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.

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.