Contensis Architecture

As Contensis is a true enterprise solution, you can even load balance the services that are running, so that, in the event that a server fails, another server offering the same capabilities can kick-in. This is especially useful when you want to provide a 24hr "no interrupt" service.

Each server can be configured with a priority, and you can choose which servers run which services. Contensis has seven services ranging from publishing to email notifications, which carry out background operations to fulfil your needs.

You could, for example, configure two servers; one could be configured to run half of the services and the second the other half. If either server fails then the other will take on its role. Of course there is no limit to the number of servers that can be configured.

This functionality allows you to 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.

If you want to provide continuous service for the editors, contributors and administrators, then this is the way forward; even in the event of a server completely failing, the system will continue to operate with no degradation.

Normally you would scale your servers to support all users, so you would not have 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.

Do bear in mind, though, that with our back-end architecture these are only requirements for providing a continuous service for editors. In the event of a server failure, assuming you have the relevant backups in place, a replacement CMS server can be configured in less than an hour.

When looking at your front-end architecture there are many options that can be explored.

The back-end of Contensis relies on a single SQL Server Repository. Please be clear that this is not the front-end, just the back-end.

Because of this, 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 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 ranging from a simple solution, through a mid-range solution, to a solution servicing offices in 20 countries.

It is important to bear in mind that 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 first architecture diagram is probably the simplest architecture of all. In essence, all 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 configuration has the advantage of being able to scale up the editors and system usage to almost twice as much as 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, except that the server also has the front-end web server architecture installed.

None the less, this configuration is useful and is often 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 is 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, meaning that just two servers are required for the minimum resilient solution.

CMS Architecture - Resilient B

This architecture is very similar to Resilient A, except that, for performance reasons, we have 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.