Configuración del proyecto de servicios de datos

Los servicios de datos pueden configurarse para que se ejecuten bajo un nombre de proyecto de Solaris cuando se pongan en línea con RGM. La configuración asocia un recurso o un grupo de recursos gestionados por RGM con un OD de proyecto de Solaris. La correlación desde el recurso o grupo de recursos a un ID de proyecto ofrece la posibilidad de usar controles sofisticados que están disponibles en el entorno Solaris para gestionar las cargas de trabajo y el consumo dentro del clúster.

Esta configuración sólo se puede realizar si se está ejecutando la versión actual del software de Sun Cluster con Solaris 9.

La funcionalidad de la gestión de Solaris en un entorno clúster permite dar prioridad a las aplicaciones más importantes al 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 la funcionalidad de la gestión que se describe aquí podría mejorar la disponibilidad de una aplicación crítica ya que evita que otras aplicaciones de prioridad baja consuman demasiados suministros del sistema, como tiempo de CPU.

La documentación de Solaris sobre esta función describe el tiempo de CPU, los procesos, las tareas y componentes similares como 'recursos'. Sin embargo, la documentación de Sun Cluster usa el término 'recursos' para describir entidades que están bajo el control de RGM. El apartado siguiente usará el término 'recurso' para hacer referencia a las entidades de Sun Cluster bajo el control de RGM y el término 'suministros' para hacer referencia a tiempo de CPU, procesos y tareas.

Este apartado 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. Este apartado también describe varios casos de recuperación de fallos y sugerencias para planificar el uso de la funcionalidad de la gestión que ofrece el entorno Solaris. Para obtener documentación detallada sobre conceptos y procedimientos de la función de la gestión, consulte System Administration Guide: Resource Management and Network Services en Solaris 9 System Administrator Collection.

Al configurar recursos y grupos de recursos para usar la funcionalidad de la gestión de Solaris en un clúster, considere el uso del siguiente proceso de alto nivel:

1. Configure aplicaciones como parte del recurso.

2. Configure recursos como parte de un grupo de recursos.

3. Habilite los recursos del grupo.

4. Haga gestionable el grupo de recursos.

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

6. Configure propiedades estándar para asociar el nombre del grupo de recursos con el proyecto que se ha 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 con el recurso o grupo de recursos, use la opción -y con la orden scrgadm(1M). Configure los valores de la propiedad al recurso o grupo de recursos. Consulte “Standard Properties” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS para obtener las descripciones adecuadas. Consulte r_properties(5) y rg_properties(5) for property descriptions.

El nombre del proyecto especificado debe existir en la base de datos de proyectos (/etc/project) y el superusuario debe estar configurado como miembro del proyecto con ese nombre. Consulte “Projects and Tasks” in System Administration Guide: Resource Management and Network Services en Solaris 9 System Administrator Collection para obtener información conceptual sobre el nombre del proyecto. Consulte project( 4) para obtener una descripción de la sintaxis de los archivos 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 proyecto nuevo no tiene vigencia hasta que el recurso o grupo de recursos se pone fuera de línea y se vuelve a poner en línea 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 dispadmin(1M) para obtener una descripción de las líneas de órdenes para establecer FSS como programador predeterminado. Consulte también priocntl(1), ps(1) y FSS(7) para obtener más información.

• 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 que se configuren servicios de datos para usar los controles que ofrece Solaris en un entorno Sun Cluster, es necesario decidir cómo se desean controlar y seguir los recursos en caso de cambios o recuperación de fallos. Considere identificar dependencias dentro del clúster antes de configurar un proyecto nuevo. Por ejemplo, los recursos y grupos de recursos dependen de grupos de dispositivos de disco. Las propiedades del grupo de recursos nodelist, failback, maximum_primaries y desired_primaries se configuran con scrgadm(1M) para identificar prioridades de las listas de nodos en el grupo de recursos. Consulte “Relationship Between Resource Groups and Disk Device Groups” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS para obtener una explicación breve sobre las dependencias de la lista de nodos entre los grupos de recursos y los grupos de dispositivos del disco. Para obtener descripciones de propiedad detalladas, consulte rg_properties(5).

Utilice las propiedades preferenced y failback configuradas con scrgadm(1M) y scsetup(1M) para determinar las prioridades de la lista de nodos del grupo de dispositivos de disco. Para obtener información sobre procedimientos, consulte “Cómo cambiar las propiedades de un dispositivo de disco” en “Administering Disk Device Groups” in Sun Cluster System Administration Guide for Solaris OS. Consulte Los componentes del hardware y el software de SunPlex para obtener información conceptual sobre la configuración de los nodos y el comportamiento de los servicios de datos a prueba de fallos y escalables.

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. Es necesario que los parámetros de configuración de los proyectos no sean idénticos en todas las aplicaciones de todos los nodos. Todos los proyectos asociados con la aplicación deben ser accesibles al menos por la base de datos de proyectos en todos los maestros potenciales de esa aplicación. Supongamos que la aplicación 1 está controlada por phys-schost-1 pero podría efectuarse una conmutación o resolución de error a phys-schost-2 o phys-schost-3. El proyecto asociado con 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 de proyectos puede ser un archivo local /etc/project o puede estar almacenada en el mapa NIS o en el servicio de directorios LDAP.

El entorno Solaris permite una configuración flexible de parámetros de uso y Sun Cluster pone 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 sobre la configuración del valor process.max-address-space.

Al utilizar controles de gestión con Sun Cluster, se deben configurar los límites de memoria apropiadamente para evitar una recuperación de fallos innecesaria de aplicaciones y un efecto “ping-pong”. En general:

• 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 casos 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 una conmutación, 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 el funcionamiento normal y las operaciones 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 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.

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

• La aplicación 2, con 3 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.