6.2. Active Memory Sharing (AMS)

Ähnlich wie im Falle von Shared Prozessoren, besteht auch beim physikalischen Speicher die Möglichkeit diesen mit mehreren LPARs zu teilen. Dabei werden den LPARs zu unterschiedlichen Zeiten unterschiedlich viel physikalischer Speicher zugewiesen, je nach Bedarf. Die Menge des physikalischen Speichers einer LPAR kann dabei im Laufe der Zeit variieren.

In der Regel wird die Hauptspeicher-Größe einer LPAR vom Administrator ausreichend und mit einem mehr oder weniger großen Sicherheitspuffer für Spitzen der Auslastung gewählt. Das sogenannte Working-Set (Speicher-Seiten die tatsächlich verwendet werden), ist in der Regel kleiner. Andernfalls ist erhöhtes Paging die Folge. Bei PowerHA-Systemen muß für den Fall einer Übernahme ausreichend viel Speicher verfügbar sein, ansonsten könnte eine Übernahme im Fehlerfalle scheitern. Dies bedeutet aber, das insbesondere bei Cluster-Systemen der Unterschied zwischen dem aktuell tatsächlich benötigten Speicher und dem konfigurierten Speicher leicht die halbe Hauptspeicher-Größe erreichen kann. Solange keine Übernahme erfolgt, wird der hierfür konfigurierte Speicher nicht verwendet (abgesehen vom Filesystem-Caching).

In Bild 6.2 ist die tatsächliche Speicherauslastung einiger LPARs über den Verlauf eines Tages gezeigt. Die rote Linie zeigt die Summe der konfigurierten Hauptspeicher-Größen der LPARs an (248 GB). Die LPARs bleiben im Verlauf des Tages in Summe allerdings teilweise deutlich unter diesem Wert. Die dargestellten Werte stammen von realen Produktionssystemen. Man sieht zwar hier nicht die in diesem Zusammenhang gern dargestellten Benutzungs-Berge einer LPAR, die auf ein Benutzungs-Tal einer anderen LPAR treffen, es werden aber trotzdem zwischen ca. 60 und 100 GB an zugewiesenem Speicher von den LPARs nicht verwendet. Mit diesem Speicher könnten zum Beispiel weitere LPARs auf dem Managed System betrieben werden, oder es könnte einzelnen LPARs mehr Speicher zugewiesen werden.

Actual (total) memory usage of some LPARs during a day.
Bild 6.2: Tatsächlicher Speicherverbrauch einiger LPARs während eines Tages.

Analog zu den Shared Prozessoren kann für das Teilen von Speicher ein sogenannter Shared Memory Pool angelegt werden. Im Unterschied zu den Shared Prozessoren, gibt es aber maximal nur einen Shared Memory Pool. Im Prinzip können dann fast beliebig viele LPARs (maximal 1000) dem Shared Memory Pool zugewiesen werden. Die Summe der Hauptspeicher-Größen dieser LPARs darf die Hauptspeicher-Größe des Shared Memory Pools übersteigen. Beispielsweise könnte in der Situation von Bild 6.2 ein Shared Memory Pool der Größe 200 GB angelegt werden und alle dargestellten 6 LPARs mit zusammen 248 GB Speicher-Größe zugewiesen werden. Da nicht ausgeschlossen werden kann, das nicht doch einmal alle LPARs zusammen mehr als 200 GB tatsächlich benutzen, muß der fehlende Speicher von 248 GB – 200 GB = 48 GB natürlich in irgendeiner Form vorgehalten werden. Hier kommen die schon von Betriebssystemen bekannten Paging-Devices in Spiel. Für jede LPAR, die den Shared Memory Pool verwendet, muß ein eigenes Paging-Device (mit einer Kapazität von mindestens der maximalen Speichergröße der LPAR) bereit gestellt werden. Fehlender physikalischer Hauptspeicher wird dann durch Speicher auf den Paging-Devices ersetzt.

In Bild 6.3 ist ein Shared Memory Pool mit 2 Shared Memory LPARs gezeigt. Der Speicher der LPARs setzt sich dabei aus physikalischem Hauptspeicher des Shared Memory Pools und eventuell Speicher von Paging-Devices zusammen. Für die LPARs selber ist nicht feststellbar, ob ein Speicherbereich physikalischen Speicher oder Speicher auf einem Paging-Device verwendet. Die Zuordnung von physikalischem Speicher aus dem Shared Memory Pool auf die einzelnen LPARs erfolgt dynamisch durch den Hypervisor. Der Hypervisor kann nach Auslagern von physikalischen Speicherseiten auf ein Paging-Device den freigewordenen physikalischen Speicher einer anderen LPAR zuordnen. Greift die ursprüngliche LPAR wieder auf die ausgelagerten Speicherseiten zu, ordnet der Hypervisor freie physikalische Speicherseiten zu, startet I/O auf das Paging-Device um die ausgelagerten Daten zu lesen und speichert diese dann auf den neuen physikalischen Speicherseiten ab. Die zugehörige LPAR bekommt von diesen Hintergrund-Aktionen nichts mit. Der Speicherzugriff dauert lediglich etwas länger.

Shared memory pool with 2 shared memory LPARs.
Bild 6.3: Shared Memory Pool mit 2 Shared Memory LPARs.

Da der Hypervisor selbst als Firmware nicht direkt selbst I/O auf die Paging-Devices starten kann, es braucht dazu den Kontext einer LPAR, muß einem Shared Memory Pool mindestens ein Virtual-I/O-Server zugeordnet werden, der das I/O von und zu den Paging-Devices übernimmt. Ein solcher Virtual-I/O-Server wird dabei als Paging Virtual-I/O-Server bezeichnet. Damit müssen die Paging-Devices auf dem Paging Virtual-I/O-Server sichtbar und zugreifbar sein. Der Hypervisor delegiert also das I/O zu den Paging-Devices an einen Paging Virtual-I/O-Server.

Das Teilen von physikalischem Hauptspeicher über einen Shared Memory Pool wird als Active Memory Sharing (AMS) bezeichnet.