The design of Arcfra Backup & Disaster Recovery uses the Kubernetes Operator pattern and follows the declarative programming paradigm. You only need to set the desired state for replication-related resources, without describing the implementation process. The system can then determine the operations required to reach the desired state.
The Kubernetes Operator pattern includes two basic concepts: resources and controllers.
Resource
Kubernetes abstracts managed objects as resources. A resource has two states: desired state and actual state. The desired state is usually defined by users, and the actual state is usually updated and maintained by controllers.
The Kubernetes system uses controllers to monitor resource objects and execute service logic, so that the actual state of resources eventually reaches the desired state and achieves the expected result.
Kubernetes provides multiple default resource types and also supports custom resources (CRs) created by users.
Asynchronous replication and recovery includes the following custom resources:
| Name | Display name | Description |
|---|---|---|
| ReplicationGroup | Replication group | A protected object corresponds to one ReplicationGroup, and one ReplicationGroup contains one ReplicationSlice. |
| ReplicationSlice | Replication restore point chain | Represents the replication restore point chain of a protected object. A replication restore point chain consists of one full restore point and multiple incremental restore points. |
| ReplicationRestorePoint | Replication restore point | A basic object that can be used for failover. It records the data and configuration of the protected object and reflects the state of the protected object during replication. |
| MultiStorageConsistentSnapshot | Data-consistent snapshot group | A group that consists of multiple storage-level data-consistent snapshots. |
| ReplicationPlan | Asynchronous replication plan | Contains the protected object, replication schedule, retention policy, and replica object settings. |
| ReplicationExecution | Asynchronous replication execution | A manually or automatically triggered execution of a replication plan, including multiple ReplicationJobs. |
| ReplicationJob | Asynchronous replication job | Represents a replication job for a protected object. |
| ReplicaGroup | Replica of a replication object | Represents a replica object in failover or failover test. |
| FailoverExecution | Failover or failover test execution | A manually triggered failover or failover test execution, including multiple ReplicationFailoverJobs, BootJobs, and ReIPJobs. |
| ReplicationFailoverJob | Replication group asynchronous replication, failover, or failover test job | Represents an asynchronous replication, failover, or failover test job for a protected object. |
| BootJob | Virtual machine startup job | Represents a virtual machine startup job for one or more virtual machines. |
| ReIPJob | IP mapping job | Represents an IP mapping job for one or more virtual machines. |
| FailbackExecution | Failback execution | A manually triggered failback execution, including multiple FailbackJobs. If the protected object is a virtual machine, the execution also includes BootJob and ReIPJob. |
| FailbackJob | Failback job | Represents a failback job for a replica object. |
| FailbackReplicationJob | Failback replication job | Represents a failback replication job for a replica object and is part of a failback job. |
| PermanentFailoverJob | Permanent failover job | Represents a permanent failover job for a replica object. |
| Peer | Peer replication service | The source-side replication service, which provides a proxy for the target-side replication service. |
Controller
The replication service has a corresponding controller for each resource. A controller listens for resource creation, editing, deletion, and other events, and triggers the corresponding execution logic based on the desired state and actual state of the resource until the resource reaches the desired state. If related operations on the corresponding resource fail and the desired state cannot be reached after limited retries, the resource object eventually enters a failed or abnormal state, and the controller does not retry the operation.
For example, after you set the execution schedule of an asynchronous replication plan on the page, the system updates the desired state of the ReplicationPlan resource, that is, the scheduled time when the asynchronous replication plan is executed. The controller responsible for the ReplicationPlan resource automatically executes asynchronous replication at the configured replication time based on the desired state of the ReplicationPlan resource, so that replication jobs are executed according to the configured schedule.
