This is the multi-page printable view of this section. Click here to print.
Architecture
1 - Overview
Resiliency Operator is installed in a Kubernetes cluster that acts as an orchestrator and hosts the tools and components that synchronize the data across assets.
2 - Components
Operator
| Component | Description |
|---|---|
| Database controller | Orchestrate the Database obejcts. |
| Synchronization controller | Orchestrate the Synchronization obejcts. |
| Synchronization plan controller | Orchestrate the SynchronizationPlan obejcts. |
3 - Synchronization objects
Introduction
Astronetes offers the following synchronization objects to cover the infrastructure resiliency requirements.
Synchronization
Synchronizes the content of an asset to another one once. The operations required to perform the snapshot depend on the plugin. More information can be found in the Plugin section. Synchronizations are managed through the Synchronization Custom Resource Definition.
Synchronization Plan
Periodic snapshots with intervals set by the user. Periodicy is established as a cron expression. When the Synchronization Plan starts a new snapshot, it creates a new Synchronization resource akin to how a Kubernetes CronJob deploys a new Job whenever the cron expression indicates. Synchronization Plans are managed through the SynchronizationPlan Custom Resource Definition.
Live Synchronization
Live Synchronization replicates the contents of a source database to a destination one in near real time. This option is the most appropiate to establish a warm-standy, pilot light or active to active resiliency architecture.
This option minimises RPO and RTO due to the minimal amount of data lost before a disaster and the low overhead and wait time to restart operations in the new instance.
Live Synchronization is managed with the Custom Resource Definition LiveSynchronization.