Introduction #
Un service proxy est un logiciel conçu pour gérer de manière transparente les connexions des clients à un ou plusieurs services, en fournissant une gestion avancée des données ou des connexions au niveau de l'application (couche 7 dans le modèle OSI). Pour y parvenir, le service proxy établit une connexion avec le client et une autre avec le serveur, dans le but d'assurer une connectivité transparente entre eux.
Lors de la mise en œuvre de l'équilibrage de charge via un service proxy (fonctionnant efficacement comme un proxy inverse), il est essentiel de personnaliser les délais d'attente pour faciliter des connexions fluides. Les valeurs de délai d'expiration par défaut peuvent ne pas suffire, selon les caractéristiques des clients ou des services d'application. Toutes les erreurs liées au délai d'attente seront enregistrées dans les journaux système à l'adresse / var / log / syslog, il est donc crucial d'examiner ce fichier pour déceler des problèmes potentiels.
Cet article fournit des informations sur l'analyse et l'identification des problèmes de délai d'attente courants avec les serveurs proxy. L'information clé à rechercher est de savoir si les délais d'attente se produisent du côté backend ou du côté client. Une fois cette distinction faite, des ajustements de délai d'attente appropriés peuvent être appliqués.
Délais d’attente côté backend #
Si des délais d'attente se produisent côté backend, les messages correspondants s'affichent comme suit :
21 août 09:23:06 noid-ee-01 livre : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff830b85700) erreur de copie du serveur suite : connexion expirée le 21 août 09 :23:06 noid-ee-01 livre : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.11:443, (7ff832d8b700) erreur de copie du serveur suite : connexion expirée le 21 août 09:23 : 16 noid-ee-01 livre : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff799926700) erreur de copie du serveur suite : connexion expirée le 21 août 09:23:18 noid- livre ee-01 : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff830bc6700) erreur de copie du serveur suite : tuyau cassé 21 août 09:23:19 noid-ee-01 livre : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:444, (7f15f5a8c700) connect_nb : le délai d'interrogation a expiré le 21 août 09:23:24 noid-ee-01 livre : noid-proxy-farm -01, service noid-service-01, backend 10.100.200.11:443, (7ff79a9a7700) erreur de copie du serveur suite : connexion expirée le 21 août 09:23:24 noid-ee-01 livre : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff79a28b700) erreur de copie du serveur suite : connexion expirée
Ces erreurs de délai d'expiration du backend spécifient le ferme, service et backend associé à l'erreur. Ces informations identifient clairement le ou les backends liés au problème. Si plusieurs batteries de serveurs, services ou backends sont impliqués dans le problème de délai d'attente, des informations supplémentaires peuvent devoir être collectées pour enquêter sur tout problème de réseau potentiel.
L'activation des journaux de batterie de serveurs peut révéler des cas dans lesquels un backend spécifique répond initialement rapidement, mais rencontre soudainement un problème de délai d'attente, comme illustré dans l'extrait de journal ci-dessous :
25 janvier 19:57:04 noid-ee-01 livre : noid-proxy-farm-01, my.service.com 185.106.182.130 - - [25/jan/2024:19:57:04 +0000] "GET / myserv/ HTTP/1.1" 200 9 "" "Mozilla/3.0 (compatible; ...)" (noid-service-01 -> 10.100.200.10:443) 0.039 secondes 25 janvier 19:57:04 noid-ee-01 livre : noid-proxy-farm-01, my.service.com 88.111.111.111 - - [25/jan/2024:19:57:04 +0000] "GET / myserv/ HTTP/1.1" 200 9 "" "Mozilla/3.0 (compatible; ...)" (noid-service-01 -> 10.100.200.10:443) 0.035 secondes 25 janvier 19:57:04 livre noid-ee-01 : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) connect_nb : le délai d'interrogation a expiré 25 janvier 19:57:04 noid-ee-01 livre : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) backend 10.100.200.10:443 connexion : connexion expirée 25 janvier 19:57:04 noid-ee-01 livre : noid-proxy-farm-01, (7fcd8eb0f700) BackEnd 10.100.200.10:443 morts (tués) dans la ferme : 'noid-proxy-farm-01', service : 'ocp-ocuco-com' 25 janvier 19:57:04 noid-ee-01 livre : noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) BackEnd mort (tué )
Ce comportement peut indiquer que le backend a atteint sa limite de connexion, empêchant des connexions supplémentaires. Alternativement, cela pourrait suggérer que le backend ne libère pas les connexions assez rapidement, ce qui entraînerait un goulot d'étranglement. Pour résoudre ce problème, il est recommandé de surveiller le backend et de mettre en œuvre des optimisations telles qu'autoriser davantage de connexions ou faire évoluer le service en ajoutant des backends supplémentaires.
Si seuls des backends spécifiques rencontrent des problèmes de délai d'attente au sein du même service, cela implique que ces backends particuliers peuvent avoir des problèmes liés à une livraison lente des applications ou à des problèmes de réseau. Les solutions ou atténuations de ces erreurs sont décrites ci-dessous.
Délais d'attente côté client #
À l'inverse, les délais d'attente des clients se manifestent dans le syslog au format suivant :
18 août 07:31:38 noid-ee-01 livre : noid-proxy-farm-01, (7f8862187700) erreur lue à partir du 12.91.1.78 : connexion expirée 18 août 07:31:43 noid-ee-01 livre : noid -proxy-farm-01, (7f8863c71700) erreur lue à partir du 12.2.1.105 : connexion expirée le 18 août 07:32:03 noid-ee-01 livre : noid-proxy-farm-01, (7f886275e700) erreur lue à partir de 12.41.1.58. 18 : connexion expirée le 07 août 32:07:01 noid-ee-01 livre : noid-proxy-farm-7, (8880f84700d12.88.1.67) erreur lue à partir de 18 : connexion expirée le 07 août 32:16:01 noid-ee -01 livre : noid-proxy-farm-7, (8880933700f12.3.1.158) erreur lue à partir du XNUMX : la connexion a expiré
Si les journaux manquent d'informations sur la batterie ou le service, cela indique que la demande du client n'a pas atteint correctement le proxy. Le client met plus de temps à exécuter la requête HTTP, ce qui fait que le proxy ignore l'existence du service demandeur. Le tableau d'adresses IP peut aider à déterminer si le problème concerne un réseau interne, des clients externes ou ceux arrivant via un pare-feu spécifique.
De plus, pour les clients externes, il est crucial de s'assurer de leur légitimité. L’utilisation des services AbuseIP peut aider à collecter de telles informations.
De plus, pour résoudre les problèmes de délai d'attente des clients, il est crucial de vérifier que le proxy ne met pas fin prématurément aux connexions. Assurez-vous que la somme du délai d'expiration de la connexion et des délais d'attente du backend est inférieure au délai d'expiration du client pour éviter toute déconnexion prématurée par le proxy.
Reportez-vous ci-dessous pour obtenir des informations sur la résolution ou l’atténuation de ces erreurs.
Correction des délais d'attente côté backend #
Vérification de la couche réseau #
Pour commencer, il est essentiel de confirmer la stabilité de la couche réseau et de s’assurer de l’absence de paquets dupliqués, de paquets perdus ou de fluctuations importantes de latence. Suivez ces étapes pour effectuer la vérification de la couche réseau :
1. Exécutez un ping de l'équilibreur de charge vers le backend et laissez-le s'exécuter pendant plusieurs minutes.
root@noid-ee-01 : ~# ping 10.100.200.10
2. Observez les réponses ping pendant l'exécution :
PING 10.100.200.10 (10.100.200.10) 56(84) octets de données. 64 octets à partir de 10.100.200.10 : icmp_seq=1 ttl=64 temps=0.395 ms 64 octets à partir de 10.100.200.10 : icmp_seq=2 ttl=64 temps=0.626 ms 64 octets à partir de 10.100.200.10 : icmp_seq=3 ttl =64 temps=0.178 ms [...] 64 octets à partir de 10.100.200.10 : icmp_seq=21 ttl=64 temps=0.502 ms 64 octets à partir de 10.100.200.10 : icmp_seq=22 ttl=64 temps=0.638 ms 64 octets à partir de 10.100.200.10 : =23 ttl=64 temps=0.573 ms ^C --- 10.100.200.10 statistiques ping --- 23 paquets transmis, 23 reçus, 0 % de perte de paquets, temps 140 ms rtt min/avg/max/mdev = 0.178/0.539/0.854/0.141 ms
Cette réponse indique que le réseau est stable, sans perte de paquets ni problème de latence. Assurez-vous de l’absence de toute anomalie lors du test ping pour confirmer la fiabilité de la couche réseau.
De plus, en exécutant un tcpdump lorsque le problème est répliqué, vous pouvez analyser le trafic réseau pour identifier le moment précis où la communication connaît des retards ou lorsque certains paquets sont manquants. Utilisez la commande suivante :
root@noid-ee-01:~# tcpdump -i tout port TCP PORT et hôte BACKENDIP -w /tmp/capture.pcap
Cette commande générera un fichier nommé /tmp/capture.pcap, qui peut être analysé à l’aide de Wireshark. Soyez prudent, car ce fichier peut croître rapidement s'il capture une quantité importante de trafic.
Réglage des délais d'attente du proxy #
Ajustement de divers délais d'attente dans le Configuration avancée de la ferme nous permet d'adapter le comportement du proxy aux besoins de nos serveurs d'applications, notamment lorsqu'ils nécessitent du temps supplémentaire pour chaque requête ou lorsque les performances du réseau sont lentes. Tenez compte des recommandations suivantes :
Expiration du délai de connexion back-end: Définissez la durée maximale d'un relier () opération sur le backend sélectionné. Si les messages aiment « connect_nb : le délai d'interrogation a expiré » sont détectés, envisagez d'augmenter cette valeur de 20 secondes par défaut à 30 ou 40 secondes. Augmentez progressivement la valeur en fonction des résultats observés, en gardant à l'esprit que le délai d'attente peut résoudre un problème sous-jacent ailleurs.
Délai d'expiration de la réponse du backend: Ajustez cette valeur si le message "Erreur de copie du serveur (suite : connexion expirée)" est identifié. De même, augmentez progressivement cette valeur jusqu'à ce qu'une diminution de ces messages soit observée. Attention toutefois à ne pas augmenter excessivement cette valeur, car cela pourrait masquer des problèmes sous-jacents côté backend. La valeur par défaut est de 45 secondes, pensez donc à l'augmenter à 60 secondes ou plus, en surveillant l'absence d'erreurs.
Fréquence de vérification des backends ressuscités: Dans les cas où des délais d'attente plus longs sont nécessaires en raison de problèmes de réseau ou de serveur d'applications provoquant des erreurs HTTP 503 intermittentes (indiquant qu'aucun service backend n'est disponible), envisagez de réduire cette valeur de 10 secondes à 5. Cet ajustement permet d'atténuer les faux positifs en marquant les backends comme des pannes causées. par des délais d'attente. Analysez si les délais d'attente se situent dans les limites normales, car l'équilibreur de charge proxy peut atténuer certains problèmes dans ce contexte.
Veuillez effectuer une analyse approfondie pour déterminer la normalité des délais d'attente. L'équilibreur de charge proxy a la capacité de résoudre et d'atténuer certains problèmes liés au délai d'attente.
Pour des informations plus détaillées, reportez-vous à l'article suivant :
Configurer les contrôles de santé #
Farm Guardian a pour objectif d'activer ou de désactiver les backends en fonction de leur disponibilité. Dans ce scénario, tirer parti de Farm Guardian nous permet de vérifier la disponibilité réelle des backends. Ce processus fonctionne indépendamment et parallèlement au proxy, fournissant un moyen de vérifier si les problèmes back-end contribuent réellement à un goulot d'étranglement du côté back-end. De plus, en examinant les statistiques du backend lorsqu'un backend est marqué comme étant indisponible, nous pouvons déterminer le nombre de connexions gérées par ce serveur, ce qui nous permet d'identifier les limites de connexion de chaque backend.
La configuration d'une vérification FarmGuardian pour TCP nous permet d'identifier tout problème de négociation avec les backends, ce qui pourrait indiquer un goulot d'étranglement au niveau du système ou de la couche du serveur Web. D'un autre côté, la configuration d'une vérification FarmGuardian pour HTTP permet d'identifier les problèmes au niveau de la couche application avec les backends, pointant ainsi vers des goulots d'étranglement potentiels dans la couche application ou base de données.
Correction des délais d'attente côté client #
Vérification de la couche réseau #
Pour valider la stabilité du réseau, exécutez un test ping depuis un autre serveur ou une autre machine vers l'adresse IP de l'IP virtuelle configurée pour la batterie d'équilibrage de charge. Cela garantit une perspective externe et permet de confirmer la fiabilité du réseau.
Vérification des clients légitimes #
Utilisez des outils sécurisés pour identifier si les problèmes de délai d'attente sont associés à des clients légitimes, des robots ou des attaquants potentiels. Si les délais d'attente sont liés à des utilisateurs non autorisés, mettez en œuvre des listes noires IPDS et/ou des protections DoS pour protéger vos services et garantir une livraison uniquement aux utilisateurs valides et authentiques.
Réglage des délais d'attente du proxy #
En outre, envisagez d'ajuster les délais d'expiration du proxy pour s'adapter à la nature des clients qui se connectent à vos services via l'équilibreur de charge. Si, par exemple, des clients mobiles, des problèmes de pare-feu ou des réseaux lents contribuent à allonger les temps de réponse, affinez le Délai d'expiration de la demande client option dans la Paramètres avancés de votre Ferme LSLB. La valeur par défaut est 30 secondes; vous pouvez l'augmenter à 60 secondes ou plus en fonction de vos besoins spécifiques. La valeur du délai d'expiration du client doit dépasser la somme du délai d'expiration de la connexion et du délai d'expiration de la réponse du backend.
Pour des informations plus détaillées, veuillez vous référer à l’article suivant :
