Coesistenza dei ruoli del server Trasporto Hub e Cassette postali quando si utilizzano i DAG

 

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

Ultima modifica dell'argomento: 2015-03-09

Microsoft Exchange Server 2007 non supporta i ruoli del server Trasporto Hub e Cassette postali sullo stesso hardware del server quando vengono utilizzate funzionalità per l'elevata disponibilità, come il cluster a copia singola (SCC) o la replica continua cluster (CCR). Una distribuzione minima per l'elevata disponibilità in Exchange 2007 richiede quattro server: due nodi per l'elevata disponibilità delle cassette postali e due server Trasporto Hub per la ridondanza nel trasferimento dei messaggi.

Per ridurre il numero di server necessari per fornire una soluzione per l'elevata disponibilità, Exchange Server 2010 supporta i ruoli del server Trasporto Hub e Cassette postali sullo stesso hardware del server durante l'utilizzo dei gruppi di disponibilità del database (DAG). Exchange 2010 fornisce la funzionalità di ridondanza shadow, che impedisce la perdita dei dati durante il trasferimento dei messaggi. Se utilizzati contemporaneamente, i gruppi di disponibilità del database (DAG) e la ridondanza shadow offrono un'infrastruttura di messaggistica altamente resiliente.

In questo argomento viene descritto il comportamento del ruolo del server Trasporto Hub di Exchange 2010 se distribuito sullo stesso hardware di un server Cassette postali che partecipa a un gruppo di disponibilità del database. Per ulteriori informazioni sui gruppi di disponibilità del database, vedere Informazioni sui gruppi di disponibilità del database.

Invio e recapito dei messaggi

La ridondanza shadow impedisce la perdita dei dati durante il trasferimento dei messaggi, mantenendo una copia duplicata del messaggio durante tutto il trasferimento. Se un messaggio viene perso durante il trasferimento a causa di un errore, la copia shadow viene inviata di nuovo dal componente di trasporto. Per informazioni dettagliate sulla modalità di implementazione della ridondanza shadow, vedere Informazioni sulla ridondanza shadow.

I server Cassette postali sono coinvolti nell'invio iniziale dei messaggi, quando un utente seleziona Invia, e nel recapito finale, quando il messaggio viene salvato nella Posta in arrivo del destinatario. Quando un messaggio viene inviato al servizio di trasporto, la copia principale di tale messaggio si trova nelle code del server Trasporto Hub a cui è stato inviato il messaggio. La copia shadow di tale messaggio indica l'elemento archiviato nella cartella Posta inviata del mittente. Quando un messaggio viene recapitato, la copia principale si trova nella Posta in arrivo del destinatario, mentre la copia shadow viene archiviata nel dumpster di trasporto.

In uno scenario per l'elevata disponibilità in cui i ruoli del server Trasporto Hub e Cassette postali coesistono sullo stesso hardware del server, è fondamentale evitare di disporre di entrambe le copie di un messaggio sullo stesso server. Si consideri lo scenario di distribuzione illustrato nella figura seguente. La topologia è costituita da due server Exchange che partecipano a un gruppo di disponibilità del database con installato il ruolo del server Trasporto Hub. I database DB1 e DB2 appartengono al gruppo di distribuzione del database. I database attivi vengono visualizzati in verde, quelli passivi in blu.

Topologia per l'elevata disponibilità di due server con ruoli del server Trasporto Hub e Cassette postali

In questa topologia, si supponga che un utente, la cui cassetta postale si trova in DB1, invii un messaggio. Se tale messaggio viene inviato al ruolo del server Trasporto Hub su Server1, i messaggi principali e shadow verranno fisicamente archiviati in Server1. I messaggi principali si troveranno nelle code del server Trasporto Hub, mentre i messaggi shadow si troveranno nella cartella Posta inviata del mittente, come illustrato nella figura seguente.

Percorso di invio indesiderato

Analogamente, se il ruolo del server Trasporto Hub su Server1 riceve un messaggio destinato a un utente di DB1, il messaggio viene recapitato direttamente e i messaggi principali e shadow verranno fisicamente archiviati in Server1. I messaggi principali i si troveranno nella Posta in arrivo del destinatario, mentre i messaggi shadow si troveranno nel dumpster di trasporto, come illustrato nella figura seguente. Se si verifica un errore del server in una di queste istanze, è possibile che il messaggio venga perso.

Percorso di recapito indesiderato

Per evitare gli scenari in cui può verificarsi la perdita dei messaggi, Exchange tenta di inviare o recapitare i messaggi su una route che garantisce l'archiviazione delle copie principali e shadow su diversi server fisici. I comportamenti modificati di invio e recapito dei messaggi vengono descritti nella sezione seguente.

Comportamento di invio dei messaggi

Quando un utente la cui cassetta postale si trova in un database membro di un DAG invia un messaggio, viene data la precedenza ai server Trasporto Hub remoti se viene rilevata l'installazione del server Trasporto Hub anche sul server locale. Come illustrato nella figura "Topologia per l'elevata disponibilità di due server con ruoli del server Trasporto Hub e Cassette postali", se un utente la cui cassetta postale si trova in DB1 invia un messaggio, il servizio di invio della posta tenterà di utilizzare il server Trasporto Hub installato su Server2 per l'invio del messaggio. Nella figura seguente viene illustrato il percorso preferito per l'invio dei messaggi.

Percorso di invio preferito

Nel caso in cui nessun altro server Trasporto Hub sia disponibile nel sito (ad esempio, se Server2 non è disponibile a causa della manutenzione pianificata), il servizio di invio messaggi passerà l'invio del messaggio al server Trasporto Hub locale. Anche se si tratta di un percorso di invio indesiderato per la ridondanza, Exchange non ritarderà il recapito dei messaggi. Questo percorso di invio di fallback è consigliabile per la disponibilità e la scarsa latenza di recapito.

Comportamento di recapito dei messaggi

Nella maggior parte dei casi, il routing dei messaggi e il comportamento di recapito non cambia. Ad esempio, se Server1 illustrato nella figura "Topologia per l'elevata disponibilità di due server con ruoli del server Trasporto Hub e Cassette postali" riceve un messaggio per un destinatario di DB2, il messaggio verrà recapitato normalmente, perché tale database è attivo su un altro server. L'unico scenario in cui un server Trasporto Hub elabora un messaggio in arrivo in modo differente è quando la cassetta postale di destinazione si trova in un database appartenente a un DAG e risulta attiva anche sul server locale. Siccome un recapito diretto in questa situazione comporterebbe la presenza del messaggio recapitato e della copia per il dumpster di trasporto sullo stesso server, il server Trasporto Hub indirizzerà di nuovo il messaggio a un altro server Trasporto Hub all'interno dello stesso sito. Nella figura seguente viene illustrato il percorso di recapito dei messaggi in questo scenario.

Percorso di recapito preferito

Nel caso in cui nessun altro server Trasporto Hub sia disponibile nel sito, il server Trasporto Hub passerà al recapito locale, anche se si tratta di un percorso di recapito indesiderato per la ridondanza. Ancora una volta, questo percorso di recapito di fallback è consigliabile per la disponibilità e la scarsa latenza di recapito.

Scenari di flusso dei messaggi

In questa sezione viene descritto cosa accade in vari scenari di flusso dei messaggi quando i ruoli del server Trasporto Hub e Cassette postali coesistono sullo stesso server. La topologia visualizzata nella figura seguente viene utilizzata per illustrare vari scenari possibili di flusso dei messaggi.

Topologia di esempio per gli scenari di flusso dei messaggi

Nella tabella seguente viene visualizzata la modalità di elaborazione dei messaggi in vari scenari da parte del ruolo del server Trasporto Hub su Server1. In tutti i casi, Server1 viene considerato il punto di ingresso.

Posizione del mittente	Posizione del destinatario	Percorso del messaggio normale	Scenari per l'elevata disponibilità
DB1, attivo su Server1	DB1, attivo su Server1	Il servizio di invio su Server1 invia un messaggio al ruolo del server Trasporto Hub su Server2. Il ruolo del server Trasporto Hub su Server2 recapita il messaggio a DB1 su Server1 e aggiunge il messaggio al dumpster di trasporto su Server2.	Se l'operazione eseguita da Server1 non riesce prima del completamento dell'invio, il messaggio nella Posta in uscita del mittente potrebbe andare perso. Se l'operazione eseguita da Server2 non riesce prima del completamento dell'invio, il messaggio viene inviato al ruolo del server Trasporto Hub su Server1. Se l'operazione eseguita da Server1 non riesce una volta completato l'invio del messaggio al ruolo del server Trasporto Hub su Server2, DB1 diventerà attivo su Server2. Il messaggio verrà accodato su Server2 finché DB1 è montato, quindi il ruolo del server Trasporto Hub recapita il messaggio localmente. Se l'operazione eseguita da Server2 non riesce una volta completato l'invio del messaggio al ruolo del server Trasporto Hub su Server2, il messaggio shadow in DB1 viene inviato di nuovo al ruolo del server Trasporto Hub su Server1, che recapita il messaggio localmente. Se l'operazione eseguita da Server1 non riesce una volta completato il recapito del messaggio, DB1 diventerà attivo su Server2. Se il messaggio recapitato non viene salvato nel database, viene recapitato di nuovo dal dumpster di trasporto su Server2.
DB1, attivo su Server1	DB2, attivo su Server2	Il servizio di invio su Server1 invia il messaggio al ruolo del server Trasporto Hub su Server2. Il ruolo del server Trasporto Hub su Server2 indirizza di nuovo il messaggio al ruolo del server Trasporto Hub su Server1. Il ruolo del server Trasporto Hub su Server1 recapita il messaggio a DB2 su Server2 e aggiunge il messaggio al dumpster di trasporto su Server1.	Eventuali errori del server, precedenti al completamento dell'invio del messaggio, vengono gestiti come descritto nella riga precedente. Se l'operazione eseguita da Server1 non riesce una volta completato l'invio del messaggio al ruolo del server Trasporto Hub su Server2, il ruolo del server Trasporto Hub su Server2 recapiterà il messaggio localmente. Se l'operazione eseguita da Server2 non riesce una volta completato l'invio del messaggio al ruolo del server Trasporto Hub su Server2, DB2 diventerà attivo su Server1. Una volta rilevata la mancata disponibilità del ruolo del server Trasporto Hub su Server2, il ruolo del server Trasporto Hub su Server1 invierà di nuovo il messaggio shadow. Una volta montato DB2 su Server1, il messaggio verrà recapitato localmente. Se l'operazione eseguita da Server1 non riesce dopo che il messaggio è stato indirizzato di nuovo a Server1 per il recapito, il ruolo del server Trasporto Hub su Server2 invierà di nuovo il messaggio shadow dopo aver rilevato la mancata disponibilità del ruolo del server Trasporto Hub su Server1. Quindi, recapiterà il messaggio localmente. Se l'operazione eseguita da Server2 non riesce dopo che il messaggio è stato indirizzato di nuovo a Server1 per il recapito, DB2 diventerà attivo su Server1. Il messaggio rimarrà in coda su Server1 finché DB2 è montato su Server1, quindi viene recapitato localmente. Se l'operazione eseguita da Server2 non riesce una volta completato il recapito del messaggio, DB2 diventerà attivo su Server1. Se il messaggio recapitato non viene salvato nel database, viene recapitato di nuovo dal dumpster di trasporto su Server1.
Telefoni esterni	DB1, attivo su Server1	Il ruolo del server Trasporto Hub su Server1 indirizza di nuovo il messaggio al ruolo del server Trasporto Hub su Server2. Il ruolo del server Trasporto Hub su Server2 recapita il messaggio a DB1 su Server1 e aggiunge il messaggio al dumpster di trasporto su Server2.	Se l'operazione eseguita da Server1 non riesce prima del completamento della ricezione del messaggio da Edge1, Edge1 tenterà il recapito al ruolo del server Trasporto Hub su Server2. Se l'operazione eseguita da Server1 non riesce una volta completata la ricezione del messaggio da Edge1, Edge1 invierà di nuovo il messaggio al ruolo del server Trasporto Hub su Server2 dopo aver rilevato la mancata disponibilità del ruolo del server Trasporto Hub su Server1. Quindi, il ruolo del server Trasporto Hub su Server2 recapiterà il messaggio localmente una volta montato DB1 su Server2. Tutti gli altri scenari di errore vengono gestiti come descritto nella prima riga.
Telefoni esterni	DB2, attivo su Server2	Il ruolo del server Trasporto Hub su Server1 recapita il messaggio a DB2 su Server2 e aggiunge il messaggio al dumpster di trasporto su Server1.	Se l'operazione eseguita da Server1 non riesce prima del completamento della ricezione del messaggio da Edge1, Edge1 tenterà il recapito al ruolo del server Trasporto Hub su Server2. Se l'operazione eseguita da Server1 non riesce una volta completata la ricezione del messaggio da Edge1, ma prima del recapito a DB2 su Server2, Edge1 invierà di nuovo il messaggio shadow al ruolo del server Trasporto Hub su Server2. Questo perché Server1 non invierà una conferma a Edge1 finché il messaggio non viene recapitato correttamente a DB2. Siccome non ha ricevuto alcuna conferma, Edge1 invierà di nuovo il messaggio dopo aver rilevato la mancata disponibilità di Server1. Se l'operazione eseguita da Server2 non riesce una volta completato il recapito del messaggio, DB2 diventerà attivo su Server1. Se il messaggio recapitato non viene salvato nel database, viene recapitato di nuovo dal dumpster di trasporto su Server1.

Nella tabella precedente viene descritto lo scenario minimo in cui esistono solo due server Trasporto Hub in un sito coesistenti con i ruoli del server Cassette postali che partecipano ai DAG. Nelle distribuzioni più complesse in cui sono disponibili altri server Trasporto Hub dedicati, i server vengono utilizzati anche per le decisioni relative al routing. Tuttavia, se si dispone di una distribuzione abbastanza grande in cui è possibile utilizzare i server Trasporto Hub dedicati, si consiglia di non installare il ruolo del server Trasporto Hub sui server Cassette postali che partecipano a un DAG.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.