Categorie di sistemi distribuiti

Lezione del 2019-03-13 mer.

È possibile classificare i tipi di sistemi distribuiti in base alle loro soluzioni tecnologiche e agli obiettivi che hanno.

Si distingue tra:

  • distributed computing systems;

  • distributed information systems;

  • pervasive systems.

Distributed computing systems

Si utilizzano per affrontare problemi di calcolo intensivo.

In questo ambito vi sono due grandi categorie:

  • cluster computing;

  • grid computing.

Cluster computing. Sono computer, usualmente simili e localizzati nella stessa zona, collegati da una rete dati ad alta velocità (LAN).

Ad esempio si può utilizzare Beowulf, che, tramite un computer master, è in grado di distribuire un insieme di processi su un gruppo di macchine Linux.

Un campo di applicazione del cluster computing è il calcolo delle previsioni meteo. Lo European Centre for Medium Range Weather Forecasts (ECMWF) a Shinfield Park, READING, Berkshire, in Gran Bretagna, era formato da centinaia di migliaia di sistemi simili, connessi con una rete locale ad altissima velocità (ordine dei Terabit).

Grid computing. In questo caso le risorse sono eterogenee, e possono appartenere a diverse istituzioni. Appartenendo a istituzioni diverse, queste risorse sono collegate tramite reti dati geografiche; di solito, Internet.

Un esempio di grid computing è il progetto SETI per la ricerca di vita extraterrestre.

La programmazione di distributed computing systems avviene utilizzando delle apposite librerie di un qualche tipo, che facilitano l’utilizzo della infrastruttura fisica.

Un criterio di scelta tra architettura cluster e grid consiste nel valutare la quantità di dati da scambiare tra i nodi. Se i dati da scambiare sono tanti, è necessario utilizzare il cluster computing. Se i dati invece sono rarefatti, è possibile utilizzare il grid computing.

La high performance computing è un’area di ricerca a se stante.

Distributed information systems

Questi hanno l’obiettivo di gestire informazione distribuita. Ovvero abbiamo pezzi di informazione su sistemi diversi, e li vogliamo gestire in modo tale che appaiano come se fossero tutti presenti in un unico sistema.

Esempio classico: database distribuiti.

Si possono avere implementazioni:

  • distributed transaction processing (o TPS: transaction processing system);

  • enterprise application integration (EAI)

Distributed transaction processing. Nei sistemi transazionali valgono le proprietà ACID (Atomicity, Consistency, Isolation, Durability) verso una base dati.

In particolare l’atomicità consiste nel riuscire a eseguire tutto un blocco di istruzioni, o non eseguire nulla in caso contrario.

La consistenza significa che vengono rispettati eventuali vincoli imposti.

L’isolamento implica che più transazioni in parallelo non interferiscono l’una con l’altra.

La durabilità significa che, all’ordine di commit i risultati delle operazioni effettuate sono permanenti.

I sistemi transazionali distribuiti hanno una difficoltà intrinseca maggiore rispetto quelli centralizzati: possono fallire a pezzi. Si pensi al fatto che ci troviamo di fronte a più basi dati, ognuna in sistemi diversi. È possibile che una transazione avvenga parzialmente su una prima base dati, quindi una seconda, e così via. Se fallisce il lavoro in una base dati intermedia, è necessario annullare anche il lavoro già effettuato in tutte le basi dati precedenti, in cui si era concluso con successo.

Per implementare sistemi distribuiti transazionali di solito si usa un Transaction Processing Monitor (TPM). Praticamente consiste nell’avere un sistema centrale che colleziona le richieste e le distribuisce ai diversi sistemi verificando puntualmente come stanno andando le singole operazioni. In tal modo, l’informazione è distribuita, ma la logica di controllo è centralizzata.

Invece di integrare le basi dati, si può pensare di integrare le applicazioni, approcciando così il concetto di Enterprise Application Integration.

In questo caso vi sono una serie di server, dotati di interfacce di comunicazione di tipo peer to peer. Le informazioni volute vengono costruite accedendo ai diversi server che le contengono, per poi montarle opportunamente. Questo approccio è molto più complesso del TPM.

Ad esempio si pensi a dei server WEB con interfacce di accesso ai servizi. Per integrare i relativi dati è necessrio lavorare sulle risposte dei servizi in questione.

Distributed pervasive systems

I sistemi distribuiti pervasivi sono parte dell’ambiente che ci circonda.

I device che li compongono hanno la necessità di scoprire i servizi e adattarsi all’ambiente.

Esempi di sistemi distribuiti pervasivi sono:

  • sistemi domestici;

  • sistemi elettronici per assistenza sanitaria;

  • reti di sensori wireless.

Un sistema domestico (home system, in italiano: domotica) tipicamente presenta le caratteristiche di essere:

  • auto gestito;

  • auto configurato;

  • essere uno spazio personale.

I sistemi elettronici per assistenza sanitaria (electronic health care systems) sono composti da sensori che rilevano misure sanitarie dal paziente (sensori di movimento, ECG, …) e le trasmettono tramite una body-area network (BAN) ad un hub che li colleziona e li ritrasmette ad un repository centralizzato.

Una architettura alternativa consiste nel collegare i sensori di misura ad un sistema di memorizzazione esterna tramite una connessione wireless continua GPRS/UMTS.

A differenza dei sistemi domestici, i sistemi sanitari non possono essere implementati con architetture fornite di singoli server. I sistemi sanitari necessitano di capacità di elaborazione in-network.

Le reti di sensori wireless (wireless sensor networks: WSNs) sono sistemi di sensori autonomi, distribuiti nello spazio fisico, che monitorizzano cooperativamente condizioni fisiche o ambientali.

Sono caratterizzati da limitazioni stringenti riguardo:

  • capacità di elaborazione;

  • quantità di memoria;

  • capacità di alimentazione.

Questi sistemi sono particolarmente sfidanti, in relazione a:

  • consumo di energia;

  • programmazione;

  • sicurezza;

  • routing;

  • ingegnerizzazione del software;

  • middleware.

Tipicamente sarà necessario ottenere le informazioni collezionate dalla rete dei sensori.

Sono possibili diverse architetture:

  • si può ipotizzare che i sensori non cooperino tra loro, e non archivino i dati raccolti, ma si limitino a inviare direttamente il dato all’operatore;

  • oppure si possono avere sensori in grado di processare e memorizzare i dati; a fronte di una query, i sensori responsabili dei dati richiesti inviano le sole risposte.

Queste soluzioni non sono molto attraenti perché:

  • i consumi energetici sono elevati;

  • è necessario limitare i dati di risposta all’operatore.

Per questi motivi si considera la necessità di avere capacità di elaborazione in-network. A questo fine si possono utilizzare pattern pub/sub (publish/subscribe).