Parte prima: introduzione

Ciao a tutti,

con questo articolo volevo dare il via ad una serie di post relativi ad una delle novità più interessanti di Exchange 2010 ovvero il Database Availability Group Replication (DAG). Iniziamo con un veloce ripasso sul DAG e sulla sua installazione. Più avanti andremo più a fondo esaminando in dettagli i componenti installanti e vedremo alcuni scenari di troubleshooting.

Come certo saprete in Exchange Server 2010 è stato abbandonato il modello di alta affidabilità utilizzato nella versione precedente. Il Cluster Continuous Replication (CCR) e il Single Copy Cluster (SCC) sono stati sostituiti dal Database Availability Group Replication (DAG).

Il DAG continua ad utilizzare il modello di replica basato sul log shipping e una filosofia simile a quella presente nello Standby Continuous Replication (SCR) di Exchange 2007.

Adesso il Mailbox Database non è più associato ad uno specifico server ma viene considerato un oggetto dell’organizzazione e può essere replicato su 16 mailbox server distribuiti su siti diversi.

Per questo motivo, con Exchange 2010, per i mailbox database, viene richiesto un nome univoco all’interno dell’organizzazione. Con questo nuovo modello inoltre è stato rimosso il concetto di Storage Group (e i transaction log in comune tra i vari database) e il MBDB appartiene semplicemente all’ organizzazione (e più precisamente al DAG).

Di seguito un confronto di come sono organizzati gli oggetti relatvi ai MBDB su Active Directory in Exchange 2007 (a sinistra) e in Exchange 2010:

image

Exchange 2007 CCR

image

Exchange 2010 DAG

Nota: i Public Folder (come per Exchange 2007) non possono essere replicati tramite DAG. E’ necessario utilizzare i meccanismi di replica classici.

In caso di fallimento del server sul quale gira il mailbox database attivo un altro mailbox server sarà scelto in base ad una serie di criteri che vedremo in seguito.

Un’altra grande differenza sta nel fatto che, diversamente dal CCR di Exchange 2007, un server che ospita una copia di un mailbox database (partecipando al DAG) può ospitare anche i ruoli CAS e HUB.

Infatti, differentemente dalle edizioni precedenti (Exchange 2007 incluso), l’installazione Exchange 2010 non “nasce” da subito come membro di un cluster. L’installazione viene condotta come se si trattasse di un server con uno o più ruoli. Dopodichè il server potrà formare o partecipare al DAG (Incremental deployment).

Altre differenze col modelli di clustering precedente di Exchange 2007 sono le seguenti:

  • Log shipping via TCP (la porta di default è la 64327) anziché SMB
  • Compressione dei log file (con un algoritmo proprietario chiamato XPRESS e basato su LZ77)
  • Encryption dei log file (via Kerberos SSP)

Un altro punto importante che il nostro Gruppo di Prodotto ha voluto sottolineare più volte è che, nonostante il nuovo modello sia basato in parte sul Windows 2008 Failover Clustering (WFC), adesso non è strettamente richiesto agli amministratori di Exchange di essere esperti di tecnologie di clustering (tutti i task che implicano azioni sul DAG possono essere effettuati da EMC o EMS) e che non sono più necessari dischi condivisi (e Storage Area Network) per far funzionare il cluster Exchange.

JBOD contro SAN e un salto nel passato

Nelle vecchie versioni di Exchange (dal 5.5 al 2003), salvo ricorrere a prodotti terze parti, avevamo necessariamente bisogno di un disco condiviso per “clusterizzare” i servizi Exchange. Questo significava acquistare una SAN (magari non dedicata), schede in fibra, SW Multipath, ulteriori costi per l’energia elettrica, contratto di assistenza per il vendor dell’ HW, costi per i “ragazzi che amministrano la SAN” e via dicendo.

Abbiamo iniziato ad abbandonare in parte questo modello con Exchange 2007 (dove continuava comunque ad essere presente il vecchio modello col Single Copy Cluster) per abbandonarlo totalmente in Exchange 2010.

Qualcuno potrà pensare che si tratta di una attenta operazione di marketing per trasferire risorse economiche dai vendor HW a Microsoft (sottoforma di licenze). Beh, non è proprio così J.

Facciamo un salto nel passato…. Per eseprienza personale, quando ero “dall’altra parte della barricata”, capitava che le nostre SAN avessero qualche problema: blocchi, uno o più dischi fuori uso per volta con conseguenti rallentamenti e (aimè) perdite di dati. Personalmente non ho mai subito nessuna perdita di dati J ma, per citare un esempio, in un caso un mio fornitore HW, dopo l’apertura di tre ticket per lo stesso problema, dopo parecchi fermi sostituì completamente una SAN in fibra entry level. Una volta passato al Supporto Microsoft non sono mancate occasioni dove il problema su Exchange derivasse in realtà da rallentamenti sulla SAN.

Ovviamente non è il caso buttare via le Storage Area Network J ma è bene ricordare che, nostante tutto (doppia alimentazione, doppia scheda in fibra, doppio switch in fibra, RAID, etc.), queste non sono immuni da problemi e rappresentano uno SPOF (signe point of failure) importante.

Adesso, con copie multiple dei MBDB, sono disponibili altre soluzioni e risorse (vedi dischi JBOD) che possono essere impiegate al posto dei più costosi sistemi RAID e Storage Area Netowork.

Non è forse meglio possedere più copie di un MBDB invece che una soltando ritrovandosi magari, dopo uno stop dei servizi, a ripristinare i dati da un backup oppure fermi in attesa del termine di un ESEUTIL su un MBDB da 300GB ?

Parte seconda: installazione

Quindi, di cosa abbiamo bisgono per creare il nostro DAG ?

  • Almeno due (massimo sedici) Exchange 2010 Server Enterprise Edition con Windows Server 2008 EE (due NIC per server sono caldamente raccomantate, confugurazioni con una sola scheda sono comunque supportate)
  • Un File Share Witness per il DAG (che non può essere ospitata da uno dei membri del DAG). Il FSW può essere anche un server Windows 2003.
  • Un Round Trip Latency tra i membri del DAG inferiore ai 250ms

Il DAG può essere creato via EMC da Organization Configuration, Mailbox, tab Database Availability Group, New Database Availability Group oppure, ovviamente, da EMS:

image

Prima di procedere, nel caso di server multihomed con una NIC dedicata al log shippping ed una alla connesione MAPI client (ed al log shipping), sarà necessario aggiungere una (o più rotte statiche) sulla interfaccia dedicata alla replica dei log tramite il seguente comando:

netsh interface ip add route <IPsubnetdaraggiugere>/<mask> "ReplicationA" <IPGateway>

Ricordo che è possibile configurare solo un default gateway per host. Per questo motivo, per l’interfaccia dedicata alla replica, abbiamo bisogno di una o più rotte statiche.

Ricordo inoltre i seguenti settings per l’interfaccia usata per la replica dei log:

Networking Features

Setting

Client for Microsoft Networks

Disabled

QoS Packet Scheduler

Disabled

File and Printer Sharing for Microsoft Networks

Disabled

Internet Protocol Version 6 (TCP/IP v6)

Enabled

Internet Protocol Version 4 (TCP/IP v4)

Enabled

Link-Layer Topology Discovery Mapper I/O Driver

Enabled

Link-Layer Topology Discovery Responder

Enabled

Sempre su questa interfaccia l’IP dovrà essere assegnato in maniera manuale, non sarà necessario configurare un server DNS e il checkbox “Register this connection's addresses in DNS” dovrà essere disabilitato.

Sempre riguardo all’indirizzamento IP il nostro esempio non prevedere appunto di assegnare a nessun componente del DAG degli indirizzi dinamicamente (via DHCP). Anticipo che durante la creazione del DAG riceveremo degli errori dovuti a questo che verranno corretti manualmente via cmdlet.

Procediamo quindi alla creazione di un DAG via GUI:

image

Nota: dopo questo step potremmo ricevere uno warning relativamente alla creazione del FSW. Nella maggiorparte dei casi l’errore deriva dal fatto che su Windows 2008 il Windows Firewall è abilitato di default (interferendo con le operazioni di creazione e condivisione della directory). Un’altra ragione, se non viene utilizzato un server Exchange 2010 come FSW, potrebbe essere relativa ad una mancanza di permessi. Si dovrà aggiungere in questo caso, al gruppo locale Administrators del FSW il gruppo Exchange Trusted Subsystem:

image

Maggiori infromazioni su eventuali errori possono essere rilevate dai file presenti presso la seguente directory: C:\ExchangeSetupLogs\DagTasks .

Successivamente alla creazione il DAG non avrà membri. Per aggiungere un server sarà semplicemente necessario selezionare il DAG e successivamete il task “Manage Database Availability Group Membership”, selezionando poi i mailbox server da includere (una volta conclusa la procedura potrebbero essere necessari alcuni minuti per il completamento).

image

Aggiungere un membro al DAG ha come conseguenza le seguenti azioni:

  • Installazione di Windows Failover Cluster (WFC) sul nodo (se non già installato)
  • Se il server aggiunto è il primo sarà creato un cluster chiamato col nome del DAG (DAG01)
  • Un Cluster networks object (CNO) con lo stesso nome del DAG (DAG01) sarà creato su AD nel conteiner “Computers”
  • Un Host (A) record col nome del DAG sarà aggiunto nel DNS
  • Il server verrà aggiunto al cluster
  • Se il server aggiunto non è il primo il modello di quorum verrà rivaluato e cambiato da Node Majority (con un numero di nodi dispari) e File Share Majority (con un numero di nodi pari e il FWS):
image

Come ultimo step sarà necessario aggiungere i MBDB da replicare. Questo da EMC da Organization Configuration, Mailbox, tab Database Management. Cliccare sul DB da includere nella replica e selezionare ”Add Mailbox Database Copy”:

image

Alla partenza dello wizard selezionare i server sui quali verrà replicato il MBDB indicando inoltre l’ “Activation Preference Number” per ognuno di essi:

image

Clicchiamo, alla fine dello wizard, su Finish:

image

Ovviamente quanto fatto sopra può essere realizzato anche via cmdlet. Un esempio qua di seguito:

Creazione di un DAG

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EXHUB1 -WitnessDirectory C:\DAG1FSW -DatabaseAvailabilityGroupIpAddresses 10.0.0.8

Aggiungere un Mailbox Server al DAG

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EXMBX1

Aggiungere un MBDB al DAG

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer EXMBX1

Tornando al wizard, a questo punto (mi riferisco al setup effettuati via EMC), questo anziché concludersi con successo potrebbe restituire uno warning: “The Network Name “DAG01” is not online. Please check that the IP address configuration of the Database Availability Group is correct”.

Questo è corretto poichè, come accennato in precedenza, non abbiamo nessun DHCP server a servire la subnet del nostro lab e lo wizard non permette di specificare gli IP da utilizzare per il DAG.

Parlo al pluralare (due IP address) poiché la configurazione in questo caso prevede due nodi da due diverse subnet. Per questo sarà necessario configurare due IP (uno per subnet) con la seguente cmdlet:

Set-DatabaseAvailabilityGroup <DAGName> –DatabaseAvailabilityGroupIpAddresses <IPAddressSite1, IPAddressSite2>

Possiamo, alla fine del nostro lavoro, verificare le impostazioni del DAG appena configurato la seguente cmdlet: Get-DatabaseAvailabilityGroup | FL

image

Prima di conlcudere sistemiamo un ultimpo punto: distinguiamo i network per la replica da quelli per l’accesso client disabilitanto su alcuni di essi il log shipping:

Get-DatabaseAvailabilityGroupNetwork –Identity <DAGName>

image

Anche questa operazione deve essere effettuare via cmdlet. Nello scenario di cui sopra queste sono le cmdlet necessarie:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG01\DAGNetwork02 -ReplicationEnabled $False
Set-DatabaseAvailabilityGroupNetwork -Identity DAG01\DAGNetwork04 -ReplicationEnabled $False

Nel prossimo post (disponibile tra breve) andremo più a fondo esplorando la configurazione appena completata e alcune parametri tra cui: Quorum models, Activation preference, Lagged copies, Active Manager, Primary Active Manager (PAM) and the Standby Active Manager (SAM), Datacenter Activation Coordination (DAC). Vedremo inoltre delle novità introdotte dal Service Pack 1 e, come accennato, parleremo un po’ di troubleshooting!

Cristian Crifò
Senior Support Engineer
Microsoft Enterprise Exchange Support