[Sammelthread] ZFS Stammtisch

Danke für die Erklärung. Da habe ich die Bedeutung des taskserver.sh Prozesses für napp-it wohl etwas überschätzt und das liegt sicherlich daran, daß ich perl nicht wirklich kenne.
Wenn ich mir das bash-Script "taskserver.sh" allerdings anschaue, wird neben den erwähnten *.sh Shellscripts, die, sofern sie existieren, im Hintergrund durch die Shell abgearbeitet werden, auch *.request Dateien abgefragt und an taskexec.pl weitergereicht. Ich hatte angenommen, daß darüber etwas (also ein request) vom GUI bzw. den automatischen Jobs kommt und entsprechend verarbeitet wird. Aber da lag ich wohl falsch ...

Trotzdem kurz meine Gedanken zum taskserver.sh: Unter linux würde ich das im Script verwendete polling - regelmäßiges überprüfen der Verzeichnisse auf Dateien mit nachfolgendem sleep 1 - ersetzen durch inotifywait. Damit kann man Dateien oder Verzeichnisse (auch ganze Verzeichnisbäume rekursiv) auf Änderungen überwachen. Zwar gibt es inotifywait unter OmniOS bzw. Solaris nicht direkt, aber die Solaris File Event Notification macht offenbar das gleiche. Beschrieben wird das hier und ich habe das dortige C-Program auch schon unter OmniOS kompiliert und kurz getestet. Es war nur eine Zeile im Source Code zu ändern, nämlich
C:
#include <ctype.h>
bei den #include Zeilen im Source Code hinzuzufügen. Danach "make" und eine ausführbare Datei entsteht.

Nach dem Starten erkennt diese problemlos, sobald im überwachten Verzeichnis eine Änderung passiert - also beispielsweise eine Datei angelegt wird - und terminiert. In einem Shell Script könnte genau dann eben die neue angelegte Datei wie bisher behandelt werden und die Überwachung des Verzeichnisses wieder gestartet werden. Klarerweise müßte man sich allfällige corner-cases noch überlegen und auch abwägen, ob eine Änderung Sinn macht ode nicht - effizienter sollte es jedenfalls werden, weil die loop: "prüfe Verzeichnis / sleep 1" nicht andauernd durchlaufen würde, sondern eine Prüfung auf auszuführende Dateien nur dann erfolgte, sobald es tatsächlich etwas zum Abarbeiten gibt.

Schließlich denke ich, daß auch eine weitere Änderung in taskserver.sh möglich sein sollte. Sofern ich das bash-Script richtig verstanden habe, sollte der bisherige Codeteil
Bash:
  # check/run /var/web-gui/_log/tmp/*.sh (initiated prior reboot)
  DIR="/var/web-gui/_log/tmp/*.sh"
  for FILE in $DIR
  do
     if [ -f $FILE ]
     then
       sh $FILE &
       echo "sh $FILE &"
       # next sleep required
       sleep 1
       cat $FILE && rm  $FILE
       echo ''
       # echo "$FILE" >> /var/web-gui/_log/remote.log # debug, ps for interactive test at console
       ps axw | grep repli-send | grep -v grep

     fi
  done
eigentlich problemlos durch
Bash:
  # check/run /var/web-gui/_log/tmp/*.sh (initiated prior reboot)
  DIR="/var/web-gui/_log/tmp/*.sh"
  for FILE in $DIR
  do
     if [ -f $FILE ]
     then
       sh < "$FILE" &
       echo "sh $FILE &"
       cat $FILE && rm  $FILE
       echo ''
       # echo "$FILE" >> /var/web-gui/_log/remote.log # debug, ps for interactive test at console
       ps axw | grep repli-send | grep -v grep
     fi
  done
ersetzt werden können.

Ich bin davon ausgegangen, daß das "sleep 1" mit dem Kommentar "next sleep required" vor den beiden Befehlen "cat && rm" nur sicherstellen soll, daß die Datei "$FILE" nicht gelöscht worden ist, bevor die Abarbeitung durch die shell gestartet wurde, weil ja nicht sichergestellt ist, daß der Befehl "sh $FILE &" tatsächlich ausgeführt wird, bevor die Datei nachfolgend gelöscht wird. Abgesehen davon, daß dies auch durch "sleep 1" nicht garantiert wird, gibt es dafür nach meiner Ansicht einen bessere Möglichkeit: Input redirection. Eine Datei, die von einem Prozeß geöffnet ist (garantiert durch die input redirection) wird durch rm zwar aus dem Verzeichnis entfernt und ist damit für andere Prozesse nicht mehr erreichbar, der Inhalt der Datei steht aber allen Prozessen, welche die Datei noch offen haben - und damit insbesondere der shell, welche das Script ja von standard input liest, bis zu deren Beendigung zur Verfügung. Damit kann das Löschen sofort nach dem Befehl sh < "$FILE" erfolgen, weil dann die Input redirection bereits passiert ist und die Datei geöffnet ist.

Das sind einmal so meine Gedanken - @gea bitte um Feedback, ob das nachvollziehbar ist und sinnvoll wäre oder nicht. Atom2
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Tasksever als Hintergrundprozess liest fortwährend das überwachte Verzeichnis mit einem sleep 1 nach jedem Lesen. Sleep ist damit der Normalfall. Das Sleep soll auch dafür sorgen dass mehrere Scripte mit einer kurzen Verzögerung gestartet werden, z.B. Massenstart Dutzender Replikationen. Echo und ps dienen nur dazu das Script zu testen wenn es als normaler Prozess im Vordergrund läuft.

Prinzipiell werden alle Prozesse vom Taskserver als Hintergrundprozess gestartet. Die Shell hat die Script Datei daher nur ganz kurz offen bis das gestartet ist. cat $FILE && rm $FILE soll dafür sorgen dass ein Script das noch nicht vollständig bearbeitet wurde nicht gelöscht wird. Das ist mir passiert als ich nur rm ohne vorheriges erfolgreiches cat aufgerufen habe. Die .request werden auch im Hintergrund ausgeführt und bearbeiten ein start/stop/delete request in der Job Übersicht.

Ich vermute mal das ein eigenes Programm das einen Ordner überwacht nicht resourcenschonender ist als eine direkte Überwachung zumal das weder besonders zeitkritisch ist oder ein Locking erfordert - so wie manche andere Scripte die dann das Lesen/ Schreiben über Perl realisieren weil das sehr gute Lockingmöglichkeiten für Textdateien bietet.

Wäre es zeitkritischer, wäre inotifywait eine gute Option (werde ich mir merken). sh < file wäre auch denkbar mit sleep für eine kurze Verzögerung bei vielen gleichzéitigen Anforderungen. Wie gesagt ist Taskserver aber ziemlich unkritisch, tut so seit Jahren und vor allem unter allen Plattformen inkl. Linux. Da ist es ganz praktisch wenn kein spezifisches Binary benötigt wird.

Vielleicht könntest du inotifywait anhängen, ist eventuell für mich oder andere interessant.
 
Zuletzt bearbeitet:
Hallo @gea,
ich erstelle gerade auf die Schnelle ein kleines bash-Script wo ich anstelle von inotifywait die etwas weniger mächtigen Version "fswatch" von Solaris verwende (ist übrigens über pkgin zu kriegen - nochmals danke für den Tip einige Beiträge weiter oben). Ich nehme an, das ist das, was Du mit "anhängen" meintest? Dort sieht man dann recht gut, wie das funktionieren könnte.
Dabei bin ich aber noch auf eine kleine Frage gestoßen und bin mir nicht sicher, ob das, was im Bash-Script taskserver.sh aktuell steht, auch das ist, was Du tatsächlich haben willst. Es geht um die beiden Zeilen
Bash:
         /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F 2>&1> /dev/null  &
       
         /usr/bin/perl /var/web-gui/data/scripts/agents/agent_autolock.pl 2>&1> /dev/null  &
und dort insbesondere um die Ausgabeumleitung. Was Du dort machst, ist eine Umleitung von stderr (fd 2) auf stdout (fd 1) und danach eine Umleitung von stdout auf /dev/null. Mit anderen Worten wird hier im Ergebnis tatsächlich nur stdout auf /dev/null umgeleitet und stderr (fd 2) wird dorthin umgeleitet, wo stdout (fd 1) vor der Umleitung ausgegeben hat. Nachdem ohne Ausgabeumleitung sowohl stdout wie auch stderr standardmäßig beide auf das gleiche "File" (idR Terminal) ausgeben, ist diese Form der Umleitung bis auf wenige Sonderfälle, die aber regelmäßig eine synchrone Abarbeitung und keinen Backgroundprocess erfordern - wie beispielsweise eine Variablenzuweisung der Form
Bash:
variable=$(cmd 2>&1 >/dev/null)
wenn man nur die Ausgabe von stderr als Wert von variable erhalten möchte - in aller Regel nicht zielführend.

Bei einer Umleitung ist nämlich die Reihenfolge relevant und Umleitungen werden von der bash links nach rechts abgearbeitet. Wenn Dein Ziel daher ist, stdout und stderr auf /dev/null umzuleiten und im Ergebnis damit sowohl die normale Programmausgaben wie auch allfällige Fehlerausgaben zu eliminieren, müßten die Kommandos daher wie folgt lauten:
Bash:
/usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F >/dev/null 2>&1 &

/usr/bin/perl /var/web-gui/data/scripts/agents/agent_autolock.pl >/dev/null 2>&1 &

Bitte um kurze Aufklärung, Atom2
 
Zuletzt bearbeitet:
In der Tat, beabsichtigt war, alles auf /dev/null umzuleiten
Danke für den Hinweis
 
Ich habe jetzt mal ein kleines bash-Script erstellt, das fswatch verwendet und die Funktion des tasksever.sh Prozesses nachbauen sollte. Das ganze schaut wie folgt aus:
Bash:
#!/usr/bin/bash

# define constants for later reuse
declare -r REQUESTDIR="/tmp/nappit"
declare -r SCRIPTDIR="/var/web-gui/_log/tmp"
declare -r TASKEXEC="/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl"
declare -r AUTOLOCK="/var/web-gui/_log/tmp/autolock.request"
declare -r AGENTLCK="/var/web-gui/data/scripts/agents/agent_autolock.pl"
declare -r BOOTINIT="/var/web-gui/data/napp-it/zfsos/_lib/scripts/agents/agent-bootinit.pl"

# init once at boot time
echo "$BOOTINIT"
/usr/bin/perl "$BOOTINIT" &
# del /var/web-gui/_log/tmp/*.sh (initiated prior reboot)
/usr/bin/rm -f "$SCRIPTDIR"/*.sh 2>/dev/null

while true; do
        while read -r changed; do
                case "$changed" in
                        "$REQUESTDIR")
                                # task requests via file /tmp/nappit/agent-xx_id.request -> ../script/agent-xx.pl
                                for file in "$REQUESTDIR"/*.request; do
                                        # start task
                                        [[ -f "$file" ]] && /usr/bin/perl "$TASKEXEC" "$file" >/dev/null 2>&1 &
                                done
                                if [[ -f "$AUTOLOCK" ]]; then
                                        # start
                                        /usr/bin/rm -f "$AUTOLOCK"
                                        /usr/bin/perl "$AGENTLCK" >/dev/null 2>&1 &
                                fi
                                ;;
                        "$SCRIPTDIR")
                                # check/run /var/web-gui/_log/tmp/*.sh (initiated prior reboot)
                                for file in "$SCRIPTDIR"/*.sh; do
                                        [[ -f "$file" ]] && /usr/bin/bash < "$file" & /usr/bin/rm -f "$file"
                                        [[ -t 0 ]] && /usr/bin/ps axw | /usr/bin/grep '[r]epli-send'
                                done
                                ;;
                esac
        done < <(/opt/local/bin/fswatch --event Updated --event AttributeModified --recursive "$REQUESTDIR" "$SCRIPTDIR")
done
Beitrag automatisch zusammengeführt:

Einige kurze Erklärungen zum Script von voher (leider wollte das Forum das nicht in einem Posting, daher ein zweites Nachfolgeposting):
  1. Ich versuche immer, externe Prozesse in einem bash-Script möglichst zu vermeiden, weil diese über fork/exec gestartert werden müssen und daher grundsätzlich mehr Ressourcen benötigen, als wenn man etwas direkt im Shell Script mit den Mitteln der Shell macht. Das betrifft beispielsweise auch sleep Prozesse; diese machen zwar nichts wenn sie gestartet sind, für deren Starten ist aber trotzdem jedesmal die Systemcall Kombination fork/exec erforderlich, und diese ist - wie man das im Englischen so schön sagt - grundsätzlich "expensive".
  2. fswatch ist zwar etwas weniger mächtig als inotifywait, aber im Betrieb über die im Solaris kernel implementierte Solaris File Event Notification sehr effizient. Durch die Verwendung von fswatch - über pkgin installierbar - wird event-gesteuert erst dann etwas gemacht, wenn sich in den überwachten Verzeichnissen etwas getan hat; ansonsten wartet das Script auf eine Ausgabe von fswatch - und das ist sehr effizient. Die möglichen Ausgaben werden auch noch eingeschränkt auf die events "Update" und "AttributeModified", welche insbesondere beim Anlegen von oder Verschieben von Dateien in die überwachten Verzeichnisse entstehen. Leider ist bei fswatch trotzdem noch ein Test, ob eine Datei vorhanden ist, erforderlich; dieses wäre bei inotifywait unter linux wohl nicht notwendig - das wäre aber noch genauer zu prüfen.
  3. Der Aufruf von Shell-Scripts (z.B. "script.sh") in /var/web-gui/_log/tmp erfolgt nicht durch Übergabe des Dateinamens als argv[1] an das bash-Kommando, sondern als input-redirection mit der Datei als stdin. Das hat den Vorteil, daß die Datei "script.sh" unmittelbar danach bereits gelöscht werden kann. Dies geht deswegen, weil die Datei durch die Eingabeumleitung zu /usr/bin/bash vom bash-Prozeß geöffnet ist und damit für diesen Prozeß während seiner Lebensdauer über stdin zur Verfügung steht, auch wen der Verzeichniseintrag durch rm gelöscht worden ist. Mit anderen Worten ist bei Eingabeumleitung auch kein "sleep n" erforderlich der versucht, sicherzustellen, daß die Datei von der bash bei Aufruf mit "/usr/bin/bash script.sh &" bereits verwendet worden ist. Im übrigen hätten wir da ohnedies eine race-condition, weil auch ein "sleep n" nicht sicherstellen kann, daß der bash-Prozeß bereits läuft (und die als Argument übergebene Datei schon geöffnet hat), wenn die Zeitdauer "n" des sleep abgelaufen ist.
  4. Ein ähnliches Problem sehe ich grundsätzlich auch beim Aufruf von "/usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl" mit einem File als Argument. Zwar wird die Datei da nicht von der bash gelöscht (sondern soweit ich das verstanden habe vom Perl Scipt taskexec.pl selbst) und damit haben wir das Problem eines möglicherweise zu frühen Löschens nicht, aber allenfalls jenes eines zu späten Löschens: Wenn bei einem weiteren Durchlauf und der Prüfung, ob Dateien im Verzeichnis vorhanden sind, die zuletzt übergebene Datei weiterhin existiert, wird der Prozeß ein zweites Mal mit der selben Datei als Argument gestartet - und auch hier kann ein sleep nicht sicherstellen, daß selbiges ausgeschlossen ist. Ob das im Perl Script behandelt wird oder nicht, kann ich mangels Kenntnis von Perl nicht sagen. Auch hier wäre die einfachste und sicherste Lösung, eine Eingabeumleitung derart zu machen, daß das Perl Script den Inhalt der ansonsten als Argument übergebenen Datei von stdin liest und abarbeitet; dann könnte sofort nach dem Starten des Prozesses ein Löschen der Datei durch das bash-Script erfolgen und ein zweiter Start im nächsten Durchlauf wäre ausgeschlossen. Das habe ich aber mangels Kenntnis des Perl-scripts taskexec.pl nicht gemacht.
  5. Das offenbar nur als Test des Script vorhandene ps-Kommando (siehe Kommentar von @gea weiter oben) startet mein Script nur dann, wen stdin (fd 0) ein Terminal ist - ansonsten wird es ignoriert. Ich hatte verstanden, das das ja auch die Intention war.
  6. Eine weitere Optimierung gibt es noch beim ps Kommando: Anstelle der beiden grep-Kommandos im Originalscript ("ps axw | grep repli-send | grep -v grep"), wobei das zweite grep nur das erste grep aus der Auflistung ausfiltern soll, habe ich "/usr/bin/ps axw | /usr/bin/grep '[r]epli-send' verwendet und damit eine RE für grep einegsetzt. Diese wird von grep dann intern ohnedies zu "repli-send" verändert, der grep Prozeß selbst scheint in der Task-Liste aber als "grep [r]epli-send" auf und wird daher vom intern verwendeten pattern "repli-send" nicht gematcht. Daher kann man sich das zweite Filter-grep so sparen.
  7. Eingepackt ist das ganze in eine "while true; do" loop für den eigentlich nicht eintreteten sollenden Fall, daß fswatch unvorhergesehen terminiert ...
  8. Am Anfang habe ich Konstanten definiert, die ich nachstehend verwende - das bevorzuge ich persönlich so, aber da hat wohl jeder seine eigen Vorstellung ...
Die Datei ist zwar noch nicht mit napp-it getestet, aber grundsätzlich sollte das funktionieren. Ich nehme an, @gea wird, falls Interesse an einer Übernahme besteht, ja test-Scripts haben, die ich mir erst einfallen lassen müßte. Und wenn kein Interesse besteht, dient das hoffentlich zumindest zur Information, was man event-gesteuert anstelle von in einer "sleep"-Loop machen kann und bringt den einen oder anderen Input oder eine Idee. Bei Fragen bitte einfach fragen ...


Beste Grüße, Atom2
 
Zuletzt bearbeitet:
Vielen Dank für die Anregungen für zeitoptimierte, eventgesteuerte Bash Abläufe. Damit habe ich mich bisher nur am Rande beschäftigt und nehme es gerne als Anregung.

Übernehmen werde ich wohl nur sh < "$FILE" & als kleine Optimierung da sonst das Binary fswatch benötigt würde das nicht per default vorhanden ist und das ich dann mitliefern und auf allen aktuellen (und eventuell früheren) Systemen testen müßte. Napp-it soll ja auch in einer neuerer Version ohne Anpassung oder Abhängigkeit auf aktuellen und früheren Illumos Plattformen, Solaris und in einer auf Perl, zfs und zpool Funktionen reduzierten Variante auf diversen Linuxen nach einer einfachen Kopieraktion laufen.

Bisher liefere ich mit napp-it bereits ein spezielles Binary mit damit es "Copy and Run auch nach Update/Downgrade" ist. Das ist tty.io, für Perl Expect das ich für interaktive Befehle wie passwd benötige und das ist sehr pflegeintensiv. Ich möchte mitgelieferte binaries daher soweit möglich vermeiden und napp-it auf minimales Bash und Perl begrenzen. Für zeitkritische oder Multiprozess Script Aktionen auf Textdateien nutze ich ansonst Perl Filelocking. Damit lassen sich race conditions auch vermeiden.
 
Zuletzt bearbeitet:
Ich bin kein Programmierer/Skripter, aber mit fswatch könnte ich dann Verzeichnisse/Filesysteme von meinem Filer (Solaris 11 mit napp-it) auf Änderung überwachen und dann die für mich interessanten Aufgaben auslösen ?

- Snapshot des Datasets
- login per ssh auf meinen duplicati lxc von meinem pve und den entsprechenden Backuptask starten

Mag bei entsprechend vielen/schnellen Änderungen zu einem Chaos führen aber für mich daheim, privat ? So wären die neuen Daten ad hoc gesichert und nicht erst nach dem eigentlichen Zeitplan - wie es jetzt der Fall ist.

Grus Lucky
 
Könnte funktionieren,

Software Installation mit pkgin


Manuals
 
Zuletzt bearbeitet:
Hallo zusammen,

Bevor ich was Versemmel, kann sich das nochmal einer anschauen, ich kann die alte platte auch wieder einbauen das wäre kein thema.


Danke
Viele Grüße
 
ganz kurz: das Kommando
zpool replace QNAPZFS2 raidz1-0 ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N4JC7Z2D
ist falsch.
Richtig wäre:
zpool replace <pool> <old-device> [new-device]
wenn ichs richtig lese in deinem Fall:

zpool replace QNAPZFS2 13419636845726771512 ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N4JC7Z2D

Erstmal nicht mit -f rumfuhrwerken und nicht ne defekte Platte wieder einbauen. Thema ASHIFT kannst ebenfalls vergessen.
 
nochmal zum Thema fswatch
Ich habe mir das mal näher angesehen. Ist ein interessantes Tool zum Überwachen von Aktivitäten
Da in pkgin nicht die neueste Version ist, habe ich die kompliert.

Imstallation

Code:
cd /
wget http://www.napp-it.org/doc/downloads/fswatchbinaries_1.17.1.tar.gz
tar -zxvf fswatchbinaries_1.17.1.tar.gz

Anschließend hat man /usr/local/bin/fswatch

Starten z.B. via
/usr/local/bin/fswatch -t -m fen_monitor --numeric --recursive /pool/dateisystem (optional danach /ordner)

Hinweis:
Der überwachte Ordner sollte nicht zu groß sein.
Es dauert bei größeren Ordnern bis Aktivitäten gelistet werden und braucht ordentlich RAM

Aktivitäten:
The numeric value of all the event flags is the following:
• NoOp: 0
• PlatformSpecific: 1
• Created: 2
• Updated: 4
• Removed: 8
• Renamed: 16
• OwnerModified: 32
• AttributeModified: 64
• MovedFrom: 128
• MovedTo: 256
• IsFile: 512
• IsDir: 1024
• IsSymLink: 2048
• Link: 4096
• Overflow: 8192

Ausgabe z.B.

Tue Jan 10 18:38:24 2023 /daten1/guenther/test/numeric.txt 68
Tue Jan 10 18:39:41 2023 /daten1/guenther/test/numeric.txt 8
Tue Jan 10 18:39:41 2023 /daten1/guenther/test 68

(68=64+4)
 
Zuletzt bearbeitet:
Zu Beginn noch eine kurze Bemerkung zum Thema fswatch: Ich würde dort nicht jedes Event melden lassen, sondern die interessierenden Events bereits beim Aufruf mit angeben (ähnlich, wie ich oben in meinem Script angegeben habe, daß ich nur an Update und AttributeModified interessiert bin). Allenfalls ist dort vorab aber etwas experimentieren erforderlich.

Nun zur eigentlichen Frage: Ich hatte jetzt seit einer knappen Woche die Replikation meiner Datasets auf das Backup-System mit Ein- und Ausschalten problemlos am Laufen. Seit zwei Tagen allerdings läuft die Replikation pro Dataset in ein Timeout (ca. 15 Minuten pro Dataset) und in der Log-Datie "<repl-job-ID>.last" im Verzeichnis /var/web-gui/_log/jobs findet sich (bei Start mit der debug-Option) dann unter anderem auch ein Eintrag, der wie folgt lautet:
Code:
2023.01.10.21.50.20     &my_log_last line 309<br> <- &my_monitor line 1202<br> <- &my_remote_delta_replication line 456<br> <- &my_run line 166     Monitor: Remote proc:<br>remote nc and zfs send not running or finished, wait for postprocessing
Ein Start der Replikation direkt über die shell auf dem Target-System hat dann auch ergeben, daß auf dem Source System zwar der Snapshot erstellt wird, aber "zfs send ... | nc ..." wird nicht gestartet. An was könnte das liegen bzw. wie sollte das eigentlich technisch gestartet werden? Irgendwie muß da ja eine Kommunikation vom Target-System zum Source System stattfinden, um letzterem mitzuteilen, daß es die Änderungen senden soll - und da scheint es irgendwie Brösel zu geben. ssh scheint es wohl nicht zu sein ...

Ich habe übrigens aktuell keinen Web-Zugriff auf das GUI, sondern nur einen ssh-Zugriff auf beide Systeme. In welchen Dateien finde ich die für die Fehlersuche erforderlichen Informationen?
 
Nun zur eigentlichen Frage: Ich hatte jetzt seit einer knappen Woche die Replikation meiner Datasets auf das Backup-System mit Ein- und Ausschalten problemlos am Laufen. Seit zwei Tagen allerdings läuft die Replikation pro Dataset in ein Timeout (ca. 15 Minuten pro Dataset) und in der Log-Datie "<repl-job-ID>.last" im Verzeichnis /var/web-gui/_log/jobs findet sich (bei Start mit der debug-Option) dann unter anderem auch ein Eintrag, der wie folgt lautet:
Code:
2023.01.10.21.50.20     &my_log_last line 309<br> <- &my_monitor line 1202<br> <- &my_remote_delta_replication line 456<br> <- &my_run line 166     Monitor: Remote proc:<br>remote nc and zfs send not running or finished, wait for postprocessing
Ein Start der Replikation direkt über die shell auf dem Target-System hat dann auch ergeben, daß auf dem Source System zwar der Snapshot erstellt wird, aber "zfs send ... | nc ..." wird nicht gestartet. An was könnte das liegen bzw. wie sollte das eigentlich technisch gestartet werden? Irgendwie muß da ja eine Kommunikation vom Target-System zum Source System stattfinden, um letzterem mitzuteilen, daß es die Änderungen senden soll - und da scheint es irgendwie Brösel zu geben. ssh scheint es wohl nicht zu sein ...

Ich habe übrigens aktuell keinen Web-Zugriff auf das GUI, sondern nur einen ssh-Zugriff auf beide Systeme. In welchen Dateien finde ich die für die Fehlersuche erforderlichen Informationen?

Das Replikationsscript auf dem Backupserver steuert den oder die Quellserver und ruft dort jeweils das Send script mit den nötigen Parametern auf. Der Backupserver und die Quellserver müssen dazu eine "Appliance Group" bilden (Menü Extensions > Appliance Group auf dem Backupserver). Wenn der Job angelegt ist, muss also lediglich das Script auf dem Backupserver gestartet werden. Kontrollieren kann man Send Aktivitiäten auf dem Quellserver im Menü Job > Menü Remote Log (/var/web-gui/_log/remote.log)
 
Das Replikationsscript auf dem Backupserver steuert den oder die Quellserver und ruft dort jeweils das Send script mit den nötigen Parametern auf. Der Backupserver und die Quellserver müssen dazu eine "Appliance Group" bilden (Menü Extensions > Appliance Group auf dem Backupserver). Wenn der Job angelegt ist, muss also lediglich das Script auf dem Backupserver gestartet werden. Kontrollieren kann man Send Aktivitiäten auf dem Quellserver im Menü Job > Menü Remote Log (/var/web-gui/_log/remote.log)
Hallo @gea,
danke für die Antwort, das hatte ich auch so verstanden und hatte ja zuletzt auch mehrfach über einige Tage so funktioniert: Aufruf des Replikationsscript auf dem Backupserver hat - nach dem Anlgene des Replikationssnapshots - "zfs send | nc" auf dem Quellserver gestartet und die Replikation ist dann auch problemlos durchgelaufen. Auch nicht mehr benötigte Replikations-Snapshots wurden automatisch gelöscht. Aktuell geht das aber mit der Fehlermeldung von oben nicht mehr. Webzugriff auf die GUI beider Server habe ich aktuell keinen, sondern nur ssh-Zugriff auf beide Server. Ist es möglich, daß die Appliance-Group verloren gegangen ist und falls ja, kann ich das mittels ssh - also ohne Web-GUI - irgendwie prüfen bzw. wiederherstellen? Irgendwo muß die Information ja auf beiden Systemen gespeichert sein.

Wie wird den der Sende-Prozeß auf dem Quellsystem durch den Backupserver initiiert? Geht das mittels Aufruf einer URL auf dem Webserver des Quellsystems und falls ja, kann man die auch zu Testzwecken manuell starten? Eine Kommunikation mit ssh zum Starten eines Prozesses auf dem Quellserver durch den Backupserver - was ja auch möglich wäre - wäre mir bisher nicht aufgefallen.

Andererseits: Wenn der snapshot auf dem Quellsystem nach dem Aufruf des Replikationsscripts automatisch erzeugt wird, müßte man doch eigentlich davon ausgehen, daß die Appliance Group als solche noch aktiv ist? Ich nehme ja an, daß auch der Replikationssnapshot (mit _nr_x am Ende) vor der eigentlichen Replikation auf dem Quellsystem vom Backupserver gesteuert erstellt wird? Oder bin ich da völlig auf dem falschen Dampfer?

Ich habe den Eindruck, als ob der Aufruf des Send-Script aus irgendwelchen Gründen nicht geht, der Aufruf eines "Erstelle-Snapshot-Scripts" vorher aber sehr wohl funktioniert. Irgendwie nicht nachvollziehbar für mich ...

Die letzte Replikationssnapshot-Nummer stimmt übrigens auf beiden System natürlich überein und wenn beim Testen auf dem Quellsystem ein neuer erstellt worden ist und die Nummer wegen der aktuell streikenden Replikation divergiert, lösche ich diesen natürlich vor einem neuerlichen Start manuell. Aber trotzdem kommt aktuell keine Kommunikation über nc zustande ...

Wenn ich hingegen nur nc auf beiden Systemen starte, kommt eine Kommunikation von stdin am Sender (Quellserver) zu stdout am Receiver (Backupserver) problemlos zustande - auch über jenen Port, der für die Replikation verwendet wird. Eine Kommunikation ist also grundsätzlich problemlos möglich und Firewall hängt auch keine dazwischen.
 
Eine einfache URL gibt es nicht da in einer Interaktion der gemeinsame Snapstand abgeglichen wird und Jobparameter übertragen werden. Ob die Appliance Group Probleme macht könnte man nur per Web-gui prüfen bzw neu erstellen. Gibt es irgendwelche Änderungen in der Netzkonfiguration, z.B. Jumbo, einen Host Namenswechsel oder mehrere Netzwerkkarten?

Woran scheitert der Aufruf der Web-gui? Wenn alles Remote steht, wäre der einfachste Weg eine Wireguard VPN Verbindung dahin, z.B. über einen billigen GL-Inet Reiserouter ab 30 Euro. Damit kommt man sicher übers Internet in ein anderes Netz. Wenn Replikation ohne napp-it per ssh funktionieren soll, dann wäre eines der freien ssh Replikationsscripts eine weitere Option, z.B. https://omnios.org/info/zrepl.html
 
@gea würde gerne vorschlagen, für diese Entwicklungsthemen einen neuen Thread aufzumachen, das hat eh nicht direkt mit ZFS zu tun. Der hier is mit über 400 Seiten ja schon vollkommen überfüllt.

cu
 
ganz kurz: das Kommando
zpool replace QNAPZFS2 raidz1-0 ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N4JC7Z2D
ist falsch.
Richtig wäre:
zpool replace <pool> <old-device> [new-device]
wenn ichs richtig lese in deinem Fall:

zpool replace QNAPZFS2 13419636845726771512 ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N4JC7Z2D

Erstmal nicht mit -f rumfuhrwerken und nicht ne defekte Platte wieder einbauen. Thema ASHIFT kannst ebenfalls vergessen.

Wahnsinn geht. du bist der Beste. du hast den Abend gerettet.
 
@gea Ist bekannt das nach einen Update auf die r151044 die TLS Mail nicht mehr funktioniert. Bleibt beim Test irgendwie hängen. Mit der ...042 hat es mit den selben eMail-Konto noch funktioniert.
Bin wieder zurück auf die ...042.
 
Bei mir geht es auch mit r44 weiterhin. Evtl musst Du die drei TLS Pakete neu installieren?
 
Danke für die Antwort, habe ich schon gemacht. Aus napp-it heraus funktioiert das nicht. Mit dem folgenden Testscript als Beispiel geht es:

Here is a sample Perl script that can be used to test sending an email over TLS with the STARTTLS extension:

use strict;
use warnings;
use Net::SMTP;

my $smtp = Net::SMTP->new('smtp.gmail.com',
Port => 587,
Hello => 'example.com',
Timeout => 30,
);

$smtp->starttls();
$smtp->auth('LOGIN', 'your_email@example.com', 'your_password');

$smtp->mail('your_email@example.com');
$smtp->to('recipient@example.com');
$smtp->data();
$smtp->datasend("Subject: Test Email\n");
$smtp->datasend("\n");
$smtp->datasend("This is a test email sent over TLS with the STARTTLS extension.\n");
$smtp->dataend();
$smtp->quit;

Werde ich wohl mal neu aufsetzen müssen ?
 
Wird TLS mit einem Report oder Alert Job genutzt?
Bei ersterem kann man per Job angeben ob TLS zu nutzen ist. Bei Alert muss man Alert Jobs auf TLS umstellen.
(Jobs > TLS > enable TLS).

ansonst:
Google has disabled sending mails through apps, see https://wpmailsmtp.com/gmail-less-secure-apps/. If you want to send alerts over Gmail, you must use TLS and you must enable 2FA authentication. After this you can create an app password .

You can then send encrypted mails with your emailadress as user and the app password. For Jobs > Reports you can select SSL encrypted mails per job. For Jobs > Email Alerts/Status you must switch mail to TLS in menu Jobs > Email> enable TLS


ps
Das Send Script mit TLS Alert ist /var/web-gui/data/napp-it/zfsos/_lib/scripts/job-email.pl Zeile 398
bzw. Testscript "/var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl"
Mein Aufruf sieht leicht anders aus.
 
Zuletzt bearbeitet:
Hallo,

Eine kurze Verständnisfrage (generell).
Annahme:
ZFS / 128 GB RAM + SLOG + HDD Spindle Pool (sagen wir mal 2 im mirror).

Der Pool soll als datastore für vSPHERE herhalten über NFS, also sync=always. Der ZFS ist selber als VM über vSwitch angebunden. Laut VMWare ist der eth adapter und der vSwitch in diesem Szenario nur auf die CPU/RAM/BUS-Geschwindigkeit begrenzt und nicht auf die Adaptergeschwindigkeit, also sagen wir mal PCIe 3.0 x4 ~= 4 GByte/s. In der Realität erreicht man in dem Szenario zwischen 4-8 GByte/s (RAMdisk to RAMdisk Transfer)

RAM ist DDR4 2666 MHz, also knapp 21 GB/s Bandbreite.
SLOG ist Optane mit sagen wir 1000 MB/s write-speed.
Pool ist WD Gold mit knapp 250 MB/s.
Jeweils an eigener PCIe Lane.

Die txg committ time ist 5s - Das dirty_max limit auf 50 % RAM gesetzt. Daten input konstanter Burst bei 100 % Bus-Auslatung (zum besseren Verständnis)

Fragen:
- Ist es dann so, dass ich pro TXG theoretisch 5s lang PCIe x4 Bandbreite als größe hätte? (Also 5 s x 4 GByte/s = 20 GByte / TXG).
- Das SLOG löst den write-ack bereits aus, sobald die Daten auf dem SLOG dev dupliziert wurden. In der Zwischenzeit und weiter danach wird wie immer von RAM -> Pool geflushed?
- Wenn das dirty_max limit bei 50 % - hier 64 GByte - liegt, der Dateninput konstant bleibt, akkumulieren dann die TXGs bis "dirty_max" erreicht?
Sprich, wenn der flush auf pool bei 0 MB/s liegen würde, könnte ich trotzdem 64 GByte in 15 s á 20 GByte/TXG im RAM vorhalten. Die Anzahl an TXGs würde allerdings eher vom SLOG speed abhängen, sprich 1 GByte/s x 5 s = 5 GByte / TXG. Sprich knapp 12 TXGs.
- Da der Speed hier maßgeblich vom SLOG abhängt, wäre die maximale Bandbreit NFS dann bei knapp 1 GByte/s bis eben das dirty_max limit erreicht ist und das System dann für weiteren Input stale schaltet.
- (-) Meta/Overhead etc natürlich.

Kurz: Akkumulieren die TXGs in RAM+SLOG solange a) SLOG groß und schnell genug, b) Pool langsam genug und c) "dirty_max" ausreichend groß?

Hintergrund der Frage ist letztlich die Auslegung bzgl. "dirty_max" RAM und SLOG Größe/Overprovisioning.

Gruß & Dank
Thomas
 
Zuletzt bearbeitet:
Prinipiell ist die Größe des RAM Schreibcaches nur bei Solaris und native ZFS zeitbasiert auf 5s ausgelegt. Bei Open-ZFS werden per default 10% des RAM/ max 4GB als Schreibcache genutzt. Ist der Ramcache teilweise gefüllt, wird er auf den Pool geschrieben damit weiteres Caching möglich bleibt. Ram ist ansonst Lesecache.

Sync write arbeitet unabhängig vom Writecache und protokolliert zusätzlich jedes Write commit sofort auf den ZIL Bereich eines Pools oder ein Slog. Die Mindestgröße des Slog ist damit 2x5s Schreiben bei Solaris bzw. 2x4 GB bei Open-ZFS. 10 GB wären also bei 10G Netz ausreichend. Overprovisioning brauchts nur bei normalem Flash. Man nimmt meist eine Intel DC Optane als Slog. Die braucht kein Overprovisioning. Da zählt nur DWPD und io Performance. In der Regel muss da auch nichts optimiert werden. Sync einschalten und allenfalls recsize kleiner setzen z.B. 32k oder 64k für VM Storage. Begrenzt wird die Schreibperformance durch Sync Write Logging mit kleinsten Blöcken auf die Optane und zusätzlich dem normalen Write aus dem Writecache. Egal was man macht, man wird bei Plattenpool + Optane Slog nicht über vielleicht 500 MB/s kommen, mit einem reinen Optane Pool vielleicht auf 800 MB/s.
 
Hallo gea,

sowei habe ich das auch verstanden. Nur meine Frage ansich bezieht sich eher auf die Auslastung RAM mit Hilfe einer Modifikation von dirty_max und dirty_max_max auf z.b. max_max=100 GB und max=75% also 75 GB max. Die 2x5 s sind ja, wenn ich dich recht verstanden habe aufgrund von a) writecache ansich (Dateninput) und b) SyncWrite, also ZIL.
Nur: Solange der Commit der Daten auf die Spindeln noch nicht erfolgt ist (also noch im gang) kann ja schon das nächste TXG gesammelt werden und somit dann unter obigen Modifikationen bis z.B. 75 GB ansteigen. Korrekt?

Und das mit Overprovisioning ist einfach um die DWPD der P1600X hochzutreiben:

GBneededOverprovTBWTBW_finalTBW/JahrTBW/TagDWPDlatency
118 GBP1600x
118​
118​
0%​
1292​
1292​
258,4​
0,70794521​
6​
7 us
118 GBP1600x
118​
64​
46%​
1292​
2382,125​
476,425​
1,30527397​
11​
7 us
118 GBP1600x
118​
32​
73%​
1292​
4764,25​
952,85​
2,61054795​
22​
7 us

Gruß
Thomas
 
Ein RAM Schreibcache z.B. 4GB dient dazu kleine write zu vermeiden indem die gesammelt und als ein großes Write geschrieben werden. Hintergrund ist dass Writes z.B. <128k sehr viel langsamer sind als größere. Ein sehr großer Schreibcache ist kontraproduktiv da damit nur kurzzeitig ein sehr schnelles Schreiben möglich wäre, nach einer entsprechenden Füllung aber dann doch wieder die reine Pool Performance bremsen würde. Ist also nichts gewonnen. Da ZFS seine Performance in hohem Maß aus dem RAM Readcache bezieht wäre ein großer Schreibcache mit kleinerem Lesecache bremsend. Und wie gesagt, für sync write ist die Größe des Schreibcaches egal. Wenn das schreibende Programm ein commit will, muss der sofort auf das Slog. Da wird nichts angesammelt.

Overprovisioning,. also die Kapazität nur teilweise zu nutzen um DWPD für den Teilbereich zu erhöhen ist letzlich nur eine veränderte Sichtweise. 10 DWPD bei 10 GB Kapazität ist das gleiche wie 1 DWPD bei 100 GB. Bei Flash macht man Overprovisioning wegen höheren iops Werten, bei Optane ändert sich das nicht.
 
Zuletzt bearbeitet:
@gea
Ich muss mich nochmal zu dem TLS eMail Problem melden.
Es funktionierte bei mir ja nach einem Update auf die ..44 und Neuinstallation der Perl Module, die TLS eMail nicht mehr. Ich bin dann auf die ..42 zurückgegangen.

Es hat mir keine Ruhe gelassen und ich habe in VMware mal Neuinstallationen der ..38/..42../44 gemacht, nappit eval 21.06 isntalliert und jeweils die Perl-Module aus dem CPAN neu compiliert.
Es funktioniert bei keiner Version mehr! Es kommt ein Fehler beim TLS Test. Der SMPT Server ist smtp.ionos.de. Dort soll sich nichts geändert haben!? Die gleichen Zugangsdaten funktionieren auf der alten Installation mit derm OmniOS ..42

Couldn't start TLS: hostname verification failed at /var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl line 80.

Bin nun einigermaßen ratlos. Kann es sein das in der CPAN sich was mit den Perl Modulen geändert hat?

vg
 
Mir ist noch Folgendes aufgefallen, die alte funktionierende ..42 auf ..44 upgedatet + Perl Module neu -> TLS Test bleibt hängen. Etwas herunprobiert und einige &mess(..) gesetzt und herausgefunden,
das der Test in der action.pl definitiv in folgendem Stück Code hängen bleibt.

...
use Net::SMTP::TLS;

### hier kommt das script noch an

# Hello => host.domain.com
my $smtp = new Net::SMTP::TLS("$server",
Hello => "$host",
Port => "587",
User => "$user",
Password => "$pw") || &mess("could not connect smtp-server $server");

### diese Stelle wird nicht mehr erreicht
...

Bleit also in der my $smtp ... stecken, Alle Variablen haben den richtigen Wert.
Der SMTP-Server ist smtp.ionos.net und funktioniert unter der ..42 (zur Zeit noch TLS1.0/1.1/1.2 aktiv, soll sich später ändern) .
Da muss sich also was in den Perl-Modulen getan haben.

Ich hoffe das hilft weiter.
Beitrag automatisch zusammengeführt:

nochmal ich :),

bei einem neu installierten OmniOS + nappit kommt halt der Fehler
Couldn't start TLS: hostname verification failed at /var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl line 80.

ist genau in der Funktion!
 
Zuletzt bearbeitet:
Net::SMTP::TLS scheint beim aktuellen OmniOS Probleme zu machen.
Ich habe den TLS send im aktuellen napp-it 23.dev (22.jan) modifiziert.

TLS Alert/Status/Test und Reports sollte damit wieder gehen
 
Kurze Info: Ich hatte dieselbe Fehlermeldung und dieselben Probleme mit TLS Mail. Mit 23.dev (22.jan) läuft es jetzt wieder. Danke @gea
 
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