Informazioni sulla ridondanza shadow

Si applica a: Exchange Server 2010

Ultima modifica dell'argomento: 2010-01-25

Le strategia di disponibilità elevata per Exchange sono state concentrate sulla disponibilità e la recuperabilità dei dati archiviati nei database delle cassette postali. Quando si implementa una soluzione altamente disponibile per i server Cassette postali, i messaggi di posta elettronica non andranno persi e saranno facilmente recuperabili dopo un errore, una volta recapitati in una cassetta postale. 

Queste strategie, tuttavia, non si estendono ai messaggi in transito. Se si verifica un errore irreversibile nel server Trasporto Hub durante l'elaborazione dei messaggi, può verificarsi la perdita di dati. Con l'aumentare del volume dei messaggi elaborati dai server Trasporto Hub, la potenziale perdita di dati diventa una preoccupazione sempre maggiore per gli amministratori.

Exchange Server 2007 ha introdotto la funzionalità Dumpster per il ruolo del server Trasporto Hub. Un server Trasporto Hub di Exchange 2007 mantiene una coda dei messaggi recapitati recentemente le cui cassette postali si trovano in un server Cassette postali in cluster. Quando si verifica un failover, il server Cassette postali in cluster richiede automaticamente a ogni server Trasporto Hub del sito Active Directory di inviare nuovamente la posta a partire dalla coda del dumpster di trasporto. Ciò impedisce la perdita di posta durante il tempo impiegato per il failover del cluster. Sebbene in questo modo venga fornito un livello di base di ridondanza del trasporto, questo sistema è disponibile esclusivamente per il recapito di messaggi in un ambiente di replica continua in cluster (CCR) e non risolve la potenziale perdita di messaggi in transito tra i server Trasporto Hub e server Trasporto Edge.

Exchange Server 2010 introduce la ridondanza shadow per garantire la ridondanza dei messaggi per l'intera fase di transito. La soluzione richiede una tecnica simile al dumpster di trasporto. Con la ridondanza shadow, l'eliminazione di un messaggio dal database di trasporto viene ritardata finché il server di trasporto non verifica che è stato completato il recapito di tutti gli hop successivi per tale messaggio. Se qualsiasi degli hop successivi non riesce prima di comunicare il recapito corretto, il messaggio viene nuovamente inviato per il recapito a tale hop successivo. 

La ridondanza shadow fornisce i vantaggi seguenti:

• Non fa affidamento sullo stato di alcun server Trasporto Hub e Trasporto Edge specifico. Finché sono presenti percorsi dei messaggi ridondanti nella topologia di routing, qualsiasi server di trasporto diventa eliminabile.
• In caso di errore di un server di trasporto, è possibile rimuoverlo dalla produzione senza svuotarne le code e senza perdere messaggi.
• Se si desidera aggiornare un server Trasporto Hub o Trasporto Edge, è possibile portare offline tale server in qualsiasi momento senza il rischio di perdere messaggi.
• Elimina l'esigenza di ridondanza dell'hardware di archiviazione per i server di trasporto.
• Consuma meno larghezza di banda rispetto alla creazione di copie duplicate dei messaggi su più server. Il solo traffico di rete aggiuntivo creato con la ridondanza shadow è lo scambio dello stato di eliminazione tra server di trasporto. Lo stato di eliminazione costituisce le informazioni mantenute da ogni server di trasporto. Indica quando un messaggio è pronto per essere eliminato dal database di trasporto.
• Fornisce la flessibilità e semplifica il ripristino da un errore del server di trasporto.

La ridondanza shadow è implementata dall'estensione servizio SMTP. Le estensioni servizio consentono agli host SMTP di negoziare il supporto della ridondanza shadow e scambiare lo stato eliminazione per i messaggi shadow.

Per informazioni sulle altre attività di gestione relative alla gestione dei server di trasporto, vedere Gestione dei server di trasporto.

Sommario

Componenti della ridondanza shadow

Flusso dei messaggi con ridondanza shadow

Shadow Redundancy Manager

Elaborazione del messaggio dopo un'interruzione

Diritti estesi richiesti per la ridondanza shadow

Componenti della ridondanza shadow

Nella tabella seguente vengono fornite descrizioni di tutti i componenti di ridondanza shadow.

Componenti della ridondanza shadow

Componente	Descrizione
Messaggio principale	Messaggio originale inviato al trasporto per il recapito.
Messaggio shadow	Copia di un messaggio che un server di trasporto mantiene finché non verifica il corretto recapito di tutti gli hop successivi per tale messaggio.
Server primario	Server di trasporto che sta attualmente elaborando un messaggio.
Server shadow	Server di trasporto che contiene le copie shadow di un messaggio dopo il recapito del messaggio al server primario.
Coda shadow	Coda che utilizza un server di trasporto per archiviare i messaggi shadow. Un server di trasporto avrà code shadow separate per ogni hop a cui ha recapitato il messaggio principale.
Stato di eliminazione	Informazioni mantenute da un server di trasporto per i messaggi shadow che indicano quando un messaggio è pronto per l'eliminazione.
Notifica di eliminazione	Risposta che un server shadow riceve da un server primario che indica che un messaggio è pronto per l'eliminazione.
Shadow Redundancy Manager	Componente di trasporto che gestisce la ridondanza shadow.
Heartbeat	Processo con cui i server di trasporto verificano la reciproca disponibilità.

Inizio pagina

Flusso dei messaggi con ridondanza shadow

Per illustrare il flusso di posta con la ridondanza shadow abilitata, considerare uno scenario semplice in cui un server Trasporto Hub invia un messaggio a un server di posta di terza parte tramite un server Trasporto Edge nella rete perimetrale.

Flusso dei messaggi con ridondanza shadow

In questo scenario, il flusso di messaggi passa attraverso le fasi seguenti:

1. Il server Trasporto Hub recapita un messaggio al server Trasporto Edge.
   1. Il server Trasporto Hub apre una sessione SMTP con il server Trasporto Edge.
   2. Il server Trasporto Edge annuncia il supporto per la ridondanza shadow.
   3. Il server Trasporto Hub notifica al server Trasporto Edge di tenere traccia dello stato eliminazione.
   4. Il server Trasporto Hub invia il messaggio al server Trasporto Edge.
   5. Il server Trasporto Edge conferma la ricezione del messaggio e registra il nome del server Trasporto Hub per l'invio delle informazioni di eliminazione per il messaggio.
   6. Il server Trasporto Hub sposta il messaggio nella coda shadow per il server Trasporto Edge e contrassegna il server Trasporto Edge come server primario. Il server Trasporto Hub diventa il server shadow.
2. Il server Trasporto Edge recapita il messaggio all'hop successivo.
   1. Il server Trasporto Edge invia il messaggio a un server di posta di terza parte.
   2. Il server di posta di terze parte conferma la ricezione del messaggio.
   3. Il server Trasporto Edge aggiorna lo stato di eliminazione per il messaggio indicando il recapito completato.
3. Il server Trasporto Hub esegue una query al server Trasporto richiedendo lo stato di eliminazione (in caso di esito positivo).
   1. Al termine di ogni sessione SMTP con il server Trasporto Edge, il server Trasporto Hub esegue una query al server Trasporto Edge richiedendo lo stato di eliminazione per i messaggi precedentemente inviati. Se il server Trasporto Hub non ha aperto alcuna sessione SMTP con il server Trasporto Edge dopo l'invio del messaggio iniziale, aprirà una sessione SMTP con il server Trasporto Edge esclusivamente per eseguire una query relativa sullo stato di eliminazione dopo un intervallo di tempo specifico.
   2. Il server Trasporto Edge controlla lo stato di eliminazione locale, restituisce l'elenco dei messaggi recapitati e rimuove le informazioni di eliminazione.
   3. Il server Trasporto Hub elimina l'elenco di messaggi dalla propria coda shadow.
4. Il server Trasporto Hub esegue una query al server Trasporto Edge richiedendo lo stato di eliminazione e invia nuovamente il messaggio (in caso di esito negativo).

   1. Se il server Trasporto Hub non è in grado di contattare il server Trasporto Edge, il server Trasporto Hub ripristina il ruolo di server primario e invia nuovamente i messaggi nella coda shadow.

   2. I messaggi inviati nuovamente vengono recapitati a un altro server Trasposto Edge e il flusso di lavoro inizia dalla fase 1.

      Nota

      Se non vi sono route alternative per un messaggio shadow (come nel caso del secondo server Trasporto Edge riportato nella figura precedente), tale messaggio non inviato nuovamente bensì resterà nella coda shadow.

Per ulteriori informazioni sul flusso dei messaggi in scenari diversi, vedere Scenari del flusso di posta con ridondanza shadow.

Scenario con più hop

Se un messaggio passa per più server che supportano la ridondanza shadow, i messaggi shadow vengono mantenuti in un server solo finché il server successivo nel percorso del messaggio non conferma il recapito. Per illustrarne il funzionamento, considerare un'organizzazione che abbia cinque siti Active Directory con installati server Trasporto Hub. I siti sono connessi tra loro come illustrato nella figura seguente. L'organizzazione ha siti a New York e a Londra configurati come siti hub, pertanto i messaggi da Chicago o Atlanta devono passare per i server Trasporto Hub dei siti di New York e Londra per raggiungere il sito di Dublino.

Topologia di esempio per uno scenario con più hop

Supporre che venga inviato un messaggio da un utente del sito di Chicago a un utente del sito di Dublino. Il messaggio dovrà passare per i siti di New York e Londra per raggiungere Dublino. In questo caso, si verifica quando segue:

1. Il server Trasporto Hub di Chicago invia il messaggio al server Trasporto Hub di New York e mantiene una copia shadow del messaggio.
2. Il server Trasporto Hub di New York invia il messaggio al server Trasporto Hub di Londra e mette in coda uno stato di eliminazione per l'hub di Chicago.
3. L'hub di Chicago esegue una query all'hub di New York richiedendo lo stato di eliminazione e riceve la notifica di eliminazione per il messaggio. A questo punto, può rimuovere il messaggio shadow dal proprio database. Se il messaggio viene o meno recapitato da Londra a Dublino non ha impatto sul momento in cui il server di Chicago elimina il messaggio shadow.

Interoperabilità

Se la ridondanza shadow viene utilizzata o meno viene deciso quando viene stabilita una nuova connessione SMTP. Se entrambi i server in una connessione SMTP supportano la ridondanza shadow, viene utilizzato il flusso di lavoro precedentemente indicato. Vi sono tuttavia situazioni in cui i server di trasporto Exchange 2010 scambiano messaggi con server di posta che non supportano la ridondanza shadow. Può trattarsi di server di posta di terze parti, di versioni precedenti di Exchange o di un'organizzazione Exchange 2010 che non ha abilitato la ridondanza shadow.

Quando un server di trasporto Exchange 2010 che supporta la ridondanza shadow stabilisce una connessione con un server che non supporta la ridondanza shadow, si verificano gli eventi seguenti:

1. Exchange stabilisce una connessione SMTP al server di destinazione.
2. Il server di destinazione non annuncia il supporto per la ridondanza shadow.
3. Poiché il server di destinazione non supporta la ridondanza, Exchange effettuerà le seguenti operazioni per ogni messaggio:
   1. Recapito del messaggio al server di destinazione.
   2. Shadow Redundancy Manager indica che il messaggio verrà recapitato all'hop successivo.
   3. Eliminazione del messaggio dopo che viene recapitato a tutti gli hop successivi.

Quando un server che non supporta la ridondanza shadow stabilisce una connessione con un server Exchange 2010, si verificano gli eventi seguenti:

1. Il server mittente stabilisce una connessione SMTP con Exchange.
2. Exchange dichiara di supportare la ridondanza shadow.
3. Il server mittente non supporta la ridondanza shadow e pertanto non la utilizza. Recapita i messaggi al server Exchange.
4. Per ogni messaggio ricevuto da Exchange, effettua le operazioni seguenti:
   1. Recapita li messaggio all'hop successivo o crea una copia shadow di tale messaggio.
   2. Invia la conferma al il server mittente.

Conferma ritardata

Il principio fondamentale alla base della ridondanza shadow consiste nel mantenere una copia del messaggio sull'hop precedente finché il server non verifica che è stato correttamente recapitato a tutti gli hop successivi. Ciò non è possibile quando un server di trasporto Exchange 2010 riceve un messaggio da un server di posta che non supporta la ridondanza shadow. Questo server di posta può essere un server Exchange che esegue una versione precedente di Exchange, un client SMTP standard o un server di posta non Exchange in Internet. In questo caso, Exchange tenta di ottenere la ridondanza shadow ritardando la conferma al server di posta finché non verifica che tale messaggio è stato recapitato correttamente a tutti gli hop successivi internamente. In questo modo, se si verifica un errore del server Exchange 2010, il server di posta mittente presuppone che il messaggio non sia stato recapitato a Exchange e prova a recapitarlo nuovamente.

Tuttavia, il recapito del messaggio agli hop successivi può richiedere molto tempo a causa della complessità dell'infrastruttura di routing o dell'errore di uno degli hop successivi. In questo caso, per evitare il timeout della sessione SMTP, il server di trasporto Exchange 2010 invia una conferma al server di posta mittente. In questo modo, la ridondanza della posta non è garantita, ma si tratta del massimo sforzo. Ad esempio, un messaggio può andare perso nel seguente scenario: Un server di posta Internet trasmette un messaggio a un server Trasporto Edge. Il server Trasporto Edge non è in grado di comunicare con il server Trasporto Hub a causa di un problema di rete e conferma la ricezione del messaggio al server di posta Internet. Si verifica quindi un errore nel server Trasporto Edge che non può essere ripristinato finché non viene risolto il problema di rete. A questo punto, il messaggio viene perso.

Il valore di timeout della conferma ritardata è controllato dall'attributo MaxAcknowledgementDelay di ogni connettore di ricezione. Il valore predefinito è 30 secondi. Per ulteriori informazioni sulla configurazione di questo attributo, vedere Configurazione della ridondanza shadow.

Inizio pagina

Shadow Redundancy Manager

Shadow Redundancy Manager è il componente principale di un server di trasporto Exchange 2010, 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:

• Mantenimento dell'elenco di server primari per ogni messaggio shadow.
• 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 dal database dopo la ricezione di tutte le notifiche di eliminazione previste.
• Decisione del momento in cui il server shadow deve assumere la proprietà dei messaggi shadow, divenendo server primario.

Inoltre, Shadow Redundancy Manager è anche responsabile della gestione dei contatori delle prestazioni relativi alla ridondanza shadow.

Heartbeat

Shadow Redundancy Manager utilizza heartbeat per determinare la disponibilità dei server per i quali vengono messi in coda messaggi shadow. Durante la sessione SMTP tra due server che supportano entrambi la ridondanza shadow, il server che avvia la connessione esegue una query al server di destinazione richiedendo lo stato di eliminazione dei messaggi precedentemente inviati a tale server, inviando un comando XQUERYDISCARD. In risposta, il server di destinazione restituisce le notifiche di eliminazione. Questo scambio tra i due server viene utilizzato come heartbeat per la ridondanza shadow.

È presente un valore di timeout per l'heartbeat. Se non viene stabilita alcuna connessione a un server per il quale Shadow Redundancy Manager sta mantenendo una coda shadow per tale durata, il server tenta di stabilire una connessione SMTP con il server primario specificamente per eseguire una query sullo stato di eliminazione e reimpostare il timer. Il valore di timeout è controllato dal parametro ShadowHeartbeatTimeoutInterval del cmdlet Set-TransportConfig ed è impostato su 300 secondi per impostazione predefinita.

Se il server non è in grado di stabilire una connessione a un server primario quando viene raggiunto il valore di timeout, reimposterà il timer e proverà nuovamente. Se il valore di timeout viene raggiunto per tre volte di fila, il server concluderà che si è verificato un errore nel server primario, assumerà la proprietà dei messaggi shadow e inizierà a generare notifiche di eliminazione per tali messaggi da inviare al server primario che ha presentato errore. Il numero di timeout per cui un server attende prima di decidere che un server primario si trova in stato di errore è controllato dal parametro ShadowHeartbeatRetryCount del cmdlet Set-TransportConfig.

Per ulteriori informazioni sulla configurazione dell'heartbeat della ridondanza shadow, vedere Configurazione della ridondanza shadow.

Inizio pagina

Elaborazione del messaggio dopo un'interruzione

La ridondanza shadow consente di ridurre al minimo la perdita di messaggi a causa di interruzioni del server. Quando un server di trasporto torna in linea dopo un'interruzione, si possono presentare due scenari:

• Il server torna in linea con un nuovo database di trasporto   In questo scenario, il database di trasporto non può essere recuperato a causa del danneggiamento dei dati o di un errore hardware. In questo caso, poiché il server di trasporto avrà un nuovo ID database, sarà riconosciuto come nuova route dagli altri server di trasporto dell'organizzazione. Ciò si applica anche alla situazione in cui non è possibile recuperare un server e viene fornito un nuovo server in sostituzione.
• Il server torna in linea con lo stesso database di trasporto   In questo scenario, non si verifica un errore del particolare server di trasporto ma tale server resta non in linea per un periodo di tempo prolungato. Questo scenario può essere causato, ad esempio, da un errore della scheda di rete o da una manutenzione prolungata sul server.

Nella tabella seguente viene riepilogato come il trasporto reagisce a questi scenari quando è abilitata la ridondanza shadow. Per chiarezza, presupporre che il server che ha avuto l'interruzione sia denominato Hub01.

Elaborazione dei messaggi negli scenari di ripristino

Scenario di ripristino	Azioni intraprese per i messaggi che dispongono di route alternative	Azioni intraprese per i messaggi che non dispongono di route alternative
Hub01 torna in linea con un nuovo database.	Quando Hub01 diventa non disponibile, ogni server che presenta messaggi shadow in coda per Hub01 assume la proprietà di tali messaggi e li invia nuovamente. I messaggi vengono quindi recapitati alle loro destinazioni mediante route alternative. Il ritardo totale per i messaggi e parti al prodotto dell'intervallo di timeout heartbeat per il numero di tentativi di heartbeat configurato nell'organizzazione.	Questi messaggi restano nella coda shadow su ogni server che presenta messaggi shadow in coda per Hub01. Quando Hub01 torna in linea con un nuovo ID database, i server shadow rilevano che si tratta di un nuovo database e inviano nuovamente i messaggi contenuti nella coda shadow a Hub01. Ciò equivale a rilevare improvvisamente una route alternativa per tali messaggi. Il ritardo totale dei messaggi dipende dalla durata dell'interruzione.
Hub01 torna in linea con lo stesso database.	Hub01 recapiterà i messaggi presenti nelle code. Ciò causerà il recapito duplicato di tali messaggi. Gli utenti delle cassette postali Exchange non vedrà i messaggi duplicati grazie al rilevamento dei messaggi duplicati. Tuttavia, i destinatari su sistemi esterni potrebbero ricevere copie duplicate. Il ritardo totale per i messaggi e parti al prodotto dell'intervallo di timeout heartbeat per il numero di tentativi di heartbeat configurato nell'organizzazione.	Hub 01 recapiterà i messaggi nelle code e quindi invierà le notifiche di eliminazione ai server shadow. Il ritardo totale dei messaggi dipende dalla durata dell'interruzione.

Inizio pagina

Diritti estesi richiesti per la ridondanza shadow

In Exchange 2010 vengono introdotti i diritti estesi seguenti, richiesti per la ridondanza shadow:

• ms-Exch-SMTP-Accept-XSHADOW
• ms-Exch-SMTP-Send-XSHADOW

Quando viene stabilita una connessione SMTP a un server di trasporto Exchange 2010, verrà annunciato il supporto della ridondanza shadow se nel connettore di ricezione utilizzato è presente il diritto esteso ms-Exch-SMTP-Accept-XSHADOW. Inoltre, il meccanismo di autenticazione nel connettore di ricezione deve essere l'autenticazione Exchange Server o Protetto esternamente.

Quando un server di trasporto Exchange 2010 stabilisce una connessione SMTP con un altro server di trasporto che annuncia il supporto per la ridondanza shadow, invia un comando XSHADOW solo se la sessione ha concesso il diritto esteso ms-Exch-SMTP-Send-XSHADOW.

Per impostazione predefinita, questi diritti estesi sono concessi al gruppo di server di Exchange su tutti i connettori di invio e di ricezione interni.

Nota

La ridondanza shadow può essere abilitata o disabilitata per l'intera organizzazione utilizzando il parametro ShadowRedundancyEnabled del cmdlet Set-TransportConfig. Questa impostazione sostituisce i diritti estesi descritti in questa sezione. Se la ridondanza shadow è disabilitata per l'organizzazione, Exchange non annuncerà mai il supporto per la ridondanza shadow né invierà comandi XSHADOW anche se i diritti estesi necessari sono stati concessi alla sessione SMTP.

Inizio pagina