[Sammelthread] napp-it 4ai, client-server Web-GUI für ZFS Server (any/mixed OS)

Remote Backup übers Internet

Bei einem guten Backup ist mindestens eine Kopie der Daten remote also nicht im gleichen Stromnetz, Brandabschnitt oder Gebäude, idealerweise auch nicht im gleichen Lan. ZFS Replikation oder Filesync sind ideal im Lan, im Internet sollte aber generell Verschlüsselung sowie Firewall bzw ein gesicherter Tunnel genutzt werden. Mit VPN oder cs-stream + Firewall ginge zwar auch sichere und verschlüsselte ZFS Replikation oder Filesync, im Internet ist aber ein S3 gestütztes Verfahren ideal weil

- fester Port für den Datentransfer z.B. bei RustFS 9000 für Filetransfer und 9001 für die Webconsole
- Jede Datei ist eine verschlüsselte, authentifizierte https Url, also perfekt für webbasierte Cloudnutzung
- S3 arbeitet gut mit schlechten, langsamen Netzwerkverbindungen oder Wlan zusammen

Um S3 zu nutzen, brauchts einen S3 Server. Das kann Amazon AWS sein (teuer), ein günstiger deutscher S3 Internet Provider oder ein minIO/RustFS Inhouse/Home S3 Server. Napp-it unterstützt einen oder mehrere RustFS Server in single-node/multi-node Cluster Modus sowie single/multiple Disk mode (ideal ist ZFS Pool= RustFS single disk mode).

Fürs Backup oder Datentransfers via S3 gibts drei Optionen

1. WinSCP (quick and easy).

In WinSCP einen S3 Server nutzen, idealerweise per SSL/TLS damit Transfers verschlüsselt werden und in den Advanced Settings dazu den S3 Path Modus setzen. WinSCP arbeitet dann im 2 Fenster Modus lokale Ordner vs S3 Buckets

1790757796230.png

2. Filesync mit rclone

Rclone ist sowas wie rsync für Cloud. Es kann lokale Ordner und S3 Buckets syncronieren. Datentransfer wird mit https verschlüsselt. Einfaches Handling und die Daten auf dem S3 Bucket können mit beliebigen S3 Tools gelesen werden, ideal also wenn man von überall darauf zugreifen möchte (private Cloud). Napp-it kann s3 backup Jobs erstellen, die einen lokalen Ordner via rclone mit einem S3 Bucket syncronisieren.

3. Backup mit restic

Restic ist ein Backup Tool das auf dem S3 Server ein verschlüsseltes Datenrepository in einem Bucket anlegt. Darin werden die Daten grundsätzlich nach Deduplizierung mit dem Client PW verschlüsselt und mit Snap Versionierung gespeichert. Snaps + Verschlüssellung + Deduplizierung sind die Restic Schlüsselmerkmale. Es ist damit die ideale Backup Alternative zu ZFS Verfahren. Beim Anlegen eines napp-it S3 backup/restore Jobs kann nan neben rclone auch restic wählen, beim Restore einen Snap. Restic Backup braucht beim ersten Lauf wegen der Deduplizierung etwas länger, ab dem zweiten Lauf ist es sehr schnell und platzsparend weil nur geänderte Datenblöcke verarbeitet werden.

Bucket/ Site Replikation

Bei zwei S3 RustFS Servern gibt es mit Bucket oder Site Replikation eine Realtime Hochverfügbarkeits-Option. Mann kann nämlich RustFS so konfigurieren dass es zwei Buckets oder zwei ganze Server (alle Buckets) selbstständig und eventbasiert im 2 Wege Modus sncron hält, set and forget halt.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Klassisches 321 Backup vs Echtzeit Sync

ZFS Replikation, Filesync und S3 Backups mit ZFS Snap Versionierung die man stündlich, täglich oder wöchentlich laufen läßt, sind klassische Backupjobs und Scripte. Im Wesentlichen syncronisiert man dabei regelmäßig einen Originaldatenstand mit einem lokalen oder Remote Backupdatenstand und behält dabei einen sinnvollen Satz von readonly Vorversionen auf die man direkt Zugreifen kann. Backup ist dabei immer wie Brot von gestern - alt statt knusprig frisch.

Realtime Sync

Die Alternative sind Echtzeit Verfahren die ein Dateisystem auf Ereignisse wie create oder write überwachen. Zusätzlich wird eine Liste aller Datein erfasst für Erst-sync oder Re-sync z.B. nach Crash oder für regelmäßiges Verify Der Vorteil ist damit klar. In dem Moment in dem eine Datei angelegt oder geändert wird, ist sie auch auf dem Backup geändert. Bei vielen Änderungen oder langsamen Storage muss eine Liste der noch nicht geänderten Dateien gepflegt werden. Für ein Hochlastsystem mit vielen Usern kann das ein Problem werden, vor allem wenn bidir Sync gewollt ist.

In napp-it 4ai ist Echtzeit sync an zwei Stellen im Einsatz

1.) cs-sync.

Das ist ein OpenSource Go Tool für alle 8 OS Plattformen von napp-it für Echtzeit sync über 3 Endpunkte A, B und C.
A und B müssen lokale Dateisysteme/Ordner sein, typischerweise ein A Ordner der lokal im Netz per SMB freigegeben ist und B als Ordner für eine inhouse Internet S3 Cloud. A und B werden eventgesteuert in Echtzeit 2way syncronisiert. Wird eine Datei per SMB geändert, wird sofort eine Kopie im S3 CloudShare aktualisiert. Wird eine Datei auf S3/RustFS hochgeladen, ist sofort auch die Kopie im SMB Share aktuell. ACL in SMB werden über Vererbung gesetzt.

Endpunkt C kann lokal oder auf einem Remote Server im Lan sein. Es ist ein Backup Endpunkt für A. Alle Änderungen auf A landen in Echtzeit auf Z
ZFS Snaps mit Versionierung sichern das auf A, B oder C ab . CS-sync ist ein Hintergrundservice in napp-it 4ai client-server, kann aber auch eigenständig als cli Tool benutzt werden, https://github.com/guenther-alka/cs-sync

2. RustFS S3 Replikation

Das wird auf 2 RustFS Server aktiviert und die 2 Server halten ausgewählte oder alle S3 Buckets im 2way Sync. Jede Änderung auf einer Seite erscheint sofort auf der anderen. Einmal eingerichtet ist das set and forget, https://docs.rustfs.com/en/administration/data/bucket/replication
 
MS 365 und NextCloud sind die "Platzhirsche" für kollaboratives Arbeiten, gleichzeitig sind beide absoute Überteile an Umfang, Komplexität und Features. Als datenschutz-unproblematischere Inhouse Option ist NextCloud denkbar, aber viel zu komplex in der Wartung und in der Absicherung im Internet, selbst als Docker Setup.

Wenn man Abstriche macht, z.B. kein Mailserver, Texteditor und Tabellenkalkulation etwas einfacher mit Focus auf Multiuser Edit, kein AD/Ldap stattdessen user.csv import/export, dazu Resourcenplanung (Beamer, Räume, Personen), sowie Ticketsystem light, also eher eine Schule, eine Abteilung, einen Verein oder einen kleineren Betrieb als Zielgruppe sieht, dann sind plötzlich absolute KISS Lösungen denkbar, durch die KI Integration werden auch komplexe Aufgaben einfach umsetzbar.

Das ist mein Ansatz mit cs-team. Läuft auf jedem OS auch ohne napp-it, copy and run (ca 10MB), keine Datenbank, ein Ordner auf der Platte reicht, mit ZFS gibts halt Snaps dazu. In der aktuellen 0.53 release habe ich nochmal Usability verbessert.

Als OpenSource git Projekt einfach erweiterbar und auditierbar.
Projectt: https://github.com/guenther-alka/cs-team
Manual: https://www.napp-it.org/pdf/cs-team_de.pdf
Standalone Setup: https://github.com/guenther-alka/cs-team/blob/main/docs/HOWTO-standalone.md
 
neue Version cs-team 0.61
github.com

GitHub - guenther-alka/cs-team: Single-binary collaboration platform (Nextcloud light): CalDAV calendar, Calc, Text, Files/WebDAV, Tasks, Chat - part of napp-it 4ai

Single-binary collaboration platform (Nextcloud light): CalDAV calendar, Calc, Text, Files/WebDAV, Tasks, Chat - part of napp-it 4ai - guenther-alka/cs-team
github.com github.com

Manual:

Teil der napp-it 4ai web-gui
ist aber Standalone nutzbar

Ziel:
80% der Kernfunktionalität von MS Teams/Office 365 bei
10% der Komplexität (single file binary, copy and run)

Inhouse Setup
volle Kontrolle über Daten, inkl. Inhouse KI

für multinationale Arbeitsgruppen
(13 Sprachen erweiterbar, inkl.wichtigste EU Sprachen, Chinesisch, Japanisch, Russisch)

oder (Hoch)Schulen und Schülern/Studierende mit Migrationshintergrund
(13 Sprachen inkl. Arabisch, Ukrainisch, Türkisch, einfach erweiterbar)
 
Zuletzt bearbeitet:
4ai/cs_rc_26.10.08.14
kleinere Bugfixes, readonly S3 Zugriff auf RustFS buckets/snaps oder regular folder/snaps
Handbuch überarbeitet https://www.napp-it.org/pdf/napp-it-cs_de.pdf (oder _en)

-bugfix in menu About > Settings
-manual https://www.napp-it.org/pdf/napp-it-cs_en.pdf (or _de)
-cs-s3gateway, access to zfs snaps or ro RustFS buckets or regular folders
-cs-team v.0.61
-cache invalidate prior and after zpool or zfs actions to guarantee correct gui state
-cs-s3 gateway (s3 readonly access to ZFS snaps and reular folders)
 
Frage: Geht ein napp-it Storage oder All in One Server mit einem USB Stick oder Disk?

Antwort: Ja, kein Problem:

- Ein minimales Linux mit ZFS (wie Proxmox) oder OmniOS (so ziemlich das resourcenschonendste ZFS OS) geht mit einem USB Stick ab 16GB. Wenn man keine Platzprobleme bei OS Updates haben möchte ist ein 32GB Stick besser.

Es gibt Systeme wie SmartOS die zu 100% im RAM laufen, die brauchen aber meist spezielle Methoden z.B. für die Userverwaltung

Generell ist die Zuverlässigkeit von Sticks auch auf bei Systemen die wenig schreiben nicht so toll. Viel besser ist ein USB 3 Laufwerk mit einer SSD oder M.2 ab ca 64GB. Die sind viel schneller, zuverlässiger und es geht auch ein OS mit grafischer Oberfläche (Linux, OSX, Windows). Das wäre meine Empfehlung mit USB

Und welches OS jetzt auf USB (SSD/M.2)

Für napp-it 4ai ist OmniOS die sicherste Wahl, wenn es vor allem um SMB Storage und Stabilität geht.
  • OmniOS (Unix): Es ist minimalistisches illumos (Solaris Fork) als bloody, stable oder LTS ohne Zusatzballast, besonders robustes ZFS und der im Kernel integrierte SMB-Server sind Teil des Systems, und Perl ist dabei. Die ACLs mit Windows-SIDs und SMB-Gruppen in Gruppen funktionieren damit wie unter Windows, ohne Samba. OmniOS ist deshalb meine erste Wahl für reine, stabile Storage-Server. Die Build-Skripte für RustFS und cs-imageindex sind dafür geprüft. Als Systemplatte passt ein USB-SSD/M.2 ab 32GB gut, mit einem normalen, persistenten Boot-Pool.

  • Free-BSD (Unix): Wäre nach OmniOS meine zweite Wahl für ZFS, meist etwas kompakter, schneller und stabiler als Linux

  • Linux (z. B. Debian oder Proxmox): Es hat die größte Hardware- und Treiberbasis, und ZFS läuft über neuestes OpenZFS. SMB geht über Samba oder das schnellere ksmbd. Die Windows-ACLs sind aber weniger komfortabel oder leistungsfähig als unter OmniOS oder Windows. Linux ist die richtige Wahl, wenn man viel Hardware-Unterstützung, Docker/VMs oder Proxmox-Funktionen braucht. Auch dabei gilt: Besser USB-SSD oder USB M.2 statt Stick.

  • Windows 11 Pro
    weil mans kennt mit grafischer Oberfläche. Storage läuft über Storage Spaces oder OpenZFS (noch release candidate). Als SMB Server bis max 20 User

  • Windows Server (günstige Essentials bis 25 User)
    mit Active Directory und SMB Direkt (SMB mit RDMA für 25-100G nics)

  • OSX
    gut als Desktop System, als Storage oder All in One Server eher weniger gut geeignet.
    Wenn man ein Inhouse KI Provider System sucht, ist ein Mac mini mit 48-64 GB RAM oder ein Mac studio mit 196GB für größere Modelle unschlagbar.

Wenn der Server vor allem ein NAS mit SMB-Freigaben und Snapshots wird, wäre OmniOS auf einer kleinen SSD meine erste Empfehlung - ist übrigens ein europäisches Projekt, haupsächlich Schweiz und England. Wenn Hardware oder VMs im Vordergrund stehen, dann Proxmox. Für Videoschnitt Windows Server + Windows Clients mit 25G nics
 
Zuletzt bearbeitet:
Ich würde vielleicht noch ergänzen man sollte bei SSDs wenn man sie dann in ein M.2 Gehäuse stecken will nur Abstand von "High Power" Modellen nehmen. zB 980Pro, 990Pro und was so in die Richtung geht. Weil sie durchaus recht Stromhungrig sind können sie in externen Gehäusen durchaus vermehrt Probleme machen besonders wenn die Stromversorgung dann noch über nen USB-A Port läuft.
 
Eine Bootplatte muss nicht besonders schnell sein, eher robust und langlebig.
Wenn es dann eine schnellere M.2 mit USB werden soll, dann halt auf Metallgehäuse und Kühlrippen achten, im Extremfall mit aktiver Kühlung.
 
Frage an Claude KI: Warum bringt mein Autosnap Job 1780659397 auf Proxmox einen Error

Ich könnte jetzt die Logs anschauen, lokales Joblog im Windows Frontend, eventuell logs auf dem Proxmox member,
und käme dann wohl auch ohne KI auf die Ursache. Es gibt aber spannendere Tätigkeiten als Logfiles zu analysieren und komplexere Probleme.

Antwort von Claude binnen 10s:
Job 1780659397 ist ein Snap-Job daily auf rpool des Members proxmox_1 (192.168.2.112). Er läuft sonntags um 23:00 mit keep=2, hold=8, VM-Freeze yes und der Zusatzoption include=/etc/pve. Er schlägt aktuell fehl, aber nicht wegen der Einstellungen, sondern wegen einer zu alten Programmversion auf dem Member.

Ich habe die Job-Dateien und das Protokoll gelesen,

Befund
  • Fehler: Der manuelle Lauf von heute um 10:45 brach mit flag provided but not defined: -pre-snap-cmd ab. Der Job übergibt wegen include=/etc/pve die Option --pre-snap-cmd an cs-freeze4snap, damit /etc/pve per rsync mit in den Snapshot kommt. Das cs-freeze4snap auf dem Proxmox-Member kennt diese Option nicht, es ist älter als 1.3.0. Dein lokales Windows-Programm hat Version 1.3.0 und kennt sie.
  • Letzter Erfolg: Der letzte erfolgreiche Lauf war am 30.08.2026 (rpool@i_daily-…), davor am 05.06.
  • Auto-Läufe fehlen: Für die Sonntage 20.09., 27.09. und 04.10. steht jeweils nur die Auto-Anforderung (request … via=auto) im Protokoll, aber kein Start und kein Ergebnis. Die Snapshots dieser Wochen fehlen also vermutlich. Warum der Job dort nicht gestartet ist, sehe ich im Protokoll nicht. Auch auto.log zeigt nur die Jobs Scrub und Index. Der Snap-Job ist dort nicht aufgeführt.
  • Warnung: snaplib.pl warnt bei einer Version unter 1.3.0 nur, übergibt die Option aber trotzdem. Deshalb bricht der Lauf hart ab.

So behebst du es
  1. Unter About > CS Tools Download das Tool cs-freeze4snap auf dem Member proxmox_1 aktualisieren (Member wählen, „update“).
  2. Danach den Job einmal manuell starten und das Protokoll ansehen.

Ich hätte die Ursache ohne KI auch in 10 Min gefunden. Ein reiner Nutzer hätte wohl lange grübeln können bis er die Ursache und einfache Lösung gefunden hätte. Klar könnte man sagen, in einem Cluster sollte man immer alle Member updaten, nicht nur einzelne oder der job könnte Programmversionen prüfen. Gibt aber auch andere OS oder Storage Probleme die nicht so einfach sind wie dieses und man mehr Logfiles lesen muss und recherchieren wo so ein Problem schonmal beschrieben wurde. Genau da ist KI mit aktuellen Daten ein unschlagbbarer Helfer.
 
Benchmarks

Benchmarks sind etwas was man immer braucht, entweder um Probleme zu erkennen oder
die Leistungsfähigkeit zwischen Pools oder Plattformen zu beurteilen oder zu vergleichen.

Ein Benchmark sollte dabei nicht zu lange laufen (ca 2-30min) und nur wenige Basis Parameter haben, damit man ohne Informatikstudium etwas damit anfangen kann. Er sollte iops, sequential performance, sync write, concurrent read/write, single user vs 5 user und steady write (min 30min write) ermitteln können. Damit das auf jedem OS läuft, mache ich die Tests in Perl. Bei ultraschnellem Storage kann man dabei an Grenzen stossen, die werden als tool limited gekennzeichnet.

Das Tool ist in napp-it 4ai enthalten, läuft aber einfach auf jedem OS inkl. Windows, Linux, Unix
via perl ./benchmark_worker.pl pool=tank profile=basic
mit profilen quick|basic|database|fileserver|mediaserver|mailserver|steadywrite|individual

download: https://github.com/guenther-alka/cs-scripts/tree/main/benchmark

z.B Proxmox mit basic profil auf Pool nvme (single Optane)
perl /opt/csweb-gui/data/menues/_lib/scripts/bench/benchmark_worker.pl pool=nvme profile=basic

testfile: /nvme/csbench_auto_20261012_154528/bench_file.dat cap=2048MB
phase: create 4k test file (recordsize=4K)
phase: 4k random read (single stream)
phase: 4k random sync write (sync=always, recordsize=4K)
phase: create test file (recordsize=128K)
phase: sequential read (1MB, single stream, linear sweep)
phase: sync write (1MB blocks, sync=always)
phase: async write (1MB blocks, sync=standard) -- cache indicator
phase: concurrent read+write (5 readers + 5 writers)
phase: multiuser read (4k, 1 vs 5 streams)

Pool : nvme (dataset, nvme/csbench_auto_20261012_154528)
Profile : basic, 2048 MB test file, 5 streams, 143 s

File create
4k file : 1449.9 MB/s
Main file : 5423.6 MB/s

4k random read (1 stream)
IOPS : 79458
Throughput : 310.4 MB/s
Latency p50/p99 : 50 / 50 us
Class : partial

4k random sync write (1 stream)
IOPS : 16999
Throughput : 66.40 MB/s
Latency p50/p99 : 100 / 250 us
Class : storage-bound

Sequential read (1 stream)
Throughput : 2276.5 MB/s
Latency p99 : 2000 us
Class : storage-bound

Sync write (1 MB blocks)
Throughput : 1111.0 MB/s
IOPS : 1111
Latency p99 : 2.0 ms
Class : storage-bound

Async write (1 MB blocks, cache indicator)
Throughput : 1391.1 MB/s
IOPS : 1391
Class : cache-influenced

Concurrent read+write (5 readers + 5 writers)
Read : 375.6 MB/s (p99 100 us)
Write : 5.8 MB/s (p99 32.0 ms)
Class : storage-bound

Multiuser read (4k, 1 vs 5 streams)
1 stream : 310.4 MB/s
5 streams : 525.7 MB/s
5 streams : 134590 IOPS
Scaling : 1.69 x
Class : tool-limited

Verdict : partial
sync write 1111 MB/s p99 2.0 ms (storage-bound)
4k write 16999 IOPS p99 250 us (storage-bound)
4k read 79458 IOPS p99 50 us (partial)
seq read 2277 MB/s (storage-bound)

BENCH_DONE ok (142.721115112305s) log=/opt/csweb-gui/data/menues/_lib/scripts/bench/last_benchmark.log
root@pve:~#
 
zum Vergleich, eine ordentliche Sata SSD (Intel 3510)


Pool : ssd (dataset, ssd/csbench_auto_20261012_181600)
Profile : basic, 2048 MB test file, 5 streams, 152 s

File create
4k file : 1436.2 MB/s
Main file : 332.0 MB/s

4k random read (1 stream)
IOPS : 60046
Throughput : 234.6 MB/s
Latency p50/p99 : 50 / 250 us
Class : partial

4k random sync write (1 stream)
IOPS : 6276
Throughput : 24.52 MB/s
Latency p50/p99 : 250 / 250 us
Class : storage-bound

Sequential read (1 stream)
Throughput : 173.0 MB/s
Latency p99 : 16000 us
Class : storage-bound

Sync write (1 MB blocks)
Throughput : 106.0 MB/s
IOPS : 106
Latency p99 : 16.0 ms
Class : storage-bound

Async write (1 MB blocks, cache indicator)
Throughput : 147.3 MB/s
IOPS : 147
Class : cache-influenced

Concurrent read+write (5 readers + 5 writers)
Read : 93.9 MB/s (p99 4000 us)
Write : 0.0 MB/s (p99 2.0 ms)
Class : storage-bound

Multiuser read (4k, 1 vs 5 streams)
1 stream : 234.6 MB/s
5 streams : 125.0 MB/s
5 streams : 32008 IOPS
Scaling : 0.53 x
Class : storage-bound

Verdict : partial
sync write 106 MB/s p99 16.0 ms (storage-bound)
4k write 6276 IOPS p99 250 us (storage-bound)
4k read 60046 IOPS p99 250 us (partial)
seq read 173 MB/s (storage-bound)

BENCH_DONE ok (151.572777032852s) log=/opt/csweb-gui/data/menues/_lib/scripts/bench/last_benchmark.log
Beitrag automatisch zusammengeführt:

zum Vergleich, eine sehr schnelle Sata HD

Pool : hd (dataset, hd/csbench_auto_20261012_185137)
Profile : basic, 2048 MB test file, 5 streams, 150 s

File create
4k file : 1507.5 MB/s
Main file : 699.7 MB/s

4k random read (1 stream)
IOPS : 59105
Throughput : 230.9 MB/s
Latency p50/p99 : 50 / 50 us
Class : cache

4k random sync write (1 stream)
IOPS : 120
Throughput : 0.47 MB/s
Latency p50/p99 : 16000 / 32000 us
Class : storage-bound

Sequential read (1 stream)
Throughput : 158.4 MB/s
Latency p99 : 32000 us
Class : storage-bound

Sync write (1 MB blocks)
Throughput : 52.0 MB/s
IOPS : 52
Latency p99 : 64.0 ms
Class : storage-bound

Async write (1 MB blocks, cache indicator)
Throughput : 300.0 MB/s
IOPS : 300
Class : cache-influenced

Concurrent read+write (5 readers + 5 writers)
Read : 1.3 MB/s (p99 64000 us)
Write : 0.0 MB/s (p99 32.0 ms)
Class : storage-bound

Multiuser read (4k, 1 vs 5 streams)
1 stream : 230.9 MB/s
5 streams : 1.6 MB/s
5 streams : 409 IOPS
Scaling : 0.01 x
Class : storage-bound

Verdict : partial
sync write 52 MB/s p99 64.0 ms (storage-bound)
4k write 120 IOPS p99 32.0 ms (storage-bound)
4k read 59105 IOPS p99 50 us (cache)
seq read 158 MB/s (storage-bound)
note: cache values are cache speed, not a storage limit

BENCH_DONE ok (150.186470985413s) log=/opt/csweb-gui/data/menues/_lib/scripts/bench/last_benchmark.log
root@pve:~#
 
Zuletzt bearbeitet:
Was ist wo wichtig

VM Storage:
Hier zählt iops und sync write

SMB Storage für mehrere Nutzer
Hier zählt multiuser read und concurrent read/write

Mediaserver und Backup
Nur hier zählen sequential values
Bei mehr als einem Nutzer, immer multiuser read im Blick behalten
Bei Videoedit concurrent read/write beachten

Desktop SSD
- Hier kann man einen langlaufenden steady write Test zusätzlich machen,
um zu sehen wie stark die Schreibraten über der Zeit einbrechen,
- concurrent read/write zeigt gut ob eine SSD insgesamt was taugt.
 
Frage: Warum nicht fio zur Analyse?
Antwort: Fio ist ein Expertentool hauptsächlich für Linux. Man muss es installieren oder bauen, konfigurieren und verstehen.

Mein Script läuft ohne Installation oder Konfiguration auf jedem OS incl. Illumos/OmniOS/Solaris/Windows und liefert die Werte die mich am meisten bei Storage interessieren wie iops/ZFS sync, single user vs multiple user und concurrent read/write Werte, dazu Test Profile für besondere Use Cases wie steady write Verhalten bei Desktop SSD.

Einfach Starten und Vergleichen.
 
Ergänzung

Man kann nicht nur die reine Pool Performance schnell auf einem beliebigen OS testen ohne etwas installieren zu müssen, sondern mt der Option -remotepath z.B. n: bei Windows oder /mnt/smb zusätzlich auch ein lokales oder remote SMB/NFS/S3 share

z.B. lokales SMB Share auf NVMe (war lokaler Pool Test 1) um zu sehen was von der lokalen Pool Performance
über den SMB Server und den ip Stack ankommt:

Remote (cifs //127.0.0.1, SMB 3.1.1, Testdatei 31744 MB = 100 % RAM)
Seq write / read 1 MB 2098 / 2916 MB/s Client-CPU 53 % / 40 %
Seq write / read 64K 2092 / 3987 MB/s
4k read QD1 30408 IOPS, p50 0.05 ms, p99 0.25 ms
4k read QD4 / QD16 68809 / 75330 IOPS (p99 0.5 / 2.0 ms)
4k write QD1 1872 IOPS, p99 32 ms
Open/Close 117507 ops/s (Client-Cache)
Metadaten create 885/s, stat 178816/s (Cache), readdir 42729/s, delete 1467/s
Perl-Grenze (1 Stream) 233156 IOPS 4k, 14437 MB/s

ps
Auf Wunsch gehen auch echte Multi User Share Tests auf mehreren clients, manuell via Putty oder koordiniert via KI
 
Zuletzt bearbeitet:
Echtzeit ZFS Replikation mit cs-sync (any OS to any OS)

ZFS Replikation arbeitet normalerweise asyncron und jobbasiert. In einem Zeitraster z.B. jede Stunde wird ein Snap erstellt und dieser mit den geänderten Datenblöcken zu einem lokalen oder remote ZFS Ziel-Dateisystem übertragen um beide syncron zu halten.

Will man Echtzeit ZFS Replikation z.B. für Disaster Recovery muss man eventgesteuert arbeiten. Ein Write auf ein überwachtes ZFS Dataset löst den Replikationsvorgang sofort aus. Da dadurch die zu sendende Daten immer sehr klein sind und sehr schnell übertragen werden, ist die Verzögerung zwischen Änderung Source und Änderung Destination Dateisystem minimal. Es muss nur nach der Erstreplikation eine sinnvolle Verwaltung der Snap-paare erfolgen mit einem sinnvollen Timing bei stark belasteten Dateisystemen sowie ein resume nach Netzausfall oder reboot z.B. des Backupservers. Echtzeit ZFS Replikation ist vor allem bei VM Storage wie Proxmox sinnvoll. Da kommt filebasiertes sync schnell an seine Grenzen aufgrund der großen Dateien.

Bei Proxmox gibt es noch zwei Aspekte. Erstens liegt die VM-Konfiguration nicht im Dataset wie bei ESXi, sondern bei Proxmox in /etc/pve. Soll das in Echtzeit replizierte Dataset einer VM wiederhergestellt werden, ist die VM-Konfiguration nötig. Stellt cs-sync beim Start fest, dass die Quelle ein Proxmox-Host ist, liest es in jedem Zyklus die Konfigurationsdatei jeder VM bzw. jedes Containers, deren Disk-Datasets zum Sync gehören (nicht das ganze /etc/pve), und hängt sie als ZFS-User-Property cs:pveconf an das zugehörige Dataset und an jeden Sync-Snapshot. Die Property wird über das cs-sync-Protokoll mit zum Backup übertragen (nicht im zfs-send-Strom); eine reine Config-Änderung geht ohne neuen Send rüber.

Zweitens ist ein Snapshot in Proxmox nicht in allen Fällen konsistent, sondern quasi wie ein Stromausfall zu sehen, je nach VM unkritisch bis heikel. Cs-sync schickt deshalb auf einer Proxmox-Quelle den ersten Snapshot jedes Tages automatisch durch cs-freeze4snap, das die VMs des Quell-Datasets vor dem Snapshot einfriert (Guest Agent, Container-Freeze). Dieser Snapshot wird als kf<MMTT> auf beiden Seiten gehalten und mit cs:consistent=app markiert, bzw. mit paused, wenn eine VM nur angehalten werden konnte (dann weiter nur absturzkonsistent). Findet cs-sync cs-freeze4snap nicht (gesucht wird im selben Ordner wie cs-sync, im napp-it-Tools-Ordner und im PATH), wird der Freeze mit einer Warnung im Log übersprungen. An Tagen ohne Datenänderung entsteht kein neuer Snapshot. So gibt es zumindest einmal täglich einen sicher wiederherstellbaren Stand.

Das biesherige cs-sync bleibt
Ordner Primary <-> Secondary: Eventgesteuertes 2 Wege Sync z.B. Sync eines SMB Share mit einem NFS/S3 Share
Ordner Primary -> lokales oder Remote Backup: Echtzeit Sync, Filebasiert oder jetzt auch per ZFS send.

Neu: Manuals für alle cs-Tools
 
Anmelden, um zu antworten.

Ähnliche Themen

G
[Guide] napp-it cs, erste Schritte
2
Antworten
58
Aufrufe
6K
gea
G
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