SQL Server in Microsoft Azure: Wie man durch Flexibilität Leistung gewinnt und zugleich Kosten spart
Diesmal widme ich mich erstmalig in einem Artikel den Thema Microsoft Azure.
(Microsoft.com: Was ist Microsoft Azure?)
Unter Microsoft Azure werden mittlerweile eine Unmenge an Diensten bereitgestellt, und einer davon ist das Hosting von virtuellen Maschinen, in denen ein SQL Server Dienst läuft. Hierbei sprechen wir also von IaaS (Infrastructure as a Service).
– Hier wird dieses Service-Modell nähergehend erläutert und unter anderem auch dem PaaS-Ansatz gegenübergestellt:
Which Windows Azure Cloud Architecture? PaaS or IaaS?
Eine schöne gegenüberstellende Grafik findet sich in diesem Blog-Artikel:
Windows Azure IaaS vs. PaaS vs. SaaS
Nachdem man sich einmal entschieden hat, dass das Konzept IaaS für einen Teil der eigenen Umgebung Sinn macht, steht die Frage der Konfiguration der SQL Server Systeme an.
Hier werden in dem Azure Portal fertige Images angeboten, die gerade Einsteigern den Zugang erleichtern sollen.
– Tatsächlich kann man mit nur 7 Klicks einen Windows Server inklusive lizensierten SQL Server einrichten, wenn man eine Vorlage aus der Galerie verwendet.
Für den produktiven Einsatz von SQL Server muss man sich jedoch etwas mehr Mühe geben, denn die Standard-Vorlagen enthalten nur eine Daten-Disk, und auf der liegt das Betriebssystem. – Dort möchte man seinen SQL Server aus mehreren Gründen nicht betreiben.
Neben Datenintegrität ist das die IO-Performance.
Microsoft stellt daher auch sogenannte „optimized“ Images – für entweder OLTP- oder OLAP-Szenarien – zur Verfügung (im Screenshot rot umrahmt), welche direkt mit 15 weiteren Data Disks kommen, was dann insgesamt 16 macht.
1) Variante 1, der „traditionelle Ansatz“ ist also: mehrere Data Disks und eine Maschine mit entsprechender Unterstützung/CPU-Power.
Die in diesem Fall 15 Daten Disks (zusätzlich zu der OS Disk) werden in 2 Storage Pools zu je 12 bzw. 3 Disks für SQL-Daten und SQL-Logs vorkonfiguriert.
Die maximalen IOPS hängen auch von den zur Verfügung stehenden CPU-Cores ab. Lineare Performance-Steigerungen sollte man auch nicht erwarten.
Das Problem hierbei: Man verliert dabei fast jegliche Flexibilität.
Und zwar hinsichtlich der Ausbaustufe (Performance) und damit letztlich auch in der Preisgestaltung.
Denn um die insgesamt 16 Data Disks zu verwenden, muss man mindestens eine der 8-Core VM-Größen betreiben (A4, A7, A8, A9, D4, D13, D14, G3, G4 und G5), durchgängig.
Lediglich nach oben kann man Skalieren.
– Wer mehr als 16 zusätzliche Datenträger benötigt, muss eine VM mit 16 bzw. 32 Cores (G-Serie) einsetzen und erhält dann die Möglichkeit bis zu 32 bzw. 64 Data Disks neben der OS Disk einzusetzen.
Nach unten ist man dann auf jeden Fall preislich festgelegt.
Damit dürfte das Ziel, Kosten durch Cloud-basierte Systeme zu sparen, jedoch schwieriger zu erreichen sein.
Die große Stärke des Cloud-basierten Ansatzes ist es aber, möglichst genau nur dann, wenn man eine bestimmte Leistung (oder Dienst) benötigt, diese anzufordern & zu erhalten, und wenn man sie nicht benötigt, diese auch nicht nutzlos „aktiviert“ zu belassen. Denn man bezahlt ja, was man „abonniert“, was hier nicht unbedingt auch das ist, was man wirklich nutzt.
Unser ideales System sollte also maximal skalierbar sein, und zwar sowohl nach oben und nach unten.
Wenn man sich einmal die Tabellen mit den derzeitigen (Stand 30.4.2015) virtuellen Maschinen und deren Performance-Kerngrößen vor Augen führt, wird es sicherlich klarer.
Es gibt derzeit 3 Serien auf dem Standard-Tier: A, D und G, wobei die G-Serie die mit der größten Power ist – und damit auch am teuersten.
Zu sehen sind die Anzahl der dedizierten CPU-Cores, die Größe des Arbeitsspeichers, die Größe der Temp-Disk, und, ganz wichtig für die Skalierbarkeit: die Anzahl der maximal erlaubten Datenträger neben der OS-Disk selber.
Pro Datendisk erhält man bis zu 500 IOPS. Um mehr IOPS zu erhalten, benötigt man also mehr Data Disks – aber auch mehr CPU Cores.
Wenn man jedoch eine Maschine mit 16 Data Disks verwendet, kann man in Zeiten geringerer Auslastung kaum herunter-skalieren. Eine A2 beispielsweise für eine Art Minimal-Betrieb ist damit unerreichbar. Und wenn man noch mehr Data Disks benötigt um IO-Peaks abfangen zu können, schränkt man sich noch mehr ein und muss dauerhaft die teuersten Maschinen bezahlen.
Welche Alternativen gibt es? Wie kann man flexibel sein, um Kosten zu sparen, und gleichzeitig je nach Bedarf auf höhere Maschinen wechseln („Scale-Up“), und auf der anderen Seite nachts oder an Wochenenden seine Maschinen auf minimale CPU’s beschränkt („Scale-Down“)?
2) Speichern der Data-Files direkt auf Azure Blob-Store
Der offensichtliche Vorteil ist hierbei, dass man keine Data-Disks benötigt – und die sind es, die die Skalierungsmöglichkeiten wesentlich beschränken. Anstelle der Data Disks werden die SQL Server Datenbankdateien direkt im Blob-Store gespeichert.
Die Datenbank-Erstellung kann dann so aussehen:
Diese Möglichkeit wird seit SQL Server 2014 unterstützt.
Hierbei erhält man ebenfalls pro File 500 IOPS, mit einem Limit von 20.000 je Storage Account, welches generell gilt.
Hier findet sich ein ausführliches Beispiel zur Einrichtung samt Code:
Create a SQL Server 2014 Database directly on Azure Blob storage with SQLXI
Der Nachteil bei dieser Variante ist in meinen Augen die Komplexität. Das Vorgehen mit Einrichtung der Shared Access Signature, die für den Zugriff auf den Blob-Container benötigt wird, ist nicht direkt trivial.
3) Speichern der Data-Files auf einer Azure Datei-Freigabe
Seit Mai letzten Jahres ist der Azure File-Service (Introducing Microsoft Azure File Service) als Vorschaufeature verfügbar.
Neben „echten“ Verzeichnissen unterstützt dieser Dienst auch Freigaben auf Basis von SMB 2.1.
Hier gibt es ein Maximum an 1000 IOPS pro Share. Das heißt ich benötige für dieselbe Menge an IOPS nur halb so viele Dateien wie für den Direkt-Zugriff auf Azure Blobs.
Wichtig ist, dass man zunächst das Preview-Feature für einen Storage-Account aktiviert hat.
Danach erzeugt man per PowerShell die notwendigen Shares und verteilt seine Datenbank-Dateien darauf.
Auch hier gilt natürlich die Begrenzung auf die maximalen 20.000 IOPS je Storage Account. Aber der Zugriff ist in meinen Augen wesentlich einfacher.
Ein Nachteil dieser Variante ist, dass man dafür sorgen muss, dass der SQL Server Dienst erst startet, wenn die Freigaben über Netzwerk auch erreichbar sind.
Abseits von manchmal auftretenden Zugriffsproblemen, die sicherlich dem Preview-Stand geschuldet sind, ist diese Kombination in meinen Augen die am Einfachsten zu Administrierende, nachdem man sich einmal an einen automatisch gesteuerten verzögerten Dienst-Start gewöhnt hat.
Der Azure-File-Dienst wird zurzeit mit 50% Rabatt angeboten, und liegt damit rund 20% unter den Azure-Blob-Storage-Preisen.
Der Vorteil der beiden letzten Varianten liegt klar auf der Hand: man ist nicht an eine bestimmte Ausbaustufe des Systems gebunden, sondern kann zu bestimmten Zeiten seinen SQL Server auf einer Maschine mit weit mehr oder auch weit weniger CPU-Cores starten.
Ein Wort noch zum Transaktionsprotokoll:
Pro Datenbank gibt es nur eine Log-Datei (mehrere Log-Dateien würden sequentiell beschrieben werden und keinerlei Performance-Vorteile bringen). Dort bringen File-Shares direkt den Vorteil, anstelle von 500 IOPS 1000 IOPS zu liefern. Wenn das nicht ausreicht, bleibt leider nur der traditionelle Ansatz im Zusammenspiel mit Windows Server Storage Spaces: ein Striping aus mehreren Data-Disks für das Transaktionsprotokoll mit dem entsprechenden Skalierbarkeitsnachteil.
Ich hoffe, ich konnte in diesem Artikel den für mich wichtigsten Vorteil des Cloud-basierten Ansatzes am Beispiel SQL Server etwas näherbringen. Sobald man sich einmal an das „Service-Konzept“ der Cloud gewöhnt hat, und traditionelle Denkmuster in der Form von „Ich benötige eine x-Core-Maschine“ hinter sich lassen kann, kann man durch das Kombinieren von verschiedenen Diensten, wie hier Virtuellen Maschinen und Dateidiensten, sehr kosten- und performance-effiziente Systeme bauen.
Und natürlich sind nicht immer IOPS das Maß der Dinge. Ich habe diese nur zur Vereinfachung über MB/sec gewählt und auch ohne auf die Request-Größe Rücksicht zu nehmen. Im Allgemeinen sind die Werte auf Basis von 4-K sequentiellen Lese-Requests zu verstehen. Das gilt aber für alle Speichermechanismen, die hier angesprochen wurden, und sollte daher zum Zwecke der Vergleichbarkeit ausreichen.
Wer Interesse hat, sich mit dem Thema noch mehr auseinanderzusetzen ist herzlich willkommen auf dem SQLSaturday Rheinland, einer 1-tägigen kostenfreien Konferenz für SQL Server am 13. Juni in Sankt Augustin.
Und am 12. Juni, also den Tag davor gibt es eine ebenso kostenfreie PreCon, „Hybrid IT Camp: Azure Szenarien & die eigene flexible Infrastruktur für jedermann“. (Short Link: http://bit.ly/sqlsat409hybridit), die ich zusammen mit Patrick Heyde von Microsoft (Blog/Twitter) durchführe.
Hier noch eine Liste an weiterführenden Links:
- Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen
- Preise für Azure-Speicher
- Create a SQL Server 2014 Database directly on Azure Blob storage with SQLXI
- Introducing Microsoft Azure File Service
- Verwenden des Azure-Dateispeichers
- Microsoft Azure Vorschaufeatures
- Wie skaliert man eine Azure SQL Datenbank on Demand und vollautomatisch
- Best Practices & Disaster Recovery for Storage Spaces and Pools in Azure
- New VM Images Optimized for Transactional and DW workloads in Azure VM Gallery
Have fun on Azure cloud
Andreas
P.S.: Noch ein explizites Dankeschön an Patrick Heyde für seine wertvollen Tipps und Mentoring in Microsoft Azure – auch ich musste mich ja erst einmal an eine neue Denkweise gewöhnen 🙂
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!