Disponibilità elevata e resilienza del sito in Exchange Server

È possibile proteggere i database delle cassette postali Exchange Server e i dati in essi contenuti configurando i server e i database di Exchange per la disponibilità elevata e la resilienza del sito. Exchange Server riduce al minimo i costi e la complessità della distribuzione di una soluzione di messaggistica a disponibilità elevata e resiliente, offrendo al tempo stesso livelli elevati di disponibilità e supporto dei dati e del servizio per cassette postali di grandi dimensioni.

Exchange Server consente ai clienti di tutte le dimensioni e in tutti i segmenti di distribuire economicamente un servizio di continuità della messaggistica nell'organizzazione basandosi sulle funzionalità di replica nativa e sull'architettura a disponibilità elevata introdotta in Exchange 2010. Per un elenco delle modifiche apportate a partire da Exchange 2010, 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

Un componente interno di Exchange che viene eseguito all'interno del servizio di replica di Microsoft Exchange, responsabile del monitoraggio degli errori e di un'azione correttiva tramite failover all'interno di un gruppo di disponibilità del database.

AutoDatabaseMountDial

Un'impostazione di una proprietà di un server Cassette postali che determina se una copia di database passivo si installerà automaticamente come nuova copia attiva sulla base del numero di file di registro che mancano nella copia in corso di installazione.

Replica continua - modalità di blocco

Nella modalità di blocco, ogni singolo aggiornamento viene scritto nel buffer di registro attivo della copia di database attiva e viene anche inviato a un buffer di registro in ognuna delle copie passive delle cassette postali in modalità di 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

Nella modalità file, i file di registro delle transazioni chiuse vengono spinti dalla copia del database attivo su una o più copie del database passivo.

Gruppo di disponibilità del database

Gruppo di un massimo di 16 server Exchange che ospita un set di database replicati.

Mobilità del database

Possibilità di replicare e montare un database delle cassette postali di Exchange Server in altri server Exchange.

Datacenter

In genere si riferisce a un sito di Active Directory; tuttavia, può anche riferirsi ad un luogo fisico. Nel contesto di questa documentazione, datacenter equivale al sito di Active Directory.

modalità di coordinamento dell'attivazione del centro dati

Una proprietà dell'impostazione del gruppo di disponibilità del database che, quando abilitata, forza il servizio di replica di Microsoft Exchange ad ottenere l'autorizzazione per installare database all'avvio.

Ripristino d'emergenza

Qualsiasi processo utilizzato per eseguire manualmente il ripristino 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 terza parte Exchange

API fornita da Exchange che consente l'utilizzo di una replica sincrona di terze parti per un gruppo di disponibilità del database invece della replica continua.

Disponibilità elevata

Soluzione che fornisce la disponibilità del servizio, la disponibilità dei dati e il ripristino automatico dagli errori che incidono su servizio o dati (ad esempio errore di rete, archiviazione o server).

Distribuzione incrementale

Possibilità di distribuire disponibilità elevata e resilienza del sito dopo l'installazione di Exchange Server.

Copia del database delle cassette postali ritardata

Copia passiva del database delle cassette postali che presenta un intervallo di riesecuzione registrazione superiore a zero.

Copia del database delle cassette postali

Database delle cassette postali (file EDB e registri) attivo o passivo.

Resilienza delle cassette postali

Nome di una soluzione unificata di disponibilità elevata e resilienza del sito in Exchange Server.

Disponibilità gestita

Un gruppo di processi interni costituito da probe, sistemi di monitoraggio e risponditori che incorpora il monitoraggio e l'elevata disponibilità in tutti i ruoli 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

Precedentemente 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

Una funzionalità del server di trasporto che fornisce ridondanza per i messaggi per l'intero periodo di transito.

Resilienza del sito

Una configurazione che estende l'infrastruttura di messaggistica a più siti di Active Directory per fornire una continuità operativa per il sistema di messaggistica nel caso di un errore che incida su uno dei siti.

Gruppi di disponibilità del database

Un dag è il componente di base del framework di disponibilità elevata e resilienza del sito integrato in Exchange Server. Un gruppo di disponibilità del database è un gruppo di un massimo di 16 server Exchange che ospita un set di database e fornisce il ripristino automatico a livello di database da errori che interessano 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 Ruolo Gruppi di disponibilità del database (DAG).

Copie del database delle cassette postali

Le funzionalità di disponibilità elevata e resilienza del sito usate per la prima volta in Exchange 2010 vengono usate in Exchange Server per creare e gestire copie del database. Exchange Server sfrutta anche il concetto di mobilità del database, ovvero i 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 un passaggio o un failover, altri server Exchange vengono a conoscenza del passaggio quasi immediatamente e reindirizzano il traffico client e di messaggistica 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 del gruppo di disponibilità del database. In Exchange Server, la disponibilità gestita fornisce comportamenti per il ripristino dalla perdita dell'accesso al protocollo a un database, tra cui il riciclo dei pool di ruoli di lavoro delle applicazioni, il riavvio di servizi e server e l'avvio dei failover del database.

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

Active Manager

Exchange Server sfrutta Active Manager per gestire l'integrità della copia del database e del database, lo stato, la replica continua e altri aspetti della disponibilità elevata. Per ulteriori informazioni su Active Manager, vedere Active Manager.

Resilienza del sito

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. Ma non è stato ottenuto il failover per la soluzione stessa perché lo spazio dei nomi deve ancora essere modificato manualmente per i ruoli del server non Cassette postali.

In Exchange 2016 ed Exchange 2019 lo spazio dei nomi non deve essere spostato con il dag. 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ù.

In Exchange Server, i client hanno più di un posto dove andare. Quasi tutti i protocolli di accesso client in Exchange Server sono basati su HTTP. Gli esempi includono Outlook, EAS, EWS, Outlook sul web ed EAC). Tutti i client HTTP supportati hanno la possibilità di usare più indirizzi IP, fornendo così 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. Questo rende il client molto meglio perché se uno degli indirizzi IP ha esito negativo, il client ha uno o più indirizzi IP alternativi a cui provare a connettersi. 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 l'indirizzo VIP per l'array del servizio Accesso client, il ripristino per i client viene eseguito automaticamente e in circa 21 secondi.

I vantaggi sono i seguenti:

• In Exchange Server, se si perde il servizio di bilanciamento del carico nel sito primario, è sufficiente disattivarlo (o forse disattivare l'indirizzo VIP) e ripristinarlo 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 2016 ed Exchange 2019 non è necessario eseguire questa operazione perché si ottiene il failover rapido (20 secondi) dello spazio dei nomi tra vip (data center).

• 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 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 Server offre anche funzionalità che consentono agli amministratori di gestire gli errori intermittenti. 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 Pianificare la disponibilità elevata e la resilienza del sito e Distribuzione di disponibilità elevata e resilienza del sito.

API di replica di terze parti

Exchange Server include 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 collegamenti ad argomenti che consentono di ottenere informazioni e gestire dag, copie del database delle cassette postali e backup e ripristino per Exchange Server.