News QNAP TS-h3077AFU: All-Flash-NAS für 30 SSDs setzt auf Ryzen 7000

[DJKno]

Ok, großartig. Aber wie relevant ist solch ein Produkt für den Normalo wie mich und 99,9% der übrigen CB-Besucher?

Tellerrand und so.
Es soll Menschen geben, die beruflich in der IT tätig sind und da sind solche Systeme für Unternehmen interessant. Der Preis spielt da eher eine untergeordnete Rolle.

 

[0x8100]

Bitflips einfach sehr selten sind.

so selten sind die gar nicht. siehe z.b. diese studie:

About a third of machines and over 8% of DIMMs in our fleet saw at least one correctable error per year.

The annual incidence of uncorrectable errors was 1.3% per machine and 0.22% per DIMM.

die studie ist zwar älter, aber ram funktioniert immer noch nach dem gleichen prinzip und aus erfahrung mit einem virtualierungs- und storagecluster mit ~14TB ram kann ich sagen, dass immer mal wieder entsprechende meldungen dazu kommen. und das ist das problem mit non-ecc: man bekommt diese fehler einfach nicht mit. defekte module kündigen sich dadurch an, dass die fehlerrate immer weiter steigt. man riskiert also nicht nur korrupte daten, man hat auch keine vorwarnung, dass demnächst was komplett aussteigt.

 

[Banned]

@0x8100

Die Datenlage ist da leider sehr uneinheitlich bzw. man wird im Netz teilweise sehr unterschiedliche Ergebnisse vorfinden. Das ist auch irgendwie nachvollziehbar, da die Entstehung von BitFlips auch ein recht komplexes Thema ist, man also keine Gleichverteilung in allen Fällen erwarten kann.

Unstrittig ist sicherlich, dass es stark mir der Anzahl der Daten zusammenhängt, die den RAM durchlaufen. Ich habe einmal einen Artikel gelesen, wo angegeben wurde, dass bei einer Serverfarm mit hohem Transferaufkommen tatsächlich mehrere Bitfehler-Fehler pro Tag auftreten; aber da wurden halt auch etliche TB an Daten pro Tag verarbeitet. Im privaten Umfeld hat man da eine ganz andere Situation.

 

[0x8100]

klar, aber dieses gerät hier ist eher nicht für den privaten einsatz gedacht. und bei so einem storage laufen ständig daten durch den ram (wir nutzen z.b. noch zusätzlich compression im storage, da gibt es noch ein paar extra transfers). der kostenunterschied zu ecc-ram ist so gering (ich meine nicht die künstlich überhöhten preise bei qnap), dass die non-ecc variante gar nicht existieren dürfte.

 

[Atkatla]

@Atkatla

Naja, also durch Bitfehler im RAM können m.E. einerseits falsche Prüfsummen berechnet... andererseits können ..., ergo können Daten unbemerkt korrumpiert werden.
Darüber hinaus kann eine Korruption der Daten eben schon auftreten, bevor sie auf den Datenträger überhaupt erstmalig geschrieben werden

Du wiederholst genau diese freenas-board-waskannallespassieren-Dinge, ohne zu berücksichtigen, was davon von Anwendung, OS und Filesystem mitigiert werden kann. Diesen Faktoren muss ja schließlich auch begegnet werden, wenn die Fehlerquelle ausserhalb des RAMs liegt. Man darf nicht davon ausgehen, dass RAM die einzige Fehlerquelle sei.

Und was die Kosten angeht, es sind eben nicht nur ein paar Cent. Vor allem im Entry-Level. Von daher ist es doch ok, wenn der Hersteller einem hier die Wahl lässt.

 

[foofoobar]

Du wiederholst genau diese freenas-board-waskannallespassieren-Dinge, ohne zu berücksichtigen, was davon von Anwendung, OS und Filesystem mitigiert werden kann. Diesen Faktoren muss ja schließlich auch begegnet werden, wenn die Fehlerquelle ausserhalb des RAMs liegt. Man darf nicht davon ausgehen, dass RAM die einzige Fehlerquelle sei.

Dann erzähle uns doch was von diesen Verfahren.

 

[0x8100]

was davon von Anwendung, OS und Filesystem mitigiert werden kann. Diesen Faktoren muss ja schließlich auch begegnet werden, wenn die Fehlerquelle ausserhalb des RAMs liegt.

hmm... daten übers netzwerk auf mehreren ebenen mit prüfsummen gesichert. daten in der cpu mit ecc gesichert. daten auf dem pcie-bus oder auf dem sata-link crc-geschützt, daten auf dem datenträger selbst und im dateisystem haben checksummen. aber der ram ist dann egal?

 

[Atkatla]

@foofoobar: Du kannst von Anwendungsebene die Korrektheit der Daten prüfen, das Filesystem kann mit Prüfsummen, Redundanzen und/oder Paritäten arbeiten und mit Checkpoints beim schreiben, das ist doch alles nichts neues mehr. Wir sind doch nicht mehr im FAT-Zeitalter. Einige der Dinge wurden doch in dem Link angesprochen. Welches Szenario vermisst du denn oder siehst du angreifbar?

 

[foofoobar]

@Atkatla

Naja, also durch Bitfehler im RAM können m.E. einerseits falsche Prüfsummen berechnet (was bei vorhandener Redundanz idR wahrscheinlich noch halb so tragisch wäre - wie auch in dem von dir verlinkten Artikel angegeben), andererseits können speziell bei der Wiederherstellung eines RAID-Verbundes (oder wenn ein einzelner Fehler korrigiert werden soll) aber auch Fehler bei der Berechnung auftreten, welche unentdeckt bleiben, ergo können Daten unbemerkt korrumpiert werden.

Und im Fall von ZFS, welches als wesentliche Eigenschaft Datenintegrität hat, werden die Daten auch noch kaputt geschrieben und das FS meldet das alles super wäre.

Und das alles nur weil man aus Geiz nicht 1/8 mehr RAM verbauen will.

 

[Atkatla]

hmm... daten übers netzwerk auf mehreren ebenen mit prüfsummen gesichert. daten in der cpu mit ecc gesichert. daten auf dem pcie-bus oder auf dem sata-link crc-geschützt, daten auf dem datenträger selbst und im dateisystem haben checksummen. aber der ram ist dann egal?

Die Prüfsummen in den anderen Ebenen hast du ja aus genau dem Grund: weil Fehler auftreten können. Der RAM ist nicht egal. Es ist eine der Komponenten wo Fehler auftreten können. Genau wie im Datenträger oder im RAID-Controller oder bei der Netzwerkübertragung. ECC erhöht zweifelsohne die Stabilität, aber ZFS kann auch ohne es existieren. Ich habe nicht gesagt, dass ECC keinen Vorteil bringt. Nur "ECC or death!" ist bei ZFS nicht korrekt.

 

[foofoobar]

@foofoobar: Du kannst von Anwendungsebene die Korrektheit der Daten prüfen, das Filesystem kann mit Prüfsummen, Redundanzen und/oder Paritäten arbeiten und mit Checkpoints beim schreiben, das ist doch alles nichts neues mehr. Wir sind doch nicht mehr im FAT-Zeitalter. Einige der Dinge wurden doch in dem Link angesprochen. Welches Szenario vermisst du denn oder siehst du angreifbar?

Welche Anwendungen machen das?
Und diese Anwendungen dürften bei Bit-Riot im RAM auch ziemliche Scheiße bauen.

 

[Atkatla]

Und im Fall von ZFS, welches als wesentliche Eigenschaft Datenintegrität hat, werden die Daten auch noch kaputt geschrieben und das FS meldet das alles super wäre.

Genau das ist nicht der Fall, auch nicht mehr als im Vergleich zu anderen modernen Filesystemen. Hast du die Links und die Aussage von dem ZFS-Entwickler gelesen und verstanden?

 

[0x8100]

ZFS kann auch ohne es existieren

natürlich funktioniert zfs & co. auch ohne ecc. aber wenn man auf allen anderen pfaden schon checksummen verwendert, warum dann nicht auch beim ram? es gibt keinen kostenvorteil, ecc-module sind sogar billiger als non-ecc. es gibt einfach keinen grund, im professionellen umfeld auf ecc-ram zu verzichten.

 

[Atkatla]

Welche Anwendungen machen das?

Diejenigen, wo die Integrität von Daten wichtig ist. Bei gute Archivierungssysteme und Datenbanken erwrartet man es. Dein Notepad sicher nicht. Selbst Winzip verwendet Prüfsummen um Inkonsistenzen zu erkennen.

Ergänzung (3. Februar 2024)

natürlich funktioniert zfs & co. auch ohne ecc. aber wenn man auf allen anderen pfaden schon checksummen verwendert, warum dann nicht auch beim ram? es gibt keinen kostenvorteil, ecc-module sind sogar billiger als non-ecc. es gibt einfach keinen grund, im professionellen umfeld auf ecc-ram zu verzichten.

Ich stimme mit dir überein, dass man im professionellen Umfeld ECC verwenden sollte, wenn man es kann und es wirtschaftlich möglich ist. Aber es ist eben nicht immer kostenneutral (Ausrüster zahlen keine Preise bei geizhals). Muss halt jeder selber wissen, ob das eingesparte Geld die Ausfallwahrscheinlichkeit wert ist.

 

[0x8100]

Ausrüster zahlen keine Preise bei geizhals

nein, sie zahlen sogar noch weniger und lassen sich das ganze vergolden. alle unsere dell-server wurden mit dem minimum an ram gekauft, der eigentliche speicher mit garantierter kompatibilität dann wesentlich günstiger woanders. diese 4TB waren nicht ganz billig - bei dell hätten sie ein vermögen gekostet.

 

[Atkatla]

Genau, die Ausrüster zahlen weniger. Und sind für die die ECC-Preise ebenfalls günstiger als die non-ECC-Preise? Bloß weil es auf Geizhals einen günstigen ECC-RAM gibt, heißt das nicht dass dorthin übertragen kannst. Zudem: die Ausrüster nehmen natürlich nicht jeden RAM, sondern validieren und wollen von den RAM-Herstellern möglichst zuverlässige Module. Denn Dell will natürlich, dass du zwar den Supportvertrag hast, der dir im Memory-Fehlerfall den Austausch-RAM am gleichen oder nächsten Tag zukommen lässt, aber noch mehr Gewinn machen die, wenn du den Servicevertrag bezahlst und der Fehlerfall gar nicht erst eintritt und die kein Ersatzmodul losschicken müssen.

Wenn du jetzt Entry-Level-Systeme designst und mit mehreren 100.000 Einheiten planst, die so wenig ausfallen sollen wie möglich, dann hast du plötzlich sehr wohl einen relevanten Kostenunterschied. Preisdruck durch Konkurrenz sorgt dafür, dass fast alle Anbieter im Entry-Level dann auch möglichst kostengünstige Optionen im Angebot haben und dann sind dann auch welche ohne ECC dabei.

 

[Banned]

Genau das ist nicht der Fall, auch nicht mehr als im Vergleich zu anderen modernen Filesystemen. Hast du die Links und die Aussage von dem ZFS-Entwickler gelesen und verstanden?

Ich gehe hier noch mal beispielhaft auf den von mir geschilderten Fall eines Rebuild ein:

Angenommen, du hast ein RAID5/RAIDZ1 mit drei Disks; die Daten sind 1 (Disk1), 0 (Disk2), 1 (Disk 3) = Parität aus XOR von Disk 1 und 2.

Nun fällt Disk2 aus. Da hier nun nicht für das einzelne Bit, sondern für den gesamten Block eine neue Prüfsumme berechnet wird, kann es sein, dass aufgrund eines Bitflips Disk2 nun eine 1 erhält statt einer 0. Die Prüfsumme für den Block auf Disk2 wird dann mit der 1 korrekt berechnet, obwohl die 1 falsch ist.

Irgendwann macht man dann einen Scrub und es wird festgestellt, dass die Daten 1-1-1 sind, was falsch ist. Da aber jeder Block der jeweiligen Prüfsumme entspricht, kann nicht festgestellt werden, wo der Fehler liegt.

Ob ZFS hier im Speziellen beim Rebuild nochmal einen nachträglichen Check durchführt, lässt sich nur vermuten - da sind wird dann schon ganz tief auf Entwicklerebene und es würde mich sehr wundern, wenn man das irgendwo aus einer offiziellen, fei zugänglichen Quelle entnehmen könnte (falls dem so ist, gerne Links ).

Somit gehe ich erst mal vom Worst Case aus (dass es nicht so ist, sondern so wie ich geschildert habe).


In deinem zweiten Link wird Folgendes genannt:

"Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error."

Das beinhaltet aber nicht den Weg der Daten zwischen CPU und RAM - was aber von ECC abgedeckt wird. Evtl. deshalb spricht der Autor hier nur von "reducing the window of vulnerability".

Letztendlich kommt er ja selbst zu dem Schluss:
"I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS."

 

[Atkatla]

@Banned Und wie man dem Problem in deinem Szenario begegnen kann, hast du doch beschrieben? Wenn ich mein Filesystem beim normalen Schreiben checken lasse, dann ist es naheliegend, dies auch beim Rebuild-Schreiben zu tun.

Klar ECC ist sinnvoll. Aber weil RAM eben nicht die einzige Fehlerquelle ist und ECC auch nicht alle Memory-Fehler entdecken kann, verweist er auch auf die Checksummen: "Additionally, use a filesystem that checksums your data, such as ZFS."
Wenn ECC Korruptionen generell verhindern könnte, bräuchte man diese nicht. Aber Korruptionen können viele Ursachen haben.

Wenn ein Hersteller wie QNAP sich dazu entscheidet, so ein Storagesystem auch ohne ECC anzubieten, wäre es naheliegend, wenn das OS von QNAP dann ZFS im Zusammenhang mit der vom Entwickler genannten Option einsetzt, wo auch Daten im Memory mit Prüfsummen belegt werden.

Wie gesagt, ich sage nicht, dass ECC nicht sinnvoll ist, sondern diverse im Netz beschriebene ZFS + non-ECC-Szenarien (wie der Scrub-of-Death) einfach nur oft wiederholt werden, aber keine Bedrohung für einfache NAS sind.

 

[0x8100]

hier geht es aber nicht um ein "einfaches" nas. das basis-system kostet 6000€, die bis zu 30 ssds nochmal mindestens das gleiche bis mehrfaches. wer da wegen 100€ auf ecc verzichtet ist selbst schuld.

 

[Banned]

Und wie man dem Problem in deinem Szenario begegnen kann, hast du doch beschrieben?

Nein.

Wenn ich mein Filesystem beim normalen Schreiben checken lasse, dann ist es naheliegend, dies auch beim Rebuild-Schreiben zu tun.

Ich habe doch gerade beschrieben, wie eine korrekte Prüfsumme trotz inkorrekter Daten entstehen kann. Was willst du da checken? Sobald die Prüfsumme mit inkorrekten Daten erstellt wurde, kannst du die Daten nicht mehr als inkorrekt erkennen.

Dass ZFS die Möglichkeit eines Bitflips berücksichtigt und nochmals nachprüft (was auf die Performance geht), würde ich eher nicht erwarten (zumal man bei einem Dateisystem wie ZFS wahrscheinlich auch als Entwickler davon ausgeht, dass ohnehin ECC-RAM verwendet wird).

Klar ECC ist sinnvoll. Aber weil RAM eben nicht die einzige Fehlerquelle ist und ECC auch nicht alle Memory-Fehler entdecken kann, verweist er auch auf die Checksummen: "Additionally, use a filesystem that checksums your data, such as ZFS."

Darum, dass Prüfsummen im Dateisystem natürlich Sinn machen, geht es hier aber gar nicht. Das wollte gewiss auch niemand in Abrede stellen.

Aber Korruptionen können viele Ursachen haben.

Was aber kein Grund ist, eine mögliche Ursache nicht anzugehen, wenn es so einfach ist wie hier.

Wenn ein Hersteller wie QNAP sich dazu entscheidet, so ein Storagesystem auch ohne ECC anzubieten, wäre es naheliegend, wenn das OS von QNAP dann ZFS im Zusammenhang mit der vom Entwickler genannten Option einsetzt, wo auch Daten im Memory mit Prüfsummen belegt werden.

Die Frage, die sich mir hier stellt, ist: Wie sehr geht das auf die Performance? Denn ansonsten wäre es doch sicherlich standardmäßig gesetzt.

Trotzdem werden Bitfehler zwischen CPU und RAM dadurch auch nicht verhindert.

Wozu also einen negativen Performance-Einfluss (in welchem Ausmaß auch immer) und eine nach wie vor bestehende Unsicherheit (zwischen CPU und RAM) einfach hinnehmen, wenn man beides einfach durch ECC-RAM unterbinden könnte?

Macht für mich keinen Sinn.