Solution description¶
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.
Architecture¶
As for the client part, it includes agents installed on VMware vSphere 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.
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.
Attention
In case of a VMware 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. Additionally, there is an external Replication Agent option for VMware source environments.
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 (manually, in case of VMware) in the target project by Hystax Acura controller separately for each customer. Its job is to forward replication data to the customer’s project via ports 80 and 3260 TCP and write it to the storage.
Cloud Agents check for updates and apply them from the Acura controller via port 15000 TCP.
Hystax Acura controller calls the target cloud’s API via TCP ports for its corresponding services.
Network schema for VMware environment¶
Aside from internal replication agents, there is an option to use an external replication agent type in case of a VMware source environment. It is downloaded in form of an OVA template and deployed on customer’s ESXi host as a separate instance.
A Replication Agent connects to the Acura controller via port 443 TCP and sends logs via port 12201 UDP. Machines with installed and running Replication Agent’s services as well as machines with a Replication Agent instance deployed on their ESXi host are 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 manually created in the target project from a template (downloaded from the Customer page) and is capable of interacting with multiple ESXi hosts in the target environment. Its job is to forward replication data to the customer’s project and write it to the corresponding datastore. On the CA, the data is received via ports 80 and 3260 TCP and is sent to a target ESXi host via ports 902 TCP and 902 UDP.
Cloud Agents check for updates and apply them from the Acura controller via port 15000 TCP.
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.
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 |
|
|
Cloud Agent (VMware): downloaded from Acura Control Panel and deployed from an OVA template |
|
|
Cloud Agent (all other supported cloud platforms): deployed automatically in the target project |
|
|
Replication Agent Windows: downloaded from Acura Control Panel - internal |
|
|
Replication Agent Linux: downloaded from Acura Control Panel - internal |
|
|
Replication Agent VMware: downloaded from Acura Control Panel - internal |
There are several host permissions that the VMware Replication Agent requires to operate: VMware Agent |
|
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 |
HWRAgent (Windows) internal replication MSI installer |
Windows 8 |
||
Windows 10 |
||
Windows Server 2008R2 |
||
Windows Server 2012 |
||
Windows Server 2012R2 |
||
Windows Server 2016 |
||
Windows Server 2019 |
||
Debian 7 |
HLRAgent (Linux) internal replication .deb/.rpm packages |
|
Debian 8 |
||
Ubuntu 14.04 |
||
Ubuntu 16.04 |
||
Ubuntu 18.04 |
||
Ubuntu 20.04 |
||
RHEL/CentOS 6.5+ |
||
RHEL/CentOS 7.1+ |
||
RHEL/CentOS 8.0+ |
OS upgrade to the latest Service Pack and patches is recommended.
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.
Linux machines with static IP addresses will keep the original network settings. Refer to our KB article for a workaround.
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 Live Migration to AWS or KVM Platform leverages vSphere and vStorage APIs that are disabled by VMware in free ESXi.
Hystax Windows Replication Agent supports only NTFS filesystems.
Hystax Windows Replication Agent doesn’t support extended volumes.
Hystax Windows Replication Agent converts dynamic disks to basic ones while migrating 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 Migration plans section and use the key “security_group” in migration plans.
CentOS 6.2 migration 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.