News Samsung PM1653: Enterprise-SSD mit SAS 24G und bis zu 30,72 TB

[Nagilum99]

Naja, man erkennt ja auf den gerenderten Bildern gar nicht wie viele DRAM packages verbaut sind. 5 sind sichtbar, könnten in Summe auch 8 sein. 2 GB ist korrekt pro Die. Aber in einem package können ja auch bis zu vier Dies sein. Könnten also auch 64 GB sein.
Am wahrscheinlichsten sind 16 oder 32 GB. 1GB pro TB NAND ist ja so das Optimum für maximale Performance.

Weiterhin ist das kein Schreibcache. Der DRAM dient zum speichern der mapping table.

Und wo steht, dass sie den DRAM nicht zum puffern benutzen?
Zum "speichern" nutzen die den sicher nicht, du meinst zum Cachen.

Ja, möglich dass da mehr drauf sitzen, aber auch deutlich über 8 GB sind bei 30 TB nichts spektakuläres.

Ergänzung (28. April 2021)

Jedoch ist mir wichtig nur eine Anlaufstelle für die Suche nach Artikeln zu haben.

• Was ist denn gerade überhaupt möglich?
• Und ganz schick wäre: Was wird denn gerade hoch gehandelt und ist auch verfügbar?

Träum weiter
(Ja, träumen ist erlaubt)

 

[bensen]

Und wo steht, dass sie den DRAM nicht zum puffern benutzen?
Zum "speichern" nutzen die den sicher nicht, du meinst zum Cachen.

Nur weil es da nicht steht muss es so sein wie du sagst? Das macht keine SSD die ich kenne. Dafür ist einfach zu wenig Speicher vorhanden.

Wo steht es das sie cachen und nicht speichern? Um mal deinen Argumentationsstil zu nutzen. Wenn die Tabelle vollständig und permanent (während des Betriebs) im DRAM liegt, kann man nicht mehr wirklich von Caching sprechen.

 

[Nagilum99]

Wo steht es das sie cachen und nicht speichern? Um mal deinen Argumentationsstil zu nutzen. Wenn die Tabelle vollständig und permanent (während des Betriebs) im DRAM liegt, kann man nicht mehr wirklich von Caching sprechen.

Wenn sie sie dort "speichern" würden, wären sie ohne Strom nach kurzer Zeit weg. Das wäre ziemlich witzlos.
Ich geb auf, du hast recht, ich Ruhe. Alles was irgendwo nicht steht ist ja so wie du es sagst. Mir fehlt der Heise-Fisch.

 

[bensen]

Wenn sie sie dort "speichern" würden, wären sie ohne Strom nach kurzer Zeit weg. Das wäre ziemlich witzlos.

Genau, man kann natürlich keine Kopie im Flash haben...

 

[Atkatla]

Und wo steht, dass sie den DRAM nicht zum puffern benutzen?

Weil es im Enterpriseumfeld Mist wäre. Es würde eine zusätzliche Fehlerschicht hinzufügen in einem Bereich, wo möglichst keine Fehler passieren dürfen. DRAM auf SSDs wird für das Halten und Cachen von Mapping Tables genutzt. Selbstverständlich liegt eine Version der Mapping Table auf dem NAND selbst. Billig SSDs nutzen sogar nur die NAND-Version und verzichten auf die schnelleren Table Caches.

In diesen Umgebungen läuft das Caching anders ab, als du dir vorstellst. Dort cacht man z.B. writes im Storagecontroller (das ist nicht der Controller der SSD, sondern das Hostsystem) auf Batterie gestütztem RAM (Storage NVRAM/NVMEM) und nicht auf den Datenträgern, damit man z.B. den Clients die Writes schneller bestätigen kann. Die Akkukapazität ist in solchen Modulen dort deutlich größer, da dort tatsächlich Nutzerdaten gehalten werden.

Die Akkus / Kondensatoren in SSDs mit Pufferfunktion selbst sind deutlich kleiner. Denn die müssen nur diejenigen Writes noch erledigen, die der SSD-Controller selbst gerade noch ausführt und dabei einige Pages eines Blocks puffern muss (siehe read-modify-writes ). Pufferbatterien auf SSDs sichern gegen Datenkorruption bei Spannungsverlust während solcher read-modify-writes.

Lese-Caches hingegen liegen im RAM des Storaqe Controllers. Das ist deutlich effizienter.

Cache für Nutzerdaten direkt in den SSDs zu puffern, wäre schlecht, weil der Storagecontroller nie wisssen würde, wann die Daten auch wirklich verlässlich auf dem NAND angekommen sind, da der SSD-Controller schon vorher den Write bestätigen würde. Das ist im Enterpriseumfeld, wo Datenintegrität am wichtigsten ist, einfach unpraktikabel. bensens Aussage bezüglich der Mapping Table und dem DRAM sind korrekt. Der Fisch wäre da eher ein Eigentor.

 

[Nagilum99]

In diesen Umgebungen läuft das Caching anders ab, als du dir vorstellst. Dort cacht man z.B. writes im Storagecontroller (das ist nicht der Controller der SSD, sondern das Hostsystem) auf Batterie gestütztem RAM (Storage NVRAM/NVMEM) und nicht auf den Datenträgern, damit man z.B. den Clients die Writes schneller bestätigen kann. Die Akkukapazität ist in solchen Modulen dort deutlich größer, da dort tatsächlich Nutzerdaten gehalten werden.

Die Akkus / Kondensatoren in SSDs mit Pufferfunktion selbst sind deutlich kleiner. Denn die müssen nur diejenigen Writes noch erledigen, die der SSD-Controller selbst gerade noch ausführt und dabei einige Pages eines Blocks puffern muss (siehe read-modify-writes ). Pufferbatterien auf SSDs sichern gegen Datenkorruption bei Spannungsverlust während solcher read-modify-writes.

Lese-Caches hingegen liegen im RAM des Storaqe Controllers. Das ist deutlich effizienter.

Cache für Nutzerdaten direkt in den SSDs zu puffern, wäre schlecht, weil der Storagecontroller nie wisssen würde, wann die Daten auch wirklich verlässlich auf dem NAND angekommen sind, da der SSD-Controller schon vorher den Write bestätigen würde. Das ist im Enterpriseumfeld, wo Datenintegrität am wichtigsten ist, einfach unpraktikabel. bensens Aussage bezüglich der Mapping Table und dem DRAM sind korrekt. Der Fisch wäre da eher ein Eigentor.

Ich weiß wie Storage controller funktionieren und dein Erklärungsversuch ist zwar nett, aber leider auch nicht ganz richtig. Manche Controller haben nur Kondensatoren um den RAM-Inhalt auf einen kleinen Flash-Chip zu kopieren. Die Kondensatoren fallen da auch übersichtlich aus.

Außerdem gibt es z.B. bei HPE schon länger die sog. Fastpath funktion: Der Controller reicht IO direkt an die SSDs weiter und umgeht seinen eigenen Cache-Layer.
Außerdem gibt es einen durchaus relevanten SDS Markt, da verwendet keiner RAID-Controller mit Cache, sondern nur billige JBODS mit simplen HBAs - oder ganz ohne HBA als NVMe.

Ob sie den DRAM nun als Cache benutzen oder nicht: Deine Ausführung ist halbwahr bzw. speist sich aus stark veraltetem Wissen.

(Ja, ich kenne Server nicht nur von Fotos. ;-) )

 

[Atkatla]

... aber leider auch nicht ganz richtig. Manche Controller haben nur Kondensatoren um den RAM-Inhalt auf einen kleinen Flash-Chip zu kopieren. Die Kondensatoren fallen da auch übersichtlich aus.

Genau das habe ich beschrieben. Mapping Table im DRAM-Cache und Kopie auf NAND. Aber kein WriteCachen von Daten in DRAM. Warum soll das nun nicht ganz richtig sein?

Bei deinem SDS-Beispiel ist der Rechner mit dem JBOD der Storage-Controller. RAID-Controller ungleich Storage Controller. Dedizierte RAID-Controller können eine Komponente eines Storage Controllers sein, müssen es aber nicht.

Die HPE-Fastpathfunktion entspricht ebenso einer möglichen Vorgehensweise von Storage Controllern. Ob z.B. eine HPE Primera oder eine Netapp FAS eigene Caches nutzt oder Daten direkt an die Drives durchgibt, ist ihnen ja überlassen bzw. konfigurierbar, denn die Verwendung von Caches ist ja kein Muss und manchmal ja auch gar nicht gewünscht. Wie gesagt, denn das was absoluter Mist wäre: die Produktivdaten-Writes an einen (von dir vermuteten) DRAM-WritePuffer in den SSDs zu übergeben, wo das Controllersystem (egal ob Software-defined/selbstgebaut oder von Netapp, HPE) nicht weiss, ob die Daten dann auch wirklich auf NAND geschrieben wurde.
Bensens und meine Aussage war, dass der DRAM auf den Drives kein Schreibcache für Daten ist. Und das waren die Gründe dafür.

Welche meiner Aussagen genau soll denn nun veraltet oder halbwahr gewesen sein? Ich habe die Vermutung, dass du meine Aussagen über StorageController direkt auf RAID-Controller bezogen und gar nicht zwischen beiden unterschieden hast. Ich weiss, dass viele beide Begriffe gerne gleich setzen.

Ich arbeite zwar nicht mit HPE Storage, sondern primär mit Netapp-Controllern, aber schau dir doch mal den Aufwand an, wie dort die NonVolatilen Daten aufwändig zwischen den einzelnen Controllern eines Clusters aufwändig synchronisiert werden. Auch bei anderen Herstellern. Glaubst du wirklich, ein Storagehersteller würde da einen DRAM-Puffer auf Drives akzeptieren, wo er nicht weiß, was darin passiert?

 

[Nagilum99]

Genau das habe ich beschrieben. Mapping Table im DRAM-Cache und Kopie auf NAND. Aber kein WriteCachen von Daten in DRAM. Warum soll das nun nicht ganz richtig sein?

Bei deinem SDS-Beispiel ist der Rechner mit dem JBOD der Storage-Controller. RAID-Controller ungleich Storage Controller. Dedizierte RAID-Controller können eine Komponente eines Storage Controllers sein, müssen es aber nicht.

Die HPE-Fastpathfunktion entspricht ebenso einer möglichen Vorgehensweise von Storage Controllern. Ob z.B. eine HPE Primera oder eine Netapp FAS eigene Caches nutzt oder Daten direkt an die Drives durchgibt, ist ihnen ja überlassen bzw. konfigurierbar, denn die Verwendung von Caches ist ja kein Muss und manchmal ja auch gar nicht gewünscht. Wie gesagt, denn das was absoluter Mist wäre: die Produktivdaten-Writes an einen (von dir vermuteten) DRAM-WritePuffer in den SSDs zu übergeben, wo das Controllersystem (egal ob Software-defined/selbstgebaut oder von Netapp, HPE) nicht weiss, ob die Daten dann auch wirklich auf NAND geschrieben wurde.

Ich meinte mit Controller: Storage Controller aka HBA, nicht den Controller auf der SSD.

Außerdem sehe ich nicht, warum das Mist sein soll. Diverse Enterprise SSDs sind offensichtlich mit Stützkondernsatoren versehen, die es zulassen den Inhalt des DRAMs noch eben in den Flash zu schieben. Das ist ja in Sekunden erledigt. Dem Controller ist es völlig egal wo die Daten liegen, er muss lediglich davon ausgehen können, dass die Daten bei einem Stromausfall nicht verloren gehen.

Es gibt übrigens gute Gründe für einen DRAM-Puffer: Latenz.
Aus genau dem Grund hat ein Kollege Fastpath für einen DB-Server abgeschaltet.
Die Latenz der Datenbank war mit aktiviertem Cache auf dem RAID-Controller niedriger als beim direkten Durchgriff auf die SSDs.

Im übrigen ist so ein Cache Layer z.B. ein Verwendungszweck von MRAM. Bestimmte Storagesysteme verwenden MRAM o.ä. weil NAND Flash einfach zu langsam ist. Sicher für viele ein Luxusproblem, aber existent.

 

[Atkatla]

Außerdem sehe ich nicht, warum das Mist sein soll. Diverse Enterprise SSDs sind offensichtlich mit Stützkondernsatoren versehen, die es zulassen den Inhalt des DRAMs noch eben in den Flash zu schieben. Das ist ja in Sekunden erledigt. Dem Controller ist es völlig egal wo die Daten liegen, er muss lediglich davon ausgehen können, dass die Daten bei einem Stromausfall nicht verloren gehen.

Nein, "davon ausgehen können" ist bei Enterprise-Storage eben nicht gut genug. Da will man wissen, ob ein Write auch wirklich dauerhaft angekommen ist. Wofür die Stützkondensatoren in den Drives da sind und welche Art von Daten damit noch fertig geschrieben werden, wurde hier schon mehrfach gesagt: read-modfy-writes und eventuelle Mapping Table-Abgleiche, denn wenn das nicht abgeschlossen wird, hast du Daten verloren, die bereits gespeichert waren, also Datenkorruption.

Aus genau dem Grund hat ein Kollege Fastpath für einen DB-Server abgeschaltet.
Die Latenz der Datenbank war mit aktiviertem Cache auf dem RAID-Controller niedriger als beim direkten Durchgriff auf die SSDs.

Ist doch auch logisch. Mit Cache kann der RAID-Controller den Write schon an den Client bestätigen, obwohl er noch nicht auf dem Drive geschrieben wurde (Write Back vs. Write Through) und der RAID-Controller weiss dennoch jederzeit genau, ob die Daten in noch RAID-Controller-Cache liegen oder anschließend schon auf ein Drive geschrieben wurden.

Wenn auf dem Drive aber nochmal ein DRAM-basierter Datenschreib-Cache wäre, wüsste der RAID-Controller selbst und auch das Storage-System nicht, ob die Daten schon verlässlich auf NAND schon angekommen sind. Sie wüssten höchstens nur, das die Blöcke übergeben wurden und hoffentlich auch gespeichert sind. Bei Systemen, wo Datenintegrität wichtiger als Performance ist (und das ist im Enterprisesegment nunmal der Fall), wäre das daher sehr hoher Unsicherheitsfaktor. Performance erreicht man da leichter über horizontale Skalierung (mehr Drives in einem Aggregat u.ö.), ohne durch solche Blackbox-Caches die Integrität zu gefährden. Caches: ja. Aber an der richtigen Stelle!
Im Consumerbereich wäre es vielleicht denkbar, und sei es nur aus Werbegründen.

 

[Nagilum99]

Nein, "davon ausgehen können" ist bei Enterprise-Storage eben nicht gut genug.

Mehr als davon ausgehen bleibt dir nicht, egal was du verbaust.

Wenn auf dem Drive aber nochmal ein DRAM-basierter Datenschreib-Cache wäre, wüsste der RAID-Controller selbst und auch das Storage-System nicht, ob die Daten schon verlässlich auf NAND schon angekommen sind

Das ist auch völlig belanglos, solange der Hersteller der Hardware dir garantiert, dass die Daten sicher sind.
Ob sie das zu dem Zeitpunkt in DRAM ablegen, MRAM oder NAND ist völlig bums.
Relevant ist: Der Hersteller garantiert dir, dass die Rückmeldung ein geschriebenes Datum bedeutet. Wie er das intern löst ist sein Problem.
Ich verweise auf oben: Du kannst bei jeder Technik nur "davon ausgehen" bzw. dich auf die Rückmeldung/Aussagen der Hersteller verlassen.

Es gab schon HDDs die den Schreibcache nicht deaktiviert hatten, obwohl die Controller so eingestellt waren.
(Fehler in der Firmware)
Und was machst du da? Genau: Gar nichts. Entweder du weißt von dem Bug oder lernst ihn auf die harte Tour kennen. (Oder hast glück und es kommt nie zu einer entscheidenden Situation)

Was du als Unsicherheit ansiehst ist deine persönliche Ansicht. Du wirst dann vermutlich auch das Thema Bitrot ganz hoch ansetzen. Daten mit vielen gebräuchlichen Dateisystemen auf einem RAID5 abzulegen gefährdet datenkonsistenz ebenalls.

 

[tackleberry]

@tackleberry psst

@Enigma Dafür ist eine schneller und billiger

Wäre mir zu lahm.

 

[Bluto]

Ich habe das aktuelle Modell... 1735. kann ich jedoch nur als Datenlaufwerk verwenden, da es absolut nicht bootfähig ist. Man kann auch kein MBR anlegen.

 

[Nagilum99]

@Atkatla: Auch wenn der Thread schon alt ist: Ich lese zufällig gerade einen Artikel, der etwas erwähnt, was mir entgangen ist:
Der DRAM muss nicht nur das Mapping übernehmen sondern tatsächlich eine art Schreibcache:
Wie bei RAID mit Parity müssen die bestehenden Zellinformationen erst ausgelesen, die Informationen verändert und anschließend wieder geschrieben werden.
Das resultiert aus der logischen Seitengröße von 16 kB (bei TLC *3). Da natürlich nicht jeder Block nacheinander beschrieben wird, was viel Leistung kosten würde, ist ein entsprechend großer DRAM Cache nötig um die Blöcke parallel verarbeiten zu können.
Reine Schreibvorgänge, die die 48 kB ersetzen können direkt geschrieben werden - bleibt aber auch nur 1 Bit identisch... ;-)
(Nennt man bei RAID mit Parity auch "write penalty")

Tip: "Beschleunigter Speicher (Flash Grundlagen, Teil 3: Firmware-Architekturen)" aus c't (Hardcore) 12/2021

 

[tackleberry]

Ich habe das aktuelle Modell... 1735. kann ich jedoch nur als Datenlaufwerk verwenden, da es absolut nicht bootfähig ist. Man kann auch kein MBR anlegen.

Das ist die PCIe Variante? Mal anderes Mainboard probiert?

 

[Atkatla]

@Atkatla: Auch wenn der Thread schon alt ist: Ich lese zufällig gerade einen Artikel, der etwas erwähnt, was mir entgangen ist:
Der DRAM muss nicht nur das Mapping übernehmen sondern tatsächlich eine art Schreibcache:
Wie bei RAID mit Parity müssen die bestehenden Zellinformationen erst ausgelesen, die Informationen verändert und anschließend wieder geschrieben werden.

Das sind doch die sogenannten Read-Modify-Writes, siehe Post #25, dritter Absatz. Dafür wird die Zwischenspeicherung und Pufferung genutzt. Das ist aber kein Cache im Sinne, dass angelieferte Daten erstmal commited und zwischengepuffert werden. Und was in den Puffer muss, entscheidet ja der Controller aufgrund dessen, was für den Write von den bereits im NAND liegenden Bits überhaupt vorher gelesen und verändert werden muss. Und wenn der Write fertig ist, werden die Daten sofort geflusht und nicht für eventuelle spätere Aufgaben aufgehoben.

SSD-Speicher ist in Blöcke und diese nochmal in Pages unterteilt. Eine leere Page kannst du sofort beschreiben. Wenn schon Daten drin sind und nur ein Teil z.B. ein paar Bits geändert werden soll, musst du die aber erst auslesen (read), die gewünschten Bits ändern (modify) und dann die komplette Page wieder schreiben (write). Und dann gibt es noch weitere Einschränkungen: man kann z.B. nur ganze Blöcke mit allen Pages darin löschen. Das führt halt dazu, dass für kleine Schreiboperationen der Controller im Hintergrund viel mehr Operationen ausführen muss, bei SSDs nennt man das "Write Amplification".

 

[Bluto]

Das ist die PCIe Variante? Mal anderes Mainboard probiert?

Hallo. Ja, genau. Die PCIe Variante. Meinst Du das könnte am Mainboard liegen? In der Tat habe ich alles mögliche probiert mit dem vorhandenen B550 Chipsatz.

Vor kurzem habe ich mir ein X570 MB zugelegt. Ich würde nochmal einen Versuch wagen…

 

[tackleberry]

Hallo. Ja, genau. Die PCIe Variante. Meinst Du das könnte am Mainboard liegen? In der Tat habe ich alles mögliche probiert mit dem vorhandenen B550 Chipsatz.

Vor kurzem habe ich mir ein X570 MB zugelegt. Ich würde nochmal einen Versuch wagen…

Von PCIe Controllern booten ist glaube immernoch kein Standard bei Consumer Board. Vor allem bei einem günstigen...

Gibt mal "Dein Board + Boot from raid controller problem" oder "Dein Board + Boot from pcie" bei Google ein.