Passano gli anni, ma il problema resta sempre quello: come si può sfruttare tutta la potenza del proprio hardware mantenendo workload isolati?

Chi ha iniziato nei primi anni duemila ha vissuto la prima rivoluzione, quella delle virtual machine, il cui principio di funzionamento è riassunto in questo schema:

+------------------+
| App | Guest Linux|
+------------------+
|     Hypervisor   |
+------------------+
|     Hardware     |
+------------------+

Grazie ad un hypervisor è possibile ottenere un forte isolamento, tanto da poter eseguire contemporaneamente sistemi operativi differenti sullo stesso host. Ovviamente questi sistemi vanno installati, gestiti e manutenuti. Senza contare la velocità con cui le virtual machine proliferano in questi ambienti, che normalmente sfugge di mano in un attimo.

Il principale problema delle VM, che si riassume nella domanda “Perché per far girare un webserver isolato ho bisogno di un intero sistema?“, ha innescato all’inizio degli anni ’10 la seconda rivoluzione guidata da Docker e dai container, il cui funzionamento sfrutta la possibilità del Kernel Linux di isolare i processi mediante le componenti native Namespace e CGroups:

+------------------+
| App | App | App  |
+------------------+
|    Linux Kernel  |
+------------------+
|     Hardware     |
+------------------+

Ciascuna App vive nel suo recinto, isolato dal resto del sistema.

Problema risolto? Parzialmente. Perché se è vero che l’overhead delle VM con i Container è ridotto, il Kernel in quel caso è condiviso, è lo stesso del sistema. In più c’è un aspetto estremamente rilevante relativo alla scalabilità: in contesti enterprise, dove il singolo host è insufficiente, è necessario far sì che altri strumenti di preoccupino della gestione delle applicazioni (leggi Kubernetes, OpenShift, Rancher), situazione che, inevitabilmente, aumenta la complessità.

Come ne si esce quindi? In realtà non ne si esce, le problematiche che abbiamo descritto sono considerate dagli addetti ai lavori le “tasse da pagare” per erogare determinati servizi in contesti di larga scala: per le VM la tassa è l’hypervisor, per i Container la tassa potrebbe essere considerata il Control Plane di Kubernetes.

Terminata questa lunga premessa, arriviamo alla notizia che raccontiamo oggi a proposito di Multikernel Technologies, un’azienda che ha nel suo nome una dichiarazione di intenti e nel suo claim una frase che risponde ai dubbi di cui sopra: “Your Cloud. Your Hardware. No Virtualization Tax.“.

La struttura della soluzione proposta, descritta tra gli altri da Phoronix, si basa su mklinux, una tecnologia che rende il Kernel di sistema in grado di avviare altre istanze del Kernel Linux. Secondo gli schemi precedenti, il funzionamento di mklinux si riassume così:

+---------------------+
|   App    |   App    |
+----------+----------+
| Linux K. | Linux K. |
+---------------------+
|     Linux Kernel    |
+---------------------+
|      Hardware       |
+---------------------+

Tornando al claim, il progetto sostiene che questa architettura permetta di eliminare alcuni costi tipici, o tasse come scrivevamo poco sopra, della virtualizzazione: niente emulazione dei dispositivi (le istanze ricevono direttamente dispositivi fisici assegnati) e niente secondo livello di page table.

Questo impatta (positivamente) sulle performance: le prime misurazioni pubblicate riportano miglioramenti rispetto a KVM che variano, a seconda del workload, da circa 1,07× a 2,5×, stando a quanto indicato dai test di Phoronix.

Vale la pena sottolineare come non si sia di fronte a VM più veloci, ma ad un modello di isolamento completamente diverso, che forse ci si può azzardare a definire il punto di incontro tra le VM e i Container.

Un nuovo livello quindi, che si aggiunge agli esistenti e che al momento non è ancora nella mainline del Kernel e quindi, richiede un certo grado di pratica per essere anche solo testato. Come suggerisce il nome della release pubblicata, v7.0-mk2, il patch set che è stato creato si applica alla versione 7.0 del Kernel Linux, pertanto per testare il tutto andrà usata proprio la versione 7.0 del Kernel comprensiva di tutte le patch pubblicata da Multikernel Technologies.

Siamo di fronte alla terza grande rivoluzione nella gestione dell’hardware? È tutto da dimostrare, ma i presupposti del progetto sono buoni. Se questo rimarrà di nicchia o meno lo scopriremo con il tempo.