Why Is Local Disk Being Ignored In VDI Deployments?
11 comments, 2906 views
Over the past 6 months I have come to the conclusion we're ignoring an obvious way to drive down VDI costs - use local disk. I have brought this up a few times on Twitter and have seen a mixed response. Violent dissent from one part of my followers and violent agreement from others. Yesterday's debate on brianmadden.com is a good example.
One response pointed me to Dan Feller’s entries on the Citrix blog - Deciding on local or shared storage for your desktop virtualization solution and Local Storage or Shared Storage, That is the Question.
In both, Dan talks about using local storage to reduce the price point of VDI, but at the cost of losing some of the features we are used to, such as load balancing, live migrations of VMs, etc. This is what I would like to take a bit farther. Do you NEED those features for your desktops?
Recently at BriForum I posed the following questions to those who attended my session “Server Virtualization: Success, VDI: Not so much. Why?”:
- How many of you boot your normal desktops from the SAN?
- How many of you boot your terminal servers from the SAN?
- How many of you have an extremely short SLA on recovering your desktops?
Very few hands went up for the last question. None were up for the first two. I used this to frame a discussion around using local disk for virtual desktops hosted in the data center. Most of today’s VDI environments are using centralized storage simply because that is how the server virtualization platform was designed.
But if we stop and think about the actual requirements of the desktops being hosted - the required uptime, SLAs, RPOs and RTOs - we'd realize we may not need SAN for VDI.
Too often centralized storage is just assumed. And once it gets momentum, it's never changed. And then the project manger or VP of IT or CFO decides that VDI is expensive and that the storage cost is the reason. What to do, what to do!
Most people never get back to thinking about local storage for virtual desktops even though there are terminal servers hosting remote desktops in the next rack over. Why is this? Because we've bought into the idea that they REQUIRE Vmotion, or fast recovery with tools like VMware’s HA. But do you really NEED that for the desktop? If you lose a host server (a fairly rare occasion, thankfully) how soon do these desktops have to be back up?
What do you do now in Terminal Server environments? When the user gets disconnected, they click the icon again and they're routed to another desktop on another host. Why is this good enough for terminal services but not for VDI?
Local disk is ignored for a few simple reasons:
- Storage companies make a lot of money selling centralized disk and the software around it so they're pushing it for VDI
- The hypervisor’s “big” features require centralized storage
- Storage reduction and image management approaches like Linked Clones and Provisioning Server don’t work well (if at all) without centralized storage.
But with the price of SAN (which is the biggest knock on VDI), we should at least be bringing up the local storage topic in the discussion.
*Shameless, somewhat on topic, plug here: Unidesk works with local or centralized storage. Our disk savings and single image management features are not based on centralized storage volumes. So you can use whatever fits your needs if you are using Unidesk. I just happen to be a big fan of local disk, specifically local SSD.
Is local storage a panacea for VDI? Maybe not. But you can get the capacity and IOPS you need at a much lower cost, and probably even enter into high performance disk (like SSDs) for a much lower cost per desktop than you could with that array you're getting quotes for.
And, yes, you may need HA to recover your servers but do you HAVE TO HAVE IT for all your desktops? If your cost per VM for storage is $450 per desktop centralized and $29 per desktop when using local storage, is that enough to make local storage more attractive? Are you willing to sacrifice HA for that low of a cost?
I believe that local storage should be one of your considerations for your VDI environment. See if it fits and if you can get it to meet your true desktop requirements. Then give us a call. We’ll make it work.
-Ron Oglesby
Ron’s Politically Incorrect VDI Blog
Too many organizations are out there trying to implement VDI and failing. Whether you like what Ron has to say or not, he is here to say what others won’t about VDI and help you get it right in your environment. Get Ron’s advice… raw…unfiltered… without the sugar coating.
 |
Comments
Based on some worked examples I've done recently, you can deploy netapp storage for 1000 heavy users using VDI at about $50/Virtual desktop. That's less than the cost of direct attached 15K spindles, and less than the cost of a SATA drive installed a thousand desktops (especially after you throw in power and heat costs). You get this and still get better performance, scalability, data protection and manageability.
I cover the technical capabilities that allow this at www.storagewithoutborders.com
I totally agree with you. We already discussed this topic via email in the last weeks and right now I'm convinced that you have to use local storage to make VDI affordable.
We have done many TCO calculations on VDI for many customers and right now there is only one way to make VDI cheaper than to replace your existing desktops:
- pray that your customer is already using software assurance licences for his existing desktops
- don't replace the existing desktops with thinclients but re-use them as VDI endpoints
- use local storage VDI instead of shared storage
- don't buy the expensive VDI editions which include storage optimization (e.g. vcomposer). You don't need them and they won't save you any money...the discs you need to get the IOPS will give you enough capacity anyway.
That will bring your initial costs for VDI down to or below a desktop hardware refresh; which may be needed because of a upcoming windows 7 migration.
The problem with VDI is that too many out there think 'enterprise storage' but don't see the obvious. Even without HA, a VDI solution that uses local storage is still a damn sight quicker than recovering / replacing a physical desktop, so short SLA's should still be realised.
Just my two pennies worth.
Ray
I want to add more though, the conversation gets interesting. One of the things i hate about TS is you can't do dynamic load balancing, so no matter how good you build the environment, a lot of times you find one server being hit by performance while others are not. With VDI and shared storage we could avoid that with dynamic LB etc..
I agree with you though local disk should be considered, absolutely. However, some cases will warrant a shared disk.
Eli
nice though, discussion is how things get done!
Anyway: look, no one (here) is saying SAN/Centralized storage is BAD. Not at all. Actually here and in my talks I always note that if YOU NEED something like HA to meet your SLAs then you need SAN based storage. Or if you NEED replication for static desktops... then you need SAN.
My problem is the biggest line item in a VDI desktop is today.... wait for it.... the storage! yet somehow people are NOT buying VDI desktops because they complain they cost too much. Then reduce the biggest line item to make the desktop just as “redundant” as a terminal server and all the sudden the world is burning and VDI is no good. Too funny. Organizations will run terminal servers (serving up remote desktops...) in a rack RIGHT NEXT to VDI Hosts and those terminal servers are using local disk.... somehow that’s, OK but not for VDI?
Also for the 100 user thing: First off if you only need 100 users and ONLY have 1 server and no redundancy anyway... there is an issue. But to quote myself from a comment on brianmadden.com on this exact topic:
loss of a host from a hdw failure isn’t that common any more (not a monthly occurrence and if it is you need a new hardware vendor). Host servers are built with a pretty solid level of redundancy to ensure that. But let’s say you do lose a host.
What % of the environment is out?
How long is out?
Can you get the users to a new desktop w/ their workspace/personalized stuff ? and if so how long will that take?
Let’s say you have a 20 server 800 user environment. At 40 active desktops per host or so that can allow for 1 or 2 hosts to be out at any given time
Now in this environment if you have a hardware failure that takes down a single host more than once per year I would be surprised. But let’s say it’s an 8 hour outage 1 time per year of 1 server (this is a non-planned outage, not “OH a drive went red, let me replace it” type of outage).
8 hours out of 2000+ work hours per user.
800 users have 1.6 million working hours a year.
40 desktops out for 8 hours is 320 lost hours (this assumes you have to repair the server and not just move them to a "new desktop" with their "stuff")
The 320 hours is like less than three tenths of a % of non planned downtime. thats like 99.98% uptime.
So the question becomes... pay 2 or 3 or 5 or 10 times more for the storage line item for your VDI desktop to MAYBE turn that 99.98 into a 99.99....
see where I am going?
If you need it, use it. But then don’t complain about the storage cost. No biggie. But if you need centralization and VDI desktops, and can work with a system to drive the cost down, look at local storage.
With the advent of converged infrastructures and others things. Does local storage still make sense?
Eli
if the VDI deployment is leveraging some kind of a 1 to many solution (PVS, Linked Clones tec...) what many people are doing is deploying VDI in a 1 : 1 config which makes absolutely no sense but that is a different story. In that situation, managing it and backing it up locally is a nightmare.
Eli
And here we are again thinking that desktop virtualization is like server virtualization. I could write a whitepaper on this but here's an important thing to keep in mind. Server virtualization is a many to 1 relationship. Desktop virtualization is a 1 to many relationship. Anyone can use that 1 desktop, but everyone needs that 1 server up.
That being said...I have a way to use local storage and still provide as good HA as a SAN. Let's say I have 100 desktops running on a server and I need HA with a short SLA. Instead of relying HA migration to another spare server...why not run the spare server actively and have 200 desktops in the pool? If I have 1 server go down, users will re-login to the broker and immediately and get transferred to the server still running the spare desktops. You were going to have to have the spare server anyways if you were going to do HA migrations to running servers, so why not just run it in an active mode? Using this methodology you can have HA while leveraging local storage. The SAN storage alone will save you the cost of that extra server to keep lying around. And as far as management goes? Provisioning Server prevents me from having to do "double" the work even though I've doubled my environment. Everything managed with 1 image so it's a simple drag and drop over collections for updates so there's no additional management overhead.
Stop thinking like a server virtualization. Takeaway of the day.
While Ron and Brian make excellent points, you have to consider the reasons why you are doing VDI to start with. The value proposition.
VDI si not cheap, you will not save on CapEx etc.. but the value prop is you can backup your desktops, you have them in a secure environment, you can replicate them and leverage BC/DR for desktops which is always neglected.
There are many reasons why local storage even if cheaper does not mean is the best possible solution for VDI
Eli
What about something with a mix of both? Say a Virtual SAN living on the local disk and replicating across other virtual SANs? I heard of a few storage companies that are in the process of developing a virtual SAN for production use. The cost may or may not make sense or may not scale its all speculation.
Maybe UniDesk has some of this on their road map to make using local disk practicable or maybe you have a Tiered VDI where you let the customer choose how much down time they are willing to take. Class A VDI VMs get HA and DRS with Shared SAN no unplanned downtime normal maintenance for Windows Patches (reboot). Class B VDI VMs get Local Disk planned downtime once a month for x amount of hours with no special approval needed for change thickets (yes I spelled it right fell free to use it) and unplanned downtime for 8 hours .
Here’s a true story at work which supports the use of local disk. The Windows SQL team looked at Cluster servers, SQL running on Local Disks and SQL running in VMs. They found SQL had the least downtime running in a VM on a SAN. Running SQL on Local disks was a close second and running the SQL as a Cluster had the most downtime. They decided to Move most of their non-critical SQL databases to local disk, Critical SQL databases either went on a cluster or a VM.
-Rich
Post new comment