Multi-Cloud/-Cluster Application Failover

Scenario

Distributed clusters are often deployed on the clouds or regions nearest to users. UCS allows you to manage application traffic and data for failover, scheduling, and migration across clouds and clusters. Figure 1 shows how UCS switches traffic from a faulty cluster to ensure service continuity.

Figure 1 Application failover in multi-cloud clusters

Constraints and Limitations

• You have two available clusters of version 1.19 or later, and each cluster must have at least one available node.
• You have added a public zone to Huawei Cloud DNS. For details, see Routing Internet Traffic to a Website.

Setting Up the Basic Environment

1. Register clusters to UCS and configure cluster access. For details, see Registering a Cluster.

   For example, connect clusters ccecluster01 and ccecluster02 to UCS and check whether the clusters are running properly.

2. Create a workload in each connected cluster.
   

   In this example, we use container images with different tags to create workloads, aiming to show you more clearly how app traffic is switched.

   • Cluster ccecluster01: Use image tag 1.0.0.
   • Cluster ccecluster02: Use image tag 2.0.0.
   Figure 2 Creating a workload
   

3. Create a LoadBalancer Service for the workloads in these two clusters.
   

   Only LoadBalancer Services are supported and displayed.

   Figure 3 Creating a Service
   

4. Use a browser to access the IP of the LoadBalancer Service to check the deployment result.
   Figure 4 Checking the deployment result
   

Verifying Failover

You have deployed applications in clusters ccecluster01 and ccecluster02 and allowed external access via LoadBalancing Services.

The following describes how to distribute app traffic to realize failover and ensure high availability.

In this example, example clusters and workloads are not limited in terms of service providers, regions, and quantity.

1. Log in to the UCS console. In the navigation pane, choose Traffic Distribution.
2. Click Create Traffic Policy. Enter the domain name (use demo.example.com here).
   Figure 5 Creating a traffic policy
   

3. Add scheduling policies for the two clusters, and then click OK.

   In this example, three scheduling policies are added to simulate cluster application deployment in different regions:

   • For ccecluster01, set Line Type to Region line - Global/Asia Pacific/Singapore.
   • For ccecluster02, set Line Type to Region line - Chinese Mainland/South China/Guangdong.
   • Add a default line for the domain name. For ccecluster01, set Line Type to Default. If no default line is added for the domain name, users in regions beyond the specified lines cannot access the applications.
   Figure 6 Adding a scheduling policy
   

4. View the scheduling policies. Three policies have been added for demo.example.com. User traffic can access applications in the two clusters based on the configured line type and weight.
   Figure 7 Viewing scheduling policies
   
   • Users in Singapore region will access the application of version 1.0.0 in ccecluster01.
   • Users in Guangdong region will access the application of version 2.0.0 in ccecluster02.
   • Users in other regions will access the application of version 1.0.0 in ccecluster01 by default.

5. A user in Guangdong visits demo.example.com to access the application. The response shows that the user is accessing the application in ccecluster02 (version 2.0.0).
   Figure 8 Checking the access result
   

6. Manually stop the application in ccecluster02 and change the number of pods to 0 to simulate a fault.
   Figure 9 Adjusting the pod quantity
   

7. When a user in Guangdong accesses the application, the request is still sent to ccecluster02 and an error is returned.

   In this case, click Suspend for the corresponding scheduling policy of ccecluster02 on the Traffic Distribution page to perform an application failover.

   Figure 10 Suspending a scheduling policy
   

   After that, the subsequent access requests of this user will be sent to ccecluster01 through the default line, and the access becomes normal. After the faulty cluster is recovered, you can click Enable to enable the policy again.