6 Replies
Last post:
Sep 24, 2008 1:47 PM by
ganesh
I agree that vLockstep (Virtual Lockstep) is a bit misleading when you compare it to a true hardware lockstep system.
I wonder if VMware FT is really a "wow" feature? In the FT break out there were page after page of limitation. VMware was very upfront in the breakout (less so in the keynote) about limitations. Some of the low lights include:
It is interesting that VMware mentioned as an after thought in the ft breakout - ESX is currently shipping on real fault tolerant servers - when you consider that they are available today, can run full SMP apps (ie Oracle), priced about the same as a cluster, and much higher availability...... seems like the better solution fault tolerant VMware solution is already in the market.
I wonder if VMware FT is really a "wow" feature? In the FT break out there were page after page of limitation. VMware was very upfront in the breakout (less so in the keynote) about limitations. Some of the low lights include:
- Single core support only - although they say single processor - when pressed they admit that means single core. Hence a typical dual socket/quad core (8 cores) can only use ONE core for VMware FT
- One ftVM per server - due to the overhead and latency issues - you can put more than one VM with FT on that 8 core server)
- Overhead upto 20% - wow
- Pair of servers required - seems to go against the server consolidation concept.
- Mid Tier applications - due to all the limitations - VMware does recommends some of the mid level critical apps - don't try this with your Oracle database.
It is interesting that VMware mentioned as an after thought in the ft breakout - ESX is currently shipping on real fault tolerant servers - when you consider that they are available today, can run full SMP apps (ie Oracle), priced about the same as a cluster, and much higher availability...... seems like the better solution fault tolerant VMware solution is already in the market.
Re: Fault Tolerance - 'wow' feature; bad name
Addressing your points:
- Single core support only: This is misleading. The only limitation is that we support single vCPU VMs. However, multiple FT VMs can be deployed across all physical processors on the server .... without limitation.
- One ftVM per server: This is a false statement and was not stated in the breakout. The number of FT VMs per server is NOT limited to one. Much like sizing the number of VMs per server is governed by load requirements, the number of ftVMs depends on load. Typical configurations will support at least four ftVMs and more.
- Overhead upto 20%: This is the worst-case scenario - the actual overhead is dependent on the workload and can be as low as 5%. Unlike StratusFT, VMware FT runs on the latest processors from Intel and AMD the day they ship and can use these same hosts for FT and non-FT workloads.
- Pair of servers required: In the end, fault tolerance involves redundant components to guarantee against failure. Is it better to have a single, expensive server or to have multiple servers whose aggregate cost is less than that single server?
- Mid Tier applications: While VMware FT is not for all workloads, VMware has found that there are many mission critical apps that must be ALWAYS available. VMware FT allows an enterprise to deliver the benefits of continuous availability to a broader set of applications. Many enterprises today have developed infrastructure architectures to ensure continuous availability of the database platform. VMware FT may not be the right answer for the most demanding workloads, but it may be ideal for the dozen of application workloads built on that database. In the end, it is those applications that the user relies on ....
- StratusFT: StratusFT is a hardware platform that supports ESX. It delivers hardware fault tolerance within the Virtual Infrastructure. The addition of VMware FT extends continuous availability to more of the enterprise.
I sat in on the session on VMware's FT product which was held right after Tuesdays key note. The engineer who gave the presentation (Dan) was very open about what this product can do. In fact there seems to be more limitations then what marketing would lead you to believe. First, it's not available yet, second you gave no pricing. But the real limitations come from the fact that you can only scale to a single core. According to what we were told (I took copious notes) an application can not scale to more then one core (he said CPU, and that was clarified to mean core).
According to your response you say - multiple FT VMs can be deployed across all physical processors on the server .... without limitation. So what you are saying is you can take an application like SQL and run it on a quad core CPU in FT? Taking advantage of all 4 cores? Or are you saying that you can run multiple apps across a CPU, each utilizing a single core? It does make a big difference.
According to your response you say - multiple FT VMs can be deployed across all physical processors on the server .... without limitation. So what you are saying is you can take an application like SQL and run it on a quad core CPU in FT? Taking advantage of all 4 cores? Or are you saying that you can run multiple apps across a CPU, each utilizing a single core? It does make a big difference.
Is vLockStep a continuous copy of primary to secondary? Or is it really LockStep similar to hp NonStop or Stratus ftServer, but done at hypervisor/software level?
This technology definitely protects application from x86 failures in one physical machine. But what about OS, application failures and non-availability due to performance issues? Looks like running two/multiple instances of application on two independent OS which share almost nothing on two independent hardware is a more complete HA solution. And, what percentage of failures are due to hardware vs OS & application?
Sateesh: it's like lockstep but done in software, rather than a
continuous copy. It will mirror execution, so if your OS on the primary
guest crashes, backup will crash the exact same way. The FT solution
doesn't change software reliability (similar to other HW FT solutions,
I would imagine). Your HA example is not really apples to apples, as HA
loses state whereas FT doesn't lose any state. You can use VMware Fault Tolerance in conjunction with VMware HA, though.
continuous copy. It will mirror execution, so if your OS on the primary
guest crashes, backup will crash the exact same way. The FT solution
doesn't change software reliability (similar to other HW FT solutions,
I would imagine). Your HA example is not really apples to apples, as HA
loses state whereas FT doesn't lose any state. You can use VMware Fault Tolerance in conjunction with VMware HA, though.
