Ovvero:  i paroloni dell’IT demistificati.

Avete invitato a cena il/la ganzo/a, cucinato una teglia di splendide lasagne per prenderlo/a per la gola e pregustate una serata indimenticabile. Durante l’aperitivo vi accorgete che, per cause indipendenti dalla vostra volontà e fuori dal vostro controllo, le lasagne non sono più commestibili. Ad esempio le ha mangiate il gatto, o il forno si è rotto e le ha bruciate.

La vostra proverbiale sagacia vi viene in aiuto: tirate fuori dal frigo un pacco di spaghetti pronti congelati e  scongiurate il disastro. Il/la ganzo/a era già pronto/a ad andare a mangiare da un’altra parte, magari senza di voi. Avete ottenuto il vostro scopo, sebbene tramite risorse non ottimali.

Se voi foste un router, un controller o un cluster, quello che avete appena fatto si chiamerebbe failover.

Ma andiamo avanti. Appena iniziati gli spaghetti precotti, sentite suonare alla porta: è vostra madre che vi ha portato una teglia delle sue leggendarie lasagne. Con la velocità di un furetto congedate la genitrice e sfilate da sotto il naso del/la allibito/a ganzo/a il piatto industriale sostituendolo con il manicaretto. La cena è salva e siete ritornati al menu previsto, che vi assicura un proseguimento degno delle vostre aspettative.

Se voi foste sempre uno dei sistemi di cui sopra, avreste appena fatto un failback, anzi, un preempt and failback. Appena la risorsa originale e qualitativamente superiore è  stata nuovamente disponibile, ne avete approfittato per ripristinare lo stato ottimale senza aspettare che la risorsa sostitutiva si esaurisse.

I sistemi di failover si applicano solitamente a connessioni, servizi e storage e servono ad assicurare la alta affidabilità di sistemi critici. Tipici esempi possono essere: connessioni multiple collegate ad uno stesso firewall che gestisca il load balancing,  controller ridondanti per sistemi di storage SAN, per evitare di avere un “single point of failure”, diversi server collegati in un cluster che assicurano la continuità di un servizio anche in caso di caduta della macchina che lo eroga. Non necessariamente la risorsa che subentra è meno performante, nel caso della connettività spesso lo è per motivi di rapporto costi/benefici. Il concetto sfuma spesso nella ridondanza.

E’ più complicato di così, ma la metafora spiega il senso.

Il tutto è nato da un thread di FriendFeed finito in vacca.