Hyper-V 2 Node Cluster von FC auf SMB3.0 umstellen

[NilsK 2.934]

Moin,

 

also ... vielleicht solltest du, bevor du weitermachst, dann doch noch mal eine Aktualisierung deines Wissensstandes vornehmen. Hier nur ein paar Details aus diesem Thread:

• "eine LUN pro VM" galt, bevor es CSV gab
• CSV nutzt man nur, wenn ein Cluster an LUNs angebunden ist (FC, iSCSI, SAS)
• Bei solch einer Anbindung gilt als Faustregel "1 CSV pro Node", sofern der Cluster nicht mehr als ca. 8 Nodes hat
• Das Quorum-Modell legt der Cluster selbst fest, wenn man ihn lässt. Ob man eine Quorum-Disk braucht, sollte man anhand des geplanten Designs entscheiden.
• SMB 3.0 empfiehlt sich für Hyper-V nur, wenn es über einen Windows-SoFS bereitgestellt wird.
• Mal eben so "Berechtigungen setzen" geht in einem Hyper-V-System schnell nach hinten los

Und als wichtigster Punkt: Das Design macht man nicht nur vor der Installation, sondern sogar vor der Beschaffung.

 

Gruß, Nils

[NorbertFe 2.034]

Und als wichtigster Punkt: Das Design macht man nicht nur vor der Installation, sondern sogar vor der Beschaffung.

Du bist aber auch wieder böse. :o

 

Bye

Norbert

[CoolAce 17]

vielen Dank für die Infos, das Wissen stammt aus eine Hyper-V MOC Kurs für 2008 und beim 2012 wurde das nicht so explizit angesprochen.

Noch mal für die Info und im Grunde hat NilsK ja Recht mit seiner Aussage.

 

Zu einem Punkt hätte ich gerne noch eine Erklärung : SMB 3.0 empfiehlt sich für Hyper-V nur, wenn es über einen Windows-SoFS bereitgestellt wird.

Andere Hersteller schreiben ja rein das Sie das Supporten , warum genau ist deiner Meinung nach Windows-SoFS die beste oder einzige Lösung ?

bearbeitet 31. Oktober 2016 von CoolAce

[NilsK 2.934]

Moin,

 

nur der Windows-SoFS unterstützt alle Vorteile, die Microsoft für SMB 3.0 angibt. Den Implementierungen der Storage-Hersteller fehlen i.d.R. einige Funktionen, etwa beim Failover. Auch die Eignung für Shared-VHDX (kann für Gast-Cluster interessant sein) ist meist nicht gegeben. Anspruchsvolle Features wie TCP Multichannel oder RDMA findet man dort meist auch nicht.

 

Tendenziell würde ich solche Systeme so einsetzen, wie sie vom Design her gedacht sind. Ein klassisches SAN-System kann eben SAN am besten.

 

Gruß, Nils

[CoolAce 17]

Danke für deine zahlreichen Hinweise und die Unterstützung. :)  :thumb1:

[zahni 554]

Soweit ich weis bietet Microsoft hier Zertifizierungen für SMB 3.0 an. Aktuelle cDOT-Versionen ab 8.2 von Netapp sind beispielsweise zertifiziert und unterstützen alle SMB 3-Funktionen inkl. Failover zwischen den cDOT-Nodes, Offload, etc.

 

https://library.netapp.com/ecmdocs/ECMP1196891/html/GUID-3E1361E4-4170-4992-85B2-FEA71C06645F.html 

[NilsK 2.934]

Moin,

 

ja, das ist aber genau der Unterschied, den ich meine. Natürlich macht NetApp Failover, aber sie machen es anders als ein Windows-SoFS - zumindest als ich das letzte Mal genauer recherchiert habe, gab es etwa keine Resilient File Handles, die beim SoFS den größten Teil des Witzes ausmachen. Außerdem fehlen (oder fehlten zumindest "damals") die Clusterfunktionen, die man für Shared-VHDX braucht.

 

In der Summe war das Ergebnis (und das sehe  nicht nur ich so), dass SMB 3.0 auf Storage-Geräten durchaus nett ist, aber gerade für das Hyper-V-Szenario einen SoFS nicht ersetzt. Und wenn man schon die entscheidenden Vorteile nicht nutzen kann, dann spricht einiges dafür, das Storage in der Art einzusetzen, wie es ursprünglich gebaut ist.

 

Gruß, Nils