Recently both NetApp and EMC published VDI whitepapers with our mutual partners VMware and Cisco. Both papers are very solid and should result in robust infrastructures; however, the solutions are far from equal and I’d like to take 5 minutes of your time to share with you some interesting points of comparison.
Sure the EMC paper focuses on UCS platform while the NetApp paper focuses on a Nexus infrastrucutre, but that’s not what I want to discuss. Yes, the EMC architecture running on Fibre Channel over Ethernet and the NetApp solution is leveraging NFS, but that’s not what I’d like you to consider either.
The level of differentiation I want to highlight is the cost per desktop in both of these solutions. Why cost? Simple, it is the number one hindrance to virtual desktop adoption.
I want to begin by sharing that I love the UCS and Nexus platforms. Cisco, you are top shelf!
For potential VDI customers looking for mission critical deployments I’d like to compare the differences in the NetApp and EMC solutions. Note these numbers come directly from the published documents of each vendor.
Note: Chart Revised since original post where I accidentally counted spare drives as storage drives
I Want my Intentions Clearly Stated
This review demonstrates the native capability of each storage controller to address the needs of a virtual desktop environment. I believe the V-Max has demonstrated that it can scale to significant capacity and scale.
By contrast, the NetApp array with integrated data deduplication, Intelligent Caching, and FlexClone and vCenter integrated tools like the Rapid Cloning Utility provides a more flexible, scalable and available architecture. For these reasons I believe the NetApp array is a better platform for Virtual Desktop Infrastructures.
If you have a V-Max in house, consider running it with Data ONTAP via our vSeries and you too can experience these savings (minus RAID-DP). You’ll transform a robust, yet traditional, storage architecture into a dynamic virtualized storage platform.
Making VDI a Reality
We are focusing on delivering storage for VDI at $75 per desktop. If you’re environment requires less than 8 IOPs it’s possible we can reduce that price. I expect big news around VDI next week at VMworld. If you are attending the show, stop by our booth. We’d love to share more details with you. The authors of this whitepaper will be in attendance.
Tip: Ask one of the technical staff for a hands on demo.
Remember, Virtualization Changes Everything… including storage!
There you go again … talking about things without knowing the facts … Vaughn, that UCS/VMAX paper was designed to showcase UCS scaling. The VMAX was purposely oversized in order to take it out of the equation, so that we could keep the focus on the scalability of UCS. At over 2x the desktop density as compared to comparable blade systems, it certainly impressed! If you want to see a study that shows EMC’s efficiency when taking array tuning into consideration, you should look at VMware’s own View Reference Architecture that they picked to run on an EMC Celerra. In that reference architecture VMware showed that a 1000 desktop building block could run on only 20 drives (it was a 30 drive config, but only 20 drives were used for desktops). It should also be pointed out that VMware included the following comment.
“The overall design also included the infrastructure components needed to integrate five building blocks, to support a 5,000-user VMware View pod that can be managed as a single entity.”
Note that the array used was our lowest end NS and is already a generation older than our current model. Additionally we just published a paper showing that we can run 1000 desktops on only 5 EFD drives and only a small fraction of the power to run.
One final question. If you were to fully deploy 2000 desktops with no data reduction technologies, then 2000 10GB images would equate to 20TB of disk. Your config required 25.2 TB of FC drives. So what exactly did dedup save you again? Where are your disk savings? Our EFD example deployed 1000 desktops on only 2TB of raw capacity.
I’m actually glad that you’ve decided to focus exclusively on “cost per desktop”. That’s what VDI is all about, right? Saving money without worrying about delivering other forms of business value?
You’ve decided to compete with $50 desktop drives from BestBuy.
Best of luck with that.
— Chuck
Chuck,
What we have been doing all along with our VDI solutions is to knock down barriers to adoption, while providing customers the flexibility to deliver great virtualized desktop services.
1) We’ve continued to highlight scalable architectures that are endorsed by both VMware and Cisco, as well as our other virtualization partners.
2) We’ve addressed the challenges of integration for both Desktop and Storage Administrators with our RCU product and it’s integration with vCenter and ViewManager.
3) We’ve addressed the challenges of performance spikes and ncertainty (BootStorms, LoginStorms, AVStorms, etc.) with our Intelligent Caching.
4) We’ve continued to address the importance of Storage Efficiency to help manage the Total Cost of Desktop Ownership, being the only company in the industry to guarantee savings for customers.
5) We’ve provided an end-to-end architecture that is inclusive of Backup and Disaster Recovery (SRM, SnapMirror, etc.).
6) We’ve addressed the operational challenges of mixing complex business application workloads (including Virtual Desktops) by delivering solutions that are consistent across platforms, across tools, and throughout the architecture.
So this is NetApp addressing another level of eliminating barriers and delivering value to customers that want to add Virtual Desktops to their Virtualized Data Center. Cost of acquisition is just one element of the overall cost. Customers looking at NetApp virtalized solutions can now check that off their list.
Aaron,
The intention of this post, and others, is full disclosure; I would like to ask the same from EMC. I believe your reply is unintentionally blurring reality.
In my haste to publish I inadvertently included 14 disk drives that were un-configured, or spares, which were not used in the testing or design considerations. In all honesty, it would have been a wise move for NetApp to have removed these drives from the systems. Alas, we are all human. I have adjusted the comparison chart to reflect the drives that were in use. If you feel that the EMC numbers should be adjusted please share the details and I will update the chart accordingly.
In response:
1. Are you willing to state that 1,000 users can run in production on 20 drives? While any vendor can deploy 1,000s of linked clones on a single drive the challenge is providing IOPs.
2. Are you stating that the user’s data (either home directory or user data disks) were included in the 20 drive configuration?
3. Where is the accounting for the Delta Disks? As you know these grow in size incredibly fast. I’d warn that claiming VDI scaling without accounting for delta disk capacity might be perceived by some as a bait and switch.
Reader data point: delta disks are differential files used by each link clone desktop in order to log their SCSI commands. These files grow and require storage capacity up to the logical capacity of the desktop.
4. The joint EMC View white paper had 64 clones per datastore. By contrast the joint NetApp View paper demonstrated the ability to clone 250. Why is that?
5. I agree EFD is awesome for deduplicated environments, but its use with linked clones still requires the capacity for delta disks. May I suggest you read the View Administrator guide in particular the section entitled ‘Desktop Refresh.’
6. If EMC didn’t support running 640 desktops on 38+ TBs of storage then why would you publish this document?
7. Why does this document show this use case drive the disk IOPs to the 50% range. I believe it implies that a V-Max with 128 15k drives can handle 640 users each with a 5 IOP workload. Would you agree that this load seems a bit light?
Sorry to be brief – my flight is departing…
Aaron:
There you go again … talking about things without knowing the facts … Vaughn, that UCS/VMAX paper was designed to showcase UCS scaling. The VMAX was purposely oversized in order to take it out of the equation, so that we could keep the focus on the scalability of UCS. At over 2x the desktop density as compared to comparable blade systems, it certainly impressed!
AJ:
Great to see the power of Cisco UCS to drive down cost per desktop without any performance penalty.
Aaron:
If you want to see a study that shows EMC’s efficiency when taking array tuning into consideration, you should look at VMware’s own View Reference Architecture that they picked to run on an EMC Celerra. In that reference architecture VMware showed that a 1000 desktop building block could run on only 20 drives (it was a 30 drive config, but only 20 drives were used for desktops).
AJ:
VMware View Ref Arch: http://www.vmware.com/files/pdf/resources/vmware-view-reference-architecture.pdf
EMC NS20 Deployment Guide: http://www.vmware.com/files/pdf/resources/vmware-view-ns20-deployment-guide.pdf
The VMware View Ref Arch is an excellent paper and showcases the strength of “VMware Linked Clones” to achieve storage efficiency and desired end user experience. I didn’t see any EMC storage efficiency highlighted. Also, the associated NS20 deployment guide shows using 29 spindles for hosting 1000 desktops (including all the data components – VM C: drive + CIFS home dir), not 20 spindles, with one hot spare. This includes 8GB as the VM C: drive, and 0.5GB per user for CIFS home directory, and about 3 IOPS per desktop for 975 desktops created using linked clones. [180*16/975]
VMware also included the following comment in that paper:
“All the physical infrastructure components used to validate this reference architecture are interchangeable. This means customers can use their vendor of choice for any physical component of the architecture, including the network, storage, and server components. Various vendors might offer or include unique features that further enhance the value of the overall VMware View offering for a particular enterprise.”
To see how NetApp complements the power of VMware Linked Clones to further drive cost per desktop down and maintaining same end user experience, check out the following 1000 seat VMware Linked Clone Ref Arch on NetApp.
http://www.vmware.com/files/pdf/resources/VMware_View_on_NetApp_Unified_Storage.pdf
It showcases 1000 desktops with 10GB per VM C drive, 2GB per user for CIFS home directory, and about 7 IOPS per desktop for all the 1000 users. All this with only 24 spindes, as we didn’t need spindles to serve up all the 7 IOPS per desktop. Thanks to NetApp dedupe aware intelligent caching that significantly reduces the disk IOPS. The demo showcasing power of intelligent caching to reduce spindle count for 1000 desktops scenario should be posted on NetAppTV channel on You Tube on Monday. If we did the sizing based on 3 IOPS per desktop and 0.5GB CIFS user data, the number of spindles would have been significantly lesser. Also the Ref Arch showcases the value of NetApp dedupe for all desktop data components – the linked clone parent VM, ‘user data disk’ for 500 VMs, CIFS home directory for 500 VMs. NetApp dedupe also provides great value for linked clone OS data disk as new writes happen and they start to grow and/or new ‘replica VMs’ are added in the datastores after patch/upgrade/new baselines.
Aaron:
It should also be pointed out that VMware included the following comment. “The overall design also included the infrastructure components needed to integrate five building blocks, to support a 5,000-user VMware View pod that can be managed as a single entity.”
AJ:
VMware Linked Clones on NetApp Unified Storage: http://www.vmware.com/files/pdf/resources/vmware-view-reference-architecture.pdf
Page 18 of the VMware View Ref Arch reads as…
When validating VMware View reference architecture designs, it is important to simulate a real world environment as closely as possible. For this validation, we built and validated each component of the virtual infrastructure needed for one 1,000-user building block using a simulated workload. We also implemented the networking and load balancing components of the access infrastructure needed to support a 5,000-user VMware View POD.
The statement in bold clearly states that the core network is capable to support “five 1000 user building blocks”. Each building block had one NS20, but this does not necessarily mean you need five NS20s for 500 users nor it means that you need one NS20 for 5000 users. You would definitely do IOPS and capacity sizing to determine how many controllers and spindles you need.
Aaron:
Note that the array used was our lowest end NS and is already a generation older than our current model. Additionally we just published a paper showing that we can run 1000 desktops on only 5 EFD drives and only a small fraction of the power to run.
AJ:
That’s great. Would love to see that paper. Do the 5 EFD factor in both the performance and capacity requirements for a real world 1000 seat VDI environment. What was the per desktop change rate (GB) and “CIFS” or “User data disk” requirement for this user profile (knowledge worker/task worker/administrative worker), what percentage, and what was the IOPS requirements? Were all these data components hosted on the 4D+1P EFD config? Each desktop although created thin using VMware linked clone, NetApp FlexClone or EMC array cloning (Celerra, iSCSI only today), will consume some unique storage over time, consuming EFD space. NetApp dedupe strongly complements VMware linked clones, NetApp FlexClones, and EMC cloning (behind NetApp v-series) and we can dedupe all these desktop data components even on EFDs i.e. linked clone OS data disk, user data disk, CIFS home dir, NetApp FlexClone, EMC clones (behind NetApp v-series). But you could have run the 1000 seat workload “IOPS simulation” using 5 EFDs. Did the storage architecture address all these practical considerations? If yes, how did the cost per desktop differ in the EFD solution over FC disk based solution (assuming same IOPS and capacity requirements per desktop for EFD and FC)?
Aaron:
One final question. If you were to fully deploy 2000 desktops with no data reduction technologies, then 2000 10GB images would equate to 20TB of disk. Your config required 25.2 TB of FC drives. So what exactly did dedup save you again? Where are your disk savings? Our EFD example deployed 1000 desktops on only 2TB of raw capacity.
AJ:
20TB usable storage in your example would not equate to 20TB raw. It would be more than 25TB raw if you did proper real world sizing (either for EMC 4+1 RAID-5 sets as used in all the deployment guides, or the NetApp 14+2 RAID-DP sets).
The VMware/NetApp/CISCO Ref Arch is based on real world VDI considerations for both capacity, and performance. From storage perspective, this translates to being able to meet IOPS requirements (which in this paper is 8 per desktop, what was yours?), and desktop capacity requirements (for VM OS disk (10GB) created using mix of VMware Linked Clone and NetApp FlexClone, Linked Clone User Data Disk for 250 users (2GB per user), and CIFS home directory for 1750 users (2GB per user)). As you note in the paper, there are plenty of spares (14), and root disks (6) in this config.
Therefore, the number spindles we required to host all the desktop data components and consider some room to growth for contingency and beyond what we considered, then we required only 64 spindles. To meet the 8 IOPS requirement per desktop and discounting NetApp dedupe aware intelligent caching (which benefits for normal day to day workloads, and bursty operations like boot storm, AV scans etc) , and not considering desktop OS disk, user data and any contingency scenarios, we would need only 54 spindles to simulate this workload. Therefore, the spindle requirements were dictated by performance requirements, capacity requirements and real world considerations. From data reduction perspective, we were able to show NetApp dedupe savings for different desktop components i.e. linked clone user data disk, OS data disk, and CIFS home directories which works across all protocols on all NetApp storage arrays.
Which EMC data reduction technology did you use for these 1000 desktops on EFDs to complement VMware Linked Clones, use data disk, and CIFS home directories? Again, would love to see that paper!
Do we agree that Linked clones work equaly on all storage arrays? I beleive the answer is yes. So…
V-Max is storage which could be replaced with any storage correct without negatively impacting the results on this EMC report.
We all know the real value of linked clones is the automation of deployment and the space savings will change over time.
The NetApp solution adds value by providing cost per desktop reduction features (with end user experience into consideration) within the array which complement Linked Clones and cannot be provided by any single EMC array over all protocols…
Regards,
Abhinav Joshi
@chuck
If you can’t compete at the price point, you don’t play.
You’d think after the last down turn you would have learned that specific lesson.
For more…
http://blogs.netapp.com/extensible_netapp/2009/08/the-75-vdi-disruption.html
cheers,
kostadis