Compartilhar via

Gerir grupos de disponibilidade de bases de dados no Exchange Server

APLICA-SE A:yes-img-162016 yes-img-192019 yes-img-seSubscription Edition

Um grupo de disponibilidade de base de dados (DAG) é um conjunto de até 16 servidores da Caixa de Correio do Exchange que fornecem uma recuperação automática ao nível da base de dados a partir de uma base de dados/servidor/falha de rede. Os DAGs utilizam replicação contínua e uma sub-rede de tecnologias de cluster de failover do Windows para fornecer alta disponibilidade e resiliência de site. Servidores de caixa de correio em um DAG monitoram-se por falhas. Quando um servidor de Caixa de Correio é adicionado a um DAG, esse servidor funciona com os outros servidores no DAG para fornecer uma recuperação automática ao nível da base de dados a partir de falhas da base de dados.

Quando criado, um DAG está vazio. Quando você 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 heartbeat do cluster de ativação pós-falha e a base de dados do cluster são utilizados para controlar e gerir informações sobre o DAG, que podem ser alteradas rapidamente, como a montagem da base de dados status, a replicação status e a última localização montada.

Criando DAGs

Pode criar um DAG com o assistente Novo Grupo de Disponibilidade de Base de Dados no Centro de administração do Exchange (EAC) ou ao executar o cmdlet New-DatabaseAvailabilityGroup na Shell de Gestão do Exchange. Quando cria um DAG, fornece um nome para o DAG e definições opcionais do servidor de testemunhos e do diretório de testemunhos. Além disso, atribua um ou mais endereços IP ao DAG, usando endereços IP estáticos ou permitindo que os endereços IP necessários sejam atribuídos automaticamente ao DAG, usando o protocolo DHCP. Pode atribuir manualmente endereços IP ao DAG com o parâmetro DatabaseAvailabilityGroupIpAddresses . Se você omitir esse parâmetro, o DAG tentará obter um endereço IP usando um servidor DHCP na rede.

Se estiver a criar um DAG que irá conter servidores de Caixa de Correio que estão a executar Windows Server 2012 R2, também tem a opção de criar um DAG sem um ponto de acesso administrativo do cluster. Nesse caso, o cluster não terá um objeto de nome de cluster (CNO) no Active Directory e o grupo de recursos principal do cluster não conterá um recurso de nome de rede ou um recurso de endereço IP.

Para obter passos detalhados sobre como criar um DAG, veja Criar um grupo de disponibilidade de base de dados.

Quando cria um DAG, um objeto vazio que representa o DAG com o nome que especificou e uma classe de objeto de msExchMDBAvailabilityGroup são criados no Active Directory.

Os DAGs utilizam um subconjunto de tecnologias de ativação pós-falha do Windows clustering no Windows Server 2008 R2 ou posterior, como o heartbeat do cluster, as redes de cluster e a base de dados de cluster (para armazenar dados que mudam ou podem ser alterados rapidamente, como alterações do estado da base de dados de ativo para passivo ou inverso, ou de montado para desmontado ou inverso). Por conseguinte, só pode criar DAGs em servidores da Caixa de Correio do Exchange instalados em versões suportadas do Windows que incluam a ativação pós-falha do Windows clustering.

Observação

O cluster de failover criado e usado pelo DAG deve ser dedicado ao DAG. O cluster não pode ser usado por nenhuma outra solução de alta disponibilidade ou para qualquer outra finalidade. Por exemplo, o cluster de failover não pode ser usado para armazenar em cluster outros aplicativos ou serviços. O uso do cluster de failover subjacente do DAG para finalidades que não sejam o DAG não tem suporte.

Servidor testemunha do DAG e diretório testemunha

Quando cria um DAG, tem de especificar um nome para o DAG com mais de 15 carateres exclusivos na floresta do Active Directory. Além disso, cada DAG é configurado com um servidor testemunha e um diretório testemunha. O servidor de testemunhos e o respetivo diretório são utilizados apenas quando existe um número par de membros no DAG e apenas para fins de quórum. Você não precisa criar o diretório testemunha com antecedência. O Exchange cria e protege automaticamente o diretório para você no servidor testemunha. O diretório de testemunhas não deve ser utilizado para qualquer finalidade que não seja para o servidor de testemunhos da DAG.

Observação

Na topologia de espelhamento da base de dados, pode ter um terceiro servidor chamado "testemunho". O servidor de testemunhos ativa a ativação pós-falha automática do principal para espelho servidor ou vice-versa. Ao contrário dos servidores principal e espelho, o servidor de testemunhos não serve a base de dados. A função do testemunho é verificar se um determinado servidor parceiro está a funcionar. Suportar a ativação pós-falha automática é a única função para o servidor testemunha e identifica qual o servidor que contém a cópia principal e qual o servidor que contém a cópia espelho da base de dados.

Os requisitos do servidor de testemunha são os seguintes:

  • O servidor testemunha não pode ser um membro do DAG.

  • O servidor testemunha deve estar na mesma floresta do Active Directory do DAG.

  • O servidor de testemunhas tem de estar em execução Windows Server 2008 ou posterior.

  • Um único servidor pode funcionar como testemunha para vários DAGs. Entretanto, cada DAG requer seu próprio diretório testemunha.

Independentemente do servidor utilizado como servidor testemunha, se a Firewall do Windows estiver ativada no servidor de testemunhos pretendido, tem de ativar a exceção da Firewall do Windows para Partilha de Ficheiros e Impressoras. O servidor de testemunhos utiliza a porta SMB 445.

Importante

Se o servidor de testemunhos que especificar não for um servidor do Exchange 2010 ou posterior, tem de adicionar o grupo de segurança universal (USG) do Subsistema Fidedigno do Exchange ao grupo de Administradores local no servidor de testemunhos antes de criar o DAG. Essas permissões de segurança são necessárias para assegurar que o Exchange possa criar um diretório e compartilhar o servidor testemunha conforme necessário.

Nem o servidor testemunha nem o diretório testemunha precisa ser tolerante a falhas ou usar uma forma de redundância ou de alta disponibilidade. Não há nenhuma necessidade de usar um servidor de arquivo em cluster para o servidor testemunha ou empregar qualquer outra forma de resiliência para o servidor testemunha. Há várias razões para isso. Com DAGs maiores (por exemplo, seis membros ou mais), várias falhas são necessárias para que haja a necessidade do servidor testemunha. Como um DAG com seis membros podem tolerar até duas falhas de votante sem perder quorum, seriam necessários até três votantes com falha para que o servidor testemunha fosse exigido a fim de manter um quórum. Além disso, se houver uma falha que afete o servidor testemunha atual (por exemplo, você perde o servidor testemunha por conta de uma falha de hardware), será possível usar o cmdlet Set-DatabaseAvailabilityGroup para configurar um novo servidor testemunha e um diretório testemunha (desde que você tenha um quórum).

Observação

Também será possível usar o cmdlet Set-DatabaseAvailabilityGroup para configurar o servidor testemunha e o diretório testemunha no local original, se o servidor testemunha tiver perdido seu armazenamento ou se alguém tiver alterado o diretório testemunha ou as permissões de compartilhamento.

Considerações colocação servidor testemunha

O posicionamento de um servidor testemunha do DAG dependerá dos seus requisitos de negócios e das opções disponíveis na organização. O Exchange inclui agora suporte para novas opções de configuração da DAG que não são recomendadas ou não são possíveis no Exchange 2010. Estas opções incluem a utilização de uma terceira localização, como um terceiro datacenter, uma sucursal ou uma rede virtual do Microsoft Azure.

A tabela a seguir lista recomendações de posicionamento de servidor testemunha gerais para diferentes cenários de implantação.

Cenário de implantação Recomendações
Único DAG implantado em um único datacenter Localize servidor testemunha no mesmo datacenter como membros do DAG
Único DAG implantado em dois datacenters; há locais adicionais disponíveis Localize o servidor de testemunhos numa rede virtual do Microsoft Azure para ativar a ativação pós-falha automática do datacenter ou

Localizar o servidor testemunha no datacenter primário
Vários DAGs implantado em um único datacenter Localize servidor testemunha no mesmo datacenter como membros do DAG. As opções adicionais incluem:
  • Usando o mesmo servidor testemunha para vários DAGs
  • Usando um membro do DAG para agir como um servidor de testemunha para um DAG diferente
Vários DAGs implantado em dois datacenters Localize o servidor de testemunhos numa rede virtual do Microsoft Azure para ativar a ativação pós-falha automática do datacenter ou

Localizar o servidor testemunha no datacenter, que é considerada primária para cada DAG. As opções adicionais incluem:

  • Usando o mesmo servidor testemunha para vários DAGs
  • Usando um membro do DAG para agir como um servidor de testemunha para um DAG diferente
DAGs única ou múltipla implantado em mais de dois datacenters Nesta configuração, o servidor testemunha deve estar localizado no datacenter onde deseja que a maioria dos votos de quorum de existir.

Quando um DAG tiver sido implementado em dois datacenters, agora pode utilizar uma terceira localização para alojar o servidor de testemunhos. Se a sua organização tiver uma terceira localização com uma infraestrutura de rede isolada de falhas de rede que afetam os dois datacenters nos quais o DAG é implementado, pode implementar o servidor de testemunhos do DAG nessa terceira localização, configurando assim o DAG com a capacidade de realizar automaticamente a ativação pós-falha de bases de dados para o outro datacenter em resposta a um evento de falha ao nível do datacenter. Se a sua organização tiver apenas duas localizações físicas, pode utilizar uma rede virtual do Microsoft Azure como uma terceira localização para colocar o servidor de testemunhos.

Especificar um servidor testemunha e um diretório testemunha durante a criação do DAG

Quando cria um DAG, tem de indicar um nome para o DAG. Também é possível especificar um servidor e um diretório testemunha.

Quando cria um DAG, estão disponíveis as seguintes combinações de opções e comportamentos:

  • É possível especificar apenas um nome para o DAG e deixar os campos Servidor testemunha e Diretório testemunha em branco. Neste cenário, o assistente procura no site local do Active Directory um servidor de Acesso de Cliente que não tenha o servidor da Caixa de Correio instalado e cria automaticamente o diretório predefinido (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN) e partilha predefinida (<DAGFQDN>>) nesse servidor e utiliza esse servidor de Acesso de Cliente como servidor testemunha. Por exemplo, considere o servidor de testemunhos CAS3 no qual o sistema operativo foi instalado na unidade C. Um DAG com o nome DAG1 no domínio contoso.com utilizaria um diretório de testemunhas predefinido de C:\DAGFileShareWitnesses\DAG1.contoso.com, que seria partilhado como \CAS3\DAG1.contoso.com.

  • É possível especificar um nome para o DAG, o servidor testemunha que você deseja usar e o diretório que você deseja criar e compartilhar no servidor testemunha.

  • É possível especificar um nome para o DAG e o servidor testemunha que deseja usar, além de deixar o campo Diretório testemunha em branco. Nesse cenário, o assistente cria o diretório padrão no servidor testemunha especificado.

  • É possível especificar um nome para o DAG e deixar o campo Servidor testemunha em branco, além de especificar o diretório que você deseja criar e compartilhar no servidor testemunha. Nesse cenário, o assistente procura um servidor de Acesso para Cliente que não tenha o servidor de Caixa de Correio instalado e cria automaticamente o DAG especificado nesse servidor, compartilha o diretório e usa o servidor de Acesso para Cliente como o servidor testemunha.

Quando um DAG for formado, ele usará inicialmente o modelo de quórum Maioria dos Nós. Quando o segundo servidor de Caixa de Correio for adicionado ao DAG, o quorum será alterado automaticamente para um modelo de quorum Maioria dos Nós e Compartilhamentos de Arquivos. Quando essa alteração ocorrer, o cluster do DAG começará a usar o servidor testemunha para manter quorum. Se o diretório testemunha não existir, ele será automaticamente criado e compartilhado pelo Exchange, que fornecerá o compartilhamento com permissões de controle total para a conta de computador do CNO do DAG.

Observação

Não é possível usar compartilhamento de arquivos que seja parte de um namespace do sistema de arquivos distribuído.

Se o firewall do Windows estiver habilitado no servidor testemunha antes de o DAG ser criado, ele poderá bloquear a criação do DAG. O Exchange usa a Instrumentação de Gerenciamento do Windows (WMI) para criar o diretório e o compartilhamento de arquivo no servidor testemunha. Se o firewall do Windows estiver habilitado no servidor testemunha e não houver nenhuma exceção de firewall configurada para a WMI, o cmdlet New-DatabaseAvailabilityGroup falhará com um erro. Se especificar um servidor de testemunhos, mas não um diretório de testemunhas, receberá a seguinte mensagem de erro:

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

Se especificar um servidor de testemunhos e um diretório de testemunhos, receberá a seguinte mensagem de aviso:

Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

Se o firewall do Windows estiver habilitado no servidor testemunha após a criação do DAG, mas antes de os servidores serem adicionados, ele poderá bloquear a adição ou remoção de membros do DAG. Se a Firewall do Windows estiver ativada no servidor de testemunhos e não existirem exceções de firewall configuradas para o WMI, o cmdlet Add-DatabaseAvailabilityGroupServer apresenta a seguinte mensagem de aviso:

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Para resolve os erros e avisos anteriores, siga um dos seguintes passos:

  • Crie manualmente o diretório testemunha e compartilhe o servidor testemunha e atribua ao CNO do DAG total controle para o diretório e o compartilhamento.

  • Habilite a exceção WMI no firewall do Windows.

  • Desabilite o firewall do Windows.

Associação ao DAG

Após a criação de um DAG, pode adicionar ou remover servidores do DAG com o assistente Gerir Grupo de Disponibilidade da Base de Dados no EAC ou os cmdlets Add-DatabaseAvailabilityGroupServer ou Remove-DatabaseAvailabilityGroupServer na Shell de Gestão do Exchange. Para obter passos detalhados sobre como gerir a associação da DAG, veja Gerir a associação ao grupo de disponibilidade da base de dados.

Observação

Cada servidor de Caixa de Correio membro de um DAG também é um nó no cluster subjacente usado pelo DAG. Como resultado, a qualquer momento, um servidor de Caixa de Correio pode ser membro de apenas um DAG.

Se o servidor de Caixa de Correio adicionado a um DAG não tiver o componente de cluster de failover instalado, o método usado para adicionar o servidor (por exemplo, o cmdlet Add-DatabaseAvailabilityGroupServer ou o assistente para Gerenciar Grupo de Disponibilidade de Banco de Dados) instalará o recurso de clustering de failover.

Quando o primeiro servidor da Caixa de Correio é adicionado a um DAG, ocorrem os seguintes eventos:

  • O componente de clustering de failover do Windows será instalado, se ainda não estiver.

  • Um cluster de failover é criado usando-se o nome do DAG. Esse cluster de failover é usado exclusivamente pelo DAG e deve ser dedicado ao DAG. O uso do cluster para qualquer outra finalidade não tem suporte.

  • Um CNO é criado no contêiner de computadores padrão.

  • O nome e o endereço IP do DAG é registrado como um Host (A) no DNS.

  • O servidor é adicionado ao objeto do DAG no Active Directory.

  • O banco de dados clusterizado é atualizado com informações sobre os bancos de dados montados no servidor adicionado.

Em um ambiente grande ou com vários locais, especialmente aqueles em que o DAG é estendido a vários locais de Active Directory, é preciso aguardar a replicação de Active Directory do objeto do DAG que contém o primeiro membro do DAG a ser concluído. Se este objeto do Active Directory não for replicado em todo o ambiente, adicionar o segundo servidor poderá fazer com que seja criado um novo cluster (e um novo CNO) para o DAG. Esta criação deve-se ao facto de o objeto DAG aparecer vazio na perspetiva do segundo membro a ser adicionado, fazendo com que o cmdlet Add-DatabaseAvailabilityGroupServer crie um cluster e um CNO para o DAG, mesmo que estes objetos já existam. Para verificar se o objeto do DAG que tem o primeiro servidor do DAG foi replicado, use o cmdlet Get-DatabaseAvailabilityGroup no segundo servidor sendo adicionado para verificar se o primeiro servidor adicionado está listado como membro do DAG.

Quando o segundo servidor e os servidores subsequentes são adicionados ao DAG, ocorrem os seguintes eventos:

  • O servidor é adicionado ao cluster de failover do Windows para o DAG.

  • O modelo de quorum é ajustado automaticamente:

    • Um modelo de quorum Maioria dos Nós é usado para DAGs com um número ímpar de membros.

    • Um modelo de quorum Maioria dos Nós e Compartilhamentos de Arquivos é usado para DAGs com um número par de membros.

  • O diretório testemunha e o compartilhamento são criados automaticamente pelo Exchange quando necessário.

  • O servidor é adicionado ao objeto do DAG no Active Directory.

  • O banco de dados clusterizado é atualizado com informações sobre bancos de dados montados.

Observação

A alteração feita no modelo de quorum deve acontecer automaticamente. No entanto, se o modelo de quórum não mudar automaticamente para o modelo adequado, pode executar o cmdlet Set-DatabaseAvailabilityGroup apenas com o parâmetro Identity para corrigir nas definições de quórum do DAG.

Pré-preparo do objeto nome do cluster para um DAG

O CNO é uma conta de computador criada no Active Directory e associada ao recurso de nome do cluster. Esse recurso está vinculado ao CNO, que é um objeto habilitado para Kerberos que atua como a identidade do cluster e fornece o contexto de segurança do cluster. A formação do cluster subjacente do DAG e do CNO para esse cluster é feita quando o primeiro membro é adicionado ao DAG. Quando o primeiro servidor for adicionado ao DAG, o Powershell remoto entra em contato com o Serviço de Replicação do Microsoft Exchange no servidor de Caixa de Correio sendo adicionado. O serviço de Replicação do Microsoft Exchange instala o recurso cluster de failover (se ele ainda não estiver instalado) e inicia o processo de criação do cluster. O Serviço de Replicação do Microsoft Exchange é executado no contexto de segurança de LOCAL SYSTEM e está sob esse contexto em que a criação do cluster é feita.

Cuidado

Caso os membros do DAG estejam executando o Windows Server 2012, você deverá preparar o CNO antes de adicionar o primeiro servidor ao DAG. Se os membros do DAG estiverem a executar Windows Server 2012 R2 e criar um DAG sem um ponto de acesso administrativo do cluster, não será criado um CNO e não terá de criar um CNO para o DAG.

Nos ambientes em que a criação de conta de computador é restrita ou as contas de computador são criadas em um contêiner que não seja o de computadores padrão, você pode preparar e fornecer o CNO. Crie e desative uma conta de computador para o CNO e, em seguida, siga um dos seguintes passos:

  • Atribua controle total da conta do computador à conta do computador do primeiro servidor de Caixa de Correio sendo adicionado ao DAG.

  • Atribua controle total da conta do computador ao USG do Subsistema Confiável do Exchange.

Atribuir controle total da conta do computador à conta do computador do primeiro servidor de Caixa de Correio sendo adicionado ao DAG assegura que o contexto de segurança de LOCAL SYSTEM possa gerenciar a conta de computador preparada. A atribuição de controle total da conta de computador ao USG do Subsistema Confiável do Exchange pode ser usada porque o USG do Subsistema Confiável do Exchange tem as contas de máquina de todos os servidores Exchange do domínio.

Para obter as etapas detalhadas sobre como preparar e fornecer o CNO de um DAG, consulte Preparar o objeto de nome de cluster de um grupo de disponibilidade do banco de dados.

Remover servidores de um DAG

Os servidores de caixa de correio podem ser removidos de um DAG através do assistente Gerir Grupo de Disponibilidade da Base de Dados no EAC ou no cmdlet Remove-DatabaseAvailabilityGroupServer na Shell de Gestão do Exchange. Para que um servidor de Caixa de Correio possa ser removido de um DAG, todos os bancos de dados de caixa de correio replicados devem ser primeiramente removidos do servidor. Se você tentar remover um servidor de Caixa de Correio com bancos de dados de caixa de correio de um DAG, haverá falha na tarefa.

Há cenários nos quais você deve remover um servidor de Caixa de Correio de um DAG antes de realizar determinadas operações. Esses cenários incluem:

  • Executar uma operação de recuperação do servidor: se um servidor de Caixa de Correio que seja membro de um DAG for perdido ou falhar e não for recuperável e precisar de substituição, pode executar uma operação de recuperação do servidor com o comutador Setup /m:RecoverServer . No entanto, antes de poder executar a operação de recuperação, primeiro tem de remover o servidor do DAG com o cmdlet Remove-DatabaseAvailabilityGroupServer com o parâmetro ConfigurationOnly .

  • Remover o grupo de disponibilidade da base de dados: podem existir situações em que tem de remover um DAG (por exemplo, ao desativar o modo de replicação de terceiros). Se precisar remover um DAG, você deverá remover primeiro todos os servidores do DAG. Se você tentar remover um DAG que contenha algum membro, haverá falha na tarefa.

Configurar propriedades do DAG

Depois de os servidores terem sido adicionados ao DAG, pode utilizar o EAC ou a Shell de Gestão do Exchange para configurar as propriedades de um DAG, incluindo o servidor de testemunhos e o diretório de testemunhos utilizado pelo DAG e os endereços IP atribuídos ao DAG.

As propriedades configuráveis incluem:

  • Servidor de testemunhos: o nome do servidor que pretende alojar a partilha de ficheiros do testemunho de partilha de ficheiros. Recomendamos que você especifique um servidor de Acesso para Cliente como o servidor testemunha. Esta nomenclatura permite ao sistema configurar, proteger e utilizar automaticamente a partilha, conforme necessário, e permite que o administrador de mensagens esteja ciente da disponibilidade do servidor de testemunhos.

  • Diretório de testemunhas: o nome de um diretório que será utilizado para armazenar dados de testemunho de partilha de ficheiros. Esse diretório será criado automaticamente pelo sistema no servidor testemunha especificado.

  • Endereços IP do grupo de disponibilidade da base de dados: um ou mais endereços IP têm de ser atribuídos ao DAG, a menos que os membros do DAG estejam a executar Windows Server 2012 R2 e esteja a criar um DAG sem um endereço IP. Caso contrário, os endereços IP do DAG podem ser configurados com endereços IP estáticos atribuídos manualmente ou podem ser atribuídos automaticamente ao DAG com um servidor DHCP na organização.

A Shell de Gestão do Exchange permite-lhe configurar propriedades DAG que não estão disponíveis no EAC, como endereços IP DAG; definições de encriptação e compressão de rede; deteção de rede; a porta TCP utilizada para replicação; e definições alternativas do servidor de testemunhos e do diretório de testemunhos; e para ativar Datacenter modo de Coordenação de Ativação.

Para obter etapas detalhadas sobre como configurar as propriedades do DAG, consulte Configurar as propriedades do grupo de disponibilidade do banco de dados.

Criptografia de rede do DAG

Os DAGs dão suporte ao uso da criptografia aproveitando os recursos de criptografia do sistema operacional Windows Server. DAGs usam a autenticação Kerberos entre servidores do Exchange. As APIs EncryptMessage e DecryptMessage do provedor de suporte de segurança (SSP) Microsoft Kerberos lidam com a criptografia do tráfego de rede do DAG. O SSP do Microsoft Kerberos dá suporte a vários algoritmos de criptografia. (Para obter a lista completa, consulte a secção 3.1.5.2, "Tipos de Encriptação" das Extensões de Protocolo Kerberos.) O handshake de autenticação Kerberos seleciona o protocolo de encriptação mais forte suportado na lista: normalmente, Encriptação Avançada Standard (AES) de 256 bits, potencialmente com um Código de Autenticação de Mensagens (HMAC) baseado em Hash SHA para manter a integridade dos dados. Para obter mais informações, veja HMAC.

A encriptação de rede é uma propriedade do DAG e não da rede DAG. Pode configurar a encriptação de rede DAG com o cmdlet Set-DatabaseAvailabilityGroup na Shell de Gestão do Exchange. As definições de encriptação possíveis para comunicações de rede DAG são apresentadas na tabela seguinte:

Configuração Descrição
Desabilitado A criptografia de rede não é usada.
Habilitado A criptografia de rede é usada em todas as redes do DAG para replicação e propagação.
InterSubnetOnly A criptografia de rede é usada em redes do DAG durante a replicação em sub-redes diferentes. Esta definição é a predefinição.
SeedOnly A criptografia de rede é usada em todas as redes do DAG apenas para propagação.

Compactação de rede do DAG

Os DAGs dão suporte à compactação interna. Quando a compactação for habilitada, a comunicação de rede do DAG usará XPRESS, que é a implementação da Microsoft do algoritmo LZ77. Esta compressão é o mesmo tipo de compressão utilizada em muitos protocolos da Microsoft, em particular, compressão MAPI RPC entre o Microsoft Outlook e o Exchange.

Tal como acontece com a encriptação de rede, a compressão de rede também é uma propriedade do DAG e não da rede DAG. Pode configurar a compressão de rede DAG com o cmdlet Set-DatabaseAvailabilityGroup na Shell de Gestão do Exchange. As possíveis definições de compressão para comunicações de rede DAG são apresentadas na tabela seguinte:

Configuração Descrição
Desabilitado A compactação de rede não é usada.
Habilitado A compactação de rede é usada em todas as redes do DAG para replicação e propagação.
InterSubnetOnly A compactação de rede é usada em redes do DAG durante a replicação em sub-redes diferentes. Esta definição é a predefinição.
SeedOnly A compactação de rede é usada em todas as redes do DAG apenas para propagação.

Redes do DAG

Uma rede do DAG é uma coleção de uma ou mais sub-redes usadas para tráfego de replicação ou tráfego MAPI. Cada DAG contém um máximo de uma rede MAPI e zero ou mais redes de replicação. Em uma configuração de adaptador de rede único, a rede é usada para MAPI e tráfego de replicação. Embora haja suporte a um único adaptador de rede e um caminho, recomendamos que cada DAG tenha pelo menos duas redes do DAG. Em uma configuração com duas redes, uma rede costuma ser dedicada ao tráfego de replicação e a outra rede é usada essencialmente para o tráfego MAPI. Você pode também adicionar adaptadores de rede a cada membro do DAG e configurar redes de DAG adicionais como redes de replicação.

Observação

Ao usar várias redes de replicação, não há qualquer maneira de especificar uma ordem de precedência para o uso das redes. O Exchange seleciona aleatoriamente uma rede de replicação, no grupo de redes de replicação, para usá-la para envio de logs.

No Exchange 2010, a configuração manual de redes DAG era necessária em muitos casos. Por predefinição, nas versões posteriores do Exchange, as redes DAG são configuradas automaticamente pelo sistema. Antes de criar ou modificar redes DAG, você deve primeiro habilitar o controle manual de redes DAG executando este comando:

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

Depois de ativar a configuração manual da rede DAG, pode utilizar o cmdlet New-DatabaseAvailabilityGroupNetwork na Shell de Gestão do Exchange para criar uma rede DAG. Para instruções detalhadas sobre como criar uma rede DAG, consulte Criar uma rede de grupo de disponibilidade do banco de dados.

Pode utilizar o cmdlet Set-DatabaseAvailabilityGroupNetwork na Shell de Gestão do Exchange para configurar as propriedades de rede DAG. Para obter etapas detalhadas sobre como configurar as propriedades de rede do DAG, consulte Configurar propriedades de rede do grupo de disponibilidade de banco de dados. Cada rede do DAG exigiu parâmetros opcionais a serem configurados:

  • Nome da rede: um nome exclusivo para a rede DAG com até 128 carateres.

  • Descrição da rede: uma descrição opcional para a rede DAG com até 256 carateres.

  • Sub-redes de rede: uma ou mais sub-redes introduzidas com um formato de sub-redes IPAddress/Máscara de Bits (por exemplo, 192.168.1.0/24 para sub-redes IPv4 (Versão IPv4) do Protocolo Internet; 2001:DB8:0:C000::/64 para sub-redes da versão 6 (IPv6) do Protocolo Internet).

  • Ativar replicação: no EAC, selecione a caixa de verificação para dedicar a rede DAG ao tráfego de replicação e bloquear o tráfego MAPI. Desmarque a caixa de verificação para impedir que a replicação utilize a rede DAG e para ativar o tráfego MAPI. Na Shell de Gestão do Exchange, utilize o parâmetro ReplicationEnabled no cmdlet Set-DatabaseAvailabilityGroupNetwork para ativar e desativar a replicação.

Observação

Desabilitar a replicação na rede MAPI não garante que o sistema não usará essa rede na replicação. Quando todas as redes de replicação configuradas estiverem offline, tiverem falhado ou estiverem indisponíveis de qualquer outra forma e somente a rede MAPI continuar ativa (o que é configurado como desabilitado para replicação), o sistema usará a rede MAPI para replicação.

As redes DAG iniciais (por exemplo, MapiDagNetwork e ReplicationDagNetwork01) criadas pelo sistema têm como base as sub-redes enumeradas pelo serviço de Cluster. Cada membro do DAG deve ter o mesmo número de adaptadores de rede, e cada adaptador de rede deve ter um endereço IPv4 (e opcionalmente, um endereço IPv6 também) em uma sub-rede exclusiva. Vários membros do DAG podem ter endereços IPv4 na mesma sub-rede, mas cada adaptador de rede e par de endereço IP em um membro do DAG específico deve estar em uma sub-rede exclusiva. Além disso, somente o adaptador usado para a rede MAPI deve ser configurado com um gateway padrão. As redes de replicação não devem ser configuradas com um gateway padrão.

Por exemplo, considere o DAG1, um DAG de dois membros em que cada membro tem dois adaptadores de rede (um dedicado para a rede MAPI e outro para uma rede de replicação). As definições de configuração de endereços IP de exemplo são apresentadas na tabela seguinte:

Exemplo de configurações do adaptador de rede

Adaptador de servidor-rede Endereço IP/máscara de sub-rede Gateway padrão
EX1-MAPI 192.168.1.15/24 192.168.1.1
EX1-Replication 10.0.0.15/24 Não aplicável
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Replication 10.0.0.16 Não se aplica

Na configuração a seguir, há duas sub-redes configuradas no DAG: 192.168.1.0 e 10.0.0.0. Quando EX1 e EX2 são adicionados ao DAG, duas sub-redes serão enumeradas e duas redes de DAG serão criadas: MapiDagNetwork (192.168.1.0) e ReplicationDagNetwork01 (10.0.0.0). Estas redes serão configuradas, conforme mostrado na tabela seguinte:

Configurações de rede de DAG enumeradas para um DAG de sub-rede única

Nome Sub-redes Interfaces Acesso MAPI habilitado Replicação habilitada
MapiDagNetwork 192.168.1.0/24 EX1 (192.168.1.15)
EX2 (192.168.1.16)		 Verdadeiro Verdadeiro
ReplicationDagNetwork01 10.0.0.0/24 EX1 (10.0.0.15)
EX2 (10.0.0.16)		 Falso Verdadeiro

Para concluir a configuração de ReplicationDagNetwork01 como a rede de replicação dedicada, desative a replicação para MapiDagNetwork ao executar o seguinte comando:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork -ReplicationEnabled:$false

Depois que a replicação é desabilitada para MapiDagNetwork, o serviço de replicação do Microsoft Exchange usa ReplicationDagNetwork01 para replicação contínua. Se ReplicationDagNetwork01 falhar, o serviço de replicação do Microsoft Exchange volta a usar MapiDagNetwork para replicação contínua. O regresso a MapiDagNetwork é feito intencionalmente pelo sistema para manter a elevada disponibilidade.

Redes DAG e várias implantações de sub-rede

No exemplo anterior, embora existam duas sub-redes diferentes em uso pelo DAG (192.168.1.0 e 10.0.0.0), o DAG é considerado uma sub-rede única porque cada membro usa a mesma sub-rede para formar a redes MAPI. Quando os membros do DAG usam sub-redes diferentes para a rede MAPI, o DAG é mencionado como um DAG com várias sub-redes. Em um DAG com várias sub-redes, as sub-redes adequadas são associadas automaticamente a cada rede DAG.

Por exemplo, considere o DAG2, um DAG de dois membros em que cada membro tem dois adaptadores de rede (um dedicado para a rede MAPI e outro para uma rede de replicação), e cada membro do DAG está localizado em um site do Active Directory separado, com sua rede MAPI em uma sub-rede diferente. As definições de configuração de endereços IP de exemplo são apresentadas na tabela seguinte:

Exemplo de configurações de adaptador de rede para um DAG com várias sub-redes

Adaptador de servidor-rede Endereço IP/máscara de sub-rede Gateway padrão
EX1-MAPI 192.168.0.15/24 192.168.0.1
EX1-Replication 10.0.0.15/24 Não aplicável
EX2-MAPI 192.168.1.15 192.168.1.1
EX2-Replication 10.0.1.15 Não se aplica

Na configuração a seguir, há quatro sub-redes configuradas no DAG: 192.168.0.0, 192.168.1.0, 10.0.0.0 e 10.0.1.0. Quando EX1 e EX2 são adicionados ao DAG, quatro sub-redes serão enumeradas, mas apenas duas redes DAG serão criadas: MapiDagNetwork (192.168.0.0, 192.168.1.0) e ReplicationDagNetwork01 (10.0.0.0, 10.0.1.0). Estas redes serão configuradas conforme mostrado na tabela seguinte:

Configurações de rede de DAG enumeradas para um DAG de várias sub-redes

Nome Sub-redes Interfaces Acesso MAPI habilitado Replicação habilitada
MapiDagNetwork 192.168.0.0/24
192.168.1.0/24		 EX1 (192.168.0.15)
EX2 (192.168.1.15)		 Verdadeiro Verdadeiro
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24		 EX1 (10.0.0.15)
EX2 (10.0.1.15)		 Falso Verdadeiro

Redes DAG e redes iSCSI

Por padrão, os DAGs realizam a descoberta de todas as redes detectadas e configuradas para uso pelo cluster subjacente. Esta deteção inclui a de quaisquer redes DE INTERNET SCSI (iSCSI) em utilização como resultado da utilização do armazenamento iSCSI para um ou mais membros do DAG. Como prática recomendada, o armazenamento iSCSI deve usar redes dedicadas e adaptadores de rede. Estas redes não devem ser geridas pelo DAG ou pelo respetivo cluster ou ser utilizadas como redes DAG (MAPI ou replicação). Em vez disso, estas redes devem ser manualmente desativadas da utilização pelo DAG para que possam ser dedicadas ao tráfego de armazenamento iSCSI. Para impedir que redes iSCSI sejam detectadas e usadas como redes DAG, configure o DAG para ignorar quaisquer redes iSCSI detectadas no momento usando o cmdlet Set-DatabaseAvailabilityGroupNetwork, como neste exemplo:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Este comando também irá desativar a rede para uso pelo cluster. Embora as redes iSCSI continuem aparecendo como redes do DAG, elas não serão usadas para MAPI ou tráfego de replicação após a execução do comando acima.

Configurar membros do DAG

Os servidores de caixa de correio que são membros de um DAG têm algumas propriedades específicas de alta disponibilidade que devem ser configuradas como descrito nas seguintes seções:

Discagem de montagem automática de banco de dados

O parâmetro AutoDatabaseMountDial especifica o comportamento de montagem de banco de dados automático após o failover de um banco de dados. Pode utilizar o cmdlet Set-MailboxServer para configurar o parâmetro AutoDatabaseMountDial com qualquer um dos seguintes valores:

  • BestAvailability: se especificar este valor, a base de dados é montada automaticamente imediatamente após uma ativação pós-falha se o comprimento da fila de cópia for menor ou igual a 12. O tamanho da fila de cópia é o número de logs reconhecidos pela cópia passiva que precisa ser replicada. Se o tamanho da fila de cópia for maior que 12, o banco de dados não será montado automaticamente. Quando o comprimento da fila de cópia é menor ou igual a 12, o Exchange tenta replicar os registos restantes para a cópia passiva e monta a base de dados.

  • GoodAvailability: se especificar este valor, a base de dados é montada automaticamente imediatamente após uma ativação pós-falha se o comprimento da fila de cópia for inferior ou igual a seis. O tamanho da fila de cópia é o número de logs reconhecidos pela cópia passiva que precisa ser replicada. Se o tamanho da fila de cópia for maior que seis, o banco de dados não será montado automaticamente. Quando o tamanho da fila de cópia é inferior ou igual a seis, o Exchange tenta replicar os logs restantes para a cópia passiva e monta o banco de dados.

  • Lossless: se especificar este valor, a base de dados não é montada automaticamente até que todos os registos gerados na cópia ativa tenham sido copiados para a cópia passiva. Essa configuração faz também com que o Gerenciador Ativo selecione a melhor cópia de algoritmo para classificar candidatos potenciais para ativação com base no valor de preferência de ativação da cópia de banco de dados e não na extensão da fila de cópia.

O valor padrão é GoodAvailability. Se especificar ou BestAvailabilityGoodAvailabilitye todos os registos da cópia ativa não puderem ser copiados para a cópia passiva que está a ser ativada, poderá perder alguns dados da caixa de correio. No entanto, o recurso de Rede Segura (que é habilitado por padrão) ajuda a proteger contra a perda da maior parte dos dados, reenviando as mensagens que estão na fila de Rede Segura.

Exemplo: configurar discagem de montagem automática de banco de dados

O exemplo seguinte configura um servidor de Caixa de Correio com uma definição AutoDatabaseMountDial de GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Política de ativação automática de cópia do banco de dados

O parâmetro DatabaseCopyAutoActivationPolicy especifica o tipo de ativação automática disponível para cópias de banco de dados da caixa de correio nos servidores Caixa de Correio selecionados. Pode utilizar o cmdlet Set-MailboxServer para configurar o parâmetro DatabaseCopyAutoActivationPolicy com qualquer um dos seguintes valores:

  • Blocked: se especificar este valor, as bases de dados não podem ser ativadas automaticamente nos servidores da Caixa de Correio selecionados.

  • IntrasiteOnly: se especificar este valor, a cópia da base de dados pode ser ativada em servidores no mesmo site do Active Directory. Esta ativação impede a ativação ou ativação pós-falha entre sites. Essa propriedade se destina a cópias de banco de dados de caixa de correio (por exemplo, uma cópia passiva transformada em uma cópia ativa). Os bancos de dados não podem ser ativados nesse servidor de Caixa de Correio para cópias de banco de dados ativos em outro site do Active Directory.

  • Unrestricted: se especificar este valor, não existem restrições especiais na ativação de cópias da base de dados da caixa de correio nos servidores da Caixa de Correio selecionados.

Exemplo: configurar política de ativação automática de cópia do banco de dados

O exemplo seguinte configura um servidor de Caixa de Correio com uma definição DatabaseCopyAutoActivationPolicy de Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Máximo de bancos de dados ativos

O parâmetro MaximumActiveDatabases (também usado com o cmdlet Set-MailboxServer) especifica o número de bancos de dados que pode ser montado em um servidor de Caixa de Correio. Você pode configurar servidores de Caixa de Correio para atender aos seus requisitos de implantação assegurando que um servidor de Caixa de Correio individual não fique sobrecarregado.

O parâmetro MaximumActiveDatabases está configurado com um valor numérico de número inteiro. Quando o número máximo for atingido, as cópias de banco de dados no servidor não poderão ser ativadas se houver failover ou alternância. Se as cópias já estiverem ativas em um servidor, ele não permitirá a montagem de bancos de dados.

Exemplo: configurar máximo de bancos de dados ativos

O exemplo seguinte configura um servidor de Caixa de Correio para suportar um máximo de 20 bases de dados ativas:

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Executar a manutenção em membros do DAG

Antes de efetuar qualquer tipo de manutenção de software ou hardware num membro da DAG, primeiro deve colocar o membro da DAG no modo de manutenção. Os scripts seguintes são fornecidos com Exchange Server para ajudar nos procedimentos de manutenção do DAG:

  • StartDagServerMaintenance.ps1: ajuda a mover todas as bases de dados ativas para fora do servidor. Também move todas as funcionalidades críticas de suporte do DAG, como a função Primary Active Manager (PAM) e impede-as de voltar ao servidor antes de a manutenção estar concluída.

  • StopDagServerMaintenance.ps1: ajuda a tirar o membro da DAG do modo de manutenção e a torná-lo um destino ativo para todas as bases de dados e todas as funcionalidades críticas de suporte do DAG.

Ambos os scripts acima aceitam o parâmetro ServerName (que pode ser o nome do anfitrião ou o nome de domínio completamente qualificado (FQDN) do membro da DAG) e os parâmetros WhatIf . Ambos os scripts podem ser executados localmente ou remotamente. O servidor no qual os scripts são executados tem de ter as ferramentas de Gestão de Clusters de Ativação Pós-falha do Windows instaladas (RSAT-Clustering).

Observação

O scriptRedistributeActiveDatabases.ps1 também está disponível, o que ajuda na montagem de bases de dados de caixas de correio em membros da DAG específicos, conforme indicado pelo número da Preferência de Ativação em cada base de dados. No entanto, no Exchange 2016 CU2 ou posterior, a nova propriedade DAG denominada PreferenceMoveFrequency equilibra automaticamente cópias de base de dados num DAG. Por conseguinte, só terá de utilizar RedistributeActiveDatabases.ps1 script se tiver desativado esta funcionalidade ou se quiser equilibrar as cópias da base de dados manualmente.

O scriptStartDagServerMaintenance.ps1 executa as seguintes tarefas:

  • Define o valor do parâmetro DatabaseCopyAutoActivationPolicy no membro da DAG como Blocked, o que impede que quaisquer cópias de base de dados sejam ativadas no servidor.

  • Coloca o nó em pausa no cluster, o que impede que o nó seja e se torne o PAM.

  • Move todas as bases de dados ativas atualmente alojadas no membro da DAG para outros membros do DAG.

  • Se o membro da DAG for atualmente proprietário do grupo de clusters predefinido, o script move o grupo de clusters predefinido (e, portanto, a função PAM) para outro membro do DAG.

Se alguma das tarefas anteriores falhar, todas as operações, exceto as movimentações bem-sucedidas da base de dados, serão anuladas pelo script.

Para iniciar os procedimentos de manutenção num membro da DAG, incluindo remover as filas de transporte e suspender a conectividade do cliente, execute as seguintes tarefas:

  1. Para esvaziar as filas de transporte, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. Para iniciar a drenagem das filas de transporte, execute o seguinte comando:

    Restart-Service MSExchangeTransport

  3. Para iniciar o processo de drenagem de todas as chamadas unified Messaging (apenas no Exchange 2016), execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. Para aceder aos scripts de manutenção do DAG, execute o seguinte comando:

    CD $ExScripts

  5. Para executar o scriptStartDagServerMaintenance.ps1 , execute o seguinte comando:

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode

    Para o valor do parâmetro MoveComment , pode fazer qualquer notação pretendida. O exemplo acima utiliza "Manutenção".

    Observação

    Este script pode demorar algum tempo a ser executado e, durante este período, poderá não ver qualquer atividade no ecrã.

  6. Para redirecionar mensagens com entrega pendente nas filas locais para o servidor Exchange especificado pelo parâmetro Target, execute o seguinte comando:

    Redirect-Message -Server <ServerName> -Target <Server FQDN>

  7. Para colocar o servidor no modo de manutenção, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

Para verificar se um servidor está pronto para manutenção, realizar as seguintes tarefas:

  1. Para verificar se o servidor foi colocado no modo de manutenção, confirme que apenas Monitoring e RecoveryActionsEnabled estão num estado ativo quando executar o seguinte comando:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

  2. Para verificar se o servidor não está a alojar cópias de bases de dados ativas, execute o seguinte comando:

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy

  3. Para verificar se o nó de cluster está em pausa, execute o seguinte comando:

    Get-ClusterNode <ServerName> | Format-List

  4. Para verificar se todas as filas de transporte foram esvaziadas, execute o seguinte comando:

    Get-Queue

Quando a manutenção estiver concluída e o membro da DAG estiver pronto para voltar ao serviço, o script StopDagServerMaintenance.ps1 ajuda a retirar o membro da DAG do modo de manutenção e a colocá-lo novamente em produção. O scriptStopDagServerMaintenance.ps1 executa as seguintes tarefas:

  • Retoma o nó no cluster, o que permite a funcionalidade completa do cluster para o membro da DAG.

  • Define o valor do parâmetro DatabaseCopyAutoActivationPolicy no membro da DAG como Unrestricted.

  • Executa o cmdlet Resume-MailboxDatabaseCopy para cada cópia de base de dados alojada no membro do DAG.

Quando estiver pronto para restaurar o membro da DAG para uma status de produção completa, incluindo retomar as filas de transporte e a conectividade do cliente, execute as seguintes tarefas:

  1. Para configurar o servidor para estar no modo de manutenção fora de manutenção e pronto para aceitar ligações de cliente, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

    Observação

    • Se o seu ambiente utilizar o Microsoft Exchange IMAP4 & serviços POP3 do Microsoft Exchange, por predefinição, os serviços param e permanecem no modo parado se os componentes e PopProxy relacionados ImapProxy estiverem no estado Inativo.
    • Para iniciar os serviços, altere o estado dos componentes e PopProxy relacionados ImapProxy para Ativo e inicie manualmente os serviços.

  2. Para permitir que o servidor aceite chamadas unified Messaging (apenas no Exchange 2016), execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  3. Para aceder aos scripts de manutenção do DAG, execute o seguinte comando:

    CD $ExScripts

  4. Para executar o scriptStopDagServerMaintenance.ps1 , execute o seguinte comando:

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>

  5. Para permitir que as filas de transporte retomem a aceitação e o processamento de mensagens, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  6. Para retomar a atividade de transporte, execute o seguinte comando:

    Restart-Service MSExchangeTransport

Para verificar se um servidor está pronto para o uso na produção, execute as seguintes tarefas:

  1. Para verificar se o servidor não está no modo de manutenção, execute o seguinte comando:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

    Se estiver a instalar uma atualização do Exchange e o processo de atualização falhar, poderá deixar alguns componentes do servidor num estado inativo, que será apresentado na saída do cmdlet acima Get-ServerComponentState . Para resolve este problema, execute os seguintes comandos:

    • Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

    • Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

    • Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

Desativar os membros do DAG

A solução de elevada disponibilidade do Exchange está integrada no processo de encerramento do Windows. Se um administrador ou aplicativo iniciar um desligamento de um servidor do Windows em um DAG com um banco de dados montado replicado para um ou mais membros do DAG, o sistema tentará ativar outra cópia do banco de dados montado, antes de permitir a conclusão do processo de desligamento.

No entanto, este novo comportamento não garante que todas as bases de dados no servidor que estão a ser encerradas irão sofrer uma lossless ativação. Dessa forma, é uma prática recomendável realizar uma alternância de servidor antes de desligar um servidor membro de um DAG.

Instalar atualizações sobre membros do DAG

Instalar atualizações do Exchange num servidor que seja membro de um DAG é um processo relativamente simples. Quando você instalar uma atualização em um servidor que é membro de um DAG, vários serviços são interrompidos durante a instalação, incluindo todos os Exchange serviços eo serviço de cluster. O processo geral para a aplicação de alterações de um membro do DAG é como se segue:

  1. Use as etapas descritas acima para colocar o membro do DAG em modo de manutenção.

  2. Instale a atualização.

  3. Use os passos descritos acima para dar o membro do DAG do modo de manutenção e colocá-lo novamente em produção.

  4. Opcionalmente, utilize o script RedistributeActiveDatabases.ps1 para reequilibrar as cópias de bases de dados ativas no DAG.

Para obter mais informações sobre as atualizações mais recentes do Exchange, consulte Exchange Server números de compilação e datas de lançamento.

Observação

Deve executar sempre todos os membros do DAG na mesma versão do servidor Exchange (incluindo atualizações cumulativas e de segurança). Execute uma "atualização sem interrupção" de todos os membros do DAG e não execute um DAG com membros numa versão diferente do Exchange durante um período de tempo prolongado.