test

Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS

Kapitel 2 Entwickeln eines Datendienstes

Dieses Kapitel enthält detaillierte Informationen zum Entwickeln eines Datendienstes.

Dieses Kapitel behandelt die folgenden Themen:

Analysieren der Eignung einer Anwendung

Als erster Schritt beim Erstellen eines Datendienstes muss überprüft werden, ob die Zielanwendung alle Anforderungen für eine hohe Verfügbarkeit bzw. Skalierbarkeit erfüllt. Wenn die Anwendung nicht allen Anforderungen entspricht, können Sie möglicherweise deren Quellcode ändern, um die Anforderungen zu erfüllen.

Die folgende Liste fasst die Anforderungen für eine Anwendung, die hoch verfügbar oder skalierbar gemacht werden soll, zusammen. Weitere Einzelheiten und Hilfe beim Ändern des Anwendungsquellcodes finden Sie in Anhang B.

Hinweis –

Ein Scalable-Dienst muss alle folgenden Bedingungen für hohe Verfügbarkeit sowie einige zusätzliche Kriterien erfüllen.

Zudem müssen Scalable-Dienste die folgenden Anforderungen erfüllen:

Bei einem Scalable-Dienst legen die Anwendungseigenschaften auch das Lastausgleichsverfahren fest. Zum Beispiel funktioniert das Lastausgleichsverfahren LB_WEIGHTED, das jeder Instanz die Antwort auf Client-Anforderungen ermöglicht, nicht für eine Anwendung, die einen Cache-Speicher auf dem Server für Client-Verbindungen verwendet. In diesem Fall muss ein Lastausgleichsverfahren angegeben werden, das den Datenverkehr eines bestimmten Clients auf eine Instanz der Anwendung beschränkt. Die Lastausgleichsverfahren LB_STICKY und LB_STICKY_WILD senden wiederholt alle Anforderungen von einem Client an dieselbe Anwendungsinstanz — wo sie einen Cache-Speicher verwenden können. Beachten Sie, dass RGM mehrere Client-Anforderungen von unterschiedlichen Clients unter den Instanzen des Dienstes verteilt. Weitere Informationen zum Einstellen der Lastausgleichsverfahren für Scalable-Datendienste finden Sie unter Implementieren einer Failover-Ressource.

Festlegen der zu verwendenden Schnittstelle

Das Sun Cluster-Entwickler-Unterstützungspaket (SUNWscdev) stellt zwei Schnittstellen für das Codieren von Datendienstmethoden bereit:

Im Sun Cluster-Entwickler-Unterstützungspaket ist auch SunPlex Agent Builder enthalten, ein Tool, das die Erstellung eines Datendienstes automatisiert.

Folgende Vorgehensweise wird beim Entwickeln eines Datendienstes empfohlen:

  1. Entscheiden Sie, ob in C oder der Korn-Shell codiert werden soll. Wenn Sie sich für die Verwendung der Korn-Shell entscheiden, können Sie die DSDL nicht verwenden, da diese nur eine C-Schnittstelle enthält.

  2. Führen Sie Agent Builder aus, geben Sie die erforderlichen Angaben ein, und generieren Sie einen Datendienst mit Quell- und ausführbarem Code, einer RTR-Datei und einem Paket.

  3. Wenn der generierte Datendienst angepasst werden muss, können Sie den generierten Quelldateien DSDL-Code hinzufügen. Agent Builder gibt mithilfe von Kommentaren bestimmte Stellen in den Quelldateien an, an denen eigener Code eingefügt werden kann.

  4. Wenn der Code weiter angepasst werden muss, um die Zielanwendung zu unterstützen, können Sie dem vorhandenen Quellcode RMAPI-Funktionen hinzufügen.

In der Praxis gibt es viele unterschiedliche Möglichkeiten zum Erstellen eines Datendienstes. Statt an bestimmten Stellen des von Agent Builder generierten Codes eigenen Code einzufügen, können Sie zum Beispiel eine der generierten Methoden oder das generierte Überwachungsprogramm komplett durch ein Programm ersetzen, das Sie mit DSDL- oder RMAPI-Funktionen völlig neu schreiben. Unabhängig von der Vorgehensweise ist es jedoch fast immer sinnvoll, mit Agent Builder zu beginnen, und zwar aus folgenden Gründen:

Hinweis –

Im Unterschied zur RMAPI, die mehrere C-Funktionen und eine Reihe von Befehlen für die Verwendung in Skripts bereitstellt, verfügt die DSDL nur über eine C-Funktionsschnittstelle. Wenn Sie also in Agent Builder Korn-Shell (ksh)-Ausgabe festlegen, ruft der generierte Quellcode die RMAPI auf, weil keine DSDL-ksh-Befehle vorhanden sind.

Konfigurieren der Entwicklungsumgebung für das Schreiben eines Datendienstes

Bevor Sie mit der Datendienstentwicklung beginnen, müssen Sie das Sun Cluster-Entwicklungspaket (SUNWscdev) installieren, um Zugriff auf die Sun Cluster-Header- und Bibliotheksdateien zu haben. Obwohl dieses Paket bereits auf allen Cluster-Knoten installiert ist, erfolgt die Entwicklung in der Regel auf einem eigenen, nicht auf einem Cluster-Knoten vorhandenen Entwicklungsrechner. In diesem typischen Fall müssen Sie den Befehl pkgadd verwenden, um das SUNWscdev-Paket auf Ihrem Entwicklungsrechner zu installieren.

Beim Kompilieren und Verknüpfen des Codes müssen Sie besondere Optionen für die Identifizierung der Header- und Bibliotheksdateien einstellen. Nach Beenden der Entwicklung auf einem Nicht-Cluster-Knoten können Sie den fertigen Datendienst auf einen Cluster übertragen und dort ausführen und testen.

Hinweis –

Vergewissern Sie sich, dass Sie eine Entwicklungsversion von Solaris 5.8 oder höher verwenden.

Verwenden Sie die Verfahren in diesem Abschnitt zu folgenden Zwecken:

Konfigurieren der Entwicklungsumgebung

Dieses Verfahren beschreibt die Installation des SUNWscdev-Pakets und das Einstellen der Compiler- und Verknüpfer-Optionen für die Datendienstentwicklung.

  1. Melden Sie sich als Superbenutzer oder in einer äquivalenten Rolle an, und ändern Sie das Verzeichnis in das gewünschte CD-ROM-Verzeichnis. 


    # cd CD-ROM_Verzeichnis

  2. Installieren Sie das SUNWscdev-Paket im aktuellen Verzeichnis. 


    # pkgadd -d . SUNWscdev

  3. Geben Sie im Makefile die Compiler- und Verknüpfer-Optionen an, mit denen die Include- und Bibliotheksdateien für den Datendienstcode identifiziert werden.

    Geben Sie die Option -I zur Identifikation der Sun Cluster-Header-Dateien an, die Option -L zum Angeben des Kompilierungszeit-Bibliotheksuchpfads im Entwicklungssystem, und die Option -R zum Angeben des Bibliotheksuchpfads zum Laufzeitverknüpfer auf dem Cluster. 

    # Makefile für Beispieldatendienst

-I /usr/cluster/include

-L /usr/cluster/lib

-R /usr/cluster/lib
...

Übertragen eines Datendienstes auf einen Cluster

Nach Beendigung der Entwicklung eines Datendienstes auf dem Entwicklungsrechner müssen Sie den Datendienst auf einen Cluster übertragen, um ihn zu testen. Um die Fehlermöglichkeiten einzuschränken, erstellen Sie am besten ein Paket aus dem Datendienstcode und der RTR-Datei, und installieren Sie das Paket auf allen Knoten des Clusters.

Hinweis –

Unabhängig davon, ob Sie den Befehl pkgadd oder eine andere Methode zum Installieren des Datendienstes verwenden, müssen Sie den Datendienst auf allen Cluster-Knoten ablegen. Agent Builder erstellt automatisch ein Paket aus der RTR-Datei und dem Datendienstcode.

Einstellen der Ressourcen- und Ressourcentypeigenschaften

Sun Cluster stellt einen Satz Ressourcentypeigenschaften und Ressourceneigenschaften bereit, die zum Definieren der statischen Konfiguration eines Datendienstes verwendet werden. Ressourcentypeigenschaften geben den Typ der Ressource, deren Version, die API-Version, usw., sowie die Pfade zu jeder der Rückmeldemethoden an. Tabelle A–1 listet alle Ressourcentypeigenschaften auf.

Ressourceneigenschaften wie Failover_mode, Thorough_probe_interval und Methodenzeitüberschreitungen definieren ebenfalls die statische Konfiguration der Ressource. Dynamische Ressourceneigenschaften wie Resource_state und Status geben den Zustand einer verwalteten Ressource wieder. Tabelle A–2 beschreibt die Ressourceneigenschaften.

Der Ressourcentyp und die Ressourceneigenschaften werden in der Ressourcentyp-Registrierungsdatei (RTR-Datei) deklariert. Diese Datei ist eine grundlegende Komponente eines Datendienstes. Die RTR-Datei definiert die anfängliche Konfiguration des Datendienstes zu dem Zeitpunkt, zu dem der Cluster-Administrator den Datendienst bei Sun Cluster registriert.

Sie sollten Agent Builder zum Generieren der RTR-Datei für Ihren Datendienst verwenden, da Agent Builder den Satz Eigenschaften deklariert, der für jeden Datendienst nützlich und erforderlich ist. Es müssen zum Beispiel bestimmte Eigenschaften wie Resource_type in der RTR-Datei deklariert werden; andernfalls schlägt die Registrierung des Datendienstes fehl. Andere Eigenschaften sind zwar nicht erforderlich, stehen aber dem Systemadministrator nur dann zur Verfügung, wenn Sie sie in der RTR-Datei deklarieren. Einige Eigenschaften sind immer verfügbar, unabhängig davon, ob Sie sie deklarieren oder nicht, da sie von RGM definiert und mit einem Standardwert versehen werden. Um diese komplexen Fragen zu umgehen, können Sie einfach Agent Builder einsetzen, um die Generierung einer geeigneten RTR-Datei sicherzustellen. Später können Sie die RTR-Datei bearbeiten und bei Bedarf bestimmte Werte ändern.

Im letzten Teil dieses Abschnitts werden Sie durch eine von Agent Builder erstellte Beispiel-RTR-Datei geführt.

Deklarieren von Ressourcentypeigenschaften

Der Cluster-Administrator kann die von Ihnen in der RTR-Datei deklarierten Ressourcentypeigenschaften nicht konfigurieren. Sie werden Bestandteil der permanenten Ressourcentypkonfiguration.

Hinweis –

Eine Ressourcentypeigenschaft, Installed_nodes, kann vom Systemadministrator konfiguriert werden. Sie kann sogar nur von einem Systemadministrator konfiguriert und nicht in der RTR-Datei deklariert werden.

Die Syntax für Ressourcentypdeklarationen lautet: 


Eigenschaftsname = Wert;
Hinweis –

RGM unterscheidet bei Eigenschaftsnamen nicht zwischen Groß- und Kleinschreibung. Die Konvention für Eigenschaften in von Sun gelieferten RTR-Dateien, mit Ausnahme der Methodennamen, ist Großschreibung des ersten Buchstabens und Kleinschreibung der restlichen Buchstaben des Namens. Methodennamen werden — ebenso wie Eigenschaftsattribute — ganz in Großbuchstaben geschrieben.

Es folgen die Ressourcentypdeklarationen in der RTR-Datei für einen Beispieldatendienst (smpl): 

# Sun Cluster-Datendienst-Builder Vorlagenversion 1.0
# Registrierungsinformationen und Ressourcen für smpl
#
#HINWEIS: Schlüsselwörter unterscheiden Groß- und Kleinschreibung nicht;
#Sie können also nach Belieben groß oder klein schreiben.
#
Resource_type = "smpl";
Vendor_id = SUNW;
RT_description = "Beispieldienst auf Sun Cluster";

RT_version ="1.0";
API_version = 2;
Failover = TRUE;

Init_nodes = RG_PRIMARIES;

RT_basedir=/opt/SUNWsmpl/bin;

Start           =    smpl_svc_start;
Stop            =    smpl_svc_stop;

Validate        =    smpl_validate;
Update          =    smpl_update;

Monitor_start   =    smpl_monitor_start;
Monitor_stop    =    smpl_monitor_stop;
Monitor_check   =    smpl_monitor_check;
Tipp –

Als ersten Eintrag in der RTR-Datei müssen Sie die Resource_type-Eigenschaft deklarieren. Andernfalls schlägt die Registrierung des Ressourcentyps fehl.

Der erste Satz Ressourcentypdeklarationen liefert grundlegende Informationen über den Ressourcentyp, wie folgt:

Resource_type und Vendor_id

Geben dem Ressourcentyp einen Namen. Sie können den Ressourcentypnamen entweder durch die Resource_type-Eigenschaft alleine angeben (smpl) oder Vendor_id als Präfix mit “.” zur Abtrennung vom Ressourcentyp verwenden (SUNW.smpl), wie im Beispiel gezeigt. Wenn Sie Vendor_id verwenden, nehmen Sie das Börsensymbol für das Unternehmen, das den Ressourcentyp definiert. Der Ressourcentypname muss im Cluster einmalig sein.

Hinweis –

Als Konvention wird der Ressourcentypname (Resource_typeVendor_id) als Paketname verwendet. Paketnamen sind auf neun Zeichen beschränkt, so dass Sie die Gesamtzahl der Zeichen in diesen beiden Eigenschaften auf neun oder weniger Zeichen beschränken sollten, auch wenn RGM diese Beschränkung nicht erzwingt. Agent Builder generiert jedoch den Paketnamen explizit anhand des Ressourcentypnamens, so dass er die Beschränkung auf neun Zeichen erzwingt.

Rt_version

Identifiziert die Version des Beispieldatendienstes.

API_version

Identifiziert die API-Version. So gibt API_version = 2 zum Beispiel an, dass der Datendienst unter Sun Cluster, Version 3.0, ausgeführt wird.

Failover = TRUE

Gibt an, dass der Datendienst nicht in einer Ressourcengruppe laufen kann, die auf mehreren Knoten gleichzeitig online sein kann. Damit wird also ein Failover-Datendienst angegeben. Weitere Informationen finden Sie unter Übertragen eines Datendienstes auf einen Cluster.

Start, Stop, Validate, usw.

Geben die Pfade zu den entsprechenden Rückmeldemethodenprogrammen an, die von RGM aufgerufen werden. Diese Pfade sind relativ zu dem Verzeichnis, das durch RT_basedir angegeben wird.

Die restlichen Ressourcentypdeklarationen geben folgende Konfigurationsinformationen an:

Init_nodes = RG_PRIMARIES

Gibt an, dass RGM die Methoden Init, Boot, Fini und Validate nur auf Knoten aufruft, die als Master des Datendienstes eingesetzt werden können. Die in RG_PRIMARIES angegebenen Knoten sind eine Untermenge aller Knoten, auf denen der Datendienst installiert ist. Setzen Sie den Wert auf RT_INSTALLED_NODES, um anzugeben, dass RGM diese Methoden auf allen Knoten aufruft, auf denen der Datendienst installiert ist.

RT_basedir

Zeigt auf /opt/SUNWsample/bin als Verzeichnispfad zu vollständigen relativen Pfaden, wie den Rückmeldemethodepfaden.

Start, Stop, Validate, usw.

Geben die Pfade zu den entsprechenden Rückmeldemethodenprogrammen an, die von RGM aufgerufen werden. Diese Pfade sind relativ zu dem Verzeichnis, das durch RT_basedir angegeben wird.

Deklarieren von Ressourceneigenschaften

Genau wie die Ressourcentypeigenschaften werden auch die Ressourceneigenschaften in der RTR-Datei deklariert. Als Konvention folgen die Ressourceneigenschaftsdeklarationen in der RTR-Datei auf die Ressourcentypdeklarationen. Die Syntax für Ressourcendeklarationen ist ein Satz von Attributwertepaaren, die zwischen geschweiften Klammern stehen:


{
    Attribut = Wert;
    Attribut = Wert;
             .
             .
             .
    Attribut = Wert;
}

Für von Sun Cluster bereitgestellte Ressourceneigenschaften (so genannte systemdefinierte Eigenschaften) können Sie bestimmte Attribute in der RTR-Datei ändern. So stellt Sun Cluster zum Beispiel Methoden-Zeitüberschreitungseigenschaften für jede Rückmeldemethode bereit und gibt Standardwerte an. In der RTR-Datei können Sie andere Standardwerte festlegen.

Sie können in der RTR-Datei auch neue Ressourceneigenschaften definieren, so genannte Erweiterungseigenschaften, indem Sie einen Satz der von Sun Cluster bereitgestellten Eigenschaftsattribute verwenden. Tabelle A–4 listet die Attribute für das Ändern und Definieren von Ressourceneigenschaften auf. Erweiterungseigenschaftsdeklarationen folgen in der RTR-Datei auf die Deklarationen der systemdefinierten Eigenschaften.

Der erste Satz systemdefinierter Ressourceneigenschaften gibt die Zeitüberschreitungswerte für die Rückmeldemethoden an: 

...

# Ressourceneigenschaftsdeklarationen folgen als Liste von
# Einträgen in Klammern auf die Ressourcentypdeklarationen.
# Die Eigenschaftsnamensdeklaration muss das erste Attribut
# nach der geöffneten geschweiften Klammer eines
# Ressourceneigenschaftseintrags sein.
#
# Mindest- und Standardwerte für Methoden-Zeitüberschreitungen einstellen.
{
        PROPERTY = Start_timeout;
        MIN=60;
        DEFAULT=300;
}

{
        PROPERTY = Stop_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Validate_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Update_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Start_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Stop_timeout;
        MIN=60;
        DEFAULT=300;
{
        PROPERTY = Monitor_Check_timeout;
        MIN=60;
        DEFAULT=300;
}

Der Name der Eigenschaft (PROPERTY = Wert) muss das erste Attribut in jeder Ressourceneigenschaftsdeklaration sein. Sie können Ressourceneigenschaften innerhalb der von den Eigenschaftsattributen definierten Grenzwerten in der RTR-Datei konfigurieren. So beträgt zum Beispiel der Standardwert für jede Methoden-Zeitüberschreitung im Beispiel 300 Sekunden. Der Verwalter kann diesen Wert ändern. Der im MIN-Attribut angegebene zulässige Mindestwert ist jedoch 60 Sekunden. In Tabelle A–4 erhalten Sie eine vollständige Liste der Ressourceneigenschaftsattribute.

Der nächste Satz Ressourceneigenschaften definiert Eigenschaften, die im Datendienst bestimmten Zwecken dienen. 

{
        PROPERTY = Failover_mode;
        DEFAULT=SOFT;
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Thorough_Probe_Interval;
        MIN=1;
        MAX=3600;
        DEFAULT=60;
        TUNABLE = ANYTIME;
}

# Die Anzahl der Wiederholungen, die innerhalb eines bestimmten Zeitraums
# auszuführen sind, bevor geschlossen wird, dass die Anwendung auf diesem
# Knoten nicht erfolgreich gestartet werden kann.
{
        PROPERTY = Retry_Count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME;
}

# Stellen Sie für Retry_Interval ein Vielfaches von 60 ein, da der Wert von
# Sekunden in Minuten konvertiert wird und aufrundet. So wird zum Beispiel ein Wert
# von 50 (Sekunden) in 1 Minute konvertiert. Verwenden Sie diese Eigenschaft,
# um die Zeit für die Anzahl Wiederholungen (Retry_Count) einzustellen.
{
        PROPERTY = Retry_Interval;
        MAX=3600;
        DEFAULT=300;
        TUNABLE = ANYTIME;
}

{
        PROPERTY = Network_resources_used;
        TUNABLE = WHEN_DISABLED;
        DEFAULT = "";
}
{
        PROPERTY = Scalable;
        DEFAULT = FALSE;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_policy;
        DEFAULT = LB_WEIGHTED;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_weights;
        DEFAULT = "";
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Port_list;
        TUNABLE = AT_CREATION;
        DEFAULT = ;
}

Diese Ressourceneigenschaftsdeklarationen fügen das TUNABLE-Attribut hinzu, das die Zeitpunkte einschränkt, zu denen der Systemadministrator die Werte ändern kann. AT_CREATION bedeutet, dass der Administrator den Wert nur bei Erstellung der Ressource angeben, ihn aber später nicht mehr ändern kann.

Für die meisten dieser Eigenschaften können Sie die von Agent Builder generierten Standardwerte akzeptieren, wenn kein besonderer Grund für eine Änderung vorliegt. Informationen zu diesen Eigenschaften finden Sie im Folgenden. Weiterführende Informationen sind unter Ressourceneigenschaften und der Online-Dokumentation unter r_properties(5) enthalten.

Failover_mode

Gibt an, ob RGM die Ressourcengruppe verschieben oder den Knoten abbrechen soll, wenn eine Start- oder Stop-Methode fehlschlägt.

Thorough_probe_interval, Retry_count, Retry_interval

Wird im Fehler-Monitor verwendet. Tunable entspricht Anytime, so dass ein Systemverwalter sie anpassen kann, wenn der Fehler-Monitor nicht optimal funktioniert.

Network_resources_used

Eine Liste der vom Datendienst verwendeten logischen Hostnamen bzw. gemeinsam genutzten Adressressourcen. Agent Builder deklariert diese Eigenschaft, so dass ein Systemverwalter beim Konfigurieren des Datendienstes eine Liste der Ressourcen (falls vorhanden) angeben kann.

Scalable

Wird auf FALSE eingestellt, um anzugeben, dass diese Ressource nicht die Cluster-Netzwerkfunktion (gemeinsam genutzte Adresse) verwendet. Diese Einstellung stimmt mit derjenigen der Failover-Ressourcentypeigenschaft überein, die auf TRUE eingestellt ist, um einen Failover-Dienst anzugeben. Weitere Informationen zur Verwendung dieser Eigenschaft finden Sie unter Übertragen eines Datendienstes auf einen Cluster und Implementieren von Rückmeldemethoden.

Load_balancing_policy, Load_balancing_weights

Erklärt diese Eigenschaften automatisch. Sie haben jedoch in einem Failover-Ressourcentyp keinen Verwendungszweck.

Port_list

Eine Liste mit Portnummern, die der Server abhört. Agent Builder deklariert diese Eigenschaft, so dass ein Systemverwalter beim Konfigurieren des Datendienstes eine Port-Liste angeben kann.

Deklarieren von Erweiterungseigenschaften

Am Ende der RTR-Beispieldatei befinden sich Erweiterungseigenschaften, wie in der folgenden Auflistung gezeigt. 

# Erweiterungseigenschaften
#

# Der Cluster-Verwalter muss den Wert dieser Eigenschaft so einstellen,
# dass sie auf das Verzeichnis mit den von der Anwendung verwendeten
# Konfigurationsdateien zeigt. Für diese Anwendung, smpl, wird der Pfad der
# Konfigurationsdatei auf PXFS (in der Regel named.conf) angegeben.
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "Pfad(e) zum Konfigurationsverzeichnis";
}

# Die folgenden beiden Eigenschaften steuern den Neustart des Fehler-Monitors.
{
        PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Anzahl der laut Fehler-Monitor zulässigen PMF-Neustarts.";
}
{
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Zeitfenster (Minuten) für Neustarts des Fehler-Monitors.";
}
# Zeitüberschreitungswert in Sekunden für das Testsignal.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Zeitüberschreitungswert für Testsignal (Sekunden)";
}

# Untergeordnete Überwachungsebene für PMF (Option -C von pmfadm).
# Der Standardwert -1 bedeutet, dass die Option -C von pmfadm nicht verwendet
# werden soll.
# Ein Wert von 0 oder höher gibt die gewünschte Ebene für die Überwachung des
# untergeordneten Prozesses an.
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “ Untergeordnete Überwachungsebene für PMF";
}
# Vom Benutzer hinzugefügter Code -- BEGIN VVVVVVVVVVVV
# Vom Benutzer hinzugefügter Code -- END   ^^^^^^^^^^^^

Agent Builder erstellt einige Erweiterungseigenschaften, die für die meisten Datendienste nützlich sind:

Confdir_list

Gibt den Pfad zum Anwendungskonfigurationsverzeichnis an. Diese Informationen sind für viele Anwendungen nützlich. Der Systemverwalter kann beim Konfigurieren des Datendienstes den Pfad zu diesem Verzeichnis bereitstellen.

Monitor_retry_count, Monitor_retry_interval, Probe_timeout

Steuert die Neustarts des Fehler-Monitors selbst, nicht diejenigen des Server-Dämons.

Child_mon_level

Stellt die Ebene der von PMF ausgeführten Überwachung ein. Weitere Informationen finden Sie unter pmfadm(1M).

Sie können in dem Bereich, der durch die Kommentare Vom Benutzer hinzugefügter Code eingegrenzt ist, weitere Erweiterungseigenschaften erstellen.

Implementieren von Rückmeldemethoden

Dieser Abschnitt enthält Informationen, die sich auf das Implementieren von Rückmeldemethoden allgemein beziehen.

Zugreifen auf Informationen über Ressourcen- und Ressourcengruppeneigenschaften

Im Allgemeinen benötigen Rückmeldemethoden Zugriff auf die Eigenschaften der Ressource. Die RMAPI stellt sowohl Shell-Befehle als auch C-Funktionen bereit, die Sie in Rückmeldemethoden für den Zugriff auf systemdefinierte und Erweiterungseigenschaften von Ressourcen verwenden können. Weitere Informationen finden Sie in der Online-Dokumentation unter scha_resource_get(1HA) und scha_resource_get(3HA)..

Die DSDL stellt zum Zugriff auf systemdefinierte Eigenschaften einen Satz C-Funktionen bereit (eine pro Eigenschaft) sowie eine Funktion zum Zugriff auf Erweiterungseigenschaften. Weitere Informationen finden Sie in der Online-Dokumentation unter scds_property_functions(3HA) und scds_get_ext_property(3HA).

Sie können den Eigenschaftsmechanismus nicht für das Speichern von dynamischen Zustandsinformationen für einen Datendienst verwenden, da keine API-Funktionen für das Einstellen von Ressourceneigenschaften vorhanden sind, mit Ausnahme derjenigen zum Einstellen von Status und Status_msg. Stattdessen müssen Sie dynamische Zustandsinformationen in globalen Dateien speichern.

Hinweis –

Der Cluster-Verwalter kann bestimmte Ressourceneigenschaften mithilfe des Befehls scrgadm oder über einen vorhandenen grafischen Verwaltungsbefehl bzw. eine vorhandene grafische Verwaltungs-Benutzeroberfläche einstellen. scrgadm darf jedoch nicht von einer Rückmeldemethode aus aufgerufen werden, da scrgadm während einer Cluster-Rekonfiguration fehlschlägt, also wenn RGM die Methode aufruft.

Idempotenz für Methoden

Im Allgemeinen ruft RGM keine Methode mehr als einmal nacheinander für die gleiche Ressource mit den gleichen Argumenten auf. Wenn jedoch eine Start-Methode fehlschlägt, könnte RGM eine Stop-Methode für eine Ressource aufrufen, obwohl diese Ressource gar nicht gestartet wurde. Ebenso könnte ein Ressourcen-Dämon von selbst ausfallen und RGM dennoch die Stop-Methode aufrufen. Die gleichen Möglichkeiten gelten für die Methoden Monitor_start und Monitor_stop.

Aus diesen Gründen müssen Sie Idempotenz in Ihre Stop- und Monitor_stop-Methoden einbauen. Wiederholte Aufrufe von Stop oder Monitor_stop für die gleiche Ressource mit den gleichen Parametern erzielen dann das gleiche Ergebnis wie ein einziger Aufruf.

Eine Auswirkung der Idempotenz ist, dass Stop und Monitor_stop 0 (Erfolg) zurückgeben müssen, auch wenn die Ressource bzw. der Monitor bereits gestoppt sind und keine Aufgabe ausgeführt wird.

Hinweis –

Die Methoden Init, Fini, Boot und Update müssen ebenfalls idempotent sein. Eine Start-Methode muss nicht idempotent sein.

Generischer Datendienst

Ein generischer Datendienst (Generic Data Service, GDS) ist ein Mechanismus, mit dem einfachen Anwendungen hohe Verfügbarkeit bzw. Skalierbarkeit verliehen wird, indem sie in das Framework des Ressourcengruppen-Managers von Sun Cluster eingefügt werden. Dieser Mechanismus erfordert keine Agentencodierung, wie dies sonst beim Einrichten von hoher Verfügbarkeit bzw. Skalierbarkeit üblich ist.

Das GDS-Modell beruht auf einem vorkompilierten Ressourcentyp, SUNW.gds, der die Zusammenarbeit mit dem RGM-Framework übernimmt.

Weitere Informationen hierzu finden Sie in Kapitel 10.

Steuern einer Anwendung

Mithilfe von Rückmeldemethoden kann RGM die Steuerung der zugrunde liegenden Ressource (Anwendung) übernehmen, sobald dem Cluster Knoten hinzugefügt bzw. daraus entfernt werden.

Starten und Stoppen einer Ressource

Für die Implementierung eines Ressourcentyps sind mindestens eine Start-Methode und eine Stop-Methode erforderlich. RGM ruft die Methodenprogramme eines Ressourcentyps zu geeigneten Zeiten und auf den entsprechenden Knoten auf, um Ressourcengruppen offline bzw. online zu bringen. Nach dem Absturz eines Cluster-Knotens verschiebt RGM zum Beispiel alle von diesem Knoten unterstützten Ressourcengruppen auf einen neuen Knoten. Es muss eine Start-Methode implementiert werden, damit RGM die Möglichkeit hat, jede Ressource auf dem noch laufenden Host-Knoten neu zu starten.

Eine Start-Methode darf nichts zurückgeben, bis die Ressource auf dem lokalen Knoten gestartet wurde und verfügbar ist. Vergewissern Sie sich, dass für Ressourcentypen, deren Initialisierung lange dauert, ausreichend lange Zeitüberschreitungswerte in den Start-Methoden eingestellt sind (stellen Sie die Standard- und Mindestwerte für die Start_timeout-Eigenschaft in der Ressourcentyp-Registrierungsdatei ein).

Eine Stop-Methode muss für Situationen implementiert werden, in denen RGM eine Ressourcengruppe offline nimmt. Angenommen, eine Ressource wird auf Knoten1 offline genommen und auf Knoten2 wieder online gebracht. Während die Ressourcengruppe offline genommen wird, ruft RGM die Stop-Methode für die Ressourcen in der Gruppe auf, um alle Aktivitäten auf Knoten1 zu stoppen. Nach Beenden der Stop-Methoden für alle Ressourcen auf Knoten1 bringt RGM die Ressourcengruppe auf Knoten2 wieder online.

Eine Stop-Methode darf nichts zurückgeben, bis die Ressource ihre Aktivität auf dem lokalen Knoten vollständig eingestellt hat und ganz heruntergefahren wurde. Die sicherste Implementierung einer Stop-Methode beendet alle Prozesse auf dem lokalen Knoten, die mit der Ressource in Beziehung stehen. Für Ressourcentypen, deren Herunterfahren lange dauert, müssen ausreichend lange Zeitüberschreitungswerte in den entsprechenden Stop-Methoden eingestellt werden. Stellen Sie die Stop_timeout-Eigenschaft in der Ressourcentyp-Registrierungsdatei ein.

Ein Fehlschlagen bzw. die Zeitüberschreitung einer Stop-Methode führt dazu, dass die Ressourcengruppe in einen Fehlerzustand gerät, der einen Bedienereingriff erforderlich macht. Um diesen Zustand zu vermeiden, müssen die Implementierungen der Stop- und Monitor_stop-Methoden eine Wiederherstellung unter allen möglichen Fehlerbedingungen versuchen. Idealerweise sollten diese Methoden mit dem Fehlerstatus 0 (Erfolg) beendet werden, nachdem jegliche Aktivität der Ressource und deren Monitor auf dem lokalen Knoten erfolgreich gestoppt wurde.

Bestimmen der zu verwendenden Start- und Stop-Methoden

Dieser Abschnitt enthält einige Tipps dazu, wann die Start- und Stop-Methoden bzw. die Prenet_start- und Postnet_stop-Methoden verwendet werden sollen. Voraussetzung zur Entscheidung für die richtigen Methoden sind sehr gute Kenntnisse sowohl des Clients als auch des Client/Server-Netzwerkprotokolls des Datendienstes.

Für Dienste, die Netzwerkadressressourcen verwenden, muss das Starten und Stoppen möglicherweise in einer bestimmten Reihenfolge stattfinden, die in Bezug zur logischen Hostname-Adresskonfiguration steht. Die optionalen Rückmeldemethoden Prenet_start und Postnet_stop ermöglichen es einer Ressourcentypimplementierung, besondere Aktionen beim Herauf- bzw. Herunterfahren auszuführen, bevor und nachdem Netzwerkadressen in derselben Ressourcengruppe als aktiv bzw. inaktiv konfiguriert werden.

Vor dem Aufruf der Prenet_start-Methode des Datendienstes ruft RGM Methoden zur Anmeldung der Netzwerkadressen auf (die sie aber nicht als aktiv konfigurieren). Nach dem Aufruf der Postnet_stop-Methoden des Datendienstes ruft RGM die Methoden auf, die Netzwerkadressen abmelden. RGM bringt eine Ressourcengruppe in dieser Reihenfolge online:

  1. Anmelden der Netzwerkadressen.

  2. Aufrufen der Prenet_start-Methode des Datendienstes (falls vorhanden).

  3. Aktiv-Konfigurieren der Netzwerkadressen.

  4. Aufrufen der Start-Methode des Datendienstes (falls vorhanden).

Wenn RGM eine Ressourcengruppe offline nimmt, wird in umgekehrter Reihenfolge verfahren:

  1. Aufrufen der Stop-Methode des Datendienstes (falls vorhanden).

  2. Inaktiv-Konfigurieren der Netzwerkadressen.

  3. Aufrufen der Postnet_stop-Methode des Datendienstes (falls vorhanden).

  4. Abmelden der Netzwerkadressen.

Bei der Entscheidung darüber, ob Start-, Stop-, Prenet_start- oder Postnet_stop-Methoden verwendet werden sollten, muss zunächst die Serverseite betrachtet werden. Beim Online-bringen einer Ressourcengruppe, die sowohl Datendienst-Anwendungsressourcen als auch Netzwerkadressressourcen enthält, ruft RGM Methoden auf, um die Netzwerkadressen als aktiv zu konfigurieren, bevor er die Start-Methoden der Datendienstressourcen aufruft. Wenn also für einen Datendienst Netzwerkadressen zum Startzeitpunkt als aktiv konfiguriert werden müssen, verwenden Sie die Start-Methode zum Starten des Datendienstes.

Ebenso ruft RGM beim Offline-nehmen einer Ressourcengruppe, die sowohl Datendienstressourcen als auch Netzwerkadressressourcen enthält, Methoden zum Inaktiv-Konfigurieren der Netzwerkadressen auf, nachdem die Stop-Methoden der Datendienstressource aufgerufen wurden. Wenn also für einen Datendienst zum Stoppzeitpunkt Netzwerkadressen als inaktiv konfiguriert werden müssen, verwenden Sie die Stop-Methode zum Stoppen des Datendienstes.

Wenn Sie zum Beispiel einen Datendienst starten oder stoppen möchten, müssen Sie möglicherweise die Verwaltungsdienstprogramme oder Bibliotheken des Datendienstes aufrufen. Manchmal verfügt der Datendienst über Verwaltungsdienstprogramme bzw. -bibliotheken, die eine Client/Server-Netzwerkschnittstelle für die Verwaltung verwenden. Dabei ruft ein Verwaltungsdienstprogramm den Server-Dämon auf, so dass möglicherweise die Netzwerkadresse aktiv sein muss, damit das Verwaltungsprogramm oder die Bibliothek verwendet werden können. Verwenden Sie unter diesen Umständen die Start- und Stop-Methoden.

Wenn beim Starten und Stoppen des Datendienstes die Netzwerkadressen als inaktiv konfiguriert sein müssen, verwenden Sie die Prenet_start- und Postnet_stop-Methoden zum Starten und Stoppen des Datendienstes. Überprüfen Sie, ob die Client-Software unterschiedlich antwortet, je nachdem, ob zuerst die Netzwerkadresse oder der Datendienst nach einer Cluster-Rekonfiguration online gebracht werden (entweder scha_control() mit dem Argument SCHA_GIVEOVER oder ein Switchover mit scswitch). Die Client-Implementierung führt möglicherweise nur sehr wenige Wiederholversuche aus und stellt diese bald ein, wenn sie feststellt, dass der Datendienst-Port nicht verfügbar ist.

Wenn der Datendienst nicht erfordert, dass die Netzwerkadresse beim Starten als aktiv konfiguriert ist, starten Sie ihn vor der Aktiv-Konfigurierung der Netzwerkschnittstelle. So wird sichergestellt, dass der Datendienst sofort auf Client-Anforderungen reagieren kann, sobald die Netzwerkadresse als aktiv konfiguriert ist. Somit ist es weniger wahrscheinlich, dass die Clients ihre Wiederholversuche einstellen. Unter diesen Umständen sollten Sie die Prenet_start-Methode anstelle der Start-Methode zum Starten des Datendienstes verwenden.

Wenn Sie die Postnet_stop-Methode verwenden, ist die Datendienstressource zu dem Zeitpunkt noch aktiv, an dem die Netzwerkadresse bereits als inaktiv konfiguriert wurde. Erst wenn die Netzwerkadresse als inaktiv konfiguriert wurde, wird die Postnet_stop-Methode aufgerufen. Daher wird das TCP bzw. der UDP-Dienst-Port oder dessen RPC-Programmnummer den Clients im Netzwerk immer als verfügbar angezeigt, außer wenn die Netzwerkadresse ebenfalls nicht antwortet.

Bei der Entscheidung darüber, ob die Start- und Stop-Methoden oder die Prenet_start- und Postnet_stop-Methoden bzw. beide zusammen verwendet werden sollten, müssen die Anforderungen und das Verhalten von Server und Client in Betracht gezogen werden.

Init-, Fini- und Boot-Methoden

Mithilfe von drei optionalen Methoden, Init, Fini und Boot, kann RGM Initialisierungs- und Beendigungscode für eine Ressource ausführen. RGM ruft die Init-Methode auf, um eine einmalige Initialisierung der Ressource auszuführen, wenn diese in einen verwalteten Zustand versetzt wird — entweder, weil die Ressourcengruppe aus einem nicht verwalteten in einen verwalteten Zustand versetzt wird, oder weil sie in einer bereits verwalteten Ressourcengruppe erstellt wird.

RGM ruft die Fini-Methode auf, um nach der Ressource zu bereinigen, wenn diese in einen unverwalteten Zustand versetzt wird — entweder, wenn die Ressourcengruppe in einen nicht verwalteten Zustand gebracht wird, oder wenn sie aus einer verwalteten Ressourcengruppe gelöscht wird. Die Bereinigung muss idempotent sein. Wenn also die Bereinigung bereits stattgefunden hat, muss Fini mit 0 (Erfolg) beendet werden.

RGM ruft die Boot-Methode auf Knoten auf, die dem Cluster neu beigetreten sind, die also gestartet bzw. neu gestartet wurden.

Die Boot-Methode führt in der Regel die gleiche Initialisierung wie Init aus. Diese Initialisierung muss idempotent sein. Wenn die Ressource also bereits auf dem lokalen Knoten initialisiert wurde, müssen Boot und Init mit 0 (Erfolg) beendet werden.

Überwachen einer Ressource

Üblicherweise werden Monitore so implementiert, dass sie in bestimmten Zeitabständen Fehlertestsignale an die Ressourcen senden, um festzustellen, ob die getesteten Ressourcen korrekt arbeiten. Wenn ein Fehlertestsignal einen Fehler ergibt, kann der Monitor versuchen, lokal neu zu starten oder ein Failover für die betroffene Ressourcengruppe durch Aufrufen der RMAPI-Funktion scha_control() bzw. der DSDL-Funktion scds_fm_action() anzufordern.

Sie können auch die Leistung einer Ressource überwachen und sie einstellen bzw. einen Leistungsbericht erstellen. Das Schreiben eines ressourcentypspezifischen Fehler-Monitors ist völlig optional. Selbst wenn Sie sich dafür entscheiden, keinen Fehler-Monitor zu schreiben, profitiert der Ressourcentyp von der Basisüberwachung des Clusters, die Sun Cluster selbst ausführt. Sun Cluster stellt Fehler der Host-Hardware, schwerwiegende Fehler des Host-Betriebssystems sowie Fehlschlagen der Host-Kommunikation auf den öffentlichen Netzwerken fest.

Obwohl RGM keinen Ressourcen-Monitor direkt aufruft, ermöglicht das Programm den automatischen Start von Monitoren für Ressourcen. Beim Offline-nehmen einer Ressource ruft RGM die Monitor_stop-Methode auf, um den Ressourcen-Monitor auf den lokalen Knoten zu stoppen, bevor die Ressource selbst gestoppt wird. Beim Online-bringen einer Ressource ruft RGM die Monitor_start-Methode auf, nachdem die Ressource selbst gestartet wurde.

Mithilfe der RMAPI-Funktion scha_control() und der DSDL-Funktion scds_fm_action() (die scha_control() aufruft) können die Ressourcen-Monitore das Failover einer Ressourcengruppe auf einen anderen Knoten anfordern. Als eine der Kontrollprüfungen ruft scha_control() den Befehl Monitor_check auf (falls definiert), um festzustellen, ob der angeforderte Knoten zuverlässig genug ist, um die Ressourcengruppe mit der Ressource zu unterstützen. Wenn Monitor_check zurückmeldet, dass der Knoten nicht zuverlässig ist, oder das Zeitlimit für die Methode überschritten wird, sucht RGM nach einem anderen Knoten, um der Failover-Anforderung nachzukommen. Wenn Monitor_check auf allen Knoten fehlschlägt, wird das Failover abgebrochen.

Der Ressourcen-Monitor kann die Status- und Status_msg-Eigenschaften einstellen, um die Monitorsicht des Ressourcenzustands wiederzugeben. Verwenden Sie die RMAPI-Funktion scha_resource_setstatus(), den Befehl scha_resource_setstatus oder die DSDL-Funktion scds_fm_action() zum Einstellen dieser Eigenschaften.

Hinweis –

Status und Status_msg eignen sich zwar besonders für einen Ressourcen-Monitor; diese Eigenschaften können jedoch von jedem beliebigen Programm eingestellt werden.

Ein Beispiel eines mit der RMAPI implementierten Fehler-Monitors finden Sie unter Definieren eines Fehler-Monitors. Ein Beispiel eines mit der DSDL implementierten Fehler-Monitors finden Sie unter SUNW.xfnts-Fehler-Monitor. Informationen zu Fehler-Monitoren, die in von Sun gelieferte Datendienste eingebaut sind, finden Sie im Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Hinzufügen von Meldungsprotokollierung zu einer Ressource

Wenn Sie Statusmeldungen in derselben Protokolldatei wie andere Cluster-Meldungen aufzeichnen möchten, verwenden Sie die erweiterte Funktion scha_cluster_getlogfacility(), um die Funktionsnummer abzurufen, die für das Protokollieren der Cluster-Meldungen verwendet wird.

Verwenden Sie diese Funktionsnummer mit der normalen Solaris-Funktion syslog(), um Meldungen in das Cluster-Protokoll zu schreiben. Sie können auch über die generische Schnittstelle scha_cluster_get() auf die Informationen zur Cluster-Protokollfunktion zugreifen.

Bereitstellen von Prozessverwaltung

Die RMAPI und die DSDL stellen Prozessverwaltungsfunktionen für die Implementierung von Ressourcen-Monitoren und Ressourcensteuerungs-Rückmeldungen bereit. Die RMAPI definiert die folgenden Funktionen. In der Online-Dokumentation finden Sie Details zu jedem dieser Befehle und Programme.

Process Monitor Facility:
pmfadm und rpc.pmfd

Die Prozessüberwachungsfunktion (Process Monitor Facility, PMF) ermöglicht das Überwachen von Prozessen und untergeordneten Prozessen sowie deren Neustart, wenn sie abgebrochen werden. Die Funktion besteht aus dem pmfadm-Befehl für das Starten und Steuern von überwachten Prozessen sowie dem rpc.pmfd-Dämon.

halockrun

Ein Programm für das Ausführen eines untergeordneten Programms mit Dateisperre. Dieser Befehl lässt sich gut in Shell-Skripts verwenden.

hatimerun

Ein Programm für das Ausführen eines untergeordneten Programms unter Zeitüberschreitungssteuerung. Dieser Befehl lässt sich gut in Shell-Skripts verwenden.

Die DSDL stellt die scds_hatimerun-Funktion für die Implementierung von hatimerun bereit.

Die DSDL stellt einen Funktionssatz (scds_pmf_*) für die Implementierung von PMF bereit. Einen Überblick über die Funktionen von DSDL-PMF und eine Auflistung der einzelnen Funktionen finden Sie unter PMF-Funktionen.

Verwaltungsunterstützung für eine Ressource

Zu den Verwaltungsaktionen bei Ressourcen gehört das Einstellen und Ändern von Ressourceneigenschaften. Die API definiert die Rückmeldemethoden Validate und Update, so dass Sie diese Verwaltungsaktionen nutzen können.

RGM ruft die optionale Validate-Methode auf, wenn eine Ressource erstellt wird und wenn eine Verwaltungsaktion die Eigenschaften der Ressource bzw. der Gruppe, zu der sie gehört, aktualisiert. RGM übergibt die Eigenschaftswerte für die Ressource und deren Ressourcengruppe an die Validate-Methode. RGM ruft Validate für den Satz von Cluster-Knoten auf, der von der Init_nodes-Eigenschaft des Ressourcentyps angegeben wird (Informationen zu Init_nodes finden Sie unter Ressourcentypeigenschaften bzw. in der Online-Dokumentation unter rt_properties(5). RGM ruft Validate auf, bevor die Erstellung bzw. Aktualisierung angewendet werden kann. Ein fehlerhafter Beendigungscode von der Methode oder einem der Knoten führt zu einem Fehlschlagen der Erstellung bzw. Aktualisierung.

RGM ruft Validate nur dann auf, wenn Ressourcen- bzw. Gruppeneigenschaften über eine Verwaltungsaktion geändert werden, und nicht, wenn RGM Eigenschaften einstellt oder wenn ein Monitor die Ressourceneigenschaften Status und Status_msg einstellt.

RGM ruft die optionale Update-Methode auf, um eine laufende Ressource darüber zu benachrichtigen, dass Eigenschaften geändert wurden. RGM ruft Update auf, nachdem eine Verwaltungsaktion die Eigenschaften einer Ressource bzw. deren Gruppe erfolgreich eingestellt hat. RGM ruft diese Methode auf denjenigen Knoten auf, auf denen die Ressource online ist. Die Methode kann die API-Zugriffsmethoden verwenden, um Eigenschaftswerte zu lesen, die eine aktive Ressource betreffen könnten, und um die laufende Ressource entsprechend anzupassen.

Implementieren einer Failover-Ressource

Eine Failover-Ressourcengruppe enthält Netzwerkadressen wie die eingebauten Ressourcentypen logischer Hostname und gemeinsam genutzte Adresse, sowie Failover-Ressourcen wie die Datendienst-Anwendungsressourcen für einen Failover-Datendienst. Die Netzwerkadressressourcen werden zusammen mit ihren abhängigen Datendienstressourcen zwischen Cluster-Knoten verschoben, wenn Datendienste ein Failover bzw. Switchover ausführen. RGM stellt eine Reihe von Eigenschaften zur Unterstützung der Implementierung einer Failover-Ressource bereit.

Die boolesche Ressourcentypeigenschaft Failover muss auf TRUE eingestellt werden, um zu verhindern, dass die Ressource in einer Ressourcengruppe konfiguriert wird, die auf mehr als einem Knoten gleichzeitig online sein kann. Diese Eigenschaft verwendet standardmäßig FALSE, so dass Sie sie für eine Failover-Ressource in der RTR-Datei als TRUE deklarieren müssen.

Die Ressourceneigenschaft Scalable legt fest, ob die Ressource die Cluster-Funktion gemeinsam genutzte Adresse verwendet. Bei einer Failover-Ressource muss Scalable auf FALSE eingestellt werden, weil eine Failover-Ressource keine gemeinsam genutzten Adressen verwendet.

Die Ressourcengruppeneigenschaft RG_mode ermöglicht es dem Cluster-Verwalter, eine Ressourcengruppe als Failover bzw. Scalable zu identifizieren. Wenn RG_mode auf FAILOVER eingestellt ist, setzt RGM die Maximum_primaries-Eigenschaft der Gruppe auf 1 und beschränkt die Ressourcengruppe, so dass sie nur von einem einzigen Knoten unterstützt wird. RGM lässt nicht zu, dass eine Ressource, deren Failover-Eigenschaft TRUE ist, in einer Ressourcengruppe erstellt wird, deren RG_mode auf SCALABLE eingestellt ist.

Die Ressourcengruppeneigenschaft Implicit_network_dependencies gibt an, dass RGM implizite starke Abhängigkeiten der Nicht-Netzwerkadressressourcen von allen Netzwerkadressressourcen (logischer Hostname und gemeinsam genutzte Adresse) innerhalb der Gruppe erzwingt. Das bedeutet, dass für die Nicht-Netzwerkadressressourcen (Datendienste) in der Gruppe keine Start-Methoden aufgerufen werden, bevor die Netzwerkadressen in der Gruppe als aktiv konfiguriert werden. Die Eigenschaft Implicit_network_dependencies wird standardmäßig auf TRUE eingestellt.

Implementieren einer Scalabe-Ressource

Eine Scalable-Ressource kann auf mehr als einem Knoten gleichzeitig online sein. Scalable-Ressourcen sind Datendienste wie Sun Cluster HA für Sun Java System Web Server (früher Sun Cluster HA für Sun ONE Web Server) und Sun Cluster HA für Apache.

RGM stellt mehrere Eigenschaften bereit, mit denen die Implementierung einer Scalable-Ressource unterstützt wird.

Die boolesche Ressourcentypeigenschaft Failover muss auf FALSE eingestellt werden, damit die Ressource in einer Ressourcengruppe konfiguriert werden kann, die auf mehr als einem Knoten gleichzeitig online sein kann.

Die Ressourceneigenschaft Scalable legt fest, ob die Ressource die Cluster-Funktion gemeinsam genutzte Adresse verwendet. Dieser Wert muss auf TRUE eingestellt werden, da ein Scalable-Dienst eine gemeinsam genutzte Adressressource verwendet, damit mehrere Instanzen des Scalable-Dienstes dem Client als ein einziger Dienst dargestellt werden.

Mithilfe der RG_mode-Eigenschaft kann der Cluster-Verwalter Ressourcengruppen als Failover oder Scalable identifizieren. Wenn RG_mode auf SCALABLE eingestellt ist, lässt RGM für Maximum_primaries einen Wert größer als 1 zu, was bedeutet, dass die Gruppe von mehreren Knoten gleichzeitig unterstützt werden kann. RGM lässt zu, dass eine Ressource, deren Failover-Eigenschaft FALSE ist, in einer Ressourcengruppe instanziiert wird, deren RG_mode auf SCALABLE eingestellt ist.

Der Cluster-Verwalter erstellt eine Scalable-Ressourcengruppe für Scalable-Dienstressourcen und eine eigene Failover-Ressourcengruppe für die Ressourcen mit gemeinsam genutzter Adresse, von der die Scalable-Ressource abhängt.

Der Cluster-Verwalter verwendet die Ressourcengruppeneigenschaft RG_dependencies zum Angeben der Reihenfolge, in der Ressourcengruppen auf einem Knoten online bzw. offline gebracht werden. Diese Reihenfolge ist für einen Scalable-Dienst wichtig, da sich die Scalable-Ressourcen und die gemeinsam genutzten Adressressourcen, von denen sie abhängen, in unterschiedlichen Ressourcengruppen befinden. Für einen Scalable-Datendienst müssen die Netzwerkadressressourcen (gemeinsam genutzte Adressen) als aktiv konfiguriert werden, bevor der Dienst gestartet wird. Daher muss der Verwalter die Eigenschaft RG_dependencies der Ressourcengruppe mit dem Scalable-Dienst so einstellen, dass sie die Ressourcengruppe mit den gemeinsam genutzten Adressressourcen enthält.

Wenn die Scalable-Eigenschaft in der RTR-Datei für eine Ressource deklariert wird, erstellt RGM automatisch den folgenden Satz Scalable-Eigenschaften für die Ressource:

Network_resources_used

Identifiziert die gemeinsam genutzten Adressressourcen, die von dieser Ressource verwendet werden. Diese Eigenschaft enthält standardmäßig eine leere Zeichenkette, so dass der Cluster-Verwalter beim Erstellen der Ressource die aktuelle Liste gemeinsam genutzter Adressen angeben muss, die der Scalable-Dienst verwendet. Der scsetup-Befehl und SunPlex-Manager stellen Funktionen bereit, mit denen die erforderlichen Ressourcen und Gruppen für Scalable-Dienste automatisch konfiguriert werden können.

Load_balancing_policy

Gibt das Lastausgleichsverfahren für die Ressource an. Sie können das Verfahren in der RTR-Datei explizit einrichten oder den Standardwert LB_WEIGHTED zulassen. In beiden Fällen kann der Cluster-Verwalter beim Erstellen der Ressource diesen Wert ändern, sofern nicht in der RTR-Datei Tunable für Load_balancing_policy auf NONE oder FALSE gesetzt wird. Zulässige Werte sind:

LB_WEIGHTED

Die Last wird auf mehrere Knoten verteilt, entsprechend den in der Eigenschaft Load_balancing_weights eingestellten Gewichtungen.

LB_STICKY

Ein bestimmter Client (identifiziert durch die Client-IP-Adresse) des Scalable-Dienstes wird immer an denselben Cluster-Knoten gesendet.

LB_STICKY_WILD

Ein bestimmter Client (identifiziert durch die Client-IP-Adresse), der eine Verbindung mit einer IP-Adresse eines Sticky-Dienstes mit Platzhalter herstellt, wird immer zu demselben Cluster-Knoten gesendet, unabhängig von der Port-Nummer, an die er gelangt.

Für einen Scalable-Dienst mit Load_balancing_policy, LB_STICKY oder LB_STICKY_WILD kann das Ändern von Load_balancing_weights, während der Dienst online ist, zu einem Zurücksetzen von vorhandenen Client-Affinitäten führen. In diesem Fall kann es vorkommen, dass ein anderer Knoten eine anschließende Client-Anforderung bedient, auch wenn der Client vorher von einem anderen Cluster-Knoten bedient wurde.

Auch wenn eine neue Instanz des Dienstes auf einem Cluster gestartet wird, können vorhandene Client-Affinitäten zurückgesetzt werden.

Load_balancing_weights

Gibt die Last an, die an jeden Knoten gesendet wird. Das Format ist Gewichtung@Knoten, Gewichtung@Knoten, wobei Gewichtung eine Ganzzahl ist, welche den relativen Anteil der Last für den angegebenen Knoten darstellt. Der an einen Knoten verteilte Lastanteil ist die Gewichtung dieses Knotens, geteilt durch die Summe aller Gewichtungen aktiver Instanzen. Zum Beispiel gibt 1@1,3@2 an, dass Knoten 1 1/4 der Last und Knoten 2 3/4 erhält.

Port_list

Identifiziert die Ports, die der Server abhört. Diese Eigenschaft enthält standardmäßig eine leere Zeichenkette. In der RTR-Datei können Sie eine Port-Liste bereitstellen. Andernfalls muss der Cluster-Verwalter die aktuelle Port-Liste bereitstellen, wenn er die Ressource erstellt.

Sie können einen Datendienst erstellen, den der Administrator dann als Scalable oder als Failover konfigurieren kann. Dafür werden sowohl die Ressourcentypeigenschaft Failover als auch die Ressourceneigenschaft Scalable in der RTR-Datei des Datendienstes als FALSE deklariert. Beim Erstellen muss die Scalable-Eigenschaft als “Tunable” angegeben werden.

Der Failover-Eigenschaftswert (FALSE) lässt zu, dass die Ressource in eine Scalable-Ressourcengruppe konfiguriert wird. Der Verwalter kann gemeinsam genutzte Adressen aktivieren, indem er den Wert beim Erstellen der Ressource von Scalable zu TRUE ändert und so einen Scalable-Dienst erstellt.

Andererseits kann der Verwalter auch dann die Ressource in eine Failover-Ressourcengruppe konfigurieren, um einen Failover-Dienst zu implementieren, wenn Failover auf FALSE eingestellt ist. Der Verwalter ändert den Wert von Scalable, der FALSE lautet, nicht. Zum Unterstützen dieser Möglichkeit sollte die Validate-Methode in der Scalable-Eigenschaft aktiviert werden. Wenn Scalable auf FALSE eingestellt ist, muss sichergestellt werden, dass die Ressource in eine Failover-Ressourcengruppe konfiguriert wurde.

Das Sun Cluster Concepts Guide for Solaris OS enthält weitere Informationen über Scalable-Ressourcen.

Validierungsprüfungen für Scalable-Dienste

Wenn eine Ressource erstellt oder aktualisiert wird und die Scalable-Eigenschaft auf TRUE eingestellt ist, validiert RGM verschiedene Ressourceneigenschaften. Wenn die Eigenschaften nicht richtig konfiguriert sind, weist RGM die versuchte Aktualisierung bzw. die Erstellung zurück. RGM führt folgende Prüfungen aus:

Schreiben und Testen von Datendiensten

Dieser Abschnitt enthält einige Informationen zum Schreiben und Testen von Datendiensten.

Verwenden von Keep-Alives

Auf der Serverseite schützt die Verwendung von TCP-Keep-Alives den Server vor der Verschwendung von Systemressourcen an einen heruntergefahrenen bzw. netzwerkpartitionierten Client. Wenn diese Ressourcen nicht bereinigt werden (auf einem Server, der lange genug aktiv bleibt), wachsen die verschwendeten Ressourcen schließlich unkontrolliert an, während die Clients abstürzen und neu starten.

Wenn die Client/Server-Kommunikation einen TCP-Strom verwendet, sollten sowohl der Client als auch der Server den TCP-Keep-Alive-Mechanismus aktivieren. Dies gilt auch für einzelne Nicht-HA-Server.

Andere verbindungsorientierte Protokolle können ebenfalls über einen Keep-Alive-Mechanismus verfügen.

Auf der Clientseite ermöglicht die Verwendung von TCP-Keep-Alives dem Client, eine Benachrichtigung zu erhalten, wenn eine Netzwerkressource ein Failover bzw. Switchover von einem realen Host zu einem anderen ausgeführt hat. Diese Übertragung der Netzwerkadressressource bricht die TCP-Verbindung ab. Wenn der Client allerdings das Keep-Alive nicht aktiviert hat, wird die Verbindungsunterbrechung möglicherweise nicht festgestellt, wenn die Verbindung zu diesem Zeitpunkt ruhte.

Angenommen, der Client wartet zum Beispiel auf die Antwort des Servers auf eine langfristige Anforderung, und die Anforderungsmeldung des Clients ist bereits beim Server angekommen und wurde auf TCP-Ebene bestätigt. In dieser Situation braucht das TCP-Modul des Clients die Anforderung nicht immer neu zu übertragen, und die Client-Anwendung ist blockiert, während sie die Antwort auf die Anforderung abwartet.

Womöglich sollte die Client-Anwendung zusätzlich zur Verwendung des TCP-Keep-Alive-Mechanismus ebenfalls in regelmäßigen Abständen ihr eigenes Keep-Alive ausführen, da der TCP-Mechanismus nicht in allen möglichen Grenzfällen perfekt funktioniert. Für die Verwendung eines Keep-Alive auf Anwendungsebene muss das Client/Server-Protokoll normalerweise einen Null-Vorgang unterstützen, oder zumindest einen effizienten schreibgeschützten Vorgang, wie einen Statusvorgang.

Testen von HA-Datendiensten

Dieser Abschnitt enthält Vorschläge zum Testen einer Datendienstimplementierung in der HA-Umgebung. Die Testfälle sind Beispiele und daher nicht umfassend. Sie benötigen Zugriff auf eine Testkonfiguration von Sun Cluster, damit sich das Testen nicht auf die Produktionsrechner auswirkt.

Testen Sie, ob sich der HA-Datendienst in allen Fällen richtig verhält, wenn eine Ressourcengruppe zwischen realen Hosts verschoben wird. Diese Fälle schließen Systemabstürze und die Verwendung des scswitch-Befehls mit ein. Testen Sie, ob die Client-Rechner nach diesen Ereignissen weiterhin Dienste erhalten.

Testen Sie die Idempotenz der Methoden. Ersetzen Sie zum Beispiel jede Methode vorübergehend mit einem kurzen Shell-Skript, das die Originalmethode zwei oder mehrere Male aufruft.

Koordinieren von Abhängigkeiten zwischen Ressourcen

Manchmal stellt ein Client/Server-Datendienst Anforderungen an einen anderen Client/Server-Datendienst, während er gleichzeitig einer Client-Anforderung nachkommt. Grob gesagt hängt ein Datendienst A von einem Datendienst B ab, wenn A seinen Dienst nur bereitstellen kann, sofern B seinen Dienst bereitstellt. Um dieser Anforderung zu entsprechen, lässt Sun Cluster die Konfiguration von Ressourcenabhängigkeiten innerhalb einer Ressourcengruppe zu. Die Abhängigkeiten wirken sich auf die Reihenfolge aus, in der Sun Cluster Datendienste startet und stoppt. Einzelheiten finden Sie in der Online-Dokumentation unter scrgadm(1M).

Wenn Ressourcen Ihres Ressourcentyps von Ressourcen eines anderen Typs abhängen, müssen Sie den Benutzer anweisen, die Ressourcen und Ressourcengruppen entsprechend zu konfigurieren bzw. Skripts oder Tools für die korrekte Konfiguration bereitstellen. Wenn die abhängige Ressource auf demselben Knoten wie diejenige Ressource, von der sie abhängt, läuft, müssen beide Ressourcen in derselben Ressourcengruppe konfiguriert werden.

Sie müssen entscheiden, ob Sie explizite Ressourcenabhängigkeiten verwenden möchten oder darauf verzichten und sich für die Verfügbarkeit von anderen Datendiensten im eigenen Code Ihres HA-Datendienstes entscheiden. Falls die abhängige Ressource und diejenige, von der sie abhängt, auf unterschiedlichen Knoten laufen können, werden sie in unterschiedlichen Ressourcengruppen konfiguriert. In diesem Fall ist ein Abruf erforderlich, da keine Ressourcenabhängigkeiten zwischen Gruppen konfiguriert werden können.

Einige Datendienste speichern keine Daten direkt, sondern hängen von einem anderen Backend-Datendienst für das Speichern aller Daten ab. Ein solcher Datendienst überträgt alle Lese- und Aktualisierungsanforderungen in Aufrufe an den Backend-Datendienst. Ein Beispiel wäre ein Client/Server-Terminkalenderdienst, der alle Daten in einer SQL-Datenbank wie Oracle aufbewahrt. Der Terminkalenderdienst verfügt über ein eigenes Client/Server-Netzwerkprotokoll. Es kann zum Beispiel ein Protokoll unter Verwendung einer RPC-Spezifikationssprache definiert haben, wie ONC RPC.

In der Sun Cluster-Umgebung können Sie HA-ORACLE verwenden, um die Backend-ORACLE-Datenbank hoch verfügbar zu machen. Dann können Sie einfache Methoden für das Starten und Stoppen des Terminkalenderdämons schreiben. Der Endbenutzer registriert den Terminkalender-Ressourcentyp bei Sun Cluster.

Wenn die Terminkalenderanwendung auf demselben Knoten wie die Oracle-Datenbank laufen muss, konfiguriert der Endbenutzer die Terminkalenderressource in derselben Ressourcengruppe wie die HA-ORACLE-Ressource und macht die Terminkalenderressource von der HA-ORACLE-Ressource abhängig. Diese Abhängigkeit wird über die Eigenschaftsmarkierung Resource_dependencies in scrgadm angegeben.

Wenn die HA-ORACLE-Ressource auf einem anderen Knoten als die Terminkalenderressource laufen kann, konfiguriert der Endbenutzer sie in zwei getrennten Ressourcengruppen. Der Endbenutzer kann eine Ressourcengruppenabhängigkeit der Terminkalendergruppe von der Oracle-Ressourcengruppe konfigurieren. Die Ressourcengruppenabhängigkeiten sind jedoch nur dann wirksam, wenn beide Ressourcengruppen gleichzeitig auf demselben Knoten gestartet bzw. gestoppt werden. Daher kann der Kalender-Datendienstdämon nach dem Starten das Warten auf die Verfügbarkeit der Oracle-Datenbank aufrufen. Die Start-Methode des Kalenderressourcentyps gibt in einem solchen Fall in der Regel einfach Erfolg zurück, da eine unbegrenzte Sperre der Start-Methode ihre Ressourcengruppe in einen belegten Zustand versetzen würde. Dann wären keine weiteren Zustandsänderungen der Gruppe wie zum Beispiel Bearbeitungen, Failover oder Switchover mehr möglich. Wenn jedoch die Zeit für die Start-Methode der Kalenderressource überschritten bzw. als Nicht-Null beendet wird, könnte es vorkommen, dass die Ressourcengruppe in eine Schleife zwischen zwei oder mehr Knoten gerät, während die Oracle-Datenbank nicht verfügbar bleibt.