Redundância de sombra

Aplica-se a: Exchange Server 2013

A redundância de sombra foi introduzida no Microsoft Exchange Server 2010 para fornecer cópias redundantes de mensagens antes de serem entregues em caixas de correio. No Exchange 2010, a redundância de sombra atrasou a exclusão de uma mensagem do banco de dados de transporte em um servidor de transporte até que o servidor verificasse o próximo salto na entrega concluída do caminho de entrega da mensagem. Se o próximo salto falhou antes de relatar a entrega bem-sucedida de volta ao servidor de transporte, o servidor de transporte reenviou a mensagem para o próximo salto. Os servidores do Exchange 2010 usaram o verbo XSHADOW para anunciar seu suporte à redundância de sombra. Se um servidor SMTP não suportasse redundância de sombra, o Exchange 2010 usava a confirmação atrasada com base em um intervalo de tempo configurado no conector de recebimento para fazer uma cópia redundante da mensagem.

A principal melhoria na redundância de sombra no Microsoft Exchange Server 2013 é que o servidor de transporte agora faz uma cópia redundante de todas as mensagens recebidas antes de confirmar o recebimento bem-sucedido da mensagem de volta para o servidor de envio. O suporte do servidor de envio ou a falta de suporte para redundância de sombra não importa. Isso ajuda a garantir que todas as mensagens no pipeline de transporte do Exchange 2013 sejam redundantes enquanto estiverem em trânsito. Se o Exchange 2013 determinar que a mensagem original foi perdida em trânsito, a cópia redundante da mensagem será entregue novamente.

Componentes de redundância de sombra

A tabela a seguir descreve os componentes da redundância de sombra. Esses termos são usados em todo o tópico.

Requisitos para redundância de sombra

Embora possa parecer óbvio, a redundância de sombra requer vários servidores de Caixa de Correio do Exchange 2013. O servidor de Caixa de Correio pode ser servidores autônomos ou servidores de Caixa de Correio e servidores de Acesso para Cliente instalados no mesmo computador.

• Se o servidor de Caixa de Correio não for membro de um DAG, os outros servidores de Caixa de Correio deverão estar no site local do Active Directory.
• Se o servidor de Caixa de Correio for membro de um DAG, os outros servidores de Caixa de Correio deverão pertencer ao mesmo DAG. Os outros servidores de Caixa de Correio que pertencem ao DAG podem estar no site local do Active Directory ou em um site remoto do Active Directory. Se o DAG abranger vários sites do Active Directory, a redundância de sombra prefere criar uma cópia redundante da mensagem em um site remoto do Active Directory para resiliência do site.

Estas são as situações em que a redundância de sombra não pode proteger as mensagens em trânsito:

• Em ambientes de servidor Exchange individuais.
• Em DAGs subprovisionados.
• Durante a falha simultânea de dois ou mais servidores de transporte envolvidos na redundância de sombra de uma mensagem.

A redundância de sombra está habilitada por padrão

Por padrão, a redundância de sombra é habilitada globalmente no serviço de transporte em todos os servidores de caixa de correio usando o parâmetro ShadowRedundancyEnabled no cmdlet Set-TransportConfig . Por padrão, se o serviço de Transporte em um servidor de Caixa de Correio não puder criar uma cópia redundante de uma mensagem, a mensagem não será rejeitada. No entanto, você pode configurar o Exchange 2013 para rejeitar uma mensagem se uma cópia redundante da mensagem não for criada usando o parâmetro RejectMessageOnShadowFailure no cmdlet Set-TransportConfig . A mensagem é rejeitada com uma falha transitória, mas o servidor remetente pode transmitir a mensagem novamente. O código de resposta SMTP é 451 4.4.0 Message failed to be made redundant. : Você deve configurar o Exchange 2013 para rejeitar mensagens que não podem ser redundantes somente quando sua organização tiver vários servidores de Caixa de Correio do Exchange 2013 disponíveis.

A tabela a seguir descreve os parâmetros que habilitam a redundância de sombra.

Parâmetros que habilitam a redundância de sombra

Como as mensagens de sombra são criadas

O principal objetivo da redundância de sombra é sempre ter duas cópias de uma mensagem dentro de um limite de alta disponibilidade de transporte enquanto a mensagem está em trânsito. Onde e quando a cópia redundante da mensagem é criada depende de onde a mensagem veio e para onde a mensagem está indo. Existem três grandes fatores determinantes:

• Mensagens recebidas de fora de um limite de alta disponibilidade de transporte.
• Mensagens enviadas fora de um limite de alta disponibilidade de transporte.
• Mensagens recebidas do serviço de Envio de Transporte de Caixa de Correio de um servidor de Caixa de Correio dentro do limite de alta disponibilidade de transporte.

Um limite de alta disponibilidade de transporte é um dos seguintes:

• Um DAG, para servidores de Caixa de Correio que são membros de um DAG. Isso inclui um DAG que abrange vários sites do Active Directory.
• Um site do Active Directory, para servidores de Caixa de Correio que não pertencem a um DAG.

A redundância de sombra nunca rastreia mensagens de sombra em um limite de alta disponibilidade de transporte. Quando uma mensagem cruza o limite de alta disponibilidade de transporte, a redundância de sombra começa ou reinicia. Isso reduz o tráfego de manutenção de mensagens de sombra e impede que novos envios de mensagens de sombra ocorram no limite de alta disponibilidade de transporte. Os servidores de Transporte de Hub do Exchange 2010 são um caso especial e são discutidos posteriormente neste tópico.

Mensagens recebidas de fora de um limite de alta disponibilidade de transporte

Quando o serviço de Transporte em um servidor de Caixa de Correio do Exchange 2013 recebe uma mensagem de fora do limite de alta disponibilidade de transporte, o servidor de Caixa de Correio não está preocupado com o suporte ou a falta de suporte para redundância de sombra pelo servidor de envio. Enquanto a redundância de sombra estiver habilitada, o servidor de Caixa de Correio que recebe a mensagem faz uma cópia redundante da mensagem em outro servidor de Caixa de Correio dentro do limite de alta disponibilidade de transporte antes de confirmar o recebimento da mensagem de volta para o servidor de envio. Veja um exemplo de como o processo funciona:

1. Um servidor SMTP transmite uma mensagem para o serviço de transporte em um servidor de Caixa de Correio. O servidor de Caixa de Correio é o servidor principal e a mensagem é a mensagem principal.

2. Enquanto a sessão SMTP original com o servidor SMTP ainda estiver ativa, o serviço de Transporte no servidor primário abre uma nova sessão SMTP simultânea com o serviço de Transporte em um servidor de Caixa de Correio diferente na organização para criar uma cópia redundante da mensagem.

   • Se o servidor principal for membro de um DAG, o servidor principal se conectará a um servidor de Caixa de Correio diferente no mesmo DAG. Se o DAG abranger vários sites do Active Directory, um servidor de Caixa de Correio em um site diferente do Active Directory será preferencial por padrão. Essa configuração é controlada pelo parâmetro ShadowMessagePreference no cmdlet Set-TransportService . O valor padrão é PreferRemote, mas você pode alterá-lo para RemoteOnly ou LocalOnly.
   • Se o servidor primário não for membro de um DAG, o servidor principal se conectará a um servidor de Caixa de Correio diferente no mesmo Site do Active Directory, independentemente do valor do parâmetro ShadowMessagePreference .

3. O servidor primário transmite uma cópia da mensagem para o serviço de Transporte em outro servidor de Caixa de Correio, e o serviço de Transporte no outro servidor de Caixa de Correio reconhece que a cópia da mensagem foi criada com êxito. A cópia da mensagem é a mensagem de sombra, e o servidor de Caixa de Correio que a contém é o servidor de sombra do servidor primário. A mensagem existe em uma fila de sombra no servidor de sombra.

4. Depois que o servidor primário recebe a confirmação do servidor de sombra, o servidor primário confirma o recebimento da mensagem principal para o servidor SMTP original na sessão SMTP original e a sessão SMTP é encerrada.

Mensagens enviadas fora de um limite de alta disponibilidade de transporte

Quando um servidor de transporte do Exchange 2013 transmite uma mensagem fora do limite de alta disponibilidade de transporte e o servidor SMTP do outro lado confirma o recebimento bem-sucedido da mensagem, o servidor de transporte move a mensagem para a Rede de Segurança. Nenhum reenvio da mensagem da Rede de Segurança pode ocorrer depois que a mensagem principal tiver sido transmitida com êxito através do limite de alta disponibilidade de transporte. Para obter mais informações sobre a Rede de Segurança, consulte Rede de Segurança.

Mensagens transmitidas dentro de um limite de alta disponibilidade de transporte

O roteamento de mensagens é otimizado no Exchange 2013 para que, quando o destino final estiver em um DAG ou site do Active Directory, vários saltos entre o serviço de Transporte em servidores de Caixa de Correio nesse DAG ou site do Active Directory normalmente não sejam necessários. Depois que a mensagem é aceita pelo serviço de Transporte em um servidor de Caixa de Correio no DAG ou no site do Active Directory que contém o destino final da mensagem, o próximo salto para a mensagem geralmente é o destino final em si. O objetivo da redundância de sombra de manter duas cópias de uma mensagem em trânsito é cumprido quando uma cópia de sombra da mensagem existe em qualquer lugar dentro do DAG ou do site do Active Directory. Normalmente, apenas cenários de failover em um DAG que exigem o cmdlet Redirect-Message para drenar as filas ativas em um servidor de Caixa de Correio exigiriam vários saltos dentro do mesmo limite de alta disponibilidade de transporte.

Redundância de sombra com servidores de Transporte de Hub do Exchange 2010 no mesmo site do Active Directory

Quando um servidor de Transporte de Hub do Exchange 2010 transmite uma mensagem para um servidor de Caixa de Correio do Exchange 2013 no mesmo site do Active Directory, o servidor de Transporte de Hub do Exchange 2010 anuncia suporte para redundância de sombra usando o comando XSHADOW, mas o servidor de Caixa de Correio não anuncia suporte para redundância de sombra. Isso impede que o servidor de Transporte de Hub do Exchange 2010 crie uma cópia de sombra da mensagem em um servidor de Caixa de Correio do Exchange 2013.

Quando o serviço de Transporte em um servidor de Caixa de Correio do Exchange 2013 transmite uma mensagem para um Transporte de Hub do Exchange 2010 no mesmo site do Active Directory, o servidor da Caixa de Correio do Exchange 2013 sinaliza a mensagem para o servidor de Transporte de Hub do Exchange 2010. Depois que o servidor de Caixa de Correio do Exchange 2013 recebe a confirmação do servidor de Transporte de Hub do Exchange 2010 de que a mensagem foi recebida com êxito, o servidor da Caixa de Correio do Exchange 2013 move a mensagem processada com êxito para a Rede de Segurança. No entanto, as mensagens processadas com êxito armazenadas na Rede de Segurança pela Caixa de Correio do Exchange 2013 nunca são reenviadas para os servidores de Transporte de Hub do Exchange 2010.

Tempos limite de SMTP

Durante a tentativa de fazer uma cópia redundante da mensagem, a conexão SMTP entre o servidor SMTP de envio e o servidor primário ou a sessão SMTP entre o servidor principal e o servidor sombra pode atingir o tempo limite. Os conectores de recebimento e os conectores de envio têm um parâmetro ConnectionInactivityTimeOut para quando os dados estão realmente sendo transmitidos no conector. Os conectores de recebimento também têm um parâmetro ConnectionTimeOut absoluto.

Se qualquer uma das sessões SMTP expirar antes que a cópia de sombra da mensagem seja criada e reconhecida com êxito, o resultado será controlado pelo parâmetro RejectMessageOnShadowFailure no cmdlet Set-TransportConfig . Por padrão, o valor desse parâmetro é $false, o que significa que a mensagem primária é aceita sem que uma cópia de sombra seja criada. Se o valor desse parâmetro for $true , a mensagem primária será rejeitada com o erro 451 4.4.0transitório.

Se a cópia de sombra de uma mensagem for criada com êxito, mas a sessão SMTP entre o servidor SMTP de envio e o servidor primário expirar, o servidor primário aceitará e processará a mensagem principal. O servidor SMTP de envio entregará novamente a mensagem não confirmada, mas a detecção de mensagens duplicadas impedirá que os usuários da caixa de correio do Exchange vejam as mensagens duplicadas. Quando o servidor SMTP de envio reenviar a mensagem, o servidor primário criará outra cópia de sombra da mensagem. Não há relação entre as mensagens de sombra criadas durante os reenvios de mensagens pelo servidor SMTP de envio.

A tabela a seguir descreve os parâmetros que controlam a criação de mensagens de sombra

Parâmetros de criação de mensagem de sombra

Como as mensagens de sombra são mantidas

Depois que uma mensagem de sombra é criada com êxito, o trabalho de redundância de sombra está apenas começando. O servidor primário e o servidor sombra precisam permanecer em contato um com o outro para acompanhar o andamento da mensagem.

Quando o servidor principal transmite com sucesso a mensagem para o próximo salto e o próximo salto confirma o recebimento da mensagem, o servidor principal atualiza o status de descarte da mensagem como entrega concluída. O status de descarte é basicamente uma mensagem que contém uma lista de mensagens que estão sendo monitoradas. Uma mensagem entregue com êxito não precisa ser mantida em uma fila de sombra, portanto, uma vez que o servidor de sombra saiba que o servidor primário transmitiu com êxito a mensagem para o próximo salto, o servidor de sombra move a mensagem de sombra da fila de sombra para a Rede de Segurança.

O servidor de sombra determina a status de descarte das mensagens de sombra em suas filas de sombra consultando o servidor primário. Se o servidor sombra abrir uma sessão SMTP com o servidor principal por qualquer motivo, incluindo a transmissão de outras mensagens não relacionadas, o servidor sombra emitirá o comando XQDISCARD para determinar o status de descarte das mensagens principais. Se o servidor sombra não tiver aberto uma sessão SMTP com o servidor primário após um intervalo de tempo pré-configurado, o servidor sombra abrirá uma sessão SMTP com o servidor primário e emitirá o comando XQDISCARD . O intervalo de tempo é controlado pelo parâmetro ShadowHeartbeatFrequency no cmdlet Set-TransportConfig . O valor padrão é de 2 minutos. Depois que o servidor sombra abre uma sessão SMTP com o servidor primário, o servidor primário responde com as notificações de descarte para mensagens que se aplicam ao servidor de sombra de consulta. No Exchange 2013, as notificações de descarte são armazenadas em disco, não na memória. Portanto, se o serviço de Transporte do Microsoft Exchange for reiniciado, as notificações de descarte serão mantidas. Após o início do serviço, o servidor primário ainda sabe sobre as mensagens processadas com êxito e essas informações estão disponíveis para o servidor sombra.

A comunicação SMTP entre o servidor de sombra e o servidor primário é usada como a pulsação que determina a disponibilidade dos servidores. Se o servidor de sombra não puder abrir uma sessão SMTP com o servidor primário após um intervalo de tempo pré-configurado ou se o banco de dados de transporte do servidor primário tiver uma ID de banco de dados diferente, o servidor de sombra se promoverá como o servidor primário, promoverá as mensagens de sombra como mensagens primárias e transmitirá as mensagens para o próximo salto. O intervalo de tempo é controlado pelo parâmetro ShadowResubmitTimeSpan no cmdlet Set-TransportConfig . O valor padrão é 3 horas.

O Gerenciador de Redundância de Sombra é o componente principal de um servidor de transporte do Exchange 2013 responsável por gerenciar a 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 no momento:

• O servidor sombra para cada mensagem primária que está sendo processada.
• O status de descarte a ser enviado aos servidores sombra.

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

• Manter a lista de servidores primários para cada mensagem de sombra.
• Comparando a ID do banco de dados original e a ID do banco de dados atual do banco de dados de fila em que a cópia primária da mensagem está armazenada.
• Verificando a disponibilidade de cada servidor primário para o qual uma mensagem de sombra está na fila.
• Processando notificações de descarte de servidores primários.
• Remoção das mensagens de sombra das filas de sombra depois que todas as notificações de descarte esperadas forem recebidas.
• Decidir quando o servidor de sombra deve assumir a propriedade das mensagens de sombra, tornando-se um servidor primário.
• Acompanhamento de bifurcações de mensagens e outras mensagens de efeitos colaterais, como notificações de status de entrega (DSNs) e relatórios de diário para verificar se a cópia redundante da mensagem não será liberada até que todas as bifurcações da mensagem sejam totalmente processadas.

A tabela a seguir descreve os parâmetros que controlam como as mensagens de sombra são mantidas.

Processamento de mensagens após uma interrupção

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

• O servidor volta a ficar online com um novo banco de dados de transporte: nesse cenário, o banco de dados de transporte é irrecuperável devido a corrupção de dados ou falha de hardware. Nesse caso, como o servidor de transporte terá uma nova ID de banco de dados, ele será reconhecido como uma nova rota pelos outros servidores de transporte da organização. Isso também se aplica à situação em que um servidor não pôde ser recuperado e um novo servidor foi provisionado como substituto.

• O servidor volta a ficar online com o mesmo banco de dados de transporte: nesse cenário, o servidor de transporte específico não falhou, mas ficou offline por tempo suficiente para que o servidor sombra assumisse a propriedade das mensagens e as reenviasse. Por exemplo, uma falha de card de rede ou uma longa manutenção no servidor causaria esse cenário.

A tabela a seguir resume como a redundância de sombra reage a esses dois cenários. Para maior clareza, suponha que o servidor que teve uma interrupção se chame Mailbox01.

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