Sun Cluster: Guía de conceptos para SO Solaris

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 principal 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 una conmutación.

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.

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.