VSA Cluster Service Considerations

Some changes have been made to the vSphere Storage Appliance (VSA) Cluster Service in version 5.1. Previously, the VSA Cluster Service was installed on the vCenter Server – there was no way to decouple it. However in VSA 5.1, the VSA Cluster Service is a stand-alone entity. It can still be deployed on the vCenter server, but it can also be deployed outside of it.

As a reminder, the VSA Cluster Service is only necessary in two node configurations. It is not necessary in three node configurations. The VSA Cluster Service provides the tie-breaker code in a two node configuration – it provides the additional vote, which when added to the votes from the VSA nodes, provide 3 votes in the cluster. If one VSA node fails, there is still a quorum of cluster members to keep the cluster running.

The main reason for decoupling the VSA Cluster Service from the vCenter server is to enable ROBO – Remote Office, Branch Office deployments. In these configurations, the vCenter server will typically reside at a central office, and the VSA cluster will reside at a remote office. With three nodes at the remote office, there is no need for the VSA Cluster Service. In two nodes configurations, the VSA Cluster Service is required. And more importantly, the VSA Cluster Service must be deployed at the remote office, on the same subnet as the VSA. If you deploy the VSA Cluster Service on your vCenter server at the central office, and try to use it as the tie-breaker for a remote two node deployment which is on a different subnet, you will get this ‘Cannot Create VSA cluster’ error:

Therefore you will need to deploy a Windows or Linux VM or host at the remote site on the same subnet, install the VSA Cluster Service on that OS, and point the VSA installer to it. This is significantly different to the way things worked in VSA 1.0. In that version, one simply picked a unique IP address for the VSA Cluster Service, and the installer took care of plumbing up that IP address on the vCenter server. In version 5.1, when populating the VSA Cluster Service IP address, you use the IP address of the vCenter server if that is where the VSA Cluster Service is installed. Otherwise if you simply select a unique IP address like you did in VSA 1.0, you will get the error:

Cannot create VSA cluster: Unable to login to VMware Cluster Service at: https://aa.bb.cc.dd:4336/services/pseudosvaservice. Please ensure the service is up, and retry.; nested exception is:
java.net.ConnectException: Connection timed out: connect

The point is that the VSA cluster service must already be installed and running at the IP address you provide before you can proceed with the installation.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @CormacJHogan

5 Replies to “VSA Cluster Service Considerations”

  1. I find this a bit odd. If I have a branch that has no users and I just want to install two nodes in it without shared storage (in this case witness servers for a sql cluster I want in a third site) this means I am going to have to install the VSA cluster service on a machine on local storage which has no HA and in the case of failure will not vote anyway. It seems to me it would make far more sense if the cluster service did exist on the VC in the main site. So even if they lost connection to each other they could still see the service. Or are you saying in the above deployment I mentioned I should install a minimum of 3 servers.

    1. Remember that vCenter can now manage multiple VSAs. I’m guessing one of the reasons for having the VSACS locally and not on vCenter is to allow for this scalability.

  2. Cormac,
    Thanks for posting this article since I can’t seem to find any information out there with VSA in 5.5. I ran into this error and I’m still confused after reading your post. So the resolution here is just to deploy a Windows box with the IP address of the VSA Cluster Service and install VSA Manager on that box before you can configure VSA?

Comments are closed.