[Guide] NAS/Server Hardwareguide 2020

Status
Für weitere Antworten geschlossen.
Gut... Recht schwaches Argument aus meiner Sicht. Aber egal, wird schon 👍
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dann gibt es keinen Weg um Supermicro oder AsusRack vorbei.

Es bleibt nicht bei SM und AsrockRack.
Gigabyte stellt ähnliche Boards für die AM5 Plattform bereit, im Gegensatz zu ersteren beiden Herstellern ist auch eine Verfügbarkeit bei den üblichen Retailern gegeben.
 
Zuletzt bearbeitet:
Was wäre eine Anwendung für die Kombination aus ECC-RAM (Fehlerentdeckung/-behebung) und XMP (Speicher(controller)übertakten)? Normale DIMMs haben JEDEC Profile und die sollten auch vollkommen ausreichen.

Ich habs nur als Feststellung geschrieben, damit typische Consumer/PC-Bauer das nicht verzweifelt suchen wenn sie im Forum z.B. suchen; weil die sind das gewohnt einzustellen. Die sind typischerweise selten mit ECC-/Servermodulen unterwegs.

Abgesehen davon jage ich die Module (dann natürlich manuell) durchaus (moderat), wenn ich weiss dass es zuverlässig funktioniert. Eben besagte B-Dies z.B. Nachdem ich dann ECC-Meldungen im Windows Eventviewer hatte, wusste ich; a) ECC-Meldung ans OS funktioniert und b) bisserl bremsen.

--
Btw, auch auf Asus-Platinen geht ECC oft bei AM4; Asrock sind nicht die einzigen. Bei MSI dagegen funktioniert es nach meiner Kenntnis annähernd nie. Daher sehe ich auch keinen wirklich Sinn darin, ECC-Module in eine QVL zu schreiben, wenn sie dann eh im Non ECC-Modus laufen. Sowas ist reichlich sinnfrei, denn ein typischer Consumer/Gamer wird nicht ECC-Module kaufen und jemand der ECC will, kein MSI.

Unter Windows kann man einen ersten Test auch im Termnal so machen:
Code:
wmic MEMORYCHIP get DataWidth,TotalWidth

Wenn die DataWidth 64 und TotalWidth 72 ist => ECC-Modus grundsätzlich schonmal erkannt. Wenn dann auch noch bei ECC-Fehlerinjektion oder etwas zu scharfen Timings entsprechende Einträge im Eventviewer auftauchen (WHEA ID 47 - Behobener Hardwarefehler - Komponente Arbeitsspeicher - Fehlerquelle: Machine Check Exception) auftaucht => dann wirds auch sauber ans OS gemeldet.
 
Zuletzt bearbeitet:
Unter Windows kann man einen ersten Test auch im Termnal so machen:
Code:
wmic MEMORYCHIP get DataWidth,TotalWidth

Wenn die DataWidth 64 und TotalWidth 72 ist => ECC-Modus grundsätzlich schonmal erkannt. Wenn dann auch noch bei ECC-Fehlerinjektion oder etwas zu scharfen Timings entsprechende Einträge im Eventviewer auftauchen (WHEA ID 47 - Behobener Hardwarefehler - Komponente Arbeitsspeicher - Fehlerquelle: Machine Check Exception) auftaucht => dann wirds auch sauber ans OS gemeldet.
Klingt super! Kann ich das auch mit Windows PE feststellen? *gg*
Hab nur TrueNAS installiert. ECC ist aktiviert im BIOS, sonst kenn ich keine entsprechenden Befehle unter Linux, um festzustellen, ob ECC wirklich genutzt wird... Kennst du da auch entsprechende Möglichkeiten um das festzustellen?
 
Zuletzt bearbeitet:
Verständnisfrage:
bspw. 4 QLC SSD im Raid5. Diese brechen unter Schreiblast beim Aufbrauchen des SLC-Caches auf z.B. nur noch 150MB/s ein. Kann das das Raid5 nicht kompensieren? Sodass beim langen und intensiven Schreiben im QLC-Modus mehr als 150MB/s geschrieben werden können?
Danke!
 
Nö, wo sollen die Daten denn hingeschrieben werden wenn nicht auf die SSDs ?
 
Selbstverfreilich sorgt ein RAID dafür, dass die Daten parallel gleichzeitig auf die Volumes verteilt werden, steigert somit die Schreib- und Lesegeschwindigkeit - nicht jedoch die AccessTime aka Kopfpositioniergeschwindigkeit bei Festplatten. Im Gegenteil, man muss immer auf die langsamste Platte warten bis die Daten vollständig sind. D.h. die Zahl der random I/Os pro Sekunde steigt nicht mit einem größeren RAID (mehr Disks), sondern sinkt. Schneller wird es nur wenn kontinuierlich Daten geschrieben/gelesen werden, also z.B. große Filmdateien.
Das entfällt natürlich komplett bei SSDs - aber zaubern kann ein RAID auch nicht. Wenn der SLC-Cache der einzelnen Platten voll ist (d.h. insgesamt N mal Cache-Größe geschrieben werden sollen), dann bricht auch beim RAID die Schreibrate ein. Wie schon p4n0 schrub - wo sollen die Daten denn sonst hin?
 
Das entfällt natürlich komplett bei SSDs
Das verhällt sich bei SSDs genauso.
Es gibt auch bei SSDs Latenzen, genauso wie sie es bei HDDs gibt. Gleiches gilt für die Datenrate.
Der Zusammenhang zwischen Latenz und Datenrate ist bei SSDs genauso wie bei HDDs.
Es können erst weitere Daten geschrieben werden, wenn der vorhergehende Schreibprozess abgeschlossen ist und das System nach der Latenz wieder bereit steht.
Der einzige Unterschied zwischen SSDs und HDDs ist, wo diese Latenz herkommt. Da ist bei der HDD die Kopfposition nur ein Teil, wenngleich der überwiegende. Ein weiteres Merkmal ist, dass SSDs das, theoretisch, auch intern parallel können. Das kommt aber auch den Controller und dessen Firmware an. Aber auch HDDs können das parallel, denn die haben ja auch mehrere Köpfe, wenngleich das nicht unabhängig ist, wie es bei SSDs der Fall ist.
Bei SSDs ist es primär erstmal die Zeit, die der Controller braucht sich zu sortieren und die Daten auf dem Flash abzulegen und dann ein rdy zurückzumelden.

Das Problem bei >SLC SSDs ist, dass in den Speicherzellen Organisationsprozesse stattfinden. Und die werden bei immer höherem Level eben zunehmend ein Problem.
Daher ist SLC-Cache eine Kaschierung und gaukelt dem User eine Geschwindigkeit vor, die er eben nur unter ganz bestimmten Gesichtspunkten hat. Grob kann man die SSD als bei QLC nur zu 1/4 befüllen. Ab dann rödelt sich die SSD einen ab.
Die alten Hasen kennen das noch von den Defragmentierungsarien bei HDDs. Das war am Ende nichts anderes, als dass man der HDD geholfen hat die Daten wieder in die richtige "Reihenfolge" zu bringen. Mit dem Unterschied, dass bei der HDD "optional" war, die Reorga bei SSDs ist aber notwendig.

Kurzum, die Latenz der SSD steigt für eine Schreiboperation, genauso wie sie eben bei einer HDD auch der Fall ist.
Und darunter leidet dann irgendwann die Datenrate, da man immer mehr wartet als wirklich zu arbeiten, wenn man so will.
Und da kann ein RAID auch nicht mehr helfen. Wenn alle SSDs im RAID5 sich einen abkaspern mit dem hin- und herkopieren, dann muss man eben warten. Wovon du aber ausgehen kannst, dass deine IOPS größer ist, als wenn du eine einzelne SSD hast.


D.h. die Zahl der random I/Os pro Sekunde steigt nicht mit einem größeren RAID (mehr Disks), sondern sinkt. Schneller wird es nur wenn kontinuierlich Daten geschrieben/gelesen werden, also z.B. große Filmdateien.
Das ist Unsinn. Vornehmlich diente RAID dem Erhöhen der IOPS.
Sprich da, wo man mit einer HDD nicht mehr hingekommen ist, hat man, bei Kapaeffizienz, einfach solange mit HDDs draufgehauen, bis die IOPS wieder im Rahmen waren.
Das hat Grenzen und ist nicht vergleichbar, was SSDs können. Aber im RAID gilt/galt je mehr HDDs, desto mehr IOPS.

Was bei sowas hilft, wenn man SLC-Cache-Gelumpe einfach weglässt. Denn der initiale max. Speed bringt die später auch nichts. Lieber schreibe ich halbwegs konstant mit 1GB/s anstatt mit kurz 6GB/s und dann später mit 200MB/s.
Auch sollte man nicht vergessen, dass es einen Unterschied zwischen Enterprise und Consumer gibt. So ne Enterprise SSDs ist eben auf eine ganz bestimme workload hin optimiert zusammen mit den internen Routinen und auch dem Interface (SAS vs. SATA)
 
Zuletzt bearbeitet:
> D.h. die Zahl der random I/Os pro Sekunde steigt nicht mit einem größeren RAID (mehr Disks), sondern sinkt.

Das ist Unsinn. Vornehmlich diente RAID dem Erhöhen der IOPS.
Sprich da, wo man mit einer HDD nicht mehr hingekommen ist, hat man, bei Kapaeffizienz, einfach solange mit HDDs draufgehauen, bis die IOPS wieder im Rahmen waren.
Das hat Grenzen und ist nicht vergleichbar, was SSDs können. Aber im RAID gilt/galt je mehr HDDs, desto mehr IOPS.
Wie soll denn das gehen?
Ich verteile bei einem RAID-5 z.B. einen Datenblock auf 4 Daten-Disks plus einer Parity-Disk. D.h. um diesen Block zu schreiben müssen 5 Disks eine bestimmte Position anfahren - fertig ist man wenn auch die langsamste Disk fertig ist.
Natürlich kann man beim Schreiben knapp die 4fache Menge Daten in derselben Zeit wegschreiben, weil jede Disk nur 1/4 der Menge schreiben muss. D.h. bis die Disk den Track wechseln muss und wieder eine Kopfpositionierung erfolgt, dauert es entsprechend länger, bzw. man hat beim Schreiben 3/4 weniger Kopfpositionierungen. Und man muss ja im Schnitt immer noch eine halbe Umdrehung warten bis der richtige Sektor unter dem Lesekopf vorbeikommt.
Aber beim Lesen nutzt das gar nix. Wenn man Datenbankzugriffe wild über die Platte verteilt hat, müssen ALLE Disks alle Tracks anfahren auf denen die Daten liegen. Wenn die Daten dann eher auf benachbarten Tracks liegen geht die Positionierung minimal schneller als bei einer einzelnen Disk. Aber man muss dann trotzdem bei jeder Transaktion die halbe Umdrehung warten. Wenn man mehr Disks hat, hat die eine den richtigen Sektor nach einer Viertelumdrehung, die andere evtl. aber erst nach einer Dreiviertelumdrehung. Zusammensetzen und ausliefern kann man den Block aber erst nachdem ALLE Disks den Sektor gelesen haben. D.h. die Wartezeit STEIGT mit der Anzahl der Disks.

OK, dafür hat man Caches. Die eine Platte kann schon den nächsten Track anfahren während die Nachbarplatte noch auf den Sektor wartet.
 
Zuletzt bearbeitet:
Selbstverfreilich sorgt ein RAID dafür, dass die Daten parallel gleichzeitig auf die Volumes verteilt werden, steigert somit die Schreib- und Lesegeschwindigkeit - nicht jedoch die AccessTime
Darum gings mir. Hatte ich bei Raid5 auch so abgespeichert.
 
D.h. die Wartezeit STEIGT mit der Anzahl der Disks.
Wartezeit != IOPS, weder proportional noch disproportional oder sonstwie.
Evtl. bin ich auch einfach zu alt, um die Erfahrungen mit HDDs Storagesystemen zu haben.
Und auch sonst findet sich ein Haufen dazu.

Die Aussage, dass die IOPS mit der Anzahl der Platten sinkt(siehe oben), ist einfach Unsinn. Es war, wie gesagt, früher Standard, dass man da einfach mit viel Platten draufgehauen hat, wenn man IOPS brauchte. Mal von RPMs und SSDs ab. Denn letzteres gab es eh nicht.
Sprich also, die Aussage wird durch die verlinkte Theorie und auch die dortige und auch sonstige Praxis einfach widerlegt.
Noch heute schreien alt eingesessene Admins nach vielen vielen Platten, wenn es viele IOPS geht. Dass man das heute einfach mit nem kleinen Sack NVMe erschlägt ist klar, aber die Forderung kommt nicht von ungefähr.

Ich habe bestimmt noch irgendwo ein paar HDD Storageshelfs rumstehen, da kann ich gerne mal ein paar Benches bezüglich IOPS machen.

Darum gings mir. Hatte ich bei Raid5 auch so abgespeichert.
Die Datenraten ist aber kein absoluter Wert. Je länger du auf Rückmeldung vom System wartest, und die ist bei QLC dementsprechend, desto länger steht das System auf der Bremse und nichts passiert. Der wird zwar für 1ms mit 1GBE die Daten zwar wieder nachfüttern, dann rödelt der sich aber wieder einen ab beim Sortieren.

Wenn das ein Problem ist, geh auch Enterpreise, die haben TLC, später auch mal QLC, machen aber solche SLC-Schwachsinn nicht. Denn dort kommt es auf Realperformance an und nicht darauf, was das Ding bei Vollmond und Brunftzeit der Maikäfer macht.
 
Zuletzt bearbeitet:
Wollte zum Thema noch mal folg. Praxiserfahrung da lassen:

Betreibe 4x1TB MX500 (TLC) im Raid im NAS mit XPenology 6.1, Pentium G4500 (2 Kerne) und 8GB RAM.

100GB schreiben und lesen über 10Gbit und 3,5GB schreiben und lesen: Siehe Screenshots.
Die Schreibrate lastet 1 Kern komplett aus und liegt nur etwas (Faktor 1,2-1,5) über der möglichen Schreibrate der einzelnen SSD. Lesen schont die CPU und liegt bei Faktor 1,5-2 über der Single-SSD.

Ist jetzt keine Wissenschaft, aber eine interessante Tendenz.
100GB habe ich zwar nicht, aber 1-35GB schiebe ich in der Tat öfters hin und her.
IOPS sind mir persönlich Wurscht bzw. bei mir nicht relevant.
 

Anhänge

  • raid5_1.png
    raid5_1.png
    147 KB · Aufrufe: 73
  • raid5_3.png
    raid5_3.png
    133,3 KB · Aufrufe: 75
  • raid5_4.png
    raid5_4.png
    40,1 KB · Aufrufe: 74
@Master Luke

Welches Dateisystem nutzt du in Xpenology?

Das ist eines der entscheidenden Leistungsmerkmale beim RAID, der vermutlich als Software-RAID läuft, oder?
 
@fortunes
synology btrfs
Die SSDs sitzen am Chipsatz, aber das kann ja nur Software-Raid sein.
 
Wenn du im BIOS keinen RAID-Modus für die SATA-Ports aktiviert hast, läuft der Software-RAID über Xpenology und damit über die CPU. Das erhöht die Auslastung der CPU also nochmal.

Hört sich für mich daher plausibel an.

Deswegen nutze ich Unraid. Da laufen die 10GBit/s direkt auf die PCIe-SSD. Erst der Umschlag auf die Laufwerke ist dann recht langsam. Aber das passiert nachts, da ist mir das egal.
 
Hallo zusammen,

wusste nicht, ob ich für eine kurze Nachfrage einen Thread aufmache oder lieber in diesen 49 Seiten hier was dazuschreibe... machen ja anscheinend auch ein paa ;-)

Anyway, möchte kleinen Win(!) Homeserver/NAS betreiben. Ich weiß, Sinnfrage Win-Eignung - bitte so belassen wegen einiger Software, die da auch drauf laufen soll.

Ich habe zwei große HDDs, die im (Win-Software-)RAID 1 laufen (ja, Backup gibt es), und bisher auf ein Asrock J5040 ITX gesetzt. Macht alles, was es soll soweit - aber ich wollte mir noch eine 2.5G-LAN-Karte da reinpacken, und stelle fest, dass das System bereits jetzt (1 Gbps) beim Kopieren im Netzwerk [langsamer Gegenpart] ~90MB/s auf die HDDs schafft und die CPU-Auslastung bei ~70-80% ist.

... geht meine Befürchtung recht, dass ich mir für 2.5Gbit eine zu schwachbrüstige CPU ausgesucht habe und was Dickeres bräuchte? Oder kann es an was simplem Anderem liegen?

Edit: Ups, die 2.5G-Karte steckt schon drin, habe aber noch keinen 2.5G-Switch hier. Keine Ahnung, ob die Karte soviel Last erzeugt? Würde sich das zwichen 1Gbs und 2.5Gbps noch ändern?
 
Zuletzt bearbeitet:
Mit nur zwei HDDs wird eine 2,5G NIC auch nichts verbessern. Beim Schreiben auf die HDDs im Raid1 hast du ja nur die Bandbreite einer HDD, und auch wenn die im Datenblatt sequentiell deutlich über 1G angeben wirst du das im realen Leben mit HDD nie erreichen.
 
Danke - ich habe da auch eine SSD drin, mit der ich den maximalen (Netzwerk-)Durchsatz einfach testen könnte, mir ging es eher um die Frage, ob die CPU schon mit der Netzwerklast von LAN und RAID ausgelastet ist und das dann überhaupt nicht schaffen würde?
Habe keine praktische Erfahrung mit der CPU-Last von RAID und LAN, hatte aber gehofft, dass der J5040 das leicht packt?
 
Zusatz: Ok, Über die 2.5G-Karte, aber 1G-Switch von SSD auf SSD kopiert - ~90% CPU-Last auf dem J5040.
Liegt das an der Realtek 2.5G-Karte, und/oder ist der J5040 dafür zu grottig? Kann ich unter Windows etwas "falsch eingestellt" haben?
Eine reale Hoffnung, dass der J5040 auf diese Weise mit entsprechendem Switch mit 2.5Gbps umgehen könnte, sehe ich nicht...?
 
Du könntest alternativ die Daten auf die SSD schieben lassen und später automatisiert auf den RAID1.

Lesend wirst du aber weiterhin von den HDDs limitiert. Der Software-RAID tut sein Übriges dazu. Nicht umsonst gibt es RAID-Controller.
 
Wie gesagt, das Limit des RAIDs ist mir bewusst - es ist ja auch "nur" auf HDDs und nicht auf SSD - meine Frage ist aber die enorme (meine Wahrnehmung) CPU-Last, die nur durch das LAN auch schon bei SSD->LAN->SSD anliegt..?
 
Mhhh, also die Onboard Realdreck Karte ist ziemlicher Mist, die lagert alles auf die CPU aus wie du schon bemerkt hast. Was ist denn die 2.5Gb Karte, Intel i225/226 oder auch eine Realdreck? Wie ist die angeschlossen, USB oder PCIE?
 
Ich verstehe nicht was bei dir soviel Leistung zieht, ich hatte lange ein Selbstbau Windows 7 NAS mit den uralten Celeron J3150 am laufen und da hat sich die CPU mit 1GBit und effektive 110MB/s praktisch nicht gerührt und eine CPU Auslastung vonmehr als 30% wäre mir garantiert aufgefallen.
Allerdings hatte ich auch kein Software Raid (das sollte eigentlich verboten werden).
 
Mhhh, also die Onboard Realdreck Karte ist ziemlicher Mist, die lagert alles auf die CPU aus wie du schon bemerkt hast. Was ist denn die 2.5Gb Karte, Intel i225/226 oder auch eine Realdreck? Wie ist die angeschlossen, USB oder PCIE?
Ja, Realtek auf PCIe. Dass das nicht "High End" ist, war mir schon bewusst - aber auf einem alten Athlon irgendwas hatte ich mit 1Gbps auch nie 100% Last, und das ist schon >10 Jahre her :) Und ja, das war auch Realtek.
Beitrag automatisch zusammengeführt:

Ich verstehe nicht was bei dir soviel Leistung zieht, ich hatte lange ein Selbstbau Windows 7 NAS mit den uralten Celeron J3150 am laufen und da hat sich die CPU mit 1GBit und effektive 110MB/s praktisch nicht gerührt und eine CPU Auslastung vonmehr als 30% wäre mir garantiert aufgefallen.
Allerdings hatte ich auch kein Software Raid (das sollte eigentlich verboten werden).
Wie gesagt, mir ist die Effektivität des RAIDs bewusst, ich erwarte aber auch nicht die 250MB/s von der Festplatte. Wobei ich mein Mini-NAS auf Win-Basis schon >20 Jahre mache, und das RAID1 mich bei keinem System ewig viel CPU-Last gekostet hat. Die CPU-Last über LAN (selbst ohne RAID-Nutzung) ist mir aber... "unerwartet" hoch. Ich werde nochmal testen, wie die mit dem eingebauten 1Gbps-NIC ist, aber mit der 2.5G-Realtek-Karte schaut das irgendwie SEHR unrosig aus.
 
Zuletzt bearbeitet:
Für meine beiden Realteks (1Gbps und 2.5Gbps) sind die aktuellen Treiber drauf.

Gerade noch einmal getestet - mit dem on-board 1Gbps komme ich beim Kopieren SSD->LAN->SSD auf den J505 auch auf 100% CPU-Load. Ohne LAN-Aktivität liegt das unter 10%. Hat jemand eine Ahnung, was falsch eingestellt sein könnte/woran es noch liegen könnte?
 
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh