Yet another question about clustering

, , ,
1

Greetings,
We are at the moment running 2 Integration Servers, each of which is hosting a complete set of all our B2B packages. We have enabled half of the services on IS #1 and the the other half on IS #2. We represent the IS’s to the Internet with DNS C-Names on very short TTL’s so we can enable the other half of services and change the C-name in the event of an IS failure.
(very poor man’s load-balance). The 2 IS instances are stand-alone and don’t “know” about each other.
Having now acquired approval from management for a BigIP, I would like to cluster and load-balance these IS instances.
So… my question is: Does anyone know if it is possible to enable clustering “after-the-fact” on these servers or do I need to rebuild?
In particular, I was planning to move the repositories from the standard built-in version to a common repository on a clustered SQL server that we have available, however, the clustering guide states that you cant move from file to JDBC-compliant. Does this mean that I can move, but need to start fresh with a new repository (ie: can’t migrate the existing one) or that it cant be done at all?
Also running SAP Adapter 6.5 (nearly all of our services talk to SAP), anybody have any tales to relate about clustering the adapters? The how-to looks pretty simple, just wondering if anyone has seen any “gotchas”.

Thanks,

Tim

2

Unless there is a specific reason to do so, I’d recommend not using IS clustering at all. Just add in the BIG-IP and enable all the packages/services on both IS instances. There shouldn’t be any issues with such an approach.

3

In fact this configuration seems superior to me. Having all the services enabled on all IS instances will facilitate easier maintenance, and (depending on the load balancing technique) will provide better dynamic load balancing depending on which half of the integrations need more resources at any given moment. The only exception to this “enable them all” philosophy that i can think of would be if you have a requirement for in-order processing.