First my apologies if you are already know all this but others may not. But to review, the broker process is made up of at least two processes. The awbrokermon which is the master controlling process and the individual broker servers. Both processes bind to ports. The awbrokermon port cannot be changed, 6850. The individual broker servers can be set to any available ports. 6849 is the default for the first broker server created but you can change that. Each broker server can have multiple brokers associated with it.
There are lots of ways to cluster the broker and it really depends on how you want your cluster to run. Active/Active, Active/Passive etc. It also depends on if you want to failover an individual instance of an IS server and associated broker or if it is an all or nothing. I’m making an assumption about running the IS and broker on the same box, your implementation maybe different. If not then your IS would be hitting the broker via a virtual ip address which would switch along with the broker on failover.
For an example assuming you wanted to implement an active/active cluster(not load balanced) but each node running multiple separate instances of IS and broker (we currently do 4 on our pair of Sun boxes). For the broker piece, you could configure the awbrokermon process to run on the local file system of each node. The actual broker server would run on a shared file system, obviously only mounted by one node at the time. The awbrokermon process would be responsible for running the active broker servers for that individual node via its configuration file. Your cluster software would be responsible for the failover of an individual broker server to the other node and back. Each unique broker server has its on port. On a failover of the broker server, not the awbrokermon which is already running on the other node, the cluster software would run the shell scripts + the (webMethods provided configuration scripts) to stop individual broker server, remove it from the configuration file of the awbrokermon process. Mount the shared file system on the other node, switch the virtual ip address, add the configuration to the running awbrokermon process which would then start the broker server process.
There are more details I left out around dependencies/relationships in your clustering software, startup orders, primary/secondary node etc. In practice this is pretty easy to setup and is reliable. Keeping up with ports is really not a big issue for us at least. It is pretty flexible in that you can run in an active/active configuration or active/passive and allows you to failover individual instances while not affecting the other instances. It also scales pretty well. But like I said, there are many, many ways to do this. This is just a suggestion that has worked for us. Your mileage can vary.
I’ve talked to webMethods support in the past about binding ip addresses and interfaces. They did not have a solution for that. It’s really more important in the IS layer which uses hostnames in it’s error logs. etc. On failover you can lose visibility into those without some behind the scenes work.
Hope this helps