Ce chapitre offre une vision globale des connaissances requises pour mettre à niveau un type de ressources et migrer une ressource.
Mise à niveau ou adaptation vers une version antérieure d'un type de ressources
Informations à fournir par le développeur de type de ressources
Conditions requises pour l'installation des packages de type de ressources
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 default, min, max, arraymin, arraymax ou la capacité de réglage ;
l'ensemble des méthodes déclarées ;
la mise en œuvre 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 :
à n'importe quel moment (ANYTIME) ;
lorsque la ressource n'est pas contrôlée (WHEN_UNMONITORED) ;
lorsque la ressource est hors ligne (WHEN_OFFLINE) ;
lorsque la ressource est désactivée (WHEN_DISABLED) ;
lorsque le groupe de ressources n'est pas géré (WHEN_UNMANAGED) ;
lors de la création (AT_CREATION).
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.
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.
L'enregistrement du type de ressources échoue si la chaîne Version_TR comporte un caractère vide, une tabulation, une barre oblique ( /), une barre oblique inverse (\), un astérisque (*), un point d'interrogation (?), une virgule (,), un point-virgule (;) ou un crochet gauche ([) ou droit (]).
La propriété RT_Version, 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 que vous avez enregistrés sous les versions antérieures à Sun Cluster 3.1 ont toujours la syntaxe suivante :
type_ressource.id_fournisseur |
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 RT_Version, 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é RT_Version est définie en tant que chaîne de caractères vide, comme illustré dans l'exemple ci-après :
#$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 |
Le RGM exécute ces contraintes sur une ressource lorsque l'administrateur système tente de modifier la ressource Type_version. Si la version actuelle du type de ressources n'apparaît pas dans la liste, le RGM impose le réglage WHEN_UNMANAGED.
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).
Modifiez la chaîne RT_Version 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 RT_Version si le fichier RTR n'a pas été modifié.
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 ou versions ultérieures. 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 ou versions ultérieures.
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.
La propriété de ressources standard propriété Type_version 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 Type_version=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 :
En l'absence de restrictions sur la période de mise à niveau de la ressource. La ressource peut être en ligne.
Lorsque les méthodes Update, Stop, Monitor_check et Postnet_stop 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 (Prenet_start et Start) 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 les méthodes de la nouvelle version du type de ressources Update, Stop, Monitor_check ou Postnet_stop sont connues pour ne pas être compatibles avec les méthodes de démarrage de la version antérieure du type de ressources (Prenet_start et Start) 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.
Similaire à WHEN_OFFLINE. Cependant, cette valeur de réglage impose une condition plus forte, à savoir que la ressource soit désactivée.
Lorsque la méthode Fini de la nouvelle version du type de ressources n'est pas compatible avec la méthode Init des anciennes versions. 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é.
Lorsque les ressources ne peuvent pas être mise à niveau vers la nouvelle version du type de ressources. Vous ne pouvez que créer de nouvelles ressources avec la nouvelle version.
L'attribut de réglage AT_CREATION 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.
La nouvelle version du type de ressources est appliquée à une ressource existante lorsque l'administrateur système édite la propriété Type_version 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, arraymin, arraymax), 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é Type_version est fournie par l'instruction #$upgrade_from figurant dans le fichier RTR et la propriété RT_version 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 Validate de la nouvelle version du type de ressources est appliquée, garantissant ainsi la validité des attributs de propriétés 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 Validate peut interroger la propriété Type_version actuelle de la ressource (avec scha_resource_get), ainsi que la nouvelle propriété Type_version (qui est transmise à la ligne de commande Validate). Par conséquent, Validate peut exclure les mises à jour des versions non prises en charge.
La rubrique “Upgrading a Resource Type” du Sun Cluster Data Services Planning and Administration Guide for Solaris OS fournit de plus amples informations sur la mise à niveau et la migration d'un type de ressources.
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.
Installez le package de mise à niveau du type de ressources sur tous les nœuds 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 nœud en mode non-cluster.
Certaines situations permettent d'installer de nouveaux packages de type de ressources sur un nœud 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.
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 RGM crée un nouveau type de ressources dont le nom possède le format suivant :
id_fournisseur.type_ressource:version |
Si la mise à niveau du type de ressources n'est installée que sur un sous-ensemble des nœuds, vous devez définir la propriété Installed_nodes du nouveau type de ressources sur les nœuds 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 RGM requiert que le groupe de ressources nodelist soit un sous-ensemble de la liste Installed_nodes du type de ressources.
scrgadm -c -t type_ressources -h liste_nœuds_installés |
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.
Pour chaque ressource du type pré-mis à niveau à migrer vers le type mis à niveau, éditez la ressource et remplacez la propriété Type_version 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.
Restaurez l'état précédent de la ressource ou du groupe de ressources en inversant la commande exécutée à l'Étape 5.
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.
Déconnectez le groupe de ressources qui contient la ressource que vous souhaitez adapter vers une version antérieure.
scswitch -F -g groupe_ressources |
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 ... |
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).
Basculez le groupe de ressources en mode non géré.
scswitch -u -g groupe_ressources |
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 |
Adaptez la ressource vers le bas en spécifiant la version antérieure sous Type_version.
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.
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 |
Le 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 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 RGM les enregistre dans le CCR.
Si une version mise à niveau d'un type de ressources déclare une nouvelle valeur par défaut pour une propriété comportant une valeur par défaut, les ressources existantes hérite de la nouvelle valeur par défaut, même si la propriété est déclarée réglable uniquement AT_CREATION ou WHEN_DISABLED. Si l'application de la nouvelle valeur par défaut engendre l'échec d'une méthode Stop, Postnet_stop 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é Type_version.
La méthode Validate 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é Tye_version 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.
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é Type_version pour mettre à niveau la ressource vers la nouvelle version 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 (et versions ultérieures), 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.
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.
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 œuvre 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 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 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 Type_version=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 œuvre du type de ressources. En outre, le développeur peut choisir d'utiliser un package différent du package Solaris employé dans ces exemples.
Tableau 3–1 Exemples de mise à niveau d'un type de ressources
Type de modification |
Capacité de réglage |
Configurations |
Procédure |
---|---|---|---|
Les propriétés sont uniquement modifiées dans le fichier RTR. |
ANYTIME |
Fournit uniquement un nouveau fichier RTR. |
Exécutez la commande pkgadd du nouveau fichier RTR sur tous les nœuds. Enregistrez le nouveau type de ressources. Migrez la ressource. |
Les méthodes sont mises à jour. |
ANYTIME |
Le chemin d'accès aux méthodes mises à jour doit différer du chemin d'accès aux méthodes antérieures. |
Exécutez la commande pkgadd des méthodes mises à jour sur tous les nœuds. Enregistrez le nouveau type de ressources. Migrez la ressource. |
Nouveau programme détecteur. |
WHEN_UNMONITORED |
Écrasez uniquement la méthode précédente du détecteur. |
Désactivez la surveillance. Exécutez la commande pkgadd du nouveau programme détecteur sur tous les nœuds. Enregistrez le nouveau type de ressources. Migrez la ressource. Activez la surveillance. |
Les méthodes sont mises à jour. Les nouvelles méthodes Update/Stop sont incompatibles avec les méthodes de Start antérieures. |
WHEN_OFFLINE |
Le chemin d'accès aux méthodes mises à jour doit différer du chemin d'accès aux méthodes antérieures. |
Exécutez la commande pkgadd des méthodes mises à jour sur tous les nœuds. Enregistrez le nouveau type de ressources. Déconnectez la ressource. Migrez la ressource. Connectez la ressource. |
Les méthodes sont mises à jour et les nouvelles propriétés sont ajoutées aux fichiers RTR. Les nouvelles méthodes requièrent de nouvelles propriétés. (L'objectif est de permettre au groupe de ressources correspondant de rester en ligne tout en évitant de connecter la ressource, même si le groupe de ressources déconnecté est mis en ligne sur un nœud). |
WHEN_DISABLED |
Écrasez les versions précédentes des méthodes. |
Désactivez la ressource.
Enregistrez le nouveau type de ressources. Migrez la ressource. Activez la ressource. |
Les méthodes sont mises à jour et les nouvelles propriétés sont ajoutées aux fichiers RTR. Les nouvelles méthodes ne requièrent pas de nouvelles propriétés. |
ANYTIME |
Écrasez les versions précédentes des méthodes. |
Lors de cette procédure, le RGM exécute les nouvelles méthodes même si la migration (qui doit configurer les nouvelles propriétés) n'a pas encore été réalisée. Il est important que les nouvelles méthodes soient fonctionnelles sans les nouvelles propriétés. Enregistrez le nouveau type de ressources. Migrez la ressource. |
Les méthodes sont mises à jour. La nouvelle méthode Fini est incompatible avec la méthode Init antérieure. |
WHEN_UNMANAGED |
Le chemin d'accès aux méthodes mises à jour doit différer du chemin d'accès aux méthodes antérieures. |
Basculez le groupe de ressources correspondant en mode non géré. Exécutez la commande pkgadd des méthodes mises à jour sur tous les nœuds. Enregistrez le type de ressources. Migrez la ressource. Basculez le groupe de ressources correspondant en mode géré. |
Les méthodes sont mises à jour. Le fichier RTR n'est pas modifié. |
Sans objet. Le fichier RTR n'est pas modifié. |
Écrasez les versions précédentes des méthodes. |
Comme le fichier RTR n'est pas modifié, il n'est pas nécessaire d'enregistrer ou de migrer la ressource. |
L'installation de nouveaux packages de type de ressources est soumise à deux conditions :
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 ?
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 Validate 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é Type_version 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.
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.
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 Stop, Postnet_stop 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 Start, Prenet_start 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 nœud appartenant au cluster. Si le 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.