With SimpliVity OmniStack, you can start small with as few as two OmniStack nodes (for storage HA) and grow the environment as needed. This provides the flexibility of starting with a small scale proof of concept and growing to large scale production without guessing the workload and purchasing up front.
The following section covers the OmniStack, XenDesktop, infrastructure and network design guidelines for XenDesktop and XenApp deployments on SimpliVity OmniStack.
Citrix XenDesktop 7.X Design Guidelines
Sizing
Compute, Storage, and Network resources for each infrastructure VM were selected using Citrix best practices as a baseline and modified based on their observed performance on the OmniStack systems.
OmniStack Servers – Two 5-host vSphere Clusters comprised of OmniStack Integrated Solution with Cisco UCS C240 M4 systems to support the Office Worker desktop workload.
The following design patterns were observed:
- Limit physical CPU to virtual CPU oversubscription
- Do not overcommit memory
Limit physical CPU to virtual CPU oversubscription
The table below shows steps on how to calculate useable physical CPU:
Memory Calculation
In this configuration, each OmniStack system has 384GB or 512GB of available physical memory. We used 384GB memory for hosted shared desktops and 512GB for hosted desktops. The table below shows steps on how to calculate useable physical memory:
Storage
For infrastructure, a single datastore per server is recommended to ensure even SimpliVity storage distribution across cluster members. This is less important in a 2 OmniStack server configuration; however, following this best practice guideline will ensure a smooth transition to a 3+ node OmniStack environment, should the environment grow over time. This best practice has been proven to deliver better storage performance and is highly encouraged.
For desktops, an equal number of SimpliVity datastores to the number of OmniStack systems in each vSphere Cluster were deployed. In this 5+5 Federation configuration, five SimpliVity datastores were created for each vSphere Cluster. This is done to more evenly distribute storage load across the OmniStack systems in the vSphere Cluster, as well as increase the likelihood any given desktop has locality with its VMDK disk.
Each datastore contains a virtual machine template and write cache files for every virtual machine. The write cache file contains all disk writes of a target device when using a write-protected vDisk (Standard Image).
Networking – The following best practices were utilized in the vSphere networking design:
- Segregate OVC networking from ESXi host and virtual machine network traffic
- Leverage 10GbE where possible for OVC and virtual machine network traffic
These best practices offer the highest network performance to VMs running on OmniStack 3.0. Taking this into consideration, a single vSphere Standard Switch is deployed for management traffic, and a single vSphere Distributed Switch is deployed for the remaining traffic, including:
- Virtual Machines
- SimpliVity Federation
- SimpliVity Storage
- vMotion