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

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 - Add new customer)
8. Notification panel displaying summary status about customers
9. Page description

Manage Target Clouds

Acura provides an ability to manage target clouds, the cloud to which customer devices will be replicated. This provides multitenancy to partners. Just click on the Manage Clouds button on the Partner's page.

The target cloud page has a number of options for working with this type of cloud:

• to create a new target cloud
• to edit an existing cloud
• to revalidate a cloud
• to delete an existing cloud

Add Target Cloud

Just click Add button on the Target clouds panel.

Specify the cloud type to which the solution is deployed, fill in all the fields by providing cloud configuration details. Use question mark icons to get hints on the fields.

Below we'll take a closer look at the field Replication storage type, for a more detailed description of the basic parameters, visit Initial product configuration page. See step 3 of the Installation steps of an appropriate cloud type.

The Replication storage type field contains a list of supported storages for replicated data. Use Cloud-native block storage when implement a migration or a disaster recovery scenario, S3-compatible storage, Unix share (NFS) or Windows share (SMB/CIFS) - for a backup scenario.

There is no need to specify additional parameters when select Cloud-native block storage. The data is stored on the target cloud.

When select S3-compatible storage, Unix share (NFS) or Windows share (SMB/CIFS), the data is stored in the external third-party storage. There is a set of parameters that should be specified for each type of storage.

A new cloud is listed and validated after saving. As soon as the validation is passed the status is set to .

Edit Target Cloud

Select the Edit menu item from the Actions drop-down menu. The Edit Cloud panel is similar to the Add Cloud except the Cloud type and the Replication storage type fields are disable for editing.

For a more detailed description of the basic parameters, visit Initial product configuration page. See step 3 of the Installation steps of an appropriate cloud type.

Note

Specify the password before save.

The validation process starts just after saving. A new cloud will be listed and validated after saving. As soon as the validation is passed the status is set to .

Revalidate Target Cloud

Validation process starts automatically after the cloud is created or edited. However, there is an ability to start this process manually. Just select Revalidate from the drop-down menu. During this process, test cloud volume and test Cloud Agent are created on the target cloud to check whether the solution is able to use cloud APIs and actually works. A new cloud will be listed and validated after saving. As soon as the validation is passed the status is set to . Otherwise, the status shows the reason why the validation is failed. Fix it and revalidate.

Delete Target Cloud

Additionally, the ability to delete target clouds has been implemented. For this purpose, the Delete command has been added to the drop-down list of actions.

Warning

A deleted cloud cannot be restored.

Notification panel

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.

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), etc.

• Active - shows whether the customer is active or not, this field affects the ability of customer users to use the system.
• 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
• Time zone - time zone to use for replication scheduling
• Cloud - target cloud.
• Target project ID - target project ID where replicated loads will be spun up.
• Use custom replication agent settings - off by default.
• Enable replication traffic compression - when on this might save a lot of network bandwidth. Checked by default.
• Additional parameters - other additional parameters in JSON format.
• Mountpoint overlay - overrides default mountpoint in JSON format.

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.

Warning

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.

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.

Customer page overview

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 - Machines and actions over them)
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 file and folder connections with the ability to manage them
8. List of Disaster Recovery plans with the ability to manage them
9. Groups of machines
10. Notification panel displaying full customer status
11. Page description

Manage Source/Failback Clouds

Acura provides an ability to manage source/failback clouds. Just click on the customer and press the Manage Clouds button on the Customer's page.

The source/failback cloud page has a number of options for working with this type of cloud:

• to create a new source/failback cloud
• to download failback agents for VMware/OpenStack/Flexible Engine or replication agents for VMware/oVirt cloud
• to edit an existing cloud
• to delete an existing cloud

Add Source/Failback Cloud

Just click Add button on the Source/Failback Clouds panel.

Specify the cloud type to which the solution is deployed, fill in all the fields by providing cloud configuration details. Use question mark icons to get hints on the fields.

For a more detailed description of the basic parameters, visit Initial product configuration page. See step 3 of the Installation steps of an appropriate cloud type.

A new cloud is listed after saving.

Edit Source/Failback Cloud

Select the Edit menu item from the Actions drop-down menu. The Edit Cloud panel is similar to the Add Cloud except the Cloud type field is disable for editing.

For a more detailed description of the basic parameters, visit Initial product configuration page. See step 3 of the Installation steps of an appropriate cloud type.

Note

Specify the password before save.

The cloud is ready to go.

Download Failback/Replication Agent

To download Failback or Replication Agent click on the approptiate item of the drop-down list. Pay attention that this feature is available for Failback Agents for VMware/OpenStack/Flexible Engine and Replication Agents for VMware/oVirt clouds only.

Note

Downloading process takes some time.

Failback Agents installation instructions:

• Failback to VMware
• Failback to Flexible Engine
• Failback to OpenStack

Replication Agents deploying instructions:

• Deploying VMware Agent
• Deploying oVirt Agent

Delete Source/Failback Cloud

Additionally, the ability to delete source/failback clouds has been implemented. For this purpose, the Delete command has been added to the drop-down list of actions.

Warning

A deleted cloud cannot be restored.

Cloud sites panel

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 panel

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

Customer page displays the machines that are protected by the solution.

When detected, new machines are placed in a group that is created by default and marked accordingly.

The solution provides the ability to create, rename and delete groups, as well as move machines between groups, grouping them by various criteria: geographic location of the machine, general snapshot storage policy or replication schedule, etc.

In addition, it is possible to start/pause protection, change replication parameters, view information about recovery points, download machine image, attach disks, restore files and folders, generate dr plans, and delete machines.

All or some of the settings described above are included in the global, group, selected machines or single machine settings menu.

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 selected machines, only the selected specific machines are affected, otherwise, group settings or global settings apply.

• Upon editing the settings of a machine, only the one specific machine is affected, otherwise, group settings or global settings apply.

Groups actions

Protect new machines

Generate DR plan from Machines Group

Groups actions

Initially, there is a Default group for each customer. The Default group, which includes all machines that have not been added to other groups, is created automatically. It is highlighted by the corresponding symbol next to its name in the list of groups. The default group cannot be deleted.

Add new machine group

To add a new group, go to Machines Groups and just click Add Group. Fill in the group name and its description. Group name should be unique within a customer.

It is possible to add any number of groups. By default, each group inherits global settings for a replication schedule and snapshot retention policies of a customer. Editing group settings will be described below. Note that group name must be unique within the customer.

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

Remove and rename groups

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

Note

The default group cannot be deleted.

Move machines between groups and customers

An ability to move machines between groups and customers is implemented:

• transfer machines manually between groups is available through the menu "Move to another group"

• transfer machines manually between customers

• transfer machines automatically between customers for a VMware case

Transfer machines manually between groups

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

Moving machines between groups is available through the "Move to another group" item in the selected machines or a single machine actions menu.

Select the group from the list and save your selection. Note that if replication schedule and snapshot storage policies have not been redefined exclusively, the new group's parameters will apply after transfer.

Transfer machines manually between customers

Additionally, there is an ability to transfer machines between groups of customers. To do this, just on the "Show groups of other customers" checkbox, select the group and save changes.

Warning

Moving to groups from other customers is a risky action. This can interfere with and potentially break machines that are already replicated. Please, ensure you're aware of the implications before proceeding.

Warning

A machine must not have any restore points.

Transfer machines automatically between customers for a VMware case

If you want to move a large number of VMware machines located on the same host, use the automatic transfer feature.

To do this, deploy a new replication agent configured for the new customer on the host. Then delete the old customer from Acura. The machines will automatically appear in the new customer's machine list.

Note

If the old customer is not deleted, the machines will still be in its list. However, machines that join the host after installing the new replication agent will appear in the list of the machines of the new customer.

Operations for working with replications

Edit Replication schedule

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

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

in the menu of separate groups

or in the general settings menu of the Machines Groups.

There are several 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.

Warning

A minor impact on the performance of the machine and the network through continuous replication can be found with continuous replication.

• Daily - replication is done daily at the specified time (multiple values can be specified).
• Weekly - replication is done weekly. It is required to specify the numbers of weeks in the month (or all weeks), days of the week and a specific time. Multiple values can be specified for all parameters.
• Monthly - replication is done monthly. It is required to specify the numbers of days in the month and a specific time. Multiple values can be specified for all parameters.
• Cron (expert) - schedule in cron format.

Additional parameters

There are additional parameters that can be set before first replication. The list of additional parameters depends on the cloud type.

Additional parameters for AWS, CROC, Flexible Engine, and OpenStack clouds

Field	Description
Volume availability zone	Override the default availability zone for replicated volumes. 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	Override the default volume type for replicated volumes. It 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.

Additional parameters for oVirt

Field	Description
VM name postfix	Set custom name postfix to avoid name collision with already existing VMs
Storage domain	Override the default storage domain
Target data center	Override the default data center
Target cluster	Override the default cluster
Target host	Override the default host
Allocation policy	Allocation policy for disks: target cloud default, sparse/thin provision or preallocated
Disk format	Override the default disk file format: target cloud default, qcow2, raw

Additional parameters for VMware

Field	Description
VM name postfix	Set custom name postfix to avoid name collition with already existing VMs
VM hardware version	Override the default VM hardware version, example: vmx-12
Host	Override the default host
Datastore	Override the default datastore
Resource pool	Override the default VMware resource pool

Additional parameters for VMware vCloud

Field	Description
VM name prefix	Set custom name prefix to avoid name collision with already existing VMs
VM hardware version	Override the default VM hardware version, example: vmx-12
Storage policy	Override the default VM storage policy
Organization VDC	Override the default organization VDC
vApp name	Override the default vApp name

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

Edit Retention Settings

Retention settings 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 settings on the level of separate machines, groups, or as general settings.

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 settings in the Actions menu (for separate machines),

in the menu of separate groups

or in the general settings menu of Machines Groups

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

• keep last restore points

  

  • by count - the amount of restore points to be retained,
  • by hours - the amount of time per hours 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).

Protect New Platform

To protect a machine, click Protect new platform in the Group settings menu

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

Detailed information about this action is available at Protecting machines section.

After this action, all machines will automatically appear in the UI in the machine group specified in the second step. Machines will be in Unprotected state.

Start protection

When a machine or a group of machines is registered on the solution, start the protection.

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

Run customized replication

Note

Replications start and finish actions are only supported by VMware Replication Agent. These actions will be ignored by other replication agents.

The feature is available for a machine or a group of machines via Run customized replication in menus Actions or Bulk actions.

Set the values of the parameters:

The Replication type, as well as the actions On replication start and finish are available for editing.

Select the Replication type:

• incremental – send only changed data blocks
• full – send all data blocks

Select the actions on start/end replication:

• default action – configured in the source cloud configuration, the default action corresponds to the value no action, unless otherwise specified
• no action – leave the machine in its original state
• power source machine off
• power source machine on

When click on the Start button, the values are saved and the replication starts.

Note

After the replication is succeed, the values will return to the original state set before the replication was started.

Sync machines replications

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

Park (Pause)/Start Protection

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

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

Generate DR plan for Machines Group

It is possible to generate a DR plan for a group of selected machines or for machines groups. To generate a DR plan from Machines Group for several machines or groups, select the desired machines and click Generate DR plan in the Bulk action or groups menu.

Detailed information is available in the section dedicated to this issue.

Notification panel

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

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.

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.

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

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

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.

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.

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

Disk attach

Hystax Acura allows to recover protected machine disk(s) and attach it to the existing machines. This feature can be found in the Machines Groups section on the customer's page and on the third step of the Cloud site creation.

Note

Attaching disks is possible to machines restored for target OpenStack and Amazon Web Services clouds.

Invoke disk attachment in one of three ways:

1. Select the Attach disk action for the source machine.

2. On the third step of the Cloud site creation (Section: ACP - Cloud sites).

3. Select the Attach disk action on Machine restore points information (to get there click on the machine's Last Restore point column of the table). Click on the paperclip icon near the restore point on the Machine restore points information window.

Note

The disk will be attached to the failover machine.

Select the disk(s) you want to attach to the target machine in the Attach disks window and the ID of the target machine from the list. Restore point can be changed, if necessary.

The process starts when the Attach button is pressed. The page appears on the screen showing the options of connection. When the disk is linked, the State changes into Active.

Note

This process doesn't guarantee that the disk will be detected by the operating system of a virtual machine. Use the administrative tools of the OS to mount the disc manually.

On the customer's page in the Attach disk section all attached disks are listed.

Cick on the machine name and the page with additional information launches. There are two buttons on this page Detach and Delete. The detached disk becomes invisible for the Hystax Acura, but remains mounted to the virtual machine. Further it's impossible to manage it by Hystax Acura. To unmount and delete disk press the Delete button.

User and general solution settings

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

Warning

Depending on user's rights and permissions, the set of available options may vary.

User settings

The window with the settings:

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

Warning

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.

Create users

To create a new user, just click Add user.

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 Assignment role and Role 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 Roles.

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

Add a role

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.

Warning

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

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.

Warning

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 «Users» 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

SMTP settings management

On the SMTP Settings tab you can manage SMTP settings and configure SMTP server that is used to send product notifications.

SMTP settings tab determines the type of encription (SSL/TSL) and such SMTP server settings as address, port, username, password. Use to get hints on the fields. Organization and License key are unavailable for editing. They are specified during the initial installation of Hystax Acura and remain unchanged.

If the mail server requires the FROM field and it does not match the login, update the data in the SMTP FROM field.

To check the SMTP server connection and configuration enter the test email address into the Test email field.

Click Check connection to check if the SMTP settings are valid. If succeed, a test message on your test email will be sent.

Warning

The settings will not be saved when press Check connection.

To save changes click Save.

Cluster settings management

To manage cluster settings go to the Cluster settings tab.

Both IPs (public and local) and SSL certificate are available for changing. Use icons to get fields hints.

Hystax Acura Control Panel Public Address is the address that is used by replication agents to access the Acura. An IP-address or DNS-name can be specified.

Local address for cloud agents is the local address of the Acura in the cloud. Used if the Acura is located in the target cloud. By default, it matches the public address. An IP-address or DNS-name can be specified.

Click the Update control panel SSL certificate checkbox if you want to specify a new certificate. If it is not checked, the private key and certificate are not displayed. After the click, both fields will appear.

Both certificates can be uploaded from the file. Use icon on the right of the field. You can specify a self-signed certificate or a complete chain of certificates (including the root one).

Private key format:

-----BEGIN PRIVATE KEY-----
ABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCD
<several base64 string with length 64>
ABCDEABC=
-----END PRIVATE KEY-----

Certificate format:

-----BEGIN CERTIFICATE-----
ABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCDEABCD
<several base64 string with length 64>
ABCDEABC=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
FGHIJFGHIJFGHIJFGHIJFGHIJFGHIJFGHIJFGHIJFGHIJFGHIJFGHIJFGHIJFGHI
<several base64 string with length 64>
FGHIJFGHIJFGHIJ
-----END CERTIFICATE-----

Certificate expiration date is calculated automatically when the value in the "Certificate" field is changed.

To save your changes click Save.

Warning

Changing these settings will not affect already installed replication agents.

Warning

If your Acura Controller is behind a load balancer, make sure to update its certificate manually. No changes made on this page will refer to the load balancer.

Protecting machines

To protect a machine, click Protect new platform in the Group settings menu

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

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.

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

The next step is to configure:

• a group.
• parameters.

The list of parameters depends on the cloud type. Detailed information about them and description can be seen via links:

• VMware agent step 3 configure

• zVirt agent step 3 configure

• Linux agent step 3 configure

• Windows agent step 3 configure

The last step is to download the agent.

After downloading and installing the agent, all machines 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.

Another ability to start the replication is to Run customized replication.

If necessary, an action Sync machines replications is available.

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.

or Recover in the main menu.

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.

Next step is to select DR plans (Section ACP - Disaster Recovery 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.

Warning

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.

The ability to select the recovery point time for each machine separately has been implemented. Expand the panel with the machine name and select the desired value in the Restore point time field.

Additionally, it is possible to attach disks to the machine being restored.

Note

Attaching disks is possible to machines restored from OpenStack, Amazon Web Services, Flexible Engine, CROC clouds.

Just check the Attach disks from additional restore point, select Additional restore point time and physical disks, which need to be restored.

Note

Restore point time and Additional restore point time values may differ.

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.

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.

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.

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.

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

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 Image downloads panel appears on the customer's page:

Click on the source machine's name and on the Links in the Physical disks window to download:

Note

The download process takes some time, this is due to the connection speed and the size of the downloaded file.

Files and folders recovery

There are two ways to start the files and folders recovery process:

1. Via main page on a Hystax Acura control panel.
2. Via the Restore files and folders context menu.

Note

The recovery process can take some time.

Recovery via main page

1. On the main page click on the customer whose data it is necessary to recover.

2. On the next page click on the source machine in the File and folder connections section.

3. On the next page the volume content will be shown. Navigate by double-clicking on it to find the file or folder you want to recover.

Note

Preparing file and folder connection requires some time.

4. Select (single-click) the file or folder to recover and click the Download button on the left hand corner of the list. The file or folder will be downloaded automatically.

Note

The download process can take some time.

Recovery via the Restore files and folders context menu

1. Go to Restore files and folders context menu.

2. Follow the wizard instructions on the next page:

-   Choose a client, click **Next**;
-   Choose a machine, click **Next**;
-   Choose restore point, click **Browse**.

3. As soon as a file and folder connection is ready, the directory tree is built. Navigate by double-clicking on it to find the file or folder you want to recover.

Note

Preparing file and folder connection requires some time.

4. Select (single-click) the file or folder to recover and click the Download button on the left hand corner of the list. The file or folder will be downloaded automatically.

Note

The download process can take some time.

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 process includes five (for the partner) or four (for the customer) steps.

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.

Reports

To access this section in Acura Control Panel, click on the "Reports" menu item in the left sidebar.

Hystax Acura provides a sophisticated set of reports on the performed Disaster Recovery activities:

• Machine state report.

• MSP DR report.

• Storage size report.

To generate a report, select its type in the drop-down menu as well as the Start and End dates to define the desired time frame, click on the blue "Generate report" button to get the results.

Note

Partners can get statistics for a specific customer or for all customers by utilizing the "Report scope" field. Customers can obtain statistics applicable only to them.

The output can be exported to a CSV file in case further data analysis is necessary.

Machine state report

• gives access to the information about changes in the number of protected / unprotected / parked machines within a specific time frame.

A chart will appear on the screen, with the number of machines vertically and dates horizontally. This diagram will allow you to visually see the dynamics of changes in the states of machines: the number of protected, suspended and unprotected is display.

Under the diagram the same data is presented in tabular form.

MSP DR report

• indicates the number of consumed licenses during a given period based on the number of successful replication of the customer machines and on the number of every unique machine that has replicas (protected / parked / warned / error state). It consists of two tables: Licenses by customer and Licenses by machines. Each table has a Download .csv button. In the report header (the 'Total licenses' field) the total number of consumed licenses is displayed.

The Licenses by сlient table shows the number of licenses used, cloud type and storage type for each client. Depending on the Storage Type, the type of license is determined: block - disaster recovery, object - backup.

The Licenses by machines table displays information about the time until which the machine is protected, the client-owner of the machine, the name of the machine and its id.

Storage size report

• provides information about object storage consumption. It gives details by customer and client. Download .csv is available for both.

The Details by customer table shows total storage consumption per the whole selected period, average storage consumption per hour. This values can be compared with provisioned consumption (per the hole period of time) and average provisioned consumption per hour.

The Details by machines table displays the same columns and id addition gives information about machine's name and machine's id.