Redundanz über asynchronen Spiegel (Hyper-V 2012 R2)

[jochen35 10]

Hallo,

wir wollen eine redundante Hyper-V Umgebung über zwei Standorte  (A und B) aufbauen, wobei uns pro Standort 3 Hostsysteme und jeweils ein Storage-System (IBM DS3512) zur Verfügung stehen. Die beiden Standorte sind über 4x10GbE miteinander verbunden. Die beiden Storage-Systeme nutzen hiervon jeweils 2x10GbE für eine Verbindung via iSCSI und können darüber leider nur einen asynchronen Mirror bereitstellen. Die Hostsysteme können mit 2x10GbE an die Storage-Systeme beider Standorte (A und B) angebunden werden. Die Clientsysteme wiederrum befinden sich an einem dritten Standort © von dem aus die Standorte A und B via GbE erreichbar sind.

Da die Storage-Systeme in der bestehenden Konfiguration leider keinen synchronen Mirror bereitstellen können, ist aus unserer Sicht ein standortübergreifender Cluster (Stretch Cluster) nicht realisierbar.

Wir sind daher nun auf der Suche nach einer Lösung, um dennoch über die Standorte A und B ein  redundantes Hyper-V System bereitstellen zu können. Im Optimalfall sollen die Hyper-V Hostsysteme dabei gleichzeitig über beide  Standorten Ressourcen bereitstellen können, die im Fehlerfall (Ausfall eines Standortes) durch den jeweils anderen Standort kompensiert werden können.

Ist das ganze Vorhaben mit Hyper-V 2012 R2 realisierbar und welche Konfigurationslösung würdet Ihr unter den genannten Voraussetzungen aus Eurer Erfahrung hierfür empfehlen?

Gruß
Jochen

[Dunkelmann 96]

Moin,

 

ohne synchrone Replikation sieht es mit einem Stretch Cluster schlecht aus.

Ich würde mal einen Blick auf DataCore werfen.

[NilsK 2.957]

Moin,

 

in der beschriebenen Konfiguration könnte man einen Hybrid aus zwei Clustern und Hyper-V Replica aufbauen.

 

• Standort 1
  • Cluster 1 aus drei Knoten
  • Anbindung ans SAN von Standort 1
  • Hyper-V Replica Broker als zusätzliche Clusterrolle
• Standort 2
  • Cluster 2 aus drei Knoten
  • Anbindung ans SAN von Standort 2
  • Hyper-V Replica Broker als zusätzliche Clusterrolle

Wichtig: Hyper-V Replica ist asynchron und nicht für jede Server-Applikation geeignet. Ich würde damit also nur die VMs replizieren, deren Applikationen das vertragen.

Für AD würde ich auf jedem der Cluster (mindestens) einen virtuellen DC einrichten, der immer läuft. Kein Replica für die DCs.

Für Exchange würde ich einen DAG-Cluster als Gastcluster empfehlen, ein Teil der VM-Nodes läuft an Standort 1, der andere an Standort 2. Kein Replica. Alternativ: Exchange nur an einem Standort, Datensicherung erfolgt an Standort 2. So könnte man nach einem Ausfall ein Dialtone Recovery an Standort 2 machen.

 

Mit der nächsten Version von Windows Server könnte Storage Replica für eure Umgebung interessant werden. Das würde ich aber durchaus noch etwas reifen lassen, bevor ich es produktiv nutze.

 

Gruß, Nils

bearbeitet 5. März 2015 von NilsK

[Dukel 455]

Welche Applikationen laufen denn virtuell? Statt eines Strechted Hyper-V Clusters kannst du auch die Applikationen verfügbar auslegen. Mit vielen Applikationen (AD, Exchange, SQL Server,...) geht dies.

[jochen35 10]

@NilsK

Das ist ein sehr interessanter Ansatz. Die Replikate stammen dann ja jeweils von einem anderen Cluster. Müssen sie vor dem Start dann erst noch dem "neuen" Cluster zugeordnet werden oder kann man sie einfach im zweiten Cluster starten, wenn der erste vom Netz ist?

 

Was die Anwendungen angeht, soll neben dem AD ein Fileserver, SQL, SharePoint und ein Terminalserver gehostet werden.

 

Storage Replica hört sich wirklich vielversprechend an, kommt für uns nur leider zu spät.

 

Könnte man es eigentlich auch so umsetzen, dass man mit allen Knoten nur einen Cluster bildet, die Anbindung ans SAN nur über Standort 1 erfolgt und über die Storage einen asynchronen Mirror am Standort 2 einrichtet? Wenn ja, wie würden dann die Knoten am Standort 2 im Fehlerfall die VMs aus dem Mirror hochfahren können?

 

Gruß

Jochen

[Dunkelmann 96]

Könnte man es eigentlich auch so umsetzen, dass man mit allen Knoten nur einen Cluster bildet, die Anbindung ans SAN nur über Standort 1 erfolgt und über die Storage einen asynchronen Mirror am Standort 2 einrichtet? Wenn ja, wie würden dann die Knoten am Standort 2 im Fehlerfall die VMs aus dem Mirror hochfahren können?

Der Ausfall des Storage oder der Verbindung bewirkt einen dirty shutdown von Cluster und VMs. Ein transparenter Failover ist nicht möglich.

 

Asynchrone Replikation ist ein DR-Setup und/oder Backupvehikel. HA ist nur bei synchroner Replikation möglich. Gleiches gilt auch für Hyper-V Replika, es ist eine DR und keine HA Lösung.

 

Du solltest erst mal klären, was gewünscht ist: DR oder HA.

[NilsK 2.957]

Moin,

 

Was die Anwendungen angeht, soll neben dem AD ein Fileserver, SQL, SharePoint und ein Terminalserver gehostet werden.

 

AD würde ich nie per Replica betreiben. Mir fällt kein Szenario ein, in dem das sinnvoll sein könnte.

 

Die anderen Dienste, die du angibst, sollten sich grundsätzlich mit Hyper-V Replica vertragen. Du musst immer im Auge behalten, dass es dort Datenverluste gibt - gering, aber vorhanden.

SQL Server ist mit Replica supported, wenn man einige Grenzen einhält. Sharepoint ist ja in Wirklichkeit auch SQL Server, die Web-Komponente ist im Wesentlichen zustandslos.

 

[Hyper-V Replica Support für Active Directory, Exchange oder SQL Server? › Daniel's Tech Blog]
http://www.danielstechblog.de/hyper-v-replica-support-fr-active-directory-exchange-oder-sql-server/
 

Im Cluster setzt Hyper-V Replica auf dem Replica Broker auf, der sich um die Clusterintegration kümmert. So kannst du von einem Cluster vom anderen replizieren. Oder auch zwischen Einzelhost und Cluster.

 

Ganz wichtig aber: Das ganze ist nicht "schnell mal eben". Es gehört ein Konzept dazu, insbesondere für den Failover-Fall.

 

Gruß, Nils

[Necron 71]

Ich mach mal kurz die Querverweise zwischen TechNet und MCSEboard rein. ;)

 

-> https://social.technet.microsoft.com/Forums/de-DE/6e51ec84-7d2a-417b-a9e8-86f916934b12/redundanz-ber-asynchronen-spiegel-hyperv-2012-r2?forum=virtualisierung