Ricerca in FOLBlog

SdSM

Le avventure e le peripezie di un SysAdmin

[SdSM] Volli, fortissimamente strilli…

 Scritto da alle 06:27 del 04/02/2014  Nessuna risposta »
feb 042014
 

Maporkalamignottatroika… Possibile che ogni due per tre qualcuno si convince che quello che bisogna fare e’ agitare la bacchetta magica ed urlare forte ‘vogliovogliovoglio’ come un bimbo di 3 anni (o anche meno) per fare le cose? Proabilmente e’ per quello che il mondo va come sta andando. Ok, fatemi ripigliare il filo…

Tempo addietro $noipensiamoallavostrarobba aveva messo in piedi un sistemone da incubo, con enne applicationservers, doppio load-balancer, doppio database e cose varie, poi l’UL della situazione aveva visto la pubblicita’ di un qualche servizio di “analisi” delle visite e gli erano venute delle strane fregole.

In sostanza il servizio di “analisi” (che millantava e millanta tutt’ora prestazioni straordinarie) consiste nel far passare tutto il traffico per il sito attraverso un proxy, cosi’ loro possono fare l’analisi dei contenuti e simili seghe mentali. Lasciamo perdere che la stessa roba si puo’ ottenere facendo un bel controllo dei log. Comunquesia l’UL ha cominciato a strillare come il suddetto bimbo ed il DNS e’ cambiato come per magilla. Ed il sito si e’ fermato.

Dopo numerose urla e strilli vari si e’ scoperto che i signori ‘analisti’ non hanno analizzato bene la situazione e la banda del loro sistema non e’ sufficiente a permettere l’analisi del sito in questione.

Dopo una manica di bestemmie e prove varie $noipensiamo ha pensato bene di tornare sui suoi passi e rimettere il DNS come stava prima (aka: usare il servizio che funziona). Ma gia’ si sa che le cose non sono mai cosi’ semplici. Ed infatti dopo un po’ arriva l’ideona degli analisti analizzatori: “dividere” il sito tra la parte ‘statica’ e la parte ‘dinamica’ “che poi e’ quella che importa” in modo che loro possano solo analizzare i contenuti dinamici.

Ed ovviamente (2) chi e’ che si becca il problemino da smazzare? (sarcasmo).

Ora, io ho cercato di far notare che se il problema e’ “Analizzamistoca$$o” non ha abbastanza banda, la soluzione e’ LORO si comperano la banda necessaria e si mettono giu’ un sistema che lo consenta di fare, e non “noi risolviamo il problema”. Ma non so come mai questo tipo di ragionamenti non funzionano mai molto bene.

Dopo un po’ di casini (causa il sistema a dir poco astruso con cui l’intero marchingegno e’ organizzato) riesco ad identificare tutta una serie di problemi.

  1. ci serve un altro certificato SSL per il nuovo dominio
  2. ci serve un indirizzo IP libero per il sito perche’ senno’ col cavolo che funziona
  3. occorre aggiungere il nuovo dominio a tutti gli application server per evitare redirect infinite
  4. occorre scovare tutti gli url ‘statici’ e redirigerli verso il nuovo dominio

E dopo tutto questo non funziona perche’ apparentemente sembra che la parte ‘statica’ non sia un gran che statica e dato il merdaviglioso cms che questa gente utilizza (che fa apparire quello scritto dai famosi slavi un miracolo della tecnologia moderna) se l’hostname non corrisponde a quello del sito non funziona un tubo!.

Percui si parte con Rewrite di headers, cambiamenti di html ‘al volo’ e cose cosi’… che oltre a rendere il sistema gia’ complicato ancora piu’ complicato, comportano anche strani problemi intermittenti (il famoso cms…) percui in alcuni casi si formano dei loop di rewrite ed in altri casi no.

E nel frattempo qualcun altro sta’ anche strillando che vuole la nuova versione del suddetto cms…

Davide

legenda personaggi

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

[SdSM] OppenSousser…

 Scritto da alle 06:27 del 21/01/2014  Nessuna risposta »
gen 212014
 

Ahhhh… La gioia dell’Open Source. Che tutti dovrebbero sapere oramai che ca$$o significa, invece io continuo a vedere che quando i vari SL/UL parlano di Open Source loro intendono “software AGGGRATISSE” mentre invece dovrebbero pensare “software di cui posso vedere i sorgenti”. Ma dato che a loro dei sorgenti non gliene frega una beneamata favonza la definizione viene cambiata in quella che riescono a capire molto meglio.

E’ l’eccitazione della scambola, quando riescono ad autoconvincersi che stanno ricevendo qualche cosa per niente, senza guardare in effetti a quanto gli costa. Un po’ come quando il mio ex-ex-ex-ex-SL cerco’ di convincermi che “noi” (noi chi?) il Sexchange non lo avevamo pagato niente ed io ritorsi che no, tu lo hai pagato e come, lo hai pagato perche’ faceva parte del package di software che era di proprieta’ di $dittafallita che tu hai spinto a rilevare, quello che non hai e’ una fattura con su scritto ‘Sexchange’ ed una cifra accanto. E dato che quella merda e’ pure una sottoscrizione, se vuoi continuare ad usarla dovrai ripagarla l’anno prossimo. Quindi non lo hai nemmeno comperato, lo hai affittato. E tacciamo sul costo dell’hardware necessario a farlo girare. Ma quando uno si convince non c’e’ molto che tu gli possa dire per convincerlo del contrario.

Bando ai preamboli e veniamo al sodo, siamo di nuovo a parlare di $allupati, i quali, dopo la “cloudizzazione” (ossignur…) hanno deciso di aggiungere qualche altro pezzo di software al loro marasma perche’ senno’ era troppo semplice. Questa volta hanno selezionato un… coso… ok, sarebbe, in teoria, un qualche tipo di motore di ricerca. Che viene venduto come “specificamente pensato per siti di e-commerce”. Che vor di’? Avete mai visto quei siti in cui voi cercate un prodotto e quello vi risponde “il 33% di quelli che cercano quel prodotto sono anche interessati a prodotto X Y e Z” che non c’entrano (in genere) una beata fava con quello che stavate cercando voi? Bene. Ecco, quello e’ il concetto.

Comunque sia, questo accrocchio viene pubblicizzato e venduto (aka: vogliono il grano) con una serie di caratteristiche altisonanti, una delle quali e’ che e’ “basato su software open-source”. Le altre caratteristiche sarebbero che e’ “fail proof”, ma sappiamo tutti che cosa vuole dire quella frase no?

L’SL della situazione si e’ lanciato ed ha acquisito una licenza temporanea per l’accrocchione ed ha cominciato a spingere per l’uso della cosa in ogni dove e come, citando le varie capacita’ del prodotto in modo quasi religioso. Non so esattamente cosa cappero stesse pensando quando lo ha acquistato. In ogni caso, nel giro di un mesetto (ed un numero impressionante di releases), il “coso” e’ diventato una parte fondmamentale della uebapplicascion di sta gente. Talmente ‘fondamentale’ che se qualche cosa non funziona in quel coso l’intera applicazione si inchioda…

Ora, unite alla precedente frase il termine ‘fail proof’ ed avete una vaga idea di quello che succede normalmente (esplosione termonucleare).

Una persona meno orientata al “technical know-how” e meno avvezza ai principi del “web 2.0 main-stream” o, banalmente, con un cervello funzionante, avrebbe intuito che il prodotto fosse meno che fantastico, lo avrebbe probabilmente messo sullo scaffale (o nel cesso) dove dovrebbe stare, avrebbe ammesso la cazzata e sarebbe andato avanti senza altri casini. Ma il fatto di dover ammettere una cazzata implica che le cose non possono di certo andare cosi’.

Le release, sottorelase, bugfix e chi piu’ ne ha piu’ ne metta si susseguono, e dato che questi rincoglioniti non possono essere off-line per manco 30 secondi le richieste di reboot e restart devono essere fatte solo tra le 7 e le 7.30 del mattino, i servers (che gia’ sono tanti) si moltiplicano ulteriormente. Adesso il foxxuto “motore di ricerca” ha non uno ma ben 5 servers dedicati, che apparentemente pero’ soffrono tutti di delirium tremens concorrente e vanno in coma con cadenza giornaliera.

Ma il bello deve ancora venire. Stamani una mail da parte degli assatanati che hanno prodotto il famoso ‘motore’ cade nella mia inbox, non so bene perche’, con il messaggio che la licenza ed il supporto per quell’arnese sono scaduti e che se vogliono continuare ad usarlo dovranno pagare. Mi assicuro subito che la mia mail sia solo in CC e che la mail originale sia stata spedita ad $allupati. Dato che e’ cosi’ mi tranquillizzo ed aspetto.

Un paio d’ore dopo mi suona il telefono.

SL – Ho appena ricevuto una mail che la licenza di $meraviglia e’ scaduta! Che cosa significa??
IO – Che la licenza e’ scaduta?
SL – Ma comeeee??
IO – Non ne ho idea, quella roba non l’abbiamo mica comperata noi.
SL – E che vuol dire che se vogliamo usarla dobbiamo pagarla?
IO – Che se volete usarlo dovete pagarlo?
SL – Ma e’ opensousse!
IO – E che c’entra? E che c’entriamo noi esatta…
SL – E’ opensusse! Non devo pagarlo!
IO – Credo che chi lo vende potrebbe avere qualche cosa in contrario al riguardo. In ogni caso perche’ lo dite a me?
SL – Perche’ siete voi che gestite queste cose!
IO – No, no, questa roba l’avete scelta, selezionata, acquistata voi. Per cui siete voi che vi gestite la cosa. Noi l’abbiamo solo installata.
SL – E perche’ mi mandano una fattura per 4 licenze?
IO – Forse perche’ avete richiesto l’installazione su 4 servers?
SL – Ma e’ openssusse!!
IO – E c’e’ “gratis” scritto da qualche parte?
SL – E’ OPENSUSSER!!

Quanto tempo ci vorra’ prima che il concetto di ‘open source’ sia disaccoppiato da quello di ‘gratuito’?

Davide

legenda personaggi

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

[SdSM] Domande domande domande…

 Scritto da alle 06:27 del 29/10/2013  Nessuna risposta »
ott 292013
 

domande-risposte-36719

E’ un mercoledi’ come tanti altri, il che significa noioso e piovoso, quando una mail turba la pace della mia casella di posta. E’ di SL, quello di $noiguardiamolavostrarobba, quello che voleva fare tutto da solo per risparmiare (tempo e soldi, soprattutto soldi) ed ha finito con lo spendere molto di piu’ tempo e molti ma molti piu’ soldi di quanto possa fare piacere a chiunque, il quale e’ preoccupato perche’ durante il recente Grande MacelloRilascio, il backup che aveva fatto del database si e’ rivelato totalmente inutile.

Ho come la vaga impressione che il backup stesse occupando troppo tempo e sia stato semplicemente interrotto a meta’, dal cui la sua inutilita’ quando hanno cercato di fare un restore, ma sto’ divagando.

In ogni caso, adesso SL si sta domandando (e domandandolo a me ovviamente) quale sarebbe il miglior modo di fare un backup “funzionante” come lo definisce lui, che consenta un ripristino dei dati in caso di catastrofe e richieda poco, anzi pochissimo, anzi niente tempo per essere generato ed usato e se posso fare un esempio di comando da usare.

Qualche cosa mi fa pensare che SL stia cercando di aggirare le limitazioni che lui stesso ha richiesto al suo contratto di assistenza facendo domande apparentemente innocue ed innocenti.

Dopo averci pensato un po’ decido di rispondere con una risposta abbastanza generica che non contenga ne’ troppe imprecisioni ne’ troppe informazioni dettagliate, suggerendogli di leggersi la documentazione e che prima di pensare a linee di comando e come fare le cose dovrebbe schiarirsi le idee sul cosa fare.

La faccenda ovviamente non si e’ fermata li’. E dopo un po’ DB e’ balzato al comando ed ha proposto un bell’incontro faccia a faccia. Il che significa un bel meeting (<sarcasmo>quanto mi mancavano!</sarcasmo>) per discutere le “modalita’ di ottimizzazione del sistema”… qualunque cosa voglia dire (tipo: far fare le cose a chi sa farle?). Partecipanti al pistolotto: DB ed IO da una parte, SL ed UL dall’altra. Qualche cosa mi fa pensare che adesso sappiamo anche chi e’ il misterioso programmatroto responsabile di tutto il gran casotto.

SL – …e quindi vorrei sapere come ottimizzare il backup.
IO – Il backup viene gia’ fatto dal nostro sistema tutte le notti e trasferito off-site, se quello che vi serve e’ una copia possiamo anche inviarvene una al mattino.
SL – Ma quel backup che voi fate contiene tutto il database! A me serve solo un backup del database $taldetali
IO – Possiamo schedulare un backup separato per quello.
SL – Ma mettiamo che io voglia farlo al momento, che parametri devo mettere? Per esempio i parametri –pippo e –pluto e’ meglio metterli o no?
IO – A parte che non ho idea di che cosa facciano, ma in genere, se un parametro non e’ di default e non si sa se serve o meno e’ meglio non usarlo.
SL – Ma voi li usate?
IO – Non so nemmeno a che servono, dovrei guardare la documentazione, ma qualche cosa mi dice che no, non li usiamo.
SL – Ma per esempio, se io non faccio il backup compresso mi viene un backup di 7 Gb, che non so dove mettere, se pero’ lo comprimo ci mette una vita, io vorrei fare una cosa veloce…
IO – “veloce” e “compresso” nella stessa frase non funzionano.
SL – Ma se io uso $unqualchetoolmaisentito lui mette automaticamente queste opzioni, perche’?
IO – Magari dovresti domandarlo a chi ha scritto il tool. Probabilmente perche’ lui pensava servissero.
SL – Ma insomma, queste opzioni devo metterle o no?
IO – Come gia’ detto, se le opzioni servono si mettono, se no non si mettono. Il punto e’ che voi non avete ancora spiegato cosa volete farci con questo backup.
SL – Allora, io vorrei avere una copia del database sul nostro sistema di sviluppo per fare le prove e poi se qualche cosa va male durante un rilascio vorrei poter fare un rename e rimettere a posto il database! Come faccio?
IO – Per prima cosa, non potete fare un ‘rename’ del database perche’ non funziona cosi’, il database deve per forza essere ricostruito dal backup, per seconda cosa, tenere in sync due database e fare un backup “al momento” per un rilascio sono due problemi separati, nel primo caso si potrebbe usare un sistema di sincronismo o replicazione, ma stento a proporlo dato che il vostro database e’ gia’ abbastanza carico e nel secondo caso e’ molto meglio non usare compressioni di sorta perche’ aumenta il tempo richiesto. Quindi quei parametri di cui parlate vanno uno in conflitto con l’altro.
SL – Ma allora perche’ $toolmaisentitoprima li mette sempre?
IO – Non lo so, domandatelo a chi lo ha scritto.
SL – E non potete fare voi uno script che noi possiamo usare per fare il backup?
IO – guardando DB hmmm?
DB – Questo e’ sicuramente possibile ma si tratta di sviluppo e non e’ coperto dal vostro contratto di assistenza.
SL – Ma e’ uno script!

A questo punto hanno cominciato a cavillare di tempi, livelli e cose cosi’ ed io mi sono limitato a guardarli e pensare che a volte, per risparmiare si finisce con lo spendere troppo.

Davide

legenda personaggi

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

[SdSM] Chi Piu’ Risparmia…

 Scritto da alle 06:27 del 03/08/2013  1 Risposta »
ago 032013
 

Gustave_Doré_-_Dante_Alighieri_-_Inferno_-_Plate_10_(Canto_III_-_Charon_herds_the_sinners_onto_his_boat)

Ritorniamo a parlare di $noiguardiamolavostrarobba di cui avevo gia’ detto abbastanza.

Quando, due anni fa, l’allora SL di belle speranze e di tasche gonfie di soldi prestati dalla banca aveva iniziato la sua ventura, si era deciso di avere due ambienti paralleli, uno per la “produzione” ed uno per il test. In modo da poter provare le cose in maniera piu’ o meno veritiera prima di scaraventarle su internet a pigs&dogs. Ora, tutti sanno che il problema dell’avere un ambiente di ‘test’ veritiero e’ il tenerlo il piu’ possibile “allineato” con quello di produzione, se i due ambienti si sballano piu’ di tanto non ha alcun senso.

Dato che, visti gli ultimi ribaltamenti, SL ed UL hanno deciso di farsi i rilasci da soli, lo stato di tali ambienti e’ andato piu’ o meno alla deriva per cavoli loro. E dato che hanno deciso di aggiungere altri servers all’ambiente di produzione, per evitare “costi eccessivi”, hanno anche deciso di dismettere l’ambiente di test sostenendo che “non e’ utile alla funzionalita’ del sistema” (cioe’ hanno preteso di farsi le prove in casa sulla stessa macchina su cui fanno lo sviluppo). Ovviamente la mia osservazione che un ambiente di test su cui si fa anche lo sviluppo non e’ proprio il meglio per fare dei test non e’ stata bene accetta.

Comunque sia, dopo i ribaltamenti di cui ho gia’ accennato i due sarchiaponi sono andati avanti per cavoli loro. Fino ad oggi, quando, all’alba delle 9.30 ricevo una bella telefonata da SL che vuole sapere quanto e’ il “carico” del loro foxxutissimo database server. Probabilmente pure lui ha letto lo stesso articolo di questa gente.

Dopo avergli spiegato pure a lui che il load average non e’ il modo migliore di giudicare il carico di un sistema (spiegazione che, come previsto, non e’ stata minimamente recepita) il tipo si mette a parlare di come a mezzogiorno vogliono fare un mega-rilascio e quindi sono preoccupati per il carico del database.

SL – …e quindi vogliamo, se possibile, aggiungere una CPU al nostro databaseserver.
IO – Hummm (guardo lo stato dell’host) In tal caso sarebbe meglio spostare la macchina virtuale su un diverso host dato che quello su cui si trova ha gia’ tutte le cpu occupate, mentre quest’altro host ne ha a bizzeffe.
SL – Ma quanto ci vuole a spostare la macchina?
IO – Spegnere la macchina, spostarla da un host all’altro, aggiungere cpu, avviare, aggiornare tools, riavviare… un 10~15 minuti credo.
Urla, gemiti, grida, rantoli di terrore ed orrore, immaginatevi un girone infernale dantesco a caso ed avete una vaga idea della cosa
SL – QUINDICIMINUTI!!! No no,.. troppo tempo, non possiamo avere tutto questo downtime!
IO – Ma non dovete anche fare un mega-rilascio?
SL – Si’.
IO – Con aggiornamento del database?
SL – Si’.
IO – E non fate anche un backup del database prima di aggiornarlo?
Urla, gemiti, grida, rantoli di terrore ed orrore, immaginatevi un girone infernale dantesco a caso ed avete una vaga idea della cosa
SL – No. Non possiamo permetterci tutto questo downtime!
IO – Quindi volete fare un update del database senza una possibilita’ di rollback? Vabbe’ il server e’ il vostro eh…
SL – Comunque, quanto costerebbe aggiungere la CPU?
IO – Hmmm… Bho, momento…

E detto questo gli passo DB per i dettagli monetari. Dopo una mezz’ora DB compare asciugandosi la faccia.

DB – Maronna! SL e’ una cosa insopportabile… Quando mia moglie ha fatto il parto cesareo si lamentava di meno…

(mi trattengo dal dirgli che forse sua moglie era anestetizzata)

IO – Quindi che si fa?
DB – Ok per l’aggiunta della cpu.
IO – Con downtime di 15 minuti?
DB – Si’ alla fine si e’ deciso.

Detto questo vado avanti a fare quello che dovrei fare fino alle 12, quando SL ricompare al telefono con sottofondo di geremiadi per darmi il via per il trasferimento. Eseguo mentre lui ed UL madonnano uno contro l’altro al telefono per installare, copiare ed aggiornare le varie cose nel loro mega-ambientone. Non c’e’ bisogno di dire che la nuova macchina virtuale e’ in funzione da una mezz’ora prima che questi arrivino al punto di ‘aggiornare il database’.

Tanto per divertimento guardo un po’ che cosa e’ cambiato nel loro megasistema… ed e’ cambiato parecchio di sicuro: non funziona piu’ un tubo. Dopo una quindicina di minuti mando una mail ad SL domandando se la cosa e’ attesa oppure no. Ricevo in risposta una mail che piu’ o meno dice “ci stiamo lavorando”.

La giornata trascorre con mail ad intervalli randomici che dicono “e’ a posto” seguite da “merda non e’ a posto per niente”. Alcuni dei server vengono riavviati a raffica (apparentemente e’ l’unico modo per far funzionare la nuova versione dell’applicazione). La cosa si trascina fino a circa le 8 di sera quando mi becco una telefonata da DB che mi domanda se posso richiamare SL prima che gli venga (a tutti e due) un collasso.

SL – (Urla, gemiti, gri…ok avete capito) E’ possibile fare un restore del database?
IO – Quale database? Quello di cui non facciamo piu’ i backup perche’ avete deciso che costava troppo?
SL – Si’ quello…
IO – Mah… l’ultimo backup e’ di 1 mese fa… non sono del tutto sicuro se funzioni.
SL – Non c’e’ un backup piu’ recente?
IO – Se non ne avete fatto uno voi prima di aggiornare no.
SL – No, non ho fatto un backup perche’ ci mette troppo tempo e volevamo ridurre il downtime.
IO – (mepensa: e adesso sei ad 8 ore di downtime, bella pensata del ca$$o) E allora non e’ che ci sia molto da fare. A meno che voi non possiate rifare l’aggiornamento a rovescio.
SL – Come sarebbe a dire?
IO – Rifare gli stessi aggiornamenti a rovescio, cioe’ invece di aggiungere togliere e roba cosi’…
SL – … non e’ che potreste darci una mano?
IO – Alle 8 di sera?

Per farla breve, sono stato fino quasi a mezzanotte per ‘rigirare’ lo script di aggiornamento e rimuovere selettivamente tutto quello che era stato modificato, certe cose ovviamente non possono essere rimosse (se fai un Update non ho idea di cosa ci fosse nei campi prima) ma a mezzanotte e’ sembrato che il loro foxxuto coso comiciasse a funzionare, se non altro non doveva riavviarsi ogni 5 minuti.

Come al solito, quando si cerca di salvare il centesimo si finisce con lo spendere le decine per rimettere a posto i casini. Ci sara’ da divertirsi quando SL ricevera’ la fattura per interventi straordinari fuori orario d’ufficio.

Davide

legenda personaggi

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

[SdSM] To upgrade or to not upgrade…

 Scritto da alle 06:27 del 12/06/2013  2 Risposte »
giu 122013
 

Upgrade

Di tanto in tanto penso che sono io che ho qualche problema, non e’ che e’ il resto del pianeta che ha infilato la testa nel didietro. Ma andiamo con ordine.

Tanto tempo fa, in una galassia lontana lontana, una ditta di rimbamba si e’ messa in testa di gestire il suo sito interdet personale. Il che non e’ che sia una gran cosa. Il sysadmin della ditta (che probabilmente non era una cattiva persona) ha deciso di prendere un server (fisico) ed installarci sopra una qualche versione di Linux. Tutto bene, se non che la versione prescelta e’ una qualche versione di Debian. Poi il sysadmin e’ migrato verso altri lidi ed i vari ‘rimpiazzi’ hanno deciso che “finche’ funziona lascialo funzionare”.

Che non e’ che sia una politica sbagliata eh! Anzi, tutt’altro. Solo che, passano gli anni ed il server rimane sempre li’, sempre con la sua versione di Debian funzionante. Finche’, un bel giorno, il supporto sull’hardware non finisce.
E quel giorno, ci si rende anche conto che quasi tutto il software installato e’ indietro di una caterva di versioni. Scatta il panico.

Dopo un po’ di casini si scova finalmente un ‘responsabile’ del sito in una qualche ditta che si e’ ritrovata ad acquistare tutto l’ambaradan dalla ditta precedente (che si e’ dissolta nel nulla nel corso delle varie crisi economiche) percui si domanda che si dovrebbe fare di questo arnese.

I problemi sono pochi ma significativi. Le applicazioni che girano su quel coso sono vecchie e si basano su versioni di software che non sono piu’ supportate e/o contengono bug di sicurezza e sarebbe meglio aggiornarle. Ma non si possono aggiornare perche’ le applicazioni non funzionano sulle versioni nuove (o ci sono serie probabilita’ che non funzionino). Ovviamente la ditta (nella sua ultima incarnazione) e’ abbastanza reticente a buttare soldi nel rifacimento di una cosa di cui non sanno un tubo di niente.

Io faccio notare che pagano tutt’ora l’hosting per quella macchina per cui se non vogliono piu’ gestirla potrebbero dismetterla e cessare di pagare. Ma apparentemente il motto generale e’ “non toccare niente” percui si continua a pagare anche se l’utilita’ della cosa e’ abbastanza dubbia (?). Alla fine qualche cosa comincia a non funzionare piu’ tanto bene, uno script di qualche genere comincia a fallire categoricamente inviando una caterva di mail al di lui papa’, solo che l’indirizzo di posta elettronica e’ oramai non piu’ funzionante percui la posta rimbalza verso ‘postmaster’ ed indovina un po’ chi e’ che si becca la mail?

IO – …percui o questi decidono di aggiornare l’hardware ed il software oppure bisogna decidersi a dargli lo sfratto.
DB – Ma che problema c’e’ ad aggiornare la macchina?
IO – A parte che l’hardware non e’ piu’ supportato? E che aggiornare il software potrebbe significare che le applicazioni non funzionano piu’? E che non abbiamo la piu’ pallida idea di cosa funziona su quel coso? Nessuna.
DB – Hai parlato con UL?
IO – Non posso parlare con UL perche’ non lavora piu’ per loro, ne’ UL2 o UL3 che sono riportati nella documentazione di quell’arnese. Apparentemente nessuno dei coinvolti nel progetto iniziale e’ piu’ in giro. Ho parlato con un CL che non sa un tubo e non vuole o puo’ prendersi alcuna responsabilita’.
DB – Ok, allora provo io a parlare con l’ex SL che magari ha un’idea.

Mi preoccupo sempre quando gli SL hanno delle idee, ma lascio che DB se la gestisca lui. Un paio di giorni dopo siamo di nuovo a consulta.

DB – Allora, ho parlato con SL che ha avuto un’idea.
IO – Sentiamo.
DB – Dunque, e’ possibile installare un rimpiazzo no?
IO – Un rimpiazzo? Un rimpiazzo di che?
DB – Intendo un server nuovo con il software vecchio.
IO – ?? eh?
DB – Noi prendiamo un server nuovo e ci installiamo una copia del server vecchio.
IO – Cioe’… fammi capire, tu vuoi prendere una macchina con dell’hardware attuale, hardware che non esisteva nemmeno quando quella versione del kernel fu creata, installare un versione di kernel e di utility di sistema che e’ vecchia di almeno 8 anni, installare una serie di tools, compilatori, interpreti eccetera eccetera vecchi di 8 anni e poi farci girare sopra le applicazioni?
DB – Si’…
IO – Ehi! Lo sai una cosa? Lo abbiamo gia’!
DB – Eh?
IO – Si’… si chiama il vecchio server!
DB – Ma di quello l’hardware non ha piu’ supporto!
IO – E le probabilita’ che il software vecchio di 8 anni funzioni su un hardware di oggi sono abbastanza basse, ma anche se funzionasse, non sarebbe meglio risolvere il problema invece di trascinarlo?

Lo so gia’ che finiremo (nel senso che IO finiro’) con il fare salti mortali per far funzionare quella roba su nuove versioni di OS e sistema finche’ qualcuno non decidera’ di tagliare la testa al toro e semplicemente spegnere l’intero arnese.

Davide

legenda personaggi

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

[SdSM] Curare e’ sempre meglio che prevenire

 Scritto da alle 06:27 del 07/04/2013  1 Risposta »
apr 072013
 

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

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