Microsoft Exchange Server 2010: Strategie di elevata disponibilità
Le strategie di che Microsoft offre per la creazione di cassette postali di Microsoft Exchange altamente disponibili si sono evoluti nel corso degli anni.
Tratto da "Exchange 2010 - un pratico approccio," pubblicato da Red Gate Books (2009).
Jaap Wesselius
Sin da Exchange Server 5.5, Microsoft ha offerto servizio cluster di Windows come opzione per la creazione di un ambiente di cassette postali di Exchange altamente disponibile. Ci sono due nodi server disponibili in un ambiente tipico cluster di memoria condivisa. Sia in esecuzione Exchange Server ed entrambi i server sono collegati a una soluzione di storage condiviso.
Nei primi giorni, questo storage condiviso è stato costruito su un bus SCSI condiviso. Successivamente utilizzati in genere Network area di archiviazione (San) con una connessione di rete iSCSI o Fibre Channel. La parte importante è stata l'archiviazione condivisa dove si trovavano i database di Exchange Server.
Un solo server nodo è il "proprietario" dei dati condivisi. Questo nodo fornisce i servizi del cliente. È noto anche come nodo attivo. Altro nodo non è in grado di accedere a questi dati ed è quindi il nodo passivo. Una rete privata tra i nodi di due server è utilizzata per le comunicazioni all'interno del cluster, come un segnale di battito cardiaco. In questo modo entrambi i nodi determinare lo stato del cluster e garantire che gli altri nodi sono ancora vivi.
Oltre a due nodi, crea un "Exchange Virtual Server" come risorsa cluster. Questo non ha nulla a che fare con le macchine virtuali. Questa è la risorsa a cui si connettono i client Outlook per accedere alle cassette postali. Quando il nodo attivo non riesce, il nodo passivo assume il Server virtuale di Exchange, che poi continua a funzionare. Anche se gli utenti noteranno un breve tempo di inattività durante il failover, è un'esperienza altrimenti senza soluzione di continuità. Nessuna azione è richiesta dall'utente.
Anche se questa soluzione offre ridondanza, c'è un singolo punto di errore — il database condiviso del server di Exchange. In un ambiente tipico, questo database è memorizzato su una SAN. Per sua natura, una SAN è un ambiente altamente disponibile. Quando qualcosa capita di database, anche se, ad esempio un errore logico, il database è disponibile per entrambi i nodi. Il risultato totale indisponibilità.
Replica di database di Exchange
Con Exchange Server 2007, Microsoft ha offerto una nuova soluzione per la creazione di ambienti Exchange altamente disponibili: replica di database. Replica di database crea una copia di un database, con conseguente ridondanza del database. Questa tecnologia era disponibile in tre varianti:
- **Replica continua locale (LCR):**Questo approccio crea una copia del database sullo stesso server.
- **Replica continua cluster (CCR):**Questo crea una copia del database su un altro nodo in un cluster di failover di Windows (ci può essere solo due nodi di un cluster CCR).
- **Standby Continuous Replication (SCR):**Questo è venuto con Exchange Server 2007 SP1. Crea una copia di un database su qualsiasi altro Server di Exchange (non necessariamente in cluster). Questo non è destinato per l'alta disponibilità (HA); è più per il disaster recovery.
Questo è come la replica di database funziona in un ambiente cluster CCR. Su cluster di failover di Windows Server 2008 o Windows Server 2003 è installato Exchange Server 2007. Non non c'è nessuna archiviazione condivisa in uso all'interno del cluster. Ogni nodo ha un proprio deposito. Questo può essere sia su una SAN (iSCSI o Fibre Channel) o direct attached storage (DAS) — locali dischi fisici.
Il nodo attivo nelle richieste di client servizi cluster e Server di Exchange utilizza la tecnologia di database standard con un database, file di log e file di checkpoint. Quando Exchange Server è finito con un file di log, viene immediatamente inviato al nodo passivo del cluster. Ciò può essere tramite una connessione di rete normale o attraverso una rete dedicata di replica.
Il nodo passivo riceve il file di log e controlla errori. Se ne trova nessuno, i dati nel file di registro viene inoltrati alla copia passiva del database. Questo è un processo asincrono, ovvero che la copia passiva è sempre un paio di file di registro dietro la copia attiva, quindi informazioni sono "mancante" nella copia passiva.
In questo ambiente, tutti i messaggi, anche i messaggi interni — vengono inviati tramite un server Trasporto Hub. Il server Trasporto Hub tiene traccia di questi messaggi in un ambiente CCR. Può quindi inviare manca informazioni (che il nodo passivo richiede in realtà) della copia passiva del cluster in caso di failover del cluster. Questo è chiamato "Dumpster di trasporto" in un server Trasporto Hub.
Questo tipo di replica funziona molto bene. Replica CCR è abbastanza affidabile, ma ci sono un paio di potenziali inconvenienti:
- Un ambiente CCR di Exchange Server 2007 viene eseguito sul clustering di Windows Server 2003 o Windows Server 2008. Per molti, questo aggiunge troppa complessità all'ambiente.
- Windows Server 2003 cluster in un ambiente più subnet è quasi impossibile, anche se questo ha migliorato (ma non è ancora perfetto) in Windows Server 2008 failover clustering.
- Resilienza del sito non è perfetta.
- Cluster CCR è possibile solo in un ambiente di due nodi.
- Tutti e tre i tipi di replica (LCR, CCR e SCR) sono gestiti in modo diverso.
Per superare questi problemi, Microsoft ha migliorato notevolmente la tecnologia di replica. Ha anche ridotto i costi amministrativi. Raggiunto questo nascondendo completamente i componenti cluster dietro l'implementazione di Exchange Server 2010. I componenti del cluster sono ancora lì, ma l'amministrazione è fatto interamente con Exchange Management Console (EMC) o Exchange Management Shell (EMS).
Replica continua DAG
In Exchange Server 2010, Microsoft ha introdotto il concetto di un gruppo di disponibilità del database (DAG). Questa è un'unità logica dei server cassette postali di Exchange Server 2010. Tutti i server di cassette postali all'interno di un DAG può replicare i database a vicenda. Un singolo DAG può ospitare fino a 16 server cassette postali e fino a 16 copie di un database.
L'idea di più copie del database in un'organizzazione di Exchange viene chiamato mobilità di scambio. Esiste un database su server multipli, ogni istanza che è identico al 100% e quindi ha lo stesso GUID.
Con un DAG in luogo, client di connettono a un database attivo. Questo è il database dove tutti i dati sono stati archiviati inizialmente. Nuovi messaggi SMTP, sia da fuori o all'interno dell'organizzazione, vengono archiviati nel database prima.
Quando Exchange Server ha terminato l'elaborazione di informazioni nel file di log del database, replica il file ad altri server. È possibile assegnare i server che riceveranno una copia del database. Il file di registro viene controllato al ricevimento e se tutto va bene, le informazioni nel file di log sono cadute nella copia locale del database.
In Exchange Server 2010, tutti i client si connettono al Server accesso Client, inclusi tutti i client di Messaging Application Programming Interface o MAPI, come Microsoft Outlook. Client Outlook supportati in Exchange Server 2010 includono Outlook 2003, Outlook 2007 e Outlook 2010.
Così il client Outlook si connette al Server di accesso Client, che poi si collega alla cassetta postale nella copia del database attiva. Purtroppo, questo è vero solo per i database delle cassette postali. Quando un client Outlook deve accedere a un database di cartelle pubbliche, il client ancora accede al server cassette postali direttamente.
Quando fallisce la copia attiva di un database o server, una delle copie del database passive diventa attiva. Durante il processo di configurazione di copia database, è possibile configurare l'ordine di failover. Server accesso Client automaticamente il failover si accorge e inizia a utilizzare il nuovo database attivo. Poiché il client Outlook è connesso al Server accesso Client e non direttamente al database, un failover del database è completamente trasparente. Messaggi come, "la connessione al server è stato persa", e "viene ripristinata la connessione al server", semplicemente non compaiono più.
Quando si costruisce un ambiente di server di cassette postali altamente disponibile in un DAG, non c'è nessuna necessità di costruire un cluster di failover in anticipo. È possibile aggiungere i server cassette postali aggiuntive al DAG al volo. Tuttavia, per il DAG funzionare correttamente, si sta ancora utilizzando alcuni componenti di clustering di failover. Questi sono installati durante la configurazione di DAG. Fate tutti i DAG e database gestione copia via EMC o EMS. Non si dovranno utilizzare la gestione di Cluster di Windows.
Il DAG con copie del database è l'unica tecnologia HA che Exchange Server 2010 utilizza. Vecchie tecnologie come SCR, CCR e SCR non sono più disponibili. Cluster tradizionale copia singola con archiviazione condivisa non è più supportato, sia.
Configurazione di un DAG non è più limitato a un server contenente solo il ruolo del server cassette postali. È possibile creare una situazione di due server Trasporto Hub, accesso Client e ruoli del Server cassette postali su entrambi i server e quindi creare un DAG e configurare copie del database.
Tuttavia, non è una configurazione HA per i server Trasporto Hub o accesso Client a meno che non hai messo bilanciatori di carico davanti a loro. È possibile utilizzare l'impostazione predefinita Windows Network Load Balancing in combinazione con i componenti di clustering di failover. Tuttavia, questo è un grande miglioramento per piccole distribuzioni di Exchange Server 2010 dove HA è ancora necessaria.
.jpg)
Jaap Wesselius è il fondatore di DM consulenti, un'azienda con un forte focus sulle soluzioni di messaggistica e collaborazione. Dopo aver lavorato presso Microsoft per otto anni, Braun ha deciso di impegnarsi più del suo tempo per la comunità di scambio nei Paesi Bassi, con conseguente in un premio di MVP di Exchange Server 2007. Egli è anche un assiduo collaboratore olandese Unified Communications User Group e un autore regolare per Simple-Talk.
Ulteriori informazioni sul "Exchange 2010 - un approccio pratico" di red-gate.com/our-company/about/book-store.