DE60023449T2

DE60023449T2 - Verfahren zur überwachung und zur steuerung von serveranwendungen durch verwendung von kostengünstigen, verborgenen kanälen

Info

Publication number: DE60023449T2
Application number: DE60023449T
Authority: DE
Inventors: Thomas Wong; Panagiotis Tsirigotis; Swee Lim; Sanjay Radia
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-01-29
Filing date: 2000-01-21
Publication date: 2006-07-13
Anticipated expiration: 2020-01-22
Also published as: WO2000045553A2; DE60023449D1; JP2002536734A; US6412001B1; EP1145496A3; EP1145496B1; WO2000045553A3; EP1145496A2; AU3348300A

Description

HINTERGRUND
Gebiet der Erfindung
Die Erfindung bezieht sich auf Netzdienstgruppen und insbesondere auf ein Verfahren und eine Vorrichtung zum Überwachen des Status von Diensten, die durch diese Gruppen ausgeführt werden.
Beschreibung des Standes der Technik
In einer Client-Server-Vernetzungsumgebung wird ein Netzdienst typisch durch eine Anwendung bereitgestellt, die auf einer Server-Maschine läuft, die Anforderungen verarbeitet, die von vielen Client-Maschinen über ein Netz gesendet werden. Die Bereitstellung einer skalierbaren und zuverlässigen Plattform für einen Netzdienst zur Verarbeitung eines zunehmenden Volumens von Client-Anforderungen ist eine primäre Herausforderung. Das US-Patent Nr. 5.938.732, eingereicht am 9. Dezember 1996, mit dem Titel "Load Balancing and Failovier of Network Services", am 17. August 1999 erteilt an Swee Boon Lim, Ashish Singhai und Sanjay Radia, beschreibt ein System, das eine skalierbare und zuverlässige Architektur besitzt, die eine Gruppe von Server-Maschinen verwendet, die jeweils die gleiche Anwendung ausführen, um gemeinsam einen Netzdienst bereitzustellen. Für eine Client-Maschine erscheint die im Folgenden als eine Dienstgruppe bezeichnete Gruppe von Server-Maschinen als eine einzelne Server-Maschine.
In diesen Anwendungen kann eine Server-Maschine mehrere Netzdienste bereitstellen und zu mehreren Dienstgruppen gehören. Jede Server-Maschine, die ein Mitglied einer Dienstgruppe ist, besitzt einen Dienstmonitor, der die Arbeitsbelastung überwacht und den Verfügbarkeitsstatus des Dienstes auf der Servermaschine bestimmt. Die Dienstmonitore von Mitgliedern einer Dienstgruppe kommunizieren miteinander über das Netz. Einer der Dienstmonitore wird als der Dienstgruppenleiter bestimmt und sammelt periodisch den Arbeitsbelastungs- und Verfügbarkeitsstatus jedes Mitglieds der Dienstgruppe. Der Dienstgruppenleiter verwendet die Informationen für den Belastungsausgleich und für die Wiederherstellung von Dienstabstürzen.
Es gibt drei Verfahren, die ein Dienstmonitor verwenden kann, um den Arbeitsbe lastungs- und Verfügbarkeitsstatus eines Dienstes zu erhalten. Diese sind das direkte Verfahren von Fernaufrufen (RPCs), das direkte Verfahren des Posting und das indirekte Verfahren der Verwendung von Betriebssystemdiensten. Gemäß dem ersten Verfahren, dem Fernaufrufverfahren (RPC-Verfahren), implementiert der Dienstmonitor die Client-Seite des RPC, während der durch den Dienstmonitor überwachte Dienst die Server-Seite des RPC implementiert. Der Dienstmonitor führt periodisch einen Fernaufruf zu dem Dienst aus, um Arbeitsbelastungsinformationen zu erhalten. Falls der Dienstmonitor keine RPC-Antwort von dem Dienst empfängt und ein Wiederholungsversuch nach einer bestimmten Zeitdauer fehlschlägt, kann der Dienstmonitor annehmen, dass der Dienst tot ist.
Obgleich der RPC-Zugang unkompliziert ist, sind die Programmierung von RPCs und das Festlegen des RPC-Clients und -Servers komplizierte und aufwändige Prozeduren, was andere Optionen wie etwa das Posting-Verfahren attraktiv macht. Gemäß dem Posting-Verfahren veröffentlicht ein Dienst seinen Arbeitsbelastungs- und Verfügbarkeitsstatus (z. B. zum momentanen Zeitpunkt) periodisch und getrennt unter Verwendung von Betriebssystemdiensten wie etwa gemeinsam genutztem Speicher oder einer IP-Mehrpunktverbindung oder -Punkt-zu-Mehrpunkt-Verbindung. Ein Dienstmonitor gewinnt die veröffentlichten Informationen aus dem Dienst, den er periodisch überwacht, möglicherweise in einem anderen Zeitraum wieder als dem, in dem die Veröffentlichung durch den Dienst stattgefunden hat, und bestimmt daraus den Status des Dienstes. Somit kann der Dienstmonitor erfassen, dass der Dienst, den er überwacht, nicht verfügbar ist, falls sich die durch den Dienst veröffentlichte Zeit, die die Dienstverfügbarkeit darstellt, nach einem bestimmten Zeitraum nicht ändert. Ein Nachteil des Posting-Verfahrens ist dagegen wieder die komplizierte Programmiertechnik, die zum Programmieren eines Dienstes und seines Dienstmonitors erforderlich ist.
Gemäß dem indirekten Verfahren der Verwendung von Betriebssystemdiensten kann ein Dienstmonitor Dienstprogramme nutzen, die durch das Betriebssystem bereitgestellt werden, und z. B. bestimmen, ob ein Rechenprozess vorhanden ist, oder die gesamte CPU-Nutzung (Zentraleinheitsnutzung) des Systems erhalten, ohne dass er direkt mit dem Dienst kommuniziert, den er überwacht. Dies ist besonders nützlich, da Dienstmonitore und Anwendungen, die auf einer Server-Maschine ausgeführt werden, typisch als Hintergrundrechenprozesse in einer Server-Maschine realisiert werden und sich somit für diese Wechselwirkung eignen. Ein Betriebssystem, das solche Hilfsmittel bereitstellt, ist Solaris^TM von Sun Micro systems, Inc.
Als ein Beispiel kann sich ein Dienstmonitor auf die CPU-Nutzung einer Server-Maschine als eine Darstellung der momentanen Arbeitsbelastung eines auf der Server-Maschine ausgeführten Dienstes stützen. Es kann eine direkte Beziehung zwischen der CPU-Nutzung eines Systems und der Arbeitsbelastung eines in dem System ausgeführten Dienstes geben. Falls die CPU-Nutzung einer Server-Maschine hoch ist, kann es z. B. nicht genug CPU-Zyklen geben, die für den Dienst in der Server-Maschine zur Verarbeitung von Client-Anforderungen verbleiben, was eine hohe Arbeitsbelastung angibt.
Ähnlich kann ein Dienstmonitor periodisch das Vorhandensein des Rechenprozesses prüfen, der den Dienst implementiert. Falls der Rechenprozess des Dienstes nicht vorhanden ist, ist der Dienst nicht verfügbar.
Das indirekte Verfahren ist effizient, da der Aufwand des Erhaltens des Arbeitsbelastungs- oder Verfügbarkeitsstatus lediglich der Aufwand der Verwendung der durch das Host-Betriebssystem bereitgestellten Systemaufrufe ist. Außerdem kann der Dienstmonitor die Arbeitsbelastungs- und Dienstvertügbarkeitsinformationen jederzeit erhalten, ohne darauf zu warten, dass der Dienst antwortet.
Ein Nachteil des indirekten Verfahrens ist, dass er keine Arbeitsbelastungsinformationen erhalten kann, die spezifisch für einen Dienst sind. Außerdem kann das indirekte Verfahren nicht wirklich sicher sein, dass ein Dienst verfügbar ist: Es kann nicht einen hängenden Rechenprozess, der keine Client-Anforderung verarbeiten kann, von einem normalen Rechenprozess unterscheiden, der Client-Anforderungen verarbeiten kann.
Somit ist es erwünscht, dass ein Dienstmonitor Arbeitsbelastungsinformationen und Verfügbarkeitsstatus direkt von dem Dienst erhält, den er überwacht, da ein solcher Zugang genauere Ergebnisse liefern würde. Da direkte Verfahren herkömmlich das Vornehmen von Änderungen an den Diensten derart umfassen, dass für die Dienste spezifische Arbeitsbelastungsinformationen an die Dienstmonitore kommuniziert werden könnten, ist es erwünscht, dass diese Informationen ohne Verwendung komplizierter Programmiertechniken wie etwa gemeinsam genutztem Speicher, Fernaufrufen oder Netzprogrammierung kommuniziert werden. Schließlich ist es erwünscht, den Aufwand zum Erhalten dieser Informationen zu verringern, um den Dienstdurchsatz zu maximieren.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung schafft ein Verfahren und eine Vorrichtung und ein computerlesbares Medium zum Überwachen und Steuern von Server-Anwendungen unter Verwendung von Umsetzungskanälen (oder verdeckten Kanälen) mit niedrigem Aufwand in Übereinstimmung mit den folgenden Ansprüchen. Sie überwindet durch Schaffung eines Umsetzungskanals, der die Kommunikation zwischen einem Dienstmonitor und einem Dienst, den er überwacht, ermöglicht, ohne eine übermäßige Überlastung für die Überwachung und Aktualisierung oder Übergabe von Nachrichten, die bestimmte Informationen angeben, zuzuziehen, die Nachteile des Standes der Technik. In einer Ausführungsform ist der Umsetzungskanal eine Kommunikationsdatei, deren Größe der Arbeitsbelastung des Dienstes entspricht, der überwacht wird, so dass der Dienstmonitor lediglich durch Untersuchung eines Größenattributs der Kommunikationsdatei die Arbeitsbelastung des Dienstes bestimmen kann. Veranschaulichend wird die Kommunikationsdatei ständig durch den Dienst aktualisiert, um für den Dienstmonitor einen "Herzschlag" zu liefern, der angibt, dass der Dienst verfügbar ist.
In einer weiteren Ausführungsform der Erfindung wird der "Herzschlag" durch eine zweite Kommunikationsdatei geliefert, die diesem Dienst zugeordnet ist. Eine getrennte Kommunikationsdatei ist besonders wünschenswert in Systemen, die keinen Zeitstempel oder kein Datum der letzten Änderung einer Datei liefern, wobei der Dienst in diesem Fall die Größe der zweiten Kommunikationsdatei regelmäßig oder ununterbrochen ändert, um anzugeben, dass der Dienst verfügbar ist.
Somit aktualisiert ein Dienst oder Prozess, der auf einem Server in einer Mehr-Server-Umgebung ausgeführt wird, periodisch Informationen über eine Kommunikationsdatei, die den Status und die Verfügbarkeit des Dienstes oder Prozesses angeben. Die Datei ist typisch eine "löchrige" Datei, d. h. eine Datei, die keinen Dateisystemspeicher belegt. Der ausgeführte Prozess aktualisiert die Größe der Datei, um z. B. die Arbeitsbelastung des ausgeführten Prozesses und das Datum der letzten Änderung anzugeben, um die Verfügbarkeit des ausgeführten Prozesses anzugeben. Irgendein anderer Prozess- und/oder Dienstmonitor, selbst jene in anderen Servern, brauchen lediglich die Dateiattribute zu untersuchen, um den Status und die Verfügbarkeit des ausgeführten Prozesses zu bestimmen. Somit wird zwischen dem ausgeführten Prozess und einem Überwachungsprozess ein Umsetzungskanal festgelegt, der den gesamten normalen Nachrichtenverarbeitungs-Zusatzaufwand beseitigt.
KURZBESCHREIBUNG DER ZEICHNUNG
Viele Vorteile der vorliegenden Erfindung werden für den Fachmann auf dem Gebiet beim Lesen dieser Beschreibung in Verbindung mit der beigefügten Zeichnung sichtbar, in der auf gleiche Element gleiche Bezugszeichen angewendet werden und in der:
1 ein schematisches Diagramm ist, das den Betrieb eines Umsetzungskanals zeigt;
2 ein schematisches Diagramm ist, das ein Dienstüberwachungssystem in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt; und
3 ein schematisches Diagramm ist, das ein Dienstüberwachungssystem in Übereinstimmung mit einer alternativen Ausführungsform der Erfindung zeigt.
AUSFÜHRLICHE BESCHREIBUNG
Ein Umsetzungskanal ist ein Kommunikationskanal, der ermöglicht, dass ein Rechenprozess unter Nutzung eines Mechanismus, dessen Verwendung für Kommunikationszwecke nicht beabsichtigt ist, Informationen überträgt. Wenn ein Rechenprozess den Zustand einer Charakteristik ändern kann, die ein weiterer Prozess abtasten kann, gibt es zwischen den zwei Prozessen einen Umsetzungskanal. Ein Umsetzungsspeicherkanal verwendet gemeinsam genutzte Systemvariablen als das Informationsübertragungsmittel.
1 veranschaulicht einen Umsetzungskanal C, der zwischen den als 30 bzw. 32 bezeichneten Prozessoren A und B festgelegt ist. Der Umsetzungskanal C entsteht über die Wechselwirkung des Prozesses A mit der Vorrichtung oder dem Prozess 34 und über die getrennte Wechselwirkung oder den getrennten Zugriff des Prozesses B auf diese gleiche Vorrichtung oder diesen gleichen Prozess. Irgendeine Manipulation der Vorrichtung oder des Prozesses 34 durch den Prozess A kann verwendet werden, um effektiv Informationen über den Prozess A an den Prozess B und, falls der Kanal doppelt gerichtet ist, umgekehrt zu kommunizieren. Für weitere Informationen über Umsetzungskanäle siehe "Information Security, an Integrated Collection of Essays", herausgegeben von Marshall D. Abrams, Sushil Jajodia, Harold J. Podell, IEEE Computer Society Press, 1995, S. 117. Eine Liste von Umsetzungskanalbeispielen ist in der Abhandlung "Multilevel Security with Fewer Fetters", M. D. Mcllory und J. A. Reeds, Proceeding UNIX Security Workshop (S. 24–31), zu finden.
Herkömmlich ist es die Aufgabe eines Umsetzungskanals, die Mehrebenensicherheit eines mehrebenensicherheitsfähigen Computersystems zu knacken. Ein Mehrebenen-Sicherheitssystem enthält Informationen mit verschiedenen Empfindlichkeiten und ermöglicht gleichzeitig den Zugriff durch Anwender mit verschiedenen Sicherheitsspielräumen und Wissensanforderungen, verhindert aber, dass Anwender Zugriff auf Informationen erhalten, für die sie keine Berechtigung haben. (Siehe "Information Security, an Integrated Collection of Essays" herausgegeben von Marshall D. Abrams, Sushil Jajodia, Harold J. Podell, IEEE Computer Society Press, 1995, S. 330–349.)
Die Kommunikationseffizienz eines Umsetzungskanals ist üblicherweise nicht von entscheidender Bedeutung, wobei jede Informationsübertragung zwischen den kooperierenden Prozessen über den Umsetzungskanal einen zusätzlichen Zusatzaufwand nach sich ziehen kann.
In Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung wird die Verwendung von universellen, aber komplizierten Zwischenprozesskommunikationsdiensten mit hohem Zusatzaufwand, die durch das Betriebssystem zur Veröffentlichung des Arbeitsbelastungs- und Verfügbarkeitsstatus eines Dienstes bereitgestellt werden, vermieden. Stattdessen wird auf einen oder zwei einfache Umsetzungskanäle aufgebaut, um Informationen hinsichtlich des Arbeitsbelastungs- und Verfügbarkeitsstatus eines Dienstes zu befördern. Genauer hat der in dieser Erfindung verwendete Umsetzungskanal die Größe einer vorgegebenen Datei. Falls ein System für den niedrigsten Kommunikationszusatzaufwand löchrige Dateien und ein speergestütztes Dateisystem unterstützt, hat der verwendete Umsetzungskanal die Größe einer löchrigen Datei in dem speichergestützten Dateisystem. Somit erfasst ein Dienstmonitor, der sich auf den Umsetzungskanal stützt, Informationen, die den Status eines Dienstes angeben, und verwendet diese Informationen, um u. a. andere Monitore über diesen Status zu unterrichten.
Die Datei, bei der ein Dienst und sein Dienstmonitor übereingekommen sind, dass sie als der Umsetzungskanal zu verwenden ist, wird im Folgenden als eine Kommunikationsdatei bezeichnet. Wie aus 2 zu sehen ist, die eine Ausführungsform der Erfindung veranschaulicht, ist einem Dienst 36 eine Kommunikationsdatei 38 zugeordnet. Die Arbeitsbelastung des Dienstes 36 ist als eine ganze Zahl X dargestellt, die dem Prozentsatz der vollen Kapazität entspricht, mit dem der Dienst 36 genutzt wird. Der Dienst 36 veröffentlicht seine Arbeitsbelastung periodisch, indem er die Größe der Kommunikationsdatei 38 so einstellt, dass sie der Arbeitsbelastungszahl X entspricht. Der Dienstmonitor 40 des Dienstes 38 liest periodisch und unabhängig die Größe der Kommunikationsdatei 38, um die Arbeitsbelastungszahl X zu erhalten.
Außerdem kann die Kommunikationsdatei 38 verwendet werden, um den Verfügbarkeitsstatus des Dienstes 36 anzugeben, falls das (nicht gezeigte) Betriebssystem der Server-Maschine ein Dienstprogramm bereitstellt, um das letzte Änderungsdatum einer Datei zu erhalten. Veranschaulichend ändert sich das letzte Änderungsdatum einer Datei, falls sich der Inhalt oder ein Attribut der Datei ändert. In einem solchen System aktualisiert der Dienst 36 die Arbeitsbelastungszahl ununterbrochen oder regelmäßig selbst dann, wenn sich die Arbeitsbelastungszahl nicht ändert, was ermöglicht, dass sich sein Dienstmonitor 40 auf das Datum der letzten Änderung der Kommunikationsdatei 38 stützt, um den Verfügbarkeitsstatus des Dienstes 36 zu folgern. Falls sich das letzte Änderungsdatum nach einer bestimmten Zeitdauer nicht ändert, kann der Dienstmonitor 40 annehmen, dass der Dienst 36, den er überwacht, nicht verfügbar ist.
Alternativ können ein Dienst und ein Dienstmonitor eine weitere, getrennte Kommunikationsdatei bestimmen, die spezifisch für das Kommunizieren des Dienstverfügbarkeitsstatus ist. Diese Ausführungsform der Erfindung ist in 3 veranschaulicht, wobei der Dienst 42 durch den Dienstmonitor 44 über die Kommunikationsdateien 46 und 48 überwacht wird. Die Kommunikationsdatei 46 arbeitet wie oben, wobei sie Informationen über den Prozentsatz der Nutzung des Dienstes 42 liefert. Die Kommunikationsdatei 48 ist für das Liefern von Informationen über den Verfügbarkeitsstatus des Dienstes 42 vorgesehen. Dieses wird durch regelmäßiges Ändern der Größe der Kommunikationsdatei 48 ausgeführt. In einer Implementierung dieser Ausführungsform inkrementiert der Dienst 42 die Größe der Kommunikationsdatei 48 periodisch um eins, wodurch er das Äquivalent eines "Herzschlags" liefert, der angibt, dass der Dienst 42"lebendig" oder verfügbar ist. Falls die Größe der Kommunikationsdatei 48, wie durch den Dienstmonitor 44 überwacht wird, nach einem bestimmten Zeitraum nicht zunimmt, kann der Dienstmonitor annehmen, dass der Dienst 42 nicht verfügbar ist.
In den meisten Betriebssystemumgebungen kann das Aktualisieren der Größe einer Kommunikationsdatei das Zuordnen von Plattenspeicher für die Datei erfordern und jedes Mal, wenn die Dateigröße geändert wird, eine Platten-E/A-Operation (Platten-Eingabe/Ausgabe-Operation) nach sich ziehen. Allerdings kann dieser Aufwand für bestimmte Systeme, die ein speichergestütztes Dateisystem und löchrige Dateien unterstützen, beseitigt werden. Veranschaulichend ist ein Loch ein Gebiet in einer Datei, das keinen Speicherraum belegt und so behandelt wird, wie wenn alle in dem Gebiet gespeicherten Daten Bytes mit einem Wert null wären. Eine löchrige Datei ist eine Datei, die wenigstens ein Loch enthält.
Ein speichergestütztes Dateisystem ist ein Dateisystem, das Schreib-Lese-Speicher (RAM) zum Speichern des Inhalts von Datendateien und der Speicherhierarchie des Dateisystems verwendet. Da das Zugreifen auf Dateien in einem speichergestützten Dateisystem die gleiche Geschwindigkeit wie das Zugreifen auf den RAM hat, ist ein Vorteil eines speichergestützten Dateisystems die Geschwindigkeit. Ein Nachteil eines speichergestützten Dateisystems ist, dass der Inhalt einer Datei eines speichergestützten Dateisystems nicht über einen Systemneustart bestehen bleibt. Das Betriebssystem Solaris^TM von Sun Microsystems, Inc., unterstützt ein tmpfs genanntes speichergestütztes Dateisystem. Das Dateisystem ufs in dem Betriebssystem Solaris^TM unterstützt löchrige Dateien.
Falls in einem speichergestützten Dateisystem durch den Dienst 36 und seinen Dienstmonitor 40 eine löchrige Datei als die Kommunikationsdatei 38 bestimmt wird, zieht die Aktualisierung der Größe der Kommunikationsdatei 38 keine aufwändige Platten-E/A-Operation (Platten-Eingabe/Ausgabe-Operation) nach sich. Darüber hinaus ist keine RAM-Zuweisung für die Datei 38 erforderlich, falls die Kommunikationsdatei 38 keine Daten enthält (d. h. falls eine löchrige Datei nur ein Loch ist). Somit besitzt das Zugreifen auf die Kommunikationsdatei 38 die gleiche Geschwindigkeit wie das Zugreifen auf den RAM, wobei der Aufwand des Einstellens oder Wiedergewinnens der Größe der löchrigen Kommunikationsdatei 38 in einem speichergestützten Dateisystem etwa der gleiche Aufwand wie ein einfacher Systemaufruf ist.
Die Nutzung von Dateisystemdiensten in Form eines Umsetzungskanals in Übereinstimmung mit der Erfindung ist viel einfacher als das Schreiben von RPC- oder Netzprogrammen. Darüber hinaus hat für Systeme wie etwa das Betriebssystem Solaris^TM von Sun Microsystems, Inc., die speichergestützte Dateisysteme und löchrige Dateien unterstützen, die Verwendung eines wie oben beschriebenen Umsetzungskanals zur Kommunikation von Arbeitsbelastungsinformationen und der Dienstverfügbarkeit einen sehr niedrigen Kommunikationszusatzaufwand und ist äußerst effizient. Allerdings wird angemerkt, dass als ein Umsetzungskanal zum Veröffentlichen der Arbeitsbelastung und der Verfügbarkeit eines Dienstes wie etwa des Dienstes 36 auch andere Dateiattribute verwendet werden können. Allerdings ist unter den verfügbaren Dateiattributen, die als ein Umsetzungskanal verwendet werden können, die Dateigröße die am einfachsten zu verwendende.
Die obigen sind beispielhafte Ausführungsarten der Erfindung und sollen nicht beschränkend sein. Für den Fachmann auf dem Gebiet ist offensichtlich, dass daran Änderungen vorgenommen werden können, ohne von dem wie in den folgenden Ansprüchen dargelegten Umfang der Erfindung abzuweichen.

Claims

Verfahren zum Veröffentlichen oder Kommunizieren des Arbeitsbelastungsstatus eines Dienstes (36, 42), der eine veränderliche Arbeitsbelastung hat und in einem Computersystem, das einen oder mehrere Computer besitzt, ausgeführt wird, gekennzeichnet durch die folgenden Schritte: Bestimmen der Arbeitsbelastung des Dienstes zu einem bestimmten Zeitpunkt; und Unterhalten einer ersten Kommunikationsdatei (38, 46) mit einer Größe, die zu der bestimmten Arbeitsbelastung proportional ist, derart, dass der Arbeitsbelastungsstatus des Dienstes durch den Dienst dadurch veröffentlicht werden kann, dass die Größe der Datei so gesetzt wird, dass sie der Arbeitsbelastung entspricht, oder durch den Dienst (36, 42) an einen Dienstmonitor (40, 44) kommuniziert werden kann, indem die Datei als ein Umsetzungskanal verwendet wird, wodurch ein hoher System-Zwischenprozesskommunikations-Zusatzaufwand vermieden wird.
Verfahren nach Anspruch 1, das ferner das Veröffentlichen der Verfügbarkeit des Dienstes (36, 42) durch periodisches Aktualisieren der Größe der ersten Kommunikationsdatei (38, 46) umfasst.
Verfahren nach Anspruch 2, bei dem der Schritt des periodischen Aktualisierens das periodische Neubestimmen der Arbeitsbelastung des Dienstes (36, 42) und das erneute Festlegen der Größe der ersten Kommunikationsdatei (38, 46) in Übereinstimmung mit der Neubestimmung umfasst.
Verfahren nach Anspruch 1, das ferner die folgenden Schritte umfasst: Unterhalten einer zweiten Kommunikationsdatei (48), die der Bereitstellung von Informationen bezüglich des Verfügbarkeitsstatus des Dienstes (42) gewidmet ist; und periodisches Ändern der Größe der zweiten Kommunikationsdatei, um dadurch anzugeben, dass der Dienst (42) aktiv ist.
Verfahren nach einem der Ansprüche 1 bis 4, bei dem die Schritte des Bestimmens und Unterhaltens durch den Dienst (36, 42) ausgeführt werden.
Verfahren nach einem der Ansprüche 1 bis 5, bei dem der Arbeitsbelastungs- und/oder der Verfügbarkeitsstatus an einen oder mehrere Dienstmonitore einer Dienstgruppe, die einen oder mehrere Computer besitzt, kommuniziert wird.
Verfahren nach Anspruch 6, bei dem die Statusinformationen durch einen ersten Dienstmonitor erfasst werden, der ferner den Schritt des Unterrichtens wenigstens eines zweiten Dienstmonitors über den Status des Dienstes ausführt.
Computerlesbares Medium, das ein Programm enthält, das den Arbeitsbelastungsstatus eines Dienstes (36, 42), der eine veränderliche Arbeitsbelastung hat und in einem Computersystem mit einem oder mehreren Computern ausgeführt wird, veröffentlicht oder kommuniziert, wobei das Programm eine Prozedur ausführt, die gekennzeichnet ist durch die folgenden Schritte: Bestimmen der Arbeitsbelastung des Dienstes zu einem bestimmten Zeitpunkt; und Unterhalten einer ersten Kommunikationsdatei (38, 46) mit einer Größe, die zu der bestimmten Arbeitsbelastung proportional ist, derart, dass der Arbeitsbelastungsstatus des Dienstes durch den Dienst dadurch veröffentlicht werden kann, dass die Größe der Datei so gesetzt wird, dass sie der Arbeitsbelastung entspricht, oder durch den Dienst (36, 42) an einen Dienstmonitor (40, 44) kommuniziert wird, indem die Datei als ein Umsetzungskanal verwendet wird, um dadurch einen hohen System-Zwischenprozesskommunikations-Zusatzaufwand zu vermeiden.
Computerlesbares Medium nach Anspruch 8, bei dem die Prozedur ferner den Schritt des Veröftentlichens der Verfügbarkeit des Dienstes (36, 42) durch periodisches Aktualisieren der Größe der ersten Kommunikationsdatei (38, 46) umfasst.
Computerlesbares Medium nach Anspruch 9, bei dem der Schritt des periodischen Aktualisierens das periodische Neubestimmen der Arbeitsbelastung des Dienstes (36, 42) und das erneute Festlegen der Größe der ersten Kommunikationsdatei (38, 46) in Übereinstimmung mit der Neubestimmung umfasst.
Computerlesbares Medium nach Anspruch 8, bei dem die Prozedur ferner die folgenden Schritte umfasst: Unterhalten einer zweiten Kommunikationsdatei (48), die der Bereitstellung von Informationen bezüglich des Verfügbarkeitsstatus des Dienstes (42) gewidmet ist; und periodisches Ändern der Größe der zweiten Kommunikationsdatei, um dadurch anzugeben, dass der Dienst (42) aktiv ist.
Computerlesbares Medium nach einem der Ansprüche 8 bis 11, bei dem die Schritte des Bestimmens und Unterhaltens durch den Dienst (36, 42) ausgeführt werden.
Computerlesbares Medium nach einem der Ansprüche 8 bis 12, bei dem der Arbeitsbelastungs- und/oder Verfügbarkeitsstatus an einen oder mehrere Dienstmonitore einer Dienstgruppe, die einen oder mehrere Computer besitzt, kommuniziert wird.
Computerlesbares Medium nach Anspruch 13, bei dem die Statusinformationen durch einen ersten Dienstmonitor erfasst werden, der ferner den Schritt des Unterrichtens wenigstens eines zweiten Dienstmonitors über den Status des Dienstes ausführt.
Vorrichtung zum Veröffentlichen oder Kommunizieren des Arbeitsbelastungsstatus eines Dienstes (36, 42), der eine veränderliche Arbeitsbelastung besitzt und in einem Computersystem mit einem oder mehreren Computern ausgeführt wird, gekennzeichnet durch eine Einrichtung zum Bestimmen der Arbeitsbelastung des Dienstes zu einem bestimmten Zeitpunkt; und eine Einrichtung zum Unterhalten einer ersten Kommunikationsdatei (38, 46) mit einer Größe, die zu der bestimmten Arbeitsbelastung proportional ist, derart, dass der Arbeitsbelastungsstatus des Dienstes durch den Dienst dadurch veröffentlicht werden kann, dass die Größe der Datei so gesetzt wird, dass sie der Arbeitsbelastung entspricht, oder durch den Dienst (36, 42) an einen Dienstmonitor (40, 44) kommuniziert wird, indem die Datei als ein Umsetzungskanal verwendet wird, um dadurch einen hohen System-Zwischenprozesskommunikations-Zusatzaufwand zu vermeiden.
Vorrichtung nach Anspruch 15, die ferner eine Einrichtung zum Veröffentlichen der Verfügbarkeit des Dienstes (36, 42) durch periodisches Aktualisieren der Größe der ersten Kommunikationsdatei (38, 40) umfasst.
Vorrichtung nach Anspruch 16, bei der die Veröffentlichungseinrichtung eine Einrichtung zum periodischen Neubestimmen der Arbeitsbelastung des Dienstes (36, 42) und zum erneuten Festlegen der Größe der ersten Kommunikationsdatei (38, 46) in Übereinstimmung mit der Neubestimmung umfasst.
Vorrichtung nach Anspruch 15, die ferner eine Einrichtung umfasst, um eine zweite Kommunikationsdatei (48) zu unterhalten, die der Bereitstellung von Informationen bezüglich des Verfügbarkeitsstatus des Dienstes (42) gewidmet ist; und um die Größe der zweiten Kommunikationsdatei periodisch zu ändern, um dadurch anzugeben, dass der Dienst (42) aktiv ist.
Vorrichtung nach einem der Ansprüche 15 bis 18, bei der die Einrichtung zum Bestimmen und Unterhalten durch den Dienst (36, 42) bereitgestellt wird.
Vorrichtung nach einem der Ansprüche 15 bis 19, bei der der Arbeitsbelastungs- und/oder der Verfügbarkeitsstatus an einen oder mehrere Dienstmonitore einer Dienstgruppe, die einen oder mehrere Computer besitzt, kommuniziert wird.
Vorrichtung nach Anspruch 20, bei der die Statusinformationen durch einen ersten Dienstmonitor erfasst werden, der ferner wenigstens einen zweiten Dienstmonitor über den Status des Dienstes unterrichtet.