Wie funktionieren Mount point - backed storage

[floh8]

Ihr schreibt in der Doku zu Containern über Storage Backed Mount Points mit 3 Varianten. Die erste funktioniert automatisch, wenn ich einen Mountpoint einrichte. Wie kann ich die 3. Variante nutzen? Damit meine ich die, die als "Directory" benannt ist. Könnt ihr ein Beispiel geben? Und welche Storage-Backends werden überhaupt unterstützt?​

Danke.

 

[ph0x]

Puh Junge, im Business sollte man aber schon wissen, wie bind mounts in Containern funktionieren ...

 

[floh8]

Bitte mal ein Beispiel. Die Doku ist zum Teil sehr unklar. Danke.

 

[dcsapak]

Wie kann ich die 3. Variante nutzen? Damit meine ich die, die als "Directory" benannt ist. Könnt ihr ein Beispiel geben? Und welche Storage-Backends werden überhaupt unterstützt?

bin mir gerade nicht sicher welche '3. variante' du meinst, kannst du auf die doku verlinken ?

wenn du 'bind mounts' meinst, das beispiel aus der doku (https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pct_settings)
ist doch ziemlich klar:

For example, to make the directory /mnt/bindmounts/shared accessible in the container with ID 100 under the path /shared, use a configuration line like mp0: /mnt/bindmounts/shared,mp=/shared in /etc/pve/lxc/100.conf. Alternatively, use pct set 100 -mp0 /mnt/bindmounts/shared,mp=/shared to achieve the same result.

mp0: /pfad/zum/dir/am/host,mp=/pfad/im/gast

 

[floh8]

die bind mounts habe ich gelesen, aber ihr schreibt ja im wiki: Container images

volume=<volume>
Volume, device or directory to mount into the container.

Currently there are three types of mount points: storage backed mount points, bind mounts, and device mounts.

Typical container rootfs configuration
rootfs: thin1:base-100-disk-1,size=8G

Storage Backed Mount Points​

Storage backed mount points are managed by the Proxmox VE storage subsystem and come in three different flavors:

• Image based: these are raw images containing a single ext4 formatted file system.
• ZFS subvolumes: these are technically bind mounts, but with managed storage, and thus allow resizing and snapshotting.
• Directories: passing size=0 triggers a special case where instead of a raw image a directory is created.

Wenn ich also beim mount-Befehl in der ct.conf bei volume=volume angebe, meine ich damit "

Storage Backed Mount Points"? Wenn ich nun size=xx angebe, wird ein image erzeugt. Wenn ich size=0 angebe, ein subvolume oder directory wird angelegt? Wie sehen Beispiele aus?​

zu image based: da wird 'nen raw-image erzeugt und als ext4 eingebunden. Wenn ich nun aber nicht ext4 haben möchte?
welche feature habe ich hier? Clonen, snapshot,etc..

zu Directories: hier habe ich direkten Zugriff auf das Filesystem dahinter wie bei bind mounts? Was ist der Unterschied zu bind mounts? Welche Feature habe ich?

Es wäre schön, wenn ihr an der Stelle im Wiki einfach auch mal eine Vergleichstabelle der unterschiedlichen Features und Beispiele für das Einbinden hinterlegt. Dann kommen auch nicht so viele Fragen oder nur von mir .

 

[dcsapak]

ah ok jetzt versteh ich

Storage Backed Mount Points"? Wenn ich nun size=xx angebe, wird ein image erzeugt. Wenn ich size=0 angebe, ein subvolume oder directory wird angelegt? Wie sehen Beispiele aus?

genau, wird eine size angegeben, wird ein volume erzeugt (wie auch immer das für den storage aussieht, ext4 raw file für directory, zfs subvolume, etc)
wird size=0 angegeben wird ein directory (auf directory basierenden storages) oder ein subvolume (zb zfs) erzeugt

dieses directory/subvolume verhält sich eig genauso wie ein bindmount, ist aber von pve erzeugt (zb für unprivileged container mit den korrekten uids/gids)

zu image based: da wird 'nen raw-image erzeugt und als ext4 eingebunden. Wenn ich nun aber nicht ext4 haben möchte?
welche feature habe ich hier? Clonen, snapshot,etc..

ist im moment immer ext4, obwohl wir schon mal überlegt haben das konfigurierbar zu machen (hat jedoch nur selten vorteile...)
features hängen immer vom storage ab. auf directory basierten storages können nur qcow2 snapshots (die für container nicht verfügbar sind)

zu Directories: hier habe ich direkten Zugriff auf das Filesystem dahinter wie bei bind mounts? Was ist der Unterschied zu bind mounts? Welche Feature habe ich?

wie bereits oben erwähnt sind das grundsätzlich bind-mounts

 

[floh8]

bring doch bitte mal für jeden der 3 unterpunkte ein beispiel für die ct.conf! danke

 

[floh8]

also ich habe mal versucht alle Varianten nachzustellen, aber ich habe es nicht hinbekommen, weil mir einfach mal die syntax fehlt - in eurer Doku.
was man konstatieren kann, ist:

Proxmox hat nur das in die GUI aufgenommen, was für den Produktivbetrieb sinnvoll ist. D.h. man nutzt entweder eine mage-Datei unter einem FS ohne snapshot-Feature oder man hat ZFS, LVM oder Ceph und kann snapshots nutzen. Damit klärt sich automatisch das ID-Mapping-Problem, das ich z.B. beim nomalen Bind Mapping habe.
Dazu brauch man nichts beachten, denn das StorageSubsystem von Proxmox entscheidet automatisch, ob es nun ein Subvolume oder eine image-Datei anlegen muss.
Falls jemand auf die Idee kommen sollte und ich bin einer davon, einen Fileserver im Container zu betreiben, dann macht es nur mit Snapshot-Möglichkeit, weil sonst das Backup ewig dauert.
Da Proxmox aus für mich noch unerklärlichen Gründen die Snapshot-Funktion von GlusterFS nicht unterstützt, muss man für dieses Cluster-Filesystem eben VMs benutzen.
Auch Container werden auf GLusterFS nicht unterstützt. Man muss den Umweg über ein Dir-Mapping (oder NFS) gehen. Habe ich getestet, geht wunderbar.

Fazit:
Wenn du GlusterFS mit Proxmox nutzen möchtest, verabschiede dich davon Container intensiv einzusetzen. Wenn DRBD für xcp-ng fertig ist, ist xcp-ng eine interessante Alternative für Proxmox, wenn man HCI machen will. Sicherer ist Xen ja sowieso .

 

[ph0x]

Sicherer ist Xen ja sowieso .

Und diese steile Behauptung gründet worauf genau?

 

[floh8]

mal wieder das internet in zweifel ziehen was? das ist allerdings schon fast grundwissen für hypervisor.

 

[ph0x]

Na, wenn's im Internet steht, wird's wohl stimmen.

 

[floh8]

du kannst dir natürlich auch ein Buch ausleihen, dann haste es auf Papier

 

[floh8]

ah ok jetzt versteh ich


genau, wird eine size angegeben, wird ein volume erzeugt (wie auch immer das für den storage aussieht, ext4 raw file für directory, zfs subvolume, etc)
wird size=0 angegeben wird ein directory (auf directory basierenden storages) oder ein subvolume (zb zfs) erzeugt

dieses directory/subvolume verhält sich eig genauso wie ein bindmount, ist aber von pve erzeugt (zb für unprivileged container mit den korrekten uids/gids)


ist im moment immer ext4, obwohl wir schon mal überlegt haben das konfigurierbar zu machen (hat jedoch nur selten vorteile...)
features hängen immer vom storage ab. auf directory basierten storages können nur qcow2 snapshots (die für container nicht verfügbar sind)


wie bereits oben erwähnt sind das grundsätzlich bind-mounts

ich beziehe mich auf deine Aussage qcow2 wäre für container nicht verfügar. Guckst du hier: https://www.howtoforge.com/tutorial/how-to-setup-virtual-containers-with-lxc-and-quota/

!!!! Bitte implementiert das !!!!! ich weiß, das macht Aufwand, aber das würde euer Produkt so dermaßen aufwerten, denn das Storagebackend wäre ja unabhängig von snapshots und subvolumes. Dann könnte man neben Ceph noch andere Clusterfilesysteme nutzen, die dann Deduplizieren können z.B. Ach wäre das geil.