test

Sun Cluster: Guía de conceptos para el SO Solaris

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.

En un entorno de Sun Cluster las aplicaciones se configuran como parte de un recurso. A continuación, debe configurar el recurso como parte de un grupo de recursos (RG). Cuando se produce un fallo, el grupo de recursos, junto con sus aplicaciones asociadas, se recupera del fallo con otro nodo. En los ejemplos siguientes los recursos no se muestran específicamente. Se presupone que cada recurso sólo tiene una aplicación.

Nota –

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

Los ejemplos siguientes tienen estas limitaciones:

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.

Clúster de dos nodos con dos aplicaciones

Puede configurar dos aplicaciones en un clúster de dos nodos para asegurarse de que cada sistema físico (phys-schost-1, phys-schost-2) actúe como el maestro predeterminado de una aplicación. Cada sistema físico actúa como el nodo secundario del otro. Todos los proyectos que estén asociados a la aplicación 1 y 2 deben estar representados en los archivos de la base de datos en 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 la aplicación 1 tiene asignadas 4 particiones y que la aplicación 2 tiene asignada 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. No obstante, el porcentaje de tiempo de la CPU disponible para cada aplicación puede modificarse. El porcentaje depende del número de particiones que estén asignadas a cada proceso que requiera tiempo de la CPU.

Ilustración: El contexto describe el gráfico.

Clúster de dos nodos con tres aplicaciones

En un clúster de dos nodos con tres aplicaciones, puede configurar un sistema físico (phys-schost-1) como el maestro predeterminado de una aplicación. El segundo sistema físico (phys-schost-2) se puede configurar como el maestro predeterminado para las dos aplicaciones restantes. 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. Las aplicaciones 2 y 3 tienen asignadas 3 y 2 particiones respectivamente en el 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 se conmuta con phys-schost-2, las particiones de las tres aplicaciones permanecen iguales. Sin embargo, los porcentajes de recursos de CPU se reasignan según el archivo de base de datos de proyectos.

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

Ilustración: El contexto describe el gráfico.

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.

Nota –

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 base de datos del proyecto de los nodos primario y secundario tienen la misma configuración.

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 siguiente diagrama ilustra el funcionamiento normal y de recuperación de fallos de esta configuración, donde RG-2, que contiene la aplicación 2, falla e intenta recuperarse con phys-schost-2. Tenga en cuenta que el número de particiones asignadas no cambia. Sin embargo, el porcentaje de tiempo de la CPU disponible para cada aplicación se puede cambiar, en función del número de particiones que estén asignadas a cada aplicación que requiera tiempo de la CPU.

Ilustración: El contexto describe el gráfico.