Replicación de instancias

Para mejorar la disponibilidad de OpenKM, puede tener dos instancias de la aplicación ejecutándose en servidores diferentes. Si el servidor principal se cae debido a un fallo de hardware, puede cambiar al servidor espejo y seguir trabajando.

Si desea una configuración de alta disponibilidad típica, puede utilizar la Configuración del clúster, pero es una arquitectura compleja si se quiere lograr un esquema de alta disponibilidad real. Existe otra opción, más fácil de configurar, que también proporciona una buena protección frente a un fallo del servidor. Es algo parecido a una configuración de clúster simplificada en la que la instancia principal se sincroniza con la instancia de respaldo. Por ejemplo, esto se puede hacer utilizando una solución de software como rsync, que minimiza la transferencia de datos.

En este esquema, asumimos que:

Cada nodo tiene su repositorio de documentos y su base de datos.
Se supone que la instancia de respaldo es un clon de la instancia principal.
En caso de que la instancia principal esté caída, debe enviar la petición del cliente a la instancia de respaldo.

Cuando el servidor principal está caído, el de respaldo pasa a ser el nuevo servidor principal, por lo que el antiguo servidor principal pasa a ser el de respaldo (cuando vuelva a estar disponible).

Esta es la configuración de cada servidor:

Servidor principal

OpenKM se configura de forma normal.
La base de datos se configura para enviar las modificaciones a la instancia de respaldo.
Rsync se configura para enviar las modificaciones del datastore cada pocos minutos al servidor de respaldo.

Servidor espejo

OpenKM se configura en modo de solo lectura.
La base de datos se configura para aceptar las modificaciones de la instancia principal.
Los ficheros del datastore se actualizan periódicamente mediante la herramienta Rsync desde el servidor principal.

Distintas implementaciones

La solución proporcionada no es la única, pero sí la más sencilla.

Una mejora sobre este primer enfoque es utilizar un servidor de ficheros externo (conectado mediante NFS) de forma que no sea necesario rsync; una solución NAS mejora la copia de seguridad y la disponibilidad de los datos. Es muy recomendable si la información almacenada es crítica para su negocio.

Otra mejora está relacionada con la base de datos. Algunas bases de datos se pueden configurar en modo maestro/esclavo, que es el modo necesario para esta configuración de servidores. También puede desplegar la base de datos en un servidor dedicado (que también debería estar replicado); algunos proveedores, como Oracle, ofrecen soluciones específicas de clúster de base de datos que conviene tener en cuenta.

Ejemplo de implementación en Linux

El siguiente script propagará los cambios del repositorio desde el servidor principal al servidor espejo:

#!/bin/bash
TOMCAT_HOME="/home/openkm/tomcat-8.5.69"
REMOTE_HOST="root@192.168.1.102"
MYSQL_PASS="*****"

echo -e "### BEGIN: $(date +"%x %X") ###\n"

# Stop local OpenKM
/etc/init.d/openkm stop

# Stop remote OpenKM
ssh $REMOTE_HOST '/etc/init.d/openkm stop'

# Sync OpenKM repositories
rsync -avh --stats --delete --exclude repository/.system.key --exclude logs $TOMCAT_HOME ${REMOTE_HOST}:/home/openkm

# Dump and copy database
mysqldump -u root -p${MYSQL_PASS} okmdb | ssh $REMOTE_HOST "mysql -u root -p${MYSQL_PASS} okmdb"

# Start local OpenKM
/etc/init.d/openkm start

# Start remote OpenKM
ssh $REMOTE_HOST '/etc/init.d/openkm start'

echo -e "\n### END: $(date +"%x %X") ###"

Copie el siguiente SQL en la ubicación $TOMCAT_HOME/start.sql del servidor remoto.

update OKM_CONFIG set 'true' where CFG_KEY='system.readonly';