Los siguientes problemas conocidos afectan al funcionamiento de la versión Sun Cluster 3.1 9/04.
Resumen del problema: scvxinstall crea entradas incorrectas vfstab cuando el dispositivo de arranque tiene varias rutas.
Solución: ejecute scvxinstall y seleccione la opción de encapsulación. Cuando aparezca el siguiente mensaje, pulse Ctrl-C para anular el reinicio:
este nodo se reiniciará en 20 segundos. Pulse Ctrl-C para anular la operación. |
Edite la entrada vfstab para que /global/.devices use el nombre /dev/{r}dsk/cXtXdX en lugar de /dev/did/{r}dsk. Esta entrada modificada permite reconocer VxVM como el disco raíz. Vuelva a ejecutar scvxinstall y seleccione la opción de encapsulación. El archivo vfstab tiene las actualizaciones necesarias. Permita que se lleve a cabo el reinicio. La encapsulación se realiza de forma normal.
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. 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 el archivo /etc/nsswitch.conf de cada nodo que pueda ser el principal para los recursos oracle_server u oracle_listener:
passwd: files groups: files publickey: files project: files
Estas entradas garantizan que la orden su no haga referencia 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: los clústeres 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 CPU.
Solución: defina el parámetro ce_taskq_disable en el adaptador ce agregando la siguiente línea al archivo /etc/system en todos los nodos del clúster.
set ce:ce_taskq_disable=1
A continuación, reinicie los nodos del clúster. Tenga en cuenta el quórum al reiniciar los nodos del clúster. Al definir este parámetro, se asegura de que las transacciones (y otros paquetes) se entreguen siempre en el contexto de una interrupción, suprimiendo así los tiempos de espera de las rutas y los posteriores avisos graves del nodo.
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 /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 adición de una de las entradas anteriores, además de las actualizaciones documentadas en Sun Cluster Data Service for SAP liveCache Guide for Solaris OS, aseguran que las órdenes su y dbmcli no se refieran a los servicios de 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: debido a un error interno, algunos de los agentes de clústeres suministrados por Sun escriben mensajes en el registro del sistema mediante el recurso LOG_USER en vez de usar LOG_DAEMON. Consulte syslog(3C). En un clúster que esté configurado con los valores predeterminados del registro del sistema, los mensajes con una gravedad de LOG_WARNING o LOG_NOTICE, que normalmente se escribirían en el registro del sistema, no se visualizan. Consulte syslog.conf(4). Este problema sólo se produce con el código de agente escrito como secuencias de órdenes de shell.
Solución:
La siguiente solución está destinada a los programadores de agentes que escriben secuencias de órdenes de shell:
En las secuencias de órdenes shell, cambie la utilidad explícitamente a scds_sylog:
facility=`scha_cluster_get -O SYSLOG_FACILITY
'scds_syslog -p ${facility}.error -m "error message"
La siguiente solución es para los administradores del clúster:
Añada la siguiente línea cerca de la parte frontal del archivo /etc/syslog.conf en todos los nodos del clúster:
user.warning /var/adm/messages
Esta entrada provoca que se registren los mensajes de user.warning. 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, en función de la mezcla de aplicaciones que se esté ejecutando.
Resumen del problema: los requisitos del archivo nsswitch.conf en el apartado dedicado a la preparación de los nodos y los discos de Sun Cluster Data Service for SAP liveCache Guide for Solaris OS no se aplican a la entrada para la base de datos 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: sccheck puede bloquearse 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 no se deben iniciar simultáneamente.
Resumen del problema: actualmente, el servicio de datos HA-DB no utiliza la variable de entorno JAVA_HOME. En consecuencia, HA-DB, cuando se ejecuta desde el servicio de datos HA-DB, usa los binarios Java de /usr/bin/. Los binarios Java de /usr/bin/ deben estar enlazados con la versión adecuada de Java 1.4 (o superior) para que el servicio de datos HA-DB funcione correctamente.
Solución: si no le importa cambiar la versión predeterminada disponible, realice el siguiente procedimiento. Por ejemplo, esta solución presupone que el directorio /usr/j2se es la ubicación en la que reside la versión más reciente de Java (como 1.4 y superior).
¿Tiene actualmente un directorio denominado java/ en el directorio /usr/? Si es así, muévalo a una ubicación temporal.
En el directorio /usr/, enlace /usr/bin/java (y todos los demás binarios relacionados con Java) con la versión adecuada de Java.
# ln -s j2se java |
Si no desea cambiar la versión predeterminada disponible, relacione la variable de entorno JAVA_HOME con la versión adecuada de Java (J2SE 1.4 y superiores) en la secuencia de órdenes /opt/SUNWappserver7/SUNWhadb/4/bin/hadbm.
Resumen del problema: Debido al error 4974875, cada vez que se realiza una recuperación automática, la base de datos se reinicializa sin elementos de reserva. El error mencionado anteriormente se ha solucionado e integrado en la versión 4.3 de HA-DB. Para HA-DB 4.2 y versiones inferiores, siga uno de los procedimientos descritos a continuación para cambiar los roles de los nodos de HA-DB.
Solución:
Identifique los nodos de HA-DB para los que se han cambiado sus roles tras una recuperación automática con éxito.
En todos los nodos identificados en el paso 1, desactive el supervisor de errores del recurso HA-DB en cuestión, en un nodo cada vez.
# cladm noderole -db dbname -node nodeno -setrole role-before-auto_recovery |
Active el supervisor de errores del recurso HA-DB en cuestión.
o
Identifique los nodos de HA-DB para los que se han cambiado sus roles tras una recuperación automática con éxito.
En todos los nodos que albergan la base de datos, desactive el supervisor de errores para el recurso HA-DB en cuestión.
En cualquiera de los nodos, ejecute la orden para cada nodo de HA-DB que necesite modificar su rol.
# cladm noderole -db dbname -node nodeno -setrole role-before-auto_recovery |
Resumen del problema: durante una actualización por turnos, si se ejecuta la orden scstat -i en un nodo del clúster, que aún no se ha actualizado, el resultado de scstat no mostrará el estado de los grupos IPMP alojados en los nodos que ya han sido actualizados.
Solución: use el resultado de scstat -i en los nodos actualizados.
Resumen del problema: no se puede añadir un recurso LogicalHostname al clúster si utiliza un grupo IPMP con un adaptador que presenta un error.
Solución: Elimine el adaptador con errores del grupo IPMP o corrija el error antes de intentar usar el gupo IPMP en un recurso LogicalHostname.
Resumen del problema: los dos campos, Status y Type, de la página de estado de los grupos de recursos muestran valores en la primera configuración regional que se usó para ver la página.
Solución: para ver los valores en una configuración regional diferente, reinicie el servidor Web.
Resumen del problema: después de encapsular el disco raíz, si anula su encapsulación y después vuelve a establecerla, es posible que vea que un volumen llamado uservol se utiliza para el sistema de archivos /global/devices/node@nodeID. Esto puede provocar problemas, ya que el nombre de volumen del sistema de archivos de los dispositivos globales de cada nodo debe ser único.
Solución: después de llevar a cabo los pasos documentados para deshacer la encapsulación, finalice el daemon vxconfigd antes de ejecutar de nuevo scvxinstall para volver a encapsular el disco raíz.
Resumen del problema: al iniciar sesión en Sun Web Console, si se pulsa varias veces el botón de inicio de sesión o Intro, las diversas solicitudes de inicio de sesión pueden provocar fallos e impedir el acceso a SunPlex Manager.
Solución: conviértase en superusuario en el nodo del clúster y reinicie Sun Web Console.
# /usr/sbin/smcwebserver restart |
Resumen del problema: la propiedad de recurso Resource_dependencies_restart no se comporta como cabe esperar cuando un recurso declara dependencias de grupo, entre recursos y de reinicio del tipo any node con respecto a un recurso en modo escalable. Este problema no afecta a la mayoría de los servicios de datos.
Información sobre las dependencias de grupo y entre recursos–y las dependencias de reinicio:
Si utiliza la función de dependencias de grupo– y entre recursos en Sun Cluster 3.1 9/04,el software Sun Cluster admite las dependencias de recursos que pueden sobrepasar los límites del grupo de recursos. El sofware Sun Cluster también admite un nuevo tipo de dependencia de recursos, la dependencia de reinicio. Si el recurso dependiente está en línea, la dependencia de reinicio permite reiniciar automáticamente este recurso cuando se inicia el recurso del que depende.
Información sobre las dependencias local node frente a las dependencias any node:
Si el recurso r1 del grupo RG1 tiene una dependencia con respecto a r2 de RG2 y, si RG1 tiene una afinidad positiva con RG2 y, si ambos (RG1 y RG2) se inician o se detienen simultáneamente en el mismo nodo, entonces la dependencia entre r1 y r2 se puede calificar como local node. Por ejemplo, si se inician RG1 y RG2 en el mismo nodo, r1 esperará a que r2 se inicie en ese nodo antes de iniciarse r1 en el mismo nodo. El estado de r2 en los demás nodos no influye en el inicio de r1.
No obstante, si RG1 no muestra una afinidad positiva con RG2, o si la afinidad es positiva pero débil, y los grupos de recursos se inician en nodos diferentes, entonces la dependencia de r1 con respecto a r2 es del tipo any node. Esta dependencia implica que r1 se iniciará cuando r2 se haya iniciado en cualquier otro nodo.
Descripción del problema:
El problema surge cuando el grupo de recursos RG2 pertenece al modo escalable (es decir, está controlado desde varios lugares) y la dependencia de r1 con respecto a r2 es una dependencia de reinicio any node. r1 se reinicia cada vez que se inicia alguna instancia de r2. r1 debería reiniciarse sólo al iniciarse la primera instancia de r2.
Solución: el comportamiento actual de las dependencias de reinicio cambiará como se ha descrito anteriormente cuando se solucione el error. No desarrolle procedimientos administrativos o código que dependa del comportamiento incorrecto actual.
Resumen del problema: si dispone de un servidor Sun Enterprise 15000 y ejecuta la orden sccheck, la comprobación falla y se registra un error en el que se indica que no se admite Sun Enterprise 15000. Esta afirmación no es correcta.
Solución: no es necesario solucionar el problema. El sofware Sun Cluster admite el servidor Sun Enterprise 15000. El error del que informa la orden sccheck indica que la comprobación puede haber caducado. En este caso, sccheck está desfasado.
Resumen del problema: no se puede seleccionar el francés (fr) como idioma para los agentes de servicios de datos que no formen parte de Sun Java Enterprise System. Sin embargo, el programa de instalación gráfico (GUI) de esos paquetes sugerirá lo contrario.
Solución: ignore la inexactitud del programa de instalación gráfico. El idioma francés (fr) no está disponible.
Resumen del problema: durante la actualización del software a Sun Cluster 3.1 9/04, la orden scinstall instala nuevos paquetes contenedor de agentes comunes (SUNWcacao y SUNWcacaocfg) pero no distribuye claves de seguridad idénticas a todos los nodos del clúster.
Solución: realice los siguientes pasos para asegurarse de que los archivos de seguridad contenedor de agentes comunes sean idénticos en todos los nodos del clúster y los archivos copiados conserven los permisos correctos. Estos archivos son necesarios para el software Sun Cluster.
En un nodo del clúster, acceda al directorio /etc/opt/SUNWcacao/.
phys-schost-1# cd /etc/opt/SUNWcacao/ |
Cree un archivo tar del directorio /etc/opt/SUNWcacao/security/.
phys-schost-1# tar cf /tmp/SECURITY.tar security |
Copie el archivo /tmp/SECURITY.tar en todos los nodos del clúster.
En cada nodo en el que haya copiado el archivo /tmp/SECURITY.tar, extraiga los archivos de seguridad.
Todos los archivos de seguridad que haya en el directorio /etc/opt/SUNWcacao/ se sobrescribirán.
phys-schost-2# cd /etc/opt/SUNWcacao/ phys-schost-2# tar xf /tmp/SECURITY.tar |
Elimine el archivo /tmp/SECURITY.tar de todos los nodos del clúster.
Debe eliminar cada copia del archivo tar para no poner en riesgo la seguridad.
phys-schost-1# rm /tmp/SECURITY.tar phys-schost-2# rm /tmp/SECURITY.tar |
En cada nodo, reinicie el agente del archivo de seguridad.
# /opt/SUNWcacao/bin/cacaoadm start |
Resumen del problema: el campo de fecha del panel de filtro avanzado de SunPlex Manager sólo acepta el formato mm/dd/aaaa. No obstante, en las configuraciones regionales no inglesas, el formato de fecha es distinto de mm/dd/yyyy y el formato de fecha que se muestra en el panel del calendario no aparece como mm/dd/yyyy.
Solución: escriba el intervalo de fechas en el panel de filtro avanzado con el formato mm/dd/aaaa. No use el botón Establecer para mostrar el calendario y elegir la fecha.
Resumen del problema: si elimina un grupo de recursos con SunPlex Manager en Solaris 8, es posible que reciba mensajes de error imposibles de leer. Este problema se produce con las siguientes configuraciones regionales: japonés, coreano, chino tradicional y chino simplificado.
Solución: ejecute la configuración regional del sistema en inglés para mostar los mensajes de error en este idioma.
Resumen del problema: en el archivo de registro de tipo de recurso (RTR) SUNW.sapscs, las descripciones de las dos propiedades de extensión son incorrectas.
Solución: la descripción de Scs_Startup_Script debe ser Startup script for the SCS. Defaults to /usr/sap/SAP_SID/SYS/exe/run/startsap. La descripción de Scs_Shutdown_Script debe ser Shutdown script for the SCS. Defaults to /usr/sap/SAP_SID/SYS/exe/run/stopsap.
Resumen del problema: después de instalar el software Sun Cluster con el método JumpStart, Sun Web Console no puede iniciar SunPlex Manager. El procesamiento de la instalación posterior con JumpStart no puede registrar con éxito SunPlex Manager. con Sun Web Console.
Solución: ejecute la siguiente secuencia de órdenes después de que se haya completado en todos los nodos la instalación del software Sun Cluster mediante JumpStart.
# /var/sadm/pkg/SUNWscspmu/install/postinstall |
Esta secuencia de órdenes registra SunPlex Manager con Sun Web Console.
Resumen del problema: el programa de instalación del CD-ROM de servicios de datos de Sun Cluster 3.1 9/04 para x86 no se puede usar para instalar HA Oracle. El programa de instalación muestra el siguiente mensaje:
Could not find child archive ....
Solución: use scinstall para instalar Sun Cluster Data Service for HA Oracle.
Resumen del problema: los servicios de datos de las aplicaciones siguientes no se pueden actualizar mediante la utilidad scinstall:
Apache Tomcat
DHCP
mySQL
Oracle E-Business Suite
Samba
SWIFTAlliance Access
WebLogic Server
WebSphere MQ
WebSphere MQ Integrator
Solución: si desea actualizar un servicio de datos para una aplicación de la lista anterior, sustituya los pasos de actualización de servicios de datos descritos en Modernización del software Sun Cluster 3.1 9/04 (periódica) de Software Sun Cluster: Guía de instalación para el sistema operativo Solaris por los pasos siguientes. 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 actualizar, 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/.