Group de Disponibilidade de Banco de Dados (DAG) é uma solução de alta disponibilidade e recuperação de desastres no Microsoft Exchange Server. Originalmente introduzido no Exchange Server 2010, o DAG garante que os serviços de email permaneçam operacionais mesmo em caso de falhas de servidor ou dados.
O que é um Grupo de Disponibilidade de Banco de Dados?
Um Grupo de Disponibilidade de Banco de Dados (DAG) é um grupo de até 16 servidores de caixa de correio que hospeda um conjunto de bancos de dados e fornece recuperação automática em nível de banco de dados de falhas que afetam servidores ou bancos de dados individuais. É o limite para replicação de banco de dados de caixa de correio, comutação de banco de dados e servidor, failover e um componente interno chamado Active Manager. O Active Manager é um componente do Exchange responsável por gerenciar as trocas e os failovers que são executados em cada servidor no DAG.
Qualquer servidor em um DAG pode hospedar cópias de bancos de dados de caixas postais de qualquer outro servidor no DAG. Quando um servidor é adicionado a um DAG, ele coopera com outros servidores no DAG para fornecer recuperação automática de falhas que afetam os bancos de dados de caixas postais, como falhas de disco ou servidor.
Conceitos Relacionados a um DAG
1. Papel do Servidor de Caixa de Correio
Um papel de MBX empresarial pode ter até 100 bancos de dados do Exchange e gerencia os modos ativo e passivo das operações de banco de dados. Sejam usados os termos "membro do DAG" "servidor DAG" ou "servidor membro do DAG" de forma intercambiável na documentação relacionada ao DAG da Microsoft eles se referem a servidores de caixa de correio MBX adicionados a um grupo DAG.
2. Ativo / Passivo
Em um DAG, um banco de dados só pode ser servido por um único papel de servidor MBX para acesso de banco de dados do cliente e esse servidor é chamado de ativo (com o estado do seu banco de dados montado).
Um servidor que não fornece acesso ao cliente, mas pode assumir o controle quando o banco de dados ativo falha para continuar oferecendo acesso ao banco de dados do cliente é chamado de passivo (este estado do banco de dados está desmontado e é exibido como "healthy" no campo de status de replicação).
3. Gerente Ativo
Quando o papel ativo do servidor MBX falha, o Gerenciador Ativo Primário (PAM) gerencia e seleciona a cópia do banco de dados a ser ativada. O Gerenciador Ativo é um componente introduzido no Exchange Server 2010, substituindo as funções tradicionais de gerenciamento de recursos de cluster e failover. Embora o Exchange Server 2010 não seja mais uma aplicação de cluster, a DAG ainda usa os serviços de cluster do Windows, mas não emprega mais grupos de cluster do Windows ou módulos de recursos de armazenamento, em vez disso, usa o Gerenciador Ativo para gerenciar o estado dos bancos de dados de caixas postais, incluindo estados ativos e passivos, operações de movimentação e estados montados.
Mecanismo DAG
O Exchange DAG utiliza clusters de failover do Windows Server. Os clusters de failover usam um mecanismo de quorum baseado em votação dos nós do cluster para determinar o Proprietário do Cluster. O quorum é um mecanismo compartilhado entre todos os membros do cluster, onde cada membro lê regularmente arquivos no quorum para determinar o status dos membros do cluster. Cada membro no cluster é considerado um voto.
O Exchange DAG usa o modo de Conjunto de Nós Maioritário. Neste modo, o Failover Cluster requer um servidor quórum externo aos membros do cluster. Este servidor quórum emite um voto ponderado para um membro específico do cluster, concedendo a esse nó privilégios de Proprietário do Cluster. No modo de Conjunto de Nós Maioritário, 50% dos votos dos nós devem estar online. Se N é o número de nós, então N/2+1 nós devem estar ativos.
Por exemplo:
1. Quando há 4 membros do DAG, o cálculo de votos é: N/2+1 = 3, permitindo a perda de 2 votos (o que significa que até dois nós podem falhar, com um voto vindo do serviço de quorum, portanto, apenas dois podem ser perdidos). Se mais de dois nós falharem, o cluster DAG perde o quorum, causando a desmontagem de todos os bancos de dados, exigindo intervenção do administrador para restaurar a normalidade.
2. Quando há 5 membros do DAG, o cálculo de votos é: N/2+1 = 3, permitindo a perda de 3 votos (o que significa que até 2 nós podem falhar). Se mais de dois nós falharem, o cluster do DAG perde o quórum e todos os bancos de dados são desmontados, exigindo intervenção do administrador para restaurar a normalidade.
Instalar um DAG
Pré-requisitos para instalar um DAG
O serviço DNS deve estar em execução
O nome atribuído ao DAG não deve exceder 15 caracteres
Os nós devem ser conectados ao ambiente de domínio
Ambos os nós devem executar uma instalação típica do Exchange SP3
Instalar o recurso de clustering de failover
Servidores devem ter a mesma versão
Cada membro do DAG deve ter o mesmo número de redes
Os nós devem ter uma instalação típica do Exchange SP3
Notas
Os nós precisam ser configurados com duas placas de rede:
- Rede MAPI (para acesso do usuário)
- Rede de replicação (para batimento cardíaco)
O servidor testemunha deve ser adicionado ao domínio
O servidor testemunha deve ter duas ou mais partições
Uma partição é usada para armazenar dados de testemunha
As versões do servidor devem ser idênticas
Implantações mistas não são permitidas, pois adicionar membros pode causar erros
Criando um DAG
Definir permissões para o grupo Exchange Trusted Subsystem
Permitir que o servidor de testemunha gerencie a programação do DAG
Defina o endereço IP do cluster para o DAG
Adicione membros ao grupo DAG
Configure a rede DAG
Iniciar o serviço Microsoft Exchange Information Store
Verifique a criação bem-sucedida do DAG
Verificando a Troca de Banco de Dados
Criar uma caixa de correio
Excluir o arquivo de banco de dados de um usuário existente
Observe as mudanças no console
Testar o envio e recebimento de e-mails para garantir o funcionamento normal
Faça backup do seu Exchange Server
Vinchin Backup & Recovery oferece proteção confiável e de nível empresarial para o Microsoft Exchange, suportando backups em máquinas virtuais e servidores físicos para armazenamento local, remoto ou na nuvem, como Azure e Amazon S3. Ele apresenta backups incrementais contínuos, agendamento flexível e seleção granular de dados, garantindo proteção de dados eficiente e consistente. Com criptografia RSA para transferência de dados, criptografia AES 256 e controle de acesso baseado em funções, o Vinchin garante segurança de ponta a ponta. A transferência de dados de alta velocidade e políticas de limitação personalizáveis aumentam ainda mais a eficiência, enquanto uma console baseada na web simplifica a gestão centralizada de backups para Exchange Server 2013, 2016, 2019 e Exchange Online.
São apenas 4 etapas para fazer o backup do Exchange Server:
1. Selecione o objeto de backup.
2. Selecione o destino do backup.
3. Configure estratégias de backup.
4. Revise e envie o trabalho.
O Vinchin Backup & Recovery oferece um teste gratuito de 60 dias com acesso completo a todos os seus recursos avançados de backup e recuperação. Clique no botão abaixo para explorar suas robustas funcionalidades.
Grupo de Disponibilidade de Banco de Dados Perguntas Frequentes
1. P: Como um servidor testemunha é usado em um DAG?
A: O servidor testemunha é usado para manter o quórum em configurações de DAG com um número par de membros. Ele ajuda a garantir que a regra da maioria seja atendida ao determinar se o DAG pode permanecer online.
2. P: Como é realizada a replicação de banco de dados em um DAG?
A: O Exchange usa a tecnologia de replicação contínua para copiar alterações do banco de dados ativo para cópias passivas. Isso garante a consistência e alta disponibilidade dos dados.
Conclusão
A implementação de um Grupo de Disponibilidade de Banco de Dados transforma um ambiente do Exchange Server em uma solução resiliente capaz de minimizar o tempo de inatividade e manter um serviço contínuo para os usuários. Ao aproveitar o failover automático e a replicação inteligente de bancos de dados, as empresas ganham tranquilidade de que serviços de email críticos podem resistir a falhas inesperadas. Garantir a configuração correta e o cumprimento das melhores práticas é essencial para maximizar os benefícios dos DAGs, permitindo que você se concentre no crescimento enquanto mantém a estabilidade operacional.
