Documentation Oracle Cloud Infrastructure

Dépannage des problèmes de serveur back-end d'équilibreur de charge

En savoir plus sur les problèmes de serveur back-end associés aux équilibreurs de charge.

Débogage d'une expiration de serveur back-end

Si le serveur back-end dépasse le temps imparti pour répondre à une demande, une erreur 504 est générée. Elle indique que le serveur back-end est arrêté ou ne répond pas à la demande transmise par l'équilibreur de charge. L'application client reçoit le code de réponse suivant : HTTP/1.1 504 Gateway Timeout.

Les erreurs peuvent se produire pour les raisons suivantes :

  • L'équilibreur de charge n'a pas pu établir de connexion avec le serveur back-end avant que le délai de connexion n'expire.
  • L'équilibreur de charge a établi une connexion avec le serveur back-end, mais le back-end n'a pas répondu avant le délai d'inactivité n'expire.
  • Les listes de sécurité ou les groupes d'interface réseau virtuelle du sous-réseau n'ont pas autorisé le trafic des back-ends vers l'équilibreur de charge.
  • Le serveur back-end ou le serveur d'applications a échoué.

Pour résoudre les erreurs d'expiration du serveur back-end, procédez comme suit :

  1. Exécutez l'utilitaire curl pour tester directement le serveur back-end à partir d'un hôte du même réseau.
    curl -i http://backend_ip_address
    Si le test met plus d'une seconde à répondre, un problème au niveau de l'application provoque une latence. Nous vous recommandons de vérifier les dépendances en amont pouvant entraîner une latence, notamment :
    • Stockage attaché à un réseau, tel qu'iSCSI ou NFS
    • Latence de base de données
    • API hors site
    • Niveau d'application
  2. Vérifiez l'application en y accédant directement à partir du serveur back-end. Consultez ses journaux d'accès pour déterminer si l'application est accessible et fonctionne correctement.
  3. Si l'équilibreur de charge et le serveur back-end se trouvent dans des sous-réseaux différents, vérifiez que les listes de sécurité contiennent des règles autorisant le trafic. S'il n'existe aucune règle, le trafic n'est donc pas autorisé.
  4. Entrez les commandes suivantes pour déterminer si des règles de pare-feu existent sur les serveurs back-end qui bloquent le trafic :

    iptables -L répertorie toutes les règles de pare-feu appliquées par iptables.

    sudo firewall-cmd --list-all répertorie toutes les règles de pare-feu appliquées par firewalld.

  5. Activez la journalisation sur l'équilibreur de charge pour déterminer si l'équilibreur de charge ou le serveur back-end est à l'origine de la latence.

Test des serveurs back-end TCP et HTTP

Cette rubrique explique comment dépanner une connexion d'équilibreur de charge. La topologie utilisée dans cette procédure comporte un équilibreur de charge public dans un sous-réseau public. Les serveurs back-end se trouvent dans le même sous-réseau.

Nous vous recommandons d'utiliser le service Oracle Cloud Infrastructure Logging pour résoudre les problèmes. (Reportez-vous à Détails des journaux d'équilibreur de charge.)

En plus de l'utilisation de la journalisation Oracle Cloud Infrastructure, vous pouvez toutefois utiliser d'autres utilitaires répertoriés dans cette section pour résoudre le problème du trafic traité par l'équilibreur de charge et envoyé à un serveur back-end. Pour effectuer ces tests, nous vous recommandons de créer une instance dans le même réseau que l'équilibreur de charge et d'autoriser le trafic dans des groupes de sécurité réseau et des listes de sécurité identiques. Utilisez les outils suivants pour résoudre les problèmes :

  • commande d'achat
    Avant d'employer les utilitaires plus avancés répertoriés ici, nous vous recommandons d'effectuer un test ping de base. Pour que ce test réussisse, vous devez autoriser les trafics ICMP entre l'instance de test et le serveur back-end.
    $ ping backend_ip_address
    La réponse doit ressembler à ce qui suit :
    PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data.
64 bytes from 192.0.2.2: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 192.0.2.2: icmp_seq=2 ttl=64 time=0.044 ms

    Si vous recevez un message du type "64 bytes from...", la commande ping a réussi.

    Si le système reçoit un message du type "Hôte de destination inaccessible", le système n'existe plus.

    L'absence de message indique que le système existe, mais qu'il n'est pas autorisé. Vérifiez l'ensemble des pare-feu, des listes de sécurité et des groupes de sécurité réseau pour vous assurer que le protocole ICMP est autorisé.

  • courbure

    Exécutez l'utilitaire curl pour envoyer des demandes HTTP à un hôte, à un port ou à une URL spécifique.

    • Dans l'exemple suivant, où curl est utilisée pour la connexion à un serveur back-end qui envoie une erreur 403 Forbidden, cette erreur est renvoyée :

      $ curl -I http://backend_ip_address/health
HTTP/1.1 403 Forbidden
Date: Tue, 17 Mar 2021 17:47:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 3539
Connection: keep-alive
Last-Modified: Tue, 10 Mar 2021 20:33:28 GMT
ETag: "dd3-5b3c6975e7600"
Accept-Ranges: bytes

      Dans l'exemple précédent, la vérification de l'intégrité échoue, renvoyant une erreur 403, ce qui indique que les droits d'accès au fichier local du serveur back-end n'ont pas été configurés correctement pour la page Vérification de l'intégrité.

    • Dans l'exemple suivant, où curl est utilisée pour la connexion à un serveur back-end qui envoie une erreur 404 Not Found, cette erreur est renvoyée :
      $ curl -I http://backend_ip_address/health
HTTP/1.1 404 Not Found
Date: Tue, 17 Mar 2021 17:47:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 3539
Connection: keep-alive
Last-Modified: Tue, 10 Mar 2021 20:33:28 GMT
ETag: "dd3-5b3c6975e7600"
Accept-Ranges: bytes

      Dans l'exemple précédent, la vérification de l'état échoue en renvoyant une erreur 404, ce qui indique que la page Vérification de l'état n'existe pas à l'emplacement attendu.

    • Dans l'exemple suivant, un serveur back-end existe et un groupe de sécurité réseau, des listes de sécurités ou un pare-feu local bloquent le trafic :
      $ curl -I backend_ip_address
curl: (7) Failed connect to backend_ip_address:port; Connection refused
    • L'exemple suivant montre un serveur back-end qui n'existe pas :
      $ curl -I backend_ip_address
curl: (7) Failed connect to backend_ip_address:port; No route to host
  • Netcat

    Netcat est un utilitaire de fonctions de réseau qui permet de lire à partir de connexions réseau et d'écrire sur ces connexions réseau via TCP ou UDP.

    • Dans l'exemple suivant, l'utilitaire netcat est exécuté au niveau TCP pour vérifier que le serveur back-end de destination peut recevoir une connexion :
      $ nc -vz backend_ip_address port
Ncat: Connected to backend_ip_address:port.

      Dans l'exemple précédent, le port est ouvert pour les connexions.

    • $ nc -vn backend_ip_address port
Ncat: Connection timed out.

      Dans l'exemple précédent, le port est fermé.

  • Modèle de données

    Utilisez l'utilitaire tcpdump pour capturer l'ensemble du trafic vers un serveur back-end afin d'assurer quel trafic provient d'un équilibreur de charge et ce qui est renvoyé à cet équilibreur.

    sudo tcpdump -i any -A port port src load_balancer_ip_address
11:25:54.799014 IP 192.0.2.224.39224 > 192.0.2.224.80: Flags [P.], seq 1458768667:1458770008, ack 2440130792, win 704, options [nop,nop,TS val 461552632 ecr 208900561], length 1341: HTTP: POST /health HTTP/1.1
  • OpenSSL

    Lors de la résolution des problèmes SSL entre l'instance d'équilibreur de charge et les serveurs back-end, nous vous recommandons d'utiliser l'utilitaire openssl. Cet utilitaire ouvre une connexion SSL vers un port et un nom d'hôte spécifiques, et imprime le certificat SSL et d'autres paramètres.

    Voici d'autres options de résolution des problèmes :

    • -showcerts

      Cette option imprime tous les certificats de la chaîne de certificat présentée par le serveur back-end. Utilisez cette option pour identifier les problèmes, tels qu'un certificat d'autorité de certification intermédiaire manquant.

    • -cipher cipher_name

      Cette option force le client et les serveurs à utiliser un mécanisme de cryptage spécifique, et permet d'exclure l'autorisation de cryptages spécifiques par le back-end.

  • Netstat

    Utilisez la commande netstat -natp pour vous assurer que l'application en cours d'exécution sur le serveur back-end est en fonctionnement. Pour les trafic TCP ou HTTP, l'application back-end, l'adresse IP et les ports doivent tous être en mode d'écoute. Si le port d'application sur le serveur backend n'est pas en mode d'écoute, le port TCP de l'application n'est pas en fonctionnement.

    Pour résoudre ce problème, assurez-vous que l'application est en fonctionnement en redémarrant l'application ou le serveur back-end.