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.