Problemas conocidos

Los siguientes problemas conocidos afectan al funcionamiento de la versión Sun Cluster 3.1 10/03. Si desea conocer la información más actual, consulte el documento Sun Cluster 3.1 10/03 Release Notes Supplement en línea en http://docs.sun.com.

Estado incorrecto de largefile (4419214)

Resumen del problema: el archivo /etc/mnttab no muestra el estado largefile más actual de un sistema de archivos VxFS montado globalmente.

Solución alternativa: use el comando fsadm para comprobar el estado largefile del sistema de archivos, en lugar de la entrada /etc/mnttab.

Los nodos no pueden mostrar las rutas qfe (4526883)

Resumen del problema: algunas veces, las rutas privadas de transporte de interconexión que terminan en un adaptador qfe no aparecen en línea.

Solución alternativa: siga los pasos que se indican a continuación:

1. El uso de scstat -W identifica el adaptador que falla. La salida mostrará todas las rutas de transporte con ese adaptador como uno de los puntos finales de la ruta en los estados faulted o waiting.

2. Utilice scsetup para eliminar de la configuración del clúster todos los cables conectados con el adaptador.

3. Utilice scsetup de nuevo para suprimir ese adaptador de la configuración del clúster.

4. Vuelva a añadir el adaptador y los cables.

5. Compruebe si aparecen las rutas. Si el problema persiste, repita los pasos que van del 1 al 5 varias veces.

6. Compruebe si aparecen las rutas. Si el problema persiste aún, rearranque el nodo con el adaptador que falla. Antes de rearrancar el nodo, el resto del clúster debe tener suficientes votos del quórum para sobrevivir al rearranque del nodo.

Bloques de archivos no actualizados tras la escritura en huecos de archivos dispersos (4607142)

Resumen del problema: el recuento de un bloque de archivos no siempre es coherente en todos los nodos del clúster después de las operaciones de escritura para asignar bloques en un archivo disperso. En el caso de un sistema de archivos del clúster colocado en UFS (o VxFS 3.4), la incoherencia del bloque en los nodos del clúster desaparece en unos 30 segundos.

Solución alternativa: las operaciones de metadatos de archivos que actualizan el inode (touch, etc.) deben sincronizar el valor st_blocks de manera que las operaciones subsiguientes de metadatos aseguren la coherencia de los valores de st_blocks.

Durante un fallo en la red, el servicio de datos se inicia y detiene de manera incorrecta (4644289)

Resumen del problema: el servicio de datos de Sun Cluster HA para Oracle utiliza el comando su para iniciar y detener la base de datos. El servicio de la red puede que deje de estar disponible si una red pública del nodo del clúster falla.

Solución alternativa: en Solaris 9, configure los archivos /etc/nsswitch.conf de la manera siguiente, de modo que el servicio de datos se inicie y detenga correctamente en el caso de un fallo en la red:

En cada nodo que pueda ser primario para los recursos oracle_server u oracle_listener, modifique /etc/nsswitch.conf de manera que incluya las entradas siguientes para la contraseña, el grupo, la clave pública y las bases de datos de proyectos:

• passwd: files

• group: files

• publickey: files

• project: files

La adición de las entradas anteriores asegura que el comando su(1M) no se refiera a los servicios de nombres de NIS/NIS+.

El desmontaje de un sistema de archivos del clúster no se efectúa (4656624)

Resumen del problema: el desmontaje de un sistema de archivos del clúster falla en algunas ocasiones aunque el comando fuser muestre que no hay usuarios en ningún nodo.

Solución alternativa: vuelva a intentar el desmontaje después de que se hayan terminado todas las operaciones de E/S asíncronas en el sistema de archivos subyacente.

Sun Cluster HA–Siebel no consigue supervisar los componentes de Siebel (4722288)

Resumen del problema: el agente Sun Cluster HA-Siebel no supervisará los componentes individuales de Siebel. Si se detecta un fallo en un componente Siebel, sólo se registrará un mensaje de advertencia en syslog.

Solución alternativa: reinicie el grupo de recursos del servidor Siebel cuyos componentes estén fuera de línea mediante el comando scswitch -R -h nodo -g grupo_recursos.

Las instancias de Oracle RAC pueden dejar de estar disponibles en las notas recién añadidas (4723575)

Resumen del problema: la instalación de la admisión de Sun Cluster para RAC en un nodo recién añadido provocará que las instancias de Oracle RAC dejen de estar disponibles.

Solución alternativa: si desea añadir un nodo a un clúster que se ejecute con la admisión de Oracle RAC sin perder la disponibilidad de la base de datos de Oracle RAC son necesarios unos pasos especiales en la instalación. En el ejemplo siguiente se describe el proceso de pasar de un clúster de 3 nodos a uno de 4, con Oracle RAC ejecutándose en los nodos 1, 2 y 3:

1. Instale Sun Cluster en el nuevo nodo (nodo 4).

   Nota: no instale los paquetes de admisión de RAC en este momento.

2. Vuelva a arrancar el nuevo nodo en el clúster.

3. Cuando el nuevo nodo se haya unido al clúster, cierre la base de datos de Oracle RAC en uno de los nodos donde ya se esté ejecutando (nodo 1, en este ejemplo).

4. Rearranque el nodo donde la base de datos estaba simplemente cerrada (nodo 1).

5. Después de hacer una copia de seguridad del nodo (nodo 1), inicie la base de datos de Oracle en ese nodo para reanudar el servicio de la base de datos.

6. Si un único nodo es capaz de gestionar la carga de trabajo de la base de datos, cierre ésta en el resto de nodos (nodos 2 y 3) y rearranque éstos. Si se requiere más de un nodo para que admita la carga de trabajo de la base de datos, hágalos de uno en uno, como se describe en los pasos que van del 3 al 5.

7. Después de rearrancar todos los nodos se pueden instalar sin riesgos los paquetes de admisión de Oracle RAC en el nodo nuevo.

La secuencia remove no consigue anular el registro del tipo de recurso SUNW.gds (4727699)

Resumen del problema: la secuencia remove no consigue anular el registro del tipo de recurso SUNW.gds y muestra el mensaje siguiente:

Resource type has been un-registered already.

Solución alternativa: después del uso de la secuencia remove, anule manualmente el registro SUNW.gds. También puede utilizar el comando scsetup o SunPlex Manager.

El uso del comando shutdown de Solaris puede provocar un aviso grave del nodo (4745648)

Resumen del problema: el uso del comando shutdown o de comandos parecidos de Solaris (por ejemplo uadmin) para cerrar un nodo del clúster puede provocar un aviso grave del nodo y mostrar el mensaje siguiente:

CMM: Shutdown timer expired. Halting.

Solución alternativa: póngase en contacto con su representante de servicios de Sun para obtener asistencia. Este aviso grave es necesario para proporcionar una manera segura y garantizada para que otro nodo del clúster asuma los servicios que dispensaba el nodo que se está cerrando.

Tiempo de espera excedido en la ruta al usar los adaptadores ce en la interconexión privada (4746175)

Resumen del problema: los clústers que utilicen los adaptadores ce en la interconexión privada pueden advertir tiempos de espera excedidos en la ruta y subsiguientes avisos graves de los nodos si uno o más nodos del clúster tienen más de cuatro procesadores.

Solución alternativa: configure el parámetro ce_taskq_disable en el controlador ce añadiendo set ce:ce_taskq_disable=1 al archivo /etc/system en todos los nodos del clúster y rearrancando éstos después. De este modo se asegura que las transacciones (y otros paquetes) se entreguen siempre en el contexto de una interrupción, suprimiendo los tiempos de espera de las rutas y los posteriores avisos graves del nodo. Las consideraciones del quórum se deben tener en cuenta al arrancar los nodos del clúster.

El comando scrgadm evita que las direcciones IP de subredes diferentes residan en un NIC (4751406)

Resumen del problema: el comando scrgadm evita el alojamiento de nombres de sistemas lógicos o direcciones compartidas que pertenecen a una subred diferente de la del grupo IPMP (NAFO).

Solución alternativa: utilice el formulario siguiente del comando scrgadm:

scrgadm -a -j <resource> -t <resource_type> -g <resource_group> -x HostnameList=<logical_hostname> -x NetIfList=<nafogroup>@<nodeid>.

Observe que los nombres de los nodos no parecen funcionar en la NetIfList; utilice en su lugar identificadores de nodos (nodeid).

Recuperación de un fallo insatisfactoria (4766781)

Resumen del problema: una recuperación de fallos o una conmutación insatisfactoria de un sistema de archivos puede llevar a éste a un estado de error.

Solución alternativa: desmonte y vuelva a montar el sistema de archivos.

El nodo se bloquea después de rearrancarlo si hay una conmutación en progreso (4806621)

Resumen del problema: si la conmutación de un grupo de dispositivos está en progreso cuando un nodo se une al clúster, el nodo que se une y la conmutación se pueden bloquear. Cualquier intento de acceder a un servicio de dispositivos también se bloqueará. Es más probable que ocurra esto en un clúster con más de dos nodos y si el sistema de archivos montado en el dispositivo es un sistema de archivos VxFS.

Solución alternativa: para evitar esta situación, no inicie los conmutadores del grupo de dispositivos mientras un nodo se esté uniendo al clúster. Si esta situación se produce, todos los nodos del clúster se deben rearrancar para restaurar el acceso a los grupos de dispositivos.

El asistente de DNS falla si no se proporciona una configuración existente de DNS (4839993)

Resumen del problema: SunPlex Manager contiene una instalación de servicio de datos que configura un servicio de DNS altamente disponible en el clúster. Si el usuario no proporciona una configuración de DNS, como un archivo named.conf, el asistente intenta generar una configuración válida de DNS mediante la autodetección de una red y la configuración del servicio de nombres. No obstante, falla en algunos entornos de red, lo que provoca que el asistente falle sin emitir un mensaje de error.

Solución alternativa: cuando se le indique, proporcione al asistente de instalación del servicio de datos de DNS de SunPlex Manager un archivo named.conf válido. De lo contrario, siga los procedimientos documentados en el servicio de datos de DNS para configurar manualmente el DNS de alta disponibilidad del clúster.

Uso de SunPlex Manager para instalar un servicio de Oracle (4843605)

Resumen del problema: SunPlex Manager contiene un asistente de instalación para el servicio de datos que configura un servicio de Oracle realmente disponible en el clúster, mediante la instalación y configuración de los binarios de Oracle, así como la creación de la configuración del clúster. No obstante, el asistente de instalación no funciona en la actualidad y provoca varios errores según la configuración del software de los usuarios.

Solución alternativa: instale y configure manualmente el servicio de datos de Oracle en el clúster, mediante los procedimientos proporcionados en la documentación de Sun Cluster.

El cierre o el rearranque de la secuencia falla (4844784)

Resumen del problema: al cerrar o rearrancar un nodo, éste puede bloquearse y la secuencia de cierre o rearranque puede que no se complete. El sistema se bloquea después de emitir el mensaje siguiente: Failfast: Halting because all userland daemons all have died.

Solución alternativa: antes de cerrar o rearrancar el nodo, ejecute el comando siguiente: psradm -f -a:

Para cerrar un nodo:

1. # scswitch -S -h <node>

2. # psradm -f -a

3. # shutdown -g0 -y -i0

Para rearrancar un nodo:

1. # scswitch -S -h <node>

2. # psradm -f -a

3. # shutdown -g0 -y -i6

---

Nota –

En algunas instancias poco frecuentes, es posible que las soluciones alternativas sugeridas no consigan solucionar este problema.

---

Rearranque de un nodo (4862321)

Resumen del problema: en los sistemas grandes que ejecuten Sun Cluster 3.x el comando shutdown -g0 -y -i6, utilizado para rearrancar un nodo, puede hacer que el sistema vaya al indicador OK con el mensaje Failfast: Halting because all userland daemons have died, en vez de rearrancar.

Solución alternativa: utilice una de las soluciones alternativas siguientes:

• Detenga el nodo y escriba boot en el indicador ok.

• Desactive failfasts antes de rearrancar el nodo:

  # /usr/cluster/lib/sc/cmm_ctl -f

  # shutdown -g0 -y -i6

Recuerde volver a activar failfasts después de rearrancar el nodo:

# /usr/cluster/lib/sc/cmm_ctl -f

o aumente el tiempo de espera de failfast_panic_delay antes de cerrar el sistema, mediante el siguiente comando mdb:

(echo 'cl_comm`conf+8/W 0t600000' ;

echo 'cl_comm`conf+c/W 0t600000') | mdb -kw

De esta manera se ajusta el tiempo de espera en 600000 ms (10 minutos).

El proceso DLM de Oracle permanece activo durante el cierre del nodo (4891227)

Resumen del problema: el proceso DLM de Oracle no termina durante el cierre y evita que /var se desmonte.

Solución alternativa: utilice una de las dos soluciones alternativas siguientes:

• No utilice una partición separada de /var.

• Utilice reboot/halt en lugar de init o shutdown.

La sonda receptora de Oracle puede superar el tiempo de espera en un sistema con una gran carga (4900140)

Resumen del problema: la sonda receptora de Oracle puede superar el tiempo de espera en un sistema con gran carga, provocando que el receptor de Oracle se reinicie.

Solución alternativa: en un sistema con gran carga, los agotamientos del tiempo de espera de la sonda del recurso del receptor de Oracle se pueden evitar aumentando el valor de la propiedad Thorough_probe_interval del recurso.

El tiempo de espera de la sonda se calcula del modo siguiente:

10 segundos si Thorough_probe_interval es mayor de 20 segundos

60 segundos si Thorough_probe_interval es mayor de 120 segundos

Thorough_probe_interval/2 en otros casos

La actualización de la propiedad del grupo de recursos de RG_system puede desencadenar un aviso grave del nodo (4902066)

Resumen del problema: si está definido como TRUE, la propiedad del grupo de recursos de RG_system indica que el grupo de recursos y sus recursos se están utilizando para la admisión de la infraestructura del clúster, en lugar de implementar un servicio de datos del usuario. Si el valor de RG_system es TRUE, RGM evita que el administrador del sistema deje fuera de línea al grupo o a sus recursos o que modifique sus propiedades. En algunas instancias, el nodo puede producir avisos graves cuando se intenta modificar un grupo de recursos adecuadamente después de configurar correctamente la propiedad de RG_system como TRUE.

Solución alternativa: no modifique el valor de la propiedad del grupo de recursos de RG_system.

Requisitos de nsswitch.conf para que passwd convierta nis en no utilizable (4904975)

Resumen del problema: en cada nodo que pueda controlar el recurso liveCache, el comando su puede que se bloquee cuando la red pública se desconecte.

Solución alternativa: en cada nodo que pueda controlar el recurso liveCache, se recomiendan los cambios siguientes de /etc/nsswitch.conf, para que el comando su no se bloquee cuando la red pública esté desconectada:

passwd: files nis [TRYAGAIN=0]

Los asistentes de instalación del servicio de datos para Oracle y Apache no admiten Solaris 9 ni una versión superior (4906470)

Resumen del problema: los asistentes de instalación del servicio de datos de SunPlex Manager para Apache y Oracle no admiten Solaris 9 ni una versión superior.

Solución alternativa: instale manualmente Oracle en el clúster y consulte para ello la documentación de Sun Cluster. Si desea instalar Apache en Solaris 9 (o una versión superior), añada manualmente los paquetes de Apache para Solaris SUNWapchr y SUNWapchu antes de ejecutar el asistente de instalación.

La instalación falla si el dominio predeterminado no está configurado (4913925)

Resumen del problema: si añade nodos a un clúster durante la instalación y la configuración, puede que vea un fallo en la “autenticación de RPC“. Los mensajes de error son parecidos a los siguientes:

• “Eror de autentificación de RPC”

• “No está autorizado a comunicarse con <nodo patrocinador>”

• “La verificación del nombre de clúster no ha sido satisfactoria”

Esto sucederá cuando los nodos no estén configurados para utilizar NIS/NIS+, especialmente si el archivo /etc/defaultdomain no está presente.

Solución alternativa: si un nombre de dominio no está configurado (es decir, si no se encuentra el archivo /etc/defaultdomain), configure el nombre del dominio en todos los nodos que se unan al clúster, mediante el comando domainname(1M) antes de proceder con la instalación. Por ejemplo, # domainname xxx.