Implement active zone-redundancy using an MSE cloud-native gateway

Disaster recovery overview

Cloud disaster recovery is classified into the following three main types:

• Same-City Cross-AZ Disaster Recovery

  Zone-disaster recovery includes active-active and active-standby disaster recovery. Data centers in the same city are physically close, which results in low network latency. This helps prevent zone-level disasters, such as fires, network disconnections, or power outages.

• Cross-region active-active disaster recovery

  Cross-region active-active disaster recovery has relatively high network latency. However, it can prevent regional disasters, such as earthquakes and floods.

• Two-region three-data-center architecture

  The two-region three-data-center architecture combines dual data centers in the same city with cross-region disaster recovery. This architecture combines the advantages of both methods and is suitable for scenarios that require high application continuity, data continuity, and availability.

In practice, zone-disaster recovery is easier to implement for data than cross-region disaster recovery. Therefore, zone-disaster recovery remains an important strategy.

Features and benefits

A disaster recovery plan that uses a cloud-native gateway has the following advantages over a plan that uses the Domain Name System (DNS) for traffic distribution:

• Cloud-native gateways are deployed across multiple zones by default and provide global traffic management at the region level.

• A disaster recovery plan that uses DNS for traffic distribution requires you to manually adjust the traffic ratio for each cluster. In contrast, a plan that uses a cloud-native gateway dynamically adjusts the traffic ratio for each cluster based on the total number of workloads. For scenarios where peer deployment cannot be guaranteed, this helps prevent backend services from crashing in clusters with fewer deployed resources.

• Disaster recovery that uses a multi-cluster gateway supports Layer 7 routing and forwarding, whereas disaster recovery that uses DNS for traffic distribution does not.

• In a disaster recovery plan that uses DNS for traffic distribution, client-side caching during an IP address switchover often causes temporary service unavailability. In contrast, a plan that uses a cloud-native gateway can smoothly fail over traffic to the backend service of another cluster.

Architecture

With the global traffic management capability of a cloud-native gateway across zones in the same region, if a single zone (Zone I) fails, 100% of the traffic is automatically routed to another zone (Zone J).

Preparations

1. Create two Nacos engines.

2. Create a Kubernetes (K8s) cluster in each of two different zones. For more information, see Create an ACK managed cluster.

If a Kubernetes (K8s) cluster that you use for active zone-redundancy is a self-managed cluster in an IDC or on another cloud platform, you can connect the on-premises cluster to the cloud by following the ACK One Quick Start for registered clusters. In this topic, the K8s cluster in Zone I is a self-managed cluster that is connected to the cloud as a registered cluster.

Procedure for connecting a self-managed K8s cluster to the cloud

1. Create a self-managed K8s cluster using kubeadm.

   

2. Check the cluster network mode. The cluster uses the Calico network plug-in, and the network mode is Calico IPIP.

   

3. Connect the self-managed cluster as a registered cluster. For more information, see Connect a target cluster to a registered cluster.

4. The self-managed K8s cluster uses the Calico IPIP network mode, which requires traffic from cloud resources to pods to be forwarded through a node. After you connect the cluster, you must add a route entry to the VPC route table that maps the pod CIDR block to the node.

   Note

   Establish network connectivity as needed. For more information, see Hybrid cloud networking overview.

3. Create a cloud-native gateway.

   Note

   When you create the cloud-native gateway, select multi-zone deployment. Make sure that the new cloud-native gateway and your clusters are in the same VPC.

Video tutorial

Step 1: Deploy the demo application in the clusters

1. Log on to the Container Service for Kubernetes (ACK) console. Use the following YAML files to deploy the demo application in the ACK clusters that are in different zones. Replace the values of nacos_address and env with your actual environment parameters.

   Deployment YAML for Zone I

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: duohuo-provider
     labels:
       app: duohuo-provider
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: duohuo-provider
     template:
       metadata:
         labels:
           app: duohuo-provider
       spec:
         containers:
           - env:
               - name: nacos_address #Endpoint of the service registry
                 value: 'mse-a8473b30-nacos-ans.mse.aliyuncs.com:8848' 
               - name: env  #Zone identifier, for example, izone or jzone
                 value: izone
             image: 'registry.cn-hangzhou.aliyuncs.com/jinfengdocker/mse-duohuo-provider:v1'
             imagePullPolicy: Always
             name: duohuo-provider
             ports:
               - containerPort: 8080
                 protocol: TCP
             resources:
               limits:
                 cpu: '2'
                 memory: 1Gi
               requests:
                 cpu: '0.5'
                 memory: 0.1Gi
   ---
   apiVersion: apps/v1         
   kind: Deployment
   metadata:
     name: duohuo-consumer
     labels:
       app: duohuo-consumer
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: duohuo-consumer
     template:
       metadata:
         labels:
           app: duohuo-consumer
       spec:
         containers:
           - env:
               - name: nacos_address #Endpoint of the service registry
                 value: 'mse-a8473b30-nacos-ans.mse.aliyuncs.com:8848' 
               - name: env  #Zone identifier, for example, izone or jzone
                 value: izone
             image: 'registry.cn-hangzhou.aliyuncs.com/jinfengdocker/mse-duohuo-consumer:v1'
             imagePullPolicy: Always
             name: duohuo-consumer
             ports:
               - containerPort: 8080
                 protocol: TCP
             resources:
               limits:
                 cpu: '2'
                 memory: 1Gi
               requests:
                 cpu: '0.5'
                 memory: 0.1Gi
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: duohuo-consumer-service
   spec:
     ports:
       - name: http
         port: 8080
         protocol: TCP
         targetPort: 8080
     selector:
       app: duohuo-consumer
     sessionAffinity: None
     type: ClusterIP

   Deployment YAML for Zone J

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: active-redundancy-provider
     labels:
       app: active-redundancy-provider
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: active-redundancy-provider
     template:
       metadata:
         labels:
           app: active-redundancy-provider
       spec:
         containers:
           - env:
               - name: nacos_address # The endpoint of the registry.
                 value: 'mse-7a4cd080-nacos-ans.mse.aliyuncs.com:8848' 
               - name: env  # The zone identifier, such as izone or jzone.
                 value: jzone
             image: 'registry.cn-hangzhou.aliyuncs.com/jinfengdocker/mse-active-redundancy-provider:v1'
             imagePullPolicy: Always
             name: active-redundancy-provider
             ports:
               - containerPort: 8080
                 protocol: TCP
             resources:
               limits:
                 cpu: '2'
                 memory: 1Gi
               requests:
                 cpu: '0.5'
                 memory: 0.1Gi
   ---
   apiVersion: apps/v1         
   kind: Deployment
   metadata:
     name: active-redundancy-consumer
     labels:
       app: active-redundancy-consumer
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: active-redundancy-consumer
     template:
       metadata:
         labels:
           app: active-redundancy-consumer
       spec:
         containers:
           - env:
               - name: nacos_address # The endpoint of the registry.
                 value: 'mse-7a4cd080-nacos-ans.mse.aliyuncs.com:8848' 
               - name: env  # The zone identifier, such as izone or jzone.
                 value: jzone
             image: 'registry.cn-hangzhou.aliyuncs.com/jinfengdocker/mse-active-redundancy-consumer:v1'
             imagePullPolicy: Always
             name: active-redundancy-consumer
             ports:
               - containerPort: 8080
                 protocol: TCP
             resources:
               limits:
                 cpu: '2'
                 memory: 1Gi
               requests:
                 cpu: '0.5'
                 memory: 0.1Gi
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: active-redundancy-consumer-service
   spec:
     ports:
       - name: http
         port: 8080
         protocol: TCP
         targetPort: 8080
     selector:
       app: active-redundancy-consumer
     sessionAffinity: None
     type: ClusterIP

2. After the deployment is successful, two workloads and one service appear in the corresponding ACK cluster.

Step 2: Create sources

Create two service sources in the cloud-native gateway and associate them with the container clusters in the two zones. For more information, see Create a service source.

Step 3: Create a service

Create a service in the cloud-native gateway. For more information, see Add a service.

The cloud-native gateway supports unified management of services across clusters. When you create a service, services that have the same name in the same namespace across the two K8s clusters are automatically merged.

Step 4: Create a routing rule in the cloud-native gateway

Create a routing rule in the cloud-native gateway and set the domain name and matching rule. Select the destination service, and then save and publish the routing rule. For more information, see Create a routing rule.

Step 5: Verify the traffic switching effect

The cloud-native gateway can dynamically adjust traffic based on the number and health status of workloads in the backend clusters. This topic demonstrates the automatic traffic switching effect of the cloud-native gateway in scenarios with peer deployment, non-peer deployment, and data center failure.

Use the following shell script to send requests to the gateway in a loop.

#!/bin/bash
for (( i = 1; i < 1000000000; i++ )); do
      curl http://114.55.XXX.XXX/helloActiveRedundancy  # Replace the IP address with the public IP address of your gateway.
      sleep 1
      echo
done