In my previous post I speculated how Citrix would plan to support Windows 2008 R1 and R2 DDCs.
With the recent announcements at Synergy Berlin on XenDesktop 5 Citrix’s strategy on supporting these OS’s in the next release of the product is becoming clearer.
No more XenDesktop IMA
The IMA service, that XenDesktop 4 was built upon, and has been the foundation infrastructure service of XenApp since the dawn of time, is being replaced with a new web-service in XenDesktop 5. This should remove the scalability limitations of IMA to allow XenDesktop farms to contain many tens or even hundreds of thousands of virtual desktops.
No mixed farms
We’ve already seen a move to not supporting mixed farms with the release of XenApp 6, where instead of allowing servers running the new version to join an existing XenApp 5 farm, you have to create a new farm, and provide aggregation of the two environments to the user using Web Interface. Citrix provide a migration utility for moving configuration settings and published applications from one environment to another, but you need to manage two distinct environments until your migration to XenApp 6 is complete.
This trend will continue with XenDesktop 5 due to the vast differences in architecture so it won’t be possible to have a mixed farm containing XenDesktop 4 and 5 DDCs or VMs.
Are new farms an issue?
Those who have been working with XenApp, Presentation Server or Metaframe for any length of time will already know that performing migrations to new versions via a new farm became the Citrix-recommended approach once Web Interface could connect to multiple farms to provide the application aggregation into a single view for users. So, from that perspective the requirement to create a new farm to migration is nothing new, and we’ve been doing it for years, but creating new farms does introduce challenges:
New SQL databases
As a new farm requires its own database, you will need to involve your DBA’s to get these created. For large enterprise environments that have multiple farms around the world this means multiple new databases, or for those with large complex replicated data store artchitecures this can be a large piece of work.
Parallel administration
With each new farm you add, there is a new admin console to manage it and training on how the various support staff, helpdesk, 2nd line, 3rd line etc all access this new console. Delegated administration and permissions need to be configured in the new farm to match (and hopefully improve on) the previous environment.
More images
If you use Citrix provisioning services to deploy your Xen infrastructure, each new farm means a new image to manage. This has to be maintained, patched etc and adds admin overhead to your release management cycles.
Retained legacy
We’re often keen to deploy the new stuff, but migrating 100% of users across to it can be painfull and often take considerable amount of time and resouce. Businesses may take the “if it ain’t broken, don’t fix it” approach and choose to stay on the existing stable platforms. This means legacy farms often hang around for many years, with noone taking ownership of them and funds long dried up to move anyone off them.
All these scenarious add cost and complexity to the environment.
Where does this leave XenApp?
Citrix have talked about moving XenApp to the new management platform and away from the old SQL blob-based datastore for a number of years. Now they have made this jump with XenDesktop (to iron out the version one bugs on a far lesser used platform?) I would expect the next release of XenApp to move to this model and require you to have a seperate farm without IMA and with a different datastore model.
This does raise the question of whether one should even start to move existing XenApp 4/5 farms onto a XenApp 6 platform if another big farm-wide move is on the cards for XenApp v.next. Should one wait and then only have to do one farm migration? Windows 2003/2008 server and XenApp 4/5 will be supported for quite a number of years to come, and going by Citrix almost-annual major release cycle, we could well see this new XenApp architecture appearing later in 2011.
Version explosion
Having customers on so many different platforms is going to be a stretch for Citrix developers and Engineering. If you look at the existing, and potential future branches of the XenApp code base you will see that producing hotfixes and service packs will become a major resource drain, sucking resources from producing the “new stuff” we all expect from our annual SA payments:
- XenApp 4.5/5 on 2003 – supported until 31/03/2013
- XenApp 5 on 2008 R1 – supported until 31/03/2013
- XenApp 6 on 2008 R2
- XenApp v.Next without IMA?
Each of these platforms have subtle differences requiring different binaries, hotfixes and service packs. XenApp 6 is vastly different with a new policy engine and different integration with RDS. I don’t ever remember a time when Citrix had this many versions of XenApp as supported production platforms. Which platforms should Citrix release new features on? There is a vast expanse of XenApp 4.5/5 on 2003 who don’t need to upgrade (or can’t because of the jump to 64-bit OS would break too much).
We’ve already seen a new enhancement pack for printing released for XenApp 6 only – is this trend going to continue? Will there be any more “feature packs” for customers still on XenApp 5? I would imagine so, but the feature set of XenApp is going to get so complex across the four “flavours” it’s going to be a nighmare for support.
Is this going to be a problem for Citrix over the next few years? Time will tell.
Going over the recent Synergy announcements and other discussions I’ve had with product experts it got me thinking what the Citrix networking range of products (Netscaler, Branch Repeater, Access Gateway, Open Cloud Access) might look like in a few years time.
Here’s a bold prediction:
Citrix networking products will eventually only be available as virtual appliances.
Lets examine why this would make sense.
Citrix are modularising their products
Netscaler has always been modular in the fact the same hardware device can run different editions of Netscaler software depending on which license you’ve purchased. Newer releases of the VPX appliance are licensed by consumption rather than features. Imagine being able to run a Netscaler, Branch Repeater and OpenCloud solution on the same piece of commodity hardware on your chosen hypervisor. Want to add a CAG? Fine – just import the CAG VM onto your existing kit.
Don’t have an existing hypervisor? No problem, Citrix will ship a fully supported Netscaler+XenServer installation you can install onto your hardware.
Citrix are moving to a common code base for their products
Take Access Gateway- Citrix will be able to run this on native CAG hardware, Netscaler hardware, and virtual appliances. If all platforms (apart from Hyper-V and ESX/VSphere) can be provided by utilising the Xen kernel this cuts down the number of platforms the code needs to support.
The Access Gateway v5 is being modularised so it can be run on both legacy CAG hardware and existing Netscaler hardware.
Citrix core strength isn’t hardware
Having to maintain relationships with different hardware manufacturers/vendors is time consuming and costly. Shipping tin is not one of Citrix’ core strengths – they are a software company. Today Citrix (and their customers) have three possible hardware devices : CAG (former Net6), Netscaler and Branch Repeater (formerly WANScaler)
If Citrix can provide a HCL for their networking products (via the XenServer HCL plus minimum hardware specifications) and be a purely software vendor that moves the whole hardware design/procure/support/repair onto someone else’s plate. Citrix could partner with a HP or Dell or even Cisco to recommend suitable off-the-shelf hardware to support the required throughput, and even offer support contracts with the relevant product support services if customers didn’t already have some kind of hardware support agreement in place.
If customers just want to use their existing Virtual Infrastructure platform, great. Citrix already supports this model today via their VPX appliances.
Let the hypervisor handle HA
Citrix will no longer need to spend as much time writing HA code into each individual product. Let the hypervisor provide the HA that best suits the customers requirement. Simpler code, fewer bugs resulting in enhanced reliability.
True elastic capacity
It’s far easier to add resources to a VM (cpu/memory) and spin up new VMs than it is to buy another appliance and get it racked & stacked in your data centre. Cloud providers wanting to do multi-tenant installations can provision lots of smaller virtual instances, rather than carve up a large, expensive device.
If your data centre is in the cloud, you don’t have (and need) hardware
Cloud providers already have data centres chocked full of their preferred flavour of hardware. They just need the features Citrix provide in their software. If more and more companies start using cloud providers to host their infrastructure, the demand for kit on customers own sites will plummet. As demand for hardware decreases, costs increase due to lower production runs, eventually making it uneconomical to continue to sell hardware devices.
Improving hypervisor network I/O
Technologies such as Intel SR-IOV are allowing hypervisor network I/O to reach previously unheard of levels. With the massive network I/O required by Netscalers and Branch Repeaters, such emerging technology would allow appliances to access the full capability of the hardware without having to be running directly on the tin like todays boxes.
Much lower start-up costs
Committing to buy a bunch of devices is expensive, especially if you don’t need all the capacity they provide from day one (but you need the ability to ramp up capacity on expand, so need the higher-spec boxes which cost more) . Being able to deploy virtual instances, starting small, on commodity hardware, and then ramping up VM resources, and your license to match demand makes much more financial sense and delivers true utility computing.
What are the challenges?
No hardware encryption
Netscaler devices contain dedicated hardware designed to perform fast encryption and decryption for the SLL offload engines. Commodity hardware would not contain this, so would need addition CPU resources allocating to achieve anywhere near comparable performance as the current hardware.
Commodity hardware can be expanded with hardware-encryption capabilities via PCI cards but this would need to be accessible through the Xen hypervisor, very much like the pass-through GPU and SR-IOV networking work being done.
No fail-to-wire NIC
WANScaler devices usually sit in-line between WAN routers and your LAN. To prevent loss of connectivity if the device, or NIC fails, they are equipped with special “fail-to-wire” NIC adaptors which turn into a piece of cable if on failure.
These NICs are not generally available for commodity hardware, so you would lose this fail-to-wire functionality, and risk a potential network outage should the virtual appliance or hypervisor fail, hang or develop a hardware fault. Some of this might be mitigate by the HA features of the hypervisor, but networking and routing is complex, and whether one could achieve the same level of “fail safe” as a fail-to-wire hardware NIC remains to be seen.
What do you think?
Post your thoughts and comments.
The current state of affairs
At present, if you want to build a XenDesktop Desktop Delivery Controller (DDC), it has to be on a Windows 2003 server. This requirement comes from the fact that the XenDesktop code is based on a customised XenApp 5 installation which is Windows Server 2003 only. XenDesktop 4 will have been around for a year soon and we still need to deploy “legacy” 2003 servers when building our shiny new XenDesktop farms. Sounds kind of crazy doesn’t it? But let’s examine why this is and what Citrix might do about it in a future release. Note this article isn’t based on any specific knowledge of future product releases, just analysis of the existing products.
2008R2 challenges
As we know, XenApp 5 can’t be installed onto Windows 2008R2 server – this requires XenApp 6. So, for Citrix to support 2008R2 XenDesktop DDCs, it would seem logical that the XenDesktop code needs to be based upon XenApp 6.
Lets look at the reasons you need a different version of XenApp for Windows Server 2008R2:
1. New RDS API hooks
Microsoft changed the hooks for Terminal Services (now known as Remote Desktop Services or RDS) to remove the “secret” API that Citrix developed and then licensed back to Microsoft. Citrix had to change their ICA stack into RDS to comply with the new APIs which meant a re-write of a number of system-level drivers.
2. 64-bit only OS
Windows Server 2008R2 is a 64-bit only operating system, which means all driver code has to be fully 64-bit and correctly signed.
So a Windows 2008R2 DDC release will be based on the XenApp 6 code?
Seems logical doesn’t it? But having XenApp 6-based DDC’s on Windows 2008 R2 servers will create the same problem XenApp users have in that you can’t mix XenApp 5 and 6 farms. Having to create a separate XenDesktop farm to introduce your first 2008R2 DDC would be a real pain. You would need new AD OU’s, SCP objects and a whole bunch of new desktop groups.
But let’s dig deeper and see if this will really be the case.
XenDesktop DDCs are equivalent to XenApp servers without the terminal services component (although bizarrely you need Terminal Services installed in application mode to install a XenDesktop DDC – a legacy left over from XenApp perhaps?)
So if RDS isn’t required, it should be relatively easy to port the non-RDS dependent components onto Server 2008R2 as it’s the RDS hooks that require the expensive re-write. Having the same “branch” of the code-tree should allow mixed XenDesktop farms with both 2003 and 2008R2 DDCs – something XenApp customers just can’t do due to the RDS changes and the new policy design Citrix also introduced in XenApp 6.
Citrix already offer a 64-bit 2003-based DDC installation so all the 64-bit porting issues will already have been addressed.
Finally, thinking about the Virtual Desktop Agent (VDA). This is like a mini-DDC – it has an IMA stack to communicate with DDCs and also doesn’t utilise RDS having it’s own ICA stack not requiring RDS. Crucially, this is supported on Windows 7, which is the same kernel as Server 2008R2 – so Citrix have most of their XenDesktop 4 stack already working on this kernel version.
So, the final question of this article remains unanswered: Why is it taking Citrix taking so long to release a DDC installation for Windows Server 2008R2?
Our friends over at Zenapp Blog have posted a great article on installing and configuring Merchandising Server 2.
The enterprise application store? Really?
Citrix calls Dazzle, it’s self-service “iTunes”-style appstore for your published applications, an “enterprise application store” .
Is that accurate though?
In reality, it’s PNAgent (or the XenApp Online Plug-in for those new to all this) with some flash animation and freedom as to what you add to your start menu.
Lets look at what Dazzle currently does, or doesn’t do:
- There is no single-sign on. You are prompted to re-enter your desktop credentials when you launch it. A real pain.
- It only gives you what you already have access to via your AD group memberships.
- It only provides access to XenApp/XenDesktop hosted applications or desktops. It doesn’t integrate with other distribution mechanisms (e.g. SCCM) to allow on-demand deployments of other applications (not all apps can be streamed after all)
- If you want something new, you’ve still got to make a call to the help desk, who then initiate whatever approval workflow is in place (outside of Dazzle)
At Synergy earlier this year, Citrix announced that the next version of Dazzle with have more workflow capabilities.
Dazzle v.next – the story so far
What have Citrix told us so far?
- Some kind of integration with Workflow Studio (is this just going to be adding/removing users to AD groups?). Hmm..does anyone actually use Workflow Studio?
- Managerial approval for application access requests
- Mac support
- Application searching
- FAQ support (hooking into your help desk knowledge base of application problems so users can find the answer themselves before calling?)
What should Dazzle offer?
Here is my “Dazzling” shopping list:
- Allow an administrator to define a list of available applications
- Define how a user gains access to them (all the time, by instant approval, by managerial approval)
- Provide reports on who has access to what, and who uses what (some kind of Edgesight integration for reporting?)
- Provide approval mechanisms via email and web
- Single sign-on
- Integrate with SCCM for on-demand deployment of MSIs and access to locally-installed applications in the same manner
What would you like to see in the next release of Dazzle? Comment away…
