Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
APLICA-SE A:
2016 2019 Subscription Edition
Microsoft Exchange Server utiliza o conceito conhecido como implementação incremental para elevada disponibilidade e resiliência do site. Instale dois ou mais servidores da Caixa de Correio do Exchange como servidores autónomos e, em seguida, configure-os incrementalmente e bases de dados de caixa de correio para elevada disponibilidade e resiliência do site, conforme necessário.
Visão geral do processo de implantação
Embora os passos reais utilizados por cada organização possam variar ligeiramente, o processo geral para implementar Exchange Server numa configuração altamente disponível ou resiliente ao site é geralmente o mesmo. Depois de realizar as tarefas de planejamento e design para a criação e a implantação de um grupo de disponibilidade de banco de dados (DAG) e a criação de cópias de banco de dados de caixa de correio, você poderá:
Criar um DAG. Para obter os passos detalhados, veja Criar um grupo de disponibilidade de base de dados. É importante ter em atenção que todos os servidores num DAG têm de estar a executar a mesma versão do Exchange. Por exemplo, não pode misturar servidores do Exchange 2013 e Exchange 2016 no mesmo DAG.
Se necessário, configure previamente o objeto de nome de cluster (CNO). A preparação prévia do CNO é necessária na implantação de um DAG com servidores de Caixa de Correio que executam o Windows Server 2012. Se estiver a implementar um DAG sem um ponto de acesso administrativo através de servidores de Caixa de Correio em execução Windows Server 2012 R2, não precisa de pré-preparar um CNO. Essa configuração prévia também é necessária em ambientes em que a criação da conta do computador é restrita ou em que as contas do computador são criadas em um contêiner que não seja o contêiner padrão do computador. Para obter etapas detalhadas, consulte Preparar o objeto de nome de cluster de um grupo de disponibilidade do banco de dados.
Adicionar dois ou mais servidores de caixa de correio ao DAG. Para obter os passos detalhados, veja Gerir a associação ao grupo de disponibilidade da base de dados.
Configurar as propriedades do DAG conforme a necessidade:
Uma opção é configurar a criptografia e a compactação do DAG, a porta de replicação, os endereços IP do DAG e outras propriedades do DAG. Para instruções detalhadas, consulte Configurar as propriedades do grupo de disponibilidade do banco de dados.
Habilitar o modo Coordenação de Ativação de Datacenter (DAC) para o DAG. Esta ação tem os seguintes benefícios:
- Protege o DAG de condições cerebrais divididas ao nível da base de dados durante a mudança para o datacenter primário após uma ativação do datacenter.
- Permite a utilização dos cmdlets de recuperação DAG incorporados.
Para mais informações, consulte Modo coordenação de ativação de Datacenter.
Adicionar cópias de banco de dados de caixa de correio entre servidores de caixa de correio no DAG. Para instruções detalhadas, consulte Adicionar uma cópia do banco de dados de caixa de correio.
Exemplo de implantação: DAG de quatro membros em dois data centers
Este exemplo detalha como a Contoso, Ltd. está a configurar e implementar um DAG de quatro membros expandido em duas localizações físicas: Boston e Oklahoma City.
Infraestrutura de base
Cada localização contém os elementos de infraestrutura necessários para operar uma infraestrutura de mensagens com base em Exchange Server, nomeadamente:
Serviços de diretório (Active Directory ou Serviços de Domínio do Active Directory Domain Services (AD DS))
Resolução de nomes DNS
Vários servidores exchange a executar serviços de Acesso de Cliente
Vários servidores da Caixa de Correio do Exchange
A figura a seguir ilustra a configuração da Contoso.
Configuração da rede
Como mostra a figura anterior, a solução envolve o uso de várias redes e sub-redes. Cada servidor de Caixa de Correio no DAG tem dois adaptadores de rede em sub-redes separadas. Em cada servidor de Caixa de Correio, é utilizado um adaptador de rede para a rede MAPI (192.168). x. x) e é utilizado um adaptador de rede para a rede de Replicação (10.0. x. x). Apenas a rede MAPI fornece conectividade ao Active Directory, serviços DNS, outros servidores exchange e clientes. O adaptador usado para a rede de Replicação em cada membro oferece conectividade apenas para adaptadores de rede de Replicação em outros membros do DAG.
As configurações de cada adaptador de rede de cada nó são detalhadas na tabela a seguir.
| Nome | Endereço IPv4 | Máscara de sub-rede | Gateway padrão |
|---|---|---|---|
| MBX1 (MAPI) | 192.168.1.4 | 255.255.255.0 | 192.168.1.1 |
| MBX2 (MAPI) | 192.168.1.5 | 255.255.255.0 | 192.168.1.1 |
| MBX3 (MAPI) | 192.168.2.4 | 255.255.255.0 | 192.168.2.1 |
| MBX4 (MAPI) | 192.168.2.5 | 255.255.255.0 | 192.168.2.1 |
| MBX1 (replicação) | 10.0.1.4 | 255.255.255.0 | Nenhum |
| MBX2 (replicação) | 10.0.1.5 | 255.255.255.0 | Nenhum |
| MBX3 (replicação) | 10.0.2.4 | 255.255.255.0 | Nenhum |
| MBX4 (replicação) | 10.0.2.5 | 255.255.255.0 | Nenhum |
Como mostra a tabela anterior, os adaptadores usados para redes de Replicação não usam gateways-padrão. Para proporcionar conectividade de rede entre cada adaptador de rede de Replicação, a Contoso usa rotas estáticas persistentes, que eles configuram usando a ferramenta Netsh.exe.
Para configurar o roteamento para os adaptadores de rede de Replicação em MBX1 e MBX2, o comando a seguir foi executado em cada servidor.
netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254
Para configurar o roteamento para os adaptadores de rede de Replicação em MBX3 e MBX4, o comando a seguir foi executado em cada servidor.
netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254
As seguintes definições de rede também estão configuradas:
A caixa de seleção Registrar os endereços desta conexão no DNS está marcada para cada adaptador de rede MAPI do membro do DAG e desmarcada para cada adaptador de rede de Replicação.
Ao menos um endereço de servidor DNS está configurado para cada adaptador de rede MAPI do membro do DAG, e nenhum está configurado para os adaptadores de rede de Replicação. Para redundância, a Contoso está usando vários endereços de servidores DNS para seus adaptadores de rede MAPI.
A Contoso não utiliza a Firewall do Windows, pelo que a desativou nos respetivos servidores.
Depois de configurar os adaptadores de rede, a Contoso está pronta para criar um DAG e adicionar os servidores da Caixa de Correio ao DAG.
Criação e configuração do grupo de disponibilidade de banco de dados
O administrador decidiu criar um Windows PowerShell script de interface de linha de comandos que executa várias tarefas:
Ele usa o cmdlet New-DatabaseAvailabilityGroup para criar o DAG. Uma vez que BOSTON é considerado o datacenter principal, a Contoso optou por utilizar um servidor de testemunhos no mesmo datacenter, nomeadamente MBX5.
Ele usa o cmdlet Set-DatabaseAvailabilityGroup para pré-configurar um servidor testemunha alternativo e um diretório testemunha alternativo para o caso de uma alternância de datacenter ser necessária.
Ele usa o cmdlet Add-DatabaseAvailabilityGroupServer para adicionar cada um dos quatro servidores de caixa de correio ao DAG.
Ele usa o cmdlet Set-DatabaseAvailabilityGroup para configurar o DAG para modo DAC. Para mais informações sobre o modo DAC, consulte Modo coordenação de ativação de Datacenter.
Os seguintes comandos são usados no script:
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer MBX5 -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8
O comando anterior cria o DAG DAG1, configura o MBX5 para funcionar como o servidor de testemunhos, configura um diretório de testemunhos específico (C:\DAGWitness\DAG1.contoso.com) e configura dois endereços IP para o DAG (um para cada sub-rede na rede MAPI).
Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer MBX10
O comando anterior configura DAG1 com as seguintes definições:
- Utilize MBX10 como um servidor de testemunhos alternativo.
- Utilize um diretório de testemunho alternativo em MBX10 com o mesmo caminho que MBX5.
Dica
Não é necessário utilizar o mesmo caminho. A Contoso está a utilizar o mesmo caminho para uniformizar a respetiva configuração.
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX3
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX4
Os comandos anteriores efetuam as seguintes ações:
- Adicione cada um dos servidores da Caixa de Correio, um de cada vez, ao DAG.
- Instale o componente Clustering de Ativação Pós-falha do Windows em cada servidor de Caixa de Correio (se ainda não estiver instalado).
- Criar um cluster de ativação pós-falha.
- Associe cada servidor de Caixa de Correio ao cluster recém-criado.
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly
O comando anterior habilita o modo DAC para o DAG.
Bancos de dados de Caixas de Correio e cópias de bancos de dados de Caixas de Correio
Depois de criar o DAG e adicionar os servidores de Caixa de Correio ao DAG, a Contoso se prepara para criar bancos de dados de caixas de correio e cópias de bancos de dados de caixas de correio. Para atender ao critério de resistência a falhas, a Contoso pretende configurar cada banco de dados de caixa de correio com três cópias de banco de dados sem atraso e uma cópia de banco de dados com atraso. A cópia com atraso tem um atraso de repetição de registo configurado de três dias.
Essa configuração proporciona um total de quatro cópias para cada banco de dados (uma ativa, duas passivas sem atraso e outra passiva com atraso). A Contoso pretende ter quatro bancos de dados ativos por servidor. Por conseguinte, a solução Contoso contém 16 cópias totais da base de dados.
Como mostra a figura a seguir, a Contoso adotou uma abordagem equilibrada no layout de banco de dados.
Layout da cópia do banco de dados para a Contoso, Ltd
Cada servidor de caixa de correio hospeda uma cópia de banco de dados de caixa de correio ativa, duas cópias de banco de dados passivas sem atraso e uma cópia de banco de dados passiva com atraso. A cópia com atraso de cada banco de dados de caixa de correio ativo é hospedada em um servidor de caixa de correio no outro site.
Para criar essa configuração, o administrador executa vários comandos.
No MBX1, execute os seguintes comandos.
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -SuspendComment "Seed from MBX4" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX3 -SourceServer MBX4
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -ActivationOnly
No MBX2, execute os seguintes comandos.
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX4 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -SuspendComment "Seed from MBX3" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX4 -SourceServer MBX3
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -ActivationOnly
No MBX3, execute os seguintes comandos.
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -SuspendComment "Seed from MBX2" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1 -SourceServer MBX2
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -ActivationOnly
No MBX3, execute os seguintes comandos.
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -SuspendComment "Seed from MBX1" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2 -SourceServer MBX1
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -ActivationOnly
Nos exemplos de Add-MailboxDatabaseCopy anteriores, não utilizámos o parâmetro ActivationPreference , porque a tarefa incrementa automaticamente o número da preferência de ativação com cada cópia adicionada:
- O banco de dados original sempre tem um número de preferência igual a 1.
- É atribuído automaticamente um número de preferência de 2 à primeira cópia adicionada.
- Partindo do princípio de que não são removidas cópias, a próxima cópia adicionada é automaticamente atribuída a um número de preferência de 3 e assim sucessivamente.
Assim, nos exemplos de Add-MailboxDatabaseCopy anteriores:
- A cópia passiva no mesmo datacenter que a cópia ativa tem um número de preferência de ativação de 2.
- A cópia passiva não atrasada no datacenter remoto tem um número de preferência de ativação de 3.
- A cópia passiva com atraso no datacenter remoto tem um número de preferência de ativação de 4.
Embora haja duas cópias de cada banco de dados ativo ao longo da WAN no outro local, a propagação pela WAN só foi realizada uma vez. A Contoso utiliza a capacidade Exchange Server de utilizar uma cópia passiva de uma base de dados como origem para propagação.
- A utilização do cmdlet Add-MailboxDatabaseCopy com o parâmetro SeedingPostponed impede a tarefa de propagar automaticamente a nova cópia da base de dados.
- O administrador pode suspender a cópia não propagada.
- Ao utilizar o cmdlet Update-MailboxDatabaseCopy com o parâmetro SourceServer , o administrador pode especificar a cópia local da base de dados como a origem da operação de propagação.
Como resultado, a propagação da segunda cópia de banco de dados adicionada a cada localidade acontece localmente, e não através da WAN.
Observação
No exemplo anterior, a cópia da base de dados não atrasada é propagada através da WAN. Essa cópia é utilizada para propagar a cópia atrasada da base de dados no mesmo datacenter que a cópia não atrasada.
A Contoso configurou uma das cópias passivas de cada base de dados de caixa de correio como uma cópia de base de dados atrasada para fornecer proteção contra os casos extremamente raros, mas catastróficos, de danos lógicos na base de dados. Como resultado, o administrador está a configurar as cópias atrasadas como bloqueadas para ativação através do cmdlet Suspend-MailboxDatabaseCopy com o parâmetro ActivationOnly . Esta configuração garante que as cópias da base de dados com atraso não são ativadas se ocorrer uma ativação pós-falha da base de dados ou do servidor.
Validar a solução
Depois de a solução ser implementada e configurada, o administrador executa várias tarefas que validam a preparação da solução antes de mover caixas de correio de produção para as bases de dados no DAG. A solução deve ser testada e inspecionada usando diversos métodos, incluindo simulações de falha. Para validar a solução, o administrador executa várias tarefas.
Para verificar a integridade geral do DAG, o administrador executa o cmdlet Test-ReplicationHealth. Esse cmdlet verifica vários aspectos do status de replicação e de repetição para oferecer informações sobre cada cópia de banco de dados e servidor de caixa de correio no DAG.
Para verificar a atividade de replicação e repetição, o administrador executa o cmdlet Get-MailboxDatabaseCopyStatus. Esse cmdlet pode oferecer informações de status em tempo real sobre uma cópia de banco de dados de caixa de correio específica ou sobre todas as cópias de banco de dados de caixa de correio em um servidor específico. Para obter mais informações sobre como monitorizar o estado de funcionamento e status de bases de dados replicadas num DAG, veja Monitorizar grupos de disponibilidade de bases de dados.
Para verificar se as alternâncias ocorrem conforme o esperado, o administrador usa o cmdlet Move-ActiveMailboxDatabase para realizar uma série de alternâncias de bancos de dados e servidores. Quando estas tarefas são concluídas com êxito, o administrador utiliza o mesmo cmdlet para mover as cópias da base de dados ativas para as respetivas localizações originais.
Para verificar os comportamentos esperados em vários cenários de falha, o administrador realiza várias tarefas que simulam falhas ou que de fato causam as falhas. Por exemplo, o administrador pode:
Desligue o cabo de alimentação no MBX1, o que aciona uma ativação pós-falha do servidor. O administrador verifica se o DB1 se torna ativo em outro servidor (de preferência o MBX2, com base nos valores de preferência de ativação).
Desligue o cabo de rede do adaptador de rede MAPI no MBX2, o que aciona uma ativação pós-falha do servidor. O administrador verifica se o DB2 se torna ativo em outro servidor (de preferência o MBX1, com base nos valores de preferência de ativação).
Leve o disco utilizado pela cópia ativa da DB3 offline, o que aciona uma ativação pós-falha da base de dados. O administrador verifica se o DB3 se torna ativo em outro servidor (de preferência o MBX4, com base nos valores de preferência de ativação).
Uma organização pode testar outros cenários de falha, com base nas necessidades empresariais. Depois de simular uma única falha (como solicitar a ficha de alimentação) e verificar o comportamento de recuperação da solução, o administrador poderá reverter a solução novamente para a configuração original. Em alguns casos, a solução pode ser testada para várias falhas simultâneas. Em última análise, o plano de teste da solução determina se a solução é revertida para a configuração original após cada simulação de falha.
Além disso, um administrador pode decidir desligar a ligação de rede entre os dois datacenters, o que simula uma falha do site. A realização de uma alternância de datacenter é um processo muito mais complexo e coordenado; no entanto, recomendamos o processo se a solução que estiver sendo implantada tiver como objetivo proporcionar resiliência de site para os dados e serviços de mensagens.
Fazendo a transição para operações
Após a implementação da solução, esta pode ser expandida com a implementação incremental. Nesse ponto, o gerenciamento da solução também faria a transição para processos de operação, com a realização das seguintes tarefas:
Monitorar a integridade e o status de DAGs e cópias de banco de dados de caixa de correio. Para obter mais informações, veja Monitorizar grupos de disponibilidade de bases de dados.
Execute alternâncias de banco de dados conforme necessário. 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.
Para mais informações sobre o gerenciamento da solução, consulte Gerenciando a alta disponibilidade e resiliência do site.