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:
Ermitteln der Installationsanforderungen und Paketzusammenstellung
Für einen geänderten Ressourcentyp bereitszustellende Dokumentation
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.
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.
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).
#$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
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.
Die Bedingungen, unter denen der Cluster-Administrator die angegebene RT_version aktualisieren kann.
Verwenden Sie die folgenden Optimierbarkeitswerte in den #$upgrade_from-Anweisungen:
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.
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.
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.
Ähnlich wie WHEN_OFFLINE. Der Cluster-Administrator muss die Ressource jedoch vor dem Upgrade deaktivieren.
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.
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.
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.
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.
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.
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.
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.
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.
Wenn Sie lediglich den Monitor-Code für einen Ressourcentyp ändern, kann die Paketinstallation die Monitor-Binärdateien überschreiben.
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.
Die folgende Tabelle enthält eine Übersicht über die Paketzusammenstellungsmethoden für Ihre neuen Ressourcentypen.
Tabelle 4–1 Festlegen der zu verwendenden Paketzusammenstellungsmethode
Änderungsart |
Optimierbarkeitswert |
Paketzusammenstellungsmethode |
---|---|---|
Eigenschaftsänderungen nur in der RTR-Datei vornehmen. |
ANYTIME |
Nur die neue RTR-Datei liefern. |
Die Methoden aktualisieren. |
ANYTIME |
Die aktualisierten Methoden in einen anderen Pfad als die alten Methoden stellen. |
Das neue Monitor-Programm installieren. |
WHEN_UNMONITORED |
Nur die frühere Version des Monitors überschreiben. |
Die Methoden aktualisieren. Die neuen Update- und Stop-Methoden sind mit den alten Start-Methoden inkompatibel. |
WHEN_OFFLINE |
Die aktualisierten Methoden in einen anderen Pfad als die alten Methoden stellen. |
Die Methoden aktualisieren und der RTR-Datei neue Eigenschaften hinzufügen. Die neuen Methoden benötigen neue Eigenschaften. Das Ziel besteht darin, der enthaltenen Ressourcengruppe zu erlauben, online zu bleiben, jedoch zu verhindern, dass sie online geht, wenn die Ressourcengruppe vom Offline-Zustand in den Online-Zustand wechselt. |
WHEN_DISABLED |
Die vorherigen Versionen der Methoden überschreiben. |
Die Methoden aktualisieren und der RTR-Datei neue Eigenschaften hinzufügen. Die neuen Methoden benötigen keine neue Eigenschaften. |
ANYTIME |
Die vorherigen Versionen der Methoden überschreiben. |
Die Methoden aktualisieren. Die neue Fini-Methode ist inkompatibel mit der alten Init-Methode. |
WHEN_UNMANAGED |
Die aktualisierten Methoden in einen anderen Pfad als die alten Methoden stellen. |
Die Methoden aktualisieren. An der RTR-Datei werden keine Änderungen vorgenommen. |
Nicht zutreffend. An der RTR-Datei werden keine Änderungen vorgenommen. |
Die vorherigen Versionen der Methoden überschreiben. Da Sie an der RTR-Datei keine Änderungen vorgenommen haben, muss die Ressource nicht registriert oder aktualisiert werden. |
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
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.
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 )
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
Version |
Wann der Cluster-Administrator ein Ressourcen-Upgrade durchführen kann |
---|---|
1.1, 1.2 oder 1.3 |
Nur, wenn die Ressource offline ist |
2.0 |
Nur, wenn die Ressource nicht überwacht ist |
2.1 |
Jederzeit |
Alle anderen Versionen |
Nur, wenn die Ressourcengruppe nicht verwaltet ist |
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