Zu berücksichtigende Faktoren
Änderungen vorschlagen
PDFs
In diesem Abschnitt werden die verschiedenen Probleme beschrieben, die bei Azure NetApp Files mit SQL Server in der Cloud zu berücksichtigen sind.
VM-Performance
Für die optimale Performance einer relationalen Datenbank in einer Public Cloud ist die Auswahl der richtigen VM-Größe wichtig. Microsoft empfiehlt, weiterhin dieselben Optionen zur Verbesserung der Datenbank-Performance zu verwenden, die für SQL Server in lokalen Serverumgebungen relevant sind. Nutzung "Speicheroptimierung" VM-Größen für die beste Performance von SQL Server Workloads Sammeln der Performance-Daten einer vorhandenen Bereitstellung, um die RAM- und CPU-Auslastung zu identifizieren und gleichzeitig die richtigen Instanzen auszuwählen Die meisten Implementierungen wählen zwischen der D-, E- oder M-Serie.
Hinweise:
-
Verwenden Sie für die beste Performance von SQL Server Workloads eine speicheroptimierte VM-Größe.
-
NetApp und Microsoft empfehlen, die Anforderungen an die Storage-Performance zu identifizieren, bevor Sie den Instanztyp mit dem entsprechenden Speicher-zu-Vcore-Verhältnis auswählen. Dadurch ist auch die Auswahl eines Instanztyps mit der richtigen Netzwerkbandbreite möglich, um die Storage-Durchsatzbegrenzungen der VM zu überwinden.
VM-Redundanz
Um Redundanz und Hochverfügbarkeit zu erhöhen, sollten SQL Server VMs sich entweder in derselben befinden "Verfügbarkeitsgruppe" Oder anders "Verfügbarkeitszonen". Bei der Erstellung von Azure VMs müssen Sie zwischen der Konfiguration von Verfügbarkeitsgruppen und den Verfügbarkeitszonen wählen. Eine Azure VM kann nicht an beiden teilnehmen.
Hochverfügbarkeit
Für hohe Verfügbarkeit ist die Konfiguration von SQL Server AOAG oder Always On Failover Cluster Instance (FCI) die beste Option. Bei AOAG werden mehrere Instanzen von SQL Server auf Azure Virtual Machines in einem virtuellen Netzwerk durchgeführt. Wenn auf Datenbankebene eine hohe Verfügbarkeit erforderlich ist, sollten Sie die Konfiguration von SQL Server-Verfügbarkeitsgruppen in Betracht ziehen.
Storage-Konfiguration
Microsoft SQL Server kann mit SMB-Dateifreigaben als Storage-Option implementiert werden. Beginnend mit SQL Server 2012, Systemdatenbanken (Master, Model, msdb oder tempdb), Zudem können Benutzerdatenbanken mit dem Server Message Block (SMB)-Dateiserver als Storage-Option installiert werden. Dies gilt sowohl für Standalone-SQL Server als auch für SQL Server FCI.
|
File Share Storage für SQL Server-Datenbanken sollte kontinuierlich verfügbare Eigenschaft unterstützen. Dadurch ist unterbrechungsfreier Zugriff auf die Dateifreigabedaten möglich. |
Azure NetApp Files bietet hochperformanten File-Storage für jeden anspruchsvollen Workload und reduziert die TCO von SQL Server im Vergleich zu Block-Storage-Lösungen. Bei Block-Storage haben VMs Beschränkungen für I/O und Bandbreite für Festplattenoperationen festgelegt. Beschränkungen der Netzwerkbandbreite allein werden auf Azure NetApp Files angewendet. Das heißt, auf Azure NetApp Files werden keine I/O-Limits auf VM-Ebene angewendet. Ohne diese I/O-Limits kann SQL Server auf kleineren, mit Azure NetApp Files verbundenen VMs ihre Performance ebenso wie SQL Server auf wesentlich größeren VMs liefern. Azure NetApp Files senken die Implementierungskosten für SQL Server durch niedrigere Computing- und Softwarelizenzkosten. Detaillierte Kostenanalysen und Performance-Vorteile der Verwendung von Azure NetApp Files für SQL Server-Implementierungen finden Sie im "Vorteile der Nutzung von Azure NetApp Files für die SQL Server-Implementierung".
Vorteile
Die Verwendung von Azure NetApp Files für SQL Server bietet u. a. folgende Vorteile:
-
Durch den Einsatz von Azure NetApp Files können kleinere Instanzen verwendet und somit die Computing-Kosten gesenkt werden.
-
Azure NetApp Files reduziert auch die Kosten für Softwarelizenzen und dadurch die TCO insgesamt.
-
Die Volume-Umgestaltung und die dynamische Service Level-Funktion optimieren die Kosten, indem sie für stabile Workloads angepasst werden und eine Überprovisionierung vermieden wird.
Hinweise:
-
Um Redundanz und Hochverfügbarkeit zu erhöhen, sollten SQL Server VMs sich entweder in derselben befinden "Verfügbarkeitsgruppe" Oder in einem anderen "Verfügbarkeitszonen". Beachten Sie die Dateipfadanforderungen, wenn benutzerdefinierte Datendateien erforderlich sind; wählen Sie in diesem Fall SQL FCI über SQL AOAG aus.
-
Der folgende UNC-Pfad wird unterstützt: "\\ANFSMB-b4ca.anf.Test\SQLDB und \\ANFSMB-b4ca.anf.Test\SQLDB\".
-
Der Loopback UNC-Pfad wird nicht unterstützt.
-
Verwenden Sie für die Dimensionierung historische Daten aus Ihrer lokalen Umgebung. Bei OLTP-Workloads passen Sie die Ziel-IOPS den Performance-Anforderungen an, wobei Workloads mit durchschnittlichen und Spitzenzeiten sowie den Leistungszählern für Festplattenzugriffe/s und Festplattenschreibvorgänge/s verwendet werden. Bei Data Warehouse- und Reporting-Workloads wird der Zieldurchsatz anhand von Workloads mit durchschnittlichen und Spitzenzeiten sowie den Byte/s der Festplattenschreibdaten und den Byte/Sek. des Festplattenschreibvorgangs angepasst Die Durchschnittswerte können zusammen mit den Funktionen zur Volumenumformung verwendet werden.
Kontinuierlich verfügbare Shares erstellen
Kontinuierlich verfügbare Shares erstellen mit dem Azure Portal oder der Azure CLI Wählen Sie im Portal die Option Eigenschaft kontinuierliche Verfügbarkeit aktivieren aus. Geben Sie bei der Azure-CLI die Freigabe als kontinuierlich verfügbare Freigabe über das an az netappfiles volume create with the smb-continuously-avl Die Option ist auf eingestellt $True. Weitere Informationen zum Erstellen eines neuen, für kontinuierliche Verfügbarkeit bestimmten Volumes finden Sie unter "Erstellen einer kontinuierlich verfügbaren Freigabe".
Hinweise:
-
Sorgen Sie für eine kontinuierliche Verfügbarkeit des SMB Volume, wie in der folgenden Abbildung dargestellt.
-
Wenn ein Domain-Konto ohne Administrator verwendet wird, stellen Sie sicher, dass dem Konto die erforderliche Sicherheitsberechtigung zugewiesen ist.
-
Legen Sie die entsprechenden Berechtigungen auf Share-Ebene und die entsprechenden Berechtigungen auf Dateiebene fest.
-
Eine kontinuierlich verfügbare Eigenschaft kann auf vorhandenen SMB Volumes nicht aktiviert werden. Um ein vorhandenes Volume zu konvertieren, wird ein kontinuierlich verfügbarer Share verwendet. Nutzen Sie die NetApp Snapshot Technologie. Weitere Informationen finden Sie unter "Vorhandene SMB Volumes werden konvertiert, um kontinuierliche Verfügbarkeit zu nutzen".
Leistung
Azure NetApp Files unterstützt drei Service-Level: Standard (16 Mbit/s pro Terabyte), Premium (64 Mbit/s pro Terabyte) und Ultra (128 Mbit/s pro Terabyte). Die Bereitstellung der passenden Volume-Größe ist für eine optimale Performance des Datenbank-Workloads wichtig. Bei Azure NetApp Files basieren die Volume-Performance und die Durchsatzbegrenzung auf einer Kombination der folgenden Faktoren:
-
Der Service Level des Kapazitäts-Pools, zu dem das Volume gehört
-
Der dem Volume zugewiesene Kontingent
-
Die QoS-Art (Quality of Service) (automatisch oder manuell) des Kapazitäts-Pools
Weitere Informationen finden Sie unter "Service-Level für Azure NetApp Files".
Performance-Validierung
Wie bei jeder Implementierung sind auch VM- und Storage-Tests entscheidend. Für die Storage-Validierung Tools wie HammerDB, Apploader, die "SQL Server Storage Benchmark-Tool (SB)", Oder jedes benutzerdefinierte Skript oder FIO mit der entsprechenden Lese-Schreib-Mischung verwendet werden sollte. Man sollte jedoch daran denken, dass die meisten SQL Server Workloads, selbst überlastete OLTP-Workloads, näher bei 80–90 % Lese- und 10–20 % Schreibvorgängen liegen.
Um die Performance zu demonstrieren, wurde für ein Volume ein kurzer Test mithilfe von Premium-Service-Leveln durchgeführt. In diesem Test wurde die Volume-Größe spontan von 100 GB auf 2 TB erhöht, ohne dass der Applikationszugriff unterbrochen wird und keine Datenmigration erforderlich ist.
Hier sehen Sie ein weiteres Beispiel für Echtzeit-Performance-Tests mit HammerDB für die in diesem Dokument behandelte Implementierung. Für diese Tests haben wir eine kleine Instanz mit acht vCPUs, einer 500 GB Premium SSD und einem 500 GB SMB Azure NetApp Files Volume verwendet. HammerDB wurde mit 80 Lagerhäusern und acht Anwendern konfiguriert.
Das folgende Diagramm zeigt, dass Azure NetApp Files bei einem Volume einer vergleichbaren Größe (500 GB) eine 2,6-mal so viele Transaktionen pro Minute liefern konnte.
Ein zusätzlicher Test wurde durchgeführt, indem die Größe auf eine größere Instanz mit 32x vCPUs und einem 16-TB-Azure NetApp Files Volume angepasst wurde. Die Anzahl der Transaktionen pro Minute wurde mit einer konsistenten Latenz von 1 ms deutlich erhöht. HammerDB wurde für diesen Test mit 80 Lagerhäusern und 64 Anwendern konfiguriert.
Kostenoptimierung
Azure NetApp Files ermöglicht eine unterbrechungsfreie, transparente Volume-Anpassung und das Ändern der Service Level ohne Ausfallzeiten und Beeinträchtigung von Applikationen. Dies ist eine einzigartige Funktion für ein dynamisches Kostenmanagement, das die Datenbankdimensionierung mit Metriken nicht mehr erfordert. Sie können stattdessen stabile Workloads verwenden, wodurch Vorlaufkosten vermieden werden. Durch die Volume-Umgestaltung und die dynamische Service Level-Änderung können Sie die Bandbreite und das Service Level von Azure NetApp Files Volumes nahezu sofort und ohne Unterbrechung des I/O-Zugriffs anpassen und den Datenzugriff erhalten.
Mit Azure PaaS-Angeboten wie LogicApp oder Funktionen kann die Volume-Größe anhand eines bestimmten Web-Hook- oder Alarm-Regelauslösens problemlos angepasst werden, um die Workload-Anforderungen zu erfüllen und gleichzeitig die Kosten dynamisch zu bewältigen.
Nehmen wir beispielsweise an, eine Datenbank, die 250 MB/s für den stabilen Betrieb benötigt, benötigt jedoch auch einen Spitzendurchsatz von 400 MB/s. In diesem Fall sollte die Implementierung mit einem 4-TB-Volume innerhalb des Premium Service-Levels durchgeführt werden, um die Performance-Anforderungen in stabilem Zustand zu erfüllen. Um Spitzenlasten zu kompensieren, erhöhen Sie die Volume-Größe mithilfe von Azure Funktionen für diesen speziellen Zeitraum auf 7 TB und verkleinern Sie das Volume, um die Bereitstellung kostengünstig zu gestalten. Bei dieser Konfiguration wird eine Überprovisionierung des Storage vermieden.