Concepts - Load Balancer

Objectif

Le Load Balancer Public Cloud repose sur le projet OpenStack Octavia et offre de nombreuses possibilités de configuration. Le but de cette page est d'expliciter les concepts de configuration pour que vous puissiez avoir une meilleure compréhension des capacités du Load Balancer.

Load Balancer Configuration concepts

Les illustrations suivantes montrent 2 configurations : une minimale et une complète qui utilise toutes les fonctionnalités. Les chapitres suivants donne une définition de chacun des concepts présents dans ces illustrations.

Listener

Un Listener définit un point d'entrée pour le trafic qui sera traité par le Load Balancer. Ses attributs principaux sont le protocole et le port, par exemple HTTPS et 443. Vous pouvez définir plusieurs listeners sur un Load Balancer.

Les protocoles suivants sont disponibles pour le trafic entrant : HTTP, HTTPS, TCP, UDP, SCTP.

Un protocole spécifique est PROMETHEUS, il permet de configurer un point de terminaison prometheus et ne gère pas le trafic lui-même. Cela permet d’exporter des métriques vers Prometheus pour la supervision, mais n’est pas utilisé pour diriger du trafic applicatif. Retrouvez plus d'informations sur cette configuration sur cette page.

Pool

Un pool définit un ensemble de membres à qui est envoyé le trafic. Un pool est associé à un listener. Pour une configuration avancée avec les L7 Policies, il est possible qu'un listener redirige le trafic vers plusieurs pools. Les attributs principaux d'un pool sont l'algorithme (par exemple Round Robin) et le protocole utilisé pour transmettre le trafic aux membres (par exemple HTTPS).

Les protocoles suivants sont disponibles : HTTP, HTTPS, PROXY, PROXYV2, SCTP, TCP ou UDP.

Retrouvez plus d'informations sur le protocole proxy ici.

Le tableau suivant fournit la matrice de compatibilité entre le protocole du listener et le protocole du pool :

Membre

Un membre définit la configuration d'un serveur à qui le trafic est envoyé. Ses attributs principaux sont une IP (192.168.1.10) et le port (443). Un membre fait partie d'un pool.

Health Monitor

Le Health Monitor définit comment le load balancer va vérifier la santé des membres qui constituent le pool. Ses attributs principaux sont la méthode de vérification (par exemple PING) et des délais / timeouts. Un Health Monitor est associé à exactement un pool.

Les Health Monitors suivants sont disponibles : HTTP, HTTPS, PING, SCTP, TCP, TLS-HELLO, UDP-CONNECT.

Le tableau suivant fournit la matrice de compatibilité entre le protocole du pool et le type de Health Monitor :

Règle L7 (L7 Rule)

Une règle est une expression logique unique qui est évaluée sur une requête HTTP entrante, par exemple sur un Header HTTP ou sur une partie de l'URI. Une règle L7 est associée à exactement une Politique L7. Par exemple une règle L7 évalue si l'URI commence par "/api".

Politique L7 (L7 Policy)

Une politique L7 est l'association entre une ou plusieurs règles L7 et un listener. Son attribut principal est l'action qui est faite lorsque toutes les règles L7 associées retourne vrai. Par exemple, un utilisateur peut spécifier une politique L7 pour que toutes les requêtes dont l'URI commence par "/api" soit routées vers un pool spécifique.

Lorsqu'une requête arrive sur un listener, les politiques sont évaluées dans l'ordre défini par l'attribut position. Lorsqu'une politique retourne vrai, l'action est effectuée et l'évaluation s'arrête. Si toutes les politiques retournent faux, la requête est alors envoyée au pool par défaut du listener.

Considérations réseau

Selon la manière dont vos applications sont exposées (uniquement dans un réseau privé, ou depuis Internet), le Load Balancer devra utiliser ou non une Gateway et une Floating IP.

La configuration requise pour le Load Balancer Public Cloud varie en fonction du type de trafic entrant (privé ou public) et des adresses IP des membres (privées ou publiques). Les chapitres suivants présentent les 3 différents types d'architectures auxquels le Load Balancer peut répondre. Le tableau ci-dessous présente également les prérequis sur le réseau / les composants supplémentaires liés à chaque architecture.

Private to Private Load Balancer

Le trafic entrant provient d'un réseau privé et est routé vers des instances accessibles à partir de ce réseau privé. Dans ce cas, une adresse Floating IP ou une Public Gateway ne sont pas nécessaires.

Public to Private Load Balancer

Le trafic entrant depuis Internet est dirigé vers une adresse Floating IP associée au Load Balancer. Pour que cette Floating IP fonctionne correctement, une Gateway est indispensable : elle assure le routage entre l’adresse IP publique (Floating IP) et l’adresse IP privée du Load Balancer. Les instances derrière le Load Balancer sont situées sur un réseau privé et n'ont pas d'IP publique, ce qui garantit qu'elles restent complètement privées et isolées d'Internet.

Public to Public Load Balancer

Le trafic entrant depuis Internet est dirigé vers une adresse Floating IP associée au Load Balancer. Pour que cette Floating IP fonctionne correctement, une Gateway est indispensable : elle assure le routage entre l’adresse IP publique (Floating IP) et l’adresse IP privée du Load Balancer. Les instances vers lesquelles le Load Balancer route le trafic sont accessibles avec une IP publique. Le Load Balancer utilise donc l’adresse Floating IP avec une sortie pour atteindre ces instances.

Prérequis réseau

* : Pour que la Floating IP fonctionne correctement, une Gateway est indispensable : elle assure le routage entre l’adresse publique (Floating IP) et l’adresse privée du Load Balancer. L’espace client OVHcloud provisionne automatiquement ces deux composants. Si vous utilisez des outils basés sur l’API OpenStack — tels que la CLI OpenStack, Terraform ou l’interface graphique Horizon — vous devrez les créer manuellement.

Operating status et Provisioning status

Deux statuts sont utilisés pour tous les concepts de Load Balancer.

Le operating status décrit le fonctionnement du composant, tandis que le provisioning status décrit l'état du cycle de vie.

Le provisioning status est hérité des composants qui sont « contenus » par le composant père. Par exemple, si un membre est mis à jour, son provisioning status change, de même que le provisioning status du pool, du listener et du load balancer.

Dans la suite de la description, lorsque l'on utilise le terme « composant », il s'agit du composant et de tous les « composants » qu'il contient.

Provisioning status

La formulation est légèrement différente entre OpenStack et OVHcloud. Le tableau suivant fournit les 2 formulations.

Operating status

• ONLINE : le composant fonctionne normalement, ce qui signifie que tous les membres du pool sont en bonne santé.
• DRAINING : applicable à un membre d'un pool UDP : le membre n'accepte pas de nouvelles connexions, cela se produit parce que son weight a été défini sur 0.
• OFFLINE : il s'agit de l'état après une action de désactivation ou si le paramétrage de admin_state_up sur false est effectué sur un composant (listener ou load balancer). Ce statut est également utilisé lors de la création du composant.
• DEGRADED : Applicable au pool et au load balancer uniquement. Un ou plusieurs des composants contenus sont en erreur. Par exemple, si un membre est en ERROR, le pool et le load balancer sont également en mode DEGRADED.
• ERROR : le composant a échoué. Par exemple, le membre est considéré comme défaillant si son contrôle d'état (health monitoring) échoue. Un pool est considéré comme ayant échoué si tous ses membres sont en erreur.
• NO_MONITOR : Lorsqu'aucun health monitor n'est configuré pour ce pool, le membre et le pool auront un statut NO_MONITOR. Cela n'a aucun impact sur le listener ou sur le operating status du load balancer.

Aller plus loin

• Une documentation technique complète (en anglais) sur la page du projet OpenStack.

• Configurez votre premier load balancer avec ce guide.

Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

Échangez avec notre communauté d'utilisateurs.