Actions effectuées par les scripts DLPAR

Les scripts d'application sont démarrés pour les opérations d'ajout et de suppression.

Lors de la suppression de ressources, des scripts sont fournis pour résoudre les conditions imposées par l'application qui empêchent la suppression de la ressource. La présence de liaisons de processeur particulières et l'absence de mémoire pouvant être détectée peuvent entraîner l'échec d'une demande de suppression. Un ensemble de commandes est fourni pour identifier ces situations, afin que des scripts puissent être écrits pour les résoudre.

Pour identifier et résoudre les dépendances DLPAR , les commandes suivantes peuvent être utilisées:

La commande ps affiche les pièces jointes du processeur de liaison et le statut d'appel système plock au niveau du processus.
La commande bindprocessor affiche les processeurs en ligne et crée de nouvelles connexions.
La commande kill envoie des signaux aux processus.
La commande ipcs affiche les segments de mémoire partagée épinglés au niveau du processus.
La commande lsrset affiche les ensembles de processeurs.
La commande lsclass affiche les classes Workload Manager , qui peuvent inclure des ensembles de processeurs.
La commande chclass permet de modifier les définitions de classe.

Les scripts peuvent également être utilisés pour des problèmes d'évolutivité et de performances générales. Lorsque des ressources sont supprimées, vous pouvez réduire le nombre d'unités d'exécution utilisées ou la taille des mémoires tampon d'application. Lorsque les ressources sont ajoutées, vous pouvez augmenter ces paramètres. Vous pouvez fournir des commandes qui peuvent être utilisées pour effectuer dynamiquement ces ajustements, qui peuvent être déclenchés par ces scripts. Installez les scripts pour démarrer ces commandes dans le contexte de l'opération DLPAR .

Structure de haut niveau des scripts DLPAR

Cette section fournit une présentation des scripts, qui peuvent être des scripts Perl , des scripts shell ou des commandes. Les scripts d'application sont requis pour fournir les commandes suivantes:

scriptinfo
Identifie la version, la date et le fournisseur du script. Il est appelé lorsque le script est installé.
pensez à vous inscrire
Identifie les ressources gérées par le script. Si le script renvoie le nom de ressource cpu, mem, capacity, ou var_weight, le script est automatiquement démarré lorsque DLPAR tente de reconfigurer les processeurs, la mémoire, capacité garantie, ou poids variable. La commande d'enregistrement est appelée lorsque le script est installé avec le sous-système DLPAR .
usage nom_ressource
Renvoie des informations décrivant la manière dont la ressource est utilisée par l'application. La description doit être pertinente pour que l'utilisateur puisse déterminer s'il doit installer ou désinstaller le script. Il doit identifier les capacités logicielles de l'application qui sont impactées. La commande usage est appelée pour chaque ressource identifiée par la commande register .
checkrelease nom_ressource
Indique si le sous-système DLPAR doit continuer à supprimer la ressource nommée. Un script peut indiquer que la ressource ne doit pas être supprimée si l'application n'est pas DLPARet qu'elle est considérée comme critique pour le fonctionnement du système.
prerelase nom_ressource
Reconfigure, suspend ou met fin à l'application de sorte que sa mise en attente sur la ressource nommée soit libérée.
postrelease nom_ressource
Reprend ou redémarre l'application.
undoprerelase nom_ressource
Démarré si une erreur est détectée et que la ressource n'est pas libérée.
checkget nom_ressource
Indique si le sous-système DLPAR doit procéder à l'ajout de ressources. Il peut être utilisé par un gestionnaire de licence pour empêcher l'ajout d'une nouvelle ressource, par exemple cpu, jusqu'à ce que la ressource soit sous licence.
preget nom_ressource
Utilisé pour préparer un ajout de ressource.
undopreacquérir nom_ressource
Démarre si une erreur est détectée lors de la phase de préacquisition ou lorsque l'événement est traité.
postacquire nom_ressource
Reprend ou démarre l'application.
preaccevent nom_ressource
Utilisé pour préparer une mise à jour DLPAR .
postaccevent nom_ressource
Reprend ou démarre l'application.
undopreaccevent nom_ressource
Démarré si une erreur est détectée lors de la phase preaccevent ou lorsque l'événement est traité.
pretopolgyupdate nom_ressource
Utilisé pour préparer une mise à jour de la topologie du système.
postopolgyupdate nom_ressource
Reprend ou démarre l'application.

Installation de scripts d'application à l'aide de la commande drmgr

La commande drmgr gère une base de données interne contenant des informations sur les scripts installés. Ces informations sont collectées lors de l'amorçage du système et sont actualisées lorsque de nouveaux scripts sont installés ou désinstallés. Les informations sont dérivées des commandes scriptinfo, registeret usage . L'installation des scripts est prise en charge dans la commande drmgr , qui copie le script nommé dans le référentiel de scripts où il sera accessible ultérieurement. L'emplacement par défaut de ce référentiel est /usr/lib/dr/scripts/all. Dans les partitions de charge de travail, l'emplacement du référentiel de script par défaut est /var/dr/scripts. Vous pouvez spécifier un autre emplacement pour ce référentiel. Pour déterminer la machine sur laquelle un script est utilisé, indiquez le nom d'hôte cible lors de l'installation du script.

Pour spécifier l'emplacement du référentiel de base, utilisez la commande suivante:

drmgr -R base_directory_path

Pour installer un script, utilisez la commande suivante:

drmgr -i script_name [-f] [-w mins] [-D hostname]

Les indicateurs suivants sont définis:

L'indicateur -i est utilisé pour nommer le script.
L'indicateur -f doit être utilisé pour remplacer un script enregistré.
L'indicateur -w est utilisé pour spécifier le nombre de minutes pendant lequel le script doit s'exécuter. Il s'agit d'une option de substitution de la valeur spécifiée par le fournisseur.
L'indicateur -D permet d'enregistrer un script à utiliser sur un hôte particulier.

Pour désinstaller un script, utilisez la commande suivante:

drmgr -u script_name [-D hostname]

Les indicateurs suivants sont définis:

L'indicateur -u est utilisé pour indiquer le script à désinstaller.
L'indicateur -D permet de désinstaller un script qui a été enregistré pour un répertoire spécifique.

Pour afficher des informations sur les scripts déjà installés, utilisez la commande suivante:

drmgr -l

Conventions de dénomination pour les scripts

Il est conseillé de générer les noms de script à partir du nom du fournisseur et du sous-système contrôlé. Les administrateurs système doivent nommer leurs scripts avec le préfixe sysadmin . Par exemple, un administrateur système qui souhaite fournir un script pour contrôler les affectations de Workload Manager peut nommer le script sysadmin_wlm.

Environnement d'exécution de script et paramètres d'entrée

Les scripts sont démarrés avec l'environnement d'exécution suivant:

L'ID utilisateur du processus est défini sur l'ID utilisateur du script.
Le GID de processus est défini sur le GID du script.
La variable d'environnement PATH est définie sur le répertoire /usr/bin:/etc:/usr/sbin .
La variable d'environnement LANG peut ou non être définie.
Le répertoire de travail en cours est défini sur /tmp.
Les arguments de commande et les variables d'environnement sont utilisés pour décrire l'événement DLPAR .

Les scripts reçoivent des paramètres d'entrée via des arguments de commande et des variables d'environnement, et fournissent une sortie en écrivant des paires name=value dans la sortie standard, où les paires name=value sont délimitées par de nouvelles lignes. Le nom est défini comme étant le nom de l'élément de données de retour attendu, et valeur est la valeur associée à l'élément de données. Les chaînes de texte doivent être placées entre parenthèses ; par exemple, DR_ERROR="text". Toutes les variables d'environnement et les paires name=value doivent commencer par DR_, qui est réservé pour la communication avec les scripts d'application.

Les scripts utilisent la paire de variables d'environnement DR_ERROR nom=valeur pour fournir des descriptions d'erreur.

Vous pouvez examiner les arguments de commande du script pour déterminer la phase de l'opération DLPAR , le type d'action et le type de ressource qui fait l'objet de la demande DLPAR en attente. Par exemple, si les arguments de la commande de script sont checkrelease mem, la phase est check, l'action est removeet le type de ressource est memory. La ressource spécifique impliquée peut être identifiée en examinant les variables d'environnement.

Les variables d'environnement suivantes sont définies pour l'ajout et le retrait de mémoire:

Remarque: dans la description suivante, un cadre est égal à 4 Ko.

DR_FREE_FRAMES=0xFFFFFFFF
Nombre de cadres disponibles actuellement dans le système, au format hexadécimal.
DR_MEM_SIZE_COMPLETED = n
Nombre de mégaoctets ajoutés ou supprimés avec succès, au format décimal.
DR_MEM_SIZE_REQUEST = n
Taille de la demande de mémoire en mégaoctets, au format décimal.
DR_PINNABLE_FRAMES=0xFFFFFFFF
Nombre total de cadres pouvant être repérés actuellement dans le système, au format hexadécimal. Ce paramètre fournit des informations utiles lors de la suppression de mémoire car il peut être utilisé pour déterminer à quel moment le système approche de la limite de la mémoire pouvant être réservée, qui est la cause principale de l'échec des demandes de suppression de mémoire.
DR_TOTAL_FRAMES=0xFFFFFFFF
Nombre total de trames actuellement dans le système, au format hexadécimal.

Les variables d'environnement suivantes sont définies pour l'ajout et la suppression de processeurs:

DR_BCPUID = N
ID UC de liaison du processeur ajouté ou supprimé au format décimal. Une connexion bindprocessor à ce processeur ne signifie pas nécessairement que la connexion doit être annulée. Cela n'est vrai que s'il s'agit du Nème processeur du système, car la position du Nème processeur est celle qui est toujours supprimée lors d'une opération de suppression de l'unité centrale. Les ID de liaison sont de nature consécutive, allant de 0 à N et sont destinés à identifier uniquement les processeurs en ligne. Utilisez la commande bindprocessor pour déterminer le nombre d'UC en ligne.
DR_LCPUID = N
ID d'unité centrale logique (UC) du processeur qui est ajouté ou supprimé au format décimal.

Les variables d'environnement suivantes sont définies pour le micropartitionnement.

DR_CPU_CAPACITY=N: Pourcentage de processeurs physiques partagés de la partition.
DR_VAR_WEIGHT=N: Priorité relative de la partition pour déterminer comment allouer des cycles d'inactivité de pool partagé.
DR_CPU_CAPACITY_DELTA=N: Différence entre la valeur actuelle du pourcentage de processeurs physiques partagés de la partition et la valeur vers laquelle elle sera modifiée lorsque cette opération sera terminée.
DR_VAR_WEIGHT_DELTA=N: Différence entre la valeur en cours de la pondération de la variable de la partition et la valeur à laquelle elle sera modifiée une fois cette opération terminée.

L'opérateur peut afficher les informations relatives à la demande DLPAR en cours à l'aide du niveau de détail de la console HMC pour observer les événements au fur et à mesure qu'ils se produisent. Ce paramètre est spécifié dans le script à l'aide de la variable d'environnement DR_DETAIL_LEVEL=N , où N peut être compris entre 0 et 5. La valeur par défaut est zéro (0) et ne signifie aucune information. Une valeur de un (1) est réservée au système d'exploitation et est utilisée pour présenter le flux de haut niveau. Les niveaux restants (2-5) peuvent être utilisés par les scripts pour fournir des informations en supposant que des nombres plus grands fournissent plus de détails.

Les scripts fournissent des données détaillées en écrivant les paires name=value suivantes dans la sortie standard:

paire nom=valeur	Descriptif
DR_LOG_ERR = message	Consigne le message avec le niveau syslog de la variable d'environnement LOG_ERR .
DR_LOG_WARNING = message	Consigne le message avec le niveau syslog de la variable d'environnement LOG_WARNING .
DR_LOG_INFO = message	Consigne le message avec le niveau syslog de la variable d'environnement LOG_INFO .
DR_LOG_EMERG = message	Consigne le message avec le niveau syslog de la variable d'environnement LOG_EMERG .
DR_LOG_DEBUG = message	Consigne le message avec le niveau syslog de la variable d'environnement LOG_DEBUG .

En outre, l'opérateur peut également configurer un journal d'informations qui est conservé à l'aide de la fonction syslog , auquel cas les informations ci-dessus sont également acheminées vers cette fonction. Dans ce cas, vous devez configurer la fonction syslog .

Commandes de scriptDLPAR

Cette section décrit les commandes de script pour DLPAR:

scriptinfo: Fournit des informations sur les scripts installés, telles que leur date de création et leurs ressources.
pensez à vous inscrire: a commencé à collecter la liste des ressources qui sont gérées par le script. La commande drmgr utilise ces listes pour démarrer des scripts en fonction du type de ressource en cours de reconfiguration.
syntaxe: Fournit des chaînes lisibles décrivant le service fourni par la ressource nommée. Le contexte du message doit aider l'utilisateur à déterminer les implications sur l'application et les services qu'elle fournit lorsque la ressource nommée est reconfigurée. Cette commande est démarrée lorsque le script est installé et les informations fournies par cette commande sont conservées dans une base de données interne utilisée par la commande drmgr . Affichez les informations à l'aide de l'option de liste -l de la commande drmgr .
Edition de contrôle: Lors de la suppression de ressources, la commande drmgr évalue les impacts de la suppression de la ressource. Cela inclut l'exécution des scripts DLPAR qui implémentent la commande checkrelease . Chaque script DLPAR peut à son tour évaluer les particularités de son application et indiquer à la commande drmgr qui utilise le code retour du script si la suppression de la ressource affecte l'application associée. S'il détecte que la suppression de la ressource peut être effectuée en toute sécurité, un statut de sortie de réussite est renvoyé. Si l'application est dans un état où la ressource est critique pour son exécution et ne peut pas être reconfigurée sans interrompre l'exécution de l'application, le script indique que la ressource ne doit pas être supprimée en renvoyant une erreur. Lorsque l'option FORCE est spécifiée par l'utilisateur, qui s'applique à l'ensemble de l'opération DLPAR , y compris ses phases, la commande drmgr ignore la commande checkrelease et commence par les commandes prerelase .
préversion: Avant la libération d'une ressource, les scripts DLPAR sont dirigés pour aider à la libération de la ressource nommée en réduisant ou en éliminant l'utilisation de la ressource de l'application. Toutefois, si le script détecte que la ressource ne peut pas être libérée de l'application, il doit indiquer que la ressource ne sera pas supprimée de l'application en renvoyant une erreur. Cela n'empêche pas le système de tenter de supprimer la ressource dans le mode d'exécution forcé ou non, et le script sera appelé lors de la phase de post-traitement, quelles que soient les actions ou inactions effectuées par la commande prerelase . Les actions effectuées par le système d'exploitation sont sûres. Si une ressource ne peut pas être supprimée proprement, l'opération échouera.
Le script DLPAR est censé enregistrer en interne les actions qui ont été effectuées par la commande prerelase , afin qu'elles puissent être restaurées lors de la phase de post-traitement en cas d'erreur. Cela peut également être géré après la phase si la nouvelle reconnaissance est implémentée. L'application peut avoir besoin de prendre des mesures sévères si l'option force est spécifiée.
Post-bail: Une fois qu'une ressource a été libérée, la commande postrelease pour chaque script DLPAR installé est démarrée. Chaque script DLPAR effectue le post-traitement requis lors de cette étape. Les applications qui ont été arrêtées doivent être redémarrées.
Le programme appelant ignore toutes les erreurs signalées par les commandes postrelease et l'opération est considérée comme une réussite, bien qu'une indication des erreurs qui peuvent s'être produites soit également signalée à l'utilisateur. Le message de variable d'environnement DR_ERROR est fourni à cette fin, de sorte que le message doit identifier l'application qui n'a pas été correctement reconfigurée.
undoprerelase: Une fois qu'une commande prerelase est émise par la commande drmgr dans le script DLPAR , si la commande drmgr ne parvient pas à supprimer ou à libérer la ressource, elle tente de rétablir l'ancien état. Dans le cadre de ce processus, la commande drmgr émet la commande undoprerelase sur le script DLPAR . La commande undoprerelase ne sera démarrée que si le script a été précédemment appelé pour libérer la ressource dans la demande DLPAR en cours. Dans ce cas, le script doit annuler toutes les actions effectuées par la commande prerelase du script. A cette fin, le script peut avoir besoin de documenter ses actions ou de fournir la possibilité de reconnaître à nouveau l'état du système et de reconfigurer l'application, de sorte que l'événement DLPAR ne se soit jamais produit.
checkacquérir: Cette commande est la première commande basée sur un script DLPAR appelée dans la séquence d'acquisition de nouvelles ressources. Il est appelé pour chaque script installé qui a précédemment indiqué qu'il prenait en charge le type particulier de ressource ajouté. L'un des principaux objectifs de la phase d'acquisition de contrôle est d'activer les gestionnaires de licences basées sur le processeur, qui peuvent vouloir faire échouer l'ajout d'un processeur. La commande checkacquérir est toujours démarrée, quelle que soit la valeur de la variable d'environnement FORCE , et le programme appelant respecte le code retour du script. L'utilisateur ne peut pas forcer l'ajout d'un nouveau processeur si un script ou un programme DLPARne parvient pas à exécuter l'opération DLPAR lors de la phase de vérification.
En résumé, la variable d'environnement FORCE ne s'applique pas vraiment à la commande checkacquérir , bien qu'elle s'applique aux autres phases. Dans la phase de préacquisition, il détermine jusqu'où le script doit aller lors de la reconfiguration de l'application. L'option force peut être utilisée par les scripts pour contrôler la règle selon laquelle les applications sont arrêtées et redémarrées comme lorsqu'une ressource est libérée, ce qui est généralement un problème DLPAR-safe.
pré-acquisition: En supposant qu'aucune erreur n'a été signalée lors de la phase d'acquisition de contrôle, le système passe à la phase de préacquisition, où le même ensemble de scripts est appelé pour préparer l'acquisition d'une nouvelle ressource, qui est prise en charge par la commande preacquérir . Chacun de ces scripts est appelé, avant que le système ne tente réellement d'intégrer la ressource, sauf si une erreur a été signalée et que la variable d'environnement FORCE n'a pas été spécifiée par l'utilisateur. Si la variable d'environnement FORCE a été spécifiée, le système passe à l'étape d'intégration, quel que soit le code retour indiqué par le script. Aucune erreur n'est détectée lorsque la variable d'environnement FORCE est spécifiée, car toutes les erreurs peuvent être évitées en annulant la configuration de l'application, ce qui est une pratique acceptée lorsque la variable d'environnement FORCE est spécifiée. Si une erreur est détectée et que la variable d'environnement FORCE n'est pas spécifiée, le système passe à la phase de non-acquisition, mais seuls les scripts précédemment exécutés dans la phase en cours sont réexécutés. Au cours de cette dernière phase, les scripts sont dirigés pour effectuer des actions de reprise.
Undopreacquérir: La phase de non-acquisition est prévue pour que les scripts puissent effectuer des opérations de récupération. Si un script est appelé dans la phase de non-acquisition, il peut supposer qu'il a correctement exécuté la commande preacquérir .
postacquérir: La commande postacquire est exécutée une fois que la ressource a été correctement intégrée par le système. Chaque script DLPAR précédemment appelé dans les phases de vérification et de prétraitement est à nouveau appelé. Cette commande permet d'incorporer la nouvelle ressource dans l'application. Par exemple, l'application peut vouloir créer de nouvelles unités d'exécution, développer ses mémoires tampon ou l'application peut avoir besoin d'être redémarrée si elle a été précédemment arrêtée.
migration de contrôle: Cette commande est la première commande basée sur un script DLPAR appelée dans la séquence de migration. Il est appelé pour chaque script installé qui a précédemment indiqué qu'il prenait en charge le type particulier de ressource ajouté. La commande checkmigrate est toujours démarrée, quelle que soit la valeur de la variable d'environnement FORCE , et le programme appelant respecte le code retour du script. L'utilisateur ne peut pas forcer la migration de la partition si un script ou un programme compatible DLPAR échoue à l'opération DLPAR lors de la phase de vérification.
prémigrer: En supposant qu'aucune erreur n'a été signalée lors de la phase checkmigrate , le système passe à la phase premigrate , au cours de laquelle le même ensemble de scripts est démarré pour la préparation de la partition. Chacun de ces scripts est appelé, avant que le système ne tente réellement de migrer la partition. Quel que soit le code retour indiqué par le script, le système passe à l'étape de migration. Si une erreur est détectée, le système passe à la phase undopremigrate , mais seuls les scripts précédemment exécutés dans la phase en cours sont réexécutés. Au cours de cette dernière phase, les scripts sont dirigés pour effectuer des actions de reprise.
Undopremigrate: La phase undopremigrate est fournie pour que les scripts puissent effectuer des opérations de reprise. Si un script est appelé dans la phase undopremigrate , il peut supposer qu'il a correctement exécuté la commande premigrate .
post-migration: La commande postmigrate est exécutée après la migration de la partition. Chaque script DLPAR précédemment appelé dans les phases de vérification et de prétraitement est de nouveau appelé.
pretopologyupdate: La commande pretopologyupdate est exécutée avant l'exécution d'une action qui affecte la topologie de la partition, telle que l'ajout ou le retrait de processeurs ou de mémoire. Cette commande est destinée à informer les scripts qu'une action de topologie a eu lieu et qu'elle ne peut pas échouer. Le système passe à l'étape d'intégration, quel que soit le code retour indiqué dans le script.
posttopologiemise à jour: La commande posttopologyupdate est exécutée une fois que la partition a terminé avec succès l'action de topologie. Chaque script DLPAR précédemment appelé dans la phase préalable est de nouveau appelé.
Checkhibernate: Cette commande est la première commande DLPAR basée sur un script qui est appelée dans la séquence d'hibernation. Il est appelé pour chaque script installé qui a précédemment indiqué qu'il prenait en charge le type particulier de ressource ajouté. La commande checkhibernate est toujours démarrée, quelle que soit la valeur de la variable d'environnement FORCE , et le programme appelant respecte le code retour du script. L'utilisateur ne peut pas forcer l'hibernation de la partition si un script ou un programme compatible DLPAR échoue à l'opération DLPAR lors de la phase de vérification.
préhibernate: En supposant qu'aucune erreur n'a été signalée lors de la phase checkhibernate , le système passe à la phase prehibernate , où le même ensemble de scripts est démarré pour préparer la partition. Chacun de ces scripts est appelé, avant que le système ne tente réellement d'hiberner la partition. Quel que soit le code retour indiqué du script, le système passe à l'étape d'hibernation. Si une erreur est détectée, le système passe à la phase undohibernate , mais seuls les scripts précédemment exécutés dans la phase en cours sont réexécutés. Au cours de cette dernière phase, les scripts sont dirigés pour effectuer des actions de reprise.
Undohibernate: La phase undohibernate est fournie pour que les scripts puissent effectuer des opérations de reprise. Si un script est appelé dans la phase checkhibernate, il peut supposer qu'il a correctement exécuté la commande checkhibernate .
posthibérnate: La commande posthibernate est exécutée une fois que la partition a été correctement mise en hibernation. Chaque script DLPAR précédemment appelé dans les phases de vérification et de prétraitement est à nouveau appelé.

pré-événement: Cette commande est la première commande DLPAR basée sur un script qui est appelée dans la séquence DLPAR de l'accélérateur de chiffrement. Il est appelé pour chaque script installé qui a précédemment indiqué qu'il prenait en charge le type particulier de ressource ajoutée ou publiée. Il est inconnu au moment de cet événement si l'action suivante correspond à un ajout ou à une édition de l'accélérateur de chiffrement. Cette action sera fournie lors de l'une des phases suivantes.
Postaccevent: La commande postaccevent est exécutée une fois que la ressource a été correctement traitée par le système. Chaque script DLPAR précédemment appelé lors de la préphase est de nouveau appelé. Cette commande permet d'incorporer le nouvel état de la ressource dans l'application.
annuler l'événement: La phase undoaccevent est fournie pour que les scripts puissent effectuer des opérations de récupération. Si un script est appelé lors de la phase undoaccevent , il a correctement exécuté la commande preaccevent .