Capítulo 3 Conceptos clave para los administradores de sistemas y los desarrolladores de aplicaciones

Este capítulo describe los conceptos clave relacionados con los componentes de software de un sistema Sun Cluster. Se tratan los siguientes temas:

• Interfaces administrativas

• Hora del clúster

• Estructura de alta disponibilidad

• Dispositivos globales

• Grupos de dispositivos de discos

• Espacio de nombres global

• Sistemas de archivos de clúster

• Supervisión de la ruta de discos

• Quórum y dispositivos del quórum

• Servicios de datos

• Uso de interconexiones del clúster para el tráfico de servicios de datos

• Tipos de recursos, grupos de recursos y recursos

• Configuración de un proyecto de servicio de datos

• Adaptadores de red públicos y Ruta múltiple de red de protocolo de Internet (IP)

• SPARC: Compatibilidad con la reconfiguración dinámica

Esta información está dirigida especialmente a los administradores de sistemas y a los desarrolladores de aplicaciones que usan el SDK y la API de Sun Cluster. Asimismo, esta información puede resultar útil a los administradores de sistemas del clúster para instalar, configurar y administrar el software del clúster. Los desarrolladores de aplicaciones pueden usar la información para entender el entorno del clúster en el que estarán trabajando.

Interfaces administrativas

Puede elegir la forma de instalar, configurar y administrar el sistema Sun Cluster desde varias interfaces de usuario, así como realizar tareas de administración del sistema a través de la interfaz gráfica de usuario (GUI) de SunPlex Manager o de la interfaz de línea de órdenes documentada. En la parte superior de la interfaz de línea de comandos hay algunas utilidades, como scinstall y scsetup, para simplificar las tareas de instalación y configuración. El sistema Sun Cluster también tiene un módulo que se ejecuta como parte de Sun Management Center e incluye una GUI para algunas tareas del clúster. y que está disponible sólo para usarlo en clústers basados en plataformas SPARC. Consulte Herramientas de administración de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener descripciones completas de las interfaces administrativas.

Hora del clúster

La hora en todos los nodos del clúster debe estar sincronizada. Que esta sincronización se realice con una fuente externa no es importante para el funcionamiento del clúster. El sistema Sun Cluster utiliza el protocolo Network Time Protocol (NTP) para sincronizar los relojes de los distintos nodos.

En general, una diferencia en el reloj del sistema de una fracción de segundo no causa problemas. Sin embargo, si ejecuta date(1), rdate(1M) o xntpdate(1M) (ya sea de forma interactiva o con las secuencias de comandos cron) en un clúster activo, podrá forzar un cambio de hora mucho mayor que una fracción de segundo para sincronizar el reloj del sistema con un origen de hora, lo que podría causar problemas con la marca de hora de modificación de archivos o confundir al servicio NTP.

Al instalar el sistema operativo Solaris en cada nodo del clúster, tendrá la oportunidad de cambiar la hora predeterminada y la configuración de la fecha para el nodo. En general, puede aceptar el valor predeterminado sugerido.

Cuando se instala el software Sun Cluster usando scinstall(1M), un paso del procedimiento consiste en configurar NTP para el clúster. El software Sun Cluster proporciona un archivo de plantilla, ntp.cluster (consulte /etc/inet/ntp.cluster en un nodo de clúster instalado), que establece una relación de igual a igual entre todos los nodos del clúster. Un nodo se establece como el “preferido”. Los nodos se identifican mediante sus nombres de hosts privados y la sincronización de hora se produce mediante la interconexión de los clústeres. Para obtener instrucciones acerca de cómo configurar un clúster para NTP, consulte el Capítulo 2, Instalación y configuración del software Sun Cluster de Software Sun Cluster: Guía de instalación para el sistema operativo Solaris.

También puede configurar uno o más servidores NTP externos al clúster y cambiar el archivo ntp.conf para reflejar esta configuración.

Durante el funcionamiento normal, nunca debería ser necesario ajustar la hora en el clúster. No obstante, si se estableció mal la hora al instalar el sistema operativo Solaris y desea modificarla, el procedimiento para hacerlo figura en el Capítulo 7, Administración del clúster de Sun Cluster: Guía de administración del sistema para el SO Solaris.

Estructura de alta disponibilidad

El sistema Sun Cluster hace que todos los componentes de la “ruta de acceso” entre los usuarios y los datos estén muy disponibles, incluidos elementos como las interfaces de red, las aplicaciones en sí, el sistema de archivos y los dispositivos multisistema. En general, un componente del clúster está muy disponible si sobrevive a cualquier fallo (de software o hardware) que se produzca en el sistema.

La siguiente tabla muestra los tipos de fallos de los componentes de Sun Cluster (tanto de hardware como de software) y los tipos de recuperaciones que se integran en la estructura de alta disponibilidad.

La estructura de alta disponibilidad del software de Sun Cluster detecta rápidamente cualquier fallo en los nodos y crea un nuevo servidor equivalente para los recursos de la estructura en otro nodo del clúster. En ningún momento se interrumpe completamente la disponibilidad de los recursos de la estructura. Los recursos de la estructura que no se han visto afectados por el fallo del nodo siguen estando disponibles durante la recuperación. Además, los recursos de la estructura del nodo fallido vuelven a estar disponibles en cuanto se recuperan. Un recurso de la estructura recuperado no tiene que esperar a que todos los demás recursos de la estructura completen su recuperación.

La mayoría de recursos de la estructura de alta disponibilidad se recuperan de manera transparente para las aplicaciones (servicios de datos) que utilizan el recurso. Las semánticas del acceso a los recursos de la estructura se conservan perfectamente entre los fallos de los nodos. Las aplicaciones no pueden detectar que el servidor del recurso de la estructura se ha movido a otro nodo. El error de un único nodo es completamente transparente para los programas de los nodos restantes que utilicen los archivos, los dispositivos y los volúmenes de discos adjuntos a este nodo. Esta transparencia es posible si hay una ruta de hardware alternativa a los discos desde otro nodo. Un ejemplo es el uso de dispositivos multisistema que tengan puertos con varios nodos.

Cluster Membership Monitor

Para asegurarse de que los datos permanezcan incorruptos, todos los nodos deben alcanzar un acuerdo uniforme sobre la pertenencia al clúster. Cuando es necesario, CMM coordina una reconfiguración de los servicios del clúster (aplicaciones) en respuesta a un fallo.

CMM recibe información sobre conectividad con otros nodos desde la capa de transporte del clúster. CMM usa la interconexión del clúster para intercambiar información de estado durante la reconfiguración.

Tras detectar un cambio en la pertenencia del clúster, CMM efectúa una configuración sincronizada de éste en la cual es posible que los recursos del clúster se redistribuyan, basándose en la nueva pertenencia del clúster.

A diferencia de las versiones de software anteriores de Sun Cluster, CMM se ejecuta por completo en el núcleo.

Consulte Acerca del aislamiento de fallos para obtener más información acerca de cómo se protege el clúster para impedir su división en numerosos clústeres separados.

Mecanismo de recuperación rápida

Si CMM detecta un problema grave en un nodo, lo notifica a la estructura del clúster para forzar el cierre (avisos graves) del nodo y hacer que deje de pertenecer al clúster. El mecanismo por el que esto se produce se llama recuperación rápida. Este mecanismo hace que un nodo se cierre de dos formas.

• Si un nodo abandona el clúster y después intenta crear uno nuevo sin tener quórum, queda “encerrado” y se le impide acceder a discos compartidos. Consulte Acerca del aislamiento de fallos para obtener información acerca de este uso del mecanismo de recuperación rápida.

• Si uno o varios de los daemons específicos del clúster sufre un fallo (clexecd, rpc.pmfd, rgmd o rpc.ed), CMM detecta el fallo y el nodo emite avisos graves.

Cuando el fallo del daemon de un clúster provoca que un nodo envíe avisos graves, se muestra un mensaje similar al siguiente en la consola para dicho nodo.

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

Después del aviso grave, es posible que el nodo rearranque e intente reunificar el clúster. Si el clúster está compuesto por sistemas basados en SPARC, puede que el nodo permanezca en el indicador OpenBoot^TM PROM (OBP). La siguiente acción del nodo dependerá del valor del parámetro auto-boot?. Puede configurar auto-boot? con eeprom(1M), en el indicador OpenBoot PROM ok .

Cluster Configuration Repository (CCR)

CCR usa un algoritmo de puesta al día de dos fases para las actualizaciones: Una actualización debe completarse satisfactoriamente en todos los miembros del clúster, de lo contrario, la actualización se deshace. CCR usa la interconexión del clúster para aplicar las actualizaciones distribuidas.

CCR se compone de archivos de texto que nunca se deben editar manualmente, ya que cada archivo contiene un registro de suma de control para asegurar la coherencia entre los nodos. La actualización manual de los archivos de CCR provocaría que un nodo o todo el clúster dejaran de funcionar.

CCR confía en CMM para garantizar que el clúster sólo se ejecute cuando se tenga el suficiente quórum y es responsable de verificar la uniformidad de los datos entre el clúster, efectuando recuperaciones según sea necesario y facilitando actualizaciones a los datos.

Dispositivos globales

El sistema Sun Cluster utiliza dispositivos globales para proporcionar a todos los dispositivos del clúster un acceso de alta disponibilidad en todo el clúster, desde cualquier nodo, con independencia del lugar al que esté acoplado físicamente el dispositivo. Por lo general, si un nodo falla a la hora de proporcionar acceso a un dispositivo global, el software Sun Cluster detecta automáticamente otra ruta al dispositivo y redirige el acceso a esa ruta. Los dispositivos globales de Sun Cluster pueden ser discos, CD-ROM y cintas. Sin embargo, los únicos dispositivos globales multipuerto que admite el software Sun Cluster son los discos. En consecuencia, los CD-ROM y los dispositivos de cinta no son actualmente dispositivos de alta disponibilidad. Los discos locales de cada servidor tampoco son multipuerto, por lo tanto no son dispositivos de alta disponibilidad.

El clúster asigna automáticamente ID exclusivos a cada disco, CD-ROM y unidad de cinta del clúster, lo que permite el acceso uniforme a todos los dispositivos desde cualquier nodo del clúster. El espacio de nombres de dispositivos global se conserva en el directorio /dev/global. Consulte Espacio de nombres global para obtener más información.

Los dispositivos globales multipuerto ofrecen más de una ruta de acceso al dispositivo. Dado que los discos multisistema forman parte de un grupo de dispositivos de discos que están alojados por más de un nodo, los discos multisistema tienen una alta disponibilidad.

ID de dispositivo y pseudocontrolador DID

El software Sun Cluster gestiona dispositivos globales a través de una estructura conocida como el pseudocontrolador del ID del dispositivo (DID) Este controlador se utiliza para asignar automáticamente identificadores exclusivos a todos los dispositivos del clúster, incluidos discos multisistema, unidades de cinta y CD-ROM.

También es una pieza integral de la función de acceso global a los dispositivos del clúster. El controlador DID prueba todos los nodos del clúster y genera una lista de dispositivos de disco únicos, asigna a cada dispositivo un número mayor y otro menor que son coherentes en todos los nodos del clúster. Para acceder a los dispositivos globales se utiliza el ID de dispositivo exclusivo en lugar de los ID de dispositivo tradicionales de Solaris como, por ejemplo, c0t0d0 para un disco.

Este enfoque garantiza que cualquier aplicación que acceda a los discos (como, por ejemplo, el gestor de volúmenes o las aplicaciones que utilicen dispositivos sin formato) utilice una ruta coherente a través del clúster. Esta uniformidad es especialmente importante en discos multisistema, debido a que los números mayor y menor de cada dispositivo pueden variar entre distintos nodos, cambiando así también las convenciones de asignación de nombres de dispositivos de Solaris. Por ejemplo, el nodo 1 podría identificar un disco multisistema como c1t2d0 y el nodo 2 podría ver ese mismo disco de forma completamente distinta, como c3t2d0. El controlador DID asigna un nombre global, como d10, que los nodos usarán en su lugar, lo que generará una asignación uniforme con el disco multisistema.

Los ID se actualizan y administran mediante scdidadm(1M) y scgdevs(1M). Consulte las siguientes páginas de comando man para obtener más información:

• scdidadm(1M)

• scgdevs(1M)

Grupos de dispositivos de discos

En el sistema Sun Cluster, todos los dispositivos multisistema deben estar bajo el control del software Sun Cluster. En primer lugar, se deben crear los grupos de discos del gestor de volúmenes —ya sea un conjunto de discos de Gestor de volúmenes de Solaris o un grupo de discos de VERITAS Volume Manager (disponible para usarlo sólo en clústeres basados en SPARC)— en los discos multisistema. A continuación, se registran los grupos de discos del gestor de discos como grupos de dispositivos de discos que forman un tipo de dispositivo global. Además, el software Sun Cluster crea automáticamente un grupo de dispositivos de bajo nivel para cada dispositivo de disco y de cinta del clúster. Sin embargo, estos grupos de dispositivos del clúster permanecen en estado fuera de línea hasta que se accede a ellos como dispositivos globales.

Este registro proporciona al sistema Sun Cluster información sobre qué nodos tienen una ruta a ciertos grupos de discos del gestor de volúmenes. En este punto, los grupos de discos del gestor de volúmenes se convierten en accesibles globalmente dentro del clúster. Si hay más de un nodo que pueda escribir (controlar) un grupo de dispositivos de disco, los datos almacenados en éste se consideran de alta disponibilidad. El grupo de dispositivos de disco de alta disponibilidad se puede utilizar para albergar los sistemas de archivos del clúster.

Los grupos de dispositivos de disco son independientes de los grupos de recursos. Un nodo puede actuar como maestro de un grupo de recursos (representando un grupo de procesos de servicios de datos), mientras que otro puede actuar de maestro de un grupo de discos a los que acceden los servicios de datos. Sin embargo, la mejor práctica consiste en mantener en el mismo nodo el grupo de dispositivos que almacena los datos de una aplicación en concreto y el grupo de recursos que contiene los recursos de la aplicación (el daemon de la aplicación). Consulte Relationship Between Resource Groups and Disk Device Groups de Sun Cluster Data Services Planning and Administration Guide for Solaris OS para obtener más información acerca de la asociación entre los grupos de dispositivos de discos y los grupos de recursos.

Cuando un nodo utiliza un grupo de dispositivos de disco, el grupo de discos del gestor de volúmenes se convierte en “global” porque proporciona un soporte multirruta a los discos subyacentes. Cada nodo del clúster conectado físicamente a los discos multisistema proporciona una ruta de acceso al grupo de dispositivos de disco.

Recuperación de fallos en grupos de dispositivos de disco

Debido a que un alojamiento de disco está conectado a más de un nodo, todos los grupos de dispositivos de disco de ese alojamiento estarán disponibles a través de una ruta de acceso alternativa si falla el nodo que esté controlando en ese momento el grupo de dispositivos. El fallo del nodo que controla el grupo de dispositivos no afecta al acceso al grupo de dispositivos excepto por el tiempo que se tarda en realizar la recuperación y las comprobaciones de integridad. Durante ese tiempo, todas las peticiones se bloquean (de forma transparente para la aplicación) hasta que el sistema vuelve a hacer que el grupo de dispositivos esté disponible.

Figura 3–1 Grupo de dispositivos de disco antes y después de una recuperación de fallos

Grupos de dispositivos de disco multipuerto

Esta sección describe las propiedades de grupo de dispositivos de disco que le permiten equilibrar rendimiento y disponibilidad en una configuración de disco multipuerto. El software Sun Cluster proporciona dos propiedades que se usan para definir una configuración de disco multipuerto: preferenced y numsecondaries. Puede controlar el orden en el que los nodos tratan de asumir el control si se produce una recuperación de fallos usando la propiedad preferenced. La propiedad numsecondaries se utiliza para establecer un número deseado de nodos secundarios para un grupo de dispositivos.

Se considera que un servicio de alta disponibilidad está inactivo cuando el nodo primario falla y no hay nodos secundarios aptos para asumir las funciones del primario. Si se produce una recuperación de fallos y la propiedad preferenced tiene un valor true, entonces los nodos siguen el orden establecido en la lista de nodos para elegir cuál de ellos será el secundario. La lista de nodos establece el orden en el que los nodos intentarán asumir el control principal o dejarán de estar en reserva para ser secundarios. Puede cambiar dinámicamente la preferencia de un servicio de dispositivo mediante la utilidad scsetup(1M). La preferencia asociada a los proveedores de servicios dependientes (por ejemplo, un sistema de archivos global) será idéntica a la preferencia del servicio de dispositivo.

El nodo primario comprueba los secundarios durante el funcionamiento normal. En una configuración de disco multipuerto, comprobar todos los nodos secundarios produce una degradación en el rendimiento del clúster y una sobrecarga en la memoria. La compatibilidad con el nodo de reserva se implementó para minimizar la degradación del rendimiento y la sobrecarga de la memoria que causaban las comprobaciones puntuales. De forma predeterminada, el grupo de dispositivos de disco tiene un nodo primario y otro secundario. El resto de nodos de proveedor disponibles aparecen como nodos de reserva. Si se produce una recuperación de fallos, el nodo secundario se convierte en primario y el nodo que tuviera una mayor prioridad en la lista, pasa a ser secundario.

Se puede definir el número que desee de nodos secundarios. Puede ser cualquier número entero entre uno y el número de nodos operativos de proveedor que no sean primarios del grupo de dispositivos.

Si está usando Gestor de volúmenes de Solaris, deberá crear el grupo de dispositivos de disco antes de definir la propiedad numsecondaries en un número distinto del predeterminado.

De manera predeterminada el número deseado de secundarios para servicios de dispositivos es de uno. El número real de proveedores secundarios que se mantiene en la estructura de réplica es el número que se indique, a menos que el número de proveedores operativos que no sean primarios sea inferior al número deseado. Debe modificar la propiedad numsecondaries y volver a comprobar la lista de nodos si está agregando o eliminando nodos de la configuración. Mantener la lista de nodos y el número deseado de nodos secundarios impide que se produzcan conflictos entre el número configurado de nodos secundarios y el número real que permite la estructura.

• (Gestor de volúmenes de Solaris) Use el comando metaset(1M) para los grupos de dispositivos de Gestor de volúmenes de Solaris junto con los ajustes de las propiedades preferenced y numsecondaries, para administrar la adición y la eliminación de nodos de la configuración.

• (Veritas Volume Manager) Use el comando scconf(1M) para los grupos de dispositivos VxVM, junto con los ajustes de las propiedades preferenced y numsecondaries, para administrar la adición y la eliminación de nodos de la configuración.

• Consulte Administración de sistemas de archivos del clúster: información general de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener información sobre los procedimientos para cambiar las propiedades de los grupos de dispositivos.

Espacio de nombres global

El mecanismo de software de Sun Cluster que habilita los dispositivos globales se llama espacio de nombres global. El espacio de nombres incluye la jerarquía /dev/global/, así como los espacios de nombres del gestor de volúmenes. El espacio de nombres global representa los discos multisistema y locales (y cualquier otro dispositivo del clúster, como CD-ROM y cintas) e incluye varias rutas de acceso de recuperación de fallos a los discos multisistema. Cada nodo que está físicamente conectado a discos multisistema proporciona una ruta al almacenamiento para cualquier nodo del clúster.

Normalmente, para Solaris Volume Manager, los espacios de nombres del gestor de volúmenes están ubicados en los directorios /dev/md/conjunto_discos /dsk (y rdsk). Para Veritas VxVM, los espacios de nombres del gestor de volúmenes están ubicados en los directorios /dev/vx/dsk/ grupo-disco y /dev/vx/rdsk/grupo-disco . Estos espacios de nombres están formados por directorios para cada conjunto de discos de Gestor de volúmenes de Solaris y cada grupo de discos de VxVM importados a través del clúster, respectivamente. Cada uno de estos directorios contiene un nodo de dispositivo para cada metadispositivo o volumen de dicho conjunto de discos o grupo de discos.

En el sistema Sun Cluster todos los nodos de dispositivos del espacio de nombres del gestor de volúmenes local se sustituyen por un enlace simbólico con un nodo de dispositivo del sistema de archivos /global/.devices/node@IDnodo, donde IDnodo es un número entero que representa los nodos del clúster. El software Sun Cluster continúa presentando los dispositivos del gestor de volúmenes como enlaces simbólicos y también en sus ubicaciones estándar. Tanto el espacio de nombres global como el estándar del gestor de volúmenes están disponibles desde cualquier nodo del clúster.

Entre las ventajas de los espacios de nombres, se incluyen las siguientes:

• Cada nodo permanece bastante independiente, con pocos cambios en el modelo de administración de dispositivos.

• Los dispositivos puede convertirse en globales de forma selectiva.

• Los generadores de enlaces de terceros siguen funcionando.

• Dado un nombre de dispositivo local, se ofrece una correlación simple para obtener un nombre global.

Ejemplo de espacio de nombres local y global

La tabla siguiente muestra las correlaciones entre los espacios de nombres local y global para un disco multisistema, c0t0d0s0.

El espacio de nombres global se genera automáticamente durante la instalación y se actualiza con cada arranque de reconfiguración; también se puede generar mediante la orden scgdevs(1M).

Sistemas de archivos de clúster

El sistema de archivos del clúster dispone de las prestaciones siguientes:

• Las ubicaciones de los accesos de archivo son transparentes. Un proceso puede abrir un archivo que se encuentre en cualquier ubicación del sistema. Los procesos de todos los nodos pueden usar el mismo nombre de ruta para localizar un archivo.

  ---

  Nota –

  Cuando el sistema de archivos del clúster lee archivos, no actualiza la hora de acceso en esos archivos.

  ---

• Se utilizan protocolos de coherencia para preservar la semántica de acceso a archivos UNIX aunque varios nodos estén accediendo al archivo al mismo tiempo.

• Para mover datos de archivos eficientemente se utiliza masivamente la antememoria y el movimiento de E/S en bloque sin copia.

• El sistema de archivos del clúster ofrece el bloqueo de archivos de aviso de alta disponibilidad a través de las interfaces fcntl(2). Las aplicaciones que se ejecuten en varios nodos del clúster pueden sincronizar el acceso a los datos mediante el bloqueo a los archivos de aviso en un archivo del sistema de archivos del clúster. Los bloqueos de archivo se recuperan inmediatamente desde los nodos que abandonan el clúster y las aplicaciones que fallan mientras se mantienen los bloqueos.

• El acceso continuo a los datos queda asegurado aunque se produzcan fallos. Las aplicaciones no se ven afectadas por fallos si sigue estando operativa una ruta de acceso a los discos. Esta garantía se mantiene para el acceso a discos de bajo nivel y todas las operaciones del sistema de archivos.

• Los sistemas de archivos del clúster son independientes del sistema de archivos subyacente y del software de gestión de volúmenes; convierten en global cualquier sistema de archivos en disco admitido.

Se puede montar un sistema de archivos en un dispositivo global con mount -g (globalmente) o con mount (localmente).

Los programas pueden acceder a un archivo en un sistema de archivos en clúster desde cualquier nodo del clúster a través del mismo nombre de archivo (por ejemplo, /global/foo).

Los sistemas de archivos del clúster se montan en todos los miembros del clúster, pero no puede montarse en un subconjunto de miembros del clúster.

Los sistemas de archivo clúster no son de tipo diferenciado. Los clientes verifican el sistema de archivos que subyace (por ejemplo, UFS).

Uso de los sistemas de archivos del clúster

En el sistema Sun Cluster todos los discos multisistema se sitúan en grupos de dispositivos de disco que pueden ser conjuntos de discos de Gestor de volúmenes de Solaris, grupos de discos de VxVM o discos individuales que no estén bajo el control de ningún gestor de volúmenes basado en software.

Para que un sistema de archivos del clúster sea de alta disponibilidad, el almacenamiento en disco subyacente debe estar conectado a más de un nodo. Por consiguiente, un sistema de archivos local (aquel que está almacenado en el disco local de un nodo) que se convierte en un sistema de archivos del clúster no es de alta disponibilidad.

Puede montar sistemas de archivos del clúster del mismo modo que montaría sistemas de archivos normales:

• Manualmente — Use el comando mount y las opciones de montaje -g o bien -o global para montar el sistema de archivos del clúster desde la línea de comandos, por ejemplo:

  SPARC: # mount -g /dev/global/dsk/d0s0 /global/oracle/data

• Automáticamente— Cree una entrada en el archivo /etc/vfstab con una opción de montaje global para montar el sistema de archivos del clúster en el arranque. Después puede crear un punto de montaje en el directorio /global de todos los nodos. El directorio /global es la ubicación que se recomienda, pero no es obligatorio usarlo. A continuación, figura una línea de ejemplo para un sistema de archivos del clúster desde un archivo /etc/vfstab:

  SPARC: /dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/data ufs 2 yes global,logging

Mientras el software Sun Cluster no impone ninguna directiva de asignación de nombre para los sistemas de archivos del clúster, puede facilitar la administración creando un punto de montaje para todos los sistemas de archivo del clúster en el mismo directorio como, por ejemplo, /global/grupo-dispositivo-disco. Consulte la Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) y la Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener más información.

Tipo de recurso de HAStoragePlus

El tipo de recurso de HAStoragePlus está designado para hacer configuraciones de sistema de archivo no globales, como UFS y VxFS, de alta disponibilidad. Use HAStoragePlus para integrar su sistema de archivos local en el entorno de Sun Cluster y hacer que el sistema de archivos tenga una alta disponibilidad. HAStoragePlus proporciona funciones de sistema de archivo adicionales como comprobaciones, montajes y desmontajes forzados que capacitan a Sun Cluster para recuperarse de los errores de los sistemas de archivos locales. Para la recuperación de fallos el sistema de archivos local debe residir en grupos de discos globales que tengan habilitados conmutadores de afinidad.

Consulte Enabling Highly Available Local File Systems de Sun Cluster Data Services Planning and Administration Guide for Solaris OS para obtener información acerca de cómo usar el tipo de recurso de HAStoragePlus.

HAStoragePlus se puede usar también para sincronizar el inicio de los recursos y los grupos de dispositivos de disco de los que dependen los recursos. Para obtener más información, consulte Tipos de recursos, grupos de recursos y recursos .

La opción de montaje Syncdir

Puede usar la opción de montaje syncdir para los sistemas de archivos del clúster que usen UFS como el sistema de archivos subyacente. No obstante, el rendimiento mejora significativamente si no se especifica syncdir. Si especifica syncdir, se garantiza que lo que se escriba sea compatible con POSIX. Si no especifica syncdir, experimentará la misma conducta que con los sistemas de archivos NFS. Por ejemplo, sin syncdir, puede que no se detecte una situación de falta de espacio hasta que cierre un archivo. Con syncdir (y el comportamiento POSIX), la condición de falta de espacio se descubriría durante la operación de escritura. Los casos en los que se pueden producir problemas si no se especifica syncdir son poco habituales.

Si está utilizando un clúster basado en SPARC, VxFS no tiene ningún punto de montaje que sea equivalente a la opción de montaje syncdir para UFS. El comportamiento de VxFS es el mismo que para UFS cuando no se especifica la opción de montaje syncdir.

Consulte FAQ sobre los sistemas de archivos para ver las preguntas frecuentes acerca de los dispositivos globales y los sistemas de archivos del clúster.

Supervisión de la ruta de discos

La versión actual del software Sun Cluster admite la supervisión de rutas de discos (DPM) Este apartado incluye información conceptual sobre DPM, el daemon DPM, y las herramientas de administración que se pueden usar para supervisar las rutas del disco. Consulte la Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener información sobre los procedimientos para supervisar, dejar de supervisar y comprobar el estado de las rutas del disco.

DPM no se admite en los nodos que ejecutan versiones anteriores a Sun Cluster 3.1 10/03. No utilice órdenes de DPM durante una modernización. Una vez finalizada la modernización en todos los nodos, éstos deben estar en línea para poder utilizar las órdenes de DPM.

Información general de DPM

DPM mejora la disponibilidad general de la recuperación de fallos y la conmutación por supervisión de la disponibilidad de la ruta de acceso a disco secundaria. Utilice el comando scdpm para verificar la disponibilidad de la ruta del disco que utiliza un recurso antes de conmutarlo. Las opciones que se proporcionan con el comando scdpm le permiten supervisar las rutas de discos a un único nodo o a todos los nodos del clúster. Consulte la página de comando man scdpm(1M) para obtener más información acerca de las opciones de la línea de comandos.

Los componentes DPM se instalan a partir del paquete SUNWscu. El paquete SUNWscu se instala durante el procedimiento de instalación estándar de Sun Cluster. Consulte la página de comando man scinstall(1M) para obtener detalles sobre la interfaz de instalación. En la siguiente tabla se indica la ubicación predeterminada para la instalación de los componentes de DPM.

En cada nodo se ejecuta un daemon DPM de subproceso múltiple. El daemon DPM (scdpmd) lo inicia la secuencia rc.d cuando arranca un nodo. Si surge algún problema, pmfd gestiona el daemon y lo reinicia automáticamente. La lista siguiente describe cómo funciona scdpmd en el arranque inicial.

En el arranque, el estado de cada ruta del disco se inicializa a UNKNOWN.

1. El daemon DPM recopila información sobre la ruta del disco y el nombre del nodo desde el archivo de estado anterior o desde la base de datos CCR. Consulte la Cluster Configuration Repository (CCR) para obtener más información acerca de CCR. Cuando se inicia el daemon DPM, éste puede forzarse para que lea la lista de discos supervisados a partir de un nombre de archivo especificado.

2. El daemon DPM inicializa la interfaz de comunicaciones para que responda a solicitudes de componentes que son externos al mismo, como la interfaz de línea de órdenes.

3. El daemon DPM realiza un ping a cada ruta del disco de la lista supervisada cada 10 minutos mediante órdenes de tipo scsi_inquiry. Todas las entradas están bloqueadas para evitar que la interfaz de comunicaciones acceda al contenido de una entrada que esté siendo modificada.

4. El daemon de DPM informa a la estructura sobre los eventos de Sun Cluster y registra el nuevo estado de la ruta mediante el mecanismo de UNIX syslogd(1M).

pmfd (1M) registra todos los errores relacionados con el daemon. Todas las funciones de la API devuelven 0 cuando tienen éxito y -1 cuando se produce algún error.

El daemon DPM supervisa la disponibilidad de la ruta lógica que está visible a través de controladores multirruta como Gestor de tráfico Sun StorEdge, HDLM y PowerPath. Las rutas de acceso físicas individuales gestionadas por estos controladores no están supervisadas porque el controlador de ruta múltiple oculta los fallos individuales al daemon DPM.

Supervisión de las rutas del disco

Este apartado describe dos métodos para supervisar las rutas del disco en el clúster. El primer método lo ofrece el comando scdpm. Utilice esta orden para supervisar, dejar de supervisar o mostrar el estado de las rutas del disco del clúster; Este comando también es útil para imprimir la lista de discos con fallos y supervisar las rutas de disco desde un archivo.

El segundo método para supervisar las rutas de los discos en el clúster lo ofrece la interfaz gráfica de usuario (GUI) de SunPlex Manager. SunPlex Manager incluye una vista topográfica de las rutas del disco supervisadas del clúster La vista se actualiza cada 10 minutos para incluir información sobre el número de pings que han fallado. Para administrar rutas del disco use la información que proporciona la GUI de SunPlex Manager junto con la orden scdpm(1M). Consulte el Capítulo 10, Administración de Sun Cluster con las interfaces gráficas de usuario de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener información acerca de SunPlex Manager.

Uso de la orden scdpm para supervisar las rutas del disco

El comando scdpm(1M) proporciona a DPM comandos de administración que permiten realizar las tareas siguientes:

• Supervisar una ruta del disco nueva

• Dejar de supervisar una ruta del disco

• Volver a leer los datos de configuración de la base de datos CCR

• Leer los discos para supervisar o dejar de hacerlo a partir de un archivo especificado

• Informar del estado de una o todas las rutas de acceso de disco del clúster

• Imprimir todas las rutas de acceso de disco que son accesibles desde un nodo

Emita la orden scdpm(1M) con el argumento ruta-disco desde cualquier nodo para llevar a cabo tareas de administración de DPM en el clúster. Éste consta en todos los casos de un nombre de nodo y de un nombre de disco. El nombre del nodo no es obligatorio y su valor predeterminado es all si no se especifica otra cosa. La tabla siguiente describe las convenciones de asignación de nombres para la ruta del disco.

Se recomienda utilizar nombres de ruta del disco globales, ya que son coherentes dentro de todo el clúster. Los nombres de las rutas del disco UNIX no son coherentes en todo el clúster. La ruta del disco UNIX correspondiente a un disco determinado puede diferir en distintos nodos del clúster. La ruta podría ser c1t0d0 en un nodo y c2t0d0 en otro. Si utiliza nombres de ruta del disco UNIX, utilice la orden scdidadm -L para asignar el nombre UNIX al nombre global antes de ejecutar órdenes de DPM. Consulte la página de comando man de scdidadm(1M).

Uso de SunPlex Manager para supervisar las rutas del disco

SunPlex Manager permite realizar las siguientes tareas de administración DPM básicas:

• Supervisar una ruta del disco

• Dejar de supervisar una ruta del disco

• Ver el estado de todas las rutas del disco en el clúster

Consulte la ayuda en línea de SunPlex Manager para obtener información de procedimientos para realizar una administración de la ruta del disco utilizando SunPlex Manager.

Quórum y dispositivos del quórum

Esta sección se divide en los siguientes apartados:

• Acerca de los recuentos de votos del quórum

• Acerca del aislamiento de fallos

• Acerca de las configuraciones del quórum

• Cumplimiento de los requisitos de dispositivos de quórum

• Mejores prácticas relacionadas con los dispositivos del quórum

• Configuraciones de quórum recomendadas

• Configuraciones de quórum atípicas

• Configuraciones de quórum malas

Para obtener una lista de los dispositivos específicos que Sun Cluster admite como dispositivos de quórum, póngase en contacto con el proveedor de servicios Sun.

Debido a que los nodos del clúster comparten datos y recursos, un clúster nunca se debe dividir en particiones separadas que estén activas a la vez porque varias particiones activas pueden provocar que se dañen los datos. Cluster Membership Monitor (CMM) y el algoritmo de quórum garantizan que como mucho una instancia del mismo clúster está operativa cada vez, incluso si se particiona la interconexión del clúster.

Para obtener una introducción acerca del quórum y CMM, consulte Pertenencia al clúster de Sun Cluster para el sistema operativo Solaris: Visión general.

De las particiones de clústeres surgen dos tipos de problemas:

• Esquizofrenia

• Amnesia

La esquizofrenia se produce cuando se pierde la interconexión del clúster entre nodos y el clúster se particiona en clústeres secundarios. Cada partición “cree” que es la única existente porque los nodos de una partición no pueden comunicarse con el nodo de la otra partición.

La amnesia se produce cuando el clúster se reinicia después de un apagado teniendo datos de configuración del clúster más antiguos que los del momento del apagado. Este problema se da cuando se inicia el clúster en un nodo que no estaba en la última partición del clúster que estuvo en funcionamiento.

Sun Cluster evita la esquizofrenia y amnesia:

• Asignando un voto a cada nodo

• Controlando la mayoría de los votos de un clúster operativo

Una partición con la mayoría de votos tiene quórum y se le permite funcionar. Este mecanismo de votos de la mayoría evita la esquizofrenia y amnesia cuando hay más de dos nodos configurados en un clúster. Sin embargo, el recuento de los votos de los nodos por sí solo no es suficiente cuando hay más de dos nodos configurados en un clúster. En un clúster de dos nodos, la mayoría es dos. Si dicho clúster de dos nodos se particiona, es necesario un voto externo para que cualquiera de las particiones obtenga quórum. Este voto externo lo proporciona un dispositivo del quórum

Acerca de los recuentos de votos del quórum

Use la opción -q del comando scstat para determinar la siguiente información:

• Votos totales configurados

• Votos presentes actuales

• Votos necesarios para quórum

Para obtener más información acerca de este comando, consulte scstat(1M).

Los nodos y los dispositivos de quórum aportan votos al clúster para formar quórum.

Un nodo aporta votos en función del estado del nodo:

• Un nodo tiene un recuento de votos de uno cuando arranca y es miembro del clúster.

• Un nodo tiene un recuento de voto de cero cuando el nodo se está instalando.

• Un nodo tiene un recuento de voto de cero cuando un administrador de sistema pone el nodo en estado de mantenimiento.

Los dispositivos del quórum aportan votos basados en el número de votos que están conectados al dispositivo. Cuando se configura un dispositivo del quórum, el software Sun Cluster asigna al dispositivo del quórum un recuento de votos de N-1, donde N es el número de votos conectados al dispositivo del quórum. Por ejemplo, un dispositivo del quórum conectado a dos nodos con recuentos distintos de cero, tiene un recuento del quórum igual a uno (dos menos uno).

Un dispositivo de quórum aporta votos si se cumple una de las siguientes condiciones:

• Al menos uno de los nodos a los que está conectado actualmente el dispositivo de quórum es miembro del clúster.

• Al menos uno de los nodos a los que el dispositivo de quórum está conectado está arrancando y dicho nodo era miembro de la última partición de clúster propietaria del dispositivo de quórum.

Los dispositivos del quórum se configuran durante la instalación del clúster o posteriormente utilizando los procedimientos descritos en el Capítulo 5, Administración del quórum de Sun Cluster: Guía de administración del sistema para el SO Solaris.

Acerca del aislamiento de fallos

Un problema fundamental de los clústers es un fallo que provoque en éstos una partición (denominada esquizofrenia). Cuando esto ocurre, no todos los nodos pueden comunicarse, por lo que algunos podrían intentar formar clústers individuales o subconjuntos que “creerían” que tienen permisos de acceso y de propiedad exclusivos respecto a los dispositivos multisistema. Cuando varios nodos intentan escribir en los discos, los datos se pueden dañar.

El aislamiento de fallos limita el acceso de los nodos a los dispositivos multisistema, evitando que físicamente se pueda acceder a ellos. Cuando un nodo abandona el clúster (falla o se particiona), el aislamiento de fallos se asegura de que el nodo ya no pueda acceder a los discos. Sólo los nodos miembros actuales tendrán acceso a los discos, conservándose así la integridad de los datos.

Los servicios de dispositivos de disco ofrecen prestaciones de recuperación de fallos para servicios que utilizan dispositivos multisistema. Cuando falla o no se puede localizar un miembro del clúster que actualmente funciona como el principal (propietario) del grupo de dispositivos de disco, se elige un nuevo miembro principal. El nuevo miembro principal habilita el acceso al grupo de dispositivos de disco para que se pueda continuar funcionando con la menor interrupción posible. Durante este proceso, el antiguo miembro principal debe perder sus derechos de acceso en favor de los dispositivos antes de que se pueda iniciar el nuevo miembro principal. Sin embargo, cuando un miembro se descuelga del clúster y deja de estar disponible, éste no puede informar al nodo que libere los dispositivos para los que era primario. Por tanto, se necesita un medio para permitir que los miembros supervivientes tomen control y accedan a los dispositivos globales de los miembros fallidos.

El sistema Sun Cluster usa reservas de disco SCSI para implementar el aislamiento de fallos, gracias a las cuales, los nodos fallidos se “aíslan” de los dispositivos multisistema, evitando que accedan a estos discos.

Las reservas de disco SCSI-2 admiten una forma de reservas que garantizan el acceso a todos los nodos adjuntos al disco (cuando no hay ninguna reserva). De lo contrario, el acceso se restringe a un solo nodo (el que tiene la reserva).

Cuando un miembro del clúster detecta que otro nodo ya no se está comunicando a través de la interconexión del clúster, inicia un procedimiento de aislamiento de fallos para evitar que el otro nodo acceda a los discos compartidos. En este proceso, el nodo excluido emite avisos graves y aparece un mensaje de “conflicto de reserva” en la consola.

El descubrimiento de que el nodo ya no es un miembro del clúster desencadena una reserva SCSI en todos los discos que están compartidos entre este nodo y los demás. El nodo aislado puede que no sea “consciente” de que está siendo aislado y, si intenta acceder a uno de los discos compartidos, detecta la reserva y emite avisos graves.

Mecanismo de recuperación rápida para aislamiento de fallos

El mecanismo mediante el cual la estructura del clúster se asegura de que un nodo que ha fallado no pueda reiniciarse ni comenzar a escribir en un almacenamiento compartido se llama recuperación rápida.

Los nodos que son miembros del clúster habilitan permanentemente un ioctl específico, MHIOCENFAILFAST, para los discos a los que tienen acceso, incluidos los de quórum. Este ioctl es una directiva para el controlador del disco. El ioctl proporciona al nodo la capacidad de enviar mensajes graves en caso de que no pueda acceder al disco porque éste esté reservado por algún otro nodo.

El MHIOCENFAILFAST ioctl provoca que el controlador marque el error devuelto desde cada lectura y escritura que el nodo emita para el disco con el código de error Reservation_Conflict. En segundo plano y de forma periódica, el ioctl emite operaciones de prueba para el disco para comprobar el código de error Reservation_Conflict. Las rutas de flujo de control en segundo y en primer plano emiten mensajes graves si se devuelve Reservation_Conflict.

En discos SCSI-2, las reservas no son persistentes, pues no resisten los rearranques de los nodos. En los discos SCSI-3 con reserva de grupo persistente (PGR), la información de reserva se almacena en el disco y permanece entre los rearranques de los nodos. El mecanismo de recuperación rápida funciona lo mismo, independientemente de que se tengan discos SCSI-2 o SCSI-3.

Si un nodo pierde conectividad con los otros nodos del clúster y no es parte de una partición que pueda conseguir el quórum, otro nodo lo expulsa del clúster. Otro nodo que forma parte de la partición que puede conseguir reservas de plazas del quórum en los discos compartidos. Cuando el nodo que no tiene quórum intenta acceder a los discos compartidos, recibe un conflicto de reserva y emite mensajes graves como resultado del mecanismo de recuperación rápida.

Después de la condición de aviso grave, el nodo podría rearrancar e intentar volver a unirse al clúster o, si éste se compone de sistemas basados en plataformas SPARC, permanecer en el indicador PROM (OBP) de OpenBoot^TM. La acción que se toma depende del valor del parámetro auto-boot?. Puede definir auto-boot? con eeprom(1M), en el indicador OpenBoot PROM ok de un clúster basado en SPARC. Si lo desea, también puede configurar este parámetro con la utilidad SCSI, que puede ejecutar opcionalmente después de que arranque la BIOS en un clúster basado en x86.

Acerca de las configuraciones del quórum

La siguiente lista contiene hechos acerca de las configuraciones de quórum:

• Los dispositivos de quórum pueden contener datos de usuario.

• En una configuración N+1, donde N dispositivos del quórum se conectan a uno de 1 a través de N nodos y el nodo N+1, el clúster sobrevive al fallo de cualquiera de ellos 1 mediante N nodos o cualquiera de los N/2 nodos. Esta disponibilidad asume que el dispositivo de quórum está funcionando correctamente.

• En una configuración de N- nodos donde un único dispositivo del quórum se conecta a todos los nodos, el clúster puede sobrevivir al fallo de cualquiera de los N-1 nodos. Esta disponibilidad asume que el dispositivo de quórum está funcionando correctamente.

• En una configuración de N nodos donde un único dispositivo de quórum se conecta a todos los nodos, el clúster puede sobrevivir al fallo del dispositivo de quórum si todos los nodos del clúster están disponibles.

Para ver los tipos de configuraciones del quórum que se deben evitar, consulte Configuraciones de quórum malas . Para ver los tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .

Cumplimiento de los requisitos de dispositivos de quórum

Debe cumplir los siguientes requisitos. Si hace caso omiso de estos requisitos, la disponibilidad del clúster puede verse comprometida.

• Asegúrese de que Sun Cluster admite el dispositivo específico como dispositivo de quórum.

  ---

  Nota –

  Para obtener una lista de los dispositivos específicos que Sun Cluster admite como dispositivos de quórum, póngase en contacto con el proveedor de servicios Sun.

  ---

  Sun Cluster admite dos tipos de dispositivos de quórum:

  • Discos compartidos con varios sistemas que admiten reservas SCSI-3 PGR

  • Discos compartidos de doble sistema que admiten reservas SCSI-2

• En una configuración de dos nodos, debe configurar al menos un dispositivo de quórum para asegurar que un único nodo puede continuar si el otro nodo falla. Consulte la Figura 3–2.

Para ver los tipos de configuraciones del quórum que se deben evitar, consulte Configuraciones de quórum malas . Para ver tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .

Mejores prácticas relacionadas con los dispositivos del quórum

Use la siguiente información para evaluar la mejor configuración de quórum para su topología:

• ¿Tiene un dispositivo capaz de estar conectado a todos los nodos del clúster?

  • En caso afirmativo, configure dicho dispositivo como el dispositivo de quórum. No necesita configurar otro dispositivo del quórum porque su configuración es óptima.

    ---

    Precaución –

    Si ignora este requisito y añade otro dispositivo de quórum, el dispositivo de quórum adicional reduce la disponibilidad del clúster.

    ---

  • En caso contrario, configure el dispositivo(s) de doble puerto.

• Asegúrese de que el número de votos aportados por los dispositivos de quórum es menor que el número de votos total aportados por los nodos. En caso contrario los nodos no pueden formar un clúster si todos los discos no están disponibles—, incluso si todos los nodos están funcionando.

  ---

  Nota –

  En entornos concretos, puede que desee reducir la disponibilidad general del clúster para satisfacer sus necesidades. En estas situaciones, puede ignorar estas recomendaciones. Sin embargo, no cumplir estas recomendaciones reduce la disponibilidad general. Por ejemplo, en la configuración que se describe en Configuraciones de quórum atípicas , el clúster está menos disponible: los votos del quórum superan los votos del nodo. El clúster tiene la propiedad de que si se pierde el acceso al almacenamiento compartido entre los nodos A y B, fallará el clúster entero.

  ---

  Consulte Configuraciones de quórum atípicas para conocer las excepciones a estas mejores prácticas.

• Especifique un dispositivo de quórum entre cada par de nodos que compartan el acceso al dispositivo de almacenamiento. Esta configuración del quórum agiliza el proceso de aislamiento de fallos. Consulte Quórum en configuraciones de más de dos nodos .

• En general, si la adición de un dispositivo de quórum iguala el número total de votos del clúster, la disponibilidad del clúster disminuye.

• Los dispositivos de quórum ralentizan ligeramente las reconfiguraciones después de que se una un nodo nuevo o se desactive uno antiguo. Por tanto, no agregue más dispositivos de quórum de los necesarios.

Para ver los tipos de configuraciones del quórum que se deben evitar, consulte Configuraciones de quórum malas . Para ver tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .

Configuraciones de quórum recomendadas

Esta sección contiene ejemplos de configuraciones recomendadas del quórum. Para ver los tipos de configuraciones del quórum que se deben evitar, consulte Configuraciones de quórum malas .

Quórum en configuraciones de dos nodos

Son necesarios dos votos de quórum para que se forme un clúster de dos nodos. Estos dos votos pueden proceder de los dos nodos del clúster o de un nodo y un dispositivo del quórum.

Figura 3–2 Configuración de dos nodos

Quórum en configuraciones de más de dos nodos

Puede configurar un clúster con más de dos nodos sin dispositivo del quórum. No obstante, si lo hace así, no podrá iniciar el clúster sin una mayoría de nodos en el clúster.

Configuraciones de quórum atípicas

En la Figura 3–3 se da por hecho que se están ejecutando aplicaciones con un papel fundamental (una base de datos de Oracle, por ejemplo) en el nodo A y en el B. Si el Nodo A y el Nodo B no están disponibles y no se puede acceder a los datos compartidos, es posible que prefiera que todo el clúster se apague. En caso contrario, esta configuración no es óptima porque no proporciona una alta disponibilidad.

Para obtener información acerca de las mejores prácticas relacionadas con esta excepción, consulte Mejores prácticas relacionadas con los dispositivos del quórum .

Figura 3–3 Configuración atípica

Configuraciones de quórum malas

Esta sección contiene ejemplos de configuraciones que se deben evitar. Para ver tipos de configuraciones del quórum recomendadas, consulte Configuraciones de quórum recomendadas .

Servicios de datos

El término servicio de datos describe una aplicación, como por ejemplo Oracle o Sun Java System Web Server, que se ha configurado para ejecutarse en un clúster en lugar de en un servidor individual. Un servicio de datos se compone de una aplicación, archivos de configuración especializados de Sun Cluster y métodos de gestión de Sun Cluster que controlan las acciones siguientes de la aplicación.

• Inicio

• Detener

• Supervisar y tomar acciones correctoras

Para obtener información acerca de los tipos de servicios de datos, consulte Servicios de datos de Sun Cluster para el sistema operativo Solaris: Visión general.

En la Figura 3–4 se compara una aplicación que se ejecuta en un único servidor de aplicaciones (modelo de servidor único) con la misma aplicación pero ejecutándose en un clúster (modelo de servidor en clúster). La única diferencia entre las dos configuraciones es que la aplicación en clúster puede que se ejecute más rápidamente y tenga una mayor disponibilidad.

Figura 3–4 Configuración estándar y configuración cliente-servidor

En el modelo de servidor único, la aplicación se configura para que acceda al servidor a través de una interfaz de red pública concreta (un nombre de sistema). El nombre de sistema está asociado con este servidor físico.

En el modelo de servidor en clúster, la interfaz de red pública es un nombre de sistema lógico o una dirección compartida. El término recursos de red se utiliza para referirse a los nombres de sistema lógicos y para las direcciones compartidas.

Algunos servicios de datos requieren que se especifiquen los nombres de sistema lógicos o las direcciones compartidas como interfaces de red. Los nombres de sistema lógicos y las direcciones compartidas no se pueden intercambiar; otros, en cambio, permiten especificar nombres de sistema lógicos o direcciones compartidas. Consulte la instalación y la configuración para cada servicio de datos para obtener detalles acerca del tipo de interfaz que debe especificar.

Un recurso de red no está asociado a un servidor físico específico. Un recurso de red puede migrar entre servidores físicos.

Un recurso de red está asociado inicialmente a un nodo, el primario. Si el primario falla, el recurso de red y el recurso de aplicación se recuperan del fallo usando un nodo de clúster diferente (secundario). Cuando el recurso de red se recupera del problema, después de un breve intervalo, el recurso de aplicación continúa ejecutándose en el secundario.

En la Figura 3–5 se compara un modelo de servidor único con un modelo de servidor en clúster. Tenga en cuenta que en el modelo de servidor basado en clúster un recurso de red (nombre de sistema lógico, en este ejemplo) puede trasladarse entre dos o más nodos del clúster. La aplicación está configurada para usar este nombre de sistema lógico en lugar de uno asociado a un servidor en particular.

Figura 3–5 Comparación entre los nombres de sistema fijo y lógico

Una dirección de red también está asociada inicialmente a otro nodo. Este nodo se denomina nodo de interfaz global. Una dirección compartida (conocida como interfaz global) se utiliza como interfaz de red única para el clúster.

La diferencia entre el modelo de nombre de sistema lógico y el modelo de servicio escalable es que en este último, cada nodo tiene la dirección de red activamente configurada en su interfaz de bucle inverso. Esta configuración permite que haya múltiples instancias de un servicio de datos activas en varios nodos simultáneamente. El término “servicio escalable” significa que puede agregarse más potencia de CPU a la aplicación agregando nodos del clúster adicionales con lo que el rendimiento se multiplicará.

Si el nodo de interfaz global falla, la dirección compartida puede iniciarse en otro nodo que también esté ejecutando una instancia de la aplicación (convirtiendo así al otro nodo en el nuevo nodo de interfaz global). O, la dirección compartida puede trasladarse a otro nodo del clúster que no estuviera ejecutando la aplicación previamente.

En la Figura 3–6 se compara una configuración de servidor único con una configuración de servicio escalable basada en clúster. Tenga en cuenta que, en la configuración de servicio escalable, la dirección compartida está presente en todos los nodos. De forma análoga a como se usan los nombres de sistema para los servicios de datos de recuperación de fallos, la aplicación se configura para usar esta dirección compartida en lugar de un nombre de sistema asociado a un servidor determinado.

Figura 3–6 Comparación entre los nombres de sistema fijos y las direcciones compartidas

Métodos de servicios de datos

El software Sun Cluster proporciona un conjunto de métodos de gestión de servicios Estos métodos se ejecutan bajo el control de Gestor de grupos de recursos (RGM), que los utiliza para iniciar, detener y supervisar la aplicación en los nodos del clúster. Estos métodos, junto con el software de la estructura del clúster y los dispositivos multisistema, permiten a las aplicaciones convertirse en servicios de datos a prueba de fallos o escalables.

RGM también gestiona los recursos del clúster, incluidas las instancias de una aplicación y de los recursos de red (nombres de sistema lógicos y direcciones compartidas).

Además de los métodos proporcionados mediante el software de Sun Cluster, el sistema Sun Cluster también proporciona una API y varias herramientas de desarrollo de servicio de datos. Estas herramientas permiten a los desarrolladores de aplicaciones desarrollar los métodos de servicios de datos necesarios para que otras aplicaciones se puedan ejecutar como servicios de datos de alta disponibilidad con el software Sun Cluster.

Servicios de datos de recuperación de fallos

Si el nodo en el que se está ejecutando el servicio de datos (el primario) falla, el servicio migra a otro nodo en funcionamiento sin intervención del usuario. Los servicios de recuperación de fallos usan un grupo de recursos de recuperación de fallos, que es un contenedor para los recursos de instancias de aplicaciones y recursos de la red (nombres de sistemas lógicos). Los nombres de sistemas lógicos son direcciones IP que pueden configurarse como activas en un nodo y, posteriormente, configurarse automáticamente como inactivas en el nodo original y activarse en otro nodo.

En los servicios de datos a prueba de fallos, las instancias de las aplicaciones sólo se ejecutan en un nodo individual. Si el supervisor de fallos detecta un error, intenta reiniciar la instancia en el mismo nodo o bien intenta iniciarla en otro nodo (el de recuperación de fallos). El resultado depende de la forma en que se haya configurado el servicio de datos.

Servicios de datos escalables

Los servicios de datos escalables tienen la capacidad de activar instancias en varios nodos; Los servicios escalables utilizan los dos siguientes grupos de recursos:

• Un grupo de recursos escalables contiene los recursos de aplicación.

• Un grupo de recursos de recuperación de fallos contiene los recursos de red (direcciones compartidas) de los que depende el servicio escalable.

El grupo de recursos escalable puede estar en línea en varios nodos, de forma que se puedan ejecutar varias instancias del servicio simultáneamente. El grupo de recurso a prueba de fallos que aloja la dirección compartida está disponible en un solo nodo cada vez. Todos los nodos que alojan un servicio escalable usan la misma dirección compartida para alojar el servicio.

Las solicitudes de servicio entran en el clúster a través de una interfaz de red única (la interfaz global). Estas solicitudes se distribuyen a los nodos, basándose en uno de los algoritmos predefinidos especificados por la directiva de equilibrado de cargas que el clúster puede usar para equilibrar la carga del servicio entre varios nodos. Puede haber varias interfaces globales en distintos nodos que alojen otras direcciones compartidas.

En los servicios escalables, las instancias de las aplicaciones se ejecutan en varios nodos simultáneamente. Si el nodo que aloja la interfaz global falla, ésta se traspasa a otro nodo. Si falla una instancia de aplicación que se está ejecutando, la instancia intenta reiniciarse en el mismo nodo.

Si no se puede reiniciar una instancia de una aplicación en el mismo nodo, y se configura otro nodo que no esté en uso para ejecutar el servicio, éste se transfiere a este nodo. De lo contrario, el servicio continúa ejecutándose en los nodos restantes, lo que posiblemente provocará una degradación del rendimiento del servicio.

El estado TCP para cada instancia de aplicación se conserva en el nodo de la instancia, no en el de la interfaz global. Por tanto el fallo en el nodo de interfaz global no afecta a la conexión.

La Figura 3–7 muestra un ejemplo de grupo de recursos escalables y de recuperación de fallos y las dependencias que existen entre ellos en cuanto a los servicios escalables. Este ejemplo muestra tres grupos de recursos. El grupo de recursos de recuperación de fallos contiene recursos de aplicación que usan los DNS de alta disponibilidad y recursos de red que usan éstos y el servidor Apache Web Server de alta disponibilidad (sólo en clústeres basados en SPARC). Los grupos de recursos escalables sólo contienen instancias de la aplicación de Apache Web Server. Tenga en cuenta que las dependencias de los grupos de recursos existen entre los grupos de recursos de recuperación de fallos y los escalables (líneas sólidas). Adicionalmente, todos los recursos de aplicación de Apache dependen del recurso de red schost-2, que es una dirección compartida (líneas de puntos).

Figura 3–7 SPARC: Ejemplo de los grupos de recursos a prueba de fallos y escalables

Políticas de equilibrio de cargas

El equilibrio de cargas mejora el rendimiento del servicio escalable, tanto en tiempo de respuesta como como en rendimiento. Hay dos clases de servicios de datos escalables.

• Puro

• Adosado

En un servicio puro, todas las instancias pueden responder a las solicitudes del cliente. En un servicio adosado, un cliente puede enviar solicitudes a la misma instancia. Estas peticiones no se redirigen a otras instancias.

Un servicio puro usa una política de equilibrio de cargas ponderada bajo la cual, predeterminadamente, las peticiones de los clientes se distribuyen de manera uniforme entre las instancias del servidor en el clúster. Por ejemplo, en un clúster de tres nodos, suponga que cada nodo tiene un peso de 1. Cada nodo atenderá 1/3 de las solicitudes procedentes de cualquier cliente en nombre de dicho servicio. El administrador puede cambiar el peso en cualquier momento usando la interfaz de comando scrgadm(1M) o la GUI de SunPlex Manager.

Un servicio adosado tiene dos perspectivas: adosado normal y adosado con comodines. Los servicios adosados permiten sesiones simultáneas de aplicación a través de varias conexiones TCP para que compartan la memoria en estado (estado de la sesión de aplicación).

Los normales permiten a un cliente compartir el estado entre varias conexiones TCP simultáneas. Se considera que el cliente es “adosado” con respecto a la instancia del servidor que recibe en un único puerto. Al cliente se le garantiza que todas sus solicitudes van a ir a la misma instancia del servidor, siempre que ésta permanezca activa y accesible y que la directiva de equilibrio de cargas no cambie mientras el servicio esté en línea.

Por ejemplo, un navegador Web en el cliente conecta con una dirección IP compartida en el puerto 80 usando tres conexiones TCP diferentes. Sin embargo, las conexiones intercambian con el servicio información de sesión almacenada en caché.

Una generalización de una directiva adosada amplía a varios servicios escalables dicha información de sesión de intercambio en segundo plano y en la misma instancia. Cuando estos servicios intercambian información de sesión en segundo plano y en la misma instancia, se considera que el cliente está “adosado” a varias instancias de servidor en el mismo nodo recibiendo información a través de distintos puertos. .

Por ejemplo, un cliente de un sitio de comercio electrónico llena su carro de la compra con artículos utilizando HTTP en el puerto 80. El cliente entonces cambia a SSL en el puerto 443 para enviar los datos de forma segura para pagar con tarjeta de crédito los artículos del carro.

Los servicios adosados comodín usan números de puerto asignados dinámicamente, pero siguen esperando que las peticiones de clientes vayan al mismo nodo. El cliente está “adosado con comodín” a los puertos que tienen la misma dirección IP.

Un buen ejemplo de esta política es el FTP de modalidad pasiva. Por ejemplo, un cliente se conecta a un servidor FTP mediante el puerto 21. El servidor entonces da instrucciones al cliente para que se vuelva a conectar a un servidor con puerto de escucha que esté en el intervalo de puertos dinámicos. Todos los requisitos para esta dirección IP se reenvían al mismo nodo mediante el que el servidor informó al cliente a través de la información de control .

Para cada una de estas directivas adosadas, la directiva de equilibrio de carga en función del peso está activada de forma predeterminada. Por lo tanto, una solicitud inicial del cliente se dirige a la instancia que indica el equilibrador de carga. Después de que el cliente establezca una afinidad para el nodo en el que se está ejecutando la instancia, las solicitudes futuras estarán dirigidas condicionalmente a dicha instancia. El nodo debe estar accesible y la directiva de equilibrado de carga no se debe haber modificado.

Los detalles adicionales de las directivas específicas de equilibrado de carga son las siguientes.

• Ponderada: la carga se distribuye entre varios nodos según valores de peso especificados. Esta directiva se define usando el valor LB_WEIGHTED para la propiedad Load_balancing_weights. Si no se establece explícitamente el peso de un nodo, éste toma de forma predeterminada el valor uno.

  La política de ponderación redirije cierta parte del tráfico de los clientes a un nodo determinado. Si consideramos que X=peso y A=el peso total de todos los nodos activos, un nodo activo recibirá aproximadamente X/A del total de conexiones nuevas que se dirijan al nodo activo. Sin embargo, el número total de conexiones debe ser lo suficientemente grande. Esta política no trata de peticiones individuales.

  Tenga en cuenta que esta política no es de tipo giratoria. Una política de este tipo provocará que cada solicitud de un cliente vaya a un nodo distinto. Por ejemplo, la primera solicitud iría al nodo 1, la segunda al nodo 2, etc.

• Adosada: en esta norma el conjunto de puertos se da a conocer en el momento en el que se configuran los recursos de la aplicación. Esta directiva se define usando el valor LB_STICKY para la propiedad Load_balancing_policy.

• Adosada-comodín: esta política tiene menos limitaciones que la “adosada” normal. En el caso de un servicio escalable que esté identificado mediante la dirección IP, los puertos los asigna el servidor (y no se conocen de antemano). Los puertos podrían cambiar. Esta directiva se define usando el valor LB_STICKY_WILD para la propiedad Load_balancing_policy.

Configuración de retroceso

Los grupos de recurso se cubren entre nodos. Cuando se produce una recuperación de fallos, el nodo secundario original pasa a ser el nuevo primario. La configuración de retroceso especifica las acciones que se producirán cuando el nodo principal vuelva a estar en línea. Las opciones son hacer que el primario original se convierta de nuevo en primario (retroceso) o permitir que el que haya tomado su papel continúe con él. Las opciones se especifican usando la configuración de la propiedad del grupo de recursos Failback .

Si falla el nodo original que alberga el grupo de recursos y se reinicia varias veces, la configuración de un retroceso podría reducir la disponibilidad del grupo de recursos.

Supervisor de fallos del servicio de datos

Cada servicio de datos de Sun Cluster proporciona un supervisor de fallos que explora periódicamente el servicio de datos para determinar su buen estado. Un supervisor de fallos comprueba que los daemons de las aplicaciones estén funcionando y que se esté dando servicio a los clientes. De acuerdo con la información que devuelven las comprobaciones, se pueden llevar a cabo acciones predefinidas, como reiniciar daemons o producir una recuperación de fallos.

Desarrollo de los nuevos servicios de datos

Sun proporciona archivos de configuración y plantillas de métodos de gestión que permiten hacer funcionar varias aplicaciones como servicios a prueba de fallos o escalables dentro de un clúster. Si Sun no le ofrece la aplicación que necesita ejecutar como servicio escalable o de recuperación de fallos, tiene una alternativa. Use una API de Sun Cluster o la API DSET para configurar la aplicación para que se ejecute como servicio escalable o de recuperación de fallos. Sin embargo, no todas las aplicaciones pueden convertirse en servicios escalables.

Características de los servicios escalables

Hay una serie de criterios que determinan si una aplicación puede convertirse o no en servicio escalable. Para determinar si su aplicación puede convertirse en servicio escalable, consulte Análisis de la validez de la aplicación de Sun Cluster: Guía del desarrollador de los servicios de datos del sistema operativo Solaris. Este conjunto de criterios se resume a continuación.

• Primero, el servicio se compone de una o varias instancias de servidor, cada una de las cuales se ejecuta en un nodo distinto del clúster. Dos o más instancias del mismo servicio no pueden ejecutarse en el mismo nodo.

• Segundo, si el servicio proporciona un almacén de datos lógico externo, deberá actuar con precaución. El acceso simultáneo a este almacén desde varias instancias de servidor debe estar sincronizado para evitar que se pierdan actualizaciones o datos de lectura mientras se estén modificando. Observe que se usa “externo” para distinguir este almacén del estado en memoria. El término “lógico” indica que el almacén aparece como una única entidad, aunque puede que esté replicado. Además, este almacén de datos lógico tiene la propiedad de que cada vez que una instancia de servidor actualiza el almacén, las demás instancias pueden “ver” la actualización de forma inmediata.

  El sistema de Sun Cluster proporciona un almacén externo a través de su sistema de archivos en clúster y sus particiones sin formato globales. Como ejemplo, supongamos que un servicio escribe datos nuevos a un archivo de registro cronológico externo o modifica los datos que haya. Cuando se ejecutan varias instancias de este servicio, cada instancia tiene acceso a su registro externo y cada una de ellas puede acceder simultáneamente a este registro. Cada instancia debe sincronizar su acceso a este registro o de lo contrario se interferirán entre ellas. El servicio puede usar normalmente el bloqueo de archivos de Solaris mediante fcntl(2) y lockf(3C) para lograr la sincronización necesaria.

  Otro ejemplo de este tipo de almacén es una base de datos de fondo (back-end), como pueda ser una instalación de Oracle Real Application Clusters Guard de alta disponibilidad para clústeres basados en SPARC o en Oracle. Este tipo de servidores de bases de datos de fondo (back-end) proporcionan sincronización integrada utilizando una consulta de base de datos o transacciones de actualización. En consecuencia, varias instancias de servidor no necesitan implementar su propia sincronización.

  El servidor Sun IMAP es un ejemplo de servicio que no es escalable. El servicio actualiza un almacenamiento, pero es privado y cuando varias instancias de IMAP escriben en él, se sobrescriben porque las actualizaciones no están sincronizadas. El servidor IMAP debe volver a escribirse para que se sincronice el acceso simultáneo.

• Por último, tenga en cuenta que las instancias pueden tener datos privados que no tengan nada que ver con los datos de otras instancias. En estos casos, el servicio no necesita un acceso simultáneo sincronizado porque los datos son privados y sólo puede gestionarlos la propia instancia. En estas circunstancias, deberá tener cuidado de no almacenar estos datos privados en el sistema de archivos en clúster porque estarían accesibles globalmente.

API de servicio de datos y API de biblioteca de desarrollo de servicios de datos

El sistema Sun Cluster proporciona las siguientes funciones para que las aplicaciones tengan una alta disponibilidad:

• Servicios de datos que se suministran como parte del sistema Sun Cluster

• Una API de servicio de datos

• Una API de biblioteca de desarrollo para los servicios de datos

• Un servicio de datos “genérico”

En Sun Cluster Data Services Planning and Administration Guide for Solaris OS se describe la forma de instalar y configurar los servicios de datos que se suministran con el sistema Sun Cluster. En Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) se describe cómo se gestionan otras aplicaciones para que tengan una alta disponibilidad en la estructura de Sun Cluster.

La API de Sun Cluster permite que los desarrolladores de aplicaciones puedan desarrollar supervisores de fallos y secuencias de comandos para iniciar y detener las instancias de servicios de datos. Con estas herramientas, una aplicación se puede implementar para que funcione como servicio de datos escalable o de recuperación de fallos. El sistema Sun Cluster proporciona un servicio de datos “genérico”. Use este servicio de datos genérico para generar rápidamente los métodos de inicio y detención que requiera una aplicación, así como implementar los servicios de datos como servicios escalables o de recuperación de fallos.

Uso de interconexiones del clúster para el tráfico de servicios de datos

Un clúster debe tener varias conexiones de red entre los nodos que formen la interconexión del clúster. El software Sun Cluster utiliza varias interconexiones para lograr los siguientes objetivos:

• Garantizar una alta disponibilidad

• Mejorar el rendimiento

Para el tráfico interno (como datos de sistema de archivos o datos de servicios escalables), los mensajes se desvían a través de las interconexiones disponibles de forma giratoria. La interconexión del clúster también está disponible para aplicaciones, para comunicaciones de alta disponibilidad entre nodos. Por ejemplo, una aplicación distribuida podría tener componentes que se ejecutaran en distintos nodos y que necesitasen comunicarse. Al usar la interconexión del clúster en lugar del transporte público, éstas conexiones pueden soportar el fallo de un enlace individual.

Para usar la interconexión del clúster para la comunicación entre nodos, una aplicación necesita los nombres de sistema privados configurados cuando se instaló Sun Cluster. Por ejemplo, si el nombre de sistema privado para el nodo 1 es clusternode1-priv, use ese nombre para comunicarse mediante la interconexión del clúster con el nodo 1. Los zócalos TCP abiertos usando este nombre se dirigen por la interconexión del clúster y pueden redirigirse de forma transparente en caso de fallo de la red.

Dado que es posible configurar nombres de sistema privados durante la instalación de Sun Cluster, la interconexión del clúster utiliza cualquier nombre que se elija en ese momento. Para determinar cuál es el nombre real, use el comando scha_cluster_get(3HA) con el argumento scha_privatelink_hostname_node.

Tanto las comunicaciones de las aplicaciones como las comunicaciones internas del clúster se distribuyen a través de las interconexiones. Como las aplicaciones comparten la interconexión del clúster con el tráfico interno de éste, el ancho de banda disponible para las aplicaciones depende del ancho de banda que utilice el resto del tráfico del clúster. Si se produce un fallo, el tráfico interno y el de la aplicación se distribuyen por las interconexiones disponibles.

A cada nodo se le asigna también una dirección por nodo fija. Esta dirección está incluida en el controlador clprivnet. La dirección IP hace referencia al nombre de sistema privado del nodo: clusternode1-priv. Para obtener información acerca del controlador de red privado de Sun Cluster, consulte la página de comando man clprivnet(7).

Si la aplicación requiere direcciones IP coherentes en todos los puntos, configure la aplicación para enlazar a la dirección por nodo tanto en el cliente como en el servidor. Todas las conexiones parece entonces que se originan en la dirección por nodo y que vuelven a ella.

Tipos de recursos, grupos de recursos y recursos

Los servicios de datos usan varios tipos de de recursos: Las aplicaciones como Apache Web Server o Sun Java System Web Server usan direcciones de red (nombres lógicos del sistema y direcciones compartidas) de las que dependen las aplicaciones. Los recursos de aplicación y red forman una unidad básica que gestiona RGM.

Los servicios de datos son tipos de recursos. Por ejemplo, Sun Cluster HA para Oracle es el tipo de recurso SUNW.oracle-server y Sun Cluster HA for Apache es SUNW.apache.

Un recurso es una concreción de tipo de recurso que está definida a nivel del clúster. Se definen varios tipos de recursos.

Los recursos de red pueden ser tipos de recursos SUNW.LogicalHostname o SUNW.SharedAddress. Estos dos tipos de recursos los ha registrado previamente el software Sun Cluster.

Los tipos de recursos HAStorage y HAStoragePlus se utilizan para sincronizar el inicio de los recursos y los grupos de dispositivos de disco de los que dependen los recursos. Estos tipos de recursos garantizan que antes de que se inicie un servicio de datos, estén disponibles las rutas a los puntos de montaje, los dispositivos globales y los nombres de grupos de dispositivos del sistema de archivos del clúster. Para obtener más información, consulte “Synchronizing the Startups Between Resource Groups and Disk Device Groups” en la Data Services Installation and Configuration Guide. El tipo de recurso HAStoragePlus comenzó a estar disponible en Sun Cluster 3.0 5/02 y se le ha agregado otra función que hace que los sistemas de archivos locales tengan una alta disponibilidad. Para obtener más información acerca de esta función, consulte Tipo de recurso de HAStoragePlus .

Los recursos administrados mediante RGM se ubican en grupos llamados grupos de recursos, por lo que se pueden administrar como si fueran una unidad. El grupo de recursos migra como unidad si se inicia una recuperación de fallos o un cambio.

Cuando se pone en línea un grupo de recursos que contiene recursos de aplicación, se inicia la aplicación en cuestión. El método de inicio del servicio de datos espera a que la aplicación esté funcionando para cerrarse correctamente. Determinar cuándo la aplicación está completamente en marcha sigue el mismo proceso que el supervisor de fallos utiliza para saber que un servicio de datos está ofreciendo servicio a clientes. Consulte la Sun Cluster Data Services Planning and Administration Guide for Solaris OS para obtener más información sobre el proceso.

Gestor de grupos de recursos (RGM)

RGM controla los servicios de datos (aplicaciones) como recursos, que las implementaciones de tipos de recursos gestionan. Éstas las proporciona Sun o las crea un desarrollador con una plantilla genérica de servicios de datos, una API de la biblioteca de desarrollo de servicios de datos (API DSDL) o con una API de gestión de recursos (RMAPI). El administrador del clúster crea y gestiona los recursos en contenedores que reciben el nombre de grupos de recursos. RGM para e inicia los grupos de recursos en nodos seleccionados como respuesta a cambios en la pertenencia al clúster.

RGM actúa en recursos y grupos de recursos. Las acciones de RGM provocan que los recursos y los grupos de recursos pasen de estar en línea a estar fuera de línea. Encontrará una descripción completa de los estados y las configuraciones se pueden aplicar a los recursos y a los grupos de recursos en la sección Configuraciones y estados de los recursos y los grupos de recursos .

Consulte Configuración de un proyecto de servicio de datos para obtener información acerca de cómo iniciar proyectos de Solaris bajo el control de RGM.

Configuraciones y estados de los recursos y los grupos de recursos

Los administradores aplican a recursos y grupos de recursos configuraciones estáticas que sólo pueden cambiarse con acciones administrativas. RGM asigna a los recursos “estados” dinámicos. Estos valores y estados se describen en la lista siguiente.

• Gestionados o no gestionados: son valores que afectan a todo el clúster y sólo se aplican a grupos de recursos. RGM gestiona los grupos de recursos. El comando scrgadm(1M) se puede usar para que RGM gestione o deje de gestionar un grupo de recursos. Estos valores no cambian con la reconfiguración del clúster.

  Cuando se crea un grupo de recursos por primera vez, no se gestiona. Un grupo de recursos debe estar administrado antes de activar los recursos colocados en el grupo.

  En algunos servicios de datos, por ejemplo, un servidor Web escalable, el trabajo se debe hacer antes de iniciar los recursos de red y después de detenerlos. Este trabajo se hace con los métodos de servicio de datos de inicialización (INIT) y finalización (FINI). Los métodos INIT sólo se ejecutan si el grupo de recursos en el que éstos residen está en estado gestionable.

  Cuando un grupo de recursos cambia de no gestionado a gestionado, los métodos INIT registrados para el grupo se ejecutan en todos los recursos.

  Cuando un grupo de recursos cambia de gestionado a no gestionado, todos los métodos FINI registrados se ejecutan para realizar una limpieza.

  Los métodos INIT y FINI se utilizan habitualmente para los recursos de red para servicios escalables. Sin embargo, estos métodos se pueden utilizar para cualquier tarea de inicio o de limpieza que no ejecute la aplicación.

• Habilitados o inhabilitados: son los valores a nivel del clúster que se aplican a los recursos. El comando scrgadm(1M) se puede usar para habilitar o inhabilitar los recursos. Estos valores no cambian con la reconfiguración del clúster.

  El valor normal para un recurso es que esté habilitado y funcionando activamente en el sistema.

  Si desea que un recurso no esté disponible en ningún nodo del clúster, deshabilite el recurso. De esta manera dejará de estar disponible para uso general.

• En línea o fuera de línea: son estados dinámicos y se aplican a recursos y grupos de recursos.

  El estado cambia de en línea a fuera de línea a medida que el clúster avanza por los distintos pasos de reconfiguración durante los procesos de recuperación de fallos o conmutación por fallos. El estado también puede cambiar mediante las acciones administrativas. Use el comando scswitch(1M) para cambiar del estado en línea al estado fuera de línea de un recurso o grupo de recursos.

  Un recurso o un grupo de recursos a prueba de fallos sólo pueden estar en línea en un nodo simultáneamente. Un recurso o un grupo de recursos escalables pueden estar en línea en algunos nodos y fuera de línea en otros. Durante una conmutación o una recuperación de fallos, los grupos de recursos y los recursos que contienen se ponen en fuera de línea en un nodo y después se vuelven a poner en línea en otro distinto.

  Si un grupo de recursos está fuera de línea, entonces todos sus recursos estarán también fuera de línea. Si un grupo de recursos está en línea, entonces todos sus recursos habilitados estarán también en línea.

  Los grupos de recursos pueden contener varios recursos, pudiendo haber dependencias entre ellos que requieren que los recursos se pongan en línea y fuera de línea en un orden determinado. Los métodos usados para poner los recursos en línea y fuera de línea pueden ocupar tiempos distintos en cada uno de ellos. Debido a las dependencias de recursos y a las diferencias de tiempo de inicio y finalización, los recursos de un mismo grupo de recursos pueden tener estados de puesta en línea y fuera de línea distintos durante una reconfiguración del clúster.

Propiedades de los recursos y los grupos de recursos

Puede configurar valores de propiedades para los recursos y los grupos de recursos de sus servicios de datos de Sun Cluster. Las propiedades estándar son comunes a todos los servicios de datos. Las propiedades de extensión son específicas de cada servicio de datos. Algunas propiedades estándar y de extensión se configuran con valores predeterminados para que no se tengan que modificar. Otras necesitan configurarse como parte del proceso de creación y configuración de recursos. La documentación de cada servicio de datos especifica qué propiedades de recurso pueden establecerse y cómo hacerlo.

Las propiedades estándar se usan para configurar propiedades de recursos y grupos de recursos que normalmente son independientes de todos los servicios de datos. Para conocer el conjunto de propiedades estándar, consulte el Apéndice A, Standard Properties de Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Las propiedades de extensión de RGM ofrecen información como la ubicación de los binarios de la aplicación y los archivos de configuración. Las propiedades de extensión se modifican a medida que se configuran los servicios de datos. El conjunto de propiedades de extensión se describe en la guía específica para servicios de datos.

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.

Adaptadores de red públicos y Ruta múltiple de red de protocolo de Internet (IP)

Los clientes hacen peticiones de datos al clúster a través de la red pública. Cada nodo del clúster está conectado como mínimo a una red pública a través de un par de adaptadores.

El software de ruta múltiple de red de protocolo de Internet (IP) de Solaris en Sun Cluster proporciona el mecanismo básico para supervisar los adaptadores de red públicos y realizar la recuperación de fallos en direcciones IP desde un adaptador a otro cuando se produce un fallo. Todos los nodos del clúster tienen su propia configuración de Ruta múltiple de red de protocolo de Internet (IP), que puede ser distinta de la configuración de otros nodos del clúster.

Los adaptadores de red públicos están organizados en grupos de ruta IP múltiple (grupos de ruta múltiple). Cada grupo de ruta múltiple tiene uno o más adaptadores de red pública. Cada adaptador de un grupo de ruta múltiple puede estar activo. Alternativamente, puede configurar interfaces de modo de espera que estén inactivas hasta que se produzca una recuperación de fallos.

El daemon de ruta múltiple in.mpathd usa una dirección IP de prueba para detectar los fallos y realizar las reparaciones. si detecta un fallo en uno de los adaptadores, se produce una recuperación de fallos. Un acceso de red se recupera del fallo desde el adaptador que ha fallado a otro adaptador funcional en el grupo de ruta múltiple. En consecuencia, el daemon mantiene la conectividad de red pública para el nodo. Si configuró una interfaz de modo de espera, el daemon eligirá dicha interfaz. De lo contrario, el daemon eligirá la interfaz con el menor número de direcciones IP. Dado que la recuperación de fallos se produce en el nivel de interfaz del adaptador, las conexiones de un nivel superior, como las TCP, no se ven afectadas, excepto por un breve retraso durante la recuperación de fallos. Cuando la recuperación de fallos de las direcciones IP se completa correctamente, se envían las difusiones ARP. En consecuencia, el daemon mantiene la conectividad con los clientes remotos.

Debido a la función de recuperación del colapso de TCP, los puntos finales TCP pueden experimentar otros retrasos después de que la recuperación del fallo haya sido correcta. Puede que algunos segmentos se hayan perdido durante la recuperación de fallos, lo que activaría el mecanismo de control de colapsos en TCP.

Los grupos de ruta múltiple ofrecen bloques de construcción para nombres de sistema lógicos y recursos de dirección compartida. También se pueden crear grupos de ruta múltiple independientemente de los nombres de sistema lógicos y los recursos de dirección compartida para supervisar la conectividad de red pública de los nodos del clúster. El mismo grupo de ruta múltiple de un nodo puede alojar cualquier número de nombres de sistema lógicos o recursos de dirección compartida. Si desea obtener más información sobre sistemas lógicos y recursos de direcciones compartidos, consulte la Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

El diseño del mecanismo de Ruta múltiple de red de protocolo de Internet (IP) está enfocado a detectar y solucionar fallos del adaptador. Su diseño no está pensado para recuperarse tras el uso del comando ifconfig(1M) por parte de un administrador para eliminar una de las direcciones IP lógicas o compartidas. El software Sun Cluster considera las direcciones IP compartidas y lógicas como recursos administrados por RGM. El modo correcto para que un administrador agregue o elimine una dirección IP es usar el comando scrgadm(1M) para modificar el grupo de recursos que contiene el recurso.

Para obtener más información acerca de la implementación de Solaris de varias rutas de red IP, consulte la documentación pertinente del sistema operativo Solaris que esté instalado en su clúster.

SPARC: Compatibilidad con la reconfiguración dinámica

El soporte de Sun Cluster 3.1 8/05 para la función de software de reconfiguración dinámica (DR) se está desarrollando en fases incrementales. Este apartado describe los conceptos y consideraciones para el soporte de Sun Cluster 3.1 8/05 de la función DR.

Todos los requisitos, las restricciones y los procedimientos que están documentados para la función DR de Solaris se aplican también al soporte de DR de Sun Cluster (excepto por la operación de quiescencia del entorno operativo). En consecuencia, revise la documentación de la función DR de Solaris antes de usar dicha función con el software Sun Cluster. Debe prestar especial atención a los problemas que afectan a los dispositivos de E/S que no están en red durante una operación de desacople de DR.

Los manuales Sun Enterprise 10000 Dynamic Reconfiguration User Guide y Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual (de las colecciones Solaris 8 on Sun Hardware o Solaris 9 on Sun Hardware) están disponibles para descargarlos de http://docs.sun.com.

SPARC: Descripción general de la reconfiguración dinámica

La función DR habilita operaciones tales como la extracción de hardware del sistema en sistemas que estén en ejecución. Los procesos DR están diseñados para asegurar el funcionamiento continuo del sistema sin necesidad de pararlo o interrumpir la disponibilidad del clúster.

DR funciona a nivel de placa, Por lo tanto, la operación DR afecta a todos los componentes de la placa. Cada placa puede contener varios componentes, como CPU, memorias e interfaces periféricas para unidades de disco, unidades de cinta y conexiones en red.

La extracción de una placa que contenga componentes activos podría provocar errores en el sistema. Antes de extraer una placa, el subsistema DR consulta otros subsistemas, como Sun Cluster, para determinar si los componentes de la placa se están utilizando. Si el subsistema DR encuentra que la placa se está usando, la operación de extraer la placa por DR no se lleva a cabo. Por lo tanto, siempre es más seguro llevar a cabo una operación de extracción de placa por DR porque el subsistema DR rechaza operaciones en las placas que contienen componentes activos.

La operación de adición de la placa DR también es siempre segura. El sistema pone en funcionamiento automáticamente las CPU y la memoria de una placa recién añadida. Sin embargo, el administrador del sistema deberá configurar manualmente el clúster para que use de forma activa componentes que estén en la placa recién agregada.

El subsistema DR tiene varios niveles. Si un nivel inferior informa de un error, el superior también informa del mismo error. No obstante, cuando el nivel inferior informa sobre un error específico, el nivel superior indica que se ha producido un error desconocido. Este error se puede omitir sin problema.

Los apartados siguientes describen consideraciones de DR para los distintos tipos de dispositivos.

SPARC: Consideraciones de clúster DR para los dispositivos CPU

El software Sun Cluster no rechaza una operación de extracción de placa por DR debido a la presencia de los dispositivos CPU.

Cuando una operación de añadir placa con DR tenga éxito, los dispositivos de CPU de la placa añadida se incorporarán automáticamente al funcionamiento del sistema.

SPARC: Consideraciones de clúster DR para la memoria

Para los propósitos de DR, se deben considerar dos tipos de memoria.

• paquete de memoria del núcleo

• paquete de memoria que no es del núcleo

que difieren sólo en su uso. El hardware real es el mismo para ambos tipos. El paquete de memoria del núcleo es la memoria utilizada por el sistema operativo Solaris. El software Sun Cluster no admite las operaciones de extracción de placas que contengan paquetes de memoria del núcleo y rechaza las operaciones de este tipo. Cuando una operación de extracción de placa por DR pertenece a una memoria distinta de la del paquete del núcleo, el software Sun Cluster no rechaza la operación. Cuando una operación de añadir placa con DR que pertenezca a memoria tenga éxito, la memoria de la placa añadida se incorporará automáticamente al funcionamiento del sistema.

SPARC: Consideraciones de clúster DR para unidades de disco y cinta

Sun Cluster rechaza las operaciones DR de extraer-placa en las unidades activas del nodo principal. Las operaciones de extracción de placa por DR se pueden llevar a cabo en unidades inactivas en el nodo primario o en cualquier unidad del nodo secundario. Después de la operación de DR, el acceso a los datos del clúster prosigue de la misma forma.

Sun Cluster rechaza las operaciones DR que afecten a la disponibilidad de los dispositivos del quórum. Para ver las consideraciones acerca de los dispositivos del quórum y los procedimientos para realizar operaciones de DR en ellas, consulte SPARC: Consideraciones de clúster DR para los dispositivos del quórum .

Consulte Reconfiguración dinámica con los dispositivos del quórum de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener instrucciones detalladas acerca de cómo llevar a cabo estas acciones.

SPARC: Consideraciones de clúster DR para los dispositivos del quórum

Si la operación de extracción de placa por DR pertenece a una placa que contenga una interfaz para un dispositivo configurado para el quórum, el software Sun Cluster rechazará la operación. El software Sun Cluster también identifica el dispositivo del quórum que se vería afectado por la operación. Es necesario inhabilitar el dispositivo como del quórum antes de poder efectuar una operación de extracción de placa con DR.

Consulte el Capítulo 5, Administración del quórum de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener instrucciones detalladas acerca de la forma de administrar el quórum.

SPARC: Consideraciones de clúster DR para las interfaces interconectadas del clúster

Si la operación de extracción de la placa por DR pertenece a una placa que contiene una interfaz de interconexión del clúster activa, el software Sun Cluster rechaza la operación. El software Sun Cluster también identifica la interfaz que se vería afectada por la operación. Debe usar una herramienta administrativa de Sun Cluster para deshabilitar la interfaz activa para que la operación de DR tenga éxito.

El software Sun Cluster requiere que cada nodo del clúster tenga como mínimo una ruta operativa para los demás nodos del clúster. No inhabilite una interfaz de interconexión privada en el caso de que represente la ultima ruta a cualquiera de los nodos del clúster.

Consulte Administración de las interconexiones del clúster de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener instrucciones detalladas acerca de cómo realizar estas acciones.

SPARC: Consideraciones de clúster DR para las interfaces de red públicas

Si la operación de extracción de la placa por DR pertenece a una placa que contenga una interfaz de red pública activa, el software Sun Cluster rechazará la operación. El software Sun Cluster también identifica la interfaz que se vería afectada por la operación. Antes de eliminar una placa que tenga una interfaz de red presente, conmute todo el tráfico de dicha interfaz a otra interfaz funcional del grupo con varias rutas usando el comando if_mpadm(1M).

Si el resto de adaptadores de red fallan mientras se está efectuando una supresión de DR en el adaptador de red inhabilitado, la disponibilidad se verá afectada. El adaptador restante no tiene a quién transferir el control durante la operación de DR.

Consulte Administración de la red pública de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener instrucciones detalladas acerca de cómo realizar una operación de extracción por DR en una interfaz de red pública.