Failover-Cluster (Stretched Cluster) - Storage Replication

[Attack44 2]

Hallo zusammen,

 

ich benötige ein wenig Hilfe in Bezug auf Stretched Cluster bzw. Storage Replication, dort komme ich nicht so ganz weiter.

 

Die Ausgangslage ist folgende, Wir haben in Gebäude A ein Failover-Cluster mit drei Nodes und einem zentralen SAN, dies ist unser "Hauptrechenzentrum". 

Im Gebäude B existiert theoretisch/technisch auch ein Failover-Cluster mit zwei Nodes und einem zentralen SAN.

 

Unser Ziel ist es, die VMs zwischen den beiden Gebäuden synchron zu halten, zumindest so weit es geht.

Wir hatten Anfangs mit einer HyperV-Replikation experimentiert, soweit waren wir damit zufrieden, aber Exchange wird ja offiziell technisch nicht unterstützt.

 

Neben dem synchron halten soll auch ein geplantes Failover zu Gebäude B möglich sein, so das Wartungsarbeiten in Gebäude A am SAN möglich sind und die VMs noch verfügbar sein.

Zwischen den Umschalten kann auch gerne keine kurze "Pause" sein, es muss nicht unbedingt eine Livemigration möglich sein.

 

Bei der ganzen Thematik habe ich mich auch mit Stretched Cluster bzw. Storage Replication beschäftigt, nur habe ich dazu nicht direkt ausführliche Anleitungen gefunden bzw. haben mir diese bisher nicht mir sehr weitergeholfen.

 

Wenn ich das richtig verstanden habe, kann ich die Storage Replication in einem  Stretched Cluster nutzen, in zwei einzelnen Failover-Clustern geht dies nicht. Aber wie geht man an die Sache heran, füge ich dem Cluster aus Gebäude A einfach die zwei Server/Nodes aus Gebäude B hinzu, ist dass dann ein Stretched Cluster? Auf das jeweilige SAN können doch nur die jeweiligen Server draufzugreifen.

 

Ich bin auch für andere Lösungen offen, ich möchte einfach nur, das beide Standorte den gleichen Datenbestand haben und man bei bedarf umschalten kann.

 

die Anbindung zwischen den beiden Gebäuden erfolgt per Glasfaser (10Gb)

 

 

Vielen Dank.

 

Gruß Andreas

[cj_berlin 1.323]

Moin,

 

von allem anderen abgesehen, lass Exchange einfach Exchange sein, bau eine DAG über beide Standorte, bilde sie ordentlich im AD ab und stelle in jedem mindestens einen Domain Controller bereit.

 

Für alles andere kannst Du Hyper-V Replica einsetzen, sofern für die jeweiligen Workloads supported.

[NilsK 2.939]

Moin,

 

solche Konstrukte neigen dazu, sehr aufwändig und sehr fragil zu werden. Sprich: Man hat enorm viel Arbeit und im Fall des Falles erreicht man nicht das, was man sich vorgestellt hat. Und es gibt viele, viele Szenarien, die man mit technischen Redundanzen kaum abfangen kann - ein simpler Klassiker sind versehentliche Löschungen. Daher bin ich kein Freund von "einfach alles spiegeln", weil es eben nicht einfach ist.

 

Mein alternativer Vorschlag: Prüft, was ihr wirklich braucht und richtet das zielgerichtet mit den jeweils zur Applikation passenden Methoden ein. "Was ihr wirklicht braucht" bedeutet, die relevanten Applikationen zu identifizieren und für diese jeweils zu untersuchen:

• welche ungeplante Ausfallzeit ist tolerabel?
• welche geplante?
• welcher Datenverlust ist im Fall eines Ausfalls tolerabel?
• welche relevanten Szenarien können zu Ausfällen führen? Welchen davon könnt ihr vorbeugen?
• was muss in welchem Szenario in welcher Qualität und in welcher Ziet wiederherstellbar sein?

Ja, das ist Arbeit. Erfahrungsgemäß aber lohnenswert. (Und ja, wenige Kunden machen das, weil sie diese Arbeit scheuen und doch lieber auf rein technische Konzepte setzen und in Kauf nehmen, dass diese nicht leisten, was sie sollen.)

 

Gruß, Nils

 

[cj_berlin 1.323]

...und vor allem (das is bei @NilsK der Punkt "welche relevanten Szenarien...") solltest Du den häufigsten Fehler der HA-Projektierung nicht wiederholen: Man beschäftigt sich bis zur Erschöpfung mit dem Ausfall eines RZ-Standorts (was äußerst selten ist, vom kontrollierten Shutdown einmal abgesehen) und vernachlässigt dabei  komplett den Ausfall der Standortverbindung (was Gang und Gäbe ist).

[NilsK 2.939]

Moin, 

 

Jupp. Und wenn wir schon beim Ergänzen sind: wesentlich häufiger als der Ausfall von "allem" ist der Ausfall von "etwas", und es ist immer wieder erschütternd, wie wenige Kunden darauf vorbereitet sind, nur einen Teil ihres Systems wiederherzustellen. 

 

Gruß, Nils

[vkf 0]

Mir ist die Ausgangssituation unklar, wird Gebäude umgebaut oder abgerissen?

Gibts ausreichend Speicher, Prozessor, Disk  & Co. in Gebäude B?

Ich finde es komisch, dem OP zu unterstellen, er hätte kein Backup für "ein simpler Klassiker sind versehentliche Löschungen."