NLB utilise des contrôles d'intégrité pour déterminer la disponibilité des serveurs backend. Lorsqu'un serveur échoue aux contrôles d'intégrité, NLB cesse de lui transférer de nouvelles requêtes et redistribue le trafic vers les serveurs sains. Lorsque le serveur récupère, NLB reprend automatiquement le transfert. Les contrôles d'intégrité améliorent la disponibilité du service et préviennent les points de défaillance uniques (SPOF).
Processus de contrôle d'intégrité
Les instances NLB s'exécutent en clusters. Les nœuds du cluster transfèrent le trafic et effectuent les contrôles d'intégrité.
Les nœuds du cluster fonctionnent de manière indépendante, transférant le trafic et exécutant les contrôles d'intégrité en parallèle.
Si NLB détecte un serveur backend non sain alors que la vidange de connexion est désactivée, les sessions existantes se terminent avant la fermeture des connexions. NLB cesse de transférer les nouvelles requêtes vers ce serveur.
Si NLB détecte un serveur backend non sain alors que la vidange de connexion est activée, les sessions existantes se poursuivent jusqu'à l'expiration du délai de vidange. NLB cesse de transférer les nouvelles requêtes vers ce serveur.
NLB utilise son adresse IP locale pour les contrôles d'intégrité. Assurez-vous que cette adresse IP n'est pas bloquée par les serveurs backend. Aucune règle de groupe de sécurité ECS n'est nécessaire, mais si d'autres politiques de sécurité sont en place (telles qu'iptables), autorisez cette adresse IP.
Lorsque tous les serveurs backend échouent aux contrôles d'intégrité, NLB passe en mode best-effort et transfère les requêtes à tous les serveurs pour maintenir la disponibilité.
Fonctionnement
Contrôles d'intégrité TCP
NLB envoie des sondes TCP personnalisées pour tester la disponibilité des serveurs backend.
Processus de contrôle d'intégrité TCP :
NLB envoie des paquets TCP SYN à l'adresse IP interne et au port de contrôle d'intégrité de chaque serveur backend.
Si le port est en écoute, le serveur backend renvoie un paquet SYN-ACK.
Si aucun SYN-ACK n'est reçu avant l'expiration du délai de réponse, le serveur est déclaré non sain. NLB envoie un paquet RST pour fermer la connexion.
Si un SYN-ACK est reçu avant l'expiration du délai, le serveur réussit le contrôle d'intégrité. NLB envoie un ACK suivi immédiatement d'un RST pour fermer la connexion.
Lors des contrôles d'intégrité, NLB termine la poignée de main trois voies et envoie immédiatement un RST pour fermer la connexion. Cela peut provoquer de fausses erreurs de connexion TCP sur les serveurs backend, qui peuvent enregistrer des erreurs Connection reset by peer dans les journaux logiciels, tels que les journaux du pool de connexions Java.
Solutions :
Configurez des contrôles d'intégrité HTTP pour les écouteurs TCP.
Activez la conservation de l'IP client sur les serveurs backend et ignorez les erreurs de réinitialisation de connexion provenant des blocs CIDR de NLB.
Contrôles d'intégrité UDP
Les contrôles d'intégrité UDP prennent en charge deux méthodes :
Méthode 1 : Contrôles d'intégrité sur les ports
La figure suivante illustre le déroulement des contrôles d'intégrité.
Processus de contrôle d'intégrité des ports UDP :
NLB envoie une requête ICMP à l'adresse IP interne du serveur backend.
NLB envoie un paquet de sonde UDP à l'adresse IP interne et au port de contrôle d'intégrité du serveur backend.
Si le serveur backend renvoie une réponse ICMP avant l'expiration du délai et ne renvoie pas de message
Port XX Unreachable, le serveur réussit le test. Sinon, il échoue.
Méthode 2 : Contrôles d'intégrité personnalisés
La figure suivante illustre le déroulement des contrôles d'intégrité.
Processus de contrôle d'intégrité UDP personnalisé :
NLB envoie un paquet de sonde UDP avec un contenu spécifié à l'adresse IP interne et au port de contrôle d'intégrité du serveur backend.
Si NLB reçoit la réponse attendue avant l'expiration du délai, le serveur réussit le test. Sinon, il échoue.
Contrôles d'intégrité HTTP
Pour les écouteurs de couche 4 (TCP ou UDP), vous pouvez configurer des contrôles d'intégrité HTTP qui envoient des requêtes HEAD ou GET pour vérifier la disponibilité des serveurs backend.
Processus de contrôle d'intégrité HTTP :
NLB envoie une requête HTTP HEAD ou GET avec le nom de domaine spécifié à l'adresse IP interne et au chemin de contrôle d'intégrité du serveur backend.
Le serveur backend renvoie un code d'état HTTP basé sur son état.
Si aucune réponse n'est reçue avant l'expiration du délai, le serveur échoue au contrôle d'intégrité.
Si une réponse est reçue avant l'expiration du délai, NLB compare le code d'état HTTP renvoyé aux codes spécifiés dans les paramètres de contrôle d'intégrité. Un code correspondant indique que le serveur est sain ; sinon, il est considéré comme non sain.
Cas d'utilisation
Contrôles d'intégrité TCP
Services FTP : Vérifiez que les serveurs FTP peuvent accepter et répondre aux demandes de connexion.
Services de messagerie : Vérifiez que les serveurs de messagerie peuvent envoyer et recevoir des messages.
Transactions financières : Détectez rapidement les pannes des serveurs de transaction pour éviter les interruptions.
Connexion à distance : Surveillez la disponibilité et les performances des services de connexion à distance.
Contrôles d'intégrité UDP
Industries traditionnelles
Services DNS : Vérifiez que les serveurs DNS répondent correctement aux requêtes.
Services VoIP : Surveillez la latence, la perte de paquets et la gigue pour les applications VoIP telles que Skype et les systèmes de téléphonie IP.
Jeux en ligne : Surveillez le temps de réponse et la disponibilité des serveurs de jeu.
Médias en continu : Évaluez la disponibilité et la qualité du flux pour les services de visioconférence et de vidéo en temps réel.
Messagerie instantanée : Surveillez la stabilité de la connexion et la latence pour la livraison de messages en temps réel.
Industries émergentes
QUIC : Vérifiez l'état de la connexion QUIC pour une transmission de données efficace et en temps réel.
IoT : Vérifiez l'état des dispositifs capteurs avec une faible latence, adapté aux appareils sensibles à la consommation d'énergie ou aux coûts.
V2X : Garantissez l'échange de données en temps réel et la fiabilité de la communication entre les véhicules et l'infrastructure.
VR et AR : Assurez une transmission rapide des données visuelles et d'interaction.
Cloud gaming : Surveillez la latence pour maintenir une expérience de jeu fluide.
Contrôles d'intégrité HTTP
Services Web : Envoyez des requêtes HTTP GET ou HEAD vers un chemin spécifié (tel que
/health) pour vérifier que le serveur peut traiter les requêtes HTTP.Contrôles d'intégrité d'applications personnalisés : Utilisez une logique personnalisée pour vérifier les pools de connexions de base de données, l'état du cache ou d'autres métriques spécifiques à l'application.
Microservices : Détectez les erreurs au niveau de l'application dans les instances de microservices. Les réponses aux contrôles d'intégrité fournissent des informations de diagnostic détaillées.
Passerelles API et proxies inverses : Surveillez l'intégrité des passerelles API ou des proxies inverses tels que NGINX et HAProxy via leurs interfaces HTTP.
Noms de domaine pour les contrôles d'intégrité HTTP
Vous pouvez éventuellement spécifier un nom de domaine pour les contrôles d'intégrité HTTP. Certains serveurs d'application vérifient l'en-tête Host avant d'accepter les requêtes. Si vous spécifiez un nom de domaine dans les paramètres de contrôle d'intégrité, NLB l'ajoute à l'en-tête Host. Sinon, NLB omet l'en-tête Host, ce qui peut entraîner des échecs de contrôle d'intégrité si le serveur backend l'exige.
Si votre serveur d'application vérifie l'en-tête Host, configurez un nom de domaine pour les contrôles d'intégrité.
Références
Pour plus d'informations sur la configuration des contrôles d'intégrité, consultez Groupes de serveurs NLB.
Pour plus d'informations sur le dépannage des problèmes de contrôle d'intégrité, consultez Dépanner les échecs de contrôle d'intégrité NLB.