Cloud Storage

Werbung
Wetterbericht:
Clouds als Storage
OOP 2010 -- 25. - 29. Januar 2010 in München
Nightschool, Nmi 3, 27. Januar 2010
Michael C. Jaeger und Uwe Hohenstein
Siemens CT T, Corporate Research and Technologies
Global Technology Field “System Architecture and Platforms”
<nur für internen Gebrauch > / Copyright ©© Siemens
Alle Rechte
vorbehalten.
M. C. JaegerAG
und 2008.
U. Hohenstein.
Alle Rechte
vorbehalten.
Übersicht – Was uns heute erwartet!
Kurzer Überblick
Einheitlicher Kenntnisstand
Spielarten des Cloud Storages
Blobs, Tables und SQL
Vor- und Nachteile
Im Vergleich zum klassischen Datenbankserver
Vorstellung prominenter Produkte
Windows Azure, Amazon (z.B. S3), Couch und Google
Generelle Überlegungen
Kosten, Migration
Seite 2 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Cloud Computing
und Cloud Storage
Allgemeiner Überblick und grundlegende Konzepte
<nur für internen Gebrauch > / Copyright © Siemens AG 2008. Alle Rechte vorbehalten.
Cloud Computing – Was ist das?
Unter Cloud Computing verstehen wir ein neues Geschäftsmodell,
das bestehende Technologien auf neuartige Weise kombiniert.
Ziel des Cloud Computings ist die wirtschaftlich effiziente
Bereitstellung von IT Ressourcen auf unterschiedlichen
Abstraktionsebenen: Infrastruktur, Plattformen und Softwaredienste.
Verwandtschaft mit:
SOA und Grid Computing
Utility Computing
Virtualisierung
Namhafte Anbieter treten in den Markt ein:
Microsoft, Google, IBM, Ubuntu, Amazon
mit hohen Investitionen
mit neuartigen Partnerschaften und Konkurrenzsituationen
Seite 4 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Ebenen des Cloud Computings
Kunden-Anwendung
SaaS
Software-as-a-Service
z.B. Salesforce
PaaS
Platform-as-a-Service
z.B. Google App Engine
IaaS
Infrastructure-as-a-Service
Seite 5 - OOP, München, Januar 2010
z.B. Amazon Elastic Computing Cloud
© Michael C. Jaeger und Uwe Hohenstein
Verwandte Technologien - und deren Hauptunterschiede
SOA: Paradigma, welches die Bereitstellung von Funktionalität im Sinne
einer Dienstleistung anstrebt
Unterschied: Cloud Computing bezieht SOA-Technologie mit ein, aber
umfasst auch weitere Dinge, zum Beispiel Virtualisierung
Grid Computing: Bereitstellung einer gemeinsamen Ressource durch
einen homogenen Verbund
Unterschied: Die Transparenz des Ortes wird zwar aufgegriffen, aber
geht über das Bereitstellen einer Ressource hinaus.
Virtualisierung: Umsetzung eines Schichten-Modells, um bei der Nutzung
der unteren Schicht physikalische Transparenz zu erlangen
Unterschied: Cloud Computing bietet Virtualisierung auf
unterschiedlichen Ebenen
Utility Computing: Nutzung von Computing- und Storage-Ressourcen auf
Pay-Per-Use-Basis
Unterschied: Utility Computing = Infrastruktur, kein SaaS
Seite 6 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Cloud Computing – Die Geschäftsperspektive
a) Einsparung durch Pay-Per-Use
Dynamische Infrastruktur, Kosten werden an den Umsatz gekoppelt
Dimensionierung vorab unnötig, Investitionen werden geringer
Keine Kosten für Administratoren
b) Rationalisierungseffekt durch größtmöglichen Maßstab
Neue Generation von Rechenzentren
Bedarf
Zeit
Quellen: Pressebilder HP Corp. & Microsoft Corp.
Seite 7 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Beispiele Speicher-Intensiver Applikationen
Zitate des Amazon Case Study Clubs (Auswahl):
Sonian: E-Mail Archivierung: Dienstleistung für Unternehmen die
gesetzliche Vorhaltefrist für E-Mail Daten bereitzustellen.
37signals: Speicherung der Daten für Basecamp and Campfire WebApplikationen für Projekt-Management (ca. 1TB) bei Amazon S3.
Altexa: Backup Lösung für 1 USD pro GB pro Monat.
ElephantDrive: Funktionsreicher Online-Speicher mit
Verschlüsselung, Gastzugriffen, effizienter Übertragungstechnik.
MiraiBio: Software zur Sequenzierung von Proteinen für DNA
Analyse. Kommt in Verbindung mit Client-Software zum Einsatz, die
auf Notebook-Computern für mobil arbeitende Biologen installiert ist.
Seite 8 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Cloud Computing - „Where ist the storage?“
Speicher und Rechenkapazität sind Basisdienste
Dimensionierung dieser Ressourcen beeinflusst wesentlich die
Kosten, bei Speicher:
Anschaffung von Festplatten
Anschaffung von Datensicherungsmedien & Administration
Dimensionierung der Anbindung des Speichers
Zwei Szenarien für Storage-Nutzung:
Applikation und Storage zusammen in der Cloud
Einfacher Fall
Applikation lokal und nur Storage in der Cloud
Z.B. bei kritischer Geschäftslogik
Z.B. bei Bereitstellung der Daten für verteilte Nutzergruppe
Seite 9 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Cloud Computing Architekturen
Client – Provider Cloud
Anwendung läuft komplett in der Cloud, Rich Client kommuniziert
über Internet mit Anwendung
In House App – Provider Cloud
Eigene Anwendung nutzt Komponenten oder Dienste, die in der
Cloud zur Verfügung gestellt werden
Private / On-Premise Cloud
Nutzung von Cloud Technologien, um Rationalisierungsvorteile für
eigene Infrastruktur zu nutzen
Kombination On-Premise – Provider Cloud
Nutzung der Provider Cloud unter Beibehaltung organisatorischer
Rahmenbedingungen für kritischen Teil der Anwendung
Seite 10 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Motivationen für Cloud Storage
„Mit einem klassischen Datenbankserver habe ich Probleme, weil ...“
Ich nicht weiß, wie mein Geschäft wachsen wird
Anforderungen an Skalierbarkeit
Integrierte Lastverteilung
Ich die Investitionen nicht bereitstellen kann
Start-up Phase eines jungen Unternehmens
Experimentelles Geschäft
Ich bestimmte Anforderungen an Zuverlässigkeit habe
Automatisches Failover & Replizierung
Ich Zugriff auf Daten jederzeit, überall, von jedem Gerät benötige
Ich die Administration nicht zur Verfügung stellen kann
Aufbau einer Datenbankadministration zu aufwändig
Ich schnell in den Markt will, Speicherdienste zeitnah nutzen will
Keine Zeit, um ein Datenbanksystem aufzubauen
Ich mich auf die Funktionalität, auf das Kerngeschäft konzentrieren will
Seite 11 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Speichern in der Cloud – keine Missverständnisse!
Grundsätzliche Möglichkeit:
Eigenen Datenbankserver in der Cloud betreiben:
mitunter aufwändiges Deployment
Fernadministration notwendig auf virtualisierter Plattform
Nutzt nicht die Technologien zur Virtualisierung der Anbieter aus
Widerspricht in vielen Punkten den genannten Motivationen
Technische Möglichkeiten der Anbieter:
Nutzung der Dienste im Rahmen der Cloud Umgebung
Blob-, Object-, Document-Storages
Table Storages
Relationaler Datenbankserver
Seite 12 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Architekturelle Möglichkeiten
1. Desktop/Server-Applikation als Client: Zugriff auf Cloud Datenbank,
wie beim klassischen RDMS:
Höhere Latenzzeiten als bei einem lokalem Server
Zugriff von verschiedenen Orten aus möglich
2. Web-basiertes Interface für Datenbank-Applikation in Cloud;
Verbindung über Internet-Technologien:
Universeller Zugriff von verschiedenen Orten
Universeller Zugriff von verschiedenen Plattformen aus
Hoher Aufwand für kleine Daten, häufige Zugriffe
3. Applikationslogik läuft in Cloud:
Daten werden über Funktionen bereitgestellt
Sinnvoll bei notwendiger Verarbeitung der Daten
Seite 13 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Technische Möglichkeiten
Unterschiedliche Arten von Cloud Storages:
Blob-, Object-, Document-Storages
Table Storages
Relationaler Datenbankserver
<nur für internen Gebrauch > / Copyright © Siemens AG 2008. Alle Rechte vorbehalten.
Cloud Storage – BLOB Storage
Speicherung von Text- und Binärdaten in der Cloud
Hierarchie:
Container : eindeutiger Name; enthält BLOB-Objekte
Objekt = Objektdaten (Datei)
+ Metadaten (Attribut/Wert)
+ HTTP-Metadaten (ETag, Last-Modified, Content-Length,
Content-Type, Content-Encoding, Content-Language etc.)
Zugriff:
SOAP & REST über HTTP(S)
APIs dazu (JetS3t, Apache Axis oder .NET)
Container
Objekt; hierarchisch organisiert
Adressierung:
http://photos.s3.amazonaws.com/2009/Barbados/beach.jpg
http://myaccount.blob.core.windows.net/?comp=list
&maxresults=10&include=metadata
Seite 15 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
REST
Representational State Transfer (RFC 2616)
Durch Roy Fielding in seiner Dissertation geprägter Ausdruck,
der Architekturstil für vernetzte Systeme beschreibt
REST-Request kann entweder über HTTP oder HTTPS verschickt werden
Operationen: basierend auf GET, HEAD, PUT, DELETE
In REST ist alles im Web eine Ressource, die über URI zugreifbar ist
XML-Dokument als Antwort
Vorteil von REST: Zugriff sowohl mit Web-Browser als auch programmatisch
aus verschiedenen Sprachen wie Java oder VB.NET mit Hilfe von RESTBibliotheken
Beispiel: Löschen eines BLOB-Objekts
DELETE /photos/2009/Barbados/beach.jpg HTTP/1.1
User-Agent: dotnet
Host: s3.amazonaws.com
Date: Tue, 15 Jan 2008 21:20:27 +0000
x-amz-date: Tue, 15 Jan 2008 21:20:27 +0000
Authorization: AWS 0PN5J17HBGZHT7JJ3X82:k3nL7gH3+PadhTEVn5EXAMPLE
Seite 16 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Operationen
Typische Operationen:
Create / Delete Container
Write / Read / Delete BLOB-Object
List BLOB-Objects
Get / Set Metadata / Properties
Spezielle Konzepte:
Ergebnisbeschränkung & Next-Token
Partielle Blob-Daten
Seite 17 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
XML-Antwort
<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01">
<Name>johnsmith</Name>
<Prefix>photos/2009/</Prefix>
<Marker/>
<MaxKeys>10</MaxKeys>
<Delimiter>/</Delimiter>
<IsTruncated>false</IsTruncated>
<Contents>
<Key>photos/2009/index.html</Key>
<LastModified>2006-01-01T12:00:00.000Z</LastModified>
<ETag>"ce1acdafcc879d7eee54cf4e97334078"</ETag>
<Size>1234</Size>
<Owner>
<ID>214153b66967d86f031c7249d1d9a80249109428335cd08f1cdc</ID>
<DisplayName>John Smith</DisplayName>
</Owner>
<StorageClass>STANDARD</StorageClass>
</Contents>
<CommonPrefixes>
<Prefix>photos/2009/January/</Prefix>
</CommonPrefixes>
</ListBucketResult>
Seite 18 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Java-Programmierung: JetS3t API
/* Create a credentials object and service to access your S3 account */
AWSCredentials myCredentials
= new AWSCredentials(myAccessKey, mySecretKey);
S3Service myService = new RestS3Service(myCredentials);
/* Create new bucket uniquely named after a normalized directory path, */
String containerName = directoryName.replace('\\','_').replace('/','_')
.replace(':', '_');
S3Bucket myContainer
= myService.createBucket(myAccessKey + "." + containerName);
/* Add files from specified directory to bucket */
File directory = new File(directoryName);
File[] files = directory.listFiles();
for (int i = 0; i < files.length; i++) {
if (files[i].isFile()) {
S3Object object = new S3Object(myContainer, files[i]);
myService.putObject(myContainer, object);
}
}
Seite 19 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Cloud Storage – Table Storage
Speicherung von strukturierten Daten
„BigTable“-Konzept (NoSQL):
Tabelle : alle Operationen/Anfragen beziehen sich auf genau eine (riesige)
Tabelle
keine feste Struktur!
keinerlei Beziehungen zwischen Tabellen
Datensatz:
Besteht aus Menge von Attributname/-wert-Paaren
Datensatz wird mit angegebenen Attributen gespeichert
Attribute und Datensätze haben eindeutige Namen
Datentypen: diverse Einschränkungen, z.B. nur String bei Amazon
Seite 20 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Beispiel-Tabelle
ID Category
01 Clothes
Subcat
Sweater
Name
Cathair
Sweater
Color
Size
Siemese S, M, L
02 Clothes
Pants
Designer
Jeans
Blue,
30x32,32x32
Yellow,
Pink
03 Car Parts Engine
Turbos
Make
Model
Audi
S4
04 Motorcycle Bodywork Fender
Blue
Parts
Eliminator
Seite 21 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Eigenschaften
Zugriff auf Daten über REST und SOAP
Nur einfache Queries (insb. kein Join!):
Vergleiche =, >, >=, <, <=, !=
AND, OR, NOT
Reduzierte Lesekonsistenz
Keine „normalen“ Transaktionen
REST-Beispiele:
GET https://sdb.amazonaws.com/?Action=CreateDomain
&DomainName=MyDomain
&AWSAccessKeyId=<Access key ID>
&Version=2009-04-15
&Signature=<Signatur>
&SignatureVersion=2
&SignatureMethod=HmacSHA256
&Timestamp=2007-06-25T15%3A01%3A28-07%3A00
GET http://myaccount.table.core.windows.net/MyTable()?
$filter=(Model%20eq%”S4”)%20and%20(Color%20eq%”Blue”)
Seite 22 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Table Storage vs. (On-Premise) Datenbankserver
+ Geringe Kosten für Setup und Pay-as-You-Go-Konzept: ideal für Start-ups
+ Verzicht auf Aufsetzen und Administration einer hochverfügbaren ClusterDatenbank: zunehmend aufwändiger und kompliziert
+ Keine (komplexe) relationale Datenbank
+ Einfache Bereitstellung von Datenbankfunktionalität
-
Proprietäre Lösungen (vendor-lock-in)
Bescheidene Anfragesprache (kein Join => mehrere clientseitige Aufrufe)
Mitunter keine sofortige Sichtbarkeit von Änderungen auf Daten
Keine direkte Kontrolle über Datenbankserver: z.B. Indexe oder andere
Optimierungen
Keine Stored Procedures, referenzielle Integrität etc.
Diverse Limitationen (z.B. Attributwertgröße limitiert auf 1024 Bytes &
Datenbanken auf 10 GB in AWS)
Neuimplementierung bisheriger DB-basierter Lösungen
Schwere Testbarkeit, z.B. gegenüber lokalem Datenspeicher
XML-basiertes Protokoll verursacht unnötigen Overhead, Latenz und Kosten
Seite 23 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Cloud Storage – Relationaler Datenbankserver
Echter Datenbankserver in der Cloud:
z.B. SQLServer (Microsoft Azure) oder MySQL (Amazon RDS)
„virtueller“ Datenbankserver zur eigenen Verwendung; mehrere Datenbanken
automatische Replikation & Backup der Daten
Ausfallsicherheit (nur bedingt!)
Übliche API‘s statt REST-Protokoll
Zugreifbar:
Von Cloud-Applikationen
Außerhalb der Cloud (z.B. über TDS-Protokoll)
generierter DB-Servername
Spezielle URL:
sqlcmd -S t17j2515ow.database.windows.net
-U MyMasterUser@t17j2515ow -d MyDB
mysql -h myinstance.crwjauxgijdf.us-east-1.rds.amazonaws.com
-P 3306 -u MyMasterUser -p
Problem: Drosselung („throttling“) bei langen Operationen und Überlast
Seite 24 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Produktauswahl
Ein Auswahl prominenter Produkte und Hersteller
<nur für internen Gebrauch > / Copyright © Siemens AG 2008. Alle Rechte vorbehalten.
The Big Players
Microsoft: Windows Azure
Blobs, Tables und erst nicht dann doch SQL Azure
Amazon
Pioneer des Storage Services: S3, Simple DB, RDS
CouchDB
Ein Produkt, ein Open-Source-Projekt für Cloud Storages
Google App Engine (GAE)
Der Späteinsteiger
Seite 26 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Microsoft Windows Azure
Quelle: Microsoft Corp. 2009
Seite 27 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Microsoft Windows Azure
Storage Services im Windows Azure SDK:
Blob Service: für große Datenvolumina
Table Service: für strukturierte Daten
Queue Service: (asynchroner) Datenaustausch
SQL Services:
SQL Azure: SQLServer in der Cloud
(früher SQL Data Services oder SQL Server Data Services)
Huron Data Hub
(auf SQL Azure und Microsoft Sync Framework aufbauend;
Synchronisation verschiedener On-Premise-Datenbankserver mit
spezifizierbaren Konfliktlösungstrategien)
Weitere in Arbeit: Reporting, Data Analytics etc.
Seite 28 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Windows Azure Services Developer Portal
https://windows.azure.com/Cloud/Provisioning/Default.aspx
Seite 29 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Windows Azure SDK
Typen: BLOB, Table, Queue
URI:
http://<Account>.blob.core.windows.net/<Container>/<BlobName>
http://<Account>.table.core.windows.net/<TableName>
http://<Account>.queue.core.windows.net/<QueueName>
Account:
Repräsentiert durch DNS-Name: wird als IP-Adresse aufgelöst, die auf ein
spezielles Data Center verweist
Account ist Geo-Location-Einheit
Wird beim Anlegen zugewiesen
127.0.0.1:10000 als DNS zum Entwicklungszeitpunkt
Seite 30 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
BLOB Service
Speichert Text- und Binärdaten:
Block-Blobs: optimiert für Streaming
Page-Blobs: optimiert für Read/Write-Operationen auf Teile
Terminologie:
Account: Namespace, global eindeutig
Container: keine Schachtelung
Blob: Inhalt, Eigenschaften, Metadaten; virtuelle Verzeichnishierarchie
Spezielle Konzepte:
Filterung: GET http://myaccount.blob.core.windows.net/mycont/
?restype=container&comp=list&prefix=c&maxresults=10&include=metadata
Snapshot: Read-only-Version eines Blobs zu einem Zeitpunkt,
adressierbar über ?snapshot=<Zeitmarke>
Restriktionen:
Timeout = 30 Sekunden für BLOB-Operationen (setzbar)
GET Blob 2 Minuten pro MB
PUT Blob 10 Minuten pro MB
Seite 31 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Table Service
Terminologie:
Account: Namespace, Grundlage für Authentifizierung
Table: Tabelle
Entity: hat Primärschlüssel (RowKey < 1 KB) und bis zu 255 Key-Value-Paare;
Begrenzung auf 1 MB in Summe
Vordefinierte Eigenschaften: PartitionKey, RowKey, Timestamp
Datentypen: byte[], bool, DateTime, double, Guid, Int32, Int64, String
Adressierung:
http://myaccount.table.core.windows.net/Tables
http://myaccount.table.core.windows.net/Tables(‘MyTable’)
?$filter=(Rating%20ge%203)%20and%20(Rating%20le%206)
Ergebnis ist sortiert nach PartitionKey, RowKey
(keine benutzerdefinierte Sortierung)
Restriktion: Query-Ergebnis: max. 1000 Sätze, 5 Sekunden Berechnungszeit
(andernfalls NextToken)
Seite 32 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Microsoft SQL Azure
Datenbankserver in der Cloud, genauer in Microsoft Data Centers
Windows Azure Plattform-Kennung zur Nutzung aller Azure-Funktionalitäten:
Grundlage für Abrechnung aller Service-Nutzungen
Je Azure-Kennung mit Login:
mehrere SQL Azure Server (nicht alle als SQLServer-Instanz implementiert)
jeder Server hat eine Master-Datenbank (wie beim SQLServer)
wenig Unterschiede ggü. SQLServer
Erzeugung und Management über SQL Azure Portal
Je SQL Azure-Server: mehrere Datenbanken; anlegbar mit CREATE DATABASE
oder über SQL Azure Portal
SQL Azure baut auf SQLServer-Technologie auf:
Relationales Datenmodell: Tabellen, Stored Procedures etc.
Vertrautheit: kein Erlernen neuer Tools, Programmier-Plattformen und Datenmodelle
TDS-Netzwerkprotokoll (ADO.NET, ODBC, JDBC etc.)
Security-Prinzipien wie beim SQLServer: SQLServer-Logins, Rollen und
Datenbankbenutzer für Tabellenzugriffe
Benutzung von On-Premise Software wie Management Studio und Reporting Services
Seite 33 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Microsoft SQL Azure
Keine Administration wie Monitoring und Dimensionierung der Platten
bzw. Log-Dateien erforderlich
Hochverfügbarkeit, Zuverlässigkeit und Sicherheit
Automatisches Failover und Lastbalancierung:
Daten werden über mehrere physikalische Server verteilt innerhalb
derselben Geo-Location
Verbesserte Performanz durch Geo-Location (über Portal wählbar) auf
SQLServer-Ebene
Synchronisation von Applikationen und Client-Devices über
gemeinsamen Data Hub
Einfaches Erzeugen, Prototyping und Deployment von Applikationen,
die Daten integrieren
Restriktion der Datenbank-Größe auf derzeit 1 – 10 GB (beim Anlegen)
Seite 34 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Microsoft SQL Azure Nutzung
Quelle: Microsoft Corp. 2009
Seite 35 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Amazon Web Services (AWS)
Amazon Web Services (AWS):
Bezahlbares, hoch-performantes, skalierbares Netzwerk von Applikationen,
für Jedermann mit Amazon.com Kennung zugreifbar
Sofortige Infrastruktur zum Erstellen neuer Webapplikationen für Jedermann
Zugreifbar über das Internet (SOAP, REST)
Libraries für verschiedene Programmiersprachen
Produktpalette mit Services:
Elastic Compute Cloud (EC2)
Simple Storage Service (S3)
SimpleDB
Relational DB Service (RDS)
Simple Queue Service (SQS)
…
Seite 36 - OOP, München, Januar 2010
=> infrastrukturelles Angebot an Rechenkapazität
=> Datenspeicher (BLOB), hohe Bandbreite
=> verteiltes „Datenbanksystem“
=> MySQL Datenbank
=> MoM, Austausch 1000 Nachrichten pro Min
© Michael C. Jaeger und Uwe Hohenstein
APIs und Authentifizierung
Zur Nutzung eines AWS Web Service:
AWS-Kennung (auch Bestehende)
Über http://aws.amazon.com zu beziehen
Auch Benutzungsberichte und Zugriffsdaten darüber abfragbar
AWS erzeugt erzeugt zwei Schlüssel:
Einen 20-Zeichen, alphanumerischen Access Key ID
Einen 40-Zeichen Secret Access Key
Normalerweise
Programmiersprachen-spezifische Library (z.B. für Java)
Kein Aufwand mit Signaturen, Zertifikaten, Signierung etc.
Seite 37 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Amazon S3 – BLOB Storage
“On demand” Speicher für das Internet (“persönliche Festplatte”)
2006 in USA (und EU) vorgestellt
Terminologie:
Bucket = Container (bis zu 100 je Kennung)
Object = Objektdaten (Datei) + Metadaten (Attribut/Wert)
+ HTTP-Metadaten
Unbegrenzte Anzahl Objekte, bis zu 5 GB Größe
Adressierung:
Schlüssel: lokal eindeutig innerhalb Bucket
Z.B. http://docs.s3.amazonaws.com/2006-03-01/AmazonS3.wsdl
Zugriff: SOAP 1.1, REST, APIs für Java, C#, Perl, PHP, Python, Ruby
Seite 38 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Spezielle Konzepte
Konkurrierende Zugriffe:
Änderungen werden aufgrund einer internen Replikation nicht sofort sichtbar
Atomare Schreib-/Leseoperation
Keine Sperren: der letzte Schreiber gewinnt
Kostenreduktion durch:
POST Upload (Inhalt wird direkt an S3 geleitet, kein Umweg über Web Server)
Requester Pay: Download-Kosten beim Aufrufer
(auch: Kopplung zum Amazon DevPay-Bezahlmechanismus)
Amazon Import/Export: Service zum schnellen Upload von Tera-Bytes
Chunked Downloads
Geographical Region
Zugriffskontrolle über Access Control Policy (ACP) für Bucket oder Objekt:
Grantee (Owner, User by E-mail, User by Canonical Representation, AWS
User Group, Anonymous Group)
Permission (READ, WRITE, READ_ACP, WRITE_ACP, FULL_CONTROL)
Seite 39 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Amazon SimpleDB – Table Storage
Eigenschaften:
„Datenbank in der Cloud“
80% der Anforderungen an Datenbanken abdecken
Einfachheit: einfacher, zugeschnittener Zugriff ohne Schnick-Schnack
Flexibilität: kein vordefiniertes DB-Schema, automatische Indexierung
Skalierbarkeit mit Datenvolumen
Hochverfügbarkeit: Verwaltung in Amazon‘s Hochverfügbarkeitszentren
Kosteneffizienz: Bezahlung nach aktuellem Verbrauch
Optimierung für Betrieb mit S3 und EC2: innerhalb AWS anfallender
Verkehr wird nicht gezählt
APIs: REST (HTTP(S)) & SOAP mit/ohne WS Security (nur HTTPS)
„Amazon SimpleDB is not a database!“ [N. Shalom]
Seite 40 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Amazon SimpleDB
Domäne (Domain):
Entspricht im Wesentlichen einer Tabelle ohne feste Struktur
Bis zu 100 Domänen möglich je Benutzer, 10 GB je Domain
Keinerlei Beziehungen zwischen Domänen
Alle Operationen/Anfragen beziehen sich auf genau eine Domäne
Item:
Entspricht Datensatz in Tabelle
Besteht aus Menge von Attributname-/Wert-Paaren
Item wird mit angegebenen Attributen gespeichert
Attribut: kann mengenwertig sein, z.B. Color = { blue, red }
256 Attribute pro Item
Attributwert < 1024 Bytes
1 Milliarde Attribute pro Domäne
Attribute und Items haben eindeutige Namen
Typen: nur String (lexikographische Ordnung)!
Seite 41 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Amazon RDS – Cloud-Datenbankserver
Amazon Relational Database Service (Amazon RDS):
Einfacher Setup, Betrieb und Skalierung einer relationalen Datenbank
(MySQL 5.1) in der Cloud
Liefert kosten-effiziente, erweiterbare relationale Datenbank (Industriestandard)
Übernimmt Management allgemeiner Datenbankadministrationsaufgaben
Code, Applikationen und Werkzeuge funktionieren wie mit existierender
MySQL-Datenbank ohne Modifikationen
Zu Beachten:
Wöchentliches 4-stündiges Wartungsintervall (evtl. Mit Down-Zeit)
Vorab-Festlegung der Datenbankgröße und Instanzklasse
Kein Verkleinern der Datenbank; nur 10% Vergrößerung
Abfragen von DB-Metriken
Anlegen einer Datenbank:
rds-create-db-instance myinstance –s 50 –c db.m1.large -–backup
-retention-period 3 –u super –p pw -–preferred-maintenance-window
Tue:00:30-Tue:04:30
https://rds.amazonaws.com/?Action=CreateDBInstance&DBName=...
Seite 42 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Eigenschaften
Zuverlässigkeit:
Amazon RDS läuft auf derselben hoch-zuverlässigen Infrastruktur wie
andere Amazon Web Services
Hochverfügbarkeit erst später!
Automatischer Backup-Service: Zurücksetzen auf beliebigen Zeitpunkt
(innerhalb spezifizierbarer Aufbewahrungsperiode)
Bestandteil der AWS-Produktfamilie:
Integration mit anderen Produkten
Geringe Latenzzeit für Zugriff aus Amazon EC2
Sicherheit:
Konfigurierbare Firewall
Seite 43 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
CloudDB – Relax!
Dokumenten-Speicher
Dokument = Inhalt + Metadaten
„Dokumenten-orientierte" Datenbank
Nutzt JavaScript Object Notation (JSON)
Strukturiert Daten in B-Trees
Wird bereits benutzt in
Ubutu 9.10, integriert in Productivity Apps 'ubuntu one'
Cloudant SaaS Provider
Content Management System (CMS) beim BBC
CMS für einige Websites (z.B. Facebook Anwendungen)
CAP Theorem – trade-off zw. Konsistenz, Verfügbarkeit und Partitionierung
CouchDB fokussiert auf Verfügbarkeit und Partitionierung
Stellt nicht sicher, dass überall gleiche Sicht vorhanden ist
Stattdessen: “Mögliche Konsistenz", warten auf ‘Agreements’ ausgelassen
Kann für bestimmte Anwendungen von Vorteil sein
Seite 44 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
CouchDB - Datenverarbeitung
Nebenläufigkeit ohne Sperren, optimistischer Ansatz
‘Multi-Version Concurrency Control’ (MVCC)
Änderungen erzeugen neue Version, zwischenzeitliche Lesezugriffe
erhalten alte Version
Nebenläufige Änderungen führen zum Konflikt bei der später
sichernden Partei
Eigene Verfahren zur Konfliktbewältigung möglich
Schreiboperationen werden versucht, konsistent zu halten
Änderungen als Sequenz von Schreiboperationen
Im Falle eines Fehlers geht eine Reihe von Änderungen verloren
Zweistufiger Schreibprozess (auf Festplatte): Header und Schreiben
der Daten jeweils atomar
Seite 45 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
CouchDB - Datenorganisation
Konzept von Sichten
Eine Sicht definiert eine Menge von Dokumenten aus der DB
Definition einer Sicht wird ebenfalls in DB gespeichert
Eine Sicht ist eine Funktion, die auf ein Dokument angewendet wird
Performanzproblem: kontinuierlich gepflegter Index
Eine Sicht kann sehr schnell abgerufen werden, die Aktualisierung
benötigt u.U. etwas länger
Replizierung zwischen verschiedenen CouchDB Servern möglich
Durch das anknüpfende Schreiben von Aktualisierungen leicht
koordinierbar
Priorität ist ein ‚non-destructive resolve‘
Selbst modifizierbares Verfahren entscheidet im Konfliktfall
Andere(s) bleiben in CouchDB, werden nur nicht als aktuelles
markiert
Seite 46 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Google Chrome / Google App Engine
Google’s Plattform für Anwendungen
Small Business, Hobby und vielleicht Enterprise
Starke Limits (zurzeit geplant)
1MB Limit für jede Datenstruktur
1GB Datenbank
maximal 30 Sek. Dauer zur Bearbeitung einer Anfrage
maximal 1000 Einträge pro Abfrage
Überlastschutz für Rechenzeit und Anzahl der Anfragen
Zwei Datenspeicher: BigTable und MemCache
MemCache: einfacher Datenspeicher für schnellen Zugriff
Temporärer Speicher
BigTable: Non-relationaler Tabellenspeicher
Dateisystem nur Lesezugriff
Seite 47 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
BigTable Non-Relational?
Zugriff unter Java:
Kein Schema
Definition über Klassen
Java: JDO oder JPA / DataNucleus Access Plattform
Hauptproblem: Verteilung von Tabellen vs. Performanz
Lösung:
Verteilung weglassen
GQL (statt JPQL)
Einfache WHERE Statements, keine Konjunktionen
keine JOIN Statements
Seite 48 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Allgemeine Aspekte
Kostenmodelle und Migration
<nur für internen Gebrauch > / Copyright © Siemens AG 2008. Alle Rechte vorbehalten.
Kostenmodell
Pay-as-You-Go-Modell
Keine Fixkosten
Nur aktueller Verbrauch (“per use”)
Bezahlung nach
Speicherplatzbelegung in der Cloud
Ein-/ausgehender Datentransfer (XML!)
CPU-Benutzung oder Anzahl Requests
DB-Konfiguration
Seite 50 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Kostenmodell: Amazon S3 BLOB Storage
Speicherbelegung (Europa):
$ 0.18 per GB – für die ersten
50 TB / Monat
$ 0.17 per GB – für die nächsten 50 TB / Monat
$ 0.16 per GB – für die nächsten 400 TB / Monat
$ 0.15 per GB – über 500 TB
(=> $ 180 für ein TB !)
eingehender Datentransfer:
$ 0.10 per GB
ausgehender Datentransfer:
$ 0.17 per GB – für die ersten
10 TB / Monat
$ 0.13 per GB – für die nächsten 40 TB / Monat
$ 0.11 per GB – für die nächsten 100 TB / Monat
$ 0.10 per GB – über 150 TB / Monat
Anzahl Requests:
$ 0.012 pro 1,000 PUT, COPY, POST, or LIST Requests
$ 0.012 pro 10,000 GET und alle anderen Requests; keine Kosten für delete
Seite 51 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Kostenmodell: Amazon SimpleDB
Speicherbelegung:
1 GB frei
$ 0.25 pro GB-Monat
SimpleDB misst Größe der Daten: Raw Bytes des Uploads
+ 45 Bytes Overhead für jedes Item, Attributname und Attribut-Wert-Paar
CPU-Benutzung:
25 SimpleDB Maschinenstunden pro Monat frei
$ 0.14 pro nachfolgender verbrauchter SimpleDB Maschinenstunde
Jede Operation liefert CPU-Verbrauch
Datentransfer:
1 GB pro Monat frei für ein/ausgehenden Datentransfer
$ 0.10 pro GB eingehenden Datentransfer danach
Für ausgehenden Datentransfer: $ 0.17 pro GB für die ersten 10 TB
(danach günstiger)
Seite 52 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Kostenmodell: Amazon RDS
DB-Konfiguration: (anzugeben beim Anlegen der DB)
Small
Large
Extra Large
Double Extra Large
Quadruple Extra Large
$ 0.11
$ 0.44
$ 0.88
$ 1.55
$ 3.10
(jeweils pro Stunde)
Speicherbelegung: (von 5 GB bis zu 1 TB, anzugeben beim Anlegen der DB)
$ 0.10 pro GB-Monat
$ 0.10 je 1 Million I/O-Requests
kein Schrumpfen!
Backup-Speicherung: automatische Backups & nutzerinitiierte DB-Snapshots;
festlegbarer Aufbewahrungszeitraum
Frei bis zu 100% der provisionierten Speicherbelegung
$ 0.15 pro weiteren GB-Monat (auch nach Ende des Datenbankserver-Betriebs)
Datentransfer:
eingehend: $ 0.10 pro GB
ausgehend: $ 0.17 pro GB, ab 10 TB günstiger
Seite 53 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Migration -- Klärungsbedarf
Grundsätzlich muss das Preismodell überprüft werden
Wird die Migration zu finanziellen Einsparungen führen?
Limitationen können auf Grund des Preismodells interessant werden
Z.B. Preissprung bei 1GB Datenbankgröße
Es muss beachtet werden, dass On-Premise Lösungen zusätzlichen
Synchronisationsaufwand erzeugen (=> zusätzlicher Verkehr)
Die Anwendung muss für ‘Multi-Instance’ Betrieb ausgelegt sein
SLA muss überprüft werden
Wie werden Wartungsarbeiten umgesetzt? Backup?
Spezielle Ausrichtungen bei Geo Location können wichtig sein
Es bringt Vorteile bei einer Datenbank-Familie zu bleiben
Z.B. Microsoft SQL Server nach SQL Azure (basierend auf SQL Server)
oder MySQL nach Amazon RDS
BigTable-Ansatz eher geeignet für Neuentwicklung von Anwendungen?
Seite 54 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Technische Besonderheiten
Cloud Computing ist (noch) ein dynamisches Feld, ständige Änderungen an
den APIs und den Limitierungen
Im Projekt sind mehrere API-Änderungen möglich
Zum Beispiel: Microsoft, Google App Engine: Gleiche Toollandschaft
Gute Integration in Visual Studio bzw. Eclipse oder Ant
Keine Kontrolle über Hard- und Software
Kein Aufruf von Betriebssystemfunktionen,
bei GAE z.B. keine Threads möglich
Sicherheitsbedenken beim Transfer zwischen Provider Cloud
und On-Premise Clouds
Wie werden die Daten auch bei Übertragung geschützt
Hohe Latenz möglich
In SF Bay Area 6 msec to GAE, aber in München?
Cloud Storage Lösungen haben andere Datentypen
=> Verlust von primitiven Typen möglich
Seite 55 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Zum Mitnehmen
<nur für internen Gebrauch > / Copyright © Siemens AG 2008. Alle Rechte vorbehalten.
Generelle Punkte bei der Umsetzung
Cloud Storage Lösungen fokussieren auf Ansätze, die weniger Komplexität im
Datenmodell erlauben als traditionelle RDBMS
Zugunsten Performanz / Skalierbarkeit
Möglichkeit, relationales Datenmodell zu überdenken
Die Art der Daten entscheidet die Nutzung der Storage-Dienste
Relationales Datenmodell passend?
Speicherung von Bildern, Videos?
Die Anwendung entscheidet die Architektur
Anwendungen verlangen On-Premise Lösung?
Balance zwischen lokaler Anwendung und Nutzung der Cloud
Beachtung des Kostenmodells
Unterschiede bei den Anbietern
Unterschiedliche Eignung für verschiedene Anwendungen
Seite 57 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Zusammenfassung
Nachteile
Keine Kontrolle über technischen und organisatorischen Betrieb
SLAs zur Zeit unklar: Wann werden Vereinbarungen getroffen?
Zusätzlich: Begrenzung der Query Laufzeit als Schutzmassnahme
Vertraulichkeit von entstehenden Daten eventuell nicht ausreichend
Große Vorteile bei Kosten und Performance durch Vereinfachung
Höhere Latenzzeiten beim Zugriff in die Cloud
Vorteile
Kostengünstiger Einstieg, geringe Investitionskosten
Schnelle Verfügbarkeit der Infrastruktur
(Unter Umständen) hohe Skalierbarkeit
Für gewisse Applikationen großen Einsparungen möglich durch
Rationalisierung
Geringer Aufwand gegen Administrationen eigener Speicherlösungen
Seite 58 - OOP, München, Januar 2010
© Michael C. Jaeger und Uwe Hohenstein
Vielen Dank für Ihre Aufmerksamkeit
Dr. Michael C. Jaeger
Siemens AG, CT T DE IT1
[email protected]
Corporate Technology,
Global Technology Field
System Architecture and
Platforms
Dr. Uwe Hohenstein
[email protected]
Otto-Hahn-Ring 6
81730 München
Within Corporate Technology, the GTF System Architecture and Platforms focuses on software
architectures for a wide range of software-types. This includes embedded systems, desktopsoftware and also networked and enterprise software. The GTF SA&P has knowledge in a lot
of different operating systems and runtime environments including Linux, Java (J2ME, JSE,
JEE), .NET, COM, Windows, OSGi, Mac OS X and the recent field of cloud computing.
<nur für internen Gebrauch > / Copyright © Siemens ©
AG
M.2008.
C. Jaeger
Alle Rechte
und U. vorbehalten.
Hohenstein.
Herunterladen