Exchange 2010 Database Availability Group
In Exchange 2007, pentru implementarea unei solutii de high availability, avem posibilitatea sa folosim unul dintre modurile de cluster LCR, CCR, SCC si SCR, si sa le configuram in functie de scenariul pe care l-am ales.
LCR – local continuous replication – este folosit in cazul organizatiilor de mici dimensiuni, care doresc sa replice o copie a bazei de date Exchange pe un alt volum, pe acelasi server.
SCC – single copy cluster – a fost preluat din versiunile mai vechi de Exchange. Este implementarea standard de cluster care foloseste storage partajat si permite tuturor nodurilor clusterului sa acceseze resursele. Un nod al clusterului va detine resursele pentru un anumit grup, iar celelalte noduri vor comunica cu quorum-ul pentru evita situatia in care resursele partajate ar fi accesate de un alt nod decat cel activ in urma producerii unei erori.
CCR – cluster continuous replication – este folosit pentru a replica bazele de date Exchange intre servere oferind redundanta atat la nivel hardware cat si din punct de vedere al storage-ului.Unul dintre impedimente il reprezinta faptul ca acest tip de cluster nu suporta decat un singur nod activ.
SCR – standby continuous replication – a devenit disponibil odata cu lansarea Exchange 2007 SP1 pentru a putea replica bazele de date Exchange intr-o locatie aflata la distanta, cum ar fi un centru pentru disaster recovery.
Lansarea celei mai noi versiuni de Exchange, 2010, aduce o modificare majora a solutiei de clustering prin introducerea noului feature numit DAG(Database Availability Group).In principiu, DAG combina functionalitatile CCR si ale SCR din Exchange 2007 acoperind atat partea de high availability, cat si cea de disaster recovery.In aceasta noua versiune de Exchange Server LCR si SCC nu mai sunt disponibile, singura metoda de a configura un cluster Exchange reprezentand-o DAG.
Alte schimbari majore fata de versiunea anterioara de Exchange este faptul ca putem instala si alte roluri pe serverul care este configurat ca membru al DAG(mai putin Edge Server) si ca a fost eliminat conceptul de Storage Group, in aceasta versiune replicarea se produce la nivel de baza de date, caz in care numele acelei baze de date trebuie sa fie unic in organizatie.
Dupa crearea DAG si adaugarea celui de al doilea server(numarul maxim de servere care pot fi adaugate intr-un grup este de 16) administratorii pot adauga copii ale bazelor de date ce vor fi replicate incremental, iar serverul Exchange va folosi mecanisme interne pentru a folosi ca si activa o copie sau alta in cazul in care va fi nevoie, pentru a mentine disponibilitatea serviciilor.
Mediul de test consta in 5 servere pe care am instalat Windows Server 2008 SP2 si o masina client cu Windows 7 RC si MS Outlook 2007.
Unul dintre servere a fost promovat la DC(are instalate rolurile de Active Directory Domain Services si DNS Server), altul are instalate rolurile Exchange HUB si CAS, iar celelalte trei au instalat rolul de Mailbox.
Pentru a instala Exchange 2010 Enterprise Edition trebuie sa fie indeplinite urmatoarele cerinte:
– procesor x64 Intel64 sau AMD64, Itanium IA64 nu sunt suportate
– memorie minim 4GB RAM.In cazul in care serverul detine rolul de Mailbox Server se adauga de la 2 pana la 10 MB/mailbox in functie de profilul utilizatorului
– spatiu pe disc de cel putin 1,2GB pentru instalarea Exchange Server plus 200MB pe system drive
– sistem de operare Windows Server 2008 x64 SP2 sau Windows Server 2008 R2
– forest functional level trebuie sa fie cel putin Windows Server 2003 si DC-ul care detine rolul de Schema Master trebuie sa ruleze cel putin Windows Server 2003 SP1
Mailbox serverele ce vor fi adaugate ca si membru in DAG trebuie sa aiba cel putin 2 placi de retea deoarece una dintre ele va fi folosita pentru comunicarea cu reteaua interna iar cea de a doua pentru replicarea bazelor de date in DAG.Aceste servere, membre ale DAG, vor trebui instalate pe editiile Enterprise ale Windows Server 2008 x64 sau Windows Server 2008 R2 deoarece Standard Edition nu suporta instalarea componentelor necesare pentru configurarea in DAG.
Dupa instalarea sistemului de operare trebuie instalate ca .NET Framework 3.5 SP1, Windows Management Framework Core (PowerShell si WinRM), Microsoft Filter Pack (pe acele servere care vor detine rolul de Hub sau Mailbox Server) si Exchange 2010 prerequisites care pot varia in functie de rolul pe care il va avea instalat serverul.Inca de la lansarea versiunii RC, Exchange 2010 contine cateva fisiere de raspuns xml preconfigurate, cu ajutorul carora pot fi instalate componentele necesare unui anumit rol sau unei anumite combinatii de roluri.
Primul va fi instalat serverul care va detine rolurile de HUB si CAS, EXCHHUBCAS01, ruland urmatoarele comenzi din command prompt:
sc config NetTcpPortSharing start= auto
ServerManagerCmd -ip Exchange-Typical.xml –Restart
Dupa instalarea componentelor, poate fi pornit wizard-ul de instalare Exchange Server 2010.Din moment ce acesta este primul server din organizatia Exchange si nu am pregatit in prealabil schema AD pentru aceasta instalare, userul cu care rulam setup-ul trebuie sa faca parte din grupurile Enterprise Administrators si Schema Administrators.
In principiu, procesul de setup al Exchange 2010 se aseamana cu cel din versiunea anterioara, insa se poate observa in aceasta faza ca nu mai sunt disponibile optiunile de instalare a rolurilor Active si Passive Clustered Mailbox.
Ca si la versiunea anterioara, trebuie sa alegem numele organizatiei, sa specificam daca in aceasta organizatie exista clienti de mail Outlook 2003(si versiuni mai vechi) sau Entourage, iar dupa verificarea instalarii componentelor necesare va incepe instalarea rolurilor selectate.
Procesul de instalare al rolului de mailbox pe celelalte 3 servere, EXCHMBX00, EXCHMBX01 si EXCHMBX02, este similar cu exceptia faptului ca va trebui rulata alta comanda pentru instalarea componentelor necesare:
ServerManagerCmd -ip Exchange-MBX.xml –Restart
Apoi va trebui selectat rolul de Mailbox:
Desi intentionam sa configuram aceste servere ca si noduri ale unui cluster, in aceasta versiune nu este necesara instalarea feature-ului Failover Clustering inainte de a instala Exchange Server.
Dupa finalizarea instalarii se poate crea Database Availability Group accesand Organization Configuration>Mailbox>Actions>New Database Availability Group din Exchange Management Console. In wizard-ul de configurare va trebui sa specificam numele grupului, numele pentru witness server si witness directory.
La finalizarea acestui pas, va fi creat un computer account in AD cu numele pe care l-am specificat pentru DAG.
Pentru a fi creat si partajat witness directory, trebuie ca grupul Exchange Trusted Subsystem sa aiba drepturi administrative pe witness server.
Dupa crearea grupului, va fi necesar sa configuram interfetele de retea pentru DAG, o retea publica pentru comunicarea cu reteaua interna si o retea privata(intr-un alt subnet) folosita pentru replicarea bazelor de date.
Dupa configurarea interfetelor de retea putem adauga primul server in DAG accesand Manage Database Availability Group Membership si selectand apoi serverul pe care dorim sa il adaugam.
Celelalte servere se pot adauga ruland urmatoarea comanda din Exchange Power Shell:
Add-DatabaseAvailabilityGroupServer -Identity EXCH14RC1 -MailboxServer NumeServer
Dupa rularea acestei comenzi(sau apasarea butonului Manage din interfata grafica), componenta Failover Clustering va fi instalata automat serverele specificate, iar ele vor deveni noduri in clusterul EXCH14RC1 si vor putea fi vizualizate in consola Failover Clustering Management.
Imediat dupa adaugarea celui de al doilea server in DAG, witness share-ul este creat pe witness server care in acest caz este serverul pe care sunt instalate rolurile de HUB si CAS, EXCHHUBCAS01. Failover clustering quorum-ul, care inainte de adaugarea celui de al doilea server era setat ca “Node Majority”, va fi schimbat automat in “Node and file share majority”.
Pentru adaugarea copiilor bazelor de date trebuie sa specificam numele bazei, numele serverului pe care se va afla acea copie si “activation preference number”, numar ce reprezinta ordinea in care copiile bazei de date vor fi montate in cazul aparitiei unei erori si pornirii procesului de failover.
Numarul maxim de mailbox servere ce pot fi adaugate in DAG este de 16 si pot fi create copii ale bazelor de date de pe un server-membru pe un altul sau pe toate celelalte servere din acel grup, deci putem avea pana la 15 copii ale unei baze de date.
Odata cu lansarea Exchange 2010 o noua componenta, numita Active Manager, determina care dintre copiile unei baze de date va fi activa si care va fi pasiva. Informatiile de configurare ale Active Manager sunt stocate in Active Directory (in timp ce datele DAG sunt stocate atat in AD cat si in baza de date a clusterului) si ruleaza pe fiecare server membru al DAG.
In cazul in care baza de date activa va deveni corupta, Active Manager va selecta urmatoarea copie care va fi montata, iar pentru a suporta noul mod de failover, toti clientii indiferent de protocolul utilizat (chiar si cei MAPI care inainte se conectau direct la mailbox serverul Exchange 2007) se conecteaza acum la serverul cu rolul de CAS; acest mod de conectare se numeste “MAPI on the Middle Tier”.
Pasii pentru replicarea continua intre bazele de date sunt urmatorii : actualizarea bazei, copierea logurilor, analizarea logurilor si comiterea tranzactiilor in baza de date.
Serviciul de replicare al Exchange 2007 foloseste protocolul Server Message Block (SMB) si notificarile pentru a transfera logurile, in timp ce in Exchange 2010 replicarea se face folosind TCP si notificari catre sursa despre logurile care sunt necesare pentru actualizarea datelor astfel existand posibilitatea de a cripta si comprima logurile, optiuni care se configureaza la nivel de Database Availability Group.Dupa analizarea logurilor, serviciul de replicare va efectua o serie de teste de validare, iar dupa ce aceasta etapa va fi finalizata, tranzactiile vor fi comise in baza de date.
Odata create copiile bazelor de date putem testa functionarea clusterului prin deconectarea interfetei de retea care este folosita pentru deservirea cererilor MAPI.
In prima faza am configurat un profil Outlook pentru userul test00-1 pe statia de lucru care se conecteaza la serverul cu rolul de CAS EXCHHUBCAS01.Mailbox-ul acestui user se afla in baza de date MBX00-1, care este montata pe mailbox serverul EXCHMBX00.
In aceslasi timp, am folosit OWA(care in aceasta versiune de Exchange este acronimul pentru Outlook Web App) pentru a accesa mailbox-ul altui user, test01-1, aflat pe baza de date MBX01-1 montata pe serverul EXCHMBX01.
Dupa un schimb de email-uri intre aceste conturi am deconectat interfata de retea(cea folosita pentru comunicarea cu reteaua interna, implicit si cu CAS-ul) a serverului EXCHMBX00 din consola VMWare.
Dupa deconectare procesul de failover a pornit automat si a montat copia bazei MBX00-1 pe serverul EXCHMBX01.
In acest timp Outlook s-a deconectat de la server, iar email-ul de test pe care am incercat sa il trimit a ramas in Outbox pana cand procesul de failover s-a terminat si mailbox-ul a putut fi accesat, durata fiind de aproximativ 45 de secunde .
In cazul in care este utilizat OWA in acest timp, dupa failover este necesar ca userul sa se reconecteze la acel mailbox cu log off/log on.
Pentru a incepe procesul de failback, am reconectat interfata de retea pe EXCHMBX00 si am verificat daca datele sunt sincronizate.La inceput, CopyStatus pe nodul afectat devine Unknown, apoi in timp ce sunt copiate logurile si comise tranzactiile in baza de date devine Failed, iar la final trece in Healthy.
Dupa identificarea sursei si rezolvarea problemei din cauza careia baza de date a devenit indisponibila(in cazul nostru intreruperea conexiunii) si verificarea consistentei bazei, putem porni procesul de failback selectand copia bazei de date(care inainte de intrerupere a fost cea activa) accesand Activate Database Copy din Action Pane, iar modificarile vor fi efectuate imediat fara a mai afecta utilizatorii.
Daca este necesar, pentru operatiunile de mentenanta, administratorii se pot folosi de facilitatile oferite de aceasta arhitectura cu baze de date replicate pe diferite servere, montand copii ale bazelor de date(configurandu-le ca baze active) situate pe alte servere membre DAG.
Toate etapele de configurare de mai sus pot fi efectuate si din Exchange Management Shell si, la fel ca si in cazul Exchange 2007, comenzile pot fi copiate din ferestrele wirzard-urilor de configurare atunci cand este folosita consola EMC.