Hyper-V Replikation in anderes Netz

[kiffajoe 12]

Guten Morgen Zusammen,

 

hat jemand Erfahrung mit Hyper-V Replikation zu einen anderen Standort und somit in ein anderes Netz?

 

Konkrete Fragestellung:

Primäres Netz: 172.17.1.0/25

Remote Netz: 172.17.4.0/25

 

Hier im lokalen Netzwerk habe ich einen Hyper-V-Host mit zwei Domaincontroller und einen Mailserver am laufen - logischerweise mit lokalen IPs - z. B. 172.17.1.9.

 

Jetzt habe ich ins Remote Netzwerk einen Hyper-V-Server integriert. Dieser soll für die Replikation als Partner vom Haupt-Hyper-V-Server agieren.

 

Der Domaincontroller mit der IP 172.17.1.91 ist auch bei allen Clients im Netzwerk als DNS-Server 1 angegeben. Wenn ich den Server jetzt repliziere funktioniert das problemlos.

Nur was ist, wenn wirklich der Worstcase eintritt und der Hyper-V-Host im primären Netzwerk ausfällt. Dann könnte ich zwar den Failover starten, aber der Domaincontroller denkt ja er wäre im Netzwerk 172.17.1.0 - dabei ist er im 172.17.4.0er Netzwerk.

 

Hat jemand eine Idee wie ich das lösen kann. Ich will die Replikation zu einem anderen Standort haben, weil ich dann einfach auch die Sicherheit habe, dass im Brandfall etc. die Server weiterhin existieren...

 

Viele Grüße

Christian

[Nobbyaushb 1.471]

Moin,

ja, das geht - die Replikation von Domänencontrollern ist z.B. nicht supportet, ebenso Exchange und mit Einschränkungen SQL

 

Das Konzept sollte überarbeitet werden.

[kiffajoe 12]

vor 2 Minuten schrieb Nobbyaushb:

Moin,

ja, das geht - die Replikation von Domänencontrollern ist z.B. nicht supportet, ebenso Exchange und mit Einschränkungen SQL

 

Das Konzept sollte überarbeitet werden.

Danke für die schnelle Antwort!

Wie macht Ihr das denn dann? Oder gibt's hier niemanden der die Anforderung hat über Standorte hinweg zu replizieren? Da hat man so eine schöne 1GB Glasfaser-Standleitung der T-Com...da könnte man die doch schön nutzen...;-)

 

LG
Christian

[mwiederkehr 373]

Es sind zwei unterschiedliche Fragestellungen:

 

- Im Brandfall eine Lösung haben, sprich, den Replica-Host in neue Räumlichkeiten zügeln und einschalten: Das geht mit Replicas. Im Notfall wäre ja Zeit vorhanden, die IP-Konfiguration umzustellen. Die DCs muss man nicht unbedingt replizieren, man kann auch einen DC permanent am zweiten Standort laufen lassen. Die Replikation von DCs sei aber seit Windows Server 2012 supported: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/support-for-using-hyper-v-replica-for-virtualized-domain-controllers. Die Replikation des Exchange ist nicht supported, aber wenn es nur ein Server ist, sollte es keine Probleme geben.

 

- Schnelle Umschaltung im Fehlerfall: Dafür ist die Hyper-V-Replikation nicht gedacht. Du müsstest stattdessen auf dem zweiten Host die Server parallel laufen lassen: zweiten (bzw. dritten) DC, zweiten Exchange (mit DAG) und allenfalls Dateiserver (mit DFS-R). Dann stimmt auch die IP-Konfiguration, aber das Setup wird komplexer.

[kiffajoe 12]

vor 1 Minute schrieb mwiederkehr:

Es sind zwei unterschiedliche Fragestellungen:

 

- Im Brandfall eine Lösung haben, sprich, den Replica-Host in neue Räumlichkeiten zügeln und einschalten: Das geht mit Replicas. Im Notfall wäre ja Zeit vorhanden, die IP-Konfiguration umzustellen. Die DCs muss man nicht unbedingt replizieren, man kann auch einen DC permanent am zweiten Standort laufen lassen. Die Replikation von DCs sei aber seit Windows Server 2012 supported: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/support-for-using-hyper-v-replica-for-virtualized-domain-controllers. Die Replikation des Exchange ist nicht supported, aber wenn es nur ein Server ist, sollte es keine Probleme geben.

 

- Schnelle Umschaltung im Fehlerfall: Dafür ist die Hyper-V-Replikation nicht gedacht. Du müsstest stattdessen auf dem zweiten Host die Server parallel laufen lassen: zweiten (bzw. dritten) DC, zweiten Exchange (mit DAG) und allenfalls Dateiserver (mit DFS-R). Dann stimmt auch die IP-Konfiguration, aber das Setup wird komplexer.

hm...ich hatte es befürchtet!

 

Wobei, wie du schon sagst: Im Brandfall wird's eh einen längeren Ausfall geben, da hätte ich Zeit manuell nachzusteuern...oder mir den Hyper-V-Host vom anderen Standort abzubauen und rüber in den Hauptstandort zu bauen - Entfernung sind nur 4km...wäre auch eine Überlegung...

Danke Euch schon mal für die Anregungen und Tipps!!!

[NilsK 2.934]

Moin,

 

doch, es ist supported, einen DC per Hyper-V Replica zu replizieren. Ob es sinnvoll ist, ist eine andere Frage. In den meisten Designs empfiehlt man, dass "auf beiden Seiten" je ein DC läuft und man diese dann nicht repliziert (wie ja auch hier schon angemerkt wurde). Dadurch ist in (fast) jedem Fall die Anmeldung schon mal möglich. Exchange hingegen ist nicht supported - heißt: Es kann gehen, aber wenn nicht, wird Microsoft einem nicht helfen.

 

VMs über Subnets hinweg zu replizieren, wirft immer die Frage nach den Netzwerkeinstellungen auf. Die wird man in der Regel anpassen müssen. Hyper-V Replica ist, wie schon angedeutet wurde, nicht als Hochverfügbarkeitslösung gedacht, sondern als "mittelschnelle" Möglichkeit zum Wiederanlauf. Es ist ja ohnehin manueller Eingriff erforderlich, selbst im selben Subnetz.

 

Gruß, Nils

 

bearbeitet 3. September 2018 von NilsK

[kiffajoe 12]

Ja, das ist mir

vor einer Stunde schrieb NilsK:

Moin,

 

doch, es ist supported, einen DC per Hyper-V Replica zu replizieren. Ob es sinnvoll ist, ist eine andere Frage. In den meisten Designs empfiehlt man, dass "auf beiden Seiten" je ein DC läuft und man diese dann nicht repliziert (wie ja auch hier schon angemerkt wurde). Dadurch ist in (fast) jedem Fall die Anmeldung schon mal möglich. Exchange hingegen ist nicht supported - heißt: Es kann gehen, aber wenn nicht, wird Microsoft einem nicht helfen.

 

VMs über Subnets hinweg zu replizieren, wirft immer die Frage nach den Netzwerkeinstellungen auf. Die wird man in der Regel anpassen müssen. Hyper-V Replica ist, wie schon angedeutet wurde, nicht als Hochverfügbarkeitslösung gedacht, sondern als "mittelschnelle" Möglichkeit zum Wiederanlauf. Es ist ja ohnehin manueller Eingriff erforderlich, selbst im selben Subnetz.

 

Gruß, Nils

 

"Mittelschnell" ist - zumindest hier -  ausreichend!