Replicación de instancias

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

Si quiere una configuración de alta disponibilidad típica, puede usar Cluster configuration, pero es una arquitectura compleja si quiere lograr un esquema de alta disponibilidad real. Hay otra opción, más fácil de configurar, que también proporciona buena protección frente a un fallo de servidor. Es algo similar a una configuración de clúster simplificada, en la que la instancia principal se sincroniza con la instancia de backup. Por ejemplo, esto puede hacerse usando una solución de software como rsync, que minimiza la transferencia de datos.

En este esquema, asumimos:

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

Cuando el servidor principal está caído, el de backup se convierte en el nuevo servidor principal, así que el antiguo servidor principal pasa a ser el de backup (bueno, cuando vuelva a estar disponible).

Esta es la configuración de cada servidor:

Servidor principal

OpenKM se configura normalmente.
La base de datos se configura para enviar modificaciones a la instancia de backup.
rsync se configura para enviar modificaciones del datastore cada pocos minutos al servidor de backup.

Servidor espejo

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

Distintas implementaciones

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

Una mejora sobre este primer enfoque es usar un servidor de ficheros externo (conectado por NFS), de forma que no se necesita rsync. Una solución NAS mejora la copia de seguridad y 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 pueden configurarse en modo maestro/esclavo, que es el modo necesario para esta configuración de servidor. También puede desplegar la base de datos en un servidor dedicado (que también debería replicarse). Algunos proveedores, como Oracle, ofrecen soluciones específicas de clúster de base de datos que deberían tenerse en cuenta.

Ejemplo de implementación en Linux

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

#!/bin/bash
TOMCAT_HOME="/home/openkm/tomcat-9.0.76"
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 remota $TOMCAT_HOME/start.sql del servidor.

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