News NVDIMM: Crucial liefert DDR4‑Module mit Flash-Backup aus

Der einzige Bereich, der mir im Moment einfällt, für den das sinnvoll sein KÖNNTE, wäre der Börsenhandel, also das High Frequency Trading. Denen kann es nie schnell genug sein, und wenn die Daten dauerhaft im RAM bleiben können, eröffnet sich das ein oder andere Einsatzgebiet für die Module.

8GB Riegel für In-Memory Datenbanken, haha... ab 32GB pro Modul geht's los, wobei das Zeug selbst mit 8GB so sackteuer sein dürfte, dass eh kein Hahn danach kräht.

Von Sandisk gab's mal die ULLtraDIMM Module - Flashstorage auf'm DDR3 Modul, mit 200 oder 400GB je Modul. Schneller als FusionIO PCI-Express Karten (die heute, im Server-/Storageumfeld, immer noch schneller als das ganze NVMe Geraffel sind), aber nur mit bestimmten Plattformen nutzbar gewesen.
 
In dem Video sieht man im Hintergrund einen weiteren idealen Einsatzzweck für diese Module: Netapp Filer.
Auf das proprietäre NVRAM Modul kann man dann komplett verzichten, die Schreiboperationen werden im RAM schon bestätigt.

Auch Hyper-Converged Systeme (Nutanix, VMware vSAN, Cisco Hyperflex, Simplivity, ...) profitieren massiv davon, denn auch hier spart man sich Platz auf den SSDs als Schreibcache.
 
Loopman schrieb:
Dann bist du einfach nur ein extrem unerfahrener "Informatiker". Ok, gerade mal 2-3 Jahre aus der Ausbildung raus... ;)
Ich wuerde an deiner Stelle nicht ueber andere Leute so vorschnell urteilen. Meine Erfahrung bezueglich dieser Bewertungen ist sogar haeufig, dass die alteingesessenen eher Lehrbuch zitieren, anstatt sich mit den gegeben Umstaenden auseinander zu setzen. Da werden gerne failover/backup/monitoring/metering Loesungen gewaehlt, die ueberhaupt nicht mehr zu den Problemen passen, die man in der Moderne hat.

Wie schon xexex sagt, es geht hier um In-Memory-Datenbanken. Dort sind viele Daten eine lange Zeit, bzw. dauerhaft im RAM. Wenn dann der Server die Grätsche macht, dann sind die Daten gesichert.
Inmemory dbs sind nicht fuer dauerhafte Persistenz ausgelegt. Ja, sie haben features um Persistenz zu erhalten. Aber der Software-Architekt, der das als Grundlage fuer nen Ersatz einer klassischen DB nimmt, gehoert halt die Leviten gelesen. Ich habe schon erlaeutert, wieso das Schwachsinn ist in heutigen Umgebungen einfach beim boot ram wieder einzudumpen und es ist auch nicht wie BBUs auf raid controllern, da diese automatisiert beim naechsten boot die Operationen ausfuehren. Nehmen wir doch einfach mal redis, was wahrscheinlich der Vorreiter von inmemory dbs ist. Redis schreibt konfigurierbar asynchron nen dump auf Platte. Versagt deine USV, rebootet die Moehre, startet redis und laedt automatisch den letzten dump. Bei default-config ist damit maximal die letzte Stunde Daten weg. Wenn du ordentlich was mit dem redis machst, fehlen wenige Sekunden. Das ist verschmerzbar und ziemlich gut automatisiert. Wieso sollte ich nochmal mich dann fuer eine HW Loesung entscheiden, die mir effektiv garbage hinterlaesst? Diese NVDIMM Loesung ist fuer Infrastrukturarchitekten, die offensichtlich noch nie etwas von slaves/standby gehoert haben. Raucht mir einer ab, promote ich den anderen zum master.


xexex schrieb:
Computerbase sollte sich Themen aus dem Profi / Serverbereich hier am besten sparen. Ich zitiere hier mal ausnahmsweise Wikipedia.
Danke, dass du mir beibringst, wie man wikipedia liest. Ehrlich gesagt, bin ich auch der Meinung, dass sich CB die Themen sparen sollte. Aber in meinen Augen nur, weil das zu haeufig zu Fronten fuehrt. Das Thema hier ist sowas von Nische, dass jeder seine Praeferenzen als das Mass der Dinge sieht.

Edit:
@Masamune2
Joah, das koennte Sinn machen.
 
Zuletzt bearbeitet:
Masamune2 schrieb:
In dem Video sieht man im Hintergrund einen weiteren idealen Einsatzzweck für diese Module: Netapp Filer.
Auf das proprietäre NVRAM Modul kann man dann komplett verzichten, die Schreiboperationen werden im RAM schon bestätigt.

Auch Hyper-Converged Systeme (Nutanix, VMware vSAN, Cisco Hyperflex, Simplivity, ...) profitieren massiv davon, denn auch hier spart man sich Platz auf den SSDs als Schreibcache.

Macht, im Zeitalter von All-Flash-Arrays, wenig Sinn, die mittlerweile günstigen SSDs gegen teuren RAM auszutauschen.
 
Selbst All-Flash Arrays haben noch NVRAM Module in denen die Schreibzugriffe zusammengefasst, dedupliziert, komprimiert und dann erst auf die SSDs losgelassen werden. Das verlängert die Lebensdauer der NANDs ungemein.
Siehe z.B. die Purestorage Flash Array (andere All-Flash Systeme kommen eh nicht an die ran ^^)

Bei Hyper-converged Systemen mag das sein, hier bietet nur Simplivity mit ihrer eigenen Controllerkarte einen Schreibcache neben dem SSD Tier. Aber da liegt eher daran das die Technik bis jetzt nicht zur Verfügung stand als daran das es sinnfrei ist.
 
Damit wir darüber diskutieren könnten, müsstest du die Gartner/IDC etc. Berichte verstehen/richtig deuten - da dies nicht der Fall ist, macht es keinen Sinn... davon mal ganz ab, sind wir wirklich sehr off topic.

Also - wenn HPE NVDIMMs anbietet, ist das deren Sache... Stand jetzt gibt es, zumindest meiner Meinung nach, keinen validen Usecase, der den extremen Preisunterschied zu SSDs rechtfertigen könnte. Zumal es ja SSD-basierende Lösungen gibt, die irrsinnig schnell sind. Da selbst normaler DRAM preislich weit über SSDs liegt, wird es beim NVDIMM sicherlich nicht viel anders sein.

Selbst für InMemory-Datenbanken sehe ich keine sinnvolle Verwendung, bzgl. des Preis-/Leistungs-Verhältnisses.
 
BlackWidowmaker schrieb:
Ich denke 3DXPoint wird zumindest die Luft dünner machen für In-Memory-Datenbanken.
Wenn man an 3D XPoint als SSD denkt, aber mit 3D XPoint als RAM wird es eher den In-Memory-Datenbanken Auftrieb geben, denn die werden ganz andere "RAM" Kapazitäten ermöglichen und eben auch den Datenerhalt bei Spannungsverlust.
 
OK, das ist dann eigentlich eine Definitionssache. Denn In-Memory-Datenbanken nennt man DB-Techniken die allein auf flüchtigen Speicher zugreifen und per Backup-Prinzip abgesichert werden. Da 3DXPoint aber per Definition eben nicht zum flüchtigen Speicher gezählt werden kann, kann eine DB die darauf zugreift per Definition keine In-Memory-Datenbank sein.

Aber da enden wir letztendlich in Wortklauberei. Sicher ist aber daß 3DXPoint mit Sicherheit in vielerlei Hinsicht den Markt aufräumen wird, und viele Software- und Hardwaretechniken dadurch obsolet werden.

Denn Einwand mit High Frequency Trading finde ich aber im Zusammenhang mit dem hier vorgestelltem Produkt am interessantesten. Da dabei um Bruchteile von Millisekunden gekämpft wird, und 3DXPoint erstmal klar langsamer sein soll als DDR4 RAM, wäre der Einsatz so eines RAMs durchaus gerechtfertigt. Da teilweise Millionen innerhalb von Sekunden verdient werden, spielt der Preis so einer Hardware dann auch absolut keine Rolle. Wobei ich solche Techniken eigentlich gerne verboten sehen würde, denn das ist parasitäres Finanzgebaren par excellence.
 
Masamune2 schrieb:
Wo hier keiner einen Use-Case findet: Die Dinger sind perfekt für Storage Systeme oder allgemein als Write Back Cache, denn die Daten können bestätigt werden wenn sie nur im RAM stehen wie bei Hardware Raid-Controllern mit Battery/Flash- Backed Write Cache.
Windows Server 2016 z.B. wird das für die Storage Spaces unterstützen und braucht somit keine SSDs mehr als Cache.

Genau für den Anwendungszweck ist das Zeug eigentlich auch gedacht.
Und nicht für In-Memory Datenbanken oder anderen Krempel - das ist totaler Unsinn, nicht zuletzt, weil - wie bereits angesprochen wurde - die restlichen Caches nicht mehr brauchbare sind oder beim booten genullt werden.

Allerdings sind die Module recht neu, selten und sehr teuer (bei geringer Kapazität - aktuell verfügbare sind AFAIK nur bis 8 GB erhältlich), daher ist das ein sehr kleiner Nischenbereich und z.B. für ZFS o.ä. hilfreich, wenn die Last sehr groß ist.
Das führt dazu, dass es bisher wenig Implementierungen gibt, die diese Module als permanenten Speicher erkennen und entsprechend behandeln. Dafür muss das BIOS angepasst sein und das Betriebssystem entsprechende funktionen implementiert haben

Was soll eine Börse damit anfangen? Quatsch!

Möglicher Anwendungszweck (neben dem erwähnten ZFS) ist z.B. das Caching z.B. für Hypervisoren, die den Zugrif auf das SAN damit puffern können, da die Latenzen und Bandbreiten erheblich besser sind.

Fazit: Wie immer, steht hier haufenweise Unsinn und extrem wenig verwertbares und das Zeug da macht erst wirklich sinn, wenn Hard- und Software angepasst sind und die Module als NVDIMM erkennen und entsprechend behandeln, ansonsten sind das überteuerte, kleine, Servermodule ohne Vorteile.
 
Nagilum99 schrieb:
Was soll eine Börse damit anfangen? Quatsch!

Achso? Ja dann sollte das mal jemand der Deutsche Börse AG (und einigen Börsenhändlern) mitteilen, denn die wissen nicht dass das Quatsch ist, und nutzen das fleissig.

Nagilum99 schrieb:
Möglicher Anwendungszweck (neben dem erwähnten ZFS) ist z.B. das Caching z.B. für Hypervisoren, die den Zugrif auf das SAN damit puffern können, da die Latenzen und Bandbreiten erheblich besser sind.

... in Zeiten stark sinkender Preise für Flash absolut sinnvoll auf schweineteure NVDIMMs zu setzen , na klar :D :D

Es gibt in solchen Umgebungen ganz andere Performance-Bremsen, wo man zuerst ansetzen sollte, und nicht sein Geld in extrem teuren RAM zu stecken.
 
Endlich mal noch jemand der Ahnung hat.
Kompletter Unsinn ist es aber auch für In-Memory Datenbanken nicht, denn man könnte in die Module das Logfile schreiben um noch kürzere Recovery Points zu haben. Logwrites sind eh sehr klein, das tut auch Flash auf Dauer nicht gut. Dazu sind auch gar keine größeren Module nötig, nähert sich das Log dem Limit wird es auf anderen Speicher geflushed.
 
Die Dinger sind gar nicht so teuer wie ihr denkt. Also original Micron sind sie schon ein paar Wochen zu bekommen, 2 Tage nach Release hatte ich schon die ersten Kunden dafür.
Nachfrage ist definitv da. Und warum die Dinger zusätzlich noch unter dem Crucial Brand released werden ist mir nicht so ganz klar, zumal das vermutlich wie bei allen Crucial-Serverspeichern nur (um-)gelabelete original Micron Ware ist.
 
Zurück
Oben