Hystax Live Migration to AWS OR KVM Platform Overview

Hystax Acura Control Panel

Hystax Acura Control Panel (ACP) is a web-application for managing HLMAK solution. The main components of the ACP are:

  • Customer page with an information display on the used resources, Migration plans, cloud sites and machine groups;
  • Cloud site page is an information display and a management panel for a running migration;
  • Wizards of machine replication and migration;
  • Notification page;
  • Users and roles management section;
  • Replication and recovery settings windows.

Recommended browsers: Google Chrome, Mozilla Firefox, Safari.

Partner page overview

image0

The partner page contains the following information:

  1. Resource management and functionality menu
  2. Management of target clouds
  3. Statistics on the number of partner’s customers
  4. Total number of customer machines
  5. Number of cloud sites launched by partner’s customers
  6. List of customers with statistics decomposition for each customer
  7. Functionality for adding new customers or editing information about existing ones (Section: ACP - Adding new customers)
  8. Notification panel displaying summary status about customers
  9. Page description

There is a default cloud, created during initial configuration of the solution, but it’s also possible to create additional clouds and assign them to customers. This provides multitenancy to partners.

Click on the “Manage Clouds” button on the Partner page and then “Add”.

add_cloud_dialog

In order to add a cloud, you need to fill in the required fields.

Field Description Example
Cloud name The name of the cloud that 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 failover workloads will be spun up default
Target project ID Target project ID where failover workloads will be spun up 39aa9af2e620404984f6d53a964386ef
Hystax Service Network Network which will be used for Hystax failover machines provider
Floating IP Network

External network which will be

used to attach Floating IPs to

migrated machines. Most Flexible Engine

clouds have “admin_external_net”

admin_external_net
Additional parameters

Other additional parameters in JSON

format, for example:

{“parameter”:”value”}

{“availability_zone”: “zone-1”}

Clicking “Save” starts the validation of the new cloud. During this process, test cloud volume and test Cloud Agent are created on the target cloud to check that the solution can use cloud APIs and actually work.

Note

Network setting for Azure cloud will have the following format: “<network_name>/<subnet_name>”

Customer dashboard overview

image6

The customer dashboard contains the following information:

  1. Resource management and functionality menu
  2. Number of customer cloud sites
  3. Number of groups of machines (Section: ACP - Machine Group Management)
  4. Total number of customer machines
  5. List of running cloud sites with the ability to manage them
  6. List of running failbacks with the ability to manage them
  7. List of Migration plans with the ability to manage them
  8. Groups of machines
  9. Notification panel showing the total status of customer replication and migration processes
  10. Page description

Click on the “Manage Clouds” button on the Partner page and then “Add”.

add_cloud_dialog

In order to add a cloud, you need to fill in the required fields. Cloud type drop-down list provides the type of cloud to which the solution is deployed.

Field Description Example
Cloud name The name of the cloud that 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 failover workloads will be spun up default
Target project ID Target project ID where failover workloads will be spun up 39aa9af2e620404984f6d53a964386ef
Hystax Service Network Network which will be used for Hystax failover machines provider
Floating IP Network

External network which will be

used to attach Floating IPs to

failover machines. Most Flexible Engine

clouds have “admin_external_net”

admin_external_net
Additional parameters

Other additional parameters in JSON

format, for example:

{“parameter”:”value”}

{“availability_zone”: “zone-1”}

Clicking “Save” adds a record about a new cloud to the solution database, but does not validate any of the set value from the cloud side.

Note

Network setting for Azure cloud will have the following format: “<network_name>/<subnet_name>”

Notification panel

image31

Notification panel informs users about issues with replication or recovery process that require their attention. ACP uses the following color scheme:

Green color of the panel means that customers do not have issues requiring immediate intervention.

Yellow color of the panel means that there are issues requiring attention/solution in the near future. For example, a machine is out of free space, a machine has been unavailable for several days.

Red color - immediate action is required. For example, several unsuccessful consecutive replications of a machine, lost connection to a replication agent, etc.

Cloud sites

image7

Cloud Site (Section: ACP - Cloud Sites) is a running migration of a customer’s business application that works on AWS or KVM Platform. Customer page allows viewing of statistics on cloud sites and performing actions on them as well, e.g. deleting cloud sites if there are no longer needed or changing their settings.

Migration plans

image8

Customer page allows creating, viewing and editing Migration plans (Section: ACP - Migration plans). This plan includes an infrastructure description and instructions that should be performed to recreate a business application on AWS or KVM Platform during a migration process. A Migration plan is created in advance on the basis of a productive infrastructure, tested by running test cloud sites, and implemented for a final migration.

Machines and actions over them

image9

Customer page displays the machines that are discovered (located in VMware vSphere, where Hystax Live Migration to AWS or KVM Platform agents are installed), or replicated by the solution. Machines can be grouped by various criteria: geographic location of the machine, general snapshot storage policy or replication schedule, etc. A customer can edit individual machines, groups and global settings in general.

Settings are as follows:

  • By default, global settings are applied to all groups and machines.
  • Upon editing group settings, the new settings are applied to all machines (in the group or the ones added later) with the default settings, otherwise, the settings of individual machines will still be valid.
  • Upon editing the settings of a machine, only the one specific machine is affected, otherwise, group settings or global settings apply.

When using automatic detection of machines that need to be replicated on VMware vSphere or installing an internal agent on a machine, these machines will be added to the set-up group for the agent (Section: ACP - Machine Replication Process).

Add new machine group

To add a new group, go to Machines Groups and just click Add.

image10

A dialog window with filled in customer data will appear. Fill in the group name and its description. Group name should be unique within a customer.

image11

After clicking Save, the group will be created. It will appear on the customer page.

Initially, there is a Default group for each customer, which cannot be deleted. It is highlighted by the corresponding symbol next to its name in the list of groups. The default group cannot be changed.

Remove and rename groups

To remove or rename a group, select appropriate items in the group menu:

image12

Default group cannot be removed, only renamed.

Move machines between groups

To move machines between groups, select machines in groups and click “Move to another group” in the “Actions” menu.

image13

As the result, a dialog window with filled in customer data will appear. Select an appropriate group.

image14

Replicate new machines

To replicate new machines, use the replication process (Section: ACP - Replicate). If the machines are running on VMware vSphere and the agents on vSphere have been started, the list of machines will show them as Not replicated (the machines are included in the main group for the agent). Select the machines and click Start replication in the Actions menu.

image15

The machines will begin to replicate according to the schedule settings (Section: ACP – Replication schedule).

Sync machines replications

To sync a machines replication, mark the machines which should be replicated simultaneously and click Start replication in the Actions menu. Replication of all selected machines will start and then they will be replicated in parallel.

image16

Park / unpark replication

To park / unpark a replication, select machines from different groups and click Park in the Actions menu. This action stops the agent’s replicating task for the machine. No further replications will be started by schedule for the machine.

image17

To unpark a replication, click Start replication in the Actions menu. A new replication will start for the machine.

Edit replication schedule

It is possible to edit replication schedule for separate machines, groups, or as general settings.

Note

Before the first replication is initiated, two additional parameters can be specified for each machine: Volume availability zone and Volume type.

  • Selecting an availability zone will explicitly determine the desired physical location of a data center for the given volume. Type in a valid abbreviation or acronym that is in use by the cloud platform itself, usually listed in its supporting documentation or at the volume creation step.
  • Volume type can be specified as a comma-separated string of disk types, e.g. “SSD, SATA”. Redundant commas and whitespaces are ignored. If a machine has more disks than the number of specified disk types, the last disk type will be used for all of the remaining disks. This way, if a machine has 5 volumes, the first volume will have “SSD“ type, and the remaining ones will have “SATA“. HDD will be used by default if no other settings are provided. Check with your cloud platform to input the correct names of volume types.

After the initial replication is completed, the additional parameters will become inaccessible. Modifying them is only possible before a new full replication.

image18

Settings are as follows:

  • By default, global settings are applied to all groups and machines.
  • Upon editing group settings, the new settings are applied to all machines (in the group or the ones added later) with the default settings, otherwise the settings of individual machines will still be valid.
  • Upon editing settings of a machine, only the one specific machine is affected, otherwise, group settings or global settings apply.

To change the settings, click Edit replication schedule in the Actions menu (for separate machines),

image19

in the menu of separate groups

image20

or in the general settings menu of Machines Groups.

image21

There are two options for a schedule:

  • Interval schedule - replication occurs at equal intervals of time. For example, every 15 minutes or every 6 hours. This option is ideal for non-critical elements of a business-application, so it does not seriously affect the performance of the system and does not load the network.
  • Continuous replication - a new replication starts immediately after the completion of the previous one. It is ideal for critical components, such as databases and mail services.

Attention

A minor impact on the performance of the machine and the network through continuous replication can be found with continuous replication. Please note that this option will generate a bulk of snapshots on a target cloud. Please check snapshot pricing before enabling this option.

Generate Migration plan from Machines Group

It is possible to generate a Migration plan for an individual machine, a group or for all available machines at once. To generate a Migration plan for several machines or groups, select the required machines by ticking their checkboxes and click Generate Migration plan in the Action menu.

image26

in the menu of groups

image27

As the result, a dialog window for creating and editing a Migration plan will appear - give it a name that is unique within the customer.

image28

To generate a Migration plan from Machines Group, click Generate Migration plan in the group settings menu (Section: ACP - Migration plans).

Edit VMware vSphere settings

To replicate machines on VMware vSphere, Hystax Live Migration to AWS or KVM Platform uses VMware CBT API, which only needs a VMware vSphere login and password to be accessed. To edit login / password on VMware vSphere, update settings on Hystax Live Migration to AWS or KVM Platform to continue. For that, use the edit settings of VMware vSphere form, which is available through the appropriate menu item in the global settings of the machine.

image29

Select an appropriate VMware vSphere platform and proceed to edit the settings. After that, the agents will automatically receive updated settings and continue the replication. The platform name must be unique within the customer.

image30

Notification panel

image31

Notification panel informs users about issues with replication or recovery process that require their attention. ACP uses the following color scheme:

Green color of the panel means that customers do not have issues requiring immediate intervention.

Yellow color of the panel means that there are issues requiring attention/solution in the near future. For example, a machine is out of free space, a machine has been unavailable for several days.

Red color - immediate action is required. For example, several unsuccessful consecutive replications of a machine, lost connection to a replication agent, etc.

Migration plans

Migration plan is a description of the infrastructure and a set of necessary instructions used to recreate a business application on a target cloud. Migration plan is created in advance on the basis of a productive infrastructure, tested by running cloud sites and transferred to the migration process.

A customer can create any number of Migration plans: one for migrating the entire infrastructure or several with a breakdown into groups of machines, departments, machine roles, etc.

To perform a migration, select one or several Migration plans to be implemented during cloud site creation (Section: ACP - Cloud Sites).

Create a Migration plan

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

image33

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

image34

The body of a Migration plan is a JSON instruction for spinning up of the infrastructure and the business application in a DC. To generate a plan based on all customer machines, click on the link Generate Migration plan from all 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.

image35

The menu item in the group properties.

image36

Migration plan syntax

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

Example of a Migration plan:

{
"machines": {
    "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:

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

{
"machines": {
    "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"
    }
  }

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, 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",
      "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 migration plan pre-generation. Can also be found by moving 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 description has the following parameters:
Parameter Description Required parameter
name interface name Yes
ip interface IP address 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”: “<IP_address>” will assign a specific external IP to the migrated machine. (only available for OpenStack and Huawei clouds)

No

Example:

"ports": [
 {
     "name": "port_0",
     "ip": "192.168.15.100",
     "subnet": "main_subnet"
 }
 ]
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_condition

Condition in which 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 stays for 2vCPU and 4GB RAM Example: “flavor”: “2-4” Yes
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 installed cloud_init, otherwise, it will be ignored. This key can be used only for OpenStack target cloud. No
firmware (VMware 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

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.

image37

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

image38

Cloud sites

Cloud site is a customer business application running on AWS or KVM Platform that consists of network infrastructure components included into the business application.

image39

The main components of the page are:

  1. Resource Management and Functionality menu
  2. Total number of machines running in the cloud site
  3. Functionality for editing site name and removing the site
  4. Information about type and condition of the cloud site
  5. List of running machines with the ability to manage them

To run a cloud site, start the Migration Process (Section: Migration Process).

When a machine is ready to be used for production and work independently from the Acura cluster, use the Detach button.

detach_btn

User and solution settings

Access to the user settings and solutions is done via the menu item Settings in the upper right corner.

image49

Attention

Due to the current user’s rights, the set of available options may vary.

The window with the settings:

image50

User settings

image51

The password and user’s full name can be edited on the page of the current user’s settings. .. attention:

Once modified, the settings automatically take effect, and you will be asked to enter updated data in order to perform a new login.

User management

This option is available only if the current user has been assigned with a role that can manage users. Management is possible only by users of the same hierarchy level and below, so that a user of a customer account wouldn’t be able to view and edit users of another customer and partner.

This page is used for to adding / removing users, assigning roles for specific resources, changing the activity of current users, resetting their passwords to new values and changing user data, such as full name.

image52

Create users

To create a new user just click Add user.

image53

As the result, a dialog window will appear. Fill in the information about a new user and user’s Organization (partner or customer).

Assign roles

Role assignment determines which rights the user will have in a particular role action area (specific partner, customer, customer machine group). If an administrator role is created and assigned to a specific customer, the user will have administrator rights over those customer resources.

Once assigned, the selected user receives a certain role for a specific scope of expertise / resource. Click Assign Role and select Role and Scope.

If a user has appropriate rights, they can assign roles according to their scope and only within that scope.

Created assignment takes effect automatically from the moment it was created.

Roles management

This option is only available if the current user has been assigned with a role that can manage roles. Partner users have access to partner roles, customer users have access to customer roles as well as roles shared with them by their partner. To assign roles to specific users click User management.

This page allows to add / remove roles, edit a set of rights for each role and change the flag of their activity.

image54

Add a role

image55

To add a role, fill in its name and description and select a role template (set of permissions, possible options: root, partner, customer, group) that manages the set of permissions, and the organization that will own the role and where it will be available for assigning.

Attention

If the user has appropriate rights during role assignment, they will be able to view roles within the organization - role owner.

It is also necessary to tick the checkbox Share the role with customers if the role is supposed to be available to partner’s customers.

Manage a set of permissions

To manage a set of permissions for role (already existing or newly created) just manage the status of the checkboxes for each permission.

image56

A ticked checkbox means the action is permitted; an empty checkbox means the action is banned. Therefore, a selected checkbox in one of the roles and its assignment to the scope grant permission for a particular action within this scope in spite of the fact that it can be removed in other roles assigned to the scope.

Attention

Editing existing roles will change the list of rights for users to whom this role has already been assigned. When a role is created and permissions are set, it can be assigned to users through the User management tab.

Replicating machines

To replicate a machine, click Replicate new platform in the Group settings menu

image57

or Download agents in the main menu of the web interface.

image58

Depending on whether a user is authorized as partner or customer, a replication process consists of four (for partner) or three (for customer) steps.

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

image59

The second step is to select an agent type depending on the platform to be replicated - VMware, Linux or Windows:

image60

The next step is to select:

  • Group to which the replicated machines will be included by the agent.
    • VMware vSphere platform. Fill in its description and login / password; or select an existing platform from the list. Parameters of protected DR platforms can be edited in the menu of global customer’s settings (Section ACP - Edit settings of VMware vSphere).

image61

The last step is to download the agent.

After downloading and installing the agent, all machines from vSphere will automatically appear in the UI in the machine group specified in the second step. Machines will be in Unprotected state.

image62

Select machines to replicate and click Start replication in the Actions menu.

image15

Migration process

To start migration process during failover testing or in case of disaster click Run Migration on the customer page with selected Migration plans

image62

or Migration in the main menu.

image63

Migration process consists of two steps.

The first step is to select a Migration plan (Section ACP - Migration plans) that will be used to carry out the migration process. Here, it is possible to create a customized Migration plan - in case Migration plans have not been updated for a while.

Attention

If several Migration plans contain descriptions of the same resources, the next step will not be available until the conflict is resolved by changing one of the plans. This is done to prevent collisions during cloud site start, which can lead to unpredictable consequences.

image66

The last step while spinning up an infrastructure on AWS or KVM Platform consists of filling in the cloud site name, restore point (point to which an infrastructure should be restored) and a final validation / modification of a Migration plan and a brief description of a future cloud site. Cloud site name must be unique within the customer and contain only Latin letters, numbers and special symbols “-“, “_” and “.”.

image67

Restore point is a point in time to which a business application will be restored. For each machine, the replicas closest to the specified point in time will be used.

To run a cloud site for migration, start machines and configure them in accordance with the final Migration plan click Run Migration.

image39

Reports

Hystax Acura provides with a sophisticated set of reports on various components usage. Partners and customers can get information on the state of machines and Cloud Sites statistics.

Partners can get statistics for a specific customer or for all customers. Customers can get statistics applicable to them.

Start and End date controls are available to limit stats scope to a specific time range.

Export to CSV is available in case a further data analysis is necessary.

MSP Report

MSP report provides information about a protected machine within a specific timeframe, showing consumed licenses. You can find the list of machines that used product licenses.

Export to CSV is available in case a further data analysis is necessary.