Informazioni sulla ridondanza shadow
Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Ultima modifica dell'argomento: 2015-03-09
Le strategia di alta disponibilità per Exchange sono state concentrate sulla disponibilità e sulla 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 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 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 dai database di trasporto viene ritardata fin quando il server di trasporto non verifica che tutti gli hop successivi per quel messaggio hanno completato il recapito. Nel caso di errore negli hop successivi prima che venga segnalato il completamento del recapito, il messaggio viene inviato nuovamente all'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.
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
.gif "Flusso di posta con ridondanza shadow")
In questo scenario, il flusso di messaggi passa attraverso le fasi seguenti:
Il server Trasporto Hub recapita un messaggio al server Trasporto Edge.
Il server Trasporto Hub apre una sessione SMTP con il server Trasporto Edge.
Il server Trasporto Edge annuncia il supporto per la ridondanza shadow.
Il server Trasporto Hub notifica al server Trasporto Edge di tenere traccia dello stato eliminazione.
Il server Trasporto Hub invia il messaggio al server Trasporto Edge.
Il server Trasporto Edge conferma la ricezione del messaggio e registra l'identità del server Trasporto Hub per l'invio delle informazioni di eliminazione per il messaggio.
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.
Il server Trasporto Edge recapita il messaggio all'hop successivo.
Il server Trasporto Edge invia il messaggio a un server di posta di terza parte.
Il server di posta di terze parte conferma la ricezione del messaggio.
Il server Trasporto Edge aggiorna lo stato di eliminazione per il messaggio indicando il recapito completato.
Il server Trasporto Hub esegue una query al server Trasporto richiedendo lo stato di eliminazione (in caso di esito positivo).
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.
Il server Trasporto Edge controlla lo stato di eliminazione locale, restituisce l'elenco dei messaggi recapitati e rimuove le informazioni di eliminazione.
Il server Trasporto Hub elimina l'elenco di messaggi dalla propria coda shadow.
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).
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.
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
.gif "Esempio di topologia complessa")
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:
Il server Trasporto Hub di Chicago invia il messaggio al server Trasporto Hub di New York e mantiene una copia shadow del messaggio.
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.
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.
Protezione della ridondanza shadow quando i ruoli del server Trasporto Hub e Cassette Postali coesistono con i gruppi di disponibilità del database (DAG)
Quando si utilizzano i gruppi di disponibilità del database (DAG), i messaggi già salvati nei database delle cassette postali sono protetti con l'architettura DAG. Per ogni messaggio recapitato a un database delle cassette postali appartenente a un DAG, la copia shadow del messaggio viene conservata nel dumpster di trasporto fino alla replica del messaggio in tutti i membri del DAG. Allo stesso modo, ogni messaggio inviato ai server Trasporto Hub da un membro del DAG dispone di due copie, una nella coda del server Trasporto Hub in attesa di recapito e una copia shadow nella cartella Posta inviata del mittente. Questo tipo di approccio è un componente chiave della ridondanza shadow.
Tuttavia, quando i ruoli del server Trasporto Hub e Cassette postali coesistono nello stesso server e sono presenti database delle cassette postali che appartengono a un DAG, può essere necessario l'instradamento del messaggio da parte del server Trasporto Hub tramite un hop aggiuntivo, per fare in modo che il messaggio principale e il messaggio shadow non si trovino nello stesso hardware del server. In particolare, il ruolo del server Trasporto Hub cerca di evitare i due scenari seguenti, dal momento che un errore su un singolo server può determinare la perdita sia del messaggio principale che del messaggio shadow:
Durante il recapito del messaggio, laddove il database delle cassette postali attivo del destinatario del messaggio e il dumpster di trasporto contenente la copia shadow del messaggio si trovano sullo stesso server Per evitare questo tipo di scenario, il server Trasporto Hub instrada il messaggio tramite un altro server Trasporto Hub all'interno del sito per fare in modo che il messaggio shadow termini in un hardware del server diverso. Tuttavia, se non sono disponibili altri server Trasporto Hub, il messaggio viene recapitato direttamente.
Durante l'invio di un messaggio, laddove la coda di trasporto contenente il messaggio principale e il messaggio shadow della cartella Posta inviata del mittente si trovano sullo stesso server Per evitare questo tipo di scenario, il driver di archivio preferisce altri server Trasporto Hub nel sito per l'invio del messaggio. Tuttavia, se non sono disponibili altri server Trasporto Hub nel sito, il messaggio viene inviato al server Trasporto Hub locale.
Per ulteriori informazioni sulla coesistenza dei ruoli del server Trasporto Hub e Cassette postali quando si utilizzano i DAG, vedere Coesistenza dei ruoli del server Trasporto Hub e Cassette postali quando si utilizzano i DAG.
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:
Exchange stabilisce una connessione SMTP al server di destinazione.
Il server di destinazione non annuncia il supporto per la ridondanza shadow.
Poiché il server di destinazione non supporta la ridondanza, Exchange effettuerà le seguenti operazioni per ogni messaggio:
Recapito del messaggio al server di destinazione.
Shadow Redundancy Manager indica che il messaggio verrà recapitato all'hop successivo.
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:
Il server mittente stabilisce una connessione SMTP con Exchange.
Exchange dichiara di supportare la ridondanza shadow.
Il server mittente non supporta la ridondanza shadow e pertanto non la utilizza. Recapita i messaggi al server Exchange.
Per ogni messaggio ricevuto da Exchange, effettua le operazioni seguenti:
Recapita li messaggio all'hop successivo o crea una copia shadow di tale messaggio.
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.
Come ignorare la conferma ritardata
Esistono situazioni in cui è improbabile che un messaggio sia recapitato prima che venga raggiunto il timeout della conferma ritardata. In questi casi, il server di trasporto utilizza uno dei seguenti metodi per gestire i messaggi:
Ignorare la conferma ritardata Per impostazione predefinita, il server di trasporto ignora la conferma ritardata per mantenere la velocità effettiva di ricezione SMTP. In sintesi, il server di trasporto invia la conferma prima che venga raggiunto il timeout.
Promozione della ridondanza shadow In Microsoft Exchange Server 2010 Service Pack 1 (SP1), anziché ignorare la conferma ritardata, è possibile configurare il server di trasporto per l'inoltro del messaggio a un qualsiasi altro server di trasporto nel sito. In questo modo, il messaggio viene effettivamente inserito nella pipeline di ridondanza shadow e viene quindi protetto. Questo processo viene denominato promozione della ridondanza shadow. Se confrontato con il metodo che prevede di ignorare la conferma ritardata, questo tipo di approccio riduce al minimo il numero di messaggi non protetti nell'organizzazione. Per impostazione predefinita, questa funzionalità è disabilitata. Per abilitare la promozione della ridondanza shadow, un amministratore deve modificare il file Edgetransport.exe.config, modificare l'impostazione della chiave shadowredundancypromotionenabled su true, salvare le modifiche al file e quindi riavviare il servizio Trasporto di Microsoft Exchange (MSExchangeTransport.exe). Per ulteriori informazioni su come eseguire questa operazione, vedere la sezione "Abilitazione della promozione di ridondanza shadow" nell'argomento Configurazione della ridondanza shadow.
Nella tabella seguente sono riportati diversi scenari in cui un server di trasporto ignora la conferma ritardata e viene illustrata la modalità di gestione di ciascuno scenario da parte di un server Exchange 2010.
| Scenario | Comportamento predefinito di Exchange 2010 (ignorando la conferma ritardata) | Exchange 2010 SP1 con promozione della ridondanza shadow abilitata |
|---|---|---|
La coda di destinazione del messaggio è in stato sospeso o Riprova. |
Il server di trasporto di ricezione ignora la conferma ritardata. |
Il server di trasporto di ricezione utilizza immediatamente la promozione della ridondanza shadow. |
La coda di destinazione entra in stato Riprova dopo l'aggiunta del messaggio. |
Il server di trasporto di ricezione ignora la conferma ritardata per i messaggi successivi fino a quando la coda di destinazione non torna nello stato Pronto. |
Il server di trasporto di ricezione utilizza la promozione della ridondanza shadow per i messaggi successivi fino a quando la coda di destinazione non torna nello stato Pronto. |
Un amministratore sospende la coda di destinazione o il messaggio. |
Se l'amministratore sospende la coda di destinazione, il server di trasporto di ricezione ignora la conferma ritardata fino a quando la coda di destinazione non torna nello stato Pronto. Se l'amministratore sospende il messaggio, il server di trasporto di ricezione gestisce regolarmente i messaggi successivi. |
Se l'amministratore sospende la coda di destinazione, il server di trasporto di ricezione utilizza la promozione della ridondanza shadow fino a quando la coda di destinazione non torna nello stato Pronto. Se l'amministratore sospende il messaggio, il server di trasporto di ricezione gestisce regolarmente i messaggi successivi. |
La coda di destinazione del messaggio contiene più di 100 messaggi. |
Il server di trasporto di ricezione ignora la conferma ritardata fino a quando le dimensioni della coda di destinazione non scendono al di sotto di 100. |
Se la coda di destinazione contiene dei messaggi, il server di trasporto di ricezione utilizza la promozione della ridondanza shadow per i messaggi successivi fino allo svuotamento della coda. |
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. Il valore predefinito di questo parametro è 300 secondi nella versione RTM di Exchange 2010 e 900 secondi in Exchange 2010 SP1.
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 dodici volte di seguito (tre volte di seguito in Exchange 2010 RTM), il server ne dedurrà che si è verificato un errore nel server primario, assumerà la proprietà dei messaggi shadow e inizierà a generare notifiche di eliminazione per questi 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 è pari 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 alla sessione è stato 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
©2010 Microsoft Corporation. Tutti i diritti riservati.