Virtualisierung

Informationen zu den Produkten Virtual PC, VM-Ware und fertigen Images finden Sie auf Produkte- VirtualPC.

Gast und Host

Der Begriff Virtualisierung steht auf dieser Seite für die Emulation eines Systems auf einem anderen System. Dabei sprechen wir von zwei Systemen:

  • Host
    Dieses System ist das aktive primäre System auf dem Server und steuert die Hardware selbst an. Das ist das System, welches sie in der Regel als erstes auf dem Server installieren
  • Gast
    Ein oder mehrere Gäste können auf dem Host gestartet werden und glauben weiterhin, Sie hätten ein eigenes System. Sie laufen als in einer eigenen virtuellen Umgebung ab und bekommen CPU, Netzwerkkarte, Speicher, Grafikarte etc. nur virtuell. Einige Lösungen simulieren hier eigene Chipsätze (z.B.: AMD-Netz, S3-Grafik), so dass die virtuellen Systeme einfach auf andere Server mit anderer Hardware umgezogen werden können.

Nicht immer sind die Begriffe so klar zu trennen.

Virtualisierungsebenen

Sicher können Sie alle VMWare Workstation um z.B. Demos auf dem gleichen System laufen zu lassen, welches auch für die tägliche Arbeit genutzt wird. Auch VirtualPC oder VirtualBox stellen solchen Dienste bereit. Aber es gibt eine ganze weitere Bandbreite von Lösungen, die auch anderen Ebenen virtualisieren. Hier eine ganz kurze Einführung:

Ebene Virtuelles System
"Hardware"-Virtualisierung		 Virtuelle Instanz
"Virtueller Server"		 Virtuelle Applikation
Produkte
  • Microsoft VirtualPC/Virtual Server
    Microsoft Hyper-V
  • VMWare Workstation/Server
    VMWare ESX
  • VirtualBox/Xen
  • QEMU
  • Und andere
  • Click2Run (C2R)
  • App-V
  • Softgrid
  • Altiris Juice
  • Thinstall
  • Ceedo
Funktionsprinzip

Bereitstellung eines kompletten virtuellen PCs als Server aber auch als virtuelle Desktops

Bereitstellung eines virtuellen Systems, welches aber auf dem gleichen Kernel läuft, d.h. jede Instanz glaubt nur einen PC für sich zu haben

Einkappselung der individuellen Applikation
Fakten
  • Sinnvoll mit passender CPU Funktion VT
  • "Hardware"-Virtualisierung
  • "Desktop"Versionen als Software eines Hostbetriebssystems oder eigenständiger Hyper-Visor als Core (Hyper-V, ESX)
  • Verschiedene Gast-OS auf einem Host möglich
  • Teilweise mit "LiveMigration" von Gast zwischen Hosts
  • Höhere Verfügbarkeit durch Failover
  • Gemeinsamer Kernel, der dupliziert wird
  • Alle Instanzen haben das gleiche OS wie der Host
  • SystemUpdates werden auf dem Host eingespielt und sind für alle Instanzen dann gültig.
  • Weniger Ressourcenverbrauch
  • Oft bei Internet Providern ("Virtual Server")
  • Jede Instanz hat seine eigene Netzwerkkarte, RAM, Speicherbereiche etc.
  • Programm muss kompatibel zum Host sein
  • Windows als Host
  • Zugriffe auf Registry/Dateisystem werden umgelenkt

So gibt es Programme wie Softgrid, die eine Virtualisierung pro Programm auf einem gemeinsamen Betriebssystem erreichen über Virtuozzo, die auf einem Server mehrere eigenständige Server darstellen bis zu Produkten wie XEN oder Windows 2008, die mit einem Hyper-Visor auch den Host auf eine virtuelle Schicht (DOM0) heben, der aber besonders privilegiert ist und die kleine Virtualisierungsschicht darunter und die parallel betriebenen Gäste kontrollieren kann. Es Grenzen sind also fließend zwischen Hardwarevirtualisierung, Systemvirtualisierung und Applikationsvirtualisierung sind also fließend. Die Überlegungen zu einer Virtualisierung sind vielfältig:

Warum Virtualisierung ?

Es gibt viele unterschiedliche Gründe, warum eine Firma über Virtualisierung nachdenkt oder sogar schon einsetzt.

  • Hardware besser nutzen (Sharing)
    Sicher.. früher wurde nach verbrauchten CPU-Zyklen abgerechnet und ein Host, der nur 5% CPU-Last hat wurde mit Verschwendung gleichgesetzt. Wenn Sie heute den Taskmanager eines Windows Servers anschauen, dann werden sie oft erkennen, dass die angezeigte CPU-Last eher niedrig ist und der "Leerlaufprozess" im Lastmanager oft die meiste CPU-Zeit beansprucht. Insofern kann man natürlich folgern, dass der PC noch weitere Aufgaben aufgebürdet bekommen kann.

Beachten Sie:
Die Belastung eines System dürfen Sie nicht alleine an der CPU festmachen. Die Last kann nämlich niedrig sein, weil die CPU auf andere Prozesse (z.B. DISK oder LAN, Pagefile) wartet. Kritischer sind aus heutiger Sicht immer die Massenspeicher und hier tun sich die meisten Administratoren schwer, diese zu "messen"

  • Leichtere Upgrades (Host tauschen)
    Wenn die virtuelle Umgebung komplett emuliert ist, dann sieht der Gast nur eine virtuelle Hardware, die auf jedem Host identisch ist. Man kann also in ein paar Jahren einfach den Host durch ein neueres leistungsstärkeres Modell ersetzen und den virtuellen Server einfach umheben. Auf ein HauptspeicherAusbau des Hosts kann man dem virtuellen Server einfach zugute kommen lassen. Auf der anderen Seite frage ich natürlich, wie lange ein solcher Server unverändert bleibt. Ich kenne sehr wenige Server, die viele Jahre "unverändert" bleiben, so dass dies wirklich ein Faktor wird.
  • Backup/Rolback (SnapShots)
    Sehr interessant ist natürlich, dass bei vielen virtuellen Systeme auch Festplatten, die der virtuelle Server sieht, auch nur "virtuell" sind. Oft kann man diese Diskdatei (VHD, VMDK) auch einfach kopieren, was faktisch einem "Clone" entspricht. Nur ein Backup ist das natürlich noch nicht. Besonders Exchange (Datenbank Transaktionsprotokolle) aber auch das Active Directory lassen sich ungerne per "Image" sichern.

"virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences für a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported."
Quelle: http://technet.microsoft.com/en-us/library/aa996719.aspx

  • Bessere Verfügbarkeit (VMotion)
    Einige Virtualisierungslösungen erlauben es, mehrere Hosts als Team zu verschalten und damit eine höhere Verfügbarkeit anzubieten. Fällt ein Host aus, dann kann der virtuelle Server auf dem anderen System schnell wieder bereit gestellt werden. Vorausgesetzt die virtuelle Disks ist für den anderen Host erreichbar (SAN oder Replikation). Einige System erlauben sogar das "Verschieben" ohne Shutdown. Der Gast wird dazu kurz angehalten, Hauptspeicherinhalte und CPU-Status zum anderen Host kopiert und dort wieder nach Sekunden fortgesetzt.
  • Unabhängigkeit von Produkten
    Wir wissen alle, dass sich bestimmte Produkte nicht auf einem Server vertragen. So ist Outlook und Exchange 2003 auf dem gleichen Server nicht erlaubt, obwohl der Server genug Leistung für beide hätte. Hier liegt der Gedanke nahe, auf einem Server einfach "zwei Server" laufen zu lassen. Sei es als zwei Gäste auf einem Host oder als ein Gast, der auf dem primären Server mitläuft. Ich habe schon gesehen, dass auf Exchange Servern einfach mit VirtualPC eine XP-Workstation mit Outlook bei Bedarf gestartet werden konnte, z.B.: um per MAPI bestimmte Aktionen durchzuführen.
  • Arbeitsplatz des Administrators
    Ein aus meiner Sicht sehr geeigneter Ansatz ist natürlich der Betrieb von Virtualisierungsprodukten auf einem Arbeitsplatz. Der Administrator kann so mit "seinem" System als normaler Benutzer arbeiten und für die Administration startet er eine virtuelle Umgebung, auf der er mit privilegierten Berechtigungen arbeitet und die Verwaltungstools hat. Es gibt Firmen, dort werden eben diese "Admin-Images" zentral bereit gestellt, damit alle Administratoren immer mit den gleichen Tools arbeiten
  • Entwicklung, Paketierung, Schulung
    Natürlich sind virtuelle Systeme auch für Entwickler und die Softwareverteilung sehr nützlich. Aber mit Servern hat das erst mal nichts zu tun. Auch für Schulungen sind virtuelle Umgebungen natürlich genial, da Sie schnell installiert sind (einfach Image kopieren) und auch schnell wieder "zurückgesetzt" werden können. Auch Microsoft stellt online Labs auf diesem Weg bereit.

Gründe gibt es also viele. Aber wie immer gibt es auch Schatten, wo so viel Licht ist.

Virtualisierung mit DC

Natürlich können auch Domain Controller virtuell betrieben werden. Es gibt sogar viele Gründe dafür einen DC virtuell zu betreiben, z.B. Um diesen Server nicht mit anderen Rollen zu beaufschlagen (Sicherheit, DomainAmin Rechte). Wer stellt schon einen extra Server nur als reiner DC hin, nur weil man aus administrativen Überlegungen keine Funktionen wie DNS, DHCP, WINS o.ä. drauf installieren möchte.

Die einzige "Gefahr" für einen DC besteht aber in einer unsachgemäßen Verwendung von Snapshots mit DCs. Ein DC mag es gar nicht, wenn er quasi einige Minuten oder gar Stunden in die Vergangenheit zurück versetzt wird. Das Problem ist, dass die anderen DCs ihn nicht mehr mitspielen lassen. Die Problemstellung entsprich auch der eine "Image Backup", was einem Snapshot sehr ähnlich ist.

Daher sollten DCs nur über die entsprechende API oder Schattenkopien (VSS) gesichert und vor allem auch wieder restauriert werden für die, die das erst verspätet lesen, gibt es gleich die passenden KB-Artikel:

  • 255504 using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
  • 555846 How to remove completely orphaned Domain Controller
  • 216498 How to remove data in Active Directory after an unsuccessful domain controller demotion

Virtualisierung mit Exchange und OCS

Da sich diese Seite primär mit Exchange im allgemeinen und Speziellen beschäftigt, möchte ich ihr Augenmerk auf eben dieses Produkt in Zusammenhang mit der Virtualisierung lenken. Die Aussagen der beiden namhaften Hersteller schicke ich einfach mal vorweg.

Announcing Enhanced Hardware Virtualization Support für Exchange 2010
http://blogs.technet.com/b/exchange/archive/2011/05/16/announcing-enhanced-hardware-virtualization-support-for-exchange-2010.aspx
UM ist nun auch virtuell supportet
DAG und Hyper-Visor-basierte Virtualisierung mit Failover ist nun supportet.

Exchange 2010 SP1 VHD ( 6 GB)
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=53f7382a-3664-4de3-8303-31e514d69f02&displaylang=en

Best Practices für Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8647c69d-6c2c-40ca-977e-18c2379b07ad
Demystifying Exchange 2010 SP1 Virtualization
http://blogs.technet.com/b/exchange/archive/2011/10/11/demystifying-exchange-2010-sp1-virtualization.aspx

Exchange kann natürlich auch auf virtuellen Systemen installiert werden. Dabei sollten Sie aber die Support Policy von Microsoft beachten:

Bei Problemen müssen Sie nachweisen, dass das Problem auch in einer nicht virtuellen Umgebung auftritt, ehe Microsoft Support aktiv wird.

Exchange in virtuellen Umgebungen und der Support für Virtualisierung von Microsoft
http://blogs.technet.com/dmelanchthon/archive/2005/10/07/412160.aspx
(Max 200 User mit Exchange 2003 SP2) Änderungen im Microsoft Support für Virtualisierung von Exchange Server
http://blogs.technet.com/dmelanchthon/archive/2005/10/31/196-nderungen-im-microsoft-support-f-252-r-virtualisierung-von-exchange-server.aspx

Exchange Server 2007 and Hyper-V
http://blogs.technet.com/scottschnoll/archive/2008/06/15/exchange-server-2007-and-hyper-v.aspx

897615 Support policy für Microsoft software running in non-Microsoft hardware virtualization software

ESX 3.5 Update 2 is on the SVVP für x86 max. 4GB and x64 max. 16 GB
http://windowsservercatalog.com/item.aspx?idItem=fb304f90-92ed-4bed-ae4f-96805c16b61c&bCatID=1521

http://technet.microsoft.com/en-us/library/cc794548(EXCHG.80).aspx
Microsoft Support Policies and Recommendations für Exchange Servers in Hardware Virtualization Environments
- UM role is not supported in a virtual environment.
- You need Exchange 2007 SP1 and Server 2008.
- VMotion is not supported für CCR and SCC clusters.

OCS 2007 R2 Virtualization Announcement
http://blogs.technet.com/ucedsg/archive/2009/05/13/ocs-2007-r2-virtualization-Announcement.aspx

Auch VMWare sichert sich ein Stück weit ab und legt den Support für Microsoft Produkte (also auch Exchange) auf die Hersteller der Hardware ab.

Support und VMWare
http://www.vmware.com/support/policies/ms_support_statement.html
Hier hat VMWare zusammengefasst, von wem Sie wann Support erhalten, wenn ihr Microsoft Windows System unter VMWare Probleme machen sollte.

Losgelöst von den rechtlichen und organisatorischen Überlegungen stellt sich natürlich generell die Frage, ob Exchange überhaupt ein Kandidat für eine Virtualisierung ist.

Ob man nun die bessere Verfügbarkeit durch Virtualisierung oder Cluster erkauft, bleibt jedem selbst überlassen. Auch Virtualisierung ist keine "Plug and Play"-Lösung. Aber konzentrieren wir und auf den Performance Faktor.

Die meisten Exchange 2003 Server kranken ja daran, dass sie "gefühlt" zu langsam sind. Häufig beschweren Sich Anwender am Popup-Fenster "Daten werden abgerufen". Der Outlook 2003 Cached Mode hilft ja solche Verzögerungen zu verbergen.

Es ändert aber nicht daran, dass Exchange, ähnlich wie SQL und Dateiserver, ein sehr "I/O-lastiges" System ist. Im Hinblick auf die Virtualisierung bedeutet dies natürlich

  • Performanceverlust durch Virtualisierung
    Jede Virtualisierung bringt etwas mehr Overhead mit. Auch wenn dies nur wenige Prozent sind, so wird ihr System zumindest nicht schneller. Zudem müssen Sie genau aufpassen, auf welchen Disks Sie die Datenbanken und Protokolle ablegen, um ihre Verfügbarkeit sicher zu stellen. Die Nutzung von RAW-Disks reduziert diesen Overhead aber raubt ihnen natürlich auch einige der Vorteile einer Virtualisierung.
  • Geringe "Koexistenz-Tauglichkeit"
    Wenn aber ein Exchange Server schon im normalen Betrieb einen dedizierten Server auslastet, dann stellt sich die Frage, welche Systeme Sie dann noch parallel auf dem gleichen Server laufen lassen wollen. Jedes weitere System knabbert RAM, CPU aber vor allem Disk-Performance.

Meine Meinung zu Virtualisierung ist geteilt. Auf der einen Seite nutze ich VMWare Workstation schon seit der ersten Version, um meine Test und DemoUmgebungen zu betreiben. Ich sehe auch immer mehr Firmen, die ausgewählte Server (meist alte Dienste) auf einer virtuellen Umgebung konsolidieren. Ich schaue mir natürlich neugierig die Server an, bei denen Schwergewichte virtualisiert wurden.

Aktuell bin ich davon überzeugt, dass Virtualisierung seinen Platz in der IT behaupten wird, aber die blinde Migrationsaktivität sich wieder normalisieren wird. Aus meiner Sicht sind Dateiserver, SQL-Server und Exchange Server keine Kandidaten für eine Virtualisierung. Andere Server können aber sehr wohl auch virtuell betrieben werden.

Es wird aber auch hier immer eine Mischform geben. Auch die Bladeserver, die vor Jahren noch in höchsten Tönen gelobt wurden, haben ihren Markt besetzt (z.B.: bei Providern oder in Verbindung mit SANs auch bei größeren Firmen). Die Mehrzahl der klassischen Mittelständler dürften aber mit klassischen Servern, die von jedermann auch bedient und betreut werden können, immer noch eine gute Wahl sein

Virtualisierung und Zeit

Viele vergessen bei der Virtualisierung das Thema "Zeit". Damit meine ich nicht die Performance eines Server oder die Zeit für die Umstellung , sondern die Zeitsynchronisation im Netzwerk. Ein PC hat eine kleine Softwareuhr, die er kontinuierlich hochzählt. Zwar haben alle PCs mittlerweile auch eine Echtzeituhr", aber in einer virtuellen Umgebung gibt es die so auch nicht nicht und würde auch nicht genutzt.

So gleichen sich alle PCs mit den Domaincontrollern ab und die wiederrum mit dem PDC-Emulator, welcher hoffentlich eine gute Quelle befragen kann. Virtuelle Systeme machen das auch aber die Zeit wird natürlich nur in größeren Abständen abgeglichen. Es kann also schon passieren, dass so ein virtuelles System um Minuten abweicht. Das habe ich selbst schon gesehen.

Die Ergebnisse reichen von Warnungen im Eventlog bis zu schweren Anmeldefehlern (Kerberos hat Probleme, wenn die Zeit > 5 Minuten abweichen). Insofern sollten Sie hier ein besonders Augenmerk drauf haben.

So können die VMWare Tools z.B. die Zeit des Gastsystems aktiv setzen. Dann muss aber der VMWare Host dir richtige Zeit haben, Zeitzonen berücksichtigen und die Korrekturen sollten "langsam" erfolgen, da auch ein hartes "Zurückstellen" nicht von jeder Anwendung akzeptiert wird

Virtualisierung und Netzwerkkarten

Natürlich muss ein VMWare oder Hyper-V-Gast auch eine Außenverbindung aufbauen können. Einige Hosts können eine entsprechende Netzwerkkarte quasi in die VM durchreichen, andere arbeiten mit virtuellen Switches, die eine Verbindung herstellen. Auch wenn das eigentlich nach "Standard" riecht, sind gerade die Netzwerkkarten und deren Einstellungen häuft doch Schuld an komischen Problemen. Hier ein paar Links.

Virtualisierung und CPUs

Heute gibt es nicht mehr nur "eine CPU". Die typische Workstation hat schon 2-4 oder mehr "Kerne" und bei Servern wird schon mit 8,12 und noch mehr Kernen gearbeitet. Wenn man von der CPU als Baustein spricht, dann ist das meist ein "Socket" und selbst ein Kern in der CPU muss nicht mehr "real" sein, wenn z.B. Hyperthreading eingesetzt wird. Ein CPU-Kern teilt sich logisch in zwei Kerne auf, damit Programme virtuell nebeneinander laufen können. Aber damit verdoppelt sich nicht die Geschwindigkeit. Wie so oft gibt es "Sonderfälle".

Sobald ein Server mehr als 1 Socket hat, gibt es zwei oder mehr CPUs, die aber nicht mehr den gleichen internen Cache benutzen,. Ab dem Moment ist z.B. zu beachten, auf welchem Socket ein Prozess läuft und mit welchen anderen Sockets dieser kommuniziert. Auch ist der Hauptspeicher in der Regel zwischen den Sockets geteilt und ein Zugriff einer CPU auf den Speicher der anderen CPU muss über einen eigenen Bus gehen. Eine Virtualisierung sollte hier schon die "Grenzen" der Physik kennen und die VMs entsprechend zuweisen.

Manchmal kann es sogar schneller sein, wenn ein Gast weniger CPUs hat. Mit sehr viele CPUs, die vielleicht mit anderen VMs gemeinsam genutzt werden, kann ein Host im ungünstigen Fall sogar ausgebremst werden, weil er auf ausreichend Cores für die Ausführung der Arbeit warten muss. Auch beim RAM gibt es immer wieder interessante Grenzen. So soll es Server geben, die nur bis 640GB optimal laufen. Mehr Speicher macht den Server angeblich sogar langsamer. Da fragen sie am besten ihren Hardware-Spezialisten.

Mit der Virtualisierung hat der Host natürlich den Zugriff auf die realen CPUs und verteilt deren Ressourcen. Ein Taskmanager unter Windows zeigt ihnen schon alle CPUs und deren Auslastung an. Ich habe mich mal gefragt, was ein Gast unter "VMWare" eigentlich hier sieht. Denn unter VMWare wird die Auslastung der CPUs nicht in Prozent sondern in Gigahertz gemessen. Wenn mir der Host nur 50% der Leistung gibt, sehe ich dann bei einer "halben" Last im Taskmanager eine 100% Auslastung. Ich habe daher in VMWare als auch in Perfmon die CPU-Gesamtlast anzeigen lassen und folgendes Bild bekommen.

Die Linien sehen sich schon sehr ähnlich. Während Windows hier ca. 40% Last anzeigt, gibt VMWare ca. 12000;MHz (12 GHz) aus. Wenn die Windows Anzeige also 100% erreichen sollte, müsste in VMWare die last auf ca. 30 GHz ansteigen. Die Anzeige von VMWare und die Windows Anzeige scheinen also synchron zu laufen. Windows misst die Zeit, wann Prozesse aktiv sind und VMWare misst die Takte, die von den zugewiesenen CPUs durch diese VM belegt sind.

Weitere Links