External Storage for Broker clusters - Virtual ou SAN?

, , ,
1

Hello.

We are building a new HA ESB under a virtual environment (in this case VMware ESX) where the Broker (7.1.2) is going to reside on a separate VM.

That VM is, in turn, cloned to the another VM which will act as a secondary machine which will be brought up when the other fails (and has been powered off).

My initial recommendation is to put the Broker’s DataStore external to the ESX, as a raw disk on SAN (FC at 2Gbps) which can be accessed by any of the VMs when needed, as this lowers the risk of data corruption because the system and the storage run independently of each other.

However I have seen some implementation where ESX managed storage was chosen which seems a contradiction, as a failure of the ESX can damage the VM and the storage.

What are your takings on these?
Do you have any of these scenarios in place and which shortcomings do you find in them?

Sag documentation does not seem to favour any approach in particular and virtualization systems have become quite resilient but even so I am concerned the integrated management of all storage under the ESX might not be the safest choice.

Would a network-access volume would be beneficial?
Which kind do you work with? (Sag suggests using NFS over TCP as one choice).

Best Regards,
Gerardo Lisboa

2

Gerardo,
I think you are on the right track to externalize your broker storage. You cloned VM would have to be synched anyway with the primary VM because of the transient nature of the broker storage (snapshots wouldn’t work well for that).

Never been a huge fan of just vanilla NFS over TCP for my realtime transactional storage although performance wise it has come a long ways. But I would defer that with my storage expert’s opinion. Give him/her the numbers, transactions per second, average payload sizes, availability requirements, failover speed, storage growth etc. You really don’t want latency in your access to the broker storage, that would be the key point.