Blog posts tagged with 'architecture'
I spent most of the week before last at Synergy in Houston, co-presenting a breakout session on XenDesktop architecture, and in a number of customer and partner meetings. Most of the time, however, I demo-ed XenDesktop to the public in the technology lab - or at least, that was the plan.
In reality, a lot of the time I actually ended up using pen and paper to sketch out XenDesktop, and how the various components that make up this product work together to deliver an end-to-end desktop virtualization story. Once the basic ideas behind XenDesktop got across, it was a lot easier to walk through the UI and demo the product. The other Citrites at the XenDesktop booths had exactly the same experience of typically setting up the scene before delving into details.
So I thought I'd try recording what I did in Houston as a little video - it's a bit rough round the edges, and it doesn't cover the full gamut of what XenDesktop can do (it doesn't talk about how you can assign individual virtual desktops to users, for instance), but it'll help explain some of the principles and ideas behind XenDesktop, and perhaps also shows where and how it differs from other VDI solutions.
PS: Sorry for my handwriting - it's never been very good...
PPS: XenDesktop (including the free Express edition) is now available for download from mycitrix.com
In my last post, I talked about our plans of moving XenApp farm settings, server settings and session policies into Group Policy Objects. This time, I want to describe our plans on a related topic: how to migrate XenApp 4.x farms into this new management model.
XenApp 4.5 Administrators have two options to migrate their farms: either upgrade the existing farm over time, running the farm in mixed-mode; or create a new farm and move users and applications over time.
The mixed-farm approach seems to be the easier of the two, but it has an important drawback: the migration cannot be staged. The recommended first step is to upgrade the Zone Data Collectors, which in turn affects all users and applications in the farm. If anything wrong happens - which is usually detected once users start to login and use their applications - there is no way to rollback without creating a farm outage.
The new farm approach is safer, as it allows Administrators to perform an "in-production" validation, migrating users and applications to the new version over time. The old production farm is not touched, which allows quick rollback of users to the previous farm if anything wrong is detected.
However, creating a new farm from scratch is not realistic in many environments. The reasons:
- Farm configuration documents may not exist, or be out-dated.
- Not sufficient hardware to maintain both farms in parallel. Servers have to move from one farm to other over time.
- The migration is not transparent to end-users. If a single Web Interface is used, it will list applications as "Application (Old Farm)" and "Application (New Farm)". If a separated WI is used, then users must configure browser and PNA to use another URL.
We do not plan to support mixed-farm migrations when we move XenApp configuration to Group Policy. Instead, we will focus on the issues above, creating the necessary tools to facilitate the transfer of configurations, users and servers from farm to farm.
This is the plan:
The first step is to create a new farm, installing a new Data Collector and creating a new IMA database. Infrastructure servers (License, Database, Edgesight, etc) may be shared between the old and new farm. The next step is to launch the Migration Wizard and go through the following steps:
- The migration tool wizard will ask information about the old farm (address, authentication). You may chose to export all the old farm data into an XML file and modify it before importing the data in the next steps.
- The wizard will ask the new farm information. It will then convert session policies, farm and server settings into Group Policies, and automatically associate GPOs with the new farm Organizational Units.
- If the old farm contained multiple application silos, the wizard will ask for a server that represents the old farm silo, and create a Group Policy Object containing that server configuration. The wizard will then associate that GPO with the OU representing the Application Silo in the new farm configuration.
- You will be able to select a list of "in-production" test users. The new farm will only enumerate applications to users in that filter list, regardless of the Application object configuration.
- Add the new farm in your Web Interface sites. Web Interface will suppress enumeration of applications coming from multiple farms, based on configuration. This change will make the migration process completely transparent to end users.
At this point, you will have a fully configured, although empty new farm. Over time, you will:
- Add more users to the new farm filter
- Remove servers from the old farm
- Upgrade XenApp software in the server (or re-image)
- Assign the server to the new farm Organizational Unit.
This method is very flexible, you may stage the process based on application silos, zones, users, or any combination of these. The migration tools provided here are also very useful for other use-cases, such as replication of settings between test and production environments.
This plan is still on the drawing board, please feel free to comment and raise scenarios where you believe it wouldn't meet your needs. Note that this is planned for the next major release after project Delaware, therefore still a long way in the future.
It's been a long long time since my last post, and much has happened since then in the desktop virtualization space, both for Citrix and in the wider industry. At the time of my last posting (December 2006, no less!) we were seeing the first attempts to virtualize Windows-based desktops, using home-grown and relatively simple "brokers". Typically, they would use straight-forward one-to-one mappings between end users and their virtual desktop, perhaps based on the user's login identity and their virtual desktop's IP address.
Since then, we have made great strides to deliver more sophisticated solutions for desktop virtualization, and a first batch of products have been released from vendors such as VMware (VDM, courtesy of their acquisition of Propero), Quest (via ProvisionNetworks), Leostream, and others (there's a good overview available from it2.0). And of course we delivered Desktop Server 1.0 last year, and have now just made a beta version of XenDesktop 2.0 available for download.
A great deal has happened here beyond the obvious name change, and our vision for this product has undergone major shifts over the past year or so. I'd like to use this post to bring you up to speed on how XenDesktop differs from Desktop Server and also many of the other desktop virtualization products.
First and foremost, while Desktop Server 1.0 was a broker that mapped end users to virtual desktops, XenDesktop provides a much more comprehensive approach to delivering desktops. A broker by itself is all very well. It allows you to migrate desktops into the data center, with all the benefits this brings in terms of preventing data loss (remember all those news stories about stolen laptops and hard drives and optical discs getting lost in the post?), reducing downtime, and gaining visibility and manageability - provided you have appropriate tools and processes in place to manage the sprawl of what will typically be VMs that host your virtual desktops.
Of course a desktop virtualization strategy can also introduce new headaches. For instance, you need to think hard about what moving your end users' desktops into the data center means for the security of other assets in the data center - you'll probably want to consider a strategy that fences off virtual desktops from other services and data hosted in the data center. More than that, though, moving desktops into the data center by itself doesn't solve some of the big management problems - you still need to worry about image management, patches, anti-virus, and on top of that you have to keep an eye on the health of the desktop virtualization infrastructure, whether this be XenServer, VMware, blade PCs, or other desktop hosting technologies. Finally, all the images for your virtual desktops need to be stored somewhere, and with multi-GB disk images, this quickly adds up to a substantial storage cost.
XenDesktop includes technology that will help you to tackle these complications, and help you get a long way towards reaping the promised benefits of desktop virtualization (well, that's my sincere hope anyway). Here's how we envisage a successful desktop virtualization strategy to play out:
- Lock down your end user's endpoint devices, or better yet, replace them by Desktop Appliances (the new term for thin clients that are specifically designed to take advantage of desktop virtualization). This minimizes the maintenance overhead and reduces the risk of end users misconfiguring or otherwise breaking their devices. We've designed XenDesktop's end-user UI so that this step becomes as painless as possible for end users: after switching on their device, end users enter their credentials and XenDesktop takes over, connecting them straight to their virtual desktop. Depending on your deployment, this uses a combination of Web Interface and Program Neighborhood Agent technology under the covers, but this is entirely transparent to end users.
- Take advantage of the migration to centrally hosted desktops and consolidate and rationalize the OS images for your end users. Ideally, you should end up with a small number of "golden images" that contain only the base operating system, as well as perhaps a few universal applications that all your users need, e.g. a standard browser or email client. The idea here is to separate the base OS from applications and user data, and hence make it an entity that can be maintained and managed independently and separately, and hence more effectively. Citrix Provisioning Server (also known as PVS - you may be familiar with it under its previous label of "Ardence") provides the required technology here, and is conveniently included in XenDesktop.
- PVS is used to create and store golden images, which are then shared among VMs, or even blade PCs. In other words, if you have 100 users all using the same base OS, you only need to store the image on disk once and PVS will stream it to the VMs hosting your virtual desktops, on demand. The VMs (or blade PCs) themselves can be entirely diskless, and this can add up to a tremendous saving in storage cost. What's more, PVS makes managing golden images is made a lot easier as well: if you need to patch your base OS with the latest service pack, you only do this to the golden image. Restarting the VMs suffices to apply the new image across the board. And if the service pack update goes wrong - no problem, it's trivial to switch back to the previous version of the image. PVS and XenDesktop will also automate the management of AD computer accounts, hence there's no need for sysprep or other tools, and adding a new virtual desktop is done in seconds: create a new diskless VM, add it to PVS' client list, and let PVS manage the new desktop's AD account.
- So now you have a very manageable environment that you can use to deliver generic desktops based on golden OS images to your end users. But your end users will need applications to carry out their daily work (remember, don't include too many apps into the base OS image, because then you need to manipulate that image every time you need to change or update one of these apps). This is where application streaming or "client side virtualization" comes into play; I've briefly touched upon this in my previous post: using XenApp technology, you can deliver applications transparently to your end users, without having to touch or "pollute" the golden image. This allows you to get away with a small number of golden images, even if your users have differing needs with respect to the applications they access: just let XenApp (or alternative technologies) deliver applications to users based on demand.
- Finally, users also need to store data and configuration or personalization settings. Again, these must be separated from the base OS and also the applications, in order to make the entire system manageable and effective. Right now, you'll have to use off-the-shelf solutions like Windows roaming profiles to store and manage data and settings separately, but naturally we recognize this as a gap and are working towards offering a solution that's integrated with XenDesktop in the not too distant future.
To recap, XenDesktop has evolved significantly from a broker into a fully fledged desktop virtualization solution that combines a broker, ICA's high-performance remoting protocol (courtesy of PortICA), virtualization infrastructure (and before you ask: yes, XenDesktop works well with a VMware and Microsoft virtualization infrastructure as well, although of course we'd prefer you to use the XenServer technology that's included in XenDesktop), image management and OS streaming, a set-up tool for wizard-driven provisioning of diskless VMs with OS streaming, and more. If you want to dig deeper, check out the official XenDesktop product site where you can also download the beta, and join the discussion forums for support.
For my next post I'm planning to go a bit more technical and describe one of the areas that has generated many questions for the beta: how XenDesktop works with AD.
Hello, this is my first post in this community, so let me start with a brief introduction: my name is Juliano Maldaner, a product architect on the Presentation Server team. One of the areas I'm working on is the simplification of Presentation Server management experience for upcoming releases. We're introducing some exciting new concepts and would like to hear your feedback!
Managing a Presentation Server farm requires much more than configuring Presentation Server components: Operating System and Application settings are as important. A successful environment must maintain PS, Operating System, and Application settings correctly configured and consistent across all servers in the farm. Maintaining this consistency throughout the farm life cycle is one of the major challenges for PS Administrators.
The Windows platform provides an outstanding tool to address these configuration management challenges: Active Directory and Group Policy. An overwhelming majority of PS deployments use Group Policy in some capacity. Integrating PS settings into GPO is possible with MFCOM scripts, but far from ideal. Most use GPO for Windows and Application settings, and Citrix management consoles for PS configuration. Because all settings must be synchronized, we realized that the management experience would be greatly simplified if PS Session Policies and Server settings were within Group Policy Objects themselves!
Presentation Server settings/policies embedded into Group Policy Editor
The main benefit of this integration is the creation a single management template for platform, applications and Citrix configuration. All operations performed with Group Policy Management Console will include Presentation Server parameters as well. Resulting Set of Policy reports will show all Citrix and platform configuration - a great help for troubleshooting and planning. Backup, Restore, and Migration will allow saving and moving configurations from farm to farm, making replication of environments much easier than what it is today.
Another key benefit is the separation of PS settings and servers. Group Policy Objects are associated with Organization Units, and not with individual servers or users. Common management operations - adding capacity to a silo; repurposing a server; or replacing a broken server - are greatly simplified: simply change the server OU membership, and the settings associated with that silo will automatically apply to the server.
Application Publishing
The Group Policy integration will NOT require Active Directory schema changes. For this reason, PS objects such as Applications and Administrators will continue to be managed via Citrix management consoles. Application Publishing will be modified to allow association of Applications with Active Directory Server Groups and Organization Units. This way, apps will be automatically published as soon as the server is assigned to the correct Organizational Unit.
Policy Filters
Presentation Server Group Policy extension will improve GPO filtering capabilities to include all filters existing on CPS 4.5 session policies - including SmartAccess. These filters will only apply to the Citrix part of the GPO, platform configuration will apply regardless of the filter result.
The Citrix policies within GPOs will also allow filtering on a per-setting level - native Group Policy only allow filtering per-policy level. Some Presentation Server features require complex filtered settings, for example: proximity printing based on client IP address. This feature will allow the configuration of such policies within a single GPO.
What about environments without Group Policy?
There are some important scenarios where Group Policies cannot be used:
- Environments using other Directory services;
- Applications that require anonymous (local) accounts;
- Organizations that restrict or deny AD delegation to PS administrators.
To support these environments, IMA will provide a global Group Policy Object, applied to all servers in the farm. This farm-wide GPO replicates the existing Farm Default settings. Per-server override is possible by configuring the server's Local Group Policy Object.
Our goal is to maintain feature parity with PS 4.5 if Group Policy is not used. However, the Administrator's experience will be optimized for Active Directory and GPO scenarios.
Active Directory and Group Policy are fundamental for a successful Presentation Server environment. Group Policy integration will bring major improvements to management experience, leveraging existing IT infrastructure and knowledge. The feedback we've received so far has been very positive, please let us know what you think!
In a previous article, I claimed that DDI (the Dynamic Desktop Initiative) is Citrix' version of VDI (Virtual Desktop Infrastructure). A few people have rightly pointed out that this is not entirely true, and I want to spend a few moments to clarify how the DDI vision differs from VDI. I hope that this will also explain the relationship between Trinity and few forms of that are currently in circulation.
The major difference between DDI and VDI should be clear from the choice of terms and acronyms: while virtualization clearly plays a big role in VDI, the more generic term is used DDI. This highlights that we envisage Trinity to be a generic desktop brokering solution that is not intimately tied to a particular virtualization solution to deliver desktops as virtual machines. More specifically, VDI is of course a VMware term, hence in a strict sense a VDI solution would require desktops to execute on top of VMware Virtual Infrastructure. However, it is straightforward to generalise the concept other virtualization vendors such as Microsoft or XenSource.
Back in Trinity land however, there is no dependency on VMware or any other virtualization vendor. Instead, Trinity operates on desktops, or workstations as we prefer to call them, regardless of the underlying execution environment. Hence Trinity can just as well broker access to a rack of physical blade machines hosted in the data center, each running its own copy of the OS, or even to the PC under your desk, should the Trinity administrator decide to make it available through the broker. (If you thinking that this strays into GoToMyPC territory then you are not far off, although of course Trinity is an in-house deployment and not a service offering like the GoTo family of products.) Lastly, Trinity also offers access to a published server desktop using traditional CPS functionality as explained in my previous post. We are currently working on the right terminology to differentiate these types of desktops, and to highlight their differences in terms of and typical use cases; once this has settled down a bit, I share it on this site.
So, to come back to virtualization, and its relationship to Trinity; maybe it is best to approach this by differentiating the various types of virtualization. Unfortunately, there seem to be nearly as many definitions of virtualization around as there are vendors in the space. I try to stick to the Citrix view of virtualization here:
- Application virtualization is our term for the type of remote access offered through CPS and similar solutions (confusingly, I have also seen this referred to as desktop virtualization). Trinity complements this type of virtualization nicely: while Trinity can broker access to, and deliver a desktop, the apps that you run on the desktop may very well be delivered as virtualized applications from a remote server. Consider a typical Citrix-internal use case scenario: enterprise applications such as SAP and tools for tracking product defects are delivered through our in-house CPS farms. There is no reason why you cannot do exactly the same thing if your primary desktop has been delivered through Trinity. In fact, we are starting to investigate how we can improve the performance of virtualized application delivery in this ICA double-hop or pass-through environment.
- I have also heard application streaming - as per Citrix Tarpon or Microsoft SoftGrid - referred to as application virtualization. Regardless of terminology, again there is a fit with Trinity, since application streaming can be the perfect method for delivering applications to a desktop brokered through Trinity. Especially in an environment where desktops run as VM images, streaming applications makes image management a lot less complicated. There was a good example of application streaming used in a customer case study at VMworld 2006 -look out for the slides and podcast of session MED0062.
- Machine virtualization is the technology VMware, Microsoft, XenSource, and others use that makes physical machine resources available to multiple virtual machines. It can provide the infrastructure upon which you build a Trinity solution. Running the brokered desktops as VMs has cost and management advantages over using physical machines (that being the VDI pitch), but machine virtualization can also be used to optimize the Trinity server infrastructure. Just like we see a number of customers run CPS and other Citrix servers in virtual machines, I would expect the same to happen for Trinity servers.
So there you have it: while Trinity doesn't depend on a particular virtualization technology or platform, it can integrate and take advantage of in several flavours of virtualization. And while Trinity is thus virtualization-agnostic, we would expect that the majority of non-server desktops brokered through Trinity will be running as VMs, for the aforementioned cost and manageability reasons. As for the Trinity team, this means that we will strive to provide the required integration between Trinity and popular virtualization platforms to ensure that you can manage both the brokering and machine virtualization aspects of a Trinity deployment smoothly and efficiently.
Finally, a brief update on what's been happening in the team: we are now busy designing and prototyping the major building blocks for the second Trinity release targeted for late next year. We are taking advantage of some the newer technologies such as WCF, to reduce the time spent prototyping, and in a recent demo I have seen the first direct ICA connection to Windows XP running within a VM. In reality, this was missing a lot of the required server-side infrastructure, but it was a cool demo and by the way, in case you missed it: Citrix has just bought Ardence (Brian Madden has a good overview of their technology and some of its benefits in a CPS environment - and as you would expect he has already posted his analysis of this announcment). Now we can start planning in more detail how this will play with our Trinity designs. More on this, I hope, after the Christmas break.
Note: I hand-edited this post since it seems to have been badly garbled during the transition to our new blogging platform. I haven't materially altered its content though (although some parts of it are now a bit out of date).
If you have followed recent Citrix announcements and a number of blogs and other postings, you probably already know that we are working on a product line in the Desktop Infrastructure (VDI) space, codenamed Trinity (by the way, Dynamic Desktop Initiative or DDI, is Citrix name for VDI). As the product architect assigned to Trinity, I intend to post here occasionally to keep you up to date on our plans and progress. As always with this type of blog, please note that much of this information is about work in progress, and I certainly cannot commit to dates or promise that certain features will make it into a final product.
With that out of the way, I would like to devote this first post to a brief overview of where and how Trinity originated, and then talk about the first couple of deliverables in the Trinity product line. Some topics I had in mind for future postings include thoughts and impressions from VMworld 2006, which I attended last month, my view on where we are as an industry with VDI, and a more detailed dissection of the various types of virtualization that are part of, or relate to Trinity. Do let me know if there are any topics you are particularly interested in, and I will try to cover them if I can.
Trinity did not just start out of the blue recently at Citrix; in some form or fashion, its roots reach all the way back to 2003, when product idea #408, on demand access to desktops was submitted. In fact it is quite likely that ideas in this area had been floating around well before that submission. The gist of that product idea pretty much covers what subsequently became known as VDI. Oh, and by the way, we are up to product idea #2098 in the meantime.
In any case, some initial investigation efforts were kicked off in our Products group, and I remember a presentation that Richard Mazzaferri and Anatoliy Panasyuk gave to the UK engineering team, outlining the concepts of brokered access to virtual desktops. This sparked quite a few I like one of them, please comments from our development team.
I do not have much visibility on what happened subsequently, except that there was never really any resource available to work on it in more detail, until things started to bubble up again early this year, which was also when Trinity was coined as a project name. After a more detailed architecture and design had been worked out, there was a bit of to-and-from between the various engineering sites in Citrix, until eventually we ended up with engineering resource being provided in both the Sydney and the Chalfont sites.
Now to complicate matters a bit, there is a second strand to the Trinity lineage, which has also been going for some time, originating from the project Dart (which was never released but influenced a number of other Citrix products such as Access Essentials, or the Access Management Console but I digress). After several iterations, this culminated in the Remote Desktop Broker (RDB) for Presentation Server, which was released earlier this year as the first Citrix DDI deliverable. You can read all about RDB in a FAQ on the Citrix web site, but in a nutshell it allows you to publish an RDP proxy component on a Presentation Server, which will route the connecting user to their virtual desktop based on a configuration of virtual desktop pools that an administrator controls through a management GUI.
All this begs the question, how all these things fit together, and what we are planning for the next couple of Trinity releases. Assuming that you have a basic understanding of Remote Desktop Broker, this can be summarized as:
We target a first release of Trinity for the first half of next year, based on Remote Desktop Broker that you have already seen. It will build on the existing combination of CPS + RDB but re-engineered to deliver an integrated product and improve the administrative experience by delivering consistent access to both shared and dedicated desktops. Maybe a word about nomenclature here: shared desktops are what you are already used to from CPS published desktop feature, while dedicated desktops are single-user OSes, whether they run on physical hardware or as a virtual machine image. Terminology hasn't been finalized yet, though. We are also working on a simpler licensing scheme for this release of Trinity, but details are still being finalized.
In the meantime, we are working on the second release, which is currently slated for release in the second half of next year. This is when we will integrate PortICA, and thus deliver the benefits of ICA that can get lost in RDB double-hop solution. While the ICA stack for dedicated desktops will certainly be big news for this release, we are also planning to take advantage of the server-side infrastructure that we built for Presentation Server to bring you an integrated, seamless experience for both administrators and end users. Our goal is to make it as simple as possible for end users to access their desktop, building upon the existing application delivery infrastructure, i.e. Web Interface, PNAgent and the like. On the other hand, administrators will be able to benefit from the same tools and features that they are used to from Presentation Server.
So much for the marketing piece - I'll flesh out our current plans for the second Trinity release in a bit more technical detail in a future post, but until then I be interested to hear your views on Trinity, VDI, DDI, RDB, or any other three-letter acronym.
Note: I hand-edited this post since it seems to have been badly garbled during the transition to our new blogging platform. I haven't materially altered its content though (although some parts of it are now a bit out of date).
-
Subscriptions
