One of the major problems in the webMethods Integration Server cluster configuration is that it provides failover support only if clients connect using the webMethods Context and TContext classes, which is seldom the case.
If a majority of the clients connections are simple HTTP(s) connections, what is best way to achive failover support in the webMethods Integration Server architecture. Has anybody used an external clustering product to achieve something similar ?
We are using an external switch to load balance HTTP(s) connections. After evaluating the alternatives, this turned out to be the best and most scalable solution.
For scheduled task fail over, you can put the Integration Servers in a cluster and set the tasks to run in the cluster. This stores execution information for the scheduled task in the repository and an internal “webMethods” algorithm is used to determine which server will execute the task.
For SAP, I posted a note in another message a while ago. You should be able to find it if you search for it.
Also note that the risk of wmReopsitory2 being a single point of failure should be mitigated.
The WMRepository2 need not be a single point of failure.
In our production system (IS 4.6) we have the reposerver data stored in a SQL database on a Raid 5 disc array (the same disc array is also used for the SQL database that holds transactional and TN data), and run reposerver services on both our back end servers that also are running IS. Both IS instances can connect through both reposervers, so we have failover.
This set up is explained in the “Possible Locations for the Repository and the Repository Server” section in the ISClusteringGuide pdf.