Testen Ihrer Einsätze

In diesem Abschnitt werden Infrastrukturtests beschrieben, die leicht durchgeführt werden können, um Ihre Bereitstellungen zu testen.

Leistungstests für das Speichersubsystem des SQL-Servers

Es ist eine gute Praxis, die Leistung des Speichersubsystems zu testen. Bei diesem Test wird das Tool Diskspd verwendet, um die Festplattenleistung zu testen. Diskspd ist ein von Microsoft entwickeltes Tool für Speichertests. Es handelt sich um ein Befehlszeilendienstprogramm, das über eine Reihe von Parametern verfügt. In unseren Tests wurden die folgenden Befehle verwendet, um jedes Laufwerk zu testen:

cd C:\Users\Administrator\Downloads
.\diskspd.exe -c100G -d300 -r -w40 -t4 -o2 -b64K -Sh -L D:\testfile.dat > TestData.txt
.\diskspd.exe -c100G -d300 -r -w40 -t4 -o2 -b64K -Sh -L E:\testfile.dat > TestLog.txt
.\diskspd.exe -c100G -d300 -r -w40 -t4 -o2 -b64K -Sh -L F:\testfile.dat > TestTempDB.txt

Die Befehlsoptionen sind wie folgt:

- -c100G- Erzeugt eine 100GB Datei namens testfile.dat auf dem zu testenden Volume.
- -d300- Ein Messzeitraum von 300 Sekunden (5 Min.).
- r- Zufälliger E/A-Zugriff.
- -w40- 40% Schreibanforderungen, 60% Leseanforderungen. Dies ist eine typische Belastung für SQL Server OLTP-Datenbanken.
- -t4- Die Anzahl der Threads pro Datei und sollte ein Thread pro verfügbarer vCPU sein.
- -o2- Die Anzahl der ausstehenden E/A-Anforderungen pro Ziel und Thread, d. h. die Tiefe der Warteschlange.
- -b64K- 64KB Blockgröße, die typisch für SQL Server ist.
- Sh- Deaktiviert sowohl das Software-Caching als auch das Hardware-Schreibcaching.
- L- Misst Latenzstatistiken.

Die Ergebnisse werden in den txt-Dateien festgehalten. Als Leitfaden für die Interpretation der Ergebnisse:

Der Abschnitt Total IO liefert Statistiken (Read+Write) pro Thread.
Die letzte Zeile im Abschnitt Total IO enthält die Gesamtwerte für den gesamten Testlauf.
Die Gesamt-MB/s sollten nahe an den MiBps in der IBM Cloud für das Volume liegen, es sei denn, es wurden mehrere Volumes gestriped.
AvgLat ist die durchschnittliche Latenzzeit.
Die nächsten beiden Abschnitte enthalten die Statistiken für die Lese- und Schreibvorgänge.
< Eine Latenzzeit von weniger als 5ms wird als gut angesehen

Die zusammengefassten Ergebnisse werden in den folgenden Abschnitten dargestellt.

Daten liefern Ergebnisse

Die wichtigsten Informationen aus dem Test lauten wie folgt:

diskspd.exe -c100G -d300 -r -w40 -t4 -o2 -b64K -Sh -L D:\testfile.dat

Daten liefern Ergebnisse
Ein-/Ausgabe	MiB/s	IOPS	Durchschnittliche Latenzzeit
Gesamte E/A	82.03	1312.45	6.088
E/A lesen	49.20	787.14	7.282
E/A schreiben	32.83	525.30	4.298

Laufwerksergebnisse protokollieren

Die wichtigsten Informationen aus dem Test lauten wie folgt:

diskspd.exe -c100G -d300 -r -w40 -t4 -o2 -b64K -Sh -L E:\testfile.dat

Laufwerksergebnisse protokollieren
Ein-/Ausgabe	MiB/s	IOPS	Durchschnittliche Latenzzeit
Gesamte E/A	82.03	1312.49	6.088
E/A lesen	49.20	787.13	7.101
E/A schreiben	32.83	525.36	4.570

Tempdb-Laufwerksergebnisse

Die wichtigsten Informationen aus dem Test lauten wie folgt:

diskspd.exe -c100G -d300 -r -w40 -t4 -o2 -b64K -Sh -L F:\testfile.dat

Tempdb-Laufwerksergebnisse
Ein-/Ausgabe	MiB/s	IOPS	Durchschnittliche Latenzzeit
Gesamte E/A	223.58	3577.33	2.231
E/A lesen	134.11	2145.77	3.615
E/A schreiben	89.47	1431.56	0.156

Failover-Tests

Die Ausfallsicherheitsprüfung besteht aus zwei Tests:

Ausfallsicherungstests für Verfügbarkeitsgruppen

Führen Sie die folgenden Schritte aus, um die Ausfallsicherung der Verfügbarkeitsgruppe zu testen:

RDP zum Bastion-Server.
Stellen Sie eine Verbindung zum primären Replikat her, indem Sie das auf dem Bastion-Server gehostete SQL Server Management Studio (SSMS) verwenden.
Erweitern Sie im Objekt-Explorer die Gruppe Always On Availability Group.
Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe und wählen Sie Failover, um den Failover-Assistenten zu öffnen.
Folgen Sie den Anweisungen, um ein Failover-Ziel auszuwählen und die Verfügbarkeitsgruppe auf ein sekundäres Replikat zu übertragen.
Bestätigen Sie, dass sich die Datenbank auf dem neuen primären Replikat in einem synchronisierten Zustand befindet.
Kehren Sie zur ursprünglichen Primärdatenbank zurück und bestätigen Sie, dass die Datenbank synchronisiert ist.

Prüfung der Ausfallsicherheit von Verbindungen

Gehen Sie folgendermaßen vor, um die Verbindung zum DNN-Listener zu testen:

RDP zum Bastion-Server.
Öffnen Sie das auf dem Bastion-Server gehostete SQL Server Management Studio (SSMS).
Verbinden Sie sich mit dem DNN-Listener.
Öffnen Sie ein neues Abfragefenster und führen Sie die Abfrage SELECT @@SERVERNAME aus, um zu prüfen, welche Replik verbunden ist.
Failover der Verfügbarkeitsgruppe auf ein sekundäres Replikat.
Führen Sie SELECT @@SERVERNAME erneut aus, um zu bestätigen, dass Ihre Verfügbarkeitsgruppe jetzt auf dem sekundären Replikat gehostet wird. Möglicherweise müssen Sie diesen Vorgang mehrmals wiederholen/ Es ist wichtig, die Failover-Zeit in Ihrer Umgebung zu verstehen

Datenbank-Lasttests

Es gibt eine Reihe von kostenlosen, quelloffenen oder lizenzierten Lasttest-Tools. HammerDB ist ein quelloffenes Tool, mit dem Sie die Leistung einer SQL Server demonstrieren können. Sie können dieses Tool auf den Bastion-Host herunterladen und es zum Lasttest des SQL-Servers verwenden:

Laden Sie HammerDB-4.1 mit den folgenden PowerShell auf den Bastion-Host herunter:

$client = new-object System.Net.WebClient
$client.DownloadFile("https://github.com/TPC-Council/HammerDB/releases/download/v4.1/HammerDB-4.1-Win-x64-Setup.exe","C:\Users\Administrator\Downloads\HammerDB-4.1-Win-x64-Setup.exe")

Folgen Sie der Methode des selbstextrahierenden Installers unter Installation und Start von HammerDB unter Windows, um HammerDB auf dem Bastion-Host zu installieren.
Folgen Sie dem Quick Start, um HammerDB so zu konfigurieren, dass ein Lasttest auf dem requiredSQL durchgeführt wird.

Lesen Sie die Informationen unter HammerDB Best Practice for SQL Server Performance and Scalability.

Für andere Versionen von HammerDB, siehe HammerDB Download.