Home > Blogs > VMware Consulting Blog


Part II: Storage Boon or Bane – VMware View Storage Design Strategy & Methodology

By TJ Vatsa, VMWare EUC Consultant

INTRODUCTION Welcome to Part II of the VMware View Storage Design Strategy and Methodology blog. This blog is in continuation to Part I that can be found here. In the last blog, I had listed some of the most prevalent challenges that impede a predictable VMware View Storage design strategy.. In this blog, I will articulate some of the successful storage design approaches that are employed by VMware End User Computing (EUC) Consulting practice to overcome those challenges.

I’d like to reemphasize the fact that storage is very crucial to a successful VDI deployment. Should the VDI project be made prone to the challenges listed in Part I, Storage, for sure, will seem to be a “bane”. But, if the recommended design strategy listed below is followed, you would be surprised to find VDI Storage being a “boon” for a scalable and predictable VDI deployment.

With that in mind, let’s dive in. Some successful storage design approaches I’ve encountered are the following:

    • 1.     PERFORMANCE Versus CAPACITY Recommendation: “First performance and then capacity”
      Often times, capacity seems more attractive when compared to performance. But, is it really so? Let’s walk through an example.

 

    • a)     Let’s say vendor “A” is selling you a storage appliance, “Appliance A” that has a total capacity of 10TB, being delivered by 10 SATA drives of 1TB capacity each.

 

    • b)     On “Appliance A”, let’s say that each SATA drive delivers approximately 80 IOPS. So, for 10 drives, the total IOPS being delivered by the appliance is 800 IOPS (10 drives * 80 IOPS).

 

    • c)     Now let’s say that vendor “B” is selling you a storage appliance, “Appliance B” that also has a total capacity of 10TB, but it is being delivered by 20 SATA drives of 0.5TB capacity each. [Note: “Appliance B” may be expensive as there is more drives compared to “Appliance A”.]

 

  • d)     Now for “Appliance B”, assuming that the SATA drive specifications are the same as those of “Appliance A”, you should be expecting 1600 IOPS (20 drives * 80 IOPS)
    • It’s mathematically clear; “Appliance B” will be delivering twice as much IOPS than “Appliance A”. More storage IOPS invariably turns out to be a boon for a VDI deployment. Another important point to consider, is the fact that employing higher tier storage also ensures high IOPS availability. Case in point, replacing the SATA drives in the example above with SAS drives will certainly provide higher IOPS. SSD drives, while expensive, will provide even higher IOPS.

 

    • 2.     USER SEGMENTATIONRecommendation: Intelligent user segmentation that does not assume “one size fits all approach”.

As was explained in Part I, taking a generic user IOPS, say “X” and then multiplying that with the total number of VDI users in an organization say “Y”, may result in an Oversized or an Undersized Storage Array design. This approach may prove costly, either upfront or at a later date.

The recommended design approach is to intelligently categorize the user’s IOPS as “Small, Medium or High” based on the load a given category of users generate across the organization. As part of the common industry nomenclature for VDI users:

a)     Task Workers: associated with small IOPS.
b)     Knowledge Workers: associated with medium IOPS.
c)     Power Users: associated with high IOPS.

With these guidelines in mind, let me walk you through an example. Let’s say that Customer A’s Silicon Valley campus location has 1000 VDI users. Assuming that the user % split is:

a)     15% Task Workers with an average of 7 IOPS each
b)     70% Knowledge Workers with an average of 15 IOPS each
c)     15% Power Users with an average of 30 IOPS each

The resulting calculation of total estimated IOPS required will look similar to Table 1 below.

Key Takeaways:

      1. It is highly recommended to discuss/consult with the customer and to also make use of a desktop assessment tool to determine the user % distribution (split) as well as the average IOPS per user segmentation.
      2. Estimated capacity growth and the buffer percentage, is assumed to be 30%. This may vary for your customer based on the industry domain and other factors.
      3. This approach to IOPS calculation is more predictable based on user segmentation specific to a given customer’s desktop usage.
      4. You can apply this strategy to customers from Healthcare, Financial, Insurance Services, Manufacturing and other industry domains.
3.     OPERATIONSRecommendation: “Include Operational IOPS related to Storage Storms”.It is highly recommended to proactively account for IOPS related to the storage storms. Any lapse can result in a severely, painful VDI user experience during the storage storms – Patch Storm, Boot Storm and Anti-Virus (AV) storm.

Assuming that a desktop assessment tool is employed to do the analysis, it is recommended to analyze the user % split targeted during each of the storm operations listed above.

For instance, if the desktop operations team pushes OS/Application/AV patches in batches of 20% of the total user community, and the estimated IOPS is let’s say three times the steady state IOPS (explained in Part I), it will be prudent to include another attribute for operational IOPS to Table 1 listed above.

A similar, strategy should also be employed to account for the boot and the log-off storms.

I hope you will find this information handy and useful during your VDI architecture design and deployment strategy.

Until next time. Go VMware!

TJ Vatsa has worked at VMware for the past 3 years with over 19 years of expertise in the IT industry, mainly focusing on the enterprise architecture. He has extensive experience in professional services consulting, Cloud Computing, VDI infrastructure, SOA architecture planning, implementation, functional/solution architecture, and technical project management related to enterprise application development, content management and data warehousing technologies.

 

2 thoughts on “Part II: Storage Boon or Bane – VMware View Storage Design Strategy & Methodology

  1. Steve

    TJ it is clear you are a man of true, clear, real hard numbers… Yet with your approach of layered tiring you’re leaving room to adjust for the reality of the world we live in today. I believe your right allowing for margins of adjustment as we need to adjust to the discoveries of tomorrow… Case in point we both can remember a time when the facts were a single server = 100% hardware with 3 or more hard drives, RAID controllers, Processors, 2 or more RAM banks, PCI video card, on-board Cashing, a motherboard, etc, it was latterly 1 to 1 hardware to software…. yet today that seems like a joke… Then Virtual encapsulation change the realities of computing for everyday after to now. Today vDI will take another layer of encapsulation to change the rules of 1 to 1 software to hardware on desktops if we ever what to get to a faster Desktop to hardware of a 100 to 1 that we are trying to sell now.

    Reply
    1. TJ Vatsa

      Hi Steve,
      Over the years I have appreciated you passion towards End User Computing domain. Here are some additional blogs that you will find useful as well. Enjoy!

      Best Regards,
      TJ Vatsa

      Part 1- Title: End User Computing 101 and Tips for Successful Deployments
      http://blogs.vmware.com/consulting/2014/08/end-user-computing-101-tips-successful-deployments.html

      Part 2- Title: End User Computing 101: Network and Security
      https://blogs.vmware.com/consulting/2014/08/end-user-computing-101-net-sec.html

      Part 3- Title: End User Computing 101: Tying It Together with Mobility, BYOD, and Proper Methodology
      http://blogs.vmware.com/consulting/2014/08/end-user-computing-101-tying-together-mobility-byod-proper-methodology.html

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>