Migrieren von Anwendungen in die AWS Cloud
Werbung
Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Migrieren von Anwendungen in die AWS Cloud Ein phasenorientierter Ansatz für die Cloud-­‐Migration Jinesh Varia Jan Metzner Oktober 2010 Aktualisiert: Oktober 2014 Seite 1 von 29 Oktober 2014 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Zusammenfassung Mit Amazon Web Services (AWS) können Sie Rechenleistung, Speicher und andere Ressourcen bereitstellen und bei Bedarf auf eine Anzahl elastischer IT-­‐Infrastrukturservices zugreifen. Mit geringen Kosten und minimalem Aufwand können Sie Ihre Anwendung in die AWS Cloud verlagern, um Investitionsaufwand (CapEx) und Kosten für Support und Verwaltung zu minimieren und gleichzeitig die Anforderungen Ihres Unternehmens an Leistung, Sicherheit und Zuverlässigkeit zu erfüllen. Dieses Dokument hilft Ihnen bei der Entwicklung einer Migrationsstrategie für Ihr Unternehmen. Es werden Schritte, Techniken und Methodologien für das Verlagern Ihrer bestehenden Unternehmensanwendungen in die AWS Cloud erörtert. Um optimal von diesem Dokument zu profitieren, sollten Sie über allgemeine Kenntnisse der verschiedenen Services und Funktionen von Amazon Web Services verfügen. Es gibt verschiedene Strategien für das Migrieren von Anwendungen in neue Umgebungen. In diesem Dokument werden mehrere Strategien erläutert, mit deren Hilfe große Unternehmen von der Cloud profitieren können. Außerdem wird die phasenorientierte, schrittweise Strategie für das Migrieren von Anwendungen in die Cloud beschrieben. Immer mehr Unternehmen verlagern Anwendungen in die Cloud, um ihren IT-­‐Komponentenbestand zu modernisieren oder um sich auf zukünftige Anforderungen vorzubereiten. Nachdem die ersten geschäftskritischen Anwendungen in die Cloud verlagert sind, stellen sie bald fest, dass es weitere Anwendungen gibt, die ebenfalls für die Cloud geeignet wären. Zur Veranschaulichung der schrittweisen Strategie werden drei Szenarios in der folgenden Tabelle aufgeführt. In jedem Szenario wird die Motivation für die Migration erläutert, die Anwendungsarchitektur vorher und nachher beschrieben, der Migrationsprozess detailliert dargestellt und die technischen Vorteile der Migration zusammengefasst: Szenarioname Lösung Anwendungsfall Firma A Webanwendung Marketing-­‐ und Collaboration-­‐Website Motivation für Migration Skalierbarkeit u. Elastizität Firma B Batchverarbeitungs-­‐ Pipeline Digital Asset Management-­‐ Lösung Reduzierung der Produkteinführungszeit Firma C Backend-­‐ Bearbeitungsablauf Schadenbearbeitungssystem Geringere TCO, Redundanz Seite 2 von 29 Zusätzliche Vorteile Verwendete Services Auto Scaling, proaktive ereignisbasierte Skalierung Automatisierung und gesteigerte Entwicklungsproduktivität Geschäftskontinuität und Schutz vor Kapazitätsüberschreitung EC2, RDS, S3, CloudFront EC2, S3, SQS, DynamoDB SWF, EC2, S3 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Einführung Entwickler und Architekten, die neue Anwendungen in der Cloud erstellen möchten, können einfach die Komponenten, Prozesse und den Workflow ihrer Lösung planen, die APIs der Cloud ihrer Wahl benutzen und die aktuellen cloudbasierten Best Practices1 für Planung, Entwicklung, Tests und Bereitstellung nutzen. Aufgrund der Entscheidung, ihre Lösungen in einer cloudbasierten Infrastruktur wie Amazon Web Services (AWS) bereitzustellen, können sie unmittelbar von den Vorteilen der sofortigen Skalierbarkeit und Elastizität, der Isolierung von Prozessen, des reduzierten Betriebsaufwands sowie der bedarfsgerechten Bereitstellung und der Automatisierung profitieren. Gleichzeitig suchen viele Unternehmen nach besseren Möglichkeiten, um ihre Bestandsanwendungen in eine cloudbasierte Infrastruktur zu migrieren, damit auch diese von denselben Vorteilen profitieren können, die Neueuntwicklungen genießen. Eines der Hauptunterscheidungsmerkmale der AWS Infrastruktur-­‐Services ist ihre Flexibilität. Diese Flexibilität ermöglicht es den Unternehmen, die Programmiermodelle, Sprachen, Betriebssysteme und Datenbanken zu wählen, die sie bereits verwenden oder mit denen sie vertraut sind. Daher verlagern heute viele Unternehmen Bestandsanwendungen in die Cloud. Es stimmt, dass es bei manchen Anwendungen ("IT-­‐Komponenten"), die aktuell in Unternehmensrechenzentren oder Co-­‐Locations bereitgestellt werden, weder technisch noch unternehmerisch sinnvoll ist, sie in die Cloud zu verlagern – zumindest noch nicht. Diese Komponenten können dort verbleiben. Viele Komponenten in einem Unternehmen können mit minimalem Aufwand schon heute in die Cloud verlagert werden. Dieses Dokument hilft Ihnen bei der Entwicklung einer Migrationsstrategie für die Unternehmensanwendungen Ihres Unternehmens. Der schrittweise, phasenorientierte Ansatz, der in diesem Dokument erläutert wird, hilft Ihnen bei der Auswahl von idealen Projekten für die Migration, der Förderung von Unterstützung im Unternehmen und der zuversichtlichen Migration von Anwendungen. Viele Unternehmen wählen einen stufenweisen Ansatz für die Cloud-­‐Migration. Es ist wichtig, zu beachten, dass bei jeder Migration, ob im Zusammenhang mit der Cloud oder nicht, einmalige Kosten anfallen und sich Widerstand gegen Veränderungen bei den Mitarbeitern formiert (kultureller und soziopolitischer Widerstand). Diese Kosten und Faktoren können im vorliegenden technischen Dokument nicht behandelt werden. Wir empfehlen Ihnen aber, dass Sie diese Aspekte berücksichtigen. Beginnen Sie damit, durch Informationen und Schulungen Unterstützung im Unternehmen zu bekommen. Konzentrieren Sie sich auf die langfristige Kapitalrendite sowie auf materielle und immaterielle Faktoren bei der Migration in die Cloud und beachten Sie die aktuellen Entwicklungen in der Cloud, damit Sie optimal von den Vorteilen der Cloud profitieren können. Es besteht kein Zweifel, dass durch die Bereitstellung Ihrer Anwendungen in der AWS Cloud Ihre Infrastrukturkosten gesenkt und die Agilität Ihres Unternehmens erhöht sowie Ihr Unternehmen von sich nicht um das Aufstellen, Bestücken und Betreiben von Serverschränken kümmern muss. Eine erfolgreiche Migration hängt vor allem von den folgenden drei Punkten ab: von der Komplexität der Anwendungsarchitektur, davon, wie eng oder lose Ihre Anwendung mit anderen Systemen gekoppelt ist und wie viel Aufwand Sie für die Migration betreiben möchten. Wir haben festgestellt, dass Kunden, die den (in diesem Dokument erläuterten) schrittweisen Ansatz befolgen und Zeit und Ressourcen für Machbarkeitsstudien investiert haben, das enorme Potenzial von AWS klar erkennen und in der Lage sind, von seinen Stärken in kürzester Zeit zu profitieren. 1 Architecting for the Cloud: Best Practices Whitepaper (Entwicklung von Architekturen für die Cloud: Whitepaper mit empfohlenen Seite 3 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Eine phasenorientierte Strategie für die Migration: Schritt-­‐für-­‐Schritt-­‐ Anleitung Abbildung 1: Der phasenorientierte Ansatz für die Cloud-­‐Migration Phasen Bewertung der Cloud • • • • • • Vorteile Finanzielle Bewertung (TCO Berechnung) Bewertung von Sicherheit und Compliance Technische Bewertung (Anwendungstypen klassifizieren) Ermittlung der Tools, die wiederverwendet werden können und die erstellt werden müssen Migration von lizensierten Lösungen Erstellen eines Plans und Messen des Erfolgs Machbarkeitsnachweis • • • Sammeln von ersten Erfahrungen mit AWS Erstellen eines Pilotprojekts und Validierung der Technologie Testen der bestehenden Software in der Cloud Verschieben Ihrer Daten • • • • Kennenlernen der verschiedenen Speicheroptionen in der AWS Cloud Migrieren von Dateiservern zu Amazon S3 Migrieren von RDBMS zu Amazon RDS Migrieren von RDBMS die nicht von Amazon RDS unterstützt werden zu EC2 + EBS Verschieben Ihrer Anwendungen • • • • 1:1-­‐Migrationsstrategie Hybrid-­‐Migrationsstrategie Erstellen von "cloudfähigen" Code-­‐Ebenen je nach Bedarf Erstellen von AMIs für jede Komponente Seite 4 von 29 Wirtschaftlichkeitsberechnung für Migration (geringere TCO, reduzierte Produkteinführungszeit, höhere Flexibilität und Beweglichkeit, Skalierbarkeit und Elastizität) Ermitteln von Lücken zwischen Ihrer bisherigen älteren Architektur und der Cloud-­‐Architektur der nächsten Generation Vertrautmachen mit verschiedenen AWS-­‐Services Minimieren von Risiken durch Validierung kritischer Teile Ihrer vorgeschlagenen Architektur Redundanz, dauerhafter Speicher, elastischer und skalierbarer Speicher Automatische Verwaltungssicherung Zukunftssichere, skalierte, serviceorientierte, elastische Architektur Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Phasen Nutzen der Cloud • • • • • Vorteile Nutzung weiterer AWS-­‐Dienste Automatisieren von Elastizität und des System Development Life-­‐cycle Verstärken der Sicherheit Erstellen eines Dashboards zum Verwalten von AWS-­‐ Ressourcen Nutzung verschiedener Availability Zones Optimierung • • • • • Oktober 2014 Optimieren der Nutzung je nach Anforderung Steigern der Effizienz Implementieren fortschrittlicher Überwachung und Telemetrie Umgestalten Ihrer Anwendung Aufspalten Ihrer relationalen Datenbanken Senkung des CapEx in der IT Flexibilität und Agilität Automatisierung und gesteigerte Produktivität Höhere Verfügbarkeit (HA) Gesteigerte Nutzung und tiefgreifende Auswirkung auf Betriebsaufwand Höhere Transparenz durch moderne Überwachung und Telemetrie Die Reihenfolge der Phasen ist nicht wichtig. Beispielsweise bevorzugen es viele Unternehmen, die Phase 1 (Bewertungsphase) zu überspringen und direkt bei Phase 2 (Machbarkeitsnachweis) einzusteigen oder die Anwendungsmigration (Phase 4) durchzuführen, bevor sie alle ihre Daten migrieren (Phase 3). Phase 1: Cloud-­‐Bewertungsphase Diese Phase hilft Ihnen beim Erstellen einer Wirtschaftlichkeitsberechnung für die Migration in die Cloud. Finanzielle Bewertung Für das Abwägen der finanziellen Aspekte des Besitzes und Betriebs eines Rechenzentrums oder der Nutzung von Co-­‐Locations im Vergleich zur Verwendung einer cloudbasierten Infrastruktur ist eine detaillierte und gründliche Analyse erforderlich. In der Praxis ist dies nicht so einfach wie das Messen der potenziellen Hardwareausgaben sowie den Kosten für Datenverarbeitungs-­‐ und Speicherressourcen. Tatsächlich müssen Unternehmen eine Vielzahl von Optionen erwägen, um einen schlüssigen Vergleich zwischen den zwei Alternativen zu ziehen. Amazon hat das Whitepaper The Economics of the AWS cloud2 veröffentlicht, das Ihnen bei der Erfassung der erforderlichen Daten für einen stichhaltigen Vergleich hilft. Für diese grundlegende TCO-­‐Methode und den zugehörigen Amazon EC2-­‐ Kostenrechner werden Branchendaten, AWS-­‐Kundenforschungsergebnisse und benutzerdefinierte Eingaben verwendet, um die jährlichen Vollkosten für den Besitz, den Betrieb und die Wartung der IT-­‐Infrastruktur mit den nutzungsabhängigen Kosten von Amazon EC2 zu vergleichen. Bei dieser Analyse werden nur die direkten Kosten der IT-­‐ Infrastruktur verglichen. Nicht berücksichtigt werden die vielen indirekten wirtschaftlichen Vorteile von Cloud Computing wie hohe Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit, Flexibilität, Reduzierung der Produkteinführungszeit und viele weitere mit der Cloud zusammenhängende Vorteile. Wir empfehlen Ihnen eine separate Analyse durchführen, um den wirtschaftlichen Wert dieser Aspekte zu ermitteln. 2 http://media.amazonwebservices.com/The_Economics_of_the_AWS_Cloud_vs_Owned_IT_Infrastructure.pdf Seite 5 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Preise Einmalige Vorauszahlung AWS Co-­‐ Vor Ort Location Serverhardware 0 $$$ $$ Netzwerkhardware 0 $$ $$ Hardwarewartung 0 $$ $$ Software Betriebssystem 0 $$ $$ Strom und Kühlung 0 0 $$ Rechenzentrum/Co-­‐Location 0 $$ $$ Administration 0 $$ $$ Speicher 0 $$ $$ Bandbreite 0 $$ $ Ressourcenverwaltungssoftware 0 0 0 Support – täglich rund um die Uhr 0 0 0 Gesamt Oktober 2014 Monatlich AWS Co-­‐ Vor Ort Location $$ 0 0 0 0 0 0 0 $ $ 0 0 0 $$ $ 0 $ 0 $ $$ $$$ $ 0 0 $$ $ $ $ $ $ $ $ $ Tabelle 1: TCO-­‐Berechnungsbeispiel für Cloud (auf Grundlage einiger Annahmen) Das AWS Economics Center stellt alle erforderlichen Tools bereit, um Ihre aktuelle IT-­‐Infrastruktur zu bewerten. Für ihre TCO Betrachtung können Sie den TCO Vergleichsrechner benutzen. Nachdem Sie eine grobe finanzielle Bewertung durchgeführt haben, können Sie Ihre monatlichen Kosten mithilfe des einfachen Monatsrechners von AWS durch Eingabe Ihrer realistischen Nutzungszahlen abschätzen. Wenn Sie diese Kosten auf einen Zeitraum von einem, drei und fünf Jahren hochrechnen, werden Sie erhebliche Einsparungen feststellen. Bewertung von Sicherheit und Compliance Wenn es für Ihr Unternehmen spezifische IT-­‐Sicherheitsrichtlinien und Compliance-­‐Anforderungen gibt, wird empfohlen, dass Sie Ihre Sicherheitsberater und -­‐Auditoren schon frühzeitig am Verfahren beteiligen. In dieser Phase können Sie die folgenden Fragen stellen: • Wie hoch ist meine allgemeine Risikotoleranz? Gibt es unterschiedliche Klassifizierungen meiner Daten mit höherer oder niedrigerer Toleranz hinsichtlich einer Gefährdung? • Wie lauten meine wichtigsten Bedenken im Zusammenhang mit Vertraulichkeit, Integrität, Verfügbarkeit und Dauerhaftigkeit meiner Daten? • An welche behördlichen oder vertraglichen Verpflichtungen zum Speichern von Daten bin ich in bestimmten Jurisdiktionen gebunden? Seite 6 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 • Was sind meine Sicherheitsbedrohungen? Wie hoch ist die Wahrscheinlichkeit, dass aus diesen Bedrohungen reale Angriffe werden? • Habe ich Bedenken hinsichtlich des Schutzes geistigen Eigentums und rechtlicher Probleme bezüglich meiner Anwendung und Daten? • Welche Optionen habe ich, wenn ich alle meine Daten aus der Cloud zurückholen muss? • Gibt es organisatorische Schwierigkeiten, die gelöst werden müssen, um die Akzeptanz für die Nutzung von Infrastrukturservices zu erhöhen? Datensicherheit kann ein schwieriges Thema darstellen, wenn es nicht klar verstanden und analysiert wird. Daher ist es wichtig, dass Sie die Risiken und Bedrohungen (und die Wahrscheinlichkeit dieser Bedrohungen) kennen und dann auf Grundlage der Vertraulichkeit Ihrer Daten diese in verschiedene Kategorien einordnen (wird im nächsten Abschnitt erläutert): Dies wird Ihnen auch bei der Entscheidung helfen, welche Datensätze (oder Datenbanken) in die Cloud verschoben werden und welche im Unternehmen verbleiben sollen. Außerdem ist es wichtig, dass Sie die folgenden Grundsätze in Bezug auf AWS Security kennen: • Sie besitzen die Daten, nicht AWS. • Sie entscheiden, an welchem geografischen Standort die Daten gespeichert werden sollen. Diese verbleiben dort, bis Sie entscheiden, sie zu verschieben. • Sie können Ihre Daten jederzeit herunterladen oder löschen. • Sie sollten die Vertraulichkeit Ihrer Daten prüfen und entscheiden, ob und wie Sie Ihre Daten während der Übertragung und auf dem Server verschlüsseln. • Sie können fein granulare Berechtigungen für die Verwaltung des Zugriffs der Benutzer innerhalb Ihres Unternehmens auf spezifische Servicevorgänge, Daten und Ressourcen in der Cloud festlegen, um eine stärkere Sicherheitskontrolle zu erreichen. • Aktuelle Informationen über Zertifizierungen und empfohlene Vorgehensweisen erhalten Sie im AWS-­‐Security Center. Technische und funktionale Bewertung Eine technische Bewertung ist erforderlich, um herauszufinden, welche Anwendungen hinsichtlich der Architektur und Strategie besser für die Cloud geeignet sind. Zu gegebener Zeit bestimmen Unternehmen, welche Anwendungen zuerst in die Cloud verschoben, welche Anwendungen später verschoben und welche Anwendungen im Unternehmen verbleiben sollten. In diesem Abschnitt der Phase sollten Unternehmensarchitekten die folgenden Fragen stellen: • Welche Unternehmensanwendungen sollten zuerst in die Cloud verschoben werden? • Stellt die Cloud alle Infrastrukturbausteine bereit, die wir benötigen? • Können wir unsere vorhandenen Tools für Ressourcenverwaltung und Konfiguration wiederverwenden? • Wie können wir laufende Supportverträge für Hardware, Software und Netzwerk kündigen? Seite 7 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Erstellen einer Abhängigkeitenstruktur und eines Klassifizierungsdiagramms Führen Sie eine gründliche Untersuchung der logischen Konstrukte Ihrer Unternehmensanwendungen durch und klassifizieren Sie Ihre Anwendungen auf Grundlage ihrer Abhängigkeiten, Risiken sowie Sicherheits-­‐ und Compliance-­‐Anforderungen. Identifizieren Sie die Anwendungen und ihre Abhängigkeiten von anderen Komponenten und Services. Erstellen Sie eine Abhängigkeitenstruktur, die die verschiedenen Teile Ihrer Anwendungen aufzeigt, und kennzeichnen Sie deren Abhängigkeiten nach oben und unten in Bezug auf andere Anwendungen. Erstellen Sie eine Tabelle, in der alle Ihre Anwendungen und Abhängigkeiten aufgelistet sind, oder erfassen Sie Ihre Abhängigkeitenstruktur einfach auf einem "Whiteboard", auf der die verschiedenen Ebenen von gegenseitigen Verbindungen Ihrer Komponenten dargestellt sind. Dieses Diagramm sollte ein korrektes Abbild der Anwendungskomponenten Ihres Unternehmens sein. Es könnte ungefähr wie das unten abgebildete Diagramm aussehen. Es sollte alle Ihre ERP-­‐Systeme, HR-­‐Services-­‐, Gehaltsabrechnungs-­‐ und Batchverarbeitungsysteme, Backend-­‐Rechnungsstellungssysteme und kundenseitigen Webanwendungen, interne IT-­‐Unternehmensanwendungen, CRM-­‐Systeme usw. sowie gemeinsame Dienste auf unterer Ebene, wie z. B. LDAP-­‐Server, enthalten. Dash board CRM Web In dieser Phase haben Sie einen klaren Einblick in Ihre IT-­‐ Komponenten und das Einordnen Ihrer Anwendungen in verschiedene Kategorien sollte jetzt möglich sein: Auth • LDAP-­‐ DB Servic • Protok olle • Suche • ERP BI • DW Anwendungen mit als "streng geheim", "geheim" oder "öffentlich" gekennzeichneten Datensätzen Anwendungen mit niedrigen, mittleren und hohen Compliance-­‐Anforderungen Anwendungen für den internen Gebrauch, für Partner oder für Kunden Anwendungen mit niedriger, mittlerer und hoher Kopplung Anwendungen mit strikter, gelockerter Lizenzierung ... usw. OLAP Engin e Bericht e Abbildung 2: Beispiel eines Whiteboard-­‐Diagramms aller IT-­‐Komponenten und deren Abhängigkeiten (Abhängigkeitenstruktur) Ermitteln des richtigen "Kandidaten" für die Cloud Nachdem Sie eine Abhängigkeitenstruktur erstellt und die IT-­‐Komponenten Ihres Unternehmens klassifiziert haben, untersuchen Sie die Abhängigkeiten jeder Anwendung nach oben und unten, um festzulegen, welche Anwendung schnell in die Cloud verschoben werden sollte. Für eine webbasierte Anwendung oder SaaS (Software as a Service)-­‐Anwendung besteht die Abhängigkeitenstruktur aus logischen Komponenten (Funktionen) der Website, wie Datenbank, Such-­‐ und Indizierungsmaschine, Anmeldungs-­‐ und Authentifizierungsservice, Rechnungsstellung oder Bezahlung usw. Für die Backend-­‐Verarbeitungs-­‐Pipeline gibt Seite 8 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 es wahrscheinlich verschiedene untereinander verbundene Prozesse, wie Workflowsysteme, Protokollierungs-­‐ und Berichtssysteme sowie ERP-­‐ oder CRM-­‐Systeme. In den meisten Fällen sind die besten Kandidaten für die Cloud die Services oder Komponenten, die die wenigsten Abhängigkeiten nach oben und unten haben. Beginnen Sie damit, nach Systemen zu suchen, die wenige Abhängigkeiten von anderen Komponenten haben. Einige Beispiele sind Backup-­‐ und Archivierungssysteme, Batchverarbeitungsanwendungen, Protokollverarbeitungssysteme, Entwicklungs-­‐, Test-­‐ und Buildsysteme, Web-­‐Front-­‐ (Marketing-­‐)Anwendungen, Queuing-­‐Systeme, Inhaltsverwaltungssysteme oder Schulungs-­‐ und Pre-­‐Sales-­‐Demosysteme. Um festzustellen, welche Kandidaten sich gut für die Cloud eignen, suchen Sie nach Anwendungen mit nicht voll ausgelasteten Komponenten, Anwendungen, bei denen ein unmittelbarer geschäftlicher Bedarf nach Skalierung vorliegt und bei denen die Kapazitäten knapp werden, Anwendungen, die strukturell flexibel sind, Anwendungen, die herkömmliche Bandlaufwerke für die Datensicherung verwenden, Anwendungen, die eine globale Skalierung erfordern (z. B. kundenseitige Marketing-­‐ und Werbeanwendungen), oder Anwendungen, die von Partnern verwendet werden. Stellen Sie Anwendungen zurück, die eine spezielle Hardware benötigen (z. B. ein Mainframe). Das h boa CR M We b Aut h LDAP -­‐ DB Such e OLA P ERP We b Proto kolle D BI Engi ne Beric hte Suc he Abbildung 3: Ermitteln des richtigen Kandidaten für die Cloud Nachdem Sie über eine Liste mit idealen Kandidaten verfügen, priorisieren Sie Ihre Liste der Anwendungen, um damit: • alle Aspekte der Cloud (Datenverarbeitung, Speicher, Netzwerk, Datenbank) möglichst klar herauszustellen • für Unterstützung in Ihrem Unternehmen zu werben und für die wichtigsten Interessengruppen eine maximale Wirkung und Transparenz zu erzielen Fragen, die in dieser Phase gestellt werden sollten: • Ist es Ihnen möglich, die derzeitige Architektur der Kandidatenanwendung in der Cloud-­‐Architektur abzubilden? Falls nicht, wie hoch wäre der Aufwand für eine Umgestaltung? Seite 9 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 • Kann Ihre Anwendung in die Instanz einer virtuellen Maschine (VM) verpackt und in der Cloud-­‐Infrastruktur ausgeführt werden oder ist eine spezielle Hardware und/oder ein spezieller Zugriff auf Hardware erforderlich, was die AWS Cloud nicht bereitstellen kann? • Berechtigt die Lizenz Ihres Unternehmen dazu, Drittanbieter-­‐Software, die in der Kandidatenanwendung verwendet wird, in die Cloud zu verschieben? • Wie hoch ist der Aufwand (in Bezug auf das Erstellen neuer Tools oder das Ändern vorhandener Tools) für das Verschieben der Anwendung? • Welche Komponente muss lokal (vor Ort) verbleiben und welche kann in die Cloud verschoben werden? • Welche Anforderungen bestehen hinsichtlich Latenz und Bandbreite? • Unterstützt die Cloud den von Ihnen benötigten Identitäts-­‐ und Authentifizierungsmechanismus? Ermitteln der Tools, die Sie wiederverwenden können Es ist wichtig, Ihre vorhandenen IT-­‐Komponenten zu untersuchen und zu analysieren. Ermitteln Sie die Tools, die Sie in der Cloud ohne Änderungen wiederverwenden können, und kalkulieren Sie, wie hoch der Aufwand (in Bezug auf Entwicklung und Bereitstellung) für das Hinzufügen von "AWS Support" zu den Tools sein wird. Möglicherweise können Sie die meisten Systemtools wiederverwenden und/oder Unterstützung für AWS problemlos hinzufügen. Alle AWS-­‐ Services zeigen standardmäßige SOAP-­‐ und REST-­‐Webservice-­‐APIs und stellen verschiedene Bibliotheken und SDKs in der Programmiersprache Ihrer Wahl bereit. Es gibt einige kommerzielle Tools, die Sie aufgrund von Lizenzproblemen momentan nicht in der Cloud benutzen können. Für diese Tools müssen Sie Ersatz finden und beschaffen: 1. Ressourcenverwaltungstools: In der Cloud haben Sie es mit abstrakten Ressourcen (AMIs, Amazon EC2-­‐ Instanzen, Amazon S3-­‐Buckets, Amazon EBS-­‐Volumes usw.) zu tun. Wahrscheinlich benötigen Sie Tools, um diese Ressourcen zu verwalten. Eine Basis-­‐Verwaltung bietet die AWS Management Console. 2. Architektur Management Tools: Wenn ermittlet wurde, welche Resourcen benötigt werden, kann man komplette Architekturen mit AWS CloudFormation beschreiben und managen. Alle benötigten Resourcen und Konfigurationen werden dazu in einer JSON Datei beschrieben, welche man z.B. im Versionskontrollsystem speichern kann. Mit der fertigen Beschreibung kann man ein komplettes Deployment in der AWS Region der Wahl mit einem einfachen Klick in der AWS Management Konsole starten. 3. Ressourcenkonfigurationstools: Automatisierung ist in der AWS-­‐Cloud sehr einfach. Daher wird empfohlen, dass Sie die Verwendung von Tools in Betracht ziehen, um die Automatisierung des Konfigurationsprozesses zu unterstützen. Informieren Sie sich über den AWS OpsWorks Service und Open-­‐Source-­‐Tools wie Chef (AWS OpsWorks kann direct Chef Rezepte benutzen), Puppet und CFEngine usw. 4. Systemverwaltungstools: Nachdem Sie Ihre Services bereitgestellt haben, müssen Sie Ihre bestehenden Systemverwaltungstools (NOC) möglicherweise anpassen, um die Anwendungen in der Cloud effektiv zu überwachen, bereitzustellen und zu "beobachten". Zum Verwalten der Amazon Virtual Private Cloud-­‐ Ressourcen können Sie dieselben Sicherheitsrichtlinien und dieselben Systemverwaltungstools verwenden, die Sie momentan für die Verwaltung Ihrer eigenen lokalen Ressourcen nutzen. 5. Integrationstools: Sie müssen die Frameworks/Bibliotheken/SDKs ermitteln, die für Sie am besten für die Integration mit AWS-­‐Services geeignet sind. Für die meisten Plattformen und Programmiersprachen sind Bibliotheken und SDKS verfügbar (siehe den Abschnitt über Ressourcen). Informieren Sie sich außerdem über Tools für Entwicklungsumgebungen wie das AWS Toolkit for Eclipse. Seite 10 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Migration von lizensierten Lösungen Es ist wichtig, Lizenzprobleme während der Bewertungsphase aus dem Weg zu räumen. Amazon arbeitet mit vielen unabhängigen Softwareherstellern (Independent Software Vendors, ISVs) zusammen, um die Migration so reibungslos wie möglich zu gestalten. Amazon kooperiert mit einer Vielzahl von Anbietern und hat momentan drei verschiedene Optionen zur Auswahl: 1. Nutzung einer eigenen Lizenz ("Bring Your Own License", BYOL) Amazon kooperiert mit einer Vielzahl von ISVs, die die Nutzung ihrer eigenen Lösungen auf Amazon EC2 gestatten. Diese EC2-­‐basierte Lizenz ist die unproblematischste Möglichkeit, um Ihre Software in die Cloud zu verschieben. Sie erwerben die Lizenz auf die herkömmliche Art oder verwenden Ihre bestehende Lizenz und wenden sie auf das Produkt an, das als vorkonfiguriertes Amazon-­‐Computerabbild (AMI) verfügbar ist. Beispielsweise stellen Oracle, Sybase, Adobe, MySQL, JBOSS, IBM und Microsoft ihre Software in der AWS Cloud über die BYOL-­‐Option zur Verfügung. Wenn Sie die gewünschte Software in der AWS Cloud nicht finden, sprechen Sie mit Ihrem Softwareanbieter, ob er seine Software in der Cloud verfügbar machen kann. Das AWS-­‐ Account Management-­‐Team kann sie bei dieser Diskussion unterstützen. 2. AWS Marketplace -­‐ Nutzungsabhängige Preise Amazon kooperiert mit erstklassigen ISVs, die ihre Software im AWS Marketplace anbieten. ISVs können eine nutzungsabhängige Lizenz anbieten, in dem sie z.B. eine Gebühr zusätzlich zu den standardmäßigen Amazon EC2-­‐Kosten berechnen. Einige ISVs bieten auch ein Supportpaket an. 3. SaaS-­‐basierter Cloud-­‐Service von ISVs Einige ISVs bieten ihre Software als Software-­‐as-­‐a-­‐Service (SaaS) an und berechnen eine monatliche Abonnementgebühr. Sie stellen standardmäßige APIs und webbasierte Oberflächen bereit und führen die Implementierung ziemlich schnell durch. Dieses Angebot wird entweder vollständig oder teilweise innerhalb der AWS Cloud verwaltet. Diese Option stellt oftmals die einfachste und schnellste Möglichkeit dar, um Ihre lokale Installation vor Ort zu einem On-­‐Demand-­‐Angebot desselben Anbieters oder zu einem entsprechenden Angebot eines anderen Anbieters zu migrieren. In den meisten Fällen bieten ISVs oder unabhängige Drittanbieter-­‐Integratoren für Cloud-­‐Unternehmensservices Migrationstools an, die Sie beim Verschieben Ihrer Daten unterstützen können. Beispielsweise gibt es von Mathematica, Quantivo, Pervasive und Cast Iron ein SaaS-­‐Angebot basierend auf AWS. Wenn Ihre Unternehmensanwendungen eng mit komplexen Unternehmenssoftwaresystemen von Drittanbietern verbunden sind, die noch nicht in die AWS Cloud migriert wurden, oder wenn Sie bereits in mehrjährige Lizenzverträge des Anbieters für die lokale Nutzung investiert haben, sollten Sie eine Umgestaltung Ihrer Unternehmensanwendungen in funktionale Bausteine in Betracht ziehen. Führen Sie alles, was möglich ist, in der Cloud aus und stellen Sie eine Verbindung zu den Systemen her, die lizenzierte Software weiterhin vor Ort ausführen. Sie können Amazon VPC verwenden, um einen IPSec-­‐VPN-­‐Tunnel zu erstellen, der es ermöglicht, dass Ressourcen, die auf AWS ausgeführt werden, sicher mit Ressourcen kommunizieren können, die sich am anderen Ende des Tunnels in Ihrem bestehenden Rechenzentrum befinden. In einem Whitepaper3 werden verschiedene Möglichkeiten erörtert, wie Sie Ihre bestehende IT-­‐Infrastruktur auf die Cloud ausdehnen können. Definieren Ihrer Erfolgskriterien In dieser Phase ist es wichtig, sich die folgende Frage zu stellen: "Wie messe ich den Erfolg?" In der folgenden Tabelle sind einige Beispiele aufgeführt. Die spezifischen Erfolgskriterien müssen an die Ziele und die Kultur Ihres Unternehmens angepasst werden. 3 http://media.amazonwebservices.com/Extend_your_IT_infrastructure_with_Amazon_VPC.pdf Seite 11 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Erfolgskriterien Alt Neu Beispiele, wie gemessen wird Kosten (Investitionsaufwand) 1 Mio. USD 300.000 USD 60 % Einsparungen bei Investitionsaufwand in den nächsten 2 Jahren Kosten (Betriebsaufwand) 20.000 USD/Jahr 10.000 USD/Jahr HardwareBeschaffungseffizienz 10 Maschinen in 7 Monaten 100 Maschinen in 5 Minuten Server-/Mitarbeiter-Verhältnis um Faktor 2 verbessert 4 Wartungsverträge beendet 3000 % schnellere Bereitstellung von Ressourcen Produkteinführungszeit 9 Monate 1 Monat 80 % schnellere Produkteinführung Zuverlässigkeit Unbekannt Redundant 40 % weniger Supportanrufe im Zusammenhang mit der Hardware Verfügbarkeit Unbekannt Mindestens 99,99 % Betriebszeit 20 % weniger Supportanrufe im Zusammenhang mit dem Betrieb Flexibilität Feste Größe des Anwendungsstacks Beliebige Größe des Anwendungsstacks Neue Möglichkeiten Rückstand von 10 Projekten Kein Rückstand, 5 neue Projekte in Planung Nicht an einen bestimmten Hardwareanbieter oder eine bestimmte Plattform oder Technologie gebunden 25 neue Projekte in 3 Monaten begonnen Tabelle 2: Beispiele, wie Erfolgskriterien gemessen werden Erstellen einer Roadmap und eines Plans Durch das Dokumentieren der Abhängigkeiten, das Erstellen einer Abhängigkeitenstruktur und die Ermittlung der zu esrtellenden oder anzupassenden Tools erhalten Sie eine Vorstellung davon, welche Anwendungen vorrangig migriert werden sollten, wie hoch schätzungsweise der Migrationsaufwand und die einmaligen Kosten ausfallen und wie der zeitliche Ablauf einzuschätzen ist. Sie können eine Roadmap für die Cloud-­‐Migration erstellen. Die meisten Unternehmen fangen oft auch schon mit der nächsten Phase, dem Pilotprojekt, an, da man dadurch einen besseren Einblick in die Technologien und Tools erhält, und somit die Roadmap und die Pläne verfeinern und anpassen kann. Phase 2: Machbarkeitsnachweis-­‐Phase Nachdem Sie den richtigen Kandidaten für die Cloud ermittelt und den für die Migration erforderlichen Aufwand kalkuliert haben, ist es Zeit für einen ersten Probelauf mit einem kleinen Projekt zum Machbarkeitsnachweis. Das Ziel dieser Phase besteht darin, AWS kennenzulernen und sicherzustellen, dass Ihre Annahmen hinsichtlich der Eignung für die Migration in die Cloud korrekt sind. In dieser Phase können Sie eine kleine Anwendung "auf der grünen Wiese" bereitstellen und im weiteren Verlauf erste Erfahrungen mit der AWS Cloud sammeln. Sammeln von ersten Erfahrungen mit AWS Machen Sie sich mit AWS API, AWS-­‐Tools, SDKs und vor allem mit der AWS Management Console und den Befehlszeilen-­‐ Tools vertraut (weitere Informationen zu den ersten Schritten erhalten Sie im Getting Started Center.) Nach Abschluss dieser Phase sollten Sie zumindest wissen, wie Sie die AWS Management Console und die Befehlszeilen-­‐ Tools verwenden müssen, um Folgendes durchzuführen: Seite 12 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Ein Objekt hochladen Informaconen über Amazon S3 Oktober 2014 Eine signierte URL erstellen Bucket erstellen Eine CloudFront-­‐ Verteilung erstellen AMI anpassen AMI bündeln Informaconen über Sicherheitsgruppen Verschiedene Availability Zones testen Eine angepasste AMI starten AMI starten Informaconen über Amazon EC2 Snapshot eines Volumes erstellen EBS-­‐Volume erstellen Volume verbinden Snapshot wiederherstellen Elascsche IP erstellen Informaconen über Amazon RDS DNS zu elascscher IP zuordnen Eine Sicherungskopie anlegen Eine DB-­‐Instanz starten Verckal skalieren Horizontal skalieren (mehr Speicher) Einrichtung Mulc-­‐AZ Abbildung 4: Erforderliche Mindestkenntnisse über Services für einen Machbarkeitsnachweis Informationen über AWS-­‐Sicherheitsfunktionen Informieren Sie sich über die derzeit verfügbaren AWS-­‐Sicherheitsfunktionen. Verwenden Sie sie je nach Bedarf in jeder Phase des Migrationsprozesses. Lernen Sie die verschiedenen von AWS bereitgestellten Sicherheitsfunktionen während der Machbarkeitsnachweis-­‐Phase kennen: AWS-­‐Anmeldeinformationen, Multi-­‐Factor Authentication (MFA), Authentifizierung und Autorisierung. Informieren Sie sich mindestens über die AWS Identity and Access Management (IAM)-­‐Funktionen, die es Ihnen ermöglichen, mehrere Benutzer zu erstellen und die Berechtigungen für jeden Benutzer innerhalb Ihres AWS-­‐Kontos zu verwalten. In Abbildung 5 sind die Inhalte dargestellt, die Sie über IAM wissen müssen: Gruppen erstellen Eine Richtlinie erstellen Informaconen über Ressourcen und Bedingungen Benutzer erstellen Neue Anmelde-­‐ informaconen für den Zugriff erstellen Benutzer zu Gruppen zuweisen Informaconen über IAM Abbildung 5: Erforderliche Mindestkenntnisse über Sicherheit in einem Machbarkeitsnachweis In dieser Phase sollten Sie sich überlegen, ob Sie verschiedene IAM-­‐Gruppen für verschiedene Unternehmensfunktionen innerhalb Ihres Unternehmens oder Gruppen für verschiedene IT-­‐Rollen (Administratoren, Entwickler, Tester usw.) erstellen möchten und ob Sie Benutzer nach Ihrem Organigramm anlegen oder ob Sie Benutzer für jede Anwendung erstellen möchten. Seite 13 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Erstellen eines Machbarkeitsnachweises Erstellen Sie einen Machbarkeitsnachweis, der einen Mikrokosmos Ihrer Anwendung darstellt oder mit dem die kritische Funktionalität Ihrer Anwendung in der Cloud-­‐Umgebung getestet wird. Beginnen Sie mit einer kleinen Datenbank (oder einem Datensatz). Haben Sie keine Angst, Instanzen zu starten oder zu beenden oder einen Belastungstest für das System durchzuführen. Wenn Sie beispielsweise planen, eine Webanwendung zu migrieren, können Sie damit beginnen, Miniaturmodelle aller Teile Ihrer Architektur (Datenbank, Webanwendung, Load Balancer) mit minimalen Daten bereitzustellen. Lernen Sie dabei, wie Sie einen eigenen Netzwerkbereich in der AWS Cloud einrichten (Amazon VPC), wie Sie eine Webserver-­‐AMI erstellen und wie Sie die Sicherheitsgruppen einrichten, damit nur der Webserver mit dem Anwendungsserver kommunizieren kann, wie alle statischen Dateien auf Amazon S3 gespeichert werden, wie ein EBS-­‐Volume für eine Amazon EC2-­‐Instanz bereitgestellt wird, wie Ihre Anwendung mit Amazon CloudWatch verwaltet/überwacht wird und wie IAM verwendet wird, um den Zugriff auf diejenigen Services und Ressourcen zu beschränken, die für die Funktion Ihrer Anwendung erforderlich sind. Die meisten unserer Unternehmenskunden probieren diese Phase aus und profitieren erheblich von dem Erstellen der Pilotprojekte. Wir haben festgestellt, das Kunden viel über die Funktionen und die Anwendbarkeit von AWS im Verlauf dieses Prozesses lernen und den Kreis der Anwendungen, die in die AWS Cloud migriert werden könnten, schnell vergrößern. In dieser Phase können Sie für Unterstützung in Ihrem Unternehmen sorgen, die Technologie validieren, ältere Software in der Cloud testen, erforderliche Benchmarks durchführen und Erwartungen festlegen. Am Ende dieser Phase sollten Sie die folgenden Fragen beantworten können: • Kenne ich die grundlegende AWS-­‐Terminologie (Instanzen, AMIs, Volumes, Snapshots, Verteilungen, Domänen usw.)? • Habe ich durch das Erstellen dieses Machbarkeitsnachweises die verschiedenen Aspekte der AWS Cloud (Datenverarbeitung, Speicher, Netzwerk, Datenbank, Sicherheit) kennengelernt? • Wird dieser Machbarkeitsnachweis innerhalb des Unternehmens ein Bewusstsein für die Leistungsfähigkeit der AWS Cloud schaffen und vergrößern? • In welcher Form sollten alle neu erworbenen Informationen und Kenntnisse am besten festgehalten werden? In einem Whitepaper oder in einer internen Präsentation? • Wie hoch ist der Aufwand, um diesen Machbarkeitsnachweis produktiv umzusetzen? • Welche Anwendungen kann ich unmittelbar nach diesem Machbarkeitsnachweis verschieben? Nach dieser Phase werden Sie einen viel besseren Einblick in die heutigen Möglichkeiten von AWS haben. Sie werden über praktische Erfahrungen mit dieser neuen Umgebung verfügen, wodurch sie einen besseren Überblick über die zu überwindenden Hürden bekommen. Phase 3: Datenmigrationsphase In dieser Phase sollten Unternehmensarchitekten die folgenden Fragen stellen: • Welche verschiedenen Speicheroptionen sind derzeit in der Cloud verfügbar? • Welche verschiedenen RDBMS-­‐Optionen (kommerziell und Open Source) sind derzeit in der Cloud verfügbar? Seite 14 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 • Wie lautet meine Datensegmentierungsstrategie? Welche Kompromisse muss ich eingehen? • Wie hoch ist der Aufwand (in Bezug auf Neuentwicklung, einmalige Skripts) für das Migrieren aller meiner Daten in die Cloud? Bei der Wahl der richtigen Speicheroption muss man zwischen verschiedenen Optionen abwägen. Es gibt verschiedene Aspekte, die Sie prüfen sollten, damit Ihre Anwendung entsprechend der Anforderungen mit minimalem Aufwand skaliert werden kann. Hinsichtlich der verschiedenen Aspekte müssen Sie geeignete Kompromisse eingehen: Kosten, Haltbarkeit, Abfragemöglichkeiten, Latenz, Leistung (Reaktionszeit), relationale SQL-­‐Joins, Größe des gespeicherten Objekts (groß, klein), Zugriffsmöglichkeit, hohes Leseaufkommen gegenüber hohem Schreibaufkommen, Aktualisierungsfrequenz, Cachefähigkeit, Konsistenz ("strikte Konsistenz" oder "eventual consistency") und Nutzungsdauer (vorübergehend). Wägen Sie Ihre Optionen sorgfältig ab und entscheiden Sie dann, welche für Ihre Anwendung geeignet sind. Das Schöne an AWS ist, dass Sie nicht auf die Verwendung eines bestimmten Services beschränkt sind. Sie können beliebig viele AWS-­‐Speicherkombinationen in jeder gewünschten Kombination verwenden. Weitere Informationen über die verschiedenen Speicherdienste und deren Einordnung in eine Gesamtstrategie erhalten Sie im Whitepaper “Storage Options in the AWS Cloud”4. 4 Siehe http://media.amazonwebservices.com/AWS_Storage_Options.pdf Seite 15 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Kennenlernen der verschiedenen Speicheroptionen in der AWS Cloud Die nachstehende Tabelle hilft Ihnen bei der Auswahl der richtigen Speicheroption: Ideal für Ideale Beispiele Amazon S3 + Amazon Glacier + CloudFront Speichern größerer Objekte, Verteilung statischer Inhalte, Datenarchivierung Amazon EC2 – Ephemeral Storage Speichern von kurzlebigen Daten Mediendateien, Audio, Video, Bilder, Sicherungen, Archive, Versionierung Konfigurationsdat en, ScratchDateien, temporäre Dateien Speicheroptimierte Instanzen für sehr hohe Random-E/ALeistungen (SSDgestützt) oder mit hoher Speicherdichte für hohe squenzielle Leistung Speicheroptimiert e Instanzen für NoSQLDatenbanken oder andere Anwendungen mit hoher RandomE/A-Leistung Amazon EBS Amazon RDS Amazon DynamoDB Amazon Redshift Persistenter Speicher unabhängig von einer Instanz für alle Arten von Daten Speichern und Abfragen von strukturierten relationalen und referenziellen Daten Attributdaten, die über einen Primär- oder Secondärschlüssel abfragbar sind, mit garantiertem Durchsatz und Latenz im einstelligen Millisekundenberei ch Speichern und Abfragen von strukturierten Daten im PetabyteBereich Anwendungen und Anwendungsd aten, Bootdaten, Logdaten und/oder Daten eines RDBMS Datenbank für Webanwendung en, komplexe Transaktionssys teme, Bestandsverwal tung und Auftragsbearbei tungssysteme Datenbank für Digitale Werbung, Online-Spiele, mobile Anwendungen, Webanwendungen , Inventarmanagem ent oder Fulfillment Systeme Data warehouse, Analyse und Reporting Workloads über große Datenmengen Instanzen mit hoher Speicherdichte für Data Warehousing, Hadoop, oder parallele Deteisysteme Nicht empfohlen für Abfragen, Suche Speichern von Datenbanklogs oder Sicherungen, Kundendaten Nicht empfohlene Beispiele Datenbank, Dateisysteme Freigegebene Laufwerke, vertrauliche Daten Statische Einfache KeyJoins oder Daten, Value Daten, Transaktionen webbasierter BLOBs, Inhalt, KeyDateisysteme. Value Daten BLOBs, Dateisysteme, Inhaltsverteilung Tabelle 3: Datenspeicheroptionen in der AWS Cloud Seite 16 von 29 Kleine Datenmengen Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Migrieren Ihrer Dateiserver-­‐Systeme, Sicherungen und Bandlaufwerke zu Amazon S3 und Amazon Glacier Wenn Ihre bestehende Infrastruktur aus Dateiservern, Protokollservern, SANs (Storage Area Networks) und Systemen besteht, die die Daten mithilfe von Bandlaufwerken in regelmäßigen Abständen sichern, sollten Sie erwägen, diese Daten in Amazon S3 zu speichern und in Amazon Glacier zu archivieren bzw. Amazon Glacier direct zu benutzen. Bestandsanwendungen können Amazon S3 meistens ohne größere Änderungen verwenden. Wenn Ihr System jeden Tag Daten generiert, wird ein Migrationsablauf empfohlen, bei dem Ihre "Pipe" auf Amazon S3 gerichtet ist, damit Ihre neuen Daten direkt in der Cloud gespeichert werden. Mithilfe eines separaten Batchprozesses können Sie dann alte Daten in Amazon S3 verschieben. Daten in Amazon S3 können einfach auf Amazon Glacier archiviert werden. Amazon Glacier wird die Daten automatisch verschlüsseln (dies ist optional für Amazon S3). Die verschiedenen RDBMS-­‐Optionen in der AWS Cloud Für Ihre relationale Datenbank stehen Ihnen mehrere Optionen zur Verfügung: RDBMS Support von Verwaltet von AWS Preise Skalierbarkeit Amazon RDS/Amazon Redshift Oracle 11g, MySQL, PostgreSQL, Microsoft SQL Server, Amazon Redshift AWS Premium Support Ja RDBMS AMIs Nutzungsabhängig Datenverarbeitung und Speicher mit einem einzigen API-Aufruf oder Klick skalieren BYOL, Nutzungsabhängig Manuell Oracle 11g, Microsoft SQL Server, MySQL, IBM DB2, Sybase, Informix, PostgreSQL AWS und Anbieter Nein DrittanbieterDatenbankservice Verschiedene Anbieter im AWS Marketplace Anbieter Nein Verschiedene Verschieden/ hängt vom Anbieter ab Tabelle 4: Optionen für relationale Datenbanken Migrieren Ihrer SQL-­‐Datenbanken zu Amazon RDS Wenn Sie ein Standard-­‐Deployment einer relationalen Datenbank wie Oracle, MySQL PostreSQL oder MS SQL Server benutzen, ist das Verschieben zu Amazon RDS ganz einfach. Mithilfe aller standardmäßigen Tools können Sie alle Daten in eine Amazon RDS-­‐DB-­‐Instanz verschieben. Stellen Sie nach dem Verschieben der Daten in eine DB-­‐Instanz sicher, dass Sie alle erforderlichen Metriken überwachen. Amazon RDS wird automatisch periodische Sicherungen erzeugen, mit deren Hilfe eine Zeitpunkt-­‐Wiederherstellung möglich ist. Wir empfehlen den Aufbewahrungszeitraum zu verlängern, falls Sie die Wiederherstellung weiter zurückliegender Zeitpunkte benötigen. Migrieren anderer Datenbanken zu Amazon EC2 und Amazon EBS Alle großen Datenbanken sind als Amazon Machine Images (AMIs) verfügbar und werden in der Cloud von den Anbietern unterstützt. Das Migrieren von Daten von einer lokalen Installation vor Ort zu einer Amazon EC2-­‐Cloud-­‐ Instanz unterscheidet sich nicht vom Migrieren von Daten von einer Maschine zu einer anderen, folglich können Sie herkömmliche Migrationswerkzeuge verwenden. Verschieben großer Datenmengen mithilfe des Import/Export-­‐Service von Amazon Wenn der Kosten-­‐ oder Zeitaufwand für das Übertragen von Daten über das Internet zu hoch ist, sollten Sie die Nutzung des AWS Import/Export-­‐Service erwägen. Mit dem AWS Import/Export-­‐Service können Sie Ihre Daten (optional verschlüsselt) auf USB 2.0-­‐ oder eSATA-­‐Speichergeräte laden und sie per Post an AWS senden. AWS lädt Ihre Daten dann in eines Ihrer Amazon S3 Buckets hoch oder erstellt Amazon EBS Volumes mit den gelieferten Daten. Seite 17 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Wenn Sie beispielsweise über mehrere Terabyte an zu analysierenden Protokolldateien verfügen, können Sie die Dateien in ein unterstütztes Gerät kopieren und das Gerät an AWS senden. AWS stellt alle Protokolldateien in Ihrem zugewiesenen Bucket in Amazon S3 wieder her. Von dort können sie dann von Ihrer in der Cloud gehosteten Business Intelligence-­‐Anwendung oder von den Amazon Elastic MapReduce-­‐Services zum Analysieren abgerufen werden. Wenn Sie über eine 100 TB-­‐Datenbank von Oracle mit 50 GB Änderungen pro Tag in Ihrem Rechenzentrum verfügen, die Sie zu AWS migrieren möchten, sollten Sie erwägen, eine vollständige Sicherung der Datenbank auf eine Festplatte durchzuführen und die Sicherung dann auf USB 2.0-­‐Geräte zu kopieren und diese einzusenden. Bis Sie bereit sind, die Produktion von DBMS zu AWS umzustellen, erstellen Sie differenzielle Sicherungen. Die vollständige Sicherung wird vom Importservice wiederhergestellt und Ihre inkrementellen Sicherungen werden über das Internet übertragen und auf die DB-­‐Instanz in der Cloud angewendet. Nachdem die letzte inkrementelle Sicherung angewendet wurde, können Sie den neuen Datenbankserver verwenden. Phase 4: Anwendungsmigrationsphase In dieser Phase sollten Sie die folgende Frage stellen: • Wie kann ich mein System teilweise oder vollständig in die Cloud verschieben, ohne meine laufenden Geschäftsaktivitäten zu stören oder zu unterbrechen? In dieser Phase lernen Sie zwei wesentliche Anwendungsmigrationsstrategien kennen: Die 1:1-­‐Migrationsstrategie und die Hybrid-­‐Migrationsstrategie. Die Vor-­‐ und Nachteile beider Strategien werden erörtert, um Ihnen bei der Entscheidung für die Methode zu helfen, die für Ihre Anwendung am besten geeignet ist. Auf Grundlage der Klassifizierung der Anwendungstypen (in Phase 1) können Sie entscheiden, welche Strategie für die jeweiligen Anwendungstypen angewendet werden soll. 1:1-­‐Migrationsstrategie Für zustandslose Anwendungen, eng verbundene Anwendungen oder eigenständige Anwendungen eignet sich die 1:1-­‐ Methode möglicherweise am besten. Statt Teile des Systems nach und nach zu verschieben, können Sie mit der 1:1-­‐ Methode alles auf einmal in die Cloud verschieben. Eigenständige Webanwendungen, die als einzelne Komponenten behandelt werden können, und Sicherungs-­‐/Archivierungssysteme sind Beispiele für diese Arten von Systemen, die mithilfe dieser Strategie in die Cloud verschoben werden können. Komponenten einer dreistufigen Webanwendung, die für eine einwandfreie Funktion eine Verbindung mit extrem geringer Latenzzeit erfordern, sind möglicherweise am besten für diese Methode geeignet, wenn die gesamte Anwendung, einschließlich der Web-­‐, Anwendungs-­‐ und Datenbankserver, auf einmal in die Cloud verschoben wird. Dieser Ansatz kann es Ihnen ermöglichen, eine Bestandsanwendung mit nur wenigen Codeänderungen in die Cloud zu migrieren. Die meisten Änderungen werden das Kopieren der Binärdateien Ihrer Anwendung, das Erstellen und Konfigurieren von Amazon Machine Images (AMIs), das Einrichten von Sicherheitsgruppen und elastischen IP-­‐Adressen, die Konfiguraiton des DNS und die Umstellung zu Amazon RDS-­‐Datenbanken zum Gegenstand haben. Dabei zeigen sich deutlich die Vorteile der grundlegenden Infrastruktur-­‐Services (Amazon EC2, Amazon S3, Amazon RDS und Amazon VPC). Bei dieser Strategie können die Anwendungen möglicherweise nicht sofort von der Elastizität und Skalierbarkeit der Cloud profitieren, da Sie schließlich echte physische Server gegen EC2-­‐Instanzen austauschen oder Dateiserver durch Amazon S3-­‐Buckets oder Amazon EBS-­‐Volumes ersetzen. Logische Komponenten sind weniger wichtig als die physischen Komponenten. Trotzdem ist es wichtig festzustellen, dass Sie durch die Verwendung dieses Ansatzes für bestimmte Anwendungstypen den Platzbedarf für Ihre IT-­‐Infrastruktur reduzieren und das Aufstellen, Bestücken und Betreiben von Serverschränken zu AWS auslagern. Dies ermöglicht es Ihnen, den Schwerpunkt Ihrer Ressourcen auf Aspekte zu legen, Seite 18 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 die Ihr Kerngeschäft differnzieren und Sie von Ihren Mitbewerbern unterscheiden. Sie werden diese Anwendung in den nächsten Stufen erneut überprüfen und dann noch mehr Vorteile der Cloud erkennen können. Wie bei jeder anderen Migration ist eine Sicherungsstrategie, eine Rollback-­‐Strategie und die Durchführung von umfassenden Tests erforderlich. Hybrid-­‐Migrationsstrategie Bei der Hybrid-­‐Migration werden einige Teile einer Anwendung in die Cloud verschoben, während anderen Teile der Anwendung vor Ort belassen werden. Die Hybrid-­‐Migrationsstrategie kann einen risikoarmen Ansatz für die Migration von Anwendungen in die Cloud darstellen. Statt die gesamte Anwendung auf einmal zu verschieben, können einzelne Teile verschoben und nacheinander optimiert werden. Dadurch wird das Risiko eines unerwarteten Verhaltens nach der Migration verringert. Dies ist ideal für große Systeme, die mehrere Anwendungen umfassen. Wenn Sie beispielsweise über eine Website verfügen und über mehrere Batchverarbeitungskomponenten (wie Indizierung und Suche), die Funktionalität für die Website beisteuern, können Sie diesen Ansatz in Betracht ziehen. Das Batchverarbeitungssystem kann z.B. zuerst in die Cloud migriert werden, während die Website im bisherigen Rechenzentrum verbleibt. Die Datenaufnahmeebene kann "cloudfähig" gemacht werden, damit die Daten direkt in die AWS Cloud geführt werden können, z.B. erst in einen Amazon S3 Bucket, oder direkt in eine Amazon EC2-­‐Instanz des Batchverarbeitungssystems, bevor die jeweilige Aufgabe ausgeführt wird. Nach einem einwandfreien Test des Batchverarbeitungssystems können Sie entscheiden, die Websiteanwendung zu verschieben. Vor Ort oder Co-­‐Location AWS Cloud Anmerkungen Prozess Service, Geschäftskomponente oder eine Funktion, die aus einem Anwendungscode, einer Geschäftslogik, einer Datenzugriffsschicht und Datenbank besteht Suche Buch-­‐ haltung Prozess Suche Suche Buch-­‐ haltung Seite 19 von 29 Dünne Schicht mit "cloudfähigem" zu schreibendem Code, die die Webservices-­‐ Schnittstelle der Komponente benutzt; besteht aus Stubs/Skeletons Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Prozess Suche Suche Buch-­‐ haltung Buch-­‐ haltung Die DB in der Nähe der Komponente, die sie verwendet, belassen: Wenn alle Komponenten dieselbe Datenbank verwenden, kann es ratsam sein, alle Komponenten und die Datenbank auf einmal zu verschieben. Wenn alle Komponenten unterschiedliche Datenbank-­‐ Instanzen/-­‐schemata verwenden und sich gegenseitig ausschließen aber in derselben physischen Box gehostet werden, kann es ratsam sein, die logischen Datenbanken zu trennen und sie während der Migration zusammen mit der Komponente zu verschieben. Prozess Prozess Proxy kann optional verwendet werden. Suche Suche Buch-­‐ haltung Buch-­‐ haltung Tabelle 5: Risikoarme Hybrid-­‐Strategie für die Migration von Komponenten in die Cloud Bei dieser Strategie müssen Sie möglicherweise temporäre "Wrapper" planen, entwerfen und erstellen, um die Kommunikation zwischen den Teilen, die sich in Ihrem bisherigen Rechenzentrum, und den Teilen, die sich in der Cloud befinden, zu ermöglichen. Diese Wrapper können "cloudfähig" und asynchron (ggf. mithilfe von Amazon SQS-­‐Queues oder dem Amazon Simple Workflow (SWF)) gemacht werden, damit Sie bei schwankenden Internet-­‐Latenzen stabil bleiben. Diese Strategie kann auch verwendet werden, um Cloudanwendungen mit anderen Cloud-­‐inkompatiblen älteren Anwendungen (Mainframe-­‐Anwendungen oder Anwendungen, die eine spezielle Hardware erfordern) zu integrieren. In einem solchen Fall können Sie "cloudfähige" Webservice-­‐Wrapper um die ältere Anwendung herum erstellen und sie als Webservice verfügbar machen. Da auf Web-­‐Ports oft von außerhalb der Unternehmensnetzwerke zugegriffen werden kann, können die Cloudanwendungen einen direkten Aufruf an diese Webservice durchführen, die wiederum mit den Mainframe-­‐Anwendungen interagieren. Sie können auch einen VPN-­‐Tunnel zwischen den älteren Anwendungen, die sich vor Ort befinden, und den Cloudanwendungen einrichten und damit Ihren Teil der AWS-­‐Cloud (VPC) mit Ihrem Unternehmensnetzwerk verbinden. Konfigurieren und Erstellen Ihrer AMIs In vielen Fällen ist es am besten, mit AMIs zu beginnen, die entweder von AWS oder einem Anbieter vertrauenswürdiger Lösungen bereitgestellt werden. Sie bilden die Grundlage für die AMIs, die Sie im weiteren Verlauf verwenden möchten. Je nach Ihren spezifischen Anforderungen müssen Sie möglicherweise auch AMIs nutzen, die von anderen ISVs bereitgestellt werden. In beiden Fällen ist der Prozess für das Konfigurieren und Erstellen Ihrer AMIs derselbe. Seite 20 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Es wird empfohlen, dass Sie eine AMI für jede Komponente erstellen, die für die Ausführung in einer separaten Amazon EC2-­‐Instanz vorgesehen ist. Außerdem wird empfohlen, einen automatischen oder halbautomatischen Bereitstellungsprozess zu erstellen, um Zeit und Aufwand für die erneute Bündelung von AMIs zu reduzieren, wenn neuer Code freigegeben wird. Dies wäre ein guter Zeitpunkt, um über einen Prozess für die Konfigurationsverwaltung nachzudenken, damit sichergestellt wird, dass Ihre in der Cloud ausgeführten Server in Ihren Prozess eingebunden werden. Phase 5: Nutzen der Cloud Nachdem Sie Ihre Anwendung in die Cloud migriert, die erforderlichen Tests ausgeführt und bestätigt haben, dass alles wie erwartet funktioniert, ist es ratsam, Zeit und Ressourcen zu investieren, um festzustellen, wie Sie weitere Vorteile der Cloud nutzen können. In dieser Phase können Sie die folgenden Fragen stellen: • Was kann ich nach der Migration der Bestandsanwendungen jetzt tun, um die Vorteile hinsichtlich Elastizität und Skalierbarkeit zu nutzen, die die Cloud verspricht? Was muss ich anders machen, um Elastizität in meinen Anwendungen zu implementieren? • Wie kann ich die Vorteile von einigen der anderen fortschrittlichen AWS-­‐Funktionen und -­‐Services nutzen? • Wie kann ich Prozesse automatisieren, um die Wartung und Verwaltung meiner Anwendungen in der Cloud zu vereinfachen? • Was genau muss ich in meiner Cloudanwendung tun, damit sie bei einem Fehlerereignis (Hardware oder Software) eigenständig den Originalzustand wiederherstellen kann? Nutzung anderer AWS-­‐Services Auto Scaling-­‐Service Mit Auto Scaling können Sie Ihre Amazon EC2-­‐Kapazitäten entsprechend den von Ihnen festgelegten Bedingungen nach oben oder nach unten anpassen. Wenn eine der Bedingungen eintritt, führt Auto Scaling automatisch die von Ihnen festgelegte Aktion durch. Untersuchen Sie jede Gruppe von ähnlichen Instanzen in Ihrer Amazon EC2-­‐Flotte und prüfen Sie, ob Sie eine Auto Scaling-­‐Gruppe erstellen können und ob Sie die Kriterien für die automatische Skalierung festlegen können (CPU-­‐ Auslastung, Netzwerk-­‐IO usw.). Sie können mindestens eine Auto Scaling-­‐Gruppe erstellen und als Bedingung festlegen, dass Ihre Auto Scaling-­‐Gruppe immer eine bestimmte Anzahl von Instanzen beinhaltet. Auto Scaling analysiert die Fehlerfreiheit jeder einzelnen Amazon EC2-­‐Instanz in Ihrer Auto Scaling-­‐Gruppe und ersetzt fehlerhafte Amazon EC2-­‐Instanzen automatisch, damit die festgelegte Gruppengröße immer gleich bleibt. Amazon CloudFront Mit nur wenigen Klicks oder Befehlszeilenaufrufen können Sie eine Amazon CloudFront-­‐Verteilung für jeden Ihrer Amazon S3-­‐Buckets erstellen. Dadurch werden Ihre statischen Objekte in einem Edge-­‐Cache näher am Kunden bereitgestellt und die Latenzzeit reduziert. Das ist in vielen Fällen so einfach, dass Kunden nicht bis zu dieser Phase Seite 21 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 warten, sondern den Service viel früher als geplant implementieren, um von CloudFront zu profitieren. Im Whitepaper Migrating to CloudFront5 erhalten Sie weitere Informationen. Amazon Elastic MapReduce Bei der Analyse eines umfangreichen Datensatzes oder der Verarbeitung großer Mengen an Dateien können Sie von Amazon Elastic MapReduce profitieren. Die meisten Unternehmen haben Metrikdaten zu verarbeiten, Logs zu analysieren oder umfangreiche Datensätze zu indizieren. Mit Amazon Elastic MapReduce können Sie wiederholbare Arbeitsabläufe erstellen, um mit wenigen Klicks einen Hadoop-­‐Cluster zu starten, die Verarbeitung durchzuführen, einen laufenden Cluster zu erweitern oder zu reduzieren und einen Cluster zu beenden. Amazon Redshift Amazon Redshift ist ein schneller, vollständig verwalteter Data Warehouse-­‐Service für Datenmengen im Petabyte-­‐ Bereich, mit dem Sie im Zusammenspiel mit Ihren vorhandenen Business Intelligence-­‐Tools alle Ihre Daten einfach und wirtschaftlich analysieren können. Wenn Daten einmal in der AWS Cloud gespeichert sind, ist die Analyse und Auswertung von Daten oft der nächste Schritt, mit denen sich Unternehmen einen tieferen Einblick in ihre Daten verschaffen können um somit ihr Geschäft zu optimieren oder neue Geschäftsideen oder Einkommensquellen zu realisieren. Amazon Route53 Amazon Route 53 ist ein hochverfügbarer und skalierbarer DNS-­‐Webservice (Domain Name System). Entwickler und Unternehmen bietet es eine außerordentlich zuverlässige und kostengünstige Möglichkeit, Endbenutzer zu Internetanwendungen zu routen. Dazu werden Namen wie www.beispiel.de in numerische IP-­‐Adressen wie 192.0.2.1 übersetzt, die Computer zur gegenseitigen Vernetzung verwenden. DNS Einträge können mit einer einfachen Webservice-­‐Schnittstelle oder über die Amazon Management Konsole verwaltet werden. Viele Merkmale sind für globale Deployments sehr hilfreich wie "Latenzbasiertes Routing" (LBR), “GEO-­‐DNS” (unterschiedliche Antworten je nach geografischer Herkunft), DNS Failover und die Integration mit anderen Services von AWS. Amazon Simple Queue Service Amazon Simple Queue Service (Amazon SQS) bietet eine schnelle, zuverlässige, skalierbare und vollständig verwaltete Queue als Service. Mit Amazon SQS können verteilte Anwendungen Nachrichten austauschen ohne dass diese verloren gehen und ohne dass alle Komponenten immer verfügbar sein müssen. Zusammen mit Amazon Elastic Compute Cloud (Amazon EC2) und anderen AWS Infrastruktur Services können automatisierte Workflows einfach erstellt werden. Amazon SQS stellt eine einfache Web Service-­‐Schnittstelle zur Verfügung, die sowohl von EC2-­‐Instanzen als auch von anderen Rechnern im Internet zum Datenaustausch benutzt werden kann. Daher eignet sich Amazon SQS sehr gut, um in hybriden Modellen die Applikationen oder Komponenten, die bereits zu AWS migriert wurden, mit den noch vorhandenen Applikationen in anderen Rechenzentren zu verknüpfen. Automatisieren der Elastizität Elastizität ist eine grundlegende Eigenschaft der Cloud. Informationen über Elastizität und über das Erstellen von Architekturen, die eine schnelle Kapazitätsanpassung nach oben oder nach unten unterstützen, erhalten Sie im Whitepaper "Architecting for the Cloud"6. Elastizität kann auf verschiedenen Ebenen der Anwendungsarchitektur 5 6 http://developer.amazonwebservices.com/connect/entry!default.jspa?categoryID=267&externalID=2456 http://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf Seite 22 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 implementiert werden. Um Elastizität implementieren zu können, ist es möglicherweise erforderlich, Ihre Anwendung umzugestalten und in Komponenten aufzuteilen, damit sie skalierbarer ist. Je mehr Sie Elastizität in Ihrer Anwendung automatisieren können, desto einfacher lässt sich Ihre Anwendung horizontal skalieren, wodurch sich die Vorteile des Betriebs in der Cloud erhöhen. In dieser Phase sollten Sie versuchen, Elastizität zu automatisieren. Nachdem Sie Ihre Anwendung in AWS verschoben und die einwandfreie Funktion sichergestellt haben, stehen Ihnen drei Optionen zur Verfügung, um Elastizität auf Batchebene zu automatisieren. Dies ermöglicht Ihnen das schnelle Starten einer beliebigen Anzahl von Anwendungs-­‐Instanzen, wenn Sie sie benötigen, und das Beenden, wenn Sie sie nicht mehr benötigen. Die Möglichkeit, die Anwendung zu aktualisieren, bleibt dabei erhalten. Wählen Sie den Ansatz, der am besten zu Ihrem Softwareentwicklungsprozess passt. 1. Verwalten des Bestands von AMIs Es ist einfach und schnell, ein Inventar von AMIs aller verschiedenen Konfigurationen einzurichten. Die Pflege (Upgrade, Patching) kann allerdings aufwendig sein,, da neuere Versionen von Anwendungen die Aktualisierung der AMIs erforderlich machen können. 2. Verwalten eines "Gold-­‐AMI" und Laden von Binärdateien beim Starten Dieser Ansatz ist etwas weniger aufwendig und verwendet ein Basis-­‐AMI ("Gold-­‐Image") für alle Anwendungstypen Der restliche Applikationsstack wird beim Starten der Instanz geladen und konfiguriert. 3. Verwalten eines gerade ausreichenden OS-­‐AMI und einer Bibliothek mit "Rezepten" oder Installationsskripts Dieser Ansatz ist wahrscheinlich am einfachsten zu verwalten – vor allem, wenn Sie eine Vielzahl an Anwendungsstacks bereitstellen müssen. Bei diesem Ansatz nutzen Sie die programmierbare Infrastruktur und verwalten eine Bibliothek mit Installationsskripten, die auf Anforderung ausgeführt werden. • Abbildung 6: Drei Optionen zum Automatisieren von Elastizität bei gleichzeitiger Aufrechterhaltung des Upgradevorgangs Seite 23 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Sicherheit verbessern Die Cloud entbindet Sie nicht von Ihrer Verantwortung, Ihre Anwendungen zu sichern. In jeder Phase Ihres Migrationsprozesses sollten Sie Best Practices für die Sicherheit implementieren. Dazu zählen unter anderem die folgenden: • Schützen Ihrer AWS-­‐Anmeldeinformationen • Wechseln Sie Ihre AWS-­‐Zugriffsinformationen immer regelmäßig und wechseln Sie sie sofort im Fall einer vermuteten Sicherheitsverletzung. • Nutzen Sie Multi-­‐Factor Authentication. • Zugriffsbeschränkung für Benutzer auf AWS-­‐Ressourcen • Erstellen Sie mithilfe der Funktionen von AWS Identity and Access Management (IAM) verschiedene Benutzer und Gruppen mit unterschiedlichen Zugriffsberechtigungen (Richtlinien), um den Zugriff auf bestimmte AWS-­‐Ressourcen zu beschränken bzw. zu gestatten. • Überprüfen und überwachen Sie fortlaufend IAM-­‐Benutzerrichtlinien. • Nutzen Sie die leistungsstarken Funktionen von Sicherheitsgruppen in Amazon EC2. • Schützen Ihrer Daten durch Verschlüsselung beim Speichern und bei der Übertragung (SSL) • Automatisieren Sie Sicherheitsrichtlinien. • Nutzen Sie die automatische Verschlüsselung beim Speichern der Daten in Amazon S3 und Amazon EBS. • Anwenden einer Wiederherstellungsstrategie • Erstellen Sie regelmäßige Amazon EBS-­‐Snapshots und stellen Sie sicher, dass die automatischen Amazon RDS-­‐Sicherungen eingeschaltet sind (was der Standard ist) . • Testen Sie Ihre Sicherungen von Zeit zu Zeit, bevor Sie sie benötigen Automatisieren des Software-­‐Entwicklungsprozesses und Upgradevorgangs in der Cloud In der AWS Cloud ist es nicht mehr erforderlich, neue Hardware lange im Voraus zu bestellen oder nicht verwendete Hardware zu horten, um Ihren Software-­‐Entwicklungsprozess zu unterstützen. Stattdessen können Entwickler, System-­‐ Builder und Tester die benötigte Infrastruktur in Minutenschnelle anfordern und von der umfangreichen Skalierung und kurzen Reaktionszeit der Cloud profitieren. Mit einer skriptfähigen Infrastruktur können Sie den Entwicklungs-­‐ und Bereitstellungszyklus Ihrer Software vollständig automatisieren. Sie können Ihre Entwicklungs-­‐, Build-­‐, Test-­‐, Staging-­‐ und Produktionsumgebungen verwalten, indem Sie wiederverwendbare Konfigurationstools erstellen, spezifische Sicherheitsgruppen verwalten und spezifische AMIs für jede Umgebung starten. Die Automatisierung Ihres Upgradevorgangs in der Cloud wird in dieser Phase dringend empfohlen, damit Sie schnell zu neueren Versionen der Anwendungen wechseln und bei Bedarf eine Zurücksetzung zu älteren Versionen durchführen können. Mit der Cloud müssen Sie keine neuen Softwareversionen auf alten Maschinen installieren, sondern können stattdessen alte Instanzen entfernen und neue, frisch vorkonfigurierte Instanzen erneut starten. Falls das Upgrade fehlschlägt, entfernen Sie es einfach und stellen ohne zusätzliche Kosten auf neue Hardware um. Seite 24 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Erstellen eines Dashboard Ihres elastischen Rechenzentrums zum Verwalten von AWS-­‐Ressourcen Es sollte für Entwicklungsingenieure und Projektmanager einfach und reibungslos möglich sein, AWS Cloud-­‐Ressourcen bereitzustellen. Gleichzeitig sollte das Managementteam Einblick in die Art und Weise haben, wie AWS-­‐Ressourcen genutzt werden. Die AWS Management Console stellt eine Ansicht Ihres Cloud-­‐Rechenzentrums bereit. Außerdem erhalten Sie grundlegende Verwaltungs-­‐ und Überwachungsfunktionen (über Amazon CloudWatch) für Ihre Cloud-­‐ Ressourcen. Die AWS Management Console wird ständig weiterentwickelt. Sie bietet eine umfangreiche Benutzeroberfläche für die Verwaltung von AWS-­‐Services. Wenn das aktuelle Design nicht Ihren Anforderungen entspricht, empfehlen wir Ihnen, die Verwendung von Drittanbieter-­‐Tools, mit denen Sie bereits vertraut sind (wie CA, IBM Tivoli), in Erwägung zu ziehen oder Ihre eigene Konsole zu erstellen, indem Sie die Web Service-­‐APIs verwenden. Mithilfe von Web-­‐Services-­‐API können Sie auf unkomplizierte Weise einen Webclient erstellen, der die Web-­‐Services-­‐API nutzt, und benutzerdefinierte Steuerkonsolen erstellen, die Ihren Anforderungen entsprechen. Wenn Sie beispielsweise eine Presales-­‐Demo-­‐Anwendungsumgebung in der Cloud für Ihr Vertriebsteam erstellt haben, damit sie eine vorkonfigurierte Anwendung in der Cloud schnell starten können, könnten Sie auch ein Dashboard erstellen, das die Aktivität der einzelnen Vertriebsmitarbeiter und Kunden anzeigt. Verwalten und beschränken Sie die Zugriffsberechtigungen auf Grundlage der Rolle des Vertriebsmitarbeiters und widerrufen Sie den Zugriff, wenn der Mitarbeiter das Unternehmen verlässt. In unserem Ressourcencenter stehen Ihnen viele verschiedene Bibliotheken zur Verfügung, die nützlich sein können, wenn Sie das Dashboard erstellen, das Ihren spezifischen Anforderungen entspricht. Erstellen eines Geschäftskontinuitätsplans und Erzielen einer hohen Verfügbarkeit (Nutzung verschiedener Availability Zones) Viele Unternehmen verfügen über keine ausreichende Notfallwiederherstellungsplanung, da der Vorgang nicht vollständig automatisch abläuft und die Kosten für die Unterhaltung eines separaten Rechenzentrums für die Notfallwiederherstellung prohibitiv hoch sind. Durch die Verwendung von Virtualisierung (Erstellung von AMI) und Daten-­‐Snapshots ist die Implementierung der Notfallwiederherstellung in der Cloud viel preiswerter und einfacher als die herkömmlichen Notfallwiederherstellungslösungen. Sie können den gesamten Vorgang des Startens von Cloud-­‐Ressourcen vollständig automatisieren, wodurch eine komplette Cloud-­‐Umgebung innerhalb von Minuten wiederhergestellt werden kann. Im Fall eines Failovers über die Cloud verläuft die Wiederherstellung nach einem Systemfehler genauso wie die Wiederherstellung nach einem Erdbeben. Daher wird dringend empfohlen, dass Sie über einen Geschäftskontinuitätsplan verfügen und sowohl Wiederherstellungsdauer (Recovery Time Objective, RTO) als auch den Zeitraum zwischen zwei Datensicherungen (Recovery Point Objective, RPO) festlegen. Ihr Geschäftskontinuitätsplan sollte Folgendes beinhalten: • eine Datenreplikationsstrategie (Quelle, Ziel, Häufigkeit) von Datenbanken (Amazon EBS) • eine Datensicherung-­‐ und -­‐Aufbewahrungsstrategie (Amazon S3 and Amazon RDS) • das Erstellen von AMIs mit den neuesten Patches und Codeaktualisierungen (Amazon EC2) • ein Wiederherstellungsplan für das Fallback von der Cloud zum Unternehmensrechenzentrum nach einem Notfall Eine in der Cloud implementierte Geschäftskontinuitätsstrategie bietet den Vorteil, dass Sie automatisch eine höhere Verfügbarkeit über verschiedene geografische Regionen und Availability Zones hinweg haben, ohne dass größere Änderungen bei den Bereitstellungs-­‐ und Datenreplikationsstrategien vorgenommen werden müssen. Sie können eine Umgebung mit einer viel höheren Verfügbarkeit erstellen, indem Sie die gesamte Architektur klonen und einer anderen Availability Zone replizieren oder indem Sie einfach Multi-­‐AZ-­‐Bereitstellungen (im Fall von Amazon RDS) verwenden. Seite 25 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Zusätzliche Informationen finden Sie im Whitepaper zur Verwendung von AWS bei einer Notfallwiederherstellung (Using AWS for Disaster Recovery)7. Phase 6: Optimierungsphase In dieser Phase sollten Sie sich darauf konzentrieren, wie Sie Ihre cloudbasierte Anwendung optimieren können, um höhere Kosteneinsparungen zu erzielen. Da Sie nur für die genutzten Ressourcen bezahlen, sollten Sie eine maximale Optimierung Ihres Systems anstreben. In den meisten Fällen schaffen Optimierungen unmittelbar Mehrwert. Eine kleine Optimierung kann zu Einsparungen in Höhe von mehreren tausend US-­‐Dollar in der nächsten Monatsrechnung führen. In dieser Phase können Sie die folgenden Fragen stellen: • Wie kann ich einige der anderen AWS-­‐Funktionen und -­‐Services nutzen, um weitere Kostensenkungen zu erzielen? • Wie kann ich die Effizienz meiner Installation steigern (und Verschwendung reduzieren)? • Wie kann ich meine Anwendungen organisieren, um einen besseren Einblick in meine bereitgestellten Anwendungen zu haben? Wie kann ich Metriken festlegen, um die Performance kritischer Anwendungen zu messen? • Verfüge ich über die erforderlichen cloudfähigen Systemadministrationstools für die Verwaltung und Wartung meiner Anwendungen? • Wie kann ich meine Anwendung und Datenbank optimieren, damit sie elastischer wird? Erfassung Ihrer Nutzungsmuster Mit der Cloud müssen Sie nicht die Kunst der Kapazitätsplanung beherrschen, da Sie eine automatisierte elastische Umgebung erstellen können. Wenn Sie Ihre Auslastungsmuster verstehen, überwachen, untersuchen und beobachten, können Sie diese elastische Umgebung effektiver verwalten. Sie können proaktiver sein, wenn Sie Ihre Datenmuster verstehen. Zum Beispiel, wenn Ihre in einer globalen AWS-­‐Infrastruktur bereitgestellte kundenseitige Website aus einem bestimmten Teil der Welt zu einer bestimmten Uhrzeit keinen Datenverkehr erwartet, können Sie Ihre Infrastruktur in dieser AWS-­‐Region für diesen Zeitpunkt nach unten skalieren. Je enger Sie Ihren Datenverkehr an den von Ihnen genutzten Cloudressourcen ausrichten, desto höher werden die Kosteneinsparungen ausfallen. Abschalten von nicht ausgelasteten Instanzen Überprüfen Sie regelmäßig die Systemlogs und Zugriffslogs, um sich über die Nutzungs-­‐ und Lebenszyklusmuster der einzelnen Amazon EC2-­‐Instanzen zu informieren. Beenden Sie Ihre nicht verwendeten Instanzen. Versuchen Sie, nicht ausgelastete Instanzen entbehrlich zu machen, um die Auslastung des gesamten Systems zu erhöhen. Sie können beispielsweise prüfen, ob eine Anwendung, die auf einer großen Instanz läuft, nicht besser auf zwei kleinere und günstigere Instanzen verteilt werden kann. Nutzung von reservierten Amazon EC2-­‐Instanzen Sie haben die Möglichkeit, gegen eine geringe einmalige Zahlung Instanzen zu reservieren, und erhalten im Gegenzug einen beträchtlichen Rabatt auf die stündliche nutzungsabhängige Gebühr für diese Instanz. Versuchen Sie, bei der Erfassung der Nutzungsmuster die Instanztypen zu ermitteln, die konstant ausgeführt werden, wie z. B. Datenbankserver oder Domänencontroller. Es gibt verschiedene Typen von reservierten Instanzen mit unterschiedlichen Vorauszahlungen und unterschiedlichen Rabatten. Diese können Sie kombinieren, um die Gesamtkosten zu optimieren. 7 Verfügbar unter http://media.amazonwebservices.com/AWS_Disaster_Recovery.pdf Seite 26 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Steigerung der Effizienz Die AWS Cloud bietet nutzungsabhängige Preise. Ihnen wird nur die von Ihnen genutzte Infrastruktur in Rechnung gestellt. Sie sind nicht für die gesamte vorhandene Infrastruktur verantwortlich. Dadurch eröffnen sich vollkommen neue Kosteneinsparungsmöglichketen. Sie können genau messbare Optimierungen für Ihr System einführen und die daraus resultierenden Einsparungen in der nächsten Monatsrechnung sehen. Wenn beispielsweise eine Caching-­‐Schicht Ihre Datenanforderungen um 80 % reduzieren kann, werden Sie die Einsparungen bereits in der nächsten Rechnung feststellen. Die Steigerung der Leistung der in der Cloud ausgeführten Anwendung kann ebenfalls zu Einsparungen bei den Gesamtkosten führen. Wenn Ihre Anwendung beispielsweise eine große Menge an Daten zwischen Amazon EC2 und Ihrem privaten Rechenzentrum überträgt, kann es sinnvoll sein, die Daten vor der Übertragung über die Datenleitung zu komprimieren. Dies kann zu erheblichen Kosteneinsparungen bei Datenübertragung und Datenspeicherung führen. Dasselbe Konzept trifft auch auf das Speichern von Rohdaten in Amazon S3 zu. Verwaltung und Wartung Fortschrittliche Überwachung und Telemetrie Implementieren Sie Telemetrie in Ihren Cloudanwendungen, um die erforderliche Transparenz in Bezug auf Ihre geschäftskritischen Anwendungen oder Services zu erhalten. Es ist wichtig, zu beachten, dass die Endbenutzer-­‐ Reaktionszeit Ihrer Anwendungen nicht allein von der Cloud-­‐Infrastruktur, sondern von verschiedenen Faktoren, wie z. B. ISP-­‐Konnektivität, Drittanbieter-­‐Services, Browser und Hops, abhängt. Durch das Messen und Überwachen der Leistung Ihrer Cloudanwendungen erhalten Sie die Möglichkeit, Leistungsprobleme proaktiv festzustellen und die zugrundeliegenden Ursachen zu identifizieren, um dann geeignete Maßnahmen zu ergreifen. Wenn beispielsweise ein Endbenutzer, der auf den nächstgelegenen Knoten Ihrer global gehosteten Anwendung zugreift, eine niedrigere Antwortrate feststellt, können Sie eventuell versuchen, mehr Webserver zu starten. Sie können sich Benachrichtigungen mithilfe des Amazon Simple Notifications Service (HTTP/E-­‐Mail/SQS) senden, wenn sich die Metrik (einer vorgegebenen AWS-­‐Ressource oder einer Anwendung) einem ungewünschten Schwellenwert nähert. Überwachung Ihrer AWS-­‐Nutzung und Logs Überwachen Sie regelmäßig Ihre AWS-­‐Nutzungsabrechnung, Service-­‐API-­‐Nutzungsberichte und Amazon S3-­‐ oder Amazon CloudFront-­‐Zugriffsprotokolle. Nutzen Sie dazu auch AWS CloudTrail, einen Web-­‐Service, der Aufrufe von AWS-­‐ APIs für Ihr Konto aufzeichnet und Protokolldateien an Sie übermittelt. Der AWS-­‐API-­‐Aufrufverlauf, der von CloudTrail generiert wird, ermöglicht eine Sicherheitsanalyse, Nachverfolgung von Ressourcenänderungen und Überwachung der Einhaltung von Vorschriften. Aufrechterhaltung der Sicherheit Ihrer Anwendungen Stellen Sie sicher, dass die Anwendungssoftware konsistent und immer auf dem neuesten Stand ist und dass Sie die neuesten Sicherheits-­‐Patches der jeweiligen Anbieter Ihrer Betriebssysteme und Anwendungen anwenden. Wenden Sie ein Patch auf ein AMI an, statt auf eine Instanz, und führen Sie häufig ein erneutes Deployment durch. Stellen Sie sicher, dass das neueste AMI für alle Ihre Instanzen verteilt wird. Umgestalten Ihrer Anwendung Um eine hoch skalierbare Anwendung zu erstellen, müssen einige Komponenten möglicherweise umgestaltet werden, damit sie optimal in einer Cloud-­‐Umgebung ausgeführt werden können. Manche bestehende Unternehmensanwendungen müssen eventuell umgestaltet werden, um eine elastische Ausführung zu ermöglichen. Einige Fragen, die Sie stellen können: Seite 27 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 • Können Sie Ihre Anwendung in ein AMI packen und bereitstellen, damit es auf einer Amazon EC2-­‐Instanz ausgeführt werden kann? Können Sie gegebenenfalls mehrere Instanzen der Anwendung auf einer EC2-­‐ Instanz ausführen? Oder können Sie mehrere Instanzen der Anwendung auf mehrere Amazon EC2-­‐ Instanzen verteilen? • Ist es möglich, das System so zu gestalten, dass es beim Auftreten eines Fehlers ausreichend stabil ist, um einen Neustart durchzuführen? • Können Sie die Anwendung in Komponenten aufteilen und diese auf separaten Amazon EC2-­‐Instanzen ausführen? Können Sie beispielsweise eine komplexe Webanwendung in einzelne Komponenten oder Web-­‐ , Anwendungs-­‐ und DB-­‐Schichten aufteilen und diese auf separaten Instanzen ausführen? • Können Sie zustandsbehaftete Komponenten extrahieren und sie zustandslos (stateless) machen? • Besteht die Möglichkeit einer Anwendungspartitionierung (Aufteilung der Lasten auf viele kleinere Maschinen anstelle weniger großer Maschinen)? • Ist es möglich, die Komponenten zu isolieren und mithilfe von Amazon SQS zu koppeln? • Können Sie Code von der Bereitstellung und Konfiguration entkoppeln? Aufteilen Ihrer relationalen Datenbank Die meisten herkömmlichen Unternehmensanwendungen verwenden in der Regel ein relationales Datenbanksystem. Datenbankadministratoren starten oft mit einem DB-­‐Schema auf Grundlage der Anweisungen des Entwicklers. Unternehmensentwickler setzen unbegrenzte Skalierbarkeit auf festen Infrastrukturen voraus und entwickeln die Anwendung entsprechend diesem Schema. Entwickler und Datenbankarchitekten tauschen sich unter Umständen nicht darüber aus, welche Art von Daten verarbeitet wird, wodurch es extrem schwierig wird, diese relationale Datenbank zu skalieren. Dies kann dazu führen, dass viel Zeit verschwendet wird, um Daten in eine "größere Box" mit mehr Speicherkapazität zu migrieren oder um sie zu Skalieren, damit mehr Rechenleistung verfügbar ist. Durch das Verschieben in die Cloud ergibt sich die Möglichkeit, das derzeitige Managementsystem für relationale Datenbanken (RDBMS) zu analysieren und es im Rahmen der Migration skalierbarer zu machen. Folgende Techniken können Ihnen helfen, Ihr RDBMS zu entlasten: • Große BLOBs und Mediendateien in Amazon S3 verschieben und den Namen (S3-­‐Schlüssel) in Ihrer bestehenden Datenbank speichern • Zugehörige Metadaten oder Kataloge in Amazon DynamoDB und Amazon CloudSearch verschieben • Nur die Daten behalten, die in der relationalen Datenbank absolut notwendig sind (Joins) • Alle relationalen Daten zu Amazon RDS verschieben, um die Flexibilität zu erhalten, die Datenverarbeitungs-­‐ und Speicherressourcen Ihrer Datenbank nur bei Bedarf über einen API-­‐Aufruf zu skalieren • Die gesamte Lesezugriffslast zu mehreren Lesereplikaten (Slaves) oder Amazon ElastiCache auslagern • Die Daten auf Grundlage von Element-­‐IDs oder -­‐Namen horizontal partitionieren Implementieren von Best Practices Implementieren Sie verschiedene Best Practices, die im Whitepaper "Architecting for the Cloud" beschrieben werden und schauen Sie sich die Hinweise an, die der AWS Trusted Advisor automatisch für Ihr Deployment erzeugt. Diese Best Practices helfen Ihnen nicht nur beim Erstellen einer hoch skalierbaren, für die Cloud geeigneten Anwendung, sondern unterstützen Sie auch beim Erstellen einer sichereren und elastischeren Anwendung. Seite 28 von 29 Amazon Web Services -­‐ Migrieren von Anwendungen in die AWS Cloud Oktober 2014 Zusammenfassung Die AWS Cloud gewährleistet Skalierbarkeit, Elastizität, Agilität und Zuverlässigkeit im Unternehmen. Um die Vorteile der AWS Cloud nutzen zu können, sollten Unternehmen eine phasenorientierte Migrationsstrategie anwenden und versuchen, so bald wie möglich von der Cloud zu profitieren. Die meisten Anwendungen können in die Cloud verschoben werden, unabhängig davon, ob es sich um eine typische dreistufige Webanwendung, eine nächtliche Batchverarbeitung oder einen komplexen Backend-­‐Verarbeitungs-­‐Workflow handelt. Der in diesem Dokument beschriebene Plan stellt einen bewährten, schrittweisen Ansatz für die Cloud-­‐Migration dar. Kunden, die diesen Plan einhalten und sich auf das Erstellen eines Machbarkeitsnachweises konzentrieren, werden die Vorteile in ihren Machbarkeitsnachweis-­‐Projekten unmittelbar feststellen und das gewaltige Potenzial der AWS Cloud erkennen. Nachdem Sie Ihre erste Anwendung in die Cloud verschoben haben, werden Sie weitere Möglichkeiten entdecken und die Vorteile erkennen, die das Verschieben weiterer Anwendungen in die Cloud bietet. Weitere Informationen 1. Migrationsszenario 1: Migrieren von Webanwendungen in die AWS Cloud 2. Migrationsszenario 2: Migrieren von Batchverarbeitungsanwendungen in die AWS Cloud 3. Migrationsszenario 3: Migrieren von Backend-­‐Verarbeitungs-­‐Pipelines in die AWS Cloud Seite 29 von 29
