Skip to main content
NetApp database solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Echtzeit-Referenzdesign auf hohem Niveau

Beitragende kevin-hoke
PDFs

Dieser Abschnitt behandelt eine Echtzeitbereitstellung eines SQL-Datenbankbestands in einer AOAG-Konfiguration unter Verwendung eines Azure NetApp Files SMB-Volumes.

  • Anzahl der Knoten: 4

  • Anzahl der Datenbanken: 21

  • Anzahl der Verfügbarkeitsgruppen: 4

  • Aufbewahrung der Sicherung: 7 Tage

  • Backup-Archiv: 365 Tage

Hinweis Die Bereitstellung von FCI mit SQL Server auf virtuellen Azure-Computern mit einer Azure NetApp Files Freigabe bietet ein kosteneffizientes Modell mit einer einzigen Kopie der Daten. Diese Lösung kann Probleme beim Hinzufügen von Dateien verhindern, wenn der Dateipfad vom sekundären Replikat abweicht.

Abbildung, die einen Eingabe-/Ausgabedialog zeigt oder schriftlichen Inhalt darstellt

Das folgende Bild zeigt die Datenbanken innerhalb von AOAG, die über die Knoten verteilt sind.

Abbildung, die einen Eingabe-/Ausgabedialog zeigt oder schriftlichen Inhalt darstellt

Datenlayout

Die Benutzerdatenbankdateien (.mdf) und die Transaktionsprotokolldateien der Benutzerdatenbank (.ldf) werden zusammen mit tempDB auf demselben Datenträger gespeichert. Das Servicelevel ist Ultra.

Die Konfiguration besteht aus vier Knoten und vier AGs. Alle 21 Datenbanken (Teil von Dynamic AX, SharePoint, RDS-Verbindungsbroker und Indexierungsdiensten) werden auf den Azure NetApp Files Volumes gespeichert. Die Datenbanken werden zwischen den AOAG-Knoten ausgeglichen, um die Ressourcen auf den Knoten effektiv zu nutzen. Im WSFC werden vier D32 v3-Instanzen hinzugefügt, die an der AOAG-Konfiguration teilnehmen. Diese vier Knoten werden im virtuellen Azure-Netzwerk bereitgestellt und nicht vom lokalen Standort migriert.

Anmerkungen:

  • Wenn die Protokolle je nach Art der Anwendung und der ausgeführten Abfragen mehr Leistung und Durchsatz erfordern, können die Datenbankdateien auf der Serviceebene „Premium“ platziert und die Protokolle auf der Serviceebene „Ultra“ gespeichert werden.

  • Wenn die Tempdb-Dateien auf Azure NetApp Files abgelegt wurden, sollte das Azure NetApp Files Volume von den Benutzerdatenbankdateien getrennt werden. Hier ist eine Beispielverteilung der Datenbankdateien in AOAG.

Anmerkungen:

  • Um die Vorteile der auf Snapshot-Kopien basierenden Datensicherung beizubehalten, empfiehlt NetApp, Daten und Protokolldaten nicht im selben Volume zu kombinieren.

  • Ein auf dem primären Replikat ausgeführter Vorgang zum Hinzufügen von Dateien kann auf den sekundären Datenbanken fehlschlagen, wenn der Dateipfad einer sekundären Datenbank vom Pfad der entsprechenden primären Datenbank abweicht. Dies kann passieren, wenn der Freigabepfad auf primären und sekundären Knoten unterschiedlich ist (aufgrund unterschiedlicher Computerkonten). Dieser Fehler kann dazu führen, dass die sekundären Datenbanken angehalten werden. Wenn das Wachstums- oder Leistungsmuster nicht vorhergesagt werden kann und geplant ist, Dateien später hinzuzufügen, ist ein SQL Server-Failovercluster mit Azure NetApp Files eine akzeptable Lösung. Für die meisten Bereitstellungen erfüllt Azure NetApp Files die Leistungsanforderungen.

Migration

Es gibt mehrere Möglichkeiten, eine lokale SQL Server-Benutzerdatenbank zu SQL Server auf einer virtuellen Azure-Maschine zu migrieren. Die Migration kann entweder online oder offline erfolgen. Die gewählten Optionen hängen von der SQL Server-Version, den Geschäftsanforderungen und den innerhalb der Organisation definierten SLAs ab. Um die Ausfallzeit während des Datenbankmigrationsprozesses zu minimieren, empfiehlt NetApp die Verwendung der AlwaysOn-Option oder der Transaktionsreplikationsoption. Wenn diese Methoden nicht verwendet werden können, können Sie die Datenbank manuell migrieren.

Der einfachste und am besten getestete Ansatz zum Verschieben von Datenbanken zwischen Maschinen ist die Sicherung und Wiederherstellung. Normalerweise können Sie mit einer Datenbanksicherung beginnen und anschließend eine Kopie der Datenbanksicherung in Azure erstellen. Anschließend können Sie die Datenbank wiederherstellen. Um die beste Datenübertragungsleistung zu erzielen, migrieren Sie die Datenbankdateien mithilfe einer komprimierten Sicherungsdatei in die Azure-VM. Das in diesem Dokument referenzierte High-Level-Design verwendet den Sicherungsansatz für Azure-Dateispeicher mit Azure-Dateisynchronisierung und stellt dann Azure NetApp Dateien wieder her.

Hinweis Azure Migrate kann zum Erkennen, Bewerten und Migrieren von SQL Server-Workloads verwendet werden.

Führen Sie zum Durchführen einer Migration die folgenden allgemeinen Schritte aus:

  1. Richten Sie die Konnektivität entsprechend Ihren Anforderungen ein.

  2. Führen Sie eine vollständige Datenbanksicherung an einem lokalen Dateifreigabespeicherort durch.

  3. Kopieren Sie die Sicherungsdateien mit Azure File Sync in eine Azure-Dateifreigabe.

  4. Stellen Sie die VM mit der gewünschten Version von SQL Server bereit.

  5. Kopieren Sie die Sicherungsdateien auf die VM, indem Sie copy Befehl von einer Eingabeaufforderung.

  6. Stellen Sie die vollständigen Datenbanken auf SQL Server auf virtuellen Azure-Computern wieder her.

Hinweis Die Wiederherstellung von 21 Datenbanken dauerte ungefähr neun Stunden. Dieser Ansatz ist spezifisch für dieses Szenario. Je nach Ihrer Situation und Ihren Anforderungen können jedoch auch andere unten aufgeführte Migrationstechniken verwendet werden.

Zu den weiteren Migrationsoptionen zum Verschieben von Daten von einem lokalen SQL Server zu Azure NetApp Files gehören die folgenden:

  • Trennen Sie die Daten- und Protokolldateien, kopieren Sie sie in den Azure Blob-Speicher und hängen Sie sie dann mit einer über die URL bereitgestellten ANF-Dateifreigabe an SQL Server in der Azure-VM an.

  • Wenn Sie die Bereitstellung einer Always On-Verfügbarkeitsgruppe vor Ort verwenden, verwenden Sie die "Assistent zum Hinzufügen von Azure-Replikaten" um ein Replikat in Azure zu erstellen und dann ein Failover durchzuführen.

  • Verwenden von SQL Server "Transaktionsreplikation" um die Azure SQL Server-Instanz als Abonnent zu konfigurieren, die Replikation zu deaktivieren und Benutzer auf die Azure-Datenbankinstanz zu verweisen.

  • Versenden Sie die Festplatte mithilfe des Windows-Import-/Export-Dienstes.

Sicherung und Wiederherstellung

Sicherung und Wiederherstellung sind ein wichtiger Aspekt jeder SQL Server-Bereitstellung. Es ist zwingend erforderlich, über das entsprechende Sicherheitsnetz zu verfügen, um in Verbindung mit Hochverfügbarkeitslösungen wie AOAG eine schnelle Wiederherstellung nach verschiedenen Datenausfall- und -verlustszenarien zu ermöglichen. SQL Server Database Quiesce Tool, Azure Backup (Streaming) oder ein beliebiges Sicherungstool eines Drittanbieters wie Commvault können verwendet werden, um eine anwendungskonsistente Sicherung der Datenbanken durchzuführen.

Mit der Azure NetApp Files Snapshot-Technologie können Sie problemlos eine Point-in-Time-Kopie (PiT) der Benutzerdatenbanken erstellen, ohne die Leistung oder Netzwerkauslastung zu beeinträchtigen. Mit dieser Technologie können Sie außerdem eine Snapshot-Kopie auf einem neuen Volume wiederherstellen oder das betroffene Volume mithilfe der Funktion „Volume zurücksetzen“ schnell in den Zustand zurückversetzen, in dem es sich befand, als die Snapshot-Kopie erstellt wurde. Der Snapshot-Prozess von Azure NetApp Files ist sehr schnell und effizient und ermöglicht im Gegensatz zum Streaming-Backup von Azure Backup mehrere tägliche Backups. Da an einem Tag mehrere Snapshot-Kopien möglich sind, können die RPO- und RTO-Zeiten erheblich reduziert werden. Um die Anwendungskonsistenz zu erhöhen, sodass die Daten intakt sind und ordnungsgemäß auf die Festplatte geschrieben werden, bevor die Snapshot-Kopie erstellt wird, verwenden Sie das SQL Server-Datenbank-Quiesce-Tool("SCSQLAPI-Tool" ; für den Zugriff auf diesen Link sind NetApp SSO-Anmeldeinformationen erforderlich). Dieses Tool kann innerhalb von PowerShell ausgeführt werden, wodurch die SQL Server-Datenbank stillgelegt wird und wiederum die anwendungskonsistente Speicher-Snapshot-Kopie für Sicherungen erstellt werden kann.

*Anmerkungen: *

  • Das SCSQLAPI-Tool unterstützt nur die Versionen 2016 und 2017 von SQL Server.

  • Das SCSQLAPI-Tool funktioniert jeweils nur mit einer Datenbank.

  • Isolieren Sie die Dateien aus jeder Datenbank, indem Sie sie auf einem separaten Azure NetApp Files -Volume platzieren.

Aufgrund der enormen Einschränkungen der SCSQL-API "Azure Backup" wurde zum Datenschutz verwendet, um die SLA-Anforderungen zu erfüllen. Es bietet eine streambasierte Sicherung von SQL Server, der in Azure Virtual Machines und Azure NetApp Files ausgeführt wird. Azure Backup ermöglicht ein RPO von 15 Minuten mit häufigen Protokollsicherungen und PiT-Wiederherstellung von bis zu einer Sekunde.

Überwachung

Azure NetApp Files ist für die Zeitreihendaten in Azure Monitor integriert und bietet Metriken zu zugewiesenem Speicher, tatsächlicher Speichernutzung, Volume-IOPS, Durchsatz, Festplattenlesebytes/s, Festplattenschreibbytes/s, Festplattenlesevorgängen/s und Festplattenschreibvorgängen/s sowie der zugehörigen Latenz. Diese Daten können verwendet werden, um Engpässe bei der Warnmeldung zu identifizieren und Integritätsprüfungen durchzuführen, um sicherzustellen, dass Ihre SQL Server-Bereitstellung in einer optimalen Konfiguration ausgeführt wird.

In diesem HLD wird ScienceLogic verwendet, um Azure NetApp Files zu überwachen, indem die Metriken mithilfe des entsprechenden Dienstprinzipals offengelegt werden. Das folgende Bild ist ein Beispiel für die Metrikoption von Azure NetApp Files .

Abbildung, die einen Eingabe-/Ausgabedialog zeigt oder schriftlichen Inhalt darstellt

DevTest mit Thick Clones

Mit Azure NetApp Files können Sie sofortige Kopien von Datenbanken erstellen, um Funktionen zu testen, die mithilfe der aktuellen Datenbankstruktur und des aktuellen Datenbankinhalts während der Anwendungsentwicklungszyklen implementiert werden sollen, um beim Auffüllen von Data Warehouses die Tools zur Datenextraktion und -bearbeitung zu verwenden oder sogar um versehentlich gelöschte oder geänderte Daten wiederherzustellen. Bei diesem Vorgang werden keine Daten aus Azure Blob-Containern kopiert, was ihn sehr effizient macht. Nachdem das Volume wiederhergestellt wurde, kann es für Lese-/Schreibvorgänge verwendet werden, was die Validierung und die Markteinführungszeit erheblich verkürzt. Dies muss aus Gründen der Anwendungskonsistenz in Verbindung mit SCSQLAPI verwendet werden. Dieser Ansatz bietet zusammen mit Azure NetApp Files eine weitere Technik zur kontinuierlichen Kostenoptimierung, indem die Option „Auf neuem Volume wiederherstellen“ genutzt wird.

Anmerkungen:

  • Das aus der Snapshot-Kopie mithilfe der Option „Neues Volume wiederherstellen“ erstellte Volume verbraucht Kapazität aus dem Kapazitätspool.

  • Sie können die geklonten Volumes mithilfe von REST oder Azure CLI löschen, um zusätzliche Kosten zu vermeiden (falls der Kapazitätspool erhöht werden muss).

Hybride Speicheroptionen

Obwohl NetApp empfiehlt, für alle Knoten in SQL Server-Verfügbarkeitsgruppen denselben Speicher zu verwenden, gibt es Szenarien, in denen mehrere Speicheroptionen verwendet werden können. Dieses Szenario ist für Azure NetApp Files möglich, bei dem ein Knoten in AOAG mit einer Azure NetApp Files SMB-Dateifreigabe und der zweite Knoten mit einem Azure Premium-Datenträger verbunden ist. Stellen Sie in diesen Fällen sicher, dass die Azure NetApp Files SMB-Freigabe die primäre Kopie der Benutzerdatenbanken enthält und der Premium-Datenträger als sekundäre Kopie verwendet wird.

Anmerkungen:

  • Um bei solchen Bereitstellungen Failover-Probleme zu vermeiden, stellen Sie sicher, dass die kontinuierliche Verfügbarkeit auf dem SMB-Volume aktiviert ist. Ohne kontinuierlich verfügbares Attribut kann es zu einem Datenbankausfall kommen, wenn auf der Speicherebene im Hintergrund Wartungsarbeiten durchgeführt werden.

  • Bewahren Sie die primäre Kopie der Datenbank auf der SMB-Dateifreigabe von Azure NetApp Files auf.

Geschäftskontinuität

Die Notfallwiederherstellung wird bei jeder Bereitstellung im Allgemeinen erst im Nachhinein berücksichtigt. Um Auswirkungen auf Ihr Unternehmen zu vermeiden, muss die Notfallwiederherstellung jedoch bereits in der anfänglichen Entwurfs- und Bereitstellungsphase berücksichtigt werden. Mit Azure NetApp Files kann die Funktion zur regionsübergreifenden Replikation (CRR) verwendet werden, um die Volumedaten auf Blockebene in die gepaarte Region zu replizieren und so unerwartete regionale Ausfälle zu bewältigen. Das CRR-fähige Zielvolume kann für Lesevorgänge verwendet werden, was es zu einem idealen Kandidaten für Notfallwiederherstellungssimulationen macht. Darüber hinaus kann dem CRR-Ziel das niedrigste Servicelevel (z. B. Standard) zugewiesen werden, um die Gesamtbetriebskosten zu senken. Im Falle eines Failovers kann die Replikation unterbrochen werden, wodurch das jeweilige Volume lese-/schreibfähig wird. Außerdem kann das Servicelevel des Volumes mithilfe der dynamischen Servicelevel-Funktionalität geändert werden, um die Kosten für die Notfallwiederherstellung erheblich zu senken. Dies ist eine weitere einzigartige Funktion von Azure NetApp Files mit Blockreplikation innerhalb von Azure.

Langzeit-Snapshot-Kopiearchiv

Viele Organisationen müssen aufgrund zwingender Compliance-Anforderungen Snapshot-Daten aus Datenbankdateien langfristig aufbewahren. Obwohl dieser Prozess in diesem HLD nicht verwendet wird, kann er leicht durch die Verwendung eines einfachen Batch-Skripts erreicht werden, indem "AzCopy" um das Snapshot-Verzeichnis in den Azure Blob-Container zu kopieren. Das Batch-Skript kann basierend auf einem bestimmten Zeitplan mithilfe geplanter Aufgaben ausgelöst werden. Der Vorgang ist unkompliziert und umfasst die folgenden Schritte:

  1. Laden Sie die ausführbare Datei AzCopy V10 herunter. Es muss nichts installiert werden, da es sich um eine exe Datei.

  2. Autorisieren Sie AzCopy mithilfe eines SAS-Tokens auf Containerebene mit den entsprechenden Berechtigungen.

  3. Nachdem AzCopy autorisiert wurde, beginnt die Datenübertragung.

Anmerkungen:

  • Achten Sie in Batchdateien darauf, die %-Zeichen, die in SAS-Token erscheinen, mit Escapezeichen zu versehen. Dies kann durch Hinzufügen eines zusätzlichen %-Zeichens neben vorhandenen %-Zeichen in der SAS-Tokenzeichenfolge erfolgen.

  • Der "Sichere Übertragung erforderlich" Die Einstellung eines Speicherkontos bestimmt, ob die Verbindung zu einem Speicherkonto mit Transport Layer Security (TLS) gesichert ist. Diese Einstellung ist standardmäßig aktiviert. Das folgende Batchskriptbeispiel kopiert rekursiv Daten aus dem Snapshot-Kopierverzeichnis in einen bestimmten Blob-Container:

SET source="Z:\~snapshot"
echo %source%
SET dest="https://testanfacct.blob.core.windows.net/azcoptst?sp=racwdl&st=2020-10-21T18:41:35Z&se=2021-10-22T18:41:00Z&sv=2019-12-12&sr=c&sig=ZxRUJwFlLXgHS8As7HzXJOaDXXVJ7PxxIX3ACpx56XY%%3D"
echo %dest%

Der folgende Beispielbefehl wird in PowerShell ausgeführt:

 –recursive
INFO: Scanning...
INFO: Any empty folders will not be processed, because source and/or destination doesn't have full folder support
Job b3731dd8-da61-9441-7281-17a4db09ce30 has started
Log file is located at: C:\Users\niyaz\.azcopy\b3731dd8-da61-9441-7281-17a4db09ce30.log
0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total,
INFO: azcopy.exe: A newer version 10.10.0 is available to download
0.0 %, 0 Done, 0 Failed, 2 Pending, 0 Skipped, 2 Total,
Job b3731dd8-da61-9441-7281-17a4db09ce30 summary
Elapsed Time (Minutes): 0.0333
Number of File Transfers: 2
Number of Folder Property Transfers: 0
Total Number of Transfers: 2
Number of Transfers Completed: 2
Number of Transfers Failed: 0
Number of Transfers Skipped: 0
TotalBytesTransferred: 5
Final Job Status: Completed

Anmerkungen:

  • Eine ähnliche Sicherungsfunktion für die langfristige Aufbewahrung wird bald in Azure NetApp Files verfügbar sein.

  • Das Batch-Skript kann in jedem Szenario verwendet werden, in dem Daten in den Blob-Container einer beliebigen Region kopiert werden müssen.

Kostenoptimierung

Durch Volume-Reshaping und dynamische Service-Level-Änderungen, die für die Datenbank völlig transparent sind, ermöglicht Azure NetApp Files kontinuierliche Kostenoptimierungen in Azure. Diese Funktion wird in diesem HLD umfassend genutzt, um eine Überbereitstellung von zusätzlichem Speicher zur Bewältigung von Arbeitslastspitzen zu vermeiden.

Die Größenänderung des Volumes kann einfach durch Erstellen einer Azure-Funktion in Verbindung mit den Azure-Warnprotokollen erfolgen.