Redundância de sombra no Exchange Server
A redundância de sombra foi introduzida no Exchange 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 fila em um servidor de Transporte do Hub até que o servidor verificasse se o próximo salto no caminho de entrega de mensagens havia concluído a entrega. Se o próximo salto falhar antes de relatar a entrega bem-sucedida de volta ao servidor de Transporte do Hub, o servidor reenvia a mensagem para o próximo salto. Os servidores de Transporte do Hub do Exchange 2010 usaram o verbo XSHADOW para anunciar seu suporte de redundância de sombra. Se um servidor de mensagens de origem 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.
O Exchange 2016 e o Exchange 2019 têm os mesmos aprimoramentos que foram feitos para a redundância de sombras no Exchange 2013: o serviço de transporte em um servidor da Caixa de Correio agora faz uma cópia redundante de qualquer mensagem recebida antes de reconhecer o recebimento da mensagem para o servidor de envio. Manter cópias redundantes de mensagens em trânsito é mais do que um esforço melhor que pode ou não funcionar, porque agora a redundância de sombra não depende dos recursos compatíveis do servidor de envio (suporte ou falta de suporte para redundância de sombra não importa). Isso ajuda a garantir que todas as mensagens no pipeline de transporte sejam redundantes enquanto estão em trânsito. Se o Exchange determinar que a mensagem original foi perdida em trânsito, a cópia redundante da mensagem será revivido.
Para obter mais informações sobre recursos de alta disponibilidade de transporte em Exchange Server, consulte Transporte de alta disponibilidade em Exchange Server. Para obter mais informações sobre a redundância de mensagens depois que uma mensagem tiver sido entregue com êxito, consulte Safety Net no Exchange Server.
Componentes de redundância de sombra
Esta tabela descreve os componentes da redundância de sombra no serviço de transporte em servidores de caixa de correio. Esses termos são usados em todo o tópico.
| Termo | Descrição |
|---|---|
| Limite de alta disponibilidade de transporte | Um DAG (grupo de disponibilidade de banco de dados) em ambientes DAG ou um site do Active Directory em ambientes que não são DAG. Para DAGs que abrangem vários sites do Active Directory, o DAG em si ainda é o limite (não o site). Quando uma mensagem chega em um servidor da Caixa de Correio no limite de alta disponibilidade de transporte, o Exchange tenta manter duas cópias redundantes da mensagem em servidores da caixa de correio dentro do limite. Quando uma mensagem deixa o limite de alta disponibilidade de transporte, o Exchange deixa de manter cópias redundantes da mensagem. |
| Mensagem primária | A mensagem enviada ao pipeline de transporte para entrega. |
| Mensagem de sombra | A cópia redundante da mensagem que o servidor sombra mantém até confirmar que a mensagem primária foi processada com êxito pelo servidor primário. |
| Servidor primário | O servidor da caixa de correio que está processando a mensagem primária no momento. |
| Servidor sombra | O servidor de caixa de correio que contém a mensagem de sombra para o servidor primário. Um servidor de caixa de correio pode ser o servidor primário para algumas mensagens e o servidor de sombra para outras mensagens simultaneamente. |
| Fila de sombras | A fila de entrega em que o servidor sombra armazena mensagens de sombra. Para mensagens com vários destinatários, cada próximo salto para a mensagem primária requer filas de sombra separadas. |
| Descartar status | As informações que o servidor mailbox mantém para mensagens de sombra para indicar que a mensagem primária foi processada com êxito. |
| Descartar notificação | A resposta que um servidor sombra recebe de um servidor primário indicando que uma mensagem de sombra está pronta para ser descartada. |
| Rede de Segurança | A versão aprimorada da lixeira de transporte no Exchange 2013 ou posterior. As mensagens processadas ou entregues com êxito a um destinatário de caixa de correio pelo serviço de transporte em um servidor de caixa de correio são movidas para a Rede de Segurança. Para obter mais informações, consulte Safety Net no Exchange Server. |
| Gerenciador de Redundância de Sombras | O componente de transporte que gerencia a redundância de sombra. |
| Pulsação | O processo que permite que servidores primários e servidores de sombra verifiquem a disponibilidade uns dos outros. |
Requisitos para redundância de sombra
Embora possa parecer óbvio, a redundância de sombra requer vários servidores de caixa de correio:
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 membros do DAG podem estar no site do Active Directory local ou em um site remoto. Por padrão, se o DAG abrange vários sites do Active Directory, a redundância de sombra prefere criar uma cópia redundante da mensagem em um site remoto 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 caixa de correio 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. Esta tabela descreve os parâmetros que permitem a redundância de sombra.
| Parâmetro | Valor padrão | Descrição |
|---|---|---|
| ShadowRedundancyEnabled em Set-TransportConfig | $true |
$true: a redundância de sombra está habilitada em todos os servidores de caixa de correio da organização. |
| RejectMessageOnShadowFailure em Set-TransportConfig | $false |
$false: quando uma cópia de sombra da mensagem não pode ser criada, a mensagem primária é aceita de qualquer maneira pelos servidores da caixa de correio na organização. Essas mensagens não são redundantes enquanto estão em trânsito. Observação: use Esse parâmetro só é significativo quando ShadowRedundancyEnabled é |
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. De 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 para a criação de mensagens de sombra:
Mensagens recebidas de fora de um limite de alta disponibilidade de transporte (o DAG ou um site do Active Directory em ambientes que não são DAG).
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.
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 reenviamentos de mensagens de sombra no 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 recebe uma mensagem de fora do limite de alta disponibilidade de transporte, o servidor da 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 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:
Um servidor de mensagens 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.
Embora a sessão SMTP original com o servidor de mensagens 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 abrange vários sites do Active Directory, um servidor de caixa de correio em um site do Active Directory diferente será preferencial por padrão (o valor padrão do parâmetro ShadowMessagePreferenceSetting no cmdlet Set-TransportConfig é
PreferRemote, mas você pode alterá-lo paraRemoteOnlyouLocalOnly).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 ShadowMessagePreferenceSetting ).
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.
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 de mensagens 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 da Caixa de Correio transmite uma mensagem fora do limite de alta disponibilidade de transporte, e o servidor de mensagens do outro lado reconhece o recebimento bem-sucedido da mensagem, e o servidor da caixa de correio 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 no Exchange Server.
Mensagens transmitidas dentro de um limite de alta disponibilidade de transporte
O roteamento de mensagens é otimizado para que, quando o destino final estiver em um site do DAG ou do Active Directory, vários saltos entre servidores dentro do DAG de destino ou site 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 de destino ou no Active Directory, o próximo salto para a mensagem normalmente é o destino final em si (por exemplo, o servidor mailbox que contém a cópia ativa da caixa de correio de destino). 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 de mensagens 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 do Hub do Exchange 2010 no mesmo site do Active Directory em organizações do Exchange 2016
Quando um servidor de Transporte do Hub do Exchange 2010 transmite uma mensagem para um servidor da Caixa de Correio do Exchange 2016 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 da Caixa de Correio 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 2016.
Quando o serviço de transporte em um servidor da Caixa de Correio do Exchange 2016 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 2016 sombreia a mensagem para o servidor de Transporte do Hub do Exchange 2010. Depois que o servidor da Caixa de Correio do Exchange 2016 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 2016 move a mensagem processada com êxito para a Safety Net. No entanto, as mensagens processadas com êxito armazenadas no Safety Net by Exchange 2016 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 servidores (o servidor de envio e o servidor primário, ou 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 de envio e o servidor primário sair, o servidor primário aceitará e processará a mensagem primária. O servidor 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 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 de envio.
A tabela a seguir descreve os parâmetros que controlam a criação de mensagens de sombra
| Origem | Valor padrão | Descrição |
|---|---|---|
| ShadowMessagePreferenceSetting em Set-TransportConfig | PreferRemote |
Esse parâmetro só é usado quando o servidor primário que está tentando fazer uma cópia de sombra da mensagem é um membro de um DAG que abrange vários sites do Active Directory.
|
| MaxRetriesForRemoteSiteShadow em Set-TransportConfig | 4 | Esse parâmetro especifica o número máximo de tentativas de criar uma cópia de sombra da mensagem em outro servidor no DAG quando o valor do parâmetro ShadowMessagePreferenceSetting é PreferRemote (o valor padrão) ou RemoteOnly. Esse parâmetro só é usado quando o servidor mailbox é membro de um DAG que abrange vários sites do Active Directory. Se uma cópia de sombra da mensagem não for criada com êxito após o número especificado de tentativas, o resultado dependerá do valor do parâmetro RejectMessageOnShadowFailure :
|
| MaxRetriesForLocalSiteShadow em Set-TransportConfig | 2 | Esse parâmetro especifica o número máximo de tentativas de criar uma cópia de sombra da mensagem em outro servidor de caixa de correio no site do Active Directory local quando:
Se uma cópia de sombra da mensagem não for criada com êxito após o número especificado de tentativas, o resultado dependerá do valor do parâmetro RejectMessageOnShadowFailure :
|
| ConnectionInactivityTimeout no Set-ReceiveConnector | 5 minutos para receber conectores no serviço de transporte em servidores de caixa de correio | Esse parâmetro especifica o tempo máximo em que uma conexão SMTP aberta com o servidor de mensagens de origem pode permanecer ociosa antes que a conexão seja fechada. O valor desse parâmetro deve ser maior que o valor do parâmetro ConnectionTimeout . |
| ConnectionTimeout no Set-ReceiveConnector | 10 minutos para receber conectores no serviço de transporte em servidores de caixa de correio | Esse parâmetro especifica o tempo máximo em que uma conexão SMTP com o servidor de mensagens de origem pode permanecer aberta, mesmo que o servidor esteja transmitindo dados. O valor desse parâmetro deve ser maior que o valor do parâmetro ConnectionInactivityTimeout. |
| ConnectionInactivityTimeOut no Set-SendConnector | 10 minutos | Esse parâmetro especifica o tempo máximo em que uma conexão SMTP aberta com um servidor de mensagens de destino pode permanecer ociosa antes que a conexão seja fechada. |
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. Caso contrário, o servidor sombra abrirá automaticamente uma sessão SMTP com o servidor primário após um intervalo de tempo pré-configurado (o 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. 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 persistirão. 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 (o parâmetro ShadowResubmitTimeSpan no cmdlet Set-TransportConfig ; o valor padrão é de 3 horas) o servidor sombra se promove como o servidor primário, promove as mensagens de sombra como mensagens primárias e transmite as mensagens para o próximo salto. Mas, sempre que o servidor de sombra detecta que a ID do banco de dados de fila do servidor primário foi alterada, o servidor sombra também se promove como o servidor primário, promove as mensagens de sombra como mensagens primárias e transmite as mensagens para o próximo salto. Isso pode acontecer bem antes que o valor do parâmetro ShadowResubmitTimeSpan tenha passado.
O Gerenciador de Redundância de Sombras é o componente principal em um servidor da Caixa de Correio responsável pelo gerenciamento da 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 pelas seguintes ações 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 notificações de status de entrega (também conhecidas como DSNs, relatórios de não entrega, NDRs ou mensagens de salto) 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.
Esta tabela descreve os parâmetros que controlam como as mensagens de sombra são mantidas.
| Parâmetro | Valor padrão | Descrição |
|---|---|---|
| ShadowHeartbeatFrequency em Set-TransportConfig | 2 minutos | O tempo máximo que um servidor sombra aguarda antes de abrir uma conexão SMTP com o servidor primário para verificar o status de descarte das mensagens. |
| ShadowResubmitTimeSpan em Set-TransportConfig | 3 horas | Quanto tempo um servidor aguarda antes de decidir se um servidor primário falhou e assume a propriedade de mensagens de sombra na fila de sombras para o servidor primário que é inacessível. Observe que um servidor sombra também pode se promover como o servidor primário antes do valor desse parâmetro quando o banco de dados de fila do servidor primário é encontrado com uma ID de banco de dados diferente. |
| ShadowMessageAutoDiscardInterval em Set-TransportConfig | 2 dias | Por quanto tempo um servidor retém eventos de descarte para mensagens entregues com êxito. Uma fila de servidor primário descarta eventos até ser consultado pelo servidor de sombras. No entanto, se o servidor sombra não consultar o servidor primário pela duração especificada neste parâmetro, o servidor primário excluirá os eventos de descarte enfileirados. |
| SafetyNetHoldTime em Set-TransportConfig | 2 dias | Quanto tempo as mensagens processadas com êxito são retidas na Rede de Segurança. As mensagens de sombra não reconhecidas eventualmente expiram da Safety Net após a soma dos valores do parâmetro SafetyNetHoldTime e MessageExpirationTimeout no cmdlet Set-TransportService . |
| MessageExpirationTimeout no Set-TransportService | 2 dias | Quanto tempo uma mensagem pode permanecer em uma fila antes de expirar. |
Processamento de mensagens após uma interrupção
Esta tabela resume como a redundância de sombra minimiza a perda de mensagens devido a interrupções no servidor. Para maior clareza, o servidor que teve uma interrupção se chama Mailbox01.
| Cenário de recuperação | Medidas tomadas |
|---|---|
| A caixa de correio01 volta online com um novo banco de dados de fila antes que o valor do parâmetro ShadowResubmitTimeSpan tenha passado (por padrão, 3 horas). Esse cenário pode ocorrer quando o banco de dados de fila está irrecuperável devido à corrupção de dados ou falha de hardware. |
Quando a nova ID do banco de dados de fila for detectada na Caixa de Correio01, cada servidor que tiver mensagens de sombra enfileiradas para o Mailbox01 assumirá a propriedade dessas mensagens e as reapresentará. Em seguida, as mensagens são entregues em seus destinos. O atraso máximo para envio de mensagens após a detecção do novo banco de dados de fila é o valor do parâmetro ShadowHeartbeatFrequency (por padrão, 2 minutos). |
| A caixa de correio01 volta online com o mesmo banco de dados depois que o valor do parâmetro ShadowResubmitTimeSpan tiver passado (por padrão, 3 horas). Esse cenário pode ocorrer após uma falha no cartão de rede ou manutenção demorada no servidor. |
Depois que o Mailbox01 voltar a funcionar, ele entregará as mensagens em suas filas, que já foram entregues pelos servidores que contêm cópias de sombra de mensagens para a Caixa de Correio01. Isso resultará na entrega duplicada dessas mensagens. Os usuários da caixa de correio do Exchange não verão mensagens duplicadas devido à detecção de mensagens duplicadas. No entanto, os destinatários em outros sistemas de mensagens podem ver cópias duplicadas de mensagens. O atraso máximo para envio de mensagens é o valor do parâmetro ShadowResubmitTimeSpan . |