Utilización de Desasignación dinámica de procesador
A partir del tipo de máquina 7044 modelo 270, el hardware de todos los sistemas con más de dos procesadores puede detectar errores corregibles, que son recopilados por el firmware. Estos errores no son muy graves y, siempre que se produzcan en raras ocasiones, se pueden ignorar sin problemas. Sin embargo, cuando un patrón de anomalías parece estar desarrollándose en un procesador específico, este patrón puede indicar que es probable que este componente muestre un error irrecuperable en un futuro próximo. Esta predicción la realiza el firmware en función de las tasas de anomalía y el análisis de umbral.
AIX® implementa una vigilancia continua del hardware y sondea regularmente el firmware en busca de errores de hardware. Cuando el número de errores de procesador alcanza un umbral y el firmware reconoce la probabilidad distinta de que este componente del sistema falle, el firmware devuelve un informe de error a AIX y registra el error en el registro de errores del sistema. Además, en sistemas multiprocesador, en función del tipo de anomalía, AIX intenta dejar de utilizar el procesador no fiable y desasignarlo. Esta característica se denomina desasignación de procesador dinámico.
En este punto, el firmware marca el procesador para la desasignación persistente para rearranques posteriores, hasta que el personal de servicio reemplace el procesador.
Impacto potencial en las aplicaciones
La desasignación de procesador no es aparente para la gran mayoría de aplicaciones, incluyendo controladores y extensiones de kernel. Sin embargo, puede utilizar las interfaces publicadas de AIX para determinar si una aplicación o extensión de kernel se está ejecutando en una máquina multiprocesador, averiguar cuántos procesadores hay y enlazar hebras a procesadores específicos.
La interfaz bindprocessor para vincular procesos o hebras a procesadores utiliza los números de CPU de vinculación. Los números de CPU de vinculación están en el rango [0 ..N-1] donde N es el número total de CPU. Para evitar que se rompan aplicaciones o extensiones de kernel que no presuponen "agujeros" en la numeración de CPU, AIX siempre hace que aparezca para las aplicaciones como si la CPU fuera la "última" (número más alto) CPU de enlace que se debe desasignar. Por ejemplo, en un SMP de 8 vías, los números de CPU de vinculación son [0..7]. Si se desasigna un procesador, el número total de CPU disponibles se convierte en 7, y se numeran [0..6]. Externamente, la CPU 7 parece haber desaparecido, independientemente del procesador físico que haya fallado.
Las aplicaciones o extensiones de kernel que utilizan el enlace de procesos/hebras podrían romperse potencialmente si AIX ha terminado de forma silenciosa sus hebras enlazadas o las ha movido a la fuerza a otra CPU cuando es necesario desasignar uno de los procesadores. La desasignación dinámica de procesador proporciona interfaces de programación para que se pueda notificar a esas aplicaciones y extensiones de kernel que está a punto de producirse una desasignación de procesador. Cuando estas aplicaciones y extensiones de kernel reciben esta notificación, son responsables de mover sus hebras enlazadas y recursos asociados (como bloques de solicitud de temporizador) fuera del último ID de CPU de enlace y se adaptan a la nueva configuración de CPU.
Si, después de la notificación de aplicaciones y extensiones de kernel, algunas de las hebras siguen enlazadas al último ID de CPU de enlace, la desasignación termina anormalmente. En este caso, AIX registra el hecho de que la desasignación ha terminado anormalmente en el registro de errores y continúa utilizando el procesador enfermo. Cuando el procesador finalmente falla, crea una anomalía total del sistema. Por lo tanto, es importante que las aplicaciones o extensiones de kernel que están enlazando hebras a las CPU obtengan la notificación de una desasignación de procesador inminente, y que actúen sobre este aviso.
Incluso en los raros casos en los que la desasignación no puede pasar, la desasignación dinámica del procesador sigue dando un aviso avanzado a los administradores del sistema. Al anotar cronológicamente el error en el registro de errores, les da la oportunidad de planificar una operación de mantenimiento en el sistema para sustituir el componente defectuoso antes de que se produzca una anomalía global del sistema.
Flujo de sucesos para la desasignación de procesador
El flujo de sucesos típico para la desasignación del procesador es el siguiente:
- El firmware detecta que un procesador ha alcanzado un umbral de error recuperable.
- AIX registra el informe de errores de firmware en el registro de errores del sistema y, cuando se ejecuta en una máquina que soporta la desasignación del procesador, inicia el proceso de desasignación.
- AIX notifica los procesos no de kernel y las hebras enlazadas a la última CPU de enlace.
- AIX espera a que todas las hebras enlazadas se alejen de la última CPU de enlace. Si las hebras permanecen enlazadas, AIX finalmente excede el tiempo de espera (después de diez minutos) y termina anormalmente la desasignación. De lo contrario, AIX invoca los manejadores de sucesos de alta disponibilidad (HAEH) registrados anteriormente. Un HAEH puede devolver un error que terminará anormalmente la desasignación. De lo contrario, AIX continúa con el proceso de desasignación y, en última instancia, detiene el procesador anómalo.
En caso de anomalía en cualquier punto de la desasignación, AIX registra la anomalía, indicando la razón por la que se ha cancelado la desasignación. El administrador del sistema puede consultar el registro de errores, efectuar la acción correctora (cuando sea posible) y reiniciar la desasignación. Por ejemplo, si la desasignación ha terminado anormalmente porque al menos una aplicación no ha desenlazado sus hebras enlazadas, el administrador del sistema podría detener las aplicaciones, reiniciar la desasignación (que debería continuar esta vez) y reiniciar la aplicación.
Interfaces de programación que tratan con procesadores individuales
Las secciones siguientes describen las interfaces de programación disponibles:
Interfaces para determinar el número de CPU en un sistema
- _SC_NPROCESSORS_CONF: Número de procesadores configurados
- _SC_NPROCESSORS_ONLN: Número de procesadores en línea
El valor devuelto por la subrutina sysconf para_SC_NPROCESSORS_CONFpermanecerá constante entre rearranques. Las máquinas uniprocesador (UP) se identifican mediante un 1. Los valores mayores que 1 indican máquinas de multiprocesador (MP). El valor devuelto para el parámetro _SC_NPROCESSORS_ONLN será el recuento de CPU activas y se disminuirá cada vez que se desasigne un procesador.
El campo _system_configuration.ncpus identifica el número de CPU activas en una máquina. Este campo es análogo al parámetro _SC_NPROCESSOR_ONLN .
Para el código que debe reconocer cuántos procesadores estaban disponibles originalmente en el momento del arranque, el campo ncpus_cfg se añade al_system_configurationtabla, que permanece constante entre rearranques.
Las CPU se identifican mediante ID de CPU de enlace en el rango [0 .. (ncpus-1)]. Los procesadores también tienen un número de CPU física que depende de la placa de CPU en la que están, en qué orden, etc. Los mandatos y subrutinas que tratan con números de CPU siempre utilizan números de CPU de enlace. Para facilitar la transición a un número variable de CPU, los números de CPU de enlace son números contiguos en el rango [0 .. (ncpus-1). El efecto de esto es que desde el punto de vista del usuario, cuando se produce una desasignación de procesador, siempre se ve como el número más alto ("último") La CPU de vinculación está desapareciendo, independientemente del procesador físico que haya fallado.
Interfaces para enlazar hebras a un procesador específico
El Mandato bindprocessor y la interfaz de programación bindprocessor le permiten enlazar una hebra o un proceso a una CPU específica, designada por su número de CPU de enlace. Ambas interfaces le permitirán enlazar hebras o procesos sólo a CPU activas. Los programas que utilizan directamente la interfaz de programación bindprocessor o que están enlazados externamente mediante un mandato bindprocessor deben poder manejar la desasignación del procesador.
El principal problema que ven los programas que se enlazan a un procesador cuando se ha desasignado una CPU es que las solicitudes de enlace a un procesador desasignado fallarán. El código que emite solicitudes bindprocessor siempre debe comprobar el valor de retorno de dichas solicitudes.
Interfaces para notificación de desasignación de procesador
El mecanismo de notificación es diferente para las aplicaciones de modalidad de usuario que tienen hebras enlazadas a la última CPU de enlace que para las extensiones de kernel.
Notificación en modalidad de usuario
A cada hebra de una aplicación en modalidad de usuario que está enlazada a la última CPU de enlace se le envían las señales SIGCPUFAIL y SIGRECONFIG . Estas aplicaciones deben modificarse para capturar estas señales y eliminar las hebras enlazadas a la última CPU de enlace (ya sea desenlazándolas o enlazándolas a una CPU diferente).
Notificación en modalidad de kernel
Los controladores y extensiones de kernel que se deben notificar de una desasignación de procesador inminente deben registrar una rutina HAEH (High-Availability Event Handler) con el kernel. Se llamará a esta rutina cuando sea inminente una desasignación de procesador. También se proporciona una interfaz para anular el registro de HAEH antes de que se desconfigure o descargue la extensión del kernel.
Registro de un manejador de sucesos de alta disponibilidad
El kernel exporta una nueva función para permitir la notificación de las extensiones del kernel en caso de eventos que afecten a la disponibilidad del sistema.
int register_HA_handler(ha_handler_ext_t *)Para obtener más información sobre esta llamada al sistema, consulte register_HA_handler en Sistema operativo y gestión de dispositivos.
El valor de retorno es igual a 0 en caso de éxito. Un valor distinto de cero indica una anomalía.
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;El campo _data privado se proporciona para el uso de la extensión de kernel si es necesario. Cualquier valor proporcionado en este campo en el momento del registro se pasará como parámetro a la función registrada cuando se llame al campo debido a un suceso de anomalía predictivo de CPU.
El campo _name es una serie terminada en nulo con una longitud máxima de 8 caracteres (sin incluir el terminador de caracteres nulos) que se utiliza para identificar de forma exclusiva la extensión del kernel con el kernel. Este nombre debe ser exclusivo entre todas las extensiones de kernel registradas. Este nombre se lista en el área de datos detallados delCPU_DEALLOC_ABORTEDregistro de errores si la extensión del kernel devuelve un error cuando el kernel llama a la rutina HAEH.
Las extensiones del kernel deben registrar su HAEH sólo una vez.
Invocación del manejador de sucesos de alta disponibilidad
- El valor del campo _data de la estructura ha_handler_ext_t pasada a register_HA_handler.
- Puntero a una estructura ha_event_t definida en el archivo sys/high_avail.h como:
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;
#define HA_ACCEPTED 0 /* Positive acknowledgement */
#define HA_REFUSED -1 /* Negative acknowledgement */Si alguna de las extensiones registradas no devuelve HA_ACEPTADA, la desasignación termina anormalmente. Las rutinas HAEH se llaman en el entorno de proceso y no es necesario fijarlas.
Si una extensión de kernel depende de la configuración de CPU, su rutina HAEH debe reaccionar a la próxima desasignación de CPU. Esta reacción es altamente dependiente de la aplicación. Para permitir que AIX continúe con la desconfiguración, deben mover las hebras que están enlazadas a la última CPU de enlace, si la hay. Además, si han estado utilizando temporizadores iniciados desde hebras enlazadas, estos temporizadores se moverán a otra CPU como parte de la desasignación de CPU. Si tienen alguna dependencia en estos temporizadores que se entregan a una CPU específica, deben tomar medidas (como detenerlos) y reiniciar sus solicitudes de temporizador cuando las hebras están enlazadas a una CPU nueva, por ejemplo.
Cancelar el registro de un manejador de sucesos de alta disponibilidad
int unregister_HA_handler(ha_handler_ext_t *)Esta interfaz devuelve 0 en caso de éxito. Cualquier valor de retorno distinto de cero indica un error.
Desasignación de un procesador en el entorno de prueba
cpu_deallocate cpunumdonde:
cpunum es un número de CPU lógica válido.
Debe rearrancar el sistema para volver a poner en línea el procesador de destino. Por lo tanto, este mandato se proporciona solo para fines de prueba y no está pensado como una herramienta de administración del sistema.