One of the goals in designing the Citrix App Layering architecture was to create a system that would allow customers to manage their Windows Operating Systems and applications a single time, regardless of the hypervisor environment or cloud they wish to use their layer packages. We understood that any mixed hypervisor environment or any hybrid cloud configuration would force most organizations to maintain two different sets of images and applications in two different management platforms.

To alleviate this management pain in our ever-increasingly hybrid world, we allow for our layer deployment models (there are two of them) to span any platform.

app-layering

The Enterprise Layer Manager (this is the virtual appliance that manages the layers) deploys layers in two ways:

  • Elastic Layers – These are dynamic layers that attach applications at login. These are often used for line of business (LOB) apps or individual user apps.
  • Layered Images – These layers contain the OS and any apps you have assigned to that image.

In each of these models, the design assumes that the layers can be used in any environment. Let’s look at the components of each model to understand why they support multiple platforms.

Elastic Layers

Elastic Layering is a method to dynamically deploy applications to a Virtual Machine at the time the users logs into the VM.  The App Layering Services running in the target VM are configured to use an SMB network share as the Layer Repository. The repository contains all of the layers and configuration files required for deployment. The Layering Services will read the configuration files then mount the layers assigned to the users. This process is designed to work entirely within the guest operating system using native Windows VHD file mounts over the network.

By storing all layers and configuration files needed in a standard share, then using only components located within the VM to mount these layers, our application connectivity is completely abstracted from the underlying hypervisor. So, whether you are running on XenServer, vSphere, AHV, Hyper-V or in the cloud, this same share (or a replica of it) can be leveraged. No calls to the hypervisor or cloud APIs are made during login or during attachment of the assigned layers. Since everything takes place inside the running Windows environment, these layers can be used on any hypervisor, as long as the app layers are available via a share.

Layered Images

While the design of the Elastic Layers is intuitive and easy to understand, Layered Images are often a little more of a head scratcher. I mean, we know as IT folks, that an OS image running on one hypervisor often has different drivers and virtual hardware that keep it from “just running” on another hypervisor or in our cloud subscription.

This is where Layered Images really shine. The image generated from the Enterprise Layer Manager is really a compiled group of assigned layers (including the OS) into a single virtual disk. That virtual disk is configured for the target environment (think platform/hypervisor here) at time of creation.  The “trick” here is that we have a unique layer type called a Platform Layer that is designed to contain things like target environment drivers. In addition, we have what we call Platform Connectors, that understand different target environments and how to prep and move the image for use into the targeted environment.

This means that the same set of layers (including the OS layer) that you are running on one environment can be “pushed” to different environments without recreation of the OS and without managing multiple sets of images in different tools.

Let’s look at these two concepts (the Platform Layer and Platform Connectors) quickly.

The Platform Layer

al2

A Platform Layer is almost identical to an application layer, but it is designed to contain all the software needed for a particular hypervisor, the provisioning service to be used, and the connection broker. The true difference between an App Layer and a Platform Layer is that a Platform Layer is only applied at time of image creation. The OS and App layers that make up the Layered Image are combined with the Platform Layer to make a bootable image that is in the correct format and state for the target environment.  Since the App and OS Layers contain only information specific to them and the Platform Layers contain the drivers and software for the target environment, it is very easy to view the concept of a Platform Layer and its ability to move Layered Images between different hypervisors. The thing to note here is that this concept and technology has been around since the first versions of Unidesk. The same technology that was used to build “boot images” in Unidesk 1.0 laid the foundation for Layered Images and our cross-platform capabilities.

The Platform Connector

To distribute the Layered Images to various provisioning tools, the Enterprise Layer Manager communicates with the underlying target hypervisor to create layers and or deploy images. Each hypervisor uses different APIs, in addition to the various available APIs for different provisioning tools (such as Citrix PVS or MCS, or VMware View Composer). This means that each connector for publishing images is specifically written to support both a hypervisor AND a provisioning system. As an example, you may see a single system with two connectors: one for Citrix MCS on vSphere and another for View Composer on vSphere. While the code is similar for hypervisor operations, each provisioning system has different requirements for the underlying disk, the OS preparation state, and the configuration of the VM itself (if used).

When publishing an image the admin will select the platform connector to use, and the Enterprise Layer Manger will composite an image (including the assigned Platform Layer) and send it directly to that service, with no other action required. This process will include building the base virtual disk that contains all assigned layers, putting that disk into the proper format (VHD, VMDK, etc.), and prepping the disk to be used by that target provisioning system (example: PVS disk states and configurations are different that MCS disk state and VM requirements), and then finally copying the disk to the target environment.

All of this happens regardless of the various platforms you are managing virtual machines on. The admin simply manages Windows Operating Systems and their applications one time and can distribute them as needed.

Wrapping up!

When combining these two delivery methods, you arrive at a management model that makes it simple to manage Windows and applications across increasingly complex environments. The benefit of this model is that it enables an administrator to update applications and operating systems once, using a single interface and a single technology, regardless of where the application will eventually execute. It doesn’t matter if your sites are all internal XenServer-based environments and cloud is just something in the future, or you have an on-prem mix of hypervisors with cloud as a DR or for specific lines of business.  All deployments can use the same base layers and be managed and updated in one place, one time.

If you would like to give Citrix App Layering a try, you can request a trial right from Citrix Cloud. Create a Citrix Cloud account (there’s no cost) and then select Citrix App Layering from the menu to access your 60-day free trial. The Citrix App Layering service includes full feature functionality and eligible customers with active Customer Success Services Select can use this service for production roll out.

syn17-h-banner-blogfooter-729x90