Dr. Andreas Thor Sommersemester 2011dbs.uni-leipzig.de/file/CDM_02_Infrastruktur_Service.pdf ·...
Transcript of Dr. Andreas Thor Sommersemester 2011dbs.uni-leipzig.de/file/CDM_02_Infrastruktur_Service.pdf ·...
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