Solution description#
Hystax Acura is a Disaster Recovery and Backup solution for business applications and IT infrastructure in case of emergency or migration between private clouds.
Disaster Recovery and Backup process consists of the initial replication of business application components (machines), infrastructure items to a backup data center (DC) and of the subsequent launch of a failover instance from one of the restore points. The failover runs on a backup DC, wherein the original IT infrastructure that includes all of the former items is restored.
Backup scenario differs from DR by storage used on a target site. In Backup mode, data is stored in object storage, which is more cost-effective for long term storage.
Replication is available for instances running on VMware, Hyper-V, OpenStack, as well as for physical machines.
Architecture#
The solution consists of server and client parts. The server one contains components, which are installed on the backup DC and responsible for retrieving changes from customer devices, their deduplication, storing data and failover as well in case of disaster. The server part also includes storage - an object storage located in the backup data center where full and incremental replications of customer machines are saved.
As for the client part, it includes agents installed on VMware vSphere/oVirt/OpenStack 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 or cluster and that replicates machines on these hosts. Standard VMware tools are used to detect changes and retrieve deltas on virtual machines via the Changed Block Tracking (CBT) API. These tools, in turn, trigger the operating system's mechanisms (such as quiesce) to ensure data consistency within the replicas. An agent instance must have at least 2 CPUs and 4 GB of RAM and must be deployed on each ESXi host or cluster containing machines designated for replication.
Note
An ESXi host or cluster detection depends on cloud configuration settings according to the discovery level.
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.
Client for OpenStack (OpenStack 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 .rpm or .deb package to be installed in the guest operating systems.
Note
A Linux agent is available for download as a deb or rpm archive.
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/OpenStack 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#
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, oVirt, or OpenStack 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.
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 vCPUs Memory: 16 GB RAM Disk space: 200 GB SSD 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 Hystax Control Panel and deployed from an OVA template | 2 CPUs Memory: 4 GB RAM |
- Ingress - tcp/80 - Egress - tcp/udp 902 (to ESXi hosts) - Egress - tcp/443 (to vCenter and ESXi hosts) |
| Cloud Agent (oVirt): downloaded from Hystax Control Panel and deployed from a RAW disk | 2 CPUs Memory: 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 CPUs Memory: 4 GB RAM |
- Ingress – tcp/80 - Egress – tcp/443, udp/12201 |
| Replication Agent Windows: downloaded from Hystax 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 Hystax 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 Hystax Control Panel – external | 2 CPUs Memory: 4 GB RAM There are several host permissions that the VMware Replication Agent requires to operate. |
- Source host – tcp/443 - vSphere host - tcp/443 - ESXi host(s) – tcp/udp/902 - udp/12201 - receive logs from the Hystax cluster |
| Replication Agent oVirt: downloaded from Hystax Control Panel – external | 2 CPUs Memory: 4 GB RAM 20GB disk |
- Source host – tcp/443 - udp/12201 - receive logs from the Acura cluster |
| Replication Agent OpenStack: downloaded from Hystax Control Panel – external | 2 CPUs Memory: 4 GB RAM 20GB disk |
- Source host – tcp/443 - udp/12201 - receive logs from the Acura cluster |
| Failback Agent VMware | Host permissions:Failback to VMware | - tcp/80 - communicate with the Acura host - tcp/443 - vSphere host - tcp/udp/902 - ESXi host(s) - udp/12201- send logs to Acura |
| Failback Agent Flexible Engine | Host permissions:Failback to Flexible Engine | - tcp/443 - communicate with the Acura host - udp/12201 - send logs to Acura - Ports to communicate with the cloud API, e.g. tcp/5000 for keystone |
| Failback Agent OpenStack | Host permissions:Failback to OpenStack | - tcp/443 - communicate with the Acura host - udp/12201 - send logs to Acura - Ports to communicate with the cloud API, e.g. tcp/5000 for keystone |
| Failback to other clouds | For other clouds, failback is done in a form of a live reverse migration of workloads to the source environment. Internal replication agents are installed directly to failover machines. |
Acura compatibility matrix and supported systems#
| Source Platform | Platform/OS version | Agent, replication type, distribution |
|---|---|---|
| VMware ESXi vRealize vSphere |
ESXi 6.0.0U3+ (except ESXi 6.7 Build 8169922) | 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 Windows Server 2025 |
HWRAgent (Windows) internal replication MSI installer |
| Bare Metal OpenStack Azure AWS Oracle Cloud |
Debian 7 Debian 8 Debian 9 Debian 10 Debian 11 Debian 12 Ubuntu 14.04 Ubuntu 16.04 Ubuntu 18.04 Ubuntu 20.04 Ubuntu 22.04 Ubuntu 24.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, Nutanix, 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.
Recommended configurations#
When deploying Hystax Acura for Disaster Recovery and Backup solution the configuration depends on the total amount of machines and the type of installation - for a test, for a single customer or to provide service.
Examples of typical configurations:
| Type of installation | Total amount of machines | Amount of nodes | Configuration of each node: CPU / RAM / Disk cores |
|---|---|---|---|
| Test | 15 | 1 | 8 / 16 GB / 150 GB SSD |
| Single customer | 50 | 1 | 16 / 32 GB / 150 GB SSD |
| Single customer | 150 | 3 | 16 / 32 GB / 200 GB SSD |
| Single customer | 250 | 3 | 24 / 48 GB / 300 GB SSD |
| Providing service | 500 | 3 | 32 / 64 GB / 300 GB SSD |
| Providing service | 1000 | 5 | 32 / 64 GB / 300 GB SSD |
Linux kernel support for HLRAgent#
Hystax Acura limitations#
- Virtual machines with disks engaged in SCSI bus sharing are not supported because VMware does not support snapshotting such VMs.
- 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.
- Free ESXi is not supported. Hystax Acura leverages vSphere and vStorage APIs that are disabled by VMware in free ESXi.
- Hystax Windows Replication Agent supports NTFS, ReFS filesystems.
- Hystax Windows Replication Agent doesn't support extended volumes.
- Hystax Windows Replication Agent converts dynamic disks to basic ones while protecting them.
- Hystax Linux Replication Agent supports replication of machines with up to 64 disks.
- Windows servers with the enabled Storage Replica feature are not supported.
- 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#
- No ssh key can be attached to failover instances, as they are created from volumes.
- Mac address cannot be set for NIC.
- Every failover instance will have an extra temporary storage volume. Volume size depends on the flavor. More information can be found at: https://blogs.msdn.microsoft.com/mast/2013/12/06/understanding-the-temporary-drive-on-windows-azure-virtual-machines/
- No security groups will be assigned to failover instances by default. Refer to Disaster Recovery plans section and use the key "security_group" in DR plans.
- CentOS 6.2 protection is not supported. Refer to https://docs.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros for further details.
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