LVS in modalità Direct Routing: stato delle connessioni

Recentemente ho dovuto far fronte a tutta una serie di allarmi generati da Nagios (NMS), relativi ad un numero troppo elevato di connessioni (sia attive che inattive) gestite da LVS (load balancer).

load balancing

In particolare, gli allarmi riportavano delle informazioni del tipo:

***** Nagios *****

Notification Type: PROBLEM

Service: IPVS HTTP Status
Host: lbprod.domain.com
Address: 
State: CRITICAL

Date/Time: Sat Aug 22 14:37:38 CET 2015

Additional Info:

CRITCAL total active=9096:8400:9000:0: total inactive=26650:50000:55000:0: 192.168.3.1:80 active=1305:1200:1300:0: 192.168.3.1:80 inactive=3925:7000:8000:0: 192.168.3.11:80 active=1304:1200:1300:0: 192.168.3.11:80 inactive=3781:7000:8000:0: 192.168.3.12:80 active=1296:1200:1300:0: 192.168.3.12:80 inactive=3952:7000:8000:0: 192.168.3.13:80 active=1287:1200:1300:0: 192.168.3.13:80 inactive=3744:7000:8000:0: 192.168.3.36:80 active=1309:1200:1300:0: 192.168.3.36:80 inactive=3653:7000:8000:0: 192.168.3.37:80 active=1299:1200:1300:0: 192.168.3.37:80 inactive=3748:7000:8000:0: 192.168.3.38:80 active=1296:1200:1300:0: 192.168.3.38:80 inactive=3847:7000:8000:0:

A primo acchito, analizzando il suddetto output, ho individuato 2 anomalie, ovvero l’elevato numero di connessioni totali attive (9096, superiore alla soglia critica 9000) ed inattive (26650).

Collegandomi dapprima al bilanciatore e lanciando il comando:

[root@nightbox ~]# watch ipvsadm

ho appurato che l’allarme generato da Nagios fosse veritiero (poichè i valori restituiti erano totalmente in linea con quelli indicati dall’allarme).

Successivamente, mi sono connesso ai vari frontend ed ho lanciato il comando:

[root@lbprod ~]# netstat -anp | grep ":80" | grep ESTABLISHED | wc -l

in modo da conteggiare il numero di connessioni attive (ESTABLISHED) presenti su ciascuno di essi. Secondo il mio ragionamento, la somma delle suddette connessioni attive doveva restituirmi un numero prossimo a quello segnalato da Nagios ed ipvsadm, ma così non è stato. Lo stesso dicasi per le connessioni inattive (diverse da ESTABLISHED), identificate mediante il comando:

[root@lbprod ~]# netstat -anp | grep ":80" | grep -v ESTABLISHED | wc -l

A questo punto ho consulato questa pagina (la documentazione ufficiale di ipvsadm, ovvero il tool di gestione di LVS tramite CLI) e mi sono soffermato sulla sezione 4.11.5, il cui titolo è abbastanza esplicativo – ActiveConn is a guess for LVS-DR ed il cui contenuto è il seguente:

For LVS-DR, the director doesn’t see the return packets and uses tables of timeouts to guess a likely state of the service at the realserver. For the same reason you can’t do stateful filtering on the director for LVS-DR controlled packets.

In soldoni, ciò significa che LVS configurato in modalità Direct Routing (DR) vede solo ed esclusivamente le connessioni in ingresso (e dirette ai frontend) ma non vede il traffico di ritorno (poichè non passa dal bilanciatore ma si sviluppa interamente tra frontend e client). Proprio per questo motivo, ipvsadm identificherà come attiva una connessione fin quando non scadrà il timeout ad essa associato.

Per visualizzare i valori di timeout per le connessioni TCP, TCP-FIN ed UDP ho utilizzando il comando:

[root@lb1 ~]# ipvsadm -l --timeout

il cui output era il seguente:

Timeout (tcp tcpfin udp): 900 60 300

con i valori di timeout espressi in secondi (per modificarli basta lanciare il comando ipvsadm –set).

Svelato dunque l’arcano, ho dapprima modificato i valori di timeout per le connessioni TCP (portandoli di poco al di sopra di quelli definiti sui frontend) ed ho innalzato le soglie di WARNING e CRITICAL per il servizio di Nagios.

Alla prossima.

LVS in modalità Direct Routing: stato delle connessioniultima modifica: 2015-08-28T10:37:12+02:00da nazarenolatella
Reposta per primo quest’articolo