von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - Virtualisierungsmanager Proxmox VE (1)
Effizientes Arbeiten mit VMs
Die Fähigkeiten vom Proxmox im Umgang mit VMs gehen über das simple Starten und Stoppen der virtuellen Instanzen weit hinaus. Proxmox bietet etwa ähnlich den Funktionen einer Cloud die Möglichkeit, VM-Templates anzulegen. Die basieren auf einem entsprechend vorbereiteten Betriebssystem-Abbild, das sich bei Bedarf schnell modifizieren lässt. Wer etwa ein "Debian"-Template hat und eine neue VM auf Debian-Basis braucht, startet eine neue VM auf Basis des Templates und ist schnell am Ziel. Zumindest erspart der Admin sich so eine erneute Grundinstallation, die viele Fragen stellt und einige Zeit frisst. In Ergänzung zur Template-Engine gibt es für laufende VMs auch eine Funktion zum Klonen – das Ergebnis ist eine neue VM, die ihrem Vorbild gleicht wie ein Ei dem anderen.
In Clouds spielt High Availability (Bild 1) anbieterseitig keine große Rolle. Möchte der Kunde ein fehlerresistentes System haben, designt er seine Umgebung eben so, dass sie diesem Kriterium entspricht. Ist klassische Hochverfügbarkeit per Cluster-Manager nötig, obliegt es dem Kunden, dieses Setup in seinen VMs per Automatisierung oder zu Fuß umzusetzen. Auf Hilfe vom klassischen Cloud-ISP kann er bei diesem Unterfangen jedenfalls nicht hoffen. In konventionellen Umgebungen sieht die Sache etwas anders aus. Hier gilt das Cloudmantra "jede Komponente kann zu jedem Zeitpunkt kaputt gehen und sollte nicht als zuverlässig vorhanden betrachtet werden" nur eingeschränkt. Denn in Virtualisierungsumgebungen fehlt meist ganz banal schon die Infrastruktur, um Ausfälle durch das Skalieren in die Breite abzufedern. Entsprechend kommt die Proxmox-Umgebung ab Werk mit mehreren Maßnahmen, die Hochverfügbarkeit bieten.
Über die Funktionalität des Proxmox-Clustermanagers gab es im Test indes keinen Grund zu Beschwerden; das Produkt erkannte den Ausfall einzelner Knoten zuverlässig und leitete automatisch auch die passenden Maßnahmen für die Recovery des Clusters ein.
Seite 1: Stark veränderte Architektur
Seite 2: Effizientes Arbeiten mit VMs
Im zweiten Teil des Workshops schauen wir uns die Integration mit dem Objektspeicher Ceph an und erklären, warum bei hyperkonvergenten Setups Vorsicht geboten ist.
dr/ln/Martin Loschwitz
Die Fähigkeiten vom Proxmox im Umgang mit VMs gehen über das simple Starten und Stoppen der virtuellen Instanzen weit hinaus. Proxmox bietet etwa ähnlich den Funktionen einer Cloud die Möglichkeit, VM-Templates anzulegen. Die basieren auf einem entsprechend vorbereiteten Betriebssystem-Abbild, das sich bei Bedarf schnell modifizieren lässt. Wer etwa ein "Debian"-Template hat und eine neue VM auf Debian-Basis braucht, startet eine neue VM auf Basis des Templates und ist schnell am Ziel. Zumindest erspart der Admin sich so eine erneute Grundinstallation, die viele Fragen stellt und einige Zeit frisst. In Ergänzung zur Template-Engine gibt es für laufende VMs auch eine Funktion zum Klonen – das Ergebnis ist eine neue VM, die ihrem Vorbild gleicht wie ein Ei dem anderen.
Bild 1: Hochverfügbarkeit spielt bei Proxmox eine wichtige Rolle, deshalb hat die Umgebung einen eigenen
Cluster Resource Manager.
Cluster Resource Manager.
In Clouds spielt High Availability (Bild 1) anbieterseitig keine große Rolle. Möchte der Kunde ein fehlerresistentes System haben, designt er seine Umgebung eben so, dass sie diesem Kriterium entspricht. Ist klassische Hochverfügbarkeit per Cluster-Manager nötig, obliegt es dem Kunden, dieses Setup in seinen VMs per Automatisierung oder zu Fuß umzusetzen. Auf Hilfe vom klassischen Cloud-ISP kann er bei diesem Unterfangen jedenfalls nicht hoffen. In konventionellen Umgebungen sieht die Sache etwas anders aus. Hier gilt das Cloudmantra "jede Komponente kann zu jedem Zeitpunkt kaputt gehen und sollte nicht als zuverlässig vorhanden betrachtet werden" nur eingeschränkt. Denn in Virtualisierungsumgebungen fehlt meist ganz banal schon die Infrastruktur, um Ausfälle durch das Skalieren in die Breite abzufedern. Entsprechend kommt die Proxmox-Umgebung ab Werk mit mehreren Maßnahmen, die Hochverfügbarkeit bieten.
Zunächst gehört ein klassischer Clustermanager zum Lieferumfang, den Proxmox in Eigenregie verfasst hat. Die Entscheidung mutet etwas seltsam an, weil ja für Linux eigentlich ein gut funktionierender Clustermanager zur Verfügung steht, nämlich Pacemaker, das zum Linux-HA-Stack gehört. Immerhin: Corosync haben die Proxmox-Entwickler nicht neu erfunden, sie setzen also auf den Stack für die Kommunikation der Cluster-Komponenten, der auch in Linux-HA offiziell Anwendung findet.
Weniger schön ist vom Architekturstandpunkt aus hingegen die Tatsache, dass die Entwickler sich für die Synchronisation der Konfigurationsdateien innerhalb eines Proxmox-Clusters gleich ein eigenes Dateisystem ausgedacht haben. Was viele mit ungläubigem Staunen quittieren, ist Realität: Proxmox verwendet ein auf den Namen "pmxcfs" getauftes Dateisystem, um zu garantieren, dass sämtliche im Cluster existierende Knoten alle relevanten Konfigurationseinträge haben.
Nun müssen wir an dieser Stelle zur Verteidigung der Entwickler anführen, dass die Grundlagen von "pmxcfs" bis ins Jahr 2010 zurückreichen, als es Dienste wie Consul oder Etcd schlicht noch nicht gab. Auch Automatisierer existieren zum damaligen Zeitpunkt kaum in zufriedenstellendem Umfang. Dass die Entwickler damals also ihr eigenes Ding gemacht haben, ist bis zu einem bestimmten Grad verständlich. Mittlerweile böte es sich aber an, auf eine der Standardlösungen zu setzen, die am Markt verfügbar sind. Immerhin: Im laufenden Betrieb funktioniert die Lösung gut und verursacht keine Probleme.
Seite 2: Effizientes Arbeiten mit VMs
Im zweiten Teil des Workshops schauen wir uns die Integration mit dem Objektspeicher Ceph an und erklären, warum bei hyperkonvergenten Setups Vorsicht geboten ist.
| << Vorherige Seite | Seite 2 von 2 |
dr/ln/Martin Loschwitz
