Capítulo 3 Conceptos clave de la administración y desarrollo de las aplicaciones

Este capítulo describe los conceptos clave relacionados con los componentes de hardware de una configuración de sistema de SunPlex. Se tratan los siguientes temas:

• Interfaces administrativas

• Hora del clúster

• Estructura de alta disponibilidad (HA)

• Dispositivos globales

• Grupos de dispositivos de discos

• Espacio de nombres global

• Sistemas de archivos del clúster

• Quórum y dispositivos del quórum

• Servicios de datos

• Desarrollo de nuevos servicios de datos

• Recursos, grupos de recursos y tipos de recursos

• Adaptadores de red pública y Ruta múltiple de red IP

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

Administración del clúster y desarrollo de aplicaciones

Esta información va dirigida principalmente a administradores del sistema y desarrolladores de aplicaciones que utilicen API y SDK de SunPlex. Asimismo, a los administradores del sistema del clúster esta información les puede resultar útil 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

Se puede elegir como instalar, configurar y administrar el sistema SunPlex 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. Además de la interfaz de la línea de órdenes hay utilidades, como scinstall y scsetup, que simplifican la instalación seleccionada y las tareas de configuración. El sistema SunPlex 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 el capítulo de introducción de Sun Cluster System Administration Guide 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 SunPlex emplea 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) (interactivamente o desde secuencias cron) en un clúster activo, puede forzar un cambio de hora mucho mayor que el de una fracción de segundo para sincronizar el reloj del sistema con el origen de la hora, lo que podría causar problemas con la marca de hora de modificación de archivos o confundir al servicio NTP.

Cuando se instala el sistema operativo Solaris en todos los nodos del clúster, se tiene la oportunidad de cambiar la fecha y hora predeterminadas para el nodo. En general, puede aceptar el valor predeterminado sugerido.

Cuando se instala el software de Sun Cluster mediante scinstall(1M), uno de los pasos del proceso es configurar NTP para el clúster. El software de Sun Cluster incluye un archivo de plantilla, ntp.cluster (consulte /etc/inet/ntp.cluster en un nodo del clúster instalado), que establece una relación de paridad entre todos los nodos del clúster, de los cuales uno de ellos es el “preferido”. Los nodos se identifican por su nombre de sistema privado y la sincronización de la hora se produce entre la interconexión del clúster. Las instrucciones sobre cómo configurar el clúster para NTP se incluyen en Sun Cluster Software Installation Guide.

También se puede establecer uno o más servidores NTP fuera del clúster y cambiar el archivo ntp.conf para que refleje la nueva configuración.

Durante el funcionamiento normal, nunca debería ser necesario ajustar la hora en el clúster. Ahora bien, si la hora se estableció incorrectamente al instalar el sistema operativo Solaris y desea cambiarla, puede consultar el procedimiento para hacerlo en Sun Cluster System Administration Guide.

Estructura de alta disponibilidad (HA)

El sistema SunPlex hace que todos los componentes de la “ruta de acceso” entre usuarios y datos esté muy disponible, incluyendo las interfaces de red, las aplicaciones en sí, el sistema de archivos y los discos 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 tabla siguiente muestra los tipos de fallos de componentes de SunPlex (tanto de hardware como de software) y los tipos de recuperación que incorpora la estructura de alta disponibilidad.

La estructura de alta disponibilidad del software de Sun Cluster detecta el fallo en un nodo rápidamente y crea un servidor equivalente nuevo para los recursos de la estructura en uno de los nodos restantes del clúster. En ningún momento se interrumpe completamente la disponibilidad de los recursos de la estructura. Los que no se hayan visto afectados por el nodo que haya fallado están completamente 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) usando el recurso. Las semánticas del acceso a los recursos de la estructura se conservan perfectamente entre los fallos de los nodos. Las aplicaciones simplemente no pueden advertir que el servidor del recurso de la estructura se ha trasladado a otro nodo. El fallo de un único nodo es completamente transparente para los programas desde el resto de los nodos que usan archivos, dispositivos y volúmenes de disco conectados a este nodo, siempre que exista una ruta de acceso alternativa de hardware a los discos desde otro nodo. Un ejemplo es el uso de discos multisistema que tengan puertos con varios nodos.

Supervisor de pertenencia al clúster

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.

Después de detectar un cambio en la composición del clúster, CMM lleva a cabo una configuración sincronizada del clúster en que los recursos de éste podrían redistribuirse de acuerdo con la nueva composición.

A diferencia de anteriores versiones del software Sun Cluster, CMM se ejecuta completamente en el núcleo.

Consulte Quórum y dispositivos del quórum para obtener información sobre cómo el clúster se protege de una partición en varios clústers independientes.

Mecanismo de recuperación rápida

Si el CMM detecta un problema grave en un nodo, envía una señal a la estructura del clúster para forzar un apagado (aviso grave) del nodo y borrarlo de la pertenencia al clúster. El mecanismo por el que ello ocurre se denomina recuperación rápida. Éste obliga a un nodo a apagarse de dos formas.

• Si un nodo abandona el clúster y después intenta crear uno nuevo sin tener quórum, queda “aislado” y se le impide acceder a discos compartidos. Consulte Aislamiento de fallos para obtener detalles sobre este uso de la recuperación rápida.

• Si uno o más daemons específicos del clúster dejan de existir (clexecd , rpc.pmfd, rgmd o rpc.ed) el CMM detecta el fallo y el nodo emite un aviso grave. Cuando la finalización de un daemon del clúster hace que un nodo emita un aviso grave, en la consola de éste aparecerá un mensaje parecido a éste.

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 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 establecer auto-boot? con eeprom(1M), en el indicador ok de la PROM de OpenBoot.

Depósito de configuración del clúster (CCR)

CCR usa un algoritmo de puesta al día de dos fases para las actualizaciones: una actualización se tiene que completar satisfactoriamente en todos los miembros del clúster o de lo contrario se anula. 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 SunPlex usa dispositivos globales para ofrecer a todo el clúster un acceso de alta disponibilidad a cualquier dispositivo del clúster, desde cualquier nodo sin que importe dónde esté la conexión física del dispositivo. En general, si un nodo falla mientras se ofrece acceso a un dispositivo global, el software de Sun Cluster descubre automáticamente otra ruta de acceso al dispositivo y redirige el acceso a la misma. Los dispositivos globales de SunPlex pueden ser discos, CD-ROM y cintas. Sin embargo, los discos son los únicos dispositivos globales multipuerto que se admiten. Ello significa que los CD-ROM y los dispositivos de cinta actualmente no son 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 exclusivas 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. Para obtener más información, véase Espacio de nombres global.

Los dispositivos globales multipuerto ofrecen más de una ruta de acceso al dispositivo. En el caso de discos multisistema, debido a que forman parte de un grupo de dispositivos de disco alojado por más de un nodo, eso los convierte en discos de alta disponibilidad.

ID de dispositivo (DID)

El software de Sun Cluster gestiona los dispositivos globales a través de una construcción conocida como el pseudocontrolador de ID de 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.

El pseudocontrolador de ID de dispositivo (DID) forma parte integral de la prestación de acceso global a los dispositivos del clúster. El controlador de DID examina todos los nodos del clúster y crea una lista de dispositivos de disco única, asignándole a cada uno un número mayor y menor exclusivos que es idéntico en todos los nodos del clúster. El acceso a los dispositivos globales se realiza usando el ID de dispositivo único asignado por el controlador DID en lugar de los ID de dispositivos de Solaris tradicionales, como c0t0d0 para un disco.

Este enfoque fuerza a que todas las aplicaciones que acceden a discos (como un gestor de volúmenes o aplicaciones que usen dispositivos a bajo nivel) utilicen una ruta de acceso uniforme en todo el 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 nodo1 podría ver un disco multisistema como c1t2d0 y el nodo2 podría ver ese mismo disco de forma completamente distinta, como c3t2d0. El controlador DID asigna un nombre global, como d10, que los nodos deben usar en su lugar, dando a cada nodo una correlación uniforme con el disco multisistema..

Los ID de dispositivo se administran con las órdenes scdidadm(1M) y scgdevs(1M). Consulte las páginas de comando man respectivas para obtener mas información.

Grupos de dispositivos de discos

En el sistema SunPlex, todos los discos multisistema deben estar bajo el control del software de Sun Cluster. En primer lugar en los discos multisistema se crean grupos de discos del gestor de volúmenes (bien conjuntos de discos de Solaris Volume Manager bien grupos de discos de VERITAS Volume Manager, sólo disponibles para usar en clústers basados en plataformas SPARC). 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.

El registro proporciona a SunPlex información del sistema sobre los nodos y sus rutas de acceso a grupos de disco 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. Estos grupos pueden usarse para alojar sistemas de archivos del clúster.

Los grupos de dispositivos de disco son independientes de los grupos de recursos. Un nodo puede controlar un grupo de recursos (que represente un grupo de procesos de servicio de datos) mientras otro puede controlar los grupos de discos a los que están accediendo los servicios de datos. Sin embargo, la mejor práctica es mantener en el mismo nodo el grupo de dispositivos de disco que almacena los datos de una aplicación determinada y el grupo que contiene sus recursos (el daemon de la aplicación). Consulte el capítulo de resumen de Sun Cluster Data Services Planning and Administration Guide para obtener más información sobre la asociación entre grupos de dispositivos de disco y grupos de recursos.

Con un grupo de dispositivos de discos, el grupo de discos del gestor de volúmenes se convierte en “global” ya que es compatible con 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 del grupo 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 Recuperación de fallos en grupos de dispositivos de disco

Grupos de dispositivos de disco multipuerto

Este apartado describe las propiedades del grupo de dispositivo de disco que permiten equilibrar el rendimiento y la disponibilidad en una configuración de disco multipuerto. El software Cluster proporciona dos propiedades que se usan para ajustar una configuración de disco multipuerto: preferenced y numsecondaries. Con la propiedad preferenced se puede controlar el orden en el que los nodos intentan asumir el control cuando se produce una recuperación de fallo. La propiedad numsecondaries se utiliza para establecer un número deseado de nodos secundarios para un grupo de dispositivos.

Un servicio de alta disponibilidad se considera caído cuando el nodo primario cae y no hay otros secundarios que puedan promocionar a los primarios. Si se produce la recuperación de fallos y la propiedad preferenced es true, los nodos siguen el orden de la lista para que se seleccione un secundario. La lista de nodos configurada define el orden en que que éstos intentarán asumir el control primario o transicionar de redundante a secundario. Puede cambiar dinámicamente la preferencia de un servicio de dispositivo mediante la utilidad scsetup(1M). La preferencia que está asociada con proveedores de servicio dependientes, por ejemplo un sistema de archivos global, será la del servicio del 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. El soporte para nodos redundantes se ha implementado para minimizar la degradación en el rendimiento y la sobrecarga de memoria que produce el proceso de comprobación. De forma predeterminada el grupo de dispositivos de disco tendrá uno primario y uno secundario. El resto de nodos de proveedor disponibles estarán en línea en el estado redundante. Si se produce una recuperación de fallos, el secundario se convertirá en el primario y el nodo con más prioridad de la lista se convertirá en el secundario.

El número de nodos secundarios que se desee se puede establecer en cualquier número entero entre uno y el número de nodos proveedores no primarios operativos del grupo de dispositivos.

Si se está utilizando Solaris Volume Manager, se debe crear el grupo de dispositivos de disco antes de establecer la propiedad numsecondaries a 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 mantiene la estructura de réplica es la deseada, a menos que el número de proveedores no primarios en funcionamiento sea inferior al deseado. Si está añadiendo o quitando nodos de la configuración, deberá hacer cambios en la propiedad numsecondaries y revisar bien la lista de nodos. Si se mantiene ésta y el número deseado de secundarios se evitarán conflictos entre el número de secundarios configurado y el número real permitido por la estructura. Utilice la orden metaset(1M) para los grupos de dispositivos de Solaris Volume Manager o, si utiliza Veritas Volume Manager, la orden scconf(1M) para los grupos de dispositivos de discos VxVM junto con las propiedades preferenced y numsecondaries para gestionar la adición y supresión de los nodos de la configuración. Consulte “Administering Cluster File Systems Overview” in Sun Cluster System Administration Guide for Solaris OS con el fin de obtener información sobre los procedimientos para cambiar las propiedades de los grupos de dispositivos de discos.

Espacio de nombres global

El mecanismo de software de Sun Cluster que habilita los dispositivos globales es el espacio de nombres global que 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. Todos los nodos conectados físicamente a discos multisistema incluyen una ruta de acceso al almacenamiento válida para todos los nodos del clúster.

En general, los espacios de nombres del gestor de volúmenes se encuentran en los directorios /dev/md/conjunto_discos/dsk (y rdsk), para Solaris Volume Manager, y en los directorios /dev/vx/dsk/grupo_discos y /dev/vx/rdsk/grupo_discos, para Veritas VxVM. Estos espacios de nombres se componen de directorios para cada conjunto de discos del Solaris Volume Manager y cada grupo de discos de VxVM importados a través del clúster, respectivamente, cada uno de los cuales aloja un nodo de dispositivo para cada metadispositivo o volumen de ese conjunto o grupo de discos.

En el sistema SunPlex todos los nodos de dispositivos del espacio de nombres del gestor de volúmenes local se sustituye 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 de Sun Cluster sigue presentando los dispositivos del gestor de volúmenes, como enlaces simbólicos, 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 del espacio de nombres global, se cuentan:

• 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 espacios de nombres locales y globales

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 del 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 situado en cualquier parte del sistema y los procesos de todos los nodos pueden usar el mismo nombre de ruta para situar 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 la funcionalidad de bloqueo de archivos a través de las interfaces fcntl(2). La aplicaciones que se ejecutan en varios nodos del clúster pueden sincronizar el acceso a las datos mediante el bloqueo del archivo de consulta 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 mientras siga 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 los archivos del sistema de archivos del clúster desde cualquier nodo de éste empleando el 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. Es decir, los clientes ven el sistema de archivos subyacente (por ejemplo, UFS).

Uso de los sistemas de archivos del clúster

En el sistema SunPlex todos los discos multisistema se sitúan en grupos de dispositivos de disco que pueden ser conjuntos de discos del Solaris Volume Manager, 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.

Al igual que ocurre con los sistemas de archivo locales, los sistemas de archivo clúster se pueden montar de dos formas:

• Manualmente: con la orden mount y las opciones de montaje -g u -o global para montar el sistema de archivos del clúster desde la línea de órdenes, por ejemplo:

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

• Automáticamente: creando una entrada en el archivo /etc/vfstab con una opción de montaje global para montar el sistema de archivos del clúster desde el arranque. Después puede crear un punto de montaje en el directorio /global de todos los nodos. Éste es una ubicación recomendada, no un requisito. La siguiente es una línea de ejemplo para un sistema de archivos del clúster del archivo /etc/vfstab:

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

Aunque el software de Sun Cluster no impone ninguna política de asignación de nombres a los sistemas de archivos del clúster, puede facilitarse la administración creando un punto de montaje para todos los sistemas de archivos del clúster en el mismo directorio, como /global/grupo-dispositivo-disco. Para obtener mas información, consulte Sun Cluster Software Installation Guide y Sun Cluster System Administration Guide.

Tipo de recurso HAStoragePlus

El tipo de recurso HAStoragePlus está diseñado para convertir en altamente disponibles configuraciones de sistemas de archivos no globales como UFS y VxFS, permite integrar el sistema de archivos local en el entorno Sun Cluster, convertir aquél en altamente disponible y proporcionar prestaciones del sistema de archivos adicionales, como comprobaciones, montajes y desmontajes forzados que permiten a Sun Cluster recuperarse pasando a 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 los capítulos de servicios de datos individuales en Data Services Installation and Configuration Guide o el capítulo 14 “Enabling Highly Available Local File Systems” de “Administering Data Services Resources” para obtener información sobre cómo usar el tipo de recurso HAStoragePlus.

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

Opción de montaje syncdir

La opción de montaje syncdir puede utilizarse en sistemas de archivos del clúster que usen UFS como sistema de archivo subyacente. Sin embargo, existe una mejora de rendimiento significativa si no se especifica syncdir. Si se especifica syncdir, se garantiza que las escrituras sean compatibles con POSIX. Si no se especifica, tendrá el mismo comportamiento que se ve con sistemas de archivos NFS. Por ejemplo, en algunos casos sin syncdir, no se descubriría una condición de falta de espacio hasta que se cerrara el archivo. Con syncdir (y el comportamiento POSIX), la condición de falta de espacio se descubriría durante la operación de escritura. La posibilidad de tener problemas si no se especifica syncdir es remota, por ello es recomendable no especificarla ya que así se mejora el rendimiento.

Si usa un clúster basado en la plataforma SPARC, Veritas VxFS no tiene una opción de montaje equivalente a 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 sistemas de archivos para obtener preguntas frecuentes sobre los dispositivos globales y los sistemas de archivos del clúster.

Supervisión de las rutas de disco

La versión actual del software Sun Cluster admite la supervisión de las rutas del disco (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 Sun Cluster System Administration Guide for Solaris OS para obtener información de los procedimientos para supervisar, dejar de supervisar y comprobar el estado de las rutas del disco.

DPM no se admite en nodos que ejecuten versiones anteriores al software de Sun Cluster 3.1 4/04. 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.

Visión general

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 la orden scdpm para verificar la disponibilidad de la ruta del disco que utiliza un recurso antes de conmutarlo. Las opciones que se incluyen con la orden scdpm permiten supervisar las rutas de acceso a discos hacia un nodo individual o hacia todos los nodos del clúster. Consulte la página de comando man scdpm(1M) para obtener más información sobre las opciones de la línea de órdenes.

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

En cada nodo se ejecuta un daemon DPM (scdpmd) de subproceso múltiple que lo inicia la secuencia rc.d cuando arrancan los nodos. 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 recoge información de rutas del disco y nombres de nodo del archivo de estado anterior o de la base de datos CCR. Para obtener más información sobre CCR, consulte Depósito de configuración del clúster (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 DPM envía una notificación a Sun Cluster Event Framework y registra el estado nuevo de la ruta a través del mecanismo UNIX syslogd(1M).

Todos los errores relacionados con el daemon se tratan en pmfd(1M). 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 es visible a través de controladores de ruta múltiple como MPxIO, 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 la orden scdpm. Utilice esta orden para supervisar, dejar de supervisar o mostrar el estado de las rutas del disco del clúster; también resulta útil para imprimir la lista de discos fallidos y supervisar rutas de los discos a partir de 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 que 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 “Administering Sun Cluster With the Graphical User Interfaces” in Sun Cluster System Administration Guide for Solaris OS para obtener información acerca de SunPlex Manager.

Uso de la orden scdpm para supervisar las rutas del disco

La orden scdpm(1M) proporciona a DPM órdenes 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 primer nodo no es necesario y, en caso de no especificarlo, toma el valor all. 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 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

• Visualizar el estado de todas las rutas del disco del 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

Debido a que los nodos del clúster comparten datos y recursos, es importante no dividir nunca un clúster en particiones distintas que estén activas al mismo tiempo. CMM garantiza que como máximo haya un solo clúster en marcha en todo momento, incluso aunque la interconexión del clúster esté particionada.

Hay dos tipos de problemas que surgen a partir de las particiones de los clústers: esquizofrenia y amnesia. La esquizofrenia se produce cuando se pierde la interconexión del clúster entre los nodos y éste se particiona en subclústers, cada uno de los cuales cree que es la única partición. Es una consecuencia de problemas de comunicación entre los nodos del clúster. La amnesia se produce cuando el clúster se reinicia después de un apagado teniendo datos del clúster más antiguos que los del momento del apagado. Esto puede ocurrir si hay varias versiones de los datos de la estructura almacenadas en disco y se inicia una nueva copia del clúster cuando la más reciente no está disponible.

La esquizofrenia y la amnesia se pueden evitar dando a cada nodo un voto y obligando a que haya una mayoría de votos por clúster en funcionamiento. Una partición con la mayoría de votos tiene quórum y se le permite funcionar. Este mecanismo de votación mayoritaria funciona bien mientras haya más de dos nodos por clúster. En un clúster de dos nodos, la mayoría es dos. Si ese tipo de clúster resulta particionado es necesario un voto externo para que alguna de las dos particiones obtenga el quórum. Este voto externo lo proporciona un dispositivo del quórum que puede ser cualquier disco que compartan dos nodos. Los discos usados como dispositivos del quórum pueden contener datos de usuario.

El algoritmo de quórum funciona dinámicamente: a medida que los eventos del clúster accionan cálculos, los resultados de éstos pueden cambiar durante la vida del clúster.

Recuentos de votos del quórum

Los nodos del clúster y los dispositivos del quórum votan para formar el quórum. De forma predeterminada los nodos del clúster aumentan en uno su recuento de votos del quórum cuando arrancan y se convierten en miembros del clúster. Los nodos también pueden tener un recuento de votos de cero, por ejemplo cuando el nodo se está instalando o cuando un administrador lo ha situado en estado de mantenimiento.

Los dispositivos del quórum adquieren votos según el número de conexiones de nodo que tenga el dispositivo. Cuando se configura un dispositivo del quórum, éste adquiere un recuento máximo 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).

Los dispositivos del quórum se configuran durante la instalación del clúster o más adelante mediante los procedimientos que se describen en Sun Cluster System Administration Guide.

Los dispositivos del quórum sólo contribuyen al recuento de votos si al menos uno de los nodos al que está conectado es un miembro del clúster. Además, durante el arranque del clúster un dispositivo del quórum contribuye al recuento sólo si, al menos, uno de los nodos a los que está conectado en ese momento está arrancando y era miembro del clúster que ha arrancado más recientemente.

Configuraciones del quórum

Las configuraciones del quórum dependen del número de nodos del clúster:

• Clústers de dos nodos: para que se forme un clúster de dos nodos hacen falta dos votos de quórum que pueden provenir de los dos nodos del clúster o de un nodo y un dispositivo del quórum. Sin embargo, es necesario configurar un dispositivo del quórum en clústers de dos nodos para asegurarse que uno de ellos pueda continuar si el otro falla.

• Clústers de más de dos nodos: se debe especificar un dispositivo del quórum entre todos los pares de nodos que compartan acceso al alojamiento del almacenamiento del disco. Por ejemplo, supongamos que hay un clúster de tres nodos parecido al que se muestra en la Figura 3–2. En esta figura, el nodo A y el nodo B comparten acceso al mismo alojamiento de disco y el nodo B y el nodo C a otro distinto. Existiría pues un total de cinco votos de quórum, tres de los nodos y dos de los dispositivos del quórum compartidos entre los nodos. Un clúster necesita una mayoría de los votos de quórum para formarse.

  El software de Sun Cluster no obliga a especificar un dispositivo del quórum entre cada par de nodos que comparta acceso a un alojamiento de almacenamiento en disco. Sin embargo, puede proporcionar los votos de quórum necesarios para el caso en que una configuración N+1 degenere en un clúster de dos nodos y también falle el nodo con acceso a ambos alojamientos del disco. Si ha configurado dispositivos del quórum entre todos los pares, el nodo restante podría seguir funcionando como clúster.

  Consulte la Figura 3–2 para obtener ejemplos de estas configuraciones.

Figura 3–2 Ejemplos de configuraciones de los dispositivos del quórum

Directrices del quórum

Use las directrices siguientes cuando configure dispositivos del quórum:

• Establezca un dispositivo del quórum entre todos los nodos que estén conectados al mismo alojamiento de almacenamiento en disco compartido. Agregue un disco dentro del alojamiento compartido como dispositivo del quórum para asegurarse de que si falla cualquier nodo, los otros puedan mantener el quórum y servir a los grupos de dispositivos de disco del alojamiento compartido.

• El dispositivo del quórum se debe conectar con al menos dos nodos.

• Un dispositivo del quórum puede ser cualquier disco de tipo SCSI-2 o SCSI-3, usado como dispositivo del quórum dual. Los discos conectados a más de dos nodos deben admitir la función Persistent Group Reservation (PGR) aunque no se esté usando el disco como dispositivo del quórum. Para obtener más información, consulte el capítulo sobre planificación en Sun Cluster Software Installation Guide.

• Puede usar como dispositivo del quórum un disco que contenga datos del usuario.

Aislamiento de fallos

Un problema fundamental de los clústers es un fallo que provoque en éstos una partición (denominada esquizofrenia). Cuando ocurre, no todos los nodos pueden comunicarse, por lo que algunos podrían intentar formar clústers individuales o subconjuntos que se creerían con permisos de acceso y de propiedad exclusivos respecto a los discos multisistema. En consecuencia, varios nodos intentando escribir en los discos podrían provocar la corrupción de los datos.

El aislamiento de fallos limita el acceso de los nodos a los discos 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 para servicios que utilizan discos multisistema. Cuando un miembro del clúster que sirve actualmente como primario (propietario) del grupo de dispositivos de disco cae o deja de ser accesible, se elije otro primario, lo que permite que continúe el acceso al grupo de dispositivos de disco con la mínima interrupción. Durante este proceso, el primario antiguo debe renunciar al acceso a los dispositivos antes de que el nuevo primario pueda iniciarse. 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 SunPlex usa reservas de disco SCSI para implementar el aislamiento de fallos, gracias a las cuales, los nodos fallidos se “aíslan” de los discos multisistema, evitando que accedan a estos discos.

Las reservas de los discos SCSI-2 admiten un tipo que concede acceso a todos los nodos conectados al disco (cuando no hay ninguna reserva vigente) o restringe el acceso a un nodo individual (el nodo que retiene 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. Cuando se produce este aislamiento de fallos es normal que el nodo aislado emita un aviso grave con mensajes de “conflicto de reserva” en la consola.

El conflicto de reserva se produce porque después de haberse detectado que el nodo ya no es miembro del clúster, se pone una reserva SCSI en todos los discos que están compartidos entre este nodo y los demás nodos. El nodo podría no advertir que se le está aislando y si intenta acceder a uno de los discos compartidos, detecta la reserva y entra en situación de pánico.

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

El mecanismo por el que la estructura del clúster se asegura de que un nodo fallido no pueda rearrancar y empezar a escribir en almacenamiento compartido se denomina 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. ioctl es una directiva para el controlador de disco y da a un nodo la posibilidad de entrar en pánico por sí mismo si éste no puede acceder al disco debido a que otro nodo lo está reservando.

ioctl MHIOCENFAILFAST hace que el controlador compruebe el retorno del error de cada lectura y escritura que emite un nodo al disco en el caso del código de error Reservation_Conflict. ioctl emite periódicamente en segundo plano una operación de prueba al disco para comprobar si se produce Reservation_Conflict. Las rutas del flujo de control de segundo y primer plano entran en pánico 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 en los rearranques de los nodos. El mecanismo de recuperación rápida funciona igual aunque disponga de 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 forme parte de la partición que pueda conseguir el quórum coloca reservas en los discos compartidos y cuando el nodo que no tiene el quórum intenta acceder a éstos recibe un conflicto de reserva y entra en condición de pánico como resultado del mecanismo de recuperación rápida.

Después de la condición de pánico, el nodo podría rearrancar e intentar volverse a unir al clúster o, si éste se compone de sistemas basados en plataformas SPARC, permanecer en el indicador OpenBoot^TM PROM (OBP). La acción que se toma depende del valor del parámetro auto-boot?. Se puede establecer auto-boot? con eeprom(1M), en el indicador ok de la PROM de OpenBoot en un clúster basado en la plataforma SPARC o con la utilidad SCSI que se puede ejecutar opcionalmente tras un arranque de la BIOS en un clúster basado en la plataforma x86.

Servicios de datos

El término servicio de datos describe una aplicación de otras fabricantes, como Sun Java System Web Server (anteriormente Sun Java System Web Server) o, en el caso de clústers basados en plataformas SPARC, Oracle, configurada para ejecutarse en un clúster antes que en un único servidor. Un servicio de datos se compone de una aplicación, archivos de configuración de Sun Cluster y métodos de gestión Sun Cluster que controlan las acciones siguientes de la aplicación.

• Iniciar

• Detener

• Supervisar y tomar acciones correctoras

• Para obtener información acerca de los servicios de datos, consulte “Data Services” in Sun Cluster Overview for Solaris OS.

En la Figura 3–3 se compara una aplicación que se ejecuta en un servidor de aplicaciones individual (el modelo de servidor individual) con la misma aplicación que se ejecuta en un clúster (el modelo de servidores en clúster). Tenga en cuenta que desde el punto de vista del usuario, no hay diferencia entre las dos configuraciones, excepto en que la aplicación en clúster podría ejecutarse más rápido y con alta disponibilidad.

Figura 3–3 Configuración cliente/servidor estándar frente a configuración en clúster

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

En el modelo basado 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 obligan a especificar nombres de sistema lógicos o direcciones compartidas como interfaces de red, no son intercambiables; otros, en cambio, permiten especificar nombres de sistema lógicos o direcciones compartidas. Consulte la instalación y configuración de cada servicio de datos para obtener los detalles que se deben especificar.

Un recurso de red no está asociado con ningún servidor físico determinado, puede cambiar entre servidores físicos.

Un recurso de red está asociado inicialmente con un nodo, el primario. Si éste falla, los recursos de la red y de la aplicación se trasladan a otro nodo del clúster (uno 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–4 se compara el modelo de servidor individual con el basado 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–4 Comparación entre los nombres de sistema fijo y lógico

Una dirección compartida también está asociada inicialmente con un nodo denominado nodo de interfaz global (GIF). La dirección compartida se usa como interfaz de red única en el clúster y se conoce como interfaz global.

La diferencia entre los modelos de nombre de sistema lógico y de servicio escalable es que en éste cada nodo también tiene la dirección compartida configurada activamente en su interfaz de bucle. Esta configuración hace posible tener activas varias instancias de un servicio de datos 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 adicionales del clúster con lo que el rendimiento se multiplicará..

Si el nodo GIF falla, la dirección compartida puede llevarse a otro nodo que también esté ejecutando una instancia de la aplicación (convirtiendo así al otro nodo en el nuevo GIF). 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–5 se compara la configuración de servidor individual con la configuración de servicio escalable 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–5 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 que se ejecutan bajo el control del Gestor de grupos de recursos (RGM), el cual los usa 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 discos 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 por el software Sun Cluster, el sistema SunPlex también proporciona una API y varias herramientas de desarrollo de servicios de datos que permiten a los programadores de aplicaciones desarrollar los métodos de servicio de datos necesarios para que otras aplicaciones se ejecuten como servicios de datos de alta disponibilidad con el software de Sun Cluster.

Servicios de datos a prueba 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 a prueba de fallos usan un grupo de recursos de recuperación de fallos, que es un contenedor para recursos de instancias de aplicaciones y de red (nombres de sistema lógicos). Éstos 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 del mismo nodo o la de otro nodo (recuperación de fallos), dependiendo 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; usan dos grupos de recursos: un grupo de recursos escalable que contiene los recursos de aplicaciones y un grupo de recursos a prueba de fallos que contiene los recursos de red (direcciones compartidas) de los que depende un 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 peticiones de servicio llegan al clúster a través de una interfaz de red individual (interfaz global) y se distribuyen a los nodos según uno de varios algoritmos definidos por la política de equilibrio de cargas que el clúster puede usar para equilibrar la carga del servicio entre varios nodos. Tenga en cuenta que pueden haber varias interfaces globales en distintos nodos alojando 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 en ejecución, ésta 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. En caso contrario, continúa ejecutándose en los nodos restantes, lo que podría provocar una degradación en el 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.

En la Figura 3–6 se muestra un ejemplo de grupo de recursos escalable y las dependencias que existen entre ellos para los servicios escalables. Este ejemplo muestra tres grupos de recursos. El grupo de recursos a prueba 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. Los grupos de recursos escalables sólo contienen instancias de la aplicación de Apache Web Server. Tenga en cuenta que existen dependencias de grupos de recursos entre los grupos de recursos escalables y los a prueba de fallos (líneas sólidas) y que todos los demás recursos de la aplicación de Apache dependen del recurso de red schost-2, que es una dirección compartida (líneas punteadas).

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

Política de equilibrio de cargas

El equilibrio de cargas mejora el rendimiento del servicio escalable, tanto en tiempo de respuesta como como en rendimiento.

Existen dos clases de servicios de datos escalables: puros y adosados. Un servicio puro es aquel cuyas instancias pueden responder a peticiones de clientes sin restricciones. Un servicio adosado es uno en el que un cliente envía peticiones 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 cluster de tres nodos supongamos que cada nodo pesa una unidad. Cada nodo dará servicio a 1/3 de las peticiones de cualquier cliente en nombre de ese servicio. El administrador puede cambiar los pesos en todo momento con la interfaz de órdenes scrgadm(1M) o con la GUI de administración de SunPlex.

Existen dos variedades de servicios adosados, normales y comodín, ambos permiten que sesiones simultáneas de aplicación a través de varias conexiones TCP compartan el estado de la memoria (estado de la sesión de aplicación).

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

Por ejemplo, un explorador web en el cliente se conecta a una dirección IP compartida en el puerto 80 usando tres conexiones TCP distintas, pero las conexiones están intercambiando información de sesión en memoria intermedia entre ellas en el servicio.

Una generalización de política de adosamiento se aplica a varios servicios escalables que intercambien información de forma no visible en la misma instancia. Cuando estos servicios intercambian información de la sesión de forma no visible en la misma instancia, se dice que el cliente está “adosado” con respecto a varias instancias de servidor del mismo nodo que recibe en varios puertos.

Por ejemplo, un cliente de una sede web de comercio electrónico llena su carro de la compra con artículos mediante HTTP normal en el puerto 80, pero cambia a SSL en el puerto 443 para enviar datos seguros y pagar con tarjeta de crédito los artículos escogidos.

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 con respecto a la misma dirección IP.

Un buen ejemplo de esta política es el FTP de modalidad pasiva. Un cliente se conecta a un servidor FTP en el puerto 21 y después el servidor le informa que vuelva a conectarse a un servidor de puertos que está a la escucha en el rango de puertos dinámico. Todas las solicitudes para esta dirección IP se redirigen al mismo nodo que el servidor informó al cliente a través de la información de control.

Tenga en cuenta que además de estas políticas de adosamiento también está vigente de forma predeterminada la política de equilibrio de cargas ponderada, por tanto la petición inicial de un cliente se dirige a la instancia que dicta el repartidor de cargas. Cuando el cliente ha establecido una afinidad para el nodo en que se está ejecutando la instancia, las futuras peticiones se dirigen a esa instancia siempre que el nodo esté accesible y la política de equilibrio de cargas no cambie.

A continuación se explican detalles adicionales sobre las políticas de equilibrio de cargas específicas.

• Ponderada: la carga se distribuye entre varios nodos según valores de peso especificados. Esta política se establece mediante 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. Dado X=peso y A=peso total de todos los nodos activos, cada uno puede esperar recibir aproximadamente X/A del total de conexiones nuevas, cuando éste sea lo bastante 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 puerta giratoria siempre haría que todas las peticiones de un cliente fueran a un nodo distinto: la primera petición 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. Se establece mediante el valor LB_STICKY para la propiedad del recurso Load_balancing_policy.

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

Valores de retroceso

Los grupos de recurso se cubren entre nodos. Cuando esto se produce, el que hacía el papel de secundario se convierte en el nuevo primario. La configuración de retroceso especifica las acciones que acontecen cuando el primario original vuelve 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. La opción deseada se especifica mediante el valor Failback de la propiedad del grupo de recurso.

En algunos casos si el nodo original que aloja al grupo de recursos está fallando y rearrancando continuamente, configurar la rectificación podría producir una disponibilidad menor para el grupo de recursos.

Supervisores de fallos de servicios de datos

Cada servicio de datos de SunPlex 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 sondas, se pueden tomar acciones predefinidas, como reiniciar daemons o producir una recuperación de fallos.

Desarrollo de 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 ofrece en algún momento una aplicación que se desee ejecutar como servicio a prueba de fallos o escalable, se puede usar la API DSET u otra para configurar la aplicación a fin de que se ejecute como un servicio de tipo a prueba de fallos o escalable.

Existe un conjunto de criterios para determinar si una aplicación puede convertirse en un servicio a prueba de fallos. Los criterios específicos se describen en los documentos de SunPlex que tratan de las API que se puede usar para las aplicaciones.

Aquí, presentamos algunas directrices que permitirán comprender si el servicio puede aprovechar las ventajas de la arquitectura de servicios de datos escalable. Repase el apartado Servicios de datos escalables para obtener más información sobre los servicios escalables.

Los servicios nuevos que sigan estas directrices pueden utilizar las ventajas de los servicios escalables. Si un servicio existente no sigue estas directrices exactamente, será necesario reescribir partes del mismo para que las cumpla.

Un servicio de datos escalable tiene las características siguientes. En primer lugar, un servicio así está compuesto por una o más 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 se pueden ejecutar en el mismo nodo.

En segundo lugar, si el servicio ofrece un almacenamiento de datos lógico externo, debe sincronizarse el acceso simultáneo a este almacenamiento desde varias instancias de servidores para evitar perder actualizaciones o leer los datos mientras se estén modificando. Tenga en cuenta que se llama “externo” para distinguir el almacenamiento del estado en la memoria y “lógico” porque aparece como una entidad única, aunque pueda estar replicado. Además, este almacenamiento de datos lógico tiene la propiedad de que cuando alguna instancia de servidor lo actualiza, las demás instancias pueden ver las modificaciones .

El sistema SunPlex proporciona ese almacenamiento externo a través de su sistema de archivos del clúster y las particiones a bajo nivel 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 ejecuten varias instancias de este servicio, cada una tendrá acceso a este registro cronológico externo y podrá intentar acceder al mismo simultáneamente. Cada instancia debe sincronizar su acceso a este registro o de lo contrario se interferirán entre ellas. El servicio podría usar bloqueos de archivo normales de Solaris con fcntl(2) y lockf(3C) para conseguir la sincronización deseada.

Otro ejemplo de este tipo de almacenamiento es una base de datos de componente trasero como Oracle de alta disponibilidad o Oracle Parallel Server/Real Application Clusters. Tenga en cuenta que este tipo de servidor de base de datos de componente trasero proporciona una sincronización incorporada gracias a las consultas de bases de datos o las transacciones de actualizaciones, por lo que no es necesario que las distintas instancias del servidor implementen su propia sincronización.

Un ejemplo de servicio que no es de tipo escalable en su encarnación actual es el servidor IMAP de Sun. 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.

Finalmente, tenga en cuenta que algunas instancias pueden tener datos privados que sean contradictorios con los de otras. En tal caso, no es necesario que el servicio se preocupe de sincronizar el acceso simultáneo, ya que los datos son privados y sólo esa instancia puede manipularlos. En este caso, se ha de tener cuidado de no almacenar estos datos privados en el sistema de archivos del clúster, porque existe la posibilidad de que resulte accesible globalmente.

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

El sistema SunPlex para que las aplicaciones estén altamente disponibles ofrece:

• Servicios de datos proporcionados como parte del sistema SunPlex

• Una API de servicio de datos

• Una API de biblioteca de desarrollo de servicio de datos

• Un servicio de datos “genérico”

El manual Sun Cluster Data Services Planning and Administration Guide describe cómo instalar y configurar los servicios de datos que se proporcionan con el sistema SunPlex. El manual Sun Cluster Data Services Developer's Guide describe cómo instrumentar otras aplicaciones para hacerlas de alta disponibilidad bajo la estructura de Sun Cluster.

Las API de Sun Cluster permiten a los programadores de aplicaciones desarrollar supervisores de fallos y secuencias que inician y detienen instancias de servicios de datos. Con estas herramientas una aplicación puede instrumentalizarse para que sea un servicio a prueba de fallos o escalable. Además, el sistema SunPlex ofrece un servicio de datos “genérico” que se puede usar para generar rápidamente métodos de inicio y detención necesarios para la aplicación y ejecutarla como servicio a prueba de fallos o escalable.

Uso de la interconexión del clúster para el tráfico de servicio de datos

Un clúster debe tener varias conexiones de red entre los nodos que formen la interconexión del clúster. El software de agrupación en clúster usa varias interconexiones para la alta disponibilidad y para mejorar el rendimiento. Para el tráfico interno (por ejemplo, datos del sistema de archivos o datos de servicios escalables), los mensajes se reparten entre todas las interconexiones disponibles como si pasaran a través de una puerta 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ó el clúster. Por ejemplo, si el nombre de sistema privado para el nodo 1 es clusternode1-priv, use ese nombre para comunicarse a través de la interconexión del clúster con el nodo 1. Los zócalos TCP abiertos mediante este nombre se dirigen por la interconexión del clúster y pueden re-dirigirse de forma transparente en caso de un fallo de la red

Tenga en cuenta que, debido a que los nombres de sistema privados pueden configurarse durante la instalación, la interconexión del clúster podría usar cualquiera de los nombres elegidos en ese momento. El nombre real podrá obtenerse con scha_cluster_get(3HA) con el argumento scha_privatelink_hostname_node.

Para el uso de la interconexión del clúster a nivel de aplicación, se usa una interconexión simple entre cada par de nodos, aunque si es posible es mejor utilizar interconexiones distintas para distintos pares de nodos. Por ejemplo, consideremos una aplicación que se ejecuta en tres nodos basados en plataformas SPARC y se comunica mediante la interconexión del clúster. La comunicación entre los nodos 1 y 2 podría darse en la interfaz hme0, mientras que la comunicación entre los nodos 1 y 3 podría producirse en la interfaz qfe1. Es decir, que la comunicación entre dos nodos estaría limitada a la interconexión simple, mientras que internamente la comunicación del clúster se dividiría entre todas las interconexiones.

Tenga en cuenta que la aplicación comparte la interconexión con el tráfico interno del clúster, por lo que el ancho de banda disponible para la aplicación depende del que se use para el resto del tráfico del clúster. En caso de fallo, el tráfico interno puede desviarse por el resto de interconexiones, mientras que las conexiones de aplicación de una interconexión fallida se cambian a otra que funcione.

Hay dos tipos de direcciones que admiten la interconexión del clúster y gethostbyname(3N) en un nombre de sistema privado normalmente devuelve dos direcciones IP. La primera dirección se denomina dirección pairwise lógica y la segunda dirección pernode lógica.

A cada par de nodos se le asigna una dirección lógica pairwise independiente. Esta pequeña red lógica admite la recuperación de fallos de las conexiones. A cada nodo también se le asigna una dirección pernode fija. Es decir, las direcciones pairwise lógicas para clusternode1-priv son distintas para cada nodo, mientras que la dirección pernode lógica para clusternode1-priv es la misma en todos los nodos. Un nodo no dispone de dirección pairwise consigo mismo, por tanto gethostbyname(clusternode1-priv) en el nodo 1 sólo devuelve la dirección pernode lógica.

Tenga en cuenta que las aplicaciones que acepten conexiones a través de la interconexión del clúster y que después verifiquen la dirección IP por motivos de seguridad deben comprobarse con todas las direcciones IP que haya devuelto la orden gethostbyname y no sólo con la primera de ellas.

Si necesita direcciones IP uniformes en su aplicación en todos los puntos, configure la aplicación para vincularla con la dirección pernode en los lados del cliente y el servidor para que parezca que todas las conexiones vengan y vayan de la dirección pernode.

Recursos, grupos de recursos y tipos de recursos

Los servicios de datos usan varios tipos de de recursos: las aplicaciones como Sun Java System Web Server (anteriormente Sun Java System Web Server) o Apache Web Server usan direcciones de red (nombres de sistema lógicos 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 for Oracle es el tipo de recurso SUNW.oracle-server y Sun Cluster HA for Apache es SUNW.apache.

El tipo de recurso SUNW.oracle-server sólo se usa en clústers basados en plataformas SPARC.

Un recurso es una concreción de tipo de recurso que está definida a nivel del clúster. Hay definidos distintos tipos de recursos.

Los recursos de red son tipos de recurso SUNW.LogicalHostname o SUNW.SharedAddress. Ambos están registrados previamente por el software de Sun Cluster.

Los tipos de recurso SUNW.HAStorage y HAStoragePlus se usan para sincronizar el inicio de recursos y los grupos de dispositivos de disco de los que éstos dependen. Aseguran que antes de que se inicie un servicio de datos, estén disponibles las rutas de acceso a los puntos de montaje de los sistemas de archivos del clúster, dispositivos globales y grupos de dispositivos. Para obtener más información, consulte “Synchronizing the Startups Between Resource Groups and Disk Device Groups” en el manual Data Services Installation and Configuration Guide. (El tipo de recurso HAStoragePlus estuvo disponible en Sun Cluster 3.0 5/02 e incorporó otra característica, permitiendo a los sistemas de archivo locales que estuvieran altamente disponibles. Para obtener más información sobre esta función, consulte Tipo de recurso HAStoragePlus.)

Los recursos gestionados por RGM se sitúan en grupos denominados grupos de recursos, de forma que pueden ser gestionados como una unidad. El grupo de recursos migra como unidad si se inicia una recuperación de fallos o una conmutación.

Cuando un grupo de recursos que contiene recursos de aplicación se pone en línea, la aplicación se inicia. El método de inicio del servicio de datos espera hasta que la aplicación esté completamente en marcha antes de salir con éxito. 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 el manual Sun Cluster Data Services Planning and Administration Guide para obtener más información sobre este 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 recursos en contenedores llamados 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 hacen que los recursos y los grupos de recursos cambien entre los estados en línea y fuera de línea. En el apartado Estados y configuración de recursos y grupos de recursos puede encontrarse una descripción completa de los estados y valores que pueden aplicarse a recursos y grupos de recursos. Consulte Recursos, grupos de recursos y tipos de recursos para obtener información sobre cómo ejecutar un proyecto de gestión de recursos bajo el control de RGM.

Estados y configuración de recursos y grupos de recursos

Los administradores aplican a recursos y grupos de recursos configuraciones estáticas que sólo pueden cambiarse con acciones administrativas. RGM cambia los grupos de recursos entre los 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. Los grupos de recursos los gestiona RGM. La orden scrgadm(1M) se puede utilizar para provocar que RGM se encargue o no de la gestión de 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. Debe gestionarse antes de que cualquier recurso que se incluya en el grupo pueda activarse.

  En algunos servicios de datos, por ejemplo en un servidor web escalable, el trabajo debe hacerse antes de iniciar los recursos de red y después de que se detengan. 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.

  El uso más común de los métodos INIT y FINI son para recursos de red de servicios escalables, pero pueden usarse para cualquier trabajo de inicialización o limpieza que no realice la propia aplicación.

• Habilitados o inhabilitados: son los valores a nivel del clúster que se aplican a los recursos. La orden scrgadm(1M) se puede usar para habilitar o inhabilitar un recurso. 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 por algún motivo desea que el recurso no esté disponible en todos los nodos del clúster, puede inhabilitarlo. 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.

  Estos estados cambian a medida que el clúster pasa a través de los pasos de reconfiguración durante una conmutación o una recuperación de fallos. También pueden cambiarse a través de acciones de administración. La orden scswitch(1M) se puede usar para cambiar los estados en línea o 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 significa que todos sus recursos también lo están. Si un grupo de recursos está en línea significa que todos sus recursos habilitados también lo están.

  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 recursos y grupos de recursos

En los servicios de datos de SunPlex se pueden configurar valores de propiedad para recursos y grupos de recursos. 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. El conjunto de propiedades estándar se describe en un apéndice de Sun Cluster Data Services Planning and Administration Guide.

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 el capítulo específico para servicios de datos de Sun Cluster Data Services Planning and Administration Guide.

Configuración del proyecto de servicios de datos

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

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

La funcionalidad de la gestión de Solaris en un entorno clúster permite dar prioridad a las aplicaciones más importantes al compartir un nodo con otras aplicaciones. Las aplicaciones podrían compartir un nodo si hay servicios consolidados o porque se haya producido una recuperación de fallos. El uso de la funcionalidad de la gestión que se describe aquí podría mejorar la disponibilidad de una aplicación crítica ya que evita que otras aplicaciones de prioridad baja consuman demasiados suministros del sistema, como tiempo de CPU.

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

Este apartado ofrece una descripción conceptual de la configuración de los servicios de datos para ejecutar procesos en un project(4) especificado de Solaris 9. Este apartado también describe varios casos de recuperación de fallos y sugerencias para planificar el uso de la funcionalidad de la gestión que ofrece el entorno Solaris. Para obtener documentación detallada sobre conceptos y procedimientos de la función de la gestión, consulte System Administration Guide: Resource Management and Network Services en Solaris 9 System Administrator Collection.

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

1. Configure aplicaciones como parte del recurso.

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

3. Habilite los recursos del grupo.

4. Haga gestionable el grupo de recursos.

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

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

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

Para configurar las propiedades estándar Resource_project_name o RG_project_name para asociar el ID de proyecto de Solaris con el recurso o grupo de recursos, use la opción -y con la orden scrgadm(1M). Configure los valores de la propiedad al recurso o grupo de recursos. Consulte “Standard Properties” in Sun Cluster Data Services Planning and Administration Guide for Solaris OS para obtener las descripciones adecuadas. Consulte r_properties(5) y rg_properties(5) for property descriptions.

El nombre del proyecto especificado debe existir en la base de datos de proyectos (/etc/project) y el superusuario debe estar configurado como miembro del proyecto con ese nombre. Consulte “Projects and Tasks” in System Administration Guide: Resource Management and Network Services en Solaris 9 System Administrator Collection para obtener información conceptual sobre el nombre del proyecto. Consulte project( 4) para obtener una descripción de la sintaxis de los archivos del proyecto.

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

Los usuarios pueden asociar recursos o grupos de recursos con proyectos en cualquier momento. Sin embargo, el nombre del proyecto nuevo no tiene vigencia hasta que el recurso o grupo de recursos se pone fuera de línea y se vuelve a poner en línea usando RGM.

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

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

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

• Programación de partición justa (FSS): ofrece la posibilidad de controlar la ubicación de tiempo de CPU disponible entre cargas de trabajo según su importancia. Ésta se mide por el número de particiones de tiempo de CPU que se asigna a cada carga de trabajo. Consulte dispadmin(1M) para obtener una descripción de las líneas de órdenes para establecer FSS como programador predeterminado. Consulte también priocntl(1), ps(1) y FSS(7) para obtener más información.

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

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

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

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

Si se configura todos los nodos del clúster de forma idéntica, los límites de uso se hacen cumplir de forma idéntica en los nodos primarios y secundarios. Es necesario que los parámetros de configuración de los proyectos no sean idénticos en todas las aplicaciones de todos los nodos. Todos los proyectos asociados con la aplicación deben ser accesibles al menos por la base de datos de proyectos en todos los maestros potenciales de esa aplicación. Supongamos que la aplicación 1 está controlada por phys-schost-1 pero podría efectuarse una conmutación o resolución de error a phys-schost-2 o phys-schost-3. El proyecto asociado con la aplicación 1 debe estar accesible en los tres nodos (phys-schost-1, phys-schost-2 y phys-schost-3).

La información de la base de datos de proyectos puede ser un archivo local /etc/project o puede estar almacenada en el mapa NIS o en el servicio de directorios LDAP.

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

Establecimiento de límites de memoria virtual por proceso

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

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

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

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

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

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

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

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

Casos de recuperación de fallos

Puede configurar parámetros de gestión para que la asignación en la configuración del proyecto (/etc/project) funcione normalmente en el clúster y en las situaciones de conmutación o recuperación de fallos.

Los apartados siguientes son casos de ejemplo.

• Los dos primeros apartados, “Clúster de dos nodos con dos aplicaciones“ y “Clúster de dos nodos con tres aplicaciones“, muestran casos de recuperación de fallos para nodos completos.

• El apartado “Recuperación de fallos sólo de grupos de recursos“ ilustra el funcionamiento de la recuperación de fallos sólo para una aplicación.

En un entorno del clúster las aplicaciones se configuran como parte de un recurso y éste como parte de un grupo de recursos (RG). Cuando se produce un fallo, el grupo de recursos, junto con su aplicación asociada, se transfieren a otro nodo. En los ejemplos siguientes los recursos no se muestran específicamente. Se presupone que cada recurso sólo tiene una aplicación.

La recuperación de fallos se produce en el orden de lista de nodos especificado en la RGM.

Los ejemplos siguientes tienen estas limitaciones:

• La aplicación 1 (App-1) está configurada en el grupo de recursos RG-1.

• La aplicación 2 (App-2) está configurada en el grupo de recursos RG-2.

• La aplicación 3 (App-3) está configurada en el grupo de recursos RG-3.

Aunque los números de particiones asignadas siguen siendo los mismos, el porcentaje de tiempo de CPU asignado a cada aplicación cambia después de la recuperación de fallos. Este porcentaje depende del número de aplicaciones que se están ejecutando en el nodo y del número de particiones que se han asignado a cada aplicación activa.

En estos casos, se asumen las configuraciones siguientes.

• Todas las aplicaciones están configuradas bajo un proyecto común.

• Cada recurso dispone de una única aplicación.

• Las aplicaciones son los únicos procesos activos de los nodos.

• Las bases de datos de los proyectos están configuradas igual en todos los nodos del clúster.

Clúster de dos nodos con dos aplicaciones

Se pueden configurar dos aplicaciones en un clúster de dos nodos para asegurarse de que todos los sistemas físicos (phys-schost-1, phys-schost-2) actúen como maestros predeterminados de una aplicación. Cada sistema físico actúa como el nodo secundario del otro. Todos los proyectos asociados con las aplicaciones 1 y 2 deben estar representado en los archivos de la base de datos de proyectos de ambos nodos. Cuando el clúster se está ejecutando normalmente, todas las aplicaciones se ejecutan en su principal predeterminado, donde la función de gestión le asigna todo el tiempo de CPU.

Después de una recuperación de fallos o una conmutación, las dos aplicaciones se ejecutan en un único nodo en que se les asigna particiones, como se especifica en el archivo de configuración. Por ejemplo, esta entrada del archivo /etc/project especifica que a la aplicación 1 se le asignan 4 particiones y a la aplicación 2 se le asigna 1 partición.

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

El diagrama siguiente ilustra el funcionamiento normal y las operaciones de recuperación de fallos de esta configuración. El número de particiones que se asignen no cambia. Sin embargo, el porcentaje de tiempo de CPU disponible para cada aplicación puede cambiar, dependiendo del número de particiones asignadas a cada proceso que requiera tiempo de CPU.

Clúster de dos nodos con tres aplicaciones

En un clúster de dos nodos con tres aplicaciones, se puede configurar un sistema físico (phys-schost-1) como principal predeterminado de una aplicación y el segundo sistema físico (phys-schost-2) como principal predeterminado para las otras dos aplicaciones. Consideremos el siguiente archivo de base de datos de proyectos de ejemplo que está en todos los nodos. El archivo de base de datos de proyectos no cambia cuando se produce una recuperación de fallos o una conmutación.

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none)
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

Cuando el clúster se está ejecutando normalmente, a la aplicación 1 se le asignan 5 particiones en su maestro predeterminado, phys-schost-1. Este número es equivalente al 100 por cien del tiempo de CPU porque es la única aplicación que lo demanda en ese nodo. A las aplicaciones 2 y 3 se les asigna 3 y 2 particiones respectivamente en su maestro predeterminado, phys-schost-2. La aplicación 2 recibiría el 60 por ciento del tiempo de CPU y la aplicación 3 recibiría el 40 por ciento durante el funcionamiento normal.

Si se produce una recuperación de fallos o una conmutación y la aplicación 1 se cambia a phys-schost-2, las particiones para las tres aplicaciones siguen siendo las mismas. Sin embargo, los porcentajes de recursos de CPU se reasignan según el archivo de base de datos de proyectos.

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

• La aplicación 2, con 3 particiones, recibe el 30 por ciento de CPU.

• La aplicación 3, con 2 particiones, recibe el 20 por ciento de CPU.

El diagrama siguiente ilustra el funcionamiento normal y las operaciones de recuperación de fallos de esta configuración.

Recuperación de fallos sólo de grupos de recursos

En una configuración en la que varios grupos de recursos tienen el mismo maestro predeterminado, un grupo de recursos (y sus aplicaciones asociadas) pueden entrar en recuperación de fallos o cambiarse a un nodo secundario. Mientras tanto el maestro predeterminado está ejecutándose en el clúster.

Durante la recuperación de fallos a la aplicación que falla se le asignan recursos, como los que se especifican en el archivo de configuración en el nodo secundario. En este ejemplo, los archivos de la base de datos de proyectos de los nodos primario y secundario tienen las mismas configuraciones.

Por ejemplo, este archivo de configuración de ejemplo especifica que a la aplicación 1 se le asigna 1 partición, a la aplicación 2 se le asignan 2 y a la aplicación 3 se le asignan otras 2.

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

El diagrama siguiente ilustra las operaciones normal y de resolución de problemas de esta configuración, en que RG-2, que contiene la aplicación 2, falla sobre phys-schost-2. Tenga en cuenta que el número de particiones asignadas no cambia. Sin embargo, el porcentaje de tiempo de CPU disponible para cada aplicación puede cambiar, dependiendo del número de particiones asignadas a cada aplicación que requiera tiempo de CPU.

Adaptadores de red pública y Ruta múltiple de red 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 Solaris Internet Protocol (IP) Network Multipathing en Sun Cluster ofrece el mecanismo básico para supervisar los adaptadores de red pública y cambiar direcciones IP de un adaptador a otro cuando se detecta un fallo. Todos los nodos del clúster tienen su propia configuración de Ruta múltiple de red IP, que puede ser distinta de la de otros nodos del clúster.

Los adaptadores de red pública están organizados en grupos de ruta múltiple IP (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 o se pueden configurar interfaces en espera que estén inactivos a menos que ocurra una recuperación de fallos. El daemon de ruta múltiple in.mpathd usa una dirección IP de prueba para detectar fallos y reparaciones, si detecta un fallo en uno de los adaptadores, se produce una recuperación de fallos. Todos los accesos de red se transfieren desde el adaptador erróneo a otro que funcione del grupo de ruta múltiple, con los cual se mantiene la conectividad de red pública para el nodo. Si se configuró una interfaz en espera, el daemon lo eligirá. En caso contrario, in.mpathd elige la interfaz con la dirección IP de número inferior. Debido a que la recuperación del fallos se produce en la interfaz del adaptador, las conexiones de mayor nivel como TCP no se resultan afectadas excepto por un breve retraso durante la recuperación de fallos. Cuando se completa satisfactoriamente la recuperación de fallos de direcciones IP, se envían emisiones ARP generalizadas. Así se mantiene la conectividad con clientes remotos.

Debido a la característica de recuperación de congestiones de TCP, los puntos finales de TCP pueden verse más retrasados después de una recuperación de fallos satisfactoria, ya que algunos segmentos podrían perderse durante el proceso, activándose el mecanismo de control de congestión 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. Para obtener más información sobre nombres de sistema lógicos y recursos de dirección compartida, consulte Sun Cluster Data Services Planning and Administration Guide.

El diseño del mecanismo de la Ruta múltiple de red IP está pensado para detectar y filtrar fallos de adaptadores, no para recuperarse de un administrador usando ifconfig(1M) para quitar una de las direcciones IP lógicas (o compartidas). El software de Sun Cluster trata las direcciones IP lógicas y compartidas como recursos gestionados por RGM. La forma correcta de que un administrador agregue o retire una dirección IP es usar scrgadm(1M) para modificar el grupo de recursos que lo contiene.

Para obtener más información sobre la implementación de Solaris de la Ruta múltiple de red IP, consulte la documentación apropiada para el sistema operativo Solaris instalado en su clúster.

SPARC: Compatibilidad con la reconfiguración dinámica

La compatibilidad de Sun Cluster 3.1 4/04 con la función de software de reconfiguración dinámica (DR) se está desarrollando en fases incrementales. Este apartado describe los conceptos y consideraciones con respecto a la compatibilidad de Sun Cluster 3.1 4/04 con la función DR.

Tenga en cuenta que todos los requisitos, procedimientos y restricciones que se documentan para la función DR de Solaris también se aplican al soporte DR de Sun Cluster (excepto para el funcionamiento silencioso del sistema operativo). Por consiguiente, se ha de repasar la documentación de la función de DR de Solaris antes de utilizarla con el software Sun Cluster. En concreto las cuestiones que afectan a los dispositivos de E/S que no son de la red durante una operación de desconexión de DR. Están disponibles para su descarga 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) desde http://docs.sun.com .

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

La función DR permite operaciones, como la extracción de hardware en sistemas que están en funcionamiento. 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, afecta a todos los componentes de ésta. Cada placa puede contener varios componentes, como CPU, memorias e interfaces periféricas para unidades de disco, unidades de cinta y conexiones en red.

Extraer una placa que contenga componentes activos puede 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 tanto, siempre es seguro usar una operación de extracción de placa por DR ya que el subsistema DR rechaza las operaciones en placas que contengan componentes activos.

La operación de agregar placas DR también es siempre segura. El sistema pone en funcionamiento automáticamente la CPU y la memoria de una placa recién añadida. Sin embargo, el administrador del sistema debe configurar manualmente el clúster para usar activamente componentes que se encuentren en la placa recién añadida.

El subsistema DR tiene varios niveles. Si un nivel inferior informa de un error, el superior también informa del mismo error. Sin embargo, cuando el nivel inferior informa del error específico, el superior informará de un “error desconocido”. Los administradores del sistema deben obviar el “error desconocido” del que informa el nivel superior.

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

SPARC: Consideraciones de la agrupación DR para dispositivos de CPU

El software Sun Cluster no rechazará una operación de extracción de placa con DR debido a la presencia de dispositivos de 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 la agrupación DR para memoria

Con respecto a DR, existen dos tipos de memoria que considerar que difieren sólo en su uso. El hardware real es el mismo para ambos tipos.

La memoria usada por el sistema operativo se llama caja de la memoria del núcleo. El software Sun Cluster no admite operaciones de extracción en placas que contengan la caja de la memoria del núcleo y rechazará cualquiera de estas operaciones. Cuando una operación de extracción de placa con DR pertenezca a una memoria distinta de la caja de la memoria del núcleo, Sun Cluster no rechazará 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 la agrupación 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 con DR pueden llevarse a cabo en unidades no activas del nodo primario y 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 consideraciones sobre los dispositivos del quórum y el procedimiento para llevar a cabo operaciones DR en ellos, consulte SPARC: Consideraciones de la agrupación DR para los dispositivos del quórum.

Consulte Sun Cluster System Administration Guide para obtener instrucciones detalladas sobre cómo llevar a cabo estas acciones.

SPARC: Consideraciones de la agrupación DR para los dispositivos del quórum

Si la operación de extracción de placa con DR pertenece a una placa que contenga una interfaz con un dispositivo configurado para el quórum, Sun Cluster rechazará la operación e identificará el dispositivo del quórum que podría resultar afectado por ésta. Es necesario inhabilitar el dispositivo como del quórum antes de poder efectuar una operación de extracción de placa con DR.

Consulte Sun Cluster System Administration Guide para obtener instrucciones detalladas sobre cómo llevar a cabo estas acciones.

SPARC: Consideraciones de la agrupación DR para interfaces de interconexión del clúster

Si la operación de extracción de placa con DR pertenece a una placa que contenga una interfaz de interconexión del clúster activa, Sun Cluster rechazará la operación e identificará la interfaz que podría resultar afectada por la operación. Es necesario usar una herramienta de administración de Sun Cluster para inhabilitar la interfaz activa antes de que la operación de DR pueda tener éxito (consulte también la nota de precaución siguiente).

Consulte Sun Cluster System Administration Guide para obtener instrucciones detalladas sobre cómo llevar a cabo estas acciones.

Sun Cluster requiere que todos los nodos del clúster tengan al menos una ruta de acceso que funcione con cada uno de 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.

SPARC: Consideraciones de la agrupación DR para interfaces de red pública

Si la supresión de placa con DR pertenece a una placa que contenga una interfaz de red pública activa, Sun Cluster rechazará la operación e identificará la interfaz que podría resultar afectada por la operación. Antes de suprimir una placa que contenga una interfaz de red activa, todo el tráfico de esa interfaz debe cambiarse a otra interfaz funcional del grupo de ruta múltiple mediante la orden 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 supresión de DR.

Consulte Sun Cluster System Administration Guide para obtener instrucciones detalladas sobre cómo llevar a cabo supresiones de DR en interfaces de red públicas.