Die Risiken der Server-Virtualisierung: Vorsicht Virtualisierung!

Server-Virtualisierung kann Unternehmen viele Vorteile bringen. Doch es gibt Kosten- und Betriebsrisiken, die IT-Verantwortliche kennen sollten. [...]

Server-Virtualisierung gilt Vielen als Universalwaffe gegen ausufernde IT-Kosten und komplexe Serverstrukturen. Die Schattenseiten der Technik und ihres Einsatzes werden jedoch oftmals übergangen. Denn virtualisierte Infrastrukturen bringen ihre eigenen Schwierigkeiten mit sich – von Security-Problemen über hohe Anforderungen an Ausfallsicherheit und Desaster Recovery bis hin zu diffizilen Lizenzierungsthemen. Die Nutzenpotenziale wie Kostenersparnis und flexibilisierten IT-Einsatz kann nur erreichen, wer die Risiken kennt und die typischen Fallen vermeidet.
Aktuelle Whitepaper zum Thema Virtualisierung:

• Ratgeber zur Überwachung virtualisierter Umgebungen
• Schnellere SAP-Entwicklung mit Virtualisierung
• Datensicherung im Virtualisierungs-Zeitalter

FALLE 1: ALTER WEIN IN NEUEN SCHLÄUCHEN
Am Anfang steht die Erkenntnis, dass viele der Gesetzmäßigkeiten für physische Rechner und Server, welche jeweils für eine einzelne Applikation zuständig waren, in virtualisierten Umgebungen nicht mehr zutreffen. Viele der Tools, Organisationsvorgaben und Denkweisen der vorvirtualisierten Zeit sind mit modernen Umgebungen nicht mehr kompatibel. Die Technik allein – also der Hypervisor -kann keine Revolution im Rechenzentrum bewirken und quasi im Vorbeigehen Kosten sparen. Auf eine kurze Formel gebracht: virtuell ist nicht physisch.
Ein Hypervisor macht noch keine moderne IT-Umgebung
Während die Abkoppelung der Server von der Hardware erhebliche Vereinfachungen und mehr Flexibilität mit sich bringt, steigen die Anforderungen an intelligentes Management und Automatisierung der neuen Umgebung:
VM-Schwemme: Die Leichtigkeit, mit der Server in virtuelle Maschinen (VMs) verlagert werden, führt am Ende oft zu mehr Aufwand bei der Administration, weil plötzlich mehr (virtuelle) Server vorhanden sind als vorher und somit die schiere Masse der Systeme verwaltet werden muss. Damit verbundene Probleme: fehlender Überblick – zum Teil können virtuelle Maschinen nur am Dateinamen oder einigen wenigen Metainformationen identifiziert werden -, übermäßiger Verbrauch von Speicherplatz, Update- und Pflegebedarf. Organisatorische Maßnahmen und Policies sollten von Anfang an greifen, um dies zu verhindern. Zudem sollten Organisationen geeignete Tools für das Management virtueller Umgebungen evaluieren, um technische Unterstützung in Anspruch zu nehmen.
Neue Tools und Prozesse: Neue Möglichkeiten wie flexible Provisionierung, das Bereithalten von Images oder die Migration von VMs von einem Rechner zum anderen erfordern entsprechende Werkzeuge und neue Policies, mit denen die Kontrolle über das Gesamtsystem gewährleistet werden kann. Ohne Standardisierung von Prozessen und Umgebungen geht nichts.
Ausfallrisiko: Die Abhängigkeit von einigen wenigen Servern macht verletzlich. Virtualisierte Umgebungen fassen viele Server auf wenig Hardware zusammen. Dies impliziert, dass viele Server ausfallen, wenn ein Rechner ausfällt. Deshalb sind hohe Anforderungen an die Ausstattung und die Mechanismen für Hochverfügbarkeit herzustellen. Als Grundlage benötigen IT-Organisationen dafür Shared Storage in Form eines SANs (Storage Area Network), meist auf Basis von Fibre Channel oder iSCSI-Techniken. Das Speichernetz muss ebenfalls hochverfügbar ausgelegt sein.
Storage im Auge behalten, Storage virtualisieren
Server-Virtualisierung kann nicht ohne ein ausgefeiltes Storage-System gelingen. Lokaler Festplatten-Speicher genügt dabei nicht für anspruchsvolle Systeme, die den Anforderungen von Hochverfügbarkeit, dynamischer Lastverteilung und hochgradiger Automatisierung entsprechen sollen. Shared Storage ist unabdingbare Voraussetzung. Ansprüche an solchen Speicher sind Zuverlässigkeit und Ausfallsicherheit, aber auch Flexibilität sowie Kostenkontrolle. Gerade in virtualisierten Umgebungen kann der Speicherbedarf explodieren.
Gefragt sind deshalb Konzepte zur effizienten Speichernutzung sowie zur transparenten Integration verschiedener Systeme auch unterschiedlicher Hersteller zu einem Gesamtsystem. Diese Anforderungen lassen sich nur mit Storage-Virtualisierung realisieren, welche systemübergreifend durch eine zusätzliche Softwareschicht von der zugrundeliegenden Hardware abstrahiert. Zugreifende Systeme und Anwendungen werden von der Hardware getrennt. Dies hat viele wichtige Effekte: das Einrichten logischer Speicherbereiche (LUNs), Plattenerweiterungen oder die Migration von Daten lassen sich ohne physische Eingriffe bewerkstelligen, viele Managementprozesse laufen unterbrechungsfrei. Wie auch bei der Server-Virtualisierung verbessert Storage-Virtualisierung die Verfügbarkeit, ermöglicht die Umsetzung von HA-Szenarien (High Availability) und steigert die Auslastung des Speichers erheblich.
Gefährdete Sicherheit: Während die Betriebssicherheit insgesamt durch Implementierung von HA-Mechanismen gewährleistet und gegenüber rein physischen Servern erhöht werden kann, bietet die zusätzliche Hypervisor-Softwareschicht potenziell neue Angriffsflächen für Angriffe auf die System- und Datensicherheit. Was früher Blech war, manifestiert sich nun als reines Datenobjekt: Der ehemalige Server wird reduziert auf eine Datei, die sich kopieren, verschieben und löschen lässt, was neue Sicherheitsprobleme eröffnet. Neben rein technischen Sicherheitslücken reißen oft Managementprobleme weitere Löcher in die Security: So sind oftmals die Security- und Compliance Fachleute nicht bei der Konzipierung und Einführung von Virtualisierungs-Setups im Boot. Dies setzt sich fort bis in das Netzwerkmanagement, wo teilweise unterschiedliche Teams für das Aufsetzen und Verwalten der neuen virtuellen Netzwerke neben den vorhandenen physischen Netzwerkstrukturen zuständig sind und sich dabei unvermeidlich ins Gehege kommen. Administratoren der VMs sind nicht zwingend auch die Verwalter der Server-Infrastruktur; jedoch werden bei Einführungsprojekten diese Rollen oftmals leichtsinnig vermischt, so dass hierdurch Teile der bis dato implementierten Sicherheitsarchitektur ausgehebelt werden.
FALLE 2: FALSCHE UND ÜBERTRIEBENE ERWARTUNGEN
Die Virtualisierungs-Euphorie verleitet Unternehmen dazu, mit verfehlten und zum Teil auch übertriebenen Erwartungen sowohl an die Fähigkeiten der Technik als auch die potenziellen Nutzeneffekte heranzugehen. So werden bei der Planung und Einführung virtualisierter Server oftmals die Konsolidierungsfähigkeiten der neuen Infrastruktur überschätzt, was teilweise von optimistischen Herstelleraussagen gefördert wird. Mögen in Test-Setups und unter Laborbedingungen problemlos bis zu 50 verschiedene VMs auf einem Rechner ausreichend schnell und stabil laufen, werden in realistischen Produktions-Szenarios deutlich geringere Konsolidierungsraten erreicht. Für den Betrieb von ressourcenintensiven geschäftskritischen Applikationen ist eine Beschränkung auf 6 bis 8 VMs je Rechner durchaus üblich. Wird hier im Vorfeld von höheren Konsolidierungsraten ausgegangen, droht eine Kostenexplosion, da letztlich doch mehr Rechner bereitgestellt werden müssen, die wiederum mehr Storage, Netzwerk-Kapazität, Lizenzen und Administration benötigen.
Gerade zu Beginn von Virtualisierungsvorhaben werden oft eher weniger ausgelastete und weniger kritische Server auf virtuellen Systemen konsolidiert, was meist gut funktioniert. Zu Problemen kommt es, wenn diese Ratios in späteren Projektphasen auf hochgradig ausgelastete Mission-Critical-Systeme mit womöglich hohen Anforderungen an die Netzwerkbandbreite übertragen werden. Dies führt zwangsläufig zu eklatanten Flaschenhälsen.
Als Faustregel sollten virtualisierte Rechner so geplant werden, dass maximal 60 Prozent der physischen Ressourcen ausgelastet werden. Damit erreicht man immer noch hohe Konsolidierungsraten, hat aber gleichzeitig genügend Reserven. Entsprechend erhöhte Kosten sind dafür einzuplanen.
Projektkiller Server- und Netz-Performance
Virtualisierung bedingt durch die zusätzlich eingezogene Softwareschicht prinzipiell eine verringerte Performance bei Rechenleistung und Netzwerkdurchsatz. In gut konzipierten Infrastrukturen, bei denen auch die technischen Komponenten optimal aufeinander abgestimmt sind, macht sich dies nicht oder kaum bemerkbar. Gibt es aber nur in einer der vielen Komponenten einen Ausreißer, kann dies die Leistung der gesamten Umgebung so negativ beinträchtigen, dass ein Einsatz unter produktiven Bedingungen unmöglich wird. Probleme entstehen dabei vorrangig bei der Netzwerkanbindung sowie beim Speicher-I/O. Vor allem das Storage-System muss performance-optimiert sein für die virtualisierte Umgebung. Das Zugriffsmuster der virtualisierten Umgebung auf den Speicher ist dabei ein zentraler Faktor. Zumeist handelt es sich dabei um Random I/O. Für dieses ist nicht die Übertragungsbandbreite entscheidend, sondern die Anzahl möglicher Input/Output Operations (I/O) pro Sekunde.
Zudem sind nicht alle Workloads und Server für die Virtualisierung geeignet. Virtualisierungskandidaten sollten Projektverantwortliche neben der technischen Ablauffähigkeit vor allem unter Performance-Gesichtspunkten aussuchen. Ist ein physischer Server bereits bei mehr als 50 Prozent CPU-Auslastung und verlangt nach mehr als 6 oder 8 GB RAM, scheidet er als Kandidat vermutlich aus, denn die virtuelle Umgebung kann nie schneller sein als die darunter liegende Physik. Zudem kann das Ziel der Konsolidierung nicht erfüllt werden. Gleiches gilt für eine hohe I/O-Auslastung.
Virtualisierung: Hilft der Hersteller oder hilft er nicht?
Gerade Virtualisierungs-Einsteiger können von dem Umstand überrascht werden, dass viele Softwarehersteller den Support ihrer Lösungen in virtuellen Umgebungen noch sehr restriktiv behandeln. Manche Player wie SAP, IBM oder Oracle unterstützen offiziell die marktführenden Hypervisor von Microsoft, VMware und Citrix (Xen) für den Betrieb ihrer Produkte, andere Virtualisierungsanbieter bleiben außen vor. Einige Hersteller behalten sich im Supportfall vor, dass ein bislang „unbekanntes“ Problem zunächst auf einem physischen Server nachgestellt und Unterstützung erst geleistet wird, wenn keine Verbindung des Problems mit dem Hypervisor besteht. Besonders pikant ist diese Handhabe bei Oracle – der Datenbankhersteller nimmt lediglich seinen eigenen Hypervisor „Oracle VM“ von diesem Zwang aus.
Die „S-Frage“ kennt weitere Spielarten: Bei manchen Systemen, darunter etwa einige gängige Linux-Distributionen, steht der technische Support außer Frage, bringt aber zusätzliche Kosten mit sich: Denn man kann zwar kostenfrei weitere Instanzen seiner virtuellen Server erstellen, muss dann aber für jeden weiteren Server – sei er physischer oder virtueller Natur – für die Herstellerunterstützung zahlen.
FALLE 3: FEHLENDES TECHNISCHES KNOW-HOW
Zu Beginn von Virtualisierungsprojekten werden oft der Administrationsaufwand und die mit der technischen Umgebung verbundene Komplexität unterschätzt. Kommen Mängel im Detailwissen dazu, sind Probleme und unkalkulierbare Risiken vorprogrammiert. Die Technik hält genügend Fallstricke bereit für diejenigen, die die Details unterschätzen. Ein Beispiel: Einen großen Zusatznutzen bezieht die Virtualisierung aus der Fähigkeit, VMs zwischen Rechnern hin- und her zu verschieben. Die Voraussetzungen dafür sind jedoch zahlreich: So müssen die beteiligten Rechner mit demselben Hypervisor ausgestattet sein, zu einem Pool gekoppelt und mit einem Netzwerk-Storage verbunden sein. Zudem müssen die CPUs der beteiligten Rechner „gleichartig“ sein, das heißt zumindest derselben Familie angehören. Als Fallstrick kann sich dabei die nachträgliche Erweiterung von Pools um weitere Rechner herausstellen: Sind darin trotz des gleichen Rechnermodells nur leicht verschiedene Prozessoren verbaut, kann es sein, dass der Hypervisor den Motion-Prozess der VM verweigert.
Die liebe Not mit dem Backup
Wie eine Studie von Kroll Ontrack zeigt, gehen in virtualisierten Umgebungen besonders oft Daten verloren. Als Ursache wurden dabei in den meisten Fällen menschliche Fehler wie versehentliches Löschen von VMs ausgemacht. In einem Viertel der Fehler sind Hardware-Defekte die Ursache – was zeigt, dass Backup- und DR-Verfahren (Disaster Recovery) in virtuellen Umgebungen noch nicht genügend etabliert sind. Aus Mangel an Kenntnis werden oftmals die Anforderungen an das Backup von VMs und deren Rücksicherung stark unterschätzt. Diese sind in Teilen anders als in rein physischen Setups, so dass die Prozesse für Sicherung, Rücksicherung und Disaster Recovery entsprechend neu definiert werden müssen. Wichtig zu wissen ist zum Beispiel, dass Backup-Vorgänge zu Ressourcen-Engpässen führen können, da virtualisierte Server und die betreffenden Netzwerkpfade per se stärker ausgelastet sind.
FALLE 4: SOFTWARELIZENZEN UND VIRTUALISIERUNG
Mit dem Verlagern existierender Server und Applikationen in eine virtuelle Umgebung ergeben sich häufig sowohl bei Betriebssystemen als auch bei der Anwendungssoftware zusätzliche Lizenzkosten oder zumindest geänderte Lizenzbedingungen. Hier tappen unbedarfte Virtualisierungs-Einsteiger unter Umständen in die Kosten-, zumindest aber in die Compliance-Falle.
Zwei Lizenzierungsmodelle sind in der Softwarewelt weit verbreitet: die Ermittlung der Kosten nach Anzahl der Prozessoren sowie die Koppelung der Lizenz an einen bestimmten Rechner. Beide Ansätze sind auf virtuellen Systemen oftmals obsolet. Denn in aller Regel werden im virtuellen Server mehrere Prozessoren oder Kerne genutzt. Zum anderen ist gerade ein Nutzenaspekt der Virtualisierung die Fähigkeit, VMs nach Bedarf zwischen einzelnen Servern hin und her verschieben zu können, sei es zur Lastverteilung oder um ungestört anstehenden Wartungsaufgaben nachgehen zu können.
Dessen ungeachtet kann es sein, dass sich mehrere virtuelle Maschinen einen einzigen Prozessor teilen und der Anwender trotzdem die volle Gebühr je Prozessor entrichten muss. Oder aber eine VM ist nur zu bestimmten Zeiten aktiv und läuft in der übrigen Zeit nicht. In vielen dieser Fälle zahlt der Anwender „gefühlt“ zu viel. Am Markt hat sich bislang noch kein einheitliches, auf Virtualisierung abgestimmtes und für den Anwender faires Modell durchgesetzt. Die Softwarebranche versucht sich derzeit noch an unterschiedlichen Ansätzen, etwa der Abrechnung nach tatsächlicher Nutzung („pay per use“).
Wichtig für IT-Verantwortliche ist, den Skalierungseffekt im Auge zu behalten: Steigt die Anzahl virtueller Maschinen im Laufe der Zeit an, wachsen die Kosten linear, falls für jede VM die volle Lizenz bezahlt werden muss. Günstig ist es dann, wenn man zu einem Lizenzmodell findet, bei dem eine größere oder gar unbegrenzte Anzahl von Instanzen eines Systems auf einem Server laufen darf. So kann es sich beispielsweise lohnen, statt viermal einen Windows 2008 Server zu kaufen, nur einmal die Enterprise-Version zu erstehen, da diese in bis zu vier virtuellen Maschinen zugleich benutzt werden darf. Die Datacenter-Version erlaubt eine unlimitierte Anzahl Instanzen des Betriebssystems in virtuellen Umgebungen (siehe hierzu: Licht im Microsoft-Lizenzdschungel).
Dass der Lizenz-Teufel im Detail steckt, zeigt sich gerade bei der Microsoft Windows Server 2008 R2 Datacenter Edition sehr deutlich: die Aufhebung der Limitierung gilt nur bei einer korrekten Lizenzierung. Diese setzt den Erwerb einer Lizenz je CPU-Sockel voraus. Zu beachten ist dabei die Mindestzahl von zwei CPU-Lizenzen pro Server. Ein Server mit einem Sechs-Kern Prozessor benötigt somit zwei Lizenzen für Windows Server 2008 R2 Datacenter Edition. Und – Achtung – einen zweiten Prozessor gleicher Bauart, da eine Installation nur auf einem Rechner mit mindestens zwei Sockeln erfolgen darf. Sollen solche Windows Server 2008-VMs auf einen anderen Host verschoben werden, muss auch der Zielhost über eine entsprechende Datacenter Lizenzierung verfügen.
Ein weiterer Effekt stellt sich durch die erweiterten technischen Möglichkeiten der Virtualisierungsumgebung ein: Betreibt ein Kunde bislang einen Hardware-basierender Server mit 32-Bit-Architektur und will im Zuge der Migration in die virtuelle Welt die Vorteile von 64 Bit-Architekturen nutzen, so muss er für eine neue Betriebssystemlizenz zumeist erneut in die Tasche greifen. Dies gilt beispielsweise bei Windows-Servern auch dann, wenn mehr Speicher als 4 GB RAM genutzt werden soll – dann steht der Kauf einer der Enterprise Varianten des Betriebssystems an, was die Projektkosten drastisch in die Höhe treiben kann.
Lizenzierung von Anwendungen
Auch die Lizenzmodelle von Applikationen und Instrastrukturbestandteilen wie Datenbanken sind häufig noch auf die Welt der physischen Rechner ausgerichtet und noch nicht an die Anforderungen der dynamischen virtualisierten Umgebungen angepasst. Für Anwender von Server-Virtualisierung ergibt sich daraus neben komplexen Lizenzbedingungen und dem fehlendem Überblick oft ein unerwartet hoher Kostenfaktor. Probleme ergeben sich vor allem auch wegen der engen Bindung der Lizenzen an die zugrundeliegende Hardware, insbesondere die CPU-Leistung. Dies führt etwa dann zu Schwierigkeiten, wenn nur Teile der physischen Kapazität genutzt – und lizenziert – werden sollen.
Beispiel 1: Wird eine Anwendung in sechs virtuellen Maschinen eines Servers mit Quadcore-CPU eingesetzt, sind je nach Lizenzbedingungen auch dementsprechend bis zu vier oder sechs Lizenzen für die Software erforderlich.
Beispiel 2: Für Disaster-Recovery- oder Backup-Zwecke werden bevorzugt Clones von virtuellen Maschinen erstellt und offline gespeichert. Die Verwendung einer Backup-Software würde je nach Lizenzmodell eine Lizenz für jede dieser VMs erfordern, was zum echten Kostenfaktor werden kann. Jedoch passen die Softwarehersteller nach und nach ihre Modelle den neuen Gegebenheiten an. So hat zum Beispiel Acronis mit der Virtual Edition eine Lizenz für seine Backup-Lösung im Angebot, die die Sicherung und Wiederherstellung von bis zu 99 VMs erlaubt – zu einem festen Preis. Voraussetzung: Die VMs müssen sich auf demselben physischen Rechner befinden.
Ein weiteres Problem kann dadurch entstehen, dass eine Leistungsbegrenzung einer VM oft nicht oder nicht ausreichend möglich ist. Wird eine Anwendung dann in einer viel zu „groß“ ausgelegten VM betrieben, kann dies Wartungs- und Support-Verträge beträchtlich verteuern.
Lizenzierung von virtualisierten Datenbanken
Der virtuelle Zwist zwischen Herstellern und deren Kunden zeigt sich besonders an der Lizenzierung von Datenbanken auf virtuellen Servern. Sofern nicht nach dem Hard Partitioning verfahren wird (dies setzt eine Segmentierung des Servers auf einigen wenigen zertifizierten Hypervisoren voraus), wendet etwa Oracle das Soft Partitioning an. Dieses besagt, dass alle im Server vorhandenen physischen Prozessoren oder deren Kerne lizenziert werden müssen. Das gilt unabhängig davon, wieviele CPUs die VM, in der die Datenbank läuft, tatsächlich adressiert und nutzt.
Bei IBM greift ein ähnliches Modell, jedoch wird beim Soft Partitioning anhand des IBM License Metric Tool die maximale tatsächliche Prozessornutzung durch die Datenbank ermittelt und nur diese lizenziert.
Microsoft unterscheidet die Server+CAL-Lizenzierung sowie die Prozessor-Lizenzierung. Mit der ersten Variante lizenziert der Anwender die User oder Geräte mittels CALs (Client Access License) sowie die notwendige Anzahl von Server-Lizenzen. Im zweiten Modell werden die VMs gezählt. Für die SQL Server Standard Edition ist je virtueller Umgebung eine Server-Lizenz notwendig. Mit einer Lizenz können bis zu vier virtuelle Betriebsumgebungen innerhalb einer physischen Server-Umgebung betrieben werden.
Beim Prozessormodell erfolgt die Lizenzierung auf Basis der physischen CPU-Kerne oder auf Grundlage der von den VMs genutzten virtuellen CPUs (vCPU). Bei der Enterprise Edition müssen je Prozessor mindestens 4 Kerne lizenziert werden. Wenn alle Kerne eines Rechners lizenziert sind, erwirbt man automatisch eine unlimitierte Zahl Lizenzen auf diesem Host. Alternativ können Kunden die virtuellen CPUs einer SQL-Server-VM lizenzieren, jedoch auch hier mindestens vier davon! Hier laufen Anwender Gefahr, Lizenzen zu bezahlen, die sie nicht brauchen, da viele SQL-Server Installationen gut mit 1 bis 2 Cores auskommen. Darüber hinaus ist ein Software Assurance (SA)-Vertrag erforderlich, um die VM-Mobilität (vMotion/Livemigration) öfter als einmal alle 90 Tage durchführen zu dürfen.
FAZIT
Die Vorteile der Virtualisierung können Unternehmen nur bei optimaler Anwendung auf allen Ebenen ernten. In vielen Fällen sind die IT-Prozesse noch nicht auf die speziellen Anforderungen virtueller Infrastrukturen ausgelegt. Neben der technischen Infrastruktur sollten IT-Verantwortliche vor allem für neue Denkprozesse, entsprechendes Know-how und Sensibilisierung sorgen. Auch organisatorische Strukturen sind an die neuen Anforderungen anzupassen.
Checkliste Lizenzkosten und Virtualisierung

• Unterschätzen Sie die Komplexität dieses Themas nicht und beziehen Sie die Ermittlung der indirekten Lizenzkosten von vorneherein in die Planung ein.
• Prüfen Sie, ob zusätzliche oder erweiterte Lizenzen benötigt werden. Beachten Sie dabei alle Systemebenen: Betriebssystem, Infrastruktur, Anwendungen.
• Seien Sie gerade bei älteren Betriebssystemversionen sowie Applikationen auf größere Restriktionen oder Kosten gefasst.
• Bedenken Sie, dass das Ausnutzen weitergehender Fähigkeiten der neuen Plattform (RAM, CPUs, Verteilung) teilweise von zusätzlichen Kosten begleitet wird.
• Beachten Sie, dass bei Pay-per-Use Modellen die Kosten nur schwer vorherzusagen und damit zu kontrollieren sind.
• Verlangen Sie eine Lizenzierung ohne Mobilitätsbeschränkungen für die VMs.
• Wenn möglich wählen Sie eine Lizenzierung auf Basis von Named Users statt auf Basis der verwendeten Prozessoren.
• Setzen Sie auf ein zentrales Lizenz-Management. Verwenden Sie durchgängig ein Software Asset Management Tool, um die Lizenzierung aller Maschinen zu überwachen und zu optimieren.

* Andrej Radonic ist freier Autor in Köln und Verfasser des Buchs Xen 3.2. Der Artikel stammt von der deutschen Computerwoche.