Cloud Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Isolation pour Cloud Service Mesh

Cette page vous explique comment configurer votre maillage de services avec une meilleure isolation des requêtes pour votre service de backend en créant une configuration d'isolation.

Cette fonctionnalité offre une isolation supplémentaire pour les backends de vos services afin d'éviter les débordements interrégionaux.

Par défaut, Cloud Service Mesh utilise l'algorithme cascade par région pour déterminer où acheminer le trafic utilisateur. Avec cet algorithme, Cloud Service Mesh achemine le trafic vers la région la plus proche jusqu'à ce que les backends fonctionnent à leur limite de capacité configurée. Passé ce seuil, le trafic commencera à déborder vers une région plus éloignée.

Grâce à cette fonctionnalité, le trafic est limité à la région la plus proche ou locale en fonction de votre région de frontend et de la configuration de l'isolation. Il ne débordera pas si la région la plus proche manque de capacité. Cela vous aide à éviter les défaillances en cascade potentielles et à limiter les éventuelles pannes dans la même région. Sinon, vous gérez toujours la configuration de votre service au niveau mondial.

diagramme d'isolation

L'utilisation de cette fonctionnalité dépend de vos cas d'utilisation réels. Vous devez examiner attentivement les points suivants avant de l'utiliser :

Si vos backends d'une région sont surchargés, Cloud Service Mesh peut toujours leur envoyer du trafic supplémentaire, même si les backends d'autres régions peuvent le gérer. Cela signifie que chaque région individuelle est plus susceptible de surcharger en raison du trafic supplémentaire. Vous devez donc planifier en conséquence.
Votre trafic est toujours acheminé avec un plan de contrôle mondial. Cela signifie qu'il existe toujours un risque de défaillances coordonnées à l'échelle mondiale dans plusieurs régions.
Cette fonctionnalité est configurée avec la ressource serviceLbPolicy. Toutes les restrictions s'appliquent toujours.
Avec le mode d'isolation STRICT, les requêtes échouent s'il n'y a pas de backend de diffusion dans la même région.

Deux scénarios sont possibles après l'application de cette fonctionnalité :

Isolement le plus proche

L'isolation régionale la plus proche consiste à isoler un frontend avec des backends colocalisés dans cette seule région. Si aucun backend n'est disponible dans la région locale, il sera connecté à la région du backend tout en optimisant la latence du réseau.

Diagramme d'isolation le plus proche

Isolement strict

L'isolation régionale stricte est une configuration dans laquelle les emplacements de l'interface ne peuvent accéder qu'aux backends de la région locale. Les frontends sans backends de diffusion dans la région locale abandonneront tout leur trafic.

Diagramme d'isolation stricte

Activer l'isolation

gcloud

Procédez comme suit pour créer une configuration d'isolation à l'aide de la Google Cloud CLI.

Exécutez la commande suivante pour créer un serviceLbPolicy :
```
gcloud network-services service-lb-policies create my-isolation-policy \
    --isolation-config-granularity=REGION \
    --isolation-config-mode=ISOLATION_MODE \
    --location=global
```
Remplacez ISOLATION_MODE par l'une des options suivantes :
1. NEAREST : le trafic est envoyé à la région la plus proche.
2. STRICT : le trafic échoue si aucun backend de diffusion n'est disponible dans la même région que le frontend.
Si aucune valeur n'est explicitement fournie, NEAREST est la valeur par défaut. Notez que vous ne pouvez spécifier ce champ que si l'option --isolation-granularity est également définie.

Si vous disposez déjà d'une règle, vous pouvez également la mettre à jour à l'aide de la commande suivante :
```
gcloud network-services service-lb-policies update POLICY_NAME \
    --isolation-config-granularity=REGION \
    --isolation-config-mode=ISOLATION_MODE \
    --location=global
```
Remplacez POLICY_NAME par le nom de votre règle existante.
Une fois la ressource serviceLbPolicy créée ou mise à jour, associez-la à votre ressource backendService :
```
  gcloud compute backend-services update BACKEND_SERVICE_NAME \
  ‐‐service-lb-policy POLICY_URL
```
Remplacez BACKEND_SERVICE_NAME par le nom de votre service de backend.

Désactiver l'isolation

Pour désactiver cette fonctionnalité, deux options s'offrent à vous :

Définissez isolationConfigs sur "non spécifié".
Supprimez ServiceLbPolicy du service s'il s'agit de la seule fonctionnalité que vous avez activée avec cette règle.

Définir `isolationConfigs` sur "Non spécifié"

Exécutez la commande suivante pour définir isolationConfigs sur "non spécifié" :

gcloud network-services service-lb-policies update my-isolation-policy \
  --isolation-config-granularity=unspecified \
  --isolation-config-mode=unspecified \
  --location=global

Supprimer `ServiceLbPolicy` du service

Exécutez la commande suivante pour supprimer le ServiceLbPolicy :

gcloud network-services service-lb-policies delete my-isolation-policy --location=global

Compatibilité, diagnostic et dépannage

Cette section décrit les problèmes potentiels après l'activation de cette fonctionnalité.

Backends surchargés

Cette fonctionnalité permet d'isoler les régions. Ainsi, le trafic ne sera pas transféré vers une région distante si la région locale est saturée. Par conséquent, certains de vos backends peuvent être surchargés si cette fonctionnalité est activée. Si ce n'est pas le comportement que vous recherchez, envisagez de désactiver cette fonctionnalité. Vous pouvez également envisager d'activer l'autoscaling pour mieux gérer les surcharges du backend.

Le trafic a été transféré

Cette fonctionnalité empêche le débordement du trafic en fonction de la capacité. Par conséquent, si vos backends étaient surchargés avant l'activation de cette fonctionnalité, il est possible que le trafic ait déjà été transféré vers une région distante. Dans ce cas, l'activation de cette fonctionnalité pourrait entraîner le retour de ce trafic.

Le trafic n'a pas été transféré

Cette fonctionnalité empêche le débordement du trafic en fonction de la capacité. Par conséquent, si vos backends n'étaient pas surchargés avant l'activation de cette fonctionnalité, il est probable que la région la plus proche soit en mesure de gérer tout le trafic. Dans ce cas, l'activation de cette fonctionnalité peut ne pas entraîner de changement de trafic à court terme.

Le trafic a été transféré après l'ajout ou la suppression de backends dans une région.

Lorsque cette fonctionnalité est activée, le trafic peut être déplacé si de nouveaux backends sont ajoutés à une région. C'est le comportement attendu, car Cloud Service Mesh tentera de router le trafic vers ces backends pour optimiser la latence réseau globale. De même, lorsque les derniers backends sont supprimés, Cloud Service Mesh commence à envoyer du trafic vers une région distante. Il s'agit également d'un comportement normal.

Échec des demandes

Si le mode d'isolation STRICT est activé et qu'aucun backend n'est disponible dans la même région que le frontend, le trafic devrait échouer. Si ce n'est pas le comportement attendu, assurez-vous d'avoir des backends dans chacune des régions où vous prévoyez d'envoyer du trafic.