Dieses Kapitel behandelt die Themen, die zum Aufrüsten eines Ressourcentyps und Migrieren einer Ressource bekannt sein müssen.
Systemverwalter müssen in der Lage sein, eine neue Version eines vorhandenen Ressourcentyps zu installieren und zu registrieren, die Registrierung mehrerer Versionen eines bestimmten Ressourcentyps zuzulassen, und eine vorhandene Ressource zu einer neuen Version des Ressourcentyps zu migrieren, ohne dabei die Ressource löschen und neu erstellen zu müssen. Ressourcenentwickler müssen die Anforderungen für eine Ressourcentypaufrüstung und Ressourcenmigration verstehen.
Ressourcentypen, die für spätere Aufrüstungen geeignet sind, werden als aufrüstfähig bezeichnet.
Eine neue Version eines Ressourcentyps kann sich von einer vorherigen Version in mehreren Punkten unterscheiden:
Die Attribute der Ressourcentypeigenschaften können sich ändern.
Der Satz der deklarierten Ressourceneigenschaften, einschließlich Standard- und Erweiterungseigenschaften, kann sich ändern.
Die Attribute von Ressourceneigenschaften, wie default, min, max, arraymin, arraymax, oder die Einstellbarkeit können sich ändern.
Der Satz der deklarierten Methoden kann unterschiedlich sein.
Die Implementierung von Methoden oder Monitoren kann sich ändern.
Der Ressourcentypentwickler entscheidet, wann eine vorhandene Ressource zu einer neuen Version migrieren kann, und wählt dabei unter folgenden Einstellbarkeitsoptionen. Die Optionen werden von am wenigsten zu am stärksten einschränkend aufgelistet:
Jederzeit (Anytime),
Wenn die Ressource nicht überwacht ist (When_unmonitored),
Wenn die Ressource offline ist (When_offline),
Wenn die Ressource deaktiviert ist (When_disabled),
Wenn die Ressourcengruppe nicht verwaltet ist (When_unmanaged),
Bei Erstellung (At_creation).
Im gesamten Kapitel wird der scrgadm-Befehl verwendet, wenn die Ausführung einer Aufrüstung behandelt wird Der Verwalter kann jedoch neben dem scrgadm-Befehl auch die GUI oder den scsetup-Befehl verwenden, um die Aufrüstung auszuführen.
Die drei Komponenten des Ressourcentypnamens sind Eigenschaften, die in der RTR-Datei als Vendor_id, Resource_type und RT_version angegeben werden. Der scrgadm-Befehl fügt den Punkt und das Semikolon als Trennzeichen ein, um den Namen des Ressourcentyps zu erstellen:
vendor_id.resource_type:rt_version |
Das Präfix Vendor_id dient zur Unterscheidung zwischen zwei Registrierungsdateien des gleichen Namens, die von verschiedenen Herstellern geliefert werden. RT_version unterscheidet zwischen mehreren registrierten Versionen (Aufrüstungen) des gleichen Basisressourcentyps. Um sicherzustellen, dass Vendor_id einmalig ist, wird empfohlen, das Börsensymbol für das Unternehmen, das den Ressourcentyp erstellt, zu verwenden.
Die Registrierung des Ressourcentyps schlägt fehl, wenn die RT_version -Zeichenkette eines der folgenden Zeichen enthält: Leerzeichen, Tabulator, Schrägstrich (/), umgekehrter Schrägstrich (\), Sternchen (*), Fragezeichen (?), Komma (,), Semikolon (;), linke eckige Klammer ([) oder rechte eckige Klammer (]).
Die RT_Version-Eigenschaft, die in Sun Cluster 3.0 optional war, ist in Sun Cluster 3.1 verbindlich.
Der vollständig qualifizierte Name ist der Name, der von folgendem Befehl zurückgegeben wird:
scha_resource_get -O Type -R Ressourcenname -G Ressourcengruppenname |
Ressourcentypnamen, die vor Sun Cluster 3.1 registriert wurden, haben weiterhin folgende Form:
vendor_id.resource_type |
RTR-Dateien für aufrüstfähige Ressourcentypen müssen eine #$upgrade-Anweisung enthalten, gefolgt von Null oder mehr Anweisungen der Form:
#$upgrade_from Version Einstellbarkeit |
Die upgrade_from-Anweisung besteht aus der Zeichenkette #$upgrade_from, gefolgt von der RT_Version, gefolgt von der Einstellbarkeitseinschränkung für die Ressource. Wenn der aufzurüstende Ressourcentyp keine Version hat, wird RT_Version als leere Zeichenkette angegeben, wie im letzten Beispiel unten gezeigt.
#$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 |
RGM erzwingt diese Einschränkungen bei einer Ressource, wenn der Systemverwalter versucht, Type_version der Ressource zu ändern. Wenn die aktuelle Version des Ressourcentyps nicht in der Liste angezeigt wird, erzwingt RGM die Einstellbarkeit von When_unmanaged.
Diese Anweisungen müssen zwischen dem Abschnitt der Ressourcentyp-Eigenschaftsdeklarationen in der RTR-Datei und dem Abschnitt der Ressourcendeklarationen in der RTR-Datei stehen. Siehe rt_reg( 4).
Die RT_Version-Zeichenkette in einer RTR-Datei ist immer dann zu ändern, wenn sich der Inhalt der RTR-Datei ändert. Der Wert dieser Eigenschaft muss deutlich machen, welche die neuere und welche die ältere Version des Ressourcentyps ist. Eine Änderung der RT_Version-Zeichenkette ist nicht erforderlich, solange keine Änderungen in der RTR-Datei vorgenommen werden.
Ressourcentypnamen in Sun Cluster 3.0 enthielten kein Versionssuffix:
vendor_id.resource_name |
Ein Ressourcentyp, der ursprünglich unter Sun Cluster 3.0 registriert wurde, behält diese Form bei, auch wenn die Cluster-Software auf Sun Cluster 3.1 aufgerüstet wird. 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 mit Sun Cluster 3.1-Software läuft.
Sie können RTR-Dateien mit der #$upgrade- oder #$upgrade_from -Anweisung in Sun Cluster 3.0 registrieren. Das Migrieren vorhandener Ressourcen zu neuen Ressourcentypen in Sun Cluster 3.0 wird jedoch nicht unterstützt.
Die Standardressourceneigenschaft Type_version speichert die RT_Version-Eigenschaft eines Ressourcentyps. Diese Eigenschaft ist nicht in der RTR-Datei vorhanden. Der Systemverwalter bearbeitet diesen Eigenschaftswert mithilfe des folgenden Befehls:
scrgadm -c -j Ressource -y Type_version=neue_Version |
Die Einstellbarkeit dieser Eigenschaft ergibt sich aus:
Der aktuellen Version des Ressourcentyps,
Den #$upgrade_from-Anweisungen in der RTR-Datei.
Verwenden Sie die folgenden Einstellbarkeitswerte in den #$upgrade_from-Anweisungen:
Wenn keine Einschränkungen der Aufrüstungszeitpunkte für die Ressource vorliegen. Die Ressource kann vollständig online sein.
Wenn bekannt ist, dass die Methoden Update, Stop, Monitor_check und Postnet_stop des neuen Ressourcentyps mit den Start-Methoden älterer Ressourcentypversionen kompatibel sind (Prenet_stop und Start), und wenn bekannt ist, dass die Fini-Methode der neuen Ressourcentypversion mit der Init-Methode der älteren Versionen kompatibel ist. Für dieses Szenario ist lediglich erforderlich, dass das Ressourcen-Monitor-Programm vor der Aufrüstung gestoppt wird.
Wenn die Inkompatibilität der Update, Stop, Monitor_check bzw. Postnet_stop-Methoden der neuen Ressourcentypversion mit den Start-Methoden von älteren Ressourcentypversionen (Prenet_stop und Start) bekannt ist, jedoch ebenso bekannt ist, dass sie mit der Init-Methode älterer Versionen kompatibel sind, muss die Ressource während der Typaufrüstung offline sein.
Ähnlich wie When_offline. Dieser Einstellbarkeitswert erzwingt jedoch die stärkere Bedingung, dass die Ressource deaktiviert sein muss.
Wenn die Fini-Methode der neuen Ressourcentypversion nicht mit der Init-Methode der älteren Versionen kompatibel ist. Dieser Einstellbarkeitswert erfordert, dass die vorhandene Ressourcengruppe in den nicht verwalteten Zustand versetzt wird, bevor Sie die Ressource aufrüsten können.
Wenn Ressourcen nicht auf die neue Ressourcentypversion aufgerüstet werden können. Nur neue Ressourcen können mit der neuen Version erstellt werden.
Die Einstellbarkeit von At_creation bedeutet, dass der Ressourcentypentwickler die Migration einer vorhandenen Ressource zu dem neuen Typ verbieten kann. In diesem Fall muss der Systemverwalter die Ressource löschen und neu erstellen. Dies ist äquivalent mit der Deklaration, dass die Ressourcenversion nur zum Zeitpunkt der Erstellung eingestellt werden kann.
Eine vorhandene Ressource nimmt die neue Ressourcentypversion an, wenn der Systemverwalter die Type_version-Eigenschaft der Ressource bearbeitet. Dabei werden die gleichen Konventionen wie bei der Bearbeitung anderer Ressourceneigenschaften beachtet, mit der Ausnahme, dass einige Informationen von der neuen Ressourcentypversion abgeleitet bzw. übernommen werden statt von der aktuellen Version.
Ressourceneigenschaftsattribute für alle Eigenschaften wie min, max, arraymin, arraymax, default, und tunability werden von der neuen Ressourcentypversion übernommen.
Die Einstellbarkeit, die auf die Type_version-Eigenschaft angewendet wird, wird aus den #$upgrade_from-Anweisungen in der RTR-Datei und der RT_Version-Eigenschaft des Ressourcentyps für die vorhandene Ressource übernommen. Diese Einstellbarkeit weicht von der unter property_attributes(5) beschriebenen Einstellbarkeit ab.
Die Validate-Methode für die neue Ressourcentypversion wird angewendet. So wird sichergestellt, dass die Eigenschaftsattribute für den neuen Ressourcentyp gültig sind. Wenn die vorhandenen Ressourceneigenschaftsattribute nicht für die Validierungsbedingungen der neuen Ressourcentypversion ausreichen, muss der Systemverwalter gültige Werte für diese Eigenschaften an der scrgadm-Befehlszeile eingeben. Dieser Fall kann eintreten, wenn die neuere Ressourcentypversion eine Eigenschaft verwendet, die in der früheren Version nicht deklariert war und die keinen Standardwert hat. Zudem kann er eintreten, wenn die vorhandene Ressource bereits über eine Eigenschaft verfügt, der ein Wert zugewiesen wurde, der für die neuere Ressourcentypversion ungültig ist.
Die Deklaration von Ressourceneigenschaften, die in einer älteren Ressourcentypversion deklariert wurden, kann in der neueren Version aufgehoben werden. Wenn die Ressource zu einer neueren Version migriert, wird die Eigenschaft aus der Ressource gelöscht.
Die Validate-Methode kann die aktuelle Type_version der Ressource mithilfe von scha_resource_get abfragen, ebenso wie die neue Type_version, die an der Validate-Befehlszeile eingegeben wird. Daher kann Validate Aufrüstungen von nicht unterstützten Versionen ausschließen.
Weitere Informationen zum Aufrüsten bzw. Migrieren eines Ressourcentyps finden Sie im Abschnitt “Upgrading a Resource Type” in Sun Cluster 3.1 Data Service Planning and Administration Guide.
In der Aufrüstungsdokumentation für den neuen Ressourcentyp finden Sie Informationen zu den Ressourcentypänderungen und Einschränkungen der Ressourceneinstellbarkeit.
Installieren Sie das Aufrüstungspaket für den Ressourcentyp auf allen Cluster-Knoten.
Die empfohlene Vorgehensweise für das Installieren von neuen Ressourcentyppaketen ist eine laufende Aufrüstung:pkgadd wird ausgeführt, während der Knoten im Nicht-Cluster-Modus gebootet wird.
In einigen Fällen wäre es möglich, neue Ressourcentyppakete auf einem Knoten in Cluster-Modus zu installieren:
Wenn der Methodencode durch die Ressourcentyp-Paketinstallation keinen Änderungen unterliegt und nur der Monitor aktualisiert wird, muss die Überwachung aller Ressourcen dieses Typs während der Installation gestoppt werden.
Wenn die Ressourcentyp-Paketinstallation weder den Methoden- noch den Monitor-Code ändert, muss die Überwachung der Ressource während der Installation nicht gestoppt werden, da die Installation lediglich eine neue RTR-Datei auf der Platte ablegt.
Registrieren Sie die neue Ressourcentypversion mit dem scrgadm-Befehl bzw. einem äquivalenten Befehl, womit auf die RTR-Datei der Aufrüstung verwiesen wird.
RGM erstellt einen neuen Ressourcentyp, dessen Name folgende Form hat:
vendor_id.resource_type:version |
Wenn die Ressourcentypaufrüstung nur auf einer Untermenge der Knoten installiert ist, müssen Sie die Installed_nodes-Eigenschaft des neuen Ressourcentyps auf die Knoten einstellen, auf denen die Aufrüstung tatsächlich installiert ist.
Wenn eine Ressource den neuen Typ übernimmt (entweder, weil sie neu erstellt wird oder weil sie aufgerüstet wurde), ist es für RGM erforderlich, dass die Ressourcengruppen-nodelist eine Untermenge der Installed_nodes-Liste des Ressourcentyps ist.
scrgadm -c -t Resource_type -h Liste_installierter_Knoten |
Für jede Ressource vom nicht aufgerüsteten Typ, die zum aufgerüsteten Typ migriert werden soll, muss scswitch aufgerufen werden, um den Zustand der Ressource bzw. deren Ressourcengruppe in denjenigen Zustand zu ändern, der von der Aufrüstungsdokumentation vorgeschrieben wird.
Bearbeiten Sie jede Ressource des nicht aufgerüsteten Typs, die zum aufgerüsteten Typ migriert werden soll, indem Sie die Type_version-Eigenschaft in die neue Version ändern.
scrgadm -c -j Ressource -y Type_version=neue_Version |
Bei Bedarf werden mit dem gleichen Befehl weitere Eigenschaften derselben Ressource auf die richtigen Werte eingestellt.
Der vorherige Zustand der Ressource bzw. der Ressourcengruppe wird durch Rückgängigmachen des in Schritt 5 aufgerufenen Befehls wiederhergestellt.
Sie können eine Ressource auf eine ältere Version ihres Ressourcentyps abrüsten. Die Bedingungen, unter denen Sie eine Ressource auf eine ältere Version des Ressourcentyps abrüsten können, sind stärker einschränkend als diejenigen für die Aufrüstung auf eine neuere Version des Ressourcentyps. Zunächst müssen Sie die Ressourcengruppe in einen nicht verwalteten Zustand versetzen. Außerdem können Sie eine Ressource nur zu einer aufrüstungsfähigen Version des Ressourcentyps abrüsten. Aufrüstungsfähige Versionen werden mithilfe des scrgadm -p-Befehls identifiziert. In der Ausgabe enthalten aufrüstungsfähige Versionen das Suffix :Version.
Bringen Sie die Ressourcengruppe mit der abzurüstenden Ressource offline.
scswitch -F -g resource_group |
Deaktivieren Sie die Ressource, die abgerüstet werden soll, sowie alle weiteren Ressourcen in der Ressourcengruppe.
scswitch -n -j resource_to_downgrade scswitch -n -j resource1 scswitch -n -j resource2 scswitch -n -j resource3 ... |
Deaktivieren Sie die Ressourcen in der Reihenfolge ihrer Abhängigkeit, wobei Sie mit den am stärksten abhängigen Ressourcen (Anwendungsressourcen) beginnen und mit den am wenigsten abhängigen Ressourcen (Netzwerkadressressourcen) enden.
Beenden Sie die Verwaltung der Ressourcengruppe.
scswitch -u -g resource_group |
Ist die alte Version des Ressourcentyps, auf den Sie abrüsten möchten, noch im Cluster registriert?
Wenn ja, gehen Sie zum nächsten Schritt.
Wenn nicht, registrieren Sie die gewünschte alte Version erneut.
scrgadm -a -t resource_type_name |
Rüsten Sie die Ressource ab, indem Sie die alte Version für Type_version angeben.
scrgadm -c -j resource_to_downgrade -y Type_version=old_version |
Bei Bedarf werden mit dem gleichen Befehl weitere Eigenschaften derselben Ressource auf die richtigen Werte eingestellt.
Bringen Sie die Ressourcengruppe mit der abgerüsteten Ressource in einen verwalteten Zustand, aktivieren Sie alle Ressourcen, und bringen Sie die Gruppe online.
scswitch -Z -g resource_group |
RGM speichert alle Ressourcen so, dass jede Eigenschaft, die nicht explizit vom Systemverwalter eingestellt (und mit einem Standardwert versehen) wurde, nicht im Ressourceneintrag im CCR (Cluster Configuration Repository, Cluster-Konfigurations-Repository) gespeichert wird. RGM ruft den Standardwert für eine fehlende Ressourceneigenschaft aus dem Ressourcentyp ab. Wenn darin kein Wert definiert ist, wird ein systemdefinierter Standardwert verwendet), wenn eine Ressource vom CCR gelesen wird. Mittels dieser Methode der Eigenschaftsspeicherung kann ein aufgerüsteter Ressourcentyp neue Eigenschaften bzw. neue Standardwerte für vorhandene Eigenschaften definieren.
Wenn Ressourceneigenschaften bearbeitet werden, speichert RGM im CCR diejenigen Eigenschaften, die im Edit-Befehl angegeben wurden.
Wenn eine aufgerüstete Version des Ressourcentyps einen neuen Standardwert für eine Eigenschaft mit Standardwert deklariert, wird der neue Standardwert von den vorhandenen Ressourcen übernommen, selbst wenn die Eigenschaft nur für At_creation oder When_disabled als einstellbar deklariert wurde. Wenn die Anwendung des neuen Standardwerts bedeuten würde, dass eine Methode wie Stop, Postnet_stop oder Fini fehlschlägt, muss die Person, die den Ressourcentyp implementiert, den Zustand der Ressource bei der Aufrüstung entsprechend einschränken. Dies geschieht durch Einschränken der Einstellbarkeit der Type_version-Eigenschaft.
Die Validate-Methode der neuen Ressourcentypversion kann prüfen, ob die vorhandenen Eigenschaftsattribute geeignet sind. Wenn dies nicht der Fall ist, kann der Systemverwalter die Eigenschaften einer vorhandenen Ressource auf die geeigneten Werte einstellen, und zwar mit dem gleichen Befehl, mit dem die Type_version-Eigenschaft bearbeitet wird, um die Ressource auf die neue Ressourcentypversion aufzurüsten.
Ressourcen, die unter Sun Cluster 3.0 erstellt wurden, übernehmen nicht automatisch neue Standardeigenschaftswerte vom Ressourcentyp, wenn sie zu einer höheren Version migriert werden, da ihre Standardeigenschaften im CCR gespeichert sind.
Der Ressourcentypentwickler muss für die neue Ressource Dokumentation bereitstellen, die folgende Informationen enthält:
Beschreibung aller hinzugefügten, geänderten oder gelöschten Eigenschaften,
Beschreibung, wie die Eigenschaften den neuen Anforderungen angepasst werden können,
Angabe der Einstellbarkeitseinschränkungen für die Ressourcen,
Hervorheben aller neuen Standardeigenschaftsattribute,
Hinweis an den Systemverwalter, dass sich die vorhandenen Ressourceneigenschaften mit dem gleichen Befehl auf die geeigneten Werte einstellen lassen, der für die Bearbeitung der Type_version-Eigenschaft verwendet wird, um die Ressource auf die neue Ressourcentypversion aufzurüsten.
Sie können einen aufrüstungsfähigen Ressourcentyp unter Sun Cluster 3.0 registrieren. Sein Name wird jedoch im CCR ohne Versionssuffix gespeichert. Um korrekt sowohl in Sun Cluster 3.0 als auch in Sun Cluster 3.1 zu laufen, muss der Monitor für diesen Ressourcentyp mit beiden Namenskonventionen umgehen können:
vendor_id.resource_name:version vendor_id.resource_name |
Der Monitor-Code kann den richtigen zu verwendenden Namen bestimmen, indem ein dem Folgenden entsprechender Befehl ausgeführt wird:
scha_resourcetype_get -O RT_VERSION -T VEND.myrt scha_resourcetype_get -O RT_VERSION -T VEND.myrt:vers |
Dann werden die Ausgabewerte mit vers verglichen. Nur einer dieser Befehle ist für einen bestimmten Wert von vers erfolgreich, da dieselbe Version eines Ressourcentyps nicht zweimal unter verschiedenen Namen registriert werden kann.
Die Aufrüstung von Anwendungscode weicht von der Aufrüstung des Agenten-Codes ab, auch wenn sich einige der Schritte gleichen. Eine Anwendungsaufrüstung kann, muss jedoch nicht, mit einer Ressourcentypaufrüstung kombiniert werden.
Diese Beispiele zeigen mehrere unterschiedliche Szenarios für die Ressourcentypinstallation und -aufrüstung. Die Einstellbarkeits- und Paketinformationen wurden anhand der Änderungstypen ausgewählt, die an der Ressourcentypimplementierung vorgenommen werden. Die Einstellbarkeit bezieht sich auf die Migration der Ressource zum neuen Ressourcentyp.
Alle Beispiele gehen von folgenden Annahmen aus:
Der Ressourcentyp wird in einem Paket im Stil von Solaris geliefert. Siehe pkgadd(1M) und pkgrm(1M).
Es ist nur eine vorherige Version des Ressourcentyps vorhanden, und daher enthält die neue RTR-Datei nur eine #$upgrade_from-Anweisung.
Das Installationsverfahren entfernt bzw. überschreibt keine Methoden, wenn die Möglichkeit besteht, dass RGM diese Methoden während der Entfernung von der Platte aufruft.
Neue Methoden sind mit den alten Methoden kompatibel, sofern nicht anders angegeben.
Ressourcen und Ressourcengruppen werden vor der Installation bzw. Migration mithilfe des Befehls scswitch(1M) oder eines äquivalenten Befehls in den erforderlichen Zustand versetzt. Das folgende Beispiel zeigt, wie die Ressourcengruppe in einen nicht verwalteten Zustand versetzt wird:
scswitch -M -n -j Ressource scswitch -n -j Ressource scswitch -F -g Ressourcengruppe scswitch -u -g Ressourcengruppe |
Der Ressourcentyp wird mit folgendem Befehl registriert:
scrgadm -a -t resource_type -f Pfad_zur_RTR_Datei |
Eine Ressource wird mit folgendem Befehl migriert:
scrgadm -c -j Ressource -y Type_version=Version \ -y Eigenschaft=Wert \ -x Eigenschaft=Wert ... |
Ressourcen und Ressourcengruppen werden nach der Migration wieder in ihren vorherigen Zustand zurückversetzt. Dies geschieht über den Befehl scswitch(1M) bzw. einen äquivalenten Befehl.
scswitch -M -e -j Ressource scswitch -e -j Ressource scswitch -o -g Ressourcengruppe scswitch -Z -g Ressourcengruppe |
Der Ressourcentypentwickler muss möglicherweise stärker eingeschränkte Einstellbarkeitswerte angeben als die in diesen Beispielen verwendeten Werte. Die Einstellbarkeitswerte sind abhängig von den genauen Änderungen, die an der Ressourcentypimplementierung vorgenommen werden. Ebenso kann sich der Ressourcentypentwickler dafür entscheiden, ein anderes Paketschema als das in diesen Beispielen eingesetzte Paket im Solaris-Stil zu verwenden.
Tabelle 3–1 Beispiele für das Aufrüsten eines Ressourcentyps
Änderungstyp |
Einstellbarkeit |
Paket |
Verfahren |
---|---|---|---|
Eigenschaftsänderungen werden nur in der RTR-Datei vorgenommen. |
Anytime |
Liefern Sie nur die neue RTR-Datei. |
Führen Sie pkgadd für die neue RTR-Datei auf allen Knoten aus. Registrieren Sie den neuen Ressourcentyp. Migrieren Sie die Ressource. |
Die Methoden werden aktualisiert. |
Anytime |
Legen Sie die aktualisierten Methoden unter einem anderen Pfad als die alten Methoden ab. |
Führen Sie pkgadd für die aktualisierten Methoden auf allen Knoten aus. Registrieren Sie den neuen Ressourcentyp. Migrieren Sie die Ressource. |
Neues Monitor-Programm. |
When_unmonitored |
Überschreiben Sie nur die vorherige Version des Monitors. |
Deaktivieren Sie die Überwachung. Führen Sie pkgadd für das neue Monitor-Programm auf allen Knoten aus. Registrieren Sie den neuen Ressourcentyp. Migrieren Sie die Ressource. Aktivieren Sie die Überwachung. |
Die Methoden werden aktualisiert. Die neuen Update-/Stop-Methoden sind inkompatibel mit den alten Start-Methoden. |
When_offline |
Legen Sie die aktualisierten Methoden unter einem anderen Pfad als die alten Methoden ab. |
Führen Sie pkgadd für die aktualisierten Methoden auf allen Knoten aus. Registrieren Sie den neuen Ressourcentyp. Nehmen Sie die Ressource offline. Migrieren Sie die Ressource. Bringen Sie die Ressource online. |
Die Methoden werden aktualisiert und die neuen Eigenschaften der RTR-Datei hinzugefügt. Die neuen Methoden benötigen neue Eigenschaften. (Ziel ist es, der betroffenen Ressourcengruppe das Online-bleiben zu ermöglichen, gleichzeitig jedoch zu verhindern, dass die Ressource online gebracht wird, wenn die Ressourcengruppe auf einem Knoten von einem Offline- in einen Online-Zustand übergeht.) |
When_disabled |
Überschreiben Sie die vorherigen Versionen der Methoden. |
Deaktivieren Sie die Ressource.
Registrieren Sie den neuen Ressourcentyp. Migrieren Sie die Ressource. Aktivieren Sie die Ressource. |
Die Methoden werden aktualisiert und die neuen Eigenschaften der RTR-Datei hinzugefügt. Die neuen Methoden benötigen keine neue Eigenschaften. |
Anytime |
Überschreiben Sie die vorherigen Versionen der Methoden. |
Während dieses Vorgangs ruft RGM die neuen Methoden auf, auch wenn die Migration, durch die die neuen Eigenschaften konfiguriert werden, noch nicht ausgeführt wurde. Die neuen Methoden müssen unbedingt in der Lage sein, ohne die neuen Eigenschaften zu funktionieren. Registrieren Sie den neuen Ressourcentyp. Migrieren Sie die Ressource. |
Die Methoden werden aktualisiert. Die neue Fini-Methode ist inkompatibel mit der alten Init-Methode. |
When_unmanaged |
Legen Sie die aktualisierten Methoden unter einem anderen Pfad als die alten Methoden ab. |
Bringen Sie die betreffende Ressourcengruppe in einen unverwalteten Zustand. Führen Sie pkgadd für die aktualisierten Methoden auf allen Knoten aus. Registrieren Sie den Ressourcentyp. Migrieren Sie die Ressource. Versetzen Sie die betreffende Ressourcengruppe in einen verwalteten Zustand. |
Die Methoden werden aktualisiert. An der RTR-Datei werden keine Änderungen vorgenommen. |
Nicht zutreffend. An der RTR-Datei werden keine Änderungen vorgenommen. |
Überschreiben Sie die vorherigen Versionen der Methoden. |
Da an der RTR-Datei nichts geändert wurde, muss die Ressource nicht registriert oder migriert werden. |
Bezüglich der Installation neuer Ressourcentyppakete gibt es zwei Anforderungen:
Wenn ein neuer Ressourcentyp registriert wird, muss der Zugriff auf dessen RTR-Datei auf der Platte möglich sein.
Wenn eine Ressource des neuen Typs erstellt wird, müssen sich alle deklarierten Methodenpfadnamen und 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.
Bei der Entscheidung über das am besten geeignete Paket muss der Ressourcentypimplementierer folgende Punkte in Betracht ziehen:
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 Methodencode geändert?
Wird der Monitor-Code geändert?
Sind die neuen Methoden- bzw. Monitor-Codes mit der vorherigen Version kompatibel?
Einige Ressourcentypaufrüstungen sind nicht mit neuem Methoden- oder Monitor-Code verbunden. So kann zum Beispiel bei einer Ressourcentypänderung nur der Standardwert oder die Einstellbarkeit einer Ressourceneigenschaft geändert werden. Da der Methodencode nicht geändert wird, ist die einzige Anforderung für die Installation der Aufrüstung ein gültiger Pfadname zu einer lesbaren RTR-Datei.
Wenn der alte Ressourcentyp nicht erneut registriert werden muss, kann die neue RTR-Datei die vorherige Version überschreiben. Andernfalls kann die neue RTR-Datei unter einem neuen Pfadnamen abgelegt werden.
Wenn die Aufrüstung den Standardwert oder die Einstellbarkeit einer Eigenschaft ändert, kann die Validate-Methode für die neue Version beim Migrieren feststellen, ob die vorhandenen Eigenschaftsattribute für den neuen Ressourcentyp gültig sind. Wenn die Aufrüstung das min, max- oder type-Attribut einer Eigenschaft ändert, validiert der scrgadm-Befehl zum Zeitpunkt der Migration automatisch diese Einschränkungen.
Die Aufrüstungsdokumentation muss alle neuen Standardeigenschaftsattribute hervorheben. Die Dokumentation muss den Systemverwalter darüber informieren, dass sich die vorhandenen Ressourceneigenschaften mit dem gleichen Befehl auf die geeigneten Werte einstellen lassen, der für die Bearbeitung der Type_version-Eigenschaft verwendet wird, um die Ressource auf die neue Ressourcentypversion aufzurüsten.
Wenn bei der Aufrüstung Eigenschaften hinzugefügt oder gelöscht werden, müssen wahrscheinlich auch einige Rückmeldemethoden oder Monitor-Code geändert werden.
Wenn der Monitor-Code die einzige Änderung an dem aktualisierten Ressourcentyp ist, kann die Paketinstallation die Monitor-Binärdateien überschreiben. Die Dokumentation muss den Systemverwalter anweisen, die Überwachung vor Installation des neuen Pakets aufzuheben.
Wenn der Methodencode die einzige Änderung an dem aktualisierten Ressourcentyp ist, muss festgestellt werden, ob der neue Methodencode mit der vorherigen Version kompatibel ist. Davon hängt ab, ob der neue Methodencode unter einem neuen Pfadnamen abgelegt werden muss oder ob die alten Methoden überschrieben werden können.
Wenn die neuen Stop-, Postnet_stop- und Fini-Methoden (falls deklariert) auf die Ressourcen angewendet werden können, die mit den alten Versionen der Start-, Prenet_stop- oder Init-Methoden initialisiert bzw. gestartet wurden, können die alten Methoden mit den neuen Methoden überschrieben werden.
Wenn der neue Methodencode nicht mit der vorherigen Version kompatibel ist, müssen die Ressourcen, welche die alten Methodenversionen verwenden, gestoppt bzw. dekonfiguriert werden, bevor sie zum aufgerüsteten Ressourcentyp migriert werden können. Wenn die neuen Methoden die alten Methoden überschreiben, müssen möglicherweise alle Ressourcen des Typs heruntergefahren und gegebenenfalls in einen nicht verwalteten Zustand versetzt werden, bevor die Ressourcentypaufrüstung ausgeführt wird. Wenn die neuen Methoden getrennt von den alten Methoden gespeichert werden und auf beide gleichzeitig zugegriffen werden kann, dann ist es auch ohne Abwärtskompatibilität möglich, die neue Ressourcentypversion zu installieren und die Ressourcen nacheinander aufzurüsten.
Auch wenn die neuen Methoden abwärtskompatibel sind, kann es erforderlich sein, jeweils nur eine Ressource für die Verwendung der neuen Methoden aufzurüsten, während die restlichen Ressourcen weiterhin die alten Methoden verwenden. Auch in diesem Fall müssen die neuen Methoden in einem getrennten Verzeichnis gespeichert werden, anstatt die alten Methoden zu überschreiben.
Ein Vorteil beim Speichern der Methoden pro Ressourcentyp in einem eigenen Verzeichnis ist, dass Ressourcen leicht zur älteren Ressourcentypversion zurückgewechselt werden können, wenn mit der neuen Version ein Problem auftritt.
Ein Ansatz für Pakete besteht darin, alle früheren Versionen, die noch unterstützt werden, in das Paket mit aufzunehmen. So kann die neue Paketversion die ältere Version ersetzen, ohne die alten Methodenpfade zu überschreiben oder zu löschen. Der Ressourcentypentwickler muss entscheiden, wie viele frühere Versionen unterstützt werden sollen.
Es wird davon abgeraten, Methoden oder pkgrm-/pkgadd-Methoden auf einem Knoten zu überschreiben, der sich aktuell im Cluster befindet. Falls RGM eine Methode aufruft, während auf die Methode auf der Platte nicht zugegriffen werden kann, kann dies zu unerwarteten Ergebnissen führen. Auch das Entfernen oder Ersetzen der Binärdatei einer laufenden Methode kann zu unerwarteten Ergebnissen führen.