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 verificava o próximo salto no caminho de entrega de mensagens concluído. Se o próximo salto falhar antes de relatar a entrega bem-sucedida de volta ao servidor de transporte, o servidor de transporte reapresentou a mensagem para o próximo salto. Os servidores do Exchange 2010 usaram o verbo XSHADOW para anunciar seu suporte de redundância de sombra. Se um servidor SMTP não deu suporte à redundância de sombra, o Exchange 2010 usou o reconhecimento atrasado com base em um intervalo de tempo configurado no conector De recebimento para fazer uma cópia redundante da mensagem.

A maior melhoria para a 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 reconhecer o recebimento com êxito da mensagem de volta para o servidor de envio. O suporte ou a falta de suporte do servidor de envio 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 estão em trânsito. Se o Exchange 2013 determinar que a mensagem original foi perdida em trânsito, a cópia redundante da mensagem será revivido 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 da caixa de correio do Exchange 2013. O servidor da caixa de correio pode ser servidores autônomos ou servidores de caixa de correio e servidores de Acesso ao Cliente instalados no mesmo computador.

• Se o servidor da caixa de correio não for membro de um DAG, os outros servidores da caixa de correio deverão estar no site do Active Directory local.
• Se o servidor mailbox for um 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 do Active Directory local ou em um site remoto do Active Directory. Se o DAG abranger vários sites do Active Directory, a redundância de sombra preferirá 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 mensagens em trânsito:

• Em ambientes de servidor do Exchange único.
• Em DAGs sub provisionados.
• 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 é habilitada por padrão

Por padrão, a redundância de sombra é habilitada globalmente no serviço de transporte em todos os servidores da Caixa de Correio usando o parâmetro ShadowRedundancyEnabled no cmdlet Set-TransportConfig . Por padrão, se o serviço de transporte em um servidor da 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 de envio 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 da caixa de correio do Exchange 2013 disponíveis.

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

Parâmetros que habilitam a redundância de sombra

Como as mensagens de sombra são criadas

O objetivo principal 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. Há três fatores determinantes principais:

• 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 envio de transporte da 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 é reiniciada. Isso reduz o tráfego de manutenção de mensagens de sombra e impede que reenviações de mensagens de sombra ocorram em todo o limite de alta disponibilidade de transporte. Os servidores de Transporte do 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 da Caixa de Correio do Exchange 2013 recebe uma mensagem de fora do limite de alta disponibilidade de transporte, o servidor mailbox não está preocupado com o suporte ou falta de suporte para redundância de sombra pelo servidor de envio. Enquanto a redundância de sombra estiver habilitada, o servidor mailbox que recebe a mensagem faz uma cópia redundante da mensagem em outro servidor da Caixa de Correio dentro do limite de alta disponibilidade de transporte antes de reconhecer o recebimento da mensagem de volta para o servidor de envio. Aqui está 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 da caixa de correio é o servidor primário e a mensagem é a mensagem primária.

2. Embora a sessão SMTP original com o servidor SMTP ainda esteja ativa, o serviço de transporte no servidor primário abre uma nova sessão SMTP simultânea com o serviço Transport em um servidor de caixa de correio diferente na organização para criar uma cópia redundante da mensagem.

   • Se o servidor primário for membro de um DAG, o servidor primário 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 do Active Directory diferente será preferido 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 primário 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 da Caixa de Correio e o serviço de transporte no outro servidor da 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 da caixa de correio que a mantém é o servidor de sombra do servidor primário. A mensagem existe em uma fila de sombras no servidor de sombras.

4. Depois que o servidor primário recebe o reconhecimento do servidor sombra, o servidor primário reconhece o recebimento da mensagem primária para o servidor SMTP original na sessão SMTP original e a sessão SMTP é fechada.

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 reconhece o recebimento bem-sucedido da mensagem, o servidor de transporte move a mensagem para a Rede de Segurança. Nenhuma resubmissão da mensagem da Rede de Segurança pode ocorrer depois que a mensagem primária tiver sido transmitida com êxito pelo limite de alta disponibilidade de transporte. Para obter mais informações sobre o Safety Net, consulte Safety Net.

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 site do DAG ou do Active Directory, vários saltos entre o serviço de transporte em servidores de caixa de correio nesse site DAG ou 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 site do DAG ou do Active Directory que contém o destino final da mensagem, o próximo salto para a mensagem normalmente é 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 no site do DAG ou do Active Directory. Normalmente, somente cenários de failover em um DAG que exigem o cmdlet Redirecionamento-Mensagem para drenar as filas ativas em um servidor da Caixa de Correio exigiriam vários saltos dentro do mesmo limite de alta disponibilidade de transporte.

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

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

Quando o serviço de transporte em um servidor da Caixa de Correio do Exchange 2013 transmite uma mensagem para um Transporte do Hub do Exchange 2010 no mesmo site do Active Directory, o servidor da caixa de correio do Exchange 2013 sombreia a mensagem para o servidor de Transporte do Hub do Exchange 2010. Depois que o servidor da Caixa de Correio do Exchange 2013 recebe o reconhecimento do servidor de Transporte do 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 Safety Net. No entanto, as mensagens processadas com êxito armazenadas no Safety Net by Exchange 2013 Mailbox nunca são reenviadas para os servidores de Transporte do Hub do Exchange 2010.

Tempo 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 primário e o servidor sombra pode ter tempo limite. Receber conectores e Enviar conectores têm um parâmetro ConnectionInactivityTimeOut para quando os dados estão sendo transmitidos no conector. Os conectores de recebimento também têm um parâmetro ConnectionTimeOut absoluto.

Se alguma das sessões SMTP perder tempo 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 a criação de uma cópia de sombra. Se o valor desse parâmetro for $true a mensagem primária for 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 sair, o servidor primário aceitará e processará a mensagem primária. O servidor SMTP de envio entregará novamente a mensagem não reconhecida, 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 reenvia a mensagem, o servidor primário criará outra cópia de sombra da mensagem. Não há nenhuma relação entre as mensagens de sombra criadas durante as resubmissões de mensagem 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 mensagens de sombra

Como as mensagens de sombra são mantidas

Depois que uma mensagem de sombra for criada com êxito, o trabalho de redundância de sombras apenas começou. O servidor primário e o servidor sombra precisam manter contato uns com os outros para acompanhar o progresso da mensagem.

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

O servidor de sombra determina o 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 primário por qualquer motivo, incluindo a transmissão de outras mensagens não relacionadas, o servidor de sombra emitirá o comando XQDISCARD para determinar o status de descarte das mensagens primárias. 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 persistentes. Depois que o serviço é iniciado, 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 sombra e o servidor primário é usada como a pulsação que determina a disponibilidade dos servidores. Se o servidor 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 Shadow Redundância Manager é 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 Sombras é responsável por manter as seguintes informações para todas as mensagens primárias que um servidor está processando no momento:

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

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

• Mantendo 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 é armazenada.
• Verificando a disponibilidade de cada servidor primário para o qual uma mensagem de sombra está enfileirada.
• Processamento de notificações de descarte de servidores primários.
• Removendo as mensagens de sombra das filas de sombra depois que todas as notificações de descarte esperadas forem recebidas.
• Decidir quando o servidor sombra deve assumir a propriedade de mensagens de sombra, tornando-se um servidor primário.
• Acompanhamento de bifurcações de mensagens e outras mensagens de efeito colateral, como DSNs (notificações de status de entrega) e relatórios de diário para verificar se a cópia redundante da mensagem não é lançada até que todos os bifurcações da mensagem sejam totalmente processados.

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 online com um novo banco de dados de transporte: nesse cenário, o banco de dados de transporte é irrecuperável devido à 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 uma substituição.

• O servidor volta a funcionar com o mesmo banco de dados de transporte: nesse cenário, o servidor de transporte específico não falhou, mas ficou offline o suficiente para que o servidor sombra assumisse a propriedade das mensagens e as reenviasse. Por exemplo, uma falha no cartão de rede ou uma manutenção longa 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 chama Caixa de Correio01.

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