Napp-IT als ESXi VM: Welche Ressourcen sollten zur Verfügung gestellt werden ?

[Traviso]

Hallo,

ich habe Napp-IT unter ESXi 7.0 als VM am Laufen.
Installiert ist Napp-IT in Version 22.01b. Der VM wurden 2 vCPUs mit je 2 Threads zugeteilt. Weiterhin 32 GB RAM.

Nachdem ich jetzt zeitlich gestaffelte Snapshots aufgesetzt habe, ist mir aufgefallen, dass während des initialen Snapshots die CPU-Auslastung in der Napp-IT VM konstant bei 100% liegt.
Der Snapshot als solches läuft jetzt schon seit 3 Tagen und das System reagiert sehr langsam (speziell die GUI).

Sollte man vielleicht mehr vCPUs/Threads per CPU für die Napp-IT VM zur Verfügung stellen ?

Auch die zeitliche Dauer des Snapshots scheint sehr lange zu sein. Inzwischen habe ich für 2 der Pools bereits parallel Snapshots laufen, da diese sich zeitlich überschnitten haben (der initiale Snapshot ist noch nicht fertiggestellt). Gibt es diesbezüglich auch eine Empfehlung ?

Vielen Dank im Voraus für die Hilfe.

 

[asche77]

So lange dauert ein snapshot nicht.

Welches Betriebssystem hast Du denn drauf? OmniOS r40 oder was anderes?

 

[Traviso]

So lange dauert ein snapshot nicht.

Es sind schon ein paar TB, mit relativ vielen kleinen Dateien.

Welches Betriebssystem hast Du denn drauf? OmniOS r40 oder was anderes?

Bei mir ist OmniOS r38 installiert.

 

[Traviso]

Um nochmal auf das Thema lang andauernder Snapshot zurückzukommen:

In Napp-IT sieht es so aus, als ob der Snapshot Task seit gestern Abend ca. 18 Uhr läuft (Screenshot wurde heute um 11:35 Uhr erstellt):

Eine Auflistung der Snapshots zeigt mir folgendes an:

Es geht also um ca. 6 TB Daten. Kann es also sein, dass der Snapshot so lange dauert ?

 

[asche77]

Nein. Der snapshot ist sehr sehr schnell erstellt - es wird ja nichts kopiert oder gelesen, sondern "einfach" ein Marker gesetzt, dass alles vor der betreffenden TXG nicht gelöscht werden kann ohne den snapshot vorher zu löschen.

Größe des Pool daher egal - heißt ja auch zettabyte file system.

 

[Traviso]

Nein. Der snapshot ist sehr sehr schnell erstellt - es wird ja nichts kopiert oder gelesen, sondern "einfach" ein Marker gesetzt, dass alles vor der betreffenden TXG nicht gelöscht werden kann ohne den snapshot vorher zu löschen.

Umso mehr stellt sich mir die Frage, warum das dann jetzt so lange dauert. Es handelt sich allerdings um den initialen Snapshot.

 

[asche77]

Teste es halt Mal auf der Kommandozeile...

Und schau (zB in napp-it unter System) was die Prozessorauslastung, iostat etc machen - evtl ist eine HDD/SSD kaputt, ein Kabel sitzt schief oder ähnlich.

 

[Traviso]

Iostat sieht so aus:

Und die Prozessorauslastung sieht auch ok aus:

Die Festplatten werden alle erkannt und es wird auch kein Problem mit den Festplatten angezeigt.

 

[asche77]

Werden dir denn im snapshot Menü schon snapshots angezeigt?

Beitrag automatisch zusammengeführt: 01.02.2022

Kommandozeile testen:
pfexec zfs snapshot [dataset]@[snapshot name]
pfexec zfs list -t snapshot

Beitrag automatisch zusammengeführt: 01.02.2022

(Vielleicht ist ja nur die Job Anzeige fehlerhaft und die snapshots normal erstellt)

 

[Traviso]

pfexec zfs list -t snapshot

pfexec zfs snapshot [dataset]@[snapshot name]

Werden dir denn im snapshot Menü schon snapshots angezeigt?

Der Snapshot wird auch hier mit 0 "used" angezeigt.

Beitrag automatisch zusammengeführt: 01.02.2022

Gerade eben wurde der Snapshot Task von gestern Abend beendet:

Der Snapshot ist 0 Byte groß. Stellt sich natürlich immer noch die Frage, warum das so lange gedauert hat.

 

[asche77]

Snapshot hat solange "null" bytes, bis eine Datei (die im snapshot enthalten ist) gelöscht oder geändert wird. Erst dann kann ja der alte Datenblock nicht einfach gelöscht/frei markiert werden, sondern muss wegen des snapshots bewahrt werden.

Ich vermute, dass da Script (job) irgendwo hängt, aber die snapshots selbst normal angelegt werden?

 

[Traviso]

Snapshot hat solange "null" bytes, bis eine Datei (die im snapshot enthalten ist) gelöscht oder geändert wird. Erst dann kann ja der alte Datenblock nicht einfach gelöscht/frei markiert werden, sondern muss wegen des snapshots bewahrt werden.

Ok, ich habe jetzt mal eine weitere Datei in diesen Pool kopiert und lasse einen weiteren Snapshot laufen. Mal sehen, wie das Ergebnis ist...
Vielen Dank auf jeden Fall für deine Tipps.

 

[asche77]

Datei löschen, nicht neu hinzukopieren

 

[Traviso]

Datei löschen, nicht neu hinzukopieren

Test1: Datei hinzugefügt
Test2: Datei aus Test gelöscht und andere Datei hinzugefügt
Test3: Datei aus Test2 gelöscht

Diese 3 Snapshots wurden manuell über das "Snapshot Menü" von Napp-IT erstellt.

Danach habe ich den "monatlichen Snapshot" manuell gestartet (im Menü "Aufgaben"). Dieser läuft jetzt bereits wieder seit einigen Minuten.

 

[asche77]

Dann sprich Mal @gea an, der Job dürfte nicht solange laufen und manuell klappt es ja mit dem zügigen anlegen der snapshots. ..

 

[Traviso]

Dann sprich Mal @gea an, der Job dürfte nicht solange laufen und manuell klappt es ja mit dem zügigen anlegen der snapshots. .

Ja, sieht wohl so aus. Danke fürs taggen von @gea.

 

[gea]

Ein Snapshot anlegen sollte nahezu sofort passieren (ist ja wie bereits gesagt nur ein Schützen bereits geschriebener ZFS Datenblöcke vor Überschreiben). Wenn das lange dauert ist das Problem woanders zu suchen (z.B. Platte, HBA/Firmware, Kabel)

Steht in System > Log oder System > Faults was auffälliges?
Ist beim sonstigen Schreiben/Lesen die Last auf allen Platte ähnlich (iostat)?
Ist Acceleration und Monitoring an oder aus (acc, mon im Topmenü bei Logout)?
Ändert sich was nach reboot?

ps
Wenn acc aus ist muss man das Aufgaben Menü manuell reloaden damit die Job Status Anzeige sich aktualisiert,

 

[Traviso]

Steht in System > Log oder System > Faults was auffälliges?

In Faults stehen im Wesentlichen eine Menge dieser Einträge:

Feb 01 13:56:16.2235 resource.sysevent.EC_zfs.ESC_ZFS_config_sync
Feb 01 13:58:22.5357 resource.sysevent.EC_zfs.ESC_ZFS_history_event

Im Log-0 sind die letzten Einträge vom 25.1. Also nichts aktuelles.

Ist beim sonstigen Schreiben/Lesen die Last auf allen Platte ähnlich (iostat)?

Von HDD8TB wird gerade eine Datei gestreamt.

Auf HDD6TB läuft immer noch der manuell gestartete monatliche Snapshot Task von heute Nachmittag.

Im Augenblick sieht es folgendermaßen aus:

Stream läuft immer noch. Zusätzlich ein manueller Snap von HDD8TB und HDD6TB. Zusätzlich läuft noch der Snapshot Task.

Ist Acceleration und Monitoring an oder aus (acc, mon im Topmenü bei Logout)?

Acceleration und Monitoring sind beide aktiviert.

Ändert sich was nach reboot?

Keine Änderung nach einem Reboot.


Edit:
Gerade habe ich noch unter System -> Faults -> Error Details folgendes gefunden:

Spoiler: Fehlermeldung

Feb 01 2022 13:55:20.020063607 ereport.io.scsi.cmd.disk.dev.rqs.derr
nvlist version: 0
class = ereport.io.scsi.cmd.disk.dev.rqs.derr
ena = 0x78c63026f00001
detector = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = dev
device-path = /pci@0,0/pci15ad,1976@10/sd@0,0
devid = id1,sd@n6000c293f5a968a098560f0f46bf9896
(end detector)

devid = id1,sd@n6000c293f5a968a098560f0f46bf9896
driver-assessment = fail
op-code = 0x1a
cdb = 0x1a 0x0 0x48 0x0 0x20 0x0
pkt-reason = 0x0
pkt-state = 0x37
pkt-stats = 0x0
stat-code = 0x2
key = 0x5
asc = 0x24
ascq = 0x0
sense-data = 0x70 0x0 0x5 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x24 0x0 0x0 0xc0 0x0 0x2 0x0 0x0
__ttl = 0x1
__tod = 0x61f92db8 0x1322577

Controller sind Fujitsu CP400i gelfasht auf LSI 9300-8i (P16 > IT-Mode).

 

[Traviso]

Der Snapshot Job läuft immer noch seit gestern Nachmittag. Iostat sieht im Augenblick so aus:

 

[gea]

Hdd6TB steht auf 100% wait/busy. Ich würde die Platte mal mit einem Herstellertool intensiv testen z.B. wd data lifeguard. Am einfachsten geht das mit einem Hirens USB Bootstick. Darauf ist Windows PE und unter anderem wd data lifeguard

Hiren's BootCD PE

edit: Ich seh gerade dass für den Autosnap Job md5 aktiviert ist. Warum?

Bei Aktivieren dieser Option wird für jede Datei vor dem Snap eine md5 Prüfsumme berechnet und als Liste auf den Pool gelegt. Das dauert richtig lange. Diese Funktion ist dafür vorgesehen (rechtssichere Langzeitarchivierung) dass man diese Liste sichert bzw ausdruckt, abzeichnet und abheftet. (Als Sicherheit/Garantie dafür dass eine Datei z.B. seit dem Erstellen nicht verändert wurde). Wenn man das nicht braucht, Job löschen und ohne md5 neu anlegen.

 

[Traviso]

Hdd6TB steht auf 100% wait/busy. Ich würde die Platte mal mit einem Herstellertool intensiv testen z.B. wd data lifeguard. Am einfachsten geht das mit einem Hirens USB Bootstick. Darauf ist Windows PE und unter anderem wd data lifeguard

HDD6TB ist ein raidz-Pool aus 3 Platten. Dann werde ich einmal alle drei Platten testen.

 

[gea]

HDD6TB ist ein raidz-Pool aus 3 Platten. Dann werde ich einmal alle drei Platten testen.

erstmal md5 löschen. Das sollte das Problem beheben.

 

[Traviso]

erstmal md5 löschen. Das sollte das Problem beheben.

Mache ich, danke für den Tipp.

Edit: Problem gelöst. Hätte ich mal genauer den Infotext dazu, beim Erstellen des Snap Jobs, gelesen. Nochmals danke für den Hinweis!

 

[Traviso]

Ich habe jetzt vom Backup Server aus Replikationsjobs angelegt, um die verschiedenen ZFS-Dateisysteme auf dem eigentlichen Server zu sichern.
Dabei waren auf dem Backup Server bereits ZFS-Dateisysteme angelegt, in welche gesichert werden sollte:

- Als Beispiel soll HDD6TB auf dem Server in HDD6TB_Backup auf dem Backupserver gesichert werden:

Gemäß log scheinen die Replikationen zu laufen. Allerdings hätte ich erwartet, dass der erste Job die ganzen Daten vom Server zum Backup Server kopiert.

Allerdings musste ich jetzt feststellen, dass alle Dateisysteme auf dem Backup Server jetzt doppelt vorhanden sind (bis auf den Root Pool):

Woran kann dies liegen ? Und woran kann es liegen, dass nicht die ganzen Daten auf den Backup Server gezogen werden ?

 

[gea]

Ich denke es liegt an einem falschen Verständnis von ZFS Replikation.

1. ZFS Erst-Replikation kopiert keine Daten im allgemeinen wie z.B. rsync sondern überträgt immer komplette ZFS datasets (Dateisysteme, Zvols und Snaps) als Datenstrom, kann man sich wie eine Radiosendung vorstellen die aufgezeichnet wird. Es ist also nicht sinnvoll vorab Dateisysteme anzulegen oder man hat dann die und zusätzlich die replizierten.

2. ZFS Folgereplikationen übertragen die geänderten ZFS Datenblöcke seit einem gemeinsamen Basissnap. Ergebnis ist ein aktualisiertes Ziel Dateisystem und ein neuer gemeinsamer Basissnap.

3. Um alle Daten (datasets) zu übertragen muss rekursiv aktiviert werden. Nachteil: Wenn neue Dateisysteme dazu kommen fehlen beim folgenden inkrementellen Aufruf die entsprechenden Snap-Paare. Es ist also meist besser je Dateisystem einen Replikationsjob anzulegen. Reduziert auch die Datenmenge bei Problemen.

4. Ein zu übertragendes Dateisystem landet unterhalb des Zieldateisystems, nicht im Zieldateisystem z.B. (ohne recursiv)

Pool1 -> Pool2: Ergebnis Pool2/Pool1
Pool1/daten -> Pool2: Ergebnis Pool2/daten
Pool1/daten -> Pool2/backup: Ergebnis Pool2/backup/daten

Todo:
Selbst angelegte Ziel Dateisysteme löschen oder wenn unklar, alle Backup Dateisysteme löschen und Replikation neu starten

 

[Traviso]

Ich denke es liegt an einem falschen Verständnis von ZFS Replikation.

Das ist wohl wahr.

Es ist also nicht sinnvoll vorab Dateisysteme anzulegen oder man hat dann die und zusätzlich die replizierten.

Ok, ich dachte, dafür wäre die Auswahlmöglichkeit beim Anlegen des Replikations Tasks da. Aber kein Problem, dann lösche ich Dateisysteme und starte nochmal alles.