At Citrix Synergy in Barcelona, Citrix unveiled the latest iteration of Project Avalon, dubbed Excalibur. Finally combining the management interface and back ends of XenApp
For as long as XenApp and XenDesktop have existed, we've longed for tighter integration.
Announced in May, Citrix Project Avalon came off as a cloud-orchestrated framework for deploying desktops. The Excalibur release falls a bit short of full-on cloud orchestration -- but in a good way. Rather than take a giant leap to a cloud-based infrastructure, Citrix has decided to do some very important housekeeping.
After years of dealing with different infrastructures for XenApp and XenDesktop, Citrix Excalibur combines the application streaming and desktop virtualization products into one back-end infrastructure with a single management interface.
The problem with IMA
To fully understand the implications of this, it's worth taking a look back at the past. When Citrix originally introduced the Independent Management Architecture (IMA), it was a well-received replacement to the ICA Browser architecture that early versions of XenApp (then called MetaFrame and WinFrame) used.
However, the ICA Browser was rife with issues because of its broadcast, distributed, and -- at best -- wonky implementation. IMA used a centralized database to manage published applications, policies and permissions. The problem with IMA was -- and still is -- that the database is not your usual structured one that behaves like a typical SQL database. It runs on SQL, but SQL is merely a container for an entirely different database structure that's effectively based on the Lightweight Directory Access Protocol.
More Citrix news
BYOD shops get Citrix Receiver, CloudGateway and ShareFile combo
Citrix acquires XenClient competitor Virtual Computer
Where Citrix will go with Receiver and Project Avalon
Early on, Citrix had aspirations to meld IMA with Active Directory. The bottom line is that IMA was a database within a database, and you couldn't fully leverage real SQL-like functionality with it.
Citrix built the first version of XenDesktop on IMA, mainly because that was the only thing available. It soon became apparent that IMA was not the proper architecture for delivering virtual desktops. IMA was designed as a hierarchical system for environments with a few hundred servers, or nodes. Each virtual desktop was treated by IMA as a separate terminal server, so instead of hundreds of nodes, there were thousands of them, and scalability suffered.
Citrix had lofty goals for XenDesktop and designed a suite of technology called FlexCast that encompasses solutions such as profile management, client hypervisor management and enhanced protocol performance. Out of this was born the FlexCast Management Architecture (FMA), and every version of XenDesktop since the very early versions has been based on FMA.
Not long ago, Citrix began to bundle XenApp with XenDesktop. That was a step in the right direction, but each product came with its own management console and kept its back-end architecture. That meant that while you were entitled to use XenApp with XenDesktop, you still had to deploy each tool separately.
For as long as XenApp and XenDesktop have existed, we've longed for tighter integration. That's where Excalibur comes in.
Excalibur to the rescue
Excalibur represents the merging of the XenApp and XenDesktop technologies into one cohesive package that's built on the same back-end components. Desktops are desktops to Excalibur, whether they come from Remote Desktop Session Host (RDSH) or Windows 7 virtual machines (VMs).
Additionally, Excalibur creates new instances of both RDSH and VDI VMs from its management console using Citrix Provisioning Server (PVS) or Machine Creation Services (MCS). The differences in those methods are worth a standalone article, but suffice it to say that MCS is the future image delivery scenario for Citrix.
For admins, this combination is exciting and liberating, but it does bring some new concerns. The main one, for me, is with regards to the scalability of the RDSH solution. The IMA architecture relies on zones to spread appropriate information around the farm. Zone Data Collectors collect information from other XenApp servers, sort that data and commit it to the IMA database. They also are the first line of communication for application access and policies -- key to the scalability of XenApp.
With FMA, there is no such thing, so we need to see how scalability is affected after the switch to FMA. In theory, since FMA was built to scale past IMA, I don't expect to see many issues.
Here's another interesting question: What's happening to the XenApp and XenDesktop names? The best answer I got was "TBD." When Citrix speaks about Excalibur, it uses generic terms such as "VDI desktop," "session-hosted desktop," or "session-hosted application." This could mean that the XenApp and XenDesktop names are on the way out, which isn't a deal other than meaning that there are now three versions of RDSH-based solutions out there.
The last thing that bears consideration is that Excalibur will not support 32-bit RDSH servers like Server 2003 R2 or Server 2008 (not 2008 R2 -- that's 64-bit only). It will, however, support 32-bit desktop operating systems. The reason for this is that machines are added to the system in much the same way as XenDesktop VMs are registered with the system -- through a Virtual Desktop Agent (VDA) which only comes in 32- and 64-bit client OSes and 64-bit server OSes. You'll have to maintain a separate XenApp (IMA-based) implementation for legacy apps that require 32-bit server OSes.
The Tech Preview version of Excalibur will be released Nov. 1, but if you want a look at the new management interface, check out the video of the demonstration I received from the show floor at Synergy Barcelona.
This was first published in October 2012