Casos de recuperación de fallos

Puede configurar parámetros de gestión para que la asignación en la configuración del proyecto (/etc/project) funcione normalmente en el clúster y en las situaciones de conmutación o recuperación de fallos.

Los apartados siguientes son casos de ejemplo.

• Los dos primeros apartados, “Clúster de dos nodos con dos aplicaciones“ y “Clúster de dos nodos con tres aplicaciones“, muestran escenarios de recuperación de fallos para nodos completos.

• El apartado “Recuperación de fallos sólo de grupos de recursos“ ilustra el funcionamiento de la recuperación de fallos sólo para una aplicación.

En un entorno del clúster las aplicaciones se configuran como parte de un recurso y éste como parte de un grupo de recursos (RG). Cuando se produce un fallo, el grupo de recursos, junto con su aplicación asociada, se transfieren a otro nodo. En los ejemplos siguientes los recursos no se muestran específicamente. Se presupone que cada recurso sólo tiene una aplicación.

La recuperación de fallos se produce en el orden de lista de nodos especificado en la RGM.

Los ejemplos siguientes tienen estas limitaciones:

• La aplicación 1 (App-1) está configurada en el grupo de recursos RG-1.

• La aplicación 2 (App-2) está configurada en el grupo de recursos RG-2.

• La aplicación 3 (App-3) está configurada en el grupo de recursos RG-3.

Aunque los números de particiones asignadas siguen siendo los mismos, el porcentaje de tiempo de CPU asignado a cada aplicación cambia después de la recuperación de fallos. Este porcentaje depende del número de aplicaciones que se están ejecutando en el nodo y del número de particiones que se han asignado a cada aplicación activa.

En estos casos, se asumen las configuraciones siguientes.

• Todas las aplicaciones están configuradas bajo un proyecto común.

• Cada recurso dispone de una única aplicación.

• Las aplicaciones son los únicos procesos activos de los nodos.

• Las bases de datos de los proyectos están configuradas igual en todos los nodos del clúster.

Clúster de dos nodos con dos aplicaciones

Se pueden configurar dos aplicaciones en un clúster de dos nodos para asegurarse de que todos los sistemas físicos (phys-schost-1, phys-schost-2) actúen como maestros predeterminados de una aplicación. Cada sistema físico actúa como el nodo secundario del otro. Todos los proyectos asociados con las aplicaciones 1 y 2 deben estar representado en los archivos de la base de datos de proyectos de ambos nodos. Cuando el clúster se está ejecutando normalmente, todas las aplicaciones se ejecutan en su principal predeterminado, donde la función de gestión le asigna todo el tiempo de CPU.

Después de una recuperación de fallos o cambio, las dos aplicaciones se ejecutan en un único nodo en que se les asigna particiones, como se especifica en el archivo de configuración. Por ejemplo, esta entrada del archivo /etc/project especifica que a la aplicación 1 se le asignan 4 particiones y a la aplicación 2 se le asigna 1 partición.

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

El diagrama siguiente ilustra las operaciones normales y de recuperación de fallos de esta configuración. El número de particiones que se asignen no cambia. Sin embargo, el porcentaje de tiempo de CPU disponible para cada aplicación puede cambiar, dependiendo del número de particiones asignadas a cada proceso que requiera tiempo de CPU.

Clúster de dos nodos con tres aplicaciones

En un clúster de dos nodos con tres aplicaciones, se puede configurar un sistema físico (phys-schost-1) como principal predeterminado de una aplicación y el segundo sistema físico (phys-schost-2) como maestro predeterminado para las otras dos aplicaciones. Consideremos el siguiente archivo de base de datos de proyectos de ejemplo que está en todos los nodos. El archivo de base de datos de proyectos no cambia cuando se produce una recuperación de fallos o un cambio.

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)  

Cuando el clúster se está ejecutando normalmente, a la aplicación 1 se le asignan 5 particiones en su maestro predeterminado, phys-schost-1. Este número es equivalente al 100 por cien del tiempo de CPU porque es la única aplicación que lo demanda en ese nodo. A las aplicaciones 2 y 3 se les asigna 3 y 2 particiones respectivamente en su maestro predeterminado, phys-schost-2. La aplicación 2 recibiría el 60 por ciento del tiempo de CPU y la aplicación 3 recibiría el 40 por ciento durante el funcionamiento normal.

Si se produce una recuperación de fallos o una conmutación y la aplicación 1 se cambia a phys-schost-2, las particiones para las tres aplicaciones siguen siendo las mismas. Sin embargo, los porcentajes de recursos de CPU se reasignan según el archivo de base de datos de proyectos.

• La aplicación 1, con 5 particiones, recibe el 50 por ciento de CPU.

• La aplicación 2, con tres particiones, recibe el 30 por ciento de CPU.

• La aplicación 3, con 2 particiones, recibe el 20 por ciento de CPU.

El diagrama siguiente ilustra el funcionamiento normal y las operaciones de recuperación de fallos de esta configuración.

Recuperación de fallos sólo de grupos de recursos

En una configuración en la que varios grupos de recursos tienen el mismo maestro predeterminado, un grupo de recursos (y sus aplicaciones asociadas) pueden entrar en recuperación de fallos o cambiarse a un nodo secundario. Mientras tanto el maestro predeterminado está ejecutándose en el clúster.

Durante la recuperación de fallos a la aplicación que falla se le asignan recursos, como los que se especifican en el archivo de configuración en el nodo secundario. En este ejemplo, los archivos de la base de datos de proyectos de los nodos primario y secundario tienen las mismas configuraciones.

Por ejemplo, este archivo de configuración de ejemplo especifica que a la aplicación 1 se le asigna 1 partición, a la aplicación 2 se le asignan 2 y a la aplicación 3 se le asignan otras 2.

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

El diagrama siguiente ilustra las operaciones normal y de resolución de problemas de esta configuración, en que RG-2, que contiene la aplicación 2, falla sobre phys-schost-2. Tenga en cuenta que el número de particiones asignadas no cambia. Sin embargo, el porcentaje de tiempo de CPU disponible para cada aplicación puede cambiar, dependiendo del número de particiones asignadas a cada aplicación que requiera tiempo de CPU.