Evoluzione dei Sistemi Distribuiti: da Flynn al Middleware, Cluster e Grid

1. Introduzione

Nella lezione precedente abbiamo visto cosa sia un sistema distribuito. Ora proviamo a capire come ci siamo arrivati: quali limiti fisici hanno spinto i progettisti hardware a moltiplicare i processori invece di renderli sempre più veloci, come si classificano le architetture parallele che ne sono nate, e come — parallelamente — anche il software ha attraversato una propria evoluzione, dai terminali passivi collegati a un host centrale fino ai sistemi completamente paritetici di oggi.

2. L'evoluzione dell'architettura hardware

Ho preferito partire dal funzionamento generale prima di entrare nei dettagli, perché la classificazione di Flynn che vedremo tra poco ha senso solo se prima si capisce da dove nasce l'esigenza del parallelismo. Per decenni, il modo più naturale per rendere un computer più veloce è stato aumentare la frequenza di clock della sua CPU. Ma questa strada ha un limite fisico ben preciso: più il clock sale, più aumentano il consumo energetico e la dissipazione del calore, fino a un punto in cui non è più sostenibile spingersi oltre. Per continuare a crescere in prestazioni, l'informatica ha dovuto cambiare strategia: invece di un solo processore sempre più veloce, più processori che lavorano insieme, distribuendo il carico computazionale.

È da questo cambio di paradigma che nascono le architetture parallele e distribuite che oggi troviamo ovunque: nei server aziendali, nelle infrastrutture cloud, persino negli smartphone che teniamo in tasca.

3. La classificazione di Flynn

Nel 1972 Michael J. Flynn propose un modo semplice ma efficace per classificare le architetture hardware, osservando due flussi presenti in ogni sistema di calcolo: il flusso delle istruzioni (le operazioni eseguite dalla CPU) e il flusso dei dati (il modo in cui i dati vengono elaborati). Combinando questi due flussi — ciascuno singolo o multiplo — Flynn ottiene quattro categorie, ancora oggi il punto di riferimento concettuale per parlare di parallelismo hardware.

Ho scelto di presentare prima lo schema generale, e solo dopo i singoli casi, perché altrimenti le sigle SISD/SIMD/MISD/MIMD restano solo lettere da memorizzare senza un vero significato.

Matrice di Flynn

4. Cluster computing: calcolo distribuito ad alte prestazioni

Il cluster computing è una forma avanzata di sistema distribuito, in cui più nodi ad alte prestazioni sono interconnessi tramite una rete locale ad alta velocità e progettati per funzionare come un unico sistema di calcolo. I nodi di un cluster sono generalmente omogenei: stesso hardware, stesso sistema operativo, stessa rete. Questo consente elevata potenza computazionale, trasferimenti dati rapidi e gestione centralizzata delle risorse.

Due modelli di cluster

• Modello Beowulf: un nodo principale coordina l'esecuzione dei processi distribuiti sugli altri nodi, tipicamente tramite librerie di comunicazione come MPI.
• Modello Single System Image (es. MOSIX): il cluster appare all'utente come un unico sistema operativo distribuito, con bilanciamento del carico automatico.

5. Grid computing: cooperazione su larga scala

Il grid computing, introdotto a metà degli anni '90, si distingue dal cluster per il suo elevato grado di decentralizzazione ed eterogeneità: i nodi possono avere hardware, sistemi operativi e politiche di sicurezza differenti e appartenere a organizzazioni diverse. L'obiettivo non è solo condividere potenza di calcolo, ma anche storage, software, database e infrastrutture di rete all'interno di organizzazioni virtuali. Con il tempo questo modello si è evoluto verso un'architettura orientata ai servizi, la Open Grid Service Architecture (OGSA), in cui tutte le risorse sono esposte come servizi accessibili e scalabili.

Ho scelto di inserire una tabella perché i dati sono più facili da confrontare colpo d'occhio, piuttosto che descriverli uno dopo l'altro nel testo:

6. Sistemi distribuiti pervasivi e reti domestiche

I sistemi distribuiti pervasivi rappresentano una nuova generazione di soluzioni informatiche, caratterizzate da dispositivi piccoli, mobili e connessi via wireless, con applicazioni in domotica, sanità digitale e reti di sensori. Nelle reti domestiche moderne, un dispositivo centrale — router o gateway — collega PC, smartphone, elettrodomestici intelligenti e dispositivi IoT, rendendo possibili ambienti automatizzati e auto-configuranti.

È uno degli argomenti che trovo più affascinanti da spiegare, perché gli studenti lo riconoscono subito nei dispositivi che usano ogni giorno: è in questo contesto che nasce la domotica (dal latino domus, casa, e "automatica"): l'insieme di tecnologie che permettono il controllo intelligente dell'abitazione, migliorando comfort, sicurezza ed efficienza energetica. Il concetto è strettamente legato a quello di Ambient Intelligence, in cui l'ambiente digitale supporta attivamente l'utente nelle attività quotidiane.

Definizione formale

Secondo D.J. Cook, un sistema di Ambient Intelligence è "un ambiente digitale che supporta le persone in modo proattivo ma ragionato nella loro vita".

7. Wearable computing e reti di sensori

Il wearable computing riguarda dispositivi indossabili in grado di raccogliere ed elaborare dati in tempo reale, con applicazioni particolarmente rilevanti in ambito medico: monitoraggio di parametri vitali e trasmissione a sistemi remoti o cloud. Le modalità operative principali sono due: la memorizzazione locale (i dati restano su un PDA o su uno smartphone) e la trasmissione remota (i dati vengono inviati a un'infrastruttura cloud, accessibile in tempo reale dagli operatori sanitari).

Attenzione — sfide dei dispositivi wearable

• Memorizzazione e gestione dei dati: capacità di archiviazione adeguata senza penalizzare le prestazioni
• Prevenzione della perdita di dati: backup e sincronizzazione per evitare perdite di informazioni cruciali
• Sicurezza e privacy: protocolli criptati e autenticazione sicura per i dati sanitari
• Gestione degli allarmi: notifiche immediate a medici o familiari in caso di valori anomali

Le reti di sensori wireless (WSN) sono composte da numerosi nodi — da 10 a 1000 — che raccolgono informazioni sull'ambiente o sul corpo umano. I dati raccolti possono seguire due strade: confluire in una base di dati centralizzata su un server remoto, oppure restare in una memorizzazione distribuita, dove ogni nodo conserva parte delle informazioni. Questa seconda opzione è particolarmente utile quando la connettività è intermittente o si vuole ridurre la dipendenza da un unico punto di raccolta.

8. Architetture a livelli e il middleware

Per ridurre il carico sui server e migliorare la modularità del software, sono state introdotte le architetture multilivello, in cui le funzionalità applicative si suddividono in più livelli logici. In questo contesto si colloca il middleware: uno strato software intermedio che si posiziona sopra il sistema operativo e sotto le applicazioni, evoluzione naturale dei sistemi operativi distribuiti, con il compito di gestire la complessità tipica dei sistemi distribuiti.

Definizione formale

Secondo D.E. Bakken, il middleware è un insieme di tecnologie software progettate per assistere gli sviluppatori nella gestione dell'eterogeneità e della complessità dei sistemi distribuiti, facilitando comunicazione e interazione tra componenti software distribuiti in un'architettura a tre livelli.

L'obiettivo principale del middleware è garantire l'interoperabilità tra applicazioni su sistemi operativi differenti e la connettività tra servizi che devono collaborare all'interno di piattaforme distribuite, offrendo API relativamente semplici da programmare. Grazie al middleware, i sistemi distribuiti possono adottare modelli di interazione come la chiamata di procedure remote (RPC) o lo scambio di messaggi tra processi. Tra le sue funzionalità: servizi di astrazione e cooperazione, servizi per le applicazioni, servizi di amministrazione del sistema, servizi di comunicazione, ambienti di sviluppo applicativo. Secondo Bernstein, un servizio di middleware è un servizio general-purpose che si colloca tra le piattaforme e le applicazioni, fungendo da collegamento tra i diversi livelli del sistema.

Ho voluto includere anche i limiti del middleware, non solo i suoi meriti: è un aspetto che nei testi scolastici viene spesso tralasciato, e invece aiuta a capire dove finisce la responsabilità di uno strumento e dove comincia quella di chi programma.

I limiti del middleware

Il middleware non è una soluzione universale. Molti sviluppatori non distinguono correttamente tra una chiamata di procedura locale e una remota, con conseguenze negative su prestazioni e affidabilità. Inoltre il middleware si occupa prevalentemente della comunicazione: non gestisce direttamente malfunzionamenti applicativi, guasti dei server o problemi di rete, che restano responsabilità dell'applicazione stessa.

9. Le architetture software distribuite: dai terminali remoti ai sistemi completamente distribuiti

L'evoluzione dei sistemi distribuiti non ha riguardato solo l'hardware: anche il software ha attraversato un proprio percorso, spesso anticipando i cambiamenti nei sistemi operativi e nelle reti. Ripercorrerlo aiuta a capire come si sia passati da sistemi rigidamente centralizzati a soluzioni flessibili, scalabili e cooperative.

Timeline architetture software

Architettura a terminali remoti

La prima forma di architettura distribuita collega terminali remoti a un'unica entità centrale, che esegue interamente l'elaborazione. I terminali sono dispositivi passivi, privi di capacità computazionale autonoma: si limitano a inviare input e a ricevere in output i risultati, mentre ogni sessione utente ha un'area di memoria dedicata ma il controllo resta totalmente accentrato. Caratteristiche tipiche: terminali omogenei e con funzionalità limitate, elaborazione completamente centralizzata, forte dipendenza da un unico punto di calcolo, bassa scalabilità e ridotta tolleranza ai guasti. Nonostante i limiti, è stato un modello efficace nelle prime fasi dell'informatica aziendale e istituzionale.

Architettura client-server

Il client-server nasce come evoluzione naturale del modello a terminali remoti: i client acquisiscono capacità di elaborazione locale e diventano entità attive, capaci di formulare richieste e interagire con uno o più server. Il server fornisce servizi specifici (accesso ai dati, elaborazione, gestione delle risorse), mentre il client gestisce l'interfaccia utente e parte della logica applicativa. Vantaggi principali: maggiore scalabilità rispetto al modello centralizzato, possibilità di distribuire i servizi su più server specializzati, interoperabilità tra tecnologie diverse, flessibilità di progettazione. Un aspetto interessante: un server può a sua volta comportarsi da client di un altro server, generando una rete di servizi interconnessi.

Architettura Web-centric

Con la diffusione del Web, le applicazioni si spostano prevalentemente sui server e i client diventano semplici interfacce di accesso, tipicamente il browser. Si distinguono le architetture Web tradizionali, basate su pagine HTML statiche o con interazione limitata, dalle architetture Web multilivello, che separano logica di presentazione, logica applicativa e gestione dei dati — una separazione che migliora manutenibilità del software e distribuzione del carico di lavoro.

Architettura cooperativa

Un'ulteriore evoluzione supera la distinzione rigida tra client e server: le entità software diventano componenti autonomi, capaci sia di offrire sia di richiedere servizi, basandosi su standard di comunicazione che garantiscono interoperabilità tra sistemi eterogenei, indipendentemente da hardware, sistema operativo o protocolli di rete. Un esempio storico significativo è CORBA (Common Object Request Broker Architecture), che permette a componenti distribuiti di comunicare come se fossero oggetti locali, favorendo modularità e riusabilità del software.

Architettura completamente distribuita

Nell'architettura completamente distribuita non esiste più un server centrale: le entità del sistema sono paritetiche e cooperano direttamente tra loro, come nei sistemi groupware o peer-to-peer. Caratteristiche: assenza di un punto centrale di controllo, elevata ridondanza delle risorse, maggiore tolleranza ai guasti, distribuzione efficace dei carichi di lavoro. Tra le tecnologie storicamente associate a questo approccio: gli standard dell'Object Management Group (OMG), RMI (Remote Method Invocation, per processi Java distribuiti) e DCOM (Distributed Component Object Model, sviluppato da Microsoft).

10. Punti chiave

• I limiti fisici della frequenza di clock (consumo, calore) hanno spinto l'hardware verso il parallelismo tra più unità di elaborazione.
• La classificazione di Flynn (1972) distingue SISD, SIMD, MISD e MIMD in base ai flussi di istruzioni e di dati; MIMD è oggi il modello più diffuso.
• Il cluster computing usa nodi omogenei per il calcolo ad alte prestazioni (modelli Beowulf e Single System Image); il grid computing coordina risorse eterogenee tra organizzazioni virtuali (OGSA).
• I sistemi pervasivi — domotica, Ambient Intelligence, wearable computing, reti di sensori — portano l'elaborazione distribuita dentro la casa e sul corpo delle persone.
• Le architetture software sono evolute da terminali remoti a client-server, Web-centric, cooperativa (CORBA) e completamente distribuita (P2P, RMI, DCOM).
• Il middleware gestisce l'eterogeneità e la complessità dei sistemi distribuiti, ma non sostituisce una corretta gestione applicativa degli errori.