Cloud Data Management

Transkript

1 Cloud Data Management Kapitel 2: Infrastruktur und Services Dr. Anika Groß Wintersemester 2016 Universität Leipzig

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

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.

8 Bsp. Google Rechenzentrum Leitungen zum Transport von Wasser zur Kühlung

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

12 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

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

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

15 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 Variante 1: Updates mit Random Access Variante 2: Neuschreiben aller Datensätze

16 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 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns Mutex lock/unlock 25 ns Main memory reference Send 2K bytes over 1 Gbps network Read 1 MB sequentially from memory Round trip within same datacenter Disk seek 100 ns 20,000 ns 250,000 ns 500,000 ns 10,000,000 ns Read 1 MB sequentially from disk Send packet CA NED CA 20,000,000 ns 150,000,000 ns [De09]

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

18 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

19 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 bzw. Hinzufügen 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,...

20 Techniken für Performance & Availability Replication Redundante Speicherung von Daten Anwendung: u.a. Dateisystem (GFS/HDFS), 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

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

22 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

23 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

24 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

25 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

26 Die Amazon-Cloud Building powerful web applications in the AWS Cloud : A Love Story - Jinesh Varia:

27

28 ...

29 Varianten zur Speicherung von Daten Content Delivery (z.b. S3, CloudFront) Storage (z.b. Elastic Block Store) Data Store / Database (z.b. SimpleDB) Nutzungsszenario Große (statische) Dateien Write-Once-Read-Many Content Delivery Network Speicherung beliebiger Daten (ähnlich HDD) File-System Speicherung (semi-) strukturierter Daten einfache Anfragen Hochskalierbare Anwendungen Beispiele Videos, Musik Backups Speicher für EC2- Instanz Log-Dateien Nutzerprofile Ungeeignet für / nicht unterstützt Querying Searching Content Distribution Komplexe SQL- Anfragen, z.b. Joins Weitere Möglichkeiten Instance Store/Ephemeral Store: Nicht-persistenter Datei-Speicher für EC2-Instanz Relational Database Service: RDBMS via WebService Best Practices for Architecting in the Cloud - Jeff Barr

30 Amazon EC2 IaaS: Mieten von Linux/Win-Instanzen RESTful Webservices (API) zur Allokation und Management von Ressourcen mittels virtueller Maschinen (VM) Amazon Machine Image (AMI) Public (vorgefertigt von Amazon) oder private (von Nutzer erstellt) Template mit Software Konfiguration (OS, Anwendungen,...) Starten von Instanzen (Kopien der AMI), laufen als virtuelle Server in der Cloud Beispiel-Auswahl (free) 1.) Amazon Linux AMI (HVM), SSD Volume Type EBS AWS command line tools, Python, Ruby, Perl, Java Docker, PHP, MySQL, PostgreSQL, 2.) Instanz: t2.micro mit vcpu, 1 GB Memory

31 Instance Types ( ) Details: ( ) General purpose (t2): high Frequency Intel Xeon Processors operating 2.5GHz Preise: Virtual CPU (vcpu) Credits per hour Linux oder Windows, Preise (EU Frankfurt), General purpose (t/m): $0.015 bis $1.15 pro Std Memory optimized (r): $0.21 bis $4.069 pro Std (15 bis 244 GiB RAM)

32 Amazon EC2: Management Bereitstellung aller Funktionen per SOAP/REST-API Programmatischen Zugriff + Web Interface für manuellen Zugriff Workflow Ggf. AMI-Upload; Speicherung durch Elastic Block Storage Reservierung physikalischer Ressourcen, Kopieren auf (phys.) Server Starten der VM = Instanziierung des AMI Zugriff mittels IP und SSH (Linux) bzw. RDP (Windows) Ggf. Einbinden weiterer Dienste

33 Amazon EC2: Abrechnung Bsp. Massive Nutzung für Forschungsprojekt (vgl: 1 Jahr = 8760 Stunden)

34 EC2-Integration mit anderen Diensten Elastic Block Store (EBS) Persistenter Blockspeicher, der zur Laufzeit mit EC2-VM verbunden werden kann Nutzung: Dateispeicher (Formatierung mit FS), Snapshot für VM, Preis (04/15): $0.119 pro GB und Monat von bereitgestelltem Speicher (SSD); $0,11 pro 1 Million I/O Requests Elastic IP EC2-VMs erhalten zufällige IP aus EC2-IP-Pool Unvorteilhaft für einfachen Nutzer-Zugriff (z.b. Webserver) Zuordnung statischer IP(s) zu EC2-VM Preis (04/15): ab $0.00 ($0.005) für (nicht) laufende EC2-VM pro Stunde Elastic Load Balancing (ELB) Automatische Verteilung eingehender Requests auf EC2-Instanzen Requests von einem Nutzer stets zur selben Instanz Erkennung ausgefallener VMs Preis (04/15): $0.03 pro Stunde (EU Frankfurt) + $0.008 pro GB Datentransfer