Our operations team has set network policies which require our hornetQ nodes be proxied by a single virtual IP; By way of example, HQ instances at 22.22.22.1, 22.22.22.2, 22.22.22.3, etc would all be represented as virtual ip 33.33.33.33, which in fact is round robin load balanced over each aforementioned instance.
When we configured the client for static discovery of the cluster at 33.33.33.33, we found that the HQ server connected to immediately reports the cluster topology (22.22.22.1, 22.22.22.2, 22.22.22.3, etc) to the client, which is problematic because the client is unable to access these IPs.
I've looked and can't see a straightforward way in which to configure a HQ cluster to work with a single virtual ip and still maintain high availability, failover, and scalability. I'm frankly wondering if the network policies are in need of revision to support HQ clustering rather than trying to shoe-horn hornetQ clustering into virtual ip load balancing.
So my question for this forum is simply this:
Can you configure a hornetQ cluster to work behind a single virtual IP and still maintain high availability, failover, and scalability?
Thank you for your feedback,
- Frank
