Virtuelle Cluster - wohin mit der shared VHDX?

[Dunkelmann 96]

Moin,

 

ich habe hier einen Hyper-V Cluster unter 2012R2. Auf dem Hyper-V Cluster laufen einige VM Cluster (File, SQL, usw.). Die Umgebung wird per VMM 2012R2 verwaltet und per DPM 2012R2 gesichert.

 

Die virtuellen Clusternodes liegen auf unterschiedlichen CSV/LUN im iSCSI Backend. VM-Cluster-Node1=CSV1; VM-Cluster-Node2=CSV2 usw.

Aktuell nutzen die VM Cluster das iSCSI Backend als shared storage.

Ich möchte jetzt die VMs vom iSCSI Backend unabhängig machen und die iSCSI-Volumes in shared VHDX migrieren.

 

Eventuell sollen virtuelle Cluster später als Service über den VMM bereitgestellt werden - das steht derzeit aber noch nicht so hoch auf der Agenda.

 

Ich stehe nun vor der Frage:

Wohin mit den shared vhdx? :confused:

Ein zusätzliches CSV, nach Gutdünken auf die vorhandenen CSV verteilen?

Gibt es Erfahrungswerte oder Empfehlungen zu diesem Thema? Meine Suche war leider nicht so ergiebig.

 

Performance ist kein primärer Faktor. Es geht eher um die Service-Verfügbarkeit, Backup und die Option zur automatischen Bereitstellung.

[Doso 77]

Wir haben dann wohl eine recht ähnliche Umgebung. Auch wir haben da vor kurzem umgestellt. Auf eines der CSV und dort in einen extra Unterordner wie z.B. "SharedVHDx".

[Dunkelmann 96]

Danke. Kannst Du etwas zum Hintergrund des Vorgehens sagen?

Gab es konkrete Argumente für die Platzierung oder erfolgte die Platzierung nur nach Bauchgefühl?

[Dukel 454]

Es sollte ja kein Unterschied machen, wo die Datei liegt, ob es eine Shares oder keine ist.

Damit man es besser erkennt, kann man einen Ordner erstellen oder eine eigene LUN bereitstellen.

[Doso 77]

Im Technet zum Einsatz für Shared VHDx steht die Empfehlung, einen eigenen Ordner zu verwenden. Als ich einen Server mit Shared VHDx per SCVMM verschieben wollte, konnte ich das nicht da er das wegen den Shared VHDx nicht zugelassen hat.

[IT-Shrek 13]

Hallo,

Shared VHDX-Dateien unterliegen noch einigen Einschränkungen, wie z.B.:

 

- Keine Host Level Backups

- Kein Hot-Resizing

- Keine Storage Live Migrationen

 

Die Lage der VHDX-Datei sollte daher so gewählt werden, dass die o.a. Einschränkungen so wenig Probleme wie möglich bereiten, aber Backup und co trotzdem sicher gestellt sind.

Der Ablageort muss Shared Storage sein, also ein CSV oder ein SMB3 Share. Ein SMB3 Share ermöglicht die Nutzung clusterübergreifend, wenn du deinen Guest-Cluster über mehrere Host-Cluster verteilen möchtest.

Ein zusätzliches CSV ist dafür nicht erforderlich.

 

Beste Grüße,

Shrek

[Dunkelmann 96]

Ein SMB3 Share ermöglicht die Nutzung clusterübergreifend, wenn du deinen Guest-Cluster über mehrere Host-Cluster verteilen möchtest.

Ein zusätzliches CSV ist dafür nicht erforderlich.

 

Beste Grüße,

Shrek

Danke.

Noch ein Argument mehr, um das iSCSI Backend endlich durch einen SOFS zu abstrahieren :)

[DocData 85]

Danke.

Noch ein Argument mehr, um das iSCSI Backend endlich durch einen SOFS zu abstrahieren :)

 

Bevor du eine Lösung gegen eine andere Lösung austauscht, solltest du nicht nur die Nachteile der bestehenden Lösung ins Auge fassen, sondern auch die möglichen Nachteile der neuen Lösung. SOFS ist nett, hat aber, ähnlich wie shared VHDX, so seine Tücken.

[NilsK 2.934]

Moin,

 

Noch ein Argument mehr, um das iSCSI Backend endlich durch einen SOFS zu abstrahieren :)

 

wie DocData schon richtig sagt: SOFS ist nicht ohne Weiteres "besser" als iSCSI. Der Protokoll-Overhead ist eher noch ungünstiger. Ein SOFS ist in den meisten Implementierungen deutlich teurer als ein gutes iSCSI-SAN. iSCSI ist lang bewährte Technik mit viel Support-Know-how am Markt. Und so weiter - ich würde das nicht automatisch aufs Altenteil schicken.

 

Ich verweise dabei auch auf deine Signatur. ;)

 

Gruß, Nils

bearbeitet 22. Juli 2014 von NilsK

[Dunkelmann 96]

Ich habe noch etwas Zeit zum Sammeln von Pro und Contra Argumenten.

Das neue Storage Backend ist erst in 12-15 Monaten fällig. Planung und Produktsichtung sind gerade erst angelaufen. :cool:

 

Zwei zusätzliche Rackserver als SOFS für das vorhandene iSCSI Backend zur Überbrückung und zum Erfarungen sammeln kosten auch nicht die Welt. Wenns nichts wird, gehen die Server mit in unsere Testumgebung :D

[NilsK 2.934]

Moin,

 

sagen wir es so: Die produktiven SOFS-Installationen, von denen ich weiß, basieren nicht gerade auf den billigsten Servern. Wenn es Sinn ergeben soll, spricht man da eher von anspruchsvollen Dingen.

 

Gruß, Nils

[Dunkelmann 96]

Wenn ich mir so ein Beispiel anschaue, ist mir schon klar, dass es nicht ohne ausreichendes Budget geht.

http://www.aidanfinn.com/?p=15974

 

Es ist ja kein Fass ohne Boden. Es ist ein überschaubarer fünfstelliger Betrag, den ich im Zweifelsfall auch versenken kann.

Vielleicht sollte ich vorher noch eine Exit-Strategie ausarbeiten :D

[NilsK 2.934]

Moin,

 

oh, wenn das so ist, sollten wir mal telefonieren. :D

 

Gruß, Nils

[Doso 77]

Ich war immer der Meinung das ein SOFS als Ersatz für ein SAN dient, und nicht das man den dazwischen klemmt.

[NilsK 2.934]

Moin,

 

Ich war immer der Meinung das ein SOFS als Ersatz für ein SAN dient, und nicht das man den dazwischen klemmt.

 

hm ... "jein" ... ;)

 

Eigentlich soll ein SOFS durchaus das klassische SAN "ersetzen". Oder andersrum: Wer ein aktuelles SAN hat, wird vom SOFS recht wenige "harte" Vorteile haben.

 

Die Marketingstrategie von Microsoft sieht vor, dass man einen SOFS mit relativ "einfachem" Storage aufbauen kann (Storage Spaces). Derzeit wird man das aber noch nicht bzw. kaum zu vetretbaren Kosten hinbekommen, da müssen sich der Markt und die Produkte noch etwas entwickeln (oder besser: noch gehörig entwickeln). Bleibt derzeit eigentlich nur ein SOFS mit nachgeschaltetem "klassischem" Block-Storage - also mit einem SAN. Und da muss man dann schon ziemlich genau gucken, ob das wirklich Sinn ergibt.

 

Gruß, Nils