Cosa sono i sistemi distribuiti?

I sistemi distribuiti suddividono il carico di lavoro e i dati tra più macchine che operano in parallelo; in questo modo, un processo che avrebbe richiesto settimane su un singolo grande computer può essere completato in poche ore o persino in pochi minuti. Ogni macchina, o "nodo", nel sistema ha la propria CPU, memoria e spesso il proprio storage. I nodi possono inviarsi messaggi a vicenda per coordinare la condivisione dei dati, suddividere il lavoro e unire le forze verso un obiettivo comune.

In un sistema distribuito, le macchine possono vivere nello stesso server rack (di un data center), tra diversi data center o in ambienti hybrid cloud disseminati nel mondo. Indipendentemente dalla configurazione, i sistemi distribuiti sono progettati per consentire agli utenti e alle applicazioni client di interagire con essi come se fossero un unico servizio ("un database", "un sito web", "un servizio di storage"), non un insieme di singoli server.

I sistemi distribuiti offrono alle imprese una soluzione a una sfida urgente dell'informatica moderna. Molte delle applicazioni attuali sono troppo grandi, troppo impegnative o troppo critiche per funzionare bene su una singola macchina. Queste applicazioni gestiscono spesso enormi volumi di dati e richieste che potrebbero sovraccaricare un singolo server. Gestiscono flussi di traffico con andamento a picchi che richiedono capacità agili di bilanciamento del carico . Gestiscono processi mission-critical in cui lunghi periodi di inattività possono essere catastrofici (sistemi bancari, ad esempio).

I sistemi distribuiti ripartiscono i workload su molti nodi e possono aggiungere automaticamente altri nodi alla rete in base alle esigenze. Questa scalabilità consente al sistema di accogliere più utenti e più dati anche quando i flussi di traffico sono imprevedibili. La scalabilità dei sistemi distribuiti è il motivo per cui le piattaforme di streaming, ad esempio, possono servire milioni di utenti in tutto il mondo, spesso contemporaneamente.

I sistemi distribuiti possono anche contribuire a ottimizzare l'affidabilità e la tolleranza ai guasti di un'architettura IT. Quando un nodo si guasta, altri nodi possono prendere il suo lavoro in modo che il servizio, complessivamente, continui a funzionare. Questa funzione riduce i singoli punti di guasto e aiuta le aziende a mantenere i sistemi ad alta disponibilità, un aspetto fondamentale per i sistemi che richiedono quasi il 100% di tempo di attività.

Inoltre, in un sistema distribuito, nodi separati cooperano strettamente ma dispongono di database e sistemi di storage propri. Questa configurazione facilita ai team IT la creazione di architetture modulari in cui diverse parti del sistema possono scalare ed evolversi in modo indipendente.

I sistemi distribuiti comprendono una serie di architetture diverse, ma tutte condividono una serie di caratteristiche fondamentali.

Per capire come funzionano i sistemi distribuiti, prendiamo l'esempio dei giochi online multiplayer di massa (MMOG).

Gli MMOG utilizzano architetture distribuite in cui molti server e nodi collaborano per mantenere un unico universo di gioco persistente, così migliaia di giocatori possono volare, commerciare, combattere ed esplorare contemporaneamente.

Poiché il mondo del gioco è enorme e il numero di giocatori è molto elevato, il backend del gioco è suddiviso su un cluster di macchine invece di essere gestito da un unico sistema. Un set di server monitora le caratteristiche dell'universo di gioco (posizioni dei giocatori, danni, inventario), mentre altre parti dell'infrastruttura gestiscono l'accesso degli utenti, le funzionalità di chat e la persistenza dell'universo. La divisione aiuta il gioco a rimanere reattivo anche quando molti giocatori sono attivi nella stessa regione contemporaneamente.

Durante ogni sessione di gioco, il sistema deve mantenere lo stato del gioco sincronizzato tra tutti i giocatori. Quando un giocatore agisce (ad esempio spostando una nave durante una battaglia di flotta), il client invia l'azione al server appropriato per quella parte del mondo di gioco. Il server aggiorna quindi lo stato di gioco condiviso in tempo reale e condivide il risultato con gli altri giocatori che devono vederlo.

Inoltre, il sistema di gioco distribuito utilizza protocolli specializzati per garantire che ogni giocatore veda gli stessi eventi di gioco all'incirca nello stesso momento.

Se un server si guasta durante il gioco, gli altri server sono progettati per coprire il problema e continuare a funzionare normalmente in modo che i giocatori non subiscano interruzioni.

I sistemi distribuiti sono l'opposto funzionale dei sistemi centralizzati. Mentre i sistemi distribuiti utilizzano un insieme di dispositivi per supportare le operazioni, i sistemi centralizzati si affidano a un server principale.

In un sistema centralizzato, un nodo centrale coordina la maggior parte o tutte le operazioni. I client di solito inviano richieste a quel nodo, e il nodo decide come elaborarle. Questa dinamica rende il sistema più comprensibile perché l'autorità è in un unico posto.

Tuttavia, un singolo nodo significa un unico punto di guasto. In un sistema centralizzato, se il server centrale non funziona, l'intero sistema non è disponibile, quindi la centralizzazione può presentare problemi significativi in situazioni in cui l'elevata disponibilità è importante.

I sistemi centralizzati spesso scalano verticalmente. Se un team IT intende migliorare il server principale, lo farà aggiungendo più processori, memoria o storage. Purtroppo, la crescita verticale non è una pratica sostenibile a lungo termine. Col tempo, richiede troppe risorse hardware e diventa troppo costoso.

Pertanto, i sistemi centralizzati sono più adatti a situazioni in cui la semplicità architettonica e la supervisione centralizzata contano più di una resilienza elevatissima. La centralizzazione è comunemente utilizzata per reti informatiche più piccole, sistemi aziendali interni, server di file e applicazioni client-server dove un'autorità necessita di un controllo stretto.

In un sistema distribuito, nessuna singola macchina detiene il controllo totale. Più nodi collaborano e ogni nodo può gestire parte del workload o memorizzare parte dei dati. La struttura è intrinsecamente più flessibile, ma richiede il coordinamento tra i nodi.

I sistemi distribuiti sono più tolleranti ai guasti perché gli altri nodi possono continuare a lavorare se un nodo si guasta. Un sistema distribuito è comunque soggetto ai guasti, ma tende a degradarsi in modo più graduale rispetto a un sistema centralizzato.

I sistemi distribuiti si basano sulla scala orizzontale, in cui il sistema aggiunge più macchine per soddisfare la crescente domanda di risorse.

Di conseguenza, gli ambienti distribuiti sono spesso preferiti in situazioni in cui molti utenti, grandi set di dati o una distribuzione geografica rendono una singola macchina centrale poco pratica. I sistemi distribuiti sono comuni per i servizi web, le piattaforme cloud, le reti blockchain e i servizi su larga scala che richiedono elevata disponibilità e scalabilità.

I sistemi distribuiti possono essere raggruppati in alcuni tipi comuni, in base a come sono organizzate le macchine e a come comunicano.

In un sistema client-server, un solo server centrale (o un piccolo gruppo di server) fornisce servizi, mentre altre macchine, mentre i "client", dipendono dal lavoro del server centrale.

Il server centrale, spesso la macchina più potente in termini di hardware, è responsabile della gestione delle risorse condivise (file, database, stampanti, account utente). I client sono tipicamente macchine per utenti finali (laptop, mobile, browser) che si concentrano sull'interazione con l'utente e sulla gestione di richieste e risposte.

Poiché i client e il server centrale vengono eseguiti su macchine separate e comunicano attraverso una rete, i sistemi client-server sono considerati sistemi distribuiti. Tuttavia, la comunicazione tra i nodi in un'architettura client-server è centralizzata.

Ogni client dipende dal server centrale per accedere alle risorse condivise, e i client non parlano direttamente tra loro di quelle risorse. Al contrario, la comunicazione tra i client e il server di solito segue un modello di richiesta-risposta.

Quando l'utente esegue un'azione (come fare clic su un pulsante), il client converte l'azione in un messaggio di richiesta e lo invia attraverso la rete al server. Il server riceve la richiesta, la elabora e poi invia una risposta. Il client interpreta quindi la risposta e mostra il risultato all'utente in modo leggibile.

Per esempio, un'applicazione web potrebbe utilizzare un browser (client) che invia richieste HTTP a un server web, che legge o scrive su un database e poi invia una risposta HTML o JSON.

La comunicazione centralizzata facilita l'aggiornamento dei sistemi client-server, l'applicazione delle politiche di sicurezza e la gestione dei dati. Il compromesso, tuttavia, è che la centralizzazione può creare colli di bottiglia e singoli punti di errore.

Nei sistemi peer-to-peer, tutti i nodi, chiamati "peer", hanno ruoli pressoché equivalenti. Ogni peer contribuisce con una parte delle proprie risorse e consuma le risorse offerte dagli altri peer. Ogni peer può sia chiedere risorse sia fornirle ad altri nodi.

Pertanto, "client" e "server" in un sistema P2P sono solo ruoli che un nodo svolge temporaneamente, non identità fisse.

In un sistema P2P puro, i peer si scoprono a vicenda e comunicano tramite una rete overlay, una rete logica costruita al di sopra delle connessioni internet fisiche. La rete overlay decide chi parla con chi e come i dati vengono instradati tra i peer.

Quando un peer ha bisogno di qualcosa (ad esempio un file chunk), invia richieste direttamente ad altri peer che potrebbero averlo. E quando un altro peer riceve la richiesta, può rispondere e inviare i dati richiesti, fungendo di fatto da server in quel momento. In seguito, i ruoli potrebbero invertirsi e gli stessi due nodi potrebbero scambiarsi i ruoli di chi fornisce i dati e chi li richiede.

Poiché tutti i peer possono sia dare che ricevere, i workload per il trattamento dei dati tendono a essere distribuiti in modo più uniforme nella rete. E man mano che più peer si uniscono, portano con sé maggiore capacità, aiutando il sistema a scalare più facilmente.

Le classiche reti di condivisione file sono un buon esempio di sistemi P2P. Il computer di ogni utente memorizza porzioni di file e le carica su altri nodi, scaricando anche eventuali parti mancanti.

I sistemi P2P sono più robusti rispetto a singoli punti di guasto rispetto ai sistemi client-server. Se un peer va off-line, l'intero sistema in genere continua a funzionare perché gli altri peer conservano copie dei dati o possono instradare i dati intorno al nodo guasto.

I sistemi multilivello espandono il modello client-server di base e lo organizzano in più livelli chiaramente separati, ognuno con il proprio compito. Le forme più comuni sono two-tier, three-tier e n-tier.

Un sistema a due livelli è un'architettura client-server con un altro nome. Il client contiene la maggior parte della logica dell'applicazione e parla direttamente con il database del server per eseguire query e aggiornamenti. Il processo è semplice, ma collega strettamente l'interfaccia utente ai dati. Qualsiasi cambiamento nella struttura dati può forzare modifiche in molti altri clienti.

Le architetture a tre livelli utilizzano tre layer. Il layer di presentazione gestisce l'interfaccia utente (pagine web, interfaccia utente mobile, interfaccia utente desktop). Il layer applicazione, o "logica aziendale", implementa regole e workflow (convalide, calcoli, decisioni). Il layer dati memorizza e recupera i dati da database distribuiti o altri sistemi di storage.

I sistemi a N livelli estendono l'idea dei tre livelli aggiungendo altri layer specializzati. Ad esempio, i team IT potrebbero scegliere di creare un'application programming interface (API) o un livello di servizio separato che esponga gli endpoint REST o GraphQL. Potrebbero anche separare un livello di autenticazione e crittografia per gestire i login e i token degli utenti.

I livelli extra seguono lo stesso principio dei primi tre. Ogni livello ha una responsabilità principale e i livelli comunicano tramite interfacce ben definite. Questa modularità permette ai team di lavorare, aggiornare o sostituire diversi livelli in modo indipendente, magari usando tecnologie diverse per ciascuno.

I sistemi multilivello sono comunemente utilizzati per gestire siti web di e-commerce e applicazioni bancarie.

Un cluster è un gruppo di computer interconnessi in locale che operano come un'unica macchina più potente. I nodi in un cluster sono strettamente accoppiati, quindi in genere sono:

• Nello stesso luogo fisico (nella stessa stanza o data center).
  
  
• Connessi tramite collegamenti ad alta velocità, come reti locali ad alta larghezza di banda (LAN) o interconnessioni specializzate.
  
  
• Utilizzano hardware e sistemi operativi simili o identici.

Poiché i nodi sono simili e ben connessi, il cluster può suddividere un compito grande in parti più piccole per l'elaborazione parallela su nodi diversi e poi combinare i risultati.

I cluster vengono gestiti da software specifici, come middleware per cluster, scheduler o resource manager. Il software decide quali nodi eseguono quali job, monitora lo stato di salute dei nodi, gestisce l'instradamento dei dati e bilancia i workload tra i nodi. Questo livello di gestione trasforma un generico gruppo di computer in rete in un cluster autonomo. Permette agli utenti di inviare un job al cluster nel suo complesso invece di effettuare l'accesso manualmente a ogni macchina.

I sistemi cluster sono utili per le situazioni che richiedono un'elaborazione ad alte prestazioni, come l'analisi dei big data, l'addestramento di modelli AI e le simulazioni scientifiche.

Il grid computing consiste nel mettere insieme molti computer indipendenti (spesso disseminati tra diverse città e paesi) e farli collaborare su un unico grande compito computazionale.

Ogni macchina partecipante a una grid potrebbe appartenere a un'organizzazione o a un individuo diverso. Potrebbero tutti avere CPU, dimensioni di memoria, sistemi operativi e policy locali differenti. Tuttavia, accettano di condividere alcune risorse disponibili per problemi comuni.

Poiché una grid copre più domini amministrativi, nessuna organizzazione possiede o controlla completamente tutte le macchine. Questa è una differenza fondamentale tra grid e cluster, dove un'unica istituzione possiede e gestisce server che risiedono in un solo data center.

In un sistema a grid, ogni nodo rimane autonomo. Può entrare o uscire dalla grid, ha un proprio Resource Manager e può avere regole di sicurezza o priorità differenti. Il middleware grid fornisce un livello comune per l'invio di job, il discovery delle risorse disponibili, la pianificazione del lavoro, lo spostamento dei dati e la raccolta dei risultati. Questo middleware permette all'intera grid di funzionare come un supercomputer virtuale per gli utenti finali.

Quando un utente invia un lavoro grande (come una simulazione di ripiegamento delle proteine o un calcolo del rischio finanziario), il middleware suddivide automaticamente il job in molti compiti più piccoli. Quindi cerca le macchine inattive o sottoutilizzate in qualsiasi punto della grid per assegnare parti del lavoro. Ogni macchina lavora per conto suo e poi invia i risultati che vengono combinati nella risposta finale.

È importante sottolineare che i nodi della grid non sono dedicati esclusivamente ad essa. Potrebbero trattarsi di normali computer desktop o server che mettono a disposizione i cicli di CPU inutilizzati quando non sono impegnati nelle attività locali principali.

I sistemi distribuiti basati sul cloud sono costruiti sopra grandi data center gestiti dai provider di cloud.

Invece di possedere server fisici, le organizzazioni affittano risorse di calcolo distribuite tramite internet. Tali risorse vengono esposte sotto forma di macchine virtuali (VM), container, database, code e altri servizi gestiti.

I sistemi cloud sono, soprattutto, elastici. Le aziende possono richiedere più capacità di calcolo, di storage o di rete quando il workload aumenta e rilasciare le risorse quando il workload diminuisce. Consentono inoltre alle aziende di pagare solo per le risorse utilizzate, invece di acquistare hardware in anticipo.

Con i sistemi cloud, i team IT possono implementare processi dinamici di scaling orizzontale. I gruppi di Auto-Scaling (gruppi logici di istanze server identiche) osservano le metriche del workload per le fluttuazioni. Quando il carico supera le soglie prestabilite, gli strumenti di automazione avviano ulteriori istanze del servizio. Quando il carico diminuisce, chiude automaticamente le istanze aggiuntive per risparmiare denaro.

Le architetture di microservizio sono sistemi distribuiti a livello di applicazione che utilizzano più componenti indipendenti in esecuzione su macchine diverse per costruire applicazioni software.

A differenza delle applicazioni monolitiche, nessun singolo microservizio in un'architettura di microservizi contiene l'intera app. Invece, ogni microservizio è un proprio piccolo servizio (con il proprio codice e solitamente il proprio storage dei dati) responsabile di una specifica capacità e che funziona indipendentemente dagli altri container.

Poiché sono indipendenti, i microservizi possono essere sviluppati, distribuiti e scalati autonomamente, ma i vantaggi del sistema derivano dalla loro collaborazione.

Quando gli utenti inviano una richiesta, il client crea un messaggio e lo invia a un dispositivo edge (ad esempio, un bilanciatore di carico o un'API Gateway). Il dispositivo edge invia la richiesta al microservizio appropriato. Il microservizio destinatario legge il messaggio, esegue la propria logica di business e poi invia una risposta al dispositivo edge, che trasmette la risposta all'utente.

I sistemi distribuiti sono pervasivi nel mondo reale. Molti degli strumenti e dei servizi utilizzati dalle persone per l'intrattenimento, gli affari e la gestione finanziaria sono costruiti su sistemi distribuiti.

• Scalabilità: i sistemi di calcolo distribuito eccellono nella scalabilità orizzontale, che consente alle aziende di aggiungere semplicemente più nodi alla rete quando i workload aumentano, invece di investire in costosi aggiornamenti a un singolo server.

• Affidabilità e tolleranza ai guasti: eliminando i singoli punti di errore, i sistemi distribuiti forniscono una ridondanza integrata che mantiene le applicazioni in esecuzione per gli utenti, anche quando i singoli nodi si guastano.

• Efficienza delle risorse e risparmio sui costi: le architetture distribuite consentono alle aziende di creare ambienti di elaborazione potenti, utilizzando cluster di hardware standard a basso costo, invece di costosi supercomputer specializzati.

• Distribuzione e accessibilità globale: i sistemi distribuiti possono implementare applicazioni più vicine agli utenti in tutto il mondo, riducendo la latenza rispondendo alle richieste da nodi geograficamente più vicini.