Cloud Data Management Kapitel 1: Infrastruktur und Services

Transkript

1 Cloud Data Management Kapitel 1: Infrastruktur und Services Dr. Eric Peukert Wintersemester 2017 Universität Leipzig, Institut für Informatik

2 Inhaltsverzeichnis Hardware-Infrastruktur Grundideen performanter Datenverarbeitung in der Cloud Aufbau eines Data Centers Software-Infrastruktur Aufbau, Anforderungen und Ziele Cloud-Dienste: Software/Platform/Infrastructure as a Service Cloud-Anbieter Beispiel: Amazon Virtualisierung Docker Open Source Cloud Software Open Stack

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 akzeptabel 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 Server Ethernet Switch Cluster [BH09]

6 Aufbau eines Datacenters (2) Bilder von Google s Data Center [BH09]

7 Bsp. Google Rechenzentrum Jedes Server-Rack verfügt über vier Switches, die durch verschiedenfarbige Kabel angeschlossen sind. reetview/ gallery/#/all/10

8 Bsp. Google Rechenzentrum Leitungen zum Transport von Wasser zur Kühlung ery/#/all/10

9 Storage Hierarchy [BH09]

10 Standard-Hardware statt High-End Standard-Hardware ist kosteneffizienter pro Leistungseinheit Ähnliche Ausfallwahrscheinlichkeiten, geringerer Stromverbrauch Nahezu beliebige Skalierbarkeit ( pay as you go/grow ) [BH09]

11 Big Data Infrastructure UL Galaxy: Commodity-Hardware im Cluster 90 Knoten (60 in Leipzig, 30 in Dresden) mit jeweils 2 x 6 Core Intel-CPU (Haswell E5 GHz) 128 GByte DDR4 ECC RAM 6 x 4 TB SATA 3,5 HDD als JBOD (HW-RAID aber vorhanden) 10 GBit/s Netzwerkinterface Sirius: 2 Knoten High Performance mit jeweils 8 x 16 Core CPUs (Intel Xeon E v3, 2.2GHz) 6 TByte DDR4 ECC RAM 2x600GB SAS (Raid1) + 5x2TB SAS (RAID 6) 10 GBit/s Netzwerkinterface + InfiniBand

12 2/3 Galaxy und Sirius Galaxy und Sirius

13 (Ö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öglicht (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 (anfangs) als Zusatzgeschäft

14 Kommunikationskosten Parallelverarbeitung erzwingt Kommunikation zwischen Knoten/Core 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

15 Kommunikationskosten (2) Vergleich: Core vs. n 4-Core Core bis zu 10mal schneller als entsprechendes 32 4-Core Cluster keine Veränderung ab n=8 [BH09]

16 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 ähnliche Performanz bei < Kosten [BH09]

17 Seeks vs. Scans Sequentielle Verarbeitung großer Datenmengen performant da aufwändige Seeks entfallen Seek = Positionierung des Lese-Schreibkopfes auf Platte Computer hard-drive seeking demo: Beispiel Datenbank mit Datensätzen à 100 Byte 1 TB Update 1% aller Datensätze, Seektime 10ms, 100MB Disk Throughput Variante 1: Updates mit Random Access Variante 2: Neuschreiben aller Datensätze

18 Datenzugriff Verarbeitung großer Datenmengen u.a. beeinflusst von Zugriffszeiten Ziele Verarbeitung nah an den Daten Daten möglichst im RAM Sequentielles Lesen von Disk 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 NED CA 0.5 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]

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

20 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

21 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 Hinzufügen/Ersetzen defekter Hardw. 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 Cent. 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,...

22 Techniken für Performance & Availability Replication Redundante Speicherung von Daten Anwendung u.a. Dateisystem (GFS/HDFS), Storage (Amazon Dynamo) Eventual Consistency Asynchrones Weiterreichen von Änderungen an Replikate Anwendung: Storage Service (Amazon Dynamo) Load Balancing Workload-Aufteilung auf mehrere Knoten Anwendung: parallele Progr. (MapReduce), WebApps (Google App Engine) Data Partitioning Aufteilung von Datenbestand in Partitionen zur effizienten Bearbeitung Anwendung: u.a. Cloud-Datenbank (Bigtable) und (MapReduce) Weitere Überprüfung ob Nodes still alive, Datenkompression

23 Techniken für Performance & Availability (2) Replication Performance Effizientes, paralleles Lesen (Nachteil: Änderungen) Availability Schutz vor Datenverlust Data Partitioning Parallele Verarbeitung von Partitionen Recovery schneller bei (kleinen) Partitionen Load Balancing Eventual Consistency Reduzierung der Knoten-Varianz (langsamster Knoten bestimmt Gesamtlaufzeit) Asynchrone Replikation verringert Antwortzeit bei Writes --- Effiziente parallele Writes Health Checking und Integritätsprüfung Datenkompression --- Identifikation fehlerhafter Knoten; keine Requests an nicht verfügbare/langsame Knoten Schnellere Datenübertragung/- speicherung (geringer CPU-Overhead) ---

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

25 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

26 Platform as a Service Framework/Komponenten zur Entwicklung und Bereitstellung von Applikationen Infrastruktur führt hochgeladenen Quellcode aus Auch DBaaS 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 SAP HANA Cloud

27 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

28 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

29 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 [1] [2] [3] [4]