[Sammelthread] ZFS Stammtisch

[Shutterfly]

Das Problem was ich für mich persönlich da sehe: Totales Neuland. Und ich habe leider nicht die Hardware und im Moment nicht das Geld um mir eine zweite Maschine nur für Tests und Spielerein aufzusetzen.

Ich hatte mal nach OmniOS angeschaut, jedoch aus oben genannten Gründen habe ich schlichtweg Schiss, das es am Ende nicht lüppt.

 

[gea]

Unter Linux ist es relativ mühsam ZFS zum Laufen zu bekommen und Glück wenn es nach dem nächsten Update noch tut. Unter Solaris btw OmniOS funktioniert das einfach und wenn etwas schiefgeht gibt es die bootbaren Snaps um auf einen früheren Systemstand zu gehen.

Probleme entstehen meist durch unter Unix/Solaris nicht unterstützte Hardware. Unix unterstützt halt nicht soviel wie Linux oder Windows..

 

[Shutterfly]

Aufgrund meines Setups wäre mein Plan eine virtualisierte Maschine mit durch gereichtem SATA-Controller, wo alle HDDs dran hängen gewesen. Neben NFS für weitere virtuelle Maschinen soll auch SMB für Windows und Linux-Clients bereitgestellt werden.

Unter Linux würde ich kein ZFS nutzen wollen derzeit. Das ist mir brisant bzgl. Abhängigkeiten etc. Daher hatte ich mit FreeNAS geliebäugelt, da dort erst einmal alles aus einer Hand kommt und per GUI nutzbar ist. Für den Anfang für ZFS wäre mir das lieber gewesen. Für NFS oder SMB nicht notwendig, das kann ich auch über Configs aber ZFS ist halt #neuland

 

[gea]

Dafür habe ich vor ca 10 Jahren das All in One Konzept vorgestellt. Man sollte aber nach Möglichkeit einen SAS Controller nehmen. Die gibts auch günstig gebraucht. Den kann man entweder komplett an die Storage VM geben oder einzelne SAS/Sata Platten problemlos durchreichen. Und als GUI kann man mein napp-it 19.12 free nehmen. Unter ESXi kann man mein vorkonfiguriertes Template einsetzen.

siehe 5b unter https://napp-it.org/manuals/index.html

 

[Shutterfly]

Ich glaub ich schaue mir die nächsten Tage OmniOS einfach mal in einer VM an. Kostet ja nix. Vielleicht motiviert mich die ZFS Encryption so weit mich damit zu beschäftigen

 

[morph027]

Unter Linux ist es relativ mühsam ZFS zum Laufen zu bekommen und Glück wenn es nach dem nächsten Update noch tut. Unter Solaris btw OmniOS funktioniert das einfach und wenn etwas schiefgeht gibt es die bootbaren Snaps um auf einen früheren Systemstand zu gehen.

Probleme entstehen meist durch unter Unix/Solaris nicht unterstützte Hardware. Unix unterstützt halt nicht soviel wie Linux oder Windows..

Das kann ich jetzt so nicht unterschreiben. Nutze ZFS on Linux jetzt seid 5 Jahren produktiv (seit Proxmox 3.4) und hatte nicht ein winziges Problem. Erst auf LUKS, jetzt seit 0.8 umgestellt auf native Verschlüsselung.

 

[gea]

Bei den Unix Optionen Free-BSD, Illumos und Solaris ist die Situation klar. ZFS tut einfach und die Webmanagement Tools für ZFS Storage dafür sind der Maßstab. Der Focus der Distributionen liegt klar auf Storage, bei den Solaris basierten Optionen sogar ohne "Fremdsoftware". Da ist alles was Storage betrifft (ZFS, FC/iSCSI, NFS, SMB) made by Sun, jetzt Oracle. Alles aus einer Hand wie man es sonst nur bei Apple und Windows kennt.

Bei Linux kommt es darauf an, welche der vielen Distributionen man nutzt. Die Unterstützung von ZFS verbessert sich aber tatsächlich, auch wenn ZFS von den Linux "Machern" immer noch abgelehnt wird. Man hat halt nicht die Situation wie bei Unix wo ausschließlich ZFS genutzt wird. Unter Linux ist ZFS eine Option von vielen und das merkt man.

 

[pfistphi]

Hallo Zusammen,

ich habe ein kleines Problem.
Ich habe einen Freenas 11.3 Server mit 3x 3TB Mirror.
Wenn ich Daten auf die SMB Freigabe kopiere wird das Änderungs- und Erstelldatum auf den Kopierzeitpunkt gesetzt.
Wie kann ich verhindern, dass das Erstelldatum geändert wird?
Ich hatte davor ZoL + Samba am laufen und da hatte ich dieses verhalten nicht.

Danke & Gruß
Philipp

Edit:
Link offenbar werden die timestamps beim kopieren neu gesetzt. Beim verschieben, bzw beim kopieren mit robocopy bleiben die originalen erhalten.

 

[danielmayer]

beim "cp"-Befehl mit "-p" bleiben sie auch erhalten.

 

[asche77]

Kurze Frage zu illumos / omniOS: Ich habe drei Seagate NAS 4TB (Baujahr 2014-2015) an einem (durchgereichten) SAS3008 Controller in meinem Dell T30. Zwei davon erkennt omnios problemlos; der mirror daraus läuft ohne Probleme. Die dritte HDD allerdings will omnios ums Verrecken nicht erkennen. In meinem Windows-PC wird sie problemlos erkannt und lässt sich formatieren, partitionieren etc. Es ist egal an welchem Strom- oder SATA-Stecker ich sie anschließe.

Weiss jemand die Ursache bzw. wie ich die in omnios zum laufen bringe?

Da sie der gleiche Typ wie die anderen Platten ist, vermute ich eher kein PIN3 Problem ...?

Am SAS-HBA jedenfalls scheint sie noch aufzutauchen (4 SSD und 3 HDD am SAS; 1x VMDisk am scsi-bus):

omniosce:~$ /usr/sbin/cfgadm -l -v
Ap_Id                          Receptacle   Occupant     Condition  Information         When         Type         Busy     Phys_Id
c1                             connected    configured   unknown         unavailable  scsi-bus     n        /devices/pci@0,0/pci15ad,1976@10:scsi
c3                             connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@2:scsi
c4                             connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@8:scsi
c5                             connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@10:scsi
c6                             connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@20:scsi
c7                             connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@40:scsi
c9                             connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@v0:scsi
c10                            connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@4:scsi

Auch dmesg meldet 7 "online" SAS-Platten (mpt_sas1-5, mpt_sas7 und mpt_sas8).

Schon format -e erkennt aber die Platte nicht:

omniosce:~$ pfexec format -e
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c0t55CD2E414DFC14FAd0 <ATA-INTEL SSDSC2KG01-0150-1.75TB>
          /scsi_vhci/disk@g55cd2e414dfc14fa
       1. c0t5000C500AFC6397Bd0 <ATA-ST4000VN008-2DR1-SC60-3.64TB>
          /scsi_vhci/disk@g5000c500afc6397b
       2. c0t5000C5008BDD7558d0 <ATA-ST4000VN000-1H41-SC46-3.64TB>
          /scsi_vhci/disk@g5000c5008bdd7558
       3. c0t5002538C404114C8d0 <ATA-SAMSUNG MZ7KM1T9-CSLB-1.75TB>
          /scsi_vhci/disk@g5002538c404114c8
       4. c0t50011731011D6D40d0 <ATA-SDLF1CRR-019T-1H-RPA1-1.75TB>
          /scsi_vhci/disk@g50011731011d6d40
       5. c0t50011731011E98A4d0 <ATA-SDLF1CRR-019T-1H-RPA1-1.75TB>
          /scsi_vhci/disk@g50011731011e98a4
       6. c1t1d0 <VMware-Virtual disk-2.0-24.00GB>
          /pci@0,0/pci15ad,1976@10/sd@1,0
Specify disk (enter its number):

 

[gea]

Nur mal ins Blaue...

Ich würde probehalber multipath io deaktivieren, z.B.

deaktivieren in
/kernel/drv/mpt_sas.conf bzw
stmsboot -d

in napp-it: Menü Disks > SAS config bzw. Disks > mpio help

 

[asche77]

@gea Danke, jetzt zeigt cfgadm auch "connected", aber die Festplatte (c9) wird weiterhin nicht erkannt (auch nach einem cfgadm -c nicht):

Ap_Id                          Receptacle   Occupant     Condition  Information
When         Type         Busy     Phys_Id
c9                             connected    unconfigured unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@v0:scsi
c10                            connected    configured   unknown         unavailable  scsi-sas     n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@4:scsi      
c10::dsk/c10t5000C5008BDD7558  connected    configured   unknown    ATA ST4000VN000-1H4168         unavailable  disk         n        /devices/pci@0,0/pci15ad,7a0@15/pci1028,1f45@0/iport@4:scsi::dsk/c10t5000C5008BDD7558d0

Dann werde ich die wohl für OmniOS abschreiben und anderweitig verwenden müssen.

Mein HP N40L mit OmniOS erkennt sie:

c1t3d0

single

via dd

ok

4 TB

S:0 H:0 T:0

ATA

ST4000VN000-1H41

Z30170F6

und bindet sie auch ein in den pool.

 

[docsnydor]

ich habe 2x 10 TB Festplatten. Ich würde gerne folgendes machen:

- je Platte eine 4 TB Partition erstellen und daraus einen zpool mirror (für wichtige, dynamische daten)
- jeweils rest der platte partition und mit mergerfs zusammen friemeln (für unwichtige, statische daten)

Kann man das so machen?

 

[Shutterfly]

Technisch solltest du das so machen können, wenn du den Pool selbst erstellst. Ob fertige Software-Lösungen das können keine Ahnung. Ob dies sinnvoll ist oder du dir später total ins Knie schießt, weil ZFS z.B. nicht sauber mit dem HDD-Controller arbeiten kann, kann ich dir nicht sagen.

 

[docsnydor]

Okay, ich probiere es aus. OS wird ein stinknormales Debian. Zur Zeit habe ich überhaupt keine Lust mehr auf die Software-Fertiglösungen.

 

[frittes]

Ein ZFS Pool selber ist auch ein ZFS Dateisystem. Für selber angelegte Dateisysteme ist das quasi das Parent Dateisystem wo man Defaults festlegen kann.

Die ideal Sicherungsoption wäre ZFS Replikation. Ist viel schneller als ein Copy mit midnight commander und erhält Dateisystem Attribute. Man kann damit auf einen anderen Pool oder Dateisystem lokal oder im Netz sichern. Lokal wäre eine USB Platte mit einem ZFS Pool ideal. Siehe Menü Jobs > Replikation. Ein Replikations Job kümmert sich automatisch um die Snaps. Man könnte damit (per ESXi hot snap) auch laufende VMs sichern.

Snaps sind im Dateisystem erreichbar unter dateisystem/.zfs/snapshot (mc) oder per SMB unter share\.zfs\snapshot. Per SMB ist der einfachste Zugriff über einen Maus-Rechtsklick auf einen beliebigen Ordner und dann mit Eigenschaft > vorherige Version.

Ich habe das mal getestet, da ich gerne auf einem Share Schattenkopien verwenden möchte. Wenn ich einen manuellen Datasnap mache funktioniert es mit der Vorgängerversion. Wenn ich unter Jobs einen autosnap Job alle 5 Minuten anlege, wird dieser zwar ausgeführt, aber es existiert weder im napp-it ein Snapshot noch lässt sich unter Windows die Vorgängerversion wiederherstellen.

Was mache ich falsch?

 

[gea]

Prinzipiell muss man einfach den Auto_service auf every 1 oder every 5 stellen, dann einen Autosnap Job mit month=every, day=every, hour=every und min=every-5 anlegen. Dann sollte das schon laufen. Kontrollieren kann man die Ausführung im Job Menü und das Ergebnis im Snapmenü wenn man mit der Jobid Snaps auflisten läßt.

Wenn man Delzero aktiviert, werden alle Snaps ohne Daten/size=0 bis auf den letzten gelöscht. Mit keep und hold kann man die Anzahl und das Vorhalten der Snaps beeinflussen. Wenn man Autosnap auf den Pool ausführt und recursive deaktiviert werden keine Snaps auf Dateisysteme angelegt.

Ansonst
welches OS und welches napp-it

 

[gea]

Es gibt ein Sicherheitsupdate zu OpenSSL in OmniOS 151032w
omniosorg/omnios-build

Es behebt einen kritischen Bug im letzen OpenSSL 1.1.1e der auch email per TLS verhindert
Topicbox

 

[gea]

Info
In napp-it ab 19.12 kann man jetzt unter OmniOS/OI im Menü Services > Bonjour Support für Apple Timemachine via SMB aktivieren (Kernelbasierter Solarish SMB Server).

 

[supemole]

Info
In napp-it ab 19.12 kann man jetzt unter OmniOS/OI im Menü Services > Bonjour Support für Apple Timemachine via SMB aktivieren (Kernelbasierter Solarish SMB Server).

Das ist ja klasse, welche OmniOS Version unterstützt denn Apple Time Machine Backups über SMB? Ich dachte immer, dass in dem Protokoll noch Apple spezifische Anpassungen fehlen.

 

[gea]

Ich habe es mit OmniOS 151032 stable getestet. Da sind alle neuen Solarish SMB 3.0 und ZFS Erweiterungen drin und das ist allein deshalb schon die erste Wahl. Eventuell geht es auch schon mit der 151030 LTS. Da sollte das Full Sync Feature bereits drin sein (wurde Ende 2017 in Illumos integriert) und SMB 2.1 könnte vielleicht auch ausreichen, https://illumos.topicbox.com/groups/omnios-discuss/T97ac7717dd31b5b5/smb-fullsync-for-time-machine

Habe ich aber wie gesagt nicht getestet.

 

[frittes]

Prinzipiell muss man einfach den Auto_service auf every 1 oder every 5 stellen, dann einen Autosnap Job mit month=every, day=every, hour=every und min=every-5 anlegen. Dann sollte das schon laufen. Kontrollieren kann man die Ausführung im Job Menü und das Ergebnis im Snapmenü wenn man mit der Jobid Snaps auflisten läßt.

Wenn man Delzero aktiviert, werden alle Snaps ohne Daten/size=0 bis auf den letzten gelöscht. Mit keep und hold kann man die Anzahl und das Vorhalten der Snaps beeinflussen. Wenn man Autosnap auf den Pool ausführt und recursive deaktiviert werden keine Snaps auf Dateisysteme angelegt.

Ansonst
welches OS und welches napp-it

Genau so habe ich es gemacht.

So sieht der Job aus:



Der Jpb läuft auch alle 5 Minuten, aber:

Weder ein Snapshot unter dem Snapshots-Menü vorhanden, noch Vorgängerversion unter Win 10.

OmniOS omnios-r151032-19f7bd2ae5

napp-it 19.12b4

 

[gea]

Ich habe es gerade selbst in dieser Kombination getestet und konnte kein Problem feststellen.
Siehe Snapjob ..1685

 

[frittes]

Merkwürdig.

Bei mir steht im Job-Log hinter info: nichts.

Wenn ich unter Snapshots nen Datasnap mache, funktioniert das einwandfrei.

So erstelle ich den autosnap:




EDIT: Jetzt geht es. Habe das OmniOS eben auf aktuellen Stand gebracht, alles neu gebootet, Job neu angelegt und nun sieht der Job-Log so aus:

 

[gea]

Ich sehe keinen Zusammenhang mit der OmniOS Version. Ich vermute mal das irgendwas "blockiert" hat und ein Reboot das entscheidende Event war.

 

[rigel]

Ich habe in napp-it eine wöchentliche Statusmail eingerichtet (immer samstags um 20 Uhr). Letzten Samstag hat das aber nicht funktioniert. Auch in der Jobübersicht sehe ich, dass die letzte Ausführung vor zwei Wochen am 28.03.2020 war:



Wie kann ich der Ursache hier auf die Spur kommen?

 

[gea]

Autojob wird hier alle 15 Minuten durch einen Cronjob angestoßen. Wird der Cronjob nicht gestartet oder so verzögert, dass er etwa erst eine Minute später ausgeführt werden kann (20:01 statt 20:00), so wäre das eine Erklärung. Ein einzelner Job hindert aber nicht weitere an der sofortigen Ausführung.

Eine mögliche Ursache wäre eventuell in System > Logs (aktuell oder einer der Vorversionen) oder in System > Faults zu finden.

 

[ces]

Hallo Gea,

kannst du dir erklären, wieso eine napp-it minio Instanz das Filesystem darunter ohne Grund ansprechen und damit den gesammten Pool aus dem spin-down holen könnte?

Meine HDDs des betreffenden Pools bleiben ohne Zugriffe von außen prinzipiell zuverlässig im spin-down. Seit ich meine bisherige minio-Installation (docker-container in einer Ubuntu-VM, mit in den container gemapptem ZFS-Volume) auf die (genial erdachte und umgesetzte!) integrierte omnios/napp-it-Lösung umgestellt habe, gehen jedoch die Platten nur kurz aus, um nach wenigen Minuten wieder hochzudrehen (und so weiter und sofort).
Dabei erfolgt kein aktiver Zugriff auf die minio-Instanz, da derzeit (noch zu Testzwecken) einzig eine duplicati-Installation einmal am Tag Daten darauf schriebt.
"Kille" ich den betreffenden minio-Prozess, bleiben die Platten langfristig im spin-down.
Dummerweise habe ich bei der Migration der minio-Instanz auch das ZFS-Filesystem von einem SSD-Pool auf den HDD-Pool umgezogen, so dass ich nicht mit Bestimmtheit sagen kann, ob sie zuvor im docker-container nicht doch periodisch die SSDs angesprochen hat, wo es dann natürlich nicht aufgefallen ist.
Ansonsten muss ich nochmal zurückbauen und das prüfen.

Danke
ces

 

[gea]

Mir ist nicht bekannt ob minIO periodisch auf die Platte zugreift. Ich muss aber auch sagen dass ich nirgendwo Spindown einsetze. Auf jeden Fall muss man für Spindown napp-it Monitoring und Acceleration (Topmenü neben logout) ausschalten und den Fehlerdienst fmd der den Pool regelmäßig prüft deaktivieren.

 

[rigel]

Eine mögliche Ursache wäre eventuell in System > Logs (aktuell oder einer der Vorversionen) oder in System > Faults zu finden.

Dort gibt es keinen einzigen Eintrag in der fraglichen Zeit. Laut /var/cron/olog ist der Job letzten Samstag auch ohne Verspätung ausgeführt worden, sofern die Angaben dort verlässlich sind:

>  CMD: perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/auto.pl
>  root 21046 c Sat Apr  4 20:00:00 2020
<  root 21046 c Sat Apr  4 20:00:00 2020

Loggt das napp-it-Skript auto.pl vielleicht noch irgendwohin, wo ich nach der Ursache suchen könnte?