test

Sun Cluster Entwicklerhandbuch Datendienste für Solaris OS

Kapitel 2 Entwickeln eines Datendienstes

In diesem Kapitel wird beschrieben, wie eine Anwendung hoch verfügbar oder skalierbar gemacht wird. Es enthält detaillierte Informationen zur Entwicklung 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 hohe Verfügbarkeit bzw. Skalierbarkeit erfüllt. Wenn die Anwendung nicht alle Anforderungen erfüllt, können Sie den Quellcode der Anwendung ändern, um sie hoch verfügbar oder skalierbar zu machen.

Die folgende Liste fasst die Anforderungen für eine Anwendung, die hoch verfügbar oder skalierbar gemacht werden soll, zusammen. Wenn Sie weitere Informationen benötigen oder den Quellcode der Anwendung ändern möchten, lesen Sie Anhang B, Codeauflistungen für Beispieldatendienste.

Hinweis –

Ein Scalable-Dienst muss für eine hohe Verfügbarkeit die folgenden Bedingungen sowie einige zusätzliche Kriterien erfüllen, die in der nachfolgenden Liste beschrieben werden.

Außerdem müssen die Scalable-Dienste folgende Anforderungen erfüllen:

Bei einem Scalable-Dienst legen die Anwendungseigenschaften auch das Lastausgleichsverfahren fest. Das Lastausgleichsverfahren Lb_weighted, das eine Reaktion auf Client-Anforderungen für jede Instanz zulässt, funktioniert nicht bei einer Anwendung, die einen im Speicher vorhandenen Cache 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, sodass sie einen im Speicher vorhandenen Cache verwenden können. Beachten Sie, dass RGM mehrere Client-Anforderungen von unterschiedlichen Clients unter den Instanzen des Dienstes verteilt. Weitere Informationen zum Festlegen des Lastausgleichsverfahrens für skalierbare Datendienste finden Sie im Abschnitt 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.

Im Folgenden wird ein Ansatz zur Entwicklung eines Datendienstes beschrieben:

  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 angeforderten Informationen ein und generieren Sie einen Datendienst, der Quellcode und ausführbaren Code enthält, eine RTR-Datei und ein 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. Anstatt zum Beispiel an bestimmten Stellen im Code, der von Agent Builder generiert wird, eigenen Code einzufügen, könnten Sie eine der generierten Methoden oder das generierte Überwachungsprogramm vollständig durch ein Programm ersetzen, das Sie mithilfe von DSDL- oder RMAPI-Funktionen von Null schreiben. Unabhängig von Ihrer Vorgehensweise macht das Starten mit Agent Builder aus folgenden Gründen fast immer Sinn:

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 Entwicklung Ihres Datendienstes beginnen, müssen Sie das Sun Cluster-Entwicklungspaket (SUNWscdev) installieren, um Zugriff auf die Sun Cluster-Header- und Bibliothekdsdateien zu erhalten. Obwohl dieses Paket bereits auf allen Cluster-Knoten installiert ist, entwickeln Sie Ihren Datendienst in der Regel auf einem separaten Entwicklungsrechner ohne Cluster und nicht auf einem Cluster-Knoten. In diesem typischen Fall müssen Sie den Befehl pkgadd für die Installation des SUNWscdev-Pakets auf Ihrem Entwicklungsrechner verwenden.

Beim Kompilieren und Verknüpfen des Codes müssen Sie besondere Optionen für die Identifizierung der Header- und Bibliotheksdateien einstellen.

Hinweis –

Im Solaris-Betriebssystem und in den Sun Cluster-Produkten kann im Kompatibilitätsmodus kompilierter C++-Code nicht mit im Standardmodus kompiliertem C++-Code gemischt werden. Wenn Sie also einen C++-basierten Datendienst zur Verwendung in Sun Cluster erstellen möchten, müssen Sie diesen Datendienst wie folgt kompilieren:

Wenn Sie die Entwicklung (auf einem Knoten ohne Cluster) beendet haben, können Sie den fertigen Datendienst zum Testen auf einen Cluster verschieben.

Hinweis –

Vergewissern Sie sich, dass Sie die Developer- oder Entire Distribution-Software von Solaris 8 OS oder eine höhere Version von Solaris OS verwenden.

In diesem Abschnitt werden die Verfahren zum Durchführen der folgenden Aufgaben beschrieben:

ProcedureSo konfigurieren Sie die Entwicklungsumgebung:

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

Schritte

  1. Nehmen Sie Superuser-Status oder eine entsprechende administrative Rolle an.

  2. Ändern Sie das Verzeichnis in das gewünschte CD-ROM-Verzeichnis. 


    # cd cd-rom-Verzeichnis

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

    • Geben Sie für Solaris 10 OS in einer Zonenumgebung als globaler Administrator in der globalen Zone den folgenden Befehl ein: 


      # pkgadd -G -d . SUNWscdev

      Das SUNWscdev-Paket wird der globalen Zone hinzugefügt, vorausgesetzt, der Inhalt von SUNWscdev wirkt sich auf keinen Bereich der globalen Zone aus, die mit einer nicht-globalen Zone gemeinsam genutzt wird.

    • Für jede andere Version von Solaris OS oder Solaris 10 OS in einer Umgebung ohne Zonen geben Sie folgenden Befehl ein: 


      # pkgadd -d . SUNWscdev

  4. Geben Sie in der makefile Compiler- und Verknüpfer-Optionen an, die die include- und Bibliotheksdateien für Ihren Datendienstcode identifizieren.

    Geben Sie die -I-Option an, um die Sun Cluster-Header-Dateien zu identifizieren, die -L-Option, um den Bibliothekssuchpfad im Entwicklungssystem anzugeben und die -R-Option, um den Bibliothekssuchpfad des Laufzeitverknüpfers im Cluster anzugeben. 

    # Makefile for sample data service
...

-I /usr/cluster/include

-L /usr/cluster/lib

-R /usr/cluster/lib
...

Übertragen eines Datendienstes auf einen Cluster

Wenn Sie den Datendienst auf einem Entwicklungsrechner fertig gestellt haben, müssen Sie den Datendienst zum Testen auf einen Cluster übertragen. Um die Fehlerquote während der Übertragung zu reduzieren, kombinieren Sie den Datendienstcode und die RTR-Datei in einem Paket und installieren Sie das Paket auf allen Knoten im Cluster.

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. Beachten Sie, dass Agent Builder dieses Paket automatisch erstellt.

Einstellen der Ressourcen- und Ressourcentypeigenschaften

Sun Cluster stellt einen Satz Ressourcentypeigenschaften und Ressourceneigenschaften bereit, die zum Definieren der statischen Konfiguration eines Datendienstes verwendet werden. Die Ressourcentypeigenschaften geben den Ressourcentyp an, seine Version, die Version der API sowie die Pfade der einzelnen Rückmeldemethoden. Der Abschnitt Ressourcentypeigenschaften enthält eine Liste mit Ressourcentypeigenschaften.

Die Ressourceneigenschaften, wie z.B. Failover_mode, Thorough_probe_interval und die Methoden-Zeitlimits definieren auch die statische Konfiguration der Ressource. Die dynamischen Ressourceneigenschaften, wie z.B. Resource_state und Status spiegeln den aktiven Zustand der verwalteten Ressource wider. Im Abschnitt Ressourceneigenschaften werden die Ressourceneigenschaften beschrieben.

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.

Verwenden Sie Agent Builder, um die RTR-Datei für Ihren Datendienst zu generieren, weil Agent Builder den Satz Eigenschaften deklariert, die für einen Datendienst nützlich und erforderlich sind. Bestimmte Eigenschaften, wie Resource_type müssen z.B. in der RTR-Datei deklariert sein. Andernfalls schlägt die Registrierung des Datendienstes fehl. Andere Eigenschaften, die zwar nicht erforderlich sind, stehen einem Cluster-Administrator nur zur Verfügung, wenn sie in der RTR-Datei deklariert sind. Einige Eigenschaften stehen zur Verfügung, ob Sie diese nun deklarieren oder nicht, weil sie von RGM definiert werden und Standardwerte bieten. Um diese Stufe der Komplexität zu vermeiden, können Sie mit Agent Builder die Generierung einer richtigen RTR-Datei sicherstellen. Später können Sie die RTR-Datei bearbeiten, um gegebenenfalls bestimmte Werte zu ändern.

Die restlichen Informationen in diesem Abschnitt stellen eine RTR-Beispieldatei dar, die von Agent Builder erstellt wurde.

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 –

Lediglich ein Cluster-Administrator kann die Ressourcentypeigenschaft Installed_nodes deklarieren. Sie können Installed_nodes nicht in der RTR-Datei deklarieren.

Die Syntax der Ressourcentypdeklarationen lautet wie folgt: 

Eigenschaftsname = Wert;
Hinweis –

Die Eigenschaftsnamen der Ressourcengruppen, Ressourcen und Ressourcentypen unterliegen nicht der Groß-/Kleinschreibung. Bei der Eingabe von Eigenschaftsnamen können Sie jede beliebige Kombination aus Groß- und Kleinbuchstaben verwenden.

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

# Sun Cluster Data Services Builder template version 1.0
# Registration information and resources for smpl
#
#NOTE: Keywords are case insensitive, i.e., you can use
#any capitalization style you prefer.
#
Resource_type = "smpl";
Vendor_id = SUNW;
RT_description = "Sample Service on 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.

Resource_type und Vendor_id

Geben dem Ressourcentyp einen Namen. Sie können den Ressourcentypnamen mit der Resource_type-Eigenschaft allein (smpl ) oder mit der Vendor_id-Eigenschaft als Präfix mit einem “.” verwenden, durch das es vom Ressourcentyp (SUNW.smpl) getrennt wird, wie im Beispiel dargestellt. Verwenden Sie als Vendor_id das Börsensymbol des Unternehmens, das den Ressourcentyp definiert. Der Ressourcentypname muss im Cluster einmalig sein.

Hinweis –

Per Konvention wird der Ressourcentypname (HerstellerIDAnwendungsname) als Paketname verwendet. Wenn Sie das Betriebssystem Solaris 9 verwenden, darf die Kombination aus Herstellername und Anwendungsname neun Zeichen überschreiten. Wenn Sie jedoch mit einer früheren Version des Betriebssystems Solaris arbeiten, darf die Kombination aus Hersteller-ID und Anwendungsname neun Zeichen nicht überschreiten, obwohl RGM diesen Grenzwert nicht erzwingt.

Agent Builder generiert andererseits in allen Fällen den Paketnamen aus dem Ressourcentypnamen, damit der Grenzwert von neun Zeichen erzwungen wird.

RT_description

Beschreibt den Ressourcentyp kurz.

RT_version

Identifiziert die Version des Beispieldatendienstes.

API_version

Identifiziert die API-Version. API_version = 2 gibt z.B. an, dass der Datendienst mit jeder beliebigen Version von Sun Cluster ausgeführt werden kann, beginnend bei Sun Cluster 3.0. API_version = 5 gibt an, dass der Datendienst für jede beliebige Version von Sun Cluster beginnend mit 3.1 9/04 installiert werden kann. API_version = 5 gibt jedoch auch an, dass der Datendienst mit keiner Version von Sun Cluster installiert werden kann, die vor 3.1 9/04 herausgegeben wurde. Diese Eigenschaft wird unter dem Eintrag API_version im Abschnitt Ressourcentypeigenschaften detailliert beschrieben.

Failover = TRUE

Gibt an, dass der Datendienst nicht in einer Ressourcengruppe ausgeführt werden kann, die an mehreren Knoten gleichzeitig online sein kann. Mit anderen Worten, diese Deklaration gibt einen Failover-Datendienst an. Diese Eigenschaft wird unter dem Eintrag Failover im Abschnitt Ressourcentypeigenschaften detailliert beschrieben.

Start, Stop und Validate

Geben die Pfade der entsprechenden Rückmeldemethodenprogramme an, die von RGM aufgerufen werden. Diese Pfade sind relativ zu dem von RT_basedir angegebenen Verzeichnis.

Die verbleibenden Ressourcentypdeklarationen liefern Konfigurationsinformationen.

Init_nodes = RG_PRIMARIES

Gibt an, dass RGM die Init-, Boot-, Fini- und Validate-Methoden nur auf Knoten aufruft, die den Datendienst bearbeiten können. Die mit 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 und Validate

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

Deklarieren von Ressourceneigenschaften

Wie im Falle von Ressourcentypeigenschaften deklarieren Sie Ressourceneigenschaften in der RTR-Datei. 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: 

{
    attribute = value;
    attribute = value;
             .
             .
             .
    attribute = value;
}

Für Ressourceneigenschaften, die von Sun Cluster bereitgestellt werden und die als systemdefinierte Eigenschaften bezeichnet werden, können Sie bestimmte Attribute in der RTR-Datei ändern. Sun Cluster bietet z.B. Standardwerte für die Methodenzeitlimit-Eigenschaften der einzelnen Rückmeldemethoden. In der RTR-Datei können Sie andere Standardwerte festlegen.

Sie können in der RTR-Datei auch neue Ressourceneigenschaften definieren, die als Erweiterungseigenschaften bezeichnet werden, indem Sie einen Satz Eigenschaftsattribute von Sun Cluster verwenden. Im Abschnitt Ressourceneigenschaftsattribute werden die Attribute zum Ändern und Definieren von Ressourceneigenschaften aufgelistet. Erweiterungseigenschaftsdeklarationen folgen in der RTR-Datei auf die Deklarationen der systemdefinierten Eigenschaften.

Der erste Satz systemdefinierter Ressourceneigenschaften legt die Zeitüberschreitungswerte für die Rückmeldemethoden fest. 

...

# Resource property declarations appear as a list of bracketed
# entries after the resource type declarations. The property 
# name declaration must be the first attribute after the open
# curly bracket of a resource property entry.
#
# Set minimum and default for method timeouts.
{
        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 für jede Ressourceneigenschaftsdeklaration sein. Sie können Ressourceneigenschaften innerhalb von Grenzwerten konfigurieren, die von den Eigenschaftswerten in der RTR-Datei definiert werden. So beträgt zum Beispiel der Standardwert für jedes Methoden-Zeitlimit im Beispiel 300 Sekunden. Der Cluster-Administrator kann den Wert ändern. Der zulässige Mindestwert, angegeben durch das MIN-Attribut, beträgt jedoch 60 Sekunden. Der Abschnitt Ressourceneigenschaftsattribute enthält eine 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;
}

# The number of retries to be done within a certain period before concluding
# that the application cannot be successfully started on this node.
{
        PROPERTY = Retry_count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME; 
}

# Set Retry_interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of
# retries (Retry_count).
{
        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 = ANYTIME;
        DEFAULT = ;
}

Diese Ressourceneigenschaftsdeklarationen umfassen u.a. das TUNABLE-Attribut. Dieses Attribut beschränkt die Gelegenheiten, zu denen der Cluster-Administrator den Wert der Eigenschaft, mit dem dieses Attribut verknüpft ist, ändern kann. Der Wert AT_CREATION bedeutet z.B., dass der Cluster-Administrator den Wert nur bei Erstellung der Ressource festlegen und ihn zu einem späteren Zeitpunkt nicht mehr ändern kann.

Für die meisten dieser Eigenschaften können Sie die Standardwerte so übernehmen, wie sie von Agent Builder generiert wurden, es sei denn, es liegt ein besonderer Grund vor, sie zu ändern. Informationen über diese Eigenschaften folgen. Weitere Informationen erhalten Sie im Abschnitt Ressourceneigenschaften oder in der Online-Dokumentation zu r_properties(5).

Failover_mode

Gibt an, ob RGM die Ressourcengruppe umleiten oder den Knoten im Falle eines Scheiterns einer Start- oder Stop-Methode abbrechen soll.

Thorough_probe_interval, Retry_count und Retry_interval

Wird im Fehler-Monitor verwendet. Tunable entspricht Anytime, sodass ein Cluster-Administrator sie anpassen kann, wenn der Fehler-Monitor nicht optimal funktioniert.

Network_resources_used

Eine Liste mit logischen Hostnamen oder gemeinsam genutzten Adressressourcen, die vom Datendienst verwendet werden. Agent Builder deklariert diese Eigenschaft so, dass ein Cluster-Administrator bei der Konfiguration des Datendienstes eine Liste mit Ressourcen angeben kann, falls vorhanden.

Scalable

Ist auf FALSE eingestellt, um anzugeben, dass diese Ressource die Cluster-Netzwerkoption (gemeinsam genutzte Adresse) nicht verwendet. Wenn Sie diese Eigenschaft auf FALSE setzen, muss die Ressourcentypeigenschaft Failover auf TRUE eingestellt sein, um einen Failover-Dienst anzugeben. Weitere Informationen über die Verwendung dieser Eigenschaft finden Sie im Abschnitt Übertragen eines Datendienstes auf einen Cluster und Implementieren von Rückmeldemethoden.

Load_balancing_policy und Load_balancing_weights

Deklariert diese Eigenschaften automatisch. Diese Eigenschaften finden jedoch bei einem Failover-Ressourcentyp keine Verwendung.

Port_list

Eine Liste mit Portnummern, die der Server abhört. Agent Builder deklariert diese Eigenschaft so, dass ein Cluster-Administrator bei der Konfiguration des Datendienstes eine Liste mit Ports angeben kann, falls vorhanden.

Deklarieren von Erweiterungseigenschaften

Erweiterungseigenschaften stehen am Ende der RTR-Beispieldatei. 

# Extension Properties
#

# The cluster administrator must set the value of this property to point to the 
# directory that contains the configuration files used by the application.
# For this application, smpl, specify the path of the configuration file on
# PXFS (typically named.conf).
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "The Configuration Directory Path(s)";
}

# The following two properties control restart of the fault monitor.
{
        PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Number of PMF restarts allowed for fault monitor.";
}
{
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time window (minutes) for fault monitor restarts.";
}
# Time out value in seconds for the probe.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time out value for the probe (seconds)";
}

# Child process monitoring level for PMF (-C option of pmfadm).
# Default of -1 means to not use the -C option of pmfadm.
# A value of 0 or greater indicates the desired level of child-process.
# monitoring.
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Child monitoring level for PMF";
}
# User added code -- BEGIN VVVVVVVVVVVV
# User added code -- END   ^^^^^^^^^^^^

Agent Builder erstellt die folgenden 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 Cluster-Administrator kann den Ort dieses Verzeichnisses bei der Konfiguration des Datendienstes angeben.

Monitor_retry_count, Monitor_retry_interval und Probe_timeout

Steuert die Neustarts des Fehler-Monitors, nicht den Server-Dämon.

Child_mon_level

Legt die Stufe der Überwachung fest, die von PMF ausgeführt werden soll. Weitere Informationen finden Sie in der Online-Dokumentation unter pmfadm(1M).

Sie können weitere Erweiterungseigenschaften in dem Bereich erstellen, der von den User added code-Kommentaren begrenzt ist.

Implementieren von Rückmeldemethoden

Dieser Abschnitt liefert allgemeine Informationen, die sich auf die Implementierung von Rückmeldemethoden beziehen.

Zugreifen auf Informationen über Ressourcen- und Ressourcengruppeneigenschaften

Im Allgemeinen ist für Rückmeldemethoden Zugriff auf die Ressourceneigenschaften erforderlich. 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 bietet einen Satz C-Funktionen (eine Funktion für jede Eigenschaft), um auf systemdefinierte Eigenschaften zuzugreifen, sowie eine Funktion für den 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 Eigenschaftenmechanismus nicht zum Speichern von dynamischen Zustandsinformationen für einen Datendienst verwenden, weil keine API-Funktionen zum Festlegen von anderen Ressourceneigenschaften als Status und Status_msg zur Verfügung stehen. Stattdessen müssen Sie dynamische Zustandsinformationen in globalen Dateien speichern.

Hinweis –

Der Cluster-Administrator kann bestimmte Ressourceneigenschaften mit dem scrgadm-Befehl oder über einen grafischen Verwaltungsbefehl oder eine Schnittstelle festlegen. Rufen Sie jedoch scrgadm nicht von einer Rückmeldemethode auf, weil scrgadm während der Cluster-Neukonfiguration, d.h. beim Aufrufen der Methode durch RGM, fehlschlägt.

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 für eine Ressource eine Stop-Methode aufrufen, obwohl die Ressource niemals gestartet wurde. Genauso könnte ein Ressourcendämon von selbst anhalten und RGM weiterhin die Stop-Methode dafür ausführen. Dieselben Szenarien gelten für die Monitor_start- und Monitor_stop-Methoden.

Aus diesem Grund müssen Sie in die Stop- und Monitor_stop-Methoden Idempotenz integrieren. Wiederholte Aufrufe von Stop oder Monitor_stop für dieselbe Ressource mit denselben Argumenten führen zu denselben Ergebnissen wie ein einzelner 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 ist und keine Aufgabe ausgeführt wird.

Hinweis –

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

Generischer Datendienst

Ein generischer Datendienst (GDS) ist ein Mechanismus, um einfache Anwendungen hoch verfügbar oder skalierbar zu machen, indem sie in das Sun Cluster-RGM-Framework eingesteckt werden. Bei diesem Mechanismus müssen Sie keinen Datendienst kodieren, was in der Regel erforderlich ist, wenn Sie eine Anwendung hoch verfügbar oder skalierbar machen möchten.

Das GDS-Modell basiert auf einem vorkompilierten Ressourcentyp, SUNW.gds, für die Interaktion mit dem RGM-Framework. Weitere Informationen finden Sie in Kapitel 10, Generische Datendienste.

Steuern einer Anwendung

Rückmeldemethoden ermöglichen RGM, die zugrunde liegende Ressource zu steuern (d.h. die Anwendung), sobald die Knoten dem Cluster beitreten oder ihn verlassen.

Starten und Stoppen einer Ressource

Für die Implementierung eines Ressourcentyps sind mindestens eine Start- und eine Stop-Methode erforderlich. RGM ruft die Methodenprogramme eines Ressourcentyps zu den richtigen Zeiten und auf den richtigen Knoten auf, um die Ressourcengruppen offline und online zu bringen. Nach dem Absturz eines Cluster-Knotens verschiebt RGM z.B. Ressourcengruppen, die von diesem Knoten verarbeitet werden, 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 die Ressourcentypen, für die ein langer Initialisierungszeitraum benötigt wird, ausreichend lange Zeitüberschreitungswerte für die Start-Methoden festgelegt sind. Um ausreichende Zeitüberschreitungswerte sicherzustellen, legen Sie in der RTR-Datei die Standard- und Mindestwerte für die Start_timeout-Eigenschaft fest.

Eine Stop-Methode muss für Situationen implementiert werden, in denen RGM eine Ressourcengruppe offline nimmt. Angenommen, eine Ressourcengruppe wird z.B. an Knoten 1 offline genommen und an Knoten 2 erneut online gebracht. Wenn die Ressourcengruppe offline genommen wird, ruft RGM die Stop-Methode für die Ressourcen in der Gruppe auf, um die gesamte Aktivität an Knoten 1 zu stoppen. Nachdem die Stop-Methoden für alle Ressourcen an Knoten 1 vollständig ausgeführt wurden, bringt RGM die Ressourcengruppe auf Knoten 2 erneut 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 am lokalen Knoten, die sich auf die Ressource beziehen. Für Ressourcentypen, für die eine lange Zeit zum Herunterfahren benötigt wird, sollten ausreichend lange Zeitüberschreitungswerte für die Stop-Methoden festgelegt sein. Legen Sie die Stop_timeout-Eigenschaft in der RTR-Datei fest.

Ein Fehler oder eine Zeitüberschreitung einer Stop-Methode führt dazu, dass die Ressourcengruppe einen Fehlerstatus erhält und der Cluster-Administrator eingreifen muss. 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.

Verwendung von 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 sollten. Sie müssen sowohl mit dem Client-Server-Netzwerkprotokoll des Clients als auch des Datendienstes vertraut sein, um zu entscheiden, welche Methoden die richtigen sind.

Für Dienste, die Netzwerkadressressourcen verwenden, ist es eventuell erforderlich, dass Start- oder Stop-Schritte in einer bestimmten Reihenfolge entsprechend der logischen Hostnamen-Adresskonfiguration unternommen werden. 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. Die Reihenfolge ist Folgende, wenn RGM eine Ressourcengruppe online bringt:

  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.

Wenn Sie eine Entscheidung treffen möchten, ob Sie die Start-, Stop-, Prenet_start- oder Postnet_stop-Methoden verwenden möchten, sollten Sie zunächst an die Serverseite denken. 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.

Zum Starten oder Stoppen eines Datendienstes müssen Sie eventuell die Verwaltungsdienstprogramme oder Bibliotheken des Datendienstes ausführen. 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 in diesem Szenario 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. Wenn Sie den Datendienst auf diese Weise starten, wird sichergestellt, dass der Datendienst sofort auf Client-Andorderungen reagieren kann, sobald die Netzwerkadresse als aktiv konfiguriert wurde. Die Wahrscheinlichkeit, dass die Clients die Wiederholversuche stoppen, ist so geringer. 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 ausgeführt. Der TCP- oder UDP-Dienstport oder seine RPC-Programmnummer scheint folglich immer den Clients im Netzwerk zur Verfügung zu stehen, außer in den Fällen, in denen die Netzwerkadresse ebenfalls nicht reagiert.

Hinweis –

Wenn Sie im Cluster einen RPC-Dienst installieren, darf der Dienst folgende Programmnummern nicht verwenden: 100141, 100142 und 100248. Diese Nummern sind den Sun Cluster-Dämonen rgmd_receptionist, fed und pmfd vorbehalten. Wenn der von Ihnen installierte RPC-Dienst eine dieser Programmnummern verwendet, müssen Sie die Programmnummer dieses RPC-Dienstes ändern.

Bei der Entscheidung, die Start- und Stop-Methoden bzw. die Prenet_start- und Postnet_stop-Methoden oder beide zu verwenden, müssen die Anforderungen und das Verhalten von Server und Client berücksichtigt werden.

Init-, Fini- und Boot-Methoden

Mithifle von drei optionalen Methoden, Init, Fini und Boot kann RGM Initialisierungs- und Beendigungscode für eine Ressource ausführen.

RGM führt die Init-Methode aus, um eine einmalige Initialisierung der Ressource durchzuführen, wenn die Ressource als Ergebnis einer der folgenden Bedingungen verwaltet wird:

RGM führt die Fini-Methode aus, um nach der Ressource eine Bereinigung durchzuführen, wenn die Ressource als Ergebnis einer der folgenden Bedingungen nicht verwaltet wird:

Die Bereinigung muss idempotent sein. Das heißt, wenn die Bereinigung bereits ausgeführt wurde, wird Fini erfolgreich beendet.

RGM führt die Boot-Methode auf Knoten aus, die dem Cluster gerade erst beigetreten sind, d.h., die Knoten wurden gerade erst gestartet oder neu gestartet.

Die Boot-Methode führt in der Regel die gleiche Initialisierung wie Init aus. Diese Initialisierung muss idempotent sein, d.h. wenn die Ressource auf dem lokalen Knoten bereits initialisiert wurde, werden Boot und Init erfolgreich beendet.

Ü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. Schlägt ein Fehlertestsignal fehl, kann der Monitor versuchen, lokal neu zu starten, oder einen Failover der betroffenen Ressourcengruppe anfordern. Der Monitor fordert den Failover an, indem die scha_control() RMAPI-Funktion oder die scds_fm_action()-DSDL-Funktion aufgerufen wird.

Sie können auch die Leistung einer Ressource überwachen und die Leistung optimieren oder in einem Bericht aufzeichnen. Das Schreiben eines ressourcentyp-spezifischen Fehler-Monitors ist 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 einen Ressourcenmonitor nicht direkt aufruft, bietet RGM das automatische Starten 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 gestartet wurde.

Die scha_control()-RMAPI-Funktion und die scds_fm_action ()-DSDL-Funktion (die scha_control() aufruft) ermögichen den Ressourcenmonitoren das Anfordern eines Failovers einer Ressourcengruppe an einen anderen Knoten. Als eine der Zustandsprüfungen ruft scha_control() Monitor_check (falls definiert) auf, um zu ermitteln, ob der angeforderte Knoten zuverlässig genug ist, um die Ressourcengruppe zu bearbeiten, die die Ressource enthält. Wenn Monitor_check zurückmeldet, dass der Knoten nicht zuverlässig ist, oder wenn eine Zeitüberschreitung für die Methode erfolgte, sucht RGM einen anderen Knoten für die Failover-Anforderung. Wenn Monitor_check an allen Knoten fehlschlägt, wird der Failover unterbrochen.

Der Ressourcenmonitor kann die Status- und Status_msg -Eigenschaften festlegen, um die Monitoransicht des Ressourcenzustands widerzuspiegeln. Verwenden Sie die scha_resource_setstatus()-RMAPI-Funktion, den scha_resource_setstatus-Befehl oder die scds_fm_action()-DSDL-Funktion, um diese Eigenschaften festzulegen.

Hinweis –

Obwohl die Status- und Status_msg-Eigenschaften für einen Ressourcenmonitor von besonderem Wert sind, können diese Eigenschaften mit jedem beliebigen Programm festgelegt werden.

Ein Beispiel für einen Fehler-Monitor, der mit der RMAPI implementiert wird, finden Sie im Abschnitt Definieren eines Fehler-Monitors. Ein Beispiel für einen Fehler-Monitor, der mit der DSDL implementiert wird, finden Sie im Abschnitt 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 Optionen:

Process Monitor Facility (PMF): pmfadm und rpc.pmfd

Überwacht Prozesse und ihre untergeordneten Prozesse und startet sie neu, wenn diese angehalten werden. Diese Option besteht aus dem pmfadm-Befehl zum Starten und Steuern der überwachten Prozesse und dem rpc.pmfd-Dämon.

Die DSDL bietet einen Satz von Funktionen (mit vorangestelltem Namen scds_pmf_ ) zur Implementierung der PMF-Funktionalität. Eine Übersicht über die DSDL-PMF-Funktionen sowie eine Liste der einzelnen Funktionen finden Sie im Abschnitt PMF-Funktionen.

Dieser Befehl und der Dämon werden in der Online-Dokumentation unter pmfadm(1M) und rpc.pmfd(1M) detailliert beschrieben.

halockrun

Ein Programm für das Ausführen eines untergeordneten Programms mit Dateisperre. Dieser Befehl kann problemlos in Shell-Skripts verwendet werden.

In der Online-Dokumentation zu halockrun(1M) wird dieser Befehl detailliert beschrieben.

hatimerun

Ein Programm zum Ausführen eines untergeordneten Programms unter Zeitlimitsteuerung. Dieser Befehl kann problemlos in Shell-Skripts verwendet werden.

Die DSDL stellt die scds_hatimerun()-Funktion für die Implementierung der hatimerun-Funktionalität bereit.

Dieser Befehl wird in der Online-Dokumentation unter hatimerun(1M) detailliert beschrieben.

Verwaltungsunterstützung für eine Ressource

Zu den Aktionen, die von Cluster-Administratoren für Ressourcen durchgeführt werden, gehören das Festlegen und Ändern der Ressourceneigenschaften. Die API definiert die Validate- und Update-Rückmeldemethoden so, dass Sie Code erstellen können, der diese Verwaltungsaktionen nutzt.

RGM ruft diese optionale Validate-Methode auf, wenn eine Ressource erstellt wird und wenn der Cluster-Administrator die Eigenschaften der Ressource oder der enthaltenen Ressourcengruppe 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, die mit der Init_nodes-Eigenschaft des Ressourcentyps angegeben sind. Informationen zu Init_nodes finden Sie in der Online-Dokumentation unter Ressourcentypeigenschaften und rt_properties(5). RGM ruft Validate auf, bevor die Erstellung oder Aktualisierung angewendet wird. Ein Fehlerbeendigungscode der Methode an einem beliebigen Knoten führt zur Unterbrechung der Erstellung oder Aktualisierung.

RGM ruft Validate nur auf, wenn ein Cluster-Administrator die Ressourcen- oder Ressourcengruppeneigenschaften ändert oder wenn ein Monitor die Ressourceneigenschaften Status und Status_msg festlegt.

RGM ruft die optionale Update-Methode auf, um eine laufende Ressource darüber zu benachrichtigen, dass Eigenschaften geändert wurden. RGM führt Update aus, nachdem ein Cluster-Administrator die Eigenschaften einer Ressource oder ihrer Gruppe erfolgreich ausführt. 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 z.B. die integrierten Ressourcentypen LogicalHostname und SharedAddress , sowie Failover-Ressourcen, wie die Datendienst-Anwendungsressourcen für einen Failover-Datendienst. Die Netzwerkadressressourcen, zusammen mit ihren abhängigen Datendienstressourcen, werden zwischen den Cluster-Knoten verschoben, wenn die Datendienste einen Failover oder Switchover ausführen. RGM stellt eine Reihe von Eigenschaften zur Unterstützung der Implementierung einer Failover-Ressource bereit.

Stellen Sie die boolesche Failover-Ressourcentypeigenschaft auf TRUE, damit die Ressource nicht in einer Ressourcengruppe konfiguriert wird, die auf mehr als einem Knoten gleichzeitig online sein kann. Der Standardwert für diese Eigenschaft lautet FALSE. Sie müssen sie für eine Failover-Ressource in der RTR-Datei als TRUE deklarieren.

Die Scalable-Ressourceneigenschaft legt fest, ob die Ressource die vom Cluster gemeinsam genutzte Adressoption verwendet. Legen Sie für eine Failover-Ressource Scalable auf FALSE fest, weil eine Failover-Ressource keine gemeinsam genutzten Adressen verwendet.

Mit der RG_mode-Ressourcengruppeneigenschaft kann der Cluster-Administrator eine Ressourcengruppe als Failover oder skalierbar identifizieren. Wenn der Wert Failover lautet, legt der RGM die Maximum_primaries -Eigenschaft der Gruppe auf 1 fest und beschränkt die Ressourcengruppe auf die Verarbeitung durch einen einzelnen Knoten. Der RGM lässt nicht zu, dass eine Ressource, deren Failover-Eigenschaft TRUE ist, einer Ressourcengruppe hinzugefügt wird, deren RG_mode auf SCALABLE eingestellt ist.

Die Implicit_network_dependencies-Ressourcengruppeneigenschaft legt fest, dass RGM implizit starke Abhängigkeiten von Adressressourcen ohne Netzwerkunterstützung für alle Netzwerkadressressourcen (LogicalHostname und SharedAddress) innerhalb der Gruppe erzwingen sollte. Folglich werden die Start-Methoden der Adressressourcen ohne Netzwerkunterstützung (Datendienst) in der Gruppe so lange nicht aufgerufen, bis die Netzwerkadressen in der Gruppe aktiv konfiguriert werden. Die Implicit_network_dependencies -Eigenschaft ist standardmäßig auf TRUE eingestellt.

Implementieren einer Scalabe-Ressource

Eine Scalable-Ressource kann auf mehr als einem Knoten gleichzeitig online sein. Skalierbare 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 bietet eine Vielzahl von Eigenschaften, die die Implementierung einer skalierbaren Ressource unterstützen.

Stellen Sie die boolesche Failover-Ressourcentypeigenschaft auf TRUE, damit die Ressource nicht in einer Ressourcengruppe konfiguriert wird, die auf mehr als einem Knoten gleichzeitig online sein kann.

Die Scalable-Ressourceneigenschaft legt fest, ob die Ressource die vom Cluster gemeinsam genutzte Adressoption verwendet. Legen Sie diese Eigenschaft auf TRUE fest, weil ein Scalable-Dienst eine Ressource mit einer gemeinsam genutzten Adresse verwendet, damit die Mehrfachinstanzen des Scalable-Dienstes dem Client als einzelner Dienst erscheinen.

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 einen Maximum_primaries-Wert zu, der höher ist als 1. Dies bedeutet, dass die Gruppe von mehreren Knoten gleichzeitig verarbeitet werden kann. RGM erlaubt, dass eine Ressource, deren Failover-Eigenschaft FALSE lautet, in einer Ressourcengruppe instantiiert werden kann, deren RG_mode-Wert SCALABLE lautet.

Der Cluster-Administrator erstellt eine Scalable-Ressourcengruppe, die die Scalable-Dienstressourcen sowie eine separate Failover-Ressourcengruppe enthalten soll. Diese wiederum soll die gemeinsam genutzten Adressressourcen enthalten, von denen die Scalable-Ressource abhängig ist.

Der Cluster-Verwalter verwendet die Ressourcengruppeneigenschaft RG_dependencies zum Festlegen 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. Deshalb muss der Cluster-Administrator die RG_dependencies-Eigenschaft (der Ressourcengruppe, die den Scalable-Dienst enthält) so festlegen, dass sie die Ressourcengruppe mit den gemeinsam genutzten Adressressourcen enthält.

Wenn Sie die Scalable-Eigenschaft in der RTR-Datei für eine Ressource deklarieren, erstelllt RGM automatisch den folgenden Satz skalierbarer Eigenschaften für die Ressource.

Network_resources_used

Identifiziert die gemeinsam genutzten Adressressourcen, die von dieser Ressource verwendet werden. Diese Eigenschaft wird standardmäßig auf die leere Zeichenkette eingestellt, sodass der Cluster-Administrator die tatsächliche Liste mit gemeinsam genutzten Adressen liefern muss, die vom Scalable-Dienst beim Erstellen der Ressource verwendet wird. 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

Legt das Lastausgleichsverfahren für die Ressource fest. Dieses Verfahren können Sie ausdrücklich in der RTR-Datei festlegen (oder den Standardwert LB_WEIGHTED zulassen). In beiden Fällen kann der Cluster-Administrator den Wert beim Erstellen der Ressource ändern (es sei denn, Sie stellen Tunable für Load_balancing_policy in der RTR-Datei auf NONE oder FALSE ein). Die folgenden Werte sind zulässig:

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 Platzhalterdienstes herstellt, wird immer an denselben Cluster-Knoten verwiesen, unabhängig von der Portnummer, an der er ankommt.

Für einen Scalable-Dienst mit einem Load_balancing_policy-Wert von LB_STICKY oder LB_STICKY_WILD kann das Ändern von Load_balancing_weights , während der Dienst online ist, dazu führen, dass bestehende Client-Affinitäten zurückgesetzt werden. In diesem Fall kann ein anderer Knoten eine nachfolgende Client-Anforderung bedienen, selbst wenn der Client zuvor von einem anderen Knoten im Cluster bedient wurde.

Auf ähnliche Weise kann das Starten einer neuen Instanz des Dienstes auf einem Cluster die vorhandenen Client-Affinitäten zurücksetzen.

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, die den relativen Anteil der Last angibt, die auf den angegebenen Knoten verteilt wird. Der Lastanteil, der auf einen Knoten verteilt wird, ist die Gewichtung dieses Knotens, geteilt durch die Summe aller Gewichtungen. Zum Beispiel gibt 1@1,3@2 an, dass Knoten 1 ein Viertel der Last erhält und Knoten 2 drei Viertel der Last.

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, der vom Cluster-Administrator als Failover- oder Scalable-Dienst konfiguriert werden kann. Deklarieren Sie dazu sowohl die Failover-Ressourcentypeigenschaft als auch die Scalable-Ressourceneigenschaft in der RTR-Datei des Datendienstes als FALSE. Beim Erstellen muss die Scalable-Eigenschaft als “Tunable” angegeben werden.

Der Failover-Eigenschaftswert FALSE erlaubt es, dass die Ressource als skalierbare Ressourcengruppe konfiguriert wird. Der Cluster-Administrator kann gemeinsam genutzte Adressen aktivieren, indem er beim Erstellen der Ressource den Wert von Scalable auf TRUE setzt, um einen Scalable-Dienst zu erstellen.

Andererseits kann der Cluster-Administrator die Ressource selbst dann zum Implementieren eines Failover-Dienstes in eine Failover-Ressourcengruppe konfigurieren, wenn Failover auf FALSE eingestellt ist. Der Cluster-Administrator ändert den Wert Scalable, der FALSE lautet, nicht. Um dieses Szenario zu unterstützen, sollten Sie in die Validate-Methode eine Prüfung der Scalable-Eigenschaft integrieren. Wenn Scalable auf FALSE eingestellt ist, prüfen Sie, ob die Ressource in einer Failover-Ressourcengruppe konfiguriert ist.

Das Sun Cluster Konzepthandbuch für 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

Verwenden des TCP-Keep-Alive-Mechanismus für den Serverschutz

Wenn Sie auf Serverseite einen TCP-Keep-Alive-Mechanismus verwenden, wird der Server geschützt und es werden keine Systemressourcen für einen heruntergefahrenen (oder netzwerk-partitionierten) Client verschwendet. Wenn diese Ressourcen nicht auf einem Server bereinigt werden, der lange genug ausgeführt wird, wachsen die verschwendeten Ressourcen beim Absturz und Neustart von Clients endlos an.

Wenn für die Client-Server-Kommunikation ein TCP-Stream verwendet wird, 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.

Wenn auf Client-Seite TCP-Keep-Alive verwendet wird, wird der Client benachrichtigt, wenn für eine Netzwerkadressressource ein Failover oder Switchover von einem physikalischen Host an einen anderen stattfindet. 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 diesem Fall muss das TCP-Modul des Clients die Anforderung nicht ständig erneut übertragen. Außerdem ist die Client-Anwendung blockiert und wartet auf eine Antwort auf die Anforderung.

Die Client-Anwendung muss, wenn mögich, nicht nur den TCP-Keep-Alive-Mechanismus verwenden, sondern auch eigene Keep-Alives auf seiner Ebene durchführen. Der TCP-Keep-Alive-Mechanismus ist nicht in allen möglichen Grenzfällen die optimale Lösung. Wenn Sie einen Keep-Alive-Mechanismus auf Anwendungsebene verwenden, ist es in der Regel erforderlich, dass das Client-Server-Protokoll eine Null-Operation unterstützt oder zumindest eine effiziente schreibgeschützte Operation, wie z.B. eine Statusoperation.

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 Zugang zu einer Sun Cluster-Testkonfiguration, sodass die Tests die Produktionsmaschinen nicht beeinträchtigen.

Testen Sie, ob sich der HA-Datendienst in allen Fällen richtig verhält, in denen eine Ressourcengruppe zwischen den physikalischen 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 eine Anforderung für einen Client erfüllt. Datendienst A ist zum Beispiel von Datendienst B abhängig, wenn Datendienst B seinen Dienst bereitstellen muss, damit Datendienst A seinen Dienst bereitstellen kann. 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 die Ressourcen Ihres Ressourcentyps von einem anderen Typ abhängig sind, müssen Sie den Cluster-Administrator anweisen, die Ressourcen und Ressourcengruppen richtig zu konfigurieren. Liefern Sie als Alternative Skripts oder Tools für die richtige Konfiguration. Wenn die abhängige Ressource auf demselben Knoten wie die “depended-on”-Ressource ausgeführt werden muss, müssen beide Ressourcen in derselben Ressourcengruppe konfiguriert werden.

Entscheiden Sie, ob Sie ausdrückliche Ressourcenabhängigkeiten verwenden möchten oder ob Sie sie auslassen möchten und die Verfügbarkeit der anderen Datendienste im Code des HA-Datendienstes abfragen möchten. 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 das Abfragen erforderlich, weil eine Konfiguration der Ressourcenabhängigkeiten über mehrere Gruppen hinweg nicht möglich ist.

Einige Datendienste speichern die Daten nicht direkt selbst. Stattdessen sind sie von einem anderen Backend-Datendienst abhängig, der alle ihre Daten speichert. Ein solcher Datendienst überträgt alle Lese- und Aktualisierungsanforderungen in Aufrufe an den Backend-Datendienst. Stellen Sie sich zum Beispiel einen hypothetischen Client-Server-Terminkalenderdienst vor, der alle Daten in einer SQL-Datenbank, z.B. Oracle, speichert. 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. Anschließend können Sie einfache Methoden zum Starten und Stoppen des Terminkalender-Dämons schreiben. Der Cluster-Administrator registriert den Terminkalender-Ressourcentyp bei Sun Cluster.

Wenn die Terminkalenderanwendung auf demselben Knoten ausgeführt werden muss wie die Oracle-Datenbank, konfiguriert der Cluster-Administrator die Terminkalenderressource in derselben Ressourcengruppe wie die HA-ORACLE-Ressource und macht die Terminkalender-Ressource abhängig von der HA-ORACLE-Ressource. Diese Abhängigkeit wird mit dem Resource_dependencies-Eigenschaftstag in scrgadm angegeben.

Wenn die HA-ORACLE-Ressource auf einem anderen Knoten als die Terminkalenderressource ausgeführt werden kann, konfiguriert sie der Cluster-Administrator in zwei separate Ressourcengruppen. Der Cluster-Administrator könnte eine Ressourcengruppenabhängigkeit der Kalenderressourcengruppe in der Oracle-Ressourcengruppe konfigurieren. Ressourcengruppenabhängigkeiten sind jedoch nur dann effektiv, wenn beide Ressourcengruppen auf demselben Knoten gleichzeitig gestartet bzw. gestoppt werden. Daher kann der Kalender-Datendienstdämon nach dem Starten das Warten auf die Verfügbarkeit der Oracle-Datenbank aufrufen. In diesem Fall gibt die Start-Methode des Kalenderressourcentyps in der Regel Erfolg aus. Wenn die Start-Methode unendlich lange blockieren würde, würde diese Methode jedoch ihre Ressourcengruppe in einen "Besetzt"-Zustand versetzen. Dieser Zustand würde alle weiteren Zustandsänderungen verhindern, z.B. Bearbeitungen, Failover oder Switchover in der Gruppe. Wenn die Start-Methode der Kalenderressource jedoch die Zeit überschritten hat oder mit einem Nicht-Null-Status beendet wurde, kann dies zu einem "Ping-Pong" der Ressourcengruppe zwischen zwei oder mehr Knoten führen und die Oracle-Datenbank nicht mehr verfügbar sein.