Last week I read a few interesting articles about storage in desktop virtualization, VDI in particular. The consensus is that this storage belongs on local disk, not the SAN. One industry expert even says you can use SSDs locally and still get away for less money. I beg to differ.
Last week I read a few interesting articles about storage in desktop virtualization, VDI in particular. The consensus is that this storage belongs on local disk, not the SAN. One industry expert even says you can use SSDs locally and still get away for less money. I beg to differ.Blogger Brian Madden posted an article making the case for using local disk. Madden makes some good points, so kudos for starting a needed conversation. Industry veteran Ron Oglesby followed Madden's post, going one step further and suggesting that we can even use SSD and it will still be cheaper than SAN.
But I think they're missing a key point.
When talking local disk vs. SAN for desktop virtualization, the first thing that comes to mind for me is, Why are we even comparing these two technologies? Are we trying to save on CapEx expenditures to justify the project? If so, both Brian and Ron know very well that VDI does not deliver significant CapEx savings. Desktops have no data center footprint and have always been a decentralized model.
Desktop virtualization, however, will save you significant money on OpEx, which is where the highest spend tends to be. CapEx costs have been steadily going down and represent less than 20% desktop total cost of ownership, according to Gartner, IDC and others; meanwhile, OpEx costs have been steadily going up and represent more than 80% of total cost of desktop ownership.
Beware trying to justify a VDI project by showing savings in CapEx just to get it approved. You may well create an administrative nightmare in which you spend more in operational and management costs than you saved. And no, you can't hide that from the CFO for very long.
Rather than comparing local disk to SAN, then, we should be comparing how much it will cost us to refresh these desktops vs. the added SAN capacity. If you have to refresh desktops, then you must have money allocated somewhere. So let's look at the numbers.
Consider a midsize company that has about 2,000 desktops. To keep the math simple, I am going to assume each desktop will cost $500 to refresh, hence:
2000 x $500 = 1,000,000.00 (1 million dollars) x 20% (generous discount) = $800,000
So it will cost us this much just to refresh the hardware. I am not going into the costs of preparing the desktop or anything of that nature. Now let's examine both the local disk and the SAN options.
We are making the following assumptions:
• 45 VMs per host
• 2 GB memory each
• 12 IOPS
There are other very relevant metrics, but for costing purposes we will stop here, assuming the rest is equal between the two scenarios.
Solution 1: VDI Using Local Storage
To support 2,000 VMs with 2 GB memory each and 12 IOPS using local storage, our calculations are as follows:
2,000 VMs / 45 = 45 hosts (rounded) + 3 extra hosts for HA = 48 total hosts.
2,000 VMs x 12 IOPS = 24,000 IOPS total required
To achieve this IOPS level, we will need our 45 servers to be populated with eight local disks (Brian mentioned eight in his article) at 300 GB each with 15,000 RPMs. We ran a quick config on Dell's Web site for a 2U server with those specs and the price came out to about $16,000 per server. Considering we need 48 of them, the total came to $768,000. With a generous 20% discount for special pricing, our final total price for this config comes out to $614,400
Assuming we will have a RAID 10 configuration in these servers for best performance, that will cut the number of spindles we have from eight to four, and considering we get about 170 IOPS per 15,000 RPM HDD, the math is as follows:
192 spindles x 170 IOPS = 32,640 IOPS
This is more than adequate to handle the load based on the requirements we suggested.
Now, I am hoping that Brian and Ron are not suggesting we don't use any sort of RAID with local disk, because that would mean eight different data stores if we are using ESX, and a entire mess when using Citrix PVS, but especially if we are using linked clones.
Solution 2: VDI Using SAN
Now let's take the same example and price it out as well to see how it becomes different. The server calculation changes slightly as we add a single dual-port 8 GB HBA in each server and 2 RAID 1 HDD.
48 x $12,000 = $576,000 - 20% = $460,800
The storage, however, looks like this:
We calculated the cost of a Hitachi AMS 2500 with 408 HDD (600 GB 15k RPMs) in order to get 30,000 IOPS; our calculations after special pricing came to $400,000. The total cost of Scenario 2 comes to $860,800.
That's a deficit between local disk and SAN of $246,400. If we compare this with the cost of a desktop refresh, you will notice that there is no CapEx savings as we stated earlier, unless you go down the local disk route.
So let's take a closer look at the challenges you will face using local disk.
The first thing that stands out is you cannot use blade technology, so if you are deploying these 48 servers, you will need 2.5 racks, at least, if you can find 1U servers that take 8 local disks, or 3.5 racks if you are using 2U servers. Now you also have to factor in the network infrastructure costs to support these 48 servers. However, going down the SAN route, one could easily use blade servers in a single rack. Of course, you will need at least 2 racks for the storage trays as well in this configuration.
When deploying an enterprisewide solution like desktop virtualization, the total cost of ownership is not the only metric that should be used to measure viability. One should also take into consideration the longer term cost of maintaining this environment.
The scenario that suggests local disk neglects the fact that servers typically are on a three-year refresh cycle. In this case the cost of deploying the environment with local disk will be incurred every three years or so. On the flip side, SANs have a much longer lifecycle within any enterprise organization. SANs can go anywhere from five to 15 years, thus maximizing the investment made.
There is one other thing I want to mention about SANs: The hard drives that are delivered within SANs are much better architected and have a longer life span than those available with servers. There is a lot we can get into about hard drive manufacturing efficiencies and everything that goes into it. That is a topic for another discussion, but not all hard drives are manufactured equal.
Let's examine area where the use of a SAN maximizes efficiency. In a local-disk model, how do you maintain your servers? From a patching perspective, hardware perspective, the only way is to schedule downtime for the desktops on these servers. Sure, you will say right away, we can use some of the spares, true, but if those spares are also put into production (as they should be if you go down that model) then you would have to manually load balance your VMs across all remaining hosts. You would need to go through this exercise every time you want to do any maintenance task on your host.
One of the advantages of a SAN is that you can migrate all VMs and redistribute them appropriately at any time of the day, and run your maintenance. Contrary to popular belief, most IT people don't enjoy working after hours and would appreciate any technology that allows us to complete all our tasks during the normal business day so we can go home.
Another metric to consider and add to the local disk scenario, is how many extra hours your employees will register supporting this environment?
Efficient Resource Usage
The whole idea behind virtualization is the effective utilization of resources. When we deploy a local-disk scenario, we are not using our storage resources efficiently. Let me explain. If your SAN is configured correctly, you can utilize the full spectrum of spindles that are available to you in order to complete any given task in a timely manner. The idea of a SAN is that you can move these workloads or schedule them to run at a different time of the day where they can get access to as many spindles and render the best performance.
Let's take our local disk example. During business hours, local disk resources will be utilized. However, as the business day comes to a close, users will tend to use their desktops less often and all these local resources are going to waste.
A SAN can take advantage of these resources and dynamically balance them during the day, but can also take full advantage of them after hours if there was a need to run certain disk-I/O- intensive applications.
An IT manager's role is not to look at projects in an isolated way but rather try and find ways to maximize the IT infrastructure, as it is a single entity that delivers IT as a service.
Dynamic Load Balancing
When deciding to use desktop virtualization and VDI in particular for an enterprise of 2,000 desktops, you want to at least know you have the flexibility of having this infrastructure load balance itself as it needs to. In the Terminal Services days, that was always one of the downsides as we could not load balance resources without having them disconnect. vMotion solved this problem for in VDI. Having the ability to load balance VMs across the least busy host is not a nice to have, it is a must have.
The alternative with local disk is what? Manual load balancing? Can someone tell me how that would work? Ruben Sprujit presented a valuable piece on storage design as well.If we are using Sprujit's document as the basis for our discussion, he suggests different profiles for different users. Power users will use more IOPS, So what do we do? Isolate power users on dedicated hosts? That would require more hosts as the IOPS requirements increase.
A mixture on the same hosts? And who would manage that? And how do you scale? Do you really want to go backwards and not use all the advancements that virtualization has brought to the table?
The Final Analysis
If you are going to do so much manual work when using local disk as your VDI design, then what is the point of virtualizing? You may as well stay on physical desktops as they require as much support.
It all comes down to why you are considering desktop virtualization. If you are doing it because you want a better way of supporting and managing desktops, then great. But if you are doing it just because it is the hottest thing and you don't have the right budget, then take a step back.
Local disk could play a role in environments where you are virtualizing fewer than, say, 500 desktops. But for larger enterprises, local disk is just not a viable solution.
And one final thought: In a world moving more and more toward converged infrastructures and private and public clouds, I am not sure that suggesting local disk is in the best interest of enterprise organizations.
Elias Khnaser is the practice manager for virtualization and cloud computing at Artemis Technology, a vendor-neutral integrator focused on aligning business and IT. Follow Elias on Twitter @ekhnaser
The Agile ArchiveWhen it comes to managing data, donít look at backup and archiving systems as burdens and cost centers. A well-designed archive can enhance data protection and restores, ease search and e-discovery efforts, and save money by intelligently moving data from expensive primary storage systems.
2014 Analytics, BI, and Information Management SurveyITís tried for years to simplify data analytics and business intelligence efforts. Have visual analysis tools and Hadoop and NoSQL databases helped? Respondents to our 2014 InformationWeek Analytics, Business Intelligence, and Information Management Survey have a mixed outlook.
Top IT Trends to Watch in Financial ServicesIT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Join us for a roundup of the top stories on InformationWeek.com for the week of September 18, 2016. We'll be talking with the InformationWeek.com editors and correspondents who brought you the top stories of the week to get the "story behind the story."