Homeserver bauen: Fragen zur Konfiguration und Hardware

thorwin

thorwin

Well-Known Member
Moin,

hier steht der Aufbau eines Homeservers an, und ich hätte ein paar Fragen zur Konfiguration und der Hardware-Ausstattung. Der Server soll hier universell Dienste für mich und die Familie zur Verfügung stellen, unter anderem
  • Fileserver (NFS/CIFS)
  • Mailserver für private Domain
  • Webserver (owncloud, wiki, blog)
  • Media-Streaming

Bandbreite in Richtung Internet sollte kein Problem sein (VDSL50), eine feste IP hab ich auch.

Hardware-technisch wollte ich 3 Platten im RAID-Z1 verbauen und zusätzlich noch 2 kleine SSDs (ja 32GB) für ZIL und L2ARC. Erste Frage: Das System und Swap lieber in den RAID-Pool oder auf die SSDs? Reichen 2 GB (gespiegelt) für ZIL und2x16 für L2ARC? Oder lieber mehr Cache und das System auf die SATA-Platten? :confused:

Nächste Frage: Preistechnisch sehen derzeit AMD CPUs mit Sockel FM2 am interessantesten aus, allerdings bin ich bei CPUs, Boards und Sockeln nicht mehr wirklich up-to-date. Hat hier jemand eine preis- und leistungsmäßig passende Alternative? Brauche halt mindestens 6x SATA, ob 6 GB/s sein muss, weiss ich nicht genau, das kann eine SSD wohl nicht ausreizen, oder?

Ansonsten sollen 8 oder 16 GB RAM in die Kiste, je nachdem, was das Budget (~450 €) noch hergibt. Als System ist 9.2 (amd64) geplant, mit -RC3 zu starten sehe ich unkritisch.

Ich sag schon ma Danke für alle möglichen Tipps und wünsch euch ein schönes Wochenende :cool:
 
Zu den SSD: 2GB ZIL reichen für dich locker aus. Die benötigte Menge an Log-Speicher hängt hauptsächlich von der in den Pool fließenden Datenrate ab und die dürfte bei dir gering sein. Beim L2ARC ist ein beliebter Fehler zu viel abzulegen, denn der L2ARC verbraucht zur Verwaltung RAM. Mit 4 bis maximal 8 Gigabyte bist du gut dabei. Allerdings würde ich mir überlegen, ob 32GB SSD die richtige Wahl sind. Die meisten dieser als Cache-SSD verkauften Dinger sind zu langsam. Mich haben sowohl sie von Transcend als auch von Sandisk enttäuscht, beide bremsen den Pool aus. SLC SSD sind zwar optimal, aber auch wieder sehr teuer... Von daher wäre, wenn das Budget es hergibt, eine 128GB Desktop-SSD die bessere Wahl. Sie sind deutlich schneller als diese Cache-SSDs, den überflüssigen Speicher lässt man halt frei.

Zur CPU: Die AMD-Prozessoren sind okay, die integrierte GPU sollte(!) sich abschalten, wenn kein Monitor angeschlossen ist. Ob es klappt, ist eine Frage des BIOS. Leider ist FM2 eine Platform auf Abruf, spätestens im Winter kommt der inkompatible Nachfolger (*seufz*) FM2+ oder so. Wenn du es jetzt kaufst sollte dir also klar sein, dass du nicht aufrüsten können wirst. Die einzigen Alternativen sind im Moment entweder ein deutlich teureres Core i3 System zu bauen, oder aber auf Intels Silvermond zu warten. Wobei das natürlich Glücksspiel ist. Der Core i3 ist deutlich schneller und braucht weniger Saft, hat aber kein AES-NI. Das kommt vielleicht mit den Haswell Core i3, die Intel demnächst auch offiziell vorstellen wird.
 
Ah, okay, dann sehe ich mir das mit den SSDs nochmal genauer an. "Desktop SSD" meint sowas wie eine Samsung 840er oder so? Hab ich ja im Notebook 2 drin, die sind schon flott :eek: Mal rechnen... ;)

Ich hab im Netz irgendwo gelesen, die ZIL sollte man spiegeln, muss man das haben?

Core i3 muss ich mal sehen, Verschlüsselung wäre schon nice. Das FM2 "auf Abruf" ist, war mir nicht klar, ist natürlich blöd, aber preislich irgendwie trotzem sehr ansprechend. Werd ich nochmal drüber nachdenken, bei AM3+ leg ich halt ~50€ mehr auf den Tresen, evtl. wäre noch eine Sockel 1155-Kombi interessant (z.B. ASRock B75 Pro3-M mit Celeron G1610, aber auch da gibt's dann kein AES-NI)
 
Jepp. Samsung, Intel, Crucial... Und so weiter. Halt die, die man sich in den Desktop schraubt.

Also, früher war der Zpool im Eimer, wenn das Log-Device weg war. In allen aktuellen Versionen läuft der Pool auch ohne weiter, aber man verliert alle Daten, die nur in der ZIL und noch nicht im Pool selbst waren. Je nach Datendurchatz auf dem Pool können das zwischen Sekundenbruchteilen und einigen Minuten vor dem Crash sein. Ob man damit leben kann, muss jeder für sich selbst entscheiden.

FM2 ist auf Abruf. "Kaveri" - also der Nachfolger der aktuellen APUs - wird einen neuen Sockel haben. Entweder FM2+ oder FM3. Er hat ein anderes Pin-Layout, wird also wahrscheinlich nicht Rückkompatibel sein. AM3+ wird wohl auch auslaufen. Es sind bisher keine neuen CPUs angekündigt und in Anbetracht des Alters der Plattform werden da wohl auch keine mehr kommen.
 
Hallo,

weil wir gerade bei dem Thema sind. kann ich den ZIL erheblich größer gestalten um Schreibzugriffe abzupuffern oder gibt es da noch etwas zu beachten?

Gruß ré
 
ZIL ist kein Schreibcache. Der Cache als solches ist immer noch der RAM.

Grob läuft das folgendermaßen ab:

1. write request kommt an, mit Anforderung, diesen "sync" zu schreiben
2. Daten landen im RAM
3. Daten werden zusätzlich in das ZIL geschrieben
4. write request wird als abgeschlossen an die Anwendung gemeldet
5. Daten werden gemütlich aus dem RAM auf Platte geschrieben
6. nach erfolgreichem Schreiben auf Platte werden die Daten im ZIL wieder als unbenutzt markiert

Nur wenn 5. jetzt fehlschlägt, sind die Daten noch im ZIL und werden beim nächsten Mal aus dem ZIL auf Platte geschrieben. Im Normalfall werden die Daten aus dem ZIL nach dem Schreiben nie wieder rausgelesen. Deswegen bringt ein größeres ZIL auch nichts.

Edit: Bei writes, die nicht sync sind, wird das ZIL von vornherein gar nicht angefasst. Und ohne ZIL würde 3. und 6. wegfallen und 4. würde nach 5. kommen.
 
Zuletzt bearbeitet:
Habe mich jetzt für ein AM3+-System entschieden. Bzgl. der SSD habe ich eine meiner beiden Samsungs aus dem Laptop "umgewidmet" und die Windows-Installation auf SATA-Platte "verbannt". Alerdings stellt sich jetzt die nächste Frage:

Die SSD ist "dummerweise" :cool: 256 GB groß, wenn ich da jetzt 8 GB für Swap, 2 GB für ZIL und 4-8 GB für L2ARC abzweige, beibt ja noch eine ganze Menge Platz über. Was mache ich damit am sinnvollsten?
  • Das OS draufpacken? Damit habe ich einen wurdervollen SPOF, oder kann ich das auf die SATA-Platten spiegeln und ZFS bewegen, vorzugsweise von SSD zu lesen und nur, wenn die platzt die SATAs heranzuziehen?
  • Diverse, für das OS "unkritische" Verzeichnisse auslagern? Ich dachte z.B. an /{.var/}tmp und /usr/{obj,ports}
  • vergammeln lassen? :ugly: Wäre eigentlich schade drum...

Am liebsten würde ich das OS auf die SSD packen, wie geht ZFS denn mit unterschiedlich schnellen Platten im (mirrored) Pool um? :confused: Schreiben ist klar, da wird's dauern, aber beim Lesen wär's fein, wenn er (vorzugsweise) die schnellere Platte nehmen könnte.
 
Ungenutzer Platz würde ja nicht vergammeln. Du würdest halt extrem langlebige ZIL/L2ARC haben, da wear leveling ja viel mehr Platz hat zum Arbeiten und jeder Sektor so nur einen Bruchteil der Schreiblast einer üblich genutzten SSD abkriegt.
 
Hmm, da hatte ich gar nicht dran gedacht. Also einfach nicht partitionieren und die Disk "macht das dann schon"?
 
Genau. Die SSD nutzt jeden Sektor gleichmäßig.

Aber wegen SPOF: Wenn die Swap ohne Spiegel auf der SSD ist, die Swap genutzt werden sollte und die SSD absegelt, würde das System (bzw. die ausgelagerten Dienste) dann nicht auch crashen?
 
Also wie es im Detail funktioniert, weiß ich nicht. Ich denke mal nicht, dass der Controller irgendeine Idee von Partitionen hat. Er wird einfach sehen, welche Blöcke wie oft geschrieben wurden und welche ungenutzt sind und "das dann schon machen".
 
-Nuke- schrieb:
Aber wegen SPOF: Wenn die Swap ohne Spiegel auf der SSD ist, die Swap genutzt werden sollte und die SSD absegelt, würde das System (bzw. die ausgelagerten Dienste) dann nicht auch crashen?
Zum Vergrößern anklicken....

Ja, da denke ich noch drüber nach. Evtl kommt swap doch im den zpool mit rein (oder als gmirror auf die SATA Platten). Bei nächster Gelegenheit werd ich dann wohl noch ne zweite SSD nachrüsten.
 
TCM schrieb:
ZIL ist kein Schreibcache. Der Cache als solches ist immer noch der RAM.

Grob läuft das folgendermaßen ab:

1. write request kommt an, mit Anforderung, diesen "sync" zu schreiben
2. Daten landen im RAM
3. Daten werden zusätzlich in das ZIL geschrieben
4. write request wird als abgeschlossen an die Anwendung gemeldet
5. Daten werden gemütlich aus dem RAM auf Platte geschrieben
6. nach erfolgreichem Schreiben auf Platte werden die Daten im ZIL wieder als unbenutzt markiert

Nur wenn 5. jetzt fehlschlägt, sind die Daten noch im ZIL und werden beim nächsten Mal aus dem ZIL auf Platte geschrieben. Im Normalfall werden die Daten aus dem ZIL nach dem Schreiben nie wieder rausgelesen. Deswegen bringt ein größeres ZIL auch nichts.

Edit: Bei writes, die nicht sync sind, wird das ZIL von vornherein gar nicht angefasst. Und ohne ZIL würde 3. und 6. wegfallen und 4. würde nach 5. kommen.
Zum Vergrößern anklicken....
Nach deinem Szenario würde ZIL die Ausfallsicherheit erhöhen, nicht aber die performance. Nach allem was ich weiß, ist aber das Gegenteil der Fall.

Und es kommen ja auch nicht alle write-requests mit einem sync, oder?
 
h^2 schrieb:
Nach deinem Szenario würde ZIL die Ausfallsicherheit erhöhen, nicht aber die performance. Nach allem was ich weiß, ist aber das Gegenteil der Fall.
Zum Vergrößern anklicken....
Nein, wieso? Performance-Erhöhung ist doch perfekt mit dem Szenario erklärbar. Ohne ZIL muss die Anwendung warten, bis die Daten auf der Platte sind, mit ZIL muss sie nur darauf warten, dass die Daten im ZIL sind, was schneller geht als Platte.

Und es kommen ja auch nicht alle write-requests mit einem sync, oder?
Zum Vergrößern anklicken....

Nein, und wie gesagt ist das ZIL dann auch nicht beteiligt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben