Service Computing Einführung Prof. Dr. Ramin Yahyapour IT & Medien Centrum 13. Oktober 2009

Logistik Vorlesung: Übung: Terminänderungen beachten: Prof. Dr. Ramin Yahyapour Dienstag, 8:30- 10 Uhr Übung: Dr. Thomas Röblitz Donnerstag: 14:15 – 16 Uhr (?) Praktische Übungen Terminänderungen beachten: Beispiel: Kommende Woche am Donnerstag Vorlesung! LSF Anmeldung für Mailingliste und Materialien in EWS

Overview What is Service, Cloud, Grid Computing? Application Examples Architecture of Grids Current Development Similarities to eBusiness Solutions and Ubiquitous Computing

Vorstellung IT & Medien Centrum Das ITMC ist der IT und Medien Dienstleister der Universität Beispiele: Management der Netzwerk-Infrastruktur bis an die Dose bzw. WLAN Zugang, DNS, Firewall, DHCP Support-Services Service-Desk Graphik, Print E-Learning Audio/Video-Erstellung und Bearbeitung Betrieb zentraler Server und Dienste eMail, Groupware Identity Management Web-Server Campus Management/Ressourcen Management Hosting und Housing von Servern Betrieb von HPC-Systemen für wissenschaftliches Rechnen.

Wiss. Rechnen/ HPC an der TU 2006: LiDO 464 CPU Cores (AMD) 20 Tbyte Storage 2008: D-Grid Ressourcen Zentrum Ruhr (DGRZR) 2048 CPU Cores (Intel) 110 Tbyte Storage 2009: LiDO2 3328 CPU Cores (Intel) 215 Tbyte Storage

Traditioneller Rechnerbetrieb WebApp DB Service X Mail Dedizierte System für Anwendungen HW angepasst auf Anwendung, daher hohe Performanz Systeme teilweise redundant für Ausfallsicherheit Heterogene Infrastruktur Kapazitäten meist überdimensioniert, um künftiges Wachstum vorwegzunehmen Physische Hardware Operating System Anwendung Storage/Network Physische Hardware Operating System Anwendung Storage/Network Physische Hardware Operating System Anwendung Storage/Network Physische Hardware Operating System Anwendung Storage/Network Physische Hardware Operating System Anwendung Storage/Network Physische Hardware Operating System Anwendung Storage/Network

Virtualisierung von Rechnern Der Einsatz von Virtualisierung erlaubt eine Trennung von HW und Anwendung. VM sind isoliert voneinander Mehrere VMs können sich einen Host teilen Heterogenität kann besser verwaltet werden. Die Ressourcen lassen sich zuteilen und partitionieren. Physische Hardware Storage/Network Virtualisierungs- plattform (Xen, vmWare, Hyperv) Anwendung Virtuelle Maschine Gast OS Physische Hardware Storage/Network Virtualisierungs- plattform (Xen, vmWare, Hyperv) Anwendung Virtuelle Maschine Gast OS Physische Hardware Storage/Network Virtualisierungs- plattform (Xen, vmWare, Hyperv) Anwendung Virtuelle Maschine Gast OS Physische Hardware Storage/Network Virtualisierungs- plattform (Xen, vmWare, Hyperv) Anwendung Virtuelle Maschine Gast OS Physische Hardware Storage/Network Virtualisierungs- plattform (Xen, vmWare, Hyperv) Anwendung Virtuelle Maschine Gast OS Nach Forrester: Über 30% Kostenersparnis

Änderung für den Betrieb eines Data Centers Trennung von Ressourcen und Anwendungen Ressourcen werden dynamisch zugeteilt Ressourcen werden selbst als Services angeboten Services Virtualisierungs-Management Virtuelle Server Speicher- virtualisierung Netzwerk virtualisierung ITMC: Server-Virtualisierung seit 2008 Speicher-Virtualisierung projektiert CPUs Physical Storage Physical Network

In die Wolken: Cloud Computing Kommerzielle Anbieter liefern Ressourcen (Amazon EC2) On-demand Zugang zu Ressourcen „Elastizität“ (dynamische Anpassung) Pay-per-use Nutzung wird einzeln abgerechnet Leichter Einstieg SaaS Software as a Service Applikationen Plattform zur Erstellung von Applikationen PaaS Platform as a Service IaaS Infrastructure as a Service Infrastruktur für Server, Speicher, Netzwerk, …

Amazon Web Services EC2 (Elastic Computing Cloud) ist der Computing Service von Amazon Basiert auf Hardware Virtualisierug (Xen) Nutzer fragen virtuelle Maschonen und und verweisen auf ein ein VM-Image,das in S3 abgelegt ist. Nutzer haben volle Kontrolle über die Instanzen (z.B. Root-Zugang, wenn notwendig). Anfragen können über SOAP oder REST erfolgen. S3 (Simple Storage Service) ist der Storage Service von Amazon, um Daten in der Cloud zu speichern Unabhängig von anderen Diensten nutzbar Daten werden hierarchisch organisiert und als Objekte oder Buckets abgelegt Zugriff über SOAP, REST und BitTorrent Weitere AWS Dienste: SQS (Simple Queue Service) SimpleDB Billing services: DevPay Elastic IP (Static IPs for Dynamic Cloud Computing) June 2, 2008

Beispiel: Amazon WS EC2 Dienst: Hosting Virtueller Maschinen on Demand 26.03.09 10:15 Beispiel: Amazon WS EC2 Dienst: Hosting Virtueller Maschinen on Demand Service Level Agreement (SLA): “Amazon EC2 SLA commitment is 99.95% availability for each Amazon EC2 Region” CPU-Leistung: [gemessen in “EC2 Compute Unit” (ECU)] “One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.”

Beispiel: Amazon WebServices EC 2 26.03.09 10:15 Beispiel: Amazon WebServices EC 2 Standard Instances Small Instance 1.7 GB Hauptspeicher, 1 EC2-Compute-Unit (1 virtual CPU-core), 160 GB Hintergrundspeicher, 32-bit Plattform Large Instance 7.5 GB Hauptspeicher, 4 EC2-Compute-Unit (2 virtual CPU-cores), 850 GB Hintergrundspeicher, 64-bit Plattform Extra Large Instance 15 GB Hauptspeicher, 8 EC2-Compute-Unit (4 virtual CPU-cores), 1690 GB Hintergrundspeicher, 64-bit Plattform High-CPU Instances High-CPU Medium Instance 1.7 GB Hauptspeicher, 5 EC2-Compute-Unit (2 virtual CPU-core), 350 GB Hintergrundspeicher, 32-bit Plattform High-CPU Extra Large Instance 7 GB Hauptspeicher, 20 EC2-Compute-Unit (8 virtual CPU-cores), 1690 GB Hintergrundspeicher, 64-bit Plattform

Public/Commercial Clouds Klares Business Modell (Pay by Creditcard..) Aktiver Markt mit vielen Anbietern Metering, Accounting, Billing Einstieg einfach und günstig … Ausstieg nicht! Für größere Data Center nur begrenzt attraktiv

Private Clouds Dienstorientierung innerhalb eines Data Centers Angebot von Infrastruktur oder Plattformen als Dienst Beispiel: ITMC liefert virtuelle Maschinen Storage on-demand für Lehrstühle Klare Web-Schnittstellen für den Nutzer Attraktives Management- Modell; Dynamische Skalierbarkeit CPUs Services Physical Storage Virtualization Management Physical Network Virtuelle Server Speicher- virtualisierung Netzwerk virtualisierung 1) Dynamische Skalierung Weitere Ressourcen 2) Scale-Out CPUs Services Physical Storage Virtualization Management Physical Network Virtuelle Server Speicher- virtualisierung Netzwerk virtualisierung Einbindung von externen Ressourcen

Cloud Computing – Hype ? Gartner Hype Cycle 2008 Hype! Aber Konzepte bleiben.

Bewertung Clouds Einfaches Managementmodell Klare Schnittstellen Betreiber Dienste Betreiber Infrastruktur Klare Schnittstellen Betreiber Infrastruktur sieht die Anwendung nicht. Hohe Effizienz auf Seiten des Betriebs Management von vielen VMs möglichst effizient auf verfügbaren Ressourcen Ähnliche Entwicklung bei Storage Hohe Flexibilität Erzeugung von neuen VMs auf Knopfdruck Offenheit von Clouds zurzeit noch nicht gegeben „Einbahnstraße“ zu einem Provider Aktuelle Bestrebungen zur Liberalisierung und Standardisierung

Unterstützung neuer Angebote 26.03.09 10:15 Unterstützung neuer Angebote Beispiel von Amazon: Animoto, “Scale as you grow” (Musik-unterlegte Videos aus eigenen Bildern) http://www.animoto.com

Eigenschaften eines Anbieters 26.03.09 10:15 Eigenschaften eines Anbieters

Grid Computing? Ressourcen „teilen“ (sharing) Produktionsumgebung in vielen Disziplinen Kollaboration in Forschungsgruppen Betrieb und Nutzung sind kompliziert TU Dortmund in mehreren Grids beteiligt

Clouds für HPC Kann Virtualisierung und Cloud Computing für wissenschaftliches Rechnen genutzt werden? Abhängig von der wiss. Anwendung Parallele Applikationen mit hohen Kommunikationsanforderungen: wenig geeignet „Bag of Tasks“ Anwendungen mit geringen Anforderungen: durchaus geeignet Vorteil: Virtualisierung findet unabhängig Einzug in DataCenter: Knowhow vorhanden VMs erlauben besser auf die Bedürfnisse der Nutzer einzugehen… … und Verantwortlichkeit auf den Nutzer zu übertragen (Software-Pflege) Mehr Freiheitsgrad im Management (Migration, Preemption) Langfristig: Job = Virtuelle Maschine Es wird künftig spezielle HPC-Systeme und Compute Clouds geben

Ressourcen Management Das automatische Management von Clouds oder Grids ist eine komplexe Aufgabe Welche Ressourcen werden für welchen Dienst/Anwendung wann eingesetzt? Hoch dynamisch und von der Arbeitslast/Workload abhängig Optimierungsziele: Antwortzeit Qualität Kosten Ressourcenverbrauch Strom (!) Multikriterielles Optimierungsproblem

Unterschiede zwischen Grids und Service Computing Grids führen meist Batch-Jobs aus: Dynamische Einreichung neuer Jobs, meist unabhängig Batch Queuing-Systeme Typischerweise “Space-sharing” Ausführung Sequentielle oder parallele Applikationen Clouds/SOA/SOI sind: Meist transkations-orientiert, wiederholende Dienste Hosting ist für lange Zeiträume Häufig “time-sharing” Ausführung Meist synchrone Workflows über verschiedene Dienste Gekoppelte Ressourcen Hosting Environment, AppServer, Datenbank

SOI Ressourcen-Management Services Neue Dienste Virtualization Management Virtuelle Server Speicher- virtualisierung Netzwerk virtualisierung CPUs Physical Storage Physical Network

Ressourcen-Management Services Neue Dienste Virtualization Management Verteilung auf Ressourcen Virtuelle Server Speicher- virtualisierung Netzwerk virtualisierung Dynamische Anpassung der Infrastruktur CPUs Physical Storage Physical Network Aktivierung und Deaktivierung von Ressourcen

Technische Herausforderungen Einheitliche Schnittstellen und Interoperabilität Dynamisches Ressourcen Management Auf Seiten der Nutzer beim Verteilen der Ressourcen Für den Betreiber im Management der Dienste Komplexität beherrschen! Skalierbarkeit, Effizienz, Dynamik, Verfügbarkeit Management von x1000 Diensten ist anspruchsvoll Komplexe Geschäftsbeziehungen zu den einzelnen Diensten Koordinierung Ein einzelner Dienst ist häufig uninteressant, Die Orchestrierung von Diensten über verschiedene Ressourcen ist notwendig Beispiel: SLA Management

Service Level Agreements Es existiert ein starker Trend Service-Management über SLAs abzubilden. Elektronischer bilateraler Kontrakt definiert im Vorfeld: Dienstgüte Rahmen-/Nutzungsbedingungen Technische Anforderungen Optimierungsziele Kosten/Strafen Automatische Verhandlungs- prozesse werden benötigt Das SLA ist elektronisch auswertbar. SLA Beschreibung Translation Monitoring Adaption Optimierungs- problem Optimierungs- problem Verhandlungs- protokoll Consumer Provider

Experiment: Overhead für SLA Erstellung Parallele Anwendung benötigt mehrere Rechenressourcen gleichzeitig Koordinierte Reservierung und garantierte parallele Ausführung Dienstgütegarantien mittels elektronischer Verträge = SLA Testanordnung 4 Systeme mit eigenem Management, 160 Rechenressourcen mit lokalem Scheduler Rechenressourcen mit zufälliger Lastverteilung Exklusive Ressourcennutzung Parallele Anwendung benötigt 6 Rechenressourcen Ablauf früheste mögliche Startzeit pro Ressource Scheduling (mögl. weitere Iteration) Überprüfung der Reservierung (mögl. weitere Iteration) Start der Anwendung Meta-Scheduler Scheduler Rechenres. Dienstgütegarantien

4 Meta-Scheduler kontrollieren jeweils ¼ der Rechenressourcen Testergebnisse 1 Meta-Scheduler kontrolliert alle Rechenressourcen Vergleich bei Allokation auf einem einzelnen System: ca. 15 sec Verhandlungs-/SLA-Overhead ist vertretbar für realen Einsatz Durchschnittliche Zeit bis eine Ko-Allokation erfolgt ist: ca. 20 sec 4 Meta-Scheduler kontrollieren jeweils ¼ der Rechenressourcen

Infrastructure Provider Customer Service Provider Business Assessment Business Use Service Demand SLA Contracting/ Sales SLA (Re-)Negotiation SLA Orchestration/ Transformation/ Aggregation Monitoring, Arbitration Procurement Business Assessment SOA Service Demand Forecasting Monitoring Adjustment Alerting Infrastructure Provider Software Provider Provisioning virtual Resource Consumption Forecasting Mapping SOI physical Projekt EU FP7: 15 Mio Euro u.a. SAP, Intel, Telefonica, Telekom Austria, TU DO

Service Management Plane SLA Management Plane Design / Prediction Plane Business SAMI Business Business View Layer Prediction Inventory SAMI Inventory Software Service Layer Software management DB VM Service VM Infrastructure Service Layer Design-time modelling Infrastructure SAMI Infrastructure SAMI

Technological Trend - Computational Power Computational power follows Moore‘s Law: double of transistor density every 18 months. Do we need this computational power?

Applications Several relevant problems are still not adequately solved. molecular, atomic simulation (chemistry, physics) pharmaceutics climate research artificial intelligence Grand Challenge Problems

Technological Trend - Networking Network performance doubles every 9 months. Computer Network 1986 to 2000 x500 x340.000 2001 to 2010 x60 x4000 the difference will yield several dimensions in a few years!

Consequence “When the network is as fast as the computer's internal links, the machine disintegrates across the net into a set of special purpose appliances” (George Gilder) Parallel programming Distributed applications Decentral problem solving

The Grid “Resource sharing & coordinated problem solving in dynamic, multi-institutional virtual organizations” (Ian Foster) Source: Globus, Ian Foster

Grid Vision Simple, transparent access to resources without central control dynamic coordination and combination of services on demand easy additionof resources autonomic management of Grid components complexity of the infrastructure is hidden from user or resource provider. Analogy: Power-Grid Transformation to „e-Science“ Support of „Virtual Organizations“

Computational Grids Connection of: High-performance computers, parallel computers Workstations-/PC-Cluster in the future single PC systems The Grid automatically dertermins on request, where, when, which computers are available for a task. Idea orginitates from metacomputing (‘90)

Trend of Online-Data The storage density doubles every 12 months. Example online-data: 2000 ~0.5 Petabyte 2005 ~10 Petabytes 2010 ~100 Petabytes Not only computational performance but also data management is a key challenge in the future!

Data-intensive Applications Medical Data Digital X-Rays Brains-Scans Petabytes of Data

Data-intensive Applications Medical Data Digital X-Rays Brains-Scans Petabytes of Data Molecular Data Genom Proteine Drug analysis Environmental Data Weather-/Climate Geophysics Astronomy Physics High-Energy Physics typical: time-variant, 3D models require large volumes of data (simulated, recorded)

Example: CERN’s Large Hadron Collider 1800 Researchers, 150 Institutes in 32 Countries work on 100 PetaByte of data with several 10.000s of processors!

Example CERN-LHC Data-Grid ~PBytes/sec Online System ~100 MBytes/sec Offline Processor Farm ~20 TIPS ~100 MBytes/sec HPSS Tier 0 CERN Computer Centre ~622 Mbits/sec Tier 1 France Regional Centre HPSS Germany Regional Centre HPSS Italy Regional Centre HPSS FermiLab ~4 TIPS HPSS ~622 Mbits/sec Tier 2 Caltech ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS ~622 Mbits/sec Institute ~0.25TIPS Institute Institute Institute Physics data cache ~1 MBytes/sec Pentium II 300 MHz Pentium II 300 MHz Pentium II 300 MHz Tier 4 Pentium II 300 MHz Physicist workstations Source: Ian Foster, DataGrid, CERN

Grid-“Resources“ Computer und data management ultimately require also network management Considerations of network connections Reservation of network properties Quality-of-service features e.g.: GMPLS/MPLS other resources: Visualization (3D-Cave, Video-Conferencing), Experimental devices and instruments Software (Licences) Services etc.

Grid-Initiatives Several Grid projects in research and academics Globus Toolkit Open-Source solution defacto standard for several protocols and services Open Grid Forum Forum similar to IETF, W3C Definition and standardisation of Grid protocols and services Commercial support IBM, Microsoft, Sun, Compaq, … Platform, Avaki, Datasynapse, ... Combination of technological interests from eScience and eBusiness

Architecture of a Grid Situation Requirement of standardisation: different types of components, different rules, policies, provider Requirement of standardisation: description of and access to resources independent, distributed, and scalable services shared protocols

Grid Functions (1) Security Authentication Privacy Information Services Information about existing resources or services Lookup and discovery of functionalities Resource Management Integration of resources

Grid Functions (2) Data Management Data transferring Data localisation Replication Synchronisation Scheduling automatic selection of resources coordination of resource allocation Accounting Billing

Future Grid Applications Use of Grid-APIs for portable access to Grid functionalities Example: dynamic resource discovery data transfers requesting network services higher abstraction level in software development

Multi-level Infrastructure Application Internet Transport Application Link Internet Protocol Architecture Collective “Coordination of several resources”: infrastructure services, application services Resource “Add resource”: Negotiate access, control access and utilization Connectivity “Communication with internal resource functions and services” Fabric “Control local execution” Source: Ian Foster

Open Grid Service Architecture OGSA is currently standardised in OGF. Goal is the simple integration of new services into the Grid. service-oriented approach Communication via WebServices, SOAP Similarity with eBusiness solutions Similar protocols Application Server

Globus Toolkit™ Open-Source software package with basic services usually the reference implementation of services that are standardized by the Global Grid Forum. Primarily, just a „bag of services“ to implement Grid projects Security Information Services Resource management Data transferring no directly usable/installable „product“

Example of a Grid Job Required Resources: needs 48 processing nodes of a specified architecture/properties for 6 hours a nearby visualization device is requested during execution Allocation Time Requirements: should be executed between 8am and 6pm the following day Data Requirements: needs a specified data set Storage Requirements: needs 1 GB of storage during execution Software Requirements: utilizies a specified licensed software package Network Requirements: a network connection with a given bandwidth between the VR device and the application is needed Cost Requirements: The user is willing to pay at most 4 Euro Objectives: He prefers cheaper job execution over an earlier execution.

Automatic Allocation and Reservation Goal: Automatic planning of the resource allocation time Network 1 Prefetching Input-Data Storing Output-Data Computer 1 Computation Reservation Computer 2 Computation Network 2 Communication Visualization Cave Visualization Software License Software Usage Storage Storage

Future Grid Scenario WAN Transfer Visualization Remote Center Reads and Generates TB of Data LAN/WAN Transfer In the near future the Grid offers users online access to Petabyte of data storage, Teraflops of computational power, on-demand access to QoS-network connections on-demand software, automatic access to arbitrary services. Difference to „Internet“, anticipated potential !

eBusiness Applications Internet Business services B2C: eCommerce-Solutions Portals Internet Business services B2B: Inter-operation between companies Supply-Chain Management Intranet Solutions Enterprise Application Integration EAI

Trend in eBusiness Solutions Previously: use of the internet as add-on technology to existing business models often stand-alone solutions for specific prupose Current and future: integration of different services (in-house, between companies) to improve efficiency orientation of internal and external business processes and workflows leveraging new business models

Technological Challenges Similar to Grid standards Standardization of services and protocols similar technologies XML-Processing Web-Services, SOAP Enterprise Java Beans Requirements security reliability performance scalability interoperability

Pervasive/Ubiquitous Computing Mobile Solutions Easy and transparent integration of different mobile components Requirements security reliability performance scalability interoperability Same Requirements; similar solutions but often additional constraints: devices may be subject tighter limitations in size, cost, performance

Kursinhalt Grundlagenzu aktuellen Web Technologien Peer2Peer XML JSP, JavaBeans EJB Web-Services Peer2Peer Grid Computing Cloud Computing

Danke für die Aufmerksamkeit!

Presentations includes figures, trademarks, logos which are properties of third parties.. Rights are reserved to the corresponding rights owners.