Für AMD und Intel ist die Virtualisierung der Prozessoren der nächste „große Schritt“. Ende 2005 soll es erste virtualisierbare CPUs von Intel geben, AMD folgt 2006. IBM praktiziert die Virtualisierung von CPUs dagegen schon seit Jahren. Und IBMs aktuelle eServer mit POWER5-Prozessoren bieten noch weit mehr.
So lässt sich ein POWER5-Server in eine Vielzahl von virtuellen Servern aufteilen, die absolut unabhängig voneinander agieren. Nicht nur der Prozessor wird virtualisiert, sondern auch die Netzwerk- und I/O-Controller sowie die Festplatten. Dies alles handhaben IBMs POWER5-Server bei Bedarf dynamisch, um Ressourcen dort bereitzustellen, wo sie gerade benötigt werden.
Denn viele Unix-Systeme sind oft lediglich zu zehn bis 15 Prozent ausgelastet - eine aus Sicht der Effizienz und Wirtschaftlichkeit nicht akzeptable Quote. Ein entsprechend großes Interesse besteht somit an Systemen und Verfahren, mit denen sich eine bessere Ausnutzung der teuren Ressourcen erzielen lässt. Dem trägt IBM bei den POWER5-Systemen mit der so genannten Virtualization Engine Rechnung.
Virtualisierung = Entkoppelung der Hardware
Die Vorteile der Virtualisierung sind vielfältig. So wird bei Bedarf schnell ein neuer Server aufgesetzt – ohne zusätzliche oder neue Hardware. Dies ermöglicht den unkomplizierten Einsatz neuer Applikationen oder Tests. Außerdem lassen sich im Betrieb befindliche virtuelle Server flexibel, schnell und dynamisch an Workload-Schwankungen anpassen.
Die Komponenten herkömmlicher Rechner besitzen von der Hardware bis hin zur Applikation eine „starre“ Verbindung, und so eine direkte Abhängigkeit voneinander. Wird beispielsweise durch Ausfall einer Komponente eine Verbindung unterbrochen, stoppt das Gesamtsystem.
Die Virtualisierung ereicht eine Entkoppelung der „starren“ Verbindung zwischen der Hardware und den Applikationen. Beim Ausfall einer Hardware-Komponente ist die Applikation nicht direkt davon betroffen. Die vom System erzeugten virtuellen Ressourcen besitzen nicht mehr den Einfluss auf die Applikationen wie die physischen Ressourcen.
Virtualisierungskomponenten stellen virtuelle Ressourcen bereit, die die gleichen Eigenschaften wie die physikalischen Ressourcen haben, aus denen sie entstanden sind. Die Virtualisierung bewirkt eine Trennung von direkt abhängigen Komponenten - Hardware, Firmware, Software. Die Herausforderung der Implementierung ist dabei, die absolute Transparenz der Virtualisierungsschicht zu gewährleisten.
Ein früher Vertreter der Virtualisierung ist die RAID-Technologie bei Festplatten. Durch spezielle Controller findet die Entkoppelung der realen Platten zum Betriebssystem hin statt. Das Betriebssystem hat nur noch Zugriff auf die bereitgestellten virtuellen RAID-Platten. Der Ausfall eines einzelnen physikalischen Laufwerks hat für das Gesamtsystem keine Folgen. Die Festplatten lassen sich im Betrieb reparieren, austauschen oder vergrößern, ohne dass das zugreifende Betriebssystem etwas davon bemerkt.
Virtualisierung in POWER-Systemen
In ähnlicher Art und Weise wie bei RAIDs erfolgt die Unterteilung von SMP-Rechnern in logische Partitionen (LPAR). Dies ist aber umgekehrt zur RAID-Technologie zu sehen. Entsteht bei den RAID-Platten aus vielen physikalischen ein logisches Laufwerk, so werden beim Partitionieren aus einem großen SMP-System viele kleine logische Partitionen erzeugt. Jede Partition stellt einen eigenständigen und absolut getrennten Rechner zu den anderen Partitionen dar.
Die Funktion des RAID-Controllers bei den Platten übernimmt beim logischen Partitionieren von SMP-Systemen eine Virtualisierungsschicht, der so genannte Hypervisor. Bei IBMs POWER5-Systemen ist der Hypervisor eine Firmware, die die Steuerung dieser komplexen Vorgänge verwaltet.
Der Hypervisor verwaltet die Hardware in Bezug auf die logisch auf dem Server befindlichen Partitionen. Welche Hardware-Komponenten zu welchen Partitionen gehören sollen, definiert der Administrator über die „Hardware Management Console“ HMC.
Die Steuerung des definierten Gesamtsystems erledigt im Betrieb nur noch der Hypervisor. Die auf den Partitionen installierten Betriebssysteme „glauben“, sie befinden sich allein auf dem Gesamtsystem. Wie bei Systemen ohne Hypervisor stellt das Betriebssystem in den LPARs den installierten Applikationen die vordefinierten und somit bekannten Ressourcen zur Verfügung.
Erst wenn der Hypervisor einer LPAR eine weitere Hardware-Ressource zuordnet, erkennt das Betriebssystem diese und kann sie benutzen. Dies ist bei einem „Stand-alone“-System gleichzusetzen mit dem Einbau neuer Hardware.
HMC und Hypervisor
Die Konfigurationen der logischen Partitionen (LPARs) und der Regeln erfolgt bei POWER5-Systemen auf der Hardware Management Console (HMC) per grafischer Oberfläche oder Kommandozeile. Die HMCs an den POWER5-Systemem sind über ein privates Administrations-Ethernet angebunden. So entsteht ein Flexibilitätsvorteil, denn die HMC lässt sich ortsunabhängig aufstellen.
Ein Remote-Zugriff auf die HMC ist über OpenSSH direkt möglich. Die Virtualisierungsschicht - der Hypervisor - ist in den POWER4- und den POWER5-Systemen nicht identisch. Die POWER5-Systeme sind so konzipiert, dass sie nicht mehr wie die POWER4-Systeme im so genannten „Full System Mode“ als Gesamtsystem ohne Hypervisor arbeiten können.
Die Ressourcen der POWER5-Systeme steuert immer der Hypervisor, auch wenn das System als eine einzige LPAR gefahren wird. POWER5-Systeme benötigen somit in fast allen Fällen eine Hardware Management Console (HMC) für den Betrieb. Mit einer HMC lassen sich POWER4- und POWER5-Systeme nicht gemeinsam administrieren.
Micro-Partitioning
Seit 2001 können IBMs eServer mit POWER4-CPUs logisch partitionieren. Als kleinste Einheit lässt sich ein Prozessor für eine LPAR wählen. Des Weiteren erfolgt die Zuordnung von Hauptspeicher und I/O-Adapter an die LPARs vollkommen unabhängig.
Die POWER5-Technologie ermöglicht das beim Mainframe schon bekannte Micro-Partitioning. So lassen sich sehr kleine Partitionen erzeugen - bis zu einem Zehntel einer physikalischen CPU. Beispielsweise sind auf einem POWER5-16-Wege-Server bis zu 160 Partitionen möglich. Die Virtualisierung erfolgt über den POWER-Hypervisor. Die Partitionen werden im Zeitscheibenverfahren ihren definierten Prozessoren zugeordnet.
Drei Partitionen sind in gleichen Teilen einem Prozessor zugeordnet, um ein Beispiel zu nennen. Der Hypervisor sorgt nun dafür, dass jede Partition die POWER5-CPU jeweils zu einem Drittel ihrer Gesamtleistung erhält. Die Granularität der Maschine selbst geht bis auf 1/100stel einer CPU, so dass die Partitionen im Beispiel genau den 33/100sten Teil des Prozessors bekommen. Diese Zuordnung lässt sich im laufenden Betrieb jederzeit dynamisch verändern.
Sinkt die Auslastung einer der drei Partitionen, so kann ihr der Hypervisor die nicht mehr benötigte Leistung entnehmen und einer anderen Partition im Betrieb zuordnen. Die Micro-Partitionierung der POWER5-Server erlaubt somit eine genaue Anpassung der Ressourcen an den Bedarf der Applikation. So lässt sich die Auslastung der Partitionen durch Hinzufügen von Bruchteilen von Prozessoren und Hauptspeicher bis hin zu Mainframe-Auslastungswerten von 70 bis 80 Prozent steuern und maximieren.
Shared Processor Pools
IBMs POWER5-Technologie ermöglicht durch das Micro-Partitioning logische Partitionen mit Prozessorressourcen, die kleiner sind als ein physikalischer Prozessor. Mit dem „Shared Processor Pool“ bieten POWER5-Server zusätzliche Virtualisierungen.
Der „Shared Processor Pool“ kann CPUs in einem so genannten „Shared Pool“ belassen. Diese Ressourcen nutzen alle dem Pool zugeordneten LPARs. Die logischen Partitionen, die ihre Ressourcen aus dem Pool beziehen sollen, bekommen virtuelle Prozessoren zugewiesen.
Die Definition der Prozessorleistung einer LPAR im „Shared Pool“ erfolgt über die Anzahl virtueller Prozessoren und der Gesamtleistung. Im „Shared Pool“ lassen sich die CPU-Ressourcen über das Micro-Partitioning in eine Vielzahl von virtuellen Prozessoren aufteilen.
Die Gesamtleistung einer LPAR wird beim Einsatz des Shared Processor Pools in „Capacity Entitlements“, CE, angegeben - also Teilbereiche der Gesamtkapazität. Ein POWER5-Prozessor erlaubt mit Micro-Partitioning die Zerlegung in zehn logische Teile. Somit ergeben sich pro Prozessor zehn CEs. Die zur Verfügung stehende Gesamt-CE-Kapazität des „Shared Pools“ errechnet sich aus der Anzahl der physischen Prozessoren mal den Faktor zehn. Besteht ein „Shared Pool“ beispielsweise aus drei Prozessoren, so ergeben sich maximal 30 CEs zur Verteilung auf die LPARs.
Shared-Pool-Partitionen: capped & uncapped
Der Administrator legt darüber hinaus fest, ob eine Partition im Shared Pool gedeckelt (capped) oder ungedeckelt (uncapped) arbeitet. Alle „uncapped“-Partitionen erhalten bei Bedarf aus dem CPU-Pool weitere Ressourcen, auch wenn ihre vordefinierte Leistungsdefinition (CEs) bereits erreicht oder sogar überschritten wurde. Bedingung ist, dass die anderen LPARs im Shared Pool Ressourcen abgeben können, also nicht voll ausgelastet sind.
Ein ganz wesentlicher Nachteil von dedizierten Server-Systemen lässt sich so vermeiden. Bei der Dimensionierung dedizierter Systeme muss jedes System stets für die maximale Spitzenlast ausgelegt sein. In den Zeiten, in denen diese Spitzenlast nicht abgerufen wird, sind diese Systeme eben sehr schlecht ausgelastet. Der Kunde investiert also bei unflexiblen Einzelsystemen in leer laufende Prozessoren.
Szenarien für Shared Processor Pools
Die typische Gesamtauslastung dedizierter Systeme im UNIX-Umfeld beträgt nur zwischen zehn bis 25 Prozent. Bei einer Server-Konsolidierung auf POWER5-Maschinen mit Micro-Partitions soll sich dieser Wert deutlich verbessern, wie IBM angibt. Durch die vom Administrator festgelegten Regeln benutzt jede Partition über ihre garantierte Leistung bei Bedarf zusätzliche Ressourcen aus dem gemeinsamen Pool. Jede LPAR gibt grundsätzlich alle nicht verwendeten Ressourcen an den POWER5-Hypervisor zurück, der diesen Ressourcen-Pool verwaltet. So entsteht ein „atmendes“ System, dessen LPAR-Grenzen sich im 10-Millisekunden-Takt verändern, ohne dass es dafür einer zusätzlichen Management-Software oder manueller Eingriffe bedarf.
Laut IBM ist eine Lösung mit einem großen POWER5-System unter Umständen kostengünstiger als die Verwendung von Blade Servern. Insbesondere rechne sich der POWER5 bei voneinander unabhängigen Workloads, in denen Spitzenlasten zu unterschiedlichen Zeiten entstehen. In diesen Fällen kann der Preis pro Micro-Partition unter den eines Blade Servers fallen. Ein gutes Beispiel für ein solches Szenario sind Test-, Entwicklungs- und Produktionsumgebungen, in denen typischerweise Spitzenlasten – wenn überhaupt – in verschiedenen LPARs zu unterschiedlichen Zeiten anfallen. Das POWER5-Gesamtsystem ist dabei optimal ausgelastet, ohne dass jeder einzelne LPAR-Server für Maximallast ausgelegt sein muss.
Ein anderer günstiger Anwendungsfall könnte sich ergeben, wenn LPARs von unterschiedlichen Kunden mit unterschiedlichen Anwendungen verwendet werden, oder wenn gleiche Anwendungen in unterschiedlichen Zeitzonen mit hoher Last laufen. Oft müssen bei großen Kunden in der Nacht die Batch-Job-Server eine große Leistungsfähigkeit haben. Mit POWER5-LPARs ist es einfach, die geforderten Ressourcen von den meist ohnehin nicht unter Last stehenden Anwendungs-Servern zu holen und am frühen Morgen durch die Lasterhöhung automatisch die Ressourcen wieder zurückzugeben.
Partition Load Manager
Eine Funktionalitätserweiterung in den POWER5-Systemen bietet der „Cross-LPAR Workload Manager“ oder auch „Partition Load Manager“ PLM. Der PLM steuert die Auslastung von logischen Partitionen innerhalb eines POWER5-Systems automatisch. Diese Regelung übernimmt die HMC mit dem POWER-Hypervisor, der die Systemressourcen wie Prozessoren und Hauptspeicher den LPARs dynamisch zuordnet. Der Partition Load Manager überwacht sowohl dedizierte LPARs als auch LPARs im „Shared Pool“.
Eine PLM-gesteuerte Partition Group verlangt als Erstes einen PLM-Master-Server. Dieser Server kann eine LPAR oder auch ein separates System sein. Dem PLM-Server werden die PLM-Clients – die zu überwachenden LPARs – zugeordnet. Die LPARs kommunizieren über einen Agenten (Software) mit dem Master. Auf allen in einer PLM-Gruppe befindlichen Clients dürfen unterschiedliche Betriebssysteme (AIX 5.2, AIX 5.3 oder Linux) installiert sein. Die vorhandenen Ressourcen in dieser PLM-Gruppe kann der PLM-Server nutzen, um die Leistungsanforderungen der der Gruppe zugehörigen Clients zu erfüllen.
Alle Client-Agenten senden Informationen über die Auslastung (Prozessoren und Speicher) ihrer LPAR an den PLM-Server. Stellt der PLM-Server fest, dass sich eine Client-LPAR an seiner vordefinierten Leistungsgrenze befindet, so wird innerhalb der Gruppe nach einer LPAR gesucht, die freie Ressourcen zur Verfügung stellen kann. Findet der PLM-Server eine freie Ressource, entfernt sie der Hypervisor von der abgebenden Client-LPAR und ordnet die Ressource der unter zu hoher Last laufenden Client-LPAR zu. Diese Überwachung findet im Gegensatz zu manuellen Eingriffen ständig statt. Sich verändernde Lastzustände in einer PLM-Gruppe gleichen die Verschiebungen von Ressourcen stetig aus.
Virtual Ethernet
Das virtuelle Ethernet ist im Mainframe-Bereich bereits seit vielen Jahren etabliert. POWER5-Server nutzen diese Technologie auch bei UNIX-Systemen. In den LPARs lassen sich virtuelle Ethernet-Adapter konfigurieren, die das Betriebssystem wie physikalische Adapter behandelt.
Pro LPAR sind bis zu 256 virtuelle Ethernet-Adapter möglich. Der Hypervisor erlaubt die Konfiguration von maximal 4096 virtuellen Ethernet-Netzen (gemäß IEEE 802.1Q) pro System. Bei der Kommunikation von LPAR zu LPAR über virtuelle Ethernet-Adapter handelt es sich in der Realität um eine „Memory-to-Memory“-Kommunikation mit entsprechend niedriger Latenzzeit. So sind laut IBM Datenraten bis zu mehreren GByte/s möglich.
Für die Anbindung der LPARs mit den virtuellen Ethernet-Device-Treibern an ein externes Netz wird eine so genannte Hosting-Partition benötigt. Auf der Hosting-Partition ist ein für diese Funktion speziell optimiertes Betriebssystem (AIX-konform) erforderlich. Die Installation der Hosting-Partition erfolgt über eine bei POWER5-Systemen mitgelieferte spezielle CD. Dabei lässt sich diese Partition ausschließlich für den Hosting-Service benutzen.
Die Hosting-Partition übernimmt die physikalisch vorhandenen Adapter und „shared“ diese Controller über alle virtuell angebundenen LPARs. So realisiert das POWER5-System eine einfache Verbindung der LPARs zu externen Netzen. Im System lassen sich bis zu vier Hosting-Partitionen erzeugen. In der Regel genügen zwei, um eine Redundanz zu erreichen. Ein einfaches Update einer Hosting-Partition ist dann im laufenden Betrieb leicht möglich.
Die Hosting-Funktionalität ist arbeitsintensiv und belastet den Server. Die erzeugte Last hängt von den zu administrierenden Ressourcen und der Anzahl der auf die Partition zugreifenden Clients ab. Eine Hosting-Partition kann im POWER5-System als dedizierte Partition laufen sowie als Micro-Partition im „Shared Pool“ angelegt sein.
Virtual I/O
POWER5-Server erlauben auf den LPARs neben dem virtuellen Ethernet auch virtuelle SCSI-Adapter (vSCSI). Die Hosting-Partition lässt sich für die Abbildung von virtuellen auf physikalischen Adaptern einsetzen. Die Kommunikation von einer LPAR in die Hosting-Partition erfolgt wiederum über den Hypervisor der POWER5-Systeme.
Durch die Möglichkeit virtueller SCSI-Adapter in den LPARs entfällt die Notwendigkeit eigener I/O-Slots und physikalischer Adapter pro Partition. Dies erweist sich bei den über 200 möglichen Partitionen der POWER5-Server als sinnvoll. Beim Virtual-I/O sind wie beim Virtual-Ethernet die physikalischen Adapter der Hosting-Partition zugeordnet. Die Hosting-Partition „shared“ diese Adapter über alle zugeordneten LPARs.
Auch bei vSCSI sind zwei Hosting-Partitionen für eine redundante Auslegung der virtuellen I/O-Pfade zweckmäßig. Mit Hilfe der Virtual-I/O-Technologie können alle LPARs beispielsweise vier an ein SAN angeschlossene Fibre-Channel-Adapter für ihr I/O verwenden. Bei I/O-intensiven Anwendungen ist die Zuweisung von dedizierten Adaptern nach wie vor sinnvoll. Dabei lässt sich auch ein Mischbetrieb von physikalischen und virtuellen Adaptern innerhalb einer LPAR definieren. So könnte beispielsweise der physikalische Adapter direkt an ein Disc-System angeschlossen sein, während die Spiegelung über einen virtuellen Pfad erfolgt.
Neben den I/O-Adaptern virtualisiert der Hypervisor die Festplatten. Logical Volumes der physikalischen Laufwerke der Hosting-Partition erscheinen als virtuelle Discs in den LPARs. Auf einer physikalischen Festplatte lässt sich – je nach Kapazität – eine Vielzahl von Betriebssystem-Images für die LPARs erzeugen und pflegen.
Obwohl die Hosting-Partition die Platten der LPARs administriert, gibt es von der Hosting-Partition keinen Zugriff auf die Daten der virtuellen Server. Hier wird strikt die Trennung der LPARs im System eingehalten.
Fazit
Die Virtualisierungsfunktionen der POWER5-Server sind Systemen mit Intel- oder AMD-CPUs derzeit weit überlegen. IBM bietet mit dem POWER5 Mainframe-Features für Plattformen mit UNIX oder Linux.
Die Virtualization Engine unterteilt das POWER5-System in eine Vielzahl von virtuellen Servern (LPARs). Durch die Virtualisierung der Prozessoren, Arbeitsspeicher, I/O-Adapter, Festplatten und Ethernet-Karten benötigen die LPARs keine physikalischen Ressourcen. Dementsprechend schnell lassen sich so auf den POWER5-Systemen neue Server erstellen, die sich nach Bedarf vergrößern oder auch wieder entfernen lassen.
Besonders die dynamische Anpassung der Ressourcen der einzelnen virtuellen Server macht die POWER5-Systeme sehr flexibel. Benötigt ein Server zu Spitzenzeiten mehr Rechenleistung, so holt er sich diese aus einem „Shared Pool“ oder von anderen virtuellen Servern, die gerade Ressourcen abgeben können.
IBM will die POWER5-Systeme im Jahr 2006 mit weiteren Funktionalitäten ausstatten. So sollen sich dann beispielsweise Partitionen von einer Maschine im laufenden Betrieb auf andere Maschinen „umziehen“ lassen. Auch beim Prozessor steht die Entwicklung nicht still. Auf der Roadmap befinden sich bereits der POWER6 für 2006/2007 und der POWER7 für das Jahr 2008/2009. (cvi)
Dieser Artikel basiert auf einem IBM-Whitepaper über die POWER5-Technologie und eServer-p5-Systeme. Verfasst wurde das Whitepaper von Peter Pötschulat, IBM Senior IT Architect pSeries.