(0) exportieren Drucken
Alle erweitern

Übersicht des Migrationslebenszyklus in Azure

Letzte Aktualisierung: April 2014

Der Migrationslebenszyklus ist eine Standardmethodik mit schrittweisen Anweisungen zum Migrieren von Anwendungen und Daten zu . Die Hauptmigrationsschritte sind die Analysephase, Anwendungsmigrationsphase, Datenmigrationsphase, Test- und Optimierungsphase und Inbetriebnahme- und Verwaltungsphase, wie aus dem folgenden Diagramm ersichtlich.

In diesem Thema werden die einzelnen Phasen ausführlich erläutert und Links zu weiteren Informationen bereitgestellt.

unterstützt auch Oracle auf virtuellen Computern in . Weitere Informationen finden Sie unter Oracle-Images für virtuelle Azure-Computer.

Autoren: Kun Cheng, Selcin Turkarslan, Norberto Garcia
Prüfer: Paolo Salvatori, Steve Howard, Stuart Ozer

Das Ziel dieser Phase besteht darin, die Geschäftsanforderungen zu ermitteln, die mit der -Lösung erfüllt werden können. Nachdem Sie die Geschäftsziele ermittelt haben, überprüfen Sie die vorhandene Anwendungsarchitektur, um die Hauptunterschiede zwischen -Lösungen und lokalen Lösungen herauszustellen und zu entscheiden, ob die vorhandene lokale Anwendung umgestaltet werden muss, um die Geschäftsanforderungen einer -Lösung zu erfüllen. Die folgenden Aufgaben und Fragen unterstützen Sie bei der Aufstellung eines Migrationsplans:

  • Definieren Sie Geschäftsanforderungen: Es ergeben sich viele mögliche Fragen aus Geschäftsszenarien, wenn eine Anwendung in ausgeführt wird:

    • Ist die -Bereitstellungslösung auf neue Kunden und Benutzer ausgerichtet?

    • Ist Mehrinstanzenfähigkeit erforderlich, um mehrere Kunden zu unterstützen?

    • Erfüllt die Anwendung die Genehmigungsregelungen, wenn die Daten in den Microsoft-Rechenzentren anstatt auf den Kundenwebsites gehostet werden?

    • Welche Anwendungen eignen sich hinsichtlich der Architektur und Strategie besser für die Cloud?

    • Welcher Migrationstyp ist am besten für die Anwendung geeignet?: Die Migration einer vollständigen Anwendung und aller Abhängigkeiten in ; oder die Migration eines Teils der Anwendung in die Cloud, während einige Ressourcen in der lokalen Umgebung verbleiben, oder die Migration einer Anwendung in Web- oder Workerrollen mit Abhängigkeiten, die besser auf einem virtuellen Computer in unterstützt werden.

    Die Antworten auf diese Fragen wirken sich auf den Entwurf des Anwendungsverhaltens für die Platform aus.

  • Bestimmen Sie Funktionsunterschiede: Kann die vorhandene Anwendung unverändert in ausgeführt werden? -SQL-Datenbanken ("SQL-Datenbank") unterstützen z. B. nicht alle Funktionen einer lokalen SQL Server-Version. Wenn Sie eine lokale Anwendung, die CLR (Common Language Runtime) verwendet, zu einer SQL-Datenbank migrieren möchten, müssen Sie die Anwendung umgestalten, indem Sie die CLR-Logik von SQL Server in die Anwendungsebene umlagern oder die CLR-Logik unter Verwendung der von der SQL-Datenbank unterstützten Transact-SQL-Anweisungen umschreiben. Beachten Sie, dass SQL CLR von SQL-Datenbanken derzeit nicht unterstützt wird.

    Ab Version 2012 wurde durch neue Funktionen für virtuelle Computer erweitert. Mit virtuellen Computern in können Sie die vorhandenen SQL Server-Anwendungen, die auf der Windows Server-Plattform erstellt wurden, mit minimalen oder überhaupt keinen Codeänderungen zur Platform migrieren. Wird SQL Server auf einem virtuellen Computer in eingesetzt, können Administratoren und Entwickler weiterhin dieselben Entwicklungs- und Verwaltungstools wie in der lokalen Umgebung verwenden. Die Leistung einer relationalen Datenbank auf einem virtuellen Computer hängt von vielen Faktoren ab, z. B. der Größe des virtuellen Computers, der Anzahl und Konfiguration der Datenträger, dem Netzwerk, der Konfiguration der Datenbanksoftware und der Arbeitsauslastung der Anwendung. Entwicklern wird empfohlen, ihre Anwendung auf virtuellen Computern unterschiedlicher Größen und mit unterschiedlicher Speicherkonfiguration zu testen, um die optimale Lösung zu finden. Weitere Informationen finden Sie unter Migrieren zu SQL Server auf einem virtuellen Azure-Computer.

  • Bereiten Sie einen Plan für Leistung und Skalierbarkeit vor: Viele ältere Anwendungen wurden für die enge Integration zwischen der Anwendungslogik und den Datenzugriffskomponenten entworfen. Bei älteren Anwendungen ist es sinnvoll, Anwendungskomponenten zu entkoppeln, um in eine bessere Leistung und Skalierung zu erzielen. Wenn die Anwendung zu "geschwätzig" ist oder zu viele Datenabfragen ausführt, könnten Sie den Azure-Cachedienst verwenden oder einen eigenen Cachingmechanismus implementieren, um Datenzugriffsabfragen in Batches zusammenzufassen und Roundtrips zwischen der Anwendung und den Daten zu reduzieren. Wenn die zu migrierende Anwendung umfangreiche Datenbanken oder ein hohes Transaktionsaufkommen verarbeiten muss, erfordert die Migration zu einer SQL-Datenbank wahrscheinlich eine Umgestaltung des Datenbankmodells. Das liegt daran, dass eine einzelne SQL-Datenbankinstanz eine begrenzte Anzahl von Transaktionen pro Sekunde bewältigen kann und über eine beschränkte Datenbankgröße verfügt. Bei großen Datenbanken oder einem hohem Transaktionsumfang sollten Sie die Implementierung einer Architektur für horizontales Skalieren unter Verwendung mehrerer SQL-Datenbanken in Betracht ziehen oder direkt Verfahren für horizontales Skalieren anstelle teurer lokaler Systeme verwenden, die vertikal skaliert sind. Wenn Sie In-Memory OLTP oder verzögerte Dauerhaftigkeit für Tabellen mit hohem Transaktionsvolumen implementieren, können Sie dadurch ebenfalls die Leistung steigern. Weitere Informationen zu In-Memory OLTP finden Sie unter In-Memory OLTP (Arbeitsspeicheroptimierung). Weitere Informationen zur verzögerten Dauerhaftigkeit finden Sie unter Vorgehensweise: Steuern der Transaktionsdauerhaftigkeit.

    Weitere Informationen zu Leistungsüberlegungen bei Verwendung von SQL Server auf einem virtuellen Computer finden Sie unter Leistungsüberlegungen für SQL Server auf virtuellen Azure-Computern und im Whitepaper Leitfaden zur Leistung für SQL Server auf virtuellen Azure-Computern.

    Von der -SQL-Datenbank wurde eine eingeschränkte Premium-Vorschau für die SQL-Datenbank freigegeben. Indem eine feste Kapazität für die SQL-Datenbank und zugehörige sekundäre Replikate reserviert wird, liefert der Premium-Dienst eine
besser vorhersagbare Leistung im Vergleich zu bestehenden Web oder Business Editionen der SQL-Datenbank. Weitere Informationen zu Premium-Konten für die SQL-Datenbank finden Sie unter Verwalten einer Premium-Datenbank und Leitfaden für die Premium-Vorschau der SQL-Datenbank.

  • Bereiten Sie einen Plan zur Verwaltung des Anwendungslebenszyklus vor: Es ist wichtig, sich die Anwendungsversionsverwaltung sowie Upgradeszenarien in zu vergegenwärtigen. Abhängig von Ihrer Vereinbarung zum Servicelevel müssen Sie u. U. mehrere Versionen der Anwendung beibehalten, um unterschiedliche Kundenschichten zu unterstützen. Beim Aktualisieren einer Anwendung in möchten Sie möglicherweise auch die Downtime minimieren. Es empfiehlt sich, die Staging- und Produktionsumgebung in mit Sorgfalt zu verwalten. Stellen Sie sicher, dass Sie bei Kompatibilitätsproblemen Rollbacks für Upgrades ausführen können. Im Plan für das Rollback von Upgrades sollte zuerst die Anwendung und dann die Datenbank berücksichtigt werden.

Nach dieser Phase empfiehlt es sich, ein Pilotprojekt aufzusetzen, um einen klaren Eindruck von den Diensten und Tools der Platform zu erhalten.

Sobald Sie sich entscheiden, die Anwendung zu zu migrieren, starten Sie mit einer Pilotversion der Anwendung und einer minimalen Datenmenge, um eine Machbarkeitsstudie zu erstellen. Implementieren Sie zuerst notwendige Codeänderungen in der Anwendung, um die -Bereitstellungsziele in Hinsicht auf geschäftliche und technische Anforderungen zu erfüllen. Anschließend müssen Sie den Anwendungscode kompilieren und für die geeigneten Rollen in bereitstellen.

Im Allgemeinen können die meisten vorhandenen lokalen Anwendungen mit geringfügigen oder überhaupt keinen Änderungen in -Cloud-Diensten ausgeführt werden. Dabei können jedoch Leistungs-, Skalierbarkeits- und Sicherheitsprobleme entstehen. Um die Leistung zu optimieren und zukünftige Skalierbarkeit zu ermöglichen, sollten Sie die Anwendung vor der Migration zu ggf. unter Verwendung mehrerer Rollen umgestalten. Weitere Informationen finden Sie unter Überlegung zur Entwicklung für Azure Cloud Services. Es wird empfohlen, zuerst die gesamte Anwendung und dann die Daten in -Cloud-Dienste zu verschieben. Aus Sicherheits-, Leistungs- oder anderen Gründen müssen einige Teile der Anwendung möglicherweise in der lokalen Umgebung verbleiben. Dazu sind Hybridlösungen erforderlich. Weitere Informationen finden Sie unter Erstellen von Hybridlösungen mit Azure.

Wenn Sie sich entscheiden, SQL Server auf einem virtuellen Computer in (Virtual Machine, VM) zu verwenden, ändern Sie die vorhandenen SQL Server-Anwendungen so, dass sie eine Verbindung mit der SQL Server-Datenbank auf der -VM herstellen. Außerdem sollten Sie einen der nachstehenden Migrationsansätze verfolgen:

  • Vielleicht verfügen Sie über eine Anwendung, die bereits auf einem vorhandenen virtuellen Computer ausgeführt wird. Sie können diesen virtuellen Computer zu migrieren. In diesem Fall sind die Anwendung sowie deren Konfigurationseinstellungen und Daten bereits in diesem virtuellen Computer enthalten. Dadurch kann es aber erforderlich sein, eine umfangreiche VHD-Datei in hochzuladen. Außerdem könnten auf dem vorhandenen virtuellen Computer Abhängigkeiten von Treibern und Hardware bestehen, die in u. U. nicht verfügbar sind.

  • Sie können einen virtuellen Computer in erstellen. Dazu initiieren Sie einen virtuellen Computer, der bereits SQL Server enthält, aus der Image Gallery. Installieren Sie dann die Anwendung auf diesem virtuellen Computer. So werden Uploadzeiten verringert und Treiber- und Hardwareabhängigkeiten entfernt, gleichzeitig müssen jedoch die Anwendung installiert und Daten hochgeladen werden.

Weitere Informationen darüber, wie Sie vorhandene SQL Server-Datenbanken zu SQL Server auf -VMs migrieren, finden Sie unter Migrieren zu SQL Server auf einem virtuellen Azure-Computer.

Wenn Sie -Cloud-Dienste verwenden, verschieben Sie relationale Daten von der lokalen SQL Server-Umgebung in die SQL-Datenbank und überführen unstrukturierte Daten in den -Speicher, z. B. den BLOB- oder Tabellenspeicher, bzw. auf -Laufwerke. Weitere Informationen finden Sie unter Migrieren von Daten zu Tabellen und BLOBs in Windows Azure sowie unter Migrieren von SQL Server-Datenbanken zu Azure SQL-Datenbanken.

Wenn Sie sich entscheiden, SQL Server auf virtuellen Computern in zu verwenden, können Sie einen von zwei Migrationsansätzen verfolgen:

  • Möglicherweise verfügen Sie bereits über einen virtuellen Computer mit Daten. Sie können diesen vorhandenen virtuellen Computer mittels einer VHD-Datei in hochladen.

  • Sie können einen virtuellen Computer in erstellen. Anschließend können Sie Daten mittels einer VHD-Datei in hochladen. Als Nächstes können Sie diese hochgeladene VHD-Datei oder einen leeren Datenträger als Datenträger an den virtuellen Computer anfügen. Sie können die Datenträger verwenden, um SQL Server-Protokolle und Datendateien zu speichern. Außerdem können Sie die im Thema Migrieren zu SQL Server auf einem virtuellen Azure-Computer beschriebenen Tools und Techniken werden, um die vorhandenen SQL Server-Datenbanken zu SQL Server auf einem virtuellen Computer in zu migrieren.

Nachdem Sie die Anwendung und Daten zu migriert haben, führen Sie Funktions- und Leistungstests aus. Testen Sie in dieser Phase die Anwendung in der Cloud, um sicherzustellen, dass sie erwartungsgemäß funktioniert. Vergleichen Sie dann die Leistungsergebnisse der lokalen Umgebung mit denen aus . Beheben Sie im Anschluss eventuelle Funktions-, Leistungs- oder Skalierbarkeitsprobleme in der Cloudanwendung. Weitere Informationen finden Sie unter Implementieren des Migrationsplans für Azure.

Richten Sie nach der Test- und Optimierungsphase die Anwendungsüberwachung und -ablaufverfolgung mit der -Diagnose ein, und implementieren Sie diese. Die -Diagnose ermöglicht es Ihnen, Diagnosedaten zu einer in ausgeführten Anwendung zu sammeln. Sie können Diagnosedaten für das Debuggen und die Problembehandlung, zum Messen der Leistung, Überwachen des Ressourceneinsatzes, die Analyse des Datenverkehrs sowie die Kapazitätsplanung und Überwachung verwenden. Weitere Informationen finden Sie unter Diagnose und Debugging in Azure in der MSDN Library.

Wenn Sie Daten zwischen der lokalen Umgebung und einer SQL-Datenbank oder zwischen verschiedenen SQL-Datenbankservern synchronisieren müssen, richten Sie den SQL-Datensynchronisierung (Vorschau)sdienst ein und konfigurieren ihn. Zusätzlich sollten Sie einen Datenwiederherstellungsplan einrichten und konfigurieren, der bei Benutzerfehlern oder Naturkatastrophen in Kraft tritt. Weitere Informationen finden Sie unter Überlegungen zu hoher Verfügbarkeit und Notfallwiederherstellung bei Azure SQL-Datenbanken.

Siehe auch

Anzeigen:
© 2014 Microsoft