Scenari del flusso di posta con ridondanza shadow

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2010-06-07

La funzionalità di ridondanza shadow in Microsoft Exchange Server 2010 fornisce ridondanza ai messaggi per l'intera fase di transito. Il flusso generale dei messaggi viene descritto in Informazioni sulla ridondanza shadow. In questo argomento viene descritto in dettaglio cosa accade per ogni specifico scenario di flusso dei messaggi relativo a Exchange.

Scenari di flusso della posta

Nella seguente figura viene illustrato ogni possibile scenario con ridondanza in un'organizzazione di Exchange e il completamento della ridondanza nei messaggi per ogni scenario. L'area ombreggiata indica dove è impostata la ridondanza shadow. La ridondanza shadow di Exchange 2010 impedisce la perdita dei dati durante il transito dei messaggi all'interno dell'area ombreggiata.

Scenari di flusso della posta con ridondanza shadow

Come mostrato dalla precedente figura, tutti i percorsi di flusso della posta possibili in un'organizzazione di Exchange rientrano in uno dei seguenti scenari:

A. Invio client Windows Mobile/MAPI

B. Flusso della posta dal server Cassette postali al server Trasporto Hub

C. Recapito dei messaggi dal server Trasporto Hub al server Cassette postali

D. Flusso della posta tra server di trasporto di Exchange 2010

E. Flusso di posta dai server di trasporto di Exchange 2010 ai server di posta che non supportano la ridondanza shadow

F. Flusso di posta dai server di posta che non supportano la ridondanza shadow ai server di trasporto di Exchange 2010

Nelle seguenti sezioni viene descritto cosa accade per ogni scenario di flusso della posta.

A. Invio client Windows Mobile/MAPI

L'invio dei messaggi da client MAPI o Windows Mobile non è ridondante. Una volta archiviato correttamente il messaggio sul server Cassette postali, le funzionalità ad elevata disponibilità di Exchange sono effettive e consentono di impedire la perdita dei dati. Questo scenario offre un quadro completo del flusso dei messaggi, dall'inizio alla fine.

Torna all'elenco degli scenari del flusso di posta

B. Flusso della posta dal server Cassette postali al server Trasporto Hub

Le seguenti azioni si verificano quando un server Cassette postali di Exchange 2010 invia messaggi a un server Trasporto Hub di Exchange 2010.

1. Il servizio di invio della posta notifica al server Trasporto Hub la presenza di un nuovo messaggio.

2. Il server Trasporto Hub preleva il messaggio dalla Posta in uscita della cassetta postale che invia il messaggio e lo memorizza nel database.

3. Se il messaggio dispone di destinatari su server Cassette postali che si trovano nello stesso sito di Active Directory, il server Trasporto Hub recapita il messaggio alle cassette postali di destinazione, seguendo la procedura descritta nello scenario C. Per tutti gli altri destinatari, il server Trasporto Hub recapita il messaggio all'hop successivo.

4. Una volta completato il recapito all'hop successivo, il server Trasporto Hub notifica al server Cassette postali che ha terminato l'elaborazione del messaggio e ne ha acquisito la proprietà. Dopo questa notifica, il messaggio viene eliminato dalla Posta in uscita.

5. Se nessuno degli altri hop per il messaggio supporta la ridondanza shadow, il server Trasporto Hub elimina il messaggio. In caso contrario, converte il messaggio in un messaggio shadow memorizzandolo nelle code shadow per gli hop a cui ha recapitato il messaggio.

Torna all'elenco degli scenari del flusso di posta

C. Recapito dei messaggi dal server Trasporto Hub al server Cassette postali

Le seguenti azioni si verificano quando un server Trasporto Hub di Exchange 2010 recapita messaggi a un server Cassette postali di Exchange 2010.

1. Il server Trasporto Hub recapita il messaggio alle cassette postali di destinazione.

2. Una volta recapitato il messaggio a tutte le cassette postali di destinazione, il server Trasporto Hub aggiunge il messaggio al dumpster di trasporto.

3. Il server Trasporto Hub mette in coda le notifiche di eliminazione all'hop da cui ha ricevuto il messaggio. Queste notifiche di eliminazione vengono create quando l'hop esegue una query al server Trasporto Hub.

4. L'hop precedente elimina il messaggio shadow corrispondente.

Torna all'elenco degli scenari del flusso di posta

D. Flusso della posta tra server di trasporto di Exchange 2010

Il processo di flusso della posta è identico per tutti gli scambi di messaggi tra server di trasporto che eseguono Exchange 2010, se avviene tra due server Trasporto Hub o tra un server Trasporto Hub e un server Trasporto Edge. Le seguenti azioni si verificano quando un messaggio viene trasferito da un server di trasporto di Exchange 2010 a un altro. Per maggior chiarezza, si supponga che il server che sta inviando il messaggio sia denominato Hub01 e il server che sta ricevendo il messaggio sia denominato Edge01.

1. Hub01 stabilisce una connessione SMTP con Edge01.

2. Edge01 dichiara di supportare la ridondanza shadow.

3. Hub01 richiede la ridondanza shadow nella sessione SMTP emettendo un comando XSHADOW. Il processo è simile alla creazione di Transport Layer Security (TLS) per una sessione SMTP.

4. Per ogni messaggio che Hub01 deve inviare a Edge01:

   1. Hub01 trasmette il messaggio a Edge01.

   2. Edge01 contrassegna il messaggio come ombreggiato da Hub01.

   3. Hub01 contrassegna Edge01 come server primario e lo aggiunge alla coda shadow per Edge01.

   4. Hub01 prepara le notifiche di eliminazione per il messaggio da inviare all'hop da cui ha ricevuto il messaggio.

5. Hub01 esegue una query in Edge01 per lo stato di eliminazione dei messaggi precedentemente inviati a Edge01.

6. Edge01 invia tutte le notifiche di eliminazione preparate per Hub01. Potrebbero riguardare i messaggi inviati nella stessa sessione SMTP o quelli inviati durante sessioni SMTP precedenti.

7. Hub01 elimina tutti i messaggi shadow per i quali Edge01 ha inviato una notifica di eliminazione.

Torna all'elenco degli scenari del flusso di posta

E. Flusso di posta dai server di trasporto di Exchange 2010 ai server di posta che non supportano la ridondanza shadow

I server di trasporto di Exchange Server 2007 e i server testa di ponte di Exchange Server 2003 non supportano la ridondanza shadow. Pertanto, se si dispone di uno scenario di coesistenza con le versioni precedenti di Exchange, le funzionalità di ridondanza di Exchange 2010 possono garantire il recapito dei messaggi solo fino all'hop del server Exchange legacy e non fino alla destinazione finale. Lo stesso vale per lo scenario in cui i server Trasporto Edge di Exchange 2010 inviano messaggi ai server di posta non di Exchange.

Le seguenti azioni si verificano quando un server Trasporto Hub di Exchange 2010 invia un messaggio a un server di trasporto di Exchange che esegue una versione precedente di Exchange o quando un server Trasporto Edge di Exchange 2010 invia un messaggio a un server di posta non di Exchange. Per maggior chiarezza, si supponga che il server Trasporto Hub di Exchange 2010 denominato Hub01 stia inviando un messaggio al server di trasporto precedente di Exchange denominato Legacy01.

1. Hub01 stabilisce una connessione SMTP con Legacy01.

2. Legacy01 non dichiara di supportare la ridondanza shadow.

3. Siccome Legacy01 non ha dichiarato di supportare la ridondanza shadow, Hub01 non avvia la ridondanza shadow per la sessione SMTP.

4. Hub01 recapita il messaggio a Legacy01.

5. Hub01 elimina il messaggio.

6. Hub01 prepara le notifiche di eliminazione per l'hop da cui ha ricevuto il messaggio.

Torna all'elenco degli scenari del flusso di posta

F. Flusso di posta dai server di posta che non supportano la ridondanza shadow ai server di trasporto di Exchange 2010

Esistono quattro punti di ingresso a un'organizzazione di Exchange in cui un server di posta che non supporta la ridondanza shadow può stabilire una connessione SMTP a un server di trasporto di Exchange 2010 e inviare messaggi.

• Un server Messaggistica unificata di Exchange 2010 connesso a un server Trasporto Hub di Exchange 2010.

• Un server di trasporto di Exchange che esegue Exchange 2007 o Exchange 2003, connesso a un server Trasporto Hub di Exchange 2010.

• Un server di posta non di Exchange su Internet connesso a un server Trasporto Edge di Exchange 2010.

• Un server di posta non di Exchange nell'organizzazione, come un server UNIX, o un client SMTP che invia messaggi a un server Trasporto Hub di Exchange 2010.

In questo scenario, Exchange 2010 offre la ridondanza shadow utilizzando la funzionalità denominata conferma ritardata. Quando un server di trasporto di Exchange 2010 riceve un messaggio da un server di posta che non supporta la ridondanza shadow, ritarda l'invio della conferma al server di posta di invio fino alla conferma del corretto recapito del messaggio alla destinazione. Per ulteriori informazioni sulla conferma ritardata, vedere Informazioni sulla ridondanza shadow.

Per descrivere questo scenario, si supponga che il server Trasporto Edge di Exchange 2010 denominato Edge01 stia ricevendo un messaggio da un server di posta non di Exchange su Internet denominato Internet01. In questo esempio, si verificano le seguenti azioni:

1. Internet01 stabilisce una connessione SMTP con Edge01.

2. Edge01 dichiara di supportare la ridondanza shadow.

3. Siccome non supporta la ridondanza shadow, Internet01 invia semplicemente il messaggio a Edge01.

4. Edge01 contrassegna il messaggio come messaggio di conferma ritardata.

5. Edge01 recapita il messaggio agli hop successivi utilizzando la procedura descritta nello scenario D.

6. Edge01 esegue una query negli hop successivi per lo stato di eliminazione del messaggio.

7. Una volta che Edge01 riceve le notifiche di eliminazione da tutti gli hop successivi, invia la conferma a Internet01.

8. Edge01 elimina il messaggio dal database.

   Nota

   Se Edge01 non può verificare il corretto recapito del messaggio a tutti gli hop successivi in 30 secondi, resterà in attesa e invierà una conferma a Internet01. Questo valore di timeout viene controllato dal valore dell'attributo MaxAcknowledgementDelay del connettore di ricezione.

Torna all'elenco degli scenari del flusso di posta

 ©2010 Microsoft Corporation. Tutti i diritti riservati.