WinFuture-Forum.de: Wie muss ich einen 2 Knoten Storage Space Direct Hyper-V Cluster ohne - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Windows Server
Seite 1 von 1

Wie muss ich einen 2 Knoten Storage Space Direct Hyper-V Cluster ohne


#1 Mitglied ist offline   SirNibo 

  • Gruppe: aktive Mitglieder
  • Beiträge: 55
  • Beigetreten: 06. August 14
  • Reputation: 0

geschrieben 23. Juni 2019 - 15:59

Hiho,

Wie muss ich einen 2 Knoten Storage Space Direct Hyper-V Cluster ohne AD erstellen das er weiterläuft wenn ein Knoten ausfällt?

Mein Testumgebung sieht folgendermaßen aus.

Windows 10 Hyper-V host
2x 2016 Hyper-V Server Vms mit jeweils 3 Platten (1x System, 2x Cluster)
1x 2016 SCSI Server für das Quorum

Der Cluster SPeicherpool besteht aus den 2x2 Cluster Platten, der als CSV läuft
Der Failovercluster mit der Test Hyper-V Maschine läuft auch.
Aber sobald ein Knoten weg ist, ist das CSV nicht mehr erreichbar und die VM ist nicht mehr erreichbar.

Ich dachte bei einem SD2 2 Knoten Cluster kann ein Knoten wegfallen und das ganze läuft dann noch weiter.

Dieser Beitrag wurde von SirNibo bearbeitet: 23. Juni 2019 - 16:00

0

Anzeige



#2 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.681
  • Beigetreten: 20. Juli 07
  • Reputation: 1.075

geschrieben 23. Juni 2019 - 18:47

Stell am besten eine ungerade Anzahl von Knoten in den Cluster. Spart das Quorum und Du hast nicht das Problem, daß Dir der Cluster aus Versehen in zwei zerfällt.

Und dann ist entweder Deine Beschreibung mißverständlich oder aber Du hast ein Architekturproblem. Hier mal ein Modell, wie man es machen könnte:

Host A: storage.test.lan
Hält die Daten der VM. Sollte ein eigenständiger Cluster sein und mit 10G oder mehr angebunden sein, aber das ist für Testumgebung natürlich erstmal Nebensache.

Host B: vm-host.test.lan
Das ist der Failovercluster, hier bestehend aus node-a.test.lan, node-b.test.lan und node-c.test.lan .

node-*.test.lan sind jeweils Windows Server mit HyperV-Rolle oder in HyperV-Edition, verbunden über ein dediziertes Netzsegment, welches auch nicht rausgeroutet wird. Niemand außer dem zuständigen Personal erhält Zugriff auf node-* .


Und dann gibt es da noch service.test.lan. Das ist die VM, die den hochverfügbaren Dienst bereitstellen soll. Anspruch ist, daß service.test.lan möglichst ständig verfügbar ist.


Dazu besteht der Datenspeicher von service.test.lan aus (mindestens) zwei Teilen:

(V) Das OS plus die installierte Anwendung plus soweit zutreffend alles das, was in den RAM geladen wird und damit einen flüchtigen Zustand hat.
Das zerfällt nochmal in Dateidaten (VF) und Arbeitsspeicher (VR).

(NV) Statische Daten. Alles das, was NICHT ständig im RAM geladen ist (sein muß) und was damit KEINEN flüchtigen Zustand hat (haben muß).

Schmiert die Service-VM ab, ist V weg und NV noch da.

NV fliegt daher raus in via NAS oder via SAN extern angebundenen Speicher.
V bleibt direkt angebunden (DAS) und muß gesondert berücksichtigt werden.

In der VM (service.) haben wir demnach C:\ für das OS als loktalen Datenträger und D:\ oder sonstwas als Freigabe, iSCSI-Target, weiß der Geier.

NV interessiert ab sofort nicht mehr. Es ist ggfs. Aufgabe des Storagesystems, NV-Daten verfügbar zu halten.


Eins unter service. drunter liegen die Knoten node-* und im Verbund der Cluster vm-host. Das ist logisch betrachtet EINE Maschine. Entsprechend müssen alle Regeln für EINE Maschine betrachtet werden. Daher das CSV, weil mehrere Maschinen nicht ein Volume einbinden können.

Entsprechend haben wir jetzt die Datendatei für V, den flüchtigen Teil des Datenbestands für service. Fällt V aus, ist die Maschine tot. Ergo darf es nicht ausfallen und wir müssen es "hochverfügbar" machen, ie. alle Knoten in vm-host müssen zu jeder Zeit Zugriff auf den "jetzigen" Stand von V haben.

Kopieren geht nicht. Das dauert viel zu lange.

Deshalb fliegt V raus und runter von den Clusterknoten. Die HyperV-Installation der Knoten referenziert die VM-Konfiguration stattdessen vom Storage, zB als \\storage\service\osdisk.vhdx, welche wiederum nur eine von zwei Disks für ein Raidset sein könnte. Oder es wird als CSV eingebunden. In jedem Fall hält das Storagesystem die Daten, *nicht* die FO-Clusterknoten.

Dasselbe gilt für den RAM. Der ist aber inhärent problematisch, weil er *schnell* sein muß. Er läßt sich zwar virtualisieren, aber jede nichtflüchtige Speicheroption für RAM ist langsamer als flüchtige. Theoretisch könnte man virtuellen RAM per 100GBits Netzwerk anbinden und auf 100Gbits+ Storage halten, aber irgendwer muß das ja auch noch bezahlen.

Option zwei wäre, RAM halt mit den verfügbaren Ressourcen dateibasiert anbinden. NVMe SSDs wären hier eine Option fürs Backend. Dann ist die Frage, ob service. noch zufriedenstellend läuft.

Und Option drei ist, den flüchtigen Speicher zu ignorieren. Dann isser eben weg, müssen wir mit leben. An der Stelle sollte klar sein, daß service. unter solchen Umständen KEINE in-memory Datenbank sein kann. :wink:


Wir haben daher drei logische Geräte.
1 - Die Storage, selber ein Cluster.
2 - Den FO-Cluster, der den Service bereitstellt.
3 - Den Service selber in seiner VM.



Fällt 1 aus, ist das gesamte Konstrukt tot. Deshalb ist 1 selbst hochverfügbar bereitzustellen.
Fällt 2 aus, ist der Service weg. Deshalb ist 2 ein zweiter dedizierter Cluster unabhängig von 1.
3 kriegt von irgendwelchen Redundanzen oder HA nichts mit. Deswegen kann man 3 auch als Genericum verstehen. Was 3 bereitstellt ist egal, 1 und 2 kümmern sich darum, daß 3 verfügbar bleibt und jede weitere "3" die durch 2 bereitgestellt wird ist identisch abgesichert.



Die Knoten des FO-Clusters benötigen keinen Datenspeicher. Wenn Knoten die Dateidaten der VM halten und ausfallen, dann ist der Service natürlich weg.


Ergo:

- Eine Storage bauen, gerne für Testzwecke als VM, auch wenn das vermutlich ziemlich langsam werden wird.

- Den FO hast Du ja schon. Dort die Knoten so konfigurieren, daß sie die VHDX für den Service von der Storage holen. Note, das wird virtualisiert auf nur einem Host nochmal langsamer. SSD im Backend ist *dringend* anzuraten, idealerweise als NVMe.

- Der Service kann vermutlich so bleiben, außer Du schiebst nichtflüchtige Daten auch durch die FO-Clusterknoten. Den Umweg könntest Du rausnehmen und nichtflüchtige Daten als iSCSI-Target oder als Freigabe direkt vom Storage einbinden.


Wenn jetzt die Storage abschmiert, dann ist der Service immer noch tot.
Wenn einer der Clusterknoten abschmiert, dann kommt es drauf an, ob dieser grad den Service bereitgestellt hatte. Wenn nicht, dann passiert natürlich auch nichts, aber wenn doch, dann verhält sich der Service wie "Resetknopf gedrückt/Stecker gezogen" und wird (auf einem anderen FO-Clusterknoten) neugestartet werden.


Und zu guter Letzt ein Hinweis: Der Aufwand ist prinzipiell nur dann nötig, wenn der bereitgestellte Service nicht selbst clusterfähig ist. Ansonsten kann man einfach den Dienst in Clusterkonfiguration bereitstellen und hätte beispielsweise wsus-a, wsus-b und wsus-c als Knoten für einen imaginären WSUS-Cluster, der aus nicht näher benennbaren Gründen ständig verfügbar sein muß und keinesfalls ausfallen darf.
(Ein Storagesystem braucht man aber trotzdem.)
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0