5.5. Multiple Shared Prozessor Pools
Eine Shared Prozessor LPAR mit Sharing-Mode uncap bekommt garantiert immer das konfigurierte Entitlement (desired_proc_units). Darüber hinaus kann eine solche LPAR, bei Verfügbarkeit, zusätzliche Prozessor-Anteile gemäß ihrer Gewichtung (uncapped_weight) bekommen. Es ist damit sicher gestellt das die LPAR bei Bedarf als Minimum ihr Entitlement zugewiesen bekommt, meistens aber auch mehr. Eine Begrenzung nach oben, also wieviele Prozessor-Anteile eine LPAR maximal bekommen kann, gibt es nur indirekt. Die Anzahl der virtuellen Prozessoren begrenzt zwar die Menge an Prozessor-Anteilen nach oben, die Begrenzung kann aber sehr hoch ausfallen, wenn eine LPAR z.B. mit einem Entitlement von 0.8 und 16 virtuellen Prozessoren konfiguriert wurde. Die LPAR kann in diesem Fall unter günstigen Umständen bis zu 16 komplette physikalische Prozessor-Cores in Beschlag nehmen (natürlich nur wenn entsprechend viele Prozessor-Anteile zur Verfügung stehen). Gibt es wenig Konkurrenz auf einem Managed System, kann eine LPAR auch mit einem niedrigen Wert bei der Gewichtung einen beträchtlichen Anteil an Prozessor-Anteilen bekommen, wie das Beispiel in Bild 5.11 zeigt.
Obwohl die LPAR nur ein Entitlement von 0.2 besitzt und einen sehr niedrigen Wert für die Gewichtung (uncap_weight=10) belegt sie in der Spitze bis zu 4 komplette Prozessor-Cores! Mehr ist bei einer Konfiguration mit 4 virtuellen Prozessoren nicht möglich.
Natürlich kann die LPAR nur soviel Prozessor-Anteile bekommen, da genügend Prozessor-Ressourcen verfügbar stehen und offensichtlich alle LPARs mit einer höheren Gewichtung ebenfalls große Mengen an Prozessor-Anteilen bekommen haben. Insofern könnte man sich auf den Standpunkt stellen das es in diesem Falle gut ist eine solche Menge an Prozessor-Ressourcen zuzuteilen, da diese ja ansonsten nicht genutzt würden. Allerdings sollte man bedenken das die Performance der dargestellten LPAR extrem unterschiedlich ausfallen kann. Zu Zeiten wo keine zusätzlichen Prozessor-Anteile verfügbar sind, bekommt die LPAR ihr garantiertes Entitlement von 0.2 (grüner Bereich im Bild). Zu anderen Zeiten, wenn sehr viele Prozessor-Ressourcen verfügbar sind, verwendet sie bis zu 4.0 physikalische Prozessor-Cores. Das ist 20 mal mehr als das garantierte Entitlement. Die Performance der LPAR kann dann auch auf das 20 fache ansteigen. Das heißt die Performance der LPAR ist extrem variabel, mal ist die Performance niedrig (nur das Entitlement steht zur Verfügung), mal ist die Performance 20 fach höher (4 komplette physikalische Prozessor-Cores stehen zur Verfügung). Dieses Verhalten ist in vielen Fällen nicht gewünscht.
Mit der Einführung von Multiple Shared Prozessor Pools (MSPP) gibt es die Möglichkeit die Verwendung von Prozessor-Anteilen für LPARs zu begrenzen. Hierfür können bis zu 64 Shared Prozessor Pools konfiguriert werden, wobei jedem Pool eine maximale Pool-Kapazität zugewiesen werden kann. Den Prozessor Pools können dann Shared Prozessor LPARs zugewiesen werden, welche dann in der Summe maximal die konfigurierte maximale Pool-Kapazität verbrauchen können. Dies ist aber nur eine der Möglichkeiten die der Einsatz von Multiple Shared Prozessor Pools bietet.
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.