Hystax Disaster Recovery overview

Hystax Acura Control Panel

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

  • Customer page with an information display of the used resources, Disaster Recovery plans, cloud sites and machine groups
  • Cloud site page is an information display and a failover control panel
  • Wizards of machine protection, failback start and recovery
  • Notification page
  • Reports section with detailed information on system resources
  • Users management section with roles and permissions
  • Replication and recovery settings section

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 the 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, 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 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 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” 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 whether the solution is able use cloud APIs and actually work.

Note

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

Notification panel

image1

Notification panel informs users about certain events that need attention or require actions to solve issues with replication or recovery process. 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 that require 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.

Add new customer

To add a new customer, go to the Partner page and just click Add.

image2

Fill in the following required fields to add a customer: Company Name, Contact Email, Contact Phone, Address, Active checkbox (activity status of a customer and all their users).

image3

  • Company Name - customer’s company name, unique within the partner, will be displayed in the UI.
  • Contact Email - email address for communication with a customer’s representative on the solution usage and billing, unique within the partner.
  • Contact Phone is the telephone number of the customer’s representative.
  • Address
  • Active - shows whether the customer is active or not, this field affects the ability of customer users to use the system.

After clicking Save, the customer will be created and shown in the customer list. An admin user for the customer is created with the default password, which will have to be changed at the first login. When a customer is created, it is advisable to proceed to the infrastructure protection sequence.

Custom replication agent settings

Applying custom settings can be essential for organizing an operational environment if there is a proxy server between Acura and the machine to be replicated or, for example, there is supposed to be a different endpoint IP for each customer.

Providing custom replication agent settings is available for every new customer that is being added to the ACP. Tick the checkbox next to Use custom replication agent settings to access the following fields.

custom_settings

Attention

Agent settings can no longer be modified through the UI, once a Customer has been successfully created.

Replication agent endpoint IP is an IPv4 address that will be used by this customer’s replication agents to connect, send data and RestAPI calls to Acura. Replication agent endpoint certificate is required in case of a proxy server in-between the components to verify security of an HTTPS connection. Input as an SSL certificate in PEM format for the replication endpoint IP (proxy server). Replication agent logging IP is a custom IPv4 address for sending logs. Replication Agents that are downloaded for the customer will use this IP as Logstash IP. The field will usually contain the same address as the Replication agent endpoint IP.

Edit existing customer

To edit an existing customer, click on the Edit button to the right of their name.

image4

A dialog window with filled in customer data will appear. Make the necessary changes and click Save, after that the customer data will be updated.

image5

Customer page overview

image6

The customer page 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 Disaster Recovery plans with the ability to manage them
  8. Groups of machines
  9. Notification panel displaying full customer status
  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, fill in the required fields. Cloud type drop-down list provides the type of the cloud to which the solution is deployed.

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 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 values from the cloud side.

Note

Network setting for Azure cloud has the following format - “<network_name>/<subnet_name>”

Cloud sites

image7

Cloud Site (Section: ACP - Cloud Sites) is a failover instance of customer business application that runs in a backup data center. Customer page allows viewing of statistics on cloud sites and performing actions on them as well, e.g. deleting cloud sites if they are no longer needed or changing their settings.

Disaster Recovery plans

image8

Customer page allows creating, viewing and editing Disaster Recovery plans (Section: ACP - Disaster Recovery plans). Disaster Recovery plan includes an infrastructure description and instructions that must be followed to recreate a business application in a backup data center in case of emergency. DR plan is created in advance on the basis of a productive infrastructure, tested by running test cloud sites, maintained up-to-date by periodic updates and transferred to the recovery process in case of disaster.

Machines and actions over them

image9

Customer page displays the machines that are discovered (located in VMware vSphere, where Hystax Acura agents are installed) or protected 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 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 protected on VMware vSphere, these will be added to the set-up group for the agent (Section: ACP - Machine Protection 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 names 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

Protect new machines

To protect new machines, use the protection process(Section: ACP - Protect). In case of VMware vSphere, once the agents have been installed, the machines will appear in the list in the unprotected state. Select the desired 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 protected 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 settings & 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

Schedule 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 settings 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.

Edit retention policies

Retention policies give the ability to set a number of restore points that will be stored in the target cloud as well as the amount of time before restore points are automatically deleted.

It is possible to edit retention policies on the level of separate machines, groups, or as general settings.

image22

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 edit settings click Edit retention policies in the Actions menu (for separate machines),

image23

in the menu of separate groups

image24

or in the general settings menu of Machines Groups

image25

To edit retention policies, set the storage period and number of snapshots to be retained:

  • keep last restore points - the amount of restore points to be retained.
  • daily restore points (days) - a number of days during which only the last restore point will be retained. After this period of time, they will be transformed into weekly restore points.
  • weekly restore points (weeks) - a number of weeks that will have only the last restore point per week retained. After the specified time, the restore point will be passed to the monthly retention.
  • monthly restore points (months) - a number of months during which only the last restore point will be retained, after this period of time they will be transformed into one per year restore points.
  • annual restore points (years) - a number of years that will have only the last restore point per year retained. After the specified time, the restore point will be snapped off the system to save space.

Note

Retention job runs as soon as a new replication takes place and uses UTC time to clean up the data.

Note

Please consider that to calculate the maximum number of restore points retained for each machine, add up all the values from each retention field - keep last restore points, daily, weekly, monthly and annually. Use the following retention scheme to only keep the one last RP for each machine - 1-0-0-0-0

A short example to illustrate how it works:

Assuming a customer has the following retention settings and schedule set to 1 hour:
  • Keep last restore point - 3
  • Daily - 2
  • Weekly - 2
  • Monthly - 1
  • Annually - 0

This means that retention will keep three last restore points created today. One restore point will be kept for each of the two previous days (Daily restore points). One restore point will be kept for each of the two previous weeks (Weekly restore points). One restore point will be kept for the previous month (Monthly restore points).

Generate DR plan from Machines Group

It is possible to generate a DR plan for an individual machine, a group or based on general settings. To generate a DR plan from Machines Group for several machines or groups, select the desired machines and click Generate DR plan in the Action menu.

image26

in the menu of groups

image27

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

image28

To generate a DR plan from Machines Group, click Generate DR plan from Machines Group on the DR plan creation page (Section: ACP - Disaster Recovery plans).

Edit VMware vSphere settings

To replicate machines from VMware vSphere, Hystax Acura uses VMware CBT API, which only needs a VMware vSphere login and password to be accessed. To edit login / password on VMware vSphere, update the settings on Hystax Acura 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 the appropriate VMware vSphere platform and proceed to edit the settings. After this, 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.

Disaster Recovery plans

image32

Disaster Recovery Plan is a description of the infrastructure and a set of necessary instructions used to recreate a business application in a DC in case of disaster. The DR plan is created in advance on the basis of a productive infrastructure, tested by running cloud sites, maintained up-to-date by periodic updates and transferred to the recovery process in case of disaster.

A customer can create any number of Disaster Recovery plans: one for restoring the entire infrastructure or several with a breakdown into groups of machines, departments, machines roles for the Disaster Recovery plan, etc.

To restore (Recovery Process), select one or several Disaster Recovery plans to be implemented during cloud site creation (Section: ACP - Cloud Sites).

Disaster Recovery plans must always be kept up-to-date, as additional time may be required to update the plan after an accident, so the downtime of the infrastructure and the business application will increase accordingly.

Create a Disaster Recovery plan

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

image33

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

image34

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.

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.

image35

The menu item in the group properties.

image36

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",
     "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 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 target machine. (Openstack, Huawei only) 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 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
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 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

Attention

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.

image37

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

image38

Cloud sites

Cloud site is a customer business application running in a backup DC that consists of network infrastructure components included into the business application.

image39

The main elements 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 the type and condition of the cloud site
  5. List of the running machines with the ability to manage them

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

User and general solution settings

Access to user and solution settings is offered through the menu item Settings in the upper right corner.

image49

Attention

Depending on user’s rights and permissions, 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 the 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

image53

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 a role (already existing or newly created) just change 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.

Company settings management

This option is only available if the current user has been assigned with a role that can manage company settings. This page allows editing of fields for the current user’s company. Fields available for editing:

  • Company Name – name of customer’s company, this information will be displayed in the UI.
  • Contact Email – email for communication with a customer’s representative on the solution usage and billing.
  • Contact Phone – customer’s representative telephone number
  • Address - customer correspondence address

Protecting machines

To protect a machine, click Protect 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 protection process consists of four (for partner) or three (for customer) steps.

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

image59

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

image60

The next step is to select:

  • Group to which the protected 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. Select machines to protect and click Start replication in the Actions menu.

image15

Recovery process

Hystax Acura provides several ways to get replicated machines up again:
  • run regular failover on the target cloud
  • download an image of the failover instance
  • download a RAW image of the replicated machine

Cloud Site creation

To start a recovery process during failover testing or in case of disaster, click Run Recover on the customer page with DR plans selected.

image62

or Recover in the main menu.

image63

Recovery process consists of three (for partner) or two (for customer) steps.

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

image64

Next step is to select DR plans (Section ACP - DR plans) which will be used to carry out the recovery process. Here, it is possible to create a customized DR plan - in case DR plans have not been updated for a while and there is no time at the moment to update all current plans according to the latest changes.

image65

Attention

If several DR 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 the cloud site start, which can lead to unpredictable behavior.

The last step, while restoring to a backup DC, consists of filling in the cloud site name, recovery point (point to which an infrastructure should be restored) and a final validation / modification of a DR 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, special symbols “-“, “_” and “.”.

Recovery 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.

image66

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

The Cloud Site page will be opened to monitor the machines statuses and information.

image39

Failover image download

Another option that becomes available to the customer once a Cloud Site for the selected machines has been established, is a failover image download. This is a favorable feature as it gives access to the immediate RAW images currently used in the CS. And since RAW is a universal format, the downloaded images can later be used to recreate instances on any hypervisor. The dedicated Cloud Site section of the ACP will be updated as soon as a new CS comes online. Wait until the state of the desired CS switches to “Running” and click on its Name.

image67

You will be forwarded to the information page of the selected CS, which lists all the included instances. Click on the green “Download” button to the right of the desired machine’s name to save its image to your computer. An expiration period for the download links needs to be chosen next, and it might take some time for them to be generated. This process can be done in the background however. So closing the window and accessing the links later might a a reasonable option.

image68

Image Download of Replicated Machine

This feature allows obtaining of a RAW image of the replicated machine from some particular restore point. Retrieved RAW image can be converted with any regular convertor to any required format due to its universality.

Once a machine is protected, use ‘…’ to click “Download machine image” in the UI. The action is available for each machine separately.

image_download_btn

The opened dialog provides options to select a restore point and set a link expiration period.

image_download_dialog

Link expiration periods may be the following:
  • 3 hours
  • 6 hours
  • 12 hours
  • 24 hours
  • 48 hours

A new expiration period starts from the time the link was last used. The process might take a few minutes, and since the links are generated in the background, the dialog can simply be closed. When the link is ready, the following icon appears next to the machine:

image_download_icon

Failback to production

When the main platform is restored after a disaster, 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 the 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.

To start a failback, click on the menu item Failback on the left sidebar.

failback_main_menu

Failback process includes four (for the partner) or three (for the customer) steps.

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

failback_step1

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.

failback_step2

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:

failback_vmware

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.

failback_vmware_cs

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.

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.Interaction.Power On
  • 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. Refer to Install VMware agents for detailed instructions.

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:

Failback to Flexible Engine

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

failback_FE

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

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

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

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.

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:

image5

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.

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

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.

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.

Reports

Hystax Acura provides 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 the stats scope to a specific time range.

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

Machine State Report

Machine state report provides information about changes in the number of protected / unprotected / parked machines within a specific time frame.

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 time frame, 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.