Chapitre 4 Modification d'un type de ressources

Ce chapitre présente les aspects essentiels de la modification des types de ressources, ainsi que des informations sur la manière d'autoriser un administrateur de cluster à mettre à niveau une ressource.

Ce chapitre contient les rubriques suivantes :

• Modification des types de ressources

• Contenu du fichier d'enregistrement du type de ressources

• Étapes et effets d'une mise à niveau effectuée par un administrateur de clusters

• Utilisation du code de contrôle du type de ressources

• Détermination des exigences relatives à l'installation et choix du type de package

• Documentation requise pour un type de ressources modifié

Modification des types de ressources

Les administrateurs de clusters doivent être à même d'effectuer les tâches suivantes :

• Installer et enregistrer une nouvelle version d'un type de ressources existant

• Autoriser l'enregistrement de plusieurs versions d'un type de ressources donné

• Mettre à niveau une ressource existante vers une nouvelle version de son type de ressources, sans avoir à la supprimer et à la recréer

Les types de ressources que vous prévoyez de mettre à niveau sont appelés types de ressources prêts pour la mise à niveau. Dans un type de ressources, vous pouvez modifier les éléments suivants :

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

• l'ensemble des propriétés de ressources déclarées (notamment les propriétés standard et les propriétés d'extension) ;

• les attributs des propriétés des ressources, notamment default, min, max, arraymin, arraymax et tunability ;

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

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

il n'est pas indispensable de modifier un type de ressources lorsque l'on modifie du code d'application.

Pour fournir aux administrateurs de clusters des outils qui leur permettront de mettre à niveau un type de ressources, vous devez tenir compte de certaines exigences. Ce chapitre vous apporte les informations nécessaires pour configurer ces outils.

Contenu du fichier d'enregistrement du type de ressources

Nom du type de ressources

Le nom d'un type de ressources se compose de trois propriétés, définies dans le fichier RTR comme vendor-id, resource-type et rt-version. La commande scrgadm insère les délimiteurs requis pour créer le nom du type de ressources (point et deux-points) :

vendor-id.resource-type:rt-version

Le préfixe vendor-id permet de distinguer deux fichiers d’enregistrement portant le même nom, mais fournis par des sociétés différentes. Pour éviter tout risque d'ambiguité de la propriété vendor-id, il est recommandé d'utiliser le symbole de la société lors de la création du type de ressources. La propriété rt-version permet de faire la distinction entre plusieurs versions enregistrées (mises à niveau) du même type de ressources.

La commande ci-dessous fournit le nom complet d'un type de ressources :

# scha_resource_get -O Type -R resource-name -G resource-group-name

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

vendor-id.resource-type

Le format des noms de types de ressources est décrit dans la rubrique Format des noms de types de ressources .

Définition des directives #$upgrade et #$upgrade_from

Pour garantir que le type de ressources modifié sera prêt pour la mise à niveau, incluez la directive #$upgrade dans son fichier RTR. Ajoutez ensuite éventuellement une ou plusieurs directives #$upgrade_from pour chacune des versions antérieures à prendre en charge.

Dans le fichier RTR, les directives #$upgrade et #$upgrade_from doivent être placées entre les déclarations des propriétés du type de ressources et les déclarations de ressources. Pour plus d'informations, reportez-vous à la page de manuel rt_reg(4).

Exemple 4–1 Directive #$upgrade_from dans un fichier RTR

#$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

La directive #$upgrade_from a le format suivant :

#$upgrade_from version tunability

version

RT_version. Si le type de ressources n'a pas de version ou que sa version est différente de celle que vous avez définie dans le fichier RTR, saisissez une chaîne vide (“”).

tunability

Cet argument définit les conditions selon lesquelles l'administrateur du cluster est autorisé à mettre à niveau la version RT_version indiquée.

Dans les directives #$upgrade_from, les valeurs de capacité de réglage sont les suivantes :

ANYTIME

Utilisez cette option lorsqu'il n'existe aucune restriction ou que l'administrateur peut mettre la ressource à niveau. La ressource peut rester connectée pendant la mise à niveau.

WHEN_UNMONITORED

Utilisez cette option lorsque les méthodes de la version du nouveau type de ressources remplissent les conditions suivantes :

• Les méthodes Update, Stop, Monitor_check et Postnet_stop sont compatibles avec les méthodes de démarrage de l'ancienne version du type de ressources (Prenet_stop et Start).

• La méthode Fini est compatible avec les méthodes Init des anciennes versions.

L'administrateur du cluster doit seulement arrêter le détecteur de la ressource avant de procéder à la mise à niveau.

WHEN_OFFLINE

Utilisez cette option lorsque la méthode Update, Stop, Monitor_check ou Postnet_stop du nouveau type de ressources est :

• compatible avec la méthode Init d'une version antérieure,

• incompatible avec les méthodes de démarrage (Prenet_stop et Start) d'une version antérieure du type de ressources.

L'administrateur du cluster doit déconnecter la ressource avant de procéder à la mise à niveau.

WHEN_DISABLED

Cette option est similaire à WHEN_OFFLINE. Cependant, l'administrateur du cluster doit désactiver la ressource avant d'effectuer la mise à niveau.

WHEN_UNMANAGED

Utilisez cette option si la méthode Fini de la nouvelle version du type de ressources est incompatible avec la méthode Init d'une version antérieure. L'administrateur du cluster doit mettre le groupe de ressources existant à l'état non géré avant de procéder à la mise à niveau.

Si une version du type de ressources n'apparaît pas dans la liste des directives #$upgrade_from, le RGM lui impose l'option de capacité de réglage WHEN_UNMANAGED, par défaut.

AT_CREATION

Cette option empêche la mise à niveau des ressources vers la nouvelle version du type de ressources. Si elle est utilisée, l'administrateur du cluster doit supprimer et recréer la ressource.

Modification de la propriété RT_version d'un fichier RTR

Ne modifiez la propriété RT_version d'un fichier RTR que lorsque le contenu du fichier RTR change. Attribuez-lui une valeur qui indique clairement qu'il s'agit de la dernière version du type de ressources.

N'incluez pas les caractères ci-dessous dans la chaîne RT_version du fichier RTR, sinon l'enregistrement du type de ressources échouera :

• Espace

• Tabulation

• Barre oblique (/)

• Barre oblique inverse (\)

• Astérisque (*)

• Point d'interrogation (?)

• Virgule (,)

• Point virgule (;)

• Crochet gauche ([)

• Crochet droit (])

La propriété RT_version, facultative dans Sun Cluster 3.0, est obligatoire depuis Sun Cluster 3.1.

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

Dans Sun Cluster 3.0, les noms des types de ressources ne contiennent pas de suffixe de version :

vendor-id.resource-type

Les noms de types de ressources enregistrés initialement dans Sun Cluster 3.0 conservent cette syntaxe même si le logiciel de cluster a été mis à niveau vers Sun Cluster 3.1 ou une version ultérieure. De même, un type de ressources dont le fichier RTR ne contient pas la directive #$upgrade aura un nom au format Sun Cluster 3.0 (sans suffixe de version) même s'il est enregistré sur un cluster fonctionnant sous Sun Cluster 3.1 ou une version ultérieure.

L'administrateur du cluster peut enregistrer des fichiers RTR à l'aide de la directive #$upgrade ou de la directive #$upgrade_from dans Sun Cluster 3.0. Cependant, la mise à niveau des ressources existantes vers un nouveau type de ressources dans Sun Cluster 3.0 n'est pas prise en charge.

Étapes et effets d'une mise à niveau effectuée par un administrateur de clusters

Lorsqu'un administrateur de clusters met à niveau un type de ressources :

• Si les attributs des propriétés de ressource ne remplissent pas les conditions de validité de la nouvelle version du type de ressources, l'administrateur de clusters doit fournir des valeurs valides. C'est le cas, notamment :

  • lorsque la nouvelle version du type de ressources n'a pas de valeur par défaut et utilise une propriété non déclarée dans la version antérieure ;

  • lorsqu'une ressource utilise une propriété dont la valeur n'est pas déclarée ou n'est pas valide dans la nouvelle version. Les propriétés déclarées dans une ancienne version du type de ressources, mais non dans sa nouvelle version, sont supprimées de la ressource.

• Toute tentative de mise à niveau d'une version du type de ressource non prise en charge échoue.

• Après la mise à niveau, les ressources héritent des attributs de propriétés de ressource pour toutes les propriétés de la nouvelle version du type de ressources.

• Si vous changez la valeur par défaut d'un type de ressources dans le fichier RTR, les ressources existantes héritent de la nouvelle valeur par défaut, même si la capacité de réglage de la propriété est définie sur AT_CREATION ou WHEN_DISABLED. Si l'administrateur de clusters crée une propriété du même type, celle-ci hérite également de la valeur par défaut. Cependant, s'il attribue une nouvelle valeur à la propriété, la nouvelle valeur remplace la valeur par défaut définie dans le fichier RTR.

les ressources créées dans Sun Cluster 3.0 n'héritent pas des attributs par défaut des propriétés de ressource lorsqu'elles sont mises à niveau vers une nouvelle version de Sun Cluster. Cette restriction s'applique uniquement aux clusters Sun Cluster 3.0 mis à niveau vers Sun Cluster 3.1 ; en outre, les administrateurs de clusters peuvent la surmonter en attribuant des valeurs aux propriétés (les valeurs définies remplaçant alors les valeurs par défaut).

Utilisation du code de contrôle du type de ressources

Il est toujours possible à l'administrateur du cluster d'enregistrer un type de ressources prêt à la mise à niveau dans Sun Cluster 3.0. Cependant, Sun Cluster enregistrera le nom du type de ressources sans le suffixe de version. Pour fonctionner correctement dans Sun Cluster 3.0 et Sun Cluster 3.1, les codes de contrôle de ces types de ressources doivent pouvoir gérer les deux conventions d'attribution de noms :

vendor-id.resource-type:rt-version
vendor-id.resource-type

Le format des noms de types de ressources est décrit dans la rubrique Format des noms de types de ressources .

Il est impossible d'enregistrer deux fois la même version du type de ressources sous deux noms différents. Pour que le code de contrôle puisse identifier le bon nom, l'administrateur du cluster doit appeler les commandes ci-dessous dans ce code :

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

Il doit ensuite comparer les valeurs de sortie avec la valeur de vers. Pour chaque valeur de vers, une seule de ces commandes fonctionne.

Détermination des exigences relatives à l'installation et choix du type de package

Pour déterminer les exigences d'installation et le type de package à utiliser, tenez compte des points suivants :

• Pour que l'on puisse enregistrer un nouveau type de ressources, le fichier RTR correspondant doit être accessible sur le disque.

• Lors de la création d'une ressource du nouveau type, tous les chemins d'accès des méthodes, ainsi que le détecteur du nouveau type de ressources, doivent se trouver 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 savoir quel type de package utiliser, posez-vous les questions suivantes :

• 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 contrôle change-t-il ?

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

• Les nouvelles méthodes et/ou le code de contrôle sont-ils compatibles avec les versions antérieures ?

Les réponses à ces questions vous aideront à identifier le type de package à utiliser pour le nouveau type de ressources.

Étapes préalables à la modification du fichier RTR

Il n'est pas nécessaire de créer du nouveau code de contrôle ou de méthode lorsque vous modifiez un type de ressources : par exemple, vous pouvez changer uniquement la valeur par défaut ou la capacité de réglage d'une propriété de ressource. Dans ce cas, vous aurez uniquement besoin d'un nouveau chemin valide vers un fichier RTR lisible.

Si vous n'avez pas besoin de ré-enregistrer le type de ressources, vous pouvez remplacer l'ancienne version du fichier RTR par la nouvelle ; si vous devez ré-enregistrer le type de ressources, placez le nouveau fichier RTR dans un nouveau chemin.

Si la mise à niveau change la valeur par défaut ou la capacité de réglage d'une propriété, utilisez la méthode Validate correspondant à la nouvelle version du type de ressources en vue de vérifier que les attributs de propriété existants sont valides pour le nouveau type de ressources. S'ils ne le sont pas, l'administrateur du cluster pourra modifier les propriétés d'une ressource existante et leur attribuer les valeurs appropriées. Si la mise à niveau modifie les attributs min, max ou type d'une propriété, la commande scrgadm valide automatiquement ces contraintes lorsque l'administrateur du cluster met à niveau le type de ressources.

Si elle ajoute ou supprime une propriété, vous devrez probablement modifier les méthodes de rappel ou le code de contrôle.

Modification du code de contrôle

Si vous modifiez uniquement le code de contrôle d'un type de ressources, l'installation du package peut remplacer les binaires de contrôle.

Modification du code de méthode

Lorsque vous modifiez uniquement le code de méthode d'un type de ressources, vous devez déterminer si le nouveau code est compatible avec l'ancien. La réponse à cette question vous aidera à déterminer si vous devez enregistrer le nouveau code de méthode dans un nouveau chemin ou si vous pouvez remplacer les anciennes méthodes par les nouvelles.

Si vous pouvez appliquer les nouvelles méthodes Stop, Postnet_stop et Fini (si elles sont déclarées) à des ressources initialisées ou démarrées à l'aide des anciennes versions de Start, Prenet_stop ou Init, vous pouvez remplacer les anciennes méthodes par les nouvelles.

Si l'application d'une nouvelle valeur par défaut à une propriété provoque l'échec d'une méthode telle que Stop, Postnet_stop ou Fini, l'administrateur du cluster devra restreindre l'état de la méthode en conséquence, lors de la mise à niveau du type de ressources.

Pour l'autoriser à le faire, limitez la capacité de réglage de la propriété Type_version.

Une bonne méthode consiste à inclure toutes les versions précédentes d'un type de ressources, si elles sont prises en charge, dans le package. Il est ainsi possible de remplacer l'ancienne version du package par la nouvelle, sans remplacer ni supprimer les anciens chemins des méthodes. Vous devez décider du nombre d'anciennes versions à prendre en charge.

Choix du type de package à utiliser

Le tableau ci-dessous vous permet de choisir le type de package à utiliser pour vos nouveaux types de ressources.

Documentation requise pour un type de ressources modifié

Les administrateurs de clusters trouveront des instructions de mise à niveau des ressources dans la rubrique Upgrading a Resource Type du Sun Cluster Data Services Planning and Administration Guide for Solaris OS. Afin de les aider à mettre à niveau un type de ressources modifié par vos soins, vous devez en outre leur communiquer les informations répertoriées dans cette section.

En règle générale, lorsque vous créez un nouveau type de ressources, vous devez fournir des documents qui remplissent les fonctions suivantes :

• Décrire les propriétés ajoutées, modifiées ou supprimées

• Indiquer comment rendre les propriétés compatibles avec les nouvelles exigences

• Présenter les contraintes de capacité de réglage appliquées aux ressources

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

• Informer les administrateurs de clusters qu'ils peuvent régler la valeur des propriétés de ressources existantes, si cela est nécessaire

Informations sur la préparation de l'installation de la mise à niveau

Expliquez aux administrateurs de clusters les procédures à suivre avant d'installer le package de mise à niveau sur un nœud :

• Si le package de mise à niveau remplace les méthodes existantes, l'administrateur doit redémarrer le nœud en mode non-cluster.

• Si le package de mise à niveau ne met à jour que le code de contrôle et ne modifie pas le code de méthode, l'administrateur doit laisser le nœud fonctionner en mode cluster. Il doit en outre désactiver la fonction de contrôle de tous les types de ressources.

• Si le package de mise à niveau met uniquement à jour le fichier RTR, sans modifier les codes de contrôle et de méthode, l'administrateur du cluster doit laisser le nœud fonctionner en mode cluster. Il doit également laisser la fonction de contrôle activée sur tous les types de ressources.

Moment opportun pour effectuer la mise à niveau

Expliquez aux administrateurs de clusters à quel moment ils peuvent mettre à niveau les ressources. Le moment opportun pour mettre la ressource à niveau dépend de l'option #$upgrade_from du fichier RTR - plus précisément, de l'option de capacité de réglage associée à chaque version de la ressource :

• à n'importe quel moment (ANYTIME) ;

• uniquement lorsque le contrôle de la ressource est désactivé (WHEN_UNMONITORED) ;

• uniquement lorsque la ressource est déconnectée (WHEN_OFFLINE) ;

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

• uniquement lorsque le groupe de ressources est non géré (WHEN_UNMANAGED ).

Exemple 4–2 Moment où la mise à niveau est possible en fonction de la propriété #$upgrade_from

Cet exemple montre la relation entre la capacité de réglage de la directive #$upgrade_from et les circonstances dans lesquelles un administrateur de clusters peut faire passer une ressource à une version ultérieure de son type de ressources.

#$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

Informations sur les modifications apportées aux propriétés de ressources

Décrivez toutes les modifications que vous avez apportées au type de ressources et qui obligent les administrateurs de clusters à modifier les propriétés des ressources existantes lors de la mise à niveau. Ces modifications peuvent être des types suivants :

• Modification des paramètres par défaut d'une ou de plusieurs propriétés du type de ressources

• Création de nouvelles propriétés d'extension du type de ressources

• Suppression de propriétés du type de ressources

• Modification de l'ensemble des propriétés standard déclarées pour le type de ressources

• Modification des attributs des propriétés de ressource, notamment min, max, arraymin, arraymax, default et tunability

• Modification de l'ensemble des méthodes déclarées

• Modification des méthodes ou du détecteur de pannes