Dans Google Cloud, vous pouvez intégrer des dispositifs tiers à disponibilité élevée de manière évolutive. Pour ce faire, vous devez configurer une route statique personnalisée et définir son saut suivant sur l'équilibreur de charge réseau interne à stratégie directe de Google Cloud. L'équilibreur de charge peut ainsi équilibrer la charge du trafic d'un préfixe de destination vers un pool de dispositifs de VM tiers dont l'état a été vérifié.
Ce guide utilise un exemple pour vous apprendre à configurer un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant. Avant de suivre ce guide, familiarisez-vous avec les points suivants :
- Concepts de l'équilibreur de charge réseau à stratégie interne
- Équilibreurs de charge réseau internes à stratégie directe en tant que sauts suivants
Autorisations
Pour suivre ce guide, vous devez créer des instances et modifier un réseau dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer de tous les rôles IAM Compute Engine suivants :
Tâche | Rôle requis |
---|---|
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge | Administrateur réseau |
Ajouter et supprimer des règles de pare-feu | Administrateur de sécurité |
Créer des instances | Administrateur d'instances Compute |
Pour en savoir plus, consultez les guides suivants :
- Access control (Contrôle des accès)
- Conditions IAM
Configurer des équilibreurs de charge réseau internes à stratégie directe comme sauts suivants avec des backends communs
Ce guide vous explique comment utiliser un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant pour une route statique personnalisée afin d'intégrer des dispositifs virtuels soumis à un scaling horizontal.
La solution décrite dans ce guide crée des VM de dispositifs exécutant Debian Linux. Les exemples de VM n'effectuent aucun filtrage de paquets, mais vous pouvez ajouter cette fonctionnalité en modifiant la configuration du réseau de cet exemple ou en utilisant différents logiciels de filtrage ou de routage des paquets.
La procédure décrite dans cette section explique comment configurer les ressources suivantes :
- Exemples de réseaux VPC et de sous-réseaux personnalisés
- Règles de pare-feu Google Cloud autorisant les connexions entrantes vers les machines virtuelles (VM) de dispositifs de backend
- Routes statiques personnalisées
- Deux VM clientes pour tester les connexions
- Les composants de l'équilibreur de charge réseau interne à stratégie directe suivants :
- VM de backend dans un groupe d'instances géré
- Vérification d'état des VM de backend
- Service de backend interne dans la région
us-west1
pour gérer la distribution des connexions entre les VM de backend - Règle de transfert interne et adresse IP interne pour l'interface de l'équilibreur de charge
Cet exemple illustre l'équilibrage de charge sur plusieurs cartes d'interface réseau, comme décrit dans la section Équilibrage de charge sur plusieurs cartes d'interface réseau.
La topologie se présente comme suit :
Le schéma illustre certaines des ressources créées par l'exemple :
- Instances d'application derrière un équilibreur de charge réseau interne à stratégie directe (
fr-ilb1
, dans cet exemple). Les instances d'application ne disposent que d'adresses IP internes - Pour chaque instance d'application, l'option
can-ip-forward
est activée. Sans cette option, une VM Compute Engine ne peut transmettre un paquet que si son adresse IP source correspond à l'adresse IP interne de la VM, à l'adresse IP d'une plage d'adresses IP d'alias ou à l'adresse IP d'une règle de transfert qui renvoie vers la VM. L'optioncan-ip-forward
modifie ce comportement de sorte que la VM puisse transmettre des paquets avec n'importe quelle adresse IP source. - Une route statique personnalisée avec la destination
10.50.1.0/24
et le saut suivant défini sur la règle de transfert de l'équilibreur de charge,fr-ilb1
.
Le schéma montre également le flux de trafic :
- Le réseau VPC
testing
dispose d'une route statique personnalisée pour le trafic qui est destiné au sous-réseau10.50.1.0/24
. Cette route achemine le trafic vers l'équilibreur de charge. - L'équilibreur de charge transfère le trafic vers l'une des instances d'application en fonction de l'affinité de session configurée. (L'affinité de session n'affecte que le trafic TCP.)
Pour les autres cas d'utilisation, consultez la section Équilibreurs de charge TCP/UDP internes en tant que sauts suivants.
Configurer les réseaux, la région et les sous-réseaux
Cet exemple utilise les réseaux VPC, la région et les sous-réseaux suivants :
Réseaux : cet exemple nécessite deux réseaux, chacun avec au moins un sous-réseau. Chaque VM de dispositif tiers de backend doit disposer d'au moins deux interfaces réseau, une par réseau VPC. Dans cet exemple, les réseaux sont des réseaux VPC en mode personnalisé nommés
testing
etproduction
. Le réseautesting
de cet exemple contient le client et l'équilibreur de charge. Le réseauproduction
contient la VM cible de destination.Région : les sous-réseaux sont situés dans la région
us-west1
. Les sous-réseaux doivent se trouver dans la même région, car les instances de VM sont des ressources zonales.Sous-réseaux : les sous-réseaux
testing-subnet
etproduction-subnet
utilisent respectivement les plages d'adresses IP principales10.30.1.0/24
et10.50.1.0/24
.
Pour créer les exemples de réseaux et de sous-réseaux, procédez comme suit.
Console
Créez le réseau testing
et le sous-réseau testing-subnet
:
Dans Google Cloud Console, accédez à la page Réseaux VPC.
Cliquez sur Créer un réseau VPC.
Saisissez le nom
testing
.Dans la section Sous-réseaux :
- Définissez Mode de création du sous-réseau sur Personnalisé.
- Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
- Nom :
testing-subnet
- Région :
us-west1
- Plage d'adresses IP :
10.30.1.0/24
- Cliquez sur OK.
- Nom :
Cliquez sur Créer.
Créez le réseau production
et le sous-réseau production-subnet
:
Dans Google Cloud Console, accédez à la page Réseaux VPC.
Cliquez sur Créer un réseau VPC.
Saisissez le nom
production
.Dans la section Sous-réseaux :
- Définissez Mode de création du sous-réseau sur Personnalisé.
- Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
- Nom :
production-subnet
- Région :
us-west1
- Plage d'adresses IP :
10.50.1.0/24
- Cliquez sur OK.
- Nom :
Cliquez sur Créer.
gcloud
Créez les réseaux VPC personnalisés :
gcloud compute networks create testing --subnet-mode=custom
gcloud compute networks create production --subnet-mode=custom
Créez des sous-réseaux sur les réseaux
testing
etproduction
de la régionus-west1
:gcloud compute networks subnets create testing-subnet \ --network=testing \ --range=10.30.1.0/24 \ --region=us-west1
gcloud compute networks subnets create production-subnet \ --network=production \ --range=10.50.1.0/24 \ --region=us-west1
Configurer les règles de pare-feu
Cet exemple utilise les règles de pare-feu suivantes :
fw-allow-testing-from-both
: règle d'entrée applicable à toutes les cibles du réseautesting
. Cette règle autorise le trafic provenant de sources comprises dans les plages d'adresses IP10.30.1.0/24
et10.50.1.0/24
. Ces deux plages couvrent les adresses IP internes principales des VM dans les deux réseaux.fw-allow-production-from-both
: règle d'entrée applicable à toutes les cibles du réseauproduction
. Cette règle autorise le trafic provenant de sources comprises dans les plages d'adresses IP10.30.1.0/24
et10.50.1.0/24
. Ces deux plages couvrent les adresses IP internes principales des VM dans les deux réseaux.fw-allow-testing-ssh
: règle d'entrée appliquée aux instances de VM dans le réseau VPCtesting
. Cette règle autorise la connectivité SSH entrante sur le port TCP22
à partir de n'importe quelle adresse. Vous pouvez choisir une plage d'adresses IP source plus restrictive pour cette règle. Par exemple, vous pouvez spécifier les plages d'adresses IP des systèmes à partir desquels vous prévoyez de lancer des sessions SSH. Cet exemple utilise le tag cibleallow-ssh
pour identifier les VM auxquelles la règle de pare-feu s'applique.fw-allow-production-ssh
: règle d'entrée appliquée aux instances de VM dans le réseau VPCproduction
. Cette règle autorise la connectivité SSH entrante sur le port TCP22
à partir de n'importe quelle adresse. Tout comme la règlefw-allow-testing-ssh
, vous pouvez choisir une plage d'adresses IP sources plus restrictive pour cette règle.fw-allow-health-check
: règle d'entrée pour les VM de dispositifs tiers qui font l'objet d'un équilibrage de charge. Cette règle autorise le trafic provenant des systèmes de vérification d'état Google Cloud (130.211.0.0/22
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-production-health-check
: règle d'entrée pour les VM de dispositifs tiers qui font l'objet d'un équilibrage de charge. Cette règle autorise le trafic provenant des systèmes de vérification d'état Google Cloud (130.211.0.0/22
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. Vous devez créer une règle de pare-feu pour autoriser les vérifications d'état à partir des plages d'adresses IP des systèmes de vérification Google Cloud. Pour plus d'informations, reportez-vous aux plages d'adresses IP de vérification.
Console
Dans la console Google Cloud, accédez à la page Règles d'administration.
Cliquez sur Créer une règle de pare-feu et saisissez les informations suivantes pour créer la règle permettant aux VM de test de recevoir des paquets des sous-réseaux de test et de production :
- Nom :
fw-allow-testing-from-both
- Réseau :
testing
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : toutes les instances du réseau
- Filtre source : Plages IPv4
- Plages IPv6 sources :
10.30.1.0/24
,10.50.1.0/24
- Protocoles et ports : tout autoriser
- Nom :
Cliquez sur Create (Créer).
Cliquez sur Créer une règle de pare-feu et saisissez les informations suivantes pour créer la règle permettant aux VM de production de recevoir des paquets des sous-réseaux de test et de production :
- Nom :
fw-allow-production-from-both
- Réseau :
production
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : toutes les instances du réseau
- Filtre source : Plages IPv4
- Plages IPv6 sources :
10.30.1.0/24
,10.50.1.0/24
- Protocoles et ports : tout autoriser
- Nom :
Cliquez sur Create (Créer).
Cliquez sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes dans l'environnement de test :
- Nom :
fw-allow-testing-ssh
- Réseau :
testing
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : tags cibles spécifiés
- Tags cibles :
allow-ssh
- Filtre source : Plages IPv4
- Plages IPv4 sources :
0.0.0.0/0
- Protocoles et ports : sélectionnez Protocoles et ports spécifiés, et saisissez :
tcp:22
- 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 dans l'environnement de production :
- Nom :
fw-allow-production-ssh
- Réseau :
production
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : tags cibles spécifiés
- Tags cibles :
allow-ssh
- Filtre source : Plages IPv4
- Plages IPv4 sources :
0.0.0.0/0
- Protocoles et ports : sélectionnez Protocoles et ports spécifiés, et saisissez :
tcp:22
- Nom :
Cliquez sur Create (Créer).
Cliquez sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud dans l'environnement de test :
- Nom :
fw-allow-health-check
- Réseau :
testing
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : tags cibles spécifiés
- Tags cibles :
allow-health-check
- Filtre source : Plages IPv4
- Plages IPv4 sources :
130.211.0.0/22
et35.191.0.0/16
- Protocoles et ports :
tcp
- 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 vérifications d'état Google Cloud dans l'environnement de production :
- Nom :
fw-allow-production-health-check
- Réseau :
production
- Priorité :
1000
- Sens du trafic : entrée
- Action en cas de correspondance : autoriser
- Cibles : tags cibles spécifiés
- Tags cibles :
allow-health-check
- Filtre source : Plages IPv4
- Plages IPv4 sources :
130.211.0.0/22
et35.191.0.0/16
- Protocoles et ports :
tcp
- Nom :
Cliquez sur Create (Créer).
gcloud
Créez la règle de pare-feu
fw-allow-testing-subnet
pour permettre aux VM de test de recevoir des paquets des sous-réseauxtesting
etproduction
:gcloud compute firewall-rules create fw-allow-testing-from-both \ --network=testing \ --action=allow \ --direction=ingress \ --source-ranges=10.30.1.0/24,10.50.1.0/24 \ --rules=all
Créez la règle de pare-feu
fw-allow-production-subnet
pour permettre aux VM de production de recevoir des paquets des sous-réseauxtesting
etproduction
:gcloud compute firewall-rules create fw-allow-production-from-both \ --network=production \ --action=allow \ --direction=ingress \ --source-ranges=10.30.1.0/24,10.50.1.0/24 \ --rules=all
Créez la règle de pare-feu
fw-allow-testing-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-testing-ssh \ --network=testing \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Créez la règle de pare-feu
fw-allow-production-ssh
pour autoriser la connectivité SSH aux VM avec le tag réseauallow-ssh
.gcloud compute firewall-rules create fw-allow-production-ssh \ --network=production \ --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 sur les VM de dispositifs tiers du réseautesting
.gcloud compute firewall-rules create fw-allow-testing-health-check \ --network=testing \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp
Créez la règle de pare-feu
fw-allow-production-health-check
pour autoriser les vérifications d'état Google Cloud sur les VM de dispositifs tiers du réseauproduction
.gcloud compute firewall-rules create fw-allow-production-health-check \ --network=production \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp
Créer les dispositifs virtuels tiers
Les étapes suivantes vous expliquent comment créer un modèle d'instance et un groupe d'instances régional géré avec plusieurs interfaces réseau. Ce groupe d'instances est utilisé comme dispositif virtuel tiers pour cet exemple.
Console
Vous devez utiliser gcloud
pour cette étape, car vous devez créer un modèle d'instance avec plusieurs interfaces réseau. Pour le moment, la console Google Cloud n'accepte pas la création de modèles d'instance avec plusieurs interfaces réseau.
gcloud
Créez un fichier local appelé
config.sh
et insérez le contenu suivant :#!/bin/bash # Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf # Read VM network configuration: md_vm="http://metadata.google.internal/computeMetadata/v1/instance/" md_net="$md_vm/network-interfaces" nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )" nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")" nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")" nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')" nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")" nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")" nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")" nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')" # Source based policy routing for nic1 echo "100 rt-nic1" >> /etc/iproute2/rt_tables sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1 sleep 1 sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1 sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1 # Use a web server to pass the health check for this example. # You should use a more complete test in production. sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl echo "Example web page to pass health check" | \ tee /var/www/html/index.html sudo systemctl restart apache2
Créez un modèle d'instance pour vos dispositifs virtuels tiers. Le modèle d'instance doit inclure l'option
--can-ip-forward
afin que les instances de VM créées à partir du modèle puissent transférer des paquets à partir d'autres instances sur les réseauxtesting
etproduction
.gcloud compute instance-templates create third-party-template-multinic \ --region=us-west1 \ --network-interface subnet=testing-subnet,address="" \ --network-interface subnet=production-subnet \ --tags=allow-ssh,allow-health-check,my-network-tag \ --image-family=debian-10 \ --image-project=debian-cloud \ --can-ip-forward \ --metadata=startup-script="$(< config.sh)"
Créez un groupe d'instances géré pour vos dispositifs virtuels tiers. Cette commande crée un groupe d'instances régional géré, qui peut ensuite faire l'objet d'un autoscaling dans
us-west1
.gcloud compute instance-groups managed create third-party-instance-group \ --region=us-west1 \ --template=third-party-template-multinic \ --size=3
Créer les ressources d'équilibrage de charge
Ces étapes permettent de configurer tous les composants de l'équilibreur de charge réseau interne à stratégie directe, en commençant par la vérification d'état et le service de backend, puis en passant aux composants d'interface :
Vérification de l'état : dans cet exemple, la vérification de l'état HTTP recherche une réponse HTTP
200
(OK). Pour plus d'informations, consultez la section sur les vérifications d'état de la présentation de l'équilibreur de charge réseau interne à stratégie directe.Service de backend : même si le service de backend de cet exemple spécifie le protocole TCP, lorsque l'équilibreur de charge est le saut suivant d'une route, Google Cloud transfère le trafic vers tous les protocoles (TCP, UDP et ICMP).
Règle de transfert : même si cet exemple de règle de transfert spécifie le port TCP 80, lorsque l'équilibreur de charge est le saut suivant pour une route, le trafic sur tout port TCP ou UDP est envoyé aux backends de l'équilibreur de charge.
Adresse IP interne : l'exemple indique une adresse IP interne,
10.30.1.99
, pour la règle de transfert.
Console
Démarrer la configuration
Dans Google Cloud Console, accédez à la page Équilibrage de charge.
- Cliquez sur Créer un équilibreur de charge.
- Sous Type d'équilibreur de charge, sélectionnez Équilibreur de charge réseau (TCP/UDP/SSL), puis cliquez sur Suivant.
- Pour Proxy ou passthrough, sélectionnez Équilibreur de charge passthrough, puis cliquez sur Suivant.
- Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
- Cliquez sur Configurer.
Créer le premier équilibreur de charge
- Définissez le paramètre Nom sur
ilb1
. - Définissez la région sur
us-west1
: - Définissez le paramètre Réseau sur
testing
. - Cliquez sur Configuration du backend et apportez les modifications suivantes :
- Sous Backends, dans la section Nouvel élément, sélectionnez le groupe d'instances
third-party-instance-group
et cliquez sur OK. - Sous Vérification d'état, sélectionnez Créer une autre vérification d'état, saisissez les informations suivantes, puis cliquez sur Enregistrer et continuer :
- Nom :
hc-http-80
- Protocole :
HTTP
- Port :
80
- Protocole de proxy :
NONE
- Chemin de requête :
/
Notez que lorsque vous créez un équilibreur de charge à l'aide de la console Google Cloud, la vérification de l'état est globale. Si vous souhaitez créer une vérification de l'état régionale, utilisezgcloud
ou l'API.
- Nom :
- Sous Affinité de session, sélectionnez IP client.
- Vérifiez qu'une coche bleue apparaît à côté de Configuration du backend avant de continuer. Répétez cette étape si ce n'est pas le cas.
- Sous Backends, dans la section Nouvel élément, sélectionnez le groupe d'instances
- Cliquez sur Configuration du frontend. Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
- Nom :
fr-ilb1
- Sous-réseau :
testing-subnet
- Dans Adresse IP interne, sélectionnez Réserver une adresse IP statique interne, saisissez les informations suivantes, puis cliquez sur Réserver :
- Nom :
ip-ilb
- Adresse IP statique : Laissez-moi choisir
- Adresse IP personnalisée :
10.30.1.99
- Nom :
- Ports : sélectionnez Unique et saisissez
80
pour le numéro de port. N'oubliez pas que le choix d'un protocole et d'un port pour l'équilibreur de charge ne limite pas les protocoles et les ports utilisés lorsque l'équilibreur de charge est le saut suivant d'une route. - Vérifiez qu'une coche bleue apparaît à côté de Configuration du frontend avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.
- Nom :
- Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.
- Cliquez sur Créer.
Démarrer la configuration
Dans Google Cloud Console, accédez à la page Équilibrage de charge.
- Cliquez sur Créer un équilibreur de charge.
- Sous Type d'équilibreur de charge, sélectionnez Équilibreur de charge réseau (TCP/UDP/SSL), puis cliquez sur Suivant.
- Pour Proxy ou passthrough, sélectionnez Équilibreur de charge passthrough, puis cliquez sur Suivant.
- Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
- Cliquez sur Configurer.
Créer le deuxième équilibreur de charge
- Définissez le paramètre Nom sur
ilb2
. - Définissez la région sur
us-west1
: - Définissez le paramètre Réseau sur
production
. - Cliquez sur Configuration du backend et apportez les modifications suivantes :
- Sous Backends, dans la section Nouvel élément, sélectionnez le groupe d'instances
third-party-instance-group
et cliquez sur OK. - Pour Vérification d'état, sélectionnez
hc-http-80
. - Sous Affinité de session, sélectionnez IP client.
- Vérifiez qu'une coche bleue apparaît à côté de Configuration du backend avant de continuer. Répétez cette étape si ce n'est pas le cas.
- Sous Backends, dans la section Nouvel élément, sélectionnez le groupe d'instances
- Cliquez sur Configuration du frontend. Dans la section Nouveaux IP et port frontend, apportez les modifications suivantes :
- Nom :
fr-ilb2
- Sous-réseau :
production-subnet
- Dans Adresse IP interne, sélectionnez Réserver une adresse IP statique interne, saisissez les informations suivantes, puis cliquez sur Réserver :
- Nom :
ip-ilb2
- Adresse IP statique : Laissez-moi choisir
- Adresse IP personnalisée :
10.50.1.99
- Nom :
- Ports : sélectionnez Unique et saisissez
80
pour le numéro de port. N'oubliez pas que le choix d'un protocole et d'un port pour l'équilibreur de charge ne limite pas les protocoles et les ports utilisés lorsque l'équilibreur de charge est le saut suivant d'une route. - Vérifiez qu'une coche bleue apparaît à côté de Configuration du frontend avant de continuer. Reprenez la procédure depuis le début si ce n'est pas le cas.
- Nom :
- Cliquez sur Vérifier et finaliser. Vérifiez vos paramètres.
Cliquez sur Create (Créer).
Configurez les ressources de l'équilibreur de charge dans le réseau VPC
production
.
gcloud
Créez une vérification d'état HTTP pour tester la connectivité TCP aux VM sur le port 80.
gcloud compute health-checks create http hc-http-80 \ --region=us-west1 \ --port=80
Créez deux services de backend internes dans la région
us-west1
.gcloud compute backend-services create ilb1 \ --load-balancing-scheme=internal \ --health-checks-region=us-west1 \ --health-checks=hc-http-80 \ --region=us-west1 \ --network=testing \ --session-affinity=CLIENT_IP
gcloud compute backend-services create ilb2 \ --load-balancing-scheme=internal \ --health-checks-region=us-west1 \ --health-checks=hc-http-80 \ --region=us-west1 \ --network=production \ --session-affinity=CLIENT_IP
Ajoutez les groupes d'instances contenant les dispositifs virtuels tiers en tant que serveurs de backend sur les services de backend.
gcloud compute backend-services add-backend ilb1 \ --instance-group=third-party-instance-group \ --instance-group-region=us-west1 \ --region=us-west1
gcloud compute backend-services add-backend ilb2 \ --instance-group=third-party-instance-group \ --instance-group-region=us-west1 \ --region=us-west1
Créez les règles de transfert internes et connectez-les aux services de backend pour terminer la configuration de l'équilibreur de charge. N'oubliez pas que le protocole (TCP) et le port (80) des équilibreurs de charge ne limitent pas les ports et protocoles transférés aux instances backend (dispositifs virtuels tiers) lors du chargement. Les équilibreurs de charge sont utilisés comme sauts suivants des routes.
gcloud compute forwarding-rules create fr-ilb1 \ --load-balancing-scheme=internal \ --ports=80 \ --network=testing \ --subnet=testing-subnet \ --region=us-west1 \ --backend-service=ilb1 \ --address=10.30.1.99
gcloud compute forwarding-rules create fr-ilb2 \ --load-balancing-scheme=internal \ --ports=80 \ --network=production \ --subnet=production-subnet \ --region=us-west1 \ --backend-service=ilb2 \ --address=10.50.1.99
Créer les routes statiques qui définissent les équilibreurs de charge en tant que sauts suivants
Créez deux routes statiques personnalisées intitulées next-hop-ilb
.
Console
Créer la première route
Dans Google Cloud Console, accédez à la page Routes.
Cliquez sur Créer une route.
Dans le champ Nom de la route, saisissez
ilb-nhop-dest-10-50-1
.Sélectionnez le réseau
testing
.Pour la plage d'adresses IP de destination, saisissez
10.50.1.0/24
.Dans le champ Tags d'instance, saisissez
my-network-tag
.Pour le saut suivant de la route, sélectionnez Spécifier une règle de transfert pour l'équilibreur de charge TCP/UDP interne.
Pour spécifier l'adresse IP de l'équilibreur de charge en tant que saut suivant, utilisez gcloud CLI ou l'API.
Spécifiez le nom de la règle de transfert. Pour le nom de la règle de transfert, sélectionnez
fr-ilb1
.Cliquez sur Create (Créer).
Créer la deuxième route
- Cliquez sur Créer une route.
- Dans le champ Nom de la route, saisissez
ilb-nhop-dest-10-30-1
. - Sélectionnez le réseau
testing
. - Pour la plage d'adresses IP de destination, saisissez
10.30.1.0/24
. Pour le saut suivant de la route, sélectionnez Spécifier une règle de transfert pour l'équilibreur de charge TCP/UDP interne.
Pour spécifier l'adresse IP de l'équilibreur de charge en tant que saut suivant, utilisez gcloud CLI ou l'API.
Pour le nom de la règle de transfert, sélectionnez
fr-ilb2
.Cliquez sur Créer.
gcloud
Créez des routes avancées en définissant le saut suivant sur chaque règle de transfert de l'équilibreur de charge, et en définissant chaque plage de destination en conséquence.
Pour l'option --next-hop-ilb
, vous pouvez spécifier le nom de la règle de transfert ou l'adresse IP. Si vous spécifiez l'adresse IP, celle-ci peut être apprise entre les pairs sans avoir à exporter la route personnalisée. Dans cet exemple, la première route utilise l'adresse IP 10.30.1.99
et la deuxième route le nom de règle de transfert fr-ilb12
.
Vous pouvez éventuellement spécifier un ou plusieurs tags d'instance sur la route.
La route peut s'appliquer à des VM spécifiques si vous spécifiez des tags réseau sur la route. Si vous ne spécifiez aucun tag réseau, la route s'applique à toutes les VM du réseau VPC. Dans cet exemple, la route utilise my-network-tag
comme tag réseau.
gcloud compute routes create ilb-nhop-dest-10-50-1 \ --network=testing \ --destination-range=10.50.1.0/24 \ --next-hop-ilb=10.30.1.99 \ --tags=my-network-tag
gcloud compute routes create ilb-nhop-dest-10-30-1 \ --network=production \ --destination-range=10.30.1.0/24 \ --next-hop-ilb=fr-ilb2 \ --next-hop-ilb-region=us-west1
Créer l'instance de VM testing
Cet exemple crée une instance de VM avec l'adresse IP 10.30.1.100
sur le sous-réseau testing-subnet
(10.30.1.0/24
) du réseau VPC testing
.
gcloud
Créez la VM
testing-vm
en exécutant la commande suivante.gcloud compute instances create testing-vm \ --zone=us-west1-a \ --image-family=debian-10 \ --image-project=debian-cloud \ --tags=allow-ssh,my-network-tag \ --subnet=testing-subnet \ --private-network-ip 10.30.1.100 \ --metadata=startup-script='#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html sudo systemctl restart apache2'
Créer l'instance de VM production
Cet exemple crée une instance de VM avec l'adresse IP 10.50.1.100
sur le sous-réseau production-subnet
(10.50.1.0/24
) du réseau VPC production
.
gcloud
La VM production-vm
peut se trouver dans n'importe quelle zone de la même région que l'équilibreur de charge, et utiliser n'importe quel sous-réseau de cette région. Dans cet exemple, la VM production-vm
se trouve dans la zone us-west1-a
.
Créez la VM
production-vm
en exécutant la commande suivante.gcloud compute instances create production-vm \ --zone=us-west1-a \ --image-family=debian-10 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=production-subnet \ --private-network-ip 10.50.1.100 \ --metadata=startup-script='#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html sudo systemctl restart apache2'
Tester l'équilibrage de charge sur un déploiement à cartes d'interface réseau multiples
Vérifiez l'état des backends de l'équilibreur de charge.
gcloud compute backend-services get-health ilb1 --region us-west1
gcloud compute backend-services get-health ilb2 --region us-west1
Testez la connectivité à partir de la VM
testing
.gcloud compute ssh testing-vm --zone=us-west1-a
curl http://10.50.1.99
exit
Testez la connectivité à partir de la VM
production
.gcloud compute ssh production-vm --zone=us-west1-a
curl http://10.30.1.99
exit
Activer le hachage symétrique
Lors du calcul du hachage mappé à l'instance backend, Google Cloud ignore la direction des adresses IP et des ports. La valeur de hachage cohérente d'un paquet TCP/UDP est identique, quelle que soit la direction d'origine du paquet. C'est ce qu'on appelle le hachage symétrique.
Pour activer ce comportement de hachage sur les équilibreurs de charge réseau internes existants, vous devez recréer la règle de transfert et la route de saut suivant.
Pour en savoir plus, consultez la section Hachage symétrique.
Supprimer et recréer des règles de transfert
Console
Supprimer une règle de transfert et en créer une nouvelle
Dans Google Cloud Console, accédez à la page Équilibrage de charge.
Cliquez sur votre équilibreur de charge
be-ilb
, puis sur Modifier.Cliquez sur Frontend configuration (Configuration du frontend).
Gardez le pointeur de la souris sur votre règle de transfert, puis cliquez sur
Supprimer pour la supprimer.Cliquez sur Ajouter une adresse IP et un port frontend.
Dans la section Nouveaux IP et port d'interface, apportez les modifications suivantes :
- Nom :
FORWARDING_RULE_NAME
- Sous-réseau :
SUBNET_NAME
- Dans le champ Adresse IP interne, sélectionnez
IP_ADDRESS
. - Ports :
PORT_NUMBER
ouALL
. - 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 vos règles de transfert existantes.
gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \ --region=REGION
Créez des règles de transfert de remplacement portant le même nom.
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --load-balancing-scheme=internal \ --ports=PORT_NUMBER or `ALL` \ --network=NETWORK_NAME \ --subnet=SUBNET_NAME \ --region=REGION \ --backend-service=BACKEND_SERVICE_NAME \ --address=IP_ADDRESS
Lorsque la SNAT n'est pas requise
Comme illustré dans l'exemple précédent, la traduction d'adresse réseau source (SNAT) n'est pas requise lorsque toutes les conditions suivantes sont remplies :
- La règle de transfert de l'équilibreur de charge réseau interne à stratégie directe a été créée le 22 juin 2021 ou après cette date.
- La route statique personnalisée faisant référence à la règle de transfert a été créée le 22 juin 2021 ou après cette date.
- Le service de backend de l'équilibreur de charge réseau interne à stratégie directe n'utilise pas le paramètre d'affinité de session
NONE
.
Pour convertir la route existante d'un équilibreur de charge réseau interne à stratégie directe de saut suivant afin d'utiliser le hachage symétrique, procédez comme suit :
Assurez-vous que le service de backend de l'équilibreur de charge réseau interne à stratégie directe n'utilise pas le paramètre d'affinité de session
NONE
.Créez une règle de transfert de remplacement qui référence le même service de backend. La règle de transfert de remplacement utilise une adresse IP différente.
Créez une route statique personnalisée de remplacement faisant référence à la nouvelle règle de transfert. Assurez-vous que cette route de remplacement a une priorité plus élevée que la route existante.
Supprimez la route existante de priorité inférieure (qui référence à la règle de transfert précédente), puis supprimez la règle de transfert précédente.
Nettoyage
Dans la configuration de l'équilibreur de charge, supprimez le backend des services de backend.
gcloud compute backend-services remove-backend ilb1 \ --instance-group=third-party-instance-group \ --instance-group-region=us-west1 \ --region=us-west1
gcloud compute backend-services remove-backend ilb2 \ --instance-group=third-party-instance-group \ --instance-group-region=us-west1 \ --region=us-west1
Supprimez les routes.
gcloud compute routes delete ilb-nhop-dest-10-50-1
gcloud compute routes delete ilb-nhop-dest-10-30-1
Dans les configurations de l'équilibreur de charge, supprimez les règles de transfert.
gcloud compute forwarding-rules delete fr-ilb1 \ --region=us-west1
gcloud compute forwarding-rules delete fr-ilb2 \ --region=us-west1
Dans les configurations de l'équilibreur de charge, supprimez les services de backend.
gcloud compute backend-services delete ilb1 \ --region=us-west1
gcloud compute backend-services delete ilb2 \ --region=us-west1
Dans les configurations de l'équilibreur de charge, supprimez la vérification d'état.
gcloud compute health-checks delete hc-http-80 \ --region=us-west1
Si vous avez utilisé la console Google Cloud, la vérification de l'état est globale. Par conséquent, la commande est la suivante :
gcloud compute health-checks delete hc-http-80 \ --global
Supprimez le groupe d'instances géré.
gcloud compute instance-groups managed delete third-party-instance-group \ --region=us-west1
Supprimez les modèles d'instance.
gcloud compute instance-templates delete third-party-template
gcloud compute instance-templates delete third-party-template-multinic
Supprimez les instances de test et de production.
gcloud compute instances delete testing-vm \ --zone=us-west1-a
gcloud compute instances delete production-vm \ --zone=us-west1-a
Étapes suivantes
- Présentation de l'équilibreur de charge réseau passthrough interne
- Basculement pour les équilibreurs de charge réseau internes à stratégie directe
- Configurez des équilibreurs de charge réseau passthrough internes avec des backends de groupes d'instances de VM
- Journalisation et surveillance de l'équilibreur de charge réseau passthrough interne
- Équilibreurs de charge réseau passthrough internes et réseaux connectés
- Dépannage des équilibreurs de charge réseau passthrough internes
- Nettoyez la configuration de l'équilibreur de charge.