Los siguientes problemas conocidos afectan al funcionamiento de la versión Sun Cluster 3.1.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
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]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.