Dai mainframe al VPS: la storia del cloud
Scopri come CTSS, Multics, Unix, IBM VM/370, Xen e KVM hanno portato il time-sharing dai mainframe degli anni 60 al VPS che noleggi oggi.
Da dove proviene il tuo VPS
La storia dell'informatica, dai mainframe al cloud, è la storia di un'idea diventata sempre meno costosa. Questa idea è il time-sharing: permettere a molte persone di usare contemporaneamente una macchina costosa, fornendo a ciascuna una vista privata del sistema. Il time-sharing è stato introdotto intorno al 1960, perché un computer costava più delle persone che lo utilizzavano. Ogni componente del VPS che noleggi oggi è stato sviluppato per risolvere quel problema: l'isolamento tra gli utenti, lo scheduler che assegna il tempo di CPU, l'hypervisor e la fatturazione basata sulle ore. Il problema non è mai scomparso. L'hardware è diventato economico, quindi una porzione di risorse che un tempo richiedeva un finanziamento di ricerca oggi costa pochi dollari al mese.
1959-1961: perché è stato inventato il time-sharing
Negli anni 1950 un computer eseguiva i programmi in modalità batch. Il programma veniva perforato su schede, il mazzo veniva consegnato a un operatore e il risultato stampato si ritirava in un secondo momento. Un solo carattere digitato in modo errato poteva costare un'intera giornata. La macchina rimaneva occupata, ed era proprio questo l'obiettivo, perché una macchina come l'IBM 7090 costava milioni di dollari e il tempo delle persone che aspettavano non compariva in nessuna fattura.
Nel gennaio 1959 John McCarthy sostenne l'idea opposta in un memorandum del MIT. Doveva essere la macchina ad aspettare la persona. Nello stesso anno Christopher Strachey descrisse una forma di time-sharing durante una conferenza dell'UNESCO, anche se intendeva il debugging eseguito da un programmatore mentre venivano eseguiti altri job, non molte persone che digitavano contemporaneamente. Intervenendo per il centenario del MIT nel 1961, McCarthy si spinse oltre: l'elaborazione poteva essere venduta come un servizio pubblico, con una tariffazione a consumo come per l'elettricità.
All'epoca l'obiezione era che il time-sharing sprecasse le risorse della macchina. Il cambio tra utenti consumava cicli di elaborazione, e i cicli erano la risorsa costosa. L'obiezione era corretta, ma smise di essere rilevante perché il costo di un ciclo diminuì per sessant'anni, mentre il costo di un'ora dell'attenzione umana non diminuì.
Cosa dovette inventare CTSS
Il gruppo di Fernando Corbató presso il MIT Computation Center costruì il Compatible Time-Sharing System (CTSS) per risolvere la questione. Fu dimostrato per la prima volta nel novembre 1961 su un IBM 709, servendo quattro utenti e trasferendo il lavoro di ciascun utente sulla propria unità a nastro magnetico. “Compatible” significava che la macchina poteva continuare a eseguire il vecchio sistema batch sottostante, perché nessuno acquista un computer che sappia fare soltanto la cosa nuova.
Quattro utenti sono pochi. L'elenco dei problemi da risolvere per arrivare a questo risultato non è breve, ed è lo stesso elenco che il kernel gestisce ancora oggi. CTSS aveva bisogno di uno scheduler, per impedire che un job lungo bloccasse tutti gli altri terminali. Aveva bisogno della protezione della memoria, in modo che un programma in crash bloccasse un solo utente invece dell'intero sistema. Aveva bisogno di uno storage persistente dopo il logout; per questo CTSS aveva uno dei primi file system riconoscibili da un utente moderno. E aveva bisogno delle password, affinché un utente non potesse leggere i file di un altro utente.
Rinominate questi componenti e avrete un sistema Linux. Lo scheduler è EEVDF, che ha sostituito CFS in Linux 6.6. La protezione della memoria è fornita dalla MMU (memory management unit), che assegna a ogni processo un proprio spazio degli indirizzi virtuali. Lo storage che resta disponibile dopo il logout è la home directory. Il file delle password si chiama ancora /etc/passwd.
Multics e l’utilità informatica
Il sistema successivo di MIT doveva essere l’utilità informatica descritta da McCarthy. Il Project MAC iniziò nel 1963, firmò il contratto per un General Electric GE-645 nell’agosto 1964 e pubblicò i primi articoli su Multics nel 1965. Il nome esprime già il concetto: Multiplexed Information and Computing Service. Un servizio, cioè qualcosa che si acquista a ore.
Multics richiese molto più tempo del previsto. Le macchine GE-645 prototipali arrivarono al MIT e ai Bell Labs nel gennaio 1967. Bell Labs abbandonò il progetto nell’aprile 1969. Multics fu reso disponibile ai clienti del MIT Information Processing Center il 1 ottobre 1969 e rimase poi in produzione da qualche parte per trentuno anni. L’ultimo sistema Multics operativo, presso il Canadian Department of National Defence a Halifax, in Nova Scotia, fu arrestato il 30 ottobre 2000.
Multics viene spesso considerato un fallimento perché arrivò in ritardo e funzionava lentamente. Il vocabolario tecnico racconta una storia diversa. Introdusse il file system gerarchico, con directory contenute in altre directory, una access control list per ogni file, la memoria virtuale segmentata, che consentiva a un programma di indirizzare un file come se fosse memoria, e i protection ring, che classificavano il codice in base al livello di attendibilità. I ring sono ancora presenti nel silicio davanti a voi. Ring 0 per il kernel e ring 3 per il codice utente sono termini del vocabolario Multics; la virtualizzazione hardware aggiunse in seguito una modalità al di sotto di ring 0 per l’hypervisor, chiamata informalmente ring -1.
Unix: time-sharing su una macchina accessibile
Dopo aver lasciato Multics, Ken Thompson si ritrovò ai Bell Labs senza un sistema che volesse usare. Nel 1969 iniziò a svilupparne uno molto più piccolo su un PDP-7 dismesso. Il primo Unix Programmer's Manual è datato novembre 1971; a quel punto il lavoro era stato trasferito su un PDP-11. Nel 1973 Thompson e Dennis Ritchie riscrissero il kernel in C, in modo che il sistema potesse essere portato su nuovo hardware senza doverlo riscrivere manualmente.
Per questo oggi si utilizza un discendente di Unix e non un discendente di Multics. Multics richiedeva hardware progettato per Multics. Unix funzionava su qualunque hardware economico e disponibile, e questa si rivelò la caratteristica decisiva.
"The UNIX Time-Sharing System" di Ritchie e Thompson fu pubblicato su Communications of the ACM nel luglio 1974. L'articolo descrive il VPS: processi, un unico file system gerarchico, file come semplici flussi di byte, fork, utenti e gruppi con bit dei permessi e una shell che è un normale programma, non parte del kernel. Cinquantadue anni dopo, quell'interfaccia è stata estesa, ma mai sostituita.
I mainframe eseguivano davvero macchine virtuali nel 1972?
Sì, ed è l’aspetto della storia che molti trascurano. Mentre il MIT sviluppava Multics, l’IBM Cambridge Scientific Center affrontava lo stesso obiettivo dal lato opposto. Invece di usare un unico sistema operativo per servire molti utenti, Robert Creasy e Les Comeau svilupparono un control program che forniva a ogni utente un computer simulato completo. CP-40 entrò in produzione a gennaio 1967. Ogni utente riceveva un System/360 virtuale ed eseguiva al suo interno un piccolo sistema operativo per singolo utente, CMS.
Nel 1968 CP-40 divenne CP-67 sul System/360-67 e IBM annunciò VM/370 il 2 agosto 1972. Si trattava di un hypervisor commerciale, venduto a clienti paganti, cinquantquattro anni fa. Un control program multiplexava l’hardware reale e i sistemi operativi guest venivano eseguiti senza modifiche all’interno di macchine virtuali, convinti di avere il controllo del computer.
La teoria arrivò due anni dopo, nello stesso numero di luglio 1974 di Communications of the ACM che pubblicava anche l’articolo su Unix. L’articolo di Gerald Popek e Robert Goldberg, "Formal Requirements for Virtualizable Third Generation Architectures", definiva ciò che un processore deve fare per supportare la virtualizzazione. La regola fondamentale è semplice. Ogni istruzione in grado di leggere o modificare lo stato del computer deve generare un trap quando un guest la esegue al di fuori della modalità kernel, in modo che l’hypervisor riprenda il controllo e risponda fornendo la versione privata dello stato appartenente a quel guest. Questa tecnica è chiamata trap and emulate. L’hardware IBM rispettava questa regola.
Perché il minicomputer ha cambiato il modello
DEC presentò il PDP-8 il 22 marzo 1965, a un prezzo di circa 18.000 dollari dell'epoca. Fu il primo minicomputer con un prezzo inferiore a 20.000 dollari e arrivò a vendere più di 50.000 unità. In seguito, il microprocessore ridusse ulteriormente i prezzi. Quando un reparto poté acquistare una macchina propria e, più avanti, anche una singola persona poté farlo, la condivisione di un computer centrale sembrò un problema risolto, che non richiedeva più una soluzione. Negli anni 1980 e 1990, l'elaborazione si spostò sulle scrivanie e nei rack pieni di piccoli server x86.
Lo spreco tornò a manifestarsi in una forma diversa. Eseguire una sola applicazione per server è semplice da gestire, ma lascia inattiva gran parte dell'hardware, mentre i costi di alimentazione e spazio nel rack vengono sostenuti per intero. È di nuovo il problema di CTSS, ma su una scala diversa: ora la risorsa costosa è la sala, insieme all'elettricità, non il processore. La risposta era quella di sempre. Condividere la macchina.
Perché x86 era così difficile da virtualizzare?
Perché x86 violava la regola di Popek e Goldberg. Al 9th USENIX Security Symposium, nell'agosto 2000, John Scott Robin e Cynthia Irvine analizzarono il set di istruzioni del Pentium e individuarono diciassette istruzioni che leggono o modificano lo stato privilegiato senza generare un fault quando vengono eseguite da codice in modalità utente. popf è l'esempio standard. Se viene eseguita in modalità utente, il processore ignora silenziosamente i bit che il programma non è autorizzato a impostare, invece di generare un trap. Un hypervisor basato sul modello trap-and-emulate, quindi, non viene a sapere che il guest ha tentato l'operazione.
Prima che l'hardware venisse corretto, comparvero due soluzioni. VMware, fondata nel 1998 a partire dalla ricerca Disco di Stanford, analizzava il codice del kernel guest e riscriveva le istruzioni problematiche prima della loro esecuzione. Questa tecnica è chiamata binary translation. Xen, nato presso il University of Cambridge Computer Laboratory, modificava invece il guest. Il paper "Xen and the Art of Virtualization", presentato al SOSP nell'ottobre 2003, descriveva la paravirtualisation: un kernel guest modificato chiama intenzionalmente l'hypervisor invece di eseguire istruzioni che l'hypervisor non può intercettare.
Poi l'hardware venne corretto, come IBM aveva fatto negli anni 1960. Intel introdusse VT-x su due modelli di Pentium 4 il 14 novembre 2005, mentre AMD introdusse AMD-V nel maggio 2006. Entrambe le tecnologie aggiungono una modalità del processore al di sotto di quella del kernel guest. Il guest può così eseguire il proprio kernel alla massima velocità, mentre l'hypervisor mantiene il controllo sugli eventi per i quali è prevista l'intercettazione. Questo rese possibile un hypervisor abbastanza piccolo da risiedere all'interno di un normale sistema operativo. Avi Kivity realizzò esattamente questa soluzione con KVM presso Qumranet: trasformò direttamente il kernel Linux nell'hypervisor. KVM è stato integrato in Linux 2.6.20, rilasciato nel febbraio 2007, ed è ciò che oggi esegue una quota significativa degli host VPS.
Come il VPS ha ricevuto il suo nome
All'inizio degli anni 2000 convergono due percorsi. Il primo è la macchina virtuale completa su x86, con un guest che avvia il proprio kernel. Il secondo è la virtualizzazione a livello di sistema operativo: un singolo kernel Linux condiviso, suddiviso in ambienti separati, ciascuno con il proprio utente root e la propria tabella dei processi. Linux-VServer e Virtuozzo di SWsoft compaiono entrambi nel 2001, mentre nel 2005 SWsoft pubblica parte di Virtuozzo come software open source OpenVZ. L'espressione "virtual private server" nasce da questo secondo percorso, per analogia con virtual private network.
Amazon trasforma il noleggio in una chiamata API. S3 viene lanciato il 14 marzo 2006 ed EC2 apre una beta pubblica limitata il 25 agosto 2006 con un solo tipo di istanza, eseguito su Xen. Acquistare capacità di calcolo smette di richiedere un contratto con un fornitore di servizi e diventa una richiesta che restituisce un risultato in un minuto.
Entrambi i percorsi esistono ancora e la distinzione determina ciò che si può fare con il server noleggiato. Un VPS KVM avvia il proprio kernel, quindi consente di caricare moduli del kernel e persino di eseguire un hypervisor all'interno del VPS. Un piano basato su container condivide il kernel dell'host e non lo consente. Dietro quella singola riga di una pagina con i prezzi ci sono sessant'anni di storia: per questo conviene capire la differenza tra VPS, VM e VPC prima di scegliere.
Cosa è cambiato dal mainframe al tuo VPS e cosa invece no
Sono cambiate quattro cose. La macchina non si trova nel tuo edificio. Il terminale è un programma invece di un elemento d'arredo. L'unità che noleggi è un computer completo con il proprio kernel, non un account sul sistema operativo di qualcun altro. Inoltre, il prezzo è sceso abbastanza da trasformare l'acquisto in un pagamento con carta, invece che in una procedura di approvvigionamento.
Il meccanismo non è cambiato affatto.
- La sessione
sshè un terminale in time-sharing. Ottieni un login e una shell, quindi uno scheduler decide quando il tuo processo verrà eseguito di nuovo. - L'isolamento è ancora garantito dall'hardware. Il lavoro è svolto dalla MMU e dai livelli di privilegio del processore, esattamente come era necessario per CP-40 nel 1967.
- Ti viene ancora addebitata una quota di una macchina in base al tempo trascorso, come facevano i service bureau con le ore di connessione.
- Continui a risentire della presenza degli altri tenant. Quando un host è sovrasottoscritto, la tua macchina virtuale attende una CPU fisica e Linux registra questa attesa come tempo CPU steal causato da un vicino rumoroso.
Quest'ultimo punto riassume in modo onesto l'intera storia. Condividere una macchina è un compromesso. È stato accettato nel 1961 perché il computer costava più delle persone, e viene accettato nel 2026 perché un server che funziona al dieci per cento della propria capacità rappresenta denaro sprecato. Se preferisci stare dalla parte dell'operatore in questo compromesso, eseguire Proxmox su hardware di tua proprietà ti consegna insieme l'hypervisor e i problemi dell'operatore.
Tieni presente il rapporto. CTSS serviva quattro utenti su una macchina che nel 1961 costava milioni di dollari e occupava un'intera stanza. Il tuo VPS, per pochi dollari al mese nel 2026, è un computer molto più potente di quello che il team di Corbató doveva razionare, e lo hai a disposizione per conto tuo. Puoi noleggiarlo proprio grazie a un'idea vecchia di sessantacinque anni che alla fine ha incontrato hardware economico. Se stai decidendo cosa installarci, inizia da cosa offre realmente un VPS e poi passa a cosa eseguono le persone su un VPS.
FAQ
Qual è stato il primo sistema informatico a divisione di tempo?
Il CTSS, Compatible Time-Sharing System, sviluppato dal gruppo di Fernando Corbató presso il MIT Computation Center. Fu dimostrato per la prima volta nel novembre 1961 su un IBM 709 e serviva quattro utenti, ciascuno trasferito su un'unità a nastro separata. Il primo servizio a divisione di tempo destinato a un'intera comunità fu il Dartmouth Time-Sharing System: il 1 maggio 1964, John Kemeny e uno studente programmatore eseguirono contemporaneamente programmi BASIC su due terminali e ricevettero entrambi le risposte corrette.
Le macchine virtuali furono davvero inventate negli anni 1960?
Sì. L'IBM Cambridge Scientific Center portò CP-40 in produzione nel gennaio 1967, fornendo a ogni utente un System/360 virtuale completo con il sistema operativo CMS in esecuzione al suo interno. Nel 1968 seguì CP-67 sul System/360-67 e IBM annunciò VM/370 il 2 agosto 1972. Erano veri hypervisor che eseguivano sistemi operativi guest non modificati, distribuiti commercialmente decenni prima che l'hardware x86 potesse fare la stessa cosa.
Perché la virtualizzazione x86 era difficile, mentre non lo era sui mainframe?
La regola di Popek e Goldberg del 1974 stabilisce che ogni istruzione in grado di leggere o modificare lo stato della macchina deve generare un trap quando il guest la esegue al di fuori della modalità kernel. x86 violava questa regola. Robin e Irvine contarono 17 istruzioni dei processori Pentium che in modalità utente falliscono senza generare un trap, invece di interrompere l'esecuzione. Di conseguenza, un hypervisor classico basato su trap-and-emulate non le rileva; popf è l'esempio più comune. VMware aggirò il problema tramite la binary translation e Xen tramite la paravirtualizzazione, fino a quando Intel VT-x, nel novembre 2005, e AMD-V, nel maggio 2006, aggiunsero una modalità hardware per l'hypervisor.
Affittare un VPS equivale ad avere un account a divisione di tempo?
Il modello di fatturazione e il problema dell'isolamento sono gli stessi. Cambia l'unità di assegnazione. Un utente di un sistema a divisione di tempo riceveva un account su un sistema operativo condiviso con tutti gli altri utenti, quindi l'amministratore era una persona del centro di calcolo. Un VPS KVM fornisce una macchina virtuale con un kernel e un account root propri, quindi l'amministratore sei tu. Un VPS basato su container si colloca tra i due modelli, perché condivide il kernel dell'host pur fornendo accesso root all'interno del proprio ambiente.