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 transição é uma falha agendada de uma base de dados ou servidor que é explicitamente iniciada por um cmdlet ou pelo sistema de disponibilidade gerido no Exchange 2013. Normalmente, as transições são feitas para preparar a execução de uma operação de manutenção. As transições envolvem mover a cópia ativa da base de dados da caixa de correio para outro servidor no grupo de disponibilidade da base de dados (DAG). Se não for encontrado nenhum destino em bom estado de funcionamento durante uma transição, os administradores receberão um erro e a base de dados da caixa de correio permanecerá ativada ou montada.

  • 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 não for encontrado nenhum destino em bom estado de funcionamento durante uma ativação pós-falha, a base de dados da caixa de correio será desmontada.

O Exchange 2013 foi concebido para processar ativações pós-falha e comutadores.

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. Pode efetuar uma transição de base de dados com o Centro de administração do Exchange (EAC) ou a 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 não tiver três localizações ou mesmo se tiver três localizações, mas quiser controlar as ações de recuperação ao nível do datacenter, pode configurar um DAG para recuperação manual se ocorrer uma falha ao 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, efetuar uma transição de datacenter no Exchange 2013 é mais fácil do que 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 seguinte 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 da 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. É mais provável que este evento ocorra quando o RAID não está a ser utilizado. Se este evento afetar o volume de registo ativo, alguns ficheiros de registo recentes serão perdidos.

Não inclui erros corrigidos automaticamente pelo NTFS ou sua pilha de hardware ou software subjacente.
Falha na base de dados ou na unidade de registo: uma unidade que armazena a base de dados ou os registos 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 no volume da base de dados ou do registo: o volume falha devido a problemas de volume de nível inferior ou NTFS. 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 Arquivo de Informações do Microsoft Exchange é parado ou colocado em pausa por um administrador. Breve interrupção durante o failover automático. Nenhuma. Desmontado. Qualquer Reinicie o serviço Arquivo de Informações do Microsoft Exchange. Não aplicável.
O serviço Arquivo de Informações do Microsoft Exchange falha; O sistema operativo 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 manual ou automaticamente o serviço Microsoft Exchange Information Store. Uma cópia passiva da base de dados estará no estado que existia quando o serviço Arquivo de Informações do Microsoft Exchange falhou.
Falha parcial do serviço Arquivo de Informações do Microsoft Exchange; parte do arquivo do Exchange deixa de funcionar, mas não é identificada como falhada. 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 operativo 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 da rede de replicação: o servidor não pode receber heartbeats, cópias de registo ou semente através 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 heartbeats, cópias de registo ou semente através 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.
Os sistemas operativos não detetados bloqueiam: o sistema operativo deixa de responder, mas não é detetado através da monitorização ou clustering. Nenhuma. Nenhuma. Qualquer um. 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 sofrem 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á sem 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 uma ativação pós-falha da base 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 uma ativação pós-falha 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ó Inativo: o servidor está acessível, mas não consegue participar em operações do DAG.
    2. Rede MAPI Inativa: o servidor não pode ser contactado através da rede MAPI e, por conseguinte, não pode participar em operações da 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 tiver mais de duas localizações para implementar componentes do serviço de mensagens, o Exchange 2013 também ativa a configuração do serviço de mensagens para ativação pós-falha automática 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 tolerância a falhas incorporada no espaço de nomes através de vários endereços IP, balanceamento de carga (e, se necessário, a capacidade de colocar e sair do serviço dos servidores). Uma das alterações mais significativas que fizemos no Exchange 2013 foi utilizar a capacidade dos clientes de colocar em cache múltiplos endereços IP devolvidos a partir de um servidor DNS em resposta a um pedido 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 obtém serão utilizados de forma fiável pelo cliente. Esta utilização ideal torna o cliente muito melhor porque se um dos endereços IP falhar, o cliente tem um ou mais a que tentar ligar. 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 operativos e browsers com 10 anos ou menos) trabalham com esta redundância automaticamente. A pilha HTTP pode aceitar vários endereços IP para um FQDN e, se o primeiro IP falhar (por exemplo, não conseguir ligar), tentará o PRÓXIMO IP na lista. Numa falha recuperável (ligação perdida após a sessão estabelecida, devido a uma falha intermitente no serviço em que, por exemplo, um dispositivo está a remover pacotes e precisa de ser retirado do serviço), o utilizador poderá ter de atualizar o browser.

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 recupera-se sozinho e pode concentrar-se em corrigir o problema principal (por exemplo, substituir um balanceador de carga com falha).

Uma vez que pode efetuar a ativação pós-falha do espaço de nomes entre datacenters, tudo o que é necessário para alcançar uma ativação pós-falha do datacenter é um mecanismo de ativação pós-falha da função caixa de correio entre datacenters. Para obter a ativação pós-falha automática para o DAG, arquitete uma solução em que o DAG é dividido uniformemente entre dois datacenters e, em seguida, coloque o servidor de testemunhos numa terceira localização para que possa ser arbitrado pelos membros do DAG em qualquer um dos datacenters, independentemente do estado da rede entre os datacenters que contêm os membros do DAG. A chave é isolar a terceira localização falhas de rede que afetam as localizações contendo membros DAG.

Se tiver apenas dois datacenters e quiser configurar a ativação pós-falha automática, pode utilizar o Microsoft Azure como a sua terceira localização. Terá de criar uma rede virtual do Azure e ligá-la aos seus dois datacenters através de uma VPN de vários pontos. Em seguida, poderá colocar o servidor de testemunhos numa máquina virtual do Microsoft Azure. Para obter mais informações, veja Using a Microsoft Azure VM as a DAG witness server (Utilizar uma VM do Microsoft Azure como um servidor de testemunhos da DAG).