Migration and Modernization Guide - Citrix Virtualization on Google Cloud

Overview

This guide was written for people with experience running and/or building a traditional, customer managed virtualization system based on Citrix Virtual Apps and Desktops technology. It is intended to help Citrix customers modernize their system to take advantage of the overwhelming benefits provided by Google Cloud and Citrix Cloud DaaS. It provides guidance on how to migrate a customer managed deployment of Citrix virtualization technology to Google Cloud and Citrix DaaS, dramatically simplifying and modernizing the system in the process. For many existing Citrix customers, migration is a journey, and many will run parallel systems for some time to facilitate migration with minimal disruption. These customers will likely implement something that resembles the Cloud Migration design pattern.

Migration and Modernization Strategy

Citrix customers of all shapes and sizes are moving to cloud-based infrastructure and services, often as part of digital transformation and/or IT modernization initiatives. Many of these organizations are turning to Google Cloud and Citrix’s cloud services. This shift is often driven by the need to do more than lift and shift everything to the cloud – they’re looking to transform their people and processes as well as their infrastructure. Citrix and Google provide products, services, and guidance which meet customers where they’re at on their digital transformation journey. They also support and even accelerate the transformation process across all ‘planes’ of technology in an organization: people, processes, and technology.

In the Google world, customer managed Citrix virtualization systems are often referred to as 'VDI', and the migration and modernization of such systems typically falls into their infrastructure modernization pillar. Google provides multiple different service offerings which can help customers migrate and modernize these 'VDI' workloads for Google Cloud, led by either Google, Citrix, or partner professional services organizations. These engagements typically follow a process flow which starts by assessing existing infrastructure, planning priorities and preparing foundations, migrating workloads in waves, and optimizing workloads and operations to get more value out of Google Cloud. Google also provides a couple toolsets which are often used in these engagements, including the StratoZone assessment, analysis, and planning tool, Google Migrate for Compute Engine, and VMware HCX for VMware Engine.

More information on the overall Google Cloud migration journey can be found in Migration to Google Cloud: Getting Started.

Migration and Modernization Process Overview

As you migrate and modernize your Citrix virtualization system and move it to Google Cloud, you’ll find that there are a number of different components or functions that you’ll be touching along the way. With each component or function, we’ll be moving from a customer managed layer to cloud managed services. Citrix and Google provide a variety of tools and services that are designed to dramatically simplify the process. At a glance, they are:

At the beginning of this process, most customers will likely be running their Citrix virtualized workloads, and the applications running inside of them, as virtual machines on top of self-managed compute, storage, and networking infrastructure. In most environments, these services are provided by a traditional hypervisor and management stack based upon VMware, Microsoft, Nutanix, or Citrix hypervisor platforms. Google provides a broad variety of different tools and services which can be used to host any application on Google Cloud. Citrix VDA’s – which run as virtual machines – can be run on either Google Cloud Compute Engine (GCE) or Google Cloud VMware Engine (GCVE).

The migration and modernization process can be broken down into three generalized phases and a couple parallel workstreams. These can be summarized as:

Phase 1: Migrate to Citrix Cloud services and prepare Google Cloud to receive workloads

• Workstream 1a – migrate virtualization infrastructure to Citrix Cloud services
• Workstream 1b - setup landing zone and enterprise networking on Google Cloud

Phase 2: Build Citrix Cloud resource location on Google Cloud

Phase 3: Migrate applications and workloads to Google Cloud

• Workstream 3a - migrate app infrastructure to Google Cloud
• Workstream 3b - port VDA images to Google Cloud

In the sections below, we're going to outline these phases/workstreams, and provide some pointers to external material that will provide additional details. That said - we'll most likely miss something that's important to you. We'd appreciate the opportunity to learn from your feedback! What did we miss? What can we do better? Please start the conversation with an email to our Citrix on Google SME working group. Thank you in advance for allowing us to be part of your journey!

Phase 1: Migrate to Citrix Cloud services and prepare Google Cloud to receive workloads

The first phase includes two workstreams, and these workstreams can be run in parallel. They are:

• Workstream 1a – migrate virtualization infrastructure to Citrix Cloud services. This process is outlined in Deployment Guide: Migrating Citrix Virtual Apps and Desktops from on-premises to Citrix Cloud. This deployment guide will help the reader migrate from a typical customer managed, on-premises deployment architecture to an architecture serviced by Citrix Cloud services. See example before and after diagrams below:

• Workstream 1b - setup landing zone and enterprise networking on Google Cloud. This includes extending active directory services into Google Cloud.

One of the foundational design/build activities Google will guide customers through is setting up the 'shell' of the customer's infrastructure on Google Cloud, often described as a landing zone. A landing zone provides you with a place to 'land' workloads on Google Cloud, and consists of at least one Google Cloud Project and basic networking services. While creating a basic landing zone and setting up a functional network on Google Cloud is simple, Enterprise requirements often force more complicated configurations. You can setup a basic landing zone on Google Cloud by completing the first 5 steps detailed in the Getting Started guide, but for more complex scenarios you've got a bit more work to do. For insights into how to create a landing zone for Enterprise environments, you can start with the links below or contact your Google Cloud Customer Engineer for more targeted guidance.

Phase 2: Build Citrix Cloud resource location on Google Cloud

This phase will leverage the Citrix Cloud services plus the landing zone and networking established in phase 1 to create a Citrix Cloud resource location on Google Cloud. This includes preparing a Google Cloud project and creating an IAM service account for hosting VDA’s on Google Cloud, installing Cloud Connectors, and defining the hosting connection and resources used for VDA provisioning and fleet management. Detailed instructions on how to build a resource location on Google Cloud can be found in the Getting Started with Citrix DaaS on Google Cloud Deployment Guide.

The Getting Started POC Guide details 8 steps that need to be completed in order to have a functional Citrix Cloud Resource Location on Google Cloud Compute Engine(GCE). The details of the steps will differ if the resource location will be deployed on Google Cloud VMware Engine (GCVE) but the outcomes are the same. If you're migrating an existing, customer managed control plane to GCE, you'll essentially be completing steps 1-5 below as part of Workstream 1b outlined above. The full 8 steps detailed in the Getting Started Guide are:

• Step 1: Setup a Google Cloud Project
• Step 2: Configure Network Services
• Step 3: Create Virtual Machines
• Step 4: Configure Access to VM Consoles
• Step 5: Deploy Active Directory
• Step 6: Initialize the Citrix Cloud Resource Location
• Step 7: Configure Citrix DaaS
• Step 8: Validate the Configuration

Once you've got a functional Citrix Cloud resource location running on Google Cloud, you can focus on completing the third phase of migration which we'll describe for you below.

Phase 3: Migrate applications and workloads to Google Cloud

This phase also includes a couple different workstreams which can run in parallel. In a Citrix virtualization environment, the 'workload' is often considered the VDA as the VDA is where the UI for a given application is executed. Most applications, however, require additional infrastructure to run. This could be as simple as a file share where documents and data are stored, as complicated as the first and second tier of a client/server application, or anywhere in between.

One long standing leading practice in the Citrix virtualization world is to place your VDA's (where the application(s) run) as close as you can to the infrastructure the application is running on. While this isn't always strictly necessary, it often goes a long way towards optimizing the performance of the application(s) in question. We break this phase down into two separate workstreams because the tooling to migrate the 'applications' often differs from the tooling used to migrate the 'workloads'.

The first workstream we've called "Workstream 3a - migrate app infrastructure to Google Cloud". This workstream could be relatively simple or quite involved depending upon the complexity of your environment. To complete this workstream, you'll need to have identified the components and dependencies of the application and supporting infrastructure. You'll also need to know what your target IaaS service will be on Google Cloud (Compute Engine or VMware Engine), and have prepared either/both to receive workloads. With this information in hand, you can then begin utilizing the migration tools available to move the app and supporting infrastructure to your target IaaS service. You can begin your learning journey on how to use these tools at the links below.

The second workstream we've called Workstream 3b - port VDA images to Google Cloud. For most customers, a lot of work goes into creating and maintaining their 'golden' images, which are essentially the source from which their various VDA estates are cloned and maintained. These images often end up being bespoke (to each catalog of VDA's running the same application stack) and very customized for a specific environment. These golden images are often relatively complex as they include an operating system, patches and updates, supporting software and management or reporting agents, application binaries, helper applications, and more. They also change over time as the components of the stack evolve and change.

Some customers build and update these golden images by hand, utilizing nothing more than a simple change log and manual change management process. Other customers invest in automation and tooling to create and manage their golden images, ultimately reducing the manual efforts required and decreasing the chance for inconsistencies and errors to develop. Some customers also incorporate Citrix's AppLayering technology into their golden image management process. Regardless, most will leverage one of Citrix's provisioning and image management tools (MCS or PVS) to deploy and update their VDA fleet.

In general, the more you've already invested in automation and tooling, the more options you'll have for completing this workstream because you've likely already prepared to handle changes in underlying compute platform. For a glimpse of what's possible with modern automation tooling for Windows, check out the work of Citrix Technology Professional Trond Eirik Haavarstein and his Automation Framework.

The tooling and technique recommendations we provide here will differ depending upon your source compute environment, your target compute environment (GCE or GCVE), and how much you've invested in automating your image builds and updates. They'll also be influenced by your desire to modernize the workload (by say updating the operating system to a new version). We'll outline some of the available tools and techniques for porting your golden VDA images to Google Cloud below.

Citrix Image Portability Service

Citrix has invested heavily in creating a modern web service capable of porting VDA images from various source compute environments to various target environments including Google Compute Engine (GCE). They call this the Image Portability Service, and as of the time of writing it is in Tech Preview. It's designed to work in concert with other Citrix services and tooling (such as the Citrix Automated Configuration tool) to allow customers to integrate golden image management into their preferred developer workflows. It currently works with source golden images used by PVS or MCS running on VMware, and outputs an image that can be used by MCS on Google Compute Engine. It is aware of many of the unique requirements for an image to be used by Citrix virtualization (such as ListOfDDCs for the Citrix VDA, machine identity, KMS/Office re-arming, etc.) and handles them appropriately for you. Refer to the documentation link provided for more information.

Google Migrate for Compute Engine

As we introduced earlier Google Migrate for Compute Engine is a powerful tool customers leverage to migrate virtual machines to GCE in bulk. Google Migrate could potentially be used to facilitate a one-time migration of your golden image virtual machines from a source compute platform to GCE. Once on GCE, it should be able to be used as the golden image instance for MCS on GCE, though this process has not been tested by Citrix Engineering as of the time of this writing.

VMware HCX for VMware Engine

For customers who choose to deploy their workloads on Google Cloud using the VMware Engine service (GCVE) as the compute environment, Google offers VMware HCX for VMware Engine to help migrate their workloads. HCX could potentially be used to facilitate a one-time migration of your golden image virtual machines from your on-premises VMware environment into GCVE. Once on GCVE, it should be able to be used as the golden image instance for MCS on GCVE, though this process has not been tested by Citrix Engineering as of the time of this writing.