Virtual desktops made easy

Transcription

1 Product test: DataCore Virtual Desktop Server 2.0 Virtual desktops made easy Dr. Götz Güttich The Virtual Desktop Server 2.0 allows administrators to launch and maintain virtual desktops with relatively little effort. These virtual desktops are stateful, which means that they retain all the changes made by the users and are not reset back to default values after every restart. IAIT had a look at how the system works in practice. Storage normally becomes the bottleneck when hosting virtual desktops. For a successful implementation of VDI environments, the storage must be fast and highly available. The Virtual Desktop Server 2.0 from DataCore Software solves all these associated problems through adaptive caching and efficient use of disks or faster SSD flash storage. The DataCore solution consists of a storage virtualization engine, which implements snapshot and cloning features during operation to make a large number of desktops available in a shorter time, without requiring a lot of storage in the process. In this way not only can faster SSD flash storage be integrated efficiently, but thin provisioning features also ensure the best possible capacity utilisation. Architecture The VDS consists of various software components, which are deployed on Windows server systems together with the Hyper V hypervisor from Microsoft. These software components include the underlying storage virtualization engine and the "DataCore VDS Console", a graphical user interface that provides users with various wizards for creating, maintaining and removing virtual desktops (VDIs) to speed up desktop provisioning and deployment. The console is also able to collect data, for example by monitoring important system resources, to ensure high performance of the entire installation. In addition, there is the VDS Web Portal, a template for a website, which allows access to the VDIs via the web, as well as various PowerShell scripts. The new features in this version include full integration with Windows Server 2012, new templates, single sign on access and Active Directory support. Furthermore, the product can also be connected into Microsoft VDI environments, if required. In this latter case the use of the DataCore Web Portal is superfluous. As regards system requirements, VDS runs on Windows Server 2008 R2 with Service Pack 1 and the latest updates, as well as on Windows Server 2012 Standard and Datacenter editions. It also requires the.net Framework In terms of hardware requirements, the server should 1 provide adequate working storage as well as an Intel Xeon CPU or the like. At the smallest set up level the VDS manages 25 virtual desktops in this case the hardware must have a working memory of at least 32 GBytes. The virtualization system can however be scaled up to 200 VDIs the larger the environment, the more working memory must be logically available. The test In testing we installed the VDS on a standard x86 server with a multi threading compatible dual core CPU with a 3.3 GHz clock rate. An internal SATA hard disk was used as a storage unit for the operating system, and an SSD and a USB 3.0 hard disk for external storage. The working memory of the test device was 16 GBytes. With this we did not meet the minimum requirements of the manufacturer, but as we never deployed more than ten VDIs in our test, the memory was completely adequate. We used Windows Server 2012 with the Hyper V role installed as the operating system. Initially we

2 tried with a German system, but the VDS could not be deployed on it. Even installation of the English language pack and changing the system language to English did not solve this issue. We therefore decided to set up a new English Server After that we had no further problems. Once the set up was complete, we added two storage pools to the system under test and then created a so called "VDI source". This was a master VDI image which was used as a source for well and worked with the virtual desktops. Finally, we used the VDS Web Portal to make our VDIs available in the network. the server is only possible if the VDS service was manually stopped previously via SANcentral. Installation To install VDS on the server, it was merely necessary to call up the set up file and to run the installation wizard. This wizard mainly asks for the installation path and should therefore not overtax any administrator. In a stand alone configuration, such as our test environment, the installation was therefore already complete, but it is also possible to perform a high availability installation with a second Hot Standby server. In this case, the responsible IT staff person must still create a service account that is available on both servers, and run the VDS Communication Service under this account. After completing the set up wizard, two new icons are Start page of the VDS tools with the most important wizards the VDI clones to be created later. For the test we used a VDI source based on Windows 7. After completing this activity we deployed the VDS console to create and administer VDIs, and also to delete them. During operation we took a look at the provisioning process of VDIs as available on the desktop. One serves to call up the "SANcentral" management tool, the other enables the start of the "VDS tools". We first called up SANcentral and started the server service. This step is only necessary once after installation. Should the server be restarted at some stage for any reason, VDS boots itself. In fact, a reboot of 2 Initial start up After the server had started we first changed our region. Regions deal with VDS configuration domains. As standard, the set up routine selects the host name of the server as the region name. We changed this also via SANcentral to a more meaningful designation. We also modified the RAM settings due to our somewhat limited working memory, so that the cache only took up 50 percent of the working memory, instead of the standard 66 percent, to ensure that memory was still free for operation of the VDIs. In the next stage we created two storage pools with the SANmanager, which can be started from SANcentral via the Tools menu. One of these pools was the "SourceImagePool", which was created using capacity from the SSD and which, during operation, was intended to contain the image from which the VDIs are generated. To this was added the "ClonePool", which recorded the data that was generated by the ongoing VDI operation. After this was completed, we went on to

3 generate the source image, which was later used as the source for our clones. the VHDX file (that is, the virtual hard disk), which we moved to a safe location. For this, we created a new virtual machine (VM) with the help of HyperV Manager and installed 32 bit Windows 7 Professional under this VM as a template for the VDIs. We then installed the Hyper V integration services on the VM and ran two scripts which DataCore had provided to prepare the virtual installation. For these scripts it is necessary to first set the execution policy to unlimited in the PowerShell (which must run with administrator privileges) Working with the VDS Tools Now we could set about putting the VDS environment itself into operation. To do this, we called up the "VDS Tools" and created a "Configuration Volume" with the first wizard offered. The DataCore solution saves the configuration files of the VDI clones on this volume. It is necessary to take the storage space needed for the Configuration Volume from a disk pool we used our "ClonePool" for this. Also, the wizard wants to know the name and size of the volume as well (we decided on 500 GBytes in testing). The first script is called "VDI Optimization". This is a PowerShell script which deactivates superfluous services and tasks in Windows 7. It also modifies various system settings to optimise the performance of Windows for the VDI deployment. According to DataCore, all essential Windows features are retained, while the script simultaneously minimises the usage of I/O resources. After the script had run we restarted the VM. The second script sets up Windows 7 so that the VDI clones generated from it have distinct names at first start up and if required join a domain. After the script has finished, the VM can be shut down and is ready for use as a VDI source. Incidentally, the script must also run after each start of the source system for instance following changes to the system configuration. After the VM had finished shutting down, we deleted it from our system using Hyper V Manager and only kept After setting up the Configuration Volume we created our source VDI. If required, multiple different source VDIs can also be created for different VDI configurations VDS supports parallel operation of multiple sources. The "Create VDI Source Image" wizard of the VDS tools generates a HyperV VM for use as a source VDI, which uses a DataCore Virtual Volume as its boot drive. The source image can either be created from a VHD file as in our test or from an existing Virtual Volume. Alternatively, it is also possible to set up an empty Virtual Volume using the wizard and to install the operating system at a later stage. To create the image, the wizard needs the path to the VHD file that is to be used, and the storage pool in which the image lands the source image 3 pool in our case. It also asks for the name for the VDI image and whether it should release unused storage space on the source hard disk after creating the image. The latter makes sense if you are trying to avoid the storage pool being loaded with empty hard disk areas that nobody needs. Finally, those responsible must specify how much working memory the VDI clone receives (in testing we allocated the clones 512 Mbytes of RAM), the virtual network with which it communicates, and where the configuration files are to be stored (in our Config Volume). After the wizard had run, we found a new VM in our Hyper V Manager. As we did not want to work with this after all it only represented the source of our VDIs we deleted it again from the administration tool, so that it would not be started accidentally by any users, and additionally used the SANmanager to unmap the associated virtual drive. This ensured that the source remained undisturbed and was not subject to manipulation attempts. Creating the clones After creation of the source image all the preparatory steps were complete, and we called up the wizard for creating clones. In the first step we generated five clones. Later in the test we launched up to ten VDIs in parallel. The wizard used to create the virtual desktops is also a component of the VDS tools, and first shows the number of available licences and existing licences, as well as the number of VDIs still available. In addition, it wants to know how many VDIs it should create and which source image to use. It also asks about

4 the storage pool for the clones (we used our clone pool here) and requests the base name for the VDIs. This base name is then expanded with a number during operation, for example "VDI 1", "VDI 2" and so on. The staff responsible can also let the wizard know the starting number, which is useful if other VDIs of the same type are already available in the system. To conclude, the wizard requires details in terms of the working memory, the storage space of the configuration files (again, our ConfigFile Volume) and the virtual network to be used. Additionally, it can start the newly created VDIs immediately after creation, if required. In operation At first start up, the clones initially carry out the provisioning, which means that they change their host name from the name of the source image (in our test this was "VDI") to a unique name in the network (here "VDI 1" to "VDI 5"). They also join a domain, where required. They then restart and are ready for daily work. Provisioning must only be carried out once after creation of the VDIs, and took around 27 seconds in our test. The clones are consequently available very quickly, and the wizard ensures that the provision of VDIs is extremely simple and can therefore also be carried out by administrators who have no in depth knowledge in the virtualization area. Apart from the wizards already mentioned, the VDS tools comprise a large number of additional wizards for tasks that arise during daily work. This includes a wizard for deleting VDIs, which works analogously to the "Create VDI Clones" wizard, and a wizard which returns the selected VDIs to the original state of the VDI source. In the process all user data is lost. Also of interest are the "VDI them all at the same time. "Change VDI Clone Memory" provides the administrators with an option to adapt the working memory of one or more clones (they must however be switched off for this), and "Create VDI Clone VMs from Existing Disks" Wizard for generating a VDI source image Clone Tools". This is a collection of tools which simplify the handling of frequently recurring work. The first tool is called "Start VDI Clones with Delay" and can be implemented to start up multiple VDIs with a time delay This makes sense when the number of clones concerned is so large that the host cannot process 4 creates multiple clones from a connected Virtual Volume. "Create Standby VDI Clones" lastly allows the creation of VDIs on the standby server in a high availability configuration. The last area of the VDI Clone Tools deals with the monitoring of the running systems. "Open Windows Performance Monitor" provides those responsible with

5 various tools for performance monitoring. The monitored parameters include the run times of hypervisor and guests, the cache hits, the length of the disk queue and much more. Should bottlenecks occur anywhere, VDS will certainly not Collector sets to be installed and controlled. These sets then record preconfigured performance counters during operation that are relevant for the performance of the VDI infrastructure. Administrators can then use the already mentioned so that the users can communicate with the VDIs via this infrastructure. On the other hand and this solution is very interesting for smaller environments for which the installation and maintenance of a corresponding Microsoft environment would be too complex DataCore also provides a web interface that allows access to the VDIs via their browser. This web interface can be installed on IIS, but it must support ASP.NET. For commissioning of the web interface, it is by and large sufficient to copy the "WebPortal" files delivered by DataCore into separate folders to adjust the configuration file (the relevant steps are explained in detail in the documentation) and to register the web page in IIS. The end user portal and the administration page of the DataCore web interface are then available via the URLs " of the server}" or " of the server}/admin". Creating VDI clones with the aid of the relevant wizard leave administrators in the lurch when it comes to troubleshooting. Incidentally, performance monitoring runs via the Microsoft Performance Monitor. The last of the VDS Tools is called "Data Collection Logs". This allows Microsoft Performance Monitor Data logs later to find out, among other things, how many VDIs the current DataCore VDS configuration supports. The web interface There are two options for ensuring that end users can access the VDI clones: Firstly, VDS can be integrated into the Microsoft VDI architecture as 5 If administrators log into the Administration portal with the default credentials "admin/admin", they arrive at an administration page that allows them to add clones to the web portal, to view the clones registered in the portal and to display a list of the VDS hosts. Additionally, the administrator and user accounts can be administered via the administration tool, a list of machines exported in CSV format, messages sent to the users, and much more. In

6 testing we first created a test user, then added our clones to the web portal and subsequently ensures an efficient utilisation of the storage components that are available and simplifies the The monitoring tools also made a positive impression. The same applies to the web interface and the support of the Microsoft VDI environment. Both these access technologies enable seamless deployment of VDS in large environments, as well as the uncomplicated provisioning of VDI clones in smaller networks. Also, the fact that the clones provided by VDS are stateful should be positively highlighted once more, as this behaviour is expected by most users during operation. Accessing a Windows 7 clone via the DataCore Web Portal allowed the test user account to access these VDIs. We then swapped over to the web page for end users. Here users have the option of using the machines offered via RDP, which functioned in testing from the start, to change the machine names and to add a machine description, as well as an alias. administration at the same time. The wizards were clear and they deserve particular mention, as they make the creation and The resulting summary of our testing is that DataCore VDS, in comparison to many other solutions, is relatively simple to install, provides a high degree of performance and hardly makes any demands during operation. Consequently, we can thoroughly recommend the product not just In addition, they can adapt their user profile with name, address, telephone number, password and the like. The web interface functioned from the start, as expected. Its scope of features is limited to the most important ones though, but this makes the administration of the product very simple. Summary The Virtual Desktop Server 2.0 from DataCore is quick to set up, works reliably and manages with relatively modest hardware. The deployment of the virtual storage struck us as very positive, as this VDS as part of the Microsoft VDI environment management of the virtual desktops easy, even for inexperienced administrators. 6 for large installations, but also for small and medium sized environments.