[Sammelthread] ZFS Stammtisch

ZFS funktioniert vom Grundsatz mit Spindown. Das Wiederanlaufen sollte halt schnell genug passieren, damit der Pool nicht degraded weil ZFS Platte(n) als "nicht verfügbar" markiert.
Z.B. Nas4free (also FreeBSD) kann das out-of-the-Box mit Sata-HBAs+Platten, bei SAS-HBAs braucht man ein Script, da der SAS-Chip+Treiber das nicht selbst veranlasst (auch bei Sata-Platten nicht).
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Vielen Dank für die Erklärung. Jetzt macht das natürlich Sinn...

Jetzt weiß ich auf jeden Fall für die Zukunft Bescheid - für mein jetziges System bringt's mir leider nichts :(
 
So... nach Stunden testen habe ich es geschafft, das Napp-IT auf einem Proxmox-Host läuft ohne das man sich die GUI zerschießt.

1.jpg
2.png
3.jpg
4.png
4a.png
5.jpg

Wie man auf Bild 4 erkennt, werden in der Übersicht die ZFS Filesysteme nicht angezeigt... unter ZFS Filesysteme -> Rename / Destroy usw erscheinen sie jedoch.
Auch ein Erstellen ist möglich.

Ich teste noch weiter...
 
Zuletzt bearbeitet:
zu Bild 4
Napp-it geht davon aus, dass Datenpool und Systempool/rpool zwei pools sind und unterdrückt daher Dateisysteme auf rpool. Am Besten also einen eigenen Datenpool anlegen. Im Problemfall wird man froh sein System und Daten sauber zu trennen. Unter Solaris kommen die bootfähigen Systemsnaps/ BE hinzu. Daher wird da praktisch immer ein separater Datenpool benutzt.

- - - Updated - - -

Vielen Dank für die Erklärung. Jetzt macht das natürlich Sinn...

Jetzt weiß ich auf jeden Fall für die Zukunft Bescheid - für mein jetziges System bringt's mir leider nichts :(

Ich würde die Rekordsize von 128k auf 512k oder 1M erhöhen. Das verringert den Verschnitt zumindes bei neuen/ geänderten Daten.
 
Vielen Dank für die Erklärung. Jetzt macht das natürlich Sinn...

Jetzt weiß ich auf jeden Fall für die Zukunft Bescheid - für mein jetziges System bringt's mir leider nichts :(

Wenn du auf recordsize=1M änderst und du die daten neu schreibst könntest du es lösen. Du musst halt ausreichend Platz haben um die datasets nochmal auf den pool zu kopieren (send/recv). Danach einfach die alten datasets löschen.
 
@gea: Eine Frage oder ggf. Bitte. Würdest du deine All-In-One Lösung für napp-IT auch für Proxmox anbieten? Zum einen würdest du definitiv an Kunden gewinnen, auch wenn das nicht dein Hauptaugenmerk ist. ESXi ist nicht für alle die beste und optimale Lösung, besonders bei Denjenigen, die OpenSource mögen :)
 
Ich glaube, ihr unterschätzt etwas, welchen Aufwand das bedeuten würde. Außerdem: warum? Ich denke, proxmox hat eine GUI - wenn die nicht reicht, fragt den Entwickler...

Nappit komm von Solaris und dort gibt es ganz andere Schnittstellen für die Funktionen, die unter Nappit interessant sind, als in der Linux-Welt. Was ihr da als UI seht und wollt, sind Funktionen die unter Solaris einfach anders gelöst/abgebildet werden bzw. integriert sind, als bei Linux. Und diese - ich nenn es mal plump "Defizite" - kann ein UI/Webinterface nicht mal eben nebenbei ausbügeln.

Ihr müsst also eine Plattform-Entscheidung treffen und könnt nicht erwarten, dass eine simple (sorry gea) Weboberfläche im Vorbeigehen/Handumdrehen die fundamentalen Plattformunterschiede nivelliert.

Genausowenig käme ich auf die Idee, gea um die Umsetzung (Portierung) von Linux-Eigenheiten für die Solariswelt zu bitten.

Da wo es Gemeinsamkeiten gibt, funktioniert Nappit ja auch für Linux/ZOL. Wo's/was nicht geht, sind die Unterschiede zu groß.
 
Zuletzt bearbeitet:
Es ist so wie Besterino sagt.

Sun hatte mit Solaris vor 15-20 Jahren ein revolutionäres Betriebssystem mit heute noch wegweisenden Eigenschaften geschaffen und dabei ausschliesslich eigene Technologien genutzt. Herausgekommen sind Sachen wie SMF fürs Servicemanagement, ZFS als Datei und Raid-System mir Prüfsummen und CopyOnWrite, Dtrace für die Systemanalyse, RBAC/ rollenbasierte Sicherheitsstrukturen, NFS und SMB als in ZFS integrierte Kerneldienste, Comstar als Framework für Enterprise FC/iSCSI Blockstorage oder Crossbow für virtuelle Netzwerkdienste mit virtuellen Nics oder Switche und vlan-Support um nur einige zu nennen. Vieles wurde in BSD, OSX, Linux oder auch Windows übernommen ohne allerdings ein ähnlich rundes Endergebnis speziell bei Storage Appliances zu bieten.

Diese Dienste sind Bestandteil jedes noch so minimalen Solarissystems egal ob Oracle Solaris oder dem OpenSource Solaris Zweig um Illumos. Alles Sun/ Oracle/ Illumos, keine Frremdprodukte. Deher funktioniert napp-it ja auch relativ problemlos mit diversen Solarisdistributionen weitgehend gleich gut. Der Ansatz von napp-it ist es, das Setup sowie das Management für Normaladmins bedienbar zu machen. Sun/ Oracle haben ja nur Big-Enterprise/ Big Data/ Cloud Anwender mit professionellen Solaris Admins auf der Kommandozeile als Ziel-Kunde.

Die Linuxversion bietet daher nur die Funktionen die auf ZFS, Cron oder Perl basieren. Das ist überall identisch. Eine zu Solaris und Illumos vergleichbare Funktionalität wäre nur durch die Integration diverser Linuxprojekte erreichbar. Die Einfachheit wäre aber nicht zu erreichen, da Linux für jedes Problem viele Lösungen anbietet, die man entweder alle unterstützen muss oder eben massive Einschränkungen vornehmen muss, egal ob man Packetmanagement, Diensteverwaltung, Plattenidentifikation, Dateisysteme, Raidoptionen oder Services betrachtet. Das ist das Problem vieler Linux Appliances. Entweder alles ist abgeschottet und proprietär (z.B. Synology) oder recht umständlich/ nicht komplett wie Webadmin.

Eine im Funktionsumfang, der Einfachheit und der Unterstützung mehrerer Solarishdistributionen vergleichbare Linuxvariante für diverse Linuxe wird und kann es nicht geben.
 
Zuletzt bearbeitet:
Ich bin mal gespannt was Solaris 11.4 bringen wird, 2018. Ich hätte ja gerne eine ähnlich funktionsreiche Dockerumgebung wie SmartOS/Triton - da hat zB jeder Kontainer automatisch seine eigene IP, wenn ich mich recht ensinne.Solaris Zonen bringen es halt nicht direkt, wenn es das für Solaris nicht gibt, was man will.


Gibt es eigentlich Virtual Box für Solaris ? Finde immer nur Solaris in VB ( könnte aber ja schon die Antwort sein..), das bringt mir aber nun wirklich nichts..
 
Zuletzt bearbeitet:
Ich bin mal gespannt was Solaris 11.4 bringen wird, 2018. Ich hätte ja gerne eine ähnlich funktionsreiche Dockerumgebung wie SmartOS/Triton - da hat zB jeder Kontainer automatisch seine eigene IP, wenn ich mich recht ensinne.Solaris Zonen bringen es halt nicht direkt, wenn es das für Solaris nicht gibt, was man will.

Solaris hatte früher Linux/LX container als zones. Keine Ahnung ob die das wieder bringen. Aktuell ist das eine Entwicklung von SmartOS (Joyent/Samsung) mit Dockersupport. LX Zonen von Illumos sind auch in OmniOS, geplant in OpenIndiana. Docker Images soll man auch mit etwas Tricksen in OmniOS nutzen können.

LX Branded Zones
The Trouble with Tribbles...: Running LX zones with Tribblix
LX Branded Zones - SmartOS Documentation - SmartOS Wiki
Joyent | Docker and the Future of Containers in Production

Gibt es eigentlich Virtual Box für Solaris ? Finde immer nur Solaris in VB ( könnte aber ja schon die Antwort sein..), das bringt mir aber nun wirklich nichts..

Ja gibt es, für OmniOS sogar als Installer von zos (hier im Forum)
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions
 
Joah. Hab ich sogar mal testweise laufen gehabt *voll stolz sei* - war aber nicht ganz trivial und Virtualbox nur über die Konsole zu administrieren ist alles andere als ein Spaß.
 

Der sollte auch noch funktionieren, es wird halt noch die Version 5.0.32 (Stand Januar 2017) und nicht die aktuellste 5.1.28 (Stand September 2017) installiert. Eine Aktualisierung auf die letzte 5.0er-Version (5.0.40, Stand April 2017) sollte aber ziemlich einfach sein. Dazu einfach im von gea verlinkten Script (Zeilen 20 und 21) folgende Änderungen vornehmen:

$vboxver1="5.0.40";
$vboxver2="115130";

Mit dem 5.1er-Zweig habe ichs im Frühjahr auch schon mal probiert, aber hier hat Oracle ein paar neue Stolpersteine (Checksum's) eingebaut. Ich habs zwar mit etwas Fummelei hinbekommen, aber den Installer-Umbau noch nicht gemacht. Außerdem ist die Weboberfläche phpvirtualbox ebenfalls "nur" bis Version 5.0 gepflegt. Aber auch das konnte ich bereits mit etwas Fummelei lauffähig machen.

Gast-Systeme wie Windows 10 etwa laufen auch unter der 5.0.32er Version, es fehlen aber eben alle Neuerungen und Bugfixes aus 2017.
 
Ich fühle mich etwas falsch verstanden. Es war gemeint die ESXi-AllInOne Lösung (mit Solaris VM) als Proxmox-AllInOne Lösung (ebenfalls mit Solaris VM) zu portieren. Es war nicht gemeint, NappIT auf Linux zu packen.
 
Ich fühle mich etwas falsch verstanden. Es war gemeint die ESXi-AllInOne Lösung (mit Solaris VM) als Proxmox-AllInOne Lösung (ebenfalls mit Solaris VM) zu portieren. Es war nicht gemeint, NappIT auf Linux zu packen.

Das soll jetzt nicht negativ klingen, aber warum sollte man dann noch wirklich Solarish in ne VM packen? Proxmox kann selbst ZFS und das sogar als System-RAID1! "Nur" wegen Dtrace oder dem besseren SMB sehe ich da keinen ernsthaften Grund ...

Und nochmal: Das ist rein sachlich gemeint!
 
Ich habe die Möglichkeit meinen Storage über PCIe-Passthrough zur VM durchzureichen und mir diesen dort verwalten zu lassen, anders läuft es ja bei ESXi auch nicht. Als System-Raid nutze ich bereits ZFS ;)
Gegenfrage, wozu nutze ich denn NappIT? Ich kann unter Solaris ja alles per CLI verwalten, will ich aber nicht und genauso wenig will ich das unter Linux/FreeBSD.
Vielleicht habe ich auch einfach den Sinn nicht hinter NappIT verstanden aber für mich ist es eine Lösung wie FreeNAS, die mir einiges an Konfigurationsaufwand bzw. CLI-Fummelei abnimmt. Proxmox alleine hat nicht viele Storage-Optionen, angefangen vom alerting und fehlender Disk-Encryption.
 
Zuletzt bearbeitet:
OpenZFS ist nahezu identisch unter BSD, Illumos, OSX und Linux da alle auf der letzten freien OpenSolaris Entwicklung bzw dem Illumos Fork aufbauen. Neue Erweiterungen auf einer dieser Plattformen findet man meist schnell auf den anderen.

Aber so wie irgendein Linux + ext4/btrfs oder auch ZFS eine auch nur annähernd gleiche Usability hat wie z.B. Synology/OMV sowenig gilt das für FreeNAS/Nas4Free unter BSD wie für napp-it/ NexentaStor unter Solaris/Illumos. Bis ein Admin/ User auch nur annähernd die Möglichkeiten eines OS auschöpfen oder dies adäquat administrieren kann ist unter der Kommandozeile schon sehr viel Know How/ Erfahrung nötig. Eine Appliance Software mit ihrem ready to use Ansatz ist da schon was anderes.

Napp-it unterscheidet sich sich da von den anderen Appliance Packeten in Wesentlichen dadurch dass es nicht eine spezielle OS Distribution nutzt sondern die Freiheit läßt, eine auszusuchen und separat upzudaten.

Eine napp-it VM mir Solaris/OmniOS/OI unter Proxmox mit pass-through sollte eigentlich problemlos installierbar sein. Die entscheidende Frage ist wie gut Solarish unter Proxmox läuft und wie gut z.B. die vnics sind. Eine vorkonfigurierte VM wie unter ESXi macht es zwar etwas einfacher aber ein Setup + Installation von napp-it per Online Installer ist auch recht trivial.
 
Wollte schon sagen, die Installation von Solaris/Nappit ist total simpel - wenn denn das Drumherum vernünftig läuft. Einzige Herausforderung sind also Einstellungen bzw. Unterstützung in Proxmox für einen solaris-Gast und Treiber in Solaris für etwaige virtuelle Devices. Was eine erste Google-Suche so ergibt, scheint Solaris als Proxmox-Gast nicht ganz so easy-peasy zu gehen, wie im ESXi.

Etwaige fehlende Unterstützung von Solaris-Gästen in Proxmox wird aber auch gea nicht kompensieren können.
 
Zuletzt bearbeitet:
Ich bin ja mal wieder so begeistert von Solaris: leichter eine boot/root-disk tauschen geht ja echt nicht!

Man braucht nichtmal die ganze Anleitung, sogar mit SATA-Disks total simpel:

1. Im laufenden system rausfinden, welche die aktuelle rpool-disk ist: zpool status rpool
Bei mir war c2t1d0 die alte, c2t0d0 die neue Disk. Dann herunterfahren.
2. freie Disk in freien SATA-Anschluss stöpseln und normal booten.
3. zpool attach rpool c2t1d0 c2t0d0
warten bis Resilver durch ist (prüfen zpool status rpool)
4. zpool detach rpool c2t1d0, Herunterfahren.
(4a. auf Wunsch, wenn die neue Disk größer ist ggf. noch: zpool set autoexpand=on rpool (hab ich aber nicht))
5. Alte Disk rausnehmen, neue Disk am physischen Platz der alten anstöpseln.
6. Bootet automatisch von neuer Disk

Vorteil dieser Vorgehensweise: bootet dann neu ohne Rumkonfigurieren im BIOS, rumfummeln mit grub oder dem boot-environment. Hab echt selten so entspannt das OS umgezogen.
 
Ja, Solaris hat echt ein paar nette Features.Ich finde ja auch das Updaten genial gelöst.
Nachdem du ein Update gemacht hast, wird nicht dein bestehendes System aktualisiert, sondern es wird ein neues Bootenvironment erstellt, was nach dem Neustart gebootet wird.Sollte etwas nicht wie gewohnt funktionieren wechselst du einfach zum alten "stable" zurück.
 
Zuletzt bearbeitet:
Ich hab mal wieder ein selbstverschuldetes Problem, sprich Backup der nappit-Einstellungen weg, und zwar will nach einem sauberen ESXi-Update mit Maintenance-Mode samt anschließendem Reboot meine nappit-Appliance nicht mehr starten. Mehr als "WARNING: init(1M) core dumped on signal 10: restarting automatically" zeigt die VM nicht mehr an.
Ich hab den Controller samt Platten jetzt kurzerhand in eine neu ausgerollte napp-it-022-ova durchgereicht und notdürftig alle Einstellungen aus dem Gedächtnis wieder eingetragen, soweit so gut. Jetzt würde ich gerne die unwillige Appliance irgendwo einhängen und herausfinden, was deren Problem ist. Welche Möglichkeiten habe ich dafür?
 
Hab mal eine Performance-Frage: Ich hab einen RaidZ-Pool aus 4TB WDReds. Das ist nun nicht wirklich flott als VM-Storage. Also dachte ich, ich pack' einen SLOG-Mirror aus 2x120GB Samsung 863 SSDs dazu, um Writes zu beschleunigen.

Also flugs die 2 SSD rein und "sudo zpool add -f Poolname log mirror SSD1 SSD2"... und der Unterschied laut CrystalDiskMark ist quasi gleich Null... hab ich was falsch gemacht?

Vorher (kein SLOG):
CDM_noSLOG.jpg

Nachher (mit SLOG):
CDM_SLOG.jpg

Pool sah so aus:
Code:
~$ zpool status ZFSdata
  pool: POOLNAME
 state: ONLINE
  scan: scrub repaired 0 in 3h23m with 0 errors on Mon Oct  2 02:53:41 2017

config:

        NAME                       STATE     READ WRITE CKSUM
        POOLNAME                    ONLINE       0     0     0
          raidz1-0                 ONLINE       0     0     0
            c0t50014EE20B72CFC6d0  ONLINE       0     0     0
            c0t50014EE2B61DDCFBd0  ONLINE       0     0     0
            c0t50014EE2B61C329Dd0  ONLINE       0     0     0
            c0t50014EE2B61CFBD4d0  ONLINE       0     0     0
        logs
          mirror-1                 ONLINE       0     0     0
            c0t5002538C401C767Cd0  ONLINE       0     0     0
            c0t5002538C401C767Dd0  ONLINE       0     0     0


Ich hätte zumindest eine etwas größere Differenz bei den Writes erwartet? (Getestet über Win10 Client auf Server über 10Gbit-Netz)
 
Zuletzt bearbeitet:
@Besterino

Überprüf doch mal mit

Code:
zfs get all ZFSdata | more
Welchen Wert logbias hat.

Wenn logbias=latency steht, sollte dein ZIL genutzt werden.

Man möge mich korrigieren, wenn ich da gerade etwas verwechsle.


Ich habe mich gerade nochmal weng in Slog und ZIL einglesen, allerdings ist die Verwirrung nun komplett.
Irgendwie wird das gerne mal als das Gleiche dargstellt und dann mal wieder nicht - aber ohne beides sinnig zu erklären.



Mein Fazit.

ZIL = "Bereich für das Journal" aka ist was wirklich geschrieben oder nicht.(Sollte bei NFS Freigaben wohl genutzt werden, da bei NFS das eigentlich automatisch genutzt wird, nur halt auf dem gleichen Pool, wenn keine SSD da)
SLOG = Schreibcache aka Schreibbefehle werden gesammelt und ZFS schreibt diese dann für sich in sinnvolle Gruppen auf den eigentlichen Pool.
L2ARC = Lesecache, wobei lieber mehr RAM als eine SSD, wenn möglich.


Ist das so richtig ?
 
Zuletzt bearbeitet:
Einen grundsätzlichen Schreibcache für alles gibt es, ausser dem Ram, nicht. Das SLOG-Device ist nur nützlich für Writes, die als synchron angefordert sind. Also von NFS z.B.
Ansonsten werden im Ram die Schreibvorgänge gebündelt/serialisiert.

=>D.h., für eine typische Umgebung z.B. mit Windows-Clients via SMB bringt ein SLOG-Device rein gar nichts. Wenn die Applikation asynchrone Schreibvorgänge absetzt, auch nicht.
=>Auch hunderte von Gbyte bringt rein gar nichts dafür. Für ein SLOG wird nur (ich glaub 2*) der Platz benötigt, der maximal bis zum nächsten Checkpoint anfällt (früher 5 sek bzw. das, was man eingestellt hatte; nun ist das adaptiv wenn ich das von Gea richtig verstanden hab).

Da Latenzen für SLOG kritisch sind, ist da selbst eine typische SSD der Klasse 850pro/SM863/PM863 schnell ein Bremser. Die Optane P4800X schaut mir da gut geeignet aus (ist aber sauteuer).
 
Zuletzt bearbeitet:
ZIL = "Bereich für das Journal" aka ist was wirklich geschrieben oder nicht.(Sollte bei NFS Freigaben wohl genutzt werden, da bei NFS das eigentlich automatisch genutzt wird, nur halt auf dem gleichen Pool, wenn keine SSD da)
SLOG = Schreibcache aka Schreibbefehle werden gesammelt und ZFS schreibt diese dann für sich in sinnvolle Gruppen auf den eigentlichen Pool.
L2ARC = Lesecache, wobei lieber mehr RAM als eine SSD, wenn möglich.

ZIL = das was Gesamelt wird und dann als seq. Write weggeschrieben wird
SLOG = Schreibcache für Sync-Writes

Asymmetrische Schreibvorgänge gehen nie über das SLOG Device. Ich bin mir jetzt nicht sicher was passiert wenn man die Eigenschaft "sync" auf "always" setzt. Dann müsste meiner Meinung alles über das SLOG Device.
 

Anhänge

  • async-zil.png
    async-zil.png
    6 KB · Aufrufe: 106
  • platter-sync-zil.png
    platter-sync-zil.png
    5,6 KB · Aufrufe: 103
  • slog-sync-zil.png
    slog-sync-zil.png
    6,6 KB · Aufrufe: 110
Mein Fazit.

ZIL = "Bereich für das Journal" aka ist was wirklich geschrieben oder nicht.(Sollte bei NFS Freigaben wohl genutzt werden, da bei NFS das eigentlich automatisch genutzt wird, nur halt auf dem gleichen Pool, wenn keine SSD da)
SLOG = Schreibcache aka Schreibbefehle werden gesammelt und ZFS schreibt diese dann für sich in sinnvolle Gruppen auf den eigentlichen Pool.
L2ARC = Lesecache, wobei lieber mehr RAM als eine SSD, wenn möglich.


Ist das so richtig ?

nicht ganz

- Zil = sofern sicheres sync write aktiviert, wird der Inhalt des Schreibcaches auf dem Pool protokolliert
und bei einem Crash beim nächsten Reboot auf dem Pool gespeichert (ähnlich Cache+BBU bei Hardwareraid)

- Slog= wie Zil, es wird aber ein eigenes Device/ Disk benutzt, kann damit bei einem guten Slog schneller sein als das Zil - ein Zil/Slog ist damit KEIN Schreibcache

Schreibvorgänge bei ZFS gehen grundsätzlich über den RAM-Schreibache. (default max 4GB). Zil/Slog dienen dazu, diesen Schreibcache (unabdingbar für schnelles sequentielles Schreiben) crashsicher zu machen.

L2Arc=Lesecache, erweitert den RAM-Lesecache, kann optional zusätzlich read-ahead
 
Zuletzt bearbeitet:
Also hilft ein SSD-Slog "nur" bei Sync-writes. Mein Pool steht auf "Standard" - sollte ich den jetzt auf "always" setzen, damit das auch bei SMB & Co. funktioniert?
 
In dem Blog hier Nex7's Blog: ZFS Intent Log wird das thematisert.Ist durchaus interessant.Wäre allerdings nett, wenn einer der ZFS Kenner hier das bestätigen oder verneinen kann.

Allerdings wird "always" in den Dokus die ich von Oracle finden konnte nicht genannt.Da wird nur von "Latency" und "Throughput" gesprochen, selbst "Standard" gibt es da nicht...wobei Latency als Standard hinterlegt ist, also sollte Latency=Standard sein..
 
Zuletzt bearbeitet:
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