rickstinson
Goto Top

Exchange 2016 DAG Erweiterung nicht möglich wg timeout

Hallo,

ich habe hier einen two-node Exchange 2016 CU17 DAG Server.
Dieser sollte nun mit zwei weiteren Servern erweitert werden. Diese sind schon installiert & konfiguriert und warten nur mehr in die DAG aufgenommen zu werden.
Das wollte ich heute eigentlich erledigen.

Das DAG Setup schaut so aus:
NIC 1: Fürs normale LAN 192.168.0.0/24
NIC 2: Replication Network 10.0.0.0/8

Soweit, so root.
Wenn ich allerdings die beiden neuen Server in die DAG hinzufügen möchte, bricht der Vorgang mit einen Timeout ab:

Fehler beim serverseitigen Verwaltungsvorgang für eine Database Availability Group. Fehler: Fehler bei Vorgang. CreateCluster-Fehler können von falsch konfigurierten statischen Adressen verursacht werden. Fehler: Fehler beim Ausführen eines Clustervorgangs. Fehler: Fehler für Cluster-API: "Fehler von AddClusterNode() (MaxPercentage=100) mit 0x5b4. Fehler: Dieser Vorgang wurde wegen Zeitüberschreitung zurückgegeben"   

Habe jetzt mal echt viel gegoogled, aber viel weiter bin ich nicht gekommen.
Es dürfte aber eben an der Konnektivität liegen. Was mir aufgefallen ist, bei EXSRV1 + EXSRV2 lauscht UDP 4443 auf der NIC2 (Replication),

Wenn ich EXSRV3 in die DAG aufnehmen möchte, lauscht aber UDP 4443 auf der NIC1 (LAN).
Nachgesehen mit "netstat -ano"

Und ich denke das ist genau mein Konnektivitätsproblem. Ich erinnere mich bei einer SQL-BAG genau vor dem selben Problem gestanden zu haben, und dass die Lösung sehr simple war... notieren hätte man sich das halt müssen...

Hat jemand vielleicht eine Idee?

Vielen Dank!

Content-Key: 583251

Url: https://administrator.de/contentid/583251

Printed on: April 13, 2024 at 12:04 o'clock

Member: falscher-sperrstatus
falscher-sperrstatus Jul 01, 2020 at 00:04:34 (UTC)
Goto Top
Wer kommt auf so ein Replicationsnetzwerk? Ist doch purste Idiotie.
Member: rickstinson
rickstinson Jul 01, 2020 at 00:25:25 (UTC)
Goto Top
Was ist daran so schlimm? Der IP Bereich wird sonst nicht verwendet. Zugegebenermaßen hab ich mir damals (um 2014, da haben wir mit Exchange 2013 DAG gestartet) nicht viel dabei gedacht.
Member: falscher-sperrstatus
falscher-sperrstatus Jul 01, 2020 at 00:30:16 (UTC)
Goto Top
Warten wir morgen ab face-smile rechne Mal wie viele Hosts da rein passen
Member: Ad39min
Solution Ad39min Jul 01, 2020 at 10:24:03 (UTC)
Goto Top
Sofern Du nicht vor hast, irgendwann 16 Millionen Exchange Server oder mehr zu betreiben, solltest Du einen kleineren Netzwerkbereich wählen.
Wenn die vergebenen IPs in diesem Bereich nah beieinander liegen (also nicht z.B. EX1 10.0.0.1 und EX2 10.255.255.254 haben), würde ich definitiv auch im Nachhinein eine kleinere Subnetzmaske festlegen.

Gegebenes Szenario: Dein Unternehmen erweitert sich um einen Standort. Dieser hat einen beliebigen Netzwerkbereich, der mit 10. anfängt. Z.B. 10.131.150.0/24.
Dieser Standort soll nun die Exchange Server von euch mitbenutzen. Diese können jedoch keine Packets an die anfragenden Clients von Standort B zurückschicken, da diese ins DAG-Netz geschickt werden.

Gruß
Alex
Member: rickstinson
rickstinson Jul 01, 2020 at 13:46:56 (UTC)
Goto Top
Das ist mir eh alles klar. War halt damals die erste DAG - alles laut howto Copy/Paste konfiguriert. face-smile Das Netz hier ist noch älter. Noch Anfang 2000 hatte hier jeder Client PC eine öffentlich routbare IP, irgendwann hab ich dann auf NAT umgestellt.
Member: rickstinson
rickstinson Jul 01, 2020 updated at 21:16:54 (UTC)
Goto Top
So, ich konnte das Problem lösen, vielleicht hilft das ja jemanden.

Problem:
Die Heartbeat Verbindung läuft über Port 3343 UDP.
Auf den bisherigen Exchange Server ist dieser Port auf die IP vom der Replication Netzwerkkarte gebunden.
Auf den zwei neuen Server war 3343 UDP auf die IP vom LAN gebunden. (netstat -ano)
-> Damit geht der Heartbeat nicht und die neuen Server lassen sich nicht in die DAG aufnehmen.

Lösung:
ich habe kurzfristig das MAPIDAG eingeschalten:
Set-DatabaseAvailabilityGroupNetwork -Identity "DAGNAME\MapiDagNetwork" -ReplicationEnabled:$true

Dann konnten die beiden neuen Server problemlos hinzugefügt werden und Port 3343 war nun brav auf die Replication Netzwerkkarte gebunden.
Danach habe ich das MapiDAG wieder abgeschalten.
Set-DatabaseAvailabilityGroupNetwork -Identity "DAG-2016\MapiDagNetwork" -ReplicationEnabled:$false -IgnoreNetwork:$true

Konnte schon zwei neue Datenbank in die DAG hinzufügen. Clusterhealth ist auch OK, und es läuft soweit ich es sehe fehlerfrei.