Utilisation de Dynamic Processor Deallocation

Editer en ligne

A partir du type de machine 7044 modèle 270, le matériel de tous les systèmes avec plus de deux processeurs peut détecter des erreurs corrigeables, qui sont collectées par le microprogramme. Ces erreurs ne sont pas fatales et, dans la mesure où elles demeurent rares, peuvent être ignorées en toute sécurité. Cependant, lorsqu'un schéma de défaillances semble se développer sur un processeur spécifique, ce schéma peut indiquer que ce composant est susceptible de présenter une défaillance irrémédiable dans un avenir proche. Cette prévision est effectuée par l'analyse des seuils et des taux d'échec basés sur le microprogramme.

AIX met en œuvre une surveillance continue du matériel et interroge régulièrement le microprogramme pour détecter les erreurs matérielles. Lorsque le nombre d'erreurs de processeur atteint un seuil et que le microprogramme reconnaît la probabilité distincte d'échec de ce composant système, le microprogramme renvoie un rapport d'erreur à AIX et consigne l'erreur dans le journal des erreurs système. En outre, sur les systèmes multiprocesseurs, en fonction du type d'échec, AIX tente d'arrêter d'utiliser le processeur non digne de confiance et de le libérer. Ce dispositif est appelé désallocation de processeur dynamique.

A ce stade, le microprogramme marque le processeur pour la libération persistante pour les réamorçages ultérieurs, jusqu'à ce que le personnel de maintenance le remplace.

Impact potentiel sur les applications

La désallocation de processeur n'est pas apparente pour la grande majorité des applications, y compris les pilotes et les extensions de noyau. Toutefois, vous pouvez utiliser les interfaces publiées AIX pour déterminer si une application ou une extension de noyau s'exécute sur une machine multiprocesseur, déterminer le nombre de processeurs existants et lier des unités d'exécution à des processeurs spécifiques.

L'interface bindprocessor de liaison des processus ou des unités d'exécution aux processeurs utilise des numéros d'UC de liaison. Les numéros d'UC de liaison sont compris dans la plage [ 0 ..N-1 ], où N est le nombre total d'UC. Pour éviter d'interrompre des applications ou des extensions de noyau qui supposent qu'il n'y a pas de "trous" dans la numérotation des unités centrales, AIX fait toujours apparaître les applications comme si l'unité centrale était la "dernière" (numéro le plus élevé) unité centrale de liaison à libérer. Par exemple, sur un multiprocesseur symétrique (SMP) à 8 voies, les numéros d'UC de liaison sont [0 .. 7]. Si un processeur est désinstallé, 7 UC sont disponibles au total, et la numérotation devient [0 .. 6]. En externe, l'unité centrale 7 semble avoir disparu, quel que soit le processeur physique défaillant.

Remarque: Dans la suite de cette description, le terme UC est utilisé pour l'entité logique et le terme processeur pour l'entité physique.

Les applications ou les extensions de noyau utilisant des processus / liaisons d'unités d'exécution peuvent être potentiellement rompues si AIX a arrêté en mode silencieux ses unités d'exécution liées ou les a déplacées de force vers une autre unité centrale lorsque l'un des processeurs doit être libéré. La désallocation de processeur dynamique fournit des interfaces de programmation pour que ces applications et extensions de noyau puissent être averties qu'une désallocation de processeur est sur le point de se produire. Lorsque ces applications et ces extensions de noyau reçoivent cette notification, elles sont chargées de déplacer leurs unités d'exécution liées et les ressources associées (telles que les blocs de requête de temporisateur) hors du dernier ID d'unité centrale de liaison et de s'adapter à la nouvelle configuration d'unité centrale.

Si, après notification des applications et des extensions de noyau, certaines des unités d'exécution sont toujours liées au dernier ID UC de liaison, la désallocation est abandonnée. Dans ce cas, AIX consigne le fait que la désallocation a été abandonnée dans le journal des erreurs et continue à utiliser le processeur de fin. Lorsque le processeur tombe en panne, il crée une défaillance totale du système. Par conséquent, il est important pour les applications ou les extensions de noyau qui lient des unités d'exécution à des UC d'obtenir la notification d'une désallocation imminente du processeur, et d'agir sur cette notification.

Même dans les rares cas où la désallocation ne peut pas passer, la désallocation de processeur dynamique émet toujours un avertissement avancé aux administrateurs système. En enregistrant l'erreur dans le journal des erreurs, ils ont la possibilité de planifier une opération de maintenance sur le système pour remplacer le composant défaillant avant qu'une panne globale du système ne se produise.

Flux d'événements pour la désallocation du processeur

Le flux standard d'événements pour la libération du processeur est le suivant :

Le microprogramme détecte qu'un seuil d'erreur remédiable a été atteint par l'un des processeurs.
AIX consigne le rapport d'erreur du microprogramme dans le journal des erreurs système et, lors de l'exécution sur une machine prenant en charge la désallocation du processeur, démarre le processus de désallocation.
AIX notifie les processus non liés au noyau et les unités d'exécution liées à la dernière unité centrale de liaison.
AIX attend que toutes les unités d'exécution liées s'éloignent de la dernière unité centrale de liaison. Si les unités d'exécution restent liées, AIX arrive à expiration (au bout de dix minutes) et abandonne la libération. Sinon, AIX appelle les gestionnaires d'événements à haute disponibilité précédemment enregistrés (HAEHs). Un HAEH peut renvoyer une erreur qui interrompt le désallocation. Sinon, AIX poursuit le processus de désallocation et arrête le processeur défaillant.

En cas d'échec à n'importe quel point de la désallocation, AIX consigne l'échec, en indiquant la raison pour laquelle la désallocation a été abandonnée. L'administrateur système peut consulter le journal des erreurs, prendre des mesures correctives (si possible) et redémarrer la libération. Par exemple, si la désallocation a été abandonnée parce qu'au moins une application n'a pas délié ses unités d'exécution liées, l'administrateur système peut arrêter la ou les applications, redémarrer la désallocation (qui doit se poursuivre cette fois) et redémarrer l'application.

Interfaces de programmation avec des processeurs individuels

Les sections suivantes décrivent les interfaces de programmation disponibles:

Interfaces permettant de déterminer le nombre d'UC sur un système

Sous-routine sysconf

La sous-routine sysconf renvoie un certain nombre de processeurs à l'aide des paramètres suivants:

_SC_NPROCESSORS_CONF: Nombre de processeurs configurés
_SC_NPROCESSORS_ONLN: Nombre de processeurs en ligne

Valeur renvoyée par la sous-routine sysconf pour_SC_NPROCESSORS_CONFrestera constante entre les réamorçages. Les machines uniprocesseur (UP) sont identifiées par un 1. Les valeurs supérieures à 1 indiquent les machines multiprocesseurs (MP). La valeur renvoyée pour le paramètre _SC_NPROCESSORS_ONLN correspond au nombre d'UC actives et est décrémentée chaque fois qu'un processeur est libéré.

La zone _system_configuration.ncpus identifie le nombre d'UC actives sur une machine. Cette zone est similaire au paramètre _SC_NPROCESSOR_ONLN .

Pour le code qui doit reconnaître le nombre de processeurs initialement disponibles lors de l'amorçage, la zone ncpus_cfg est ajoutée à la_system_configurationqui reste constante entre les réamorçages.

Les UC sont identifiées par des ID UC de liaison dans la plage [ 0 .. (ncpus-1) ]. Les processeurs possèdent également un numéro d'unité centrale physique qui dépend de la carte d'unité centrale sur laquelle ils se trouvent, de l'ordre dans lequel ils se trouvent, etc. Les commandes et les sous-routines traitant des numéros d'unité centrale utilisent toujours des numéros d'unité centrale de liaison. Pour faciliter la transition vers des nombres variables d'UC, les numéros d'UC de liaison sont des nombres contigus dans la plage [ 0 .. (ncpus-1). Cela a pour effet que, du point de vue de l'utilisateur, lorsqu'une désallocation de processeur a lieu, elle ressemble toujours au numéro le plus élevé ("dernier") L'unité centrale de liaison est en train de disparaître, quel que soit le processeur physique défaillant.

Remarque: Pour éviter les problèmes, utilisez la variable ncpus_cfg pour déterminer quel est le numéro d'unité centrale de liaison le plus élevé possible pour un système particulier.

Interfaces permettant de lier des unités d'exécution à un processeur spécifique

La commande bindprocessor et l'interface de programmation bindprocessor vous permettent de lier une unité d'exécution ou un processus à une unité centrale spécifique, désignée par son numéro d'unité centrale de liaison. Les deux interfaces vous permettent de lier des unités d'exécution ou des processus uniquement à des unités centrales actives. Les programmes qui utilisent directement l'interface de programmation bindprocessor ou qui sont liés en externe par une commande bindprocessor doivent pouvoir gérer la désallocation du processeur.

Le principal problème détecté par les programmes qui se lient à un processeur lorsqu'une unité centrale a été libérée est que les demandes de liaison à un processeur libéré échoueront. Le code qui émet des demandes bindprocessor doit toujours vérifier la valeur de retour de ces demandes.

Interfaces de notification de libération du processeur

Le mécanisme de notification est différent pour les applications en mode utilisateur dont les unités d'exécution sont liées à la dernière unité centrale de liaison et pour les extensions de noyau.

Notification en mode utilisateur

Chaque unité d'exécution d'une application en mode utilisateur liée à la dernière unité centrale de liaison reçoit les signaux SIGCPUFAIL et SIGRECONFIG . Ces applications doivent être modifiées pour intercepter ces signaux et éliminer les unités d'exécution liées à la dernière unité centrale de liaison (en les déliant ou en les liant à une unité centrale différente).

Notification en mode noyau

Les pilotes et les extensions de noyau qui doivent être notifiés de l'imminence d'un désallocation de processeur doivent enregistrer une routine HAEH (High-Availability Event Handler) auprès du noyau. Cette routine est appelée lorsqu'une désallocation de processeur est imminente. Une interface est également fournie pour désenregistrer le HAEH avant que l'extension de noyau ne soit déconfigurée ou déchargée.

Enregistrement d'un gestionnaire d'événements à haute disponibilité

Le noyau exporte une nouvelle fonction pour permettre la notification des extensions du noyau en cas d'événements qui affectent la disponibilité du système.

L'appel système est:

int register_HA_handler(ha_handler_ext_t *)

Pour plus d'informations sur cet appel système, voir register_HA_handler dans Operating system and device management.

La valeur de retour est égale à 0 en cas de réussite. Une valeur différente de zéro indique un échec.

L'argument d'appel système est un pointeur vers une structure décrivant le HAEH de l'extension du noyau. Cette structure est définie dans un fichier d'en-tête nommé sys/high_avail.h, comme suit:

typedef struct _ha_handler_ext_ { 
    int (*_fun)();        /* Function to be invoked */ 
    long long _data;      /* Private data for (*_fun)() */ 
    char        _name[sizeof(long long) + 1]; 
} ha_handler_ext_t;

La zone _data privée est fournie pour l'utilisation de l'extension de noyau si nécessaire. Toute valeur donnée dans cette zone au moment de l'enregistrement sera transmise en tant que paramètre à la fonction enregistrée lorsque la zone est appelée en raison d'un événement d'échec prédictif de l'unité centrale.

La zone _name est une chaîne à terminaison nulle d'une longueur maximale de 8 caractères (à l'exclusion du caractère de fin null) qui est utilisée pour identifier de manière unique l'extension du noyau avec le noyau. Ce nom doit être unique parmi toutes les extensions de noyau enregistrées. Ce nom est répertorié dans la zone de données détaillées de laCPU_DEALLOC_ABORTEDentrée du journal des erreurs si l'extension du noyau renvoie une erreur lorsque la routine HAEH est appelée par le noyau.

Les extensions de noyau ne doivent enregistrer leur HAEH qu'une seule fois.

Appel du gestionnaire d'événements à haute disponibilité

Les paramètres suivants appellent la routine HAEH:

Valeur de la zone _data de la structure ha_handler_ext_t transmise à register_HA_handler.

Un pointeur vers une structure ha_event_t définie dans le fichier sys/high_avail.h comme suit:

typedef struct {                    /* High-availability related event */ 
    uint _magic;                    /* Identifies the kind of the event */ 
#define HA_CPU_FAIL 0x40505546      /* "CPUF" */ 
    union { 
        struct {                   /* Predictive processor failure */ 
            cpu_t dealloc_cpu;     /* CPU bind ID of failing processor */ 
                       ushort domain;         /* future extension */ 
            ushort nodeid;         /* future extension */ 
            ushort reserved3;      /* future extension */ 
            uint reserved[4];      /* future extension */ 
        } _cpu; 
        /* ... */                  /* Additional kind of events -- */ 
        /* future extension */ 
    } _u; 
} haeh_event_t;

La fonction renvoie l'un des codes suivants, également définis dans le fichier sys/high_avail.h :

#define HA_ACCEPTED 0     /* Positive acknowledgement */ 
#define HA_REFUSED -1     /* Negative acknowledgement */

Si l'une des extensions enregistrées ne renvoie pas HA_ACCEPTED, la désallocation est abandonnée. Les routines HAEH sont appelées dans l'environnement de processus et n'ont pas besoin d'être épinglées.

Si une extension de noyau dépend de la configuration de l'unité centrale, sa routine HAEH doit réagir à la prochaine désallocation de l'unité centrale. Cette réaction est fortement dépendante de l'application. Pour permettre à AIX de procéder à la déconfiguration, ils doivent déplacer les unités d'exécution qui sont liées à la dernière unité centrale de liaison, le cas échéant. De plus, s'ils ont utilisé des temporisateurs démarrés à partir d'unités d'exécution liées, ces temporisateurs seront déplacés vers une autre unité centrale dans le cadre de la désallocation de l'unité centrale. S'ils dépendent de ces temporisateurs livrés à une unité centrale spécifique, ils doivent prendre des mesures (par exemple, les arrêter) et redémarrer leurs demandes de temporisation lorsque les unités d'exécution sont liées à une nouvelle unité centrale, par exemple.

Annulation de l'enregistrement d'un gestionnaire d'événements à haute disponibilité

Pour maintenir la cohérence du système et éviter les pannes du système, les extensions de noyau qui enregistrent un HAEH doivent annuler l'enregistrement lorsqu'elles sont déconfigurées et vont être déchargées. L'interface est la suivante:

int unregister_HA_handler(ha_handler_ext_t *)

Cette interface renvoie 0 en cas de réussite. Toute valeur de retour différente de zéro indique une erreur.

Désallocation d'un processeur dans l'environnement de test

Pour tester les modifications apportées aux applications ou aux extensions de noyau afin de prendre en charge cette désallocation de processeur, utilisez la commande suivante pour déclencher la désallocation d'une unité centrale désignée par son numéro d'unité centrale logique. La syntaxe est la suivante:

cpu_deallocate cpunum

où :

cpunum est un nombre d'UC logique valide.

Vous devez réamorcer le système pour remettre le processeur cible en ligne. Par conséquent, cette commande est fournie uniquement à des fins de test et n'est pas conçue comme un outil d'administration système.