Instance replication
To enhance OpenKM's availability, you can have two instances of the application running on different servers. If the principal server goes down due to a hardware failure, you can switch to the mirrored server and keep working.
In this scheme, we assume:
- Each node has its document repository and database.
- The backup instance is supposed to be a clone of the main instance.
- In case the main instance is down, you should send the client request to the backup instance.
An option is to use a DNS, which you can modify in case of server failure, or an HAProxy instance, which, properly configured, can detect a problem in the main server and forward the request to the working one.
Keep in mind that in this configuration, only one server should accept client requests.
When the main server is down, the backup one becomes the new main server, so the old main server is now the backup one (well, when it becomes available again).
This is the configuration of each server:
Main server
- OpenKM is configured normally.
- The database is configured to send modifications to the backup instance.
- rsync is configured to send datastore modifications every few minutes to the backup server.
Mirror server
- OpenKM is configured in read-only mode.
- The database is configured to accept modifications from the main instance.
- Datastore files are periodically updated by the rsync tool from the main server.
Different implementations
The provided solution is not the only one, but the simplest.
An improvement over this first approach is to use an external file server (connected by NFS) so rsync is not required. A NAS solution improves data backup and availability and is highly recommended if the stored information is critical for your business.
Another improvement is related to the database. Some databases can be configured in master/slave mode, which is the required mode for this server configuration. You can also deploy the database on a dedicated server (which should also be replicated), or use providers like Oracle that offer specific database cluster solutions which should be taken into consideration.
Sample Linux implementation
The replication is done only in one direction, from the main server to the mirror server.
The mirror server must be configured to be in read-only mode so users can't add or modify documents.
The following script will propagate the repository changes from the main server to the mirror server:
In the sample, the main server is 192.168.1.101.
Both OpenKMs are installed in the OpenKM user's home (/home/openkm) for simplicity.
This script should be executed by the root user from the main server and can be scheduled to run daily using the Linux cron utility, for example.
The script uses rsync to minimize network load, and only modified or added documents will be transferred. The whole process can take a few minutes, depending on your repository activity.
#!/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") ###"Copy the following SQL into the remote $TOMCAT_HOME/start.sql file on the server.
update OKM_CONFIG set 'true' where CFG_KEY='system.readonly';After the first synchronization, stop the remote Tomcat, update the start.sql script there, and start the Tomcat again.
