Nach unserem sehr erfolgreichen Webinar zur „Einführung in Puppet“ veranstalten wir in wenigen Tagen unser zweites Puppet Webinar mit dem Thema „Puppet Enterprise and VMware„.
PuppetLabs hat vor kurzem ein neues Set an Puppet Modulen für das Management von VMware Umgebungen veröffentlicht. Diese Integration und die weiteren Features von Puppet Enterprise sind Thema des Webinars.
Das einstündige Webinar findet am 14.05.2013 um 11:00Uhr statt und wird von dem sehr erfahrenen Puppet Labs engineer Reid Vandewiele in englischer Sprache durchgeführt. Natürlich sind auch Kollegen von uns mit dabei, die alle aufkommenden Fragen (auch auf deutsch) beantworten können.
Die Registrierung kann hier durchgeführt werden. Bitte nicht von der Zeitangabe beeindrucken lassen (in UTC), das Seminar startet um 11:00h.
Wer sich nochmals das erste Webinar ansehen möchte, kann dies gerne hier machen. Wir freuen uns auf eine rege Teilnahme!
NETWAYS Blog
Migration von vmWare Server nach Xen
Virtualisierung soll viele Probleme lösen. Es soll die Server besser auslasten und bei einem Ausfall der Hardware dafür sorgen, dass man ohne große Probleme die Maschine wieder ans laufen bekommt. Solange man bei einer Virtualisierungslösung bleibt, gibt es auch relativ wenig Probleme. Sollte man sich aber dazu entschließen zu wechseln, muss man einiges beachten.
Diese Woche haben wir die Migration von vmWare Server 2.0.2 nach XEN 4.0 durchgeführt. Dabei sind mehrere Dinge zu beachten. Zuerst muss man auf der vmWare Seite einiges Vorbereiten:
vmWare
Das erste, was man kontrollieren muss, ist ob das .vmdk Image aus einem monolithischen Block besteht, oder ob es in mehrere sparse files aufgeteilt ist. Dies sind in der Regel 2GB große Dateien mit Zahlen hinter der .vmdk Endung. Im ersten Fall muss man nichts weiter tun, im zweiten Fall bringt vmWare Server ein tool namens vmware-vdiskmanager mit, mit dem man diese konviertieren kann. Der Befehl hierfür lautet
vmware-vdiskmanager -r image.vmdk -t 0 image-flat.vmdk
Anschließend kann man das Image auf den Xen Server kopieren.
XEN
Da Xen mit .vmdk images nicht direkt umgehen kann, muss man es erst einmal ins raw Format konvertieren.
qemu-img convert -f vmdk image-flat.vmdk -O raw image.img
Nun muss man sich entscheiden ob man die Maschine vollvirtualisiert betreiben möchte, was für Windows die einzige Möglichkeit ist, oder ob man auch einen für Xen Angepassten Kernel zur Verfügung hat und damit auch Paravirtualisierung nutzen kann, was deutlich performanter ist. Am einfachsten ist es, wenn man diesen schon installiert hat, als die Maschine noch unter vmWare lief, es geht aber auch noch im Nachhinein. Hierzu muss man das image mounten, per chroot in das Verzeichnis wechseln und den Kernel hinzufügen.
fdisk -lu image.img //zeigt die Partitionen des Images an.
kpartx -a image.img //mapt die Partitionen des images nach /dev/mapper/loop . . .
mount /dev/mapper/loop2p1 /mnt // mountet die erste Partition des images nach /mnt
mount -t proc proc /mnt/proc/ //proc dazu mounten
mount -t sysfs sys /mnt/sys // sys dazu mounten
mount --bind /dev /mnt/dev // /dev dazu mounten
chroot /mnt // nach/mnt als root Verzeichnis wechseln
Ab hier kann man mit den Mitteln des Betriebsystems (je nachdem ob die virtuelle Maschine Debian, RedHat, Suse oder sonst etwas ist) einen neuen kernel nachinstallieren. Am Beispiel Debian:
apt-get install linux-image-2.6.32-5-xen-amd64 linux-modules-2.6.32-5-xen-amd64
Den Kernel und die ramdisk braucht man später auch außerhalb des Images, daher sollte man ihn sich z.B. nach /boot/xen kopieren
exit // beendet chroot
cp /mnt/boot/vmlinuz-2.6.32-5-xen-amd64 /boot/xen
cp /mnt/boot/initrd.img-2.6.32-5-xen-amd64 /boot/xen
Anschließend noch alles wieder unmounten und die kpartx mappings löschen
umount /mnt/proc
umount /mnt/sys
umount /mnt/dev
umount /mnt
kpartx -d image.img
Xen Konfiguration
Jetzt ist das image vorbereitet und man muss bloß noch eine funktionierende Konfiguration anlegen. Das hier abgebildete Beispiel könnte dabei als Vorlage dienen.
# image.cfg
memory = 1024
vcpus = 1
name = 'image'
vif = [ 'bridge=xenbr1,vifname=image' ]
disk = [ 'file:/xen/image.img,sda,w']
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'destroy'
kernel = '/boot/xen/vmlinuz-2.6.26-2-xen-amd64'
ramdisk = '/boot/xen/initrd.img-2.6.26-2-xen-amd64'
root= '/dev/sda1'
extra = "xencons=tty "
Achtung: ohne den letzten Eintrag hat man keine Konsole unter XEN
Eine Alternative zum booten unter Angabe von kernel und ramdisk ist die Benutzung von pygrub als bootmanager. Hierbei zieht sich pygrub den Kernel und die Ramdisk vor dem booten aus dem image und benutzt ihn einfach. Man bekommt am Anfang ein Auswahlmenü ähnlich wie bei grub. Um pygrub zu benutzen ersetzt man die Einträge kernel, ramdisk und root durch
bootloader="/usr/bin/pygrub"
Achtung: pygrub funktioniert nicht mit grub2!
Xen virtuelle Maschine starten
xm create -c image.cfg // startet die Maschine
xm list // zeigt laufende Maschinen
xm shutdown image // fährt die Maschine herunter
xm destroy image // beendet die Maschine hart (als würde man den Strom ziehen)
xm help // zeigt die übrigen Kommandos
Inventory- und Softwaremanagement für Windows… mit OpenSource!?
Die Fichtner-Gruppe ist ein Dienstleister für öffentliche- und private Infrastruktur. Die Spezialisten für Ver- und Entsorgungswirtschaft verfügen über weltweit mehr als 1.600 Mitarbeiter, welche sich international um die Planung, Beratung als auch Realisierung von Projekten kümmern.
Ein weltweit agierender Dienstleister dessen Mitarbeiter viel im Ausland tätig sind ist natürlich auf ein zuverlässiges Tool für Softwareverteilung angewiesen. Hier kommt OCS zum Einsatz. NETWAYS unterstützt die Fichtner Gruppe bei der Implementierung von OCS als Tool für Software Rollouts und GLPI als Oberfläche für Inventory jeglicher Art (Server, Clients, Drucker, Lizenzen, …).
Automatische Softwareverteilung im Intranet und Internet, automatisches Hard- und Softwareinventory und eine „schlanke“ Clientinstallation sind nur ein paar der gewünschten Anforderungen die OCS erfüllt.
Da alle guten Dinge heut zu Tage nicht „3“, sondern „virtualisiert“ sind, wurde der OCS- und GLPI Server in eine virtuelle Maschine auf einem VMware ESX Server installiert. So bleibt die Umgebung und deren Ressourcen skalierbar und dynamisch.
Wir wünschen der Fichtner Gruppe an dieser Stelle viel Spaß mit dem Tool und ein erleichtertes Arbeiten in der Zukunft und unterstützen die weitere Realisierung des Projekts natürlich gerne.
VMware via perl API und Nagios monitoren
Die Überwachung von VMware ESX Server mittels SNMP ist nicht die wahre Freude. Von Version zu Version ändern sich OIDs oder es kommen auf der selben OID andere Rückgabewerte.
Doch es gibt ja seit VMware ESX Server 2.x auch das Common Interface API. Eigentlich will man ja nur wissen ob es den VMs gut geht und wie die Lastsituation auf dem Wirt bzw. den Gastsystemen aussieht.
Für genau diesen Zweck gab es bisher keine für NETWAYS und unsere Kunden angemessene Lösung.
Wir haben jetzt auf der perl API aufbauend ein Plugin entwickelt, welches ohne größeren Aufwand den Zustand der VMs prüft. Nun ist es möglich sicherzustellen, dass bestimmte Gastsysteme laufen und gleichzeitig Graphen für CPU Last, Speicher- und Plattennutzung sowie weiterer Parameter zu erzeugen.
Um nur die Anzahl der laufenden VMs zu monitoren und sicherzustellen, dass alle Gastsysteme laufen, muss nicht extra jede Virtuelle Maschine im Monitoring konfiguriert werden, sondern es genügt mit unserem Plugin den globalen Status zu prüfen.
Darüber hinaus können aber auch pro VM Graphen für die verschiedenen Performancecounter erzeugt werden.
Wir veröffentlichen check_vmware3.pl wie immer unter der GPL auf NagiosExchange mit Dokumentation auf NagiosWiki.