Informazioni sui gruppi di disponibilità del database

 

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

Ultima modifica dell'argomento: 2015-03-09

Un gruppo di disponibilità del database (DAG, Database Availability Group) è il componente di base del framework a disponibilità elevata e resilienza del sito integrata in Microsoft Exchange Server 2010. Un gruppo di disponibilità del database è un gruppo costituito da 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 server o database.

Un gruppo di disponibilità del database è un confine per la replica del database delle cassette postali, gli switchover di database e server, i failover e un componente interno di Exchange 2010 denominato Active Manager. Active Manager, che viene eseguito su ogni server in un gruppo di disponibilità del database (DAG), gestisce switchover e failover. Per ulteriori informazioni su Active Manager, vedere Informazioni su Active Manager.

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.

Sommario

Ciclo di vita del gruppo di disponibilità del database

Utilizzo di un gruppo di disponibilità del database per la disponibilità elevata

Utilizzo di un gruppo di disponibilità del database per la resilienza del sito

Prestazioni del client quando si utilizzano i gruppi di disponibilità del database

Ciclo di vita del gruppo di disponibilità del database

I gruppi di disponibilità del database sfruttano una funzionalità di Exchange 2010 denominata distribuzione incrementale che consiste nell'abilità di distribuire disponibilità di servizi e dati per tutti i server Cassette postali e i database dopo l'installazione di Exchange. Dopo aver distribuito Exchange 2010, è possibile creare un gruppo di disponibilità del database, aggiungere server Cassette postali al gruppo di disponibilità del database, quindi replicare i database delle cassette postali tra i membri del gruppo di disponibilità del database.

Un gruppo di disponibilità del database viene creato utilizzando il cmdlet New-DatabaseAvailabilityGroup. Un gruppo di disponibilità del database viene inizialmente creato come oggetto vuoto in Active Directory. Questo oggetto directory viene utilizzato per archiviare informazioni relative al gruppo di disponibilità del database, come, ad esempio, le informazioni di appartenenza del server. Quando si aggiunge il primo server a un DAG, per quel DAG viene creato automaticamente un cluster di failover. Il cluster di failover viene utilizzato esclusivamente dal gruppo di disponibilità del database e il cluster deve essere dedicato al DAG. L'utilizzo del cluster per altri scopi non è supportato.

Oltre alla creazione del cluster di failover, viene anche attivata l'infrastruttura che controlla i server per rilevare eventuali problemi della rete o dei server stessi. Il meccanismo heartbeat di cluster di failover e il database cluster sono poi utilizzati per tracciare e gestire le informazioni sul gruppo di disponibilità del database che possono cambiare rapidamente, come lo stato di installazione del database, lo stato di replica e l'ultimo percorso d'installazione.

Durante il processo di creazione, al gruppo di disponibilità del database viene assegnato un nome univoco e uno o più indirizzi IP statici, oppure il gruppo viene configurato per l'uso del protocollo DHCP (Dynamic Host Configuration Protocol). È possibile specificare un unico indirizzo IP oppure un elenco separato da virgole di indirizzi IP utilizzando il parametro DatabaseAvailabilityGroupIPAddresses.

In questo esempio viene mostrato un DAG che disporrà di tre server. Due server (EX1 e EX2) si trovano nella stessa subnet (10.0.0.0) e il terzo server (EX3) si trova in una subnet diversa (192.168.0.0).

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

Il cluster per DAG1 viene creato quando EX1 viene aggiunto al gruppo di disponibilità del database. Durante la creazione del cluster, il cmdlet Add-DatabaseAvailabilityGroupServer recupera gli indirizzi IP configurati per il gruppo di disponibilità del database e ignora quelli che non corrispondono ad alcuna delle subnet individuate in EX1. In questo esempio, il cluster per DAG1 viene creato con l'indirizzo IP 10.0.0.5 e 192.168.0.5 viene ignorato.

Viene quindi aggiunto EX2 e il cmdlet Add-DatabaseAvailabilityGroupServer recupera nuovamente gli indirizzi IP configurati per il gruppo di disponibilità del database. Non viene apportata alcuna modifica agli indirizzi IP del cluster poiché EX2 si trova nella stessa subnet di EX1.

Viene quindi aggiunto EX3 e il cmdlet Add-DatabaseAvailabilityGroupServer recupera nuovamente gli indirizzi IP configurati per il gruppo di disponibilità del database. Poiché è presente una subnet corrispondente a 192.168.0.5 in EX3, l'indirizzo 192.168.0.5 viene aggiunto come risorsa indirizzo IP nel gruppo cluster. Inoltre, viene automaticamente configurata una dipendenza OR per la risorsa nome rete per ogni risorsa indirizzo IP. L'indirizzo 192.168.0.5 verrà utilizzato dal cluster quando il gruppo cluster si sposta in EX3.

La funzionalità clustering di failover di Windows registra gli indirizzi IP per il cluster in Domain Name System (DNS) quando la risorsa nome rete viene portata online. Inoltre, viene creato un oggetto nome cluster (CNO, cluster network object) in Active Directory. Il nome, l'indirizzo IP e l'oggetto di rete cluster per il cluster vengono utilizzati solo internamente dal sistema per proteggere il gruppo di disponibilità del database e per la comunicazione interna. Amministratori e utenti finali non hanno necessità di interfacciarsi o connettersi al nome del gruppo di disponibilità del database o all'indirizzo IP per alcun motivo.

Oltre a un nome e uno o più indirizzi IP, il gruppo di disponibilità del database è configurato per utilizzare un server di controllo e una directory di controllo. Il server e la directory di controllo sono specificati automaticamente dal sistema oppure possono essere specificati manualmente dall'amministratore.

Per impostazione predefinita, il gruppo di disponibilità del database è progettato per utilizzare la funzionalità di replica continua incorporata per replicare i database delle cassette postali tra i server del gruppo di disponibilità del database. Se si utilizza un tipo di replica di dati di terza parte che supporta l'API di replica di terza parte in Exchange 2010, è necessario creare il gruppo di disponibilità del database in modalità di replica di terza parte utilizzando il cmdlet New-DatabaseAvailabilityGroup con il parametro ThirdPartyReplication. Non è possibile disabilitare questa modalità, una volta abilitata.

Una volta creato il gruppo di disponibilità del database, è possibile aggiungere server Cassette postali a tale gruppo di disponibilità del database. Quando si aggiunge il primo server al gruppo di disponibilità del database, viene formato un cluster per l'utilizzo da parte del gruppo di disponibilità del database. I gruppi di disponibilità del database fanno uso limitato della tecnologia clustering di failover di Windows, ad esempio heartbeat cluster, reti cluster e database cluster (per l'archiviazione di dati che cambiano, quali le modifiche di stato del database da attivo a passivo o viceversa, oppure da montato a smontato e viceversa). Con l'aggiunta di ogni server successivo al gruppo di disponibilità del database, il server viene aggiunto anche al cluster sottostante (e il modello di quorum del cluster viene automaticamente regolato dal sistema, in base alle necessità) e il server viene aggiunto all'oggetto gruppo di disponibilità del database in Active Directory.

Dopo l'aggiunta dei server Cassette postali a un gruppo di disponibilità del database, è possibile configurare una vasta gamma di proprietà del gruppo di disponibilità del database, ad esempio è possibile utilizzare o meno la crittografia di rete o la compressione di rete per la replica del database all'interno del DAG. È anche possibile configurare reti di gruppi di disponibilità del database e crearne altre.

Dopo aver aggiunto i membri a un gruppo di disponibilità del database e configurato tale gruppo, è possibile replicare i database delle cassette postali attivi in ogni server negli altri membri del gruppo di disponibilità del database. Dopo aver creato le copie del database delle cassette postali, è possibile monitorare l'integrità e lo stato delle copie utilizzano una vasta gamma di strumenti di monitoraggio incorporati. Inoltre, è possibile eseguire switchover di server e database.

Per ulteriori informazioni sulla creazione di gruppi di disponibilità del database, sulla gestione della loro appartenenza, sulla configurazione delle loro proprietà, su creazione e monitoraggio di copie del database delle cassette postali e sull'esecuzione di switchover, vedere Gestione della disponibilità elevata e della resilienza del sito.

Modelli di quorum del gruppo di disponibilità del database

Alla base di ogni gruppo di disponibilità del database è presente un cluster di failover Windows. I cluster di failover utilizzano il concetto di quorum, che si basa sul consenso dei votanti per assicurare che, in un determinato momento, sia in funzione un solo sottoinsieme dei membri del cluster (che può includere tutti i membri o la maggioranza dei membri). Il quorum non è un concetto nuovo per Exchange 2010. Anche i server Cassette postali a elevata disponibilità nelle precedenti versioni di Exchange utilizzano il clustering di failover e il concetto di quorum. Il quorum rappresenta una vista condivisa di membri e risorse. Il termine quorum viene anche utilizzato per descrivere i dati fisici che rappresentano la configurazione del cluster condivisa da tutti i suoi membri. Di conseguenza, per tutti i gruppi di disponibilità del database è necessario che il cluster di failover sottostante raggiunga il quorum. Se il cluster perde il quorum, tutte le operazioni del gruppo di disponibilità del database vengono interrotte e tutti i database montati ospitati nel gruppo di disponibilità del database vengono smontati. In questo caso, è necessario l'intervento dell'amministratore per risolvere il problema del quorum e ripristinare le operazioni del gruppo di disponibilità del database.

Il quorum è importante per garantire la coerenza, per risolvere eventuali conflitti derivanti dal partizionamento e per garantire la velocità di risposta dei cluster:

• Garanzia di coerenza   Il requisito principale per un cluster di failover Windows è che ogni membro deve disporre sempre di una vista del cluster coerente con gli altri membri. L'hive del cluster viene utilizzato come l'archivio definitivo in cui sono memorizzate tutte le informazioni di configurazione relative al cluster. Se non è possibile caricare localmente l'hive del cluster in un membro del gruppo di disponibilità del database, il servizio Cluster non viene avviato perché non è in grado di garantire che il membro soddisfa il requisito di disporre di una vista del cluster coerente con gli altri membri.

• Funzione di tie-breaker   Nei gruppi di disponibilità del database viene utilizzata una risorsa di controllo del quorum con un numero pari di membri per evitare scenari di sindrome split brain e per garantire che solo una raccolta di membri nel gruppo di disponibilità del database è considerata ufficiale. Quando il server di controllo è necessario per il quorum, i membri del gruppo di disponibilità del database in grado di comunicare con il server di controllo possono impostare un blocco SMB (Server Message Block) sul file di log del server di controllo. Il membro del gruppo di disponibilità del database che blocca il server di controllo (definito nodo di blocco) mantiene un voto aggiuntivo ai fini del quorum. I membri del gruppo di disponibilità del database in contatto con il nodo di blocco sono in maggioranza e mantengono il quorum. I membri del gruppo di disponibilità del database in contatto con il nodo di blocco sono in minoranza e perdono il quorum.

• Garanzia di capacità di risposta   Per garantire la velocità di risposta, il modello di quorum assicura che, ogniqualvolta il cluster è in esecuzione, un numero sufficiente di membri del sistema distribuito è operativo e in comunicazione ed è possibile garantire almeno una replica dello stato corrente del cluster. Non è richiesto tempo ulteriore per mettere i membri in comunicazione o per determinare se è garantita una replica specifica.

I gruppi di disponibilità del database con un numero pari di membri utilizzano la modalità quorum Maggioranza dei nodi e delle condivisioni file del cluster di failover, che impiega un server di controllo esterno che funge da tie-breaker. In questa modalità di quorum, ogni membro del gruppo di disponibilità del database ottiene un voto. Viene inoltre utilizzato il server di controllo per attribuire un voto pesato a un membro del gruppo di disponibilità del database (ad esempio, ottiene due voti anziché uno). Per impostazione predefinita, i dati relativi al quorum del cluster vengono archiviati nel disco di sistema di ogni membro del gruppo di disponibilità del database e ne viene garantita la coerenza tra tutti i dischi. Non viene tuttavia archiviata alcuna copia dei dati del quorum sul server di controllo. Nel server di controllo è presente un file che tiene traccia del membro con la copia più aggiornata dei dati, ma in tale server non è presente alcuna copia dei dati del quorum del cluster. In questo modo, la maggioranza dei voter (i membri del gruppo di disponibilità del database più il server di controllo) deve essere operativa e in grado di comunicare reciprocamente per mantenere il quorum. Se la maggior parte dei votanti non è in grado di comunicare con gli altri, il cluster sottostante del gruppo di disponibilità del database perde il quorum e sarà necessario un intervento amministrativo per ripristinare il funzionamento del gruppo di disponibilità del database.

I gruppi di disponibilità del database con un numero dispari di membri utilizzano la modalità quorum Maggioranza dei nodi del cluster di failover. In questa modalità, ogni membro ottiene un voto e il disco di sistema locale di ciascun membro viene utilizzato per archiviare i dati del quorum del cluster. Se la configurazione del gruppo di disponibilità del database viene modificata, le modifiche si rifletteranno su tutti i diversi dischi. La modifica viene considerata vincolante e permanente solo se viene apportata ai dischi della metà dei membri (con arrotondamento per difetto) più uno. Ad esempio, in un gruppo di disponibilità del database con cinque membri, la modifica deve essere apportata a due membri più uno o a un totale di tre membri.

Il quorum richiede che la maggioranza dei voter sia in grado di comunicare reciprocamente. Si consideri un gruppo di disponibilità del database con quattro membri. Poiché il gruppo di disponibilità del database include un numero pari di membri, viene utilizzato un server di controllo esterno per fornire a uno dei membri del cluster un quinto voto che consenta di risolvere i conflitti. Per mantenere una maggioranza di voter (e quindi il quorum), almeno tre voter devono essere in grado di comunicare reciprocamente. In qualsiasi momento, un numero massimo di due voter può trovarsi offline senza interrompere il servizio e l'accesso ai dati. Se tre o più voter sono offline, il gruppo di disponibilità del database perde il quorum e il servizo e l'accesso ai dati verranno interrotti fino alla risoluzione del problema.

Inizio pagina

Utilizzo di un gruppo di disponibilità del database per la disponibilità elevata

Per illustrare come un gruppo di disponibilità del database può fornire disponibilità elevata per i database delle cassette postali, considerare l'esempio seguente, in cui viene utilizzato un gruppo di disponibilità del database con cinque membri. Questo gruppo di disponibilità del database è illustrato nella figura seguente.

Gruppo di disponibilità del database con cinque membri

Nella figura precedente, i database verdi sono copie del database delle cassette postali attive e i database blu sono copie del database delle cassette postali passive. In questo esempio, non viene eseguito il mirroring delle copie tra ogni server, le copie vengono viceversa ripartite tra più server. In questo modo si assicura che non vi siano due server nel gruppo di disponibilità del database con lo stesso insieme di copie del database e ciò fornisce al gruppo di disponibilità del database maggiore resilienza agli errori, inclusi gli errori che si verificano mentre altri componenti non sono disponibili a causa della normale manutenzione.

Considerare lo scenario seguente, utilizzando il gruppo di disponibilità del database dell'esempio precedente che illustra la resilienza a più errori di database e server.

Inizialmente, tutti i database e i server sono integri. È necessario installare alcuni aggiornamenti del sistema operativo su EX2. Viene eseguito uno switchover del server mediante il quale viene attivata la copia di DB4 su un altro server Cassette postali. Lo switchover del server consente di spostare tutte le copie attive del database delle cassette postali dal server corrente in uso a uno più server Cassette postali nel gruppo di disponibilità del database, in previsione di un'interruzione pianificata del server corrente. È possibile eseguire rapidamente uno switchover del server eseguendo il comando riportato di seguito in Exchange Management Shell.

Move-ActiveMailboxDatabase -Server EX2

In questo esempio, è presente un solo database delle cassette postali attivo in EX2 (DB4), pertanto viene spostata una sola copia del database delle cassette postali attiva. Omettendo il parametro ActivateOnServer nel comando precedente, si è scelto di selezionare automaticamente la nuova copia attiva migliore possibile, e viene scelta la copia in EX5, come illustrato nella figura seguente.

Gruppo di disponibilità del database con un server offline per manutenzione

Mentre viene eseguita la manutenzione su EX2, si verifica un errore hardware irreversibile in EX3 che si disconnette. Prima di disconnettersi, EX3 ospitava la copia attiva di DB2. Per ripristinare il sistema dall'errore, viene automaticamente attivata la copia di DB2 ospitata in EX1 entro 30 secondi. come illustrato nella figura seguente.

Gruppo di disponibilità del database con un server offline per manutenzione e un server in errore

Una volta completata la manutenzione programmata per EX2, il server viene portato online. Non appena EX2 è disponibile, gli altri membri del gruppo di disponibilità del database ne ricevono notifica e le copie di DB1, DB4 e DB5 ospitate su EX2 vengono automaticamente sincronizzate con la copia attiva di ogni database. come illustrato nella figura seguente.

Gruppo di disponibilità del database con un server ripristinato che sincronizza le copie del database

Dopo che il componente hardware che ha causato l'errore in EX3 è stato sostituito, EX3 viene riportato online. Quando EX3 è di nuovo disponibile, gli altri membri del gruppo di disponibilità del database ne ricevono notifica e le copie di DB2, DB3 e DB4 ospitate su EX3 vengono automaticamente sincronizzate con la copia attiva di ogni database. come illustrato nella figura seguente.

Gruppo di disponibilità del database con un server ripristinato che sincronizza le copie del database

Inizio pagina

Utilizzo di un gruppo di disponibilità del database per la resilienza del sito

Oltre a fornire disponibilità elevata in un datacenter, un gruppo di disponibilità del database può essere esteso a uno o più altri datacenter in una configurazione che fornisce resilienza del sito per uno o più datacenter. Nelle figure dell'esempio precedente, il gruppo di disponibilità del database si trova in un unico datacenter e in un unico sito Active Directory. È possibile utilizzare la distribuzione incrementale per estendere questo gruppo di disponibilità del database a un secondo datacenter (e a un secondo sito Active Directory) distribuendo un server Cassette postali e le risorse di supporto necessarie (uno o più server Active Directory e uno o più server Trasporto Hub e Accesso client). Il server Cassette postali viene quindi aggiunto al gruppo di disponibilità del database, come illustrato nella figura seguente.

Gruppo di disponibilità del database esteso tra due siti di Active Directory

In questo esempio, una copia passiva di ogni database attivo nel datacenter di Redmond è configurata in EX6 nel datacenter di Dublino. Esistono tuttavia molti altri esempi di configurazioni del gruppo di disponibilità del database che forniscono resilenza del sito. Ad esempio:

• Anziché ospitare solo le copie passive del database, EX6 potrebbe ospitare tutte le copie attive o un insieme di copie attive e passive.

• Oltre a EX6, nel datacenter di Dublino potrebbero essere distribuiti più gruppi di disponibilità del database, offrendo protezione da ulteriori errori. Questo tipo di configurazione è anche in grado di fornire ulteriori capacità, in modo tale che, se si verifica un errore nel datacenter di Redmond, il datacenter di Dublino è in grado di supportare un numero di utenti molto più grande.

Utilizzo di più gruppi di disponibilità del database per la resilienza del sito

Nell'esempio precedente, un singolo gruppo di disponibilità del database si estende su più datacenter, fornendo resilienza del sito per uno o entrambi i datacenter. Quando si utilizza un singolo gruppo di disponibilità del database per fornire resilienza del sito in un ambiente in cui ogni datacenter a cui viene esteso il gruppo di disponibliità del database ha un gran numero di utenti attivi, esiste un singolo punto di errore nella connessione WAN (Wide Area Network). Ciò avviene perché il quorum richiede che la maggioranza dei voter sia attiva e in grado di comunicare reciprocamente.

Nell'esempio precedente, la maggioranza dei voter si trova nel datacenter di Redmond. Se il datacenter di Dublino ospita database attivi delle cassette postali e dispone di un gruppo di utenti locale, un'interruzione della connessione WAN determinerebbe un'interruzione del servizio di messaggistica per gli utenti di Dublino. Quando si verifica un'interruzione della connettività WAN, solo i membri del gruppo di disponibilità del database del datacenter di Redmond mantengono il quorum e continuano a fornire il servizio di messaggistica.

Per eliminare la rete WAN come singolo punto di errore quando è necessario fornire resilienza del sito per più datacenter che dispongono ciascuno di un gruppo di utenti attivo, è consigliabile distribuire più gruppi di disponibilità del database, in cui ogni DAG dispone della maggioranza dei voter in un datacenter separato. Quando si verifica un'interuzione della connettività WAN, la replica verrà bloccata fino al ripristino della connettività. Gli utenti potranno utilizzare il servizio di messaggistica, dal momento che ogni gruppo di disponibilità del database continua a servire il proprio gruppo di utenti locale.

Inizio pagina

Prestazioni del client quando si utilizzano i gruppi di disponibilità del database

I gruppi di disponibilità del database possono essere utilizzati per fornire sia disponibilità elevata che resilienza del sito. Le prestazioni del client quando si utilizza un gruppo di disponibilità del database dipendono dal tipo e della versione del client e dal protocollo utilizzato dal client per accedere ai dati delle cassette postali. Ad esempio, se si verifica un failover del database tra più siti, la logica del comportamento e della riconnessione utilizzata da un client POP3 o IMAP4 è diversa dalla logica del comportamento e della riconnessione utilizzata da un client Microsoft Outlook 2010.

Nelle sezioni seguenti vengono descritti il comportamento e la logica del client in diversi scenari. Il comportamento descritto presuppone che:

• L'ambiente contiene un singolo array del server Accesso client in ogni sito Active Directory e ogni sito contiene almeno due server Accesso client.

• Un bilanciamento del carico appropriato basato su hardware o su software è stato installato e configurato davanti all'array del server Accesso client.

• È stata completata un'adeguata pianificazione dello spazio dei nomi e dei certificati, inclusi i record DNS necessari.

Comportamento e logica di Microsoft Outlook

In genere, tutte le versioni di Outlook si comportano allo stesso modo quando i failover del database che si verificano in un singolo datacenter e in un unico sito Active Directory. Diversamente dalle versioni precedenti di Exchange, in Exchange 2010, Outlook non si connette più direttamente all'archivio di Exchange sul server Cassette postali. Diversamente, Outlook (e gli altri client MAPI) viene connesso ai servizi Accesso client RPC e Rubrica nel ruolo del server Accesso client e Outlook dell'utente viene configurato per la connessione all'array del server Accesso client, che quindi connette il client a un singolo server Accesso client. I vantaggi offerti dalla mancata connessione di Outlook al server Cassette postali sono i seguenti:

• Quando si verifica un failover del database, Outlook rimane connesso allo stesso server nell'array del server Accesso client. In questo caso, Active Manager del gruppo di disponibilità del database segnala al client Active Manager in esecuzione sul server Accesso client quale membro del gruppo di disponibilità del database ospita la copia attiva del database. Il server Accesso client si connette quindi al server Cassette postali e Outlook segnala che è connesso al server Exchange.

• Se uno dei server Accesso client nell'array del server Accesso client non è disponibile a causa di un'interruzione, pianificata o meno, i server Accesso client rimanenti nell'array gestiscono il carico del client. Poiché Outlook è configurato per la connessione all'array del server Accesso client e non al singolo server Accesso client, possono verificarsi degli errori nei singoli membri dell'array del server Accesso client oppure possono essere portati offline manualmente senza influire sul profilo di Outlook dell'utente. Ciò si può verificare automaticamente (ad esempio, riconfigurazione automatica dell'array, basata sul monitoraggio eseguito dalla soluzione di bilanciamento del carico davanti all'array) o può essere eseguito manualmente.

Tutte le versioni di Outlook si comportano allo stesso modo quando si verificano switchover del datacenter tra due datacenter e due siti Active Directory. Gli switchover del data center comportano la modifica degli indirizzi IP utilizzati dagli spazi dei nomi di accesso client (ad esempio, Microsoft Office Outlook Web App, SMTP, POP3, IMAP4, Individuazione automatica, Servizi Web Exchange o Accesso client RPC), dagli indirizzi IP nel datacenter principale agli indirizzi IP nel datacenter secondario. Di conseguenza, lo spazio dei nomi utilizzato nel profilo Outlook dell'utente non viene modificato e Individuazione automatica continua a indirizzare i client allo stesso spazio dei nomi dell'array del server Accesso client.

Il comportamento di Outlook dopo un failover di database tra diversi siti è diverso dal comportamento dopo un failover di database in un singolo sito Active Directory o dopo uno switchover del database.

Esempio di comportamento delle versioni di Outlook

Negli esempi seguenti viene descritto il comportamento di Outlook 2010, Office Outlook 2007 e Office Outlook 2003 dopo che si è verificato un failover di database tra diversi siti. In tutti gli esempi viene utilizzata una topologia costituita da un gruppo di disponibilità del database con quattro membri esteso su due siti di Active Directory, ovvero Redmond e Portland. La cassetta postale dell'utente è ospitata su DB1, che viene replicato per ciascun server. In ogni esempio si verifica un failover della copia attiva di DB1 da MBX2 a MBX3.

Topologia di esempio con dimostrazione del comportamento di Outlook dopo un failover di database tra siti diversi

Ogni client è configurato con CAS1 come server principale, rendendo Redmond il sito profili di Outlook. Poiché i client si trovano a Redmond, la proprietà RPCClientAccessServer per DB1 è configurata per CAS1, rendendo Redmond il sito del database preferenziale. Poiché in DB1 si è verificato un errore su MBX2 ed è stato attivato su MBX3, Portland è il sito del database montato.

Esempio per Outlook 2010 e Outlook 2007

Se è disponibile un server Accesso client nel sito di Redmond, Outlook 2010 e Outlook 2007 continueranno a connettersi all'array RPC del server Accesso client nel sito di Redmond. Il server Accesso client utilizzato dal client comunicherà utilizzando RPC MAPI con il server Cassette postali dell'utente nel sito di Portland.

Se non sono disponibili server Accesso client nel sito di Redmond, dovrà essere eseguito uno switchover del centro dati da Redmond a Portland per ripristinare l'accesso ai servizi ed ai dati. Per la procedura dettagliata relativa all'esecuzione di uno switchover del centro dati, vedere Esecuzione del passaggio di un server.

Esempio per Outlook 2003

Quando Outlook 2003 cerca di stabilire una connessione a CAS1, riceve un messaggio di ecWrongServer come risposta. Diversamente da Outlook 2010 e Outlook 2007, Outlook 2003 non include la funzionalità Individuazione automatica ed è necessario utilizzare altri metodi per aggiornare il profilo dell'utente. Il reindirizzamento del profilo MAPI è il meccanismo utilizzato da Outlook 2003. Il reindirizzamento del profilo MAPI richiede che il server di origine sia online. Se CAS1 non è disponibile e se anche tutti gli altri server Accesso client dell'array non sono disponibili (o se l'array contiene solo CAS1), Outlook 2003 non sarà in grado di eseguire il reindirizzamento MAPI o la connessione al database delle cassette postali dell'utente senza intervento manuale.

Comportamento e logica di Outlook e quando si utilizzano le cartelle pubbliche

Anche se i database delle cartelle pubbliche possono essere ospitati sui server Cassette postali membri di un gruppo di disponibilità del database, i database delle cartelle pubbliche non utilizzano la replica continua e si basano sulla replica delle cartelle pubbliche per la disponibilità elevata. Il comportamento dei client di Outlook in fase di riconnessione a un database delle cartelle pubbliche dopo un failover del database delle cassette postali non dipende solo dalla natura dell'errore, ma dalle impostazioni di configurazione della replica delle cartelle pubbliche e dall'integrità e dal livello di aggiornamento dei database delle cartelle pubbliche. Poiché non è possibile utilizzare la replica continua per i database delle cartelle pubbliche, la disponibilità elevata per i database delle cartelle pubbliche viene realizzata distribuendo più database delle cartelle pubbliche e configurandoli per la replica reciproca. Si consiglia di configurare più repliche di ogni cartella.

Comportamento e logica di un client non Outlook

In genere, il comportamento dei client e dei protocolli diversi da Outlook e MAPI varia in base all'applicazione utilizzata e allo scenario di errore. Generalmente, come per Outlook, le applicazioni e i client di Exchange tipici (ad esempio, Outlook Web App, Microsoft Exchange ActiveSync, POP3, IMAP4 e Servizi Web Exchange) si comportano allo stesso modo quando si verificano failover del database in un unico datacenter e in un singolo sito Active Directory. Analogamente, tutti i client e i protocolli citati (inclusi SMTP e Windows PowerShell) si comportano allo stesso modo di Outlook dopo lo switchover di un datacenter.

Se si verifica un failover di database tra siti diversi, il comportamento varia a seconda dei client e dei protocolli. Nella tabella seguente vengono elencati i comportamenti dei client citati.

Comportamento in seguito a failover del database tra siti diversi

Client o protocollo	Comportamento
Outlook Web App	Reindirizzamento manuale. In questo scenario, lo spazio dei nomi del client viene modificato da http://mailred.contoso.com a http://mailpdx.contoso.com. Una volta immesse le credenziali di accesso, l'utente viene reindirizzato a CAS2 nel sito di Portland tramite una pagina di reindirizzamento manuale in cui viene spiegato che è stato utilizzato l'URL errato e che l'URL corretto è https://mailpdx.contoso.com/owa.
Exchange ActiveSync	Proxy o reindirizzamento. In questo scenario, il comportamento del client è determinato dall'implementazione e dalla versione del protocollo di Exchange ActiveSync del dispositivo client.
POP3 e IMAP4	Proxy. Questo scenario comporta sempre il proxy tra server Accesso client.
Servizi Web di Exchange	Utilizza la funzionalità Individuazione automatica per determinare il nuovo endpoint di connessione.

Inizio pagina

 ©2010 Microsoft Corporation. Tutti i diritti riservati.