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
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.
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 ).
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
Version |
Moments où la mise à niveau est possible |
---|---|
1.1, 1.2 ou 1.3 |
Uniquement lorsque la ressource est déconnectée |
2.0 |
Uniquement lorsque le contrôle de la ressource est désactivé |
2.1 |
À tout moment |
Autres versions |
Uniquement lorsque le groupe de ressources est à l'état non géré |
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