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

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.