Virtualisierung oder Container - Eure Meinungen

[Shutterfly]

Moin moin,

mich würde aus gegebenem Anlass einmal eure Meinungen zum Thema Virtualisierung und Container interessieren. Was bevorzugt ihr? Wieso? Wieso gerade nicht?

Ich persönlich betreibe auf meinem Home-Server mit Arch-Linux sowohl VMs über KVM, als auch einige Docker-Container. In den Containern habe ich teilweise Kleinzeug wie z.B. einen munin server oder einen nginx reverse proxy. In den VMs schlummern spezielle Kandidaten wie seafile (wo ich keine Docker-Instanz haben wollte) oder pfsense (was aufgrund FreeBSD nicht geht).

Ein Container-Kandidat habe ich bislang unerwähnt gelassen: GitLab samt Mattermost. Und dieser Kandidat hat mich die Tage zur der Frage hier gebracht.

Grundsätzlich finde ich Docker bzw. Container ganz interessant bzgl. Schonung der Ressourcen. Während KVM erst einmal den vollen RAM für eine VM reserviert, obwohl vielleicht 70% nur in Spitzen benötigt werden, können bei guter Planung Docker-Container viel dynamischer den RAM teilen, da sie alle aus dem gleichen Pool schöpfen. Was natürlich auch Nachteile haben kann, wenn man das Nutzungsverhalten nicht kennt und nicht sauber planen kann.

Was mich jedoch gerade im Fall von GitLab nun ins Grübeln gebracht hat, ist der Umstand, dass Container viel umständlicher zu sichern sind (im Hinblick auf Snapshots) als eine VM per KVM. Hier ist ein Snapshot schnell erstellt, man kann ein Major-Update von GitLab machen und im Zweifelsfall ein Rollback. Bei Docker im speziellen geht so etwas zwar auch, ist jedoch viel mit etwas mehr Fummeln verbunden. Es fühlt sich einfach nicht so smooth wie bei KVM an.

Da ich demnächst einmal Pi-hole anstatt des pfsense dns resolvers probieren möchte, stehe ich wieder vor der Frage: Baue ich mir ein Dockerfile selbst (mit unbound gibt es leider keins direkt, was mir gefällt) oder baue ich eine neue VM mit ansible.

Und daher wollte ich mal in die Runde fragen wie ihr so entscheidet, wann welche Technik oder gerade eine spezielle Technik nicht genutzt wird. Erfahrungen und allgemeine Meinungen sind natürlich ebenso willkommen

PS: Sollte dies doch eher in den Bereich "Software" gehören, dann bitte ich um Entschuldigung

 

[sweetchuck]

Grundsätzlich finde ich Docker bzw. Container ganz interessant bzgl. Schonung der Ressourcen. Während KVM erst einmal den vollen RAM für eine VM reserviert, obwohl vielleicht 70% nur in Spitzen benötigt werden, können bei guter Planung Docker-Container viel dynamischer den RAM teilen, da sie alle aus dem gleichen Pool schöpfen. Was natürlich auch Nachteile haben kann, wenn man das Nutzungsverhalten nicht kennt und nicht sauber planen kann.

In der Firma verwenden wir LXC-Container, die den selben Unterbau wie Docker haben. Dort kann man per Parameter angeben, wie viel RAM oder Kerne der Container maximal verwenden darf. Ich würde einfach mal erwarten, daß Docker das auch kann.

Was mich jedoch gerade im Fall von GitLab nun ins Grübeln gebracht hat, ist der Umstand, dass Container viel umständlicher zu sichern sind (im Hinblick auf Snapshots) als eine VM per KVM. Hier ist ein Snapshot schnell erstellt, man kann ein Major-Update von GitLab machen und im Zweifelsfall ein Rollback. Bei Docker im speziellen geht so etwas zwar auch, ist jedoch viel mit etwas mehr Fummeln verbunden. Es fühlt sich einfach nicht so smooth wie bei KVM an.

Ich würde hier mal das Stichwort ZFS einwerfen.

 

[Shutterfly]

In der Firma verwenden wir LXC-Container, die den selben Unterbau wie Docker haben. Dort kann man per Parameter angeben, wie viel RAM oder Kerne der Container maximal verwenden darf. Ich würde einfach mal erwarten, daß Docker das auch kann.

Vielleicht habe ich mich unglücklich ausgedrückt aber genau diese Regeln will ich bei Docker bzw. Containern nicht haben. Hier soll jeder nehmen, wie er mag, da das System derzeit nie eine 100%ige Auslastung bei CPU oder RAM hat.

Was mich gerade stört ist, dass bei VMs über KVM der RAM-Ressourcen vollständig blockiert werden. Overcommitting ist bei KVM leider nicht so problemlos möglich wie bei ESXi.

Ich würde hier mal das Stichwort ZFS einwerfen.

ZFS ist aufgrund vieler Dinge für mich derzeit keine Option. Fängt schon mit der Problematik einer echten Verschlüsslung an, wo man dann sehr spezielle Betriebssysteme verwenden müsste, und hört bei der notwendigen Investition für mehr Platten, welche ich derzeit nicht tätigen will, auf.

 

[bytegetter]

Mehrere Seafile-Instanzen (und deren Backups dazu) laufen hier unter Proxmox als LXC. Sogar auf einem ollen N36L Microserver. Performance ist ausreichend schnell.

 

[eldiabolo18]

Vielleicht habe ich mich unglücklich ausgedrückt aber genau diese Regeln will ich bei Docker bzw. Containern nicht haben. Hier soll jeder nehmen, wie er mag, da das System derzeit nie eine 100%ige Auslastung bei CPU oder RAM hat.

Was mich gerade stört ist, dass bei VMs über KVM der RAM-Ressourcen vollständig blockiert werden. Overcommitting ist bei KVM leider nicht so problemlos möglich wie bei ESXi.

Glaub mir, du willst Ressourcebeschraenkung haben. Das klingt komisch, solange bis ein Container amok lauft und den ganzen Host wegreisst. Sowas ist Best-Practice. Fuer docker-compose gibt es bis yaml Version 2.4 die Moelgichkeit cpu/ram limit etc. anzuegeben, das tut ganz gut den Zweck. Muss man halt vorher mal eben gucken wie der Service so Ressourcen braucht und es dann einstellen.

Ich hab selber auch Container und VMs. Allerdings betreibe ich ich meine Container IN VMs. Das ist der absolute Traum. Ich kann zb KVM Snapshots und Backups machen, ich kann das ganze Dockersystem auf nen anderen Host migrieren. Letztens habe ich meinen KVM-Host neu installiert. Ich hab drei qcow2-images und XMLs (fuer meine drei docker instanzen) gesichert, neu installiert, KVM installiert, angeworfe und Docker liefer alles wieder. War der smoothest Workflow seit langem.

ZFS ist aufgrund vieler Dinge für mich derzeit keine Option. Fängt schon mit der Problematik einer echten Verschlüsslung an, wo man dann sehr spezielle Betriebssysteme verwenden müsste, und hört bei der notwendigen Investition für mehr Platten, welche ich derzeit nicht tätigen will, auf.

Das stimmt nicht ganz. Du kannst ganz normal ZFS verwenden mit einer Disk und dann alle Vorteile inkl. zB. Snapshots und auch Verschluesselung (keine Ahnung von welchen speziellen Betriebssystemen du redest) seit v0.8.X. Einfach mal bisschen schlau machen. ZFS ist eigentlich easy fuer den Heimgebrauch, insbesondere mit wenigen Platten.

Es gibt aber auch Dinge, die man nicht wirklich in Dockercontainer werfen will, zB. nen DHCP-Server (wenn man jetzt mal Pi-Hole o.Ae. fuer den Heimgebrauch weglaesst), da ist dann einfach ne VM mal notwendig.

 

[tolga9009]

Ich bin starker Container-Verfechter und denke, dass man Container grundsätzlich den VMs immer vorziehen sollte, wann immer es möglich ist. pfSense ist z.B. nicht möglich und da gibt es keine andere Wahl. Aber bei so Sachen wie GitLab bietet sich ein Container sehr gut an.

Wichtig: Container heißt nicht immer Docker. Es gibt privileged und unprivileged. Und es gibt Anwendungs-Container und System-Container. Ich setze ausschließlich nur unprivileged System-Container ein und nutze dafür systemd-nspawn, welches bei jeder Linux-Distri mit systemd automatisch dabei ist. LXD wäre die Alternative. Aktuell habe ich u.a. Arch Linux, CentOS und Debian Container im Einsatz. Vorteil: ich muss nur ein paar Kleinigkeiten beachten, der Rest ist fast identisch zu einem vollwertigen VPS. D.h. ich kann pacman / apt / yum benutzen, SSH Login usw.; im Endeffekt läuft alles wie in einer VM auch, nur leichtgewichtiger und schneller. Ein voller systemd Reboot bis zur Login-Shell z.B. dauert etwa 2 - 3 Sekunden.

Als Unterbau habe ich Arch Linux mit BTRFS. Auf dem Host ist außer den Basics (Netzwerk-Tools, rsync, ssh usw.) nichts installiert. Wenn ich z.B. einen Nextcloud Container erstellen will, benutze ich "machinectl clone centos nextcloud" und anschließend "machinectl start nextcloud". Das Klonen dauert nicht einmal eine Sekunde und nimmt keinen Speicherplatz in Anspruch (BTRFS Snapshot). Der geklonte Container "nextcloud" beinhaltet bereits alles: root-Passwort bereits gesetzt, eigenständige IP per DHCP, SSH-Keys kopiert, Firewall, sodass ich direkt SSH'en und loslegen kann. Von hier aus läuft die Installation wie auf einem ganz normalen VPS auch und ich kann mich zu 99,9% an die Anleitungen im Internet halten.

Da die Container im Grunde nur BTRFS Subvolumes darstellen, kann ich mit dem Tool "snapper" mir von ausgewählten Containern (Nextcloud, Samba) eine Timeline erstellen lassen, um Ransomware bzw. User-Error abzufangen. Der Command dafür ist ein Einzeiler: "snapper -c nextcloud create-config /var/lib/machines/nextcloud". Es werden dann die letzten 3 Stunden, 3 Tage, 4 Wochen und 3 Monate als Snapshot vorgehalten (konfigurierbar). Du kannst natürlich auch manuell Snapshots erstellen (und löschen): "snapper -c nextcloud create --description 'vor Upgrade auf 19.0'".

Das tolle an System-Containern ist, dass ich mich mit den Konzepten von Anwendungs-Containern und Docker & Co. nicht auseinandersetzen muss, aber dennoch die ganzen Vorteile mitnehmen kann. Die Container sind über eine Netzwerkbrücke direkt mit dem Netzwerk verbunden und besitzen eine eigene Firewall und eigene IP. Ich arbeite wie in einer stinknormalen VPS, habe alle Tools parat, wie all die Jahre zuvor auch. Die Hauptarbeit besteht darin, einmalig System-Container einzurichten, da es zumindest bei systemd-nspawn keine vertrauenswürdige, gute Quelle für Images gibt (gibt es bei LXD allerdings).

Das Backup bedarf keiner besonderen Aufmerksamkeit: das Root-Verzeichnis des Hosts wird 1:1 per rsync kopiert und fertig. Da die systemd-nspawn Container als BTRFS Subvolumes vorliegen, kann der Host auf alle Dateien der Container ganz normal zugreifen (mit root-Rechten), als wären es ganz normale Unterordner. Wenn sich also eine kleine Log-Datei in einem Container ändert, zieht rsync nur diese einzige Log-Datei rüber. Wenn ein neuer Container hinzukommt, wird dieser inkrementell rüberkopiert, wie sonst ein normaler Unterordner auch.

Die Kombination aus systemd-nspawn und BTRFS wird auch bei Facebook eingesetzt. Nachteil ist, dass es für sowas keine GUI gibt und daher nicht massentauglich ist. Für mich funktioniert es jedoch prima und das Ergebnis kann sich auch sehen lassen: mit aktuell ca. 8 vollwertigen System-Containern (5x Arch Linux, 1x Debian, 2x CentOS, u.a. laufen GitLab, Nextcloud, LDAP, DLNA, Samba, PostgreSQL, Redis, Image-Server) komme ich auf ca. 0.03 CPU Load Average im Idle und ~600MB (von 16GB) RAM Auslastung.

Ich habe auch bereits Offline-Migrationen von Containern vollzogen: "machinectl export-tar", auf Webserver packen und dann auf dem anderen Host "machinectl pull-tar". LXD kann das etwas besser und unterstützt auch Live-Migration von Containern.

Das einzige, wo ich vorsichtig mit Containern wäre, sind Anwendungen, wo du privileged Container brauchst. Das sollte man nur mit LSM (SELinux, AppArmor) laufen lassen oder direkt in einer VM. Ich bevorzuge hier VM, da unter Arch Linux die manuelle Konfiguration von AppArmor aufwendig ist. Wenn aber Ubuntu als Host mit LXD zum Einsatz kommt (und ZFS als Dateisystem) oder z.B. Proxmox, sollte das Out-of-the-Box direkt konfiguriert sein und keine Gefahr darstellen.

 

[Shutterfly]

So, leider hatte die Antwort etwas gedauert.

Das stimmt nicht ganz. Du kannst ganz normal ZFS verwenden mit einer Disk und dann alle Vorteile inkl. zB. Snapshots und auch Verschluesselung (keine Ahnung von welchen speziellen Betriebssystemen du redest) seit v0.8.X. Einfach mal bisschen schlau machen.

Mit speziellen Betriebssystemen meine ich alle, welche das "echte" ZFS einsetzen und Verschlüsslung ohne Probleme beherrschen (z.B. Solaris). Schaue ich jedoch Richtung OpenZFS, dann sehe ich hier noch einige bestätigte Performance-Probleme. Zum Beispiel: https://github.com/openzfs/zfs/issues/9458 Bei meiner Recherche bin ich häufiger auf Beiträge gestoßen, wo Leute über so etwas berichtet haben.

Wichtig: Container heißt nicht immer Docker. Es gibt privileged und unprivileged. Und es gibt Anwendungs-Container und System-Container. Ich setze ausschließlich nur unprivileged System-Container ein und nutze dafür systemd-nspawn, welches bei jeder Linux-Distri mit systemd automatisch dabei ist. LXD wäre die Alternative.

Vielen Dank für diesen Hinweis. Ich kannte nspawn tatsächlich noch nicht und finde die Idee bzw. das Prinzip tatsächlich ansprechend. Könnte für mich ein schönes Mittelstück zwischen Docker, welches für reine einfache Applikationen meiner ersten Recherche nach noch einfacher aussieht, und vollwertigen VMs sein, wo ich aufgrund von fremden Architekturen (wie FreeBSD) daran gebunden bin.

Wenn ich es richtig verstanden habe, dann werden die Dateisysteme der Container als ganz normale Verzeichnisse auf dem Dateisystem abgelegt und könnten dann einfach gesichert werden. Ist das korrekt @tolga9009? Gilt dies nur für BTRFS? Von BTRFS würde ich persönlich nämlich noch Abstand halten, da mir das System bislang noch nicht fertig genug ist [1] [2]. Außerdem ist die Umstellung meines Systems nun nicht einfach so möglich, weswegen ich keine Lust auf Experimente habe.

Was ich für mich jedenfalls noch einmal recherchieren muss ist der Aspekt der Sicherheit gegenüber VMs.

[1] https://btrfs.wiki.kernel.org/index.php/Status
[2] https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F

 

[tolga9009]

Wenn ich es richtig verstanden habe, dann werden die Dateisysteme der Container als ganz normale Verzeichnisse auf dem Dateisystem abgelegt und könnten dann einfach gesichert werden. Ist das korrekt @tolga9009? Gilt dies nur für BTRFS?

Genau. Im Sinne von systemd-nspawn ist ein Container ein ganz normaler Ordner, der das Root-Verzeichnis des Gast-Systems enthält. Wenn du denselben Ordner nach "/var/lib/machines" verschiebst, kann dann auch machinectl damit umgehen. machinectl ist hier nichts besonderes: es ist einfach nur ein Front-End, um die Handhabung zu vereinfachen. Du kannst ganz nach UNIX-Philosphie statt "machinectl clone archlinux meinklon" auch "cp --recursive /var/lib/machines/archlinux /var/lib/machines/meinklon" ausführen und die Container mit dem Tool "systemd-nspawn" starten.

Ein BTRFS Subvolume präsentiert sich auch als "ganz normaler Ordner", weshalb das hier so gut Hand in Hand geht.

Um einen Arch Linux Container zu erstellen, führst du (wie bei der normalen Installation auch) folgenden Befehl aus: "pacstrap /var/lib/machines/archlinux base". Diese Dateien gehören root:root und du kannst auf diesen Dateien ganz normal zugreifen.

Ein COW Dateisystem (wie BTRFS) bringt einpaar Features mit, die die Handhabung von Containern stark verbessern. Es funktioniert aber prinzipiell auch ohne BTRFS. Dann wird bei einem Klonvorgang eben der komplette Ordner "ohne COW" kopiert - also wird ein ~700MB großer Ordner copy-pasted. Bei COW geht das in Bruchteilen einer Sekunde und nimmt paar Kilobytes in Anspruch, bei ext4 auf ner normalen Festplatte dauert das dann halt etwas länger (viele kleine Dateien) und nimmt nochmal extra 700MB in Anspruch. Wenn du nicht 5 Container hast, sondern 30, macht sich das irgendwann schon bemerkbar. Desweiteren weiß ich nicht, inwiefern COW beim Caching hilft, kann mir aber vorstellen, dass es positive Effekte hat.

Wenn dir BTRFS zu heikel ist (die Info finde ich persönlich veraltet, aber anderes Thema), kann ZFS und XFS auch COW. Bei ZFS und XFS bin ich mir allerdings nicht sicher, ob "machinectl" damit automatisch umgehen kann. Ein manuelles "cp --reflink=always" sollte aber nach wie vor funktionieren.

 

[asche77]

Natürlich kann ZFS Clones: https://docs.oracle.com/cd/E19253-01/819-5461/gbcxz/index.html

Interessant sind auch die zones von OmniOS (bzw joyent), nicht nur aber auch die LX zones.

 

[martingo]

Ich würde mal folgendes ins Feld führen:
- Proxmox Host
- LXCs für die Brot-und-Butter Anwendungen wie pihole, Webserver etc
- VMs für Nicht-Linux-Systeme wie Windows DC, Windows 10 Wartungs VM und aus Sicherheitsgründen abzutrennende Appliances wie VPN AC
- VM für Docker Container, sofern solche benötigt werden (Docker direkt auf Proxmox aufzusetzen ist möglich, aber nicht empfohlen)

 

[tolga9009]

Natürlich kann ZFS Clones: https://docs.oracle.com/cd/E19253-01/819-5461/gbcxz/index.html

Ich glaube, du hast dich mit dem Thread vertan. Hier wurde nie was anderes behauptet.

@martingo ich weiß nicht, ob es mit LXC läuft (müsste eigentlich), aber Docker kann man in einem systemd-nspawn Container laufen lassen. Dazu /sys/fs/cgroup als rw Bind-Mount durchreichen und den Container privileged laufen lassen. Funktionierte ohne weitere Basteleien direkt auf Anhieb und inklusive Networking.

 

[martingo]

@tolga9009 : was meinst Du, was Du nicht weißt, ob es mit LXC läuft?

 

[Shutterfly]

Ich würde mal folgendes ins Feld führen:
- Proxmox Host

Proxmox ist mir zu limitierend bzw. sperrig von den Möglichkeiten. Und bei komplizierten Dingen muss man eh auf die Konsole, da kann ich auch gleich direkt bei Arch bleiben, wo ich neben LXC/LXD und KVM auch noch Docker, nspawn, klassisches chroot oder in wilden Tagen sogar rkt nutzen könnte.

Und da ich gerne auf der Shell arbeite und, wie oben schon angemerkt, OpenZFS noch nicht nutzen möchte, macht Proxmox für mich keinen Sinn.

Grundsätzlich hat es mit meiner eigentlichen Frage "Virtualisieren oder Container" recht wenig zu tun

 

[sweetchuck]

@martingo ich weiß nicht, ob es mit LXC läuft (müsste eigentlich), aber Docker kann man in einem systemd-nspawn Container laufen lassen.

Docker in LXC geht ebenfalls.

 

[tolga9009]

@sweetchuck Perfekt!

@Shutterfly nspawn und LXD brauchst du nicht nebenher laufen lassen, da es im Grunde genommen fast dasselbe ist. Ich würde mich für das entscheiden, womit du besser klar kommst und das andere verwerfen. LXD bietet mehr Funktionen (u.a. AppArmor Integration, Live-Migration, fertige Images), sodass hier vieles einfacher und schneller von der Hand gehen sollte. Ich habe mich dennoch für nspawn entschieden, weil es damals LXD nicht in der Arch Linux Repo gab und nspawn für meinen Anwendungsfall vollkommen genügte. Vorteil bei LXD ist auch, dass die Dokumentation sehr gut ist, da es von vielen Leuten auch in produktiven Umgebungen eingesetzt wird. Somit auch breiter getestet.

Wenn du mit LXD klar kommst, würde ich das so machen:
- LXD für alles, was in einem LXC Container laufen kann
- Docker auch in LXC Container
- VM für alles, was nicht in einem LXC Container läuft (Windows, FreeBSD)

Den Host so schlank wie möglich halten, sodass sich die Updates in Grenzen halten (linux-lts hilft auch).

Wenn du weder ZoL, noch BTRFS verwenden willst, bietet sich als Alternative LVM (Thin) an. Eine Vergleichstabelle findest du unter: https://lxd.readthedocs.io/en/latest/storage/#feature-comparison

Vielleicht noch eine weitere Alternative: statt mdadm + LVM Thin + ext4 (oder XFS), wäre es vielleicht auch eine Option für dich, mdadm + BTRFS zu fahren. Du würdest dann Metadaten im DUP Profil (doppelt abgespeichert) und Daten im SINGLE Profil abspeichern. Vorteil: du kannst weiterhin COW, Checksummen, Snapshots und Clones nutzen. Und das RAID wird durch das kampferprobte mdadm realisiert. Nachteil: BTRFS kann Checksummen Fehler nur melden, aber nicht reparieren. Ist immernoch besser, als dass der Fehler still und heimlich passiert.

 

[Shutterfly]

@Shutterfly nspawn und LXD brauchst du nicht nebenher laufen lassen, da es im Grunde genommen fast dasselbe ist.

Danke für deine umfassende Antwort. Das ich LXC/LXD und nspawn nicht nebeneinander laufen lassen müsste, ist mir klar. Ich könnte aber

Ich habe dies nur geschrieben weil mich diese "Nimm Proxmox"-Antwort genervt hat. Sie hat nichts mit meiner eigentlichen Diskussionsfrage "VM oder Container - eure Meinungen" zu tun. Stattdessen wurde eine Standardantwort ohne Begründung geliefert. Wonach keiner gefragt hat

Weil er würde mit Proxmox LXC verwenden weil Proxmox das nur von Haus aus kann. Und das ist für mich kein Grund.

Ich wähle meine Lösung letztendlich nach Aspekten wie Stabilität, Performance, Sicherheit (jaja Container und Sicherheit), CLI, Dokumentation usw. Und nicht weil sie von Haus aus angeboten wird.

Aber das war nun schon zu viel zu dem Thema.

Letztendlich schwanke ich noch zwischen LXC bzw. LXD und nspawn und versuche irgendwelche technischen Vor- bzw. Nachteile zu finden, welche mir die Entscheidung einfacher machen. Aber in der Tiefe findet sich leider im Internet nur schwer etwas.

Nachtrag: Das man mit LXD seit 4.0 wohl auch VMs neben Container laufen lassen kann, hat mich interessiert. Daher werde ich in diese Richtung noch einmal genauer recherchieren. Wobei ich hier noch gar nicht weiß was für eine Art Hypervisor genutzt wird

 

[martingo]

Mein lieber @Shutterfly,

mich nervt auch vieles und trotzdem bin ich in der Lage, zurückzuschreiben ohne pampig zu werden. Deine erste Antwort habe ich auch widerspruchslos zur Kenntnis genommen (möglicherweise war ich auch etwas einsilbig, aber ich dachte, dass das Wesentliche bereits gesagt wurde - nur nicht von jedem), aber nachdem Du meinen Beitrag noch ein zweites Mal kritisiert hast, doch noch einige Worte:

• Ich habe nicht gesagt, dass Du Proxmox nehmen sollst. Ich habe es angesprochen und nachdem Du nspawn nicht kanntest, dachte ich, dass Du auch LXC nicht kennst. Das hat nämlich die gleichen Eigenschaften, die Du an nspawn gut fandest (lokales Verzeichnis für den Container auf dem Host mit direkter Zugriffsmöglichkeit, ZFS-Snapshots, Direkt-Backup etc.). Proxmox ist für den Unternehmenseinsatz geeignet und auch, wenn ich seit 20 Jahren auf der Kommandozeile unterwegs bin, schätze ich mittlerweile die Vorteile fertiger Appliances, die auch mal von jemand anderem gewartet werden können. Ich will nicht sagen, dass niemand in größeren Unternehmen heute noch einen Linux Hypervisor von der Pieke auf aufsetzt - üblich ist es aber definitiv nicht. Außerdem ist der Host im Fehlerfall binnen weniger Minuten komplett aufgesetzt und die Backups können eingespielt werden. Alternativ paralleler Zweit-Host, auf den die Maschinen dann mehr oder weniger ohne Downtime migriert werden können. Mit Proxmox arbeite ich seit ca. 10 Jahren und es gibt wenig, was ich auf der Kommandozeile machen müsste. Wenn es mal eine spezielle VM/LXC Konfiguration ist, dann wird das File eben einmalig angepasst, aber steht dann auch in Backups dauerhaft zur Verfügung.
• Wenn Du eine eigene Arch Instanz einrichten und betreiben willst ohne den Komfort, den eine Appliance bietet, dann tu das doch gerne. Ich fahre seit 20 Jahren mit Debian stable sehr gut, auch wenn neuere Versionen dort häufig länger auf sich warten lassen. Das wäre ein reiner Glaubenskrieg, andere Distributionen schlecht zu reden. Und Arch hat sich in den vergangenen Jahren auch sehr gut entwickelt. Das ist aber genau sowenig ein Grund, Proxmox/Debian madig zu reden.
• LXC habe ich für Standard-Linux-Anwendungen vorgeschlagen, weil der Ressourcen-Overhead sehr gering ist, die LXCs sich sehr gut warten lassen und Du Ressourcen Zuweisungen sehr flexibel handhaben kannst. Ja, Du musst eine Obergrenze bzgl. der Kerne und des Speichers angeben. Auch wenn es sehr unsinnig wäre, könntest Du aber jedem einzelnen Container den gesamten RAM des Servers zuweisen. Weit entfernt von best-practice mit allen resultierenden Nachteilen, aber möglich. Üblicherweise weist man so viel wie nötig, aber so wenig wie möglich zu. Egal bei welchem Hypervisor. LXCs nehmen sich nur soviel wie sie brauchen, aber wenn ein Container aus welchem Grund auch immer Amok läuft, bemerkt man es frühzeitig im Monitoring statt dass ein Container die anderen beeinflusst oder gar der Host mit out-of-memory klatscht. Wenn sich die Anforderungen verändern (z.B. der Datenbank Container soll auf Grund steigender Datensätze mehr RAM bekommen), kann man das live und ohne Reboot des Containers ändern.
• VMs laufen daheim auf einem ESXi (primär weil Solarish für meinen Fileserver unter ESXi besser läuft als auf einem regulären Linux Hypervisor). Eine dieser VMs ist Proxmox, der wiederum ausschließlich meine LXC Container hostet (genannte Vorteile). Ein angemieteter externer Server läuft direkt mit Proxmox und darauf dann einige Windows VMs und eine Mikrotik CHR Instanz. Die Performance ist nach Installation der QEMU Treiber nahezu identisch zur den ESXi VMs. Auch das Memory Ballooning läuft unter QEMU unauffällig. Ein DomainController belegt aktuell 1,45GB von zugewiesenen 2GB. Ein anderer Windows Server 2019 belegt aktuell 6.78GB von zugewiesenen 12GB. Nicht mal das zugewiesene Minimum von 8GB wird aktuell genutzt (aber reserviert).
• ZFS on Linux ist seit PVE 3.4 integriert und ich denke seit PVE 5.0 der Default. Aktuell sind wir bei PVE 6.2. In Debian Stable ist es seit Debian Buster/10.0 angekommen. Es läuft absolut stabil mit einer ganzen Menge Vorteile. Dass Du Verschlüsselung nutzen willst, hattest Du zu Beginn nicht gesagt. Ja, die ZFS-Dateisystem Verschlüsselung läuft bisher unter dem "originalen" Oracle Solaris am besten, auch unter OmniOS gibt es noch Probleme, an denen noch gearbeitet wird. Bei mir persönlich sind per OmniOS und nappit nur Nutzdaten verschlüsselt, aber keine VMs/Container. Insofern kann ich das jetzt erstmal gut aussitzen. Den Weg, auf Oracle Solaris zu setzen gäbe es natürlich auch oder ZoL auf einer LUKS verschlüsselten Partition zu betreiben. Ist kein Standard mehr, erfordert Konsolen Arbeit, aber hatte ich zwischenzeitlich auch laufen und lief top.
• Ich denke, wenn Du Dir den Proxmox Spiegelstrich wegdenkst, habe ich dennoch ein stimmiges Konzept geliefert, welche Technik ich für welchen Anwendungsfall bevorzugen würde. Letztlich ist das dennoch eine Geschmackssache, insofern habe ich auch auf seitenweise Begründungen verzichtet. Mein Beitrag war weder themenfremd noch belehrend noch haltlos. Insofern hat mich Deine Reaktion etwas geärgert.

So, das eine oder andere habe ich sicher noch vergessen, aber ich hoffe, ich habe nun alles etwas mehr ins rechte Licht gerückt und wir können weiter konstruktiv zusammenarbeiten, sofern noch Fragen offen sind.

Viele Grüße
Martin

 

[Shutterfly]

So, hatte was gedauert aber ich habs nicht vergessen.

mich nervt auch vieles und trotzdem bin ich in der Lage, zurückzuschreiben ohne pampig zu werden. Deine erste Antwort habe ich auch widerspruchslos zur Kenntnis genommen (möglicherweise war ich auch etwas einsilbig, aber ich dachte, dass das Wesentliche bereits gesagt wurde - nur nicht von jedem), aber nachdem Du meinen Beitrag noch ein zweites Mal kritisiert hast, doch noch einige Worte:

Vielleicht kam es falsch rüber aber die Antwort an dich war meiner Meinung nach nicht pampig. In meiner späteren Begründung habe ich meine "innere Meinung und Stimmung" wiedergegeben, welche ich auch weiterhin vertrete, jedoch bewusst so nicht als Antwort an dich kommuniziert habe. Da ich in diesem Thread jedoch nach Meinungen und Begründungen gesucht habe, gibt es für mich kein "das Wesentliche wurde bereits gesagt".

Immerhin gibt es bei der persönlichen Meinung nicht das einzig Wahre, auch wenn das einige das lieber so hätten Daher fehlte mir bei deinem Beitrag die Begründung.

• Ich denke, wenn Du Dir den Proxmox Spiegelstrich wegdenkst, habe ich dennoch ein stimmiges Konzept geliefert, welche Technik ich für welchen Anwendungsfall bevorzugen würde. Letztlich ist das dennoch eine Geschmackssache, insofern habe ich auch auf seitenweise Begründungen verzichtet. Mein Beitrag war weder themenfremd noch belehrend noch haltlos. Insofern hat mich Deine Reaktion etwas geärgert.

Ohne die, durch deinen letzten Beitrag, genannten Begründungen, ist dein ursprünglicher Beitrag für mich aber nicht nutzbar. Der Promox-Spiegelstrich hätte man weg lassen können, für die anderen Punkte die oben von dir gegebenen Begründungen direkt hinzunehmen. Dann wäre ich super fein damit gewesen und hätte dir für diese ausführliche Begründung gedankt.

Jedoch ohne Begründung ist das geschriebene Wort für mich leider nicht bewertbar und somit nicht verwertbar. Aber gut, jetzt kann ich die Punkte nachvollziehen und danke auch dir für die Einblicke.