Cloud Data Management

Transkript

1 Cloud Data Management Kapitel 2: Infrastruktur und Services Dr. Michael Hartung Sommersemester 2012 Universität Leipzig Institut für Informatik 1

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 2

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 3

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 4

5 Aufbau eines Datacenters Server CPUs DRAM Disks Rack Server Ethernet Switch Cluster 5 [BH09]

6 Aufbau eines Datacenters (2) [BH09] Source: Barroso and Urs Hölzle (2009) 6

7 Storage Hierarchy 7 [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 ) 8 [BH09]

9 (Ökonomische) Gründe für Data Centers Sehr große ( 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 9

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: Core-SMP vs 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 µs (1-1/n)] 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) 10

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 11 [BH09]

12 Kommunikationskosten (3) Vergleich: (c/128) 128-Core vs. (c/4) 4-Core Bsp: Cluster size = 512 entspricht Core vs 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 12 [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 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 13

14 Datenzugriff Verarbeitung großer Datenmengen u.a. beeinflusst von Zugriffszeiten Ziel: Verarbeitung nah an den Daten L1 cache reference Branch mispredict L2 cache reference Mutex lock/unlock Main memory reference Send 2K bytes over 1 Gbps network Read 1 MB sequentially from memory Round trip within same datacenter Disk seek Read 1 MB sequentially from disk Send packet CA Netherlands CA ns 5 ns 7 ns 25 ns 100 ns 20,000 ns 250,000 ns 500,000 ns 10,000,000 ns 20,000,000 ns 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 NFS HDD1 HDD2 Client 15 NFS Server Dateisystem (Server) EXT4 EXT4 HDD1 HDD2

16 Notwendigkeit neuer Dateisysteme für Cloud Nutzer Beispiele Anzahl der Dateien Größe der Dateien Lesezugriff Lokal / Netzwerk Anwender, (lokale) Programme Textverarbeitung Fotoverwaltung sehr viele (>>1,000,000) kleine (KB-MB) teilw. concurrent, komplett Schreibzugriff mehrfach Überschreiben Cloud 16

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 17

18 Google File System: Architektur [GGL03] 18

19 Master Metadata-Management Mapping Datei > Chunk > ChunkServer (Node) Alles im Hauptspeicher (performant) Logfile 64 byte pro Chunk, wenige Dateien 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) 19

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) 20 [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 21

22 Hadoop File System: Architektur [HDFS] GFS Master=HDFS Namenode, GFS ChunkServer = HDFS Datanode 22

23 GFS/HDFS: Zusammenfassung Eigenschaft Metadaten Technologie / Idee 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 23

24 Software-Infrastruktur Presentation Modality/Platform The frogs who desired a king. Data/Voice/Video, PC/Embedded/Mobile APIs Applications Native, Web, Emulated Software as a Service Platform as a Service Infrastructure as a Service Data Meta Data Integration & Middleware APIs Connectivity & Delivery Abstraction Hardware Facilities Content 24 Structured/Unstructured Database, Messaging, Queueing Management IPAM/DNS, Transport, Security, Auth. VMM, Grid/Cluster, Images Compute, Network, Storage Power, HVAC, Space

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 25

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,... 26

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 27

28 Techniken für Performance & Availability (2) Replication Performance Availability Schutz vor Datenverlust Data Partitioning Load Balancing Eventual Consistency Recovery schneller bei (kleinen) Partitionen --- Effiziente parallele Writes Identifikation fehlerhafter Knoten; keine Requests an nicht verfügbare/langsame Knoten Health Checking und Integritätsprüfung Datenkompression ---

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 29

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 30

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 31

32 Vergleich IaaS, PaaS und SaaS IaaS PaaS SaaS Nutzer Administrator Anwendungsentwickler Endnutzer Komponenten Compute Capacity Bezahlung CPU, Speicher,... Beispiele Compute Capacity Cloud Storage Amazon EC2 + S3, Azure Storage Cloud-DB BigTable, SimpleDB App Framework + Compute Capacity Requests, Dienstnutzung (DB, Mail,...)... CPU, Speicher,... Anwendungsfälle Laufzeitumgebung MapReduce, Google App Engine Erweiterbare Webapps Facebook Business Layer + App Framework + Compute Capacity Nutzungsdauer/- intensität (je nach App-Typ) WebApps Google Mail 32

33 Die Amazon-Cloud Building powerful web applications in the AWS Cloud : A Love 33Story - 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 GHz 2007 Opteron or 2007 Xeon CPU: 1 1 CU bis 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. APIs Connectivity & Delivery Abstraction Hardware Facilities Elastic Block Store (EBS) = Persistenter Blockspeicher, der zur Laufzeit mit EC2- VM verbunden werden kann Infrastructure as a Service

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 35

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 [GGL03] Ghemawat, Gobioff, and Leung: The Google File System. Symposium on Operating Systems Principles, 2003 [HDFS] [1] [2] [3] 36