Virtuozity

VMs haben virtuelle Festplatten im VMFS-Dateisystem, nämlich ihre zugehörigen VMDK-Dateien. Da diese Dateien alle Informationen einer Festplatte enthalten, entsprechen sie vom Aufbau her einer physikalischen Disk, d.h. auch VMDK-Dateien haben einen blockweisen Aufbau (sogenanntes Virtual Block Device).

Das Performance-Problem kommt dann ins Spiel, wenn man bedenkt, dass die VMDK-Datei nichts weiter ist als eine Kapselung, denn das VMFS-Dateisystem hat wiederum Blöcke auf der LUN. Wenn diese Blöcke (VM vs. Physik) jedoch nicht exakt übereinander liegen, entsteht folgender Effekt: Jeder virtuelle Block den die VM benötigt, erzeugt doppelten Aufwand im SAN, da sich der virtuelle Block ja über zwei physische Blöcke im VMFS erstreckt, die beide vom Storage bedient werden müssen.

Die Lösung dafür heißt "Storage Alignment", was nichts anderes bedeutet, als dass man diese Blöcke exakt übereinander platziert. Dummerweise ist dies bei Windows nicht standardmäßig so, was mit der Partitionierung zu tun hat. Im sogenannten "Partiton Starting Offset" wird die Anzahl der Bytes als Versatz zum Partitionsanfang festgehalten. Dieser Wert liegt normalerweise bei 32.256 Bytes und genau da liegt das Problem: Um ein Storage Alignment zu erreichen muss dieser Wert durch 4096 teilbar sein, ansonsten liegen die Blöcke nicht übereinander! Der empfohlene Wert für bisherige Windows-Systeme liegt bei 32.768 Bytes. Windows Server 2008 und Vista arbeiten anders und haben einen Standardwert von 1.048.576 Bytes eingestellt, der bereits optimal ist.

Daher empfiehlt es sich, diesen Wert bereits in seinem "Golden Master" einzustellen. Wenn Sie den Partition Offset abfragen wollen, können Sie dies entweder manuell über die "System Information" (msinfo32) unter Windows tun oder automatisiert über WMI. Hier ein einfaches Beispiel zur Abfrage über die PowerShell:

$computer = "Server1,Server2,Server3"
$namespace = "root\CIMV2"
$properties = "__SERVER,Caption,StartingOffset"
Get-WmiObject -class Win32_DiskPartition -computername $computer -namespace $namespace -property $properties


Leider können Sie den Offset nicht im Nachhinein korrigieren, stattdessen muss eine neue Fesplatte erstellt werden. Dieser Aufwand lohnt sich nur bei Systemen mit hoher I/O-Last, da diese Optimierung bei VMs mit geringem I/O keine messbaren Auswirkungen hat. Für ihr Golden Master lohnt sich der Aufwand aber auf jeden Fall. Gehen Sie dazu bitte folgendermaßen vor:

1. Booten Sie die leere VM mit Windows PE oder Bart PE.
2. Starten Sie das Programm "diskpart" über die Konsole.
3. Wählen Sie die zu bearbeitende Disk aus.
4. Geben Sie Folgendes ein: create partition primary align=32
5. Rebooten Sie die VM und installieren Sie das Betriebssystem.

Entgegen der häufigen Annahme, dass Storage Alignment nur für blockbasierten Storage (SAN, iSCSI) relevant ist, sehe ich keinen technischen Grund, warum dies für netzwerkbasierten Speicher (NFS) anders sein sollte. Die Zugriffsmethode spielt letztendlich keine Rolle, denn auch bei NFS-Storage liegen die VMDK-Dateien auf irgendeinem Dateisystem, dem wiederum physische Blöcke zugrunde liegen.

Link: http://www.run-virtual.com/?page_id=160

Grundsätzlich empfehle ich jedem, die ESX-Konfiguration innerhalb eines Clusters einheitlich zu halten. Dazu gehören vor allem die präsentierten LUNs sowie die Einstellungen der vSwitches. Natürlich sind Sonderlösungen immer denkbar, vor allem im Testumfeld, im Sinne einer stabilen Betriebsplattform würde ich jedoch in produktiven Umgebungen von abweichenden Konfigurationen absehen. Der Hauptgrund dafür ist, dass VMotion-Migrationen höchstwahrscheinlich scheitern werden, da das System die Voraussetzungen zwischen den verschiedenen Hosts vor der Migration prüft. Steht die LUN oder die entsprechende Portgroup nicht zur Verfügung, kann die Migration nicht durchgeführt werden, da die VM gar nicht betrieben werden könnte.

Lange Rede kurzer Sinn: Konfigurieren Sie Ihre Portgroups am Besten per Skript (esxcfg-vmswitch) auf der Konsole um Vertippen oder sonstige menschliche Fehler auszuschließen. Für alle, die nicht gerne auf diese Weise arbeiten empfiehlt sich der "ITQ Infrastructure Client" von Flores Eken. Mit ihm können Sie auf komfortable Weise schnell neue Portgroups für eine Vielzahl von ESX-Servern einrichten und wieder löschen. Außerdem lassen sich Portgroup-Informationen schnell zum Vergleich exportieren.

Ein weiterer Vorteil des Programms ist, dass sich beliebige Shell-Befehle für die ausgewählten Hosts ausführen lassen. Für weitere Bequemlichkeit sorgen direkte Links in die beliebten Tools "Putty" und "WinSCP". Alles in allem ein sehr empfehlenswertes Werkzeug vor allem für Shell-Einsteiger.

Link: http://www.run-virtual.com/?page_id=157

Mein geschätzter Kollege Jason Boche hat vor Kurzem einen Blog-Eintrag geschrieben, in dem er dazu auffordert Game Server zu virtualisieren. Da ich mich mit dem Thema professionellen Game Server Hostings bereits beschäftigt habe, möchte ich gerne eine Gegenposition dazu einnehmen:

Obwohl ich ein großer Verfechter von Virtualisierung bin, weiß ich um die Grenzen dieser Technologie. Grundsätzlich rate ich dringend von jeglicher Virtualisierung ab, wenn es um Echtzeitanwendungen geht, völlig unabhängig von deren Einsatzzweck. Dazu gehören alle zeitkritischen Applikationen oder Anwendungen, bei denen es auf Latenzzeiten ankommt. Einige Beispiele dafür sind VoIP, Firewalls, Game Server oder medizinische Anwendungen für Diagnostik und Operation.

Aus meiner Sicht ist hier die optimale Reaktionszeit der Anwendung höher zu bewerten als die Möglichkeiten der Kosteneinsparung durch Konsolidierung. Im Gegenteil, häufig können solche virtuellen Systeme sogar teurer werden, z.B. durch Wartungskosten aufgrund erhöhter Unzufriedenheit und Beschwerden durch Kunden. Auch wenn VMs auf den ersten Blick ein stabiles "gefühltes" Timing-Verhalten aufweisen, so ist dies jedoch praktisch nie der Fall, da wir von Abweichungen im Millisekunden-Bereich sprechen, die bei Echzeitanwendungen bereits als relevant einzustufen sind. Wer sich davon überzeugen möchte, sollte einfach mal das oben verlinkte Tool "VM Time" ausprobieren. Es ist eigentlich dazu gedacht die Zeitsynchronisation von VMs mit dem Host zu überprüfen und zeigt daher nur Abweichungen im Sekundenbereich an. Trotzdem kann man beobachten, dass ab und zu Abweichungen von bis zu einer Sekunde, also 1000 Millisekunden auftreten, was für Echtzeitanwendungen völlig inakzeptabel ist.

Speziell im Bereich Game Server Hosting ist eine Virtualisierung aus meiner Sicht zudem auch völlig überflüssig, da die verschiedenen Server problemlos auf diverse Ports verteilt werden können. Das Auffinden der Spiele durch die Spieler wird schon seit Langem über spezielle Directory Server der jeweiligen Hersteller vorgenommen, so dass keine Notwendigkeit besteht, ausschließlich den Standard-Port zu verwenden. Darüber lässt sich nach meiner Erfahrung sogar ein deutlich höheres Konsolidierungspotenzial ausschöpfen, abgesehen davon spart man jede Menge IP-Adressen.

Daher lautet mein Fazit: Never virtualize realtime applications! Diese Aussage lasse ich einfach mal in der Hoffnung stehen, dass zukünftige Technologien mich eines Besseren belehren.

Link: http://ovirt.org/

oVirt ist ein quelloffenes und plattformübergreifendes Managementsystem für Virtualisierungsumgebungen. Das Frontend besteht aus einem Web-Interface und ist komplett LDAP-integrierbar, die Steuerung erfolgt über "libvirt", eine Open Source API zur Manipulation von virtuellen Umgebungen. Dazu gehören VM Management, Aufbau einer sicheren Remote-Access-Verbindung und Storage Management. Zusätzlich beinhaltet oVirt den Datensammler "collectd" um statistische Auswertungen der Umgebung zu erstellen.

Aktuell wird leider lediglich KVM als Virtualisierer unterstützt, jedoch sollen weitere Plattformen wie OpenVZ, LXC und vor allem Xen folgen.

Link: http://www.vmware.com/products/server/

Der kostenlose Virtualisierer VMware Server steht nun in der Version 2.0 zur Verfügung und bringt einige Neuerungen und Erweiterungen mit:

• maximal 8GB RAM pro VM
• maximal 10 vNICs pro VM
• 64bit Guest OS Support
• Windows Vista Guest OS Support
• Host & Guest Support für Windows Server 2008, RHEL 4.5 - 5.1 und SLES 10.1
• unter 64bit Linux Hosts jetzt auch als 64bit-Anwendung verfügbar
• USB 2.0 Guest Support
• neues Netzwerkkonfigurationstool
• CIFS/NFS-Shares können als Speicherort für VMs verwendet werden
• Microsoft VSS-Unterstützung
• verbessertes Web-Interface

Trotz aller Verbesserungen bleiben ein bis zwei Wehrmutstropfen, denn es wurde auch etwas gestrichen: Ab der Version 2.0 keine Einbindung mehr in vCenter Server möglich. Wer die Management-Konsole der Vorgängerversion kannte, wird vermutlich auch das überarbeitete Web-Interface nicht unbedingt als Fortschritt empfinden. So ist die Netzwerkkonfiguration beispielsweise nicht integriert, sondern als separates Tool zu starten.

Fazit: Wer eine entsprechende Hardware zur Verfügung hat, sollte lieber auf den ebenfalls kostenlosen ESXi-Server setzen. Skalierbarkeit, Performance und Features sprechen einfach dafür. Der VMware Server bleibt jedoch eine gute Wahl, wenn man VMs auf jeder beliebigen Hardware betreiben können muss.