Configuración de clúster

Nota

Esta nueva arquitectura de clúster es una mejora de la anterior y soluciona estos problemas encontrados en la otra versión:

• Punto único de fallo: solo el maestro puede modificar el índice. Si el maestro falla, todo el sistema tendría problemas.
• Latencia: los nodos esclavos tienen que refrescar su índice local cada cierto número de minutos. Por ello existe una latencia entre el maestro y el esclavo para ver un elemento recién indexado.

Este tipo de arquitectura proporciona reparto de carga entre servidores, además de alta disponibilidad. Veamos la arquitectura propuesta. Hay varios servidores OpenKM y uno (o varios) servidores HAProxy que distribuirán las peticiones de los usuarios entre esos servidores OpenKM. HAProxy también puede configurarse para detectar qué servidor OpenKM está caído y evitar enviarle peticiones hasta que vuelva a estar operativo. Opcionalmente, puede configurar varios servidores de base de datos replicados (gestionados también por otro HAProxy) que evitan que el servicio se interrumpa si un nodo de base de datos deja de funcionar. Por defecto, OpenKM almacena los documentos en disco para maximizar el rendimiento, por lo que necesita que estos archivos estén replicados entre sus servidores OpenKM. Una opción es GlusterFS, que es una solución de software para crear sistemas de archivos distribuidos, pero NFS es bastante bueno en la mayoría de las situaciones y más fácil de configurar en servidores Linux.

Tenga en cuenta que esto es solo una propuesta y usted es libre de implementar la infraestructura que desee para conseguir los mismos resultados. Para evitar una configuración excesiva y difícil, vamos a describir una arquitectura simplificada que cumple el mismo objetivo: el nodo maestro, la base de datos y el servidor NFS están en la misma máquina.

Precaución

Recuerde que todas las instancias de OpenKM deben utilizar la misma instancia de base de datos. Solo una base de datos para todas las instancias. Este recurso se configura en el archivo TOMCAT_HOME/conf/server.xml.

Si mira dentro del directorio TOMCAT_HOME/repository, puede ver estos otros:

• cache: son archivos generados que se utilizan sobre todo en la vista previa. Si se eliminan, se volverán a crear.
• datastore: estos archivos son el contenido binario de los documentos almacenados en OpenKM. Debe cuidarlos y siempre se recomienda una copia de seguridad.
• index: donde Lucene almacena los índices utilizados en la búsqueda de documentos y metadatos. En caso de eliminación, puede volver a indexar el repositorio desde Administration > Utilities.

Según esta información, puede colocar las carpetas cache y datastore en otro servidor como recursos compartidos. De media, el 80% de las acciones de los usuarios son de lectura de documentos y solo el 20% de escritura (crear o actualizar documentos). La carpeta problemática es index, porque los índices de Lucene no pueden compartirse entre varias instancias de OpenKM. Entonces, ¿qué podemos hacer? La solución es que cada instancia de OpenKM tenga su propio índice y que se envíen mensajes entre ellas para mantener actualizado su índice local. Si un nodo necesita actualizar el índice, también envía el mensaje a los demás nodos, que procesarán la modificación localmente.

Nota

Los mensajes no se envían directamente entre los nodos, sino mediante un proveedor JMS como Apache ActiveMQ.

ActiveMQ

En realidad, los mensajes no se envían a los nodos, sino a una cola que almacena todos esos mensajes, que son consumidos por los demás nodos. Utilizaremos Apache ActiveMQ para gestionar esta cola; es un conocido intermediario de mensajes (message broker) y proveedor JMS. Así pues, descargue Apache ActiveMQ e instálelo. Más adelante tendrá que configurar en los nodos (en el archivo server.xml) dónde se está ejecutando la instancia del broker. Una vez descomprimido e iniciado:

$ tar xzvf apache-activemq-5.13.4-bin.tar.gz
$ cd apache-activemq-5.13.4
$ ./bin/activemq console

Puede acceder a la consola de administración mediante esta URL http://master:8161/admin (usuario por defecto: admin, contraseña: admin)

Nota

Para cambiar la contraseña de administrador por defecto, edite el archivo $ACTIVEMQ_HOME/conf/jetty-realm.properties.

Obviamente, debería configurar Apache ActiveMQ como servicio, de modo que se inicie y se detenga cuando el servidor arranque o se apague. Afortunadamente incluye un script de inicio que puede configurarse en un par de pasos:

$ sudo ln -s /path/to/activemq-5.13.4/bin/activemq /etc/init.d/activemq
$ sudo update-rc.d activemq defaults

Ahora el servicio estará en línea siempre que arranque el servidor. Otra forma de hacerlo es utilizar el Java Service Wrapper que viene incluido en la instalación. Las instrucciones sobre esta configuración están disponibles en Installing ActiveMQ as a service on Linux.

En el caso de Windows, puede encontrar un script para registrarlo como servicio en $ACTIVEMQ_HOME/bin/win64/InstallService.bat que, una vez ejecutado, creará el servicio.

Peligro

Si desea forzar el enlace por IPv4, edite el archivo $ACTIVEMQ_HOME/bin/env de esta forma:

# Uncomment to enable audit logging
#ACTIVEMQ_OPTS="$ACTIVEMQ_OPTS -Dorg.apache.activemq.audit=true"
ACTIVEMQ_OPTS="$ACTIVEMQ_OPTS -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses"

Precaución

Para que ActiveMQ funcione correctamente, cada instancia de OpenKM debe tener su propio ID de instalación.

Mensajes de aviso (advisory)

ActiveMQ admite mensajes de aviso (advisory) que permiten ver lo que ocurre en el sistema. La implementación actual admite información sobre:

• Inicio y parada de consumidores, productores y conexiones.
• Creación y destrucción de destinos temporales.
• Expiración de mensajes en topics y colas.
• Brokers que envían mensajes a destinos sin consumidores.
• Inicio y parada de conexiones.

Este tipo de mensajes son una especie de canal administrativo en el que puede recibir información sobre lo que ocurre en el proveedor JMS y otra información relacionada con productores, consumidores y destinos. OpenKM crea un topic llamado “OpenKM.Cluster”, por lo que todos estos avisos se crean por defecto:

Topics de aviso	Descripción
ActiveMQ.Advisory.Connection	Mensajes de inicio y parada de conexión
ActiveMQ.Advisory.MasterBroker	Un broker es ahora el maestro en una configuración maestro/esclavo
ActiveMQ.Advisory.Producer.Topic.OpenKM.Cluster	Mensajes de inicio y parada de productor en un Topic
ActiveMQ.Advisory.Consumer.Topic.OpenKM.Cluster	Mensajes de inicio y parada de consumidor en un Topic
ActiveMQ.Advisory.MessageDLQd.Topic.OpenKM.Cluster	Mensaje enviado a la DLQ (Dead Letter Queue)

Nota

El uso de mensajes de aviso supone una sobrecarga en términos de memoria y recursos de conexión. Si no va a utilizarlos, puede deshabilitarlos editando el archivo ACTIVEMQ_HOME/conf/activemq.xml y añadiendo esta propiedad:

<broker advisorySupport="false">

Más información sobre los mensajes de aviso en la documentación de ActiveMQ.

Nota: si un mensaje no puede entregarse, el sistema intenta reenviarlo. Cuando los intentos de reentrega superan un máximo configurado, ese mensaje se considera problemático y se envía a la Dead Letter Queue. La Dead Letter Queue por defecto se llama ActiveMQ.DLQ. Si desea que estos mensajes se descarten, configure el policyEntry correspondiente de esta forma:

<deadLetterStrategy>
    <discarding/>
</deadLetterStrategy>

Más información sobre la DLQ en Message Redelivery and DLQ Handling.

Nodo proxy

Este es el único nodo que debe ser accesible para los usuarios y que repartirá las peticiones entre los nodos esclavos. La parte más importante es la configuración de HAProxy. Este formato de configuración funciona en HAProxy v1.5

frontend LB
  bind 192.168.0.220:80
  reqadd X-Forwarded-Proto:\ http
  default_backend LB

backend LB 192.168.0.220:80
  mode http
  stats enable
  stats hide-version
  stats uri /stats
  stats realm HAProxy\ Statistics
  stats auth admin:admin
  balance roundrobin
  option httpchk
  option httpclose
  option forwardfor
  cookie LB insert
  server node1 192.168.0.222:8080 cookie node1 check
  server node2 192.168.0.223:8080 cookie node2 check

Según esta configuración, las peticiones de los usuarios se repartirán mediante el algoritmo round-robin entre los dos servidores OpenKM. Si alguno de los servidores OpenKM falla, las peticiones se reenviarán únicamente al que funcione. En http://proxy/stats (usuario por defecto: admin, contraseña: admin) podrá ver el estado de los nodos y otras estadísticas. Hay un manual completo de HAProxy en http://cbonte.github.io/haproxy-dconv/configuration-1.5.html. Si utiliza otra versión de HAProxy, algunas opciones pueden haber cambiado.

Nodo maestro

Este tipo de nodo no es muy diferente de los esclavos. La única diferencia real es que puede ejecutar tareas de crontab, entre otras acciones de administración. Como dijimos antes, para simplificar la configuración este nodo maestro también almacenará los archivos de cache y datastore.

Nota

En este ejemplo vamos a utilizar este servidor también como servidor NFS, pero es muy habitual disponer de una SAN que actúe como servidor NFS.

Creemos estos directorios:

$ sudo mkdir /mnt/okm_extraction
$ sudo mkdir /mnt/okm_cache
$ sudo mkdir /mnt/okm_dstore
$ sudo chown openkm:openkm /mnt/okm_*

Vamos a exponer estos directorios por NFS, por lo que necesitamos instalar el soporte:

$ sudo apt-get install nfs-kernel-server

 Una vez instalado, edite el archivo /etc/exports y añada estas líneas:

/mnt/okm_extraction *(rw,sync,no_root_squash,no_subtree_check)
/mnt/okm_cache *(rw,sync,no_root_squash,no_subtree_check)
/mnt/okm_dstore *(rw,sync,no_root_squash,no_subtree_check)

Tras guardarlo, debe ejecutar este comando (cada vez que modifique este archivo debe ejecutarlo):

$ sudo exportfs -ra

Ahora creemos los enlaces simbólicos:

$ sudo ln -s /mnt/okm_cache TOMCAT_HOME/repository/cache
$ sudo ln -s /mnt/okm_dstore TOMCAT_HOME/repository/datastore
$ sudo ln -s /mnt/okm_extraction TOMCAT_HOME/repository/extraction
$ sudo chown -h openkm:openkm TOMCAT_HOME/repository/cache
$ sudo chown -h openkm:openkm TOMCAT_HOME/repository/datastore
$ sudo chown -h openkm:openkm TOMCAT_HOME/repository/extraction

En lugar de crear enlaces, puede configurar OpenKM para que cree estos directorios en otras ubicaciones:

repository.extraction.home=/mnt/okm_extraction
repository.datastore.home=/mnt/okm_dstore
repository.cache.home=/mnt/okm_cache

En el caso de Windows, puede montar un recurso compartido o utilizar la utilidad mklink:

C:\> mklink /D c:\okmrepo \\SERVER\path\to\shared

Para habilitar esta configuración, edite TOMCAT_HOME/OpenKM.cfg y descomente esta parte:

# Cluster - Master
cluster.backend=jms
cluster.node=master

Edite TOMCAT_HOME/conf/server.xml y descomente esta parte:

<!-- Cluster - Master & Slave -->
<Resource auth="Container" name="jms/ConnectionFactory"
          type="org.apache.activemq.ActiveMQConnectionFactory"
          description="JMS Connection Factory"
          factory="org.apache.activemq.jndi.JNDIReferenceFactory"
          brokerURL="tcp://localhost:61616"
          brokerName="HibernateSearchBroker"/>

Precaución

Si inicia el broker en otro servidor, configure la propiedad brokerURL.

Edite TOMCAT_HOME/conf/context.xml y descomente esta parte:

<!-- Cluster - Master & Slave -->
<ResourceLink global="jms/ConnectionFactory" name="jms/ConnectionFactory" type="javax.jms.ConnectionFactory"/>

Nodos esclavos

Estos nodos pueden escribir en las carpetas cache y datastore. Aquí también necesitamos crear los directorios compartidos que se utilizarán como punto de montaje:

$ sudo mkdir /mnt/okm_cache
$ sudo mkdir /mnt/okm_dstore
$ sudo mkdir /mnt/okm_extraction
$ sudo chown openkm:openkm /mnt/okm_*

Instale el soporte de cliente NFS:

$ sudo apt-get install nfs-common

Queremos que se monten automáticamente, así que edite el archivo /etc/fstab y añada:

# Cluster
master:/mnt/okm_extraction /mnt/okm_extraction nfs auto,noatime,rsize=8192,wsize=8192,timeo=14,intr
master:/mnt/okm_cache /mnt/okm_cache nfs auto,noatime,rsize=8192,wsize=8192,timeo=14,intr
master:/mnt/okm_dstore /mnt/okm_dstore nfs auto,noatime,rsize=8192,wsize=8192,timeo=14,intr

Nota

Edite el archivo /etc/hosts y configúrelo para que resuelva el nombre del servidor “master” con la IP correcta.

Ahora montémoslos:

$ sudo mount -a

Creemos los enlaces simbólicos:

$ sudo ln -s /mnt/okm_cache TOMCAT_HOME/repository/cache
$ sudo ln -s /mnt/okm_dstore TOMCAT_HOME/repository/datastore
$ sudo ln -s /mnt/okm_extraction TOMCAT_HOME/repository/extraction
$ sudo chown -h openkm:openkm TOMCAT_HOME/repository/cache
$ sudo chown -h openkm:openkm TOMCAT_HOME/repository/datastore
$ sudo chown -h openkm:openkm TOMCAT_HOME/repository/extraction

En lugar de crear enlaces, puede configurar OpenKM para que cree estos directorios en otras ubicaciones:

repository.extraction.home=/mnt/okm_extraction
repository.datastore.home=/mnt/okm_dstore
repository.cache.home=/mnt/okm_cache

En el caso de Windows, puede montar un recurso compartido o utilizar la utilidad mklink:

C:\> mklink /D c:\okmrepo \\SERVER\path\to\shared

Para habilitar esta configuración, edite TOMCAT_HOME/OpenKM.cfg y descomente esta parte:

# Cluster - Slave
cluster.backend=jms
cluster.node=slave

Edite TOMCAT_HOME/conf/server.xml y descomente esta parte: 

<!-- Cluster - Master & Slave -->
<Resource auth="Container" name="jms/ConnectionFactory"
          type="org.apache.activemq.ActiveMQConnectionFactory"
          description="JMS Connection Factory"
          factory="org.apache.activemq.jndi.JNDIReferenceFactory"
          brokerURL="tcp://master:61616"
          brokerName="HibernateSearchBroker"/>

Precaución

Si inicia el broker en un servidor diferente, configure la propiedad brokerURL.

Edite TOMCAT_HOME/conf/context.xml y descomente esta parte:

<!-- Cluster - Master & Slave -->
<ResourceLink global="jms/ConnectionFactory" name="jms/ConnectionFactory" type="javax.jms.ConnectionFactory"/>