Co-Authored by Dale Carter, Senior Solutions Architect - VMware Professional Services Engineering
App Volumes, a result of VMware's recent acquisition of CloudVolumes, provides an alternative, just-in-time method for integrating and delivering applications to virtualized desktop and Remote Desktop Services (RDS)-based computing environments. With this real-time application delivery system, applications are delivered by attaching virtual disks (VMDK’s) to the virtual machine without modifying the VM or applications themselves. Applications can be scaled out with superior performance, at lower costs, and without compromising end-user experience.
For this blog post, I have colluded with Dale Carter - one of my good friends and former colleague from VMware's Professional Services Engineering team. Dale and I will discuss ways to build resiliency and scalability within the App Volumes architecture using F5's Local Traffic Manager (LTM).
Basically, App Volumes does a "real time" attachment of applications (read-only and writable) to virtual desktops and RDS hosts using VMDK's. When the App Volumes Agent checks in with the manager, the App Volumes Manager (the brains of App Volumes) will attach the necessary VMDKs to the virtual machines through a connection with a paired vCenter. The App Volumes agent manages the redirection of file system calls to AppStacks (read only VMDK of applications) or Writeable Volumes (a user-specific writeable VMDK). IT administrators, through the web-based App Volumes Manager console, can dynamically provision, manage, or revoke applications access. Applications can even be dynamically delivered while the users are logged into the RDS session or virtual desktop.
The App Volumes manager is a critical component for administration and Agent communications. By using F5's LTM capabilities, we can intelligently monitor the health of each App Volumes Manager server, balance and optimize the communications for the App Volume Agents, and build a level of resiliency for maximum system uptime.
Who is talking with what?
As with any application, there's always some back-and-forth chatter on the network. Besides administrator-initiated actions to the App Volumes Manager using a web browser, there are 4 other events that will generate traffic through the BIG-IP: these 4 events are very short, quick communications - there aren't any persistent or long-term connections kept between App Volumes agent and manager.
When an IT administrator assigns an application to a desktop/user that is already powered on and logged in, the App Volumes Manager talks directly with vCenter and attaches the VMDK. The Agent then handles the rest of the integration of the VMDK into the virtual machine. When this event occurs, the agent never communicates with the App Volumes Manager during this process.
Configuring Load Balancing with App Volume Managers
Setting up the load balancing for App Volumes Manager servers is pretty straightforward. Before we walk through the load-balancing configuration, we'll assume that your F5 is already setup on your internal network and has the proper licensing for LTM.
Also, it's important to ensure the App Volume agents will be able to communicate with the BIG-IP's virtual IP address/FQDN assigned to App Volume managers - take the time to check routing and access to/from the agents and BIG-IP.
Since the App Volumes manager works with both HTTP and HTTPS, we'll show you how to load balance App Volumes using SSLTermination. We'll be doing SSL Bridging (SSL from the client to the F5 à it is decrypted à it is re-encrypted and sent to the App Volumes Manager server). This method will allow the F5 to use advanced features, such as iRules and OneConnect, while maintaining a secure, end-to-end connection.
Click Here to get a step-by-step guide on integrating App Volumes Manager servers with F5's LTM. Here are some prerequisites you'll need to consider before you start:
Determine what the FQDN will be and what virtual IP Address will be used.
Add the FQDN and virtual IP into your company's DNS.
Create and/or import the certificate that will be used (in this blog post, we won't be covering creating, importing and chaining certificates).
The certificate should contain the FQDN that we will use for load balancing. We can actually leave the default certificates on the App Volumes Manager servers - BIG-IP will handle all the SSL translations, even with self-signed certificates created on the App Volumes servers. A standard, 2048-bit Web Server (with private key) will work well with the BIG-IP - make sure you import and chain the Root and Intermediate Certificates with the Web Server Certificate.
Once you're done running through the instructions, you'll have some load-balanced App Volumes Manager servers!