Kapitel 4 Ändern eines Ressourcentyps

In diesem Kapitel werden die Themen beschrieben, mit denen Sie vertraut sein müssen, wenn Sie einen Ressourcentyp ändern möchten. Informationen über die Möglichkeiten zum Aktualisieren einer Ressource durch den Cluster-Administrator sind ebenfalls enthalten.

Dieses Kapitel behandelt die folgenden Themen:

• Überblick über das Ändern eines Ressourcentyps

• Erstellen des Inhalts der RTR-Datei

• Vorgänge beim Upgrade durch einen Cluster-Administrator

• Implementieren des Ressourcentyp-Monitor-Codes

• Ermitteln der Installationsanforderungen und Paketzusammenstellung

• Für einen geänderten Ressourcentyp bereitszustellende Dokumentation

Überblick über das Ändern eines Ressourcentyps

Die Cluster-Administratoren müssen folgende Aufgaben durchführen können:

• Installieren und Registrieren einer neuen Version eines bestehenden Ressourcentyps

• Zulassen der Registrierung von mehreren Versionen eines bestimmten Ressourcentyps

• Upgrade einer vorhandenen Ressource auf eine neue Version des Ressourcentyps, ohne die Ressource löschen und neu erstellen zu müssen

Ein Ressourcentyp, den Sie aktualisieren möchten, wird als Ressourcentyp mit Upgrade-Unterstützung bezeichnet. Elemente eines bestehenden Ressourcentyps, den Sie eventuell ändern möchten, sind:

• Attribute von Ressourcentypeigenschaften

• Der Satz von deklarierten Ressourceneigenschaften, einschließlich Standard- und Erweiterungseigenschaften

• Attribute von Ressourceneigenschaften, z.B. default, min, max, arraymin, arraymax oder tunability

• Der Satz von deklarierten Methoden

• Die Implementierung von Methoden oder Monitoren

Beim Ändern von Anwendungscode müssen Sie nicht notwendigerweise einen Ressourcentyp ändern.

Sie müssen die Voraussetzungen für die Bereitstellung von Tools kennen, mit denen ein Cluster-Administrator einen Ressourcentyp aktualisieren kann. In diesem Kapitel erfahren Sie, was Sie zum Einrichten dieser Tools benötigen.

Erstellen des Inhalts der RTR-Datei

Ressourcentypname

Die drei Komponenten eines Ressourcentypnamens sind Eigenschaften, die in der RTR-Datei als Hersteller-ID, Ressourcentyp und RT-Version angegeben sind. Der Befehl scrgadm fügt beim Erstellen eines Ressourcentyps den Punkt und Doppelpunkt ein:

Hersteller-ID.Ressourcentyp:RT-Version

Das Hersteller-ID-Präfix dient dazu, zwischen zwei Registrierungsdateien mit demselben Namen verschiedener Unternehmen zu unterscheiden. Um sicherzustellen, dass die Hersteller-ID einmalig ist, verwenden Sie beim Erstellen des Ressourcentyps das Börsensymbol des Unternehmens. Die RT-Version unterscheidet zwischen mehreren registrierten Versionen (Upgrades) desselben Basisressourcentyps.

Sie können den vollständig qualifizierten Ressourcentypnamen durch Eingabe des folgenden Befehls abrufen:

# scha_resource_get -O Type -R Ressourcenname -G Ressourcengruppenname

Ressourcentypnamen, die vor Sun Cluster 3.1 registriert wurden, verwenden weiterhin folgende Form:

Hersteller-ID.Ressourcentyp

Das Format von Ressourcentypnamen wird im Abschnitt Format von Ressourcentypnamen beschrieben.

Angeben der #$upgrade- und #$upgrade_from-Anweisungen

Um sicherzustellen, dass der Ressourcentyp, den Sie ändern, Upgrade-Unterstützung bietet, fügen Sie die #$upgrade-Anweisung in die RTR-Datei des Ressourcentyps ein. Fügen Sie nach der #$upgrade-Anweisung null oder mehrere #$upgrade_from-Anweisungen für jede frühere Version des Ressourcentyps ein, den Sie unterstützen möchten.

Die #$upgrade- und #$upgrade_from-Anweisungen müssen zwischen den Ressourcentyp-Eigenschaftsdeklarationen und den Ressourcendeklarationsabschnitten in der RTR-Datei stehen. Weitere Informationen finden Sie in der Online-Dokumentation zu rt_reg(4).

Beispiel 4–1 #$upgrade_from-Anweisung in einer RTR-Datei

#$upgrade_from   "1.1"   WHEN_OFFLINE
#$upgrade_from   "1.2"   WHEN_OFFLINE
#$upgrade_from   "1.3"   WHEN_OFFLINE
#$upgrade_from   "2.0"   WHEN_UNMONITORED
#$upgrade_from   "2.1"   ANYTIME
#$upgrade_from   ""      WHEN_UNMANAGED

Das Format der #$upgrade_from-Anweisung lautet wie folgt:

#$upgrade_from Version Optimierbarkeit

Version

Die RT_version. Geben Sie eine leere Zeichenkette an (“”), wenn ein Ressourcentyp keine Version aufweist, oder für andere Versionen als zuvor in der RTR-Datei definiert.

Optimierbarkeit

Die Bedingungen, unter denen der Cluster-Administrator die angegebene RT_version aktualisieren kann.

Verwenden Sie die folgenden Optimierbarkeitswerte in den #$upgrade_from-Anweisungen:

ANYTIME

Verwenden Sie diese Anweisung, wenn es keine Beschränkungen gibt, wann der Cluster-Administrator die Ressource aktualisieren kann. Die Ressource kann während des Upgrades vollständig online sein.

WHEN_UNMONITORED

Verwenden Sie diese Anweisung, wenn die Methoden der neuen Ressourcentypversion wie folgt lauten:

• Die Update-, Stop-, Monitor_check- und Postnet_stop-Methoden sind mit den älteren Startmethoden (Prenet_stop und Start) der Ressourcentypversion kompatibel

• Die Fini-Methode ist mit der Init-Methode älterer Versionen kompatibel

Der Cluster-Administrator muss lediglich das Ressourcen-Monitor-Programm vor dem Upgrade stoppen.

WHEN_OFFLINE

Verwenden Sie diese Anweisung, wenn die Update-, Stop-, Monitor_check- oder Postnet_stop-Methode Folgendes ist:

• Kompatibel mit der Init-Methode einer älteren Version

• Inkompatibel mit den Startmethoden (Prenet_stop und Start) einer älteren Ressourcentypversion

Der Cluster-Administrator muss die Ressource vor dem Upgrade offline nehmen.

WHEN_DISABLED

Ähnlich wie WHEN_OFFLINE. Der Cluster-Administrator muss die Ressource jedoch vor dem Upgrade deaktivieren.

WHEN_UNMANAGED

Verwenden Sie diese Anweisung, wenn die Fini-Methode der neuen Ressourcentypversion mit der Init-Methode einer älteren Version inkompatibel ist . Der Cluster-Administrator muss die vorhandene Ressourcengruppe vor dem Upgrade in den nicht verwalteten Zustand bringen.

Wenn in der Liste der #$upgrade_from-Anweisungen keine Version des Ressourcentyps erscheint, stellt RGM die Optimierbarkeit von WHEN_UNMANAGED standardmäßig auf diese Version ein.

AT_CREATION

Verwenden Sie diese Anweisung, um zu verhindern, dass vorhandene Ressourcen auf die neue Version des Ressourcentyps aktualisiert werden. Der Cluster-Administrator muss eine Ressource löschen und neu erstellen.

Ändern der RT_version in einer RTR-Datei

Sie müssen die RT_version -Eigenschaft in einer RTR-Datei nur dann ändern, wenn sich der Inhalt der RTR-Datei ändert. Wählen Sie für diese Eigenschaft einen Wert, der genau angibt, ob diese Version des Ressourcentyps die aktuellste ist.

Verwenden Sie in der Zeichenkette RT_version der RTR-Datei keines der folgenden Zeichen, da die Registrierung des Ressourcentyps sonst fehlschlägt:

• LEERTASTE

• TAB

• Schrägstrich (/)

• Umgekehrter Schrägstrich (\)

• Stern (*)

• Fragezeichen (?)

• Komma (,)

• Strichpunkt (;)

• Linke eckige Klammer ([)

• Rechte eckige Klammer (])

Die RT_version-Eigenschaft, die in Sun Cluster 3.0 optional war, ist ab Sun Cluster 3.1 verbindlich.

Ressourcentypnamen in früheren Versionen von Sun Cluster

Die Ressourcentypnamen in Sun Cluster 3.0 enthalten kein Versionssuffix, wie hier abgebildet:

Hersteller-ID.Ressourcentyp

Ein Ressourcentyp, der ursprünglich unter Sun Cluster 3.0 registriert war, hat weiterhin einen Namen, der dieser Syntax folgt, selbst nachdem der Cluster-Administrator die Cluster-Software auf Sun Cluster 3.1 oder höher aktualisiert. Ebenso erhält ein Ressourcentyp, in dessen RTR-Datei die #$upgrade-Anweisung fehlt, einen Namen im Sun Cluster 3.0-Format ohne Versionssuffix, wenn die RTR-Datei auf einem Cluster registriert ist, der mindestens mit Sun Cluster 3.1-Software läuft.

Der Cluster-Administrator kann RTR-Dateien mithilfe der #$upgrade-Anweisung oder der #$upgrade_from-Anweisung in Sun Cluster 3.0 registrieren. Ein Upgrade vorhandener Ressourcen auf neue Ressourcentypen in Sun Cluster 3.0 wird jedoch nicht unterstützt.

Vorgänge beim Upgrade durch einen Cluster-Administrator

Im Folgenden erfahren Sie, wie ein Cluster-Administrator vorgehen muss, wenn er einen Ressourcentyp aktualisiert:

• Wenn die vorhandenen Ressourceneigenschaftsattribute die Validierungsbedingungen der neuen Ressourcentypversion nicht erfüllen, muss der Cluster-Administrator gültige Werte angeben. Dies muss der Cluster-Administrator unter folgenden Bedingungen tun:

  • Wenn die neue Version des Ressourcentyps keinen Standardwert aufweist und eine Eigenschaft verwendet, die nicht in der früheren Version deklariert ist.

  • Wenn die vorhandene Ressource eine Eigenschaft verwendet, deren Wert in der neuen Version nicht deklariert oder ungültig ist. Deklarierte Eigenschaften, die in einer neuen Version eines Ressourcentyps nicht deklariert sind, werden aus der Ressource gelöscht.

• Jeder Versuch, ein Upgrade von einer nicht unterstützten Version eines Ressourcentyps vorzunehmen, scheitert.

• Nach einem Upgrade erben die Ressourcen die Ressourceneigenschaftsattribute für alle Eigenschaften aus der neuen Version des Ressourcentyps.

• Wenn Sie den Standardwert eines Ressourcentyps in der RTR-Datei ändern, wird der neue Standardwert von den bereits vorhandenen Ressourcen geerbt. Der neue Standardwert wird auch dann vererbt, wenn die Eigenschaft lediglich bei Erstellung AT_CREATION oder bei Deaktivierung WHEN_DISABLED als optimierbar deklariert ist. Eine Eigenschaft desselben Typs, die vom Cluster-Administrator erstellt wird, erbt auch diesen Standardwert. Wenn der Cluster-Administrator jedoch einen neuen Standardwert für die Eigenschaft angibt, überschreibt der neue Standardwert den in der RTR-Datei angegebenen Standardwert.

In Sun Cluster 3.0 erstellte Ressourcen erben keine neuen Standardressourcen-Eigenschaftsattribute vom Ressourcentyp, wenn ein Upgrade auf eine höhere Version von Sun Cluster erfolgt. Diese Beschränkung gilt nur für Sun Cluster 3.1-Cluster, für die ein Upgrade von Sun Cluster 3.0-Clustern erfolgt. Der Cluster-Administrator kann diese Beschränkung überwinden, indem er die Werte für die Eigenschaften angibt und so die Standardwerte überschreibt.

Implementieren des Ressourcentyp-Monitor-Codes

Der Cluster-Administrator kann einen Ressourcentyp mit Upgrade-Unterstützung in Sun Cluster 3.0 registrieren. Sun Cluster zeichnet jedoch den Ressourcentypnamen ohne Versionssuffix auf. Um korrekt sowohl in Sun Cluster 3.0 als auch in Sun Cluster 3.1 zu laufen, muss der Monitor-Code für diesen Ressourcentyp mit beiden Namenskonventionen umgehen können:

Hersteller-ID.Ressourcentyp:RT-Version
Hersteller-ID.Ressourcentyp

Das Format von Ressourcentypnamen wird im Abschnitt Format von Ressourcentypnamen beschrieben.

Der Cluster-Administrator kann dieselbe Ressourcentypversion nicht unter zwei verschiedenen Namen registrieren. Um zu ermöglichen, dass der Monitor-Code den richtigen Namen ermittelt, rufen Sie im Monitor-Code die folgenden Befehle auf:

scha_resourcetype_get -O RT_VERSION -T VEND.myrt
scha_resourcetype_get -O RT_VERSION -T VEND.myrt:vers

Vergleichen Sie die Ausgabewerte dann mit vers. Nur einer dieser Befehle ist für einen bestimmten Wert von vers erfolgreich.

Ermitteln der Installationsanforderungen und Paketzusammenstellung

Denken Sie an die folgenden zwei Anforderungen, wenn Sie die Installationsanforderungen und die Paketzusammenstellung für Ressourcentyppakete bestimmen:

• Bei der Registrierung eines neuen Ressourcentyps muss auf seine RTR-Datei auf der Platte zugegriffen werden können.

• Bei der Erstellung einer Ressource des neuen Typs müssen sich alle deklarierten Methodenpfadnamen sowie das Monitor-Programm für den neuen Typ auf der Platte befinden und ausführbar sein. Die alten Methoden- und Monitor-Programme müssen so lange an ihrem Platz bleiben, wie die Ressource in Verwendung ist.

Um die richtige Paketzusammenstellung zu bestimmen, beantworten Sie folgende Fragen:

• Wird die RTR-Datei geändert?

• Werden der Standardwert oder die Einstellbarkeit einer Eigenschaft geändert?

• Wird der min- oder max-Wert einer Eigenschaft geändert?

• Werden bei der Aufrüstung Eigenschaften hinzugefügt oder gelöscht?

• Wird der Monitor-Code geändert?

• Wird der Methodencode geändert?

• Sind die neuen Methoden, der Monitor-Code oder beides mit den früheren Versionen kompatibel?

Die Antworten auf diese Fragen helfen Ihnen, die richtige Paketzusammenstellung für den neuen Ressourcentyp zu bestimmen.

Bevor Sie die RTR-Datei ändern

Sie müssen nicht notwendigerweise eine neue Methode oder einen Monitor-Code erstellen, wenn Sie einen Ressourcentyp ändern. Zum Beispiel können Sie auch nur den Standardwert oder die Optimierbarkeit einer Ressourceneigenschaft ändern. In diesem Fall benötigen Sie lediglich einen neuen gültigen Pfadnamen einer lesbaren RTR-Datei, da Sie ja am Methodencode keine Änderungen vornehmen.

Wenn Sie den alten Ressourcentyp nicht erneut registrieren müssen, kann die neue RTR-Datei die frühere Version überschreiben. Stellen Sie die neue RTR-Datei andernfalls in einen neuen Pfad.

Wenn durch das Upgrade der Standardwert oder die Optimierbarkeit geändert wird, verwenden Sie die Validate-Methode für die neue Version des Ressourcentyps, um zu prüfen, ob die vorhandenen Eigenschaftsattribute für den neuen Ressourcentyp gültig sind. Falls nicht, kann der Cluster-Administrator die Eigenschaften einer bereits vorhandenen Ressource in die richtigen Werte ändern. Wenn durch das Upgrade die min-, max - oder type-Attribute einer Eigenschaft geändert werden, validiert der scrgadm-Befehl diese Beschränkungen automatisch, wenn der Cluster-Administrator den Ressourcentyp aktualisiert.

Wenn durch das Upgrade eine neue Eigenschaft hinzugefügt oder eine alte Eigenschaft gelöscht wird, müssen Sie wahrscheinlich die Rückmeldemethoden oder den Monitor-Code ändern.

Ändern von Monitor-Code

Wenn Sie lediglich den Monitor-Code für einen Ressourcentyp ändern, kann die Paketinstallation die Monitor-Binärdateien überschreiben.

Ändern von Methodencode

Wenn Sie lediglich den Methodencode in einem Ressourcentyp ändern, müssen Sie bestimmen, ob der neue Methodencode mit dem alten kompatibel ist. Die Antwort auf diese Frage bestimmt, ob der neue Methodencode in einem neuen Pfad gespeichert werden muss oder ob die alten Methoden überschrieben werden können.

Wenn Sie die neuen Stop-, Postnet_stop- und Fini-Methoden (falls deklariert) auf Ressourcen anwenden können, die von den alten Versionen der Start-, Prenet_stop - oder Init-Methoden initialisiert wurden, können die alten Methoden mit den neuen Methoden überschrieben werden.

Wenn die Anwendung eines neuen Standardwerts auf eine Eigenschaft dazu führt, dass eine Methode wie Stop, Postnet_stop oder Fini fehlschlägt, muss der Cluster-Administrator den Zustand der Ressource beim Upgrade des Ressourcentyps entsprechend beschränken.

Sie erlauben dem Cluster-Administrator die Beschränkung des Zustands der Ressource, wenn diese aktualisiert wird, indem die Optimierbarkeit der Type_version-Eigenschaft beschränkt wird.

Ein Ansatz bei der Paketzusammenstellung besteht darin, alle früheren Versionen eines Ressourcentyps zu berücksichtigen, für die das Paket weiterhin Unterstützung bietet. Bei diesem Ansatz kann die neue Paketversion die alte ersetzen, ohne dass die alten Methodenpfade überschrieben oder gelöscht werden. Sie müssen entscheiden, wie viele frühere Versionen unterstützt werden sollen.

Festlegen der zu verwendenden Paketzusammenstellungsmethode

Die folgende Tabelle enthält eine Übersicht über die Paketzusammenstellungsmethoden für Ihre neuen Ressourcentypen.

Für einen geänderten Ressourcentyp bereitszustellende Dokumentation

Anweisungen zum Upgrade eines Ressourcentyps finden Sie unter Upgrading a Resource Type in Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Um dem Cluster-Administrator ein Upgrade eines Ressourcentyps zu ermöglichen, den Sie ändern, ersetzen Sie diese Anweisungen durch zusätzliche Informationen, wie in diesem Abschnitt beschrieben.

Wenn Sie einen neuen Ressourcentyp erstellen, müssen Sie im Allgemeinen eine Dokumentation mitliefern, die Folgendes enthält:

• Eine Beschreibung der Eigenschaften, die Sie hinzufügen, ändern oder löschen

• Eine Beschreibung, wie die Eigenschaften den neuen Anforderungen entsprechen

• Eine Übersicht über die Optimierbarkeitsbeschränkungen von Ressourcen

• Eine Übersicht über alle neuen Standardeigenschaftsattribute

• Informationen für den Cluster-Administrator, wann er die vorhandenen Ressourceneigenschaften gegebenenfalls auf die richtigen Werte setzen kann

Vorbereitungen für die Installation eines Upgrades

Erklären Sie dem Cluster-Administrator, was er zu tun hat, bevor er das Upgrade-Paket auf einem Knoten installiert, wie folgt:

• Wenn durch das Upgrade-Paket bereits vorhandene Methoden überschrieben werden, weisen Sie den Cluster-Administrator an, den Knoten im Nicht-Cluster-Modus neu zu starten.

• Wenn durch das Upgrade-Paket lediglich der Monitor-Code aktualisiert wird und der Methodencode unverändert bleibt, teilen Sie dem Cluster-Administrator mit, dass der Knoten weiterhin im Cluster-Modus ausgeführt werden soll. Teilen Sie dem Cluster-Administrator ebenfalls mit, die Überwachung aller Ressourcentypen zu deaktivieren.

• Wenn durch das Upgrade-Paket lediglich die RTR-Datei aktualisiert wird und der Monitor- sowie der Methodencode unverändert bleiben, teilen Sie dem Cluster-Administrator mit, dass der Knoten weiterhin im Cluster-Modus ausgeführt werden soll. Teilen Sie dem Cluster-Administrator ebenfalls mit, die Überwachung aller Ressourcentypen aktiviert zu lassen.

Wann soll ein Ressourcen-Upgrade durchgeführt werden?

Erklären Sie dem Cluster-Administrator, wann er Ressourcen auf eine neue Version des Ressourcentyps aktualisieren kann. Die Bedingungen, unter denen der Cluster-Administrator den Ressourcentyp aktualisieren kann, richten sich wie folgt nach der Optimierbarkeit der #$upgrade_from -Anweisung für jede Version der Ressource in der RTR-Datei:

• Jederzeit (ANYTIME)

• Nur, wenn die Ressource nicht überwacht wird (WHEN_UNMONITORED)

• Nur, wenn die Ressource offline ist (WHEN_OFFLINE)

• Nur, wenn die Ressource deaktiviert ist (WHEN_DISABLED)

• Nur, wenn die Ressourcengruppe nicht verwaltet ist (WHEN_UNMANAGED )

Beispiel 4–2 Wie #$upgrade_from definiert, wann ein Cluster-Administrator ein Upgrade durchführen kann

In diesem Beispiel wird dargestellt, wie sich die Optimierbarkeit der #$upgrade_from-Anweisung auf die Bedingungen auswirkt, unter denen der Cluster-Administrator eine Ressource auf eine neue Version eines Ressourcentyps aktualisieren kann.

#$upgrade_from   "1.1"   WHEN_OFFLINE
#$upgrade_from   "1.2"   WHEN_OFFLINE
#$upgrade_from   "1.3"   WHEN_OFFLINE
#$upgrade_from   "2.0"   WHEN_UNMONITORED
#$upgrade_from   "2.1"   ANYTIME
#$upgrade_from   ""      WHEN_UNMANAGED

Informationen über die Änderungen von Ressourceneigenschaften

Beschreiben Sie alle Änderungen, die Sie am Ressourcentyp vorgenommen haben, für die der Cluster-Administrator Eigenschaften der bereits vorhandenen Ressourcen ändern muss, wenn er ein Upgrade ausführt. Mögliche Änderungen sind u.a.:

• Standardeinstellungen vorhandener Ressourcentypeigenschaften, die Sie geändert haben

• Neue Erweiterungseigenschaften des Ressourcentyps, den Sie eingeführt haben

• Bereits vorhandene Eigenschaften des Ressourcentyps, den Sie zurückgezogen haben

• Änderungen am Satz von Eigenschaften, die Sie für den Ressourcentyp deklariert haben

• Die Attribute von Ressourceneigenschaften, z.B. min, max, arraymin, arraymax, default und tunability, die Sie geändert haben

• Änderungen an dem Satz von Methoden, die Sie deklariert haben

• Implementierung von Methoden oder des Fehler-Monitors, die bzw. den Sie geändert haben