Redundância sombra no Exchange Server
A redundância 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 sombra atrasou a eliminação de uma mensagem da base de dados de fila num servidor de Transporte do Hub até o servidor verificar que o próximo salto no caminho de entrega de mensagens tinha concluído a entrega. Se o salto seguinte tiver falhado antes de comunicar a entrega com êxito no servidor de Transporte do Hub, o servidor submetia novamente a mensagem para esse salto seguinte. Os servidores de Transporte do Hub do Exchange 2010 utilizaram o verbo XSHADOW para anunciar o suporte de redundância sombra. Se um servidor de mensagens de origem não suportar a redundância sombra, o Exchange 2010 utilizou a confirmação atrasada com base num intervalo de tempo configurado no conector Receber para fazer uma cópia redundante da mensagem.
O Exchange 2016 e o Exchange 2019 têm as mesmas melhorias efetuadas à redundância sombra no Exchange 2013: o serviço transporte num servidor de Caixa de Correio faz agora uma cópia redundante de qualquer mensagem recebida antes de reconhecer a receção da mensagem para o servidor de envio. Manter cópias redundantes de mensagens em trânsito é mais do que um melhor esforço que pode ou não funcionar, porque agora a redundância sombra não depende das funcionalidades suportadas pelo servidor de envio (o suporte ou a falta de suporte para redundância sombra não importa). Isto ajuda a garantir que todas as mensagens no pipeline de transporte são 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á resgatada novamente.
Para obter mais informações sobre as funcionalidades de elevada disponibilidade do transporte no Exchange Server, veja Transport high availability in Exchange Server (Transporte de elevada disponibilidade no Exchange Server). Para obter mais informações sobre a redundância de mensagens após a entrega com êxito de uma mensagem, consulte Safety Net in Exchange Server.
Componentes de redundância sombra
Esta tabela descreve os componentes da redundância sombra no serviço Transporte nos servidores da Caixa de Correio. Estes termos são utilizados ao longo do tópico.
| Termo | Descrição |
|---|---|
| Limite de elevada disponibilidade do transporte | Um grupo de disponibilidade de base de dados (DAG) em ambientes DAG ou um site do Active Directory em ambientes não DAG. Para DAGs que abrangem vários sites do Active Directory, o DAG em si continua a ser o limite (não o site). Quando uma mensagem chega a um servidor de Caixa de Correio no limite de elevada disponibilidade de transporte, o Exchange tenta manter duas cópias redundantes da mensagem nos servidores da Caixa de Correio dentro do limite. Quando uma mensagem deixa o limite de elevada disponibilidade do transporte, o Exchange deixa de manter cópias redundantes da mensagem. |
| Mensagem primária | A mensagem enviada para o pipeline de transporte para entrega. |
| Mensagem sombra | A cópia redundante da mensagem que o servidor sombra reté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á atualmente a processar a mensagem primária. |
| Servidor sombra | O servidor da Caixa de Correio que contém a mensagem sombra para o servidor primário. Um servidor de Caixa de Correio pode ser o servidor primário de algumas mensagens e o servidor sombra para outras mensagens em simultâneo. |
| Fila de sombras | A fila de entrega onde o servidor sombra armazena mensagens sombra. Para mensagens com vários destinatários, cada próximo salto para a mensagem primária requer filas sombra separadas. |
| Eliminar status | As informações que o servidor da Caixa de Correio mantém para as mensagens sombra indicarem que a mensagem primária foi processada com êxito. |
| Eliminar notificação | A resposta que um servidor sombra recebe de um servidor primário que indica que uma mensagem sombra está pronta para ser eliminada. |
| Rede de Segurança | A versão melhorada do contentor de lixo de transporte no Exchange 2013 ou posterior. As mensagens que são processadas ou entregues com êxito a um destinatário da caixa de correio pelo serviço transporte num servidor de Caixa de Correio são movidas para a Rede de Segurança. Para obter mais informações, consulte Rede de Segurança no Exchange Server. |
| Gestor de Redundância Sombra | O componente de transporte que gere a redundância sombra. |
| Pulsação | O processo que permite que os servidores primários e os servidores sombra verifiquem a disponibilidade uns dos outros. |
Requisitos para redundância sombra
Embora possa parecer óbvio, a redundância 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 têm de estar no site do Active Directory local.
Se o servidor da Caixa de Correio for membro de um DAG, os outros servidores da Caixa de Correio têm de pertencer ao mesmo DAG. Os outros membros do DAG podem estar no site do Active Directory local ou num site remoto. Por predefinição, se o DAG abranger vários sites do Active Directory, a redundância sombra prefere criar uma cópia redundante da mensagem num site remoto para resiliência do site.
Estas são as situações em que a redundância sombra não pode proteger mensagens em trânsito:
Em ambientes de servidor exchange individuais.
Em DAGs subprovisionados.
Durante a falha simultânea de dois ou mais servidores de Caixa de Correio envolvidos na redundância sombra de uma mensagem.
A redundância sombra está ativada por predefinição
Por predefinição, a redundância sombra está ativada globalmente no serviço Transporte em todos os servidores da Caixa de Correio. Esta tabela descreve os parâmetros que permitem a redundância sombra.
| Parâmetro | Valor padrão | Descrição |
|---|---|---|
| ShadowRedundancyEnabled em Set-TransportConfig | $true |
$true: a redundância sombra está ativada em todos os servidores da Caixa de Correio na organização.
|
| RejectMessageOnShadowFailure em Set-TransportConfig | $false |
$false: quando não é possível criar uma cópia sombra da mensagem, a mensagem principal é aceite de qualquer forma pelos servidores da Caixa de Correio na organização. Estas mensagens não são mantidas redundantemente enquanto estão em trânsito.
Nota: utilize Este parâmetro só é significativo quando ShadowRedundancyEnabled é |
Como as mensagens sombra são criadas
O objetivo main da redundância sombra é ter sempre duas cópias de uma mensagem dentro de um limite de elevada disponibilidade de transporte enquanto a mensagem estiver em trânsito. Para onde e quando a cópia redundante da mensagem é criada depende da origem da mensagem e do destino da mensagem. Existem três fatores que determinam a criação de mensagens sombra:
Mensagens recebidas de fora de um limite de elevada disponibilidade de transporte (o DAG ou um site do Active Directory em ambientes não DAG).
Mensagens enviadas fora de um limite de elevada disponibilidade de transporte.
Mensagens recebidas do serviço Submissão de Transporte da Caixa de Correio a partir de um servidor de Caixa de Correio dentro do limite de elevada disponibilidade de transporte.
A redundância sombra nunca monitoriza as mensagens sombra num limite de elevada disponibilidade de transporte. Quando uma mensagem ultrapassa o limite de elevada disponibilidade do transporte, a redundância sombra começa ou reinicia. Isto reduz o tráfego de manutenção de mensagens sombra e impede resubmissões de mensagens sombra no limite de elevada disponibilidade do transporte. Os servidores de Transporte do Hub do Exchange 2010 são um caso especial e são abordados mais adiante neste tópico.
Mensagens recebidas de fora de um limite de elevada disponibilidade de transporte
Quando o serviço Transporte num servidor de Caixa de Correio recebe uma mensagem fora do limite de elevada disponibilidade de transporte, o servidor da Caixa de Correio não está preocupado com o suporte ou com a falta de suporte para redundância sombra pelo servidor de envio. Enquanto a redundância sombra estiver ativada, o servidor da Caixa de Correio que recebe a mensagem efetua uma cópia redundante da mensagem noutro servidor da Caixa de Correio dentro do limite de elevada disponibilidade do transporte antes de reconhecer a receção da mensagem de volta para o servidor de envio. Eis um exemplo de como o processo funciona:
Um servidor de mensagens transmite uma mensagem para o serviço Transporte num servidor de Caixa de Correio. O servidor da Caixa de Correio é o servidor primário e a mensagem é a mensagem principal.
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 Transporte num 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 liga-se 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 num site do Active Directory diferente é preferido por predefinição (o valor predefinido do parâmetro ShadowMessagePreferenceSetting no cmdlet Set-TransportConfig é
PreferRemote, mas pode alterá-lo paraRemoteOnlyouLocalOnly).Se o servidor primário não for membro de um DAG, o servidor primário liga-se 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 Transporte noutro servidor da Caixa de Correio e o serviço 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 sombra e o servidor da Caixa de Correio que a contém é o servidor sombra do servidor primário. A mensagem existe numa fila sombra no servidor sombra.
Depois de o servidor primário receber a confirmação do servidor sombra, o servidor primário reconhece a receção 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 elevada disponibilidade de transporte
Quando um servidor de Caixa de Correio transmite uma mensagem fora do limite de elevada disponibilidade de transporte e o servidor de mensagens do outro lado reconhece a receção bem-sucedida da mensagem e o servidor da Caixa de Correio move a mensagem para a Rede de Segurança. Não é possível submeter novamente a mensagem da Rede de Segurança depois de a mensagem primária ter sido transmitida com êxito através do limite de elevada disponibilidade do transporte. Para obter mais informações sobre a Rede de Segurança, consulte Safety Net in Exchange Server.
Mensagens transmitidas dentro de um limite de elevada disponibilidade de transporte
O encaminhamento de mensagens é otimizado para que, quando o destino final estiver num site da DAG ou do Active Directory, não sejam normalmente necessários vários saltos entre servidores dentro do DAG ou site de destino. Depois de a mensagem ser aceite pelo serviço Transporte num servidor de Caixa de Correio no DAG de destino ou no Active Directory, o próximo salto da mensagem é normalmente o destino final em si (por exemplo, o servidor de Caixa de Correio que contém a cópia ativa da caixa de correio de destino). O objetivo da redundância sombra de manter duas cópias de uma mensagem em trânsito é cumprido quando existe uma cópia sombra da mensagem em qualquer parte do site do DAG ou do Active Directory. Normalmente, apenas os cenários de ativação pós-falha num DAG que requerem o cmdlet Redirect-Message para drenar as filas de mensagens ativas num servidor da Caixa de Correio exigiriam vários saltos dentro do mesmo limite de elevada disponibilidade de transporte.
Redundância 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 de 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 sombra com o comando XSHADOW, mas o servidor da Caixa de Correio não anuncia suporte para redundância sombra. Isto impede que o servidor de Transporte do Hub do Exchange 2010 crie uma cópia sombra da mensagem num servidor de Caixa de Correio do Exchange 2016.
Quando o Serviço de transporte num servidor de 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 ensombra a mensagem para o servidor de Transporte do Hub do Exchange 2010. Depois de o servidor da Caixa de Correio do Exchange 2016 receber a confirmação 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 Rede de Segurança. No entanto, as mensagens processadas com êxito armazenadas na Rede de Segurança pela Caixa de Correio do Exchange 2016 nunca são reenviadas para os servidores de Transporte do Hub do Exchange 2010.
Tempos limite de SMTP
Durante a tentativa de fazer uma cópia redundante da mensagem, a ligação SMTP entre servidores (o servidor de envio e o servidor primário, ou o servidor primário e o servidor sombra) pode exceder o tempo limite. Os conectores receive e Send connectors têm um parâmetro ConnectionInactivityTimeOut para quando os dados estão realmente a ser transmitidos no conector. Os conectores de receção também têm um parâmetro ConnectionTimeOut absoluto.
Se alguma das sessões SMTP exceder o limite de tempo antes de a cópia sombra da mensagem ser criada com êxito e reconhecida, o resultado será controlado pelo parâmetro RejectMessageOnShadowFailure no cmdlet Set-TransportConfig . Por predefinição, o valor deste parâmetro é $false, o que significa que a mensagem primária é aceite sem a criação de uma cópia sombra. Se o valor deste parâmetro for $true a mensagem primária for rejeitado com o erro 451 4.4.0transitório .
Se a cópia sombra de uma mensagem for criada com êxito, mas a sessão SMTP entre o servidor de envio e o servidor primário exceder o limite de tempo, o servidor primário aceita e processa a mensagem primária. O servidor de envio irá entregar novamente a mensagem não reconhecida, mas a deteção de mensagens duplicadas impedirá os utilizadores da caixa de correio do Exchange de verem as mensagens duplicadas. Quando o servidor de envio submeter novamente a mensagem, o servidor primário criará outra cópia sombra da mensagem. Não existe nenhuma relação entre as mensagens sombra criadas durante as resubmissões de mensagens pelo servidor de envio.
A tabela seguinte descreve os parâmetros que controlam a criação de mensagens sombra
| Origem | Valor padrão | Descrição |
|---|---|---|
| ShadowMessagePreferenceSetting em Set-TransportConfig | PreferRemote |
Este parâmetro só é utilizado quando o servidor primário que está a tentar fazer uma cópia sombra da mensagem é um membro de um DAG que abrange vários sites do Active Directory.
|
| MaxRetriesForRemoteSiteShadow em Set-TransportConfig | 4 | Este parâmetro especifica o número máximo de tentativas para criar uma cópia sombra da mensagem noutro servidor no DAG quando o valor do parâmetro ShadowMessagePreferenceSetting é PreferRemote (o valor predefinido) ou RemoteOnly. Este parâmetro só é utilizado quando o servidor da Caixa de Correio é membro de um DAG que abrange vários sites do Active Directory. Se uma cópia sombra da mensagem não for criada com êxito após o número especificado de tentativas, o resultado depende do valor do parâmetro RejectMessageOnShadowFailure :
|
| MaxRetriesForLocalSiteShadow em Set-TransportConfig | 2 | Este parâmetro especifica o número máximo de tentativas para criar uma cópia sombra da mensagem noutro servidor da Caixa de Correio no site do Active Directory local quando:
Se uma cópia sombra da mensagem não for criada com êxito após o número especificado de tentativas, o resultado depende do valor do parâmetro RejectMessageOnShadowFailure :
|
| ConnectionInactivityTimeout em Set-ReceiveConnector | 5 minutos para Receber conectores no serviço transporte em servidores de Caixa de Correio | Este parâmetro especifica o tempo máximo durante o qual uma ligação SMTP aberta com o servidor de mensagens de origem pode permanecer inativa antes de a ligação ser fechada. O valor deste parâmetro tem de ser maior do que o valor do parâmetro ConnectionTimeout . |
| ConnectionTimeout em Set-ReceiveConnector | 10 minutos para Receber conectores no serviço Transporte em servidores de Caixa de Correio | Este parâmetro especifica o tempo máximo durante o qual uma ligação SMTP com o servidor de mensagens de origem pode permanecer aberta, mesmo que o servidor esteja a transmitir dados. O valor desse parâmetro deve ser maior que o valor do parâmetro ConnectionInactivityTimeout. |
| ConnectionInactivityTimeOut em Set-SendConnector | 10 minutos | Este parâmetro especifica o tempo máximo durante o qual uma ligação SMTP aberta a um servidor de mensagens de destino pode permanecer inativa antes de a ligação ser fechada. |
Como as mensagens sombra são mantidas
Após a criação com êxito de uma mensagem sombra, o trabalho de redundância sombra ainda agora começou. O servidor primário e o servidor sombra têm de permanecer em contacto uns com os outros para controlar o progresso da mensagem.
Quando o servidor primário transmite a mensagem com êxito para o salto seguinte e o próximo salto reconhece a receção da mensagem, o servidor primário atualiza a status de eliminação da mensagem à medida que a entrega é concluída. A status de eliminação é basicamente uma mensagem que contém uma lista de mensagens que estão a ser monitorizadas. Uma mensagem entregue com êxito não precisa de ser mantida numa fila sombra, pelo que assim que o servidor sombra souber que o servidor primário transmitiu a mensagem com êxito para o salto seguinte, o servidor sombra move a mensagem sombra da fila sombra para a Rede de Segurança.
O servidor sombra determina a status de eliminação das mensagens sombra nas respetivas filas sombra ao consultar 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 sombra emite o comando XQDISCARD para determinar a eliminação status 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 predefinido é 2 minutos).
Depois de o servidor sombra abrir uma sessão SMTP com o servidor primário, o servidor primário responde com as notificações de eliminação de mensagens que se aplicam ao servidor sombra de consulta. As notificações de eliminação são armazenadas no disco (não na memória), pelo que, se o serviço de Transporte do Microsoft Exchange reiniciar, as notificações de rejeição persistem. Após o início do serviço, o servidor primário ainda sabe das mensagens que processou 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 é utilizada como heartbeat que determina a disponibilidade dos servidores. Se o servidor sombra não conseguir 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 predefinido é 3 horas), o servidor sombra promove-se como o servidor primário, promove as mensagens sombra como mensagens primárias e transmite as mensagens para o próximo salto. No entanto, sempre que o servidor sombra detetar que o ID da base de dados da fila do servidor primário foi alterado, o servidor sombra também se promove como o servidor primário, promove as mensagens sombra como mensagens primárias e transmite as mensagens para o salto seguinte. Isto pode acontecer muito antes de o valor do parâmetro ShadowResubmitTimeSpan ter passado.
O Gestor de Redundância Sombra é o componente principal num servidor de Caixa de Correio responsável pela gestão da redundância sombra. O Gestor de Redundância Sombra é responsável por manter as seguintes informações para todas as mensagens principais que um servidor está atualmente a processar:
O servidor sombra para cada mensagem primária que está a ser processada.
A eliminação status a ser enviada para os servidores sombra.
O Gestor de Redundância Sombra é responsável pelas seguintes ações para todas as mensagens sombra que um servidor sombra tem nas respetivas filas sombra:
Manter a lista de servidores primários para cada mensagem sombra.
Comparar o ID da base de dados original e o ID de base de dados atual da base de dados de fila onde a cópia primária da mensagem está armazenada.
Verificar a disponibilidade de cada servidor primário para o qual uma mensagem sombra está em fila.
Processamento de notificações de eliminação de servidores primários.
Remover as mensagens sombra das filas sombra depois de todas as notificações de eliminação esperadas serem recebidas.
Decidir quando o servidor sombra deve assumir a propriedade das mensagens sombra, tornando-se um servidor primário.
Controlar bifurcações de mensagens e outras mensagens de efeito colateral, como notificações de entrega status (também conhecidas como DSNs, relatórios de entrega sem êxito, NDRs ou mensagens de devolução) e relatórios de diário para verificar se a cópia redundante da mensagem não é lançada até que todos os forks da mensagem sejam totalmente processados.
Esta tabela descreve os parâmetros que controlam a forma como as mensagens sombra são mantidas.
| Parâmetro | Valor padrão | Descrição |
|---|---|---|
| ShadowHeartbeatFrequency em Set-TransportConfig | 2 minutos | A quantidade máxima de tempo que um servidor sombra aguarda antes de abrir uma ligação SMTP ao servidor primário para marcar eliminar status de mensagens. |
| ShadowResubmitTimeSpan em Set-TransportConfig | 3 horas | Quanto tempo um servidor aguarda antes de decidir que um servidor primário falhou e assume a propriedade das mensagens sombra na fila sombra do servidor primário inacessível. Tenha em atenção que um servidor sombra também pode promover-se como o servidor primário antes do valor deste parâmetro quando se detetar que a base de dados de fila do servidor primário tem um ID de base de dados diferente. |
| ShadowMessageAutoDiscardInterval em Set-TransportConfig | 2 dias | Durante quanto tempo um servidor retém eventos de rejeição para mensagens entregues com êxito. Os servidores primários eliminam eventos até serem consultados pelo servidor sombra. No entanto, se o servidor sombra não consultar o servidor primário durante a duração especificada neste parâmetro, o servidor primário elimina os eventos de eliminação em fila. |
| SafetyNetHoldTime em Set-TransportConfig | 2 dias | Durante quanto tempo as mensagens processadas com êxito são mantidas na Rede de Segurança. As mensagens sombra não reconhecidas acabam por expirar a partir da Rede de Segurança após a soma dos valores do parâmetro SafetyNetHoldTime e MessageExpirationTimeout no cmdlet Set-TransportService . |
| MessageExpirationTimeout em Set-TransportService | 2 dias | Quanto tempo uma mensagem pode permanecer numa fila antes de expirar. |
Processamento de mensagens após uma indisponibilidade
Esta tabela resume como a redundância sombra minimiza a perda de mensagens devido a falhas no servidor. Para maior clareza, o servidor que teve uma falha chama-se Caixa de Correio01.
| Cenário de recuperação | Medidas tomadas |
|---|---|
| A caixa de correio01 volta a estar online com uma nova base de dados de fila antes de o valor do parâmetro ShadowResubmitTimeSpan ter passado (por predefinição, 3 horas). Este cenário pode ocorrer quando a base de dados de fila está irrecuperável devido a danos nos dados ou falha de hardware. |
Quando o novo ID da base de dados de fila é detetado na Caixa de Correio01, cada servidor que tenha mensagens sombra em fila para a Caixa de Correio01 assumirá a propriedade dessas mensagens e irá submetê-las novamente. Em seguida, as mensagens são entregues nos respetivos destinos. O atraso máximo para a submissão de mensagens após a nova base de dados de fila ser detetada é o valor do parâmetro ShadowHeartbeatFrequency (por predefinição, 2 minutos). |
| A caixa de correio01 volta a estar online com a mesma base de dados depois de o valor do parâmetro ShadowResubmitTimeSpan ter passado (por predefinição, 3 horas). Este cenário pode ocorrer após uma falha de card de rede ou uma manutenção demorada no servidor. |
Depois de a Caixa de Correio01 voltar a ficar online, irá entregar as mensagens nas suas filas, que já foram entregues pelos servidores que contêm cópias sombra de mensagens para a Caixa de Correio01. Isto resultará na entrega duplicada destas mensagens. Os utilizadores da caixa de correio do Exchange não verão mensagens duplicadas devido à deteção de mensagens duplicadas. No entanto, os destinatários de outros sistemas de mensagens podem ver cópias duplicadas de mensagens. O atraso máximo para a submissão de mensagens é o valor do parâmetro ShadowResubmitTimeSpan . |