Capítulo 4 Preguntas más frecuentes

Este capítulo incluye respuestas a las preguntas más frecuentes acerca del sistema Sun Cluster. Las preguntas están organizadas por temas.

Preguntas más frecuentes sobre alta disponibilidad

¿Qué es exactamente un sistema de alta disponibilidad?

En el sistema Sun Cluster, se llama alta disponibilidad (HA) a la capacidad de un clúster para mantener en funcionamiento una aplicación. La aplicación sigue ejecutándose incluso cuando se produce un fallo que, normalmente, dejaría un sistema de servidor fuera de servicio.

¿Cuál es el proceso por el que el clúster proporciona alta disponibilidad?

A través de un proceso conocido como recuperación de fallos, la estructura del clúster proporciona un entorno de alta disponibilidad. Recuperación de fallos es una serie de pasos que realiza el clúster para migrar recursos de servicios de datos de un nodo fallido a otro operativo dentro del clúster.

¿Cuál es la diferencia entre un servicio de datos a prueba de fallos y otro escalable?

Hay dos tipos de servicios de datos de alta disponibilidad:

• recuperación tras error

• escalable

Un servicio de datos a prueba de fallos ejecuta una aplicación sólo en un nodo primario del clúster cada vez. Los demás nodos pueden ejecutar otras aplicaciones, pero cada una se ejecuta sólo en un nodo. Si un nodo principal falla, las aplicaciones que se ejecutan en el nodo que ha fallado se recuperan del error y continúan ejecutándose en otro nodo.

Un servicio escalable reparte una aplicación entre varios nodos para crear un servicio lógico único que aprovecha el número de nodos y procesadores de todo el clúster en el que se ejecutan.

Para cada aplicación un nodo aloja la interfaz física para el clúster. Este nodo se denomina interfaz global (GIF). En un clúster pueden existir varios nodos GIF. Cada uno de ellos aloja una o más interfaces lógicas que pueden usar los servicios escalables y que reciben el nombre de interfaces globales. Un nodo GIF aloja una interfaz global para todas las solicitudes hacia una aplicación en particular y las despacha a los distintos nodos en los que se esté ejecutando el servidor de la aplicación. Si el nodo GIF falla, la interfaz global se traslada a un nodo superviviente.

Si falla alguno de los nodos en los que se ejecuta la aplicación, ésta continúa ejecutándose en otros nodos con una leve pérdida de rendimiento. Este proceso continúa hasta que el nodo que ha fallado vuelve al clúster.

FAQ sobre los sistemas de archivos

¿Puedo ejecutar uno o varios de los nodos de un clúster como servidores NFS de alta disponibilidad con otros nodos de clúster como clientes?

No, no haga un montaje de bucle cerrado.

¿Puedo usar un sistema de archivos en clúster para aplicaciones que no estén bajo el control de Gestor de grupos de recursos?

Sí. Sin embargo, sin el control de RGM, es necesario reiniciar manualmente las aplicaciones después del fallo del nodo en que se están ejecutando.

¿Deben tener todos los sistemas de archivos en clúster un punto de montaje en el directorio /global?

No. Sin embargo, si se sitúan los sistemas de archivos clúster bajo el mismo punto de montaje, como /global, se consigue una mejor organización y gestión de estos sistemas de archivos.

¿Cuáles son las diferencias entre usar el sistema de archivos del clúster y exportar sistemas de archivos NFS?

Hay varias diferencias:

1. El sistema de archivos del clúster admite dispositivos globales. NFS no admite acceso remoto a los dispositivos.

2. El sistema de archivos del clúster dispone de un espacio de nombres global. Sólo es necesaria una orden de montaje. Con NFS, debe montarse el sistema de archivos en cada uno de los nodos.

3. El sistema de archivos del clúster almacena en antememoria los archivos en más casos que NFS. Por ejemplo, el sistema de archivos en clúster almacena en caché los archivos cuando se accede a éstos desde varios nodos para efectuar tareas de lectura, escritura, bloqueo de archivos o E/S asíncronas.

4. El sistema de archivos del clúster está creado para aprovechar futuras interconexiones rápidas de clúster que ofrezcan DMA remotas y funciones de copia cero.

5. Si cambia los atributos de un archivo (usando chmod(1M), por ejemplo) en un sistema de archivos en clúster, el cambio se refleja inmediatamente en todos los nodos. Con un sistema de archivos NFS exportado, este cambio puede requerir mucho más tiempo.

El sistema de archivos /global/.devices/node@ID nodo aparece en mis nodos del clúster. ¿Puedo usar este sistema de archivos para almacenar datos que deseo que estén altamente disponibles y sean globales?

Estos sistemas de archivos almacenan los espacios de nombre de dispositivo global. Estos sistemas de archivos no están destinados a un uso general. Aunque son globales, a ellos nunca se accede de manera global: cada nodo accede sólo a su propio espacio de nombre de dispositivo global. Si un nodo está caído, el resto no puede acceder al espacio de nombres del nodo en cuestión. Estos sistemas de archivos no son de alta disponibilidad. No deberían usarse para almacenar datos que hayan de estar globalmente accesibles o altamente disponibles.

FAQ sobre gestión de volúmenes

¿Necesito duplicar todos los dispositivos de disco?

Para que un dispositivo de disco se considere de alta disponibilidad, debe estar duplicado o usar hardware RAID-5. Todos los servicios de datos deben usar dispositivos de disco de alta disponibilidad o sistemas de archivos del clúster montados en dispositivos de disco de alta disponibilidad. Estas configuraciones pueden tolerar fallos de disco puntuales.

¿Puedo usar un gestor de volúmenes para los discos locales (disco de arranque) y otro distinto para los discos multisistema?

SPARC: esta configuración se admite si el software Gestor de volúmenes de Solaris administra los discos locales y VERITAS Volume Manager administra los discos multisistema. No se admite ninguna otra combinación.

x86:no, esta configuración no se admite, puesto que Gestor de volúmenes de Solaris sólo se admite en los clústeres basados en la plataforma x86.

FAQ sobre servicios de datos

¿Qué servicios de datos de Sun Cluster están disponibles?

La lista de servicios de datos compatibles se incluye en Productos admitidos de Notas de la versión de Sun Cluster 3.1 8/05 para SO Solaris.

¿Qué versiones de aplicaciones son compatibles con los servicios de datos de Sun Cluster?

La lista de versiones de aplicaciones compatibles se incluye en Productos admitidos de Notas de la versión de Sun Cluster 3.1 8/05 para SO Solaris.

¿Puedo escribir mi propio servicio de datos?

Sí. Consulte el Capítulo 11, Funciones de la API de DSDL de Sun Cluster: Guía del desarrollador de los servicios de datos del sistema operativo Solaris para obtener más información.

Al crear recursos de red, ¿debo especificar direcciones IP numéricas o nombres de sistema?

El método preferido para especificar recursos de red es usar el nombre de sistema de UNIX en lugar de la dirección IP numérica.

Al crear recursos de red, ¿cuál es la diferencia entre usar un nombre de sistema lógico (un recurso LogicalHostname) o una dirección compartida (un recurso SharedAddress)?

Excepto en el caso de Sun Cluster HA para NFS, cada vez que la documentación recomiende el uso de un recurso LogicalHostname en un grupo de recursos en modo Failover, se podrá utilizar un recurso SharedAddress o bien uno LogicalHostname. El uso de un recurso SharedAddress lleva consigo varias sobrecargas adicionales porque el software de red del clúster está configurado para SharedAddress, no para LogicalHostname.

La ventaja de usar un recurso SharedAddress queda de manifiesto cuando se configuran servicios de datos escalables y de recuperación de fallos y se desea que los clientes puedan acceder a ambos servicios utilizando el mismo nombre de sistema. En este caso, los recursos SharedAddress y el recurso de aplicación de recuperación de fallos están incluidos en un grupo de recursos. El recurso de servicio escalable está en un grupo de recursos separado y está configurado para usar el recurso SharedAddress. Los servicios escalables y de recuperación de fallos pueden usar el mismo conjunto de nombres de sistemas y direcciones que está configurado en el recurso SharedAddress .

FAQ sobre las redes públicas

¿Qué adaptadores de red pública admite el sistema Sun Cluster?

Actualmente, el sistema Sun Cluster es compatible con los adaptadores de red pública Ethernet (10/100BASE-T y 1000BASE-SX Gb). Debido a que en el futuro podrían admitirse interfaces nuevas, compruebe con el representante de ventas de Sun cuál es la información más actual.

¿Cuál es el papel de la dirección MAC en la recuperación de fallos?

Cuando se produce una recuperación de fallos, se generan nuevos paquetes de protocolo de resolución de direcciones (ARP) y se envían a todo el mundo. Estos paquetes ARP contienen la nueva dirección MAC (del nuevo adaptador físico al que se ha transferido el nodo) y la dirección IP antigua. Cuando otra máquina de la red recibe uno de estos paquetes, borra la correlación MAC-IP antigua de la antememoria ARP y usa la nueva.

¿Admite el sistema Sun Cluster la configuración local-mac-address?=true ?

Sí. En realidad, la Ruta múltiple de red IP requiere que el valor local-mac-address? esté configurado como true.

Puede definir local-mac-address? con eeprom(1M), en el indicador OpenBoot PROM ok de un clúster basado en SPARC. También puede definir una dirección MAC con la utilidad SCSI que se ejecute opcionalmente después de que arranque la BIOS en un clúster basado en x86.

¿Cuánto retraso cabe esperar cuando Ruta múltiple de red de protocolo de Internet (IP) realiza una conmutación entre los adaptadores?

El retraso podría ser de varios minutos. El motivo es que cuando se realiza una conmutación en Ruta múltiple de red de protocolo de Internet (IP), la operación envía ARP innecesarios. Sin embargo, no se puede asegurar que el router entre el cliente y el clúster vayan a usar ARP innecesarios. Por ello, hasta que venza la entrada de caché de ARP para esta dirección IP en el router, la entrada podrá usar la dirección MAC antigua.

¿Con qué velocidad se detecta el fallo de un adaptador de red?

El tiempo de detección de fallos predeterminado es de 10 segundos. Este algoritmo intenta cumplir el tiempo de detección de fallos predeterminado, pero el real depende de la carga de la red.

FAQ sobre pertenencia al clúster

¿Tienen que tener la misma contraseña de superusuario todos los miembros del clúster?

No es necesario que el superusuario comparta la misma contraseña en todos los miembros del clúster. Sin embargo, esta práctica simplifica mucho la administración del clúster.

¿Es importante el orden en el que arrancan los nodos?

En la mayoría de los casos no. Sin embargo, el orden de arranque es importante para evitar la amnesia. Por ejemplo, si el nodo dos era el propietario del dispositivo del quórum y el nodo uno estaba caído, y después se desactiva el nodo dos, hay que volver a activar éste antes que aquél. Este orden impide que se active de forma accidental un nodo con información de configuración del clúster desfasada. Consulte Acerca del aislamiento de fallos para obtener detalles acerca de la amnesia.

¿Es necesario realizar una duplicación de los discos locales en un nodo del clúster?

Sí. Aunque la duplicación no es un requisito, duplicar los discos del nodo del clúster impide que un fallo de disco no duplicado deje inactivo el nodo. El inconveniente de realizar una duplicación de los discos locales de un nodo del clúster es que complica la administración del sistema.

¿Cuáles son los inconvenientes de realizar copias de respaldo de los miembros del clúster?

En un clúster se pueden usar varios métodos de copia de respaldo. Un método consiste en dejar un nodo para que sirva de respaldo con una unidad de cinta o una biblioteca adjunta. A continuación se debe usar el sistema de archivos del clúster para realizar la copia de seguridad de los datos. No conecte este nodo a los discos compartidos.

Consulte el Capítulo 9, Copia de seguridad y restauración de un clúster de Sun Cluster: Guía de administración del sistema para el SO Solaris para obtener información adicional acerca de cómo hacer copias de respaldo y restaurar los datos.

¿Cuándo está un nodo en el suficiente buen estado como para usarlo como secundario?

Solaris 8 y Solaris 9:

Después de un arranque, un nodo está en el suficiente buen estado como para ser secundario cuando éste muestra el indicador de inicio de sesión.

Solaris 10:

Un nodo está en buen estado para ser un nodo secundario si el hito multi-user-server se está ejecutando.

# svcs -a | grep multi-user-server:default

FAQ sobre almacenamiento en clúster

¿Qué hace que el almacenamiento multisistema sea de alta disponibilidad?

El almacenamiento multisistema es de alta disponibilidad porque puede sobrevivir a la pérdida de un único disco gracias a la duplicación (o gracias a los controladores RAID-5 basados en hardware). Como los dispositivos de almacenamiento multisistema tienen más de una conexión de sistema, también pueden resistir la pérdida de un nodo al cual estén conectados. Además, las rutas redundantes desde cada nodo al almacenamiento conectado ofrecen tolerancia para el fallo de un adaptador del bus del sistema, de un cable o del controlador de disco.

FAQ sobre interconexiones del clúster

¿Qué interconexiones del clúster admite el sistema Sun Cluster?

Actualmente, el sistema Sun Cluster admite las siguientes interconexiones del clúster:

• Ethernet (100BASE-T Fast Ethernet y 1000BASE-SX Gb) en clústeres basados en SPARC y en x86

• Infiniband en clústeres basados en SPARC y en x86

• SCI sólo en clústeres basados en SPARC

¿Cuál es la diferencia entre un “cable” y una “ruta” de transporte?

Los cables de transporte del clúster se configuran usando adaptadores y conmutadores de transporte. Los cables unen adaptadores y conmutadores según cada componente. El gestor de la topología del clúster usa los cables disponibles para crear las rutas de transporte entre los extremos de los nodos. Un cable no se correlaciona directamente con una ruta de transporte.

Los cables son “habilitados” e “inhabilitados” por el administrador estáticamente. Los cables tienen un “estado” (habilitado o inhabilitado), pero no un “estatus”. Si se inhabilita un cable, es como si estuviera sin configurar. Los cables que están inhabilitados no pueden usarse como rutas de transporte. Estos cables no están probados y, en consecuencia, se desconoce su estado. Puede obtener el estado de un cable usando el comando scconf -p.

El gestor de topología del clúster establece dinámicamente las rutas de transporte. El “estatus” de una ruta de transporte viene determinado por el gestor de topologías. Una ruta puede tener un estado de “en línea” o “fuera de línea.” Puede obtener el estatus de una ruta de transporte usando el comando scstat(1M).

Considere el ejemplo siguiente de clúster de dos nodos con cuatro cables.

node1:adapter0      to switch1, port0
node1:adapter1      to switch2, port0
node2:adapter0      to switch1, port1
node2:adapter1      to switch2, port1

A partir de estos cuatro cables, se pueden formar dos rutas de transporte posibles.

node1:adapter0    to node2:adapter0
node2:adapter1    to node2:adapter1

FAQ sobre sistemas cliente

¿Es necesario considerar alguna necesidad o restricción de cliente para usarla con un clúster?

Los sistemas cliente se conectan a un clúster del mismo modo que lo harían a cualquier otro servidor. En algunos casos, dependiendo de la aplicación del servicio de datos, es posible que necesite instalar software de lado del cliente o llevar a cabo otros cambios de configuración para que el cliente pueda conectarse a la aplicación del servicio de datos. Consulte el Capítulo 1, Planning for Sun Cluster Data Services de Sun Cluster Data Services Planning and Administration Guide for Solaris OS para obtener más información acerca de los requisitos de configuración del cliente.

FAQ sobre la consola administrativa

¿El sistema Sun Cluster requiere una consola administrativa?

Sí.

¿Tiene que tratarse de una consola de administración exclusiva para el clúster? ¿O puede usarse para otras tareas?

El sistema Sun Cluster no requiere una consola administrativa dedicada, pero si usa una, obtendrá los siguientes beneficios:

• Permite la gestión centralizada del clúster ya que agrupa herramientas de consola y gestión en la misma máquina

• Ofrece al proveedor de servicio de hardware una resolución de problemas potencialmente mas rápida

¿Debe colocarse la consola administrativa “cerca” del clúster (por ejemplo, en la misma habitación)?

Compruébelo con su proveedor de servicio de hardware. El proveedor puede requerir que la consola esté ubicada cerca del clúster. No existe ninguna razón técnica por la que la consola deba estar situada en la misma habitación.

¿Puede atender una consola administrativa a más de un clúster, si se cumplen primero otros requisitos de distancia?

Sí. Se pueden controlar varios clústeres desde una misma consola de administración. También puede compartirse un concentrador de terminal simple entre varios clústeres.

FAQ sobre el concentrador de terminal y el procesador de servicio del sistema

¿Requiere el sistema Sun Cluster un concentrador de terminal?

Ninguna versión de software a partir de la Sun Cluster 3.0 requiere un concentrador de terminal para ejecutarse. En cambio, los productos Sun Cluster 2.2 sí requieren un concentrador de terminal para aislamiento de fallos. Los productos posteriores no lo necesitan.

La mayoría de los servidores Sun Cluster utilizan un concentrador de terminal, pero el servidor Sun Enterprise E1000 no lo usa. ¿Por qué no?

El concentrador de terminal es en la práctica un conversor serie para Ethernet para la mayoría de los servidores. El puerto de la consola del concentrador de terminal es un puerto serie. El servidor Sun Enterprise E1000 no tiene una consola serie. El procesador de servicio del sistema (SSP) es la consola, a través de Ethernet o del puerto jtag. Para el servidor Sun Enterprise E1000 se utiliza siempre SSP para las consolas.

¿Cuáles son las ventajas de usar un concentrador de terminal?

El uso de un concentrador de terminal proporciona acceso de consola a cada nodo desde cualquier estación de trabajo de la red. Este acceso se proporciona incluso cuando el nodo está en OpenBoot PROM (OBP) en un nodo basado en SPARC o un subsistema de arranque en un nodo basado en x86.

Si uso un concentrador de terminal que no sea compatible con Sun, ¿qué necesito saber para saber si sirve el que quiero usar?

La principal diferencia entre el concentrador de terminal que es compatible con Sun y otros dispositivos de consola es que el concentrador de terminal de Sun tiene un firmware especial. Este firmware impide que el concentrador de terminal envíe una parada a la consola cuando arranca. Si dispone de un dispositivo de consola que puede enviar una parada, o una señal que la consola pueda interpretar como una parada, dicha parada desconectará el nodo.

¿Puedo liberar un puerto bloqueado en el concentrador de terminal compatible con Sun sin reiniciarlo?

Sí. Anote el número de puerto que necesita restaurarse y escriba las órdenes siguientes:

telnet ct
Enter Annex port name or number: cli
annex: su -
annex# admin
admin : reset número_puerto
admin : quit
annex# hangup
#

Consulte los siguientes manuales para obtener información acerca de cómo configurar y administrar el concentrador de terminal compatible con Sun.

• Información general sobre la administración de Sun Cluster de Sun Cluster: Guía de administración del sistema para el SO Solaris

• Capítulo 2, Installing and Configuring the Terminal Concentrator de Sun Cluster 3.0-3.1 Hardware Administration Manual for Solaris OS

¿Qué ocurre si falla el propio concentrador de terminal? ¿Es necesario tener otro de recambio?

No. No se pierde ninguna disponibilidad del clúster si el concentrador de terminal falla. Se pierde la posibilidad de conectarse a las consolas del nodo hasta que el concentrador vuelva a estar operativo.

Si se usa un concentrador de terminal, ¿qué ocurre con la seguridad?

Normalmente, el concentrador de terminal está adjunto a una pequeña red que usan los administradores de sistema, no a una red que se utilice para el acceso de otros clientes. La seguridad se puede controlar limitando el acceso a esa red en particular.

SPARC: ¿Cómo se utiliza la reconfiguración dinámica con una cinta o unidad de disco?

Siga estos pasos:

• Determine si el disco o la unidad de cinta forma parte de un grupo de dispositivos activo. Si la unidad no forma parte de un grupo de dispositivos activos, puede llevar a cabo la operación de extracción DR en él.

• Si la operación de extracción de placa DR pudiera afectar a un disco o unidad de cinta activos, el sistema rechazará la operación e identificará las unidades que se verían afectadas por la operación. Si la unidad forma parte de un grupo de dispositivos activos, acceda a SPARC: Consideraciones de clúster DR para unidades de disco y cinta .

• Determine si la unidad es un componente del nodo primario o del secundario. Si la unidad es un componente del nodo secundario, puede llevar a cabo la operación de extracción DR en el mismo.

• Si la unidad es un componente del nodo primario, es necesario intercambiar los nodos primario y secundario antes de realizar la operación de extracción DR en el dispositivo.

Si el nodo principal falla durante una operación de DR en un nodo secundario, la disponibilidad del clúster queda afectada. El nodo primario no tiene dónde transferirse hasta que se proporcione un nodo secundario nuevo.