11

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?

|improve this question
9

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.

|improve this answer
  • I think all the answers are good. They have all helped out. Nuno's was the most complete. – Hendrik Beenker Mar 14 '13 at 21:54
  • Hi Nuno, for limited number of end user it is ok to have a single database, but consider a website having thousands of hit per hours. Should we not have multiple load balanced broker database in that case. I understand, caching will improve but not everything can be cached. – rdhaundiyal Nov 16 '15 at 17:07
6

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).

|improve this answer
5

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/

|improve this answer
  • Yeas, definitely read those blogs. Also looked at the answers in this Tridion SO post. I have helped set-up an implementation like the Building-Blocks post. I guess I am more looking for people to say: "Don't just add deployers and databases when scaling out, but do this..." – Hendrik Beenker Mar 11 '13 at 15:15
  • I have honestly not had to deal with this situation myself so maybe on of the authors of those posts will be able to give a proper answer. – Rob Stevenson-Leggett Mar 11 '13 at 17:49
3

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.