À propos des Load Balancers
Un Load Balancer distribue le trafic réseau entrant entre plusieurs VMs pour répartir la charge 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.
- Répartir le trafic entre plusieurs Sous-régions (Availability Zones) ou Subnets.
- Configurer des health checks pour vérifier l’état de chaque VM et rediriger le trafic uniquement vers les instances saines.
Informations générales
Load Balancers et VMs backend
Les VMs enregistrées auprès d’un Load Balancer sont appelées VMs backend.
Vous pouvez enregistrer autant de VMs backend que nécessaire, et les (dés)enregistrer à tout moment selon vos besoins.
- Vous pouvez enregistrer une VM backend auprès d’un Load Balancer relié à Internet en utilisant sa Public IP.
Voir : Lier une Public IP à une VM ou à une interface réseau et Enregistrer des VMs auprès d’un Load Balancer. - Un Load Balancer est créé dans une Sous-région ou un Subnet spécifique, mais il peut distribuer du trafic vers toutes les Sous-régions de sa Région ou tous les Subnets de son réseau.
Selon leurs Security Groups, les VMs backend peuvent recevoir :
- uniquement le trafic venant du Load Balancer,
- ou le trafic provenant d’autres sources (par exemple un autre Load Balancer ou Internet).
Les Load Balancers fonctionnent en round robin : les requêtes entrantes sont réparties équitablement entre toutes les VMs backend.
Le Load Balancer effectue également des vérifications d’état (health checks) pour déterminer quelles VMs sont disponibles pour le trafic.
Pour en savoir plus, voir Configurer les health checks.
Un seul type de health check peut être configuré par Load Balancer.
Il est recommandé de créer un Load Balancer par service afin d’éviter les faux positifs ou la non-détection d’une panne.
Types de Load Balancers
Un Load Balancer peut être :
- Public (Internet-facing)
- Interne (privé)
-
Load Balancer public :
Créé dans un VPC, il distribue les flux entrants venant d’Internet entre les VMs backend situées dans différentes Sous-régions d’une même Région ou dans plusieurs Subnets d’un même VPC.
Ce type de Load Balancer est accessible depuis Internet. -
Load Balancer interne :
Créé dans un réseau privé (VPC ou Net), il distribue le trafic entre les VMs backend dans un ou plusieurs Subnets.
Ce type de Load Balancer est accessible uniquement depuis le CIDR interne du réseau.
Nom DNS
Chaque Load Balancer reçoit automatiquement un nom DNS, composé de son nom et de son endpoint (nom-du-load-balancer.endpoint
).
Ce nom DNS permet d’y accéder et d’y envoyer du trafic.
- Les Load Balancers publics reçoivent un nom DNS public.
- Les Load Balancers internes reçoivent un nom DNS privé.
Le nom DNS d’un Load Balancer interne est résolu vers son IP privée, que ce soit en interne (dans le réseau) ou publiquement (dans un environnement connecté).
Public IP
Les Public IP sont des adresses IPv4 publiques que vous pouvez allouer à votre compte NumSpot.
Elles peuvent être associées à des Load Balancers publics pour leur permettre de recevoir du trafic Internet.
Les adresses IP publiques associées peuvent :
- soit appartenir à NumSpot (lorsqu’elles sont créées automatiquement par la plateforme) ;
- soit être provisionnées dans votre propre espace compte (lorsque vous les allouez explicitement).
Le tableau ci-dessous décrit le comportement d’association selon les paramètres utilisés :
Méthode de l’API NumSpot | Spécification de la Public IP | Comportement d’association |
---|---|---|
CreateLoadBalancer | Spécifiée | La Public IP indiquée est associée au Load Balancer. |
CreateLoadBalancer | Non spécifiée | Une Public IP gérée par NumSpot est automatiquement créée et associée au Load Balancer. |
UpdateLoadBalancer | Spécifiée | Si la précédente IP vous appartenait, elle est dissociée. Si elle appartenait à NumSpot, elle est libérée. |
UpdateLoadBalancer | Spécifiée avec une valeur vide | Si la précédente IP vous appartenait, elle est remplacée par une IP gérée par NumSpot. Si elle appartenait déjà à NumSpot, elle reste inchangée. |
UpdateLoadBalancer | Non spécifiée | Aucun changement d’adresse IP. |
DeleteLoadBalancer | — | Si la Public IP vous appartient, elle est dissociée. Si elle est gérée par NumSpot, elle est automatiquement supprimée. |
Pour plus d’informations, voir À propos des Public IP.
Configuration
Listeners
Chaque Load Balancer doit être créé avec au moins un listener, c’est-à-dire un processus chargé d’écouter le trafic entrant sur un port et un protocole spécifiques.
Un listener définit :
- le protocole et le port frontend (côté client),
- et le protocole et port backend (côté VM).
Les protocoles pris en charge sont :
- HTTP / HTTPS
- TCP / SSL
- Les protocoles sécurisés pris en charge sont TLS 1.1 et TLS 1.2.
TLS 1.0 et les versions obsolètes de SSL ne sont pas supportées. - Un listener ne peut pas être modifié après création, mais vous pouvez en ajouter ou en supprimer plusieurs par Load Balancer.
Les ports doivent être compris entre 1 et 65535 inclus.
Les protocoles frontend et backend doivent être de même type :
- HTTP(S) → HTTP
- TCP/SSL → TCP
Vous pouvez également configurer des listener rules pour rediriger le trafic selon le chemin URI ou d’autres critères.
Voir Créer une listener rule.
Sessions persistantes
Par défaut, chaque requête réseau est distribuée indépendamment.
Pour maintenir la session d’un même utilisateur sur la même VM backend, vous pouvez activer les sessions persistantes (sticky sessions) à l’aide d’un cookie de persistance.
Deux modes existent :
- Basé sur une durée : le cookie a une durée fixe.
- Contrôlé par l’application : la session dure tant que le cookie défini par la VM backend est valide.
Les sessions persistantes sont disponibles uniquement pour les Load Balancers avec des listeners HTTP ou HTTPS.
En cas de défaillance de la VM backend, la session est automatiquement redirigée vers une VM saine et reste active jusqu’à expiration du cookie.
Vous pouvez activer des secure cookies, utilisables uniquement via HTTPS, pour renforcer la sécurité des sessions.
Redirections SSL
Vous pouvez activer le chiffrement du trafic entre les clients et le Load Balancer en configurant un listener HTTPS ou SSL à l’aide d’un certificat serveur x509.
Ce certificat, délivré par une autorité de certification, contient la clé publique et la signature utilisée pour l’authentification du serveur.
- Dans le cas d’une terminaison SSL, le Load Balancer déchiffre les requêtes avant de les transmettre aux VMs backend (trafic en clair interne).
- Dans le cas d’un SSL passthrough, le chiffrement est maintenu de bout en bout : le certificat est installé directement sur les VMs backend.
Le certificat SSL peut être remplacé à tout moment via l’API NumSpot ou la Console.
Pour plus d’informations, voir Remplacer le certificat SSL utilisé par un Load Balancer HTTPS.
Pour utiliser la terminaison SSL :
- Téléchargez votre certificat serveur dans Elastic Identity Management (EIM).
- Référencez-le via son NumSpot Resource Name (NRN) lors de la création du listener.
Il est recommandé d’utiliser un certificat par Load Balancer pour une gestion simplifiée et un renouvellement indépendant.