Capitolo 1: Architettura dei sistemi distribuiti Introduzione

Transcript

1 Capitolo 1: Architettura dei sistemi distribuiti Introduzione Abbiamo visto come negli ultimi anni la crescita esponenziale del Web abbia in qualche modo portato allo sviluppo di servizi fortemente centralizzati, in netto contrasto con la natura fortemente distribuita della rete stessa così come era stata concepita. L architettura client/server, che rappresenta il core system di molti sistemi presenti ad oggi su Internet, ha portato sicuramente notevoli vantaggi in termini di fruizione del servizio e centralità di risorse ma questi stessi vantaggi si sono dimostrati più volte una sorta di handicap proprio nei punti di forza che volevano rappresentare. Il crescente numero di attacchi informatici atti alla negazione del servizio (Distribuited Denial of Service) uniti ad una esponenziale crescita dell utenza, con sempre maggiori richieste di risorse, è risultato come il maggior punto di debolezza dell architettura client/server. D altra parte non possiamo ignorare come l esistenza di un sistema basato su di una topologia a carattere gerarchico, qual è il DNS (Domain Name System) ci insegni (da 30 anni a questa parte) come l organizzazione e lo scambio di una cospicua mole di informazioni, non possano sottostare ad un architettura centralizzata e scarsamente ridondata. Dopo aver analizzato brevemente l architettura di rete client/server illustrandone i principali pregi e difetti, vedremo di seguito l architettura dei sistemi distribuiti e le loro caratteristiche al fine di individuare un modello di rete volto a risolvere molte delle problematiche che affliggono le architetture centralizzate. 5

2 1.1 Architettura Client / Server Nella architettura client/server si ha la presenza di due o più nodi con ruoli differenti e ben definiti : - client : richiedono un servizio e ne usufruiscono senza condividere risorse - server : forniscono risorse ai client I sistemi centralizzati sono la più comune topologia di rete che si possa presentare. Nodo Server Nodi Client Fig. 1 : Topologia di rete centralizzata (Client / Server) Molti sono i servizi su Internet che presentano tale topologia. Il più conosciuto è senz altro il WWW seguito dalla posta elettronica e dai servizi basati sullo scambio di file (FTP) ; in tutti questi vi è sempre presente un nodo server che fornisce, nel caso dei servizi elencati, pagine Web, inoltro della posta elettronica piuttosto che la possibilità di scaricare un file nel caso dell FTP. Si può notare come proprio il servizio FTP dia non solo la possibilità di ricevere un file ma anche quella di spedirne uno verso il server stesso. Questa bidirezionalità nella comunicazione client/server non deve trarre in inganno : seguendo la definizione di sistema distribuito precedentemente esposta, un sistema centralizzato, quale l FTP, non consente la condivisione delle risorse né in termini di file né in termini di potenza di calcolo; i nodi client comunicano solo ed esclusivamente con il server FTP. 6

3 Al fine di gestire un carico superiore di richieste e garantire un certo grado di fault-tolerance, i moderni sistemi centralizzati basati su di un architettura client/server, si avvalgono di una topologia ibrida di questo tipo : Nodi Server Nodi Client Fig. 2 : Topologia di rete ibrida centralizzata con nodi server ad anello I nodi server vengono connessi secondo una topologia ad anello o cluster, configurati tutti allo stesso modo e contenenti le stesse informazioni. Nel caso in cui uno dei nodi costituenti il cluster dovesse per qualche motivo smettere di funzionare, le richieste dei client verrebbero soddisfatte dal un altro server nell anello : tutto questo avviene in modo trasparente per il client Pregi e difetti dell architettura Client/Server Come spiegato precedentemente le architetture centralizzate client/server sono le topologie di rete più comuni e semplici da realizzare. Questa semplicità di implementazione consente una facile gestione del sistema ed una coerenza dei dati assicurata dalla centralità degli stessi e dal conseguente controllo che il server può applicare. Anche l implementazione della sicurezza rappresenta, nei sistemi client/server, un fattore di facile implementazione visto che tutti gli sforzi devono essere concentrati su di un solo nodo (server). 7

4 Alcune applicazioni peer-to-peer hanno alcune componenti centralizzate. Il progetto (Search for Extraterrestrial Intelligence)[13] si basa su di una architettura fortemente centralizzata, dove il server distribuisce il proprio carico di lavoro, a tutti i nodi partecipanti. Lo stesso Napster[14], manteneva l indice delle risorse condivise all interno di un server, demandando invece lo scambio dei file ai nodi collegati ad esso. La centralità delle risorse porta ad avere un singolo punto di fallimento ; se il server si guasta o viene attaccato, le risorse risultano essere non disponibili ed è altrettanto facile per il governo ospitante il server, colpire con leggi e/o ingiunzioni il servizio erogato. Seppur l architettura ibrida di fig.2 consente un maggior grado di fault-tolerance, spesse volte questa soluzione risulta essere un palliativo per problematiche che tenderanno sempre a ripresentarsi nel tempo. A tutto ciò si aggiunge il fattore scalabilità, anch esso legato alle disponibilità e/o volontà del proprietario del nodo server. 1.2 Definizione di un sistema distribuito Un sistema distribuito è un modello di rete in cui la potenza di calcolo o le risorse da condividere e/o elaborare, vengono distribuite fra più calcolatori (nodi). Da questa definizione discende direttamente quella di sistema peer-to-peer o sistema paritetico : 8

5 Se stiamo cercando un modo per capire se ci troviamo di fronte ad un sistema paritetico dobbiamo porci due domande : 1. il sistema consente un numero variabile di nodi connessi e indirizzi di rete temporanei? 2. il sistema elargisce ai nodi al confine della rete sufficiente autonomia? Se la risposta ad entrambe queste domande è sì allora l applicazione è peer-topeer. Se la risposta ad entrambe è no allora l applicazione non è peer-to-peer. Peer-to-Peer : Harnessing the power of disruptive technologies Clay Shirky Pur essendoci un comune accordo sulla definizione di sistema distribuito, molte obiezioni sono state sollevate per la definizione di sistema peer-to-peer (P2P in seguito). I puristi del P2P affermano che tutte le componenti di un sistema paritetico debbano essere completamente decentralizzate (routing e ricerca di file soprattutto) mantenendo ruoli e responsabilità dei singoli nodi, ad un livello paritario completo. Altri sviluppatori e ricercatori tendono a mantenere la definizione di sistema paritetico più vicina a quella di sistema distribuito, demandando solo una parte delle funzioni della rete ai singoli nodi per conservare alcune funzioni cardine presso nodi altamente specializzati. 9

6 1.3 Requisiti di sistema In accordo con la pubblicazione di Nelson Minar[4] sul sito ci serviremo di sette proprietà per valutare e confrontare la bontà di un sistema distribuito; vediamole in dettaglio. Gestione La proprietà Gestione si riferisce alla complessità, in termini tecnici, nel mantenere il sistema perfettamente funzionante. La possibilità di gestire facilmente un sistema risiede nella facilità nell effettuare l update (aggiornamento) di alcune o tutte le sue parti, nella possibilità di riparare nodi o connessioni non perfettamente funzionanti ed infine della raccolta di alcune informazioni di Log atte a verificarne il corretto funzionamento. Coerenza dei dati La coerenza delle informazioni all interno di un sistema distribuito (e non solo), definisce il grado di fiducia che l utenza concede al sistema stesso. Questa proprietà consente di stimare caratteristiche quali la consistenza dei dati e la non-ripudiabilità delle informazioni. La domanda chiave di questa proprietà è : quanto siamo certi che un file all interno del sistema sia di fatto inalterato e inalterabile? Espandibilità Da non confondere con la scalabilità, l espandibilità definisce il grado di difficoltà nell inserire nuovi nodi all interno del sistema preesistente. 10

7 Fault Tolerance A differenza di quanto accade nei sistemi centralizzati dove eventi quali la caduta di un server, gli attacchi DDOS o il degrado delle performance dovuto al guasto di router vengono considerati eccezionali, nei sistemi distribuiti questi fattori sono all ordine del giorno. Per questo motivo un sistema distribuito deve porre molta attenzione a tutte quelle tecniche (ridondanza,gestione delle performance etc...) che consentono un alto grado di fault-tolerance. Sicurezza La sicurezza rappresenta indubbiamente una parte fondamentale nella valutazione di un architettura ben congegnata. Molti aspetti vanno tenuti in considerazione. Tra i tanti se è possibile per un utente danneggiare il sistema, inserire informazione sporca, utilizzare il sistema stesso per fini non previsti dal progetto iniziale od illeciti. Aspetti Politici Quanto risulterebbe difficile per una governo o qualsiasi altra autorità, ordinare la chiusura o limitare l utilizzo del sistema? Questo argomento sarà approfondito in seguito, vista l importanza che ricopre nei sistemi paritetici. Scalabilità L ultima proprietà, non certo per importanza, che andremo ad utilizzare per valutare un sistema distribuito è la scalabilità. Essa rappresenta la possibilità per un sistema di crescere di dimensioni mantenendo intatte le proprie caratteristiche. Pur essendo considerata una proprietà vincente dei sistemi distribuiti, vedremo che la realtà è molto più complessa. 11