Blog posts tagged with 'migration'

It's that time in the XenApp world again... Migration.  With the release of XenApp 5, many of you are contemplating a migration.  Why is migration such a big deal? I've heard numerous reasons like "It takes a long time to test my applications with the new XenApp (especially true if there is a new operating system involved)", "It takes a long time to rebuild my servers as I have to update my server build scripts" or "My current XenApp environment works fine, so why change it".

Those were all good points a few years ago.  But with the enhancements and optimizations made on XenServer for XenApp virtual machines, it is a great time to test server virtualization for XenApp to simplify migration.  And if we virtualize the XenApp servers, migration to XenApp 5, 6, 9, 11 or even XenApp 243 will be even easier (of course we will have changed the product name a few times. Let me hear a Hallelujah for HomerFrame or XenHomer).

But if we are going to migrate to XenApp 5, why not make the migration easier. Just how will XenServer make migration easier?  That is a great question, and I'm glad I asked it

Hardware
First, part of a new XenApp version means organizations will have to update their server builds.  Many of the server builds I've seen are complex scripts or require many manual changes once the build is complete.  Many times, there are multiple builds because of differences in the underlying hardware.  With XenServer , the links between the OS and the hardware are cut resulting in the ability to create a single build that can span multiple hardware variations.  How many fewer images will you now have to maintain?  Simplified

Optimization
With XenApp, you want to get the most users out of  your hardware.  This has been true with previous versions, is true with XenApp 5 and will be true in the future versions.  With a new OS and a new XenApp, do you have any idea how much hardware you need to support your users for the different application sets?  This is a challenge, especially when trying to design the new environment.  When you designate a server for a certain function, it is awfully hard to change the server's function, unless you virtualize.  With XenServer, you can make a virtual machine into anything you want.  You can move the running virtual machine to another physical server without the users ever knowing.  With XenServer and XenApp, you are no longer stuck in your static environment; instead, you are dynamically changing the environment based on the needs of the business. Simplified

Maintenance
How many of you like spending your days patching servers?  Not many.  Unfortunately, with each piece of software, there will undoubtedly be patches. With physical servers, you have to patch each server. With server virtualization, you still have to patch each virtual server.  But with XenServer Platinum, you only have to patch your base image, which is delivered to the virtual server via Provisioning Server.  If I have one XenApp image for SAP and another XenApp image for all of my other applications, I only have to patch both of those images.  Those images are then streamed to hundreds of physical or virtual servers.  Simplified

Evaluate
How could we do a migration without evaluating the apps and OS and XenApp configuration? This is critically important, especially if you are upgrading to a new OS like Windows Server 2008. With XenServer Platinum, the evaluation and testing phase is simplified.  How do you typically do this?  Well, you build the environment in a test lab.  You run test, modify, re-test. The cycle continues until a golden image is created.  That image must be used as a guide for rolling into production.  If you use scripts, you have to figure out how to script the build process to mimic your image.  If you use cloning solutions, you have to modify based on hardware.  If you use Provisioning Server, which is part of XenServer, you take your server, create a Provisioning Server image, and copy the image to production for delivery.  Simplified.   

Rollback
Let's say you upgraded without doing a proper test (shame on you).  As it turns out, one of the applications, which unlucky for you, is mission critical and is not working correctly.  What do you do?  Well, you have a few options:

• Try to troubleshoot and fix. You will be under the gun to get it fixed quickly as the business needs the application.
• Rebuild the physical server with the old setup. This will take a few hours for the build to complete and configure the applications.
  

Neither of those options sounds good to me.  Instead, if the environment was virtualized with XenServer Platinum, you would easily be able to change the version of XenApp delivered based on the Provisioning Server image you associated with each target device.  Simplified

XenServer for XenApp can simplify migrations by focusing on the areas of Hardware, Optimization, Maintenance, Evaluation and Rollback (This is what I like to call the HOMER Criteria).   It's a great way to get more done without working harder.  You get the migration done faster while providing a more dynamic environment for the business. 

Daniel

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.