Capítulo 4 Preguntas más frecuentes (FAQ)

Este capítulo incluye las respuestas a las preguntas más frecuentes sobre el sistema SunPlex. Las preguntas están organizadas por temas.

FAQ sobre alta disponibilidad

• ¿Qué es exactamente un sistema de alta disponibilidad?

  El sistema SunPlex define la alta disponibilidad (HA) como la posibilidad del clúster de mantener en marcha una aplicación aunque se produzca un fallo que en condiciones normales provocaría que el servidor no estuviera disponible.

• ¿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?

  Existen dos tipos de servicios de datos de alta disponibilidad, a prueba de fallos y 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 primario falla, las aplicaciones que se ejecutan en este nodo se trasladan a otro nodo y continúan ejecutándose.

  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). Pueden haber varios nodos GIF en el clúster. 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 está ejecutando la aplicación, ésta continúa ejecutándose en los demás nodos con alguna pérdida de rendimiento hasta que el nodo fallido vuelve al clúster.

FAQ sobre sistemas de archivos

• ¿Puedo ejecutar uno o más nodos del 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 del clúster para aplicaciones que no estén bajo el control del Gestor de grupos de recursos?

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

• ¿Deben tener todos los sistemas de archivos del clúster un punto de montaje debajo del directorio /global?

  No. Sin embargo, si se sitúan los sistemas de archivos del clúster bajo un 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?

  Existen 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, cuando se accede a un archivo desde varios nodos, para lectura, escritura, bloqueo de archivo, E/S asíncrona.

  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 modifica los atributos de un archivo (por ejemplo, mediante chmod(1M)) en un sistema de archivos del clúster, los cambios se reflejarán inmediatamente en todos los nodos. Con un sistema de archivos NFS exportado, esto puede llevar mucho más tiempo.

• El sistema de archivos /global/.devices/node@<ID_nodo> aparece en los nodos de mi 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. No están pensados para un uso general. Aunque sean globales, nunca se accede a ellos de forma global (cada nodo sólo accede a su propio espacio de nombres de dispositivo global). Si un nodo está inactivo, 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 de 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 con el software Solaris Volume Manager cuando gestiona los discos locales y VERITAS Volume Manager con los discos multisistema. No se admite ninguna otra combinación.

  x86: No, esta configuración no se admite, puesto que Solaris Volume Manager sólo se admite en los clústers basados en la plataforma x86.

FAQ de servicios de datos

• ¿Qué servicios de datos SunPlex están disponibles?

  La lista de servicios de datos admitidos se incluye en el manual Sun Cluster Release Notes.

• ¿Qué versiones de aplicaciones admiten los servicios de datos de SunPlex?

  La lista de las versiones de aplicaciones admitidas se incluye en el Sun Cluster Release Notes.

• ¿Puedo escribir mi propio servicio de datos?

  Sí. Para obtener más información, consulte la documentación de Sun Cluster Data Services Developer's Guide y de Data Service Enabling Technologies que se incluía con la API de desarrollo de las bibliotecas del servicio de datos.

• 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 for NFS, siempre que en la documentación se habla del uso de un recurso LogicalHostname de un grupo de recursos de modo Failover, en su lugar se puede usar un recurso SharedAddress o LogicalHostname. El uso de un recurso SharedAddress produce una sobrecarga adicional porque el software de red del clúster está configurado para SharedAddress pero no para LogicalHostname.

  Existe una ventaja respecto a usar SharedAddress cuando que se está configurando servicios de datos escalables y a prueba de fallos y se desea que los clientes puedan acceder a ambos servicios usando el mismo nombre de sistema. En este caso los recursos SharedAddress junto con el recurso de la aplicación de recuperación de fallos están contenidos en un grupo de recursos, mientras que el recurso del servicio escalable está contenido en un grupo de recursos separado y configurado para usar SharedAddress. Tanto los servicios escalables como los que son a prueba de fallos pueden usar después el mismo conjunto de nombres de sistema/direcciones que estén configurados en el recurso SharedAddress.

FAQ de redes públicas

• ¿Qué adaptadores de red pública admite el sistema SunPlex?

  Actualmente el sistema SunPlex admite 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.

• ¿El sistema SunPlex admite el valor local-mac-address?=true?

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

  Se puede establecer local-mac-address? con eeprom(1M), en el indicador ok de la PROM de OpenBoot en un clúster basado en la plataforma SPARC o con la utlidad SCSI que se puede ejecutar opcionalmente tras un arranque de la BIOS en un clúster basado en la plataforma x86.

• ¿Cuánto retraso puede esperarse cuando la Ruta m&uacute;ltiple de red IP lleva a cabo una conmutación entre adaptadores?

  El retraso podría ser de varios minutos. Esto es debido a que cuando se lleva a cabo la conmutación de la Ruta m&uacute;ltiple de red IP, implica enviar una ARP innecesaria. Sin embargo, no hay garantías de que el encaminador entre el cliente y el clúster utilizará la ARP innecesaria. Así que, hasta que la entrada de la antememoria ARP de esta dirección IP en el encaminador no supere el tiempo de espera, es posible que utilice la dirección MAC anterior.

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

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

  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 es importante para evitar la amnesia (consulte Quórum y dispositivos del quórum para obtener más información sobre 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. Esto evita que accidentalmente se active un nodo con información de configuración del clúster anticuada.

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

  Sí. Aunque esta duplicación no es un requisito, con ella se asegura que un fallo de disco sin duplicación haga inoperativo 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 es tener un nodo como respaldo con una unidad de cinta/biblioteca conectada. 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 manual Sun Cluster System Administration Guide para obtener información adicional sobre los procedimientos de copia de seguridad y restauración.

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

  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.

FAQ de almacenamiento del 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 disco, gracias a la duplicación (o debido a controladores RAID-5 basados en el 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 de interconexión del clúster

• ¿Qué interconexiones del clúster admite el sistema SunPlex?

  Actualmente, el sistema SunPlex admite las interconexiones del clúster Ethernet (100BASE-T Fast Ethernet y 1000BASE-SX Gb) en los clústers basados en las plataformas SPARC y x86. El sistema SunPlex admite las interconexiones del clúster de interfaz de red SCI sólo en los clústers basados en la platafoma SPARC.

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

  Los cables de transporte del clúster se configuran mediante los adaptadores de transporte y los conmutadores. 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.

  El administrador “habilita” e “inhabilita” los cables 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. No han sido sondeados y por tanto no es posible conocer su estatus. El estado de un cable puede verse con scconf -p.

  El gestor de topología del clúster establece dinámicamente las rutas de transporte. El “estatus” de una ruta de transporte lo determina el gestor de topología. Una ruta puede tener el estatus “en línea” o “fuera de línea”. El estatus de una ruta de transporte puede visualizarse con 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 posibles rutas de transporte.

  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 al clúster como lo harían con 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 los capítulos de Sun Cluster Data Services Planning and Administration Guide relacionados con este tema para obtener más información sobre los requisitos de la configuración del lado del cliente.

FAQ de consola de administración

• ¿Requiere el sistema SunPlex una consola de administración?

  Sí.

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

• El sistema SunPlex no requiere el uso de una consola de administración exclusiva, pero si se utiliza una de este tipo se obtienen estas ventajas:

  • 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

• ¿Es necesario que la consola de administración se encuentre “cerca” del propio clúster, por ejemplo en la misma habitación?

  Compruébelo con su proveedor de servicio de hardware. Es posible que el proveedor le requiera que la consola se sitúe muy cerca del clúster en sí mismo. No existe ninguna razón técnica por la que la consola deba estar situada en la misma habitación.

• ¿Puede servirse a más de un clúster desde la misma consola de administración, siempre que se cumplan los requisitos de distancia?

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

FAQ sobre concentrador de terminal y procesador de servicio del sistema

• ¿Requiere el sistema SunPlex un concentrador de terminal?

  Todas las versiones del software empezando por Sun Cluster 3.0 no requieren la ejecución de ningún concentrador de terminal. Al contrario de lo que ocurre con el producto Sun Cluster 2.2, que requería un concentrador de terminal para el aislamiento de fallos, los productos posteriores no dependen el concentrador de terminal.

• Veo que la mayoría de servidores de SunPlex usan concentradores de terminal, pero el servidor Sun Enterprise E10000 no. ¿Por qué?

  El concentrador de terminal es en la práctica un conversor serie para Ethernet para la mayoría de los servidores. Su puerto de consola es un puerto serie. El servidor Sun Enterprise E10000 no dispone de 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 E10000, siempre se usa SSP para consolas.

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

  Usar un concentrador de terminal ofrece acceso en el nivel de la consola a todos los nodos desde una estación de trabajo remota de la red, incluso cuando el nodo está en la PROM de OpenBoot (OBP) en un nodo basado en la plataforma SPARC o en un subsistema de arranque en un nodo basado en la plataforma x86.

• Si utilizo un concentrador de terminal no admitido por Sun, ¿qué necesito saber para certificar el que deseo utilizar?

  La diferencia principal entre el concentrador de terminal que admite Sun y los otros dispositivos de consola es que el de Sun dispone de firmware especial que evita que éste envíe un carácter de interrupción a la consola cuando arranca. Tenga en cuenta que si dispone de un dispositivo de consola que envía a la consola caracteres de interrupción o una señal que pueda interpretarse como tales, el nodo se apaga.

• ¿Se puede liberar un puerto bloqueado en el concentrador de terminal que admite Sun sin volverlo a arrancar?

  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 el manual Sun Cluster System Administration Guide para obtener más información sobre la configuración y administración del concentrador de terminal que admite Sun.

• ¿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?

  En general, el concentrador de terminal está conectado a una pequeña red que usan los administradores de sistema, no una red que se use para otros accesos de 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?

  • 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, vaya a SPARC: Consideraciones de la agrupación 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.