Vorwort
Ein Kollege von mir hat mich die Tage angesprochen, dass er ein Performance-Problem mit einem nach Azure migrierten (P2V Migration) System habe. Also nicht er hat das Performance-Problem, sondern vielmehr der MSSQL Server auf der Kunden VM.
Nach kurzem Abgleich ist folgendes klar:
1. Der Kunde ist ein Budget-Kunde, sprich jeder € tut weh – und nein, SQL PaaS ist leider keine Option
2. der MSSQL Server ist fernab irgendeiner Best Practice installiert. So befinden sich alle Datenbank-Dateien, etc. auf der Betriebssystem-Disk
3. das Performance-Problem wird offenbar durch Disk-Latenzen hervorgerufen
4. der MSSQL Server ist vital für den Kunden
5. die Version des MSSQL Servers ist sagen wir mal mutig
6. eine längere Downtime benötigt einiges an Vorlaufzeit. Also muss eine rasche Lösung ohne längere Downtime her
Soweit ist klar, das hier Kreativität gefragt ist. Die Version des MSSQL Servers, als auch der Einsatz von SQL PaaS kommen aus den üblichen Gründen (Hersteller-Support, etc.) nicht in Frage.
Was sind also Maßnahmen, die einen Benefit bringen, aber nicht ins Geld gehen?
Maßnahmen
Was wären die üblichen Schritte soweit?
1. Aufteilen der Datenbankdateien auf eigene Disks (vorzugsweise Premium SSDs) mit 64k Blocksize – anschließend einen Abgleich der Datentransferraten durchführen (max IOPs und max Throughput)
2. Anheben der MSSQL Server Version
3. Saubere Konfiguration des (neuen) MSSQL Servers
Wie gesagt ist der MSSQL Server vital für den Kunden. Also gilt es eine längere Downtime zu vermeiden. Damit kommen wir zum ersten Punkt (Aufteilen der Datenbankdateien). Für eine schnelle Maßnahme verschieben wir die TempDB auf die „Temp-Disk“, die auf jeder SQL IaaS VM vorhanden ist. Vorteil ist, dass dies „nur“ einen Neustart des SQL Server Dienstes Bedarf. Eine Anleitung bietet folgender Artikel: http://www.sqlservice.se/configure-sql-server-tempdb-on-ssds-in-azure-virtual-machines-iaas/
Außerdem wechseln wir noch die VM-Größe von E8s_v3 auf DS13_v2. Stimmt schon, dass diese VM-Größe rund 70€/Monat teurer ist und ich gesagt habe, dass der Kunde ein kleines Budget hat. Auf der anderen Seite sind die zu erwartenden Performancegewinne durch die höhere IO-Leistung der DS13_v2 groß genug um für ein paar (Paar) Monate die höhere Rate zu rechtfertigen.
Die E8s_v3 hat ein max. IOPS Volumen von 12800, die DS13_v2 von 25600 IOPS. Wichtig ist, dass sich diese Leistung über alle Disks aufteilt. Folglich liefert die DS13_v2 mehr IOPS pro Disk.
Zu guter Letzt werden noch sauber die Antivirus-Ausnahmen gesetzt.
https://support.microsoft.com/help/309422/choosing-antivirus-software-for-computers-that-run-sql-server
Fazit
Schon richtig, die Maßnahmen sind maximal ein Pflaster und die es Bedarf schon Mut so ein Konstrukt für eine kritische Komponente zu fahren. Auf der anderen Seite lief das System so die letzten Jahre und hat es überlebt. So ist also die Hoffnung, dass es auch noch etwas länger lebt.
Alle weitere Maßnahmen setzen eine saubere Planung und auch ein sauberes Testing voraus. So kann ich mir auch ein Rightsizing mit aktuellen CPUs, einer sauberen Implementierung sowie den Performanceoptimierungen der neueren SQL Server Versionen gut vorstellen. Heißt also weniger Cores und somit weniger Consumption-Kosten.