À propos des load balancers

Les VM enregistrées auprès d’un load balancer sont appelées VM backend. Vous pouvez enregistrer autant de VM backend que nécessaire auprès d’un load balancer, et vous pouvez enregistrer ou désenregistrer des VM backend à tout moment selon vos besoins.

En fonction de ses règles de security groups, une VM backend peut recevoir soit le trafic venant uniquement du load balancer soit le trafic venant à la fois du load balancer et d’une autre source (par exemple un autre load balancer, internet, ou autres).

Les load balancers fonctionnent en mode round robin : les requêtes frontend sont distribuées de façon égale entre les VM backend. Le nombre de requêtes frontend reçues par une VM backend correspond ainsi au nombre total de requêtes frontend divisé par le nombre total de VM backend.

Le load balancer vérifie la santé des VM backend pour déterminer les VM saines vers lesquelles il peut distribuer du trafic. Pour en savoir plus sur les health checks, voir Configurer les health checks.

Un load balancer peut être soit relié à internet, soit interne :

Un nom DNS est automatiquement attribué à chaque load balancer et est composé du nom du load balancer et de son endpoint (nom-du-load-balancer.endpoint). Ce nom DNS vous permet d’accéder à votre load balancer et de lui envoyer des requêtes.

Les load balancers reliés à internet reçoivent un nom DNS public, tandis que les load balancers internes reçoivent un nom DNS privé.

Les IP publiques sont des adresses IPv4 publiques que vous pouvez allouer à votre compte. Vous pouvez associer des IP publiques uniquement à des load balancers reliés à internet dans le Cloud public ou dans un Net.

Les propriétaires des IP publiques sont 3DS OUTSCALE ou vous, selon ce que vous spécifiez lorsque vous associez celles-ci.

Le tableau ci-dessous décrit les différents comportements d’association lorsque vous utilisez le paramètre PublicIp :

Pour en savoir plus sur les IP publiques, voir À propos des IP publiques.

Chaque load balancer doit être créé avec un listener pour pouvoir recevoir des requêtes. Un listener correspond au processus qui traite les requêtes arrivant au load balancer depuis internet ou depuis votre réseau privé, configuré avec un protocole et un port, avec un port compris entre 1 et 65535 tous deux inclus.

Vous configurez également le protocole et le port pour router le trafic jusqu’aux VM backend.

Les load balancers OUTSCALE prennent en charge les protocoles HTTP/HTTPS et TCP/SSL. Les protocoles sécurisés sont supportés uniquement entre le client et le load balancer. Les protocoles frontend et backend doivent être de même niveau, c’est-à-dire que :

Le numéro de port que les VM backend écoutent doit être compris entre 1 et 65535, tous deux inclus.

Vous pouvez également gérer le comportement d’un load balancer à l’aide de listener rules. Ces règles vous permettent de rediriger le trafic vers une VM backend spécifique en fonction d’un chemin d’accès dans l’URI de la requête. Pour en savoir plus, voir Créer une listener rule.

Par défaut, un load balancer distribue chaque requête réseau indépendamment des autres, ce qui signifie que deux requêtes successives d’un même utilisateur peuvent être routées vers deux VM backend différentes. Toutefois, vous pouvez utiliser une politique de sessions persistantes (sticky sessions) pour lier l’utilisateur à la VM backend ayant traité la première requête.

Les sessions persistantes fonctionnent au moyen d’un cookie de persistance, avec une durée spécifique. À l’expiration du cookie de persistance, la session persistante est réinitialisée et la prochaine requête crée une nouvelle session persistante.

Il existe deux types de politiques de sessions persistantes :

Pour en savoir plus, voir Configurer des sessions persistantes pour vos load balancers.

Vous pouvez créer un listener pour un load balancer avec un certificat serveur SSL x509 afin de rendre possible le trafic chiffré en protocole SSL ou HTTPS entre le client initiant les connexions SSL ou HTTPS et le load balancer. Les certificats serveurs x509 sont délivrés par une autorité de certification et contiennent des informations d’authentification comme une clé publique et la signature de l’autorité de certification. Ce certificat est utilisé par le load balancer pour déchiffrer les requêtes de connexion venant de ce client, qui sont ensuite envoyées vers ses VM backend enregistrées avec le protocole de votre choix (HTTP ou TCP).

La terminaison SSL assure la confidentialité de la communication entre internet et le load balancer grâce à la vérification des informations d’authentification. La communication entre votre load balancer et ses VM backend enregistrées est en clair et sa sécurité est assurée par les règles que vous ajoutez aux security groups de vos VM backend. Vous pouvez par exemple souhaiter utiliser un load balancer avec terminaison SSL dans les cas où vous devez assurer un certain niveau de confidentialité, par exemple pour un site web qui requiert une authentification par identifiant et mot de passe.

Vous pouvez également envoyer des flux HTTPS vers des VM backend qui portent un certificat SSL à l’aide du protocole TCP. Grâce à cette méthode appelée SSL passthrough, le certificat est installé sur les VM backend plutôt que sur le load balancer. Le load balancer ne déchiffre pas les données circulant entre le client et les VM backend via le protocole TCP.

Pour en savoir plus sur comment configurer des listeners pour les load balancers avec terminaison SSL ou SSL passthrough, voir Configurer un load balancer pour une redirection SSL.

Vous pouvez créer un listener SSL ou HTTPS lorsque vous créez le load balancer, ou vous pouvez l’ajouter au load balancer à tout moment. Vous devez d’abord télécharger votre certificat serveur dans Elastic Identity Management (EIM), et le spécifier lorsque vous créez le listener en utilisant son OUTSCALE Resource Name (ORN). Pour en savoir plus, voir Travailler avec les certificats serveurs.

Pages connexes