Questo articolo è dedicato a chi non si occupa in maniera professionale dei temi trattati, alcune parti tecniche sono, pertanto, generiche e tecnicamente poco precise.
Voglio qui spiegare in modo, spero, semplice cos’è cambiato per quasi tutti in questi venti anni di servizi esposti a Internet in tema di infrastruttura, ovvero quello che, generalmente, gli utenti non vedono.
Siamo nel 2000, in pieno boom delle dot-com. Il sottoscritto in quel periodo passava gran parte le giornate ad installare server e storage per conto di COMPAQ ed era di casa nei datacentre di Milano e Roma dei maggiori fornitori Internet e di alcune grosse aziende.
In quel periodo la virtualizzazione era ancora cosa per pochissimi e comunque non mainstream. Chi offriva servizi su Internet lo faceva, essenzialmente, seguendo tre strategie.
Prima opzione: un bel serverone. Molti servizi erano ospitati su un solo server dove c’erano dati e pagine HTML. Il server era dimensionato per sostenere un ragionevole carico di traffico. Considerate che vent’anni fa nessuno si stracciava le vesti se un sito andava giù per dieci minuti e la velocità di accesso a Internet era tale per cui il collo di bottiglia era quasi sempre la connettività, non certo il server. Questa strategia era anche quella dei server aziendali: si dimensionava l’hardware in base al carico massimo, con il risultato che per l’80% o, spesso, 95% del tempo la macchina era lì a consumar (tanta) corrente e basta.
Seconda opzione: cluster. Chi aveva soldi da spendere (parliamo di non meno di 30 milioni del vecchio conio di solo hardware per una soluzione entry level) approntava un cluster, ovvero due (i ricchissimi più di due, ma erano veramente pochi) server con dei dischi locali per il sistema operativo e i programmi; i due nodi erano collegati via SCSI in rame o Fibre Channel in fibra ad uno storage condiviso dai nodi, nel senso che i due server potevano accedere alle medesime partizioni dello storage. In un cluster ogni servizio (inteso come istanza di database, file server, istanza di server HTTP, eccetera) girava su uno solo dei due nodi (c’erano eccezioni, ma non complichiamo la storia). Il trucco era avere almeno due servizi e ripartirli sui nodi; in caso di spegnimento di uno dei nodi, i servizi migravano sul nodo supersite con un downtime di massimo 4 o 5 secondi (dipendeva dal tipo di servizio e dal hardware sottostante). Qui abbiamo un pochino di ridondanza e di distribuzione, ma un nodo doveva, comunque, essere in grado di reggere il carico dell’intero sistema in caso di guasto del gemello. Era una sorta di RAID1 di servizi.
Terza opzione: frontend/backend. Si tratta di avere come frontend una serie di server HTTP che dialogano da un lato con Internet e dall’atro con i fornitori di dati (file server o SQL server) che stanno dietro (backend). Con tecnologie che ora sembrano rozze, ma che per quel periodo erano all’avanguardia, era possibile avere un numero relativamente arbitrario (dipendeva dalla tecnologia utilizzata) di frontend da modulare in base al traffico previsto oppure alle nuove esigenze di traffico. Il backend era in questi casi un robusto e carrozzatissimo server SQL. Ovviamente ogni frontend era una macchina fisica con una connessione di rete verso Internet e una verso il server SQL. Le tipiche macchine da frontend erano i server a 1U, le novità del momento.
In buona sostanza, se nel 2000 volevate avere un pochino di ridondanza a livello servizio oppure un minimo di elasticità dovevate comperare tanto ferro per far fronte ai momenti di massimo carico e lasciarlo poi a far quasi nulla per gran parte della sua vita.
Facciamo un salto in avanti di quasi 10 anni: il boom delle dot-com è storia antica, oscurata dagli eventi del 9/11, COMPAQ si è fusa in HP, Altavista è cosa nota solo ai vecchi nostalgici del secolo precedente, Apple sta convincendo tutti di quanto sia essenziale avere un iPhone collegato a Internet via rete mobile. Ah, sì. C’erano anche i Blackberry. VMware ESX[i] è alla versione 3 ed è finalmente un hypervisor bare metal, ovvero il server fisico fa il boot con ESX[i].
Nel 2007 o 2008 avevo partecipato per la prima volta ad un grande evento di VMware in Italia. In apertura il responsabile EMEA di VMware aveva raccontato che fino a prima della virtualizzazione il gestore dei bancomat (o delle carte di credito, non ricordo esattamente) spagnoli aveva l’infrastruttura di server fisici dimensionata per far fronte al traffico di un paio di giorni dell’anno (vicino a Natale) e per il resto dell’anno i server stavano lì a oziare. Con la virtualizzazione poteva gestire meglio le risorse e dedicarle alle macchine di frontend nei due o tre giorni di necessità e ad altri scopi nel resto dell’anno.
Dieci anni fa la virtualizzazione diventata mainstream permetteva, quindi, di gestire al meglio le risorse del hardware e permetteva di assegnare risorse là dove erano necessarie.
Per spiegare in parole povere cosa sia la virtualizzazione, considerate il vostro computer che fa girare diversi programmi contemporaneamente, la stessa cosa avviene nella virtualizzazione, ma al posto dei programmi sono interi computer virtuali. Inoltre tecnologie simili a quelle del cluster descritto sopra permettono di spostare le macchine virtuali da una macchina fisica all’altra senza interruzione. Capite, quindi, che se avete dei momenti di basso carico, si possono consolidare le macchine virtuali si poche macchine fisiche e spegnere temporaneamente le macchine fisiche inutilizzate.
In quegli anni stavano nascendo i primi strumenti di orchestrazione delle risorse virtuali, quelli che avrebbero poi spianato la strada al cloud computing. Quello vero, non quello del marketing dei computer alla frutta. Immaginate di essere un grande fornitore di macchine virtuali e di avere un’infrastruttura fisica che si adatta al carico richiesto. Il sistema accende e spegne automaticamente pezzi fisici dell’infrastruttura in base alle richieste di macchine virtuali. Inoltre un sistema di analisi dell’attività delle macchine virtuali vi permette di fatturare al cliente un tot non in base al numero di macchine virtuali, ma al loro consumo effettivo di risorse (se la macchina virtuale esegue 2+2 una volta al secondo pagate pochissimo, se genera dei frattali ad alta risoluzione e li spedisce via Internet pagate di più)
Facciamo un ultimo balzo temporale per arrivare in questo disastrato 2020, tutte le organizzazioni (tranne una) di servizi online traggono beneficio dalle funzioni elastic del cloud computing descritto appena sopra.
Se dovete offrire un servizio online in cui non sapete qual è l’affluenza dei clienti predisponete un insieme di macchine virtuali di un provider di cloud computing, le tenete spente (quindi non pagate) e configurate il vostro insieme di risorse per accendere automaticamente le macchine virtuali in caso di picchi di utilizzo e spegnerle in caso di utilizzo ridotto. Esistono ovviamente degli strumenti che automatizzano questo processo. Pagherete solamente le risorse utilizzate e i vostri utenti percepiranno sempre il servizio come disponibile; è il sacro graal di chi deve gestire questo tipo di servizi.
Questo concetto è familiare da anni a tutti coloro che configurano e gestiscono servizi dedicati ad un’ampia gamma di utenti con picchi di traffico improvvisi.
Tutti tranne coloro i quali gestiscono i servizi governativi come i click day dell’INPS, del bonus biciclette o l’iniziativa di cashback. Queste persone sembrano ferme a vent’anni fa, non riescono a configurare un insieme di macchine virtuali che traggono beneficio dalla feature elastic del cloud computing e riescono a portare la proverbiale inefficienza della PA italiana anche su Internet.
Lascia un commento