Post on 13-Feb-2019
Cloud Data Management
Kapitel 2: Infrastruktur
und Services
Dr. Anika Groß
Wintersemester 2016
Universität Leipzig
http://dbs.uni-leipzig.de/
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
“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
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
Aufbau eines Datacenters
Server
• CPUs
• DRAM
• Disks
Rack
• 40-80 Server
• Ethernet Switch Cluster
[BH09]
Aufbau eines Datacenters (2)
[BH09]
Bilder von Google‘s Data Center
http://www.google.com/about/datacenters/gallery/#/
Bsp. Google Rechenzentrum
• „Jedes Server-Rack verfügt über vier Switches, die durch verschiedenfarbige Kabel
angeschlossen sind.“
• http://www.google.com/about/datacenters/inside/streetview/
http://www.google.com/about/datacenters/gallery/#/all/10
Bsp. Google Rechenzentrum
• Leitungen zum Transport von Wasser zur Kühlung
http://www.google.com/about/datacenters/gallery/#/all/10
Storage Hierarchy
[BH09]
Standard-Hardware statt “High-End”
• Standard-Hardware ist kosteneffizienter pro “Leistungseinheit”
• Ähnliche Ausfallwahrscheinlichkeiten, geringerer Stromverbrauch
• Nahezu beliebige Skalierbarkeit (“pay as you go/grow”)
[BH09]
(Ökonomische) Gründe für Data Centers
• Sehr große (50.000 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”
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”
– 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)
• Light communication: f =1
• Medium communication: f =10
• Heavy communication: f =100
1 ms + f [100 ns / n + 100 s (1 - 1/n)]
Kommunikationskosten (2)
• Vergleich: 1 nm-Core vs. n m-Core
• 1 nm-Core bis zu 10mal schneller als entsprechendes n m-Core
Cluster
• keine Veränderung ab n=8
[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 cores
• Standard-Hardware-Cluster hat ähnliche Performanz bei deutlich
geringeren Kosten
[BH09]
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: https://youtu.be/jbqPBcMVARE
• Beispiel
– Datenbank mit 1010 Datensätzen à 100 Byte 1 TB
– Update 1% aller Datensätze
• Variante 1: Updates mit Random Access
• Variante 2: Neuschreiben aller Datensätze
Datenzugriff
• Verarbeitung großer Datenmengen u.a. beeinflusst von Zugriffszeiten
• Ziele
– Verarbeitung “nah an” den Daten
– Daten möglichst im RAM
– Sequentielles Lesen von DiskL1 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
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 → NED → CA 150,000,000 ns
[De09]
Software-Infrastruktur
Facilities
Hardware
Abstraction
Connectivity & Delivery
APIs
Integration & Middleware
DataMeta
DataContent
Applications
APIs
Presentation
Modality/Platform
Infr
astr
uctu
re a
s a
Ser
vice
Pla
tform
as
a S
ervi
ce
Sof
twar
e a
s a
Ser
vice
The frogs who desired a king.
http://www.rationalsurvivability.com/blog/?p=567
IPAM/DNS, Transport, Security, Auth.
VMM, Grid/Cluster, Images
Compute, Network, Storage
Power, HVAC, Space
Structured/Unstructured
Database, Messaging, Queueing
Management
Data/Voice/Video, PC/Embedded/Mobile
Native, Web, Emulated
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
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, ...
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
Techniken für Performance & Availability (2)Performance Availability
Replication Effizientes, paralleles Lesen
(Nachteil: Änderungen)
Schutz vor Datenverlust
Data Partitioning Parallele Verarbeitung von Partitionen Recovery schneller bei (kleinen)
Partitionen
Load Balancing Reduzierung der Knoten-Varianz
(langsamster Knoten bestimmt
Gesamtlaufzeit)
---
Eventual
Consistency
Asynchrone Replikation verringert
Antwortzeit bei Writes
Effiziente parallele Writes
Health Checking
und Integritäts-
prüfung
---
Identifikation fehlerhafter
Knoten; keine Requests an nicht
verfügbare/langsame Knoten
Daten-
kompression
Schnellere Datenübertragung/-speicherung
(geringer CPU-Overhead) ---
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
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
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
Vergleich IaaS, PaaS und SaaS
IaaS PaaS SaaS
Nutzer Administrator Anwendungsentwickler Endnutzer
Komponenten
Compute Capacity
App Framework +
Compute Capacity
Business Layer +
App Framework +
Compute Capacity
Bezahlung CPU, Speicher, ...
Requests,
Dienstnutzung (DB, Mail, ...) ...
CPU, Speicher, ...
Nutzungsdauer/-
intensität (je nach
App-Typ)
Anwendungs-
fälle
Compute
Capacity
Cloud Storage
Cloud-DB Laufzeit-
umgebung
Erweiterbare
Webapps
WebApps
Beispiele Amazon EC2
+ S3, Azure
Storage
BigTable,
SimpleDB
MapReduce,
Google App
Engine
Facebook Google Mail
Die “Amazon-Cloud”
Building 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
https://eu-central-1.console.aws.amazon.com/console/home?region=eu-central-1#
Varianten zur Speicherung von Daten
• Weitere Möglichkeiten
– Instance Store/Ephemeral Store: Nicht-persistenter Datei-Speicher für EC2-Instanz
– Relational Database Service: RDBMS via WebService
Content Delivery
(z.B. S3, CloudFront)
Storage
(z.B. Elastic Block Store)
Data Store / Database
(z.B. SimpleDB)
Nutzungs-
szenario
• 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
Best Practices for Architecting in the Cloud - Jeff Barrhttp://www.slideshare.net/AmazonWebServices/best-practices-for-architecting-in-the-cloud-jeff-barr
Amazon EC2
http://aws.amazon.com/ec2
http://www.slideshare.net/guestd0b61e/amazon-ec2-application-design
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instances-and-amis.html
• 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 2015.03 (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
Instance Types
• Details: http://aws.amazon.com/ec2/instance-types/
• 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)
(04-2015)
(04-2015)
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
Amazon EC2: Abrechnung
• Bsp. Massive Nutzung für Forschungsprojekt (vgl: 1 Jahr = 8760 Stunden)
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