Was ist sind Database Availability Groups?
Die Hochverfügbarkeit
in der Vorgängerversion Exchange 2007 Mittels CCR, SCC, SCR und LCR
gehört nunmehr der Vergangenheit an. Durch die Database Availability
Groups abgekürzt auch DAG genannt, erfolgt der Failover nun pro
Datenbank und nicht mehr pro Server. Diese DAG Funktion im Exchange
2010, wird auch als inkrementelle Bereitstellung bezeichnet. Hierbei
handelt es sich um die Fähigkeit, die Dienst- und Datenverfügbarkeit für
alle Postfachserver und Datenbanken bereitzustellen.
How-To DAG:
1. Anforderungen
2. Netzwerk
3. Einrichtung
4. Proof of Conecpt
Funktionsweise:
Jeder
Server in einer Datenbankverfügbarkeitsgruppe kann als Host für eine
Kopie einer Postfachdatenbank eines beliebigen anderen Servers in der
Datenbankverfügbarkeitsgruppe fungieren. Wenn einer
Datenbankverfügbarkeitsgruppe ein Server hinzugefügt wird, wird dieser
mit den anderen Servern in der DAG eingesetzt, um eine automatische
Wiederherstellung nach Fehlern zu bieten, die Postfachdatenbanken
betreffen, z. B. Datenträger- oder Serverfehler.
DAG Alle Server Online:
DAG mit einem Server der zur Wartung offline geschaltet wurde und einem ausgefallenen Server:
1. Anforderungen
Allgemeine Anforderungen:
- DNS (Domain Name System) muss laufen.
- Jeder Postfachserver in einer Database Availability Groups muss ein Mitgliedsserver in erselben Domäne sein.
- DAG Mitglied und gleichzeitig File Server ist nicht unterstützt.
- Der DAG Name muss ein gültiger, verfügbarer und eindeutiger Computername mit maximal 15 Zeichen sein.
Hardwareanforderungen:
-
Grundsätzlich gibt es keine besonderen Hardwareanforderungen an das
DAG. Die Anforderungen müssen gemäß Exchange 2010 Hard- und
Softwarevoraussetzung erfüllt werden.
Softwareanforderungen:
- Das DAG ist in Exchange 2010 sowohl in der Standard als auch in der Enterprise Edition verfügbar.
Netzwerkanforderungen:
-
Jedes DAG Mitglied muss min. einen Netzwerkadapter besitzen, der mit
Allen anderen DAG Mitgliedern darüber kommunizieren (Protokollversand
/Seeding) kann.
2. Netzwerk Konfiguration
Netzwerkverbindungen:
Wie
in jeder Hochverfügbarkeit Strategie, ist ein Single Point of Failure
tunlichst zu vermeiden. Deshalb sind zwei Netzwerkarten für
physikalische/ logische Separation zwischen LAN (MAPI-Netzwerk) und DAG
(Replikationsnetzwerk) mit deren Operationen zwingend erforderlich.
Adapter/ Bindungen:
Auch hier ist DNS ein sehr wichtiger Bestandteil .
Damit die Server sich untereinander via die DNS auflösen können, so ist
im den Ersten Schritt auf eine saubere DNS-Konfig zu sorgen. Damit die
DNS-Anfragen schnellstmöglich abgearbeitet werden, ist neben der
Allgemeinen Konfiguration des Netzwerkadapters s.h. unten auch die
Verbindungsreihenfolge wichtig. Hierzu wird die entsprechende Verbindung
nach oben gesetzt, die auch im gleichen Subnetz mit dem o.g. DNS Server
steht. In diesem Fall “LAN“ Verbindung.
Netzwerk Konfiguration – LAN/ DNS:
Netzwerk Konfiguration – DAG:
Damit es nicht zu Konflikten oder gar
zu Beeinträchtigungen kommt, sollte das DAG Netzwerksegment stets ein
eigenständiges sein. Dieses Segment wird für die Kommunikation der
Server untereinander sowie für das Failover-Handling genutzt.
3. Einrichtung
Hinweis: Sofern kein Data Center Betrieb
angedacht (max. 16 Server) ist, reicht ein Zeugenserver (WitnessServer)
völlig aus. Der Zeugenserver muss min. ein Windows Server 2003 SP2 oder
höher sein und darf auf keinen DAG Mitglied-Server laufen. Empfehlung,
legt das FSW auf einen der CAS/HUB oder DC's. Das ist leider noch nicht
Alles. Des Weiteren muss die Gruppe “Exchange Trusted Subsystem“ auf dem
Zeugenserver Mitglied der Lokalen Administratoren sein. In einigen
Projekten habe ich gesehen, dass diese Berechtigung durch das DAG
automatisch gesetzt wurde. Verlassen sollte man sich hierauf aber nicht
und sollte der Sache stets nachgehen.
New-DatabaseAvailabilityGroup
-Name DAG-1 -WitnessServer DC01 -WitnessDirectory C:filesharewitness -
AlternateWitnessDirectory C:filesharewitness -AlternateWitnessServer
DC02
Verwaltung - DAG:
Get-DatabaseAvailabilityGroup | fl
Name : DAG-1
Servers : {SRVEX01}
FileShareWitnessShare : \DC01FileShareWitness
FileShareWitnessDirectory : C:filesharewitness
AlternateFileShareWitnessShare :
AlternateFileShareWitnessDirectory :
NetworkCompression : InterSubnetOnly
NetworkEncryption : InterSubnetOnly
DatacenterActivationMode : Off
StoppedMailboxServers : {}
StartedMailboxServers : {}
OperationalServers :
ControllingActiveManager :
ReplicationPort : 0
NetworkNames : {}
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
Identity : DAG-1
WhenChanged : 29/03/2011 7:22:42
WhenCreated : 29/03/2011 7:22:42
OrganizationId :
OriginatingServer : srvex01.exchangetayfun.com
IsValid : True
Verwaltung - DAG IP-Adresse:
Hinweis:
Sofern das DAG über EMC erstellt wird, so steht die Cluster-IP auf per
Default auf DHCP. Meine Empfehlung ist, die Cluster-IP bei der DAG
Erstellung direkt auf Statisch zu setzen. Dies kann nur aus der Shell
mit folgendem Befehl erfolgen:
New-DatabaseAvailabilityGroup -Name
DAG-1 -WitnessServer DC01 -WitnessDirectory
C:DAGWitnessDAG-1.exchangetayfun.com
-DatabaseAvailabilityGroupIPAddresses 10.10.1.102
Nachträglich mit:
Set-DatabaseAvailabilityGroup -Identity DAG-1 - DatabaseAvailabilityGroupIpAddresses 10.10.1.102
Für GUI Freunde - DAG Statische IP-Adresse Nachträglich:
Mitgliedschaft - DAG:
Im dem folgenden Schritt werden die Server als mit Mitglied in das DAG hinzugefügt.
Add-DatabaseAvailbilityGroupServer -Identity DAG-1 -MailboxServer SRVEX01
Add-DatabaseAvailbilityGroupServer -Identity DAG-1 -MailboxServer SRVEX02
Verwaltung – Erstellen Neue Postfachdatenbankkopie:
Nach der
erfolgeichen DAG-Mitgliedschaft, kann nun die s.g.
Posfachdatenbankankkopie erstellt werden. Hinweis: Die Datenbankkopie
wird auf dem DAG-Partner im gleichem Pfad abgelegt wie auf dem
Quellserver. Vorab darüber sich Gedanken zu machen, kann einges an
Stress und Zeit sparen
Add-MailboxDatabaseCopy -Identity 'DB01' -MailboxServer 'SRVEX01'
Verwaltung – Auswahl Postfachdatenbankkopie Partner:
4. Proof of Concept - DAG:
Nun kann die Verfügbarkeit Next Generation DAG mit Fehler-Simulationen auf Herz und Nieren geprüft werden.
- Get-MailboxDatabaseCopyStatus
- Test-ReplicationHealth
- Move-ActiveMailboxDatabase
- Simulation Systemausfall
o Dismount Postfachfatenbank,
o Mailbox-Knoten Herunterfahren
o Netzwerkarte deaktivieren ...
Fazit:
Durch geschickten Einsatz von DAG kann Hardware- sowie Backupkosten gesenkt werden.