Sun Cluster 3.1 4/04 para Solaris: Notas sobre la versión

Problemas conocidos

Los siguientes problemas conocidos afectan al funcionamiento de la versión Sun Cluster 3.1.

Servicios de datos: Pautas para la instalación

Identifique los requisitos de todos los servicios de datos antes de comenzar con la instalación de Solaris y Sun Cluster. Si no especifica estos requisitos es posible que efectúe una instalación incorrecta y, en consecuencia, se vea obligado a reinstalar completamente Solaris y Sun Cluster.

Por ejemplo, la opción Oracle Parallel Fail Safe/Real Application Clusters Guard de Parallel Server/Real Application Clusters de Oracle tiene requisitos especiales para los nombres de los nodos o de los sistemas que se utilizan en un clúster. Debe tener en cuenta estos requisitos antes de instalar el software Sun Cluster porque no puede cambiar los nombres de los sistemas después de instalar el software Sun Cluster. Si desea obtener más información sobre los requisitos especiales de los nombres de los nodos o de los sistemas, consulte la documentación de Oracle Parallel Fail Safe/Real Application Clusters Guard.

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: siga los pasos que se indican a continuación:

Con scstat -W, identifique el adaptador que falle. 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.
Utilice scsetup para suprimir de la configuración del clúster todos los cables conectados con el adaptador.
Utilice scsetup de nuevo para suprimir ese adaptador de la configuración del clúster.
Vuelva a añadir el adaptador y los cables.
Compruebe si aparecen las rutas. Si el problema persiste, repita los pasos que van del 1 al 5 varias veces.
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.

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: después del uso de la secuencia remove, anule manualmente el registro SUNW.gds. También puede utilizar la orden scsetup o SunPlex Manager.

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 emitir subsiguientes avisos graves de los nodos si uno o más nodos del clúster tienen más de cuatro procesadores.

Solución: 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 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: 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: 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: 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.

No es posible añadir el adaptador al grupo IPMP después de la supresión (4884060)

Resumen del problema: si se usa SunPlex Manager para suprimir un adaptador de un grupo IPMP de varios adaptadores, puede que no siempre sea posible añadir de nuevo el adaptador suprimido al mismo grupo inmediatamente.

Solución: borre /etc/hostname.adapter antes de intentar añadir de nuevo el adaptador al mismo grupo IPMP.

La versión del shell de `scds_syslog` no usa el recurso `LOG_DAEMON` (4897239)

Resumen del problema: debido a un error interno, la mayoría de los agentes de clústers suministrados por Sun están escribiendo mensajes en el registro del sistema (consulte syslog(3C)) mediante el recurso LOG_USER en vez de usar LOG_DAEMON. En un clúster que está configurado con los valores predeterminados del registro del sistema (consulte syslog.conf(4)), los mensajes con una gravedad de LOG_WARNING o LOG_NOTICE, que normalmente se escribirían en el registro del sistema, no se visualizan.

Solución: añada la línea siguiente cerca de la parte frontal del archivo /etc/syslog.conf en todos los nodos del clúster:

user.warning			/var/adm/messages

De este modo se registrarán los mensajes user.warning. Se puede añadir una línea similar a los mensajes user.notice, pero no es necesario y puede provocar que los registros se llenen demasiado rápido, según la mezcla de aplicaciones que se esté ejecutando.

Los requisitos de `nsswitch.conf` para `passwd` hacen que la orden `nis` sea inutilizable (4904975)

Resumen del problema: los requisitos del archivo nssswitch.conf en “Preparing the Nodes and Disks” in Sun Cluster Data Service for SAP liveCache Guide for Solaris OS no se aplican a la entrada de la base de datos de passwd. Si se cumplen estos requisitos, la orden su se podría bloquear en cada nodo que pueda controlar el recurso liveCache cuando la red pública esté abierta.

Solución: en cada nodo que pueda controlar el recurso liveCache, la entrada del archivo /etc/nsswitch.conf de la base de datos passwd debe ser:

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: 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.

Aviso grave del nodo después de que un nodo rearranque como parte de la encapsulación de `scvxinstall` (4931910)

Resumen del problema: los tiempos inadecuados de los rearranques del nodo del clúster durante la encapsulación del disco raíz pueden provocar la aparición de avisos graves.

Solución: ejecute scvxinstall en un sólo nodo y espere a que un nodo haya terminado todos sus rearranques antes de iniciar scvxinstall en otro nodo.

El tamaño predeterminado de la ventana de SunPlex Agent Builder en los entornos nacionales que no son el inglés es demasiado pequeño (4937877)

Resumen del problema: al ejecutar SunPlex Agent Builder en un entorno nacional que no sea inglés, el tamaño predeterminado de la ventana es demasiado pequeño y es posible que los controles no aparezcan en ésta. Se ha observado este problema en los entornos nacionales español y alemán.

Solución: cambie manualmente el tamaño de la ventana de SunPlex Agent Builder según se necesite.

La orden `sccheck` se bloquea si se ejecuta simultáneamente en varios nodos (4944192)

Resumen del problema: es posible que la orden sccheck se bloquee si se inicia simultáneamente desde varios nodos.

Solución: no inicie la orden sccheck desde una consola múltiple que pase órdenes a varios nodos. Las ejecuciones de sccheck se pueden solapar, pero ésta no se debe iniciar simultáneamente.

`scinstall -r` no suprime los paquetes de servicios de datos de los entornos nacionales (4955294)

Resumen del problema: scinstall -r no suprime los paquetes de servicios de datos específicos de los entornos nacionales.

Solución: cuando aparezca el nodo, ejecute pkginfo | grep -i cluster para asegurarse de que todos los paquetes de servicios de datos se hayan suprimido. Si desea suprimir los paquetes enumerados, ejecute pkgrm en cada paquete.

Aparece un idioma en el entorno nacional del chino tradicional que no corresponde (4955538)

Resumen del problema: algunos mensajes del SunPlex Agent Builder del entorno nacional del chino tradicional aparecen en chino simplificado.

Solución: ejecute SunPlex Agent Builder en el entorno nacional zh_TW para que se muestren correctamente los mensajes en chino tradicional.

Los archivos binarios de Java enlazados con una versión incorrecta de Java pueden provocar que el agente HADB funcione incorrectamente (4968899)

Resumen del problema: si se invoca hadbm desde el agente HADB, toma los archivos binarios de /usr/bin. El agente HADB no consigue trabajar adecuadamente, puesto que se deben enlazar los archivos binarios de java en /usr/bin con la versión adecuada de Java 1.4 (o superior).

Solución: asigne la variable de entorno JAVA_HOME a la versión adecuada de Java 1.4 (o superior) en la secuencia de órdenes /opt/SUNWappserver7/SUNWhadb/4/bin/hadbm.

`scsetup` no es capaz de añadir el primer adaptador a un clúster de un único nodo (4983095)

Resumen del problema: si se utiliza scsetup en un intento de añadir el primer adaptador a un clúster de un único nodo, aparece el mensaje de error siguiente: Unable to determine transport type.

Solución: configure manualmente al menos el primer adaptador:

# scconf -a -A trtype=tipo,name=nombre_nodo,node=nombre_nodo

Tras configurar el primer adaptador, use la orden scsetup para configurar los trabajos de interconexión, como se espera.

Algunos servicios de datos no se pueden modernizar mediante la utilidad `scinstall`

Resumen del problema: los servicios de datos de las aplicaciones siguientes no se pueden modernizar mediante la utilidad scinstall:

Apache Tomcat
DHCP
mySQL
Oracle E-Business Suite
Samba
SWIFTAlliance Access
Servidor WebLogic
WebSphere MQ
WebSphere MQ Integrator

Solución: si planea modernizar un servicio de datos para una aplicación en la lista precedente, sustituya el paso para modernizar servicios de datos de la sección “Modernización del software Sun Cluster 3.1 4/04 (periódica)” en Software Sun Cluster: Guía de instalación para el sistema operativo Solaris con los pasos que siguen. Siga estos pasos en cada nodo donde estén instalados los servicios de datos.

Suprima el paquete de software del servicio de datos que esté modernizando.

# pkgrmpaq-inst

paq-inst especifica el nombre del paquete de software del servicio de datos que va a modernizar, como se indica en la tabla siguiente.

Aplicación	Paquete de software del servicio de datos
Apache Tomcat	`SUNWsctomcat`
DHCP	`SUNWscdhc`
mySQL	`SUNWscmys`
Oracle E-Business Suite	`SUNWscebs`
Samba	`SUNWscsmb`
SWIFTAlliance Access	`SUNWscsaa`
Servidor WebLogic (entorno nacional inglés)	`SUNWscwls`
Servidor WebLogic (entorno nacional francés)	`SUNWfscwls`
Servidor WebLogic (entorno nacional japonés)	`SUNWjscwls`
WebSphere MQ	`SUNWscmqs`
WebSphere MQ Integrator	`SUNWscmqi`

Instale el paquete de software para la versión del servicio de datos cuya modernización está efectuando.

Si desea instalar el paquete de software, siga las instrucciones de la documentación de Sun Cluster relacionada con los servicios de datos que está modernizando. Esta documentación está disponible en http://docs.sun.com.

El método de parada de HA Oracle excede el tiempo de espera (4644289)

Resumen del problema: el servicio de datos de Sun Cluster HA para Oracle utiliza la orden del superusuario, su(1M), para iniciar y detener la base de datos. Si ejecuta Solaris 8 o Solaris 9, es posible que el servicio de red no quede disponible cuando falle una red pública de un nodo del clúster.

Solución: incluya estas entradas en los archivos de configuración de /etc/nsswitch.conf en cada nodo que pueda ser el principal para los recursos oracle_server o oracle_listener:

passwd: files
groups: files
publickey: files
project:  files

Estas entradas aseguran que la orden su no se refiera a los servicios de nombres NIS/NIS+, de modo que el servicio de datos se inicie y se detenga correctamente durante un fallo en la red.

Tiempo de espera del método de parada de SAP liveCache excedido (4836272)

Resumen del problema: El servicio de datos de Sun Cluster HA para SAP liveCache usa la orden dbmcli para iniciar y detener liveCache. Si ejecuta Solaris 9, es posible que el servicio de red no quede disponible cuando falle una red pública de un nodo del clúster.

Solución: incluya una de estas entradas de la base de datos publickey en los archivos de configuración /etc/nsswitch.conf en cada nodo que pueda ser el principal para los recursos liveCache:

publickey:
publickey:  files
publickey:  files [NOTFOUND=return] nis
publickey:  files [NOTFOUND=return] nisplus

La adicion de una de las entradas anteriores, además de las actualizaciones documentadas en Sun Cluster Data Service for SAP liveCache Guide for Solaris OS asegura que las órdenes su y dbmcli no se refieran a los servicios de los nombres NIS/NIS+. Si se sobrepasan los servicios de nombres NIS/NIS+ se asegura que el servicio de datos se inicie y se detenga correctamente durante un fallo en la red.

HA-Siebel no se reinicia automáticamente debido a errores en los componentes de Siebel (4722288)

Resumen del problema: Sun Cluster HA para Siebel no supervisa los componentes individuales de Siebel. Si se detecta un error en alguno de ellos, sólo se registra un mensaje de aviso en syslog (registro del sistema).

Solución: reinicie el grupo de recursos del servidor de Siebel en el que los componentes estén fuera de línea mediante la orden scswitch -R -h nodo -g grupo_recursos.