Instance replication
To enhance OpenKM availability you can have two instances of the application running on different servers. If the principal server gets 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 own 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 petitions.
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 is 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 modification from the main instance.
- Datastore files are periodically updated by 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 using an external file server (connected by NFS) so Rsync is not needed. Using a NAS solution which improves the data backup and availability. It is highly recommended if the stored information is critical for your business.
Another improvement is related to the database. Some database can be configured in master / slave mode, which the required mode for this server configuration. But you can also deploy the database in a dedicated server (which should be also replied) but some providers like Oracle offer specific database cluster solutions which should be taken in consideration.
Sample Linux implementation
The replication is done only in one direction, from main server to mirror server.
The mirror server must be configured to be in read-only mode so users can't add or modify documents.
The follow script will propagate the repository changes from main server to mirror server:
On the sample the main server 192.168.1.101.
Both OpenKM are installed at the OpenKM user home (/home/openkm) for simplicity.
This script should be executed - by user root - from the main server, and can be scheduled to be executed every day using 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
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") ###"Copy the following SQL into the remote /home/tomcat-7.0.61/start.sql server localtion.
update OKM_CONFIG set 'true' where CFG_KEY='system.readonly';After the first synchronization, stop remote Tomcat, update the start.sql script there and start the Tomcat again.