Post to Twitter |
Comments (5) |
Views (19082) |
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.
Comments (5)
Mar 27, 2008
Shawn Bass says:
Juliano, This approach sounds very solid to me. I also think this "Migrat...Juliano,
This approach sounds very solid to me. I also think this "Migration Wizard" is something that should have existed 7 years ago for straight up MFCOM based farm migrations. But I digress.
Overall the strategy sounds great and I'll be looking forward to getting the beta bits whenever they are ready.
Shawn
Mar 29, 2008
Anonymous says:
I don't like this approach at all. It overly complicates installing a new versi...I don't like this approach at all.
It overly complicates installing a new version of Citrix Presentation Server and adds a lot of 'necessary' extra settings to an already pretty fragile product (XenApp) - those necessary settings (eg: WI filters, going through the migration wizard, automatically creating OU's etc) are not necessary at all in the current situation.
It's fine if you introduce these features and make them optional, but overly complicating mandatory configuration of simple CPS farms solely because of software design choices is something not to be expected from a commercial vendor imho.
Apr 04, 2008
Juliano Maldaner says:
The migration process above was described with a large farm in mind - multiple s...The migration process above was described with a large farm in mind - multiple sites and application silos. For these farms, the new migration process is certainly an improvement. As I mentioned, the recommended approach is to create a new farm anyway, and the migration tools will only help.
For smaller farms, you are correct: there are more steps to perform the migration. However, if the farm is small enough that the whole migration can be performed in a single farm outage, then migration can be simplified further:
- Run the migration wizard on the old farm, and export the configuration to XML files.
- Uninstall/re-install XenApp in all servers.
- Run the migration wizard and select to import the previous farm XML configuration.
The last step will take care of Group Policies Objects as well, although you have an option to use the IMA group policy and each server Local Group Policy instead.
Again, I'm not debating the process for small farms is simpler than the mixed-farm migration. It is not. But keep in mind that the release where Group Policy is introduced is an exception. Migration to subsequent releases is simplified due to the flexible nature of Group Policies.
Apr 05, 2008
Anonymous says:
I truely do not see how having to create a new farm and having all the extra swi...I truely do not see how having to create a new farm and having all the extra switches is an improvement over simply upgrading an CPS in-place or by simply re-imaging or deploying new CPS versions on existing servers in the CPS farm.
I understand Citrix' desire to be able to do away with legacy code and development, but at the same time this should not complicate the administrator's life - there are more of us admins, then there are of developers
I would suggest introducing the best of both worlds - keep the possibility to perform inplace upgrades of Citrix, but on the first version to be upgraded, automatically run the wizard doing all the heavy lifting automatically for you.
Then you have to solve the little problem of the CPS 4.5 farm and the 'newer' CPS farm getting out of sync because of different configuration sources, but i'm sure you can think of something for that (eg - blocking the editting of settings using CPS 4.5 servers by issueing an required hotfix for CPS 4.5 and below)
By the way - can you define small and large farms by numbers?
Jun 03, 2008
Juliano Maldaner says:
The definition of small or large, from a migration standpoint, is how long the f...The definition of small or large, from a migration standpoint, is how long the farm has to run in mixed state. A small farm can be upgraded in a single maintenance window, while large farms cannot. There aren't absolute numbers, it depends on the farm complexity as well as the IT organization size.
Keeping data in-synch will be easy in this timeframe, once we integrate with Group Policies. A single GPO can be assigned to multiple farms, through the Organizational Unit structure.
The intent of this new migration strategy is not to simplify XenApp engineering, but to align the migration strategy with best-practices recommendations. Mixed-farm migration is not recommended, for the reasons I mentioned above. This new method does require more steps, but I disagree it is more complex. At the end, it is a simple export/import operation. A wizard will make the process simple for new admins, and Powershell will make it scriptable for seasoned admins.
Add Comment