Personnalisation de l'extension du noyau

Editer en ligne

Au cours de l'opération AIX Live Update, les extensions du noyau peuvent être affectées. La plateforme DLPAR (Dynamic Logical Partitioning) permet de communiquer la progression de l'opération entre l'opération Mise à jour active et les extensions de noyau.

Le tableau suivant décrit les états d'extension de noyau dans la partition d'origine et la partition de substitution au cours de chaque phase :

Phases	Partition d'origine	Partition de substitution
Vérifier	Les extensions de noyau sont notifiées en même temps que les applications. Toutes les données de l'environnement `orig-rootvg` sont copiées dans l'environnement `surr-boot-rootvg` lors de la création des données.	Les extensions de noyau sont notifiées en même temps que les applications. Les données de contrôle sont disponibles sur les groupes de volumes `surr-boot-rootvg` et `surr-mir-rootvg` en raison de la mise en miroir. Le périphérique `surr-mir-rootvg` n'est disponible qu'après la phase préalable.
pre	Les extensions de noyau sont notifiées après vérification des applications. Les données de contrôle doivent être sauvegardées dans le groupe de volumes `orig-rootvg`. En raison de la mise en miroir, les données sont également disponibles sur le groupe de volumes `surr-mir-rootvg`. Les données deviennent disponibles dans l'environnement chrooté pour la partition de substitution après l'opération splitvg qui ne se produit qu'après la notification DLPAR. Après un redémarrage de la partition de substitution, les extensions de noyau doivent prendre en compte la modification de l'emplacement du fichier. Si l'ancien chemin est x, le nouveau chemin est /old/x.	Les extensions de noyau sont notifiées lorsque les systèmes de fichiers du groupe de volumes `surr-mir-rootvg` sont montés. Les données collectées sur la phase préalable de la partition d'origine sont disponibles uniquement dans l'environnement chrooté (après la modification du répertoire racine). Les applications qui se trouvent sur une partition de substitution doivent être conscientes de la disponibilité de l'environnement chrooté.
post	Cette notification est envoyée aux applications lorsque des applications sont lancées sur la partition de substitution.	Cette notification est envoyée aux applications lorsque des applications sont lancées sur la partition de substitution.
Post-erreur	Les extensions de noyau peuvent prendre les mesures appropriées.	Fournit aux extensions de noyau la possibilité de répondre à l'échec de Mise à jour active en fonction de la phase dans laquelle la phase Post-erreur se produit.

Si une extension de noyau s'attend à ce que l'opération de traitement DLPAR prenne beaucoup de temps, le gestionnaire doit renvoyer DR_WAIT à l'appelant et poursuivre la demande de manière asynchrone. Une fois la demande terminée, le gestionnaire doit appeler le service de noyau reconfig_complete().

L'état de l'application situé dans les extensions de noyau doit être considéré à partir des extensions de noyau associées. Les extensions connexes du noyau doivent contrôler ces états d'application lorsque les applications sont contrôlées et les recharger avec le bon état lorsque les applications sont redémarrées.

Considérations sur les périphériques

Lorsque la partition de substitution est démarrée, les unités doivent être configurées de la même manière que la configuration sur la partition d'origine. La même unité sur la partition d'origine et la partition de substitution doit avoir le même nom, le même numéro de périphérique (devno (majeur, mineur)) et la même configuration périphérique.

Certains périphériques peuvent avoir des attributs personnalisés qui sont modifiés dans ODM (Object Data Manager), mais qui ne sont pas pris en compte (ces modifications prennent effet à l'heure de redémarrage de la partition logique). Lorsque la partition de substitution est démarrée, les attributs personnalisés prennent effet. Les périphériques de stockage peuvent ne pas avoir la même topologie multitrajet sur la partition de substitution que la partition d'origine.

Extensions de noyau en mobilité

Les extensions du noyau doivent faire l'objet de considérations particulières en matière de mobilité afin que la charge de travail ne soit pas interrompue. Pour la plupart des extensions du noyau, il suffit de les décharger sur la partition d'origine et de les recharger sur la partition de substitution.

Extension de noyau sécurisée

Par défaut, toutes les extensions de noyau chargées sur la partition d'origine doivent être identifiées comme sécurisées pour les opérations Live Update , sauf si vous l'avez remplacée par le paramètre kext_check dans le fichier /var/adm/ras/liveupdate/lvupdate.data .

En général, une extension de noyau est Sécurité pour l'opération Mise à jour active si l'extension de noyau connaît l'opération Mise à jour active ou n'a pas besoin d'être au courant de l'opération Mise à jour active . Une extension de noyau est réputée être Mise à jour active Sécurité si elle répond à l'une des conditions suivantes:

L'extension de noyau est chargée avec l'indicateur SYS_LUSAFE.
Le nom d'extension de noyau se trouve dans le fichier /etc/liveupdate/lvup_SafeKE.

Pour marquer l'extension de noyau comme Live Update sécurisée, les extensions de noyau peuvent être chargées à l'aide de l'appel sysconfig() avec l'indicateur SYS_LUSAFE défini dans le fichier sys/sysconfig.h .

Dans certaines extensions de noyau sécurisées, il se peut que l'indicateur SYS_LUSAFE ne soit pas défini. Vous pouvez les marquer comme sûres pour une opération Live Update à l'aide de la commande lvupdateSafeKE .

Les extensions de noyau sécurisé sont répertoriées dans le fichier /etc/liveupdate/lvup_safeKE. La duplication n'est pas autorisée dans cette liste. Chaque extension du noyau doit être listée avec son chemin complet.

Dans tous les modes, il est toujours validé que les extensions de noyau chargées sont sûres, même lorsque vous choisissez de ne pas appliquer l'exigence. Dans ce cas, l'opération Mise à jour active consigne les extensions de noyau non conformes, mais continue à fonctionner.

Chargement des extensions de noyau

Lorsque la partition de substitution est démarrée, elle charge uniquement les extensions de noyau associées aux périphériques configurées. Les commandes normales qui commencent généralement lors de l'initialisation régulière d'une partition logique peuvent ne pas démarrer. Par conséquent, certaines extensions de noyau requises par des applications de contrôle peuvent ne pas être chargées lorsque les applications sont redémarrées. Le cadre Mise à jour active offre plus d'un mécanisme pour gérer une telle situation:

Les applications avec des extensions de noyau peuvent être activées pour le contrôle s'ils gèrent le chargement et le déchargement des extensions de noyau. Le déchargement doit se produire avant le gel des applications et vous pouvez charger les extensions du noyau lorsque les applications sont redémarrées.
Les extensions de noyau peuvent être préchargées sur la partition de substitution avant le redémarrage des applications. Le cadre Mise à jour active offre un mécanisme d'enregistrement. Toutes les méthodes de chargement enregistrées pour l'opération Mise à jour active sont exécutées avant le redémarrage des applications. La commande lvupdateRegKE peut être utilisée pour ajouter ou supprimer des extensions de noyau à précharger.
Le chemin complet de l'extension de noyau est nécessaire. Dans une erreur de chargement, l'opération Mise à jour active est arrêtée.

Exemple d'interaction entre un processus et une extension de noyau.

Cet exemple montre comment l'interaction entre un processus et une extension de noyau doit être traitée. L'objectif de l'opération Mise à jour active est de préserver le comportement des charges de travail dans le processus de mise à jour.

Supposons qu'une application comprend un processus test_process et une extension de noyau test_ke. L'extension de noyau test_ke dispose d'un compteur de variables utilisé pour compter certains événements. Le processus test_process lit le compteur à partir de test_ke et le consomme lors de son exécution. Lorsque test_ke est chargé, le compteur est initialisé sur 0. La valeur du compteur augmente avec le temps. Dans l'opération Live Update , lorsque test_process est vérifié avec un point de contrôle, son état de processus est sauvegardé, mais la valeur de compteur n'est pas sauvegardée. Étant donné que les extensions du noyau ne font pas l'objet de contrôle, vous devez vous assurer que le compteur est préservé lorsqu'il est chargé sur la partition de substitution. Cette fonction est prise en charge par l'infrastructure DLPAR dans l'opération Live Update .

Les applications sont contrôlées sur la partition d'origine.
Une notification est envoyée aux extensions de noyau à la phase préalable.
L'extension de noyau test_ke utilise le service de noyau reconfig_register_list() pour enregistrer les gestionnaires de reconfiguration pour les événements DLPAR.
Dans le gestionnaire de la phase préalable, le compteur est enregistré dans le fichier /var/adm/ras/liveupdate/kext/test_ke. Ce fichier se trouve sur rootvg de sorte qu'il puisse être transféré vers la partition de substitution après la mise en miroir de la partition.
Sur la partition de substitution, la phase préalable est envoyée aux extensions de noyau après l'installation de l'environnement surr-mirr-rootvg. Cela signifie que les données sauvegardées pour l'extension de noyau test_ke, y compris le compteur de variables, sont maintenant disponibles. L'état de l'extension de noyau test_ke peut être reconfiguré pour correspondre à l'état lors de sa sauvegarde.