Informazioni su Active Manager

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

Ultima modifica dell'argomento: 2015-03-09

Microsoft Exchange Server 2010 include un nuovo componente Active Manager che fornisce funzionalità in grado di sostituire il modello delle risorse e le funzionalità di gestione del failover fornite dall'integrazione con il servizio Cluster nelle precedenti versioni di Exchange. Exchange non utilizza più il modello di risorse del cluster per la disponibilità elevata. Tutte le risorse cluster di Exchange fornite da exres.dll non esistono più, compreso il costrutto chiamato server di cassette postali in cluster. Exchange utilizza un cluster di failover di Windows, ma non esistono gruppi di cluster per Exchange e non sono presenti risorse di archiviazione nel cluster. Di conseguenza, se si esamina il cluster utilizzando gli strumenti di gestione del cluster, sono visibili solo le risorse cluster principali (indirizzo IP e nome di rete e, se necessario, la risorsa quorum). I nodi e le reti cluster esistono ancora, ma sono gestite da Exchange e non dal cluster o dagli strumenti cluster.

Active Manager viene eseguito come ruolo su tutti i server Cassette postali. Nei server Cassette postali non configurati per la disponibilità elevata, è disponibile un singolo ruolo di Active Manager: Active Manager autonomo. Nei server membri di un gruppo di disponibilità del database (DAG), sono disponibili due ruoli di Active Manager: Active Manager principale (PAM) e Active Manager di standby (SAM). PAM è l'Active Manager in un gruppo di disponibilità del database che decide quali copie sono attive o passive. PAM è responsabile del recupero delle notifiche di cambiamento della tecnologia e della risposta agli errori del server. Il membro del gruppo di disponibilità del database che contiene il ruolo PAM è sempre il membro che possiede attualmente la risorsa quorum del cluster (gruppo di cluster predefinito). Se il server che possiede la risorsa quorum del cluster incontra un errore, il ruolo PAM passa automaticamente a un server ancora attivo, che assume la proprietà della risorsa quorum del cluster. Inoltre, se è necessario scollegare il server che ospita la risorsa quorum del cluster per ragioni di manutenzione o di aggiornamento, è necessario spostare prima il PAM in un altro server del gruppo di disponibilità del database. Il PAM controlla tutti gli spostamenti delle designazioni attive tra le copie di un database (solo una copia può essere attiva in un dato momento e tale copia può essere montata o smontata). Il PAM esegue anche le funzioni del ruolo SAM sul sistema locale (rilevamento degli errori del database locale e dell'Archivio informazioni locale).

Il SAM fornisce informazioni sul server che ospita la copia attiva di un database delle cassette postali agli altri componenti di Exchange che eseguono un componente client di Active Manager (ad esempio il servizio Accesso client RPC o il server Trasporto Hub). Il SAM rileva gli errori dei database locali e dell'Archivio informazioni locale. Per rispondere a tali errori richiede al PAM l'avvio di un failover (se il database è replicato). Un SAM non determina la destinazione del failover e non aggiorna lo stato della posizione del database nel PAM. Accede allo stato della posizione della copia attiva del database solo per rispondere alle query ricevute in relazione alla copia attiva del database.

In Exchange 2010, il servizio di replica di Microsoft Exchange consente di controllare periodicamente l'integrità di tutti i database montati. Inoltre, controlla ESE (Extensible Storage Engine) alla ricerca di errori di I/O. Se il servizio rileva un errore, viene inviata una notifica ad Active Manager, che determina quale copia del database dovrebbe essere montato e quali sono i requisiti per il montaggio di tale database. Inoltre, tiene traccia della copia attiva di un database delle cassette postali (basandosi sull'ultima copia montata del database) e fornisce le informazioni sui risultati della verifica al componente Accesso client RPC sul server Accesso client a cui è connesso il client.

Selezione della copia migliore in Active Manager

Quando si verifica un errore che incide sul database delle cassette postali replicato, Active Manager esegue la procedura di risoluzione del problema selezionando la miglior copia possibile del database in cui si è verificato l'errore per l'attivazione. Il processo generale ha luogo nel seguente ordine:

1. Active Manager rileva l'errore.

2. Il PAM esegue un algoritmo interno denominato selezione della copia migliore (BCS).

3. Viene eseguito un processo denominato ACLL (Attempt Copy Last Logs), che cerca di copiare i file di log mancanti dal server che ha ospitato la copia attiva del database prima del failover.

4. Una volta completato il processo ACLL, il PAM invia una richiesta di montaggio ad Archivio informazioni di Microsoft Exchange tramite una chiamata di procedura remota (RPC). A questo punto, è possibile uno dei due eventi indicati di seguito:

   1. Il database viene montato ed è disponibile per i client; oppure

   2. Il database non viene montato e il PAM esegue i passaggi 3 e 4 sulla migliore copia successiva (se disponibile).

Durante la ricerca della miglior copia possibile, il PAM utilizza fino a dieci set di criteri separati per determinare la miglior copia da attivare. Dopo averla individuata, viene eseguito il processo ACLL. Al termine del processo ACLL, se tutti i file di log mancanti sono stati copiati dalla copia attiva precedente, il database viene montato senza alcuna perdita di dati. In questo caso si parla di failover senza perdite. Se il processo ACLL ha esito negativo, viene analizzato il valore configurato per AutoDatabaseMountDial. Per ulteriori informazioni su AutoDatabaseMountDial, vedere Set-MailboxServer. Se il numero di registri persi è inferiore al valore configurato per AutoDatabaseMountDial, il database viene montato. Se il numero di registri persi è superiore al valore configurato per AutoDatabaseMountDial, il database non viene montato fino al ripristino dei file di registro mancanti o fino a quando un amministratore non esegue il montaggio esplicito del database, accettando la perdita dei dati. Se il database non viene montato automaticamente, il PAM selezionerà la miglior copia successiva (se disponibile). Sono almeno tre i motivi per cui la copia del database inizialmente selezionata non viene montata automaticamente:

1. Il numero di file di log persi è maggiore del valore configurato per AutoDatabaseMountDial.

2. Il server su cui è stato effettuato il tentativo di montaggio è configurato con un valore basso per il numero attivo di database e il numero massimo di copie attive del database è stato raggiunto sul server.

3. La copia del database è sospesa per l'attivazione.

Processo di selezione della copia migliore

Active Manager inizia il processo di selezione della copia migliore creando un elenco di copie del database che sono potenziali candidati all'attivazione. Le copie del database che risultano irraggiungibili o che presentano un blocco amministrativo che ne pregiudica l'attivazione (utlizzando la proprietà DatabaseCopyAutoActivationPolicy del cmdlet Set-MailboxServer) vengono ignorate e non utilizzate durante il processo di selezione. L'ordine dell'elenco dipende dalla versione di Exchange 2010:

• Nella versione di produzione (RTM) di Exchange 2010, Active Manager ordina l'elenco ottenuto utilizzando la lunghezza della coda di copia come chiave primaria. Il calcolo è basato su LastLogInspected (dal punto di vista della copia), quindi l'elenco delle copie potenziali viene ordinato in base al valore più alto per LastLogInspected (che sarà la copia con la lunghezza della coda di copia più bassa). Active Manager ordina quindi l'elenco una seconda volta utilizzando il valore per ActivationPreference come chiave secondaria. La copia con il valore ActivationPreference più basso avrà la priorità più alta nell'elenco.

• In Exchange 2010 Service Pack 1 (SP1), il comportamento è identico se confrontato con la versione RTM, ad eccezione dei server configurati con il valore di montaggio del database automatico Senza perdita di dati. Quando si utilizza l'impostazione Senza perdita di dati, Active Manager ordina l'elenco ottenuto in ordine crescente utilizzando il valore per ActivationPreference come chiave primaria. Tale comportamento è preimpostato per ridurre al minimo un eventuale squilibrio del database spostando le operazioni (ad esempio gli switchover o quando si esegue StartDagServerMaintenance.ps1).

Di seguito, Active Manager tenta di individuare nell'elenco una copia delle cassette postali del database con stato Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing o SeedingSource, quindi valuta la potenziale attivazione di ogni copia dell'elenco utilizzando un ordine impostato di dieci criteri. Active Manager determina se uno dei candidati all'attivazione soddisfa il primo set di criteri:

• Dispone di un indice del contenuto con stato Healthy.

• Presenta una lunghezza della coda di copia inferiore a 10 file di registro.

• Presenta una lunghezza della coda di riesecuzione inferiore a 50 file di registro.

Se nessuna delle copie del database soddisfa il primo set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare il set di criteri successivo:

• Dispone di un indice del contenuto con stato Crawling.

• Presenta una lunghezza della coda di copia inferiore a 10 file di registro.

• Presenta una lunghezza della coda di riesecuzione inferiore a 50 file di registro.

Se nessuna delle copie del database soddisfa il secondo set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare il terzo set di criteri:

• Dispone di un indice del contenuto con stato Healthy.

• Presenta una lunghezza della coda di riesecuzione inferiore a 50 file di registro.

Se nessuna delle copie del database soddisfa il terzo set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare il quarto set di criteri:

• Dispone di un indice del contenuto con stato Crawling.

• Presenta una lunghezza della coda di riesecuzione inferiore a 50 file di registro.

Se nessuna delle copie del database soddisfa il quarto set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare il quinto set di criteri:

• Presenta una lunghezza della coda di riesecuzione inferiore a 50 file di registro.

Se nessuna delle copie del database soddisfa il quinto set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare il sesto set di criteri:

• Dispone di un indice del contenuto con stato Healthy.

• Presenta una lunghezza della coda di copia inferiore a 10 file di registro.

Se nessuna delle copie del database soddisfa il sesto set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare il settimo set di criteri:

• Dispone di un indice dei contenuti con stato Crawling.

• Presenta una lunghezza della coda di copia inferiore a 10 file di log.

Se nessuna delle copie del database soddisfa il settimo set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare l'ottavo set di criteri:

• Dispone di un indice del contenuto con stato Healthy.

Se nessuna delle copie del database soddisfa l'ottavo set di criteri, Active Manager cerca di individuare una copia del database in grado di soddisfare il nono set di criteri:

• Dispone di un indice del contenuto con stato Crawling.

Se nessuna delle copie del database soddisfa il nono set di criteri, Active Manager cerca di attivare una qualsiasi copia del database con stato Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing o SeedingSource (il decimo set di criteri). Se non sono disponibili copie del database in grado disoddisfare il decimo set di criteri. non viene attivata automaticamente alcuna copia del database.

Una volta individuate una o più copie in grado di soddisfare uno o più set di criteri, viene eseguito il processo ACLL per copiare i file di log dall'origine alla potenziale nuova copia attiva. Una volta complettao il processo ACLL, il PAM invia una richiesta di montaggio e il database viene montato ed è di nuovo disponibile per i client, oppure non viene montato e il PAM cerca la copia migliore successiva (se disponibile).

Esempi di selezione della copia migliore

Nella sezione seguente vengono illustrati alcuni esempi del processo di selezione e attivazione della copia migliore di Active Manager.

Esempio 1: Scenario di base

In questo esempio sono disponibili quattro copie del database delle cassette postali DB1. DB1 è attualmente attivo su Server1, in cui si verificato un errore hardware. Nella tabella seguente viene mostrato lo stato corrente delle copia del database di DB1 su Server2, Server3 e Server4.

Se le copie disponibili vengono ordinate in base alle lunghezze delle code di copia (utilizzando Preferenza di attivazione, se necessario), si ottiene un elenco ordinato come segue:

• Server3\DB1

• Server2\DB1

• Server4\DB1

Al di fuori dell'elenco, solo due copie del database soddisfano il primo set di criteri per l'attivazione:

• la copia su Server3, il cui stato del database è Disconnectedandhealthy, una lunghezza della coda di copia minore di 10, una lunghezza della coda di replica minore di 50 e un indice dei contenuti integro.

• La copia su Server3, il cui stato del database è Healthy, una lunghezza della coda di copia minore di 10, una lunghezza della coda di replica minore di 50 e un indice di contenuto integro.

Di queste due copie, la copia su Server3 presenta la lunghezza della coda di copia più bassa; pertanto, Server3 viene selezionato come la potenziale copia da attivare dato che presenta la minor quantità di dati mancanti.

Una volta attivata la copia su Server3, il servizio di replica di Microsoft Exchange su Server3 esegue il processo ACLL e tenta di copiare i file di log mancanti dal server attivo precedente (in questo caso, Server1). Una volta completato il processo ACLL, al PAM vengono notificati i risultati del processo ACLL. Se tutti i registri vengono copiati in modo corretto, il database verrà contrassegnato come copia attiva e sarà montato senza alcuna perdita di dati. Se mancano uno o più registri, si farà riferimento al valore del parametro AutoDatabaseMountDial. Se la perdita dei dati rientra nel valore configurato, il database verrà contrassegnato come copia attiva e sarà montato senza alcuna perdita di dati. La maggior parte dei dati mancanti sarà quindi ripristinata dal dumpster di trasporto.

Se Active Manager non invia una richiesta di montaggio all'Archivio informazioni e l'operazione di montaggio non riesce, Active Manager tornerà all'elenco ordinato precedente e tenterà di attivare la migliore copia successiva (in questo caso, Server2).

Esempio 2: Due copie con la stessa lunghezza della coda di copia

In questo esempio sono disponibili quattro copie del database delle cassette postali DB2. DB2 è attualmente attivo su Server1, in cui si verificato un errore hardware. Nella tabella seguente viene mostrato lo stato corrente delle copia del database di DB2 su Server2, Server3 e Server4.

Se le copie disponibili vengono ordinate in base alle lunghezze delle code di copia (utilizzando Preferenza di attivazione, se necessario), si ottiene un elenco ordinato come segue:

• Server2\DB2

• Server3\DB2

• Server4\DB2

Al di fuori dell'elenco, solo due copie del database soddisfano il primo set di criteri per l'attivazione:

• La copia su Server3, il cui stato del database è Healthy, una lunghezza della coda di copia minore di 10, una lunghezza della coda di replica minore di 50 e un indice di contenuto integro.

• La copia su Server3, il cui stato del database è DisconnectedandHealthy, una lunghezza della coda di copia minore di 10, una lunghezza della coda di replica minore di 50 e un indice di contenuto integro.

Di queste due copie, la copia su Server2 presenta una lunghezza della coda di copia uguale alla copia su Server3, ma presenta anche un valore più basso per Preferenza di attivazione; quindi la copia su Server2 si trova in cima all'elenco e viene selezionata come la copia da attivare, dato che presenta la minor quantità di dati mancanti e il valore più basso per Preferenza di attivazione.

Esempio 3: Copie con stato del database identico e stato dell'indice dei contenuti diverso

In questo esempio sono disponibili quattro copie del database delle cassette postali DB3. DB3 è attualmente attivo su Server1, in cui si verificato un errore hardware. Nella tabella seguente viene mostrato lo stato corrente delle copia del database di DB3 su Server2, Server3 e Server4.

Se le copie disponibili vengono ordinate in base alle lunghezze delle code di copia (utilizzando Preferenza di attivazione, se necessario), si ottiene un elenco ordinato come segue:

• Server2\DB3

• Server3\DB3

• Server4\DB3

Le tre copie del database ospitate sui server sopra citati soddisfano i criteri di attivazione. Nonostante Server2 presenti un valore più basso per Activation Preference, lo stato dell'indice dei contenuti è Crawling; di conseguenza, quando Active Manager controlla l'elenco in base al primo set di criteri (che include un indice dei contenuti con stato Healthy), la copia del database su Server3 sarà la copia prescelta, dal momento che lo stato dell'indice dei contenuti è Healthy.

Esempio 4: Effetto di AutoDatabaseMountDial sulla selezione della copia migliore

In questo esempio sono disponibili quattro copie del database delle cassette postali DB4. DB4 è attualmente attivo su Server1, in cui si è verificato un errore che ne ha causato il riavvio. Nella tabella seguente viene mostrato lo stato corrente delle copie del database di DB4 su Server2, Server3 e Server4. Il parametro AutoDatabaseMountDial per tutti i server Cassette postali nel gruppo di disponibilità del database è configurato per Senza perdita di dati (la lunghezza della coda di copia è 0).

Poiché le impostazioni di montaggio automatico del database sono impostate su Senza perdita di dati, Active Manager utilizza Preferenza di attivazione anziché la lunghezza della coda di copia come chiave di ordinamento primaria. Se le copie disponibili vengono ordinate in base ai risultati della Preferenza di attivazione, si otterrà un elenco ordinato come segue:

• Server2\DB4

• Server3\DB4

• Server4\DB4

Nessun database soddisfa il primo, il secondo o il terzo set di criteri, ma la copia del database su Server3 soddisfa il quarto set di criteri (presenta un indice dei contenuti con stato Crawling e una lunghezza della coda di replica inferiore a 50). La copia del database su Server3 presenta una lunghezza della coda di copia con valore 100, ma poiché Server1 non ha terminato il riavvio, il processo ACLL non è in grado di copiare i file di log mancanti su Server3. Il processo ACLL segnala al PAM che la quantità di dati mancanti non rientra nel valore configurato per il parametro AutoDatabaseMountDial e quindi il PAM selezionerà la miglior copia disponibile successiva.

Nello scenario precedente, le copie del database su Server2 e Server4 corrispondono al sesto set di criteri (presentano un database e un indice dei contenuti integro e una lunghezza della coda di copia inferiore a 10). La copia del database su Server2 rappresenta il tentativo successivo, dal momento che occupa la posizione più alta nell'elenco ordinato delle copie disponibili. Il processo ACLL viene eseguito su Server2, ma Server1 non è ancora in grado di comunicare in rete e il processo ACLL non è in grado di copiare alcun registro. Tuttavia, poiché la lunghezza della coda di copia rientra nel valore configurato per il parametro AutoDatabaseMountDial, il processo ACLL invia un messaggio di operazione riuscita al PAM e il PAM invia una richiesta di montaggio del tramite RPC.

 ©2010 Microsoft Corporation. Tutti i diritti riservati.