Interruzioni pianificate e non pianificate

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2007-10-29

Le interruzioni pianificate e non pianificate sono le due forme di interruzione utilizzate in un ambiente di replica continua cluster (CCR, Cluster Continuous Replication). Le interruzioni pianificate vengono avviate esplicitamente da un amministratore per eseguire il ripristino in seguito a un errore o per eseguire un'operazione di manutenzione. Le interruzioni non pianificate si riferiscono a eventi imprevisti che danno origine all'indisponibilità del servizio, dei dati o di entrambi. La replica continua cluster è progettata per gestire le interruzioni sia pianificate sia non pianificate.

Interruzioni pianificate

La replica continua cluster consente di pianificare un'interruzione estesa del sistema di un determinato nodo senza un'interruzione estesa del server di cassette postali in cluster. La funzionalità di interruzione pianificata della replica continua cluster è stata progettata per garantire che tutti i dati del registro sul nodo attivo vengano copiati correttamente nel nodo passivo. Pertanto, durante le interruzioni pianificate non si verificano mai perdite di dati, anche se la replica viene eseguita in modo asincrono. Se si verificano errori e conseguenti failover, è possibile che i dati più recenti del registro non siano disponibili nel nodo passivo quando viene portato in linea.

In una soluzione CCR è possibile mettere non in linea un solo nodo per volta. Se più nodi sono non in linea contemporaneamente, il servizio viene interrotto. In qualsiasi momento specifico, o il computer host della condivisione di file per il quorum maggioranza dei nodi (MNS) condivide il testimone o il nodo passivo del cluster di failover può essere messo non in linea per manutenzione, aggiornamenti e riparazioni hardware e software. È consigliabile non disattivare mai un nodo se non si è prima verificato se è attivo o se ospita risorse. Per determinare se ospita risorse, utilizzare Amministrazione cluster. È possibile verificare lo stato del nodo eseguendo il cmdlet Get-ClusteredMailboxServerStatus in Exchange Management Shell. Per ulteriori informazioni sulla visualizzazione dello stato di un server di cassette postali in cluster, vedere Come visualizzare lo stato del server cassette postali cluster.

Attività amministrative

Le interruzioni pianificate vengono avviate esplicitamente da un amministratore per eseguire il ripristino in seguito a un errore o per eseguire un'operazione di manutenzione. L'interruzione pianificata consente al sistema di spostare il server di cassette postali in cluster dal nodo attivo a quello passivo (rendendo così il nodo passivo il nuovo nodo attivo) e di montare i database e i gruppi di archiviazione replicati. Una volta montati, i database diventano la fonte di tutti gli aggiornamenti successivi per tutte le nuove repliche. Le due copie invertono i ruoli delle repliche, quello della copia che genera le modifiche al database e quello della copia che le riceve e le applica.

Poiché la replica continua cluster utilizza la replica asincrona, la transizione del server di cassette postali in cluster attivo da un nodo a un altro all'interno del cluster necessita del coordinamento tra il cluster e il supporto della replica. La replica continua cluster implementa tale coordinamento. L'amministratore avvia un'interruzione pianificata con il cmdlet Move-ClusteredMailboxServer di Exchange Management Shell.

Il cmdlet Move-ClusteredMailboxServer verifica che il nodo passivo disponga di una copia valida e integra e che tale copia sia relativamente corrente. Se la copia non è relativamente corrente, è possibile estendere l'interruzione durante il completamento della replica. Se le verifiche hanno esito positivo, la transizione viene avviata. In caso di assenza di errori durante lo spostamento, l'attività viene completata quando il server di cassette postali in cluster viene eseguito sul nodo selezionato e tutti i database sono montati. Durante questo processo è possibile che si verifichino errori che impediscono la transizione o interessano il montaggio automatico di tutti i database. In questo caso, subentra il comportamento dell'interruzione non pianificata.

In alcuni casi le interruzioni pianificate vengono utilizzate per ripristinare server interessati da errori parziali, ad esempio server con database o file di registro corrotti. In questo caso, la logica di invio dei registri tramite il sistema di replica blocca il cmdlet Move-ClusteredMailboxServer. L'amministratore dispone di una semplice opzione per gestire questo scenario; smonta i database che presentano problemi ed emette il comando Move-ClusteredMailboxServer con un'opzione che tenta di copiare i registri associati ai database disinstallati, senza però compromettere lo spostamento nel caso in cui non fosse possibile copiarli tutti. Il risultato è il recupero agevole, anche di un gruppo di archiviazione corrotto, con il cmdlet Move-ClusteredMailboxServer.

Il cmdlet Move-ClusteredMailboxServer consente a un amministratore di registrare le ragioni dell'avvio dello spostamento, riportate nel registro eventi. Il comando obbliga inoltre l'amministratore a specificare il nodo che ospiterà il server di cassette postali in cluster, evitando così lo spostamento erroneo del server di cassette postali in cluster quando è già ospitato sul nodo corretto.

L'interfaccia di gestione da riga di comando Cluster.exe e l'interfaccia utente grafica (GUI, Graphical User interface) Amministrazione cluster includono entrambe la possibilità di spostare un server di cassette postali in cluster. L'utilizzo di questi metodi attiva la logica di svuotamento della replica. Si consiglia tuttavia di non utilizzare questi metodi per le seguenti ragioni:

• Questi metodi non convalidano l'integrità o lo stato della copia passiva. Quindi, il loro utilizzo può dare luogo alla possibilità di un'interruzione estesa mentre il nodo esegue le operazioni di replica per rendere il database montabile.

• Inoltre, è possibile che questi metodi lascino il database non in linea per un tempo indefinito a causa dell'interruzione della replica.

Ripristino dell'attività di replica dopo un'interruzione pianificata

Il processo di ripristino di un ambiente di replica continua cluster dopo un'interruzione pianificata di un nodo attivo è il riavvio del nodo. La replica viene automaticamente avviata all'avvio del sistema. I casi da considerare sono due:

• L'interruzione pianificata è riuscita, non ha mostrato errori durante la transizione associata all'interruzione pianificata e tutti i database sono andati automaticamente in linea. In questo caso l'amministratore ha eseguito l'interruzione pianificata in modo da garantire che gruppi di archiviazione e database dei due nodi fossero coerenti. Di conseguenza il nodo può essere riattivato e continuare immediatamente ad eseguire le repliche. È possibile rendere la copia corrente, rieseguendo i registri senza alcuna operazione particolare.

• L'interruzione pianificata è riuscita solo parzialmente oppure alcuni database erano corrotti prima che venisse eseguita. In questo caso, l'interruzione pianificata non può dimostrare che tutti i registri dell'origine erano disponibili per la destinazione prima che venissero montati i relativi database. Di solito questa situazione si verifica a causa di un errore che si è verificato prima dell'interruzione pianificata o ad uno stadio avanzato delle operazioni di interruzione pianificata. Di conseguenza, i database di origine e di destinazione non sono coerenti. In alcuni casi, la replica continua cluster può eseguire automaticamente il ripristino da alcune incoerenze. In questo caso la replica avvierà ed elaborerà tutti i registri disponibili. Se la replica non riesce a eseguire il ripristino automatico, la copia verrà contrassegnata come interrotta e verrà generato un evento che indica il problema. Se l'archiviazione è fattibile, la prima operazione di ripristino da eseguire è il reseeding della copia. Per ulteriori informazioni sulla procedura per la risoluzione di questi problemi, vedere Come eseguire il seeding di una copia della replica continua cluster.

Interruzioni non pianificate

Le interruzioni non pianificate si verificano come risposta automatica del sistema ad alcuni tipi di errori. La replica continua cluster si concentra sul ripristino automatico di tali errori qualora si sia sicuri che la disponibilità verrà incrementata e che la maggior parte degli ambienti trarrà beneficio dal ripristino automatico.

Un'interruzione non pianificata consente al sistema di attivare il server Cassette postali sul nodo passivo rendendolo di conseguenza attivo e di montare i database e i gruppi di archiviazione replicati. Una volta montati, i database diventano la fonte di tutti gli aggiornamenti successivi per tutte le nuove repliche. Le due copie invertono i ruoli delle repliche, quello della copia che genera le modifiche al database e quello della copia che le riceve e le applica.

Poiché la replica continua cluster utilizza la replica asincrona, l'esecuzione di un'interruzione non pianificata implica la perdita di alcuni dati. Per lo meno i registri scritti attivamente dal server attivo non sono disponibili per le attività di ripristino. La replica continua cluster risolve questo problema fornendo il controllo amministrativo del comportamento di failover e una funzionalità per recuperare in massa tutti i dati che verrebbero potenzialmente interessati.

Se si verifica un failover, la replica continua cluster attiverà sempre il server Cassette postali sul nodo passivo restante. I controlli di sistema vengono eseguiti se i database sono montati su questo nuovo nodo attivo. La replica continua cluster fornisce controlli amministrativi per determinare se i database sono montati. La posizione predefinita è Best availability. Il sistema monterà automaticamente in questa posizione tutti i database sincronizzati con il database di produzione precedentemente attivo. Best availability consente più varianti nell'incoerenza delle due copie. Come regola generale, Good availability porterà un database in linea se durante la generazione di un nuovo registro è stato replicato l'ultimo registro generato. Lossless garantisce che la copia non venga portata in linea a meno che non possa essere confermato che non vi saranno perdite di dati. Se si utilizza questa impostazione, il ripristino automatico avverrà solo se il server originario è di nuovo operativo e tutti i dati di registro sono disponibili e integri.

Se uno o più database si trovano in una condizione che impedisce il montaggio automatico, l'amministratore può comunque decidere esplicitamente di montare la copia con il contenuto disponibile. L'amministratore deve verificare lo stato della copia ed emettere due comandi. il primo informa il motore di replica che la copia deve diventare l'origine della replica (l'origine delle modifiche), ossia montabile, mentre il secondo monta il database.

Per ulteriori informazioni sul ripristino a seguito di danneggiamento dei dati o errori quando la replica continua cluster è abilitata, vedere Gestione della replica continua cluster.

Controlli amministrativi

Vengono forniti controlli amministrativi per controllare il comportamento in caso di un'interruzione non pianificata. La replica continua cluster assegna un attributo per i server Cassette postali utilizzabili per controllare il comportamento dell'interruzione non pianificata. L'attributo AutoDatabaseMountDial può presentare tre valori: Lossless, Good availability, and Best availability.

• Lossless   Indica la perdita di nessun registro. Se l'attributo è impostato su Lossless, nella maggior parte dei casi il sistema attenderà il ritorno in linea del nodo guasto prima del montaggio dei database. Anche in questo caso il sistema in stato di errore deve essere ripristinato con tutti i registri accessibili e integri. Dopo il guasto, il nodo passivo viene reso attivo e il servizio Archivio informazioni di Microsoft Exchange viene portato in linea. Verifica che i database possano essere montati senza perdita di dati. In caso affermativo i database vengono montati, diversamente il sistema tenterà periodicamente di eseguire la copia dei registri. Se il server viene ripristinato con i registri integri, il tentativo riuscirà con conseguente montaggio dei database, in caso contrario i registri rimasti non saranno disponibili e il database interessato non verrà montato.

  Nota

  Una volta completato il failover, l'amministratore potrà decidere in qualsiasi momento di intervenire e decidere di eseguire il montaggio con i database e i registri disponibili sul nodo che era precedentemente passivo. Questa attività viene eseguita con un semplice processo in due passaggi. Si presume che l'amministratore abbia deciso di intervenire sulla base di un'analisi del tempo necessario per ripristinare l'operatività del server originario. La replica coerente tra i due nodi al momento del guasto e l'urgenza dei client di poter accedere al server sono alcuni fattori da considerare nell'analisi.

• Good availability   Indica che sono andati perduti tre registri. Good availability   Fornisce il ripristino completo e automatico in caso di replica normale in cui i registri vengono replicati alla velocità con cui vengono generati.

• Best availability   Indica la perdita di sei registri, l'impostazione predefinita. Best availability   Funziona in modo analogo a Good availability, ma consente il ripristino automatico in caso di lieve latenza della replica. Pertanto dopo il failover il nuovo nodo attivo potrebbe trovarsi in uno stato leggermente precedente al vecchio nodo attivo aumentando così la probabilità di divergenze nei database, per la cui correzione è richiesto un reseeding completo.

Per ulteriori informazioni sulla gestione delle interruzioni, vedere Come regolare il failover e le impostazioni di installazione per la replica continua cluster.