Freitag, 2. September 2011

Hochverfügbarkeit Exchange 2010




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.

Keine Kommentare:

Kommentar veröffentlichen