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

Si desea una configuración típica de alta disponibilidad, puede utilizar la Configuración de 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 ofrece una buena protección frente al fallo de un 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 puede hacerse con una solución de software como Rsync, que minimiza los datos transferidos.

En este esquema, asumimos que:

Cada nodo tiene su propio repositorio de documentos y su propia base de datos.
Se supone que la instancia de respaldo es un clon de la instancia principal.
Si la instancia principal está caída, debe enviar las peticiones de los clientes a la instancia de respaldo.

Cuando el servidor principal está caído, el de respaldo se convierte en 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 archivos del datastore se actualizan periódicamente con la herramienta Rsync desde el servidor principal.

Implementaciones diferentes

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 archivos externo (conectado por NFS) para que no sea necesario Rsync. Se trata de utilizar una solución NAS que mejora la copia de seguridad y la disponibilidad de los datos. Se recomienda encarecidamente 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 requerido para esta configuración de servidores. Pero también puede desplegar la base de datos en un servidor dedicado (que también debería replicarse); además, algunos proveedores como Oracle ofrecen soluciones específicas de clúster de bases de datos que conviene tener 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-8.5.24"
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';