Condividi tramite

Pianificazione della disponibilità elevata e della resilienza del sito

  • Articolo

 

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

Ultima modifica dell'argomento: 2016-11-28

Microsoft Exchange Server 2010 ha una nuova struttura unificata per la resilienza delle cassette postali che include nuove funzionalità, quali il gruppo di disponibilità del database e le copie dei database delle cassette postali. Sebbene la distribuzione di queste nuove funzionalità sia rapida e semplice, occorre comunque un'accurata pianificazione preventiva per fare in modo che qualunque soluzione per l'elevata disponibilità e resilienza del sito che utilizza queste funzionalità risponda alle aspettative e alle esigenze aziendali dei clienti.

Durante la fase di pianificazione, gli architetti e amministratori di sistema nonché le altre figure professionali coinvolte devono determinare i requisiti della distribuzione e in particolare i requisiti per l'elevata disponibilità e resilienza del sito. Per la distribuzione di queste funzionalità, devono essere soddisfatti sia i requisiti generali sia requisiti specifici relativi all'hardware, al software, alla rete. Per istruzioni sui requisiti di archiviazione per i DAG, vedere Progettazione dell'archiviazione del server Cassette postali.

Sommario

Requisiti generali

Requisiti hardware

Requisiti di archiviazione

Requisiti software

Requisiti di rete

Requisiti del server di controllo

Pianificazione della resilienza del sito

Pianificazione degli switchover tra datacenter

Requisiti generali

Prima di distribuire un DAG e creare le copie dei database delle cassette postali, verificare che tutti i requisiti del sistema siano soddisfatti:

  • Domain Name System (DNS) deve essere in esecuzione. Il server DNS dovrebbe accettare gli aggiornamenti dinamici. Se il server DNS non accetta gli aggiornamenti automatici, occorre creare un record dell'host DNS (A) per ciascun server Exchange. In caso contrario, Exchange non funzionerà correttamente.

  • Ciascun server per cassette postali in un DAG deve essere un membro dello stesso dominio.

  • Non è consentito aggiungere un server per cassette postali Exchange 2010 che sia anche un server di directory in un DAG.

  • Il nome assegnato al DAG deve essere un nome di computer valido, disponibile e univoco di massimo 15 caratteri.

Requisiti hardware

In genere, non esistono requisiti hardware specifici per i DAG o le copie dei database delle cassette postali. I server utilizzati devono soddisfare i requisiti definiti negli argomenti Prerequisiti di Exchange 2010 e Requisiti di sistema di Exchange 2010. Per informazioni sulla pianificazione dell'hardware, vedere i seguenti argomenti:

Requisiti di archiviazione

In generale, non esistono requisiti particolari di archiviazione specifici per i gruppi DAG o per le copie del database delle cassette postali. I gruppi DAG non richiedono o non utilizzano l'archiviazione condivisa gestita dal cluster. L'archiviazione condivisa gestita dal cluster è supportata per l'utilizzo in un gruppo DAG solo quando il gruppo è configurato per l'utilizzo di una soluzione che sfrutta il servizio API per la replica di terze parti incorporato in Exchange 2010. Per informazioni sulla pianificazione di archiviazione, vedere Progettazione dell'archiviazione del server Cassette postali.

Requisiti software

I DAG sono disponibili in Exchange 2010 Standard Edition ed Exchange 2010 Enterprise Edition. Inoltre, un DAG può contenere un mix di server con Exchange 2010 Standard Edition ed Exchange 2010 Enterprise Edition in esecuzione.

Su ciascun membro del DAG deve anche essere in esecuzione lo stesso sistema operativo. Exchange 2010 è supportato su entrambi i sistemi operativi Windows Server 2008 e Windows Server 2008 R2. Su tutti i membri di un DAG deve essere in esecuzione Windows Server 2008 o Windows Server 2008 R2. Non è consentito avere una combinazione di Windows Server 2008 e Windows Server 2008 R2.

Oltre ai requisiti per l'installazione di Exchange 2010, è necessario soddisfare anche i requisiti relativi al sistema operativo. I DAG utilizzano la tecnologia clustering di failover di Windows e di conseguenza richiedono la versione Enterprise di Windows.

Requisiti di rete

Esistono specifici requisiti di rete che vanno soddisfatti per ciascun DAG e per ciascun membro di un DAG. Le reti DAG sono simili alle reti pubbliche, private e miste utilizzate nelle precedenti versioni di Exchange. Tuttavia, diversamente dalle precedenti versioni, l'utilizzo di una singola rete in ciascun membro di un DAG ora è una configurazione supportata. Inoltre, la terminologia è stata in certa misura modificata. Al posto delle reti pubblica, privata o mista, ciascun DAG dispone di una singola rete MAPI, che viene utilizzata da altri server (ad esempio, altri server Exchange 2010, server di directory e simili) per comunicare con il membro di un DAG e zero o più reti di replica, che sono reti dedicate al log shipping e al seeding.

Sebbene sia supportata una sola rete, si consiglia di fare in modo che ciascun DAG abbia almeno due reti: una singola rete MAPI e una singola rete di replica. Ciò garantisce la necessaria ridondanza alla rete e al percorso di rete e consente al sistema di distinguere tra un errore del server e un errore della rete. L'utilizzo di una singola scheda di rete impedisce al sistema di distinguere tra i due tipi di errore.

Nota

La documentazione del prodotto in quest'area di contenuti è basata sul presupposto che ciascun membro del DAG contenga almeno due schede di rete, che ciascun DAG sia configurato con una rete MAPI e almeno una rete di replica e che il sistema sia in grado di distinguere tra un errore della rete e un errore del server.

Quando si progetta l'infrastruttura di rete per il DAG, considerare quanto segue:

  • Ciascun membro del DAG deve avere almeno una scheda di rete in grado di comunicare con tutti gli altri membri del DAG. Se si utilizza un singolo percorso di rete, si consiglia di utilizzare una connessione Gigabit Ethernet. Quando si utilizza una singola scheda di rete in ciascun membro del DAG, è necessario che la rete del DAG sia abilitata per la replica e configurata come rete MAPI. Poiché non ci sono altre reti, il sistema utilizzerà la rete MAPI anche come rete di replica. Inoltre, quando si utilizza una singola scheda di rete in ciascun membro del DAG, si consiglia di progettare la soluzione globale considerando una singola scheda e un singolo percorso di rete.

  • L'utilizzo di due schede di rete in ciascun membro del DAG consente di avere una rete MAPI e una rete di replica nonché le seguenti procedure di recupero:

    • Nel caso di un errore della rete MAPI, si verifica il failover di un server (presupponendo che esistano delle copie integre dei database delle cassette postali che possono essere attivate).

    • In caso di errore della rete di replica, se la rete MAPI non è interessata dal problema per le operazioni di log shipping e seeding verrà utilizzata la rete MAPI, anche se la relativa proprietà ReplicationEnabled è impostata su False. Quando la rete di replica è nuovamente in funzione e pronta per riprendere le operazioni di log shipping e seeding, è necessario passare manualmente alla rete di replica. Per passare da una rete MAPI a una rete di replica ripristinata, è necessario sospendere e riprendere la replica continua tramite i cmdlet Suspend-MailboxDatabaseCopy e Resume-MailboxDatabaseCopy o riavviare il servizio di replica di Microsoft Exchange. È consigliabile eseguire le operazioni di sospensione e ripresa per evitare la breve interruzione del servizio determinata dal riavvio del servizio di replica di Microsoft Exchange.

  • Ciascun membro del DAG deve avere lo stesso numero di reti. Ad esempio, se si pianifica l'utilizzo di una singola scheda di per un membro del DAG, anche tutti gli altri membri del DAG dovranno utilizzare una singola scheda di rete.

  • Ciascun DAG deve avere una sola rete MAPI. La rete MAPI deve fornire la connessione ad altri server Exchange e ad altri servizi, come Active Directory e DNS.

  • È possibile aggiungere ulteriori reti di replica, secondo necessità. È possibile evitare che una singola scheda di rete costituisca un singolo punto di errore utilizzando la tecnologia del teaming della scheda di rete o altra tecnologia simile. Tuttavia, anche utilizzando la tecnologia del teaming, non si può impedire che la rete stessa costituisca un singolo punto di errore.

  • Ciascuna rete in ciascun server di un membro del DAG deve trovarsi sulla propria subnet. Ciascun server del DAG può trovarsi su una subnet differente, ma le reti MAPI e di replica devono essere instradabile e garantire la connessione, in modo tale che:

    • Ciascuna rete di ciascun server di un membro del DAG si trovi su una propria subnet che è diversa da quella utilizzata da ogni altra rete del server.

    • Ciascuna rete MAPI del server di un membro del DAG possa comunicare con la rete MAPI di ogni altro membro del DAG.

    • Ciascuna rete di replica del server di un membro del DAG possa comunicare con la rete di replica di ogni altro membro del DAG.

    • Non esiste un routing diretto che consenta il traffico heartbeat dalla rete di replica sul server di un membro del DAG alla rete MAPI sul server di un altro membro del DAG o viceversa oppure tra più reti di replica nell'ambito del DAG.

  • Indipendentemente dalla posizione geografica rispetto agli altri membri del DAG, ciascun membro del DAG deve avere una latenza di rete (tempo di andata e ritorno) inter-membro non superiore a 500 millisecondi (ms). Se aumenta la latenza di andata e ritorno tra due server Cassette postali che ospitano copie di database, aumenta anche il potenziale rischio che le repliche non siano aggiornate. Indipendentemente dalla latenza della soluzione, i clienti dovrebbero convalidare che la rete fra ciascun membro del DAG è in grado di soddisfare gli obiettivi di sicurezza e disponibilità della distribuzione. Configurazioni con alti valori di latenza, per raggiungere i requisiti desiderati, potrebbero richiedere una regolazione particolare di DAG, dei parametri di rete e replicazione, ad esempio aumentare il numero dei database o ridurre il numero di cassette postali per database.

  • I requisiti della latenza di andata e ritorno potrebbero non essere i requisiti di larghezza di banda e latenza più rigidi per una configurazione multi-datacenter. Per determinare i requisiti di rete richiesti dall'ambiente è necessario valutare il carico complessivo della rete che include l'accesso dei client, Active Directory, i servizi di trasporto e di replica continua, nonché il traffico dovuto alle applicazioni.

  • Le reti del DAG supportano Internet Protocol versione 4 (IPv4) e IPv6. IPv6 è supportato solo quando si utilizza anche IPv4; un ambiente IPv6 puro non è supportato. L'utilizzo degli indirizzi IPv6 e degli intervalli di indirizzi IP è supportato solo quando sul computer sono abilitati sia IPv6 che IPv4 e la rete supporta entrambe le versioni degli indirizzi IP. Se Exchange 2010 viene distribuito in questa configurazione, tutti i ruoli dei server potranno inviare e ricevere dati da dispositivi, server e client che utilizzano gli indirizzi in formato IPv6.

  • Automatic Private IP Addressing (APIPA) è una funzionalità di Microsoft Windows che assegna automaticamente gli indirizzi IP quando sulla rete non è disponibile alcun server DHCP (Dynamic Host Configuration Protocol). Gli indirizzi APIPA (inclusi gli indirizzi assegnati manualmente dall'intervallo di indirizzi APIPA) non sono supportati per i DAG o per Exchange 2010.

Requisiti degli indirizzi IP e dei nomi dei DAG

Durante il processo di creazione, a ciascun DAG viene assegnato un nome univoco e uno o più indirizzi IP fissi oppure il DAG viene configurato per utilizzare il protocollo DHCP. Indipendentemente dall'utilizzo di indirizzi IP fissi o dinamici, ogni indirizzo IP assegnato al DAG deve essere presente sulla rete MAPI.

Ciascun DAG richiede almeno un indirizzo IP sulla rete MAPI. Un DAG richiede degli indirizzi IP aggiuntivi quando la rete MAPI si estende su più subnet. La figura che segue illustra un DAG in cui tutti i nodi hanno la rete MAPI sulla stessa subnet.

DAG con rete MAPI sulla stessa subnet

In questo esempio, la rete MAPI di ciascun membro del DAG si trova sulla subnet 172.19.18.x. Di conseguenza, il DAG richiede un singolo indirizzo IP su quella subnet.

La figura successiva illustra un DAG avente una rete MAPI che si estende su due subnet: 172.19.18.x e 172.19.19.x.

DAG con rete MAPI che si estende su più subnet

In questo esempio, la rete MAPI di ciascun membro del DAG si trova su una subnet separata. Di conseguenza, il DAG richiede due indirizzi IP, uno per ciascuna subnet sulla rete MAPI.

Ogni volta che la rete MAPI del DAG si estende su una subnet aggiuntiva, occorre configurare un ulteriore indirizzo IP per quella subnet. Ogni indirizzo IP configurato per il DAG viene assegnato e utilizzato dal cluster di failover che è il livello di base del DAG. Il nome del DAG viene utilizzato anche per il cluster di failover del DAG stesso.

In ogni specifico momento, il cluster del DAG utilizza uno solo degli indirizzi IP assegnati. La funzionalità clustering di failover di Windows registra questo indirizzo IP nel DNS quando le risorse Indirizzo IP e Nome di rete del cluster vengono richiamate online. Oltre all'indirizzo IP e al nome di rete, viene creato anche un oggetto nome cluster (o CNO) in Active Directory. Il nome, l'indirizzo IP e il CNO del cluster vengono utilizzati internamente dal sistema per proteggere il DAG e per la comunicazione interna. Amministratori e utenti finali non hanno necessità di interfacciarsi o connettersi al nome del DAG o all'indirizzo IP.

Nota

Sebbene l'indirizzo IP e il nome di rete del DAG siano utilizzati internamente dal sistema, non è assolutamente indispensabile per Exchange 2010 che queste risorse siano disponibili. Anche qualora le risorse Indirizzo IP e Nome di rete del cluster siano offline, la comunicazione interna al DAG continua senza problemi, in quanto vengono utilizzati i nomi dei server dei membri del DAG. Tuttavia, si consiglia di monitorare periodicamente la disponibilità di queste risorse per verificare che non siano rimaste offline per più di trenta giorni. Se il cluster alla base del DAG rimane offline per oltre 30 giorni, l'account CNO del cluster potrebbe essere invalidato dal meccanismo di garbage collection in Active Directory.

Configurazione della scheda di rete per i DAG

Ogni scheda di rete deve essere configurata per l'utilizzo previsto. Una scheda di rete utilizzata per una rete MAPI è configurata in modo diverso da una scheda di rete utilizzata per un rete di replica. Oltre a configurare in modo appropriato la scheda di rete, occorre anche configurare la sequenza di connessione alla rete in Windows, facendo in modo che la rete MAPI si trovi al primo posto nella sequenza di connessione. Per istruzioni dettagliate sulla procedura di modifica della sequenza di connessione alla rete, vedere l'articolo relativo alla modificare dell'ordine dei binding di protocollo.

Configurazione della scheda di rete MAPI

Una scheda di rete da utilizzare per una rete MAPI deve essere configurata come descritto nella tabella che segue.

Funzionalità di rete Impostazione

Client per reti Microsoft

Abilitato

Utilità di pianificazione pacchetti QoS

Abilitazione opzionale

Condivisione file e stampanti per reti Microsoft

Enable

Internet Protocol versione 6 (TCP/IP v6)

Abilitazione opzionale

Internet Protocol versione 4 (TCP/IP v4)

Enabled

Driver I/O mapper di individuazione topologia livelli di collegamento

Enabled

Risponditore individuazione topologia livelli di collegamento

Enabled

Le proprietà del TCP/IP v4 per una scheda di rete MAPI devono essere configurate come segue:

  • L'indirizzo IP della rete MAPI di un membro del gruppo di disponibilità del database può essere assegnato manualmente o configurato per l'utilizzo del protocollo DHCP. Se si utilizza il protocollo DHCP, si consiglia di utilizzare delle prenotazioni permanenti per l'indirizzo IP del server.

  • La rete MAPI utilizza in genere un gateway predefinito, anche se non è obbligatorio averne uno.

  • È necessario configurare almeno un indirizzo di server DNS. Si consiglia di utilizzare più server DNS per garantire la ridondanza.

  • È necessario selezionare la casella di controllo Registra nel DSN gli indirizzi di questa connessione.

Configurazione della scheda di rete di replica

Una scheda di rete da utilizzare per una rete di replica deve essere configurata come descritto nella tabella che segue.

Funzionalità di rete Impostazione

Client per reti Microsoft

Disabilitato

Utilità di pianificazione pacchetti QoS

Abilitazione opzionale

Condivisione file e stampanti per reti Microsoft

Disabilitato

Internet Protocol versione 6 (TCP/IP v6)

Abilitazione opzionale

Internet Protocol versione 4 (TCP/IP v4)

Enabled

Driver I/O mapper di individuazione topologia livelli di collegamento

Enabled

Risponditore individuazione topologia livelli di collegamento

Enabled

Le proprietà del TCP/IP v4 per una scheda di rete di replica devono essere configurate come segue:

  • L'indirizzo IP della rete di replica di un membro del gruppo di disponibilità del database può essere assegnato manualmente o configurato per l'utilizzo del protocollo DHCP. Se si utilizza il protocollo DHCP, si consiglia di utilizzare delle prenotazioni permanenti per l'indirizzo IP del server.

  • Le reti di replica in genere non utilizzano gateway e, se la rete MAPI ha un gateway predefinito, nessun'altra rete deve avere gateway predefiniti. Il routing del traffico di rete su una rete di replica può essere configurato tramite route statiche permanenti che portano alla rete corrispondente su altri membri del DAG che utilizzano indirizzi gateway in grado di effettuare il routing tra le rete di replica. Tutto il traffico esterno a questa route verrà gestito dal gateway predefinito configurato sulla scheda della rete MAPI.

  • Gli indirizzi del server DNS non devono essere configurati.

  • La casella di controllo Registra nel DSN gli indirizzi di questa connessione non va selezionata.

Requisiti generali

Requisiti del server di controllo

Un server di controllo è un server che si trova all'esterno di un DAG e che viene utilizzato per ottenere e mantenere il quorum quando il DAG ha un numero pari di membri. I DAG con un numero dispari di membri non utilizzano un server di controllo. Tutti i DAG con un numero pari di membri utilizzano un server di controllo. Il server di controllo può essere qualsiasi computer con Windows Server. Non è necessario che la versione del sistema operativo Windows Server del server di controllo sia uguale a quella utilizzata dai membri del DAG.

Il quorum viene mantenuto a livello di cluster, che è il livello di base del DAG. Un DAG ha il quorum quando la maggioranza dei suoi membri è online e può comunicare con gli altri membri online del DAG. Questa nozione di quorum è uno degli aspetti del concetto di quorum così come è inteso nel clustering di failover di Windows. Un aspetto correlato e necessario del quorum nei cluster di failover è la risorsa quorum. La risorsa quorum è una risorsa interna del cluster di failover che fornisce la funzionalità di arbitrato necessaria per le decisioni inerenti lo stato del cluster e il riconoscimento dell'appartenenza al cluster. La risorsa quorum fornisce inoltre un archivio permanente dove è possibile memorizzare le informazioni di configurazione. Alla risorsa quorum è abbinato il registro quorum, un database di configurazione per il cluster. che contiene informazioni quali l'elenco dei server che appartengono al cluster, l'elenco delle risorse installate nel cluster e lo stato di tali risorse (ad esempio, se sono online o meno).

È fondamentale che ogni membro del DAG abbia un'idea chiara di come è configurato il cluster alla base del DAG. Il quorum viene utilizzato come l'archivio in cui sono memorizzate tutte le informazioni di configurazione relative al cluster. Per evitare la sindrome "split brain", il quorum viene utilizzato anche per risolvere eventuali conflitti. La sindrome "split brain" si verifica quando i membri del DAG non riescono a comunicare tra loro pur essendo attivi e in esecuzione. È possibile evitare questa sindrome e mantenere il DAG operativo, facendo in modo che la maggioranza dei membri del DAG (e, nel caso dei DAG con un numero dispari di membri, il server di controllo) sia sempre disponibile e in grado di interagire.

Pianificazione della resilienza del sito

Ogni giorno, un numero sempre crescente di aziende si rende conto di quanto l'accesso a un sistema di messaggistica affidabile e disponibile sia fondamentale per il loro successo. Per molte organizzazioni, il sistema di messaggistica è parte integrante dei loro piani di continuità aziendale e la loro distribuzione del servizio di messaggistica viene progettata in un'ottica di resilienza del sito. Fondamentalmente, molte soluzioni con resilienza del sito prevedono la distribuzione dell'hardware in un secondo datacenter.

In ultima analisi, la struttura globale di un DAG, incluso il numero di membri del DAG e il numero di copie dei database delle cassette postali, dipende, per ciascuna organizzazione, dal contratto di servizio di recupero che copre le varie problematiche. In fase di pianificazione, gli architetti e amministratori della soluzione identificano i requisiti della distribuzione e in particolare i requisiti di resilienza del sito. Essi identificano il percorso o i percorsi da utilizzare e gli opportuni obiettivi da definire nel contratto di servizio di recupero. Il contratto di servizio identifica due elementi specifici che devono costituire la base della progettazione di una soluzione in grado di garantire elevata disponibilità e resilienza del sito: l'obiettivo temporale di recupero (RTO, Recovery Time Objective) e l'obiettivo per il punto di recupero (RPO, Recovery Point Object). Entrambi questi valori sono misurati in minuti. L'RTO è il periodo di tempo che intercorre tra un'interruzione e il ripristino del servizio. L'RPO fa riferimento al livello di aggiornamento in cui si troveranno i dati al termine dell'operazione di recupero. Un contratto di servizio può anche prevedere il pieno ripristino dell'operatività del datacenter principale dopo che tutti i suoi problemi sono stati risolti.

Gli architetti e amministratori della soluzione determinano altresì quali gruppi di utenti hanno bisogno della resilienza del sito e se la soluzione multi-sito avrà la configurazione attiva/passiva o attiva/attiva. Nella configurazione attiva/passiva, nessun utente utilizza di norma il datacenter di standby. Nella configurazione attiva/attiva, gli utenti utilizzano entrambi i datacenter e una parte dei database della soluzione ha un percorso attivo preferenziale in un secondo datacenter. Quando il servizio per gli utenti di un datacenter s'interrompe a causa di un problema, quegli stessi utenti vengono attivati nell'altro datacenter.

La creazione di contratti di servizio appropriati spesso richiede una risposta alle seguenti domande:

  • Qual è il livello di servizio richiesto dopo che si verifica un errore del datacenter principale?

  • Gli utenti necessitano dei propri dati o solo di servizi di messaggistica?

  • Con quale velocità sono richiesti i dati?

  • Quanti utenti è necessario supportare?

  • In quale modo gli utenti potranno accedere ai propri dati?

  • Qual è il contratto di servizio per l'attivazione del datacenter di standby?

  • In che modo il servizio viene trasferito di nuovo al datacenter principale?

  • Le risorse sono dedicate alla soluzione con resilienza del sito?

Rispondendo a queste domande è possibile iniziare a dare forma alla propria soluzione di messaggistica con resilienza del sito. Un requisito fondamentale per il recupero da errori del sito prevede la creazione di una soluzione che trasporti i dati di messaggistica necessari a un datacenter di backup che ospita il servizio di backup per la messaggistica.

Pianificazione dello spazio dei nomi

Exchange 2010 modifica il modo di pianificare il proprio spazio dei nomi per la distribuzione di una configurazione con resilienza del sito. Una buona pianificazione dello spazio dei nomi è essenziale perché gli switchover tra datacenter possano avvenire correttamente. Dal punto di vista dello spazio dei nomi, ogni datacenter utilizzato nella configurazione con resilienza del sito viene considerato attivo. Di conseguenza, ciascun datacenter avrà bisogno del proprio spazio dei nomi univoco per i vari servizi di Exchange 2010 del sito, inclusi gli spazi dei nomi per Outlook Web App, Outlook Anywhere, Exchange ActiveSync, Servizi Web Exchange, Accesso client RPC, Post Office Protocol versione 3 (POP3), Internet Message Access Protocol versione 4 (IMAP4) e Simple Mail Transfer Protocol (SMTP). Inoltre, uno dei datacenter ospita lo spazio dei nomi per l'individuazione automatica (Autodiscover). Questa struttura consente anche di eseguire lo switchover di un singolo database dal datacenter principale a un secondo datacenter per convalidare la configurazione del secondo datacenter come parte della procedura di convalida ed esecuzione di uno switchover tra datacenter.

Si consiglia di utilizzare un DNS diviso per i nomi host di Exchange utilizzati dai client. Il termine "DNS diviso" si riferisce a una configurazione di server DNS nella quale i server DNS interni restituiscono un indirizzo IP interno per un nome host e i server DNS esterni (che interfacciano con Internet) restituiscono un indirizzo IP pubblico per quello stesso nome host. Poiché il DNS diviso utilizza gli stessi nomi host internamente ed esternamente, questa strategia consente di ridurre al minimo il numero di nomi host necessari.

La figura che segue illustra la pianificazione dello spazio dei nomi per una configurazione con resilienza del sito.

Spazi dei nomi per la distribuzione di DAG con resilienza del sito

Come illustrato sopra, ciascun datacenter utilizza uno spazio dei nomi separato e univoco e ciascuno contiene i server DNS nella configurazione DNS diviso per quegli spazi dei nomi. Il datacenter Redmond, che è considerato il datacenter principale, è configurato con lo spazio dei nomi protocollo.contoso.com. Il datacenter Portland è configurato con lo spazio dei nomi protocollo.standby.contoso.com. Gli spazi dei nomi possono includere le designazioni di standby, come nella figura sopra, possono essere basati sulla località (ad esempio, protocollo.portland.contoso.com) oppure possono essere basati su altre convenzioni di denominazione che meglio rispondono alle specifiche esigenze della propria organizzazione. Il requisito chiave è che, indipendentemente dalla convenzione di denominazione utilizzata, ciascun datacenter abbia il proprio spazio dei nomi univoco.

Configurazione di FailbackURL

Alcuni browser Web, incluso Microsoft Internet Explorer, durante ogni sessione di esplorazione mantengono una cache dei nomi DNS separata dalla cache DNS fornita dal sistema operativo. Durante un failback al datacenter principale dopo uno switchover del datacenter, l'utilizzo di questa cache separata da parte del browser Web potrebbe determinare la creazione di un ciclo al momento dell'accesso degli utenti di Outlook Web App, che causa il reindirizzamento di tali utenti allo stesso URL in un ciclo ripetitivo.

Durante un processo di failback, l'indirizzo IP dello spazio dei nomi di Outlook Web App viene modificato in DNS da un endpoint nel centro dati standby e riportato al valore dell'endpoint originario nel centro dati primario. Dopo che il TTL per il record DNS è scaduto e la cache DNS del sistema operativo è stata cancellata, il browser Web che mantiene la propria cache dei nomi separata può continuare a connettersi all'endpoint nel datacenter in standby, anche se lo spazio dei nomi è ospitato nel datacenter principale.

Normalmente, chiudere il browser Web è sufficiente a cancellare la sua cache dei nomi separata quindi prevenire loop di accesso. Tuttavia, al fine di limitare il problema per tutti i browser Web e tutti gli utenti di Outlook Web App, è possibile configurare la proprietà FailbackURL della directory virtuale Outlook Web App. Il parametro FailbackUrl specifica il nome host utilizzato da Outlook Web App per connettersi al server Accesso client dopo il failback al sito principale. Questo spazio dei nomi richiede una voce DNS separata che punta all'indirizzo IP del server Accesso client originario. Il valore del parametro FailbackUrl deve essere diverso dal valore del parametro ExternalUrl per la directory virtuale di Outlook Web App. Quando un utente Outlook Web App fornisce le proprie credenziali, il server Accesso client rileva se l'URL di reinstradamento è lo stesso URL che il client sta visitando. Se l'URL è lo stesso, il server Accesso client controlla se il parametro FailbackUrl è configurato:

  • Se il parametro FailbackUrl è configurato, questo reinstraderà l'utente all'URL dal quale è possibile accedere a Outlook Web App.

  • Se il parametro FailbackUrl non è configurato, l'utente riceverà un messaggio di errore indicante che una modifica della configurazione del server impedisce temporaneamente l'accesso alle proprie cassette postali. Il messaggio indica all'utente di chiudere tutte le finestre del browser (cancellando in questo modo la cache dei nomi del browser) e di riprovare dopo pochi minuti.

Pianificazione dei certificati

Per la distribuzione di un DAG in un singolo datacenter, non ci sono particolari considerazioni inerenti la progettazione dei certificati. Per contro, quando un DAG si estende su più datacenter in una configurazione con resilienza del sito, esistono specifiche considerazioni sui certificati che vanno tenute in debito conto. In genere, la progettazione dei certificati dipende dai client in uso e dai requisiti imposti da altre applicazioni che utilizzano quei certificati. Tuttavia, esistono specifiche raccomandazioni e procedure consigliate da seguire in merito al tipo e numero di certificati da utilizzare.

Il primo obiettivo è quello di utilizzare il numero minimo possibile di certificati per i server Accesso client, i server proxy inverso e i server di trasporto (Edge e Hub). Si consiglia di utilizzare un solo certificato per tutti questi endpoint dei servizi in ciascun datacenter. Questo approccio consente di ridurre la minimo il numero di certificati necessari e ciò di conseguenza riduce il costo e la complessità della soluzione.

Per i client Outlook Anywhere, si consiglia di utilizzare un solo certificato SAN (Subject Alternative Name) per ciascun datacenter e di includere più nomi host in quel certificato. Per garantire la connessione con Outlook Anywhere dopo lo switchover di un database, server o datacenter, occorre utilizzare lo stesso Nome principale del certificato in ciascun certificato e configurare l'oggetto configurazione provider Active Directory di Outlook con lo stesso Nome principale nel formato standard di Microsoft (msstd). Ad esempio, se si utilizza il Nome principale del certificato mail.contoso.com, il relativo attributo va configurato come segue:

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Alcune applicazioni che si integrano con Exchange hanno specifici requisiti per i certificati, che potrebbero richiedere l'utilizzo di certificati aggiuntivi. Exchange 2010 può coesistere con Office Communications Server (OCS). L'OCS richiede certificati a 1024 bit o più che utilizzano il nome server OCS come Nome principale del certificato. Tuttavia, poiché l'utilizzo di un nome server OCS come Nome principale del certificato impedisce il corretto funzionamento di Outlook Anywhere, è necessario utilizzare un certificato aggiuntivo e separato per l'ambiente OCS.

Per ulteriori informazioni sull'utilizzo dei certificati SAN per l'accesso client Exchange 2010, vedere Configurazione dei certificati SSL per l'utilizzo di più nomi host del server Accesso client.

Pianificazione della rete

Oltre agli specifici requisiti di rete che devono essere soddisfatti per ciascun DAG e per ciascun server che è membro di un DAG, ci sono altri requisiti e consigli che sono specifici delle configurazioni con resilienza del sito. Come per tutti i DAG, a prescindere dal fatto che i membri del DAG siano distribuiti in un singolo sito oppure in più siti, la latenza di rete (tempo di andata e ritorno) inter-membro non deve essere superiore a 500 millisecondi (ms). Inoltre, ci sono specifiche impostazioni di configurazione consigliate per i DAG che si estendono su più siti:

  • Le reti MAPI devono essere isolate dalle reti di replica Si devono utilizzare i criteri di connessione di rete di Windows oppure i criteri di protezione tramite firewall o gli elenchi di controllo dell'accesso al router di Windows per bloccare il traffico tra la rete MAPI e la rete o le reti di replica. Questa configurazione è necessaria per prevenire il problema dell'heartbeat cross-talk delle reti.

  • I record DNS lato client devono avere una durata (TTL) di 5 minuti Il tempo di inattività dei client dipende non solo dalla rapidità dello switchover, ma anche dalla rapidità con cui avviene la replica DNS e con cui i client eseguono le query per ottenere le informazioni DNS aggiornate. I record DNS di tutti i servizi dei client Exchange, inclusi Outlook Web App, Exchange ActiveSync, Servizi Web Exchange, Outlook Anywhere, SMTP, POP3, IMAP4 e l'accesso client RPC, sia nei server DNS interni che in quelli esterni, devono essere impostati con una durata (TTL) di 5 minuti.

  • Utilizzare le route statiche per configurare la connessione tra tutte le reti di replica Per garantire la connessione tra tutte le schede di rete di replica, utilizzare le route statiche persistenti. Si tratta di una configurazione rapida e una tantum che va eseguita su ciascun membro del DAG quando si utilizzano gli indirizzi IP statici. Se si utilizza il protocollo DHCP per ottenere gli indirizzi IP delle proprie reti di replica, è possibile utilizzarlo anche per assegnare delle route statiche all replica, semplificando in tal modo la procedura di configurazione.

Pianificazione generale della resilienza del sito

Oltre ai requisiti per l'elevata disponibilità elencati sopra, ci sono altri consigli che riguardano la distribuzione di Exchange 2010 in una configurazione con resilienza del sito (ad esempio, estensione di un DAG su più datacenter). Ciò che si fa durante la fase di panificazione influenza direttamente il successo della soluzione con resilienza del sito. Ad esempio, un'inadeguata progettazione dello spazio dei nomi può causare problemi con i certificati e una configurazione errata dei certificati può impedire l'accesso degli utenti ai servizi.

Per ridurre al minimo il tempo di attivazione di un secondo datacenter e permettergli di ospitare gli endpoint dei servizi di un datacenter fuori uso, è necessario effettuare una pianificazione accurata. Esempio:

  • Gli obiettivi del contratto di servizio per la soluzione con resilienza del sito devono essere ben compresi e documentati.

  • I server del secondo datacenter devono avere sufficiente capacità per ospitare l'intera popolazione di utenti di entrambi i datacenter.

  • Nel secondo datacenter devono essere abilitati tutti i servizi forniti dal datacenter principale (a meno che un servizio non sia escluso dal contratto di servizio per la resilienza del sito). Questo servizi sono: Active Directory, infrastruttura di rete (DNS, TCP/IP e così via), servizi di telefonia (se si utilizza la messaggistica unificata) e infrastruttura del sito (alimentazione, raffreddamento e simili).

  • Affinché gli utenti di un datacenter fuori uso possano avvalersi di questi servizi, è necessario che siano configurati i certificati server appropriati. Alcuni servizi non consentono l'istanziazione (ad esempio, POP3 e IMAP4) e consentono l'utilizzo di un solo certificato. In questi casi, il certificato deve essere un certificato per nomi alternativi del soggetto che quindi include più nomi oppure i nomi devono essere così simili da permettere l'utilizzo di un certificato jolly, a condizione che i criteri di sicurezza dell'organizzazione ne consentano l'utilizzo.

  • I servizi necessari devono essere definiti nel datacenter secondario. Ad esempio, se il primo datacenter ha tre diversi URL SMTP su differenti server di trasporto, è necessario definire la configurazione appropriata nel secondo datacenter per abilitare almeno uno dei server di trasporto (se non tutti e tre) per gestire il carico di lavoro.

  • È necessario approntare la configurazione di rete appropriata per supportare lo switchover tra datacenter. Ciò potrebbe implicare la verifica delle opportune configurazioni di bilanciamento del carico, della configurazione del DNS globale e dell'abilitazione della connessione a Internet con l'appropriata configurazione del routing.

  • La strategia per l'abilitazione delle modifiche apportate al DNS per supportare lo switchover tra datacenter deve essere ben compresa. Le specifiche modifiche al DNS, tra le impostazioni per la durata (TTL), devono essere definite e documentate per supportare il contratto di servizio in vigore.

  • Va altresì definita un'adeguata strategia di test della soluzione e questa strategia va inserita nel contratto di servizio. La convalida periodica della distribuzione è uno dei modi per garantire che la qualità e adeguatezza della distribuzione non si deteriorino nel tempo. Una volta convalidata la distribuzione, si consiglia di documentare nel dettaglio quella parte di configurazione che influenza direttamente il successo della soluzione. Inoltre, si consiglia di lavorare al miglioramento dei processi di gestione delle modifiche che interessano quei specifici segmenti della distribuzione.

Requisiti generali

Pianificazione degli switchover tra datacenter

Completare una pianificazione e preparazione appropriate comporta non solo la distribuzione delle risorse del secondo datacenter, come i server Accesso client e Trasporto Hub, ma anche preconfigurare quelle risorse in modo da ridurre al minimo le modifiche necessarie come parte di un'operazione di switchover tra datacenter.

Nota

I servizi Accesso client e Trasporto Hub sono obbligatori per il secondo datacenter anche quando l'attivazione automatica dei database delle cassette postali del secondo database è bloccata. Questi servizi sono necessari per eseguire gli switchover tra database nonché il test e la convalida dei servizi e dati nel secondo datacenter.

Per meglio comprendere come funziona il processo di switchover tra datacenter di Exchange 2010, è bene cercare di capirne il funzionamento di base.

Come illustrato nella figura che segue, una distribuzione con resilienza del sito consiste di un DAG che ha i membri in entrambi i datacenter.

DAG con i membri in due datacenter

Quando un DAG è destinato all'estensione su più datacenter, dovrebbe essere progettato in modo tale che la maggioranza dei membri del DAG si trovi nel datacenter principale oppure, se ciascun datacenter ha lo stesso numero di membri, che il datacenter principale ospiti il server di controllo. Questa progettazione garantisce che il servizio venga fornito nel datacenter principale anche nel caso in cui si verifichi un'interruzione della connessione di rete tra i due datacenter. Tuttavia, ciò significa anche che in caso di errore del datacenter principale, verrà perduto il quorum per tutti i membri del secondo datacenter.

Sono anche possibili errori parziali del datacenter e ciò si verifica con relativa frequenza. Il presupposto è che nel caso in cui il datacenter principale perda una percentuale di funzionalità tale da impedire l'erogazione del servizio, deve essere effettuato lo switchover per attivare il secondo datacenter. Il processo di attivazione comporta che l'amministratore configuri i server superstiti parzialmente operativi in modo che cessino del tutto l'attività. L'attivazione può quindi procedere nel datacenter secondario. Questo consente di evitare che gli stessi servizi possano essere richiesti e forniti simultaneamente dai due datacenter.

A causa della perdita del quorum, i membri del DAG del secondo datacenter non possono essere portati online automaticamente. Quindi, l'attivazione dei server per le cassette postali nel secondo datacenter richiede un ulteriore passo nel quale i server dei membri del DAG vengono forzati per creare il quorum, mentre i server del datacenter fuori uso vengono internamente rimossi (ma solo temporaneamente) dal DAG. Ciò consente di avere una soluzione con funzionalità parziale, ma stabile e in grado di rimanere operativa anche in presenza di un certo numero di errori aggiuntivi.

Nota

Una condizione necessaria affinché la soluzione sia in grado di rimanere operativa in presenza di altri errori è che il DAG abbia almeno quattro membri e i quattro membri siano suddivisi tra due siti Active Directory (ad esempio, almeno due membri per ciascun datacenter).

Questa è la procedura base utilizzata per ristabilire la funzionalità del ruolo Cassette postali nel secondo datacenter. L'attivazione degli altri ruoli nel secondo datacenter non implica azioni esplicite sui server interessati del secondo datacenter. Anzi, i server del secondo datacenter diventano gli endpoint per quei servizi normalmente ospitati dal datacenter principale. Ad esempio, un utente che normalmente utilizza il datacenter principale potrebbe utilizzare l'indirizzo https://mail.contoso.com/owa per connettersi ad Outlook Web App. Dopo l'errore del datacenter, questi endpoint dei servizi vengono trasferiti al secondo datacenter come parte dell'operazione di switchover. Durante l'operazione di switchover, gli endpoint dei servizi del datacenter principale vengono riassegnati a indirizzi IP alternativi che corrispondono agli stessi servizi nel secondo datacenter. Ciò consente di ridurre al minimo il numero di modifiche da apportare alle informazioni di configurazione archiviate in Active Directory durante la procedura di switchover. In generale, esistono due modi per completare questa operazione:

  • Aggiornare i record DNS oppure

  • Riconfigurare DNS e il bilanciamento del carico per abilitare o disabilitare gli indirizzi IP alternativi, spostando in tal modo i servizi tra i datacenter.

È necessario stabilire una strategia per il test della soluzione. La strategia deve essere organizzata in base ai termini del contratto di servizio. La convalida periodica della distribuzione è uno dei modi per garantire che la distribuzione non si deteriori nel tempo.

L'attenta esecuzione di queste fasi di pianificazione influenzerà direttamente il successo di uno switchover tra datacenter. Ad esempio, un'inadeguata progettazione dello spazio dei nomi può causare problemi con i certificati e una configurazione errata dei certificati può impedire l'accesso degli utenti ai servizi.

Una volta convalidata la distribuzione, si consiglia di documentare nel dettaglio tutte quelle parti della configurazione che influenzano direttamente il successo dello switchover tra datacenter. Inoltre, si consiglia di lavorare al miglioramento dei processi di gestione delle modifiche che interessano quei specifici segmenti della distribuzione.

Per ulteriori informazioni sugli switchover tra datacenter, incluse l'attivazione di un datacenter secondario e la riattivazione di un datacenter principale fuori uso, vedere Passaggi centro dati.

Requisiti generali

 ©2010 Microsoft Corporation. Tutti i diritti riservati.