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.