Présentation du basculement pour l'équilibreur de charge réseau à stratégie directe externe

Vous pouvez configurer un équilibreur de charge réseau à stratégie directe basé sur les services de backend pour répartir les connexions entre les instances de machines virtuelles (VM) dans des backends principaux puis, si nécessaire, utiliser 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 externes à stratégie directe. Avant de configurer le basculement pour votre équilibreur de charge réseau à stratégie directe, 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 standard de répartition du trafic de l'équilibreur de charge.

Par défaut, lorsque vous ajoutez un backend au service de backend d'un équilibreur de charge réseau externe à stratégie directe, 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.

Backends compatibles

Les groupes d'instances (gérés et non gérés) et les NEG zonaux (avec des points de terminaison GCE_VM_IP) 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 suivant illustre un équilibreur de charge réseau passthrough externe 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 un équilibreur de charge réseau passthrough externe. — Exemple de basculement pour un équilibreur de charge réseau externe à stratégie directe (cliquez pour agrandir).

L'exemple suivant représente un équilibreur de charge réseau externe à stratégie directe 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 externe multizone

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 des équilibreurs de charge réseau externes à stratégie directe sont soit des backends principaux, soit 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 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 externe à stratégie directe 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 principales non opérationnelles qui déclenche un basculement est un pourcentage configurable.

Limites

Groupes d'instances : vous pouvez avoir jusqu'à 50 groupes d'instances backend principales et jusqu'à 50 groupes d'instances backend de basculement.

Pool actif

Le pool actif est l'ensemble des VM de backend auquel un équilibreur de charge réseau externe à stratégie directe transmet de 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 expliqué dans la règle 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 externe à stratégie directe 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 externe à stratégie directe 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, lorsque aucune VM principale ni aucune VM de secours ne sont opérationnelles, Google Cloud répartit les nouvelles connexions entre toutes les VM principales. Il le fait en dernier recours.

Si vous préférez, vous pouvez configurer votre équilibreur de charge réseau externe à stratégie directe pour supprimer les nouvelles connexions lorsque toutes les VM principales et les VM de secours sont non opérationnelles.

Drainage de connexion lors du basculement et de la restauration

Lorsque le drainage de connexion est activé pour la règle de basculement, les connexions établies aux instances du groupe d'instances principal ou du groupe d'instances de basculement continuent d'être envoyées aux instances avec lesquelles elles ont été établies, même après un basculement ou une restauration, empêchant ainsi l'interruption de la connexion. Lorsque le drainage de connexion est désactivé pour la règle de basculement, toutes les connexions existantes sont immédiatement interrompues pendant le basculement ou la restauration.

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 leurs VM de backend actuelles, même si celles-ci ne se trouvent 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 fait office de destination pour toutes les connexions, désactivez le drainage de connexion pour que le passage d'une VM principale à une VM de secours n'autorise pas les connexions existantes sur les deux. 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 illustre le comportement de basculement de l'exemple d'équilibreur de charge réseau externe à stratégie directe 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 externe à stratégie directe utilisant le basculement, consultez la page Configurer le basculement pour les équilibreurs de charge réseau externes à stratégie directe.
Pour configurer et tester un équilibreur de charge réseau externe à stratégie directe avec un service de backend, consultez la page Configurer un équilibreur de charge réseau externe à stratégie.