Architettura LAMP per sistemi cloud DIME-aware

Introduzione 
1 
 
 
Introduzione 
 
Da decenni la legge di Moore ha correttamente anticipato la crescita esponenziale del 
numero di transistor e delle prestazioni dei processori. Nonostante tale incremento, 
nuove esigenze portano a richiedere più potenza di calcolo rispetto a quella che un 
processore singolo può fornire. Di conseguenza, i sistemi multiprocessore e i sistemi 
multi-core si sono sviluppati e diffusi in molti settori di elaborazione. 
Ad esempio, Mozilla ha recentemente annunciato di voler trovare un modo per 
realizzare un’interfaccia DOM (Document Object Model) multi-threaded per Firefox, in 
modo tale che una singola pagina web possa essere renderizzata sfruttando i diversi 
core dei processori [1].  
Tuttavia, le problematiche di progettazione dei sistemi multi-core non si limitano solo 
alla scelta di particolari architetture o strategie di comunicazione hardware, ma 
coinvolgono anche la progettazione del software, la quale deve fornire nuovi 
paradigmi di design che siano capaci di sfruttare a pieno le capacità e la potenza di tali 
sistemi. Allo scopo di far fronte ai problemi di scalabilità e per utilizzare propriamente 
le tecnologie multi-core, la prossima generazione delle architetture di servizi dovrà 
emulare la flessibilità architetturale degli organismi cellulari, i quali sono tolleranti ai 
fault e implementano strutture e comandi di controllo che rendono possibile 
l’esecuzione delle proprietà di self-configuring, self-monitoring, self-protecting, self-
healing e self-optimizing (in breve self-*). 
Pertanto, nella progettazione di un sistema che offre dei servizi di qualsiasi tipo, 
bisogna garantire almeno le proprietà di flessibilità, efficienza e scalabilità [2]. La 
flessibilità è misurata in termini di tolleranza del servizio ai fault, fluttuazioni nella 
contesa delle risorse, minacce alla sicurezza e cambiamento delle priorità di business;
Introduzione 
2 
 
quanto detto è riassumibile in termini di dependability, cioè la capacità di erogare un 
servizio trustable (degno di fiducia) in modo corretto.  
L’efficienza è misurata in termini di costo totale dei diritti di proprietà e ritorno sugli 
investimenti. Infine, la scalabilità si raggiunge attraverso la gestione delle risorse nel 
rispetto della variabilità del numero degli elementi computazionali richiesti per 
soddisfare i requisiti dei servizi previsti. 
Poiché le soluzioni IT si sono evolute da un modello server-centric a tecnologie grid-
based o cloud-based, la flessibilità, l’efficienza e la scalabilità sono migliorate grazie 
all’automatizzazione del lavoro e alla conoscenza della gestione dei task e delle risorse, 
per gestire i cambiamenti di cui l’applicazione e i suoi servizi necessitano. 
Sfortunatamente, estendere l’attuale stato dell’arte per sviluppare applicazioni che 
sfruttano la piena potenza dei sistemi multi-core è difficile e, soprattutto, richiede 
sviluppatori in grado di adattarsi a nuovi paradigmi di programmazione, adatti per i 
sistemi paralleli. Ma, in realtà, il problema dello sfruttamento della potenza dei sistemi 
multi-core non si limita solo alla preparazione degli sviluppatori; per ottenere il 
comportamento richiesto da una certa applicazione, l’accesso ai dati deve essere 
coordinato tra tutti i core, attraverso delle tecniche di sincronizzazione e applicando 
politiche opportune per garantire tutti i goal del sistema. Ne segue, quindi, che la 
maggior parte delle tecniche attuali di computing e le strategie di progettazione dei  
sistemi operativi devono essere riesaminate affinché sfruttino a pieno il parallelismo 
offerto dalla molteplicità dei core.  
In aggiunta, i moderni approcci per la gestione delle risorse non sono sensibili alla 
natura distribuita delle transazioni e alla contesa delle risorse condivise distribuite; 
essi, nel migliore dei casi, fanno capo a tecniche complesse e coinvolgono molti livelli 
software di management, impedendo anche una corretta gestione degli errori. 
Confrontando le macchine agli organismi viventi, von Neumann affermò che le prime 
non sono fault tolerant come i secondi [2]. Egli, infatti, sosteneva che “It’s very likely 
that on the basis of philosophy that every error has to be caught, explained, and 
corrected, a system of the complexity of the living organism would not run for a 
millisecond”.
Introduzione 
3 
 
Gli organismi sono riusciti ad incapsulare le regole per costruire e gestire un sistema 
complesso in modo semplice; sono anche riusciti a inventare dei meccanismi di 
replicazione, riparazione, ricombinazione e adattamento, con lo scopo di eseguire tali 
regole in maniera precisa. 
Dall’analogia con la struttura degli organismi cellulari è possibile delineare un nuovo 
modello computazionale, definibile come una macchina di Turing managed, che 
supporta delle funzionalità di segnalazione: tale modello è stato battezzato DIME, cioè 
Distributed Intelligent Managed Element. Questo modello permette l’incapsulamento 
di un server virtuale in un elemento computazionale che si autogestisce (è self-
managed) e collabora con una rete di altri elementi dello stesso tipo per eseguire un 
workflow implementato come un insieme di task, organizzati in un DAG. 
Alla luce di quanto detto, l’obiettivo della tesi è stato la dimostrazione della flessibilità, 
dell’efficienza e della scalabilità del modello DIME in un sistema operativo 
convenzionale (Linux), iniettando un middleware non basato sul modello di von 
Neumann, con lo scopo di introdurre le funzioni di self management (FCAPS) e un 
livello di segnalazione indipendente da quello di esecuzione. È stata scelta 
l’architettura LAMP per dimostrare la gestione delle transazioni end-to-end, basandosi 
sulle priorità di business, le fluttuazioni del workload, i failure dei componenti e i 
vincoli di latenza.  
Lo scenario che è stato oggetto di studio della tesi è di tipo cloud, un modello di 
servizio che si sta diffondendo con grande rapidità tra imprese e pubbliche 
amministrazioni, poiché incoraggia un utilizzo flessibile delle proprie risorse o di quelle 
messe a disposizione da un fornitore di servizi specializzato.  
Mi preme sottolineare che il lavoro di tirocinio, conclusosi con la realizzazione della 
tesi, è stato realizzato proficuamente in collaborazione con Kawa Objects Inc. [21], 
azienda impegnata nella definizione del modello DIME e nella sua implementazione 
mediante diversi use-case.   
Nel corso della tesi verranno più volte sottolineati i concetti di auto-scaling e self-
repair delle risorse computazionali, il performance management, la sicurezza delle 
transazioni end-to-end e il live migration dei servizi. Queste proprietà appartengono ad
Introduzione 
4 
 
una rete basata sul modello DIME, la quale offre computing e storage on-demand, 
senza il bisogno di un hypervisor layer, semplificando lo schema di parallelismo e, allo 
stesso tempo, velocizzando le comunicazioni tra i vari componenti. In aggiunta, 
attraverso l’FCAPS management, lo sviluppatore deve concentrarsi solo 
sull’implementazione della parte algoritmica del servizio, senza preoccuparsi dei 
problemi di management: questo incentiva il concetto di separation of concerns. 
Quindi, il modello DIME sfrutta il parallelismo (sfruttando i thread a livello di core o a 
livello di processo), con l’obiettivo di costruire un livello di management al di sopra di 
una rete di nodi computazionali basati sul modello SPC di von Neumann, garantendo 
un’orchestrazione semplice dei servizi di rete, con l’obiettivo di monitorare, controllare 
e ottimizzare  dinamicamente l’esecuzione dei workflow.  
La tesi è articolata in 4 capitoli. Il capitolo 1 discute i modelli delle architetture 
parallele, le problematiche tipiche nella progettazione dei sistemi distribuiti, il modello 
di von Neumann e le problematiche per lo sviluppo di una macchina che si possa auto-
replicare e auto-gestire, in forte analogia con gli organismi cellulari. In seguito, il 
capitolo approfondisce l’architettura e il modello DIME, evidenziandone i settori 
applicativi e le modalità di utilizzo per fornire servizi scalabili con alto grado di 
affidabilità e performance. 
Il capitolo 2 descrive come sia possibile integrare il modello DIME all’interno 
dell’architettura LAMP e come sia possibile gestire l’interazione tra questi all’interno di 
uno scenario cloud, mettendo in luce i vantaggi di questo nuovo approccio.  
Il capitolo 3 analizza e descrive i risultati ottenuti valutando alcuni scenari di rete e 
focalizzando l’attenzione sui vantaggi che una politica di load balancing potrebbe 
apportare in uno scenario cloud. Infine, il capitolo 4 conclude il lavoro con alcune 
analisi e prospettive future.
Capitolo 1 – Architetture parallele 
5 
 
 
1 Architetture parallele 
 
Negli anni passati l’industria dei microprocessori general-purpose si è pesantemente 
sviluppata grazie alla maggiore capacità di integrazione, confermata dalla ben nota 
legge di Moore. Questo comportò un rapido sviluppo di architetture di processori 
single-thread, in grado di svolgere più funzionalità grazie all’integrazione di queste 
all’interno dello stesso chip o dello stesso package. Tuttavia, il guadagno in termini di 
performance non era gratis, poiché la progettazione di tali sistemi doveva risolvere 
nuove problematiche nate paradossalmente con l’evoluzione della tecnologia, quali il 
consumo di potenza (potenza di leakage o potenza statica, cioè la potenza dissipata dal 
transistor quando questo non commuta) o il ritardo di propagazione del segnale sul 
bus; si parla quindi di effetti sub-micron poiché la loro causa è dovuta all’aumento 
della capacità di integrazione, ormai basata su tecnologie dell’ordine dei nanometri. 
Per cui, dall’esigenza di ottimizzare nuovi parametri e risolvere nuovi problemi, 
l’obiettivo diventò cercare delle soluzioni architetturali per sfruttare la crescente 
capacità di integrazione [3]. 
Una di queste soluzioni è rappresentata dal superamento delle architetture single-core 
con architetture multi-core, le quali supportano l’integrazione di più core all’interno 
del chip di una CPU. Questo approccio migliorò le capacità di elaborazione dei singoli 
thread e si diffuse rapidamente coprendo diverse fette di mercato, dai laptop ai super-
computer. 
Le architetture dei moderni processori hanno il supporto per la virtualizzazione a livello 
hardware; Intel e AMD hanno aggiunto ai loro ISA un insieme d’istruzioni per rendere 
molto semplice la virtualizzazione su architetture x86. AMD ha introdotto AMD-V, che 
era conosciuta all’inizio come Pacifica, mentre le estensioni offerte da Intel sono
Capitolo 1 – Architetture parallele 
6 
 
conosciute come Intel Virtualization Technology (o IVT). L’idea che sta dietro questo 
approccio è quello di estendere l’ISA in modo da creare un livello di privilegio che si 
trova al di sotto del dominio privilegiato. Questo tipo di approccio ha il vantaggio 
fondamentale di non dover modificare il sistema operativo ospite; invece, il relativo 
svantaggio è la poca portabilità di questo metodo. Infatti le implementazioni a 
supporto della full virtualization sono legate all’ISA del processore che si utilizza [4]. 
Tuttavia, le problematiche di progettazione dei sistemi multi-core non si limitano solo 
alla scelta di particolari architetture o strategie di comunicazione hardware, ma 
coinvolgono anche la progettazione del software, la quale deve fornire nuovi 
paradigmi di design che siano capaci di sfruttare a pieno le capacità e la potenza di tali 
sistemi. A tal proposito, le prospettive generali in tale direzione sono  alquanto 
pessimistiche; come afferma David Patterson, “la capacità di trarre il vero vantaggio 
dall’utilizzo delle architetture multi-core è limitata dalla nostra incapacità di capire 
come rendere affidabile il software parallelo quando il numero di core aumenta” [5]. 
 
1.1 Architetture multi-core 
 
L’industria del computing è caratterizzata dalla ricerca di prestazioni sempre crescenti 
ed efficienti, dalle applicazioni di fascia alta nei settori delle reti, telecomunicazioni e 
avionica, ai sistemi embedded a basso consumo. Nonostante il costante incremento 
delle frequenze di clock, la velocità dei circuiti non può aumentare indefinitamente. La 
velocità della luce costituisce oggi un limite pratico per i progettisti dei calcolatori di 
fascia alta e le prospettive di riuscire a far muovere gli elettroni e i fotoni ancora più 
velocemente sono scarse. I problemi di dissipazione termica necessitano di sistemi di 
condizionamento sempre più sofisticati. Infine, le dimensioni delle lunghezze di canale 
dei transistor non potranno diminuire all’infinito, ma raggiungeranno presto il punto in 
cui conterranno così pochi atomi tali da generare effetti quantistici non più trascurabili 
[5]. Pertanto, il percorso di sviluppo dei sistemi di calcolo porta chiaramente verso i 
sistemi multi-core. Al contrario delle architetture server-centric, in cui la risorsa CPU è 
condivisa da più task, le architetture multi-core promuovono un’architettura dotata di
Capitolo 1 – Architetture parallele 
7 
 
più CPU, in cui ogni CPU è formata da più thread  in grado di eseguire diversi task in 
parallelo. Dunque, il calcolo parallelo, nella sua forma più semplice, rappresenta 
l’impiego simultaneo di risorse di calcolo multiple per risolvere un problema di 
elaborazione, in modo da poter essere eseguito su più CPU, spezzando un problema in 
parti discrete elaborabili contemporaneamente, dove ciascuna viene ulteriormente 
suddivisa in una serie di istruzioni che possono essere eseguite in modo seriale su 
differenti CPU.  Per poter essere eseguito in modo parallelo, il problema di calcolo 
deve avere le seguenti caratteristiche: essere scomponibile in parti risolvibili 
simultaneamente ed eseguire istruzioni di programma multiple in qualsiasi momento. 
Il calcolo parallelo è inoltre un’evoluzione del calcolo seriale che tenta di emulare ciò 
che spesso avviene nel mondo naturale. Infatti, come dimostrato anche dalla natura, la 
capacità di lavorare in parallelo attraverso la formazione di un gruppo è un modo 
efficiente per raggiungere un obiettivo comune; basti pensare agli esseri umani, i quali 
hanno imparato ad organizzarsi in un’architettura sociale in cui ogni partecipante ha 
delle capacità limitate, ma un insieme o un gruppo di essi riesce a svolgere delle 
attività per il raggiungimento di un obiettivo che un singolo non sarebbe in grado di 
raggiungere. Pertanto, i diversi individui operano in gruppo creando delle reti 
intelligenti, poiché essi realizzano un obiettivo attraverso modalità differenti, 
collezionando informazioni dal mondo esterno e usandole per controllare l’ambiente 
circostante. Quindi, le human-networks sono formate da un gruppo di individui che 
operano come un sistema in cui [7]: 
 ogni sistema ha uno scopo all’interno di un sistema più ampio. 
 Tutte le parti del sistema devono essere presenti e devono essere disposte in 
modo corretto affinché il sistema svolga le sue funzioni in modo ottimale 
(separation of concern). 
 I sistemi cambiano in merito ai feedback, ovvero collezionano informazioni, le 
analizzano e controllano l’ambiente utilizzando delle risorse speciali. 
 I sistemi mantengono la loro stabilità attraverso l’elaborazione di segnali di 
feedback.
Capitolo 1 – Architetture parallele 
8 
 
La società stabilisce degli obiettivi, divide i compiti in attività separate che verranno 
eseguite da individui differenti con ruoli diversi ed, infine, connette e coordina tali 
individui per raggiungere l’obiettivo previsto. 
Un requisito fondamentale che si vuole in ogni tipologia di rete, sia sociale che di 
computer, è la scalabilità. In tal caso, essa si può garantire attraverso la segmentazione 
gerarchica e la specializzazione delle attività. Tuttavia, c’è sempre un bilanciamento tra 
il costo di coordinamento degli individui e la dimensione della rete sociale. Se il 
numero di individui cresce, l’efficienza dell’organizzazione viene mantenuta attraverso 
la specializzazione delle attività: in altre parole, l’agilità e la scalabilità di una società 
dipendono dalla sua capacità di rispondere velocemente ad eventuali cambiamenti 
richiesti per raggiungere un obiettivo, attraverso la riconfigurazione dell’intera rete. Le 
caratteristiche di specializzazione e segmentazione delle reti umane, la coordinazione 
distribuita e l’abilità di adattarsi tempestivamente a nuovi scenari si riferiscono ad un 
modello che, se emulato nelle reti di CPU, può essere molto utile per migliorare le 
performance in termini di robustezza, availability, reliability e security. Al fine di 
supportare queste caratteristiche, si definisce FCAPS un sistema capace di gestire gli 
aspetti di fault, configurazione, accounting, performance e sicurezza di tutti gli 
elementi di una rete: ciò garantisce lo sviluppo di un sistema altamente affidabile ed 
efficiente. Il Telecommunications Management Network (TMN) definisce framework 
FCAPS un sistema che svolge le seguenti funzionalità [7]: 
 Fault Management: gestisce il rilevamento di un fault nei dispositivi di rete, 
isolando i fault e attivando delle procedure di ripristino. 
 Configuration Management: gestisce le modifiche, la configurazione, 
l’installazione e la distribuzione del software a tutti i dispositivi di rete. 
 Accounting Management: gestisce le funzioni di utilizzo delle risorse di rete 
collezionando delle informazioni di account. 
 Performance Management: fornisce delle funzioni di monitoraggio della rete 
per garantire determinati requisiti di QoS. 
 Security Management: fornisce un accesso controllato alle risorse di rete.
Capitolo 1 – Architetture parallele 
9 
 
Le organizzazioni gerarchiche sono progettate secondo queste proprietà per 
migliorarne l’efficienza e per garantire il raggiungimento di determinati obiettivi 
attraverso l’uso dell’FCAPS management e la segnalazione di eventi (o signaling). 
 
1.1.1 Livelli  di parallelismo 
 
L’implementazione di un sistema che possa lavorare in parallelo in un ambiente di 
calcolo in cui l’ordine deve essere mantenuto a tutti i costi pone alcuni problemi, 
derivanti dal fatto che la soluzione non può essere realizzata solo in hardware, 
attraverso implementazioni a livello di compilatore o di sistema operativo, anche 
perché in queste aree la parallelizzazione è già stata implementata da tempo. Il 
parallelismo può essere pensato a vari livelli, ovvero a livello di bit, di istruzione, di task 
e di dato [6]. Il parallelismo a livello di bit estende l’architettura hardware per operare 
simultaneamente su dati più grandi; per esempio, se un core a 8-bit deve elaborare un 
oggetto a 16 bit, richiede due istruzioni. Il parallelismo a livello di istruzione è una 
tecnica che identifica le istruzioni che non dipendono l’una dall’altra, in quanto, ad 
esempio, lavorano su dati differenti. Questa tecnica, solitamente implementata 
tramite il compilatore, non sempre è di semplice attuazione e la sua possibilità di 
realizzazione dipende dal tipo di applicazione (ad esempio, è applicabile nel digital 
signal processing). Il parallelismo a livello di task prevede la distribuzione di differenti 
applicazioni, processi o thread in diverse unità di elaborazione; la difficoltà di 
implementazione non risiede tanto nella modalità di distribuzione dei thread, ma nel 
capire come dividere l’applicazione in thread multipli. Infine, il parallelismo a livello di 
dato è collegato ad una classificazione del calcolo parallelo tramite la tassonomia di 
Flynn, che raggruppa le architetture di calcolo multiprocessore in funzione delle 
dimensioni istruzioni/dati e degli stati singolo/multiplo [8]. I sistemi SISD (Single 
Instruction Single Data) sono i calcolatori seriali e comprendono la maggior parte dei 
PC e workstation a CPU singola; all’estremo opposto si trova l’approccio di tipo MIMD 
(Multiple Instruction Multiple Data), dove ogni processore può lavorare in parallelo su 
flussi dati differenti, con esecuzione sincrona o asincrona. L’approccio SIMD (Single
Capitolo 1 – Architetture parallele 
10 
 
Instruction Multiple Data) prevede l’elaborazione di dati in modo simultaneo da parte 
di unità di calcolo multiple e viene usato in sistemi embedded commerciali, come ad 
esempio quelli di Freescale. Infine, la casistica MISD è stata utilizzata per lo più in 
passato, in poche applicazioni di super-computing estremamente specializzate o 
addirittura solo in applicazioni sperimentali. 
 
1.2 Sistemi federati e problematiche dei sistemi distribuiti 
 
Un sistema federato è formato da un gruppo di componenti che collaborano per il 
raggiungimento di un obiettivo comune. Le aziende usano i sistemi federati per 
collaborare ed eseguire processi di business basati sull’utilizzo di risorse distribuite che 
appartengono a diversi owner. Un modello di business federato mantiene un livello di 
fiducia tra i partecipanti; la fiducia fornita dal processo di business è spesso intesa in 
termini di accordo sui requisiti di availability, performance, security e costo. Pertanto, i 
sistemi federati sono delle reti di computazione distribuita, le cui risorse sono 
condivise per eseguire processi di business per la realizzazione di un obiettivo comune. 
Tuttavia, questo scenario pone dei problemi tipici dei sistemi distribuiti, quali la 
condivisione e l’accesso a risorse condivise, il problema della fiducia (o trust), l’impatto 
della latenza di comunicazione tra i partecipanti e la gestione della sincronizzazione tra 
processi distribuiti [9].  
Pertanto, si possono delineare quattro principali problemi nella progettazione di un 
sistema distribuito: 
1. Connection Management. Gestisce i meccanismi per l’accesso alle risorse 
condivise, in modo tale che esso sia consistente e ordinato. In aggiunta, per un 
corretto ed efficiente utilizzo dei servizi di rete, devono essere garantite anche 
le proprietà di reliability, availability, performance, security ed accounting: 
queste proprietà sono meglio conosciute con l’acronimo FCAPS. Quindi, il 
Connection Management definisce i meccanismi per l’allocazione delle risorse 
agli utenti autorizzati in base alle loro priorità di business, i requisiti di workload 
e i vincoli di latenza.
Capitolo 1 – Architetture parallele 
11 
 
2. Trasparenza. Le risorse di un sistema distribuito potrebbero essere fisicamente 
dislocate in differenti container e i componenti potrebbero essere 
geograficamente separati. Un qualsiasi sistema distribuito dovrebbe 
nascondere agli utenti e ai programmatori come i processi e le risorse sono 
fisicamente distribuite in rete. Quindi la trasparenza deve essere intesa in 
termini di: 
 Accesso: nascondere le differenze nella rappresentazione dei dati e 
nella modalità di accesso alle risorse. 
 Locazione: nascondere dove una risorsa è collocata fisicamente 
(l’accesso prescinde dalla conoscenza della locazione dell’oggetto). 
 Migrazione: una risorsa si può spostare da una locazione all’altra 
senza inficiare le operazioni degli utenti/programmi. 
 Rilocazione: possibilità di rilocare una risorsa mentre è in uso da 
parte di un utente. 
 Replicazione: nascondere che esistono più copie della stessa risorsa. 
 Concorrenza: gestione dell’accesso di più utenti/processi alla stessa 
risorsa condivisa. 
 Failure: un utente non si accorge che una risorsa non sta funzionando 
propriamente e che il sistema sta risolvendo il malfunzionamento. 
 Scalabilità: le componenti coinvolte dal sistema possono aumentare 
o diminuire senza che la struttura del sistema o gli algoritmi 
applicativi cambino. 
 Performance: le capacità adattative del sistema gli permettono di 
essere riconfigurato per migliorare le performance al variare del 
carico. 
3. Openness. Offre la capacità di estendere e migliorare i sistemi distribuiti in 
quanto i servizi sono progettati in modo tale che l’accesso a questi non dipenda 
da come il servizio sia stato implementato. Secondo tale filosofia, ogni servizio 
deve definire un’interfaccia standard di accesso dall’esterno. Questa proprietà 
accresce l’interoperabilità tra servizi e processi distribuiti.
Capitolo 1 – Architetture parallele 
12 
 
4. Scalabilità. Il workload e i vincoli di latenza cambiano, pertanto i sistemi 
distribuiti devono tenere in considerazione tali fluttuazioni. La scalabilità è un 
concetto complesso, che abbraccia la composizione, la decomposizione, la 
migrazione e l’amministrazione di risorse distribuite. 
Le attuali best-practice dei modelli computazionali distribuiti si basano sull’architettura 
server-centric di von Neumann, ovvero lo Stored Program Control (SPC), la quale si è 
evoluta nel corso delle recenti decadi. Nella sua forma più semplice, la computazione e 
la memorizzazione sono separati usando rispettivamente i dispositivi CPU e memoria. 
Una singola struttura di memorizzazione (o storage) detiene sia l’insieme delle 
istruzioni necessarie per gestire la computazione, sia i dati generati e utilizzati dal 
flusso di esecuzione: la separazione della memoria dall’unità di processamento è 
implicita in questo modello. Oggi, il modello SPC di von Neumann è abbastanza diverso 
dall’architettura di von Neumann relativa ai sistemi self-replicating (von Neumann, 
1966). Il problema della replicazione del codice non autorizzato può essere risolto 
attraverso l’uso di meccanismi per la protezione della memoria ed, in particolare, 
attraverso le architetture di memoria virtuali che sono state incorporate nei sistemi 
operativi per gestire le risorse computazionali e di storage. Durante le ultime cinque 
decadi, sono stati introdotti molti livelli di astrazione software per mappare 
l’esecuzione di workflow complessi in una sequenza di uno e zeri; queste tecnologie 
prevedono la definizione di linguaggi di programmazione, file system, database, 
sistemi operativi ecc. Mentre ciò ha portato all’automazione di molti processi di 
business, il modello computazionale rimaneva centralizzato e relativo a mainframe o 
mini-computer. La computazione distribuita che utilizzava le risorse di rete, quali 
elementi SPC e risorse di storage, si realizzò negli anni ‘70, iniziando dal modello client-
server fino ai modelli attualmente noti come grid-computing e cloud-computing, in cui 
centinaia di server fisici e virtuali forniscono capacità di esecuzione e orchestrazione 
distribuita dei flussi computazionali [9]. 
La condivisione delle risorse computazionali distribuite ha migliorato le modalità di 
comunicazione, di collaborazione e di commercio su internet e, di conseguenza, ha 
reso possibile l’aumento del numero dei servizi accessibili dalla rete. Questa crescita
Capitolo 1 – Architetture parallele 
13 
 
esponenziale dei servizi nel mercato di consumo ha introdotto vincoli abbastanza rigidi 
nelle attuali infrastrutture IT. Grazie ad Internet si è venuto a creare un tessuto di 
connessioni globali che collega tra loro milioni di reti, grandi e piccole, centinaia di 
milioni di PC ed un numero crescente di altri apparecchi come i telefoni mobili. Tutto 
ciò ha determinato una significativa riduzione dei costi di accesso ad informazioni, 
spesso preziose per i pirati informatici. Pertanto le preoccupazioni in materia di 
sicurezza delle reti informatiche e dei sistemi di informazione sono aumentate 
parallelamente al rapido incremento del numero di utenti e del valore delle transazioni 
effettuate sulle reti stesse. La sicurezza ha assunto un’importanza critica tale da farne 
un presupposto indispensabile per la crescita delle imprese di commercio e per il 
funzionamento dell’economia nel suo complesso. La perdita di fiducia è un problema 
fondamentale nella progettazione dei sistemi distribuiti, legata alla perdita di capacità 
di recupero dopo un failure operazionale.  
Il principio base del trattamento dei malfunzionamenti in natura è quello di 
minimizzare i loro effetti e applicare delle strategie correttive per il ripristino del 
normale funzionamento quando necessario [9]. Trattando lo stesso problema 
nell’ambito degli automi artificiali, è invece richiesta una diagnosi immediata; infatti, 
confrontando le macchine con gli esseri viventi, von Neumann affermava che gli 
automi artificiali non sono fault tolerant come gli organismi viventi. Tuttavia, il modello 
che si propone nel corso del capitolo gestisce il trattamento degli errori nel modo più 
tempestivo possibile, sia per quanto riguarda la rilevazione sia la correzione degli 
stessi.  
Non è certo un’esagerazione pensare che oggi le comunicazioni, le collaborazioni e il 
commercio on-line hanno drammaticamente alterato sia il consumatore sia le 
economie di business. Ci sono due principali business driver (cioè i principali fattori che 
guidano le scelte strategiche in fatto di sviluppo applicativo) che stanno forzando nuovi 
approcci per la gestione di servizi distribuiti [9]: 
 l’avvicinamento del consumatore ad una nuova generazione di applicazioni 
native su internet, quali Twitter, Facebook e You Tube, sta spingendo al bisogno 
di garantire elevata scalabilità in base alla domanda. I requisiti che si cercano