Compartilhar via


Noções Básicas Sobre o Modo Coordenação de Ativação do Datacenter

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2011-09-01

O modo Coordenação de Ativação de Datacenter (DAC) é uma configuração de propriedade para um grupo de disponibilidade de banco de dados (DAG). O modo DAC fica desabilitado por padrão e deve ser habilitado para todos os DAGs com dois ou mais mebros que utilizam replicação contínua. O modo DAC não deve ser habilitado para DAGs no modo de replicação de terceiros, a menos que especificado pelo fornecedor terceirizado.

Se uma falha catastrófica que afeta o DAG ocorre (por exemplo, uma falha completa de um dos data centers), o modo DAC será usado para controlar o comportamento de ativação de um DAG. Quando o modo DAC não está habilitado e ocorre uma falha que afeta vários servidores no DAG, e a maioria dos membros do DAG é restaurada após a falha, o DAG é reiniciado e tenta montar bancos de dados. Em uma configuração com vários datacenters, esse comportamento poderá causar a síndrome do cérebro dividido, uma condição que ocorre quando todas as redes falham, e os membros do DAG não podem receber sinais de pulsação um do outro. A síndrome do cérebro dividido também pode ocorrer quando a conectividade de rede é danificada entre os data centers. A síndrome da divisão é evitada exigindo-se sempre a disponibilidade e a interação da maioria dos membros do DAG (e, no caso dos DAGs com um número par de membros, o servidor testemunha do DAG) para que o DAG esteja operacional. Quando a maioria dos membros está em comunicação, diz-se que o DAG tem um quórum.

Por exemplo, considere um cenário em que o primeiro datacenter tem dois membros do DAG e o servidor testemunha, e o segundo datacenter tem dois outros membros do DAG. Se o primeiro datacenter tiver queda de energia e você ativar o DAG no segundo datacenter (por exemplo, ativando a testemunha de compartilhamento de arquivo alternativa no segundo datacenter), se o primeiro datacenter for restaurado sem conectividade de rede ao segundo datacenter, o DAG poderá entrar no estado de síndrome de cérebro dividido.

Como funciona o modo DAC

O modo DAC foi projetado para impedir a ocorrência dessa síndrome com a inclusão de um protocolo denominado Protocolo de Coordenação de Ativação de Datacenter (DACP). Após uma falha catastrófica, quando o DAG se recuperar, ele não montará automaticamente os bancos de dados, embora, o DAG tenha um quorum. Em vez disso, o DACP é usado para determinar o estado atual do DAG e se o Gerenciador Ativo deve tentar montar os bancos de dados.

Você pode considerar o modo DAC um nível de aplicativo de quorum para bancos de dados de montagem. Para entender a finalidade do DACP e como ele funciona, é importante entender o cenário principal com o qual ele deve lidar. Considere o cenário de dois datacenters. Suponha que haja uma falha de alimentação completa no datacenter principal. Nesse caso, todos os servidores e a WAN ficam inoperantes, portanto, a organização toma a decisão de ativar o datacenter em espera. Em quase todos os cenários de recuperação, quando a energia é restaurada para o datacenter principal, a conectividade da WAN em geral não é restaurada imediatamente. Isso significa que os membros do DAG no datacenter principal receberão energia, mas não conseguirão se comunicar com os membros do DAG no datacenter em espera ativado. O datacenter principal deve sempre ter a maioria dos votantes do quorum do DAG, o que significa que, quando a energia é restaurada, mesmo na ausência de conectividade da WAN para os membros do DAG no datacenter em espera, os membros do DAG no datacenter principal têm a maioria e, por esse motivo, têm quorum. Isso é um problema porque, com quorum, esses servidores podem montar seus bancos de dados, os quais, por sua vez, causariam divergência a partir dos bancos de dados ativos reais que agora estão montados no datacenter em espera ativado.

DACP foi criado para resolver esse problema. O Gerenciador Ativo armazena um bit na memória (0 ou 1) que informa ao DAG se ele tem permissão para montar os bancos de dados locais atribuídos como ativos no servidor. Quando um DAG está em execução no modo DAC (que pode ser qualquer DAG com três ou mais membros), toda vez que o Gerenciador Ativo é inicializado, o bit é definido como 0, significando que não tem permissão para montar bancos de dados. Como ele está no modo DAC, o servidor deve tentar se comunicar com todos os outros membros do DAG conhecidos para obter outro membro do DAG e dar a ele uma resposta informando se pode ou não montar bancos de dados locais atribuídos como ativos a ele. A resposta vem na forma da definição do bit para outros Gerenciadores Ativos no DAG. Se outro servidor responder que seu bit está definido como 1, isso significa que os servidores têm permissão para montar bancos de dados, portanto, o servidor sendo inicializado define seu bit como 1 e monta os bancos de dados.

Mas, quando você se recupera de uma falta de energia no datacenter principal, em que os servidores são recuperados, mas a conectividade da WAN não foi restaurada, todos os membros do DAG no datacenter principal terão um valor de bit DACP igual a 0; e, por essa razão, nenhum dos servidores consegue se comunicar com um membro do DAG que tem um valor de bit igual a 1.

Modo DAC para DAGs com dois membros

Os DAGs com dois membros têm limitações inerentes que impedem o DACP de sozinho oferecer proteção total contra a síndrome do cérebro dividido em nível de aplicativo. Para DAGs com apenas dois membros, o modo DAC também usa o tempo de inicialização do servidor testemunha do DAG para determinar se ele pode montar bancos de dados na inicialização. O tempo de inicialização do servidor testemunha é comparado com o tempo quando o DACP foi definido como 1.

  • Se o tempo de definição do DACP for menor que tempo de inicialização do servidor testemunha, o sistema considerará que o membro do DAG e o servidor testemunha foram reinicializados ao mesmo tempo (talvez devido à perda de potência no data center principal), e o membro do DAG não terá permissão para montar bancos de dados.

  • Se o tempo de definição do DACP for menor que tempo de inicialização do servidor testemunha, o sistema considerará que o membro do DAG foi reinicializado por alguma outra razão (talvez devido a uma paralisação programada para manutenção, perda de potência ou travamento do sistema que isolaram o membro do DAG), e o membro do DAG tem permissão para montar bancos de dados.

Importante

Como o tempo de inicialização do servidor testemunha é usado para determinar se um membro do DAG pode montar seus bancos de dados ativos na inicialização, você não deverá nunca reiniciar o servidor testemunha e o membro do DAG ao mesmo tempo. Isso pode deixar o membro do DAG em um estado em que ele não pode montar bancos de dados na inicialização. Se isso acontecer, você deverá executar o cmdlet Restore-DatabaseAvailabilityGroup no DAG. Isso restaura o DACP e permite que o membro do DAG monte bancos de dados.

Outros benefícios do modo DAC

Além de impedir a síndrome do cérebro dividido no nível de aplicativo, o modo DAC também permite o uso de cmdlets de resiliência de site integrados usados para executar as alternâncias de datacenter. Entre eles estão os seguintes:

Realizar alternância de datacenter para DAGs que não estejam no modo DAC envolve o uso de uma combinação de ferramentas do Exchange e ferramentas de gerenciamento de cluster.

Para mais informações sobre alternâncias de datacenter, consulte Switchovers do Datacenter.

Habilitar o modo DAC

O modo DAC pode ser habilitado apenas com o uso do Shell de Gerenciamento do Exchange. Especificamente, você pode usar o cmdlet Set-DatabaseAvailabilityGroup para habilitar e desabilitar o modo DAC, conforme ilustrado no exemplo a seguir.

Set-DatabaseAvailabilityGroup -Identity DAG2 -DatacenterActivationMode DagOnly

No exemplo anterior, um DAG denominado DAG2 é habilitado para o modo DAC.

Para mais informações sobre a habilitação do modo DAC, consulte Configurar as Propriedades do Grupo de Disponibilidade do Banco de Dados e Set-DatabaseAvailabilityGroup.

 © 2010 Microsoft Corporation. Todos os direitos reservados.