L'évolution des contrôleurs de distribution application

Dans le monde dynamique d’aujourd’hui, les organisations sont constamment confrontées au défi de fournir des applications critiques à des millions d’utilisateurs dans le monde entier. Il est extrêmement important qu’ils déploient des services réseau et application pour rendre les applications évolutives, sécurisées et disponibles. C’est l’une des principales raisons de l’évolution des contrôleurs de distribution application (ADC). Cependant, aucune de ces fonctionnalités ne peut être mise en œuvre sans une base solide dans la technologie d’équilibrage de charge de base. Commençons donc par comprendre l’importance de l’équilibrage de charge, comment il conduit à une distribution efficace des application et comment les ADC continuent d’évoluer et d’adopter le monde du cloud.

L’objectif de l’équilibrage de charge est d’équilibrer le trafic entrant du réseau ou des application sur plusieurs serveurs physiques et de faire en sorte que ces serveurs ressemblent à un seul serveur pour le monde extérieur. Il existe de nombreuses raisons pour cela, mais les principales raisons sont le besoin d’« évolutivité », de « haute disponibilité » et de « prévisibilité ».

L'évolutivité est la capacité à s'adapter de manière dynamique ou facile à une charge accrue sans affecter les performances existantes. La haute disponibilité (HA), quant à elle, est la capacité d'un site à rester disponible et accessible même en cas de défaillance d'un ou plusieurs systèmes. La virtualisation des services (imiter le comportement des composants logiciels pour accélérer et tester le développement application ) présente une opportunité intéressante en termes d’évolutivité et de disponibilité. Si le service ou le point de contact utilisateur est séparé des serveurs réels, l' application peut être mise à l'échelle en ajoutant davantage de serveurs. De plus, la défaillance d’un serveur individuel ne rendra pas l’ensemble de application indisponible. La prévisibilité est un peu moins claire car elle représente des morceaux de HA ainsi que certaines leçons apprises en cours de route. On peut le décrire au mieux comme le fait d’avoir le contrôle sur la manière et le moment où les services sont fournis en termes de disponibilité et de performances.

Aux débuts de l’Internet commercial, de nombreux aspirants millionnaires du secteur des dotcom ont découvert un sérieux problème dans leurs plans. Les mainframes n'avaient pas de logiciel de serveur Web (du moins jusqu'à l'AS/400e) et même s'ils en avaient, ils ne pouvaient pas se les permettre avec les budgets de démarrage. Ce qu'ils pouvaient se permettre, c'était du matériel serveur standard, disponible dans le commerce, provenant de l'un des fabricants de PC les plus répandus. Le principal problème avec la plupart d’entre eux était qu’il était impossible qu’un seul serveur basé sur PC puisse gérer le volume de trafic que leur entreprise allait générer. Et s’il tombait en panne, ils étaient hors ligne et en faillite. Heureusement, certains de ces gens avaient prévu de gagner des millions en résolvant ce problème particulier. Cela a conduit à la naissance de l’équilibrage de charge.

Avant l’apparition de dispositifs d’équilibrage de charge spécialement conçus et disponibles dans le commerce, de nombreuses tentatives ont été faites pour utiliser la technologie existante afin d’atteindre les objectifs d’évolutivité et de disponibilité. La technologie la plus répandue (et toujours utilisée) était le DNS round-robin.

Selon cette méthode, le DNS attribuerait un certain nombre d’adresses IP uniques à différents serveurs, sous le même nom DNS. Cela signifiait que la première fois qu'un utilisateur demandait une résolution pour « www.exemple.com », le serveur DNS transmettait chaque nouvelle connexion au premier serveur de la file jusqu'à ce qu'il atteigne le bas de la file, avant de revenir au premier serveur. Cette solution était simple et permettait une répartition uniforme des connexions sur un ensemble de machines.

D’un point de vue évolutif, cette solution a fonctionné remarquablement bien car elle offrait la possibilité d’ajouter un nombre presque illimité de serveurs à un nom DNS. Cependant, en ce qui concerne la disponibilité, la solution a créé un obstacle car le DNS n'avait aucune capacité de savoir si les serveurs répertoriés fonctionnaient ou non. Si un serveur devient indisponible et qu'un utilisateur tente d'y accéder, la demande peut être envoyée à un serveur en panne.

Un autre facteur déterminant du DNS round-robin était la prévisibilité, qui correspond à un niveau de confiance élevé qu'un utilisateur va être envoyé vers un serveur particulier. Cela s’articule autour de l’idée de persistance : le concept consistant à s’assurer qu’un utilisateur n’est pas équilibré sur un nouveau serveur une fois qu’une session a commencé ou lorsque l’utilisateur reprend une session précédemment suspendue. Il s’agit d’un problème très important que le DNS round-robin ne peut pas résoudre.

Pour résoudre ce problème, l’une des premières solutions spécialement conçues était l’équilibrage de charge intégré directement dans le logiciel application ou le système d’exploitation (OS) du serveur application . Bien qu'il y ait eu autant d'implémentations différentes que d'entreprises qui les ont développées, la plupart des solutions tournaient autour d'astuces réseau de base. Par exemple, une telle solution comportait tous les serveurs dans un pool (également appelé cluster), en plus de leur propre adresse IP physique.

Lorsque les utilisateurs tentaient de se connecter au service, ils se connectaient à l’IP du pool au lieu de l’IP physique du serveur. Quel que soit le serveur du pool qui répond en premier à la demande de connexion, l'utilisateur est redirigé vers une adresse IP physique (la sienne ou celle d'un autre système du pool) et la session de service démarre. L’un des principaux avantages de cette solution était que les développeurs application pouvaient utiliser diverses informations pour déterminer à quelle adresse IP physique le client devait se connecter. Par exemple, ils pourraient demander à chaque serveur du pool de conserver un décompte du nombre de sessions que chaque membre du pool gérait déjà, puis de diriger toutes les nouvelles demandes vers le serveur le moins utilisé.

Au départ, l’évolutivité de cette solution était évidente. Il vous suffisait de créer un nouveau serveur, de l'ajouter au pool et d'augmenter la capacité de votre application. Au fil du temps, cependant, l’évolutivité de l’équilibrage de charge basé sur les applications a été remise en question. Étant donné que les membres du pool devaient rester en contact permanent les uns avec les autres pour savoir à qui devait être adressée la prochaine connexion, le trafic réseau entre les membres du pool augmentait de manière exponentielle à chaque nouveau serveur ajouté au pool. Une fois que le pool a atteint une certaine taille (généralement 5 à 10 hôtes), ce trafic a commencé à avoir un impact sur le trafic des utilisateurs finaux ainsi que sur l’utilisation du processeur des serveurs eux-mêmes. Ainsi, l'évolutivité était excellente tant que vous n'aviez pas besoin de dépasser un petit nombre de serveurs (d'ailleurs, moins qu'avec le DNS round-robin).

La haute disponibilité a été considérablement augmentée grâce au DNS round-robin et à l'équilibrage de charge logiciel. Étant donné que les membres du pool étaient en communication constante entre eux et que les développeurs application pouvaient utiliser leurs vastes connaissances en application pour savoir quand un serveur fonctionnait correctement, ces solutions éliminaient pratiquement le risque que les utilisateurs accèdent à un serveur incapable de répondre à leurs demandes. Il convient toutefois de souligner que chaque itération des caractéristiques HA permettant l’intelligence avait un impact correspondant sur l’utilisation du serveur et du réseau, limitant encore davantage l’évolutivité. L’autre impact négatif du HA concernait la fiabilité. De nombreuses astuces réseau utilisées pour distribuer le trafic dans ces systèmes étaient complexes et nécessitaient une surveillance considérable au niveau du réseau. Par conséquent, ces méthodes de distribution rencontraient souvent des problèmes qui affectaient l’ensemble de application et tout le trafic sur le réseau de application .

Ces solutions ont également amélioré la prévisibilité. Étant donné que les concepteurs de application savaient quand et pourquoi les utilisateurs devaient être renvoyés vers le même serveur au lieu d'être équilibrés en charge, ils pouvaient intégrer une logique qui permettait de garantir que les utilisateurs resteraient persistants si nécessaire. Ils ont également utilisé la même technologie de « pooling » pour répliquer les informations d’état utilisateur entre les serveurs, éliminant ainsi de nombreuses instances qui nécessitaient une persistance en premier lieu. Enfin, grâce à leur connaissance approfondie des application , ils étaient mieux à même de développer des algorithmes d’équilibrage de charge basés sur l’état réel de l’ application plutôt que sur des éléments tels que les connexions, qui n’étaient pas toujours une bonne indication de la charge du serveur.

Outre les limitations potentielles en matière d’évolutivité réelle et les problèmes de fiabilité, l’équilibrage de charge basé sur les applications propriétaires présentait également un inconvénient supplémentaire : Le développement et la maintenance de application étaient assurés par le fournisseur. Le problème principal ici était que toutes les applications ne fournissaient pas de technologie d’équilibrage de charge (ou de pooling), et celles qui le faisaient ne fonctionnaient souvent pas avec celles fournies par d’autres fournisseurs application . Bien que plusieurs organisations aient produit des logiciels d'équilibrage de charge au niveau du système d'exploitation et indépendants des fournisseurs, elles ont malheureusement souffert des mêmes problèmes d'évolutivité. Et sans intégration étroite avec les applications, ces « solutions » logicielles ont également rencontré des défis supplémentaires en matière de haute disponibilité.

La deuxième itération de l'équilibrage de charge spécialement conçu est apparue sous la forme d'appareils basés sur le réseau. Ce sont les véritables pères fondateurs des contrôleurs de distribution application d’aujourd’hui. Ces appareils résidaient physiquement en dehors des applications elles-mêmes et, bien qu'ils aient commencé comme des équilibreurs de charge, ils ont réalisé leur équilibrage de charge à l'aide de techniques de réseau beaucoup plus simples comme NAT. Ces appareils présenteraient une adresse de serveur virtuel au monde extérieur et lorsque les utilisateurs tenteraient de se connecter, les appareils transmettraient la connexion au serveur réel le plus approprié.

L'équilibreur de charge pouvait contrôler exactement quel serveur recevait quelle connexion et utilisait des « moniteurs de santé » de complexité croissante pour garantir que le serveur application (un serveur physique réel) répondait comme nécessaire. Si le serveur ne répondait pas correctement, l’équilibreur de charge arrêtait automatiquement d’envoyer du trafic vers ce serveur jusqu’à ce qu’il produise la réponse souhaitée. Bien que les moniteurs de santé soient rarement aussi complets que ceux créés par les développeurs application eux-mêmes, l’approche matérielle basée sur le réseau pouvait fournir des services d’équilibrage de charge de base à presque toutes les application de manière uniforme et cohérente, créant enfin un point d’entrée de service véritablement virtualisé unique aux serveurs application .

D’un point de vue évolutivité, les organisations qui ont commencé à remplacer l’équilibrage de charge basé sur un logiciel par une solution basée sur du matériel ont constaté une baisse spectaculaire de l’utilisation de leurs serveurs. Cela leur a évité de devoir acheter des serveurs supplémentaires à court terme et a contribué à générer un retour sur investissement accru à long terme.

De même, HA a contribué à réduire la complexité de la solution et à fournir un équilibrage de charge indépendant des applications, ce qui a conduit à une plus grande fiabilité et à une plus grande profondeur en tant que solution. Le matériel d'équilibrage de charge basé sur le réseau a permis au propriétaire de l'entreprise de fournir un niveau élevé de disponibilité à toutes ses applications au lieu de quelques-unes avec équilibrage de charge intégré.

La prévisibilité était un élément essentiel ajouté par le matériel d’équilibrage de charge basé sur le réseau. Il était désormais beaucoup plus facile de prédire où une nouvelle connexion serait dirigée et beaucoup plus facile de la manipuler. Ces appareils ont ajouté de l'intelligence au processus, ce qui a permis de créer une distribution de charge contrôlée (par opposition à la distribution incontrôlée du DNS dynamique). Cela permettait aux propriétaires d’entreprise de répartir la charge sur les serveurs en fonction de la capacité de ces derniers à gérer la charge.

L'avènement de l'équilibreur de charge basé sur le réseau et de la virtualisation a apporté de nouveaux avantages en matière de sécurité et de gestion, tels que le masquage de l'identité des serveurs application auprès de la communauté Internet et la possibilité de « purger » les connexions d'un serveur afin qu'il puisse être mis hors ligne pour maintenance sans impact sur les utilisateurs. C’est sur cette base que les ADC sont nés.

Avec une fonction d'équilibrage de charge centrale, qui est également un proxy complet, le service informatique a vu un excellent endroit pour superposer et consolider les services nouveaux et émergents. Cela a conduit à un dispositif d’équilibrage de charge évoluant vers une plate-forme ADC extensible. En termes simples, le proxy est la base de l'équilibrage de charge et la technologie sous-jacente qui rend les ADC possibles.  

Lorsqu’on discute de la sécurité ADC, la virtualisation créée par proxy (la technologie de base) est essentielle. Qu'il s'agisse de déchargement du cryptage SSL/TLS, d'authentification centralisée ou même de pare-feu fluides pour les applications, la puissance de ces solutions réside dans le fait qu'un équilibreur de charge (édition matérielle ou virtuelle) est le point d'agrégation de la virtualisation sur toutes les applications. L’authentification centralisée est un exemple classique. Les mécanismes d’authentification et d’autorisation traditionnels ont toujours été intégrés directement dans l’ application elle-même. Tout comme pour l'équilibrage de charge basé sur les applications, chaque implémentation dépendait et était unique à l'implémentation de chaque application, ce qui donnait lieu à de nombreuses méthodes différentes. Au lieu de cela, en appliquant l’authentification au point d’entrée virtualisé à toutes les applications, une méthode d’authentification unique et uniforme peut être appliquée. Non seulement cela simplifie considérablement la conception et la gestion du système d’authentification, mais cela améliore également les performances des serveurs application eux-mêmes en éliminant la nécessité d’exécuter cette fonction. De plus, cela élimine également le besoin, en particulier dans les applications développées en interne, de consacrer du temps et de l’argent au développement de processus d’authentification dans chaque application distincte.

La disponibilité est l’attribut ADC le plus simple à rattacher à l’équilibreur de charge d’origine, car il est lié à tous les attributs de base de l’équilibreur de charge : évolutivité, haute disponibilité et prévisibilité. Cependant, les ADC vont encore plus loin que l’équilibreur de charge. La disponibilité des ADC représente également des concepts avancés tels que la dépendance des application et le provisionnement dynamique. Les ADC sont capables de comprendre que les applications fonctionnent désormais rarement de manière autonome : Ils s’appuient souvent sur d’autres applications pour réaliser leur conception. Ces connaissances augmentent la capacité de l'ADC à assurer la disponibilité des application en prenant également en compte ces autres processus. Les ADC les plus intelligents du marché fournissent également des interfaces programmatiques qui leur permettent de modifier dynamiquement la manière dont ils fournissent des services en fonction des entrées externes. Ces interfaces permettent un provisionnement dynamique et la mise à l'échelle/réduction automatisée requise pour les environnements modernes tels que les déploiements cloud et conteneurisés.

L’amélioration des performances était une autre extension évidente du concept d’équilibrage de charge. Les équilibreurs de charge amélioraient intrinsèquement les performances des applications en garantissant que les connexions n'étaient pas seulement dirigées vers les services disponibles (et répondant dans un délai acceptable), mais également vers les services avec le moins de connexions et/ou d'utilisation du processeur. Cela garantissait que chaque nouvelle connexion était prise en charge par le système le mieux à même de la gérer. Plus tard, lorsque le déchargement SSL/TLS (à l’aide de matériel dédié) est devenu un élément essentiel des offres d’équilibrage de charge, il a réduit la quantité de surcharge de calcul du trafic chiffré ainsi que la charge sur les serveurs back-end, améliorant ainsi leurs performances.

Les ADC d’aujourd’hui vont encore plus loin. Ces appareils incluent souvent des technologies de mise en cache, de compression et même de mise en forme du débit pour augmenter encore les performances globales et la diffusion des applications. De plus, plutôt que d’être les implémentations statiques d’appareils autonomes traditionnels fournissant ces services, un ADC peut utiliser son intelligence applicative innée pour n’appliquer ces services que lorsqu’ils génèrent un avantage en termes de performances, optimisant ainsi leur utilisation.

Par exemple, la technologie de compression —malgré la croyance commune—n’est pas nécessairement bénéfique pour tous les utilisateurs de l’ application. Certes, les utilisateurs disposant d’une faible bande passante peuvent bénéficier énormément de paquets plus petits puisque le goulot d’étranglement est le débit réel. Même les connexions qui doivent parcourir de longues distances peuvent en bénéficier, car des paquets plus petits signifient moins d'allers-retours pour transporter les données, diminuant ainsi l'impact de la latence du réseau. Cependant, les connexions à courte distance (par exemple, au sein du même continent) avec une bande passante importante peuvent être moins performantes lors de l'application de la compression. Étant donné que le débit n’est pas nécessairement le goulot d’étranglement, la surcharge supplémentaire liée à la compression et à la décompression ajoute une latence que le débit accru ne compense pas du point de vue des performances. En d’autres termes, si elle n’est pas correctement gérée, la technologie de compression comme solution peut être pire que le problème d’origine. Mais en appliquant intelligemment la compression uniquement lorsque cela est bénéfique pour les performances globales, un ADC optimise l'utilisation et le coût de la technologie de compression, laissant plus de cycles de processeur pour les fonctions qui en tireront le meilleur parti.

Parce que la transformation numérique est un impératif stratégique important, de nombreuses entreprises ont commencé à se lancer dans leur voyage vers le cloud. Avec le nombre croissant d' applications qui évoluent et changent le monde qui nous entoure, on pense que les organisations qui migrent vers le cloud bénéficieront de nombreux avantages tels qu'une plus grande agilité, des coûts opérationnels mieux alignés, une évolutivité à la demande et une plus grande concentration sur leur cœur de métier.  

Le « cloud » n’est pas une entité unique et amorphe de ressources partagées de calcul, de stockage et de réseau ; il est plutôt composé d’un mélange complexe de fournisseurs, d’infrastructures, de technologies et d’environnements qui sont souvent déployés dans plusieurs nœuds mondiaux. C’est la raison pour laquelle de nombreuses entreprises ont déployé des applications dans plusieurs clouds différents : publics, privés et même une combinaison de ceux-ci. C'est le multi-cloud : la nouvelle réalité.

Même dans ce paysage en évolution rapide, plusieurs facteurs ralentissent l’adoption du cloud. Le premier défi est l’étalement du multi-cloud, où les applications existantes ont été « déplacées et déplacées » et où les applications « nées dans le cloud » ont été déployées de manière non planifiée et non gérée. De plus, pour répondre à leurs besoins à court terme, les organisations ont tendance à utiliser des plateformes cloud disparates, des architectures différentes, des services application variés et plusieurs ensembles d’outils. Cela entraîne une complexité architecturale dans toute l’entreprise et rend le transfert applications d’un environnement à un autre beaucoup plus difficile, sans parler du coût élevé.

Les ADC sont l’évolution naturelle de l’espace réseau critique détenu par les équilibreurs de charge du passé. Bien que les ADC doivent beaucoup à ces appareils du passé, ils constituent une toute nouvelle génération offrant non seulement disponibilité, mais également performances et sécurité. Comme leur nom l’indique, ils s’occupent de tous les aspects permettant de livrer une application de la meilleure façon possible.

Grâce à des fonctionnalités avancées telles que intelligence applicative, le déchargement SSL et les interfaces programmatiques, les ADC modernes peuvent aider les organisations à développer leur activité et à atteindre les utilisateurs partout et à tout moment. Avec l’évolution constante des besoins du monde technique, les ADC sont également plus capables de s’adapter aux technologies les plus récentes dans les environnements multi-cloud et conteneurs.

En fin de compte, nous pouvons affirmer avec certitude que les ADC ne seront pas seulement le principal canal et point d’intégration par lequel les applications seront livrées de manière plus rapide, plus intelligente et plus sûre, mais continueront d’évoluer et d’adopter le monde du cloud d’abord.