L'équilibreur de charge réseau proxy interne Trusted Cloud by S3NS est basé sur un proxy et fourni par un logiciel proxy Envoy Open Source et par la pile de virtualisation de réseau Andromeda.
L'équilibreur de charge réseau proxy interne est un équilibreur de charge de couche 4 qui vous permet d'exécuter et de mettre à l'échelle votre trafic de service TCP derrière une adresse IP interne régionale accessible uniquement aux clients situés dans le même réseau VPC ou aux clients connectés à votre réseau VPC. L'équilibreur de charge interrompt d'abord la connexion TCP entre le client et l'équilibreur de charge au niveau d'un proxy Envoy. Le proxy ouvre une deuxième connexion TCP aux backends hébergés dans Trusted Cloud by S3NS, sur site ou dans d'autres environnements cloud. Pour plus de cas d'utilisation, consultez la page Présentation de l'équilibreur de charge réseau proxy.
Modes de fonctionnement
Cet équilibreur de charge est disponible en mode régional et est désigné ci-après par le terme "équilibreur de charge réseau proxy interne régional". L'équilibreur de charge est mis en œuvre en tant que service géré basé sur le proxy Envoy Open Source. En mode régional, tous les clients et backends se trouvent dans une région spécifiée. Utilisez cet équilibreur de charge si vous souhaitez diffuser du contenu à partir d'une seule géolocalisation (par exemple, pour respecter les réglementations de conformité).
Architecture
Le schéma suivant présente les ressources Trusted Cloud requises pour les équilibreurs de charge réseau proxy internes.
Régional
Ce schéma montre les composants d'un déploiement d'équilibreur de charge réseau proxy interne régional au niveau Premium.
Sous-réseau proxy réservé
Dans le diagramme ci-dessus, le sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google pour exécuter des proxys Envoy en votre nom. Vous devez créer un sous-réseau proxy réservé dans chaque région du réseau VPC dans lequel vous utilisez un équilibreur de charge réseau proxy interne basé sur Envoy.
Le tableau suivant décrit les exigences relatives aux sous-réseaux proxy réservés pour les équilibreurs de charge réseau proxy internes :
| Mode d'équilibreur de charge | Valeur de l'option --purpose du sous-réseau proxy réservé |
|---|---|
| Équilibreur de charge réseau proxy interne régional |
Les équilibreurs de charge régionaux et interrégionaux ne peuvent pas partager les mêmes sous-réseaux Tous les équilibreurs de charge régionaux basés sur Envoy d'une région et d'un réseau VPC partagent le même sous-réseau proxy réservé. |
En outre :
- Les sous-réseaux proxy réservés ne sont utilisés que pour les proxys Envoy, et non pour vos backends.
- Les instances de machine virtuelle (VM) de backend ou les points de terminaison de tous les équilibreurs de charge réseau proxy internes d'une région et d'un réseau VPC reçoivent les connexions du sous-réseau proxy réservé.
- L'adresse IP d'un équilibreur de charge réseau proxy interne n'est pas située dans le sous-réseau réservé au proxy. L'adresse IP de l'équilibreur de charge est définie par sa règle de transfert gérée en interne.
Règles de transfert et adresses IP
Les règles de transfert permettent d'acheminer le trafic par adresse IP, port et protocole vers une configuration d'équilibrage de charge comprenant un proxy cible et un service de backend.
Spécification de l'adresse IP. Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS de votre application. Vous pouvez soit réserver une adresse IP statique qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une pour votre compte. Nous vous recommandons de réserver une adresse IP statique. Si vous ne le faites pas, vous devez mettre à jour votre enregistrement DNS avec l'adresse IP éphémère nouvellement attribuée chaque fois que vous supprimez une règle de transfert et en créez une autre.
Les clients utilisent l'adresse IP et le port pour se connecter aux proxys Envoy de l'équilibreur de charge. L'adresse IP de la règle de transfert correspond à l'adresse IP de l'équilibreur de charge (parfois appelée adresse IP virtuelle ou VIP). Les clients se connectant à un équilibreur de charge doivent utiliser TCP. Pour obtenir la liste complète des protocoles acceptés, consultez la page Comparaison des fonctionnalités de l'équilibreur de charge.
L'adresse IP interne associée à la règle de transfert peut provenir d'un sous-réseau du même réseau et de la même région que vos backends.
Spécification du port Chaque règle de transfert que vous utilisez dans un équilibreur de charge réseau proxy interne peut faire référence à un port unique compris entre 1 et 65 535. Pour accepter plusieurs ports, vous devez configurer plusieurs règles de transfert.
Le tableau suivant présente les exigences relatives aux règles de transfert pour les équilibreurs de charge réseau proxy internes :
| Mode d'équilibreur de charge | Règle de transfert, adresse IP et sous-réseau proxy réservé --purpose |
Routage depuis le client vers l'interface de l'équilibreur de charge |
|---|---|---|
| Équilibreur de charge réseau proxy interne régional |
Schéma d'équilibrage de charge :
Sous-réseau proxy réservé
Adresse IP
|
Les backends doivent également se trouver dans la même région que l'équilibreur de charge. |
Règles de transfert et réseaux VPC
Cette section décrit comment les règles de transfert utilisées par les équilibreurs de charge d'application externes sont associées aux réseaux VPC.
| Mode d'équilibreur de charge | Association de réseaux VPC |
|---|---|
| Équilibreur de charge réseau proxy interne interrégional Équilibreur de charge réseau proxy interne régional |
Les adresses IPv4 internes régionales existent toujours dans les réseaux VPC. Lorsque vous créez la règle de transfert, vous devez spécifier le sous-réseau à partir duquel l'adresse IP interne est extraite. Ce sous-réseau doit se trouver dans la même région et le même réseau VPC qu'un sous-réseau proxy réservé. est créé automatiquement. Il existe donc une association de réseau implicite. |
Proxy cibles
L'équilibreur de charge réseau proxy interne met fin aux connexions TCP du client et crée des connexions vers les backends. Par défaut, l'adresse IP et les informations de port d'origine du client ne sont pas conservées. Vous pouvez conserver ces informations à l'aide du protocole de PROXY. Le proxy cible achemine les requêtes entrantes directement vers le service de backend de l'équilibreur de charge.
Le tableau suivant présente les API de proxy cibles requises par les équilibreurs de charge réseau proxy internes :
| Mode d'équilibreur de charge | Proxy cible |
|---|---|
| Équilibreur de charge réseau proxy interne régional | Régional regionTargetTcpProxies |
Service de backend
Un service de backend dirige le trafic entrant vers un ou plusieurs backends associés. Un backend est soit un groupe d'instances, soit un groupe de points de terminaison du réseau. Le backend contient des informations sur le mode d'équilibrage permettant de définir l'utilisation maximale en fonction des connexions (ou, pour les backends de groupe d'instances uniquement, de l'utilisation).
Chaque équilibreur de charge réseau proxy interne possède une seule ressource de service de backend.
Le tableau suivant spécifie les exigences relatives service de backend pour les équilibreurs de charge réseau proxy internes :
| Mode d'équilibreur de charge | Type de service de backend |
|---|---|
| Équilibreur de charge réseau proxy interne régional | Régional regionBackendServices |
Backends compatibles
Le service de backend accepte les types de backends suivants :
| Mode d'équilibreur de charge | Backends compatibles sur un service de backend | ||||||
|---|---|---|---|---|---|---|---|
| Groupes d'instances | NEG zonaux | NEG Internet | NEG sans serveur | NEG hybrides | GKE | ||
| Équilibreur de charge réseau proxy interne régional |
Points de terminaison pour le type GCE_VM_IP_PORT |
NEG régionaux uniquement | |||||
Tous les backends doivent être du même type (groupes d'instances ou NEG). Vous pouvez utiliser simultanément différents types de backends de groupe d'instances ou utiliser différents types de backends NEG, mais vous ne pouvez pas utiliser des backends de groupe d'instances et de NEG ensemble sur le même service de backend.
Vous pouvez combiner des NEG zonaux et des NEG hybrides au sein du même service de backend.
Pour minimiser les interruptions de service pour vos utilisateurs, activez le drainage de connexion sur les services de backend. De telles interruptions peuvent se produire lorsqu'un backend est arrêté, supprimé manuellement ou supprimé par un autoscaler. Pour en savoir plus sur la manière dont vous pouvez utiliser le drainage de connexion pour réduire le plus possible les interruptions de service, consultez la page Activer le drainage de connexion.
Backends et réseaux VPC
Pour les groupes d'instances, les NEG zonaux et les NEG de connectivité hybride, tous les backends doivent être situés dans le même projet et la même région que le service de backend. Toutefois, un équilibreur de charge peut référencer un backend qui utilise un autre réseau VPC dans le même projet que le service de backend. La connectivité entre le réseau VPC de l'équilibreur de charge et le réseau VPC du backend peut être configurée à l'aide de l'appairage de réseaux VPC, de tunnels Cloud VPN ou de rattachements de VLAN Cloud Interconnect.
Définition du réseau de backend
- Pour les NEG zonaux et hybrides, vous spécifiez explicitement le réseau VPC lorsque vous créez le NEG.
- Pour les groupes d'instances gérés, le réseau VPC est défini dans le modèle d'instance.
- Pour les groupes d'instances non gérés, le réseau VPC du groupe d'instances est défini pour correspondre au réseau VPC de l'interface
nic0de la première VM ajoutée au groupe d'instances.
Exigences du réseau de backend
Le réseau de votre backend doit répondre à l'une des exigences réseau suivantes :
Le réseau VPC du backend doit correspondre exactement à celui de la règle de transfert.
Le réseau VPC du backend doit être connecté à celui de la règle de transfert à l'aide de l'appairage de réseaux VPC. Vous devez configurer les échanges de routes de sous-réseau pour permettre la communication entre le sous-réseau proxy réservé dans le réseau VPC de la règle de transfert et les sous-réseaux utilisés par les instances ou points de terminaison de backend.
Pour tous les autres types de backend, tous les backends doivent se trouver dans le même réseau VPC et dans la même région.
Backends et interfaces réseau
Si vous utilisez des backends de groupe d'instances, les paquets sont toujours distribués à nic0. Si vous souhaitez envoyer des paquets à des interfaces non nic0 (vNIC ou interfaces réseau dynamiques), utilisez plutôt des backends de NEG.
Si vous utilisez des backends de NEG zonaux, les paquets sont envoyés à l'interface réseau représentée par le point de terminaison dans le NEG. Les points de terminaison du NEG doivent se trouver dans le même réseau VPC que le réseau VPC défini explicitement pour le NEG.
Protocole de communication avec les backends
Lorsque vous configurez un service de backend pour un équilibreur de charge réseau proxy interne, vous définissez le protocole utilisé par le service de backend pour communiquer avec les backends. L'équilibreur de charge n'utilise que le protocole spécifié et n'essaie pas de négocier une connexion à l'aide de l'autre protocole. Les équilibreurs de charge réseau proxy internes n'acceptent que le protocole TCP pour la communication avec les backends.
Vérification de l'état
Chaque service de backend spécifie une vérification d'état qui vérifie régulièrement que les backends sont disponibles et aptes à recevoir une connexion de l'équilibreur de charge. Cela réduit le risque que des requêtes soient envoyées à des backends ne pouvant pas les traiter. Les vérifications d'état ne vérifient pas si l'application elle-même fonctionne.
Protocole de vérification d'état
Bien que ce ne soit pas obligatoire et pas toujours possible, il est recommandé d'utiliser une vérification d'état dont le protocole correspond à celui du service de backend. Par exemple, une vérification d'état TCP teste plus précisément la connectivité TCP aux backends. Pour obtenir la liste des protocoles de vérification de l'état d'état compatibles, consultez la section Vérifications d'état de la page "Comparaison des fonctionnalités de l'équilibreur de charge".
Le tableau suivant spécifie le champ d'application des vérifications d'état compatibles avec les équilibreurs de charge réseau proxy internes dans chaque mode :
| Mode d'équilibreur de charge | Type de vérification d'état |
|---|---|
| Équilibreur de charge réseau proxy interne régional | Régional regionHealthChecks |
Pour en savoir plus sur les vérifications d'état, consultez les pages suivantes :
Règles de pare-feu
Les équilibreurs de charge réseau proxy internes nécessitent les règles de pare-feu suivantes :
- Une règle d'autorisation d'entrée qui autorise le trafic provenant des vérifications d'état de Google. Pour en savoir plus sur les plages d'adresses IP de vérification de l'état d'état spécifiques et découvrir pourquoi il est nécessaire d'autoriser le trafic qui en provient, consultez Plages d'adresses IP de vérification et règles de pare-feu.
- Une règle d'autorisation d'entrée qui autorise le trafic provenant du sous-réseau proxy réservé
Les ports de ces règles de pare-feu doivent être configurés comme suit :
Autorisez le trafic vers le port de destination pour la vérification d'état de chaque service de backend.
Pour les backends de groupe d'instances : déterminez les ports à configurer par le mappage entre le port nommé du service de backend et les numéros de port associés à ce port nommé sur chaque groupe d'instances. Les numéros de port peuvent varier entre les groupes d'instances attribués au même service de backend.
Pour les backends de NEG
GCE_VM_IP_PORT, autorisez le trafic vers les numéros de port des points de terminaison.
Il existe certaines exceptions aux exigences des règles de pare-feu pour ces équilibreurs de charge :
- Il n'est pas nécessaire d'autoriser le trafic provenant des plages de vérification de l'état de l'état de Google pour les NEG hybrides. Toutefois, si vous utilisez à la fois des NEG hybrides et zonaux dans un service de backend, vous devez autoriser le trafic provenant des plages de vérification de l'état de l'état Google pour les NEG zonaux.
- Pour les NEG Internet régionaux, les vérifications d'état sont facultatives. Le trafic provenant des équilibreurs de charge qui utilisent des NEG Internet régionaux provient du sous-réseau proxy réservé, puis est traduit par la NAT (à l'aide de Cloud NAT) en adresses IP NAT allouées manuellement ou automatiquement. Ce trafic inclut à la fois les vérifications d'état et les requêtes des utilisateurs depuis l'équilibreur de charge vers les backends. Pour en savoir plus, consultez NEG régionaux : utiliser une passerelle Cloud NAT.
Accès des clients
Les clients peuvent se trouver sur le même réseau ou sur un réseau VPC connecté à l'aide de l'appairage de réseaux VPC.
Pour les équilibreurs de charge réseau proxy internes régionaux, les clients doivent se trouver dans la même région que l'équilibreur de charge par défaut. Ils doivent également se trouver sur le même réseau VPC que l'équilibreur de charge ou sur un réseau VPC connecté au réseau VPC de l'équilibreur de charge via l'appairage de réseaux VPC.
Les clients sur site peuvent accéder à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN. Ces tunnels ou rattachements doivent se trouver dans la même région que l'équilibreur de charge.
Architecture du VPC partagé
L'équilibreur de charge réseau proxy interne est compatible avec les réseaux qui utilisent un VPC partagé. Les réseaux VPC partagés vous permettent de séparer clairement les responsabilités entre les administrateurs réseau et les développeurs de services. Vos équipes de développement peuvent se concentrer sur la création de services dans des projets de service, tandis que les équipes d'infrastructure réseau peuvent provisionner et administrer l'équilibrage de charge. Si vous n'êtes pas familiarisé avec le VPC partagé, consultez la présentation du VPC partagé.
| Adresse IP | Règle de transfert | Proxy cible | Composants backend |
|---|---|---|---|
Une adresse IP interne doit être définie dans le même projet que les backends. Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, l'adresse IP interne doit être définie dans le même projet de service que les VM de backend et doit faire référence à un sous-réseau du réseau VPC partagé souhaité dans le projet hôte. L'adresse elle-même provient de la plage d'adresses IP principale du sous-réseau référencé. |
Une règle de transfert interne doit être définie dans le même projet que les backends. Pour que l'équilibreur de charge soit disponible dans un réseau VPC partagé, la règle de transfert interne doit être définie dans le même projet de service que les VM de backend et doit faire référence au même sous-réseau (dans le réseau VPC partagé) que celui auquel l'adresse IP interne associée fait référence. |
Le proxy cible doit être défini dans le même projet que les backends. | Dans un scénario de VPC partagé, les VM de backend sont généralement situées dans un projet de service. Un service de backend interne régional et une vérification d'état doivent être définis dans ce projet de service. |
Distribution du trafic
Un équilibreur de charge réseau proxy interne distribue le trafic vers ses backends comme suit :
- Les connexions provenant d'un seul client sont envoyées à la même zone tant que des backends (groupes d'instances ou NEG) opérationnels dans cette zone sont disponibles et ont une capacité déterminée par le mode d'équilibrage.
Pour les équilibreurs de charge réseau proxy internes régionaux, le mode d'équilibrage peut être
CONNECTION(backends de groupes d'instances ou de NEG) ouUTILIZATION(backends de groupes d'instances seulement). - Les connexions d'un client sont envoyées au même backend si vous avez configuré l'affinité de session.
- Une fois le backend sélectionné, le trafic est réparti entre des instances (dans un groupe d'instances) ou des points de terminaison (dans un NEG), en fonction d'une règle d'équilibrage de charge. Pour en savoir plus sur les algorithmes de règle d'équilibrage de charge compatibles, consultez le paramètre
localityLbPolicydans la documentation de l'API sur le service de backend régional.
Affinité de session
L'affinité de session vous permet de configurer le service de backend de l'équilibreur de charge pour envoyer toutes les requêtes d'un même client au même backend, à condition que le backend soit opérationnel et dispose de la capacité requise.
L'équilibreur de charge réseau proxy interne offre une affinité basée sur les adresses IP client, qui permet de transmettre toutes les requêtes provenant d'une même adresse IP client au même backend, à condition que ce backend dispose d'une capacité suffisante et reste opérationnel.
Basculement
Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels.
Le tableau suivant décrit le comportement de basculement des équilibreurs de charge réseau proxy internes :
| Mode d'équilibreur de charge | Comportement de basculement | Comportement lorsque tous les backends ne sont pas opérationnels |
|---|---|---|
| Équilibreur de charge réseau proxy interne régional | L'équilibreur de charge implémente un algorithme de basculement souple par zone. Plutôt que d'attendre que tous les backends d'une zone deviennent non opérationnels, l'équilibreur de charge commence à rediriger le trafic vers une zone différente lorsque le ratio entre les backends opérationnels et non opérationnels dans une zone est inférieur à un certain seuil (70 % ; ce seuil n'est pas configurable). Si aucun des backends de toutes les zones n'est opérationnel, l'équilibreur de charge met immédiatement fin à la connexion du client. Le proxy Envoy envoie le trafic aux backends opérationnels dans une région en fonction de la répartition du trafic configurée. |
Désactivation de la connexion |
Équilibrage de charge pour les applications GKE
Si vous créez des applications dans Google Kubernetes Engine (GKE), vous pouvez utiliser des NEG zonaux autonomes pour équilibrer la charge du trafic directement vers les conteneurs. Avec les NEG autonomes, vous devez créer l'objet Service qui crée le NEG zonal, puis associer le NEG au service de backend afin que l'équilibreur de charge puisse se connecter aux pods.
Documentation GKE associée :
Quotas et limites
Pour en savoir plus sur les quotas et les limites, consultez la section Quotas et limites.
Limites
- L'équilibreur de charge réseau proxy interne ne prend pas en charge le trafic IPv6.
- L'équilibreur de charge réseau proxy interne n'est pas compatible avec les déploiements de VPC partagé pour lesquels l'interface de l'équilibreur de charge se trouve dans un projet hôte ou de service, ou le service de backend et les backends se trouvent dans un autre projet de service (également appelé référencement de services inter-projets).
Étapes suivantes
Configurez un équilibreur de charge réseau proxy interne régional avec un backend de NEG zonal
Configurez un équilibreur de charge réseau proxy interne régional avec un backend de NEG hybride
Configurer un équilibreur de charge réseau proxy interne régional avec un backend de NEG Internet