La virtualizzazione per il networking

Scegliere il modello di software più adatto
Per supportare l’architettura hardware per un progetto di networking basato sul multicore, occorre trovare il modello di architettura di elaborazione software più adatto per le diverse applicazioni presenti sul mercato delle telecomunicazioni, tenendo presente i modelli di elaborazione generali sopra descritti. I tre grandi modelli software da esaminare sono l’Smp (Symmetric Multiprocessing), l’Amp (Asymmetric Multiprocessing) e il multicore ibrido.

Symmetric Multiprocessing
Assegnare risorse in un progetto multicore può risultare difficile, soprattutto quando più componenti software non sanno come altri componenti utilizzano tali risorse. L’Smp  risolve il problema facendo girare un solo OS su tutti i core del chip. Conoscendo bene tutti gli elementi del sistema, l’OS è in grado di assegnare le risorse a core multipli, prescindendo dall’intervento del progettista dell’applicazione. Facendo girare un solo OS, l’Smp può assegnare in modo dinamico le risorse a determinate applicazioni piuttosto che ai core delle Cpu, migliorando l’utilizzo dell’hardware disponibile. Inoltre i tool di tracing di sistema possono raccogliere statistiche operative e interazioni applicative per il chip multicore nel suo complesso, consentendo ai progettisti di capire come ottimizzare le applicazioni ed eseguire il relativo debug. Se utilizzato correttamente, l’OS abilitato all’Smp offre questi vantaggi senza costringere il progettista a usare Api o linguaggi di programmazione specializzati. Ma nella realtà l’Smp lavora meglio su modelli di elaborazione puramente ‘Cpu/execution-bound’. Ogni volta che il minimo comportamento I/O-bound si inserisce in un’applicazione, le prestazioni effettive dell’Smp crollano. I ritardi I/O tendono a distruggere l’ipotetico boost lineare delle prestazioni Smp tra più core. In pratica il modello Smp non è molto flessibile oltre i quattro core, tranne che con le pure applicazioni ’processing-intensive’.

• IPC tra core nell’Smp - Dato che un solo OS controlla tutti i core di un sistema Smp, tutta la IPC (Inter-Process Communication) tra core è considerata locale. Si ottiene così un netto miglioramento delle prestazioni perché il sistema non ha bisogno di un protocollo IPC speciale per garantire la comunicazione tra applicazioni che girano su core diversi. Tuttavia un OS che supporta la IPC continua per la comunicazione sia tra OS (sul dispositivo multicore) che esterna (verso altri domini e processori) è un’ottima soluzione.

• Allocazione delle risorse nell’Smp - In un sistema Smp tutte le risorse, inclusa la memoria, vengono condivise e gestite dall’OS. Ma se le applicazioni utilizzano un modello di accesso a una memoria condivisa, per definizione devono esistere misure di protezione integrate, atte a garantire che le diverse parti dell’applicazione non possano accedere contemporaneamente a tali risorse condivise. Questo è il problema principale alla radice di ciò che viene definito ‘problema di concorrenza’ nel multicore. Le applicazioni il cui progetto fa molto assegnamento su modelli di elaborazione a memoria condivisa avranno sicuramente grossi problemi di concorrenza da affrontare creando diversi meccanismi di bloccaggio. Tali meccanismi contribuiscono a una riduzione generale dell’utilizzo massimo della Cpu tra più core di esecuzione paralleli. Come spiegato più avanti, un modello a trasferimento di messaggi per il coordinamento e la sincronizzazione processo/thread eviterà la maggior parte di questi problemi di concorrenza.

Asymmetric Multiprocessing (Amp)
L’Amp offre un ambiente di esecuzione simile a quello dei sistemi monoprocessore tradizionali che la maggior parte dei progettisti conosce e comprende. Di conseguenza offre un percorso relativamente diretto per il porting del legacy code, oltre a un meccanismo diretto per controllare in che modo viene usata ogni Cpu e, nella maggior parte dei casi, consente ai progettisti di lavorare con tool e tecniche di debug standard. L’Amp può essere omogeneo, dove ogni core usa lo stesso tipo e la stessa versione di OS, o eterogeneo, dove ogni core usa un OS diverso o una versione diversa dello stesso OS. In generale il modello Amp lavora meglio per l’elaborazione I/O-bound perchè può adattarsi meglio a più core se le velocità di I/O sono uniformi e quantificabili. In caso contrario, una sorta di meccanismo di bilanciamento è necessario o almeno consigliabile. Se utilizzato correttamente il modello Amp consente alle applicazioni che girano su un core solo di comunicare in modo trasparente con applicazioni e servizi di sistema su altri core, ma senza l’elevato uso della Cpu imposto dalle forme tradizionali di comunicazione tra processi.

• IPC tra core nell’Amp - Usando più istanziazioni dell’OS, normalmente l’Amp necessita di una infrastruttura di networking completa per supportare la comunicazione tra applicazioni che girano su core diversi. Per implementare il livello più basso di trasferimento di buffer, un sistema Amp può usare periferiche di I/O come una porta Ethernet assegnata ad ogni processore/core, uno schema a memoria condivisa/interrupt-based o speciali motori di accelerazione messaggi tra core basati su HW, in base alle risorse hardware del sistema.
Ma il modello IPC migliore è quello che supporta continuamente la comunicazione tra processi/thread sullo stesso core/dominio OS, la comunicazione tra core in un dispositivo multicore e la comunicazione tra dispositivi con altre Cpu nel sistema collegato in rete. Il che significa che, a prescindere dalla posizione, le applicazioni possono comunicare direttamente con altre applicazioni nelle rete connessa e non solo con il dispositivo intra-multicore.

• Allocazione delle risorse nell’Amp - Con l’Amp il progettista può decidere come suddividere tra i core le risorse hardware condivise usate dalle applicazioni. Normalmente l’allocazione delle risorse avviene staticamente durante l’avvio e include l’allocazione della memoria fisica, l’uso delle periferiche e la gestione degli interrupt. Mentre il sistema potrebbe allocare o accedere alle risorse in modo dinamico, questo comporta un complesso coordinamento tra i core. In ambito Amp il problema della ‘concorrenza’, comune nei sistemi Smp, non esiste in una sola applicazione. Il problema si presenta solo in caso di memoria condivisa o risorse tra applicazioni indipendenti multiple su core diversi.In un sistema Amp si programma sempre un processo da eseguire sullo stesso core, anche quando quel core ha un uso massimo della Cpu e altri core sono inattivi. Così uno o più core finiscono per essere utilizzati troppo o troppo poco. Per risolvere il problema, il sistema potrebbe consentire alle applicazioni di migrare dinamicamente da un core all’altro.

Modelli multicore ibridi
Secondo un nuovo interessante modello, un dispositivo multicore omogeneo presenta più di due core. E se i core potessero essere segmentati tra un modello Smp e un modello Amp? I vantaggi sono evidenti: le applicazioni più adatte per l’Smp possono operare insieme ad applicazioni più adatte per l’Amp, nello stesso unico dispositivo che potrebbe andare a sostituire un intero sistema multiprocessore, con conseguente riduzione del numero di componenti da utilizzare e del consumo energetico, aumento della dissipazione di calore e  prestazioni uguali o migliori. Si tratta di un concetto potente che il settore sta attualmente esaminando. Ma questo caso ibrido presenta diverse ramificazioni in un’implementazione multicore reale, per cui le soluzioni precedenti il multicore erano spesso costituite da classici sistemi con più Cpu o più schede, ognuno con proprie esigenze e proprie soluzioni di elaborazione. Questi gli aspetti principali:
- una soluzione multicore deve supportare sia i modelli Smp che i modelli Amp;
- una soluzione multicore deve richiedere poche o nessuna modifica delle applicazioni esistenti consolidate;
- una soluzione multicore deve supportare più sistemi operativi per poter gestire una combinazione di ambienti operativi per il piano di controllo e il piano dati; ma non è sempre così per determinate implementazioni;
- una soluzione multicore deve supportare un certo livello di condivisione di dispositivi, risorse e servizi fra tutti i core;
- una soluzione multicore deve avere una funzione di localizzazione guasti per un solo core o un insieme di core;
- una soluzione multicore deve supportare un ambiente di tool integrato per il debug del codice del software, oltre che per l’analisi e la visualizzazione delle prestazioni del sistema.

Scegliere l’infrastruttura OS adatta
E se ci fosse una sola infrastruttura OS in grado di soddisfare sia i requisiti dell’Smp che quelli dell’Amp in un dispositivo multicore? In tal caso qualsiasi applicazione potrebbe essere configurata con le sue migliori caratteristiche di elaborazione in un dispositivo multicore e operare con lo stesso profilo prestazionale della sua precedente implementazione. Una infrastruttura di questo tipo esiste già ed è prodotta da Enea. Un unico ambiente OS in grado di supportare tutti i modelli di elaborazione necessari offre diversi vantaggi, soprattutto in termini di prestazioni. Ma che dire dello scenario in cui sono necessari sistemi operativi eterogenei a causa dell’esistenza di un determinato sistema in un dispositivo multicore? In un caso come questo entra in gioco un’infrastruttura di virtualizzazione. La virtualizzazione è una tecnica usata per creare un ambiente di esecuzione per un software simile a quello per cui era stato progettato in origine, ma con un hardware o un sistema operativo diverso. La virtualizzazione si può ottenere a due livelli: sistema operativo e hardware. La virtualizzazione dell’hardware non viene trattata in questo articolo. Invece la virtualizzazione del software, specificamente in forma di hypervisor multicore, viene affrontata in questa sede perché riguarda in particolare i sistemi operativi o gli ambienti di esecuzione. Ciò che differenzia un sistema operativo di tipo ‘stand-alone’ da una versione virtualizzata è il fatto che l’OS virtualizzato opera in una modalità meno privilegiata (modalità utente), il che si rende necessario perché la macchina virtuale che fornisce l’architettura virtualizzata è l’unica entità che opera al massimo livello privilegiato (modalità supervisore).