Home 
ORDIX News 3/2007 Betriebssysteme
ORDIX News 3/2007 Betriebssysteme
ORDIX News 3/2007 Betriebssysteme
Serverkonsolidierung und -flexibilisierung interessieren.
| HMC Hardware Management Console. Administrationseinheit zur Steuerung des Hypervisors. |
| Hypervisor Firmware zur Kontrolle der Hardware. |
| Shared Processor Pool Prozessoren, die auf mehrere Partitionen flexibel verteilt werden. |
| LPAR Zusammenstellung von Systemressourcen und einem Betriebssystem. |
| DLPAR Verteilen von Systemressourcen im laufenden Betrieb. |
| Entitled Capacity Garantierte Prozessorleistung einer Partition. |
| PLM Partition Load Manager. Software, die per DLPAR freie Systemressourcen auf Partitionen verteilen kann. |
| Trunk Adapter Netzwerkadapter mit virtueller und physikalischer Seite. |
| SEA Shared Ethernet Adapter. AIX-Bezeichnung für den Trunk Adapter. |
| SMT Simultaneous Multi-Threading. Parallele Verarbeitung zweier Threads im Prozessor. |
| VIOS Virtual I/O-Server. Logische Partition, die virtuelle Ressourcen zur Verfügung stellt. |
Weiterführende Links
Partitionieren bedeutet, sich aus den Gesamtressourcen eines Hostsystems eine Untergruppe auszuwählen, um darauf eine lauffähige Betriebssysteminstanz zu installieren und als eigenständigen Server zu verwenden. Die schon mit der POWER4-Architektur verfügbare Möglichkeit, Server unter IBMs Unix-Klon AIX zu partitionieren, wurde mit der Entwicklung der POWER5-Architektur unter AIX 5.3 sowie unter den Linux Enterprise Distributionen von Red Hat und Suse weiterentwickelt.
|
| Abb. 1: Konfiguration physischer E/A-Einheiten auf der Hardware Management Console (HMC). (vergrößern) |
Auf dieser Plattform ist es möglich, einer logischen Partition (LPAR) einzelne Kommunikationsadapter, Festplatten und Speicherbereiche feingranuliert zuzuweisen (siehe Abbildung 1). Durch die hohe Leistungsfähigkeit der POWER5-Prozessoren ist es dabei notwendig geworden, die Prozessorkapazität zu mikropartitionieren, das heißt, weiter zu unterteilen.
Sie wird in Inkrementen von mindestens Zehntelprozessoren auf die Partitionen verteilt, damit auch die Anforderungen „kleinerer" Systeme abgebildet werden. Nach der Mindestkapazität von 0,1 Prozessor pro Partition ist eine weitere Unterteilung in 0,01 Prozessoreinheiten mögglich. Somit sind auf einem System mit n Prozessoren theoretisch 10 * n logische Partitionen verfügbar.
Die Hardwareverwaltung eines POWER5-Systems geschieht über den POWER Hypervisor, eine prozessorgebundene Firmware, die über eigene Adapter mit einer Hardware Management Console (HMC) verbunden ist. Die HMC, ein eigenständiges linux-basiertes System mit spezieller Software, stellt eine komfortable grafische und eine kommandobasierte Schnittstelle zum Hypervisor zur Verfügung.
Im Zusammenspiel des Hypervisors mit der HMC werden die einzelnen Partitionen konfiguriert, gestartet und gestoppt. Mit der Fähigkeit, über die HMC virtuelle Konsolenverbindungen zu den Partitionen aufzubauen, lässt sich beispielsweise eine Partition einfach für die Installation aus dem Netzwerk konfigurieren.
Des Weiteren ist mit der HMC und dem Service Focal Point eine partitionsübergreifende Überwachung der Systemhardware gegeben. Allerdings lassen sich kleinere Systeme aus der Einstiegsklasse der POWER5-Baureihe auch über einen Integrated Virtualization Manager verwalten, so dass man die HMC hauptsächlich bei Midrange und Enterprise Servern einsetzt. Jeder Server ist ebenfalls als Full System Partition mit allen Ressourcen ohne HMC verwendbar.
Jeder logischen Partition werden ein oder mehrere Profile zugeordnet. In den Profilen wird je nach Anforderung an die Partition hinterlegt, welche Ressourcen beim Booten herangezogen werden. Das heißt, Unterschiede in der Prozessorbelegung, in der Inanspruchnahme von Band- oder DVD-Laufwerken oder Unterschiede in der speziellen Verwendung von Kommunikationsadaptern können im Profil hinterlegt werden.
Für Prozessorbelastung und Speichergröße werden in den Profilen über die Angabe von Minimal- und Maximalwerten immer Bandbreiten eingerichtet, womit man den Bereich definiert, in dem man dynamisch logisch partitionieren kann. Ohne Unterbrechung des Systembetriebs können Ressourcen wie Speicher, Prozessoranteile und Adapter untereinander zwischen den Partitionen eines Hostsystems verschoben werden.
Soll beispielsweise ein DVD-Laufwerk von einer Partition zur anderen verschoben werden, so wird unter AIX auf Partition A das Laufwerk mit rmdev betriebssystemseitig gelöscht, über die HMC verschoben und auf Partition B mit dem cfgmgr betriebsbereit gemacht.
Zwar ist es immer noch möglich, den Partitionen dedizierte, also „ganze" Prozessoren zuzuweisen; im Sinne einer erhöhten Flexibilisierung schöpfen Partitionen jedoch ihre Rechenleistung aus einem Pool von gemeinsamen Prozessoren (Shared Processor Pool).
Jeder Partition kann zwar eine feste Rechenleistung (Entitled Capacity, EC) garantiert werden, die natürlich für alle Partitionen zusammen die gesamte physikalische Kapazität nicht übersteigt. Sind im Gesamtsystem jedoch freie Prozessorkapazitäten vorhanden, weil z. B. eine Partition zu einem Zeitpunkt nur 20 Prozent ihrer EC anfordert, so kann eine andere Partition automatisch darauf zugreifen. Auf diese Weise lassen sich bei geschickter Planung nacht- und tagaktive Produktions-, Test- und Entwicklungssysteme so aufbauen, dass vorhandene Kapazitäten nicht brachliegen.
Die Verteilung von freiem Hauptspeicher auf Partitionen geschieht jedoch nicht ohne Weiteres automatisch. Hierzu ist der Einsatz der Zusatzsoftware Partition Load Manager (PLM) für AIX 5.3 notwendig. Der PLM basiert auf einem Client/Server-Modell für die gemeinsame Nutzung von Systeminformationen und kann per dynamischer logischer Partitionierung Systemressourcen verteilen.
Neben der Tatsache, dass für die benannten Eigenschaften eine Gebühr pro Prozessor (die Advanced Virtualization Option) bezahlt werden muss, beansprucht der Hypervisor grob 6 Prozent des im System installierten Hauptspeichers und die Verwaltung im Prozessorpool vermindert dessen Leistung um etwa 4 Prozent.
Gegen einen relativ geringen Aufpreis können Prozessoren und Hauptspeicher zwar ab Fabrik in das System eingebaut sein, sind aber nicht aktiviert. Zum einen kann damit die Ausfallsicherheit erhöht werden, da diese beim Ausfall aktiver Bauteile automatisch mit den bis dahin deaktivierten Komponenten durch den Hypervisor ersetzt werden.
Auf der anderen Seite lassen sich mit dem Erwerb von Lizenzen die Ressourcen aber auch permanent oder temporär (für Jahresendabschlüsse, Lasttests etc.) hinzuschalten, ohne dass eine Downtime für den Einbau von Hardware notwendig ist.
Durch (Mikro-)Partitionierung und DLPAR ist besonders auf Servern der Midrange- bis Enterprise-Klasse ein hohes Maß an Flexibilisierung möglich. Bei Konsolidierungen können Systeme aus allen Leistungsklassen aller vergangener Prozessorarchitekturen in logische Partitionen abgebildet werden.
Fällt der Bedarf an einer Partition weg, so können deren Ressourcen dem Bedarf anderer Partitionen zur Verfügung gestellt werden. Ein mit vielen Fehleinschätzungen behaftetes Server Sizing wird entschärft.
Bei steigender Anzahl von Partitionen tritt das Problem auf, dass die Anzahl von I/O-Adaptern für Ethernet, für Storage und Datensicherung bzw. für Platten von Betriebssystem-Images usw. stark ansteigt. Hier verspricht die Virtualisierung von I/O-Einheiten Besserung.
Nachdem wir uns die Möglichkeit angesehen haben, wie man auf einem System mit n Prozessoren maximal 10 * n Betriebssysteminstanzen installiert, wollen wir uns nun anschauen, wie man die Klippe umschifft, für jede dieser 10 * n Partitionen die entsprechenden Platten und Adapter zur Verfügung zu stellen.
Um im Jargon zu bleiben, wird das Schiff durch Virtualisierung auf Kurs gehalten. Mit Hilfe der Virtualisierung werden physikalische Ressourcen aufgeteilt und mehreren Partitionen als virtuelle Ressource zur Verfügung gestellt. Auf der POWER5-Plattform geschieht dies mit den so genannten Virtual I/O-Servern (VIOS). Das sind Partitionen mit einer speziellen AIX-Version, die die physikalischen Ressourcen verwalten.
Beim Virtual SCSI (vSCSI) zum Beispiel definiert man über die HMC per Mausklick einen virtuellen SCSI Server Adapter auf dem VIOS und einen virtuellen SCSI Client Adapter auf einer LPAR und verbindet diese miteinander.
Mit dem Befehl cfgdev wird dem VIOS-Betriebssystem der Adapter als vhost bekannt gemacht. Ein beliebiger als Logical Volume (LV) definierter Plattenplatz wird mit dem vhost verknüpft (Befehl mkvdev). Dem Client System ist danach das LV als reguläre hdisk bekannt und kann als Bootplatte benutzt werden.
Es ist klar, dass auf diese Weise, mit einer ausreichend großen Festplatte problemlos bis zu 20 LVs für die Betriebssysteme geschnitzt werden können. In der hochverfügbaren Welt sollte eine Boot-Platte gespiegelt sein. Das ist jetzt ganz einfach: Entweder auf einer zweiten Festplatte am VIOS ein weiteres LV definieren und über denselben oder einen weiteren vhost zur Partition durchreichen oder besser einen zweiten VIOS einrichten, der die Funktionalität des ersten spiegelt und einen Failover bereitstellt.
Aber nicht nur LVs auf Platten können auf einen vhost gelegt werden, sondern auch alle internen und externen über ein SCSI Protokoll angesprochenen Festplatten. Somit sind auch über Fibrechannel angesprochene Platten im SAN virtualisierbar. Dabei ist es möglich, die Multipathing Software zur Verwaltung von Lastverteilung und Failover des Storage der jeweiligen Hersteller schon auf dem VIOS zu installieren.
Der Vorteil liegt auf der Hand: Auch größere Mengen an externem Speicher können flexibel, ohne zwischenzeitliches Verlegen neuer Kabel, den Partitionen zur Verfügung gestellt werden. Trotzdem muss natürlich die Kapazitätsauslastung der Adapter im Auge behalten werden. Ein VIOS benötigt für sich selbst üblicherweise 0,5 bis 1 GB Speicher und 0,25 bis 1,5 Prozessoren.
Zunächst birgt die Plattform die Möglichkeit, ein virtuelles Ethernet zwischen den Partitionen eines Host-Systems aufzubauen. Analog dem vSCSI werden wieder entsprechende Adapter über die HMC definiert, den Betriebssystemen bekannt gemacht und wie physikalische Adapter behandelt. Die Philosophie hinter der Virtualisierung auf der POWER5-Plattform ist ohnehin, auf Betriebssystemseite der Partitionen so wenig Unterschiede wie nötig in der Behandlung von physikalischen und virtuellen Adaptern zu machen.
Der physikalisch über den Speicherbus abgewickelte Datenverkehr des virtuellen Ethernets kann dabei Transferraten erreichen, die deutlich über den Transferraten von GB Ethernet Schnittstellen liegen. Auf dem VIOS definiert man „Trunk Adapter". Sie besitzen eine physikalische Seite mit den Kabeln zum Switch und eine virtuelle Seite zu den Partitionen und werden Shared Ethernet Adapter (SEA) genannt.
Die Transferraten auf physikalischer Seite können dabei durch Verwendung entsprechend leistungsfähiger Adapter und mit Kanalbündelung - über Link Aggregation oder Etherchannel - hochgeschraubt werden. Durch Einkapselung in unterschiedliche VLANs wird der Datenverkehr auf virtueller Seite gesichert. SEAs lassen sich mit Hilfe von Control Channels ebenfalls hochverfügbar machen.
|
| Abb. 2: Konfigurationsmaske zur Einteilung der virtuellen Prozessoren. (vergrößern) |
Bezieht eine Partition ihre Rechenleistung aus dem Shared Processor Pool, so wird ihr per Benutzereingabe auf der HMC im Profil eine Anzahl an virtuellen CPUs zugewiesen. Die Zahl der virtuellen CPUs reflektiert die Anzahl der Zeitscheiben, auf denen die Partitionen Rechenkapazität anfordern dürfen und ist identisch mit der Anzahl an Prozessoren, die das Betriebssystem später erkennt. Abbildung 2 zeigt eine HMC-Maske, in der die Eigenschaften der virtuellen Prozessoren einer Partition definiert werden.
Die Rechenleistung einer virtuellen CPU ist variabel, sie liegt je nach Auslastung zwischen einer Zehntel und einer ganzen physikalischen CPU. Daher achtet man darauf, die Anzahl der virtuellen CPUs gleich der Zahl der von der Partition maximal anforderbaren CPUs anzugeben. Ansonsten kann man die maximal gewünschte Prozessorleistung nicht abrufen. Eine Daumenregel ist daher, dass die minimal zugewiesene Prozessorleistung mindestens ein Zehntel der Anzahl virtueller Prozessoren ist. Eine Leistungssteigerung von bis zu 30 Prozent erzielt man mit Simultaneous Multi-Threading (SMT): Also durch die gleichzeitige, parallele Ausführung zweier Threads im Prozessor. Diese Eigenschaft ist allerdings auch abschaltbar, da manche Applikationen damit instabil laufen.
In hochproduktiven Umgebungen wird es sicherlich zu einer Mischung von physikalischen und virtuellen Adaptern kommen. Wo mit garantierten Datentransferraten und Zugriffszeiten gearbeitet werden muss, hinter denen die Rechenleistung mehrerer Prozessoren steht, ist es ratsam, den Zugriff auf das Storage durch dedizierte, physikalische Adapter abzuwickeln.
Zeitlich steuerbare Vorgänge (Batchläufe, Datensicherung etc.) oder Vorgänge ohne Performance-Anforderungen (wie sie z. B. bei Zugriffen auf Systemlaufwerke und in Administrations- oder Heartbeat-Netzwerken vorkommen) können ohne Weiteres virtualisiert werden und bergen so immenses Einsparungspotenzial.
IBM bietet mit der POWER5- bzw. mit der ab dem Herbst 2007 erwarteten POWER6-Architektur eine hochflexible Plattform, die sich an wechselnde Anforderungen schnell anpassen lässt.
Dr. Uwe Bechthold (info@ordix.de).