I’m old enough to remember when virtualization technologies first came on to the scene. Initially they were strictly relegated to learning environments such as test labs. These Type 2 (hosted) hypervisors were typically third-party software solutions that installed on top of a general purpose operating system such as Windows and Linux. They were not recommended for production environments at all. Later, Type 1 (native) hypervisors became more prevalent, and these solutions were designed and supported for production deployment. This was a real game changer, and greatly aided server consolidation and datacenter optimization. The rush to virtualize everything was on.
However, as we often discovered the hard way, not all workloads lend themselves well to virtualization. In the early days, anything that placed heavy demands on the disk subsystem was often better served using physical servers. The same held true for network-intensive workloads. Advances in modern hypervisors, solid-state disk drives, and CPU performance gains now allow for nearly all workloads to be supported reliably and efficiently, with a few exceptions and caveats.
Challenges in deploying DirectAccess in virtual environment
DirectAccess presents unique challenges to systems engineers who wish to virtualize this workload. DirectAccess is both network and CPU intensive, placing heavy demands on the underlying shared virtual infrastructure, even with relatively small deployments. Unlike traditional client-based VPN, concurrent connections are much higher, as DirectAccess is an always-on solution. Any time a remote DirectAccess client has an active Internet connection they will be connected to the corporate network through the DirectAccess server. The DirectAccess server consumes resources in order to maintain these network connections, and places substantial load on the CPU as all of the network communication is encrypted with IPsec. In addition, a significant percentage of DirectAccess clients often rely on the IP-HTTPS IPv6 transition protocol, which encapsulates IPsec encrypted traffic in HTTP and encrypts it again using SSL/TLS. This additional encryption/decryption further strains the CPU. Using Windows 8.x clients can help alleviate this bottleneck, as they can leverage null encryption. However, Windows 7 clients cannot, and are the most common DirectAccess clients supported today.
Further complicating things is that the DirectAccess experience is particularly sensitive to latency. In a virtual environment, all network communication runs through the virtual host’s CPU, and running DirectAccess in a shared virtual infrastructure with already heavy CPU demand (the goal for a virtual host server!) can degrade the user experience if it is not addressed. Solving these challenges in a virtual environment requires reserving generous amounts of resources to the DirectAccess virtual machine, especially CPU and RAM. Of course this is often detrimental to the performance of other workloads on the virtual host. In addition, using dedicated physical resources like pass-through disks or special Single Root I/O Virtualization (SR-IOV) network adapters are often required to reduce latency and improve throughput. In some cases, deploying dedicated virtual host servers for DirectAccess may be required, especially for deployments supporting thousands or tens of thousands of connected DirectAccess clients.
Of course all of this comes at great expense, both in terms of cash and supportability. Pouring money in to a specialized virtual infrastructure to support DirectAccess is expensive, and the complicated configuration makes it much more difficult to manage and support. Also, dedicating resources to DirectAccess defeats the whole purpose of virtualization in the first place, which is to consolidate workloads in a shared environment to improve host utilization.
Recommendations for Deploying DirectAccess
For a small test lab or a very limited proof-of-concept deployment, perhaps a virtual deployment for DirectAccess might work. However, in all but the smallest of DirectAccess deployments there are diminishing returns for virtualizing this specific workload. In almost all cases, DirectAccess is much better suited to running on a dedicated appliance. Without the performance penalty imposed by the hypervisor, the DirectAccess experience is far better both for end users and administrators alike. Deploying DirectAccess on the Celestix hardware appliance or virtual machine, with its certified configuration and predictable performance, can reduce your deployment time and administrative costs while at the same time ensuring the best possible experience for everyone involved.
For more information, email us at sales@celestix.com or call us at +1 (510) 668 0700.
