Hadian et bienvenue à nouveau.
Dans cette vidéo, nous allons parler de l'équilibreur de charge Gateway en donnant un aperçu de haut niveau.
Avant de parler des équilibreurs de charge Gateway, il est important de comprendre l'énoncé
du problème et les défis auxquels l'organisation était confrontée.
L'inspection du trafic est l'un des éléments importants, en particulier pour les grandes entreprises.
Maintenant, l'inspection du trafic peut être liée aux IEDs, EFPs.
Il peut s'agir de pare-feu, de cas d'utilisation liés à l'inspection approfondie des paquets, etc.
Et c'est la raison pour laquelle, dans la plupart des entreprises, vous verrez une sorte d'appareil de réseau
virtuel lié aux IED, aux EFP, aux pare-feu qui ont été déployés dans les abus.
Examinons maintenant la question du point de vue architectural pour voir comment elle s'intègre.
Disons que vous avez un sous-réseau où tous vos serveurs d'application sont hébergés et qu'il est nécessaire
de procéder à une sorte d'inspection du trafic.
Les organisations utilisent donc une sorte d'appareil de réseau virtuel
lié aux EEI, aux EFP, etc. qui sont fournis par divers fournisseurs comme Cisco, ET cetera.
Et ce dispositif réseau peut se charger de l'inspection globale du trafic.
Supposons maintenant qu'il existe une passerelle Internet qui est utilisée pour envoyer et recevoir du trafic sur
Internet.
Ainsi, si un serveur d'application veut envoyer ou recevoir du trafic depuis l'Internet, ce
trafic va d'abord vers l'appareil de réseau où il est inspecté, puis il va vers la passerelle
Internet.
De même, le trafic provenant d'Internet est acheminé vers l'appareil de réseau où il est inspecté.
Après l'inspection, l'appareil réseau renvoie le trafic au serveur d'application.
C'est donc l'un des cas d'utilisation que l'on rencontre couramment dans les entreprises.
Maintenant, avant de continuer, comprenons, sur la base de cette architecture, comment les tables
de route peuvent être définies.
Maintenant, au niveau du sous-réseau 1 où les serveurs d'application sont hébergés, regardons dans la table des
routes ici vous définissez qu'il y aura une route par défaut du VPC local et la cible est locale.
Cependant, pour toute autre destination comme 0000, qui comprend également le trafic vers l'internet,
la cible est l'appliance réseau E9, donc tout le trafic provenant du serveur d'application n'est
pas destiné à La VPC ira d'abord vers l'appliance réseau.
Maintenant, au niveau de l'appareil réseau, vous avez une route locale ici et vous avez a0000 qui va vers la passerelle
Internet.
Le serveur d'application envoie donc d'abord le trafic destiné à la passerelle Internet à l'appliance réseau.
Network Appliance inspectera le trafic et l'enverra ensuite à la passerelle Internet.
C'est donc une partie.
La deuxième partie à prendre en compte ici est la route au niveau de la passerelle Internet également.
Et ici, vous pouvez définir tout le trafic qui va vers le sous-réseau du serveur d'application.
Donc si vous voyez le site, ce bloc est 1077 2. 0 slash 24, que vous pouvez voir ici, tout le trafic qui
va vers le sous-réseau, on devrait aller à la E neuf de l'appareil réseau.
Donc, quel que soit le réseau de l'appareil, c'est là que le trafic ira.
Très bien.
J'espère donc qu'avec cette vue d'ensemble de haut niveau, vous avez compris l'architecture de la mise
en œuvre de ce type d'installation.
Ce type d'architecture pose certains problèmes.
Tout d'abord, comme nous l'avons dit, le routage est effectué à un niveau interne de l'appareil réseau.
Par exemple, à partir de cette route, nous pouvons identifier que tout le trafic
qui va vers l'Internet va vers la cible de l'INA de l'appareil réseau.
C'est ce que dénote le premier pointeur.
Or, lorsque vous disposez d'une telle table de routage, vous rencontrez des problèmes liés à la haute disponibilité et à la mise à
l'échelle.
Par exemple, disons que cet appareil de réseau est tombé en panne.
Ce n'est rien d'autre qu'une instance facile.
Que se passe-t-il si cette instance EC 2 tombe en panne ?
Pourtant, selon la table de route, le trafic se dirigera vers l'INA.
Donc ce que vous aurez à faire si vous lancez une appliance réseau EC deux de plus, vous devrez
changer la table de route associée à la passerelle Internet ainsi que celle du sous-réseau du serveur d'application.
Le deuxième problème principal est la mise à l'échelle.
Puisque nous avons défini un seul INA.
Que se passe-t-il si dix instances de l'appliance réseau sont en cours d'exécution ?
C'est donc aussi l'un des problèmes auxquels vous serez confrontés ici.
Afin de surmonter ce problème, A a introduit un nouveau type d'équilibreurs de charge appelés "équilibreurs de charge
de passerelle", qui vous permettent de déployer et de gérer facilement les appareils virtuels.
Ainsi, dans ce type d'architecture, vous avez plusieurs ensembles d'appareils réseau et vous créez un équilibreur
de charge de passerelle.
Et cet équilibreur de charge de passerelle a aussi un point d'accès spécifique.
Ainsi, tout le trafic du serveur d'application, supposons-le, vers l'Internet, ira vers l'équilibreur de charge
de la passerelle.
Endpoint, qui à son tour le transmet à l'équilibreur de charge Gateway.
Et cet équilibreur de charge de passerelle peut distribuer le trafic à plusieurs ensembles d'appareils réseau en fonctionnement.
Dans ce type d'architecture, les choses sont beaucoup plus simples.
Vous bénéficiez d'une haute disponibilité puisqu'il existe plusieurs ensembles d'appareils réseau et vous
n'avez pas vraiment à vous soucier des problèmes de mise à l'échelle.
Maintenant, en parlant de l'équilibreur de charge Gateway, il y a un point très important à noter,
c'est que pour utiliser l'équilibreur de charge Gateway, les appareils doivent prendre en charge le protocole genic.
Par exemple, vous voyez que les instances EC2 via le point de terminaison de l'équilibreur de charge Gateway envoient le trafic
à l'équilibreur de charge Gateway.
Maintenant, cet équilibreur de charge de passerelle et cette appliance réseau doivent également communiquer, et c'est la raison pour
laquelle le protocole doit être pris en charge.
L'idée est donc que tout le trafic reçu des deux instances de la CE sera encapsulé en utilisant
le Geneve.
C'est donc un point que vous devez garder à l'esprit.
Il s'agit donc d'une vue d'ensemble de très haut niveau sur les équilibres de charge des passerelles, et c'est ainsi que se termine la vidéo d'aujourd'hui.