• English
Shop

| | Cloud Solutions 0

Installieren und Konfigurieren von Microsoft SQL Server 2014 in Azure mit Azure Files

Vorweg: Ich bin kein SQL-Server Profi. Aber ab und zu installiere und konfiguriere ich einen SQL Server. In diesem Fall möchte ich einen Microsoft SQL Server 2014 als IaaS in Azure installieren – SQL as a Service ist leider keine Option.

Aber wie ist ein SQL Server mit Fokus auf die Disks zu konfigurieren? Es ist best-practice jeweils eine dedizierte Disk für folgende Dateien zu verwenden:

  • Data files
  • Log files
  • TempDB data file
  • TempDB log file

In der klassischen Data Center Welt würde ich verschiedene RAID Level und/oder ein Enterprise Storage verwenden. In Azure habe ich drei andere Ansätze:

Verwenden von dedizierten Azure Standard Disks, verbunden mit der SQL Server VM:

  • Einfach und kostengünstig
  • Limitiert auf 500 IOPS pro Disk

Verwenden vom Azure Premium Storage (SSD), verbunden mit der SQL Server VM:

  • Extrem gute Performance
  • Sehr teuer!

Verwenden von Azure Files als Netzwerkfreigaben anstatt von Disks:

  • Einfach und günstig
  • Bis zu 1000 IOPS pro Freigabe

In diesem Fall verwende ich Azure Files.

Vorbereitung des Storage

Erstellen oder verwenden eines vorhandenen Storage Account in derselben Region, in der sich auch die SQL Server VM befindet. Achtung: Ein Storage Account kann bis zu 20000 IOPS liefern. Für den SQL Server muss der Storage Account noch 4000 IOPS liefern können.

Ich erstelle einen neuen Storage Account „sqldataonazure“ in der Region meiner SQL Server VM (Größe der VM: D2_V2):


Im Storage Account erzeuge ich 4 Azure File Shares mit einem Quota von 1024 GB:

  • sql-data
  • sql-log
  • sql-tempdb-data
  • sql-tempdb-log

 

Zum Mappen eines Azure File Shares (zum Beispiel von „sql-data“) liefert der Klick auf den Share -> Connect folgendes Kommando:

net use [drive letter] \\sqldataonazure.file.core.windows.net\sql-data /u:sqldataonazure [storage account access key]

Den Storage Account Access Key ist einsehbar über den Storage Account -> All settings -> Access keys ->key1 (oder key2)

Der Benutzername (sqldataonazure) und der Access Key (=Password) wird im folgenden Schritt verwendet.

Erstellen eines funktionalen Domänen Benutzer Accounts

Damit der SQL Server auf die Freigaben zugreifen kann, muss dessen Dienstaccount berechtigt werden. Leider lassen sich Azure Files nicht wie normale Freigaben berechtigen. Nur oben beschriebener Benutzer (sqldataonazure) hat Zugriff auf die Shares. Als Workaround wird deshalb im Active Directory ein Servicebenutzer erstellt, der exakt so heißt wir der Storage Account (sqldataonazure). Als Password wird der Storage Account Access Key hinterlegt:


Danach wird der Benutzer in die lokale Administratoren-Gruppe der zukünftigen SQL Server VM aufgenommen (der SQL Server selbst ist noch nicht installiert):

Nach Logoff und Login mit dem neuen Account (sqldataonazure) sind die Shares ohne Eingabe von Name/Password zugreifbar: Start -> Run -> \\sqldataonazure.file.core.windows.net\sql-data

Installieren des SQL Server 2014

Vor der Installation des SQL Servers muss über Roles and Features das Microsoft .Net Framework 3.5 SP1 installiert werden.

In dem Kontext des Service Benutzers (sqldataonazure) wird das Setup aus dem ISO Image (muss lokal liegen) gestartet:

Über Installation -> New SQL Server stand-alone… wird die Installation gestartet und bis zur Dienstekonfiguration (Server Configuration) durchgeführt.

Der Dienst SQL Server Database Engine und der SQL Server Agent werden so konfiguriert, dass sie im Kontext des Funktionsaccounts „sqldataonazure” starten:

In der „Database Engine Configuration / Data Directories“ werden die Azure Fileshares wie folgt hinterlegt:

Ein Klick auf „Yes“ bestätigt, dass die Rechte richtig sind:

Nach der Installation zeigt der Share \\sqldataonazure.file.core.windows.net\sql-data folgenden Inhalt:

\\sqldataonazure.file.core.windows.net\sql-tempdb-data

Konfiguration des SQL Server Dienst Service

Nach der Installation wird der Dienst (und ggf. der des Agents) so konfiguriert, dass verzögert startet. Das stellt sicher, dass die Subsysteme für den Zugriff auf Fileshares vor dem Start des SQL Servers online sind.

Im SQL Server Management Studio sind die Lokationen der Datenbanken (hier mit einer CRM Datenbank) sichtbar:

Kurzer Performance Vergleich

Mit dem Tool SQLTest von SQLWorkShops.com habe ich einen kurzen Vergleich zwischen einem physikalischen SQL Server und dem in Azure gemacht. Das Ergebnis ist relativ gleich, obwohl die Ausstattung recht unterschiedlich ist (Hinweis: Eine A2 VM ist im Vergleich doppelt so langsam wie die verwendetet D2_V2 VM).

SQL Server in Azure auf einer D2_V2 sized VM (2 vCores, 7 Gbyte RAM) mit Azure Files:

Physikalischer SQL Server mit 4-Core Xeon CPU E5506 @ 2.13 GHz; 24 GByte RAM; 1xSAN Storage (1 GBit/s):

Viel Spaß mit einer recht guten IOPS Performance (für die überschaubaren Kosten).