Comunicazioni

Protezione dei dati e ripristino di emergenza per Exchange Server 2007

Lee Benjamin

Panoramica:

• Backup e ripristino di base
• Continuità dei dati
• Tecnologie di replica
• Soluzioni alternative

Microsoft Exchange Server è stato progettato specificamente per soddisfare le esigenze di backup. Le organizzazioni hanno l'esigenza di eseguire il backup oltre che il ripristino dei relativi dati di messaggistica. Per rispondere a questa esigenza, Microsoft ha creato una gamma completa di opzioni per la protezione dei dati, che spaziano da

funzionalità di backup e ripristino di base a soluzioni di continuità operativa e di continuità aziendale che forniscono i più alti livelli di disponibilità e ripristino di emergenza. In questo articolo verranno esaminate queste opzioni e verranno fornite informazioni utili nella scelta del metodo di implementazione della soluzione di ripristino di Exchange più appropriata alla propria organizzazione.

LIVELLO 1: BACKUP E RIPRISTINO DI BASE

È possibile eseguire il backup dei file di Exchange sia in modalità non in linea che in fase di esecuzione. Il secondo approccio rappresenta, in effetti, il metodo consigliato per l'esecuzione del backup di Exchange. Exchange è tuttavia molto più di un insieme di file. È un archivio di informazioni con file di database e registri delle transazioni di grandi dimensioni. I messaggi inviati a Exchange vengono archiviati immediatamente nei registri delle transazioni e, quando nel sistema sono disponibili alcuni cicli non utilizzati (in genere solo pochi millisecondi dopo), i messaggi vengono copiati nel database. Grazie alla possibilità di copiare le informazioni sul disco il più rapidamente possibile, Exchange un livello molto elevato di recuperabilità. Per il ripristino di Exchange è fondamentale la disponibilità di entrambi i set di dati. In caso di errore del sistema, la combinazione di un backup precedente e di tutte le transazioni eseguite a partire da tale momento consentirà di ripristinare in Exchange le informazioni più recenti. Tenere presente che in Exchange le transazioni vengono automaticamente replicate in un database ripristinato, in base alle esigenze.

I programmi di backup accedono alle informazioni contenute nel database di Exchange tramite l'API di backup ESE (Extensible Storage Engine) o le più recenti soluzioni VSS che verranno illustrate più avanti in questo articolo. Ogni volta che viene avviato un backup ESE, Exchange sospende temporaneamente tutte le operazioni di scrittura nei relativi database. Nello stesso momento in cui ESE imposta temporaneamente il database sulla modalità di sola lettura che ne garantisce la disponibilità per la copia in un backup completo, utilizza anche un database temporaneo in cui memorizzare le nuove transazioni eseguite durante il backup. Quando il backup viene completato, ESE reimposta il database sulla normale modalità di lettura/scrittura e applica le transazioni che sono state accumulate nel database temporaneo. Al termine di un processo di backup eseguito in modo corretto vengono inoltre eliminati i registri delle transazioni obsoleti.

Sebbene il processo di backup sia semplice e avvenga in modo trasparente persino per gli utenti che eseguono l'accesso durante la notte mentre il backup è in corso, il completamento di ESE potrebbe richiedere tempi piuttosto lunghi, in base alle dimensioni dei database di Exchange, che possono variare da pochi gigabyte a dimensioni ancora gestibili comprese tra 30 e 50 GB fino ad arrivare persino a 100 GB, un contesto in cui diventa quasi impossibile eseguire il backup durante la notte quando si utilizzano tecnologie standard. Per avere un'idea delle opzioni disponibili quando si utilizza NTBackup.exe, dare un'occhiata alla Figura 1.

Figura 1** Utilizzo dell'utilità NTBackup **

Procedure consigliate per Exchange

Se si desidera essere in grado di effettuare rapidamente il ripristino in seguito a comuni errori di sistema o hardware, è consigliabile eseguire backup completi di Exchange durante la notte. Per ottimizzare le prestazioni e la recuperabilità ogni volta che un server Exchange utilizza dischi locali, è opportuno utilizzare array RAID separati per memorizzare i database e i registri delle transazioni di Exchange. In tal modo, in caso di errore di un controller dell'array RAID o di guasto di più dischi dell'array che impedisce ai dischi rimanenti di ricostruire i dati con striping, si sarà comunque in grado di eseguire il ripristino. In caso di perdita dei registri delle transazioni, saranno comunque disponibili database di Exchange aggiornati nelle altre unità che consentiranno di continuare le normali operazioni con i nuovi registri delle transazioni. In caso di perdita delle unità del database, la strategia di ripristino consigliata prevede l'accesso al backup completo eseguito la notte precedente per i database di Exchange e successivamente l'applicazione dei registri delle transazioni del giorno corrente per aggiornarlo.

È importante limitare le dimensioni dei database di Exchange in modo che sia possibile eseguirne il backup e, cosa più importante, il ripristino, in un intervallo di tempo accettabile. Per la maggior parte delle organizzazioni, questo implica la necessità di limitare le dimensioni dei database a un intervallo compreso tra 30 e 50 GB. Quando le dimensioni di un database superano questo valore, è consigliabile suddividerlo in più database in modo da rendere più gestibile il processo di ripristino.

Continuum dei processi di backup e ripristino

Il posizionamento dei database e dei registri delle transazioni è molto importante non solo in termini di prestazioni del processo di backup ma anche in termini di velocità del ripristino. Attualmente, tutti i server supportano diversi livelli di ridondanza dell'unità disco, a cui viene fatto riferimento con il termine RAID. In sostanza, la tecnologia RAID impedisce che un eventuale errore dell'unità disco determini l'arresto anomalo del sistema; le prestazioni del sistema subiranno tuttavia un rallentamento fino a quando il disco non viene sostituito o ricreato. Fino a tale momento, il controller dell'array deve ricostruire i dati presenti nei dischi rimanenti in tempo reale in risposta alla richiesta di accesso a ciascun disco. Per ulteriori informazioni sulla modalità di archiviazione del server delle cassette postali, vedere l'articolo di Microsoft IT Showcase "Passaggio alla piattaforma a 64 bit con Exchange Server 2007".

Una delle funzionalità di base di Exchange è la progettazione di database a istanza singola. questo implica che all'interno di un database di Exchange viene archiviata un'unica copia di uno specifico messaggio, insieme a un singolo allegato (se disponibile). Se il messaggio è stato inviato a più destinatari nello stesso archivio di informazioni, verranno creati puntatori aggiuntivi agli oggetti (messaggio, allegato), ma gli oggetti non verranno duplicati. Questo rappresenta un enorme vantaggio non solo in termini di efficienza del recapito dei messaggi, ma anche in termini di risparmio di spazio, sia su disco che su nastro.

Sebbene Exchange consenta un ripristino efficace dell'intero database, il ripristino di singole cassette postali, cartelle o messaggi richiede prima di tutto il ripristino dell'intero nastro. Non sorprende che gli utenti desiderassero funzionalità di ripristino più granulari. Tuttavia, la disponibilità di una singola istanza sul nastro preclude questa possibilità. I fornitori di soluzioni di backup hanno risposto a questa esigenza con il cosiddetto "backup brick-level", ovvero il backup specifico delle singole cassette postali, che io tuttavia non consiglio di utilizzare. Dopo aver completato un backup completo del database di Exchange utilizzando l'API di backup ESE approvata, i prodotti di backup aggiungono ciascuna cassetta postale al nastro di backup. Poiché l'API di backup non fornisce un metodo per estrarre i dati dalle singole cassette postali, viene utilizzato MAPI. La durata del nastro di backup diventa, di conseguenza, notevolmente maggiore in quanto vengono duplicati tutti i messaggi e gli allegati.

Microsoft ha introdotto alcuni miglioramenti che risolvono parzialmente questo problema. Ad esempio, il cestino amministrativo (o dumpster) conserva gli elementi per un determinato periodo di tempo dopo che sono stati eliminati dagli utenti in modo da consentirne il riutilizzo nel caso in cui siano necessari. Inoltre, non è più necessario conservare un server di riserva come foresta di ripristino di Exchange; i gruppi di archiviazione di ripristino consentono a un amministratore di montare parzialmente i database ripristinati dal nastro e di copiare o unire i dati a livello delle cassette postali.

Dalla pratica nasce la perfezione

La maggior parte delle organizzazioni ha sperimentato che, indipendentemente dal livello di backup e di ripristino su cui è ricaduta la scelta, i supporti di backup e le procedure di ripristino devono essere testati con regolarità. Troppi amministratori apprendono che le relative tecnologie di backup e procedure di ripristino funzionano in modo corretto solo dopo una situazione di emergenza. Il momento più appropriato per eseguire il test è il giorno dopo la creazione e la configurazione del nuovo server, quando è già operativo come parte dell'organizzazione Exchange ma viene utilizzato solo da un numero limitato di utenti. In tale fase è consigliabile eseguire un backup completo di Exchange, effettuare backup periodici delle unità e acquisire lo stato del sistema, che include i file di importanza critica del disco di sistema e la metabase di IIS (in cui viene conservata la configurazione di routing di Exchange). Successivamente, riformattare il nuovo server e ricominciare da capo, aggiornando le note prese quando si è creato il server per la prima volta. A questo punto si dovrebbe essere in grado di ripristinare le impostazioni dello stato del sistema; è inoltre opportuno reimplementare le impostazioni di configurazione del sistema manualmente basandosi sulla documentazione correlata.

Il tempo dedicato a questa esercitazione per la verifica del piano di ripristino di emergenza consentirà di ridurre significativamente i tempi di ripristino in futuro. Ripetere il processo periodicamente. Nel corso di questo processo, annotare il tempo impiegato per recuperare i nastri archiviati fuori sede. Coloro che si sono imbattuti in situazioni che richiedevano la necessità di attendere il completamento di questo intervallo apparentemente interminabile iniziano a pensare più seriamente al ruolo importante che i backup da disco a disco possono svolgere nell'ambito della relativa strategia di backup e ripristino, anche se l'archiviazione di nastri fuori sede continua a fornire la principale "rete di sicurezza" per il ripristino di emergenza.

Problematiche correlate al backup su nastro

Il ripristino di dati da nastro richiede tempi eccessivamente lunghi. Considerato il ruolo critico che Exchange riveste attualmente per le organizzazioni, sia gli utenti che il corpo direttivo dell'azienda si aspettano che questa applicazione sia sempre disponibile. Quando si verifica un problema grave, la maggior parte delle organizzazioni viene colta impreparata. Nessuna organizzazione dispone della preparazione adeguata per gestire i tempi eccessivi lunghi, addirittura otto ore, richiesti dal ripristino da nastro di database di 75 GB; un intervallo che non include neppure il tempo impiegato per ripristinare i nastri dalla struttura di archiviazione fuori sede o per reinstallare il sistema operativo.

Inoltre, occorre considerare le difficoltà insite nel ripristino da nastro del database corretto. Nei 10 anni successivi al rilascio della prima versione di Exchange, il costo dell'archiviazione su disco e delle reti WAN si è ridotto in misura considerevole. Di conseguenza, molte organizzazioni sono in grado di sostenere i costi di metodi di backup e ripristino più rapidi. Queste organizzazioni hanno la possibilità di sfruttare i vantaggi di tecnologie che consentono loro di dotare l'infrastruttura Exchange di adeguati piani di continuità operativa e di ripristino di emergenza.

LIVELLO 2: CONTINUITÀ OPERATIVA

La continuità operativa è un insieme di processi e tecnologie volti a garantire il ripristino nel minor tempo possibile, riducendo al minimo i tempi di inattività non previsti. La continuità operativa offre livelli migliorati di RTO (Recovery Time Objective, tempo massimo di ripristino del servizio) e di RPO (Recovery Point Objective, perdita dati tollerata) su nastro per il ripristino locale e mira a eliminare, ove possibile, i tempi richiesti per ripristinare i nastri in sede. Dare un'occhiata alla Figura 2 per un confronto tra continuità operativa, processi di backup e ripristino e piano di ripristino di emergenza.

Figura 2** Continuum del processo di ripristino **(Fare clic sull'immagine per ingrandirla)

In questo diagramma viene illustrato il continuum del processo di ripristino e della disponibilità che va da soluzioni lente ed economiche nella parte inferiore sinistra a soluzioni rapide e costose nella parte superiore destra, con una transizione deliberatamente indistinta tra le soluzioni di continuità operativa e di ripristino di emergenza.

Il grafico dà un'idea dei compromessi tra costi, tempi di ripristino e disponibilità che questi approcci comportano. In questo articolo viene intenzionalmente operata una chiara distinzione tra processi di continuità locali e ripristino di emergenza. Il piano di ripristino di emergenza è sempre considerato remoto, il cui obiettivo principale è il recupero di dati archiviati fuori sede. La distanza introduce problemi aggiuntivi e comporta un maggiore dispendio in termini di denaro, ma il piano di ripristino di emergenza mira ad assicurare principalmente la continuità aziendale dopo eventi catastrofici. questo argomento verrà trattato in maggior dettaglio più avanti in questo articolo.

Un po' di storia

Man mano che Exchange ha cominciato a svolgere un ruolo sempre più strategico nell'ambito dell'infrastruttura e considerata l'attuale tendenza ad archiviare nei database di Exchange una quantità sempre più elevata di informazioni, è emersa chiara la necessità di ridurre i tempi di backup e ripristino. In collaborazione con Microsoft, alcune organizzazioni di grandi dimensioni hanno elaborato un approccio che garantiva un miglioramento dei tempi di ripristino di uno stato di parziale operatività. Se un'organizzazione era in grado ricevere e inviare nuovi messaggi di posta elettronica al mondo esterno, nessuno avrebbe immaginato che si fossero verificati dei problemi. Dopotutto l'apparenza oggi ha un ruolo notevole nella società.

Per implementare questo ripristino temporaneo per Exchange, è stato utilizzato un nuovo database vuoto in sostituzione del database danneggiato. In Exchange e Active Directory® sono state quindi create nuove cassette postali con autorizzazioni appropriate e gli utenti erano in grado di ricevere e inviare messaggi. Una volta recuperato il nastro di backup e ripristinati i dati, poteva essere montato dagli utenti con privilegi di amministratore. L'amministratore di Exchange avrebbe quindi unito le cassette postali ripristinate nelle cassette postali temporanee. Era possibile assegnare alle cassette postali livelli di priorità, in base alle esigenze. Sebbene si trattasse di un miglioramento, questo era un processo piuttosto complesso e dispendioso in termini di tempo che originariamente prevedeva l'utilizzo di EXMERGE e successivamente è stato adattato ai gruppi di archiviazione di ripristino. Tenere presente tuttavia che il ripristino completo dei dati dopo uno scenario di ripristino temporaneo può rivelarsi un'attività difficile e complessa, in particolare in situazioni in cui è possibile utilizzare fino a 50 gruppi di archiviazione, come in Exchange 2007). Se si prende in considerazione l'implementazione di uno scenario di ripristino temporaneo, accertarsi che i vantaggi ottenuti superino gli sforzi richiesti.

Servizio Copia Shadow del volume

Per sfruttare i vantaggi dei dischi più economici e per rimuovere l'overhead sul processore generato dai server di produzione di Exchange, è stata sviluppata una nuova API di backup per Microsoft® Windows Server® 2003 ed Exchange. Il servizio Copia Shadow del Volume (VSS) è stato creato per consentire l'esecuzione di copie temporizzate coerenti dei dati. Questi snapshot sono copie rapide di sola lettura dei dati di Exchange che includono in successione solo i dati che sono stati modificati. Le copie in genere fanno riferimento a un altro server con spazio su disco disponibile o a una rete SAN (Storage Area Network). È possibile conservare più snapshot con backup eseguiti su nastro. Di conseguenza, il server Exchange di produzione non dovrà più soffrire l'impatto in termini di prestazioni dell'overhead generato dal software di backup e dalla copia su nastro.

L'utilizzo del servizio Copia Shadow del volume per la protezione dei dati di Exchange comporta diversi vantaggi. Primo, è possibile rimuovere dal server Exchange il carico sulle prestazioni delle operazioni di backup su nastro. Sebbene il backup su nastro continui a essere necessario, è possibile utilizzare la copia dei dati di Exchange senza alcun impatto sulle prestazioni degli utenti. Secondo, è possibile creare più di uno snapshot per notte, con il vantaggio aggiuntivo di poter conservare più snapshot sul server secondario o altri dispositivi di archiviazione locali.

Sul mercato sono disponibili numerosi prodotti di terze parti che sfruttano i vantaggi offerti dalle funzionalità snapshot VSS. Alcuni riducono semplicemente il tempo necessario per il backup e il ripristino dei database di Exchange, mentre altri aggiungono ulteriori funzionalità, ad esempio un ripristino più granulare rispetto a quello offerto dalla modalità Exchange nativa in modo da consentire il ripristino a livello delle cassette postali. Sebbene i backup "brick level" non rappresentino la soluzione preferita dagli utenti, questi hanno comunque l'esigenza di ripristinare specifiche cartelle o singoli messaggi.

Tecnologie di replica

Il failover di Exchange mediato da software è un'opzione fornita da alcuni fornitori di tecnologie di replica. Questa opzione consente l'attivazione di un server Exchange standby e indica ad Active Directory che tutte le cassette postali degli utenti sono state spostate. Questa operazione può essere eseguita in due modi, che richiedono entrambi alcune personalizzazioni degli ambienti Exchange e Windows. Uno dei due metodi prevede l'adozione di alcuni accorgimenti con il server DNS in modo che il server standby assuma il nome e l'indirizzo IP del server in cui si è verificato l'errore. Il vantaggio di questo approccio risiede nella sua semplicità di utilizzo sulle workstation client in quanto Outlook® pensa che sta ancora utilizzando lo stesso server.

Il secondo approccio prevede l'utilizzo di un server di standby che esegue Exchange, in cui vengono archiviate le copie del database ma non viene montato nulla. In caso di errore, il server di standby informa Active Directory che tutte le cassette postali degli utenti sono state spostate. Successivamente, viene eseguito uno script o viene distribuito un criterio di gruppo, che informa i client che le cassette postali risiedono su un server di posta differente. Outlook 2007 fornisce il supporto per Active Directory, il che semplifica il processo in quanto è in grado di stabilire questi mapping automaticamente.

Clustering locale con MSCS

A un livello più alto nel continuum della disponibilità si trova Microsoft Cluster Services (MSCS); Exchange è un'applicazione abilitata per i cluster. Il clustering prevede la condivisione di informazioni tra due o più computer in modo che, in caso di errore su uno di essi, gli altri possono assumere il controllo. Attualmente, la maggior parte dei cluster Exchange è rappresentata da due o quattro nodi, anche se è possibile utilizzare fino a otto nodi. Un nodo è sempre designato come passivo, operativo quando Windows Server è in esecuzione ed Exchange Server è installato, ma non contiene cassette postali attive. L'utilizzo di un cluster attivo/attivo a due nodi era possibile in Exchange 2003, ma a causa dei carichi sulle prestazioni, ora è sconsigliato e non verrà supportato in Exchange 2007.

Analogamente alla disposizione dei cluster in Exchange 2003, i cluster di Exchange 2007 che includono un nodo passivo possono ancora utilizzare un singolo vettore di archiviazione (storage array). Sebbene i vettori di archiviazione di tipo cluster dispongano in genere di una serie di funzionalità di ridondanza per gestire diversi tipi di errore, forniscono tuttavia una sola copia di dati, il che lascia aperta una finestra di vulnerabilità. Per questo motivo, questi cluster vengono chiamati cluster a copia singola (SCC) per distinguerli dalla successiva frontiera nell'ambito della protezione dei dati rappresentata dai cluster a copia multipla (MCC) in Exchange 2007. I cluster a copia multipla verranno illustrati in maggiore dettaglio nella sezione relativa al ripristino di emergenza.

Replica continua locale

La replica continua locale (LCR) è una nuova funzionalità di Exchange 2007 che garantisce una gestione più efficace di una seconda copia dei database e dei registri delle transazioni di Exchange all'interno dello stesso server. Questo aggiunge un livello di ridondanza alla procedura consigliata che prevede l'installazione del database e dei registri delle transazioni di Exchange su array RAID separati: LCR consente di archiviare una copia secondaria dei registri sull'array in cui è archiviata la copia principale del database e di archiviare una copia secondaria del database sull'array in cui è archiviata la copia principale dei registri (vedere la Figura 3). In caso di errore dell'array o del controller RAID, sarà possibile utilizzare il database e i registri delle transazioni archiviati nell'altro array. In questo modo, sarà possibile continuare a svolgere le attività aziendali, anche se non senza un certo nervosismo e con prestazioni ridotte, fino a quando non si sarà in grado di ricreare l'array in cui si è verificato l'errore.

Figura 3** Configurazione di LCR **

Poiché LCR è una soluzione per la continuità operativa locale, non una soluzione di backup, è comunque necessario utilizzare una strategia di backup completo. L'utilizzo di LCR inoltre incide sulle prestazioni in quanto il server in uso ora dovrà eseguire due copie del database e dei registri delle transazioni. Inoltre, l'implementazione di Exchange 2007 prevede alcune limitazioni che rendono l'utilizzo di LCR adatto solo alle organizzazioni di piccole dimensioni in quanto LCR supporta un solo database in un gruppo di archiviazione e un solo database di cartelle pubbliche all'interno di un'organizzazione.

Il failover mediante un ripristino basato su LCR non è istantaneo: un professionista IT esperto dovrà eseguire alcuni script per il backup di Exchange. Il processo richiede l'esecuzione dei comandi di Exchange Management Shell all'esterno di Exchange Management Console.

Mentre Exchange Server 2003 Enterprise Edition consentiva a un'organizzazione di eseguire fino a 20 database Exchange (quattro gruppi di archiviazione ciascuno dei quali contenente un massimo di cinque database), Exchange 2007 Enterprise Edition consente di eseguire fino a 50 gruppi di archiviazione, ciascuno con il proprio database. Anche i registri delle transazioni sono stati ridotti da file di 5 MB in Exchange 2003 a file di 1 MB in Exchange 2007. Entrambe queste modifiche sono state introdotte allo scopo di fornire il supporto per LCR, nonché per la replica continua cluster (CCR), che verrà discussa tra breve.

Le organizzazioni di piccole e medie dimensioni utilizzeranno LCR per garantire una maggiore protezione dei dati nell'ambito delle relative operazioni Exchange. LCR è facile da implementare ma richiede l'intervento manuale. In quanto soluzione per l'archiviazione su disco locale all'interno dello stesso server, LCR rappresenta solo il primo passo verso il miglioramento della continuità operativa. Anche se garantisce la protezione da errori di un array RAID o di controller RAID, più guasti simultanei del disco o errori dei controller RAID sono relativamente rari. Nella maggior parte dei casi, gli scenari di errore implicano il collasso dell'intero server, il che introduce la fase successiva nell'ambito della protezione di Exchange.

Replica off-host locale di terze parti

Per migliorare le funzionalità di ripristino di Exchange, alcuni fornitori di terze parti hanno sviluppato prodotti che sfruttano i vantaggi della replica "off-host" utilizzando i file di registro di Exchange per conservare una copia di standby del database di Exchange su un altro computer. In questo caso, la soluzione di archiviazione e protezione dei dati esegue un backup completo ESE di Exchange in un computer differente ed effettua il pull dei registri delle transazioni non appena vengono chiusi da Exchange. Inserisce le transazioni nella copia del database di Exchange in modo che sia sempre aggiornato. Come osservato in precedenza, questi registri sono relativamente piccoli (5 MB in Exchange 2003 e 1 MB in Exchange 2007) e pertanto, una volta completato il backup completo, la copia dei file di registro sul server off-host non genera in pratica alcun overhead sul server Exchange.

LIVELLO 3: RIPRISTINO DI EMERGENZA ED ELEVATA DISPONIBILITÀ

Il ripristino di emergenza è la capacità di ristabilire uno stato di completa operatività in caso di mancata disponibilità del principale centro dati. Exchange merita una soluzione di ripristino di emergenza efficace in quanto le funzioni di calendario e di posta elettronica rivestono attualmente un'importanza cruciale per la maggior parte delle organizzazioni.

Alcune aziende ritengono che i tradizionali backup su nastro archiviati fuori sede siano una forma di piano di ripristino di emergenza, senza pensare alla conseguenze insite in un'eventuale distruzione, dovuta ad esempio a un incendio o un'inondazione, dell'unico centro dati disponibile: un cumulo di bobine di nastro sarebbe senza dubbio di scarsa utilità per l'organizzazione. Il ripristino di emergenza determina necessariamente lo spostamento non solo dei dati in una posizione alternativa, ma anche della tecnologia e dei processi in grado di riportare l'applicazione in uso a uno stato di completa operatività. Per essere efficace, il piano ripristino di emergenza deve prevedere la separazione tra i sistemi primari e secondari. La distanza di separazione tra le sedi dipende dall'entità dell'emergenza a cui si deve far fronte. Se la preoccupazione principale riguarda lo scoppio di un incendio, probabilmente un altro edificio nel campus aziendale garantisce una distanza di sicurezza sufficiente a evitare qualsiasi pericolo per i dati aziendali. Tuttavia, le emergenze a livello di infrastruttura che coinvolgono treni o aerei potrebbero interessare un raggio di circa due chilometri o più. Molti disastri avvengono a livello locale: inondazioni, tempeste di neve, terremoti e persino interruzioni di alimentazione. Esistono calamità che hanno un impatto diretto sui sistemi di comunicazione, che possono spaziare da un retroescavatore che può interrompere il collegamento al proprio ISP ad attacchi Denial of Service e attacchi DoS su Internet che prendono di mira il commercio in generale.

Ai fini pratici, se la propria organizzazione dispone già di più sedi con personale IT, è possibile che una di queste sedi sia in grado di soddisfare i criteri stabiliti per la continuità operativa remota, in base ai tipi di situazioni di emergenza a cui far fronte. Utilizzare una propria struttura e il proprio personale sarà senza dubbio meno costoso che accordarsi con un fornitore di terze parti per la fornitura di soluzioni di ripristino di emergenza o prendere in affitto un nuovo locale.

Infine, il ripristino di emergenza è strettamente correlato anche alla percezione dell'azienda da parte del proprio pubblico: non dare ai clienti l'impressione che l'organizzazione abbia cessato l'attività. Quando un'emergenza colpisce una città o un'area specifica, se la propria azienda non ritorna operativa nel più breve tempo possibile, vi è la possibilità che clienti e fornitori pensino al peggio; molte aziende falliscono proprio per questo motivo. L'azienda deve dare ai clienti l'impressione che si sta attivando per ristabilire tempestivamente la propria operatività in modo da rassicurarli da possibili dubbi circa la continuità aziendale. I clienti avranno opinioni diverse per quanto riguarda il concetto di ripristino tempestivo: sono comprensibilmente meno pazienti con le interruzioni di servizio che avvengono presso le relative aziende di servizi finanziari rispetto ad esempio alle interruzioni che si verificano presso i relativi fornitori di arredi per ufficio.

Requisiti del ripristino di emergenza

La capacità di riportare in linea Exchange dopo una situazione di emergenza richiede la replica dei relativi dati nella sede secondaria e l'utilizzo di una tecnologia di replica che sia in grado di presentare i dati a un server Exchange che supporti tale tecnologia, quindi l'invio di una notifica ai client Outlook in cui vengono informati che le relative cassette postali sono state spostate.

La replica di Exchange richiede un utilizzo intensivo di risorse, in particolare su lunghe distanze. Data la natura transazionale del database Exchange, l'ordine di ciascuna operazione di scrittura riveste un'importanza fondamentale. A complicare ulteriormente la situazione è il fatto che il protocollo di trasporto utilizzato da Exchange per comunicare tutte le transazioni e le informazioni del sistema tra i server è SMTP, noto come protocollo che richiede un impiego intensivo di larghezza di banda. Inoltre, con i cluster Exchange è necessario mantenere un heartbeat tra i sistemi ogni 500 millisecondi. Se un nodo secondario non riceve l'heartbeat, potrebbe attivare l'avvio di un failover.

Le complessità insite nella gestione di tali problematiche potrebbero rappresentare la ragione per cui Microsoft si stia addentrando solo ora in questa area con Exchange 2007. In assenza di un prodotto Microsoft specifico, sono state sviluppate diverse soluzioni di terze parti che consentono di replicare i dati di Exchange mediante l'uso della replica basata su host o su array.

I fornitori hanno compreso che potevano estendere un cluster distribuendo i nodi in posizioni diverse, una tecnica definita cluster esteso. Oggi, il metodo più comune di implementazione dei cluster estesi è rappresentato dall'utilizzo di prodotti di replica dei dati di terze parti generici o di prodotti specificamente progettati per l'estensione di un nodo di Exchange. È possibile eseguire questa operazione con MSCS; tuttavia la necessità di utilizzo di subnet costituisce un requisito impegnativo su una rete WAN. Il clustering e le complessità correlate alla necessità di fornire una connettività a larghezza di banda elevata e affidabile ai centri dati remoti determinano comprensibilmente un incremento dei costi e della disponibilità di personale dedicato per creare, gestire e testare periodicamente i sistemi di ripristino di emergenza.

Replica continua cluster

Microsoft estende il suo supporto per i cluster con il meccanismo di replica continua cluster incluso in Exchange 2007. CCR estende la capacità della replica continua locale di gestire due copie dei registri delle transazioni e di un database di Exchange per implementare la stessa idea su due nodi cluster. Il ripristino di emergenza implica la separazione geografica di sistemi primari e secondari e i cluster a copia multipla (MCC) di Microsoft non saranno in grado di coprire distanze significative fino a quando Windows Server 2008, nome in codice precedente "Longhorn," non fornirà il supporto per i cluster estesi.

La tecnologia che consente a nodi MCC di disporre di copie separate di dati è definita maggioranza dei nodi (MNS, Majority Node Set), che indica il processo di elezione che due o più nodi eseguono per determinare quale nodo dispone della copia attiva dei dati. In caso di errore, i nodi rimanenti eseguono un nuovo processo di elezione per determinare quale nodo assumerà il controllo come nuovo server di elaborazione/dati primario. Il supporto di questa "democrazia tecnica" viene fornito da CCR, che assicura che ciascun nodo disponga di un database aggiornato. I cluster di Exchange 2007 che utilizzano CCR sono limitati a solo due nodi.

In ambienti di grandi dimensioni, i server Exchange in genere configurano il disco di sistema locale sul server stesso e si connettono al database di Exchange tramite una rete SAN utilizzando array di dischi SCSI, in fibra ottica o iSCSI. Con un cluster MCC/MNS, una domanda interessante riguarda la possibilità o meno che i gruppi di archiviazione di Exchange di fascia alta utilizzino di nuovo, come in passato, array RAID locali per ciascun nodo. Se lo scopo di un cluster MNS è consentire la disponibilità in ogni nodo di una archiviazione separata, ha senso continuare a configurare ciascun nodo in modo che faccia riferimento a una rete SAN il cui scopo principale consiste nel fornire un sistema di archiviazione comune?

Un probabile scenario di cluster MCC/MNS moderato prevede un nodo primario con archiviazione sulla rete SAN e un nodo cluster secondario con dischi locali o una rete SAN iSCSI a basso costo. Questo nodo secondario potrebbe trovarsi in una posizione remota rispetto al centro dati primario, in una sede che non dispone di un'infrastruttura SAN.

Indipendentemente dall'evoluzione di questa situazione, la configurazione MCC che prevede l'utilizzo di MNS e la tecnica CCR rappresentano un altro passo al livello superiore della gerarchia che conduce verso la ridondanza e la disponibilità migliorata in quanto più computer sono in grado di eseguire il failover e i dati vengono replicati in elementi di archiviazione separati. I dati sono ancora interamente confinati in un unico centro dati, almeno fino a quando non viene rilasciato Windows Server 2008. Windows Server 2008 fornirà il supporto nativo per i cluster estesi, consentendo la separazione geografica dei nodi in un cluster MNS, purché la latenza di rete tra i nodi sia inferiore a 500 ms. Fino ad allora (e oltre), la tecnologia cluster di terze parti può basarsi su Microsoft MNS e CCR per fornire la separazione geografica necessaria perché la tecnica del cluster esteso rappresenti una soluzione di ripristino di emergenza efficace.

Il clustering è collocato all'estremo più alto del continuum del ripristino di emergenza e la tecnica CCR è correttamente posizionata a un livello del continuum che la indica come soluzione di disponibilità elevata di Exchange. Anche se la combinazione di queste tecnologie può generare un certo overhead in termini di costi e di personale, è possibile prevedere che si rivelerà una soluzione di fascia alta davvero interessante per i clienti che desiderano utilizzare un ambiente Microsoft omogeneo.

Continuità operativa remota di terze parti

Non vi sono dubbi riguardo al fatto che la soluzione Microsoft e le estensioni di terze parti occuperanno l'estremo più alto del continuum del processo ripristino quando verranno rese disponibili. Il vantaggio principale di questa soluzione risiede nella capacità di failover automatico nel giro di pochi secondi. Tuttavia, non tutte le organizzazioni desiderano questo livello di disponibilità e continuità aziendale né possono permettersi di investire le centinaia di migliaia di dollari necessari per garantire tale continuità. Per molte aziende, una soluzione affidabile che garantisca il ripristino completo di Exchange in pochi minuti risponde perfettamente ai relativi requisiti di continuità operativa.

Ad esempio, Mimosa Systems, Inc. estende la continuità operativa all'interno di un singolo centro dati alla continuità remota. In una posizione remota, il piano di ripristino di emergenza di Mimosa consente di mantenere una copia di Exchange, di garantirne il costante aggiornamento in base ai registri delle transazioni forniti dal server Exchange primario e di rendere sempre disponibile questa copia attiva al server Exchange di standby. Il server Exchange remoto utilizza l'hardware standard e, analogamente all'implementazione di un singolo centro dati, è necessario tenerlo sempre attivo e sempre pronto per essere attivato in caso di emergenza. In caso di emergenza, un operatore nella sede remota avvia ed esegue il failover installando i file di database di standby, modificando il mapping per le cassette postali e i profili di Outlook. Tenere presente tuttavia che queste soluzioni di terze parti sono soggette alle limitazioni di supporto descritte nell'articolo della Knowledge Base "Politica di supporto Microsoft per i prodotti di terze parti che modificano o estraggono i contenuti del database di Exchange".

Conclusione

La protezione dei dati di Exchange è disponibile come un continuum di tecnologie e procedure che possono essere raggruppate in tre livelli in base al costo e alle funzionalità. Quando si esaminano i requisiti di tali tecnologie per la protezione dei dati di Exchange, è opportuno prendere in considerazione i tempi di inattività che i propri azionisti sono in grado di tollerare. Prestazioni migliori e tempi di ripristino più rapidi comportano costi maggiori, con le opzioni di fascia alta nell'ordine di cifre a cinque zeri. Sono disponibili soluzioni più convenienti che si avvicinano ma non raggiungono i più elevati livelli di disponibilità. Le scelte effettuate devono riflettere le esigenze reali della propria organizzazione.

Service Pack 1 per Exchange 2007

Attualmente in fase di beta testing, Service Pack 1 (SP1) per Exchange 2007 includerà numerose funzionalità non disponibili finora agli amministratori, tra cui miglioramenti a OWA, funzionalità GUI aggiuntive nella console e molto altro.

Di particolare interesse per gli amministratori che prevedono di utilizzare soluzioni di ripristino, Exchange 2007 SP1 include inoltre una terza soluzione di disponibilità a integrazione di LCR e CCR: replica continua secondaria (SCR). Si tratta di un "approccio di compromesso" e Microsoft mira a creare un'"configurazione ideale" in grado di offrire livelli più elevati di ripristino, senza la complessità insita nella " elevata disponibilità."

SCR consentirà la replica dei registri delle transazioni e del database di Exchange in un server Exchange differente rispetto a quello su cui risiedono in genere le cassette postali. La destinazione di SCR può essere locale o remota e può essere un cluster o un server Exchange di standby. Tuttavia, SCR non richiede un cluster in nessuna delle due posizioni e si differenzia da CCR in quanto la destinazione è un ambiente standby e il failover è un processo manuale. Tenere presente che è comunque necessario eseguire la prima copia di grandi dimensioni in rete, in sostanza un backup completo. Potrebbe essere necessario eseguire di tanto in tanto questa replica estesa tenendo tuttavia presenti le implicazioni sulla rete in uso, proprio come con CCR e le soluzioni di terze parti. Prevedo di assistere a un massiccio utilizzo sia di SCR che di CCR nonché di prodotti aggiuntivi che forniscono funzionalità simili e talvolta di maggiore valore.

Lee Benjamin gestisce ExchangeGuy Consulting Services in cui lavora direttamente con i clienti e fornisce servizi di consulenza ai partner Microsoft. Lee è presidente del più grosso gruppo di utenti Exchange al mondo, ExchangeServerBoston, e direttore del gruppo BostonUserGroups. Occupa inoltre il ruolo di MVP per Exchange, è Microsoft Certified Trainer e partecipa regolarmente come oratore a conferenze di settore.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.