Ce guide s'appuie sur un exemple pour expliquer les principes fondamentaux de l'équilibrage de charge TCP/UDP interne de Google Cloud. Avant de le suivre, familiarisez-vous avec les points suivants :
- Concepts d'équilibrage de charge TCP/UDP interne
- Présentation des règles de pare-feu
- Concepts de la vérification de l'état
Pour obtenir des conseils détaillés sur cette tâche directement dans la console Google Cloud, cliquez sur Visite guidée :
Autorisations
Pour suivre ce guide, vous devez créer des instances et modifier un réseau dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer de tous les rôles IAM Compute Engine suivants :
Tâche | Rôle requis |
---|---|
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge | Administrateur réseau |
Ajouter et supprimer des règles de pare-feu | Administrateur de sécurité |
Créer des instances | Administrateur d'instances Compute |
Pour en savoir plus, consultez les guides suivants :
- Access control (Contrôle des accès)
- Conditions IAM
Configurer l'équilibreur de charge avec des sous-réseaux à pile unique
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 :
- Exemple utilisant un réseau VPC en mode personnalisé nommé
lb-network
. - Un sous-réseau à pile unique (
stack-type
défini surIPv4
) qui est requis pour le trafic IPv4. Lorsque vous créez un sous-réseau à pile unique sur un réseau VPC en mode personnalisé, vous choisissez une plage de sous-réseau IPv4 pour le sous-réseau. - Des règles de pare-feu autorisant les connexions entrantes aux VM de backend.
- Le groupe d'instances backend, situé dans la région et le sous-réseau suivants pour cet exemple :
- Région :
us-west1
- Sous-réseau:
lb-subnet
, avec plage d'adresses IPv4 principale10.1.2.0/24
.
- Région :
- Quatre VM de backend : deux VM dans un groupe d'instances non géré dans la zone
us-west1-a
et deux VM dans un groupe d'instances non géré dans la zoneus-west1-c
. Pour démontrer l'accès mondial, cet exemple crée une deuxième VM cliente de test dans une région et un sous-réseau différents :- Région :
europe-west1
- Sous-réseau :
europe-subnet
, avec plage d'adresses IP principale10.3.4.0/24
- Région :
- VM cliente pour tester les connexions
- Les composants de l'é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 zonaux. - 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 :
Configurer un réseau, une région et un sous-réseau
Pour créer les exemples de réseau et de sous-réseaux, procédez comme suit :
Console
Dans Google Cloud Console, accédez à la page Réseaux VPC.
Cliquez sur Créer un réseau VPC.
Dans le champ Nom, saisissez
lb-network
.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
- Type de pile IP : IPv4 (pile unique)
- Plage d'adresses IP :
10.1.2.0/24
- Nom :
- Cliquez sur OK.
- Cliquez sur Ajouter un sous-réseau et saisissez les informations suivantes :
- Nom :
europe-subnet
- Région :
europe-west1
- Type de pile IP : IPv4 (pile unique)
- Plage d'adresses IP :
10.3.4.0/24
- Nom :
- Cliquez sur OK.
Cliquez sur Create (Créer).
gcloud
Créez le réseau VPC personnalisé :
gcloud compute networks create lb-network --subnet-mode=custom
- Au sein du réseau
lb-network
, créez un sous-réseau pour les backends dans la régionus-west1
et un autre sous-réseau pour tester l'accès mondial dans la régioneurope-west1
:
gcloud compute networks subnets create lb-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-west1
gcloud compute networks subnets create europe-subnet \ --network=lb-network \ --range=10.3.4.0/24 \ --region=europe-west1
- Au sein du réseau
API
Envoyez une requête POST
à la méthode networks.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/global/networks
{
"routingConfig": {
"routingMode": "REGIONAL"
},
"name": "lb-network",
"autoCreateSubnetworks": false
}
Envoyez deux requêtes POST
à la méthode subnetworks.insert
.
POST https://compute.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
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/europe-west1/subnetworks
{
"name": "europe-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
"ipCidrRange": "10.3.4.0/24",
"privateIpGoogleAccess": false
}
Configurer des règles de pare-feu
Cet exemple utilise les règles de pare-feu suivantes :
fw-allow-lb-access
: règle d'entrée, applicable à toutes les cibles du réseau VPC, autorisant le trafic provenant de sources dans les plages10.1.2.0/24
et10.3.4.0/24
. Cette règle autorise le trafic entrant de n'importe quel client situé dans l'un des deux sous-réseaux. Elle vous permet ultérieurement de configurer et tester l'accès mondial.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 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 cibleallow-ssh
pour identifier les VM auxquelles la règle 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
et35.191.0.0/16
). Cet exemple utilise le tag cibleallow-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
- Dans Google Cloud Console, accédez à la page Pare-feu.
Accéder à la page "Pare-feu" - 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-access
- 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 : Plages IPv4
- Plages IPv4 sources :
10.1.2.0/24
et10.3.4.0/24
- Protocoles et ports : tout autoriser
- Nom :
- Cliquez sur Create (Créer).
- 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 : Plages IPv4
- Plages IPv4 sources :
0.0.0.0/0
- Protocoles et ports : choisissez Protocoles et ports spécifiés, puis saisissez
tcp:22
.
- Nom :
- Cliquez sur Create (Créer).
- 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 : Plages IPv4
- Plages IPv4 sources :
130.211.0.0/22
et35.191.0.0/16
- Protocoles et ports : tout autoriser
- Nom :
- Cliquez sur Create (Créer).
gcloud
Créez la règle de pare-feu
fw-allow-lb-access
pour autoriser la communication depuis le sous-réseau :gcloud compute firewall-rules create fw-allow-lb-access \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.1.2.0/24,10.3.4.0/24 \ --rules=tcp,udp,icmp
Créez la règle de pare-feu
fw-allow-ssh
pour autoriser la connectivité SSH aux VM avec le tag réseauallow-ssh
. Lorsque vous omettezsource-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
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-access
en envoyant une requête POST
à la méthode firewalls.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/global/firewalls
{
"name": "fw-allow-lb-access",
"network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
"priority": 1000,
"sourceRanges": [
"10.1.2.0/24", "10.3.4.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://compute.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://compute.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 zones 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é.
Pour utiliser cet exemple et les options de configuration supplémentaires, chacune des quatre VM exécute un serveur Web Apache qui écoute sur les ports TCP suivants : 80, 8008, 8080, 8088, 443 et 8443.
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 et peuvent se connecter 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 10.
Console
Créer des VM de backend
- Dans Google Cloud Console, accédez à la page Instances de VM.
Accéder à la page "Instances de VM" - Répétez les étapes 3 à 8 pour chaque 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
- Nom :
- Cliquez sur Créer une instance.
- Définissez le Nom comme indiqué à l'étape 2.
- Dans le champ Région, choisissez
us-west1
, puis sélectionnez une zone comme indiqué à l'étape 2. - Dans la section Disque de démarrage, assurez-vous que les options sélectionnées sont Debian pour le système d'exploitation et 10 (Buster) pour la version. Si nécessaire, cliquez sur Sélectionner pour modifier l'image.
- Cliquez sur Options avancées.
- Cliquez sur Mise en réseau et configurez les champs suivants :
- Pour Tags réseau, saisissez
allow-ssh
etallow-health-check
. - Pour Interfaces réseau, sélectionnez l'option suivante :
- Réseau :
lb-network
- Sous-réseau :
lb-subnet
- Type de pile IP : IPv4 (pile unique)
- Adresse IP interne principale : éphémère (automatique)
- Adresse IP externe : Éphémère
- Réseau :
- Pour Tags réseau, saisissez
Cliquez sur Gestion. Saisissez le script suivant dans le champ Script de démarrage. Le contenu du script est identique pour les quatre VM :
#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 :8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts=":443 :8443" vm_hostname="$(curl -H "Metadata-Flavor:Google"
http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" |
tee /var/www/html/index.html echo "Page served from: $vm_hostname" |
tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|default:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completedCliquez sur Create (Créer).
Créer des groupes d'instances
- Dans Google Cloud Console, accédez à la page Groupes d'instances.
Accéder à la page "Groupes d'instances" - 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
etvm-a2
- Groupe d'instances :
ig-c
, zone :us-west1-c
, VM :vm-c1
etvm-c2
- Groupe d'instances :
- Cliquez sur Créer un groupe d'instances.
- Cliquez sur Nouveau groupe d'instances non géré.
- Définissez le Nom comme indiqué à l'étape 2.
- Dans la section Emplacement, sélectionnez
us-west1
pour la région, puis choisissez une zone comme indiqué à l'étape 2. - Pour Réseau, saisissez la valeur suivante :
lb-network
. - Pour Sous-réseau, saisissez la valeur suivante :
lb-subnet
. - Dans la section Instances de VM, ajoutez les VM comme indiqué à l'étape 2.
- Cliquez sur Create (Créer).
gcloud
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-10 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check \ --subnet=lb-subnet \ --metadata=startup-script='#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed'
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
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
Vous pouvez obtenir le DEBIAN_IMAGE_NAME
actuel en exécutant la commande gcloud
suivante :
gcloud compute images list \ --filter="family=debian-10"
Créez quatre VM de backend en envoyant quatre requêtes POST
à la méthode instances.insert
:
POST https://compute.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/e2-standard-2",
"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-image-name",
"diskType": "projects/project-id/zones/zone/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\nfile_ports=\"/etc/apache2/ports.conf\"\nfile_http_site=\"/etc/apache2/sites-available/000-default.conf\"\nfile_https_site=\"/etc/apache2/sites-available/default-ssl.conf\"\nhttp_listen_prts=\"Listen 80\\nListen 8008\\nListen 8080\\nListen 8088\"\nhttp_vh_prts=\"*:80 *:8008 *:8080 *:8088\"\nhttps_listen_prts=\"Listen 443\\nListen 8443\"\nhttps_vh_prts=\"*:443 *:8443\"\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nprt_conf=\"$(cat \"$file_ports\")\"\nprt_conf_2=\"$(echo \"$prt_conf\" | sed \"s|Listen 80|${http_listen_prts}|\")\"\nprt_conf=\"$(echo \"$prt_conf_2\" | sed \"s|Listen 443|${https_listen_prts}|\")\"\necho \"$prt_conf\" | tee \"$file_ports\"\nhttp_site_conf=\"$(cat \"$file_http_site\")\"\nhttp_site_conf_2=\"$(echo \"$http_site_conf\" | sed \"s|*:80|${http_vh_prts}|\")\"\necho \"$http_site_conf_2\" | tee \"$file_http_site\"\nhttps_site_conf=\"$(cat \"$file_https_site\")\"\nhttps_site_conf_2=\"$(echo \"$https_site_conf\" | sed \"s|_default_:443|${https_vh_prts}|\")\"\necho \"$https_site_conf_2\" | tee \"$file_https_site\"\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://compute.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://compute.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://compute.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://compute.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
- Dans Google Cloud Console, accédez à la page Instances de VM.
Accéder à la page "Instances de VM" - Cliquez sur Create instance (Créer une instance).
- Définissez le paramètre Nom sur
vm-client
. - Définissez le paramètre Zone sur
us-west1-a
. - Cliquez sur Options avancées.
- Cliquez sur Mise en réseau et configurez les champs suivants :
- Pour Tags réseau, saisissez
allow-ssh
. - Pour Interfaces réseau, sélectionnez l'option suivante :
- Réseau :
lb-network
- Sous-réseau :
lb-subnet
- Réseau :
- Pour Tags réseau, saisissez
- 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-10 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=lb-subnet
API
Envoyez une requête POST
à la méthode instances.insert
.
POST https://compute.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/e2-standard-2",
"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-client",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"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 vous devez transmettre le trafic HTTP via l'équilibreur de charge interne, vous devez 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, vous spécifiez une adresse IP interne,
10.1.2.99
, lors de la création de la règle de transfert.
Console
- Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Accéder à la page "Équilibrage de charge" - Cliquez sur Créer un équilibreur de charge.
- Sur la carte Équilibrage de charge TCP, cliquez sur Démarrer la configuration.
- Pour Web ou interne uniquement, sélectionnez Seulement entre les VM.
- Pour Type d'équilibreur de charge, sélectionnez Passthrough.
- Cliquez sur Continuer.
- Définissez le paramètre Nom sur
be-ilb
.
Configurer les backends
- Cliquez sur Configuration du backend et apportez les modifications suivantes :
- Région :
us-west1
- Réseau :
lb-network
- Pour ajouter des backends, procédez comme suit :
- Sous Nouveau backend, pour gérer uniquement le trafic IPv4, sélectionnez le type de pile d'adresses IP comme IPv4 (pile unique).
- Sélectionnez le groupe d'instances
ig-c
, puis cliquez sur Terminé. - Cliquez sur Ajouter un backend et répétez cette étape pour ajouter
ig-a
.
- Sous Vérification d'état, sélectionnez Créer une vérification d'état, saisissez les informations suivantes, puis cliquez sur Enregistrer :
- Nom :
hc-http-80
- Protocole :
HTTP
- Port :
80
- Protocole de proxy :
NONE
- Chemin de requête :
/
Notez que lorsque vous créez un équilibreur de charge à l'aide de la console Google Cloud, la vérification de l'état est globale. Si vous souhaitez créer une vérification de l'état régionale, utilisezgcloud
ou l'API.
- Nom :
- Vérifiez qu'une coche bleue apparaît à côté de Configuration du backend avant de continuer.
- Région :
Configurer l'interface
- Cliquez sur Configuration de l'interface. Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
- Nom :
fr-ilb
- Sous-réseau :
lb-subnet
- Dans Adresse IP interne, sélectionnez Créer une adresse IP, saisissez les informations suivantes, puis cliquez sur Réserver :
- Nom :
ip-ilb
- Version IP : IPv4
- Adresse IP statique : Laissez-moi choisir
- Adresse IP personnalisée :
10.1.2.99
- Nom :
- Ports : sélectionnez Plusieurs et saisissez
80,8008,8080,8088
pour le numéro de port. - Vérifiez qu'une coche bleue apparaît à côté de Configuration de l'interface avant de continuer.
- Nom :
Vérifier la configuration
- Cliquez sur Vérifier et finaliser.
- Vérifiez les paramètres de configuration de votre équilibreur de charge.
- Facultatif : cliquez sur Code équivalent pour afficher la requête API REST qui sera utilisée pour créer l'équilibreur de charge.
- Cliquez sur Créer.
gcloud
Créez une vérification d'état HTTP régionale pour tester la connectivité HTTP aux VM sur le port 80.
gcloud compute health-checks create http hc-http-80 \ --region=us-west1 \ --port=80
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 \ --health-checks-region=us-west1
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
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,8008,8080,8088 \ --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 regionHealthChecks.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/regionHealthChecks
{
"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://compute.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/regions/us-west1/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://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules
{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"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"
}
Tester votre équilibreur de charge
Ces tests vous montrent comment valider la configuration de votre équilibreur de charge et en savoir plus sur son comportement attendu.
Tester la connexion depuis la VM cliente
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.
Connectez-vous à l'instance de VM cliente.
gcloud compute ssh vm-client --zone=us-west1-a
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
La règle de transfert est configurée pour desservir les ports
80
,8008
,8080
et8088
. Pour envoyer du trafic vers ces autres ports, ajoutez deux points (:
) et le numéro de port après l'adresse IP, comme ceci :curl http://10.1.2.99:8008
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
Pinguer 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.
Connectez-vous à l'instance de VM cliente.
gcloud compute ssh vm-client --zone=us-west1-a
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
Envoyer des requêtes à partir de VM à équilibrage de charge
Ce test montre que lorsqu'une VM de backend envoie des paquets à l'adresse IP de la règle de transfert de son équilibreur de charge, ces requêtes sont réacheminées vers elle-même. Cette contrainte s'applique quel que soit l'état de la VM de backend de la vérification d'état.
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 l'OS invité. Sur les VM Linux, l'environnement invité crée une route pour l'adresse IP de l'équilibreur de charge dans la table de routage locale du système d'exploitation.
Comme cette route locale se trouve dans la VM elle-même (et non dans une route du réseau VPC), les paquets envoyés à l'adresse IP de l'équilibreur de charge ne sont pas traités par le réseau VPC. À la place, les paquets envoyés à l'adresse IP de l'équilibreur de charge restent dans le système d'exploitation de la VM.
Connectez-vous à une VM de backend, telle que
vm-a1
:gcloud compute ssh vm-a1 --zone=us-west1-a
Envoyez une requête Web à l'équilibreur de charge (par adresse IP ou nom de service) à l'aide de
curl
. La réponse provient de la même VM de backend qui effectue la requête. Les requêtes répétées sont traitées de la même manière. La réponse attendue lors du test à partir devm-a1
est toujours la suivante :Page served from: vm-a1
.curl http://10.1.2.99
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
Lorsqu'une VM de backend pour un équilibreur de charge TCP/UDP interne envoie des paquets à l'adresse IP de la règle de transfert de l'équilibreur de charge, les paquets sont toujours acheminés vers la VM qui effectue la requête. En effet, un équilibreur de charge TCP/UDP interne est un équilibreur de charge à stratégie directe et est mis en œuvre en créant une route locale pour l'adresse IP de l'équilibreur de charge dans le système d'exploitation invité de la VM, comme indiqué dans cette section. Dans le cas où les backends à équilibrage de charge doivent envoyer du trafic TCP à l'adresse IP de l'équilibreur de charge et que vous devez distribuer le trafic comme s'il provenait d'une instance qui n'a pas de charge backend équilibrée, envisagez plutôt d'utiliser un équilibreur de charge proxy TCP régional interne.
Pour en savoir plus, consultez la page Équilibreurs de charge TCP/UDP internes en tant que sauts suivants.
Configurer l'équilibreur de charge avec des sous-réseaux à double pile
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 :
- L'exemple de cette page utilise un réseau VPC en mode personnalisé nommé
lb-network-dual-stack
. Le trafic IPv6 requiert un sous-réseau en mode personnalisé. - Un sous-réseau à double pile (
stack-type
défini surIPv4_IPv6
), requis pour le trafic IPv6. Lorsque vous créez un sous-réseau à double pile sur un réseau VPC en mode personnalisé, choisissez un type d'accès IPv6 pour le sous-réseau. Pour cet exemple, nous définissons le paramètreipv6-access-type
du sous-réseau surINTERNAL
. Cela signifie que les nouvelles VM de ce sous-réseau peuvent se voir attribuer des adresses IPv4 internes et des adresses IPv6 internes. Pour obtenir des instructions, consultez la documentation VPC sur l'ajout d'un sous-réseau à deux piles. - Des règles de pare-feu autorisant les connexions entrantes aux VM de backend.
- Le groupe d'instances backend, situé dans la région et le sous-réseau suivants pour cet exemple :
- Région :
us-west1
- Sous-réseau:
lb-subnet
, avec plage d'adresses IPv4 principale10.1.2.0/24
. Bien que vous choisissiez la plage d'adresses IPv4 à configurer sur le sous-réseau, la plage d'adresses IPv6 est attribuée automatiquement. Google fournit un bloc CIDR IPv6 de taille fixe (/64).
- Région :
- Quatre VM à double pile de backend : deux VM dans un groupe d'instances non géré dans la zone
us-west1-a
et deux VM dans un groupe d'instances non géré dans la zoneus-west1-c
. Pour démontrer l'accès mondial, cet exemple crée une deuxième VM cliente de test dans une région et un sous-réseau différents :- Région :
europe-west1
- Sous-réseau :
europe-subnet
, avec plage d'adresses IP principale10.3.4.0/24
- Région :
- VM cliente pour tester les connexions
- Les composants de l'é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 zonaux. - Deux règles de transfert internes pour l'interface de l'équilibreur de charge.
Le diagramme suivant montre l'architecture de cet exemple :
Configurer un réseau, une région et un sous-réseau
L'exemple d'équilibreur de charge TCP/UDP interne décrit sur cette page est créé dans un réseau VPC en mode personnalisé nommé lb-network-dual-stack
.
Pour configurer des sous-réseaux avec des plages IPv6 internes, activez une plage IPv6 interne ULA du réseau VPC. Les plages de sous-réseaux IPv6 internes sont allouées à partir de cette plage.
Console
Dans Google Cloud Console, accédez à la page Réseaux VPC.
Cliquez sur Créer un réseau VPC.
Dans le champ Nom, saisissez
lb-network-dual-stack
.Si vous souhaitez configurer des plages d'adresses IPv6 internes sur les sous-réseaux de ce réseau, procédez comme suit :
- Dans le champ Plage IPv6 interne ULA du réseau VPC, sélectionnez Activée.
- Dans le champ Allouer une plage IPv6 interne, sélectionnez Automatiquement ou Manuellement.
Dans le champ Mode de création de sous-réseau, sélectionnez Personnalisé.
Dans la section Nouveau sous-réseau, spécifiez les paramètres de configuration de sous-réseau suivants :
- Dans le champ Nom, saisissez
lb-subnet
. - Pour Région, sélectionnez
us-west1
. - Pour créer un sous-réseau à double pile, sélectionnez IPv4 et IPv6 (double pile) dans le champ Type de pile d'adresses IP.
- Dans Plage IPv4, saisissez
10.1.2.0/24
. - Dans le champ Type d'accès IPv6, sélectionnez Interne.
- Dans le champ Nom, saisissez
Cliquez sur OK.
Pour ajouter d'autres sous-réseaux, cliquez sur Ajouter un sous-réseau et répétez les étapes ci-dessus.
Cliquez sur Créer.
gcloud
Pour créer un réseau VPC en mode personnalisé, exécutez la commande
gcloud compute networks create
.Pour configurer des plages IPv6 internes sur n'importe quel sous-réseau de ce réseau, utilisez l'option
--enable-ula-internal-ipv6
. Cette option attribue un préfixe ULA/48
compris dans la plagefd20::/20
utilisée par Google Cloud pour les plages de sous-réseaux IPv6 internes. Si vous souhaitez sélectionner la plage IPv6/48
attribuée, utilisez l'option--internal-ipv6-range
pour spécifier une plage.gcloud compute networks create lb-network-dual-stack \ --subnet-mode=custom \ --enable-ula-internal-ipv6 \ --internal-ipv6-range=ULA_IPV6_RANGE \ --bgp-routing-mode=regional
Remplacez
ULA_IPV6_RANGE
par un préfixe/48
compris dans la plagefd20::/20
utilisée par Google pour les plages de sous-réseaux IPv6 internes. Si vous n'utilisez pas l'option--internal-ipv6-range
, Google sélectionne un préfixe/48
pour le réseau, par exemplefd20:bc7:9a1c::/48
.Au sein du réseau
NETWORK
, créez un sous-réseau pour les backends dans la régionus-west1
et un autre sous-réseau pour tester l'accès mondial dans la régioneurope-west1
:Pour créer les sous-réseaux, exécutez la commande
gcloud compute networks subnets create
.gcloud compute networks subnets create lb-subnet \ --network=lb-network-dual-stack \ --range=10.1.2.0/24 \ --region=us-west1 \ --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL
gcloud compute networks subnets create europe-subnet \ --network=lb-network-dual-stack \ --range=10.3.4.0/24 \ --region=europe-west1 \ --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL
API
Créez un réseau VPC en mode personnalisé.
Pour configurer les plages IPv6 internes sur n'importe quel sous-réseau de ce réseau, définissez enableUlaInternalIpv6
sur "true". Cette option attribue une plage /48
comprise dans la plage fd20::/20
utilisée par Google pour les plages de sous-réseaux IPv6 internes. Si vous souhaitez sélectionner la plage IPv6 /48
attribuée, utilisez également le champ internalIpv6Range
pour spécifier une plage.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks { "autoCreateSubnetworks": false, "name": "lb-network-dual-stack", "mtu": MTU, "enableUlaInternalIpv6": true, "internalIpv6Range": "ULA_IPV6_RANGE", "routingConfig": { "routingMode": "DYNAMIC_ROUTING_MODE" } }
Remplacez les éléments suivants :
PROJECT_ID
: ID du projet où le réseau VPC a été créé.MTU
: unité de transmission maximale du réseau. La MTU peut être de1460
(par défaut) ou de1500
. Consultez la page Présentation de l'unité de transmission maximale avant de définir la MTU sur1500
.ULA_IPV6_RANGE
: préfixe/48
de la plagefd20::/20
utilisée par Google pour les plages de sous-réseaux IPv6 internes. Si vous ne fournissez pas de valeur pourinternalIpv6Range
, Google sélectionne un préfixe/48
pour le réseau.DYNAMIC_ROUTING_MODE
:global
ouregional
pour contrôler le comportement de l'annonce de routage des routeurs cloud dans le réseau. Pour plus d'informations, consultez la documentation relative au mode de routage dynamique.Pour plus d'informations, reportez-vous à la méthode
networks.insert
.
Envoyez deux requêtes POST
à la méthode subnetworks.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks { "ipCidrRange": "10.1.2.0/24", "network": "lb-network-dual-stack", "name": "lb-subnet" "stackType": IPV4_IPV6, "ipv6AccessType": Internal }
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks { "ipCidrRange": "10.3.4.0/24", "network": "lb-network-dual-stack", "name": "europe-subnet" "stackType": IPV4_IPV6, "ipv6AccessType": Internal }
Configurer des règles de pare-feu
Cet exemple utilise les règles de pare-feu suivantes :
fw-allow-lb-access
: règle d'entrée, applicable à toutes les cibles du réseau VPC, autorisant le trafic provenant de sources dans les plages10.1.2.0/24
et10.3.4.0/24
. Cette règle autorise le trafic entrant de n'importe quel client situé dans l'un des deux sous-réseaux. Par la suite, vous pourrez configurer et tester l'accès mondial.fw-allow-lb-access-ipv6
: règle d'entrée, applicable à toutes les cibles du réseau VPC, autorisant le trafic provenant de sources de la plage IPv6 configurée dans le sous-réseau. Cette règle autorise le trafic IPv6 entrant de n'importe quel client situé dans l'un des deux sous-réseaux. Par la suite, vous pourrez configurer et tester l'accès mondial.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 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 cibleallow-ssh
pour identifier les VM auxquelles la règle 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
et35.191.0.0/16
). Cet exemple utilise le tag cibleallow-health-check
pour identifier les instances auxquelles la règle doit s'appliquer.fw-allow-health-check-ipv6
: 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 (2600:2d00:1:b029::/64
). Cet exemple utilise le tag cibleallow-health-check-ipv6
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
Dans Google Cloud Console, accédez à la page Pare-feu.
Cliquez sur Créer une règle de pare-feu, puis saisissez les informations suivantes pour créer la règle permettant d'autoriser le trafic de sous-réseau :
- Nom :
fw-allow-lb-access
- Réseau :
lb-network-dual-stack
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : toutes les instances du réseau
- Filtre source : Plages IPv4
- Plages IPv4 sources :
10.1.2.0/24
et10.3.4.0/24
- Protocoles et ports : tout autoriser
- Nom :
Cliquez sur Créer.
Cliquez sur Créer une règle de pare-feu, puis saisissez les informations suivantes pour créer la règle permettant d'autoriser le trafic de sous-réseau IPv6 :
- Nom :
fw-allow-lb-access-ipv6
- Réseau :
lb-network-dual-stack
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : toutes les instances du réseau
- Filtre source : Plages IPv6
- Plages IPv6 sources : adresse IPV6_ADDRESS attribuée dans
lb-subnet
- Protocoles et ports : tout autoriser
- Nom :
Cliquez sur Créer.
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-dual-stack
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : tags cibles spécifiés
- Tags cibles :
allow-ssh
- Filtre source : Plages IPv4
- Plages IPv4 sources :
0.0.0.0/0
- Protocoles et ports : sélectionnez Protocoles et ports spécifiés, puis saisissez
tcp:22
.
- Nom :
Cliquez sur Créer.
Cliquez à nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état IPv6 Google Cloud :
- Nom :
fw-allow-health-check-ipv6
- Réseau :
lb-network-dual-stack
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : tags cibles spécifiés
- Tags cibles :
allow-health-check-ipv6
- Filtre source : Plages IPv6
- Plages IPv4 sources :
2600:2d00:1:b029::/64
- Protocoles et ports : tout autoriser
- Nom :
Cliquez sur Créer.
Cliquez à nouveau 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-dual-stack
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : tags cibles spécifiés
- Tags cibles :
allow-health-check
- Filtre source : Plages IPv4
- Plages IPv4 sources :
130.211.0.0/22
et35.191.0.0/16
- Protocoles et ports : tout autoriser
- Nom :
Cliquez sur Create (Créer).
gcloud
Créez la règle de pare-feu
fw-allow-lb-access
pour autoriser la communication depuis le sous-réseau :gcloud compute firewall-rules create fw-allow-lb-access \ --network=lb-network-dual-stack \ --action=allow \ --direction=ingress \ --source-ranges=10.1.2.0/24,10.3.4.0/24 \ --rules=all
Créez la règle de pare-feu
fw-allow-lb-access-ipv6
pour autoriser la communication depuis le sous-réseau :gcloud compute firewall-rules create fw-allow-lb-access-ipv6 \ --network=lb-network-dual-stack \ --action=allow \ --direction=ingress \ --source-ranges=IPV6_ADDRESS \ --rules=all
Remplacez
IPV6_ADDRESS
par l'adresse IPv6 attribuée danslb-subnet
.Créez la règle de pare-feu
fw-allow-ssh
pour autoriser la connectivité SSH aux VM avec le tag réseauallow-ssh
. Lorsque vous omettezsource-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-dual-stack \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Créez la règle
fw-allow-health-check-ipv6
pour autoriser les vérifications d'état IPv6 Google Cloud.gcloud compute firewall-rules create fw-allow-health-check-ipv6 \ --network=lb-network-dual-stack \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check-ipv6 \ --source-ranges=2600:2d00:1:b029::/64 \ --rules=tcp,udp
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-dual-stack \ --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-access
en envoyant une requêtePOST
à la méthodefirewalls.insert
.POST https://compute.googleapis.com/compute/v1/projects/
PROJECT_ID
/global/firewalls{ "name": "fw-allow-lb-access", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "10.1.2.0/24", "10.3.4.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-lb-access-ipv6
en envoyant une requêtePOST
à la méthodefirewalls.insert
.POST https://compute.googleapis.com/compute/v1/projects/
PROJECT_ID
/global/firewalls{ "name": "fw-allow-lb-access-ipv6", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "IPV6_ADDRESS" ], "allowed": [ { "IPProtocol": "tcp" }, { "IPProtocol": "udp" }, { "IPProtocol": "icmp" } ], "direction": "INGRESS", "logConfig": { "enable": false }, "disabled": false }
Remplacez
IPV6_ADDRESS
par l'adresse IPv6 attribuée danslb-subnet
.Créez la règle de pare-feu
fw-allow-ssh
en envoyant une requêtePOST
à la méthodefirewalls.insert
.POST https://compute.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-dual-stack", "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-ipv6
en envoyant une requêtePOST
à la méthodefirewalls.insert
.POST https://compute.googleapis.com/compute/v1/projects/
PROJECT_ID
/global/firewalls{ "name": "fw-allow-health-check-ipv6", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "2600:2d00:1:b029::/64" ], "targetTags": [ "allow-health-check-ipv6" ], "allowed": [ { "IPProtocol": "tcp" }, { "IPProtocol": "udp" } ], "direction": "INGRESS", "logConfig": { "enable": false }, "disabled": false }
Créez la règle de pare-feu
fw-allow-health-check
en envoyant une requêtePOST
à la méthodefirewalls.insert
.POST https://compute.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-dual-stack", "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 zones 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é.
Pour utiliser cet exemple et les options de configuration supplémentaires, chacune des quatre VM exécute un serveur Web Apache qui écoute sur les ports TCP suivants : 80, 8008, 8080, 8088, 443 et 8443.
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 et peuvent se connecter 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.
Assurez-vous que le type de pile du sous-réseau correspond au type de pile des modèles d'instances utilisés par les groupes d'instances gérés. Le sous-réseau doit être une pile double si le groupe d'instances géré utilise un modèle d'instance à double pile.
Pour plus de simplicité, ces VM de backend exécutent Debian GNU/Linux 10.
Console
Créer des VM de backend
- Dans Google Cloud Console, accédez à la page Instances de VM.
Accéder à la page "Instances de VM" - Répétez les étapes 3 à 8 pour chaque 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
- Nom :
- Cliquez sur Créer une instance.
- Définissez le Nom comme indiqué à l'étape 2.
- Dans le champ Région, choisissez
us-west1
, puis sélectionnez une zone comme indiqué à l'étape 2. - Dans la section Disque de démarrage, assurez-vous que les options sélectionnées sont Debian pour le système d'exploitation et 10 (Buster) pour la version. Si nécessaire, cliquez sur Sélectionner pour modifier l'image.
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
etallow-health-check-ipv6
. - Cliquez sur le bouton Modifier (
- Réseau :
lb-network-dual-stack
- Sous-réseau :
lb-subnet
- Type de pile d'adresses IP: IPv4 et IPv6 (double pile)
- Adresse IP interne principale : éphémère (automatique)
- Adresse IP externe : Éphémère
) sous Interfaces réseau, apportez les modifications suivantes, puis cliquez sur OK : - Réseau :
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 if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" 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 echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed
- Cliquez sur Mise en réseau et ajoutez les tags réseau suivants :
Cliquez sur Create (Créer).
Créer des groupes d'instances
- Dans Google Cloud Console, accédez à la page Groupes d'instances.
Accéder à la page "Groupes d'instances" - 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
etvm-a2
- Groupe d'instances :
ig-c
, zone :us-west1-c
, VM :vm-c1
etvm-c2
- Groupe d'instances :
- Cliquez sur Créer un groupe d'instances.
- Cliquez sur Nouveau groupe d'instances non géré.
- Définissez le Nom comme indiqué à l'étape 2.
- Dans la section Emplacement, sélectionnez
us-west1
pour la région, puis choisissez une zone comme indiqué à l'étape 2. - Pour Réseau, saisissez la valeur suivante :
lb-network-dual-stack
. - Pour Sous-réseau, saisissez la valeur suivante :
lb-subnet
. - Dans la section Instances de VM, ajoutez les VM comme indiqué à l'étape 2.
- Cliquez sur Create (Créer).
gcloud
Pour créer les quatre VM, exécutez la commande
gcloud compute instances create
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-10 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check-ipv6 \ --subnet=lb-subnet \ --stack-type=IPV4_IPV6 \ --metadata=startup-script='#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" 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 prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed'
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
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
Vous pouvez obtenir le DEBIAN_IMAGE_NAME
actuel en exécutant la commande gcloud
suivante :
gcloud compute images list \ --filter="family=debian-10"
Créez quatre VM de backend en envoyant quatre requêtes POST
à la méthode instances.insert
:
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/zones/[ZONE]/instances
{
"name": "[VM-NAME]",
"tags": {
"items": [
"allow-health-check-ipv6",
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/project-id/zones/[ZONE]/machineTypes/e2-standard-2",
"canIpForward": false,
"networkInterfaces": [
{
"stackType": "IPV4_IPV6",
"network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network-dual-stack",
"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-image-name",
"diskType": "projects/project-id/zones/zone/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\nfile_ports=\"/etc/apache2/ports.conf\"\nfile_http_site=\"/etc/apache2/sites-available/000-default.conf\"\nfile_https_site=\"/etc/apache2/sites-available/default-ssl.conf\"\nhttp_listen_prts=\"Listen 80\\nListen 8008\\nListen 8080\\nListen 8088\"\nhttp_vh_prts=\"*:80 *:8008 *:8080 *:8088\"\nhttps_listen_prts=\"Listen 443\\nListen 8443\"\nhttps_vh_prts=\"*:443 *:8443\"\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\nprt_conf=\"$(cat \"$file_ports\")\"\nprt_conf_2=\"$(echo \"$prt_conf\" | sed \"s|Listen 80|${http_listen_prts}|\")\"\nprt_conf=\"$(echo \"$prt_conf_2\" | sed \"s|Listen 443|${https_listen_prts}|\")\"\necho \"$prt_conf\" | tee \"$file_ports\"\nhttp_site_conf=\"$(cat \"$file_http_site\")\"\nhttp_site_conf_2=\"$(echo \"$http_site_conf\" | sed \"s|*:80|${http_vh_prts}|\")\"\necho \"$http_site_conf_2\" | tee \"$file_http_site\"\nhttps_site_conf=\"$(cat \"$file_https_site\")\"\nhttps_site_conf_2=\"$(echo \"$https_site_conf\" | sed \"s|_default_:443|${https_vh_prts}|\")\"\necho \"$https_site_conf_2\" | tee \"$file_https_site\"\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://compute.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-dual-stack",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet"
}
POST https://compute.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-dual-stack",
"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://compute.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://compute.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
- Dans Google Cloud Console, accédez à la page Instances de VM.
Accéder à la page "Instances de VM" - Cliquez sur Create instance (Créer une instance).
- Définissez le paramètre Nom sur
vm-client
. - Définissez le paramètre Zone sur
us-west1-a
. - 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 Modifier sous Interfaces réseau, apportez les modifications suivantes, puis cliquez sur OK :
- Réseau :
lb-network-dual-stackk
- Sous-réseau :
lb-subnet
- Type de pile d'adresses IP: IPv4 et IPv6 (double pile)
- Adresse IP interne principale : éphémère (automatique)
- Adresse IP externe : Éphémère
- Réseau :
- Cliquez sur Mise en réseau et ajoutez
- 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-10 \ --image-project=debian-cloud \ --stack-type=IPV4_IPV6 \ --tags=allow-ssh \ --subnet=lb-subnet
api
Envoyez une requête POST
à la méthode instances.insert
.
POST https://compute.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/e2-standard-2",
"canIpForward": false,
"networkInterfaces": [
{
"stackType": "IPV4_IPV6",
"network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network-dual-stack",
"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-client",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"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 vous devez transmettre le trafic HTTP via l'équilibreur de charge interne, vous devez utiliser TCP, et non UDP.
Règle de transfert : cet exemple crée deux règles de transfert internes pour le trafic IPv4 et IPv6.
Adresse IP interne : dans cet exemple, vous spécifiez une adresse IP interne,
10.1.2.99
, lors de la création de la règle de transfert IPv4. Pour en savoir plus, consultez la page Adresse IP interne. Bien que vous choisissiez l'adresse IPv4 configurée, l'adresse IPv6 est attribuée automatiquement.
Console
- Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Accéder à la page "Équilibrage de charge" - Cliquez sur Create load balancer (Créer un équilibreur de charge).
- Sous Équilibrage de charge TCP, cliquez sur Démarrer la configuration.
- Sous Web ou interne uniquement, sélectionnez Seulement entre les VM.
- Cliquez sur Continuer.
- Sur la page Nouvel équilibreur de charge interne, procédez comme suit :
- Dans le champ Nom, saisissez
be-ilb
. - Pour la région, sélectionnez
us-west1
. - Pour le réseau, sélectionnez
lb-network-dual-stack
.
- Dans le champ Nom, saisissez
Configuration du backend
- Cliquez sur Configuration du backend et procédez comme suit :
- Sous Nouveau backend, pour Type de pile IP, sélectionnez IPv4 et IPv6 (double pile).
- Sélectionnez
ig-a
groupe d'instances, puis cliquez sur OK. - Cliquez sur Ajouter un backend.
- Dans la section Nouveau backend, sélectionnez le groupe d'instances
ig-c
, puis cliquez sur OK. - Sous Vérification d'état, sélectionnez Créer une vérification d'état, saisissez les informations suivantes, puis cliquez sur Enregistrer :
- Nom :
hc-http-80
. - Champ d'application : Régional.
- Protocole :
HTTP
- Port :
80
. - Proxy protocol :
NONE
. - Chemin de requête :
/
.
- Nom :
- Vérifiez qu'une coche bleue apparaît à côté de Configuration du backend.
Configuration de l'interface
- Cliquez sur Configuration de l'interface.
Nom :
fr-ilb-ipv6
.- Pour gérer le trafic IPv6, procédez comme suit :
- Version IP : IPv6
- Sous-réseau :
lb-subnet
. La plage d'adresses IPv6 de la règle de transfert est toujours éphémère. - Ports : Multiple.
- Dans le champ Numéro de port, saisissez
80,8008,8080,8088
.
- Dans le champ Numéro de port, saisissez
- Cliquez sur OK.
- Pour gérer le trafic IPv4, procédez comme suit :
- Cliquez sur Ajouter une adresse IP et un port frontend pour ajouter la règle de transfert IPv4.
- Nom :
fr-ilb
- Version IP : IPv4
- Sous-réseau :
lb-subnet
- Pour Adresse IP interne, sélectionnez Créer une adresse IP, 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
- Nom :
- Ports : sélectionnez Plusieurs et saisissez
80,8008,8080,8088
pour le numéro de port. - Cliquez sur OK.
Si un cercle bleu avec une coche s'affiche à gauche de Configuration du frontend, cela indique que la configuration a réussi.
- Pour gérer le trafic IPv6, procédez comme suit :
Vérifier la configuration
- Cliquez sur Vérifier et finaliser. Vérifiez tous vos paramètres.
- Si les paramètres sont corrects, cliquez sur Créer. La création de l'équilibreur de charge TCP/UDP interne prend quelques minutes.
gcloud
Créez une vérification d'état HTTP régionale pour tester la connectivité HTTP aux VM sur le port 80.
gcloud compute health-checks create http hc-http-80 \ --region=us-west1 \ --port=80
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 \ --health-checks-region=us-west1
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
Créez deux règles de transfert pour le service de backend. Lorsque vous créez la règle de transfert IPv4, spécifiez
10.1.2.99
pour l'adresse IP interne dans le sous-réseau pour les adresses IPv4.gcloud compute forwarding-rules create fr-ilb \ --region=us-west1 \ --load-balancing-scheme=internal \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=be-ilb \ --backend-service-region=us-west1
gcloud compute forwarding-rules create fr-ilb-ipv6 \ --region=us-west1 \ --load-balancing-scheme=internal \ --subnet=lb-subnet \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=be-ilb \ --backend-service-region=us-west1 \ --ip-version=IPV6
api
Créez la vérification d'état en envoyant une requête POST
à la méthode regionHealthChecks.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/regionHealthChecks
{
"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://compute.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/regions/us-west1/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://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules
{
"name": "fr-ilb-ipv6",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
"backendService": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb",
"ipVersion": "IPV6",
"networkTier": "PREMIUM"
}
Créez la règle de transfert en envoyant une requête POST
à la méthode forwardingRules.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules
{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
"backendService": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
Tester 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.
Connectez-vous à l'instance de VM cliente.
gcloud compute ssh vm-client --zone=us-west1-a
Décrivez la règle de transfert IPv6
fr-ilb-ipv6
. Notez l'élémentIPV6_ADDRESS
dans la description.gcloud compute forwarding-rules describe fr-ilb-ipv6 --region=us-west1
Décrivez la règle de transfert IPv4
fr-ilb
.gcloud compute forwarding-rules describe fr-ilb --region=us-west1
À partir de clients disposant d'une connectivité IPv6, exécutez la commande suivante:
$ curl -m 10 -s http://IPV6_ADDRESS:80
Par exemple, si l'adresse IPv6 attribuée est
[fd20:1db0:b882:802:0:46:0:0/96]:80
, la commande doit se présenter comme suit :$ curl -m 10 -s http://[fd20:1db0:b882:802:0:46:0:0]:80
À partir de clients disposant d'une connectivité IPv4, exécutez la commande suivante:
$ curl -m 10 -s http://10.1.2.99:80
Remplacez les espaces réservés par des valeurs valides :
IPV6_ADDRESS
correspond à l'adresse IPv6 éphémère de la règle de transfertfr-ilb-ipv6
.
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
Vous pouvez activer l'accès mondial pour votre exemple d'équilibreur de charge TCP/UDP interne afin de le rendre accessible aux clients situés dans toutes les régions.
Les backends de votre exemple d'équilibreur de charge doivent toujours être situés dans une région (us-west1
).
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
- Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Accéder à la page "Équilibrage de charge" Dans la colonne Nom, cliquez sur votre équilibreur de charge TCP/UDP interne. L'exemple d'équilibreur de charge est nommé
be-ilb
.Cliquez sur Configuration du frontend.
Cliquez sur Modifier (
).Sous Accès mondial, sélectionnez Activer.
Cliquez sur OK.
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
Mettez à jour l'exemple de règle de transfert de l'équilibreur de charge,
fr-ilb
, pour inclure l'option--allow-global-access
.gcloud compute forwarding-rules update fr-ilb \ --region=us-west1 \ --allow-global-access
Vous pouvez utiliser la commande
forwarding-rules describe
pour déterminer si l'accès mondial est activé pour une règle de transfert. Exemple :gcloud compute forwarding-rules describe fr-ilb \ --region=us-west1 \ --format="get(name,region,allowGlobalAccess)"
Le mot
True
apparaît dans la sortie, après le nom et la région de la règle de transfert, lorsque l'accès mondial est activé.
API
Envoyez une requête PATCH
à la méthode forwardingRules/patch
.
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules/fr-ilb
{
"allowGlobalAccess": true
}
Créer une VM cliente pour tester l'accès mondial
Console
- Dans Google Cloud Console, accédez à la page Instances de VM.
Accéder à la page "Instances de VM" - Cliquez sur Create instance (Créer une instance).
- Définissez le paramètre Nom sur
vm-client2
. - Définissez le paramètre Zone sur
europe-west1-b
. - Cliquez sur Options avancées.
- Cliquez sur Mise en réseau et configurez les champs suivants :
- Pour Tags réseau, saisissez
allow-ssh
. - Pour Interfaces réseau, sélectionnez l'option suivante :
- Réseau :
lb-network
- Sous-réseau :
europe-subnet
- Réseau :
- Pour Tags réseau, saisissez
- 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 europe-west1-b
et utilise le même sous-réseau que les VM de backend.
gcloud compute instances create vm-client2 \ --zone=europe-west1-b \ --image-family=debian-10 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=europe-subnet
API
Envoyez une requête POST
à la méthode instances.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/zones/europe-west1-b/instances
{
"name": "vm-client2",
"tags": {
"items": [
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/project-id/zones/europe-west1-b/machineTypes/e2-standard-2",
"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/europe-west1/subnetworks/europe-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "vm-client2",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"diskType": "projects/project-id/zones/europe-west1-b/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
],
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
Se connecter à la VM cliente et tester la connectivité
gcloud compute ssh vm-client2 --zone=europe-west1-b
Testez la connexion à l'équilibreur de charge sur tous les ports configurés, comme vous l'avez fait depuis le client vm-client
dans la région us-west1
. Testez la connectivité HTTP sur les quatre ports configurés sur la règle de transfert :
curl http://10.1.2.99 curl http://10.1.2.99:8008 curl http://10.1.2.99:8080 curl http://10.1.2.99:8088
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.
Pour votre groupe d'instances, vous pouvez définir un service de backend et mapper un nom de port sur le port correspondant. Le service d'équilibrage de charge transfère le trafic vers le port nommé.
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
- Dans Google Cloud Console, accédez à la page Modèles d'instances de VM.
Accéder à la page "Modèles d'instance de VM" - Cliquez sur Create instance template (Créer un modèle d'instance).
- Dans le champ Nom, spécifiez
template-vm-ilb
. - Choisissez un type de machine.
- Pour Disque de démarrage, cliquez sur Modifier, choisissez Debian pour le système d'exploitation et 10 (Buster) pour la version.
- Cliquez sur Enregistrer pour confirmer les options de ce disque de démarrage.
Cliquez sur Options avancées.
- 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
etallow-health-check
- Réseau :
- Cliquez sur Gestion. Dans le champ Script de démarrage, copiez et collez le contenu de script suivant :
#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed
- Cliquez sur Mise en réseau, puis apportez les modifications suivantes :
Cliquez sur Create (Créer).
Groupe d'instances géré
- Dans Google Cloud Console, accédez à la page Groupes d'instances.
Accéder à la page "Groupes d'instances de VM" - Cliquez sur Créer un groupe d'instances.
- Définissez le paramètre Nom sur
ig-ilb
. - Pour Emplacement, sélectionnez Multizone et définissez la région sur
us-west1
. - Définissez le Modèle d'instance sur
template-vm-ilb
. - 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.
- Définissez le nombre minimal d'instances sur
1
et le nombre maximal d'instances sur6
. - 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
. - Cliquez sur Create (Créer).
gcloud
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-10 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check \ --subnet=lb-subnet \ --region=us-west1 \ --network=lb-network \ --metadata=startup-script='#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed'
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
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
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 TCP/UDP 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
- Dans Google Cloud Console, accédez à la page Instances de VM.
Accéder à la page "Instances de VM" - Répétez les étapes ci-dessous pour chaque VM de backend.
- Cliquez sur le nom de la VM de backend (par exemple,
vm-a1
) pour afficher les détails de l'instance de VM. - Cliquez sur Modifier .
- Dans la section Interfaces réseau, cliquez sur le bouton Modifier.
- Dans la fenêtre pop-up Adresse IP externe, sélectionnez Aucune, puis cliquez sur Terminé.
- Cliquez sur Enregistrer.
gcloud
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]"
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://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/zones/us-west1-a/instances/vm-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None
Accepter le trafic sur tous les ports
La règle de transfert de l'équilibreur de charge, et non son service de backend, détermine le ou les ports sur lesquels l'équilibreur de charge accepte le trafic. Pour plus d'informations sur l'utilité de chaque composant, consultez la section Composants.
Lorsque vous avez créé cet exemple de règle de transfert d'équilibreur de charge, vous avez configuré les ports 80
, 8008
, 8080
et 8088
. Le script de démarrage qui installe Apache le configure également pour accepter les connexions HTTPS sur les ports 443
et 8443
.
Pour utiliser ces six ports, vous pouvez configurer la règle de transfert de façon à accepter le trafic sur tous les ports. Avec cette stratégie, vous pouvez également configurer la ou les règles de pare-feu qui autorisent les connexions entrantes vers les VM de backend afin qu'elles n'autorisent que certains ports.
Cette procédure vous montre comment remplacer l'exemple de règle de transfert de l'équilibreur de charge par une règle qui accepte le trafic sur tous les ports.
Pour en savoir plus sur l'utilisation de cette configuration, consultez la page Équilibrage de charge TCP/UDP et règles de transfert internes avec adresse IP commune.
Console
Supprimer une règle de transfert et en créer une nouvelle
- Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Accéder à la page "Équilibrage de charge" - Cliquez sur votre équilibreur de charge
be-ilb
, puis sur Modifier. - Cliquez sur Configuration du frontend.
- Passez la souris sur votre règle de transfert 10.1.2.9 et cliquez sur l'icône de la corbeille pour la supprimer.
- Cliquez sur Ajouter une adresse IP et un port frontend.
- Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
- Nom :
fr-ilb
- Sous-réseau :
lb-subnet
- Dans le champ Adresse IP interne, sélectionnez
ip-ilb
. - Ports : Tous
- Cliquez sur OK.
- Vérifiez qu'une coche bleue apparaît à côté de Configuration de l'interface avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.
- Nom :
- Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.
- Cliquez sur Create (Créer).
gcloud
Supprimez votre règle de transfert existante,
fr-ilb
.gcloud compute forwarding-rules delete fr-ilb \ --region=us-west1
Créez une règle de transfert de remplacement portant le même nom et dont la configuration de port utilise le mot clé
ALL
. Les autres paramètres de la règle de transfert ne changent pas.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=ALL \ --backend-service=be-ilb \ --backend-service-region=us-west1
API
Supprimez la règle de transfert en envoyant une requête DELETE
à la méthode forwardingRules.delete
.
DELETE https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules/fr-ilb
Créez la règle de transfert en envoyant une requête POST
à la méthode forwardingRules.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules
{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"allPorts": true,
"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"
}
Tester le trafic avec la configuration de tous les ports
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 sur les quatre ports :
curl http://10.1.2.99 curl http://10.1.2.99:8008 curl http://10.1.2.99:8080 curl http://10.1.2.99:8088
Testez la connectivité HTTPS sur les ports
443
et8443
. L'option--insecure
est obligatoire, car chaque serveur Apache dans l'exemple de configuration utilise un certificat autosigné.curl https://10.1.2.99 --insecure curl https://10.1.2.99:8443 --insecure
Remarquez que les requêtes HTTP (sur les quatre ports) et HTTPS (sur les deux ports) sont réparties entre toutes les VM de backend.
Accepter le trafic sur plusieurs ports à l'aide de deux règles de transfert
Lorsque vous avez créé cet exemple de règle de transfert d'équilibreur de charge, vous avez configuré les ports 80
, 8008
, 8080
et 8088
. Le script de démarrage qui installe Apache le configure également pour accepter les connexions HTTPS sur les ports 443
et 8443
.
Une stratégie alternative à la configuration d'une règle de transfert unique pour accepter le trafic sur tous les ports consiste à créer plusieurs règles de transfert, acceptant chacune cinq ports ou moins.
Cette procédure vous montre comment remplacer l'exemple de règle de transfert de l'équilibreur de charge par deux règles de transfert, l'une traitant le trafic sur les ports 80
, 8008
, 8080
et 8088
, et l'autre sur les ports 443
et 8443
.
Pour en savoir plus sur l'utilisation de cette configuration, consultez la page Équilibrage de charge TCP/UDP et règles de transfert internes avec adresse IP commune.
Console
- Dans Google Cloud Console, accédez à la page Règles de transfert.
Accéder à la page "Règles de transfert" - Sélectionnez
fr-ilb
. - Cliquez sur Supprimer.
- Accédez à la page Équilibrage de charge.
Accéder à la page Équilibrage de charge - Sélectionnez votre équilibreur de charge TCP/UDP interne. Dans cet exemple,
be-ilb
. - Cliquez sur Modifier.
- Cliquez sur Frontend configuration (Configuration du frontend).
- Cliquez sur Ajouter une adresse IP et un port frontend.
- Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
- Nom :
fr-ilb-http
- Sous-réseau :
lb-subnet
- Sous Usage, sélectionnez Partagé.
- Dans Adresse IP interne, sélectionnez Réserver une adresse IP statique interne, saisissez les informations suivantes, puis cliquez sur Réserver :
- Nom :
internal-10-1-2-99
- Adresse IP statique : Laissez-moi choisir
- Adresse IP personnalisée :
10.1.2.99
- Cliquez sur Réserver.
- Nom :
- Ports : sélectionnez Plusieurs et saisissez
80,8008,8080,8088
pour le numéro de port. - Cliquez sur OK.
- Nom :
- Cliquez sur Ajouter une adresse IP et un port frontend.
- Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
- Nom :
fr-ilb-https
- Sous-réseau :
lb-subnet
- Sous Usage, sélectionnez Partagé.
- Sous Adresse IP, sélectionnez
internal-10-1-2-99
. - Ports : sélectionnez Plusieurs et saisissez
443,8443
pour le numéro de port. - Cliquez sur OK.
- Vérifiez qu'une coche bleue apparaît à côté de Configuration de l'interface avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.
- Nom :
- Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.
- Cliquez sur Mettre à jour.
gcloud
Supprimez votre règle de transfert existante,
fr-ilb
.gcloud compute forwarding-rules delete fr-ilb \ --region=us-west1
Créez une adresse IP interne statique (réservée) pour
10.1.2.99
et définissez l'option--purpose
surSHARED_LOADBALANCER_VIP
. L'option--purpose
est obligatoire pour que deux règles de transfert internes puissent utiliser la même adresse IP interne.gcloud compute addresses create internal-10-1-2-99 \ --region=us-west1 \ --subnet=lb-subnet \ --addresses=10.1.2.99 \ --purpose=SHARED_LOADBALANCER_VIP
- Créez deux règles de transfert de remplacement avec les paramètres suivants :
gcloud compute forwarding-rules create fr-ilb-http \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=be-ilb \ --backend-service-region=us-west1
gcloud compute forwarding-rules create fr-ilb-https \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=443,8443 \ --backend-service=be-ilb \ --backend-service-region=us-west1
API
Supprimez la règle de transfert en envoyant une requête DELETE
à la méthode forwardingRules.delete
.
DELETE https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules/fr-ilb
Créez une adresse IP interne statique (réservée) pour 10.1.2.99
et définissez son objectif sur SHARED_LOADBALANCER_VIP
en envoyant une requête POST
à la méthode addresses.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/addresses
{
"name": "internal-10-1-2-99",
"address": "10.1.2.99",
"prefixLength": 32,
"addressType": INTERNAL,
"purpose": SHARED_LOADBALANCER_VIP,
"subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet"
}
Créez deux règles de transfert en envoyant deux requêtes POST
à la méthode forwardingRules.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules
{
"name": "fr-ilb-http",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"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"
}
{
"name": "fr-ilb-https",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"443", "8443"
],
"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"
}
Tester le trafic avec la configuration multiport
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 sur les quatre ports :
curl http://10.1.2.99 curl http://10.1.2.99:8008 curl http://10.1.2.99:8080 curl http://10.1.2.99:8088
Testez la connectivité HTTPS sur les ports
443
et8443
. L'option--insecure
est obligatoire, car chaque serveur Apache dans l'exemple de configuration utilise un certificat autosigné.curl https://10.1.2.99 --insecure curl https://10.1.2.99:8443 --insecure
Remarquez que les requêtes HTTP (sur les quatre ports) et HTTPS (sur les deux ports) sont réparties entre 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 un hachage créé à partir des adresses IP du client et de l'adresse IP de la règle de transfert interne de l'équilibreur de charge.
Pour découvrir les types d'affinité de session compatibles, consultez la section Options d'affinité de session.
Console
- Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Accéder à la page "Équilibrage de charge" - Cliquez sur be-ilb (nom du service de backend que vous avez créé pour cet exemple), puis cliquez sur Modifier.
- Sur la page Modifier l'équilibreur de charge interne, cliquez sur Configuration du backend.
- Sélectionnez IP client dans le menu contextuel Affinité de session.
- Cliquez sur Mettre à jour.
gcloud
Exécutez la commande gcloud
suivante pour mettre à jour le service de backend be-ilb
, en spécifiant l'affinité de session basée sur les adresses IP client :
gcloud compute backend-services update be-ilb \ --region=us-west1 \ --session-affinity CLIENT_IP
API
Envoyez une requête PATCH
à la méthode regionBackendServices/patch
.
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/backendServices/be-ilb
{
"sessionAffinity": "CLIENT_IP"
}
Configurer une règle de suivi des connexions
Cette section explique comment mettre à jour le service de backend afin de modifier la règle de suivi des connexions par défaut de l'équilibreur de charge.
Une règle de suivi des connexions inclut les paramètres suivants :
gcloud
Exécutez la commande gcloud compute
backend-services
suivante pour mettre à jour la règle de suivi des connexions pour le service de backend :
gcloud compute backend-services update BACKEND_SERVICE \ --region=REGION \ --tracking-mode=TRACKING_MODE \ --connection-persistence-on-unhealthy-backends=CONNECTION_PERSISTENCE_BEHAVIOR \ --idle-timeout-sec=IDLE_TIMEOUT_VALUE
Remplacez les espaces réservés par des valeurs valides :
BACKEND_SERVICE
: le service de backend que vous mettez à jourREGION
: région du service de backend que vous mettez à jourTRACKING_MODE
: mode de suivi des connexions à utiliser pour les paquets entrants. Pour obtenir la liste des valeurs acceptées, consultez la section Mode de suivi.CONNECTION_PERSISTENCE_BEHAVIOR
: comportement de persistance des connexions lorsque les backends ne sont pas opérationnels. Pour obtenir la liste des valeurs acceptées, consultez la section Persistance des connexions sur les backends non opérationnels.IDLE_TIMEOUT_VALUE
: nombre de secondes pendant lesquelles une entrée de table de suivi des connexions doit être conservée après que l'équilibreur de charge a traité le dernier paquet correspondant à l'entrée.Vous ne pouvez modifier cette propriété que lorsque le suivi des connexions est inférieur à cinq tuples (c'est-à-dire, lorsque l'affinité de session est configurée pour être
CLIENT_IP
ouCLIENT_IP_PROTO
, et que le mode de suivi estPER_SESSION
).Le délai par défaut est 600 secondes (10 minutes). La valeur maximale du délai d'inactivité configurable est de 57 600 secondes (16 heures).
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.
Console
Ajouter le deuxième sous-réseau
- Dans Google Cloud Console, accédez à la page Réseaux VPC.
Accéder à la page "Réseaux VPC" - Cliquez sur Créer un réseau VPC.
- Cliquez sur
lb-network
. - Dans la section Sous-réseaux :
- Cliquez sur Ajouter un sous-réseau.
- Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
- Nom :
second-subnet
- Région :
us-west1
- Plage d'adresses IP :
10.5.6.0/24
- Cliquez sur Ajouter.
- Nom :
Ajouter la deuxième règle de transfert
- Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Accéder à la page "Équilibrage de charge" - Cliquez sur votre équilibreur de charge
be-ilb
, puis sur Modifier. - Cliquez sur Configuration du frontend.
- Cliquez sur Ajouter une adresse IP et un port frontend.
- Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
- Nom :
fr-ilb-2
- Version IP : IPv4
- Sous-réseau :
second-subnet
- Dans le champ Adresse IP interne, sélectionnez
ip-ilb
. - Ports : 80, 443
- Cliquez sur OK.
- Vérifiez qu'une coche bleue apparaît à côté de Configuration de l'interface avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.
- Nom :
- Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.
- Cliquez sur Create (Créer).
gcloud
Créez un deuxième sous-réseau sur le réseau
lb-network
, dans la régionus-west1
:gcloud compute networks subnets create second-subnet \ --network=lb-network \ --range=10.5.6.0/24 \ --region=us-west1
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
API
Envoyez une requête POST
à la méthode subnetworks.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/subnetworks
{
"name": "second-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
"ipCidrRange": "10.5.6.0/24",
"privateIpGoogleAccess": false
}
Créez la règle de transfert en envoyant une requête POST
à la méthode forwardingRules.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/forwardingRules
{
"name": "fr-ilb-2",
"IPAddress": "10.5.6.99",
"IPProtocol": "TCP",
"ports": [
"80", "443"
],
"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"
}
Tester la nouvelle règle de transfert
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.
Utiliser le sous-paramètre de backend
L'exemple de configuration crée un service de backend sans sous-paramètre.
Cette procédure vous montre comment activer le sous-paramètre sur le service de backend pour l'exemple d'équilibreur de charge TCP/UDP interne afin que le déploiement puisse évoluer vers un plus grand nombre d'instances backend.
Vous ne devez activer le sous-paramètre que si vous devez accepter plus de 250 VM de backend sur un seul équilibreur de charge.
Pour en savoir plus sur ce cas d'utilisation, consultez la section Sous-paramètre du backend.
gcloud
Utilisez la commande gcloud
suivante pour mettre à jour le service de backend be-ilb
, en spécifiant la règle de sous-paramètre :
gcloud compute backend-services update be-ilb \ --subsetting-policy=CONSISTENT_HASH_SUBSETTING
API
Envoyez une requête PATCH
à la méthode regionBackendServices/patch
.
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID
/regions/us-west1/backendServices/be-ilb
{
"subsetting":
{
"policy": CONSISTENT_HASH_SUBSETTING
}
}
Créer un équilibreur de charge pour la mise en miroir de paquets
La mise en miroir de paquets vous permet de copier et de collecter des données de paquets à partir d'instances spécifiques dans un VPC. Les données collectées peuvent vous permettre de détecter les menaces de sécurité et de surveiller les performances des applications.
La mise en miroir de paquets nécessite un équilibreur de charge TCP/UDP interne pour équilibrer le trafic vers un groupe d'instances de destinations de collecteur. Pour créer un équilibreur de charge TCP/UDP interne pour la mise en miroir de paquets, procédez comme suit :
Console
Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Cliquez sur Créer un équilibreur de charge.
Dans la section Équilibrage de charge TCP, cliquez sur Démarrer la configuration.
Dans la section Web ou interne uniquement, sélectionnez Seulement entre les VM, puis cliquez sur Continuer.
Sur la page Nouvel équilibreur de charge interne:
- Indiquez un Nom.
- Dans le champ Région, sélectionnez la région des instances de VM dans lesquelles vous souhaitez mettre en miroir les paquets.
- Pour Réseau, sélectionnez le réseau sur lequel vous souhaitez mettre en miroir les paquets.
Sélectionnez Configuration du backend.
Dans le volet Configuration du backend, cliquez sur Groupe d'instances, puis sélectionnez un groupe d'instances vers lequel transférer les paquets.
Cliquez sur Vérification d'état, puis sur Créer une vérification d'état.
Sur la page Vérification de l'état:
- Saisissez un nom.
- Pour Protocole, sélectionnez HTTP.
- Dans la section Port, saisissez
80
. - Cliquez sur Enregistrer.
Cliquez sur Configuration de l'interface.
Dans le volet Configuration du frontend:
- Cliquez sur Sous-réseau et sélectionnez un sous-réseau dans la même région que les instances à mettre en miroir.
- Dans la section Ports, sélectionnez Tous.
- Cliquez sur Configurations avancées.
- Cochez la case Activer cet équilibreur de charge pour la mise en miroir de paquets.
- Cliquez sur OK.
Cliquez sur Create (Créer).
gcloud
Créez une vérification d'état HTTP régionale pour tester la connectivité HTTP à un groupe d'instances sur le port 80:
gcloud compute health-checks create http HEALTH_CHECK_NAME \ --region=REGION \ --port=80
Remplacez les éléments suivants :
HEALTH_CHECK_NAME
: nom de la vérification d'état.REGION
: région des instances de VM pour lesquelles vous souhaitez mettre en miroir les paquets.
Créez un service de backend pour le trafic HTTP:
gcloud compute backend-services create COLLECTOR_BACKEND_SERVICE \ --region=REGION \ --health-checks-region=REGION \ --health-checks=HEALTH_CHECK_NAME \ --load-balancing-scheme=internal \ --protocol=tcp
Remplacez les éléments suivants :
COLLECTOR_BACKEND_SERVICE
: nom du service de backend.REGION
: région des instances de VM dans lesquelles vous souhaitez mettre en miroir les paquets.HEALTH_CHECK_NAME
: nom de la vérification d'état.
Ajoutez un groupe d'instances au service de backend:
gcloud compute backend-services add-backend COLLECTOR_BACKEND_SERVICE \ --region=REGION \ --instance-group=INSTANCE_GROUP \ --instance-group-zone=ZONE
Remplacez les éléments suivants :
COLLECTOR_BACKEND_SERVICE
: nom du service de backend.REGION
: région du groupe d'instances.INSTANCE_GROUP
: nom du groupe d'instances.ZONE
: zone du groupe d'instances.
Créez une règle de transfert pour le service de backend.
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --region=REGION \ --network=NETWORK \ --subnet=SUBNET \ --backend-service=COLLECTOR_BACKEND_SERVICE \ --load-balancing-scheme=internal \ --ip-protocol=TCP \ --ports=all \ --is-mirroring-collector
Remplacez les éléments suivants :
FORWARDING_RULE_NAME
: nom de la règle de transfert.REGION
: région de la règle de transfert.NETWORK
: réseau pour la règle de transfert.SUBNET
: sous-réseau dans la région des VM sur lesquelles vous souhaitez mettre en miroir les paquets.COLLECTOR_BACKEND_SERVICE
: service de backend pour cet équilibreur de charge.
Étapes suivantes
- Consultez la page Concepts d'équilibrage de charge TCP/UDP interne pour les principes de base importants.
- Pour plus d'informations sur le basculement, consultez la page Concepts de basculement pour l'équilibrage de charge TCP/UDP interne.
- Pour les options de noms DNS disponibles que votre équilibreur de charge peut utiliser, consultez la page Équilibrage de charge interne et noms DNS.
- Pour obtenir les étapes de configuration, ainsi qu'un exemple de configuration de basculement d'équilibreur de charge TCP/UDP interne, consultez la page Configurer le basculement pour l'équilibrage de charge TCP/UDP interne.
- Pour plus d'informations sur la configuration de la journalisation et de la surveillance pour l'équilibrage de charge TCP/UDP interne, consultez la page Surveillance de l'équilibrage de charge TCP/UDP interne.
- Pour plus d'informations sur l'accès aux équilibreurs de charge TCP/UDP internes à partir de réseaux pairs connectés à votre VPC, consultez la page Équilibrage de charge TCP/UDP interne et réseaux connectés.
- Pour plus d'informations sur la résolution des problèmes liés à votre équilibreur de charge TCP/UDP interne, consultez la page Résoudre les problèmes liés à l'équilibrage de charge interne TCP/UDP.
- Nettoyez la configuration de l'équilibreur de charge.