Konzepte

Bei klassischen Batchsystemen wie dem CXbatch (und ähnlichen, auf NQS basierenden Systemen) werden Jobs je nach Anforderungen, vor allem CPU-Zeit und Hauptspeicherbedarf, in Klassen eingeteilt und jeder Jobklasse eine Queue zugeordnet. Dieses Verfahren funktioniert gut, wenn die Verteilung der Jobs auf die Klassen im wesentlichen gleich bleibt. In einer Umgebung mit sich ständig änderndem Jobmix wie an einem Hochschul-Rechenzentrum treten aber sofort Probleme auf:

• Teilt man die Ressourcen eines Rechners komplett auf Queues auf, kann die Maschine halb leer stehen, obwohl Jobs gerechnet werden könnten. Treten etwa von einer Jobklasse weniger Jobs auf als geplant, werden die der entsprechenden Queue zugeordneten Ressourcen nicht ausgenutzt. Gleichzeitig warten aber u.U. Jobs in anderen Queues, die eigentlich gerechnet werden könnten.

• Vergibt man aber mehr als die vorhandenen Ressourcen und hofft auf eine vernünftige Verteilung, kann es leicht passieren, dass der Rechner zu stark belastet wird, was zu verringerter Performance oder sogar zu Abstürzen führen kann.

LSF geht daher einen anderen Weg: Im einfachsten Fall gibt es nur eine einzige Queue, die alle Ressourcen einer Maschine verwaltet. Ein Job spezifiziert seinen Bedarf und das Batchsystem startet ihn, sobald die Anforderungen erfüllt werden können. Dabei können sehr verschiedene Ressourcen angegeben werden, z.B.:

• CPU-Zeit
• Hauptspeicher
• Plattenplatz (etwa in /usertemp)
• Anzahl der CPUs
• Anzahl von Lizenzen einer bestimmten Software
• anderer Job ist fertig (Kettenjobs)

Können mehrere Jobs gestartet werden, gilt dabei natürlich grundsätzlich das übliche Warteschlangen-Prinzip: Wer zuerst kommt, rechnet zuerst. Dies kann bedeuten, dass ein einzelner Benutzer, der eine große Zahl von Jobs absetzt, den Rechner auf längere Zeit mit Beschlag belegt. Um auch dieses Problem zu lösen, gibt es bei LSF eine zusätzliche Prioritäten-Steuerung. So kann man etwa dafür sorgen, dass Jobs von Benutzern oder Arbeitsgruppen bevorzugt werden, die in letzter Zeit weniger CPU-Zeit verbraucht haben oder von denen gerade weniger Jobs laufen.

Ein weiteres Problem ist das Zusammenspiel von parallelen und nicht-parallelen Jobs. Fordert etwa ein großer Paralleljob 8 CPUs an, während gerade nur vier CPUs frei sind, wird er zunächst warten müssen. Kleinere Jobs können aber gestartet werden, so dass möglicherweise nie 8 CPUs gleichzeitig frei sind und der große Job ``verhungert''. Damit das nicht passiert, reserviert LSF die freien CPUs und alle weiteren frei werdenden, bis der große Job gestartet werden kann. Ein solches Vorgehen verschlechtert allerdings die Auslastung, weil ja dadurch CPUs unbenutzt bleiben.

Dagegen verwendet LSF das folgende, als ``Backfilling'' bezeichnete Verfahren: Da die Laufzeiten der Jobs beim Start angegeben werden bzw. durch die maximale Laufzeit in der Queue begrenzt sind, kann man abschätzen, wie lange es dauert, bis der große Job an der Reihe ist. Die frei werdenden CPUs werden dann mit kleinen Jobs beschäftigt, die rechtzeitig fertig sind, so dass sie den großen Job nicht aufhalten. Auf diese Weise wird ein vernünftiger Kompromiss zwischen dem Wunsch nach hoher Auslastung und den Anforderungen großer Jobs erzielt.