Équilibrage de charge 101 : Écrous et boulons

Sur le marché dynamique et centré sur les applications d'aujourd'hui, les organisations subissent une pression de plus en plus forte pour fournir les informations, les services et les expériences que leurs clients attendent, et ce, rapidement, de manière fiable et sécurisée. Les fonctions clés du réseau et des applications, telles que l'équilibrage de charge, le chiffrement, l'accélération et la sécurité, peuvent être fournies via des contrôleurs de distribution d'applications (ADC), qui sont des appareils physiques ou virtuels fonctionnant comme des proxys pour les serveurs physiques. Avec l'explosion des applications, ainsi que les exigences imposées aux organisations par le cycle rigoureux d'intégration continue et de déploiement continu (CI/CD), il n'est pas étonnant que le marché des ADC devrait atteindre 2,9 milliards de dollars par an d'ici 2020.¹

Mais avant de nous tourner vers l’avenir, regardons comment nous en sommes arrivés là. L’équilibrage de charge basé sur le réseau est la base essentielle sur laquelle fonctionnent les ADC. Au milieu des années 1990, les premiers dispositifs matériels d’équilibrage de charge ont commencé à aider les organisations à faire évoluer leurs applications en répartissant les charges de travail sur les serveurs et les réseaux. Ces premiers appareils étaient neutres en termes d’application et résidaient en dehors des serveurs d’application eux-mêmes, ce qui signifie qu’ils pouvaient équilibrer la charge à l’aide de techniques de réseau simples. Essentiellement, ces appareils présenteraient une « adresse IP virtuelle » au monde extérieur et, lorsque les utilisateurs tenteraient de se connecter, ils transmettraient la connexion au serveur réel le plus approprié effectuant une traduction d'adresse réseau bidirectionnelle (NAT).

Cependant, avec l’avènement de la virtualisation et du cloud computing, une nouvelle itération d’ADC d’équilibrage de charge est arrivée sous la forme d’éditions virtuelles fournies par logiciel et destinées à s’exécuter sur des hyperviseurs. Aujourd’hui, les appareils virtuels peuvent fournir des services applicatifs avec la même étendue de fonctionnalités que ceux qui s’exécutent sur du matériel spécialement conçu. De plus, ces éditions virtuelles éliminent une grande partie de la complexité liée au déplacement des services d’application entre les environnements virtuels, cloud et hybrides, permettant aux organisations de lancer rapidement et facilement des services d’application dans des environnements cloud privés ou publics.

La dernière tendance en date dans le domaine des centres de données est la conteneurisation, une méthode de virtualisation des applications qui permet de déployer et d’exécuter des applications distribuées. Le processus isole les applications et les contient dans des espaces mémoire clairement délimités sur un système d'exploitation partagé, ce qui non seulement rend le développement et le déploiement d'une application plus faciles que la création d'un appareil virtuel, mais les rend également plus rapides. En raison des améliorations spectaculaires en termes de portabilité et de performances, la conteneurisation pourrait offrir aux entreprises une plus grande évolutivité et une plus grande agilité. À l’avenir, les architectures de conteneurs pourraient également aider les organisations à mieux tirer parti des différents environnements cloud.

Les ADC d’aujourd’hui ont évolué à partir des premiers équilibreurs de charge grâce au processus de virtualisation des services. Et désormais, avec les éditions virtuelles exclusivement logicielles, les ADC peuvent non seulement améliorer la disponibilité, mais également aider les organisations à fournir les applications évolutives, performantes et sécurisées dont leur entreprise a besoin. En fin de compte, tous ces services d’application virtualisés, ces déploiements d’infrastructures partagées et ces capacités de routage intelligentes ne seraient pas possibles sans la base solide de la technologie d’équilibrage de charge.

Pour comprendre comment les entreprises peuvent mieux relever les défis complexes d’un marché en constante évolution, explorons les fondements de la distribution d’applications : Équilibrage de charge 101.

Avant de commencer, passons en revue la terminologie de base de l’équilibrage de charge. Ce serait plus facile si tout le monde utilisait le même lexique ; malheureusement, chaque fournisseur de dispositifs d’équilibrage de charge (et, par conséquent, d’ADC) semble utiliser une terminologie différente. Avec quelques explications, nous pouvons cependant dissiper cette confusion.

La plupart des ADC d'équilibrage de charge utilisent les concepts de nœud, d'hôte, de membre ou de serveur ; certains ont les quatre, mais ils signifient des choses différentes. Ces termes tentent tous d’exprimer deux concepts fondamentaux. Un concept, généralement appelé nœud ou serveur, est l'idée du serveur physique ou virtuel lui-même qui recevra le trafic de l'ADC. Il s'agit de l'adresse IP du serveur physique et, en l'absence d'un équilibreur de charge, il s'agirait de l'adresse IP à laquelle le nom du serveur (par exemple, www.exemple.com) correspondrait. Dans la suite de cet article, nous désignerons ce concept par le terme d’hôte.

Le deuxième concept est exprimé par le terme « membre » (malheureusement également appelé nœud par certains fabricants). Un membre est généralement un peu plus défini qu'un hôte dans la mesure où il inclut le port TCP de l'application réelle qui recevra le trafic. Par exemple, un hôte nommé www.exemple.com peut être résolu en une adresse de 172.16.1.10, qui représente l'hôte, et peut avoir une application (un serveur Web) exécutée sur le port TCP 80, ce qui donne l'adresse membre 172.16.1.10:80. En termes simples, le membre inclut la définition du port de l'application ainsi que l'adresse IP du serveur physique/virtuel. Dans la suite de cet article, nous appellerons cela le service.

Pourquoi toute cette complexité ? Parce que la distinction entre un serveur et les services d’application exécutés sur celui-ci permet à l’équilibreur de charge d’interagir individuellement avec les applications plutôt qu’avec le matériel ou l’hyperviseur sous-jacent, dans un centre de données ou dans le cloud. Un hôte (172.16.1.10) peut avoir plusieurs services disponibles (HTTP, FTP, DNS, etc.). En définissant chaque application de manière unique (172.16.1.10:80, 172.16.1.10:21 et 172.16.1.10:53, par exemple), l'ADC peut appliquer un équilibrage de charge et une surveillance de l'état uniques (un concept que nous aborderons plus tard) en fonction des services plutôt que de l'hôte.

N'oubliez pas que la plupart des technologies basées sur l'équilibrage de charge utilisent un terme pour représenter l'hôte, ou le serveur physique, et un autre pour représenter les services disponibles sur celui-ci, dans ce cas, simplement l'hôte et les services.

L'équilibrage de charge permet aux organisations de répartir le trafic d'application entrant sur plusieurs destinations back-end, y compris les déploiements dans des clouds publics ou privés. Il est donc nécessaire d’avoir le concept d’une collection de destinations back-end. Les clusters, comme nous les appellerons (ils sont également connus sous le nom de pools ou de fermes), sont des collections de services similaires disponibles sur n'importe quel nombre d'hôtes. Par exemple, tous les services qui proposent la page Web de l'entreprise seraient regroupés dans un cluster appelé « page Web de l'entreprise » et tous les services qui proposent des services de commerce électronique seraient regroupés dans un cluster appelé « commerce électronique ».

Un serveur virtuel est un proxy du serveur réel (physique, virtuel ou conteneur). Associé à une adresse IP virtuelle, il s’agit du point de terminaison de l’application présenté au monde extérieur.

Avec une compréhension de ces termes, nous maîtrisons les bases de l’équilibrage de charge. L'ADC d'équilibrage de charge présente les serveurs virtuels au monde extérieur. Chaque serveur virtuel pointe vers un cluster de services qui résident sur un ou plusieurs hôtes physiques.

Bien que la figure 2 ne soit pas représentative d’un déploiement réel, elle fournit la structure élémentaire pour poursuivre une discussion sur le processus d’équilibrage de charge et de distribution d’applications.

Une fois ce vocabulaire commun établi, examinons la transaction simple consistant à livrer l’application au client. Comme illustré, l'ADC d'équilibrage de charge se trouve généralement en ligne entre le client et les hôtes qui fournissent les services que le client souhaite utiliser. Comme pour la plupart des choses dans la livraison d’applications, ce positionnement n’est pas une règle, mais plutôt une bonne pratique dans tout type de déploiement. Supposons également que l’ADC est déjà configuré avec un serveur virtuel qui pointe vers un cluster composé de deux points de service. Dans ce scénario de déploiement, il est courant que les hôtes disposent d'une route de retour qui pointe vers l'équilibreur de charge afin que le trafic de retour soit traité via celui-ci sur son chemin de retour vers le client.

La transaction de livraison d'application de base est la suivante :

• Le client tente de se connecter au service.
• L'ADC accepte la connexion et, après avoir décidé quel hôte doit recevoir la connexion, modifie l'IP de destination (et éventuellement le port) pour correspondre au service de l'hôte sélectionné (notez que l'IP source du client n'est pas touchée).
• L'hôte accepte la connexion et répond à la source d'origine, le client, via sa route par défaut, l'ADC.
• L'ADC intercepte le paquet de retour de l'hôte et modifie maintenant l'IP source (et le port possible) pour qu'il corresponde à l'IP et au port du serveur virtuel, puis renvoie le paquet au client.
• Le client reçoit le paquet de retour, pensant qu'il provient du serveur virtuel, et continue le processus.

Cet exemple très simple est relativement simple, mais il y a quelques éléments clés à noter. Tout d’abord, dans la mesure où le client le sait, il envoie des paquets au serveur virtuel et le serveur virtuel répond : c’est simple. Deuxièmement, le NAT a lieu. C'est ici que l'ADC remplace l'IP de destination envoyée par le client (du serveur virtuel) par l'IP de destination de l'hôte vers lequel il a choisi d'équilibrer la charge de la requête. La troisième partie de ce processus rend le NAT « bidirectionnel ». L'IP source du paquet de retour de l'hôte sera l'IP de l'hôte ; si cette adresse n'était pas modifiée et que le paquet était simplement transmis au client, le client recevrait un paquet de quelqu'un à qui il n'en a pas demandé un et le supprimerait simplement. Au lieu de cela, l'équilibreur de charge, se souvenant de la connexion, réécrit le paquet afin que l'IP source soit celle du serveur virtuel, résolvant ainsi ce problème.

Généralement, à ce stade, deux questions se posent : Comment l'ADC d'équilibrage de charge décide-t-il à quel hôte envoyer la connexion ? Et que se passe-t-il si l'hôte sélectionné ne fonctionne pas ?

Discutons d’abord de la deuxième question. Que se passe-t-il si l'hôte sélectionné ne fonctionne pas ? La réponse simple est qu'il ne répond pas à la demande du client et que la tentative de connexion expire finalement et échoue. Ce n’est évidemment pas une circonstance privilégiée, car elle ne garantit pas une haute disponibilité. C'est pourquoi la plupart des technologies d'équilibrage de charge incluent un certain niveau de surveillance de l'état pour déterminer si un hôte est réellement disponible avant de tenter de lui envoyer des connexions.

Il existe plusieurs niveaux de surveillance de la santé, chacun avec une granularité et une concentration croissantes. Un moniteur de base enverrait simplement un ping à l'hôte lui-même. Si l'hôte ne répond pas au ping, il est fort probable que tous les services définis sur l'hôte soient en panne et doivent être supprimés du cluster de services disponibles. Malheureusement, même si l'hôte répond au ping, cela ne signifie pas nécessairement que le service lui-même fonctionne. Par conséquent, la plupart des appareils peuvent effectuer des « pings de service » d'une certaine sorte, allant de simples connexions TCP jusqu'à l'interaction avec l'application via une interaction scriptée ou intelligente. Ces moniteurs de santé de niveau supérieur offrent non seulement une plus grande confiance dans la disponibilité des services réels (par opposition à l'hôte), mais ils permettent également à l'équilibreur de charge de différencier plusieurs services sur un seul hôte. L'équilibreur de charge comprend que même si un service peut être indisponible, d'autres services sur le même hôte peuvent fonctionner correctement et doivent toujours être considérés comme des destinations valides pour le trafic utilisateur.

Cela nous ramène à la première question : Comment l'ADC décide-t-il à quel hôte envoyer une demande de connexion ? Chaque serveur virtuel dispose d'un cluster de services dédié spécifique (répertoriant les hôtes qui offrent ce service) qui constitue la liste des possibilités. De plus, la surveillance de l'état de santé modifie cette liste pour créer une liste d'hôtes « actuellement disponibles » qui fournissent le service indiqué. C'est cette liste modifiée à partir de laquelle l'ADC choisit l'hôte qui recevra une nouvelle connexion. Le choix de l’hôte exact dépend de l’algorithme d’équilibrage de charge associé à ce cluster particulier. Certains de ces algorithmes incluent le minimum de connexions, le ratio dynamique et un simple round robin où l'équilibreur de charge parcourt simplement la liste en commençant par le haut et alloue chaque nouvelle connexion à l'hôte suivant ; lorsqu'il atteint le bas de la liste, il recommence simplement en haut. Bien que cela soit simple et très prévisible, cela suppose que toutes les connexions auront une charge et une durée similaires sur l’hôte back-end, ce qui n’est pas toujours vrai. Les algorithmes plus avancés utilisent des éléments tels que le nombre de connexions actuelles, l'utilisation de l'hôte et même les temps de réponse réels pour le trafic existant vers l'hôte afin de choisir l'hôte le plus approprié parmi les services de cluster disponibles.

Les systèmes de distribution d’applications suffisamment avancés seront également capables de synthétiser les informations de surveillance de l’état de santé avec des algorithmes d’équilibrage de charge pour inclure une compréhension de la dépendance des services. Ceci est principalement utile dans les cas où un seul hôte dispose de plusieurs services, tous nécessaires pour répondre à la demande de l'utilisateur. Dans un tel cas, vous ne souhaitez pas qu'un utilisateur accède à un hôte qui dispose d'un service opérationnel mais pas de l'autre. En d’autres termes, si un service échoue sur l’hôte, vous souhaitez également que l’autre service de l’hôte soit retiré de la liste des services disponibles du cluster. Cette fonctionnalité devient de plus en plus importante à mesure que les services deviennent plus différenciés avec HTML et scripts.

La partie de l’équilibrage de charge qui implique la sélection d’un service disponible lorsqu’un client lance une demande de transaction ne représente que la moitié de la solution. Une fois la connexion établie, l'ADC doit vérifier si le trafic suivant provenant de cet utilisateur doit être équilibré. Il existe généralement deux problèmes spécifiques liés à la gestion du trafic de suivi une fois la charge équilibrée : la maintenance de la connexion et la persistance.

Si l'utilisateur tente d'utiliser une connexion TCP de longue durée (port 21 : FTP, port 23 : Telnet ou autre) qui ne se ferme pas immédiatement, l'équilibreur de charge doit s'assurer que plusieurs paquets de données transportés via cette connexion ne sont pas équilibrés en charge vers d'autres hôtes de service disponibles. Il s’agit d’une maintenance de connexion et nécessite deux capacités clés. La première est la possibilité de suivre les connexions ouvertes et le service hôte auquel elles appartiennent. Deuxièmement, l’équilibreur de charge doit pouvoir continuer à surveiller cette connexion afin que la table de connexion puisse être mise à jour lorsque la connexion se ferme. Il s’agit d’un tarif assez standard pour la plupart des ADC.

Il est cependant de plus en plus courant que le client utilise plusieurs connexions TCP de courte durée (par exemple, le port 80 : HTTP) pour accomplir une tâche unique. Dans certains cas, comme la navigation Web standard, cela n'a pas d'importance et chaque nouvelle demande peut être envoyée à l'un des hôtes de service back-end ; cependant, il existe de nombreux cas (XML, commerce électronique, etc.) où il est extrêmement important que plusieurs connexions du même utilisateur soient envoyées au même hôte de service back-end et ne soient pas équilibrées en charge. Ce concept est appelé persistance ou affinité du serveur.

Il existe plusieurs façons d’aborder ce problème, en fonction du protocole et des résultats souhaités. Par exemple, dans les transactions HTTP modernes, le serveur peut spécifier une connexion « keep-alive », qui transforme ces multiples connexions de courte durée en une seule connexion de longue durée, qui peut être gérée comme les autres connexions de longue durée. Cependant, cela n’apporte qu’un soulagement limité, principalement parce qu’à mesure que l’utilisation des services Web et mobiles augmente, maintenir toutes les connexions ouvertes plus longtemps que nécessaire met à rude épreuve les ressources de l’ensemble du système. C'est pourquoi aujourd'hui, dans un souci d'évolutivité et de portabilité, de nombreuses organisations s'orientent vers la création d'applications sans état qui s'appuient sur des API. Cela signifie essentiellement que le serveur oubliera toutes les informations de session pour réduire la charge sur les ressources et dans ces cas, l'état est maintenu en transmettant les identifiants de session ainsi que par le concept de persistance.

L’une des formes les plus élémentaires de persistance est l’affinité d’adresse source, qui consiste simplement à enregistrer l’adresse IP source des requêtes entrantes et l’hôte de service sur lequel elles ont été équilibrées, et à faire en sorte que toutes les transactions futures soient dirigées vers le même hôte. Il existe deux façons d’y parvenir : utiliser des identifiants de session SSL et des cookies. La persistance SSL suit la session SSL à l'aide des identifiants de session SSL, ce qui signifie que même lorsque l'adresse IP du client change, l'équilibreur de charge reconnaîtra la session persistante en fonction de l'identifiant de session. La persistance basée sur les cookies offre la possibilité d'insérer un cookie sur l'ordinateur d'un client pour identifier de manière unique une session, puis de faire référence à ce cookie dans les requêtes, afin que la connexion soit établie avec le bon serveur.

Aujourd’hui, l’intelligence des ADC permet aux organisations d’ouvrir les paquets de données et de créer des tables de persistance pour pratiquement tout ce qu’ils contiennent. Cela leur permet d’utiliser des informations uniques, telles que le nom d’utilisateur, pour maintenir la persistance. Cependant, les organisations doivent s'assurer que ces informations client identifiables seront présentes dans chaque demande effectuée, car tous les paquets sans elles ne seront pas conservés et seront à nouveau équilibrés, ce qui endommagera probablement l'application.

Au début, l’équilibrage de charge visait à répartir les charges de travail sur l’ensemble du réseau et à garantir la disponibilité des applications et des services. Cependant, à mesure que la technologie a évolué, les équilibreurs de charge sont devenus des plates-formes de distribution d'applications, garantissant que les applications critiques d'une organisation étaient hautement disponibles et sécurisées. Bien que l’équilibrage de charge de base reste la base de la distribution d’applications, les ADC modernes offrent des fonctionnalités beaucoup plus avancées.

Les entreprises se rendent compte que le simple fait de pouvoir accéder à une application ne la rend pas utilisable, et que les applications inutilisables représentent une perte de temps et d’argent pour l’organisation qui les déploie. C'est là qu'intervient l'ADC moderne, permettant aux organisations de consolider les services basés sur le réseau tels que le déchargement SSL/TLS, la mise en cache, la compression, la mise en forme du débit, la détection d'intrusion, les pare-feu d'application et même l'accès à distance en un seul point stratégique qui peut être partagé et réutilisé sur tous les services d'application et tous les hôtes pour créer un réseau de distribution d'applications virtualisé. Cela permet aux équipes réseau, applicatives et opérationnelles de mieux répondre aux demandes commerciales en matière de délais de livraison plus courts et d’évolutivité accrue, sans jamais sacrifier le besoin de sécurité.

Si vous souhaitez en savoir plus sur le fonctionnement de la distribution d'applications avancées et sur l'avenir des ADC, lisez L'évolution des contrôleurs de distribution d'applications et Allez au-delà du simple équilibrage de charge .