Dear Team,
I have one production VM which I want highly available (not want any kind of downtime), can't use FT as it one support single core in ESXi 5.1 , is there any option / new feature available on ESX5.1 / esxi5.5, Need ur urgent assistance on the same.
regards
Mr VMware
I can't think of any native features as FT in version 5.5 still only supports a single vCPU.
What application is going to run on this VM? Perhaps the application can be clustered across more than one node?
Cheers,
Jon
What is running on it? IS it windows? Have you thought about Application level high availability?
Unfortunately FT in the current releases of VMware vSphere doesn't support more then one vCPU. Check this technical preview, which was shown on the VMworld 2013.
What type of application do you run inside the VM and why is it necessary, that this application has to be always available?
Yes its windows , and running SQL server and we want application or server highly available, request you to suggest some alternative
As you can't make any sort of high availability from VM side(without application downtime), it's best to make it high available from the application layer.
There is nothing new in ESX 5.1/5.5 which will help the VM suffering from (un)planned downtime. When you're talking about SQL, take a look at MS SQL Clustering or AlwaysOn. Anyhow it would require a 2nd VM, preferably not on the same ESXi host , maybe even datacenter.
References
VMware KB: Microsoft Clustering on VMware vSphere: Guidelines for supported configurations
VMware KB: Microsoft Cluster Service (MSCS) support on ESXi/ESX
http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Availability_and_Recovery_Options.pdf
http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-FAQ.pdf
Also don't forget to have a look at the best practices
http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Best_Practices_Guide.pdf
Hope it helps searching an answer for your question.
I agree with Wh33ly that Microsoft SQL AlwaysOn could be a solution for your problem. But you should note, that high availability is not only determined by a clustered server or database. Think about client connectivity or a logical failure inside the DB (e.g. corrupt transaction).