Four  Nodes cluster:

In this architecture topology, we have 2 nodes in primary site and 2 nodes in DR site. All the nodes are active and take loads equally. They are connected with primary site load balancer in normal situation. DR site servers points to primary site database and shared file system. If disaster strikes, the traffic is routed through to DR site load balancer and correspondingly DR site database and file system are used.  So in normal situation we have 4 nodes sharing the load and during disaster we have 2 nodes taking the load.  Also when DR site is not available, primary site nodes take entire loads.

Fault Tolerant architecture:

This is very flexible and fault tolerant server setup. In parallel it ensures equal utilization of resources. This architecture has minimum human intervention requirement in case of disaster.

Failover:  In case of disaster, no special activities to be performed for server setup perspective.    External application and database connection url   may change due to disaster if external application also affected.  In that case configuration needs to be changed accordingly.   If server uses internal database, database url may also needs to be changed assuming database will be replicated using oracle dataguard or any other technology. If local dns entry is changed, then no need to change any connection url.

Failback: No intervention required unless, external urls invoked by servers also get changed due to disaster. Internal database connection url may need to be changed. If local dns entry is changed for local or intranet application, then you may not need to change anything.

Disadvantage: This 4 node active clusters works well when primary and DR site are in close proximity and connected with high speed network. Don’t use this type of configuration if the locations are far or connected with slow network. In that case some request will be served faster and some request will be served slower.  This configuration is not recommended in that case.