Basculement pour les équilibreurs de charge réseau passthrough internes

Vous pouvez configurer un équilibreur de charge réseau passthrough interne pour répartir les connexions entre plusieurs instances de machines virtuelles (VM) dans des backends principaux puis, si nécessaire, avoir recours à des backends de basculement. Avec le basculement, vous disposez d'une méthode permettant d'augmenter la disponibilité tout en étant mieux à même de contrôler la gestion de votre charge de travail lorsque les VM de vos backends principaux ne sont pas opérationnelles.

Cette page décrit les concepts et les exigences spécifiques au basculement pour les équilibreurs de charge réseau à stratégie interne. Avant de configurer le basculement pour les équilibreurs de charge réseau passthrough internes, assurez-vous de connaître les concepts présentés dans les articles suivants :

Ces concepts sont importants à comprendre, car la configuration du basculement modifie l'algorithme de répartition du trafic standard de l'équilibreur de charge réseau passthrough interne.

Par défaut, lorsque vous ajoutez un backend à un service de backend de l'équilibreur de charge réseau passthrough interne, ce backend est un backend principal. Vous pouvez désigner un backend comme backend de basculement lorsque vous l'ajoutez au service de backend de l'équilibreur de charge, ou en modifiant le service de backend ultérieurement. Les backends de basculement ne reçoivent les connexions de l'équilibreur de charge qu'après qu'un taux configurable de VM principales n'a pas réussi les vérifications d'état.

Groupes d'instances compatibles

Les groupes d'instances gérés et non gérés sont acceptés comme backends. Pour des raisons de simplicité, les exemples figurant sur cette page présentent des groupes d'instances non gérés.

L'utilisation de groupes d'instances gérés avec l'autoscaling et le basculement peut entraîner une répétition des opérations de basculement et de restauration du pool actif entre les backends principaux et de basculement. Google Cloud ne vous empêche pas de configurer le basculement avec les groupes d'instances gérés, car cette configuration pourrait être bénéfique pour votre déploiement.

Architecture

L'exemple simple suivant illustre un équilibreur de charge réseau passthrough interne avec un backend principal et un backend de basculement.

Le backend principal est un groupe d'instances non géré dans la zone us-west1-a.
Le backend de basculement est un autre groupe d'instances non géré dans la zone us-west1-c.

Exemple de basculement pour les équilibreurs de charge réseau passthrough interne. — Exemple de basculement pour les équilibreurs de charge réseau passthrough interne (cliquez pour agrandir)

L'exemple suivant représente un équilibreur de charge réseau passthrough interne avec deux backends principaux et deux backends de basculement, les uns comme les autres étant répartis entre deux zones de la région us-west1. Cette configuration augmente la fiabilité, car elle ne dépend pas d'une seule zone pour tous les backends principaux ou de basculement.

Les backends principaux sont les groupes d'instances non gérés ig-a et ig-d.
Les backends de basculement sont les groupes d'instances non gérés ig-b et ig-c.

Basculement de l'équilibreur de charge réseau passthrough interne multizone. — Basculement de l'équilibreur de charge réseau passthrough interne multizone (cliquez pour agrandir).

Lors du basculement, les deux backends principaux deviennent inactifs, tandis que les VM opérationnelles des deux backends de basculement deviennent actives. Pour obtenir une explication complète du fonctionnement du basculement dans cet exemple, consultez la section Exemple de basculement.

VM et groupes d'instances backend

Les groupes d'instances non gérés dans les équilibreurs de charge réseau passthrough internes sont des backends principaux ou des backends de basculement. Vous pouvez désigner un backend comme backend de basculement lorsque vous l'ajoutez au service de backend, ou en le modifiant après l'avoir ajouté. Sinon, les groupes d'instances non gérés sont par défaut des groupes principaux.

Vous pouvez configurer plusieurs backends principaux et plusieurs backends de basculement dans un seul équilibreur de charge réseau passthrough interne en les ajoutant au service de backend de l'équilibreur de charge.

Une VM principale est membre d'un groupe d'instances que vous avez défini comme backend principal. Les VM d'un backend principal participent au pool actif de l'équilibreur de charge (décrit dans la section suivante), sauf si l'équilibreur de charge utilise ses backends de basculement.

Une VM de secours est membre d'un groupe d'instances que vous avez défini comme backend de basculement. Les VM d'un backend de basculement participent au pool actif de l'équilibreur de charge lorsque les VM principales deviennent non opérationnelles. Le nombre de VM non opérationnelles qui déclenchent le basculement est un pourcentage configurable.

Limites

VM : le pool actif peut contenir jusqu'à 250 VM. En d'autres termes, vos groupes d'instances backend principaux peuvent contenir jusqu'à 250 VM principales, et vos groupes d'instances backend de basculement peuvent compter jusqu'à 250 VM de secours.
Groupes d'instances non gérés : vous pouvez avoir jusqu'à 50 groupes d'instances backend principaux et jusqu'à 50 groupes d'instances backend de basculement.

Par exemple, un déploiement maximal pourrait comporter 5 backends principaux et 5 backends de basculement, chaque groupe d'instances contenant 50 VM.

Pool actif

Le pool actif est l'ensemble des VM de backend auquel un équilibreur de charge réseau passthrough interne envoie les nouvelles connexions. L'appartenance des VM de backend au pool actif est calculée automatiquement en fonction des backends qui sont opérationnels et des conditions que vous pouvez spécifier, comme décrit dans la section Taux de basculement.

Le pool actif ne combine jamais les VM principales et les VM de secours. Les exemples suivants clarifient les possibilités d'appartenance. Après le basculement, le pool actif ne contient que des VM de secours. En fonctionnement normal (après la restauration), le pool actif ne contient que des VM principales.

Pool actif pour le basculement et la restauration. — Pool actif pour le basculement et la restauration (cliquez pour agrandir).

Basculement et restauration

Le basculement et la restauration sont des processus automatiques qui permettent d'intégrer des VM de backend dans le pool actif de l'équilibreur de charge ou de les en sortir. Lorsque Google Cloud supprime les VM principales du pool actif et y ajoute des VM de basculement opérationnelles, le processus est appelé basculement. Lorsque Google Cloud effectue l'opération inverse, le processus est appelé restauration.

Stratégie de basculement

Une stratégie de basculement est un ensemble de paramètres que Google Cloud utilise pour le basculement et la restauration. Chaque équilibreur de charge réseau passthrough interne dispose d'une stratégie de basculement dotée de plusieurs paramètres :

Taux de basculement
Suppression du trafic lorsque aucune VM de backend n'est opérationnelle
Drainage de connexion lors du basculement et de la restauration

Taux de basculement

Un taux de basculement configurable détermine à quel moment Google Cloud effectue un basculement ou une restauration, en modifiant l'appartenance au pool actif. Le taux peut être compris entre 0.0 et 1.0 (inclus). Si vous n'indiquez pas de taux de basculement, Google Cloud utilise une valeur par défaut de 0.0. Nous vous recommandons de définir votre taux de basculement en vous servant d'un nombre qui fonctionne pour votre cas d'utilisation plutôt que d'utiliser cette valeur par défaut.

Conditions	VM dans le pool actif
Le taux de basculement (x) est `!= 0.0`. Le taux de VM principales opérationnelles est `>= x`. Le taux de basculement (x) est `= 0.0`. Le nombre de VM principales opérationnelles est `> 0`.	Toutes les VM principales opérationnelles
Si au moins une VM de secours est opérationnelle et que : Le taux de basculement (x) est `!= 0.0`. Le taux de VM principales opérationnelles est `< x`. Le taux de basculement est `= 0.0`. Le nombre de VM principales opérationnelles est `= 0`.	Toutes les VM de secours opérationnelles
Lorsque toutes les VM principales et toutes les VM de secours ne sont pas opérationnelles et que vous n'avez pas configuré votre équilibreur de charge pour supprimer le trafic dans cette situation.	Toutes les VM principales, en dernier recours

Les exemples suivants clarifient l'appartenance au pool actif. Pour obtenir un exemple avec des calculs, consultez la section Exemple de basculement.

Un taux de basculement de 1.0 nécessite que toutes les VM principales soient opérationnelles. Lorsque au moins une VM principale n'est plus opérationnelle, Google Cloud effectue un basculement en faisant passer les VM de secours dans le pool actif.
Un taux de basculement de 0.1 nécessite qu'au moins 10 % des VM principales soient opérationnelles. Sinon, Google Cloud effectue un basculement.
Un taux de basculement de 0.0 signifie que Google Cloud n'effectue un basculement que lorsque aucune VM principale n'est opérationnelle. Le basculement ne se produit pas si au moins une VM principale est opérationnelle.

Un équilibreur de charge réseau passthrough interne répartit les connexions entre les VM du pool actif en fonction de l'algorithme de répartition du trafic.

Suppression du trafic lorsque aucune VM de backend n'est opérationnelle

Par défaut, lorsqu'aucune VM principale et de secours n'est opérationnelle, Google Cloud ne répartit les nouvelles connexions qu'entre les VM principales. Cette opération est effectuée en dernier recours. Les VM de secours sont exclues de cette distribution de connexions de dernier recours.

Si vous préférez, vous pouvez configurer votre équilibreur de charge réseau passthrough interne pour supprimer les nouvelles connexions lorsque toutes les VM principales et de secours ne sont pas opérationnelles.

Drainage de connexion lors du basculement et de la restauration

Le drainage de connexion permet aux sessions TCP existantes de rester actives pendant une période pouvant atteindre une durée configurable, même lorsque les VM de backend ne sont plus opérationnelles. Si votre équilibreur de charge utilise le protocole TCP, les conditions suivantes s'appliquent :

Par défaut, le drainage de connexion est activé. Les sessions TCP existantes peuvent persister sur une VM de backend pendant 300 secondes (5 minutes), même si la VM de backend n'est plus opérationnelle ou ne se trouve pas dans le pool actif de l'équilibreur de charge.
Vous pouvez désactiver le drainage de connexion lors des événements de basculement et de restauration. La désactivation du drainage de connexion lors du basculement et de la restauration permet de mettre fin rapidement à toutes les sessions TCP, y compris aux sessions établies. Les connexions aux VM de backend peuvent être fermées avec un paquet de réinitialisation TCP.

La désactivation du drainage de connexion lors du basculement et de la restauration est utile dans les situations suivantes :

Application de correctifs sur les VM de backend : avant l'application de correctifs, configurez les VM principales pour qu'elles échouent aux vérifications d'état afin que l'équilibreur de charge effectue un basculement. La désactivation du drainage de connexion garantit que toutes les connexions sont transférées vers les VM de secours rapidement et de manière planifiée. Cela vous permet d'installer des mises à jour et de redémarrer les VM principales sans que les connexions existantes persistent. Une fois les correctifs appliqués, Google Cloud peut effectuer une restauration lorsqu'un nombre suffisant de VM principales (tel que défini par le taux de basculement) ayant réussi leurs vérifications d'état est atteint.
Nécessité de n'utiliser qu'une seule VM de backend pour garantir la cohérence des données : si vous devez vous assurer qu'une seule VM principale est la destination de toutes les connexions, désactivez le drainage de connexion pour que le passage d'une VM principale à une VM de secours entraîne l'impossibilité d'une persistance simultanée des connexions existantes sur les deux VM. Cela réduit le risque d'incohérence des données en ne conservant qu'une VM de backend active à la fois.

Exemple de basculement

L'exemple suivant décrit le comportement de basculement de l'exemple d'équilibreur de charge réseau passthrough interne multizone présenté dans la section Architecture.

Les backends principaux de cet équilibreur de charge sont les groupes d'instances non gérés ig-a dans la région us-west1-a et ig-d dans la région us-west1-c. Chaque groupe d'instances contient deux VM. Les quatre VM des deux groupes d'instances sont des VM principales :

vm-a1 dans ig-a
vm-a2 dans ig-a
vm-d1 dans ig-d
vm-d2 dans ig-d

Les backends de basculement pour cet équilibreur de charge sont les groupes d'instances non gérés ig-b dans la région us-west1-a et ig-c dans la région us-west1-c. Chaque groupe d'instances contient deux VM. Les quatre VM des deux groupes d'instances sont des VM de secours :

vm-b1 dans ig-b
vm-b2 dans ig-b
vm-c1 dans ig-c
vm-c2 dans ig-c

Supposons que vous souhaitiez configurer une stratégie de basculement pour cet équilibreur de charge de sorte que les nouvelles connexions soient transférées vers les VM de secours lorsque le nombre de VM principales opérationnelles est inférieur à deux. Pour ce faire, définissez le taux de basculement sur 0.5 (50%). Google Cloud utilise le taux de basculement pour calculer le nombre minimal de machines virtuelles principales qui doivent être saines en multipliant le taux de basculement par le nombre de machines virtuelles principales : 4 × 0.5 = 2

Lorsque les quatre VM principales sont opérationnelles, Google Cloud répartit les nouvelles connexions entre toutes ces VM. Lorsque les VM principales échouent aux vérifications d'état :

Si vm-a1 et vm-d1 ne sont plus opérationnelles, Google Cloud répartit les nouvelles connexions entre les deux VM principales opérationnelles restantes (vm-a2 et vm-d2), car le nombre de VM principales opérationnelles est au moins égal au minimum.
Si vm-a2 échoue également aux vérifications d'état, laissant une seule VM principale opérationnelle (vm-d2), Google Cloud détecte que le nombre de VM principales opérationnelles est inférieur au minimum, et effectue donc un basculement. Le pool actif est défini sur les quatre machines virtuelles de sauvegarde saines et les nouvelles connexions sont réparties entre ces quatre (dans les groupes d'instances ig-b et ig-c). Même si vm-d2 reste saine, elle est supprimée du pool actif et ne reçoit pas de nouvelles connexions.
Si vm-a2 redevient opérationnelle et réussit sa vérification d'état, Google Cloud détecte que le nombre de VM principales opérationnelles est au moins égal à deux (le minimum), et effectue donc une restauration. Le pool actif est défini sur les deux VM principales opérationnelles (vm-a2 et vm-d2), et les nouvelles connexions sont réparties entre elles. Toutes les VM de secours sont supprimées du pool actif.
À mesure que les autres VM principales redeviennent opérationnelles et réussissent leurs vérifications d'état, Google Cloud les ajoute au pool actif. Par exemple, si vm-a1 devient opérationnelle, Google Cloud définit le pool actif sur les trois VM principales opérationnelles (vm-a1, vm-a2 et vm-d2) et répartit les nouvelles connexions entre elles.

Étapes suivantes

Pour configurer et tester un équilibreur de charge réseau passthrough interne qui utilise le basculement, consultez la page Configurer le basculement pour les équilibreurs de charge réseau à stratégie interne.
Pour configurer et tester un équilibreur de charge réseau passthrough interne, consultez la page Configurer un équilibreur de charge réseau à stratégie interne.
Pour résoudre les problèmes de basculement avec votre équilibreur de charge réseau passthrough interne, consultez la page Résoudre les problèmes liés à l'équilibreur de charge réseau passthrough interne.