Help Center/ Distributed Cache Service/ Service Overview/ Disaster Recovery and Multi-Active Solution
Updated on 2024-09-30 GMT+08:00

Disaster Recovery and Multi-Active Solution

Whether you use DCS as the frontend cache or backend data store, DCS is always ready to ensure data reliability and service availability. The following figure shows the evolution of DCS DR architectures.

Figure 1 DCS DR architecture evolution

To meet the reliability requirements of your data and services, you can choose to deploy your DCS instance within a single AZ or across AZs.

Single-AZ HA Within a Region

Single-AZ deployment means deploying an instance within a physical equipment room. DCS provides process/service HA, data persistence, and hot standby DR policies for different types of DCS instances.

Single-node DCS instance: When DCS detects a process fault, a new process is started to ensure service HA.

Figure 2 HA for a single-node DCS instance deployed within an AZ

Master/Standby, read/write splitting, or cluster DCS instance: By default, data is persisted to disk on the master node and incrementally synchronized and persisted to the standby node, achieving hot standby and data persistence.

The following figure shows the data synchronization and persistence of the master and standby node processes, including the processes of master/standby and read/write splitting instances and each shard of cluster instances.

Figure 3 HA among master and standby nodes within an AZ

Cross-AZ DR Within a Region

The master and standby nodes of a DCS instance (single-node type not included) can be deployed across AZs (in different equipment rooms). Power supplies and networks of different AZs are physically isolated. When a fault occurs in the AZ where the master node is deployed, the standby node connects to the client and takes over data read and write operations.

Figure 4 Cross-AZ deployment of a master/standby DCS instance
Figure 5 Cross-AZ deployment of a read/write splitting DCS instance
Figure 6 Cross-AZ deployment of a Proxy Cluster DCS instance
Figure 7 Cross-AZ deployment of a Redis Cluster DCS instance

When creating a master/standby, cluster, or read/write splitting DCS instance, select a standby AZ that is different from the master AZ as shown below.

Figure 8 Selecting different AZs

You can also deploy your application across AZs to ensure both data reliability and service availability in the event of power supply or network disruptions.

Cross-Region Multi-Active

Currently, HUAWEI CLOUD DCS does not support cross-region multi-active because Redis does not have a mature active-active solution. Active-active is different from disaster recovery or master/standby HA.

Redis active-active across clouds or regions cannot be achieved because the customized REdis Serialization Protocols (RESP) are not unified. If active-active is required, it can be implemented through dual-write on the application end.

Figure 9 Dual-write on the application side to achieve multi-active

Note:

  1. The dual-write solution cannot ensure cache consistency (due to network problems). Applications need to tolerate cache inconsistency (by setting the time to live to achieve eventual consistency). If applications require strong cache consistency, this solution is not suitable. Currently, there is no solution in the industry to ensure strong cross-region cache consistency.
  2. You are advised to perform operations on the cross-region L2 cache in asynchronous mode.