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.
The replication and recovery module 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. |
| SyncReplicationPlan | Synchronous replication plan | Contains the protected object, restore point creation interval, retention policy, and replica object settings. |
| SyncReplicationJob | Synchronous replication job | Represents a synchronous replication job for a protected object. |
| ReplicationJob | Asynchronous replication job | Represents an asynchronous 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 SyncReplicationFailoverJobs, BootJobs, and ReIPJobs. |
| SyncReplicationFailoverJob | Replication group synchronous replication failover or failover test job | Represents a synchronous 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. |
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 protected objects of a synchronous replication plan on the page, the system updates the desired state of the SyncReplicationPlan resource, that is, the list of objects that need protection. The controller responsible for the SyncReplicationPlan resource automatically creates ReplicationGroup and SyncReplicationJob resources based on the desired state of the SyncReplicationPlan resource, so that protected objects are protected by synchronous replication.
