Beinahe enzyklopädisch behandelt unser Schwerpunkt-Artikel über IPSEC verschlüsselte Verbindungen zwischen Linux, Windows, BSD, Solaris, Cisco- sowie ... (mehr)

UCS-Virtualisierung

Beim UCS besteht eine Virtualisierungsumgebung stets aus mindestens zwei Komponenten, nämlich einem Virtualisierungsserver (Xen oder KVM) und einem UCS, der als Virtual Machine Manager (UVMM) fungiert. Die zugehörige Rollenverteilung ergibt sich wie gesehen einerseits aus der Auswahl des zu installierenden Pakets im Setup-Programm. Im Verlauf der Installation muss man außerdem jedem UCS-System eine Systemrolle zuweisen. So kann ein als UVMM-Manager auserkorener UCS gleichzeitig auch Master Domain Controller, Backup Domain Controller oder Slave Domain Controller sein. Ein Virtualisierungsserver kann zudem UCS-Memberserver sein.

Abbildung 1: Eine UCS-Virtualisierungsumgebung setzt sich aus drei Komponenten zusammen, die im einfachsten Fall auf ein und derselben Maschine laufen können.

Beim Aufsetzen einer neuen UCS-Virtualisierungsumgebung genügt es im einfachsten Szenario, einen DC Master aufzusetzen, der gleichzeitig als physischer Server für die Virtualisierung fungiert und den UVMM-Dienst zur Verfügung stellt. Nach dem obligatorischen Neustart stehen im Grub-Bootloader mehrere Kernel zur Auswahl. Mit dem ersten Eintrag startet der UCS den Xen-Kernel und lädt den Hypervisor für die Virtualisierung auf dem physischen Server.

Abbildung 2: Dieser UCS-Server kann wahlweise als Xen-Hypervisor oder UCS-Managementsystem fungieren, mangels CPU-Unterstützung aber nicht als KVM-Virtualisierungsserver.
Abbildung 3: Steht KVM mangels CPU-Unterstützung nicht zur Verfügung, erstellt das System eine paravirtualisierte Xen-Umgebung.

Der Xen-Hypervisor ist im Xen-Virtualisierungszenario für das Verteilen der Ressourcen auf die virtuellen Maschinen zuständig. Allerdings muss der Administrator den Xen-Hypervisor noch konfigurieren. Dabei gilt es, zunächst die Gewichtung der Ressourcenverteilung zwischen Hypervisor und Gast-Instanzen anzupassen, was Xen intern mithilfe sogenannter Credits regelt. Per Default sind alle Ressourcen gleich verteilt und mit einem Credit-Wert von 256 belegt. Die Dokumentation empfiehlt, in der Datei »/etc/rc.local« den Wert für den Hypervisor auf 512 zu erhöhen. Dazu ist in der vorletzten Zeile vor »exit 0« der Eintrag

xm sched-credit -d Domain-0 -w 512

zu ergänzen. Die Xen-Dokumentation empfiehlt außerdem, dem Hypervisor einen Anteil des physischen Arbeitsspeichers und auf MehrkernSystemen eine oder mehrere CPUs fest zuzuweisen. Diese Konfiguration kann beim UCS mithilfe einer UCS-Systemvariable »grub/xenhopt« erfolgen, die der Admin beim UCS mit »ucr set« setzen kann:

ucr set grub/xenhopt="dom0_mem=xxxxM dom0_max_vcpus=x dom0_vcpus_pin"

Hierbei steht xxxx für die Größe des zuzuweisenden Arbeitsspeichers in Megabyte, x für die Anzahl zuzuweisender CPUs. Die nötige Größe des Arbeitsspeichers hängt primär von der Anzahl laufender Dienste ab. Wer einen reinen UCS-Virtualisierungsserver aufsetzt, sollte mit 1 GByte Arbeitsspeicher für einen Xen-Hypervisor zurechtkommen. Will man neben der Xen-Virtualisierung weitere Dienste vom UCS zur Verfügung stellen (Webserver, Mailserver), ist der Wert gegebenenfalls nach oben zu korrigieren, etwa

ucr set grub/xenhopt="dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin"

für einen Virtualisierungs-Server mit 4 GByte RAM und zwei CPUs.

UVMM-Assistenten

Sind alle Konfigurationsvorarbeiten erledigt, ist das Anlegen und Verwalten virtueller Instanzen im grafischen UVMM-Modul der Univention Management Console relativ einfach. Vor dem Konfigurieren virtueller Instanzen ist unbedingt darauf zu achten, den seit Anfang April 2011 verfügbaren Patch-Level 2.4-2 wie beschrieben einzuspielen. Damit lässt sich dann beispielsweise der paravirtualisierte Zugriff auf Laufwerke und Server direkt über das UVMM-Modul einrichten. Virtualisierte Systeme können so auf Geräte des physischen Virtualisierungsservers (CD, DVD) zugreifen (Passthrough), außerdem lassen sich jeder virtuellen Instanz auch mehrere Netzwerkkarten zuweisen. Weiter kann der Admin im UVMM-Profil den Parameter »Architektur« auf »automatic« setzten, womit das UVMM-Modul stets die Hardware des physischen Servers auf der virtuellen Maschine anbietet.

Abbildung 4: Assistenten helfen beim Anlegen neuer virtueller Instanzen.

Übrigens ist es auf einem 64-Bit-System nicht mehr erforderlich, eine 32-Bit-CPU zu emulieren. Allerdings lässt sich durchaus auch ein 32-Bit-Betriebssystem installieren. Beim Erstellen virtueller Maschinen erzeugt das System in der Regel vollvirtualisierte Systeme (KVM), sofern die im Virtualisierungsserver verbaute CPU über eine VT-Erweiterung verfügt. Xen-Hosts dagegen beherrschen in Verbindung mit Linux auch Paravirtualisierung.

Das UVMM-Modul heißt innerhalb der Univention Management Console (UMC) »Virtuelle Maschinen« und zeigt auf der linken Seite in einer Baumstruktur eine Übersicht der vorhandenen physischen Server gruppiert nach Namen an, dazu die jeweils konfigurierten virtuellen Instanzen. Wählt man einen physischen Server aus, erscheint rechts seine CPU- und Speicherauslastung.

Das UVMM-Modul kann virtuelle Instanzen anlegen, bearbeiten und löschen. Außerdem kann der Admin den Status einer virtuellen Instanz ändern. Im Detail hängt der Funktionsumfang von der darunter liegenden Virtualisierungstechnik ab; sogenannte Sicherungspunkte sind beispielsweise nur mit KVM möglich. Zum Erstellen einer neuen virtuellen Instanz steht im UVMM-Modul ein Assistent zur Verfügung.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023