Kapitel 3 Aufrüsten eines Ressourcentyps

Dieses Kapitel behandelt die Themen, die zum Aufrüsten eines Ressourcentyps und Migrieren einer Ressource bekannt sein müssen.

• Überblick

• Ressourcentyp-Registrierungsdatei

• Type_version-Ressourceneigenschaft

• Migrieren einer Ressource zu einer anderen Version

• Auf- und Abrüsten eines Ressourcentyps

• Standardeigenschaftswerte

• Ressourcentyp-Entwicklerdokumentation

• Ressourcentypnamens- und Ressourcentyp-Monitor-Implementierungen

• Anwendungsaufrüstungen

• Beispiele für Ressourcentypaufrüstungen

• Installationsanforderungen für Ressourcentyppakete

Überblick

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.

Ressourcentyp-Registrierungsdatei

Ressourcentypname

Die drei Komponenten des Resssourcentypnamens 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 ein Leerzeichen, Tabulator, Schrägstrich (/), umgekehrten Schrägstrich (\), Asterisk (*), Fragezeichen (?), Komma (,), Semicolon (;), linke eckige Klammer ([) oder rechte eckige Klammer (]) als Zeichen enthält.

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 erstellt wurden, verwenden weiterhin folgende Form:

vendor_id.resource_type

Anweisungen

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 Einstellbarkeitseinschränkung RT_Version 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).

Ändern von RT_Version in einer RTR-Datei

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 früheren Versionen von Sun Cluster

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 oder höhere Versionen 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 bzw. einer höheren Version 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.

Type_version-Ressourceneigenschaft

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:

Anytime

Wenn für die Aufrüstung einer Ressourcekene Einschränkungen vorhanden sind. Die Ressource kann vollständig online sein.

When_unmonitored

Wenn bekannt ist, dass dieUpdate-, Stop-, Monitor_check- und Postnet_stop-Methoden der neuen Ressourcentypversion mit den Startmethoden der älteren Ressourcentypversion kompatibel sind (Prenet_stop und Start), und wenn sichersteht, 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.

When_offline

Wenn bekannt ist, dass die Update, Stop, Monitor_check oder Postnet_stop-Methoden der neuen Ressourcentypversion nicht mit den Startmethoden der älteren Ressourcentypversion kompatibel sind (Prenet_stop und Start), jedoch mit der Init-Methode der älteren Versionen kompatibel sind, dann muss sich die Ressource zum Zeitpunkt der Typaufrüstung offline befinden.

When_disabled

Ähnlich wie When_offline. Dieser Einstellbarkeitswert erzwingt jedoch die stärkere Bedingung, dass die Ressource deaktiviert sein muss.

When_unmanaged

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.

At_creation

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.

Migrieren einer Ressource zu einer anderen Version

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, Standard und Einstellbarkeit 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.

Auf- und Abrüsten eines Ressourcentyps

Weitere Informationen zum Aufrüsten bzw. Migrieren eines Ressourcentyps finden Sie im Abschnitt “Upgrading a Resource Type” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

So rüsten Sie einen Ressourcentyp auf

1. In der Aufrüstungsdokumentation für den neuen Ressourcentyp finden Sie Informationen zu den Ressourcentypänderungen und Einschränkungen der Ressourceneinstellbarkeit.

2. 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.

3. 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

4. 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 Ressourcentyp -h Liste_installierter_Knoten

5. 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.

6. 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.

7. Der vorherige Zustand der Ressource bzw. der Ressourcengruppe wird durch Rückgängigmachen des in Schritt 5 aufgerufenen Befehls wiederhergestellt.

So rüsten Sie eine Ressource auf eine ältere Version des Ressourcentyps ab

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.

1. Bringen Sie die Ressourcengruppe mit der abzurüstenden Ressource offline.

   scswitch -F -g Ressourcengruppe

2. Deaktivieren Sie die Ressource, die abgerüstet werden soll, sowie alle weiteren Ressourcen in der Ressourcengruppe.

   scswitch -n -j aufzurüstende_Ressource scswitch -n -j Ressource1 scswitch -n -j Ressource2 scswitch -n -j Ressource3 ...

   ---

   Hinweis –

   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.

   ---

3. Beenden Sie die Verwaltung der Ressourcengruppe.

   scswitch -u -g Ressourcengruppe

4. 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 Ressourcentypname

5. Rüsten Sie die Ressource ab, indem Sie die alte Version für Type_version angeben.

   scrgadm -c -j abzurüstende_Ressource -y Type_version=alte_Version

   Bei Bedarf werden mit dem gleichen Befehl weitere Eigenschaften derselben Ressource auf die richtigen Werte eingestellt.

6. 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 Ressourcengruppe

Standardeigenschaftswerte

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 für eine aufgerüstete Version des Ressourcentyps ein neuer Standardwert für eine mit Standardwert versehene Eigenschaft deklariert wird, dann wird der neue Standardwert an die vorhandenen Ressourcen vererbt, auch wenn die Einstellbarkeit der Ressource nur als At_creation oder When_disabled 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.

Ressourcentyp-Entwicklerdokumentation

Der Ressourcentypentwickler muss für eine 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.

Ressourcentypnamens- und Ressourcentyp-Monitor-Implementierungen

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 und Sun Cluster 3.1 bzw. höheren Versionen 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.

Anwendungsaufrüstungen

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.

Beispiele für Ressourcentypaufrüstungen

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 Solaris-Paket 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 Ressourcentyp -f path_to_RTR_file

• 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 Solaris-Paket zu verwenden.

Installationsanforderungen für Ressourcentyppakete

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?

Erforderliche Informationen vor dem Ändern der RTR-Datei

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.

Ändern von Monitor-Code

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.

Ändern von Methodencode

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.