Ricerca in FOLBlog

Apr 072013
 
closeQuesto articolo è stato pubblicato 4 anni 2 mesi 24 giorni giorni fa quindi alcuni contenuti o informazioni presenti in esso potrebbero non essere più validi. Questo sito non è responsabile per eventuali errori causati da questo problema.

Siamo a parlare di architettura. No, non il tipo di architettura che specifica come costruire un palazzo in modo che vinca premi su premi anche se sembra vomitato dagli alieni e nessuno vuole viverci anche solo vicino, si tratta di architettura di sistema ovviamente.

Taaaaaaanto tempo fa quando ero giovane, imbecille e con tanti capelli (adesso sono solo imbecille), la regola aurea insegnata e ripetuta era: sedetevi con una penna ed un foglio di carta e fate funzionare il cervello: cercate di immaginarvi cosa puo’ andare male e scegliete una architettura che a) risolva i vostri problemi e b) eviti di schiantarsi miserandamente quando una o piu’ di quelle cose brutte e cattive succedono. Questo tipo di modus operandi ha portato a cose come il protocollo TCP/IP, SCSI et similia. Poi e’ successo qualche cosa, credo che la “vecchia” generazione di ingegnieri, quelli che si ingegniavano, sia andata in pensione ed una nuova generazione, ammaliata dalla tecnologia, l’abbia sostituita. Questi ultimi hanno probabilmente pensato: “fuckoff pensare e’ difficile ed e’ noioso, le penne e la carta sono superate, la nostra tecnologia e’ invincibile, se ci sono problemi basta buttarci piu’ risorse per risolverli”. Il risultato di questo metodo di pensiero sono cose come il sistema ferroviario/autostradale (sempre prossimi al collasso e perennemente in fase di ristrutturazione).

Ovviamente io non mi occupo dell’architettura in grande stile, al massimo posso addocchiare l’architettura della nostra di rete e di solito l’effetto che mi fa e’ di farmi produrre un suono tipo “Mehoooowwwwwww….” con facepalm incorporato. Per esempio, per qualche strano motivo tutte le macchine sono dotate di un IP pubblico (anche quelle che non hanno nessun motivo di averlo perche’ non dovrebbero MAI essere disponibili su interdet, tipo database server). Per qualche altro strano motivo tuttavia, tutte le macchine hanno come unico gateway UN firewall. Uno solo. Ok, e’ ridondato (nel senso che c’e’ una seconda macchina che sarebbe li’ pronta a sostituirla nel caso di un patatrac) me e’ un solo firewall, non c’e’ load balancer. Il che significa anche che, avendo certi servizi unici, lo scambio da ‘attivo’ a ‘passivo’ e’ solo manuale (no, non cominciate a commentare, e’ cosi’ e basta. Non l’ho fatto io il sistema). Ovviamente, grazie al principio del “basta buttare risorse al problema”, nessuno ha mai pensato di fare una mini-analisi di quanto e’ il carico massimo che e’ possibile attaccare a questo famoso e solitario firewall prima che se ne vada in coma profondo, l’ipotesi era (probabilmente) che “quando ci arriveremo butteremo li’ un firewall piu’ grosso”. Bhe’, quel giorno e’ oggi.

Sono le 2 del mattino di domenica, quando il famosissimo e famigerato pager si mette a suonare segnalandomi che 280 servers sono improvvisamente in coma. Io balzo fuori dal letto accendo il lapdog e cerco di capire che accidenti sta succedendo. Un rapido controllo mi dice che il firewall non accetta piu’ connessioni. Subdorando problemi di capacita’ mi collego al secondario, balzo sullo switch e faccio un rapido controllo. Yep! Il foxxuto backup e’ in pieno svolgimento e questo semplicemente sta sovraccaricando la capacita’ del firewall.

Un altro rapido controllo mi dice anche che se lo lascio cosi’ ci sono ben poche possibilita’ che il backup vada a termine prima delle 8 del mattino. Quindi rapida decisione: ammazzo il backup. Dopo un giro di kill che neanche un’assassino professionista se lo sogna il firewall ripiglia un pelo di energia e le cose cominciano a rimettersi in sesto. I problemi adesso sono che 1) diversi servers avranno cominciato a notificare i vari SL/UL che sono stati ‘down’ per un certo periodo di tempo (quale migliore sistema di notificare il proprio proprietario che si e’ morti se non mandare una mail? No, non rispondete), 2) alcuni di questi cosi hanno dischi in condivisione su altri sistemi e con molta probabilita quei dischi sono adesso off-line 3) la settimana prossima succedera’ esattamente la stessa identica cosa. Il che ci lascia due scelte: “buttare altre risorse” al problema o cambiare drasticamente la struttura dell’intero sistema.

Dopo aver risolto il punto 2) sopra (dato che non posso fare un tubo riguardo 1) e 3) ) ed aver scritto il rapportino di “incidente” e marcato le mie ore extra me ne torno a letto. Al lunedi’ ovviamente siamo tutto a consulto con il grande capo. Il guaio e’ che non pare voler capire che il problema non e’ a “one time freaky thing” ma e’ strutturale.

DB – Quindi il problema e’ risolto.
IO – Ma risolto un ca$$o! Il problema e’ che il firewall ha raggiunto la sua capacita’ di carico massima e basta un minimo di sollecitazione per portarlo al collasso. Come avevo detto quando mi venne presentata la situazione piu’ di un anno fa. E’ solo questione di tempo.
DB – Ma adesso funziona tutto no?
IO – E continuera’ a funzionare se non succede niente fino a domenica, quando si inchiodera’ di nuovo tutto nel momento in cui il backup inizia a girare.
DB – (guardando P) Non possiamo far girare il backup in un’orario diverso?
P – Hummm… si credo sia possibile magari anticipandolo di mezz’ora…
IO – Cosi’ anticipi o posticipi solo il momento in cui il firewall entra in crisi. Il punto e’ che abbiamo troppi sistemi attaccati dietro a quel firewall che non dovrebbe nemmeno essere li’ per prima cosa.
P – Ma ci serve un firewall!
IO – E su questo siamo anche d’accordo. Ma il 90% delle macchine dietro a quel firewall sono Linux ed hanno gia’ un indirizzo IP pubblico: mettiamo un firewall sulla singola macchina ed evitiamo di far passare tutte le connessioni da un unico collo di bottiglia. In questo modo riduciamo il carico del firewall del 90% in un botto solo. Lasciamo le macchine Windows sul firewall (dato che non mi fido di quel coso di windows manco un po’). E magari si potrebbe pensare a come implementare un Out-of-band network per il backup e la manutenzione.
(P e DB si guardano stralunati come a dire “ma che sta a di’ questo?”) P – No guarda, tu non hai idea di come e’ strutturata la rete…
IO – Il che e’ possibilissimo dato che qui si attua una decisa separazione delle competenze, ma da quello che posso vedere spostare l’ora di esecuzione del backup non risolvera’ il problema. Il problema non e’ il backup o la capacita’ del firewall, il problema e’ che la rete e’ strutturata con troppi colli di bottiglia e troppi single-point-of-failure. C’e’ un firewall dietro al quale c’e’ uno switch dietro al quale ci sono ‘n’ servers. Il che significa che abbiamo due colli di bottiglia e due single-point-of-failure. I server virtuali girano su un host, altro collo di bottiglia e single-point-of-failure, ed i loro dischi sono volumi logici su un SAN che e’ collegato tramite un altro switch. Se uno di questi elementi ha un problema, come e’ gia’ capitato con quel disco sifulo sul SAN, l’intero sistema ne risente.
P – Ma il sistema e’ stato progettato in modo da richiedere il minimo di manutenzione!
IO – E allora spiegami come mai sto accumulando ore extra di recupero per allarmi ad orari assurdi. O forse per te “minimo di manutenzione” significa che puoi impostare una cosa in 2 minuti e poi perdere 40 ore alla settimana, tutte le settimane, per tenerla in piedi? Io preferisco metterci 40 ore per impostare qualche cosa e poi dimenticarmela perche’ sta in piedi da sola.
DB – Vabbe’, questi sono punti di vista (me pensa: e gia’…) in ogni caso non possiamo di certo metterci adesso a rifare tutto l’architettura (me pensa: senno dovresti ammettere che quello precedente era una chiavica?), quindi dobbiamo trovare una soluzione al problema. Io direi di sostituire il firewall. Mettiamone uno piu’ potente e prestante con una maggiore capacita’ e finita li’ (me pensa: che t’avevo detto io?).
IO – Guarda che se aumenti semplicemente la capacita’ finisci per ritrovarti con lo stesso identico problema ma aumentato del fatto che hai molte piu’ macchine/collo di bottiglia che vengono affette quando il sistema crolla.
DB – E piantiamola li’.

E cosi’ comincia l’odissea di ‘sostituire il firewall’ che regge l’intera baracca.

Ovviamente la mia idea di installare il nuovo firewall come secondario di quello esitente e poi fare un fallback in modo che il nuovo diventi primario e poter (eventualmente) ritornare a quello vecchio se qualche cosa non funziona e’ stata cassata immediatamente da P che preferisce “soluzioni pratiche”, aka: sostituire di botto entrambi i firewall in un colpo solo.

Il che si e’ tramutato in una all-night alla colo per sincronizzare il duo. Il giorno dopo P ha scoperto sulla sua pelle che la nuova versione di SSH installata su questo firewall manda in coma il firmware dello switch primario dietro al firewall stesso. Che gioia.

Davide

legenda personaggi

Articoli simili:

  • Facebook
  • Twitter
  • Delicious
  • StumbleUpon
  • Wikio
  • Reddit
  • Technorati
  • Segnalo
  • Live
  • Add to favorites
  • Email
  • RSS

 Lascia un commento

Puoi usare questi tag e attributi HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(richiesto)

(richiesto)

Pinterest
EmailEmail
PrintPrint
%d blogger hanno fatto clic su Mi Piace per questo: