Architetture dei Sistemi Distribuiti

Transcript

1 Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica Architetture dei Sistemi Distribuiti Corso di Sistemi Distribuiti e Cloud Computing A.A. 2014/15 Valeria Cardellini Architettura sw di un SD Definisce l organizzazione logica e l interazione dei vari componenti software (tra loro e con l ambiente) che costituiscono il SD Diverse scelte possibili nella realizzazione di un SD Architettura di sistema: istanziazione finale di un architettura software I vari componenti del SD sono posizionati e istanziati sulle diverse macchine che costituiscono il sistema Valeria Cardellini - SDCC 2014/15 1

2 Architectural styles (patterns) for DS Pattern: a commonly applied solution for a class of problems An architectural style is a coherent set of design decisions concerning the architecture In terms of definition and usage of components and connectors Component (building block) Modular unit with well-defined required and provided interfaces Fully replaceable within its environment Connector Mechanism that mediates communication, coordination or coordination among components Main architectural styles for DS Layered style Object-based style Event-based style Data-oriented style Publish-subscribe style Valeria Cardellini - SDCC 2014/15 2 Componenti organizzati in livelli (layer) Architettura a livelli Componente a livello i invoca componente del livello sottostante i-1 Comunicazione tra componenti: basata su scambio di messaggi (comunicazione tra processi) Le richieste scendono lungo la gerarchia, mentre le risposte risalgono Servizi tipici offerti da un applicazione distribuita con architettura a livelli: di interfaccia, applicativi, di storage Valeria Cardellini - SDCC 2014/15 3

3 Architettura basata su oggetti Componente=oggetto: incapsula una struttura dati fornendo un API per accedere o modificare i dati Incapsulamento e information hiding riducono la complessità di gestione Riusabilità tra applicazioni diverse Wrapping di componenti legacy Comunicazione tra componenti: mediante chiamata a procedura remota (RPC) o invocazione di metodo remota (RMI) Valeria Cardellini - SDCC 2014/15 4 Disaccoppiamento Porre vincoli sui componenti che possono interagire può introdurre vincoli non necessari Soluzione: far comunicare in modo indiretto mittente e destinatario/i tramite un intermediario All problems in computer science can be solved by another level of indirection (Titan project at Univ. of Cambridge) Disaccoppiamento (decoupling): fattore abilitante per ottenere maggiore flessibilità e per definire stili architetturali che possono sfruttare al meglio la distribuzione e scalabilità Proprietà di disaccoppiamento Spaziale (o referenziale): i componenti non devono conoscersi (reciprocamente o meno); sono anonimi Temporale: i componenti interagenti non devono essere compresenti (presenti insieme nello stesso instante) quando la comunicazione ha luogo Di sincronia: i componenti interagenti non devono aspettarsi a vicenda e non sono soggetti a blocchi reciproci Valeria Cardellini - SDCC 2014/15 5

4 Decoupling: pros and cons Thanks to decoupling, the DS can be flexible while dealing with changes and can provide more dependable services Space decoupling: components can be replaced, updated, replicated or migrated Time decoupling: allows to manage volatility (senders and receivers can come and go) Synchronization decoupling: no blocking Main disadvantage: Performance overhead introduced by indirection Valeria Cardellini - SDCC 2014/15 6 Evoluzione degli stili architetturali Il disaccoppiamento dei componenti ha determinato la definizione di stili architetturali alternativi, in cui i componenti non comunicano direttamente tra loro Architettura basata su eventi Architettura orientata ai dati Architettura publish-subscribe Valeria Cardellini - SDCC 2014/15 7

5 Architettura basata su eventi Comunicazione tra componenti: tramite la propagazione di eventi Evento: cambio significativo dello stato (es.: variazione della temperatura, apertura di una porta) Componenti Pubblicano notifiche sugli eventi che osservano Sottoscrivono eventi di cui sono interessati a ricevere la notifica Comunicazione Basata su scambio di messaggi Asincrona Multicast Anonima Esempi: Java Swing Quale tipo di disaccoppiamento? Valeria Cardellini - SDCC 2014/15 8 Data-oriented architecture Communication among components: through a shared data space (usually passive, but sometimes active) with persistent storage Data added to or removed from the shared space Also known as blackboard model API for shared space write, take, read and their variants (takeifexists, readifexists) In case of active space: also notify (to avoid polling) Mutual exclusion to access data Examples: Linda and tuple space JavaSpaces, GigaSpaces, TIBCO ActiveSpaces, Fly Object Space How can we implement the shared space? Which type of decoupling? Valeria Cardellini - SDCC 2014/15 9

6 Architettura publish/subscribe I produttori generano eventi (publish) e si disinteressano della loro consegna ai consumatori I consumatori si registrano come interessati ad un evento (subscribe) e sono avvisati (notify) della sua occorrenza Disaccoppiamento completo tra entità interagenti Publisher Publisher P P publish publish Middleware publish/subscribe Storage and management of subscriptions notify() subscribe() unsubscribe() subscribe unsubscribe notify S S Subscriber S Subscriber Subscriber Valeria Cardellini - SDCC 2014/15 10 Publish/subscribe and decoupling Space decoupling P Middleware notify S publish/subscribe publish notify notify() S Time decoupling P publish Middleware publish/subscribe notify S S Synchronization decoupling P P publish Middleware publish/subscribe notify() notify Middleware publish/subscribe notify() S notify t S P.T. Eugster et al., The many faces of publish/subscribe ACM Comput. Surv. 35(2): , June Valeria Cardellini - SDCC 2014/15 11

7 Publish/subscribe variations Most widely used subscription schemes in publish/subscribe systems Topic-based (or subject based) Participants can publish events and subscribe to individual topics, which are identified by keywords Cons: limited expressiveness Content-based Events are not classified according to some predefined external criterion, but according to their actual content, e.g., meta-data associated to events Consumers subscribe to events by specifying filters Cons: implementation challenges Valeria Cardellini - SDCC 2014/15 12 Implementation issues of publish/subscribe Tasks of publish-subscribe system To ensure that events are delivered efficiently to all subscribers that have filters matching the event In a secure, scalable, dependable, concurrent way Centralized vs distributed implementations Centralized: a single node acting as an event broker that maintains a repository of subscriptions and matches event notifications against this set of subscriptions Pro: simple Cons: lacks resiliency and scalability Distributed: network of cooperative brokers as well as peer-topeer implementations (e.g., based on DHT) The distributed implementation of content-based schemes is complex Valeria Cardellini - SDCC 2014/15 13

8 Other common architectural patterns Proxy Aim: to support location transparency (see RPC and RMI) Control access to an object using another proxy object The proxy is created in the local address space to represent the remote object and offers the same interface of the remote object Broker Aim: to separate and encapsulate the details of the communication infrastructure from its application functionality Enables components of a distributed application to interact without handling remote concerns by themselves Locates the server for the client, hides the details of remote communication, More than 100 design patterns for distributed computing systems! Source: Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, Vol. 4 Valeria Cardellini - SDCC 2014/15 14 Choosing an architectural style No single solution: the same problem can be tackled with many different designs and architectural styles Choice depends often on extra-functional requirements: Costs (resource usage, development effort needed) Scalability (effects of scaling work complexity and available resources) Performance (e.g., execution time, response time, latency) Reliability Fault tolerance Maintainability (extending system with new components) Usability (ease of configuration and usage) Reusability Valeria Cardellini - SDCC 2014/15 15

9 Architettura di sistema E l istanziazione finale di un architettura software Quali componenti software usare? Come interagiscono i componenti? Dove sono posizionati i componenti? Tipologie di architetture di sistema Architetture centralizzate Architetture decentralizzate Architetture ibride Valeria Cardellini - SDCC 2014/15 16 Architetture centralizzate E il modello client/server Il più diffuso Intrinsecamente distribuito Esempio: Web Comunicazione tra client e server basata su scambio di messaggi e comportamento di tipo request-reply Possibile sorgente del problema di prestazioni (ad es. Web) Alcune richieste (ma non tutte) di tipo idempotente Possono essere ripetute più volte senza causare danni o problemi Proprietà importante in caso di comunicazioni inaffidabili: rendere logicamente affidabile una connessione fisicamente inaffidabile ha un costo molto elevato Asimmetria con il client che conosce il server e interagisce in modo sincrono e bloccante (di default) Forte accoppiamento Compresenza di chi interagisce Valeria Cardellini - SDCC 2014/15 17

10 Stratificazione E lo stile architetturale a livelli applicato alle architetture centralizzate Livello dell interfaccia utente Gestisce l interazione con l utente ed aggiorna la vista dell applicazione presentata all utente Spesso suddiviso in due livelli (livello lato client e livello di presentazione lato server) Livello applicativo (logico o business) Livello dei dati Gestisce lo spazio di memorizzazione persistente, spesso un DBMS Ad es. presente in molti SD informativi, che implementano il livello dei dati mediante DB relazionali, ad oggetti o object-relational Valeria Cardellini - SDCC 2014/15 18 Stratificazione (2) Esempio: motore di ricerca Web Valeria Cardellini - SDCC 2014/15 19

11 Architetture multilivello Mapping tra livelli logici (layer) e livelli fisici (tier) Architettura ad un singolo livello (single-tier) Configurazione monolitica mainframe e terminale stupido (no client/server!) Architettura a due livelli (two-tier) Due livelli fisici (client e server) Architettura a tre livelli (three-tier) Diverse configurazioni possibili Determinate dalla ripartizione dei servizi di interfaccia, applicativo e di storage nei diversi livelli Valeria Cardellini - SDCC 2014/15 20 Two-tier configurations thin client fat client Valeria Cardellini - SDCC 2014/15 21

12 Three-tier configurations Valeria Cardellini - SDCC 2014/15 22 Architetture multilivello (2) Da 1 a N livelli Con l introduzione di ciascun livello Migliorano flessibilità, funzionalità e possibilità di distribuzione Ma aumentando il numero di livelli, possibile degrado delle prestazioni Aumenta il costo della comunicazione Più complessità, in termini di gestione ed ottimizzazione Valeria Cardellini - SDCC 2014/15 23

13 Architetture multilivello (3) Varie architetture client-server possibili In relazione all organizzazione del servizio e dei suoi dati Distribuzione verticale Componenti logicamente diversi dello stesso servizio possono essere assegnati a macchine distinte Sia sul lato server che sul lato client (delega parziale) Servizio reso tramite la cooperazione di componenti distribuiti Ripartizione gerarchica (anche di autorità) Distribuzione orizzontale Server e client possono essere partizionati ma ogni loro componente può operare da solo Condivisione del carico (con ripartizione del lavoro gestita da un dispatcher) Ogni componente sa fornire il servizio richiesto Esempio che esamineremo: Web cluster Valeria Cardellini - SDCC 2014/15 24 Architetture decentralizzate ovvero i sistemi peer-to-peer (P2P) Il termine peer-to-peer si riferisce ad una classe di sistemi ed applicazioni che utilizzano risorse distribuite per eseguire una funzionalità (anche critica) in modo decentralizzato P2P is a class of applications that takes advantage of resources -- storage, cycles, content, human presence -- available at the edges of the Internet (Clay Shirny, 2000) Peer: entità con capacità simili alle altre entità nel sistema Condivisione delle risorse (cicli di CPU, storage, dati) Offrire ed ottenere risorse dalla comunità di peer Valeria Cardellini - SDCC 2014/15 25

14 Caratteristiche dei sistemi P2P Tutti i nodi (peer) del sistema con identiche capacità e responsabilità (almeno in linea di principio) Nodi indipendenti (autonomi) e localizzati ai bordi (edge) di Internet Nessun controllo centralizzato Ogni peer ha funzioni di client e server e condivide risorse e servizi servent = server + client In realtà, possono essere presenti server centralizzati o nodi con funzionalità diverse rispetto agli altri (supernodi) Sistemi altamente distribuiti Il numero di nodi può essere dell ordine delle centinaia di migliaia Nodi altamente dinamici ed autonomi Un nodo può entrare o uscire dalla rete P2P in ogni momento Operazioni di ingresso/uscita (join/leave) dalla rete Ridondanza delle informazioni Valeria Cardellini - SDCC 2014/15 26 Applicazioni P2P Distribuzione e memorizzazione di contenuti Contenuti: file, video streaming, Reti, protocolli e client per file sharing ( killer application del P2P): Gnutella, FastTrack, edonkey, BitTorrent, Kademlia, LimeWire, emule, imesh, utorrent, P2P TV (video streaming di canali TV in real time): PPLive, File storage: Freenet, OceanStore, Condivisione di risorse di calcolo (elaborazione distribuita) Es.: SETI@home: Search for Extraterrestrial Intelligence Es.: Folding@home: Protein folding Collaborazione e comunicazione Es.: Chat/IRC, Instant Messaging, XMPP Telefonia Es.: Skype Content Delivery Network Es.: CoralCDN Piattaforme di sviluppo per applicazioni P2P Es:. JXTA Valeria Cardellini - SDCC 2014/15 27

15 Fundamental challenges in P2P computing Heterogeneity in peer resources Hardware heterogeneity: too many models with different architectures Software heterogeneity: OS and software environment differences Network heterogeneity: different network connections and protocols Scalability System scaling related to performance and bandwidth Location Data location, data locality, network proximity, and interoperability Fault tolerance Failure management and load balancing Valeria Cardellini - SDCC 2014/15 28 Fundamental challenges in P2P computing (2) Performance Routing efficiency, self-organization, applications Free-riding avoidance Free-riders: peers that are selfish and unwilling to contribute anything Anonymity and privacy Onion routing for anonymous communications Trust and reputation management Lack of trust among peers who are strangers to each other Network threats and defense against attacks Churn resilience Peers come, leave and even fail at random Valeria Cardellini - SDCC 2014/15 29

16 Operazioni principali per un nodo P2P Consideriamo un applicazione di file sharing Un nodo del sistema P2P svolge le seguenti operazioni di base: Bootstrap: è la fase di ingresso nella rete P2P Soluzioni possibili: configurazione statica, cache preesistenti, nodi well-known Lookup di risorse: come localizzare le risorse in una rete P2P? Retrieval della risorsa localizzata Focalizziamo l attenzione sul lookup delle risorse Valeria Cardellini - SDCC 2014/15 30 Overlay network Overlay network: rete virtuale che interconnette i peer Basata su una rete fisica sottostante I nodi sono costituiti dai processi I collegamenti rappresentano i possibili canali di comunicazione Fornisce un servizio di localizzazione delle risorse Instradamento a livello applicativo Valeria Cardellini - SDCC 2014/15 31

17 Overlay routing Idea di base: Il sistema fa trovare il percorso per raggiungere una risorsa Rispetto al routing tradizionale Risorsa: no indirizzo di nodo della rete, ma file, CPU disponibile, spazio libero su disco, Concentriamo l attenzione sul routing, non sull interazione tra peer per recuperare una risorsa Il recupero avviene tipicamente con un interazione diretta tra peer, ad es. usando HTTP Valeria Cardellini - SDCC 2014/15 32 Tasks of overlay network Besides routing of requests to resources, an overlay network must also perform: Insertion of resources Deletion of resources Node addition and removal How to identify resources? Globally Unique IDentifier (GUID), usually derived as a secure hash (e.g., SHA-1) from some of all of the resource s state Types of overlay networks: Unstructured overlay networks Structured overlay networks Valeria Cardellini - SDCC 2014/15 33

18 Unstructured overlay networks Always built on random graphs Nodes select their neighbors randomly from all the peers in the network We examine three types of random graphs Erdos-Renyi model Small-world networks Scale-free networks Main properties of random graphs we consider Clustering coefficient of a vertex: fraction of edges that actually exist between the neighbors of that vertex and the maximum number of possible edges between those neighbors (if a vertex v has m v neighbors, at most m v (m v -1)/2) Clustering coefficient of a graph: the average clustering coefficient over all vertices Average shortest path length: shortest path between two vertices averaged over all pairs of vertices Valeria Cardellini - SDCC 2014/15 34 Random graphs models Erdos-Renyi random graph (classical random network) n: number of vertices (fixed) p: probability that two vertices have an edge deg(v): vertex degree Probability that a vertex v has degree k Vertex degree follows binomial distribution Mean vertex degree: (n-1)p Clustering coefficient: p Average shortest path: log(n)/log((n-1)p) Graph diameter: approx. log(n) Wrapping up: Short average shortest path length and low clustering coefficient But low clustering not observed in many real-world networks! Homogeneous network with an exponential tail Valeria Cardellini - SDCC 2014/15 35

19 Random graphs models (2) Other models for more (but not fully!) realistic graphs Some properties observed in real-world graphs (but not in Erdos-Renyi graphs): High clustering coefficient Presence of hubs (high-degree nodes), i.e., nonhomogeneous network Watts-Strogatz random graph (small-world network) Properties: Small average shortest path length High clustering coefficient, independent of the number of vertices Nodes are not neighbors of one another, but most nodes can be reached from every other by a small number of hops Example: social networks Limitation: does not account for the formation of hubs Valeria Cardellini - SDCC 2014/15 36 Random graphs models (3) Albert-Barabasi random graph (scale-free network) Vertex degree follows power law distribution P(deg(v) = k) ~ ck -γ where 2 < γ < 3 How do new nodes attach themselves to existing nodes? On the basis of preferential attachment The more connected a node is, the more likely it is to receive new links, e.g. think about social networks connecting people! There are a few hubs, but their number decreases exponentially (power law) Scale-free: graph diameter ~ ln (ln n) Many networks are conjectured to be scale-free (Internet, Web, social networks, power grids), but still controversial hypothesis in some cases hub Scale-free networks are highly resilient against faulty constituents: ideal interconnect also for cloud computing Valeria Cardellini - SDCC 2014/15 37

20 Unstructured overlay networks: characteristics Overlay created in ad-hoc manner Each node joins the network following some simple, local rule A joining node contacts a set of neighbors No overall control over the network topology or the placement of resources within the network Goal: to manage nodes with a highly dynamic behavior (high join/leave rates) Pros: insertion and deletions of nodes and resources are easily managed Cons: resource location is complicated by the lack of organization Unpredictable performance Examples: Gnutella, FastTrack, edonkey, Valeria Cardellini - SDCC 2014/15 38 Routing in reti non strutturate Classifichiamo le reti non strutturate in base al livello di distribuzione dell indice risorse-peer Sistemi P2P decentralizzati puri: flooding In alternativa gossiping (analizzato successivamente) Sistemi P2P centralizzati: directory centralizzata (es. Napster) Sistemi P2P ibridi: directory semi-centralizzate e flooding limitato ai supernodi Valeria Cardellini - SDCC 2014/15 39

21 Sistemi P2P centralizzati Un nodo centralizzato (directory server) possiede il mapping risorse-peer (index), fornendo un servizio di discovery dei peer e di ricerca delle risorse Limiti Gestione costosa della directory centralizzata Collo di bottiglia costituito dal nodo centrale (scalabilità limitata) Single point of failure (motivi tecnici e legali, es. Napster) peers Napster server Index 1. File location request 2. List of peers offering the file 5. Index update 3. File request 4. File delivered Napster server Index Valeria Cardellini - SDCC 2014/15 40 Flooding Approccio completamente distribuito per localizzare le risorse Query di lookup inviate secondo il meccanismo di flooding (inondazione) Ogni peer propaga (flood) la richiesta ai peer vicini, che a loro volta inviano la richiesta ai loro vicini (escludendo il vicino da cui hanno ricevuto la richiesta) Fino a che la richiesta è risolta, oppure viene raggiunto un massimo numero di peer interrogati (definito da Time To Live o TTL) Ad ogni inoltro il TTL viene decrementato Il TTL limita il raggio della ricerca, evitando che il messaggio sia propagato all infinito ID univoco assegnato alla richiesta per evitare che venga nuovamente elaborata dai nodi da cui è stato già ricevuta (presenza di cicli nei grafi) Costo di lookup: O(N), con N numero di nodi della rete Valeria Cardellini - SDCC 2014/15 41

22 Flooding (2) Alternative per l invio della risposta alla query di lookup: Diretto: dal peer con risposta positiva al peer che ha originato la richiesta Basato sul backward routing Backward routing La risposta positiva viene inoltrata a ritroso lungo lo stesso cammino seguito dalla query Si usa il GUID per individuare il backward path Quali vantaggi rispetto all invio diretto? Valeria Cardellini - SDCC 2014/15 42 Example of flooding Valeria Cardellini - SDCC 2014/15 43

23 Problemi del flooding Crescita esponenziale del numero di messaggi Possibilità di attacchi di tipo denial-of-service Nodi black-hole in caso di congestione Non è realistico esplorare tutta la rete Costo della ricerca Le risposte dovrebbero avere tempi ragionevoli Come determinare il raggio di ampiezza del flooding (ovvero il TTL)? Non è garantito che vengano interrogati (tutti) i nodi che posseggono la risorsa Traffico di query Messaggi senza risultato occupano comunque banda Mancanza di relazione tra topologia di rete virtuale e fisica Quanto sono distanti i peer vicini? Valeria Cardellini - SDCC 2014/15 44 Reti strutturate Costruzione della rete overlay basata su algoritmi deterministici Vincoli sulla topologia del grafo e sul posizionamento delle risorse sui nodi del grafo Organizzazione della rete secondo principi rigidi Esempi di topologia: anello, albero, ipercubo Reti basate su Distributed Hash Table (DHT) Obiettivo: migliorare la localizzazione delle risorse, minimizzando il numero di messaggi inviati Svantaggio: aggiunta o rimozione di nodi sono operazioni costose Esempi: Chord, Pastry, CAN, Kademlia, Valeria Cardellini - SDCC 2014/15 45

24 Routing in reti strutturate Basato su Distributed Hash Table (DHT) nella stragrande maggioranza dei casi Ad ogni peer è assegnato un GUID da uno spazio di identificatori grande; ogni peer conosce alcuni peer Ad ogni risorsa condivisa viene assegnato un GUID (dallo stesso spazio di identificatori usato per i peer), definito applicando alla risorsa una funzione hash Per instradare la richiesta per una risorsa verso il peer associato, occorre mappare univocamente il GUID della risorsa nel GUID di un peer in base a una metrica di distanza Richiesta instradata verso il peer con GUID più vicino a quello della risorsa Possibile copia della risorsa in ogni peer attraversato Valeria Cardellini - SDCC 2014/15 46 Distributed Hash Table Astrazione distribuita della struttura dati hash table Una risorsa è rappresentata dalla coppia chiave-valore (key K, value V) K identifica la risorsa (contenuta in V): corrisponde al GUID API per l accesso alla DHT (comune a molti sistemi basati su DHT) put(k, V): inserisce la risorsa (memorizza V in tutti i nodi responsabili per la risorsa identificata da K) remove(k): cancella tutti i riferimenti a K e all associato V V = get(k): recupera V associato a K da uno dei nodi responsabili put(k, V) Distributed application get(k) Distributed hash table node node. node Valeria Cardellini - SDCC 2014/15 47 V

25 Distributed Hash Table (2) Occorre mappare univocamente la chiave di una risorsa nel GUID del nodo più vicino Identificatore a m bit (solitamente m=128 o 160) Le risorse vengono mappate nello stesso spazio di indirizzamento dei nodi mediante una funzione di hash Ad es. la funzione crittografica di hash SHA-1 Ogni nodo è responsabile di una parte di risorse memorizzate nella DHT Ad ogni nodo viene assegnata una porzione contigua dello spazio di identificatori Ogni nodo memorizza informazioni relative alle risorse mappate sulla propria porzione di identificatori Ogni chiave viene mappata su almeno un nodo della rete Replicazione per migliorare la disponibilità Valeria Cardellini - SDCC 2014/15 48 Difficoltà nelle DHT Poiché ogni risorsa è identificata solo mediante il valore della chiave, per cercare una risorsa occorre conoscere il valore della chiave E semplice effettuare query di ricerca di tipo exactmatch, ad es. basate sul nome della risorsa E più difficile e costoso supportare query più complesse Ad es. query con wildcard, range query, Valeria Cardellini - SDCC 2014/15 49

26 Reti basate su DHT Caratterizzate da elevata scalabilità rispetto alla dimensione (numero di nodi) Diverse proposte di sistemi P2P basati su DHT In cosa differisco? Nella definizione dello spazio di identificatori (e quindi la topologia della rete) e nella selezione dei peer con cui comunicare (ovvero la metrica di distanza) Più di 20 protocolli ed implementazioni per reti P2P strutturate, tra cui: Chord (MIT) Pastry (Rice Univ., Microsoft) Tapestry (Berkeley Univ.) CAN (Berkeley Univ.) Kademlia (NY Univ.) Chimera (UCSB) SkipNet (Washington Univ, Microsoft) Valeria Cardellini - SDCC 2014/15 50 Chord pdos.csail.mit.edu/chord Algoritmo per il lookup in reti P2P I nodi e le chiavi delle risorse sono mappati in un anello mediante una funzione di hash detta consistent hashing Ogni nodo è responsabile delle chiavi poste tra sé e il nodo precedente nell anello La risorsa con chiave k è mappata nel nodo con il più piccolo identificatore id k Questo nodo è detto succ(k), successore della chiave k Ad es. succ(1)=1, succ(10)=12 Metrica di distanza: basata sulla differenza lineare tra gli identificatori Valeria Cardellini - SDCC 2014/15 51

27 Consistent hashing A special kind of hashing Both items and buckets are uniformly distributed and in the same identifier space (the same circle) using a standard hash function Integral to the robustness and performance of Chord In case of hash table resizing (adding or removing a bucket): the mapping of items to buckets does not significantly change Practical impact: nodes can join and leave the network with minimal disruption All buckets get roughly same number of items: load balancing Original devised by Karger et al. at MIT for distributed caching Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the World Wide Web Some details and Java implementation Largely used: for example, Amazon Dynamo s partitioning scheme relies on consistent hashing to distribute the load across multiple storage hosts Valeria Cardellini - SDCC 2014/15 52 Finger table in Chord Finger table (FT) Tabella di routing posseduta da ogni nodo Se FT p è la FT del nodo p, allora FT p [i] = succ(p + 2 i-1 ) mod 2 m, 1 i m succ(p+1), succ(p+2), succ(p+4), succ(p+8), succ(p+16), Dimensione della FT pari a m, con m = # bit GUID Idea della finger table Ogni nodo conosce bene le posizioni vicine ed ha un idea approssimata delle posizioni più lontane 000 Nell esempio m=3 FT 0 [1]=0+2 0 =1 FT 0 [2]=0+2 1 =2 FT 0 [3]=0+2 2 = Valeria Cardellini - SDCC 2014/

28 Algoritmo di routing in Chord Come risolvere la chiave k nell identificatore di succ(k) a partire dal nodo p (algoritmo di routing): Se k è nella zona di competenza di p, la ricerca termina Altrimenti, p inoltra la richiesta al nodo q con indice j in FT p q = FT p [j] k < FT p [j+1] q è il nodo più lontano da p la cui chiave viene prima della (o è uguale alla) chiave k Caratteristiche Raggiunge velocemente le vicinanze del punto cercato, per procedere poi con salti via via più piccoli Costo di lookup: O(log(N)), con N numero dei nodi Valeria Cardellini - SDCC 2014/15 54 Esempio di routing in Chord Il nodo 1 risolve la chiave 26 Il nodo 28 risolve la chiave 12 Nell esempio: m=5 Quindi chiavi da 0 a Valeria Cardellini - SDCC 2014/15 55

29 Ingresso e uscita di nodi in Chord Ogni nodo mantiene anche il puntatore al predecessore per semplificare le operazioni di join e leave Al join nell overlay network, il nodo p: Contatta un nodo arbitrario a cui chiede la ricerca di succ(p+1) Si inserisce nell anello Inizializza la sua FT chiedendo succ(p + 2 i-1 ), 2 i m Aggiorna la FT del nodo che lo precede sull anello Trasferisce dal suo successore su se stesso le chiavi di cui è responsabile Alla leave dall overlay network, il nodo p: Trasferisce al suo successore le chiavi di cui è responsabile Aggiorna nel nodo che lo precede il puntatore al nodo che lo segue sull anello Aggiorna nel nodo che lo segue il puntatore al nodo che lo precede sull anello Costo di join/leave: O(log 2 N) Valeria Cardellini - SDCC 2014/15 56 Riassumendo: caratteristiche di Chord Vantaggi Bilanciamento del carico Chord distribuisce uniformemente le chiavi fra i nodi Scalabilità Le operazioni di lookup sono efficienti: O(log(N)) Robustezza Problemi Chord aggiorna periodicamente le finger table dei nodi per riflettere i mutamenti della rete (nodi che entrano o escono) Manca una nozione di prossimità fisica Supporto costoso per ricerche senza matching esatto Altre proposte di reti P2P strutturate per risolvere tali problemi Valeria Cardellini - SDCC 2014/15 57

30 Pastry Fornisce un substrato per applicazioni P2P Sviluppato da Microsoft Research e Rice University Alcune applicazioni: Scribe (multicast), SQUIRREL (caching coooperativo), PAST (storage) Basato su Plaxton routing Meccanismo per la diffusione efficiente di risorse su una rete, pubblicato nel 1997 (precede P2P!) Idea di base: la risorsa A è memorizzata sul nodo con ID che presenta il prefisso più lungo in comune con A Prefix matching routing: basato sul confronto tra prefisso del nodo prefisso della risorsa In realtà, Pastry usa una soluzione più complessa: ogni nodo mantiene anche un leaf set (i nodi a lui più vicini nello spazio bidirezionale degli ID) Anche Tapestry e Kademlia si basano su Plaxton routing Valeria Cardellini - SDCC 2014/15 58 Pastry (2) Come in Chord, GUID dei nodi e delle risorse sono mappati su un anello Chiavi (GUID) rappresentate con d simboli da b bit ciascuno (in genere b=4) Ogni nodo possiede: Tabella di routing Leaf set: L peer più vicini al nodo sull anello in entrambe le direzioni (L/2 - e L/2 + ) Neighborhood list: M peer più vicini in base alla metrica di distanza (non usata per il routing) Routing basato su longest prefix matching Ad ogni passo del routing, si inoltra la ricerca verso il nodo con ID via via più vicino a quello della risorsa cercata Es: ***8 **98 * Costo del routing: in media meno di "log 2 N# passi Valeria Cardellini - SDCC 2014/15 59

31 Plaxton routing Esempio: chiave con b=2 e d=4 chiave di 8 bit Di solito chiavi molto più lunghe (128 bit) Regole di composizione della tabella di routing Gli ID dei nodi sulla riga n-esima condividono le stesse prime n cifre con l ID del nodo corrente La (n+1)-esima cifra degli ID sulla riga n-esima è il numero di colonna Ad ogni elemento della tabella possono corrispondere più nodi Si sceglie il nodo più vicino in base ad una metrica di prossimità (ad es. RTT) Tabella di routing del nodo (0)212 - (2)311 (3)121 1(0)31 1(1)23-1(3)12 12(0)0 12(1)1-12(3)1-122(1) 122(2) 122(3) "log 2 b N# righe nella tabella 2 b -1 elementi in ogni riga Valeria Cardellini - SDCC 2014/15 60 Plaxton routing (2) Query di lookup inoltrata in base al meccanismo di longest prefix matching Verso il nodo che condivide col nodo di destinazione almeno una cifra in più del nodo corrente Se non esiste, al nodo numericamente più vicino Nodo 1220 Routing 0321 Routing 1106 Routing 1201 Routing 1221 (0)212 - (2)311 (3)121 1(0)31 1(1)23-1(3)12 12(0)0 12(1)1-12(3)1-122(1) 122(2) 122(3) Valeria Cardellini - SDCC 2014/15 61

32 Esempio di routing in Pastry Consideriamo uno spazio degli ID di 2 18, ! Attenzione: nell esempio suffix routing (anziché prefix routing) Quanti hop? Meno di "log 2b N# Valeria Cardellini - SDCC 2014/15 62 Hybrid architectures We will study some examples of hybrid architectures Client/server combined with P2P Examples: P2P systems with superpeers Edge-server architectures used for Content Delivery Network BitTorrent: once a node has identified where to download a file from, it joins a swarm of downloaders who in parallel get file chunks from the source, but also distribute these chunks amongst each other. Valeria Cardellini - SDCC 2014/15 63

33 Architettura sw di un SD Basata su SO di rete Il SO di rete fornisce i servizi di comunicazione E compito dello sviluppatore dell applicazione distribuita mascherare le differenze delle piattaforme Basata su middleware Il middleware fornisce i servizi di comunicazione, coordinazione e gestione, mascherando l eterogeneità Valeria Cardellini - SDCC 2014/15 64 Middleware Alcune definizioni: Insieme di servizi per gestire la complessità e l eterogeneità presenti nei SD Strato software in mezzo sopra al sistema operativo, ma sotto le applicazioni fornisce un astrazione di programmazione distribuita (un modello computazionale uniforme) per mascherare alcune eterogeneità degli elementi sottostanti (reti, hw, sistemi operativi, linguaggi di programmazione,...) Software che fornisce servizi che consentono ai vari componenti di SD di comunicare e gestire dati Riferimento: W. Emmerich, Software Engineering and Middleware: A Roadmap, FOSE Valeria Cardellini - SDCC 2014/15 65

34 Middleware (2) Servizio general-purpose che si colloca tra piattaforme e applicazioni (P. Bernstein, 1996) Esempi di middleware: RPC, Java RMI, CORBA, Java EE,.NET, Web Services, Enterprise Service Bus (ESB) Valeria Cardellini - SDCC 2014/15 66 Tipi di middleware Varie tipologie di middleware; consideriamo una possibile classificazione non esaustiva correlata agli stili architetturali esaminati Piattaforme più recenti di middleware offrono soluzioni ibride Object-oriented middleware Evoluzione di RPC: i componenti distribuiti sono oggetti (con identità, interfaccia, incapsulamento) Spesso protocolli sincroni di richiesta/risposta Esempi: Java RMI, CORBA Message-oriented middleware (MOM) Scambio asincrono di messaggi Può offrire elevata flessibilità ed affidabilità Molte implementazioni basate su sistema a code di messaggi Esempi: Apache ActiveMQ, IBM WebSphere MQ, JBoss HornetQ, JORAM (implementazione di JMS), Oracle WebLogic Valeria Cardellini - SDCC 2014/15 67

35 Tipi di middleware (2) Middleware per componenti Evoluzione dell object-oriented middleware Sia comunicazione sincrona che asincrona I componenti vivono in contenitori (application server), che sono in grado di gestire la configurazione e la distribuzione dei componenti e fornire ad essi funzionalità di supporto Esempi: Java EE,.NET, JBoss Middleware orientato ai servizi Enfasi sull interoperabilità tra componenti eterogenei, sulla base di protocolli standard aperti ed universalmente accettati Generalità dei meccanismi di comunicazione (sia sincroni che asincroni) Flessibilità nell organizzazione degli elementi (servizi) Web services, Grid services Esempi: Apache Axis2, Apache CFX, Globus Toolkit Valeria Cardellini - SDCC 2014/15 68 Architetture e middleware In molti casi il middleware segue uno specifico stile architetturale Ad es. architettura basata su oggetti e object-oriented middleware Tale approccio architetturale al middleware offre Semplicità progettuale ma scarsa adattabilità e flessibilità E preferibile un middleware che si possa adattare dinamicamente all applicazione specifica e all ambiente (adaptive and reflective middleware) Ancora meglio, è preferibile un sistema software in grado di adattare il proprio funzionamento rispetto a se stesso e all ambiente " sistemi autonomici Domanda per sistemi autonomici in continuo aumento (mobile computing, ubiquitous computing, fog computing, ) Ad es.: contesto dell utente, del dispositivo, dell ambiente Valeria Cardellini - SDCC 2014/15 69

36 Sistemi autonomici Autonomic Computing: paradigma in grado di rispondere all esigenza di gestire la crescente complessità ed eterogeneità dei sistemi IT complessi mediante adattamenti automatici Ispirato dal sistema nervoso umano, in grado di controllare alcune funzioni vitali (battito cardiaco, temperatura, ) mascherandone la complessità all uomo Un sistema autonomico dovrebbe essere in grado di: gestire le proprie funzionalità autonomamente (ovvero senza o con limitato intervento umano) esprimendo capacità di adattamento (comportamenti reattivi e proattivi) a dinamiche interne ed esterne, più in generale ai cambiamenti dell ambiente Valeria Cardellini - SDCC 2014/15 70 Obiettivi di un sistema autonomico Un sistema autonomico, a fronte di determinate politiche impostate dall amministratore, è in grado di auto-gestirsi, perseguendo come obiettivi: Self-configuring Capacità di auto-configurarsi Self-healing Capacità di sopravvivere a guasti (ad es. malfunzionamenti hw) Self-optimizing Capacità di ottimizzare le proprie prestazioni Self-protecting Capacità di proteggersi da attacchi esterni Complessivamente: essere un sistema self-* Riferimento: J.O. Kephart, D.M. Chess, The vision of Autonomic Computing, IEEE Computer, 36(1), Jan Valeria Cardellini - SDCC 2014/15 71

37 Come raggiungere gli obiettivi? Il sistema deve conoscere il suo stato interno (selfawareness) e le attuali condizioni operative esterne (self-situation) Il sistema deve individuare cambiamenti riguardanti il suo stato e l ambiente circostante (self-monitoring) e di conseguenza deve adattarsi (self-adjustement) Questi attributi sono i meccanismi implementativi Valeria Cardellini - SDCC 2014/15 72 Sistemi di controllo in retroazione In molti casi, i sistemi self-* sono organizzati come sistemi di controllo in retroazione Componente per la stima della metrica Misura il comportamento del sistema Componente di analisi Analizzare le misure e le confronta con dei valori di riferimento E il cuore del ciclo di controllo, poiché contiene gli algoritmi che decidono gli eventuali adattamenti Meccanismi per influenzare il comportamento del sistema Organizzazione logica di un sistema di controllo in retroazione (l organizzazione fisica può essere molto diversa: i vari componenti possono essere distribuiti) Valeria Cardellini - SDCC 2014/15 73

38 Reference architecture: MAPE MAPE-K (Monitor, Analyze, Plan, Execute) control loop Source: Kephart & Chess, The Vision of Autonomic Computing, IEEE Computer, Valeria Cardellini - SDCC 2014/15 74 Reference architecture: MAPE (2) Tasks of the architectural building blocks Valeria Cardellini - SDCC 2014/15 75

39 Example 1: Provisioning of cloud resources Autonomic provisioning of virtual machines in Cloud systems To determine how many virtual machines to allocate in order to satisfy SLA when the request load changes System components Mapping of component on SaaS and IaaS providers Source: E. Casalicchio, L. Silvestri, Architectures for autonomic service management in cloud-based systems, Valeria Cardellini - SDCC 2014/15 76 Example 2: Two-level cloud controller Automatic resource management based on two levels of controllers, one for the service provider and one for the application Application controllers and cloud controllers work in concert Application 1 SLA 1. SLA n Application n Application 1 VM VM. Application n VM VM Application controller. Application controller Monitor Monitor Decision. Decision Cloud Controller Actuator Actuator Cloud Platform Source: D. Marinescu, Cloud Computing: Theory and Practice, Morgan Kaufmann, Valeria Cardellini - SDCC 2014/15 77

40 Example 3: Coordinating power and performance management Autonomous performance and power managers cooperate to ensure SLA performance and energy optimization They are fed with performance and power data and implement the performance and power management policies Communication between autonomous managers Performance manager Power manager Control policy Performance data Power data Control policy Blade Blade Workload generator Workload distribution Blade Blade Power assignment Power Blade Source: D. Marinescu, Cloud Computing: Theory and Practice, Morgan Kaufmann, Valeria Cardellini - SDCC 2014/15 78