News Kioxia PM6: Erste 24G-SAS-SSDs für Server eingeführt

[schmalband]

@schmalband

Ich weiß zwar nicht, in welchen Enterprises du dich bewegst, aber in meinen sind Technologien wie Scale-Out-SDS- oder NVMe-oF-Lösungen die Zukunft und keine Plattenarrays mit Unmengen an SAS-Platten über Expander.

Tellerand und so...

Habe ich sowas behauptet oder als Vorteil rausgestellt?
NVMe-over-Fabrics ist im Moment noch ein Nischenprodukt was, sich so wie es jetzt am Markt ist, nicht durchsetzen wird. Vielleicht in Version 1.5 oder 2.0.
Es ist hauptsächlich eine Vendor-Lock-Lösung und ein Marketing-Thema.

 

[Simon]

@Zgurgar

Klar brauchst dafür aktuelle Technik. Viel teurer sind NVMe-oF-Lösungen aber nicht mehr. Die Brocade G610 (für z.B. NVMe-over-FC) fangen bei 5.000 - 6.000 € in der Basis an, die kleinen Mellanox SN2010 25G-Ethernet-Switche mit DCBX-Unterstützung (für z.B. NVMe-over-RoCE) liegen in ähnlichen Regionen. Beim Storage fängt der Spaß mit einer IBM FlashSystem 5100 für relativ schmales Geld an und auch eine NetApp A400 oder PureStorage X10/X20 ist für den Mittelstandskunden ab etwa 250 Mitarbeiter keine unerreichbare Liga.

Wer natürlich sonst gewohnt ist, QNAP NAS-Systeme als "Enterprise-Storage" für irgendwelche Kunden anzupreisen, für den ist das natürlich nix.

 

[Zgurgar]

@Zgurgar

Klar brauchst dafür aktuelle Technik. Viel teurer sind NVMe-oF-Lösungen aber nicht mehr. Die Brocade G610 (für z.B. NVMe-over-FC) fangen bei 5.000 - 6.000 € in der Basis an, die kleinen Mellanox SN2010 25G-Ethernet-Switche mit DCBX-Unterstützung (für z.B. NVMe-over-RoCE) liegen in ähnlichen Regionen. Beim Storage fängt der Spaß mit einer IBM FlashSystem 5100 für relativ schmales Geld an und auch eine NetApp A400 oder PureStorage X10/X20 ist für den Mittelstandskunden ab etwa 250 Mitarbeiter keine unerreichbare Liga.

Wer natürlich sonst gewohnt ist, QNAP NAS-Systeme als "Enterprise-Storage" für irgendwelche Kunden anzupreisen, für den ist das natürlich nix.

Ist halt immer eine Use-Case Frage. Im Grunde sehe ich den Nutzen momentan (noch) bei Anwendungen die extreme Performance benötigen und wo man mit normalen SAS SSDs schon am Limit ist.
Bei Anwendungen die jetzt eher so vor sich hinlaufen kann man sich das Geld auch sparen.

Die Zukunft ist es sicherlich. Aber aktuell ist es auch nicht das Produkt mit dem die Hersteller jetzt den großen Umsatz machen bzw. etwas für die breite Masse.

 

[ofenheiz]

• Es gibt am Markt bisher kaum verfügbare NVMe-RAID-Controller. Das kann ein temporäres System sein, verhindert aber derzeit den Vormarsch von PCIe für Storage-Systeme

NVMe-RAID-Controller sind auch eine seltsame Gattung. Der große Vorteil von NVMe ist ja der geringe Protokoll-Overhead, der, wenn die NVMe-SSD direkt an die CPU angebunden ist, sehr niedrige Latenzen ermöglicht. Diese geringen Latenzen sind einer der Bausteine, welche die Mega-großen Input/Output-Zahlen überhaupt erst ermöglichen. Wenn jetzt ein Raid6-Controller dazwischen gehängt wird, steigt zwangsweise wieder die Latenz und die Leistung ist ein ganzes Stück niedriger. Da hätte man auch gleich bei SAS bleiben können.

Nichts desto trotz, ohne mindestens Raid1 für NVMe-SSds würde ich mich im Server-Umfeld auch nicht trauen zu arbeiten.

 

[h00bi]

NVMe RAID Controller sind der Hauptgrund warum von AMD PCIe 4.0 gepusht wurde.

Moderne RAID Controller sind aber i.d.R. "Tri-Mode" und können SATA, SAS und NVMe.
Die Backplaneanschlüsse sind ja für alle Laufwerkstypen identisch.

Dual Porting ist auch bei NVMe möglich, sogar auf unterschiedliche Namespaces.

Das einzige was bei NVMe noch ein Problem/Nachteil gegenüber SAS ist, ist die Anzahl der Devices.
Bei NVMe liegt das Limit aktuell bei 24-32 Laufwerken, bei SATA/SAS sind 240 Laufwerke möglich (an einem Tri-Mode Controller).

 

[SoDaTierchen]

S-ATA = 1 Queue, 32 Einträge
SAS = 1 Queue, 256 Einträge
NVMe = 64K Queues, 64K Einträge

Du kannst noch immer NVMe (Protokoll) nicht mit SAS (Schnittstelle) vergleichen ... Abgesehen davon klingt da in der Theorie zwar unendlich krass, hat in der Praxis abseits von Workstations aber kaum eine Bedeutung.

@MichaG: Danke für den Link, das war mir noch nicht bekannt. PCIe-typisch halbieren sich dabei die verfügbaren Lanes, aber immerhin überhaupt möglich.

ohne mindestens Raid1 für NVMe-SSds würde ich mich im Server-Umfeld auch nicht trauen zu arbeiten.

Genau das. Da kann NVMe so toll sein wie es will, solange RAID-Controller dafür Mangelware sind, taugen die Dinger nur als Cache. Oder in Systemen, in denen ein temporärer Ausfall nicht weh tut.

 

[Rickmer]

Abgesehen davon klingt da in der Theorie zwar unendlich krass, hat in der Praxis abseits von Workstations aber kaum eine Bedeutung.

Workstation, who cares?

Mein erster Gedanke geht bei hoher I/O Last eher an SQL-Server und Mail-Server.

Wenn du dann ein paar hundert (oder tausend) Mitarbeiter hast, die alle auf dasselbe zentrale Management-Programm zugreifen und dann ein paar Auszüge fürs Reporting machen, kannst du auch guten Storage in die Knie zwingen...

 

[SoDaTierchen]

@Rickmer: Erstens: Niemals abfällig über Anwendungsfälle sprechen, die du nicht verstehst oder verstehen möchtest. Zweitens: Gerade wenn das Storage in die Knie geht sind die Unterschiede zwischen den Protokollen irrelevant. Dann zählt nur noch brutal, was das Storage leisten kann, die Protokoll-Effizienz oder gar CPU-Load sind dann absolut nebensächlich.

Ich weiß, dass Storage-Leistung ein gigantisches Problem sein kann. Aus Erfahrung. Aber NVMe ist da keine Lösung, jedenfalls nicht, wenn das Ding nicht ausfallen darf. Denn bei NVMe-Hardware-RAIDs ist dieselbe PCIe-Schnittstelle das Limit, wie bei SAS-basierten RAIDs, bei Software-RAIDs ist die Lastverteilung leider nicht besonders gut, sodass die Raids die Mehrleistung gegenüber einem gut bestückten SAS-basierten RAID nicht ausspielen können. Verzichtest du auf das RAID und lässt die NVMes direkt angebunden, dann ist die Leistung natürlich über alle Zweifel erhaben. Dafür ist bei einem Ausfall aber direkt das Geschrei groß, besonders in dem Fall, wenn auf einmal ein paar Tausend Leute nicht mehr mit den Diensten arbeiten können.

PS: Ich kann mit Workstations auch wenig anfangen, aber das ist der einzige Anwendungsfall, der mir spontan einfällt, bei dem man in Kauf nehmen würde, wenn so eine Kiste mal wegen Festplatten-Reparatur nen Tag ausfällt.

 

[Simon]

@Rickmer

Für einen Mail-Server wäre das etwas überzogen, SQL-Server vielleicht schon eher. (Wobei dort der Trend ja auch eher in Richtung In-Memory-DBs geht).

Ich denke da eher an große Backends für Analytics Workloads (Hadoop und Co) oder größere NoSQL-Datenbanken wie Elastic Search, wo dann etliche k8s-Cluster mit den entsprechenden Applikationen ihre Abfragen drauf loshämmern.

@SoDaTierchen

Keiner redet von irgendwelchen einfachen RAID-Controllern in irgendwelchen Servern, sondern von anständigen Storage-Systemen, wo die Logic sowieso über größere CPUs läuft und die NVMe-Disks entweder direkt oder per PCIe-Switch angebunden sind. Da hast du dann pro Disk eine PCIe-x4-Schnittstelle, statt ein PCIe-RAID-Controller, wo dann 16-24 SAS-Disks sich eine müde PCIe-x8-Schnittstelle teilen müssen.

Mal zum Vergleich:

https://www.storagereview.com/review/netapp-aff-a800-review
https://www.storagereview.com/review/netapp-aff-a800-nvmeof-review

Im SQL-Test stehen da "730,567 IOPS with a latency of 1.4ms" (Standard) vs. " 1,466,467 IOPS at a latency of only 496.6µs " (NVMe-oF). Hab mir das Setup dort nicht bis ins letzte Detail angeschaut, aber der Vorteil ist schon an dieser Stelle eklatant.

__

Und natürlich ist hier jederzeit eine Redundanz vorhanden und sogar im laufenden Betrieb ist ein Austausch der Drives möglich.

 

[SoDaTierchen]

@Simon: ich bin beeindruckt, du befasst dich mit der Materie und hinterfragst. Gefällt mir gut, mein erster Eindruck von dir war etwas negativer.

Die Benchmarks sind cool, aber nicht vergleichbar, leider. Das nvme-of-storage hat 23 NVMes in einem Gespann, das andere storage 2x11 auf zwei "RAID-DP-Aggregates". Daher kann die Halbierung der Leistung allein von dieser Aufteilung kommen. Muss aber nicht.

Ich suche Mal etwas herum, vielleicht finde ich ja Vergleichbares. Rechnerisch könnte ein entsprechendes SAS-Gerät auf einen Durchsarzt 1,2Gbps x 23 = 27,6 Gbps kommen. Das hier verwendete storage schafft etwa 25Gbps lesend. Da das aber reale Werte sind, ist das schon beeindruckend. Ich glaube zwar noch immer, dass NVMe im Serverumfeld noch keinen nennenswerten Vorteil gegenüber SAS-basierten Lösungen bietet, möchte es jetzt aber genau wissen. Ich melde mich später, ob ich was zur Thematik finden konnte.

 

[Nagilum99]

Standardfrage, was kann nun SAS anders als PCIe damit man eine Bandbreite die DoA ist, hinnimmt?

Da wurde ja inzwischen schon drauf eingegangen, auch wenn hier viel ahnungsloser Quatsch geschrieben wurde. @SoDaTierchen hat das recht gut ausgeführt.

@Simon: Du brauchst keine "in memory DBs", du musst die DB nur grundsätzlich mit ausreichend RAM "bewerfen".
Wenn du Datenbanken im 0,TB-Bereich hast, die auf extremen storage IO angewiesen sind, hast du höchstwahrscheinlich einiges falsch gemacht.
Gute DBs haben kaum lesenden IO und arbeiten primär im RAM.

Und wie schon erwähnt 64k x 64k beeindrucken nur Leute, die allenfalls pseudo-ahnung von der realen Welt haben. In der Praxis ist das völlig irrelevant. Diese Queues müssen auch sinnvoll befüllt werden um irgendeinen Effekt zu haben. Mit PCIe 6.0 SSDs mag das vielleicht mal Relevanz haben - inwieweit das aber noch für SSD-Backplanes taugt und welche Tribute das fordern wird...

IMHO ist SAS24G überfällig und SAS selbst wird, wie auch FC, noch Dekaden leben.

Warum mit SAS24G 'damals' gewartet wurde ist einfach zu erklären: 1. müssen SSDs und RoCs das (dauerhaft, nicht nur kurze Peaks) verarbeiten, 2. macht SAS24G erst mit PCIe 4 richtig Sinn, da sonst der Steckplatz zum Flaschenhals wird. Controller haben ja indR. mind. 8, üblicherweise bis max. 24 Kanäle.

Es wird nun allerdings auch Zeit für RAID-Controller mit deutlich mehr Cache. 4 GB (idR. ist dort Ende) sind heutzutage doch arg wenig.

 

[Simon]

Ich bin echt erstaunt, wie rückständig hier manche denken. °_°

 

[Nagilum99]

Ich bin echt erstaunt, wie rückständig hier manche denken. °_°

Wie präzise deine Argumente...

 

[Simon]

@Nagilum99

Wer einfach so sämtliche DB-Workloads über einen Kamm schert und lokale RAID-Controller für Enterprise-Anwendungen als das Maß aller Dinge hält, da ist jegliche sachliche Diskussion unmöglich.

Aber gut. Falsches Forum für solche Themen.

 

[Nagilum99]

• an einen SAS-Expander können bis zu 36 Geräte angeschlossen werden (theoretisch 128, praktisch gibt es sowas noch nicht). Dank SAS-Fanouts kannst du an einem Raid-Controller mit 2 Ports bis zu 2592 Festplatten anschließen (Theoretisch über 16.000, aber dafür fehlen wieder Geräte). Bei PCIe ist das Limit derzeit bei 256 PCIe-Lanes (2x AMD Rome) bzw. 320 PCIe-Lanes (8x Xeon Platinum). Da PCIe keine Lane auf 2 Geräte aufteilen kann, ist hier schnell ein Limit erreicht.

Da sind übrigens 2 Fehler:
1. Ändert sich die Anzahl der PCIe Lanes bei AMD nicht: Pro CPU werden 64 Lanes für den Link zwischen den Sockel benötigt/umgewidmet.

Außerdem kann man die Lanes über PCIe-Switche sehr wohl 'aufteilen' (Nvidias GA100 Module verwenden sowas) - aber die Dinger sind teuer und verbrauchen recht viel Energie.

Das ist falsch. Es gibt durchaus eine große Anzahl an SAS-SSDs, die auch oft und gerne verbaut werden. SAS-SSDs können sogar von der höheren Bandbreite profitieren und mit fast 2,4GB/s über SAS funken.

Nicht zu vergessen: Die Bandbreite ist vor allem an den Uplinks der Storagegehäuse wichtig. Die SAS4 Expander sind in der Lage 4x S-ATA600 nahezu perfekt in eine SAS24G Lane zu stopfen. Im Netz gab es da Videos zu.
Damit geht es nicht primär um jedes Laufwerk sondern vor allem um die Links zwischen den Gehäusen/Controllern/Backplanes.

@Nagilum99
Da ist jegliche sachliche Diskussion unmöglich.

Aber gut. Falsches Forum für solche Themen.

Nein, mit der Aussage passt du sehr gut in dieses Forum. Ich bin dann auch nicht weiter an deinen Argumenten interessiert.

 

[SoDaTierchen]

Pro CPU werden 64 Lanes für den Link zwischen den Sockel benötigt/umgewidmet.

Außerdem kann man die Lanes über PCIe-Switche sehr wohl 'aufteilen'

Beides richtig. Ersteres hatte ich glatt vergessen, Letzteres irgendwie verdrängt. Dass die Bandbreite dabei komplett flöten geht, ist ja irrelevant, dasselbe Problem haben SAS-Expander ja auch.

Zum Thema Benchmark: Ich konnte nichts sinnvolles finden. Scheinbar ist die Performance noch kein Thema, oder die Unternehmen, die das brauchen, haben nicht-öffentliche Benchmarks. Wenn man bedenkt, dass SAS-3 2,4GB/s leisten kann und Enterprise-NVMe-SSDs meist "nur" 1,8GB/s lesen können, dann könnte man auch zu dem Schluss kommen, dass der Vergleich derzeit einfach noch keine Relevanz hat.

 

[Nagilum99]

[...]dann könnte man auch zu dem Schluss kommen, dass der Vergleich derzeit einfach noch keine Relevanz hat.

Ich kenne große Firmen die nach wie vor günstige S-ATA SSDs einsetzen, weil sie dort kein Problem mit dem Storage-IO haben, sondern einfach sehr große Datenmengen (XY TB) in Summe schnell/random verfügbar haben müssen - und was ist da günstiger als z.B. ein RAID über 24 1 TB S-ATA SSDs?

Zu von dir erwähnten Raiser-Cards: Mit PCIe 5 (oder erst 6? ich meine es war schon mit 5) sind selbige übrigens nicht mehr erlaubt. Ich weiß nicht wie die OEMs/ODMs das umsetzen werden. Die Dämpfung der Steckverbindungen soll zu hoch sein, als dass der Standard das zulässt - zumindest Stand jetzt.
Was das in Bezug auf Backplanes etc. bedeutet kann sich jeder (mit etwas Ahnung) denken.

Es bleibt spannend (und viel komplizierter als manch einer hier meint).

 

[Piktogramm]

Das SAS bei SSDs noch zum Einsatz kommt, hat in erster Linie Kompatibilitätsgründe, weil die Ökosysteme (Controller, Backplanes) eben seit 15 Jahren darauf ausgelegt waren.

This! Michbestückung von alten und neuen Speichersystemen wird mit SAS eine Ecke einfacher als mit den Abwandlungen von PCIe, einfach weil SAS bereits breit ausgerollt wurde.

Es wird nun allerdings auch Zeit für RAID-Controller mit deutlich mehr Cache. 4 GB (idR. ist dort Ende) sind heutzutage doch arg wenig.

Wobei Hardware Raid Controller sowieso eine aussterbende Gattung sind. Außerhalb von eher kleinen Windows Servern habe ich lange nichts mehr gesehen, was nicht in Software über die CPU lief.
Was den Durchsatz, Menge an Speicher und Kosten angeht, liefert so eine x86 CPU mittlerweile einfach mehr.

 

[Nagilum99]

Wobei Hardware Raid Controller sowieso eine aussterbende Gattung sind. Außerhalb von eher kleinen Windows Servern habe ich lange nichts mehr gesehen, was nicht in Software über die CPU lief.
Was den Durchsatz, Menge an Speicher und Kosten angeht, liefert so eine x86 CPU mittlerweile einfach mehr.

Ganz sicher sterben die noch lange nicht, denn sie haben für kleine/mittlere Umgebungen ein sehr wichtiges Argument: Gepufferten Schreibcache.
Semmelt dir dein Software RAID aus irgendeinem Grund ab, sind alle Daten, die sich noch im RAM befunden haben weg. Datenbanken potentiell korrupt etc.
Den Schreibcache abzuschalten ist selten eine Option - auch bei SSDs nicht.
Abgesehen davon sind die anteiligen Kosten bei Servern oft geringfügig und die Leistung steigt mit jeder Generation deutlich.

Etwas spezieller: Auch für Datenbanken können sich solche Controller lohnen, da der Schreibvorgang als abgeschlossen zurückgemeldet wird, sobald die Daten im RAM des Controllers liegen - das kann die Latenz erheblich senken.

Last but not least: Vielfach kommen noch S-ATA/SAS HDDs zum Einsatz, weil SSDs von HPE, Dell & co einfach sündhaft teuer sind. Ein RAID-Controller und ein paar 1/2 TB HDDs kosten einen Bruchteil und reichen oft aus (wobei hier wieder der batteriegestützte (Schreib)cache wichtig ist).

Edit: Oder wie definierst du "klein"?

 

[Simon]

@Piktogramm

Danke. Wenigstens einer, der verstanden hat, dass es hier nicht um irgendwelche Eigenbau-Bastellösungen geht.

Ohne RGB-Beleuchtung kommen hier manche einfach sonst nicht klar.