Azure SQL VM – keine Möglichkeit den Plattenplatz zu konfigurieren

Ein Kunde hatte mich die letzten Tage gebeten, ihn bei der Optimierung eines SQL Servers auf einer Azure VM zu unterstützen. Der Kunde hatte immer mal wieder leichte Performance Probleme mit dem SQL Server, der Applikation Hersteller bzw Betreuer wollte oder konnte nicht mehr sagen bzw helfen. Von dort erhielten der Kunde erst einmal nur die Aussage, man empfehle für die DATA-Platten des SQL Servers eine Latenz von 5ms… ok, in Azure lässt sich dies offiziell nur mit ULTRA Disks erreichen. Ich möchte hier in diesem Beitrag nicht unbedingt auf das Wie eingehen, sondern nur auf einen Fehler, der mir im Rahmen der Analysen aufgefallen ist.

Erst einmal zur Erläuterung, ich habe mit dem Kunden gesprochen und ihm vorgerechnet was es kostet den Server mit 2 TB Ultra-Disks auszustatten und ob es nicht vielleicht sinnvoller und zielführender ist, den SQL Server auf “Herz und Nieren” zu prüfen, zu optimieren (auch die Applikation bzw deren T-SQL) und im letzten Schritt notfalls doch auf Ultra-Disks zu gehen.

Der Kunde war einverstanden und gemeinsam haben wir den SQL Server einem Review unterzogen, auch wenn die Marketplace-Images von Microsoft (Danke an das Produktteam!) schon sehr gut konfiguriert sind, lässt sich doch noch das ein oder andere anpassen.

Azure SQL VM und die Data-Disks

Wenn man den Empfehlungen zu Azure SQL in einer virtuellen Maschine folgt, dann kann man dort in den Empfehlungen lesen:

Stripe multiple Azure data disks using Storage Spaces to increase I/O bandwidth up to the target virtual machine’s IOPS and throughput limits.

https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices-storage

In einem ersten Anlauf haben wir die 1TB Platte durch mehrere kleine Platten ersetzt, um den maximalen Throughput von 200MB auf 625MB zu erhöhen. Das hat soweit auch ohne Downtime funktioniert, der Kunde ist bisher sehr glücklich. Aber im Zuge dieser Arbeiten bin ich eben auch auf eine Meldung im Azure Portal an dieser virtuellen Maschine bzw der SQL Server Konfigurationsübersicht gestossen, mit der ich im ersten Moment nichts anfangen konnte und Google auch keinerlei Hilfe brachte.

Im Azure Portal gibt es die Möglichkeit für alle SQL Server innerhalb einer Azure VM entsprechend mehrere Extensions auszurollen, die den Administrator dabei unterstützen sollen, die VM bzw den SQL Server über Powershell, Azure CLI oder das Portal zu administrieren und deren Daten in Logs und Metrics darzustellen. Hierzu nutzt Microsoft unter anderem den “SQL Server IaaS Extension Query Service” oder “SQL Server IaaS Agent extension”, beide sammeln Daten aus der virtuellen Maschine und dem SQL Server und stellen diese nutzerfreundlich im Portal dar. Leider war das bei diesem Kunden und dieser VM nicht zu 100% verfügbar, wie der folgende Screenshot zeigt.

Azure SQL VM im Portal leider ohne Anzeige der verfügbaren und belegten Plattenkapazitäten

Auch in der weiteren Übersicht “Configure” waren keine Daten zum Storage ermittelbar, obwohl alle Extensions auf dem Server ausgerollt waren und auch nach einem/mehreren Reboots keinerlei Daten anzeigten. Also bin ich auf die Suche nach der Ursache gegangen…

Extension-Log und fn_trace_gettable

Wie man der Microsoft-Dokumentation entnehmen kann, gibt es unterschiedliche Modis, für unterschiedliche Anforderungen und natürlich kann man hier auch entnehmen, dass es ein lokales Errorlog gibt, welches man unter Umständen zur Fehlersuche nutzen kann. Bei diesem Errorlog handelt es sich um ein XE-File und ein Tracefile, beide nicht mit dem Notepad sondern nur SQL Server Management Studio lesbar… also blieb nichts anderes, als kurzerhand mit einer T-SQL Systemfunktion auf das Tracefile zuzugreifen, um festzustellen, dass der Systemuser anscheinend keinerlei oder zu wenige Berechtigungen hat. Normalerweise befindet sich die Extension direkt auf dem C-Laufwerk im Verzeichnis C:\SQLIaaSExtension, so dass man diesen Pfad in der SQL Abfrage entsprechend nutzen muss.

SELECT * FROM fn_trace_gettable('C:\SQLIaaSExtension\Log\log.trc', default);  
GO  

Durch die Ausführung dieses T-SQL Statements zum Auslesen des Extension-Logfiles, erhielt ich unter anderem die folgende Zeile :

alter server role [sysadmin] add member [NT Service\SQLIaaSExtensionQuery]

Bei der Suche nach dem User musste ich dann feststellen, dass der Kunde diesen User – warum auch immer – gelöscht hat (später stellte ich fest, dass dies anscheinend nicht “per accident” passiert ist, sondern bewusst, denn auf anderen SQL Servern in Azure fehlt der User ebenfalls)

USE [master]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
DROP LOGIN [NT SERVICE\SqlIaaSExtensionQuery]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
CREATE LOGIN [NT SERVICE\SqlIaaSExtensionQuery] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO

ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT SERVICE\SqlIaaSExtensionQuery]
GO

Testweise habe ich diesen User erneut angelegt, berechtigt und im Azure Portal überprüft, ob es eine Veränderung in den Ansichten gibt… Ja, die SQL Server IaaS Agent Extension kann nun wieder auf den SQL Server zugreifen und die notwendigen oder relevanten Daten auslesen.

Azure SQL VM im Portal mit Anzeige der verfügbaren und belegten Plattenkapazitäten

Azure SQL – Change your Skills – DataSaturday #6 Malta

Gestern durfte ich meinen Vortrag im Rahmen des DataSaturday #6 auf Malta halten, dabei ging es um die Veränderungen im Leben eines DBAs, wenn er sich damit konfrontiert sieht, dass seine SQL Server und/oder Datenbanken in die Microsoft Cloud Azure migriert werden sollen. Ich wollte mit diesem Vortrag die Ängste minimieren und aufzeigen, dass es sich bei Azure SQL eben auch “nur” um einen SQL Server bzw einen SQL Datenbank handelt.

Abweichend von allen anderen Veranstaltungen hatte sich Dennes (und sein Team) etwas neues im Ablauf einfallen lassen, die Session hatte keine 60 Minuten sondern 90 Minuten. Die ersten 15 Minuten wurden als Interview oder Einleitung genutzt, der Host stellte den nächsten Sprecher vor, dazu hatte man ein kleines Video produziert und individuelle Fragen zum jeweiligen Lebenslauf vorbereitet. Dann kam der eigentliche Vortrag über volle 60 Minuten, gefolgt von weiteren 15 Minuten für Fragen und Antworten der Teilnehmer oder der Host konnte selber entsprechende Fragen stellen. Alles in allem eine gelungene Lösung, die den Talk eher wie ein Gespräch leitete und allen ein wenig “Druck” nahm und man sich (hoffentlich auch als Teilnehmer) mehr dazugehörig fühlte.

Mein Host war Deepthi Goguri, es hat mir viel Spaß bereitet diese Session gemeinsam mit Ihr zu halten. Auch wenn dies nicht mein erster Vortrag auf Englisch war, so bin ich doch immer noch ein wenig nervöser… finde ich die richtigen Worte im richtigen Moment, spreche ich alles richtig aus… Durch die ruhige und freundliche Art von Deepthi wurde auch ich ruhiger und konnte mich ein wenig besser auf die Session vorbereiten. Half zwar nicht darüber hinweg, dass ich wieder einmal mehr erzählen und zeigen wollte, als ich Zeit zur Verfügung hatte, daran muss ich dringend arbeiten! Vor zwei Jahren hatte ich mich mit Rob Sewell unterhalten, dass ich meine Komfortzone dringend verlassen möchte => nicht nur Vorträge auf Deutsch zu halten, sondern auch einmal mit Englisch starten wolle und ob er mich bei meinem englischen Start – als Mentor sozusagen – unterstützen könne. Und dann kam Corona und alles kam anders… ich bin einfach mal gesprungen und habe es gewagt… womit wieder wir beim Thema wären 😉

It is just a SQLServer - dont be afraid of moving you databases into Azure

Einfach mal trauen und ausprobieren

Deepthi fragte mich gestern, was ich den Teilnehmern denn empfehlen würde, wenn der Auftraggeber oder Arbeitgeber mit der Migration in die Cloud starten wolle. Hier kann ich allen Interessierten nur empfehlen, keine Angst zu haben, nur weil der SQL Server nicht mehr im eigenen Rechenzentrum steht, sondern jetzt in einem Rechenzentrum von Microsoft, heißt dies nicht, dass Microsoft all die Arbeit übernimmt und man – als Datenbank-Administrator – nichts mehr zu tun hat… ok, man muss etwas neues lernen und etwas anders denken, aber es ist immer noch ein SQL Server mit seinen Datenbanken!
Die ersten Schritte könnten die folgenden sein:

  • einen Azure Free Account anlegen
  • einfach mal bspw. eine kostenfreie Linux VM deployen und ausprobieren, wie man dort einen SQL Server installiert
  • oder eine Azure SQL Database, um zu sehen welche Schritte man hier gehen muss, um dies zu erreichen
  • und natürlich all die großartigen Ressourcen von Microsoft Learn – Learning Paths and Modules mit vielen Inhalten und Übungen – erarbeiten
    Azure Fundamentals – AZ-900
    Azure Data Fundamentals – DP-900
  • wenn man dann Fragen zu den einzelnen Optionen hat, dann kann man auch die sehr nützliche Dokumentation lesen, die auch mir, sehr oft hilft gewisse Themen besser zu verstehen.

zahlreiche Lern-Unterstützung zu Azure SQL verfügbar

Microsoft – hauptsächlich in Form von Anna Hoffman und Bob Ward – stellt auch sehr viele interaktive Lernmaterialien zur Verfügung, die man sich in Form von Workshops, Labs oder Youtube Videos erarbeiten kann! Es gibt Material für mehrere Wochen durchgängiges Lernen rund um den SQL Server und/oder Azure SQL… egal ob Azure SQL Database oder die Managed Instance oder auch als SQL Server VM in Azure. Hier heißt es einfach mal starten und ausprobieren, keine Scheu… es ist keine Magie, sondern eigentlich recht einfach, da man sich alles selber zusammenstellen kann, wie man es benötigt 😉

Microsoft Learn: Azure SQL fundamentals learning path
aka.ms/azuresqlfundamentals
Select the Azure SQL Workshop
aka.ms/sqlworkshops
How to choose tool
aka.ms/chooseazuresql
Azure SQL documentation
aka.ms/azuresqldocs
More videos from our team
aka.ms/dataexposed

Change your Skills - Learning - Ressourcen-Overview

Hier geht es zu meinen Slides aus diesem Vortrag:
Azure SQL – Change your skills to become a cloud DBA

und wer jetzt noch etwas zu Azure SQL Database lesen möchte, der kann dies natürlich entweder in meinem Blog hier tun oder in dem relativ neuen Post zu Azure SQL von Deepthi 😉

Echt jetzt ??? Datenbank mit aktiviertem Auto_Close ???

Ich bin hvor kurzem erneut über eine Konfiguration auf einer Datenbank bzw auf einem SQL Server gestolpert, bei der ich immer wieder frage: “Wie kommt man im Jahr 2020/21 auf die Idee an einer Datenbank den Parameter “Auto_Close” auf True zu setzen?” Selbst wenn man diesen Wert seit Jahren und etlichen Versionen “mit sich herumschleppt”, so muss das doch irgendwann mal auffallen… In der Vorbereitung auf diesen Blog-Post habe ich zahlreiche Artikel gefunden, die schon mindestens 10 Jahre alt sind (zum Beispiel) und davon abraten, diesen Konfigurationsparameter auf “true” zu setzen. Aber einmal der Reihe nach, was macht dieser Parameter, was bewirkt er und warum waren manche Dienstleister der Meinung, dass das Aktivieren von AutoClose eine gute Idee sei.

Was ist dieses AutoClose

Gemäß Microsoft Dokumentation

AUTO_CLOSEWenn ON festgelegt wurde, wird die Datenbank heruntergefahren, und die Ressourcen werden freigegeben, wenn der letzte Benutzer die Datenbank beendet hat. Die Datenbank wird automatisch erneut geöffnet, wenn ein Benutzer versucht, die Datenbank nochmals zu verwenden.Wenn OFF festgelegt wurde, bleibt die Datenbank geöffnet, nachdem der letzte Benutzer die Datenbank beendet hat.Diese Option ist für alle Datenbanken auf True festgelegt, wenn Sie SQL Server 2000 Desktop Engine oder SQL Server Express verwenden, und unabhängig vom Betriebssystem auf False festgelegt, wenn Sie eine der anderen Editionen verwenden.
-- Aktivieren der AUTOCLOSE Funktion
USE [master]
GO
ALTER DATABASE [WideWorldImporters] SET AUTO_CLOSE ON WITH NO_WAIT
GO

-- Deaktivieren der AUTOCLOSE Funktion
USE [master]
GO
ALTER DATABASE [WideWorldImporters] SET AUTO_CLOSE OFF WITH NO_WAIT
GO

Heißt also, dass alle Datenbanken die irgendwann mal vor “Jahrzehnten” auf einem SQL Server Express oder einer Desktop Engine erstellt wurden, diesen Parameter (im worst-case seit 20 Jahren) bei jeder Migration mit sich mitnehmen… Warum schaut hier denn kein Admin hin und setzt diesen Wert wieder auf das Optimum “false” )? Natürlich muss ich zumindest daraufhin weisen, dass es unter ganz bestimmten Anwendungsfällen auch sinnvoll sein kann, diesen Parameter zu aktivieren! (dazu später mehr)

Also um das noch einmal im Detail zu erläutern, was AutoClose bewirkt… Die Datenbank schläft eigentlich immer, da Auto_Close aktiviert wurde, dann kommt der User und möchte Daten aus der Datenbank abfragen… dann muss der SQL Server diese Datendateien erst öffnen, einen DBCC CheckDB laufen lassen… die Folge davon ist natürlich ein gewisser Zeitverlust je nach Größe der Datenbank, der allgemeinen Leistung des System und der aktuellen Last auf dem System.

Ich kann mir gut vorstellen, warum man früher der Meinung war, dass die Nutzung dieser Option eine gute Idee war… früher – also rund um den SQL Server 2000 bzw 2005 – gab es noch nicht so performante Systeme und Ressourcen waren teurer, daher hat man sich somit erhofft System-Ressourcen zu sparen und für andere Datenbanken und Applikationen nutzen zu können. Ebenso habe ich gelesen, dass es damals was damit zu tun gehabt haben soll, dass der SQL Server auch auf FAT32-Filesystemen lauffähig (Windows 98) war und es hier Befürchtungen gab, dass Datenbanken “zerstört” werden könnten weil sie eben nicht richtig geschlossen (im Filesystem) wurden.*¹ Und natürlich wie in der Microsoft Dokumentation benannt, war das natürlich bei allen “freien” Versionen der Fall, da hier nur eine CPU genutzt werden konnte, hier dann einer Ressourcen-Knappheit vorgebeugt werden sollte.

SQL-Server - Database Properties - Options - Auto_Close

Worst-case: Performance-Impact

Der worst-case ist natürlich, dass die Aktivierung – ob gewollt, ungewollt oder eben per Default – zu Performancebeinträchtigung des SQL Servers und der nutzenden Applikationen kommt. Durch das ständige Öffnen und Schliessen der Datenbanken und das damit verbundene Überprüfen der Datenbank-Konsistenz. Wie bereits angedeutet, kann es Sinn machen, diese Funktion zu aktivieren, denn es gibt immer Ausnahmen… zum Beispiel könnte ich mir Entwickler-Server vorstellen, bei denen jeder Entwickler seine eigene Datenbank hat und ggfs nicht alle gleichzeitig arbeiten/entwickeln, dann könnte es unter Umständen Sinn machen, diesen Konfigurationspunkt zu verändern. Oder – und hier kommt wieder der Blogbeitrag von Greg*¹ zum Tragen – wenn man einen SQL Server mit vielen Datenbanken hat, die aber nicht alle gleichzeitig genutzt werden (zum Beispiel ein weltweit agierender Händler mit sehr vielen Standorten und jeder Standort eine eigene Datenbank hat). Aber wie immer gilt dann, dass man das testen muss, was ggfs sinnvoller ist, dauernd die Datenbank zu schliessen oder eben offen zu lassen.

Ich hatte zum Beispiel in der letzten Woche einen Kunden mit einem langsamen SQL Server, als ich dort ins Log schaute, waren 90% der Einträge genau die Meldungen “Starting database” und “Shutting down database” (das war nicht das einzige Problem hier), aber eben genau diese Kunden-Situation hat mich dazu bewogen, diesen Beitrag zu schreiben.

Wer jetzt – bei nächster Gelegenheit seine SQL Server überprüfen möchte, dem möchte ich den Blogpost aus dem Jahr 2013 von Rob Sewell ans Herz legen, wo er mit Powershell eine Liste von Servern überprüft und ggfs korrigiert. => SQL Express Migration Auto_Close Setting

*¹ – Thx an Greg Low

SQL Server Patch – Server startet nicht mehr

Manchmal treffen gewisse Themen zeitnah zusammen, in diesem Fall waren es mehrere Mails aus der Data-Platform-MVP-Distributionlist, mehreren Kunden-Meldungen und dazu noch passsende Beiträge in anderen Blogs, daher möchte ich dazu einen deutschen Beitrag leisten. 😉
Es geht um einen Fehler der anscheinend schon seit mehreren Jahren in allen SQL Server Versionen und Editionen in unterschiedlichen Konstellationen auftritt, die meisten DBAs werden sehr wahrscheinlich nie mit diesem Problem zusammentreffen, wahrscheinlich auch nie vorher an dieses Problem denken. Falls doch, kommt hier eine Erläuterung…

Wann tritt der Fehler auf? – Ausgangslage

Wer kennt es nicht? Man stößt das Rollout von Patchen auf seine Windows Server (inkl SQL Server Cumulative Updates) an und wartet auf die Fertigmeldung…. nach einiger Zeit meldet sich die WSUS Konsole und meldet alle Patches als “erfolgreich” ausgerollt… man meldet an die beteiligten Abteilungen, dass man den Rollout-Vorgang erfolgriech abgeschlossen hat… dann kommt aber die Fertigung und meldet, dass die Produktion nicht wieder anläuft…

Oder ein Kunde meldet sich mit den Worten:

Übrigens spielen wir gerade ein Backup ein, weil nach dem Windows Update (inkl. SQL Server Updates) der Service für den Server (und ein paar andere Services) nicht mehr startet…

Jetzt geht die Fehlersuche los und irgendwann stellt man fest, dass der SQL Server zwar das Patch erhalten hat, danach auch sauber gebootet hat aber der SQL Server Datenbank-Dienst nicht wieder sauber gestartet wurde… noch weiter in das Trouble-Shooting einsteigen und dann im Errorlog des SQL Servers entsprechende Meldungen finden:

Error: 2714, Severity: 16, State: 6.
There is already an object named 'TargetServersRole' in the database.
Error: 2759, Severity: 16, State: 0.
CREATE SCHEMA failed due to previous errors.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 2714, state 6, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 2714, Severity: 16, State: 25.
There is already an object named 'DatabaseMailUserRole' in the database.
Error: 2759, Severity: 16, State: 0.
CREATE SCHEMA failed due to previous errors.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database ‘master’ failed because upgrade step ‘sqlagent100_msdb_upgrade.sql’ encountered error 2714, state 6, severity 25. 
This is a serious error condition which might interfere with regular operation and the database will be taken offline. 
If the error happened during upgrade of the ‘master’ database, it will prevent the entire SQL Server instance from starting. 
Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

Es sollte allen DBAs bekannt sein, dass der SQL Server im Rahmen eines Patches auch Änderungen an den Datenbank-Strukturen der System-Datenbanken durchführt, diese Änderungen werden in der Regel mithilfe von T-SQL-Statements über ein SQL-File mitgeführt. Diese Skripte sollten eigentlich in der Regel auf ALLEN (!) SQL-Servern bei allen Kunden in allen Ausprägungen funktioneren, genau hier ist das Problem… es wird immer ein (oder zwei) Systeme gehen, die vom “Standard” abweichen… sei es “per accident” oder aufgrund einer administrativen Anpassung.

Bezogen auf “TargetServersRole” – hier reicht es den SQL Dienst mit dem Traceflag 902 manuell zu starten und das Schema in der “msdb => Security => Schema” zu löschen.

Bei “DatabaseMailUserRole” wird es etwas schwieriger, hier muss ein wenig mehr T-SQL Code ausgeführt werden, denn über das SQL Server Management Studio findet man diese Rolle nicht, da es sich hier um einen Oprhaned User handelt. Pinal Dave hat hierzu eine gute Erläuterung mit Lösung geschrieben:

USE [msdb]
GO
CREATE ROLE [DatabaseMailUserRole] AUTHORIZATION [dbo]
GO
USE [msdb]
GO
ALTER AUTHORIZATION ON SCHEMA::[DatabaseMailUserRole] TO [DatabaseMailUserRole]
GO

Bei meiner letzten Korrektur trat erst der Fehler mit der TargetServersRole als erstes auf, dann die SQL Server Engine ohne Traceflag neu gestartet und wieder in eine Fehlersituation gelaufen, diesmal mit der DatabaseMailUserRole, also dieser Fehler/diese Fehler können auch hintereinander auftreten. Meine Kunden konnte ich in beiden Situationen mit der Hilfe der Blogbeiträge doch recht schnell wieder bereinigen und innerhalb kürzester Zeit den SQL Server wieder lauffähig zur Verfügung stellen.

Danke an Tim Wappat für die Lösung und die Bereinigung der TargetServersRole
https://timwappat.info/post/2019/02/15/SQLUpgradeFailMsdb110_upgradesql (lässt sich leider nicht so schön einbetten 🙁 )

Danke an Pinal Dave für die Lösung und die Bereinigung der DatabaseMailUserRole

SQL Server Failover Cluster on Azure

ich bin heute “gezwungen” gewesen mir “schnell” ein SQL Server 2019 Failover Cluster zu erstellen um etwas zu testen, da der Kunde nur eine produktive Umgebung hat und ich erst einen funktionierenden Fahrplan für die Umsetzung benötige… also schnell eine Anleitung rausgesucht, ich wusste was grobes aber musste mich natürlich erst einmal in die Details einlesen…

Ich habe schon mehrfach gehört, dass Microsoft seit einiger Zeit auch “Shared Disks” für eben Failover Cluster anbietet, aber wie man diese nun deployed und zusätzlich noch richtig in Windows bzw dem Cluster Manager einbindet, diese Informationen fehl(t)en mir. Also Google gefragt, dieser mich auf eine Beitrag in den Microsoft Docs verwiesen und ich einfach mal drauflos gelegt.

Erstellen Sie eine FCI mit gemeinsam genutzten Azure-Festplatten

in diesem Beitrag steht unter Voraussetzungen folgendes:

Bevor Sie die in diesem Artikel aufgeführten Anweisungen ausführen, sollten Sie über Folgendes verfügen:
 - Ein Azure-Abonnement
 - Zwei oder mehr virtuelle Windows Azure-Computer. Verfügbarkeitsgruppen und Näherungsplatzierungsgruppe werden bei SSD Premium und Verfügbarkeitszonen werden   bei für Ultra Disks unterstützt. Wenn Sie eine PPG verwenden, müssen alle Knoten in derselben Gruppe vorhanden sein.
 - Ein Konto mit Berechtigungen zum Erstellen von Objekten auf virtuellen Azure-Computern und in Active Directory
 - Die neueste Version von PowerShell.

Meine Überlegungen dazu… Azure Subscription habe ich, zwei virtuelle Maschinen kann ich schnell deployen, AvailabilityGroups oder ProximityGroups habe ich auch bzw brauche ich hier nicht und eine Domäne mit entsprechendem DomainAdmin-User habe ich auch… also schnell zwei virtuelle Maschinen “SQL Server 2019 Developer auf Windows 2019” deployed und die Anleitung genau befolgt.

  • SharedDiskConfig.json angelegt und gemäß Doku befüllt
  • ResourceGroupDeployment mit SharedDiskConfig.json ausgeführt, also die SharedDisk angelegt
  • SharedDisk der ersten virtuellen Maschine hinzugefügt
  • SharedDisk der zweiten virtuellen Maschine hinzugefügt… HALT STOP, eine Fehlermeldung…
Cannot change network spine of shared disk myDataDisk while it is attached to running VM(s)

die Fehlersuche beginnt…

Da dies meine ersten Versuche mit Shared Disks sind/waren, habe ich natürlich erst einmal alles genauer untersucht bzw versucht, zumal die Shared Disk trotz Fehlermeldung an der zweiten Maschine (zumindest im Portal) zu sehen war. Restart der virtuellen Maschine ging nicht, wegen dem komischen Deployment-Zustand, Abhängen der Platte im ersten Moment auch nicht, als Owner der Platte konnte ich die erste VM ausmachen, aber wie kann ich jetzt die zweite VM zum Owner machen… alles sehr strange…

Aber es gab etwas was mich doch ein wenig irritierte… sowohl in der Anleitung als in den Powershell Snippets gibt es den Hinweis auf die Verwendung von Proximity Placement Groups. Beim Googeln nach der Fehlermeldung stieß ich dann auch einen Beitrag auf Stackoverflow, wo jemand denselben Fehler hatte und die Lösung eben in diesen Proximity Placement Gruppen gefunden hatte. Aber wieso wird in der Dokumentation nicht wirklich daraufhin gewiesen… Na gut, erst einmal selber ausprobieren, ob das dann funktioniert.

Anlegen einer PPG und Maschinen hinzufügen

Ok, also habe ich versucht den kürzesten und einfachsten Weg zu nehmen… Anlegen einer Proximity-Placement-Group und die beiden bereits vorhandenen virtuellen Maschinen dieser hinzufügen. Die Anlage der PPG über das Azure Portal war schnell und einfach (Ressourcengruppe => neue Ressource => PPG suchen und auswählen => Region und Namen eintragen und erstellen), das Hinzufügen der VMs habe ich dann ebenfalls über das Portal gemacht, dazu müssen die Maschinen erst einmal gestoppt werden und die Ressourcen deallokiert werden.

Danach habe ich vorsichtshalber noch einmal die Shared-Disk gelöscht und neu erstellt und konnte diese dann erfolgreich an beide SQL Server VMs anbinden.

$dataDiskConfig = New-AzDiskConfig -Location 'eastus2' -DiskSizeGB 1024 -AccountType Premium_LRS -CreateOption Empty -MaxSharesCount 2

New-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName 'myClusterDisk' -Disk $dataDiskConfig


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl01"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl02"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'

Im Nachgang konnte ich auf beiden Servern problemlos erst das Windows Failover Cluster validieren und erstellen, um dann die SQL Server Knoten zu installieren bzw hinzuzufügen.

Ich werde also zeitnah die Beschreibung bei Microsoft anpassen (lassen). Ich hoffe dieser Blogpost hilft euch bei Zeiten weiter, damit ihr nicht so lange braucht 😉