Introduzione. Laurea magistrale in ingegneria informatica A.A Leonardo Querzoni. Versioni al tratto. Versione 3D

Transcript

1 Introduzione Versioni al tratto Versione 3D Sistemi La versione negativa Distribuiti 3D prevede l utilizzo dell ombra esclusivamente sul fondo colore Rosso Sapienza. Laurea magistrale in ingegneria informatica A.A Elementi Base. Marchio/Logo Versione negativa 3D e al tratto La versione negativa del Marchio/Logo deve essere adottata su fondo scuro. Sono da preferire i fondi Rosso Sapienza, il nero o un colore tra quelli della gamma istituzionale. Manuale di Identità Visiva Sapienza Università di Roma Leonardo Querzoni

2 Informazioni sul corso Sito web del corso: Orari: Lun 14:00-15:30 B2 Mar 14:00-15:30 B2 Gio 12:00-13:30 B2 Ricevimento: Martedì 15:30-17:30 ufficio B208 Altri giorni/orari su appuntamento: 2

3 Informazioni sul corso Libro di testo: C. Cachin, R. Guerraoui and L. Rodrigues. Introduction to Reliable and Secure Distributed Programming Springer, 2011 Slide disponibili sul sito web del corso Esame: Singola prova scritta con 5 esercizi. NON è possibile integrare il voto con una prova orale. È possibile ripetere la prova se il voto non vi soddisfa. Quando consegnate una nuova prova, ogni voto acquisito precedentemente viene perso. 3

4 Avviso Borse di studio EMC2 per laureati triennali iscritti al primo anno di magistrale: 1 borsa per Ing. Informatica 1 borsa per Ing. delle Comunicazioni 2 borse per le lauree magistrali della facoltà I3S riservate a studentesse Scadenza 2/3/2012 Informazioni su: 4

5 Introduzione ai sistemi distribuiti Fino all inizio degli anni 80 l uso di quasi tutte le applicazioni era confinato al singolo calcolatore. Questo è vero anche oggi per applicazioni di uso comune (fogli di calcolo, word processors, etc.) L uso di una rete di comunicazione cambia la filosofia di progettazione delle applicazioni: World Wide Web Trasferimento dati tra calcolatori remoti etc. 5

6 Introduzione ai sistemi distribuiti Ma cos è un sistema distribuito? Un sistema distribuito è un insieme di computer indipendenti che appare ai propri utenti come un singolo sistema coerente. o anche Un sistema distribuito è un insieme di calcolatori che coordinano le loro azioni attraverso lo scambio di messaggi su una rete di comunicazione. e infine A distributed system is one in which the failure of a computer you did not even know existed can render your own computer unusable (Leslie Lamport) 6

7 Introduzione ai sistemi distribuiti Le applicazioni che fanno uso della rete sono soggette a problemi specifici: Internet 7

8 Introduzione ai sistemi distribuiti Obiettivi di un sistema distribuito: Accessibilità Trasparenza Apertura Scalabilità Problemi tipici di un sistema distribuito: Concorrenza Distanza geografica Guasti Sicurezza Eterogeneità 8

9 Introduzione ai sistemi distribuiti Accessibilità Uno degli obiettivi fondamentali di un sistema distribuito è permettere l accesso degli utenti a risorse remote. Motivazioni: Economiche Maggiore facilità di collaborazione Problemi: Sicurezza Concorrenza 9

10 Introduzione ai sistemi distribuiti Trasparenza Un sistema distribuito in grado di presentarsi agli utenti ed alle applicazioni come un singolo computer è detto trasparente. Tipi di trasparenza: Accesso - Indipendenza dalla piattaforma utilizzata e dalla specifica rappresentazione dei dati scambiati Ubicazione - Indipendenza dalla posizione geografica Migrazione - Possibilità di spostare le risorse quando non avvengono accessi Replicazione - Indipendenza dal numero di copie presenti per la specifica risorsa 10

11 Introduzione ai sistemi distribuiti Trasparenza Un sistema distribuito in grado di presentarsi agli utenti ed alle applicazioni come un singolo computer è detto trasparente. Tipi di trasparenza: Concorrenza - Indipendenza dal numero di accessi contemporanei alla risorsa Guasto - Indipendenza dai possibili malfunzionamenti del sistema La completa trasparenza non sempre è possibile La completa trasparenza non sempre è desiderabile 11

12 Introduzione ai sistemi distribuiti Apertura Capacità di un sistema distribuito di essere esteso e reimplementato (anche parzialmente) Condizioni che favoriscono l apertura di un sistema: Documentazione estesa Specifica dei servizi offerti e delle interfacce relative Formalizzazione dei protocolli Aderenza agli standard 12

13 Introduzione ai sistemi distribuiti Apertura La specifica dei servizi deve essere Completa: viene specificato tutto ciò che è necessario sapere per implementare il servizio Non ambigua: una specifica deve poter essere interpretata in un singolo modo Neutrale: la specifica non può imporre scelte relative alla implementazione Conseguenze di una specifica completa, non ambigua e neutrale: Interoperabilità Portabilità 13

14 Introduzione ai sistemi distribuiti Scalabilità Capacità di un sistema distribuito di sopportare la crescita di diversi fattori: Dimensione del sistema stesso - numero di utenti e/o risorse Carico - numero di operazioni eseguite sul sistema Distanza geografica Amministrazione - numero di domini di amministrazione diversi/indipendenza delle macchine 14

15 Introduzione ai sistemi distribuiti Scalabilità La scalabilità può essere raggiunta usando algoritmi distribuiti: nessun elemento del sistema ha informazioni complete sullo stato di tutto il sistema ogni elemento del sistema prende decisioni solo basandosi su informazioni locali il malfunzionamento di un elemento del sistema non riduce la funzionalità del sistema la perdita di un messaggio scambiato tra due elementi del sistema non riduce la funzionalità del sistema ogni elemento basa il suo funzionamento su un orologio locale non sincronizzato con gli altri 15

16 Introduzione ai sistemi distribuiti Nella progettazione di un sistema distribuito non bisogna dare per scontate i seguenti punti: La rete di comunicazione è affidabile La rete di comunicazione è sicura La rete di comunicazione è omogenea La topologia di interconnessione non cambia La latenza di comunicazione è zero L ampiezza di banda è infinita Il costo di trasporto dei dati è zero C è un unico amministratore 16

17 Piattaforme middleware Realizzare applicazioni distribuite è spesso molto complesso. Per questo si ricorre a software detti middleware: Appl. A Appl. B Appl. C Middleware SO locale SO locale SO locale SO locale Rete Il middleware offre primitive di comunicazione, sincronizzazione, coordinamento, localizzazione, accesso trasparente, etc. per la realizzazione di applicazioni distribuite complesse. 17

18 Piattaforme middleware Una piattaforma middleware è costituita da un insieme di: architetture protocolli algoritmi componenti software interfacce e loro specifiche... La realizzazione di una piattaforma middleware richiede la risoluzione dei problemi precedentemente esposti. 18

19 Architetture per middleware Un middleware distribuito è costituito da un insieme di componenti software che dialogano. Si pongono due problemi durante la fase di progettazione: come organizzare i componenti software e come connetterli stile architetturale dove posizionare i componenti software e come collegare le macchine tra loro architettura di sistema Queste due scelte hanno un forte impatto sulla complessità degli algoritmi implementabili, sui costi del sistema, sulla sua estendibilità, sulle prestazioni, etc. 19

20 Stili architetturali Uno degli stili più noti è quello che definisce le layered architectures. Ogni strato software interagisce Livello N Livello N-1 solo con lo strato superiore e con quello inferiore. Largamente impiegato nell ambito della progettazione dei protocolli di rete, ma talvolta poco flessibile. Livello 2 Livello 1 20

21 Stili architetturali Nelle architetture ad oggetti i componenti software interagiscono attraverso delle chiamate a procedura remota (RPC/RMI). Ogni componente rappresenta un vero e proprio oggetto dotato di proprietà e metodi usabili per modificarlo. Obj D Obj A Obj E Obj C Obj B 21

22 Stili architetturali Nelle data-centric architectures i componenti interagiscono esclusivamente attraverso uno spazio di dati a cui possono accedere. Questo spazio può rappresentare una memoria distribuita o un file system condiviso. I dati vengono letti e scritti dai vari componenti come se fossero presenti Comp A leggi Comp B scrivi localmente. Spazio dei dati condivisi 22

23 Stili architetturali Nelle event-driven architectures i componenti producono e consumano eventi in modo disaccoppiato. Un bus applicativo comune si occupa di instradare gli eventi tra i vari componenti. Ogni componente viene Comp A notifica evento Comp B sottoscrivi notificato solo degli bus applicativo eventi a cui è effettivamente interessato. pubblica Comp C 23

24 Architetture di sistema Il metodo più ovvio per organizzare una applicazione distribuita è di centralizzare l elaborazione su un singolo nodo che serve le richieste ricevute dall esterno. Questo tipo di organizzazione, detta anche client/ server è la più semplice da gestire. E basata su un modello di interazione domada / risposta. 24

25 Architetture di sistema Nel tempo l organizzazione delle applicazioni basare su questa architettura è cambiata stratificandosi. I diversi livelli possono essere suddivisi in modo diverso tra client e server. 25

26 Architetture di sistema È possibile introdurre ulteriori livelli di suddivisione ed ottenere architetture client/server multilivello. 26

27 Architetture di sistema Le architetture client/server multilivello realizzano una distribuzione verticale dei ruoli e delle funzionalità. Distribuendo orizzontalmente i componenti si ottengono architetture peer-to-peer. In queste architetture componenti distinti giocano lo stesso ruolo e sono considerati paritetici. L organizzazione tra i componenti che definiscono un architettura peer-to-peer è detta overlay network 27