[Sammelthread] ZFS Stammtisch

[kandamir]

Danke für die Anwort, @gea! Hatte die Antwort heute glatt übersehen... was Du schreibst über sequentiell und viele kleine Dateien kann ich durchaus nachvollziehen bzw. es ist mir bewusst. Ich hatte ja die Benchmarks zweimal laufen lassen (iozone 1GB): einmal USB3.0, einmal direkt SATA. Die Voraussetzungen sollten bis auf die Anbindung also gleich sein. Da über USB 3.0 nur die 90 MB/sec. zustande kamen, mache ich die USB3.0 Anbindung als Ursache aus. Und ich gehe sogar davon aus, dass die Schreibgeschwindigkeit effektiv sogar noch weiter einbrechen wird, da ich eher viele kleinere Dateien habe (Fotos, MP3, wenige Videos). Also genau das, was letztlich ausbremst. So kommt aber zusätzlich als Bremse noch USB3.0 dazu. Und das müsste ja viel mehr schaffen (5GBit/sec, da sind also 260MB/Sec. gut drin).

Zum Hotplug: das funktioniert ja rundsätzlich auch. Ich würde es mal „warmplug“ bezeichnen. So halbwegs hot, aber es müssen noch zwei, drei Handgriffe getan werden (dadurch ist es dann nicht mehr hot, sondern nur noch warm). Warum ist die Platte nicht automatisch connctet und konfiguriert? So muss ich das von Hand machen...

 

[frittes]

Hi

Wenn ich die VMs jetzt in einem einzelnen Dataset habe, welches per NFS dem ESXi zugewiesen ist, wie gehe ich da vor, wenn ich das auf einzelne Datasets verteilen will? Kann ich da einfach das grosse Dataset löschen, und dann kleinere anlegen? Muss ich da nacher für jedes Dataset eine einzelne NFS Freigabe im ESXi einhängen? Dünkt mich reichlich kompliziert und unhandlich, gerade auch was den Platzverbrauch angeht. Den muss ich ja wohl dann einzeln für jedes Dataset reservieren, richtig?

Bei mir siehts zur Zeit so aus, aber irgendwie profitiere ich noch gar nicht so richtig von dem Storage und seinen Möglichkeiten:

Anhang anzeigen 528381

Das liegt an dem Layout, was Du verfolgst.

Also aus meiner Sicht solltest Du applikationsgetrieben Dein Layout aufbauen. Nicht für jede Platte einen Pool!

Sinn ist es Pools zu haben mit vielen Platten dahinter, um die Ausfallsicherheit zu steigern.

Ich mache es so: Zwei SSDs für den VM Pool im Mirror. Die sicher ich ab und an noch mit XSI-Backup auf ne SSD in VMware (Host-Controller), die das ZFS nicht kennt. Darüber hinaus synce ich die Daten des Backups noch auf ne externe Platte. Also 2fach abgesichert.

Weiterhin gibt es, bei mir, dann noch einen Datenpool, auch mit vielen Platten, 6 an der Zahl im Raid-Z2. Die sicher ich nicht, da ich die Kapazitäten extern nicht bereitstellen kann. Deswegen 2 Platten als Ausfallsicherheit.

Beispielhaft:

POOL_SSD für VM-Images
POOL_HDD für Daten

Und da drauf erzeugst Du dann Deine ZFS-Filesystems, je nachdem, wie Du sie brauchst.

Dann kannst Du auch easy snapshotten und z.B. unter Windows recovern über Vorgängerversion.

 

[effemmess]

Moin,

ich hab eine leicht OffTopic-Frage...
Weiß jemand wo/wie ich genauere Infos zur OmniOS-Infiniband unterstützung finde? In den Release Notes für 151034 steht ja nur " Support for Mellanox ConnectX-4/5/6 NICs"
Evtl. doch nur Ethernet? Welche Protokolle? RDMA?

Grüße

 

[gea]

Ich habe das jetzt nicht verfolgt.

Belastbare Antworten zum Stand und der geplanten Weiterentwicklung der Treiber wird man wohl nur hier erhalten: https://illumos.topicbox.com/groups/developer

 

[AliManali]

Hi

Bringt mir bei einem ESXi AiO mit napp-it eine Optane für den Filer mit SLOG was? SLOG ist einfach Schreibcache, richtig? Am napp-it würden nur ein LSI SAS 2008 mit zwei Platten, sowie eine SSD für die VMs hängen. Da wird dann auch nich sonderlich viel kopiert im Normalfall.

Ich habe mir das napp-it pdf für Optane mal angesehen. Blicke da aber null durch, ob uns das was bringt.

 

[Trambahner]

Ein Slog ist _kein_ Schreibcache.

Ein Slog nimmt temporär die Daten auf, die als synchroner Schreibvorgang von ZFS verlangt werden. Ansonsten bestätigt ZFS den Schreibvorgang erst, wenn er auf dem Zielpool sicher abgelegt ist. Mit Slog bestätigt ZFS den Schreibvorgang bereits, wenn der Block auf das SLog-Device geschrieben wurde. Nichts desto trotz schreibt ZFS natürlich den Block dann aus dem Ram auf die Zieldevices.
Nippelt die Kiste ab, z.B. bei Stromausfall, werden beim nächsten Betrieb die noch nicht sicher geschriebenen Blocks vom Slog auf den Zielpool geschrieben. Das ist der einzige Fall, bei dem lesend auf die Daten in einem Slog zugegriffen wird

=> D.h. asynchrone Schreibaufträge (iSCSI und SMB/Samba und damit Filerdienste per default) profitieren 0,0 davon, synchrone Schreibaufträge (NFS und damit potentiell AIO-Datastores für die VMs) profitieren, werden aber nie schneller als asynchrone.
Sync kann man auch bewusst immer aktivieren oder deaktivieren; auf jedem einzelnen Dataset/ZVol. D.h. man kann NFS auch zwingen, asynchron zu schreiben. Damit verliert man aber Sicherheit für die Datenkonsistenz der VMs.
Andersrum kann man natürlich auch SMB zwingen, synchron zu schreiben.

=>kurz: mit den Standardsettings der Pools, Datasets und Zvols bringts für iSCSI und SMB Shares nix, für NFS ist es ein wichtiger Boost für vernünftige Geschwindigkeiten bei HDD-Pools und langsamen SSD-Pools, wo es aber nie schneller werden kann als bei async Zugriff auf den gleichen Pool.

 

[AliManali]

Ok. Und was ist genau der Unterschied zwischen synchronem und asynchronem Schreiben?

Ich sehe das halt so: Wenn ich z.B. eine ausgeschaltete VM per Midnight Commander von der SSD auf die HDD sichern möchte, scheitert der Schutz vom SLOG bei Stromausfall schon daran, weil die vmdk grösser als das SLOG Device ist? Und rein für den Betrieb der VMs selbst bringt das auch nichts?

Wie gesagt, da wird ein HBA mit zwei Platten und eine SSD mit den NFS Freigaben (VMs) dran hängen. Die VMs soll man per MC verschieben können, und auf den Platten gibts noch ein bisschen SMB.

Würdest Du da eine Optane für napp-it und SLOG mitnehmen wenn eh neu aufgebaut wird, oder reicht da für den filer wie weiter oben gea meinte eine Consumer SSD?

 

[Trambahner]

Async = ZFS nimmt Schreibauftrag an, puffert ihn im Ram (="Arc"), bestätigt dem aufrufenden Prozess "Schreibauftrag ausgeführt", führt diesen aber erst aus wenn es es für richtig hält/Zeit ist/Puffer volllaufen.
=> Prozess kann weiterarbeiten und wartet nicht.

Sync ohne Slog = ZFS nimmt Schreibauftrag an, puffert ihn im Ram (="Arc"), schreibt ihn auf das Ziel weg, wartet auf "ok" des Geräts und meldet erst dann dem Prozess "erledigt".
=> Prozess kann nicht weitermachen, bevor die Daten bestätigt weggeschrieben sind, sondern muss warten.

Sync mit Slog = ZFS nimmt Schreibauftrag an, puffert ihn im Ram (="Arc"), schreibt ihn aufs Slog weg, bestätigt dem Prozess "erledigt" und schreibt ihn auf das endgültige Ziel weg wie bei Async. Sobald das erfüllt, wird der endsprechende Block im Slog unnötig und entfernt.
=> Prozess kann weitermachen, sobald Slog-Schreibvorgang erledigt.
=> Daten bleiben eben nicht im Slog "gecached" (daher ists kein Schreibcache). Das Slog arbeitet quasi rollierend.


"Schreibauftrag" sind übrigens immer Datenblöcke, keine ganzen Dateien ! Es spielt daher keine Rolle, ob die VM-Imagedatei komplett ins Slog passt oder nicht, sondern ob Datenblöcke davon bereits comittet sind. ZFS fängt ja eh an, die Blöcke physikalisch wegzuschreiben und am Slog wieder freizugeben
Es geht nur drum, den Inhalt abzusichern, der noch im Ram ist und nicht bestätigt geschrieben ist.


Falls Du mit dem MC Files umkopierst, hat das mit NFS nix zu tun, sondern ist ein lokaler Kopiervorgang im Dateisystem und es gelten nur die eingestellten Eigenschaften des Datasets. Und die sind per default nicht "sync", nur die Daten die im Moment über NFS "eintrudeln".

 

[gea]

Ich würde das mal so beschreiben:

Alle einzelnen kleine und größere Schreibvorgänge in ZFS gehen immer und grundsätzlich in den RAM-Schreibcache und werden dabei z.B. an eine VM als auf Platte geschrieben gemeldet. Das geht sehr schnell da RAM auch bei kleinen Schreibvorgängen sehr schnell ist. Platten sind bei kleinen Schreibaktionen dagegen furchtbar langsam.

Hat man z.B. einen 4 GB RAM Schreibcache und der ist halb gefüllt, so wird der Inhalt als ein großer schneller sequentieller Schreibvorgang auf Platte geschrieben. Die restliche Hälfte übernimmt in dieser Zeit die Cachefunktion. Um das einzuschätzen kann man davon ausgehen dass eine moderne Platte sequentiell bei einem 2GB Schreibvorgang > 100 MB/s kann, bei einzelnen kleinen z.B. 8-512k Schreibaktionen dagegen auf unter 10 MB/s einbricht.

Stürzt der Rechner nun beim Schreiben ab, so ist der Inhalt des RAM-Schreibcaches verloren. Das sind bis zu 4 GB in diesem Beispiel. Für ZFS ist das kein großes Problem. Eine aktuell geschriebene Datei ist defekt, das Dateisystem bleibt valide wegen Copy on Write. Aus Sicht von ZFS ist eine VM aber eine Datei mit einem Dateisystem darauf. ZFS kann dafür nicht geradestehen und das VM Betriebssystem hat auch keine Kontrolle über den Schreibvorgang (wegen dem ZFS Cache). Da kann es passieren dass Dateiänderungen es auf Platte schaffen, nicht aber die dazugehörenden Metadaten. Das VM Dateisystem ist dann korrupt.

Um das zu verhindern (dass Schreibvorgänge die einer VM als "auf Platte" geschrieben gemeldet wurden sich im Nirwana auflösen), muss man den Inhalt des RAM Schreibcaches der es noch nicht auf die Platte geschafft hat sichern um fehlende Schreibvorgänge beim nächsten Reboot auf Platte zu schreiben.

Damit das passiert (logging) muss man sync aktivieren. Will man das Schreibprotokoll nicht auf dem langsamen Pool speichern, kann man ein Slog einsetzen das für kleine Schreibaktionen optimiert ist. Für ein Slog reichen ab ca 10 GB. Der Pool und/oder das Slog dürfen dann natürlich ihrerseits keinen Datenverlust bei Stromausfall erleiden wie es bei Desktop SSD und ihrem Ramcache der Fall ist. Das "Risiko" eines Pools/Slog mit SSD ohne PLP ist aber deutlich geringer als wenn man einen Pool ganz ohne sync betreibt. Für "produktion use" ist aber immer ein Pool und ein Slog mit plp unabdingbar. Mechanische Platten mit deaktiviertem Cache sind sicher. Das Problem sind im Zweifel Desktop SSD/NVMe ohne funktionierende powerloss protektion. Manche Hersteller werben da mit obskuren Sachen die plp suggerieren.

Es geht nicht darum, eine ganze VM beim Schreiben zu puffern sondern darum dass bestätigte Schreibvorgänge garantiert auf Platte sind. Damit werden die VM eigenen Mechanismen die ein Dateisystem valide halten nicht ausgehebelt.

@Trambahner, kleine Korrektur
Arc ist RAM Lesecache und nicht RAM Schreibcache

 

[sch4kal]

Ich würde das mal so beschreiben:

Alle einzelnen kleine und größere Schreibvorgänge in ZFS gehen immer und grundsätzlich in den RAM-Schreibcache und werden dabei z.B. an eine VM als auf Platte geschrieben gemeldet. Das geht sehr schnell da RAM auch bei kleinen Schreibvorgängen sehr schnell ist. Platten sind bei kleinen Schreibaktionen dagegen furchtbar langsam.

Hat man z.B. einen 4 GB RAM Schreibcache und der ist halb gefüllt, so wird der Inhalt als ein großer schneller sequentieller Schreibvorgang auf Platte geschrieben. Die restliche Hälfte übernimmt in dieser Zeit die Cachefunktion. Um das einzuschätzen kann man davon ausgehen dass eine moderne Platte sequentiell bei einem 2GB Schreibvorgang > 100 MB/s kann, bei einzelnen kleinen z.B. 8-512k Schreibaktionen dagegen auf unter 10 MB/s einbricht.

Stürzt der Rechner nun beim Schreiben ab, so ist der Inhalt des RAM-Schreibcaches verloren. Das sind bis zu 4 GB in diesem Beispiel. Für ZFS ist das kein großes Problem. Eine aktuell geschriebene Datei ist defekt, das Dateisystem bleibt valide wegen Copy on Write. Aus Sicht von ZFS ist eine VM aber eine Datei mit einem Dateisystem darauf. ZFS kann dafür nicht geradestehen und das VM Betriebssystem hat auch keine Kontrolle über den Schreibvorgang (wegen dem ZFS Cache). Da kann es passieren dass Dateiänderungen es auf Platte schaffen, nicht aber die dazugehörenden Metadaten. Das VM Dateisystem ist dann korrupt.

Um das zu verhindern (dass Schreibvorgänge die einer VM als "auf Platte" geschrieben gemeldet wurden sich im Nirwana auflösen), muss man den Inhalt des RAM Schreibcaches der es noch nicht auf die Platte geschafft hat sichern um fehlende Schreibvorgänge beim nächsten Reboot auf Platte zu schreiben.

Damit das passiert (logging) muss man sync aktivieren. Will man das Schreibprotokoll nicht auf dem langsamen Pool speichern, kann man ein Slog einsetzen das für kleine Schreibaktionen optimiert ist. Für ein Slog reichen ab ca 10 GB. Der Pool und/oder das Slog dürfen dann natürlich ihrerseits keinen Datenverlust bei Stromausfall erleiden wie es bei Desktop SSD und ihrem Ramcache der Fall ist. Das "Risiko" eines Pools/Slog mit SSD ohne PLP ist aber deutlich geringer als wenn man einen Pool ganz ohne sync betreibt. Für "produktion use" ist aber immer ein Pool und ein Slog mit plp unabdingbar. Mechanische Platten mit deaktiviertem Cache sind sicher. Das Problem sind im Zweifel Desktop SSD/NVMe ohne funktionierende powerloss protektion. Manche Hersteller werben da mit obskuren Sachen die plp suggerieren.

Es geht nicht darum, eine ganze VM beim Schreiben zu puffern sondern darum dass bestätigte Schreibvorgänge garantiert auf Platte sind. Damit werden die VM eigenen Mechanismen die ein Dateisystem valide halten nicht ausgehebelt.

@Trambahner, kleine Korrektur
Arc ist RAM Lesecache und nicht RAM Schreibcache

Solche hilfreichen Beiträge sollte man ganz oben anpinnen !

 

[AliManali]

Noch mal eine Frage: wie sieht es mit napp-it und TRIM aus? Ich meine mal gehört zu haben, dass es unter napp-it eh kein TRIM gibt, und mitunter auch deshalb die Server SSD besser sind? Aber wahrscheinlich habe ich das ja falsch in Erinnerung.

Es soll ja LSI-9211-8i geben, die kein TRIM unterstützen, habe ich aufgeschnappt? Wie finde ich heraus, ob mein Controller TRIM unterstützt, und kann man das in napp-it auslesen, falls es benötigt wird? Beispiel wäre mein PERC 310. Wir haben aber auch noch einen Fujitsu bestellt, da wäre es wohl wichtig, das im Vorhinein schon zu wissen, bevor wir die SSD bestellen.

 

[gea]

Napp-it ist ein Management Tool für eine Reihe von Betriebssystemen. Trim wird dabei nicht von napp-it bereitgestellt sondern von dem Betriebssystem.

Ein aktuelles OmniOS kann z.B. Trim (ist ein aktuelles Open_ZFS Feauture) und da kann man das auch per napp-it handhaben. Ein älteres Betriebssystem kann das nicht, weder mit noch ohne napp-it.

Trim im Raid auf Controller Ebene gibt es nicht. Daher ist das bei Hardware Raid auch nicht verfügbar. Auch bei ZFS Softwareraid geht das nur bei "guten" SSDs. Bei Einführung von ZFS Trim im Raid gabs gerne mal Probleme mit manchen Desktop SSDs. Zwischenzeitlich werden die Problem-SSD gut erkannt.

 

[AliManali]

Nein, ich mein ohne RAID. Weder Hardware noch Software. Einfach bei einem napp-it AiO ESXi mit einem durchgereichtem HBA im IT Mode. Muss ich da drauf achten bei einem LSI-9211-8i?

 

[gea]

Ein Controller kann kein Trim im Raid, egal ob Adaptec, LSI oder Sata/onboard.
Ein OS wie OmniOS oder Linux kann Trim auf ZFS Software-Raid, dann auf einem beliebigen Plattenkontroller.

Trim auf Einzelplatten ohne Raid kann ZFS wohl schon von Anbeginn aus Zeiten von OpenSolaris.

 

[MisterY]

Hi,
ich habe ein RaidZ1 Pool aus 3 1 TB HDDs. laut ncdu sind dort 90 GB belegt.

zfs list tank sagt:

NAME   USED  AVAIL     REFER  MOUNTPOINT
tank   912G   884G     85.8G  /tank

Aber in der Proxmox-GUI sind 912 GB von 1.75 TB belegt bzw. 1.34 TB von 2.72 TB.

An Daten sind da bestimmt so um die 912 GB drauf, aber wieso sagt "zfs list tank", dass der Pool nur 1 TB groß ist? Irgendwie bin ich verwirrt.

Wie finde ich heraus, wie viel nun wirklich belegt sind und was wie viel belegt?

 

[p4n0]

Zfs list sagt doch used und available.
Addierst du beide Werte hast du doch deine poolsize?

 

[jonofe]

Kurze Frage zur napp-it ZFS Replikation:

Ich habe einen napp-it Server, von dem 14 ZFS Filesystems einmal pro Tag repliziert werden.
Auf dem Zielserver läuft auch napp-it mit Replikations-Extension und dort sind die Replikationsjobs definiert.
Ich habe 19.00 Uhr als Startzeit für alle Replikationsjobs gewählt und erhalte damit täglich Fehlermeldungen, immer bei unterschiedlichen Jobs.

Hier ein Beispiel:

Ein nachträglicher manueller Start, lässt die Jobs dann fehlerfrei durchlaufen.
Wenn ich die Jobs hingegen in 5 minütigem Abstand starte, d.h. 19:00, 19:05, 19:10, usw., dann läuft die gesamte Replikation fehlerfrei.

Ist das normal? Laufen die Jobs aufgrund der Vielzahl in ein Timeout? Kann man die Jobs auch voneinander abhängig definieren, d.h. Job 2 startet wenn Job 1 fertig ist?

Danke im Voraus für eure Hilfe.

 

[Gen8 Runner]

Wie finde ich heraus, wie viel nun wirklich belegt sind und was wie viel belegt?

Moin,
erstmal folgendes ausführen, um auch anzuzeigen, wieviel Snapshots an Speicherplatz einnehmen:

zpool set listsnapshots=on rpool

Anschließend:

zfs list -o space -r rpool

Snapshots nutzen eben teilweise auch einige (oder viele) GB/TB, bis auch diese endgültig gelöscht werden.

 

[gea]

Kurze Frage zur napp-it ZFS Replikation:

Ich habe einen napp-it Server, von dem 14 ZFS Filesystems einmal pro Tag repliziert werden.
Auf dem Zielserver läuft auch napp-it mit Replikations-Extension und dort sind die Replikationsjobs definiert.
Ich habe 19.00 Uhr als Startzeit für alle Replikationsjobs gewählt und erhalte damit täglich Fehlermeldungen, immer bei unterschiedlichen Jobs.

Hier ein Beispiel:

Anhang anzeigen 533123

Ein nachträglicher manueller Start, lässt die Jobs dann fehlerfrei durchlaufen.
Wenn ich die Jobs hingegen in 5 minütigem Abstand starte, d.h. 19:00, 19:05, 19:10, usw., dann läuft die gesamte Replikation fehlerfrei.

Ist das normal? Laufen die Jobs aufgrund der Vielzahl in ein Timeout? Kann man die Jobs auch voneinander abhängig definieren, d.h. Job 2 startet wenn Job 1 fertig ist?

Danke im Voraus für eure Hilfe.

Wenn die Jobs bei zeitlichem Versatz laufen, ist es wohl ein Resourcenproblem z.B. bei wenig RAM. ZFS nutzt den überwiegenden Teil des RAM als Schreib/Lesecache. Benötigt ein anderes Programm RAM wird der freigegeben. Das kann aber etwas dauern. Ein hoher plötzlicher Bedarf kann da zu einem Problem werden.

In Zusammenhang mit minIO (benötigt nochmal deutlich mehr Resourcen als ein zfs send/receive), dem Amazon S3 Service ist mir bei gleichzeitigem Start mehrerer Sessions aufgefallen, dass auch der Start der Dienste mit "at now" im Hintergrund Probleme bereiten kann. Stehen zuwenig Resourcen bereit, landen die Dienste in der at queue und werden erst mit Verzögerung gestartet - zu spät für eine wartende Replikation. In napp-it 20.dev habe ich daher den Startmechanismus für Hintergrund Dienste/Jobs geändert.

Wenn man in der Jobübersicht bei "Replicate" oder der letzten Ausführung (Klick auf Datum) nachschaut und als Fehlermeldung des zfs receive ein "failed to read from stream" steht wäre das ein Indiz für diese Problematik.

Ich würde daher bei einem älteren napp-it empfehlen, die Jobs mit etwas Versatz zu starten oder alternativ schauen ob sich das Verhalten bei einem aktuellen napp-it 20.dev ändert.

 

[jonofe]

Wenn man in der Jobübersicht bei "Replicate" oder der letzten Ausführung (Klick auf Datum) nachschaut und als Fehlermeldung des zfs receive ein "failed to read from stream" steht wäre das ein Indiz für diese Problematik.

Ja, genau diese Fehlermeldung ist es.

schauen ob sich das Verhalten bei einem aktuellen napp-it 20.dev ändert.

Es ist die Version 20.06a1 Pro. Ist die 20.dev aktueller?
Falls ja, dann ändere ich mal alle Replications Jobs auf die gleiche Startzeit und mache ein Update auf 20.dev.
Wenn das weiterhin schief läuft versuche ich mal den Versatz kleiner zu machen (1 Minute) oder sollte der Versatz dann so groß sein, dass der vorherige Job beendet ist bevor der nächste startet?

Das ganze läuft übrigens auf ESXi (Xeon 1230v3, 24GB), davon 16GB für napp-it. Und napp-it ist ausschließlich Replikationsziel (keine SMB/NFS Shares, keine ESXi Datastores)

Noch einige ergänzende Fragen:

1. Kann ich irgendwie mehrere Replication Jobs gleichzeitig im Webinterface starten? Oder gibt es einen cli Befehl dafür?
2. Gleiche Frage für gleichzeitig ändern, z.B. alle Jobs auf 19.00 Uhr Startzeit stellen?
3. Kann ich irgendwie eine automatisierbare Rückmeldung bekommen, wann ein Replikationsjob beendet wurde? Ich möchte damit einen automatischen Shutdown nach Beenden aller Replikationsjobs machen.

 

[gea]

napp-it 20.dev ist neuer.
(Pre Version für 21.01 )

Man kann mehrere Jobs gleichzeitig starten oder Parameter ändern indem man mit "Switch" links oberhalb der Jobliste die Jobs selektiert. Wenn man das nur auf Replikationsjobs einschränken will, zuerst Jobs > Replikation wählen

3.
Man könnte einen "Other Job" definieren, den man nach den Replikationen startet und der per "ps axw | grep zfs receive" prüft ob noch Replikationen laufen um andernfalls ein Shutdown auszulösen.

Regelmäßige inkrementelle Replikationen laufen aber nur relativ kurz. Man kann daher ohne viele Probleme zu erwarten einfach nach 30 Minuten per other Job herunterfahren. Sollte man lange Replikationen planen, den Job auf "manual" stellen. Wird doch einmal eine Replikation unterbrochen, so wird die beim nächsten Lauf einfach nachgeholt.

 

[jonofe]

@gea : Danke für den Denkanstoß, habe es jetzt wie folgt gelöst:

Per ipmitool wird um 17:30 Uhr der ESXi Server automatisch eingeschaltet.

Ab 17.45 starten minütlich die Replikationsjobs.

Mit einem "Other Job", der um 18 Uhr minütlich (bis max 18:59) startet wird der Server bei Beendigung aller Repliaktionsjobs heruntergefahren:

ps auxww | grep job_replicate.pl | grep -vq grep || ssh root@esxi-backup.feld.home poweroff -d 60

 

[Elektromat]

Servus Zusammen,

hatte heute versucht aus einem Solaris Snapshot per Windows Dateiversionsverlauf Dateien einer meiner VMs herzustellen.
Hab mir hierzu den Snap Ordner im Windows geöffnet, und bekomme die folgende Meldung beim Kopieren einzelner Dateien.

Der Hauptteil der Dateien hat sich normal und ohne Fehler kopieren lassen.

Zufällig jemand ne Idee ob es hier eine Möglichkeit gibt die Berechtigung zu erhalten? Es hängt nur an zwei Dateien.
Bzw. warum erscheint die Meldung zur Anonymous berechtigung, wenn der Share mit meinem Benutzer eingehängt ist? Und vor allem nur bei zwei von vielen Dateien.
Die betroffene VM ist voll lauffähig, Benötige nur einen alten Stand.
Es macht auch keinen unterschied ob Ich aus dem Snap auf einen Share kopiere oder auf meine Windows Maschine.
Andere VMs kann ich Problemlos und ohne Berechtigungs Fehlermeldung aus meinen Snaps kopieren.

Danke und Grüße
Elektromat

 

[gea]

Gibt eigentlich nur zwei Möglichkeiten.

1. Die Zieldatei die überschrieben werden soll ist geöffnet,
z.B. weil die zugehörige VM noch läuft.

-> VM Offline stellen

2. Man hat keine Rechte auf die Datei die gelesen oder überschrieben werden soll.

- > Als root kopieren oder den VM Ordner rekursiv auf everyone@=modify stellen
(per napp-it oder Windows als root).

Wenn man keine Rechte auf die Dateien im readonly Snap hat (z.B. weil die ESXi unter einem anderen user account angelegt hat) muss man als root kopieren und kann dann die Rechte nach dem Kopieren setzen/prüfen.

 

[Elektromat]

- > Als root kopieren oder den VM Ordner rekursiv auf everyone@=modify stellen
(per napp-it oder Windows als root).

Wenn man keine Rechte auf die Dateien im readonly Snap hat (z.B. weil die ESXi unter einem anderen user account angelegt hat) muss man als root kopieren und kann dann die Rechte nach dem Kopieren setzen/prüfen.

Mit root ist der Solaris root gemeint oder? Den sehe ich allerdings unter den SMB usern im Solaris nicht.
Das Netzlaufwerk konnte ich im Windows nicht als Solaris root einhängen.

Das setzen auf everyone@=modify hat für den eigentlichen VMShare funktioniert. Die VM Dateien kann ich nun hier normal ohne Probleme in der Berechtigung kopieren. Folgend erstellte Snaps werden damit korrekte Berechtigungen aufweisen.

Die alt bestehenden Snaps machen Berechtigungs Probleme es fehlt hier Lesen as Berechtigung in einzelnen Dateien.

Die Dateien im selben Verzeichnis die sich korrekt kopieren lassen haben bei Jeder die Berechtigung Lesen und Schreiben.


Ein Kopieren per SSH root Login auf solaris mit dem cp -r Befehl aus ../.zfs/snapshot/<SNAPname>/.... hat erwartungsgemäß problemlos funktioniert.

 

[gea]

user root per SMB:
Da der SMB Server installiert ist, erzeugt ein erneutes Setzen eines Passworts per "passwd root" neben dem Unix Passwort auch ein Windows Passwort (in /var/smb). Anschließend kann man sich als root per SMB anmelden und kann, da man volle Dateirechte hat auch alles kopieren oder alle ACL ändern.

Auf der Konsole kann man auch midnight commander nutzen um komfortabel Daten zu kopieren oder Dateien zu editieren.

Manche SMB Admin Funktionen unter Windows Computer Management wie das Anzeigen der Share Rechte, der angemeldeten User und der offenen Dateien erfordern zusätzlich, dass der angemeldete SMB User in der lokalen Solaris Windows SMB Gruppe Administratoren ist (lokale Unix + SMB Gruppen, eine Solaris Besonderheit für bessere Windows Kompatibilität)

 

[Elektromat]

user root per SMB:
Da der SMB Server installiert ist, erzeugt ein erneutes Setzen eines Passworts per "passwd root" neben dem Unix Passwort auch ein Windows Passwort (in /var/smb). Anschließend kann man sich als root per SMB anmelden und kann, da man volle Dateirechte hat auch alles kopieren oder alle ACL ändern.

Auf der Konsole kann man auch midnight commander nutzen um komfortabel Daten zu kopieren oder Dateien zu editieren.

Manche SMB Admin Funktionen unter Windows Computer Management wie das Anzeigen der Share Rechte, der angemeldeten User und der offenen Dateien erfordern zusätzlich, dass der angemeldete SMB User in der lokalen Solaris Windows SMB Gruppe Administratoren ist (lokale Unix + SMB Gruppen, eine Solaris Besonderheit für bessere Windows Kompatibilität)

Bzgl. dem root pwd werd ich bei Gelegenheit mal schauen. Wobei der mc absolut ausreichend ist, wenn man nur gelegentlich Daten aus Snaps herstellen muss.

Der midnight commander erinnert mich ein wenig. an die guten alten DOS Zeiten (Norton Commander) .
Da hatte ich nicht dran gedacht. Super Tipp.

 

[gea]

Midnight Commander ist ein Klon des Norton Commanders,

Norton Commander – Wikipedia

de.wikipedia.org

Für eine Linux/Unix Minimalinstallation ohne grafische Oberfläche für mich immer das erste Tool das ich installiere.

 

[kandamir]

Kurze Frage:
Habe für meine bis dato unverschlüsselten Dateisysteme eine verschlüsselte Kopie angelegt (Snapshots per zfs send|recv an verschlüsseltes Filesystem gesendet). Aktuell habe ich also pro Filesystem eine unverschlüsselte und eine verschlüsselte Version, z.B. /Data/Filesystem und /Data/Filesystem_enc, beide sind auf dem gleichen Stand. Nun möchte ich natürlich, dass die unverschlüsselten Filesysteme nicht mehr verwendet werden. Reicht es, die Filessysteme umzubenennen, damit SMB und NFS Freigaben auf die verschlüsselte Version zugreifen?
Danke und Gruß Kandamir

 

[gea]

Prinzipiell ja (wenn Dateisystemname = Mountpoint).
Bei SAMBA (das nichts von ZFS weiß) reicht das alleine.

Bei Solarish und dem kernel/ZFS basierten SMB Server wo ein SMB/NFS Share eine reine ZFS Eigenschaft ist, muss man darauf achten dass im umbenannten enc Filesystem NFS + SMB Sharing aktiviert wird und dass nicht das alte und das neue Dateisystem das SMB Share unter gleichem Namen bereitstellen will.