Storage Spaces Direct Volumes für iSCSI Target verwenden

[KorF 0]

@Dukel

Ich suche ja eine Möglichkeit S2D per iSCSI bereit zu stellen aber leider finde ich hier nicht wirklich was

[Dukel 454]

DAS geht ja eben nicht!

 

[KorF 0]

Wäre dann NFS noch eine Möglichkeit oder fällt das auch weg?

[mwiederkehr 373]

NFS ist für S2D bzw. Scale-Out File Server nicht unterstützt.

 

Aber was ist überhaupt das Ziel Deiner Arbeit? Einen Virtualisierungscluster zu bauen oder einen redundanten Speicher:

 

Falls Virtualisierungscluster, würde ich entweder Hyper-V Hyperconverged nehmen oder VMware mit einem iSCSI-Target ohne S2D, einfach auf einem einzelnen Server. In der Arbeit kannst Du dann beschreiben, dass man in der Praxis den Speicher anders aufbauen würde. Allenfalls, falls Du den Speicher in die Virtualisierungs-Hosts einbauen kannst, wäre VMware vSAN eine Option.

 

Falls Du einen verteilten Speicher bauen willst, wirst Du wohl entweder bei einer kommerziellen Software (SANsymphony) oder aber Linux (mit DRBD und Pacemaker) landen. Das ist aber evtl. zu viel für ein einzelnes Projekt (und es stellt sich die Frage nach der Praxisrelevanz).

[KorF 0]

Das Ziel meiner Arbeit ist es eine Testinstallation von S2D zu installieren und den Storage an ein System anzubinden, welches System das ist hab ich nicht definiert. Ich will kein Virtualisierungscluster bauen, sondern nur den Speicher den ich von S2D als Pool bzw. Volumes erstellt habe für ein anderes System bereit zu stellen, das vielleicht VMs Hostet oder sonst was. 

Aber wenn iSCSI & NFS nicht von S2D unterstützt wird, bleibt mir vermutlich nichts anders übrig als auf dem Cluster noch Hyper-V zu installieren.

[Dukel 454]

Dann passt deine Projektarbeit nicht.

S2D ist für Virtualisierung und nicht für File-Services. Dafür ist ein "einfaches" Storage Spaces.

 

https://learn.microsoft.com/en-us/azure-stack/hci/concepts/storage-spaces-direct-overview?toc=%2Fwindows-server%2Fstorage%2Ftoc.json&bc=%2Fwindows-server%2Fbreadcrumbs%2Ftoc.json

 

What is Storage Spaces Direct?

Storage Spaces Direct is a software-defined storage solution that allows you to share storage resources in your converged and hyperconverged IT infrastructure. It enables you to combine internal storage drives on a cluster of physical servers (2 and up to 16) into a software-defined pool of storage. This storage pool has cache, tiers, resiliency, and erasure coding across columns—all configured and managed automatically.

...

You can deploy Storage Spaces Direct on a cluster of physical servers or on virtual machine (VM) guest clusters. If deploying it on a hyperconverged cluster of physical servers, we recommend using Azure Stack HCI servers. To deploy Storage Spaces Direct as part of Azure Stack HCI, see Deploy the Azure Stack HCI operating system.

[mwiederkehr 373]

Wenn es darum geht, einen Cluster mit S2D zu bauen und den Speicher irgendeinem System zur Verfügung zu stellen, würde ich einen Scale-out File Server bauen und die Freigaben ein paar Clients zur Verfügung stellen. Dann wäre die Arbeit die Konfiguration von S2D, evtl. inkl. SSD-Cache, Benchmarks, Failover-Tests, Überwachung und Dokumentation der Wiederherstellung nach dem Austausch defekter Disks. Zusätzlich allenfalls noch einen kurzen Vergleich der Vor- und Nachteile mit anderen Systemen. Das wäre in der Schweiz im Rahmen einer Abschlussarbeit (zehn Tage Zeitbudget).

[KorF 0]

@mwiederkehr Das hört sich nach etwas an so wie ich es mir ursprünglich vorgestellt habe.

 

Hast du da irgendwie eine Anleitung dafür, wie das funktioniert?

[tesso 375]

vor 14 Minuten schrieb KorF:

Hast du da irgendwie eine Anleitung dafür, wie das funktioniert?

Genau das sollst du doch in deinem Projekt erstellen. 

[KorF 0]

@mwiederkehr Funktioniert es auch wenn ich keinen Scale-Out File Server sondern einen Fileserver for general use nehme und dann per NFS an VMware mounte, oder würdest du sagen lieber den Scale-Out File Server?

[tesso 375]

SOFS ist eni active/active Konstrukt. General use ein active/passive

[testperson 1.680]

Vielleicht fangen wir doch einfach mal vorne an: Wie lautet denn deine Projektarbeit bzw. was hast du da eingereicht und was ist genehmigt worden?

 

Hier jetzt von einer Technik zur anderen zu hüpfen und immer wieder andere, neue Ideen zu bekommen, ist in meinen Augen nicht zielführend. Generell wäre das auch ein Thema für deinen Betrieb und den dortigen Ausbildungsbetreuer.

[Weingeist 159]

Also ich verstehe nicht wirklich was Du genau tun musst, kannst oder sollst und was davon freiwillig ist und was nicht. Egal was die Aufgabe ist, alles in Verbindung mit Storage Spaces ist nicht 0815.

 

Nicht böse gemeint, aber aktuell sehe ich tendenziell schon ein Begriffsproblem oder ein Unverständis bei Dir welche Technik für was zuständig ist. Somit ist es eigentlich auch umöglich zu sagen wie man Dir helfen soll. =)

 

Unterstützugn kann ich Dir aber mal mit den Begrifflichkeiten und Hintergrundinfos geben, fange mal von vorne an:
Storage Spaces: Ist ein hochentwickeltes, sehr Crash-Resistentes Software-RAID. Allerdings ist das ganze nicht mehr im klassischen Sinn basierend auf relativ starren Discs, sondern das Kernstück ist ein Datenblock/Stripe welcher je nach den gewünschter Performance (Anz Discs pro Stripe - 1 bis X coluns) und Sicherheitsanforderung (Anz. Kopien - 1 bis 3) über die Disc(s) verteilt wird. Wenn Du mehr dazu erfahren willst, kann z.Bsp. ein paar alte Threads von mir hier suchen. Müsste ein paar Jahre her sein.

 

Storage Spaces Direct: Ist die Ausdehnung des Konzepts über mehrere Nodes hinweg. Soweit dürfte das klar sein.

 

Das ist das Fundament, also die Speicherung und die Bereitstellung von Datenblöcken zu definierten Kriterien für ein Volume. Im Gegensatz zu einer Disc bzw. Disc-Set auf einem klassischen Hardware-Controller oder Einsteiger SAN welches das Performance/Sicherheitskozept im Voraus festlegt und darauf dann die Volumes erstellt werden. (Etwas vereinfacht gesagt)

 

Der Denkfehler den viele machen ist, dass SOFS und Storage Spaces Direct das selbe sind bzw. zusammen verwendet werden müssen. Was aber so nicht stimmt. Storage Spaces Direct stellt "nur" die Plattform/Unterbau für die Datenblöcke/Volumes zu Verfügung, wer die Veröffentlichung des Volumes übernimmt, ist Storage Spaces Direct egal und zuständig dafür ist es auch nicht. Also das was normal die SAN macht. Ist quasi also auch schon etwas Hyperconverged zusammen mit einer Veröffentlichungs-Rolle (vergleichbar evtl. mit NetApp-Filer).

 

 

Danach kommen also die verschiedenen Varianten wie ein solches Sammelsurium an organisierten Datenblöcken als Volume veröffentlicht  werden und wer somit wie in der Lage ist, diese abzurufen, zu verändern, zu erstellen etc. Das erledigen dann die Cluster-Rollen welche für die Veröffentlichung zuständig sind.

 

Die Cluster Rolle welche die Veröffentlichung übernimmt, schert sich aus klassischer Sicht nicht um das WIE die Daten dahinter abgesichert sind, sie schaut nur, dass sie das gleiche Volume/Blöcke im Fehlerfall des Hosts über einen anderen Host zu Verfügung stellen kann. Sind die Speicher-Blöcke nicht mehr verfügbar, hat sie zwar ihren Job erfüllt, aber es ist trotzdem down. Normal ist das die vollständigem SAN-Ausfall, bei Storage Spaces halt wenn alle Nodes down sind.

 

Ein per NFS-Rolle/iSCSI Target oder "normalem" SMB-Fileserver zu Verfügung gestelltes Volume kann speichertechnisch über alle Nodes laufen, ist aber im Grunde punkto Zugriff ein klassisches Cluster im Aktiv/Passiv Modus. Also läuft der ganze Traffic eines Volumes über einen Node. Fällt dieser aus, übernimmt der nächste Node die Veröffentlichung der identischen Daten. Beim iSCSI Target wird das Volume als Block-Storage weitergegeben. Sprich das ganze File-Handling und somit auch die Pflege der Filetable wird weitergegeben and den Empfänger des Volumes. Ein Teil der Vorzüge von SP sind somit obsolet und man hätte wohl mehr Freude an einer klassischen SAN welche gleich Block-Storage veröffentlicht.

 

Ein Scale-Out-Filse-Server (SOFS) läuft mit den neuesten SMB Erweiterungen, Anbindung an ESXi zum aktuellem Zeitpunkt deshalb nicht möglich. Wie bereits andere kommunziert haben. Dieses Konstrukt läuft im Active-Active Modus. Die Last/Zugriffe kann über mehrere Nodes verteilt werden. Das ganze produziert für jeden File-Zugriff aber einen deutlich höheren Overhead als z.Bsp. normales SMB oder NFS, daher wird es eben aktuell auch nur für vDiscs und Datenbanken empfohlen weil da verhältnissmässig wenig Open/Close/Berechtigungsanfragen/resize stattfinden. Im Grunde spricht aber nichts dagegen einen SOFS als normalen hochverfügbaren Fileserver einzusetzen, wenn alle Clients SMB 3.0 unterstützten und man auch sonst ein paar Dinge in Kauf nimmt, die schlicht noch nicht umgesetzt sind (Weiss ich grad nimmer auswendig, manches davon wie Dedupe geht schon, manches nicht). Dem Konstrukt ist eigentlich egal ob die Files 2TB oder 1MB gross sind. Aber der Zugriff wird tendenziell langsamer sein. Nicht zwingend die Übertragung selbst, sondern das drumherum. Das arbeiten mit einer Access-DB ist mit sicherheit langsamer, das speichern eines Worddokuments wird vermutlich total egal sein. Verschieben von ganzen Ordnerstrukturen mit tausenden Files verursacht eine ziemliche Last. Handling mit grossen Files ist aus Ausfalltechnischer Sicht und der damit einhergehenden Arbeit das ganze wieder online zu bringen, kaum zu toppen. Auch für normale Clients.

Anmerkung: Ob SOFS Nicht-SP-Direct Volumes unterstützt kann ich nichtmal sagen, da nie probiert. Findet man aber sicher schnell raus in den Dokus oder mit Tests. Möglich das es notwendig ist, möglich, dass es unabhängig davon ist. Je nach dem wie eng die Layer verzahnt sind/entsprechende Prüfungen erfolgen. Ich tippe gefühlsmässig auf abhängig. Überlasse ich Dir nachzuforschen.

 

 

Auch das Caching geschieht über verschiedene Ebenen. Write/Read mittels der Tiers auf Poolebene (nicht im eigentlichen Sinne ein Cache,aber irgendwie schon), dem RAM als Read welches Windows sowieso benutzt (allerdings eben wirklich nur für sehr kleine Files von ein paar KB, die grenze kann man mit dem überschreiben von Sektoren herausfinden, Daten nicht mehr da, aber Windows liest die Datei noch korrekt, zumindest spätestens bis zum Reboot), sowie den Cluster-Cache welches zur Zeit die einzige Möglichkeit ist, RAM als schnellen Read-Cache für grössere Files zu Verfügung zu stellen. Dieser ist allerdings Hostbezogen (Keine Ahnung wie das technisch genau funktioniert in Verbindung mit SOFS, da blicke ich nicht ganz durch, tippe darauf, dass einfach der Cache des Host für den Client zuständig ist, via jenen man gerade zugreift, was es ineffizent machen könnte. Wäre noch zu untersuchen/erforschen, heute vielleicht in Dokus). Genau dieser Umstand macht das "normale" Storage Spaces auf einem Single-Node mit Magnetplatten ultralahm. Weil eben der RAM-Cache durch die Cluster-Rolle zustande kommt. Man bräuchte also eine Single-Node-Cluster um davon zu profitieren. Oft kann man aber mit SSD und NVMe gut leben, weil deren Latenz tief genug ist (Daher empfehle ich auch immer Enterprise-HDD's zu nehmen. Diese haben normal eine relativ gute Durschnitts-Latenz, das macht das schreiben und lesen insbesondere mit mehreren Discs pro Stripe/anz Columns auch ohne Cache schnell, weil immer die aktuell langsamste zählt. HDD ist konstant lahm, da konstant hohe Latenz.).

 

Die moderne Art der Verbindung zum SMB ist dann "SMB-Direct". Das lagert Lanspezifische CPU-Zyklen an hochspezifische LAN-Karten aus (RDMA). Notwendig ist das nicht, aber sehr vorteilhaft. Alles was in Verbindung mit Storage Spaces die Latenz senkt, hilft der Performance enorm. Salopp gesagt ist Storage Spaces aktuell auf Geideh und Verderb mit der Latenz verheiratet. Weil eben die Cache-Möglichkeiten aufgrund der Ausfallsicherheit im Vergleich zu klassischen SAN's mit Batterie/Kondi Puffer des RAM's eher Stiefmütterlich sind. Ist diese tief, rennt es, ist sie hoch, lahmt es. Möglicherweise hat hier Intel Optan RAM Abhilfe geschaffen oder wird es in Zukunft (nachforschen, aber wäre prädestiniert dafür). ;)

 

 

Mein persönliches Fazit

Der grösste Showstopper von SP direct ist dem hochverfügbaren, sehr modernen Konzept geschuldet. Damit das ganze überhaupt einen Sinn macht und man aus der Komplexität auch einen Nutzen hat und eben nicht nur Komplexität entsteht die im Fehlerfall eben seinen Dienst versagt, sollte man mind. 4 Nodes betreiben und die Sache entsprechend verstehen. Ist also eine ziemliche Schlacht an Hardware für eine Minimalkonfig und wird erst mit der Skalierung besser. Um zu verstehen warum das so ist, muss man etwas tiefer in die Funktionsweise von Storage Spaces und ReFs tauchen. Die Lektüren sind bei MS aber deutlich besser als vor 10 Jahren, da durfte/musste man das meiste selber herausfinden. Auch warum es optimal 4 Discs/stripe-sets (columns in SP) und nicht wie für RAID 1 deren zwei für einen 2-way Mirror (obwohl es geht!) und deren 5 für einen 3-Way Mirror auf einem Single-Node. Auch möchte man eher nicht direkt einen SOFS für die Clients und gleichzeitig für die VMs auf den gleichen Maschinen. Da würde man die unterste Ebene der Infrastruktur direkt ins LAN stellen. Tut man aber mit den iSCSI Adaptern der SAN auch nicht. ;)

 

So kommt man recht schnell zum Schluss, dass man produktiv entweder eine SAN nimmt oder sich sonst ein paar andere Gedanken machen muss, wenn man keine so grosse Infrastruktur unterhalten/finanzieren möchte (z.Bsp. Single Host mit Storage Spaces statt Hardware-RAID dafür ultraschnelles Recovery). Für den Spieltrieb gibts nicht viel cooleres als SP, zumindest für mich =)

 

 

Was man beachten sollte beim Entscheid

Mit Hyperconverged sind dann ein paar Spielereien möglich die entweder wirklich besser auf der Spielwiese bleiben oder wenigstens eine hervorragende Doku benötigen. Sonst lässt man es besser. Oft erfüllt ein deaktiviertes aber separat repliziertes DFS-Target für File-Services seinen Zweck genauso gut. Noch wichtiger ist, dass einem die Einfachheit der Assistenz-Konfiguration nicht über die Komplexität von Storage Spaces hinwegtäuschen soll. Eigentlich wie bei vielem, insbesondere bei Cluster. Die sind schneller am Ausfall beteiligt, statt dass sie davor schützen als einem Lieb ist wenn man die Infrastruktur vernachlässigt. Nur sind hier die Auswirkungen unter Umständen recht dramatisch, ähnlich einer sterbenden SAN. Mit dem Unterschied, dass die grossen Hersteller einen excellenten Support und Rep-Abteilung haben. Bei Storage Spaces sind die Experten sehr rar und sie zu finden ist ist auch schwierig.

 

 

Ein paar Tips zur Umsetzung

Insbesondere mit wenigen Discs/Hosts ist der Assistent tendenziell unbrauchbar (er macht stripes über zu viele Discs) und man muss selber via Powershell ran. Paradox, weil Grossumgebungen sicher mit Powershell erstellt werden. Man sollte recht genau wissen wie es funktioniert, sonst fällt einem Storage Spaces gerne auf die Füsse (wobei die Kontrollmechanismen von Windows 2022 heute viel besser sind als noch mit 2012). Wenn man aber genügend Zeit in die möglichen Fails investiert und versteht was SP daraus macht (speicher voll, strom weg, strom aller hosts weg, Festplatte kappen, Bad-Sectors erzwingen, DB-Write unter Last usw.), ist Storage Spaces ausfallsicherer als vermutlich jeder Hardware-Controller den man in eine 0815 Büchse steckt (von denen durfte ich in den letzten 10 Jahren so einige tauschen, für Magnet nehme ich die noch).

 

Dann noch die fast vergessenen Ärgernisse die heute noch, wenn auch abgeschwächt bestehen:

Der Tod von fast jedem Pool oder ReFs Volume ist übrigens Speicher der ausgeht. Das passiert schneller als einem Lieb ist und man geneigt ist anzunehmen, verursacht durch die Funktion die das Fileystem eigentlich schützen sollte. Insbesondere beim hantieren mit sehr grossen Files die verändert und wieder gespeichert werden, da immer erst die Daten neu geschrieben werden, dann die Metadaten aktualisiert und erst dann der Speicher der alten Kopie wieder freigegeben wird. Daher auch lieber gleichgrosse Platten verwenden, auch wenn man geneigt sein könnte einfach alles an Platten reinzuschieben was gerade so rumliegt. Da verliert man den Überblick über den effektiv freien Speicher für eine grosse Operation nicht. Das sollte man höchstens in grossen Pools und lieber single Hosts/testumgebungenm datengräber.

 

Das "auffinden" von defekten Festplatten erfordert ein Gehäuse welchse auch beim richtigen Slot "leuchten" kann. Hat man das nicht, hilft nur eine Doku. Sonst endet es böse. ;)

 

Ein (eigentlich sehr) wichtiger Bug war mit Version 2019 leider immer noch "schlimm", also nicht behoben. Nicht immer wird ein Mehrheitsentscheid erzwungen. Sprich hat man einen Three-Way Mirror, muss es nicht sein, das die zwei guten Sets das schlechte Set überstimmen. Sprich gibts im Set 1 einen unerkannten Bad Sector, heisst es leider nicht zwingend, dass SP dieses Set korrigiert und stattdessen den Wert der andern Zwei nimmt. Wovon man aber eigentlich ausgehen würde, wozu sonst mehrere Mirror und Prüfsummen. Gilt eigentlich auch beim 2-way, weil grundsätzlich sind meines Wissens Prüfsummen mit von der Party via den Metadaten, sprich SP wüsste eigentlich wenn ein Stripe inkosistent ist und könnte den Stripe von der Kopie lesen und diesen verwenden, wenn er OK ist. Die Wartungsjobs (Aufgabenplanung) erfüllen den Job zwar manchmal, aber dann ist es eventuell zu spät, da bereits gelesen und gecrashed. Manchmal erfüllen Sie ihn auch auch falsch. Wie es mit 2022 aussieht weiss ich nicht, produktiv vorgekommen ist es bei mir noch nicht nicht oder ich habe nichts davon bemerkt. Ist aber auch eher selten bei SSD's, wenn es vorkommt, ist sie meist eh am Ende. In der Testumgebung erzwingen war aber durchaus möglich. Mit 2022 habe ich die Tests noch nicht gemacht.

 

Zum Schluss: Für das testen ist wichtig wie das OS die Discs erkennt/markiert. Als physische Discs oder eben als Shared Disc. Eine Shared Disc kann man nicht einem Storage Spaces Direct Pool hinzufügen. Eine Phyische-Disc nicht einer Cluster-Rolle für die Veröffentlichung der Daten. Notfalls muss man das für Testumgebungen umbiegen.

 

Sorry wurde etwas länger, aber einkürzen bräuchte noch mehr Zeit, das überlasse ich Dir :-P