One of our client has a plan to go on virtulization.
So to my knowledge in the above virtulization scenerio we can only eligible to propose Application HA. As the above solution can provide best response for Hardware/OS failure.
Correct me if I am wrong for any point mentioned above. Suggestion required if we can improve the above solution with the help of Symantec product(s).
Another option is to install VCS in the virtual nodes. The advantage of this is you can fail an application from one virtual node to another virtual node that is already running, rathering than starting up the same virtual node like with ApplicationHA. Let me give an example (I know mainly about VCS, so some details about ApplicationHA and ESX may not be 100% correct):
You have applications A and B running in virtual node V1 and another virtual node V2
In ApplicationHA you would have A and B running in V1 and V2 would not be running and if app A dies, then I believe V1 is shutdown and started somewhere else (or with SRM maybe you can also startup V2 which runs apps A and B too) and hence this results in an outage for app B which didn't have an issue and also as well as starting app A and B, you have to start V1 (or V2)
In VCS you would have A and B running in V1 and V2 WOULD be running and if app A dies, then app A is started in V2 and app B remains in V1 and the failover is usually quicker than using ApplicationHA as V2 is already running, so you don't have to start V2. With this solution, VCS controls failover, not VMWare, but you can still vMotion virtual nodes and as well as virtual to virtual failover, you can also configure virtual to physical and physical to virtual
There is more info at:
So the only benefit is time saving.
As you said : Another option is to install VCS in the virtual nodes. The advantage of this is you can fail an application from one virtual node to another virtual node that is already running
This will really increase cost if we install Global Cluster in the virtual nodes. So its up to the client that does he bear the downtime while virtual machine will be up via Application HA or he cant bear the downtime of our services.
I think the time saving is quite small - it is more that VCS is more flexible. Suppose you have 4 SQL instances. With ApplicationHA, if you put them all in the same VM then if one SQL instance fails, then all the SQL instances will be failed over, so probably you might use 4 VMs instead and install each SQL instance in its own VM, but the you have 4 O/S's. With VCS as you move the individual SQL instance as you don't have to more the whole VM so this gives you more flexiblity - for instance if the physical node dies so you loose all 4 SQL instances, you could fail the SQL instances to different VMs if you wanted to, if for examples the VMs you were failing to were already running apps so you wanted to share the load.
With the flexibilty that VCS brings if you apps run just as well at the DR site as the primary site, then I recommend customers spread their apps across nodes at both sites and that way you are making use of the hardware at the DR site all the time and when you have a disaster (at Primary site OR DR site) then you don't have an outage for ALL your apps as some will already be running on the site that remains up.
If OS corrupted the same VM cannot be restarted at different ESXi host.
If ESXi host down all VM need to restart at other ESXi host which consume time but if installed VCS inside guest, the only time is failover process.
Application which is HA via VMware/ESXi may need to down when OS need to patch. in VCS case the Application can move to other node.
The link is correct, but the product for installing VCS in the virtual node will be VCS for Windows or Linux (depending on O/S in virtual host), not VCS for VMWare. There used to be a VCS for VMWare where you would install VCS in the VMWare hypervisor, but VMWare stopped supporting VCS in the hypervisor so this product is no longer available.
@Zahid : if OS is corrupted, i dont think any help from VMWare exist to start it. So the solution for this lies in starting from earleir snapshot and nothing else. If the configuration present in OS does not change after snapshot is taken, it should be okey to use the previously stored vmdks for the OS
If the ESXi host is down, i think VMWare will take up the failover action. With in-guest VCS clustering your applications will failover instantly (*), and VMWare will bring up the VMs eventually. the application can be up and running sooner.
I think what Zahid was pointing out is that if O/S is corrupted, then as with VMWare, with or without ApplicationHA, the whole Virtual node is failed over - you loose your app, but with VCS as you just fail over the app to another node (whose O/S is not corrupted), your app can remain highly available.
Likewise, with patching the O/S, if using VCS inside the virtual node, you can patch the inactive node, then failover app to patched node, but with VMWare (with or without ApplicationHA), you have to take down app to patch the O/S.