Compartilhar via

Cenários de fluxo de correio de redundância de sombra

  • Artigo

Aplica-se a: Exchange Server 2010

Tópico modificado em: 2009-10-20

O recurso redundância de sombra do Microsoft Exchange Server 2010 fornece redundância para as mensagens durante todo o tempo em que estiverem em trânsito. O fluxo de emails no geral é explicado em Noções Básicas Sobre Redundância de Sombra. Este tópico explica detalhadamente o que acontece em cada cenário de fluxo de mensagens que pode envolver o Exchange.

Cenários de fluxo de email

A imagem a seguir mostra todos os cenários de redundância possíveis em uma organização do Exchange e como a redundância da mensagem é obtida em cada cenário. A área sombreada mostra onde a redundância de sombra está em vigor. A redundância de sombra do Exchange 2010 evita a perda de dados enquanto as mensagens estão em trânsito na área sombreada.

Dica

Os servidores Acesso para Cliente foram omitidos da imagem para fins de simplificação.

Cenários de fluxo de email com redundância de sombra
Cenários de fluxo de mensagens de redundância de sombra

Como foi possível observar na imagem anterior, todos os caminhos do fluxo de emails em uma organização do Exchange correspondem a um dos seguintes cenários:

A. Envio do cliente MAPI/Windows Mobile

B. Fluxo de email do servidor de Caixa de Correio para o servidor de Transporte de Hub

C. Entrega de mensagem do servidor de Transporte de Hub para o servidor de Caixa de Correio

D. Fluxo de email entre Servidores de Transporte do Exchange 2010

E. Fluxo de email dos Servidores de Transporte do Exchange 2010 para Servidores de Email que não oferecem suporte a redundância de sombra

F. E. Fluxo de email dos Servidores de Email que não oferecem suporte a redundância de sombra para os Servidores de Transporte do Exchange

As seções a seguir explicam o que acontece em cada cenário de fluxo de email.

A. Envio do cliente MAPI/Windows Mobile

Os envios de mensagens de clientes MAPI ou Windows Mobile não são redundantes. Após o armazenamento bem-sucedido da mensagem em um servidor de Caixa de Correio, os recursos de alta disponibilidade do Exchange entram em vigor e ajudam a evitar a perda de dados. Esse cenário fornece uma visão completa do fluxo de mensagens, do começo ao fim.

Retornar à lista de cenários de fluxo de email

B. Fluxo de email do servidor de Caixa de Correio para o servidor de Transporte de Hub

As ações a seguir ocorrem quando um servidor de Caixa de Correio do Exchange 2010 envia mensagens para um servidor de Transporte de Hub do Exchange 2010.

Importante

Os servidores de caixa de correio do Exchange 2010 não podem se comunicar com servidores de transporte que estão executando versões anteriores do Exchange. Portanto, este tópico discute apenas o fluxo de email de um servidor de Caixa de Correio do Exchange 2010 para um servidor de Transporte de Hub do Exchange 2010.

  1. O serviço de envio de email notifica o servidor de Transporte de Hub que há uma nova mensagem.
  2. O servidor de Transporte de Hub pega a mensagem da Caixa de Saída da caixa de correio enviando-a e armazenando-a em seu banco de dados.
  3. Se a mensagem tem destinatarios em servidores de Caixa de Correio que são os mesmo do site do Active Directory, o servidor de Transporte de Huv entrega a mensagem para as caixas de correio de destino, seguindo as etapas listadas no cenário C. Para todos os outros destinatários, o servidor de Transporte de Hub entrega a mensagem para o próximo salto.
  4. Após a conclusão da entrega para o próximo salto, o servidor de Transporte de Hub notifica o servidor de Caixa de Correio que está encerrado o processamento da mensagem e que ele assumiu a propriedade da mensagem. Após essa notificação, a mensagem é excluída da Caixa de Saída.
  5. Se nenhum outro salto da mensagem suportar redundância de sombra, o servidor de Transporte de Hub exclui a mensagem. Caso contrário, a mensagem será convertida em uma mensagem de sombra quando armazenada nas filas de sombra dos saltos para os quais é entregue a mensagem.

Retornar à lista de cenários de fluxo de email

C. Entrega de mensagem do servidor de Transporte de Hub para o servidor de Caixa de Correio

As ações a seguir ocorrem quando um servidor de Transporte de Hub do Exchange 2010 envia mensagens para um servidor de Caixa de Correio do Exchange 2010.

Importante

Os servidores de Transporte de Hub do Exchange 2010 não podem se comunicar com servidores de Caixa de Correio que estão executando versões anteriores do Exchange. Portanto, este tópico discute apenas o fluxo de email de um servidor de Transporte de Hub do Exchange 2010 para um servidor de Caixa de Correio do Exchange 2010.

  1. O servidor de Transporte de Hub entrega a mensagem para as caixas de correio de destino.
  2. Após a entrega da mensagem para todas as caixas de correio de destino, o servidor de Transporte de Hub adiciona a mensagem no dumpster de transporte.
  3. O servidor de Transporte de Hub enfileira notificações de descarte para os saltos que receberam a mensagem. Essas notificações de descarte são criadas quando o salto consulta o servidor de Transporte de Hub.
  4. O salto anterior exclui a mensagem de sombra correspondente.

Retornar à lista de cenários de fluxo de email

D. Fluxo de email entre Servidores de Transporte do Exchange 2010

O processo de fluxo de email é idêntico para todas as trocas de mensagens entre servidores de transporte que executam o Exchange 2010, seja entre dois servidores de Transporte de Hub ou entre um servidor de Transporte de Hub e um servidor de Transporte de Borda. As ações a seguir ocorrem quando uma mensagem é transferida de um servidor de transporte do Exchange 2010 para outro. Para fins de esclarecimento, suponhamos que o nome do servidor que está enviando a mensagem seja Hub01 e o nome do servidor que está recebendo a mensagem seja Borda01.

  1. O Hub01 estabelece uma conexão SMTP com o Borda01.
  2. O Borda01 anuncia suporte a redundância de sombra.
  3. O Hub01 solicita a redundância de sombra na sessão SMTP emitindo o comando XSHADOW. O processo é similar ao de estabelecimento da Segurança de Camada de Transporte (TLS) em uma sessão SMTP.
  4. Para cada mensagem que o Hub01 precisa enviar para o Borda01:
    1. O Hub01 transmite a mensagem para o Borda01+.
    2. O Borda01 marca a mensagem como sombreada por Hub01.
    3. O Hub01 marca o Borda01 como o servidor primário e o adiciona em sua fila de sombra para o Borda01.
    4. O Hub01 prepara notificações de descarte para a mensagem que será enviada ao salto do qual recebeu a mensagem.
  5. O Hub01 consulta o Borda01 para saber o status de descarte das mensagens previamente enviadas para o Borda01.
  6. O Borda01 envia todas as notificações de descarte que foram preparadas para o Hub01. Elas poderiam ser para mensagens enviadas na mesma sessão SMTP ou para aquelas que foram enviadas durante sessões SMTP anteriores.
  7. O Hub01 exclui todas as mensagens de sombra para as quais o Borda01 enviou uma notificação de descarte.

Retornar à lista de cenários de fluxo de email

E. Fluxo de email dos Servidores de Transporte do Exchange 2010 para Servidores de Email que não oferecem suporte a redundância de sombra

Nem servidores de transporte do Exchange Server 2007 nem servidores bridgehead do Exchange Server 2003 suportam redundância de sombra. Portanto, se você tiver um cenário de coexistência com versões anteriores do Exchange, os recursos de redundância do Exchange 2010 poderão garantir a entrega de mensagens somente até o salto do Exchange herdado, e não todo o caminho até seu destino. O mesmo se aplica ao cenário em que os servidores de Transporte de Borda do Exchange 2010 enviam mensagens para servidores de email não relacionados ao Exchange.

As seguintes ações ocorrem quando um servidor de Transporte de Hub do Exchange 2010 envia uma mensagem para um servidor de transporte do Exchange que está executando uma versão anterior do Exchange ou quando um servidor de Transporte de Borda do Exchange 2010 envia uma mensagem para um servidor de email não relacionado ao Exchange. Para esclarecer, suponhamos que um servidor de Transporte de Hub do Exchange 2010 chamado Hub01 esteja enviando uma mensagem para um servidor de transporte mais antigo do Exchange, chamado Herdado01.

  1. O Hub01 estabelece uma conexão SMTP com o Herdado01.
  2. O Herdado01 não anuncia o suporte à redundância de sombra.
  3. Como o Herdado01 não anuncia a redundância de sombra, o Hub01 não inicia a redundância de sombra na sessão SMTP.
  4. O Hub01 entrega a mensagem para o Herdado01.
  5. O Hub01 exclui a mensagem.
  6. O Hub01 prepara notificações de descarte para o salto do qual recebeu a mensagem.

Retornar à lista de cenários de fluxo de email

E. Fluxo de email dos Servidores de Email que não oferecem suporte a redundância de sombra para os Servidores de Transporte do Exchange

Existem quatro pontos de entrada para uma organização do Exchange na qual um servidor de email que não oferece suporte a redundância de sombra pode estabelecer uma conexão SMTP com um servidor de transporte do Exchange 2010 e pode enviar mensagens.

  • Servidor de Unificação de Mensagens (UM) do Exchange 2010 conectando-se a um servidor de Transporte de Hub do Exchange 2010.
  • Servidor de transporte do Exchange que está executando o Exchange 2007 ou o Exchange 2003 e se conectando a um servidor de Transporte de Hub do Exchange 2010.
  • Servidor de email não relacionado ao Exchange na Internet conectando-se a um servidor de Transporte de Borda do Exchange 2010.
  • Servidor de email não relacionado ao Exchange na organização, como um servidor UNIX, ou um cliente SMTP que está enviando mensagens para um servidor de Transporte de Hub do Exchange 2010.

Nesse cenário, o Exchange 2010 consegue a redundância de sombra usando um recurso chamado atraso de confirmação. Quando um servidor de transporte do Exchange 2010 recebe uma mensagem de um servidor de email que não oferece suporte a redundância de sombra, ele atrasa enviando uma confirmação para o servidor de email de envio até que ele confirme que a mensagem foi entregue com sucesso ao seu destino. Para obter mais informações sobre atraso de confirmação, consulte Noções Básicas Sobre Redundância de Sombra.

Para ilustrar essa situação, suponha que um servidor de Transporte de Borda do Exchange 2010, chamado Borda01, esteja recebendo uma mensagem de um servidor de email do Exchange na Internet chamado Internet01. Neste exemplo, as seguintes ações ocorrem:

  1. O Internet01 estabelece uma conexão SMTP com o Borda01.

  2. O Borda01 anuncia suporte a redundância de sombra.

  3. Como o Internet01 não oferece suporte a redundância de sombra, ele simplesmente envia a mensagem para o Borda01.

  4. O Borda01 marca a mensagem como uma mensagem com atraso de confirmação.

  5. O Borda01 entrega a mensagem para os próximos saltos usando as etapas abordadas no cenário D.

  6. O Borda01 consulta os próximos saltos para status de descarte da mensagem.

  7. Depois que o Borda01 recebe notificações de descarte de todos os saltos seguintes, ele envia a confirmação para o Internet01.

  8. O Borda01 exclui a mensagem de seu banco de dados.

    Dica

    Se o Borda01 não puder verificar a entrega bem-sucedida da mensagem para todos os saltos seguintes dentro de 30 segundos, ele atingirá o tempo-limite e enviará uma confirmação para o Internet01. Esse tempo-limite é controlado pelo valor do atributo MaxAcknowledgementDelay do conector de Recebimento.

Retornar à lista de cenários de fluxo de email