FASP in virtual environments

by John Heaton
 

Aspera's high-speed transport technology, fasp™, is used to fully utilize bandwidth no matter the network conditions, even in the presence of other traffic. Until recently this rate control capability had difficulty in achieving full efficiency in virtual environments. With the introduction of fasp™ 2.6.4 (a patch to 2.6.3) and the release 2.7, the fasp™ technology can be deployed in virtual machines where it was once susceptible to problems.

Understanding Virtualization

To adequately discuss the problem and resolution it is important to make a distinction with regard to the various virtualization technologies available on the marketplace. While there are various methods to do virtualization (Full Virtualization, Para-Virtualization, Emulation, etc) the important distinction is if a host/guest model is deployed, or is the virtualization technology making use of a hypervisor. Since hypervisor implementations such VMWare ESXi and XEN are the most prevalent uses of virtualization technology in the enterprise, the fasp™ 2.6.4 implementation is designed to work in virtual machines deployed in a hypervisor. While the research shows the solution in fasp™ 2.6.4 will work in other virtual machine models, a hypervisor implementation is recommended to ensure best performance.

A hypervisor is a layer of code that straddles the hardware and the virtual machines. These virtual machines are called guest operating systems in virtualization parlance. As opposed to the host/guest model where virtual machines run on top of another OS, a hypervisor provides the closest access to hardware resources. If a virtual machine was working inside another OS, the virtual machine is at the whim of the host operating system. Hypervisors allow the guest operating system to not depend on the underlying OS use of system resources since the hypervisor's sole purpose is to manage virtual machines (as opposed to virtual machines, terminal services, user input, etc).

Before continuing it should be noted that the preceding was just a summary of virtualization. A good reference to these topics can be found in a number of places, such as this article in Ars Technica as well as this follow-up.

The problem with Virtualization and fasp™ prior to 2.6.4

The fasp™ protocol has two main modes:fair, which automatically adapts transfer speed to network conditions, and fixed; virtual machines affect the fair mode but does not adversely impact how fixed transfers occur. The reason for this disparity is found in the nature of how virtualization technologies make use and provide access to system resources. The fair mode algorithm makes use of clock timing at precise intervals to adjust the transfer rate as capacity becomes available or unavailable, and virtual machines typically do not provide the timing accuracy necessary to be effective. In particular, virtual machines may get "dirty" values that misrepresent the true timing, and these values would cause fair mode transfer to not be as efficient as possible.

Opting out of Virtualization

Of course, the simplest way to avoid the problem is to not run Aspera in a VM. While Virtualization provides a lot of benefits, like hardware utilization, on demand computing and certain high availability configurations, their utility in certain High Performance tasks is arguable. By dedicating hardware for high performance transfers you can be assured that the software is working as it was intended to the specification of the hardware used.

Sadly, the realities of modern datacenter design require higher degrees of utilization per square foot or per watt used. That is where virtualization comes in to play, and that is also why fasp™ 2.6.4-VM was developed.

The solution to Virtual Machine deployments offasp

With the release of fasp™ 2.6.4 and on to version 2.7+, the protocol now employs filters to remove the incorrect timing data that used to skew the rate control capabilities offasp™.

Installing the patch

If using 2.6.3, an upgrade to 2.6.4 is needed. The procedure for installing the patch, as well as the patch itself, is documented in the Patch README and release page

Enabling the filter in 2.7+

Add<rtt_autocorrect>true</rtt_autocorrect> to the <protocol_options> section of theaspera.conf. This can be done from the configuration UI in the Windows and Linux GUI, as well as the Console's Configuration tab.

Where to deploy

The code necessary to correct the VM skewing needs to be on the receive side of the transfer. It is safe to assume that the VM where the server is located is a prime candidate for the patchedascp, but the patch should also be deployed on bare-metal systems that receive data from VM Aspera servers and clients. As for the tag in the configuration, it is only needed on one side of the connection. If set on one side of the transfer, it will be set on both ends.

Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk