Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 1
Sistemi Distribuiti
Corso di Laurea in Ingegneria
Prof. Paolo N...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 2
sommario
 Contesto tecnologico
 Architetture Parallele
 GRID...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 3
Il Contesto Tecnologico
Crescita delle risorse
 Il numero di t...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 4
Network Exponentials
 Network vs. computer performance
 Compu...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 5
Frieda’s Application …
Simulate the behavior of F(x,y,z) for 20...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 6
Non posso aspettare 3600 ore
 Potrei eseguire le 600 F(x,y,z) ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 7
sommario
 Contesto tecnologico
 Architetture Parallele
 GRID...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 8
Architetture Parallele
 La definizione di un’architettura otti...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 9
Esempio di caso Lineare
 VettC = VettA + VettB
 In modo seque...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 10
Esempio di caso 2D, (..nD)
 MatC = MatA + MatB
 In modo sequ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 11
Comunicazione fra processi
 In alcuni casi vi e’ la necessita...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 12
overhead
 Nel caso lineare Costo computazionale
 O(n)
 Nel ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 13
Soluzioni parallele diverse
nstella
ngerarchica nanello
nCompl...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 14
Soluzioni parallele diverse
nmesh
nMesh
nrichiusa
ncubo
niperc...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 15
Piramide detta anche grid
nGerarchica
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 16
3 Processori
in forma ciclica o consecutiva
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 17
8 Processori in
forma ciclica o consecutiva
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 18
Esempio di elaborazione locale spaziale
1 2 3
4 5 6
7 8 9
1 2 ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 19
 Comunicazione fra processi per congiungere dati parziali
 S...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 20
Speed Up
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 21
Speed Up
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 22
An example
quicksort
merge
quicksort
quicksort
quicksort
quick...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 23
Un Esperimento CONDOR at DISIT
15
140
667
535
2680
1800
0
400
...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 24
Scelte che hanno condizionato il risultato
 Non si è utilizza...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 25
Allocazione dei processi
 Caso 1, caso semplice ed immediato:...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 26
Problemi
 Parallelizzazione degli algoritmi
 Progettazione p...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 27
sommario
 Contesto tecnologico
 Architetture Parallele
 GRI...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 28
Grid vs Distributed and Parallel
Parallel
Computing
Distribute...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 29
The GRID
 “the Grid” term coined in the mid 1990s to denote a...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 30
GRID
service
Richiedente
(casa famaceutica,
simulazioni, etc.
...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 31
Per essere un GRID
• coordina risorse e fornisce meccanismi di...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 32
Scienze Data Intensive
 Fisica nucleare e delle alte energie
...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 33
BigData Science
 How to: compute, process, simulate, extract ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 34
sommario
 Contesto tecnologico
 Architetture Parallele
 GRI...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 35
Concetti Estesi del GRID
 Virtual Organization (VO) è costitu...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 36
U.S. PIs: Avery, Foster, Gardner, Newman, Szalay
www.ivdgl.org...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 37
PISA
NAPOLI
COSENZA
PERUGIA
PADOVA
GENOVA
LECCE
MILANO
PALERMO...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 38
Grid of Cluster computing
 GRID
 collezione di risorse distr...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 39
sommario
 Contesto tecnologico
 Architetture Parallele
 GRI...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 40
Applicazioni dei GRID
 Calcolo parallelo: sfruttamento di ris...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 41
Alcuni dettagli
 Profiling and personalization
Profilo del c...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 42
Types of Grid Computing
share access
to computing
resources
Co...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 43
Types of Grid Computing
 GRID Compute
 Per esempio ricerca d...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 44
The Systems Problem:
Resource Sharing Mechanisms That …
 Addr...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 45
Aspects of the Systems Problem
1) interoperability when differ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 46
Programming & Systems Problems
 The programming problem
 Fac...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 47
Problemi dei GRID
 condivisione delle risorse flessibile e si...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 48
sommario
 Contesto tecnologico
 Architetture Parallele
 GRI...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 49
GRID projects
 LEGION
 Middleware per la connessione di reti...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 50
Some GRID Solutions !!
 Condor
 Unix and windows
 Small sca...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 51
GLOBUS and its toolkit
 Open Source, Middleware
 http://www-...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 52
 Al Global Grid Forum (GGF4),
 Globus Project e IBM hanno de...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 53
Globus GRID Tool Kit
l Sicurezza (GSI)
l Gestione delle risors...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 54
Componenti di GLOBUS toolkit 1/2
 Grid Security Infrastructur...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 55
Componenti di GLOBUS toolkit 2/2
 Data Management
 GRIDFTP e...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 56
n56
Tre componenti principali
1. RSL (Resource Specification L...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 57
GRAM GRAM GRAM
LSF Condor PBS
Application
Resource Specificati...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 58
Combinazione Globus e Condor
n
 Globus
 Protocolli per comun...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 59
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 60
CONDOR
 Nasce nel 1988, University of Madison
 Creazione di ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 61
Salvataggio del contesto
 Per poter migrare il processo devo ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 62
CONDOR
 A basso livello si basa su procolli di comunicazione
...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 63
Sicurezza in CONDOR
 L’autenticazione di una comunicazione so...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 64
CONDOR architecture
Central Manager
Condor_Collector
Condor_Ne...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 65
CONDOR ruoli e servizi
 Central Manager, solo un Central Mana...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 66
CONDOR: Pregi e difetti
 Pregi:
 non necessita di modificare...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 67
sommario
 Contesto tecnologico
 Architetture Parallele
 GRI...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 68
AXMEDIS Content Processing GRID
 accesso dai dati
 trasforma...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 69
AXMEDIS Content Processing, GRID
CMSs
Crawlers
AXMEDIS
databas...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 70
Front end
servers,
VOD, prod
on demand
AXMEDIS Content Process...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 71
AXMEDIS Content Processing Area
l GRID infrastructure for
 au...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 72
Factory and integration
WEB Server
Playout Server
Web+Strm Ser...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 73
AXMEDIS Content Processing GRID
 GRID per il Content Processi...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 74
Snapshots of the GRID at work
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 75
AXCP processing capabilities
 Automating access to databases ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 76
AXCP processing capabilities
 Processing functionalities:
 G...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 77
AXMEDIS Content Processing GRID
AXMEDIS
Scheduler
AXMEDIS
Rule...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 78
AXMEDIS Content Processing Area:
AXCP Rule Editor
l It is an I...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 79
Rule Editor
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 80
Rule Editor
 The Rule Editor allows
 Writing AXCP Scripts in...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 81
AXMEDIS Content Processing Area: AXCP Rule
 AXCP Rules includ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 82
Regole AXCP, formalizzazione XML
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 83
AXCP visual designer
 Fast and simple Visual
Programming of A...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 84
Visual Designer
 Visual language for GRID
programming
 RuleB...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 85
Rule Scheduler
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 86
Rule Scheduler
 AXCP Rule Scheduler performs:
 executors dis...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 87
GRID Node
Profile
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 88
Log Properties
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 89
Esempio di esecuzione
var sb = new AXSearchbox();
sb.Host = "l...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 90
AXMEDIS CP GRID, technical view
WS for
Control and
Reporting
(...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 91
Realizzazione: Rule Engine
Scheduler
Esecutoreremoto
• Eng. Cm...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 92
Scheduler Command Manager
e Graphic User Interface
l Lo Schedu...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 93
GRID Gerarchico
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 94
Gestione Gerarchica di microGRID
 Ogni Scheduler identifica u...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 95
Internal Scheduler
l permette la scelta dei job da mandare in ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 96
Dispatcher
•riunisce le funzionalità di associazione, lancio
e...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 97
Evolution of Rule’s State
INACT
IVE
ACTI
VE
SUSPE
NDED
RUNNI
N...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 98
Scheduler GUI
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 99
Scheduler
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 100
Sfruttamento della CPU nei nodi
nIn Nero la % di CPU sfruttat...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 101
Planning and Exploiting Node capabilities
 GRID node has a p...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 102
Ottimizzazione della Pianificazione
Allocazione dei processi ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 103
Gantt diagram and jobs
nRes1
nRes2
nRes3
nRes4
nRes5
nJ20
nJ2...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 104
Pianificazione dei processi
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 105
Dipendenze
nPunti di sync ?
nPer la comunicazione ?
nConsumo ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 106
Gantt Diagrams (OPTAMS, TS)
Schedule cumulative for phase bef...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 107
Condor
JobMonitor
Screenshot
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 108
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 109
Per ogni processo al tempo Tx
 D: Durata prevista del proces...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 110
Pianificazione e Ripianificazione
Nell’ottica del controllo d...
5/17/2014 (C) Paolo Nesi-1995-2000 111
Esempio di
ottimizzazione
125 task, 2CAD, 2CAM,
4ADP, 6MM, 2MEMA
Ottimizzazione: 24...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 112
Confronto AG, TS
In letteratura le tecniche più utilizzate pe...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 114
Mosse operate sui task
O(1,1) O(2,2)
O(2,1) O(1,2)
O(1,3)
O(2...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 115
Funzionale di costo
F = KA*allocation-KB*biasDeadline+KD* d...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 116
Funzionali di costo
Funzionale Anticipa
scadenze
Riduce
sched...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 117
Andamento funzionali
F = KA*allocation-KB* biasDeadline+KD* ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 118
AXMEDIS CP GRID, technical view
WS for
Control and
Reporting
...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 119
Realizzazione: Grid Peer Interface e Grid Peer
l La Grid Peer...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 120
GRID Interface
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 121
AXCP GRID NODE
…
…
EXECUTOR MANAGER GRID PEER INTERFACE
SCRIP...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 122
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 123
sommario
 Contesto tecnologico
 Architetture Parallele
 GR...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 124
Applicazioni per microGRID
 Adattamento di contenuti
 E.g.:...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 125
Production On Demand
User and Device
profile
AXCP GRID
Activa...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 126
Apetti rilevanti
 Device che comunicano al server il loro pr...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 127
MPEG-21 DIA
MPEG-21 DID
Digital Item
Adaptation Engine
MPEG-2...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 128
MPEG-21 DIA model
Usage Environment Description Tools
• User ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 129
Profiling, MPEG-21 DIA
 The device/terminal capabilities inc...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 130
Adaptation of multimedia content
 Functionalities
 Allows c...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 131
Fingerprint and descriptors
 What is the Fingerprint
 It is...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 132
Fingerprint Features
 Features:
 Never included with the co...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 133
Usage of Fingerprint
 Then Content
Owners, may monitor
 dis...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 134
sommario
 Contesto tecnologico
 Architetture Parallele
 GR...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 135
Aspetti e caratteristiche di alto livello
 Portabilita’:
 S...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 136
GRID comparison 1
axmedis Condor Globus Legion Unicore
Descri...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 137
GRID comparison 2
AXMEDIS Condor Globus Legion Unicore
OGSA
C...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 138
GRID comparison 3
AXMEDIS Condor Globus Legion Unicore
Langua...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 139
Micro GRID for scalable media comput.
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 140
Comparison: Micro GRID for media
IEEE Multimedia 2012
AXMEDIS...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 141
micro grid
post production
protection, packing, licensing
Dig...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 142
Grid Project References
l Open Science Grid
 www.openscience...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 143
sommario
 Contesto tecnologico
 Architetture Parallele
 GR...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 144
Architetture MapReduce
 At the basis of Apache Hadoop soluti...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 145
Typical problems
 Large number of nodes in the clusters
 Re...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 146
Typical problems
 Hadoop has no security model, nor safeguar...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 147
Recovering from failure
 If some node fails in providing res...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 148
Hadoop data distribution
 Is based on the Hadoop Distributed...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 149
Processes vs Data
 Processes works on specific chunks of dat...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 150
MapReduce: Isolated Processes
 The main idea:
 Each individ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 151
Mappers and Reducers
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 152
How it works
 Programmer has to write the Mappers and the Re...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 153
Hadoop Flat Scalability
 Hadoop on a limited amount of data ...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 154
Releasing job
on Hadoop
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 155
An example of WordCount
 Mapper
map(key1, value1)  list(ke...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 156
Mapping input and ouput
 Document1:
 Queste sono le slide d...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 157
Reduce input
 reduce (key2, list (value2))  list(key3, valu...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 158
Reducer Output as ……
 inverted index (the previous example)
...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 159
pertanto
 Gli esempi sono due
 1) Conteggio delle parole ne...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 160
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 161
public static class MapClass extends MapReduceBase
implements...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 162
/*** A reducer class that just emits the sum of the input val...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 163
driver
public void run(String inputPath, String outputPath) t...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 164
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 165
Reducer
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 166
Esempio di elaborazione locale spaziale
1 2 3
4 5 6
7 8 9
 M...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 168
references P. Bellini, I. Bruno, D. Cenni, P. Nesi, "Micro g...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 169
For More Information
l Globus Project™
 www.globus.org
l Gri...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 170
Reference
 Yahoo tutorial
 https://developer.yahoo.com/h
ad...
Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 171
Sistemi Distribuiti
Corso di Laurea in Ingegneria
Prof. Paolo...
Upcoming SlideShare
Loading in …5
×

From parallel architecture to mapreduce hadoop passing on grid, UNIFI course

201 views
193 views

Published on

Contesto tecnologico
Architetture Parallele
GRID: definizione e motivazioni
Concetti estesi dei GRID, microgrid
Applicazioni e problemi dei GRID
Soluzioni GRID...Globus, Condor
Soluzioni MicroGRID: AXCP grid
Applicazioni per microGRID
Confronto fra GRID
Architetture MapReduce

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
201
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

From parallel architecture to mapreduce hadoop passing on grid, UNIFI course

  1. 1. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 1 Sistemi Distribuiti Corso di Laurea in Ingegneria Prof. Paolo Nesi 2014 Parte 6: Architetture Parallele, Sistemi GRID, big data computing, Map Reduce Dipartimento di Ingegneria dell’Informazione, University of Florence Via S. Marta 3, 50139, Firenze, Italy tel: +39-055-4796523, fax: +39-055-4796363 DISIT Lab http://www.disit.dinfo.unifi.it/ paolo.nesi@unifi.it
  2. 2. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 2 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  3. 3. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 3 Il Contesto Tecnologico Crescita delle risorse  Il numero di transistor raddoppia ogni 18 mesi (Legge di Moore)  La velocità dei computer raddoppia ogni 18 mesi  La densità di memoria raddoppia ogni 12 mesi  La velocità della rete raddoppia ogni 9 mesi Differenza = un ordine di grandezza ogni 5 anni Pertanto ogni anno che passa diventa piu’ conveniente usare delle soluzioni distribuite.
  4. 4. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 4 Network Exponentials  Network vs. computer performance  Computer speed doubles every 18 months  Network speed doubles every 9 months  Difference = one order of magnitude every 5 years  1986 to 2000  Computers: x 500  Networks: x 340,000  2001 to 2010  Computers: x 60  Networks: x 4000nMoore’s Law vs. storage improvements vs. optical improvements. Graph from Scientific American (Jan-2001) by Cleo Vilett, source Vined Khoslan, Kleiner, Caufield and Perkins.
  5. 5. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 5 Frieda’s Application … Simulate the behavior of F(x,y,z) for 20 values of x, 10 values of y and 3 values of z (20*10*3 = 600 combinations) F takes on the average 6 hours to compute on a “typical” workstation (total = 3600 hours) F requires a “moderate” (128MB) amount of memory F performs “moderate” I/O - (x,y,z) is 5 MB and F(x,y,z) is 50 MB Non posso aspettare 3600 ore
  6. 6. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 6 Non posso aspettare 3600 ore  Potrei eseguire le 600 F(x,y,z) su 600 calcolatori  Costo di comunicazione dei dati  Possibile se le 600 F(x,y,z) sono esecuzioni completamente indipendenti (come in questo caso),  dove ogni processo parte da dati che non dipendono dai risultati degli altri processi, delle altre esecuzioni
  7. 7. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 7 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  8. 8. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 8 Architetture Parallele  La definizione di un’architettura ottima in termini di processi paralleli per il calcolo scientifico dipende dal problema  Non confondiamo il Problema con la Soluzione  Vi sono problemi  intrinsecamente sequenziali  Lineari vettoriali  Multidimensionali vettoriali  Paralleli nei dati di ingresso  Paralleli nei dai di uscita  Paralleli nei servizi  Paralleli nella procedura  Etc..
  9. 9. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 9 Esempio di caso Lineare  VettC = VettA + VettB  In modo sequenziale il Costo e’ o(N), in parallelo il costo e’ 1  Soluzione parallela:  N nodi  Un concentratore per raccolta dati  Comunicazione fra nodi: assente  Comunicazione con il nodo concentratore ……………. 1. Passa A e B 2. Passa Ai, Bi 3. Calcola Ai+Bi 4. Passa Ci 5. Metti insieme C 6. Passa C 1 2 2 2 2 33 3 3 4 444 5 6
  10. 10. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 10 Esempio di caso 2D, (..nD)  MatC = MatA + MatB  In modo sequenziale il Costo e’ o(NM), in parallelo il costo e’ 1  Soluzione parallela:  N*M nodi  Un concentratore per raccolta dati  Comunicazione fra nodi: assente  Comunicazione con il nodo concentratore ……………. a. Passa A e B b. Passa Aij, Bij c. Calcola Aij+Bij d. Passa Cij e. Metti insieme C f. Passa C 1 2 2 2 2 33 3 3 4 444 5 6
  11. 11. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 11 Comunicazione fra processi  In alcuni casi vi e’ la necessita’ di effettuare connessioni/comunicazioni dirette fra modi dell’architettura parallela  Se queste comunicazioni possono essere eseguite in parallelo (contemporaneamente) si risparmia tempo rispetto a farle gestire tutte da un nodo centrale come in molti sistema di gestione di processi concorrenti  Un sistema di gestione di processi concorrenti dovrebbe  permettere di mappare in modo logico un’architettura parallella/concorrente qualsiasi sul’architettura fisica in termini di processori e calcolatori  Permettere ai nodi (processori) di comunicare chiamandosi in modo logico e non fisico  Permettere di identificazione in modo logico i nodi.
  12. 12. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 12 overhead  Nel caso lineare Costo computazionale  O(n)  Nel caso parallelo  Comunico Ai e Bi: O(n)+O(n)  Calcolo Ci: O(1)  Comunico Ci: O(n)  Quale delle due soluzioni e’ piu’ efficiente?  Dipende dai dati, da N, dal costo della comunicazione, etc.  Architetture specifiche (composizioni di processori con connessioni dedicate) possono produrre soluzioni efficaci per problemi specifici.
  13. 13. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 13 Soluzioni parallele diverse nstella ngerarchica nanello nCompletamente connessa
  14. 14. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 14 Soluzioni parallele diverse nmesh nMesh nrichiusa ncubo nipercubo
  15. 15. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 15 Piramide detta anche grid nGerarchica
  16. 16. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 16 3 Processori in forma ciclica o consecutiva
  17. 17. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 17 8 Processori in forma ciclica o consecutiva
  18. 18. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 18 Esempio di elaborazione locale spaziale 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 nMedia: ∑ n per stimarla per ogni punto della matrice: nProblemi al contorno nSovrapposizione dei dati
  19. 19. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 19  Comunicazione fra processi per congiungere dati parziali  Spesso necessarie per processi iterativi  Soluzioni di equazioni alle derivate parziali  Soluzioni agli elementi finiti  Inversioni di matrici a blocchi  Condizioni al contorno  Soluzioni di equazioni alle derivate parziali  Soluzioni agli elementi finiti  Integrazione del calcolo  Equazioni differenziali alle derivate parziali  Calcolo di Flussi  Calcolo per antenne Comunicazioni fra processi
  20. 20. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 20 Speed Up
  21. 21. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 21 Speed Up
  22. 22. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 22 An example quicksort merge quicksort quicksort quicksort quicksort quicksort quicksort quicksort merge merge merge merge merge merge File ordinato
  23. 23. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 23 Un Esperimento CONDOR at DISIT 15 140 667 535 2680 1800 0 400 800 1200 1600 2000 2400 2800 4000 32000 64000 N° stringhe input file Risultati finali Esecuzione Locale Condor Tempoesecuzione(secondi)
  24. 24. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 24 Scelte che hanno condizionato il risultato  Non si è utilizzato un merge sort dall’inizio perché’ non è efficiente visto che inviare due valori ad un nodo per sapere quale dei due è maggiore costa di più che farlo in locale  Andamento del costo locale e distribuito del merge, per decidere  Si poteva utilizzare:  Algoritmi di ordinamento diversi  Una partizione diversa dei dati, non 8 processi ma per esempio 4, con due livelli e non 3  Questo poteva permettere di avere maggiori vantaggi in certe condizioni
  25. 25. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 25 Allocazione dei processi  Caso 1, caso semplice ed immediato:  Ho 8+4+2+1 processori e un processo per processore.  Ogni processo sa da dove prendere i dati e dove mandare i risultati  Costo di comunication elevato  Caso 2, riduzione del costo di comunicazione:  Ho 8 processori, questi computano la prima fase, poi quelli pari comunicano il risultato ai dispari, che  divengono pertanto i 4 processori della fase 2  Quelli che hanno id divisibile per 4 passano i risultati a quelli modulo 4 + 1, questi divengono quelli della fase 3  Etc. etc.
  26. 26. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 26 Problemi  Parallelizzazione degli algoritmi  Progettazione parallela  Non tutti gli algoritmi si possono parallelizzare in modo facile e poco costoso..  Bilanciamento fra vantaggi e costi di comunicazione  Massimizzazione dello Speed Up: Efficienza della soluzione parallela  Allocazione ottima dei processi sui nodi/peer:  Capacità dei nodi può cambiare nel tempo (Clock, rete, memoria, storage)  Costi di comunicazione che cambiano nel tempo, altre comunicazioni  Problema di allocazione: Genetic Algorithms, Taboo Search, etc.  Tolleranza ai fallimenti  Ridondanza dei processi  Migrazione dei processi, salvataggio del contesto  Limitato controllo delle capacità dei nodi  Limitato controllo delle prestazioni: CPU, rete, QoS, ….
  27. 27. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 27 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  28. 28. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 28 Grid vs Distributed and Parallel Parallel Computing Distributed Computing GRID Computing
  29. 29. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 29 The GRID  “the Grid” term coined in the mid 1990s to denote a distributed computing infrastructure for advanced science and engineering  “Resource sharing & coordinated problem solving in dynamic, multi- institutional virtual organizations” (Ian Foster, Karl Kesselman)  Un insieme di risorse computazionali, di dati e reti appartenenti a diversi domini amministrativi  Fornisce informazioni circa lo stato delle sue componenti tramite Information Services attivi e distribuiti.  Permette agli utenti certificati di accedere alle risorse tramite un’unica procedura di autenticazione  Gestisce gli accessi concorrenti alle risorse (compresi i fault)  No single point of failure
  30. 30. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 30 GRID service Richiedente (casa famaceutica, simulazioni, etc. dati proble ma Macro GRID Micro GRID Connessioni e comunicazioni Server/risorse messe a disposizione da istituzioni diverse disposte in modo geografico
  31. 31. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 31 Per essere un GRID • coordina risorse e fornisce meccanismi di sicurezza, policy, membership… • Usa protocolli ed interfacce standard, open e general- purpose. • permette l’utilizzo delle sue risorse con diversi livelli di Qualities of Service ( tempo di risposta, throughput, availability, sicurezza…). • L’utilità del sistema (middle tier) e molto maggiore a quella della somma delle sue parti nel supporto alle necessità dell’utente.
  32. 32. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 32 Scienze Data Intensive  Fisica nucleare e delle alte energie  Nuovi esperimenti del CERN  Ricerca onde gravitazionali  LIGO, GEO, VIRGO  Analisi di serie temporali di dati 3D (simulazione, osservazione)  Earth Observation, Studio del clima  Geofisica, Previsione dei terremoti  Fluido, Aerodinamica  Diffusione inquinanti  Astronomia: Digital sky surveys
  33. 33. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 33 BigData Science  How to: compute, process, simulate, extract meaning, of vaste/huge amount of data to create knowledge  Exploit efficiently the hugh amount of data/knowledge  Issues:  Data representation: indexing, search, execute, etc..  Data computing: sparse, uncertain, fast, etc.  Data understanding: mining, analize, etc.  Data view: fast, navigate,  Applications:  Recommendations, suggestions, semantic computing  Business intelligence: health, trends, genomic, HBP,  Distributed database, decision taking  Social networking, smart city  Event detection, unexpected correlation
  34. 34. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 34 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  35. 35. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 35 Concetti Estesi del GRID  Virtual Organization (VO) è costituita da:  un insieme di individui o istituzioni  un insieme di risorse da condividere  un insieme di regole per la condivisione  VO: utenti che condividono necessità e requisiti simili per l’accesso a risorse di calcolo e a dati distribuiti e perseguono obiettivi comuni.  abilità di negoziare le modalità di condivisione delle risorse tra i componenti una VO (providers and consumers) ed il successivo utilizzo per i propri scopi. [I.Foster]
  36. 36. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 36 U.S. PIs: Avery, Foster, Gardner, Newman, Szalay www.ivdgl.org iVDGL: International Virtual Data Grid Laboratory Tier0/1 facility Tier2 facility 10 Gbps link 2.5 Gbps link 622 Mbps link Other link Tier3 facility
  37. 37. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 37 PISA NAPOLI COSENZA PERUGIA PADOVA GENOVA LECCE MILANO PALERMO ROMA TORINO MATERA PAVIA BARI BOLOGNA Coordinamento Programma Nazionale FIRB CNR e Università HPC, Programmazione parallela, Grid computing, Librerie scientifiche, Data base e knowledge discovery, Osservazione della terra, Chimica computazionale, Elaborazione di immagini, … ASI Applicazioni di osservazione della Terra CNIT Tecnologie e infrastrutture hardware-software di comunicazione ad alte prestazioni, Tecnologia ottica, … CAGLIARI INFN e Università Grid (INFN-Grid, DataGrid, DataTag) , Applicazioni di e-science: Astrofisica, Biomedicina, Geofisica, …
  38. 38. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 38 Grid of Cluster computing  GRID  collezione di risorse distribuite, possibilmente eterogenee, ed una infrastruttura hardware e software per calcolo distribuito su scala geografica.  mette assieme un insieme distribuito ed eterogeneo di risorse da utilizzare come piattaforma per High Performance Computing.  Cluster, a micro-grid  Usualmente utilizza piattaforme composte da nodi omogenei sotto uno stesso dominio amministrativo  spesso utilizzano interconnessioni veloci (Gigabit, Myrinet).  Le componenti possono essere condivise o dedicate.
  39. 39. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 39 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  40. 40. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 40 Applicazioni dei GRID  Calcolo parallelo: sfruttamento di risorse distribuite a basso costo al posto di supercalcolatori  Applicazioni di calcolo massivo:  Medicali E.g.: From TAC to 3D real models  Profiling and personalization  Visione artificiale E.g.: Composition/mosaicing of GIS images  Risoluzione delle license per DRM  Adattamento di risorse digitali, coversione di formato  Stima di fingerprint di risorse digitali  Generazione di descrittori di risorse digitali  Simulazione strutturali, fluidodinamica, deformazioni, finanziarie, servizi, etc.  Predizioni del tempo  Predizioni finaziarie
  41. 41. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 41 Alcuni dettagli  Profiling and personalization Profilo del cellulare, capabilities, preferenze utenti Richiesta di contenuti, formati, img, doc, etc. Milioni di utenti al secondo  Visione artificiale E.g.: Composition/mosaicing of GIS images  Risoluzione delle license per DRM Richieste di risoluzione delle license  Adattamento di risorse digitali, coversione di formato  Stima di fingerprint di risorse digitali Riconoscimento delle tracce audio  Generazione di descrittori di risorse digitali Produzione di descrittori per inserirle in metadata, quando viene riprodotto un catalogo Indicizzazione e preparazione alle query Natural Language Processing, affective computing
  42. 42. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 42 Types of Grid Computing share access to computing resources Compute grids share access to databases and files systems Data grids share access to application software and services Utility grids
  43. 43. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 43 Types of Grid Computing  GRID Compute  Per esempio ricerca dello spazio delle soluzioni Predizione finanziaria, del tempo Problema del Commesso viaggiatore Analisi del genoma Produzione delle possibili tracce, evoluzioni dello stato in una macchina a stati Model checking, history checking  GRID Data  Database frazionato: da1M record in 10 da 100000 che in parallelo danno un risposta alla query  Query replicate  GRID Service  Database replicato per dare un servizio a molte persone, il parallelismo e’ sulle persone, sugli accessi al servizio. Query diverse sullo stesso database
  44. 44. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 44 The Systems Problem: Resource Sharing Mechanisms That …  Address security and policy concerns of resource owners and users  Are flexible enough to deal with many resource types and sharing modalities  Scale to  large number of resources,  many participant/users  many program components/process  On different nodes and configurations  Operate efficiently when dealing with large amounts of data & computation
  45. 45. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 45 Aspects of the Systems Problem 1) interoperability when different groups want to share resources  Diverse components, policies, mechanisms  E.g., standard notions of identity, means of communication, resource descriptions 2) shared infrastructure services to avoid repeated development, installation  E.g., one port/service/protocol for remote access to computing, not one per tool/application  E.g., Certificate Authorities: expensive to run  A common need for protocols & services
  46. 46. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 46 Programming & Systems Problems  The programming problem  Facilitate development of sophisticated applications  Facilitate code sharing among nodes  Requires programming environments APIs, SDKs, tools, distributed debug  The systems problem  Facilitate coordinated use of diverse resources Smart allocation, profiling, capabilities  Facilitate infrastructure sharing e.g., certificate authorities, information services  Requires systems protocols, services
  47. 47. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 47 Problemi dei GRID  condivisione delle risorse flessibile e sicura su scala geografica  L’ottimizzazione dello sfruttamento delle risorse, il cui stato non è direttamente sotto controllo e le informazioni relative sottostanno ad un certo grado di incertezza  Formazione dinamica di organizzazioni virtuali, VO  Negoziazione online per l’accesso ai servizi: chi, cosa, perché, quando, come, QOS  sistemi in grado di fornire diversi livelli di “Quality of Service”  Gestione automatica della infrastruttura  Problemi a licello di risorse e connettivita’ che sono il collo di bottiglia di molte applicazioni GRID
  48. 48. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 48 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  49. 49. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 49 GRID projects  LEGION  Middleware per la connessione di reti  Distribuzione di processi ed allocation  Trasparente per l’utente che chiede il servizio  UNICORE-UNiform Interface to COmputing REsources  Ministero tedesco  Combina le risorse di centri di computer e le rende disponibili in modo sicuro e senza cuciture attraverso intranet o internet.  Peer certificati per garantire l’uso e la sicurezza dei dati  GLOBUS  Open source (era)  Ora sta diventando commerciale
  50. 50. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 50 Some GRID Solutions !!  Condor  Unix and windows  Small scale GRID, non parallelism  Globus  Parallel  Unix like  C and java  Legion  Parallel, C++  Unix like  Too much space needed, 300Mbyte  Unicore  Java  Unix like  Open source  AXMEDIS, AXCP  C++ and JavaScript  Windows  Accessible Code, Free Software
  51. 51. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 51 GLOBUS and its toolkit  Open Source, Middleware  http://www-unix.globus.org/toolkit/license.html  Library for:  monitoraggio, scoperta e gestione delle risorse e delle informazioni  sicurezza dei nodi (certificati, autenticazione)  sicurezza delle comunicazioni  tolleranza dei guasti  portabilità  Globus Toolkit è cresciuto attraverso una strategia open- source simile a quella di Linux: questo ha incoraggiato una vasta comunità di programmatori e sviluppatori a introdurre continue migliorie al prodotto
  52. 52. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 52  Al Global Grid Forum (GGF4),  Globus Project e IBM hanno definito le linee dell’Open Grid Services Architecture (OGSA),  matrimonio e l’evoluzione di due tecnologie: Grid Computing e Web Services.  OGSA introduce il concetto fondamentale di Grid Service, ovvero un GRID che dispone di interfacce che lo rendono manipolabile per mezzo di protocolli web service.  Open Grid Services Infrastructure (OGSI) definisce le interfacce di base/standard e i comportamenti per servizi gestibili dal sistema. Open Grid Services Architecture
  53. 53. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 53 Globus GRID Tool Kit l Sicurezza (GSI) l Gestione delle risorse (GRAM, Access and Management) l Gestione dei dati (GASS, GridFTP, GRM) l Servizi di informazione (GIS, security) l Comunicazione (I/O, Nexus, MPICH) l Supervisione dei processi e gestione guasti (MDS, HBM)
  54. 54. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 54 Componenti di GLOBUS toolkit 1/2  Grid Security Infrastructure, GSI  meccanismo di autenticazione che si occupa della sicurezza nell'ambiente Grid, garantendo l'accesso solamente agli utenti autorizzati. Si basa sullo standard di certificati  GSI delega, ossia effettua una creazione remota di un proxy delle credenziali e permette a un processo remoto di autenticarsi per conto dell'utente.  Globus Resource Allocation Manager, GRAM  abilitare un accesso sicuro e controllato alle risorse computazionali gestendo l'esecuzione remota di operazioni sulle risorse stesse.  Il gatekeeper e un processo del GRAM che gestisce la richiesta di un nodo cliente inviandola al job manager, il quale dopo aver creato un processo per la richiesta ne controlla l'esecuzione comunicandone lo stato all'utente remoto.
  55. 55. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 55 Componenti di GLOBUS toolkit 2/2  Data Management  GRIDFTP e’ un protocollo utilizzato per realizzare lo scambio di file tra le varie risorse all'interno della griglia. Estende il protocollo FTP, aumentando la capacita e la sicurezza del trasferimento dati  GRID Information Services, GIS  raggruppa le informazioni di stato delle varie risorse e viene suddiviso in tre principali servizi: MDS, Monitoring and Discovering Service. GIIS, Grid Index Information Service, organizzato in processi in relazione gerarchica, la root e’ TOP MDS GRIS, Grid Resource Information Service, che colleziona info e le invia al GIIS. Il GRIS e’ installato su ogni risorsa.
  56. 56. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 56 n56 Tre componenti principali 1. RSL (Resource Specification Language) per comunicare i requisiti delle risorse 2. Resource Broker: gestisce il mapping tra le richieste ad alto livello delle applicazioni e le risorse disponibili. 3. GRAM (Grid Resource Allocation Management) è responsabile di un set di risorse ed agisce da interfaccia verso vari Resource Management Tools (Condor,LSF,PBS, NQE, EASY-LL ma anche, semplicemente, un demone per la fork) Resource Management Services
  57. 57. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 57 GRAM GRAM GRAM LSF Condor PBS Application Resource Specification Language Information Service Local resource managers Broker Co-allocator Queries & Info Resource Management Architecture nLoad Sharing Facility nPortable Batch System” negotiation Monitor and discover planner
  58. 58. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 58 Combinazione Globus e Condor n  Globus  Protocolli per comunicazioni sicure tra domini  Accesso standard a sistemi batch remoti  Condor  Job submission e allocation  Error recovery  Creazione di un ambiente di esecuzione
  59. 59. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 59
  60. 60. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 60 CONDOR  Nasce nel 1988, University of Madison  Creazione di cluster di workstation PC  Sfruttamento di momenti di scarsa attivita’ della CPU;  Condor lascia la CPU se l’utente lavora sul PC  Salva il punto e poi riparte  Sposta/migra se necessario l’esecuzione del processo su un’altra CPU  Il codice non viene cambiato ma viene semplicemente linkato con lib speciali
  61. 61. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 61 Salvataggio del contesto  Per poter migrare il processo devo salvare il contesto.  Il contesto lo salvo ad intervali regolari, per esempio ogni decimo del tempo di esecuzione.  in questo caso ho uno spreco massimo di 1/10 del tempo di esecuzione, che deve essere vantaggioso rispetto al costo di spostamento del processo sull’altro nodo
  62. 62. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 62 CONDOR  A basso livello si basa su procolli di comunicazione diversi per gestire i processi (interoperabilita’):  Vanilla: permette di eseguire tutti i programmi che non possono essere re-linkati ed è utilizzato per shell scripts. Non sono implementate migrazione e chiamate di sistema.  PVM: per far girare sopra Condor programmi scritti per l’interfaccia PVM (Parallel Virtual Machine).  MPI: Questo ambiente risulta utile per eseguire i programmi scritti secondo il paradigma di Message Passing Interface (MPICH).  Globus Permette di eseguire i processi scritti …..  Java: Permette di eseguire i processi scritti per la Java Virtual Machine  ….
  63. 63. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 63 Sicurezza in CONDOR  L’autenticazione di una comunicazione sotto Condor è realizzata grazie all’implementazione di alcuni protocolli: tra questi citiamo  GSI (basato su certificati X.509),  Kerberos,  e un meccanismo basato su file-system (Windows prevede un meccanismo di autenticazione proprietario).
  64. 64. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 64 CONDOR architecture Central Manager Condor_Collector Condor_Negotiator Submit Machine Controlling Daemons Condor_Shadow Process Execution Machine Control via Unix signals to alert job when to checkpoint Controlling Daemons User’s job User’s code Condor_Syscall_Library All System Calls Performed As Remote Procedure Calls back to the Submit MachineCheckpoint File is Saved to Disk
  65. 65. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 65 CONDOR ruoli e servizi  Central Manager, solo un Central Manager.  Raccoglie tutte le informazioni e negoziare tra le richieste e le offerte di risorse.  Affidabile e potente  Submit  Altre macchine del pool (incluso il Central Manager) possono invece essere configurate per sottomettere jobs a Condor.  queste macchine necessitano di molto spazio libero su disco per salvare tutti i punti di checkpoint dei vari job sottomessi.  Execute (i nodi del GRID)  Alcune macchine nel pool (incluso il Central Manager) possono essere configurate per eseguire processi Condor.  Essere una macchina di esecuzione non implica la richiesta di molte risorse.
  66. 66. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 66 CONDOR: Pregi e difetti  Pregi:  non necessita di modificare i vostri programmi Differentemente da seti@home  set-up semplice  facilità di gestione della coda dei job  breve tempo necessario ad implementare una “griglia” funzionante.  estrema versatilità nel gestire svariati tipi di applicazioni (.exe).  trasparenza agli occhi degli utenti durante l’esecuzione.  Difetti:  I meccanismi di sicurezza implementati non garantiscono ancora il medesimo livello di protezione offerto da una vera soluzione middleware.  Limitato controllo sull’intera grid.  Bassa “tolleranza” ai guasti: se nessuna macchina del pool soddisfa i requisiti di un job, questo rimane in attesa senza andar mai in esecuzione e l’utente è costretto a rimuoverlo manualmente.
  67. 67. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 67 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  68. 68. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 68 AXMEDIS Content Processing GRID  accesso dai dati  trasformazione contenuti  produzione di contenuti on deman  Adattamento in tempo reale, riduzione costi, etc  manipolazione di license in tempo reale  protezione dei cotenuti digitali  Comunicazione con altri processi  Monitoraggio  Controllo reti P2P
  69. 69. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 69 AXMEDIS Content Processing, GRID CMSs Crawlers AXMEDIS database Area AXMEDIS databases AXMEDIS Editors AXMEDIS Factory Programme and Publication AXMEDIS Workflow Management tools AXMEDIS Content Processing Engines and Scheduler GRIDs AXEPTool Area AXEPTools AXEPTools
  70. 70. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 70 Front end servers, VOD, prod on demand AXMEDIS Content Processing GRID Your CMSs AXCP Scheduler AXMEDIS Rule Editor Workflow manager nAXMEDIS Database DistributionC hannels and servers AXCP nodes AXCP GRID Rules Plug-in for content processing WS, FTP, etc. Quick Starter Front end servers, VOD, prod on demand AXCP Visual Designer Visual Elements and Rules
  71. 71. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 71 AXMEDIS Content Processing Area l GRID infrastructure for  automatic production and processing content on the basis of rules  AXCP Rules which are  written as scripts by the AXCP Rule Editor  executed in parallel and rationally using the computational resources accessible in the content factory  AXCP Rule Engine. l AXCP area receives commands coming from the Workflow of the factory.
  72. 72. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 72 Factory and integration WEB Server Playout Server Web+Strm Server Internet, WEB, VOD, POD.. DB CMS AXCP Quick Start, Your tools commands, Workflow systems,… AXMEDIS Automated and Manual Factory Tools AXMEDIS DRM Monitoring & Reporting Broadcast, IPTV, i-TV, VOD, POD,… Mobiles, PDA, etc. AXMEDIS Automated and Manual Factory Tools AXMEDIS Automated and Manual Factory Tools AXMEDIS Automated and Manual Factory Tools P2P distrib & monitor Social Networks
  73. 73. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 73 AXMEDIS Content Processing GRID  GRID per il Content Processing  Discovery di risorse, nodi Valutazione dello stato e delle pontenzialita dei nodi  Creazione di regole, processi Un solo processo per nodo  Esecuzione di regole/processi, attivano anche processi locali scritti non in forma di regole On demand, periodiche, collegate, asincrone  Allocazione ed ottimizzazione dei processi  Comunicazione con il gestore ma anche fra nodi N to N N to S, per monitor e/o invocazione di regole/processi  Tracciamento e controllo dei processi  Workflow, gestione di alto livello, integratione macchina Users
  74. 74. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 74 Snapshots of the GRID at work
  75. 75. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 75 AXCP processing capabilities  Automating access to databases and comm. channels  Automating Content Profiling:  device and user profile processing  Automating Content Protection:  MPEG-21 IPMP, OMA, etc.  Automating Content license production and processing:  MPEG-21 REL, OMA ODRL, etc.  Automating Content Production/Processing  Metadata, integration and extraction  Content Processing: adaptation, transcoding, filtering, analysis, recognition, etc..  Content Composition and Formatting (SMIL, XSLT)  Packaging: MPEG-21, OMA, ZIP, MXF  Using protected content and DRM support, content processing is performed in secure manner even on the GRID nodes according to the DRM rules/licenses
  76. 76. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 76 AXCP processing capabilities  Processing functionalities:  Gathering content  Production of new objects: composition, etc.  Formatting: SMIL, XSLT, etc.  Synchronization of media, etc.  Content adaptation, transcoding, …..….  Reasoning on device capabilities and user preferences, (user, device, network, context)  Production of licenses, MPEG-21 REL, OMA  Verification of Licenses against them and PAR  Metadata and metadata mapping: Dublin Core, XML  Extraction of descriptors and fingerprints …MPEG-7  Protocols: IMAP, POP, Z39.50, WebDav, HTTP, FTP, WS, etc.  Controlling P2P networks  ....  Any type of resource in any format  Multimedia: MPEG21, IMS, SCORM, etc.  DB: ODBC, JDBC, DB2, Oracle, MS-SQL, MySQL, XML databases, etc.  Licensing systems: MPEG-21, OMA  File Formats: any video, audio, image, xml, smil, html, ccs, xslt, etc.
  77. 77. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 77 AXMEDIS Content Processing GRID AXMEDIS Scheduler AXMEDIS Rule Editor Workflow manager
  78. 78. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 78 AXMEDIS Content Processing Area: AXCP Rule Editor l It is an IDE tool for: l Creating and editing AXCP Rules l Defining parameters and required AXMEDIS Plugins l Editing, checking and debugging JS code l Activating AXCP Rules into the AXCP Rule Engine
  79. 79. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 79 Rule Editor
  80. 80. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 80 Rule Editor  The Rule Editor allows  Writing AXCP Scripts in Java Script with the above capabilities Calling libraries in javascripts Calling plug in functions in C++, and other languages  Defining AXCP scripts metadata: Manifesto components Scheduling details Capabilites Information, etc.  Debug scripts: defining break points, run/stop/execute step by step, Monitoring variables, etc.  Putting in execution java scripts
  81. 81. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 81 AXMEDIS Content Processing Area: AXCP Rule  AXCP Rules include metadata for heading information (Header) and firing (Schedule)  AXCP Rules contain algorithms for composition, formatting, adaptation, transcoding, extraction of fingerprint and descriptors, protection, license manipulation, potential available rights manipulation, resource manipulation, load and save from databases and file system, content migration etc. (Definition)  Algorithms are written by using JavaScript programming language  JS was extended  with data types derived from AXMEDIS Framework, MPEG21, and general resource definition such as: images, documents, video, licenses, etc.  to use different functionalities for content processing by means the AXMEDIS Plugin technology (adaptation, fingerprint, etc…)
  82. 82. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 82 Regole AXCP, formalizzazione XML
  83. 83. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 83 AXCP visual designer  Fast and simple Visual Programming of AXCP GRID processes  Composing Blocks as JS modules to create AXCP rules  Composing AXCP Rules to create sequences of actions to be scheduled according to their dependencies
  84. 84. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 84 Visual Designer  Visual language for GRID programming  RuleBlock::= {JSBlock} | <defined in JS as JS rule>  JSBlock::= <defined in JS as JSBlock>  ManRuleBlock as specific manager for its child processing rules.
  85. 85. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 85 Rule Scheduler
  86. 86. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 86 Rule Scheduler  AXCP Rule Scheduler performs:  executors discovering, monitoring (rule analysis)  Rules transfering and installation, allocation of Scripts on Nodes on the basis of capabilties and rule needs  Recover from the nodes the node information about their capabilities: CPU clock, cpu exploitation profile Space on the disk Communication throughput with databases Libraries accessible with their version  Monitoring GRID nodes, via messages of errors  Controlling (stop, pause, kill, etc.) GRID nodes  Logs generation and collecting data
  87. 87. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 87 GRID Node Profile
  88. 88. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 88 Log Properties
  89. 89. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 89 Esempio di esecuzione var sb = new AXSearchbox(); sb.Host = "liuto.dsi.unifi.it"; sb.Port = "2200"; sb.Username = "admin"; sb.Password = "password"; var qs = new QuerySpec(); var a = new Array(1); a[0] = 1; qs.Archives = a; qs.Parser = QueryParser.ALGPARSER; qs.Info = QueryInfo.INFO_CONTEXT; qs.View = QueryView.VIEW_PUBLISHED; qs.Sort = QuerySort.SORT_STANDARD; qs.QueryString = key; qs.FirstDoc = 0; qs.LastDoc = 10; var qr = new Array(); var maxres = sb.Query(qs, qr); var i, j; for(i = 0; i < qr.length; ++i) { var doc = sb.GetDocument(qr[i].ID); var meta = sb.GetDocumentMetadata(qr[i].ID); for(j = 0; j < meta.length; ++j) { var m = meta[j]; } } print("-> "+doc.MimeType+" ["+doc.Size+"]"+"n") print("--> "+meta[j].Key+ "["+meta[j].Slice+"]="+meta[j].Value+"n");
  90. 90. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 90 AXMEDIS CP GRID, technical view WS for Control and Reporting (Workflow)
  91. 91. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 91 Realizzazione: Rule Engine Scheduler Esecutoreremoto • Eng. Cmd & Rep.: interfaccia remota verso il workflow manager • Scheduler Cmd Manager: interfaccia dello scheduler • Internal Scheduler: schedulazione dei job, supervisione del dispatcher • Dispatcher: gestore delle risorse remote, della comunicazione e dell’associazione job-esecutore • Grid Peer Interface: modulo per la gestione della comunicazione remota • Rule Executor: modulo per l’esecuzione dello script
  92. 92. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 92 Scheduler Command Manager e Graphic User Interface l Lo Scheduler Command Manager è un’interfaccia che rende indipendente lo scheduler dal tipo di interfaccia utente (grafica o di comunicazione remota) usata l L’interfaccia grafica permette un accesso rapido alle funzionalità dell’applicazione Scheduler Command Manager Scheduler GUI Engine Commands and Reporting User Workflow Manager
  93. 93. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 93 GRID Gerarchico
  94. 94. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 94 Gestione Gerarchica di microGRID  Ogni Scheduler identifica un microGRID  Da ogni nodo del GRID e’ possibile inviare richieste ad altri Scheduler e pertanto ad altri microGRID  Le richieste vengono inviate tramite chiamate a Web Services  Si viene a greare una gerarchia di grid e di nodi in tali grid  I singoli MicroGRID possono essere distirbuiti anche geograficamente, si veine a creare un vero e proprio GRID geografico  I nodi foglia possono inviare richieste allo scheduler radice, etc.
  95. 95. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 95 Internal Scheduler l permette la scelta dei job da mandare in esecuzione e l’aggiornamento della periodicità, il controllo sulla scadenza, il controllo e l’aggiornamento delle liste dei job e degli esecutori
  96. 96. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 96 Dispatcher •riunisce le funzionalità di associazione, lancio e controllo:  Resource Controller: controllo dello stato degli esecutori e la richiesta del loro profilo  Optimizer: associazione degli esecutori con i job da mandare in esecuzione in funzione del profilo e politica FCFS  Rule Launcher: invio di comandi e del file del job agli esecutori remoti  Rule Monitor: controllo sulle notifiche inviate dagli esecutori e dai job in esecuzione
  97. 97. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 97 Evolution of Rule’s State INACT IVE ACTI VE SUSPE NDED RUNNI NG COMPLE TE Rule Editor::Enable AXWF:: Enable Rule Editor::Disable AXWF::Disable Scheduler::End Scheduler::Run Scheduler::Pause Scheduler::Resume If Periodic Scheduler::Refresh If Not Periodic Scheduler:: Disable FAILUR E Rule Editor::Disable AXWF::Disable Rule Editor::Enable AXWF:: Enable If error Scheduler::Failure LAUNC HING If executor!=NULL Scheduler::Failure Scheduler::Launch If executor!=’Available’ Scheduler::Delay If deadline OR time Scheduler::Failure DELAY ED If executor==’Available’ Scheduler::Run PAUSE Scheduler::Suspend Scheduler::Resume
  98. 98. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 98 Scheduler GUI
  99. 99. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 99 Scheduler
  100. 100. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 100 Sfruttamento della CPU nei nodi nIn Nero la % di CPU sfruttata da processi utente nIn Rosso la % di CPU sfruttata dal processo del GRID nPolitiche nStare strettamente sotto/allo X% nAccettare che si possa andare sotto, ma stare all’X% come valore medio nSfruttare al massimo la CPU quando l’utente non e’ presente
  101. 101. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 101 Planning and Exploiting Node capabilities  GRID node has a profile describing its capabilities: time profile, memory, HD, communication, tools and plug ins, etc. CPU exploitation controll with an adaptive threshold 0 20 40 60 80 100 120 1 12 23 34 45 56 67 78 89 100 111 122 133 144 155 166 177 188 199 210 Average on 10 values of CPU workload Threshold Global CPU Workload GRID node CPU usage
  102. 102. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 102 Ottimizzazione della Pianificazione Allocazione dei processi sui nodi  Valutazione del profilo dei Nodi  Capabilities dei nodi  Potenza computazionale  Network Capabilities  Valutazione delle necessità delle regole/processi  Componenti necessari, funzioni necessarie  Scadenza temporale, deadline  Architettura per la sua esecuzione se multi nodo  Scelta della soluzione ottima:  Bilanciamento del carico  Soddisfazione dei vincoli  Algoritmi di allocazione  Deadline monotonic  Taboo Search  Genetic Algorithms
  103. 103. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 103 Gantt diagram and jobs nRes1 nRes2 nRes3 nRes4 nRes5 nJ20 nJ2 nJ1 nVincoli, di dipendenza nVincoli, di dipendenza nDeadline for J1 ntime nRisorse: host, cpu
  104. 104. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 104 Pianificazione dei processi
  105. 105. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 105 Dipendenze nPunti di sync ? nPer la comunicazione ? nConsumo di risultati ? nAttese ? nPossibile deadlock (da evitare)
  106. 106. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 106 Gantt Diagrams (OPTAMS, TS) Schedule cumulative for phase before the optimization Schedule cumulative for phase after the optimization
  107. 107. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 107 Condor JobMonitor Screenshot
  108. 108. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 108
  109. 109. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 109 Per ogni processo al tempo Tx  D: Durata prevista del processo (con incertezza)  Tstart: Tempo di start (time stamp di start)  Tend: Tempo previsto di completamento  Pc: Percentuale di completamento (se possibile), per esempio  Valore dell’indice di un processo iterativo,  numero di iterazioni, etc. etc.  Ad un certo Tx>Tstart la Pc puo’ essere:  Conforme (Tx-Tstart)/D%==Pc  In anticipo Pc > (Tx-Tstart)/D%  In ritardo Pc < (Tx-Tstart)/D%  Necessario attualizzare
  110. 110. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 110 Pianificazione e Ripianificazione Nell’ottica del controllo della QoS  Sul microGRID come sul GRID viene effettuata una pianificazione dei processi allocandoli sulle risorse (CPU) (righe blu nella prossima slide)  Nella pianificazione si devono tenere conto di vari vincoli come: deadline, dipendenze, requisiti computaizone, requisiti in termini di librerie e programmi, memoria, CPU, etc.  Questa allocazione non e’detto che si verifichi  Alcuni processi possono essere eseguiti piu’ velocemente, altri piu’ lentamente, riespetto ai tempi previsti, etc. (processi rossi nella prossima slide)  Ogni tanto e’necessario fare una ripianificazione e correzione della situazione (processi verdi nella prossima slide).
  111. 111. 5/17/2014 (C) Paolo Nesi-1995-2000 111 Esempio di ottimizzazione 125 task, 2CAD, 2CAM, 4ADP, 6MM, 2MEMA Ottimizzazione: 24.6%
  112. 112. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 112 Confronto AG, TS In letteratura le tecniche più utilizzate per affrontare tali problemi sono le seguenti: • AG (Algoritmi Genetici) • TS (Tabu Search) Dai lavori utilizzati come riferimento risulta che: • TS maggior velocità (almeno un ordine di grandezza) • TS capacità di trovare il maggior numero di soluzione ottime (benchmark) • TS minor dipendenza rispetto al problema (aumento job e macchine) • TS architettura realizzativa semplice (adatta a vari problemi) • AG maggior robustezza (non necessita di soluzione iniziale). Versioni modificate come GLS hanno prodotto buoni risultati.
  113. 113. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 114 Mosse operate sui task O(1,1) O(2,2) O(2,1) O(1,2) O(1,3) O(2,3) MM0 MM1 t O(2,3) O(1,1) O(2,2) O(2,1) O(1,2) O(1,3) O(2,3) MM0 MM1 t O(1,3) Mossa di Shift Mossa di Allocazione Qualsiasi mossa più complessa può essere ottenuta per composizione di queste mosse semplici
  114. 114. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 115 Funzionale di costo F = KA*allocation-KB*biasDeadline+KD* delay+KV* varTotale+Kc* Cmax • allocation costituisce il valor medio di violazione di contemporaneità nella schedula • Cmax misura la lunghezza temporale della schedula • biasDeadline è il valor medio relativo all’anticipo (o al ritardo) rispetto alle scadenze delle operazioni contenute nella schedula • delay favorisce l’anticipo dei task in ritardo rispetto a quelli che rientrano nella scadenza prevista • vatTotale costituisce una misura del valor medio del carico complessivo sulle risorse utilizzate • I vari K sono i pesi associati ai funzionali. I indicano che si prende la variazione del funzionale rispetto all’iterazione precedente
  115. 115. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 116 Funzionali di costo Funzionale Anticipa scadenze Riduce schedula Risolve violazioni Uniforma carico BiasDeadline SI SI NO NO Delay SI per i task in ritardo SI se task in ritardo NO NO Cmax SI ma solo dell’ultimo SI NO NO Allocation NO NO SI NO VarTotale NO NO NO SI
  116. 116. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 117 Andamento funzionali F = KA*allocation-KB* biasDeadline+KD* delay+KV* varTotale+Kc* Cmax 5 11 7 7 3 10 10 10 10 10          C V D B A K K K K K
  117. 117. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 118 AXMEDIS CP GRID, technical view WS for Control and Reporting (Workflow)
  118. 118. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 119 Realizzazione: Grid Peer Interface e Grid Peer l La Grid Peer Interface rende il sistema indipendente dal tipo di strato di comunicazione utilizzato l Permette l’invio e la ricezione di messaggi di testo l Permette l’invio e la ricezione di file l Permette la scoperta degli esecutori e connessione l E’ configurabile Messaggi di testo file scoperta configurazione
  119. 119. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 120 GRID Interface
  120. 120. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 121 AXCP GRID NODE … … EXECUTOR MANAGER GRID PEER INTERFACE SCRIPT EXECUTOR SCRIPT MANAGER JS ENGINE (API Functions) AXOM JS_AXOM AXOM Content Processing JS_ Funtions from AXOM Content Processing Resource Types JS_ Resource Types Selection JS_ Selection AXMEDIS Rule Executor LAUNCHER Protection JS_ Protection GRID PEER DRM JS_ DRM PAR JS_ PAR Functions JS_ Functions
  121. 121. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 122
  122. 122. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 123 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  123. 123. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 124 Applicazioni per microGRID  Adattamento di contenuti  E.g.: youtube  Produzione di suggerimenti per social network  Produzione di newsletter per social network  Controllo di reti CDN  Questa tecnologie viene recentemente rimpiazzata da soluzioni Hadoop
  124. 124. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 125 Production On Demand User and Device profile AXCP GRID Activate Rule AXMEDIS DRM Content: Search, Selection, Acquisition, Production, Adaptation, Transcoding, Formatting, Packaging, Protection, Publication and Licensing on Demand CollectionDistributorServer Social Networks Content Databases
  125. 125. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 126 Apetti rilevanti  Device che comunicano al server il loro profilo (CCPP)  Device che collezionano dati del profilo utente e che gli possono passare al server (CCPP)  Server che devono essere in grado di leggere ed interpretare queste informazioni per adattare il loro servizio  Server devono essere in grado di gestire un numero elevato di elaborazioni al minuto o al giorno  Servizi off-line e/o realtime (online, on demand):  Generazione di pagine WEB dinamiche  Generazione di contenuti digitali adattati secondo le esigenze di utente, device, connessione
  126. 126. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 127 MPEG-21 DIA MPEG-21 DID Digital Item Adaptation Engine MPEG-21 IPMP/REL Resource MPEG-21 DII Resource Adaptation Engine Description Adaptation Engine Descriptor MPEG-21 DIA Tools MPEG-21 DID’ MPEG-21 IPMP/REL’ MPEG-21 DII’ MPEG-21 DID MPEG-21 IPMP/REL MPEG-21 DII MPEG-21 DIA Tools Usage Environment Description Tools Digital Item Resource Adaptation Tools Digital Item Declaration Adaptation Tools DI-1 DI-3 DI-2 Descriptor Resource’ Descriptor’ MPEG-21 DIA Tools MPEG-21 DID Digital Item Adaptation Engine MPEG-21 IPMP/REL Resource MPEG-21 DII Resource Adaptation Engine Description Adaptation Engine Descriptor MPEG-21 DIA Tools MPEG-21 DID’ MPEG-21 IPMP/REL’ MPEG-21 DII’ MPEG-21 DID MPEG-21 IPMP/REL MPEG-21 DII MPEG-21 DIA Tools Usage Environment Description Tools Digital Item Resource Adaptation Tools Digital Item Declaration Adaptation Tools DI-1 DI-3 DI-2 Descriptor Resource’ Descriptor’ MPEG-21 DIA Tools
  127. 127. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 128 MPEG-21 DIA model Usage Environment Description Tools • User Characteristics • Terminal Capabilities • Network Characteristics • Natural Environment Characteristics Digital Item Resource Adaptation Tools • Bitstream Syntax Description • Terminal and Network QoS • Bitstream Syntax Description Link • Metadata Adaptability Digital Item Declaration Adaptation Tools • Session Mobility • DIA Configuration Usage Environment Description Tools • User Characteristics • Terminal Capabilities • Network Characteristics • Natural Environment Characteristics Digital Item Resource Adaptation Tools • Bitstream Syntax Description • Terminal and Network QoS • Bitstream Syntax Description Link • Metadata Adaptability Digital Item Declaration Adaptation Tools • Session Mobility • DIA Configuration
  128. 128. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 129 Profiling, MPEG-21 DIA  The device/terminal capabilities include codec capabilities (specific parameters for each codec), display capabilities, included players features, interactivity features, power consumption, memory, CPU power in terms of MIPS or MFLOPS, storage, etc.  The network capabilities (such as: maximum capacity, minimum bandwidth, quality indicators, etc.) and conditions (such as: delay and errors related to capabilities, etc.).  The user characteristics such as: user information in MPEG-7; user preferences; user history including (e.g., the actions performed on DIs), presentation preferences such as preferred rendering of audiovisual and textual information, accessibility features (for example, audio left/right balance and color arrangement), location characteristics (such as: mobility characteristics and destination, for example for describing the user movements).  The natural environment characteristics are related to the physical environment such as light conditions, time, location, environmental noise, etc.
  129. 129. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 130 Adaptation of multimedia content  Functionalities  Allows creating generic multimedia files (3GP, MP4 ISMA compliant)  Adaptation of aggregated simple media files (MPEG-4 audio and video, MPEG-1/2 audio and video, JPEG images, AVI files, SRT subtitles…)  Media tracks may be added, removed and delayed  Extraction of single track from multimedia files  File splitting by size or time  Concatenation of multimedia files  Conversion between different multimedia scene formats (MP4, BT, XMT, SWF, X3D, SMIL…)
  130. 130. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 131 Fingerprint and descriptors  What is the Fingerprint  It is an ID-code estimated on the digital content or resource that present in practical an high probability to be unique for that content with respect to other similar content  To make the recognition of the digital content possible Indexing into the database  Fingerprint as a high level content descriptor  Resources Audio: Rhythm, tonality, duration, genre, etc. Video: number of scenes, description of the scene, etc. Text: main keywords, summary, topics, etc.  Collected as MPEG-7 descriptors  Vectors of those features, etc.  Independent on the resolution, format, etc.  May be Computationally intensive  Etc.
  131. 131. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 132 Fingerprint Features  Features:  Never included with the content if its aim is the usage for content protection  Included in the content (package) only if it is used as content descriptor  Robust to adaptation processing: Scaling: time, space, color, etc.  Short and concise  Repeatable  Light to be estimated estimable during streaming, on the basis of a short duration of the content streaming  Robust to eventual watermark addition  Etc.  Typically more computational intensive with respect to WM:  The WM code is read/extracted from the content  The FP code has to be estimated from the content
  132. 132. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 133 Usage of Fingerprint  Then Content Owners, may monitor  distribution channels  published content collection  Etc.  To detect the passage of their content by  estimating in real time the fingerprint the  searching into the database Monitoring PCs PDAs OpenSky Data Broadcast Kiosks Kiosks i-TVs Channel Distributors PC- Distributors PDA- Distributors Mobile-Distributors Mobiles Satellite Data Broadcast Packaging
  133. 133. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 134 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  134. 134. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 135 Aspetti e caratteristiche di alto livello  Portabilita’:  Su diversi OS e piattaforme  Come java script  modularita’:  Si possono aggiungere facilmente nuove funzionalita’  Riusabilita’:  Si possono aggiungere facilmente nuove funzionalita’  Gli script sono parametrizzati  Expandibilita’:  Si possono aggiungere facilmente nuove funzionalita’  Flessibilita’:  Si possono aggiungere facilmente nuove funzionalita’
  135. 135. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 136 GRID comparison 1 axmedis Condor Globus Legion Unicore Description Content processing GRID for media Network batch and resource manager Bag of Grid Technologie s MetaSystem object based Vertical Grid system Category Small Scale Small Scale Grid MiddleWare MiddleWare MiddleWare Resource Manager Central machine Manager Central machine Manager GRAM Collector, Scheduler, Enactor Incarnation DataBase on Vsite Resouce Discovery manifesto ClassAds MDS (handles resource informations) limited Target System Interface (TSI) Communication WS Remote System Call Nexus, Globus I/O Asynchronous message- passing system, LOIDs Asynchronous Transaction Fault Tolerance none Checkpoint & Migration Heart Beat Monitor (HBM) Checkpoint via libraries Failure Flag Security DRM GSI (X.509) Kerberos (User/Ip based) UIDs GSI (X.509) SSL (Secure Sockets Layer) Public-key cryptography based on RSAREF 2.0 Three message-layer security modes MayI (classes security) SSL X.509 Architecture hierarchical Universes structured “Hourglass” architecture Everything is an object… “Three-tier model”
  136. 136. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 137 GRID comparison 2 AXMEDIS Condor Globus Legion Unicore OGSA Compliant NO No yes no yes Parallelism Yes, not internal No yes yes - Parameters Studies Yes No yes yes - Necessary changes to user’s source code No, + Extended JS Re-link with Condor libraries Re-link with Globus libraries, changes to support parallelism Directive embedded in Fortran Code; use of MPL to parallelize C++ application; interface for PVM and MPI application - Platform Windows XP, and server MacOS Linux RedHat 7.x, 8.0, 9 Solaris 2.6, 2.7, 8, 9 IRIX 6.5 Hp-Unix. Windows NT4, 2000, Xp (con funzionalità ridotte) Server: Linux Client: Linux Any platform that supports JDK Solaris 5.x IRIX 5.x, 6.5 Linux RedHat 5.x AIX 4.2.1, 4.3 Hp-Unix 11.x Cray Unicos (as a virtual host only) Server: Unix Linux Client: Any platform that support Java (J2RE) 1.4 o superiori
  137. 137. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 138 GRID comparison 3 AXMEDIS Condor Globus Legion Unicore Languag es Any language is viable, JS is the glue to put in execution Application: C C++ Java Application : C Java Application: C++ MPL (an extension of C++) Fortran Application: Java Middleware: Java 2.0 Require ments Windows On Windows: at least 50 MBytes of free disk space NTFS or FAT - 250-300 MB of free disk space at least 256 MB virtual memory /bin/ksh installed - Licence Source code available Source code available on mail request (Open source) Binaries packages only Open source Links www.axmedis.org www.cs.wisc.edu/condor (necessary state name, e-mail and organization) www.globu s.org www.legion.virginia.edu (Legion RSA libraries are available separately; from 1/1/03 contact Avaki.com for all inquiries about Legion) www.unicorepro. com
  138. 138. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 139 Micro GRID for scalable media comput.
  139. 139. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 140 Comparison: Micro GRID for media IEEE Multimedia 2012 AXMEDIS MMGRID MediaGrid GridCast MediaGrid.or g Omneon MediaGrid Content Management: storage, UGC, .. X (x) (x) X X Content computing/processing: adaptation,  processing conversion, cross media content  packaging,   .. X (x) (x) (x) X Content Delivery Network Management X X X X X Metadata enrichment and reasoning X Content Protection Management (CAS/DRM) X Content Indexing and Querying, knowledge base X X X Semantic Computing Reasoning on user profiling,  content descriptors, recommendations X User Interaction Support, rendering, collaboration X X X Client player as grid nodes for intelligent content X Global and/or Local grid L/(G) G G G G/L L
  140. 140. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 141 micro grid post production protection, packing, licensing Digichannel CA & DRM servers P2P CDN-aP2P CDN-b PC users with smart players micro grid content production UGC management & publication Social Portal and UGC collection Mobile Medicine Variazioni Content Enrichment Portal users micro grid content post production packing and protection CA & DRM servers Musa ANSC Kiosk service portal Kiosks users micro grid content production post production, packing PDA users PDA users with smart players Mobile users PC users
  141. 141. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 142 Grid Project References l Open Science Grid  www.opensciencegrid.org l Grid3  www.ivdgl.org/grid3 l Virtual Data Toolkit  www.griphyn.org/vdt l GriPhyN  www.griphyn.org l iVDGL  www.ivdgl.org l PPDG  www.ppdg.net l AXMEDIS  www.axmedis.org l CHEPREO  www.chepreo.org l UltraLight  www.ultralight.org l Globus  www.globus.org l Condor  www.cs.wisc.edu/condor l WLCG  www.cern.ch/lcg l EGEE  www.eu-egee.org nFrom AXMEDIS you can download the installable tool to set up your GRID
  142. 142. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 143 sommario  Contesto tecnologico  Architetture Parallele  GRID: definizione e motivazioni  Concetti estesi dei GRID, microgrid  Applicazioni e problemi dei GRID  Soluzioni GRID...Globus, Condor  Soluzioni MicroGRID: AXCP grid  Applicazioni per microGRID  Confronto fra GRID  Architetture MapReduce
  143. 143. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 144 Architetture MapReduce  At the basis of Apache Hadoop solution  Designed to realize  Large scale distributed batch processing infrastructures  Exploit low costs hardware from 1 to multiple cores, with low to large Mem, with low to large storage each  Covering huge (big data) storage that could not be covered by multi core parallel architectures  See Yahoo! Hadoop tutorial  https://developer.yahoo.com/hadoop/tutorial/index.htm l
  144. 144. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 145 Typical problems  Large number of nodes in the clusters  Relevant probability of failures,  CPU: when hundreds of thousands of nodes are present  Network: congestion may lead to do not provide data results and data inputs in times  Network: failure of apparatus  Mem: run out of space  Storage: run out of space, failure of a node, data corruption, failure of transmission  Clock: lack of synchronization, locked files and records not released, atomic transactions may lose connections and consistency  Specific parallel solutions provide support for recovering from some of these failures
  145. 145. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 146 Typical problems  Hadoop has no security model, nor safeguards against maliciously inserted data.  It cannot detect a man-in-the-middle attack between nodes  it is designed to handle very robustly hardware failure data congestion issues  Storage may be locally become full:  Reroute, redistribute mechanisms are needed  Synchronization among different nodes is needed  This may cause: network saturation Deadlock in data exchange
  146. 146. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 147 Recovering from failure  If some node fails in providing results in time, the other nodes should do the work of the missing node  The recovering process should be performed automatically  The Solution may be not simple to implement in non simple parallel architectures, topologies, data distribution, etc.  Limits:  Individual hard drives can only sustain read speeds between 60-100 MB/second  assuming four independent I/O channels are available to the machine, that provides 400 MB of data every second
  147. 147. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 148 Hadoop data distribution  Is based on the Hadoop Distributed File System (HDFS) that distribute data files on large chunks on the different nodes  Each chunk is replicated across several nodes, thus supporting the failure of nodes.  An active process maintains the replications when failures occurs and when new data are stored.  Replicas are not instantly maintained aligned !!!
  148. 148. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 149 Processes vs Data  Processes works on specific chunks of data. The allocations of processes depend on the position of the chunks they need to access,  That is: data locality.  This minimize the data flow among nodes  Avoid communications among nodes to serve computational nodes  Hadoop is grounded on moving computation to the data !!! And **not** data to computation.
  149. 149. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 150 MapReduce: Isolated Processes  The main idea:  Each individual record is processed by a task in isolation from one another. Replications allow to reduce communications for: contour conditions, data overlap, etc.  This approach does not allow any program to be executed.  Algorithms have to be converted into parallel implementations to be executed on cluster of nodes.  This programming model is called MapReduce model
  150. 150. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 151 Mappers and Reducers
  151. 151. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 152 How it works  Programmer has to write the Mappers and the Reducers  The data migration  from Nodes hosting mappers’ outputs  to nodes needing those data to processing Reducers  is automatically implicitly performed if these data is specifically tagged  Hadoop internally manages all of the data transfer and cluster topology issues.  This is quite different from traditional parallel and GRID computing where the communications have to be coded may be with MPI, RMI, etc.
  152. 152. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 153 Hadoop Flat Scalability  Hadoop on a limited amount of data on a small number of nodes may not demonstrate particularly stellar performance as the overhead involved in starting Hadoop programs is relatively high.  parallel/distributed programming paradigms such as MPI (Message Passing Interface) may perform much better on two, four, or perhaps a dozen machines.  specifically designed to have a very flat scalability curve  If it is written for 10 nodes may work on thousands with small rework effort
  153. 153. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 154 Releasing job on Hadoop
  154. 154. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 155 An example of WordCount  Mapper map(key1, value1)  list(key2, value2b)  Reducer: reduce (key2, list (value2))  list(key3, value3)  When the mapping phase has completed, the intermediate (key, value) pairs must be exchanged between machines to send all values with the same key to a single reducer. list(key2, value2a) nOther sources
  155. 155. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 156 Mapping input and ouput  Document1:  Queste sono le slide di Mario Rossi  Document2:  Le slide del corso di Sistemi Distribuiti  Mapping output:  list(key2, value2)  Queste, Document1  sono, Document1  le, Document1  slide, Document1  di, Document1  Mario, Document1  Rossi, Document1  Le, Document2  slide, Document2  del, Document2  corso, Document2  di, Document2  Sistemi, Document2  Distribuiti, Document2
  156. 156. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 157 Reduce input  reduce (key2, list (value2))  list(key3, value3)  Queste, Document1  sono, Document1  le, Document1  slide, list (Document1, Document2)  di, list (Document1, Document2)  Mario, Document1  Rossi, Document1  Le, Document2  corso, Document2  Sistemi, Document2  Distribuiti, Document2
  157. 157. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 158 Reducer Output as ……  inverted index (the previous example)  …  le, Document1  slide, list (Document1, Document2)  di, list (Document1, Document2)  …  Counting Words  …  le, 1  slide, 2  di, 2  … • mapper (filename, file-contents): • for each word in file-contents: • emit (word, 1) • • reducer (word, values): • sum = 0 • for each value in values: • sum = sum + value • emit (word, sum)
  158. 158. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 159 pertanto  Gli esempi sono due  1) Conteggio delle parole nei vari testi, distribuzione della frequenza delle parole  Tipicamente usato in algoritmi di stima della similarita’ in base al numero di parole simili ed al loro peso (frequenza in un certo dominio, documento)  2) generazione di una lista di sorgenti per ogni parala.  Esempio di indice inverso
  159. 159. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 160
  160. 160. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 161 public static class MapClass extends MapReduceBase implements Mapper <LongWritable, Text, Text, IntWritable> { private final static IntWritable one = new IntWritable(1); private Text word = new Text(); public void map (LongWritable key, Text value, OutputCollector<Text, IntWritable> output, Reporter reporter) throws IOException { String line = value.toString(); StringTokenizer itr = new StringTokenizer(line); while (itr.hasMoreTokens()) { word.set(itr.nextToken()); output.collect(word, one); } } }
  161. 161. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 162 /*** A reducer class that just emits the sum of the input values. */ public static class Reduce extends MapReduceBase implements Reducer <Text, IntWritable, Text, IntWritable> { public void reduce (Text key, Iterator<IntWritable> values, OutputCollector<Text, IntWritable> output, Reporter reporter) throws IOException { int sum = 0; while (values.hasNext()) { sum += values.next().get(); } output.collect(key, new IntWritable(sum)); } }
  162. 162. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 163 driver public void run(String inputPath, String outputPath) throws Exception { JobConf conf = new JobConf(WordCount.class); conf.setJobName("wordcount"); // the keys are words (strings) conf.setOutputKeyClass(Text.class); // the values are counts (ints) conf.setOutputValueClass(IntWritable.class); conf.setMapperClass(MapClass.class); conf.setReducerClass(Reduce.class); FileInputFormat.addInputPath(conf, new Path(inputPath)); FileOutputFormat.setOutputPath(conf, new Path(outputPath)); JobClient.runJob(conf); }
  163. 163. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 164
  164. 164. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 165 Reducer
  165. 165. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 166 Esempio di elaborazione locale spaziale 1 2 3 4 5 6 7 8 9  Map (arrange data and put lables/keys):  Extract submatrix from file  Create 3x3 (or NxN) data with a single Key  Reduce:  Ex A) Make the estimation of average  Ex B) make filtering  Ex c) perform derivative for optical flow, etc.  Etc. etc.
  166. 166. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 168 references P. Bellini, I. Bruno, D. Cenni, P. Nesi, "Micro grids for scalable media computing and intelligence on distributed scenarious", IEEE Multimedia, Feb 2012, Vol.19, N.2, pp.69.79, IEEE Computer Soc. Press  P. Bellini, M. Di Claudio, P. Nesi, N. Rauch, "Tassonomy and Review of Big Data Solutions Navigation", in "Big Data Computing", Ed. Rajendra Akerkar, Western Norway Research Institute, Norway, Chapman and Hall/CRC press, ISBN 978-1-46-657837-1, eBook: 978-1-46-657838-8, july 2013  ALEX HOLMES, Hadoop in Practice, 2012 by Manning Publications Co. All rights reserved.  I. Foster, C. Kesselman, The Grid, 2nd ed. Morgan Kaufmann, 2004.  F. Berman, G. Fox, T. Hey, Grid Computing, Wiley, 2003.  Burkhardt J. , et al., Pervasive Computing, Addison Wesley, 2002.  Hansmann U., Merk L., Nicklous M.S., Stober T., Pervasive Computing, Springer Professional Computing, 2nd ed., 2003.  A. S. Tanenbaum, M. Van Steen, "Distributed Systems", Prentice Hall, 2002 nhttp://www.globus.org nhttp://www.axmedis.org nhttp://www.cs.wisc.edu/condor
  167. 167. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 169 For More Information l Globus Project™  www.globus.org l Grid Forum  www.gridforum.org l Book (Morgan Kaufman)  www.mkp.com/grids l Survey + Articoli  www.mcs.anl.gov/~foster
  168. 168. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 170 Reference  Yahoo tutorial  https://developer.yahoo.com/h adoop/tutorial/index.html  Book:  ALEX HOLMES, Hadoop in Practice, 2012 by Manning Publications Co. All rights reserved.
  169. 169. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2013-2014 171 Sistemi Distribuiti Corso di Laurea in Ingegneria Prof. Paolo Nesi 2014 Parte 6: Architetture Parallele, Sistemi GRID, big data computing, Map Reduce Dipartimento di Ingegneria dell’Informazione, University of Florence Via S. Marta 3, 50139, Firenze, Italy tel: +39-055-4796523, fax: +39-055-4796363 DISIT Lab http://www.disit.dinfo.unifi.it/ paolo.nesi@unifi.it

×