Implementing Multiple deployers/Broker databases vs. replication

Question

I am currently working in a Tridion 2009 SP1 environment where are trying to set-up a fail-over situation by using two deployers which are deploying content to two different file servers and two different Broker Databases. So far so good, except that when one deployment target fails the publish action has to be redone (for both).

Now they want to double this situation by adding two more servers, two more Broker databases, etc...

In my opinion it seems that this not only increases the possibility of failure, but also doesn't create an easy fail over situation and can create more complications. I'd prefer the single source of storage (or file replication) in combination with a replicated server.

How is this typically done in large organizations with many webservers, publishers and deployers?

Answer 1

There are - as usual with Tridion - about as many solutions as you may think of.

My preferred solutions:

• If you're using a model that can get all data from the Database (CWA, DD4T, WebService), then, by all means, please use this. Single database for delivery, caching properly set up on delivery servers and you're good to go. In a CWA customer environment we had the site running for over 2 hours with the database down thanks to caching.
• If this is not possible and you need files in the file system, then try to use SAN/NAS solutions, as this will ensure all files are distributed to all servers at the same time.

To avoid:

• File replication (unless it's very near real-time): the reason to avoid this is that your cache notification will arrive before the new file and there's a chance your delivery server will (re)cache the previous version of the file instead of the new one. You cannot modify the cache notification delay, so this may always cause some trouble

If none of the above is an option, then using multiple deployers might be the only solution available - the problem here is that you will introduce a more complex deployment environment, with "transactional deployments" and 2-phase commits that slow down the deployment time and will introduce more points of failure.

Answer 2

If you have two datacenters then I would just shoot for the solution you already have. Indeed if one DC is down then you will need to resubmit jobs either because the complete transaction failed across both DCs (see Nuno's remark on transactional deployments) or because one of the DCs is not out of sync with the other (non-transactional deployments). Recovery of published jobs here could be more or less automated using scripts or even good monitoring applications.

For larger scale environments CD database replication works well (master/slave) but you will start to find problems when: - The Cache needs invalidation on the slave DCs - it's possible to code a solution for this to replicate cache messages (talk to SDL PS for more information on how to do this) - when you need to write to the database with a bespoke data store or just audience manager - you then need a more complex multi-master database solution or to make your storage of data done via a webservice layer (run off the master DB).

Answer 3

These blog posts might help:

http://blog.building-blocks.com/scaling-the-sdl-tridion-deployer

http://www.julianwraith.com/2012/12/multi-multi-sdl-tridion-deployers-solving-the-race-condition/

Answer 4

For the DB part, you can also try to put in place a SQL cluster. For the Filesystem part, SAN/NAS is probably the best solution.

For the deployers, you can configure different deployers working on the SQL cluster. BUT you have to be sure that these 2 deployers won't work at the same time. An active - passive load balancer can be the solution.