Información especial sobre la implementación y la actualización

En este apartado se incluye información adicional acerca de la actualización y la implementación de HADB.

• Implementación

• Actualización en línea de 4.4.1 a 4.4.2

Implementación

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

Actualización en línea de 4.4.1 a 4.4.2

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:

1. 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).

2. Instale la nueva versión en los hosts hadbm client.

3. Detenga todos los agentes de administración que se estén ejecutando en los hosts de HADB.

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

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

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

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

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