Partilhar via

Gerenciando grupos de disponibilidade de bancos de dados

  • Artigo

 

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

Tópico modificado em: 2016-11-28

DAG (grupo de disponibilidade do banco de dados) é um conjunto de até 16 servidores de caixa de correio do Microsoft Exchange Server 2010 que fornece recuperação automática no nível de banco de dados, diante de uma falha no banco de dados, no servidor ou na 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. Ao ser adicionado a um DAG, um servidor de Caixa de Correio funciona com outros servidores no DAG para fornecer recuperação automática em nível de banco de dados a partir de falhas de banco de dados.

Ao ser criado, um DAG permanece inicialmente vazio, e um objeto de diretório é criado no Active Directory que representa o DAG. O objeto de diretório é usado para armazenar informações relevantes sobre o DAG, como informações da associação do servidor. 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 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.

Sumário

Criando DAGs

Associação ao DAG

Configurando propriedades do DAG

Redes do DAG

Configurando membros do DAG

Executando a manutenção em membros do DAG

Desativando os membros do DAG

Instalando pacotes cumulativos em membros do DAG

Criando DAGs

Um DAG pode ser criado usando-se o assistente de Novo Grupo de Disponibilidade de Banco de Dados, no Console de Gerenciamento do Exchange (EMC), ou executando-se o cmdlet New-DatabaseAvailabilityGroup, no Shell de Gerenciamento do Exchange. Ao criar um DAG, você fornece um nome para o DAG, um servidor testemunha opcional e as configurações do diretório testemunha. Além disso, um ou mais endereços IP são atribuídos ao DAG, usando-se endereços IP estáticos ou permitindo-se que os endereços IP necessários sejam atribuídos automaticamente ao DAG, usando o protocolo DHCP. É possível atribuir endereços IP manualmente ao DAG usando-se o parâmetro DatabaseAvailabilityGroupIpAddresses. Se você omitir esse parâmetro, o DAG tentará obter um endereço IP usando um servidor DHCP na rede.

Para instruções detalhadas sobre como criar um DAG, consulte Criar um Grupo de Disponibilidade de Banco de Dados.

Quando você cria um DAG, um objeto vazio representando o DAG com o nome especificado e uma classe de objeto msExchMDBAvailabilityGroup é criada no Active Directory.

DAGs usam um subconjunto das tecnologia de cluster de failover do Windows, como a pulsação do cluster, redes de cluster e o banco de dados de cluster (para armazenar dados que mudam ou podem mudar 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). Porque os DAGs dependem do cluster de failover Windows, eles só podem ser criados em servidores de Caixa de correio do Exchange 2010 com o sistema operativo Windows Server 2008 Enterprise ou com o Windows Server 2008 R2 Enterprise.

Dica

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

Ao criar um DAG, você precisa especificar um nome para o DAG que não seja maior que 15 caracteres, exclusivo dentro da floresta do Active Directory. Além disso, cada DAG é configurado com um servidor testemunha e um diretório testemunha. O servidor testemunha e seu diretório só são usados para fins de quorum, quando houver um número par de membros no DAG. 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 não deve ser usado para qualquer outro fim que não seja do servidor testemunha do DAG.

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 testemunha deverá estar executando o Windows Server 2003 ou posterior.

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

Recomendamos que você use um servidor de Transporte de Hub do Exchange 2010 no site do Active Directory que contenha o DAG. Isso permite ao servidor e ao diretório testemunha permanecerem sob o controle de um administrador do Exchange. Independentemente de qual servidor é usado como o testemunha, se o firewall do Windows estiver habilitado no servidor testemunha pretendido, você deverá habilitar a exceção de firewall do Windows para compartilhamento de arquivo e impressora.

Importante

Se o servidor testemunha especificado não for um servidor do Exchange 2010, você deverá adicionar o grupo de segurança universal (USG) Subsistema Confiável do Exchange ao grupo Administradores local no servidor testemunha 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).

Dica

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.

Como prática recomendável, em um ambiente no qual um DAG se estende por vários data centers (e sites do Active Directory) e está configurado para resiliência do site, recomendamos que você use um servidor testemunha no data center principal (o data center que contém a maioria da população de usuários). Se cada data center tiver um número semelhante de usuários, o data center escolhido para hospedar o servidor testemunha será considerado o principal a partir do ponto de vista da solução. Se o servidor testemunha estiver no datacenter com a maioria da população cliente, a maioria dos clientes manterá o acesso após uma falha.

Se o datacenter for remoto para grandes populações de usuários, isso poderá afetar a sua decisão. Assim, você precisaria determinar se há um requisito para que o data center primário permaneça íntegro e ativo em caso de perda de conectividade WAN (rede de longa distância) com os outros dois data centers. Nesse caso, o servidor testemunha também deve estar no datacenter primário.

Embora haja suporte ao uso de um servidor testemunha em um terceiro datacenter, não recomendamos isso. Do ponto de vista do Exchange, essa configuração não fornece mais disponibilidade. Será importante examinar os fatores de caminho críticos, se você usar um servidor testemunha em um terceiro datacenter. Por exemplo, se houver falha na conexão WAN entre o data center principal e o segundo e o terceiro data centers, a solução no data center principal se tornará indisponível.

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

Ao criar um DAG, você deve fornecer um nome para ele. Também é possível especificar um servidor e um diretório testemunha. Se você especificar um servidor testemunha, recomendamos que use um servidor de Transporte de Hub porque isso permite a um administrador do Exchange estar atento à disponibilidade do servidor testemunha.

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

  • É possível especificar apenas um nome para o DAG e deixar os campos Servidor testemunha e Diretório testemunha em branco. Nesse cenário, o assistente procura um servidor de Transporte de Hub que não tenha a função servidor de Caixa de Correio instalada e cria automaticamente o diretório padrão (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) e o compartilhamento padrão (<DAGFQDN>) nesse servidor e usa esse servidor de Transporte de Hub como o servidor testemunha. Por exemplo, considere um servidor testemunha chamado EXMBX3 no qual o sistema operacional tenha sido instalado na unidade C. Um DAG chamado DAG1 em um domínio chamado contoso.com usaria um diretório testemunha padrão de C:\DAGFileShareWitnesses\DAG1.contoso.com, que seria compartilhado como \\EXMBX3\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 Transporte de Hub que não tenha a função Servidor de Caixa de Correio instalada e cria automaticamente o DAG especificado nesse servidor, compartilha o diretório e usa o servidor Transporte de Hub 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 DAG começará a usar o servidor testemunha para manter um quorum. Se o diretório testemunha não existir, o Exchange o criará e compartilhará automaticamente, além de fornecer o compartilhamento com permissões de controle total para a conta de computador do objeto de nome do cluster (CNO) do DAG.

Dica

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. Caso especifique um servidor testemunha, mas não um diretório testemunha, será exibida a seguinte mensagem de erro.

A tarefa não pôde criar o diretório testemunha padrão no servidor <Nome de Servidor>. Especifique um diretório testemunha manualmente.

Caso especifique um servidor testemunha e um diretório testemunha, será exibida a seguinte mensagem de erro:

Não é possível acessar compartilhamentos de arquivos no servidor testemunha 'Nome do servidor'. Até o problema ser corrigido, o grupo de disponibilidade pode ficar mais vulnerável a falhas. Você pode usar o cmdlet Set-DatabaseAvailabilityGroup para tentar a operação novamente. Erro: O caminho da rede não foi encontrado.

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 o firewall do Windows estiver habilitado no servidor testemunha e não houver nenhuma exceção de firewall configurada para a WMI, o cmdlet Add-DatabaseAvailabilityGroupServer exibirá a seguinte mensagem de aviso.

Falha ao criar o diretório testemunha de compartilhamento de arquivo 'C:\DAGFileShareWitnesses\DAG_FQDN' no servidor testemunha 'Nome do servidor'. Até o problema ser corrigido, o grupo de disponibilidade pode ficar mais vunerável a falhas. Você pode usar o cmdlet Set-DatabaseAvailabilityGroup para tentar a operação novamente. Erro: Ocorreu uma exceção de WMI no servidor 'Nome do servidor': O servidor RPC não está disponível. (Exceção de HRESULT: 0x800706BA)

Para resolver o erro e os avisos anteriores, execute um destes procedimentos:

  • 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.

Voltar ao início

Associação ao DAG

Depois da criação de um DAG, é possível adicionar servidores ao DAG ou removê-los do DAG, usando o assistente para Gerenciar Grupo de Disponibilidade de Banco de Dados no EMC ou usando os cmdlets Add-DatabaseAvailabilityGroupServer ou Remove-DatabaseAvailabilityGroupServer no Shell. Para instruções detalhadas sobre como gerenciar a associação ao DAG, consulte Gerenciar a Associação no Grupo de Disponibilidade de Banco de Dados.

Dica

Cada servidor de Caixa de Correio membro de um DAG também é um nó no cluster subjacente usado pelo DAG. Dessa forma, a qualquer momento, um servidor de Caixa de Correio pode ser membro de apenas um único 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 de Caixa de Correio for adicionado a um DAG, ocorrerá o seguinte:

  • 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 esse objeto do Active Directory não for replicado em todo o ambiente, a adição do segundo servidor poderá causar a criação de um novo cluster (e novo CNO) para o DAG. Isso ocorre porque o objeto do DAG aparentará estar vazio a partir da perspectiva do segundo membro sendo adicionado, dessa forma fazendo com que o cmdlet Add-DatabaseAvailabilityGroupServer crie um novo cluster e CNO para o DAG, embora esses 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 e os servidores subsequentes forem adicionados ao DAG, ocorrerá o seguinte:

  • 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.

Dica

A alteração feita no modelo de quorum deve acontecer automaticamente. No entanto, se o modelo de quorum não for alterado automaticamente para o modelo apropriado, será possível executar o cmdlet Set-DatabaseAvailabilityGroup com apenas o parâmetro Identity para corrigir as configurações de quorum do DAG.

Preparando o objeto de rede de 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. No Exchange 2007, essa conta de máquina habilitada para Kerberos foi criada no domínio com o uso do contexto de segurança do usuário que executa as tarefas. Isso exigiu que a conta do usuário tivesse permissões para criar e habilitar as contas de máquina no domínio ou que a conta do computador estivesse corretamente preparada e provisionada.

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, Powershell 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.

Aviso

Caso os membros do DAG estejam executando o Windows Server 2012, você deverá preparar o CNO antes de adicionar o primeiro servidor ao 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 desabilite uma conta de computador para o CNO e:

  • 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 Prepare o objeto de nome de cluster para um grupo de disponibilidade do banco de dados.

Removendo servidores de um DAG

Os servidores de caixa de correio podem ser removidos de um DAG usando-se o assistente para Gerenciar Grupo de Disponibilidade de Banco de Dados no EMC ou o cmdlet Remove-DatabaseAvailabilityGroupServer no Shell. 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:

  • Realizar uma operação de recuperação de servidor   Se um servidor de Caixa de Correio membro de um DAG for perdido ou houver uma falha e ele não puder ser recuperado e precisar de substituição, será possível realizar uma operação de recuperação de servidor usando a opção Setup /m:RecoverServer. No entanto, antes de conseguir realizar a operação de recuperação, você deve primeiro remover o servidor do DAG usando o cmdlet Remove-DatabaseAvailabilityGroupServer com o parâmetro ConfigurationOnly.

  • Remover a disponibilidade do banco de dados   Talvez haja situações nas quais você precise remover um DAG (por exemplo, ao desabilitar 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 um ou mais membros, haverá falha na tarefa.

Voltar ao início

Configurando propriedades do DAG

Depois que os servidores forem adicionados ao DAG, será possível usar o EMC ou o Shell para configurar as propriedades de um DAG, inclusive o servidor testemunha e o diretório testemunha usados pelo DAG, além dos endereços IP atribuídos ao DAG.

As propriedades configuráveis incluem:

  • Servidor testemunha   O nome do servidor em que você deseja hospedar o compartilhamento de arquivos para a testemunha de compartilhamento de arquivos. Recomendamos que você use especifique um servidor de Transporte de Hub fora do DAG como o servidor testemunha. Isso permite ao sistema configurar, proteger e usar o compartilhamento automaticamente, conforme necessário.

  • Diretório testemunha   O nome de um diretório que será usado para armazenar dados de testemunha de compartilhamento de arquivos. Esse diretório será criado automaticamente pelo sistema no servidor testemunha especificado.

  • Endereços IP do grupo de disponibilidade de banco de dados   Um ou mais endereços IP atribuídos ao DAG. Esses endereços podem ser configurados usando-se endereços IP estáticos manualmente, ou podem ser atribuídos automaticamente ao DAG usando-se um servidor DHCP na organização.

O Shell permite configurar as propriedades do DAG que não estão disponíveis no EMC, como os endereços IP do DAG, a criptografia de rede e as configurações de compactação, a descoberta de rede, a porta TCP usada para replicação e o servidor testemunha alternativo e as configurações do diretório testemunha, além de habilitar o modo de Coordenação de Ativação do Data Center.

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 a lista completa, consulte a seção 3.1.5.2, "Encryption Types" de Kerberos Protocol Extensions). O handshake de autenticação Kerberos selecione o protocolo de criptografia mais forte suportado na lista: normalmente, criptografia AES (Advanced Encryption Standard) de 256 bits, potencialmente com um SHA HMAC (Código de Autenticação da Mensagem Baseada em Hash) para manter a integridade dos dados. Para detalhes, consulte HMAC.

A criptografia de rede é uma propriedade do DAG e não de uma rede do DAG. É possível configurar a criptografia de rede do DAG usando o cmdlet Set-DatabaseAvailabilityGroup no Shell. As configurações de criptografia possíveis para a comunicação de rede do DAG são mostradas na tabela a seguir.

Configurações de criptografia da comunicação de rede do DAG

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 é a configuração padrã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. Para mais detalhes, consulte An Explanation of the Deflate Algorithm e a seção 3.1.7.2 "Compression Algorithm" de Wire Format Protocol Specification. Esse é o mesmo tipo de compactação usado em muitos protocolos da Microsoft, em especial, a compactação MAPI RPC entre o Microsoft Outlook e o Exchange.

Assim como acontece com a criptografia de rede, a compactação de rede também é uma propriedade do DAG, e não de uma rede do DAG. Você configura a compactação de rede do DAG usando o cmdlet Set-DatabaseAvailabilityGroup no Shell. As configurações de compactação possíveis para a comunicação de rede do DAG são mostradas na tabela a seguir.

Configurações de compactação da comunicação de rede do DAG

Configuração Descrição

Desabilitado

A compactação de rede não é usada.

Enabled

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 é a configuração padrão.

SeedOnly

A compactação de rede é usada em todas as redes do DAG apenas para propagação.

Voltar ao início

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.

Dica

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.

É possível usar o assistente de Novo Grupo de Disponibilidade de Banco de Dados no EMC ou o cmdlet New-DatabaseAvailabilityGroupNetwork no Shell para criar uma rede do DAG. Para instruções detalhadas sobre como criar uma rede DAG, consulte Criar uma Rede de Grupo de Disponibilidade de Banco de Dados.

É possível usar a caixa de diálogo Propriedades do DAG no EMC ou o cmdlet Set-DatabaseAvailabilityGroupNetwork no Shell para configurar as propriedades de rede do 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 do DAG, com até 128 caracteres.

  • Descrição da rede   Uma descrição opcional para a rede do DAG, com até 256 caracteres.

  • Sub-redes da rede   Uma ou mais sub-redes inseridas usando-se um formato de IPAddress/Bitmask (por exemplo, 192.168.1.0/24 para sub-redes IPv4; 2001:DB8:0:C000::/64 para sub-redes IPv6).

  • Habilitar replicação   No EMC, marque a caixa de seleção para dedicar a rede do DAG ao tráfego de replicação e bloquear o tráfego MAPI. Desmarque a caixa de seleção para evitar a replicação do uso da rede do DAG e habilitar o tráfego MAPI. No Shell, use o parâmetro ReplicationEnabled no cmdlet Set-DatabaseAvailabilityGroupNetwork para habilitar e desabilitar a replicação.

Dica

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.

A redes DAG iniciais (por exemplo, DAGNetwork01 e DAGNetwork02) 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 configurações de definição de endereço IP de exemplo são mostradas na tabela a seguir.

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-Replicação

10.0.0.15/24

Não aplicável

EX2-MAPI

192.168.1.16

192.168.1.1

EX2-Replicação

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: DAGNetwork01 (192.168.1.0) e DAGNetwork02 (10.0.0.0). Essas redes serão configuradas como mostrado na tabela a seguir.

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

Nome Sub-redes Interfaces Acesso MAPI habilitado Replicação habilitada

DAGNetwork01

192.168.1.0/24

EX1 (192.168.1.15)

EX2 (192.168.1.16)

Verdadeiro

Verdadeiro

DAGNetwork02

10.0.0.0/24

EX1 (10.0.0.15)

EX2 (10.0.0.16)

Falso

Verdadeiro

Para concluir a configuração do DAGNetwork02 como a rede de replicação dedicada, desabilite a replicação para DAGNetwork01 executando o seguinte comando.

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

Após a replicação ser desabilitada para DAGNetwork01, o serviço de Replicação do Microsoft Exchange usará DAGNetwork02 para replicação contínua. Se DAGNetwork02 tiver uma falha, o serviço de Replicação do Microsoft Exchange será revertido para usar DAGNetwork01 para replicação contínua. Isso é feito intencionalmente pelo sistema para manter alta disponibilidade.

Redes do 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, a configuração adicional das redes do DAG deve ser feita para associar as sub-redes apropriadas a cada rede do 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 configurações de definição de endereço IP de exemplo são mostradas na tabela a seguir.

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-Replicação

10.0.0.15/24

Não se aplica

EX2-MAPI

192.168.1.15

192.168.1.1

EX2-Replicação

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 e duas redes de DAG serão criadas: DAGNetwork01 (192.168.0.0), DAGNetwork02 (10.0.0.0), DAGNetwork03 (192.168.1.0) e DAGNetwork04 (10.0.1.0). Essas redes serão configuradas como mostrado na tabela a seguir.

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

DAGNetwork01

192.168.0.0/24

EX1 (192.168.0.15)

Verdadeiro

Verdadeiro

DAGNetwork02

10.0.0.0/24

EX1 (10.0.0.15)

Falso

Verdadeiro

DAGNetwork03

192.168.1.0/24

EX2 (192.168.1.15)

Verdadeiro

Verdadeiro

DAGNetwork04

10.0.1.0/24

EX2 (10.0.1.15)

Falso

Verdadeiro

Para a conclusão da configuração necessária, DAGNetwork03 e DAGNetwork04 devem ser recolhidos em DAGNetwork01 e DAGNetwork02, respectivamente. Isso envolve adicionar a sub-rede atualmente associada a DAGNetwork03 a DAGNetwork01 e adicionar a sub-rede atualmente associada a DAGNetwork04 a DAGNetwork02. Isso removerá as associações de sub-rede de DAGNetwork03 e DAGNetwork04, deixando-as como redes DAG vazias que podem ser removidas. Para recolher as sub-redes nas duas redes de DAG e desabilitar a replicação na rede MAPI, execute os seguintes comandos.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork01 -Subnets 192.168.0.0,192.168.1.0 -ReplicationEnabled:$false
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -Subnets 10.0.0.0,10.0.1.0
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork03
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork04

Redes do DAG e redes iSCSI

Por padrão, os DAGs realizam a descoberta de todas as redes detectadas e configuradas para uso pelo cluster subjacente. Isso inclui todas as redes iSCSI (Internet SCSI) em uso como resultado do uso 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. Essas redes não devem ser gerenciadas pelo DAG ou pelo cluster, ou usadas como redes DAG (MAPI ou replicação). Em vez disso, essas redes devem ser desabilitadas manualmente do uso 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 DAG, elas não serão usadas para MAPI ou tráfego de replicação após a execução do comando acima.

Voltar ao início

Configurando 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 Automática de Montagem do Banco de Dados

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

  • Máximo de Bancos de Dados Ativos

Discagem Automática de Montagem do 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. É possível usar o cmdlet Set-MailboxServer para configurar o parâmetro AutoDatabaseMountDial com qualquer um dos seguintes valores:

  • BestAvailability   Se você especificar esse valor, o banco de dados será montado automaticamente depois de um failover se o tamanho da fila de cópia for menor que 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 tamanho da fila de cópia é inferior ou igual a 12, o Exchange tenta replicar os logs restantes para a cópia passiva e monta o banco de dados.

  • GoodAvailability   Se você especificar esse valor, o banco de dados será montado automaticamente logo depois de um failover se o tamanho da fila de cópia for menor que 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 você especificar esse valor, o banco de dados não será montado automaticamente até que todos os logs que foram 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 você especificar BestAvailability ou GoodAvailability e nenhum log da cópia ativa puder ser replicado para a cópia passiva sendo ativada, você poderá perder alguns dados da caixa de correio. No entanto, o recurso de dumpster de transporte (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 dumpster de transporte.

Além dos valores anteriores, você pode configurar também o parâmetro AutoDatabaseMountDial com um valor personalizado usando ADSI Edit ou Ldp.exe para modificar o atributo diretamente no Active Directory. O parâmetro AutoDatabaseMountDial é representado pelo atributo msExchDataLossForAutoDatabaseMount do objeto de servidor de Caixa de Correio. O valor numérico de número inteiro desse atributo representa o número máximo de arquivos de log de transações que você pode perder para montar um banco de dados sem intervenção humana. Se você configurar o parâmetro AutoDatabaseMountDial com um valor personalizado maior que 12, recomendamos aumentar também o tamanho do dumpster de transporte para oferecer maior proteção contra perda de um número maior de logs.

Exemplo: Configurando Discagem Automática de Montagem do Banco de Dados

O exemplo a seguir configura um servidor de Caixa de Correio com uma configuraçã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. É possível usar o cmdlet Set-MailboxServer para configurar o parâmetro DatabaseCopyAutoActivationPolicy com qualquer um dos seguintes valores:

  • Blocked   Se você especificar esse valor, os bancos de dados não poderão ser ativados automaticamente nos servidores de Caixa de Correio selecionados.

  • IntrasiteOnly   Se você especificar esse valor, a cópia de banco de dados poderá ser ativada nos servidores no mesmo site do Active Directory. Isso impede o failover ou a ativação 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 você especificar esse valor, não haverá nenhuma restrição especial na ativação de cópias de banco de dados de caixa de correio nos servidores de Caixa de Correio.

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

O exemplo a seguir configura um servidor de Caixa de Correio com uma configuraçã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 é 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: Configurando Máximo de Bancos de Dados Ativos

O exemplo a seguir configura um servidor de Caixa de Correio para suporte a um máximo de 20 bancos de dados ativos.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Voltar ao início

Executando a manutenção em membros do DAG

Antes de executar qualquer tipo de manutenção de software ou hardware em um membro do DAG, você deverá primeiro remover o membro do DAG do serviço usando o script StartDagServerMaintenance.ps1. Esse script remove todos os bancos de dados ativos do servidor e impede bancos de dados ativos de mover para esse servidor. Esse script também assegura que toda a funcionalidade de suporte do DAG crítica que possa estar no servidor (por exemplo, a função de Gerenciador Ativo Primário (PAM)) seja movida para outro servidor e impedida de ser movida de volta para o servidor. Especificamente, o script StartDagServerMaintenance.ps1 executa as seguintes tarefas:

  • Executa Suspend-MailboxDatabaseCopy com o parâmetro ActivationOnly para suspender cada cópia de banco de dados hospedada no membro do DAG para ativação.

  • Pausa o nó no cluster, que impede que o nó seja e se torne o PAM.

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

  • Move todos os bancos de dados ativos atualmente hospedados no membro do DAG para outros membros do DAG.

  • Se o membro do DAG atualmente tiver o grupo de clusters padrão, o script moverá o grupo de clusters padrão (e por esse motivo a função PAM) para outro membro do DAG.

Se alguma das tarefas anteriores falhar, todas as operações, exceto as movimentações de banco de dados feitas com êxito, serão desfeitas.

Após a manutenção ser concluída e o membro do DAG estar pronto para voltar à operação, você poderá usar o script StopDagServerMaintenance.ps1 para tirar o membro do DAG do modo de manutenção e colocá-lo novamente em operação. Especificamente, o script StopDagServerMaintenance.ps1 executa as seguintes tarefas:

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

  • Retoma o nó no cluster, que disponibiliza toda a funcionalidade do cluster para o membro do DAG.

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

Ambos os scripts aceitam o parâmetro -ServerName (que pode ser o nome de host ou o nome de domínio totalmente qualificado (FQDN) do membro do DAG) e o parâmetro -WhatIf. Os dois scripts podem ser executados local ou remotamente. O servidor em que os scripts são executados devem ter as ferramentas de Gerenciamento de Cluster de Failover do Windows instaladas (RSAT-Clustering).

Voltar ao início

Desativando os membros do DAG

A solução de alta disponibilidade do Exchange 2010 é integrada ao processo de desligamento 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, esse novo comportamento não assegura que todos os bancos de dados no servidor desligados enfrentarão uma ativação lossless. Dessa forma, é uma prática recomendável realizar uma alternância de servidor antes de desligar um servidor membro de um DAG. Para obter etapas detalhadas sobre como realizar uma alternância de servidor, consulte Alternar um Servidor.

Voltar ao início

Instalando pacotes cumulativos em membros do DAG

A instalação de pacotes cumulativos de atualizações do Microsoft Exchange Server 2010 em um servidor membro de um DAG é um processo relativamente simples. Quando você instalar um pacote cumulativo de atualizações em um servidor membro de um DAG, vários serviços serão interrompidos durante a instalação, inclusive todos os serviços do Exchange e o serviço de Cluster. O processo geral para aplicar pacotes cumulativos de atualizações a um membro do DAG da seguinte forma:

  1. Use o script StartDagServerMaintenance.ps1 para colocar o membro do DAG no modo de manutenção.

  2. Instale o pacote cumulativo de atualizações.

  3. Use o script StopDagServerMaintenance.ps1 para tirar o membro do DAG do modo de manutenção e colocá-lo novamente em produção.

  4. Use o script RedistributeActiveDatabases.ps1 para balancear novamente as cópias de banco de dados ativas no DAG.

É possível baixar o pacote cumulativo de atualizações mais recente para o Exchange 2010 no Centro de Download da Microsoft. Para instruções detalhadas sobre como instalar um pacote cumulativo de atualizações em um membro do DAG, consulte Instalando Pacotes Cumulativos de Atualizações em Membros do Grupo de Disponibilidade de Banco de Dados.

Voltar ao início

 © 2010 Microsoft Corporation. Todos os direitos reservados.