Share via


Noções Básicas Sobre Grupos de Disponibilidade de Banco de Dados

Tópico modificado em: 2010-01-13

Um grupo de disponibilidade de banco de dados (DAG) é o componente base da estrutura de alta disponibilidade e resiliência de site interna do Exchange Server 2010. Um DAG é um grupo de até 16 servidores de Caixa de Correio que hospeda um conjunto de bancos de dados e oferece recuperação automática, no nível de banco de dados, diante de falhas que afetem servidores ou bancos de dados individuais.

Um DAG é um limite para a replicação do banco de dados de caixa de correio, alternâncias de banco de dados e servidor, e failovers, e para um componente interno chamado Active Manager. O Active Manager é um componente do Exchange 2010 que gerencia alternâncias e failovers executados em todos os servidores em um DAG. Para obter mais informações sobre o Active Manager, consulte Noções Básicas Sobre o Gerenciador de Ativos.

Qualquer servidor em um DAG pode hospedar uma cópia de um banco de dados de caixa de correio de qualquer outro servidor no DAG. Quando um servidor é adicionado a um DAG, funciona com outros servidores no DAG para oferecer recuperação automática de falhas que afetem bancos de dados de caixa de correios, como uma falha de disco ou uma falha do servidor.

Sumário

Ciclo de Vida do Grupo de Disponibilidade de Banco de Dados

Usando um Grupo de Disponibilidade de Banco de Dados para Alta Disponibilidade

Usando um Grupo de Disponibilidade de Banco de Dados para Resiliência de Site

Ciclo de Vida do Grupo de Disponibilidade de Banco de Dados

DAGs otimizam um recurso do Exchange 2010 conhecido como implantação incremental, que é a capacidade de implantar serviços e disponibilidade de dados para todos os servidores de Caixa de Correio e de bancos de dados depois da instalação do Exchange. Depois de implantar o Exchange 2010, é possível criar um DAG, adicionar servidores de Caixa de Correio a ele, e replicar bancos de dados de caixa de correio entre os membros do DAG.

Um DAG é criado usando o cmdlet New-DatabaseAvailabilityGroup. Um DAG inicialmente é criado como um objeto vazio no Active Directory. O objeto diretório é usado para armazenar informações relevantes sobre o DAG, como informações da associação de servidor. Quando um administrador adiciona o primeiro servidor a um DAG, um cluster de failover é criado automaticamente para o DAG. Além disso, é iniciada a infraestrutura que monitora os servidores em busca de falhas de rede ou servidor. Em seguida, o mecanismo de pulsação do cluster de failover e o banco de dados do cluster são usados para acompanhar e gerenciar informações sobre o DAG que podem ser alteradas rapidamente, como o status de montagem do banco de dados, o status da replicação e o local da última montagem.

Durante a criação, o DAG recebe um nome exclusivo e um ou mais endereços IP estáticos, ou configurados para usar o protocolo DHCP. Você pode especificar um único endereço IP ou uma lista de endereços IP separados por vírgula, usando o parâmetro DatabaseAvailabilityGroupIPAddresses.

Considere um DAG que terá três servidores; dois (EX1 e EX2) estão na mesma sub-rede (10.0.0.0) e o terceiro (EX3) está em uma sub-rede diferente (192.168.0.0). O administrador executa os seguintes comandos:

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

Dica

Configurar o parâmetro DatabaseAvailabilityGroupIPAddresses com o valor 0.0.0.0 configura o DAG (cluster) para o usar o DHCP para seus endereços IP ou recursos de endereços IP.

O cluster DAG1 é criado quando EX1 é adicionado ao DAG. Durante a criação do cluster, o cmdlet Add-DatabaseAvailabilityGroupServer recupera o endereço IP configurado para o DAG e ignora aqueles que não correspondem às sub-redes encontradas em EX1. Neste exemplo, o cluster DAG1 é criado com o endereço IP 10.0.0.5, e 192.168.0.5 é ignorado.

Em seguida, EX2 é adicionado. Novamente, o cmdlet Add-DatabaseAvailabilityGroupServer recupera os endereços IP configurados para o DAG. Não há alterações nos endereços IP do cluster porque EX2 está na mesma sub-rede de EX1.

Em seguida, EX3 é adicionado. Novamente, o cmdlet Add-DatabaseAvailabilityGroupServer recupera os endereços IP configurados para o DAG. Como uma sub-rede que corresponde a 192.168.0.5 está presente em EX3, o endereço 192.168.0.5 é adicionado como um recurso de endereço IP no grupo do cluster. Além disso, uma dependência OR para o recurso de Nome de Rede para cada recurso de endereço IP é automaticamente configurada. O endereço 192.168.0.5 será usado pelo cluster quando o grupo do cluster muda para o EX3.

O Cluster de Failover do Windows registra o endereço IP para o cluster no DNS quando o recurso de Nome de Rede é colocado online. Além disso, um objeto rede de cluster (CNO) é criado no Active Directory. O nome, endereços IP e o CNO do cluster são usados apenas internamente pelo sistema para proteger o DAG e para fins de comunicação interna. Os administradores e usuários finais não precisam ter interface com ou se conectar ao nome do DAG ou ao endereço IP por qualquer razão.

Além de um nome e um ou mais endereços IP, o DAG também é configurado para usar um servidor testemunha e um diretório testemunha. O servidor testemunha e o diretório testemunha são automaticamente especificados pelo sistema ou podem ser manualmente especificados pelo administrador.

Por padrão, um DAG é projetado para usar o recurso interno de replicação contínua para replicar bancos de dados de caixa de correio entre servidores do DAG. Se estiver usando uma replicação de dados de terceiros que ofereça suporte à API de Replicação de Terceiros do Exchange 2010, você deve criar o DAG no modo replicação de terceiros, usando o cmdlet New-DatabaseAvailabilityGroup com o parâmetro ThirdPartyReplication. Depois de habilitado, este modo não pode ser desabilitado.

Depois da criação do DAG, servidores de Caixa de Correio podem ser adicionados a ele. Quando o primeiro servidor é adicionado ao DAG, um cluster é formado, para ser usado pelo DAG. DAGs fazem uso limitado da tecnologia de Cluster de Failover do Windows, a saber, a pulsação do cluster, redes de cluster, e o banco de dados de cluster (para armazenar dados que alteram ou que podem ser alterados rapidamente, como mudanças de estado de banco de dados de ativo para passivo ou vice-versa ou de montado para desmontado e vice-versa). Conforme cada servidor subsequente é adicionado ao DAG, ele entra no cluster subjacente (e o modelo de quorum do cluster é automaticamente ajustado pelo sistema, conforme necessário) e o servidor é adicionado ao objeto DAG no Active Directory.

Depois que os servidores de Caixa de Correio são adicionados ao DAG, você pode configurar várias propriedades do DAG, como se utiliza criptografia de rede ou compactação de rede para replicação de banco de dados dentro do DAG. Você também pode configurar redes de DAG e criar redes de DAG adicionais, conforme necessário.

Depois de adicionar membros ao DAG e de configurá-lo, os bancos de dados de caixa de correio ativos em cada servidor podem ser replicados para os outros membros do DAG. Depois de criar cópias de bancos de dados de caixa de correio, você pode monitorar a integridade e o status das cópias usando várias ferramentas de monitoramento internas. Além disso, você pode executar alternâncias de banco de dados e de servidor, conforme necessário.

Para obter mais informações sobre criação de DAGs, gerenciamento de associação ao DAG, configuração das propriedades do DAG, criação e monitoramento de cópias de bancos de dados de caixa de correio e execução de alternâncias, consulte Gerenciando a alta disponibilidade e resiliência do site.

Retornar ao início

Usando um Grupo de Disponibilidade de Banco de Dados para Alta Disponibilidade

Para ilustrar como um DAG pode fornecer alta disponibilidade para seus bancos de dados de caixa de correio, considere o seguinte exemplo, que usa um DAG com cinco membros. Esse DAG é ilustrado na figura a seguir.

Grupo de disponibilidade de banco de dados
Grupo de Disponibilidade de Banco de Dados

Na figura anterior, os bancos de dados verdes são cópias de bancos de dados de caixa de correio ativas, e os bancos de dados azuis são cópias de bancos de dados de caixa de correio passivas. Neste exemplo, as cópias de bancos de dados não estão espelhadas por cada servidor, mas estão distribuídas entre vários servidores. Isso garante que não existam dois servidores no DAG com o mesmo conjunto de cópias de bancos de dados, fornecendo ao DAG maior resiliência a falhas, incluindo falhas que ocorrem enquanto outros componentes estão desligados como resultado de uma manutenção regular.

Considere o cenário a seguir, usando o DAG do exemplo anterior, que ilustra a resiliência a várias falhas de banco de dados e servidor.

Inicialmente, todos os bancos de dados e servidores estão íntegros. Um administrador precisa instalar algumas atualizações de sistema operacional em EX2. O administrador executa uma alternância de servidor, que ativa a cópia do DB4 em outro servidor de Caixa de Correio. Uma alternância de servidor é uma tarefa que um administrador executa para mover todas as cópias de bancos de dados de caixa de correio ativas do servidor atual para um ou mais servidores de Caixa de Correio do DAG em preparação para uma interrupção agendada, para o servidor atual. O administrador pode executar uma alternância de servidor rapidamente, executando o seguinte comando no Shell de Gerenciamento do Exchange.

Move-ActiveMailboxDatabase -Server EX2

Neste exemplo, existe apenas um banco de dados de caixa de correio ativo em EX2 (DB4), então apenas uma cópia de banco de dados de caixa de correio ativa é movida. Neste caso, omitindo o parâmetro ActivateOnServer no comando anterior, o administrador opta por deixar o sistema escolher a melhor cópia ativa nova possível, e o sistema opta por copiar em EX5, como mostra a figura a seguir.

Grupo de disponibilidade de banco de dados com um servidor offline para manutenção

Grupo de Disponibilidade de Banco de Dados com um servidor offline

Enquanto o administrador está executando tarefas de manutenção no EX2, EX3 passa por uma falha de hardware catastrófica, e fica offline. Antes de ficar offline, EX3 hospedava a cópia ativa do DB2. Para se recuperar da falha, o sistema automaticamente ativa a cópia de DB2 que está hospedada em EX1 dentro de 30 segundos. Isso está ilustrado na figura a seguir.

Grupo de disponibilidade de banco de dados com um servidor offline para manutenção e um servidor com falha

DAG com um servidor offline e um servidor com falha

Depois de concluir a manutenção agendada em EX2, o administrador coloca o servidor online novamente. Assim que EX2 estiver em funcionamento, os outros membros do DAG são notificados e as cópias de DB1, DB4 e DB5 que estão hospedadas em EX2 são automaticamente ressincronizadas com a cópia ativa de cada banco de dados. Isso está ilustrado na figura a seguir.

Grupo de disponibilidade de banco de dados com um servidor restaurado ressincronizando suas cópias de bancos de dados

DAG com servidor restaurado ressincronizando bancos de dados

Depois que o componente de hardware que falhou em EX3 for substituído por um novo componente, EX3 é colocado online novamente. Assim como aconteceu com EX2, depois que EX3 está em funcionamento, os outros membros do DAG são notificados e as cópias de DB1, DB3 e DB4 que estão hospedadas em EX3 são automaticamente ressincronizadas com a cópia ativa de cada banco de dados. Isso está ilustrado na figura a seguir.

Grupo de disponibilidade de banco de dados com um servidor reparado ressincronizando suas cópias de bancos de dados

DAG com membro ressincronizando cópias de bancos de dados

Retornar ao início

Usando um Grupo de Disponibilidade de Banco de Dados para Resiliência de Site

Além de fornecer alta disponibilidade dentro de um data center, um DAG também pode ser estendido para um ou mais outros data centers em uma configuração que fornece resiliência de site para um ou vários data centers. Nas figuras de exemplo anteriores, o DAG está localizado em um único data center e um único site do Active Directory. A implantação incremental pode ser usada para estender este DAG para um segundo data center (e um segundo site do Active Directory), implantando um servidor de Caixa de Correio e os recursos de suporte necessários (a saber, um ou mais servidores do Active Directory, e um ou mais servidores de Transporte de Hub e Acesso para Cliente), e então adicionando o servidor de Caixa de Correio ao DAG, conforme ilustrado abaixo.

Grupo de disponibilidade de banco de dados estendido por dois sites do active directory

DAG estendido a dois sites do Active Directory

Neste exemplo, uma cópia passiva de cada banco de dados ativo no data center em Redmond é configurada em EX6 no data center em Dublin.

Retornar ao início