Este apartado describe información adicional importante acerca de la implementación de HADB incluida en Application Server 8.2.
El nuevo comando de administración hadbm setadminpassword se ha implementado para que sea posible cambiar la contraseña utilizada para la administración de la base de datos. El comando adopta opciones que indican qué agente de administración se debe usar y cuál es la contraseña nueva y la antigua. Para obtener más información, consulte la página de comando man hadbm setadminpassword.
El comando de administración existente hadbm listpackages se ha modificado. Anteriormente el comando no adoptaba operandos y enumeraba todos los paquetes del dominio de administración pertinente. Las modificaciones introducen un operando de nombre de paquete opcional, que muestra una lista que contiene sólo los paquetes con dicho nombre. Si no se especifica el operando, se mostrarán todos los paquetes. Para obtener más información, consulte la página de comando man hadbm listpackages.
El comando de administración existente hadbm createdomain se ha modificado. El operando hostlist se ha ampliado para que especifique también el número de puerto del agente de administración. De este modo, el dominio se especifica completamente usando sólo el operando hostlist. El comportamiento anterior todavía se admite para conseguir compatibilidad con versiones anteriores. Para obtener más información, consulte la página de comando man hadbm createdomain.
Algunos mensajes de error del sistema de administración se han modificado. Las modificaciones están destinadas a mejorar la comprensión, la coherencia y la precisión de los mensajes de error. Las modificaciones en sí no se indican en estas notas de la versión.
Los comportamientos de instalación y desinstalación se han modificado levemente. La instalación y la desinstalación de HADB deben conservar siempre los archivos softlink /opt/SUNWhadb/4, pero éste no siempre ha sido el caso.
La posibilidad de introducir contraseñas en la línea de comandos como opciones de comando ya no se admite. Esto es relevante para todos los comandos hadbm que usen contraseñas como opciones de la línea de comandos. En los comandos hadbm, antes era posible introducir una contraseña en forma de:
Un archivo de contraseña
Una opción de línea de comandos
Una entrada interactiva
El método 2, la opción de la línea de comandos, no se considera seguro y, en consecuencia, ha quedado obsoleto. Se muestra un mensaje de advertencia en el caso de que se introduzca una contraseña de este modo. En su lugar, use el método 1, un archivo de contraseña, o bien el método 3, la salida interactiva. El uso de una contraseña en la línea de comandos quedará obsoleto en la siguiente versión. Tenga en cuenta que esto es aplicable a todos los comandos hadbm que admiten una contraseña en la línea de comandos.
HADB se ha actualizado para que pueda usar JGroups Versión 2.2, y su código fuente se distribuye junto con HADB. Para que sea posible realizar una actualización en línea desde una versión anterior de HADB, tanto JGroups 2.1 como 2.2 se proporcionan con HADB. Para JGroups 2.1, se proporciona sólo la codificación de bytes.
Hay varias consideraciones importantes que hay que tener en cuenta a la hora de configurar HADB para que utilice uno de los siguientes sistemas de archivos:
ext2 y ext3: HADB es compatible con los sistemas de archivos ext2 y ext3 para Red Hat Application Server 3.0. En la versión Red Hat Application Server 2.1, HADB admite sólo el sistema de archivos ext2.
Veritas: si se usa el sistema de archivos Veritas en una plataforma Solaris, se incluirá el siguiente mensaje en el archivo de historial “WRN: Direct disk I/O mapping failed (WRN: error en la asignación de E/S directa de disco). Este mensaje indica que HADB no puede activar la función de E/S directa de los datos y los dispositivos de registro. La entrada o salida directa es una mejora en el rendimiento que reduce el coste de la CPU al escribir páginas de disco. Esto también provoca que haya una menor carga para administrar las páginas de datos no útiles en el sistema operativo.
Para usar la función de E/S directa con el sistema de archivos Veritas, siga uno de estos procedimientos:
Cree los datos y los dispositivos de registro en un sistema de archivos que esté montado con la opción mincache=direct. Esta opción se aplica a todos los archivos creados en el sistema de archivos. Consulte el comando mount_vxfs(1M) para obtener más detalles.
Use la utilidad Veritas Quick I/O para realizar entradas y salidas sin formato en los archivos del sistema de archivos. Consulte VERITAS File System 4.0 Administrator's Guide for Solaris para obtener más información.
Tenga en cuenta que estas configuraciones no han sido probadas con Application Server 8.2.
Consulte Application Server Edición Enterprise High Availability Administration Guide para obtener información sobre la instalación y la configuración de HADB con el software Application Server.
Los usuarios deben conservar los archivos del historial de HADB, los archivos de configuración del agente de administración, los archivos de registro y el repositorio y todos los dispositivos de datos externos a la ruta de instalación. De lo contrario, esto se debe hacer antes de la actualización. Para mover el repositorio de administración y los archivos de configuración:
Detenga todos los agentes de administración antiguos y deje los nodos de HADB ejecutándose.
En cada host, mueva el directorio del repositorio a la nueva ubicación.
En cada host, copie el directorio dbconfig en la nueva ubicación.
En cada host, actualice el archivo mgt.cfg y defina la ruta correcta para dbconfig y el directorio del repositorio.
Inicie los agentes de administración usando el archivo actualizado mgt.cfg.
Para actualizar de la versión 4.4.x de HADB a la versión 4.4.3, lleve a cabo el siguiente procedimiento:
Realice las tareas previas a la actualización mencionadas anteriormente si es necesario.
Instale la versión 4.4.3 de HADB en todos los hosts de HADB (en una ruta distinta de la de la versión 4.4.x, por ejemplo, en /opt/SUNWhadb/4.4.3).
Instale la versión 4.4.3 de HADB en los hosts del cliente hadbm, en caso de que sean diferentes de los de los hosts de HADB.
Detenga todos los agentes de administración que se estén ejecutando en todos los hosts de HADB.
Inicie los procesos del agente de administración usando el software de la nueva versión, pero con los archivos de configuración antiguos. En los pasos que quedan, utilice el comando hadbm que se incluye en el directorio bin de la nueva versión.
Registre el paquete en el dominio de administración (el nombre del paquete predeterminado pasa a ser V4.4, por lo que será necesario utilizar otro nombre de paquete para evitar conflictos con los paquetes existentes que tengan el mismo nombre):
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.3 V4.4.3 |
Ejecute el comando hadbm listpackages y compruebe que el nuevo paquete esté registrado en el dominio.
Reinicie la base de datos con la nueva versión 4.4.3 de hadbm. Si es necesario mover los dispositivos y los archivos del historial, ejecute la actualización en línea junto con la definición de nuevas rutas para los dispositivos y los archivos del historial en una única operación:
hadbm set packagename=V4.4.3,devicepath=new_devpath, historypath=new_histpath |
De lo contrario, si los dispositivos y los archivos del historial están ya fuera del directorio de instalación, ejecute el siguiente comando, que sólo realiza un reinicio por turnos de los nodos:
hadbm set packagename=V4.4.3 database name |
Compruebe que la base de datos esté ejecutándose (para ello, use el comando hadbm status) y que funcione normalmente, atendiendo las transacciones de los clientes.
Si todo está funcionando, la instalación antigua podrá eliminarse posteriormente. Antes de anular el registro del paquete antiguo, elimine del depósito ma todas las referencias al mismo. De lo contrario, hadbm unregisterpackage fallará y mostrará un error que indica que el paquete está en uso ("package in use").Una operación de reconfiguración ficticia, por ejemplo, hadbm set connectiontrace=same as previous value, eliminará todas las referencias al paquete antiguo. Ahora, proceda a anular el registro del paquete antiguo:
hadbm unregisterpackage [--hosts=host-list] old pacakge name |
Elimine la instalación antigua del sistema de archivos.
En Solaris, para probar que la actualización es correcta, compruebe si la actualización se ha realizado correctamente:
Asegúrese de que los procesos que se estén ejecutando usen los nuevos binarios. Compruebe lo siguiente en todos los nodos de HADB:
new path/bin/ma -v new path/bin/hadbm -v |
Compruebe si se está ejecutando la base de datos. El siguiente comando debería mostrar que todos los nodos de HADB se están “ejecutando”.
new path/bin/hadbm status -n |
Asegúrese de que los productos que usen HADB hayan cambiado sus punteros para que señalen a la nueva ruta de HADB.
Los productos que usan HADB pueden ejecutar sus pruebas de actualización para verificar que la actualización de HADB también está funcionando.
Después de realizar una actualización en línea, si la nueva versión no funciona correctamente, vuelva a usar la versión anterior de HADB. Sin embargo, si ha habido un cambio en el repositorio del agente de administración, será posible volver a una versión anterior de HADB, pero el nuevo agente de administración deberá estar ejecutándose.
En este apartado se incluye información adicional acerca de la actualización y la implementación de HADB.
El dispositivo de almacenamiento, y los archivos de registro y de historial de los discos sólo locales no utilizan sistemas de archivos montados de forma remota.
Si hay más de un nodo en un host, se recomienda que los dispositivos de cada nodo estén en discos diferentes. De lo contrario, la contención del disco podría reducir el rendimiento. Los indicios de este problema se pueden ver en los archivos del historial mediante mensajes como, por ejemplo, BEWARE - last flush/fputs took too long (ATENCIÓN: los últimos vaciados/entradas tardaron demasiado tiempo). Cuando un único nodo tiene más de un archivo de dispositivos de datos, se recomienda usar distintos discos para dichos archivos de dispositivos.
Use los discos locales (preferiblemente discos separados de los que se usan para los dispositivos de datos) para instalar binarios de HADB en los hosts de HADB. La contención del disco o los retrasos de NFS podrían provocar que se reinicie el nodo, con el mensaje de advertencia, "Process blocked for nnn, max block time is nnn" (Proceso bloqueado durante nnn; tiempo máximo de bloqueo, nnn) en los archivos del historial.
No coloque los dispositivos de HADB, los archivos de historial, los directorios del agente de administración y los archivos de configuración del agente en la ruta del paquete HADB. Esto causará problemas en el momento de actualizar a nuevas versiones y de eliminar la ruta del paquete antiguo.
Esta versión de HADB se admite para un máximo de 28 nodos; 24 de ellos activos y 4 de reserva.
Se recomienda utilizar la misma versión para el controlador JDBC y para el servidor HADB.
No se admite el uso de IPv6, sólo de IPv4.
La longitud de la línea de comandos en Windows está restringida a 2048 bytes.
La red debe configurarse para la multidifusión UDP.
Debido al excesivo intercambio observado en las actualizaciones 1 a 3 de RedHat Enterprise Linux 3.0, no se recomienda su uso como plataforma de implementación. Este problema se ha solucionado en RedHat Enterprise Linux 3.0 Update 4.
Posibilidad de ejecutar NSUP con prioridad de tiempo real.
Los procesos (clu_nsup_srv ) del supervisor de nodos (NSUP) garantizan la alta disponibilidad de HADB con ayuda del intercambio de mensajes de latidos (heartbeat) de una forma periódica. La temporización se ve afectada cuando se utiliza NSUP con otros procesos provocando la aniquilación del recurso. La consecuencia es una falsa partición de la red y que el nodo se reinicia precedido de una advertencia “Process blocked for n seconds” (Proceso bloqueado durante x segundos) en los archivos del historial, lo que da como resultado transacciones canceladas y otras excepciones.
Para solucionar este problema, clu_nsup_srv (que se encuentra en installpath/lib/server) debe tener el conjunto de bits suid y el archivo debe ser propiedad del usuario root. Esto se consigue de forma manual mediante los comandos:
# chown root clu_nsup_srv # chmod u+s clu_nsup_srv |
Esto hace que el proceso clu_nsup_srv se ejecute como el usuario root cuando se inicia y esto, a su vez, permite que el proceso se asigne a sí mismo automáticamente prioridad de tiempo real después del inicio. Para evitar cualquier repercusión negativa en la seguridad usando setuid, la prioridad en tiempo real se define al principio y el proceso retrocede al UID efectivo una vez que se haya cambiado la prioridad. Otros procesos de HADB disminuirán su prioridad a un tipo de prioridad de tiempo compartido.
Si NSUP no pudo definir la prioridad de tiempo real, se emite una advertencia: “Could not set realtime priority” (No se pudo establecer una prioridad de tiempo real) (unix: errno will be set to EPERM), que se escribe en el archivo ma.log y se continúa sin prioridad de tiempo real.
Hay casos en los que no es posible establecer prioridades de tiempo real, por ejemplo:
Cuando la instalación se ha efectuado en zonas no globales de Solaris 10
Cuando los privilegios PRIV_PROC_LOCK_MEMORY (Permitir que un proceso bloquee páginas en la memoria física) y/o los privilegios PRIV_PROC_PRIOCNTL se han revocado en Solaris 10
Los usuarios desactivan los permisos setuid
Los usuarios instalan el software como archivos tar (opción de instalación nonroot para App.server)
El proceso clu_nsup_srv no requiere recursos de la CPU, su huella es pequeña y si se ejecuta con prioridad de tiempo real no repercutirá en el rendimiento.
Configuración de rutas múltiples de red IP para HADB para Solaris (se ha probado sólo en Solaris 9).
Sun recomienda que los hosts de Solaris que ejecutan HADB se configuren con rutas múltiples de red para garantizar la mayor disponibilidad posible de la red. La configuración de las rutas múltiples de red se describe detalladamente en IP Network Multipathing Administration Guide. Si opta por usar rutas múltiples con HADB, consulte el apartado sobre administración de rutas múltiples de IP Network Multipathing Administration Guide para configurar las rutas múltiples antes de continuar con la adaptación de la configuración de rutas múltiples para HADB, tal y como se describe más abajo. IP Network Multipathing Administration Guide forma parte de la colección de documentación relacionada con el administrador de sistemas de Solaris 9 y se puede descargar desde http://docs.sun.com.
Establecimiento del tiempo de detección de fallos de la interfaz de red
Para que HADB sea compatible con la conmutación por error de rutas múltiples, el tiempo de detección de fallos de la interfaz de red no debe superar los 1000 milisegundos, tal y como especifica el parámetro FAILURE_DETECTION_TIME en /etc/default/mpathd. Edite el archivo y cambie el valor de este parámetro a 1000 si el valor original es superior:
FAILURE_DETECTION_TIME=1000 |
Para que el cambio surta efecto, ejecute el siguiente comando:
pkill -HUP in.mpathd |
Direcciones IP que se deben usar con HADB
Tal y como se describe en Solaris IP Network Multipathing Administration Guide, las rutas múltiples suponen la agrupación de interfaces de red físicas en grupos de interfaces con rutas múltiples. Cada interfaz física en un grupo de este tipo cuenta con dos direcciones IP asociadas: una dirección de interfaz física y una dirección de prueba. Para transmitir datos, sólo se puede usar la dirección de interfaz física, mientras que la dirección de prueba es sólo para uso interno de Solaris. Cuando se ejecuta hadbm create --hosts, cada host debe especificarse sólo con una dirección de interfaz física desde el grupo de rutas múltiples.
Ejemplo
Supongamos que el host 1 y el 2 tienen dos interfaces de red físicas cada uno de ellos. En cada host, estas dos interfaces están configuradas como grupos de rutas múltiples y están ejecutando ifconfig -a, por lo que se obtiene lo siguiente:
Host 1
bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000 broadcast 129.159.115.255 |
Host 2
bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000 broadcast 129.159.115.255 |
Aquí, las interfaces de red de los dos hosts son las que aparecen como bge0 y bge1. Las que aparecen como bge0:1 y bge1:1 son las interfaces de prueba de rutas múltiples (por lo tanto, están marcadas como DEPRECATED [en desuso] en el resultado de ifconfig), tal y como se describe en IP Network Multipathing Administration Guide.
Para configurar HADB en este entorno, seleccione una dirección de interfaz física de cada host. En este ejemplo, elegimos 129.159.115.10 del host 1 y 129.159.115.20 del host 2. Para crear una base de datos con un nodo de base de datos por host, use el siguiente argumento para hadbm create:
--host 129.159.115.10,129.159.115.20 |
Para crear una base de datos con dos nodos de base de datos en cada host, use el siguiente argumento:
--host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20 |
En ambos casos, la variable ma.server.mainternal.interfaces de los dos hosts debe establecerse en 129.159.115.0/24.
No es posible actualizar en línea de 4.2 ó 4.3 a 4.4. Sin embargo, la versión 4.4 admite actualizaciones en línea para las versiones futuras. Para actualizar de 4.4.1 a 4.4.2, lleve a cabo los siguientes pasos:
Instale 4.4.2 en todos los hosts de HADB (en una ruta distinta de 4.4.1, por ejemplo en /opt/SUNWhadb/4.4.2-6).
Instale la nueva versión en los hosts hadbm client.
Detenga todos los agentes de administración que se estén ejecutando en los hosts de HADB.
Inicie los procesos del agente de administración usando el software de la nueva versión, pero con los archivos de configuración antiguos. En los pasos que quedan, utilice el comando hadbm, que se incluye en el directorio bin de la nueva versión.
Registre el paquete en el dominio de administración (el nombre predeterminado del paquete pasa a ser V4.4, por lo que será necesario utilizar otro nombre de paquete para evitar conflictos con los paquetes existentes que tengan el mismo nombre):
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2 |
Reinicie la base de datos con la nueva versión (el siguiente comando realiza un reinicio por turnos de los nodos):
hadbm set packagename=V4.4.2 database_name |
Compruebe que la base de datos esté “ejecutándose” (para ello, use el comando hadbm status) y que funcione normalmente atendiendo las transacciones de los clientes.
Si todo está funcionando, la instalación antigua podrá eliminarse posteriormente.
Antes de anular el registro del paquete antiguo, elimine todas las referencias a él del repositorio ma. De lo contrario, hadbm unregisterpackage fallará y mostrará un error que indica que el paquete está en uso (package in use).Una operación de reconfiguración ficticia, por ejemplo, hadbm set connectiontrace= <same_as_previous_value>, eliminará todas las referencias al paquete antiguo. Ahora, proceda a anular el registro del paquete antiguo:
hadbm unregisterpackage [--hosts=<host_list>] <old_package_name> |
Elimine la instalación antigua del sistema de archivos, tal y como se describe en las installation instructions de HADB.
No se puede crear un índice secundario UNIQUE en una tabla.
La expresión (DISTINCT column) no está permitida en una expresión agregada, a menos que se trate de la única expresión seleccionada.
Todas las tablas deben crearse con una especificación de clave primaria, es decir, no se pueden usar tablas que no tengan claves primarias.
FULL OUTER JOIN no se admite.
Las subconsultas IN que son subconsultas de tablas no se admiten, por ejemplo:
SELECT SNAME FROM S WHERE (S1#,S2#) IN (SELECT S1#,S2# FROM SP WHERE P#='P2') |
No se admiten otras restricciones distintas de NOT NULL y PRIMARY KEY.
Es posible asignar un nuevo propietario a un recurso. No obstante, cuando se realiza esta acción, los privilegios concedidos al propietario actual no se conceden al nuevo propietario.
No se admite el uso de dos o más subconsultas NOT EXISTS anidadas en las que cada subconsulta no esté directamente relacionada con el nivel externo de las consultas.
No se admiten los privilegios de columnas.
Los constructores de valores de filas se permiten sólo en sentencias VALUES.
Las subconsultas no se aceptan como expresiones de valor en los constructores de valores de filas.
Los siguientes tipos de datos no se pueden usar cuando se crean claves primarias:
REAL
FLOAT
DOUBLE PRECISION
DECIMAL
NUMERIC
Application Server incluye equilibrado de carga para los clientes HTTP, IIOP y JMS; compatibilidad con conmutación por error de sesión HTTP; compatibilidad con la agrupación en clústeres de EJB y los servicios de conmutación por error; temporizadores EJB de alta disponibilidad; recuperación de transacciones distribuida; compatibilidad con actualizaciones de aplicaciones por turnos; y una base de datos de alta disponibilidad para el almacenamiento del estado transitorio de las aplicaciones J2EE.
La disponibilidad hace posible la conmutación por error de las instancias de Application Server en un clúster. Si una instancia de Application Server pasa a estar inactiva, otra instancia de Application Server asumirá las sesiones que estaban asignadas al servidor que ahora no está disponible. La información de sesión se almacena en HADB. HADB es compatible con la persistencia de las sesiones HTTP, los Stateful Session Beans y las credenciales de inicio de sesión único.