Configurer l'équilibrage de charge TCP/UDP interne

Ce guide s'appuie sur un exemple pour enseigner les principes fondamentaux de l'équilibrage de charge TCP/UDP interne de Google Cloud. Avant de suivre ce guide, familiarisez-vous avec les points suivants :

Permissions

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

Pour en savoir plus, consultez les guides suivants :

Prérequis

Ce guide vous explique comment configurer et tester un équilibreur de charge TCP/UDP interne. Les étapes de cette section décrivent comment configurer les éléments suivants :

  1. Un exemple de réseau VPC avec des sous-réseaux personnalisés
  2. Des règles de pare-feu autorisant les connexions entrantes aux VM de backend
  3. Quatre VM de backend :
    • Deux VM dans un groupe d'instances non géré dans la zone us-west1-a
    • Deux VM dans un groupe d'instances non géré dans la zone us-west1-c
  4. VM cliente pour tester les connexions
  5. Les composants d'équilibreur de charge TCP/UDP interne suivants :
    • Vérification d'état du service de backend
    • Un service de backend interne dans la région us-west1 pour gérer la distribution des connexions vers les deux groupes d'instances régionaux
    • Règle de transfert interne et adresse IP interne pour l'interface de l'équilibreur de charge

L'architecture de cet exemple se présente comme suit :

Exemple de configuration de l'équilibrage de charge TCP/UDP interne (cliquez pour agrandir)
Exemple de configuration de l'équilibrage de charge TCP/UDP interne (cliquez pour agrandir)

Configurer un réseau, une région et un sous-réseau

Vous avez besoin d'un réseau VPC avec au moins un sous-réseau. Les équilibreurs de charge TCP/UDP internes sont régionaux. Le trafic au sein du réseau VPC est acheminé vers l'équilibreur de charge si sa source provient d'un sous-réseau situé dans la même région que l'équilibreur de charge.

Cet exemple utilise le réseau VPC, la région et le sous-réseau suivants :

  • Réseau : le réseau est un réseau VPC en mode personnalisé nommé lb-network.

  • Région : la région est us-west1.

  • Sous-réseau : le sous-réseau lb-subnet utilise la plage d'adresses IP 10.1.2.0/24.

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

Console

  1. Accédez à la page "Réseaux VPC" dans Google Cloud Console.
    Accéder à la page "Réseaux VPC"
  2. Cliquez sur Créer un réseau VPC.
  3. Saisissez le nom lb-network.
  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 : lb-subnet
      • Région : us-west1
      • Plage d'adresses IP : 10.1.2.0/24
      • Cliquez sur OK.
  5. Cliquez sur Créer.

gcloud

  1. Créez le réseau VPC personnalisé :

        gcloud compute networks create lb-network --subnet-mode=custom
        
  2. Créez un sous-réseau sur le réseau lb-network, dans la région us-west1 :

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

api

Envoyez une requête POST à la méthode networks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks
    {
      "routingConfig": {
        "routingMode": "REGIONAL"
      },
      "name": "lb-network",
      "autoCreateSubnetworks": false
    }
    

Envoyez une requête POST à la méthode subnetworks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks
    {
      "name": "lb-subnet",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "ipCidrRange": "10.1.2.0/24",
      "privateIpGoogleAccess": false
    }
    

Configurer les règles de pare-feu

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

  • fw-allow-lb-subnet : règle d'entrée applicable à toutes les cibles du réseau VPC, autorisant tout le trafic provenant de sources comprises dans la plage 10.1.2.0/24. Cette règle autorise le trafic entrant depuis n'importe quelle source du sous-réseau lb-subnet vers les instances (VM) faisant l'objet d'un équilibrage de charge.

  • fw-allow-ssh : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui 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 uniquement les plages d'adresses IP du système à partir duquel vous prévoyez de lancer des sessions SSH. Cet exemple utilise le tag cible allow-ssh pour identifier les VM auxquelles il doit s'appliquer.

  • fw-allow-health-check : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise le trafic issu 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.

Console

  1. Accédez à la page "Règles de pare-feu" de Google Cloud Console.
    Accéder à la page "Règles 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 d'autoriser le trafic de sous-réseau :
    • Nom : fw-allow-lb-subnet
    • Réseau : lb-network
    • Priorité : 1000
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : toutes les instances du réseau
    • Filtre source : IP ranges
    • Plages d'adresses IP sources : 10.1.2.0/24
    • Protocoles et ports : tout autoriser
  3. Cliquez sur Créer.
  4. Cliquez de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes :
    • Nom : fw-allow-ssh
    • Réseau : lb-network
    • 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 : IP ranges
    • Plages d'adresses IP sources : 0.0.0.0/0
    • Protocoles et ports : choisissez Protocoles et ports spécifiés, puis saisissez tcp:22.
  5. Cliquez sur Créer.
  6. Cliquez une troisième fois sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud :
    • Nom : fw-allow-health-check
    • Réseau : lb-network
    • 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 : IP ranges
    • Plages d'adresses IP sources : 130.211.0.0/22 et 35.191.0.0/16
    • Protocoles et ports : tout autoriser
  7. Cliquez sur Créer.

gcloud

  1. Créez la règle de pare-feu fw-allow-lb-subnet pour autoriser la communication depuis le sous-réseau :

        gcloud compute firewall-rules create fw-allow-lb-subnet \
            --network=lb-network \
            --action=allow \
            --direction=ingress \
            --source-ranges=10.1.2.0/24 \
            --rules=tcp,udp,icmp
        
  2. Créez la règle de pare-feu fw-allow-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-ssh \
            --network=lb-network \
            --action=allow \
            --direction=ingress \
            --target-tags=allow-ssh \
            --rules=tcp:22
        
  3. Créez la règle fw-allow-health-check pour autoriser les vérifications d'état Google Cloud.

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

api

Créez la règle de pare-feu fw-allow-lb-subnet en envoyant une requête POST à la méthode firewalls.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    {
      "name": "fw-allow-lb-subnet",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "priority": 1000,
      "sourceRanges": [
        "10.1.2.0/24"
      ],
      "allowed": [
        {
          "IPProtocol": "tcp"
        },
        {
          "IPProtocol": "udp"
        },
        {
          "IPProtocol": "icmp"
        }
      ],
      "direction": "INGRESS",
      "logConfig": {
        "enable": false
      },
      "disabled": false
    }
    

Créez la règle de pare-feu fw-allow-ssh en envoyant une requête POST à la méthode firewalls.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    {
      "name": "fw-allow-ssh",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "priority": 1000,
      "sourceRanges": [
        "0.0.0.0/0"
      ],
      "targetTags": [
        "allow-ssh"
      ],
      "allowed": [
       {
         "IPProtocol": "tcp",
         "ports": [
           "22"
         ]
       }
      ],
     "direction": "INGRESS",
     "logConfig": {
       "enable": false
     },
     "disabled": false
    }
    

Créez la règle de pare-feu fw-allow-health-check en envoyant une requête POST à la méthode firewalls.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    {
      "name": "fw-allow-health-check",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "priority": 1000,
      "sourceRanges": [
        "130.211.0.0/22",
        "35.191.0.0/16"
      ],
      "targetTags": [
        "allow-health-check"
      ],
      "allowed": [
        {
          "IPProtocol": "tcp"
        },
        {
          "IPProtocol": "udp"
        },
        {
          "IPProtocol": "icmp"
        }
      ],
      "direction": "INGRESS",
      "logConfig": {
        "enable": false
      },
      "disabled": false
    }
    

Créer des VM de backend et des groupes d'instances

Cet exemple utilise deux groupes d'instances non gérés ayant chacun deux VM de backend (serveur). Pour démontrer la nature régionale de l'équilibrage de charge TCP/UDP interne, les deux groupes d'instances sont placés dans des régions distinctes, us-west1-a et us-west1-c.

  • Le groupe d'instances ig-a contient les deux VM suivantes :
    • vm-a1
    • vm-a2
  • Le groupe d'instances ig-c contient les deux VM suivantes :
    • vm-c1
    • vm-c2

Le trafic vers les quatre VM de backend est équilibré. Chacune des quatre VM exécute un serveur Web Apache sur les ports TCP 80 et 443. Chaque VM reçoit une adresse IP interne dans lb-subnet et une adresse IP externe éphémère (publique). Vous pouvez supprimer les adresses IP externes ultérieurement.

Les adresses IP externes des VM de backend ne sont pas obligatoires. Toutefois, elles sont utiles dans cet exemple, car elles permettent aux VM de backend de télécharger Apache depuis Internet, en plus de faciliter la connexion via SSH.

Par défaut, Apache est configuré pour se lier à n’importe quelle adresse IP. Les équilibreurs de charge TCP/UDP internes distribuent les paquets en conservant l'adresse IP de destination. Vérifiez que le logiciel serveur exécuté sur les VM de backend écoute l'adresse IP de la règle de transfert interne de l'équilibreur de charge. Si vous configurez plusieurs règles de transfert internes, assurez-vous que votre logiciel écoute l'adresse IP interne associée à chacune d'elles. L'adresse IP de destination d'un paquet distribué à une VM de backend par un équilibreur de charge TCP/UDP interne est l'adresse IP interne de la règle de transfert.

Pour plus de simplicité, ces VM de backend exécutent Debian GNU/Linux 9.

Console

Créer des VM de backend

  1. Accédez à la page Instances de VM de Google Cloud Console.
    Accéder à la page Instances de VM
  2. Répétez les étapes ci-dessous pour créer quatre VM, en utilisant les combinaisons de noms et de zones suivantes :
    • Nom : vm-a1, zone : us-west1-a
    • Nom : vm-a2, zone : us-west1-a
    • Nom : vm-c1, zone : us-west1-c
    • Nom : vm-c2, zone : us-west1-c
  3. Cliquez sur Créer une instance.
  4. Définissez le Nom comme indiqué à l'étape 2.
  5. Pour la région, choisissez us-west1, puis choisissez une zone comme indiqué à l'étape 2.
  6. Dans la section Disque de démarrage, assurez-vous que les options sélectionnées sont Debian pour le système d'exploitation et 9 Stretch pour la version. Si nécessaire, cliquez sur Sélectionner pour modifier l'image.
  7. Cliquez sur Gestion, sécurité, disques, mise en réseau et location unique et apportez les modifications suivantes :

    • Cliquez sur Mise en réseau et ajoutez les tags réseau suivants : allow-ssh et allow-health-check.
    • Cliquez sur le bouton de modification sous Interfaces réseau, apportez les modifications suivantes, puis cliquez sur OK :
      • Réseau : lb-network
      • Sous-réseau : lb-subnet
      • Adresse IP interne principale : éphémère (automatique)
      • Adresse IP externe : Éphémère
    • Cliquez sur Gestion. Dans le champ Script de démarrage, copiez et collez le contenu de script suivant. Le contenu du script est identique pour les quatre VM :

      #! /bin/bash
          apt-get update
          apt-get install apache2 -y
          a2ensite default-ssl
          a2enmod ssl
          vm_hostname="$(curl -H "Metadata-Flavor:Google" \
          http://169.254.169.254/computeMetadata/v1/instance/name)"
          echo "Page served from: $vm_hostname" | \
          tee /var/www/html/index.html
          systemctl restart apache2
          
  8. Cliquez sur Créer.

Créer des groupes d'instances

  1. Accédez à la page Groupes d'instances de Google Cloud Console.
    Accéder à la page Groupes d'instances
  2. Répétez les étapes ci-dessous pour créer deux groupes d'instances non gérés, comportant chacun deux VM, à l'aide des combinaisons suivantes.
    • Groupe d'instances : ig-a, zone : us-west1-a, VM : vm-a1 et vm-a2
    • Groupe d'instances : ig-c, zone : us-west1-c, VM : vm-c1 et vm-c2
  3. Cliquez sur Créer un groupe d'instances.
  4. Définissez le Nom comme indiqué à l'étape 2.
  5. Dans la section Emplacement, sélectionnez Zone unique, choisissez us-west1 pour la région, puis choisissez la zonecomme indiqué à l'étape 2.
  6. Dans la section Type de groupe, sélectionnez Groupe d'instances non géré.
  7. Pour Réseau, saisissez la valeur suivante : lb-network.
  8. Pour Sous-réseau, saisissez la valeur suivante : lb-subnet.
  9. Dans la section Instances de VM, ajoutez les VM comme indiqué à l'étape 2.
  10. Cliquez sur Créer.

gcloud

  1. Créez quatre VM en exécutant la commande suivante quatre fois, en utilisant ces quatre combinaisons pour [VM-NAME] et [ZONE]. Le contenu du script est identique pour les quatre VM.

    • [VM-NAME] : vm-a1 et [ZONE] : us-west1-a
    • [VM-NAME] : vm-a2 et [ZONE] : us-west1-a
    • [VM-NAME] : vm-c1 et [ZONE] : us-west1-c
    • [VM-NAME] : vm-c2 et [ZONE] : us-west1-c
        gcloud compute instances create [VM-NAME] \
            --zone=[ZONE] \
            --image-family=debian-9 \
            --image-project=debian-cloud \
            --tags=allow-ssh,allow-health-check \
            --subnet=lb-subnet \
            --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
        
  2. Créez les deux groupes d'instances non gérés dans chaque zone :

        gcloud compute instance-groups unmanaged create ig-a \
            --zone=us-west1-a
        gcloud compute instance-groups unmanaged create ig-c \
            --zone=us-west1-c
        
  3. Ajoutez les VM aux groupes d'instances appropriés :

        gcloud compute instance-groups unmanaged add-instances ig-a \
            --zone=us-west1-a \
            --instances=vm-a1,vm-a2
        gcloud compute instance-groups unmanaged add-instances ig-c \
            --zone=us-west1-c \
            --instances=vm-c1,vm-c2
        

api

Pour les quatre VM, utilisez les noms et zones de VM suivants :

  • [VM-NAME] : vm-a1 et [ZONE] : us-west1-a
  • [VM-NAME] : vm-a2 et [ZONE] : us-west1-a
  • [VM-NAME] : vm-c1 et [ZONE] : us-west1-c
  • [VM-NAME] : vm-c2 et [ZONE] : us-west1-c

Créez quatre VM de backend en envoyant quatre requêtes POST à la méthode instances.insert :

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances
    {
      "name": "[VM-NAME]",
      "tags": {
        "items": [
          "allow-health-check",
          "allow-ssh"
        ]
      },
      "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/machineTypes/n1-standard-1",
      "canIpForward": false,
      "networkInterfaces": [
        {
          "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
          "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
          "accessConfigs": [
            {
              "type": "ONE_TO_ONE_NAT",
              "name": "external-nat",
              "networkTier": "PREMIUM"
            }
          ]
        }
      ],
      "disks": [
        {
          "type": "PERSISTENT",
          "boot": true,
          "mode": "READ_WRITE",
          "autoDelete": true,
          "deviceName": "[VM-NAME]",
          "initializeParams": {
            "sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
            "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
            "diskSizeGb": "10"
          }
        }
      ]
      "metadata": {
        "items": [
          {
            "key": "startup-script",
            "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
      },
      "scheduling": {
        "preemptible": false
      },
      "deletionProtection": false
    }
    

Créez deux groupes d'instances en envoyant une requête POST à la méthode instanceGroups.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups
    {
      "name": "ig-a",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
    }

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups
    {
      "name": "ig-c",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
    }
    

Ajoutez des instances à chaque groupe d'instances en envoyant une requête POST à la méthode instanceGroups.addInstances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a/addInstances
    {
      "instances": [
        {
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a1",
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a2"
        }
      ]
    }

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c/addInstances
    {
      "instances": [
        {
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c1",
          "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c2"
        }
      ]
    }
    

Créer une VM cliente

Cet exemple crée une VM cliente (vm-client) dans la même région que les VM de backend (serveur). Le client est utilisé pour valider la configuration de l'équilibreur de charge et faire la démonstration du comportement attendu, tel que décrit dans la section consacrée aux tests.

Console

  1. Accédez à la page Instances de VM de Google Cloud Console.
    Accéder à la page Instances de VM
  2. Cliquez sur Créer une instance.
  3. Définissez le paramètre Nom sur vm-client.
  4. Définissez le paramètre Zone sur us-west1-a.
  5. Cliquez sur Gestion, sécurité, disques, mise en réseau et location unique et apportez les modifications suivantes :
    • Cliquez sur Mise en réseau et ajoutez allow-ssh aux tags réseau.
    • Cliquez sur le bouton de modification sous Interfaces réseau, apportez les modifications suivantes, puis cliquez sur OK :
      • Réseau : lb-network
      • Sous-réseau : lb-subnet
      • Adresse IP interne principale : éphémère (automatique)
      • Adresse IP externe : Éphémère
  6. Cliquez sur Créer.

gcloud

La VM cliente 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, le client se situe dans la zone us-west1-a et utilise le même sous-réseau que les VM de backend.

    gcloud compute instances create vm-client \
        --zone=us-west1-a \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=lb-subnet
    

api

Envoyez une requête POST à la méthode instances.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances
    {
      "name": "vm-client",
      "tags": {
        "items": [
          "allow-ssh"
        ]
      },
      "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/machineTypes/n1-standard-1",
      "canIpForward": false,
      "networkInterfaces": [
        {
          "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
          "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
          "accessConfigs": [
            {
              "type": "ONE_TO_ONE_NAT",
              "name": "external-nat",
              "networkTier": "PREMIUM"
            }
          ]
        }
      ],
      "disks": [
        {
          "type": "PERSISTENT",
          "boot": true,
          "mode": "READ_WRITE",
          "autoDelete": true,
          "deviceName": "[VM-NAME]",
          "initializeParams": {
            "sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
            "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
            "diskSizeGb": "10"
          }
        }
      ]
      "scheduling": {
        "preemptible": false
      },
      "deletionProtection": false
    }
    

Configurer les composants de l'équilibreur de charge

Ces étapes permettent de configurer tous les composants de l'équilibreur de charge TCP/UDP interne, en commençant par la vérification d'état et le service de backend, puis en passant aux composants d'interface :

  • Vérification d'état : dans cet exemple, la vérification d'é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'équilibrage de charge TCP/UDP interne.

  • Service de backend : étant donné que nous devons transmettre le trafic HTTP via l'équilibreur de charge interne, nous devons utiliser TCP, et non UDP.

  • Règle de transfert : Cet exemple crée une seule règle de transfert interne.

  • Adresse IP interne : dans cet exemple, nous indiquons une adresse IP interne, 10.1.2.99, lors de la création de la règle de transfert.

Console

Créer l'équilibreur de charge et configurer un service de backend

  1. Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
    Accéder à la page "Équilibrage de charge"
  2. Cliquez sur Créer un équilibreur de charge.
  3. Sous Équilibrage de charge TCP, cliquez sur Démarrer la configuration.
  4. Sous Web ou interne uniquement, sélectionnez Seulement entre les VM.
  5. Cliquez sur Continuer.
  6. Définissez le paramètre Nom sur be-ilb.
  7. Cliquez sur Configuration du backend et apportez les modifications suivantes :
    1. Région : us-west1
    2. Réseau : lb-network
    3. Sous Backends, dans la section Nouvel élément, sélectionnez le groupe d'instances ig-a et cliquez sur OK.
    4. Cliquez sur Ajouter le backend. Dans la section Nouvel élément qui s'affiche, sélectionnez le groupe d'instances ig-c, puis cliquez à nouveau sur OK.
    5. 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 : /
    6. 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.
  8. Cliquez sur Configuration du frontend. Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
    1. Nom : fr-ilb
    2. Sous-réseau : lb-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.1.2.99
    4. Ports : sélectionnez Unique et saisissez 80 pour le numéro de port.
    5. Vérifiez qu'une coche bleue apparaît à côté de Configuration de l'interface avant de continuer. Répétez cette étape si ce n'est pas le cas.
  9. Cliquez sur Vérification et finalisation. Vérifiez vos paramètres.
  10. Cliquez sur Créer.

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 \
            --port=80
        
  2. Créez le service de backend pour le trafic HTTP :

        gcloud compute backend-services create be-ilb \
            --load-balancing-scheme=internal \
            --protocol=tcp \
            --region=us-west1 \
            --health-checks=hc-http-80
        
  3. Ajoutez les deux groupes d'instances au service de backend :

        gcloud compute backend-services add-backend be-ilb \
            --region=us-west1 \
            --instance-group=ig-a \
            --instance-group-zone=us-west1-a
        gcloud compute backend-services add-backend be-ilb \
            --region=us-west1 \
            --instance-group=ig-c \
            --instance-group-zone=us-west1-c
        
  4. Créez une règle de transfert pour le service de backend. Lorsque vous créez la règle de transfert, indiquez 10.1.2.99 pour l'adresse IP interne dans le sous-réseau.

        gcloud compute forwarding-rules create fr-ilb \
            --region=us-west1 \
            --load-balancing-scheme=internal \
            --network=lb-network \
            --subnet=lb-subnet \
            --address=10.1.2.99 \
            --ip-protocol=TCP \
            --ports=80 \
            --backend-service=be-ilb \
            --backend-service-region=us-west1
        

api

Créez la vérification d'état en envoyant une requête POST à la méthode healthChecks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks
    {
      "name": "hc-http-80",
      "type": "HTTP",
      "httpHealthCheck": {
        "port": 80
      }
    }
    

Créez le service de backend régional en envoyant une requête POST à la méthode regionBackendServices.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices
    {
      "name": "be-ilb",
      "backends": [
        {
          "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a",
          "balancingMode": "CONNECTION"
        }
        {
          "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c",
          "balancingMode": "CONNECTION"
        }
      ],
      "healthChecks": [
        "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/hc-http-80"
      ],
      "loadBalancingScheme": "INTERNAL",
      "connectionDraining": {
        "drainingTimeoutSec": 0
      }
    }
    

Créez la règle de transfert en envoyant une requête POST à la méthode forwardingRules.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/forwardingRules
    {
      "name": "fr-ilb",
      "IPAddress": "10.1.2.99",
      "IPProtocol": "TCP",
      "ports": [
        "80"
      ],
      "loadBalancingScheme": "INTERNAL",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "backendService": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb",
      "networkTier": "PREMIUM"
    }
    

Test

Ces tests vous montrent comment valider la configuration de votre équilibreur de charge et en savoir plus sur son comportement attendu.

Test de l'équilibrage de charge

Ce test contacte l'équilibreur de charge à partir d'une VM cliente distincte (autre qu'une VM de backend de l'équilibreur de charge). Le comportement attendu est une répartition du trafic entre les quatre VM de backend, car aucune affinité de session n'a été configurée.

  1. Connectez-vous à l'instance de VM cliente.

        gcloud compute ssh vm-client --zone=us-west1-a
        
  2. Envoyez une requête Web à l'équilibreur de charge à l'aide de curl pour contacter son adresse IP. Répétez la requête pour que les réponses proviennent de différentes VM de backend. Le nom de la VM qui génère la réponse est affiché dans le texte de la réponse HTML, selon le contenu de /var/www/html/index.html sur chaque VM de backend. Les réponses attendues ressemblent à ceci : Page served from: vm-a1, Page served from: vm-a2, etc.

        curl http://10.1.2.99
        
    • Si vous ajoutez un libellé de service à la règle de transfert interne, vous pouvez utiliser le DNS interne pour contacter l'équilibreur de charge à l'aide de son nom de service.

          curl http://web-test.fr-ilb.il4.us-west1.lb.[PROJECT_ID].internal
          

Ping de l'adresse IP de l'équilibreur de charge

Ce test illustre un comportement attendu : vous ne pouvez pas pinguer l'adresse IP de l'équilibreur de charge. En effet, les équilibreurs de charge TCP/UDP internes sont mis en œuvre dans la programmation de réseaux virtuels. Il ne s'agit pas d'appareils distincts.

  1. Connectez-vous à l'instance de VM cliente.

        gcloud compute ssh vm-client --zone=us-west1-a
        
  2. Essayez de pinguer l'adresse IP de l'équilibreur de charge. Notez que vous n'obtenez pas de réponse et que la commande ping expire au bout de 10 secondes dans cet exemple.

        timeout 10 ping 10.1.2.99
        

Envoi de requêtes à partir de VM à équilibrage de charge

Ce test montre que les requêtes adressées à l'équilibreur de charge provenant de l'une des VM de backend (VM du serveur à équilibrage de charge) reçoivent toujours une réponse de la même VM qui envoie la requête.

L'équilibrage de charge TCP/UDP interne est mis en œuvre à l'aide d'une programmation de réseau virtuel et de la configuration de VM dans le système d'exploitation invité. Sur les VM Linux, l'environnement invité Linux effectue la configuration locale en installant une route dans la table de routage du système d'exploitation invité. En raison de ce routage local, le trafic vers l'adresse IP de l'équilibreur de charge reste sur la VM à équilibrage de charge elle-même. (Cette route locale est différente des routes du réseau VPC).

  1. Connectez-vous à une VM de backend, telle que vm-a1 :

        gcloud compute ssh vm-a1 --zone=us-west1-a
        
  2. Envoyez une requête Web à l'équilibreur de charge (par adresse IP ou nom de service) à l'aide de curl. Répétez la requête et notez que la réponse est envoyée par la VM de backend qui effectue la requête. La réponse attendue lors du test à partir de vm-a1 est toujours la suivante : Page served from: vm-a1.

        curl http://10.1.2.99
        
  3. Inspectez la table de routage locale et recherchez une destination correspondant à l'adresse IP de l'équilibreur de charge lui-même : 10.1.2.99. Ce routage fait partie intégrante de l'équilibrage de charge TCP/UDP interne, mais il permet également de comprendre pourquoi une requête provenant d'une VM derrière l'équilibreur de charge reçoit toujours une réponse de la même VM.

        ip route show table local | grep 10.1.2.99
        

Options de configuration supplémentaires

Cette section développe l'exemple de configuration et propose d'autres options de configuration. Toutes les tâches sont facultatives. Vous pouvez les exécuter dans n'importe quel ordre.

Activer l'accès mondial

Grâce à l'accès mondial, les instances de VM clientes de n'importe quelle région peuvent accéder à vos équilibreurs de charge TCP/UDP internes.

Dans l'exemple suivant, une VM cliente de la région europe-west1 accède à l'équilibreur de charge TCP/UDP interne dans la région us-west1.

Équilibrage de charge TCP/UDP interne avec accès mondial (cliquez pour agrandir)
Équilibrage de charge TCP/UDP interne avec accès mondial (cliquez pour agrandir)

Par défaut, les VM clientes distribuant du trafic vers votre réseau VPC doivent se trouver dans la même région que celle de l'adresse IP de la règle de transfert interne et des backends associés. Vous pouvez ignorer ce comportement par défaut en activant l'accès mondial, ce qui permet aux clients de toutes les régions d'accéder aux backends de l'équilibreur de charge. Les instances backend doivent toujours être situées dans une seule région, qui doit être la même que celle de l'équilibreur de charge.

L'accès mondial étend également les possibilités de déploiement lorsque vous accédez à un équilibreur de charge TCP/UDP interne à partir de réseaux VPC connectés à l'aide de l'appairage de réseaux VPC. Pour en savoir plus, consultez la section Équilibrage de charge interne et réseaux connectés.

Pour configurer l'accès mondial, procédez aux modifications de configuration ci-dessous.

Console

Modifier la règle de transfert de l'équilibreur de charge

  1. Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
    Accéder à la page Équilibrage de charge
  2. Dans la colonne Nom, cliquez sur votre équilibreur de charge TCP/UDP interne.
  3. Cliquez sur Modifier.
  4. Cliquez sur Configuration du frontend.
  5. Cliquez sur l'icône en forme de crayon.
  6. Sous Accès mondial, sélectionnez Activer.
  7. Cliquez sur OK.
  8. Cliquez sur Mettre à jour.

Sur la page Détails de l'équilibreur de charge, vérifiez que la configuration du frontend indique Régional (region) avec accès mondial.

gcloud

  1. Mettez à jour votre règle de transfert existante, fr-ilb, pour inclure l'option --allow-global-access.

        gcloud compute forwarding-rules update fr-ilb \
           --allow-global-access
        
  2. Assurez-vous que la règle de transfert autorise un accès mondial.

        gcloud compute forwarding-rules describe fr-ilb
        

    Le résultat doit inclure allowGlobalAccess: true.

  3. Créez une VM cliente dans une région différente de celle de l'équilibreur de charge. Dans cet exemple, le client se trouve dans la région europe-west1.

        gcloud compute instances create vm-client2 \
           --zone=europe-west1-a \
           --image-family=debian-9 \
           --image-project=debian-cloud \
           --tags=allow-ssh \
           --subnet=lb-subnet
        
  4. Connectez-vous à l'instance de VM cliente et testez la connectivité.

        gcloud compute ssh vm-client2 --zone=europe-west1-a
        
        curl http://10.1.2.99
        

api

Envoyez une requête PATCH à la méthode forwardingRules/patch.

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/forwardingRules/fr-ilb
    {
      "allowGlobalAccess": true
    }
    

Configurer des groupes d'instances gérés

L'exemple de configuration a créé deux groupes d'instances non gérés. Vous pouvez également utiliser des groupes d'instances gérés, y compris des groupes d'instances gérés zonaux et régionaux, comme backends pour l'équilibrage de charge TCP/UDP interne.

Les groupes d'instances gérés nécessitent la création d'un modèle d'instance. Cette procédure montre comment remplacer les deux groupes d'instances zonaux non gérés de l'exemple par un seul groupe d'instances géré régional. Un groupe d'instances géré régional crée automatiquement des VM dans plusieurs zones de la région, ce qui simplifie la distribution du trafic de production entre les zones.

Les groupes d'instances gérés sont également compatibles avec l'autoscaling et l'autoréparation. Si vous utilisez l'autoscaling avec l'équilibrage de charge TCP/UDP interne, vous ne pouvez pas effectuer de scaling en fonction de l'équilibrage de charge.

Cette procédure vous montre comment modifier le service de backend pour l'exemple d'équilibreur de charge TCP/UDP interne afin qu'il utilise un groupe d'instances géré régional.

Console

Modèle d'instance

  1. Accédez à la page Modèles d'instances de VM dans Google Cloud Console.
    Accéder à la page Modèles d'instance de VM
  2. Cliquez sur Créer un modèle d'instance.
  3. Définissez le paramètre Nom sur template-vm-ilb.
  4. Choisissez un type de machine.
  5. Pour Disque de démarrage, cliquez sur Modifier. Choisissez le système d'exploitation Debian et la version 9 Stretch.
  6. Cliquez sur Enregistrer pour confirmer les options de ce disque de démarrage.
  7. Cliquez sur Gestion, sécurité, disques, réseau et location unique.
    • Cliquez sur Mise en réseau, puis apportez les modifications suivantes :
      • Réseau : lb-network
      • Sous-réseau : lb-subnet
      • Tags réseau : allow-ssh et allow-health-check
    • Cliquez sur Gestion. Dans le champ Script de démarrage, copiez et collez le contenu de script suivant :
      #! /bin/bash
          apt-get update
          apt-get install apache2 -y
          a2ensite default-ssl
          a2enmod ssl
          vm_hostname="$(curl -H "Metadata-Flavor:Google" 
      http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" |
      tee /var/www/html/index.html systemctl restart apache2
  8. Cliquez sur Créer.

Groupe d'instances géré

  1. Accédez à la page Groupes d'instances de VM dans Google Cloud Console.
    Accéder à la page Groupes d'instances de VM
  2. Cliquez sur Créer un groupe d'instances.
  3. Définissez le paramètre Nom sur ig-ilb.
  4. Pour Emplacement, sélectionnez Multizone et définissez la Région sur us-west1.
  5. Définissez le Modèle d'instance sur template-vm-ilb.
  6. (Facultatif) Configurez l'autoscaling. Vous ne pouvez pas effectuer d'autoscaling sur le groupe d'instances en fonction de l'utilisation de l'équilibrage de charge HTTP, car le groupe d'instances est un backend pour l'équilibrage de charge TCP/UDP interne.
  7. Définissez le nombre minimal d'instances sur 1 et le nombre maximal d'instances sur 6.
  8. (Facultatif) Configurez l'autoréparation. Si vous configurez l'autoréparation, utilisez la même vérification d'état que celle utilisée par le service de backend pour l'équilibreur de charge TCP/UDP interne. Dans cet exemple, utilisez hc-http-80.
  9. Cliquez sur Créer.

gcloud

  1. Créez le modèle d'instance. Si vous le souhaitez, vous pouvez définir d'autres paramètres, tels que le type de machine, que le modèle d'image doit utiliser.

        gcloud compute instance-templates create template-vm-ilb \
            --image-family=debian-9 \
            --image-project=debian-cloud \
            --tags=allow-ssh,allow-health-check \
            --subnet=lb-subnet \
            --region=us-west1 \
            --network=lb-network \
            --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
        
  2. Créez un groupe d'instances géré régional à l'aide du modèle :

        gcloud compute instance-groups managed create ig-ilb \
            --template=template-vm-ilb \
            --region=us-west1 \
            --size=6
        
  3. Ajoutez le groupe d'instances géré régional en tant que backend au service de backend que vous avez déjà créé :

        gcloud compute backend-services add-backend be-ilb \
            --region=us-west1 \
            --instance-group=ig-ilb \
            --instance-group-region=us-west1
        
  4. Déconnectez les deux groupes d'instances non gérés (zonaux) du service de backend :

        gcloud compute backend-services remove-backend be-ilb \
            --region=us-west1 \
            --instance-group=ig-a \
            --instance-group-zone=us-west1-a
        gcloud compute backend-services remove-backend be-ilb \
            --region=us-west1 \
            --instance-group=ig-c \
            --instance-group-zone=us-west1-c
        

Supprimer les adresses IP externes des VM de backend

Lors de la création des VM de backend, une adresse IP externe éphémère a été attribuée à chaque VM afin de pouvoir télécharger Apache via un script de démarrage. Étant donné que les VM de backend ne sont utilisées que par un équilibreur de charge interne, vous pouvez supprimer leurs adresses IP externes. La suppression des adresses IP externes empêche les VM de backend d'accéder directement à Internet.

Console

  1. Accédez à la page Instances de VM de Google Cloud Console.
    Accéder à la page Instances de VM
  2. Répétez les étapes ci-dessous pour chaque VM de backend.
  3. Cliquez sur le nom de la VM de backend (par exemple, vm-a1) pour afficher la page Informations sur l'instance de VM.
  4. Cliquez sur Modifier.
  5. Dans la section Interfaces réseau, cliquez sur le bouton Modifier.
  6. Dans la fenêtre pop-up Adresse IP externe, sélectionnez Aucune, puis cliquez sur Terminé.
  7. Cliquez sur Enregistrer.

gcloud

  1. Pour rechercher une instance dans une zone, par exemple si vous utilisez un groupe d'instances géré régional, exécutez la commande suivante pour chaque instance afin de déterminer sa zone. Remplacez [SERVER-VM] par le nom de la VM à rechercher.

        gcloud compute instances list --filter="name=[SERVER-VM]"
        
  2. Répétez l'étape ci-dessous pour chaque VM de backend. Remplacez [SERVER-VM] par le nom de la VM et [ZONE] par la zone de la VM.

        gcloud compute instances delete-access-config [SERVER-VM] \
            --zone=[ZONE] \
            --access-config-name=external-nat
        

api

Envoyez une requête POST à la méthode instances.deleteAccessConfig pour chaque VM de backend, en remplaçant vm-a1 par le nom de la VM et us-west1-a par la zone de la VM.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/v1-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None
    

Accepter le trafic sur plusieurs ports

Le composant qui contrôle le port pour le trafic entrant est la règle de transfert interne. Cette procédure vous montre comment remplacer la règle de transfert pour le port 80 par celle qui accepte le trafic sur les ports 80 et 443. Lorsque vous créez les VM de backend, le script de démarrage qui installe et configure Apache le configure également pour diffuser le trafic HTTPS sur le port 443. La règle de transfert doit être remplacée car Google Cloud n'accepte pas la mise à jour des règles de transfert.

gcloud

  1. Supprimez votre règle de transfert existante, fr-ilb.

        gcloud compute forwarding-rules delete fr-ilb \
            --region=us-west1
        
  2. Créez une règle de transfert de remplacement portant le même nom pour les ports 80 et 443. Les autres paramètres de cette règle, y compris l'adresse IP et le service de backend, sont identiques.

        gcloud compute forwarding-rules create fr-ilb \
            --region=us-west1 \
            --load-balancing-scheme=internal \
            --network=lb-network \
            --subnet=lb-subnet \
            --address=10.1.2.99 \
            --ip-protocol=TCP \
            --ports=80,443 \
            --backend-service=be-ilb \
            --backend-service-region=us-west1
        
  3. Connectez-vous à l'instance de VM cliente et testez les connexions HTTP et HTTPS.

    • Connectez-vous à la VM cliente :

          gcloud compute ssh vm-client --zone=us-west1-a
          
    • Testez la connectivité HTTP :

          curl http://10.1.2.99
          
    • Testez la connectivité HTTPS. L'option --insecure est obligatoire, car la configuration du serveur Apache dans l'exemple de configuration utilise des certificats autosignés.

          curl https://10.1.2.99 --insecure
          
    • Notez que les requêtes HTTP (sur le port 80) et HTTPS (sur le port 443) sont gérées par toutes les VM de backend.

Utiliser l'affinité de session

L'exemple de configuration crée un service de backend sans affinité de session.

Cette procédure vous montre comment mettre à jour le service de backend pour l'exemple d'équilibreur de charge TCP/UDP interne afin qu'il utilise l'affinité de session basée sur les adresses IP clientes.

L'équilibreur de charge dirige les requêtes d'un client vers la même VM de backend en fonction d'un hachage créé à partir de l'adresse IP du client et de l'adresse IP interne de l'équilibreur de charge (adresse IP interne d'une règle de transfert interne).

Console

  1. Accédez à la page "Équilibrage de charge" dans Google Cloud Console.
    Accéder à la page Équilibrage de charge
  2. Cliquez sur be-ilb (nom du service de backend que vous avez créé pour cet exemple), puis cliquez sur Modifier.
  3. Sur la page Modifier l'équilibreur de charge interne, cliquez sur Configuration du backend.
  4. Sélectionnez IP client dans le menu contextuel Affinité de session.
  5. Cliquez sur Mettre à jour.

gcloud

Utilisez la commande gcloud suivante pour mettre à jour le service de backend be-ilb, en spécifiant l'affinité de session de l'adresse IP cliente :

    gcloud compute backend-services update be-ilb \
        --session-affinity CLIENT_IP
    

api

Envoyez une requête PATCH à la méthode regionBackendServices/patch.

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb
    {
      "sessionAffinity": "CLIENT_IP"
    }
    

Pour plus d'informations sur l'utilisation de l'affinité de session pour influencer la répartition du trafic et pour obtenir une description de chaque option, consultez la page Répartition du trafic.

Créer une règle de transfert dans un autre sous-réseau

Cette procédure crée une deuxième adresse IP et une règle de transfert dans un sous-réseau différent pour démontrer que vous pouvez créer plusieurs règles de transfert pour un équilibreur de charge TCP/UDP interne. La région de la règle de transfert doit correspondre à celle du service de backend.

Sous réserve des règles de pare-feu, les clients de n'importe quel sous-réseau de la région peuvent contacter l'une ou l'autre des adresses IP de l'équilibreur de charge TCP/UDP interne.

  1. Créez un deuxième sous-réseau sur le réseau lb-network, dans la région us-west1 :

        gcloud compute networks subnets create second-subnet \
            --network=lb-network \
            --range=10.5.6.0/24 \
            --region=us-west1
        
  2. Créez une deuxième règle de transfert pour les ports 80 et 443. Les autres paramètres de cette règle, y compris l'adresse IP et le service de backend, sont identiques à ceux de la règle de transfert principale, fr-ilb.

        gcloud compute forwarding-rules create fr-ilb-2 \
            --region=us-west1 \
            --load-balancing-scheme=internal \
            --network=lb-network \
            --subnet=second-subnet \
            --address=10.5.6.99 \
            --ip-protocol=TCP \
            --ports=80,443 \
            --backend-service=be-ilb \
            --backend-service-region=us-west1
        
  3. Connectez-vous à l'instance de VM cliente et testez les connexions HTTP et HTTPS aux adresses IP.

    • Connectez-vous à la VM cliente :
        gcloud compute ssh vm-client --zone=us-west1-a
        
    • Testez la connectivité HTTP aux adresses IP :
        curl http://10.1.2.99
        curl http://10.5.6.99
        
    • Testez la connectivité HTTPS. L'option --insecure est obligatoire, car la configuration du serveur Apache dans l'exemple de configuration utilise des certificats autosignés.
        curl https://10.1.2.99 --insecure
        curl https://10.5.6.99 --insecure
        
    • Notez que les requêtes sont traitées par toutes les VM de backend, quels que soient le protocole (HTTP ou HTTPS) et l'adresse IP utilisés.

Étape suivante