web-dev-qa-db-fra.com

Les contrôles de santé du groupe cible NLB sont hors de contrôle

J'ai un équilibreur de charge réseau et un groupe cible associé qui est configuré pour effectuer des contrôles d'intégrité sur les instances EC2. Le problème est que je vois un nombre très élevé de demandes de bilan de santé; plusieurs chaque seconde.

intervalle par défaut entre les vérifications est censé être de 30 secondes, mais elles arrivent environ 100 fois plus souvent qu'elles ne le devraient.

Ma pile est construite dans CloudFormation, et j'ai essayé de remplacer HealthCheckIntervalSeconds, ce qui n'a aucun effet. Fait intéressant, lorsque j'ai essayé de modifier manuellement l'intervalle dans la console, j'ai trouvé ces valeurs grisées:

Edit Healthcheck Settings

Voici la partie pertinente du modèle, avec ma tentative de changer l'intervalle commenté:

NLB:
  Type: "AWS::ElasticLoadBalancingV2::LoadBalancer"
  Properties:
    Type: network
    Name: api-load-balancer
    Scheme: internal
    Subnets: 
      - Fn::ImportValue: PrivateSubnetA
      - Fn::ImportValue: PrivateSubnetB
      - Fn::ImportValue: PrivateSubnetC

NLBListener:
  Type : AWS::ElasticLoadBalancingV2::Listener
  Properties:
    DefaultActions:
      - Type: forward
        TargetGroupArn: !Ref NLBTargetGroup
    LoadBalancerArn: !Ref NLB
    Port: 80
    Protocol: TCP

NLBTargetGroup:
  Type: AWS::ElasticLoadBalancingV2::TargetGroup
  Properties:
    # HealthCheckIntervalSeconds: 30
    HealthCheckPath: /healthcheck
    HealthCheckProtocol: HTTP
    # HealthyThresholdCount: 2
    # UnhealthyThresholdCount: 5
    # Matcher:
    #   HttpCode: 200-399
    Name: api-nlb-http-target-group
    Port: 80
    Protocol: TCP 
    VpcId: !ImportValue PublicVPC

Mes instances EC2 sont dans des sous-réseaux privés sans accès du monde extérieur. Le NLB est interne, il n'y a donc aucun moyen d'y accéder sans passer par l'API Gateway. API Gateway n'a pas de /healthcheck endpoint configuré, ce qui exclut toute activité provenant de l'extérieur du réseau AWS, comme les personnes qui exécutent une commande ping manuelle sur le endpoint.

Voici un exemple du journal de mon application extrait de CloudWatch, alors que l'application doit être inactive:

07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:33 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:34 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:34 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:34 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:35 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:35 {"label":"Received request URL","value":"/healthcheck","type":"trace"}
07:45:35 {"label":"Received request URL","value":"/healthcheck","type":"trace"}

Je reçois généralement 3 à 6 demandes par seconde, donc je me demande si c'est juste la façon dont les équilibreurs de charge réseau fonctionnent, et AWS n'a toujours pas documenté cela (ou je ne l'ai pas trouvé), ou sinon comment Je pourrais résoudre ce problème.

amazon-web-servicesamazon-ec2amazon-cloudformationamazon-elb
14
Miles

Mise à jour: cela a été répondu sur le post du forum aws qui confirme que c'est un comportement normal pour les équilibreurs de charge réseau et cite leur nature distribuée comme raison. Il n'y a aucun moyen de configurer un intervalle personnalisé. En ce moment, les documents sont toujours obsolètes et spécifient le contraire.

Il s'agit soit d'un bogue dans les groupes cibles NLB, soit d'un comportement normal avec une documentation incorrecte . Je suis arrivé à cette conclusion parce que:

  • J'ai vérifié que les contrôles de santé proviennent de la NLB
  • Les options de configuration sont grisées sur la console
    • déduisant que AWS connaît ou a imposé cette limitation
  • Les mêmes résultats sont observés par d'autres
  • La documentation est spécifiquement destinée aux équilibreurs de charge réseau
  • Les documents AWS vous mènent généralement dans une chasse aux oies sauvages

Dans ce cas, je pense que cela pourrait être un comportement normal qui a été mal documenté, mais il n'y a aucun moyen de vérifier cela à moins que quelqu'un d'AWS ne le puisse, et il est presque impossible d'obtenir une réponse à un problème comme celui-ci sur le forum aws.

Il serait utile de pouvoir configurer le paramètre, ou au moins de mettre à jour les documents.

21
Miles

Employé AWS ici. Pour élaborer un peu sur la réponse acceptée, la raison pour laquelle vous pouvez voir des rafales de demandes de contrôle de santé est que NLB utilise plusieurs vérificateurs de santé distribués pour évaluer la santé cible. Chacun de ces vérificateurs d'intégrité fera une demande la cible à l'intervalle que vous spécifiez, mais tous vont lui faire une demande à cet intervalle, vous verrez donc une demande de chacune des sondes distribuées. La santé cible est ensuite évaluée en fonction du nombre de sondes qui ont réussi.

Vous pouvez lire une explication très détaillée écrite ici par un autre employé d'AWS, sous "Un regard sur les contrôles de santé Route 53": https://medium.com/@adhorn/patterns-for-resilient-architecture-part- 3-16e8601c488e

Ma recommandation pour les contrôles de santé est de coder les contrôles de santé pour qu'ils soient très légers. Beaucoup de gens font l'erreur de surcharger leur bilan de santé pour faire des choses comme vérifier la base de données principale ou exécuter d'autres vérifications. Idéalement, un bilan de santé pour votre équilibreur de charge ne fait rien d'autre que renvoyer une chaîne courte comme "OK". Dans ce cas, votre code devrait prendre moins d'une milliseconde pour répondre à la demande de contrôle de santé. Si vous suivez ce modèle, des rafales occasionnelles de 6 à 8 demandes de vérification de santé ne devraient pas surcharger votre processus.

4
nathanpeck

Un peu tard pour la fête là-dessus. Mais ce qui fonctionne pour moi, c'est que mon service (C++) tourne un fil dédié aux contrôles de santé provenant d'ELB. Le thread attend une connexion socket puis attend de lire à partir du socket; ou rencontrez une erreur. Il ferme ensuite le socket et revient à l'attente du prochain ping de vérification de l'état. C'est BEAUCOUP moins cher que d'avoir ELB touché mon port de trafic tout le temps. Non seulement cela fait croire à mon code qu'il est attaqué, mais il accélère également toute la logistique et autres nécessaires pour servir un vrai client.

1
Shaun Botha