zfs pools migrieren zwischen LXCs?

A

Astralix

Member
Proxmox Subscriber
Jan 18, 2025
57
7
8
Austria
Hallo erst mal, ich bin der Neue...

Mein alter Server hat den Geist aufgegeben und nachdem ich in den vergangen Jahren verschiedene Lösungen für meinen Sever zusammen gebastelt hatte, nutze ich den Storage Controller Ausfall, um alles mal aufzuräumen.

Das Problem ist, dass ich da eine Verständnisfrage habe, die speziell mich zu betreffen scheint...

ALTE Frage zum Verständnis meines Gedankengangs...

Ich habe eine große Audio und Video Sammlung, die ich noch eine ganze Zeit lang über einfach samba shares verwalten / aufräumen muss.
Gleichzeitig möchte ich sie aber über jellyfin verfügbar machen.

Auch bei dem Office-Dateien möchte ich über nextcloud, paperless und vorübergehend auch noch samba zugreifen können.

Ich habe einen zfs pool aus SSDs für das ganze system und die LXC / LXM. Läuft.
Dann gibt es einen zfs pool "datapool" auf dem soll alles and Dokumenten liegen, die Office shares, paperless und nextcloud betreffen
Und es gibt einen zfs pool "mediapool" auf dem sollen alle Audio- / Video-Dateien liegen, die in samba und jellyfin verfügbar sein sollen.

Nach meinem Verständnis kann ich auf einem pool beliebige subvolumes anlegen, die aber immer nur einer VM oder einem container zur Verfügung stellen.
Bei VMs bin ich mir nicht mal darüber sicher, denn normal wird immer dazu geraten die Drives oder das ganze PCIe Interface in die VM zu binden.
Das würde aber die Option unterwandern, eine proxmox Installation zu spiegeln?

Aber vielleicht bin ich auch nur zu ungeschickt mit zfs richtig umzugehen?
Meine ganzen alten Drives kann ich schließlich problemlos nach /mnt/old_data mounten und dann als bind-mount in die LXC verbinden.
Aber an ein "subvol-1023-disk-0" in das ich in samba etwas voreilig schon Daten geschaufelt habe, komme ich direkt im proxmox root nicht heran?

Final würde ich gerne meine Daten / Programme / Office / Musik u.s.w. trennen aber der Server kann nicht noch ein paar Jahre offline bleiben...

NEUE Frage:

Grundsätzlich ist es ja keine gute Idee, Daten mehrfach in offenen und geschlossenen Systemen zu streuen und vor allem unbewusst zu veröffentlichen.
Ein samba share, der parallel in Nextcloud sichtbar ist, das kann dumm enden. Andererseits ist es ja leicht möglich Daten aus einem samba share am PC bewusst in die Nextcloud zu kopieren oder in paperless abzulegen.

Bei den Videos und der Musik ist es im Grunde genau das selbe. Man kann die Sammlung aufräumen und gezielt in OMV oder Jellifin hochladen.

Aber... Hier kommt meine Verständnisfrage:
Ich habe ein zfs von ~24TB, darauf folgende raidz pools:
sambapool <- 16TB alte office, software, musik, video vom defekten RAID, als pool samba LCX zugeteilt.
cloudpool <- 4TB nextcloud daten von der alten nextcloud, als pool nextcloud LXC zugeteilt.
mediapool <- 4TB noch leer, da sollen ja ein Großteil der Daten aus sambapool hin, als pool jellifin LCX zugeteilt

Wie kann ich während der migration von videos und musik von sambapool nach mediapool den einen nach und nach verkleinern, während ich den anderen vergrößere?

Oder kann ich alle pools mit 24TB angeben und das zfs richtet das dann schon?

Vielleicht kann mir da jemand helfen? Danke!
 
Last edited:
Guten Morgen!

Zunächst muss ich mich entschuldigen, dass ich hier solche Anfänger-Fragen stelle, die in den ZFS Handbüchern schon recht früh behandelt werden. Leider arbeite ich hier unter Zeitdruck, denn mein Server muss wieder zurück an seinen Platz und der ist 500km entfernt. Daher lese ich parallel zu meinen Fragen hier auch das zfshandbook.

Es hängt sicher an grundsätzlichem Verständnis von ZFS, da ich bislang alles eher traditionell über Hardware RAID gemanaged habe.

Bash: 
root@tardis:~# zpool list -v
NAME                                         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
mediapool                                   43.6T  27.3T  16.3T        -         -     0%    62%  1.00x    ONLINE  -
  raidz1-0                                  43.6T  27.3T  16.3T        -         -     0%  62.6%      -    ONLINE
    ata-ST12000NE0008-2JL101_ZHZ5TZNZ       10.9T      -      -        -         -      -      -      -    ONLINE
    ata-ST12000NE0008-2JL101_ZHZ5WK34       10.9T      -      -        -         -      -      -      -    ONLINE
    ata-ST12000NE0008-2JL101_ZHZ5Z3NT       10.9T      -      -        -         -      -      -      -    ONLINE
    ata-ST12000NE0007-2GT116_ZJV69DSN       10.9T      -      -        -         -      -      -      -    ONLINE
rpool                                       2.72T  18.1G  2.70T        -         -     0%     0%  1.00x    ONLINE  -
  raidz1-0                                  2.72T  18.1G  2.70T        -         -     0%  0.65%      -    ONLINE
    ata-CT1000BX500SSD1_2435E98A4C02-part3   931G      -      -        -         -      -      -      -    ONLINE
    ata-CT1000BX500SSD1_2435E98A4BEF-part3   931G      -      -        -         -      -      -      -    ONLINE
    ata-CT1000BX500SSD1_2408E898FA2B-part3   931G      -      -        -         -      -      -      -    ONLINE
zprool status gibt zusätzlich nur aus, dass alles in Ordnung ist.

Mal sehen, ob ich langsam dahinter komme...
ZFS selbst erzeugt zunächst einen Pool auf den physikalischen Medien. Dieser Pool kann Grundeigenschaften mitbringen, wie Mirroring oder RAIDZx.
In meinem Fall habe ich rpool aus 3x SSD für boot, system und LXCs. Dann habe ich mediapool für alle alten Daten.

Auf diesen beiden Pools liegen Volumes, und daher ist meine Namensgebung missverständlich, denn der pool ist hier nach einem seiner zukünftigen Verwendungszwecke benannt, aber eben nur nach einem.

Ich muss also meine Aussage vom initialen Post korrigieren und die Planung anders darstellen?
mediapool bekommt verschiedene volumes:
- sambavolume -> Alles samba sharing
- cloudvolume -> alles nextcloud
- papervolume -> alles paperless
- mediavolume -> alles jellyfin oder omv

Aktuell liegt halt alles in sambavolume mit ca 20TB und muss nach und nach in die anderen Volumes verteilt werden. Damit würde samba volume nach und nach schrumpfen, während die anderen nach und nach wachsen.

Ein Missverständnis kann ich damit dann auch selbst aufklären, ich schrumpfe keinen Pool. Im Gegenteil, es ist zu erwarten, dass ich mehr Platten oder größere Platten in einen Pool stecke und das kann ZFS problemlos managen.

Die richtige Frage ist also, wie dynamisch sind die Volumes und wie leicht kann ich die in ihrer Größe in beide Richtungen verändern?
 
Astralix said:
Die richtige Frage ist also, wie dynamisch sind die Volumes
Click to expand...
Sehr! :)

Astralix said:
und wie leicht kann ich die in ihrer Größe in beide Richtungen verändern?
Click to expand...
Jedem Dataset und auch jedem ZVOL steht grundsätzlich der gesamte Platz des ZFS-Pools zur Verfügung.

* für ZVOLs (=block devices für die virtuellen Platten der VMs) wird bereits beim Anlegen eine Größe spezifiziert
* für Datasets gibt es zwei verschiedene "Quota"

Beide können on-the-fly geändert werden! Das ist einer der hypschen Fähigkeiten des ganzen ZFS Konstrukts. Natürlich ist "verkleinern" möglicherweise gefährlich...

Code: 
~# zfs list
NAME                            USED  AVAIL  REFER  MOUNTPOINT
...
rpool/data/subvol-2053-disk-0  7.87G  24.5G  7.47G  /rpool/data/subvol-2053-disk-0
rpool/data/vm-1118-disk-0      5.45G   261G  5.45G  -
Ersteres ist ein Dataset, also ein Filesystem, welches in diesem Fall auch gemountet wurde. Letzteres ist ein ZVOL, das kann der Host nicht ohne weiteres mounten, es hat kein direkt sichtbares Dateisystem. (Das legt ein Gast von "innen" heraus erst an.)

Code: 
~# zfs get all rpool/data/subvol-2053-disk-0 | grep -i quota
rpool/data/subvol-2053-disk-0  quota                 none                            default
rpool/data/subvol-2053-disk-0  refquota              32G                             received

~# zfs get all rpool/data/vm-1118-disk-0 | grep -i size
rpool/data/vm-1118-disk-0  volsize               8G                        local
 
  • Like
Reactions: Astralix
Guten Morgen,

ich beziehe mich auf das Bild: "A zpool is a collection of vdevs"

Quelle: https://klarasystems.com/articles/openzfs-understanding-zfs-vdev-types/

Im Fall zfs pool "mediapool" hast Du ein VDEV als RaidZ1 mit 4 HDDs (Seagate IronWolf Pro, NAS 12 TB) angelegt.

Zur Klärung in meinem Kopf es gibt ZFS Datasets und es gibt ZFS Volumes.
Diese kann man mit zfs list mediapool -t volume,filesystem -r anzeigen lassen.
Ein ZFS Volume ist ein Block-Device und diese liegen unter /dev/zvol/mediapool/...
Ein ZFS Dataset ist direkt eine Art ZFS "Partition" mit Filesystem.

Zum Handling und Datendurchsatz bei reiner HDD Nutzung, ändere ich noch folgende Parametrisierung:
* zfs set atime=off mediapool

Der Proxmox Backup Server benötigt auf seinem ZFS Pool zu seinem ZFS Dataset Backup:
* zfs set atime=on bsapool/backup

ZFS Pools, hier mediapool, müssen einen Quota auf dem obersten Dataset, von ca. 80% der maximalen Größe haben.
* zfs get quota mediapool
* zfs set quota=35T mediapool

Rechnung:
* 43,6 TByte * 0,80 = 34,88 TByte
aufgerundet 35 TByte

Aber man könnte auch schhreiben 34.9T
* zfs set quota=34.9T mediapool

Ich runde im Bereich von 80 % - 85 % das ZFS Top-Level Quota.

Selbst habe ich schon mehrfach bei ein ZFS Pool mit einem VDEV, z.B. ZFS Mirror (Raid1), die darunter liegenden Datenträger gegen gegen größere ausgetauscht.

Der erste Schtritt ist das Austauschen jedes einzelnen Datenträgers gegen, hier einen größeren Datenträger.

Stichwort: "zfs replace disk"

Anm.: Dazu gibt es bei einem ZFS Mirror noch ein anderes Vorgehen, als bei Austausch eines Datenträgers bei einem ZFS RaidZ1.

Wenn die Daten auf das neue Medium übertragen wurden (resilver), kann man den alten Datenträger entfernen.

Sind alle alten/ kleinen Datenträger durch neue/ größere ersetzt worden, kann man den ZFS Pool in seiner Gesamtheit vergrößern.

Einige Commands:
* zpool get autoexpand mediapool
* zpool set autoexpand=on mediapool
* zpool set autoexpand=off mediapool

* zpool set autoexpand=on <pool>
funktioniert nicht immer alleine, dann ist dies noch notwendig:
* zpool online -e <pool> <new-device-id>

Erfolg hatte ich dann, indem ich mit Hilfe von cfdisk jede ZFS Partition - aller neue Datenträger - auf sein maximum erweiterte.
* zpool set autoexpand=on <pool>
* zpool online -e <pool> <new-device-id>
* zpool set autoexpand=off <pool>

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-online.8.html

Zum sicheren Kopieren von Daten auf ein neuen ZFS Pool gibt es zfs send <pool1>/<dataset1> | zfs recv <pool2>/<dataset2>

# https://openzfs.github.io/openzfs-docs/man/master/8/zfs-send.8.html
# https://openzfs.github.io/openzfs-docs/man/master/8/zfs-recv.8.html

Du kannst z.B. ZFS Pool "mediapool" um einen weiteren VDEV RaidZ1 erweitern:
zpool add mediapool raidz1 <new-device0> <new-device1> <new-device2> <new-device3>

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-add.8.html

Bei einem ZFS Mirror (Raid1) kann man noch auf ein weiteres Vorgehen zurückgreifen.
Bsp. man hätte erstellt: zpool <pool> mirror <new-device0> <new-device1>

Dann kann man über zpool attach <pool> <old-deviceX> <new-device2>
einen weiteren gespiegelete Datenträger einhängen.

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-attach.8.html
# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-detach.8.html

ZFS Special Device
Noch eine Anmerkung zu ZFS Metadaten, alle meine ZFS Pools, die HDDs enthalten, haben auch noch einen SDD VDEV mit der selben Organisation der HDD VDEV erhalten, und dienen fortan als ZFS Special Device.

Bsp. ZFS RaidZ1 mit 3x HDD, benötigt dann eine ZFS Mirror (!) mit 3x SSD für die Ausfallsicherheit.

Ein ZFS Special Device kann man immer nachträglich noch dazunehmen, nur nicht (nie) mehr entfernen!
Hier liegen fortan alle Methadaten des ZFS Datei und Filesystems.
Die Größe des ZFS VDEV Special Device auf SSD Basis erweitert dann auch noch den Speicherpool.

# https://openzfs.github.io/openzfs-docs/man/master/8/zpool-add.8.html

HDD Blocksize 4 kByte (zpool get ashift <pool>, für HDDs i.A. 12 == 2¹² Byte)
ZFS Recordsize 128 kByte
ZFS Volblocksize 4k o. 8k o. 16k

Wird auf einem Dataset ein klein Datei (touch <file>) angelegt, so müssen u.a. 128 kByte / 4 kByte = 32 Blocknummern gespeichert werden. Die Checksummen und die weiteren Metadaten unbeachtet.

Eine Datei mit 1 Gbyte benötigt schon 262144 Blocknummern.
Bei Lesen muss auf alle Diese Informationen zugegriffen werden, und hier konnkurieren dann die Zugriffe bei HDDs auf die Metadaten und die Datenzugriffe miteinander.
Ein SSD ZFS VDEV als Special Device ist dann schon eine Paralellisierung und entlastet die langsammen HDDs sehr.
Stichwort ist hier Randowm 4k R/W IOP/s, die ich für die Rechnung mit 100 IOP/s für HDD annehme.
Wenn eine SSD (SATA3) nun 100.000 IOP/s erreicht, dann ist das schon 100x mehr und auch die maximale Datenübertragung mit ca. 550 MByte/s ist schneller.

So sieht man schnell, ein ZFS Special Device muss bei HDD Nutzung, vorhanden sein.
 
Last edited:
  • Like
Reactions: Astralix and UdoB
Okay, das ist natürlich ne Menge Info! danke Euch Beiden!

Code: 
root@tardis:~# zfs list
NAME                            USED  AVAIL  REFER  MOUNTPOINT
mediapool                      19.2T  9.79T  1023K  /mediapool
mediapool/subvol-1049-disk-0   19.2T  9.79T  19.2T  /mediapool/subvol-1049-disk-0
rpool                          12.1G  1.74T   139K  /rpool
rpool/ROOT                     4.25G  1.74T   128K  /rpool/ROOT
rpool/ROOT/pve-1               4.25G  1.74T  4.25G  /
rpool/data                     7.42G  1.74T   160K  /rpool/data
rpool/data/subvol-1031-disk-0  2.19G  1.81G  2.19G  /rpool/data/subvol-1031-disk-0
rpool/data/subvol-1032-disk-0  1.20G  2.80G  1.20G  /rpool/data/subvol-1032-disk-0
rpool/data/subvol-1033-disk-0  1.11G  98.9G  1.11G  /rpool/data/subvol-1033-disk-0
rpool/data/subvol-1048-disk-0  1.97G  6.03G  1.97G  /rpool/data/subvol-1048-disk-0
rpool/data/subvol-1049-disk-0   970M  7.05G   970M  /rpool/data/subvol-1049-disk-0
rpool/var-lib-vz                367M  1.74T   367M  /var/lib/vz
root@tardis:~#

Ich habe auf dem mediapool ein ca 20TB großen Volume angelegt und kopiere innerhalb des samba LXC die Daten um.
Da ich von einem traditionellen RAID auf ein neues ZFS kopiere, verwende ich rsync.

Dass man pools nicht nur vergrößern sondern mit anderen pools kombinieren kann, ist praktisch zu wissen! Ich bin noch am Planen, ob ich einen Server mit vielen Bays kaufe oder einen schlanken Server und mehrere storage Bays kombiniere. Aber das ist Zukunft.

Frage 1)
ashift habe ich für den mediapool auf 32k gesetzt, da ich dachte, dass das das Handling von im Allgemeinen immer she großen Daten vereinfacht. Videos sind ja immer recht riesig.
Den Pool für die Dokumente und Dateien von Nextcloud werde ich auf einem weiteren HDD pool bauen, hier werden hauptsächlich kleinere Datenblöcke verwalten werden. Dokumente halt. Dieser Pool setzt sich dann aus den HDD zusammen, die durch den Abbau des physikalischen RAID frei werden.

Frage 2)
ZFS special Device: Verstehe ich (noch) nicht. Klar wären Metadaten auf einem schnellen Medium perfekt, aber ich habe nur noch einen SATA Anschluss frei und es bleibt am Ende nur eine 512er SSD übrig. Wie berechne ich die Größe, denn den Pool erweitern muss es ja nicht. Ich habe schon gesehen, dass es da SLOG gibt. Auch sind die Infos, ob und was man da verwenden soll sehr unterschiedlich. Aber die Dokumentationen sind auch sehr unterschiedlich alt.

Aktuell wollte ich für den Tower-Server noch keine weiteren HBA kaufen, da das alte Gigabyte Board nur einen PCIe-16x Slot hat und ich da den LSI 9260-8i drin stecken habe. Den kann man nach meiner Recherche nicht auf HBA / IT Mode umflashen. Einen LSI 9400-16i will ich aber (noch) nicht kaufen, da diese andere Kabel haben und langfristig ein Epyc Serverboard geplant ist. Da ist es dann sinnvoller mehrere 8i HBA einzusetzen und damit eine Ausfallsicherheit zu gewährleisten. Und in einem Tower-Gehäuse brennen die LSI Controller früher oder später ab, da sie für einen mächtigen Luftstrom ausgelegt sind, der in Servergehäusen durch viele Lüfter quer durch das Gehäuse gedrückt wird, in einem Tower aber nahezu nicht existent ist.
 
Last edited:
Dann noch ein weitere Gedanke mit einem Hardwarevorschlag:
# https://forum.proxmox.com/threads/e...dware-zu-meinem-proxmox-ve.160851/post-740188

So könntest Du ein NAS für deine großen Datenmengen aufbauen:.
* 2x NVMe PCIe 3.0 oder 4.0,
* hast 1x 2.5 GBit/s Netzwerk und
* die 8x SATA3 Ports, 4x SATA3 CPU, 4x SATA3.
* Über einen SATA 3 - Adapter/ Controller, kann man das Mainboard noch um weitere 6x SATA 3, über PCIe 3.0 x2, erweitern.

# SilverStone SST-ECS06, Serial ATA-Controller

Ja kostet etwas Geld, und funktioniert bei mir in zwei AMD Systemen mit CPU und APU im PCIe 3.0 x16 oder x4 Slot.

Das Biostar B760MX2-E Pro D4 bildet dann die Basis für dein NAS und Du könntest den ZFS Pool mit 3x VDEVs (ZFS Special Device) oder 4 VDEVs (ZFS Special Device und ZIL/SLOG) aufbauen:
1) VDEV-0 ZFS RaidZ1 4x HDD, IOP/s 100
2) VDEV-1 ZFS RaidZ1 4x HDD, IOP/s 100
3) VDEV-2 ZFS Mirror 3x SSD 500 GByte (SATA 3), SSD Partition-1 mit ca. 450 GByte
4) VDEV-3 ZFS ZIL/SLOG RaidZ1 3x SSD 500 GB (SATA 3), SSD Partition-2 mit ca. 32 GByte
5) SATA 3 Anschlüsse: (4+4+6)-4-4-3 = 3 (spare)

Das könnte in Schritten erfolgen:
a) VDEV-0 ZFS RaidZ1 4x HDD
b) VDEV-1 ZFS Mirror 3x SSD 500 GByte (SATA 3), SSD Partition-1 mit ca. 450 GByte
c) VDEV-1 ZFS ZIL/SLOG RaidZ1 3x SSD 500 GB (SATA 3), SSD Partition-2 mit ca. 32 GByte

anlegen und die Daten vom alten System mit ZFS Pool "mediapool" übertragen, z.B. rsync -avP <local-src> <remote-dest> [--delete].
So landen schon alle Metadaten auf den SSDs.

Dann den Pool mediapool aus dem Poxmox VE entfernen, aushängen und zerstörren.
zpool destroy mediapool
Dann noch für alle HDD Disks des alten Pools mediapool:
wipefs -a <dev-id>
Dann kann man schon die HDDs physisch ausbauen und umziehen lassen.

Ich nutze die Device-Bezeichnungen unter: /dev/disk/by-id/... für die HDDs.
zpool add <pool> raidz1 <new-device0> <new-device1> <new-device2> <new-device3>

SATA 3 SSD, die man auch einfach beschaffen könnte:
# Kingston DC600M 480 GB, SSD

Dem NAS würde ich mindestens 32 GByte, besser 64 GByte DDR4 Arbeitsspeicher, zuweisen.
Dann kann ZFS auf auf sein Ram-Cache setzen.

Mit einer weiteren 2.5 GBit/s Netzwerkkarte, in einem der PCIe 3.0 x1 Slots, könnte man eine LACP (Link Aggregation) über beide Netzwerkkarten aufbauen, und so eine Lastverteilung/ Ausfallsicherheit erreichen.

# https://www.alternate.de/Netzwerkkarten
# https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlagen

Wer sich nun Fragen sollte, wo kann ich die ganzen HDDs und SSDs verbauen?
Erhält mit diesem 2HE Gehäuse eine Basis:
# Inter-Tech 2U 20248, Server-Gehäuse
 
Last edited:
  • Like
Reactions: Astralix
Ja die Hardware...

Im Sommer ändere ich das mit Supermicro Server Brett und 32 core Epyc + 256GB RAM, später dann redundant und auf dem Gelände verteilt als Mirror.
LACP und ähnliches sind mir bekannt. Der Grund ist, dass ich einige VMs mit hoher Datenverarbeitung ( SDR Software defined radios) darauf laufen lassen möchte. Eventuell trenne ich aber auch noch mal interne Systeme und externe Systeme oder Storage, Hosting und Internal... Später!

Aktuell steht nur ein AMD A8 APU auf einem alten Gigabyte GA-A75-D2H zur Verfügung mit 6x on Board SATA und nur 2 DRAM Slots...
Auf dem Board stecken aktuell 16GB DRAM (DDR3 1.5V) und ja, anscheinend wurden nie größere Riegel für diesen Speicher-Typ hergestellt als 8GB. Da ich nur zwei Slots habe, ist das nun mal nicht zu ändern. Ich gebe aber jetzt keine 500€ aus für eine Zwischenlösung.

Um aus dem vorhandenen Brett das Maximum herauszuholen habe ich erst mal nur folgendes zur Hand:

1) 4xSATA PCIe-1x Controller mit 3x 1TB SSD für proxmox system root und storage für die LXC / VM

2) 6xSATA on Board Controller
-> 4x SATA on Board, da hängt aktuell das neue ZFS drauf (4x 12TB HDD)
-> 1x SATA on Board, alte SSD mit rootfs und VMs vom ursprünglichen Server. (1x 512GB SSD)
-> 1x SATA on Board, alte HDD mit Daten vom alten Server (1x 4TB HDD)

Mechanisch hat das Gehäuse jetzt einen icy dock tough armor mit 4x 2.5" SSD/HDD cages für 1) und 8x 3,5" HDD cages mit SATA/SAS backplane.
im icy-dock sind die drei SSDs für system.
4x SATA sind belegt für die 12TB, sobald das physikalische RAID leer kopiert ist.

Das icy dock hatte ich schon mal gekauft, da man dieses auch in vielen 3U supermicro rack-server cases einbauen kann. So hätte ich das System einfach umstecken können.

Aber ausgehend von der Situation und dem Unwillen noch mehr Geld in die nur vorübergehende Konfiguration zu stecken...
Was mache ich mit der 512GB SSD, damit diese sinnvoll eingesetzt wird? Als cache soll man sie ja nicht verwenden, die haben dann keine wirklich hohe Lebenserwartung.
 
Bei TrueNAS war ich nicht sicher, ob das auf LXC / volumes läuft. Viele Beschreibungen leiten ganze PCIe Slots nach TrueNAS um, damit das die Verwaltung machen kann. Nach meinem Verständnis kann man aber keine proxmox Skalierung / Spiegelung mehr machen, wenn VMs hart selbst ihren Storage verwalten.

Generell sehe ich als Neueinsteiger ein Problem im "nichts vergessenden Internet", dass man immer wieder auf Beschreibungen, Vorgaben und fehlende Lösungen trifft, die aber schon lange veraltet sind. Auch bei der Installation von proxmox + nginx-proy-manager und Nextcloud bin ich einem irren Wust an sctripten und komplexen reverse proxy Lösungen aufgesessen, bis ich drauf kam, dass man nur zwei Optionen setzt in der proxy config Webseite und einen Eintrag in der Nectcloud Config. Quasi 6h Googeln und basteln, dann feststellen, dass es in 2 Minuten eigentlich fertig gewesen wäre...

Und da dieser Eintrag nun ebenfalls als Suchergebnis auftauchen wird, wenn man proxmox und nextcloud und nginx-proxy-manager sucht, hier der Link zu der Seite, die mir das in Minuten ans Rennen gebracht hat:
https://www.c-rieger.de/nginx-proxy-manager-mit-nextcloud/

Zu meinem rpool:
Ich migriere aktuell noch von einer alten Konfiguration auf eine neue!
D.h. es stecken noch alte Disks am Mainboard SATA und auch noch alle 4TB Platten am LSI 9260-8i RAID controller.

Also noch einmal zur Planung:

rpool
--> ist mein Storage für das System und Datenbanken. So viel Datenbanken wird es nicht geben und bisher hat dazu eine 450GB Partition völlig ausgereicht. D.h. ein 3TB raidz1 pool mit der Option auf ein weiteres 1TB im leeren Schacht sollte da für die nächste Zukunft ausreichen. Alle VMS / LXC legen hier ihre systeme, configs und datenbanken ab. Pro VM oder LXC liegt hier also ein subvolume.

mediapool
--> Hier liegen alle Daten im Sinne von realen Median Dateien. Also Filme, Musik, Video-Archiv aus dem Labor, vielleicht schaffe ich es mal auf YouTube ;)
Damit ist klar, hier werden zwei subvolumes liegen, einmal das unsortierten Krams, der über samba erreichbar ist und noch per Davinci geschnitten oder aus dem hobbylabor hochgeladen wird.
Außerdem liegt hier ein Jellyfin subvolume für die Medien, die man in der Familie sharen möchte.

datapool
--> Nachdem das alte 5x 4TB RAID leer kopiert habe, werde ich davon 4 Platten in ein RAIDZ pool überführen.
Hier wird es dann zwei subvolumes geben, eines für die Nextcloud und eines für Paperless.

Die Migration ist also so:
Alles von den alten Platten nach mediapool/subvolume-samba/
Alte Platten sinnvoll re-integrieren in zpools oder caches oder wasauchimmer.
Alte Daten von mediapool/subvolume-samba/ in die zuständigen LXC überführen.

Am Ende bleibt dann die oben genannte Sortierung übrig. Und es bleiben 2x 4TB HDD und eine 512GB SSD übrig. Und nur für letztere ist noch ein Slot da.
 
Danke noch mal für Deine Geduld!

Ich glaube, wir sprechen über zwei unterschiedliche Netz-Strukturen oder Datenhaltungsweisen...

Mein bisheriger Aufbau war ein Server mit einem RAID5 für Massen an wichtigen und unwichtigen Daten.
Dazu eine UPS oder APU, wie auch immer man einen Satz Batterien mit 230V Ausgang nennen mag.
Neben dem RAID noch ein paar Platten mit super wichtigen Daten in der Nextcloud.

Die Redundanz der Nextcloud kam dadurch, dass jede Datei mindestens noch einmal auf einem der Nextcloud Clients lokal gespiegelt war.
So konnte man mit vorhandenem PC Material aus der Bastelkiste und einem RAID Controller eine zuverlässige Infrastruktur bauen.
Stirbt eine RAID Platte, hätte ich mich ins Auto gesetzt und wäre die Platte tauschen gefahren, wäre die Nextcloud gestorben, hätte ich alle Rechner in eine neu aufgesetzte NC zurück gespiegelt.

Und diese Struktur hat sich etabliert. D.h. es gibt nur zwei Leute, die noch Daten unter samba haben. Alles andere ist in der Nextcloud oder eben in zukünftigen Diensten wie jellyfin.

Samba wird bleiben, auch wenn fast alle Rechner auf Linux umziehen oder umgezogen sind. Denn ich habe einige Messgeräte, die nur mit samba shares klar kommen und ihre Messergebnisse dort ablegen können. Auch habe ich noch die ein oder andere Windows XP VM für Messgeräte Software oder Update Tools. Dazu noch eine aktuelle Windows 11 VM für mein Steuerprogramm.

Aber das ganze Dokumenten-Management läuft nun seid 5 Jahren ca auf Nextcloud. Paperless soll nun dazu kommen. Aber samba wird es nur noch für mich und die Messgeräte geben. Und dazu habe ich, weil ich das schon lange so mache, einfach ein minimales Debian LXC aufgesetzt und darin manuell eine smb.conf so eingerichtet, dass es zwei User hat, und nun ziehe ich gerade die rüber kopierten RAID Daten in ihren Berechtigungen gerade.
Um da nicht zu stolpern habe ich passende Gruppen unter proxmox selbst und dem LXC angelegt, so dass diese übereinstimmen und ich auch aus der unprivileged VM alle Dateioperationen durchführen kann. ( gruppe family GID 1001 auf Debian --> gruppe family GID 101001 auf proxmox)

Nun weißt Du, wie es dazu kam, dass es so ist, wie es ist. Was würde sich für mich durch TrueNAS verändern oder verbessern? Was übersehe ich?
Ich bin da offen!
 
@Astralix ja Gedanke war, eine anderes Datenmanagement, alles Zentral auf einem eigenen externen NAS, auf fast aktueller Hardware mit einem modernen Betriebssystem.
So ist das zukünftige Management und Erweiterbarkeit auch gegeben.
 
Hatte schon über unifi NAS nachgedacht da ich diese zentral managen kann. Die 6er Bays kosten vergleichsweise wenig und sind über 10GB SFP+ schnell angebunden.
Trotzdem verstehe ich nicht, was TrueNAS mir verwaltungsmäßig an Vorteilen bietet.
 
So langsam kapiere ich das!
TrueNAS als reines Storage und die proxmox volumes über schnelles LAN von extern angebunden.
Dann wiederum würde aber proxmox unter dem TrueNAS keinen Sinn machen.

Ich muss mir TrueNAS einfach mal ansehen, was es kann.
 
Ja jetzt ja!

Also einfache sparsames Board was 6 bis 8x SATA plus cache NVMe unterstützt und das gerade schnell genug ist um 2x 10GB SFP+ zu bedienen.

Aber mein Gedankenknoten ist da ein anderer... Wenn ich zwei proxmox habe, die sich replizieren, dann stelle ich die in zwei unterschiedliche Gebäude und habe 100% Funktion, wenn der eine oder der andere ausfällt.

Wenn ich TrueNAS und proxmox verwende, habe ich entweder VMs ohne Daten oder Daten ohne VMs...

Also müsste man zur Rettung der Daten immer noch 2x TrueNAS aufbauen und an unterschiedlichen Orten unterbringen und muss trotzdem noch Backups zurück sichern, damit wieder alles läuft.

Trotzdem ist das Konzept eine Berechnung wert. Wenn ich 2x 25W trueNAS laufen habe und 1x 120W proxmox, dann ist das weniger als 2x 120W proxmox... Wobei 120W Mindestlast bei einem Dual-Epyc system war. Ich werde erst mal mit einem Single Epyc starten. Das sollten dann < 100W werden.
 
Guten Abend,

mein Ansatz bezog sich auf deine Ausführungen bzgl. deinem ZFS Pool "mediapool".
Der Basiert auf einem ZFS RaidZ1 mit 4 HDDs liegt:
Code: 
raidz1-0     43.6T  27.3T  16.3T        -         -     0%  62.6%      -    ONLINE
    ata-ST12000NE0008-2JL101_ZHZ5TZNZ        10.9T      -      -        -         -      -      -      -    ONLINE
    ata-ST12000NE0008-2JL101_ZHZ5WK34       10.9T      -      -        -         -      -      -      -    ONLINE
    ata-ST12000NE0008-2JL101_ZHZ5Z3NT        10.9T      -      -        -         -      -      -      -    ONLINE
    ata-ST12000NE0007-2GT116_ZJV69DSN       10.9T

Dort hattest Du einen ZFS Volume über Proxmox VE angelegt "subvol-1049-disk-0" und an die VM 1049 gebunden.
Dort kann sie als direkter Speicher verwendet werden.

Code: 
mediapool 19.2T  9.79T  1023K  /mediapool<br>mediapool/subvol-1049-disk-0   19.2T  9.79T  19.2T  /mediapool/subvol-1049-disk-0

Da Du, nach meinem Eindruck, expandieren möchtest, ist es für mich klar, alle Daten aller VM wandern auf eine externes NAS, dass man unter TrueNas betreiben könnte.
Freigaben von ZFS Datasets und als Verzeichnisse sind in TrueNas einfach über die GUI zu managen.

Ein Protokoll wäre Samba, Cifs im lokalen Netz über die Netzwerk-Schnittstelle. NFS und iSCSI werden auch noch unterstützt.
So sind alle Daten zentral an einer Stelle.
Mit dem im Vorschlag genannten Biostar B760MX2-E Pro D4 Mainboard mit 1x 2.5 GBit/s on Board.

Die LXC oder VM laufen nun auf einem kleineren Proxmox VE Server, dass z.B. mit 2x 1 TB SSD (SATA3) auskommt.
# Kingston DC600M 960 GB, SSD

Hier kann man auch den Proxmox VE Server installieren und einfach die benötigte Rechenleistung und Strombedarf skallieren.

Backups kann man dann auch oder u.a. auf das Nas in einem eigene Bereich ablegen.
 
Last edited:
Okay...

Spielen wir das mal durch...
1) Der Server den ich habe ist eine semi-produktive Spielwiese und kann völlig außen vor bleiben.
2) Ein Backup, das im gleichen Gebäude liegt wie die originalen Daten kein Backup.
3) Es wird recycelte aber keine uralte Hardware verwendet.

Wenn ich Deine Ideen und meine mische, dann komme ich auf folgendes Konzept:

2x TrueNAS mit reinen Datenvolumen, gespiegelt, eines beim proxomox server, eines woanders auf dem Gelände.
1x Proxmox VE Server mit lokalen schnellen NVMe für System, VM, Caching.

Daten lagern auf den TrueNAS, Proxmox macht regelmäßige Backups und Snapshots auf die TrueNAS.
In der Konfiguration darf immer ein TrueNAS und der Proxmox selbst zerstört werden, ohne dass es einen Datenverlust gibt.

Zur Hardware:
Ich bin ein Fan von recycelter Ware, aber nicht älter als eine oder zwei Generationen zurück. Denn gerade in den letzten Jahren habt sich die Rechenleistung vervielfacht und der Stromverbraucht enorm reduziert. Ich finde das BIOSTAR Board super günstig, aber es passt nicht in das Konzept.
Für die TrueNAS werde ich MiniITX Boards einsetzen, die in 19" Storage Gehäuse mit mind. 14 Slots passen.
Für den Proxmox werde ich unter einem 32 Core Epyc nicht anfangen. Dafür laufen am Ende doch zu viele VMs darauf.

Für die Protokolle zur Anbindung des Proxmox an die TrueNAS muss ich mich mal schlau machen, NFS wäre da meine Wahl.

Mal sehen...
 
  • Like
Reactions: Johannes S and news
So, meine ersten ZFS reliability tests sind dann schon mal unfreiwillig am Laufen.
Da ist tatsächlich eine der Platten ausgestiegen und ich warte auf neue. Sollen in Kürze kommen.

Frage dazu:
Wenn man mehrere Pools oder Tanks aus verschieden großen Platten hat, also Pool1 aus 4x 21TB und Pool2 aus 3x 4TB, kann man dann statt je eine weitere Platte als RAIDZ2 auch eine gemeinsame Hotspare einrichten?

Weitere Frage zu Proxmox:
Ich hatte kurz bevor die Platte starb, schon meinen Mail Account eingerichtet, damit ich Warnungen bekommen kann. Allerdings scheint es nicht zu reichen, da den Default Eintrag mit einem gültigen SMTP Account zu verbinden. Denn die Test-Mails kommen alle wunderbar durch, aber eine Warnung zu der Platte habe ich nicht erhalten. (Auch nicht im SPAM)
 
Uns ist nicht klar wie deine VDEV für dein ZFS Poll zusammen hängen.

Wenn man mehrere Pools oder Tanks aus verschieden großen Platten hat, also Pool1 aus 4x 21TB und Pool2 aus 3x 4TB, kann man dann statt je eine weitere Platte als RAIDZ2 auch eine gemeinsame Hotspare einrichten?
Click to expand...

Aus 4x 21 TB? kann man 2x VDEV als ZFS Raid1 - Mirror anlegen und diese als ZFS Pool mit VDEV-0 - stripe - VDEV-1 oder ZFS Pool mit VDEV-0 - Mirror - VDEV-1 zusammen "bauen".
Auch könnte das VDEV als ZFS RaidZ1 oder als ZFS RaidZ2 definiert sein.
Ein VDEV mit ZFS RaidZ3 aus 4 HDD ist eher selten.

Aus den 3x 4TB Datenträgern, kann man z.B. ein VDEV als ZFS RaidZ1 mit 3 Datenträgern oder ein VDEV ZFS Raid1 - Mirror auf 3 Datenträgern erzeugen.
Ein austausch Datenträger hat mindestens die Größe des auszutauschenden defekten Datenträgers des betroffenen VDEV zu haben. Puh ich hoffe es wird klar.
 
Last edited:
  • Like
Reactions: Johannes S
Vielleicht schiebe ich noch ein Beispiel hinterher:
Sei
a) VDEF-0 als ZFS Mirror auf 2x 500 GB Datenträgern definiert
b) VDEF-1 als ZFS Mirror auf 2x 500 GB Datenträgern definiert
c) Der ZFS Pool tank wird aus einem ZFS Stripe aus VDEF-0 und VDEF-1 gebildet.

Da alle Datenträger mit 500 GB gleich groß sind, kann man in jeden VDEV-n jeden der Datenträger damit austauschen.
Hätte man nun einen 1000 GB großen Datenträger, so würde man eine Partition mit 500 GB erzeugen und wäre auch schon am Ziel.

Was auch geht, hatte ich mal erzeugt eine VDEV-x mit 2 Datenträgern als Stripe-1, der dann die Größe eines Datenträgers eines VDEV-y hatte und dies konnte dann auch verwendet werden.
 
Last edited:
You must log in or register to reply here.
Top Bottom