War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Exportieren (0) Drucken
Alle erweitern

Implementieren des Migrationsplans für Azure

Letzte Aktualisierung: Februar 2015

Azure ist eine internetweite Computing- und Dienstplattform, die in Microsoft-Rechenzentren gehostet wird. Mit Azure müssen Entwickler und Administratoren keine zugrunde liegende Software und Hardwareinfrastruktur implementieren, da alle grundlegenden Betriebssystem-, Hardware-, Netzwerk- und Speicherressourcen sowie Plattformupdates automatisch von Microsoft betreut werden.

Es wird dringend empfohlen, nach der Migration der Anwendung zur Cloud genau dieselben Funktions- und Leistungstests für die Anwendung auszuführen, die sie für alle neu bereitgestellten Anwendungen ausführen. Da sich Azure von lokalen Plattformen unterscheidet, sollten bei der Implementierung der Migration folgende wichtige Aspekte berücksichtigt werden:

Dieses Thema beschäftigt sich hauptsächlich mit Azure Cloud Services. Eine vorläufige Anleitung zur Migration mit SQL Server auf virtuellen Azure-Computern finden Sie unter Migrating with Azure Virtual Machines.

Autoren: Kun Cheng, Steve Howard
Mitwirkende: Selcin Turkarslan

Bei der Migration von Anwendungen zur Cloud sollten Sie die erforderlichen Test- und Debugverfahren kennen, um sicherzustellen, dass die Anwendung in der Cloud erwartungsgemäß funktioniert. Im Folgenden werden einige Ansätze zum Testen der Anwendung vorgeschlagen:

  • Azure Tools für Microsoft Visual Studio: Sie können Ihre Anwendung erstellen und diese dann mithilfe der Server- und Speicheremulatoren, die mit den Azure Tools bereitgestellt werden, lokal ausführen und debuggen. Dadurch können Sie Ihre Anwendung lokal entwickeln, bevor Sie sie in Azure veröffentlichen. Azure Tools für Microsoft Visual Studio stellen eine Erweiterung von Visual Studio 2010 dar und bieten die Möglichkeit, die Anwendung mit Server- und Speicheremulatoren zu testen, die einen Großteil der Azure-Funktionen zur Verfügung stellen. Es empfiehlt sich, diese Art von Tests zu Beginn der Funktionstests auszuführen. Weitere Informationen finden Sie unter Azure Tools für Microsoft Visual Studio.

  • SQL Server Data Tools: SQL Server Data Tools (SSDT) bieten eine integrierte Umgebung innerhalb von Visual Studio 2010, die Sie zum Entwerfen von Datenbanken, Erstellen oder Bearbeiten von Datenbankobjekten und -daten oder Ausführen von Abfragen für alle unterstützten SQL-Plattformen verwenden können, einschließlich externer Azure SQL-Datenbank- und lokaler Microsoft SQL Server 2012-Plattformen. Durch die Tools können Datenbankprojektlösungen mithilfe der lokalen Standarddatenbank oder einer Azure SQL-Datenbank getestet werden, indem der Teil der Anwendung überprüft wird, der für den Zugriff auf relationale Daten konzipiert ist. Weitere Informationen finden Sie unter SQL Server Data Tools. Hinweis: Sowohl Azure Tools für Microsoft Visual Studio als auch SSDT ermöglichen es Ihnen, grundlegende Funktionalitäts- und Kompatibilitätstest mit Offline- und Onlinedatenquellen für die Anwendung auszuführen. Um alle Aspekte einer echten Cloudanwendung in Hinsicht auf Funktionalität, Leistung und Skalierbarkeit zu testen, müssen Simulationstests auf der Azure Platform ausgeführt werden, auf der die Anwendung bereitgestellt und ausgeführt wird.

  • Automatisiertes Testframework: Viele vorhandene Anwendungen verfügen bereits über ein automatisiertes Testframework, mit dessen Hilfe sichergestellt werden kann, dass alle Komponenten oder Funktionen der Anwendung erwartungsgemäß arbeiten. Wenn eine Anwendung auf Azure ausgeführt wird, ist das automatisierte Testframework entwurfsbedingt u. U. nicht funktionsfähig. Wenn das automatisierte Testframework lokal ausgeführt werden muss, aber in der Lage ist, unter Verwendung der definierten Endpunkte eine Verbindung mit einer Anwendung in Azure herzustellen, funktioniert es eventuell noch. Andernfalls wird empfohlen, sowohl das automatisierte Testframework als auch die Anwendung in Azure zu hosten, um potenzielle Verbindungsverluste und Latenzprobleme zu mindern.

  • Visual Studio-Auslastungstest: Wenn für eine Anwendung kein automatisiertes Testframework verfügbar ist, empfiehlt es sich, ein neues automatisierten Testframework zu erstellen und mithilfe der Visual Studio-Auslastungstests Simulationstests mit mehreren gleichzeitigen Benutzern durchzuführen.

Sie sollten versuchen, die effektiven Übernahmezeiten zwischen Testphase, Staging und Produktion soweit wie möglich zu minimieren. Es kann Stunden oder Tage dauern, eine große Datenbank aus der lokalen Umgebung in Azure zu kopieren. Außerdem möchten Sie bestimmt nicht für die gesamte Dauer, die zur vollständigen Migration der vorhandenen Daten erforderlich ist, auf die Anwendung verzichten. Aus diesem Grund benötigen Sie einen Plan zur Minimierung der durch die Übernahme verursachten Downtime. "Übernahme" bezeichnet die Zeitspanne, die für den vollständigen Übergang zu Azure erforderlich ist. Vor der Übernahme sollten Sie überprüfen, welche Tabellen statische Daten und welche Tabellen Daten enthalten, die sich während der Übernahme ändern könnten. Statische Daten müssen während der Übernahmezeit nicht verschoben werden. Falls Sie jedoch unsicher sind, ob Daten in einer bestimmten Tabelle während der Übernahme geändert werden, sollten Sie Systemlogik integrieren, durch die im Anschluss alle Änderungen migriert werden. Zusätzlich sollten Sie überlegen, ob alle Daten aus den lokalen Systemen zur Cloud migriert werden müssen, bevor die Anwendung in Azure online geschaltet wird. Wenn die Anwendung online geschaltet und die Daten später nachgezogen werden können, lässt sich die Downtime vollständig vermeiden.

Wenn die Daten in Azure jedoch mit den lokalen Daten konsistent sein müssen, bevor diese als Livedaten in Azure bereitgestellt werden, sollten Sie die bei der Übernahme zu migrierende Datenmenge minimieren, da so auch die für die tatsächliche Übernahme erforderliche Downtime reduziert wird. Es kann zweckmäßig sein, einige Daten vor der Übernahme und die übrigen Daten nach der tatsächlichen Übernahme zu verschieben. In diesen Fällen sollte aus dem Migrationsplan klar ersichtlich sein, welche Daten zuerst migriert werden müssen und welche verbleibenden Daten nach der Übernahme verschoben werden können. Auf diese Weise kann die Anwendung nach einer kürzeren Downtime in Azure online geschaltet und bereits produktiv genutzt werden, während Sie die verbleibenden Daten migrieren. Für die Datenmigration vor der Übernahme stehen folgende Datensynchronisierungsmethoden zur Verfügung:

Microsoft Azure Der SQL-Datensynchronisierung (Vorschau)-Dienst stellt Datensynchronisierungsfunktionen für SQL-Datenbanken bereit – SQL Server und SQL-Datenbank. Der Dienst bietet derzeit die beiden folgenden Hauptfunktionen:

  • Synchronisierung von Daten zwischen lokalen SQL Server-Datenbanken und Microsoft Azure SQL-Datenbank-Instanzen, sodass lokale und cloudbasierte Anwendungen dieselben Daten nutzen können.

  • Synchronisierung von Daten zwischen mindestens zwei Microsoft Azure SQL-Datenbank-Instanzen. Die Instanzen können sich im selben Rechenzentrum, in unterschiedlichen Rechenzentren oder in verschiedenen Regionen befinden.

Microsoft Azure Die SQL-Datensynchronisierung (Vorschau) eignet sich besonders in folgenden Situationen für die Synchronisierung lokaler Datenbanken und Microsoft Azure SQL-Datenbank-Instanzen:

  • Anwendungen müssen parallel getestet werden.

  • Sie müssen die Anwendung vor der endgültigen Übernahme aller lokalen Datenvorgänge in Microsoft Azure parallel ausführen.

  • Sie müssen die Anwendung während der Migration zu Microsoft Azure lokal ausführen und gleichzeitig eine minimale Downtime gewährleisten.

  • Sie müssen die Daten im Rahmen einer Hybridlösung zwischen der lokalen Umgebung und der Microsoft Azure-Anwendung kontinuierlich synchronisieren.

Um inkrementelle Datenänderungen nachzuverfolgen, wenn die Synchronisierungsgruppe konfiguriert ist, fügt die SQL-Datensynchronisierung (Vorschau) eine Änderungsnachverfolgungstabelle für jede Tabelle hinzu, die synchronisiert wird. Bei Verwendung der SQL-Datensynchronisierung (Vorschau) ist darauf zu achten, Kapazitätspläne für Änderungsnachverfolgungstabellen zu berücksichtigen. Außerdem sollten Sie nach der Einrichtung der Synchronisierung keine Änderungen an den Tabellenstrukturen oder Primärschlüsseln von Tabellen vornehmen, die synchronisiert werden, es sei denn, die Synchronisierungsgruppe wird erneut initialisiert. Für Situationen, in denen eine fortlaufende bzw. Zwischensynchronisierung der Daten erforderlich ist, ist die SQL-Datensynchronisierung (Vorschau) nicht optimal geeignet.

Warnung: SQL-Datensynchronisierung (Vorschau) wird derzeit nur als Preview zur Verfügung gestellt, um Produktfeedback für zukünftige Versionen zu sammeln. Sie sollte nicht in Produktionsumgebungen eingesetzt werden.

Weitere Informationen zur SQL-Datensynchronisierung (Vorschau) finden Sie unter SQL-Datensynchronisierung.

Sie können Daten mithilfe der Replikation, der Spiegelung oder des Protokollversands von lokalen SQL Server-Umgebungen in andere lokale SQL Server-Umgebungen oder in eine auf einem virtuellen Azure-Computer ausgeführte SQL Server-Instanz verschieben. Sie können die Verfahren jedoch nicht verwenden, um Daten in oder aus Azure SQL-Datenbanken zu verschieben. Weitere Informationen finden Sie unter Replikation und Protokollversand und Datenbankspiegelung und Protokollversand.

Um die Dauer der Datenübertragung während der Übernahmezeit zu minimieren, sollten Sie so viele Daten wie möglich vor der tatsächlichen Übernahme auf die Azure Platform verschieben. Sie können einen benutzerdefinierten ETL-Auftrag erstellen, um die geänderten Daten vom lokalen System in die Azure-Umgebung zu verschieben. Bei der Migration von einem lokalen System mit SQL Server 2008 oder höher wird die Verwendung von Change Data Capture oder der Nachverfolgung von Datenänderungen empfohlen, um sicherzustellen, dass tatsächlich nur die geänderten Daten und nicht mehr von der lokalen Datenbank in die Azure SQL-Datenbankinstanz verschoben werden. Weitere Informationen zu diesen beiden Funktionen finden Sie unter Nachverfolgen von Datenänderungen in der SQL Server-Onlinedokumentation. Bei Datenbanken, die Change Data Capture oder die Nachverfolgung von Datenänderungen nicht unterstützen, müssen Sie ein Nachverfolgungssystem für Ihre Änderungen und die migrierten Daten erstellen. In allen Fällen liegt der Schlüssel zur Minimierung der für die tatsächliche Übernahme erforderlichen Downtime darin, bei der tatsächlichen Übernahme eine möglichst kleine Datenmenge zu verschieben.

Mithilfe einer DAC können Sie Daten aus einer SQL Server-Instanz exportieren und in den Azure-BLOB-Speicher einfügen. Aus dem Speicher kann sie in Azure SQL-Datenbanken importiert werden. Mit einer DAC können Sie Filter einrichten, auf deren Grundlage Tabellen importiert oder exportiert werden sollen. Filter auf Zeilenebene können jedoch nicht eingerichtet werden. Aus diesem Grund eignet sich eine DAC für Fälle, in denen vollständige Tabellen in einer einzelnen Datenbank Platz finden, funktioniert aber nicht für horizontal skalierte Datenbanken. Zum Migrieren von Daten für Anwendungen, die eine laufende Datensynchronisierung erfordern, ist eine DAC nicht optimal geeignet. Weitere Informationen finden Sie unter Exportieren einer Datenebenenanwendung in der SQL Server-Onlinedokumentation.

Datenbanksicherungen sollen Ihnen die Wiederherstellung nach Datenverlusten ermöglichen, die durch Verwaltungsfehler oder Anwendungsfehler bzw. den Verlust eines vollständigen Rechenzentrums entstehen. Das Sichern und Wiederherstellen von Daten in Azure SQL-Datenbanken unterscheidet sich von dem Verfahren auf lokalen SQL Server-Systemen und muss mit den verfügbaren Ressourcen und Tools kompatibel sein. Die zuverlässige Verwendung von Sicherungen und Wiederherstellungen erfordert daher eine Sicherungs- und Wiederherstellungsstrategie für Azure SQL-Datenbanken. Die Probleme, nach denen eine Azure SQL-Datenbankinstanz u. U. wiederhergestellt werden muss, können in drei allgemeine Kategorien gegliedert werden:

  • Infrastruktur- oder Hardwarefehler: Innerhalb eines Datencenters könnten Hardwarefehler auftreten. Beispielsweise kann der physische Knoten, auf dem die Azure SQL-Datenbankinstanz ausgeführt wird, abstürzen.

  • Anwendungs- oder Benutzerfehler: Es kann vorkommen, dass Benutzer oder Anwendungen ungewollte Änderungen an den Daten vornehmen. Dies kann einen Wiederherstellungsvorgang erforderlich machen. Beispielsweise kann ein Benutzer versehentlich die Daten des falschen Kunden bearbeiten usw.

  • Verlust von Funktionen des Datencenters: Die aktuelle Vereinbarung zum Servicelevel für Azure SQL-Datenbanken sehen eine besondere Ausnahme für Faktoren vor, die nicht der angemessenen Kontrolle von Microsoft unterliegen, z. B. Naturkatastrophen. Im Fall einer Naturkatastrophe könnte das Rechenzentrum auf eine Weise Schaden nehmen, die die Datenbankwiederherstellung von den Replikaten oder Onsitesicherungen unmöglich macht.

Welches Risiko Sie im Hinblick auf die in Rechenzentren mit Azure SQL-Datenbanken gespeicherten Daten als hinnehmbar empfinden, liegt letztendlich in Ihrer Entscheidung. Ausführliche Informationen zu den verfügbaren Sicherungs- und Wiederherstellungstools sowie zum Aufstellen passender Notfallwiederherstellungsstrategien finden Sie im Artikel Azure SQL-Datenbank-Geschäftskontinuität in der MSDN Library.

Bei der tatsächlichen Anwendungsmigration zu Azure können Sie folgende Ansätze verfolgen:

  • Parallele Ausführung: Bei diesem Ansatz kann die Anwendung parallel lokal und in Azure ausgeführt werden. Dadurch können Sie Livetests mit der Anwendung in Azure ausführen, bevor die Anwendung vollständig von der Cloud abhängig wird. Die folgenden Tests sollten neben anderen Tests ausgeführt werden: Funktionalitätstests, Leistungstests und Skalierbarkeitstests. Nachdem Sie das neue System eingehend in Azure getestet haben, führen Sie die endgültige Datenmigration aus und fahren das lokale System herunter.

  • Unterbrechung und Übernahme: Dieser Ansatz ist geeignet, wenn alle Daten vor der vollständigen Onlineschaltung in Azure synchronisiert sein müssen. Bei diesem Ansatz sollten zunächst alle Funktions- und Leistungstests in Azure abgeschlossen sein. Anschließend richten Sie das System für die Datenreplikation in die Azure-Umgebung unter Verwendung einer der oben genannten Datensynchronisierungsmethoden ein. Es empfiehlt sich, die Datensynchronisierung so zeitnah wie möglich zu halten, indem Sie die Dauer des letzten Synchronisierungs- oder ETL-Vorgangs vor der endgültigen Übernahme minimieren. Sobald die Übernahme in Azure ansteht, fahren Sie das lokale System herunter, führen die letzte Datensynchronisierung aus und aktivieren die Anwendung in Azure.

Siehe auch

Anzeigen:
© 2015 Microsoft