Proxmox oder lxd Storage

  • Hallo,


    mal eine Frage in die Runde an alle die Proxmox oder lxd benutzen: was verwendet ihr als Storage? ZFS, Btrfs, LVM (thin) oder raw/qcow2 Files? Was ist der jeweilige Vorteil? Verwendet ihr Snapshots für Backups?


    Ich hadere gerade mit der Geschwindigkeit des Backups auf einem SSD Rootserver, da ich dort raw Files am Laufen habe und deswegen kein Snapshot geht. Da die SSD so klein ist, kann ich auch kein lokales tmp verwenden.


    Volker

  • Ich habe LXD auf mehreren Maschinen im Einsatz. Dabei nutze ich BTRFS mit loop-backed storage. Das ist laut LXD Docs nicht für den Produktiveinsatz geeignet, läuft bei uns aber problemlos. Alternativ kannst du natürlich auch eine eigene Partition einrichten. Vorteil: BTRFS kann (im Gegensatz zu ZFS) getrimmt werden, sodass im SCP die korrekte Festplattenbelegung angezeigt wird. Die Performance ist auf allen Storage-Technologien (HDD, Optane, SSD) ausreichend schnell, wobei HDD etwas langsamer ist. Zwischen Optane und SSD gibt es (gefühlt) keinen Unterschied in der alltäglichen Geschwindigkeit.


    Für Backups mache ich einen Offline-Snapshot der Container und exportiere diesen dann als Image auf den netcup Storage: https://github.com/janxb/ServerUtils/blob/master/lxd-backup

  • ZFS on Linux wird mit Version 0.8 wohl TRIM Support bekommen. Aber wann das dann in Proxmox kommt steht ja in den Sternen. Auf dem betroffenen Rootserver läuft auch nur ein einziger Container, eigentlich ist dann Proxmox da viel zu viel Overhead bei der vergleichsweise kleinen SSD. Es ging mir nur darum den Container als ganzen auf andere Hosts schieben zu können.


    Wo ich das Repository sehe: das hattest Du mir schonmal empfohlen. 😃 Es ist beruhigend, dass Du das immer noch so am Laufen hast. Dann wird es eher das Beste sein, dass ich teste das ganze in LXD zu importieren, auf einer Optan Maschine. Entweder lasse ich es dann dort, da die Kiste mehr Cores hat, oder ich ziehe es dann später zurück auf die jetzige Kiste, wenn alles neu aufgesetzt ist. Die Optan Kiste hat nämlich etwas zu wenig RAM, viel zu viel Disk, aber dafür wenigstens viele vCores statt dedizierten.

  • Ich benutze seit längerer Zeit und auf mehreren Systemen LXD mit ZFS. ZFS weil es für meine Zwecke irgendwie am einfachsten war. Ich hatte bisher damit nur einmal Probleme als eine Disk vollgelaufen ist und ich zuerst herausfinden musste, wie ich das Problem lösen kann.


    Bei meinem Anwendungen spielt die Performance für Schreib-Operationen in der Regel keine Rolle, umso wichtiger ist aber ein schnelles Lesen. Weil ich mit ZFS im Vergleich mit BTRFS deutlich schlechtere Resultate hatte, hatte ich mal mit der recordsize rumgespielt und dabei signifikant bessere Leseraten erzielt. Da ich aber bisher trotzdem keine Probleme hatte, habe ich es bei den Vorgabewerten belassen.


    Snapshots mach ich vor allem mit meinen Entwicklungs- und Test-Containern ab und zu fallweise um das Rad zurückzudrehen, wenn ich mal was zerschossen habe. Meistens setze ich die Container aber mit geeigneten Images und Profiles sowie unter Verwendung von Cloud-Init mit ein paar Scripten gleich neu auf. Das geht dann einfach und in der Regel super schnell. Ein Entwicklungscontainer mit allen benötigten Tools steht in der Regel in 2 bis 5 Minuten mitsamt den tagesaktuellen Updates fertig bereit zum Einsatz. Natürlich wurde das alles nicht in einem Tag erschaffen, sondern ist langsam gewachsen.


    Ich bin auch gespannt wie es sich mit Optane verhält. Leider komme ich aber vorerst nicht dazu dies mit meinem neuen VPS Eierpower zu testen. Ich habe bereits eine Anwendung, die zur Zeit auf einem vergleichbaren System mit SSD und etwas weniger Speicher bei einem anderen Provider läuft. Je nachdem wie der Test ausfällt werde ich die Anwendung zu netcup zügeln oder den VPS hier kündigen.

  • Ich benutze seit längerer Zeit und auf mehreren Systemen LXD mit ZFS. ZFS weil es für meine Zwecke irgendwie am einfachsten war. Ich hatte bisher damit nur einmal Probleme als eine Disk vollgelaufen ist und ich zuerst herausfinden musste, wie ich das Problem lösen kann.

    Hast Du das auf SSD oder SAS Systemen am laufen? Was hast Du wegen der vollgelaufenen Disk gemacht? War das wegen dem fehlenden TRIM Support?

  • Vorteil: BTRFS kann (im Gegensatz zu ZFS) getrimmt werden,

    Ich betreibe ebenfalls LXD auf BTRFS hier auf Netcup. Und zwar wegen dem "Nesting", also weil ich auch Docker-Container einbetten kann. Aber wie trimme ich die denn das? Da das Volumen von LXD gar nicht eingebunden wird, musste ich es erst einbinden, um fstrim auszulösen. Geht das auch ohne mount?

  • Ich habe hier auch Proxmox OHNE vmx flag laufen. Nur LXC. Als Storage ist LVM Thin im Einsatz.


    Der Overhead von ZFS ist mir auf virtuellen Maschinen zu hoch.


    Wieso Proxmox? Weil es einfach ist und funktioniert.

    LVM Thin habe ich auf einem Proxmox die Tage auch getestet und war von der Geschwindigkeit des Backups mit Snapshot begeistert. 5 Minuten statt 30 Minuten. Proxmox hat schon den Vorteil, dass man die Backups leicht auf nen anderen Server kriegt. Wenn nur 1-2 Container auf dem Host laufen sollen, ist es mir aber eigentlich zu viel Overhead. Daher nehme ich auch LXD her.

  • Praktisch bei Proxmox ist halt auch, dass man mehrere Nodes zu einem Cluster zusammenfassen kann. Damit ist es möglich zentrale Firewallregeln anzulegen und Container zwischen den Nodes zu verschieben, z.B. zum Lastausgleich.

    Seit der Einführung der CloudVLANs ist die Erstellung des Clusters auch wesentlich einfacher.

  • Praktisch bei Proxmox ist halt auch, dass man mehrere Nodes zu einem Cluster zusammenfassen kann. Damit ist es möglich zentrale Firewallregeln anzulegen und Container zwischen den Nodes zu verschieben, z.B. zum Lastausgleich.

    Seit der Einführung der CloudVLANs ist die Erstellung des Clusters auch wesentlich einfacher.

    Den Teil muss ich auch nochmal testen. Ich hatte Probleme damit einen Cluster zum Laufen zu kriegen. Ich vermute ich habe das am Anfang mit dem zweiten Netzwerkdevice für den Cluster falsch gemacht. Und dass die Proxmox Nodes nicht alle leer waren. Und mit dem nicht für alle Nodes freigeschaltetem NFS Backup Space gab es auch ein Problem.


    Ich habe noch VPS vorgesehen für ein Testsetup. Mal schauen ob das dann am Ende besser aussieht.


    Aber ich werde meinem LXD Node auf jeden Fall noch BTRFS verpassen, das werde ich so schnell nicht umstellen...

  • Hast Du das auf SSD oder SAS Systemen am laufen? Was hast Du wegen der vollgelaufenen Disk gemacht? War das wegen dem fehlenden TRIM Support?

    Ich habe SSD und SAS Systeme mit LXD und ZFS am laufen. Bei netcup nur SSD.


    Wie ich das mit der vollgelaufenen Disk gelöst habe weiss ich im Detail schon wieder nicht mehr und ja, es war wegen dem fehlenden TRIM Support. Den Hinweis zur Lösung des Problems habe ich über das LXC/LXD Forum gefunden. Ich wollte es noch dokumentieren, hab es aber verschlampt.

  • Hmm... Das mit dem fehlenden TRIM Support bei ZFS ist dann erstmal blöd. Bevor ich das auf SSDs einsetze, werde ich auf ZOL 0.8 Support warten müssen.


    Das BTRFS hilft ja an der Stelle erstmal. Ich have heute einen LXD Host darauf umgestellt und das Backup mit dem Script von janxb getestet. Scheint erstmal zu passen.

  • Ich benutze seit längerer Zeit und auf mehreren Systemen LXD mit ZFS

    Zumindest früher gab es bei LXD + ZFS die Einschränkung, dass ein Snapshot/Image solange weiter existieren muss. wie ein Container daraus erstellt wurde. Beispiel: Ich exportiere einen Container auf Host A und importiere ihn als Image in Host B. Das Image kann ich jetzt aber nicht löschen, da noch ein Container darauf referenziert. Diese Einschränkung gibt es bei BTRFS nicht, daher bin ich vor einiger Zeit umgestiegen.

  • Zumindest früher gab es bei LXD + ZFS die Einschränkung, dass ein Snapshot/Image solange weiter existieren muss. wie ein Container daraus erstellt wurde.

    Den Fall, wie du ihn mit dem exportierten Image beschreibst, müsste ich zuerst mal nachvollziehen. Das wäre natürlich lästig. Kopiere ich aber z.B. einen Container, der ein Snapshot enthält, dann ist dieser Snapshot auch in der Kopie enthalten und kann nicht gelöscht werden, bevor er aus allen Kopien gelöscht wurde, bzw. diese nicht mehr vorhanden sind. Dies kann etwas lästig werden, weil man nicht ohne weiteres erkennen kann, wo überall ein bestimmter Snapshot enthalten ist.


    In deinem Fall würde ich wahrscheinlich so vorgehen, dass ich die Snapshots des Containers zuerst lösche bevor ich ihn exportiere, oder aus dem Container zuerst eine Kopie erstelle aus der ich die Snapshots lösche und dann diese bereinigte Kopie des Containers exportiere.

  • pgloor


    Das von dir beschriebene Szenario ist ein anderes, als mein Beispiel.


    1. Image eines Container von Host A erstellen und dieses anschließend exportieren.

    2. Image in Host B importieren und davon einen neuen Container erstellen

    3. Image kann auf Host B jetzt nicht mehr gelöscht werden, da ein abhängiger Container existiert.


    Hinweis: Snapshots und Images sind verschiedene Dinge. Außerdem eine Einschränkung bei ZFS: Restores sind immer nur vom letzten Snapshot möglich. Um von einem älteren Snapshot wiederherzustellen, müssen alle neueren gelöscht werden. So zumindest laut LXD Doku.


    Edit: Ergänzung / Klarstellung: Natürlich kannst du das Image im Frontend von LXD löschen. Physikalisch auf der Platte bleiben die Daten allerdings noch vorhanden und belegen Speicherplatz.

  • Ich denke ich habe dich schon richtig verstanden. Wenn du aber aus dem Container alle Snapshots löscht bevor du das Image erstellst, sollte diese Abhängigkeit auf Host B doch auch nicht mehr gegeben sein. Sonst wäre das meiner Ansicht nach ein Bug.

    Hinweis: Snapshots und Images sind verschiedene Dinge. Außerdem eine Einschränkung bei ZFS: Restores sind immer nur vom letzten Snapshot möglich. Um von einem älteren Snapshot wiederherzustellen, müssen alle neueren gelöscht werden. So zumindest laut LXD Doku.

    Ja, das ist so und ich muss zugeben, dass ich nicht wusste, dass diese Einschränkung nur für ZFS gilt.

  • Wenn du aber aus dem Container alle Snapshots löscht bevor du das Image erstellst, sollte diese Abhängigkeit auf Host B doch auch nicht mehr gegeben sein.

    Der Container enthält keine Snapshots.


    Du erstellt ein Image des (nackten) Containers auf Host A. Dieses Image exportierst du und importierst es auf Host B. Weiterhin gilt: Es sind keine Snapshots im Spiel. Jetzt löschst du das Image auf Host B. In der GUI ist es verschwunden, auf der Platte existiert das ZFS Volume aber weiterhin, da es ein von ihm abhängiges Volume (den neu erstellen Container) gibt. Das ist kein Bug, sondern die Arbeitsweise von ZFS.