Concepts de l'équilibrage de charge HTTP(S) interne

L'équilibrage de charge HTTP(S) interne est assuré par un équilibreur de charge régional de couche 7 basé sur un proxy qui vous permet d'assurer l'exécution et le scaling de vos services derrière une adresse IP d'équilibrage de charge privée uniquement accessible dans la région de l'équilibreur de charge dans votre réseau VPC.

Présentation

L'équilibrage de charge HTTP(S) interne de Google Cloud Platform (GCP) est assuré par un équilibreur de charge HTTP et HTTPS privé basé sur un proxy. Il répartit le trafic sur les instances de VM du backend ou sur les points de terminaison des groupes de points de terminaison du réseau (NEG) au sein d'une seule région du réseau VPC à l'aide d'un mappage d'URL. L'équilibreur de charge n'est accessible que dans la région choisie de votre réseau VPC, sur une adresse IP interne privée (RFC 1918).

Pour en savoir plus sur les différences entre un équilibreur de charge HTTP(S) interne et d'autres équilibreurs de charge GCP, consultez la page Choisir un équilibreur de charge.

Types de trafic, schéma et champ d'application

Un équilibreur de charge HTTP(S) interne est défini par un seul mappage d'URL, qui fait référence à un ou plusieurs services de backend à l'aide d'un schéma d'équilibrage de charge géré en interne. Chaque service de backend est compatible avec l'un des protocoles suivants : HTTP, HTTPS ou HTTP/2. Chacun d'eux accepte les VM de backend ou les points de terminaison d'un groupe de points de terminaison du réseau (NEG).

Comme le champ d'application d'un équilibreur de charge HTTP(S) interne est régional et non global, les VM des clients et du backend, ou les points de terminaison doivent tous se trouver dans la même région. Les clients des réseaux connectés peuvent utiliser un tunnel Cloud VPN ou un rattachement d'interconnexion Cloud Interconnect dans la même région que l'équilibreur de charge.

Schéma complet

Chaque équilibreur de charge HTTP(S) interne possède une adresse IP privée faisant office de frontend pour les VM ou les points de terminaison de son backend. Les requêtes de vos clients internes restent en interne dans votre réseau et dans votre région.

Services internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)
Services internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)

Cas d'utilisation

Services

Un cas d'utilisation courant consiste à équilibrer la charge du trafic entre les services. Dans cet exemple, l'utilisateur obtient les vidéos et les images avec la même URL de base, mygcpservice.internal, en utilisant les chemins /video et /images.

Le mappage d'URL de l'équilibreur de charge HTTP(S) interne redirige le trafic vers un service de backend pour le contenu video et vers un autre service de backend pour le contenu images, en fonction de l'outil de mise en correspondance des chemins d'accès du mappage d'URL.

Le schéma suivant présente trois services : les vidéos, les images et les paiements.

Services (microservices) internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)
Services (microservices) internes avec un équilibrage de charge basé sur la couche 7 (cliquez pour agrandir)

Services Web à trois niveaux

L'équilibrage de charge HTTP(S) interne vous permet d'assurer la compatibilité avec les services Web classiques à trois niveaux.

Dans le schéma suivant, les différents types d'équilibreurs de charge évoluent en trois niveaux :

Le schéma présente trois types d'équilibreurs de charge GCP.

  1. Un équilibreur de charge HTTP(S) externe global distribue le trafic provenant d'Internet vers un ensemble de groupes d'instances frontend Web dans différentes régions.
  2. Ces interfaces envoient le trafic HTTP(S) vers un ensemble d'équilibreurs de charge HTTP(S) internes régionaux (sujet de cette présentation).
  3. Les équilibreurs de charge HTTP(S) distribuent le trafic sur les groupes d'instances middleware.
  4. Ces instances middleware envoient le trafic vers les équilibreurs de charge TCP/UDP internes qui équilibrent la charge du trafic entre les clusters de stockage de données.
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux (cliquez pour agrandir)
Routage basé sur la couche 7 pour les niveaux internes d'une application à plusieurs niveaux (cliquez pour agrandir)

Architecture et ressources

L'interface d'un équilibreur de charge HTTP(S) interne comprend une adresse IP interne, une règle de transfert interne, ainsi qu'un proxy HTTP ou HTTPS cible. Un seul mappage d'URL redirige le trafic vers un ou plusieurs services de backend à l'aide d'un schéma d'équilibrage de charge INTERNAL_MANAGED. Chaque service de backend répartit le trafic entre ses groupes d'instances backend ou ses groupes de points de terminaison du réseau selon un mode d'équilibrage configurable. Au sein de chaque groupe d'instances ou de chaque groupe de points de terminaison du réseau, le trafic est réparti selon une règle configurable. Pour en savoir plus, consultez la page Répartir le trafic.

Chaque service de backend est régional. Tous les backends d'un service de backend donné doivent être des groupes d'instances ou des groupes de points de terminaison du réseau. Les groupes d'instances non gérés, les groupes d'instances zonaux gérés et les groupes d'instances régionaux gérés sont acceptés.

Le schéma suivant présente les ressources GCP requises pour un équilibreur de charge HTTP(S) interne.

Composants de l'équilibrage de charge HTTP(S) interne (cliquez pour agrandir)
Composants de l'équilibrage de charge HTTP(S) interne (cliquez pour agrandir)

Les ressources suivantes définissent un équilibreur de charge HTTP(S) interne :

  • Une règle de transfert interne régionale, qui indique l'adresse IP interne et le port de l'équilibreur de charge (adresse utilisée lorsque les clients se connectent à l'équilibreur de charge), ainsi que le proxy cible dans lequel il transfère chaque requête entrante.

  • Un proxy HTTP(S) régional cible reçoit la requête de l'utilisateur et la transmet au mappage d'URL. Un proxy HTTPS cible accepte un nombre limité de certificats SSL qui permettent au proxy de prouver son identité aux clients.

  • Un mappage d'URL régional analyse l'URL des requêtes et les transfère à des services de backend spécifiques en fonction de l'hôte et du chemin d'accès de l'URL de la requête.

  • Un service de backend régional répartit les requêtes entre les backends opérationnels (groupes d'instances ou groupes de points de terminaison du réseau).

  • Une vérification d'état régionale indique la disponibilité de vos backends.

  • Un ou plusieurs backends doivent être connectés au service de backend. Les backends peuvent être de l'un des types suivants :

    • Groupes d'instances gérés (zonaux ou régionaux)
    • Groupes d'instances non gérés (zonaux)
    • Groupes de points de terminaison du réseau (zonaux)

    Vous ne pouvez pas utiliser à la fois des groupes d'instances et des groupes de points de terminaison du réseau sur le même service de backend.

  • Un sous-réseau proxy réservé dont les adresses IP sont la source du trafic entre l'équilibreur de charge et vos backends. Vous devez créer un sous-réseau proxy réservé dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge HTTP(S) internes. Ce sous-réseau est partagé par tous les équilibreurs de charge HTTP(S) internes de la région.

  • Un pare-feu permettant aux backends d'accepter les connexions du sous-réseau proxy réservé. Consultez l'exemple sur la page Configurer des règles de pare-feu.

Limites

  • L'équilibrage de charge HTTP(S) interne fonctionne au niveau régional. Rien ne garantit que la requête d'un client dans une zone de la région est envoyée à un backend situé dans la même zone que le client. L'affinité de session ne limite pas la communication entre les zones.

  • L'équilibrage de charge HTTP(S) interne n'est pas compatible avec les fonctionnalités suivantes :

  • L'équilibrage de charge HTTP(S) interne n'est pas compatible avec l'appairage de réseaux VPC. Si vous avez besoin d'un équilibreur de charge interne compatible avec l'appairage de réseaux VPC, utilisez l'équilibrage de charge TCP/UDP interne.

  • Le protocole WebSocket n'est pas accepté.

  • GCP ne vous avertit pas si votre sous-réseau proxy réservé manque d'adresses IP.

Étapes suivantes