Recovery process

Recovery process consists of a preliminary stage, which is a DR plan preparation, and of a regular DR strategy testing and actions in case of disaster. "Actions in case of disaster" stand for configuration and launching of a cloud site, changes of a running cloud site's settings, failback to production and, finally, removal of the cloud site.

Available recovery scenarios

• Recovery as a virtual machine

Use case: start a virtual machine from a specific recovery point. Sequence of steps:

• Restore files and folders

  Use case: view and download files and folders from a specific recovery point. Detailed information. Sequence of steps:

• Disk attach

  Use cases: recover files and folders using an existing virtual machine, recover a database from transaction logs. Use with the "Recover as a virtual machine" scenario at the disk attachment level from an additional recovery point. Detailed information. Sequence of steps:

• Download an image from failover

  Use case: download backup disks as RAW images. One of the failure recovery scenarios. Detailed information. Sequence of steps:

• Failback

  Use case: automatically create a VM on the source site from a failover VM and perform periodic incremental synchronizations. This option is available for VMware, Flexible Engine, and OpenStack source clouds, and requires downloading and deploying the Failback agent. Detailed information. Sequence of steps:

• Download a virtual machine image

  Use case: Recovering a virtual machine on the source site from recovery point disk images. For security/cleanup purposes, image download has a TTL. Detailed information.

Create and prepare DR plans

DR plans are scenarios for recovery process in case of disaster. They include a description of machines (number of vCPU, RAM, rank, etc.) and networks.

The sheer existence of an up-to-date DR plan is enough for a quick recovery in case of disaster.

Create a Disaster Recovery plan

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

When adding a new plan, specify its name and the contents of the plan. DR 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 DR 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.

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

The body of a DR plan is a JSON instruction for restoring the infrastructure and the business application in a DC. To generate a plan based on all customer machines, click on the link Generate DR plan from all machines.

Disaster Recovery plan for a group of machines

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

The menu item in the group properties.

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.

Generate a DR plan from a file

This tool is best used for machines that have already been protected. 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 DR plan, click on the Apply button.

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

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

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

DR plan syntax

DR plan body is a JSON instruction for restoring infrastructure and business application in a backup DC.

Example of a Disaster Recovery 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 in a backup DC:

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

project_name -- a name of the OpenStack project, in which the cloud site will be launched. If the project does not exist, it will be created. By default, the name of the cloud site is used. The created projects will be deleted together with the cloud site:

{
"project_name":"acura_project"
}

Syntax of machine description

Machine description consists of a number of parameters describing machine properties, such as machine name, 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
id	Internal id of customer machine that is generated with DR 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
flavour	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 only)	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 only. 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 DR plan, the DR 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

Warning

Specified subnet_id must be available for the used Availability Zone.

Edit existing DR plan

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

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

DR plans testing

Protection from disaster is not limited to a one-time creation of a DR plan. It is necessary to constantly check its relevance and carry out regular DR strategy testing with a recommended frequency of once in every 3-4 weeks. The following steps would be enough in order to perform this check:

• create cloud sites from a DR plan with certain regularity;
• carry out a set of tests (these should be prepared as part of a DR strategy and adapted for a customer infrastructure; customer and DR service provider are mutually responsible for their preparation).

Upon receiving test results, a DR plan is adjusted accordingly (by adding descriptions of new machines, removing obsolete ones) and a troubleshooting sequence of the recovery process is performed in case of issues with the customer's business application. For example, there may be a blue screen (BSOD) when one of the machines is started.

Testing steps:

1. Update a DR plan.
2. Create cloud site from a current recovery point.
3. Run a set of tests in a running cloud site.
4. Update and adjust the DR plan, troubleshoot problems.

Implementation of these steps allows the customer to be prepared in advance for a disruptive event and minimize the related problems.

Recovery at the time of an accident

In case of an accident, start a cloud site (failover) to recover the working capacity of a business application on the backup site. Use the previously prepared DR plan as a recovery scenario.

A detailed description of recovery process configuration can be found in the section ACP - Recovery process.

Recovery process may require some time: its duration depends on the structure complexity of a DR plan and orchestration/dependency levels between components of a business application. As soon as all components receive an Active status, the business application is ready for operation, and it is possible to proceed to the next stage, which includes transferring the main traffic to the backup site and setting up individual components.

Warning

Redirecting the main traffic to a DC 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. Cloud sites description and the related settings are described in the section ACP - Cloud sites.

During DR strategy testing or after restoring the main site and reconciling the accumulated changes, it is recommended to remove redundant cloud sites so that they do not take up spare resources.

Failback to production

Once the main site is restored after an accident, it is commonly required to failback the business application to its origin with all the changes that have been accumulated on the backup platform since the launch of the cloud site, and redirect the user traffic accordingly.

The process consists of:

1. Downloading an agent with a prepared DR plan, running it in the production environment to download changes from the last recovery point.
2. Testing business application in a production environment.
3. Stopping machines in the cloud site to finalize the changes.
4. Downloading changes from the running cloud site to the new production.
5. Starting machines in the production and redirecting traffic accordingly.
6. Protection of the new production.

Once these steps are complete, a business application will failback to production with all the changes accumulated since the redirection of traffic to the backup site.

Failback process includes five (for the partner) or four (for the customer) steps. It starts from the Failback button of the menu

For the partner, the first step is to select a customer who requires a failback.

In the second step, select a cloud platform and a DR plan suitable for restoring your workloads - a scenario, describing the machines to be downloaded and created.

In the third step, select a target cloud for a failback. This field is mandatory. Select an existing platform or create a new one and click "Next" to proceed.

Depending on the selected failback type, there will be differences in the parameters that are required to add a new cloud.

Failback to VMware

To register a new cloud for the failback, the following fields have to be filled:

Field	Description	Example
Cloud name	The name of the cloud which will be shown in UI. The name must be unique	Failback cloud
Endpoint	Endpoint to connect to	192.168.5.2
Login	User login	user
Password	Password to access the target cloud	passw

In the fourth step, select a Cloud Site to failback from and failover machines for the failback process.

In the fifth step, use the "Download Agent" button to get the agent. The agent installed on a new environment is required to download the data from the running cloud site.

Alternativaly use Download Failback Agent item on Manage Clouds page to get the agent's file.

If the agent is installed, it will be displayed as online, and it will be possible to specify the target storage and host for the machine. After that, enter a failback name and click on the "Start Failback" button.

VMware Failback Agent requirements

Ports for correct agent work:

• Communicate with the Acura host - tcp/80, tcp/443

• vSphere host - tcp/443

• ESXi host(s) - tcp/udp/902

• Send logs to the Acura cluster - udp/12201

Failback process uses the same agent that is used for the replication process. But please note, there is a number of host permissions that the agent requires for a successful failback. For ESXi 6.0 and older, the list of permissions is as follows:

• VirtualMachine.Inventory.Create
• VirtualMachine.Inventory.Delete
• VirtualMachine.Config.Rename
• VirtualMachine.Config.UpgradeVirtualHardware
• VirtualMachine.Configuration.Add New Disk
• VirtualMachine.Configuration.Raw Device
• Resource.Assign VirtualMachine to Resource Pool
• Datastore.Allocate Space
• Network.Assign Network
• VirtualMachine.Interact.PowerOn
• VirtualMachine.Interact.PowerOff
• VirtualMachine.Config.AdvancedConfig
• VirtualMachine.Provisioning.DiskRandomAccess
• VirtualMachine.Provisioning.DiskRandomRead
• VirtualMachine.State.Create Snapshot
• VirtualMachine.State.Revert Snapshot
• VirtualMachine.State.Remove Snapshot
• VirtualMachine.Configuration.CPUCount
• VirtualMachine.Configuration.Memory
• VirtualMachine.Config.AddRemoveDevice
• VirtualMachine.Config.Settings

For ESXi 6.5 and higher, create a role with the following privileges:

• Datastore

  • Allocate space

• Global

  • Enable methods

• Network

  • Assign network

• Resource

  • Assign Virtual machine to resource pool

• Virtual machine

  • Change Configuration

    • Acquire disk lease
    • Add new disk
    • Advanced configuration
    • Configure Raw device
    • Toggle disk change tracking
    • Change CPU count
    • Memory

  • Edit Inventory

    • Create from existing
    • Create new

  • Interaction

    • Backup operation on virtual machine
    • Power off
    • Power on

  • Provisioning

    • Allow disk access
    • Allow read-only disk access
    • Allow virtual machine download

• Snapshot management

  • Create snapshot

  • Remove snapshot

  • Revert to snapshot

VMware Failback Agent installation

Deploy the failback agent to one of ESXi hosts and start it. Log in via the terminal to the user's account that was issued earlier during the agent download.

Custom DR plan parameters for VMware

Example of a VMware Disaster Recovery plan:

{
"devices": {
   "ubuntu-small": {
      "id": "52560751-12ca-9b0e-db00-02cb718a138a",
      "guest_id": "centos64Guest",
      "hardware_ver": "vmx-11",
      "flavor": "1-2",
      "rank": 0,
      "ports": [
      {
         "name": "port_0",
         "mac": "de:ad:be:ef:15:89",
         "subnet": "net"
      }
      ]
   }
},
"subnets": {
   "net": {
      "name": "net",
      "subnet_id": "VM Network",
      "cidr": "172.22.0.0/16"
   }
}
}

When compiling a recovery plan, a User can specify the following custom parameters: Guest operating system identifier and Hardware version. The respective lines would be "guest_id" and "hardware_ver" Since these parameters are inherent to VMware, please refer to their official documentation for the full list of approved types and versions:

• Enum - VirtualMachineGuestOsIdentifier
• Virtual machine hardware versions

Failback to Flexible Engine

To register a new cloud for the failback, the following fields have to be filled:

Field	Description	Example
Cloud name	The name of the cloud which will be shown in UI. The name must be unique	Failback cloud
Keystone API endpoint	Keystone authentication URL	http://controller.dts.loc:35357/v3
User domain	User domain name to access the target cloud	default
Username	Username to access the target cloud	user
Password	Password to access the target cloud	passw
Target project domain	Target project domain where failback workloads will be spun up	default
Target project ID	Target project ID where failback workloads will be spun up	39aa9af2e620404984f6d53a964386ef
Hystax Service VPC ID	VPC ID which will be used for Hystax failback machines	6a61f859-ad2c-4092-826f-ee2ed85a3ec9
Floating IP Network	External network which will be used to attach Floating IPs to migrated machines. Most Huawei clouds have “admin_external_net”	admin_external_net
Availability zone	Availability zone where all resources will be created	zone-1

Warning

In case of using DVS it is highly recommended to specify VCenter as Endpoint rather than an ESXi host. This is due to the use of the VCenter metadata service.

Please note that the user using for access must have the necessary access rights for DVS.

In the fourth step select a Cloud Site and one or several machines from the selected Cloud Site, you can also define a flavor, Subnet ID and static IP. Note that field "Subnet ID" is required.

The next step is to download the failback agent, deploy it to a target Flexible Engine cloud and check the failback configuration. After that, enter a failback name and click on the "Start Failback" button.

Alternativaly use Download Failback Agent item on Manage Clouds page to get the agent's file.

Flexible Engine Failback Agent requirements

Ports for correct agent work:

• Communicate with the Acura host - tcp/443

• Send logs to the Acura cluster - udp/12201

• Ports to communicate with the cloud API, e.g. tcp/5000 for keystone

Flexible Engine Failback Agent installation

Failback agent is downloaded as tar.gz file with a raw image inside. Extract the data from the archive and create a new image in the target project from the raw image of the Failback Agent. Create a new instance from the image and start it.

Note

Failback agent requires tcp/443 and udp/12201 to be opened in order to get access to the Acura Controller node.

Failback to OpenStack

To register a new cloud for a failback, the following fields have to be filled:

Field	Description	Example
Cloud name	The name of the cloud which will be shown in UI. The name must be unique	Failback cloud
Keystone API endpoint	Keystone authentication URL	http://controller.dts.loc:35357/v3
User domain	User domain name to access the target cloud	default
Username	Username to access the target cloud	user
Password	Password to access the target cloud	passw
Target project domain	Target project domain where failback workloads will be spun up	default
Target project ID	Target project ID where failback workloads will be spun up	39aa9af2e620404984f6d53a964386ef
Hystax Service Network	Network which will be used for Hystax failback machines	provider
Floating IP Network	External network which will be used to attach Floating IPs to migrated machines. Most Huawei clouds have “admin_external_net”	admin_external_net

In the fourth step, select a Cloud Site and one or several machines from the selected Cloud Site, you can also define a flavor, Subnet ID and static IP. Note that field "Subnet ID" is required.

The next step is to download the failback agent, deploy it to a target OpenStack cloud and check the failback configuration. After that, enter a failback name and click on the "Start Failback" button.

Alternativaly use Download Failback Agent item on Manage Clouds page to get the agent's file.

OpenStack Failback Agent requirements

Ports for correct agent work:

• Communicate with the Acura host - tcp/443

• Send logs to the Acura cluster - udp/12201

• Ports to communicate with the cloud API, e.g. tcp/5000 for keystone

OpenStack Failback Agent installation

Failback agent is downloaded as tar.gz file with a raw image inside. Extract the data from the archive and create a new image in the target project from the raw image of the Failback Agent. Create a new instance from the image and start it.

Note

Failback agent requires tcp/443 and udp/12201 to be opened in order to get access to the Acura Controller node.

Failback to other clouds

For other clouds, a failback is done in form of a live reverse migration of workloads to a source environment. Internal replication agents are installed directly on failover machines.

All replications happen in the background and do not require any failover downtime till the final cutover. You can run an unlimited number of test failbacks/migrations.

Please contact your service provider or Hystax to get a migration kit.