UCS als Host für UCS VM's

UCS - Univention Corporate Server
, , ,
#1

Hallo zusammen,

ich möchte hier bei mir neue Server-Hardware anschaffen bzw. diese ist bereits da und möchte das Server-System komplett neu aufsetzen. Bei einer anderen Installation habe ich Debian als Host und UCS als Gast im Einsatz aber hier ist die Leses/Schreib - Performance auf die Samba-Freigaben nicht sonderlich konstant.

Ich konnte es schlussendlich nicht klären ob es am darunter liegenden Debian, dessen KVM-Konfiguration oder am BTRFS liegt.

Auf der Neuinstalltion hätte ich gerne UCS als Host und einen weiteren UCS als VM damit ich diesem im Bedarfsfall leichter auf einen anderen Host verschieben kann. Ich benötige folgende Dienste:

  • DHCP/DNS
  • Samba4 ADS
  • OX
  • Bareos

Mein Frage zielt darauf ab wo ich am besten welchen Dienst ansiedle. Meine Idee war den Virtualisierungs-Host so “dumm” wie möglich zu halten und dort lediglich den UCS mit der Virtualisierungs-Verwaltung zu installieren. Darauf drei VM’s:

  • VM01: DHCP/DNS, Benutzer, Rechner, Samba-ADS Infrastruktur)
  • VM02: Bareos
  • VM03: OX

Passt dass so oder gibt es dazu eine sinnvollere Aufteilung? Hatte schon überlegt den Bareos auf dem Virtualisierung-Host zu platzieren

#2

Moin,

Meine Idee war den Virtualisierungs-Host so “dumm” wie möglich zu halten und dort lediglich den UCS mit der Virtualisierungs-Verwaltung zu installieren.

Das ist sehr sinnvoll. Wenn andere Dienste außer der Virtualisierung auf einem Virtualisierer installiert werden, so verliert man gleich mehrere wertvollste Vorteile einer Virtualisierung: man kann die Maschine und damit die Dienste nicht mehr snapshotten (z.B. vor Updates), man kann sie nicht mehr einfach auf andere Hardware umziehen, wenn man mehr Performance benötigt etc.

Bezogen auf Univention ist ein Szenario möglich, bei dem der Virtualisierer ein UCS-System ist, das nur ein einfacher DC Slave und kein DC Master ist. Der DC Master wird dann in einer virtuellen Maschine auf dem physikalischen DC Slave eingerichtet.

Leider gibt’s hier ein gewisses Henne-Ei-Problem: das zuerst installierte System muss eigentlich der DC Master sein, aber bevor Sie den als VM aufsetzen können, brauchen Sie den installierten DC Slave. Aber es geht tatsächlich, wenn man ein wenig Handarbeit anlegt. Univention hat das Vorgehen in einem Cool-Solutions-Artikel dokumentiert. Ob das mit 4.2 noch funktioniert, vermag ich nicht zu sagen. Der Artikel wurde für 4.0 geschrieben.

Was die Aufteileung der Dienste betrifft: das hängt sehr vom erwarteten Nutzungsprofil ab. DHCP, DNS, Samba sind auf einem DC Master zusammen gut aufgehoben. Bei allen weiteren Diensten sollte man sich fragen: welche Ressourcen benötigen sie jetzt? Welche benötigen sie evtl. in der Zukunft? Wenn mehrere Dienste ein- und dieselbe Ressource intensiv nutzen (z.B. CPU-Last), so ist es sinnvoll, die in unterschiedliche VMs zu trennen, um sie in Zukunft einfach auf unterschiedliche Hardware verlagern zu können, indem die Maschinen verschoben werden (und nicht die Installationen innerhalb der Betriebssysteme).

Unter den Gesichtspunkten halte ich Ihren Vorschlag mit den VMs 1 bis 3 für durchaus vernünftig und sinnvoll.

Gruß,
mosu

#3

Falls das Hostsystem ebenfalls UCS verwenden soll, so ist es meiner Meinung nach sinnvoll diesen als DC-Slave mit den Apps DHCP, KVM und UVMM einzurichten.

#4

Um das Henne-Ei-Problem zu lösen habe ich auf einem Laptop in Virtualbox oder VMware eine VM mit einer 2.UCS Domäne (KVM, UVMM) erstellt. In dieser wiederum den DC-Master der gewünschten UCS-Domäne. Später kann der DC-Master umziehen und die VM für spätere Aktionen (Systemausfall) wieder verwendet werden.

#5

Es gibt natürlich mehrere Wege, so eine Konstellation aufzusetzen. Eine Erstinstallation auf einem Nicht-UCS-Virtualisierer ist allerdings nicht zwangsläufig nötig. Der Cool-Solutions-Artikel, den ich verlinkt hatte, zeigt einen Weg, den physikalischen DC Slave für Virtualisierung zuerst aufzusetzen aber noch nicht zu joinen. Dann wird dort mit etwas Handarbeit die VM für den DC Master angelegt, der DC Master installiert und anschließend der physikalische DC Slave in die Domäne gejoint. Ist in Summe weniger Arbeit, sofern das alles klappt.

#6

Nachdem die Hardware endlich da ist und ich Zeit habe die Installation durchzuführen werde ich mich mal durch den Artikel hangeln. Einen Slave ohne Join bedeutet für mich im Installer:

-> Einer bestehenden UCS-Domäne beitreten
-> Fortfahren mit unvollständigen Einstellungen

Oder?

Ich habe den Server zunächst mal ins vorhandene LAN gehängt und Netzwerk per DHCP konfigurieren lassen. Funktioniert das? Ich würde die IP-Einstellungen am Ende dann anpassen.

#7

Das klappt so leider nicht. Oder ich mache etwas falsch. Das bisherige LAN:

DNS/DHCP: 192.168.5.20
GW: 192.168.5.10

Gebe bei der Installation des neuen UCS eine freie IP statisch an (192.168.5.2) und trage DNS und GW entsprechend ein.

Am Ende wähle ich die o.g. Optionen. Danach kann ich “Slave” wählen und die Software:

  • KVM virtualization server
  • UCS Virtual Machine Manager

zusätzlich anwählen. Wenn ich dann auf weiter klicke erhalte ich:

Der angegebene DNS-Server 192.168.5.20 ist nicht Teil einer gültigen UCS-Domäne.

Was mache ich falsch?

Viele Grüße
Sven

#8

Falls du noch andere Hardware mit Virtualisierungsfunktion hast (ist ja eigentlich inzwischen Standard bei neuer Hardware), würde ich diese zunächst als KVM-Host nehmen (z.B. mit OVirt Live und darin den Master installieren. Dann kannst du problemlos auf der eigentlichen Hardware den eigentlichen KVM-Host mit UCS einrichten und anschließend den Master darauf als VM migrieren.

#9

Ich habe mir das Live-ISO von OVirt gezogen aber weder auf einem Asus-PC noch auf einer HP Workstation (Z240) startet das LiveSystem korrekt (Hardware-Virtualisierung im BIOS ist aktiv). An der Workstation kommt am Ende dass es zu Fehlern kam (ohne nähere Angaben) und ich kann mich dann aber einloggen. Allerdings funktioniert kein Netzwerk und in den Settings finde ich keine Option einen LAN-Adapter bzw. Verbindung hinzuzufügen. Gibt es noch ein alternatives System mit dem ich schnell einen KVM-Host einrichten kann? Hardware wäre frei. Muss also kein Live sein.

#10

Mit Proxmox VE war ich damals ganz zufrieden. Ist aber etwas größer.

Ansonsten giebt es noch AQemu, aber bis jetzt hab ich dann doch immer VirtualBox genommmen.

Wenn du eh eine Desktop-Linux-Installation hast, würde ich für die Installation einfach auf der Konsole starten.

#11

Ok, ich versuche mal mein Glück. Ein grundsätzliche Frage. Auf meine Bisherigen KVM-Hosts habe ich immer LVM genutzt d.h. jedes HD-Device einer VM war ein LVM auf dem Host und das Format war RAW.

Wie ist das bei UCS bzw. dessen Virtualisierung? Wie und wo legt dieser die Images ab? Kann man beim UCS die HD-Images dann nachträglich vergrößern?

Wenn ich jetzt den späteren Master (Hostname: TUX) auf einem anderen Host (Hostname: KVM01) installiere. Wie lege ich hier die Partitionen auf TUX am besten an?:

/dev/sda /boot ext2 500MB
Rest LVM

VolumeGroup: tux_vg01

tux_root ext4 50GB /
tux_var ext4 30GB /var
tux_home ext4 50GB /home
tux_data ext4 750G /data

oder macht es keinen Sinn auf der VM mit LVM zu arbeiten?

#12

Du kannst auch unter AFAIK LVM-Volumes als HDD für die VMs nutzen. Standardmäßig nutzt UCS bei der Virtualisierung aber QCOW-Images. Diese nutzen (anfangs) nur den Platz, der auch tatsächlich benötigt wird und unterstützen vor allem auch Snapshots. Eine Vergörßerung ist auch möglich aber etwas umständlicher als bei LVM-Volumes, da erst das Image, dann die Partion und dann ggf. LVM-Volumes innerhalb der VM vergrößert werden müssen. Aber dank QCOW kann man ja gleich eine größere Reserve einplanen.

Das kann man schon so machen. Denkbar ist natürlich auch stattdessen mehrere Images zu nutzen (hat eine Ebene weniger). /home und /var auf eine extra Partition/Image/Volume zu legen macht auch Sinn.

#13

Danke! Ich werde auf dem späteren Host wie o.g. LVM nutzen und in der VM nicht. Ich denke dann ist es einfach zu handhaben.

Eine Frage noch zur Swap-Partition. Der Host ist ein Server mit Hardware-RAID 5 (LSI) an dem ausschließlich SSD’s hängen. Macht es da Sinn auf die Swap-Partition zu verzichten?

Und in der VM. Macht da eine Swap-Partition überhaupt Sinn?

Gruß Sven

#14

Gerade stellt sich mir noch die Frage welche Rolle ich dem Virtualisierungs-Host am besten gebe. Ich denke “Backup” und nicht “Slave” oder?

#15

Das könnte auch ein “Member” sein, wenn er nur Virtualisierung machen soll. “Backup” würde ich da (für single-use Virtualisierung) eher nicht nehmen, das ist aber nur meine Meinung.

#16

Ich habe mir einfach mal die verschiedenen Rollen im Handbuch angeschaut und die Überlegung war:

Den Virtualisierungs-Host als Backup zu machen bringt mir den Vorteil das Anmeldung und Internet auch dann noch funktioniert wenn der Master (VM) aus irgend einem Grund gerade “down” ist oder umgezogen wird etc. Ich denke der Overhead d.h. die User-Daten etc die ich dann zusätzlich auf dem Host haben sind sicher nicht allzu groß.

Bin aber noch nicht lange mit UCS am tun und somit an Euren Meinungen interessiert.

#17

Ich würde den “overhead” nicht unterschätzen, gerade auf einem BackupDC… Das ist natürlich jedem selbst überlassen, aber ich würde halt einen member nehmen um sämtliche Ressourcen der VM bereitstellen zu können.

#18

Ok, danke für den Tipp! Ich habe noch eine Frage zur Partitionierung. Der Server (Host) ist mein einem LSI 8 Kanal-RAID-Controller ausgestattet an welchem im Moment 4 SSD als RAID 5 konfiguriert sind.

Ich habe mal gehört dass man bei Verwendung von SSD’s auch auf die Swap-Partition verzichten kann und webenso bei der VM. Ist das richtig oder bringt dies Nachteile mit sich. Der Server hat 2 Operons mit je 6 Kernen und 64GB RAM. Mehr als die EIngangs erwähnten VM’s sollen darauf nicht laufen.

#19

Ich bin der Meinung man sollte bei SSDs immer noch im Hinterkopf behalten, dass SSD Speicherzellen nicht unbegrenzt oft beschrieben werden können - SWAP Partitionen können potentiell sehr viele Schreibprozesse beinhalten. Die Verwendung einer Swap Partition hängt auch eher vom RAM ab. Je mehr RAM desto seltener muss geswapt werden.

#20

Ein Zwischenstand: Ich bin seit Gestern daran das Vorhaben umzusetzen. Ich habe auf einem externen PC den Master installiert und auf der Server-Hardware den Member. Da SSD und außreichend RAM ohne Swap.

Die beiden Systeme + mein Notebook hängen in einem gesonderten Netz ohne Zugang zum Internet.

Ich habe bei der Installation ein reproduzierbares Problem. Wenn ich den Member, welcher ja nachher der Virtualisierungs-Host sein wird, ganz normal installiere. Sprich: statische IP, UCS-Domain join als Member, keine Zusatzpakete installiere funktioniert es soweit. Wähle ich bereits hier zusätzlich den Virtualisierungs-Server an klappt der Join nicht da er den Master nicht findet.

Ich vermute mal es liegt daran dass beim Member die IP von ethX auf br0 “geschoben” wird.

Ich habe dann einfach ohne den Virtualisierungs-Server installiert aber nun kann ich den nicht nachinstallieren da ich keine Internetverbindung habe.

Kann ich irgendwie die DVD wieder einbinden und von dort installieren? Wie mache ich das unter UCS?

Oder gibt es einen anderen Weg das Problem zu umschiffen?

Viele Grüße
Sven

Mastodon