Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsNVMe-RAID auf Xeon: Intel VROC wird doch nicht eingestellt
Intel hat nun bestätigt, dass die angekündigte komplette Einstellung des Supports für VROC-Software (Virtual RAID on CPU) ein Fehler gewesen ist. Die Meldung sei schlicht vorschnell publiziert worden. Jetzt folgt also die Kehrtwende: Die Xeon-CPUs werden weiterhin VROC unterstützen. Das gilt auch für Sapphire Rapids.
Bessere Latenzen und außerdem Kosten Einsparung.
Wieso noch einen zusaätzlichen chip kaufen? Warum mehr Leitungen legen, wenn doch integriert?
Vielleicht nicht so relevant bei den einzelnen Usern, aber in Rechenzentren oder Forschungseinrichtungen sind das schon eneorme Einsparungen...
Software-RAID hat ganz generell sehr gute Leistung.
Man ist flexibler, kommt näher an die Hardware - schonmal bei einem Blackbox-RAID einfach nur smartctl -t long auf einer verdächtigen Platte versucht? - und meist ist es auch noch performanter. Zum Arbeiten reicht es wenn man mit mdadm umgehen kann, mit den lvm-tools wird es dann richtig Oberklasse.
Viele "Hardware-RAIDs" sind ausserdem LAUSIG gewartet. Die Verwaltungsoberfläche ist manchmal nur klickibunti und kann nix oder ist gleich geradeheraus fehlerhaft, lahm und unerträglich. Und anscheinend machen sich die Hersteller einen Spaß daraus die RAIDs mit künstlichen Grenzen zu kastrieren - ich kann schon garnichtmehr mitzählen wie oft ich in ein 1TByte-Limit, 2TByte, 4, 8, 16, 32 uswusf gerumpelt bin. Im Prinzip lautet die Logik "wir unterstützen sowieso nur Konfigurationen die wir selber komplett verkauft haben und wenn wir maximal 5x2TByte anbieten müssen wir 16TByte auch nicht unterstützen.
Sicher, es gibt Obergrenzen. Kein Mensch macht Software-RAID um ein externes 24-Bay-RAID anzusprechen.
Aber um mal eben 2-12 Laufwerke in einem Tower anzubinden - gibt nix besseres.
Je nach Anwendungsfall ist die Leistung einfach nur abgrundtief pervers. Weka Distributed Filesystem benutzt das z.B. bei Ryzen in Kombination mit mehreren Nvidia A100. Bei Linus Tech Tipps haben die einen Server damit aufgesetzt
HW-Raids sind oftmals teurer, langsamer, gruslig implementiert.
Software Raids müssen einmal durch eine o. mehrere Schichten des Betriebssystems (Treiber, die Implementierung des SW-Raids) und sind dann der Ressourcenverwaltung des OS unterworfen. Da die Raidfunktionalität vom arbeitendem OS abhängt, kann (ohne Umwege) nicht vom Raid gebootet werden.
VROC läuft etwas näher an der Hardware, anstatt die Abstraktionsschichten des Betriebssystems zu nutzen, läuft NVMe und Organisation direkt auf der CPU, ebenso wie die Ressourcenverwaltung. Das erlaubt in der Theorie bessere Latenzen und etwas effizienteres Arbeiten. Auch ist es möglich, dass das Raid aktiv ist, bevor ein OS gestartet ist, daher man kann vom Raid booten.
Ohne es genauer zu wissen, aber mir scheint es zu offensichtlich, als dass man es nicht so nutzen würde. Wenn die CPU sich direkt um Raids kümmert, wird man wahrscheinlich NVMe-oF direkt aufs Raidcluster machen können. Da wäre Imho richtig was an Latenzen zu gewinnen, wenn man da Raids nutzen kann, ohne am Netzwerk- und Raidstack des OS vorbei muss.
Crass Spektakel schrieb:
Sicher, es gibt Obergrenzen. Kein Mensch macht Software-RAID um ein externes 24-Bay-RAID anzusprechen.
Raid Arrays aus 24 (aktiven) Laufwerken zeigt entweder, dass da jemand nicht überschlagen hat, was das für die Ausfallwahrscheinlichkeit bedeutet, oder hat sehr spezielle Probleme. Und nimmt irgendwer, der 19" Einschübe nur für Laufwerke nutzt noch irgendwas Anderes als reine SDS Lösungen?
Software Raids müssen einmal durch eine o. mehrere Schichten des Betriebssystems (Treiber, die Implementierung des SW-Raids) und sind dann der Ressourcenverwaltung des OS unterworfen. Da die Raidfunktionalität vom arbeitendem OS abhängt, kann (ohne Umwege) nicht vom Raid gebootet werden.
VROC läuft etwas näher an der Hardware, anstatt die Abstraktionsschichten des Betriebssystems zu nutzen, läuft NVMe und Organisation direkt auf der CPU, ebenso wie die Ressourcenverwaltung. Das erlaubt in der Theorie bessere Latenzen und etwas effizienteres Arbeiten. Auch ist es möglich, dass das Raid aktiv ist, bevor ein OS gestartet ist, daher man kann vom Raid booten.
Das ist sehr nebulös und klingt eher nach einem Werbespot.
Piktogramm schrieb:
Ohne es genauer zu wissen, aber mir scheint es zu offensichtlich, als dass man es nicht so nutzen würde. Wenn die CPU sich direkt um Raids kümmert, wird man wahrscheinlich NVMe-oF direkt aufs Raidcluster machen können. Da wäre Imho richtig was an Latenzen zu gewinnen, wenn man da Raids nutzen kann, ohne am Netzwerk- und Raidstack des OS vorbei muss.
Software Raids müssen einmal durch eine o. mehrere Schichten des Betriebssystems (Treiber, die Implementierung des SW-Raids) und sind dann der Ressourcenverwaltung des OS unterworfen. Da die Raidfunktionalität vom arbeitendem OS abhängt, kann (ohne Umwege) nicht vom Raid gebootet werden.
Allgemein ist VROC nichts anderes als ein Fake-Raid, was die Nachteile von (klassischem) SW Raid und HW Raid kombiniert: Ist von HW abhängig, aber hat u.a. durch das Fehlen einer BU-Batterie Write-Hole Probleme etc.
"Klassisches" RAID ist in Zeiten von immer größeren HDDs (und SSDs) eh immer mehr auf dem Rückzug. Moderne Dateisysteme wie ZFS sind hier deutlich effizienter. Schon alleine, weil die Raid-Schicht "weiß", wo welche Daten liegen, außerdem helfen nur Checksummen (wie sie von ZFS etc. verwendet werden) gegen Bit-Rot. Bei einem klasssichen Raid ist es bei zu vielen teildefekten HDDs noch nichtmal einfach herauszufinden, welche Dateien jetzt konkret kaputt sind. Und das Write-Hole Problem wird durch COW effizient umgangen. Auch ist man dort wesentlich flexibler bzgl. der Frage, welche Daten wie redundant gespeichert werden sollen.
"oft" ist keine Kategorie, auf die ich irgendwas geben würde. Grundlegend sind write holes ein Problem bei jedem Raid, welches Paritäten berechnet. Die Frage ist ob und wie man damit umgeht. Das Verhalten und Mitigations bei typischen (Linux) Softwareraids ist dokumentiert. Was an der Stelle eher problematisch ist, dass das Verhalten bei etablierten Anbietern für professionelle HW-Raidcontroler in ihren Dokumenten da nicht drauf eingehen. Was nicht bedeutet, dass das Problem durch Nichterwähnung einfach weg geht, sondern dass man als Anwender da in undokumentiertes Gebiet rennt.
Und da es hier ja um Intel geht, deren Marketing ist oftmals ja wirklich viel Blendwerk. Die Sprechen das Problem samt Lösung an: https://www.intel.com/content/www/us/en/support/articles/000057368/memory-and-storage.html
Naja und wenig verwunderlich, Journaling wird genutzt (wie bei ZFS und bedingt mdadm und zukünftig wohl auch BTRFS).
foofoobar schrieb:
Das ist sehr nebulös und klingt eher nach einem Werbespot.
Wieso nebulös? Die Treiber vom Betriebssystem hängen wie alle andere Software auch am Scheduler des Betriebssystems und durch die technisch sinnvolle Trennung verschiedener Schichten an Treibern gibt es Latenzen. Die sind in den meisten Fällen nicht sonderlich groß, es läppert sich aber.
foofoobar schrieb:
Warum will man am OS vorbei Netzwerk und RAID machen wollen?
Weniger Latenzen, geringer Latenzen, minimierte Latenzen, absoluter Durchsatz im Bereich >100GBe, weniger CPU Overhead und damit geringere Kosten bei Anschaffung und Betrieb der Storagecluster.
Siehe auch: https://en.wikipedia.org/wiki/NVMe#NVMe-oF
Hatte ich erwähnt, dass das senken von Latenzen hier recht interessant ist?
Ergänzung ()
mifritscher schrieb:
Vernünftige OSe haben kein Problem, von einem SW-RAID zu booten. Genauso wenig wie mit beliebigen Kombis aus [BIOS, UEFI] und [MBR, GPT] zu booten...
Jain, bei reinen SW-Raids braucht es besagte Umwege. Das (U)EFI weiß ja nichts vom SW-Raid, wenn von lokalen Laufwerken gestartet werden soll, kann das EFI einen Bootloader nur von einem einzelnem Laufwerk laden. Wenn der Bootloader, also die erste Softwareschicht dann die Raid Arrays ansteuern und davon das OS läd, ist es eben schon minimal anders als bei einem HW-Raid bzw. Vroc wo der Bootloader direkt vom Array kommen kann.
mifritscher schrieb:
Allgemein ist VROC nichts anderes als ein Fake-Raid, was die Nachteile von (klassischem) SW Raid und HW Raid kombiniert: Ist von HW abhängig, aber hat u.a. durch das Fehlen einer BU-Batterie Write-Hole Probleme etc.
"Klassisches" RAID ist in Zeiten von immer größeren HDDs (und SSDs) eh immer mehr auf dem Rückzug. Moderne Dateisysteme wie ZFS sind hier deutlich effizienter.
Und dann gibt es Weirdos, denen Dateisysteme zu ineffizient und langsam sind, und die ihre Daten einfach direkt auf dem Laufwerk/Array adressieren wollen..
mifritscher schrieb:
Und das Write-Hole Problem wird durch COW effizient umgangen.
COW allein hat damit recht wenig zu tun. Das ist eher ein Ding der Paritätsberechnung und unvollständig geschriebener Blöcke, ohne dass bekannt ist, welcher Block defekt ist. Datapart1 + Datapart2 + Parityblock, mindestens ein Block ist defekt, das ist feststellbar, aber es ist nicht feststellbar, welcher Block. Ohne ein Journal und zusätzlicher Checksummen kann das Problem nicht gelöst werden.
Edit: Also vielleicht zur Klarstellung. COW so wie es ZFS implementiert sorgt für gescheites Checksumming. Grundsätzlich kann man COW aber auch anders implementieren (ja ich schau dich an BTRFS )
Software-RAID hat ganz generell sehr gute Leistung.
Man ist flexibler, kommt näher an die Hardware - schonmal bei einem Blackbox-RAID einfach nur smartctl -t long auf einer verdächtigen Platte versucht? - und meist ist es auch noch performanter. Zum Arbeiten reicht es wenn man mit mdadm umgehen kann, mit den lvm-tools wird es dann richtig Oberklasse.
Lausig die Realität bei Soft-RAID, wenn ohne direkte Anbindung an die CPU Daten mehrfach durch Busse übertragen werden: Laufwerk, ggf. Controller, ggf. Southbridge/Chipsatz, Arbeitsspeicher, CPU und zurück. Noch dazu RAID5/6, und die Kiste wird langsam, aber jeder misst 0% CPU-Auslastung und wundert sich.
Lausig die Realität bei Soft-RAID, wenn ohne direkte Anbindung an die CPU Daten mehrfach durch Busse übertragen werden: Laufwerk, ggf. Controller, ggf. Southbridge/Chipsatz, Arbeitsspeicher, CPU und zurück. Noch dazu RAID5/6, und die Kiste wird langsam, aber jeder misst 0% CPU-Auslastung und wundert sich.
Wenn man HW-Raids so deppert ins System steckt, dass sie von der Anbindung her limitiert sind, sind sie auch nicht schneller. Wer sich in den Fuß schießt humpelt, egal welche Schuhe getragen wurden -.-
Und da wir hier schon "vernünftige Betriebssysteme" im Thread erwähnt haben. Die inkludieren I/O-Wait in der CPU-Auslastung
Gott sei dank sind die Meisten IT-ler nicht so kleingeistig, dass sie Lösungen für ihre Probleme nicht nutzen, nur weil Anbieter $foo die Lösung $bar nicht anbieten (kann).
Gott sei dank sind die Meisten IT-ler nicht so kleingeistig, dass sie Lösungen für ihre Probleme nicht nutzen, nur weil Anbieter $foo die Lösung $bar nicht anbieten (kann).
)
