ARCHITETTURE DISTRIBUITE e SERVIZI di RETE motivazioni

Transcript

ARCHITETTURE DISTRIBUITE e
SERVIZI di RETE
Sistemi Distribuiti
MOTIVAZIONI
tecnologiche ed economiche
(Local Area Network LAN Wide Area Network WAN)
DEFINIZIONE
Insieme di sistemi distinti per località che
comunicano e cooperano per
consentire servizi coordinati e risultati congiunti
INFOS
motivazioni tradizionali
introducono la possibilità di
- accedere a risorse remote
- condividere risorse remote come locali
COMMS
SISTEMI di ENORMI DIMENSIONI e MOLTE
RISORSE
TRASPARENZA della ALLOCAZIONE
QUALITÀ dei SERVIZI (QoS)
garantire modalità e proprietà
DINAMICITÀ del SISTEMA
aggiungere risorse al sistema aperto
seri problemi teorici (COMPLESSITÀ)
-..
affidabilità
per tollerare guasti dependability
accessibilità e condivisione delle risorse
adeguamento alle richieste distribuite
domande distribuite (prenotazioni aeree)
eterogeneità degli accessi
Concorrenza: moltissime attività (processi) possono essere
in esecuzione
Nessun tempo globale: non è possibile una perfetta
sincronizzazione degli orologi di un sistema distribuito
uniformità in crescita e scalabilità
indipendenza dal numero dei nodi del sistema
Fallimenti indipendenti: molte cause di fallimento, crash di
macchine e possibili problemi di rete.
Una macchina isolata dalla rete potrebbe peraltro continuare
computazione ...
Architetture Distribuite e Servizi di Rete – Modelli C/S
apertura del sistema
capacità di evoluzione secondo necessità
1
2
PROBLEMI della distribuzione
Progetto di un programma (applicazione)
eterogeneità
varietà di hardware, reti, protocolli, sistemi operativi,
linguaggi di programmazione, implementazioni fatte
da diversi programmatori
complessità intrinseca
sistemi più complessi da specificare e risolvere
sicurezza (security)
più difficile garantire integrità e correttezza
sbilanciamenti nell'uso delle risorse
necessità di sfruttare in modo giusto le risorse
capacità di esecuzione totale limitata
inferiore a quella di un mainframe equivalente
Applicazione
Problema
Architettura
Algoritmo
codifica
mapping
binding
Tecnologia
Linguaggio
di Alto Livello
Aree di interesse
• previsioni meteorologiche
• dinamica molecolare
• modelli biologici
• evoluzione di sistemi spaziali
• sistemi globali (Internet, Web, ...)
PROGRAMMAZIONE
Algoritmo ==> in un linguaggio di alto livello
(più linguaggi)
- calcolo scientifico ed ingegneristico
- progetto automatico VLSI
- operazioni database
- intelligenza artificiale
obiettivi a breve e lungo termine
- sistemi distribuiti ad amplissimo raggio
accesso ad informazioni globalmente distribuite
Sistema Operativo
3
MAPPING
- decisioni di allocazione per l'architettura scelta
configurazione a risorse e località
BINDING di processi e oggetti
- decisione di aggancio di ogni entità del programma
sulle risorse del sistema
GESTIONE STATICA
il binding differito alla esecuzione ==> NECESSITÀ di
GESTIONE DINAMICA del BINDING e delle RISORSE
4
Tipica architettura MIMD
Multiple Instruction Multiple Data (MIMD)
Ambiente di programmazione
Interfaccia grafica
Strumenti debugging
Compilatori
Strumenti di allocazione
Necessità di controllo della soluzione
Strumenti di ambiente
Nodo
processore collegato alla memoria privata
anche organizzata a livelli
Nodo
Linguaggio di programmazione
Linguaggio
Processore
Processore
MM
Controllo di Qualità di Servizio
Monitoraggio sistema
Bilanciamento del carico
Supporto al routing
Supporto run-time al parallelismo
Nodo
PP
MM
PP
Cache
Processore
Memoria
Processore
Architettura parallela
Insieme di nodi
Rete interconnessione
Rete
Rete didi
Interconnessione
Interconnessione
Nodo
Nodo
PP
MM
PP
MM
Nodo
PP
MM
Un ambiente di programmazione tende a ottenere
Reti di workstation
Calcolatori indipendenti connessi da una rete locale
(LAN)
trasparenza e indipendenza dalla architettura
(portabilità su nuove architetture)
astrazione
(nascondere complessità parallelismo)
corretta gestione delle risorse (statica e dinamica)
NON esistono ancora ambienti di programmazione
soddisfacenti e completamente trasparenti
LAN
In ogni caso, soluzione ==>
uso diretto di funzioni dinamiche, con visibilità della
architettura - tipo primitive di KERNEL
Rete di workstation
problemi di portabilità
5
6
ETEROGENEITÀ E APERTURA
LOCALITÀ DISTINTE
i più comuni sistemi aperti sono i
Sistemi Eterogenei
PROBLEMI intrinseci alla distribuzione
costituiti da
processori e interconnessioni
per la rete fissa
terminali diversissimi
per la rete fissa e mobile
creazione e gestione di risorse globali
sistemi di supporto (sistemi operativi) diversi
per workstation, per personal,
per dispositivi limitati (LAPtop, PDA, telefonini)
complessità intrinseca
sistemi più complessi da specificare e risolvere
sicurezza (security)
più difficile garantire integrità e correttezza
sbilanciamenti nell'uso delle risorse
necessità di sfruttare in modo giusto le risorse
applicazioni e servizi differenziati
forniti a clienti molto diversi
capacità di esecuzione totale limitata
inferiore a quella di un mainframe equivalente
utenti con competenze diversissime
progettisti, esperti, medi, scarsi di conoscenze
Legge di Grosh
migliore bilancio costo/performance
con un monoprocessore mainframe
(senza problemi di memoria e I/O)
proprietà di apertura va oltre
APERTURA di un SISTEMA distribuito
☺ capacità di adattamento alle condizioni di stato
successive alla messa in opera senza blocchi
necessità di identificare (monitor) e controllare
(gestione) lo stato del sistema
non esiste un sistema aperto in assoluto, ma solo
in relazione a una specificata esigenza
ovviamente con i limiti alla potenza di calcolo
- velocità della luce
- costi elevati aumentando l'integrazione
NOTA - la distribuzione delle risorse è
sempre più
un vincolo di tutte le architetture disponibili
un assunto necessario per le risorse più comuni
Se il sistema è aperto si devono potere cambiare
alcune parti o strategie durante la esecuzione
(senza dovere fermare il servizio e ripartire da zero
con una nuova esecuzione)
7
8
Sistemi di rete e Servizi
MODELLO CLIENTE/SERVITORE
Spesso i sistemi sono solo sistemi di rete in cui le
potenzialità non sono sfruttate
Il modello Client/Server mette in gioco due entità:
l’entità Client richiede il servizio
l’entità Server offre il servizio
Scenario di un servizio Web
Informazioni presentate in modo trasparente
ELABORAZIONE
FORM
INPUT UTENTE
Nodo C
OUTPUT
Processo
Client
elemento
...
richiesta servizio
...
< attesa risposta >
...
ricezione risposta
...
abcdef
VISIONE LOCALE
RETE
applicazioni esterne
applicazioni di supporto
richiesta
risposta
il modello Client/Server C/S risolve il problema del
coordinamento o sincronizzazione (quando e come
sincronizzare i processi comunicanti) definendo il
Server come un processo sempre in attesa di richieste
di servizio
Si semplifica in questo modo il protocollo di
comunicazione sottostante che non deve
occuparsi di attivare un processo alla ricezione di
un messaggio
HTTP
server
CGI
sistema locale
utente
TCP / IP
Processo
Server
...
< attesa richiesta >
ricezione rich. serv.
...
< servizio >
...
invio risposta
...
tipico caso di invocazione procedurale:
il cliente aspetta il completamento del servizio
attuato dal servitore
NODI REMOTI
HTTP
client
Nodo S
sistema remoto
TCP / IP
rete
DINAMICITÀ
Se cominciamo a replicare i dati e memorizzare le
informazioni su siti intermedi => evoluzione
9
10
È un modello di comunicazione asimmetrica, molti:1
Il Cliente designa esplicitamente il destinatario
Il Servitore non esprime il nome del processo con cui
desidera comunicare
Se mettiamo in gioco due processi:
potremmo anche avere schemi diversi
Nodo A
Processo
Client 1
Se il cliente non vuole bloccarsi in attesa
CICLO di richieste ad intervallo (polling)
che deve essere o esaudita subito
o restituire un insuccesso
Nodo S
Processo
Server
Questo modo carica il cliente della responsabilità
dell'ottenere le informazioni
modello pull
Nodo Z
Processo
Client N
Si potrebbe anche risolvere in modo diverso, dividendo
le responsabilità
il cliente segnala il proprio interesse, poi fa altro
è compito del server di inviare la informazione
se e quando disponibile
il Server deve accedere alle risorse del sistema
considerando i problemi di:
autenticazione utenti
autorizzazione all’accesso
integrità dei dati
privacy delle informazioni
e deve gestire richieste contemporanee da molti Client
(server concorrenti)
Questa interazione divide i compiti tra cliente e servitore
modello push (per il servitore)
che forza le informazioni rovesciando i ruoli
Maggiore complessità di progetto dei Server rispetto ai
Client.
Se il cliente ha bisogno di una informazione la richiede
=> in genere aspetta fino a quando non è disponibile
(sincronizzazione con la risposta)
11
MOLTE MODALITÀ DIVERSE ED ETEROGENEITÀ
12
MODELLO DI STATO DEL SERVITORE
Due tipi principali di interazioni:
L’interazione tra un Client e un Server di due tipi
stateful, cioè si mantiene lo stato dell’interazione
e un messaggio e la operazione conseguente può
dipendere da quelli precedenti
stateless, non si tiene traccia dello stato, ogni
messaggio è completamente indipendente dagli
altri
Lo stato dell’interazione usualmente memorizzato nel
Server (che può essere stateless o stateful)
• interazione connection-oriented
si stabilisce un canale di comunicazione virtuale
prima di iniziare lo scambio dei dati (es.
connessione telefonica)
• interazione connectionless
non c’è connessione virtuale, ma semplice
scambio di messaggi isolati tra loro (es. il sistema
postale)
Un Server stateful garantisce efficienza
(dimensioni messaggi più contenute e migliore
velocità di risposta del Server)
Un Server stateless è più affidabile in presenza di
malfunzionamenti (soprattutto causati dalla rete)
Il Server stateful deve poter identificare il Client
Per esempio, si consideri le differenze tra un file server
stateless e stateful (NFS di SUN è stateless)
La scelta tra le due forme dipende dal tipo di
applicazione e anche da vincoli imposti dal livello di
comunicazione sottostante
Per esempio, in Internet il livello di trasporto prevede i
protocolli TCP e UDP
La scelta tra server stateless o stateful deve tenere in
conto anche dell’applicazione
Un’interazione stateless è possibile SOLO se il
protocollo applicativo è progettato con operazioni
idempotenti
• TCP con connessione, reliable (affidabile) e
preserva l’ordine di invio dei messaggi
maggiore Qualità del Servizio
• UDP senza connessione, non reliable e non
preserva ordine messaggi
Operazioni idempotenti producono sempre lo stesso
risultato, per esempio, un Server fornisce sempre la
stessa risposta a un messaggio M indipendentemente
da altri messaggi (anche M) ricevuti dal Server stesso
13
14
CONCORRENZA NEL SERVITORE
POSSIBILI SERVITORI
Lato Client
I Client sono programmi sequenziali, eventuali
invocazioni concorrenti supportate dal sistema
operativo multitasking
RIEPILOGO
Tipo di comunicazione
con connessione senza connessione
S iterativo
E
R concorrente
singolo
singolo
processo
V
processo
E
concorrente
RTipo di multi
Server
Lato Server
La concorrenza è cruciale per migliorare le prestazioni
di un Server
Un Server iterativo processa le richieste di servizio
una alla volta
Possibile basso utilizzo delle risorse, in quanto non
c’è sovrapposizione tra elaborazione ed I/O
concorrente
multi
processo
processo
Un Server concorrente può gestire molte richieste di
servizio concorrentemente, cioè una richiesta può
essere accettata anche prima del termine di quella (o
quelle) attualmente in corso di servizio
Migliori prestazioni ottenute da sovrapposizione
elaborazione ed I/O
Maggiore complessità progettuale
Si pensi ad un Web server che deve rispondere a
moltissime richieste contemporaneamente
La scelta del tipo
di Server dipende
dalle caratteristiche
del servizio da fornire
Vari tipi di Server
dipende dal tipo di protocollo e
dalla tecnologia realizzativa della esecuzione
e della comunicazione tra cliente e servitore
servizio sequenziale vs concorrente
servizio con vs senza connessione
servizio con vs senza stato
Per esempio, in Unix è facile realizzare un Server
concorrente generando un processo nuovo (fork)
per ogni richiesta di servizio (server concorrente
multi processo)
15
16
PROGETTO DI CLIENTI E SERVITORI
Modelli di SERVIZIO
Come si distribuisce la logica applicativa tra i Client e i
Server?
servizio sequenziale
il servitore considera le richieste una alla volta
ritardi nel servizio stesso ai clienti
servizio concorrente
il servitore serve più richieste insieme
maggiore complessità progettuale del server
NON è necessario il parallelismo nel server
In genere il server prevede un progetto complesso e il
client deve essere più snello
Fat Client vs. Thin Client
servizio senza connessione
(ad esempio usando UDP)
costo basso, ma si devono realizzare ordinamenti
e reliability
servizio con connessione
(ad esempio usando TCP)
costo superiore della realizzazione
Considerazioni di configurazione del sistema, di carico
sul server, di traffico di rete
Server
Presentation
(GUI)
Presentationlogic
logic
(GUI)
Application
Applicationlogic
logic
Database
Databaselogic
logic
servizio senza stato (stateless server)
il servitore considera le richieste e le dimentica
appena fornite
problemi nella gestione di richieste replicate
senza rieseguire il servizio
servizio con stato (stateful server)
il servitore tiene traccia dello stato di interazione dei
servizi con i clienti
maggiore complessità progettuale del server
NON facile decidere lo stato in concorrenza
Thin Client
Client
17
Fat Client
Client
Server
Presentation
(GUI)
Presentationlogic
logic
(GUI)
Application
Applicationlogic
logic
Databaselogic
Databaselogic
18
SISTEMI MULTI TIER
Un sistema C/S può essere anche decomposto in parti
(3-tier C/S), per distribuire il carico di lavoro di un
Server su diverse macchine
MODELLO astratto
interazione sincrona
Si possono anche avere molti nodi diveris che si
incaricano di svolgere funzioni molto diverse e sono
separate nel sistema per ragioni diverse
schemi più complessi
clienti / servitori multipli
- 1 solo servizio per ogni richiesta
(stampa di un file)
- 1 servizio da ogni possibile servitore
(aggiorna copie di un file)
Server
Server
Presentation logic (GUI)
Presentation logic (GUI)
Necessità di coordinamento tra i servitori
con Replicazione o Suddivisione
Application logic
Application logic
Database logic
Database logic
Socket, RPC, HTTP
asincrona / non bloccante
I servizi sono forniti da più servitori (molti:molti)
con diverse possibilità
di bilanciamento di carico
di limiti di esecuzione
di disponibilità e tolleranza ai guasti
di vicinanza geografica
Client
(default)
SQL
importanza di stabilire il numero di operazioni che
si vogliono ottenere
modello di comunicazione
• 1 sola stampa
• aggiornamento di tutte le copie
(e attesa del completamento di tutte le operazioni)
schema di base cliente servitore
I servizi sono forniti da un servitore che
risponde a diversi clienti (molti:1)
- i clienti conoscono il servitore
- il servitore rappresenta la astrazione dei servizi e
non conosce i possibili clienti
(O ATTESA PARZIALE)
19
20
SCHEMA CLIENTI E AGENTI MULTIPLI
SCHEMI A CLIENTI AGENTI/SERVITORI
MULTIPLI
I servizi sono forniti dal coordinamento di più servitori
che forniscono un servizio globale unico
modello two tier
CLIENTE
clienti
AGENTI / SERVITORI e RISORSE
servitori
agenti
gli agenti forniscono il servizio e possono:
- partizionare le capacità di servizio
- replicare le funzionalità di servizio
in modo trasparente al cliente
CLIENTE
AGENTI
cliente
risorse
entità
richiesta di servizio
AGENTI
anche paralleli e capaci di coordinarsi
SERVITORI
anche paralleli replicati e coordinati
PROTOCOLLI
di coordinamento, sincronizzazione, rilevazione e
tolleranza ai guasti
agenti
servizio coordinato
Mail
sistema B
Posta
Due livelli di coordinamento nell'accesso alle risorse
da parte dei clienti
modello three tier
MTA
UA
MTA
sistema A
MTA
MODELLI a LIVELLI MULTIPLI
per la divisione dei compiti
confinando il lavoro sul livello meno congestionato
schemi di comunicazione a multicast/broadcast
UA
sistema C
21
22
RIUSO dell'esistente e dei COMPONENTI
Framework, librerie di componenti
modello cliente/servitore
I modelli non prevedono stato della connessione per
il servitore
NESSUNO STATO nel SERVER (stateless)
LIBRERIE
Un insieme di librerie costituisce un set di funzioni
(interfaccia nota) che possono essere chiamate da un
livello che le usa
Concetto di STATO della interazione
STATO PERMANENTE della interazione
? mantenuto dal cliente o dal servitore
STATO SOFT nel SERVER
(mantenuto solo per un tempo predeterminato)
-
-
Applicazione
Servitore che tiene traccia dei clienti
servitore con stato
Servitore che tiene traccia della storia della
interazione con ogni cliente
servitore con stato partizionato: una
partizione per ogni sessione di interazione
Servitore che conosce i clienti
uso di una lista per la autorizzazione
Servitore che consente interazione tra i clienti
servitore con stato e interazione mutua tra i
clienti attraverso i servizi
Servitori coordinati con interazione tra i clienti
coordinamento dei servitori con stato
interazione mutua tra clienti e servitori
ADT
matematiche
Database
GUI
3D rendering
internet
Librerie (anche OO)
Ogni applicazione si deve uniformare a questa
struttura
In caso di più applicazioni, ogni applicazione deve
replicare la stessa organizzazione
• Giochi di simulazione distribuita (MOO)
• Prenotazione aerei
• Navigazione in Web
• mantenere stato su Web
e la consistenza delle copie replicate?
internet
Main LOOP
Le librerie sono ad aggancio dinamico (DLL)
Dynamic Linked Libraries
non SONO SVILUPPATE insieme con i programmi
utilizzatori
23
24
FRAMEWORK
MODELLO ad EVENTI
in contrapposizione ad un modello sincrono di richiesta
e di attesa della risposta
Un FRAMEWORK costituisce un modello di esecuzione
ed un ambiente di richiesta di funzionalità più integrato
tende:
• a non replicare la struttura implicita
• a rovesciare il controllo (per eventi di sistema)
vedi Windows struttura a loop di attesa di eventi
che vengono smistati ai richiedenti
si gestisce la possibilità di inviare messaggi su
necessità disaccoppiando gli interessati
• I consumatori eseguono le attività
• I produttori segnalano le necessità
• Il gestore degli eventi segnala l'occorrenza degli
eventi significativi agli interessati
meccanismi di supporto della cornice
Servizio di Notifica Eventi
Classi esistenti
3D rendering
produce quotazione
GUI
internet
LOOP
matematiche
logica specifica
SISTEMA gestore
dell'offerta degli eventi
BACKCALL
della applicazione
ADTs
CONSUMATORE
PRODUTTORE
gestione
eventi
PRODUTTORE
di sistema
Database
produce quotazione
Funzioni e servizi
CONSUMATORE
consuma offerta
push dell'evento alle entità interessate e registrate
Vedi la maggior parte dei sistemi a finestre
Sono possibili backcall o upcall (push del framework)
dal Framework alle applicazioni
eventi asincroni
consuma offerta
25
26
MODELLI a DELEGAZIONE
MODELLI a CONTENIMENTO
in contrapposizione ad un modello C/S
in contrapposizione ad un modello C/S
per ragioni di trasparenza
si lascia la possibilità di delegare una funzionalità ad
una diversa entità che opera al posto della principale
ad esempio, di svolgere una funzione per noi
entità PROXY, DELEGATE, AGENTI, ATTORI
un server lascia ad aspettare una risposta ad una
operazione una altra entità che lavora in modo push per
fornire la risposta al server stesso
Servizio di Delega e Notifica
si lasciano molte funzionalità come responsabilità ad
una entità responsabile (contenitore) che se ne
occupa, spesso introducendo politiche di default,
evitando che si verifichino errori ...
entità CONTENITORI, CONTAINER, ENGINE, ...
ad esempio attuando azioni necessarie
ad esempio introducendo nuove azioni
ad esempio consentendo politiche diverse senza che
il cliente (e a volte il servitore) se ne accorgano
invia richiesta, con delega a un proxy
Un servizio potrebbe essere integrato in un ambiente
(middleware) che si occupa di aspetti diversi (vedi
CORBA, framework a finestre, servlet, ecc.)
richiedente
A
C
SISTEMA che svolge
la operazione
CONTAINER
Richieste
PROXY
B
il proxy invia la risposta al richiedente
ad esempio usando eventi locali
Cliente 1
OPERAZIONI VARIE
Cliente 2
La notifica avviene usando eventi come nei
framework
che si interpongono tra utenti e basso livello e
gestiscono il sistema in tutti i suoi dettagli
Vedi la maggior parte dei sistemi a finestre
OPERAZIONE
SEMPLIFICATA
Cliente i
Cliente i
Cliente i
27
28
modelli preventivi/reattivi
PROCESSI
modelli ottimisti e pessimisti
si usa il termine processo per indicare una
entità dinamica che concentra capacità di esecuzione
Esempi
Programma: entità statica rappresentata da un file (su
disco) che specifica il codice e i dati su cui si deve
eseguire per produrre un risultato
il problema della interferenza/congestione
- ring previene la congestione con regole precise di
controllo di accesso
- CSMA/CD tenta l'accesso senza controllo e deve
tenere conto della interferenza possibile, con
opportune strategie
I primi sono approcci
I secondi sono approcci
Processo: entità dinamica che associa ad un
programma tutte le risorse necessarie alla esecuzione
(processore, disco, file, memoria, stack, heap,
comunicazione, ...)
pessimisti/preventivi
ottimisti/reattivi
Possiamo quindi avere molti processi che fanno
riferimento allo stesso programma, anche sulla stessa
macchina in esecuzione contemporaneamente
Naturalmente, in genere
i sistemi preventivi sono statici per l'aspetto
considerato
i sistemi reattivi sono dinamici
CONCORRENZA vs PARALLELISMO
Processi concorrenti (che usano la stesso processore)
Processi paralleli (che usano processori diversi)
modelli STATICI
modelli DINAMICI
concorrenza è uno dei modi per ottenere un buon uso
delle risorse: se un processo si ferma (ad esempio, un
processo cliente aspetta una risposta), il processore
può eseguire altri processi
VEDI ANCHE IL CASO DEI PROCESSI
Coda dei processi pronti ad eseguire e
scheduling dei processi sul processore
29
30
SOLUZIONE
Possibilità di creare entità più leggere
con limiti precisi di visibilità e barriere di
condivisione
PROCESSI
Processi differenziati
Processi leggeri
Thread 1
Stack Thread 2
Thread 3
Processo pesante
Stack /Heap
Processi leggeri
attività che condividono visibilità tra di loro e
che sono caratterizzata da uno stato limitato
overhead limitato
Dati
Dati
Thread 1
Codice
Codice
ad esempio in UNIX, i thread o
lightweight process
Thread 2
Thread 3
Quale contenitore unico si può considerare per la
visibilità dei thread?
In genere, un processo pesante
che contiene più processi leggeri
modello dei processi
processi pesanti/processi leggeri
Processo
IMPLEMENTATIVAMENTE
Tutti i sistemi vanno nel senso di offrire
granularità differenziate per ottenere
un servizio migliore e più adatto ai requisiti dell'utente
SPAZIO di indirizzamento
SPAZIO di esecuzione
insieme di codice, dati (statici e dinamici),
parte di supporto, cioè di interazione con il
sistema operativo (file system, shell, socket,
etc.) e per la comunicazione
Si useranno processi pesanti quando è il caso e
processi leggeri se si vuole avere un overhead più
limitato
Il processo pesante funziona anche da
contenitore di processi leggeri
un'aggregazione di parecchi componenti
Processo pesante ad esempio in UNIX
cambiamento di contesto operazione molto pesante
overhead
31
In caso di mobilità, si deve considerare cosa muovere
e se siamo facilitati nel farlo
32
Caso 1: Server sequenziale o iterativo
Caso 2: Server concorrente
più richieste alla volta
una richiesta alla volta (con connessione o meno)
I tempi di risposta al servizio aumentano ==>
servizi brevi
1a) server sequenziale senza connessione servizi
senza stato (che introduce ritardi) e non soggetti a
guasti
unica coda
C1
risposta sulla
2a) SERVER PARALLELO:
uso di processi multipli, un master server
generazione di processi interni per ogni servizio
massimo parallelismo per servizi non interferenti
Si deve garantire che il costo di generazione del
processo non ecceda il guadagno ottenuto
Processo
Server
Controllore
porta cliente
Cn
Azioni
#portaserver
1b) server sequenziale con connessione
servizi con requisiti di reliability
limitando lo stato (uso di TCP)
difficile realizzazione pratica
overhead delle azioni di controllo della connessione
C1
#portac1
unica coda iniziale
Soluzione con processi creati in precedenza
che consentano di essere velocemente smistati al
servizio necessario
numero prefissato di processi iniziali e altri
creati su necessità e mantenuti per un certo
intervallo
2b) Un unico server, che gestisce la concorrenza
servizi devono condividere lo stato
uso di asincronismi interni
Processo
Server
Controllore
risposta sulla
porta cliente
#portaserver
Cn
Azioni
unica connessione stabilita
C1
#portac1
#portaserver
con connessione
più processi, generati dal server per i servizi
contemporanei
senza connessione
più processi ciascuno con una porta privata del
cliente
33
34
2a) Server parallelo senza connessione
C1
Processo
Server
Controllore
Cn
#portaserver
#portan
Porte differenziate
C1
2b)
SERVER concorrente non parallelo
in caso di connessione e stato (limitati)
realizzato con un unico processo che produce effetti di
concorrenza
#porta1
l'unico processo master deve considerare tutte le
richieste ed servirle al meglio (mantenendo le
connessioni)
generazione
processo
#porta1
Azioni
Facciamo il caso di connessione (ma anche senza)
Ci
Cn
#portan
C1
Processi Client attivi
#porta1
richieste
iniziali
Processi Server
Cn
#portan
C1
connessione
2a) Server parallelo con connessione
#portaserver
Azioni
C1
Processo
Server
Controllore
Processo
Server
Controllore
Processo
Server
Controllore
Ci
connessione
Cn
Cn
Processi Client in attesa
Unico Processo Server
C1
Azioni
Connessioni
Ci
Cn
Processi Server
Necessità di rispondere in modo veloce alle richieste
successive e sollecitazioni
Un canale unico e un processo per ogni servizio
35
36
altri modelli di comunicazione
Tuple
pipeline, farm, etc.
Astrazione della memoria condivisa +
comunicazione
Lo spazio delle tuple è un insieme strutturato di
relazioni, intese come attributi e valori
Operazioni di scrittura e lettura concorrenti
Accesso in base al contenuto degli attributi
pattern di interconnessione concorrenti
publish-suscribe
Pipeline
Stage1
Stage2
Operazioni di In e Out
Su uno spazio di tuple si possono depositare / estrarre
informazioni di alto livello senza possibilità di causare
interferenze
Out inserisce una tupla nello spazio
In estrae una tupla, se esiste
attende nel caso la tupla non sia ancora presente
==> una tupla con alcuni attributi non specificati
Stage3
Insieme di entità che comunicano in modo ordinato:
uscita di uno stage è l'ingresso del successivo
Ogni stage lavora sui dati elaborati dal precedente
Possibilità di concorrenza nei servizi
di richieste diverse
Aumento del throughput (efficienza)
throughput
esempio: Una possibile relazione potrebbe essere:
messaggio (dachi, achi, corpo)
Lo spazio serve da contenitore per valori di tuple in
accordo al pattern specificato (ai tipi degli attributi, qui
stringhe ASCII)
Tuple possibili per lo spazio messaggio:
{Antonio, Giovanni, msg1}
{Giovanni, Antonio, msg1}
{Antonio, Giovanni, msg2} …
numero di servizi per unità di tempo
Farm
suddivisione del lavoro
Slave1
Master
SlaveI ...
SlaveN
Out:
In:
con attese diverse degli slave da parte del master
37
messaggio (P, Q, testo1)
messaggio (?, Q, ?)
38
altri modelli di comunicazione
SPAZI di TUPLE
tuple meccanismo generale
per la comunicazione e sincronizzazione
Linda (Gelertner)
realizzazione della memoria condivisa a confronto con
lo scambio di messaggi
Non ci sono limiti alle tuple che si possono depositare e
che possono rimanere nello spazio delle tuple senza
limiti di tempo o di memoria
Portano a comunicazione disaccoppiata
poco sincronizzata e compresente
In tempo
Un processo potrebbe lasciare tuple in un sistema
e solo molto dopo i consumatori potrebbero
arrivare a prelevare le tuple stesse
In conoscenza reciproca
i consumatori non devono conoscere in alcun
modo i processi produttori e non possono
interferire (una operazione estrae una tuple,
eventuali altre aspettano)
In qualità - QoS
Gli spazi delle tuple sono persistenti e tendono a
mantenere le tuple depositate senza limiti di
memoria (come requisiti) senza introdurre
interferenza tra processi
Spazi di tuple sono messi a disposizione per favorire
comunicazioni ben fatte di alto livello
Javaspaces, …
39
Pari (peer-to-peer)
le entità in gioco sono tutte pari e possono prendere
l’iniziativa secondo necessità e senza ruoli predefiniti
(es. Napster)
Publish/Subscribe
Da una parte una serie di utenti (consumatori)
specificano il proprio interesse ad
alcuni eventi (subscribe)
Dall’altra, un gestore (produttore) registra
le loro richieste e notifica gli
eventi ai consumatori (es. mailing list)
Cliente 1
Cliente 2
Subscribe
LAN
Notifica
Subscribe
Subscribe
Notifica
Cliente 3
Servitore
di Notifica
Notifica
40
MODELLO di interconnessione
modello di interconnessione
concetto di località (limiti alla comunicazione)
vs. globalità (nessun vincolo)
a connessione/ senza connessione
CONNESSIONE
le entità stabiliscono di preallocare le risorse per la
comunicazione (statico)
modelli globali
non impongono restrizioni alle interazioni
entità
risorse
statiche
dedicate
comunicazione
operazioni non scalabili
dipendenti dal diametro del sistema
SENZA CONNESSIONE
le entità comunicano utilizzando le risorse che sono
disponibili al momento della azione (dinamico)
modelli locali (RISTRETTI)
prevedono una limitazione alla interazione
entità
comunicazione
località
routing
dinamico
operazioni (forse) scalabili
poco dipendenti dal diametro del sistema
Alcuni modelli, detti a connessione (TCP), non
impegnano risorse intermedie
Vedremo questi comportamenti meglio più avanti...
verso la località, i domini, i vincoli
per la scalabilità
41
42
STATO DELL'ARTE
Anziché
usare kernel monolitici (vedi UNIX)
e che si accettano in blocco (o meno)
e che pesano sulle performance
STATO DELL'ARTE
esaminando i sistemi operativi
dal concentrato verso il distribuito
UNIX rappresenta un modello di conformità
per caratteristiche di accesso ai file
per possibilità di concorrenza
per possibilità di comunicazione
I sistemi operativi general-purpose tendono a fornire
soluzioni ispirate o analoghe. Si pensi a:
•
evoluzioni che fanno ancora i conti con le proprietà
di UNIX (vedi anche Linux)
•
Microsoft Windows NT che introduce processi e
controllo di accesso
rinforzato da
OPEN SOURCE e FREE SOFTWARE
UNIX rappresenta un limite
per caratteristiche di concorrenza
processi pesanti
I sistemi operativi evoluti preservano la compatibilità
con migliori prestazione per la gestione delle risorse
per i processi (leggeri) e per la distribuzione delle
risorse (processi e dati)
Le politiche sono realizzate al disopra in spazio utente
I microkernel non sono sviluppati solo
da ambienti tipo UNIX, ma anche come modello
per ambienti tipo Windows
in cui l'accento è
sulle interfacce grafiche,
sulla interazione visuale, etc.
In ogni caso, anche gli approcci proprietari devono
tenere e tengono in conto di questa evoluzione
Inoltre si cercano standard per la eterogeneità
•
Object-Oriented
CORBA
•
Linguaggio Java
Uso di microkernel
realizzazioni minimali del supporto di un S.O.
le politiche specificate al disopra del kernel
a livello applicativo
a livello utente processi applicativi e di sistema
☺
apertura a nuove strategie (generalità)
costi superiori delle strategie realizzate
(rispetto a soluzione ad-hoc)
I microkernel contengono il supporto per i processi e
per le comunicazioni tra processi
43
44
Approcci ad ambienti aperti
possibilità di avere un ambiente aperto per superare la
eterogeneità delle diverse piattaforme anche durante
la esecuzione senza fare ripartire il sistema
Il primo aspetto richiede un ambiente standard
ANSA, DCE, OSF, etc.
Il secondo aspetto richiede un ambiente interpretato
linguaggi script
tipo Shell, TCL/Tk, Perl, Python
Java legato allo scenario Web
Java si basa su un interprete e una macchina virtuale
che supporta e produce la esecuzione
Applet
e
Applicazioni Java
Estensione di Classi di Java
Classi Base
Java Virtual Machine
Interfaccia di portabilità
Adattatore
Browser
S.O.
Adattatore
Browser
S.O.
Adattatore
Browser
S.O.
Adattatore
Browser
S.O.
Hw
Hw
Hw
Hw
Interconnessione via Rete
Java consente una facile integrazione con le
informazioni Web attraverso applet e la facile
integrabilità
Inoltre, comincia ad avere strumenti per il supporto di
molte funzionalità
nuove versioni di Java
nuove proprietà e alcune incompatibilità
45

ARCHITETTURE DISTRIBUITE e SERVIZI di RETE motivazioni

Transcript

Documenti analoghi

IL “PATRIMONIO” DI DATI E LE BASI DI DATI

Algoritmi ed architetture per la risoluzione di problemi di visual search

sarah becchio_cv - studioerrante architetture

Sistemi e Reti

READ MORE

Metodo di stima del moto in una sequenza video mediante

STAGE INGEGNERE ELETTRONICO O INFORMATICO