Noções básicas sobre grupos de disponibilidade de banco de dados

 

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

Tópico modificado em: 2015-03-09

Um DAG (grupo de disponibilidade de banco de dados) é o componente básico do framework de alta disponibilidade e de resiliência de site integrado ao Microsoft Exchange Server 2010. Um DAG é um grupo de até 16 servidores de Caixa de Correio que hospeda um conjunto de bancos de dados e oferece recuperação automática no nível de banco de dados diante de falhas que afetem servidores ou bancos de dados individuais.

Um DAG é uma fronteira para a replicação de banco de dados de caixa de correio, alternância de banco de dados e servidor e um componente interno do Exchange 2010 chamado Gerenciador Ativo. O Gerenciador Ativo, que é executado em todos os servidores em um DAG, gerencia alternâncias e failovers. Para mais informações sobre o Gerenciador Ativo, consulte Noções Básicas Sobre o Gerenciador de Ativos.

Qualquer servidor em um DAG pode hospedar uma cópia de um banco de dados de caixa de correio de qualquer outro servidor no DAG. Quando um servidor é adicionado a um DAG, funciona com outros servidores no DAG para oferecer recuperação automática de falhas que afetem bancos de dados de caixas de correios, como uma falha de disco ou uma falha do servidor.

Sumário

Ciclo de vida do grupo de disponibilidade de banco de dados

Usando um grupo de disponibilidade de banco de dados para alta disponibilidade

Usando um grupo de disponibilidade de banco de dados para resiliência de site

Experiência de cliente ao usar grupos de disponibilidade do banco de dados

Ciclo de vida do grupo de disponibilidade de banco de dados

Os DAGs utilizam um recurso do Exchange 2010 conhecido como implantação incremental, que é a capacidade de implantar disponibilidade de dados e serviços para todos os servidores de Caixa de Correio e bancos de dados após a instalação do Exchange. Depois de implantar o Exchange 2010, é possível criar um DAG, adicionar servidores de Caixa de Correio ao DAG e replicar os bancos de dados de caixa de correio entre os membros do DAG.

Um DAG é criado usando o cmdlet New-DatabaseAvailabilityGroup. Um DAG é criado inicialmente como um objeto vazio no Active Directory. Esse objeto de diretório é usado para armazenar informações relevantes sobre o DAG, como informações de associação do servidor. Quando você adiciona o primeiro servidor a um DAG, um cluster de failover é criado automaticamente para o 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.

Além de um cluster de failover ser criado, a infraestrutura que monitora os servidores em busca de falhas de rede ou servidor é iniciado. 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.

Durante a criação, cada DAG recebe um nome exclusivo e um ou mais endereços IP estáticos, ou é configurado para usar o protocolo DHCP. Você pode especificar um único endereço IP ou uma lista separada por vírgula de endereços IP usando o parâmetro DatabaseAvailabilityGroupIPAddresses.

Este exemplo mostra um DAG que terá três servidores. Dois servidores (EX1 e EX2) estão na mesma sub-rede (10.0.0.0), e o terceiro servidor (EX3) está em uma sub-rede diferente (192.168.0.0).

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

O cluster de DAG1 é criado quando EX1 é adicionado ao DAG. Durante a criação de cluster, o cmdlet Add-DatabaseAvailabilityGroupServer recupera os endereços IP configurados para o DAG e ignora os que não correspondem a nenhuma das sub-redes encontradas em EX1. Nesse exemplo, o cluster do DAG1 é criado com um endereço IP 10.0.0.5 e 192.168.0.5 é ignorado.

Em seguida, EX2 é adicionado, e o cmdlet Add-DatabaseAvailabilityGroupServer recupera novamente os endereços IP configurados para o DAG. Não são feitas alterações nos endereços IP do cluster, pois EX2 está na mesma sub-rede de EX1.

Em seguida, EX3 é adicionado, e o cmdlet Add-DatabaseAvailabilityGroupServer recupera novamente os endereços IP configurados para o DAG. Como uma sub-rede correspondente a 192.168.0.5 está presente em EX3, o endereço 192.168.0.5 é adicionado como um recurso de endereço IP no grupo do cluster. Além disso, uma dependência OR para o recurso de Nome de Rede de cada recurso de endereço IP é configurada automaticamente. O endereço 192.168.0.5 será usado pelo cluster quando o grupo do cluster for movido para EX3.

O cluster de failover do Windows registra os endereços IP do cluster no DNS (sistema de nomes de domínio) quando o recurso de Nome de Rede é posto online. Além disso, um objeto de nome do cluster (CNO) é criado no Active Directory. O nome, os endereços IP e o CNO do cluster são usados apenas internamente pelo sistema para proteger o DAG e para fins de comunicação interna. Os administradores e os usuários finais não precisam interagir com ou se conectar ao nome do DAG ou ao endereço IP por motivo algum.

Além de um nome e um ou mais endereços IP, o DAG também é configurado para usar um servidor testemunha e um diretório testemunha. O servidor testemunha e o diretório testemunha são especificados automaticamente pelo sistema ou podem ser especificados manualmente pelo administrador.

Por padrão, um DAG é projetado para utilizar o recurso interno de replicação contínua para replicar bancos de dados de caixa de correio entre servidores no DAG. Se você estiver usando uma replicação de dados de terceiros com suporte à API de Replicação de Terceiros no Exchange 2010, o DAG deve ser criado em modo de replicação de terceiros usando o cmdlet New-DatabaseAvailabilityGroup com o parâmetro ThirdPartyReplication. Depois de habilitado, este modo não pode ser desabilitado.

Depois que o DAG é criado, os servidores de Caixa de Correio podem ser adicionados ao DAG. Quando o primeiro servidor é adicionado ao DAG, um cluster é formado para utilização pelo DAG. Os DAGs fazem uso limitado de tecnologias de cluster de failover do Windows, como a pulsação de cluster, as redes de cluster e o banco de dados de cluster (para armazenar dados que mudam, como alterações no estado do banco de dados de ativo para passivo e vice-versa, ou de montado para desmontado e vice-versa). Conforme cada novo servidor é adicionado ao DAG, ele ingressa no cluster subjacente, o modelo de quorum do cluster é ajustado automaticamente pelo sistema e o servidor é adicionado ao objeto do DAG no Active Directory.

Depois que servidores de Caixa de Correio são adicionados a um DAG, várias propriedades do DAG podem ser configuradas, como o uso de criptografia de rede ou compactação de rede para replicação de banco de dados no DAG. Você pode também configurar redes de DAG e criar redes de DAG adicionais.

Depois de adicionar membros a um DAG e configurar o DAG, os bancos de dados de caixa de correio ativos em cada servidor podem ser replicados para os outros membros do DAG. Depois de criar cópias de banco de dados de caixa de correio, você pode monitorar a integridade e o status das cópias usando diversas ferramentas de monitoramento internas. Além disso, é possível realizar alternâncias de banco de dados e servidor.

Para mais informações sobre a criação de DAGs, o gerenciamento de associações do DAG, a configuração de propriedades do DAG, a criação e o monitoramento de cópias de banco de dados de caixa de correio e a realização de alternâncias, consulte Gerenciando a alta disponibilidade e resiliência do site.

Modelos de quorum do grupo de disponibilidade de banco de dados.

Sob cada DAG há um cluster de failover do Windows. Clusters de failover usam o conceito de quorum, que utiliza um consenso de votantes para garantir que apenas um subconjunto dos membros do cluster (o que pode significar todos os membros ou uma maioria dos membros) esteja funcionando ao mesmo tempo. O quorum não é um conceito novo no Exchange 2010. Servidores de Caixa de Correio amplamente disponíveis em versões anteriores do Exchange também usam o cluster de failover e seu conceito de quorum. O quorum representa uma visão compartilhada de membros e recursos e o termo quorum também é usado para descrever os dados físicos que representam a configuração dentro do cluster que é compartilhado entre todos os membros do cluster. Como resultado, todos os DAGs exigem que seu cluster de failover subjacentes tenham quorum. Se o cluster perder quorum, todas as operações DAG se encerram e todos os bancos de dados montados hospedados no DAG irão desmontar. Neste caso, a intervenção do administrador será necessária para corrigir o problema de quórum e restaurar as operações do DAG.

O quorum é importante para garantir a consistência, para agir como desempate para evitar o particionamento e para garantir uma boa resposta do cluster:

• Garantindo a consistência Um requisito primário para um cluster de failover do Windows é que cada membro sempre tenha uma visualização do cluster consistente com a dos outros membros. O grupo de quorum funciona como o repositório definitivo de todas as informações de configuração relacionadas ao cluster. Se o grupo de cluster não puder ser carregado localmente em um membro do DAG, o serviço Cluster não inicia, porque não pode garantir que o membro atenda ao requisito de ter uma visualização do cluster consistente com a de outros membros.

• Agindo como um desempate Um recurso de testemunha de quorum é usado em DAGs com um número par de membros para evitar cenários de síndrome do cérebro dividido, e para garantir que apenas uma coleção dos membros do DAG seja considerada oficial. Quando o servidor testemunha é necessário para o quorum, qualquer membro do DAG que possa se comunicar com o servidor testemunha pode pôr um bloqueio de protocolo SMB no arquivo witness.log do servidor testemunha. O membro do DAG que bloqueia o servidor testemunha (chamado de nó de bloqueio) mantém um voto adicional para fins de quorum. Os membros do DAG em contato com o nó de bloqueio estão em maioria e mantêm quorum. Quaisquer membros do DAG que não possam contatar o nó de bloqueio estão em minoria e portanto perdem quorum.

• Garantindo uma boa capacidade de resposta Para garantir uma boa capacidade de resposta, o modelo de quorum se certifica de que, sempre que o cluster estiver em execução, membros suficientes do sistema distribuído estejam operacionais e comunicativos, e que pelo menos uma réplica do estado atual do cluster possa ser garantida. Não é necessário tempo adicional para fazer os membros se comunicarem ou para determinar se uma réplica específica é garantida.

DAGs com um número par de membros usam modo de quorum Maioria dos Nós e Compartilhamento de Arquivo do cluster de failover, que emprega um servidor testemunha externo que age para desempatar. Nesse modo de quórum, cada membro do DAG conta com um voto. Além disso, o servidor testemunha é usado para fornecer um membro do DAG com uma votação ponderada (por exemplo, ele conta dois votos em vez de um). Os dados de quorum do cluster são armazenados por padrão no disco do sistema de cada membro do DAG e é mantido consistente nesses discos. Entretanto, uma cópia dos dados do quorum não será armazenada no servidor testemunha. Um arquivo no servidor testemunha é usado para manter o controle de qual membro tem a cópia mais atualizada dos dados, mas o servidor testemunha não tem uma cópia dos dados de quorum do cluster. Neste modo, a maioria dos votantes (os membros do DAG somados ao servidor testemunha) deve estar operacional e ser capaz de se comunicar entre si para manter o quorum. Se a maioria dos votantes não puder se comunicar com os outros, o cluster subjacente do DAG perde quorum e o DAG exigirá intervenção administrativa para tornar-se novamente operacional.

Os DAGs com número ímpar de membros usam o modo de quorum Maioria dos Nós do cluster de failover. Neste modo, cada membro tem um voto e o disco de sistema local de cada membro é usado para armazenar os dados de quorum do cluster. Se a configuração do DAG for alterada, essa alteração é refletida nos diferentes discos. A alteração só é considerada como confirmada e realizada de forma persistente se for feita nos discos de metade dos membros (arredondando para baixo) mais um. Por exemplo, em um DAG de cinco membros, a alteração deve ser feita em dois membros mais um, ou três membros no total.

O quorum exige que a maioria dos votantes seja capaz de se comunicar entre si. Considere um DAG com quatro membros. Como este DAG tem um número par de membros, um servidor testemunha externo é usado para fornecer a um dos membros do cluster um quinto voto, para desempate. Para manter uma maioria de votantes (e com isso o quorum), pelo menos três votantes devem ser capazes de se comunicar entre si. A qualquer momento, um máximo de dois votantes podem estar offline sem interromper o serviço e o acesso aos dados. Se três ou mais votantes estiverem offline, o DAG perde quorum e o acesso aos dados e ao serviço é interrompido até o problema ser resolvido.

Voltar ao início

Usando um grupo de disponibilidade de banco de dados para alta disponibilidade

Para ilustrar como um DAG pode oferecer alta disponibilidade aos seus bancos de dados de caixa de correio, considere o exemplo a seguir, que usa um DAG com cinco membros. Esse DAG é ilustrado na figura a seguir.

DAG com cinco membros

Na figura anterior, os bancos de dados verdes são cópias ativas de banco de dados de caixa de correio e os bancos de dados azuis são cópias passivas de banco de dados de caixa de correio. Neste exemplo, as cópias de banco de dados não são espelhadas em cada servidor, mas sim distribuídas em vários servidores. Isso garante que dois servidores do DAG não terão o mesmo conjunto de cópias de banco de dados, dando ao DAG uma maior resiliência a falhas, incluindo as que ocorrem enquanto outros componentes não estão disponíveis como resultado de manutenção regular.

Considere o seguinte cenário, usando o DAG do exemplo anterior, que ilustra resiliências a múltiplas falhas de banco de dados e servidor.

Inicialmente, todos os bancos de dados e servidores têm integridade. É necessário instalar algumas atualizações de sistema operacional no EX2. Você realiza uma alternância de servidor, que ativa a cópia de DB4 em outro servidor de Caixa de Correio. Uma alternância de servidor move todas as cópias de banco de dados de caixa de correio ativas de seu servidor atual para um ou mais servidores de caixa de correio no DAG em preparação para uma interrupção agendada do servidor atual. Uma alternância de servidor pode ser realizada rapidamente com a execução do comando a seguir no Shell de Gerenciamento do Exchange.

Move-ActiveMailboxDatabase -Server EX2

Neste exemplo, há apenas um banco de dados de caixa de correio ativa no EX2 (DB4), portanto apenas uma cópia de caixa de correio ativa é movida. Ao omitir o parâmetro ActivateOnServer no comando anterior, você optou por deixar que o sistema selecionasse a melhor cópia ativa nova possível, e o sistema escolheu a cópia em EX5, como mostra a figura a seguir.

DAG com um servidor offline para manutenção

Enquanto você realiza a manutenção em EX2, EX3 passa por uma falha de hardware catastrófica e fica offline. Antes de ficar offline, EX3 hospedava a cópia ativa de DB2. Para se recuperar da falha, o sistema ativa automaticamente a cópia de DB2 hospedada em EX1 em 30 segundos. Isso é ilustrado na figura a seguir.

DAG com um servidor offline para manutenção e um servidor com falha

Depois que a manutenção agendada é concluída para EX2, você põe o servidor online. Assim que EX2 fica disponível, os outros membros do DAG são notificados, e as cópias de DB1, DB4 e DB5 hospedadas em EX2 são sincronizadas automaticamente com a cópia ativa de cada banco de dados. Isso é ilustrado na figura a seguir.

DAG com servidor restaurado sincronizando suas cópias de bancos de dados

Depois que o componente de hardware com falha de EX3 é substituído por um novo componente, EX3 é posto online. Depois que EX3 fica disponível, os outros membros do DAG são notificados, e as cópias de DB2, DB3 e DB4 hospedadas em EX3 são sincronizadas automaticamente com a cópia ativa de cada banco de dados. Isso é ilustrado na figura a seguir.

DAG com servidor reparado sincronizando suas cópias de bancos de dados

Voltar ao início

Usando um grupo de disponibilidade de banco de dados para resiliência de site

Além de oferecer alta disponibilidade em um data center, um DAG também pode ser ampliado para um ou mais datacenters, em uma configuração que oferece resiliência de site para um ou vários datacenters. Nas figuras do exemplo anterior, o DAG está localizado em um único datacenter e em um único site do Active Directory. A implantação incremental pode ser usada para estender este DAG para um segundo data center (e um segundo site do Active Directory) por implantação da Caixa de Correio e os recursos de suporte necessários (um ou mais servidores do Active Directory e um ou mais servidores de Transporte de Hub e de Acesso para cliente). O servidor de Caixa de Correio é então adicionado ao DAG, como é ilustrado na figura a seguir.

DAG estendido a dois sites do Active Directory

Neste exemplo, uma cópia passiva de cada banco de dados ativo no datacenter Redmond é configurada em EX6 no datacenter Dublin. Entretanto, há muitos outros exemplos de configurações de DAG que oferecem resiliência de site. Por exemplo:

• Em vez de hospedar apenas cópias passivas de banco de dados, o EX6 poderia hospedar todas as cópias ativas, ou poderia hospedar um misto de cópias ativas e passivas.

• Além do EX6, vários membros do DAG poderiam ser implantados no datacenter Dublin, oferecendo proteção contra falhas adicionais. A configuração também oferece capacidade adicional, de modo que se o datacenter Redmond falhar, o datacenter Dublin possa suportar uma população muito maior.

Usando vários grupos de disponibilidade de banco de dados para resiliência de site

No exemplo anterior, um único DAG se estende por vários datacenters, oferecendo resiliência de site para um dos ou ambos os datacenters. Ao usar um único DAG para oferecer resiliência de site em um ambiente no qual cada datacenter para o qual você estende o DAG tem uma população ativa de usuários, há um único ponto de falha na conexão WAN. Isso acontece porque o quorum exige que a maioria dos votantes seja ativa e capaz de se comunicar entre si.

No exemplo anterior, a maioria dos votantes está localizada no datacenter Redmond. Se o datacenter Dublin hospedar bancos de dados de caixa de correio ativos e tiver uma população local de usuários, uma interrupção na WAN resultaria em uma interrupção no serviço de mensagens para os usuários de Dublin. Quando a conectividade WAN é interrompida, apenas os membros do DAG no datacenter Redmond mantêm quorum e continuam oferecendo o serviço de mensagens.

Para eliminar o WAN como ponto único de falha quando precisar oferecer resiliência de site para vários datacenters, cada um com uma população ativa de usuários, é necessário implantar vários DAGs, onde cada DAG tem uma maioria de votantes em um datacenter separado. Quando ocorre uma interrupção de WAN, a replicação é bloqueada até que a conectividade seja restaurada. Os usuários terão o serviço de mensagens, porque cada DAG continua servindo sua população local de usuários.

Voltar ao início

Experiência de cliente ao usar grupos de disponibilidade do banco de dados

DAGs podem ser usados para oferecer alta disponibilidade e resiliência de site. A experiência de cliente ao usar um DAG depende do tipo e da versão do cliente e do protocolo usado pelo cliente para acessar os dados da caixa de correio. Por exemplo, se um failover de banco de dados entre sites ocorrer, o comportamento e a lógica de reconexão usada por um cliente POP3 ou IMAP4 serão diferentes do comportamento e da lógica de reconexão usada por um cliente do Microsoft Outlook 2010.

As seções a seguir descrevem o comportamento e a lógica do cliente em vários cenários. O comportamento descrito presume que:

• O ambiente contém uma única matriz de servidor de Acesso para Cliente em cada site do Active Directory, e cada site contém pelo menos dois servidores de Acesso para Cliente.

• Um balanceador de carga apropriado baseado em hardware ou software está instalado e configurado na frente da matriz do servidor de Acesso para Cliente.

• O planejamento e as configurações apropriadas de namespace e certificados foram concluídos, incluindo os registros DNS necessários.

Comportamento e lógica do Microsoft Outlook

De modo geral, todas as versões do Outlook se comportam do mesmo jeito com failovers de banco de dados que ocorram em um único datacenter e em um único site do Active Directory. Ao contrário de versões anteriores do Exchange, no Exchange 2010, o Outlook não se conecta mais diretamente ao repositório do Exchange no servidor de Caixa de Correio. Em vez disso, o Outlook (e qualquer outro cliente MAPI) se conecta aos serviços de Acesso para Cliente RPC e de Catálogo de Endereços na função de servidor Acesso para Cliente, e o Outlook do usuário é configurado para se conectar à matriz do servidor de Acesso para Cliente, que por sua vez conecta o cliente a um servidor de Acesso para Cliente individual. Essa abstração da conexão do Outlook do servidor de Caixa de Correio oferece os seguintes benefícios:

• Quando ocorre um failover de banco de dados, o Outlook permanece conectado ao mesmo servidor na matriz do servidor de Acesso para Cliente. Quando isso ocorre, o cliente do Gerenciador Ativo em execução no servidor de Acesso para Cliente descobre qual membro do DAG hospeda a cópia ativa do banco de dados a partir do Gerenciador Ativo do DAG. Em seguida, o servidor de Acesso para Cliente se conecta a esse servidor de Caixa de Correio, e o Outlook indica que ele está conectado ao servidor do Exchange.

• Se um dos servidores de Acesso para Cliente na matriz do servidor de Acesso para Cliente ficar indisponível por causa de uma interrupção agendada ou não, os servidores de Acesso para Cliente remanescentes nessa matriz lidarão com a carga do cliente. Como o Outlook é configurado para se conectar à matriz do servidor de Acesso para Cliente e não a um servidor de Acesso para Cliente individual, os membros da matriz do servidor de Acesso para Cliente podem experimentar falhas individualmente ou ser postos offline manualmente sem afetar o perfil do Outlook do usuário. Isso pode acontecer de forma automática (por exemplo, a reconfiguração automática da matriz, com base no monitoramento realizado pela solução de balanceamento de carga na frente da matriz) ou ser realizado manualmente.

Todas as versões do Outlook também se comportam da mesma maneira para alternâncias de banco de dados que ocorram entre dois datacenters e dois sites do Active Directory. As alternâncias de datacenter envolvem a mudança de endereços IP usados por namespaces de acesso para cliente (por exemplo, Microsoft OfficeOutlook Web App, SMTP, POP3, IMAP4, Descoberta Automática, Serviços Web do Exchange ou Acesso para Cliente RPC) de endereços IP no datacenter primário para endereços IP no datacenter secundário. Como resultado, o namespace usado no perfil do Outlook do usuário não muda, e a Descoberta Automática continua a direcionar os clientes ao mesmo namespace de matriz de servidor de Acesso para Cliente.

O comportamento do Outlook após um failover de banco de dados entre sites é diferente do comportamento após um failover de banco de dados em um único site do Active Directory ou após uma alternância de datacenter.

Comportamento de exemplo para versões do Outlook

Os exemplos a seguir ilustram o comportamento do Outlook 2010, do Office Outlook 2007 e do OfficeOutlook 2003 após a ocorrência de um failover de banco de dados entre sites. A topologia usada em cada exemplo é de um DAG com quatro membros estendido para dois sites do Active Directory:  Redmond e Portland. A caixa de correio do usuário está hospedada em DB1, que é replicado para todos os servidores. Em cada exemplo, a cópia ativa de DB1 passa por failover de MBX2 para MBX3.

Topologia de exemplo demonstrando o comportamento do Outlook após um failover de banco de dados entre sites

Cada cliente é configurado com CAS1 como servidor primário, fazendo de Redmond o site de perfil do Outlook. Como os clientes estão localizados em Redmond, a propriedade RPCClientAccessServer de DB1 é configurada para CAS1, fazendo de Redmond o site de banco de dados preferencial. Como DB1 falhou em MBX2 e se tornou ativo em MBX3, Portland é o site de banco de dados montado.

Exemplo para Outlook 2010 e Outlook 2007

Se um servidor de Acesso para Cliente estiver disponível no site Redmond, o Outlook 2010 e o Outlook 2007 continuarão se conectando à matriz de Acesso para Cliente RPC no site Redmond. O servidor de Acesso para Cliente usado pelo cliente irá se comunicar usando RPC MAPI com o servidor de Caixa de Correio do usuário no site Portland.

Se não houver servidores de Acesso para Cliente disponíveis no site Redmond, uma alternância de datacenter de Redmond para Portland terá que ser realizada para restaurar o acesso aos serviços e dados. Para instruções detalhadas sobre como realizar uma alternância de datacenter, consulte Alternar um Servidor.

Exemplo para Outlook 2003

Quando o Outlook 2003 tenta se conectar ao CAS1, ele também recebe uma mensagem de ecWrongServer como resposta. Ao contrário do Outlook 2010 e do Outlook 2007, o Outlook 2003 não inclui o recurso de Descoberta Automática, e precisa usar outros meios para atualizar o perfil do usuário. O redirecionamento de perfil MAPI é o mecanismo usado pelo Outlook 2003. O redirecionamento de perfil MAPI exige que o servidor de origem original esteja online. Se CAS1 não estiver disponível, e se todos os outros servidores de Acesso para Cliente na matriz também não estiverem (ou se a matriz contiver apenas CAS1), o Outlook 2003 não poderá realizar o redirecionamento MAPI nem se conectar ao banco de dados de caixa de correio do usuário sem intervenção manual.

Comportamento e lógica do Outlook quando pastas públicas são usadas

Embora os bancos de dados de pasta pública possam ser hospedados em servidores de Caixa de Correio que sejam membros de um DAG, os bancos de dados de pasta pública não usam replicação contínua, e dependem da replicação de pasta pública para alta disponibilidade. O comportamento de clientes do Outlook reconectando a um banco de dados de pasta pública após um failover de banco de dados de caixa de correio depende não apenas da natureza da falha, mas de suas configurações de replicação de pasta pública e da integridade e atualidade de seus bancos de dados de pasta pública. Como a replicação contínua não pode ser usada com bancos de dados de pasta pública, a alta disponibilidade de bancos de dados de pasta pública é atingida com a implantação de múltiplos bancos de dados de pasta pública configurados para replicarem uns com os outros. É recomendável configurar mais de uma réplica de cada pasta.

Comportamento e lógica de cliente não Outlook

De modo geral, o comportamento de clientes e protocolos que não sejam do Outlook e MAPI varia de acordo com o aplicativo que está sendo usado e com o cenário de falha. De modo geral, assim como no Outlook, os aplicativos e clientes típicos do Exchange (por exemplo, Outlook Web App, Microsoft Exchange ActiveSync, POP3, IMAP4 e Serviços Web do Exchange) se comportam do mesmo jeito com failovers de banco de dados que ocorram em um único datacenter e em um único site do Active Directory. De forma semelhante, todos esses clientes e protocolos (incluindo o SMTP e o Windows PowerShell) se comportam da mesma forma que o Outlook após uma alternância de datacenter.

Se ocorrer um failover de banco de dados entre sites, o comportamento varia entre esses clientes e protocolos. A tabela a seguir lista o comportamento desses clientes.

Comportamento de failover de banco de dados para clientes típicos do Exchange

Cliente ou protocolo	Comportamento
Outlook Web App	Redirecionamento manual. Nesse cenário, o namespace de cliente está mudando de http://mailred.contoso.com para http://mailpdx.contoso.com. Depois de entrar com as credenciais de logon, o usuário é redirecionado para o CAS2 no site Portland por meio de uma página de redirecionamento manual explicando que a URL errada foi usada e que a URL correta é https://mailpdx.contoso.com/owa.
Exchange ActiveSync	Proxy ou redirecionamento. Neste cenário, o comportamento do cliente é determinado pela implementação e pela versão do protocolo do Exchange ActiveSync no dispositivo cliente.
POP3 e IMAP4	Proxy. Este cenário sempre envolve servidor de Acesso para Cliente para proxy do servidor de Acesso para Cliente.
Serviços Web do Exchange	Usa a Descoberta Automática para determinar o novo ponto de extremidade de conexão.

Voltar ao início

 © 2010 Microsoft Corporation. Todos os direitos reservados.