Im Unterschied zum klassischen Prozess-Handling innerhalb von Betriebssystemen bzw. Programmiersprachen ermöglicht es der hier vorliegende Prozess-Kernel

• Prozesse über mehrere Server hinweg verteilt zu verwalten,
• Betriebssystem-unabhängig zu arbeiten, auch in heterogenen OS-Umgebungen
• ohne dedizierte Steuerung die am Gesamtsystem beteiligten Server, auf denen dieser Kernel läuft,
  selbstverwaltend arbeiten zu lassen (autonome Lastverteilung, Eigenregistrierung der Server)

Die PIC (Prozess Inter Communication = Verwaltung der Prozesse und Austausch diesbezüglicher Informationen) erfolgt über eine im System logisch einmalig vorhandene SQL-Datenbank. Als SQL-Datenbank sind z.Zt. MySQL, MS-SQL und Oracle erprobt. Weitere Datenbank-Typen können bedarfsweise ergänzt werden.

Verwaltungstechnisch stehen zur PIC sowohl zwischen den Prozessen als auch zur externen Steuerung (z.B. per HTML-Interface) u.a. Stati- und Signal-Felder je Prozess und je Server zur Verfügung. Die Prozesse selbst werden als Record in einer entsprechenden Tabelle gehalten, wobei diese als Basis für History-Aussagen (Records werden nicht gelöscht), zur Selbstbereinigung des Systems (killen evtl. hängender Prozesse), zur Verwaltung von Prozess-Abhängigkeiten (Prozess A ist Child-Prozess von Prozess B), zur Server-Zuordnung der Prozesse sowie als Grundlage zur Laufzeitüberwachung (Down-Status, Start- und Alive-Zeiten) dienen.

Der Bedarf an zu startenden Prozessen (Jobs) wird durch eine SQL-Tabelle vorgegeben, die durch den/die Kernel-Prozess(e) des/der Server(s) laufend überwacht wird. Die Übernahme eines Jobs und dessen Start durch einen Server bestimmt sich dabei einerseits aus dem Erreichen von bestimmten Job-Parametern wie Startzeiten und Startfreigaben, andererseits aus dem Fakt, dass bestimmte Randparameter (z.B. zur Durchführung des Jobs notwendige Ressourcen des jeweiligen Servers) verfügbar und im Moment frei sind. Nach Übernahme eines Jobs durch einen Server ist der Job während seiner Laufzeit für die Übernahme durch andere Server gesperrt und unterliegt der Timeoutüberwachung des jeweiligen Kernels.

Der Kernel selbst kann cross-over (von anderen Servern/Kernel aus) oder durch Cron-Jobs des gleichen Servers überwacht werden, wobei dank einer Mitführung der Ereignisse "Letzter Betriebssystem-Start des Servers" sowie "Letzter Kernel-Start" evtl. bei Absturz oder Kernel-Abbruch entstandene überhängende Jobs sauber abgebaut werden (Selbstbereinigung des Prozess-Kernels). Diese Mechanismen sind auf Basis der Betriebssysteme Windows (Windows-NT, Windows 2000) sowie Linux (Suse/bash) erprobt.

Der Prozess-Kernel ist als eigenständiges open source Programm auf Basis der Scriptsprache Perl ausgelegt und unterliegt der GPL im Copyright Dr. G. Wanjek / mhr.de 2000-2002; gpl@mhr.de . Damit ist sichergestellt, dass er als zentraler Bestandteil der Anwendungssysteme jederzeit auch durch lokale Administratoren bedarfsweise kurzfristig angepasst bzw. modular erweitert werden kann, sowie durch breite Anwendungsbasis insgesamt schneller höhere Programmstabilität erringt.

Die weiteren Beschreibungen des Kernels beziehen sich auf den beispielhaften Anwendungsfall, Prozesse zur DFÜ-Kommunikation auszulösen und zu verwalten. Die Ressourcenverwaltung bezieht sich in diesem Fall als Devices (Geräte zur DFÜ-Kommunikation auf den jeweiligen Servern) sowie Module (zu startende Programm-Bausteine z.B. zur Kommunikation, Berechnung, Wandlung usw.). Die dabei gegebenenfalls verwendeten Programmmodule bzw. eventuell benötigte Geräte werden durch die vordefinierten Jobs dabei abstrakt vorgegeben (Devicetyp / Modultyp). Der/die Prozess-Kernel übernehmen diese Jobs jedoch anhand der an ihnen konkret verfügbaren und im Kernel-Startprozess registrierten effektiven Ressourcen (Module und Devices).

Erprobte Anwendungsfälle sind u.a. rechenzeitintensive Berechnungs- und Konvertierungsaufgaben in autonomer Lastverteilung, sowie Kommunikationsaufgaben, z.B. zur taskgesteuerten Anlagen-Überwachung.

Arbeitsweise des Prozess-Kernels
Der Prozess-Kernel arbeitet in zwei Phasen:

• Startprozess
• Watchdog-Prozess mit Jobstart-Prozess

Der Startprozess wird einmalig durchlaufen und mündet in einen Zyklus, der als Watchdog-Prozess permanent laufend die eigentlichen Funktionen des Prozess-Kernels (Start und Überwachung von Jobs) bereitstellt. Der Watchdog-Prozess kann mittels Signal an den entsprechenden SQL-Record beendet werden.

Startprozess
Im Startprozess werden nacheinander folgende Schritte durchlaufen. Diese Schrittfolge kann bedarfsweise modular erweitert oder angepasst werden.

• Server-Registrierung: Der den Kernel startende Server wird in der Datenbank registriert. Abhängig von der IP-Adresse des den Prozess tragenden Servers wird ein dort schon vorhandener Eintrag aktualisiert oder neu angelegt. Sollten mehrere Records mit der IP-Adresse, die angefordert wurde, bereits existieren, werden diese entfernt und eine Neuregistrierung durchgeführt.
• Ermittlung der Server-ID: Dieses Feld ist als PK (Primary Key) eindeutig innerhalb der Datenbank und nachfolgend das Kriterium für den Server-Bezug aller weiteren Aktionen. Mehrfachregistrierungen (die u.U. auftreten bei unsauber konfigurierten SQL-Servern mit Mehrfach-CPU’s) und gesetztes "disabled"-Flag (ungleich 0) werden getestet und münden ggf. in entsprechende Fehlerabbrüche. Bei Erfolg wird in der Prozesstabelle ein neues Record für den Kernel-Prozess aufgenommen, welches von "normalen Jobs" anhand folgender Kriterien unterscheidbar ist:
• prozesse.pro_pro_idx=NULL (ist kein Child-Prozess eines Kernel-Prozesses)
• ID/PK des aktuellen Servers
• Ermittlung der Uptime des Servers: Die Zeit des letzten Starts des Server-Betriebssystems (OS) wird ermittelt, um darauf basierend nachfolgend ggf. nach Kernel-Kill od. –absturz noch laufende Child-Prozesse zu entfernen. Hintergrund ist die Entscheidung, ob registrierte PID’s (Prozess-ID’s) noch gültig sind (=kill evtl. noch laufender Prozesse) oder nicht (PID u.U. neu vergeben nach OS-Neustart)
• Entfernen ggf. noch laufender alter Child-Prozesse: Nach letztem OS-Start gestartete und noch als "laufend" gekennzeichnete Child-Prozesse (prozesse.pro_down!=1) werden gekillt, ältere lediglich in der Datenbank verwaltungstechnisch bereinigt.
• Ressourcen-Registrierung: Die physisch verfügbaren Ressourcen des Servers werden registriert und in den Tabellen "module" (installierte Software-Bausteine für Jobs), "devices" (vorhandene eventuell notwendige Geräte zur Jobausführung) sowie "xMoDvt" (effektiv vorhandene Modul-Devicetyp-Relationen) eingetragen. Diese Tabellen werden bzgl. des aktuellen Servers komplett neu gefüllt (Löschen alter Einträge und Neueintrag). Die Tabellen "devicetyp" bzw. "modultyp", die Aussagen zur abstrakten Beschreibung der Module/Devices enthalten, werden ggf. ergänzt, jedoch werden dort nie Einträge gelöscht.
• Watchdog-Start: Der zyklische Watchdog-Prozess wird gestartet. Als Kennzeichen für diesen Zustand wird folgende Änderung im Record des Kernel-Prozesses durchgeführt:
• prozesse.pro_iswatchdog=1 (vorher: 0)

Watchdog-Prozess
Der Watchdog (="Wachhund")-Prozess dient der zyklischen Überwachung von folgenden Ereignissen:

• Watchdog beenden (down): Der Watchdog-Prozess und das Kernel-Programm selbst terminieren (beenden sich) nach folgenden Ereignissen bzw. Signalen am Record des Kernel-Prozesses:
• Hartes Down: prozesse.pro_down=1 (vorher: 0)
  evtl. noch laufende Child-Prozesse werden sofort gekillt
• Soft-Down: prozesse.pro_signal=1 (vorher: 0)
  bzgl. evtl. noch laufender Child-Prozesse dieses Kernels wird auf deren Beendigung
  bzw. Timeout gewartet. Danach terminieren Watchdog- und Kernel-Prozess
• Server wird administrativ deaktiviert
  Dieses Ereignis mündet in ein Soft-Down. Wird vor Ende evtl. noch laufender Jobs der Server-disabled-Status wieder aufgehoben, läuft der Watchdog-Prozess unverändert weiter.
• Job-Timeout-Überwachung: Child-Prozesse dieses Servers werden in der Datenbank mit zwei Zeitstempeln versehen: prozesse.pro_made (Zeitstempel bei Erzeugung des Job-Prozesses), sowie prozesse.pro_alive (Zeitstempel bei Erzeugung, sowie bei Aktualisierung durch den Job selbst). Diese werden in Differenz zu folgenden Werten verglichen und bei Überschreitung als Ereignis gewertet, um den Job zu killen:
• $maxTimeoutJob: maximale Gesamtdauer eines Jobs in Sekunden (wird verglichen mit pro_made)
$aliveTimeoutJob: maximale Zeitdifferenz seit letztem alive-Tick des Jobs in Sekunden (wird verglichen mit pro_alive, "Job lebt noch")
• Kernel-alive: Im Kernel-Prozess-Record wird zur Kernel-Eigenüberwachung das Feld prozesse.pro_alive mit dem aktuellen Zeitstempel aktualisiert.
• Jobs starten: Der Kernel-Prozess überwacht die Tabelle "jobs", ob Aufträge zum Job-Start vorliegen. Grundlage sind dabei einerseits effektiv verfügbare Ressourcen des Servers (siehe Startprozess) sowie deren momentane Verfügbarkeit durch evtl. schon gestartete Jobs (maximale parallele Startbarkeit), sowie das Erreichen folgender Parameter am Job
• geforderter Device- und Modultyp passend zu freien Ressourcen (jobs.job_dvt_idx bzw. jobs.job_mot_idx
  passend zu registrierten freien Modulen/Devices)
• Startzeit(en) erreicht (jobs.job_start_min, *_opt, *_max)
• Job läuft noch nicht (jobs.job_running=0)
• Job ist freigegeben zur Bearbeitung (jobs.job_returncode=0)
• Job wurde bisher von keinem anderen Server übernommen

Job-Start-Prozess
Hat der Watchdog-Prozess einen oder mehrere Jobs für sich als startfähig erkannt, wird eine Job-Start-Sequenz abgearbeitet. Da die evtl. auf mehrere Server verteilten Prozess-Kernel eigenständig anstehende Jobs als für sich startbar erkennen, andererseits die Jobs innerhalb der Watchdog-Schleife sequentiell bei Erreichen des Jobstart-Ereignisses ohne Möglichkeit der dedizierten oder gar exakten Zeitvorgabe des tatsächlichen Startmomentes gestartet würden, werden hier Maßnahmen der Verriegelung möglicher Mehrfach-Jobstarts auf unterschiedlichen Servern notwendig.

Dazu wird bei evtl. mehrfach vorhandenen startbaren Jobs über diese ein Job-Stapel aufgebaut, wobei jeweils nur der oberste der zum Start anstehenden Jobs versucht wird zu starten. Die Reihenfolge dieses Jobstapels ergibt sich aus der Sortierung der Job-Startzeiten (min, opt, max) sowie, so immer noch identische Zeiten vorliegen, nach dem eindeutigen PK des Jobs (job_idx = Reihenfolge der Job-Generierung). Da während des Startversuches des Jobs ein anderer Kernel auf einem anderen Server die weiteren Jobs bereits gestartet haben kann, wird der Job-Stapel im nächsten Zyklus erneut abgefragt.

Vor dem eigentlichen Start eines Jobs wird zusätzlich eine Sequenz durchlaufen, die sicherstellt, dass kein anderer Server zufälligerweise exakt zeitgleich den selben Job startet. Dazu versucht der Kernel-Server zunächst, den betreffenden Job als "von ihm übernommen" zu kennzeichnen. Hierfür wird versucht, die ID des eigenen Servers einzutragen. Die dabei geltende Nebenbedingung "von noch keinem anderen Server übernommen" verhindert unter Ausnutzung von SQL-eigenen Locking-Mechanismen die gleichzeitige Übernahme durch andere Server und sichert letztendlich damit die komplette Selbstverwaltung der Server.

Der eigentliche Jobstart erfolgt unterschiedlich bzgl. des zugrundeliegenden Betriebssystems. Diese Unterscheidung wird notwendig, da die Verwendung von Oracle als Datenbanksystem in Kombination zu Windows als Betriebssystem eines Kernel-Servers kein sauberes Generieren von Child-Prozessen per "fork" o.ä. erlaubt. Während somit auf Unix-Basis laufende Kernel-Server noch innerhalb des Kernels die PID des gestarteten Job-Prozesses registrieren könnten (PID ist notwendig für Startup- oder Timeout-Kill-Sequenzen), müssen zumindest Windows-Module innerhalb des Moduls selbst diese Registrierung vornehmen (siehe setPidJob() in ./*_pic_lib.pl). Weiterhin kann es möglich sein, dass bestimmte Module auf bestimmten Betriebssystemen sogenannte "Stub-Prozesse" (kleine vorgelagerte Prozesse zum eigentlichen Modul-Start) benötigen. Da auch diese "hängen" können und ggf. gekillt werden müssen, stehen zwei Felder je Job-Record als PID zur Verfügung (job_PID und job_SPID), wobei im Falle eingetragener Werte beide in Kill-Sequenzen abgearbeitet werden. Zum Killen von Prozessen unter Windows-Betriebssystemen ist das Programm kill.exe (Bestandteil z.B. des Windows-Resource-Kits; © Microsoft) oder ein Freeware-Pendant im Suchpfad erforderlich.

Als Parameter wird jedem Job der PK (jobs.job_idx) des vor Start neu generierten Job-Records übergeben. Darüber kann innerhalb der Module eindeutig auf alle Informationen der Datenbank zu diesem Job zugegriffen werden. Weiterhin stehen den Modulen innerhalb der mit dem Kernel gelieferten PIC-Include-Library (pic_lib.pl) Tool-Programme zur Verfügung (dbInit, dbDeInit, setPidJob, getTime, aliveJob, downJobDb usw.). Die Verwendung dieser kann in den Beispiel-Modulen (./modules/*_sample*.pl) sowie in den Köpfen der jeweiligen Tools verifiziert werden.

Prozess-Kernel aus Datenbank-Sicht