F5 Load Balancer invia nuovamente la richiesta al timeout

Consentitemi di prefigurarlo dicendo che non sono un amministratore di sistema, sono un programmatore.

Di recente, i nostri amministratori di sistema hanno installato i bilanciatori di carico F5. Da allora, ho notato che ogni volta che una richiesta scade e finisce per lanciare un 500, il bilanciamento del carico invia la stessa richiesta all'altro nostro server. IIS invia la risposta di timeout anche se lo script è ancora in esecuzione. Anche le richieste POST vengono duplicate se uno script viene eseguito per più di 5 minuti. Questo mi sembra un potenziale problema, specialmente con i siti di e-commerce in cui è coinvolta la fatturazione dei clienti.

Questo è solo un problema con alcuni dei nostri script più lunghi (ma è un problema serio). Mi è stato detto che si tratta di un comportamento previsto e dovremo modificare il nostro codice per renderlo conforme. Quindi le mie domande sono:

Questo comportamento è previsto?
Qual è il vantaggio del bilanciamento del carico che replica la richiesta dopo un timeout diverso dall'utente che non deve aggiornare?
Con questa architettura, se viene eseguito uno script che impantona il server o le risorse di maiale, finirà per essere eseguito su entrambi i server. È davvero ottimale?

iis load-balancing f5-big-ip

— Jim D
fonte

Quando dici "invia la stessa richiesta" all'altro server, ti riferisci ai controlli di integrità configurati o alle richieste dell'utente? Il mio senso è no, ma vale la pena chiarire. La risposta a questa modifica cambierà la risposta e / o eventuali suggerimenti.

— mcauth,

@mcauth invia nuovamente la richiesta dell'utente. Fondamentalmente se un utente esegue un'azione che richiede un errore 500, il bilanciamento del carico invia la stessa richiesta esatta all'altro server, creando così due risposte da una singola richiesta HTTP.

— Jim D,

Sono in orbita di Big-IP da un bel po 'di tempo, e non ho mai saputo di rigiocare una richiesta se non specificatamente detto di farlo, diciamo, tramite un iRule che fa un HTTP :: collect per buffer payload richiesta . Molto strano. Senza vedere la configurazione di corsa è molto difficile da dire.

— mcauth,

Basta saltare un po 'questa discussione per farti sapere che sto colpendo esattamente lo stesso problema. Hai avuto ulteriori informazioni sulla risoluzione?

— BitMask777,

@ BitMask777 - Purtroppo non ci siamo mai spinti oltre. Questo è ancora il comportamento del bilanciamento del carico e ci siamo "occupati di esso".

— Jim D,

Risposte:

Dai un'occhiata a questa voce sul monitoraggio passivo delle applicazioni in Big-IP

Le mie risposte alle tue domande, per quanto deludenti, lo sono

Forse (dipende dalla configurazione del monitoraggio passivo)
L'utente non vede un errore
Forse (voglio servire gli errori dei miei utenti o provare la richiesta da qualche altra parte?)

"Action on Service Down" è un'impostazione configurabile.

— quadruplebucky
fonte

Grazie per la tua risposta. Hai ragione nel dire che è un po 'deludente, speravo in qualcosa di più concreto. Immagino sia concreto nello spiegare che non esiste una risposta definitiva.

— Jim D,

Se si verifica un errore 500, ciò indica un problema sul server Web. L'F5 semplicemente inoltrerà questo errore al client di connessione. Non "rispedirà" la richiesta di propria iniziativa. L'unico modo in cui ciò potrebbe accadere è se il client riprova la richiesta. A quel punto, questa richiesta potrebbe eventualmente essere bilanciata in base al carico di un altro membro del pool, sebbene non vi siano garanzie e si baserebbe sulla persistenza o sul metodo di bilanciamento del carico utilizzato (round robin, connessioni minime, ecc.).

In breve, a meno che tu non abbia dei iRule davvero pazzi sulla tua F5, questo è un comportamento causato dallo script stesso.

(Nota: sono stato un ingegnere di supporto Nework per F5 per un anno e mezzo con LTM)

— James Shewey
fonte