Noções Básicas Sobre Redundância de Sombra

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

Tópico modificado em: 2015-03-09

Altas estratégias de disponibilidade para o Exchange focaram na disponibilidade e recuperação de dados armazenados em bases de dados da caixa de correio. Quando você implementa uma solução altamente disponível para seus servidores de Caixa de correio, as mensagens de e-mail não serão perdidas, e elas podem facilmente ser recuperadas depois de um falha, depois que chegam em uma caixa de correio.

No entanto, essas estratégias não se estendem às mensagens enquanto estiverem em trânsito. Se um servidor de Transporte de Hub falhasse durante o processamento de mensagens e não pudesse ser recuperado, poderia haver perda de dados. À medida que o volume de mensagens processadas por servidores de Transporte de Hub aumenta, a perda potencial de dados torna-se uma preocupação crescente para administradores.

O Microsoft Exchange Server 2007 introduziu o recurso de dumpster de transporte para a função do servidor de Transporte de Hub. Um servidor de Transporte de Hub do Exchange 2007 mantem uma fila de mensagens entregues recentemente aos destinatários cujas caixas de correio estão em um servidor de caixas de correio em cluster. Quando ocorre um failover, o servidor de caixas de correio em cluster solicita automaticamente a cada servidor de Transporte de Hub no site do Active Directory para reenviar a mensagem da fila do dumpster de transporte. Isto impede que os e-mails se percam durante o tempo gasto para que o cluster faça failover. Enquanto este fornece um nível básico de redundância de transporte, só disponível para entrega de mensagem em ambiente de replicação contínua de (CCR)  e não endereça perda potencial de mensagem quando as mensagens estão em trânsito entre servidores de Transporte de Hub e Transporte de Borda.

Exchange Server 2010 O traz o recurso redundância de sombra para fornecer redundância para mensagens durante todo o tempo em que estiverem em trânsito. A solução envolve uma técnica semelhante ao dumpster de transporte. Com a redundância de sombra, a exclusão de uma mensagem dos bancos de dados de transporte é adiada até que o servidor de transporte verifique se todos os saltos seguintes para aquela mensagem foram totalmente entregues. Se qualquer um dos próximos saltos falhar antes de relatar sucesso na entrega, a mensagem será reenviada para entrega para o próximo salto.

A redundância de sombra fornece os seguintes benefícios:

• Elimina a dependência no estado de qualquer servidor de Transporte específico de Hub ou Transporte de Borda. Enquanto existirem caminhos redundantes de mensagem em sua topologia de roteamento, qualquer servidor de transporte se tornará descartável.

• Se um servidor de transporte falha, é possível retirá-lo da produção sem esvaziar suas filas ou mensagens perdidas.

• Se deseja atualizar um servidor de Transporte de Hub ou Transporte de Borda, é possível trazer esse servidor offline a qualquer momento sem o risco de mensagens perdidas.

• Ele elimina a necessidade de redundância de hardware de armazenamento para servidores de transporte.

• Consome menos largura de banda que criar cópias duplicadas de mensagens em servidores múltiplos. O único trânsito adicional de rede gerado com redundância de sombra é a troca de estado de descarte entre servidores de transporte. Status de descarte são as informações que cada servidor de transporte mantém. Indica quando uma mensagem está pronta para ser descartada do banco de dados de transporte.

• Ele oferece resiliência e simplifica a recuperação de uma falha de servidor de transporte.

Redundância de sombra é implementada, estendendo o serviço SMTP. As extensões de serviço permitem que hosts de SMTP negociem suporte de redundância de sombra e troca de estado de descarte para mensagens de sombra.

Procurando tarefas de gerenciamento relacionadas ao gerenciamento de servidores de transporte? Consulte Gerenciando Servidores de Transporte.

Componentes de redundância de sombra

A tabela a seguir fornece descrições de todos os componentes de redundância de sombra.

Componentes de redundância de sombra

Voltar ao início

Fluxo de mensagens de redundância de sombra

Para ilustrar o fluxo de correio com redundância de sombra habilitado, considera o cenário simples onde um servidor de Transporte de Hub envia uma mensagem a um servidor de correio de terceiros via um servidor de Transporte de Borda na rede de perímetro.

Fluxo de mensagens com redundância de sombra

Nesse cenário, o fluxo de mensagens vai pelos seguintes estágios:

1. O servidor de Transporte de Hub entrega uma mensagem ao servidor de Transporte de Borda.

   1. O servidor de Transporte de Hub abre uma sessão de SMTP com o servidor de Transporte de Borda.

   2. O servidor de transporte de Borda anuncia o suporte de redundância de sombra.

   3. O servidor de Transporte de Hub notifica o servidor de Transporte de Borda para controlar estado de descarte.

   4. O servidor de transporte de Hub envia a mensagem para o servidor de transporte de Borda.

   5. O servidor de Transporte de Borda confirma o recebimento da mensagem e registra a identidade do servidor de Transporte de Hub para enviar informações de descarte para a mensagem.

   6. O servidor de Transporte de Hub move a mensagem à fila de sombra para o servidor de Transporte de Borda e marca o servidor de Transporte de Borda como o servidor principal. O servidor de transporte de Hub se torna o servidor de sombra.

2. O servidor de transporte de Borda envia a mensagem para o próximo salto.

   1. O servidor de Transporte de Borda envia a mensagem para um servidor de email de terceiros.

   2. O servidor de email de terceiros confirma o recebimento da mensagem.

   3. O servidor de Transporte de Borda atualiza o estado de descarte para a mensagem como entrega completa.

3. O servidor de Transporte de Hub consulta o servidor de Transporte de Borda para estado de descarte (caso de êxito).

   1. No fim de cada sessão de SMTP com o servidor de Transporte de Borda, o servidor de Transporte de Hub consulta o servidor de Transporte de Borda para estado de descarte em mensagens previamente submetidas. Se o servidor de Transporte de Hub não abriu quaisquer sessões de SMTP com o servidor de Transporte de Borda depois da submissão inicial de mensagem, ele abrirá uma sessão de SMTP com o servidor de Transporte de Borda para consultar apenas o estado de descarte depois de um tempo específico.

   2. O servidor de Transporte de Borda verifica o estado de descarte local e envia de volta a lista de mensagens que foi entregue, e retira as informações de descarte.

   3. O servidor de Transporte de Hub exclui a lista de mensagens de sua fila de sombra.

4. O servidor de Transporte de Hub consulta o servidor de Transporte de Borda para estado de descarte e submete a mensagem (caso de falha).

   1. Se o servidor de Transporte de Hub não pudere contatar o servidor de Transporte de Borda, o servidor de Transporte de Hub reinicia a função do servidor principal e apresenta de novo as mensagens na fila de sombra.

   2. As mensagens reenviadas são entregues a outro servidor de Transporte de Borda e o fluxo de trabalho inicia a etapa 1.

      Dica

      Se não há rotas alternativas disponíveis para uma mensagem de sombra (como o segundo servidor de Transporte de Borda mostrou na figura anterior), não será reenviado, mas permanece na fila de sombra.

Para obter mais informações sobre fluxo de mensagens com vários cenários diferentes, consulte Cenários de fluxo de correio de redundância de sombra.

Vários cenários de salto

Se uma mensagem viaja por vários servidores que suportam redundância de sombra, as mensagens de sombra são retidas em um servidor somente até que o próximo servidor no caminho de mensagem confirme a entrega. Para ilustrar como isto funciona, considere uma organização que tem cinco sites Active Directory com servidores de Transporte de Hub instalados. Os sites são ligados um ao outro conforme mostrado na figura a segur. A organização tem sites em Nova Iorque e Londres configurados como sites de hub, então as mensagens de Chicago ou Atlanta precisam passar por servidores de Transporte de Hub  nos sites de Nova Iorque e Londres para chegar ao site de Dublin.

Topologia de exemplo para vários cenários de salto

Presuma que uma mensagem é enviada por um operador no site de Chicago a um operador no site de Dublin. Esta mensagem deverá viajar pelo site de Nova Iorque e Londres para chegar a Dublin. Nesse caso, ocorre o seguinte:

1. O servidor de Transporte de Hub em Chicago enviará a mensagem ao servidor de Transporte de Hub em Nova Iorque, e reterá uma cópia de sombra da mensagem.

2. O servidor de Transporte de Hub de Nova Iorque enviará a mensagem ao servidor de Transporte de Hub em Londres e consulta um estado de descarte para o hub de Chicago.

3. O hub de Chicago consulta o hub de Nova Iorque para estado de descarte e recebe a notificação de descarte para a mensagem. Neste momento, ele pode remover a mensagem de sombra do seu banco de dados. Se a mensagem foi entregue de Londres a Dublin não tem um impacto de quando o servidor de Chicago exclui a mensagem de sombra.

Proteção de redundância de sombra quando funções de servidor de Transporte de Hub e Caixa de Correio coexistem com DAGs

Ao usar grupos de disponibilidade de banco de dados (DAGs), as mensagens que já foram enviadas aos bancos de dados da caixa de correio são protegidas com a arquitetura DAG. Para cada mensagem entregue a um banco de dados da caixa de correio que faça parte de um DAG, a cópia de sombra dessa mensagem é retida no dumpster de transporte até que seja replicada para todos os membros do DAG. Da mesma, qualquer mensagem enviada aos servidores de Transporte de Hub por um membro do DAG tem duas cópias, uma na fila do servidor de Transporte de Hub aguardando entrega e uma cópia de sombra na pasta Itens Enviados do remetente. Essa abordagem é um elemento crucial da redundância de sombra.

Porém, quando as funções de servidor de Transporte de Hub e de Caixa de Correio coexistem no mesmo servidor e você tem bancos de dados de caixa de correio que fazem parte de um DAG, os servidores de Transporte de Hub podem ter de rotear uma mensagem através de um salto extra para evitar que a mensagem principal e a mensagem de sombra estejam no mesmo hardware de servidor. Especificamente, a função de servidor de Transporte de Hub tenta evitar os dois cenários descritos a seguir porque a falha de um único servidor possa resultar em perda da mensagem principal e da mensagem de sombra:

• Durante a entrega da mensagem, quando o banco de dados da caixa de correio ativa do destinatário da mensagem e o dumpster de transporte contendo a cópia de sombra da mensagem estiverem no mesmo servidor Para evitar esse cenário, o servidor de Transporte de Hub roteia a mensagem por outro Servidor de Transporte de Hub dentro do site para garantir que a mensagem de sombra acabe em um hardware de servidor diferente. Entretanto, se não houver outros servidores de Transporte de Hub disponíveis, ele entregará a mensagem diretamente.

• Durante o envio da mensagem, quando a fila de transporte que contém a mensagem principal e a mensagem de sombra na pasta Itens Enviados do remetente estiverem no mesmo servidor   Para evitar esse cenário, o driver de repositório escolhe outros servidores de Transporte de Hub no site para envio da mensagem. Entretanto, se não houver outros servidores de Transporte de Hub disponíveis no site, ele entregará a mensagem ao servidor de Transporte de Hub local.

Para obter mais informações sobre coexistência de funções de servidor Transporte de Hub e Caixa de Correio ao usar DAGs, consulte Coexistência de Funções de Servidor de Caixa de Correio e Transporte de Hub ao Usar DAGs.

Interoperabilidade

Se uma redundância de sombra for usada ou não é decidido enquanto estabelece uma nova conexão SMTP. Se ambos os servidores em uma conexão SMTP suportarem redundância de sombra, o fluxo de trabalho mencionado previamente é usado. No entanto, haverá situações onde os servidores de transporte do Exchange 2010 trocam mensagens com servidores de correio que não suportam redundância de sombra. Estes podem ser servidores de correio de terceiros, versões anteriores do Exchange,ou uma organização do Exchange 2010 que não habilitou redundância de sombra.

Quando um servidor de transporte do Exchange 2010 que suporta redundância de sombra estabelece uma conexão com um servidor que não suporta redundância de sombra, os seguintes acontecimentos acontecem:

1. Exchange estabelece uma conexão SMTP para o servidor de destino.

2. O servidor de destino não anuncia o suporte à redundância de sombra.

3. Uma vez que o servidor de destino não suporta redundância, o Exchange executará o seguinte para cada mensagem:

   1. Entregar a mensagem para o servidor de destino.

   2. O Gerente de Redundância de Sombra marcará que a mensagem é entregue ao próximo salto.

   3. Exclua a mensagem depois que é entregue a todos os saltos.

Quando um servidor que não suporta redundância de sombra estabelece uma conexão com um servidor Exchange 2010, os seguintes eventos acontecem:

1. O servidor de envio estabelece uma conexão SMTP com Exchange.

2. Exchange O  anuncia suporte de redundância de sombra.

3. O servidor remetente não suporta redundância de sombra e portanto ele não a usará. Ele fornecerá mensagens para o servidor de Exchange.

4. Para cada mensagem que o Exchange receber, ele fará o seguinte:

   1. Entrega a mensagem ao próximo salto, ou faz uma cópia de sombra do mesmo.

   2. Envia confirmação de recebimento para o servidor de envio.

Atraso de Reconhecimento

O princípio principal atrás da redundância de sombra mantem uma cópia da mensagem no salto prévio até que o servidor verifica se ela foi entregue com êxito a todos os próximos saltos. Isto não é possível quando um servidor de transporte do Exchange 2010 recebe uma mensagem de um servidor de correio que não suporta redundância de sombra. Este servidor de correio pode ser um servidor Exchange executando uma versão mais antiga do Exchange, um cliente normal de SMTP, ou um servidor de correio do Exchange na Internet. Neste caso, as tentativas do Exchange para realizar redundância de sombra atrasando a confirmação ao servidor de correio até que verifica que a mensagem com êxito foi entregue com êxito a todos os próximos saltos internamente. Desta maneira, se o servidor do Exchange 2010 falhar, o servidor de envio de correio irá presumir que a mensagem nunca foi entregue ao Exchange e tentará entregar novamente.

No entanto, a entrega da mensagem para os próximos saltos pode levar um longo tempo devido à complexidade de sua infraestrutura de roteamento, ou a falha de um dos próximos saltos. Neste caso, para impedir a sessão de SMTP a partir do tempo limite, o servidor de transporte do Exchange 2010 irá enviar um aviso ao servidor de correio de envio. Neste caso, a redundância de email não é garantida, mas é um melhor esforço. Por exemplo, uma mensagem pode ser perdida na seguinte situação: Um servidor de email da Internet transmite uma mensagem para um servidor de transporte de borda. O servidor de Transporte de Borda não pode se comunicar com o servidor de Transporte de Hub devido a um problema de rede e confirma o recebimento da mensagem para o servidor de email da Internet. O servidor de Transporte de Borda, em seguida, falha e não pode ser recuperado antes que o problema da rede seja resolvido. Neste ponto, a mensagem é perdida.

O valor de tempo de inativideade de reconhecimento de retardo é controlado pelo atributo MaxAcknowledgementDelay de cada conector de recebimento. O valor padrão é 30 segundos. Para saber mais sobre esse recurso, consulte Configurar Redundância de Sombra.

Ignorando o atraso de confirmação

Há casos em que é improvável que uma mensagem seja entregue antes do tempo limite de atraso de confirmação seja atingido. Nesses casos, o servidor de transporte usa um dos seguintes métodos para lidar com as mensagens:

• Ignorando o atraso de confirmação Por padrão, o servidor de transporte ignora o atraso de confirmação para manter a taxa de transferência de recepção de SMTP. Basicamente, o servidor de transporte emite uma confirmação antes que o tempo limite seja atingido.

• Promoção de redundância de sombra No Microsoft Exchange Server 2010 Service Pack 1 (SP1), em vez de ignorar o atraso de confirmação, o servidor de transporte pode ser configurado para retransmitir a mensagem para qualquer outro servidor de transporte no site. Isso efetivamente insere a mensagem no pipeline de redundância de sombra, protegendo-a. Esse processo é chamado de promoção de redundância de sombra. Essa abordagem minimiza o número de mensagens desprotegidas na organização em comparação com o método de ignorar o atraso de confirmação. Por padrão, essa recurso está desabilitado. Para habilitar a promoção de redundância de sombra, um administrador deve editar o arquivo Edgetransport.exe.config file, alterar a chave shadowredundancypromotionenabled para true, salvar as alterações no arquivo e reiniciar o serviço de Transporte do Microsoft Exchange (MSExchangeTransport.exe). Para obter mais informações sobre como fazer isso, consulte a seção “Habilitar Promoção de Redundância de Sombra“ no tópico Configurar Redundância de Sombra.

As tabelas a seguir relacionam quatro cenários diferentes nos quais um servidor de transporte ignora o atraso de confirmação e como um servidor do Exchange 2010 lida com esse cenário.

Voltar ao início

Gerenciador de redundância de sombra

O Gerenciador de redundância de sombraExchange 2010 é o componente central de um servidor de transporte do responsável pela gestão de redundância de sombra.

O Gerenciador de redundância de sombra é responsável por manter as seguintes informações para todas as mensagens principais que um servidor está processando atualmente:

• O servidor de sombra para cada mensagem principal que está sendo processado.

• O status de descarte a ser enviado a servidores de sombra.

O Gerenciador de redundância de sombra é responsável pelo seguinte para todas as mensagens de sombra que um servidor tem em suas filas de sombra:

• Manter a lista de servidores principais para cada mensagem de sombra.

• Verificar a disponibilidade de cada servidor principal para o qual uma mensagem de sombra é colocada na fila de espera.

• Processamento de notificações de descarte de servidores principais.

• Remover as mensagens de sombra no banco de dados depois que todas as notificações de descarte esperadas forem recebidas.

• Decidir quando o servidor de sombra deve tomar posse de mensagens de sombra, tornando-se um servidor principal.

Além disso, o Gerenciador de redundância de sombra também é responsável pela gestão dos contadores de desempenho relacionados com a redundância de sombra.

Pulsação

O Gerenciador de redundância de sombra utiliza pulsação para determinar a disponibilidade dos servidores para os quais as mensagens de sombra são enfileiradas. Durante a sessão de SMTP entre dois servidores que suportam redundância de sombra, o servidor que inicia a conexão consulta o servidor de destino para estado de descarte das mensagens enviadas anteriormente ao servidor. O servidor de início realiza isso emitindo um comando XQUERYDISCARD. Em resposta, o servidor de destino retorna as notificações de descarte. Este intercâmbio entre os dois servidores é usado como a pulsação para redundância de sombra.

Há um valor de tempo limite para a pulsação. Se nenhuma conexão for estabelecida para um servidor para o qual o Gerenciador de redundância de sombra está mantendo uma fila de sombra para esse período, o servidor tentará estabelecer uma conexão SMTP com o servidor principal especificamente para consultar o estado de descarte e zerar o cronômetro. O valor de tempo limite é controlado pelo parâmetro ShadowHeartbeatTimeoutInterval do cmdlet Set-TransportConfig. O valor padrão desse parâmetro é de 300 segundos na versão RTM (versão de produção) do Exchange 2010, e de 900 segundos no Exchange 2010 SP1.

Se o servidor não puder estabelecer uma conexão com um servidor principal quando o valor de tempo limite é atingido, ele irá zerar o cronômetro e tentar novamente. Se o valor de tempo limite for atingido doze vezes consecutivas (três vezes consecutivas no Exchange 2010 RTM), o servidor irá concluir que o servidor principal falhou e vai assumir a propriedade das mensagens de sombra e começar a gerar notificações para se desfazer delas para enviar para o servidor principal que falhou. O número de tempos limites que um servidor irá esperar antes de decidir se um servidor principal não é controlado pelo parâmetro do ShadowHeartbeatRetryCount cmdlet Set-TransportConfig.

Para saber mais sobre como configurar a pulsação da redundância de sombra, consulte Configurar Redundância de Sombra.

Voltar ao início

Processamento da mensagem após uma paralisação

A redundância de sombra minimiza a perda de mensagem devido a Interrupções de servidor. Quando um servidor de transporte volta a ficar online após uma interrupção, há dois cenários:

• O servidor volta a ficar on-line com um banco de dados de transporte novos   Neste cenário, o banco de dados de transporte é irrecuperável, devido à corrupção de dados ou falha de hardware. Neste caso, porque o servidor de transporte terá um novo banco de dados de identificação, que será reconhecido como uma nova rota de transporte dos servidores na organização. Isto também se aplica à situação em que um servidor não pôde ser recuperado, e um novo servidor foi configurado como uma substituição.

• O servidor volta a ficar on-line com o mesmo banco de dados de transporte   Neste cenário, o servidor de transporte especial não falhou, mas estava off-line por um longo período de tempo. Por exemplo, uma falha na placa de rede, ou um tempo de manutenção no servidor causaria este cenário.

A tabela abaixo resume como o transporte reage a esses dois cenários quando a redundância de sombra é habilitada. Para maior clareza, suponha que o servidor que teve uma interrupção é nomeado Hub01.

Processamento de mensagens em cenários de recuperação

Voltar ao início

Direitos estendidos necessários para redundância de sombra

Exchange 2010 O apresenta os dois direitos estendidos a seguir, necessários para redundância de sombra:

• ms-Exch-SMTP-Accept-XSHADOW

• ms-Exch-SMTP-Send-XSHADOW

Quando uma conexão SMTP é estabelecida com um servidor de transporte do Exchange 2010, ele anunciará suporte de redundância de sombra se o direito estendido do ms-Exch-SMTP-Accept-XSHADOW existe no conector de Recebimento a ser usado. Além disso, o mecanismo de autenticação em um conector de Recebimento deve ser a autenticação do Servidor do Exchange ou Protegido Externamente.

Quando um servidor de transporte do Exchange 2010 estabelece uma conexão SMTP com outro servidor que anuncia o suporte de redundância de sombra, ele emitirá um comando XSHADOW apenas se a sessão tiver concedido o direito estendido do ms-Exch-SMTP-Send-XSHADOW.

Por padrão, esses direitos estendidos são concedidos ao grupo de Servidores do Exchange de todos os conectores internos de Envio e conectores de Recebimento.

Voltar ao início

 © 2010 Microsoft Corporation. Todos os direitos reservados.