Un load balancer distribue le trafic réseau entrant entre plusieurs instances Flexible Compute Unit (FCU) du Cloud public ou d'un Virtual Private Cloud (VPC) pour éviter leur surcharge et augmenter la disponibilité et la fiabilité de vos services.

Vous pouvez :

  • Distribuer la charge réseau à l'aide des protocoles TCP/SSL et HTTP/HTTPS

  • Distribuer la charge réseau entre plusieurs Availability Zones (AZ) ou subnets
  • Configurer des health checks pour vérifier l’état de chacune des instances et envoyer le trafic uniquement aux instances saines
Pour le protocole SSL, les load balancers 3DS OUTSCALE prennent en charge les protocoles successeurs TLS 1.1 et TLS 1.2. Ils ne prennent pas en charge le TLS 1.0 ainsi que les versions obsolètes de SSL.

Les sujets suivants sont abordés : 


Informations générales

Load balancers et instances back-ends

Les instances enregistrées auprès d'un load balancer sont appelées des instances back-ends. Lorsqu'une instance est enregistrée auprès d'un load balancer, celle-ci reçoit des requêtes front-ends. Vous pouvez enregistrer autant d'instances back-ends auprès d'un load balancer que nécessaire, et vous pouvez enregistrer de nouvelles instances back-ends ou les désenregistrer à tout moment selon vos besoins. Une instance qui a été désenregistrée d'un load balancer peut être enregistrée à nouveau auprès de celui-ci si besoin.

Dans le Cloud public, vous pouvez distribuer la charge réseau entre des instances placées dans la même AZ ou dans différentes AZ d'une même Région. Dans un VPC, vous pouvez distribuer la charge réseau entre des instances placées dans un ou plusieurs subnets, dans la même AZ ou dans différentes AZ de la même Région, que vous spécifiez lors de la création du load balancer. Pour en savoir plus, voir À propos des VPC et Référence des Régions, Availability Zones et endpoints

Selon la configuration des security groups de vos instances back-ends, celles-ci peuvent recevoir uniquement le trafic venant du load balancer ou venant à la fois du load balancer et d'une autre source (par exemple un autre load balancer, internet, et ainsi de suite).

Les load balancers fonctionnent en mode round robin : les requêtes front-ends sont distribuées de façon égale entre les instances back-ends à tour de rôle. La quantité de requêtes front-ends reçue par une instance back-end correspond ainsi au nombre total de requêtes front-ends divisé par le nombre total d'instances back-ends.

Le load balancer vérifie la santé des instances back-ends puis distribue la charge réseau entre les instances saines. Pour en savoir plus sur les health checks, voir Configurer les health checks.

Vous ne pouvez configurer qu'un type de health checks par load balancer en spécifiant le port et le protocole des instances back-ends à vérifier. Nous vous recommandons donc de créer un load balancer par service pour éviter qu'une panne ne soit pas détectée. 

 

Types de load balancers

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

  • Un load balancer relié à internet peut être créé dans le Cloud public ou dans un VPC. Ce type de load balancer distribue les flux entrants venant d'internet entre les instances back-ends qui peuvent être placées dans différentes AZ du Cloud public ou différents subnets d'un VPC. Ce load balancer a un nom DNS public et vous pouvez y accéder depuis internet.


  • Un load balancer interne peut être uniquement créé dans un VPC. Ce type de load balancer distribue la charge réseau entre les instances back-ends placées dans un ou plusieurs subnets d'un VPC. Ce load balancer a un nom DNS privé et vous pouvez y accéder uniquement depuis votre réseau privé.

Nom DNS et listeners

Un nom DNS est automatiquement attribué à chaque load balancer et est composé du nom du load balancer et de son endpoint (nom-load-balancer.endpoint). Pour en savoir plus, voir Référence des Régions, Availability Zones et endpoints

Ce nom DNS vous permet de contacter votre load balancer et de lui envoyer des requêtes. Les load balancers reliés à internet reçoivent un nom DNS public, alors que les load balancers internes reçoivent un nom DNS privé. 

Chaque load balancer doit être créé avec un listener pour pouvoir recevoir des requêtes. Un listener correspond au processus gérant les requêtes arrivant au load balancer depuis internet ou 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 instances back-ends.

Les load balancers 3DS OUTSCALE supportent 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 front-end et back-end doivent être de même niveau, ainsi : 

  • Si le protocole front-end est HTTP ou HTTPS, le protocole back-end doit être HTTP. 
  • Si le protocole front-end est TCP ou SSL, le protocole back-end doit être TCP.

Le numéro du port sur lequel les instances back-ends écoutent doit être compris entre 1 et 65535, tous deux inclus.

Vous ne pouvez pas modifier la configuration d'un listener une fois celui-ci créé. Vous pouvez cependant ajouter autant de listeners que nécessaire à un load balancer, et les supprimer au besoin. Pour en savoir plus, voir Ajouter ou supprimer des listeners.

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 instance back-end spécifique selon un chemin d'accès dans l'URI de la requête. Pour en savoir plus, voir Créer une listener rule

Sessions persistantes

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 instances back-ends différentes. Toutefois, vous pouvez utiliser une politique de sessions persistantes (sticky sessions) pour lier l'utilisateur à l'instance back-end ayant traité la première requête.

Les sessions persistantes fonctionnent au moyen d'un cookie de persistance, avec une durée spécifique. Elles sont disponibles uniquement pour les load balancers ayant des listeners HTTP ou HTTPS. À l'expiration du cookie de persistance, la session persistante est réinitialisée et la prochaine requête crée alors une nouvelle session persistante.

Il existe deux types de politiques de sessions persistantes :

  • Reposant sur une durée : Le cookie de persistance a une durée spécifique dans le temps.
  • Contrôlée par une application : Le cookie de persistance a la même durée que celle d'un cookie de l'instance back-end.
En cas de défaillance de l'instance back-end à laquelle l'utilisateur est lié, la session persistante est réinitialisée vers les instances saines. La session persiste alors sur une autre instance jusqu'à l'expiration du cookie, même si l'instance d'origine redevient saine.

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



Redirections SSL pour les 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 instances back-end enregistrées avec le protocole de votre choix (HTTP ou TCP).

Le certificat utilisé par le load balancer pour la terminaison SSL peut être remplacé à tout moment. Pour en savoir plus, voir Remplacer le certificat SSL utilisé par un load balancer HTTPS.

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 instances back-ends enregistrées est en clair et sa sécurité est assurée par les règles que vous ajoutez aux security groups de vos instances back-ends. 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 instances back-ends 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 instances back-end plutôt que sur le load balancer. Le load balancer ne déchiffre pas les données circulant entre le client et les instances back-end 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. 

Il est recommandé d'utiliser un certificat par load balancer.