none
Verständnisfrage: iSCSI Cluster für Hyper-V Cluster RRS feed

  • Frage

  • Guten Morgen zusammen!

    Ich arbeite aktuell an einem Projekt, an dessen Ende ein hochverfügbares, georedundantes 2-Knoten Hyper-V Cluster stehen soll.
    Meine Frage bezieht sich auf den dazugehörigen iSCSI Storage.

    Man möge mich korrigieren wenn ich falsch liege:
    Diese Knoten (identisch ausgestattet) können ihren lokalen Speicher nicht in Echtzeit replizieren und bei Ausfall einen Failover auf den anderen Knoten durchführen, weshalb eine lokale Speicherung der VMs nicht praktikabel ist.
    Deshalb wird ein separater (iSCSI-)Storage benötigt.

    Um einen Single-Point-of-Failure zu vermeiden, möchte ich dieses Storage ebenfalls als 2-Knoten-Cluster (unter Windows) betreiben.

    Nun meine Verständnisfrage:
    Bräuchte dieses zweite Cluster mit der installierten iSCSI-Target-Rolle nicht wiederum einen separaten Storage, weil es sich ja wieder um lokalen Speicher handeln würde?
    Und wenn das doch geht, warum kann der Hyper-V-Cluster die VMs nicht wie eingangs erwähnt lokal speichern und auf beide Knoten replizieren?

    Vielleicht habe ich ja ein Brett vorm Kopf.

    Vielen Dank für eure Hilfe!


    • Bearbeitet D_Khan Montag, 22. Februar 2021 11:18 Fehler entfernt
    Montag, 22. Februar 2021 11:17

Antworten

  • Moin,

    wenn iSCSI als Zugangsmedium für Dich nicht in Stein gemeißelt ist, kannst Du dir Storage Spaces Direct (S2D) anschauen. Da wird tatsächlich der lokale Festplattenspeicher der Hosts zu einem redundanten clusterfähigen Speicher (CSV) zusammengefasst.

    Du könntest mit so etwas sowohl einen reinen Hyper-V-Cluster bauen (VMs sitzen direkt auf den S2D-Volumes) oder Dein ursprüngliches Konzept umsetzen (Im "Storage-Cluster" sitzt eine geclusterte iSCSI-Target-Rolle auf einem S2D-Volume, und das "Computer-Cluster" greift darauf per iSCSI zu, oder: Im "Storage-Cluster" sitzt ein Scale Out Fileserevr (SOFS) auf dem S2D-Volume, und Hyper-V greift darauf per SMB3 zu).

    S2D ist ein Datacenter-Feature, daher könnte ein reines Storage-Cluster teuer werden, für Hyper-V wirst Du ja vermutlich ohnehin Datacenter-Lizenzierung einsetzen...

    Ein ähnliches Konzept verfolgen z.B. Produkte von StarWind.

    Last but not least: Wenn "Georedundant" für "hohe Latenzen zwischen den Standorten" steht, wirst Du mit jeder Art synchroner Replikation vermutlich nicht glücklich werden.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert D_Khan Montag, 22. Februar 2021 18:09
    Montag, 22. Februar 2021 11:28

Alle Antworten

  • Moin,

    wenn iSCSI als Zugangsmedium für Dich nicht in Stein gemeißelt ist, kannst Du dir Storage Spaces Direct (S2D) anschauen. Da wird tatsächlich der lokale Festplattenspeicher der Hosts zu einem redundanten clusterfähigen Speicher (CSV) zusammengefasst.

    Du könntest mit so etwas sowohl einen reinen Hyper-V-Cluster bauen (VMs sitzen direkt auf den S2D-Volumes) oder Dein ursprüngliches Konzept umsetzen (Im "Storage-Cluster" sitzt eine geclusterte iSCSI-Target-Rolle auf einem S2D-Volume, und das "Computer-Cluster" greift darauf per iSCSI zu, oder: Im "Storage-Cluster" sitzt ein Scale Out Fileserevr (SOFS) auf dem S2D-Volume, und Hyper-V greift darauf per SMB3 zu).

    S2D ist ein Datacenter-Feature, daher könnte ein reines Storage-Cluster teuer werden, für Hyper-V wirst Du ja vermutlich ohnehin Datacenter-Lizenzierung einsetzen...

    Ein ähnliches Konzept verfolgen z.B. Produkte von StarWind.

    Last but not least: Wenn "Georedundant" für "hohe Latenzen zwischen den Standorten" steht, wirst Du mit jeder Art synchroner Replikation vermutlich nicht glücklich werden.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert D_Khan Montag, 22. Februar 2021 18:09
    Montag, 22. Februar 2021 11:28
  • Hallo!

    Nein, iSCSI ist keineswegs fix, es scheint nur die gängigste Lösung zu sein.

    Nach deinem Tipp schaue ich mir mal S2D an, da hier nach meinem Verständnis der Invest in die zusätzliche Storage-Hardware entfallen würde und ein einzelnes Cluster ausreicht.

    (Sprich: 2x Hardware anstatt 4x Hardware?) 

    Nice to know: Das Projekt befindet sich noch in der Planungsphase, es kann also noch einiges gedreht werden. Der Ping konnte unter Realbedingungen noch nicht getestet werden. Die RZ befinden sich ca. 20km auseinander, verbunden per 1Gbit, in ferner Zukunft kann auf 10Gbit erweitert werden, davon soll jetzt zu Beginn jedoch aus Kostengründen abgesehen werden, auch wenn technisch sinnvoll. 

    Wie funktioniert denn in dem von dir beschriebenen Fall das Failover bei der 1-Cluster-Lösung?

    Repliziert das Cluster die Daten laufend auf beide Knoten?

    Das scheint auf jeden Fall eine optimale Lösung zu sein, wenn so umsetzbar.

    Danke für den Denkanstoß.

    Montag, 22. Februar 2021 11:51
  • Moin,

    für S2D ist 10 GB Pflicht.

    Alle Requirements sind hier und minutiös zu befolgen.

    Ist es ein vollsymmetrisches Szenario (sprich: die Last wird auch im Regelbetrieb auf beide RZ verteilt) oder ein Ausfallszenario (im Regelbetrieb ist die Last im RZ1 konzentriert, bei Ausfall muss RZ2 möglichst nahtlos übernehmen)?


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 22. Februar 2021 13:05
  • Moin,

    Es wird ein Ausfallszenario. 

    Ich habe den Preis eines 10G Crossconnect einmal angefragt, mal schauen was die Geschäftsführung sagt.

    Bisher hatten wir tatsächlich nur mit 1G geplant, harren wir der Dinge, die da kommen.


    Montag, 22. Februar 2021 14:20
  • Moin,

    Es wird ein Ausfallszenario. 

    In dem Fall: Storage Replication oder Hyper-V-Replication. Es muss ja nicht synchron sein, nur konsistent.

    Das Problem mit synchroner Storage-Replikation ist immer, dass Deine Network-Latenz zur Storage-Latenz wird bzw. auf die dem Storage grundsätzlich inne wohnende Latenz drauf kommt.

    Die zuverlässigste Methode ist aber weiterhin nicht die Replikation auf der Plattform-Ebene, sondern in der Applikation. AD, Exchange, SQL machen es vor. Und wenn Du solche Anwendungen hast: Am besten diese gleich standort-redundant bauen und aus der Plattform-Replikation ausschließen.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 22. Februar 2021 15:28
  • Auf das Cluster kommen Kundendaten und später auch Kunden VMs.

    Ziel ist es, eine hohe Verfügbarkeit der VMs selbst beim Totalausfall eines RZ zu gewährleisten und das ohne (sofortigen) manuellen Eingriff.

    Und da bei der Replikations-Lösung kein automatischer Failover stattfindet, ist dies leider keine zu den Anforderungen passende Lösung.

    Wenn durch die Geschäftsführung das 10G Upgrade genehmigt wird, gehe ich deinen S2D-Vorschlag nochmal an, dieser scheint nach erster Recherche sehr vielversprechend, da alle anderen Anforderungen, sowohl von uns an das System als auch umgekehrt gegeben sind.

    Vielen Dank für den Input.

    Montag, 22. Februar 2021 18:09
  • Und da bei der Replikations-Lösung kein automatischer Failover stattfindet, ist dies leider keine zu den Anforderungen passende Lösung.

    Huch? Doch, in eine Richtung schon. Zurück muss man das manuell schwenken.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 22. Februar 2021 19:09
  • Okay, das müsste ich nochmal testen.

    Die Lösung war schonmal angedacht, nur fand halt kein automatischer Failover statt, weshalb auch online überall auf eine Clusterlösung verwiesen wurde, anstelle der klassischen Hyper-V Replikation.

    Aber ich lasse mich gerne eines Besseren belehren. ;)

    Edit: Den Artikel habe ich durch eine kurze Google-Suche gefunden, ein Beispiel für meine bisherigen Ergebnisse.

    The biggest advantage to building a cluster is that clustering allows Hyper-V VMs to failover automatically in the event that something happens to a host server. The Hyper-V replication feature doesn't allow VMs to failover automatically; failovers have to be initiated manually.

    https://redmondmag.com/articles/2020/10/15/hyperv-replication-vs-two-node-cluster.aspx

    • Bearbeitet D_Khan Dienstag, 23. Februar 2021 06:09 Nachtrag
    Dienstag, 23. Februar 2021 06:06