Cloud Data Management

Kapitel 2: Infrastruktur Kapitel 2: Infrastruktur und Services

Dr. Andreas ThorSommersemester 2011

1

Sommersemester 2011

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

Inhaltsverzeichnis• Hardware-Infrastruktur

– Grundideen performanter Datenverarbeitung in der Cloud

– Aufbau eines Data Centers

• Dateisysteme für die Cloud• 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

2

– Beispiel: Amazon

“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 akzeptable

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

3

Scale-up vs. Scale-out [DGLS99 ff]• Scale-up = vertikale Skalierung

– schnellere SMP-Knoten

– Shared Everything

• Scale-out = horizontale Skalierung• 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, ...

4

– geringere Kosten, geringere Administrationsaufwand, leichte Erweiterbarkeit, ...

– Alternative: geringere Zahl von High-End-Servern

Aufbau eines Datacenters

5

Server• CPUs• DRAM• Disks

Rack• 40-80 Server• Ethernet Switch Cluster

[BH09]

Aufbau eines Datacenters (2)

6Source: Barroso and Urs Hölzle (2009)

[BH09]

Storage Hierarchy

7 [BH09]

Standard-Hardware statt “High -End”• Standard-Hardware ist kosteneffizienter pro “Leistungseinheit”

• Ähnliche Ausfallwahrscheinlichkeiten, geringerer Stromverbrauch

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

8 [BH09]

(Ökonomische) Gründe für Data Centers• Sehr große (50.000 Server) Data Centers kostengünstiger als mittelgrose

(1.000 Server)– Faktor 5-7 pro Ressource (Netzwerk, Speicher, Administratoren, ...)

• Virtualisierung ermöglich (nahezu) freie Standortwahl nach ökonomischen • 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”

9

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

Kommunikationskosten• Parallelverarbeitung erzwingt Kommunikation zwischen Knoten/Cores

– SMP (shared memory): Latenz ~100 ns

– LAN: Latenz ~100 µs

• Scaling “up” vs. scaling “out”• 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)

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

10

• 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)]

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• keine Veränderung ab n=8

11 [BH09]

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 coresPerformanzvorteil deutlich, z.B. <15% ab 1024 cores

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

12 [BH09]

Seeks vs. Scans• Sequentielle Verarbeitung großer Datenmengen performant da

aufwändige Seeks entfallen– Seek = Positionierung des Lese-Schreibkopfes auf Platte

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

– Update 1% aller Datensätze

• Variante 1: Updates mit Random Access

13

• Variante 2: Neuschreiben aller Datensätze

Source: Ted Dunning, on Hadoop mailing list

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

14

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]

Dateisysteme und verteilte Dateisysteme• Dateisystem

– System für permanente Datenspeicherung

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

– Basisobjekt: Datei

– eindeutigig referenziert durch Namen und (hierarchischen) Pfad

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

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

– Problemfälle• Concurrency

• Replication

NFSServer

Dateisystem

15

• Replication

• Caching

– Beispiele: DFS, NFS, ...

Dateisystem (für Nutzer/Anwendung)

NTFS EXT4 NFSClientHDD1 HDD2

Dateisystem(Server)

EXT4

HDD1

EXT4

HDD2

Notwendigkeit neuer Dateisysteme für Cloud

Lokal / Netzwerk Cloud

Nutzer Anwender, (lokale) Programme

Beispiele TextverarbeitungBeispiele TextverarbeitungFotoverwaltung

Anzahl der Dateien

sehr viele (>>1,000,000)

Größe der Dateien

kleine (KB-MB)

16

Dateien

Lesezugriff teilw. concurrent, komplett

Schreibzugriff mehrfach Überschreiben

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)• 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)

17

• 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

Google File System: Architektur

18

[GGL03]

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

19

– 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)

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

20

– 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]

Hadoop• Framework für skalierbare und verteilte Software

– frei, open-source, Java

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

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

Hadoop File System: Architektur

22

[HDFS]

GFS Master=HDFS Namenode, GFS ChunkServer = HDFS Datanode

GFS/HDFS: ZusammenfassungEigenschaft Technologie / Idee

Metadaten

InstanzdatenInstanzdaten

Zuverlässigkeit

Lese-Operation

23

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

Software-Infrastruktur

APIs

Presentation Modality/Platform

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

Data/Voice/Video, PC/Embedded/Mobile

APIs

Integration & Middleware

DataMetaData

Content

Applications

Infra

stru

ctur

e as

a S

ervi

ce

Plat

form

as

a Se

rvic

e

Softw

are

as

a Se

rvic

e

Structured/Unstructured

Database, Messaging, Queueing

Management

Native, Web, Emulated

24Facilities

Hardware

Abstraction

Connectivity & Delivery

Infra

stru

ctur

e as

a S

ervi

ce

Plat

form

as

a Se

rvic

e

Softw

are

as

a Se

rvic

e

IPAM/DNS, Transport, Security, Auth.

VMM, Grid/Cluster, Images

Compute, Network, Storage

Power, HVAC, Space

Cluster-Level Software: Anforderungen• Ressource Management

– Zuordnung von Tasks zu Ressourcen

– Ziel: Performanz, effizienter Energieverbrauch

• Hardware Abstraction• Hardware Abstraction– Virtualisierung

– Ziel: Einheitlicher (einfacher) Ressourcen-Zugriff

• Deployment und Maintenance– Software-Upgrades, Monitoring

– Ziel: geringerer Nutzer/Administrator-Aufwand

• Programming Framework

25

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

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

Cluster-Level-Software: Besonderheiten• vs. Desktop-Software

– inhärente Parallelität• effiziente Ausnutzung aller verfügbarer Ressourcen

– relativ homogene Platform• begrenzte Heterogeniä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

26

– nicht vorhersagbarer (Daten-)Input• Umfang, Schema, ...

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

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

Techniken für Performance & Availability• Replication

– Redundante Speicherung von Daten

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

• Load Balancing• 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

27

• 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

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

Replication Schutz vor Datenverlust

Data Partitioning Recovery schneller bei (kleinen) Data Partitioning Recovery schneller bei (kleinen) Partitionen

Load Balancing---

Eventual Consistency

Effiziente parallele Writes

28

Health Checking und Integritäts-prüfung

---Identifikation fehlerhafter

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

Daten-kompression ---

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

29

– Amazon Elastic Compute Cloud (EC2), Rackspace

– Amazon Simple Storage Service (S3)

– Amazon Route 53

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 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

30

– Amazon Elastic MapReduce, Hadoop MapReduce

– Google App Engine

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• 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, ...)

31

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

– Salesforce

Vergleich IaaS, PaaS und SaaS

IaaS PaaS SaaS

Nutzer Administrator Anwendungsentwickler Endnutzer

Komponenten App Framework +Business Layer +App Framework +Komponenten

Compute CapacityApp Framework +Compute Capacity

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

32

Cloud Storage

Beispiele Amazon EC2+ S3, Azure Storage

BigTable, SimpleDB

MapReduce,Google App Engine

Facebook Google Mail

Die “Amazon-Cloud”

33Building 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

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öglichHardware

Abstraction

Connectivity & Delivery

APIs

Infra

stru

ctur

e as

a S

ervi

ce

– 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

FacilitiesInfra

stru

ctur

e as

a S

ervi

ce

34

– 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

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

Zusammenfassung• Hardware-Infrastruktur

– Data Center sind Basis einer effiziente Cloud-Infrastruktur

– “Scale out” statt “Scale up”

• Dateisysteme für die Cloud, z.B. GFS• 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

35

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 • [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/

36

• [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