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 cae por un fallo de hardware, puede cambiar al servidor espejo y seguir trabajando.

Si quiere una configuración típica de alta disponibilidad, puede usar la Cluster configuration, pero es una arquitectura compleja si quiere lograr un esquema real de alta disponibilidad. Hay otra opción, más fácil de configurar y que también ofrece buena protección frente a un fallo de servidor. Es algo así como una configuración de clúster simplificada donde la instancia principal se sincroniza con la instancia de respaldo. Por ejemplo, esto se puede hacer 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.
Se supone que la instancia de respaldo es un clon de la instancia principal.
Si la instancia principal cae, debería enviar las peticiones del cliente a la instancia de respaldo.

Cuando el servidor principal cae, el de respaldo se convierte en el nuevo servidor principal, así que el antiguo servidor principal pasa a ser el de respaldo (bueno, 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 modificaciones a la instancia de respaldo.
rsync se configura para enviar 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 modificaciones de la instancia principal.
Los ficheros del datastore se actualizan periódicamente con la herramienta rsync desde el servidor principal.

Implementaciones distintas

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

Una mejora sobre este primer enfoque es usar un servidor de ficheros externo (conectado por NFS), de modo que no se necesita rsync. Una solución NAS mejora la copia de seguridad y disponibilidad de 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 master/slave, que es el modo requerido 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 del servidor $TOMCAT_HOME/start.sql.

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