Chapitre 3 Mise à niveau d'un type de ressources

Ce chapitre offre une vision globale des connaissances requises pour mettre à niveau un type de ressources et migrer une ressource.

• Présentation générale

• Fichier RTR (Resource Type Registration)

• Propriété de ressources Version_type

• Migration d'une ressource vers une version différente

• Mise à niveau ou adaptation vers une version antérieure d'un type de ressources

• Valeur par défaut des propriétés

• Informations à fournir par le développeur de type de ressources

• Mise en oeuvre du nom et du détecteur du type de ressources

• Mises à niveau de l'application

• Exemples de mise à niveau d'un type de ressources

• Conditions requises pour l'installation des packages de type de ressources

Présentation générale

Les administrateurs système doivent pouvoir installer et enregistrer une nouvelle version d'un type de ressources existant, pour permettre l'enregistrement de plusieurs versions d'un type de ressources donné et la migration d'une ressource existante vers une nouvelle version du type de ressources sans devoir ni supprimer, ni recréer la ressource. Les développeurs de ressources doivent maîtriser les exigences requises pour permettre la mise à niveau d'un type de ressources et la migration des ressources.

Lorsqu'un type de ressources est conçu dans le but de pouvoir être mis à niveau, il est dit qu'il prend en charge des mises à niveau.

La nouvelle version d'un type de ressources peut s'avérer sensiblement différente de la version antérieure. Voici la liste des caractéristiques qui ont pu être modifiées :

• les attributs de propriétés du type de ressources ;

• l'ensemble des propriétés de ressources déclarées, y compris les propriétés standard et d'extension ;

• les attributs de propriétés de ressource, comme par défaut , min, max, min_tableau, max_tableau ou la capacité de réglage ;

• l'ensemble des méthodes déclarées ;

• la mise en oeuvre des méthodes ou des détecteurs.

Le développeur du type de ressources décide quand il est possible de migrer une ressource existante vers une nouvelle version en choisissant l'une des options de capacité de réglage suivantes. Ces options sont classées de la moins à la plus restrictive :

• à tout moment (Á-tout-moment) ;

• lorsque la ressource n'est pas contrôlée (Lorsque_non_contrôlée ) ;

• lorsque la ressource est hors ligne (Lorsque_hors_ligne) ;

• lorsque la ressource est désactivée (Lorsque_désactivée) ;

• lorsque le groupe de ressources n'est pas géré (Lorsque-non-gérée ) ;

• à la création (Á_création).

ce chapitre traite de la procédure de mise à niveau au moyen de la commande scrgadm mais l'administrateur n'est pas contraint d'utiliser cette commande. Il peut également effectuer la mise à niveau par le biais de l'interface utilisateur graphique ou au moyen de la commande scsetup.

Fichier RTR (Resource Type Registration)

Nom du type de ressources

Les trois composantes du nom du type de ressources sont des propriétés spécifiées dans le fichier RTR sous id_fournisseur, type_ressources et version_type_res. La commande scrgadm insère les délimiteurs (points et deux points) pour créer le nom du type de ressources :

vendor_id.resource_type:rt_version

Le préfixe id_fournisseur permet de distinguer deux fichiers de connexion portant le même nom mais provenant de deux fournisseurs différents. La version_type_res permet de distinguer plusieurs versions enregistrées (mises à niveau) du même type de ressources de base. Pour avoir l'assurance que l'id_fournisseur est unique, nous vous recommandons d'utiliser le symbole boursier de l'entreprise en tant que type de ressources.

La mise en ligne d'une ressource échoue si la chaîne version_type_res comprend un espace vide, une tabulation, une barre oblique (/) ou (\), un astérisque (*), un point d'interrogation (?), une virgule (,), un point virgule (;), un crochet gauche ([) ou un crochet droit (]).

La propriété Version_TR, qui était facultative dans Sun Cluster 3.0, est désormais obligatoire sous Sun Cluster 3.1.

Le nom qualifié est le nom que renvoie la commande suivante :

scha_resource_get -O Type -R nom_ressource -G nom_groupe_ressources

Les noms de type de ressources enregistrés sous les versions antérieures à Sun Cluster 3.1 se présentent toujours sous la forme suivante :

type_ressource.id_fournisseur

Instructions

Les fichiers RTR des types de ressources supportant les mises à niveau doivent inclure une instruction #$upgrade, suivie de zéro ou plusieurs instructions comme suit :

#$upgrade_from version capacité_réglage

L'instruction upgrade_from comprend la chaîne #$upgrade_from, suivie de Version_RT, de la contrainte de capacité de réglage de la ressource. Si le type de ressources en cours de mise à jour ne possède pas de version, la propriété Version_RT est définie en tant que chaîne de caractères vide, comme illustré dans l'exemple ci-après :

#$upgrade_from   "1.1"   Losque_hors_ligne
#$upgrade_from   "1.2"   Losque_hors_ligne
#$upgrade_from   "1.3"   Losque_hors_ligne
#$upgrade_from   "2.0"   Lorsque_non_contrôlée
#$upgrade_from   "2.1"   À_tout_moment
#$upgrade_from   ""      Lorsque_non_gérée

Le gestionnaire RGM exécute ces contraintes sur une ressource lorsque l'administrateur système tente de modifier la ressource Version_type. Si la version actuelle du type de ressources n'apparaît pas dans la liste, le gestionnaire RGM impose la capacité de réglage de l'instruction Lorsque_non_gérée.

Ces instructions doivent apparaître entre la rubrique relative aux déclarations de propriétés de type de ressources et la rubrique relative aux déclarations de ressources du fichier RTR. Reportez-vous à rt_reg( 4).

Modification de la chaîne Version_RT dans un fichier RTR

Modifiez la chaîne Version_RT dans un fichier RTR chaque fois que le contenu de ce fichier change. La valeur de cette propriété doit permettre de reconnaître la nouvelle version du type de ressources de la précédente. Il n'est pas nécessaire de modifier la chaîne Version_RT si le fichier RTR n'a pas été modifié.

Noms des types de ressources dans les versions précédentes de Sun Cluster

Les noms de type de ressources dans Sun Cluster 3.0 ne contenaient pas le suffixe de version :

nom_ressource.id_fournisseur

Le format du nom d'un type de ressources initialement enregistré sous Sun Cluster 3.0 est conservé même après la mise à niveau du logiciel vers Sun Cluster 3.1. De la même façon, un nom de format Sun Cluster 3.0 sans version de suffixe est attribué à un type de ressources dont le fichier RTR ne contient pas d'instruction #$upgrade, si ce fichier est enregistré sur un cluster fonctionnant sous Sun Cluster 3.1.

Vous pouvez enregistrer des fichiers RTR avec l'instruction #$upgrade ou #$upgrade_from dans Sun Cluster 3.0. Par contre, la migration des ressources existantes vers les nouveaux types de ressources dans Sun Cluster 3.0 n'est pas prise en charge.

Propriété de ressources Version_type

La propriété de ressources standard propriété Version_type contient la propriété RT_Version d'un type de ressources. Cette propriété n'apparaît pas dans le fichier RTR. L'administrateur système édite la valeur de cette propriété à l'aide de la commande suivante :

scrgadm -c -j ressource -y version_type=nouvelle_version

La capacité de réglage de cette propriété provient de :

• La version actuelle du type de ressources.

• Les instructions #$upgrade_from figurant dans le fichier RTR.

Utilisez les valeurs de capacité de réglage dans les instructions #$upgrade_from :

À_tout_moment

En l'absence de restrictions quand il est possible de mettre une ressource à niveau. La ressource peut être en ligne.

Lorsque_non_contrôlée

Lorsque les méthodes de Mise_à_jour, Arrêt, Contrôle_détecteur et Arrêt_après_réseau de la nouvelle version du type de ressources sont connues pour être compatibles avec les méthodes de démarrage de la version antérieure (Arrêt_avant_réseau et Démarrage) et lorsque la méthode Fini de la nouvelle version du type de ressources est connue pour être compatible avec la méthode Init des versions antérieures. Dans ce cas, il faut simplement arrêter le programme du détecteur de ressources avant la mise à niveau.

Lorsque_hors_ligne

Lorsque les méthodes de la nouvelle version du type de ressources Mise_à_jour, Arrêt, Contrôle_détecteur ou Arrêt_après_réseau sont connues pour ne pas être compatibles avec les méthodes de démarrage de la version antérieure du type de ressources (Arrêt_avant_réseau et Démarrage) mais pour être compatibles avec la méthode Init des versions précédentes, la ressource doit être hors ligne lors de la mise à niveau du type auquel elle appartient.

When_disabled

Identique à Lorsque_hors_ligne. Cette valeur de capacité de réglage implique que la ressource soit désactivée.

Lorsque-non-gérée

Lorsque la méthode version Fini de la nouvelle version du type de ressources n'est pas compatible avec la méthode Init des versions antérieures. Lorsque cette valeur de capacité de réglage est définie, vous ne pouvez mettre à niveau la ressource qu'après avoir basculé l'état du groupe de ressources existant en mode non géré.

À_la_création

Lorsqu'il est impossible de mettre à niveau les ressources vers la nouvelle version de type de ressources. Vous ne pouvez que créer de nouvelles ressources avec la nouvelle version.

La capacité de réglage de À_la_création signifie que le développeur du type de ressources peut empêcher la migration d'une ressource existante vers un nouveau type. Le cas échéant, l'administrateur système doit supprimer, puis recréer la ressource. Ceci revient à déclarer que la version de la ressource ne peut être définie qu'au moment de la création.

Migration d'une ressource vers une version différente

La nouvelle version du type de ressources est appliquée à une ressource existante lorsque l'administrateur système édite la propriété Version_type de cette ressource. Les conventions appliquées sont identiques à celles servant à éditer les autres propriétés de ressources, si ce n'est que certaines informations peuvent provenir de la nouvelle version du type de ressources au lieu de la version actuelle :

• Les attributs de propriétés de ressources de toutes les propriétés ( min, max, min_tableau, max_tableau), les valeurs par défaut et la capacité de réglage sont issus de la nouvelle version du type de ressources.

• La capacité de réglage applicable à la propriété Version_type est fournie par l'instruction #$upgrade_from figurant dans le fichier RTR et la propriété Version_RT du type de ressources de la ressource existante. Elle est différente de la capacité de réglage décrite dans property_attributes(5).

• La méthode de Validation de la nouvelle version du type de ressources est appliquée, garantissant ainsi que les attributs de propriétés sont valides pour le nouveau type de ressources. Si les attributs de propriétés de ressources existants ne satisfont pas aux conditions de validation de la nouvelle version du type de ressources, l'administrateur système doit attribuer des valeurs valides aux propriétés concernées sur la ligne de commande scrgadm. Cette situation peut se présenter si la dernière version du type de ressources exécute une propriété qui n'a pas été déclarée dans la version précédente et pour laquelle aucune valeur par défaut n'a été définie. Vous pouvez également y être confronté si la ressource existante possède une propriété dont la valeur, qui a déjà été attribuée, est invalide pour la dernière version du type de ressources.

• Les propriétés de ressources qui ont été déclarées dans la version précédente du type de ressources peuvent ne pas être déclarées dans la nouvelle version. Lors de la migration de la ressource vers la nouvelle version, ces propriétés sont supprimées.

la méthode de Validation peut interroger la propriété Version_type actuelle de la ressource (avec scha_resource_get), ainsi que la nouvelle propriété Version_type (qui est transmise à la ligne de commande Validation). Par conséquent, Validation peut exclure les mises à jour des versions non prises en charge.

Mise à niveau ou adaptation vers une version antérieure d'un type de ressources

La rubrique “Upgrading a Resource Type” du document Sun Cluster 3.1 Data Service Planning and Administration Guide fournit de plus amples informations sur la mise à niveau et la migration d'un type de ressources.

Procédure de mise à niveau d'un type de ressources

1. Lisez la documentation de mise à niveau du nouveau type de ressources pour découvrir les modifications apportées au type de ressources et les contraintes de capacités de réglage des ressources.

2. Installez le package de mise à niveau du type de ressources sur tous les noeuds du cluster.

   La méthode d'installation recommandée de nouveaux packages de type de ressources est en cours de révision : pkgadd est exécuté lors de l'initialisation d'un noeud en mode non-cluster.

   Certaines situations permettent d'installer de nouveaux packages de type de ressources sur un noeud en mode cluster :

   • Si l'installation du package de type de ressources ne modifie pas le code de méthode tout en mettant uniquement à jour le détecteur, vous devez interrompre la surveillance de toutes les ressources de ce type pendant l'installation.

   • Si l'installation du package de type de ressources ne modifie ni le code de méthode ni le code de contrôle, il n'est pas nécessaire d'interrompre la surveillance des ressources lors de l'installation. De fait, cette opération installe juste un nouveau fichier RTR sur le disque.

3. Enregistrez la nouvelle version du type de ressources à l'aide de la commande scrgadm (ou une commande équivalente), en indiquant le fichier RTR de la mise à niveau.

   Le gestionnaire RGM crée un nouveau type de ressources dont le nom possède le format suivant :

   id_fournisseur.type_ressource:version

4. Si la mise à niveau du type de ressources n'est installée que sur un sous-ensemble des noeuds, vous devez définir la propriété Noeuds_installés du nouveau type de ressources sur les noeuds sur lesquels elle est réellement installée.

   Lorsque le nouveau type est attribué à une ressource (venant d'être créée ou mise à jour), le gestionnaire RGM requiert que le groupe de ressources liste_noeud soit un sous-ensemble de la liste Noeuds_installés du type de ressources.

   scrgadm -c -t type_ressources -h liste_noeuds_installés

5. Pour chaque ressource du type pré-mis à niveau à migrer vers le type mis à niveau, exécutez scswitch pour basculer l'état de la ressource ou de son groupe sur l'état approprié, comme indiqué dans la documentation de mise à niveau.

6. Pour chaque ressource du type pré-mis à niveau à migrer vers le type mis à niveau, éditez la ressource et remplacez la propriété Version_type par la nouvelle version.

   scrgadm -c -j ressource -y version_type=nouvelle_version

   Remplacez, si nécessaire, les autres propriétés de la même ressource par les valeurs appropriées dans la même commande.

7. Restaurez l'état précédent de la ressource ou du groupe de ressources en inversant la commande exécutée à l'Étape 5.

Procédure d'adaptation d'une ressource vers une version antérieure de son type de ressources

Vous pouvez adapter une ressource vers une version antérieure de son type de ressources. Les conditions requises pour adapter une ressource vers une version antérieure du type de ressources sont plus restrictives que celles requises pour mettre à niveau le type de ressources. Vous devez commencer par basculer le groupe de ressources en mode non géré. En outre, vous ne pouvez adapter une ressource vers une version antérieure que si cette version est compatible avec la mise à jour du type de ressources. Vous pouvez identifier ces versions à l'aide de la commande scrgadm -p. Les versions compatibles avec la mise à jour apparaissent avec le suffixe :version.

1. Déconnectez le groupe de ressources qui contient la ressource que vous souhaitez adapter vers une version antérieure.

   scswitch -F -g groupe_ressources

2. Déconnectez la ressource que vous souhaitez adapter vers une version antérieure, ainsi que toutes les ressources du groupe de ressources.

   scswitch -n -j ressource_vers_version_antérieure scswitch -n -j ressource1 scswitch -n -j ressource2 scswitch -n -j ressource3 ...

   ---

   Remarque :

   désactivez les ressources par ordre de dépendance, en commençant par les plus dépendantes (ressources d'application) et en terminant par les moins dépendantes (ressources d'adresse réseau).

   ---

3. Basculez le groupe de ressources en mode non géré.

   scswitch -u -g groupe_ressources

4. La version antérieure du type de ressources vers laquelle vous souhaitez faire l'adaptation figure-t-elle toujours sur le cluster ?

   • Si oui, passez à l'étape suivante.

   • Si non, réenregistrez la version antérieure qui vous intéresse.

     scrgadm -a -t nom_type_ressource

5. Adaptez la ressource vers le bas en spécifiant la version antérieure sous Version_type.

   scrgadm -c -j ressource_vers_version_antérieure -y version_type=version_antérieure

   Remplacez, si nécessaire, les autres propriétés de la même ressource par les valeurs appropriées dans la même commande.

6. Basculez le groupe contenant la ressource à adapter vers une version antérieure en mode géré, activez toutes les ressources et connectez le groupe de ressources.

   scswitch -Z -g groupe_ressources

Valeur par défaut des propriétés

Le gestionnaire RGM enregistre toutes les ressources. Par conséquent, toutes les propriétés qui ne sont pas explicitement définies par l'administrateur (et configurées sur leur valeur par défaut) ne sont pas enregistrées dans l'entrée des ressources du CCR (cluster configuration repository). Le gestionnaire RGM trouve les valeurs par défaut d'une propriété de ressource manquante dans le type de ressources (ou, si elles n'y figurent pas, à l'aide des valeurs par défaut définies par le système) lorsqu'une ressource est lue à partir du CCR. Cette méthode d'enregistrement des propriétés permet à un type de ressources mis à niveau de définir de nouvelles propriétés ou de nouvelles valeurs par défaut pour les propriétés existantes.

Lors de l'édition de propriétés de ressources à l'aide de la commande appropriée, le gestionnaire RGM les enregistre dans le CCR.

Si une version mise à niveau du type de ressources déclare une nouvelle valeur par défaut pour une propriété par défaut, les ressources existantes héritent de cette valeur, même si la propriété est déclarée comme étant réglable uniquement À_création ou Lorsque_désactivée. Si l'application de la nouvelle valeur par défaut engendre l'échec d'une méthode d'Arrêt, Arrêt_après_réseau ou Fini par exemple, la personne chargée de la mise en application du type de ressources doit modifier en conséquence l'état de la ressource au moment de sa mise à niveau. Pour ce faire, il doit restreindre la capacité de réglage de la propriété Version_type.

La méthode de Validation de la nouvelle version du type de ressources peut effectuer un contrôle pour vérifier que les attributs de propriétés existants sont appropriés. S'ils ne le sont pas, l'administrateur système peut définir de façon appropriée les valeurs des propriétés d'une ressource existante dans la commande servant à modifier la propriété Version_type pour mettre à niveau la ressource vers la nouvelle version du type de ressources.

les ressources créées dans Sun Cluster 3.0 n'héritent pas des attributs de propriétés par défaut du type de ressources lors de leur migration vers une version ultérieure car leurs propriétés par défaut sont enregistrées dans le CCR.

Informations à fournir par le développeur de type de ressources

Le développeur de type de ressources doit fournir les informations suivantes avec la nouvelle ressource :

• décrire les ajouts, modifications ou suppressions de propriétés ;

• décrire la procédure à appliquer pour rendre les propriétés conformes aux nouvelles exigences ;

• définir les contraintes de capacité de réglage au niveau des ressources ;

• afficher les nouveaux attributs de propriétés par défaut ;

• informer l'administrateur système qu'il est possible de modifier les propriétés de ressources existantes sur les valeurs appropriées à l'aide de la commande servant à modifier la propriété Version_type pour mettre à niveau la ressource vers la nouvelle version du type de ressources.

Mise en oeuvre du nom et du détecteur du type de ressources

Vous pouvez enregistrer un type de ressources supportant les mises à niveau dans Sun Cluster 3.0. Par contre, son nom est enregistré dans le CCR sans le suffixe de version. Pour fonctionner correctement dans Sun Cluster 3.0 et Sun Cluster 3.1, le détecteur de ce type de ressources doit pouvoir gérer deux conventions d'attribution des noms :

id_fournisseur.nom_ressource:version
id_fournisseur.nom_ressource

Le code de contrôle peut déterminer le nom approprié à utiliser en exécutant l'équivalent de

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

puis en comparant les valeurs de sortie avec vers. Seule une de ces commandes n'échouera pas pour une valeur spécifique de vers car il est impossible d'enregistrer la même version d'un type de ressources deux fois sous deux noms différents.

Mises à niveau de l'application

La mise à niveau du code d'application diffère de celle du code de l'agent, bien que certains points se recoupent. La mise à niveau de l'application peut être accompagnée ou non de la mise à niveau d'un type de ressources.

Exemples de mise à niveau d'un type de ressources

Ces exemples présentent plusieurs scénarios de mise à niveau et d'installation d'un type de ressources. Les informations relatives au package et à la capacité de réglage ont été choisies en fonction des types de modifications apportés à la mise en oeuvre du type de ressources. La capacité de réglage s'applique à la migration de la ressource vers le nouveau type de ressources.

Tous les exemples supposent que :

• Le type de ressources est fourni dans un package de type Solaris. Reportez-vous à pkgadd(1M) et pkgrm(1M).

• Il existe une seule version antérieure du type de ressources et, par conséquent, une seule instruction #$upgrade_from dans le nouveau fichier RTR.

• La procédure d'installation ne peut pas supprimer ou écraser les méthodes dans la mesure où le gestionnaire RGM peut les exécuter alors qu'elles ont été effacées du disque.

• Les nouvelles méthodes sont compatibles avec les méthodes antérieures à moins que l'inverse soit spécifié.

• Les ressources et les groupes de ressources sont basculés dans l'état requis avant l'installation ou la migration à l'aide de la commande scswitch (1M) appropriée ou d'une commande équivalente. Exemples de basculement du groupe de ressources en mode non géré :

  scswitch -M -n -j ressource scswitch -n -j ressource scswitch -F -g groupe_ressources scswitch -u -g groupe_ressources

• Vous pouvez enregistrer un type de ressources à l'aide de la commande suivante :

  scrgadm -a -t type_ressource -f transfert_vers_fichier_RTR

• Vous pouvez migrer un type de ressources à l'aide de la commande suivante :

  scrgadm -c -j ressource -y version_type=version \ -y propriété=valeur \ -x propriété=valeur ...

• L'état précédent des ressources et des groupes de ressources est restauré après la migration à l'aide de la commande scswitch (1M) ou d'une commande équivalente :

  scswitch -M -e -j ressource scswitch -e -j ressource scswitch -o -g groupe_ressources scswitch -Z -g groupe_ressources

Le développeur du type de ressources peut devoir spécifier des valeurs de capacité de réglage plus restrictives que celles utilisées dans ces exemples. Les valeurs de réglage dépendent des modifications précises qui ont été apportées à la mise en oeuvre du type de ressources. En outre, le développeur peut choisir d'utiliser un package différent du package de type Solaris employé dans ces exemples.

Conditions requises pour l'installation des packages de type de ressources

L'installation de nouveaux packages de type de ressources comportent deux conditions requises :

• Lorsqu'un nouveau type de ressources est enregistré, son fichier RTR doit être accessible sur le disque.

• Lorsqu'une ressource du nouveau type est créée, tous les noms de chemin d'accès aux méthodes déclarés, ainsi que le programme détecteur du nouveau type doivent figurer sur le disque et être exécutables. Les programmes détecteurs et de méthode antérieurs doivent être conservés au même emplacement tant que la ressource est utilisée.

  Pour choisir le package le plus approprié, la personne chargée de la mise en application du type de ressources doit tenir compte des points suivants :

  • Le fichier RTR change-t-il ?

  • La valeur par défaut ou la capacité de réglage d'une propriété change-t-elle ?

  • La valeur min ou max d'une propriété change-t-elle ?

  • La mise à niveau supprime-t-elle ou ajoute-t-elle des propriétés ?

  • Le code de méthode change-t-il ?

  • Le code de contrôle change-t-il ?

  • Les nouvelles méthodes ou le nouveau code de contrôle est-il compatibles avec la version antérieure ?

Informations utiles avant la modification d'un fichier RTR

Certaines mises à niveau du type de ressources n'impliquent ni une nouvelle méthode ni un nouveau code de contrôle. Par exemple, la mise à niveau d'un type de ressources peut n'induire que la modification de la valeur par défaut ou de la capacité de réglage d'une propriété de ressources. Comme le code de méthode ne change pas, il est uniquement nécessaire, pour installer la mise à niveau, de disposer d'un nom de chemin d'accès valide vers un fichier RTR lisible.

Il n'est pas nécessaire de réenregistrer le type de ressources précédent car le nouveau fichier RTR peut écraser la version antérieure. Dans le cas contraire, vous devez enregistrer le nouveau fichier RTR sous un nouveau nom de chemin d'accès.

Si la mise à niveau modifie la valeur par défaut ou la capacité de réglage d'une propriété, la méthode de Validation de la nouvelle version peut vérifier, au moment de la migration, que les attributs de propriétés existants sont valides pour le nouveau type de ressources. Si la mise à niveau modifie les attributs min, max ou type d'une propriété, la commande scrgadm valide automatiquement ces contraintes au moment de la migration.

Les informations relatives à la mise à niveau doivent présenter tous les nouveaux attributs de propriétés par défaut. Elles doivent indiquer à l'administrateur système qu'il est possible de modifier les propriétés de ressources existantes sur les valeurs appropriées à l'aide de la commande servant à modifier la propriété Version_type pour mettre à niveau la ressource vers la nouvelle version du type de ressources.

Si la mise à niveau ajoute ou supprime des propriétés, il est probable qu'il faille également modifier le code de contrôle ou certaines méthodes de rappel.

Modification du code de contrôle

Si seul le code de contrôle a été modifié dans le type de ressources mis à jour, l'installation du package peut écraser les codes de contrôle binaires. La documentation doit spécifier à l'administrateur système de suspendre la surveillance avant d'installer le nouveau package.

Modification du code de méthode

Si seul le code de méthode a été modifié dans le type de ressources mis à jour, il est crucial de déterminer si le nouveau code de méthode est compatible avec la version antérieure. Ceci vous permet de savoir si vous devez enregistrer ce nouveau code sous un nouveau nom de chemin d'accès ou si vous pouvez écraser les méthodes antérieures.

Si vous pouvez appliquer les nouvelles méthodes d'Arrêt, Arrêt_après_réseau et Fini (à condition d'être déclarées) aux ressources initialisées ou exécutées par les versions antérieures des méthodes de Démarrage , Arrêt_avant_réseau ou Init, vous pouvez écraser les anciennes méthodes par les nouvelles.

Si le nouveau code de méthode n'est pas compatible avec la version antérieure, vous devez arrêter une ressource ou la supprimer de la configuration à l'aide des versions antérieures avant de pouvoir la migrer vers le type de ressources mis à niveau. Si les nouvelles méthodes écrasent les anciennes, il peut s'avérer nécessaire d'arrêter (voire de basculer en mode non géré) toutes les ressources de ce type avant de mettre ce dernier à niveau. Si les nouvelles et les anciennes méthodes sont enregistrées séparément (tout en étant accessibles simultanément), vous pouvez, même en l'absence de rétrocompatibilité, installer la nouvelle version du type de ressources et mettre les ressources à niveau individuellement.

Même si les nouvelles méthodes sont rétrocompatibles, il peut s'avérer nécessaire de mettre à niveau une ressource pour utiliser les nouvelles méthodes tandis que les autres ressources continuent d'utiliser les méthodes antérieures. Vous devez encore enregistrer les nouvelles méthodes dans un répertoire distinct plutôt que d'écraser les méthodes antérieures.

L'enregistrement des méthodes de chaque version du type de ressources dans un répertoire distinct permet de rebasculer les ressources vers la version antérieure en cas de problème avec la nouvelle version.

Une autre approche consiste à inclure toutes les versions précédentes encore prises en charge dans le package. Le cas échéant, le nouveau package remplace la version antérieure sans écraser ni supprimer les chemins d'accès aux méthodes antérieures. C'est au développeur du type de ressources de décider du nombre de versions antérieures prises en charge.

nous vous recommandons d'écraser les méthodes ou les méthodes pkgrm/ pkgadd sur un noeud appartenant au cluster. Si le gestionnaire RGM doit exécuter une méthode qui n'est pas accessible sur le disque, ceci risque d'engendrer des résultats inattendus. La suppression ou le remplacement du code binaire d'une méthode en cours d'exécution peut également engendrer des résultats inattendus.