[Sammelthread] ZFS Stammtisch

Ja.
Midnight Commander mc starten und
/var/web-gui/_log/napp-it.cfg bearbeiten.

PW löschen (oder Datei löschen)
Im Login Fenster von napp-it erscheint dazu ein kurzer Hinweis
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bei einer Optane oder anderen Highend NVMe wird es vermutlich nicht ganz so wichtig sein, wenn man man nur eine Queue hat zum Abarbeiten. Ich vermute aber mal dass viele günstigere NVMe sehr stark davon profitieren werden. Neben NVMe hotplug das auch gerade in Illumos landet, sicher ein wichtiger NVMe Fortschritt. Falls @snipor keine Probleme mit seiner Intel-Serie unter ESXi feststellen kann und das an OmniOS rückmeldet, wird es auch unter ESXi 6 insgesamt weniger weniger Probleme mit manchen NVMe geben (ESXi 5 wird dann halt nicht mehr unterstützt).

Insgesamt landen in Illumos (NexentaStor,OmniOS,OpenIndiana,SmartOS) eh gerade so viele neue Features auf Einmal wie seit langem nicht mehr. Das nächste OmniOS 151032 stable wird ein echtes Hammer-Release.

Der Solarish SMB Server, der immer schon besondere Performance, Windows SID und ntfs artige ACL, Windows SMB Gruppen und problemlose Unterstützung für ZFS Snaps=Windows vorherige Version bietet, kommt jetzt SMB 3.02 dazu, sowie persistent handles im Failover Cluster, Feature #11031: SMB3 persistent handles - illumos gate - illumos

Dazu kommen all die Nettigkeiten die aktuell in Open-ZFS landen wie ZFS Verschlüssellung, Allocation Classes mit speziellen vdev, sequentielles Resilvering oder Trim für SSDs um einige nach ihrer Wichtigkeit für mich aufzulisten.
 
Habe meinen Server erweitern wollen

HBA (DELL H310) IT Mode eingebaut und durchgereicht (ESXI 6.7 U3)
die angeschlossenen Platten tauchen einfach nicht bei Napp It auf.

Ein zwetes Napp It nur mit deisem Controller erstelt und siehe da alles paletti.

Welche Schritte muss ich vollziehen das dieser Conti in der Orginal Version seine Platten anzeigt ?
 
Danke gea, hat wunderbar geklappt.

Mit all den neuen Features in OmniOS bin ich echt am überlegen ob ich von Solaris wechseln soll - hing bisher primär an der Verschlüsselung per Filesystem.
 
Performancemäßig war Solaris bisher immer etwas besser. Und hatte ZFS Verschlüssellung, SMB3, NFS 4.1, vdev remove aich für Raid-Z und sequentielles Resilvering. Dazu für kommerzielle Kunden Support-Garantie bis 2035+.

Für private Nutzung sehe ich Illumos langsam als praktisch gleichwertig, in manchen Dingen sogar voraus (Replikation verschlüsselter Dateisysteme oder LX/Bhyve Zonen). Auch für kommerzielle Nutzung ist OmniOS LTS bis auf den Ultra Langzeitsupport eine echt gute Alternative.
 
Hi

Hatte auf meinem napp-it SSD NFS Store nur noch 90GB frei, oder so. Also habe ich eine 230GB VM (thick) verschoben, und die ursprüngliche VM auf der SSD gelöscht. Habe jetzt immer noch nur 100GB frei. Muss ich da noch was bereinigen auf dem ZFS? Nach mir müsste da jetzt noch mehr Platz frei sein nach der Löschaktion.

FreeSpace.PNG

- - - Updated - - -

Ah, Idiot, hatte da noch Schnappschüsse drauf

*/erledigt
 
Update zu Open-ZFS Allocation Classes
(Das sind spezielle vdevs für die dedup Tabelle, Metadaten, kleine ios oder gezielt für einzelne Dateisysteme)

Dedup und Spezielle Vdevs brauchen die gleiche Redundanz wie der restliche Pool. Benutzt man eine einzelne Platte (SSD/NVMe) und fällt diese aus, so ist der Pool verloren. Unterstützt werden daher neben einzelnen Platten n-way Mirrors. Bei mehreren Mirrors findet eine Lastverteilung statt. Raid-Zn wird nicht unterstützt.

Dedup- und spezielle vdevs kann man aus einem Pool auch wieder entfernen. Das klappt aber nur, wenn alle vdevs im Pool die gleiche ashift Einstellung haben, z.B. ashift=12 für 4k Platten.

Im aktuellen Illumos gibt es noch das Problem, dass bei einem Pool aus ashift=12 vdevs und einem special vdev mit anderem ashift, z.b. ashift=9 der Pool crasht wenn man versucht den zu entfernen. Im aktuellen napp-it dev stelle ich daher von ashift=auto auf ashift=12 als Default beim Erstellen oder Erweitern eines Pools um.

Ich habe das mal in der Illumos-dev Mailliste gemeldet und hoffe dass dieser Bug bald beseitigt wird.

Der Vollständigkeit halber, falls jemand ZoL nutzt
panic when removing vdev from pool with different-ashift special/dedup vdev · Issue #9363 · zfsonlinux/zfs · GitHub
 
Habe mit Schrecken gesehen, dass die vmwaretools für Solaris nicht mehr weiterentwickelt werden. Damit dürften dann Solaris-Gäste wohl insgesamt bei ESXi immer schlechter supported werden, vermute ich mal? Vor allem leider für das „echte“ Solaris, da Oracle wohl eher kein Interesse hat, für ESXi eigene Treiber zu bauen... :(
 
Der Trend geht ja ganz allgemein zu den open-vm-tools.
open-vm-tools/open-vm-tools/modules/solaris at master · vmware/open-vm-tools · GitHub

Ansonsten.
Solaris 11.4 war bisher immer der schnellste ZFS Server, hatte bei weitem die meisten Killer-Features und bietet Support Garantie bis 2037+ für zahlende Kunden. Für private Nutzung ändert sich aber gerade vieles. Bis auf den Performanceaspekt sieht es so aus


Code:
                      Solaris 11.4    OmniOS 151032 (Solaris Fork, vorraussichtlich, November 2019)
SMB kernelb. Server   v 3.1           v 3.02
             Client   v 2.1           v 3.02

NFS Server            v 4.1           v 4.0 

ZFS Verschlüssellung  ja              ja
zfs send encr.        nein            ja
 
spezielle vdev        nein            ja

sequ. Resilvering     ja              ja		 
vdev remove           ja (alle)       ja (nur mirror und basic) 

LX/Linux Zonen        nein            ja
Byhve Virtualisierer  nein            ja

Opensource            nein            ja 
Support (kommerziell) ja              ja
Bugfixed (free)       nein            ja

Für nichtkommerzielle Nutzung ist OmniOS/OI/SmartOS neuerdings deutlich attraktiver.
 
Zuletzt bearbeitet:
Featuremäßig (inkl. Bug bei vdev remove von special/dedup vdev) sind Illumos und ZoL gleichauf. Die Replikation zwischen beiden sollte also nicht daran scheitern. Ich habe das aber noch nicht versucht.

Ich würde als erstes ein Ziel angeben, dass noch nicht existiert. Als Alternativoption raw send (-w) versuchen. Damit wird das verschlüsselte Dateisystem direkt übertragen und kann auf dem Zielsystem mit dem ursprünglichen Schlüssel entsperrt werden.
 
Hallo,

dürfte ich um Hilfe bei einem Problem bitten? Wir betreiben einen OmniOS v11 r151014 Server, welcher neben NFS und CIFS auch 5 iSCSI Targets hostet. Die LUNs sind sowohl volumen- als auch dateibasiert. Alles funktioniert gut, bis der scrub startet. Denn nach einer Weile verlieren die iSCSI Initiators ihre Verbindung zu den LUNs bis man einen Rescan in der Datenträgerverwaltung durchführt. Nachdem ich das Problem erstmal bemerkt habe, hab ich versucht über das ZFS/Scrub Tuning den Scrub zu verlangsamen (z.b. zfs_scan_idle erhöht). Allerdings ist in der Beschreibung die Rede von "user I/O". Ich vermute, dass der comstar dienst eher als system betrachtet wird, womit dieses Tuning zwecklos wäre.

TL;DR: Mein Scrub wirkt sich negativ auf den iSCSI Target Dienst aus, worauf hin Clients die Verbindung verlieren. Bin ich damit hier richtig? Hat jemand einen Tip für mich, oder dieses Problem selbst schon einmal gehabt?

MfG, Nico
 
Ich würde als erstes ein Ziel angeben, dass noch nicht existiert.
Hi,
auf die kluge Idee bin ich zwischenzeitlich auch schon gekommen und habe deshalb meine Frage gelöscht. War mir nicht klar, dass schon jemand darauf antwortet, üblicherweise mache ich das nicht. Die Frage war nur einfach Käse :d
Vielen Dank trotzdem und Grüße
Martin

- - - Updated - - -

Komme ich eigentlich von 151033 zurück auf 151032? War mir beim Upgrade nicht klar, dass bloody schon 151033 ist.
Oder muss ich die VM neu anlegen?
 
Ich würde zwei Dinge versuchen

- Begrenzen des Arc Caches z.B. auf 60-70% RAM via set zfs:zfs_arc_max =

Tuning the Oracle Solaris Kernel - Oracle Solaris Tunable Parameters Reference Manual
ZFS weist den RAM zwar dynamisch zu, es kann aber manchmal durchaus hilfreich sein, RAM freizulassen

- neueres OmniOS
151014 ist schon recht alt. Ich würde aber vermutlich auf 151032 warten, da damit sequentielles Resilvering kommt.

- - - Updated - - -

Hi,

Komme ich eigentlich von 151033 zurück auf 151032? War mir beim Upgrade nicht klar, dass bloody schon 151033 ist.
Oder muss ich die VM neu anlegen?

Seit dieser Woche ist die Bloody bereits 151033. Die bisherige 151031 bloody geht gerade in 151032 stable über. Ob das Downgrade auf 151032 stable klappt, muss man probieren. Aktuell stehen die Chance gut da es sich ja eigentlich noch um das gleiche OS handelt. Wenn nicht, dann ein früheres BE starten und das upgraden.
 
Hi,

bezüglich des obigen feature Vergleich Solaris 11.4 vs OmniOS habe ich mal ˋne Frage bezüglich des Verschlüsselung eines ZFS filesystems unter Solaris 11.4.

- Müssen für einen replication job via napp-it beide ZFS filesysteme unlocked sein, damit dies funktioniert? Sprich Quelle und Ziel, wenn beide mit encryption angelegt wurden? Das zfs send/receive unverschlüsselt übers Netzwerk läuft ist mir sowei klar. Oder reicht es auch, wenn nur das Quell filesystem unlocked ist? Auch nach blicken in die Oracle Doku ist mir das Ganze, trotz der Beispiele, irgendwie noch nicht 100% richtig klar.

Hintergrund der Frage, es soll regelmässig auf ein Backupsystem repliziert werden und das System nur für den Zweck kurzzeitig eingeschaltet und danach wieder zeitnah runtergefahren werden. Wäre natürlich klasse das dortige fs nicht jedesmal wieder händisch unlocken zu müssen.
 
Zuletzt bearbeitet:
Ich müsste das jetzt selbst ausprobieren. Es sollte aber unter Solaris wohl so sein:

Beide Dateisysteme müssen unlocked sein, da die Übertragung unverschlüsselt erfolgt.
Das Zieldateisystem (unter einem unlocked parent) erhält dann den Parent Key

https://docs.oracle.com/cd/E37838_01/html/E61017/gkkih.html#SVZFSgkkof

Unter OmniOS kann die Übertragung verschlüsselt erfolgen und das Zieldateisystem ist verschlüsselt.
Unlock dann mit dem Key für das Quelldateisystem
 
Das hatte ich mir fast schon gedacht, gibt wohl mit sru12 oder so ein feature, dass nun zumindestens von einem unencrypted fs auf ein bereits mit encryption versehenes fs repliziert werden kann. Aber das ist ja hier nicht relevant.

Wäre es theoretisch realisierbar als keysource neben prompt, password auch noch auf ein keyfile zu referenzieren, welches auf dem Quell fs liegt und bspws. per smb freigegen und unlocked ist, so dass das Backuo System beim boot das Ziel fs automatisch unlocked? Vorausgesetzt natürlich das das durchlaufende Quellsystem vorher bereits einmal händisch unlocked wurde? Ich hoffe man versteht worauf ich hinaus will.
 
Über die nappit GUI wahrscheinlich nicht. Per eigenem Skript auf jeden Fall. Ist theoretisch nur ein Einzeiler.
Verzeichnis mit Keyfile per NFS in der fstab (bzw. vfstab) verbinden. Dann in der rc.local Keyfile laden und Pool importieren.

-----------
Leider gibt es kein Quick-and-Dirty Bootscriptfile in Solaris wie rc.local.
So müsstest Du Dir ein existierendes Service File als Vorlage nehmen. Optional auch hier beim Start NFS mounten, Pool mit Keyfile importieren.
Beim Stop dann Pool exportieren und NFS umounten.
 
Ich nehme an, es geht darum dass eine Replikation ein Quell (oder Zieldatesystem) automatisch aufschließen kann.

Mit napp-it 19.dev könnte man dazu die Pre/Post Funktionalität nutzen. Wenn man da ein Script "/var/web-gui/_log/jobs/jobid.pre" anlegt (jobid= jobid des replikationsjobs) so wird dieses Script vor einer Replikation aufgerufen (also vor zfs receive oder zfs send).

Das Script könnte dann den Key bereitstellen, egal mit welchem Verfahren. Bei "prompt" müsste man Expect nutzen um den interaktiv bereitzustellen. Ein Perl Script dazu könnte so aussehen:

Code:
use Expect;
my $exp; #->raw_pty(1);
$exp = Expect->spawn("sudo /sbin/zfs key -l -r dateisystem") or die "Couldn't mount: $!\n";     
     $exp->expect(1,
        [ 'Enter' =>
        sub {
              $exp->send("prompt\r");                                     
              exp_continue;
            }
                        ]
      );
$exp->soft_close();

Ein zusätzliches script jobid.post könnte dann die Dateisysteme wieder abschließen


Den Schlüssel sollte man dann aber nicht lokal bereitstellen sondern wenigstens von einem USB Stick, besser einen iSCSI target oder per wget von einem Webserver beziehen.
 
Hi Günther,
ich spiele gerade mit den Appliance Maps herum und mir sind zwei Probleme für meinen Server aufgefallen:
- bei 3v gibt es in der Cols Anzahl nur ...,5,8,... - ich würde für den ML350p 6 Stück benötigen. Das konnte ich per Workaround lösen (im Browser Quelltext untersuchen und einen Wert auf 6 ändern).
- die Variante 2h gibt es bisher nicht, obwohl diese zumindest bei HP Server auch recht gebräuchlich ist. Per Workaround kann ich diesen Wert zwar auch einstellen, aber hierfür gibt es noch keine grafische Darstellung.
Wäre es eine Option, die beiden Dinge im nächten Dev Release zu berücksichtigen?
Viele Grüße
Martin
 
Die Col-Anzahl läßt sich einfach in der "/var/web-gui/data/napp-it/zfsos/05_Disks and controller/12_Appliance_Maps=-lin/00_create_maps/action.pl" anpassen (Line 140: 1,2,4,6,8,..)

Die Bereitstellung von 2h (2,5" horizontal) ist aufwändiger da dann auch die ganzen Textplatzierungen angepasst werden müssen. Als Workaround für die Darstellung 3h nehmen. Ich setze das mal unverbindlich auf die Wish List. Aktuell komme ich aber nicht dazu, vor allem wegen der neuen Features in Illumos. Da ist erstmal ein Keyserver mit unlock via SMB in der Mache.
 
Alles klar, vielen Dank! Wenn ich mal Langeweile habe, würde ich mir das selbst mal ansehen :d
 
Danke für die Rückmeldungen, die Annahmen gehen in die richtige Richtung, idealerweise sollte das Ganze aber sogar unabhängig vom Replikationsjob sein.

Die Prämissen wären:

- Quellserver läuft immer und Quell fs ist immer unlocked
- Zielserver läuft nur sporadisch (bspws. 1x die Woche, bootet und unlocked das Ziel fs automatisch während des Starts, zu einem definierten Zeitpunkt fährt das System wieder herunter, bis zum nächsten mal.
- Replikationsjob läuft regelmässig während eines slots wo das Zielsystem verfügbar ist.

Muss mir das mit den pre und post Skripten mal näher ansehen, komme im Moment aber auch nicht richtig dazu, mir Zeit dafür zu nehmen.
 
Hallo,

mal eine Frage... ich hab einen nappit Server als SMB Filer, läuft einwandfrei. Snaps sind aktiviert und funktionieren auch.
Unter Windows werden auf dem verbundenen Netzlaufwerk allerdings keine "Vorgängerversion wiederherstellen" sichtbar.
Eine Domäne hab ich nicht.

Hab ich eine Einstellung übersehen?
 
nappit ist kein Server, sondern eine WebGUI (+x) für unterschiedliche Betriebssysteme und Services.
Insofern:
welches OS? Linux? Oracle Solaris? OmniOS? ...?
welcher SMB Dienst? Kernelfunktion von Solaris? Samba?

Im Idealfall sogar jeweils noch mit Versionen? Und sogar Config?
 
Kein Problem,

die normale nappit OVA von nappit.org, durchgereichter B140i (Server ist ein ML30Gen9). 3x4TB als RAIDZ1, 1x 4TB Spare

config:
Code:
pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 2h2m with 0 errors on Mon Oct 21 05:02:07 2019
config:

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz1-0  ONLINE       0     0     0
	    c3t1d0  ONLINE       0     0     0
	    c3t2d0  ONLINE       0     0     0
	    c3t3d0  ONLINE       0     0     0
	spares
	  c3t0d0    AVAIL   

errors: No known data errors
Pool details zdb -C tank

   

   

   

MOS Configuration:
        version: 5000
        name: 'tank'
        state: 0
        txg: 3852022
        pool_guid: 4952639535510411834
        hostid: 1253576321
        hostname: 'napp-it028'
        com.delphix:has_per_vdev_zaps
        vdev_children: 1
        vdev_tree:
            type: 'root'
            id: 0
            guid: 4952639535510411834
            create_txg: 4
            children[0]:
                type: 'raidz'
                id: 0
                guid: 16858915214322509009
                nparity: 1
                metaslab_array: 39
                metaslab_shift: 36
                ashift: 9
                asize: 12002320711680
                is_log: 0
                create_txg: 4
                com.delphix:vdev_zap_top: 35
                children[0]:
                    type: 'disk'
                    id: 0
                    guid: 4495926704472793605
                    path: '/dev/dsk/c3t1d0s0'
                    devid: 'id1,sd@SATA_____MB4000GVYZK_________________ZC16ZV2D/a'
                    phys_path: '/pci@0,0/pci15ad,7a0@16/pci103c,8165@0/disk@1,0:a'
                    whole_disk: 1
                    DTL: 159
                    create_txg: 4
                    com.delphix:vdev_zap_leaf: 36
                children[1]:
                    type: 'disk'
                    id: 1
                    guid: 10476160904033746973
                    path: '/dev/dsk/c3t2d0s0'
                    devid: 'id1,sd@SATA_____MB4000GVYZK_________________ZC17027A/a'
                    phys_path: '/pci@0,0/pci15ad,7a0@16/pci103c,8165@0/disk@2,0:a'
                    whole_disk: 1
                    DTL: 158
                    create_txg: 4
                    com.delphix:vdev_zap_leaf: 37
                children[2]:
                    type: 'disk'
                    id: 2
                    guid: 12772962802606645982
                    path: '/dev/dsk/c3t3d0s0'
                    devid: 'id1,sd@SATA_____MB4000GVYZK_________________ZC16ZA4L/a'
                    phys_path: '/pci@0,0/pci15ad,7a0@16/pci103c,8165@0/disk@3,0:a'
                    whole_disk: 1
                    DTL: 157
                    create_txg: 4
Code:
OmniOS 5.11     omnios-r151028-3aeadc46d9       March 2019
Noch mehr Infos benötigt?
 
Zuletzt bearbeitet:
Und nicht nur Snapshots angelegt, sondern die Dateien auch anschließend geändert? Sonst werden keine Vorgängerversionen angezeigt.
 
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