napp-it cs webgui (copy and run, single/multi Server, beliebiges OS)
- Ersteller gea
- Erstellt am
- Registriert
- Dez. 2024
- Beiträge
- 150
RustFS S3 Server ist released
rustfs.com rustfs.com
Warum RustFS?
- 1:1 Ersatz für minIO, der bisherigen Hauptoption für ein inhouse/at home S3 Share (nur noch kommerziell verfügbar)
Warum überhaupt S3 shares, ich habe doch ZFS und SMB shares?
- ZFS ist ideal als gemeinsame Lan Ablage mit SMB. Man kann gemeinsam mit aktuellen Daten arbeiten und den Zugriff mit ACL regeln
Zugriff oder Freigabe der Daten im Internet ist aber ein Problem. Direktes Arbeiten über VPN + SMB ist zwar möglich, aber meist nicht sinnvoll wegen zu geringer Performance. Meist sollte man das Dokument erst herunterladen.
SMB im Internet ohne VPN ist ein nogo/ massives Sicherheitsleck, ideal ist Zugriff über authentifiziertes https so wie bei Cloud Providern wir Google. Genau das bietet S3. Da ist jede Datei eine Url im Internet, direkt herunterladbar per browser oder RustFS web-console (die auch hochladen kann). Alternativ kann man beliebige S3 Browser nehmen, als Einfachsten WinSCP im S3 Folder Modus.
Ein weiterer Aspekt ist Backup. Zwar bietet ZFS remote Replikation, das ist aber nicht realtime, benötigt ein spezielles Job Setup sowie VPN oder Tunnellösungen oder SSH als root. Mit S3 kann man einfach Backups übers Internet erstellen, entweder mit rclone (rsync for cloud) oder restic. Das verschlüsselt, dedupliziert und versioniert die Daten.
Realtime Backup
Ein weiterer Aspekt ist realtime Backup. Das bietet RustFS mit Realtime 2Wege Single Bucket Sync or Host Sync (alle Buckets). Dabei wird eventgesteuert jede Änderung auf einer oder der anderen Seite sofort auf dem Partner aktualisiert. Einmal eingerichtet, handhabt das RustrFS selber im Hontergrund
SMB +S3
Die beiden ergänzen sich ideal, SMB lokal und S3 als Share im Internet. Allerdings kennt S3 keine File ACL und kein File Locking, arbeitet immer auf Uer Basis (User hat Zugriff oder nicht. Ideale Ergänzung für SMB+S3 Shares ist eventgesteuertes bidir sync zwischen S3 und SMB. Damit erscheint jedes per SMB angelegte oder S3 hochgeladene Dokument sofort im anderen Share, https://github.com/guenther-alka/cs-sync
Setup in Napp-it
Vorab Dateisystem "pool"/s3_storage anlegen, dann
1. RustFS, rc, rclone und restic herunterladen (Menü Pool > S3 > local services)
2. Rustfs configurieren und starten
3. Cluster einrichten (mehrere RustFS) in Menü Pool > S3 > Remote Pool
Backup Jobs für rclone oder restic anlegen
Sync Service S3 <-> SMB anlegen (Menü Services)
https://www.napp-it.org/pdf/s3_storage_guide_de.pdf
Im Clustermodus werden S3 secrets und restic pw nur auf dem Frontend Management Server gespeichert, nicht auf den Cluster Members
rustfs.com rustfs.com
Warum RustFS?
- 1:1 Ersatz für minIO, der bisherigen Hauptoption für ein inhouse/at home S3 Share (nur noch kommerziell verfügbar)
Warum überhaupt S3 shares, ich habe doch ZFS und SMB shares?
- ZFS ist ideal als gemeinsame Lan Ablage mit SMB. Man kann gemeinsam mit aktuellen Daten arbeiten und den Zugriff mit ACL regeln
Zugriff oder Freigabe der Daten im Internet ist aber ein Problem. Direktes Arbeiten über VPN + SMB ist zwar möglich, aber meist nicht sinnvoll wegen zu geringer Performance. Meist sollte man das Dokument erst herunterladen.
SMB im Internet ohne VPN ist ein nogo/ massives Sicherheitsleck, ideal ist Zugriff über authentifiziertes https so wie bei Cloud Providern wir Google. Genau das bietet S3. Da ist jede Datei eine Url im Internet, direkt herunterladbar per browser oder RustFS web-console (die auch hochladen kann). Alternativ kann man beliebige S3 Browser nehmen, als Einfachsten WinSCP im S3 Folder Modus.
Ein weiterer Aspekt ist Backup. Zwar bietet ZFS remote Replikation, das ist aber nicht realtime, benötigt ein spezielles Job Setup sowie VPN oder Tunnellösungen oder SSH als root. Mit S3 kann man einfach Backups übers Internet erstellen, entweder mit rclone (rsync for cloud) oder restic. Das verschlüsselt, dedupliziert und versioniert die Daten.
Realtime Backup
Ein weiterer Aspekt ist realtime Backup. Das bietet RustFS mit Realtime 2Wege Single Bucket Sync or Host Sync (alle Buckets). Dabei wird eventgesteuert jede Änderung auf einer oder der anderen Seite sofort auf dem Partner aktualisiert. Einmal eingerichtet, handhabt das RustrFS selber im Hontergrund
SMB +S3
Die beiden ergänzen sich ideal, SMB lokal und S3 als Share im Internet. Allerdings kennt S3 keine File ACL und kein File Locking, arbeitet immer auf Uer Basis (User hat Zugriff oder nicht. Ideale Ergänzung für SMB+S3 Shares ist eventgesteuertes bidir sync zwischen S3 und SMB. Damit erscheint jedes per SMB angelegte oder S3 hochgeladene Dokument sofort im anderen Share, https://github.com/guenther-alka/cs-sync
Setup in Napp-it
Vorab Dateisystem "pool"/s3_storage anlegen, dann
1. RustFS, rc, rclone und restic herunterladen (Menü Pool > S3 > local services)
2. Rustfs configurieren und starten
3. Cluster einrichten (mehrere RustFS) in Menü Pool > S3 > Remote Pool
Backup Jobs für rclone oder restic anlegen
Sync Service S3 <-> SMB anlegen (Menü Services)
https://www.napp-it.org/pdf/s3_storage_guide_de.pdf
Im Clustermodus werden S3 secrets und restic pw nur auf dem Frontend Management Server gespeichert, nicht auf den Cluster Members
dideldei
Lt. Commander
- Registriert
- Dez. 2014
- Beiträge
- 1.140
Hallo,
zum Thema MinIO bzw. RustFS hätte ich eine oder mehrere Frage.
Ich nutze MinIO derzeit als S3-backend für eine selbst gehostete Anwendung und überlege, ob RustFS langfristig ein sinnvoller Ersatz wäre.
Hast du RustFS bereits als direkten Ersatz für MinIO in einer bestehenden Umgebung eingesetzt, bzw getestet?
Wie vollständig ist die S3-Kompatibilität in der Praxis?
Gibt es Funktionen oder API-Aufrufe, bei denen RustFS gegenüber MinIO noch Probleme macht?
Wie würdest du eine bestehende MinIO-Installation auf RustFS migrieren, bzw. einfach die Objekte übernehmen und die Anwendung anschließend auf den neuen S3-Endpunkt umstellen?
Siehst du RustFS inzwischen als produktionsreif für kleinere Selfhosted-Umgebungen?
Schönes WE an alle.
zum Thema MinIO bzw. RustFS hätte ich eine oder mehrere Frage.
Ich nutze MinIO derzeit als S3-backend für eine selbst gehostete Anwendung und überlege, ob RustFS langfristig ein sinnvoller Ersatz wäre.
Hast du RustFS bereits als direkten Ersatz für MinIO in einer bestehenden Umgebung eingesetzt, bzw getestet?
Wie vollständig ist die S3-Kompatibilität in der Praxis?
Gibt es Funktionen oder API-Aufrufe, bei denen RustFS gegenüber MinIO noch Probleme macht?
Wie würdest du eine bestehende MinIO-Installation auf RustFS migrieren, bzw. einfach die Objekte übernehmen und die Anwendung anschließend auf den neuen S3-Endpunkt umstellen?
Siehst du RustFS inzwischen als produktionsreif für kleinere Selfhosted-Umgebungen?
Schönes WE an alle.
- Registriert
- Dez. 2024
- Beiträge
- 150
Ich habe RustFS in napp-it integriert und getestet, auch mit Claude Unterstützung. Wo ich bis vor Kurzem Probleme hatte, war Bucket/Site Replication und selbstsignierte Zertifikate. Das geht jetzt. Für readonly Archiv Buckets oder ZFS Snaps habe ich einen Feature Request am Laufen, https://github.com/rustfs/rustfs/issues/8077
Meine bisherigen Bug und Feature Requests, z.B. für Unix/OmniOS Support, Replikation oder selbstsignierte Zertifikate wurden extrem schnell bearbeitet.
Bei der Zusammenarbeit mit restic oder rclone ist mir nichts negatives aufgefallen. Dir rc cli Console ersetzt die mc console von minIO. Bei der RustFS webconsole auf Port 9001 ist mir nichts negatives aufgefallen.
Für die Migration wird wohl rclone das Mittel der Wahl sein.
Für einen Test könnte man auch (falls ZFS) einen Clone des minIO Ordners anlegen und für RustFS nutzen.
Produktionreif?
Bei 1.0.0 releases ist da immer ein Fragezeichen. Ich würde mit Tests anfangen und bis zum vollständigen Wechsel 3-6 Monate warten wie die Rückmeldungen der anderen Nutzer sind,
https://github.com/rustfs/rustfs/issues
RustFS könnte sehr populär werden.
Meine bisherigen Bug und Feature Requests, z.B. für Unix/OmniOS Support, Replikation oder selbstsignierte Zertifikate wurden extrem schnell bearbeitet.
Bei der Zusammenarbeit mit restic oder rclone ist mir nichts negatives aufgefallen. Dir rc cli Console ersetzt die mc console von minIO. Bei der RustFS webconsole auf Port 9001 ist mir nichts negatives aufgefallen.
Für die Migration wird wohl rclone das Mittel der Wahl sein.
Für einen Test könnte man auch (falls ZFS) einen Clone des minIO Ordners anlegen und für RustFS nutzen.
Produktionreif?
Bei 1.0.0 releases ist da immer ein Fragezeichen. Ich würde mit Tests anfangen und bis zum vollständigen Wechsel 3-6 Monate warten wie die Rückmeldungen der anderen Nutzer sind,
https://github.com/rustfs/rustfs/issues
RustFS könnte sehr populär werden.
Zuletzt bearbeitet:
- Registriert
- Dez. 2024
- Beiträge
- 150
napp-it cs-team (ultralight "Nextcloud XXXS")
https://forums.servethehome.com/index.php?threads/napp-it-cs-team-ultralight-nextcloud-xxxs.56446/
https://forums.servethehome.com/index.php?threads/napp-it-cs-team-ultralight-nextcloud-xxxs.56446/
- Registriert
- Dez. 2024
- Beiträge
- 150
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
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
- Registriert
- Dez. 2024
- Beiträge
- 150
überarbeitete Manuals
napp-it: https://www.napp-it.org/pdf/napp-it-cs_de.pdf
cs-team v.0.61: https://www.napp-it.org/pdf/cs-team_de.pdf
napp-it: https://www.napp-it.org/pdf/napp-it-cs_de.pdf
cs-team v.0.61: https://www.napp-it.org/pdf/cs-team_de.pdf
- Registriert
- Dez. 2024
- Beiträge
- 150
Illumos ZFS und das daraus entstandene OpenZFS ist für Free-BSD. Linux und OSX released, fehlt eigentlich nur noch Windows für ein universelles NAS Dateisystem und das kommt immer näher
OpenZFS 2.4.4rc4 für Windows
https://github.com/openzfsonwindows/openzfs/releases/tag/zfswin-2.4.4rc4
*** rc4
Ganz Interessant ist die ZFS Snap Integration in den Windows Explorer, vor allem für Windows 11 da Microsoft hier VSS mit ZFS Snaps als "Vorherige Version" entfernt hat um die Server Versionen zu pushen wo das verfügbar ist.
OpenZFS 2.4.4rc4 für Windows
https://github.com/openzfsonwindows/openzfs/releases/tag/zfswin-2.4.4rc4
*** rc4
- Explorer integration exposing snapshot versions
- Fix "zfs diff"
- zfs_tray features
- Paging IO deadlock fix
- Fix BSOD related to SEQ
- zfs_inactive deadlock fix
Ganz Interessant ist die ZFS Snap Integration in den Windows Explorer, vor allem für Windows 11 da Microsoft hier VSS mit ZFS Snaps als "Vorherige Version" entfernt hat um die Server Versionen zu pushen wo das verfügbar ist.
Zuletzt bearbeitet:
- Registriert
- Dez. 2024
- Beiträge
- 150
Benchmarks (nicht nur für ZFS)
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:~#
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:~#
- Registriert
- Dez. 2024
- Beiträge
- 150
zum Vergleich, eine ordentliche Sata SSD (Intel 3510)
to compare a quite good 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
to compare a quite good 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
- Registriert
- Dez. 2024
- Beiträge
- 150
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.
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.
- Registriert
- Dez. 2024
- Beiträge
- 150
Echtzeit ZFS Replikation mit cs-sync (any OS to any OS)
https://www.napp-it.org/cs-tools.html
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
veconf 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
https://www.napp-it.org/cs-tools.html
https://www.napp-it.org/cs-tools.html
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
veconf 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
https://www.napp-it.org/cs-tools.html
- Registriert
- Dez. 2024
- Beiträge
- 150
Neue Version cs-team als add on (in napp-it oder standalone)
Single File (15MB) Kollaborations Tool auch für multikulturelle Arbeitsgruppen/Klassen
https://github.com/guenther-alka/cs-team/releases
Manual
https://www.napp-it.org/pdf/cs-team_de.pdf
Teil der cs-Tools
https://www.napp-it.org/cs-tools.html
Entwicklungsziel: Inhouse app mit 80% der wichtigsten MS365 Funktionen
mit Multiuser Text/Calc, Chat, iCal, Files, Aufgaben ohne Mail/Videoserver) bei 10% der Komplexität im Betrieb
Zielgruppe: Teams und multikulturelle Arbeitsgruppen/Schulklassen um gemeinsam Texte oder Kalkulationen zu bearbeiten
Betrieb: Ohne IT Abteilung, integriert in die napp-it 4ai web-gui, läuft aber auch Standalone (15MB single file app für jedes OS inkl. Windows oder Solaris), durch AI einfach selbst auditier- und erweiterbar.
neu in der aktuellen 0.63:
Versionshistorie (wer hat wann was bearbeitet)
Import von Versionen aus ZFS Snapjobs z.B. mit keep last 20 snaps mit delzero damit nur Snaps Änderungen bleiben.
Kommentare zu Texten oder Tabellenwerten
Neue Texte/pdf als Zusammenfassung oder durch Zusammenführen von txt/pdf
Neue Texte aus AI Recherche mit einstellbarer Detailtiefe (einfach, mittel,wissenschaftlich) inkl. Quellenübersicht mit Relevanz
Recherche in Muttersprache z.B. Türkisch oder Arabisch mit Übersetzung in Arbeitssprache z.B. de oder en
Auth gegen lokales pw oder Google/Microsoft/AD/Ldap
Pw reset per mail (Passwort vergessen)
Gruppen: Globaladmins, Groupadmins, Gäste
DSGVO Auskunft/Löschen mit Protokoll
dazu
leichter Jahrgangswechsel (Semester/Schulklassen mit Group rename oder User move)
13 Sprachen inkl. EU Sprachen, Arabisch, Türkisch, Ukrainisch, Russisch, Japanisch, Chinesisch
Single File (15MB) Kollaborations Tool auch für multikulturelle Arbeitsgruppen/Klassen
https://github.com/guenther-alka/cs-team/releases
Manual
https://www.napp-it.org/pdf/cs-team_de.pdf
Teil der cs-Tools
https://www.napp-it.org/cs-tools.html
Entwicklungsziel: Inhouse app mit 80% der wichtigsten MS365 Funktionen
mit Multiuser Text/Calc, Chat, iCal, Files, Aufgaben ohne Mail/Videoserver) bei 10% der Komplexität im Betrieb
Zielgruppe: Teams und multikulturelle Arbeitsgruppen/Schulklassen um gemeinsam Texte oder Kalkulationen zu bearbeiten
Betrieb: Ohne IT Abteilung, integriert in die napp-it 4ai web-gui, läuft aber auch Standalone (15MB single file app für jedes OS inkl. Windows oder Solaris), durch AI einfach selbst auditier- und erweiterbar.
neu in der aktuellen 0.63:
Versionshistorie (wer hat wann was bearbeitet)
Import von Versionen aus ZFS Snapjobs z.B. mit keep last 20 snaps mit delzero damit nur Snaps Änderungen bleiben.
Kommentare zu Texten oder Tabellenwerten
Neue Texte/pdf als Zusammenfassung oder durch Zusammenführen von txt/pdf
Neue Texte aus AI Recherche mit einstellbarer Detailtiefe (einfach, mittel,wissenschaftlich) inkl. Quellenübersicht mit Relevanz
Recherche in Muttersprache z.B. Türkisch oder Arabisch mit Übersetzung in Arbeitssprache z.B. de oder en
Auth gegen lokales pw oder Google/Microsoft/AD/Ldap
Pw reset per mail (Passwort vergessen)
Gruppen: Globaladmins, Groupadmins, Gäste
DSGVO Auskunft/Löschen mit Protokoll
dazu
leichter Jahrgangswechsel (Semester/Schulklassen mit Group rename oder User move)
13 Sprachen inkl. EU Sprachen, Arabisch, Türkisch, Ukrainisch, Russisch, Japanisch, Chinesisch
