Compartilhar via

Switchovers e Failovers

  • Artigo

Aplica-se a: Exchange Server 2013 SP1

Alternâncias e failovers são duas formas de interrupções no Microsoft Exchange Server 2013.

  • Uma alternância é uma interrupção agendada de um banco de dados ou servidor iniciado explicitamente por um cmdlet ou pelo sistema de disponibilidade gerenciada no Exchange 2013. Normalmente, as trocas são feitas para se preparar para executar uma operação de manutenção. As trocas envolvem mover a cópia do banco de dados da caixa de correio ativa para outro servidor no DAG (grupo de disponibilidade de banco de dados). Se nenhum destino saudável for encontrado durante uma substituição, os administradores receberão um erro e o banco de dados da caixa de correio permanecerá para cima ou montado.

  • Um failover se refere a eventos inesperados que resultam na indisponibilidade de serviços, dados ou ambos. Um failover envolve a recuperação automática do sistema de uma falha por meio da ativação de uma cópia do banco de dados da caixa de correio passiva a fim de torná-la a cópia do banco de dados da caixa de correio ativa. Se nenhum destino saudável for encontrado durante um failover, o banco de dados da caixa de correio será desmontado.

O Exchange 2013 foi projetado para lidar com alternâncias e failovers.

Procurando tarefas de gerenciamento relacionadas à alta disponibilidade e à resiliência de site? Consulte Gerenciando a alta disponibilidade e resiliência do site.

Alternâncias

Há três tipos de alternâncias no Exchange 2013:

  • Alternâncias de banco de dados
  • Alternâncias de servidor
  • Alternâncias de datacenter

Alternâncias de banco de dados

Uma alternância de banco de dados é o processo por meio do qual um banco de dados ativo individual é trocado por outra cópia do banco de dados (uma cópia passiva), e essa cópia do banco de dados torna-se a nova cópia do banco de dados ativo. Alternâncias de banco de dados podem acontecer dentro de datacenters e entre eles. Uma alternância de banco de dados pode ser executada usando o Centro de Administração do Exchange (EAC) ou o Shell. Independentemente da interface usada, o processo de alternância é o seguinte:

  1. O administrador inicia uma alternância de banco de dados para mover a cópia atual do banco de dados da caixa de correio ativa para outro servidor.

  2. O cliente utilizado para a tarefa realiza uma chamada RPC para o serviço de Replicação do Microsoft Exchange em um membro do DAG.

  3. Se o membro do DAG não mantiver a função de Gerenciador Ativo Primário (PAM), este remeterá a tarefa para o servidor que mantiver a função PAM.

  4. A tarefa realiza uma chamada RPC para o serviço de Replicação do Microsoft Exchange no servidor que mantém a função PAM.

  5. O PAM lê e atualiza as informações de localização do banco de dados que estão armazenadas no banco de dados de cluster do DAG.

  6. O PAM entra em contato com o serviço de Replicação do Microsoft Exchange no membro do DAG cuja cópia passiva está sendo ativada como a nova cópia do banco de dados da caixa de correio ativa.

  7. O serviço de Replicação do Microsoft Exchange no servidor de destino consulta os serviços de Replicação do Microsoft Exchange em todos os outros membros do DAG para determinar a melhor fonte de log para a cópia do banco de dados.

  8. O banco de dados do servidor atual é desmontado, e o serviço de Replicação do Microsoft Exchange no servidor de destino copia os logs restantes para o servidor de destino.

  9. O serviço de Replicação do Microsoft Exchange no servidor de destino solicita a montagem de um banco de dados.

  10. O serviço de Armazenamento de Informações do Microsoft Exchange no servidor de destino repete os arquivos de log e monta o banco de dados.

  11. Quaisquer códigos de erro são retornados para o serviço de Replicação do Microsoft Exchange do servidor de destino.

  12. O PAM atualiza as informações do estado da cópia do banco de dados no banco de dados de cluster do DAG.

  13. Quaisquer códigos de erro são retornados pelo serviço de Replicação do Microsoft Exchange do servidor de destino para o serviço de Replicação do Microsoft Exchange do PAM.

  14. O serviço de Replicação do Microsoft Exchange do PAM retorna quaisquer erros para a interface administrativa em que a tarefa foi chamada.

  15. O PowerShell Remoto retorna os resultados da operação para a interface administrativa de chamada.

Para obter etapas detalhadas sobre como realizar um alternância de banco de dados, consulte Ativar uma cópia do banco de dados de caixa de correio.

Alternâncias de servidor

Uma alternância de servidor é o processo pelo qual todos os bancos de dados ativos em um membro do DAG são ativados em um ou mais outros membros do DAG. Assim como a alternância de banco de dados, uma alternância de servidor pode ocorrer tanto dentro de um mesmo datacenter quanto entre datacenters, e pode ser iniciada com o uso do EAC e do Shell. Independentemente da interface utilizada, o processo de alternância do servidor é o seguinte:

  1. O administrador inicia uma alternância de servidor para mover todas as cópias atuais do banco de dados da caixa de correio ativas para um ou mais servidores diferentes.

  2. A tarefa segue as mesmas etapas descritas anteriormente, neste tópico, para alternâncias de banco de dados (Etapas 2 a 4) para cada um dos bancos de dados ativos no servidor atual.

  3. O PAM lê e atualiza as informações de localização do banco de dados que estão armazenadas no banco de dados de cluster do DAG.

  4. O PAM entra em contato com o serviço de Replicação do Microsoft Exchange de cada membro do DAG que possui uma cópia passiva sendo ativada.

  5. O serviço de Replicação do Microsoft Exchange nos servidores de destino consulta os serviços de Replicação do Microsoft Exchange em todos os outros membros do DAG para determinar a melhor fonte de log para a cópia do banco de dados.

  6. O banco de dados do servidor atual é desmontado, e o serviço de Replicação do Microsoft Exchange de cada servidor de destino copia os logs restantes.

  7. O serviço de Replicação do Microsoft Exchange em cada servidor de destino solicita a montagem de um banco de dados.

  8. O serviço de Armazenamento de Informações do Microsoft Exchange de cada servidor de destino repete os arquivos de log e monta o banco de dados.

  9. Quaisquer códigos de erro são retornados para o serviço de Replicação do Microsoft Exchange do servidor de destino.

  10. O PAM atualiza as informações do estado da cópia do banco de dados no banco de dados de cluster do DAG.

  11. Quaisquer códigos de erro são retornados pelo serviço de Replicação do Microsoft Exchange do servidor de destino para o serviço de Replicação do Microsoft Exchange do PAM.

  12. O serviço de Replicação do Microsoft Exchange do PAM retorna quaisquer erros para a interface administrativa em que a tarefa foi chamada.

  13. O PowerShell Remoto retorna os resultados da operação para a interface administrativa de chamada.

Para obter etapas detalhadas sobre como realizar uma alternância de servidor, consulte Alternar um Servidor.

Switchovers do Datacenter

Em uma configuração resiliente do site, a recuperação automática como resposta a uma falha no nível do site pode ocorrer dentro de um DAG, o que permite que o sistema de mensagens permaneça em um estado funcional. Essa configuração exige pelo menos três locais, devido ao fato de exigir a implantação dos membros DAG em dois locais e do servidor testemunha do DAG em um terceiro local.

Se você não tiver três locais ou mesmo se tiver três locais, mas quiser controlar ações de recuperação no nível do datacenter, poderá configurar um DAG para recuperação manual se ocorrer uma falha no nível do site. Nesse caso, você executaria um processo chamado alternância de datacenter. Assim como em muitos cenários de recuperação de desastres, o planejamento e a preparação antecipados para uma alternância de datacenter podem simplificar o processo de recuperação e reduzir a duração da interrupção.

Devido às inúmeras alterações arquitetônicas no Exchange 2013, incluindo a consolidação de funções de servidor, executar uma troca de datacenter no Exchange 2013 é mais fácil do que era no Exchange 2010. Para obter instruções detalhadas de como executar uma alternância de datacenter, consulte Switchovers do Datacenter.

Failovers

Um failover é um processo de ativação automático que pode ocorrer no banco de dados, no servidor ou no nível do datacenter. Os failovers ocorrem em resposta a uma falha que afeta um banco de dados individual (por exemplo, uma perda de armazenamento isolada), um servidor completo (por exemplo, uma falha na placa mãe ou perda de energia) ou um site completo (por exemplo, a perda de todos os membros DAG em um site).

Os DAGs e as cópias do banco de dados da caixa de correio fornecem redundância completa (e recuperação rápida) tanto dos dados como dos serviços que fornecem acesso aos dados. A tabela a seguir lista as ações de recuperação esperadas para várias falhas. Algumas falhas exigem que o administrador inicie a recuperação, e outras são tratadas automaticamente pelo sistema.

Descrição Ativação automática Ação de reparo automático Estado durante o reparo: Ativo Estado durante o reparo: Passivo Ações de reparo Comments
Falha simples no banco de dados do Mecanismo de Armazenamento Extensível (ESE): As unidades que armazenam o banco de dados estão retornando erros em algumas leituras (por exemplo, um erro -1018). Possível interrupção breve.

Possível failover automático.		 Correção automática de página incorreta. Alternância manual, failover automático ou reparo online. Falhou Recompilação de RAID, reparo do banco de dados e da cópia do banco de dados, restauração e execução da recuperação em vez de correção da página ou correção de página da cópia. Pode haver outros códigos de falhas simples do banco de dados.

Não inclui falhas de bloco do sistema de arquivos NTFS.

Se o failover ou a alternância forem executados, o servidor de host será atualizado.
Falha "semissuave" no banco de dados do ESE: As unidades que armazenam o banco de dados estão retornando erros em algumas gravações. Breve interrupção durante o failover automático. Recompilação automática do disco/volume após possível substituição da unidade. Desmontado se não puder ser recuperado. Falhou A recompilação de RAID pode resolver o problema.

Cópia e reparo, restauração e execução da recuperação ou recompilação do disco/volume após possível substituição.		 Um erro semissuave de gravação do ESE significa que algumas gravações foram bem-sucedidas.

Não inclui falha de bloco NTFS.
Falha "semissuave" de log do ESE: As unidades que armazenam os dados de log estão retornando erros não recuperados em algumas leituras ou gravações. Breve interrupção durante o failover automático. Recompilação automática do disco/volume após possível substituição da unidade. Desmontado se não puder ser recuperado. Falhou A recompilação de RAID pode resolver o problema.

Cópia e reparo, restauração e execução da recuperação ou recompilação do disco/volume após possível substituição.		 Um erro semissuave de leitura/gravação do ESE significa que algumas leituras/gravações foram bem-sucedidas.

Se o banco de dados falhar, a recuperação automática ocorrerá antes de o processo de recuperação de dados de log começar.
Erro de software ou esgotamento de recursos do ESE: Um erro em que o ESE finaliza a instância (por exemplo, Evento ID 1022, profundidade do ponto de verificação muito alta). Breve interrupção durante o failover automático. Nenhuma. Desmontado se não puder ser recuperado. Falhou Correção de problema de recurso subjacente. Essa falha poderia ser o erro de superfície dos outros casos.
Falhas de bloco NTFS: As unidades que armazenam o banco de dados ou os logs apresentam erro de leitura ou gravação em uma estrutura de controle NTFS. Breve interrupção durante o failover automático. Volume reconstruído após possível substituição de unidade. Desmontado se não puder ser recuperado. Falhou A recompilação de RAID pode resolver o problema. Os utilitários para NTFS podem resolver os problemas com NTFS. A recuperação do exchange pode ser necessária. Esse evento é mais provável de ocorrer quando RAID não estiver em uso. Se esse evento afetar o volume de log ativo, alguns arquivos de log recentes serão perdidos.

Não inclui erros corrigidos automaticamente pelo NTFS ou sua pilha de hardware ou software subjacente.
Falha no banco de dados ou na unidade de log: uma unidade que armazena o banco de dados ou os logs falhou e está inacessível. Breve interrupção durante o failover automático. Unidade reformatada ou substituída, seguida de recompilação completa de volume. Desmontado se não puder ser recuperado. Falhou Substituição de unidade seguida de possível recompilação de RAID.

Substituição de unidade seguida de recompilação completa de volume.

Recompilação completa de volume.		 Não aplicável.
Falha de volume de banco de dados ou log: o volume falha devido a problemas de volume de NTFS ou de nível inferior. Breve interrupção durante o failover automático. Unidade reformatada ou substituída. Desmontado se não puder ser recuperado. Falhou Substituição de unidade seguida de possível recompilação de RAID.

Substituição de unidade seguida de recompilação completa de volume.

Recompilação completa de volume.		 Não se aplica.
Banco de dados ou volume de log sem espaço: O sistema de arquivos NTFS com o banco de dados ou os arquivos de log está sem espaço. Failover automático se outra cópia não estiver em estado similar. Nenhuma. Desmontado. Falhou Execução de backups completos ou incrementais, exclusão manual de logs, espera de intervalo de tempo, continuação da cópia do banco de dados ou reparo da cópia do banco de dados com falha. Não se aplica.
O administrador desmonta o banco de dados errado. Se o failover automático não estiver bloqueado pelo administrador, haverá uma breve interrupção.

Se o failover automático estiver protegido, haverá uma interrupção até que o banco de dados seja montado.		 Nenhuma. Desmontado. Não se aplica. O administrador corrige o erro. Não se aplica.
O administrador suspende a cópia do banco de dados errada. Dependendo da configuração e da cópia afetada, a recuperação automática poderá ser evitada. Nenhuma. Não se aplica. Suspenso O administrador corrige o erro. Não se aplica.
O administrador desmonta um banco de dados para armazenamento, NTFS ou manutenção do volume. Se o failover automático não estiver bloqueado pelo administrador, haverá uma breve interrupção.

Se o failover automático estiver bloqueado, haverá interrupção até que o administrador conclua a tarefa.		 Nenhuma. Desmontado. Não se aplica O administrador conclui a tarefa. Não se aplica.
O administrador suspende uma cópia do banco de dados para armazenamento, NTFS ou manutenção do volume. Dependendo da configuração e da cópia afetada, a recuperação automática poderá ser evitada. Nenhuma. Não se aplica. Suspenso O administrador conclui as ações. Não se aplica.
O administrador desmonta um banco de dados para manutenção de banco de dados offline. Interrupção até ser reparado. Nenhuma. Desmontado. Suspenso O administrador conclui as ações. Há divergência entre cópias ativas e passivas do banco de dados.

O administrador deve suspender as cópias.
Falha do controlador de armazenamento, de disco ou da rede da área de armazenamento (SAN). Breve interrupção durante o failover automático. Nenhuma. Desmontado. Qualquer Reparo do hardware. Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema apresentou falha.
Manutenção do hardware do servidor. Breve interrupção durante o failover automático (a menos que bloqueado por um administrador). Nenhuma. Desmontado. Qualquer Conclusão das ações. Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema foi encerrado.
Manutenção do software do servidor. Breve interrupção durante o failover automático (a menos que bloqueado por um administrador). Nenhuma. Desmontado. Qualquer Conclusão das ações. Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema foi encerrado.
O serviço da Microsoft Exchange Information Store é interrompido ou pausado por um administrador. Breve interrupção durante o failover automático. Nenhuma. Desmontado. Qualquer Reinicie o serviço Microsoft Exchange Information Store. Não aplicável.
Falha no serviço da Microsoft Exchange Information Store; o sistema operacional ainda está em execução. Breve interrupção durante o failover automático. O Service Control Manager reinicia o serviço Microsoft Exchange Information Store. Desmontado. Qualquer Reinicie manualmente ou automaticamente o serviço Microsoft Exchange Information Store. Uma cópia de banco de dados passivo estará no estado que existia quando o serviço microsoft Exchange Information Store falhasse.
Falha parcial do serviço da Microsoft Exchange Information Store; alguma parte do repositório exchange para de funcionar, mas não é identificada como falha. Possível interrupção breve durante o failover automático. Nenhuma. Montado e parcialmente funcional. Qualquer um, mas pode estar parcialmente funcional. Reinicie o servidor, o sistema operacional ou o serviço Microsoft Exchange Information Store. Não aplicável.
Falha do servidor: O servidor apresentou falha por causa de um dos seguintes motivos:
  • Falha completa de energia
  • Falha não recuperada do chip do processador, da placa-mãe ou do painel traseiro
  • Erro de parada do sistema operacional
  • O sistema operacional parou de responder
  • Falha total na comunicação
 Breve interrupção durante o failover automático. Reinicializar o computador. Desmontado. Qualquer Restauração de energia, alteração das configurações do sistema operacional, alteração das configurações de hardware, substituição do hardware, reinicialização do sistema operacional, manutenção do sistema operacional, manutenção do hardware ou reparo de problemas na comunicação. Não se aplica.
O DAG apresenta falha de quorum. Interrupção até ser reparado. Nenhuma. Desmontado. Qualquer Reparo do quorum com falha, atribuição de novo quorum ou restauração da rede que está causando a falha no quorum. Uma cópia do banco de dados passiva estará no estado em que se encontrava quando o sistema apresentou falha.
Falha na comunicação da rede MAPI: O servidor não está mais disponível na rede MAPI. Breve interrupção durante o failover automático; deve estar sem perdas. Nenhuma. Continua havendo tentativas de comunicação. Desmontado. Qualquer Correção do problema de comunicação ao corrigir problemas de hardware ou software. Não aplicável.
Falha na comunicação de rede de replicação: o servidor não pode receber pulsações, cópias de log ou sementes por meio da rede de replicação com falha. Pode haver breve interrupção de cópias e propagações enquanto a carga de trabalho é transferida para outra rede. Nenhuma. Continua havendo tentativas de comunicação. Nenhuma. Qualquer Correção do problema de comunicação ao corrigir problemas de hardware ou software. Resiliência afetada por falha.
Várias falhas de comunicação de rede: o servidor não pode receber pulsações, cópias de log ou sementes por meio de várias redes. Breve interrupção durante o failover automático; deve estar sem perdas. Nenhuma. Continua havendo tentativas de comunicação. Desmontado. Qualquer Correção do problema de comunicação ao corrigir problemas de hardware ou software. Pelo menos uma rede ainda está funcionando.
Falha parcial de uma ou mais redes: Redes apresentam altas taxas de erro. Falha não detectada; nenhuma ação. Nenhuma. Montado, mas há possíveis problemas de desempenho. Qualquer Correção do problema de comunicação ao corrigir problemas de hardware ou software. Redes apresentam taxas de erro mais altas do que o normal.
Sistemas operacionais não detectados travam: o sistema operacional para de responder, mas não é detectado por monitoramento ou clustering. Nenhuma. Nenhuma. Qualquer. Qualquer Reiniciar ou encerrar os recursos que não estão respondendo. O travamento não foi detectado, portanto nenhuma ação foi executada.

Algumas funcionalidades podem ser operacionais.
A unidade do sistema operacional apresenta falha. Breve interrupção durante o failover automático. Nenhuma. Desmontado. Qualquer Substituição da unidade e reconstrução do servidor ou do volume usando RAID. Não se aplica.
A unidade do sistema operacional está sem espaço. Breve interrupção durante o failover automático. Nenhuma. Desmontado. Qualquer Liberação manual de espaço no volume. Não aplicável.
As unidades que contêm binários do Exchange experimentam uma falha de volume ou unidade. Breve interrupção durante o failover automático. Nenhuma. Desmontado. Qualquer Substituição da unidade e reinstalação do aplicativo ou reconstrução do volume usando a RAID. Não aplicável.
A unidade que contém os binários do Exchange está fora do espaço. Breve interrupção durante o failover automático. Nenhuma. Desmontado. Qualquer Liberação manual de espaço no volume. Não se aplica.
Novo log inválido detectado: A sequência de log foi interrompida por um arquivo existente. Breve interrupção durante o failover automático; assume outras cópias que não têm o mesmo problema. Nenhuma. Desmontado. Falhou Remoção dos logs destrutivos após a determinação de sua origem. Os logs destrutivos não devem replicar.
A replicação contínua detecta log inválido: A repetição detecta um log inadequado durante uma cópia ou repetição. Não se aplica. Descartar log. Não se aplica. Falhou Descarte do log inválido; movimentação do fluxo do log de impacto. Não se aplica.

Failovers de banco de dados

Um failover de banco de dados ocorre quando uma cópia do banco de dados que estava ativa não é mais capaz de permanecer ativa. As seguintes ocorrências fazem parte de um failover de banco de dados:

  1. A falha do banco de dados é detectada pelo serviço de Armazenamento de Informações do Microsoft Exchange.

  2. O serviço de Armazenamento de Informações do Microsoft Exchange grava eventos de falha no log de eventos do canal vermelho.

  3. O Gerenciador Ativo do servidor que contém o banco de dados com falha detecta os eventos de falha.

  4. O Gerenciador Ativo solicita o status da cópia do banco de dados dos outros servidores que mantêm uma cópia do banco de dados.

  5. Os outros servidores retornam o status da cópia do banco de dados solicitado pelo Gerenciador Ativo solicitador.

  6. O PAM inicia a movimentação do banco de dados ativo para outro servidor no DAG usando um algoritmo de seleção de melhor cópia.

  7. O PAM atualiza o local de montagem do banco de dados no banco de dados do cluster para consultar o servidor selecionado.

  8. O PAM envia uma solicitação para o Gerenciador Ativo do servidor selecionado para se tornar o mestre do banco de dados.

  9. O Gerenciador Ativo do servidor selecionado solicita que o serviço de Replicação do Microsoft Exchange tente copiar os últimos logs do servidor anterior e defina o sinalizador montável do banco de dados.

  10. O serviço de Replicação do Microsoft Exchange copia os logs do servidor que anteriormente tinham a cópia ativa do banco de dados.

  11. O Gerenciador Ativo lê o número de geração de log máximo a partir do banco de dados do cluster.

  12. O serviço de Armazenamento de Informações do Microsoft Exchange monta a nova cópia ativa do banco de dados.

Failovers de servidor

Um failover de servidor ocorre quando o membro do DAG não é mais capaz de prestar serviços à rede MAPI ou quando o serviço do Cluster de um membro do DAG não é mais capaz de contatar os demais membros do DAG. As seguintes ocorrências fazem parte de um failover do servidor:

  1. O serviço de Cluster do PAM envia uma notificação para o PAM mediante uma de duas condições:

    1. Nó Para baixo: o servidor é acessível, mas não pode participar de operações DAG.
    2. Mapi Network Down: o servidor não pode ser contatado pela rede MAPI e, portanto, não pode participar de operações DAG.

  2. Se o servidor for alcançável, o PAM entra em contato com o Gerenciador Ativo do servidor afetado e solicita que todos os bancos de dados sejam desmontados imediatamente.

  3. Para cada cópia do banco de dados afetada:

    1. O PAM solicita o status da cópia do banco de dados de todos os servidores do DAG.
    2. O PAM recebe uma resposta de todos os membros alcançáveis e ativos do DAG.
    3. O PAM tenta determinar a melhor fonte de log dentre todos os servidores que respondem ao consultar o número mais recente de geração de log de cada um dos respondentes.
    4. Cada um dos servidores responde com o número de geração de log.

  4. O PAM recupera o status do catálogo de índices de pesquisa atual do banco de dados do cluster.

  5. Com base no número de geração de log e a integridade do catálogo de cada cópia do banco de dados, o PAM seleciona as melhores cópias a fim de ativá-las.

  6. O PAM atualiza o local de montagem do banco de dados no banco de dados do cluster.

  7. O PAM inicia o failover do banco de dados comunicando-se com o Gerenciador Ativo de um ou mais outros servidores.

  8. O Gerenciador Ativo dos servidores selecionados solicitam que o serviço de Replicação do Microsoft Exchange tente copiar os últimos logs do servidor anterior e defina o sinalizador montável.

  9. Quando o banco de dados é montável, o Gerenciador Ativo dos servidores monta os bancos de dados.

Para obter mais informações sobre o melhor processo de seleção de cópias do Gerenciador Ativo, consulte Active Manager.

Failovers de datacenter

Mudanças significativas foram feitas no Exchange 2013 que resolvem os desafios apresentados na configuração de resiliência de site do Exchange 2010. Com a simplificação de namespace, consolidação das funções do servidor, separação do servidor de Acesso para Cliente e recuperação do DAG (no Exchange 2013, o namespace não precisa ser movido com o DAG) e as mudanças do balanceamento de carga o Exchange 2013 fornece novas opções de resilência de site, como a capacidade de usar um único namespace global. Além disso, se você tiver mais de dois locais para implantar componentes do serviço de mensagens, o Exchange 2013 também habilita a configuração do serviço de mensagens para failover automático em resposta a falhas que exigiram intervenção manual no Exchange 2010.

A resiliência de site foi simplificada operacionalmente no Exchange 2013. O Exchange aplica a tolerância a falhas interna no namespace por meio de vários endereços IP, balanceamento de carga (e, se necessário, a capacidade de levar servidores dentro e fora de serviço). Uma das alterações mais significativas que fizemos no Exchange 2013 foi usar a capacidade dos clientes de armazenar em cache vários endereços IP retornados de um servidor DNS em resposta a uma solicitação de resolução de nomes. Considerando que o cliente tem a capacidade de armazenar em cache vários endereços IP (quase todos os HTTP do cliente armazenam, e já que quase todos os protocolos de acesso para cliente no Exchange 2013 são baseados em HTTP (Outlook, Outlook Anywhere, EAS, EWS, OWA, EAC, RPS, etc.) e todos os clientes HTTP suportados têm a capacidade de usar vários endereços IP), fornecendo dessa forma failover no lado do cliente. Você pode configurar o DNS para lidar com vários endereços IP para um cliente durante uma resolução de nome. O cliente solicita mail.contoso.com e recebe de volta dois endereços IP ou quatro endereços IP, por exemplo. No entanto, muitos endereços IP que o cliente recebe de volta serão usados de forma confiável pelo cliente. Essa utilização ideal torna o cliente muito melhor porque, se um dos endereços IP falhar, o cliente terá um ou mais outros para tentar se conectar. Se um cliente tentar um e ele falhar, ele aguardará cerca de 20 segundos e tentará o próximo na lista. Dessa forma, se perder a conectividade com a sua matriz CAS principal e tiver um endereço IP secundário publicado de uma matriz CAS secundária, a recuperação dos clientes acontecerá automaticamente e em aproximadamente 21 segundos.

Os clientes HTTP modernos (sistemas operacionais e navegadores da Web com dez anos ou menos) funcionam com essa redundância automaticamente. A pilha HTTP pode aceitar vários endereços IP para um FQDN e, se o primeiro IP ele tentar falhar com força (por exemplo, não pode se conectar), ele tentará o próximo IP na lista. Em uma falha suave (conectar-se perdido após a sessão estabelecida, devido a uma falha intermitente no serviço em que, por exemplo, um dispositivo está soltando pacotes e precisa ser retirado do serviço), o usuário pode precisar atualizar seu navegador.

Com a configuração correta, o failover pode ocorrer no nível de cliente, e os clientes serão automaticamente redirecionados para um segundo datacenter que tem servidores de Acesso para Cliente operacionais, e esses servidores usam um proxy na comunicação de volta para o servidor de Caixa de Correio, que permanece não afetado pela interrupção (porque você não faz uma alternância). Em vez de trabalhar para recuperar o serviço, o serviço se recupera e você pode se concentrar em corrigir o problema principal (por exemplo, substituir um balanceador de carga com falha).

Como você pode fazer failover do namespace entre datacenters, tudo o que é necessário para obter um failover do datacenter é um mecanismo para failover da função Caixa de Correio entre datacenters. Para obter failover automático para o DAG, você arquitete uma solução em que o DAG é dividido uniformemente entre dois datacenters e, em seguida, coloque o servidor testemunha em um terceiro local para que ele possa ser arbitrado por membros DAG em qualquer datacenter, independentemente do estado da rede entre os datacenters que contêm os membros DAG. A chave é isolar a terceira localização falhas de rede que afetam as localizações contendo membros DAG.

Se você tiver apenas dois datacenters e quiser poder configurar o failover automático, poderá utilizar o Microsoft Azure como seu terceiro local. Você precisará criar uma rede virtual do Azure e conectá-la aos dois datacenters usando uma VPN de vários pontos. Em seguida, você poderá colocar seu servidor testemunha em uma máquina virtual do Microsoft Azure. Para obter mais informações, consulte Usando uma VM do Microsoft Azure como um servidor testemunha DAG.