Ridondanza shadow in Exchange Server
La ridondanza shadow è stata introdotta in Exchange 2010 per fornire copie ridondanti dei messaggi prima che siano recapitati alle cassette postali. In Exchange 2010, la ridondanza shadow ritardava l'eliminazione di un messaggio dal database delle code su un server Trasporto Hub fino a quando il server non aveva verificato che l'hop successivo avesse completato il percorso di recapito del messaggio. Se l'hop successivo restituiva un errore prima di segnalare l'effettivo recapito al server Trasporto Hub, quest'ultimo rinviava il messaggio a tale hop successivo. I server Trasporto Hub Exchange 2010 utilizzavano il verbo XSHADOW per annunciare il loro supporto per la ridondanza shadow. Se un server di messaggistica di origine non supportava la ridondanza shadow, Exchange 2010 utilizzava una conferma ritardata basata su un intervallo di tempo configurato sul connettore di ricezione per creare una copia ridondante del messaggio.
Exchange 2016 ed Exchange 2019 presentano gli stessi miglioramenti apportati alla ridondanza shadow in Exchange 2013: il servizio Trasporto in un server Cassette postali ora crea una copia ridondante di qualsiasi messaggio ricevuto prima di confermare la ricezione del messaggio al server di invio. La gestione di copie ridondanti dei messaggi in transito è più di un lavoro che può funzionare o meno, perché ora la ridondanza shadow non dipende dalle funzionalità supportate del server di invio (il supporto o la mancanza di supporto per la ridondanza shadow non è importante). Questo aiuta a garantire che tutti i messaggi nella pipeline di trasporto siano resi ridondanti durante il transito. Se Exchange determina che il messaggio originale è andato perso nel transito, viene recapitata la copia ridondante del messaggio.
Per altre informazioni sulle funzionalità di disponibilità elevata del trasporto in Exchange Server, vedere Disponibilità elevata del trasporto in Exchange Server. Per altre informazioni sulla ridondanza dei messaggi dopo che un messaggio è stato recapitato correttamente, vedere Safety Net in Exchange Server.
Componenti della ridondanza shadow
In questa tabella vengono descritti i componenti di ridondanza shadow nel servizio di trasporto sui server Cassette postali. In questo argomento vengono utilizzati i seguenti termini:
| Termine | Descrizione |
|---|---|
| Limite di disponibilità elevata del trasporto | Un gruppo di disponibilità del database (DAG) in ambienti DAG, oppure un sito Active Directory in ambienti non DAG. Per i DAG che si estendono su più siti Active Directory, è il DAG stesso che rappresenta il limite (non il sito). Quando un messaggio arriva in un server Cassette postali nel limite di disponibilità elevata del trasporto, Exchange tenta di conservare due copie ridondanti del messaggio nei server Cassette postali all'interno del limite. Quando un messaggio lascia il limite di disponibilità elevata del trasporto, Exchange smette di conservare le copie ridondanti del messaggio. |
| Messaggio principale | Il messaggio inviato alla pipeline di trasporto per il recapito. |
| Messaggio shadow | La copia ridondante del messaggio che il server shadow gestisce fino alla conferma che il messaggio primario è stato correttamente elaborato dal server primario. |
| Server primario | Il server Cassette postali che sta attualmente elaborando il messaggio primario. |
| Server shadow | Il server Cassette postali contenente il messaggio shadow per il server primario. Un server Cassette postali potrebbe essere il server primario per alcuni messaggi e il server shadow per altri messaggi. |
| Coda shadow | La coda di recapito dove il server shadow archivia i messaggi shadow. Per i messaggi con più destinatari, ogni hop successivo per il messaggio primario richiede code shadow separate. |
| Stato di eliminazione | Le informazioni mantenute dal server Cassette postali per i messaggi shadow che indicano che il messaggio primario è stato elaborato correttamente. |
| Notifica di eliminazione | La risposta che un server shadow riceve da un server primario che indica che un messaggio shadow è pronto per la rimozione. |
| Rete sicura | La versione migliorata di Exchange 2013 o versione successiva del dumpster di trasporto. I messaggi correttamente elaborati o recapitati a un destinatario di cassette postali dal servizio Trasporto su un server Cassette postali sono trasferiti in Safety Net. Per altre informazioni, vedere Safety Net in Exchange Server. |
| Shadow Redundancy Manager | Componente di trasporto che gestisce la ridondanza shadow. |
| Heartbeat | Il processo che consente ai server primari e ai server shadow di verificare reciprocamente la disponibilità. |
Requisiti per la ridondanza shadow
Anche se può sembrare ovvio, la ridondanza shadow richiede più server Cassette postali:
Se il server Cassette postali non è membro di un gruppo di disponibilità del database, gli altri server Cassette postali devono trovarsi nel sito Active Directory locale.
Se il server Cassette postali è membro di un gruppo di disponibilità del database, gli altri server Cassette postali devono appartenere allo stesso gruppo. Gli altri membri del gruppo di disponibilità del database possono trovarsi nel sito Active Directory locale o in un sito remoto. Per impostazione predefinita, se il gruppo di disponibilità del database si estende su più siti Active Directory, la ridondanza shadow preferisce creare una copia ridondante del messaggio in un sito remoto per la resilienza del sito.
Di seguito sono riportate le situazioni in cui la ridondanza shadow non può proteggere i messaggi in transito:
Negli ambienti con server Exchange singolo.
Nei gruppi di disponibilità del database con provisioning.
Durante l'errore simultaneo di due server di Cassette postali coinvolti nella ridondanza shadow di un messaggio.
La ridondanza shadow è abilitata per impostazione predefinita
Per impostazione predefinita, la ridondanza shadow è abilitata a livello globale nel servizio di trasporto in tutti i server Cassette postali. Nella tabella seguente sono descritti i parametri che consentono la ridondanza shadow.
| Parametro | Valore predefinito | Descrizione |
|---|---|---|
| ShadowRedundancyEnabled in Set-TransportConfig | $true |
$true: la ridondanza shadow è abilitata in tutti i server Cassette postali dell'organizzazione. |
| RejectMessageOnShadowFailure in Set-TransportConfig | $false |
$false: quando non è possibile creare una copia shadow del messaggio, il messaggio primario viene accettato comunque dai server Cassette postali dell'organizzazione. Questi messaggi non sono persistenti in maniera ridondante durante il transito. Nota: usare Questo parametro è significativo solo quando ShadowRedundancyEnabled è |
Modalità di creazione dei messaggi shadow
L'obiettivo principale della ridondanza shadow è sempre quello di avere due copie di un messaggio entro un limite di disponibilità elevata del trasporto mentre il messaggio è in transito. Il momento e la posizione di creazione della copia ridondante del messaggio dipendono dalla provenienza e dalla destinazione del messaggio. Esistono tre fattori determinanti per la creazione di messaggi shadow:
Messaggi ricevuti esternamente a un limite di disponibilità elevata del trasporto (il gruppo di disponibilità dei database oppure un sito Active Directory in ambienti non DAG).
Messaggi inviati esternamente a un limite di disponibilità elevata del trasporto.
Messaggi ricevuti dal servizio Invio Trasporto cassette postali da un server Cassette postali nel limite di disponibilità elevata del trasporto.
La ridondanza shadow non tiene mai traccia dei messaggi shadow attraverso un limite di disponibilità elevata del trasporto. Quando un messaggio supera il limite di disponibilità elevata del trasporto, la ridondanza shadow viene avviata o riavviata. In questo modo si riduce il traffico di gestione dei messaggi shadow e si impedisce il rinvio dei messaggi shadow attraverso il limite di disponibilità elevata del trasporto. I server Trasporto Hub di Exchange 2010 rappresentano un caso speciale e sono affrontati più avanti in questo argomento.
Messaggi ricevuti esternamente a un limite di disponibilità elevata del trasporto
Quando il servizio Trasporto su un server Cassette postali riceve un messaggio esternamente al limite di disponibilità elevata del trasporto, il server Cassette postali non è interessato al supporto della ridondanza shadow da parte del server di invio. Finché la ridondanza shadow è abilitata, il server Cassette postali che riceve il messaggio crea una copia ridondante del messaggio su un altro server Cassette postali nel limite di disponibilità elevata del trasporto prima di dare atto della ricezione del messaggio al server di invio. Ecco un esempio di funzionamento del processo:
Un server di messaggistica trasmette un messaggio al servizio Trasporto su un server Cassette postali. Il server Cassette postali è il server primario e il messaggio è il messaggio primario.
Mentre la sessione SMTP originale con il server di messaggistica è ancora attiva, il servizio Trasporto sul server primario apre una nuova sessione SMTP simultanea con il servizio Trasporto su un server Cassette postali diverso nell'organizzazione per creare una copia ridondante del messaggio.
Se il server primario è un membro di un DAG, il server primario si connette a un server Cassette postali diverso nello stesso DAG. Se il gruppo di disponibilità del database si estende su più siti di Active Directory, per impostazione predefinita è preferibile usare un server Cassette postali in un sito di Active Directory diverso. Il valore predefinito del parametro ShadowMessagePreferenceSetting nel cmdlet Set-TransportConfig è , ma è
PreferRemotepossibile modificarlo inRemoteOnlyoLocalOnly.Se il server primario non è un membro di un dag, il server primario si connette a un server Cassette postali diverso nello stesso sito active directory (indipendentemente dal valore del parametro ShadowMessagePreferenceSetting ).
Il server primario trasmette una copia del messaggio al servizio di trasporto su un altro server Cassette postali, mentre il servizio di trasporto sull'altro server Cassette postali conferma che la copia del messaggio sia stata creata correttamente. La copia del messaggio è il messaggio shadow e il server Cassette postali che lo gestisce è il server shadow per il server primario. Il messaggio esiste in una coda shadow sul server shadow.
Dopo aver ricevuto la conferma dal server shadow, il server primario conferma la ricezione del messaggio primario al server di messaggistica originale nella sessione SMTP originale e la sessione SMTP viene chiusa.
Messaggi inviati esternamente a un limite di disponibilità elevata del trasporto
Quando un server Cassette postali trasmette un messaggio all'esterno del limite di disponibilità elevata del trasporto e il server di messaggistica all'altro capo conferma la corretta ricezione del messaggio, il server Cassette postali sposta il messaggio in Rete sicura. Non può verificarsi alcun rinvio del messaggio da Safety Net dopo che il messaggio primario è stato trasmesso attraverso il limite di disponibilità elevata del trasporto. Per altre informazioni su Safety Net, vedere Safety Net in Exchange Server.
Messaggi trasmessi all'interno di un limite di disponibilità elevata del trasporto
Il routing dei messaggi è stato ottimizzato in modo che, se la destinazione finale è in un gruppo di disponibilità del database o in un sito Active Directory, non siano generalmente richiesti più hop tra i server all'interno del gruppo di disponibilità del database o nel sito. Dopo che il messaggio viene accettato dal servizio di trasporto su un server Cassette postali nel gruppo di disponibilità del database o nel sito Active Directory, l'hop successivo del messaggio è generalmente la destinazione finale stessa (ad esempio, il server Cassette postali contenente la copia attiva della cassetta postale di destinazione). L'obiettivo della ridondanza shadow di mantenere due copie di un messaggio in transito viene soddisfatto quando esiste una copia shadow del messaggio in qualsiasi punto del gruppo di disponibilità del database o del sito di Active Directory. In generale, solo gli scenari di failover in un gruppo di disponibilità del database che richiede il cmdlet Redirect-Message per svuotare le code dei messaggi attive su un server Cassette postali richiedono più hop nello stesso limite di disponibilità elevata del trasporto.
Ridondanza shadow con i server Trasporto hub di Exchange 2010 nello stesso sito di Active Directory nelle organizzazioni di Exchange 2016
Se un server Trasporto Hub di Exchange 2010 trasmette un messaggio a un server Cassette postali di Exchange 2016 nello stesso sito Active Directory, il server Trasporto Hub di Exchange 2010 annuncia il supporto per la ridondanza shadow utilizzando il comando XSHADOW, mentre il server Cassette postali non annuncia il supporto per la ridondanza shadow. Questo impedisce al server Trasporto Hub di Exchange 2010 di creare una copia shadow del messaggio su un server Cassette postali di Exchange 2016.
Quando il servizio Trasporto su un server Cassette postali di Exchange 2016 trasmette un messaggio a un server Trasporto Hub di Exchange 2010 nello stesso sito Active Directory, il server Cassette postali di Exchange 2016 crea una copia shadow del messaggio per il server Trasporto Hub di Exchange 2010. Dopo che il server Cassette postali di Exchange 2016 riceve conferma dal server Trasporto Hub di Exchange 2010 che il messaggio è stato correttamente ricevuto, il server Cassette postali di Exchange 2016 sposta il messaggio correttamente elaborato in Safety Net. Tuttavia, i messaggi elaborati correttamente in Safety Net dal server Cassette postali di Exchange 2016 non vengono mai rinviati ai server Trasporto Hub di Exchange 2010.
Timeout SMTP
Durante il tentativo di creare una copia ridondante del messaggio, potrebbe verificarsi un timeout della connessione SMTP tra i server (il server di invio e il server primario o il server primario e il server shadow). I connettori di ricezione e i connettori di invio hanno entrambi un parametro ConnectionInactivityTimeOut per quando i dati vengono effettivamente trasmessi sul connettore. I connettori di ricezione hanno anche un parametro ConnectionTimeOut assoluto.
Se una delle sessioni SMTP si verifica prima che la copia shadow del messaggio venga creata e riconosciuta correttamente, il risultato viene controllato dal parametro RejectMessageOnShadowFailure nel cmdlet Set-TransportConfig . Per impostazione predefinita, il valore di questo parametro è $false, il che significa che il messaggio primario viene accettato senza che venga creata una copia shadow. Se il valore di questo parametro è $true il messaggio primario viene rifiutato con l'errore 451 4.4.0temporaneo .
Se la copia shadow di un messaggio viene creata correttamente, ma la sessione SMTP tra il server di invio e il server primario subisce un timeout, il server primario accetta ed elabora il messaggio primario. Il server di invio recapiterà di nuovo il messaggio non confermato, ma il rilevamento dei messaggi duplicati impedirà agli utenti delle cassette postali di Exchange di vedere i messaggi duplicati. Quando il server di invio ripete l'invio del messaggio, il server primario crea un'altra copia shadow del messaggio. Non c'è alcuna relazione tra i messaggi shadow creati durante il rinvio dei messaggi da parte del server di invio.
Nella tabella seguente sono descritti i parametri che controllano la creazione dei messaggi shadow
| Origine | Valore predefinito | Descrizione |
|---|---|---|
| ShadowMessagePreferenceSetting in Set-TransportConfig | PreferRemote |
Questo parametro viene utilizzato solo quando il server primario che sta tentando di creare una copia shadow del messaggio è un membro di un gruppo di disponibilità del database che si estende su più siti Active Directory.
|
| MaxRetriesForRemoteSiteShadow in Set-TransportConfig | 4 | Questo parametro specifica il numero massimo di tentativi di creazione di una copia shadow del messaggio in un altro server nel dag quando il valore del parametro ShadowMessagePreferenceSetting è PreferRemote (il valore predefinito) o RemoteOnly. Questo parametro è utilizzato solo quando il server Cassette postali è membro di un gruppo di disponibilità dei database che si estende su più siti Active Directory. Se una copia shadow del messaggio non viene creata correttamente dopo il numero specificato di tentativi, il risultato dipende dal valore del parametro RejectMessageOnShadowFailure :
|
| MaxRetriesForLocalSiteShadow in Set-TransportConfig | 2 | Questo parametro consente di specificare il numero massimo di tentativi per creare una copia shadow del messaggio in un altro server Cassette postali nel sito Active Directory locale quando:
Se una copia shadow del messaggio non viene creata correttamente dopo il numero specificato di tentativi, il risultato dipende dal valore del parametro RejectMessageOnShadowFailure :
|
| ConnectionInactivityTimeout in Set-ReceiveConnector | 5 minuti per i connettori di ricezione nel servizio di trasporto sui server Cassette postali | Questo parametro consente di specificare il tempo massimo per il quale una connessione SMTP aperta con il server di messaggistica di origine può restare inattiva prima che venga chiusa. Il valore di questo parametro deve essere maggiore del valore del parametro ConnectionTimeout . |
| ConnectionTimeout in Set-ReceiveConnector | 10 minuti per i connettori di ricezione nel servizio di trasporto sui server Cassette postali | Questo parametro consente di specificare il tempo massimo per il quale una connessione SMTP con il server di messaggistica di origine può restare aperta anche se è in corso la trasmissione di dati dal server. Il valore di questo parametro deve essere maggiore del valore del parametro ConnectionInactivityTimeout . |
| ConnectionInactivityTimeOut in Set-SendConnector | 10 minuti | Questo parametro consente di specificare il tempo massimo per il quale una connessione SMTP aperta con un server di messaggistica di destinazione può restare inattiva prima che venga chiusa. |
Modalità di manutenzione dei messaggi shadow
Dopo aver creato correttamente un messaggio shadow, il lavoro della ridondanza shadow è appena cominciato. Il server primario e il server shadow devono rimanere in contatto per tenere traccia dell'avanzamento del messaggio.
Quando il server primario trasmette correttamente il messaggio all'hop successivo e l'hop successivo conferma la ricezione del messaggio, il server primario aggiorna lo stato di rimozione del messaggio impostandolo come recapito completato. Lo stato di rimozione è fondamentalmente un messaggio che contiene un elenco di messaggi monitorati. Un messaggio recapitato correttamente non deve essere mantenuto in una coda shadow; nel momento in cui il server shadow sa che il server primario ha trasmesso correttamente il messaggio all'hop successivo, il server shadow sposta il messaggio shadow dalla coda shadow a Safety Net.
Il server shadow determina lo stato di rimozione dei messaggi shadow nelle code shadow interrogando il server primario. Se il server shadow apre una sessione SMTP con il server primario per un qualunque motivo (compresa la trasmissione di altri messaggi non correlati), il server shadow invia il comando XQDISCARD per determinare lo stato di rimozione dei messaggi primari. In caso contrario, il server shadow aprirà automaticamente una sessione SMTP con il server primario dopo un intervallo di tempo preconfigurato (il parametro ShadowHeartbeatFrequency nel cmdlet Set-TransportConfig ; il valore predefinito è 2 minuti).
Dopo che il server shadow ha aperto una sessione SMTP con il server primario, questo risponde con le notifiche di rimozione per i messaggi corrispondenti al server shadow che esegue la query. Le notifiche di rimozione vengono archiviate sul disco (non in memoria) quindi, se il servizio di trasporto Microsoft Exchange viene riavviato, tali notifiche persistono. Dopo l'avvio del servizio, il server primario conosce ancora i messaggi elaborati correttamente e tali informazioni sono disponibili per il server shadow.
La comunicazione SMTP tra il server shadow e il server primario è utilizzata come heartbeat che determina la disponibilità dei server. Se il server shadow non può aprire una sessione SMTP con il server primario dopo un intervallo di tempo preconfigurato (il parametro ShadowResubmitTimeSpan nel cmdlet Set-TransportConfig; il valore predefinito è 3 ore), il server shadow alza il suo livello a quello di server primario, alza di livello i messaggi shadow trasformandoli in messaggi primari e trasmette i messaggi all'hop successivo. Tuttavia, ogni volta che il server shadow rileva che l'ID del database delle code del server primario viene modificato, il server shadow alza di livello anche i messaggi shadow trasformandoli in messaggi primari e trasmette i messaggi all'hop successivo. Ciò potrebbe verificarsi anche prima che venga superato il valore del parametro ShadowResubmitTimeSpan.
Shadow Redundancy Manager è il componente principale di un server Cassette postali, responsabile della gestione della ridondanza shadow. Shadow Redundancy Manager è responsabile del mantenimento delle informazioni seguenti per tutti i messaggi principali che un server sta attualmente elaborando:
Server shadow per ogni messaggio principale in fase di elaborazione.
Stato di eliminazione da inviare al server shadow.
Shadow Redundancy Manager è responsabile di quanto segue per tutti i messaggi shadow presenti nelle code shadow di un server shadow:
Mantenimento dell'elenco di server primari per ogni messaggio shadow.
Confronto tra l'ID database originale e l'ID database corrente del database delle code in cui è archiviata la copia primaria del messaggio.
Controllo della disponibilità di ogni server primario per cui viene messo in coda un messaggio shadow.
Elaborazione delle notifiche di eliminazione provenienti dai server primari.
Rimozione dei messaggi shadow provenienti dalle code shadow dopo la ricezione di tutte le notifiche di rimozione previste.
Decisione del momento in cui il server shadow deve assumere la proprietà dei messaggi shadow, divenendo server primario.
Verifica delle biforcazioni dei messaggi e di altri messaggi con effetto collaterale, quali notifiche sullo stato del recapito (denominate anche DSN, rapporti di mancato recapito, NDR o notifiche di mancato recapito) e rapporti del journal, per verificare che la copia ridondante del messaggio non venga rilasciata finché non sono state elaborate tutte le biforcazioni del messaggio.
Nella tabella seguente sono descritti i parametri che controllano la gestione dei messaggi shadow.
| Parametro | Valore predefinito | Descrizione |
|---|---|---|
| ShadowHeartbeatFrequency in Set-TransportConfig | 2 minuti | Il tempo massimo atteso da un server shadow prima di aprire una connessione SMTP al server primario per verificare lo stato di rimozione dei messaggi. |
| ShadowResubmitTimeSpan in Set-TransportConfig | 3 ore | Il tempo che un server attende prima di decidere che si è verificato un errore in un server primario e di acquisire la proprietà dei messaggi shadow nella coda shadow per il server primario che non è raggiungibile. Tenere presente che un server shadow può alzare di livello anche se stesso diventando server primario prima del valore di questo parametro quando si rileva che il database delle code del server primario ha un ID database diverso. |
| ShadowMessageAutoDiscardInterval in Set-TransportConfig | 2 giorni | Il tempo per cui un server conserva gli eventi di rimozione per i messaggi recapitati correttamente. Un server principale mette in coda gli eventi di eliminazione fino all'interrogazione da parte di un server shadow. Tuttavia, se il server shadow non interroga il server primario per la durata specificata in questo parametro, il server primario elimina gli eventi in coda. |
| SafetyNetHoldTime in Set-TransportConfig | 2 giorni | Il tempo di conservazione in Safety Net dei messaggi elaborati correttamente. I messaggi shadow non riconosciuti alla fine scadono da Safety Net dopo la somma dei valori dei parametri SafetyNetHoldTime e MessageExpirationTimeout nel cmdlet Set-TransportService . |
| MessageExpirationTimeout in Set-TransportService | 2 giorni | Quanto tempo un messaggio può rimanere in coda prima della scadenza. |
Elaborazione del messaggio dopo un'interruzione
Nella tabella seguente viene fornito un riepilogo su come la ridondanza shadow consente di ridurre al minimo la perdita di messaggi a causa di interruzioni del server. Per ragioni di chiarezza, il server che ha subito un'interruzione è denominato Mailbox01.
| Scenario di ripristino | Azioni intraprese |
|---|---|
| Mailbox01 torna disponibile online con un nuovo database delle code prima che venga superato il valore del parametro ShadowResubmitTimeSpan (per impostazione predefinita, 3 ore). Questo scenario può verificarsi quando il database delle code è irreversibile a causa di errori hardware o danneggiamento dei dati. |
Quando l'ID del nuovo database delle code viene rilevato in Mailbox01, ogni server che presenta messaggi shadow in coda per Mailbox01 assume la proprietà di tali messaggi e li invia nuovamente. I messaggi vengono quindi recapitati alle loro destinazioni. Il ritardo massimo per l'invio di messaggi dopo il rilevamento del nuovo database della coda è il valore del parametro ShadowHeartbeatFrequency (per impostazione predefinita, 2 minuti). |
| Mailbox01 torna online con lo stesso database dopo il superamento del valore del parametro ShadowResubmitTimeSpan (per impostazione predefinita, 3 ore). Questo scenario può verificarsi in seguito a un errore di schede di rete o a operazioni di manutenzione che richiedono molto tempo nel server. |
Dopo il ritorno online di Mailbox01, vengono recapitati i messaggi nelle relative code, che potrebbero già essere stati recapitati dai server che possiedono le copie shadow dei messaggi per Mailbox01. Ciò causerà il recapito duplicato di tali messaggi. Gli utenti delle cassette postali di Exchange non vedranno i messaggi duplicati grazie al rilevamento dei messaggi duplicati. Tuttavia, i destinatari su altri sistemi di messaggistica potranno visualizzare copie duplicate dei messaggi. Il ritardo massimo per l'invio di messaggi è il valore del parametro ShadowResubmitTimeSpan . |