WhipTail whips VDI's ass WhipTail claims that its flashy solid state XLR8r appliance is more cost-effective than EMC and NetApp disk drive arrays for hosting virtual desktop images (VDIs). The device is known as the Racerunner Virtual Desktop XLR8r. Accelerator. Geddit? WhipTail's pitch is that it's cheaper to host thousands of VDIs on this than on …
Just put all the apps on a share and serve that from a separate VDI across the local virtual switch. This way they are cached on the VDI which serves them and the average IOPs to disk per image are reduced by an order of magnitude. In fact, in a tightly managed environment you can put most of the images themselves onto a share as well. Trivial if they are not Winhoze and one of the most underutilised cost reduction drivers in a Linux/Unix environments. Still possible on Winhoze, but requires some effort and a few working grey cells in the admin (yeah I know - thinking and doing something original to reduce costs instead of shopping, that is a criminal offence).
Not a very big array though, is it? I mean, if you're wanting to run 5k virtual desktops, it's highly likely that you've already got something along the lines of a big calriion, DMX or VMAX array (or Hitachi or IBM equivilant). Why would you get another array, which would require separate administration and doesn't seem to offer half the features (replication, snapshots etc) of proper enterprise disks?
Also, who'd of thought that a new small array at around 7TB would cost less than a new DMX or VMAX hosting the same storage? Now compare the cost to ADDING 7TB to an existing DMX or VMAX...
"Okay. Let's say an average VDI needs 30 or so IOPS and a single disk drive could support 7 VDIs."
Think again - if each of these VDIs is really demanding 30 (randomish) IOPs per second on a sustained basis, then there is no way you are going to map them onto a single HDD and hope it survives. Firstly, with that number of independent workloads then the access pattern will tend to be more random with longer seeks than a single workload. Sequential reads get disrupted and all sorts of nasty things happen.That means seeks are longer, device level caches don't work so well and that implied 5ms I/O latency goes out the window.
Of course if you have a layer of cache in there, and some form of de-duplication (like running VM images from snaps so that many blocks are shared) then you can get many more IOPs per back end disk as most don't get near the spinning material, writes are performed to NV cache and staged back asynchronously. Indeed the likes of NetApp solutions couldn't possibly work acceptably if it was otherwise.
Then, as anybody who does capacity planning can tell you, you don't count on using 100% of your throughput capacity. The IO queueing starts to become completely out of hand and effective latency starts heading to the sky. If you are doing randomish I/Os, then you'll be lucky to maintain 60% average utilisation across the backend storage. In practice, it becomes very difficult to balance workloads that well.
However, as far as SSDs go, then they are a near perfect fit for system images, especially if fronted by logic which allows the sharing of common blocks. After all, system images are dominated by huge collections of executables, libraries and so on and they are perfect candidates for de-dup technologies of various sorts.
Of course if you map it to a RAID-1 mirrored set, then
Hello gents,
Thanks for the commentary and perspective. I am the Enterprise Account Manager for WhipTail Tech in North America and hope to provide some answers for your genuine concerns.
Regarding the article itself, the fact is that there is no doubt we can deliver on this. The University of Groningen in The Netherlands, as one example, is running 6,000 VDI users on a single appliance as we speak. Their current motion is adding a few more boxes to scale to 18,000 users. Three appliances, 6U, 540 watts of power for 18,000 VDI users. It is literally that simple. It's all math.
Regarding cost analysis, it's very simple. Go to you preferred storage platform vendor and search for their scaling documents for 1,000, 5,000, 10,000 VDI users and get MSRP pricing. Then research their power requirements to calculate power and cooling cost. Then factor in the lifetime TCO of a data center rack ($120,000 according to APC) and apply that to how many racks of data center space are required for their solution. Out of all the scaling documents we read and priced, the absolute BEST three year TCO for a 5,000 user VDI environment was over $1.5 million dollars. Ours is under $190,000 - much less for smaller enviroments. Math.
That TCO/ROI value proposition has nothing to do with inline data deduplication and compression. That TCO/ROI is based soley on the core performance and efficiency value proposition of our management of the Racerunner SSD array.
Data deduplication and compression is an advanced feature that can be turned on or off, per LUN, based on what's best for your environment. We see the best value of that feature around virtual server environments where we can deduplicate significantly, while improving performance 200%. It can also be handy in certain database enviroments where 4:1 compression can be achieved.
Our 7.5 TB appliance is actually a hybrid of 1.5 TB of SSD and 6 TB of SATA drives, all in a 2U appliance. This is a great play for a SMB shop where they dedicate the 1.5 TB of "fast" storage to Exchange, VDI, Virtual Servers, key databases, etc, and the "slow" to file shares and other slow workloads. Then we deduplicate the storage to the "slow" workloads so that an SMB can have a 2U SAN that will scale significantly with the business. This same appliance can also be used by the large enterprise to carve up fast and slow worloads within a specific workload to maximize the minimal data center and environmental impact.
Regarding larger capacity SSD only appliances, we are capable of deliverying 9-12 TB of SSD in the same 2U chassis, but we are working on your behalf to confirm that those size drives are ready for the enterprise.
Our conservative, "over the fabric", production numbers for IOPS are 150,000 read and 100,000 write. Sustained, random, 4k block size. At 20 IOPS per user (again, see scaling documents from Citrix, VMware, etc. - they are saying AT LEAST 20), that's 150,000/20 IOPS = 7,500 users per appliance. Scalability from a capacity perspective is limited by each customer's approach to provisioning, cloning, golden images, etc. Obviously the University of Groningen excelled in this department to enable 6,000 users per appliance. Again, math.
Regarding Commment #1, caching is a typical response to the latency and overall mechanical limitations of HDD. It helps, but it's just another frankestein addition to the core problem that adds cost, complexity, energy consumption, etc. The mathematical problem with the caching approach is that VDI workloads are 50% - 90% WRITE - we solve that at the disk level, which takes us back to why have racks of equipment when you can do it in 2U? I would suggest asking your preferred platform storage vendor for a 6,000 user VDI environment reference so you can ask how many racks of storage it took, how much it cost to procure, and how much it cost to maintain. That is, if they can even find a reference.
Regarding Comment #2, I would question if the DMX or VMAX can even deliver on a 6,000 environment without crashing, without you allocating racks of storage, and without dedicating a team of people to focus solely on replacing failed hard drives. But even if they could actually make it work, why would you spend 10X as much with 100X the power, cooling, and rack space? So, to answer your question of "why invest in a separate console, vendor, etc," the answer is to save the environment and millions of dollars.
Regarding Comment #3, back to the 50% - 90% write workload.
Thank you again for your comments. I can be reached at rsnell@whiptailtech.com or 615-337-0883.
Facts are stubborn things. This is a mathematical conversation. It really IS this simple - it's just up to each of you to accept it. Welcome to the new world order.
I look forward to further discussion.
Best regards,
Ryan
Good day everyone! Sunny and breezy in the northeast USA today. :)
I'm Brian Feller the VP of Sales and Ops at WhipTail, and I thought since half of our firm is currently in a zombie-like state post Citrix-Synergy 2010 I'd pop over a quick note for a previous reply:
The real issue with adding SSD's to current HHD array's is that the array's themselves are not built to accentuate the positives of solid-state. The realities we've seen is that they limit the acceleration, but more importantly do not address the nuances of wear management whether it's the more expensive and generally available SLC Flash or less common (and the underlying Flash of our XLR8r SAN series) MLC Flash. Put another way, HDD's treat flash like disk. Without the delicate focus by the array to mitigate the write amplification and endurance issues, enterprise clients burn these drives out in 9-12 months. Thus, forced to re-invest in a costly solution.
The Racerunner is a purpose-built Flash appliance, with several years of development under the hood specifically dealing with the nuances of a NAND architecture (it's in our IP software that we solve these issues) and guaranty the drives to last more than 7 years.
Not to put too fine a point on it, but the appliance is not going to "replace" a current HDD infrastructure from NetApp, EMC so much as complement it In a virtual desktop scenario, it's an IO play pure and simple. For straight database acceleration we attach to the most IO intensive data (SQL, Exchange, OLTP) and allow the current investment in HDD's simply be re-allocated elsewhere. This is accomplished by our sister-solution the Racerunner Datacenter XLR8r - complete with inline deduplication and compression.
Naturally, we have clients who are tremendous evangelists for our technology who have been happy to share their experiences publicly.
I wish everyone a great weekend...what an exciting time in It (Cloud, Solid-state, VDI, etc!)
Cheers,
~Brian
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
