Service Mesh Disaster Recovery Series: Region-level disaster recovery with ASM and GTM - Alibaba Cloud Service Mesh

Une panne régionale est une interruption majeure susceptible de perturber vos services cloud. Lorsqu'elle survient, les services dans n'importe laquelle des zones de disponibilité concernées risquent des échecs de connexion, une perte de données et une indisponibilité des charges de travail.Service Mesh (ASM) vous permet de déployer une passerelle d'entrée ASM dans un cluster Kubernetes ou une Elastic Container Instance (ECI) en tant que point d'entrée de trafic unifié pour vos applications. Chaque cluster dispose d'une adresse IP dédiée pour sa passerelle d'entrée. En cas de défaillance d'une région, l'adresse IP défectueuse est supprimée et tout le trafic est redirigé vers la région saine pour assurer la reprise après sinistre au niveau régional.

Architecture de reprise après sinistre

Cette section décrit une architecture de reprise après sinistre bi-régionale et bi-cluster afin d'illustrer la gestion des pannes régionales :

Configurez une architecture de plan de contrôle multi-master en déployant un cluster Kubernetes dans chacune des deux régions. Déployez des services cloud-native identiques dans les deux clusters. Les services communiquent entre eux via les noms de domaine des clusters Kubernetes.

Remarque
Un plan de contrôle multi-master garantit une latence de transmission prévisible et adaptée à la production pour les proxies du maillage dans chaque région. Il assure également la haute disponibilité du plan de contrôle pour la reprise après sinistre en cas de défaillance régionale.
Déployez une passerelle ASM dans chaque cluster et configurez-la pour exposer une adresse IP d'entrée publique ou un nom de domaine via un Classic Load Balancer (CLB) ou un Network Load Balancer (NLB). Utilisez ensuite Alibaba Cloud DNS et Global Traffic Manager (GTM) pour résoudre un nom de domaine vers les deux adresses IP.
En cas de panne régionale, les services de la région saine ne sont pas affectés. Global Traffic Manager (GTM) supprime automatiquement l'adresse IP de la région défaillante du pool de résolution DNS et achemine tout le trafic vers la passerelle ASM de la région saine.

En cas de pic de trafic, configurez les fonctionnalités suivantes pour optimiser davantage la redirection du trafic après une panne régionale.

Activez HPA pour la passerelle ASM afin de mettre à l'échelle automatiquement les instances et gérer les pics de trafic.

Remarque
La fonctionnalité HPA est disponible uniquement sur les éditions Enterprise et Ultimate d'ASM.
Configurez la limitation de débit pour la passerelle ASM ou les services critiques du cluster. La fonctionnalité de limitation locale d'ASM empêche les pics de trafic de submerger les services de votre cluster, évitant ainsi les pannes de service dans la région saine dues à un transfert massif de trafic.
(Facultatif) Configurez la surveillance des métriques et les alertes pour la fonctionnalité de limitation d'ASM. Cela vous permet d'observer les événements en temps réel, de détecter rapidement les pannes et de mettre à l'échelle rapidement les charges de travail dans la région saine.

Flux de travail de reprise après sinistre

La reprise après sinistre inter-régions est prise en charge pour tous les types de clusters. Ce tutoriel utilise un cluster managé ACK pour illustrer le processus de création des clusters et des instances ASM, la configuration de la reprise après sinistre et l'exécution d'un test de panne.

Configuration de la reprise après sinistre

Ce tutoriel utilise une passerelle d'entrée de type CLB à titre d'exemple. Pour plus d'informations sur l'intégration d'une passerelle d'entrée de type NLB avec GTM, consultez la rubrique Connecter un nom de domaine métier à GTM.

Étape 1 : Configurer un plan de contrôle multi-master

Dans deux régions différentes, créez deux clusters nommés cluster-1 et cluster-2, et activez l'option Expose API server with EIP. Pour plus d'informations, consultez la rubrique Créer un cluster managé ACK.
Dans les mêmes régions que les clusters, créez deux instances Service Mesh, mesh-1 et mesh-2. Ajoutez cluster-1 et cluster-2 aux instances ASM respectives pour construire un maillage de services avec une architecture de plan de contrôle multi-master. Pour plus d'informations, reportez-vous aux étapes 1 et 2 de la rubrique Implémenter la reprise après sinistre multi-cluster en utilisant une architecture de plan de contrôle multi-master ASM.

Étape 2 : Déployer la passerelle d'entrée et l'application

Dans les deux instances ASM, créez une passerelle d'entrée ASM nommée ingressgateway. Pour plus d'informations, consultez la rubrique Créer une passerelle d'entrée.
Dans les clusters cluster-1 et cluster-2, déployez l'application exemple Bookinfo. Pour plus d'informations, consultez la rubrique Déployer une application dans un cluster associé à une instance ASM.
Dans les deux instances ASM, créez une ressource Gateway et un service virtuel pour utiliser la passerelle ASM comme point d'entrée du trafic pour l'application Bookinfo. Pour plus d'informations, consultez la rubrique Utiliser les ressources Istio pour router le trafic en fonction des versions.
Activez globalement la rétention du trafic local au cluster pour les deux instances ASM. Pour plus d'informations, consultez la rubrique Activer la fonctionnalité de rétention du trafic local au cluster au niveau global.

Remarque
Dans un scénario de reprise après sinistre au niveau de la région, le trafic doit rester au sein d'un seul cluster. Par défaut, si deux clusters Kubernetes ou plus sont ajoutés à la même instance de maillage de services, le mécanisme d'équilibrage de charge du maillage peut router les appels vers les services du cluster pair. L'activation de la rétention du trafic local au cluster maintient les requêtes pour un service au sein de son propre cluster et empêche les appels inter-clusters.

(Facultatif) Étape 3 : Vérifier l'état du service

Obtenez les adresses IP publiques des deux passerelles ASM. Vous les utiliserez pour vérifier l'état du service et configurer GTM ultérieurement. Pour plus d'informations, consultez la rubrique Obtenir l'adresse de la passerelle d'entrée.

Utilisez les fichiers kubeconfig des clusters cluster-1 et cluster-2 pour afficher les noms des pods du service reviews.

kubectl get pod| grep reviews

Résultat attendu :

reviews-v1-5d99dxxxxx-xxxxx       2/2     Running   0          3d17h
reviews-v2-69fbbxxxxx-xxxxx       2/2     Running   0          3d17h
reviews-v3-8c44xxxxx-xxxxx        2/2     Running   0          3d17h

Dans la barre d'adresse de votre navigateur, saisissez successivement http://{IP_address_of_mesh-1_ingress_gateway}/productpage et http://{IP_address_of_mesh-2_ingress_gateway}/productpage. Actualisez la page 10 fois pour accéder à l'application Bookinfo.

Chaque actualisation de la page affiche une version différente du service reviews (v1, v2 ou v3). Les trois versions du service reviews dans les deux clusters correspondent aux noms des pods affichés dans le résultat de l'étape précédente. Cela indique que les services fonctionnent comme prévu et que la fonctionnalité de rétention du trafic local au cluster est opérationnelle.

Les versions des services sont visuellement distinctes : la version reviews-v1 n'affiche pas les notes sous forme d'étoiles, la version reviews-v2 affiche des étoiles noires et la version reviews-v3 affiche des étoiles rouges.

Étape 4 : Configurer GTM

Utilisez les deux adresses IP publiques obtenues comme adresses IP d'entrée de trafic pour l'application et configurez l'équilibrage de charge actif-actif et la reprise après sinistre dans GTM. Pour plus d'informations, consultez la rubrique Comment GTM implémente l'équilibrage de charge actif-actif et la reprise après sinistre.

Une fois la configuration terminée, l'architecture ressemble à l'illustration suivante :

(Facultatif) Étape 5 : Configurer la limitation locale et l'observabilité

Utilisez le contenu YAML suivant pour configurer les règles de limitation locale pour mesh-1 et mesh-2. Pour plus d'informations, consultez la rubrique Configurer la limitation locale pour une passerelle d'entrée.

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMLocalRateLimiter
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  configs:
    - limit:
        fill_interval:
          seconds: 1
        quota: 100
      match:
        vhost:
          name: '*'
          port: 80
          route:
            name_match: gw-to-productage
  isGateway: true
  workloadSelector:
    labels:
      istio: ingressgateway

Configurez la collecte de métriques et les alertes pour la limitation locale pour les deux instances ASM. Pour plus d'informations, consultez la rubrique Configurer la collecte de métriques et les alertes pour la limitation locale.

Test de panne

Ce test utilise l'outil fortio pour exécuter un test de charge sur l'application exemple, simulant l'accès des utilisateurs externes. Pendant le test de charge, supprimez manuellement la charge de travail de la passerelle d'entrée pour simuler une panne régionale et observer le basculement de reprise après sinistre.

Exécutez la commande suivante pour démarrer un test de charge de cinq minutes sur l'application exemple. Remplacez le nom de domaine dans la commande par celui que vous avez configuré dans GTM.
```
fortio load -jitter=False  -c 1 -qps 100 -t 300s -keepalive=False -a http://{your_domain_name}/productpage
```
Pendant l'exécution du test de charge, simulez une panne régionale dans cluster-2.
1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Deployments.
3. Dans la liste déroulante Namespace, sélectionnez istio-system.
4. Dans la liste des charges de travail, repérez istio-ingressgateway. Dans la colonne Actions, cliquez sur More > Delete.

Attendez la fin du test de charge. Le résultat attendu est le suivant :

# range, mid point, percentile, count
>= -261.054 <= -0.0693516 , -130.561 , 100.00, 3899
# target 50% -130.595
WARNING 100.00% of sleep were falling behind
Aggregated Function Time : count 3899 avg 0.076910055 +/- 0.02867 min 0.062074583 max 1.079674 sum 299.872304
# range, mid point, percentile, count
>= 0.0620746 <= 0.07 , 0.0660373 , 19.34, 754
> 0.07 <= 0.08 , 0.075 , 71.94, 2051
> 0.08 <= 0.09 , 0.085 , 96.08, 941
> 0.09 <= 0.1 , 0.095 , 99.23, 123
> 0.1 <= 0.12 , 0.11 , 99.62, 15
> 0.12 <= 0.14 , 0.13 , 99.82, 8
> 0.14 <= 0.16 , 0.15 , 99.92, 4
> 1 <= 1.07967 , 1.03984 , 100.00, 3
# target 50% 0.0758289
# target 75% 0.0812673
# target 90% 0.0874825
# target 99% 0.0992691
# target 99.9% 0.155505
Error cases : count 527 avg 0.074144883 +/- 0.07572 min 0.062074583 max 1.079674 sum 39.0743532
# range, mid point, percentile, count
>= 0.0620746 <= 0.07 , 0.0660373 , 82.54, 435
> 0.07 <= 0.08 , 0.075 , 96.58, 74
> 0.08 <= 0.09 , 0.085 , 99.05, 13
> 0.09 <= 0.1 , 0.095 , 99.24, 1
> 0.12 <= 0.14 , 0.13 , 99.43, 1
> 1 <= 1.07967 , 1.03984 , 100.00, 3
# target 50% 0.0668682
# target 75% 0.0692741
# target 90% 0.0753108
# target 99% 0.0897923
# target 99.9% 1.06568
# Socket and IP used for each connection:
[0] 3900 socket used, resolved to [39.XXX.XXX.160:80 (3373), 106.XXX.XXX.73:80 (527)], connection timing : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
Connection time histogram (s) : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
# range, mid point, percentile, count
>= 0.027057 <= 0.03 , 0.0285285 , 13.28, 518
> 0.03 <= 0.035 , 0.0325 , 62.79, 1931
> 0.035 <= 0.04 , 0.0375 , 83.95, 825
> 0.04 <= 0.045 , 0.0425 , 86.13, 85
> 0.045 <= 0.05 , 0.0475 , 86.18, 2
> 0.05 <= 0.06 , 0.055 , 86.28, 4
> 0.06 <= 0.07 , 0.065 , 98.03, 458
> 0.07 <= 0.08 , 0.075 , 99.77, 68
> 0.08 <= 0.09 , 0.085 , 99.92, 6
> 1 <= 1.07747 , 1.03874 , 100.00, 3
# target 50% 0.0337079
# target 75% 0.0378848
# target 90% 0.0631659
# target 99% 0.0755882
# target 99.9% 0.0885
Sockets used: 3900 (for perfect keepalive, would be 1)
Uniform: false, Jitter: false, Catchup allowed: true
IP addresses distribution:
39.XXX.XXX.160:80: 3373
106.XXX.XXX.73:80: 527
Code  -1 : 527 (13.5 %)
Code 200 : 3372 (86.5 %)
Response Header Sizes : count 3899 avg 178.19851 +/- 70.45 min 0 max 207 sum 694796
Response Body/Total Sizes : count 3899 avg 4477.7081 +/- 1822 min 0 max 5501 sum 17458584
All done 3899 calls (plus 1 warmup) 76.910 ms avg, 13.0 qps

Le résultat montre que bien que quelques requêtes aient échoué pendant la simulation de la panne régionale, la plupart ont réussi. Cela démontre que la combinaison d'ASM et de GTM assure efficacement la reprise après sinistre en cas de panne régionale.

Dans la console GTM, vérifiez l'état du nom de domaine d'accès. L'adresse IP pour cluster-2 est indiquée comme indisponible.

Vous pouvez également configurer des alertes pour être notifié lorsqu'une adresse IP devient indisponible, ce qui vous permet de la supprimer manuellement. Pour plus d'informations, consultez la rubrique Configurer des alertes.