[Kaufberatung] Sparsamer (File-)Server

Die günstigen haben nur ein Problem, sie sind mechanisch so instabil, dass die mech. Belastung der Platten (durch Vibration und ggf. Resonanz)ansteigt und das wiederum lässt die Haltbarkeit sinken.

Selbiges kann man wohl auch beim Norco erwarten, was nicht sonderlich stabil gebaut zu sein scheint.

Das X8SIL-F unterstütz sicherlich auch mehr. 4x 8GB Module sind durchaus machbar bei nonreg.
(nur wurde und wird das nicht mehr nachgetestet, genauso wie auch 4x 16GB oder gar 32GB @reg gehen werden)

Und natürlich bewegen wir uns hier im Home-Server bereich. Dein Mainboard stellt die entry-Server-class dar und das sind unter anderem auch home-Server. Ein Home-Server definiert sich nicht dadurch, dass er aus Consumerkomponenten besteht.

Nicht mehr Home-Server kann man wohl den S2011 oder auch G34 ansehen. (obwohl man sich sowas auch gerne mal hinstellt)
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn er jetzt schon bei einem Mainboard hervorhebt, dass es doch 8xSATA Anschlüsse hat, dann gehört es halt irgendwo mit dazu, dass man darauf hinweist, dass diese nicht alle zusammen mit der maximalen Bandbreite an die CPU angebunden sind. Das war schon vor 15 Jahren so und ist selbst auf den aktuell neuesten Dual Sockel 2001 Systemen heute noch so. Das die Onboard-Anschlüsse immer durch einen Flaschenhals an die CPU angebunden ist und man mit extra Steckkarten deutlich weiter kommt wird sich wohl auch in Zukunft nicht ändern, erst wenn wirklich alles in der CPU integriert ist...
Da gebe ich dir absolut recht. Wer ein größeres RAID mit den OnBoard Steckplätzen baut dem muss/sollte bewusst sein, das dies nie zu einer sehr guten Performance führen wird.
Wobei da auch die Frage ist ob man das immer braucht ?
Ich wollte gute Performance, aber keine spitzen Performance, und brauche auch weit mehr als 8 SATA Anschlüsse. Daher habe ich mir einen guten SoftwareRAIDController eingebaut. Performancetest siehe RAID6 Festplatten Benchmark - Netzwerk - XBMCNerds und das reicht mir vollkommen aus. Manchen mag auch die Performance der OnBoard Möglichkeiten ausreichen, andere brauchen über 1 GB und greifen zu HardwareRAIDControllern. Das muss letzte Endes jeder selbst entscheiden. Aber darauf aufmerksam machen sollte man auf jeden Fall da hast du recht.

Das ein RAID kein BACKUP ersetzt MUSS jedem der ein RAID verwendet absolut klar sein. Ich habe RAID6 am laufen und es können somit jederzeit 2 Festplatten ausfallen ohne Datenverlust. Dennoch sichere ich die wirklich wichtigen Daten noch einmal extern auf eine HDD.

Habe auch selbst recht günstige 4in3 und 3in2 Module für die Festplatten verbaut. Cooler Master Stacker 4in3 Modul und Lian Li EX-23NB. Bin mit beiden Modellen sehr zufrieden und sie funktionieren wunderbar ohne Probleme. Musste bei dem Lian Li nur den Lüfter über einen Widerstand etwas drosseln.
 
Zuletzt bearbeitet:
Wenn ich das hier lese stellt es mir die Haare auf.... ein Raid ist nicht nur für die Performance da und ein Raid mit den Onboardcontrollern oder ein SoftwareRaid ist eigentlich totaler Mist und würde ich nie betreiben, ausser ich hab keine wichtigen Daten auf den HDDs.
Geht dein Board drauf, was ja schonmal vorkommt, kannste dir dein Raid sonst wo hinschmieren. Raid 0 mit Onboard lass ich mir noch eingehen, aber ohne richtigen Controller niemals ein 5/6 oder 1 0....ne. Bastelt mal schön weiter.
 
ohne das sich alle paar Monate eine der günstigeren Desktop-HDDs verabschiedet. Die ausgewählte Seagate 7200.14 zählt leider auch zu dieser Kategorie.
Ich frage mich langsam, ob die Qualität der Festplatten in den letzten 4 Jahren so sehr abgenommen hat. Ich habe hier eine Samsung HD753LJ von 2008 mit 12860 Betriebsstunden und 2500 Einschaltvorgängen. Laufen tut sie immer noch ohne Probleme. Warum sollte das bei einer Seagate ST3000DM001 anders sein?

keibertz schrieb:
Da gebe ich dir absolut recht. Wer ein größeres RAID mit den OnBoard Steckplätzen baut dem muss/sollte bewusst sein, das dies nie zu einer sehr guten Performance führen wird.
Bei den günstigen Boards sind 6 Sata-Ports direkt vom Chipsatz. Soll das heißen, die Intel Sata-Schnittstelle ist nicht für parallele Verwendung geeignet? Bei den Boards mit 8 Sata sind 2 durch einen zusätzlichen Controller herausgeführt. Der Controller ist bei dem Asrock und Gigabyte Board mit PCIe 2.0 1x angebunden. Damit erreicht man theoretisch 500MByte/s Datenrate. Das sollte für zwei Festplatten ja reichen?

Wenn ich ein Raid aufbauen sollte, dann habe ich es mit mdadm als Software-Raid unter Linux vor. Wenn ich dann ein Gigabit-Netzwerk auslasten kann reicht mir das eigentlich. Schneller kann ich die Daten sowieso nicht auf den Server bringen.
 
Zuletzt bearbeitet:
@andi Der TE hat ja noch kein Board gekauft :)
Die Zeiten von fehlerhaften Onboard Chipsätzen welche die Daten der HDDs vernichten sind hoffentlich zur Zeit wieder überstanden. Kommt ja alle paar Jahre wieder einmal vor ;)
Desweiteren will der TE ja auch nicht die fragwürdigen Hostraid Treiber für ein Windows Software Raid verwenden sondern auf Linux mit LVM aufsetzen. Da spielt der SATA-Chip keine große Rolle. Ggf. gibt es nur Probleme mit den extra Ports welche nicht vom Intel Chipsatz abgedeckt werden.
Aber ein einfacher SAS-HBA ohne Raid und Cache gibt es ja neu auch oft für 120+ Euro für acht HDDs.

Lassen wir dem TE erst einmal Zeit sich über die Möglichkeiten selbst zu informieren. Supermicro.com ist unter anderem eine gute Anlaufstelle ;)
Ansonsten gibt es hier im Forum auch schon einige Threads aus denen ein etwas größerer Fileserver wurde als zuerst geplant.

@ SplasHX11
Nicht korrigierbare Lesefehler pro gelesenem Bit, max 1 pro 10^14
Annualized Failure Rate (AFR) <1 %
Betrieb in Stunden 2.400
Zur Frage wegen der Anbindung der SATA-Ports, guck dir einfach an wie viele PCIe Lanes die entsprechende i3 CPU integriert hat und wie viel für den Chipsatz (sofern nicht über diesen DMI-Port angebunden) übrig bleiben.

Habe es erst bei einem Supermicro Dual Sockel 2001 Mainboard gemacht. Dort ist laut Diagramm über die zweite CPU am DMI ein zusätzlicher PCIe 2.0 x4 angebunden. Bei der ersten CPU hängt daran (über den DMI) der Onboard Chipsatz C206. An diesem wiederum 2xGbit Lan und 8xSAS 2.0 mit je 6Gbit/sec. Wenn allen Schnittstellen des Chipsatz nicht recht viel mehr als ein x4 PCIe 2.0 von der Bandbreite her gesehen zur Verfügung steht, dann braucht man sich über mangelnde Performance später nicht wundern.
Die Übertragunsrate bei PCIe ist übrigens Brutto und wird in der Praxis leider nur zu < 80% ausgenutzt. Bei einigen den meisten Controllern oft nur 40-60% max.
 
Zuletzt bearbeitet:
Die 2400 Stunden sind ja nicht die maximalen Betriebsstunden, sonder die Laufzeit in einem Jahr bei der die Ausfallwahrscheinlichkeit unter einem Prozent bleibt. Und die nichtkorrigierbaren Lesefehlerrate halte ich nicht für so sehr schlimm. Wenn dann eine Datei defekt sein sollte, ist es in meinem Fall auch nicht weiter schlimm. Funktioniert denn ein Raid5-Rebuild mit defekten Sektoren/nicht lesbaren Bits auf den verbliebenen Festplatten, wenn eine ausgefallen ist (Linux, mdadm)? Mir ist klar, dass dann einige Daten nicht mehr fehlerfrei wiederhergestellt werden können, aber funktioniert ein Rebuild mit den verbliebenen lesbaren Bereichen?
 
Bei einem RAID5 ist ja gerade das Gute, dass alle Daten redundant gehalten werden. Sprich solange der Bereich nur auf einer Festplatte nicht lesbar ist macht das überhaupt nichts. Erst wenn er auf beiden abgelegten Festplatten nicht mehr lesbar ist kommt es zu Problemen.
Erklärung RAID siehe RAID
 
Ich meine ja folgenden Fall: Angenommen ich habe ein Raid5 aus drei Platten. Eine davon fällt komplett aus. Auf mindestens einer der anderen verbleibenden Festplatten tritt so ein/mehrere nicht korrigierbarer Lesefehler auf. Was passiert dann? Kann ich die Daten trotzdem noch retten/ein Rebuild durchführen nur eben mit einigen defekten Dateien?
 
Prinzipiell kann man nicht mehr lesbare Sektoren bei einem Raid5 rebuild ignorieren, dafür musst du dich aber etwas in lvm/mdadm einlesen. Am besten bevor der Ernstfall einmal eintretten sollte. Und nein, die max. Betriebsstunden sind diese 2400h/Jahr! Das eine HDD früher ausfällt dazu zählen andere Faktoren wie Zugriffsmuster/Last mehr als das bloße drehen der Magnetscheiben. Der Motor hat in der Regel keine Probleme 24/7 durch zu laufen :) für die Lager ist es sogar eher besser, außer da wurde auch deutlich gespart...
 
Ich meine ja folgenden Fall: Angenommen ich habe ein Raid5 aus drei Platten. Eine davon fällt komplett aus. Auf mindestens einer der anderen verbleibenden Festplatten tritt so ein/mehrere nicht korrigierbarer Lesefehler auf. Was passiert dann? Kann ich die Daten trotzdem noch retten/ein Rebuild durchführen nur eben mit einigen defekten Dateien?
Ah ok dann habe ich dich falsch verstanden. Ich glaube das ist dann so ein typischer Fall von pech gehabt. Kommt aber bestimmt auch etwas auf den RAIDController an wie er damit genau umgeht bzw in wie weit er das Rebuild dennoch beenden kann. Aber da bin ich mir nicht sicher.
Umgehen kannst du das glaube ich nur mit einem RAID6 bei dem du dann die Daten auf 3 Festplatten liegen hast und dir somit 2 Festplatten jederzeit ausfallen können.
 
Günstiger sind nur LTO5 Tapes mit < 3 Cent/GB, hast halt nicht den schnellen wahlfreien Zugriff, aber dafür 160MB/sec konstant und nicht auf < 120-80MB/sec abfallend zum Ende der Kapazität wie bei HDDs üblich.
 
Ich habe mir nun das ASRock H77 Pro4-M mit einem Pentium G860 und 8GB Ram gekauft. Dazu eine 250GB 2,5" HDD für das OS und eine 3TB Seagate für Datenspeicher. Installiert habe ich Ubuntu Server 12.04.

Jetzt bin ich dabei verschiedene Dinge zu testen, wie u.a auch Truecrypt. Ohne Truecrypt kann ich über Samba das Gigabit Lan zu 95-96% (ca 110MB/s) konstant auslasten. Mit Truecrypt sieht die Netzwerkauslastung jedoch so aus: Unbenannt-1.jpg

Damit komme ich auf eine Datenrate beim Schreiben auf den Server von ca 100MB/s mit zwei Dateien parrallel von unterschiedlichen Festplatten. Im Screenshot wurde zu beginn von nur einer Festplatte kopiert und dann die zweite hinzugenommen. Im Truecrypt Benchmark komme ich auf >250MB/s. Von der Leistung sollte der Rechner also locker reichen. Beim Kopieren sehe ich unter "top" auf dem Server auch keine auslastung, die 200% ergeben würde. Wie kommen die Einbrüche in der Geschwindigkeit zustande und wie kann ich das verhindern?
 
Zuletzt bearbeitet:
Das dürfte zum einen an den Clients und dem Protokoll SMB an sich liegen. Aber auch, dass der Benchmark wohl ohne HDD Zugriffe rein im Arbeitsspeicher statt findet?
 
Mit dem AES-Befehlssatz im i5 hätte ich ja nur eine geringere CPU-Belastung beim Verschlüsseln. Daran sollte es eigentlich nicht liegen.

Ich habe das ganze auch nochmal über FTP versucht. Da habe ich die gleichen Einbrüche in der Netzwerkauslastung. Aufgefallen ist mir aber noch, dass die Einbrüche nur beim Schreiben auftreten. Lesen klappt ohne Probleme. Ich habe auch nochmal getestet mit welcher Geschwindigkeit mit und ohne verschlüsselung von der Festplatte gelesen werden kann:

sudo hdparm -t /dev/sdb

/dev/sdb:
Timing buffered disk reads: 496 MB in 3.00 seconds = 165.10 MB/sec

sudo hdparm -t /dev/mapper/truecrypt1

/dev/mapper/truecrypt1:
Timing buffered disk reads: 370 MB in 3.01 seconds = 122.78 MB/sec

Es sieht doch so aus, als ob irgendein Prozess für kurze Zeit aufhört zu arbeiten, wodurch dann die Einbrüche in der Auslastung zustande kommen?
 
Nimm doch mal keine oder eine leichtere Verschlüsselung für Truecrypt, vielleicht liegt es ja nur an den 4kbyte Sektoren deiner HDD?
 
Ich habe nochmal rumprobiert und habe herausgefunden, dass das Dateisystem wohl einen Einfluss hat. Mit ext4 bekomme ich die genannten Einbrüche und mit xfs sehr konstante Auslastungen. Und das egal ob ich mit dm-crypt oder truecrypt verschlüssele. Jetzt bleibt nur noch die Frage: Bleibe ich bei xfs oder kann man ext4 noch optimieren? Wie sieht es mit der Fehlersicherheit bei xfs aus? Ich habe gelesen, dass es gerade bei Stromausfällen Probleme macht...
 
XFS hatte frühers vor etlichen Jahren dein beschriebenes Problem mit Datenverlusten beim Schreiben wenn keine USV-Anlage vor dem Netzteil war.
 
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