(0) exportieren Drucken
Alle erweitern

Planen einer Migration zu Azure

Letzte Aktualisierung: April 2014

Wenn Sie mit der Migrationsplanung beginnen, sind zunächst mehrere wichtige Faktoren zu beachten, die für den Migrationsprozess maßgeblich sind. Dazu gehören Kosten, geschäftliche und technische Anforderungen, Zeitrahmen sowie Testverfahren. In diesem Abschnitt werden verschiedene Aspekte und Schritte erörtert, die Sie beachten sollten, während Sie eine Migration zu Azure planen:

Autoren: Steve Howard
Prüfer: James Podgorski, Paolo Salvatori, Selcin Turkarslan, Stuart Ozer

Die Kostenfrage ist einer der wichtigsten Faktoren. Sie sollte in einer frühen Phase des Entscheidungs- und Planungsprozesses geklärt werden, wenn die Migration einer lokalen Anwendung zu Azure in Betracht gezogen wird. Die Kostenermittlung bei einer Anwendung für Azure richtet sich nach einer Reihe von Faktoren, wie der Datenverkehrslast im Netzwerk, den Eingabe-/Ausgabemerkmalen der Anwendung sowie der von der Anwendung verarbeiteten Datenmenge. Die Preisberechnung wird nicht in diesem Thema behandelt. Es empfiehlt sich, zu Beginn der Migrationsplanung den Azure-Preisrechner zur Kosteneinschätzung zu Hilfe zu nehmen. Sie finden den Azure-Preisrechner hier.

Bei der Kostenberechnung für Ihr Unternehmen sollten Sie auch die direkten Azure-Kosten während der Entwicklungs- und Testphase einbeziehen. In einem lokalen Entwicklungsprojekt entstehen Kosten für Entwicklungs- und Testserver. Entsprechend fallen in der Azure-Umgebung Gebühren für die Ressourcen an, die Sie während der Entwicklungs- und Testphase nutzen. Darüber hinaus sollten Sie Schulungskosten und Kosten für das Portieren der Anwendung auf Azure berechnen. Leistungstests und eine Kapazitätsplanung sollten möglichst im Vorfeld durchgeführt werden, um die für die Anwendung benötigte Kapazität einschätzen zu können.

Azure bietet für einige geschäftliche und technische Anforderungen optimale Voraussetzungen. Ohne, dass diese Liste Anspruch auf Vollständigkeit erhebt, sind Anwendungen mit folgenden Merkmalen sehr gut für die Migration zu Azure geeignet:

  • Verteilte Benutzerbasis: Azure-Datencenter sind über verschiedene Kontinente verteilt. Da die Rechenzentren miteinander verbunden sind, können Daten bei Bedarf mit einem hochleistungsfähigen Mechanismus verteilt werden. Mithilfe von Azure-Funktionen wie Content Distribution Network (CDN) und Datensynchronisierungsdiensten können relevante oder stark genutzte Daten auf die Rechenzentren in der Nähe der Endbenutzer verteilt werden. Wenn Benutzer auf Rechenzentren in der Nähe ihres geografischen Standorts zugreifen können, wird die Länge des Roundtrips minimiert und folglich die Benutzerfreundlichkeit optimiert.

  • Variable Auslastung: Damit lokale Anwendungen zu Stoßzeiten Spitzenlasten bewältigen können, benötigen Sie Hardware. Beispielsweise erwirbt ein Einzelhändler in Erwartung eines regen Weihnachtsgeschäfts normalerweise zusätzliche Server. Ähnlich kann eine Buchhaltungsabteilung die Erweiterung der Infrastruktur planen, um Lastspitzen durch Abschlussbuchungen zum Monats- oder Jahresende zu bedienen. Die übrige Zeit sind die für Spitzenbelastungen angeschafften Server unterausgelastet. Andererseits können für flexible Skalierbarkeit ausgelegte Anwendungen Azure nutzen, um während Spitzenzeiten neue Anwendungsinstanzen online zu schalten und die Verarbeitungsleistung und -kapazität in Phasen mit geringeren Anforderungen wieder zurückzufahren. Mit der richtigen Anwendungsarchitektur und -verwaltung zahlen Sie bei Azure nur für das, was Sie brauchen.

  • Mehrinstanzenfähigkeit: Dienstanbietern stehen in Azure unterschiedliche Möglichkeiten zur Verfügung, Anwendungsdienste für eine beliebige Anzahl von Kunden in derselben Infrastruktur bereitzustellen und so die Betriebskosten zu minimieren.

  • Fokus auf Anwendungen: Insbesondere Dienstanbieter möchten ihre Ressourcen auf die Anwendungs- und Funktionsentwicklung und nicht auf die Infrastrukturverwaltung konzentrieren. Mit Azure entfällt ein Großteil des für lokal gehostete Infrastrukturen oder traditionelle servergehostete Anwendungen erforderlichen administrativen Mehraufwands. So können Sie Ihre Ressourcen stattdessen auf die Entwicklung von Anwendungen und Funktionen fokussieren.

  • Minimieren der Anforderungen von Infrastrukturressourcen: Bei der Entwicklung von Anwendungsarchitekturen, die in der Lage sind, die flexible Skalierbarkeit von Azure zu nutzen, können bei Bedarf auch Rollen- und Ressourceninstanzen zugeordnet werden. Es sind weder Anfangsinvestitionen in Hardware erforderlich, noch müssen in Zeiten niedriger Auslastung Server verwaltet werden, die für Spitzenauslastungen konzipiert sind.

Neben den bekannten Vorteilen des PaaS-Modells (Platform as a Service) bietet Azure die Möglichkeit, virtuelle Computer zu hosten. Die virtuellen Computer sind unter jedem von Azure unterstützten Betriebssystem lauffähig und können Anwendungen auf die gleiche Weise wie in einer lokalen Umgebung ausführen. Eine Liste der unterstützten Betriebssysteme finden Sie unter Übersicht über virtuelle Computer in Azure. Virtuelle Computer können auch in eine größere Anwendungsarchitektur eingebunden werden, die Instanzen von Web- oder Workerrollen und andere Azure-Komponenten umfassen kann. Virtuelle Computer ermöglichen die Portierung von Diensten oder Anwendungsparts, die sich ansonsten u. U. nicht so einfach auf Azure portieren lassen. Weitere Informationen finden Sie unter Migrieren mit virtuellen Windows Azure-Computern.

In der Analyse- und Entwurfsphase sollten Sie feststellen, welche Anwendungen am stärksten von einem Umstieg auf Azure profitieren würden. Anschließend beginnen Sie mit dem Entwurf der Azure-Implementierung und des Implementierungsplans. In dieser Phase sollten Sie den Architekturentwurf gliedern und einen Zeitrahmen planen.

Zentrale Planungsfaktoren lauten:

  • Identifizieren Sie aktuelle Herausforderungen: Die folgende Liste enthält einige Beispiele für Herausforderungen, die bei der Planung eventuell erforderlicher Umstrukturierungen der Architektur berücksichtigt werden sollten:

    • Anwendungskomponenten, deren Leistung mit der aktuellen Auslastung und Architektur unter dem Normbereich liegt: Wenn eine SQL-Abfrage keine zufriedenstellende Leistung zeigt, sollten Sie sie vor der Migration bzw. weiteren Entwurfsschritten optimieren. Darüber hinaus sollten auch Komponenten auf Anwendungsebene umgestaltet und horizontal skaliert werden.

    • Anforderungen für flexible Skalierbarkeit: Sie sollten ermitteln, wie die Anwendung in funktionale, unabhängig skalierbare Einheiten, die unabhängig voneinander ausführbar sind, zerlegt werden kann.

    • Ungleichmäßige Auslastungsmuster: Sie sollten ungleichmäßige Auslastungsmuster identifizieren und zur Bewältigung hoher Lastwerte horizontale Skalierung in die Anwendung integrieren. Sie sollten einplanen, auf welche Weise der Grad der horizontalen Skalierung zwischen Phasen mit hoher und Phasen mit geringer Auslastung angepasst wird.

    • Wachstumsprognosen: Wachstumsprognosen dienen der IT-Abteilung als erstes Anzeichen für einen möglicherweise erforderlichen Paradigmenwechsel. Finden Sie heraus, in welchen Fällen horizontale Skalierung eine Lösung für das prognostizierte Wachstum sein könnte. Das erwartete Wachstum kann auch ein Indikator dafür sein, dass in bestimmten Data Warehouse-zentrierten Anwendungen beispielsweise ein Paradigmenwechsel zu Big Data-Analyselösungen in Betracht gezogen werden sollte. Diese Möglichkeiten sollten in der Planungsphase erörtert werden. Bedenken Sie, dass sich die endgültige Lösung möglicherweise erst später im Entwurfs- und Implementierungsprozess herauskristallisieren kann. Derartige Unsicherheits- und Einflussfaktoren sollten aufgelistet und zu einem geeigneten Zeitpunkt, beispielsweise bei der anfänglichen Migration oder später, ausgewertet werden.

  • Identifizieren Sie technische Anforderungen: Ermitteln Sie die Anforderungen der einzelnen Anwendungskomponenten zu Haupt- und Nebenzeiten. Planen Sie die Skalierung jeder einzelnen Komponente. Möglicherweise verfügen einzelne Komponenten über unterschiedliche Skalierungsfähigkeiten und -mechanismen. Technische Anforderungen müssen nicht auf die Leistung beschränkt sein. Beispielsweise sollten bei der Planung einer Migration die Voraussetzungen für HADR (High Availability and Disaster Recovery) oder maximale Netzwerklatenz bestimmt und mit den Funktionen von Azure verglichen werden. Die folgende Liste enthält einige Beispiele für technische Anforderungen:

    • Verwendung von relationalem Speicher: Verschaffen Sie sich einen Überblick über die in den relationalen Datenbanken gespeicherten Daten. Daten, die tatsächlich transaktionsgebunden und relational sind oder eine echte Transaktionsverarbeitung erfordern, sollten im relationalen Speicher verbleiben. Diese Art von Daten kann auf einem Azure SQL-Datenbankserver (SQL-Datenbank) oder auf virtuellen Computern gespeichert werden, auf denen SQL Server ausgeführt wird. Andere Arten von Daten können effizient in Azure-Tabellen, Azure-BLOB-Speichern oder Azure-Laufwerken gespeichert werden. Es empfiehlt sich, den für die jeweiligen Daten erforderlichen Speichertyp zu ermitteln.

    • Auswählen des relationalen Datenspeichers: Die Entscheidung für eine SQL-Datenbank oder für SQL Server auf virtuellen Azure-Computern richtet sich nach mehreren Faktoren. Wenn Sie auf den administrativen Mehraufwand in Verbindung mit hoher Verfügbarkeit, Lastenausgleich und transparentem Failover verzichten möchten, ist eine SQL-Datenbank die beste Wahl. Während der Migration einer Anwendung oder in Sonderfällen, in denen Funktionen in einer SQL-Datenbank noch nicht verfügbar sind, ist SQL Server auf virtuellen Azure-Computern u. U. jedoch die beste Zwischenlösung. Die Beantwortung dieser Fragen ist situations- und lösungsbedingt. Die folgende Liste enthält einige Überlegungen zu diesem Thema:

      • Datenbankgröße: Azure SQL-Datenbanken sind zurzeit auf eine Datenmenge von 5 GB für die Web Edition-Datenbank und auf 150 GB für die Business Edition-Datenbank beschränkt. Wenn Sie die Kapazität der Datenbank erweitern möchten, verwenden Sie ein Verfahren für horizontale Skalierung. Weitere Informationen zu den Verfahren für horizontale Skalierung in Azure finden Sie unter "Horizontale Skalierung von Windows Azure SQL-Datenbanken". Neueste Informationen zu verfügbaren Datenbankeditionen und -größen finden Sie unter Konten und Abrechnung für Azure SQL-Datenbanken.

      • Anzahl der Datenbanken: SQL-Datenbanken unterstützen standardmäßig bis zu sechs Server pro Abonnement und 150 Datenbanken in jedem SQL-Datenbankserver einschließlich der master-Datenbank. Eine Erweiterung dieser Begrenzung ist möglich. Weitere Informationen erhalten Sie von einem Kundendienstmitarbeiter im Microsoft Online Services-Kundenportal.

      • Datenbankübergreifende Abfragen: SQL-Datenbanken unterstützen zurzeit keine datenbankübergreifenden Joins oder Abfragen. Bei Unions oder Joins, für die Daten aus mehr als einer SQL-Datenbank erforderlich sind, muss diese Logik in der Anwendungsebene der Anwendung ausgeführt werden.

      • CLR-Objekte (Common Language Runtime): SQL-Datenbanken unterstützen zurzeit keine CLR-Aggregationen, -Trigger, -Funktionen oder gespeicherten CLR-Prozeduren. Zur Ausführung in einer SQL-Datenbank sollten Sie gespeicherte Prozeduren, Trigger oder Funktionen in Transact-SQL portieren. Komplexe Logik oder Vorgänge, wie Aggregationen, die in Transact-SQL nicht auf Datenbankebene ausgeführt werden können, sollten in die Anwendungsebene verschoben werden. Derartige Schritte können Sie mithilfe einer Workerrolle ausführen.

      • Datentypen: Einige SQL Server-Systemdatentypen werden von SQL-Datenbanken nicht unterstützt. Neueste Informationen finden Sie unter Datentypen (Azure SQL-Datenbank) in der MSDN Library zu SQL.

      • Replikation: Replikationstypen wie die Transaktionsreplikation oder Mergereplikation sind in SQL-Datenbanken nicht verfügbar. können aber in der auf den virtuellen Azure-Computern ausgeführten SQL Server-Software eingerichtet und ausgeführt werden. Mithilfe der SQL-Datensynchronisierung können Daten zwischen SQL-Datenbankinstanzen synchronisiert werden. Falls Transaktionskonsistenz oder komplexe Konfliktlösungen erforderlich sind, liefert der SQL-Datensynchronisierungsdienst möglicherweise keine zufriedenstellenden Ergebnisse. Warnung: Die SQL-Datensynchronisierung wird zurzeit nur als Preview zur Verfügung gestellt, um Produktfeedback für zukünftige Versionen zu sammeln. Sie sollte nicht in Produktionsumgebungen eingesetzt werden.

      • Volltextsuche: Azure SQL-Datenbanken unterstützen zurzeit keine Volltextsuche. Wenn die Anwendung Volltextabfragen für Zeichendaten in SQL Server-Tabellen ausführt, sollten Sie die Migration der Datenbank in einem virtuellen Azure-Computer mit SQL Server in Betracht ziehen. Weitere Informationen zu SQL Server auf Azure-VMs finden Sie unter Migrieren zu SQL Server auf einem virtuellen Azure-Computer.

      • Lizenzierung: In SQL-Datenbanken werden monatliche Gebühren für die gewählte Datenbankgröße erhoben. Bei der Ausführung auf einem virtuellen Azure-Computer wird für SQL Server eine Lizenz benötigt.

      • Anmeldung und Sicherheit: Die Windows-Authentifizierung (integrierte Sicherheit) wird in SQL-Datenbanken nicht unterstützt, kann jedoch für SQL Server auf virtuellen Azure-Computern genutzt werden. Weitere Sicherheitsrichtlinien sowie Einschränkungen von SQL-Datenbanken finden Sie unter Sicherheitsrichtlinien für und Einschränkungen von Azure SQL-Datenbanken.

      • Funktionsparität: Weitere Informationen zu Ähnlichkeiten und Unterschieden zwischen SQL Server und SQL-Datenbanken finden Sie unter SQL Database Overview.

  • Anmeldung und Benutzersicherheit: Mithilfe der neuen Netzwerkerweiterungen für Azure kann eine Active Directory-Domäne aus dem lokalen Netzwerk auf Azure erweitert werden. Weitere Informationen finden Sie unter Migrieren mit virtuellen Windows Azure-Computern. Ausführliche Informationen zur Sicherheitsverwaltung in SQL-Datenbanken finden Sie unter Verwalten von Datenbanken und Anmeldungen in der Azure SQL-Datenbank.

  • Aufgliederung von Anwendungsfunktionen: Ermitteln Sie, an welchen Stellen die Anwendung in funktionale Einheiten zerlegt werden kann, damit sie in getrennten Azure-Rollen oder auf getrennten virtuellen Computern ausgeführt werden kann. Auf diese Weise erzeugen Sie eine flexible Skalierbarkeit und schaffen gleichzeitig Unterstützung für Hybridanwendungen, falls einige Anwendungen für das Cloud Computing ungeeignet sind.

  • PCI-Anforderungen (Payment Card Industry) und andere rechtliche Ansprüche: Vor der Migration einer Anwendung oder einer Komponente in Azure überprüfen Sie den aktuellen Status erforderlicher Zertifizierungen oder Voraussetzungen. In Fällen, in denen beispielsweise PCI-Compliance erforderlich ist, haben Sie die Möglichkeit, bestimmte Bereiche aus der zu Azure migrierten Anwendung und Datenbank zu entfernen und eine Hybridanwendung auszuführen. So profitiert ein Großteil der Komponenten von Azure und Cloud Computing, während die Teile der Daten und Anwendung, die eine straffe institutionelle Kontrolle sowie Compliance erfordern, überwacht werden können.

  • Wichtige Komponenten, die nicht in Azure Platform gehostet werden können: Einige Komponenten bzw. Arten von Daten können aus anderen Gründen u. U. nicht in der öffentlichen Cloud gehostet werden. Ermitteln Sie diese Komponenten, und ziehen Sie eine Hybridanwendung in Betracht. Bei Verwendung einer Hybridarchitektur können einige Komponenten in Azure gehostet werden, um alle Vorteile von Azure und Cloud Computing auszuschöpfen. Gleichzeitig können die Teile der Daten und Anwendung, die eine straffe institutionelle Kontrolle sowie Compliance erfordern, überwacht werden.

Sobald Sie den Umfang der Migration definiert haben, wird auch der für jeden Schritt im Migrationsplan erforderliche Arbeitsaufwand deutlich. Betrachten Sie jede Anwendung und Datenkomponente, um einzuschätzen, wie viel Zeit und Ressourcen für Entwicklung, Tests und Migration benötigt werden. Wenn Sie die Anwendung in Funktionen zerlegen, entwickeln Sie diese zerlegten Komponenten parallel, um flexibel skalierbare Komponenten zu erzeugen.

Legen Sie Projektmeilensteine, z. B. Funktions- und Leistungstests, sowie Veröffentlichungstermine im Migrationsplan fest. Die Migration kann schrittweise und in Iterationen verlaufen, beispielsweise mit der Fertigstellung der einzelnen Komponenten für Azure oder mit der Überführung der Komponenten in Azure-Webrollen und -Workerrollen.

Sobald der Zeitrahmen für die Entwicklung und Migration aufgestellt ist, erstellen Sie einen Wachstumsplan für diesen Zeitraum und entscheiden, welche Änderungen an der vorhandenen Anwendung und Infrastruktur nötig sind. Bei dieser Planungsweise kann der bisherige Systembetrieb aufrechterhalten werden, bis die Migration abgeschlossen ist. Stellen Sie sich bei der Konzeption des Zwischenplans folgende Fragen: Welche Schwachstellen gibt es derzeit, wie wird ein unterbrechungsfreier Betrieb sichergestellt und in welchem Umfang kann der Betrieb mit der Übergangsinfrastruktur fortgesetzt werden? Identifizieren Sie zusätzlich Schritte, die für die Fortführung des Betriebs erforderlich sein können. Oft muss einfach nur eine SQL-Abfrage optimiert oder ein Webserver für eine bestimmte Anwendung hinzugefügt werden. Erarbeiten Sie Notfallpläne für unerwartet schnelles Wachstum oder unvorhergesehene Leistungsanforderungen. Fragen Sie sich bei der Notfallplanung, ob höhere Leistungsanforderungen bzw. ein schnelleres Wachstum durch die horizontale Skalierung auf virtuelle Azure-Computer bewältigt werden könnten. In diesem Fall kämen Sie ohne zusätzliche Hardwareinvestitionen aus.

Jeder Migrationsplan sollte Pläne für umfassende Funktionalitätstests und Auslastungstests vorsehen. Eine Beschreibung der Testmethoden geht über den Rahmen dieses Artikels hinaus. Die folgende Liste enthält wichtige Punkte, die beim Testen beachtet werden sollten:

  • Automatisieren Sie Testskripts

  • Testen Sie alle Ebenen und Komponenten der Anwendung

  • Legen Sie Aktivitätsraten zugrunde, die realen Systembedingungen entsprechen

  • Führen Sie Tests bis zum maximal erwarteten Auslastungsgrad und darüber hinaus aus

Planen Sie Zeit für die Entwicklung und Ausführung der Testverfahren sowie zur Behebung der gefundenen Probleme ein.

Benennen Sie beim Festlegen der geschäftlichen und technischen Anforderungen die Ressourcen, die für eine erfolgreiche Migration benötigt werden. Möglicherweise müssen sie für die Migration rekrutiert bzw. erworben werden. Die Ressourcen teilen sich in drei primäre Bereiche auf:

  • Personal: Möglicherweise benötigen Sie zusätzliche Mitarbeiter mit speziellen Fachkenntnissen, um die Anwendung erfolgreich zu migrieren. Nach der Migration sehen sich technische Mitarbeiter u. U. mit neuen Aufgaben konfrontiert, die ein Umlernen erfordern. Beispielsweise könnte die Funktion von Kontoadministratoren und Dienstadministratoren bei der Verwaltung von Anmeldungen, Zugriffsebenen, Dienstebenen und Skalierungsebenen überdacht werden.

  • Tools: Bestimmen Sie die Tools, die zum Entwickeln, Testen und Bereitstellen der Azure-Anwendung erforderlich sind. Weitere Informationen finden Sie unter Azure Tools für Microsoft Visual Studio und Tools und Hilfsprogramme für Azure SQL-Datenbanken.

  • Beratung: Sie benötigen u. U. spezielles Know-how zum Migrieren der Anwendung. Ein Migrationsexperte kann Ihnen viel Zeit und Geld ersparen, indem er Sie vor häufigen Migrationsfehlern bewahrt.

Bei kleineren Anwendungen reicht das Azure-Verwaltungsportal möglicherweise für die Verwaltung von Azure-Bereitstellungen aus. Mit dem Azure-Verwaltungsportal können Sie sich anmelden und die Bereitstellungen und Anwendungen verwalten sowie die Anzahl der Instanzrollen ändern und SQL-Datenbankinstanzen verwalten. Für komplexere Anwendungen und Anwendungen, die Dienste für Kunden bereitstellen, ist das Azure-Verwaltungsportal möglicherweise nicht ausreichend.

Azure macht die REST-API verfügbar, um Ihnen die programmgesteuerte Verwaltung von Anwendungen und VMs zu ermöglichen, die in Azure gehostet werden, sowie die Bereitstellung und Verwendung des Azure-Speichers. Sie können eine Verwaltungsschnittstelle für die Skalierung und Überwachung der Azure-Umgebung programmieren. Der Migrationsplan sollte einen Plan zur Verwaltung der Anwendung nach der Migration enthalten, und zwar insbesondere dann, wenn die Verwaltung eine benutzerdefinierte Schnittstelle oder Automatisierung umfasst.

Weitere Informationen darüber, wie Sie Azure-Bereitstellungen mithilfe der REST-API verwalten, finden Sie unter API-Referenzen für Azure.

Siehe auch

Anzeigen:
© 2014 Microsoft