Share via

Gerenciando grupos de disponibilidade de bancos de dados

  • Artigo

Aplica-se a: Exchange Server 2010

Tópico modificado em: 2010-01-25

Um grupo de disponibilidade do banco de dados (DAG) é um conjunto de até 16 servidores de Caixa de Correio do Microsoft Exchange Server 2010 que oferece recuperação automática em nível de banco de dados a partir de uma falha de banco de dados, servidor ou rede. Os DAGs usam replicação contínua e um subconjunto de tecnologias de clustering de failover do Windows para oferecer disponibilidade de caixa de correio contínua. Os servidores Caixa de Correio em um DAG monitoram todas as outras 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 grupos de disponibilidade de banco de dados

Associação ao grupo de disponibilidade de banco de dados

Configurando as propriedades do grupo de disponibilidade de banco de dados

Redes do grupo de disponibilidade de banco de dados

Desligando membros do grupo de disponibilidade de banco de dados

Instalando pacotes cumulativos de atualizações para os membros do grupo de disponibilidade do banco de dados

Criando grupos de disponibilidade de banco de dados

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

Os DAGs usam um subconjunto de tecnologias de clustering de failover do Windows, como a pulsação clusterizada, as redes clusterizadas e o banco de dados clusterizado (para armazenar dados alterados ou que podem ser alterados rapidamente, como alterações no estado do banco de dados de ativo para passivo ou o inverso, ou de montado para desmontado ou o inverso). Como dependem do clustering de failover do Windows, os DAGs só podem ser criados em servidores de Caixa de Correio do Exchange 2010 com o sistema operacional Windows Server 2008 Enterprise ou o Windows Server 2008 R2 Enterprise.

Servidor testemunha do grupo de disponibilidade de banco de dados 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 irá criar e proteger 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 deve estar executando o Windows Server 2008 R2, o Windows Server 2008, Windows Server 2003 R2 ou o Windows Server 2003.
  • Um único servidor pode funcionar como uma testemunha para vários DAGs; no entanto, cada DAG exige 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 testemunha e ao diretório permanecerem sob o controle de um administrador do Exchange.

Importante

Se o servidor testemunha especificado não for um servidor do Exchange 2010, você deverá adicionar o grupo de segurança universal 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 clusterizado 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 obrigatórias para que haja a necessidade do servidor testemunha. Como um DAG com seis membros podem tolerar até duas falhas de servidor sem perder quorum, seriam necessários até três membros com falha para que o servidor testemunha fosse exigido a fim de manter um quorum. 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 quorum).

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 datacenters (e sites do Active Directory) e está configurado para resiliência do site, recomendamos que você use um servidor testemunha no datacenter primário (o datacenter que contém a maioria da população de usuários). Se cada datacenter tiver um número semelhante de usuários, o datacenter escolhido para hospedar o servidor testemunha será considerado o datacenter primário 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 datacenter primário permaneça íntegro e ativo em caso de perda de conectividade WAN (rede de longa distância) com os outros dois datacenters. 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 datacenter primário e o segundo e o terceiro datacenters, a solução no datacenter primário 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 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 irá procurar um servidor de Transporte de Hub que não tenha a função servidor de Caixa de Correio instalada e criará automaticamente o diretório padrão (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) e o compartilhamento padrão (<DAGFQDN>) nesse servidor e usará 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 criará 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 irá procurar um servidor de Transporte de Hub que não tenha a função Servidor de Caixa de Correio instalada e irá criar automaticamente o DAG especificado nesse servidor, compartilhar o diretório e usar o servidor Transporte de Hub como o servidor testemunha.

Quando um DAG for formado, ele usará inicialmente o modelo de quorum 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 rede do cluster (CNO) do DAG.

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á exibido o seguinte 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á exibido o seguinte 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á o seguinte 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:

  • Prepare o diretório testemunha e o compartilhamento no servidor testemunha
  • Habilite a exceção WMI no firewall do Windows
  • Desabilite o firewall do Windows

Retornar ao início

Associação ao grupo de disponibilidade de banco de dados

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-DatabaseAvailbilityGroupServer ou Remove-DatabaseAvailbilityGroupServer 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 clustering 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.
  • Um objeto de rede de cluster (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 grupo de disponibilidade do banco de dados

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.

Conforme mencionado acima, 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.

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 da primeira Caixa de Correio sendo adicionada ao DAG.
  • Atribua controle total da conta do computador ao grupo de segurança universal do Subsistema Confiável do Exchange.

Atribuir controle total da conta do computador à conta do computador da primeira Caixa de Correio sendo adicionada 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 grupo de segurança universal do Subsistema Confiável do Exchange pode ser usada porque o grupo 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 PExecutar o pré-teste do Objeto de Rede de Cluster para um Grupo de Disponibilidade do Banco de Dados.

Removendo servidores de um grupo de disponibilidade de banco de dados

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-DatabaseAvailbilityGroupServer 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á determinados 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 grupo de disponibilidade de banco de dados 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.

Retornar ao início

Configurando as propriedades do grupo de disponibilidade de banco de dados

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

Para instruções detalhadas sobre como configurar propriedades de grupo de disponibilidade de banco de dados, consulte Configurar as Propriedades do Grupo de Disponibilidade do Banco de Dados.

Criptografia de rede do grupo de disponibilidade de banco de dados

Os DAGs dão suporte ao uso da criptografia aproveitando os recursos de criptografia do sistema operacional Windows Server. Os DAGs usam autenticação Kerberos entre servidores do Exchange. As APIs EncryptMessage/DecryptMessage do SSP (provedor de suporte de segurança) do Microsoft Kerberos tratam a criptografia do tráfego de rede do DAG. O SSP do Microsoft Kerberos dá suporte a vários algoritmos de criptografia. (Para ver a lista completa, consulte a seção de referência 3.1.5.2, "Encryption Types" de Kerberos Protocol Extensions) O handshake de autenticação Kerberos seleciona 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.

Dica

As informações de sites de terceiros existentes neste tópico são fornecidas para ajudá-lo a localizar as informações técnicas necessárias. As URLs estão sujeitas a alteração sem aviso prévio.

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

SeedOnly

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

Compactação de rede do grupo de disponibilidade de banco de dados

Os DAGs também 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 detalhes, consulte algoritmo LZ77 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.

Dica

As informações de sites de terceiros existentes neste tópico são fornecidas para ajudá-lo a localizar as informações técnicas necessárias. As URLs estão sujeitas a alteração sem aviso prévio.

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.

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.

SeedOnly

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

Retornar ao início

Redes do grupo de disponibilidade de banco de dados

Embora haja suporte a um único adaptador de rede e um caminho, recomendamos que cada DAG tenha pelo menos duas 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. 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. É possível criar redes adicionais em um DAG e configurá-las como redes de replicação para redundância.

Dica

Durante o uso de várias redes de replicação, não há como especificar uma ordem de precedência para o uso da rede. O Exchange selecionará aleatoriamente uma rede de replicação do grupo de redes de replicação a ser usada no 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 do 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 instruções detalhadas sobre como configurar 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 Endereço IP/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, com falha ou indisponíveis, e apenas uma rede MAPI permanecer não habilitada para replicação, o sistema continuará usando essa rede na replicação até que uma rede habilitada para replicação fique online e disponível para uso.

Redes do DAG e redes iSCSI

Por padrão, os DAGs realizarão 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 placas de interface 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, devem ser desabilitadas manualmente do uso pelo DAG, para que possam ser dedicadas ao tráfego de armazenamento iSCSI. Há duas etapas a serem realizadas para desabilitar redes iSCSI de serem detectadas e usadas como redes do DAG:

  1. Configure o DAG para ignorar todas as redes iSCSI detectadas no momento usando o cmdlet Set-DatabaseAvailabilityGroupNetwork, conforme este exemplo.

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

  2. Desabilite a rede para uso pelo cluster, executando o comando a seguir a partir de um prompt de comando elevado ou uma janela do PowerShell. (Execute Cluster network para exibir os nomes das redes de cluster.)

    Cluster network ClusterNetworkName /prop Role=0

Depois de desabilitar todas as redes iSCSI para uso pelo DAG e seu cluster, é possível forçar a descoberta de rede executando o cmdlet Set-DatabaseAvailabilityGroup com o parâmetro DiscoverNetworks. Se qualquer rede iSCSI continuar sendo mostrada como rede do DAG, remova todas as sub-redes da rede e exclua a rede do DAG.

Retornar ao início

Desligando membros do grupo de disponibilidade de banco de dados

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 com menos perda. Dessa forma, é uma prática recomendável realizar uma alternância de servidor antes de desligar um servidor membro de um DAG. Para instruções detalhadas sobre como realizar uma alternância de servidor, consulte Alternar um Servidor.

Retornar ao início

Instalando pacotes cumulativos de atualizações em membros do grupo de disponibilidade de banco de dados

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 parados durante a instalação, inclusive todos os serviços do Exchange e o serviço de Cluster do Windows. O processo geral para aplicar pacotes cumulativos de atualizações a um membro do DAG da seguinte forma:

  • Realize uma alternância de servidor para que todos os bancos de dados no servidor sejam cópias passivas.
  • Suspenda a ativação para os bancos de dados no servidor que está sendo atualizado.
  • Instale o pacote cumulativo de atualizações.
  • Retome a ativação para os bancos de dados no servidor atualizado.
  • Execute alternâncias de banco de dados conforme necessário.

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

Retornar ao início