Middleware bildet Basis für hybride Nutzungsvarianten - Midrange ...

Seit einiger Zeit ist Live Partition
Mobility (LPM) auch für IBM i verfügbar.
Damit ist es möglich, eine LPAR
im laufenden Betrieb auf ein zweites
System zu migrieren. Dieser Vorgang
läuft in mehreren Schritten ab: Zuerst
wird überprüft, ob auf dem Zielsystem
genügend Ressourcen (CPU, Hauptspeicher)
verfügbar sind, um die neue LPAR
aufzunehmen. Ist dies der Fall, so wird
automatisch eine Shell-LPAR erzeugt.
Anschließend werden im zugehörigen
VIO-Server des Zielssystems die notwendigen
VSCSI- und NPIV-Konfigurationen
erzeugt. Dann beginnt die Migration
der Hauptspeicherinhalte des
primären Systems zum neuen System.
Während dieser Zeit kann auf dem primären
System weiterhin gearbeitet werden.
Wenn nur noch ein geringer Anteil
der Hauptspeicherseiten zur Migration
ansteht, wird das primäre System eingefroren.
Die Endanwender „sehen die
Eieruhr“; die Jobs im System werden
nicht abnormal beendet. Die restlichen
Hauptspeicherseiten werden migriert
und die Jobs laufen auf dem neuen System
weiter. Auf dem primären System
wird die ursprüngliche LPAR-Definition
als letzter Schritt gelöscht.
Live Partition Mobility ist kein
Ersatz für eine Hochverfügbarkeitslösung.
Der Vorgang kann nur angestoßen
werden, wenn der Hypervisor
noch aktiv ist. Wenn das gesamte System
„abgestürzt“ ist, so kann auch kein
LPM mehr angestoßen werden. Außerdem
ist zu beachten, dass jeweils eine
komplett neue LPAR erstellt und die
alte gelöscht wird. Szenarien – wie Datensicherung
auf dem Backup-System
oder Arbeiten auf dem Backup-System
–, während auf dem Produktivsystem
z. B. ein Release-Wechsel läuft, sind mit
Live Partition Mobility nicht zu realisieren.
Vielmehr geht es darum, geplante
Umzüge auf eine zweite Hardware ohne
Unterbrechung des Betriebs zu ermöglichen
– sei es, um eine Wartung an der
Hardware vorzunehmen oder um wechselnde
Workloads zwischen mehreren
Systemen sinnvoll zu verteilen.
Voraussetzung für Live Partition
Mobility mit IBM i ist, dass alle Ressourcen
der entsprechenden LPAR
über einen VIO Server virtualisiert
sind. Die LPAR darf keine eigenen physischen
Adapter oder Plattenlaufwerke
besitzen. Beide Systeme müssen den
gleichen SAN Storage verwenden und
sich im gleichen Ethernet-Netzwerk
befinden. Außerdem müssen beide Systeme
mindestens Power7-Technologie
verwenden. Neben IBM i 7.1 sind der
Technology Refresh 4, Firmware Level
740.40 oder 730.51, HMC V7R7.5.0.M0
und VIOS 2.2.1.5 (FP25 SP3) notwendig.
PowerVM wird in der Enterprise
Edition benötigt. Für Kunden, die LPM
testen möchten, kann über das kostenlose
Hardware-Feature #ELPM eine
60-Tage-Testversion von Live Partition
Mobility bestellt werden. Um den Aufbau
einer Hochverfügbarkeitslösung
im IBM i-Umfeld zu unterstützen, bietet
die IBM sog. CBU Editions (Capacity
Backup) an. Diese Modelle verfügen
über ein spezielles Lizenzmodell, das
es erlaubt, IBM i-Lizenzen temporär
von einem zugeordneten Primärsystem
auf das CBU-System zu übertragen und
dort zu nutzen. Detaillierte Informationen
zu den erlaubten Kombinationen
von Primärsystem und CBU-Modell
finden sich unter: www.ibm.com/sys
tems/resources/systems_power_hard
ware_cbu_ps_cbu.pdf
Wenn das Backup-System nur bei
Ausfall des Produktivsystems genutzt
werden soll und keine regelmäßigen
Roll-Swaps geplant sind, kann dieses
Szenario auch über Capacity on Demand
abgedeckt werden. Dabei können
im System vorhandene, aber nicht
aktivierte Prozessoren temporär aktiviert
werden. Die Abrechnung erfolgt
tageweise. Utility Capacity on Demand
erlaubt sogar die minutenweise Abrechnung
von CPU-Verbrauch. Utility Capacity
on Demand setzt voraus, dass ein
bestimmter Pool an Prozessor-Ressourcen
zur Verfügung gestellt wird. Das
System „bedient“ sich automatisch aus
diesem Pool, wenn die permanent aktivierten
Prozessoren nicht ausreichen,
um die vorhandene Last zu verarbeiten
und schaltet die benötigten Prozessoren
selbständig hinzu. Sabine Jordan ó
ANZEIGE
03/2013 · MIDRANGE MAGAZIN
25