cavallette

Da piu ‘parti ci e’ stato chiesto di delineare meglio i problemi che abbiamo
avuto in queste settimane. Qui di seguito c’e’ un tentativo. Per noi e’ molto
complicato riuscire a comunicare, mentre stiamo cercando di risolvere i
problemi. Quindi abbiate pazienza, se il report arriva in ritardo,
speriamo risulti esaustivo.

L’origine del male sta in ldap, ma in punto oscuro, difficile da indagare.
Ldap e’ un sistema comodo (??) per gestire elenchi, nello specifico noi teniamo in quel
database praticamente tutto: le vostre password stanno nel
database ldap, ma anche semplicemente l’elenco degli utenti sta li’ dentro. Quando si rompe
ldap a cascata si verificano problemi su ogni servizio dal web alla posta, in primis
perche’ il sistema non sa piu’ chi siete e cosa volete da lui. Per questo non riuscivate piu’
ad autenticarvi sulle caselle di posta.
L’infrastruttura di AI e’ formata da diverse macchine, disposte in luoghi diversi.
Perche’ tutto funzioni a modino e’ necesssario che ldap gestisca correttamente le
operazioni di replicazione del database, quando si modifica il contenuto (ad esempio
per aggiungere una casella di posta), i cambiamenti si diffondono su tutte le macchine
del pianeta AI, che quindi risultano allineate e possono funzionare come un sistema omogeneo.
In queste settimane ci si e’ rotta la replicazione.
Tutto e’ partito da un altro problema, piu’ banale, ma che ci affligge da sempre:
lo spazio disco. Su alcuni server caselle mai utilizzate, ma piene di spam, stavano
rapidamente saturando i dischi. Abbiamo deciso di abilitare
un sistema di quota per suddividere in maniera piu’ corretta lo spazio disco
tra i nostri utenti. Per ciascun utente sono stati aggiunti alcuni campi nel
database ldap. Da qui siamo sprofondati in un inferno di madonne sadomaso e cristi
un po’ glam che ci guardavano dall’alto e ridevano di noi.
Abbiamo provato a togliere le quote, ma qualcosa sembrava averci definitivamente
abbandonato. Si e’ pensato di passare tutti i nostri sistemi a debian lenny per poter
avere una nuova versione di ldap, ma neppure questo ha risolto allora abbiamo
compilato una nostra versione di openldap, ma non bastava ancora. Il carico
sulle macchine era troppo alto, troppa memoria e troppa cpu impegnati da ldap,
tutto risultava instabile.
Siamo passati allora ad una nuova modalita’ di replicazione, meno onerosa in
termine di banda e di cpu, la syncrepl-delta, questo ci ha dato respiro.
Quello che sembra aver pacificato pero’ l’animo inquieto di ldap e’ stata la
ripopolazione totale del db, a botte di ldapadd, un’operazione lentissima, ma
al termine della quale la replicazione ha ripreso a funzionare correttamente.
Il nostro problema in sintesi era che il master ldap tentava la replicazione, ma
lo slave in maniera perentoria restituiva un errore, non considerando validi
gli attributi che il master chiedeva di replicare. A questo punto il carico saliva a mille,
il master crashava, i database non era allineati, e tutto finiva ai maiali.
Ripopolando il database ldap da zero il sistema ha ripreso a funzionare, quote
comprese. La principale difficolta’ e’ stata che chiaramente nell’ambiente
di test tutto funzionava correttamente.
Rimaniamo ancora un po’ interdetti per non essere riusciti a compredere
la vera orgine del male. D’altra parte questo e’ un problema che filosofi e teologi
indagano dalla notte dei tempi.

This entry was posted on giovedì, Maggio 28th, 2009 at 2:48 pm and is filed under Avvisi, Comunicati, Problemi_Tecnici. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.