6
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:
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!
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!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 583251
Url: https://administrator.de/contentid/583251
Ausgedruckt am: 23.11.2024 um 23:11 Uhr
6 Kommentare
Neuester Kommentar
Wer kommt auf so ein Replicationsnetzwerk? Ist doch purste Idiotie.
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.
Warten wir morgen ab 
rechne Mal wie viele Hosts da rein passen
rechne Mal wie viele Hosts da rein passen
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
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
Das ist mir eh alles klar. War halt damals die erste DAG - alles laut howto Copy/Paste konfiguriert. 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.
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.
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.
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.
1
