AWS Elastic Load Balancing et Elastic Network Adapter
Cette section donne un aperçu des fonctionnalités AWS ELB et ENA et décrit également comment ces fonctionnalités sont déployées sur les instances de pare-feu virtuel vSRX.
Présentation d’AWS Elastic Load Balancing
Cette section fournit des informations sur AWS ELB.
Elastic Load Balancing (ELB) est un service d’équilibrage de charge pour les déploiements Amazon Web Services (AWS).
ELB distribue le trafic entrant des applications ou du réseau dans les zones de disponibilité ntra, telles que les instances Amazon EC2, les conteneurs et les adresses IP. ELB met à l’échelle votre équilibreur de charge au fur et à mesure que le trafic vers votre application évolue au fil du temps et peut s’adapter automatiquement à la grande majorité des charges de travail.
AWS ELB utilise des équilibreurs de charge d’application pour permettre l’automatisation à l’aide de certains services AWS :
Amazon Simple Notification Service: pour plus d’informations, reportez-vous à https://docs.aws.amazon.com/sns/latest/dg/welcome.html.
AWS Lambda: pour plus d’informations, voir https://docs.aws.amazon.com/lambda/latest/dg/welcome.html.
AWS Auto Scale Group— Pour plus d’informations, reportez-vous à https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html.
Avantages d’AWS Elastic Load Balancing
Assure un équilibrage de charge élastique pour la zone intra disponible en répartissant automatiquement le trafic entrant.
Offre la flexibilité nécessaire pour virtualiser vos cibles applicatives en vous permettant d’héberger davantage d’applications sur la même instance, de gérer de manière centralisée les paramètres de sécurité couche transport (TLS) et de décharger les charges de travail gourmandes en ressources processeur de vos applications.
Fournit des fonctionnalités de sécurité robustes telles que la gestion intégrée des certificats, l’authentification des utilisateurs et le déchiffrement SSL/TLS.
Prend en charge la mise à l’échelle automatique d’un nombre suffisant d’applications pour répondre aux différents niveaux de charge applicative sans nécessiter d’intervention manuelle.
Vous permet de surveiller vos applications et leurs performances en temps réel grâce aux métriques, à la journalisation et au suivi des demandes d’Amazon CloudWatch.
Offre un équilibrage de charge entre les ressources AWS et sur site à l’aide du même équilibreur de charge.
Composants d’AWS Elastic Load Balancing
Les composants d’AWS Elastic Load Balancing (ELB) sont les suivants :
Load balancers—Un équilibreur de charge sert de point de contact unique pour les clients. L’équilibreur de charge répartit le trafic applicatif entrant sur plusieurs cibles, telles que des instances EC2, dans plusieurs zones de disponibilité (AZ), augmentant ainsi la disponibilité de votre application. Vous ajoutez un ou plusieurs écouteurs à votre équilibreur de charge.
Listeners or vSRX instances: un écouteur est un processus de vérification des demandes de connexion, à l’aide du protocole et du port que vous configurez. En tant qu’écouteurs, les instances du pare-feu virtuel vSRX vérifient les demandes de connexion des clients à l’aide du protocole et du port que vous configurez et transfèrent les demandes à un ou plusieurs groupes cibles, en fonction des règles que vous définissez. Chaque règle spécifie un groupe cible, une condition et une priorité. Lorsque la condition est remplie, le trafic est transféré vers le groupe cible. Vous devez définir une règle par défaut pour chaque instance de pare-feu virtuel vSRX. Vous pouvez ajouter des règles qui spécifient différents groupes cibles en fonction du contenu de la demande (également appelé routage basé sur le contenu).
Target groups or vSRX application workloads—Chaque application de pare-feu virtuel vSRX en tant que groupe cible est utilisée pour acheminer les requêtes vers une ou plusieurs cibles enregistrées. Lorsque vous créez chaque instance de pare-feu virtuel vSRX en tant que règle d’écoute, vous spécifiez une application et des conditions de pare-feu virtuel vSRX. Lorsqu’une condition de règle est remplie, le trafic est transféré à l’application de pare-feu virtuel vSRX correspondante. Vous pouvez créer différentes applications de pare-feu virtuel vSRX pour différents types de requêtes. Par exemple, créez une application de pare-feu virtuel vSRX pour les demandes générales et d’autres applications de pare-feu virtuel vSRX pour les demandes de microservices de votre application.
AWS ELB prend en charge trois types d’équilibreurs de charge : les équilibreurs de charge d’applications, les équilibreurs de charge réseau et les équilibreurs de charge classiques. Vous pouvez sélectionner un équilibreur de charge en fonction des besoins de votre application. Pour plus d’informations sur les types d’équilibreurs de charge AWS ELB, consultez AWS Elastic Load Balancing.
Présentation de l’équilibreur de charge d’application
À partir de la version 18.4R1 de Junos OS, les instances du pare-feu virtuel vSRX prennent en charge AWS Elastic Load Balancing (ELB) à l’aide de l’équilibreur de charge d’application pour fournir une sécurité évolutive au trafic Internet à l’aide des services AWS natifs. Un équilibreur de charge applicative distribue automatiquement le trafic applicatif entrant et met à l’échelle les ressources pour répondre aux demandes de trafic.
Vous pouvez également configurer des vérifications de l’état pour surveiller l’état des cibles enregistrées afin que l’équilibreur de charge puisse envoyer des requêtes uniquement aux cibles saines.
Les principales caractéristiques d’un équilibreur de charge applicative sont les suivantes :
équilibrage de charge de couche 7
Prise en charge de HTTPS
Haute disponibilité
Caractéristiques de sécurité
Prise en charge des applications conteneurisées
Prise en charge de HTTP/2
Prise en charge des WebSockets
Prise en charge IPv6 native
Séances collantes
Contrôles d’intégrité avec surveillance opérationnelle, journalisation, suivi des demandes
Pare-feu d’applications Web (WAF)
Lorsque l’équilibreur de charge d’application reçoit une demande, il évalue les règles de l’instance du pare-feu virtuel vSRX par ordre de priorité pour déterminer la règle à appliquer, puis sélectionne une cible dans l’application pare-feu virtuel vSRX pour l’action de règle. Vous pouvez configurer une règle d’instance de pare-feu virtuel vSRX pour acheminer les demandes vers différents groupes cibles en fonction du contenu du trafic applicatif. Le routage est effectué indépendamment pour chaque groupe cible, même lorsqu’une cible est enregistrée auprès de plusieurs groupes cibles.
Vous pouvez ajouter et supprimer des cibles de votre équilibreur de charge en fonction de l’évolution de vos besoins, sans perturber le flux global de requêtes vers votre application. ELB met à l’échelle votre équilibreur de charge au fur et à mesure que le trafic vers votre application évolue au fil du temps. ELB peut mettre à l’échelle automatiquement la majorité des charges de travail.
La séquence de lancement de l’équilibreur de charge d’application et l’écran actuel peuvent être visualisés à l’aide des propriétés de l’instance du pare-feu virtuel vSRX. Lors de l’exécution du pare-feu virtuel vSRX en tant qu’instance AWS, la connexion à l’instance via SSH démarre une session sur Junos OS. La CLI standard de Junos OS peut être utilisée pour surveiller l’intégrité et les statistiques de l’instance du pare-feu virtuel vSRX. Si la balise #load_balancer=true est envoyée dans les données utilisateur, les messages de démarrage mentionnent que les interfaces Pare-feu virtuel vSRX sont configurées pour la prise en charge de l’ELB et de la mise à l’échelle automatique. Les interfaces eth0 et eth1 sont alors permutées.
Si une configuration Junos OS non prise en charge est envoyée à l’instance du pare-feu virtuel vSRX dans les données utilisateur, l’instance du pare-feu virtuel vSRX revient à sa configuration d’usine par défaut. Si la balise #load_balancer=true est manquante, les interfaces ne sont pas permutées.
Déploiement d’AWS Application Load Balancer
AWS ELB Application Load Balancer peut être déployé de deux manières :
Pare-feu virtuel vSRX derrière l’équilibreur de charge d’application AWS ELB
Sandwich ELB
- Pare-feu virtuel vSRX derrière le déploiement de l’équilibreur de charge applicative AWS ELB
- Déploiement en sandwich d’AWS ELB Application Load Balancer
Pare-feu virtuel vSRX derrière le déploiement de l’équilibreur de charge applicative AWS ELB
Dans ce type de déploiement, les instances du pare-feu virtuel vSRX sont attachées à l’équilibreur de charge de l’application, dans une ou plusieurs zones de disponibilité (AZ), et les charges de travail de l’application se trouvent derrière les instances du pare-feu virtuel vSRX. L’équilibreur de charge de l’application envoie du trafic uniquement à l’interface principale de l’instance. Pour une instance de pare-feu virtuel vSRX, l’interface principale est l’interface de gestion fxp0.
Pour activer ELB dans ce déploiement, vous devez permuter l’interface de gestion et l’interface de premier revenu.
La figure 1 illustre le déploiement du pare-feu virtuel vSRX derrière AWS ELB Application Load Balancer.
Activation d’AWS ELB avec le pare-feu virtuel vSRX derrière le déploiement de l’équilibreur de charge d’application AWS ELB
Voici les conditions préalables à l’activation d’AWS ELB avec le pare-feu virtuel vSRX derrière le type de déploiement de l’équilibreur de charge d’application AWS ELB :
Tout le trafic entrant et sortant vers ELB est surveillé à partir de l’interface ge-0/0/0 associée à l’instance de pare-feu virtuel vSRX.
L’instance de pare-feu virtuel vSRX au lancement comporte deux interfaces dans lesquelles les sous-réseaux contenant les interfaces sont connectés à la passerelle Internet (IGW). La limite de deux interfaces est définie par le déploiement du groupe AWS Auto Scaling. Vous devez définir au moins une interface dans le même sous-réseau qu’AWS ELB. Les interfaces supplémentaires peuvent être attachées par la fonction lambda.
La vérification de la source ou de la destination est désactivée sur l’interface eth1 de l’instance de pare-feu virtuel vSRX.
Pour le déploiement d’un équilibreur de charge d’application AWS ELB à l’aide du pare-feu virtuel vSRX derrière la méthode AWS ELB Application Load Balancer :
L’instance de pare-feu virtuel vSRX contient :
Données utilisateur d’initialisation du cloud (cloud-init) avec la balise ELB comme #load_balancer=true.
La configuration des données utilisateur avec la balise #junos-config, fxp0 (dhcp), ge-0/0/0 (dhcp) (doit être DHCP n’importe quel groupe de sécurité qu’il doit définir)
Cloud-Watch déclenche un service de notification simple (SNS), qui à son tour déclenche une fonction Lambda qui crée et attache une interface réseau élastique (ENI) avec une adresse IP élastique (EIP) à l’instance de pare-feu virtuel vSRX. Plusieurs nouvelles ENI (maximum de 8) peuvent être attachées à cette instance.
L’instance de pare-feu virtuel vSRX doit être redémarrée. Un redémarrage doit être effectué chaque fois que l’instance de pare-feu virtuel vSRX se lance ultérieurement avec des interfaces permutées.
Note:Le cluster de châssis n’est pas pris en charge si vous essayez de permuter l’ENI entre les instances et la surveillance IP.
Vous pouvez également lancer l’instance du pare-feu virtuel vSRX dans un groupe ASG (Auto Scaling Group). Ce lancement peut être automatisé à l’aide d’un modèle de formation de nuages (CFT).
Déploiement en sandwich d’AWS ELB Application Load Balancer
Dans ce modèle de déploiement, vous pouvez faire évoluer à la fois la sécurité et les applications. Pare-feu virtuel vSRX et les applications se trouvent dans des ASG différents, et chacun de ces ASG est attaché à un équilibreur de charge d’application différent. Ce type de déploiement ELB est un moyen simple et élégant de mettre à l’échelle manuellement les déploiements de pare-feu virtuel vSRX pour faire face aux augmentations de trafic prévues ou prévues, tout en offrant une haute disponibilité multi-AZ. Le déploiement garantit la haute disponibilité et l’évolutivité entrantes pour les déploiements AWS.
Étant donné que l’équilibreur de charge évolue dynamiquement, son adresse IP virtuelle (VIP) est un nom de domaine complet (FQDN). Ce nom de domaine complet se résout en plusieurs adresses IP en fonction de la zone de disponibilité. Pour activer cette résolution, l’instance du pare-feu virtuel vSRX doit être en mesure d’envoyer et de recevoir du trafic à partir du nom de domaine complet (ou des multiples adresses vers lesquelles il se résout).
Vous pouvez configurer ce nom de domaine complet à l’aide de la set security zones security-zone ELB-TRAFFIC address-book address ELB dns-name FQDN_OF_ELB commande.
La figure 2 illustre le déploiement sandwich de l’équilibreur de charge d’application AWS ELB pour le pare-feu virtuel vSRX.
Activation du déploiement sandwich d’AWS Application Load Balancer pour le pare-feu virtuel vSRX
Pour le déploiement sandwich de l’équilibreur de charge d’application AWS ELB pour le pare-feu virtuel vSRX :
Pare-feu virtuel vSRX reçoit la balise #load_balancer=true dans les données utilisateur cloud-init.
Dans Junos OS, le processus d’amorçage initial analyse le disque monté pour détecter la présence du fichier d’indicateur dans le fichier setup_vsrx . Si le fichier est présent, cela indique que les deux interfaces avec DHCP dans deux références virtuelles différentes doivent être configurées. Cette mise à jour de l’analyse et de la configuration est effectuée dans la configuration par défaut et au-dessus des données de l’utilisateur si le fichier d’indicateur est présent.
Note:Si des données utilisateur sont présentes, le temps de démarrage après la deuxième ou la troisième validation du processus mgd augmente.
Vous devez redémarrer l’instance de pare-feu virtuel vSRX. Redémarrez toutes les fois que l’instance de pare-feu virtuel vSRX est lancée avec des interfaces permutées.
Note:La prise en charge des clusters de châssis pour l’échange des interfaces réseau élastiques (ENI) entre les instances et la surveillance IP ne fonctionne pas.
Vous pouvez également lancer une instance de pare-feu virtuel vSRX dans un ASG et automatiser le déploiement à l’aide d’un modèle de formation cloud (CFT).
Création d’une pile CFT (Cloud Formation Template) pour le pare-feu virtuel vSRX derrière le déploiement de l’équilibreur de charge d’application AWS
Cette rubrique fournit des détails sur la façon d’appeler la création de la pile CFT (Cloud Formation Template) pour le déploiement non sandwich (avec le pare-feu virtuel vSRX derrière AWS Application Load Balancer) qui ne contient qu’un seul équilibreur de charge.
Avant d’invoquer la création de la pile CFT, assurez-vous que les éléments suivants sont déjà disponibles dans l’environnement AWS :
VPC créé et prêt à l’emploi.
Un sous-réseau de gestion
Un sous-réseau externe (sous-réseau pour l’interface du pare-feu virtuel vSRX recevant le trafic de l’ELB).
Un sous-réseau interne (sous-réseau pour l’interface du pare-feu virtuel vSRX envoyant du trafic à la charge de travail).
ID d’AMI de l’instance de pare-feu virtuel vSRX que vous souhaitez lancer.
Données utilisateur (configuration du pare-feu virtuel vSRX qui doit être validée avant que le trafic ne soit transféré à la charge de travail. Il s’agit d’une base de 64 données codées ne dépassant pas 4096 caractères ; Vous pouvez utiliser jusqu’à trois champs de données utilisateur si un seul champ de données dépasse 4096 caractères).
Fichier de clé EC2.
Récupérez le fichier de fonction lambda add_eni.zip à partir du référentiel Juniper Pare-feu virtuel vSRX GitHub et chargez-le dans votre compartiment S3 d’instances. Utilisez ces informations dans le champ Emplacement Lambda S3 du modèle.
Votre compte AWS doit disposer des autorisations nécessaires pour créer des fonctions Lambda sur diverses ressources de votre région.
Suivez les étapes suivantes pour appeler la création de la pile CFT pour AWS ELB avec le pare-feu virtuel vSRX derrière le déploiement de l’équilibreur de charge d’application AWS ELB.
- Cliquez sur le bouton Create Stack en haut à droite de la page CloudFormation.
- Sur la nouvelle page, sélectionnez la case d’option Télécharger un fichier modèle , puis cliquez sur le bouton Choisir un fichier , puis sélectionnez votre fichier modèle et cliquez sur Suivant.
- Sélectionnez votre fichier Amazon EC2 Key Pair et cliquez sur Next (Suivant).
- Passez à la page suivante avec l’option Configurer les options de pile et l’option Avancé , puis cliquez sur Suivant.
- Sur la page suivante, vous pourrez consulter et modifier les détails de la création de votre pile. Une fois que vous avez terminé la révision, cliquez sur le bouton Créer une pile en bas à droite de la page.
- Une fois la pile créée avec succès, cliquez sur Services>EC2 , puis sur Groupes Auto Scaling dans le menu de gauche.
Sur le côté droit de la page, vous devriez voir un groupe de mise à l’échelle automatique (ASG) avec le nom de la pile que vous avez créée.
Lorsque vous sélectionnez l’ASG que vous avez créé, les détails de l’ASG s’affichent en bas de la page.
Cliquez sur l’onglet Stratégies de mise à l’échelle pour créer une stratégie de mise à l’échelle pour cet ASG, afin de maintenir un certain nombre de vSRX dans l’ASG et de répondre à diverses demandes, selon vos besoins. Reportez-vous à la section « Exemple de stratégie de mise à l’échelle » dans la section « Exemples de données » de la rubrique ci-dessous.
Auto Scaling Group surveille l’état des instances du pare-feu virtuel vSRX. Une nouvelle instance apparaît automatiquement si une défaillance d’instance du pare-feu virtuel vSRX est détectée. Vous trouverez plus d’informations dans l’onglet Historique des activités de l’ASG et dans les journaux Cloudwatch.
- Cliquez sur Services>EC2 , puis sur Équilibreurs de charge dans le menu de gauche. Sur le côté droit de la page, vous devriez voir un équilibreur de charge (LB) avec le nom de la pile que vous avez créée. Vous pouvez sélectionner cet équilibreur de charge et afficher les détails de l’équilibreur de charge en bas de la page.
L’onglet Instances ci-dessus affiche les instances du pare-feu virtuel vSRX en cours d’équilibrage de charge par ce LB. Un nom DNS sera attribué à ce LB comme indiqué ci-dessus. Tout trafic HTTP envoyé à cet hôte sera transféré par le pare-feu virtuel vSRX à la charge de travail du serveur Web protégée par le pare-feu virtuel vSRX. Le nombre d’instances de pare-feu virtuel vSRX peut varier entre MinASGInstances et MaxASGInstances utilisées lors de la configuration, en fonction des critères de mise à l’échelle.
Exemple de configuration d’AWS Elastic Load Balancer avec instance de pare-feu virtuel vSRX pour le trafic HTTP
Vous devez disposer de l’adresse IP de votre serveur DNS et de l’adresse IP de votre serveur Web (ou si votre serveur Web se trouve derrière un équilibreur de charge, utilisez l’adresse IP de cet équilibreur de charge ci-dessous au lieu de l’adresse IP du serveur Web).
Après avoir utilisé vos adresses IP dans la configuration ci-dessous, convertissez cette configuration au format Base 64 (voir : https://www.base64encode.org/), puis collez la configuration convertie dans le champ UserData. Ce faisant, applique la configuration ci-dessous à la configuration par défaut existante sur un pare-feu virtuel vSRX lancé dans AWS, pendant le processus de création de la pile.
#load_balancer=true
#junos-config
system {
name-server {
<Your DNS Server IP>
}
syslog {
file messages {
any any;
}
}
}
security {
address-book {
global {
address websrv <Your Web Server IP>/32>;
}
}
nat {
source {
rule-set src-nat {
from interface ge-0/0/0.0;
to zone trust;
rule rule1 {
match {
source-address 0.0.0.0/0;
destination-port {
80;
}
}
then {
source-nat {
interface;
}
}
}
}
}
destination {
pool pool1 {
address <Your Web Server IP>/32>;
}
rule-set dst-nat {
from interface ge-0/0/0.0;
rule rule1 {
match {
destination-address 0.0.0.0/0;
destination-port {
80;
}
}
then {
destination-nat {
pool {
pool1;
}
}
}
}
}
}
}
policies {
from-zone untrust to-zone trust {
policy mypol {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone trust {
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
interfaces {
ge-0/0/0.0;
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
dhcp;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
dhcp;
}
}
}
}
routing-instances {
ELB_RI {
instance-type virtual-router;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
}
Présentation d’AWS Elastic Network Adapter (ENA) pour les instances de pare-feu virtuel vSRX
Amazon Elastic Compute Cloud (EC2) fournit l’adaptateur réseau élastique (ENA), l’interface réseau de nouvelle génération et les pilotes associés qui offrent une mise en réseau améliorée sur les instances de pare-feu virtuel vSRX EC2.
Amazon EC2 offre des capacités de mise en réseau améliorées par le biais de l’adaptateur réseau élastique (ENA).
Avantages
Prend en charge les interfaces d’équipement à files d’attente multiples. ENA utilise plusieurs files d’attente d’émission et de réception pour réduire les frais internes et augmenter l’évolutivité. La présence de plusieurs files d’attente simplifie et accélère le processus de mappage des paquets entrants et sortants vers un vCPU particulier.
Le pilote ENA prend en charge les fonctionnalités de déchargement TCP/IP standard telles que le déchargement de somme de contrôle et le déchargement de segmentation de transmission TCP (TSO).
Prend en charge la technologie de pilote réseau RSS (mise à l’échelle côté réception) qui permet une distribution efficace du traitement de réception réseau sur plusieurs processeurs dans des systèmes multiprocesseurs, pour une mise à l’échelle multicœur. Certains appareils ENA prennent en charge un mode de fonctionnement appelé file d’attente à faible latence (LLQ), qui permet d’économiser plusieurs microsecondes.
Présentation d’AWS Elastic Network Adapter
La mise en réseau améliorée utilise la virtualisation des E/S à racine unique (SR-IOV) pour fournir des capacités réseau hautes performances sur les types d’instances pris en charge. La SR-IOV est une méthode de virtualisation des équipements qui offre des performances d’E/S plus élevées et une utilisation du processeur plus faible par rapport aux interfaces réseau virtualisées traditionnelles. La mise en réseau améliorée offre une bande passante plus élevée, des performances de paquets par seconde (pps) plus élevées et des latences inter-instances toujours plus faibles. Il n’y a pas de frais supplémentaires pour l’utilisation de la mise en réseau améliorée.
ENA est une interface réseau personnalisée optimisée pour offrir un débit élevé et des performances de paquets par seconde (pps), ainsi que des latences constamment faibles sur les instances EC2 du pare-feu virtuel vSRX. En utilisant ENA pour les instances C5.large du pare-feu virtuel vSRX (avec 2 vCPU et 4 Go de mémoire), vous pouvez utiliser jusqu’à 20 Gbit/s de bande passante réseau. La mise en réseau améliorée basée sur ENA est prise en charge sur les instances du pare-feu virtuel vSRX.
Le pilote ENA expose une interface de gestion légère avec un ensemble minimal de registres mappés en mémoire et un jeu de commandes extensible via une file d’attente d’administration. Le pilote prend en charge une large gamme d’adaptateurs ENA, est indépendant de la vitesse de liaison (c’est-à-dire que le même pilote est utilisé pour 10 Gbit/s, 25 Gbit/s, 40 Gbit/s, etc.) et négocie et prend en charge diverses fonctionnalités. L’ENA permet de traiter le trafic Ethernet à haut débit et à faible coût en fournissant une paire de files d’attente Tx/Rx dédiée par cœur de processeur.
Les pilotes DPDK pour ENA sont disponibles sur https://github.com/amzn/amzn-drivers/tree/master/userspace/dpdk.
Lorsque des équilibreurs de charge d’application AWS ELB sont utilisés, les interfaces eth0 (première) et eth1 (seconde) sont échangées contre l’instance de pare-feu virtuel vSRX. AWS ENA détecte et relie l’interface avec le pilote de noyau correspondant.