Virtualization is very hot at the moment. Many companies are considering virtualizing at least some part of their infrastructure. Which possibilities exist for SBC infrastructures, how far developed are these options, and what are the experiences with virtualization? In this article we will take a short journey through virtualization with the SBC infrastructure in mind.
Virtualization Techniques
Server Virtualization
The first virtualization technique that came into the market was server virtualization. With server virtualization your server software is not installed and running on a physical machine directly, but will run on a specific host together with more virtual servers. The host (software) arranges the use of available resources, which are offered as virtualized resources.
The main reason for this virtualization technique was that at the time several server applications were not compatible which each other. For every new application a new server was needed, where most of the time the server resources were not used much and were taking up a lot of space in data centers. Being able to run all these servers on one physical machine makes better use of resources, is more efficient, and takes less physical space. The first machines offering this were big servers full of processors, memory and Network Interface Cards; this way every virtualized server could use its own processor, memory and network interface card, so the space problem was solved.
Server virtualization developed very quickly into the current server virtualization possibilities – now the usage of server resources can also be controlled.
Resource Virtualization
With this virtualization technique virtual machines can share physical resources like processor, memory and network interface card capacity. As mentioned earlier many server applications do not use all the resources which are made available. So with applications of this type it is definitely a good idea to share one processor, for example if both use only a few CPU resources. Current server virtualization techniques also make it possible to add or remove assigned resources to the virtual machine quickly.
As you can see Server and Resource virtualization are nowadays complementary. This has resulted in a robust solution to host several virtualized servers on several hardware platforms. The most well known is VMware with their server virtualization products, where the ESX product is the most robust implementation.
With all the developments for server virtualization techniques and the strong interest of companies in virtualizing their server infrastructure, the question of whether Terminal Servers can be virtualized is being asked more frequently. Technically Terminal Servers can be virtualized without any problems, but there are a couple of practical downsides.
First of all Terminal Servers are pretty resource intensive because there are more users are accessing the server simultaneously. Because usage is located in the user reserved part of the memory and many applications cannot use more than one or two CPUs, adding more (virtualized) resources is not useful. Several experts on VMware and SBC, like Ron Oglesby, stress tested virtualized Terminal Servers. These these tests showed that with 20 to 30 users connected the servers got exhausted. While running the same tests on physical machines the amount of users increased to 50 – 60 users. This means that you would need twice as many virtual servers than physical servers.
Last, but not least, is manufacturer support for virtual machines. Citrix’s official statement in article CTX997956 is that they support Citrix Presentation Server on virtualized servers, but support is based on best effort and hotfixes will only be released if the problem can be reproduced on physical hardware.
Application Virtualization
The big upcoming virtualization technique is application virtualization. With application virtualization applications are not installed on the hard disk of the machine, but will be packaged and run on to a virtualization layer. This virtualization layer runs above the operating system in a read only modus. This way the application in the layer can use resources available within the operating system, but cannot change anything. Every application has its own separated virtualization layer (often called a bubble). These separated bubbles insure that applications cannot conflict with each other, because all the needed files are available in the bubble for that specific application. In contrast with applications installed on the hard disk, files are not overwritten. This is big advantage because more applications can be run on the same machine without conflicts. Also updating an application is much easier because you only need to replace the version number of the bubble instead of another installation on the hard disks. Virtualized applications use resources in the same manner as applications installed on the hard disk (except disk space, logically), so application virtualization does not prevent excessive resource usage of an application. Detailed information about Application information can be found in the article Using SoftGrid for Conflicting Applications in Terminal Service Environment.
SBC environments profit a lot from application virtualization on Terminal Servers, because many applications can be made available from the servers. Since application conflicts no longer occur, more applications can be made available on the same server. This is valid for different applications but also different versions of the same application. Time which is normally spent while updating and testing can be shortened. This is endorsed by the new Application Streaming feature within Citrix Presentation Server and the acquirement of SoftGrid by Microsoft last year.
Operating System Virtualization
With the acquisition of Ardence by Citrix, this virtualization technique is now appearing in the spotlight. With Operating System virtualization nothing is installed any more on the local device, but everything is run from a so-called virtualized disk from the network.
With this technique you can use private disks or shared disks. A private disk is used by one client only, just like a local disk. Depending on the user rights inside the operating system the user can save information on the disks. The changes are saved on the virtualized disk. Secondly there are shared disks. This kind of disk can be used by more clients (at the same time). During use changes are saved in a special cache, but when the client is shut down or restarted the cache will be cleared. In other words, when the client boots up they will use the default configuration available on the virtualized disk. The virtualized disk will be created to take a copy from one machine that is installed in the traditional manner. The software will make sure that when a client boots the computer name is changed to a unique identifier in your infrastructure. Because the creation of the virtualized disk is just like imaging, you should develop some system whereby other identifiers (like the Citrix Services) are changed during boot up, either by scripting or other means.
Operating System virtualization is very useful in very secure environments (nothing is available locally on the client), to keep all clients exactly the same (uniform), simplified management and easy update mechanisms (for new applications, hotfixes and more) with a quick fallback scenario.
Operating System Virtualization can be very useful in SBC environments. Often it is very difficult to keep the servers identical because of the many changes and updates to applications and the operating system. Testing updates is also very difficult and fallback scenarios are time consuming. When Operating System virtualization is used with the shared disk methodology every server is exactly the same when it is restarted. Updates can be easily tested and implemented, with a quick fallback scenario.
VDI Virtualization
The demand to access applications from any place at any time by employees is growing rapidly. Web-based applications and Terminal Services are two familiar techniques to access applications outside the office building. But some applications are not available in a web-based version or are not Terminal Server aware and can only be installed on a fat client (operating system). In a Virtual Desktop Infrastructure these kinds of applications can be installed with a client operating system (for example Windows XP) on a VMware ESX server. An additional third party product (called Broker) is used to manage the VDI environment, for example, determining which Remote Desktop Host a user is assigned/connected to, automatic deployment of the VDI system and the provisioning of Remote Desktop Hosts. A very detailed description of VDI is described in the article Virtual Desktop Infrastructure Overview.
VDI basics are pretty similar to SBC concepts. Only you provide access to an application or desktop that can only be accessed by one user per VDI system. Actually VDI can be the solution for those applications you cannot offer via the Terminal Server environment right now. When using VDI you can reduce the need for fat clients within the office and allow the use of applications out of the office.
Conclusion
In this article the current virtualization techniques were briefly discussed. Secondly we looked at those techniques and what they can do in your SBC environment. We can conclude that application virtualization, operating system virtualization and VDI can be complementary to SBC infrastructures. Server virtualization is also possible, but the downsides must be considered carefully before virtualizing your Terminal Servers.
