FreeBSD als Storage-Server (NFS + iSCSI)

thorwin

thorwin

Well-Known Member
N'Abend!

Ich spiele derzeit mit dem Gedanken, für ein neues Projekt 2 FreeBSD-Server als Storage-Server einzusetzen. Versorgt werden sollen Linux-KVM-Hypervisor, die den Storage für ihre VMs von dort beziehen (iSCSI für die "internen" Platten und NFS für Shared Storage).

Was genau an Hardware verbaut wird, steht noch nicht fest, aber im Prinzip wird es auf Server mit 24 Platten (voraussichtlich 2x 600GB SAS für's System plus 22x 2TB S-ATA für die Daten) hinauslaufen. Jetzt kommen die Fragen:

  • Wie sind eure Erfahrungen mit FreeBSD als iSCSI Target?
  • Kann ich die LUNs aus einem ZFS-Pool herausgeben oder ist es sinnvoller, einzelne Devices zu nehmen? Aus einem Pool wäre sehr charmant, weil ich damit einfach deutlich flexibler bin was die Aufteilung NFS <-> iSCSI angeht
  • Wie teile ich 22 Platten auf? 3x [5+2] + 1 HS? 2x [9+2]? 1x [19+2] + 1 HS? Gibt's da Erfahrungswerte? Der ZFS Best Practisec Guide bei solarisinternals sagt, man möge KOnfigurationen mit 40+ Platten ein einem RAIDset vermeiden, aber da komme ich eh nicht hin...
  • Vermutlich ist es extrem sinnvoll, in das Setup eine SSD als ZIL und Cache zu integrieren, richtig?

Die Fragen nach Sizeing, SSD etc. sind aber erstmal nachgelagert, derzeit geht es mir hauptsächlich darum, ob und wie ich iSCSI und NFS auf einer solchen Maschine sinnvoll und performant (Netzanbindung wird mit 2x 10GE als LACP-Channel erfolgen) herauskriege.

Wenn jemand einen Hardware-Tipp für eine solche Maschine hat, bin ich auch für alles offen, ich stehe derzeit noch sehr am Anfang meiner Überlegungen...
 
Dieses Gehäuse würde eine gute Grundlage liefern:
http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm
und dem Board "Supermicro X8DT3-F"

Du kannst alle 24 Plätze für Daten-Disks verwenden.
Betriebssystem kommt entweder auf ein kleines, internes SATA-Flash-Modul oder USB-Flash-Modul, oder auf 1-2 weitere 2,5 Zoll interne Platten. 2 Flash-Drives können je nach Zusammenstellung dann auch innen rein, anstatt wertvollen Wechselrahmen zu belegen. 2 Flashdrives als Mirror für ZIL und Cache. Evtl. könnte man sogar da auch noch das OS mit draufpacken in separate Partitionen.
Du brauchst keine 600 GB SAS Platten fürs Betriebssystem in einem Storage-Server.

Ich würde wohl die 24 Disks in 3 Sets zerlegen und je nach Sicherheitsbedürfnis dann als RaidZ1 oder RaidZ2 auslegen (ich würde wohl Raid Z2 bevorzugen/empfehlen). Hotspare würde ich ganz weglassen...lieber RaidZ2.
Das gibt dir dann 36 TB blank bei 2 TB Disks.
Wenn mehr Speed gefordert ist, könntest du alternativ auch 4 Sets a 6 Platten machen; bleiben dann nur 32 TB.

VIEL RAM...so 24 GB würde ich wohl nehmen.

Das ganze geht für ca. 12.000 - 15.000 Euro Netto pro Box.

Zu iSCSI kann ich leider nichts sagen. Auch wird die Synchronisation/Replikation der beiden Storage-Server eine interessante Aufgabe.

Alternativ könnstest du dich auch nach einer Nexenta-Storage-Appliance umschauen...die sollten auch einigermaßen günstig sein, kommen mit hübschem GUI und laufen auf OpenIndiana.
 
Zuletzt bearbeitet:
Jou, das klingt schon mal fein, vielen Dank. Ich hatte auch an RaidZ2 gedacht. OS auf interner 2.5" Disk und 2x PCI-SSD als ZIL/Cahce klingt auch passend. Jetzt brauch' ich nur noch Infos zu iSCSI :D
 
cd /usr/ports/net/istgt/ && make install clean
-> /usr/local/etc/istgt/istgt.conf erstellen / anpassen
-> /usr/local/etc/istgt/auth.conf erstellen / anpassen
/etc/rc.conf:
-> istgt_enable="YES"
danach /usr/local/etc/rc.d/istgt start
So im Prinzip grob sollte das gehen bärig

Gruß Bummibär
 
Hah! Super. :cool:

Das gepaart mit dem hier für die ZFS-Integration sieht genau nach dem aus, was ich gesucht habe. Jetzt muss nur noch mein Chef nicken :D
 
Die erwähnten ZFS-Tuning-Tricks in dem verlinkten Artikel von dir sind veraltet und nicht mehr nötig/evtl. sogar kontraproduktiv. Auch sonst hat der Artikel kaum Mehrwert zu dem was der Bär schon sagte.
 
Das bezieht sich auf die Einträge in /boot/loader.conf? Dann lasse ich die einfach weg, vfs.zfs.zil_disable schien mir (so aus dem Bauch raus) sowieso kontraproduktiv zu sein. Danke für die Info.

Was der Artikel für mich aber an Neuem hatte, ist die Info, wie ich eine iSCSI-LUN aus ZFS rauskriege. Da war mir tatsächlich nicht klar, dass es einfach über eine Quota geht und ohne Anlegen eines Device- bzw. Loopback Files.
 
Ja das ZIL zu deaktivieren ist ungefähr so sinnvoll, wie den Write-Cache eines RAID Controllers ohne BBU zu aktivieren.
 
Wenn es ein reiner Fileserver ist, würde ich an ZFS gar nichts tunen. Wenn die Kiste noch andere Dingen machen soll, kann es sinnvoll sein, den ARC auf ca. Zweidrittel des RAM zu begrenzen. Mehr Tuning ist aber erst dann notwenig, wenn es wirklich Probleme geben sollte. Und meist tut es das nicht...
 
Nein, keine anderen Dienste. Nur NFS und evtl. (das ist noch intern zu klären) iSCSI.

Ich werde die Kiste (so sie denn kommt) erstmal so simpel wie möglich halten, also keinerlei Tuning. Schließlich muss ich ja auch erst mal beweisen, dass das so tut wie ich es angeprießen habe... :p
 
thorwin schrieb:
Ich spiele derzeit mit dem Gedanken, für ein neues Projekt 2 FreeBSD-Server als Storage-Server einzusetzen. Versorgt werden sollen Linux-KVM-Hypervisor, die den Storage für ihre VMs von dort beziehen (iSCSI für die "internen" Platten und NFS für Shared Storage).
Zum Vergrößern anklicken....

Für mich klingt das nach viel random i/o. In dem Fall würde ich dir eine Mirror-Konfiguration statt RAIDZ ans Herz legen. Vielleicht sogar 3-way-Mirrors.

Wenn du soviel Platten drin hast, kannste das ja auch testen, in dem du 2 Pools anlegst - einen mit RAIDZ und einen anderen in einer Mirror-Konfiguration.

Rob
 
Aus Erfahrungen hier mit anderen Hypervisor- und Storage-Lösungen haben wir gelernt, dass da gar nicht sooo viel random-IO zusammenkommt. Aber du hast sicher recht, man kann/sollte mal einen Test mit Mirror vs. RaidZ laufen lassen in der Testphase. *Notizinsbuchkritzel*
 
Mit ner SSD als Cache und Logging dürfte das doch relativ relativiert werden, kann ich mir vorstellen..dennoch...Tests sind immer besser.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben