Un équilibreur de charge de passerelle (GWLB) fonctionne au niveau de la couche 3 (couche réseau) et distribue le trafic de manière transparente vers les serveurs principaux, améliorant ainsi la sécurité et la disponibilité des applications.
État de l'instance
Les instances GWLB peuvent se trouver dans les états suivants :
|
État de l'instance |
Description |
Type de verrouillage |
Suppression autorisée |
Mise à jour de la configuration autorisée |
|
En cours d'exécution |
Fonctionnement normal. |
Non applicable |
Oui |
Oui |
|
Création en cours |
Création en cours. |
Non applicable |
Non |
Non |
|
Mise à jour de la configuration |
Mise à jour de la configuration en cours. |
Non applicable |
Non |
|
|
Arrêté |
Instance arrêtée. |
Verrouillage pour impayés : verrouillé en raison d'un paiement en retard. Réglez le paiement pour déverrouiller. |
Non |
Version IP
Les instances GWLB acceptent le trafic IPv4.
L'instance GWLB utilise des adresses IPv4 privées issues de son sous-réseau pour communiquer avec les serveurs principaux.
Transfert inter-zones
Le transfert inter-zones est activé par défaut et ne peut pas être désactivé pour le moment. Une instance GWLB distribue le trafic vers les serveurs principaux situés dans toutes les zones de disponibilité activées de la région.
Unité maximale de transmission
L'unité maximale de transmission (MTU) correspond à la taille maximale d'un paquet pouvant être transmis sur un réseau. Elle inclut l'en-tête IP et la charge utile, mais exclut l'en-tête Ethernet.
-
Limite MTU du GWLB :
Taille maximale du paquet : 1 500 octets. Les paquets plus volumineux sont supprimés.
-
Paramètres MTU pour les appliances virtuelles réseau :
Le GWLB encapsule le trafic IP avec un en-tête Geneve (+68 octets) avant de le transférer vers les NVA. Pour gérer les paquets encapsulés de 1 500 octets, assurez-vous que :
Les trames Jumbo sont activées pour l'instance ECS sur laquelle la NVA est déployée.
-
La MTU de l'interface de la NVA est définie à au moins 1 568 octets.
Configurez cette MTU dans l'image de la NVA conformément à la documentation de votre fournisseur d'appliance.
-
Fragmentation IP :
Le GWLB ne prend pas en charge la fragmentation IP.
-
Découverte de la MTU du chemin (PMTUD) :
Le GWLB ne génère pas les messages ICMP nécessaires pour indiquer qu'une fragmentation est requise et ne prend donc pas en charge la PMTUD.
Délai d'inactivité de la connexion
Le délai d'inactivité de la connexion définit la durée pendant laquelle une connexion peut rester inactive avant que le GWLB ne la ferme. Le comportement du délai d'expiration dépend de l'algorithme de planification des flux et du type de trafic.
Gestion du trafic TCP
-
Lorsque l'algorithme de planification des flux est un hachage à cinq tuples :
Le GWLB suit l'état de la connexion TCP. Si aucune donnée n'est transférée pendant la période de délai d'expiration, la connexion est fermée et le trafic existant est supprimé. L'instance GWLB achemine le trafic ultérieur vers un nouveau serveur principal. Une nouvelle connexion est établie lors de la requête suivante.
Le délai d'expiration par défaut est de 350 secondes. Vous pouvez personnaliser le délai d'inactivité de la connexion TCP dans les paramètres de l'écouteur. Plage valide : 60 à 6 000 secondes.
Ajustez le délai d'inactivité de la connexion TCP pour optimiser l'utilisation des ressources :
Augmentez le délai d'expiration pour les connexions de longue durée (transactions financières, interactions avec la base de données, systèmes ERP). Faites correspondre ou dépassez les délais d'expiration des NVA principales pour éviter une terminaison prématurée. Par exemple, si le délai d'expiration de votre pare-feu est de 3 600 secondes, définissez celui du GWLB à 3 700 secondes.
Réduisez le délai d'expiration pour le trafic de courte durée ou sporadique afin de libérer les connexions inactives et de réduire la consommation de ressources.
RemarqueSi une connexion TCP se ferme activement avant le délai d'expiration, le GWLB supprime immédiatement son état.
-
Lorsque l'algorithme de planification des flux est un hachage à deux/trois tuples :
Le GWLB hache les flux par deux tuples (adresse IP source, adresse IP de destination) ou trois tuples (adresse IP source, adresse IP de destination, protocole) pour maintenir l'affinité du serveur. Si un flux reste inactif au-delà du délai d'expiration, son état est effacé et les paquets suivants peuvent être acheminés vers un autre serveur principal.
Le délai d'inactivité de la connexion est fixé à 350 secondes et ne peut pas être modifié.
Gestion du trafic non TCP
Bien que l'UDP soit sans connexion, le GWLB maintient l'état du flux en fonction de l'algorithme de planification pour garantir l'affinité du serveur. Si un flux reste inactif au-delà du délai d'expiration, son état est effacé et les paquets suivants peuvent être acheminés vers un autre serveur principal.
Le délai d'inactivité de la connexion pour le trafic non TCP est fixé à 120 secondes et ne peut pas être modifié.
Mode de trafic
Par défaut, le GWLB fonctionne en mode d'équilibrage de charge, transférant le trafic des endpoints GWLB vers les serveurs principaux.
Pour une réponse d'urgence, un dépannage ou une maintenance des NVA, basculez vers le mode de contournement. En mode de contournement, le GWLB renvoie le trafic directement à l'endpoint sans le transférer aux serveurs principaux, garantissant ainsi la continuité du service.
Non activé par défaut. Contactez votre gestionnaire de compte pour utiliser cette fonctionnalité.
|
Mode de trafic |
Mode d'équilibrage de charge |
Mode de contournement |
|
Comportement du GWLB |
Le GWLB transfère le trafic de l'endpoint vers les serveurs principaux pour traitement. |
Le GWLB renvoie le trafic directement à l'endpoint sans le transférer aux serveurs principaux. |
|
Diagramme d'architecture |
 |
 |
|
Cas d'utilisation |
Mode par défaut. Les pare-feu tiers traitent le trafic métier comme prévu. |
Utilisé pour la maintenance du réseau et du pare-feu :
|
|
Notes |
- |
|
Console
Dans la console GWLB, accédez à la page Instance Details. À droite de Traffic Processing Mode, cliquez sur Modify pour changer le mode de traitement du trafic.
API
Changez le mode de trafic en appelant UpdateLoadBalancerAttribute et en définissant le paramètre TrafficMode.
Les valeurs suivantes sont prises en charge pour le paramètre TrafficMode :
LoadBalance (par défaut) : mode d'équilibrage de charge
ByPass : mode de contournement
Interrogez le mode de trafic d'une instance GWLB avec :
Le passage au mode de contournement contourne le traitement de sécurité des NVA. Évaluez les risques de sécurité associés.
-
Lors du passage au mode d'équilibrage de charge avec des protocoles avec état, configurez les NVA (telles que les pare-feu) pour gérer le trafic en milieu de session. Sinon, les connexions existantes peuvent être interrompues.
Par exemple, pour le trafic TCP, le pare-feu doit être configuré pour permettre l'établissement d'une session TCP sans segment SYN initial.
-
Fonctionnement :
TCP utilise une poignée de main en trois étapes pour établir une connexion. Ce processus implique l'envoi d'un segment SYN par le client, la réponse du serveur avec un segment SYN-ACK et l'envoi d'un segment ACK par le client pour terminer la connexion.
Après le passage du mode de contournement au mode d'équilibrage de charge, le trafic est à nouveau acheminé via les NVA. Les NVA qui nécessitent le paquet SYN initial ne peuvent pas reconnaître les paquets en milieu de flux provenant de connexions existantes, ce qui entraîne l'interruption de ces connexions. Les nouvelles connexions ne sont pas affectées. Configurez votre NVA pour accepter les sessions TCP sans paquet SYN afin d'éviter les interruptions.
Exemple de configuration : sur un pare-feu FortiGate, activez
tcp-session-without-syndans la politique de pare-feu. Pour plus d'informations, consultez la documentation officielle de votre fournisseur de pare-feu.
-