Configurer un équilibreur de charge réseau proxy interne interrégional avec des backends de groupes d'instances de VM

Ce document fournit des instructions de configuration d'un équilibreur de charge réseau proxy interne interrégional pour vos services exécutés sur des VM Compute Engine.

Avant de commencer

Avant de suivre ce guide, familiarisez-vous avec les points suivants :

Autorisations

Pour suivre ce guide, vous devez savoir comment 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 de réseaux Compute
Ajouter et supprimer des règles de pare-feu Administrateur de sécurité de Compute
Créer des instances Administrateur d'instances Compute

Pour en savoir plus, consultez les guides suivants :

Vue d'ensemble de la configuration

Vous pouvez configurer l'équilibreur de charge comme indiqué dans le schéma suivant :

Déploiement haute disponibilité de l'équilibreur de charge réseau proxy interne interrégional
Déploiement haute disponibilité de l'équilibreur de charge réseau proxy interne interrégional (cliquez pour agrandir).

Comme le montre le schéma, cet exemple crée un équilibreur de charge réseau proxy interne interrégional dans un réseau VPC, avec un service de backend et deux groupes d'instances gérés dans les régions REGION_A et REGION_B.

Le schéma montre les éléments suivants :

  1. Un réseau VPC avec les sous-réseaux suivants :

    • Le sous-réseau SUBNET_A et un sous-réseau proxy réservé dans REGION_A.
    • Le sous-réseau SUBNET_B et un sous-réseau proxy réservé dans REGION_B.

    Vous devez créer des sous-réseaux proxy réservés dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge réseau proxy internes interrégionaux. Le sous-réseau proxy réservé de la région est partagé entre tous les équilibreurs de charge réseau proxy internes interrégionaux dans la région. Les adresses sources des paquets envoyés depuis l'équilibreur de charge vers les backends de votre service sont attribuées à partir du sous-réseau proxy réservé. Dans cet exemple, le sous-réseau proxy réservé de la région REGION_B possède une plage d'adresses IP principale de 10.129.0.0/23 et, pour REGION_A, une plage d'adresses IP principale de 10.130.0.0/23 utilisant la taille de sous-réseau recommandée.

  2. La configuration à haute disponibilité intègre des backends de groupes d'instances gérés pour les déploiements de VM Compute Engine dans les régions REGION_A et REGION_B. Si les backends d'une région sont indisponibles, le trafic bascule vers l'autre région.

  3. Un service de backend global surveillant l'utilisation et l'état des backends.

  4. Un proxy TCP cible global qui reçoit la requête de l'utilisateur et la transmet au service de backend.

  5. Les règles de transfert globales, qui disposent de l'adresse IP interne régionale de votre équilibreur de charge, pour transmettre chaque requête entrante au proxy cible.

    L'adresse IP interne associée à la règle de transfert peut provenir de n'importe quel sous-réseau du même réseau et de la même région que les backends. Veuillez noter les conditions suivantes :

    • L'adresse IP peut (mais ne doit pas nécessairement) provenir du même sous-réseau que les groupes d'instances backend.
    • L'adresse IP ne doit pas provenir d'un sous-réseau proxy réservé dont l'option --purpose est définie sur GLOBAL_MANAGED_PROXY.
    • Si vous souhaitez utiliser la même adresse IP interne avec plusieurs règles de transfert, définissez l'option d'adresse IP --purpose sur SHARED_LOADBALANCER_VIP.

Configurer le réseau et les sous-réseaux

Au sein du réseau VPC, configurez un sous-réseau dans chaque région où vos backends sont configurés. En outre, configurez un objet proxy-only-subnet dans chaque région où vous souhaitez configurer l'équilibreur de charge.

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

  • Réseau : le réseau est un réseau VPC en mode personnalisé nommé NETWORK.

  • Sous-réseaux pour les backends.

    • Un sous-réseau nommé SUBNET_A dans la région REGION_A utilise 10.1.2.0/24 pour sa plage d'adresses IP principale.
    • Un sous-réseau nommé SUBNET_B dans la région REGION_B utilise 10.1.3.0/24 pour sa plage d'adresses IP principale.
  • Sous-réseaux pour les proxys.

    • Un sous-réseau nommé PROXY_SN_A dans la région REGION_A utilise 10.129.0.0/23 pour sa plage d'adresses IP principale.
    • Un sous-réseau nommé PROXY_SN_B dans la région REGION_B utilise 10.130.0.0/23 pour sa plage d'adresses IP principale.

Les équilibreurs de charge d'application internes interrégionaux sont accessibles depuis n'importe quelle région du VPC. Ainsi, les clients de n'importe quelle région peuvent accéder aux backends de votre équilibreur de charge à l'échelle mondiale.

Configurer les sous-réseaux backend

Console

  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 un Nom pour le réseau.

  4. Dans la section Sous-réseaux, définissez le Mode de création du sous-réseau sur Personnalisé.

  5. Créez un sous-réseau pour les backends de l'équilibreur de charge. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

    • Renseignez un Nom pour le sous-réseau.
    • Sélectionnez une région : REGION_A.
    • Saisissez une plage d'adresses IP : 10.1.2.0/24
  6. Cliquez sur OK.

  7. Cliquez sur Ajouter un sous-réseau.

  8. Créez un sous-réseau pour les backends de l'équilibreur de charge. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

    • Renseignez un Nom pour le sous-réseau.
    • Sélectionnez une région : REGION_B.
    • Saisissez une plage d'adresses IP : 10.1.3.0/24
  9. Cliquez sur OK.

  10. Cliquez sur Créer.

gcloud

  1. Créez le réseau VPC personnalisé à l'aide de la commande gcloud compute networks create :

    gcloud compute networks create NETWORK \
        --subnet-mode=custom
    
  2. Créez un sous-réseau dans le réseau NETWORK de la région REGION_A à l'aide de la commande gcloud compute networks subnets create :

    gcloud compute networks subnets create SUBNET_A \
        --network=NETWORK \
        --range=10.1.2.0/24 \
        --region=REGION_A
    
  3. Créez un sous-réseau dans le réseau NETWORK de la région REGION_B à l'aide de la commande gcloud compute networks subnets create :

    gcloud compute networks subnets create SUBNET_B \
        --network=NETWORK \
        --range=10.1.3.0/24 \
        --region=REGION_B
    

Terraform

Pour créer le réseau VPC, utilisez la ressource google_compute_network.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

Pour créer le sous-réseau VPC dans le réseau lb-network-crs-reg, utilisez la ressource google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}
resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

API

Envoyez une requête POST à la méthode networks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configurer le sous-réseau proxy réservé

Un sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google Cloud pour exécuter des proxys Envoy en votre nom. Les proxys interrompent les connexions du client et créent de nouvelles connexions vers les backends.

Ce sous-réseau proxy réservé est utilisé par tous les équilibreurs de charge régionaux basés sur Envoy dans la même région que le réseau VPC. Il ne peut y avoir qu'un seul sous-réseau proxy réservé actif pour une utilisation donnée, par région et par réseau.

Console

Si vous utilisez la console Google Cloud, vous pouvez créer le sous-réseau proxy réservé ultérieurement sur la page Équilibrage de charge.

Si vous souhaitez créer le sous-réseau proxy réservé maintenant, procédez comme suit :

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

    Accéder aux réseaux VPC

  2. Cliquez sur le nom du réseau VPC.
  3. Dans l'onglet Sous-réseau, cliquez sur Ajouter un sous-réseau.
  4. Saisissez un Nom pour le sous-réseau proxy réservé.
  5. Sélectionnez une région : REGION_A.
  6. Dans la liste Objectif, sélectionnez Proxy géré interrégional.
  7. Dans le champ Plage d'adresses IP, saisissez 10.129.0.0/23.
  8. Cliquez sur Ajouter.

Créez le sous-réseau proxy réservé dans REGION_B.

  1. Dans l'onglet Sous-réseau, cliquez sur Ajouter un sous-réseau.
  2. Saisissez un Nom pour le sous-réseau proxy réservé.
  3. Sélectionnez une région : REGION_B.
  4. Dans la liste Objectif, sélectionnez Proxy géré interrégional.
  5. Dans le champ Plage d'adresses IP, saisissez 10.130.0.0/23.
  6. Cliquez sur Ajouter.

gcloud

Créez le sous-réseau proxy réservé à l'aide de la commande gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23
    

Terraform

Pour créer le sous-réseau proxy réservé VPC dans le réseau lb-network-crs-reg, utilisez la ressource google_compute_subnetwork.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}
resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

Créez les sous-réseaux proxy réservés avec la méthode subnetworks.insert, en remplaçant PROJECT_ID par votre ID de projet.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

Configurer des règles de pare-feu

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

  • fw-ilb-to-backends : 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 sources plus restrictive pour cette règle. Par exemple, vous pouvez spécifier uniquement les plages d'adresses IP du système à partir duquel vous souhaitez 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-healthcheck : règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise tout le trafic TCP issu des systèmes de vérification d'état Google Cloud (dans 130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.

  • fw-backends : règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise le trafic TCP sur les ports 80, 443 et 8080 à partir des proxys gérés de l'équilibreur de charge réseau proxy interne. Cet exemple utilise le tag cible load-balanced-backend pour identifier les VM auxquelles la règle de pare-feu s'applique.

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.

Les tags cibles définissent les instances backend. Sans les tags cibles, les règles de pare-feu s'appliquent à toutes les instances backend du réseau VPC. Lorsque vous créez les VM de backend, veillez à inclure les tags cibles spécifiés, comme décrit dans la section Créer un groupe d'instances géré.

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 de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes :

    • Nom : fw-ilb-to-backends
    • Réseau : NETWORK
    • 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 :
      • Choisissez Protocoles et ports spécifiés.
      • Cochez la case TCP, puis saisissez 22 pour le numéro de port.
  3. Cliquez sur Créer.

  4. Cliquez une deuxiè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-healthcheck
    • Réseau : NETWORK
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : Tags cibles spécifiés
    • Tags cibles : load-balanced-backend
    • Filtre source : Plages IPv4
    • Plages IPv4 sources : 130.211.0.0/22 et 35.191.0.0/16
    • Protocoles et ports :

      • Choisissez Protocoles et ports spécifiés.
      • Cochez la case TCP, puis saisissez 80 pour le numéro de port.

      Nous vous recommandons de limiter cette règle aux seuls protocoles et ports qui correspondent à ceux utilisés par votre vérification de l'état. Si vous utilisez tcp:80 pour le protocole et le port, Google Cloud peut contacter vos VM via HTTP sur le port 80, mais pas via HTTPS sur le port 443.

  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 serveurs proxy de l'équilibreur de charge à se connecter aux backends :

    • Nom : fw-backends
    • Réseau : NETWORK
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : Tags cibles spécifiés
    • Tags cibles : load-balanced-backend
    • Filtre source : Plages IPv4
    • Plages IPv4 sources : 10.129.0.0/23 et 10.130.0.0/23
    • Protocoles et ports :
      • Choisissez Protocoles et ports spécifiés.
      • Cochez la case TCP, puis saisissez 80, 443, 8080 pour les numéros de port.
  7. Cliquez sur Créer.

gcloud

  1. Créez la règle de pare-feu fw-ilb-to-backends 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-ilb-to-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Créez la règle fw-healthcheck pour autoriser les vérifications d'état Google Cloud. Cet exemple autorise tout le trafic TCP provenant des tests de vérification d'état. Toutefois, vous pouvez configurer un ensemble de ports plus restreint en fonction de vos besoins.

    gcloud compute firewall-rules create fw-healthcheck \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. Créez la règle fw-backends pour autoriser les proxys de l'équilibreur de charge réseau proxy interne à se connecter à vos backends. Définissez source-ranges sur les plages allouées de votre sous-réseau proxy réservé, par exemple 10.129.0.0/23 et 10.130.0.0/23.

    gcloud compute firewall-rules create fw-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=SOURCE_RANGE \
        --target-tags=load-balanced-backend \
        --rules=tcp:80,tcp:443,tcp:8080
    

API

Créez la règle de pare-feu fw-ilb-to-backends en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Créez la règle de pare-feu fw-healthcheck en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Créez la règle de pare-feu fw-backends pour autoriser le trafic TCP dans le sous-réseau proxy pour la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Créer un groupe d'instances géré

Cette section explique comment créer un modèle et un groupe d'instances géré. Le groupe d'instances géré fournit des instances de VM exécutant les serveurs de backend d'un exemple d'équilibreur de charge réseau proxy interne interrégional. Pour votre groupe d'instances, vous pouvez définir un service HTTP et mapper un nom de port sur le port correspondant. Le service de backend de l'équilibreur de charge transfère le trafic vers les ports nommés. Le trafic des clients fait l'objet d'un équilibrage de charge par rapport aux serveurs de backend. À des fins de démonstration, les backends diffusent leurs propres noms d'hôte.

Console

  1. Dans la console Google Cloud, accédez à la page Modèles d'instances.

    Accéder à la page Modèles d'instances

    1. Cliquez sur Create instance template (Créer un modèle d'instance).
    2. Dans le champ Nom, saisissez gil4-backendeast1-template.
    3. Assurez-vous que le disque de démarrage est défini sur une image Debian, telle que Debian GNU/Linux 10 (Buster). Ces instructions utilisent des commandes uniquement disponibles dans Debian, comme apt-get.
    4. Cliquez sur Options avancées.
    5. Cliquez sur Mise en réseau et configurez les champs suivants :
      1. Pour Tags réseau, saisissez allow-ssh et load-balanced-backend.
      2. Pour Interfaces réseau, sélectionnez l'option suivante :
        • Réseau : NETWORK
        • Sous-réseau : SUBNET_B
    6. Cliquez sur Gestion. Saisissez le script suivant dans le champ Script de démarrage.

      #! /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
      
    7. Cliquez sur Créer.

    8. Cliquez sur Créer un modèle d'instance.

    9. Dans le champ Nom, saisissez gil4-backendwest1-template.

    10. Assurez-vous que le disque de démarrage est défini sur une image Debian, telle que Debian GNU/Linux 10 (Buster). Ces instructions utilisent des commandes uniquement disponibles dans Debian, comme apt-get.

    11. Cliquez sur Options avancées.

    12. Cliquez sur Mise en réseau et configurez les champs suivants :

      1. Pour Tags réseau, saisissez allow-ssh et load-balanced-backend.
      2. Pour Interfaces réseau, sélectionnez l'option suivante :
        • Réseau : NETWORK
        • Sous-réseau : SUBNET_A
    13. Cliquez sur Gestion. Saisissez le script suivant dans le champ Script de démarrage.

      #! /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
      
    14. Cliquez sur Créer.

  2. Dans la console Google Cloud, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

    1. Cliquez sur Créer un groupe d'instances.
    2. Sélectionnez Nouveau groupe d'instances géré (sans état). Pour plus d'informations, consultez la page Groupes d'instances gérés (MIG) sans état ou avec état.
    3. Dans le champ Nom, saisissez gl7-ilb-mig-a.
    4. Pour Emplacement, sélectionnez Zone unique.
    5. Pour Région, sélectionnez REGION_A.
    6. Pour Zone, sélectionnez ZONE_A.
    7. Pour Modèle d'instance, sélectionnez gil4-backendwest1-template.
    8. Spécifiez le nombre d'instances que vous souhaitez créer au sein du groupe.

      Pour cet exemple, spécifiez les options suivantes sous Autoscaling :

      • Dans le champ Mode autoscaling, sélectionnez Off:do not autoscale.
      • Dans le champ Nombre maximal d'instances, saisissez 2.

      Si vous le souhaitez, dans la section Autoscaling de l'interface utilisateur, vous pouvez configurer le groupe d'instances de manière à ajouter ou supprimer automatiquement des instances en fonction de l'utilisation du processeur.

    9. Cliquez sur Créer.

    10. Cliquez sur Créer un groupe d'instances.

    11. Sélectionnez Nouveau groupe d'instances géré (sans état). Pour plus d'informations, consultez la page Groupes d'instances gérés (MIG) sans état ou avec état.

    12. Dans le champ Nom, saisissez gl7-ilb-mig-b.

    13. Pour Emplacement, sélectionnez Zone unique.

    14. Pour Région, sélectionnez REGION_B.

    15. Pour Zone, sélectionnez ZONE_B.

    16. Pour Modèle d'instance, sélectionnez gil4-backendeast1-template.

    17. Spécifiez le nombre d'instances que vous souhaitez créer au sein du groupe.

      Pour cet exemple, spécifiez les options suivantes sous Autoscaling :

      • Dans le champ Mode autoscaling, sélectionnez Off:do not autoscale.
      • Dans le champ Nombre maximal d'instances, saisissez 2.

      Si vous le souhaitez, dans la section Autoscaling de l'interface utilisateur, vous pouvez configurer le groupe d'instances de manière à ajouter ou supprimer automatiquement des instances en fonction de l'utilisation du processeur.

    18. Cliquez sur Create (Créer).

gcloud

Les instructions gcloud CLI de ce guide supposent que vous utilisez Cloud Shell ou un autre environnement avec bash installé.

  1. Créez un modèle d'instance de VM avec le serveur HTTP à l'aide de la commande gcloud compute instance-templates create.

    gcloud compute instance-templates create gil4-backendwest1-template \
       --region=REGION_A \
       --network=NETWORK \
       --subnet=SUBNET_A \
       --tags=allow-ssh,load-balanced-backend \
       --image-family=debian-10 \
       --image-project=debian-cloud \
       --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'
    
    gcloud compute instance-templates create gil4-backendeast1-template \
        --region=REGION_B \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --tags=allow-ssh,load-balanced-backend \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --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é dans la zone à l'aide de la commande gcloud compute instance-groups managed create.

    gcloud compute instance-groups managed create gl7-ilb-mig-a \
        --zone=ZONE_A \
        --size=2 \
        --template=gil4-backendwest1-template
    
    gcloud compute instance-groups managed create gl7-ilb-mig-b \
        --zone=ZONE_B \
        --size=2 \
        --template=gil4-backendeast1-template
    

API

Créez le modèle d'instance avec la méthode instanceTemplates.insert, en remplaçant PROJECT_ID par votre ID de projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil4-backendwest1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"           
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-10"
         },
         "autoDelete":true
       }
     ]
  }
}

Créez un groupe d'instances géré dans chaque zone à l'aide de la méthode instanceGroupManagers.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl7-ilb-mig-a",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil4-backendeast1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"           
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-10"
         },
         "autoDelete":true
       }
     ]
  }
}

Créez un groupe d'instances géré dans chaque zone à l'aide de la méthode instanceGroupManagers.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl7-ilb-mig-b",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}

Configurer l'équilibreur de charge

Cet exemple vous explique comment créer les ressources suivantes pour l'équilibreur de charge réseau proxy interrégional:

  • Une vérification d'état TCP globale.
  • Un service de backend global avec les mêmes MIG que le backend.
  • Un proxy cible mondial.
  • Deux règles de transfert globales avec des adresses IP régionales. Pour l'adresse IP de la règle de transfert, utilisez la plage d'adresses IP SUBNET_A ou SUBNET_B. Si vous essayez d'utiliser le sous-réseau proxy réservé, la création de la règle de transfert échoue.

Disponibilité du proxy

Parfois, les régions Google Cloud ne disposent pas d'une capacité de proxy suffisante pour un nouvel équilibreur de charge. Dans ce cas, la console Google Cloud fournit un message d'avertissement de disponibilité du proxy lors de la création de votre équilibreur de charge. Pour résoudre ce problème, vous pouvez effectuer l'une des opérations suivantes :

  • Sélectionnez une autre région pour votre équilibreur de charge. Cette option peut être pratique si vous avez des backends dans une autre région.
  • Sélectionnez un réseau VPC comportant déjà un sous-réseau proxy réservé alloué.
  • Attendez que le problème de capacité soit résolu.

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 proxy, puis cliquez sur Suivant.
  5. Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
  6. Pour Déploiement interrégional ou régional, sélectionnez Recommandé pour les charges de travail interrégionales, puis cliquez sur Suivant.
  7. Cliquez sur Configurer.

Configuration de base

  1. Saisissez un Nom pour l'équilibreur de charge.
  2. Pour Réseau, sélectionnez NETWORK.

Configurer l'interface avec deux règles de transfert

  1. Cliquez sur Configuration de l'interface.
    1. Saisissez un Nom pour la règle de transfert.
    2. Dans la liste Région du sous-réseau, sélectionnez REGION_A.

      Réserver un sous-réseau proxy réservé

    3. Dans la liste Sous-réseau, sélectionnez SUBNET_A.
    4. Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.
      • Saisissez un Nom pour l'adresse IP statique.
      • Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
      • Dans le champ Adresse IP personnalisée, saisissez 10.1.2.99.
      • Sélectionnez Réserver.
  2. Cliquez sur OK.
  3. Pour ajouter la deuxième règle de transfert, cliquez sur Ajouter une adresse IP et un port d'interface.
    1. Saisissez un Nom pour la règle de transfert.
    2. Dans la liste Région du sous-réseau, sélectionnez REGION_B.

      Réserver un sous-réseau proxy réservé

    3. Dans la liste Sous-réseau, sélectionnez SUBNET_B.
    4. Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.
      • Saisissez un Nom pour l'adresse IP statique.
      • Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
      • Dans le champ Adresse IP personnalisée, saisissez 10.1.3.99.
      • Sélectionnez Réserver.
  4. Cliquez sur OK.
Configurer le service de backend
  1. Cliquez sur Configuration du backend.
  2. Dans la liste Créer ou sélectionner des services de backend, cliquez sur Créer un service de backend.
  3. Saisissez un Nom pour le service de backend.
  4. Dans le champ Protocole, sélectionnez TCP.
  5. Pour le Port nommé, saisissez http.
  6. Dans la liste Type de backend, sélectionnez Groupe d'instances.
  7. Dans la section Nouveau backend :
    • Dans la liste Groupe d'instances, sélectionnez gl7-ilb-mig-a dans REGION_A.
    • Définissez le paramètre Numéros de ports sur 80.
    • Cliquez sur OK.
    • Pour ajouter un autre backend, cliquez sur Ajouter un backend.
    • Dans la liste Groupe d'instances, sélectionnez gl7-ilb-mig-b dans REGION_B.
    • Définissez le paramètre Numéros de ports sur 80.
    • Cliquez sur OK.
  8. Dans la section Vérification d'état, cliquez sur Créer une vérification d'état.
    • Dans le champ Nom, saisissez global-http-health-check.
    • Définissez le paramètre Protocole sur HTTP.
    • Définissez le paramètre Port sur 80.
    • Cliquez sur Enregistrer.

Vérifier la configuration

  1. Cliquez sur Vérifier et finaliser.
  2. Vérifiez les paramètres de configuration de votre équilibreur de charge.
  3. Cliquez sur Créer.

gcloud

  1. Définissez la vérification d'état TCP à l'aide de la commande gcloud compute health-checks create tcp.

    gcloud compute health-checks create tcp global-health-check \
       --use-serving-port \
       --global
    
  2. Définissez le service de backend avec la commande gcloud compute backend-services create.

    gcloud compute backend-services create gl4-gilb-backend-service \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=TCP \
      --enable-logging \
      --logging-sample-rate=1.0 \
      --health-checks=global-health-check \
      --global-health-checks \
      --global
    
  3. Ajoutez des backends au service de backend à l'aide de la commande gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
      --balancing-mode=CONNECTION \
      --max-connections=50 \
      --instance-group=gl4-ilb-migb \
      --instance-group-zone=ZONE_A \
      --global
    
    gcloud compute backend-services add-backend gl4-gilb-backend-service \
      --balancing-mode=CONNECTION \
      --max-connections=50 \
      --instance-group=gl4-ilb-migb \
      --instance-group-zone=ZONE_B \
      --global
    
  4. Créez le proxy cible.

    Créez le proxy cible à l'aide de la commande gcloud compute target-tcp-proxies create.

    gcloud compute target-tcp-proxies create gilb-tcp-proxy \
      --backend-service=gl4-gilb-backend-service \
      --global
    
  5. Créez deux règles de transfert, l'une avec une adresse IP virtuelle (10.1.2.99) dans REGION_B et l'autre avec une adresse IP virtuelle (10.1.3.99) dans REGION_A. Pour plus d'informations, consultez la page Réserver une adresse IPv4 interne statique.

    Pour les réseaux personnalisés, vous devez faire référence au sous-réseau dans la règle de transfert. Notez qu'il s'agit du sous-réseau de VM et non du sous-réseau proxy.

    Utilisez la commande gcloud compute forwarding-rules create avec les options appropriées.

    gcloud compute forwarding-rules create gil4forwarding-rule-a \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --subnet-region=REGION_A \
      --address=10.1.2.99 \
      --ports=80 \
      --target-tcp-proxy=gilb-tcp-proxy \
      --global
    
    gcloud compute forwarding-rules create gil4forwarding-rule-b \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_B \
      --subnet-region=REGION_B \
      --address=10.1.3.99 \
      --ports=80 \
      --target-tcp-proxy=gilb-tcp-proxy \
      --global
    

API

Créez la vérification de l'état en envoyant une requête POST à la méthode healthChecks.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
"name": "global-health-check",
"type": "TCP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Créez le service de backend global en envoyant une requête POST à la méthode backendServices.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gl4-gilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Créez le proxy TCP cible en envoyant une requête POST à la méthode targetTcpProxies.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetTcpProxy

{
"name": "l4-ilb-proxy",
}

Créez la règle de transfert en envoyant une requête POST à la méthode forwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Créez la règle de transfert en envoyant une requête POST à la méthode globalForwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Tester l'équilibreur de charge

Créer une instance de VM pour tester la connectivité

  1. Créez une VM cliente dans les régions REGION_B et REGION_A :

    gcloud compute instances create l4-ilb-client-a \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_A \
        --zone=ZONE_A \
        --tags=allow-ssh
    
    gcloud compute instances create l4-ilb-client-b \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --zone=ZONE_B \
        --tags=allow-ssh
    
  2. Utilisez SSH pour vous connecter à chaque instance cliente.

    gcloud compute ssh l4-ilb-client-a --zone=ZONE_A
    
    gcloud compute ssh l4-ilb-client-b --zone=ZONE_B
    
  3. Vérifiez que l'adresse IP diffuse son nom d'hôte.

    • Vérifiez que la VM cliente peut atteindre les deux adresses IP. La commande doit réussir et renvoyer le nom de la VM de backend qui a diffusé la requête :

      curl 10.1.2.99
      
      curl 10.1.3.99
      

Tester le basculement

  1. Vérifiez le basculement vers les backends de la région REGION_A lorsque les backends de REGION_B sont non opérationnels ou inaccessibles. Pour simuler un basculement, supprimez tous les backends de REGION_B :

    gcloud compute backend-services remove-backend gl4-gilb-backend-service \
      --instance-group=gl4-ilb-migb \
      --instance-group-zone=ZONE_B \
      --global
    
  2. Connectez-vous à une VM cliente dans REGION_B en utilisant SSH.

    gcloud compute ssh l4-ilb-client-b \
       --zone=ZONE_B
    
  3. Envoyez des requêtes à l'adresse IP faisant l'objet d'un équilibrage de charge dans la région REGION_B. Le résultat de la commande affiche les réponses des VM de backend dans REGION_A :

    {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo "***"
    echo "*** Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
    }
    

Options de configuration supplémentaires

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

Protocole de PROXY pour la conservation des informations de connexion client

L'équilibreur de charge réseau proxy interne met fin aux connexions TCP du client et crée des connexions vers les instances de VM. Par défaut, l'adresse IP et les informations de port d'origine du client ne sont pas conservées.

Pour conserver et envoyer les informations de connexion d'origine à vos instances, activez le protocole de PROXY (version 1). Dans le cadre de la requête, ce protocole envoie à l'instance un en-tête supplémentaire contenant les éléments d'origine : l'adresse IP source, l'adresse IP de destination, ainsi que les numéros de ports.

Assurez-vous que les instances backend de l'équilibreur de charge réseau proxy interne exécutent des serveurs HTTP ou HTTPS compatibles avec les en-têtes de protocole de PROXY. Si les serveurs HTTP ou HTTPS ne sont pas configurés pour accepter les en-têtes de protocole de PROXY, les instances backend renvoient des réponses vides. Par exemple, le protocole de PROXY ne fonctionne pas avec le logiciel Apache HTTP Server. Vous pouvez utiliser un autre logiciel serveur Web, tel que Nginx.

Si vous définissez le protocole de PROXY pour le trafic utilisateur, vous devez également le définir pour vos vérifications d'état. Si vous effectuez la vérification d'état et la diffusion de contenu sur le même port, définissez l'en-tête --proxy-header de la vérification d'état pour qu'il corresponde aux paramètres de votre équilibreur de charge.

L'en-tête de protocole de PROXY est généralement constitué d'une seule ligne de texte parfaitement lisible, au format suivant :

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

Voici un exemple de protocole de PROXY:

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

Dans l'exemple précédent, l'adresse IP du client est 192.0.2.1, l'adresse IP d'équilibrage de charge est 198.51.100.1, le port client est 15221 et le port de destination est 110.

Lorsque l'adresse IP du client n'est pas connue, l'équilibreur de charge génère un en-tête de protocole de PROXY au format suivant :

PROXY UNKNOWN\r\n

Mettre à jour l'en-tête du protocole de PROXY pour le proxy TCP cible

L'exemple de configuration d'équilibreur de charge de cette page vous montre comment activer l'en-tête du protocole de PROXY lors de la création de l'équilibreur de charge réseau proxy interne. Pour modifier l'en-tête du protocole de PROXY pour un proxy TCP cible existant, suivez les instructions suivantes.

Console

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

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

  2. Cliquez sur Modifier à côté du nom de votre équilibreur de charge.

  3. Cliquez sur Configuration de l'interface.

  4. Définissez la valeur du champ Protocole de proxy sur On (Activé).

  5. Cliquez sur Mettre à jour pour enregistrer vos modifications.

gcloud

Dans la commande suivante, modifiez le champ --proxy-header et définissez-le sur NONE ou PROXY_V1 en fonction de vos besoins.

gcloud compute target-ssl-proxies update int-tcp-target-proxy \
    --proxy-header=[NONE | PROXY_V1]

Utiliser la même adresse IP entre plusieurs règles de transfert internes

Pour que plusieurs règles de transfert internes partagent la même adresse IP interne, vous devez réserver l'adresse IP et définir son option --purpose sur SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

Activer l'affinité de session

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

Ces procédures vous montrent comment mettre à jour un service de backend pour l'exemple d'équilibreur de charge afin que ce service utilise l'affinité basée sur les adresses IP client ou l'affinité basée sur les cookies générés.

Lorsque l'affinité basée sur les adresses IP client est activée, l'équilibreur de charge dirige les requêtes d'un client particulier toujours vers la même VM de backend, grâce à un hachage créé à partir de l'adresse IP du client et de l'adresse IP de l'équilibreur de charge (l'adresse IP interne d'une règle de transfert interne).

Console

Pour activer l'affinité de session basée sur les adresses IP client, procédez comme suit :

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.
    Accéder à la page "Équilibrage de charge"
  2. Cliquez sur Backends.
  3. Cliquez sur le nom du service de backend que vous avez créé pour cet exemple, puis sur Modifier.
  4. Sur la page Détails du service backend, cliquez sur Configuration avancée.
  5. Sous Affinité de session, sélectionnez IP client dans le menu.
  6. Cliquez sur Mettre à jour.

gcloud

Utilisez la commande gcloud suivante pour mettre à jour le service de backend BACKEND_SERVICE, en spécifiant l'affinité de session basée sur les adresses IP client :

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --session-affinity=CLIENT_IP

Activer le drainage de connexion

Vous pouvez activer le drainage de connexion sur les services de backend afin de garantir à vos utilisateurs un temps d'interruption minimal lorsqu'une instance assurant la diffusion du trafic est arrêtée, supprimée manuellement ou supprimée par un autoscaler. Pour en savoir plus sur le drainage de connexion, consultez la documentation Activer le drainage de connexion.

Étapes suivantes