Cool Master schrieb:
Der aktuelle Server (alter Ivy 3770)
Ist das Hobby oder beruflich? Einen Server auf der Basis einer Consumerplattform ist in Unternehmen ein No-Go.
Cool Master schrieb:
auch (größere) DBs laufen z.B. Inventar-System.
Dann würde ich auf jeden Fall ECC RAM verwenden, gerade auch wenn man ZFS nehmen möchte, wie es auch Matt Ahren, Mitentwickler des ZFS-Dateisystems, schreibt:
Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM und dann erst oben drauf ein Filesystem mit Prüfsummen wie ZFS zu verwenden, wenn man seine Daten liebt und vor Korruption schützen möchte!
ZFS ist für Server entwickelt und hat keinen wirklichen eigenen Schutz vor RAM Fehlern, außerdem nutzt es nichts, wenn die Daten schon bei der Übertragung im RAM korrumpiert werden.
majusss schrieb:
DDR4 produziert eh nicht mehr so viele Fehler wie DDR3.
Weil bei DDR4 wenigstens eine CRC zur Erkennung von Übertragungsfehlern eingeführt wurde.
majusss schrieb:
da deine Daten ja trotzdem unerkannt verrotten
Korrupte Daten kommen allenfalls aufgrund von FW Bugs oder Fehlern auf den internen Datenpfade der Platte oder des Host Controllers zustande, zumeist aber von RAM Fehlern des Rechners selbst. Natürlich passieren nicht laufen so viele RAM Fehler das die ganzen Kunden der billigen NAS ständig Ärger damit hätten, aber sie können vorkommen und wer mehr Sicherheit will, muss eben zu ECC RAM und dem passenden System greifen. Bei Consumer Hardware reicht es, wenn es meistens bei den meisten Leute funktioniert, dafür muss es aber billig sein. Erst wenn Fehler gehäufter auftreten, werden Gegenmaßnahmen ergriffen. So hat man bei PATA damit mit Einführung der schnellen Ultra-DMA Übertragung eine CRC32 für jedes übertragene Paket eingeführt und wiederholt die Übertragung, wenn die CRC nicht stimmt, bei bis zu 8192 Byte Daten pro Paket reicht eine CRC32 um praktisch jeden Fehler erkennen zu können. Fehler der Backplane oder das Datenkabels führen also zu Kommunikationsfehlern und damit der Wiederholung der Übertragung und somit zu Verzögerungen, im schlimmsten Fall zum Abbruch, aber niemals zu korrupten Daten! Bei DDR4 RAM hat man nun ebenfalls eine CRC bei der Übertragung eingeführt, aber die ersetzt kein ECC RAM, da sie nicht vor gekippten Bits im Speicher selbst schützt, sondern eben nur vor Übertragungsfehlern.
Die Sache mit dem "Datenrost", also das eine HDD einfach mal andere Daten liefern würde, ist ein Märchen, zumindest für die Consumer HDDs. Bei den Enterprise HDDs kann dies anderes sein, wenn sie auf 520 oder 528 Byte pro Sektor formatiert wurden (was bei SATA Platte überhaupt nicht geht), denn dann schreibt der SAS RAID Controller selbst seine Prüfsumme in diese zusätzlichen 8 / 16 Byte und stellt die Platte so ein, dass sie die Rohdaten ohne eine eigene ECC Prüfung und ohne wiederholte Versuche sollte diese scheitern, einfach so überträgt. Da hat dann aber der RAID Controller die Aufgabe dies zu erkennen und die Daten aufgrund der Daten von den anderen Platten zu rekonstruieren, den Sektor mit den falschen Daten zu überschreiben und dem Rechner die korrekten Daten zu übermitteln. Diese SAS RAID Controller haben mit den entsprechenden Platten also mehr Verantwortung und auch immer ECC RAM verbaut. Man macht das übrigens um zu hohe Antwortzeiten wegen wiederholter Versuche der Platte die Daten doch noch korrekt zu lesen, zu vermeiden. Bei SATA Platten geht dies halt nicht, dafür hat man dort die TLER/ERC, also einen Möglichkeit den Timeout einzustellen wie lange die Platte versucht einen Sektor doch noch korrekt zu lesen.
Eine andere Möglichkeit wo Platten korrupte Daten liefern sind die ATA Streaming Befehle für Echtzeitvideoaufzeichnungen. Da hat jeder Befehl einen eigenen Timeout und es wäre schlimmer Aussetzer als Pixelfehler im Video zu haben. Diese besonderen Befehle unterstützen Desktop und NAS Platte aber gar nicht und Windows oder Linux nutzt sie von sich aus auch gar nicht. Daher kann man auch Surveillance statt NAS Platten in so einen Server bauen, bei Nutzung der normalen Befehle haben die genauso eine gute UBER von 1:10^14 oder 1:10^15 und geben ebenfalls Lesefehler statt korrupter Daten wieder, wenn mal ein Sektor nicht mehr lesbar ist.
chithanh schrieb:
Ansonsten ist die Frage ECC oder nicht ECC primär, ob die Datenintegrität wichtig ist oder ob auch Mal Datenkorruption auftreten darf ohne dass es schlimm ist.
So würde ich es auch sehen, wenn man dann schon bei dem Thema knausern muss.
rocketworm schrieb:
Nen 16GB 2666MHz ECC RDIMM Modul
RDIMM läuft aber nicht mit TR, sondern nur mit EPYC, er braucht
UDIMM, also unbuffered RAM.
Cool Master schrieb:
Was bringen mir 10 GBit/s NICs wenn das gesamte Netzwerk nur 1 GBit/s hat?
Wenn man einen Switch mit einem 10GbE Port hat, kann der diese auf die anderen Ports aufteilen und 10 Clients können mit je 1Gb/s gesättigt werden. Wenn aber der "Server" in einem Raum steht aus dem gerade eine Gigabit Leitung rausführt, dann bringt das natürlich nichts, aber dann bringen Dir 10 einzelne Gigabit NIC auch nichts.