Fragen zu SOFS und Hyper-V

[Dunkelmann 96]

Moin,

 

ich versuche gerade, ein paar Storageszenarien für den nächsten Hardwarezyklus zu bewerten. Eine mögliche Variante ist ein SOFS.

Falls Funktionen nur mit VMM oder anderen System Center Produkten möglich sein sollten - kein Problem, SC ist im Einsatz.

Performance steht aktuell nicht an erster Stelle. Die Priorität liegt bei Verfügbarkeit und Migrationspfaden.

1. Können sich mehrere Hyper-V Cluster eine Freigabe auf dem SOFS teilen?
   Ist das empfohlen oder wird davon eventuell abgeraten? Gibt es Best Practice dafür?
2. Können VMs per Live Migration zwischen den Clustern verschoben werden oder auf eine höhere Hyper-V Version migriert werden, ohne dass die VHDX kopiert werden muss?
3. Jetzt zu den physischen Platten in den JBOD:
   Wenn Mirror oder Triple-Mirror mit zwei bzw. drei Shared SAS Enclosures eingesetzt wird, werden die Mirrorsets automatisch auf die Enclosures verteilt, so dass der Ausfall eines Enclosures tolleriert werden kann?
   Falls nicht automatisch, ist es manuell möglich?

Auch anderen Input zum Thema nehme ich gerne mit :)

[Doso 77]

1. Ohne mich jetzt mit SOFS auszukennen, würde ich alleine wegen der Übersichtlichkeit her von abraten. Ich bin ja schon beim umziehen von 30 VMs fast durcheinander gekommen bei den ganzen Ordnern und Servern die Teilweise gleich heißen, da würde ich nun nicht auch noch Cluster auf dem Storage mischen.

 

2. Ja. Mit Shared Nothing Migration, also VM aus dem Cluster rausnehmen, per Hyper-V Manager verschieben und dann im neuen Cluster wieder hochverfügbar machen. Evtl. geht es auch mit Clustering an - gibt hier einen Blog zum Thema, kA ob das auch bei SOFS so klappt: http://www.danielstechblog.de/virtual-machine-manager-live-migration-fehler-smb-3-0-storage/

bearbeitet 29. August 2014 von Doso

[Necron 71]

2. Ja. Mit Shared Nothing Migration, also VM aus dem Cluster rausnehmen, per Hyper-V Manager verschieben und dann im neuen Cluster wieder hochverfügbar machen. Evtl. geht es auch mit Clustering an - gibt hier einen Blog zum Thema, kA ob das auch bei SOFS so klappt: http://www.danielstechblog.de/virtual-machine-manager-live-migration-fehler-smb-3-0-storage/

Hi,

 

wenn der SCVMM im Einsatz ist, dann siehe meinen Blogeintrag. Ansonsten so wie Doso es beschrieben hat. Wobei man keine Shared Nothing Live Migration machen muss. Es wäre viel eher eine Live Migration. :)

 

Zu Punkt 1:

 

Ja, kann man machen.

[Dunkelmann 96]

Danke für die Antworten.

 

Bei Punkt 1+2 ging es mir primär um die Migration. Die Übersichtlichkeit ist egal - ob ein paar hundert VMs auf einem iSCSI oder einem SMB liegen macht für mich ersteinmal keinen Unterschied.

Wenn ich die VMs clusterübergreifend live migrieren kann, ohne dass die VHDX kopiert (=dubliziert) werden muss, hilft mir das bei der Kapazitätsplanung schon weiter.

 

Zu Punkt 3 habe ich in der Zwischenzeit auch etwas gefunden.

Um den Ausfall eines Enclosures zu tollerieren, muss der SOFS mindestens 3 Enclosures haben.

 

To use enclosure awareness with Storage Spaces, your environment must meet the following requirements:

    JBOD storage enclosures must support SCSI Enclosure Services (SES).
    Storage spaces must use the mirror resiliency type if you're using Windows Server 2012:
        To tolerate one failed enclosure with two-way mirrors, you need three compatible storage enclosures.
        To tolerate two failed enclosures with three-way mirrors, you need five compatible storage enclosures.

http://social.technet.microsoft.com/wiki/contents/articles/11382.storage-spaces-frequently-asked-questions-faq/rss.aspx#Enclosure_Awareness_Support_Tolerating_an_Entire_Enclosure_Failing

[Necron 71]

Drei JBODs sind pflicht für einen Scale-Out File Server, hatte die Frage zu Beginn leider überpflogen, egal ob Two-Way oder Three-Way Mirror. ;)

[DocData 85]

Hallo,

 

du schreibst:

 

Performance steht aktuell nicht an erster Stelle. Die Priorität liegt bei Verfügbarkeit und Migrationspfaden.

 

Bei Punkt 1+2 ging es mir primär um die Migration. Die Übersichtlichkeit ist egal - ob ein paar hundert VMs auf einem iSCSI oder einem SMB liegen macht für mich ersteinmal keinen Unterschied.

 

Ich halte das für brandgefährlich. Was sind ganz konkret deine Anforderungen? Übersichtlichkeit, also die Transparenz des Systems, ist gerade im Hinblick auf das Troubleshooting unverzichtbar.

 

Irgendwie drängt sich mir der EIndruck auf, dass es auf jeden Fall ein SOFS werden soll, egal mit welchen Vor- oder Nachteilen.

[Dunkelmann 96]

Irgendwie drängt sich mir der EIndruck auf, dass es auf jeden Fall ein SOFS werden soll, egal mit welchen Vor- oder Nachteilen.

Der Eindruck täuscht. Ich habe nicht vor, eine Lösung zu erzwingen.

Um das Für und Wieder besser abwägen zu können, muss ich mich argumentativ für eine Seite entscheiden; das war in diesem Fall der SOFS. Warum? Ganz einfach, jeder Anbieter erzählt wie toll seine Premium Storages sind. Somit ist die Position schon besetzt; außerdem spiele ich gerne des Teufels Advokat :cool:

 

Meine Anforderungen an die Storagelösung sind klar - auch in konkreten Zahlen - und definieren sich über Performance, Kapazität und Verfügbarkeit als Primärfaktoren.

Rackspace, Handling und Supportfähigkeit (durch den Hersteller und die interne IT) spielen neben den Kosten pro TB natürlich auch eine Rolle.

[Doso 77]

Ganz einfach, jeder Anbieter erzählt wie toll seine Premium Storages sind.

 

IBM wirbt ja ganz gerne mal damit das seine Einsteiger SAN super für Virtualiserung sind, auch mit Hyper-V. Haben sogar ein Whitepaper mit einer Referenz-Architektur, daran habe ich mich orientiert. SAN fällt aus, Techniker ist nach fünf Minuten der Meinung das unser Netzwerk schuld ist. Nachdem ich dann alles abgesteckt habe, und das SAN immer noch nichts tut gehen ihm die Ideen aus. Mehrere Techniker Besuche später geht das SAN wieder, nur um 2 Monate später wieder den Geist aufzugeben. Das Vorgänger SAN von Fujitsu hat alle paar Monate einfach mal so sein RAID zerlegt.

 

Ich kann dich also echt verstehen, wenn du da Alternativen suchst.  :rolleyes:

[DocData 85]

Um das Für und Wieder besser abwägen zu können, muss ich mich argumentativ für eine Seite entscheiden; das war in diesem Fall der SOFS. Warum? Ganz einfach, jeder Anbieter erzählt wie toll seine Premium Storages sind. Somit ist die Position schon besetzt; außerdem spiele ich gerne des Teufels Advokat :cool:

Und weil die Anbieter alle gerne erzählen wie toll ihr Produkt ist (was würdest du in der gleichen Situation machen?), schraubst du dir selber was zusammen? Das Rad neu zu erfinden ist selten sinnvoll. Weder technisch, noch betriebswirtschaftlich. Du gehst ja auch nicht hin und rührst dir die Farbe zum streichen der Wände selber zusammen, nur weil Brillux erzählt wie toll ihre Farbe ist. Genausowenig baust du dir deine eigene Heizung, nur weil du Vaillant doof findest. Infrastruktur, egal ob Server, Netzwerk oder Storage, sind heute Commodities. Und deswegen sollte man da eigentlich keinen Hirnschmalz in die Entwicklung einer eigenen Lösung stecken.

 

Meine Anforderungen an die Storagelösung sind klar - auch in konkreten Zahlen - und definieren sich über Performance, Kapazität und Verfügbarkeit als Primärfaktoren.

Rackspace, Handling und Supportfähigkeit (durch den Hersteller und die interne IT) spielen neben den Kosten pro TB natürlich auch eine Rolle.

Wenn ich den SOFS betrachte und dann "Handling" und "Supportfähigkeit" als Kriterien heranziehe, dann fällt das Ding durch. Was erwartest du? Das du es selber supporten kannst? Das ist vielleicht dein Wunsch, aber wenn man nur Lösungen beschafft, die man wirklich selber versteht und supporten kann, dann bist du eigentlich nur noch mit der Lösungssuche beschäftigt und gehst nicht deinem eigenen Job nach.

 

Was du machst ist mir nicht unbekannt. Ich habe einige Mandanten die genauso ticken. Einen hat das mal ziemlich in die sc***e geritten. Ich will dir den SOFS nicht madig machen. Aber die Position die du beziehst ("Premiumhersteller" bähh, selbst ist der Mann) ist für eine interne IT ziemlich grenzwertig.

[Daniel -MSFT- 129]

Und weil die Anbieter alle gerne erzählen wie toll ihr Produkt ist (was würdest du in der gleichen Situation machen?), schraubst du dir selber was zusammen? Das Rad neu zu erfinden ist selten sinnvoll. Weder technisch, noch betriebswirtschaftlich. Du gehst ja auch nicht hin und rührst dir die Farbe zum streichen der Wände selber zusammen, nur weil Brillux erzählt wie toll ihre Farbe ist. Genausowenig baust du dir deine eigene Heizung, nur weil du Vaillant doof findest. Infrastruktur, egal ob Server, Netzwerk oder Storage, sind heute Commodities. Und deswegen sollte man da eigentlich keinen Hirnschmalz in die Entwicklung einer eigenen Lösung stecken.

 

Nur mal als Anmerkung am Rande: Storage Spaces sind entwickelt worden, weil wir uns für Azure & Co. genau angesehen haben, welchen Mehrwert SANs liefern und was 15k Server-Festplatten im RAID-Verbund für das Preis-Leistungsverhältnis bedeuten. Das Ergebnis war, dass die Serverkosten um 40% und der Stromverbrauch um 15% sinken, wenn wir auf klassische RAID-Controller, SANs, 15k HDDs, etc. verzichten und intelligentere Lösungen bauen in Kombination von HDD+SSD. Die Ausfallsicherheit wandert zum großen Teil von der Hardware in die Software. Das gleiche im Netzwerkbereich. Vergiss die megakomplexen Switcharchitekturen. Die Switches sind nur noch Connectoren, das Netzwerkdesign erfolgt in Software ausserhalb des Switches. RDMA über 10G Ethernet statt FiberChannel. Der Trend zu Software-defined storage und Software-defined Networking zeigt, wie sich hier dramatisch Kosten senken und die Flexibilität erhöhen lassen. 

 

Siehe zum Beispiel das Provide cost-effective storage for Hyper-V workloads by using Windows Server und das Provide cost-effective storage for Hyper-V workloads by using Windows Server: planning and design guide.

 

'I do not believe you can do today's job with yesterday's methods and be in business tomorrow.' - Nelson Jackson

 

Have fun!

Daniel

[Dunkelmann 96]

Wenn ich den SOFS betrachte und dann "Handling" und "Supportfähigkeit" als Kriterien heranziehe, dann fällt das Ding durch. Was erwartest du? Das du es selber supporten kannst? Das ist vielleicht dein Wunsch, aber wenn man nur Lösungen beschafft, die man wirklich selber versteht und supporten kann, dann bist du eigentlich nur noch mit der Lösungssuche beschäftigt und gehst nicht deinem eigenen Job nach.

Beim Handling steht es in meinem Szenario unentschieden.

Der SOFS hat bei der Bereitstellung von Storage für die Hyper-V Cluster und bei der System Center Integration die Nase vorn.

Beim Handling von Platten (bzw. SSD), RAID Arrays und Volumes gewinnt das klassische Blockstorage.

 

Die Supportfähigkeit ist für mich aktuell ein klares Negativ-Kriterium des SOFS. Inhouse Support ist für uns nur sinnvoll möglich, wenn die Einsparungen bei der Hardware und der Verzicht auf Herstellersupport, zusätzlich notwendige Planstellen gegenfinanzieren.

Momentan ist der break even für zusätzliche Planstellen noch nicht erreicht.

Auf externen Support eines Systemhauses zu setzen, ist keine Alternative. Endweder gibt es qualifizierten Herstellersupport oder die notwendige Kompetenz inklusive Redundanz beim Personal wird intern vorgehalten.

 

Was du machst ist mir nicht unbekannt. Ich habe einige Mandanten die genauso ticken. Einen hat das mal ziemlich in die sc***e geritten. Ich will dir den SOFS nicht madig machen. Aber die Position die du beziehst ("Premiumhersteller" bähh, selbst ist der Mann) ist für eine interne IT ziemlich grenzwertig.

Am Ende des Tages ist es mir egal, woher mein Storage kommt. Es muss den Anforderungen genügen und bezahlbar sein.

An vielen Premiumanbietern stört mich der Vendor Lock In und dass ich häufig Features mit kaufen muss, die ich nicht benötige.

 

Wie es der Zufall will, habe ich heute Vormittag meine Anforderungs- / Lösungsmatrix aufgebaut.

Das klassische Blockstorage hat in meinem Szenario erstaunlich deutlich gewonnen.

bearbeitet 3. September 2014 von Dunkelmann

[DocData 85]

 

 

An vielen Premiumanbietern stört mich der Vendor Lock In und dass ich häufig Features mit kaufen muss, die ich nicht benötige.

Und den Vendor Lock-In hast du bei einem SOFS nicht? Wahrscheinlich genausowenig, wie z.B. bei DataCore.  :rolleyes: 
 

[Dunkelmann 96]

 

Und den Vendor Lock-In hast du bei einem SOFS nicht? Wahrscheinlich genausowenig, wie z.B. bei DataCore.  :rolleyes: 

 

Den Vendor Lock In bei Microsoft habe ich an vielen Stellen. Da käme es auf einen weiteren Service nicht mehr an.

 

 

Off-Topic:

Auch wenn es jetzt etwas vom Thema abschweift.

Langfristige strategische Entscheidungen sind nicht immer rein technisch oder wirtschaftlich motiviert. Sie haben oftmals auch eine politische Dimension.

Bevor Du mir leichtfertige Planung unterstellst oder mit 'Rolling Eyes' antwortest, solltest Du sicher sein, das gesamte Bild zu kennen.

 

over and out

[DocData 85]

Langfristige strategische Entscheidungen sind nicht immer rein technisch oder wirtschaftlich motiviert. Sie haben oftmals auch eine politische Dimension.

 

Das brauchst du mir nun wirklich nicht sagen. Aber die Art und Weise wie du argumentierst und was du schreibst lässt einen anderen Rückschluss zu. Dafür mache ich den Job schon zu lange und dafür habe ich zu viele Mandanten erlebt.

[Necron 71]

Bitte bleibt beim Thema. :)