Create Content

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: more minor wording changes

...

  1. Review your MCP 1.0 environment and eliminate unnecessary assets
    1. Review current Cloud Servers in the MCP 1.0 location. Delete any that you no longer require on MCP 2.0
    2. Review any Client Images that you have deployed in the MCP 1.0 location. Delete any that you no longer require on MCP 2.0
    3. Cleanup Firewall Rules and ACL Rules
  2. Assess your downtime requirements
    1. Identify your mission critical systems and calculate the downtime you can take
    2. Follow step 6 to migrate any machine(s) that can be shut down or which might require a longer downtime
  3. Create a Network Domain in the corresponding MCP 2.0 location (this will be your "Target" location)
    1. Deploy a MCP 2.0 Network Domain in the Target MCP 2.0 location as described in How to Deploy a Network Domain in a MCP 2.0 Data Center Location
      1. MCP 2.0 supports multiple VLANs in the same Network Domain so for most users, only a single MCP 2.0 Cloud Network Domain will be required
    2. For each MCP 1.0 Network, deploy a VLANs VLAN in the MCP 2.0 Network Domain to support your Cloud Servers
      1. You can configure each VLAN to match the Source Cloud Network's IPv4 Addressing. Unlike MCP 1.0, MCP 2.0 allows users to define their IPv4 address space. For details, see Introduction to IP Addressing in MCP 2.0.
    3. Add Public IPv4 Blocks to support your needs. See How to Manage Public IPv4 Addresses on a Network or Network Domain
      1. Unlike MCP 1.0, a Cloud Network Domain does not include any public IPv4 addresses by default.
  4. Create Equivalent Firewall Rules on Your MCP 2.0 Target
    1. Create Firewall Rules on the MCP 2.0 Target Network Domain to match the MCP 1.0 Source Network's intent as described in How to Create a Firewall Rule on a Network Domain
      1. Note firewall behavior is different in MCP 2.0. The default rules are different - traffic between VLANs is denied by default. For more details, see Introduction to Firewall Rules for Cloud Network Domains in MCP 2.0
  5. Copy Client Images from MCP 1.0 Source location to MCP 2.0 Target location
    1. This function does not use the DRS for Cloud feature as it applies only to Cloud Servers. Instead, use the function described at How to Copy a Client Image between Locations in the Same Geographic Region
  6. Copy powered off MCP 1.0 Servers from MCP 1.0 Source Network to MCP 2.0 Target Network Domain
    1. If the server isn't running, the DRS for Cloud feature isn't needed. Instead, use the function described at How to Copy a Stopped MCP 1.0 Cloud Server to an MCP 2.0 Data Center Location
  7. For each powered on MCP 1.0 Source Server, Create a DRS Target Server attached to the associated VLAN
    1. Details on this function are available at How to Create a DRS Target Server. Make sure you assign the DRS Target Server the same private IPv4 address as the Source Server. This ensures that the CloudControl IPv4 record will be accurate when the DRS Preview step is implemented below.
    2. MCP 2.0 supports multiple NIC's but since you're migrating a MCP 1.0 Cloud Server, it will only have one NIC.
  8. Create Consistency Group(s) that Pairs your MCP 1.0 "Source" Servers to the MCP 2.0 "Target" Servers
    1. Details on this function are available at How to Create a DRS Consistency Group
    2. Identify the servers that need to be migrated with the server state as of the same period in time and group them together in the same Consistency Group.
  9. You will need to wait for the Consistency Group to replicate, which can take several hours
    1. You can monitor the state as described in How to View and Clean your Consistency Groups
  10. You can test your migration by putting the Consistency Group(s) in DRS Preview mode using a DRS snapshot
    1. This brings up your Target Servers with the same disk state as the Source Servers as of the snapshot time. Details on this function are at How to Start a DRS Preview for a Consistency Group
      1. Use the most recent available DRS Snapshot
      2. Once the Consistency Group is in preview mode, you can login using the console option and validate the workload
      3. If you configure the NIC in the Guest OS with the same IPv6 assigned to the Primary NIC, you'll be able to use that IPv6 to log in via the Client-to-Site VPN described in How to Connect to a VPN with Single-Factor or Multi-Factor VPN Authentication
      4. We recommend confirming the CloudControl record of the Cloud Server NIC address matches what you see configured in CloudControl
    2. Note that if your application leverages inbound public IP traffic, you'll need to configure equivalent connectivity to your new public IP addresses:
      1. MCP 2.0 NAT functionality is similar to MCP 1.0. See How to Create a NAT Rule on a Network or Network Domain
      2. MCP 2.0 uses Virtual Listeners instead of MCP 1.0 VIP functionality. For an overview, see Introduction to Virtual Listeners / VIPs in MCP 2.0
      3. You should ensure your DNS entries are prepared to support a migration to the new MCP 2.0 public addresses by making sure the TTL (Time to Live) is short

...

  1. Put your MCP 1.0 assets into maintenance
  2. Put the Consistency Group(s) in DRS Preview mode in the same manner you did for testing
  3. Apply IPv6 addresses to the Target Servers as was done in testing.
  4. Confirm the application is ready to migrate prior to the next step!
  5. Commit the DRS Preview State as described in How to Initiate a Failover for a DRS Consistency Group
    1. The workload on the MCP 2.0 Target Server will be powered on and the corresponding workload in MCP 1.0 will be powered off
    2. The Consistency Group will be removed as part of this process, so it's a one-way change. 
      1. If for some reason you need to fail back, you can power off the Server in MCP 2.0 and power the MCP 1.0 Server back on but to re-initiate migration, you will need to re-configure all of the Consistency Group(s)
  6. As needed, update DNS records to the new Public IPv4 on the MCP 2.0 side
    1. You will need to work with you DNS provider support team to change the DNS setting
  7. If you use Cloud Monitoring, disable Cloud Monitoring on the MCP 1.0 Source Server and enable on the MCP 2.0 side.
    1. To disable to MCP 1.0 side, see How to Disable Cloud Monitoring for a Server
      1. Stopping Cloud Monitoring will delete historical data. You can download reports before you disable in case you need to preserve the historical data.
    2. To enable the MCP 2.0 side, see How to Enable Cloud Monitoring for a Server
  8. If you use Cloud Backup 
    1. Backup history or retention cannot be moved to MCP 2.0
    2. If you do not need backup history of the MCP 1.0 server, simply simply delete backups from MCP 1.0 as described in How to Delete a Backup Client on a Cloud Server and How to Disable Cloud Backup for a Server
    3. If you wish to keep the backup history available for a period of time, you can detach the history and described in Detaching a Backup Set. However, you cannot restore onto the MCP 2.0 server in a self-service manner. To restore onto MCP 2.0, you will need to open a ticket with backup support to perform a restore on your behalf
    4. In either case, you may want to change your backup approach on MCP 2.0:
      1. Many MCP 2.0 locations support a newer alternative called Cloud Server Snapshots. See Introduction to Cloud Server Snapshots
      2. Alternately, you can enable the same Cloud Backup feature on MCP 2.0 as described in:
        1. How to Enable Cloud Backup on a Cloud Server
        2. How to Install the Backup Client on a Linux Server and How to Install the Backup Client on a Windows Server
        3. Additional Steps to Enable Application Backups once Client is Installed
  9. When complete, delete your MCP 1.0 assets and take advantage of the new capabilities MCP 2.0 offers.

...