Home > Blogs > VMware Consulting Blog > Tag Archives: VMware View Storage

Tag Archives: VMware View Storage

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.

 

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

By TJ Vatsa, VMWare EUC Consultant

INTRODUCTION I am writing this blog to share my thoughts and experiences when it comes to architecting enterprise virtual desktop infrastructure (VDI) solutions. While some schools of thought believe that a one size fits all approach provides a low cost, modular deployment strategy, I believe in a different perspective, which is – “one size may fit, or better yet, align with one specific use case”. This approach in my opinion leads to a repeatable, predictable design strategy and methodology that can be applied to any use case from any industry vertical. This strategy and methodology is what I’ll attempt to articulate in the next few paragraphs and in my continuing subsequent blog series on this topic.

Having worked with many customers across different industry domains namely- Healthcare, Financial, Insurance Services, Manufacturing and others, I’ve noticed one key aspect of VDI that is the most crucial element to either a successful or a challenging VDI deployment – “Storage”, boon or bane. If you’ve got your share of scars implementing VDI like I have, then you know what I’m talking about.

With this introductory background, let’s cut to the chase. The most prevalent, key VDI challenges that I’ve come across are the following:

    • 1.     CAPACITY – Oversized but underperforming storage platforms that are very costly to own depending upon the availability of the capital on hand or budgeted amount for the fiscal year.

Given the current trend that the storage capacity is becoming cheaper for certain tiers of storage (still somewhat expensive for tier 1) customers are often tempted to go in for high-end capacity storage arrays. During the VDI storage sizing effort, this approach creates a perception that there is and will be sufficient storage capacity available to house the VDI storage requirements for the current as well as the future VDI user population. While the perception may be true, it only guarantees storage capacity but not the performance that the users expect from a VDI response time perspective.

    • 2.     PERFORMANCECluttered user segmentation assuming “one size fits all approach”.

The performance capability of a storage array is commonly measured in terms of how many total IOPS (Input/Output Operations Per Second) say “Z”, is the storage array capable of supporting. [Note: From a VDI perspective, we are interested in the frontend (aka) logical IOPS of the storage array.]

From a VDI deployment perspective, the next logical step is to determine the IOPS requirements per desktop, say “X” and then multiply that with the total number of VDI users, say “Y”. So the obvious conclusion for the Storage Architects, IT Managers, IT Directors and other stake holders to arrive at is that as long as (X * Y) <= Z, the storage array will be capable of supporting the expected performance service-level agreement (SLA).

The biggest pit fall that has been made in this calculation is the assumption that the IOPS per desktop “X” is the same across all the user categories aka user communities/segmentations as well as the use cases across different lines of businesses (LOBs) within an enterprise. This leads to the challenging “one size fits all” approach. The resulting outcome is either an undersized storage array design or an oversized storage array design contingent upon “X” being the peak or the valley on the IOPs graph. In either scenario it will be a costly proposition:

      • a)     Oversized Storage Array
        Upfront costly investment (should “X” represent peak IOPS) since not all VDI users will be requiring such high IOPS.

 

      • b)     Undersized Storage Array
        Delayed but additional investment (should “X” represent the valley IOPS) because you would need to augment the required storage performance needs at a later date to cater to your power users who demand higher IOPS.

 

  • 3.     OPERATIONSPerformance blues during patching operations.

 

Another challenging aspect that I’ve experienced with the storage sizing effort is the fact that the teams involved end up overlooking the storage storms. These storms cause operational blues during patch updates, Anti-Virus (AV) updates as well as the booting operations causing boot storms.

Assuming that you’ve deployed a desktop assessment/monitoring application to measure the IOPS on a per desktop basis, there are at least these two important categories of IOPS that you should be aware of:

    • a)     Steady State IOPS
      These are the IOPS metrics that the desktop assessment/monitoring application reports during normal day to day desktop operations. Let us say that this is represented by a measure “S”.

 

    • b)     Peak State IOPS

These are the IOPS metrics that the desktop assessment/monitoring application reports during the storage storms. I have seen this metric averaging up to at least three times the steady state. For instance if the steady state IOPS per desktop is “S”, the peak state IOPS say “P” can be up to and in certain cases beyond “3S”. Therefore based on the preceding example: (P = 3S).

For those of you who are already considering these aspects during your VDI storage plan and design phase, hats off to you. For others, I’d highly recommend keeping these aspects in mind while you are planning and designing storage requirements for your VDI deployment.

In my next blog (Part II – Storage Boon or Bane, VMware View Storage Design Strategy & Methodology), I’ll be sharing with you my experiences on how to overcome these challenges with tried and tested design approaches for a scalable and predictable VMware View VDI deployment.

Until then, 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.