Migrieren von Anwendungen in die AWS Cloud Ein phasenorientierter Ansatz für die Cloud- Migration

Transkript

1 Migrieren von Anwendungen in die AWS Cloud Ein phasenorientierter Ansatz für die Cloud- Migration Jinesh Varia Jan Metzner Oktober 2010 Aktualisiert: Seite 1 von 29

2 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 Motivation für Migration Firma A Webanwendung Marketing- und Skalierbarkeit u. Collaboration- Website Elastizität Firma B Firma C Batchverarbeitungs- Pipeline Backend- Bearbeitungsablauf Digital Asset Management- Lösung Schadenbearbeitungssystem Reduzierung der Produkteinführungszeit Geringere TCO, Redundanz Zusätzliche Vorteile Auto Scaling, proaktive ereignisbasierte Skalierung Automatisierung und gesteigerte Entwicklungsproduktivität Geschäftskontinuität und Schutz vor Kapazitätsüberschreitung Verwendete Services EC2, RDS, S3, CloudFront EC2, S3, SQS, DynamoDB SWF, EC2, S3 Seite 2 von 29

3 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 Practices 1 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

4 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

5 Phasen Nutzen der Cloud 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 Optimieren der Nutzung je nach Anforderung Steigern der Effizienz Implementieren fortschrittlicher Überwachung und Telemetrie Umgestalten Ihrer Anwendung Aufspalten Ihrer relationalen Datenbanken Vorteile 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 cloud 2 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 Seite 5 von 29

6 Preise Einmalige Vorauszahlung Monatlich AWS Co- Location Vor Ort AWS Co- Location Serverhardware 0 $$$ $$ $$ 0 0 Netzwerkhardware 0 $$ $$ Hardwarewartung 0 $$ $$ 0 0 $ Software Betriebssystem 0 $$ $$ $ 0 0 Strom und Kühlung 0 0 $$ 0 $$ $ Rechenzentrum/Co- Location 0 $$ $$ 0 $ 0 Administration 0 $$ $$ $ $$ $$$ Speicher 0 $$ $$ $ 0 0 Bandbreite 0 $$ $ $$ $ $ Ressourcenverwaltungssoftware $ $ $ Support täglich rund um die Uhr $ $ $ Vor Ort Gesamt 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

7 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

8 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 Auth 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: DB Suche ERP LDAP- Servic BI DW Protok olle 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

9 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 DB CR M Such e We b ERP LDAP - BI Aut h Proto kolle D Suc he We b OLA P Engi ne Beric hte 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

10 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

11 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 Whitepaper 3 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 Seite 11 von 29

12 Erfolgskriterien Alt Neu Beispiele, wie gemessen wird Kosten (Investitionsaufwand) Kosten (Betriebsaufwand) Hardware- Beschaffungseffizienz 1 Mio. USD USD 60 % Einsparungen bei Investitionsaufwand in den nächsten 2 Jahren USD/Jahr USD/Jahr Server-/Mitarbeiter-Verhältnis um Faktor 2 verbessert 4 Wartungsverträge beendet 10 Maschinen in 7 Monaten 100 Maschinen in 5 Minuten 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 Flexibilität Neue Möglichkeiten Feste Größe des Anwendungsstacks Rückstand von 10 Projekten Erstellen einer Roadmap und eines Plans Beliebige Größe des Anwendungsstacks Kein Rückstand, 5 neue Projekte in Planung Tabelle 2: Beispiele, wie Erfolgskriterien gemessen werden 20 % weniger Supportanrufe im Zusammenhang mit dem Betrieb Nicht an einen bestimmten Hardwareanbieter oder eine bestimmte Plattform oder Technologie gebunden 25 neue Projekte in 3 Monaten begonnen 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

13 Informaconen über Amazon S3 Bucket erstellen Ein Objekt hochladen Eine CloudFront- Verteilung erstellen Eine signierte URL erstellen AMI anpassen AMI bündeln Eine angepasste AMI starten AMI starten Informaconen über Sicherheitsgruppen Verschiedene Availability Zones testen Informaconen über Amazon EC2 EBS- Volume erstellen Elascsche IP erstellen Volume verbinden DNS zu elascscher IP zuordnen Snapshot eines Volumes erstellen Snapshot wiederherstellen Informaconen über Amazon RDS Eine DB- Instanz starten Eine Sicherungskopie anlegen 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: Informaconen über IAM Gruppen erstellen Benutzer erstellen Eine Richtlinie erstellen Neue Anmelde- informaconen für den Zugriff erstellen Informaconen über Ressourcen und Bedingungen Benutzer zu Gruppen zuweisen 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

14 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

15 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 Seite 15 von 29

16 Kennenlernen der verschiedenen Speicheroptionen in der AWS Cloud Die nachstehende Tabelle hilft Ihnen bei der Auswahl der richtigen Speicheroption: Ideal für Amazon S3 + Amazon Glacier + CloudFront Speichern größerer Objekte, Verteilung statischer Inhalte, Datenarchivierung Amazon EC2 Ephemeral Storage Speichern von kurzlebigen Daten Speicheroptimierte Instanzen für sehr hohe Random-E/A- Leistungen (SSDgestützt) oder mit hoher Speicherdichte für hohe squenzielle Leistung Amazon EBS Amazon RDS Amazon DynamoDB 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 Amazon Redshift Speichern und Abfragen von strukturierten Daten im Petabyte- Bereich Ideale Beispiele Mediendateien, Audio, Video, Bilder, Sicherungen, Archive, Versionierung Konfigurationsdat en, Scratch- Dateien, temporäre Dateien Speicheroptimiert e Instanzen für NoSQL- Datenbanken oder andere Anwendungen mit hoher Random- E/A-Leistung 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 Tabelle 3: Datenspeicheroptionen in der AWS Cloud Statische Daten, webbasierter Inhalt, Key- Value Daten Einfache Key- Value Daten, BLOBs, Dateisysteme. BLOBs, Dateisysteme, Inhaltsverteilung Joins oder Transaktionen Kleine Datenmengen Seite 16 von 29

17 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: Amazon RDS/Amazon Redshift RDBMS AMIs Drittanbieter- Datenbankservice RDBMS Oracle 11g, MySQL, PostgreSQL, Microsoft Oracle 11g, Microsoft SQL Server, MySQL, Verschiedene Anbieter im AWS Marketplace SQL Server, Amazon Redshift IBM DB2, Sybase, Informix, PostgreSQL Support von AWS Premium Support AWS und Anbieter Anbieter Verwaltet von AWS Ja Nein Nein Preise Nutzungsabhängig BYOL, Nutzungsabhängig Verschiedene Skalierbarkeit Datenverarbeitung und Speicher mit einem einzigen API-Aufruf oder Klick skalieren Tabelle 4: Optionen für relationale Datenbanken Manuell Migrieren Ihrer SQL- Datenbanken zu Amazon RDS Verschieden/ hängt vom Anbieter ab 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

18 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

19 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 Suche Service, Geschäftskomponente oder eine Funktion, die aus einem Anwendungscode, einer Geschäftslogik, einer Datenzugriffsschicht und Datenbank besteht Buch- haltung Prozess Suche Suche Dünne Schicht mit "cloudfähigem" zu schreibendem Code, die die Webservices- Schnittstelle der Komponente benutzt; besteht aus Stubs/Skeletons Buch- haltung Seite 19 von 29

20 Prozess Buch- haltung Suche Buch- haltung Suche 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