Modèles d'utilisation d'adresses IP flottantes dans Compute Engine

Last reviewed 2024-01-29 UTC

Ce document explique comment utiliser les modèles de mise en œuvre d'adresses IP flottantes lors de la migration d'applications vers Compute Engine à partir d'un environnement réseau sur site. Ce document est destiné aux ingénieurs réseau, aux administrateurs système et aux ingénieurs d'opérations qui migrent les applications vers Google Cloud.

Également appelées adresses IP partagées ou virtuelles, les adresses IP flottantes sont souvent utilisées pour rendre hautement disponibles les environnements réseau sur site. À l'aide d'adresses IP flottantes, vous pouvez transmettre une adresse IP entre plusieurs serveurs physiques ou virtuels configurés de manière identique. Cette pratique permet le basculement ou la mise à niveau du logiciel de production. Cependant, vous ne pouvez pas mettre en œuvre directement des adresses IP flottantes dans un environnement Compute Engine sans modifier l'architecture selon l'un des modèles décrits dans ce document.

Le dépôt GitHub qui accompagne ce document inclut, pour chaque modèle, des exemples de déploiements que vous pouvez déployer automatiquement en utilisant Terraform.

Adresses IP flottantes dans des environnements sur site

Les adresses IP flottantes sont couramment utilisées dans des environnements sur site. Voici des exemples de cas d'utilisation :

Il existe plusieurs façons de mettre en œuvre des adresses IP flottantes dans un environnement sur site. Les serveurs partageant des adresses IP flottantes partagent également les informations d'état via un mécanisme de pulsation. Ce mécanisme permet aux serveurs de se communiquer mutuellement leur état de fonctionnement. Il permet également au serveur secondaire de prendre le relais de l'adresse IP flottante après la défaillance du serveur principal. Ce schéma est fréquemment mis en œuvre à l'aide du protocole VRRP (Virtual Router Redundancy Protocol), mais vous pouvez également utiliser d'autres mécanismes similaires.

Une fois le basculement d'une adresse IP lancé, le serveur reprenant l'adresse IP flottante ajoute l'adresse à son interface réseau. Le serveur annonce cette prise de contrôle à d'autres périphériques utilisant la couche 2 en envoyant une trame de protocole ARP (Address Resolution Protocol) gratuite. Parfois, un protocole de routage tel que OSPF (Open Shortest Path First) annonce l'adresse IP au routeur de couche 3 en amont.

Le schéma suivant illustre une configuration typique dans un environnement sur site.

Caractéristiques de l'environnement sur site

Le schéma précédent montre comment un serveur principal et un serveur secondaire connectés au même commutateur échangent des informations de réactivité via un mécanisme de pulsation. En cas de défaillance du serveur principal, le serveur secondaire envoie une trame ARP gratuite au commutateur pour prendre le contrôle de l'adresse IP flottante.

Les solutions d'équilibrage de charge sur site utilisent des configurations légèrements différentes comme l'équilibrage de charge réseau Windows ou l'équilibrage de charge Linux avec réponse Direct Server (IPVS, par exemple). Dans ces scénarios, le service envoie également des trames ARP gratuites, mais avec l'adresse MAC d'un autre serveur comme source ARP gratuite. Cette action usurpe les trames ARP et prend le contrôle de l'adresse IP source d'un autre serveur.

Cette action permet de répartir la charge d'une adresse IP sur différents serveurs. Ce type de configuration ne fait pas partie des sujets présentés dans ce document. Dans presque tous les cas où les adresses IP flottantes sont utilisées pour l'équilibrage de charge sur site, la migration vers Cloud Load Balancing est préférable.

Défis liés à la migration des adresses IP flottantes vers Compute Engine.

Compute Engine utilise une pile réseau virtualisée dans un réseau VPC (Virtual Private Cloud). Par conséquent, les mécanismes de mise en œuvre classiques ne peuvent pas fonctionner sans modifications dans Google Cloud. Par exemple, le réseau VPC traite les demandes ARP dans le réseau logiciel en ignorant les trames ARP gratuites. De plus, il est impossible de modifier directement la table de routage réseau VPC avec des protocoles de routage standards tels que OSPF ou BGP (Border Gateway Protocol). Les mécanismes couramment utilisés pour les adresses IP flottantes reposent soit sur le traitement de requêtes ARP afin de changer d'infrastructure, soit sur des réseaux programmables par OSPF ou BGP. Par conséquent, le basculement d'adresse IP ne repose pas sur ces mécanismes dans Google Cloud. Si vous migrez une image de machine virtuelle (VM) en utilisant une adresse IP flottante sur site, aucun basculement de cette adresse IP flottante n'est possible sans modifier l'application.

Vous pouvez utiliser un réseau en superposition pour créer une configuration permettant une communication de couche 2 complète et une prise en charge IP à l'aide de requêtes ARP. Toutefois, la configuration d'un réseau en superposition est complexe et rend difficile la gestion des ressources réseau de Compute Engine. Cette approche ne fait pas non plus partie des sujets abordés dans ce document. À la place, ce document décrit des modèles de mise en œuvre de scénarios de basculement dans un environnement réseau Compute Engine sans créer de réseaux superposés.

Pour mettre en œuvre des applications hautement disponibles et fiables dans Compute Engine, utilisez des architectures avec scaling horizontal. Ce type d'architecture minimise les effets d'une défaillance d'un seul nœud.

Ce document décrit plusieurs modèles permettant de migrer une application existante à l'aide d'adresses IP flottantes depuis un environnement sur site vers Compute Engine, y compris les suivants :

L'utilisation d'adresses IP d'alias qui transitent entre les instances de VM est déconseillée en tant que mécanisme de basculement, car elle ne répond pas aux exigences de haute disponibilité. Dans certains scénarios de défaillance, comme un événement de défaillance zonale, il est possible que vous ne puissiez pas supprimer une adresse IP d'alias d'une instance. Par conséquent, vous risquez de ne pas pouvoir l'ajouter à une autre instance, ce qui rend le basculement impossible.

Sélectionner un modèle pour votre cas d'utilisation

Selon vos besoins, un ou plusieurs des modèles décrits dans cette solution peuvent être utiles pour mettre en œuvre des adresses IP flottantes dans un environnement sur site.

Tenez compte des facteurs suivants lorsque vous choisissez le modèle qui vous permet le mieux d'utiliser une application :

  • Adresse IP flottante interne ou externe : la plupart des applications nécessitant des adresses IP flottantes utilisent des adresses IP internes flottantes. Certaines applications utilisent des adresses IP externes flottantes, car le trafic vers les applications externes doit généralement être équilibré en charge.

    Plus loin dans cette section, un tableau recommande des modèles que vous pouvez utiliser pour des adresses IP internes flottantes et des adresses IP externes flottantes. Pour les cas d'utilisation qui reposent sur des adresses IP internes flottantes, n'importe lequel de ces modèles peut être adapté à vos besoins. Toutefois, nous vous recommandons de migrer les cas d'utilisation reposant sur des adresses IP externes flottantes vers l'un des modèles utilisant l'équilibrage de charge.

  • Protocoles d'application : si votre VM n'utilise que TCP et UDP, vous pouvez utiliser tous les modèles de la table. Si elle utilise d'autres protocoles en plus de IPv4 pour se connecter, seuls certains modèles sont appropriés.

  • Compatibilité avec le déploiement en mode actif/actif : certaines applications peuvent, tout en utilisant des adresses IP flottantes sur site, fonctionner en mode de déploiement actif/actif. Cette fonctionnalité signifie que ces applications n'ont pas forcément besoin de basculer d'un serveur principal vers un serveur secondaire. D'autres modèles s'offrent à vous pour transférer ces types d'applications vers Compute Engine. Les applications qui ne nécessitent jamais plus d'un seul serveur d'application pour recevoir du trafic ne sont pas compatibles avec le déploiement en mode actif-actif. Vous ne pouvez mettre en œuvre ce type d'application qu'avec certains modèles présentés dans le tableau suivant.

  • Comportement de restauration automatique après récupération de la VM principale : lorsque la VM principale d'origine se rétablit après un basculement, l'une des deux opérations suivantes est appliquée au trafic en fonction du modèle utilisé. Le trafic rebascule immédiatement vers la VM principale d'origine ou reste sur la nouvelle VM principale jusqu'à ce que la restauration soit lancée manuellement ou qu'une défaillance de la nouvelle VM principale ne survienne. Dans tous les cas, seules les connexions nouvellement lancées sont affectées. Les connexions existantes restent sur la nouvelle VM principale jusqu'à leur fermeture.

  • Compatibilité avec les vérifications de l'état : si vous ne pouvez pas vérifier si votre application répond de manière réactive à l'aide des vérifications de l'état de Compute Engine, vous pouvez utiliser certains modèles décrits dans le tableau suivant.

  • Groupes d'instances : tout modèle compatible avec les vérifications d'état est également compatible avec les groupes d'instances. Pour recréer automatiquement des instances défaillantes, vous pouvez utiliser un groupe d'instances géré avec autoréparation. Si vos VM conservent leur état, vous pouvez utiliser un groupe d'instances géré avec état. Si vos VM ne peuvent pas être recréées automatiquement ou si vous avez besoin d'un basculement manuel, utilisez un groupe d'instances non géré et recréez manuellement les VM lors du basculement.

  • Mécanismes de pulsation existants : si la configuration de haute disponibilité de votre application utilise déjà un mécanisme de pulsation, tel que Heartbeat, Pacemaker, or Keepalived, vous pouvez utiliser certains modèles décrits dans le tableau suivant.

Le tableau suivant répertorie les capacités des modèles. Ces modèles sont tous décrits dans les sections suivantes :

Nom du modèle Adresse IP Protocoles compatibles Mode de déploiement Restauration automatique Compatibilité des vérifications de l'état de l'application requise Peut intégrer un mécanisme de pulsation
Modèles utilisant l'équilibrage de charge
Équilibrage de charge actif-actif Interne ou externe TCP/UDP uniquement Actif-Actif Non disponible Oui Non
Équilibrage de charge avec basculement et vérifications de l'état exposées par l'application Interne ou externe TCP/UDP uniquement Actif-Passif Immédiat (sauf connexions existantes) Oui Non
Équilibrage de charge avec basculement et vérifications de l'état exposées par la pulsation Interne ou externe TCP/UDP uniquement Actif-Passif Configurable Non Oui
Modèles utilisant les routes Google Cloud
Utiliser des routes ECMP Interne Tous les protocoles IP Actif-Actif Non disponible Oui Non
Utiliser des routes de priorité différente Interne Tous les protocoles IP Actif-Passif Immédiat (sauf connexions existantes) Oui Non
Utiliser un mécanisme de pulsation pour changer le saut suivant d'une route Interne Tous les protocoles IP Actif-Passif Configurable Non Oui
Modèle utilisant l'autoréparation
Utiliser une seule instance d'autoréparation Interne Tous les protocoles IP Non disponible Non disponible Oui Non

Le choix du modèle à utiliser pour votre cas d'utilisation dépend de plusieurs facteurs. L'arbre de décision suivant peut vous aider à affiner vos choix et à trouver une option adaptée.

Arbre de décision pour le choix d'un équilibreur de charge.

Le diagramme précédent décrit les étapes suivantes :

  1. Une instance d'autoréparation unique offre-t-elle une disponibilité suffisante pour vos besoins ?
    1. Si oui, consultez la section Utiliser une seule instance d'autoréparation plus loin dans le présent document. L'autoréparation utilise, dans un groupe d'instances de VM, un mécanisme permettant de remplacer automatiquement une instance de VM défaillante.
    2. Dans le cas contraire, passez au point de décision suivant.
  2. Votre application a-t-elle besoin de protocoles en plus des protocoles IPv4 outre les protocoles TCP et UDP ?
    1. Si oui, passez au point de décision suivant.
    2. Dans le cas contraire, passez au point de décision suivant.
  3. Votre application peut-elle fonctionner en mode actif-actif ?
    1. Si oui, et si l'application nécessite des protocoles autres que TCP et UDP en plus de IPv4, consultez la section Utiliser des routes ECMP (Equal-Cost Multi-Path) plus loin dans le présent document. Les routes ECMP distribuent le trafic entre les sauts suivants de toutes les routes candidates.
    2. Si oui, et si l'application ne nécessite pas de protocoles autres que TCP et UDP en plus de IPv4, consultez la section Équilibrage de charge actif-actif plus loin dans le présent document. L'équilibrage de charge actif-actif utilise vos VM comme backends pour un équilibreur de charge TCP/UDP interne.
    3. Sinon, dans tous les cas, vous pouvez passer au point de décision suivant.
  4. Votre application peut-elle exposer les vérifications d'état Google Cloud ?
    1. Si oui, et qu'elle nécessite des protocoles en plus des protocoles IPv4 outre les protocoles TCP et UDP, consultez la section Équilibrage de charge avec basculement et vérifications de l'état exposées par l'application plus loin dans ce document. L'équilibrage de charge avec basculement et vérification de l'état exposée par l'application utilise vos VM comme backends pour un équilibreur de charge TCP/UDP interne. Il utilise également l'adresse IP d'équilibrage de charge TCP/UDP interne en tant qu'adresse IP virtuelle.
    2. Si oui, et qu'elle ne nécessite pas de protocoles en plus des protocoles IPv4 outre les protocoles TCP et UDP, consultez la section Utiliser des routes de priorité différente plus loin dans ce document. L'utilisation de routes de priorité différente permet de garantir que le trafic circule toujours vers une instance principale, sauf si cette instance échoue.
    3. Si ce n'est pas le cas, et qu'elle nécessite des protocoles en plus des protocoles IPv4 outre les protocoles TCP et UDP, consultez la section Équilibrage de charge avec basculement et vérifications de l'état exposées par la pulsation plus loin dans ce document. Dans le modèle d'équilibrage de charge avec basculement et vérifications de l'état exposées par la pulsation, les vérifications de l'état ne sont pas exposées par l'application elle-même, mais par un mécanisme de pulsation exécuté entre les deux VM.
    4. Dans le cas contraire et si l'application NE NÉCESSITE PAS de protocoles autres que TCP et UDP en plus de IPv4, consultez la section Utiliser un mécanisme de pulsation pour changer le saut suivant d'une route plus loin dans le présent document. L'utilisation d'un mécanisme de pulsation pour changer le saut suivant d'une route utilise une seule route statique dont le saut suivant pointe vers l'instance de VM principale.

Modèles utilisant l'équilibrage de charge

En règle générale, vous pouvez migrer votre application utilisant des adresses IP flottantes vers une architecture Google Cloud utilisant Cloud Load Balancing. Vous pouvez utiliser un équilibreur de charge réseau interne à stratégie directe, car cette option convient à la plupart des cas d'utilisation où le service sur site migré est exposé uniquement en interne. Cette option d'équilibrage de charge est utilisée pour tous les exemples de la présente section ainsi que pour les exemples de déploiement sur GitHub. Si vos clients accèdent à l'adresse IP flottante à partir d'autres régions, sélectionnez l'option d'accès mondial.

Si votre application communique à l'aide de protocoles en plus des protocoles IPv4, outre les protocoles TCP ou UDP, vous devez choisir un modèle qui n'utilise pas l'équilibrage de charge. Ces modèles sont décrits plus loin dans ce document.

Si votre application utilise HTTP(S), vous pouvez utiliser l'équilibrage de charge d'application interne pour mettre en œuvre le modèle actif-actif.

Si le service que vous essayez de migrer est disponible en externe, vous pouvez mettre en œuvre tous les modèles abordés dans cette section à l'aide d'un équilibreur de charge réseau passthrough externe. Pour les déploiements en mode actif/actif, vous pouvez également utiliser un équilibreur de charge d'application externe, un proxy TCP ou un proxy SSL si votre application utilise des protocoles et des ports compatibles avec ces options d'équilibrage de charge.

Tenez compte des différences suivantes entre les mises en œuvre basées sur une adresse IP flottante sur site et tous les modèles basés sur l'équilibrage de charge :

  • Temps de basculement : l'association du message keepalive à une trame ARP gratuite dans un environnement sur site peut basculer sur une adresse IP en quelques secondes. Dans l'environnement Compute Engine, le temps de récupération moyen en cas de basculement dépend des paramètres que vous avez définis. En cas de défaillance de l'instance de VM ou du service d'instance de VM, le temps moyen de basculement du trafic dépend des paramètres de vérification d'état tels que Check Interval et Unhealthy Threshold. Lorsque ces paramètres sont définis sur leurs valeurs par défaut, le basculement prend généralement entre 15 et 20 secondes. Vous pouvez réduire cette durée en diminuant ces valeurs de paramètre.

    Dans Compute Engine, les basculements au sein d'une zone ou entre des zones prennent le même temps.

  • Protocoles et ports : dans une configuration sur site, les adresses IP flottantes acceptent tout le trafic. Choisissez l'une des spécifications de port suivantes dans la règle de transfert interne pour l'équilibreur de charge réseau interne à stratégie directe :

    • Spécifiez au moins un port et jusqu'à cinq ports par leur numéro.
    • Spécifiez ALL pour transférer le trafic sur tous les ports pour TCP ou UDP.
    • Utilisez plusieurs règles de transfert avec la même adresse IP pour transférer un mélange de trafic TCP et UDP, ou pour utiliser plus de cinq ports avec une seule adresse IP :
      • TCP ou UDP uniquement et de 1 à 5 ports : utilisez une règle de transfert.
      • TCP et UDP et de 1 à 5 ports : utilisez plusieurs règles de transfert.
      • Six ports ou plus, et TCP ou UDP : utilisez plusieurs règles de transfert.

  • Vérification de l'état : sur site, vous pouvez vérifier la réactivité de l'application sur une machine de différentes manières :

Équilibrage de charge actif-actif

Dans le modèle d'équilibrage de charge actif-actif, vos VM sont des backends pour un équilibreur de charge réseau interne à stratégie directe. Vous utilisez l'adresse IP de l'équilibreur de charge réseau interne à stratégie directecomme une adresse IP virtuelle. Le trafic est réparti équitablement entre les deux instances de backend. Le trafic appartenant à une même session est dirigé vers une même instance de backend, conformément aux paramètres d'affinité de session.

Utilisez le modèle d'équilibrage de charge actif-actif si votre application n'utilise que des protocoles basés sur TCP et UDP, et qu'elle ne nécessite pas de basculement entre les machines. Utilisez le modèle dans un scénario où les applications peuvent répondre aux requêtes en fonction du contenu de la requête elle-même. N'utilisez pas le modèle si un état de machine n'est pas synchronisé en permanence, par exemple dans une base de données principale ou secondaire.

Le schéma suivant montre une mise en œuvre du modèle d'équilibrage de charge actif-actif :

Gestion du modèle d'équilibrage de charge actif-actif par un client interne.

Le schéma précédent montre comment un client interne accède à un service qui s'exécute sur deux VM via un équilibreur de charge réseau interne à stratégie directe. Les deux VM font partie d'un groupe d'instances.

Le modèle d'équilibrage de charge actif-actif nécessite que votre service expose les vérifications de l'état en utilisant l'un des protocoles de vérification de l'état compatibles pour garantir que seules les VM réactives reçoivent du trafic.

Pour obtenir un exemple complet de mise en œuvre de ce modèle, consultez l'exemple de déploiement avec Terraform sur GitHub.

Équilibrage de charge avec basculement et vérifications de l'état exposées par l'application

Semblable au modèle actif-actif, le modèle d'équilibrage de charge via le basculement et les vérifications de l'état exposées par l'application utilise vos VM comme backends pour un équilibreur de charge réseau interne à stratégie directe. Il utilise également l'adresse IP de l'équilibreur de charge réseau interne à stratégie directe comme une adresse IP virtuelle. Pour garantir qu'une seule VM à la fois reçoit du trafic, ce modèle applique le basculement pour les équilibreurs de charge réseau internes à stratégie directe.

Ce modèle est recommandé si votre application ne reçoit que du trafic TCP ou UDP, mais n'est pas compatible avec un déploiement en mode actif-actif. Lorsque vous appliquez ce modèle, tout le trafic est dirigé vers la VM principale ou vers la VM de basculement.

Le schéma suivant montre une mise en œuvre du modèle d'équilibrage de charge avec basculement et vérifications de l'état exposées par l'application :

Comment un client interne atteint-il un service placé derrière un équilibreur de charge réseau interne à stratégie directe.

Le schéma précédent montre comment un client interne accède à un service placé derrière un équilibreur de charge réseau interne à stratégie directe. Deux VM se trouvent dans des groupes d'instances distincts. Un groupe d'instances est défini comme backend principal. L'autre groupe d'instances est défini en tant que backend de basculement pour un équilibreur de charge réseau interne à stratégie directe.

Si le service de la VM principale ne répond plus, le trafic bascule vers le groupe d'instances de basculement. Une fois que la VM principale est réactive, le trafic rebascule automatiquement vers le service de backend principal.

Pour obtenir un exemple complet de mise en œuvre de ce modèle, consultez l'exemple de déploiement avec Terraform sur GitHub.

Équilibrage de charge avec basculement et vérifications de l'état exposées par la pulsation

Le modèle d'équilibrage de charge avec basculement et vérifications de l'état à pulsation est identique au modèle précédent. La différence est que les vérifications de l'état ne sont pas exposées par l'application elle-même, mais par un mécanisme de pulsation s'exécutant entre les deux VM.

Le schéma suivant montre une mise en œuvre du modèle d'équilibrage de charge avec basculement et vérifications de l'état exposées par la pulsation :

Comment un client interne accède à un service derrière un équilibreur de charge interne avec deux VM dans des groupes d'instances distincts

Ce schéma montre comment un client interne accède à un service placé derrière un équilibreur de charge interne. Deux VM se trouvent dans des groupes d'instances distincts. Un groupe d'instances est défini comme backend principal. L'autre groupe d'instances est défini en tant que backend de basculement pour un équilibreur de charge réseau interne à stratégie directe. Keepalived est utilisé comme mécanisme de pulsation entre les nœuds de VM.

Les nœuds de VM échangent des informations sur l'état du service en utilisant le mécanisme de pulsation choisi. Chaque nœud de VM vérifie son propre état et communique cet état au nœud distant. En fonction de l'état du nœud local et de l'état reçu par le nœud distant, un nœud est élu nœud principal tandis que l'autre est élu nœud de sauvegarde. Vous pouvez utiliser ces informations d'état pour exposer un résultat de vérification d'état qui garantit que le nœud considéré comme principal dans le mécanisme de pulsation reçoit également le trafic de l'équilibreur de charge réseau interne à stratégie directe.

Par exemple, avec le message keepalive, vous pouvez appeler des scripts en utilisant des variables de configuration notify_master, notify_backup et notify_fault qui modifient l'état de la vérification d'état. Lors de la transition vers l'état principal (dans le message keepalive, cet état est appelé master), vous pouvez démarrer une application qui écoute sur un port TCP personnalisé. Lorsque vous passez à un état de sauvegarde ou d'erreur, vous pouvez arrêter cette application. La vérification d'état peut ensuite être une vérification d'état TCP, qui réussit si ce port TCP personnalisé est ouvert.

Ce modèle est plus complexe que le modèle utilisant le basculement avec des vérifications de l'état exposées par l'application. Toutefois, il vous donne plus de contrôle. Par exemple, vous pouvez le configurer pour se restaurer immédiatement ou manuellement dans le cadre de la mise en œuvre du mécanisme de pulsation.

Pour obtenir un exemple complet de mise en œuvre de ce modèle utilisant le message keepalive, consultez l'exemple de déploiement avec Terraform sur GitHub.

Modèles utilisant les routes Google Cloud

Si votre application utilise des protocoles autres que TCP ou UDP en plus de IPv4, vous pouvez migrer votre adresse IP flottante vers un modèle basé sur des routes.

Dans cette section, les mentions de routes font toujours référence aux routes Google Cloud faisant partie d'un réseau VPC. Les références aux routes statiques font toujours référence à des routes statiques sur Google Cloud.

En utilisant l'un de ces modèles, vous définissez plusieurs routes statiques pour une adresse IP spécifique avec les différentes instances en tant que sauts suivants. Cette adresse IP devient l'adresse IP flottante utilisée par tous les clients. Elle doit être en dehors de toutes les plages d'adresses IP du sous-réseau VPC, car les routes statiques ne peuvent pas remplacer les routes de sous-réseau existantes. Vous devez activer le transfert d'adresses IP sur les instances cibles. Le transfert d'adresses IP vous permet d'accepter le trafic pour les adresses IP non attribuées aux instances (dans ce cas, l'adresse IP flottante).

Si vous souhaitez que les routes d'adresses IP flottantes soient disponibles à partir de réseaux VPC appairés, exportez les routes personnalisées afin que les routes d'adresses IP flottantes se propagent à tous les réseaux VPC appairés.

Pour disposer d'une connectivité à partir d'un réseau sur site connecté via Cloud Interconnect ou Cloud VPN, vous devez utiliser des annonces de routage d'adresses IP personnalisées pour que l'adresse IP flottante soit annoncée sur site.

Les modèles basés sur le routage présentent les avantages suivants par rapport aux modèles basés sur l'équilibrage de charge :

  • Protocoles et ports : les modèles basés sur le routage s'appliquent à tout le trafic envoyé vers une destination spécifique. Les modèles basés sur l'équilibrage de charge n'autorisent que le trafic TCP et UDP.

Les modèles basés sur le routage présentent les inconvénients suivants par rapport aux modèles basés sur l'équilibrage de charge :

  • Vérification d'état : les vérifications d'état ne peuvent pas être associées aux routes Google Cloud. Les routes sont utilisées quel que soit l'état des services de VM sous-jacents. Lorsque la VM est en cours d'exécution, les routes dirigent le trafic vers des instances même si le service n'est pas opérationnel. Associer une règle d'autoréparation à ces instances permet de remplacer les instances qui ne sont pas opérationnelles après une durée que vous spécifiez. Cependant, le trafic reprend immédiatement une fois que ces instances redémarrent, même avant que le service ne soit opérationnel. Cet intervalle peut entraîner des erreurs de service lorsque des instances non opérationnelles continuent à diffuser du trafic ou sont en cours de redémarrage.
  • Temps de basculement : après avoir supprimé ou arrêté une instance de VM, Compute Engine ignore toute route statique pointant vers cette instance. Toutefois, comme aucune vérification de l'état n'est effectuée sur les routes, Compute Engine utilise toujours la route statique tant que l'instance est toujours disponible. En outre, l'arrêt de l'instance prend du temps. Le temps de basculement est donc considérablement plus long qu'avec les modèles basés sur l'équilibrage de charge.
  • Adresses IP flottantes internes uniquement : bien que vous puissiez mettre en œuvre des modèles à l'aide de l'équilibrage de charge avec l'équilibreur de charge réseau externe à stratégie directe pour créer une adresse IP flottante externe, les modèles basés sur le routage ne fonctionnent qu'avec les adresses IP flottantes internes.
  • Sélection d'adresse IP flottante : vous ne pouvez définir des routes que vers des adresses IP flottantes internes qui ne font partie d'aucun sous-réseau. Les routes de sous-réseau ne peuvent pas être écrasées dans Google Cloud. Suivez ces adresses IP flottantes pour ne pas les attribuer accidentellement à un autre réseau.
  • Joignabilité des routes : pour rendre les adresses IP flottantes internes joignables à partir de réseaux sur site ou de réseaux appairés, vous devez distribuer ces routes statiques comme décrit précédemment.

Utiliser le routage ECMP (Equal-Cost Multi-Path)

Le modèle de routage ECMP (Equal-Cost Multi-Path) est semblable au modèle d'équilibrage de charge actif-actif : le trafic est réparti équitablement entre les deux instances backend. Lorsque vous utilisez des routes statiques Google Cloud, ECMP distribue le trafic entre les sauts suivants de toutes les routes candidates en utilisant un hachage à cinq tuples pour l'affinité.

Vous mettez en œuvre ce modèle en créant deux routes statiques de priorité égale avec les instances Compute Engine en tant que sauts suivants.

Le schéma suivant montre une mise en œuvre du modèle de routage ECMP :

Comment un client interne accède à un service à l'aide de l'une des deux routes ECMP

Le schéma ci-dessus montre comment un client interne accède à un service via l'une des deux routes dont le saut suivant pointe vers les instances de VM qui mettent en œuvre le service.

Si le service ne répond plus sur une VM, l'autoréparation tente de recréer l'instance qui ne répond pas. Une fois que l'autoréparation a supprimé l'instance, la route pointant vers celle-ci devient jusqu'à la création de la nouvelle instance. Une fois que la nouvelle instance existe, la route pointant vers cette instance est immédiatement et automatiquement rétablie, et le trafic est réparti équitablement entre les instances.

Le modèle de routage ECMP nécessite que votre service expose les vérifications de l'état à l'aide de protocoles compatibles pour que l'autoréparation puisse remplacer automatiquement les VM qui ne répondent pas.

Vous trouverez un exemple de mise en œuvre de ce modèle avec Terraform dans le dépôt GitHub associé au présent document.

Utiliser des routes de priorité différente

Le modèle utilisant des routes de priorité différente est semblable au modèle précédent, sauf qu'il utilise des routes statiques de priorité différente afin que le trafic circule toujours vers une instance principale, sauf si cette instance échoue.

Pour mettre en œuvre ce modèle, suivez la même procédure que dans le modèle de routage ECMP. Lors de la création des routes statiques, attribuez à la route avec le saut suivant pointant vers l'instance principale une valeur de priorité inférieure (route principale). Attribuez à l'instance avec le saut suivant pointant vers l'instance secondaire une valeur de priorité plus élevée (route secondaire).

Le schéma suivant montre une mise en œuvre du modèle utilisant des routes de priorité différente : Comment un client interne accédant à un service utilise une route principale ou secondaire en fonction des circonstances du réseau

Le schéma précédent montre comment un client interne accédant à un service utilise une route principale avec une valeur de priorité de 500 pointant vers la VM 1 en tant que saut suivant lorsque les circonstances sont normales. Une deuxième route avec une valeur de priorité de 1 000 est disponible et pointe vers la VM 2, la VM secondaire, en tant que saut suivant.

Si le service de la VM principale ne répond plus, l'autoréparation tente de recréer l'instance. Une fois que l'autoréparation a supprimé l'instance et avant que la nouvelle instance ne soit créée, la route principale dont le saut suivant correspond à l'instance principale devient inactive. Le modèle utilise ensuite la route dont le saut suivant correspond à l'instance secondaire. Une fois la nouvelle instance principale opérationnelle, la route principale redevient active et tout le trafic est dirigé vers l'instance principale.

Comme pour le modèle précédent, le modèle utilisant des routes de priorité différente nécessitent que votre service expose les vérifications de l'état à l'aide de protocoles compatibles pour que l'autoréparation puisse remplacer automatiquement les VM qui ne répondent pas.

Vous trouverez un exemple de mise en œuvre de ce modèle avec Terraform dans le dépôt GitHub associé au présent document.

Utiliser un mécanisme de pulsation pour changer le saut suivant d'une route

Si votre application met en œuvre un mécanisme de pulsation, par exemple un message keepalive, pour surveiller la réactivité de l'application, vous pouvez appliquer le modèle de mécanisme de pulsation afin de modifier le saut suivant de la route statique. Dans ce cas, vous n'utilisez qu'une seule route statique dont le saut suivant pointe vers l'instance de VM principale. Lors du basculement, le mécanisme de pulsation modifie le saut suivant de la route pour cibler la VM secondaire.

Le schéma suivant montre une mise en œuvre du mécanisme de pulsation pour changer le modèle de saut suivant d'une route :

Comment un client interne accède à un service où la VM principale et la VM secondaire échangent des informations de pulsation

Le schéma précédent montre comment un client interne accède à un service via une route dont le saut suivant pointe vers la VM principale. La VM principale échange des informations de pulsation avec la VM secondaire via un message keepalive. Lors du basculement, le message keepalive appelle une fonction Cloud qui utilise des appels d'API pour modifier le saut suivant afin de cibler la VM secondaire.

Les nœuds utilisent le mécanisme de pulsation choisi pour échanger des informations sur l'état du service. Chaque nœud de VM vérifie son propre état et le communique au nœud de VM distant. En fonction de l'état du nœud de VM local et de l'état reçu du nœud distant, un nœud de VM est élu nœud principal tandis que l'autre est élu nœud de sauvegarde. Une fois qu'un nœud devient principal, il modifie le saut suivant de la route ciblant l'adresse IP flottante pour cibler sa propre adresse. Si vous utilisez le message keepalive, vous pouvez appeler un script en utilisant la variable de configuration notify_master, qui remplace la route statique par un appel d'API, ou Google Cloud CLI.

Le mécanisme de pulsation permettant de changer le modèle de saut suivant d'une route ne nécessite pas que les VM fassent partie d'un groupe d'instances. Si vous souhaitez que les VM soient automatiquement remplacées en cas de défaillance, vous pouvez les placer dans un groupe d'instances avec autoréparation. Vous pouvez également réparer et recréer manuellement les VM qui ne répondent pas.

L'appel de la procédure suivante sur le basculement garantit que le temps de basculement est réduit, car le trafic bascule après l'exécution d'un seul appel d'API à l'étape 1 :

  1. Créez une route statique avec l'adresse IP flottante en tant que destination et la nouvelle instance principale en tant que saut suivant. La nouvelle route doit avoir un nom de route différent et une priorité de route inférieure (400, par exemple) que la route d'origine.
  2. Supprimez la route d'origine vers l'ancienne VM principale.
  3. Créez une route portant le même nom et la même priorité que la route que vous venez de supprimer. Pointez-la vers la nouvelle VM principale en tant que saut suivant.
  4. Supprimez la route statique que vous avez créée. Vous n'en avez pas besoin pour vous assurer que le trafic est acheminé vers la nouvelle VM principale.

Comme la route d'origine est remplacée, une seule route doit être active à la fois même dans un réseau fractionné.

L'utilisation du mécanisme de pulsation pour changer le modèle de priorité de la route plutôt que d'autres modèles basés sur les routes peut réduire le temps de basculement. Vous n'avez pas besoin de supprimer et remplacer les VM via l'autoréparation pour le basculement. Vous disposez également d'un meilleur contrôle sur le moment auquel revenir au serveur principal d'origine lorsqu'il répond à nouveau.

L'un des inconvénients de ce modèle est que vous devez gérer vous-même le mécanisme de pulsation. La gestion de ce mécanisme peut complexifier l'utilisation. Un autre inconvénient est que vous devez accorder des privilèges permettant de remplacer la table de routage globale, soit aux VM exécutant le processus de pulsation, soit à une fonction sans serveur appelée à partir du processus de pulsation. La modification de la table de routage globale par une fonction sans serveur est plus sécurisée, car elle peut réduire le champ d'application des privilèges accordés aux VM. Toutefois, cette approche est plus complexe à mettre en œuvre.

Pour obtenir un exemple complet de mise en œuvre de ce modèle avec un message keepalive, consultez l'exemple de déploiement avec Terraform sur GitHub.

Modèle utilisant l'autoréparation

Selon les besoins en temps de récupération, la migration vers une seule instance de VM peut être une option viable lors de l'utilisation de Compute Engine. Cette option est valable même si plusieurs serveurs utilisant une adresse IP flottante ont été utilisés sur site. Ce modèle peut être utilisé parfois malgré la réduction du nombre de VM, car vous pouvez créer une instance Compute Engine en quelques secondes ou quelques minutes, alors que les défaillances sur site nécessitent généralement des heures, voire des jours pour être corrigées.

Utiliser une seule instance d'autoréparation

En utilisant ce modèle, vous utilisez le mécanisme d'autoréparation d'un groupe d'instances de VM pour remplacer automatiquement une instance de VM défaillante. L'application expose une vérification d'état et l'autoréparation remplace automatiquement la VM lorsque l'application n'est pas opérationnelle.

Le schéma suivant montre une mise en œuvre du modèle utilisant une seule instance d'autoréparation :

Comment un client interne se connecte directement à une instance Compute Engine

Le schéma précédent montre comment un client interne se connecte directement à une instance Compute Engine placée dans un groupe d'instances géré d'une taille de 1 et avec l'autoréparation activée.

Par rapport aux modèles utilisant l'équilibrage de charge, le modèle utilisant unes seule instance d'autoréparation présente les avantages suivants :

  • Distribution du trafic : comme il n'existe qu'une seule instance, l'instance reçoit toujours tout le trafic.
  • Facilité d'utilisation : comme il n'existe qu'une seule instance, ce modèle est le moins compliqué à mettre en œuvre.
  • Économies de coûts : l'utilisation d'une seule instance de VM au lieu de deux peut réduire de moitié le coût de la mise en œuvre.

Cependant, cette approche présente les inconvénients suivants :

  • Temps de basculement : ce processus est beaucoup plus lent que les modèles basés sur l'équilibrage de charge. Lorsque la vérification d'état détecte une défaillance de machine, la suppression et la recréation de l'instance défaillante prennent au moins une minute, mais souvent plus de temps. Ce modèle n'est pas courant dans les environnements de production. Toutefois, le temps de basculement peut être suffisant pour certains services internes ou expérimentaux.
  • Réaction aux pannes de zone : un groupe d'instances géré d'une taille de 1 ne survit pas à une défaillance de zone. Pour réagir aux défaillances de zone, envisagez d'ajouter une alerte Cloud Monitoring lorsque le service échoue et créez un groupe d'instances dans une autre zone en cas de défaillance de la zone. Étant donné que vous ne pouvez pas utiliser la même adresse IP dans ce cas, utilisez une zone privée Cloud DNS pour adresser la VM et changer le nom DNS par la nouvelle adresse IP.

Vous trouverez un exemple de mise en œuvre de ce modèle avec Terraform dans le dépôt GitHub.

Étape suivante