Configurer un équilibreur de charge réseau passthrough interne pour les dispositifs tiers

Dans Google Cloud, vous pouvez intégrer des dispositifs tiers à disponibilité élevée de manière évolutive. Pour ce faire, vous devez configurer une route statique personnalisée et définir son saut suivant sur l'équilibreur de charge réseau interne à stratégie directe de Google Cloud. L'équilibreur de charge peut ainsi équilibrer la charge du trafic d'un préfixe de destination vers un pool de dispositifs de VM tiers dont l'état a été vérifié.

Ce guide utilise un exemple pour vous apprendre à configurer un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant. Avant de suivre ce guide, familiarisez-vous avec les points suivants :

Autorisations

Pour suivre ce guide, vous devez créer des instances et modifier un réseau dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer de tous les rôles IAM Compute Engine suivants :

Tâche Rôle requis
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge Administrateur réseau
Ajouter et supprimer des règles de pare-feu Administrateur de sécurité
Créer des instances Administrateur d'instances Compute

Pour en savoir plus, consultez les guides suivants :

Configurer des équilibreurs de charge réseau internes à stratégie directe comme sauts suivants avec des backends communs

Ce guide vous explique comment utiliser un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant pour une route statique personnalisée afin d'intégrer des dispositifs virtuels soumis à un scaling horizontal.

La solution décrite dans ce guide crée des VM de dispositifs exécutant Debian Linux. Les exemples de VM n'effectuent aucun filtrage de paquets, mais vous pouvez ajouter cette fonctionnalité en modifiant la configuration du réseau de cet exemple ou en utilisant différents logiciels de filtrage ou de routage des paquets.

La procédure décrite dans cette section explique comment configurer les ressources suivantes :

  • Exemples de réseaux VPC et de sous-réseaux personnalisés
  • Règles de pare-feu Google Cloud autorisant les connexions entrantes vers les machines virtuelles (VM) de dispositifs de backend
  • Routes statiques personnalisées
  • Deux VM clientes pour tester les connexions
  • Les composants de l'équilibreur de charge réseau interne à stratégie directe suivants :
    • VM de backend dans un groupe d'instances géré
    • Vérification d'état des VM de backend
    • Service de backend interne dans la région us-west1 pour gérer la distribution des connexions entre les VM de backend
    • Règle de transfert interne et adresse IP interne pour l'interface de l'équilibreur de charge

Cet exemple illustre l'équilibrage de charge sur plusieurs cartes d'interface réseau, comme décrit dans la section Équilibrage de charge sur plusieurs cartes d'interface réseau.

La topologie se présente comme suit :

Exemple détaillé de cartes d'interface réseau multiples à saut suivant pour l'équilibreur de charge réseau passthrough interne
Exemple détaillé de cartes d'interface réseau multiples à saut suivant pour l'équilibreur de charge réseau passthrough interne (cliquez pour agrandir)

Le schéma illustre certaines des ressources créées par l'exemple :

  • Instances d'application derrière un équilibreur de charge réseau interne à stratégie directe (fr-ilb1, dans cet exemple). Les instances d'application ne disposent que d'adresses IP internes
  • Pour chaque instance d'application, l'option can-ip-forward est activée. Sans cette option, une VM Compute Engine ne peut transmettre un paquet que si son adresse IP source correspond à l'adresse IP interne de la VM, à l'adresse IP d'une plage d'adresses IP d'alias ou à l'adresse IP d'une règle de transfert qui renvoie vers la VM. L'option can-ip-forward modifie ce comportement de sorte que la VM puisse transmettre des paquets avec n'importe quelle adresse IP source.
  • Une route statique personnalisée avec la destination 10.50.1.0/24 et le saut suivant défini sur la règle de transfert de l'équilibreur de charge, fr-ilb1.

Le schéma montre également le flux de trafic :

  • Le réseau VPC testing dispose d'une route statique personnalisée pour le trafic qui est destiné au sous-réseau 10.50.1.0/24. Cette route achemine le trafic vers l'équilibreur de charge.
  • L'équilibreur de charge transfère le trafic vers l'une des instances d'application en fonction de l'affinité de session configurée. (L'affinité de session n'affecte que le trafic TCP.)

Pour les autres cas d'utilisation, consultez la section Équilibreurs de charge TCP/UDP internes en tant que sauts suivants.

Configurer les réseaux, la région et les sous-réseaux

Cet exemple utilise les réseaux VPC, la région et les sous-réseaux suivants :

  • Réseaux : cet exemple nécessite deux réseaux, chacun avec au moins un sous-réseau. Chaque VM de dispositif tiers de backend doit disposer d'au moins deux interfaces réseau, une par réseau VPC. Dans cet exemple, les réseaux sont des réseaux VPC en mode personnalisé nommés testing et production. Le réseau testing de cet exemple contient le client et l'équilibreur de charge. Le réseau production contient la VM cible de destination.

  • Région : les sous-réseaux sont situés dans la région us-west1. Les sous-réseaux doivent se trouver dans la même région, car les instances de VM sont des ressources zonales.

  • Sous-réseaux : les sous-réseaux testing-subnet et production-subnet utilisent respectivement les plages d'adresses IP principales 10.30.1.0/24 et 10.50.1.0/24.

Pour créer les exemples de réseaux et de sous-réseaux, procédez comme suit.

Console

Créez le réseau testing et le sous-réseau testing-subnet :

  1. Dans Google Cloud Console, accédez à la page Réseaux VPC.

    Accéder aux réseaux VPC

  2. Cliquez sur Créer un réseau VPC.

  3. Saisissez le nom testing.

  4. Dans la section Sous-réseaux :

    • Définissez Mode de création du sous-réseau sur Personnalisé.
    • Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
      • Nom : testing-subnet
      • Région : us-west1
      • Plage d'adresses IP : 10.30.1.0/24
      • Cliquez sur OK.

  5. Cliquez sur Créer.

Créez le réseau production et le sous-réseau production-subnet :

  1. Dans Google Cloud Console, accédez à la page Réseaux VPC.

    Accéder aux réseaux VPC

  2. Cliquez sur Créer un réseau VPC.

  3. Saisissez le nom production.

  4. Dans la section Sous-réseaux :

    • Définissez Mode de création du sous-réseau sur Personnalisé.
    • Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
      • Nom : production-subnet
      • Région : us-west1
      • Plage d'adresses IP : 10.50.1.0/24
      • Cliquez sur OK.

  5. Cliquez sur Créer.

gcloud

  1. Créez les réseaux VPC personnalisés :

    gcloud compute networks create testing --subnet-mode=custom

    gcloud compute networks create production --subnet-mode=custom

  2. Créez des sous-réseaux sur les réseaux testing et production de la région us-west1 :

    gcloud compute networks subnets create testing-subnet \
    --network=testing \
    --range=10.30.1.0/24 \
    --region=us-west1

    gcloud compute networks subnets create production-subnet \
    --network=production \
    --range=10.50.1.0/24 \
    --region=us-west1

Configurer les règles de pare-feu

Cet exemple utilise les règles de pare-feu suivantes :

  • fw-allow-testing-from-both : règle d'entrée applicable à toutes les cibles du réseau testing. Cette règle autorise le trafic provenant de sources comprises dans les plages d'adresses IP 10.30.1.0/24 et 10.50.1.0/24. Ces deux plages couvrent les adresses IP internes principales des VM dans les deux réseaux.

  • fw-allow-production-from-both : règle d'entrée applicable à toutes les cibles du réseau production. Cette règle autorise le trafic provenant de sources comprises dans les plages d'adresses IP 10.30.1.0/24 et 10.50.1.0/24. Ces deux plages couvrent les adresses IP internes principales des VM dans les deux réseaux.

  • fw-allow-testing-ssh : règle d'entrée appliquée aux instances de VM dans le réseau VPC testing. Cette règle autorise la connectivité SSH entrante sur le port TCP 22 à partir de n'importe quelle adresse. Vous pouvez choisir une plage d'adresses IP source plus restrictive pour cette règle. Par exemple, vous pouvez spécifier les plages d'adresses IP des systèmes à partir desquels vous prévoyez de lancer des sessions SSH. Cet exemple utilise le tag cible allow-ssh pour identifier les VM auxquelles la règle de pare-feu s'applique.

  • fw-allow-production-ssh : règle d'entrée appliquée aux instances de VM dans le réseau VPC production. Cette règle autorise la connectivité SSH entrante sur le port TCP 22 à partir de n'importe quelle adresse. Tout comme la règle fw-allow-testing-ssh, vous pouvez choisir une plage d'adresses IP sources plus restrictive pour cette règle.

  • fw-allow-health-check : règle d'entrée pour les VM de dispositifs tiers qui font l'objet d'un équilibrage de charge. Cette règle autorise le trafic provenant des systèmes de vérification d'état Google Cloud (130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible allow-health-check pour identifier les instances auxquelles la règle doit s'appliquer.

  • fw-allow-production-health-check : règle d'entrée pour les VM de dispositifs tiers qui font l'objet d'un équilibrage de charge. Cette règle autorise le trafic provenant des systèmes de vérification d'état Google Cloud (130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible allow-health-check pour identifier les instances auxquelles la règle doit s'appliquer.

Sans ces règles de pare-feu, la règle d'entrée interdite par défaut bloque le trafic entrant vers les instances backend. Vous devez créer une règle de pare-feu pour autoriser les vérifications d'état à partir des plages d'adresses IP des systèmes de vérification Google Cloud. Pour plus d'informations, reportez-vous aux plages d'adresses IP de vérification.

Console

  1. Dans la console Google Cloud, accédez à la page Règles d'administration.

    Accéder à la page "Stratégies de pare-feu"

  2. Cliquez sur Créer une règle de pare-feu et saisissez les informations suivantes pour créer la règle permettant aux VM de test de recevoir des paquets des sous-réseaux de test et de production :

    • Nom : fw-allow-testing-from-both
    • Réseau : testing
    • Priorité : 1000
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : toutes les instances du réseau
    • Filtre source : Plages IPv4
    • Plages IPv6 sources : 10.30.1.0/24, 10.50.1.0/24
    • Protocoles et ports : tout autoriser

  3. Cliquez sur Create (Créer).

  4. Cliquez sur Créer une règle de pare-feu et saisissez les informations suivantes pour créer la règle permettant aux VM de production de recevoir des paquets des sous-réseaux de test et de production :

    • Nom : fw-allow-production-from-both
    • Réseau : production
    • Priorité : 1000
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : toutes les instances du réseau
    • Filtre source : Plages IPv4
    • Plages IPv6 sources : 10.30.1.0/24, 10.50.1.0/24
    • Protocoles et ports : tout autoriser

  5. Cliquez sur Create (Créer).

  6. Cliquez sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes dans l'environnement de test :

    • Nom : fw-allow-testing-ssh
    • Réseau : testing
    • Priorité : 1000
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : tags cibles spécifiés
    • Tags cibles : allow-ssh
    • Filtre source : Plages IPv4
    • Plages IPv4 sources : 0.0.0.0/0
    • Protocoles et ports : sélectionnez Protocoles et ports spécifiés, et saisissez : tcp:22

  7. Cliquez sur Create (Créer).

  8. Cliquez de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes dans l'environnement de production :

    • Nom : fw-allow-production-ssh
    • Réseau : production
    • Priorité : 1000
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : tags cibles spécifiés
    • Tags cibles : allow-ssh
    • Filtre source : Plages IPv4
    • Plages IPv4 sources : 0.0.0.0/0
    • Protocoles et ports : sélectionnez Protocoles et ports spécifiés, et saisissez : tcp:22

  9. Cliquez sur Create (Créer).

  10. Cliquez sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud dans l'environnement de test :

    • Nom : fw-allow-health-check
    • Réseau : testing
    • Priorité : 1000
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : tags cibles spécifiés
    • Tags cibles : allow-health-check
    • Filtre source : Plages IPv4
    • Plages IPv4 sources : 130.211.0.0/22 et 35.191.0.0/16
    • Protocoles et ports : tcp

  11. Cliquez sur Create (Créer).

  12. Cliquez de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud dans l'environnement de production :

    • Nom : fw-allow-production-health-check
    • Réseau : production
    • Priorité : 1000
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : tags cibles spécifiés
    • Tags cibles : allow-health-check
    • Filtre source : Plages IPv4
    • Plages IPv4 sources : 130.211.0.0/22 et 35.191.0.0/16
    • Protocoles et ports : tcp

  13. Cliquez sur Create (Créer).

gcloud

  1. Créez la règle de pare-feu fw-allow-testing-subnet pour permettre aux VM de test de recevoir des paquets des sous-réseaux testing et production :

    gcloud compute firewall-rules create fw-allow-testing-from-both \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  2. Créez la règle de pare-feu fw-allow-production-subnet pour permettre aux VM de production de recevoir des paquets des sous-réseaux testing et production :

    gcloud compute firewall-rules create fw-allow-production-from-both \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  3. Créez la règle de pare-feu fw-allow-testing-ssh pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh. Lorsque vous omettez source-ranges, Google Cloud interprète la règle comme désignant n'importe quelle source.

    gcloud compute firewall-rules create fw-allow-testing-ssh \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  4. Créez la règle de pare-feu fw-allow-production-ssh pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh.

    gcloud compute firewall-rules create fw-allow-production-ssh \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  5. Créez la règle fw-allow-health-check pour autoriser les vérifications d'état Google Cloud sur les VM de dispositifs tiers du réseau testing.

    gcloud compute firewall-rules create fw-allow-testing-health-check \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

  6. Créez la règle de pare-feu fw-allow-production-health-check pour autoriser les vérifications d'état Google Cloud sur les VM de dispositifs tiers du réseau production.

    gcloud compute firewall-rules create fw-allow-production-health-check \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

Créer les dispositifs virtuels tiers

Les étapes suivantes vous expliquent comment créer un modèle d'instance et un groupe d'instances régional géré avec plusieurs interfaces réseau. Ce groupe d'instances est utilisé comme dispositif virtuel tiers pour cet exemple.

Console

Vous devez utiliser gcloud pour cette étape, car vous devez créer un modèle d'instance avec plusieurs interfaces réseau. Pour le moment, la console Google Cloud n'accepte pas la création de modèles d'instance avec plusieurs interfaces réseau.

gcloud

  1. Créez un fichier local appelé config.sh et insérez le contenu suivant :

    #!/bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
# Read VM network configuration:
md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
md_net="$md_vm/network-interfaces"
nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
# Source based policy routing for nic1
echo "100 rt-nic1" >> /etc/iproute2/rt_tables
sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
sleep 1
sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html
sudo systemctl restart apache2

  2. Créez un modèle d'instance pour vos dispositifs virtuels tiers. Le modèle d'instance doit inclure l'option --can-ip-forward afin que les instances de VM créées à partir du modèle puissent transférer des paquets à partir d'autres instances sur les réseaux testing et production.

    gcloud compute instance-templates create third-party-template-multinic \
    --region=us-west1 \
    --network-interface subnet=testing-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check,my-network-tag \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script="$(< config.sh)"

  3. Créez un groupe d'instances géré pour vos dispositifs virtuels tiers. Cette commande crée un groupe d'instances régional géré, qui peut ensuite faire l'objet d'un autoscaling dans us-west1.

    gcloud compute instance-groups managed create third-party-instance-group \
    --region=us-west1 \
    --template=third-party-template-multinic \
    --size=3

Créer les ressources d'équilibrage de charge

Ces étapes permettent de configurer tous les composants de l'équilibreur de charge réseau interne à stratégie directe, en commençant par la vérification d'état et le service de backend, puis en passant aux composants d'interface :

  • Vérification de l'état : dans cet exemple, la vérification de l'état HTTP recherche une réponse HTTP 200 (OK). Pour plus d'informations, consultez la section sur les vérifications d'état de la présentation de l'équilibreur de charge réseau interne à stratégie directe.

  • Service de backend : même si le service de backend de cet exemple spécifie le protocole TCP, lorsque l'équilibreur de charge est le saut suivant d'une route, Google Cloud transfère le trafic vers tous les protocoles (TCP, UDP et ICMP).

  • Règle de transfert : même si cet exemple de règle de transfert spécifie le port TCP 80, lorsque l'équilibreur de charge est le saut suivant pour une route, le trafic sur tout port TCP ou UDP est envoyé aux backends de l'équilibreur de charge.

  • Adresse IP interne : l'exemple indique une adresse IP interne, 10.30.1.99, pour la règle de transfert.

Console

Démarrer la configuration

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur Créer un équilibreur de charge.
  3. Sous Type d'équilibreur de charge, sélectionnez Équilibreur de charge réseau (TCP/UDP/SSL), puis cliquez sur Suivant.
  4. Pour Proxy ou passthrough, sélectionnez Équilibreur de charge passthrough, puis cliquez sur Suivant.
  5. Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
  6. Cliquez sur Configurer.

Créer le premier équilibreur de charge

  1. Définissez le paramètre Nom sur ilb1.
  2. Définissez la région sur us-west1 :
  3. Définissez le paramètre Réseau sur testing.
  4. Cliquez sur Configuration du backend et apportez les modifications suivantes :
    1. Sous Backends, dans la section Nouvel élément, sélectionnez le groupe d'instances third-party-instance-group et cliquez sur OK.
    2. Sous Vérification d'état, sélectionnez Créer une autre vérification d'état, saisissez les informations suivantes, puis cliquez sur Enregistrer et continuer :
      • Nom : hc-http-80
      • Protocole : HTTP
      • Port : 80
      • Protocole de proxy : NONE
      • Chemin de requête : / Notez que lorsque vous créez un équilibreur de charge à l'aide de la console Google Cloud, la vérification de l'état est globale. Si vous souhaitez créer une vérification de l'état régionale, utilisez gcloud ou l'API.
    3. Sous Affinité de session, sélectionnez IP client.
    4. Vérifiez qu'une coche bleue apparaît à côté de Configuration du backend avant de continuer. Répétez cette étape si ce n'est pas le cas.
  5. Cliquez sur Configuration du frontend. Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
    1. Nom : fr-ilb1
    2. Sous-réseau : testing-subnet
    3. Dans Adresse IP interne, sélectionnez Réserver une adresse IP statique interne, saisissez les informations suivantes, puis cliquez sur Réserver :
      • Nom : ip-ilb
      • Adresse IP statique : Laissez-moi choisir
      • Adresse IP personnalisée : 10.30.1.99
    4. Ports : sélectionnez Unique et saisissez 80 pour le numéro de port. N'oubliez pas que le choix d'un protocole et d'un port pour l'équilibreur de charge ne limite pas les protocoles et les ports utilisés lorsque l'équilibreur de charge est le saut suivant d'une route.
    5. Vérifiez qu'une coche bleue apparaît à côté de Configuration du frontend avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.
  6. Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.
  7. Cliquez sur Créer.

Démarrer la configuration

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur Créer un équilibreur de charge.
  3. Sous Type d'équilibreur de charge, sélectionnez Équilibreur de charge réseau (TCP/UDP/SSL), puis cliquez sur Suivant.
  4. Pour Proxy ou passthrough, sélectionnez Équilibreur de charge passthrough, puis cliquez sur Suivant.
  5. Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
  6. Cliquez sur Configurer.

Créer le deuxième équilibreur de charge

  1. Définissez le paramètre Nom sur ilb2.
  2. Définissez la région sur us-west1 :
  3. Définissez le paramètre Réseau sur production.
  4. Cliquez sur Configuration du backend et apportez les modifications suivantes :
    1. Sous Backends, dans la section Nouvel élément, sélectionnez le groupe d'instances third-party-instance-group et cliquez sur OK.
    2. Pour Vérification d'état, sélectionnez hc-http-80.
    3. Sous Affinité de session, sélectionnez IP client.
    4. Vérifiez qu'une coche bleue apparaît à côté de Configuration du backend avant de continuer. Répétez cette étape si ce n'est pas le cas.
  5. Cliquez sur Configuration du frontend. Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
    1. Nom : fr-ilb2
    2. Sous-réseau : production-subnet
    3. Dans Adresse IP interne, sélectionnez Réserver une adresse IP statique interne, saisissez les informations suivantes, puis cliquez sur Réserver :
      • Nom : ip-ilb2
      • Adresse IP statique : Laissez-moi choisir
      • Adresse IP personnalisée : 10.50.1.99
    4. Ports : sélectionnez Unique et saisissez 80 pour le numéro de port. N'oubliez pas que le choix d'un protocole et d'un port pour l'équilibreur de charge ne limite pas les protocoles et les ports utilisés lorsque l'équilibreur de charge est le saut suivant d'une route.
    5. Vérifiez qu'une coche bleue apparaît à côté de Configuration du frontend avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.
  6. Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.

  7. Cliquez sur Create (Créer).

  8. Configurez les ressources de l'équilibreur de charge dans le réseau VPC production.

gcloud

  1. Créez une vérification d'état HTTP pour tester la connectivité TCP aux VM sur le port 80.

    gcloud compute health-checks create http hc-http-80 \
    --region=us-west1 \
    --port=80

  2. Créez deux services de backend internes dans la région us-west1.

    gcloud compute backend-services create ilb1 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=testing \
    --session-affinity=CLIENT_IP

    gcloud compute backend-services create ilb2 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=production \
    --session-affinity=CLIENT_IP

  3. Ajoutez les groupes d'instances contenant les dispositifs virtuels tiers en tant que serveurs de backend sur les services de backend.

    gcloud compute backend-services add-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services add-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  4. Créez les règles de transfert internes et connectez-les aux services de backend pour terminer la configuration de l'équilibreur de charge. N'oubliez pas que le protocole (TCP) et le port (80) des équilibreurs de charge ne limitent pas les ports et protocoles transférés aux instances backend (dispositifs virtuels tiers) lors du chargement. Les équilibreurs de charge sont utilisés comme sauts suivants des routes.

    gcloud compute forwarding-rules create fr-ilb1 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=testing \
    --subnet=testing-subnet \
    --region=us-west1 \
    --backend-service=ilb1 \
    --address=10.30.1.99

    gcloud compute forwarding-rules create fr-ilb2 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=production \
    --subnet=production-subnet \
    --region=us-west1 \
    --backend-service=ilb2 \
    --address=10.50.1.99

Créer les routes statiques qui définissent les équilibreurs de charge en tant que sauts suivants

Créez deux routes statiques personnalisées intitulées next-hop-ilb.

Console

Créer la première route

  1. Dans Google Cloud Console, accédez à la page Routes.

    Accéder à la page Routes

  2. Cliquez sur Créer une route.

  3. Dans le champ Nom de la route, saisissez ilb-nhop-dest-10-50-1.

  4. Sélectionnez le réseau testing.

  5. Pour la plage d'adresses IP de destination, saisissez 10.50.1.0/24.

  6. Dans le champ Tags d'instance, saisissez my-network-tag.

  7. Pour le saut suivant de la route, sélectionnez Spécifier une règle de transfert pour l'équilibreur de charge TCP/UDP interne.

    Pour spécifier l'adresse IP de l'équilibreur de charge en tant que saut suivant, utilisez gcloud CLI ou l'API.

  8. Spécifiez le nom de la règle de transfert. Pour le nom de la règle de transfert, sélectionnez fr-ilb1.

  9. Cliquez sur Create (Créer).

Créer la deuxième route

  1. Cliquez sur Créer une route.
  2. Dans le champ Nom de la route, saisissez ilb-nhop-dest-10-30-1.
  3. Sélectionnez le réseau testing.
  4. Pour la plage d'adresses IP de destination, saisissez 10.30.1.0/24.

  5. Pour le saut suivant de la route, sélectionnez Spécifier une règle de transfert pour l'équilibreur de charge TCP/UDP interne.

    Pour spécifier l'adresse IP de l'équilibreur de charge en tant que saut suivant, utilisez gcloud CLI ou l'API.

  6. Pour le nom de la règle de transfert, sélectionnez fr-ilb2.

  7. Cliquez sur Créer.

gcloud

Créez des routes avancées en définissant le saut suivant sur chaque règle de transfert de l'équilibreur de charge, et en définissant chaque plage de destination en conséquence.

Pour l'option --next-hop-ilb, vous pouvez spécifier le nom de la règle de transfert ou l'adresse IP. Si vous spécifiez l'adresse IP, celle-ci peut être apprise entre les pairs sans avoir à exporter la route personnalisée. Dans cet exemple, la première route utilise l'adresse IP 10.30.1.99 et la deuxième route le nom de règle de transfert fr-ilb12.

Vous pouvez éventuellement spécifier un ou plusieurs tags d'instance sur la route. La route peut s'appliquer à des VM spécifiques si vous spécifiez des tags réseau sur la route. Si vous ne spécifiez aucun tag réseau, la route s'applique à toutes les VM du réseau VPC. Dans cet exemple, la route utilise my-network-tag comme tag réseau.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag

gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

Créer l'instance de VM testing

Cet exemple crée une instance de VM avec l'adresse IP 10.30.1.100 sur le sous-réseau testing-subnet (10.30.1.0/24) du réseau VPC testing.

gcloud

  1. Créez la VM testing-vm en exécutant la commande suivante.

    gcloud compute instances create testing-vm \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh,my-network-tag \
    --subnet=testing-subnet \
    --private-network-ip 10.30.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

Créer l'instance de VM production

Cet exemple crée une instance de VM avec l'adresse IP 10.50.1.100 sur le sous-réseau production-subnet (10.50.1.0/24) du réseau VPC production.

gcloud

La VM production-vm peut se trouver dans n'importe quelle zone de la même région que l'équilibreur de charge, et utiliser n'importe quel sous-réseau de cette région. Dans cet exemple, la VM production-vm se trouve dans la zone us-west1-a.

  1. Créez la VM production-vm en exécutant la commande suivante.

    gcloud compute instances create production-vm \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

Tester l'équilibrage de charge sur un déploiement à cartes d'interface réseau multiples

  1. Vérifiez l'état des backends de l'équilibreur de charge.

    gcloud compute backend-services get-health ilb1 --region us-west1

    gcloud compute backend-services get-health ilb2 --region us-west1

  2. Testez la connectivité à partir de la VM testing.

    gcloud compute ssh testing-vm --zone=us-west1-a

    curl http://10.50.1.99

    exit

  3. Testez la connectivité à partir de la VM production.

    gcloud compute ssh production-vm --zone=us-west1-a

    curl http://10.30.1.99

    exit

Activer le hachage symétrique

Lors du calcul du hachage mappé à l'instance backend, Google Cloud ignore la direction des adresses IP et des ports. La valeur de hachage cohérente d'un paquet TCP/UDP est identique, quelle que soit la direction d'origine du paquet. C'est ce qu'on appelle le hachage symétrique.

Pour activer ce comportement de hachage sur les équilibreurs de charge réseau internes existants, vous devez recréer la règle de transfert et la route de saut suivant.

Pour en savoir plus, consultez la section Hachage symétrique.

Supprimer et recréer des règles de transfert

Console

Supprimer une règle de transfert et en créer une nouvelle

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur votre équilibreur de charge be-ilb, puis sur Modifier.

  3. Cliquez sur Frontend configuration (Configuration du frontend).

  4. Gardez le pointeur de la souris sur votre règle de transfert, puis cliquez sur Supprimer pour la supprimer.

  5. Cliquez sur Ajouter une adresse IP et un port frontend.

  6. Dans la section Nouveaux IP et port d'interface, apportez les modifications suivantes :

    1. Nom : FORWARDING_RULE_NAME
    2. Sous-réseau : SUBNET_NAME
    3. Dans le champ Adresse IP interne, sélectionnez IP_ADDRESS.
    4. Ports : PORT_NUMBER ou ALL.
    5. Cliquez sur OK.
    6. Vérifiez qu'une coche bleue apparaît à côté de Configuration de l'interface avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.

  7. Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.

  8. Cliquez sur Create (Créer).

gcloud

  1. Supprimez vos règles de transfert existantes.

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
    --region=REGION

  2. Créez des règles de transfert de remplacement portant le même nom.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=internal \
    --ports=PORT_NUMBER or `ALL` \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --region=REGION \
    --backend-service=BACKEND_SERVICE_NAME \
    --address=IP_ADDRESS

Lorsque la SNAT n'est pas requise

Comme illustré dans l'exemple précédent, la traduction d'adresse réseau source (SNAT) n'est pas requise lorsque toutes les conditions suivantes sont remplies :

  • La règle de transfert de l'équilibreur de charge réseau interne à stratégie directe a été créée le 22 juin 2021 ou après cette date.
  • La route statique personnalisée faisant référence à la règle de transfert a été créée le 22 juin 2021 ou après cette date.
  • Le service de backend de l'équilibreur de charge réseau interne à stratégie directe n'utilise pas le paramètre d'affinité de session NONE.

Pour convertir la route existante d'un équilibreur de charge réseau interne à stratégie directe de saut suivant afin d'utiliser le hachage symétrique, procédez comme suit :

  • Assurez-vous que le service de backend de l'équilibreur de charge réseau interne à stratégie directe n'utilise pas le paramètre d'affinité de session NONE.

  • Créez une règle de transfert de remplacement qui référence le même service de backend. La règle de transfert de remplacement utilise une adresse IP différente.

  • Créez une route statique personnalisée de remplacement faisant référence à la nouvelle règle de transfert. Assurez-vous que cette route de remplacement a une priorité plus élevée que la route existante.

  • Supprimez la route existante de priorité inférieure (qui référence à la règle de transfert précédente), puis supprimez la règle de transfert précédente.

Nettoyage

  1. Dans la configuration de l'équilibreur de charge, supprimez le backend des services de backend.

    gcloud compute backend-services remove-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services remove-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  2. Supprimez les routes.

    gcloud compute routes delete ilb-nhop-dest-10-50-1

    gcloud compute routes delete ilb-nhop-dest-10-30-1

  3. Dans les configurations de l'équilibreur de charge, supprimez les règles de transfert.

    gcloud compute forwarding-rules delete fr-ilb1 \
    --region=us-west1

    gcloud compute forwarding-rules delete fr-ilb2 \
    --region=us-west1

  4. Dans les configurations de l'équilibreur de charge, supprimez les services de backend.

    gcloud compute backend-services delete ilb1 \
    --region=us-west1

    gcloud compute backend-services delete ilb2 \
    --region=us-west1

  5. Dans les configurations de l'équilibreur de charge, supprimez la vérification d'état.

    gcloud compute health-checks delete hc-http-80 \
    --region=us-west1

    Si vous avez utilisé la console Google Cloud, la vérification de l'état est globale. Par conséquent, la commande est la suivante :

    gcloud compute health-checks delete hc-http-80 \
     --global

  6. Supprimez le groupe d'instances géré.

    gcloud compute instance-groups managed delete third-party-instance-group \
    --region=us-west1

  7. Supprimez les modèles d'instance.

    gcloud compute instance-templates delete third-party-template

    gcloud compute instance-templates delete third-party-template-multinic

  8. Supprimez les instances de test et de production.

    gcloud compute instances delete testing-vm \
    --zone=us-west1-a

    gcloud compute instances delete production-vm \
    --zone=us-west1-a

Étapes suivantes