© 2010 DinamiQs

VirtualStorm is hardware agnostic. In other words, it will run on any combination of servers, storage and network. However, the system is designed in such a way that it tries to make optimal use of of the components that are available. So there are some things to take into account when designing an environment and especially larger environments require thought and careful design to make the most of the VirtualStorm software stack.

Below is a general architecture that describes how the VDI environment is best created. There are many implementations that can deliver different results. The goal of this document is to describe and make clear the ideal situation for most environments, ranging from simple, small environments to large enterprise VDI structures and private and public clouds.

Small scale environments

Current server hardware is very powerful. Considering that most users deploy their applications and work by typing text or opening and closing applications and any combination thereof and that read time for what appears on screen is also required, it stands to reason that in general end-users utilize only a very small portion of available resources.

Combine this with the VirtualStorm optimized Windows (XP or 7) stack running on a hardware supported virtualization hypervisor such as VMware’s ESX and it becomes obvious that high densities of VMs can be achieved using regular compute hardware and relatively small storage.

The smallest environment for VirtualStorm would be a single server with some internal disks, running ESX and having a Desktop folder and a Repository folder. The first is for the deployment of Windows desktops, the second is for deployment of one or more application repositories and to hold the master-image.

The Desktop folder should be sequential IO optimized whereas the Repository folder must be random IO optimized. With regular internal disks (SCSI or SAS) you will need at minimum a RAID card to create additional volumes apart from the mirrored disk to install ESX. Depending on the number of CPUs and cores inside the server and the available memory, you might run 50 to 200 virtual desktops on this single server. A single box should have at least one VM running at least Windows 2003 with Active Directory and a separate vSphere vCenter server(or VirtualCenter.) This box would also be responsible for handling the domain and handing out DHCP addresses to the end-points, as well as running the central DinamiQs Management Console to manage all Virtual Desktops. This means you should reserve between 4 GB and 8 GB of physical memory for management servers. A typical Windows XP desktop requires around 150 MB of physical memory for average use. Power users may require 250-300 MB for proper operation. This means you can scale your server to these numbers. If you have a total of 24GB, you have 16GB available for end-users, meaning you can run between 50 and 100 VMs besides the management servers.

VirtualStorm Cloud Enabled Virtual Desktop Infrastructure

based on industry leading technologies.

By

The future of VDI

Storage

Architectures

Version 1.1

Of course having all virtual desktops inside a single box is not an ideal situation. It is in fact suited at most for a Proof of Concept environment, definitely not for produc-tion where you need resilience and redundancy.

So how do you scale a system like this? It is very impor-tant to understand that VirtualStorm scales linearly. That means that with each server you add, you can increase the number of VMs by roughly 200 for each extra server on average (depending on CPU type and memory) The minimum setup would be a 2 server system. Each of these servers would only require 2 disks, internally mir-rored, to host ESX on. Then there is a Storage Network, be it Fiber Channel, InfiniBand or NFS/ iSCSI over Ethernet. The only thing to really keep in mind is to separate the presentation network from the storage network. This is very important as this will separate different workloads from each other. In the past NFS and iSCSI were not the storage protocols of choice, mostly due to misunderstandings in the proper scaling of these protocols over the LAN. VMware would in fact not support any sort of performance over these proto-cols. It is our experience that has shown that these protocols are in fact viable, with proper performance, as long as the architecture is properly designed and the equipment used adheres to certain standards. In Fiber Channel and Infiniband networks, the protocol is very efficient and, very important, transports data at very low latency. Especially in application landscapes that re-quire lots of random IO and quick retrieval of files, that low latency helps improve the end-user experience. With the arrival of economical low-latency 10 Gb/s inter-connects, NFS and iSCSI protocol running across these interconnects demonstrate very acceptable performance for VirtualStorm VDI.

Small to midscale environments

Up to 1000 users can be housed in a small to mid-range SAN with 2-4 Gbit/s FC or multiple 1Gbit/s connectors with NFS or iSCSI. The way VirtualStorm co-operates with the cache the desktops require an average of 0-2.5 IOPS from disk while the application repository requires 2-4 IOPS from disk to operate per user. An important part of the SAN is the cache, which handles big application workloads. Since all applications are equal for all users, the cache-hit ratio will be very high. This means that a 1000 user SAN wil require between 0 and 2500 IOPS for the desktop volumes and between 2000 and 4000 IOPS for the repository. The repository can be constructed from a number of regular FC or SAS drives. This will give raw performance of 1000-1500 IOPS for a 5 or 6 drive RAID5 volume, which is enhanced by the cache in most storage arrays. More cache definitely improves performance, specifically because of the static nature of VirtualStorm.

Since images require up to 2.4GB of diskspace, a thou-sand user environment requires a maximum of 2.4TB of disk space. The maximum number of VMs in a LUN should not exceed 500 VMs. (to avoid SCSI command queuing), which means that a thousand users can be put in two volumes of roughly 1.2 TB each. This can be achieved through RAID10 volumes of 12—14 146GB FC or SAS disks each or 4 volumes of 600GB each, requiring 6-8 drives each. Volumes must remain below 2000GB anyway (ESX limitation) and 2000GB is not 2TB! The total number of drives comes to 24-32 drives for se-quential IO and another 5-7 drives for random IO. A thou-sand users can therefore be hosted on a relatively small SAN. Important to keep in mind is that most people will start only a few applications, meaning that they will not load up dozens of applications and therefore will not fill up their page file to the maximum. The total size of each user’s files can be anywhere between 1.6 and 2.4 GB; this can be taken into account when sizing the number of disks. It is recommended not to use very large disks, as the sys-tem does require sufficient disks to deliver the necessary IO and bandwidth to provision the applications to the Vir-tual Machines. 146GB drives are recommended for Virtu-alStorm environments.

Scalable infra for one thousand+ users. The Core/Edge config is optional

Single server VDI setup with VirtualStorm

Large scale environments

When sizing and scaling a large environment, care must be taken to size all parts of the infrastructure. Current limitations in VDI hover at numbers between 3000 and 5000 users for traditional fat client VM farms. Using VirtualStorm allows to scale beyond those numbers and still maintain performance. Management at these scales is usually done through creation of vCenter silos of one thousand VMs, sometimes in different datacenters. Again, VirtualStorm allows creation of a single large environment.

vCenter has linking capabilities which allow it to link multiple vCenters together to scale up the management of the environment. The DinamiQs Management Console has been designed and constructed to manage a limitless number of virtual desktops across LAN and WAN networks and it integrates with the desktop automation module. The scaling of the environment requires the setup of sufficient storage, compute and interconnects. The averages that have been found so far for larger environments show that a regular server connected with 1 or 2 Gbit/s network interfaces will run 200-300 VMs. Linear scalability requires that storage is connected at a ratio of up to 7 or 8 servers per 10Gbit/s interface (6-7 on an 8Gbit/s FC interface.) In this case connecting with multiple interfaces scales up the environment by these numbers of users.

At this moment extreme scale Desktop environments are rare for precisely the problems that VirtualStorm aims to solve: VM density and Storage requirements. The all important third factor here is the management of the environment, which is addressed through the Management Console that allows scaling to tens of thousands of Desktops in one environment. Combined with massive deployment capabilities of VirtualStorm and system-wide instantaneous updates and upgrades for

thousands of users simultaneously, the solution provides a scalable environment for large enterprises.

There are many ways to scale up a setup and to deploy across datacenters using active/passive or active/active setups. As you scale up you will find that the datacenters are more and more becoming a consolidated, centralized environment for shared resources and you should treat them as such.

Cloud Enabled Desktops - DaaS with VirtualStorm

Using VirtualStorm allows for large scale deployments. This has been demonstrated in several showcases. Using the software has allowed hosts to be pushed to 800+ VMs on a single box. (See below)

Using these numbers of VMs in a production environment is of course not recommended, but it shows the capabilities of both ESX and the VirtualStorm Software Infrastructure. The approach VirtualStorm takes allows for integration with Cloud Management tools for rapid deployment and fast upscaling of resources, with resource overcommit as depicted above to create full blown desktop clouds.

As there are no real standards for Cloud Computing interfaces apart from the de-facto standards by some of the large cloud providers, integrating into new cloud initiatives is a matter of setting up the proper interfacing between the customer facing cloud front-ends and the deployment, operational and billing structures of the backend, ie the VirtualStorm Software Infrastructure.

Cloud Desktop deployment for tens of thousands of desktops which used to be a matter of weeks can now be resolved in days, hours even, as the technology allows for multi-desktop deployment across the whole of the infrastructure and application deployment through simple activation and de-activation mechanisms.

A VirtualStorm Software Infrastructure Desktop Cloud

Single dual socket quad core host 826 VMs

Multi-datacenter VirtualStorm environment

IOPS and bandwidth in a VirtualStorm Environment

Having a centralized storage usually means that a spe-cific controller is used that virtualizes a number of drives and presents the virtualized ‘disks’ (also called LUNs) to the servers through the storage network (also called the Storage Area Network or SAN.) A typical VirtualStorm setup will have a LUN that is ran-dom IO optimized, for instance through a RAID5 volume consisting of four to eight drives. This LUN is used for the application repository. In addition there will be several LUNs for desktop provisioning. These LUNs should be sequential IO optimized, which can be achieved through creating RAID10 volumes. The LUNs are shared among all ESX hosts that are con-nected to the central storage. The interconnects can be Fiber Channel, 1 or 10 Gbit Ethernet (using NFS or iSCSI to mount the volumes) or even Infiniband. You need to take care to tune the storage bandwidth to the maximum bandwidth of the connected servers. So if you have a 10Gig connected storage array, make sure your total ag-gregate server connectivity does not go too far beyond that 10Gig Ethernet. The same arguments apply to FC and Infiniband. Latency of the interconnects is important. Use of large frames also helps speed up the environment as it re-duces TCP/IP overhead and at the same time correlates with the sequential IO fingerprint of the storage. Most switches have latencies that run in the microseconds and are often blocking type. The best Ethernet connectivity is non-blocking with sub microsecond latencies and the largest possible frames. Since VirtualStorm scales linearly where it concerns servers, the limits that you reach are to be found in the interconnects and the number and configurations of the connected drives in the central storage. The desktop volumes are sequential IO optimized. This happens because the applications that are read from the repository and fed into the RAM of the virtual machine are simultaneously written into a special page file next to the XP image VMDK file.

This page file contains application stripes of applications that were read from the repository. (See also the MES explained” document.) Whenever an application is stopped and restarted, the VirtualStorm drivers first check the cache. If the applica-tion is available, it is read, else the driver checks the page file and if the application resides there, it is read as sequential IO with speeds of up to 50MB/s per drive and fed into the RAM of the Virtual Machine. The way the system works is that all applications slowly get spread across the SAN as sequential IO optimized stripes with extremely low overhead from VMware itself. The result is a construct that allows application provision-ing to be spread across the complete storage array, lev-eraging disk bandwidth through sequential IO until the bandwidth limits of the interconnects are reached.

The design of VirtualStorm allows for environments that get faster as they are being used. This has been wit-nessed in multi-thousand desktop environments.

Although VirtualStorm has run over 400 VMs on a dual socket quad core server with sufficient memory, this number is getting close to the scheduling limits of ESX itself. Fortunately in VirtualStorm most of the scheduling issues found in ESX are alleviated due to the low de-pendence on the engine’s scheduling. Proper use of the integrated hardware acceleration of modern CPUs and the use of hardware supported transparent page caching and other techniques and not using VMware overcommit and memory ballooning, result in ESX only having to handle the actual running of the VMs and doing some display-protocol work for the virtual NICs. It may not come as a surprise that ESX is actually quite capable of handling such workloads.

For production purposes DinamiQs advises the use of no more than 200 VMs per dual socket quad core server with 48GB of memory. This allows for sufficient headway for maintaining production performance levels even in the case of failure of several ESX servers.

In case of doubt, do get in touch with us or one of our resellers. We’re happy to help you design and scale your VDI environment.

DinamiQs B.V. Kabelstraat 3 1322 AD Almere The Netherlands tel: +31 36 524 11 60 fax: +31 36 524 11 10 email: info@dinamiqs.com

North American Distribution

Web: http://www.VirtualStormNow.com Email: sales@virtualstormnow.com

Call: +1 (603) 766 4986

The future of VDI