Disponibilità elevata e resilienza del sito

Si applica a: Exchange Server 2013

È possibile proteggere i database delle cassette postali di Exchange Server 2013 e i dati che contengono configurando i database e i server Cassette postali per la disponibilità elevata e la resilienza del sito. Exchange 2013 riduce il costo e la complessità della distribuzione di una soluzione di messaggistica a disponibilità elevata e resilienza del sito fornendo al contempo livelli di servizio e disponibilità dei dati e assistenza per cassette postali di grandi dimensioni.

Exchange 2013 consente ai clienti di tutte le dimensioni e in tutti i segmenti di distribuire economicamente un servizio di continuità di messaggistica nell'organizzazione, basandosi sulle capacità di replica nativa e sull'architettura di elevata disponibilità in Exchange 2010. Per un elenco delle modifiche in Exchange 2010 ed Exchange 2007, vedere Modifiche alla disponibilità elevata e resilienza sul sito rispetto le versioni precedenti.

Terminologia chiave

I seguenti termini chiave sono importanti per comprendere l'elevata disponibilità o la resilienza del sito:

• Active Manager: componente interno di Exchange eseguito all'interno del servizio Replica di Microsoft Exchange responsabile del monitoraggio degli errori e dell'azione correttiva tramite failover all'interno di un gruppo di disponibilità del database.

• AutoDatabaseMountDial: impostazione della proprietà di un server Cassette postali che determina se una copia passiva del database verrà montata automaticamente come nuova copia attiva, in base al numero di file di log mancanti dalla copia montata.

• Replica continua - modalità blocco: in modalità blocco, poiché ogni aggiornamento viene scritto nel buffer del log attivo della copia del database attivo, viene fornito anche a un buffer di log in ogni copia passiva della cassetta postale in modalità blocco. Quando il buffer di registro è pieno, ogni copia del database compila, ispeziona e crea il file di log successivo nella sequenza di generazione.

• Replica continua - modalità file: in modalità file, i file di log delle transazioni chiusi vengono sottoposti a push dalla copia attiva del database a una o più copie passive del database.

• Gruppo di disponibilità del database: un gruppo di un massimo di 16 server cassette postali di Exchange 2013 che ospita un set di database replicati.

• Mobilità del database: possibilità di replicare e montare un database delle cassette postali di Exchange 2013 in altri server Cassette postali di Exchange 2013.

• Data center: in genere si riferisce a un sito di Active Directory; tuttavia, può anche fare riferimento a un sito fisico. Nel contesto di questa documentazione, datacenter equivale al sito di Active Directory.

• Modalità di coordinamento attivazione del data center: proprietà dell'impostazione del gruppo di disponibilità del database che, se abilitata, impone al servizio Replica di Microsoft Exchange di acquisire l'autorizzazione per montare i database all'avvio.

• Ripristino di emergenza: qualsiasi processo usato per il ripristino manuale da un errore. Può trattarsi di un errore che incide su un elemento singolo oppure di un errore che riguarda un'intera posizione fisica.

• API di replica di terze parti di Exchange: API fornita da Exchange che consente l'uso di replica sincrona di terze parti per un gruppo di disponibilità del database anziché per la replica continua.

• Disponibilità elevata: soluzione che fornisce disponibilità del servizio, disponibilità dei dati e ripristino automatico da errori che influiscono sul servizio o sui dati, ad esempio un errore di rete, archiviazione o server.

• Distribuzione incrementale: possibilità di distribuire disponibilità elevata e resilienza del sito dopo l'installazione di Exchange 2013.

• Copia del database delle cassette postali ritardata: copia passiva del database delle cassette postali con un ritardo di riesecuzione del log maggiore di zero.

• Copia del database delle cassette postali: database delle cassette postali (file e log con estensione edb), attivo o passivo.

• Resilienza delle cassette postali: nome di una soluzione unificata di disponibilità elevata e resilienza del sito in Exchange 2013.

• Disponibilità gestita: set di processi interni costituiti da probe, monitoraggi e risponditori che incorporano il monitoraggio e la disponibilità elevata in tutti i ruoli del server e in tutti i protocolli.

• *over (pronunciato "star over"): abbreviazione di switchover e failover. Per switchover si intende l'attivazione manuale di una o più copie del database. Per failover si intende l'attivazione automatica di una o più copie del database dopo un errore.

• Rete di sicurezza: in precedenza noto come dumpster di trasporto, questa è una funzionalità del servizio di trasporto che archivia una copia di tutti i messaggi per X giorni. L'impostazione predefinita è 2 giorni.

• Ridondanza shadow: funzionalità del server di trasporto che fornisce ridondanza per i messaggi per l'intero tempo in cui sono in transito.

• Resilienza del sito: configurazione che estende l'infrastruttura di messaggistica a più siti di Active Directory per garantire la continuità operativa per il sistema di messaggistica in caso di errore che interessa uno dei siti.

Gruppi di disponibilità del database

Un gruppo di disponibilità del database è il componente di base del framework a disponibilità elevata e resilienza del sito integrata in Exchange 2013. Un DAG è un gruppo di un massimo di 16 server Cassette postali che ospita un insieme di database e fornisce il ripristino automatico a livello del database da errori che hanno un impatto su singoli database, reti o server. Qualsiasi server in un gruppo di disponibilità del database è in grado di ospitare una copia del database delle cassette postali da qualsiasi altro server nel gruppo di disponibilità del database. Quando un server viene aggiunto al gruppo di disponibilità del database, funziona con altri server nel gruppo di disponibilità del database per fornire il ripristino automatico da errori che hanno un impatto sui database delle cassette postali, ad esempio un errore nel server o nel disco. Per ulteriori informazioni sui gruppi di disponibilità del database, vedere Database availability groups (DAGs).

Copie del database delle cassette postali

Le funzionalità disponibilità elevata e resilienza del sito utilizzate introdotte inizialmente in Exchange 2010 vengono utilizzate in Exchange 2013 per creare e mantenere copie dei database. Exchange 2013 inoltre sfrutta il concetto di mobilità del database, cioè failover a livello di database gestiti da Exchange.

La mobilità dei database consente di disconnettere i database dai server e di supportare fino a 16 copie di un singolo database. Fornisce, inoltre, un'esperienza locale per la creazione di copie di un database.

L'impostazione di una copia del database come database delle cassette postali attivo è definita switchover. Quando si verifica un errore che incide su un database o sull'accesso ad un database e un nuovo database diventa la copia attiva, il processo è denominato failover. Questo processo si riferisce inoltre a un errore server in cui uno o più server portano in linea i database precedentemente in linea sul server che ha presentato l'errore. Quando si verifica uno switchover o un failover, gli altri server di Exchange 2013 vengono a conoscenza dello switchover pressoché immediatamente e reindirizzano il traffico di messaggistica e client al nuovo database attivo.

Ad esempio, se un database attivo in un gruppo di disponibilità del database presenta un problema a causa di un errore dell'archiviazione sottostante, Active Manager effettua immediatamente il ripristino mediante failover su una copia del database in un altro server Cassette postali del gruppo di disponibilità del database. In Exchange 2013, la disponibilità gestita aggiunge nuovi comportamenti da recuperare dalla perdita di accesso del protocollo a un database, inclusi il riciclaggio dei pool di lavoro delle applicazioni, il riavvio di servizi e server e l'avvio dei failover dei database.

Per ulteriori informazioni sulle copie del database delle cassette postali, vedere Copie del database delle cassette postali.

Active Manager

Exchange 2013 sfrutta il componente di Active Manager introdotto in Exchange 2010 per gestire il database e l'integrità, lo stato, la replica continua della copia del database e altri aspetti dell'elevata disponibilità del server Cassette postali. Per ulteriori informazioni su Active Manager, vedere Active Manager.

Resilienza del sito

Anche se Exchange 2013 continua a utilizzare i gruppi di disponibilità del database e il servizio Clustering di failover di Windows per la disponibilità elevata del ruolo del server Cassette postali e la resilienza del sito, quest'ultima non è la stessa in Exchange 2013. La resilienza del sito è molto migliorata in Exchange 2013 perché è stata semplificata. Le modifiche architetturali sottostanti che erano state effettuate in Exchange 2013 hanno un impatto notevole sugli aspetti del ripristino di una configurazione della resilienza del sito.

In Exchange 2010, il ripristino della cassetta postale (gruppo di disponibilità del database) e dell'accesso client (array del server Accesso client) erano legati tra loro. Se andavano perduti tutti i server Accesso client, il VIP per l'array o una parte significativa del gruppo di disponibilità del database, ci si trovava nella situazione in cui era necessario effettuare un switchover del datacenter. Si tratta di un processo ben documentato e generalmente ben compreso, anche se occorre del tempo per eseguirlo ed è necessario l'intervento umano per avviarlo.

In Exchange 2013, se per qualche motivo va perduta l'array del server Accesso client (ad esempio, si verifica un errore del dispositivo di bilanciamento del carico), non è necessario eseguire un switchover del datacenter. Con la corretta configurazione, il failover si verifica a livello del client e i client vengono automaticamente reindirizzati a un secondo datacenter che dispone di server Accesso client operativi e questi server comunicano tramite proxy con il server Cassette postali dell'utente, che non subisce gli effetti dell'interruzione (poiché non si effettua uno switchover). Poiché il servizio viene ripristinato automaticamente, invece di effettuare le operazioni di recupero del servizio, l'utente può dedicarsi alla risoluzione del problema (ad esempio, la sostituzione del dispositivo di bilanciamento del carico).

Inoltre, con la semplificazione dello spazio dei nomi, il consolidamento dei ruoli del server, il disaccoppiamento dei requisiti dei ruoli server del sito di Active Directory, la separazione del ripristino dell'array del server Accesso client e del gruppo di disponibilità del database e le modifiche apportate al bilanciamento del carico, in Exchange 2013 sono presenti delle modifiche che ora consentono il ripristino automatico e separato del server Accesso client e del gruppo di disponibilità del database nei siti, fornendo in tal modo scenari di failover del datacenter, se si dispone di tre postazioni.

In Exchange 2010, era possibile distribuire un gruppo di disponibilità del database su due datacenter e ospitare il testimone su un terzo datacenter e abilitare il failover per il ruolo del server Cassette postali per uno dei datacenter. Tuttavia, il failover non si risolveva da solo, in quanto bisognava ancora modificare manualmente lo spazio dei nomi per i ruoli del server non di cassette postali.

In Exchange 2013, lo spazio dei nomi non ha bisogno di spostarsi con il gruppo di disponibilità del database. Exchange sfrutta la tolleranza di errore incorporata nello spazio dei nomi attraverso più indirizzi IP e il bilanciamento del carico (e, se necessario, la possibilità di attivare e disattivare i server). I client HTTP moderni lavorano automaticamente con questa ridondanza. Lo stack HTTP può accettare più indirizzi IP per un nome di dominio completo (FQDN) e, se si verifica un errore con il primo indirizzo IP (ovvero, non riesce a connettersi), passerà al successivo indirizzo IP dell'elenco. In caso di errore non grave (la connessione è andata perduta una volta stabilita la sessione, forse a causa di un errore saltuario nel servizio in cui, ad esempio, un dispositivo sta interrompendo i pacchetti e deve essere disattivato), l'utente potrebbe aver bisogno di riaggiornare il browser.

Ciò significa che lo spazio dei nomi non è più un singolo punto di errore come lo era in Exchange 2010. In Exchange 2010, forse il più grosso singolo punto di errore nel sistema di messaggistica è il nome di dominio completo che è stato dato agli utenti, poiché dice all'utente dove andare. Nel paradigma Exchange 2010, modificare il punto in cui va il nome di dominio completo non è facile, poiché è necessario modificare il DNS, quindi occuparsi della latenza del DNS, che in alcune parti del mondo è piuttosto scarsa. Inoltre, bisogna occuparsi anche delle cache dei nomi nei browser che normalmente hanno una durata di circa 30 minuti o più.

Una delle modifiche apportate in Exchange 2013 è l'abilitazione dei client a usufruire di più destinazioni. Presupponendo che il client abbia la possibilità di usufruire di più destinazioni (quasi tutti i protocolli di accesso client in Exchange 2013 si basano su HTTP (alcuni esempi includono Outlook, Outlook via Internet, EAS, EWS, OWA e l'interfaccia di amministrazione di Exchange) e tutti i client HTTP supportati hanno la possibilità di utilizzare più indirizzi IP fornendo, in tal modo, il failover sul lato client. È possibile configurare il DNS per gestire più indirizzi IP per un client durante la risoluzione dei nomi. Ad esempio, il client richiede mail.contoso.com e ottiene due indirizzi IP o quattro indirizzi IP. Tuttavia, il client utilizzerà in maniera affidabile molti degli indirizzi IP che ottiene. Ciò migliora notevolmente la condizione del client, poiché se si verifica un errore su uno degli indirizzi IP, il client può disporre di uno o più indirizzi aggiuntivi per tentare la connessione. Se un client ne prova uno e si verifica un errore, attende circa 20 secondi e, quindi, prova l'indirizzo successivo nell'elenco. Pertanto, se si perde il VIP per l'array del server Accesso client, il ripristino per i client avviene automaticamente e in circa 21 secondi.

I vantaggi sono i seguenti:

• In Exchange 2010, se si perdeva il dispositivo di bilanciamento del carico nel datacenter principale e non si disponeva di un atro dispositivo su quel sito, bisognava eseguire uno switchover del datacenter. In Exchange 2013, se si perde il dispositivo di bilanciamento del carico nel sito principale, è sufficiente disattivarlo (o magari disattivare il VIP) e ripararlo o sostituirlo. I client che ancora non utilizzano il VIP nel datacenter secondario eseguiranno automaticamente un failover sul VIP secondario senza che vengano apportate modifiche allo spazio dei nomi e al DNS. Ciò non solo significa che non è più necessario eseguire uno switchover, ma anche che tutto il tempo generalmente associato al ripristino dello switchover di un datacenter viene risparmiato. In Exchange 2010, bisognava gestire la latenza DNS (di qui, la raccomandazione di impostare la durata TTL su 5 minuti e l'introduzione dell'URL di failback). In Exchange 2013, non è necessario effettuare tali operazioni, in quanto si dispone di un failover rapido (20 secondi) dello spazio dei nomi tra i VIP (datacenter).

• Poiché è possibile eseguire il failover dello spazio dei nomi tra i datacenter, per ottenere il failover di un datacenter è sufficiente disporre di un meccanismo per failover del ruolo del server Cassette postali nei datacenter. Per ottenere un failover automatico per il gruppo di disponibilità del database, è sufficiente architettare una soluzione in cui il gruppo di disponibilità del database è equamente suddiviso tra i due datacenter e, quindi, posizionare il server di controllo in una terza posizione affinché possa essere gestito dai membri del gruppo di disponibilità del database in uno dei datacenter, indipendentemente dallo stato della rete tra i datacenter che contengono i membri del gruppo di disponibilità del database. Se sono presenti solo due datacenter e non è disponibile una terza posizione fisica, è possibile inserire il server di controllo in una macchina virtuale di Microsoft Azure. Per ulteriori informazioni, vedere Utilizzo di una macchina virtuale Azure Microsoft come server di controllo del DAG.

• In questo scenario, gli sforzi dell'amministratore vengono velocizzati grazie a una soluzione semplice del problema e non spesi nel servizio di ripristino. È sufficiente risolvere il problema verificatosi, mentre il servizio rimane in esecuzione e l'integrità dei dati viene mantenuta. Il livello di urgenza e stress che si avverte durante la riparazione di un dispositivo rotto è nulla rispetto all'urgenza e allo stress che si avvertono durante il ripristino del servizio. È meglio per l'utente finale e meno stressante per l'amministratore.

È possibile consentire il failover senza dover eseguire dei switchback (alcune volte denominati per errore failback). Se si perdono i server Accesso client nel datacenter principale e si verifica un'interruzione di 20 secondi per i client, potrebbe anche non essere necessario occuparsi del failback. A questo punto, la preoccupazione primaria sarebbe di risolvere il problema principale (ad esempio, la sostituzione del dispositivo di bilanciamento del carico). Una volta che è di nuovo online e funzionante, alcuni client inizieranno ad utilizzarlo, mentre altri potrebbero rimanere operativi tramite l'uso del secondo datacenter.

Exchange 2013 fornisce anche la funzionalità che consente agli amministratori di occuparsi degli errori saltuari. Un errore saltuario si verifica quando, ad esempio, è possibile effettuare la connessione TCP iniziale, ma poi non accade più nulla. Per un errore saltuario è necessaria un' ulteriore azione amministrativa poiché potrebbe essere la conseguenza di un dispositivo di sostituzione messo in funzione. Mentre è in corso il processo di riparazione, il dispositivo potrebbe attivarsi e accettare alcune richieste, ma non essere realmente pronto a fornire servizi ai client fino a quando non viene eseguita la necessaria procedura di configurazione. In questo scenario, l'amministratore può eseguire un switchover dello spazio dei nomi semplicemente rimuovendo il VIP per il dispositivo in corso di sostituzione dal DNS. In tal modo, durante il periodo di manutenzione, nessun client cercherà di connettersi. Una volta completata la sostituzione, l'amministratore può aggiungere nuovamente il VIP al DNS e i client potranno iniziare ad utilizzarlo.

Per informazioni dettagliate sulla pianificazione e la distribuzione della resilienza del sito, vedere Pianificazione della disponibilità elevata e della resilienza del sito e Distribuzione di disponibilità elevata e resilienza del sito.

API di replica di terze parti

Exchange 2013 include anche un'API di replica di terze parti che consente alle organizzazioni di usare soluzioni di replica sincrona di terze parti anziché la funzionalità di replica continua predefinita. Microsoft supporta soluzioni di terze parti che usano questa API, a condizione che la soluzione fornisca le funzionalità necessarie per sostituire tutte le funzionalità di replica continua native disabilitate in seguito all'uso dell'API. Le soluzioni sono supportate solo quando l'API viene usata all'interno di un gruppo di disponibilità del database per gestire e attivare le copie del database delle cassette postali. L'uso dell'API al di fuori di questi limiti non è supportato. Inoltre, la soluzione deve soddisfare i requisiti di supporto hardware di Windows applicabili. La convalida dei test non è necessaria per il supporto.

Quando si distribuisce una soluzione che utilizza l'API di replica di terze parti integrata, è necessario tenere presente che il fornitore della soluzione è responsabile del supporto principale della soluzione. Microsoft supporta i dati di Exchange sia per le soluzioni replicate che per quelle non replicate. Le soluzioni che usano la replica dei dati devono rispettare i criteri di supporto Microsoft per la replica dei dati. Inoltre, le soluzioni che utilizzano il modello di risorse cluster di failover Windows devono soddisfare i requisiti per il supporto dei cluster di Windows, come descritto nell'articolo 943984 della Microsoft Knowledge Base relativo ai criteri del Servizio Supporto Tecnico Microsoft per Windows Server 2008 o i cluster di failover di Windows Server 2008 oppure ai criteri del Servizio Supporto Tecnico Microsoft per il cluster di failover di Windows Server 2012.

I criteri di supporto per il backup e il ripristino di Microsoft per le distribuzioni che utilizzano soluzioni basate su API per le repliche di terze parti sono analoghi ai criteri delle distribuzioni delle repliche continue native.

Se si è un partner alla ricerca di informazioni su API di terze parti, contattare il rappresentante Microsoft.

Documentazione sulla resilienza del sito e l'elevata disponibilità

La tabella seguente contiene i collegamenti agli argomenti che guideranno l'utente attraverso l'apprendimento della gestione dei DAG, delle copie del database delle cassette postali e del backup e ripristino per Exchange 2013.