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.
Commenti
21 risposte a “Concetti strani in italiano standard”
“Il tutto è nato da un thread di FriendFeed finito in vacca.”
che strano. 🙂
si potrebbe invaccare anche questo …. 🙂
“in italiano standard” è più bello di “for dummies”. 😛
Se poi durante il preempt ti emozioni e fai cadere tutto avrai fatto un epic fail (senza over)
Bea
In questo momento mi sento “uno stripe di mirror backuppato a dovere” che tradotto vuol dire figlio unico di mamma meridionale che vive anche ancora in casa: nel caso in cui il piatto del giorno vada a farsi benedire c’è sempre la parmigiana scaldata del giorno prima!!
Posso aggiungere: SCACCIAFIGA!
Eh eh eh
non è finito in vacca, ha subito un detour, per altro ha portato a capire che ognuno ha il suo punto debole, per non chiamarla coda di paglia, e che spesso non ci si capisce.
io direi al contrario, che ora ne so un po piu dei tuoi punti deboli e tu un po piu’ dei punti deboli miei e di serena.
baci
s.
‘azzarola, mi hanno rubato già il commento. 😛
Dovresti farci una serie, anzi, un libro: la tecnologia spiegata senza tecnologia 😀
Quando leggi questo pensi:
Certo che e’ fuor, hem, geek all’ultimo stadio…
Poi legg, ti piace e ci pensi bene bene, ti riconosci e dici:
Porca miseria! sono conciato alla stessa deprecabile maniera….
😛
Ecco, qui ci farei un libro, da leggersi ovunque, porti il buon umore 🙂
E’ più complicato di così???
Bellina come metafora… la terrò a mente quando dovrò spiegare concetti simili! 😉
Ciao,
Emanuele
[…] ai link di questa settimana, va… Un tema stile magazine per WordPress Polpo tenta suicidio Concetti strani in italiano standard Statistiche web: quando i numeri non bastano Facebook è diverso Music Camp (se si fa io ci […]
peccato solo che ho scoperto il tuo blog quando sono venuto via da Zena
Una sola parola, anzi 3 😀
Sei un grande !! 😀
Fantastica spiegazione!!!
….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.
Quando leggo questi tuoi post è un po’ come essere a casa, essendo in ufficio. La mia anima nerd si commuove. =P
Che poi la tua spiegazione è favolosa, davvero. Ma io avrei una domanda prof. Beggi: vorrei sapere come si dice in italiano quando ti si rompe un disco mirrorato SAN e il mirror ha dei blocchi corrotti e devi partire di restore sap+oracle e nel frattempo un cluster SUN Solaris di produzione effettua uno switch dondolando da un nodo all’altro senza fermarsi e corrompe tutti i dati del DB con questo giochino? E soprattutto quando succede tutto questo di venerdì pomeriggio?
=P
Lo sai benissimo anche tu: si dice: “sfiga”.
ESATTO!!! =D
Non c’è niente da fare, non mi deludi mai…;-)
[…] Qui la puntata precendente. Tags: raid, ridondanza, Tecnica […]