HA-Datenspeicher

[cech 0]

Hallo,

mich würde mal interessieren ob Ihr eueren Datenspeicher ebenfalls Hochverfügbar gemacht habt und wenn ja wie ?

Ich meine, nehmen wir mal an ich habe ein Hyper-V - Cluster bestehend aus 2 Knoten, hinzu kommt ein Aktiv-Passiv Datenspeichermodell.

Beide Datenspeichergeräte synchonisieren sich untereinander und werden mit EINER IP-Adresse angesprochen.

Die Anbindung erfolg via iscsi, man kann davon ausgehen das bei einem Ausfalls eines Datenspeichers eine gewissen Umschaltzeit für den wechseln von passiv in aktiv ereicht wird, so weit so gut, wir reden hier von einer Umschaltzeit von unter 2 Minuten vielleicht max. 3 Minuten.

Was passiert jetzt aber auf dem Hyper-V host mit den einzelnen VM`s ? Die meisten bleiben stehen oder frieren ein !

Wie habt Ihr das Problem gelöst ? Ich denke mal es spielt sicherlich keine Rolle über welche Art die vms auf den Datenspeicher zugreifen.

Das Problem hat man ja auch bei SMB, Iscsi etc.

Gruß

Vielleicht habe ich ja auch einfach nur ein Denkfehler ich steh gerade wirklich auf dem Schlauch !

[Nobbyaushb 1.580]

Wir haben unter den Shares sowie unter dem Hyper-V-Cluster jeweils einen aktiv/aktiv Datacore Server, je 2 Stück, alles über Glasfaser 2*10G bzw. FibreChannel 2*8G bei den beiden älteren Datacore-Servern.

 

Somit alles HA - die sind auch in verschiedenen Räumen / Brandabschnitten und nur mittels Glasfaser verbunden.

 

;)

[Dukel 468]

Die Anbindung erfolg via iscsi, man kann davon ausgehen das bei einem Ausfalls eines Datenspeichers eine gewissen Umschaltzeit für den wechseln von passiv in aktiv ereicht wird, so weit so gut, wir reden hier von einer Umschaltzeit von unter 2 Minuten vielleicht max. 3 Minuten.

 

Was hast du denn für eine Storage, welche eine so lange Umschaltzeit hat? Es gibt unterbrechungsfreie Storages, die Sofort umschalten. Bei SMB (seit v3.0) ist das auch im Protokoll enthalten.

[NilsK 3.046]

Moin,

 

ein gespiegeltes Storage bedeutet noch lange kein unterbrechungsfreies Umschalten. Das erwarten zwar viele Kunden, aber nur wenige Storage-Systeme können das wirklich leisten.

 

Der Nutzen der Spiegelung besteht zunächst meist darin, dass keine Daten verloren gehen. Beim Ausfall des Primärsystems fällt dann aber das Gesamtsystem aus. Man kann es dann manuell auf das Sekundärsystem umstellen und neu starten. Die Daten sind alle da, aber eben nicht unterbrechungsfrei.

 

Selbst bei höherwertigen Mimiken, die ein "transparentes Failover" unterstützen, kann es zu längeren Umschaltzeiten kommen, die die Applikationen zunächst zum Absturz bringen. Und auch bei solchen Speichersystemen gibt es Situationen, in denen das Failover gar nicht funktioniert - das ist sogar nicht einmal unwahrscheinlich. Das Stichwort ist hier "Split Brain", was i.d.R. eine dritte Instanz erfordert. Ist diese nicht vorhanden oder nicht erreichbar, dann gibt es kein Failover.

 

Gruß, Nils

[magheinz 111]

unsere Datenspeicher sind Hochverfügbar. wir nutzen dazu Netapp-HA-Pärchen.

Da wir die beiden Controller nicht nur für HA sondern auch zur Lastverteilung nutzen gibt es zwei IP-Ziele für ISCSI. Bei einem Failover bleiben beide IPs aktiv. Es geht genau ein PING verloren. ISCSI hat damit kein Problem, SMB2.0 schon. Die VMs merken nichts von der Umschaltung unter VMware. Ich denke das ist bei HyperV nicht anders.

2Minuten Umschaltzeit sind aber ein KO-Kriterium dann brauche ich gar keinen Automatismus da die VMs eh alle abgeschmiert sind. Der Wiederanlauf des ganzen RZ dauert dann knappe 1-2 Stunden. Das soltle ungeplant möglichst gar nicht vorkommen.

 

Ich habe aber auch schon  solche Lösungen selber gebaut mit Linux, DRBD und einer IP-Umschaltung. Auch mit FreeNAS sollte das gehen.

[Ganzjahresgriller 1]

So kann man das mit MS Storage Spaces machen: http://dataonstorage.com/images/PDF/Solutions/poc2015/DataON_SOFS_MX-2340-308_Windows_Server_2012_R2_Storage_Spaces_Storage.pdf

[NeMiX 76]

Split Brain wurde ja schon von NilsK in die Runde geworfen. Das wird gerne unterschätzt und bei PoCs gerne mal unter den Tisch fallen gelassen.

Ich habe mit Metrocluster von NetApp in solchen HA Szenarien bisher nur gute Erfahrung gemacht, dort wurde dann aber auch alles doppelt ausgelegt inkl. die Anbindung zwischen den beiden Controllern über 2 verschiedene physikalische Wege.

Interesannterweise kommen per default Windows Server mit einem längeren Storage Timeout (hatte schon mal Server die selbst knapp 2 Minuten überlebt haben in einem Testszenario) klar als Linux das unter 10Sekunden die Mounts in RO setzt und bei einem Neustart erst mal einen Integrity Check durchführt. Das hängt aber auch sehr von der Workload ab die gerade stattfindet und die Storagehersteller haben für sowas immer Anweisungen was am OS geändert werden sollte.

 

Die ganzen Hyper-Converged Kisten (Nutanix, Simplivity usw.) können das teilweise auch, nur ob eine Eierlegende Wollmilchsau die Lösung für alle Storageprobleme ist wage ich zu beweifeln.

[Dukel 468]

Alternativen ist evtl. Storage Virtualisierung wie VSan oder Windows Server 2016 (Storage Spaces Direct), bei denen es kein SAN gibt sondern replizierte Lokale Storages. Dort tritt dieses Problem gar nicht auf.

[NorbertFe 2.280]

Dafür andere. ;)

[Dunkelmann 96]

Moin,

 

2-3 Minuten ist schon recht viel bzw. viel zu viel für einen transparenten Failover. Unter 60 Sekunden sollte es schon liegen.

Man kann natürlich am disk timeout schrauben und so die Clusterressource (mit Glück) am Leben halten. Wie Nils schon schrieb, gilt es auch das Verhalten der Anwendungen zu berücksichtigen.

 

Was soll mit dem hochverfügbaren Storage erreicht werden? Minimaler Datenverlust, maximale Verfügbarkeit oder Beides?

Wie wird synchronisiert? Synchron oder Asynchron?

[Doso 77]

Wir verwenden in iSCSI SAN für unseren Hyper-V Cluster. Da ist etwas Ausfallsicherheit drumrum gebaut, also redundantes Netzwerk, MPIO, zwei Controller, aber es ist halt nur das eine SAN. Auch das kann, und ist leider schonmal, ausfallen.Man kann auch den Storage auf HA trimmen, aber das erhöht halt die Komplexität und vor allem die Kosten nochmal massiv. Da hat Cheffe halt dann nein gesagt.. Backup hätten wir ja auch noch, dann haben wir ggf. halt ein paar Tage Ausfall. Wir leben halt mit dem Risiko.

[monstermania 53]

Bei uns sieht das Szenario ähnlich wie bei Doso aus.

Hosts sind redundant. SAN ist zentral und soweit wie möglich redundant ausgelegt (Dual-Anbindung, usw.). Ein voll redundantes SAN-Konzept wurde ebenfalls aus Kosten/Nutzengründen verworfen. Wir haben baulich bedingt die gesamte IT Infrastruktur im gleichen Brandabschnitt stehen (Serverraum). Vollredundanz macht m.E. eigentlich auch nur Sinn, wenn die gesamte Infrastruktur auch komplett auf min. 2 Brandabschnitte aufbaut. 

[magheinz 111]

Wir haben sogar zwei Brandabschnitte und trotzdem ist das DR-Konzepz aus Kostengründen nicht durchgeführt worden. Der Speicher ist aber so ausgelegt das wir das jederzeit umsetzen könnten, es fehlen nur die redundanten Server. Wir haben primär eine Netapp(HA-Cluster) und als Backup auch eine. Im Dümmsten Fall könnten wir die Backupnetapp produktiv schalten und müssten eine Reihe Server für VMWare besorgen. Wenn mal wieder Geld übrig ist kommt ein zweites Bladecenter an die Backupnetapp und DR ist "fertig". Die Lizenzfragen wären dann noch mal spannend zu klären...