Optimierung der iSeries LPAR Performance

10. November 2008 | Von | Kategorie: Systemmanagement

Ein Artikel aus der NEWSolutions NEWSabo plus. Dieser 11 Seitige Artikel zeigt Optimierungs-Möglichkeiten für LPAR auf der iSeries auf.

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.

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
    Für die Planung einer LPAR Konfiguration sollten Überlegungen zu folgenden Fragen angestellt werden:

  1. Worin soll die primäre Aufgabenstellung jeder Partition bestehen? Beispielsweise könnten Partitionen angelegt werden für:
    • traditionelle Produktionsanwendungen
    • Anwendungsentwicklung
    • Web-Serving
    • Domino
    • andere Aufgaben

     

  2. Welche Workload ist für die einzelnen Partitionen zu erwarten? (Gewünschter prozentualer Anteil an der interaktiven Leistung und/oder der Batchleistung des Gesamtsystems in CPW)
  3. Zu welchen Zeiten treten die Spitzenbelastungen der einzelnen Partitionen ein?
  4. Welche Performance-Anforderungen werden an jede einzelne Partition in Relation zu den anderen zum gleichen Zeitpunkt aktiven Partitionen gestellt?

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.

Schlagworte: , , , , , , , , , , , , , , , ,

Schreibe einen Kommentar

Sie müssen eingeloggt sein, um einen Kommentar schreiben.