API Doc
Search Docs...
⌘ K
ACOSABSAVEANSABDR
  • ABDR asynchronous replication and recovery technical whitepaper

Basic concepts

This chapter explains the technical terms used in this document. If you encounter unfamiliar concepts while reading, you can quickly find their definitions and detailed explanations here.

Arcfra Backup & Disaster Recovery

Arcfra Backup & Disaster Recovery is a data protection product for Arcfra IT infrastructure. It provides backup, replication, and disaster recovery solutions for workloads running on Arcfra infrastructure.

Replication service

The replication service is responsible for managing asynchronous replication plans and scheduling jobs such as asynchronous replication, failover, failover test, failback, and permanent failover for virtual machines.

Depending on the associated cluster, replication services are divided into target-side replication services and source-side replication services.

  • Target-side replication service

    The replication service associated with the target cluster is mainly responsible for executing asynchronous replication plans, performing failover and failover tests, managing replication resources, and reading data from the target cluster and transmitting the data to the source-side replication service during failback. The target-side replication service ensures the synchronization of replicated data and maintains data consistency between replica virtual machines and source virtual machines.

  • Source-side replication service (Peer)

    The replication service associated with the source cluster is mainly responsible for reading data from the source cluster and transmitting the data to the target-side replication service. During failback, it receives data transmitted by the target-side replication service and writes the data to the source cluster.

Site

A site refers to a fault domain managed by a single AOC. A site can include one or more clusters and data centers. Each site is completely isolated in terms of geographical location, hardware equipment, management platform, and software services, and does not share any resources with other sites.

Sites can be divided into the following two types:

  • Source site: A source site usually runs production workloads. The replication service replicates virtual machine data from the source site to replica objects at the target site to achieve data synchronization.
  • Target site: A target site is usually used for disaster recovery and stores replica objects replicated from the source site.

Intra-site replication

The source cluster and target cluster are located at the same site. When a source virtual machine is unavailable, you can switch to a replica object in another cluster within the site, achieving cluster-level disaster recovery. If the AOC that manages the site fails, failover cannot be initiated.

Cross-site replication

The source cluster and target cluster are located at different sites. When a source virtual machine in the source site is unavailable, you can switch to a replica object at the target site to achieve site-level disaster recovery, regardless of whether the AOC that manages the source site has failed.

Cross-site replication includes the following two types:

  • Incoming replication: The target site is the current site, and the source site is another associated site.
  • Outgoing replication: The source site is the current site, and the target site is another associated site.

Source cluster

Usually a production cluster that hosts production applications and data. It is the cluster to which source virtual machines belong and is located at the source site.

Target cluster

Usually a cluster used for disaster recovery. It stores replica objects replicated from the source cluster and is located at the target site.

Protected object

The original object used as the replication data source. It is usually a virtual machine in an ACOS (AVE) cluster.

A protected object is usually a virtual machine in the production environment, hosting production applications and data.

Replica object

A complete copy of a protected object created through an asynchronous replication plan. It contains the same data and configuration as the protected object. Replica objects are typically used for disaster recovery. When a protected object fails, the replica object can quickly take over the protected object to ensure service continuity and availability. A replica object is usually stored in a target cluster used for disaster recovery and is kept synchronized with the protected object through periodic asynchronous replication plans.

Asynchronous replication plan

An asynchronous replication plan is used to plan and schedule data replication operations. Through an asynchronous replication plan, you can define information such as replication objects, replication type, replication site, target cluster, replication service, replication schedule, replication window, retention policy, and replica objects.

Replication object

A protected object and its corresponding replica object are called a set of replication objects. For virtual machine replication, a source virtual machine and its replica virtual machine are called a set of replication objects.

Replication schedule

The frequency and time at which an asynchronous replication plan automatically executes. It is used to specify the time interval for data replication. A shorter replication schedule enables a smaller RPO (Recovery Point Objective). For example, if the replication schedule is set to 15 minutes, at most 15 minutes of data may be lost when a disaster event occurs.

Replication window

The time range during which an asynchronous replication plan is allowed to execute automatically.

Full asynchronous replication

Full asynchronous replication is a data replication method that replicates all data of a protected object, including the operating system, applications, files, configurations, and other data. During full asynchronous replication, all data of the protected object is replicated to the replica object, ensuring that the replica object is completely consistent with the protected object and providing reliable disaster recovery capability. Full asynchronous replication typically occurs during initial replication. It is used to create the initial copy of a protected object and provides a baseline for subsequent incremental asynchronous replication.

Incremental asynchronous replication

Incremental asynchronous replication replicates data that has changed since the last full or incremental asynchronous replication. During incremental asynchronous replication, only data that has changed in the protected object since the last replication is transmitted to the replica object. This greatly reduces the amount of data transmitted and the transmission time, improving replication efficiency. Incremental asynchronous replication complements full replication, enabling the replica object to continuously track and synchronize changes to the protected object and ensuring data accuracy and consistency.

Fingerprint

During asynchronous replication, the replication service divides protected object data into blocks and calculates a fingerprint for each data block. During incremental asynchronous replication, the fingerprints of data blocks are compared. If the fingerprint of the same data block is identical to that of the previous replication, the replication service determines that the data block has not changed and does not transmit the data block again.

Restore point

A restore point is the data state generated each time replication, failover in Generate now mode, failover test in Generate now mode, or failback is performed for a replication object. It is saved as a snapshot on the replication object. A restore point records the data and configuration of the replication object and reflects the state of the replication object when the preceding operation was performed.

Restore points allow replication objects to quickly roll back to a specific data state when needed. For example, in a disaster recovery scenario, you can restore a replica object to a previous point in time to resume normal operations. Generating restore points regularly helps keep the data on replica objects up to date and maintain service continuity and availability.

Fault handling

Recovery operations that can be performed after a fault occurs, including failover, failover test, failback, and permanent failover.

  • Failover

    Failover is an operation used when a protected object is unavailable. When a protected object is unavailable, the replica object can be rolled back to a state consistent with the specified restore point and then switched over for use. Through failover, the system can quickly restore services to the state before the fault, ensuring service continuity and stability.

  • Failover test

    Failover test is an operation that simulates a disaster recovery drill. Without interrupting production workloads on the source side, it generates test virtual machines to verify the effectiveness of the recovery mechanism. Incremental data generated during the drill is not synchronized back to the protected virtual machines.

  • Failback

    Failback means that after the protected object that experienced a fault resumes normal use, the replica object transfers the data changed during failover back, and then services are switched back to the protected object. Failback synchronizes data between replication objects, ensuring that the protected object can continue to provide services after the fault is resolved.

  • Permanent failover

    Permanent failover is a measure taken when a protected object cannot recover from a fault. When a protected object has an unrecoverable failure, the replica object formally takes over the service role of the protected object to ensure continuous service provision and availability.

RPO (Recovery Point Objective)

Recovery point objective. It mainly refers to the acceptable time frame for data loss in a failover scenario. RPO is measured in time and indicates the time span from the most recent replication point to the time when the fault occurs. A smaller RPO value indicates that the system allows less data loss in the event of a fault. A larger RPO value means that the system can tolerate a longer time range of data loss during a fault.

RTO (Recovery Time Objective)

Recovery time objective. It mainly refers to the amount of time a service system can tolerate from crash to recovery. A shorter RTO value indicates that the service system requires rapid recovery when a fault occurs, while a longer RTO value means that the service system can tolerate a longer recovery time.

VPC (Virtual Private Cloud)

A virtual private cloud is a logically isolated network environment built for cloud resources. You can configure VPC subnets, IP addresses, route tables, floating IPs, gateway services, security services, and other resources in a VPC to achieve network isolation and security control. Replica virtual machines and source virtual machines can be deployed in the same or different VPCs, and flexible network mapping is supported. Test virtual machines must be deployed in a VPC different from the source virtual machine.

VPC subnet

A VPC subnet is a fundamental network module that makes up a VPC. It is used to segment the IP address space of the VPC. Virtual machines in the same VPC subnet can communicate directly by default. Virtual machines across VPC subnets can also communicate with each other if routing is reachable.

Floating IP

A floating IP is a network address translation (NAT) mechanism that uses one-to-one mapping to dynamically bind an IP address from an external subnet to a virtual machine inside a VPC. This allows external networks to actively access virtual machines in the VPC. Floating IPs provide flexible external access for virtual machines in a VPC while ensuring network security.

Network mapping

A configuration rule designed to address network environment differences between a source virtual machine and a replica virtual machine or test virtual machine.

Because replica virtual machines, test virtual machines, and source virtual machines are often in different network environments, completely copying the network configuration of a source virtual machine to a replica virtual machine or test virtual machine may prevent the network from being properly configured or connected in the target cluster environment. By configuring network mapping rules, the VM network to which the source virtual machine belongs can be mapped to the corresponding VM network in the target cluster, ensuring that the replica virtual machine or test virtual machine can connect to the network properly.

IP mapping

A configuration rule designed to address IP address mismatches between a source virtual machine and a replica virtual machine or test virtual machine in different network environments.

Because replica virtual machines, test virtual machines, and source virtual machines are often in different network environments, completely copying the IP address of a source virtual machine to a replica virtual machine or test virtual machine may prevent the network from being properly connected in the target cluster. By configuring IP mapping rules, during failover and failover test, the replication service can automatically set the correct IP address for the replica virtual machine or test virtual machine, ensuring that the replica virtual machine or test virtual machine can provide services according to the expected network configuration without manually updating the virtual machine IP address.

AVE

AVE refers to the ACOS native virtualized computing platform. It is the KVM-based virtualization engine component in ACOS hyper-converged software when ACOS is directly deployed in hyper-converged mode on x86_64 servers. In addition to basic features such as virtual machine lifecycle management, power operations, high availability, and cold and hot migration, AVE integrates with the ABS storage component to provide advanced virtual machine services such as instant snapshots, templates, and cloning.

AVE is easy to use. All operations on ACOS hyper-converged clusters can be performed through AOC.

AOC

Arcfra multi-cluster centralized resource management platform. It is designed to manage data centers within sites as well as multiple Arcfra clusters and system services across data centers, and provides complete and standard RESTful APIs and SDKs in multiple programming languages.