Skip to content

Migration process#

Migration process consists of a preliminary stage, which is a Migration plans preparation, and of a Migration testing itself.

Available migration scenario#

pp_recoveryflow-recover-as-a-vm

Each of these steps is described in detail below.

Create and prepare Migration plans#

Migration plans are scenarios for a migration process in case of test or final migrations. They include descriptions of machines (flavor type, rank, etc.) and network settings. Rules for creating Migration plans and their syntax.

dr_add_drplan_dialog

Create a Migration plan#

To create a Migration plan, just click Add on the Customer page.

dr_add_drplan_btn

When adding a new plan, specify its name and the contents of the plan. Migration plan name must be unique within the customer.

There are two modes for creating or editing a plan: Basic and Expert. To switch between them, choose the corresponding tab on the "Generate Migration Plan" page.

In the Basic mode, the user can either paste/enter network specifications for a failover machine manually or pick the networks from the list that Acura gets directly from the target cloud. The list of networks can be received automatically from the following platforms - VMware, OpenStack, Flexible Engine, AWS, Azure.

dr_basic_mode

The Expert mode allows for a more detailed configuration that should be provided in the JSON format.

dr_add_drplan_dialog

The body of a Migration plan is a JSON instruction for migrating up of the infrastructure and the business application in a target cloud. To generate a plan based on all customer machines, click on the link Generate Migration plan from all machines.

Migration plan for a group of machines#

To generate a Migration plan for several machines or a group of machines, just click Generate Migration plan in the Bulk Actions menu after selecting them

cp_device_actions_genplan

or the menu item in the group properties

cp_group_genplan

The dialog window for creating and editing a disaster recovery plan will appear, specify its name. Migration plan name must be unique within the customer. The content of the plan is formed based on the selected machines settings.

dr_add_drplan_dialog

Generate a migration plan from a file#

This tool is best used for machines that have already been replicated. It is highly efficient for multiple machines as it saves a significant amount of time when creating a plan for them.

To get started, download the machines list.

In the machines_list.csv file some fields will be automatically filled based on the replication data. Update the information in the "flavor" field, enter the "cidr" of the network in which the machine should be installed, and add information about the ports in the columns starting with "ports".

Once you have updated the file, upload it. To begin creating the migration plan, click on the Apply button.

cp_create_plan_from_file

It will take some time to create the migration plan, after which a window will open. In this window, you can edit the plan name and other fields if needed.

cp_edit_plan_created_from_file

Pay close attention to the orange warning text at the top of the window, as it indicates potentially problematic areas that could cause migration issues. Make any necessary corrections on the form.

Once you are satisfied with the plan, click on the Save button to save the migration plan.

Migration plan syntax#

Migration plan body is a JSON instruction for restoring infrastructure and business application in a target cloud.

Example of a Migration plan:

{
"devices": {
    "IIS_Acura-Demo": {
    "rank": 1,
    "id": "52ce9361-b282-72b6-425a-f67347c5b79a",
    "ports": [
        {
        "name": "port_0",
        "ip": "192.168.15.112",
        "subnet": "main_subnet"
        },
        {
        "name": "port_1",
        "subnet": "external"
        }
    ]
    },
    "rhel7.2": {
    "id": "522f3448-6a56-aa45-2131-207f7dda6664",
    "ports": [
        {
        "name": "port_0",
        "ip": "192.168.15.100",
        "subnet": "main_subnet"
        }
    ],
    "rank": 0,
    "boot_condition": {
        "delay_seconds": 120,
        "type": "wait"
    }
    }
},
"subnets": {
    "main_subnet": {
        "cidr": "192.168.15.0/24",
        "subnet_id": "eda47a07-d1dd-4aca-ae8f-c652e997008e"
    }
  }
}

Basetags#

devices -- contains a description of each machine. It is necessary to list all the machines that should be recreated in the cloud site:

{
"devices": {
    "rhel7.2": {
      "id": "522f3448-6a56-aa45-2131-207f7dda6664",
      "ports": {
        "port_0": {
          "ip": "192.168.15.100",
          "subnet": "main_subnet"
        }
      },
      "rank": 0,
      "boot_condition": {
        "delay_seconds": 120,
        "type": "wait"
      }
    }
}

subnets -- contains a description of networks that need to be recreated on a target site:

{
 "subnets": {
    "main_subnet": {
        "cidr": "192.168.15.0/24",
        "subnet_id": "eda47a07-d1dd-4aca-ae8f-c652e997008e"
    }
  }

Syntax of machine description#

Machine description consists of a number of parameters describing machine properties, such as machine name, flavor for the machine in the cloud site, network settings, rank and conditions for loading the machines to maintain the sequence and orchestration for the launching process of the cloud site:

{
"rhel7.2": {
      "id": "522f3448-6a56-aa45-2131-207f7dda6664",
      "custom_image_metadata": {
        "hw_qemu_guest_agent": "no",
        "os_require_quiesce": "no",
        "my_os_type": "linux-custom",
        "hw_disk_bus": "scsi",
        "hw_scsi_model": "virtio-scsi",
        "my_custom_image_tag": "linux"
      },
      "security_groups": [
            "sg-1",
            "sg-2" 
      ],
      "availability_zone": "zone-1",
      "user_data": "#!/bin/bash\nrpm -e hlragent\nrm -rf /etc/hystax\n",
      "ports": {
        "port_0": {
          "ip": "192.168.15.100",
          "subnet": "main_subnet"
        }
      },
      "rank": 0,
      "boot_condition": {
        "delay_seconds": 120,
        "type": "wait"
      }
    }
}

Machine description parameters:

Parameter Description Required field
machine_name Base tag for machine description. Name will be used to identify machine in the cloud site. Yes
fix_dev_prefix Enter the prefix to automatically update Linux target disk names during P2V. Possible values:
- ‘sd’ (for names like /dev/sda1),
- ‘vd’ (for names like /dev/vda1),
- ‘xvd’ (for names like /dev/xvda1).
Disk names are replaced as a part of Linux P2V in the following files (non-existing files are skipped):
- /etc/fstab,
- /boot/grub/grub.cfg (also /grub/grub.cfg in case /boot is a separate partition),
- /boot/grub2/grub.cfg (also /grub2/grub.cfg in case boot is a separate partition).
Example:
{
"devices": {
"ds-debian10-sda": {
"fix_dev_prefix": "vd",
...
}
}
}		 No
id Internal id of customer machine that is generated with Migration plan pre-generation. Can also be found by moving the mouse pointer to the machine name in the machine list on the Customer page. Yes
ports List of machine's network interfaces configurations. There can be one or more interfaces. Interfaces will be added in the same order in which they are described. Interface parameters description and example see below. Yes
rank Order in which a group of machines will be launched. For example machines with rank 2 will be launched only after all machines with rank 1 are started and those in turn only after all machines with a rank 0 are started. Yes
boot_conditions Condition in which a machine is considered to be running. Delay in time is supported after its expiration the machine is considered to be running. The condition extends across the whole rank. If there are several machines with a delay in time the rank is considered fulfilled after waiting for the longest time.
Syntax:
"boot_condition": {
"delay_seconds": number of seconds to wait,
"type": "wait"
}

Example

"boot_condition": {
"delay_seconds": 120,
"type": "wait"
}
 No
flavor Name or ID of an existing flavor in the target cloud. For VMware target cloud, flavor is specified as vCPU-RAM, e.g. 2-4 that stands for 2vCPU and 4GB RAM
Example:
“flavor”: “2-4”		 Yes
config_drive False by default. Set it as true to use the configuration drive.
Example:
"config_drive": "true"		 No
security_groups List of security groups to use for the the machine. This will overwrite the default group(s). No
availability_zone Name of Availability Zone to use for the machine. This will overwrite the availability_zone that is specified in the cloud config settings No
user_data Script to be executed on the target machine. To use the key “user_data”, the source machine must have cloud_init installed, otherwise, it will be ignored. This key can be used only for OpenStack target cloud. No
firmware (Vmware, oVirt, GCP) Parameter that selects a boot option for the machine. Available values are BIOS or EFI. If not specified, BIOS will be used by default.
Example:
“firmware”: “EFI”		 No
guest_id Guest operating system identifier. Refer to VMware’s official documentation Example: “guest_id”: “ubuntu64Guest” No
hardware_ver Virtual machine hardware version. Refer to VMware’s official documentation The following format is required “vmx-”.
Example:
“hardware_ver”: “vmx-11”		 No
byol (AWS only) If byol is false (or not set), AWS ImportImage is used (AWS does its own P2V). If byol is true, AWS RegisterImage is used and we do our own P2V.
Example:
"devices": {
"sd_small_ubuntu": {
"rank": 0,
"byol": true,
}
}		 No
ntp_server (Windows only) Specify the protocol used by Windows operating systems to synchronize.
Example:
"devices": {
"im-WS2019-ntp": {
"flavor": "m1.medium",
"ports": [
{
"name": "port_0",
"subnet": "provider-subnet"
}
],
"id": "52eef058-012b-70dd-9271-28ee5f56d171",
"rank": 0,
"ntp_server": "ntp6.ntp-servers.net"
},
"subnets":{
"provider-subnet": {
"name": "provider-subnet",
"subnet_id": "6129317f-4987-4bf3-bfd0-c0edc3bc4bba",
"cidr": "172.24.1.0/24"
}
}
}		 No
hostname (Windows machines in OpenStack clouds only) New hostname of the Windows machine. Can be set to:
- true (default) – use machine name from plan as hostname.
- false – do not modify hostname.
- any string – set hostname to this string.
Example:
"devices": {
"ds2012test": {
"id": "9f51d0de-b6cb-400e-b223-5e748cc39d01",
"flavor": "m1.medium",
"hostname": "my-super-long-custom-hostname",
"rank": 0,
"ports": [
{
"name": "port_0",
"subnet": "DS-internal-2"
}
]
}
},
"subnets": {
"DS-internal-2": {
"name": "DS-internal-2",
"subnet_id": "76377dae-4e35-4183-bafa-b06eef69249e",
"cidr": "172.22.0.0/16"
}
}		 No
rclocal_script Script that runs when Linux boots.
Example:
"rclocal_script": "#!/bin/bash\ndate > date.txt\n"		 No
copy_efi_bootloader False by default. Set it as true to use a stock bootloader.
Example:
"copy_efi_bootloader": true		 No
key_name Key pair for a device.
Example:
"key_name": "yv-key"		 No
meta A list of instance meta tags. OpenStack, OpenNebula.
Example:
"devices": {
"rhel7.2": {
...
"meta": {
"Image Name": "Hystax_CATI_...",
"Image ID": "f389c03b-...",
"Image": "image",
"Key Name": "username"
}
}		 No
custom_image_metadata Set custom image metadata for replicated machines. OpenStack only.
Example:
"custom_image_metadata": {
"hw_qemu_guest_agent": "no",
"os_require_quiesce": "no",
"my_os_type": "linux-custom",
"hw_disk_bus": "scsi",
"hw_scsi_model": "virtio-scsi",
"my_custom_image_tag": "linux"
},
It is possible to set the parameter as a string with a JSON object:
"custom_image_metadata": "hw_qemu_guest_agent=no,os_require_quiesce=no,my_os_type=linux-custom,hw_disk_bus=scsi,hw_scsi_model=virtio-scsi,yv_custom_image_tag=Linux".
Alternatively, this parameter can be set as an additional option during the initial configuration step or when adding a cloud. Note that if the parameter is set both during initial configuration/cloud addition and in the Migration plan, the Migration plan settings take priority and will be applied to the cloud, even if the value is an empty string.		 No

Ports' interface description has the following parameters:

Parameter Description Required parameter
name interface name Yes
ip interface IP address.

Windows adapters will be configured as DHCP by default. If you want to set static configuration, use this field in conjunction with mac field.		 No
mac interface mac address. Ignored for AWS target cloud. No
subnet subnet name that the interface will belong to Yes
routing_allowed allows machine to be a router (has “true” or “false” values, default value is “false”). Ignored for AWS target cloud. No
floating_ip adds floating_ip for port (has “true” or “false” values, default value is “false”). Using this parameter with the “true” value limits the machine to have only one port. “floating_ip”: “” will assign a specific external IP to the target machine. (Openstack, Huawei only) No
mtu (Windows only) The largest size of a packet that can be sent in a network connection without needing to be fragmented. Use in conjunction with a mac address.
Example:
"devices": {
"DS2012R2MULMBR": {
"id": "9f51d0de-b6cb-400e-b223-5e748cc39d01",
"flavor": "m1.medium",
"rank": 0,
"ports": [
{
"name": "port_0",
"ip": "172.22.8.249",
"mac": "08:00:27:46:79:29",
"gateway_ip": "172.22.1.2",
"dns_nameservers": [
"172.22.1.2",
"8.8.4.4"
],
"mtu": 1511,
"subnet": "DS-internal-2"
}
]
}
},
"subnets": {
"DS-internal-2": {
"name": "DS-internal-2",
"subnet_id": "76377dae-4e35-4183-bafa-b06eef69249e",
"cidr": "172.22.0.0/16"
}
}		 No

Examples:

"ports": [{
    "name": "port_0"
    "ip": "192.168.15.100"
    "subnet": "main_subnet"
    }]

Ports, subnets, mac, ip, gateway, and dns. To set static - use mac (windows failover):

  {
  "devices": {
    "sd_small_ubuntu": {
      "rank": 0,
      "ports": [
        {
          "name": "port_0",
          "ip": "172.22.8.144",
          "mac": "08:00:27:46:79:27",
          "gateway_ip": "172.22.1.2",
          "dns_nameservers": [
            "172.22.1.2",
            "172.22.1.3"
          ],
          "subnet": "subnet_1"
        }
      ],
      "id": "5260881c-c921-f037-df78-6105f018a9c2",
      "flavor": "m1.medium"
    }
  },
  "subnets": {
    "subnet_1": {
      "name": "subnet_1",
      "cidr": "172.22.0.0/16"
    }
  }
}

In the case of floating IP: 

  "devices": {
    "centos": {
      "ports": [
        {
          "name": "port_0",
          "floating_ip": true,
          "subnet": "subnet_0"
...

Syntax of network description#

Network description consists of a number of parameters, such as network name, its CIDR and the address of DNS servers.

Example:

{
"subnets": {
    "main_subnet": {
        "cidr": "192.168.15.0/24",
        "subnet_id": "eda47a07-d1dd-4aca-ae8f-c652e997008e"
        }
  }
}

Network description parameters:

Parameter Description Required parameter
network name network identifier name is a base tag for network description Yes
cidr network CIDR Yes
subnet_id existing subnet ID in the target cloud. Yes

Note

Specified subnet_id must be available for the used Availability Zone.

Edit an existing Migration plan#

To edit an existing Migration plan, select an appropriate Migration plan and click Edit on the Customer page.

dr_edit_drplan_btn

A dialog window, where the Migration plan can be edited, will appear.

dr_edit_drplan_dialog

Test and final migrations#

Once full replicas of selected machines are completed, customer can run a set of test migrations to evaluate the results, form correct expectations and configure infrastructure settings.

A detailed description of migration process configuration.

rp_recovery_flow3

Migration process may require some time: its duration depends on the structure complexity of a Migration plan and orchestration / dependency levels between components of a business application. As soon as all components receive the Active status, the business application is ready for operation, and it is possible to test the migration or perform a final migration, which will lead up to detaching the Hystax solution from the cloud site.

Warning

Redirecting the main traffic to AWS or KVM platform is not part of the solution's current functionality and should be coordinated with the service provider in advance.

For the sake of time-saving, it is recommended to use a simplified set of tests that will run in the cloud site before switching production traffic to the new target.

Cloud site settings#

After cloud site creation, a number of additional actions can be performed in order to configure the runtime of a business application, such as adding machines to the cloud site, stopping/starting machines. See the description of the cloud sites and the related settings.

cs_cs_page

During Migration testing, it is recommended to remove redundant cloud sites so that they do not take up spare resources.

Hystax Support Portal | Contact Support: [email protected] | Terms of use | © Copyright 2024 | Hystax | All rights reserved