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:

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.

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.

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.

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".

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:

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:

Weitere Informationen finden Sie unter "Service-Level für Azure NetApp Files".

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.

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.