Bonnes pratiques pour les adresses IP flottantes

Cette solution propose des alternatives à l'utilisation d'adresses IP flottantes lors de la migration d'applications vers Google Compute Engine à partir d'un environnement réseau sur site. Également appelées adresses IP "partagées" ou "virtuelles", les adresses IP flottantes sont souvent utilisées pour rendre hautement disponibles les environnements réseaux 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, permettant ainsi 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.

Adresses IP flottantes dans des environnements sur site

Les adresses IP flottantes sont couramment utilisées dans des environnements sur site. La liste suivante présente quelques exemples d'utilisation des adresses IP flottantes :

  • Les appliances physiques hautement disponibles, telles qu'un ensemble de pare-feu ou d'équilibreurs de charge, utilisent souvent des adresses IP flottantes pour les basculements.
  • Les serveurs nécessitant une haute disponibilité utilisent généralement des adresses IP flottantes, par exemple des bases de données relationnelles maître/esclave telles que Microsoft SQL Server utilisant des groupes en disponibilité permanente.
  • Les environnements Linux qui mettent en œuvre des équilibreurs de charge ou des proxys inverses utilisent des adresses IP flottantes telles que IPVS, HAProxy ou NGINX. Pour détecter les défaillances de nœuds et déplacer des adresses IP flottantes entre les instances, ces environnements utilisent des daemons tels que heartbeat, pacemaker ou keepalived.
  • Les adresses IP flottantes permettent une haute disponibilité avec les services Windows utilisant le clustering de basculement Windows Server.

Il existe plusieurs façons de mettre en œuvre des adresses IP flottantes dans un environnement sur site. Dans tous les cas, les serveurs partageant l'adresse IP doivent également partager leurs états respectifs via un mécanisme de pulsation. Ce mécanisme permet aux serveurs de communiquer leur état de fonctionnement l'un à l'autre. Il permet également au serveur secondaire de prendre le relais de l'adresse IP flottante après la défaillance du serveur lié. 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 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. L’adresse IP peut également être annoncée vers le routeur de couche 3 en amont par un protocole de routage tel que OSPF (Open Shortest Path First).

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

caractéristiques de l'environnement sur site

Il s'agit d'utiliser une configuration légèrement différente avec des solutions d'équilibrage de charge sur site, telles que l'équilibrage de charge réseau Windows ou l'équilibrage de charge Linux avec une réponse Direct Server, par exemple, IP Virtual Server (IPVS). Dans ces cas-là, le service envoie également des trames ARP gratuites, mais avec l'adresse MAC d'un autre serveur comme source ARP gratuite. Le principe est ici principalement d'usurper les trames ARP et de reprendre l'adresse source d'un autre serveur. Ce type de configuration est hors du champ d'application de la solution présentée ici. Dans presque tous les cas, la migration vers l'équilibrage de charge est le chemin de migration privilégié.

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 fonctionnent pas immédiatement. Par exemple, le réseau VPC traite les demandes ARP en fonction de la topologie de routage configurée et ignore 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).

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 est également hors du champ d'application de la solution présentée ici. Au lieu de cela, cette solution offre des approches alternatives pour la mise en œuvre de scénarios de basculement dans un environnement réseau Compute Engine natif.

Cette solution présente la manière de migrer dans Compute Engine la majorité des cas d'utilisation décrits.

Les guides étape par étape suivants existent déjà pour des cas d'utilisation plus spécifiques :

Exemple de cas d'utilisation pour la migration

Cette solution décrit quatre options de migration différentes pour passer des IP flottantes sur site à Compute Engine.

Le cas d'utilisation implique la migration de deux serveurs HAProxy internes qui acheminent le trafic vers différents backends en fonction de la correspondance et du remplacement d'en-tête de couche 7 complexes. En raison des règles complexes en jeu, cet ensemble de serveurs ne peut pas être remplacé par un équilibrage de charge interne ni même par un équilibrage de charge HTTP. La figure suivante présente un aperçu de ce cas d'utilisation.

cas d'utilisation de la migration

Les serveurs HAProxy utilisent le logiciel keepalived sur site pour vérifier la disponibilité à l'aide d'une connexion croisée séparée et transmettre les adresses IP flottantes entre les deux serveurs.

Pour ce cas d'utilisation, les quatre options décrites dans les sections suivantes correspondent à des remplacements sur site valables pour les adresses IP flottantes. Pour d'autres cas d'utilisation, peut-être plus complexes, il se peut qu'il y ait moins d'options pertinentes. Après avoir décrit les options, cette solution fournit des indications sur les options préférées en fonction de cas d'utilisation spécifiques.

La section suivante explique comment migrer ce scénario vers Compute Engine.

Mise en œuvre à l'aide de Compute Engine

Cette section décrit plusieurs manières de migrer le scénario sur site vers Compute Engine. Pour réduire la complexité, au lieu d'utiliser la correspondance basée sur l'en-tête décrite précédemment, toutes les requêtes sont transférées à un seul groupe de backends NGINX ayant une configuration minimale.

Pour tous les exemples, le trafic est acheminé depuis HAProxy vers un groupe de backends Compute Engine, eux-mêmes placés dans un groupe d'instances avec autoscaling. Ces backends sont accessibles via un équilibreur de charge interne. Pour l'exemple de configuration, ces backends diffusent la configuration NGINX par défaut.

Pour mettre en œuvre l'exemple de cas d'utilisation, utilisez un projet dédié pour les tests.

Configurer les backends

Dans cette section, il s'agit de configurer les backends NGINX auxquels les nœuds HAProxy ont accès. Il est recommandé de créer ces backends dans un VPC dédié à ce déploiement au lieu du réseau par défaut.

Pour configurer les backends, procédez comme suit :

  1. Définissez votre zone par défaut, par exemple :

    gcloud config set compute/zone us-central1-f
    
  2. Configurez un réseau pour les tests et définissez des règles de pare-feu pour autoriser le trafic interne, puis utilisez la commande ssh pour communiquer avec le réseau :

    gcloud compute networks create ip-failover
    
    gcloud compute firewall-rules create failover-internal \
        --network ip-failover --allow all --source-ranges 10.128.0.0/11
    
    gcloud compute firewall-rules create failover-ssh \
        --network ip-failover --allow tcp:22 --source-ranges 0.0.0.0/0
    
  3. Créez un modèle d'instance pour les backends NGINX :

    gcloud compute instance-templates create www \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata startup-script="apt-get -y install nginx"
    
  4. Créez un groupe d'instances gérées par zone avec autoscaling sur la base du modèle suivant :

    gcloud compute instance-groups managed create www \
        --template www --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed set-autoscaling www \
        --max-num-replicas 10 --min-num-replicas 1 \
        --target-cpu-utilization 0.8 --zone us-central1-f
    
  5. Associez un équilibreur de charge interne avec une adresse IP fixe (10.128.2.2) à ce groupe d'instances :

    gcloud compute health-checks create http simple-check
    
    gcloud compute backend-services create www-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    
    gcloud compute backend-services add-backend www-lb\
        --instance-group www \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create www-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.2.2 \
        --backend-service www-lb
    
  6. Créez une instance à tester et utilisez la commande ssh pour vous y connecter, puis vérifiez si vous pouvez accéder à l'IP d'équilibrage de charge interne :

    gcloud compute instances create testing \
        --machine-type n1-standard-1 --zone us-central1-f \
        --network ip-failover --scopes compute-ro
    
    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.2.2
    <!DOCTYPE html> [...]
    username@testing:~$ exit

Cet exemple de configuration utilise les instances n1-standard-1, limitées par un débit réseau de deux gigaoctets par seconde pour chaque instance. Pour un déploiement réel, il vous faudrait dimensionner les instances en fonction de vos besoins.

De plus, les instances sont créées avec des adresses IP externes afin de pouvoir télécharger les packages nécessaires à l'aide de scripts de démarrage. Dans une configuration de production, il est nécessaire de créer des images personnalisées et des instances sans adresse IP externe.

Option 1 : Utiliser l'équilibrage de charge interne

Vous pouvez mettre en œuvre le scénario sur site dans Compute Engine en plaçant les deux serveurs HAProxy dans un groupe d'instances gérées derrière l'équilibrage de charge interne et en utilisant l'adresse IP de l'équilibrage de charge interne en tant qu'IP virtuelle, comme le montre la figure suivante.

option 1 : équilibrage de charge interne

Différences avec une installation sur site

L'IP d'équilibrage de charge interne agit de la même manière que les IP flottantes dans l'environnement sur site, à quelques différences notables :

  • Distribution du trafic

    La différence la plus notable est que le trafic est partagé entre les deux nœuds, alors que dans la configuration d'origine, le trafic n'accède qu'à un nœud à la fois. Cette approche convient parfaitement dans un scénario où le trafic est routé en fonction du contenu de la requête elle-même, mais ne fonctionne pas si on se trouve en présence d'état non synchronisé en permanence, par exemple une base de données maître/esclave.

  • Temps de basculement

    L'utilisation de keepalived dans un environnement sur site associé à un protocole ARP gratuit peut basculer sur une adresse IP en quelques secondes. Dans l'environnement Compute Engine, le temps de récupération moyen dépend du mode de défaillance. En cas d'échec de l'instance de machine virtuelle ou du service d'instance de machine virtuelle, le trafic en fonction du temps moyen de basculement dépend des paramètres de vérification de l'é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, mais il peut être réduit en ajustant ces paramètres. Dans Compute Engine, les basculements au sein de zones ou entre les zones prennent le même temps.

  • Vérification de l'état

    Lorsqu'il est utilisé sur site, en plus d'attendre un signal actif, keepalived peut vérifier l'état de la machine hôte de différentes manières, comme par exemple en surveillant la disponibilité du processus HAProxy. Dans Compute Engine, la vérification de l'état doit être accessible de l'extérieur de l'hôte via un port HTTP/HTTPS/TCP ou SSL. Si les spécificités de l'hôte doivent être vérifiées, vous devez installer un service simple sur l'instance pour exposer ces spécificités, ou choisir une autre option.

  • Ports

    Dans une configuration sur site, les adresses IP flottantes acceptent tout le trafic, tandis que l'équilibrage de charge interne limite le transfert à cinq ports maximum.

Mettre en œuvre l'option 1

Pour mettre en œuvre cette solution, procédez comme suit :

  1. Créez un modèle d'instance pour les serveurs HAProxy qui transmettent les requêtes :

    gcloud compute instance-templates create haproxy \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. Créez un groupe d'instances zonal basé sur les modèles d'instance avec une taille statique de deux. Associez une règle d'autoréparation aux instances à l'aide de la vérification de l'état créée précédemment :

    gcloud compute instance-groups managed create haproxy \
        --template haproxy --size 2 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. Associez un équilibreur de charge interne aux serveurs HAProxy avec une vérification de l'état :

    gcloud compute backend-services create haproxy-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    gcloud compute backend-services add-backend haproxy-lb\
        --instance-group haproxy \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create haproxy-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.1.1 \
        --backend-service haproxy-lb
    
  4. Testez si vous pouvez accéder à HAProxy via un équilibrage de charge interne :

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

Après la suppression de l’une des instances HAProxy via la console ou l’arrêt du processus HAProxy sur l’une des instances, curl réussira malgré tout après une brève période de basculement.

Option 2 : Utiliser une seule instance gérée

Selon les besoins en temps de récupération, la migration avec une seule instance de VM peut constituer une option viable de Compute Engine, même si plusieurs serveurs sont utilisés sur site. L'intérêt est que vous pouvez créer une nouvelle instance de Compute Engine en quelques minutes, alors que les défaillances sur site nécessitent généralement des heures, voire des jours, pour être corrigées.

option 2 : instance gérée unique

Comparer l'option 2 à l'option 1 : équilibrage de charge interne

L'option 2 présente des avantages et des inconvénients majeurs par rapport à l'option 1.

Avantages :

  • Distribution du trafic

    Comme il n'y a qu'une seule instance, tout le trafic converge vers celle-ci, comme dans un scénario maître/esclave sur site.

  • Économies

    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.

  • Simplicité

    Cette solution est facile à mettre en œuvre et nécessite peu d'éléments supplémentaires.

Inconvénients :

  • Temps de basculement

    Lorsque la vérification de l'état a détecté une panne machine, la suppression et la recréation de l'instance défaillante prend au moins une minute, mais souvent beaucoup plus. Ce processus est beaucoup plus lent que la suppression d'une instance de l'équilibrage de charge interne.

  • Réaction aux pannes de zone

    Un groupe d'instances gérées de taille 1 ne survit pas à une défaillance de zone. Pour réagir aux défaillances de zone, envisagez d'ajouter une alerte Stackdriver Monitoring lorsque le service échoue et créez manuellement un groupe d'instances dans une autre zone en cas de défaillance de la zone.

Mettre en œuvre l'option 2

Suivez les étapes ci-dessous pour mettre en œuvre l'option 2 :

  1. Créez un modèle d'instance pour votre instance de VM HAProxy :

    gcloud compute instance-templates create haproxy-single \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. Créez un groupe d'instances gérées de taille 1 pour votre VM HAProxy et associez une règle d'autoréparation :

    gcloud compute instance-groups managed create haproxy-single \
        --template haproxy-single --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. Testez si vous pouvez accéder à HAProxy via l'IP d'équilibrage de charge interne :

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ instance=$(gcloud compute instances list |awk '$1 ~ /^haproxy-single/ { print $1 }')
    
    username@testing:~$ curl $instance
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Lorsque vous supprimez l'instance HAProxy ou arrêtez le processus d'instance HAProxy à l'aide de la console, l'instance doit se restaurer automatiquement après un délai avec la même adresse IP et le même nom d'instance.

Option 3 : Basculement à l'aide de différentes routes prioritaires

Deux routes Compute Engine avec des priorités différentes offrent un autre moyen d'activer le basculement de trafic entre deux instances lorsque vous ne pouvez pas utiliser l'équilibrage de charge interne.

Dans cette section, il s'agit de créer deux instances de VM et de les placer dans un groupe d'instances gérées avec autoréparation, avec une taille statique de 1, permettant ainsi au système de se réparer automatiquement.

Vous devez activer le transfert IP sur ces deux instances. Ensuite, après la création des instances, vous redirigez tout le trafic IP flottant vers ces deux instances en configurant deux routes avec des priorités différentes pour gérer le trafic.

option 3 : différentes routes prioritaires

Comparer l'option 3 à l'option 1 : équilibrage de charge interne

Avec l'option 3, vous pouvez migrer des cas d'utilisation dans lesquels l'équilibrage de charge interne ne peut pas être facilement utilisé. Cette option présente les avantages suivants :

  • Distribution du trafic

    Le trafic circule toujours vers l'instance de VM ayant la priorité la plus basse. Lorsque cette instance de VM n'est pas disponible, le trafic utilise la meilleure route suivante. Cette architecture ressemble à un environnement sur site où un seul serveur est actif à la fois.

  • Protocoles

    L'équilibrage de charge interne est appliqué uniquement à un ensemble spécifique de protocoles ou de ports, tandis que les routes s'appliquent à tout le trafic vers une destination spécifique.

  • Régionalité

    L'équilibrage de charge interne est disponible uniquement dans une région, tandis que les routes peuvent être créées globalement.

L'option 3 présente des inconvénients par rapport à l'option 1, qui utilise l'équilibrage de charge interne.

  • Vérification de l'état

    Avec l'option 3, aucune vérification d'état n'est associée à l'une des deux routes. Les routes sont utilisées quel que soit l'état des services de VM sous-jacents. Le trafic est dirigé vers des instances, même si le service n'est pas opérationnel. Associer une règle d'autoréparation à ces instances supprime celles-ci lorsqu'elles ne sont pas opérationnelles pendant un certain temps. Mais une fois que ces instances redémarrent, le trafic reprend même avant que le service ne soit opérationnel, ce qui peut entraîner des erreurs de service pendant la période durant laquelle les instances non opérationnelles continuent à diffuser du trafic ou sont en train de redémarrer.

  • Temps de basculement

    Une fois que vous avez supprimé ou arrêté une instance de VM, la route est automatiquement retirée. Toutefois, en l'absence de vérification de l'état, tant que l'instance est toujours disponible, la route est utilisée. En outre, l'arrêt de l'instance prend du temps. Le temps de basculement est donc considérablement plus long qu'avec l'approche d'équilibrage de charge interne.

  • Sélection d'adresse IP flottante

    Vous pouvez définir des routes uniquement pour les adresses IP qui ne font partie d'aucun sous-réseau. L'adresse IP flottante doit être choisie en dehors de toutes les plages de sous-réseaux existantes.

  • Appairage de réseaux VPC

    Les instances de VM ne peuvent utiliser que les routes à partir de leur propre réseau VPC, mais pas celles à partir de réseaux VPC appairés.

Mettre en œuvre l'option 3

Lors de la mise en œuvre, vous utiliserez l'adresse IP 10.191.1.1, qui se trouve en dehors de tous les sous-réseaux actifs du réseau ip-failover. Procédez comme suit :

  1. Créez un modèle d'instance pour les serveurs HAProxy qui transmettent les requêtes :

    gcloud compute instance-templates create haproxy-route \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    apt-get update
    apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.191.1.1
        netmask 255.255.255.255
    EOF
    service haproxy restart
    service networking restart" --can-ip-forward
    
  2. Créez deux groupes d'instances gérées, de taille 1, pour vos instances de VM HAProxy, et associez-leur une règle d'autoréparation :

    gcloud compute instance-groups managed create haproxy-r1 \
        --template haproxy-route --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-r1 --health-check simple-check --zone us-central1-f
    
    gcloud compute instance-groups managed create haproxy-r2 \
        --template haproxy-route --size 1 --zone us-central1-b
    
    gcloud compute instance-groups managed update \
        haproxy-r2 --health-check simple-check --zone us-central1-b
    
  3. Créez une route principale et une de secours vers ces instances de VM après leur démarrage :

    haproxy1=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r1/ { print $1 }')
        #save the instance name of the first HAproxy instance
    
    haproxy2=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r2/ { print $1 }')
        #save the instance name of the second HAproxy instance
    
    gcloud compute routes create haproxy-route1 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance $haproxy1
    
    gcloud compute routes create haproxy-route2 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 600 --next-hop-instance-zone us-central1-b \
        --next-hop-instance $haproxy2
    
  4. Testez si vous pouvez accéder à HAProxy via la route :

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.191.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Lorsque vous supprimez l'instance principale HAProxy via la console, la route vers l'instance secondaire doit être utilisée dès que l'instance est complètement hors service.

Option 4 : Basculement à l'aide d'appels d'API de routes

Comme l'option 3, l'option 4 utilise des routes, mais diffère considérablement de l'option 3. Au lieu de s'autoréparer et de recréer automatiquement des instances, les scripts keepalived ou autres utilisent des appels d'API pour ajouter une route à une nouvelle instance opérationnelle ou pour supprimer une route d'une instance défaillante. Cette approche est utile dans les cas où vous ne pouvez pas utiliser les vérifications de l'état de Compute Engine pour suivre l'état de l'application ou déterminer quelle machine virtuelle est la principale. Toute logique d'application peut déclencher une reprogrammation dynamique des routes.

L'utilisation d'appels d'API de routes en tant que méthode de basculement est également utile lorsque la recherche de défaillances d'applications et la remise en ligne des instances sont manuelles. Toutefois, comme les VM doivent pouvoir enregistrer toutes les pannes et être automatiquement remplacées à mesure qu'elles deviennent opérationnelles, vous ne devez pas effectuer une recherche manuelle des pannes dans Compute Engine.

option 4 : basculement à l'aide d'appels d'API de routes

Comparer les différences de l'option 4 : équilibrage de charge interne

Contrairement à l'équilibrage de charge interne, l'option 4 offre les avantages suivants :

  • Distribution du trafic

    Comme pour les options 2 et 3, le trafic ne concerne qu'une instance de machine virtuelle à la fois.

  • Absence de confiance dans les vérifications de l'état de Compute Engine

    Le basculement peut être déclenché par toute logique d'application personnalisée. Avec l'option 4, vous utilisez un script pour gérer les réactions de keepalived aux échecs de communication entre les HAProxys primaire et secondaire. C'est la seule option qui fonctionne lorsque vous ne pouvez ou ne souhaitez pas utiliser les vérifications de l'état de Compute Engine.

L’option 4 présente également des inconvénients majeurs :

  • Complexité

    Cette option doit être construite sur mesure à l'aide de l'API Compute Engine ou d'appels gcloud pour pouvoir retirer et définir une nouvelle route à l'aide de l'API Compute Engine. Construire cette logique de manière fiable est souvent complexe.

  • Temps de basculement

    Dans la mesure où un script personnalisé requiert au moins deux appels d'API Compute Engine pour retirer et créer une nouvelle route sur Compute Engine, le basculement est légèrement plus lent qu'avec un équilibreur de charge interne.

  • Sélection d'adresse IP flottante

    Vous pouvez définir des routes uniquement pour les adresses IP qui ne font partie d'aucun sous-réseau. Les adresses IP flottantes doivent être choisies en dehors de toutes les plages de sous-réseaux existantes.

  • Appairage de réseaux VPC

    Les instances de VM ne peuvent utiliser que les routes à partir de leur propre réseau VPC, mais pas celles à partir de réseaux VPC appairés.

Mettre en œuvre l'option 4

Cette mise en œuvre utilise l'adresse IP 10.190.1.1, qui se trouve en dehors de tous les sous-réseaux actifs du réseau ip-failover. La route vers cette adresse sera automatiquement créée et supprimée par keepalived.

Tout d'abord, créez deux instances HAProxy avec haproxy et keepalived installés à l'aide d'adresses IP internes statiques pour les deux instances. Vous devez également activer le transfert IP pour pouvoir arrêter la route et requérir un accès à l'API Compute Engine. Pour faire simple, vous n'utiliserez pas de modèles d'instance ni de groupes dans cet exemple.

Créez l'option 4 en procédant comme suit :

  1. Créez l'instance principale avec une adresse IP statique du type 10.128.4.100 :

    gcloud compute instances create haproxy-a \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.100 \
        --scopes compute-rw --zone us-central1-f \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state MASTER
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.100
        unicast_peer {
            10.128.4.200
        }
        virtual_router_id 50
        priority 100
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance haproxy-a --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  2. Créez l'instance secondaire avec une adresse IP statique du type 10.128.4.200 :

    gcloud compute instances create haproxy-b \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.200 \
        --scopes compute-rw --zone us-central1-c \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state BACKUP
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.200
        unicast_peer {
            10.128.4.100
        }
        virtual_router_id 50
        priority 50
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-c \
        --next-hop-instance haproxy-b --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  3. Testez si vous pouvez accéder à HAProxy via la route :

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.190.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Lorsque HAProxy sur l'instance haproxy-a est supprimé ou que l'instance se verrouille, les pulsations VRRP ne sont plus présentes et l'instance haproxy-b appelle le script takeover.sh. Ce script déplace la route pour l'adresse 10.190.1.1 de haproxy-a vers haproxy-b, si bien que le test fonctionne toujours.

Choisir la meilleure option pour votre cas d'utilisation

Pour les exemples de cas d'utilisation impliquant un ensemble de nœuds HAProxy prenant des décisions de routage complexes, la mise en œuvre préférée de Compute Engine est Option 1 : Utiliser l'équilibrage de charge interne. En effet, les instances de VM sont sans état et peuvent facilement fonctionner dans un scénario actif-actif. De plus, les vérifications de l'état de Compute Engine peuvent être utilisées. Avec d'autres cas d'utilisation, l'option 1 pourrait ne pas être la meilleure option.

Outre les avantages et les inconvénients énumérés précédemment pour chaque option, l'arbre de décision suivant peut vous aider à choisir un schéma de mise en œuvre.

arbre de décision

Les applications hautement disponibles et fiables sont mieux mises en œuvre dans Compute Engine avec des architectures comportant un scaling horizontal, minimisant ainsi l'impact d'une défaillance d'un seul nœud. La migration d'un scénario commun sur site, tel que deux serveurs avec des adresses IP flottantes, est difficile car ce scénario ne peut pas être dupliqué dans Compute Engine. Comme indiqué précédemment, le transfert d'adresses IP entre différentes machines en moins d'une seconde à l'aide d'un protocole ARP gratuit ne fonctionne pas en raison de la nature de l'infrastructure de routage virtuelle.

L'équilibrage de charge interne permet de transférer de nombreux cas d'utilisation de manière simple et fiable à Compute Engine. Dans les cas où vous ne pouvez pas utiliser d'équilibreur de charge interne, vous pouvez mettre en œuvre plusieurs autres options ne nécessitant pas de mécanismes de routage superposés complexes.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine