image2

You Are here: Start Kategorie als Blog Exchange 2010: Einrichtung DAG

Exchange 2010: Einrichtung DAG PDF Drucken E-Mail
Montag, den 06. August 2012 um 12:14 Uhr

Hier mal ein Schnellablauf zum Einrichten einer DAG. Damit die Clients in von der Replikation nicht beeinflusst
werden, empfiehlt sich ein eigenes ReplLAN. Dieses ist aber nicht zwingend erforderlich bietet sich aber bei
gerade beim Seeding an:


Sollte eine Witness genutzt werden: Handelt es sich bei dem Server nicht um einen Exchange, muss
die ETS-Gruppe in die lokale Admingruppe. Handelt es sich weiter um einen DC muss ETS in die
Administratoren-Gruppe der Domain-Admins. Das sollte aber NUR in einem Lab erfolgen, da das ein
Sicherheitrisiko birgt!

 

LAN einrichten

Die Konfiguration der Netzwerkadapter sieht wie folgt aus:

Element

LAN

DAGReplication

Client für Microsoft-Netzwerk

aktiviert

deaktiviert

QoS-Packetplaner

optional

optional

Datei- und Druckerfreigabe für Microsoft-Netzwerk

aktiviert

deaktiviert

IPv6

optional

optional

IPv4

aktiviert

aktiviert

EA-Treiber für Verbindungsschicht-Topologierkennung

aktiviert

aktiviert

Antwort für Verbindungsschicht-Topologierkennung

aktiviert

aktiviert

In den erweiterten DAGReplication-Einstellungen sollten als nächstes die DNS-Registrierung und folgende
WINS-Einstellungen deaktiviert werden:

Achten Sie darauf, dass das „normale“ LAN in den Adaptereinstellungen ganz oben steht:

DAG einrichten

Im nächsten Schritt wird die Datenverfügbarkeitsgruppe angelegt. Das kann über die EMC als auch über die EMS erfolgen:

In der Zusammenfassung erhält man auch den Powershellbefehl für die Aufgabe. Die Meldung "Die Exchange-
Sicherheitsgruppe 'Vertrauenswürdiges Teilsystem' ist kein Mitglied der lokalen Gruppe 'Administratoren' auf
dem angegebenen Zeugenserver
" zur fehlenden Sicherheitsgruppe kann ignoriert werden, da wir die Rechte
bereits angepasst haben:

New-DatabaseAvailabilityGroup –Name DAG1 –WitnessServer witnesssrv –WitnessDirectory “C:\DAGWitness”
-DatabaseAvailabilityGroupIPAddresses 192.168.200.10

Im nächsten Schritt können Sie die Member der Gruppe bereits zuordnen. Folgen für vorhandene Datenbanken
hat das nicht:

Als letzter Schritt wird noch das DAG-IP definiert, dass im oberen Befehl evtl. mit DatabaseAvailabilityGroupIPAddresses
bereits eingerichtet wurde. Ohne diese ClusterIP wird die Cluster-Ressouce, die Im Hintergrund aktiv ist, nicht starten:

Ein entsprechender Eintrag ist im Anschluss im DNS zu finden:

Genauso gibt es jetzt im AD ein entsprechenden Objekt und es empfiehlt sich eine eigene Cluster-OU zu erstellen,
in der diese Objekte verschoben werden, um ein versehentliches Löschen zu verhindern:

Gleiches gilt für die Eigenschaften der DAG, die nun in der Configuration Partition des ADs zu finden sind
(Configuration > Services > Microsoft Exchange > Administrative Groups > FirstGroup > Database Available Group):

Sowohl auf dem DAGwitness und im lokalen Failovercluster-Manager hat sich einiges getan:

Damit die Replikation nicht über beide Netzwerke stattfindet, sollte beim „normalen“ LAN die Replikation deaktiviert werden:

Datenbankkopie erstellen

Als nächstes können Sie für die Datenbank eine Kopie erstellen:

Server für die neue Kopie auswählen und hinzufügen:

Je nach Größe der Datenbanken solle das Seeding das Netzwerk etwas in Anspruch nehmen - 50GB hatten hier etwa
20Minuten benötigt:


Probleme

Gerade beim Hinzufügen eines neuen Servers zu einer SingleCopyDB kann es zu Fehlern kommen. Dabei wird evtl. auf ein fehlendes Log hingewiesen oder man wird mit dem Abbruch durch einen User konfrontiert (ESE 221 / ESE 245):


Abhilfe schafft hier das verzögerte Seeding mit aktivierter Umlaufprotokollierung:

Datenbankkopie erstellen:
Add-MailboxDatabaseCopy TestDB -MailboxServer E10-2 -SeedingPostponed:$true

Umlaufprotokollierung aktivieren:
Set-MailboxDatabase TestDB -CircularLoggingEnabled:$true

Seeding der DB anschupsen:
Update-MailboxDatabaseCopy TestDB\E10-2 –DeleteExistingFiles:$true

Umlaufprotokollierung deaktivieren:
Set-MailboxDatabase TestDB -CircularLoggingEnabled:$false

Siehe auch:
http://blogs.technet.com/b/exchange/archive/2011/05/31/exchange-2010-high-availability-misconceptions-addressed.aspx