Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
Dunkelmann

Virtuelle Cluster - wohin mit der shared VHDX?

Empfohlene Beiträge

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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".

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
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 :)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

  • Like 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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 von NilsK

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×