Das neue Betriebskonzept für den FP-Server
Helmut Mastal
Die drei Systeme SGI Power Challenge R 10000 des FP-Servers haben in den letzten Monaten, insbesondere nach dem Austausch der Quantum-Platten durch IBM-Platten im Rahmen der Gewährleistung im Juli dieses Jahres, eine zufriedenstellende Stabilität erreicht. Es war daher sinnvoll, das Betriebskonzept, welches im Herbst vergangenen Jahres aus einigen Defacto-Konventionen unter dem Eindruck der damaligen schlechten Betriebsbedingungen entstanden ist, nochmals grundsätzlich zu überdenken.
Maßgebend für ein neues Betriebskonzept sind die folgenden Voraussetzungen:
Die ShareII-Software, die für die gleichmäßige Verteilung der Ressourcen auf die Benutzer zuständig ist und jetzt auch die Überwachung der Disk-Quotas pro Gruppe bewältigt, ist hauptsächlich Ein-System-orientiert und eine entsprechende Erweiterung auf System-Complexe ist am Markt nicht erhältlich. Die Performance der NFS-Komponente des Betriebssystems ist relativ niedrig und – obwohl mit den neuesten Patch-Levels Verbesserungen erzielt wurden – ist abzusehen, daß etwa die zehnfache bisherige Performance nötig wäre, um einen wahlfreien Zugang von Produktionsjobs zu den einzelnen Systemen zu ermöglichen.
Es wurde daher entschieden, daß grundsätzlich Produktionsjobs einer Benutzergruppe nur auf dem System laufen, auf dem die zugehörigen Homedirectories liegen. Die Administration der Systeme soll aber auf einer gemeinsamen Basis von Usernames und Gruppen beruhen, sodaß der interaktive Zugang grundsätzlich auf allen drei Systemen möglich bleibt.
Im Juli 1997 wurden die Disk-Quotas scharf gemacht, nachdem mit den einzelnen Benutzergruppen noch der gegenwärtige und zukünftige Bedarf an Plattenplatz diskutiert worden war. Die Quotas stellen Kontingente für Benutzergruppen für das Homefilesystem /peopledar. Im allgemeinen bezieht sich damit die Quota-Angabe auf den Verbrauch eines Instituts. In einzelnen Fällen wurden bei Instituten mit mehreren deutlich unterscheidbaren Schwerpunkten der Arbeit am FP-Server Unterteilungen in Arbeitsgruppen mit getrennten Quotas vorgenommen.
Die Quotas werden im Rahmen von ShareII fiktiven Usernames der Form zzinst zugeordnet. Es sind Hard- und Softlimits definiert für das Filesystem /peopleund für die Summe aller Filesysteme. Es besteht dabei folgender Zusammenhang:
Hardlimit (people) = Softlimit
(people)x2 für Softlimit (people) < 500 MByte
sonst Softlimit (people) + 500 MByte
Softlimit (all) = Softlimit (people) + 1 GByte
Hardlimit (all) = Softlimit (people) + 2 GByte
Beim Überschreiten des Softlimits erfolgt eine Warnung, beim Überschreiten des Hardlimits wird der schreibende Prozeß abgebrochen.
Zur Information über die Limits steht das Utility-Programm pldag zur Verfügung. Mit
pldag hostname
kann auch jeweils die Belegung auf den beiden anderen Systemen gefunden werden.
Die für die Produktion gedachten Batch-Queues Long und Xlong sind ähnlich wie die Quotas den Arbeitsgruppen zugeordnet. Sie sind immer auf dem System angesiedelt, wo sich auch die Home-Directories befinden und haben ein Runlimit von jeweils 4 gleichzeitig exekutierenden Jobs. Erfolgt das Submit von einem anderen als dem Home-System aus, so wird der Job von NQS automatisch zum Home-System übertragen (Statisches Loadlevelling).
Die eher für Testzwecke gedachten Short-Queues sind auf jedem System angesiedelt. Die Durchführung erfolgt immer auf dem System, wo das Submit durchgeführt wurde. Es ist daher auch eine Durchführung am „falschen“ System möglich. Diese Möglichkeit ist vor allem zur Durchführung dringender Arbeiten gedacht und sollte im Normalfall nicht genützt werden, um den NFS-Zugriff auf die Home-Directories zu vermeiden.
Parallelisierung mit verschiedenen Methoden (Autoparallelisierung, MPI, ...) am Home-System ist zulässig. Die Parallelisierung mit MPI über mehrere Systeme hinweg ist im Sinne des neuen Betriebskonzepts nicht mehr möglich. Die über rsh und rexec zur Verfügung gestellten Betriebsmittel wurden auf das Ausmaß interaktiver Sessions (3000 CPU-Sekunden) reduziert. Parallelisierung mit MPI kann daher systemübergreifend nur mehr in Ausnahmefällen (Demos) angewendet werden.
Aufgrund des zeitlichen Verlaufs von Benutzerprojekten kommt es immer wieder zu ungleichen Belastungen der drei Systeme. Es werden daher in regelmäßigen Abständen die Verbräuche (CPU, Memory, Disk) untersucht und, wenn erforderlich, Umlagerungen von Benutzer-Homes (und der zugehörigen Produktions-Queues) auf andere Systeme vorgenommen, selbstverständlich nach Absprache mit den Betroffenen.
Bei wesentlichen Änderungen an den Voraussetzungen sind auch entsprechende Konsequenzen beim Betriebskonzept denkbar.