Migrating WordPress to Azure Using Azure Site Recovery (ASR) 1
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, our provision of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. The descriptions of other companies products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers. 2016 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without express authorization of is strictly prohibited. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. 2
Contents 1. Introduction... 4 2. Target Audience... 4 3. Prerequisites... 4 4. Source Environment (on-premise) Setup... 5 5. Migrating WordPress (Standalone) to Azure... 6 5.1. Deploy Mobility Services Agent & Replicate Workload to Azure... 6 5.2. Create a Recovery Plan for your workloads... 13 5.3. Initiate Failover & Validate Workload... 14 5.3.1. Test Failover... 14 5.3.2. Failover... 20 6. Next Steps... 27 7. Additional Resources... 27 8. Support... 28 3
1. Introduction This document is a detailed guide describing the steps for migrating on-premise WordPress workloads to Microsoft Azure using Azure Site Recovery (ASR). It is only intended to be used as a reference guide by Managed Services Providers (MSPs) that are part of the MSP - Azure Cloud Migration Program. The goal is to help MSPs familiarize themselves with the processes and steps needed to migrate on-premise WordPress workloads by leveraging the capabilities of ASR services to migrate workloads to Azure. Although ASR was designed as a Business Continuity and Disaster Recovery (BCDR) tool, the same techniques can be applied for migrations because of its direct replication capabilities to Azure with minimal changes required to the on-premise infrastructure. Specifically, this document covers the migration of WordPress to Azure. 2. Target Audience This document is primarily intended for Azure Architects, Solution Specialists and System Administrators who will be involved in the on-premise to Azure workload migrations. It is assumed that this audience understands the intricacies of Microsoft Azure and its core services and has deep insights into its customer s on-premise workloads in order to successfully migrate them to Azure. The document is NOT intended to be a primer or guide on WordPress or ASR but rather a guide to migrating WordPress workloads to Azure. 3. Prerequisites Before we can get started with migrating WordPress to Azure, all items listed below must be completed or complied with: 4
1. The source Planning, Discovery, and Assessment (Business risk, Cloud Suitability Etc.) steps should be completed and the application/workload has been approved to be migrated to Azure. 2. The Azure Network Planning should be completed. 3. The ASR Capacity Planning and source setup should be completed. 4. Installation and Configuration of Apache (2.2.15 (UNIX)) should be completed. 5. Installation and Configuration of MySQL (Version 14.14) should be completed. 6. Installation and Configuration of WordPress (Version 4.6.1) should be completed. 7. Red Hat Version(s) supported by ASR are: Red Hat Enterprise Linux 6.7 Red Hat Enterprise Linux 7.1 Red Hat Enterprise Linux 7.2 Please Note: This document showcases WordPress on Red Hat Enterprise Linux 6.7 (Enterprise) version only. Other versions of supported Red Hat Enterprise Linux migrations will be similar, but it is recommended that partners understand the subtle differences to successfully migrate to Azure. 4. Source Environment (on-premise) Setup This section covers the lab environment configuration that was used to test the migration of a WordPress using ASR. 1. We have a single Red Hat Enterprise Linux 6.7 server (VM) running a WordPress application and a local instance of MySQL Server acting as the backend database. 2. The VM has a single dynamic disk (VHD) attached with a base Size of 20GB shared across the Operating System, MySQL database & Apache logs. The document assumes that these migration procedures would be similar to other supported versions of Red Hat Enterprise Linux Server workloads, but have not been verified. It is highly recommended that the Architects and System Administrators involved in the migration effort ensure that they are testing this in their version of the environment. 5
5. Migrating WordPress (Standalone) to Azure Migrating an application to Azure is typically a phased approach that consists of the following stages: I. Deploy Mobility Service Agent & Replicate the Workload: Using ASR, the source workload is replicated to an Azure Recovery Vault. Once the initial replication is complete, ASR constantly monitors the application in the source and replicates the deltas to Azure on a regular basis. II. III. Test Failover: Once the initial replication is complete, a test failover will spin up Azure VMs and the application can be tested multiple times without affecting the production workload running in the source environment. Failover: After the application has been successfully tested and validated to your satisfaction using test failover process, an unplanned failover will initiate a failover of the application from the source to Azure and turn off the source VM(s). 5.1. Deploy Mobility Services Agent & Replicate Workload to Azure The first step in migrating WordPress workloads to Azure is to Deploy the Mobility Services Agent and start replicating the workload using ASR. Once the initial replication process is complete, ASR constantly monitors the application in the source and replicates the changes (deltas) to Azure as well. The section below shows the steps to replicate WordPress workload to Azure. 1. Login to the Azure Portal. Under All Resources search for the Recovery Vault name, open it and click on Site Recovery. Note: This Recovery Vault should have been setup using the ASR Setup Guide prior to migrating workloads. Please refer to the ASR Setup Guide for more details. 2. Click on Step 2: Replicate Application and then click on the Source blade to select the below options and click OK. Source On Premises Source location - Select the Configuration Server 6
Machine type o Physical Machines for migrating Physical or HyperV VM s o Virtual Machines for migrating VMware VMs VCenter / VSphere Host Select the VCenter host [Applies only if you selected virtual machines for Machine Type] Process Server Select the Process server that you want to use for replication. If you haven t set up a separate or multiple process server(s), the configuration server will show up as default 7
3. Under Target choose the following properties and click OK: Subscription The subscription to be used for migrations. Post Failover Resource Group The Resource Group to be used for Migrations. (These should have been created as part of the migration planning process). Post Deployment failover model Resource Manager. Storage Account Choose the one(s) that were created for handling migrations during ASR Capacity Planning phase. Azure Network Configure now for selected machines. Post Failover Azure Network - Choose the Azure VNET that was created for migrations during the Network planning phase. Subnet Choose the correct subnet within the Azure VNET. 8
4. Based on the Machine Type chose earlier, the below section(s) will slightly change: If Machine Type = Virtual Machines: In the Virtual Machines > Select Virtual Machines blade, select the RHEL VM you want to migrate and click OK 9
If Machine Type = Physical Machines: In the Physical Machines > Select Physical Machines blade, click on +Physical Machine. Enter the Server Name, on-premise IPAddress, select OS type and click OK. This will discover the on-premise server from and add it to the vault for protection. Continue this process to add more RHEL servers to be replicated (if required). 5. Under Notifications you will see that the server is being discovered and if the mobility services agent is NOT present, it will be installed on this server. You can always check the progress of this job under Your Recovery Vault > Jobs > Site Recovery Jobs 10
6. Once the job completes, you can see that newly discovered server in the Azure Portal. 7. In Properties > Configure Properties blade, either set default values or choose properties per VM. Account Choose the appropriate account that has administrator rights to the Servers being migrated Disks to replicate From the dropdown, select the disks that you want to include in replication and uncheck the ones that are not required (Ex: Disk for non-production (temp) data). 8. In Replication settings > Configure replication settings choose the appropriate policy and click OK with the default values. You can always modify the replication policy in Your Recovery Vault > Site Recovery Infrastructure > Replication Policies (For VMware & Physical Machines) > Policy Name > Edit Settings. Changes you apply will be used for machines that are already replicating as well as new machines. 11
9. Now click on Enable Replication. 12
10. Track the replication progress by checking at Your Recovery Vault > Replicated Items. Once the status of a Replicated Item (server) changes to Protected, it means the application/workload is ready for failover. 5.2. Create a Recovery Plan for your workloads We are now going to create a Recovery Plan in your Azure Vault. The usage of Recovery Plans helps facilitate easier management and migration of multiple servers (that make your service/application) into Azure without having to deal with each component individually. Below are a couple of examples to provide additional context and the steps below to create and configure a recovery plan. Examples: A Recovery Plan for ALL your RHEL servers in your environment. This way you can migrate all RHEL servers into Azure cutover at one. Enterprise applications are mostly multi-tier that are split into multiple Server roles. Like IIS Web applications are split into Web front end & back end database servers that can be included in the same recovery plan & migrated to Azure. Just about any server(s) that you need to manage & migrate into Azure at the same time. 1. In the Azure Portal, go to Your Recovery Vault > Recovery Plans (Site Recovery Infrastructure) and click on +Recovery Plan. 2. Provide the following details and click OK. Name A meaningful friendly name (Ex: TestRecoveryPlan) Source On premise VMware Host / Configuration Server Target Microsoft Azure Allow Items with Deployment Model Resource Manager Select Items From the list of Protected Items choose ALL the servers that comprise of your application / service and click OK. 13
5.3. Initiate Failover & Validate Workload 5.3.1. Test Failover Once the initial replication is complete, a test failover can now be initiated to test your workload in Azure. This can be done multiple times without affecting the on-premise workload (source independent). 1. Login to the Azure Portal, under All Resources search for the Recovery Vault name and open it. 2. Click on Replicated items, select the replicated server(s) that you want to test for failover (Ex: BELSYSGLAB02) 3. Click on Compute and Network, ensure the correct values as described below are set and click Save: Name This will be pre-populated with the source server name. Recommendation is to leave the same or you can modify by clicking on the Text box. Resource Group Choose the correct Resource Group where the new VMs will be grouped (this should have been decided during planning phase). Size Based on the source server SKU an Azure VM SKU is pre-selected. Either leave as-is or feel free to change SKU as you see fit. 14
Target Network Select the Non-Production Azure VNET created for test failovers (should have been created during Network Planning phase). Target Subnet Ensure the correct subnet is selected (configuration should have been decided during Network Planning phase). TargetIP Either provide a StaticIP from the Target Subnet or DHCP will assign any available IP from the Target Subnet. 4. Repeat Steps 2-3 for all other protected servers that you want to test failover for. 5. Now to Initiate the Test Failover, go to Your Vault > Recovery Plans (Site Recovery), click on against the specific recovery plan choose Test Failover. 6. For Recovery Point choose Latest Processed (most current data). Ensure the correct Azure VNET is showing (or select from drop down list) and click OK 7. Check the progress in Your Recovery Vault > Jobs > Site recovery jobs. Once complete, you will see a new VM created with a suffix of -test [Ex: BELSYSGLAB02-Test]. 15
8. Based on your Network planning and whether to use either Site to Site VPN, ExpressRoute, or a Custom Setup and your enterprise remote access policies, RDP to this new VM using its Azure-IPAddress (You can find this by exploring the VM properties at All Resources > Type VM Name >Properties > Private IP address) 16
9. Ensure that all the Firewall connections are up to date, so that we are able to access the WordPress by following command iptables -nl. 10. Browse the WordPress Application using the Private IP obtained from the failed over VM Properties. 17
11. In addition to all the above, please run any other specific tests as directed by your Linux admin/product team. 12. Once all your application test cases have successfully passed validations, you can complete the Test Failover scenario by following the steps below. Please be advised that this will decommission the Test VM and related resources in Azure however, you can always re-initiate a Test failover how many ever times you want without impacting the source application or other resources. In the Azure Portal, go to Your Recovery Vault > Recovery Plans (site Recovery) > Click against the Recovery Plan that underwent Test Failover and click clean test failover Provide a justification, check Testing is complete, delete test failover virtual machines and click OK. 18
13. The test infrastructure should now be decommissioned and this also concludes the Test failover scenario. Optionally, you can also check the progress at Your Recovery Vault > Jobs > Site Recovery Jobs. 19
5.3.2. Failover Only after the application, has been thoroughly and successfully validated using the Test Failover process and other unit tests as required by the customer s organization, you should initiate a Failover. This will begin the final migration of a server/application/workload from the source (on-premise) environment to Azure. 20
NOTE: Pre-Planned-Failover Checklist 1. When the Failover is initiated, the source server must be shut down before the failover. This is required to prevent any issues with the same application operating in both environments. 2. Please communicate the application migration date and time to all customers and stakeholders. 3. <optional based on your configuration> Any public or private DNS endpoint updates need to be complete before the Failover is initiated. 4. <optional based on your configuration> Complete re-configuration of your Global load balancing (GLB) solutions. 5. <optional based on your configuration> Ensure the server has the appropriate backup/high Availability solutions configured in Azure like Availability sets. 6. <optional recommendation based on your configuration> Planning for a Disaster Recovery (DR) strategy in Azure is complete. 1. Login to the Azure Portal. Under All Resources, search for the Recovery Vault name and open it. 2. Click on Replicated items and then click on the server that has completed the Test Failover (Status shows as Test Failover Completed). 3. Click on Compute and Network, ensure the correct values are set as described below, and click Save: Name This will be pre-populated with the source server name. Recommendation is to leave it the same, otherwise you can modify it by clicking on the Text box. Resource Group Choose the correct Resource Group where the new VMs will be grouped (this should have been decided during planning phase). 21
Size Based on the source server SKU an Azure VM SKU is pre-selected. Either leave as-is or feel free to change SKU. Target Network Select the Production Azure VNET created for test failovers (This VNET should have been created during Network Planning phase). Target Subnet Ensure the correct subnet is selected (again configuration should have been decided during Network Planning phase). TargetIP Either provide a StaticIP from the Target Subnet selected above or DHCP will assign any available IP from the Target Subnet. 4. Repeat steps 2 3 for all other protected servers that comprise your WordPress application. 5. Now to initiate the Failover, goto Your Vault > Recovery Plans (Site Recovery), click on against the specific recovery plan (Ex: TestRecoveryPlan) choose Failover. 22
6. Ensure direction is from Source Azure. For Recovery Point choose Latest Processed (most current data), and check the checkbox to shut down the on premise VM before the beginning of failover and Click OK and wait for the job to complete. You can also check the status at Your Recovery Vault > Jobs > Site Recovery jobs. 7. In the Azure Portal, navigate to Virtual Machines in the left-side navigation menu, and you will now see a new VM has been created. 8. Based on your Network planning and whether to use either Site to Site VPN, ExpressRoute, or a Custom Setup and your enterprise remote access policies, RDP to this new VM using its Azure-IPAddress (You can find this by exploring 23
the VM properties. All Resources > Type VM Name >Properties > Private IP address) 9. Ensure that all the Firewall connections are up to date, so that we are able to access the WordPress by following command iptables -nl. 24
10. Browse the WordPress Application using the Private IP obtained from the failed over VM Properties. 11. In addition to all the above, please run any other specific tests as directed by your Linux admin/product team. 12. Once all your application test cases have successfully passed validations, you can Commit your Recovery Plan by following below steps. In the Azure Portal go to Your Vault > Recovery Plans (Site Recovery), click the Recovery Plan that completed Failover, click More, then Commit. 25
Read and understand the warning, after which you can click OK. Please Note that clicking OK will commit the machines in the recovery plan, and that we cannot change the recovery point of the machine. 13. Once you committed the Recovery Plan you can Complete Migration by following the below steps. This will end ASR protection, remove the server from Your Vault > Replicated Items, and cleanup all migration related properties. In the Azure Portal go to Your Vault > Replicated Items, click the server that completed Failover, click More, then Complete Migration. Read and understand the warning, after which you can click OK. Please Note that clicking OK will finalize the migration of the application to Azure, and that it cannot be rolled back to the source. 26
14. This concludes the migration guide for WordPress to Azure using Azure Site Recovery (ASR). Your workload should now be operational in Azure. 6. Next Steps With the application now migrated to Azure, please follow your enterprise policy to start the application decommission process in the source environment. 7. Additional Resources ASR documentation from Microsoft Azure Migrate Linux workloads to Azure Best Practices to deploy Mobility Services Agent Automate Mobility Services Agent Deployment Planning: o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-prereq 27
o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-deploymentplanner Network Design: o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-networkdesign Capacity Planning: o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-plancapacity-vmware o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-capacityplanner Step by Step guides: o https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-migrate-toazure (Multiple guides) 8. Support For support queries, please refer to our support portal or submit your questions to our support team via email. 28