haproxy: mantiene le sessioni esistenti sotto carico elevato, serve '503' ai nuovi arrivi


12

Cercare di fare ciò che dice nel titolo: mantenere le sessioni esistenti sotto carico elevato e inviare messaggi 503 ai visitatori appena arrivati.

Problema: funziona, ma le sessioni non durano oltre 90 secondi circa.

I risultati attuali mi chiedono se manchi un'impostazione di timeout.

Scopo

Sto cercando di ottenere haproxy per:

  • invia richieste per nuove sessioni a backend-001 quando il numero totale di sessioni sul frontend è inferiore a una determinata soglia.
  • servire un errore 503 per le nuove sessioni quando il numero totale di sessioni sul frontend è superiore a tale soglia
  • consentire richieste per sessioni esistenti anche se il numero di sessioni supera la soglia

In questo modo, i visitatori che stanno compilando un modulo in più passaggi non saranno sorpresi da un errore 503 e ai nuovi visitatori potrà essere detto di "tornare più tardi perché siamo davvero impegnati in questo momento".

Impostare

L'impostazione è la seguente:

            {visitors}
                ↓ 
            [haproxy]
                ↓ 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

approccio attuale

Per ottenere quanto sopra, sto usando la configurazione di seguito.

Questo è per i test, con un limite molto basso (10 connessioni sul front-end (fe_conn gt 10)), per facilitare i test.

Per mettere il server sotto carico, sto usando httperf come segue:

httperf --hog --server staging.machine.tld --uri / do_some_things --wsess = 500,10,30 --rate 2

global
    daemon
    maxconn 10000

defaults
    mode        http
    timeout connect 6s
    timeout client  60s
    timeout server  60s
    balance roundrobin
    option http-server-close

frontend http-in
    bind [PUBLIC_IP]:80

    default_backend backend-001

    acl too_many fe_conn gt 10
    use_backend b_too_many if too_many

backend backend-001
    fullconn 10
    appsession _session_id len 128 timeout 7200s

    cookie SERVERID insert maxidle 7200s
    server Server1 127.0.10.1:80 cookie backend-001 check

backend b_too_many
    errorfile 503 /var/www/50x.html

problema

Come accennato in precedenza, il problema è: quasi funziona, ma le sessioni non durano oltre 90 secondi circa.

Se continui a fare clic su, puoi mantenere la sessione anche quando ci sono 10 sessioni occupate.

Il tentativo di aprire una pagina sul server con un'istanza del browser diversa genera l'errore 503.

Quindi, sembra che ci sia quasi. Qualcuno ha idea di cosa potrebbe causare i brevi tempi di sessione?

E in particolare come posso ripararlo :)

(modifica: rimosso 'peso 1 maxconn 10' dalla linea 'server', non pertinente e potrebbe confondere) (modifica la seconda: corretta '10 sessioni sul front-end' a '10 connessioni sul front-end ')


Potrebbe essere una domanda sciocca: qual è l'impostazione keep_alive in nginx? Apparentemente sono i 75 anni di default - potrebbe essere questo il problema?
Aidan Kane,

Risposte:


4

Sfortunatamente, sembra che tu stia confondendo completamente le connessioni con le sessioni a livello di applicazione. Un utente che visita il sito potrebbe avere un cookie che ti fa pensare di possedere una connessione mentre non è necessariamente il caso. Potrebbe aprire tutte le connessioni necessarie per recuperare oggetti e navigare tra le pagine.

I 90 secondi che stai osservando sicuramente sono il timeout di mantenimento del browser per le connessioni inattive.

È possibile ottenere ciò che desideri, ma è un po 'più complesso di quello, poiché devi anche considerare la presenza del cookie di persistenza nella richiesta per capire se il visitatore è nuovo o meno.

Inoltre, in generale è più efficiente fare affidamento sul conteggio medio delle connessioni per server piuttosto che sul conteggio delle connessioni frontend. Il motivo è che quando un server muore, è necessario regolare nuovamente questo numero. Il modo più efficiente per farlo è impostare un valore maxconn del server per abilitare l'accodamento e utilizzare avg_queue in modo che il limite si applichi al numero medio di richieste in coda sui server. Ciò consente di gestire correttamente i visitatori noti spostando delicatamente i nuovi utenti su un altro back-end quando il carico aumenta a causa dei visitatori esistenti.


1
Grazie grazie! Ciò si è chiarito molto. Ora ho funzionato controllando (tra le altre cose) il backend-cookie con hdr_sub (Quindi, "hdr_sub (cookie) SERVERID = backend-001"). Pubblicherò una configurazione funzionante al termine.
Apenootje,
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.