Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register


DOWN time...

Continuamo la "saga" di $noiguardiamolavostrarobba, di cui ho detto anche troppo fino ad ora.

Avevamo lasciato il branco di paguri (che oramai hanno superato in pagurosita' i veri paguri), con la gestione praticamente "in house" dell'intero parco di servers e servizi vari. Se vi ricordate questa storia, vi ricorderete anche di come erano "stretti" nei tempi. Adesso il sarchiaponi stanno cercando di vendere parte del loro "business" ad un'altra societa' (per la serie: incassiamo il grano intanto che si puo' e scappiamo di corsa). Il risultato e' che sono ancora piu' isterici per quanto riguarda l'uptime del sistema.

Ed ecco profilarsi all'orizzonte una cosa orrenda... terribile, terrificante! Gli Update! Si' perche' quando si fanno update del sistema per definizione bisogna fare un reboot, e data la natura intradipendente del loro sistema, fare il reboot di un sistema significa tirare giu' tutto l'ambaradan e pregare in cirillico che riparta tutto come si deve.

Dopo un panegirico terrificante UL riesce a mercanteggiare con DB di fare gli updates di lunedi' invece che di domenica come tutti gli altri, il che significa che dovremo fare due "round" di updates, uno "normale" alle 7 della domenica mattina ed uno "speciale" alle 7 del lunedi' mattina. Poi un secondo giro di patteggiamenti sposta il secondo round alle 9.

UL insiste che il downtime deve essere ridotto al minimo e propone il seguente Piano Strategico:

  1. Iniziare updates su sistemi Linux
  2. Iniziare updates su sistemi Windows
  3. Mettere pagina di manutenzione all'ultimo secondo
  4. Reboot sistemi Linux
  5. Reboot sistemi Windows
  6. Aggiornamento VMWare tools su Windows
  7. Aggiornamento VMWare tools su Linux
  8. Secondo reboot dei vari database servers (plurale)
  9. Quando i db sono up & running, reboot degli application servers in uno specifico ordine per evitare problemi di interdipendenze.
  10. Rimozione della pagina di manutenzione

Ovviamente tutto questo nell'ipotesi che non ci sia nessun problema e che l'intero arnese riesca a restare in piedi mentre le librerie e gli applicativi vengono aggiornati sotto il suo naso... non c'e' da dire che io non lo credo molto eh?

Arriva il fatidico lunedi' e cominciamo la solfa. Sempre per ridurre al minimo il downtime siamo in 3 che ci dividiamo il compito, con stretta coordinazione via Chat...

08.59 Io: Ok, allora pronti a cominciare? 09.03 Io: HALLO!!! C'e' nessuno di la'??? 09.04 DB: Ok, pronti. 09.07 CL: Pronti anche qui. 09.07 Io: Inizio update LNX01 09.08 Io: Inizio update LNX02 ... 09.28 Io: Gli update vanno a velocita' lumaca... 09.33 DB: Io non ho ancora cominciato. 09.34 Io: Ma non dovevamo cominciare in sincronia? 09.37 CL: Mi da errore su un package... 09.38 Io: CL, hai disabilitato il repository speciale? 09.44 CL: No. 09.57 Io: Hummm... il load average del db server e' salito a 19. Non sono molto sicuro che questo coso regga gli updates fatti mentre sta funzionando. 10.11 Io: Ed infatti mi sto beccando alert a tutto spiano... metto la pagina di manutenzione? 10.18 Io: Ripeto: metto la pagina di manutenzione? 10.35 DB: Ho Ul al telefono che dice che il sito non e' piu' funzionale 10.35 Io: e che ti ho detto? 10.36 Io: CL, come sta andando di la'? 10.47 CL: Che faccio per quell'errore? 10.48 Io: Disabilita il repository! 10.52 CL: Ok. 11.03 Io: Ok, pronto per il reboot. 11.19 DB: Io sono ancora in alto mare... 11.19 Io: Dato che il sito e' ancora fuori combattimento metto la pagina di manutenzione. 11.38 DB: Sta ancora aggiornando. ma e' normale? 11.39 Io: Il fatto che stia anche funzionando non aiuta di certo... 11.55 CL: Ok, io sono pronto. 12.18 DB: Possiamo iniziare con il reboot.

Segue panico e terrore per il reboot.

12.33 Io: Inizio aggiornamento vmware tools. 12.43 DB: Come' che si faceva a fare l'aggiornamento??

Sorvolo sulla spiegazione 'volante' in chat... Comunque sia, all'una e mezza finiamo di fare questo aggiornamento ed iniziamo il secondo reboot. Altro panico e terrore e poi le cose cominciano a riavviaris... o meglio si riavvierebbero se non che devono essere riavviate in un preciso ordine e se non si segue quell'ordine sono ca$$i piu' o meno acidi. Quindi prima di imbroccare la sequenza che consente un riavvio piu' o meno sano ci passa un'altra ora.

Risultato: alle 3 del pomeriggio, con UL che geme e grida al telefono, togliamo la pagina di manutenzione e diamo "via libera" al sistema. E scopriamo subito che le cose non funzionano come dovrebbero. Apparentemente qualche aggiornamento non e' stato propriamente "indolere" ed adesso alcune funzionalita' della loro webapplicascion non sono piu' funzionali. Altre grida e strepiti di UL. Io ho fatto gentilmente (non tanto) notare che se avessero mantenuto un sistema di TEST si sarebbe potuta fare la prova di aggiornamento prima, cosi' non ci si sarebbe ritrovati a tentare di debuggare conflitti di librerie su un sistema "live".

Ed a proposito di "tenere il downtime al minimo necessario". Dato che l'intero ambaradan era in funzione l'aggiornamento e' stato di una lentezza cataclismica, abbiamo totalizzato quasi 5 ore di downtime in un colpo solo... Come gia' detto, chi cerca di risparmiare il centesimo qualche volta si trova poi a spendere il centone.

L'unica nota positiva della giornata e' stato il commento di DaBoss: "non so per quanto resteranno nostri clienti"...detto con un certo tono.

Davide
12/11/2012 08:00

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

8 messaggi this document does not accept new posts

Anonymous coward

Di Anonymous coward postato il 12/11/2012 08:20

Metti i "ritorno a capo" nella parte della chat se no si capisce poco".

MA ancora la meni con la storia del sistema di TEST? non si puo', costa troppo, non e' mai allineato, serve per altro, dobbiamo tagliare i costi "superflui" etc etc.  

Quanto costa un sistema di test? uguale al sistema di produzione visto che deve essere identico. Quanti aggiornamenti si fanno all'anno? diciamo 4, uno al trimenstre. Quindi 20 ore di downtime all'anno costano molto meno che non il raddoppio dei costi per avere un sistema di test. Questo e' quello che pensano loro, ovviamente....

-- Anonymous coward

Messer Franz (again)

@ Anonymous coward Di Messer Franz (again) postato il 12/11/2012 10:31

<Metti i "ritorno a capo" nella parte della chat se no si capisce poco".

 

io trovo che sia un po' difficile da leggere ma dia l'idea del caos totale e a cazzate a raffica...in breve , per me va bene cosi'

-- Messer Franz (again)

Anonymous coward

@ Anonymous coward Di Anonymous coward postato il 13/11/2012 11:57

Quanti aggiornamenti si fanno all'anno? diciamo 4, uno al trimenstre.

Se hai macchine Windows ti tocca schedularne uno al mese (e oggi è Patch Tuesday!). A meno che tu non si in grado di tenere sotto controllo vulnerabilità ormai pubbliche anche gravi per altri due. È che ora devi progettare un sistema perché sia aggiornabile senza downtime, se questa è la richiesta.

-- Anonymous coward

Alberto

Di Alberto postato il 12/11/2012 08:30

> L'unica nota positiva della giornata e' stato il commento di DaBoss: "non so per quanto resteranno nostri clienti"...detto con un certo tono.

È una promessa o una minacciasmiley?

-- Alberto

trekfan1

@ Alberto Di trekfan1 postato il 12/11/2012 20:21

 

> L'unica nota positiva della giornata e' stato il commento di DaBoss: "non so per quanto resteranno nostri clienti"...detto con un certo tono.

È una promessa o una minacciasmiley?

 



Forse una speranza LOL

-- trekfan1

Messer Franz

Di Messer Franz postato il 12/11/2012 10:29

<Come gia' detto, chi cerca di risparmiare il centesimo qualche volta si trova poi a spendere il centone.

 

d'altra parte , se facessero tutto "click click fatto tutto"  la network gestapo come farebbe a pagare i conti di fine mese? Meglio tanti extra e tante fatturine .... tanto paga  il tuo stomaco....

-- Messer Franz

Guido

Di Guido postato il 12/11/2012 14:26

Mi ero quasi dimenticato che oggi era Lunedì ;\) ero a fare un cUloquio...

Il fatto è che certa gente non capisce che le cose non si pianificano sperando che vada tutto bene, ma pensando a cosa puo' andare male

(che fa la sua porca differenza) ;\)

-- He who controls the past commands the future. He who commands the future, conquers the past - Kane

Anonymous coward

Di Anonymous coward postato il 12/11/2012 20:49

Tutto ciò mi ricorda MOLTO di quando io, il mio capo ed un ingengere Siemens "facevamo" (cioè faceva lui, l'inge) l'upgrade del sw di base della nostra centrale telefonica Hicom-300: essendo per l'appunto una centrale telefonica non è che potevamo aggiornare alle 11 di mattina, e così ci davamo appuntamento per le 11 di sera, in sala macchine... poi l'inge iniziava uno strano rito in cui era coinvolto un gallo nero ed un backup su nastro... al che iniziava lo shutdown ordinato della centrale.

A centrale spenta (power down) tirava fuori le stecche delle EPROM ed iniziava ad estrarre schede (tutte 386 e qualche 486), smadonnando appena appena perchè le EPROM precedenti non uscivano... io ed il mio capo in Religioso Silenzio.

Al che, reinserite le schede, l'inge tracciava un pentacolo a terra col sangue conservato del suddetto gallo, accendeva il numero giusto di candele ai vertici... e ridava corrente... quasi subito iniziava a pregare, in un oscuro dialetto di R'lyeh... io ed il mio capo sempre in R.S.

Come spesso accade, non è che gli upgrade funzionino... non al primo colpo, comunque: in genere una delle due CPU si impallava con un Codice di Errore Astrale (o a'stronzo, a seconda del manuale in cui era inscritto) e l'inge impallidiva, il tono delle preghiere raggiungeva parossismi allucinanti, mentre tentava di acquisire la consolle dell'ACL e dar comandi in antico teutonico... io ed il mio capo iniziavamo a guardarci ed uscivamo in frasi tipo "...se possiamo fare qualcosa..." che non facevano altro che aumentare il volume delle bestemm^H^H^H^H^H^H^Hpreghiere e la sudorazione dell'inge.

Quindi, in genere, altro power-down (io ed il mio capo guardavamo, vogliosi, il grosso cavo di alimentazione trifase e l'accetta con residui di sangue di gallo nero), sostituzione di parte delle EPROM con "altre"... preghiera, bestemmia, ri-power-up, preghiera, preghiera, preghiera, preghiera, preghiera, preghiera... io ed il mio capo iniziavamo a sogghignare come due vampiri alla vista di una giovane vergine...

Alla fine, verso le 2 o le 3, quando perfino i lupi mannari erano andati a dormire, l'Infame Aggeggio si degnava di ripartire, lasciando sul campo un ingegnere mooooolto dimagrito (e facendo ritrarre le nostre zanne dalla vicinanza alla sua jugulare)... una bella stretta di mano, da Veri Professionisti, e via... nella notte fonda (con un vago suono di ali di cuoio).

-- Anonymous coward

8 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira