Failover automático do Exchange DAG - motivos

Question

Nosso DAG 2013 parece ativar arbitrariamente DBs em outros servidores e movê-los dos que estavam ativos. Ao observar as métricas, não houve picos visíveis em RAM / IO / Networking / etc, por isso não sei por que estão em movimento.

Não consigo descobrir como auditar por que os bancos de dados são movidos e estou procurando um arquivo de log ou cmdlet do powershell que possa ajudar a solucionar isso.

Para esclarecimentos, simplificando bastante as coisas: O servidor 1 tem DB1 ativo O servidor 2 tem o DB2 ativo Servidor 3 tem DB3 ativo

Cada servidor tem cópias passivas dos outros dois bancos de dados. Durante a noite, sem motivo aparente, as coisas vão se mexer e ficar assim:

O servidor 1 tem DB1 e DB3 ativos O servidor 2 não tem DBs ativos Servidor 3 tem DB 2 ativo

Obrigado por qualquer ajuda!

PS: Caso alguém esteja lidando com isso e queira pará-lo com a perda de alguns recursos (por exemplo, autofailover) considere o uso da seguinte política em cada servidor em que você deseja interromper o envio automático:

Set-MailboxServer -Identity EXSRV01 -DatabaseCopyAutoActivationPolicy Blocked

Em que EXSRV01 é substituído pelo nome do servidor Exchange para interromper a ativação automática.

    

Answer 1

Vou adicionar ao meu comentário uma resposta mais completa. Com base na resposta do mfinni no clustering, se um banco de dados falhar, haverá sempre um erro. A reação padrão do Exchange a qualquer coisa errada é falhar em um banco de dados para proteger contra cenários cerebrais divididos (ambos os bancos de dados acham que estão ativos e causam crimes contra a humanidade).

Você pode ter uma CPU / Memória perfeitamente razoável e aparentemente sem blips de rede, mas no Cluster de MSFT você verá falhas por vários motivos. Se o clustering acha que está tendo um problema, ele faz o trabalho fantástico de REINICIAR o serviço de cluster para garantir que tudo esteja funcionando. Quando isso acontece, o Exchange falhará em TODOS os bancos de dados. Isso pode ser causado por muitos problemas semelhantes a:

1. Alto uso de memória além de servidores de caixa de correio já alocação de memória maluca (2013 faz um trabalho melhor aqui)
2. Item da lista
3. Rede "blips"; não ofenda seu administrador de rede aqui, pode ser literalmente um aumento de TTL na rede de heartbeat OU até mesmo um reset para um vswitch por qualquer motivo
4. Vmotion .... mas você tem isso correto porque isso não é suportado. ; -)

Os registros do visualizador de eventos de clusterização fornecem a você a hora da "falha" e você pode correlacionar isso aos logs do visualizador de eventos de alta disponibilidade para descobrir se houve um acúmulo de um problema ou se foi um evento súbito. Eu vi onde o próprio banco de dados estava muito ocupado tentando acompanhar algumas bombas de e-mail de alguns departamentos causadas por tarefas agendadas de controle e isso fez com que o log de transações ultrapassasse os limites de replicação para a integridade do banco de dados ... boom. .. failover.

Se você encontrar alguma coisa nesses registros, poste-a (esfregue dados confidenciais) e eu posso ajudar mais. E verifique se você está com o patch atualizado em todos os servidores do Exchange. Houve algumas atualizações de CU que causaram problemas semelhantes sem motivo.

    

Answer 2

Se essas forem VMs e o processo de backup envolver a obtenção de um instantâneo de VMware, você poderá atingir o tempo limite do heartbeat permitido do DAG. Você precisa definir os valores de atraso e limite de SameSubnet e CrossSubnet superiores aos padrões.

link

cluster /prop SameSubnetDelay=2000:DWORD cluster /prop CrossSubnetDelay=4000:DWORD cluster /prop CrossSubnetThreshold=10:DWORD cluster /prop SameSubnetThreshold=10:DWORD