Server 2022: Kann endlich NFS auf ReFs Volumes -> Storage VMs unter ESXi

[Weingeist 159]

Hallo zusammen,

 

Für alle die NFS nutzen, da scheint nun mit 2022 endlich eine NFS Freigabe auf ReFs Volumes möglich zu sein. Darauf warte ich seit es Storage Spaces und ReFs gibt - also rund 9 Jahre

Scheinbar wurde die Zuordnungstabelle bei Windows-NFS auf 64bit erweitert oder ein Parser implementiert (noch keine Info dazu gefunden)

 

Interessant ist das für die Nutzung von Windows als Storage VM unter VmWare ESXi. Mir ist klar, das ist absolute Nische und manche sehen es als Gebastel, aber es hat für mich eben einige Vorzüge weshalb ich das in Kauf nehme dafür aber in den oberen Schichten 0815 habe. Da es zudem einfach zu Verwalten, nachzuvollziehen und zudem sehr extrem crashresistend ist (Stromausfälle, Festplattendefekte etc. ), ist es für mich mehr als verschmerzbar. Braucht nur etwas mehr CPU-Power bei hoher IO Last (für die virtuelle LAN-Karte der Storage VM), aber das ist eh selten das Problem in Kleinumgebungen.

 

- Windows und nicht Linux (KnowHow, einfache Anbindung von Zusatzsoftware, Backup, Rechteverwaltung etc.)

- Nutzung der Volumes auch auf anderen Servern, zbsp. als Backup-Ziel jedoch ohne das Windows weiss wo die Disk liegt sondern eben der HyperVisor (Einfacher Umzug der Volumes etc.)

- sehr robustes Dedupe auf Storage-Level

- Ausschalten von VMFS als Dateisystem das deutlich weniger Crahsresistent als ReFs/Ntfs ist und für RAID entweder Controller oder teure vSAN benötigt

- Keine teure SAN oder eher lausige NAS für Shared Storage und trotzdem Verwendung von hochwertiger Hardware möglich

- Lokales High-Speed Software RAID möglich (mit SSD/NVMe)

- extrem schnelles Recovery (Hauptproblem beim günstigen SAN's)

- Ultraschneller Datenaustausch zwischen Server und Clients die auf VDI basieren (selbst lausig programmierte Server/Client Software wird dank der extrem niedrigen Latenz rasend schnell, KMU-Chefs freut das, die stört eh jede Gedenksekunde )

 

Man kann natürlich auch gleich HyperV nutzen, aber manchmal braucht es VmWare und ich persönlich mag die Administration von ESXi deutlich lieber als von HyperV. Zudem setze ich gerne Horizon View sowie Teradici-Software ein und benötige öfter mal einen Lizenzserver der nur unter einer Linux-Appliance unter ESXi supported wird.

 

[zahni 552]

Sorry, aber einige der Stickpunkte müssen sich erst beweisen und brauchen eine fachliche Validierung. Wie kommst Du z.B. darauf, das VMFS weniger Crashresistent ist? Und warum sollte ich eine Storage-VM unter VMWare bereitstellen? Und wie schalte ich VMFS ab, wenn ich VMWare nutze? Die einzig mir bekannte Möglichkeit wäre die Nutzung von NFS.

 

Zitat

Keine teure SAN oder eher lausige NAS für Shared Storage und trotzdem Verwendung von hochwertiger Hardware möglich

??

Ist der Storage nicht immer der limitierende Faktor, egal was ich für ein Dateisystem nutze? 

 

 

[cj_berlin 1.312]

Moin,

dazu kann ich aus der Erfahrung mit unzähligen VMware Support-Calls, die meisten davon mit Storage-Anteil, nur eins sagen:

Solange sich in der unteren Zeile da nichts ändert, bleibt's Gebastel, was im Zweifel durch den Errichter (Dich) zu supporten ist.

[Weingeist 159]

@jberlin: Na klar muss ich das selber supporten. Mache ich seit vielen Jahren. Anfangs nur für mich, dann nur VDI, später dann auch Server. Weil es einfach zu gut und unproblematisch lief.

Windows Server mit durchgereichten Platten>Storage Spaces (Software RAID)>NTFS>NFS>ESXi. Bis dato hatte ich nur noch nichts zu supporten bzw. nur am Anfang weil ESXi plötzlich APD auf NFS geschoben hat unter starker Auslastung. War aber ein generelles NFS-Problem welches per Patch von VmWare gefixt wurde.

 

 

vor 3 Stunden schrieb zahni:

Sorry, aber einige der Stickpunkte müssen sich erst beweisen und brauchen eine fachliche Validierung. Wie kommst Du z.B. darauf, das VMFS weniger Crashresistent ist

Weil ich das selber getestet habe. ReFs kriegte ich nicht wirklich in die Knie und hat sich jeweils korrekt selber repariert - auch bei direkten Sektormanipulationen der Platten, On und Offline - . Festplatten ziehen, weiterschreiben, wieder rein. Strom weg etc. Nur vollaufen war und ist vermutlich immer noch ein Problem. Aber auch VMFS ist davon wenig bis gar nicht begeistert.

VMFS hat selber auch gar keine lokale RAID-Funktionalität wie die Storage Spaces. Das verteilte vSAN habe ich noch nie auf Herz und Nieren geprüft. Ebensowenig wie Storage Spaces Direct. Beide nur angetestet. Bei beiden ist mir die Materialschlacht zu gross. ;)

 

Bezüglich limitierender Faktor: Bei meinen älteren Systemen war das jeweils die CPU-Leistung. Da wird enorm viel für die virtuelle Netzwerkkarte verbraucht. Beim aktuellen Testsystem mit AMD Epyc habe ich den limitierenden Faktor noch nicht gefunden aber auch erst Quick/Dirty aufgesetzt. Entweder wird nicht alle CPU-Leistung für die Netzwerkkarte freigegeben oder die NVMe's sind zu lahm.

 

Und ich sage ja im Titel bereits: NFS mittels Storage VM... Gründe habe ich genannt. Ich sage ja, es ist Gebastel. Aber eines das excellent funktioniert. Für mich. Wer das auf Testsystemen auch machen möchte, kann es tun. Wer es nicht möchte, lässte es einfach bleiben. ;)

 

Ein Recovery von einer VM mit 25GB ist in knapp einer Minute durch. Läuft also zackig.

bearbeitet 23. August 2021 von Weingeist

[cj_berlin 1.312]

Wir haben einfach unterschiedliche Kunden  

[zahni 552]

vor 31 Minuten schrieb cj_berlin:

Wir haben einfach unterschiedliche Kunden  

Ich wäre einer davon. Ich bekomme schon beim Lesen der Lösung  Kopfschmerzen.

[Weingeist 159]

Immer wieder interessant wie etwas andere Ansätze erstmal verschrien werden bevor man sie genau prüft. Im Endeffekt ist es genau gleich gelöst wie es VmWare vor ein paar Jahren mit der Storage-Appliance gemacht hat oder wie es andere Anbieter nach wie vor als Alternative zu vSAN machen. Nur mit dem Unterschied, dass die Appliance Windows ist, welches nachweisbar sehr robust ist. Sowohl NTFS als auch ReFs und auch Storage Spaces. Alles bewährt und funktionstüchtig. Ob nun explizit dafür zertifiziert oder nicht. Da ist im Grunde nichts komplexes daran.

Es wurden auch jahrelang MS-Cluster, Exchange etc. auf VmWare betrieben obwohl MS den Segen extrem lange nicht offiziell dazu gab. Einfach weil es funktioniert hat und keinen Grund gab warum es nicht hätte funktionieren sollen. Schlicht weil es Software war, die nunmal funktioniert hat. Und Cluster sind komplexitätstechnisch in jeder Hinsicht eine andere Liga als eine Storage-Appliance!

 

Zumal die darunter liegende Hardware die ich verwende jeweils für VmWare zertifiziert ist. Hatte noch nie ein Problem mit dem VmWare Support und nahme ihn bezüglich View/Horizon schon öfter in Anspruch.

 

Ist klar das dies nichts für grössere Umgebungen ist. Aber für ein oder zwei Server funktioniert das gut. Sehr gut sogar. Die perfekte Aufstellung mit SAN oder deren zwei, Dual-Switches auf Storage und LAN Seite etc. kann da gar nicht sinnvoll finanziert werden, schon gar nicht in der gleichen Performance. Und wenn dies Ausfallsicherheit gebraucht wird, dann wird es auch finanziert und ist nicht mehr mein Gebiet.

 

Da ich immer gleiche Basis-System nehme und nur hochwertiges Material verbaue, habe ich die Systeme mit meinen Ersatz-Teilen wenn es eilt schneller wieder oben als die Hardware-Lieferanten selber die Teile am nächsten Tag liefern. Und wenn nicht so zeitkritisch, dann auch mal ohne Vertrag. Wäre dann Pech wenn mein Ersatz genau in dem Moment nicht vorhanden ist. Dauert es halt ein bis zwei Tage bis Ersatz da ist.

 

Windows Storage Spaces in Verbindung mit NFS traue ich jedenfalls mehr zu als fast allen Appliances die für den gleichen Zweck verkauft werden und teilweise zertifiziert sind. Einfach weil MS im Storage-Bereich sehr wenig Murks abliefert. Zumal ich mir mal fast eine Woche Zeit genommen habe um alle mir erdenklichen Szenarien für Ausfälle in Zusammenhang mit Storage Spaces in x-facher Ausführung zu simulieren. Selbst das Software-RAID aus der Windows-XP Zeit hat excellent funktioniert wenn man sich zwei kleinen Eigenheiten bewusst war.

Ich habe unter XP/2003 produktiv mit Software-RAID gearbeitet wenn das Budget Hardware nicht zuliess und noch richtig Geld kostete als Software-RAID noch mindestens 10 Jahre vollständig verschrien war. Performance war ein graus, aber zuverlässig waren diese immer.

 

Aber eben, jeder wie er mag. Ich sage immer es gibt verschiedene Wege nach Rom, nur die Ausrüstung sollte passen.

bearbeitet 23. August 2021 von Weingeist

[mwiederkehr 373]

Was mich dabei interessieren würde: Was machst Du bei Windows Updates? Alle VMs herunterfahren? Das ist aus meiner Sicht ein Hauptproblem von solchen Konstrukten. Bei einem SAN hat man einen Speicher, aber zwei Controller, bei dieser Lösung hat man einen "Controller" bzw. bräuchte zwei Server (und NFS mit Windows-Bordmitteln hochverfügbar zu machen wäre wohl auch nicht einfach). Ein MSA ist immer verfügbar, auch bei Updates. (Eine Ausnahme sind höchstens Firmware-Updates der Disks, aber die gibt es zum Glück so gut wie nie.)

 

Deshalb bevorzuge ich (ausser für Testumgebungen) "richtige" SAN. Wenn es günstig sein muss, kann auch ein Synology UC3200 eingesetzt werden. Das ist zertifiziert für Hyper-V und VMware (allerdings iSCSI, nicht NFS).

[Weingeist 159]

Update: Da dies ja selten Systeme sind die unter enormer Last stehen wo ein Single-Host-System überhaupt in Frage kommt bzw. problemlos ein Fenster gefunden wird wo wenig bis nix los ist, hält ESXi auch ein Update + Reboot der Storage-VM aus. NFS ist da nicht wirklich kritisch. Der Reboot dauert mit potenten SSD's/NVMe's keine Minute. Aber selbst wenn es etwas länger dauert ist das für die paar IO's absolut kein Problem. Timeout setzt man ja allgemein höher als mit physischen Maschinen. Der "normale" IO Stau bei ausgelasteten Maschinen im grossen Umfeld dürfte da deutlich höher ausfallen. ;)

 

Drehe die VM's aber Firewall-technisch sowieso komplett zu. Netzwerkadapter ist nur im Wartungsnetz. Haben also keinen Zugang ins normale produktive Netz. Wenn es mal nicht passt, bekommen sie halt kein Update. An der Base-Filter-Engine sowie Firewall wird seitens MS sehr selten innerhalb des gleichen Builds gepatched, weil das eines der wenigen Dienste sind, die MS wirklich komplett durchcheckt bevor sie freigegeben werden.

 

Wie gesagt, wenn es um Hochverfügbarkeit geht, ist das sowieso der komplett falsche Ansatz und eine völlig andere Preisklasse. Das Prinzip mit der Storage VM ist gut für ein erweitertes Single-Host-Prinzip. Sprich alles auf ein oder zwei Maschinen und Sicherung auf die Platten der jeweils anderen Maschinen + evtl. lokal (Auch hier der Vorteil von NFS, kann komplett mit Windows Bordmitteln erledigt werden wenn gewünscht und Kosten gespart werden soll). Klar hätte ich auch lieber überall eine super performante SAN, wenn möglich noch gesynct, aber das ist bei meinen Systemen aber so gut wie immer ausserhalb des Budgets und eigentlich auch der Notwendigkeit. Aber so kann ich halt auch bei kleinst-Umgebungen eine +- saubere Dienstrennung machen und auf schnelle und zuverlässige Speicher setzen. Das hilft mir mehr die laufenden Kosten tief zu halten und das ich keine ungeplanten Einsätze habe. Mein Recovery-Zeiten mit ~300-500MB/s bei VMDK's sind auf alle Fälle zackig. Und das Fenster macht man ja bekanntlich für den Worst-Case, also z.Bsp. Ausfall der Backplane. ;)

 

Mir macht beim dem Prinzip nur die Ransomware-Problematik Sorgen. Bei ner SAN hat man Hardware Snapshots die im schlechtesten Fall dem Stand eines Strom-Crashes entsprechen wenn wirklich unabhängig vom Netz (da keine Agents). Da muss ich das Konzept um etwas zusätzliches erweitern das Kostentechnisch nicht überbordet und einfach in der Handhabung ist.