Contensis allows you to load balance the services that are running. This means that, in the event of server failure, another server offering the same capabilities can kick-in. This is especially useful when you want to provide a 24hr uninterrupted service.
Each server can be configured with a priority; choose which servers run each of Contensis' seven "services". These services range from publishing to email notifications, which carry out background operations to fulfil your needs.
For example, you could configure two servers; each configured to run half of the services. If either server fails then the other will take on its role.
You can spread the load of the services across any number of servers although, as always, if you just need one server, all of the components will run happily from it.
The graphical user interface for Contensis is served via Microsoft IIS. If required you can span this across multiple servers, but if you want to do this you will require an extra CMS licence. The actual load balancing can be done using any load balancer that supports session affinity. Microsoft provides a solution called NLB or network load balancing which ships as standard with all current Windows server operating systems.
A load balanced GUI provides continuous service for the editors, contributors and administrators; even in the event of a server completely failing, the system will continue to operate with no degradation. You can scale your servers to support all users to minimise any performance issues in the event of one server failing; if one server will not cope with all users, then it is advisable to have three in the configuration.
These are only requirements for providing a continuous service for editors. Even with one server, a replacement CMS server can be configured in less than an hour after a server failure, assuming you have the relevant backups in place.
The back-end of Contensis relies on a single SQL server repository. This is not the front-end, just the back-end.
If you want to provide a continuous service even in the event of server failure, you will need to invest in a SQL server resilience model. You can use database replication, database clustering, virtual server solutions. The solution you use will depend upon your organisation and the technology you use.
We have provided a diagram of a standard SQL server clustering model below:
We have provided some diagrams below showing how the Contensis content management system can scale from a single server right the way up to a multi-server load balanced environment.
These sample architecture diagrams are meant only as a guide to the possibilities; often we will work with a customer to design a specific architecture to suit their individual needs.
CMS architecture - non resilient A
This is the simplest architecture; software is installed on a single server including the database services. In this set-up there is no resilience in the event of server failure. Bear in mind that this is just the back-end, not the front-end website.
If the single server were to fail then your website would still be up and running due to our disconnected publishing architecture, but your users would not be able to contribute content during the outage.
CMS architecture - non resilient B
This architecture again offers no resilience, but is designed for situations where you may not need resilience but may need better performance.
In this scenario all Contensis software is installed on a single server but the actual database is installed on a separate server. This can scale up the editors and system usage to almost double the first architecture, as there is twice as much processing power available.
CMS architecture - non resilient C
This architecture is probably the least resilient of all. The CMS architecture is very similar to CMS architecture non resilient A but with the front-end web server architecture installed.
This configuration might be used for development servers and on smaller implementations when there are no resilience issues.
CMS architecture - resilient A
This is the simplest of our resilient CMS architecture diagrams. In order to make the solution resilient, there are a pair of load balanced CMS servers, with a SQL cluster repository.
A simple modification to this configuration would be to house the SQL cluster on the CMS servers, with just two servers required for the minimum resilient solution.
CMS architecture - resilient B
This architecture is very similar to resilient A. Performance is enhanced with a pair of load balanced servers to run the Contensis services, as well as the load balanced GUI servers and a backend SQL cluster.
This is the most high performing and resilient solution, and could be extended at any point by simply adding extra CMS servers.