Mit V4R4 kündigte IBM Logical Partitioning (LPAR) für iSeries Systeme an und bot damit Systemadministratoren eine neue Möglichkeit, Systeme zu konsolidieren, die Anzahl redundanter Systemressourcen zu reduzieren und zusätzliche administrative Tätigkeiten zu vermeiden. Eine weitere wesentliche LPAR Erweiterung – die Möglichkeit zur dynamischen Umverteilung von Verarbeitungs-Ressourcen (z.B. Prozessoren, interaktive Kapazität und Speicher) – folgte mit V5R1.
Diese Erweiterung erlaubt wesentliche Einflussnahme auf die Systemauslastung, da Systemadministratoren dadurch in die Lage versetzt werden, Ressourcen exakt dort zuzuordnen, wo sie gerade dringend benötigt werden, ohne dafür ein IPL der von dieser Veränderung betroffenen Partitionen durchführen zu müssen. Dieser Artikel betrachtet die unterschiedlichen Performance-Aspekte auf einem LPAR System und gibt Anhaltspunkte, wie eine LPAR Konfiguration sinnvoll geplant werden kann und wie Ressourcen zur Optimierung der Performance dynamisch verteilt werden können.
![Künstler Burgy Zapp [http://burgyzapp.de]](http://newsolutions.de/it/wp-content/uploads//fr5_last_IMG_1465.jpg)
Was bedeutet eigentlich „Performance“?
Zuerst muss einmal definiert werden, mit welcher Bedeutung der Begriff „Performance“ zu belegen ist. Ein beliebiger Benutzer oder ein beliebiges Unternehmen z.B. versteht Performance-Optimierung auf einem LPAR System schlicht im Sinne von Maximierung des Durchsatzes für das Gesamtsystem. Der Begriff „Gesamtsystem“ umfasst hierbei die gesamte iSeries Systemhardware (alle Partitionen zusammengenommen im Gegensatz zu einer einzelnen Partition). Der Begriff „Gesamtsystem“ wird hier verwendet, um eine Abgrenzung zu dem bisher meist verwandten Begriff „System“ zu schaffen, der unter LPAR Gesichtspunkten seine klare Aussagekraft eingebüßt hat. Mit „System“ könnte sowohl das gesamte iSeries System (repräsentiert durch eine Seriennummer) gemeint sein, ebenso gut könnte aber auch eine einzelne Partition gemeint sein, die ja als unabhängiges logisches System agiert. Ein anderer Benutzer wiederum mag die Meinung vertreten, eine optimale Performance sei immer dann gegeben, wenn die Produktionspartitionen alle erdenklichen benötigten Ressourcen ohne Rücksicht darauf erhalten, wie sehr z.B. Development-Partitionen oder andere Partitionen darunter leiden müssen. Wieder ein anderer mag die Optimierung der Performance unter zeitlichen Gesichtspunkten sehen, so zum Beispiel die Zuordnung aller benötigten Ressourcen zu einer Partition namens „LONDON“ zu einem Zeitpunkt, wo die Arbeitsbelastung dort am höchsten ist. Zu einem anderen Zeitpunkt im Tagesablauf wird dann die Partition „SAN DIEGO“ mit einer hohen Anzahl von Ressourcen ausgestattet, nämlich genau dann, wenn hier die Belastung am höchsten ist, usw.
Welchen Einfluss auch immer Ihre aktuelle Systemumgebung auf Ihre persönliche Betrachtungsweise von Performance hat, so viel steht fest: Der Einsatz der LPAR Möglichkeiten zur Maximierung Ihrer System-Performance bedarf einer sorgfältigen Abwägung der Performanceanforderung sowohl jeder einzelnen Partition als auch des Gesamtsystems.
Konfiguration Ihres iSeries Systems für LPAR
Eine LPAR Konfiguration beinhaltet die Aufteilung der vorhandenen Ressourcen des Gesamtsystems auf die einzelnen zu erstellenden Partitionen. Ein entscheidender erster Schritt hierbei ist die Zusammenstellung von Informationen über die zu erstellenden Partitionen (siehe nachfolgende Abbildung „Überlegungen zur Partitionierung“). OS/400 stellt einige Unterstützungen bei dieser Analyse zur Verfügung. So lassen sich zum Beispiel Informationen aus gesammelten Performancedaten oder Performance-Monitoren für diese Planung verwenden.
| Überlegung zur Partitionierung |
|
Die Aufteilung von Ressourcen während der LPAR Konfiguration betrifft Speicher, Prozessor (CPU) und interaktive Kapazität. Für jede Partition ist für jede dieser Ressourcen ein Minimum- und ein Maximum-Wert vorzugeben. Die LPAR Fähigkeit, Ressourcen dynamisch neu zuordnen zu können, hat unter dem Gesichtspunkt eines Maximums an Flexibilität und Performance wesentlichen Einfluss auf die Art und Weise, in der LPAR implementiert werden sollte.
WLPAR Konfigurationsüberlegungen
Bei der Konfiguration eines iSeries Systems für LPAR ist der Primärpartition besondere Beachtung zu widmen. Diese Partition unterscheidet sich von allen anderen Partitionen dadurch, dass sie für das Management aller anderen Partitionen verantwortlich ist. Und anders als bei allen anderen Partitionen bedingt ein IPL der Primärpartition somit auch ein IPL aller anderen Sekundärpartitionen. Um die LPAR Fähigkeit der dynamischen Zuordnung von Verarbeitungs-Ressourcen nutzen zu können, muss die Primärpartition zumindest unter V5R1 betrieben werden. Zumindest V5R1 muss auch auf allen Sekundärpartitionen installiert sein, denen dynamisch Ressourcen zugeordnet werden sollen.
Wegen ihrer Schlüsselrolle wäre es ungünstig, die Primärpartition mit Aufgaben zu belegen, die gegebenenfalls häufige IPLs erfordern. So könnte zum Beispiel die Entwicklung einer Anwendung unter Einbeziehung neuer, noch unerprobter Technologien das häufigere Einspielen von PTFs bedingen, was dann eventuell jeweils ein IPL zum Anlegen dieser PTFs nach sich ziehen kann. Plant man den Betrieb mehrerer Produktionspartitionen, ist es sinnvoll, die Primärpartition klein auszulegen und ihr überwiegend die Steuerungsfunktionen des Gesamtsystems zuzuordnen. Für die unterschiedlichen Produktionsumfelder sowie die Entwicklungsumgebung sollte man dann jeweils eigene Sekundärpartitionen einplanen.
Als nächstes ist festzulegen, welche und wie viele Prozessoren generell für gemeinschaftliche Nutzung zur Verfügung stehen sollen. Jede Partition muss für die Nutzung entweder dedizierter oder aber gemeinschaftlich genutzter Prozessoren konfiguriert werden (Abbildung 1). Die Aufteilung der gemeinschaftlich genutzten Prozessoren erfolgt nicht physisch, sondern nach einem Zeitscheibenverfahren, bei dem jeder Partition für die ihr zugeteilte Zeitscheibe die komplette Prozessorleistung zur Verfügung steht. Würde also z.B. der Wert 0,52 für den Anteil einer Partition an einem gemeinschaftlich genutzten Prozessor gewählt, so bedeutet das, dass dieser Prozessor der Partition zu 52% der Zeit vollständig zur Verfügung steht. Obwohl je Partition nur ein Prozessortyp (entweder dediziert oder gemeinschaftlich genutzt) verwendet werden kann, können in einem Gesamtsystem durchaus beide Arten von Partitionen (mit Zuordnung dedizierter oder gemeinschaftlicher genutzter Prozessoren) angelegt werden.
Jeder Partition, der gemeinschaftlich genutzte Prozessoren zugeteilt werden, muss zumindest der Wert 0,10 (10 %) eines Prozessors zugeordnet werden. IBM empfiehlt jeder Partition als Minimalwert 0,25 (25 %) eines Prozessors zuzuordnen. Gemeinsam genutzte Prozessoren erlauben eine fein abgestimmte Zuteilung der Prozessorleistung, da eine Zuordnung in 0,01 (1 %) Schritten vorgenommen werden kann. Die Verwendung gemeinsam genutzter Prozessoren erzeugt andererseits aber einen gewissen System-Overhead, da der Prozessor Cache bei jeder Neuzuordnung des Prozessors gelöscht werden muss. Der „Preis“ für diesen Overhead ist ein Absinken der Prozessor-Performance um etwa 6-10 %.
Dedizierte Prozessoren erlauben eine effizientere Ausnutzung der Prozessorleistung, da der Prozessor Cache hier nicht in dieser Häufigkeit gelöscht werden muss. Da aber andererseits dedizierte Prozessoren einzelnen Partitionen nur in ganzen Einheiten zugeordnet werden können, ergibt sich in Hinblick auf die Flexibilität hier ein Nachteil gegenüber gemeinsam genutzten Prozessoren. Bei der Definition gemeinsam genutzter Prozessoren kann jenen Partition, die aktuell höhere Prozessorleistung benötigen, diese Leistung in entsprechender Granularität dynamisch zur Verfügung gestellt werden, ohne dabei Prozessorleistung zu vergeuden.
Letztlich muss die Entscheidung über den Einsatz von dedizierten oder gemeinschaftlich genutzten Prozessoren (oder einer Kombination von beiden) von der Systemkonfiguration sowie von geplantem Umfang und Häufigkeit der dynamischen Neuzuordnung von Prozessorleistung zu den einzelnen Partitionen abhängig gemacht werden.
Festlegen der Minimal- und Maximalwerte
Im Rahmen der Konfiguration der Partitionen und Festlegung der aktuellen Ressourcen für Speicher, Prozessoren und interaktive Kapazität müssen auch die Minimal- und Maximalwerte für diese Ressourcen festgelegt werden. Die Wahl dieser Werte muss sorgfältig bedacht werden. Setzt man die Minimalwerte zu hoch fest, bindet man eventuell unnötigerweise Ressourcen, die man später besser einer anderen Partition zugeordnet hätte. Obwohl LPAR zwar die dynamische Zuordnung von Ressourcen zu Partitionen erlaubt, muss bei Änderung der Minimal- und Maximalwerte für eine Partition ein IPL des Gesamtsystems durchgeführt werden, bevor diese Änderungen Wirksamkeit erlangen.
Die Speicherzuteilung für jede Partition wird im System in einer Speicherseitentabelle (page table) verwaltet. Es muss ausreichend Speicher vorhanden sein, um die bei der Partitions-Konfiguration vergebenen Maximalwerte abzudecken. Überdies wird aber auch Speicherplatz benötigt, um die page table zu verwalten. Man sollte also darauf achten, die Maximalwerte nicht zu hoch anzusetzen, da das letztlich zu einer aufgeblähten page table führt, was wiederum die Vergeudung wertvoller Speicherressourcen zur Folge hat.
Vergleichbare Einbußen sind bei der Festlegung der Werte für Prozessoren und interaktive Kapazität nicht zu befürchten. So können die Werte hier hoch angesetzt werden, um die maximale Flexibilität bei der dynamischen LPAR Zuordnung zu ermöglichen. Was allerdings bedacht werden muss, ist die Tatsache, dass die Werte für CPU (Prozessor) und interaktive Kapazität in einem gewissen Zusammenhang stehen. Erhöht man einen der beiden Werte, muss als Folge davon eventuell auch der andere Wert erhöht werden. Als Unterstützung bei der Festlegung dieser Werte ermittelt man zu erst den Wert CPW/Prozessor, indem man den CPW Wert des Gesamtsystems durch die Anzahl der verfügbaren Prozessoren dividiert. Danach berechnet man den Wert CPW/(Prozent interaktiver Kapazität) indem man den CPW Wert des Gesamtsystems durch 100 dividiert.
Die Anzahl von Prozessoren, die zur Unterstützung einer vorgegebenen Menge interaktiver Kapazität benötigt wird, kann folgendermaßen abgeleitet werden:
- % gewünschter interaktiver Kapazität * (CPW/(% interaktiver Kapazität)) CPW/Prozessor
Dedizierte Prozessoren werden auf die nächste ganze Zahl aufgerundet, gemeinschaftlich genutzte Prozessoren auf das nächste Hundertstel. Umgekehrt leitet sich der Prozentsatz benötigter interaktiver Kapazität bezogen auf eine bestimmte Anzahl von Prozessoren folgendermaßen ab:
- gewünschte # Prozessoren * (CPW / Prozessor)* 0,015 CPW/Prozessor
Der ermittelte Prozentsatz an interaktiver Kapazität wird auf die nächste ganze Zahl aufgerundet. Man sollte diese Formeln allerdings nur als grobe Leitlinien verstehen und dabei berücksichtigen, dass IBM diese Relation zwischen interaktiver Kapazität und Anzahl von Prozessoren nicht immer strikt umsetzt.
LPAR Empfehlungen
Diese Berechnungen unterstreichen die Wichtigkeit sorgfältiger Planung im Vorfeld der Implementierung einer LPAR Konfiguration. Auch wenn die Anforderungen eines jeden Systems sicherlich individuell sehr unterschiedlich sind, so lassen sich doch einige generelle Leitlinien aufzeigen:
- Beim Betrieb mehrerer Produktionspartitionen sollte die Planung einer möglichst „kleinen“ Primärpartition in Erwägung gezogen werden, deren Hauptaufgabe in der Verwaltung der anderen Partitionen liegt.
- Zur Optimierung der Performance sollten dedizierte Prozessoren anstelle von gemeinsam genutzten Prozessoren verwendet werden. (Ein mögliches Szenario für ein System mit mehreren Partitionen könnte folgendermaßen aussehen: Konfiguration einer Primärpartition mit einer Basis von 0,50 gemeinsam genutzten Prozessoren, einer Entwicklungspartition mit 0,50 gemeinsam genutzten Prozessoren und Konfiguration der Produktionspartitionen mit dedizierten Prozessoren.)
- Bei der Verwendung gemeinsam genutzter Prozessoren sollten keiner Partition Werte unter 0,25 Prozessoren zugeordnet werden.
- Die Minimalwerte sollten für alle Ressourcen möglichst gering gehalten werden, um eine Möglichst hohe Flexibilität für die dynamische LPAR Zuordnung zu erhalten.
- Die Maximalwerte für Prozessoren und interaktive Kapazität sollten hoch angesetzt werden, um eine möglichst hohe Flexibilität für die dynamische LPAR Zuordnung zu ermöglichen.
- Die Maximalwerte für die Speicherzuordnung sollten in vernünftigem Rahmen gehalten werden, um ein unnötiges Aufblähen der page table zu vermeiden.
- Es muss sichergestellt werden, dass für jede Partition der vergebene Prozessor-Minimalwert in der Lage ist, den Prozentsatz an interaktiver Kapazität für diese Partition abzudecken (und umgekehrt) und dass die Maximalwerte für diese Ressourcen kompatibel sind.
Dynamische Zuordnung von Ressourcen zu „Not leidenden“ Partitionen Nach dem die LPAR Konfiguration abgeschlossen ist, lässt sich aus den Möglichkeiten der dynamischen LPAR Ressourcenzuordnung zusätzlicher Nutzen ziehen, indem jenen Partitionen, die aktuell erhöhten Leistungsbedarf haben, zusätzliche Ressourcen zugeordnet werden können. Wenn z.B. unterschiedliche Partitionen unterschiedliche Zeitzonen bedienen, ist das recht einfach – über den Operations Navigator (OpsNav) werden Partitionen zu den jeweiligen Spitzenbelastungszeiten alle Ressourcen zugeordnet, die gerade erübrigt werden können.
Was ist aber zu tun, wenn eine bestimmte Anzahl von Partitionen gleichzeitig aktiv ist und eine oder mehrere dieser Partitionen schlechte Performance aufweist? Gibt es Empfehlungen, welche Ressourcen umverteilt werden können, um in einer solchen Situation Abhilfe zu schaffen?
Zuerst sollte der Prozentsatz an CPU-Benutzung geprüft werden. Sind einer Partition nicht in ausreichendem Maße Prozessor-Ressourcen zugeordnet, wird die Zuordnung anderer Ressourcen keinen wesentlichen Einfluss auf die Performance erzielen können. Über die Anzeige WRKSYSSTS (Work with System Status) erhält man die benötigten Informationen (Abbildung 2.) Der Wert „%CPU used“ in der oberen linken Ecke der Anzeige ist hier die kritische Variable. Verweilt dieser Wert z.B. länger als eine Minute über 90 % (bei einer eingestellten refresh-rate von 5 Sekunden), kann davon ausgegangen werden, dass die mangelnde Performance der Partition auf unzureichende Prozessorzuordnung zurückzuführen ist.
In der LPAR Kofigurations-Anzeige (Abbildung 1) oder im Operations Navigator (Logical Partitions, Configure Partitions) wird die Partition ausgewählt, von der Ressourcen übertragen werden sollen. (Ausgewählt sollte hierzu eine oder mehrere Partitionen werden, deren CPU-Auslastung niedrig ist, z.B. unterhalb 35%.) Werden gemeinsam benutzte Prozessoren eingesetzt, kann zum Beispiel nach Auswahl des Icons für den Pool gemeinsam genutzter Prozessoren die Funktion „Übertragen„ (Move) gewählt werden. Bei Benutzung des Operations Navigators entspricht die Anzeige der Abbildung 3.
Einzugeben ist der Anteil von zu übertragender Prozessorleistung und die Zielpartition. Wie bei allen dynamischen LPAR Zuordnungen werden die Veränderung unmittelbar ohne Durchführung eines IPL wirksam.
Interaktive Performance
Wird einer Partition mit schlechter Performance dynamisch zusätzliche Prozessorleistung zugewiesen und als Folge davon sinkt die CPU Auslastung der Partition, so verbessern sich möglicherweise damit auch die Antwortzeiten. Tritt eine Verbesserung der Antwortzeiten ein, kann man sicher davon ausgehen, dass der Engpass in unzureichender CPU Zuordnung bestanden hat. Verbessern sich die Antwortzeiten hingegen nicht, wird überdies eventuell auch noch zusätzliche interaktive Kapazität benötigt.
Anders als bei der CPU-Auslastung gibt es hier keine einzelne Variable, aus der sich die interaktive Performance einer Partition ablesen ließe. Ermitteln lassen sich Werte hier z.B. über die Aufzeichnungsmöglichkeiten und Performance Monitore im Operations Navigator. Eine Einschätzung lässt sich aber gegebenenfalls auch anhand der eigenen Antwortzeit oder der „Anzahl telefonischer Beschwerden betroffener interaktiver Benutzer„ vornehmen.
Zur Zuordnung interaktiver Kapazität wird die gleiche Schnittstelle wie zuvor schon zur Zuordnung von Prozessor-Ressourcen verwendet. Anzugeben ist die abgebende Partition, der entsprechende Prozentsatz interaktiver Kapazität und die Zielpartition. Wie vielleicht aus den vorherigen Ausführungen bereits erkennbar geworden ist, müssen die dynamisch neu zugeordneten Prozessor-Ressourcen nicht zwingend aus einer einzelnen Partition entnommen werden. Das bedeutet, dass durch die Neuverteilung von Ressourcen einerseits mehrere Partitionen profitieren können, andererseits aber eventuell auch mehrere Partitionen entsprechende Performance-Nachteile in Kauf nehmen müssen. Berücksichtigt werden sollte dabei aber grundsätzlich, dass interaktive Kapazität und CPU gegenseitige Abhängigkeiten aufweisen. Eine Zuteilung höherer interaktiver Kapazität zu einer Partition kann dazu führen, dass dieser Partition auch mehr CPU Ressourcen zugeordnet werden müssen, obwohl sich aus der Performance Statistik für diese Partition eine solche Maßnahme vielleicht nicht direkt ablesen lässt.
Neuzuordnung von Speicherressourcen
Eine hohe Anzahl an Fehlseiten (page faults) – abzulesen von aus der WRKSYSSTS Anzeige – sind das sicherste Zeichen dafür, dass eine Partition mehr Speicher benötigt. Zusätzlich hat die Anzahl der Plattenarme einer Partition Einfluss auf die noch zu tolerierende Anzahl von Fehlseiten.
Um ein extremes Beispiel zu wählen: würde nur eine einzige Platte mit 100 Fehlseiten/sek. zur Verfügung stehen, hätte das System erhebliche Schwierigkeiten, überhaupt irgendeine Verarbeitung erledigt zu bekommen. Stünden aber 100 Platten zur Verfügung, ließen sich 100 Fehlseiten/sec problemlos tolerieren, da die effektive Fehlseitenrate nur 1/sek./Plattenarm beträgt. Eine grobe, aber recht nützliche Daumenregel ist es, die Fehlseitenrate durch die der Partition zur Verfügung stehende Anzahl von Platten (Plattenarmen) zu dividieren und das Ergebnis als effektive Fehlseitenrate zu Vergleichszwecken zu benutzen. Aus der WRKDSKSTS (work with disk status) Anzeige lässt sich die Anzahl der Platten in der Partition ermitteln. Mit Hilfe des Operations Navigators (siehe Abbildung 4) oder über die LPAR Konfigurationsanzeige lassen sich Speicherressourcen zwischen den Partitionen umverteilen.
Bei der Übertragung von Speicherressourcen besteht keine Abhängigkeit zu anderen Ressourcen. Anders als bei Prozessoren und interaktiver Kapazität geschieht die Übertragung von Speicher allerdings nicht unmittelbar. Wenn Speicher von einer Partition an eine andere übertragen wird, so muss zuerst die Gesamtmenge des zu übertragenden Speichers auf die Platte geschrieben werden. Aus diesem Grunde ist es nicht ratsam, zuviel Speicher in einem Arbeitsgang zu übertragen. Eine gute Daumenregel ist, nicht mehr als 500 MB oder aber nicht mehr als 20 % des Speichers einer Partition zu übertragen, welcher dieser beiden Werte auch immer geringer ist.
Sorgfältige Planung der LPAR Konfiguration sowie wohlüberlegter Einsatz der dynamischen LPAR Neuzuordnung von Ressourcen kann einen signifikanten und positiven Einfluss auf die Systemperformance ausüben.
Ähnliche Artikel:
