Universit degli Studi di Roma Tor Vergata

Dipartimento di Ingegneria Civile e Ingegneria Informatica

Sistemi di computing e
storage nel Cloud
Corso di Sistemi Distribuiti e Cloud Computing
A.A. 2013/14
Valeria Cardellini

MapReduce
Modello di programmazione per processare ed
elaborare grandi quantit di dati distribuiti su larga scala
http://labs.google.com/papers/mapreduce.html

Anche implementazione di un sistema che esegue i

relativi programmi
Alcuni esempi di applicazioni:

Web indexing
Reverse Web-link graph
Distributed sort
Web access statistics

MapReduce fornisce

Funzioni definite dallutente

Parallelizzazione e distribuzione automatica
Tolleranza ai guasti
Scheduling dellI/O
Monitoraggio

Valeria Cardellini - SDCC 2013/14

MapReduce: modello

Elaborazione in due stadi: Map e Reduce

Map e Reduce sono scritte dallo sviluppatore
Input ed output: insieme di coppie chiave/valore
Map
Esegue una funzione su valori individuali di un set di dati per
creare una nuova lista di valori
map (in_key, in_value) -> list(out_key, intermediate_value)
Esempio: square x = x * x
map square [1,2,3,4,5]
returns [1,4,9,16,25]

Reduce
Combina valori in un set di dati per creare un nuovo valore
reduce (out_key, list(intermediate_value)) -> list(out_value)
Esempio: sum = (each elem in arr, total +=)
reduce [1,4,9,16,25]
returns 55 (la somma degli elementi)
2

Valeria Cardellini - SDCC 2013/14

MapReduce: esempio
Contare il numero di occorrenze di ciascuna parola in
una grande collezione di documenti (WordCount)
Map(String key, String value):
// key: document name
// value: document contents
for each word w in value:
EmitIntermediate(w, 1 );

Map emette ciascuna parola con un semplice 1

associato

Valeria Cardellini - SDCC 2013/14

MapReduce: esempio (2)

Reduce (String key, Iterator values):
// key: a word
// values: a list of counts
int result=0
for each v in values:
result += ParseInt(v)
Emit(AsString(result))

Reduce somma tutti gli 1 emessi per una parola

per ottenere il totale
Quello mostrato pseudo-codice; per il codice
completo dell esempio vedere http://labs.google.com/
papers/mapreduce.html
Valeria Cardellini - SDCC 2013/14

MapReduce: schema di implementazione

Valeria Cardellini - SDCC 2013/14

Hadoop
Apache Hadoop provides open-source software for
reliable, scalable, distributed computing
Includes Hadoop MapReduce for easily writing applications
which process vast amounts of data (multi-terabyte datasets) in-parallel on large clusters (thousands of nodes) of
commodity hardware in a reliable, fault-tolerant manner
See
http://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html
for the WorkCount code

Apache Hadoop NextGen MapReduce (YARN):

MapReduce 2.0

Valeria Cardellini - SDCC 2013/14

Data storage in the Cloud

Various forms of data storage in the Cloud:
NoSQL databases (or more generally, data stores)
Examples: BigTable, Cassandra, MongoDB, Hbase, SimpleDB,
DynamoDB

Key-value storage systems

Examples: Dynamo, Couchbase

Distributed file systems

Examples: Google File System (GFS), Hadoop Distributed File
System (HDFS)

Goals: massive scaling on demand (elasticity) and

simplified application development and deployment
Some systems offered only as Cloud services
either directly (e.g., Amazon SimpleDB) or as part of a
programming environment

Other systems used only within a particular company

(e.g., Dynamo, GFS)

Valeria Cardellini - SDCC 2013/14

NoSQL data stores

NoSQL = Not Only SQL
SQL-style querying is not the crucial objective
A large number of immensely diverse data stores not based
on the relational data model (key-value data stores,
document stores, column-family stores, graph databases)

Main features of NoSQL data stores

Support flexible schema
Scale horizontally
Provide scalability and high availability by storing and
replicating data in distributed systems, often across
datacenters
Do not typically support ACID properties, but are rather
referred as BASE systems

Valeria Cardellini - SDCC 2013/14

NoSQL data stores (2)

Useful when working with a huge quantity of data
when the datas nature does not require a relational
model
Traditional join operations cannot be used

Barriers to NoSQL adoption:

No full ACID transaction support
Lack of standardized interfaces
Huge investments already made in SQL by enterprises

Valeria Cardellini - SDCC 2013/14

Dynamo
Sistema di storage usato da numerosi servizi
di base nella piattaforma di Amazon
Sistema di storage di tipo chiave-valore
altamente disponibile e scalabile
Idea di base: gestire i fallimenti la modalit
standard di funzionamento
Ad es., per il servizio di shopping cart: Customers should be
able to view and add items to their shopping cart even if disks
are failing, network routes are flapping, or data centers are
being destroyed by tornados

Garantire il rispetto di Service Level Agreements

Ad es., service guaranteeing that it will provide a response
within 300ms for 99.9% of its requests for a peak client load of
500 requests per second.

G. DeCandia et al., "Dynamo: Amazon's highly available key-value

store", Proc. of ACM SOSP 2007.
Valeria Cardellini - SDCC 2013/14

10

Piattaforma di Amazon

Valeria Cardellini - SDCC 2013/14

11

Caratteristiche di Dynamo
Semplice interfaccia chiave/valore
Semplici operazioni di lettura (get) e scrittura (put) su oggetti
identificati in modo univoco da una chiave
Oggetti di dimensione < 1MB
Le operazioni coinvolgono un solo oggetto alla volta

Elevata disponibilit con una finestra di consistenza

definita (eventual consistency)
Propriet BASE (Basically Available, Soft-state, Eventual
consistent) anzich ACID

Uso efficiente delle risorse

Schema semplice di scale-out per gestire l aumento di
dimensione del set di dati o dei tassi di richieste
Solo uso interno di Dynamo:
ambiente operativo non ostile e quindi no requisiti relativi a
sicurezza (ad es. autorizzazione ed autenticazione)
Valeria Cardellini - SDCC 2013/14

12

Principi progettuali di Dynamo

Sacrificare la consistenza forte in favore della
disponibilit (vedi teorema CAP)
Uso di tecniche di replicazione ottimistiche
Possono verificarsi aggiornamenti conflittuali che devono
essere individuati e risolti: quando e chi risolve i conflitti?
Quando: risoluzione dei conflitti eseguita durante operazioni
di read anzich di write, ossia always writeable
Chi: data store o applicazione; se data store si usa una
politica semplice (ad es. last write wins )

Ulteriori principi:
Scalabilit incrementale
Aggiunta di nodi senza compromettere il funzionamento del
sistema

Simmetria e decentralizzazione
Tecniche dei sistemi P2P

Eterogeneit
Valeria Cardellini - SDCC 2013/14

13

Interfaccia di sistema di Dynamo

Ad ogni oggetto memorizzato associata una chiave
Semplice interfaccia che espone operazioni di get()
e put() usata per accedere agli oggetti
get(key): individua tutte le repliche dell oggetto associato
alla chiave e restituisce un singolo oggetto o un elenco di
oggetti con versioni contrastanti insieme a un contesto
put(key, context, object): determina dove devono
essere memorizzate le repliche dell oggetto in base alla
chiave associata e scrive le repliche su disco
Il contesto codifica i metadati di sistema, ad esempio la
versione dell oggetto
Sia la chiave che l oggetto sono trattati come un array di byte
opaco
Hash MD5 applicato alla chiave per generare un identificatore
a 128 bit, usato per determinare i nodi del sistema di storage
che sono responsabili per servire quella chiave
14

Valeria Cardellini - SDCC 2013/14

Tecniche usate in Dynamo

Problem

Technique

Advantage

Partitioning

Consistent hashing
Vector clocks with
reconciliation during reads

Incremental scalability
Version size is decoupled
from update rates
Provides high availability
and durability guarantee
when some of the replicas
are not available
Synchronizes divergent
replicas in the background
Preserves symmetry and
avoids having a
centralized registry for
storing membership and
node liveness information

High Availability for writes

Handling temporary
failures

Sloppy Quorum and

hinted handoff

Recovering from
permanent failures

Anti-entropy using Merkle

trees

Membership and failure

detection

Gossip-based
membership protocol and
failure detection

Valeria Cardellini - SDCC 2013/14

15

Partizionamento in Dynamo
Consistent hashing: l intervallo di output della
funzione di hash viene trattato come uno spazio
circolare fisso o anello (in modo simile a Chord)
Nodi e chiavi sono mappati sull anello
A differenza di Chord: zero-hop DHT

Nodi virtuali : ogni nodo fisico pu essere

responsabile di pi di un nodo virtuale

Valeria Cardellini - SDCC 2013/14

16

Replicazione in Dynamo
Ogni oggetto replicato su N nodi
N un parametro configurabile dall applicazione che usa
Dynamo

Preference list: la lista di nodi che responsabile per

gestire una determinata chiave
Contiene pi di N nodi per gestire fallimenti
In figura: oggetto identificato dalla chiave K
replicato sui nodi B, C e D

Valeria Cardellini - SDCC 2013/14

17

Tecniche usate in Dynamo

Problem

Technique

Advantage

Partitioning

Consistent hashing
Vector clocks with
reconciliation during reads

Incremental scalability
Version size is decoupled
from update rates
Provides high availability
and durability guarantee
when some of the replicas
are not available
Synchronizes divergent
replicas in the background
Preserves symmetry and
avoids having a
centralized registry for
storing membership and
node liveness information

High availability for writes

Handling temporary
failures

Sloppy Quorum and

hinted handoff

Recovering from
permanent failures

Anti-entropy using Merkle

trees

Membership and failure

detection

Gossip-based
membership protocol and
failure detection

Valeria Cardellini - SDCC 2013/14

18

Data versioning in Dynamo

Una chiamata a put() pu ritornare al chiamante
prima che l aggiornamento sia stato applicato a tutte
le repliche
Una chiamata a get() pu restituire molteplici
versioni dello stesso oggetto
Problema: un oggetto pu avere diverse versioni, che
il sistema dovr riconciliare
Soluzione: uso dei clock vettoriali per catturare la
casualit tra diverse versioni dello stesso oggetto

Valeria Cardellini - SDCC 2013/14

19

Tecniche usate in Dynamo

Problem

Technique

Advantage

Partitioning

Consistent hashing
Vector clocks with
reconciliation during reads

Incremental scalability
Version size is decoupled
from update rates
Provides high availability
and durability guarantee
when some of the replicas
are not available
Synchronizes divergent
replicas in the background
Preserves symmetry and
avoids having a
centralized registry for
storing membership and
node liveness information

High Availability for writes

Handling temporary
failures

Sloppy Quorum and

hinted handoff

Recovering from
permanent failures

Anti-entropy using Merkle

trees

Membership and failure

detection

Gossip-based
membership protocol and
failure detection.

Valeria Cardellini - SDCC 2013/14

20

Sloppy quorum in Dynamo

R/W il minimo numero di nodi che devono
partecipare ad un operazione di read/write
L impostazione di R + W > N determina un sistema
quorum-like
In questo modello, la latenza di un operazione di get (o put)
determinata dalla replica pi lenta tra le R (o W) repliche
Per migliorare la latenza, R e W possono essere configurati
in modo da essere minori di N
Configurazione tipica in Dynamo: (N, R, W) = (3, 2, 2)

Sloppy quorum
Tutte le operazioni di read/write sono eseguite dai primi N
nodi funzionanti presi dalla preference list (non sempre
coincidono con i primi N nodi sull anello relativi alla data
chiave)

Valeria Cardellini - SDCC 2013/14

21

Hinted handoff in Dynamo

Sia N = 3; se A
temporaneamente gi o non
raggiungibile durante una
scrittura, si invia la replica a D
D sa che la replica appartiene
ad A:
gliela inoltrer appena A torna ad
essere funzionante
terminato con successo l invio ad
A, D cancella la replica

Viene applicato anche in questo

caso il principio progettuale
always writeable
22

Valeria Cardellini - SDCC 2013/14

Caratteristiche di GFS
File system distribuito implementato in user space
Gestione di file di dimensioni molto grandi (multi GB)
File suddiviso in chunk di dimensione fissa (64MB)
Chunk memorizzati come normali file sui chunk server

Scrittura in modalit append: aggiungendo dati alla

fine del file (possibili append concorrenti)
Elevata affidabilit, ottenuta mediante replicazione
dei chunk
No caching dei dati

S. Ghemawat, H. Gobioff, S.-T. Leung, "The Google File System",

Proc. of ACM SOSP 2003.

Valeria Cardellini - SDCC 2013/14

23

Nodi in GFS
Due tipi di nodi
Master
Chunk server

Chunk server
Memorizzano i chunk

Master

Singolo master: per semplificare l architettura

Coordina l accesso ai chunk
Non memorizza chunk, ma soltanto metadati relativi ai chunk
Gestisce il mantenimento dell opportuno grado di
replicazione dei chunk

Valeria Cardellini - SDCC 2013/14

24

Replicazione e tolleranza ai guasti in GFS

Ogni chunk replicato su pi chunk server
3+ chunk server per ciascun chunk
Grado di replicazione >3 per chunk soggetti ad elevato tasso
di richieste
Replicazione dei chunk gestita con schema primary-backup

Integrit dei dati

Checksum di 32B per ogni blocco di 64KB in ciascun chunk

Valeria Cardellini - SDCC 2013/14

25

Architettura di GFS

In figura: operazione di lettura

- Chunk handle ~ file name del chunk
- Il client interagisce con il master per aprire e trovare il file
- Il client interagisce con il chunk server per i dati
Valeria Cardellini - SDCC 2013/14

26

Architettura di GFS (2)

Quale il punto debole potenziale di questa architettura?

Il master singolo!
Single point of failure
Scalability bottleneck
Valeria Cardellini - SDCC 2013/14

27

Master singolo in GFS

Soluzioni adottate in GFS per evitare
problemi legati al master singolo:
Per evitare single point of failure: presenza di pi
master ombra che forniscono accesso read-only al
file system in caso di non disponibilit del master
Per evitare scalability bottleneck: minimizzare il
coinvolgimento del master
Mai dati sul master, ma solo metadati
In pi caching dei metadati lato client
Dimensione grande dei chunk
Il master delega la propria autorit alle repliche primarie
per gestire le mutazioni dei dati (lease dei chunk)

Semplice!
28

Valeria Cardellini - SDCC 2013/14

Interfaccia di GFS
I file sono organizzati gerarchicamente in directory e
identificati da pathname, ma GFS:
Non ha una struttura dati per directory
Non supporta alias

Operazioni tradizionali su un file system:

create, delete, open, close, read, write

In pi:
snapshot: crea una copia di un file o dell albero di una
directory
record append: appende dati ad un file (supporta append
atomiche, concorrenti)

Valeria Cardellini - SDCC 2013/14

29

Chunk size
Chunk size is 64 MB (much larger than typical block
sizes)
Large chunk size reduces:
number of interactions between client and master
network overhead by keeping a persistent TCP connection
to the chunk server over an extended period of time
size of metadata stored on the master

Potential disadvantage: chunks for small files may

become hot spots (requires higher replication factor)
Each chunk replica is stored as a plain Linux file and
is extended as needed

30

Valeria Cardellini - SDCC 2013/14

Metadati in GFS
Metadati memorizzati sul master
Spazio dei nomi di file e chunk
Mapping da file a chunk
Posizioni delle repliche di ciascun chunk

Metadati memorizzati in memoria (64 B per chunk)

Vantaggi: Veloce e facilmente accessibile
Limitazione: numero di chunk limitato dalle dimensioni della
memoria del master ( The cost of adding extra memory to the
master is a small price to pay for the simplicity, reliability,
performance, and flexibility gained )

Il master mantiene un log delle operazioni per registrare

in modo persistente aggiornamenti critici sui metadati
Persistenza su disco locale
Replicato
Checkpoint per recovery pi veloce
Valeria Cardellini - SDCC 2013/14

31

Mutazioni in GFS
Mutazione = write o append
Deve essere applicata ad ogni
replica
Obiettivo: minimizzare il
coinvolgimento del master

Meccanismo di lease:
Il master sceglie una replica come
primaria e le assegna un lease
per le mutazioni
Il primario definisce un ordine
seriale delle mutazioni
Tutte le repliche seguono
quest ordine

Flusso dei dati disaccoppiato

del flusso di controllo
Valeria Cardellini - SDCC 2013/14

32

Append atomico in GFS

Il client specifica i dati
GFS appende i dati al file in modo atomico almeno
una volta
GFS sceglie l offset
Funziona per scrittori concorrenti

Molto usato dalle applicazioni di Google

Ad es., per file che servono come code molteplici produttori/
singolo consumatore

Valeria Cardellini - SDCC 2013/14

33

Modello di consistenza in GFS

Modello di consistenza relaxed (eventual
consistency)
Consistente = tutte le repliche hanno lo stesso
valore
Definito = la replica riflette la mutazione,
consistente
Propriet:
Scritture concorrenti lasciano la regione in uno stato
consistente, ma eventualmente non definito
Il fallimento di scritture lascia la regione in uno stato
inconsistente

E un modello di consistenza semplice ed efficiente

Aggiornamento dello spazio dei nomi atomico e
serializzabile
Valeria Cardellini - SDCC 2013/14

34

Compiti del master in GFS

Memorizzazione dei metadati
Gestione/locking dello spazio dei nomi
Comunicazione periodica con i chunk server
Invia istruzioni, raccoglie informazioni di stato, controlla lo
stato di salute (messaggi di heartbeat)

Creazione, re-replicazione, bilanciamento dei chunk

Bilancia l utilizzazione dello spazio e la velocit di accesso
Distribuisce le repliche tra i rack del cluster per ridurre la
probabilit di fallimenti correlati
Ri-replica i dati se il grado di replicazione scende sotto la
soglia
Ri-bilancia i dati per bilanciare il carico sullo storage e delle
richieste

Valeria Cardellini - SDCC 2013/14

35

Compiti del master in GFS (2)

Garbage collection
Pi semplice ed affidabile del tradizionale delete di file
Registra la cancellazione e rinomina il file usando un nome
nascosto

Cancellazione di repliche vecchie

Individua le repliche vecchie usando i numeri di versione dei
chunk

36

Valeria Cardellini - SDCC 2013/14

GFS problems
GFS was designed (in 2001) with MapReduce in mind
But found lots of other applications
Designed for batch applications with large files (web crawling
and indexing) but wrong for applications like Gmail or YouTube,
meant to serve data in near real-time

Problems
Single master node in charge of chunk servers
All metadata about files stored in the master s memory: limits
total number of files
Problems when storage grew to tens of Pbytes
Automatic failover added (but still takes 10 seconds)
Designed for high throughput but delivers high latency: not
appropriate for latency sensitive applications
Delays due to recovering from a failed replica chunkserver
delay the client
Valeria Cardellini - SDCC 2013/14

37

After GFS: Colossus

Colossus (GFS2)

Next-generation cluster-level file system at Google

Specifically designed for real-time services
Automatically sharded metadata layer
Data typically written using Reed-Solomon (1.5x)
Client-driven replication, encoding and replication
Distributed masters
Support smaller files: chunks go from 64 MB to 1 MB

38

Valeria Cardellini - SDCC 2013/14

Chubby
Servizio di lock a grana grossa
Offre un implementazione affidabile e scalabile di un
protocollo per il consenso distribuito (Paxos) incapsulata in
un API
Altri sistemi distribuiti (loosely-coupled) possono usarlo per
sincronizzare l accesso a risorse condivise

Servizio che fornisce

Sincronizzazione (elezione del leader, informazioni
condivise)
Affidabilit e disponibilit
Semantica semplice
Alte prestazioni, throughput e capacit di storage solo
aspetti secondari
M. Burrows, "The Chubby Lock Service for Loosely-Coupled
Distributed Systems", Proc. of OSDI 2006.
Valeria Cardellini - SDCC 2013/14

39

Esempi di utilizzo di Chubby

GFS: elezione del master
BigTable: elezione del master, discovery client,
locking delle tabelle
Posizione well-known per il bootstrap di sistemi
distribuiti di grandi dimensioni
Meccanismo di lock progettato per lock coarsegrained: mantenuti per ore o giorni
Minor carico sul lock server
I lock sopravvivono a fallimenti del lock server
Definizione di lock fine-grained al di sopra di Chubby

40

Valeria Cardellini - SDCC 2013/14

Interfaccia di Chubby
Presenta un semplice file system distribuito
Insieme ridotto di operazioni su file rispetto ad un
tradizionale FS distribuito

I client possono eseguire operazioni di open/

close/read/write su file
Letture e scritture solo di tipo whole-file
Supporto per lock reader/writer di tipo advisory
I client possono iscriversi per ricevere notifiche di
aggiornamento dei file

Valeria Cardellini - SDCC 2013/14

41

Architettura di sistema di Chubby

2 componenti principali:
Server (Chubby cell)
Client library
Comunicazione via RPC

Proxy
Opzionale
All client traffic
One Chubby Cell
Master
replica

replica

replica

replica

replica

42

Valeria Cardellini - SDCC 2013/14

Cella di Chubby
Cella: insieme di server replica
Generalmente 5 server: 1 master e 4 repliche

Usa Paxos per eleggere il master

Promessa di non eleggere un nuovo master per un certo
tempo (lease del master)
Il lease del master viene rinnovato periodicamente

Mantiene copie di un database semplice

Operazioni di write soddisfatte da un quorum di
maggioranza
Operazioni di read soddisfatte dal solo master
Sistema di replacement per repliche fallite

Valeria Cardellini - SDCC 2013/14

43

Elezione del master in Chubby

L elezione del master semplice
Tutte le repliche cercano di acquisire un lock in scrittura sul
file indicato
La replica che ottiene il lock il master
Il master pu poi scrivere il suo indirizzo nel file
Le altre repliche possono leggere questo file per scoprire chi
il master
Chubby si comporta come un servizio di naming

Valeria Cardellini - SDCC 2013/14

44
44

File, directory, handle in Chubby

Interfaccia simile a file system
Es. di nome: /ls/foo/wombat/pouch
API specializzata

Chubby non:
Supporta spostamento di file (move), link hard o simbolici
Mantiene semantica dei permessi dipendente dal path della
directory
Rivela data di modifica delle directory e data di ultimo
accesso ai file

Nodi (file o directory)

Di tipo permanent oppure ephemeral
Diversi metadati associati ad ogni nodo

Handle
Analoghi ai descrittori di file in Unix
Valeria Cardellini - SDCC 2013/14

45

Lock e sequencer in Chubby

Chubby utilizza un file o una directory come lock
lettore-scrittore
Un client pu tenere il lock in modo esclusivo (writer)
Un qualunque numero di client pu tenere il lock in modo
condiviso (reader)

I lock sono di tipo advisory (consultivo)

E compito del client comportarsi bene e controllare che il
lock non sia tenuto da altri client (in modo analogo ai mutex)
Soluzione opposta: lock di tipo mandatory (vincolante)

E costoso numerare tutte le interazioni in un SD

In Chubby sono numerate solo le interazioni che usano i lock

Sequencer: stringa di byte che descrive lo stato del

lock dopo l'acquisizione
Il possessore di un lock pu richiedere il sequencer
Un client passa il sequencer al server
46

Valeria Cardellini - SDCC 2013/14

API di Chubby
Open()
Creazione dell handle
Specifica come verr usato l handle (controllo degli accessi,
eventi che devono essere notificati, )

Close() e Poison()
Close() per chiudere un handle aperto
Poison() per far fallire le operazioni in corso o successive su
un handle senza chiudelo

Altre chiamate dell API:

GetContentsAndStat(), GetStat, SetContents() per
leggere contenuto e metadati di un file e scriverne il contenuto
Delete() per cancellare un nodo
Acquire(), TryAcquire(), Release() per acquisire e
rilasciare lock
GetSequencer(), SetSequencer(),
CheckSequencer() per operazioni su sequencer
Valeria Cardellini - SDCC 2013/14

47