Need some good discussion regarding pros & cons of the below.
In our environment we have a number of Broker HA clustering happening.
Now we are thinking of moving the Broker Binaries into a seperate directory in the Shared Volume.
The Shared volume has another directory for the Broker Data files.
Can I know what could be the possible loopholes with this approach ??
I know there might not be any run time issues with this but want to know why it is a standard practice to have binaries on the machine rather than having them on a seperate direcorry in the shared volume itself.
There is not much in it between local or shared storage.
One advantage of having local disk install of broker software on each machine is that you can do broker software upgrades in a controlled manner by firstly updating the passive server then manually failing over the active broker server to the passive server and starting up on the passive server. You can then upgrade the siftware on the active server and leave the service running. If the brokers do not start on the passive upgraded server then you can regress by starting on the active unchanged server and investigate the passive server at your leisure or restore it back to its original state before the upgrade. This same approach same approach is useful for hardware upgrades (memory, cpu etc). No real service downtime except for failover between active/passive which is goingg to be very little. Disadvantage is that you have to maintain two or more copies of the software.
Installing broker software on shared storage (SAN) will require you to stop the brokers for software fixes and upgrades and so stop the service while the broker software is being upgraded. If things go wrong then the regression path is more complex and requires a longer service downtime.
I prefer to have software executable files installed on local disk it does mean that I have to maintain multiple copies but in a cluster environment the passive servers can be worked on without effecting the service (no downtime) and you can spend more time taking backups, applying and checink upgrade software and other things. Regression is quick because you revert back to the active box if the passive box upgrade does not work so least disruption to live service.
By all means keep the configuration files on SAN otherwise you will have to maintain these files by manually copying them to the other servers if they change.
However, with 7.1 the Broker Monitor and Broker Server are tightly coupled with the software installation directory such that the awbrokermon.cfg file is saved in a fixed location within the software directory and the awbroker executable reads the awbrokermon.cfg file from the directory that it was run from in order to determine the Broker Monitor port and the IP Address to bind to. So for 7.1 the deployment will have to be thought out again depending on the clustering software. For HP ServiceGuard Brokers run in a service guard package definition with a VIP for the Broker Servers within the package so you can bind the Broker Monitor and Broker Servers to the VIP, very useful to bind to IP for firewalls between Brokers and application. This means that for each ServiceGuard package in the cluster a unique Broker installation will be necessary unlike 6.5 having a single install and the location of the monitor config file control by ACTIVE_CONFIG variable. Sorry I going off track.