10G + ECC + ZFS | Xeon-E/W vs. Ryzen

[Trambahner]

- Das mit der passthru.map für den Sata-Controller klappt oft nicht bei AMD-Boards. Auf dem X570D4U-2L2T funktioniert das nicht (oder man möge mir sagen, wie).
Allerdings hat das mit der passthru.map auch bei Intel in der einen oder anderen ESXI-Version/Update schon gezickt. 100% Verlass ist da nicht, ist hier und da etwas wackelig.

- RDM einzelner Platten ist bei SAS-Geräten offiziell unterstützt, bei Sata nicht. Allerdings klappt es oft. (Egal ob Intel oder AMD).

- Storage mit Sharing würde ich wohl immer abkapseln, über eine VM oder per Gerät. Warum? Damit das nicht mitgerissen wird, wenn am Hypervisor was schief läuft. ESXI selber kann eh nicht ZFS, Proxmox kann es aber ist kein "Storage-Experte" und dann muss man Sharing extra einrichten. Bin kein Proxmox-Experte, aber Samba muss man wohl per Shell nachinstallieren und administrieren. Kann man machen, erhöht aber die Komplexität und den Aufwand im Desaster-Fall.

@supernode: Du hast mich nach der Leistungsaufnahme gefragt. Ich hab ein X570D4U-2L2T mit 5600X, HBA 9400i-16, 64GB ECC, 6*HC530 HDD, 6xSM883/SM863, 2*970EvoPlus, 5 140er Lüfter. Idled mit laufenden Disks etwa bei 80W (manchmal steht auch 75W auf der USV) mit 2 1Gbit-Links, wenn die Disks im Spindown sind dann etwa 50-55W. OS: ESXI 7.0 mit Xigmanas als Nas-VM. Idle schwankt da immer jeweils +-5W.
HBA braucht etwa 8-10W, IPMI etwa 7W. eine HDD 5,5W Idle, eine der Samsung-SSDs 1W. einer der Lüfter auch ~1W.

gemessene Idle-Varianten (bevor das System live ging) mit 32GB Ram (2*16 ECC):
39-42W bei ESXI 7.0.1 U1C idle, 1*lan@i210, 2*970evo Plus ssd, 3 lüfter, power@balanced, keyboardless, no mouse
39-41W bei Win10 idle, 0*lan@i210, 2*970evo Plus ssd, NH-D15 =2 Lüfter,1*sata ssd, quadro p400 gpu, power@balanced,keyboard,mouse, TDP-Limit auf 90W.
42-43W, dto, wenn PBO aktiv und auf 105W-Limit gesetzt

ESXI ist generell kein "Kostverächter" bzgl. Leistungsaufnahme; dat Ding ist nicht dafür gemacht das letzte Watt zu sparen. Proxmox ist etwas sparsamer und man kann ggü. dem Standardsetup mit #powertop oft noch ein paar Watt extra sparen.
Zum Vergleich mein Deskmini X300. Ryzen Pro 4350G mit 32GB Ram und 1 Sata-SSD. 6W unter Win10 Idle, ESXI+Proxmox, jeweils mit USB Dual-Lanadapter, ~15W. Proxmox nach Powertop 12W. (etwa 1,5W gehen da auf Rechnung des USB-Lanadapter)
Leider kann der Deskmini kein ECC (die CPU kann es offiziell, aber das Deskmini-Mainboard nicht).

 

[tar]

Nein, wieso.

Weil diese auf "U.2" als Oberbegriff Bezug nehmen und es auch als "U.2-Anschluss" beschreiben und nicht (allgemein) als "(Mini)-SAS-Anschluss", präzise "SFF-8643". Im Handbuch fehlt diese nicht unwesentliche konkrete Spezifikation auf SFF-8643 sogar gänzlich (als ob es SFF-8639 und SFF-8644 nicht gäbe) - da steht in der Spezifikationsübersicht nur "1x U.2 Anschluss (unterstützt U.2 NVMe Geräte)" ohne Verweis auf SATA/SAS. In der Motherboard-Übersicht schlicht "U.2". Unter Ausstattungsinhalt steht dann "Mini-SAS-HD-Anschluss (U.2)". Bei Geizhals steht einfach eine Mischung der Port-Spezifikation.

Asus schreibt doch, dass man ein SFF-8643 auf SATA für SATA-Geräte oder SFF-8643 auf U.2 (SFF-8639) für U.2 Geräte braucht.

Genau das tut Asus eben nicht.

Also ist das entweder von Asus und Delock falsch beschrieben oder du irrst dich und U.2 ist per se als SFF-8639 und SFF-8643 spezifiziert, weswegen man den Port auch immer nur mit "U.2" betitelt (d.h. man benötigt ein SFF-8639/8643-auf-SFF-8639/8643-Kabel, um ein U.2-Gerät anzuschließen).

 

[danielmayer]

Das Asus ist falsch beschrieben. Im Übrigen nicht das erste Mal, ich hatte mit denen vor Jahren schon Streit...
In den Specs auf der Homepage steht tatsächlich "U2 Connector", im Handbuch zunächst auch. Erst bei den Details steht dann Mini-Sas-Hd. Insofern widersprechen sich die dortigen Angaben und nur letzteres ist richtig.

 

[gea]

Die Verwirrung kommt daher dass über die gleiche mechanische Steckverbindung (SFF-xxx) elektrisch unterschiedliche Signale geführt werden können wie Sata, SAS oder NVMe (=U.2). Je nachdem wird ein anderes Adapterkabel benötigt das auf der anderen Seite halt Sata, SAS oder U.2 hat.

Es ist eine Unsitte, eigentlich sogar irreführend und falsch, statt der korrekten Steckerbezeichnung elektrische Eigenschaften wie U.2 zu beschriften wenn damit im konkreten Fall ein anderes Signal übertragen wird oder übertragen werden kann.

 

[underclocker2k4]

Genau das tut Asus eben nicht.

Ich beziehe mich auf

Anhang anzeigen 612175

Und da ist es so, wie es geschrieben steht. (gemäß Normungslage)
Die Dokumente, die du verlinkt hast, geben das korrekt wieder.

Dass irgendwelche Marketingleute und auch Redakteure das nicht schnallen, ist eine andere Sache.

Also ist das entweder von Asus und Delock falsch beschrieben oder du irrst dich und U.2 ist per se als SFF-8639 und SFF-8643 spezifiziert, weswegen man den Port auch immer nur mit "U.2" betitelt (d.h. man benötigt ein SFF-8639/8643-auf-SFF-8639/8643-Kabel, um ein U.2-Gerät anzuschließen).

Wo wir dann auch wieder bei dem Punkt wären

Anhang anzeigen 612182

U.2 wird bei NVMe SSDs im 2,5" Format eingesetzt. Sie wurde zunächst als SFF-8639 bezeichnet. 2015 entschloss sich die SSD Form Factor Working Group (SFFWG) für den einfacheren Namen U.2, was auch gut zur etablierten M.2 Schnittstelle passt.

Der Stecker nennt sich weiterhin SFF-8639, welcher eine lange Historie hat.
U.2 ist ein Marktingname für den SFF-8639, der PCIe bzw. darauf aufsetzend NVMe zur Verfügung stellt.
Viel mehr noch, der SFF-8639 kann auch SAS-Geräte aufnehmen, da er dedizierte (sprich andere) Pins für das SAS-Interface verwendet. Die SAS-Belegung im SFF-8639 stammt vom SFF-8482 ab.
Der SFF-8482 war der ursprüngliche SAS Connector für SAS-HDDs.
SFF-8482 beschreibt den mechanischen Stecker an der HDD/SSD. Dieser stellt 2 Datenlinks zur Verfügung, weswegen er auch 2x-Stecker genannt wird.
SFF-8678,SFF-8680,SFF-8681 beschreiben wiederum wie der gesamte Stecker (also nicht das Pinout/Kontakte) beschaffen sein muss, dass der SFF-8482 3Gb/s,12Gb/s bzw. 24Gb/s übertragen kann, sprich also die Anforderungen von SAS1, SAS2/3 und SAS4 beschreibt.


Weiter geht es dann mit dem SFF-8629, der eine Weiterentwicklung des SFF-8482 ist und einfach nur 2 weiter Datenlinks hinzufügt. Dazu hat man die gegenüberliegenden Seite der Powerpins um Datenpins erweitert.
Durch die 2 Lanes war es dann ein 4x-Stecker.
Das ist aber wieder nur das Pinout/Kontakte. SFF-8630 und SFF-8640 beschreiben dann die Beschaffenheit für Übertragungen 12Gb/s bzw. 24Gb/s über den SFF-8629 Stecker, sprich also die Anforderungen von SAS3 und SAS4 beschreibt.

Eine SAS4 HDD/SSD kann also einen SFF-8482-Stecker haben und unterstützt dann nur 1 oder 2 Datenlanes, sie kann aber auch SFF-8629 haben und unterstützt dann wahlweise 1-4 Lanes. Wobei eine HDD/SSD mit 1-2 Lanes nicht klar als Gerät mit SFF-8482 oder SFF-8629 zu erkennen ist, weil man dann den Entwickler fragen müsste, an welche Beschaffenheit für die Übertragung er sich gehalten hat.
Es wird aber so sein, dass eine SFF-8482 HDD/SSD in einem SFF-8629 Slot und umgekehrt laufen wird, ggf. mit reduzierter Laneanzahl.

Dann hat man sich gedacht, dass man noch 2 weitere Datenlanes braucht.
Es wurde der SFF-8639 Stecker geschaffen, der dann ein 6x Stecker ist. Also noch mehr Kontakte neben den "gerade" hinzugefügten 2x Datenlanes des 4x Steckers.
Wobei jetzt 2 Lanes exklusiv SAS/SATA sind, 2 Lanes exklusiv PCIE/NVMs und 2 Lanes SAS/PCIe/NVMe.

Jetzt ist es so, dass dieses ganze SFF-Benamungsschema die Leute völlig verwirrt, die nicht in der Normungslage unterwegs sind.
Also hat man sich entschlossen, analog zum M.2 einen handlebaren Marketingnamen zu finden, U.2 und hat den SFF-8639 dahingehend umbenannt.
U.2 ist also nur ein anderer, handhabbarer, Name für den SFF-8639-Stecker.
Gemäß der SPEC des SFF-8639 kann es auch 2-4 Lanes SAS HDDs/SSDs geben, die ein U.2 Interface haben. Und das macht es dann besonders lustig, weil diese Geräte mit NVMe nun überhaupt nix am Hut haben.
(ob sich ein Laufwerkshersteller jemals traut sowas zu bauen, wird sich zeigen)
Problem dabei ist, dass der U.2 Stecker im Vergleich zur Verwendung mit NVMe SSD anders beschaltet ist.
Ein quad lane Kabel mit z.B. einem SFF-8643 Stecker hat also ein andere Lanerouting für (quad)SAS bzw. (quad)NVMe HDDs/SSDs.
Viel Spaß dabei rauszubekommen, wofür man das Kabel jetzt verwenden kann.
Das selbe Problem hat man auch bei Backplanes. Daher haben U.2 Backplanes zwei unterschiedliche Anschlüsse, wenn sie SATA/SAS/NVMe (Tri-Mode) unterstützen wollen. Sie brauchen nämlich Anschlüsse für SAS-Controller und separate Anschlüsse für NVMe-Controller.
Das macht die Backplanes unnötig aufwendig und damit teuer, zumal dann immer die jeweils anderen 2 Lanes tot liegen, bzw. es Signalprobleme gibt, da 2 Lanes ja sowohl zum NVMe als auch SAS Port gehen, wenn SAS als quad lanes ausgeführt ist.

Also, schlechte Idee, neue Idee, wir machen U.3 aka SFF-TA-1001.
Wir nehmen wieder 2 Lanes weg, und nutzen die restlichen 4 Lanes gleichermaßen für SAS als auch NVMe.
Dadurch wird das Routing der Lanes im Stecker angeglichen und man kann die selben Kabel verwenden, sofern man quad port SAS fahren will. Ansonsten kann mit einem z.b. SFF-8643 auf 4x SFF-8643 einen Quad SAS Controller an eine U.3 Backplane anbinden für single port SAS oder SFF-8643 auf 2x SFF-8643 für dual port SAS. Oder geht einfach auf ein SFF-8643 nach SFF-8643 Kabel, wenn man NVMe fahren will.

Abschließend ist zu sagen, dass
SFF-8639 U.2 als Marketingnamen hat,
SFF-8643 mini-SAS HD als Marketingnamen hat und der Vollständigkeit halber
SFF-8087 mini-SAS,
SFF-8088 extern mini-SAS,
SFF-8644 extern mini-SAS HD gemarketingt werden.

PS: Die Spezifikation spricht weiterhin nur vom SFF-8639-Stecker. Die Anwendung, sprich Serverbauer z.B. sprechen dann vom U.2.

EDIT:
Somit gibt der SFF-8639 den Betrieb von SFF-8482 HDDs frei. Man kann die Stecker der z.B. Backplanes aber so kodieren, dass keine alten SAS HDDs in U.2 Backplanes passen, da z.b. die SAS Lanes nicht beschaltet sind.
In einem SFF-TA-1001 hingegen würde die alte SAS HDD laufen, da die erste Lanes mindestens beschaltet ist und daher, mit passendem Kabel, auch an den Controller angebunden ist.
Daher ist meine persönliche Empfehlung, dass in den Server U.2 direkt sein gelassen wird und man direkt auf U.3 geht. So kann man zwischen HDDs und SSD wählen, sofern man das noch überhaupt möchte.
(es gibt da ja mittlerweile auch andere, non 2,5", Formate für hot swap SSDs)

 

[supernode]

Ist die Anbindung zwischen X570 und CPU bei den 3000ern und 5000ern identisch PCIe 4.0 x4?
Bringen die 5000er denn außer höherer IPC noch weitere Features mit? Bin gerade am überlegen ob ich einen 3950x nehmen kann der aktuell zu nem interessanten Preis zu haben wäre...

Die Verbauchswerte schau ich später genauer an, bin noch unterwegs

 

[Trambahner]

Ja, 3000er (ausser den 3xxxxG APUs) und 5000er haben beide PCIe4.0 x4 zum Chipsatz.
Die Verbesserungen am Cache ist ja schon in der IPC quasi berücksichtigt.

Die 5000er sind Idle AFAIK etwas sparsamer und auch die Speicheranbindung/Infinity Fabric ist wohl etwas besser. Kann evtl. wichtig sein, wenn Du 4x Dualrank-Module verbaust (Vollbestückung).
Mit meinem 5600X und den 4x 16GB Dualrank ECC, Samsung B-Die!, geht max. 3066 bei 1.37V für die Dimms. 3200 bootet damit nicht mehr. Im Handbuch wird bei 4xDR Modulen 2933 spezifiziert.
Man könnte da jetzt noch mit async IF und Speicher rumspielen, aber das ist kontraproduktiv. Lieber 3066 synchron.

 

[supernode]

Ok danke. Rund 15% Mehrleistung bei 100% Aufpreis ist halt schon ne Ansage (3950X -> 5950X). Da ist man dann schon fast im Epyc Bereich.
Dann könnte ich ja auch einen 3000er nehmen und dafür mit mehr Cores. Alternativ wär wohl ein 5800X ne preislich akzeptable Lösung.
Die Idle Stromaufnahme bei den beiden CPUs ist nahezu identisch soweit ich dazu im Netz was finde.

@Trambahner Danke für die vielen Messwerte. Wär mal interessant wie sich bspw. ein Xeon mit den ganzen Lüftern, Controllern und Platten schlägt. Intel sagt man ja nach dass der etwas sparsamer ist. Ob 80 oder dann 70 Watt gehen dann aber auch unter.
Darf ich fragen wür was du neben dem großen Server noch den DeskMini laufen lasst? Übernimmt der dann die 24/7 Aufgaben und der Große wird schlafen gelegt?

Eine Anfängerfrage noch: Was würde sich denn jetzt besser anbieten: ESXi oder doch besser Proxmox? Soweit ich das nun mitbekommen hab ist bei den Storage Themen häufiger ESXi im Einsatz und Proxmox eher für die typischen Virtualisierungsthemen typischer Heimserver.

 

[maxblank]

ESXi free ist zum Teil beschnitten, was zum Beispiel die Backup-API betrifft oder das Verschieben von VMs im laufendem Betrieb auf eine andere LUN / Storage.

 

[tar]

Eine Anfängerfrage noch: Was würde sich denn jetzt besser anbieten: ESXi oder doch besser Proxmox? Soweit ich das nun mitbekommen hab ist bei den Storage Themen häufiger ESXi im Einsatz und Proxmox eher für die typischen Virtualisierungsthemen typischer Heimserver.

Einfach verwaltbare Storage inkl. Docker und VMs: Unraid
Bester Hypervisor: ESXi (unfree, ofc)
Dazwischen: Proxmox (für viele Funktionen muss man die Shell bemühen)

 

[supernode]

Wenn ich nun ZFS nutzen möchte um schleichende Datenkorruption zu eliminieren, was wäre dann die beste Wahl?
Ich nehme mal an dass die 3 in Bezug auf VM-Performance ziemlich ähnlich sind?

- Die Lizenzkosten für ESXi sind für die Heimnutzung zu hoch und wohl auch nicht nötig. Es bliebe also ESXi Free-Edition und für meine Standardaufgaben zu Hause reicht das wohl auch?!

- Proxmox kann ja ZFS nativ (hatten wir ja oben schon) aber man sollte trotzdem ne extra VM aufsetzen damit das einfacher administrierbar und portierbar ist. Aufgrund von Open Source sehe ich da weniger die Gefahr dass der Hersteller die Free-Edition einstellt...

- Unraid Lizenz mit 100€ wär für zu Hause Okay. Das AsrockRack Board wird wohl auch gut unterstützt.
Unraid kann ZFS wohl nur über ein Plugin aber auch da eher alles auf dem manuellen Weg + man verliert die HDD Schlaffunktion.
ZFS sollte also auch hier in die VM und dann stellt sich mir die Frage ob man in Unraid noch einen Mehrwert hat.
Wenn man die NAS Funktion von Unraid (ohne ZFS) nutzt zusammen mit 10G bräuchte man wohl nen NVMe Cache, d.h. das hätte dann Auswirkung auf den Hardwareaufbau.

 

[Digi-Quick]

TrueNAS und XigmaNAS bringen auch 'nen Virtualisierer mit und sind im ggs. zu Unraid kostenlos!

TrueNAS : Ich kann ich leider nicht rausfinden welcher das gegenwärtig ist (FreeNAS hatte erst Virtualbox und später Bhyve, der direkte Dokkersupport war nur Kurz verfügbar.)
XigmaNAS : Virtualbox

evtl. ginge auch OMV mit ZFS_Plugin (ist das mitlerweile vernüftig bedienbar / verwaltbar und funktionell ausgereift? - habe mich damit nicht mehr weiter beschäftigt)

 

[tar]

Wenn ich nun ZFS nutzen möchte um schleichende Datenkorruption zu eliminieren, was wäre dann die beste Wahl?

Im Heimbereich sind ECC-Fehler, Bitrot und Datenrost sehr unwahrscheinlich. Letztlich hilft gegen Datenkorruption nur ein Backup. Raids gleich welcher Art ersetzen kein Backup.

Ich nehme mal an dass die 3 in Bezug auf VM-Performance ziemlich ähnlich sind?

Ich habe vor etwa 2 Jahren folgendes getestet:
- in Windows unter VMware Workstation eine ESXi-VM erstellt und darin eine Windows-VM (VMware) erzeugt
- in Windows unter VMware Workstation eine Unraid-VM erstellt und darin eine Windows-VM (KVM) erzeugt
- separat zu beiden Windows-VMs direkt per Remote Desktop verbunden
- Fazit: die VM unter der ESXi-VM lief flüssiger

Im Netz wird allerdings gegenteilig davon berichtet, dass KVM performanter sei, dafür sei VMware eleganter/einfacher zu handhaben (man kann sich bspw. mit VMware Workstation direkt zu den VMs in ESXi verbinden).

- Die Lizenzkosten für ESXi sind für die Heimnutzung zu hoch und wohl auch nicht nötig. Es bliebe also ESXi Free-Edition und für meine Standardaufgaben zu Hause reicht das wohl auch?!

Das kannst du nur selbst testen, ob dir das reicht.

- Unraid Lizenz mit 100€ wär für zu Hause Okay. Das AsrockRack Board wird wohl auch gut unterstützt.
Unraid kann ZFS wohl nur über ein Plugin aber auch da eher alles auf dem manuellen Weg + man verliert die HDD Schlaffunktion.

Ist bei ZFS nicht per se die Schlaffunktion unmöglich?

 

[p4n0]

Im Heimbereich sind ECC-Fehler, Bitrot und Datenrost sehr unwahrscheinlich. Letztlich hilft gegen Datenkorruption nur ein Backup. Raids gleich welcher Art ersetzen kein Backup.

Oh, da steckt irgendwie ganz viel falscher Inhalt drinnen.
Es ist egal ob zu Hause oder im Datacenter. Fehler passieren ueberall. Die warscheinlichkeit ist nicht geringer, nur wenn die Kiste daheim steht.
Gegen Datenkorruption hilft ein Backup uebrigens nicht. Es muss eine Instanz her, welche mitbekommt dass die Daten faelschlicherweise geaendert wurden.
In dem Fall ein modernes Dateisystem wie ZFS

 

[gea]

- Die Lizenzkosten für ESXi sind für die Heimnutzung zu hoch und wohl auch nicht nötig. Es bliebe also ESXi Free-Edition und für meine Standardaufgaben zu Hause reicht das wohl auch?!

Die beiden wohl wichtigsten Einschränkungen der ESXi free
- Backup und VM verschieben im laufenden Betrieb ist nicht möglich (oder man muss etwas tricksen)

Für ersteres hat man die ZFS Storage VM, die macht Snapshots, Backup und schnelles copy/move z.B. via zfs send oder SMB quasi nebenher. Selbst "hot" Backups also laufende VM mit RAM Inhalt sind möglich. Zum Verschieben einer VM muss man die halt kurz herunterfahren. Dank ZFS Snaps hat man allerdings nur eine Downtime (shutdown, aktuelles sync, import, poweron) wenns darauf ankommt von 2-3 Minuten bis eine VM auf einem anderen Server wieder läuft.

Der Hauptvorteil von ESXi (warum ich ESXi nutze))
- best of all Performance
- best of all Unterstützung beliebiger Gäste (BSD, Linux, OSX, Solarish, Windows)
- minimalster Resourcenverbrauch für den VM Server, eher eine Firmware, kein fettes OS
- schnellste Wiederherstellung selbst im Crashfall Bootplatte defekt (ESXi Neuinstallation oder Reserveplatte, VM Import)
- völlige Trennung/ Unabhängigkeit von Virtualisierer, Storage und Diensten, Die Alternative ist "irgendetwas zickt=alles instabil"

Letzteres ist vor allen angesichts der dauernd nötigen "kritischen" Sicherheitsupdates auf den verschiedenen Betriebssystemen/ Diensten ein Riesenvorteil.

 

[underclocker2k4]

- Backup und VM verschieben im laufenden Betrieb ist nicht möglich (oder man muss etwas tricksen)

Ich bin der Meinung, dass man mit Veeam vom free ESX ein Backup on the fly machen kann.

 

[gea]

VMware tut halt alles um das nicht zu unterstützen, Es geht wenn andere Anbieter ESXi free irgendwie unterstützen und das meinte ich mit "tricksen". Ist aber in Verbindung mit einer ZFS SAN/Storage VM aber eh nur akademisch. Die bieten storagemäßig in allen Punkten 1000% mehr als ein nacktes ESXi.

 

[Trambahner]

5900X/5950X stehen IMO aktuell ausser Frage, weil schlecht verfügbar und teuer; da stimm ich zu.

Der Deskmini ist aktuell Bastel-/Versuchsplattform. Soll dann in er 2. Jaherhälfte mal OpnSense-Box werden, wenn unsere 1Gbit-Internetanbindung da ist. Darum auch getrimmt auf Idle-Sparsamkeit und geringe Lautstärke und nicht absolute Performance. Darum auch der kleinste Renoir, der spart Idle nochmal ein kleinwenig ggü den 6/8-Kerner. Mit ~10-15W ist das Ding ja annäherndin der Größenordnung einer Fritzbox. Gut, Gfast-Modem muss man dann noch rechnen.

Yup, die große Kiste ist nur an bei Bedarf. Nicht 24/7. Dito die Backupmaschine (das ist der 1240v5 auf X11SSH-CTF, die vorherige Hauptmaschine), die ist nur beim Backuppen an.

 

[tar]

Oh, da steckt irgendwie ganz viel falscher Inhalt drinnen.
Es ist egal ob zu Hause oder im Datacenter. Fehler passieren ueberall. Die warscheinlichkeit ist nicht geringer, nur wenn die Kiste daheim steht.

Wo finde ich die zahlreichen Berichte von Bitrot und Datenrost im Heimbereich?
Wo finden sich die lebenswichtigen, tagelangen Berechnungen für eine ECC-Notwendigkeit im Heimbereich?

Die Wahrscheinlichkeit, dass derlei Dinge überhaupt auftreten und dann noch irgendwas superwichtiges verloren geht, ist bereits aufgrund des geringeren Datenaufkommens im Heimbereich ggü. einem Datacenter wesentlich niedriger.

Gegen Datenkorruption hilft ein Backup uebrigens nicht. Es muss eine Instanz her, welche mitbekommt dass die Daten faelschlicherweise geaendert wurden.
In dem Fall ein modernes Dateisystem wie ZFS

Für den Heimbereich (wohlgemerkt: da geht es um private Fotos & Dokumente und nicht um die NASA-Berechnung zur Mondreise) reichen Checksummenprüfungen beim Backuppen und sporadische Jobläufe, die eben diese Checksumme(n ) zwischen 2 Backups abgleichen. Bei ZFS läuft das sinnfreierweise permanent und man muss mit zahlreichen Nachteilen leben:
- keine flexible Kapazitätsskalierung, d.h. bei RaidZx müssen alle Platten dieselbe Größe haben, wird bei Upgrade teuer
- da man alle Platten auf einmal upgraden muss und sich diese hierfür im selben Zeitfenster anschafft, erhöht sich bei einem Plattenausfall die Ausfallwahrscheinlichkeit einer weiteren Platte während des Rebuilds -> alles Pfutsch (grundsätzliches Raidproblem)
- höhere Plattenauslastung und damit Stromkosten, da kein Sleepmodus

ZFS schützt auch nicht gegen Datenkorrumption, weswegen man nachwievor Backups benötigt.

 

[underclocker2k4]

Wo finde ich die zahlreichen Berichte von Bitrot und Datenrost im Heimbereich?
Wo finden sich die lebenswichtigen, tagelangen Berechnungen für eine ECC-Notwendigkeit im Heimbereich?

Die Wahrscheinlichkeit, dass derlei Dinge überhaupt auftreten und dann noch irgendwas superwichtiges verloren geht, ist bereits aufgrund des geringeren Datenaufkommens im Heimbereich ggü. einem Datacenter wesentlich niedriger.

Wieso sollte die Wahrscheinlichkeit geringer sein? Die Wahrscheinlichkeit ist gleich, da beide Welten auf die selbe Hardware setzen.
Also sagen wir mal, 1% aller Daten sind nach 30 Tagen Müll.

Jetzt ist es im Datacenter nur so, dass die absolute Menge an Daten deutlich größer und damit auch die größere absolute Menge an Mülldaten entsteht.

Sprich @home sind es 30GB und im DC sind es dann 30PB, weil die die 1-miofache Menge verarbeiten.
Die Wahrscheinlichkeit ist aber die Gleiche.

Ob nun ZFS das richtige ist oder nicht, wird man dann merken, wenn man seinen Enkeln die Bilder deren Eltern vermachen möchte, wenn man mal ins Grab steigt. Dann zeigt sich, wie gut der digitale Schuhkarton wirklich war. (denn den analogen gibt es dann nicht mehr)
Und da würde ich auf die paar 100EUR liebend gerne verzichten.
ZFS bedeutet ja nicht, dass man plötzlich 20er Arrays bauen muss.
Ein ZFS kann auch einfach nur aus z.B. 2-3 Platten bestehen.
Zudem kann man das ZFS auch für das Backupstorage verwenden.

Der Vergleich zwischen ZFS und Backup ist in etwa so sinnvoll wie der Vergleich zwischen RAID und Backup oder Apfel mit Birne oder Gold und Porsche 911.
Die haben jeweils nur im Grundsatz etwas miteinander zu tun, zielen aber jeweils auf völlig verschiedenen Sachen ab.

PS:
Was soll Datenkorrumption sein?
Ist bekannt dass das Substantiv zu korrumpieren die Korruption ist?

EDIT:
Die Fehler treten also mit der gleichen Wahrscheinlichkeit auf. Der Unterschied ist nur, dass das im DC Tagesgeschäft ist, wohingegen das bei einem selber 1x im Jahr oder 1x im Jahr in der gesamten Straße auftritt. In allen Fällen ist es aber so, dass man nicht der Gearschte sein will.
Und da es eben im DC öfter passiert setzt man da auch mehr Fokus drauf, weil es zu dem oftmals auch unternehmenskritisch ist.
Das heißt aber nicht, dass man @home sorgenfrei schlafen kann und man kugelsicher ist. Vieles bekommt man auch garnicht mit.
Wenn einem das NAS mal abschmiert, kein Problem, 1x neu booten, ok. Passiert das im Unternehmen, warten alle Leute erstmal.
Wenn es aber rumpelt, dann rumpelt es richtig. Man kann ja mal ein paar Datenretter fragen, wieviele Anrufe wie von Privatleuten haben und was man davon durch geeignete Gegenmaßnahmen erledigen kann.
Wenn im DC ne HDD stirbt, dann "schmeißt" man die weg. Stirbt der Controller im Clustermember des SAN, setzt sich der Admin gerade an den Tisch. Stirbt ein Clustermember im SAN, kommt der Admin langsam in Wallung.
@home ist immer sofort Party.

Und auch so nen totalcrash eines USB-Stack einer Backupplatte kann schon sehr viel Spaß bereiten. USB ist in etwa so unzuverlässig wie die DB...

2ndEDIT:
Wenn man sich über Wahrscheinlichkeiten unterhält, sollten sich ggf. mal vorher schlaulesen, was das mit dieser Wahrscheinlichkeit, Stochastik und Statistik so auf sich hat.
Die Wahrscheinlichkeit ist in beiden Welten in etwa gleich, da, mal abgesehen von Spezialrechnern, beide Welten auf die annähernd selbe Technik setzen.

Der Unterschied liegt in der absoluten Häufigkeit (sprich die absolute Menge) des Auftreten von Fehlern.
Wer 1x im Jahr "Mensch ärgere Dich nicht" spielt der verliert halt deutlich seltener als jemand der das 200 Tage im Jahr 10h am Tag spielt. In beiden Situationen ist die Wahrscheinlichkeit des Verlierens gleich. Nur ist Letzterer ggf. deutlich gefrusteter.

 

[tar]

Was soll Datenkorrumption sein?

🤪 Damit meinte ich das ungewollte Ändern einer Datei durch den Benutzer (falschen Knopf gedrückt, Trojaner, Virus) und nicht durch die Hardware. Datenmanipulation wäre wohl das treffendere Wort.

 

[underclocker2k4]

Dennoch heißt das Datenkorruption, ohne den, von dir falsch, eingefügten Buchstaben "m", so wie es p4n0 auch geschrieben hat.
Wenn man schon auf Rechtschreibfehler hinweist, dann sollte man auch Sattelfest sein.

EDIT: Und dennoch schützt ZFS genau dagegen (Datenmanipulation). Da es im Hintergrund die Daten nicht überschreibt, sondern quasi eine Versionierung auf Filesystemebene realisiert.
Sprich, ein Trojaner kann alles Löschen oder verschlüsseln und die Daten sind dennoch vollständig wiederherstellbar.
Ist dir denn die Funktionsweise von ZFS überhaupt bekannt? Scheint mir nämlich nicht so.

ZFS ist kein moderner Abklatsch von RAID. Es ist viel viel mehr. Es spricht z.B. genau solche Problem aktiv an.

 

[tar]

Dennoch heißt das Datenkorruption, ohne den, von dir falsch, eingefügten Buchstaben "m", so wie es p4n0 auch geschrieben hat.
Wenn man schon auf Rechtschreibfehler hinweist, dann sollte man auch Sattelfest sein.

Das war von mir nur überhaupt kein Hinweis auf einen Rechtschreibfehler

Übrigens gehen auch deine Ausführungen bzgl. der Wahrscheinlichkeit an meiner Aussage vorbei

 

[Trambahner]

Auch private Fotos + Dokumente sind nicht zu unterschätzen. Da können viel Emotionen dran hängen.
Ich jedenfalls möchte auch da keine defekten Files. Und ich hatte defekte Bilder und Zip-Files in der tieferen Vergangeheit. Mit Hw-Raid. Ob es die HDDs oder der Ram waren, kann ich nicht mehr sagen.
Nie wieder passiert seit 2013 seit ich ZFS und ECC-Ram verwende.

Daher: Main-Filer = ZFS mit ECC mit regelmässig Snapshots, Backup-Filer = ZFS mit ECC in anderer Brandzone, auch mit zusätzlichen Snapshots. Annähernd nur Enterprise-Hw.
Nicht billig, das ist richtig. Aber es ist es mir wert.

Und mit den 2k Euro des TE ohne Platten kann man auch schon Vernünftiges bauen.

 

[tar]

Und dennoch schützt ZFS genau dagegen (Datenmanipulation). Da es im Hintergrund die Daten nicht überschreibt, sondern quasi eine Versionierung auf Filesystemebene realisiert.
Sprich, ein Trojaner kann alles Löschen oder verschlüsseln und die Daten sind dennoch vollständig wiederherstellbar.
Ist dir denn die Funktionsweise von ZFS überhaupt bekannt? Scheint mir nämlich nicht so.

Das ist mir neu! Danke - dann wäre es in der Tat ein sinnvoller Schutz.

 

[underclocker2k4]

@tar
Ok, dann hat dein Editor automatisch das "m" eingefügt und es unterstrichen oder ein anderer User war am Rechner.
?_?

Deine Aussage war, dass die Wahrscheinlichkeit @home deutlich niedriger ist.
Das ist falsch! Die absolute Häufigkeit des Auftreten von Problemen mag @home geringer sein, aber nicht die Wahrscheinlichkeit.
Siehe auch den Edit oben.

Was du meinst ist also nicht die Wahrscheinlichkeit, sondern die absolute Häufigkeit, dass mal was in die Fritten geht.
Und diese Häufigkeit ist @home in der Tat geringer als im Datacenter.
Und das kann wohl jeder so unterscheiben.
Dennoch bleibt die Wahrscheinlichkeit in beiden Fällen annähernd gleich, weswegen man im DC Aufwand treibt, dass es nicht zu so solch negativen Auswirkungen kommt.

 

[tar]

@tar
Ok, dann hat dein Editor automatisch das "m" eingefügt und es unterstrichen oder ein anderer User war am Rechner.
?_?

Nein - ich wollte auf das hinaus, was ich dir gerade beschrieben hatte, also den Unterschied zwischen der ungewollten Datenveränderung durch die Hardware (Bitrot, Datenrost) und durch den Nutzer (Trojaner, ...).

Deine Aussage war, dass die Wahrscheinlichkeit @home deutlich niedriger ist.
...

Die Wahrscheinlichkeit, dass es auftritt und dabei etwas wichtiges betroffen ist, ist geringer. Das logische UND bitte nicht überspringen 🤓

Irgendwie scheinen wir beide ein Kommunikationsproblem zu haben - das fiel mir schon bei dem U.2-Zeug auf.

 

[underclocker2k4]

OK.
Deine Aussage war:

Die Wahrscheinlichkeit, dass derlei Dinge überhaupt auftreten und dann noch irgendwas superwichtiges verloren geht, ist bereits aufgrund des geringeren Datenaufkommens im Heimbereich ggü. einem Datacenter wesentlich niedriger.

"derlei Dinge" sind

Im Heimbereich sind ECC-Fehler, Bitrot und Datenrost sehr unwahrscheinlich. Letztlich hilft gegen Datenkorruption nur ein Backup. Raids gleich welcher Art ersetzen kein Backup.

Woran machst du bitte fest, was wichtig ist oder nicht?
Was ist wenn @home alles als wichtig deklariert ist?
Wenn Mutti dich jedes Mal aus dem Bett wirft, wenn Netflix und Unter Uns nicht läuft, weil das Switch mal wieder hops gegangen ist?
Und wenn das einzige, was @home läuft, das NAS mit den Kinderbildern ist, dann hast du 100% wichtige Sachen.
Und diese haben ein persönliches Kritikalitätslevel von -10, da für einen persönlich Tschernobyl ein Kindergeburtstag war.

Und genauso gibt es im Datacenter ein Haufen Geräte/Systeme, da bekommt niemand mit, dass die gerade nicht laufen.

Und viele nonHighend-19"-42HE User haben @home so gut wie keine Dienste laufen außer die Fritzbox mit dem WLAN fürs Netflix und eben das NAS (oder ne (USB)Platte) mit den ganzen Bildern/Videos.

Das heißt also, dass die Wahrscheinlichkeit des Befalls eines wichtigen Systems @home sogar höher ist (sein kann) als im Datacenter.
Jetzt können wir in die Diskussion natürlich noch die Schadensauswirkung mit einkalkulieren. Die können wir dann in Wirtschaftsschäden, Umweltschäden, Personenschäden, immaterielle Schäden und weitere Schadensmodelle untergliedern.
Nur wie gewichten wir jetzt die Schadensmodell gegeneinander, dass dies allgemeingültig wird?
Ich denke, dass der IT-Welt dazu noch fundierte Normen fehlen.

Woher kommt also das Wissen über die relative Verteilung von wichtigen und unwichtigen Systemen @home und im DC, sowie die Klassifizierung aller Systeme in wichtig und unwichtig?

Die Formel lautet:
GAU-Auftretenswahrscheinlichkeit * relative Verteilung wichtiger Systeme = Auftretenswahrscheinlichkeit bei wichtigen Systemen
Und das geht "fürs" DC nur auf, wenn im DC, relativ gesehen, mehr wichtige Systeme sind als @home.

Die absolute Häufgkeit, dass wichtige Systeme betroffen sind, ist im DC natürlich höher.
Rest steht dann oben.

Mir scheint auch, dass wir da ein Kommunikationsproblem haben.
Das liegt primär daran, dass du Sachen die du dir irgendwie zusammenreimst oder ungefragt irgendwo aufschnappst als Faktenwissen kundtust. Und dieses Faktenwissen von der realen Welt massiv abweicht.
Und da springe ich natürlich drauf an.

 

[tar]

Aus meiner Sicht machst du aus einer Mücke einen Elefanten, indem du simple Aussagen überhöht sezierst, während durch kurzes Nachhaken völlig klar ist, was jemand (in dem Fall: ich) meinte (siehe auch U.2-Thema). Dass dir deine Zeit dafür nicht zu schade ist, spricht Bände.

 

[underclocker2k4]

Mag sein, dass alternative Fakten für dich eine Mücke sind.
Ich kann Desinformation aber nicht leiden und zwar im tiefsten meiner Seele.
Und daher springe ich darauf an und stelle das auch richtig, sofern ich in der Lage bin das richtig zu stellen.

Bei dem U.2 Thema brauch ich auch nicht nachhaken, was du meinst, weil ich weiß was du meinst. Daher habe ich auch direkt klargestellt, was korrekt ist.

10G + ECC + ZFS | Xeon-E/W vs. Ryzen

Hallo, seit einigen Wochen sitze ich nun an den Vorüberlegungen für einen leistungsstarken Homeserver. Leider bin ich in dem Server-Hardware-Sektor weniger aktiv weshalb ich euch um Hilfe bitten möchte. Speziell bei den Mainboards und Storage Controllern fehlt mir der Einblick welche Modelle...

www.hardwareluxx.de

Wozu soll ich da nachhaken.
Alles was danach kam, diente nur dazu herzuleiten, woher du dieses Falschwissen hast und dich und alle anderen die das (mit)lesen dabei gleichzeitig noch aufzuschlauen. Und das alles in der Hoffnung, dass sich das festsetzt und sich damit das Wissen und nicht das Unwissen verbreitet.

Und ja, das spricht Bände, dass mir meine Zeit nicht zu schade ist. Ich hoffe nämlich, dass die Leute lernen wollen, wenn gleich ich weiß, dass es so einige gibt, die das nicht wollen oder auch nicht können.

Ich weiß schon wo das fehlerhafte Wissen im Grundsatz herkommt, weil ich nämlich viel lese und dabei auch so manchen Schwachsinn lesen muss und das mit meinem Wissen gegenprüfen kann. Und dann die Fragezeichen aufgehen.
Und dabei ist vieles "einfach" zu validieren. Nur kostet die Recherche eben Zeit, die klar nicht jeder hat.
Daher bin ich mir nicht zu fein, diese Recherche für mich zu betreiben und die notwendige Essenz selbiger dann hier zu kommunizieren.

Mag für dich idiotisch klingen, genauso wie für mich solche alternativen Fakten idiotisch klingen.

Ich gehe ja auch nicht ins AMG-Forum und erkläre denen, wie sie den V12 richtig einzustellen haben, nur weil ich im MB-Autohaus den neuen AMG Prospekt mitgenommen habe. Da habe ich nämlich soviel Ahnung von wie vom Flug einer Mondrakete.

EDIT:
Ich lerne natürlich auch gerne dazu. Die Allwissenheit beanspruche ich für mich nicht.
Wenn hier also jemand Fehler meinerseits aufzeigt, dann nehme ich das gerne an und versuche das Wissen an der Stelle zu präzisieren. Genauso lerne ich auch völlig neue und unbekannte Sachen, um diese dann, sofern sinnvoll/Zeit/etc. wieder zu vertiefen.