Isolation pour Cloud Service Mesh

Cette page 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 compatibilité d'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 en cascade par région pour déterminer où le trafic utilisateur doit être acheminé. Avec cet algorithme, Cloud Service Mesh achemine le trafic vers la région la plus proche jusqu'à ce que les backends atteignent leur limite de capacité configurée. Ensuite, le trafic commencera à déborder dans une région plus éloignée.

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

diagramme d'isolation

L'utilisation ou non 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 gérer le trafic. Cela signifie que chaque région individuelle est plus susceptible d'être surchargée en raison du trafic supplémentaire, et vous devez 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 backends de diffusion dans la même région.

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

Isolation la plus proche

L'isolation régionale la plus proche est celle où un frontend avec des backends colocalisés est isolé uniquement dans cette région. Si aucun backend n'est disponible dans l'emplacement local, il sera connecté à la région du backend tout en optimisant la latence du réseau.

Diagramme d'isolation la plus proche

Isolation stricte

L'isolation régionale stricte est celle où les emplacements de frontend ne peuvent atteindre que les backends de la région locale. Les frontends sans backends de diffusion dans la région locale abandonneront tout leur trafic.

Diagramme de l'isolation stricte

Activer l'isolation

gcloud

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

  1. Exécutez la commande suivante pour créer une 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.

    S'il n'est pas explicitement fourni, NEAREST est la valeur par défaut. Notez que vous ne pouvez spécifier ce champ que si l'indicateur --isolation-granularity est également défini.

    Vous pouvez également mettre à jour une stratégie existante à 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 stratégie existante.

  2. Une fois qu'une ressource serviceLbPolicy est 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é, vous avez deux options :

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

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 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é offre une compatibilité d'isolation. Par conséquent, le trafic ne sera pas transféré vers une région distante si la région locale est pleine. Ainsi, certains de vos backends peuvent être surchargés si cette fonctionnalité est activée. Si ce n'est pas le comportement souhaité, envisagez de désactiver cette fonctionnalité. Vous pouvez également envisager d'activer l'autoscaling pour mieux gérer les surcharges de 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é, le trafic a peut-être déjà été transféré vers une région distante. Dans ce cas, l'activation de cette fonctionnalité peut entraîner le transfert 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 transfert 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 transféré si de nouveaux backends sont ajoutés à une région. Ce comportement est normal, car Cloud Service Mesh tente d'acheminer le trafic vers ces backends afin d'optimiser la latence globale du réseau. 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.

Les requêtes ont échoué

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