Comprendre les équilibreurs de charge GCP

Présentation des équilibreurs de charge GCP

Présentation de l'équilibreur de charge GCP

Types d'équilibreurs de charge GCP

Voir Types d'équilibreurs de charge GCP pour en savoir plus.

Il existe deux principaux types d'équilibreurs de charge dans GCP (Google Cloud Platform) :

• Équilibreurs de charge d'application: pour le trafic HTTP(S) de couche 7

• Équilibreurs de charge réseau : pour le trafic de couche 4 (TCP, UDP...) et également le trafic SSL/TLS.

Les équilibreurs de charge réseau sont divisés en deux catégories :

Équilibreurs de charge réseau proxy

Termine les connexions des requêtes client et crée de nouvelles connexions aux backends, provenant de l'équilibreur de charge. Les réponses des backends sont renvoyées à l'équilibreur de charge, puis aux clients par l'équilibreur de charge. Par défaut, les backends voient l'adresse IP de l'équilibreur de charge au lieu des IP des clients. Il est également possible de transférer les adresses IP des clients aux backends en activant l'option Protocole PROXY.

L'affinité de session ainsi que le drainage de connexion peuvent également être configurés pour les backends de l'équilibreur de charge réseau proxy.

Cet équilibreur de charge est également appelé Équilibreur de charge réseau proxy SSL lorsqu'il met fin aux connexions SSL/TLS et Équilibreur de charge réseau proxy TCP lorsqu'il met fin aux connexions TCP, UDP ou autres protocoles de couche 4.

Équilibreurs de charge réseau de transfert

Les demandes de connexion des clients sont directement transmises aux backends. Les réponses des backends sont directement envoyées aux clients (retour direct du serveur).

Portées des équilibreurs de charge GCP

• Externe: accessible depuis Internet via une adresse IP publique
• Interne: accessible uniquement depuis l'intérieur d'un réseau interne GCP (VPC) ou depuis des réseaux qui y sont connectés, via une adresse IP privée (RFC 1918)
• Global: optimisé (faible latence) pour le trafic provenant de n'importe où dans le monde. L'équilibreur de charge sera accessible via une adresse IP anycast globale. Les applications back-end peuvent être déployées dans n'importe quelle région GCP.
• Régional: optimisé (faible latence) pour le trafic provenant d'une région spécifique du monde. L'équilibreur de charge sera accessible via une adresse IP régionale. Les applications back-end doivent être déployées dans la même région que l'équilibreur de charge. Tout le trafic réseau restera dans la région choisie.
• Interrégional: optimisé (faible latence) pour le trafic provenant de plusieurs régions (2 ou plus). L'équilibreur de charge sera accessible via une IP virtuelle dédiée (VIP) à l'intérieur de chaque région. Les applications backend doivent être déployées dans les régions choisies. Tout le trafic réseau restera à l'intérieur des régions choisies.

La combinaison d'une des portées : global, régional ou interrégional et de la portée externe ou interne constitue le mode de déploiement ou mode de fonctionnement de l'équilibreur de charge. Ex : interne interrégional, externe global, externe régional...

Parfois, vous verrez également le mode de fonctionnement classique disponible pour certains équilibreurs de charge externes. Il peut être utilisé pour déployer l'équilibreur de charge en mode de fonctionnement externe global (quand utilisé en mode Premium) ou externe régional (quand utilisé en mode Standard).

Équilibreur de charge d'application

Équilibreur de charge d'application (ECA)

• Présentation de l'ECA

• Présentation de l'ECA externe + modes de fonctionnement + fonctionnalités

• Présentation de l'ECA interne + modes de fonctionnement + fonctionnalités

• Architecture de haute disponibilité ECA

Équilibreur de charge réseau proxy

Équilibreur de charge réseau proxy (ECRP)

• Présentation de l'ECRP

• Présentation + modes de fonctionnement + fonctionnalités de l'ECRP

• Présentation + modes de fonctionnement + fonctionnalités de l'ECRP

• Architecture de haute disponibilité de l'ECRP

Équilibreur de charge réseau de transfert

Équilibreur de charge réseau de transfert (ECRT)

• Présentation de l'ECRT

• Présentation de l'ECRT externe (backend via un service de backend)

• Présentation de l'ECRT externe (backend via un pool cible)

• Présentation de l'ECRT interne

Composants des équilibreurs de charge GCP

Services de backend et règles de transfert

Composants de l'équilibreur de charge réseau de transfert

Nous expliquerons ce que sont les Règles de transfert ainsi que les Service de backend, et montrerons également comment les Tests de vie ainsi que les Règles de pare-feu sont utilisés, en lien avec le service de backend.

Service de backend

Le composant Service de backend peut être utilisé pour représenter les backends des équilibreurs de charge. Les backends sont la destination finale du trafic de l'équilibreur de charge. Ils peuvent être considérés comme des points de terminaison (IP + port) qui reçoivent le trafic de l'équilibreur de charge. Ex : machines virtuelles (groupes classiques ou d'instances) et NEG (groupes de points de terminaison réseau).

Le composant Service de backend prend en charge les backends suivants :

• groupes d'instances de machines virtuelles (gérés ou non gérés)
• Groupes de points de terminaison de réseau (NEG)

Certaines fonctionnalités intéressantes de l'équilibreur de charge sont également définies par le Service de backend :

• affinité de sessions
• délais d'expiration des connexions client
• journalisation des requêtes
• types de tests de vie pour les backends (http, tcp...)
• IAP (proxy prenant en charge l'identité)
• Cloud Armor (Pare-feu d'application Web)
• Etc... la commande suivante devrait donner un aperçu de ces fonctionnalités :

gcloud compute backend-services create --help
gcloud compute backend-services add-backend --help

Voici un exemple de création d'un service de backend à l'aide de gcloud :

# Backend service needs health checks for the backends
# Here is an example for creating a http health check
gcloud compute health-checks create http http-basic-check --port 80

# We also need to create a firewall rule to allow 
# health checks probes sources IP ranges on the backends.
# Depending on the type of the Load Balancer, the list of 
# the IP ranges can be found here:
# https://cloud.google.com/load-balancing/docs/health-check-concepts?hl=en#ip-ranges
gcloud compute firewall-rules create fw-allow-health-check \
  --network=$network \
  --action=allow \
  --direction=ingress \
  --source-ranges=$ranges \
  --target-tags=allow-health-check \
  --rules=tcp:80

# Create the backend service
gcloud compute backend-services create myapp-backend-service --protocol=HTTP --port-name=http --health-checks=http-basic-check --global

# Add an instance group as backend to the backend service
gcloud compute backend-services add-backend myapp-backend-service \
  --instance-group=web-instance-group \
  --instance-group-zone=us-east4-c \
  --global

Outre les services de backend, les composants suivants peuvent également être utilisés pour certains équilibreurs de charge :

• backend pour bucket: pour utiliser les buckets Cloud Storage comme backends (pour gérer des sites Web statiques par exemple)... pris en charge uniquement par les équilibreurs de charge d'application.
• pools cibles: pour utiliser des machines virtuelles comme backends.

Règle de transfert

La Règle de transfert est le point d'entrée des équilibreurs de charge GCP et définit l'adresse IP de l'équilibreur de charge, un protocole + un ou plusieurs ports sur lesquels écouter et, selon le type d'équilibreur de charge, spécifie soit un Service de backend, un proxy cible ou un pool cible.

L'exposition (externe ou interne) et la portée de l'équilibreur de charge (régionale ou globale) sont également déterminées par la règle de transfert. Une Règle de transfert peut être soit :

• externe ou interne :

# gcloud flag for: gcloud compute forwarding-rules create...
--load-balancing-scheme=[EXTERNAL|EXTERNAL_MANAGED|INTERNAL|INTERNAL_MANAGED|INTERNAL_SELF_MANAGED]` (gcloud flag)

• mondial ou régional :

# gcloud flags for: gcloud compute forwarding-rules create ...
--global
--region=REGION

Voici quelques exemples de création de règles de transfert pour les équilibreurs de charge réseau de transfert à l'aide de gcloud :

# (Regional, external) Passthrough Network Load Balancer
# Backends are virtual machines inside a target pool

$ gcloud compute forwarding-rules create my-forwarding-rule-1 \
    --region $region \
    --ports 80 \
    --address my-regional-static-ip-name \
    --target-pool my-target-pool

# (Regional, internal) Passthrough Network Load Balancer
# Backends are virtual machines inside instance groups

$ gcloud compute forwarding-rules create my-forwarding-rule-2 \
    --ports=80 \
    --address=my-regional-static-ip-name \
    --backend-service=my-backend-service \
    --address-region=$region \
    --load-balancing-scheme=INTERNAL \
    --network=my-vpc \
    --subnet=my-vpc-subnet # subnet of the associated IP address (--address)    

Proxy cible et certificats SSL/TLS

Composants de l'équilibreur de charge du réseau proxy

Les requêtes client reçues par l'Équilibreur de charge réseau proxy sont transmises aux Proxy cibles suivants :

• proxy TCP cible : pour TCP/UDP et autre trafic de couche 4
• proxy SSL cible : pour le trafic SSL. L'utilisation de ce proxy cible nécessite un Certificats SSL/TLS pour chiffrer les communications entre les clients et l'équilibreur de charge.

Connexions reçues par le Équilibreur de charge d'application sont transmises à :

• proxy HTTP(S) cible : pour le trafic HTTP(S) (couche 7). L'utilisation du proxy cible HTTPS nécessite un proxy associé Certificats SSL/TLS pour chiffrer les communications entre les clients et l'équilibreur de charge.

Toutes les connexions arrivant aux proxy cibles sont interrompues et de nouvelles connexions, provenant de l'équilibreur de charge, sont créées vers les backends. C'est l'objectif principal des proxy cibles.

Les commandes suivantes devraient donner un aperçu des possibilités lors de la création d’un proxy cible :

gcloud compute target-tcp-proxies create --help
gcloud compute target-ssl-proxies create --help
gcloud compute target-https-proxies create --help
gcloud compute target-http-proxies create --help

Voici un exemple de création d'un proxy cible HTTP à l'aide de gcloud :

gcloud compute target-http-proxies create myapp-target-http-proxy --url-map myapp-url-map

# for target-https-proxies an additional flag should be specified 
# (--certificate-map or --certificate-manager-certificates...)
# to indicate where to find the SSL/TLS certificate

Mappage d'URL

Composants de l'équilibreur de charge d'application

Utilisé uniquement par les proxy HTTP cible des équilibreurs de charge d'application, pour déterminer où transférer une requête HTTP (vers un service de backend ou un backend pour bucket). Les décisions de transfert/routage sont prises en fonction de l'hôte (nom du host) et/ou de l'URI des requêtes HTTP.

La commande suivante devrait donner un aperçu des possibilités lors de la création d’un mappage d’URL :

gcloud compute url-maps create --help

Voici un exemple de création d'un mappage d'URL à l'aide de gcloud :

gcloud compute url-maps create myapp-url-map --default-service myapp-backend-service

Documentations complémentaires

• Technologies derrière les équilibreurs de charge GCP
• Tarifs des équilibreurs de charge GCP
• Tarification générale des réseaux
• Croquis d'équilibrage de charge
• Article de blog sur l'équilibrage de charge dans Google Cloud
• Article de blog sur l'équilibrage de charge Google Cloud (calculs sans serveur)
• Page produit d'équilibrage de charge
• Documentation sur l'équilibrage de charge