There are key considerations for deploying failover technology in Sterling B2B Integrator.
For all of these scenarios, key considerations are:
- Making sure that the machine configurations remain correctly synchronized (to whatever degree is needed), which may include maintaining differences as well as propagating changes. This is particularly critical after a failure, when repairs may involve configuration changes.
- Making sure that the partial failure scenarios are handled properly. In particular, network partitioning in which the cluster management software sees a failure, but the node is actually still running and is possibly accessing the database.
- Evaluating what the correct actions are in the case that disk takeover occurs, but the filesystem is corrupted and must be repaired. With modern journaling file systems, this is less of a problem, but it does happen, particularly in a heavily loaded environment.
- The failover capabilities must be tested and the level of assurance that it will work each time is much lower than with an active-active type cluster when both nodes are functioning all the time. This can make testing failover a risk in itself.
The most common scenarios for deploying this kind of failover technology are:
- Sterling B2B Integrator is configured to fail over to a development or test environment. This gets maximum utilization of hardware and with a test box, can help justify the expense of making it identical to the production box. This approach, however, does increase the risk of divergent system configurations.
- Sterling B2B Integrator is configured to fail over to a box that does nothing else except serve as a failover platform. This works well when a single failover platform serves several production systems (although this entails risks of its own).
- Sterling B2B Integrator is configured to fail over to a system running another application, often the database server supporting the application (with the database server also being configured to fail over to the Sterling B2B Integrator platform). While attractive from a cost standpoint, combining applications, even in a failure scenario can often result in inadequate performance.