Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate

Transcription

1 White Paper PlateSpin Transformation Manager PlateSpin Migrate Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Updated for PlateSpin Transformation Manager 1.0 and PlateSpin Migrate 12.1

2 Table of Contents Introduction to Workload Migrations... 1 Minimum Prerequisites... 2 Cloud Resource Planning and Resource Group Management... 4 Creating an Azure Application to Represent PlateSpin Migrate... 6 Configuring a User for PlateSpin Migrate to Use Enabling Azure Subscriptions for Deployment of the PlateSpin Migrate Replication Environment Adding a Microsoft Azure Location as a Migration Target Configuring and Executing Workload Migrations Additional Resources page

3 Introduction to Workload Migrations In today s dynamic world, the need for cost reduction and the desire to increase operational efficiency have a constant impact on the organization of IT resources. Enterprises are relentlessly looking for better ways to manage infrastructure, systems and applications and this often leads to the execution of projects where large numbers of workloads are moved from one platform or data center to another. Typical examples include the migration of physical servers onto a virtual platform, the migration of virtual machines from one virtual platform to another, traditional data center consolidations, and the migration of on-premise workloads into a managed or public cloud, like Microsoft Azure. This White Paper contains best practices for migrating large amounts of Microsoft Windows 2008 and 2012 workloads into the Microsoft Azure Cloud with PlateSpin Migrate from NetIQ. PlateSpin Migrate is a powerful workload portability solution that automates the process of moving workloads over the network between physical servers, virtual hosts and enterprise cloud platforms all from a single point of control. It provides enterprises and service providers with a mature, proven solution for testing, migrating and rebalancing workloads across infrastructure boundaries. Some of the key features in PlateSpin Migrate are: Anywhere to anywhere workload migration capabilities. Horizontally scalable with up to 40 concurrently active migrations per single PlateSpin Migrate server. Minimal service downtime during final cutover. 1

4 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate PlateSpin Migrate is a powerful workload portability solution that automates the process of moving workloads over the network between physical servers, virtual hosts and enterprise cloud platforms all from a single point of control. Fig. 1 PlateSpin Migrate performs anywhere-to-anywhere migrations Minimum Prerequisites PlateSpin Migrate requires the use of Microsoft Azure s new Resource Management for migrating workloads into the Microsoft Azure cloud. Before you can migrate workloads into Microsoft Azure with PlateSpin Migrate, you need to set up your cloud environment correctly. This means you need to have, as a minimum, the following items: A Microsoft Azure Account (i.e., a username and password combination). A Subscription you want to bill to (one Account can have multiple Subscriptions). 2

5 For easy migrations, NetIQ recommends to enable a VPN between your on-premise networks and Microsoft Azure networks. A Client ID (the ID represents PlateSpin Migrate as an application that makes use of the Microsoft Azure API). An Azure Active Directory user created as a Contributor for the Subscription. A Virtual Network with a Subnet. There are certain requirements related to ports and routing that we will discuss below. The PlateSpin Migrate server is preferably installed on-premise, meaning at the same location where the source workloads reside. Information on how to install PlateSpin Migrate can be found on /documentation/platespin-migrate-12 (consult the Installation Guide and the User Guide). The minimum network-related prerequisites for a successful migration are: The source and the target workload need to be able to communicate with the PlateSpin Migrate server on port 443. The target workload is the replica of the source workload that will reside in Microsoft Azure. The PlateSpin Migrate server needs to be able to communicate with the Microsoft Azure API endpoint on port 443. The PlateSpin Migrate server needs to be able to communicate with the source workloads on the ports that are used for DCOM, WMI and RPC. The target workload needs to be able to reach the source workload on port 3725 (default). The direction of this connection can be reversed (source to target), and the port number is configurable. Consult the PlateSpin Migrate documentation for further details on how to change these default settings. For easy migrations, NetIQ recommends to enable a VPN between your on-premise networks and Microsoft Azure networks. Creation of the VPN can be accomplished by using the Azure PowerShell cmdlets. For complete instructions, consult Microsoft s documentation at azure.microsoft.com/en-us/documentation/articles/vpn-gateway-create-siteto-site-rm-powershell, or watch our YouTube video at: watch?v=cqqg6wkxrow 3

6 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Cloud Resource Planning and Resource Group Management Storage Resources in Microsoft Azure have some inherent limitations, which may require some up-front planning if large amounts of workloads are to be migrated into the cloud. Besides understanding these limitations, it is good to familiarize yourself with Microsoft Azure Resource Groups. Resource Groups are extremely important: every resource (CPU, RAM, disk space, IP address, etc.) needs to belong to a Resource Group. The main purpose of the Resource Group is to manage the life cycle of such resources, in function of a business service need. In essence, as long as the business service is needed, the resources are needed. Resource Groups allow you to manage resources from the perspective of the business service. If you want full control over your Storage Accounts, then you need to set them up prior to performing your migrations Storage Access in Microsoft Azure is represented by a Storage Account. When using PlateSpin Migrate to migrate workloads into Microsoft Azure, the Storage Account is referred to as the Datastore. When no Datastore is selected for a migration, PlateSpin Migrate will use (or create, for the first migration) a default Datastore (Storage Account). Like any other resource, the Storage Account must reside in a Resource Group, so when PlateSpin Migrate creates the Storage Account, it will also create a default Resource Group. The inherent Storage Account-related limitations in Microsoft Azure are: A single disk that s stored in a Storage Account has a maximum size of 1 TB (absolute limit). One Storage Account can contain up to 500 TB of data (default limit contact Microsoft for further details). One Subscription can contain up to 100 Storage Accounts (default limit contact Microsoft for further details). If you want full control over your Storage Accounts (i.e., you don t want to rely on defaults created by PlateSpin Migrate), then you need to set them up prior to performing your migrations, as illustrated on the following page (example names are used). 4

7 When performing a migration with PlateSpin Migrate, you will need to first select the Virtual Network, and then the Subnet where the workload needs to reside. Fig. 2 Managing Storage Accounts In Microsoft Azure A second type of resource that may require some planning are the Virtual Networks. As stated earlier in the section Minimal Requirements, at least one Virtual Network needs to be pre-created manually, before starting your migrations. This Virtual Network also needs to belong to a Resource Group, just like the Storage Account. Secondly, the Virtual Network needs to have at least one Subnet that s available for workload provisioning. When performing a migration with PlateSpin Migrate, you will need to first select the Virtual Network, and then the Subnet where the workload needs to reside. None of these resources are created automatically by PlateSpin Migrate, so they have to be set up manually, in advance, as illustrated on the following page (example names are used). 5

8 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Because PlateSpin Migrate makes use of Microsoft Azure s API to migrate workloads, it needs to be represented by an Azure Application, with a unique Client ID. Fig. 3 Managing Virtual Networks In Microsoft Azure Creating an Azure Application to Represent PlateSpin Migrate Because PlateSpin Migrate makes use of Microsoft Azure s API to migrate workloads, it needs to be represented by an Azure Application, with a unique Client ID. To create an Application, go to the Microsoft Azure portal ( and select the Active Directory link. In the Default Directory, select the Applications tab. Select Add and then Add an application my organization is developing. 6

9 Fig. 4 Select Active Directory To Start Generating A Client ID Fig. 5 Add An Application 7

10 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Enter an application name such as PlateSpin Migrate and select Native Client Application. Next, enter a valid URI for the Redirect URI. (Note: This URI will not be utilized by PlateSpin Migrate, but has to be syntactically correct). Fig. 6 Specify Application Type Fig. 7 Specify Redirect URI 8

11 Once created, click on the Configure tab for your new application, scroll down to the permissions to other applications section, and select the Add application button. Make sure that the Windows Azure Service Management API App is selected (a green check will be seen next to the name of the App). Then you need to select the Access Azure Service Management (preview) delegated permission. Once completed, make note of the Client ID on this page. This will be used when adding an Azure Location as a PlateSpin Migrate Target. Fig. 8 Go To The Configure Tab For Your New Application Fig. 9 Click The Add application Button 9

12 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Fig. 10 Make Sure Windows Azure Service Management API Is Selected Fig. 11 Select The Access Azure Service Management (preview) Delegated Permission Configuring a User for PlateSpin Migrate to Use To configure access to your Subscription, from the Microsoft Azure portal ( azure.com) once more select the Active Directory link. Select the Users tab, select Add User, fill out the user details and select the User Role. 10

13 Fig. 12 Add A User Fig. 13 Give The User The User Role In the next screen, click Create and make note of the temporary password shown, as you need to log out of the Microsoft Azure portal and re-login with this newly created user and temporary password. You will be prompted to create a new password at that point. 11

14 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Make note of this new password and your full user name. Both will be used when adding an Azure Location as a PlateSpin Migrate Target. Once this action is completed, log out and re-login to the Microsoft Azure portal as the Subscription Administrator. Select Subscriptions and select your Subscription. Click on the Access icon to bring up the Subscription users. Click Add, and select the Contributor role. Then select the user you created previously to represent PlateSpin Migrate, and click OK. Fig. 14 Select Subscriptions And Select Your Subscription Fig. 15 Go to Users 12

15 Fig. 16 Click Add, and select the Contributor role Fig. 17 Select Your User 13

16 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Enabling Azure Subscriptions for Deployment of the PlateSpin Migrate Replication Environment While replicating a workload to Microsoft Azure, PlateSpin Migrate has the future target workload booted from a temporary helper VM. This helper VM is called the PlateSpin Migrate Replication Environment. It is published free of charge in the Azure Marketplace, but is a required component for all migrations; for each subscription that will perform migrations to Microsoft Azure with PlateSpin Migrate, you must enable programmatic deployment of the helper VM. Once this enablement has been done, PlateSpin Migrate will transparently use the helper VM as needed, while performing migrations. Enabling Programmatic Deployment of the Replication Environment In the Microsoft Azure portal menu, click New in the upper left corner, and search for PlateSpin Migrate 12.1 Replication Environment using the search widget. Select the PlateSpin Migrate 12.1 Replication Environment once found. Fig. 18 Find the Replication Environment in the Microsoft Azure Marketplace 14

17 At the bottom of the PlateSpin Migrate Replication Environment detail screen, click the blue link called Want to deploy programmatically? Get started, to display the terms of use. Scroll down until you see Choose the subscriptions. Here, for each subscription that will perform migrations with PlateSpin Migrate, change its status from Disable to Enable. Then click Save. Fig. 19 Enable the subscriptions that will perform migrations with PlateSpin Migrate 15

18 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Adding a Microsoft Azure Location as a Migration Target In PlateSpin Migrate, a platform that you want to migrate workloads to is always referred to as a Target. To add a Microsoft Azure Location as a Target, click on Targets in the upper menu bar, click on Add Target, and provide the following information: Type (choose Microsoft Azure Location ) Subscription ID Client ID (this is the Client ID you noted down earlier when you created the Application) Username (this is the username of the user you created earlier for PlateSpin Migrate to use) Password (this is the new password you generated earlier for your PlateSpin Migrate user) Location Name (choose the desired Microsoft Azure Location) Click on Add to add the Location as a PlateSpin Migrate Target. This may take a minute. Note: you should only choose locations for which you have the vpn configured. Fig. 20 Adding A Microsoft Azure Location As A PlateSpin Migrate Target 16

19 PlateSpin Migrate has an intuitive and easy-to-use Web UI, which allows you to drive migrations with just a couple of clicks. Configuring and Executing Workload Migrations Once all prerequisites are fulfilled, and your cloud resources are set up correctly, and at least one Microsoft Azure Location is configured as a migration target, you can start migrating workloads. PlateSpin Migrate has an intuitive and easy-to-use Web UI, which allows you to drive migrations with just a couple of clicks. The migration process consists of three parts: discovery, configuration, and cutover. Discovery of Source Workloads Click on Workloads in the top menu bar, and click on Add Workload. To add (i.e. discover) a workload, you need to provide the following information: Hostname or IP. The IP address or resolvable hostname of the source workload. Type. Windows or Linux. Credentials. A username and password combination that has administrative privileges for the source workload. Once all information is provided, click on Add Workload, and wait until the workload shows up as Not Configured in the Workloads list. The workload is now fully discovered. 17

20 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Fig. 21 Adding A Workload To PlateSpin Migrate Fig. 22 Discovered Workload In The Workloads List 18

21 If you will manually kick off the migration after its configuration, no schedule needs to be set up. Configuration of the Migration In the Workloads overview, select the workload and click the Configure Migration button. This brings you to a screen where you can first configure the basic migration settings: Full or incremental replication. for migrations to Microsoft Azure, only full replications are supported Target selection. choose any Microsoft Azure Location which was previously configured as a Target Fig. 23 Configuring The Basic Migration Settings When these selections have been make, click on Configure Migration at the bottom of the screen. This brings you to the configuration screen for the workload migration. This screen has four subsections: Schedule Settings This section allows you to schedule the execution of the migration. If you will manually kick off the migration after its configuration, no schedule needs to be set up. 19

22 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate Fig. 24 Schedule Settings And Migration Settings Migration Settings This section contains most of the Microsoft Azure-specific migration settings. You need to provide information for the following configuration settings: Cloud Instance Size. by default the size that most closely matches your workload will be selected. If you want to use another Cloud Instance Size, you can select it from the drop-down menu. Replication Network. this is the network (Virtual Network and Subnet) that will be used for the replication traffic. Usually these will be the same as for the final target workload, but they can be different if needed. Networks Allowed for Replication. networks on the source workload that can be used for replication. Virtual Machine Name. name of the virtual machine in Microsoft Azure. The default pattern used by PlateSpin Migrate is <hostname>-vm. Disk(s). the disks that need to be replicated. For each disk you can select the Datastore (i.e., the Storage Account) that will provide the necessary storage services. The DiskPath is auto-generated using the pattern <hostname>/<hostname>-vm_<index>.vhd. 20

23 Fig. 25 Microsoft Azure-Related Migration Settings Target Workload Settings Besides having to select the final network (Virtual Network and Subnet) for the target workload, no settings in this section are specific to migration to Microsoft Azure. Consult the PlateSpin Migrate documentation for more information. Tag No settings in this section are specific to migration to Microsoft Azure. Consult the PlateSpin Migrate documentation for more information. Cutover: Executing the Migration Once all information is provided, click on Save to save the configuration. This brings you to a summary page called Cutover Configured with all migration configuration details. Check the details one last time, and then click the Run Cutover button and confirm the extra Execute 21

24 White Paper Best Practices for Migrating Workloads to Microsoft Azure with PlateSpin Migrate step in the next screen. This will initiate the workload migration. PlateSpin Migrate will automatically enable RDP services on the target workload, if they were not enabled on the source workload, and will modify the firewall settings of the target workload to enable RDP traffic. When the migration is finished, PlateSpin Migrate will boot the target workload in Microsoft Azure, allowing you to log in with any RDP client. NetIQ recommends shutting down services on the source workload prior to starting the cutover. This ensures that all necessary transaction data is captured in the migration. NetIQ recommends shutting down services on the source workload prior to starting the cutover. This ensures that all necessary transaction data is captured in the migration. Fig. 26 Find Your Migrated Workload Booted In Microsoft Azure After The Migration Has Completed 22

25 Additional Resources NetIQ has posted three YouTube movies that describe the end-to-end process of migrating a workload to Microsoft Azure, similar to what is described in this document: Part 1 Setting up your VPN and networks: Part 2 Configuring your Azure cloud: Part 3 Driving a workload migration: 23

26 Worldwide Headquarters 515 Post Oak Blvd., Suite 1200 Houston, Texas USA /communities/ For a complete list of our offices in North America, Europe, the Middle East, Africa, Asia-Pacific and Latin America, please visit: /contacts Q 04/ NetIQ Corporation and its affiliates. All rights reserved. NetIQ, the NetIQ logo, and PlateSpin are trademarks or registered trademarks of NetIQ Corporation in the USA. All other company and product names may be trademarks of their respective companies.