1

Cloud Data Management

Kapitel 2: Infrastrukturund Services

Dr. Michael HartungSommersemester 2012

Universität LeipzigInstitut für Informatikhttp://dbs.uni-leipzig.de

2

Inhaltsverzeichnis

• Hardware-Infrastruktur– Grundideen performanter Datenverarbeitung in der Cloud

– Aufbau eines Data Centers

• Dateisysteme für die Cloud– Google File System, Hadoop File System

• Software-Infrastruktur– Aufbau, Anforderungen und Ziele

– Cloud-Dienste: Software/Platform/Infrastructure as a Service

• Cloud-Anbieter– Beispiel: Amazon

3

“Big Ideas”

• Scale “out” statt scale “up”– Grenzen von SMPs (symmetric multi-processors) und großen Shared-Memory-

Maschinen

• Freie Skalierbarkeit– Flexible Nutzung von Rechner-Ressourcen (“1000 Rechner für 1 Minute”)

• Sequentielle Datenverarbeitung statt wahlfreiem Datenzugriff– Festplatten: Seeks sind teuer, Datendurchsatz akzeptabl

• Datenverarbeitung dort, wo die Daten liegen (geringe Zugriffszeit)– Vermeiden unnötigen Datentransfers

4

Scale-up vs. Scale-out [DGLS99 ff]

• Scale-up = vertikale Skalierung– schnellere SMP-Knoten

– Shared Everything

• Scale-out = horizontale Skalierung– N unabhängige Rechner (z.B. Commodity Server)

– Hinzufügen neuer Rechner nach Bedarf

– Shared Nothing oder Shared Disk (Cluster)

• Scale-out in Cloud-Data-Center mit preiswerter Standard-Hardware– geringere Kosten, geringere Administrationsaufwand, leichte Erweiterbarkeit, ...

– Alternative: geringere Zahl von High-End-Servern

5

Aufbau eines Datacenters

Server• CPUs• DRAM• Disks

Rack• 40-80 Server• Ethernet Switch Cluster

[BH09]

6

Aufbau eines Datacenters (2)

Source: Barroso and Urs Hölzle (2009)

[BH09]

7

Storage Hierarchy

[BH09]

8

Standard-Hardware statt “High-End”

• Standard-Hardware ist kosteneffizienter pro “Leistungseinheit”

• Ähnliche Ausfallwahrscheinlichkeiten, geringerer Stromverbrauch

• Nahezu beliebige Skalierbarkeit (“pay as you go/grow”)

[BH09]

9

(Ökonomische) Gründe für Data Centers

• Sehr große (50.000 Server) Data Centers kostengünstiger als mittelgroße (1.000 Server)– Faktor 5-7 pro Ressource (Netzwerk, Speicher, Administratoren, ...)

• Virtualisierung ermöglich (nahezu) freie Standortwahl nach ökonomischen Gesichtspunkten– Strompreis, Löhne, Steuern, ...

• Große Web-Firmen (Google, Amazon, ...) benötigen große Infrastrukturen – ... die aber nicht ständig zu 100% ausgelastet sind

– Vermietung von Ressourcen als “Zusatzgeschäft”

http://www.slideshare.net/ISSGC/session-58-cloud-computing-virtualisation-and-the-future-speaker-ake-edlund

10

Kommunikationskosten

• Parallelverarbeitung erzwingt Kommunikation zwischen Knoten/Cores– SMP (shared memory): Latenz ~100 ns

– LAN: Latenz ~100 µs

• Scaling “up” vs. scaling “out”– Kleines Cluster of High-End-SMPs vs. großes Cluster of Low-End-SMPs

– Bsp: 8 × 128-Core-SMP vs. 128 × 4-Core-SMP

• Einfaches Kostenmodell– Gesamtkosten: Kosten für Berechnung (1ms) + Kosten für (globalen) Datenzugriff

– Für n Knoten (keine Berücksichtigung der Cores)

• Light communication: f =1

• Medium communication: f =10

• Heavy communication: f =100

Source: analysis on this an subsequent slides from Barroso and Urs Hölzle (2009)

1 ms + f × [100 ns × n + 100 µs × (1 - 1/n)]

11

Kommunikationskosten (2)

• Vergleich: 1 × n⋅m-Core vs. n × m-Core

• 1 × n⋅m-Core bis zu 10mal schneller als entsprechendes n × m-Core Cluster

• keine Veränderung ab n=8

[BH09]

12

Kommunikationskosten (3)

• Vergleich: (c/128) × 128-Core vs. (c/4) × 4-Core – Bsp: Cluster size = 512 entspricht 4 × 128-Core vs. 128 × 4-Core

• Sobald “High-End-Server” geclustert werden (müssen), sinkt der Performanzvorteil deutlich, z.B. <15% ab 1024 cores

• Standard-Hardware-Cluster hat ähnliche Performanz bei deutlich geringeren Kosten

[BH09]

13

Seeks vs. Scans

• Sequentielle Verarbeitung großer Datenmengen performant da aufwändige Seeks entfallen– Seek = Positionierung des Lese-Schreibkopfes auf Platte

• Beispiel– Datenbank mit 1010 Datensätzen à 100 Byte → 1 TB

– Update 1% aller Datensätze

• Variante 1: Updates mit Random Access

• Variante 2: Neuschreiben aller Datensätze

Source: Ted Dunning, on Hadoop mailing list

14

Datenzugriff

• Verarbeitung großer Datenmengen u.a. beeinflusst von Zugriffszeiten

• Ziel: Verarbeitung “nah an” den Daten

L1 cache reference 0.5 ns

Branch mispredict 5 ns

L2 cache reference 7 ns

Mutex lock/unlock 25 ns

Main memory reference 100 ns

Send 2K bytes over 1 Gbps network 20,000 ns

Read 1 MB sequentially from memory 250,000 ns

Round trip within same datacenter 500,000 ns

Disk seek 10,000,000 ns

Read 1 MB sequentially from disk 20,000,000 ns

Send packet CA → Netherlands → CA 150,000,000 ns

[De09]

15

Dateisysteme und verteilte Dateisysteme

• Dateisystem– System für permanente Datenspeicherung

– Zugriffsschicht für physischen Datenträger (HDD, DVD, ...)

– Basisobjekt: Datei

– eindeutig referenziert durch Namen und (hierarchischen) Pfad

– Beispiele: FAT32, NTFS, ext4, ...

• Verteiltes Dateisystem– ermöglicht Zugriff auf Dateien anderer Rechner (Server)

– Problemfälle• Concurrency

• Replication

• Caching

– Beispiele: DFS, NFS, ...

Dateisystem (für Nutzer/Anwendung)

NTFS EXT4 NFSClientHDD1 HDD2

NFSServer

Dateisystem(Server)

EXT4

HDD1

EXT4

HDD2

16

Notwendigkeit neuer Dateisysteme für Cloud

Lokal / Netzwerk Cloud

Nutzer Anwender, (lokale) Programme

Beispiele TextverarbeitungFotoverwaltung

Anzahl der Dateien

sehr viele (>>1,000,000)

Größe der Dateien

kleine (KB-MB)

Lesezugriff teilw. concurrent, komplett

Schreibzugriff mehrfach Überschreiben

17

Google File System

• Proprietäres, verteiltes Linux-basiertes Dateisystem – Hochskalierend: tausende Festplatten, mehrere 100TB

– Open Source-Alternative: Hadoop Distributed File System

• Netzknoten: „billige“ Standardhardware (kein RAID)– Hardwarefehler- und ausfälle sind Regelfall; Gewährleistung von Datensicherheit

• optimiert für Streaming Access– File-Änderungen durch Anhängen: write once - read many times

– Verteiltes, sequentielles Lesen (blockweise)

• Hoher Durchsatz statt geringer Latenz

• Physische Datenpartitionierung in Chunks (Default: 64 MB)– Verteilung über mehrere Chunkserver (und Replizierung jedes Chunks)

• Master-Server– Mapping: Datei->Chunk->Node

– Replikat-Management: Default 3 Chunk-Kopien (in 2 Racks)

– Anfragebearbeitung, Zugriffsverwaltung

18

Google File System: Architektur

[GGL03]

19

Master

• Metadata-Management– Mapping Datei > Chunk > ChunkServer (Node)

– Alles im Hauptspeicher (performant)• 64 byte pro Chunk, “wenige” Dateien

• Logfile– persistentes Logging kritischer Metadaten-Updates

– Repliziert, Checkpoints (Revovery)

• Single-Master-Problem (Single Point of Failure, Bottleneck)– Shadow Masters

• haben (“recent”) Kopie des Mappings; springen bei Ausfall ein

– Reduzierter Workload für Master• nur Metadaten

• große Chunksize (64MB), damit wenige Metadaten / Interaktion / Netzwerk Overhead

• Authority-Weiterreichung an Primary Replicas bei Datenänderung (Lease)

20

Datenmanipulation

• Mutation (Schreiben oder Anhängen)– muss für alle Replikate

durchgeführt werden

• Lease Meachnismus– Master bestimmt ein Replica zur

Koordinierung (“lease for mutation”)

– Primary Replica sendet Folge von Mutations-Operationen an alle Secondary Replicas

– Reduzierte Master-Workload

– Datenfluss von Kontrollfluss entkoppelt

• Append-Operation– GFS hängt Daten von Client an File an

– GFS bestimmt Offset, damit parallele Schreibzugriffe möglich

– optimiert für Multiple-Producer-Single-Reader-Queues (z.B. MapReduce)

[GGL03]

21

Hadoop

• Framework für skalierbare und verteilte Software– frei, open-source, Java

• (z.T.) “Nachbau” proprietärer Systeme– GFS/HDFS, BigTable/HBase, MapReduce

http://www.slideshare.net/cloudera/tokyo-nosqlslidesonly

22

Hadoop File System: Architektur

[HDFS]

GFS Master=HDFS Namenode, GFS ChunkServer = HDFS Datanode

23

GFS/HDFS: ZusammenfassungEigenschaft Technologie / Idee

Metadaten

Instanzdaten

Zuverlässigkeit

Lese-Operation

Schreib-Operation

• Auf GFS/HDFS abgestimmte Programmiermodelle (z.B. MapReduce)– “Moving Computation is Cheaper than Moving Data”

– Ziel: Berechnung auf gleichem (oder nahem) Knoten wie Daten

24

Software-Infrastruktur

Facilities

Hardware

Abstraction

Connectivity & Delivery

APIs

Integration & Middleware

DataMetaData

Content

Applications

APIs

Presentation Modality/Platform

Infra

stru

ctur

e as

a S

ervi

ce

Plat

form

as

a Se

rvic

e

Softw

are

as

a Se

rvic

e

The frogs who desired a king.http://www.rationalsurvivability.com/blog/?p=567

IPAM/DNS, Transport, Security, Auth.

VMM, Grid/Cluster, Images

Compute, Network, Storage

Power, HVAC, Space

Structured/Unstructured

Database, Messaging, Queueing

Management

Data/Voice/Video, PC/Embedded/Mobile

Native, Web, Emulated

25

Cluster-Level Software: Anforderungen

• Ressource Management– Zuordnung von Tasks zu Ressourcen

– Ziel: Performanz, effizienter Energieverbrauch

• Hardware Abstraction– Virtualisierung

– Ziel: Einheitlicher (einfacher) Ressourcen-Zugriff

• Deployment und Maintenance– Software-Upgrades, Monitoring

– Ziel: geringerer Nutzer/Administrator-Aufwand

• Programming Framework– einfache Realisierung paralleler/web-scale Anwendungen

– Ziel: Erhöhung der Produktivität von Programmierern

26

Cluster-Level-Software: Besonderheiten

• vs. Desktop-Software– inhärente Parallelität

• effiziente Ausnutzung aller verfügbarer Ressourcen

– relativ homogene Plattform• begrenzte Heterogenität durch schrittweise Ersetzen defekter Hardware

– große Varianz in Workload• Varianz der Applikationen, Nutzungsvarianz (Peaks), ...

– “Fault-free“-Anforderung• Verfügbarkeit trotz täglicher Hardware-Defekte auf Grund Größe eines Data Centers

• vs. High Performance Computing– nicht vorhersagbarer (Daten-)Input

• Umfang, Schema, ...

– sehr große Datenvolumina• z.T. auch bei HPC

– nicht nur Computing• Speicher-Dienste, Datenbanken, Web-Applikationen, ...

27

Techniken für Performance & Availability

• Replication– Redundante Speicherung von Daten

– Anwendung: u.a. Dateisystem (GFS/HFS), Storage Service (Amazon Dynamo)

• Load Balancing– Workload-Aufteilung auf mehrere Knoten

– Anwendung: parallele Programmierung (MapReduce), WebApps (Google App Engine)

• Data Partitioning– Aufteilung eines Datenbestandes in mehrere Partitionen zur effizienten Bearbeitung

– Anwendung: u.a. Cloud-Datenbank (Bigtable), parall. Programmierung (MapReduce)

• Eventual Consistency– Änderungen am Datenbestand werden nicht sofort an Replikate weitergereicht

– Anwendung: Storage Service (Amazon Dynamo)

• Weitere– Überprüfung ob Nodes “still alive”, Überprüfung der Datenintegrität, Datenkompression

28

Techniken für Performance & Availability (2)Performance Availability

Replication Schutz vor Datenverlust

Data Partitioning Recovery schneller bei (kleinen) Partitionen

Load Balancing---

Eventual Consistency

Effiziente parallele Writes

Health Checking und Integritäts-prüfung

---Identifikation fehlerhafter

Knoten; keine Requests an nicht verfügbare/langsame Knoten

Daten-kompression ---

29

Infrastructure as a Service

• Bereitstellung (Mieten) von Ressourcen + Infrastruktur-Tools– CPU, Storage, Network

– “Lokaler Server in der Cloud”

– früher: Utility Computing

• Keine automatische Skalierung

• Hohe Flexibilität– Bezahlung nach Nutzung (pro CPU-Stunde, pro MB, ...)

– Zeitraum und “Größe” frei wählbar (“1000 CPUs für 1 Stunde”)

• Beispiele– Amazon Elastic Compute Cloud (EC2), Rackspace

– Amazon Simple Storage Service (S3)

– Amazon Route 53

30

Platform as a Service

• Framework zur Entwicklung und Bereitstellung von Applikationen– Infrastruktur führt “hochgeladenen” Quellcode aus

• Begrenzte automatische Skalierung– Dynamische Allokation von Instanzen je nach Nutzungsaufkommen

– Dynamische Partitionierung von Daten möglich

• Mittlere Flexibilität– Bezahlung nach Nutzung (CPU, Speicher, Requests, ...)

– Einschränkungen beim Quellcode (Sprache, nutzbare Bibliotheken, ...)

• Beispiele– Amazon Elastic MapReduce, Hadoop MapReduce

– Google App Engine

31

Software as a Service

• Bereitstellung von (Web)-Applikationen zur sofortigen Nutzung– Standardisierte Software (z.B. Office-Produkte, CRM, ...)

– Datenspeicherung i. Allg. beim Anbieter

• Automatische Skalierung durch Anbieter– definierte Verfügbarkeit / Response-Times möglich

• Flexibilität– flexible Bezahlung nach Nutzungsumfang (statt Lizenzkosten)

– “Customisierung” nur eingeschränkt möglich

• Beispiele– Google Apps (Docs, Mail, ...)

– Salesforce

32

Vergleich IaaS, PaaS und SaaS

IaaS PaaS SaaS

Nutzer Administrator Anwendungsentwickler Endnutzer

KomponentenCompute Capacity

App Framework +Compute Capacity

Business Layer +App Framework +Compute Capacity

Bezahlung CPU, Speicher, ...Requests, Dienstnutzung (DB, Mail, ...) ...CPU, Speicher, ...

Nutzungsdauer/-intensität (je nach App-Typ)

Anwendungs-fälle

Compute CapacityCloud Storage

Cloud-DB Laufzeit-umgebung

ErweiterbareWebapps

WebApps

Beispiele Amazon EC2+ S3, Azure Storage

BigTable, SimpleDB

MapReduce,Google App Engine

Facebook Google Mail

33

Die “Amazon-Cloud”

Building powerful web applications in the AWS Cloud : A Love Story - Jinesh Varia: http://www.slideshare.net/AmazonWebServices/building-powerful-web-applications-in-the-aws-cloud-a-love-story-jinesh-varia

34

Amazon EC2

• IaaS: Mieten von Linux-Instanzen– RESTful Webservices (API) zur Allokation

und Management von Ressourcen mittels virtueller Maschinen (VM)

– Erstellung eigener VM’s möglich

• Basiert auf Xen Hypervisor– 1 EC2-CU (“Compute Unit”)

= CPU capacity of 1.0-1.2 GHz 2007 Opteron or 2007 Xeon

– CPU: 1 core @ 1 CU bis 8 cores @ 2.5 CU

– Virtuelle Speicher: 1.7 GB bis 15 GB

– Linux oder Windows; Preise (EU): $0.10 bis $2.50

• Integration mit anderen Diensten, u.a.– Elastic Block Store (EBS) = Persistenter Blockspeicher, der zur Laufzeit mit EC2-

VM verbunden werden kann

Facilities

Hardware

Abstraction

Connectivity & Delivery

APIs

Infra

stru

ctur

e as

a S

ervi

ce

http://aws.amazon.com/ec2 http://www.slideshare.net/guestd0b61e/amazon-ec2-application-design

35

Zusammenfassung

• Hardware-Infrastruktur– Data Center sind Basis einer effiziente Cloud-Infrastruktur

– “Scale out” statt “Scale up”

• Dateisysteme für die Cloud, z.B. GFS– optimiert für große Datenmengen und konkurrierende Zugriffe

• Software-Infrastruktur– Software/Platform/Infrastructure as a Service

– Techniken für Performance & Availability

36

Quellen und Literatur

• [BH09] Barroso and Hölzle: The datacenter as a computer: An introduction to the design of warehouse-scale machines. Morgan & Claypool, 2009

• [De09] Dean: Designs, Lessons and Advice from Building Large Distributed Systems. Keynote LADIS 2009

• [DGLS99] Devlin, Gray, Laing, Spix: Scalability Terminology, MS Tech Report, Dec. 1999

• [GGL03] Ghemawat, Gobioff, and Leung: The Google File System. Symposium on Operating Systems Principles, 2003

• [HDFS] http://hadoop.apache.org/hdfs/• [1] http://www.slideshare.net/gwendal/cloud-engineering

• [2] http://www.slideshare.net/Clogeny/cloud-computing-making-the-right-choices

• [3] http://www.slideshare.net/AmazonWebServices/building-powerful-web-applications-in-the-aws-cloud-a-love-story-jinesh-varia