Bundesamt für Sicherheit in der Informationstechnik

G 4.50 Überlastung des z/OS-Betriebssystems

Auch wenn durch den Workload Manager ein z/OS-Betriebssystem so verwaltet wird, dass eine Überlastung eigentlich nicht vorkommen sollte, gibt es eine Reihe von Gefährdungen, die zu einer Überlastung führen können. Eine Überlastung muss nicht zwangsläufig zu einem kompletten System-Stillstand führen. Es können auch nur verschiedene System-Ressourcen nicht mehr verfügbar sein, obwohl das System selbst noch reagiert. Die nachfolgenden Situationen sind typisch, aber nicht die einzigen Gefährdungen dieser Art.

Spool-Full-Situation

Die Spool-Datei eines Job Entry Subsystem (JESx) ist nur für eine bestimmte Menge von Ausgabedaten vorgesehen. Es kann vorkommen, dass z. B. durch eine Programmschleife unbegrenzt Daten auf die Spool-Datei des JESx geschrieben werden. Dies kann zu einer Spool-Full-Situation führen, neue Batch-Jobs können nicht mehr gestartet werden. Nur die laufenden Online-Verfahren sind u. U. noch aktiv, sofern keine Ausgabedateien auf die Spool-Datei geschrieben werden. Da viele JES-Kommandos bei der Ausführung eine benutzbare Spool-Datei voraussetzen, kann dies bedeuten, dass umfangreiche (und zeitintensive) Recovery-Maßnahmen notwendig sind, um dieses Problem zu bereinigen.

Vollständiger System-Stillstand

Unix-Prozesse im USS-Subsystem (Unix System Services) werden in z/OS auf Adressräume abgebildet. Steht nicht mehr genügend Hauptspeicher zur Verfügung, müssen diese Adressräume über den AuxiliaryStorage Manager ( ASM ) auf die Page-Platten ausgelagert werden. Reichen auch diese nicht aus, kann kein Adressraum mehr angelegt werden.

Wenn die Anzahl der Unix-Prozesse im USS nicht beschränkt ist und nicht genügend Platz auf den Page-Platten zur Verfügung steht, können sich deshalb Sicherheitsprobleme durch den Start von zu vielen Unix-Prozessen ergeben. Ursache kann beispielsweise eine rekursive Funktion sein, die unentwegt neue Unix-Prozesse startet. Als Folge kann es passieren, dass das System praktisch stillsteht.

Von diesem Problem ist z/OS (mit 64 Bit-Adressierung) im Vergleich zu seinem Vorgänger OS/390 (mit 31 Bit-Adressierung) durch die höhere Adressierbarkeit deutlich weniger betroffen. Durch die höhere Adressierbarkeit kann dem z/OS-System ein größerer Hauptspeicher zur Verfügung gestellt werden. Dies hat zur Folge, dass die Page-Platten erst viel später benötigt werden.

Generell können Kommandos oder Programmteile, die ständig neue Prozesse starten, sehr schnell das System überlasten. Dies kann letztendlich einen Initial Program Load (IPL) erforderlich machen.

Systemüberlastung durch zu viele JESx Initiators

Über die Anzahl der gestarteten Initiators steuert der Administrator die Batch-Verarbeitung und deren Prioritäten. Sind zu wenig Initiators gestartet, können Staus bei der Batch-Verarbeitung entstehen. Sind zu viele Initiators gestartet, kann dies zur Überlastung von Ressourcen führen.

Werden zu viele Batch-Jobs gestartet, so besteht die Gefahr, dass die Page Datasets nicht ausreichen. Dies erfordert ein manuelles Eingreifen in die Systemsteuerung durch das Bedienpersonal.

Ist das Job Entry Subsystem mit einer sehr großen Anzahl von Initiators definiert worden, die jedoch nicht sofort aktiviert werden, kann es vorkommen, dass bei der Eingabe des JES2-Kommandos $SI (statt z. B. $SI1-10) alle möglichen Initiators gestartet werden. Dadurch laufen unter Umständen mehr Batch-Jobs an als geplant. Dies führt zwar in der Regel nicht zu einem System-Stillstand, die Antwortzeiten können sich jedoch erheblich verlängern.

Verzögerte Bandverarbeitung

Wenn gleichzeitig mehr Bandeinheiten angefordert werden, als Stationen vorhanden sind, verzögert sich die Sicherung der Daten auf Bänder. Die Sicherungs-Jobs gehen in den Wait-Status und warten auf freie Bandstationen.

Beispiele

  • In einer z/OS-Installation wurden zu viele Initiators gestartet. Dies hatte zur Folge, dass während der Batch-Verarbeitung zu viele Batch-Jobs gleichzeitig aktiviert wurden, wodurch die CPU des Systems stark belastet wurde. Obwohl das System die Last bewältigt hat, führte die Situation zu langen Antwortzeiten bei der Time Sharing Option (TSO).
  • Bei der USS-Basisdefinition eines z/OS-Betriebssystems wurden die Werte von MAXPROCSYS und MAXFILEPROC auf sehr hohe Werte gesetzt. Als ein Mitarbeiter einen rekursiven Funktionsaufruf, den er auf einer Unix-Schulung kennen gelernt hatte, unter Unix System Services ausprobierte, blieb das System nach kurzer Zeit wegen Auxiliary Storage Shortage stehen.

Stand: Stand 2005