.png)
Coexistência de Funções de Servidor de Caixa de Correio e Transporte de Hub ao Usar DAGs
Aplica-se a: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Tópico modificado em: 2010-07-19
O Microsoft Exchange Server 2007 não oferece suporte a funções de servidor Transporte de Hub e Caixa de Correio no mesmo hardware de servidor quando recursos de alta disponibilidade, como SCC (cluster de cópia única) ou CCR (replicação contínua em cluster), são usados. Uma implantação mínima de alta disponibilidade no Exchange 2007 requer quatro servidores: dois nós para alta disponibilidade de caixa de correio e dois servidores Transporte de Hub para redundância de transferência de mensagens.
Para reduzir o número de servidores exigidos para fornecer uma solução de alta disponibilidade, o Exchange Server 2010 suporta funções de servidor Transporte de Hub e Caixa de Correio no mesmo hardware de servidor quando se está utilizando DAGs (grupos de disponibilidade) de banco de dados. O Exchange 2010 fornece um recurso chamado redundância de sombra, que oferece proteção contra perda de dados enquanto mensagens estão em trânsito. Quando utilizados juntos, os DAGs e a redundância de sombra oferecem uma infraestrutura de sistema de mensagens altamente resiliente.
Este tópico enfatiza como a função de servidor Transporte de Hub do Exchange 2010 se comporta quando implantada no mesmo hardware de servidor que o servidor de Caixa de Correio que participa do DAG. Para saber mais sobre DAGs, consulte Noções Básicas Sobre Grupos de Disponibilidade de Banco de Dados.
A redundância de sombra evita perda de dados enquando as mensagens estão em trânsito mantendo uma cópia duplicada da mensagem junto com o caminho da mensagem. Se uma mensagem for perdida em trânsito em razão de falha, a cópia de sombra da mensagem é reenviada pelo componente de Transporte. Para informações detalhadas sobre como a redundância de sombra é implementada, consulte Noções Básicas Sobre Redundância de Sombra.
Os servidores de caixa de correio estão envolvidos durante o envio inicial de mensagens, quando um usuário clica em Enviar, e durante a entrega final, quando a mensagem é salva na Caixa de entrada do destinatário. Quando uma mensagem é enviada para Transporte, a cópia primária dessa mensagem fica nas filas do servidor Transporte de Hub para o qual a mensagem foi enviada. A cópia de sombra dessa mensagem é o item armazenado na pasta Itens enviados do remetente. Quando a mensagem é entregue, a cópia primária fica na Caixa de entrada do destinatário e a cópia de sombra da mensagem é armazenada no dumpster de transporte.
Em uma situação de alta disponibilidade em que as funções de servidor Transporte de Hub e Caixa de Correio coexistem no mesmo hardware de servidor, é crucial tentar evitar que se tenham ambas as cópias de uma mensagem armazenadas no mesmo servidor. Considere a situação de implantação mostrada na figura a seguir. A topologia consiste em dois servidores do Exchange participando de um DAG com a função de servidor Transporte de Hub instalada. Os bancos de dados DB1 e DB2 fazem parte do DAG. Os bancos de dados ativos são mostrados em verde, e os bancos de dados passivos são mostrados em azul.
Nessa topologia, suponha que um usuário cuja caixa de correio está em DB1 envie uma mensagem. Se essa mensagem for enviada para a função de servidor Transporte de Hub no Servidor1, ambas as mensagens primária e de sombra serão fisicamente armazenadas no Servidor1. As mensagens primárias ficarão nas filas do servidor Transporte de Hub, e as mensagens de sombra ficarão na pasta Itens enviados do remetente, como mostrado na figura a seguir.
De maneira similar, se a função de servidor Transporte de Hub no Servidor1 receber uma mensagem destinada a um usuário em DB1, a mensagem é entregue diretamente, e ambas as mensagens primária e de sombra serão fisicamente armazenadas no Servidor1. As mensagens primárias ficarão na Caixa de entrada do remetente, e as mensagens de sombra ficarão no dumpster de transporte, conforme mostrado na figura a seguir. Se uma falha de servidor ocorrer em qualquer uma dessas instâncias, há uma chance de a mensagem ser perdida.
Para evitar essas situações em que uma perda de mensagem pode ocorrer, o Exchange tenta enviar ou entregar mensagens em uma rota que garanta que as cópias primária e de sombra das mensagens sejam armazenadas em servidores físicos diferentes. O comportamento de envio e entrega de mensagem modificada é discutido na seção a seguir.
Quando um usuário cuja caixa de correio está em um banco de dados que é membro de um DAG envia uma mensagem, o serviço de envio de mensagens dá preferência aos servidores Transporte de Hub remotos caso detecte que o servidor Transporte de Hub também está instalado no servidor local. Conforme mostrado na figura "Topologia de alta disponibilidade de dois servidores com funções de servidor Transporte de Hub e Caixa de Correio", se um usuário cuja caixa de correio está em DB1 envia uma mensagem, o serviço de envio de mensagens tentará usar o servidor Transporte de Hub instalado no Servidor2 para envio da mensagem. A figura a seguir mostra esse caminho preferencial de envio de mensagens.
Nos casos em que nenhum outro servidor Transporte de Hub estiver disponível no local (por exemplo, se Servidor2 estiver indisponível em razão de manutenção agendada), o serviço de envio de mensagens retornará o envio da mensagem para o servidor Transporte de Hub local. Embora esse seja um caminho de envio indesejável para redundância, o Exchange não atrasará a entrega das mensagens. Esse caminho de envio de fallback é desejável para disponibilidade e baixa latência de entrega.
O comportamento de entrega e o roteamento da mensagem não mudam na maior parte dos casos. Por exemplo, se o Servidor1 mostrado na figura "Topologia de alta disponibilidade de dois servidores com funções de servidor Transporte de Hub e Caixa de Correio" receber uma mensagem para um destinatário em DB2, ele entregará a mensagem normalmente porque esse banco de dados está ativo em um servidor diferente. A única situação em que um servidor Transporte de Hub processará uma mensagem de entrada de forma diferente será quando a caixa de correio de destino estiver em um banco de dados que faz parte de um DAG e também estiver ativo no servidor local. Como uma entrega direta nessa situação resultaria na mensagem entregue e a cópia no dumpster de transporte no mesmo servidor, o servidor Transporte de Hub reencaminhará essa mensagem para outro servidor Transporte de Hub dentro do mesmo local. A figura a seguir mostra o caminho de entrega da mensagem nessa situação.
No caso em que nenhum outro servidor Transporte de Hub esteja disponível no local, o servidor Transporte de Hub retornará para a entrega local, embora seja um caminho de entrega indesejável para redundância. Novamente, esse caminho de entrega de fallback é desejável para disponibilidade e baixa latência de entrega.
Esta seção explica em detalhes o que acontece em diversas situações de fluxo de mensagens quando as funções de servidor Transporte de Hub e Caixa de Correio coexistem no mesmo servidor. A topologia mostrada na figura a seguir é utilizada para ilustrar as diversas situações possíveis de fluxo de mensagens.
A tabela a seguir mostra como a função de servidor Transporte de Hub no Servidor1 processa mensagens em várias situações. Em todos esses casos, o Servidor1 é considerado o ponto de entrada.
| Localização do remetente | Localização do destinatário | Caminho normal da mensagem | Situações de alta disponibilidade |
|---|---|---|---|
| DB1, ativo no Servidor1 | DB1, ativo no Servidor1 |
|
|
| DB1, ativo no Servidor1 | DB1, ativo no Servidor2 |
|
|
| Externo | DB1, ativo no Servidor1 |
|
|
| Externo | DB1, ativo no Servidor2 |
|
|
A tabela anterior enfatiza a situação mínima em que existem somente dois servidores Transporte de Hub em um local em que ambos coexistem com funções de servidor de Caixa de correio que participam de DAGs. Em implantações mais complexas, em que servidores Transporte de Hub dedicados adicionais estão disponíveis, esses servidores também são utilizados na tomada de decisões de roteamento. Contudo, se você tiver uma implantação grande o suficiente, na qual você pode implantar servidores Transporte de Hub dedicados, uma prática recomendada é não instalar a função de servidor Transporte de Hub em servidores de Caixa de Correio que participam de um DAG.
