Exchange Server 2010
Garantendo la disponibilità elevata in Microsoft Exchange Server 2010
William r. Stanek
- Caratteristiche di elevata disponibilità in Exchange Server 2010
- Dettagli in gruppi di disponibilità del database
M ailbox database e i dati in che essi contenuti sono fondamentali per qualsiasi organizzazione di Exchange. Per garantire un'elevata disponibilità per i database delle cassette postali, Exchange 2007 fornito un'ampia gamma di replica e clustering opzioni, tra cui la replica continua locale, cluster a copia singola e i server cassette postali cluster. Sebbene queste funzionalità rappresentata miglioramenti attraverso le offerte precedenti, sono comunque poste molte sfide di implementazione. Ogni approccio a elevata disponibilità per i principianti, è stato gestito in modo diverso. Con cluster a copia singola, tutti i server di cassette postali in un cluster utilizzato archiviazione condivisa. Implementazione del clustering significava che gli amministratori di Exchange era necessario configurare il clustering di failover di Windows, che è piuttosto complesso e può richiedere una notevole quantità di tempo di un amministratore per ottenere un elevato livello di tempi di attività. Con replica continua, Exchange 2007 utilizzato replica asincrona incorporate per creare copie dei dati e quindi mantenuta copie mediante transazione accedere riesecuzione e di spedizione. Sebbene la replica continua locale consente di creare copie locali in un ambiente non cluster, si utilizza la replica continua cluster o replica continua di standby in un ambiente cluster e ogni tipo di replica continua è stato gestito in modo diverso.
Exchange Server 2010 ha un approccio radicalmente diverso per un'elevata disponibilità in quanto un'elevata disponibilità è integrata in sua architettura di base, creazione di una soluzione end-to-end che fornisce disponibilità del servizio, la disponibilità dei dati e il recupero automatico. Il risultato è tale, una chiave, soluzione a disponibilità elevata sostituisce molti, diverse soluzioni utilizzate in precedenza. Questa soluzione è il gruppo di disponibilità del database (DAG).
DAGs forniscono il failover automatico e il ripristino a livello di database (piuttosto il livello di server) senza richiedere cluster quando si distribuiscono più server di cassette postali con più copie dei database delle cassette postali. A causa di queste modifiche, creazione di una soluzione di elevata disponibilità Mailbox server non è più richiede componenti hardware del cluster o la configurazione cluster avanzate. Invece, DAGs forniscono il componente di base per un'elevata disponibilità e failover è automatica per i database delle cassette postali che fanno parte della stesso DAG. DAGs può essere esteso a più siti Active Directory e modifiche correlate all'architettura per i server cassette postali di attivare un database di una singola cassetta postale per spostarsi tra i siti di Active Directory. Di conseguenza, un database delle cassette postali singolo in un sito di Active Directory può eseguire il failover a un altro sito di Active Directory.
È necessario ricordare che la copia del database è per solo database delle cassette postali. Per garantire la ridondanza e un'elevata disponibilità dei database di cartelle pubbliche, si utilizzerà la replica delle cartelle pubbliche. A differenza con replica continua cluster, in cui più copie di una cartella pubblica database non può esistere all'interno dello stesso cluster, è possibile replicare i database delle cartelle pubbliche tra server in un DAG.
Prima approfondire i dettagli di DAGs, osservare let’s altri modi per Exchange 2010 sono state modificate le opzioni di disponibilità elevata.
Esercitazione rapida di High Availability Features in Exchange Server 2010
Nelle versioni precedenti, Exchange opera come un'applicazione cluster utilizzato il modello di gestione delle risorse del cluster. In questo approccio, implementata un'elevata disponibilità per i server cassette postali prima creazione di un cluster di failover di Windows ed eseguendo quindi il programma di installazione di Exchange in modalità cluster. Come parte del processo di installazione, la DLL (exres.dll) delle risorse cluster di Exchange è stata registrata, consentendo la creazione di un server cassette postali in cluster. Al contrario, Exchange 2010 non funzionano come un'applicazione cluster e il modello di gestione delle risorse del cluster non è più utilizzato per un'elevata disponibilità. La DLL di risorse cluster di Exchange e tutte le risorse del cluster che non è più fornito esisteranno. Exchange 2010 utilizza invece un proprio modello di elevata disponibilità interno. Sebbene alcuni componenti di Windows clustering di failover vengono ancora utilizzati in questo modello, vengono ora gestiti in modo esclusivo da Exchange 2010.
L'aspetto interessante è che sufficientemente, molte delle tecnologie di replica sottostante rimangono, ovvero sono state semplicemente si sono evoluti e funziona in modi diversi in modo significativo. Poiché i gruppi di archiviazione sono state rimosse da Exchange 2010, viene eseguita la replica continua a livello di database. Invece di utilizzare Server Message Block (SMB) per registrare la spedizione e seeding utilizzi Exchange 2010 una singola definito dall'amministratore porta TCP per il trasferimento dei dati. Anziché estrarre un file di registro chiuso dalla copia attiva copie passive, copia attiva inserisce i file di registro a copie passive e il flusso di dati è protetto mediante crittografia o compressi per ridurre le dimensioni dei dati replicati. Sebbene copia attiva del database nelle versioni precedenti di Exchange potrebbe essere utilizzata solo per seeding e reseeding, in Exchange Server 2010 attivi e passivi copie dei database delle cassette postali possono essere specificati come origini per seeding e reseeding, consentendo che più facilmente aggiungere una copia di un database a un altro server di cassette postali.
Un altro cambiamento significativo ha a che fare con la modalità di replica dei dati. In Exchange 2007, la replica di Microsoft Exchange servizio rieseguiti registri nella copia del database passivo e creata una cache di operazioni di lettura/scrittura che è stato utilizzato per ridurre leggere le operazioni di I/O. Quando la copia passiva del database è stata attivata, la cache del database è andato persa, tuttavia, poiché il servizio Archivio informazioni di Microsoft Exchange montata il database non disponga di questa cache disponibile. Ciò significava che la copia passiva è stata attivata e resi disponibile in uno stato senza una cache pronto a freddo. Uno stato a freddo è lo stesso stato che sarebbe stata la cache del database nella seguente un riavvio del server o un riavvio dei servizi in esecuzione la memorizzazione nella cache. Essere in uno stato a freddo significava che il server non dispone di operazioni di lettura/scrittura nella cache, una condizione che in genere aumentato il numero di operazioni di lettura I/O necessari fino a quando la dimensione della cache sufficientemente aumentata per ridurre di I/O del disco sul server. In Exchange 2010, il servizio Archivio informazioni di Microsoft Exchange vengono riprodotti i registri e gestisce le operazioni di montaggio, garantendo che la cache è disponibile quando viene attivata e reso disponibile una copia passiva. Di conseguenza, il server è più probabile che per poter utilizzare la cache per ridurre le operazioni di lettura I/O dopo un passaggio o il failover.
Con i server di cassette postali ad elevata disponibilità, i messaggi di posta elettronica sono sicuri una volta che arrivano in una cassetta postale, la protezione dei messaggi di posta elettronica in transito è tuttavia un'altra questione. Se un server Trasporto Hub si verifica un errore durante l'elaborazione dei messaggi e non può essere recuperato, potrebbero provocare la perdita dei messaggi. Come misura precauzionale contro la perdita di dati, in Exchange 2007 ha introdotto il trasporto contenitore funzionalità, si è verificata server Trasporto Hub gestita una coda di messaggi recapitati recentemente a destinatari cui cassette postali sono state protette mediante la replica continua locale o replica continua cluster. I messaggi sono stati conservati nel trasporto contenitore fino a quando non è stato raggiunto un limite di tempo definito dall'amministratore o un limite di dimensione. In caso di failover, un server cassette postali in cluster richiesto automaticamente tutti i server Trasporto Hub nel sito Active Directory per inviare di nuovo posta dal trasporto contenitore coda. Questo approccio non consentito posta vengano persi durante il tempo necessario per il failover del cluster. Sebbene questo approccio funziona, è disponibile solo per il recapito dei messaggi in un ambiente di replica continua e non indirizzo potenziale perdita di messaggi quando i messaggi sono in transito tra i server Trasporto Hub e Trasporto Edge.
Exchange 2010 consente di risolvere questi difetti in diversi modi. Il trasporto contenitore ora riceve commenti, per determinare quali messaggi sono stati consegnati e replicati. Server Trasporto hub conservare una copia dei messaggi inviati a un database delle cassette postali replicate in un DAG. La copia viene conservata nella coda di trasporto (mail.que) fino a quando il server Trasporto Hub ha notificato che i registri delle transazioni che rappresenta il messaggio sono stati replicati e ispezionati da tutte le copie del database delle cassette postali correttamente. Quindi vengono eliminati i registri dal trasporto contenitore, garantendo che il trasporto contenitore coda viene utilizzato solo per mantenere copie dei messaggi in cui i registri delle transazioni non sono state ancora replicati. Inoltre, quando un database delle cassette postali in uno failsover di sito di Active Directory a un altro sito di Active Directory, trasporto contenitore le richieste di redelivery vengono inviate al sito originale e il nuovo sito.
Per garantire la ridondanza per i messaggi durante tutto il tempo che siano in transito, Exchange 2010 consente di aggiungere la funzionalità di ridondanza di ombreggiatura. Ombreggiatura ridondanza viene utilizzato un approccio simile al trasporto contenitore, ad eccezione del fatto l'eliminazione dei messaggi provenienti da database di trasporto viene ritardata fino a quando il server Trasporto verifica che tutti gli hop successivo per tale messaggio abbiano completato il recapito. Se il server trasporto non è in grado di verificarlo hop successivo recapito, il messaggio viene nuovamente inviato per la consegna all'hop successivo. Questo approccio utilizza meno larghezza di banda di rete rispetto alla creazione di copie duplicate dei messaggi su più server. In questo caso, il traffico di rete aggiuntive solo generato è lo scambio di scartare i messaggi di stato tra i server di trasporto. Scartare i messaggi di stati generati da Gestione ridondanza shadow e indicano quando un messaggio di posta elettronica è pronto per essere eliminata dal database di trasporto.
La ridondanza di ombreggiatura è un'estensione del servizio SMTP (Simple Mail Transfer Protocol) e viene utilizzata, purché entrambi i server in una connessione SMTP supportano la funzionalità. Quando si dispone di percorsi ridondanti messaggio nella topologia di routing, la ridondanza shadow rende qualsiasi server di trasporto disposable, eliminando la dipendenza sullo stato di qualsiasi server hub o Trasporto Edge specifico. In questo caso, se si verifica un errore in un server di trasporto o se si desidera portarlo in modalità non in linea per manutenzione, è possibile eseguire in modo che in qualsiasi momento mediante la rimozione, sostituzione o aggiornamento senza la necessità di svuotare le code o preoccuparsi che i messaggi andranno persi.
Il gestore della ridondanza shadow utilizza un approccio di heartbeat nel determinare la disponibilità dei server per il quale vengono accodati i messaggi di ombreggiatura. Il server che ha iniziato rilascia un messaggio di XQUERYDISCARD e in risposta al server di destinazione restituisce le notifiche di eliminazione. Questo scambio di notifica è l'heartbeat.
Se un server non è in grado di stabilire una connessione a un server primario nell'intervallo di timeout dell'heartbeat, è 300 secondi per impostazione predefinita, il server Reimposta il timer e tenta nuovamente, fino a tre volte (valore predefinito del numero di tentativi di heartbeat). Se un server primario non risponde nel momento in cui che è stato raggiunto il numero di tentativi, il server determina che il server primario non è riuscita, si presuppone che la proprietà dei messaggi di ombreggiatura e li invia di nuovo. I messaggi vengono quindi recapitati alle rispettive destinazioni come appropriato. In alcuni scenari, ad esempio quando il server originale viene fornito in linea con il database originale, può causare il recapito dei messaggi duplicato. A causa delle funzionalità di rilevamento di messaggi duplicati in Exchange, gli utenti delle cassette postali di Exchange non vengono visualizzati i messaggi duplicati. Tuttavia, i destinatari nei server di Exchange Mailbox potrebbero ricevere copie duplicate.
Dettagli in DAGs
Sebbene molti miglioramenti di disponibilità elevata che ho descritto finora sono importanti, Nessuna singola caratteristica molto influisce sulle modalità di che Gestione Exchange 2010 come gruppi di disponibilità del database. DAGs sono il componente di base dell'elevata disponibilità in Exchange 2010. Le regole per DAGs sono semplici. Ogni DAG può avere fino a 16 server cassette postali come membri. Ogni server di cassette postali può essere un membro di DAG e può essere un solo host solo una copia di un database. La copia ospitata può essere una copia attiva o una copia passiva. Una copia attiva differisce da una copia passiva in quanto è in uso e da cui si accede da utenti anziché in modalità non in linea. Non è possibile creare due copie dello stesso database sullo stesso server. In seguito, qualsiasi server in un DAG può host una copia di qualsiasi database delle cassette postali da qualsiasi altro server il DAG. Sebbene più database possono essere attivi contemporaneamente, solo una copia di qualsiasi database particolare può essere attiva in qualsiasi momento e su altri server in un DAG può essere fino a 15 copie passive di questo database.
Quando si crea il primo DAG di un'organizzazione di Exchange, Exchange crea un cluster di failover di Windows, ma esistono Nessun gruppo di cluster per Exchange e Nessuna risorsa di archiviazione del cluster. Il DAG utilizza solo l'heartbeat del cluster, reti di cluster e le caratteristiche di database di cluster dei cluster di failover di Windows. L'heartbeat del cluster viene utilizzato per rilevare errori. Ogni DAG richiede almeno una rete per il traffico di replica e almeno una rete per MAPI e altro traffico. Il database del cluster vengono memorizzate le modifiche dello stato del database e altre informazioni importanti. Come è possibile aggiungere altri server per il DAG, vengono aggiunti i server a cluster sottostante e modello di quorum del cluster viene modificato automaticamente secondo le necessità in base al numero di server membri.
Gestione Active è il componente Exchange 2010 che fornisce funzionalità per la gestione di modello e failover della risorsa. Attiva il gestore viene eseguito su tutti i server di cassette postali che sono membri di un DAG opera come titolare del ruolo principale (gestione di Active primario) o un detentore del ruolo di standby secondario (la gestione Active Standby) di un determinato database. Primario decide viene copiato il database che saranno attivo e che viene copiato da attivare. Il server primario riceve le notifiche di modifica della topologia e reagisce agli errori del server. Il server primario è anche proprietario la risorsa quorum del cluster. Se il server che funge da ruolo primario ha esito negativo, il ruolo primario viene spostata automaticamente in un altro server il DAG e tale server diventa proprietario della risorsa quorum del cluster.
Secondaria rileva errori di database replicati, locali e l'archivio informazioni locale e genera le notifiche di errore per il server primario, che richiede il server primario per avviare un failover. Secondario non determina quale server si subentra né aggiornare lo stato del percorso del database. Il server primario esegue queste attività. Quando si verifica un errore in un database attivo, il gestore di Active utilizza un algoritmo Best Copia selezione per selezionare una copia di database per l'attivazione. Questo algoritmo identifica la copia del database migliore per attivare in base allo stato del database, lo stato di indice di contenuto, la lunghezza della coda di copia e la lunghezza della coda di riesecuzione della copia del database. Se più di una copia di database soddisfa i criteri di selezione, viene utilizzato il valore di preferenza di attivazione e il database con il valore di preferenza più basso è attivato e installato.
Dopo aver aggiunto i server a un DAG, i database attivi su ciascun server possono essere replicati ad altri server in DAG di ed è possibile configurare altre proprietà di DAG, ad esempio la crittografia di rete o la compressione di rete per la replica di database. All'interno di DAG, i registri delle transazioni vengono replicati in ogni server membro che dispone di una copia di un database delle cassette postali e rieseguiti nella copia del database delle cassette postali. Dopo aver creato più copie di database, è possibile utilizzare Exchange Management Console e in Exchange Management Shell per monitorare lo stato di replica e l'integrità di DAGs. Database failover può avvenire automaticamente in caso di interruzione oppure è possibile avviare manualmente commutazione. In un passaggio viene disinstallata copia attiva e una copia passiva su un altro server il DAG viene montata e reso copia attiva.
Semplificazione true
Come ho ho spiegato in questo articolo, Exchange 2010 dispone di numerosi importanti miglioramenti che consentono di migliorare la disponibilità, inclusa l'integrazione delle funzionalità di elevata disponibilità in base, modifiche di architettura che consentono di migliorare la disponibilità e altro ancora. Di tutte le funzionalità nuove e modificate, DAGs sono il mio preferito. DAGs davvero semplificare l'implementazione di cluster e consentono di concentrarsi su ciò che è più importante, ovvero i dati. Spero che si trova in questo articolo utile e verrà cercare mio nuovi libri, “ Exchange Server 2010 Administrator del ' s Pocket Consultant, ” “ Windows 7 Administrator del ' s Pocket Consultant ” e “ dell'amministratore di Windows Server 2008 Pocket Consultant, 2nd Edition ”.
William R. Stanek (williamstanek.com) è un esperto in tecnologia iniziali, autore pluripremiato di oltre 100 libri e un insegnante esplicativo molto darn valida. Libri corrente o imminente includono “ Active Directory Administrator del ' s Pocket Consultant, ” “ Group Policy Administrator del Pocket Consultant, ” “ Windows 7 Administrator del ' s Pocket Consultant, ” “ Exchange Server 2010 Administrator del ' s Pocket Consultant ” e “ Windows Server 2008 oltre ogni limite. ” Seguire Twitter in Stanek https://twitter.com/WilliamStanek.