In Part I of this series we looked at why TCP disconnects happen during a Microsoft Quick Migration and why they stay alive using live migration or VMware VMotion. In Part II we’ll look at he financial impact this has on two different customers I recently met with in the Northeast US. Hopefully this will show why Quick Migration really isn’t good enough for really any application you have in the environment. Hopefully it will also show why live migration or VMware VMotion is a key building block to a truly dynamic datacenter.
Customer 1: Downtime is Money
The first customer in question is in the financial market. They have a unit that does a lot of trading on a daily basis (most banks and financial companies do as well). I’m just going to use one trading application as an example. The application in question moves a lot of money around all day long. The theory is that since it’s such a large sum that even a few minutes or even seconds at a marginally higher interest rate earns a ton of money. The theory works too. For this particular application the customer says that every 20 seconds of downtime equates to $800,000 in lost revenue for the institution. The application will sit at very low utilization for most of the day even though it’s still doing trades. Every once in a while the application spikes and gets really busy. This is a classic example of a prime candidate for consolidation using virtualization. The only problem is when the app spikes you might need to move it to a host with more resources. VMware’s dynamic resource scheduler (DRS) can see these application spikes and automatically initiate a VMware VMotion to another host in the environment that has enough resources. This is a classic case of where VMware VMotion or live migration from other vendors would come into play. This is also where Microsoft will pitch Quick Migration and where the client app will suffer from the inability of Quick Migration to keep connections alive. For this particular client the money lost with Quick Migration downtime will pay for all of their licenses of VMware with just one migration. From there on out they are making money and at the same time improving the agility and flexibility of their environment. That’s a truly dynamic datacenter.
Customer 2: Downtime is a Headache
You can probably see the business value working already for the above application. Now just to make sure you see the total value let’s look at another application at a different customer I met with earlier that same day. This customer is in the trucking industry. They have about 20 servers in their environment. They are actually 100% virtualized in their datacenter and are just now looking to implement a VDI solution and a traveling desktop solution (ACE) for their workers. One of the applications in their environment is the timecard system. The vast majority of their workers are hourly employees. The timecard system sits idle most of the day and runs on a server with a dozen other workloads. At shift change (which happens 3 times a day) the timecard VM gets very busy. Depending on where it is currently running, it may need to get moved to a different environment Obviously, you don’t want to be down during this migration since people are trying to clock in and get to work. There is a smaller financial impact but a larger productivity impact since they have hundreds of workers clocking in and out during these time periods. What’s worse is the popular time keeping system that they’re using will disconnect the clients (the card readers) during a TCP timeout and the only way to bring the clients back on-line is to manually go into a configuration screen and “disconnect” them and “reconnect” them – again, more loss on productivity. Taking this further is the fact that the application moves around automatically using VMware’s Dynamic Resource Scheduler (DRS) so the admin doesn’t have to be sitting there ready to login to the application and reconnect the clients all day long.
Conclusion
These are just two customers benefitting from a dynamic datacenter and leveraging VMware VMotion to build the environment. There are over 100,000 other VMware customers that have gone down this same path and expressing the same feelings – downtime while migrating a workload is unacceptable. Every other hardware-level virtualization provider in the market, with the exception of Microsoft, is enabling their customers to enjoy the freedom of no downtime migrations. It begs the question: Where is Microsoft’s Quick Migration really good enough? As a follow-up: Why would you want to go that route when every other hardware based virtualization provider can offer you no downtime migrations.
Tags: Microsoft, quick migration, vmotion, VMware
April 4th, 2008 at 7:02 pm
Reviving the Dormant Grand Architectures of IT with VMotion
Long-deferred vendor visions of agile data centers are finally coming true now that VMware virtualization with VMotion live migration has severed the ties that kept services fixed to x86 hardware. Unfortunately, some vendors are trying to stage a reviv…
April 7th, 2008 at 8:14 am
Er. Not quite
“This is also where Microsoft will pitch Quick Migration and where the client app will suffer from the inability of Quick Migration to keep connections alive.”
No. Corporately that’s not a place we’d put in Quick Migration, and any individual pitching that would deserve to get their backside kicked from here to Christmas.
If the application runs at $40,000 per second in downtime cost we’d (a) Dedicate enough resources to it, full time.
and (b) Make sure it was clustered at the application level – because a crash of the OS, application or virtualization parts would require a full reboot.
We can get into an interesting discussion the thrust of which is that VMware is further down the road with a vision of grid computing than Microsoft is.
It does seem that (as with the case with over committing memory – I notice you never came back with an “in production” customer btw) the VMware path seems to be one of spending more money on software and less on hardware, and then using the extra features of the software to work round the hardware limitations. You have to have a “grid” environment to do that to the full; the upside of a well developed grid means you can take servers off-line completely when you need less capacity. Whether using the servers more efficiently actually recovers the investment in software (and extra hardware for the grid) or not is interesting too – you’d probably argue “quite often, but not always” and I’d “Rarely but not never”
May 17th, 2008 at 10:24 am
James,
finally someone with a balanced view and argument. I work for an hardware vendor and often (always?) I have the same feeling about the VMware approach you have described.
Having this said I have also to report that a financial institution I have been working with a couple of years ago “had” to put the entire traders backoffice Windows servers on VMware ESX …. simply because there was no other (better) way to provide storage + server high-availability and DR capabilities for a string of 70+ physical heterogeneous Windows systems. And those systems were MORE than mission critical (hence the requirements).
Interestingly enough this customer was not even interested in being able to do VMotion… what I have described was the primary objective.
I think we all need to recognize that virtualization is really a disruptive technology. It’s not uncommon to meet customers nowadays that are virtualizing for the sole objective of being able to solve HA/DR issues rather than being able to consolidate or to move a live workload from a white box to another. Your strategy is good for a mission critical SQL database …. but when you have 70 heterogeneous not even cluster aware applications ….. MSCS on dedicated physical boxes just add complexity without solving the core problem.
Having this said again congratulations for keeping the discussion at a “polite” level (not commong on this blog I have noticed).
> “quite often, but not always” and I’d “Rarely but not never”
Right … similar to the glass being half full or half empty…
Massimo.