Continuing our VCAP7-DTM design study guide, we will continue with section 4: physical storage design.
In sections 1 to 3 of the blueprint, we started with the logical and conceptual designs of the VMware methodology. Based on this we created the physical design, which should contain all building blocks that are going to be used for that specific use-case.
Based on our physical design, it is key that we know “HOW” we are going to provide the solution. In section 4, we will look at the “WHAT”.
The following sections of the VCAP7-DTM study guide will individually focus on creating a design for specific topics like storage, networking,…
Again, this is an agile process, a decision we make can always be iterated on or changed depending on future decisions.
If you have not yet read the first 2 parts, you will find the links below.
Index
VCAP7-DTM Design study guide Part 1 – phase 1 & 2: logical design
VCAP7-DTM Design study guide Part 2 – phase 3: physical design
VCAP7-DTM Design study guide Part 3 – phase 4: physical design
VCAP7-DTM Design study guide Part 4 – phase 5: network design
Section 4 – Create a Physical Design for Horizon Storage
Following the decisions, we made regarding how our physical design will be for the solution, you should have a key understanding of what building blocks/components will be used.
Storage is one of the most important but sometimes overlooked aspects of delivering a performant VDI environment. When scaled correctly, an end-user will have a performant desktop. But when under scaled, there could be issues like boot storms, slow provisioning, and just an overall worse end-user experience.
The blueprint covers following topics a candidate should know about:
Objective 4.1 – Create and Optimize a Physical Design for Horizon Infrastructure Storage
Objective 4.2 – Create and Optimize a Physical Design for View Pool Storage
Objective 4.3 – Create and Optimize a Physical Storage Design for Applications
Objective 4.4 – Create and Optimize a Tiered Physical Horizon Storage Design
Objective 4.5 – Integrate Virtual SAN into a Horizon Design
Storage requirements for backend infrastructure:
When it comes to the backend infrastructure and the storage requirements, we need to take a look at the individual components.
The type of storage that is being used is also important to know, as this can have some implications on the availability/recoverability of the data. Example: local disks vs Netapp/3par vs VSAN. More on that later in this blogpost.
Profiles:
Dynamic Environment Manager (DEM) previously known as UEM, has some requirements for storing user-profiles and configuration.
Most of the time there is no real estimation on how large the profiles will be (amount of applications, personalization,…) .
But a good rule of thumb is between 50 and a 100mb per UEM profile.
So, for a DTAP (Development, Test, Acceptance, Production) environment with 100 users, a file share with at least 750-1000GB should be deployed.
Databases:
Horizon only has 3 components or features that have a requirement of a database:
- AppVolumes
- Horizon Events
- Composer
- Identity Manager (on-prem only)
I will not go into detail about the recommended sizing’s of these but make sure you know the sizes and other requirements.
Furthermore, it is important to know the limitations for using, for example, a local SQL express vs an always-on SQL cluster.
AppVolumes:
When creating new AppStacks these AppStacks will be stored in a VMDK format on a storage location accessible through the vCenter.
The default template has a size of 20GB, but I do recommend creating additional templates with smaller disks (1/5/10GB).
More on this can be found here: https://kb.vmware.com/s/article/2116022
Should your design contain multiple pods/sites, a multi-site AppVolumes deployment does require an additional shared NFS datastore.
As already mentioned in section 3, a shared NFS is needed to be able to replicate the AppStacks between sites.
This again has requirements and implications on the storage design.
Storage requirements for Horizon resources:
With Horizon there are currently three options of deploying VDI/RDSH virtual machines in your environment:
Full clones, linked-clones, and instant-cloning (preferred method of provisioning).
Each of these methods has a specific impact on storage requirements:
full Clones:
A full clone as the word says itself is a fully independent Virtual Machine. Storage requirements are therefor 100% of the original OS disk,
meaning a base image of 50GB will have with 10 VM’s a storage requirement of 500GB.
Linked Clones and Instant Clones:
To calculate the storage requirements for LC or IC provisioning, VMware created a sizing formula. Link to KB article
| Data Type | Min Recommended (GB) | 50% Utilization (GB) | Max Recommended (GB) |
|---|---|---|---|
| OS disks | Number of VMs * (2 * memory of VM) + (2 * replica disk) | Number of VMs * (50% of replica disk + memory of VM) + (2 * replica disk) | Number of VMs * (100% of replica disk + memory of VM) + (2 * replica disk) |
| Persistent disks | Number of VMs * 20% of persistent disk | Number of VMs * 50% of persistent disk | Number of VMs * 100% of persistent disk |
The storage of instant clones is approx. 50-90% efficient.
Storage Accelerators
To enhance the I/O performance of each ESX hosting VDI desktop pools, the Content-Based Read-Cache (CBRC) was designed to provide a memory cache to increase I/O performance. Performance benefits can be noticed during boot storms on hosts with slower storage (spinning disks). The CBRC is by default enabled and configurable between 100 and 2048mb.
I recommend setting the CBRC to the maximum (2048MB) depending on the number of desktop pools, that will be hosted on the ESX hosts.
Storage requirements for Applications:
When it comes to application provisioning in a Horizon solution, there are 3 possibilities:
- AppStacks (AppVolumes)
- ThinApp
- Local install
As already mentioned, AppVolumes create AppStacks in a VMDK format that is stored on a shared datastore for x amount of ESX hosts.
This will reduce the required amount of storage as the VMDK’s will be read from shared locations.
ThinApp can also be used to provision applications. Storing ThinApp can be done in two ways, stored locally on each VDI or streamed from a share. The streaming will reduce the overall requirements for storage. Streaming needs to be scaled correctly as the overhead on the fileserver or network can cause congestion and slow performance.
Storage design with Tiered Physical storage:
In cooperating a multi-tier storage solution into your Horizon design needs to be performed correctly to ensure the best performance, high-availability, and capacity usage.
The backend Horizon components should be placed on a high-available redundant LUN (raid 5/ 6) to ensure no disk failure will impact the availability of the horizon services.
Desktop pools should be split up as in the replica VM’s and the clones itself.
The Replica disk should be placed on a High-performance storage medium like NVME / Optane to ensure the quickest cloning operations.
More info can be found on the VMware Horizon documentation: here
The desktop clones can be placed on slower NLSAS drives or standard SSD storage.
It is still important to ensure that the storage can provide the required IOPS for the operating system. This can be version dependent but the applications on the base image can also have a big impact on the read/write operations.
Make sure to validate this before a storage decision has been made! Slow storage will kill the overall end-user experience.
Storage design with VMware vSAN:
As the Multi-tier storage appliances are less flexible and scalable, Hyperconverged solutions provide a great storage platform for EUC solutions. Incorporating vSAN into a Horizon solution is a no-brainer to ensure the best performance for your VDI/RDSH workloads.
Today vSAN comes in 2 flavors Hybrid or All-Flash, it is important to know both versions for the exam. But in today’s sight, the only real version today’s customers are going for is all-flash. As the $/GB is pretty much the same as HDDs. I won’t go into detail much more about that topic. More on that in a future blog post.
vSAN uses Storage based policy management (SBPM) to provide levels of redundancy, performance and other SLA’s to individual VMs.
These levels of redundancy are mentioned in Faults to Tolerate (FTT). To calculate the required number hosts to satisfy an FTT level, the following calculation needs to be made: 2N +1 where N is the FTT level.
When using Instant clones on a vSAN datastore, Horizon will automatically create a new SPBM storage policy.
This policy is configured with a default set of rules that can be found: here
- Failures to tolerate (FTT): 1
- FTT method: RAID 1
- Stripes per object: 1
- Flash read cache reservation: 0%
- Object space reservation (thick provisioning): 0%
The default policy can be modified or additional vSAN policies can be created based on the difference SLA needs.
Conclusion:
Rapping up part 3 containing the storage design of the VCAP7-DTM study guide. It is important to reflect your initial decisions (building blocks) with the implications and requirements it has on storage. We will continue with part 4 that will take a deeper look into the networking side of an EUC solution.
VCAP7-DTM Part 4 is still working in progress.