[Linuxtrent] Problema in squid o altro ? Fantasmi ?
- From: Ezio Paglia <ezio@xxxxxxxxxxxxxxx>
- To: LinuxTrent <linuxtrent@xxxxxxxxxxxxx>
- Date: Mon, 12 Jan 2015 10:26:59 +0100
Ciao a tutti.
Vorrei chiedere il vostro consiglio su un problema che riguarda al
momento un nostro server su cui è installato lo squid3 e un apache2 con
wpad.dat e che serve a proxare la navigazione comunale verso il mondo.
Nel passato una DomU Xen (debian squeeze) racchiudeva oltre a questo
squid anche altri servizi minori; sulla stessa macchina fisica ( Debian
lenny) erano installate anche altre macchine virtuali, con scarsa
richiesta di risorse di rete. La macchina fisica disponeva di un'unica
interfaccia di rete. A una firewall era, tra le altre cose, ed è
demandato il compito di bloccare opportunamente le richieste verso il
mondo e di lasciar passare quanto transitava via proxy.
L'inconveniente descritto era che con frequenza oscillante tra 3 giorni
e 2 settimane, la macchina fisica contenente tutte le virtuali entrava
in boot. In nessuno dei log della fisica o delle virtuali si riusciva a
capire il motivo dell'evento. La ripartenza delle virtuali avveniva
senza errori.
Più recentemente abbiamo deciso di affrontare il problema che in buona
parte immaginavamo legato a presunti problemi del firmware della
macchina fisica. Senza sapere ancora che il problema potesse riguardare
il proxy, considerato che il server che lo conteneva era, tra quelli
virtuali, quello più accessato e sfruttato, abbiamo pensato che isolare
i servizi più accessati su una macchina fisica dedicata, potesse almeno
evitare il fastidio della ripartenza su altre virtuali. Su questa
macchina fisica abbiamo anche utilizzato la seconda scheda di rete,
pensando che potesse essere utile raddoppiare la banda se, come pareva,
la macchina faceva da collo di bottiglia. Debian wheezy, scarsa RAM (1
GB), squid3 + apache2 + dhcpd + altri servizi minori.
Dopo questo passaggio l'inconveniente è diventato più frequente (ogni
1-2 giorni) e ha riguardato specificamente questa macchina senza
riguardare più il vecchio server Xen né mandandolo in boot. In orari per
lo più notturni e di assenza di persone dal servizio la macchina
congelava il kernel, la mattina presto gli operatori venivano chiamati
dagli uffici che non navigavano, vedevano solo sulla console messaggi di
sospensione dei servizi per più di 120 secondi etc, la console era
inaccessibile, il server non rispondeva a ssh, potevano solo effettuare
il reboot. Anche in questo caso i log non denotavano niente di
particolare prima dell'inconveniente. Fra l'altro il proxy sostiene una
banda enorme senza problemi di giorno, a quell'ora di notte (si va dalle
10 di sera alle 3 di notte) non c'è nessuno che naviga ad eccezione di
qualche PC acceso, siamo anche lontani dall'orario di rotazione dei log
che potrebbe avere un minimo di pesantezza. Cioè il processore, la RAM e
la rete sono sottoutilizzati quando il blocco avviene.
Ultimo e attuale tentativo, stessa configurazione, ma isolamento dei
servizi squid3 e apache2 con solo la url di wpad. Cioè dhcp e altro,
prima su quel server, messi su altro server e, questa volta, parecchia
RAM (4 GB), immaginando che 1 GB potesse far entrare squid in sofferenza.
Stesso esito. In fase 2 (serverino piccola RAM wheezy) avevo anche
attivato statistiche snmp, disco, ram per vedere se c'era qualche
condizione esagerata, ma mi sembrava che prima dell'evento niente di
particolare accadesse, anzi, quasi calma piatta.
In tutte le configurazioni sono state usate diverse porte di switch.
Quindi lo stesso pacchetto squid3, ma in diverse release e su diversi
sistemi (da lenny a wheezy), ha creato problemi (è legato al
congelamento in wheezy fisica, procura il reboot in lenny Xen). Ma
questo sembra inverosimile, perché è verosimilmente anche tra i
pacchetti più noti, usati del mondo, su due release poi ...
Una concomitanza che ho verificato, l'unica mattina in cui sono stato io
ad aprire e di notte si era verificato l'inconveniente, è che la
macchina, inaccessibile a console e a ssh, rispondeva a ping. Tuttavia
non ho dato peso a questo fatto sebbene ora mi ponga il dubbio se a
rispondere non sia stata un'altra macchina e non avessi dovuto fare
arping anziché ping prima di dare il boot. Adesso ad arping risponde
solo una macchina, quella giusta e purtroppo non so come istruire i miei
colleghi a fare la stessa cosa con client windows. Inoltre la rete in
cui si trova il proxy è esattamente quella mia e dei miei colleghi, cioè
è difficile che ci sia un IP duplicato e dispettoso che vale solo di notte.
Altra concomitanza è che ad un potenziamento di RAM, rete, CPU è
corrisposta una maggiore frequenza di blocco.
E' anche vero che la frequenza di blocco sembra essere legata
all'inserimento massivo di molti dispositivi in rete (telefonia fissa).
Non ho attivato al momento su quella macchina log da o a remoto.
Domande :
* Un IP duplicato può congelare il kernel ?
* Quando ad un sistema si congela il kernel, risponde a ping ?
* C'è modo di configurare le cose affinché riesca dai log a vedere i
primi i messaggi di errore evitando il congelamento di kernel ?
* Avete consigli e suggerimenti da darmi ?
Grazie in anticipo.
Ezio
Other related posts: