Freitag, 6. Dezember 2013

Exchange 2013 - DAG Netzwerke für Clients und Replikation trennen

Auch unter Exchange 2013 ist es für eine DAG möglich, die Netzwerke für den Clientzugriff und die DAG Replikation zu trennen. Wie dies eingerichtet wird, zeige ich in diesem Post.

Vorbereitung

Grundsätzlich müssen die MBX Server, die Mitglied der DAG sind mal zwei Netzwerkkarten haben, um die Netze trennen zu können. Ich habe mir dazu auf dem Hyper-V Host einen privaten virtuellen Switch erstellt. Unter Hyper-V bedeutet ein privater virtueller Switch, dass nur VM's die mit dem Switch verbunden sind, miteinander kommunizieren können. Auch der Hyper-V Host selbst kommt nicht an das Netzt ran. Also also ob man zwei Hardware Server über einem Switch miteinander verbindet.



IP-Einstellungen

Client Netzwerk:
  • IP die aus dem Clientnetzwerk erreichbar ist
  • Default Gateway
  • DNS Server
Replication Netzwerk:
  • IP Range kann frei gewählt werden, muss sich aber vom Client Netzwerk unterscheiden
  • Kein Default Gateway
  • Keine DNS Server

Anpassungen für das Replication Netzwerk

In den IP v4 Einstellungen der Replication Netzwerkkarte muss die Einstellung "Adressen dieser Verbindung in DNS registrieren" (englisch: Register this connection’s address in DNS) deaktiviert werden:


Zusätzlich muss auch noch die Bindungs-Reihenfolge der Netzwerkkarten angepasst werden. Dies macht man wie folgt:


  1. Klicken Sie mit der rechten Maustaste auf das Symbol Netzwerk im Infobereich der Taskleiste
  2. Klicken Sie auf Netzwerk- und Freigabecenter.
  3. Klicken sie im Netzwerk- und Freigabecenter auf "Adaptereinstellungen ändern"
  4. Drücken Sie die ALT-TASTE, um die Menüleiste anzuzeigen, und klicken Sie dann im Menü "Erweitert" auf "Erweiterte Einstellungen".
  5. Nun kann die Reihenfolge der Netzwerkkarten angepasst werden. Das Client Netzwerk muss vor dem Replikations Netzwerk platziert werden:


Anpassungen in den Einstellungen der DAG

Meist erkennt die DAG die neue Netzwerkkarte und konfiguriert sich selbständig richtig. Kontrollieren kann man dies mit folgenden Befehl:

Get-DatabaseAvailabilityGroupNetwork | FL  Name,Subnets,Interfaces

Falls das Resultat aussieht wie folgt, ist alles OK:


Falls nach der Angabe der Subnets nicht "UP" sondern "Misconfigured" steht, kann dies wie folgt korrigiert werden:

  1. Die Konfiguration der Netzwerke für die DAG auf manuell stellen:

    Set-DatabaseAvailabilityGroup <Name of DAG> -ManualDagNetworkConfiguration $true
  2. Kontrolle der Einstellungen:

    Get-DatabaseAvailabilityGroupNetwork | FL  Name,Subnets,Interfaces

    In meinen Tests hat dieser Schritt die Einstellungen immer korrigiert.
  3. Nun kann die automatische Konfiguration wieder eingeschaltet werden:

    Set-DatabaseAvailabilityGroup <Name of DAG> -ManualDagNetworkConfiguration $false
Wenn ihr nun aber die Einstellungen der DAG Netzwerke anschaut, fällt auf, dass die automatische Konfiguration die Netzwerke so einstellt, dass die Replikation auf beiden Netzwerken möglich ist. Wenn man aber sicher stellen will, dass kein Replikationstraffic über das Client Netzwerk fliest, geht dies nur wenn die automatische Konfiguration der Netzwerke abgestellt wird.

Grundsätzlich finde ich diese Einstellung richtig, denn es bringt so etwas wie Redundanz. Wenn das Relpikationsnetz nicht zur Verfügung stehen sollte, kann die DAG auch das Client Netzwerk verwenden. Es kann aber auch ganz klar gewünscht sein, die Replikation über das Client Netzwerk auf jeden Fall zu verhindern. In diesem Fall wird die automatishc eKonfiguration der Netze wiederum mit folgenden Befehl aufgehoben:
Set-DatabaseAvailabilityGroup <Name of DAG> -ManualDagNetworkConfiguration $true

und mit folgenden Befehl die Replikation für das Client Netzwerk verhindert:

Get-DatabaseAvailabilityGroupNetwork -Identity <Name der DAG>\MapiDagNetwork | Set-DatabaseAvailabilityGroupNetwork -ReplicationEnabled $false

Wenn wir uns danach die Einstellungen nochmal anschaue sieht dies wie folgt aus:



Keine Kommentare:

Kommentar posten