Which CMS can handle serving pages from multiple hosting locations?

1
votes

Our company has been quite successful in managing its website including all of the business logic and stuff. However, there are also a lot of static content pages which today get served using a templating system which stores the content in serialized PHP objects on the file system.

We are now considering using a "real" CMS, however we have some requirements which sort out more or less all the usual suspects. The most important requirement is our hosting environment:

We have two completely separate hosting locations with a "share nothing" approach for failover. Both locations have separate MySQL instances which are slaves () of our master database which is located on-site at our HQ. Both locations have a certain number of web servers each storing the complete website (again, for failover).

From this architecture, two possible approaches come out naturally: - A database-driven CMS which gets managed at our HQ and gets replicated over to our hosting locations (and images and stuff which gets replicated using our file sync process) - A file driven CMS in which not only the attachments, but also the content files get synced using our file sync

The database driven approach seems more flexible to me, however we couldn't find a CMS which works in a "administer locally on a read/write database and serve content using only a read-only slave". The usual suspect for example (Typo3) needs a database to write to for its logging and session management, is therefore not an option. Other CMS seem to share this problem.

So, long story short, is there a (PHP/MySQL-)CMS out there which can handle this? Any suggestions?

Extra points if the CMS can easily integrated with our Zend Framework applications (or vice versa).

2
phpmysqlcontent-management-systemreplicationweb-hosting
Is writing not important in your application? That should be because otherwise the concept of having one master database creates a direct single point of failure? If you explain a bit more how you site works we can answer better. So is it something like a Facebook with lots of writes or is is more like a news website for example where a small groups posts relatively low amount of news items compared to the views? – Luc Franken
The main purpose of the website can be considered as an ecommerce website, we are selling our products to consumers. The CMS however is planned for news pages, product advertisement pages and similar. Writes occur very rarely, most of the pages only show content. – Dan Soap

2 Answers

3
votes

You should look into Percona, which is a MySQL Performance Company who put MySQL on steroids. The easily support a Master/Master/Master environment, and can achieve it easily without needing to change auto-increment values from master to master.

They have a product called, XtraDB Cluster. It is a free prodcut, works just like MySQL, installs the same way, but handles clustering at the DB level and does a damn good job.

Once you have your DB's under control, you can install a CMS on one of the servers, make your changes, copy it to all other servers and your entire environment is fail-over ready.

2
votes

According to the added information in your comment it seems we are talking about static content.

Existing systems

As far as I can see you have a system already in place and stable which is able to deploy static content. In that sense it does not make sense to make more complex situations. Keep it simple will most of the time work best when it fits your needs.

Depending on your needs you can make the choice between your database sync or your file sync.

File sync

If you can send everything totally static your file sync will do just well. Though I see an issue there. For example: If you need a list of latest news items you would also have to generate and sync it. When you use database sync you can just do the simple query needed SELECT * FROM news ORDER BY created_at DESC LIMIT 0,10.

Amount of synchronization actions

Another point is the amount of synchronization you need to do. If you have a screen for example with 10 news items in your backend. The writer created 3 posts and starts clicking the publish button for each of them. In basic your file sync would start syncing after the first one. So it should first sync then new news item. Then it should update the latest news items listing and then sync that one.

That could be kind of bad if they start editing quite well. Because this also needs to be done on a title change for example.

Database solution

This is where a database is better at, you just update the record and it will get there. The latest news section will update itself when the new record becomes available.

Issue with related static content

Now you have one issue here: You have to make sure your process goes in 2 steps: 1. Sync images and other static content 2. Sync and/or publish the news item

Otherwise you will see broken images. This could be done for example by: Make sure that the sync of a new image starts directly. So when it is uploaded to the CMS. Then it will be there before the news item is published. You could verify that based on your needs.

Alternatives

Since this is static content you might be able to process it a bit better. That would require new technology to your stack so first verify whether it is really needed. A news item is a workflow. So, it has steps next to each other. In general for a workflow you could use queues. So you create a queue with new news items, a queue for publishing, one for syncing static items etc.

Queues work quite well with caching systems. And there is a quite interesting part to review I think. Currently there are strong caching systems available which can make the content available and sync them. They are based on the fact that you have lots of servers serving the same content. They might be a very stable and simple solution to get your work done. But as said, if you don't have them yet consider whether you want to add new complexity to your stack.