-
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 SolarisTM 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 SolarisTM von Sun Microsystems, Inc., unterstützt ein
tmpfs genanntes speichergestütztes
Dateisystem. Das Dateisystem ufs in dem Betriebssystem SolarisTM 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 SolarisTM 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.