Exchange Queue & ABilanciamento del carico, Trasporto Edge e altro

Henrik Walther

D Nel nostro ambiente di produzione aziendale sono distribuiti diversi server con Microsoft® Office SharePoint® Server. Per trasmettere i messaggi in uscita, ognuno di questi server richiede la presenza di server di Trasporto Hub (HT) nella nostra infrastruttura in cui è stato appena distribuito Exchange Server 2007. Poiché un server SharePoint ci consente solo di specificare il nome di dominio completo (FQDN) di un singolo server SMTP (Exchange), nella pagina Amministrazione centrale | Operazioni | Impostazioni posta elettronica in uscita, come mostrato nella Figura 1, mi stavo chiedendo come fosse possibile eliminare questo singolo punto di errore?

Figura 1 Impostazioni posta elettronica in uscita nella pagina Amministrazione centrale SharePoint (fare clic sull'immagine per ingrandirla)

R Questa è un'ottima domanda dato che molte organizzazioni sono attente alla elevata disponibilità e quindi non sono disposte ad accettare nessun punto di errore nei loro ambienti di produzione aziendale. Ciò è particolarmente vero quando si tratta di servizi di messaggistica e collaborazione.

I server HT Exchange 2007 sono adattabili per impostazione predefinita. Cioè, se in un sito Active Directory® è distribuito più di un server HT e uno di questi server in quel sito non è disponibile, il server HT di origine che tenta di distribuire il messaggio passerà al prossimo server HT disponibile nel sito Active Directory. Questo avviene usando il meccanismo DNS round robin (se il primo server HT nell'elenco non risponde, si prova con il successivo).

Pertanto, quando si tratta di comunicazioni tra tutti i server HT e tra il server Cassetta postale e il server HT (cioè all'interno dell'organizzazione), non dobbiamo preoccuparci della elevata disponibilità (o del bilanciamento del carico in quel caso), dato che si tratta di una funzionalità nativa di Exchange 2007. Tenere presente, comunque, che se si installa il ruolo del server HT in un computer in cui è installato anche il ruolo del server Cassetta postale, quest'ultimo preferirà sempre il server HT locale a tutti gli altri server in un sito Active Directory (anche quando il server HT installato in locale non è disponibile) quando il servizio Invio posta di Microsoft Exchange invia i messaggi.

L'informazione precedente non è veramente utile a proposito dei server SharePoint ma è importante conoscerla prima di proseguire. Poiché un server HT è adattabile per impostazione predefinita, non è possibile bilanciare il carico delle comunicazioni all'interno dell'organizzazione tra i server HT in Exchange 2007 usando altri servizi di bilanciamento del carico hardware o la funzionalità WNLB (Windows® Network Load Balancing).

Infatti non c'era alcun supporto al bilanciamento del carico del traffico SMTP in entrata per i server HT basati sulla versione Exchange 2007 RTM. Ma con Exchange 2007 SP1 le cose sono cambiate. Con il Service Pack 1, non è ancora possibile bilanciare il carico delle comunicazioni all'interno dell'organizzazione usando servizi di bilanciamento del carico hardware o la funzionalità WNLB (e comunque perché farlo?) ma è possibile bilanciare il traffico SMTP in entrata proveniente da origini non Exchange (ad esempio i server SharePoint) e client Exchange come IMAP o POP che inviano i messaggi in uscita all'organizzazione Exchange 2007 usando il connettore predefinito di ricezione client nel server HT.

Pertanto, per configurare un server SharePoint in modo da trasmettere i messaggi tramite un'organizzazione Exchange 2007 SP1, è possibile creare semplicemente un record DNS in Active Directory e puntarlo al servizio di bilanciamento del carico hardware che può quindi distribuire il traffico tra i server HT o usare la funzionalità WNLB per questo scopo. Per usare l'ultimo metodo, configurare il cluster WNLB con un indirizzo IP virtuale e un nome FQDN (ad esempio mail.contoso.com) e aggiungere la porta 25 (traffico SMTP in entrata proveniente da server non Exchange) e 587 (traffico SMTP in entrata proveniente da client Exchange come IMAP e POP) nella scheda Regole porta. La Figura 2 mostra l'aspetto della scheda Regole porta con questa configurazione. Inoltre, è importante assicurarsi di assegnare l'esatto indirizzo IP del cluster NLB virtuale a entrambe le regole invece di selezionare tutti gli indirizzi IP.

Figura 2 Regole della porta definite (fare clic sull'immagine per ingrandirla)

Dopo che è stato configurato il cluster NLB, è necessario creare un nuovo connettore di ricezione che dovrebbe essere configurato per l'ascolto sulla porta 25 e consentire solo ai server che lo richiedono di trasmettere i messaggi usando questo connettore. Inoltre, assicurarsi che questo connettore usi l'indirizzo IP del cluster NLB virtuale che era stato creato in precedenza.

D La nostra infrastruttura si basa su Exchange Server 2007. Per rendere ridondanti i nostri server Cassetta postale Exchange 2007, sia a livello hardware che di archiviazione, li abbiamo configurati tutti come server Cassetta postale organizzati in cluster con la tecnologia CCR (Cluster Continuous Replication). Sia il nodo attivo che quello passivo in ogni cluster CCR si trova nello stesso centro dati fisico. Ora che abbiamo eseguito l'aggiornamento dei nostri server Exchange 2007 al Service Pack 1, vogliamo sfruttare la disponibilità dei servizi e dei dati replicando i database delle cassette postali nei server Cassetta postale in un secondo sito, usando la nuova tecnologia SCR (Standby Continuous Replication) inclusa in Exchange 2007 SP1.

Sappiamo che le origini SCR possono essere server Cassetta postale autonomi Exchange 2007 SP1 o server Cassetta postale in cluster, basati sulla tecnologia CCR o SCC (Single Copy Cluster). Ma cosa devono essere i server di destinazione SCR?

R I server di destinazione SCR (conosciuti anche come endpoint SCR) devono essere o un server Cassetta postale indipendente in cui è attivata LCR (Local Continuous Replication) per qualsiasi gruppo di archiviazione o nodi passivi in un cluster di failover Windows (conosciuto in precedenza come Microsoft Cluster Server) in cui è installato il ruolo di server Cassetta postale. Ciò significa che è possibile formare il proprio cluster di failover e quindi installare il ruolo di server Cassetta postale in un nodo passivo in quel cluster di failover ma non è possibile usare un server Cassetta postale come destinazione SCR.

D La nostra organizzazione usa Exchange 2007 come piattaforma di messaggistica. Abbiamo deciso di sostituire la nostra vecchia soluzione antispamming/antivirus nella rete perimetrale con una soluzione basata sui server di Trasporto Edge Exchange 2007 in cui è installato Forefront™ Security for Exchange, in modo da poter usufruire di più livelli di protezione dei messaggi e sicurezza. Pensiamo di distribuire almeno altri due server di Trasporto Edge nel prossimo futuro.

Quindi ecco la mia domanda. Come possiamo affrontare il bilanciamento del carico delle concessioni SMTP in entrata nella nostra soluzione di protezione dei messaggi basata sul Trasporto Edge Exchange 2007 e quindi distribuire il carico e rendere tutto ridondante?

R Se i server di Trasporto Edge nella rete perimetrale sono server SMTP rivolti a Internet, è possibile usare un approccio simile a quello usato nel gruppo Microsoft Information Technology (Microsoft IT). Microsoft IT ha distribuito sei server di Trasporto Edge (tre a Redmond e tre a Silicon Valley) che gestiscono più di 16 milioni di messaggi in entrata al giorno (e più di 13 milioni di messaggi vengono filtrati come spamming).

Microsoft IT ha in totale tre record MX (Mail Exchange) per il dominio Microsoft.com. Essi sono: maila.microsoft.com, mailb.microsoft.com e mailc.microsoft.com (vedere la Figura 3). Ogni record MX è stato configurato con una preferenza di 10, pertanto viene selezionato casualmente usando una tecnica round robin DNS. Inoltre, a ogni record MX sono associati due indirizzi IP (host di posta).

Figura 3 Record MX e host di posta Internet per Microsoft.com (fare clic sull'immagine per ingrandirla)

Perché due indirizzi IP per record MX? Perché alcuni agenti di trasferimento dei messaggi (MTA) selezionano sempre lo stesso record MX, indipendentemente dal numero di record che sono stati configurati per un dominio. Per quanto riguarda Exchange Server, non è stato un problema per molti anni (fino a Exchange 2000) ma purtroppo ci sono ancora MTA che hanno questo flusso di progettazione. Pertanto, indipendentemente da quale MTA tenta di distribuire un messaggio a un indirizzo Microsoft.com, tutte le connessioni SMTP vengono distribuite usando una combinazione di round robin DNS e bilanciamento del carico.

D il nostro dominio Active Directory si basa sui controller di dominio Windows Server® 2003. Attualmente stiamo nella fase di pianificazione della transizione dei nostri controller di dominio Windows Server 2003 a Windows Server 2008 e del nostro ambiente di messaggistica Exchange 2003 a Exchange Server 2007. Possiamo far passare il nostro dominio Active Directory a Windows Server 2008 aggiornando tutti i server in cui è in esecuzione Windows Server 2003 a Windows Server 2008, prima di far passare l'ambiente di messaggistica da Exchange Server 2003 a Exchange 2007?

R Sì, Exchange Server 2003 SP2 è supportato completamente in un dominio Active Directory composto interamente da controller di dominio Windows Server 2008, pertanto è possibile proseguire con il piano in atto. Tenere presente solo che, se si pensa di usare controller di dominio Windows Server 2008 di sola lettura, non è opportuno configurare il servizio RUS (Recipient Update Service) Exchange per l'uso di questi controller di sola lettura.

Henrik Walther è un Certified Architect di Microsoft: Messaging (apprendista) ed Exchange MVP con più di 14 anni di esperienza nel lavoro IT. Lavora come Technology Architect per Interprise Consulting ed è autore di documentazione tecnica per Biblioso Corp.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.