Por que grandes instalações do Exchange exigem tempo de inatividade para manutenção?

Eu usei vários provedores de Exchange de primeira linha ao longo dos anos e todos eles tiveram períodos de inatividade programados regulares para manutenção de rotina (aproximadamente uma vez por mês). Pergunto-me o que é o Exchange que torna impossível evitar tempos de inatividade dessa natureza? É realmente impossível manter o tempo de atividade 24x7 ou apenas proibitivamente caro e por quê?

As atualizações do Windows e do Exchange sempre exigem reinicializações para concluir a instalação, então isso faz parte. Com um bom planejamento e configuração adequada (balanceadores de carga e cluster), você pode manter o tempo de atividade 24x7, para que o email esteja sempre disponível em um servidor.

No lado do cliente, porém, sempre há uma breve interrupção (de 5 a 30 segundos), pois o Outlook descobre que o servidor CAS ao qual está conectado está offline e a Descoberta Automática o alterna para outro. Normalmente, você recebe a mensagem "O administrador do Exchange fez uma alteração que exige que você reinicie o Outlook" quando isso acontece.

Não é uma interrupção longa, mas conta como uma interrupção; é por isso que você precisa agendar um tempo de manutenção para fazê-lo. Há também a chance de algo dar errado durante o período de manutenção; portanto, para a CYA, é necessário agendá-lo.

EDIT: Então, descobri que se você colocar um balanceador de carga na frente dos servidores CAS, não receberá a mensagem "O administrador do Exchange fez uma alteração ..." no Outlook. Você ainda terá uma breve interrupção quando o balanceador de carga o alternar para um servidor CAS ativo.

Para encurtar a história ... Você não está usando tantos provedores.

Não há motivo para agendar períodos de inatividade regulares de um ambiente do Exchange (embora o agendamento de janelas de manutenção regulares seja sempre uma coisa sábia). Especialmente com o Exchange 2010. Desde que sua redundância seja planejada e implementada corretamente, tudo flui. Rede redundante, armazenamento redundante, servidores redundantes.

Você provavelmente não conseguirá isso usando um provedor de US $ 3 / mês. Não revendo caixas de correio do Exchange de US $ 3 / mês. A maioria dos meus motivos para recomendar o Exchange hospedado lida com a importância do email e do tempo de atividade. Você precisa pagar mais por um provedor que não diminui o tempo todo, mas o ROI faz sentido.

Nosso provedor envia e-mails para cada manutenção programada. Recebemos pelo menos um deles por mês. 99% deles basicamente lêem: "Estamos fazendo manutenção em nossos servidores entre 2h e 2h15. Você pode perceber de 15 a 30 segundos de problemas de conectividade enquanto as caixas de correio / armazenamento falham".

Se você procura um tempo de atividade de 100% sem 30 segundos de failover, simplesmente não o encontrará em nenhum lugar. Não no Exchange, nem no Google Apps, nem no Domino. 100% de tempo de atividade não existe. As janelas de manutenção sempre serão necessárias e os failovers ainda requerem tempo (mesmo que esse tempo seja breve).

Portanto, encontre um novo provedor que possa custar mais, mas fornecerá o tipo de tempo de atividade necessário.

Mantenha a redundância N + 1 para literalmente todas as partes da rede para garantir que nenhum tempo de inatividade para manutenção custaria mais; mais do que o serviço não seria mais competitivo em termos de preço. A maioria das empresas é muito tolerante com o tempo de inatividade mínimo programado. Isso não é exclusivo do Exchange, quase todo fornecedor de hospedagem, de qualquer tipo, com o qual eu lidei faz aproximadamente a mesma coisa.

No caso do Exchange, ele será desativado uma vez por mês (pelo menos) para o Patch Tuesday.

A única manutenção de rotina que o Exchange precisa é aplicar patches nos servidores, o que em um ambiente criado corretamente não deve causar nenhum tempo de inatividade: mesmo com apenas dois servidores, você pode manter um deles ativo enquanto faz o patch e reinicia o outro. Fazer backups não cria tempo de inatividade e o teste de restaurações é algo que precisa ser feito em um ambiente de recuperação de desastres, não em servidores ativos. Realmente não entendo o que é essa "manutenção de rotina" ou por que deveria ser necessária.

Não estou dizendo, é claro, que garantir um tempo de atividade de 99% é fácil; problemas acontecem, mesmo nos ambientes melhores e mais caros. O que estou dizendo é que não há nenhuma razão para desativar um sistema do Exchange para "manutenção de rotina". A menos que você execute desfragmentações offline de rotina de seus bancos de dados ... algo que ninguém em sã consciência deveria fazer mais (mas ainda assim ...).

Não há nada no Exchange que o torne inerentemente não confiável ou propenso a cair ... na verdade, eu diria que o oposto se aplica. Depende de como os provedores estão configurados para fornecer seu serviço do Exchange .

Um serviço pode ser fornecido por um ou mais servidores - os principais sites, sistemas de email (por exemplo, gmail, hotmail etc.) são fornecidos por grupos de servidores projetados para permitir que alguns dos servidores que hospedam o serviço estejam offline sem afetar a disponibilidade. do serviço.

Se os servidores que prestam o serviço são construídos em um sistema que suporta alta disponibilidade (por exemplo, armazenamento em cluster), é possível que alguns dos servidores que fornecem o serviço estejam offline sem realmente colocar o serviço offline.

Essa é a teoria ... e a teoria pode ser feita para funcionar na prática. A questão é quanto o fornecedor está preparado para gastar em hardware, design e suporte de sistemas (o custo de passar de 99,99% disponível para 99,999% disponível é muito maior do que o custo de passar de 99% para 99,9% disponível, por exemplo) . No caso de um serviço hospedado, isso rapidamente se torna uma questão de quanto as pessoas estão preparadas para pagar pelo serviço.

Para um provedor, isso pode rapidamente se tornar proibitivamente caro, e quando você está gravando com disponibilidade muito alta, mesmo pequenas quantidades de tempo de inatividade podem prejudicar suas estatísticas .