Cloud-Computing - Grundlagen

Transkript

1 Cloud-Computing - Grundlagen alois.schuette@h-da.de Alois Schütte 24. November / 119

2 Inhaltsverzeichnis 1 Definitionen und Begriffe Begriffe Definition Cloud Computing 2 Cloud Stack Vor- und Nachteile der Servicemodelle Risiken des Cloud-Computing 3 Virtualisierung Host mit Hypervisor Host mit Containern Cloud Bestandteile Fallbeispiel KVM Fallbeispiel LXC 4 Web Services Definition Webservice SOA Web Service Architektur, Beispiel REST JSON-RPC 5 Bezahlmodelle 2 / 119

3 Definitionen und Begriffe Begriffe Provisioning Mit Provisioning wird der Prozess beschrieben, um Nutzer eines IT-Systems mit allem nötigen auszustatten, um eine Tätigkeit durchzuführen. Vorbereiten und Bereitstellen von Maschinen, Ressourcen oder Dienstleistungen Nach der Bereitstellung mit sehr wenig Aufwand konfiguriert Also gleich verwendbar Beispiel: Durch mieten einer virtuellen Maschineninstanz bei Amazon werden dort automatisch Speicher (Plattenplatz, RAM), Netzwerkeinstellungen (IP-Adresse, Subnetz, etc.) und das eigentliche Betriebssystem vorkonfiguriert und nach Abschluss dieses Vorgangs mit Login-Daten versehen. Nun kann der Nutzer sich anmelden und die Maschine verwenden. 3 / 119

4 Definitionen und Begriffe Begriffe SysOpping Der Betrieb der bereitgestellten Ressourcen. Hierunter zählen alle administrativen Aufgaben, die nachträglich an der Ressource durchgeführt werden. Das anlegen weiterer Benutzer oder das Starten weiterer Dienste sind Beispiele dafür. Fehlerbehebungen fallen auch in diese Kategorie. Es findet hier teilweise auch eine Trennung der administrativen Verantwortlichkeiten statt. So kann ein Benutzer einer virtuellen Maschine viele Dinge mit Administratorrechten selbst erledigen. Ausserhalb der Maschine kann der Diensteanbieter die Maschine überwachen (Ressourcenverbrauch zur Abrechnung) sowie starten und stoppen, aber meist selbst keine direkte Kontrolle auf die in der Maschine laufenden Prozesse durchführen. 4 / 119

5 Definitionen und Begriffe Begriffe De-Provisioning Die korrekte Entsorgung von Ressourcen (Sperrung von Zugängen, freigeben von belegten Ressourcen wie z.b. Plattenplatz) wird als De-Provisioning bezeichnet. Sie kann als Umkehroperation zum Provisioning betrachtet werden, ähnlich wie das Abmelden eines Telefonanschlusses aufgrund von Umzug. Dieser Prozess sollte, ebenso wie beim Provisioning auch, möglichst automatisiert ablaufen. Besonders wichtig dabei ist, dass Daten aus einer früheren Instanz in von einer anderen (neuen) Instanz nicht mehr wiederherstellbar sind, selbst wenn sich diese im gleichen Speicherbereich wie die frühere Instanz befindet. Das De-Provisioning ermöglicht es der Cloud, neue Ressourcen für andere Aufgaben bereitzustellen, bzw. zu schrumpfen. 5 / 119

6 Definitionen und Begriffe Begriffe Prozess der Bereitstellung von Ressourcen in der Cloud 6 / 119

7 Definitionen und Begriffe Definition Cloud Computing Definition Cloud Computing Die allgemein anerkannte Definition von Cloud-Computing kommt vom NIST 1 (vgl. [1]): Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models. 1 National Institute of Standards and Technology 7 / 119

8 Definitionen und Begriffe Definition Cloud Computing Fünf Eigenschaften des Cloud-Modells 1 On-demand self-service Die Provisionierung von Rechnerressourcen für einen Kunden läuft automatisch ab. Eine menschliche Interaktion durch den Service Provider ist nicht notwendig. 2 Broad network access Die Dienste sind über das Netz verfügbar und der Zugriff darauf erfolgt über Standard-Mechanismen, die den Zugriff durch heterogene Thin bzw. Thick Clients (z.b. Mobiltelefon, Tablet, Laptop oder Workstation) erlauben. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 8 / 119

9 Definitionen und Begriffe Definition Cloud Computing Fünf Eigenschaften des Cloud-Modells 1 On-demand self-service Die Provisionierung von Rechnerressourcen für einen Kunden läuft automatisch ab. Eine menschliche Interaktion durch den Service Provider ist nicht notwendig. 2 Broad network access Die Dienste sind über das Netz verfügbar und der Zugriff darauf erfolgt über Standard-Mechanismen, die den Zugriff durch heterogene Thin bzw. Thick Clients (z.b. Mobiltelefon, Tablet, Laptop oder Workstation) erlauben. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 8 / 119

10 Definitionen und Begriffe Definition Cloud Computing Fünf Eigenschaften des Cloud-Modells 3 Resourcepooling Die Ressourcen des Dienstanbieters sind in einem Pool zusammengefasst, so dass sie einer Vielzahl von Kunden zur Verfügung stehen (Multi-Tenant Modell). Die verschiedenen physischen und virtuellen Ressourcen werden dabei dynamisch zugeordnet und wieder freigegeben, in Abhängigkeit von der Beanspruchung durch den Kunden. Generell hat der Kunde keine Kontrolle und kein Wissen über den exakten Aufenthaltsort der bereitgestellten Ressourcen. Eventuell kann jedoch auf einem höheren Abstraktionsniveau festgelegt werden, wo sich die Ressourcen befinden (z.b. das jeweilige Land oder das Datenzentrum). Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 9 / 119

11 Definitionen und Begriffe Definition Cloud Computing Fünf Eigenschaften des Cloud-Modells 4 Rapid elasticity Ressourcen können elastisch zugeteilt und wieder freigegeben werden. In manchen Fällen kann dies komplett automatisch ablaufen, so dass dem Kunden die Ressourcen daher oftmals als unbegrenzt vorkommen. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 10 / 119

12 Definitionen und Begriffe Definition Cloud Computing Fünf Eigenschaften des Cloud-Modells 5 Measured service Die Nutzung der Ressourcen innerhalb des Cloudsystems kann automatisch überwacht und gemessen und anschließend, in Abhängigkeit des bereitgestellten Dienstes (z.b. Speicherplatz, Rechenleistung), dem Kunden berechnet werden. Typischerweise geschieht dies auf einer pay-per-use Basis. Der Kunde bezahlt also nur für die Ressourcen, die er auch tatsächlich genutzt hat. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 11 / 119

13 Definitionen und Begriffe Definition Cloud Computing Drei Servicemodelle 1 Software as a Service (SaaS) Der Service Provider stellt dem Kunden die Nutzung seiner Applikationen sowie die hierzu notwendigen Ressourcen der verwendeten Cloud-Infrastruktur als Dienst bereit. Der Kunde hat dabei keine Kontrolle über die Applikationen sowie die darunterliegende Infrastruktur. Kundenspezifische Konfigurationen an den Applikationen sind möglich. Der Service Provider muss hier nicht zwingend die Kontrolle über die Cloud-Infrastruktur besitzen. Er kann sie bei einem Cloud-Provider eingekauft haben und ist somit wiederum selbst Cloud-Kunde. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 12 / 119

14 Definitionen und Begriffe Definition Cloud Computing Drei Servicemodelle 2 Platform as a Service (PaaS) Der Service Provider stellt dem Kunden auf der Cloud-Infrastruktur eine Umgebung zur Entwicklung und Ausführung eigener Applikationen bereit. Das ermöglicht dem Kunden die Kosten für den Ankauf und die Verwaltung der benötigten Hard- und Software-Komponenten zu reduzieren. Da der Provider die Entwicklungsumgebung bestimmt, müssen die Applikationen des Kunden kompatibel zu den vom Provider unterstützten Programmiersprachen, Libraries etc. sein. Der Kunde hat hierbei nur die Kontrolle über seine Applikationen, jedoch nicht über die darunterliegende Infrastruktur der Cloud. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 13 / 119

15 Definitionen und Begriffe Definition Cloud Computing Drei Servicemodelle 3 Infrastructure as a Service (IaaS) Der Service Provider stellt dem Kunden IT-Ressourcen, wie Rechenleistung, Speicherplatz und Netzwerk-Equipment zur Verfgung, was diesem wiederum die Anschaffung und Verwaltung eigener Hardware erspart. Im Gegensatz zu PaaS hat der Kunde hier deutlich mehr Freiheiten um diese vom Provider bereitgestellte, virtualisierte Infrastruktur zu nutzen. So kann er sein eigenes Betriebssystem wählen und darin anschließend beliebige Software ausführen. Auch hier hat der Kunde jedoch keinen direkten Zugriff auf die darunterliegende Infrastruktur der Cloud selbst. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 14 / 119

16 Definitionen und Begriffe Definition Cloud Computing Vier Einsatzmodelle 1 Private Cloud Eine private Cloud ist nur innerhalb eines bestimmten Netzes (z.b. Firmen- oder Heimnetz) erreichbar, nicht über öffentlich zugängliche IP-Adressen (Internet). Broad Network Access Rapid Measured Elasticity Service Resource Pooling On-Demand Self-Service Essential Characteristics Diese Clouds erfüllen meist einen bestimmten Zweck, der für die Öffentlichkeit nicht relevant ist oder er ist so speziell, dass es sich aufgrund der geringen Nutzerzahlen nicht lohnt, diesen weltweit anzubieten. Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Model Model 15 / 119

17 Definitionen und Begriffe Definition Cloud Computing Vier Einsatzmodelle 2 Public Cloud Eine öffentliche Cloud ist prinzipiell über das Internet für alle erreichbar. Es müssen meistens vorher bestimmte Vereinbarungen bzgl. Dienstqualität, Kosten, etc. ausgehandelt werden. Erst danach wird der Zugriff auf die Dienste oder Ressourcen, welche diese Cloud anbietet, freigeschaltet. Ein populäres Beispiel dazu ist Amazons Cloud-Speicherdienst S3 (Simple Storage Service). Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 16 / 119

18 Definitionen und Begriffe Definition Cloud Computing Vier Einsatzmodelle 3 Hybride Cloud Eine hybride Cloud vereint die Eigenschaften einer privaten und öffentlichen Cloud. Die Cloud nutzt sowohl interne Dienste, kann aber bei Bedarf auch von extern erreichbar sein bzw. externe Dienste nutzen (z.b. Speicherplatz bei Amazon). Der Vorteil liegt in der Skalierbarkeit, da man bei Bedarf zusätzliche Ressourcen aus dem Internet dazuschalten kann. Durch die genaue Trennung von Diensten zwischen intern und extern, lassen sich trotzdem Datenschutzanforderungen umsetzen. Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 17 / 119

19 Definitionen und Begriffe Definition Cloud Computing Vier Einsatzmodelle 4 Community Cloud Sie wird für die exklusive Nutzung durch eine Gemeinschaft, wie zum Beispiel ein Zusammenschluss zweier oder mehrerer Organisationen, bereitgestellt. Das Cloudsystem selbst kann sich im Besitz einer oder mehrerer der beteiligten Organisationen oder auch einer dritten Partei befinden, der bzw. denen dann die Verwaltung des Systems obliegt. Kennen Sie Beispiele? Broad Rapid Measured On-Demand Network Access Elasticity Service Self-Service Resource Pooling Software as a Platform as a Infrastructure as a Service (SaaS) Service (PaaS) Service (SaaS) Public Private Hybrid Community Deployment Service Essential Model Model Characteristics 18 / 119

20 Definitionen und Begriffe Definition Cloud Computing Zusammenfassung der NIST Definition Broad Network Access Rapid Elasticity Resource Pooling Measured Service On-Demand Self-Service Essential Characteristics Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (SaaS) Service Model Public Private Hybrid Community Deployment Model 19 / 119

21 Cloud Stack Cloud Stack Wir betrachten Vor- und Nachteile der Elemente des Cloud-Stacks und Risiken des Cloud-Computing. Service-Modell Zielgruppe Beispiel Software as a Service (SaaS) Endbenutzer Salesforce.com Platform as a Service (PaaS) Entwickler Google App Engine Infrastructure as a Service (IaaS) Administratoren Amazon EC2 Kennen Sie weitere Beispiele? 20 / 119

22 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von IaaS aus Sicht des Anbieters Pro Durch Elastizität werden mehr Ressourcen genutzt, die alle auch separat abgerechnet werden. plattformunabhängig Es lassen sich mehr Ressourcen anbieten: (Haupt-)Speicher, CPU, Netzwerk, etc. Automatische Skalierung, wenig bis keine manuellen Eingriffe nötig Contra Komplexe Kundenwünsche können nicht immer umgesetzt werden Infrastruktur darf nicht zu komplex werden, um Sicherheitsrisiken zu vermeiden 21 / 119

23 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von IaaS aus Sicht des Anbieters Pro Durch Elastizität werden mehr Ressourcen genutzt, die alle auch separat abgerechnet werden. plattformunabhängig Es lassen sich mehr Ressourcen anbieten: (Haupt-)Speicher, CPU, Netzwerk, etc. Automatische Skalierung, wenig bis keine manuellen Eingriffe nötig Contra Komplexe Kundenwünsche können nicht immer umgesetzt werden Infrastruktur darf nicht zu komplex werden, um Sicherheitsrisiken zu vermeiden 21 / 119

24 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von IaaS aus Sicht des Nutzers Pro plattformunabhängig Mehrere Ressourcen des Anbieters stehen zur Auswahl, direkt nutzbar Es müssen keine eigenen Ressourcen angeschafft werden Die Ressourcen sind aufeinander abgestimmt und funktionieren zusammen Contra Mehr Ressourcen müssen verwaltet werden. Effizienz der gemieteten Ressourcen abhängig vom Angebot des Anbieters Eventuell langfristig grössere Kosten als eine Lösung im eigenen Haus Durch die Zentralisierung entstehen ganz neue Sicherheitsbedenken/-modelle 22 / 119

25 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von IaaS aus Sicht des Nutzers Pro plattformunabhängig Mehrere Ressourcen des Anbieters stehen zur Auswahl, direkt nutzbar Es müssen keine eigenen Ressourcen angeschafft werden Die Ressourcen sind aufeinander abgestimmt und funktionieren zusammen Contra Mehr Ressourcen müssen verwaltet werden. Effizienz der gemieteten Ressourcen abhängig vom Angebot des Anbieters Eventuell langfristig grössere Kosten als eine Lösung im eigenen Haus Durch die Zentralisierung entstehen ganz neue Sicherheitsbedenken/-modelle 22 / 119

26 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von PaaS aus Sicht des Anbieters Pro Längerfristige Entwicklungszeit und Hosting der späteren Anwendung bindet Kunden langfristig, daher höhere Einnahmen zu erwarten Nutzer ist für die Funktionalität der Software zuständig, Anbieter nur für die Dienstbereitstellung Contra Anbieter muss sich sowohl um die Hardware als auch die Entwicklungswerkzeuge kümmern und diese ggfs. aufeinander abstimmen Erweiterung schwierig, viele Testfälle zu berücksichtigen, da viele verschiedene Kunden Höhere Traffickosten durch Hosting und Entwicklung 23 / 119

27 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von PaaS aus Sicht des Anbieters Pro Längerfristige Entwicklungszeit und Hosting der späteren Anwendung bindet Kunden langfristig, daher höhere Einnahmen zu erwarten Nutzer ist für die Funktionalität der Software zuständig, Anbieter nur für die Dienstbereitstellung Contra Anbieter muss sich sowohl um die Hardware als auch die Entwicklungswerkzeuge kümmern und diese ggfs. aufeinander abstimmen Erweiterung schwierig, viele Testfälle zu berücksichtigen, da viele verschiedene Kunden Höhere Traffickosten durch Hosting und Entwicklung 23 / 119

28 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von PaaS aus Sicht des Nutzers Pro Einheitliche Systemlandschaft, Werkzeuge vom Anbieter aufeinander abgestimmt keine eigene IT-Infrastruktur zur Entwicklung/zum Hosting der späteren Anwendung notwendig Entwicklung ist nicht standortgebunden, kann weltweit stattfinden Contra Anwender ist an die Entwicklungswerkzeuge des Anbieters gebunden Komplexe Anwendungen lassen sich nicht ohne Aufwand zu einem anderen Anbieter oder zurück ins eigene Haus umziehen 24 / 119

29 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von PaaS aus Sicht des Nutzers Pro Einheitliche Systemlandschaft, Werkzeuge vom Anbieter aufeinander abgestimmt keine eigene IT-Infrastruktur zur Entwicklung/zum Hosting der späteren Anwendung notwendig Entwicklung ist nicht standortgebunden, kann weltweit stattfinden Contra Anwender ist an die Entwicklungswerkzeuge des Anbieters gebunden Komplexe Anwendungen lassen sich nicht ohne Aufwand zu einem anderen Anbieter oder zurück ins eigene Haus umziehen 24 / 119

30 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von SaaS aus Sicht des Anbieters Pro Software bleibt auf den eigenen Servern, keine Raubkopien im Umlauf Präzises Abrechnungsmodell (monatlich) Bessere Übersicht, wieviele Kunden die Software wirklich nutzen Updates müssen nicht beim Anwender installiert werden, testen wird vereinfacht Neue Kunden, die bisher nicht über die nötigen Ressourcen verfügten, die Software selbst einzusetzen, können gewonnen werden (z.b. High-End Graphiksoftware) Contra Betriebskosten für die Serverlandschaft inkl. notwendiger Skalierung bei hoher Auslastung Bei Ausfall ist die Software für alle Kunden gleichzeitig nicht verfügbar 25 / 119

31 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von SaaS aus Sicht des Anbieters Pro Software bleibt auf den eigenen Servern, keine Raubkopien im Umlauf Präzises Abrechnungsmodell (monatlich) Bessere Übersicht, wieviele Kunden die Software wirklich nutzen Updates müssen nicht beim Anwender installiert werden, testen wird vereinfacht Neue Kunden, die bisher nicht über die nötigen Ressourcen verfügten, die Software selbst einzusetzen, können gewonnen werden (z.b. High-End Graphiksoftware) Contra Betriebskosten für die Serverlandschaft inkl. notwendiger Skalierung bei hoher Auslastung Bei Ausfall ist die Software für alle Kunden gleichzeitig nicht verfügbar 25 / 119

32 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von SaaS aus Sicht des Nutzers Pro Geringe Anschaffungs- und Betriebskosten Reduzierung eigener IT, Konzentration aufs Kerngeschäft Grundfunktionen oftmals kostenlos und ausreichend (Freemium-Modell) Contra Datenschutzbedenken (wer kann auf meine Daten zugreifen?) Keine Individualsoftware, oft nur minimale Anpassungsmöglichkeiten (z.b. Firmenlogo, Corporate Design) Integration in andere Anwendungen schwierig, z.t. gar nicht möglich Internetverbindung notwendig, oft keine Offline-Nutzung, Geschwindigkeit nicht immer optimal 26 / 119

33 Cloud Stack Vor- und Nachteile der Servicemodelle Vor- und Nachteile von SaaS aus Sicht des Nutzers Pro Geringe Anschaffungs- und Betriebskosten Reduzierung eigener IT, Konzentration aufs Kerngeschäft Grundfunktionen oftmals kostenlos und ausreichend (Freemium-Modell) Contra Datenschutzbedenken (wer kann auf meine Daten zugreifen?) Keine Individualsoftware, oft nur minimale Anpassungsmöglichkeiten (z.b. Firmenlogo, Corporate Design) Integration in andere Anwendungen schwierig, z.t. gar nicht möglich Internetverbindung notwendig, oft keine Offline-Nutzung, Geschwindigkeit nicht immer optimal 26 / 119

34 Cloud Stack Risiken des Cloud-Computing Risiken des Cloud-Computing 1/4 Vendor Lock-In Nutzt man die Dienste eines Anbieters, ist man auf dessen Infrastruktur, Datenformate, etc. angewiesen. Der Wechsel zu einem anderen Anbieter gestaltet sich dadurch schwieriger (oftmals vom Anbieter gewollt), weil dessen Cloud-Plattform nicht kompatibel zum neuen Anbieter ist. Somit gestaltet sich ein Umzug von einer Cloud in eine andere schwierig, kostenintensiv oder manchmal sogar unmöglich. Man ist so dem Anbieter ausgeliefert und dieser kann z.b. die Preise erhöhen ohne Abwanderung seiner Kunden befürchten zu müssen. Kriterien zur Abmilderung des Risikos: Daten sollten in offenen Formaten gespeichert werden. Datenformate sollten von mehr als einem Hersteller eingesetzt werden. Das Backup von den Daten in der Cloud sollte möglich und problemlos sein Es werden nur sog. Wegwerfdaten in der Cloud gespeichert, die sich schnell wieder erzeugen lassen und die selbst keinen grossen 27 / 119

35 Cloud Stack Risiken des Cloud-Computing Risiken des Cloud-Computing 1/4 Vendor Lock-In Nutzt man die Dienste eines Anbieters, ist man auf dessen Infrastruktur, Datenformate, etc. angewiesen. Der Wechsel zu einem anderen Anbieter gestaltet sich dadurch schwieriger (oftmals vom Anbieter gewollt), weil dessen Cloud-Plattform nicht kompatibel zum neuen Anbieter ist. Somit gestaltet sich ein Umzug von einer Cloud in eine andere schwierig, kostenintensiv oder manchmal sogar unmöglich. Man ist so dem Anbieter ausgeliefert und dieser kann z.b. die Preise erhöhen ohne Abwanderung seiner Kunden befürchten zu müssen. Kriterien zur Abmilderung des Risikos: Daten sollten in offenen Formaten gespeichert werden. Datenformate sollten von mehr als einem Hersteller eingesetzt werden. Das Backup von den Daten in der Cloud sollte möglich und problemlos sein Es werden nur sog. Wegwerfdaten in der Cloud gespeichert, die sich schnell wieder erzeugen lassen und die selbst keinen grossen 27 / 119

36 Cloud Stack Risiken des Cloud-Computing Risiken beim Cloud-Computing 2/4 Reliability Wenn es Probleme beim Anbieter gibt, können die Dienste des Kunden davon betroffen sein und nicht mehr zur Verfügung stehen. Der Kunde kann in dieser Situation nicht mehr tun als auf den Anbieter zu vertrauen, die Dienstleistung schnell wiederherzustellen. Ein Kriterium bei der Auswahl eines Anbieters sollte daher sein, wie schnell dieser im Fehlerfall reagiert und wie gross die vertraglich zugesicherte Downtime im Jahr maximal sein kann (z.b. max. 5 Stunden im Jahr). Doch selbst dies kann manchmal nicht ausreichen, da der Ausfall ausserhalb des Einflussbereiches des Anbieters liegt (z.b. Naturkatastrophen). Kriterien zur Abmilderung des Risikos: Es sollte ein Notfallplan für diese Fälle existieren. Evtl. sollte über eine lokale Lösung (weniger leistungsfähig) für einen solchen Fall nachgedacht werden. Ein Fallback zu einem anderen Anbieter sollte vor einem Ausfall getestet werden. Backups sollten weder in der Cloud noch lokal gespeichert werden. 28 / 119

37 Cloud Stack Risiken des Cloud-Computing Risiken beim Cloud-Computing 2/4 Reliability Wenn es Probleme beim Anbieter gibt, können die Dienste des Kunden davon betroffen sein und nicht mehr zur Verfügung stehen. Der Kunde kann in dieser Situation nicht mehr tun als auf den Anbieter zu vertrauen, die Dienstleistung schnell wiederherzustellen. Ein Kriterium bei der Auswahl eines Anbieters sollte daher sein, wie schnell dieser im Fehlerfall reagiert und wie gross die vertraglich zugesicherte Downtime im Jahr maximal sein kann (z.b. max. 5 Stunden im Jahr). Doch selbst dies kann manchmal nicht ausreichen, da der Ausfall ausserhalb des Einflussbereiches des Anbieters liegt (z.b. Naturkatastrophen). Kriterien zur Abmilderung des Risikos: Es sollte ein Notfallplan für diese Fälle existieren. Evtl. sollte über eine lokale Lösung (weniger leistungsfähig) für einen solchen Fall nachgedacht werden. Ein Fallback zu einem anderen Anbieter sollte vor einem Ausfall getestet werden. Backups sollten weder in der Cloud noch lokal gespeichert werden. 28 / 119

38 Cloud Stack Risiken des Cloud-Computing Risiken beim Cloud-Computing 3/4 Datensicherheit Wenn einmal Daten in der Cloud beim eienm Anbieter gespeichert sind, ist unklar, wer noch auf diese Daten Zugriff hat. Unbemerkt lassen sich Daten wegkopieren bzw. Backups könten in die falschen Hände geraten, ohne dass der Kunde davon weiss. Selbst nach dem Löschen von Daten nach Nutzung der Cloud-Ressourcen bleibt unklar, ob diese nicht doch noch irgendwo gespeichert sind. Transparenz der Sicherungsvorgänge beim Anbieter sind ein erster Schritt, das Vertrauen des Kunden zu gewinnen, es bleibt aber trotzdem ein ungutes Gefühl zurück. Kriterien zur Abmilderung des Risikos: Nur unwichtige Daten, die keine Geschäftsgeheimnisse, Kundendaten, etc. beinhalten, in der Cloud speichern. Temporäre Daten, die beispielsweise bei Berechnungen grösserer Probleme gespeichert und die nur als ganzes einen Sinn ergeben, eignen sich zur Speicherung in der Cloud. Wichtige Daten immer verschlüsseln und nicht die evtl. angebotene Verschlüsselung des Anbieters nutzen. 29 / 119

39 Cloud Stack Risiken des Cloud-Computing Risiken beim Cloud-Computing 3/4 Datensicherheit Wenn einmal Daten in der Cloud beim eienm Anbieter gespeichert sind, ist unklar, wer noch auf diese Daten Zugriff hat. Unbemerkt lassen sich Daten wegkopieren bzw. Backups könten in die falschen Hände geraten, ohne dass der Kunde davon weiss. Selbst nach dem Löschen von Daten nach Nutzung der Cloud-Ressourcen bleibt unklar, ob diese nicht doch noch irgendwo gespeichert sind. Transparenz der Sicherungsvorgänge beim Anbieter sind ein erster Schritt, das Vertrauen des Kunden zu gewinnen, es bleibt aber trotzdem ein ungutes Gefühl zurück. Kriterien zur Abmilderung des Risikos: Nur unwichtige Daten, die keine Geschäftsgeheimnisse, Kundendaten, etc. beinhalten, in der Cloud speichern. Temporäre Daten, die beispielsweise bei Berechnungen grösserer Probleme gespeichert und die nur als ganzes einen Sinn ergeben, eignen sich zur Speicherung in der Cloud. Wichtige Daten immer verschlüsseln und nicht die evtl. angebotene Verschlüsselung des Anbieters nutzen. 29 / 119

40 Cloud Stack Risiken des Cloud-Computing Risiken beim Cloud-Computing 4/4 Bankrott des Cloud-Anbieters Unternehmen können enteignet, von Konkurrenten übernommen oder Pleite gehen. Dann stellt sich die Frage, was mit den Daten passiert, die dort gespeichert hatte. Selbst wenn der neue Anbieter verspricht, die Cloud des bisherigen Anbieters weiter zu betreiben, ändern sich durch die Übernahme evtl. auch die AGB 2. Die Daten könnten auf diese Weise auch in einem Land mit anderer Gesetzgebung was den Datenschutz angeht, abgelegt werden. Ist der Anbieter wirklich bankrott und es findet sich kein Nachfolger, so bleibt einem meist nur recht kurze Zeit, um seine Daten und angebotenen Anwendungen woanders zu betreiben. Kriterien zur Abmilderung des Risikos: Kontakt halten zum Anbieter, um möglichst früh Anzeichen eines solchen Falls mitzukriegen (Börsen-)Nachrichten studieren, Markt beoachten (evtl. gibt es ja einen günstigeren Anbieter) Alternativen bereithalten und als Teil des Notfallplans darauf vorbereitet sein 30 / 119

41 Cloud Stack Risiken des Cloud-Computing Risiken beim Cloud-Computing 4/4 Bankrott des Cloud-Anbieters Unternehmen können enteignet, von Konkurrenten übernommen oder Pleite gehen. Dann stellt sich die Frage, was mit den Daten passiert, die dort gespeichert hatte. Selbst wenn der neue Anbieter verspricht, die Cloud des bisherigen Anbieters weiter zu betreiben, ändern sich durch die Übernahme evtl. auch die AGB 2. Die Daten könnten auf diese Weise auch in einem Land mit anderer Gesetzgebung was den Datenschutz angeht, abgelegt werden. Ist der Anbieter wirklich bankrott und es findet sich kein Nachfolger, so bleibt einem meist nur recht kurze Zeit, um seine Daten und angebotenen Anwendungen woanders zu betreiben. Kriterien zur Abmilderung des Risikos: Kontakt halten zum Anbieter, um möglichst früh Anzeichen eines solchen Falls mitzukriegen (Börsen-)Nachrichten studieren, Markt beoachten (evtl. gibt es ja einen günstigeren Anbieter) Alternativen bereithalten und als Teil des Notfallplans darauf vorbereitet sein 30 / 119

42 Virtualisierung Virtualisierung Um Cloud Computing zu verstehen, ist es notwenig, wichtige Grundlagen der Virtualisierung zu verstehen. Durch Virtualisierung wird die Bereitstellung mehrerer virtualisierter Rechner auf einem Host möglich und dadurch die Skalierung dieser Komponente. So wird es ermöglicht, dass auf einem Host gleichzeitig mehrere (virtuelle) Rechner und Betriebssysteme ausgeführt werden können. 31 / 119

43 Virtualisierung Host mit Hypervisor Schematischer Aufbau eines Hosts mit Hypervisor 1/3 Host: Physischer Server, auf dem der Hypervisor und der VMM installiert ist und auf dem später die VMs ablaufen. VMM: Virtual Machine Manager, ist eine Software, die direkt auf dem Host ausgeführt wird. Sie dient zur Konfiguration, Steuerung und Überwachung der Virtualisierung angefangen beim Hypervisor bis hinauf zu den einzelnen VMs. 32 / 119

44 Virtualisierung Host mit Hypervisor Schematischer Aufbau eines Hosts mit Hypervisor 2/3 Hypervisor: Ist in der Lage, virtuelle Maschinen auszuführen und bestimmte Geräte des Hosts an die VMs weiterzuleiten, ohne dass es einer Device Emulation bedarf. Device Emulation: Emulierung von Geräten wie z.b. Netzwerkkarten, die von den VMs als echte Hardware erkannt und genutzt werden sollen. 33 / 119

45 Virtualisierung Host mit Hypervisor Schematischer Aufbau eines Hosts mit Hypervisor 3/3 Virtual Networking: Bereitstellen von einem virtuellen Netz, meist mit Bridge, die Host- Netzwerkkarte auf interne virtuelle Netzwerkarten verteilt. VM: Virtual Machine, ein virtualisierter Rechner, der auf diesem Host über den Hypervisor lauffähig ist. 34 / 119

46 Virtualisierung Host mit Containern Hosts mit Containern Container stellen eine leichtgewichtige Alternative der Virtualisierungs- Technologie dar. Es ist eine Erweiterung der chroot Methode. Hardware wird nicht emuliert, sondern das Host-Betriebssystem wird mit den VMs geteilt. Man bezeichnet es auch als Container-Virtualisierung im Gegensatz zur Paravirtualisierung. Mit Containern kann ein Server mehrere tausend VMs hosten. Container sind auch als VM innerhalb einer paravirtualisierten VM möglich (z.b. LXC innerhalb EC2 VM) Beispiele: LXC, vserver, OpenVZ. Office User Space OS-Kernel Host-Hardware Container VM 35 / 119

47 Virtualisierung Cloud Bestandteile Schematischer Aufbau der Bestandteile einer Cloud 1/2 Nimmt man nun mehrere dieser Virtualisierungs-Hosts und fügt diesen einen gemeinsamen Speicher (shared-storage) mit Load-Balancer hinzu, wird es möglich, eine skalierbare und ausfallsichere Infrastruktur zu erstellen: eine Cloud. (vgl. [3]) 36 / 119

48 Virtualisierung Cloud Bestandteile Schematischer Aufbau der Bestandteile einer Cloud 2/2 Die VMs können von einem Host auf einen anderen übertragen und ausgeführt werden (VM migration), da diese sich auf dem gemeinsam genutzten Speicher befinden und so für alle Hosts zugreifbar sind. Durch die Anbindung von weiteren Hosts und durch die Erhöhung des shared Storage (mit entsprechender Hochverfügbarkeit und Ausfallsicherung) lassen sich noch weitere VMs bei Bedarf hinzufügen. Der Benutzer braucht nicht unbedingt zu wissen, wo genau in diesem Verbund seine Maschine ausgeführt wird. (vgl. [3]) 37 / 119

49 Virtualisierung Cloud Bestandteile Gesamtbild der Bestandteile einer Cloud 1/4 (vgl. [3]) Die Benutzer greifen über das Internet bzw. Intranet auf ihre VMs zu. Loadbalancer sind dafür verantwortlich, die Last so zu verteilen, dass keine Engpässe bei VMs bzw. Netzwerkanfragen entstehen (z.b. nach Round-Robin Verfahren). Bei Bedarf können weitere (Standby) VMs gestartet werden, um grössere Lastspitzen abzuarbeiten. 38 / 119

50 Virtualisierung Cloud Bestandteile Gesamtbild der Bestandteile einer Cloud 2/4 (vgl. [3]) Durch Caching-Mechanismen wird dieser Prozess unterstützt und die Anfragen können so schneller bearbeitet und wieder zurück an den Benutzer geschickt werden, ohne direkt auf die VMs zugreifen zu müssen. Filter wie z.b. Firewalls oder Traffic Shaper sorgen dafür, dass der Netzwerkverkehr nicht überhand nimmt und bestimmte Anfragen gar nicht erst zu den VMs durchgelassen werden. 39 / 119

51 Virtualisierung Cloud Bestandteile Gesamtbild der Bestandteile einer Cloud 3/4 (vgl. [3]) Das Management über die Virtualisierungs-Hosts, auf denen die VMs laufen, wird durch eine darüberliegende Kontrollinstanz durchgeführt. Aufgaben wie z.b. Monitoring der Gesamtauslastung der Cloud sind dort ebenfalls angesiedelt. Verwaltet wird dies meist aus einem separaten, cloudanbieterinternen Netz (sog. Verwaltungsnetz), auf das die Nutzer der VMs nicht zugreifen dürfen. 40 / 119

52 Virtualisierung Cloud Bestandteile Gesamtbild der Bestandteile einer Cloud 4/4 (vgl. [3]) Durch SLA 3 s zwischen dem Nutzer und dem Anbieter werden bestimmte Rahmenbedingungen festgelegt, z.b. Erreichbarkeit, Dienstgüte, Abrechnungsmodelle, Verfügbarkeit, Reaktions- und Reparaturzeiten, etc. 3 Service Level Agreement 41 / 119

53 Virtualisierung Fallbeispiel KVM Fallbeispiel KVM Hier wird am Beispiel KVM erläutert, wie Virtuelle Maschinen installiert und verwaltet werden können. Weiterhin wird der Zugriff auf die VMen beschrieben. 42 / 119

54 Virtualisierung Fallbeispiel KVM Test der Host-Hardware KVM benötigt eine CPU mit Hardware-Unterstützung für Virtualisierung, z.b. Intel VT AMD-V Ein Test, ob die CPU Hardware-Unterstützung für Virtualisierung ermöglicht ist: :~# egrep '( vmx svm ) ' -- color= always / proc / cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep... vmx est... Ist die Ausgabe des o.a. Kommandos leer, unterstützt die Host-CPU keine Virtualisierung. 43 / 119

55 Virtualisierung Fallbeispiel KVM Admin anlegen Hier wird der Benutzer für die Installation eingerichtet. Zunächst das Homeverzeichnis: :~$ sudo mkdir -p / var / lib / Eine neue Gruppe namens oneadmin mit der Nummer wird angelegt und ein neuer Admin der Gruppe zugefügt. as@one :~$ sudo groupadd -g oneadmin as@one :~$ sudo useradd -u m oneadmin -d / var / lib / one \ -s / bin / bash -g oneadmin as@one :~$ sudo chown -R oneadmin : oneadmin / var / lib / one as@one :~$ sudo passwd oneadmin 44 / 119

56 Virtualisierung Fallbeispiel KVM Admin ssh Zugang einrichten Als oneadmin anmelden und ssh konfigurieren: :~$ su - oneadmin oneadmin@one :~$ ssh - keygen oneadmin@one :~$ cat ~/. ssh / id_rsa. pub > ~/. ssh / authorized_keys Um später bei weiteren Hosts, die der Opennebula-Cloud angehören sollen, nicht separat das hinzufügen des Hosts zu der SSH-Hostliste extra bestätigen zu müssen und dies stattdessen von SSH automatisch übernehmen zu lassen, fügt man die folgenden zwei Zeilen in die Datei /.ssh/config ein: Host * StrictHostKeyChecking no 45 / 119

57 Virtualisierung Fallbeispiel KVM Installation der benötigten Software In diesem Abschnitt wird der KVM-Hypervisor und QEmu installiert und eingerichtet, damit dieser später die virtuellen Maschinen instantiieren und betreiben kann. :~$ sudo apt - get install qemu - kvm libvirt - bin as@one :~$ sudo apt - get install ubuntu -vm - builder as@one :~$ sudo apt - get install bridge - utils ruby Libvirt muss konfiguriert werden, so dass die Benutzer in der Gruppe oneadmin die Rechte besitzen, VMs zu verwalten und VNC-Verbindungen zu ermöglichen. Dazu wird die Datei /etc/libvirt/libvirtd.conf bearbeitet, so dass dort die Zeile unix sock group folgendermassen aussieht: unix_sock_group = " oneadmin " 46 / 119

58 Virtualisierung Fallbeispiel KVM vnc konfigurieren Jetzt werden in der Datei /etc/libvirt/qemu.conf VNC-Verbindungen von überall aus dem Netzwerk zugelassen, indem der Kommentar vor der Zeile vnc listen entfernt wird, so dass in der Datei steht: vnc_listen = " " Im Anschluss wird der libvirt-dienst neu gestartet: as@one :~$ sudo service libvirt - bin restart Bei erfolgreichem Start des libvirt-dienstes legt dieser eine Datei libvirt-sock in /var/run/libvirt/ an. Die Mitglieder der Gruppe oneadmin erhalten mit dem folgenden Befehl Zugriff auf diese Datei: as@one :~$ chown : oneadmin / var / run / libvirt / libvirt - sock 47 / 119

59 Virtualisierung Fallbeispiel KVM Test der Installation Der aktuelle Benutzer wird den Gruppen libvirtd und kvm zugefügt: :~$ sudo adduser `id -un ` libvirtd oneadmin@one :~$ sudo adduser `id -un ` kvm Testen, ob KVM erfolgreich installiert ist mittels virsh: oneadmin@one :~$ virsh -c qemu :/// system list listet VMs Id Name State Gibt es eine Fehlermeldung, war die Installation nicht erfolgreich. 48 / 119

60 Virtualisierung Fallbeispiel KVM Netzwerk-Bridge einrichten Über eine Bridge können die VMen auf die physische Netzwerkkarte des Host zugreifen: :~# vi / etc / network / interfaces auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet manual auto br0 iface br0 inet static address netmask network broadcast gateway dns - search fbi.h- da. de dns - nameservers bridge_ports eth0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off 49 / 119

61 Virtualisierung Fallbeispiel KVM Netzwerk neu starten und kontrollieren :~# / etc / init.d/ networking restart root@one :~# ifconfig br0 Link encap : Ethernet HWaddr 00:23: df :9d :65:04 inet addr : Bcast : Mask : UP BROADCAST RUNNING MULTICAST MTU :1500 Metric :1 eth0 Link encap : Ethernet HWaddr 00:23: df :9d :65:04 UP BROADCAST RUNNING MULTICAST MTU :1500 Metric :1... virbr0 Link encap : Ethernet HWaddr b2 :07: cd :1f: fa: fc inet addr : Bcast : Mask : UP BROADCAST MULTICAST MTU :1500 Metric : / 119

62 Virtualisierung Fallbeispiel KVM Erzeugung einer Debian VM - Vorbereitung Anlegen des Festplattenimages, einer Datei die als Betriebssystem- Festplatte dient. oneadmin@one :/ var / lib / images$ qemu - img create -f raw debian. img 6G Formatting / var / lib / images / debian. img, fmt=raw size = Nun wird ein neues Verzeichnis angelegt, das die ISO-Images für die zu installierenden Betriebssysteme beinhaltet: as@onehost :~$ mkdir -p / var / lib / iso as@onehost :~$ chown -R oneadmin : oneadmin / var / lib / iso Jetzt wird ein ISO-Imgage von Debian für die Netzinstallation heruntergeladen: oneadmin@one :/ var / lib / iso$ wget \ http :// cdimage. debian. org / debian -cd /6.0.5/ i386 /iso -\ cd/debian i386 - netinst. iso 51 / 119

63 Virtualisierung Fallbeispiel KVM Erzeugung einer Debian VM - BS-Installation Nun wird eine deployment-datei (debian deployment) erstellt: debian deployment 1 oneadmin@one :/ var / lib / one$ vi debian_deployment 3 <domain type='kvm ' 4 xmlns : qemu = 'http :// libvirt. org / schemas / domain / qemu /1.0 '> 5 <name > Debian -VM </ name > 6 <memory > </ memory > 7 <os > 8 <type arch=' i686 '>hvm </ type > 9 <boot dev = 'hd '/> 10 <boot dev=' cdrom '/> 11 </os > 12 <on_reboot >restart </ on_reboot > 13 <on_crash >restart </ on_crash > 15 <devices > 16 <emulator >/ usr / bin /kvm </ emulator > 17 <disk type=' file ' device = ' disk '> 18 <source file='/ var / lib / images / debian. img '/> 19 <target dev='hda '/> 20 <driver name=' qemu ' type='raw ' cache= ' default '/> 21 </disk > 52 / 119

64 Virtualisierung Fallbeispiel KVM Erzeugung einer Debian VM - BS-Installation 1 <disk type=' file ' device = ' cdrom '> 2 <driver name=' qemu ' type='raw '/> 3 <target dev='hdc ' bus='ide '/> 4 <readonly /> 5 <source file='/ var / lib / iso / debian i386 - netinst. iso '/> 6 <address type=' drive ' controller = '0' bus='1' unit='0'/> 7 </disk > 9 <controller type='ide ' index= '0'> 10 <address type='pci ' domain = '0x0000 ' bus='0x00 ' 11 slot='0x01 ' function = '0x1 '/> 12 </ controller > 13 <interface type=' network '> 14 <source network = ' default '/> 15 </ interface > 16 <graphics type='vnc ' port=' 5960 ' keymap = 'de '/> 17 </ devices > 19 <features > 20 <acpi /> 21 </ features > 22 </ domain > 53 / 119

65 Virtualisierung Fallbeispiel KVM Erzeugung einer Debian VM - BS-Installation Es wird jetzt das Grundgerüst der virtuellen Maschine erstellt, das zuvor in der Datei debian deployment definiert wurde. oneadmin@onet :/ var / lib / one$ virsh create debian_deployment Domain Debian - VM created from / var / lib / one / debian_deployment Erscheint die Fehlermeldung Error starting domain: internal error Network default is not active., so ist das Default-Netz nicht gestartet, dann starten durch: sudo virsh net - start default sudo virsh net - autostart default 54 / 119

66 Virtualisierung Fallbeispiel KVM Erzeugung einer Debian VM - BS-Installation Nun verbindet man sich mit einem VNC Client (xvnc4viewer1 für Debian) auf den VNC-Port, der in der Deployment-Datei im Abschnitt < graphics > definiert wurde (5960). oneadmin@onet :/ var / lib / one$ xvnc4viewer :5960 Ist man per VNC verbunden, sollte das Installations-Setup der ISO-Datei erscheinen, mit dem man die Installation des Betriebssystems nun durchführen kann (die Datei /var/lib/images/debian.img dient dabei als Festplatte). Dabei empfiehlt es sich, den OpenSSH-Server als Paket gleich mitzuinstallieren, wenn man dazu aufgefordert wird. 55 / 119

67 Virtualisierung Fallbeispiel KVM Erzeugung einer Debian VM - BS-Installation Nun kann man die Installation durchführen: 56 / 119

68 Virtualisierung Fallbeispiel KVM Verwalten der VMen - virt-manager Es existieren graphische Front-Ends zum Verwalten von VMen, z.b. der virt-manager: 57 / 119

69 Virtualisierung Fallbeispiel KVM Verwalten der VMen - virsh Zum Verwalten der VMen benutzen wird das Kommandozeilen-Werkzeug virsh, es ist sehr viel mächtiger als der virt-manager. Das virsh-tool setzt an der libvirt-management-api an. Die man-pages zeigen die umfangreichen Optionen oder aber die help-anweisung innerhalb des Tools. oneadmin@one :~$ virsh Welcome to virsh, the virtualization interactive terminal. Type : ' help ' for help with commands ' quit ' to quit virsh # 58 / 119

70 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Anhalten eines Gasts 1 oneadmin@one :~$ virsh list 2 Id Name State Debian - VM running 6 oneadmin@one :~$ virsh suspend 13 7 Domain 13 suspended 9 oneadmin@one :~$ virsh list 10 Id Name State Debian - VM paused 14 oneadmin@one :~$ Im suspended Status verbraucht die VM System RAM, aber keine CPUoder Netz-Ressourcen. 59 / 119

71 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Fortsetzen eines Gastes 1 oneadmin@one :~$ virsh list 2 Id Name State Debian - VM paused 6 oneadmin@one :~$ virsh resume 13 7 Domain 13 resumed 9 oneadmin@one :~$ virsh list 10 Id Name State Debian - VM running 14 oneadmin@one :~$ 60 / 119

72 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Speichern eines Gasts 1 oneadmin@one :~$ virsh list 2 Id Name State Debian - VM running 6 oneadmin@one :~$ virsh save 13 debian. save 7 Domain 13 saved to debian. save 9 oneadmin@one :~$ virsh list 10 Id Name State oneadmin@one :~$ ls -l d* 14 -rw root root Aug 29 14:21 debian. save Der Gast wird gestoppt und der Zustand in der Datei gesichert. Wiederherstellen kann man den Gast mittels restore 61 / 119

73 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Wiederherstellen eines Gasts 1 oneadmin@one :~$ virsh list 2 Id Name State oneadmin@one :~$ virsh restore debian. save 6 Domain restored from debian. save 8 oneadmin@one :~$ virsh list 9 Id Name State Debian - VM running 13 oneadmin@one :~$ Dies startet die gespeicherte virtuelle Maschine. Der Name der virtuellen Maschine, sowie deren UUID bleiben erhalten, werden aber einer neuen ID zugewiesen. 62 / 119

74 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Neustarten eines Gasts 1 oneadmin@one :~$ virsh list 2 Id Name State Debian - VM running 6 oneadmin@one :~$ virsh reboot 14 7 Domain 14 is being rebooted 9 oneadmin@one :~$ virsh list 10 Id Name State Debian - VM running 14 oneadmin@one :~$ 63 / 119

75 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Abrufen der Domain-Bezeichner eines Gasts 1 oneadmin@one :~$ virsh list 2 Id Name State Debian - VM running 6 oneadmin@one :~$ virsh domid Debian - VM oneadmin@one :~$ virsh domname Debian - VM 12 oneadmin@one :~$ virsh domuuid fe3d2a6 - bf56-06b4-84c8-04 f60e oneadmin@one :~$ 64 / 119

76 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Anzeigen von Gastinformationen 1 oneadmin@one :~$ virsh dominfo 14 2 Id: 14 3 Name : Debian - VM 4 UUID : 9fe3d2a6 - bf56-06b4-84c8-04 f60e OS Type : hvm 6 State : running 7 CPU (s): 1 8 CPU time : 359,9s 9 Max memory : kb 10 Used memory : kb 11 Persistent : no 12 Autostart : disable 13 Managed save : no 14 Security model : apparmor 15 Security DOI : 0 16 Security label : libvirt -9 fe3d2a6 - bf56-06b4-84c8-04 f60e oneadmin@one :~$ 65 / 119

77 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Anzeigen von Host-Informationen 1 oneadmin@one :~$ virsh nodeinfo 2 CPU model : x86_64 3 CPU (s): 2 4 CPU frequency : 1596 MHz 5 CPU socket (s): 1 6 Core (s) per socket : 2 7 Thread (s) per core : 1 8 NUMA cell (s): 1 9 Memory size : kb 11 oneadmin@one :~$ 66 / 119

78 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Status eines Gasts 1 Id Name State Debian - VM running 4 oneadmin@one :~$ running bezieht sich auf Gäste, die derzeit auf einer CPU aktiv sind. blocked bedeutet blockiert (auf eine I/O warten). paused bezieht sich auf Gäste, die angehalten wurden (virsh suspend). Wenn ein Gast angehalten ist, verbraucht er weiterhin Arbeitsspeicher und andere Ressourcen, nimmt jedoch nicht am Scheduling teil und erhält keine CPU-Ressourcen vom Hypervisor. shutdown ist für Gäste, die gerade dabei sind herunterzufahren. Dem Gast wurde das Signal zum Herunterfahren gesendet. crashed Gäste schlugen bei der Ausführung fehl und laufen nicht mehr. Dieser Status kann nur auftreten, wenn der Gast konfiguriert wurde, nach einem Absturz nicht neu zu starten. 67 / 119

79 Virtualisierung Fallbeispiel KVM Verwalten der VMen - Starten mittels qemu Wenn nur eine Image-Datei vorhanden ist, kann man qemu-werkzeuge verwenden, um einen Gast zu starten. Eine Image-Datei erkennt man mittels des file Kommandos. 1 as@one :/ var / lib / images$ file debian. img grep 'x86 boot ' 2 debian. img : x86 boot sector ; partition 1:... 4 as@one : images$ sudo qemu - system - i386 debian. img 68 / 119

80 Virtualisierung Fallbeispiel LXC Fallbeispiel LXC Hier wird am Beispiel LXC erläutert, wie Container installiert und verwaltet werden können. LinuX Container bieten die Möglichkeit, Prozesse und Prozessgruppen zu isolieren, indem Kernel-Ressourcen virtualisiert und gegeneinander abgeschottet werden. Das wird mit Hilfe der im Kernel enthaltenen Cgroups realisiert. Mit LXC kann man entweder einzelne Anwendungen oder ganze Linux-Distributionen in einem Container starten. Es existieren zwei Werkzeugsammlungen zum Verwalten von Linux-Containern: 1 Der LXC-Treiber für libvirt, den man z.b. über virsh bedient. libvirt ist eher ausgelegt, unterschiedliche Virtualisierungslösungen zu verwalten. 2 Projekt LXC. Beschränkt sich nur auf Linux-Container, bietet für diese aber eine größere und flexiblere Werkzeugsammlung. Dies soll hier kurz beschrieben werden. 69 / 119

81 Virtualisierung Fallbeispiel LXC Installation Der Kernel von Ubuntu enthält ab Version (Ubuntu 9.10) alle Voraussetzungen zum Betreiben von LXC. Es müssen nur noch die Programme zur Verwaltung von Containern installiert werden: 1 $ sudo apt - get install lxc 2 $ sudo apt - get install debootstrap Ubuntu oder Debian System erzeugen 3 $ sudo apt - get install bridge - utils Nutzung von Ethernet Bridge Zunächst sollte das cgroup-dateisystem eingehängt werden. 1 $ sudo mount cgroup -t cgroup / sys / fs/ cgroup 2 $ sudo echo ' cgroup / sys / fs/ cgroup cgroup defaults 0 0 ' >> / etc / fstab Test der Installation: 1 $ sudo lxc - execute -n CN1 / bin / bash Container erzeugen 2 $ ps -e ps im Container 3 $ PID TTY TIME CMD 4 1 pts /6 00:00:00 lxc - init PID 1 im Container 5 2 pts /6 00:00:00 bash 6 86 pts /6 00:00:00 ps 7 $ Dadurch startet man die Bash in einem Container namens CN1 und zeigt die Prozesse innerhalb des Containers an. 70 / 119