NAS und Energiesparen: System auf USB-Stick oder RAID?

buebo

Well-Known Member
Hallo,
nach gefühlten hundert Jahren ohne BSD ist es nun soweit. Ein FreeBSD Rechner soll im privaten Rahmen als NAS dienen.

Es geht darum Medieninhalte im Netz (zwischen drei und fünf Benutzern) per NFS und SMB zur Verfügung zu stellen. Davon abgesehen soll das System als Backup-Laufwerk dienen. Die Daten werden dabei auf einem RAIDZ liegen.

Beim letzen Mal, als ich sowas ähnliches zusammengebaut habe, war noch vinum aktuell, da hatte sich die Frage wo das System selbst liegen soll so gar nicht gestellt. Mittlerweile ist das Booten vom ZFS Raid ja relativ problemlos.

Ich frage mich an der Stelle allerdings ob es sich nicht im Hinblick auf den Stromverbrauch bezahlt macht, das komplette System auf einen USB-Stick zu legen, so dass die Platten runterfahren können, wenn gerade niemand auf die Inhalte zugreift.

Konkret stellt sich also die Frage: Lassen sich die Systemplatten automatisch runterfahren, wenn gerade nichts im System passiert? Da alles auf dem Raid-Verbund liegt, würde ich vermuten, dass für jeden Zugriff direkt alle Platten anspringen müssten.

Da sehe ich definitiv noch Sparmöglichkeiten :-)
 
Hello buebo,

bis vor kurzem hatte ich einen kleinen Homeserver, bestehend aus zwei Festplatten für die Daten und einem USB-Stick auf dem das System installiert war.
Der Hauptgrund das System auf dem USB-Stick zu spielen lag in meinem Fall jedoch in der Geräuschentwicklung der Festplatten.
Je nach verwendeter Festplatte liegt die Ersparnis beim Stromverbrauch bei ca. 2 bis 6 Watt pro Platte.
Wenn das System auf dem USB-Stick liegt, lassen sich die beiden Festplatten in den Spindown versetzten.
Hiebei kann z.B. das Tool sysutils/ataidle hilfreich sein. Alternativ kann man sich auch ein Script mit camcontrol basteln.
Aufpassen muss man nur bei den täglichen/wöchentlichen/monatlichen Cronjobs, welche die Festlatten aufwecken können.
Manche Festplatten vertragen das ständige Aufwecken nicht so gut.

Beste Grüße,
laenger
 
Hi,
pack das System mit allem drum und dran doch einfach auf eine 2.5" SATA III SSD. Geräusche gibt die keine von sich und der Stromverbrauch ist auch sehr gering. Bei Updates etc. ist das Ganze recht performant und zügig erledigt. Die Raid Platten kannst Du ja dann "parken" wenn Du die nicht brauchst. Das "Gefummel" mit USB hast Du dann auch nicht.

Beste Grüße
Bummibär
 
Ich geb da Bummibär recht. Nimm eine kleine SSD 32gb oder kleiner für dein Rootfs. Das mit USB Sticks ist Kindergarten. Gehen tut das alles z.B. FreeNAS macht das so, aber schön ist was anderes.
 
Also USB Sticks verrecken wie die Fliegen, wenn man sie als r/w Rootfs nutzt. Die meisten erzeugen binnen weniger Stunden genug I/O Errors um das System zum Stillstand zu bringen.
 
Also USB Sticks verrecken wie die Fliegen, wenn man sie als r/w Rootfs nutzt. Die meisten erzeugen binnen weniger Stunden genug I/O Errors um das System zum Stillstand zu bringen.

Ganz so schlimm ists jetzt auch nicht, aber wenn man überlegt, dass es für 25€ 16GB SSDs gibt, macht das sicherlich mehr Sinn als alles andere.
 
Hi Leute,
einen SATA-Port würde ich nur ungerne für das System opfern. Das Mainboard hat davon genau sechs, das Gehäuse sechs Platten-Slots. Vier davon sind schon durch Platten verlegt. die letzten zwei würde ich mir für eine eventuelle Erweiterung aufsparen.

IDE Ports sind keine vorhanden, die einzige Alternative wäre also USB. Spontan würde mir da noch ein CF oder SD Adapter einfallen. Damit hätte man ebenfalls ein bootbares Medium, mit vielleicht sogar längerer Haltbarkeit als das bei einem USB-Stick der Fall wäre.

Mal gucken mit was die entsprechenden Adapter noch zu Buche schlagen.
 
Die elegantere Lösung ist wie schon geschildert eine SSD Festplatte.
Es kommt immer darauf an, was man mit dem System machen will. Die Performance eines USB-Sticks ist wirklich nicht so berauschend.
Ports bauen kann da schon "etwas" länger dauern und wirkt sich nicht gerade positiv auf die Lebensdauer des Sticks aus...
Wenn es unbedingt ein USB-Stick sein muss, dann kann es sinnvoll sein bestimmte Verzeichnisse/Partitionen im Arbeitsspeicher einzuhängen.
Ich habe ganz gute Erfahrungen mit TMPFS gemacht.
Lesezugriffe vertragen Flashspeicher sehr gut, Schreibzugriffe verringern die Lebenserwartung hingegen deutlich.
Wenn nur Daten im Netzwerk zur Verfügung gestellt werden sollen, dann könnten FreeNAS oder NAS4Free Alternativen sein, da diese u.a. auch für Embedded-Systeme gedacht sind.
Ich muss aber gestehen, dass ich nicht wirklich Erfahrung mit diesen Systemen besitze.

Grüße,
laenger
 
Mein NAS mit FreeBSD 7.4 läuft seit einigen Jahren vom USB-Stick und betreibt fünf Platten im RAIDZ mit ZFS und ein DVD Laufwerk, weshalb ich auch nicht eine (damals auch noch unerschwingliche) SSD verbaut habe.
Damals hatte ich zunächst VINUM probiert.
Es war mir nicht gelungen, die Platten schlafen zu schicken, bzw, nach jedem Aufwachen war der Raid in der einen oder anderen Form nicht mehr konsistent.
Mit ZFS habe ich es deshalb gar nicht erst so probiert und lasse die Platten einfach durchlaufen.
Ich glaube, dass es Probleme macht, weil die Platten nicht spontan nach dem Aufwachen Daten liefern und es deutliche Exemplarstreuungen gibt. Früher hatten SCSI Platten ja eine extra Leitung zum Syncen, wenn sie in einem Verband eingesetzt werden sollten. So etwas muss sicher heute nicht mehr sein, aber ich glaube eben, dass es genau die Richtung ist, in der wir immer noch Probleme haben. Wenn eine Platte im Verband nicht zur passenden Zeit die gewünschten Daten liefern kann, gibt es halt einen Fehlern und so etwas ist bei einem Aufwachen von mehreren Platten einfach der NormalFall.

Den Stick habe ich kopiert, also einen zweiten Stick im PC liegen, den ich bei Bedarf einstecken und einfach davon booten kann.
Gelegentlich, wenn das System zur Wartung heruntergefahren wird, synchronisiere ich die Sticks und tausche sie gegeneinander, etwa alle 100 bis 150 Tage.

Alle Anwendungen wurden komplett mit pkg_upgrade installiert, es gibt da keinen Ports-Tree. Ich bin damit zwar ausreichend glücklich, weiß aber nicht, ob ich das wieder so machen würde. Letztlich hatte mich irgendein Wahnsinn befallen und ich wollte etwas zusätzlich installieren, was eine Menge Abhängigkeiten mit sich brachte und damit schließlich meinen Stick voll packte. Das machte einige Arbeit, meine Aktion wieder rückgängig zu machen, weil die mir bekannten Tools nun nicht griffen und pkg_upgrade keine downgrade, bzw pkg_delete Funktion kennt. Es sichert zwar, was war, aber es deinstalliert nicht.
Mit pkgng sollte das vielleicht kein Thema mehr sein, ich habe das bislang aber noch nicht benutzt.

Die Schreibzugriffe auf den Stick habe ich so gut es geht minimiert.
Ich nutze kein Journal.
Ich nutze keinen SWAP (wirklich, ich nutze gar keinen SWAP aber das ist nicht zu empfehlen, wie mir glaubhaft versichert wurde) und SWAP auf USB ist natürlich eh ein NOGO.
Ich lenke alle Syslogs über Links auf den Raid (anstatt die vielen configs anzupassen, einfach /var/log auf den Raid und zurück-gelinkt) und nicht auf den Stick, analog zu anderen Schreibvorgängen, die vorhersehbar sind, etwa Druckaufträge oder Zeitabfragen von ntpd oder was auch immer.
Im Grunde genommen boote ich nur von USB, nutze dann tmpfs und den Raid und schreibe hoffentlich gar nicht mehr auf den Stick.
So sollte eigentlich auch die Performance vollkommen unabhängig vom Stick sein, aber für mich unverständlich und vollkommen überraschend fand ich durch schlechte Werte bei einer hier im Forum damals durchgeführten Prüfung mit bonnie (benchmarks/bonnie) eine schlechte Lötstelle im Sockel des verwendeten USB-Adapters. Ich habe den Stick mit diesem Adapter ins Gehäuse gelegt, damit niemand ihn versehentlich abziehen kann. Im Grunde würde ich ihn lieber direkt an die Anschlussstelle auf dem Motherboard löten, aber damit ist ein Tausch des Sticks nicht mehr einfach und schnell.

Die Performance insgesamt ist nicht so berauschend bei mir, wenn ich das mit einem gewöhnlichen SW-Raid unter einem busybox/Linux vergleiche, das sogar von einer CF bootet und ausgiebig Gebrauch von sogenannten RAM-Disks macht. Dabei rede ich von einem Thecus, einem recht teuren fertig-Produkt, der ziemlich verschlossen ist und deshalb nicht wirklich für mich durchschaubar wird. Aber mit einem i386 (ich denke ATOM, will aber nun nicht nachsehen) und nur 512MB RAM leistet der im Grunde alles, was ich auch mit meinem FreeBSD NAS kann, außer einigen Dingen, die ich eben doch genau so einbauen konnte, wie ich das wollte.

ZFS braucht vergleichsweise viel PC-Power und RAM, aber beides ist ja heute billig und ich würde und werde wohl wieder einen eigenen NAS mit FreeBSD und ZFS bauen, wenn das nötig wird.
Allerdings würde ich wohl auch SSDs einplanen, alleine, weil ich darauf ZIL realisieren würde. Suche mal Beiträge hier dazu, das wird dann schnell offensichtlich, dass jeder das will und zwar am liebsten redundant. ZIL auf USB verbietet sich natürlich vollkommen von selbst. Hat man erst mal SSD drin, dann würde ich die natürlich auch für das System selbst nutzen. Die Vorteile gegenüber USB sind enorm, aber an grundlegenden Technologien, möglichst wenig auf eine System-Partition zu schreiben, würde ich dabei festhalten.

Ja, USB-Sticks sind gewissermaßen Kinderkram, das möchte ich unterschreiben.
Mit USB3 war ich bisher nicht konfrontiert und da könnte alles doch ein wenig anders aussehen, ich weiß das nicht. Alles, was ich sage, bezieht sich auf den alten USB-Stack in FreeBSD7.4 und maximal USB2 und da ist der noch recht schlecht, soweit ich das überhaupt erkennen kann (also von der Endanwender-Sicht). Ein Linux (egal ob mit busybox oder GNU) scheint da besser zu sein, aber neuere FreeBSDs wohl auch.
Aber sogar damit konnte sogar ich einen brauchbaren NAS für den Heimanwender aufbauen und über Jahre ohne einen einzigen Fehler betreiben und er läuft immer noch...
 
Da will ich ganz kurz einwerfen, dass FreeBSD 7 Meiner Meinung das denkbar schlechteste Release für Dateisystemzugriffe ist. Mit FreeBSD 6 wäre die Performance wahrscheinlich besser gewesen.
 
Okay, das liest sich alles etwas durchwachsen. :-)

Ich habe jetzt per ataidle den Platten mal relativ kurze Idle und Standby Zeiten vorgegeben (10 und 15 Minuten) und lasse die ganze Geschichte nun mal laufen.

Die Hoffnung ist, das ohne größere Systembewegungen (/var/log liegt auf mfs) die Platten auch so einschlafen. Sobald alles erstmal geladen ist, sollten eigentlich kaum noch Lesezugriffe laufen. Die entsprechenden Werte Smartwerte sehen jetzt so aus:

/dev/ada0
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 33

/dev/ada1
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 32

/dev/ada2
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 30

/dev/ada3
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 23

Mal schauen, wie das in 24 Stunden aussieht.
 
Der Start_Stop_Count ist nicht so interessant, da dieser nur durch "Strom an/Strom aus" geändert wird. Halte ein Auge auf Load_Cycle_Count.

Meine Laptopplatte:
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 801993

Und die ist keine zwei Jahre alt, ich habe dem allerdings auch erst Anfang des Jahres entgegengewirkt ;).
 
Okay, das liest sich alles etwas durchwachsen. :-)

/var/log liegt auf mfs

kannst du mir das kurz übersetzen? Was ist mfs?
(ich finde nur Beiträge zum ehemaligen Ministerium für Staatssicherheit, das kann ja nicht sein...)

Neulich hatte ein Teilnehmer hier darum gebeten, seinen Beitrag zu seinem Eigenbau eines Fileservers / NAS zu kommentieren. Du findest das hier:
http://www.freebsduser.eu/
Das ist nicht uninteressant.

Du schickst also mit ataidle die Platten schlafen, die einen ZFS RAIDZ bilden?
Hast du alle mit der gleichen Zeit versehen? oder ganz bewusst mal Unterschiede eingebaut? Ist ja schon interessant, was dann passiert, denn in der Praxis dürfte das irgendwann ja mal vorkommen.
Wie gesagt, mit VINUM hatte ich da viel probiert und mich anschließend für ZFS entschieden, aber auch die Lust verloren, alles ständig neu aufzusetzen und nochmal zu probieren. Meine Versuche gingen damals total in die Hose.
 
Zurück
Oben