Warmer Regen oder Gewitter: Cloud Storage

Transkript

1 Warmer Regen oder Gewitter: Cloud Storage Frühjahrstreffen der GI Fachgruppe Datenbanksysteme zum Thema Database as a Service 6. Mai 2010, Leipzig Uwe Hohenstein, Michael C. Jaeger Siemens CT T, Corporate Research and Technologies Global Technology Field System Architecture and Platforms Page 1 - Database As a Service, Mai 2010

2 Übersicht Erwartungen an Cloud Computing Kategorien von Cloud Storage Lösungen Bewertung der Cloud Storage Lösungen Page 2 - Database As a Service, Mai 2010

3 Vorteile des Cloud Computing [Armbrust et al. 1999] 1. Prinzipiell unbegrenzte Verfügbarkeit an Ressourcen 2. Geringe Investitionen (Anschaffungskosten) und Kostenreduktion 3. Elastizität ( Pay As You Go ) Weitere: 4. Ausfallsicherheit und Hochverfügbarkeit 5. Verringerung des administrativen Aufwands 6. Standardisierung Bewertung von Cloud Storage-Lösungen Bestandsaufnahme vom März 2010! Page 3 - Database As a Service, Mai 2010

4 Cloud Storage Cloud Storage als Ressource des Cloud Computing Speicherung von Daten in der Cloud Speicher für DB-Anwendungen in der Cloud Verzicht auf selbst-administrierten Datenbankserver Verfügbarkeit Kategorien: a) BLOB Storage: Virtuelles Dateisystem b) Table Storage: BigTable-Ansatz, NoSQL-Datenbank c) (echter) DB-Server [ d) Plattenspeicher (z.b. Amazon EBS) ] Page 4 - Database As a Service, Mai 2010

5 a) BLOB Storage BLOB = Binary Large Object 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.) Adressierung: &maxresults=10&include=metadata Zugriff: SOAP & REST (Representational State Transfer (RFC 2616)) über HTTP(S) APIs dazu (JetS3t, Apache Axis oder.net) Produkte: Blob Service (Microsoft Azure SDK), Amazon S3 Page 5 - Database As a Service, Mai 2010

6 BLOB Storage (2) 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 Page 6 - Database As a Service, Mai 2010

7 b) Table Storage Speicherung von strukturierten Daten BigTable -Konzept (NoSQL): Tabelle : alle Operationen/Anfragen beziehen sich auf genau eine (riesige) Tabelle keine feste Struktur: Datensatz, bestehend aus ID + Menge von Attributname/-wert-Paaren, wird gespeichert keinerlei Beziehungen zwischen Tabellen Produkte: Amazon SimpleDB, Google BigTable, Table Service im Azure SDK Zugriff: SOAP & REST über HTTP(S); APIs $filter=(model%20eq% S4 )%20and%20(Color%20eq% Blue ) Page 7 - Database As a Service, Mai 2010

8 Table Storage: Beispiel-Tabelle ID Category Subcat Name Color Size Make Model 01 Clothes Sweater Cathair Pink S, M, L Sweater 02 Clothes Pants Designer Jeans Blue, Yellow, Pink 30x32,32x32 03 Car Parts Engine Turbos Audi S4 04 Motorcycle Parts Bodywork Fender Eliminator Blue Zugriffe: Nur auf eine Tabelle Kein Join Page 8 - Database As a Service, Mai 2010

9 c) Relationaler Datenbankserver Relationaler Datenbankserver in der Cloud: z.b. SQLServer (Microsoft Azure) oder MySQL (Amazon RDS) virtueller Datenbankserver zur eigenen Verwendung; mehrere Datenbanken übliche API s statt REST-Protokoll Produkte: SQL Azure, Amazon RDS, Oracle Image für AWS Zugreifbar: über übliche Protokolle mit spezieller DB-URL Von Cloud-Applikationen Außerhalb der Cloud sqlcmd -S t17j2515ow.database.windows.net -U MyMasterUser@t17j2515ow -d MyDB mysql -h myinstance.crwjauxgijdf.us-east-1.rds.amazonaws.com -P u MyMasterUser -p Page 9 - Database As a Service, Mai 2010

10 Bewertung der Storage-Lösungen Elastitizät hinsichtlich Datenvolumen: BLOB: Ok Table: - Begrenzung der Anzahl Tabellen sowie Tabellengröße => Reaktion (z.b. Umverteilung, Erweiterung) nötig - Werte kleiner als 1 KB DB-Server: - (noch) relativ kleine DB-Größe bei SQL Azure (10 GB), 5GB 1TB bei RDS - vereinbarte (!) Maximalgröße wird provisioniert: Reaktionszeit bei Änderung? - vorgefertigte Instanzkategorien S, M, L, XL etc. (bestimmt Cachegröße, Anzahl Connections, Kerne etc.) Page 10 - Database As a Service, Mai 2010

11 Bewertung der Storage-Lösungen (2) Kosteneinsparung durch Elastizität: Kostenmodelle teilweise noch im Wandel Einflussfaktoren: Speicherkosten, CPU-Nutzung, Datentransfer, Unterschiedliche Preise je Region (US East/West, EU) BLOB: - hohe Kosten, z.b. 150 $ pro Monat für 1 TB bei Amazon S3 - Kostenskalierbarkeit gegeben Table: - mitunter kostenloser Basissockel (keine Fix/Verbrauchskosten) - danach Abrechnung nach Verbrauch DB-Server: - vorgefertigte Instanzkategorien (S, M, L, XL etc.) - Speicherprovisionierung Page 11 - Database As a Service, Mai 2010

12 Bewertung der Storage-Lösungen (3) Ausfallsicherheit/Hochverfügbarkeit: BLOB/Table: - mehrfache Replikation der Daten - Abbruch von Query-Ergebnissen (Next-Token) DB-Server: - demnächst Replikation - Wartungsintervall (4 Stunden pro Woche bei RDS) - Abbruch von Queries bzw. verzögertes Re-Connect - Ausfall bei Wechsel der Instanzgröße (bei Performanzproblemen)? Page 12 - Database As a Service, Mai 2010

13 Bewertung der Storage-Lösungen (4) Administrationsaufwand: BLOB: nur Anlegen einer Benutzerkennung Table: - automatische Indexe (Performanz?) - Überwachung der Table-Größe (maximale Obergrenze) DB-Server: vorgefertigte Instanzen (keine Kontrolle über Platten) - Überwachung der DB-Größe - DBA-Aktivitäten wie Anlegen von Indexen Standardisierung: BLOB/Table: - kein Standard, aber ähnliche Konzepte mit unterschiedlichen APIs - REST/SOAP-Protokoll - Ansätze wie SimpleJPA oder SimpleORM DB-Server: - üblicher DBserver mit SQL und üblichen Standard APIs (JPA, JDO etc.) Page 13 - Database As a Service, Mai 2010

14 Sonstiges Service Level Agreements Mehr als Geld zurück? Zugang aus Firmennetz Auf DB-Server: Probleme mit Proxy Auf BLOB/Table Storage kein Problem Gesetzliche Aspekte Bezahlung Firmenkreditkarte und dann? Page 14 - Database As a Service, Mai 2010

15 Fazit Cloud Storage <> Datenbanksystem Vorteile des Cloud Computing sind für Cloud Storage nicht immer gegeben Cloud Applikation: => Cloud Storage sinnvoll => Gesamtkosten betrachten => Table Storage mit Portabilität schlecht verträglich Cloud Storage ohne Cloud Applikation => sorgfältige Analyse, insbesondere der Kosten Partitionierung frühzeitig berücksichtigen Page 15 - Database As a Service, Mai 2010

16 Danke für die Aufmerksamkeit! Uwe Hohenstein Michael C. Jaeger Siemens AG, CT T DE IT1 Corporate Technology, Global Technology Field System Architecture and Platforms Otto-Hahn-Ring München Within Corporate Technology the Global Technology Field System Architecture and Platforms focuses on software architectures for a wide range of software-types. This includes embedded systems, distributed applications, and enterprise software. In the recent field of cloud computing the focus is cloud computing architecture for cloud platform stacks and applications. Cloud computing architecture is key for scalability, cost efficiency, and meeting of legal and business requirements. These activities are completed by the industry focused evaluation of strategic cloud computing platforms in order to support customers on their way to cloud computing. Page 16 - Database As a Service, Mai 2010