We are running SDL Tridion 2013 SP1 with Oracle 11g as the CMS DB and IIS/Tomcat/Oracle 11g on the Presentation Side. Currently the presentation side is comprised of one node/instance of each of the following:

  1. Web Server (IIS)
  2. Application Server (Apache Tomcat - 2 instances: 1 for Content Deployer; and 1 for Website)
  3. Content Broker DB (running on Oracle 11g)

The client has now asked us to propose a solution for High Availability and Disaster Recovery for their CMS as well Website. They plan on implementing Oracle RAC to take care of the database side of the things.

We are thinking of the following solution for the Production environment:

  1. 2 Web Servers (IIS) load balanced thru a NLB
  2. 2 Application Servers (Apache Tomcat - each running 2 instances of Tomcat: 1 for Deployer; 1 for website) load balanced thru a NLB

I have read up a several blog posts and articles regarding multiple deployers and no one seems to suit the client's requirements. Based on the this article it is not advised to have multiple deployers trying to publish the same contents. The suggested approach is to have each deployer publish contents for a given publication:

  • deployer 1
    • publication a
    • publication b
  • deployer 2
    • publication c
    • publication d
  • etc…

With the above setup if Deployer 2 is offline then there is no way to publish contents from Publications C & D.

One of our suggested solution relies on a shared storage (NAS) shared by all deployers and presentation tomcat instances and then replicated to the DR storage. But this involves a manual change of deployer/tomcat configuration during a DR situation to activate the DR Storage.

The client needs the ability to seemless continue publishing even in case of DR and they have asked for a seemless Production to DR switch over. Please provide any other suggestions of implementing the required.

1 Answer 1


There is one way using which you can achieve seamless production delivery i.e using the following approach:

2 Application Servers (Apache Tomcat - each running 2 instances of Tomcat: 1 for Deployer; 1 for website) load balanced thru a NLB. Here, NLB should be failover partners (active-passive). So at a time only one deployer is active and other deployer is passive.

This way in case of DR, the passive deployer will become active and serve the publishing.

Hope this helps.

  • Thanks @Hiren for the suggested approach. However it does not provide any kind of Load Balancing or High Availability within the Production environment itself. Where would the deployed files (JSP, CSS, PDF etc.) be stored? Mar 2, 2015 at 11:32
  • @hzahid - To answer you question, you can create common share for both deployers and since only one deployer is active at a time, you don't need to worry about publish happening from two different places, your concern was you will have separate deployers based on publication. However that is not required in this case and you can provide high availability.
    – Hiren Kaku
    Mar 2, 2015 at 18:29
  • When using a Shared Storage between Production & DR environments introduces the Shared Storage as a single point of failure as well as a manual reconfiguration during a DR situation is required to make the DR storage active and DR deployer read/write to DR Storage. Mar 3, 2015 at 7:13
  • Shared storage can also be behind load balancer. So when you deploy through load balancer then it will be deployed to either of the share then you can have sync job to sync the shares. I am not sure about the level of control that you can have for sync job.
    – Hiren Kaku
    Mar 3, 2015 at 18:38
  • 1
    @AndrewWilliamRoss - This is not tridion configuration, this should be done at the VIP / Big IP level so your deployers are load balanced by failover algorithm instead of round robin or something else.
    – Hiren Kaku
    May 26, 2015 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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