Comment configurer les contrôles de santé ELB avec plusieurs applications exécutées sur chaque instance EC2?


11

Chez AWS, nous aimerions utiliser des ELB pour équilibrer la charge des instances EC2 qui hébergent plusieurs applications. Idéalement, nous aimerions avoir un bilan de santé pour l'application.

Cependant, AWS Elastic Load Balancers ne vous autorise actuellement à envoyer une requête ping qu'à un seul emplacement pour un contrôle d'intégrité.

Quelle serait la meilleure façon de mettre en œuvre un contrôle d'intégrité avec ELB qui prend en compte l'état de plusieurs applications déployées sur chaque instance EC2?


4
Une façon serait d'implémenter votre propre bilan de santé en faisant un script renvoyer un état basé sur ses vérifications des deux applications.
Nathan C

1
ELB est un service géré. Créez un autre ELB pour la deuxième application avec son propre bilan de santé. La plupart du coût est par demande, il vous en coûtera donc presque le même pour faire fonctionner 2 ELB.
Guy

Je pense que la réponse de @ NathanC est la meilleure solution; J'ai un cas similaire où si l'une des deux conditions échoue, le bilan de santé devrait échouer. L'ajout d'un autre ELB vous permettra d'avoir un autre bilan de santé, mais AFAIK un seul ELB peut être utilisé pour acheminer le trafic (ou non)
Tom Harrison Jr

@Guy en fait, étant donné que les heures ELB sont facturées indépendamment des demandes, c'est ~ 20 USD par mois (selon la région), donc la plupart du coût est par demande uniquement si vous fournissez déjà plus de 2,5 To de données par mois ( à 0,008 $ / Go)
Josip Rodin

Réponses:


10

Voici deux façons de résoudre ce problème;

La première option consiste à ajouter un autre contrôle d'intégrité sur l'hôte qui valide l'intégrité et renvoie HTTP 200s à l'ELB si la logique indique que vous souhaitez conserver l'hôte en ligne. La logique vous appartient, bien sûr. L'inconvénient ici serait que si l'application 2 était déployée avec succès sur certains hôtes, tous les hôtes seraient toujours «sains» et recevraient du trafic.

Une autre option consiste à utiliser un ELB supplémentaire pour chaque application. Vous pouvez pointer plusieurs ELB vers les mêmes instances EC2 dorsales et le coût est assez mineur pour le faire. De cette façon, vous pouvez vérifier l'état de santé par application et supprimer les hôtes présentant des problèmes au niveau de chaque application plutôt qu'une approche tout ou rien.

Edit: Veuillez noter qu'il s'agit d'une réponse plus ancienne et spécifique à ELB et non à ALB. ALB prend en charge nativement des cibles distinctes sur un hôte.


7

L'utilisation d'un ELB par application est la voie à suivre ici.

Tout d'abord, vous pouvez en avoir besoin de toute façon si chaque application se trouve sur son propre domaine et que vous devez prendre en charge SSL. Actuellement, les ELB Amazon n'autorisent qu'un seul certificat SSL pour chaque domaine, ce qui nécessite des ELB distincts pour chaque domaine compatible SSL. (Les certifications SSL Wildcard étant une exception).

Le défi ici est que les contrôles de santé ELB ne peuvent pas actuellement être dirigés vers un domaine virtuel particulier hébergé sur une instance EC2. (Aucun en-tête "Host:" n'est envoyé). Les pings de santé ELB vont toujours au domaine par défaut, comme si vous aviez chargé l'adresse IP de l'instance EC2 dans votre navigateur. Un peu de colle est donc nécessaire pour recevoir les contrôles de santé sur le domaine par défaut, puis répondre avec l'état de santé d'une application particulière.

Voici un exemple de configuration de travail qui pourrait être ajouté à une serverdirective Nginx . Il serait installé sur chacune des instances EC2 à équilibrage de charge.

    # This goes in the `server` block noted by 'default_server', often /etc/nginx/sites-enabled/default

    # All AWS Health Checks from the ELBs arrive at the default server.
    # Forward these requests on the appropriate configuration on this host.
    location /health-check/ {
      rewrite ^/health-check/(?<domain>[a-zA-Z0-9\.]+) /api/v1/status break;
      # Lie about incoming protocol, to avoid the backend issuing a 301 redirect from insecure->secure,
      #  which would not be considered successful.
      proxy_set_header X-Forwarded-Proto 'https';
      proxy_set_header "Host" $domain;
      proxy_pass http://127.0.0.1;
    }

Dans le paramètre "Health Check" de l'ELB pour "first-application.com", vous devez sélectionner "HTTP" et le port 80 et entrer un chemin comme:

/health-check/first-application.com

Avec la configuration Nginx ci-dessus exécutée sur l'hôte, la demande serait reçue sur le domaine par défaut et proxy la réponse de la configuration Nginx sur le même hôte pour https://first-application.com/api/v1/status

Avec cette approche, il n'y a pas de configuration par application dans Nginx. Tant que chaque application possède un nom de domaine unique, il vous suffit de vous assurer de configurer correctement un ELB pour chaque application.


3
Merci. Cela semblait faire l'affaire cependant. J'espérais éviter d'avoir à avoir plusieurs équilibres de charge avec cela.
tourdownunder

6

Le 11 août 2016, Amazon a introduit les équilibreurs de charge d'application . Ceux-ci vous permettent de spécifier plusieurs groupes cibles, chacun avec son propre type de vérification de l'état. C'est donc désormais possible avec un seul équilibreur de charge!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.