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.

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
echo -e "### BEGIN: $(date +"%x %X") ###\n"

# Stop local Tomcat
/etc/inid.d/tomcat stop

# Stop remote Tomcat
ssh root@192.168.1.101 '/etc/inid.d/tomcat stop'

# Sync OpenKM repositories
rsync -rahe 'ssh -p 22022' --stats --delete --exclude tomcat/server/default/log --exclude tomcat/start.sql /home/openkm/tomcat root@192.168.1.101:/home/openkm

# Start local Tomcat
/etc/init.d/tomcat start

# Start remote Tomcat
ssh root@192.168.1.101 '/etc/init.d/tomcat start'

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

Copie el siguiente SQL en la ubicación remota del servidor /home/tomcat-7.0.61/start.sql.

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