Ricerca in FOLBlog

[SdSM] Failsafe

 Scritto da alle 06:27 del 06/05/2012  Aggiungi commenti
Mag 062012
 
closeQuesto articolo è stato pubblicato 5 anni 7 mesi 11 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.

safe

Tanto tempo fa, c’erano i computers, che erano quelle cose complicatissime e costosissime che richiedevano una frotta di tecnici in camice bianco sempre a svolazzare intorno ed aggiustare o ritoccare cose per farli funzionare. Poi il mito della "infallibilita’" si e’ sparso ed oggi abbiamo i peesee che sono quei cosi che funzionano quando ne han voglia loro ed i cui proprietari continuano ad aggiustare e ritoccare nel tentativo di farli funzionare. Ed abbiamo i server che sono come i peesee, ma (di solito) se ne occupano i sysadmin, che sono quegli esseri leggendari che si narra vivano in un qualche antro sperduto nei sotterranei del palazzo e nessuno ha mai visto in persona.

Che si fa per evitare che un… qualcosa si rompa con facilita’? Semplice: lo si rende fail proof. Che e’ come dire "inaffondabile" nei riguardi di una nave. Un modo molto fantasioso per dire "quando qualche cosa va male preparati ad una catastrofe".

Un sysadmin intelligente sa che il miglior sistema e’ quello di avere dei backup, anche nei riguardi dell’hardware. Questo e’ quello che si chiama "evitare i Single Point Of Failure", che in termini meno tecnici significa "evitare che quando UN COSO si guasta provochi una catastrofe". I vari SL ed UL hanno opinioni contrastanti in genere. Fa’ tanto figo da dire nelle riunioni, ma quando cominciano a vedere i costi lievitare per "dispositivi di backup" e "ridondanza del sistema" cominciano a strillare di "sforamenti di budget" et similia.

Poi ci sono i casi estremi… come quello che mi e’ capitato questa settimana con $noivendiamolibri, che e’ una ditta specializzata nel vendere, comperare, riciclare e rivendere libri di testo scolastici ed altre cose cosi’.

Tempo addietro avevano un sistema composto da due server di produzione collegati ad un database server dietro ad un load-balancer. Il load-balancer ed il db server erano gli unici elementi che potessero dare dei problemi.

Poi, per qualche strano motivo, digestione difficile probabilmente, l’SL di turno si e’ fatto intortare dal marketdroide di turno ed un nuovo fiammante sistema e’ stato implementato. Il nuovo sistema si basa su numero UN server di produzione (dovrebbero essere due ma il secondo risulta non operazionale), un server LDAP (Il cui scopo e’ tutt’ora ignoto), un server di indicizzazione e due server di ricerca (di cui uno dei due e’ sempre non operazionale e no, non e’ nemmeno ‘standby’), un server di database con ennemila istanze per gestire il tutto e ben 3 load balancer. Uno attaccato al server di produzione, uno per il server di ricerca ed uno per il server LDAP. Ora, che senso abbia un load balancer con UN solo backend e’ tutto da discutere, ma questo e’ quanto.

Il risultato e’, come feci notare quando l’intero ambardan venne presentato, che il numero di ‘single point of failure’ e’ aumentato a sette (!) in quanto ogni singolo server sembra essere ‘essenziale’ per il funzionamento dell’intero sistema e se qualche cosa va male, l’intero accrocchio cessa di funzionare. Non solo ma, come scopriamo rapidamente, il malfunzionamento di uno dei componenti provoca errori a catena che sono molto difficili da tracciare al "vero" colpevole.

E cosi’ arriviamo ad oggi. Sabato mattina. Ore 3.45. Si’, significa un quarto alle quattro del mattino. Quando il malefico guinzaglio-cellofono comincia a suonare per avvisarmi che l’intero ambaradan e’ fuori servizio. Il che significa che UNO QUALUNQUE di quella montagna di servers potrebbe avere dei problemi.

Ok, silenzia il coso, verifica via browser e trovo la paginetta di "fuori servizio", il che significa che il load balancer che dovrebbe essere davanti ai vari server di produzione funziona, vediamo un po’ come funziona il server di produzione. Ed un login dopo scopro che il server sta funzionando ma scrive errori su errori lamentandosi che non riesce a connettersi con il famoso server di ricerca, il quale sembra a sua volta funzionare ma non riesce ad aggiornare i dati dal server di indicizzazione, il quale a sua volta sembra funzionare ma non riesce a leggere salca$$ocosa dal server di database, il quale a sua volta… Il tutto condito da bestemmie ed imprecazioni perche’ niente mi ispira di piu’ che l’essere svegliato alle 4 del sabato mattina da un cellofono isterico. Nyaaaaahhhhhh!

Dopo una manica di stop, start, stop, stop, muorifottutobastardo, start, check, re-check e cosi’ via, traccio il problema in un crash silenzioso del server ldap. Il che significa che il servizio LDAP pare funzionare ma non ritorna nessun risultato. Ovviamente non basta riavviare il servizio, occorre manualmente lanciare una riparazione del database, fermare e riavviare il servizio, aspettare che sia avviato e poi riavviare tutti i foxxuti servizi su tutti i foxxuti servers!. Con l’eccezione dei load balancer e del server di database che sono solo dei passacarte.

E meno male che il branco di dementi che hanno proposto questo setup lo hanno promosso come "fail-safe".

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: