Come impostare i controlli di integrità ELB con più applicazioni in esecuzione su ciascuna istanza EC2?


11

In AWS vorremmo utilizzare ELB per bilanciare il carico delle istanze EC2 che ospitano più applicazioni. Idealmente vorremmo avere un controllo sanitario per l'applicazione.

Tuttavia, i bilanciatori di carico elastici AWS attualmente consentono solo di eseguire il ping di una posizione per un controllo dello stato.

Quale sarebbe il modo migliore di implementare controlli sanitari con ELB che tenga conto dello stato di più applicazioni distribuite su ciascuna istanza EC2?


4
Un modo sarebbe implementare il proprio controllo di integrità facendo in modo che uno script restituisca uno stato basato sui controlli di entrambe le applicazioni.
Nathan C,

1
ELB è un servizio gestito. Creare un altro ELB per la seconda applicazione con il proprio controllo di integrità. Gran parte del costo è per richiesta, quindi ti costerà quasi lo stesso per far funzionare 2 ELB.
Guy

Penso che la risposta di @ NathanC sia la soluzione migliore; Ho un caso simile in cui se una delle due condizioni fallisce, il controllo sanitario dovrebbe fallire. L'aggiunta di un altro ELB ti consentirà di avere un altro controllo sanitario, ma AFAIK può essere utilizzato solo un ELB per instradare il traffico (o meno)
Tom Harrison Jr

@Acquista in realtà, dato che le ore ELB sono addebitate indipendentemente dalle richieste, che è ~ 20 USD al mese (a seconda della regione), quindi la maggior parte del costo è per richiesta solo se si forniscono già oltre 2,5 TB di dati al mese ( a $ 0,008 / GB)
Josip Rodin,

Risposte:


10

Ecco due modi per risolverlo;

La prima opzione è quella di aggiungere un altro controllo di integrità sull'host che convalida l'integrità e restituisce HTTP 200 all'ELB se la logica dice che si desidera mantenere l'host online. La logica che c'è, ovviamente, dipende da te. Lo svantaggio qui sarebbe che se l'app 2 fosse distribuita correttamente su alcuni host, tutti gli host sarebbero comunque "sani" e ricevono traffico.

Un'altra opzione è quella di utilizzare un ELB aggiuntivo per ogni applicazione. È possibile puntare più ELB alle stesse istanze EC2 di back-end e il costo è abbastanza piccolo per farlo. In questo modo è possibile verificare lo stato di integrità per applicazione e rilasciare host con problemi a livello di applicazione piuttosto che un approccio tutto o niente.

Modifica: si prega di notare che questa è una risposta precedente ed è specifica per ELB e non ALB. ALB supporta nativamente destinazioni separate su un host.


7

L'utilizzo di un ELB per app è il modo per andare qui.

Innanzitutto, potresti averne bisogno comunque se ogni applicazione si trova nel proprio dominio e devi supportare SSL. Gli ELB di Amazon attualmente consentono solo un certificato SSL per ciascun dominio, che richiede ELB separati per ciascun dominio abilitato per SSL. (Le certificazioni SSL Wildcard sono un'eccezione).

La sfida qui è che i controlli di integrità ELB non possono attualmente essere indirizzati a un particolare dominio virtuale ospitato su un'istanza EC2. (Non viene inviata l'intestazione "Host:"). I ping di integrità ELB passano sempre al dominio predefinito, come se l'utente avesse caricato l'indirizzo IP per l'istanza EC2 nel browser. Quindi è necessaria della colla per ricevere i controlli di integrità sul dominio predefinito e quindi rispondere con lo stato di integrità di una particolare applicazione.

Ecco una configurazione di esempio funzionante che potrebbe essere aggiunta a una serverdirettiva Nginx . Sarebbe installato su ciascuna delle istanze EC2 con bilanciamento del carico.

    # 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;
    }

Nell'impostazione "Verifica dello stato" dell'ELB per "first-application.com", selezionare "HTTP" e Porta 80 e immettere un percorso come:

/health-check/first-application.com

Con la configurazione Nginx sopra in esecuzione sull'host, la richiesta sarebbe ricevuta sul dominio predefinito e proxy la risposta dalla configurazione Nginx sullo stesso host per https://first-application.com/api/v1/status

Con questo approccio non esiste una configurazione per-app in Nginx. Finché ogni app ha un nome di dominio univoco, devi solo assicurarti di impostare un ELB per ogni app in modo appropriato.


3
grazie. Questo sembrava fare il trucco però. Speravo di evitare la necessità di avere più bilanci di carico con questo.
tourdownunder

6

L'11 agosto 2016, Amazon ha introdotto i bilanciatori del carico delle applicazioni . Ciò consente di specificare più gruppi target, ognuno con il proprio tipo di controllo dello stato. Quindi questo è ora possibile utilizzando un unico bilanciamento del carico!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.