Configuración de un proyecto de servicio de datos

Los servicios de datos se pueden configurar para que se inicien con un nombre de proyecto de Solaris cuando RGM los ponga en línea. La configuración asocia un recurso o un grupo de recursos gestionados por RGM con un OD de proyecto de Solaris. La asignación de un recurso o un grupo de recursos a un ID de proyecto le permite utilizar controles sofisticados que están disponibles en el sistema operativo Solaris para gestionar las cargas de trabajo y el consumo en el clúster.

Podrá llevar a cabo esta configuración sólo si está utilizando la versión actual del software Sun Cluster con Solaris 9 como mínimo.

El uso de la función de gestión de Solaris en un entorno de Sun Cluster le permite garantizar que las aplicaciones más importantes tengan prioridad a la hora de compartir un nodo con otras aplicaciones. Las aplicaciones podrían compartir un nodo si hay servicios consolidados o porque se haya producido una recuperación de fallos. El uso de las funciones de gestión descritas en este documento puede mejorar la disponibilidad de una aplicación que sea básica impidiendo que otras aplicaciones con una prioridad inferior consuman en exceso suministros del sistema como, por ejemplo, el tiempo de la CPU.

La documentación de Solaris sobre esta función asigna el término “recursos” al tiempo de la CPU, los procesos, las tareas y otros componentes similares. Mientras que en la documentación de Sun Cluster, se utiliza el término “recursos” para describir entidades que están bajo el control de RGM. En la siguiente sección se utilizará el término “recurso” para referirse a las entidades de Sun Cluster que están bajo el control de RGM. En esta sección se utiliza el término “suministros” para referirse al tiempo de la CPU, los procesos y las tareas.

Esta sección ofrece una descripción conceptual de la configuración de los servicios de datos para ejecutar procesos en un project(4) especificado de Solaris 9. En esta sección también se describen varias situaciones de recuperación de fallos, así como sugerencias para planificar el uso de la función de gestión que proporciona el sistema operativo Solaris.

Para obtener documentación sobre los conceptos y los procedimientos relacionados con la función de gestión, consulte el Capítulo 1, Network Service (Overview) de System Administration Guide: Network Services.

Cuando vaya a configurar recursos y grupos de recursos para usar la función de gestión de Solaris en un clúster, use los siguientes procedimientos generales:

1. Configure las aplicaciones como parte del recurso.

2. Configure los recursos como parte del grupo de recursos.

3. Habilite los recursos en el grupo de recursos.

4. Haga que el grupo de recursos esté administrado.

5. Cree un proyecto de Solaris para el grupo de recursos.

6. Configure propiedades estándar para asociar el nombre del grupo de recursos al proyecto creado en el paso 5.

7. Ponga en línea el grupo de recursos.

Para configurar las propiedades estándar Resource_project_name o RG_project_name para asociar el ID de proyecto de Solaris al recurso o grupo de recursos, use la opción --y con el comando scrgadm(1M). Configure los valores de la propiedad al recurso o grupo de recursos. Consulte el Apéndice A, Standard Properties de Sun Cluster Data Services Planning and Administration Guide for Solaris OS para ver las definiciones de las propiedades. Consulte r_properties(5) y rg_properties(5) para ver las descripciones de las propiedades.

El nombre de proyecto especificado debe existir en la base de datos de proyectos (/etc/project) y el superusuario debe estar configurado como miembro de dicho proyecto. Consulte el Capítulo 2, Projects and Tasks (Overview) de System Administration Guide: Solaris Containers-Resource Management and Solaris Zones para obtener información conceptual sobre la base de datos de nombres de proyectos. Consulte project(4) para conocer la sintaxis del archivo del proyecto.

Cuando RGM pone en línea el recurso o grupo de recursos, ejecuta los procesos relacionados que hay bajo el nombre del proyecto.

Los usuarios pueden asociar recursos o grupos de recursos con proyectos en cualquier momento. Sin embargo, el nombre del nuevo proyecto no entra en vigor hasta que el recurso o el grupo de recursos se ponga fuera de línea y luego en línea de nuevo usando RGM.

Ejecutar recursos y grupos de recursos bajo el nombre del proyecto permite configurar las funciones siguientes para gestionar suministros de sistema en todo el clúster.

• Contabilidad ampliada: ofrece una forma flexible de registrar el consumo según las tareas o los procesos. La contabilidad ampliada permite examinar el uso histórico y evaluar las necesidades de capacidad para cargas de trabajo futuras.

• Controles: proporcionan un mecanismo para ajustarse a los suministros del sistema. Puede evitarse que los procesos, tareas y proyectos consuman grandes cantidades de suministros de sistema especificados.

• Programación de partición justa (FSS): ofrece la posibilidad de controlar la ubicación de tiempo de CPU disponible entre cargas de trabajo según su importancia. Ésta se mide por el número de particiones de tiempo de CPU que se asigna a cada carga de trabajo. Consulte las siguientes páginas de comando man para obtener más información:

  • dispadmin(1M)

  • priocntl(1)

  • ps(1)

  • FSS(7)

• Agrupaciones: ofrecen la posibilidad de usar particiones para aplicaciones interactivas según los requisitos de éstas. La agrupaciones pueden usarse para particionar un servidor que admite distintas aplicaciones de software. El uso de agrupaciones produce una respuesta más predecible para cada aplicación.

Determinación de requisitos para la configuración de proyectos

Antes de configurar los servicios de datos para que utilicen los controles proporcionados por Solaris en un entorno de Sun Cluster, debe decidir cómo desea controlar y supervisar los recursos en los procesos de recuperación de fallos y conmutación. Identifique las dependencias del clúster antes de configurar un nuevo proyecto. Por ejemplo, los recursos y grupos de recursos dependen de grupos de dispositivos de disco.

Use las propiedades de grupo de recursos nodelist, failback, maximum_primaries y desired_primaries que están configuradas con scrgadm(1M) para identificar las prioridades de la lista de nodos para el grupo de recursos.

• Para obtener una breve información sobre las dependencias existentes entre los grupos de recursos y los grupos de dispositivos de discos, consulte Relationship Between Resource Groups and Disk Device Groups de Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

• Para ver una descripción detallada de las propiedades, consulte rg_properties(5).

Use las propiedades preferenced property y failback que están configuradas con scrgadm(1M) y scsetup(1M) para determinar las prioridades de la lista de nodos del grupo de dispositivos.

• Para obtener información conceptual acerca de la propiedad preferenced, consulte Grupos de dispositivos de disco multipuerto .

• Para obtener información sobre los procedimientos, consulte “How To Change Disk Device Properties” en la Administración de grupos de dispositivos de disco de Sun Cluster: Guía de administración del sistema para el SO Solaris.

• Para obtener información conceptual acerca de la configuración del nodo y del comportamiento de los servicios de datos escalables y de recuperación de fallos, consulte la Componentes de software y hardware del sistema Sun Cluster .

Si se configura todos los nodos del clúster de forma idéntica, los límites de uso se hacen cumplir de forma idéntica en los nodos primarios y secundarios. Los parámetros de configuración de los proyectos no deben ser idénticos para todas las aplicaciones en los archivos de configuración de todos los nodos. Todos los proyectos que estén asociados a la aplicación deben, como mínimo, estar accesibles para la base de datos en todos los posibles maestros de esta aplicación. Suponga que phys-schost-1 actúa como maestro de la Aplicación 1, pero ésta podría conmutarse o efectuar la recuperación de fallos con phys-schost-2 o phys-schost-3. El proyecto que esté asociado a la aplicación 1 debe estar accesible en los tres nodos (phys-schost-1, phys-schost-2 y phys-schost-3).

La información de la base de datos del proyecto puede ser un archivo de base de datos local /etc/project o puede almacenarse en la asignación NIS o en el servicio de directorio LDAP.

El sistema operativo Solaris hace posible una configuración flexible de los parámetros de uso y Sun Cluster impone pocas restricciones. Las opciones de configuración dependen de las necesidades de la sede. Considere las directrices generales de los apartados siguientes antes de configurar los sistemas.

Establecimiento de límites de memoria virtual por proceso

Configure el control process.max-address-space para limitar la memoria virtual a cada proceso. Consulte rctladm(1M) para obtener información detallada acerca de la configuración del valor de process.max-address-space.

Cuando use los controles de gestión con el software Sun Cluster, configure los límites de memoria de forma adecuada para impedir las recuperaciones de fallos innecesarias y el efecto “ping-pong” de las aplicaciones. En general, deberá seguir las siguientes directrices.

• No configure unos límites de memoria demasiado bajos.

  Cuando una aplicación llegue a su límite de memoria, podría producirse una recuperación de fallos. Esta directriz es especialmente importante para aplicaciones de base de datos, ya que al alcanzar un límite de memoria virtual se pueden producir consecuencias inesperadas.

• No configure límites de memoria idénticos en nodos primarios y secundarios.

  Límites idénticos podrían causar un efecto ping-pong cuando una aplicación alcance su límite de memoria y se recupere el error en un nodo secundario con un límite de memoria idéntico. Configure el límite de memoria un poco por encima en el nodo secundario. La diferencia en los límites de memoria ayuda a evitar la situación ping-pong y da al administrador del sistema un periodo de tiempo en el que ajustar los parámetros como sea necesario.

• Use los límites de memoria de la gestión de recursos para el equilibrio de cargas.

  Por ejemplo, puede usar límites de memoria para evitar que que una aplicación que no funcione bien consuma demasiado espacio de intercambio en disco.

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 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.

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

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.

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.

• 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 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.