Start Cloud Eine Einführung in die Migration von SQL Server 2008/2008 R2-Datenbanken in die...

Eine Einführung in die Migration von SQL Server 2008/2008 R2-Datenbanken in die Azure-Cloud

9
0


System- und Datenbankadministratoren sind jetzt gezwungen, etwas gegen ältere SQL Server 2008- und 2008 R2-Datenbankanwendungen zu unternehmen. Grund ist das Ende des Extended Support im Juli 2019. Auch der Extended Support endet im Januar 2020 für den gemeinsamen Begleiter Windows Server 2008 und 2008 R2. Ein Upgrade auf die neuesten Versionen ist natürlich immer eine Option, aber Microsoft bietet eine attraktive Alternative, wenn Upgrades nicht praktikabel oder nicht kostengerecht sind: Migrieren Sie die Datenbank in die Azure-Cloud und erhalten Sie drei weitere Jahre Support für erweiterte Sicherheitsupdates ohne zusätzliche Kosten gegenüber den Standardpreisen für virtuelle Computer.

In diesem Artikel werden wichtige Überlegungen zum Migrieren geschäftskritischer Legacy-SQL Server 2008/R2-Datenbanken in die Azure-Cloud hervorgehoben, um Administratoren zu helfen, fundiertere Entscheidungen zu treffen. Zu den wichtigsten Überlegungen gehört es zu wissen, welche Optionen verfügbar sind und welche nicht.

Ausführen von Legacy-Software in einer hochmodernen Cloud

Die Azure-Cloud bietet eine Fülle von Diensten zum Ausführen und Schützen von Anwendungssoftware, aber einige davon unterstützen SQL Server 2008/R2 nicht. Die größte Einschränkung betrifft die Abhängigkeit von Failover-Cluster-Instanzen (FCIs) von gemeinsam genutztem Speicher. In einem Unternehmensrechenzentrum kann gemeinsam genutzter Speicher mit einem Storage Area Network (SAN) oder Network Attached Storage (NAS) bereitgestellt werden. Beide Speicherformen sind jedoch in der Azure-Cloud nicht verfügbar.

Bei Legacy-Datenbankanwendungen, die nicht kritisch sind, ist es möglicherweise nicht erforderlich, FCIs zu verwenden, um eine hohe Verfügbarkeit (HA) sicherzustellen. Für die meisten Batch-Datenbankanwendungen sollten beispielsweise manuelle Sicherungs- und Wiederherstellungsprozesse eine ausreichende Betriebszeit gewährleisten.

Im Gegensatz zu Batch-Anwendungen haben die meisten Anwendungen für die Online-Transaktionsverarbeitung strengere Ziele für den Wiederherstellungspunkt und die Wiederherstellungszeit, die nur mit robusteren HA- und/oder Disaster Recovery-Vorkehrungen (DR) erfüllt werden können. Für DR wird SQL Server 2008/R2 von Azure Site Recovery unterstützt, dem DR-as-a-Service (DRaaS)-Angebot von Microsoft. ASR repliziert die gesamte aktive Instanz in eine „warme“ Standby-Instanz in einer anderen Azure-Region. Da jedoch manuelle Prozesse zur Erkennung und Wiederherstellung eines Fehlers erforderlich sind, eignet sich ASR nur für Anwendungen mit einem Recovery Point Objective (RPO) von einigen Minuten oder mehr und einem Recovery Time Objective (RTO) von mehreren Minuten oder mehr. Die Beschränkung von 10 Megabyte pro Sekunde der WAN-Bandbreite pro Festplatte kann auch die Verwendung für einige Anwendungen ausschließen.

Es ist erwähnenswert, dass die beiden Möglichkeiten, mit denen Microsoft den Mangel an freigegebenem Speicher angegangen ist, SQL Server 2008/R2 nicht unterstützen. Eine davon sind SQL Servers eigene Always On-Verfügbarkeitsgruppen, die in SQL Server 2012 verfügbar wurden. Die andere ist Storage Spaces Direct, das mit der Datacenter Edition von Windows Server 2016 und SQL Server 2016 eingeführt wurde.

Es ist auch erwähnenswert, dass die Geld-zurück-Service-Level-Agreement-Garantie von Azure keine Verfügbarkeit auf Datenbank- oder Anwendungsebene gewährleistet. Das SLA stellt effektiv nur „Wählton“ sicher, oder genauer gesagt, dass mindestens eine Instanz über eine externe Netzwerkkonnektivität verfügt.

Sicherstellen der Hochverfügbarkeit für SQL Server 2008/R2-Datenbanken

Für Anwendungen mit einer strengen RTO, die eine Betriebszeit von vier-neun (99,99 %) und einen RPO von null (kein Datenverlust) erfordert, ist die einzige praktikable Option für SQL Server 2008/R2 die Verwendung von FCIs. Und das erfordert die Verwendung von Failover-Clustering-Software von Drittanbietern, um eine synchrone Datenreplikation zu ermöglichen.ohne SANs – über mehrere Azure Availability Zones hinweg.

Failover-Clustering-Lösungen von Drittanbietern ermöglichen zumindest Datenreplikation in Echtzeit, kontinuierliche Überwachung, die Fehler auf Datenbank- oder Anwendungsebene erkennen kann, sowie konfigurierbare Richtlinien für Failover und Failback. Die meisten sind so konzipiert, dass sie sich nahtlos in FCIs und Windows Server Failover Clustering (WSFC) integrieren lassen. Die meisten sind auch anwendungsunabhängig konzipiert, um eine universelle HA/DR-Lösung bereitzustellen, die für praktisch alle Anwendungssoftware, einschließlich aller Versionen von SQL Server, geeignet ist.

Eine beliebte Konfiguration ist die Verwendung von Drittanbieter-Failoverclustering für HA und Azure Site Recovery für DR. Diese kostengünstige Kombination repliziert Daten synchron über mehrere Azure-Verfügbarkeitszonen hinweg, indem virtuelle Volumes verwendet werden, die für die SQL Server-FCIs als freigegebener Speicher angezeigt werden. ASR repliziert dann das Paar von Images virtueller Computer (VM) im Failovercluster (sowohl im aktiven als auch im Standby) asynchron in eine andere Azure-Region in einem Regionspaar, um vor weit verbreiteten Katastrophen zu schützen.

Eine weitere beliebte Konfiguration, die im Diagramm gezeigt wird, besteht darin, die Failover-Clustering-Software sowohl für HA als auch für DR zu verwenden. Diese Option ist außerdem kostengünstig und bietet den zusätzlichen Vorteil, dass eine einzige Lösung bereitgestellt wird, die für alle Anwendungen einfacher zu implementieren, zu testen, zu überwachen, zu warten und anderweitig zu verwalten ist.

Diese kostengünstige Konfiguration besteht aus einem HA-Failovercluster mit zwei Knoten, der sich über zwei Azure-Verfügbarkeitszonen erstreckt, sowie einer dritten Instanz, die in einer separaten Azure-Region bereitgestellt wird, um eine vollständige Wiederherstellung nach weit verbreiteten Katastrophen zu ermöglichen.

Das „Heben und Verschieben“ eines vorhandenen SQL Server 2008/R2-Failoverclusters vom Standort in die Azure-Cloud ist recht unkompliziert und umfasst einfach das Ersetzen der freigegebenen Datenträgerressourcen durch die virtuellen Volumes des SANless-Failoverclusters und das Ersetzen des Datenträgerzeugen durch eine Dateifreigabe Zeuge. Die einzige andere Änderung betrifft die Konfiguration des Azure Internal Load Balancer (ILB) für die Clientumleitung, die auch das Ausführen eines PowerShell-Skripts auf den lokalen Knoten erfordert, um die SQL Server-Cluster-IP-Ressource zu aktualisieren, um auf das ILB-Probe zu lauschen.

Wenn kein lokaler HA-Failovercluster vorhanden ist, der aufgehoben und verschoben werden kann, muss ein solcher erstellt werden. Die meisten Anbieter von Failover-Clustering-Lösungen bieten eine detaillierte Dokumentation sowie umfassende Schritt-für-Schritt-Anleitungen für die Konfiguration von HA- und/oder DR-Clustern mithilfe von in der Cloud verfügbaren Diensten. Hier ist ein Beispiel für einen solchen Leitfaden speziell für Azure: Schritt für Schritt: Konfigurieren einer SQL Server 2008 R2-Failoverclusterinstanz auf Windows Server 2008 R2 in Azure.

Die gute Nachricht über „ausgereifte“ Software und Dienste ist, dass Sie sich nicht auf Neuland begeben werden, wenn Sie sich entscheiden, Ihre SQL Server 2008/R2-Datenbanken zu Azure zu migrieren.

Bildnachweis: Roland IJdema/Shutterstock

David Bermingham ist Technical Evangelist bei SIOS-Technologie. Er ist in der Technologie-Community als Hochverfügbarkeitsexperte anerkannt und wurde in den letzten 8 Jahren zum Microsoft MVP gewählt: 6 Jahre als Cluster MVP und 2 Jahre als Cloud and Datacenter Management MVP. David besitzt zahlreiche technische Zertifizierungen und verfügt über mehr als dreißig Jahre IT-Erfahrung, unter anderem in den Bereichen Finanzen, Gesundheitswesen und Bildung.



Vorheriger ArtikelOpenMandriva Lx 4.1 RC KDE-fokussierte Linux-Distribution jetzt zum Download verfügbar
Nächster ArtikelApple, die wundervolle MacBook-Schmetterlingstastatur aufzugeben, ist ein großer Fehler

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein