At a high level I have been searching to find steps or documentation per setting up a passive deployer as a fail over for an active deployer. Using Tridion 2013 and Tomcat as a deployer, is there any documentation/manual or blogs regarding this (maybe I may have overlooked or not come upon yet), available?
The installation and setup of the deployer is exactly the same whether it is an active or a passive deployer which you can refer here Deployer Setup
The active/passive setup is done via the NLB. In the NLB you have to setup active/passive (failover) partners in terms of your deployers. So, only one deployer is active at a time while is the other one is a failover partner.
Also, in your publication targets you need to specify the NLB endpoint of the deployers so that the transaction will always go to the active deployer, like:
This setup will ensure that publish transactions are picked up by only the active deployer.
Also, if you do plan to use Tridion caching on content delivery, you will need to setup NLB for cache channel service as well on port 1099 so that your oData servers can listen in for publish events and cache clearing can happen on the same as well.
Be aware that the passive deployer must not become active until the previously active deployer has ceased all deployment (or you could get out-of-order deployment commits).
Ideally before making the passive deployer the active one the previously active deployer must be terminated (or disconnected from the network, or otherwise ensured to no longer commit deployments).
Edit: There are several ways of achieving this:
- make the failover action a manual action and explicitly verify the original active deployer is no longer performing deployments before making the switch
- use clustering instead of NLB failover and restrict access to the database to the cluster IP address (which only ever one node in the cluster will use at a given time)
- Extend the deployer and implement a database-level lock which only one of the deployers can hold. The lock must expire if the deployer loses its connection with the database server (most likely via a timeout mechanism). Deployments should be put "on hold" until the lock can be acquired.
The core of the problem is that NLB failover works fine for stateless applications but deployers are stateful and not explicitly designed with this kind of failover in mind. As such making a truly high available and reliable deployment solution requires much more work than just implementing NLB failover.
Of course you can always "take the risk" and hope for the best; depending on the quality requirements of your platform this is by far the simplest solution (apart from manual failover; if failover occurs very infrequently why automate it to begin with?).