Guide To High Availability
From KnowledgeTree Document Management Made Simple
Contents |
High Availability Architecture
The objective of high availability are to:
- ensure that the system performance does not degrade with an increase in users or size of KnowledgeTree repository
- ensure failure of hardware does not cripple the KnowledgeTree service, or at least minimise downtime
There are many ways in which the architecture can be defined. This document will discuss one approach from which System Administrators can make their own derivations.
If you have made a high availability solution, we would appreciate any comments, suggestions, or recommendations that can be used to assist the community.
Web Server Clustering
KnowledgeTree is based on an intensive plugin framework that can cause significant processor and I/O load. As the number of users increase, the impact on the web server is also fealt.
The web server has a few tasks to deal with:
- allowing for files to be uploaded and download - I/O
- managing documents in the repository - I/O
- general events based on the plugin framework - Processor
I/O can be easily managed by ensuring that suitable hardware is in place. However, this section will focus on how to scale the processing capabilities and and their dependencies.
Standby Replication
Having a single node for the database implies a single point of failure. It is essential that a backup is made of the database and stored on an external/independent device for safe keeping.
An alternative or complementary solution is to implement replication to a standby machine. If an event takes place where some hardware failure results in the primary machine being decommissioned, the configuration can be tweaked to use the standby database on another machine.
Setting up replication in MySQL
Standby recovery procedures for KnowledgeTree
Database Clustering
Although standby replication provides a level of availability, it is not ideal as it requires some sort of reconfiguration, systematically or manually. Ideally there would be multiple databases that can be clustered in a manner requires minimal interaction in the event of failure, and can possibly also serve as a mechanism for distributing access to the system through different geographic locations were bandwidth is restricted.
With the current implementation of KnowledgeTree it will not be possible to use the native database clustering features to implement this solution. MySQL provides a set of features in its implementation of replication using 'autoincrement_offset' and 'autoincrement_increment' values. To implement this sort of solution, the KnowledgeTree would need to cater for such a mechanism where each database host would be assigned an 'offset' and the 'increment' would be based on the number of hosts in the cluster. MySQL implements asynchronous replication from master to slave, so the offset/increment mechanisms allow for master-master manipulation - however, conflict detection and resolution is an area that will need to be investigated carefully. The implications around versions are tricky.
Repository Replication
As all documents are eventually stored on a disk somewhere, it is important to ensure that the repository is safe. Ideally, this should be replicated to other hardware using utilities such as 'rsync'.
Replicating the repository with rsync
Simple High Availability Configuration
This section will discuss a high availability configuration that can be implemented.
This configuration is composed of:
- 3 web servers
- 2 mysql databases
- 1 network storage device
- gigabit connectivity
The web servers would be load balanced with apache mod_proxy. The databases implement basic standby replication. The network storage device can be a high speed device would have its own high availability features - e.g. mirroring, backup, etc.
del.icio.us
digg
reddit
facebook
stumbleupon
