Based on the location of your PlateSpin Migrate server, review the following sections:
PlateSpin Migrate requires the use of Microsoft Azure Resource Management for migrating workloads to the Microsoft Azure Cloud. For migrations to Microsoft Azure Cloud, you must prepare your Azure account, subscriptions, and services in the desired Azure global and sovereign cloud environment.
Table 9-1 describes the minimum configuration you must perform in the appropriate Azure environment before you can migrate workloads to Azure.
Table 9-1 Minimum Required Configuration for Your Azure Account
|
Azure Configuration |
Description |
|---|---|
|
Microsoft Azure Account |
Create a account in the Azure environment where you will migrate workloads. An administrator on the account is required to perform the Application setup, to enable PRE programmatic access, and to create a Contributor user that will be used by Migrate. |
|
Azure Subscription ID |
The ID for the Azure Subscription in the specified Azure account that you want to bill for Azure-related costs for migrations using PlateSpin Migrate. An account can have multiple subscriptions. You must provide the Subscription ID when you add a Microsoft Azure Location as a migration target in PlateSpin Migrate. To view a Subscription ID, log in to the Azure portal with your Azure user account that you use to manage your subscriptions, then go to the Subscriptions page and select the subscription. |
|
Contributor user for the subscription created in Azure Active Directory |
A special-purpose user identity for PlateSpin Migrate that you create in Azure Active Directory. You add a Contributor role to the user account for the specified subscription. Using this Contributor user only for Migrate helps to uniquely identify actions performed by Migrate in Azure for the subscription. In Migrate, you use the Contributor user credentials to add Azure as a target platform. Migrate uses the credentials for this user when it accesses the Migrate Azure API through the related subscription. See Section 9.6, Configuring a Contributor User for PlateSpin Migrate to Use. |
|
Application (client) ID |
An ID that represents PlateSpin Migrate as it makes use of the Microsoft Azure API when it replicates or migrates workloads on your behalf to VMs in the target Azure location for a subscription in your Azure account. See Section 9.5, Configuring an Application in Azure to Represent PlateSpin Migrate. |
|
Azure Virtual Network and Subnet |
You must create least one Virtual Network with a Subnet in the specified Subscription. If you have an site-to-site VPN set up, the subnet must be different than the default Gateway Subnet. Network resources are never created automatically by PlateSpin Migrate, so they always must be set up manually in advance. For instructions, refer to Azure documentation. |
|
Azure Storage Account |
For each target VM, PlateSpin Migrate supports using Azure Managed Disks or using Azure Storage Accounts and unmanaged disks. The setting applies at the VM level. NOTE:At least one Azure storage account is required when you use unmanaged disks. Managed Disks do not require a storage account. |
|
Azure Availability Sets |
PlateSpin Migrate supports using pre-defined Azure Availability Sets for target VMs. See Prerequisites for Using Azure Availability Sets. |
For each target VM, PlateSpin Migrate supports using Azure Managed Disks or using Azure Storage Accounts and unmanaged disks.
Azure Managed Disks is an Azure service that provides replicas of your data to help ensure persistence of your data and high tolerance against failures. Azure automatically creates and manages the placement of the disks in the target Azure location. You do not need to specify a storage account or location in a storage account. The specified Cloud Instance Size for the target VM determines how many data disks you can attach to the VM and the type of storage you can use to host the managed disks. The Azure Managed Disks setting applies to all disks for the target VM.
Using Azure Managed Disks is optional. It is enabled by default in keeping with Azure default VM settings.
NOTE:
To verify the availability in the target Azure location of Managed Disks service, refer to the Microsoft Azure Products Available by Region.
For information about disk types, sizes, and performance characteristics for Azure Manage Disks, refer to Introduction to Azure Managed Disks in Microsoft Azure Documentation.
Azure automatically and transparently provides Azure Storage Service Encryption for all storage, including Azure Managed Disks.
PlateSpin Migrate does not support configuration of Azure Disk Encryption for the target workload.
Azure Disk Encryption provides OS-based encryption for OS and data volumes at rest by using BitLocker for Windows VMs or DM-Crypt for Linux VMs. After the cutover is complete, you can use Azure tools to enable Azure Disk Encryption for the cutover workload.
When you configure migrations to Azure, specify one of the following storage types for hosting the managed disks for the target VM:
Standard HDD (hard disk drives)
Standard SSD (solid state drives)
Premium SSD
A storage type of Standard HDD allows you to choose VMs with HDD or SDD storage, whereas Standard SSD and Premium SSD are restricted to VMs that support the appropriate level of SSD storage. For information about disk performance characteristics, refer to What Disk Types Are Available in Azure? in the Microsoft Azure Documentation.
You can use Azure Managed Disks in combination with a predefined Azure Availability Set that has been configured to use managed disks.
If you do not use Managed Disks for a VM, the VM disks are unmanaged by the Azure Managed Disks server. The VM disks will use the Azure page blob type of general-purpose storage, which can run on HDD (Standard) or SSD (Premium) storage media. You can use Azure General Purpose Storage V1 or V2, according to your needs.
If you plan to use unmanaged disks, you must create at least one Azure Storage account in the specified Subscription for the target Azure platform. For information about Azure Storage Accounts, refer to Introduction to Azure Storage in Microsoft Azure documentation.
NOTE:A Standard Storage Account can be used for Azure VM sizes that use HDD or SDD storage media. A Premium Storage Account can be used only for Azure VM sizes that use SDD storage media.
If no Azure Storage Account is associated with a subscription, PlateSpin Migrate sets up a Standard general-purpose storage account to use as the datastore for the target VM. The datastore name is based on the Azure Resource Group for the Subscription.
For information, see Azure Page Blobs (unmanaged disks) in Microsoft Azure Documentation.
An Azure Availability Set is an Azure service that provides high availability to two or more member VMs by deploying them in different fault domains and update domains. Fault domains ensure that the VMs run on different host servers, compute racks, storage units, and network switches. Update domains ensure that maintenance outages for host hardware do not occur at the same time.
NOTE:VMs must be created in the Availability Set. You cannot add an existing VM to an Availability Set.
Using Azure Availability Sets is optional. No availability set is configured by default for the target VM, even if the selected Resource Group includes availability sets.
PlateSpin Migrate supports using pre-defined Azure Availability Sets for target VMs. You cannot create Availability Sets in Migrate.
Before you configure workloads for the target VMs that you want to add to an Availability Set:
Use the Azure portal to create and define the Availability Set in a resource group for the specified target location.
You can use an Availability Set in combination with Azure Managed Disks only if you enable the Use Managed Disks option in the Availability Set definition.
When the first VM is created in the Availability Set, Azure selects the physical hardware that will be used in the target Azure location. Thereafter, Azure limits the cloud instance sizes and networks that can be used for future member VMs accordingly.
NOTE:If you have multiple VMs configured for the same empty Availability Set, the first cutover VM determines the Azure limits based on the configuration characteristics of that VM. PlateSpin Migrate might prompt you to choose different cloud instance sizes or networks after the Azure limitations are enacted.
PlateSpin Migrate provides the ability to automatically install Microsoft Azure Virtual Machine Agent on target Windows and Linux workloads at cutover and test cutover. The minimum requirements for the source workloads are:
Windows: Microsoft Azure supports Azure VM Agent only for workloads running Windows Server 2008 R2 and higher.
Linux: Before you add the source Linux workload to Migrate, ensure that it meets the following requirements:
PlateSpin Migrate requires Python 2.7 or higher to be installed on the source workload.
The source Linux workload must also meet minimum Azure Linux Agent requirements and system dependencies. See Understanding and Using the Azure Linux Agent in the Microsoft Azure Documentation.
If you set up an Azure site-to-site VPN (or an Azure Express Route connection) between the premises where your source workloads reside and the target Azure environment, you can deploy your PlateSpin Migrate server on-premises. Before you use PlateSpin Migrate to migrate workloads to Microsoft Azure, ensure that the following cloud access prerequisites are correctly configured and available:
A PlateSpin Migrate license.
A PlateSpin Migrate server deployed on-premise.
A site-to-site VPN connection between your local data center and Microsoft Azure Portal.
For information, see the following Microsoft resources:
A default Gateway Subnet.
The minimum network-related prerequisites for a successful migration are described in Table 9-2.
Table 9-2 Port Requirements for Migrate Server on Premise
|
Location |
Port |
Protocol |
Remarks |
|---|---|---|---|
|
On-premise source workload Cloud-based target workload |
TCP 443, outbound |
HTTPS |
The on-premise source workload and the cloud-based target workload must be able to communicate with the PlateSpin Migrate server through HTTPS (TCP/port 443) over the site-to-site VPN connection. |
|
On-premise Migrate Server |
TCP 443, outbound |
HTTPS |
The on-premise PlateSpin Migrate server must be able to communicate with the Microsoft Azure API endpoint. |
|
On-premise source workloads |
TCP 22 TCP 135, 445 UDP 135, 138 and TCP 39 |
SSH (Linux) WMI/RPC/DCCOM NetBIOS |
The PlateSpin Migrate server must be able to communicate with the source workloads on the ports that are used for discovery. See Requirements for Discovery and Section 19.6, Discovering Details for Source Workloads. |
|
On-premise source workloads using Migrate Agent |
TCP 22 TCP 443 |
SSH (Linux) HTTPS |
Instead of discovery, you can use the Migrate Agent utility to register source workloads with the Migrate server. See Requirements for Workload Registration and Section 19.7, Registering Workloads and Discovering Details with Migrate Agent. |
|
On-premise source workload Cloud-based target workload |
TCP 3725 |
Migrate |
The cloud-based target workload must be able to communicate (target to source) with the on-premise source workload across the VPN. The source workload must be able to send data to the target workload during replication across the VPN. The port number is configurable. See port 3725 in Section 2.6.3, Requirements for Migration. If you use Migrate Agent for registration and discovery, the default direction of the replication connection must be reversed (source to target) by changing advanced settings on the Migrate server. See Section 5.9, Configuring the Contact Direction for the Replication Port. |
|
Network Security Group in Azure for the cloud-based target workloads |
TCP 443, inbound TCP 3389, inbound TCP 22, inbound |
HTTPS RDP (Windows) SSH (Linux) |
Allow inbound connections in the Network Security Group for the cloud-based target workloads. For information about creating and configuring a Network Security Group in Azure, refer to Create, Change, or Delete a Network Security Group in Microsoft Azure Documentation. |
Before you use PlateSpin Migrate to migrate workloads to Microsoft Azure, ensure that the following cloud access prerequisites are correctly configured and available:
A PlateSpin Migrate license.
Deploy an Azure Marketplace image of the PlateSpin Migrate server in the target Azure environment, or create an Azure Windows instance in the target Azure environment and install the Migrate server. See Deploying PlateSpin Migrate Server in the Cloud
in the PlateSpin Migrate 2019.5 Installation and Upgrade Guide.
NOTE:The cloud-based Migrate server does not require a site-to-site VPN connection between your local data center and Microsoft Azure Portal. When no VPN is provided between the source network and the cloud-based Migrate server, you can use Migrate Agent to register workloads with the cloud-based Migrate server using secure communications over the public Internet. Internet access and public IP addresses are required. For deployment information, see Figure 8-2, Cloud-Based Migrate Server for Automated Migration to AWS.
Specify Static as the allocation method for the public IP address of the Migrate server to ensure that the IP address does not change when the server is restarted.
NOTE:A change in IP address on the PlateSpin Server breaks the heartbeat communications with source workloads.
You cannot specify the actual IP address assigned to the public IP resource. Azure allocates and reserves an IP address from a pool of its available IP addresses in the Azure location where you deploy the Migrate server. The address persists through server restarts. Azure releases the IP address only when you delete the resource or change the resource’s allocation method to Dynamic.
Install the Migrate Agent on the source workload, then register the workload with the cloud-based PlateSpin Migrate server. See Registering Workloads and Discovering Details with Migrate Agent.
To download the Migrate Agent, launch the PlateSpin Migrate Web Interface and click the Downloads tab. For information about installing and using the Migrate Agent, see Migrate Agent Utility.
The minimum network-related prerequisites for a successful migration when the Migrate Server is in Azure are described in Table 9-3.
Table 9-3 Port Requirements for Migrate Server in Azure
|
Location |
Port |
Protocol |
Remarks |
|---|---|---|---|
|
Source workload Network firewall |
TCP 443, outbound |
HTTPS |
Required to allow the source workload to register (using the Migrate Agent utility) and communicate with the cloud-based PlateSpin Migrate server. The PlateSpin Migrate Server uses secure SSL for communications with the workloads you want to migrate. |
|
Source workload Network firewall Network Security Group (NSG) in Azure |
TCP 3725, outbound |
Migrate |
Required to allow communications with the target machine and to transfer data from the source to the target during replication. The direction of the communication (source to target) is automatic, but the port number is configurable.For information about changing the default port setting, see port 3725 in Requirements for Migration. For information about creating and configuring a Network Security Group in Azure, refer to Create, Change, or Delete a Network Security Group in Microsoft Azure Documentation. |
|
NSG in Azure for the Migrate Server |
TCP 443, inbound TCP 3389, inbound |
HTTPS RDP |
Allow inbound connections in the Network Security Group for the cloud-based Migrate server. The <Migrate-server-name>-nsg is created automatically when you deploy the Migrate server in Azure. |
|
NSG in Azure for the Migrate Server |
TCP 61613, inbound |
STOMP |
If you use PlateSpin Transformation Manager with the cloud-based Migrate server, allow inbound connections in the Network Security Group for STOMP communications related to Event Messaging. NOTE:No messages are published by Event Messaging unless you open port 61613 on the Migrate server host to allow registration by subscribers, and a PlateSpin Migrate Connector subscribes. See Section 5.5, Enabling Event Messaging for PlateSpin Migration Factory. |
|
NSG in Azure for the Migrate Server |
TCP 123, outbound |
Network Time Protocol (NTP) |
Add this port setting to the security group if you are using an NTP service outside the virtual network where you deploy the Migrate server. |
|
NSG in Azure for the Migrate Server |
TCP 22, outbound |
SSH |
This port allows outbound communications from the Migrate server to Linux workloads. |