Intégration de l'opération DLPAR dans l'application

L'opération DLPAR peut être intégrée à l'application de l'une des manières suivantes:

  • Utilisation d'une approche basée sur un script, dans laquelle l'utilisateur installe un ensemble de scripts DLPAR dans un répertoire. Ces scripts sont appelés lors de l'exécution de l'opération DLPAR . Les scripts sont conçus pour reconfigurer l'application en externe.
  • A l'aide du signal SIGRECONFIG , qui est utilisé pour intercepter le signal de chaque processus enregistré. La méthode du signal suppose que l'application a été codée pour intercepter le signal, et que le gestionnaire de signaux va reconfigurer l'application. Le gestionnaire de signaux appelle une interface pour déterminer la nature de l'opération DLPAR .

Ces deux méthodes suivent la même structure de haut niveau. L'une ou l'autre méthode peut être utilisée pour prendre en charge DLPAR, bien que seul le mécanisme basé sur un script puisse être utilisé pour gérer les dépendances DLPAR liées aux partitions logicielles Workload Manager (ensembles de processeurs). Aucune API n'étant associée à Workload Manager, l'utilisation d'un gestionnaire de signaux n'est pas un moyen approprié pour traiter les contraintes de planification imposées par Workload Manager. Les applications elles-mêmes ne sont pas compatibles avec Workload Manager. Dans ce cas, l'administrateur système peut vouloir fournir un script qui appelle les commandes Workload Manager pour gérer les interactions DLPAR avec Workload Manager.

La décision quant à la méthode à utiliser doit être basée sur la façon dont le système ou la logique spécifique aux ressources a été introduit dans l'application. Si l'application a été dirigée en externe pour utiliser un nombre spécifique d'unités d'exécution ou pour dimensionner ses mémoires tampon, utilisez l'approche basée sur un script. Si l'application connaît directement la configuration du système et utilise ces informations en conséquence, utilisez l'approche basée sur le signal.

L'opération DLPAR elle-même est divisée en plusieurs phases:
  • phase de vérification

    La phase de vérification est appelée en premier et permet aux applications de faire échouer la demande DLPAR en cours avant de changer l'état du système. Par exemple, la phase de vérification peut être utilisée par un gestionnaire de licence basé sur l'UC pour faire échouer l'intégration d'un nouveau processeur si l'ajout d'UC fait que le nombre de processeurs dans le système dépasse le nombre de processeurs sous licence. Il peut également être utilisé pour préserver la sécurité DLPAR d'un programme qui n'est pas sécurisé par DLPAR. Dans ce dernier cas, il faut tenir compte des services fournis par l'application, car il peut être préférable d'arrêter le programme, de terminer la demande, puis de redémarrer le programme.

  • pré-phase et post-phase

    Les éléments pre phase et post phase sont fournis pour arrêter le programme, terminer la demande, puis redémarrer le programme.

Le système tente de s'assurer que tout le code de vérification sur les différents supports est exécuté dans son intégralité au niveau du système avant que l'événement DLPAR passe à la phase suivante.