Dove ci porta la tecnologia senza gestione?

Dove ci porta la tecnologia senza gestione?

Dove ci porta la tecnologia senza gestione?

Sono davvero debitore a Tom Bittman per la sua celebre frase:

“Virtualization without good management is more dangerous than not using virtualization in the first place.”

In effetti virtualizzare è diventato comodo, conveniente ed alla portata di chiunque, ma se anni fa un problema sullo storage di un server (da una banale partizione piena, ad un controller guasto o ad un firmware buggato) colpiva al massimo un singolo servizio oggi le possibilità di mettere al tappeto l’intera azienda in una sola mossa sono indubbiamente aumentate.
Questo vale in generale per tutte le soluzioni tecnologiche complesse. Uno dei principali compiti del consulente informatico dovrebbe essere quello di indirizzare le organizzazioni verso soluzioni tecnologiche che non solo rispondono alle esigenze espresse dal cliente ma siano anche adeguate e sostenibili in termini di complessità e skill necessari, alla realtà in cui vengono applicate. Guardandosi in giro, il mondo è pieno di controesempi.
Il più illuminante lo sperimentai dal vivo nell’estate del 2003. Un cliente, una piccola realtà manifatturiera, era arrivato alla conclusione che per raggiungere un’elevata disponibilità del sistema si sarebbe dovuto dotare di un database in cluster. Nella sua mente il mero acquisto del sistema in cluster significava ottenere automaticamente la massima disponibilità del sistema. Dieci anni fa i cluster di fail-over erano ancora architetture di una discreta complessità e nel progetto venne sottovalutato il fatto che nello staff IT mancassero le competenze per una corretta gestione di una tale infrastruttura.
Alla fine il fornitore mise in piedi il cluster, lo testò e lo portò con successo in produzione.
Circa due mesi dopo, un temporale determinò un black-out di alcune ore, dopo il quale il cluster sembrava non partire più. Nelle settimane precedenti i tecnici dello staff IT avevano aggiunto un nuovo servizio al cluster ma non avevano testato tutti i possibili scenari di failure. Il fornitore intervenne la mattina seguente per ripristinare la situzione. Con un po’ di lentezza la produzione tornò a regime.
La settimana successiva un elettricista intervenì nella sala server dell’azienda per una serie di riparazioni (tra cui la sostituzione dell’UPS e lo spostamento di alcuni server in un secondo rack). Durante i lavori vennero scollegati sia il cavo di heartbeat del cluster, sia uno dei dispositivi di fencing. Per rimettere in funzione il cluster che (ovviamente e a ragione!) non voleva saperne di ripartire, un’operatore pensò bene di forzare l’esecuzione dei servizi su un nodo. Le partizioni condivise vennero montate da entrambi i nodi, che iniziarono allegramente a scrivere sugli stessi blocchi e al posto dei datafiles ci si ritrovò ben presto con un ammasso informe di bit inutilizzabili. In gergo questa situazione si chiama “split brain”.
Il seguito potete immaginarlo (restore da nastro, rebuild del database, ecc.): la produzione restò ferma per due giorni interi e si persero i dati delle transazioni delle ultime 12 ore.
Mi sorge un dubbio: siamo veramente sicuri che un sistema single-server avrebbe avuto una affidabilità complessiva inferiore a quella del cluster…?
Lesson learned:
“Technology without good management is more dangerous than not using technology at all.”

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *