Skip to content

Solution description#

Hystax Acura Live Migration is a migration solution for business applications and IT infrastructure.

"Lift and shift" process consists of the initial replication of business application components (machines), infrastructure items to a target environment with a subsequent launch of the migrated workloads.

Replication is available for instances running on public clouds, VMware, Hyper-V, KVM, OpenStack, as well as for physical machines.

Architecture#

The solution consists of server and client parts. The server one contains components, which are deployed on AWS from AMI or a golden image on KVM Platform and responsible for retrieving changes from customer machines, their deduplication, storing data and running migrations as well.

As for the client part, it includes agents installed on VMware vSphere/oVirt for replication of machines on the cloud platform or agents for Windows/Linux installed on guest operating systems for replication of other types of cloud platforms and physical machines.

Client for VMware (VMware agent) - a Linux machine, supplied as an OVA file, that is deployed to each ESXi host and that replicates machines on these hosts. Standard VMware tools are used to detect changes and obtain deltas on the machines (Changed Block Tracking API), which in turn induce the tools of operating systems (quiesce) to preserve data consistency inside replicas.

Client for oVirt (oVirt agent) - a Linux machine, supplied as an RAW file, that is deployed on the main data center and that replicates machines on it.

Linux agent - a Linux daemon installed on a guest OS in case of replicating machines on public clouds like AWS, Microsoft Azure or Google Cloud as well as Hyper-V, KVM, OpenStack or physical machines with Linux operating systems. Supplied as a bash instruction to be executed in guest operating system terminal, thereby the agent is installed on the machine.

Windows agent - a Windows service installed on a guest OS in case of replicating machines on public clouds like Microsoft Azure or Google Cloud as well as Hyper-V, KVM, OpenStack or physical machines with Windows operating systems. Supplied as a ZIP file with MSI and a configuration file for installation on a guest operating system.

Warning

In case of a VMware/oVirt infrastructure replication, there is no need to install Windows/Linux agents on each machine. Just install a VMware agent on each ESXi host of vSphere.

Network schema#

network_schema

Acura's interconnections:

  • Generally, Replication Agent installers are downloaded from Acura's web UI and deployed as a service directly on the source machines.
  • Aside from internal replication agents, there is an option to use an external replication agent type in case of a VMware or oVirt source environment. It is downloaded in form of an OVA/RAW template and deployed on customer's hypervisor as a separate instance.
  • A Replication Agent connects to the Acura controller via port 443 TCP and sends logs via port 12201 UDP. A machine with an installed and running Replication Agent's service is discovered in Acura Control Panel (ACP) and can be replicated. The agents do not require an Internet connection to function as long as Acura's host is reachable from their network.
  • A Cloud Agent (CA) is an auxiliary machine automatically created (except VMware/oVirt) in the target cloud by Hystax Acura controller separately for each customer. Its job is to forward replication data to the customer's project via port 80 TCP and write it to the storage.
  • In case of a VMware/oVirt cloud agent is downloaded from the Customer
    page and deployed manually. It is capable of interacting with hypervisors on the target environment. Its job is to forward replication data to the storage. On the CA, the data is received via port 80 TCP and is sent to a target hypervisor via ports 902 TCP and 902 UDP.
  • Hystax Acura controller calls the target cloud API via TCP ports for its corresponding services.
  • In case of VMware communication with vSphere and its corresponding services is carried out via port 443 TCP both from the Controller and the CA. In case of using vCloud, communication with its API is carried out via port 443 TCP by the Controller.
  • If the data is stored in an object or a file storage, the controller requires access to it, due to the data is stored outside the target cloud, in a third-party storage. If data is stored in a block storage, there is no need to provide additional access. The data is stored on the target cloud side.

Data flow description#

The solution consists of client (Source Environment) and server (Target Cloud) parts.

fd_diagram

The solution implements different ways of storing replicated data: block, object and file. A block storage is recommended for a migration or a disaster recovery scenario, while an object or a file storage works better for a backup scenario.

Data replication#

As for the client part, it includes Replication agent, the utility for replication of the machine on the target cloud. A machine with an installed and running Replication Agent service is discovered in ACP and can be replicated. On the Target Cloud there are two services Receiver and Cloud Agent. Receiver is a part of Hystax Acura Controller (controller). Its processes are invisible for the administrator and are displayed as controller processes. Cloud Agent is automatically launched by the controller separately for each customer. Generally, a controller provides the connection with a Replication agent and gets the data. A Cloud Agent is an auxiliary machine. Its job is to forward replication data to the Replica Volume. When using an object or a file storage, the controller forwards data from the source site to the external storage.

Note

In case of VMware/oVirt a Cloud Agent must be installed and deployed manually on the Target Cloud.

A Replication Agent connects to the controller and sends the source data. In case of a block storage, a controller gives it to the Cloud Agent. Its job is to write the data to the storage. In the further, the Replication Agent checks for updates and the Cloud Agent creates snapshots if necessary.

When selecting an object or a file storage, the data is transferred by the controller to external storage, the target cloud is not involved.

The replication schedule is set in the ACP by the administrator.

Data storage#

In the case of a block storage, the data is stored in the volumes on the target cloud. These disks and their snapshots are subsequently used as recovery points from which machines are picked up at the target site. The time to raise a virtual machine is minimal and is calculated in minutes, i.e. there are no long-term recovery operations. However, it must be taken into account that this type of storage is more expensive compared to object and file. We recommend choosing this type of storage when implementing a disaster recovery or a migration scenario.

For the backup scenario, it is recommended to select an S3-compatible object or a file storage (NFS, SMB/CIFS support is implemented). These are third-party storages, the data is stored outside the target cloud. The efficiency of these types of storage is high if you need to restore files or folders. This is achieved through deduplication in the storage system and the ability to store a longer history of recovery points. The downside is that the recovery process in the form of virtual machines on the target cloud will take longer than for block devices.

Data recovery#

For a block storage, machine recovery takes place entirely on the target cloud. In addition to the ACP, Orchestrator and V2V are installed on the Target Cloud. The Orchestrator job is to configurе, coordinatе, and managе recovery process. The V2V utility deploys a virtual machine Restore machine filled with applications and customer's data based on Restore volume* content.

ACP sends the signal to the Orchestrator to start the recovery process. The Orchestrator starts 3 processes:

  • The first to create data volume Restore volume based on the chosen recovery point.
  • The second to create a virtual machine and attach the Restore volume to it.
  • The third to start V2V to coordinate the first two.

As a recovery result a customer gets a virtual copy of the machine filled with the latest data stored on the Target Cloud.

Note

Recovery process may require some time: its duration depends on the structure complexity and amount of data.

When restoring data from an object or a file storage, a recovered volume is created on the target cloud first. It is attached to the cloud agent. Data from the recovery point is written to this volume. The following corresponds to recovery from the block storage: create a virtual machine, attach restore volume, and so on.

Deployment requirements#

Hystax Acura Component System Requirements Network Requirements (Allow traffic to/from the following ports)
Hystax Acura (controller): deployed from the image provided by Hystax 8 vCPUsMemory: 16 GB RAM
Disk space: 200 GB drive
Ingress – tcp/443
Ingress – tcp/4443
Ingress - udp/12201
Egress - tcp/443
Egress - tcp/80 (to Hystax Cloud Agent)
Cloud Agent (VMware): downloaded from Acura Control Panel and deployed from an OVA template 2 CPUsMemory: 4 GB RAM Ingress - tcp/80
Ingress - tcp/15000
Egress - tcp/udp 902 (to ESXi hosts)
Egress - tcp/443 (to vCenter and ESXi hosts)
Cloud Agent (oVirt): downloaded from Acura Control Panel and deployed from a RAW disk 2 CPUsMemory: 4 GB RAM
20 GB disk
Ingress – tcp/80
Egress – tcp/443, udp/12201
Cloud Agent (all other supported cloud platforms): deployed automatically in the target project 2 CPUsMemory: 4 GB RAM Ingress – tcp/80
Egress – tcp/443, udp/12201
Replication Agent Windows: downloaded from Acura Control Panel - internal Memory: 2 GB RAM
CPU: x64 processor
Disk space: 100 MB required for product installation and not less than 15% free space of disk size for VSS snapshots creation
Microsoft .NET Framework 4.0
tcp/443 - send data to the Acura host
udp/12201 - send logs to Acura
Replication Agent Linux: downloaded from Acura Control Panel - internal Memory: 500 MB RAM
Disk space: 100 MB required for product installation and not less than 15% free space of disk size for snapshots creation
tcp/443 - send data to the Acura host
udp/12201 - send logs to Acura
Replication Agent VMware: downloaded from Acura Control Panel - internal 2 CPUsMemory: 4 GB RAM
There are several host permissions that the VMware Replication Agent requires to operate: vmware-agent-requirements
Source host - tcp/80, tcp/443
vSphere host - tcp/443
ESXi host(s) – tcp/udp/902
udp/12201 - receive logs from the Acura cluster
Replication Agent oVirt: downloaded from Acura Control Panel - internal 2 CPUsMemory: 4 GB RAM
20GB disk
Source host - tcp/80, tcp/443
udp/12201 - receive logs from the Acura cluster

Acura compatibility matrix and supported systems#

Source Platform Platform/OS version Agent, replication type, distribution
VMware ESXi
vRealize
vSphere
ESXi 6.0.0U3+ HVRAgent (VMware)
external replication
OVA VM template
Bare Metal
OpenStack
Azure
AWS
Oracle Cloud
Windows 7
Windows 8
Windows 8.1
Windows 10
Windows 11
Windows Server 2008R2
Windows Server 2012
Windows Server 2012R2
Windows Server 2016
Windows Server 2019
Windows Server 2022
HWRAgent (Windows)
internal replication
MSI installer
Bare Metal
OpenStack
Azure
AWS
Oracle Cloud
Debian 7
Debian 8
Debian 9
Debian 10
Debian 11
Ubuntu 14.04
Ubuntu 16.04
Ubuntu 18.04
Ubuntu 20.04
Ubuntu 22.04
RHEL/CentOS 6.5+
RHEL/CentOS 7.1+
RHEL/CentOS 8.0+
RHEL/CentOS 9.0
HLRAgent (Linux)
internal replication
.deb/.rpm packages

Supported platforms:

OpenStack, VMware, oVirt, OpenNebula, Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud, Alibaba Cloud, Hyper-V, and physical machines.

Supported applications:

SAP, Microsoft Active Directory, PostgreSQL, Oracle, NGINX, Red Hat Jboss Enterprise, IBM WebSphere, Apache, VMware vSphere, MongoDB, Hadoop, Spark, MySQL, and others.

When deploying Hystax Acura for Migration solution the configuration depends on the total amount of machines, desired amount of simultaneously replicated machines and the type of installation - for a test, for a single migration project or to provide service.

Examples of typical configurations:

Type of installation Total amount / amount of simultaneously replicated machines Amount of nodes Configuration of each node: CPU / RAM / Disk cores
Test 50 / 5 1 8 / 16 GB / 150 GB
Single project 150 / 20 1 12 / 24 GB / 150 GB
Single project 350 / 40 1 16 / 32 GB / 200 GB
Single project 1000 / 100 1 24 / 48 GB / 300 GB
Providing service 1000 / 100 3 16 / 32 GB / 300 GB SSD
Providing service 3000 / 200 3 24 / 48 GB / 300 GB SSD

Linux kernel support for HLRAgent#

List of supported versions

Hystax Acura limitations#

  1. Virtual machines with disks engaged in SCSI bus sharing are not supported because VMware does not support snapshotting such VMs.
  2. Linux machines with static IP addresses will keep the original network settings. Refer to our KB article for a workaround.
  3. RDM virtual disks in physical mode, Independent disks, and disks connected via in-guest iSCSI initiator are not supported. Network shares and mount points targeted to 3rd party storage devices are also skipped, as these volumes/disks are not visible in the VM configuration file.
  4. Free ESXi is not supported. Hystax Live Migration to AWS or KVM Platform leverages vSphere and vStorage APIs that are disabled by VMware in free ESXi.
  5. Hystax Windows Replication Agent supports only NTFS filesystems.
  6. Hystax Windows Replication Agent doesn't support extended volumes.
  7. Hystax Windows Replication Agent converts dynamic disks to basic ones while migrating them.
  8. Hystax Linux Replication Agent supports replication of machines with up to 64 disks.
  9. Windows servers with the enabled Storage Replica feature are not supported.
  10. Ephemeral networks are not supported

AWS Limitations#

Hystax Acura uses an import image mechanism to launch replicated machines on AWS, therefore all "Import Image" limitations apply. Refer to the official AWS documentation for more details.

Azure Limitations#

VMware Limitations#

  • Max number of restore points stored for one machine is 29.
  • Replication and failover of the same machine can't be started at the same time because both processes work with the same machine on the target side.

Replicated machines licensing on AWS#

According to the AWS requirements, machines running Red Hat Enterprise Linux (RHEL) must have Cloud Access (BYOL) licenses in order to be copied to AWS, whereas Windows machines will use the AWS licensing. For more information, please refer to the official AWS guide

Release notes#

version 4.1

version 4.0

version 3.10

version 3.9.1

version 3.9

version 3.8

version 3.7

version 3.6

version 3.5

version 3.4

version 3.3

version 3.2

version 3.1