Azure Arc-enabled Data Services – Cloud Summit 2021

Auch gestern durfte ich wieder auf einer internationalen Community-Veranstaltung – dem Cloud Summit – über Azure Arc-enabled Data Services sprechen, natürlich in der Hauptsache wie man eine Azure SQL Managed Instance im eigenen Rechenzentrum betreiben kann. Wie bereits auf dem DataSaturday #14 in Oslo, habe ich bei den verschiedenen Möglichkeiten von Azure Arc begonnen und habe die einzelnen Komponenten der Umgebungen vorgestellt, was wird benötigt und wie kann man dies recht einfach deployen. Zum Ende hin gab es wieder eine ausführliche Demonstration wie man einen Data Controller auf Kubernetes deployen kann und wie man dann mittel Azure Data Studi eine Managed Instance oder PostgreSQL Hyperscale ausrollen kann.

Ich habe mich sehr gefreut ein Teil dieser mehrere Tage gehenden Veranstaltung Cloud Summit 2021 zu sein, der Vortrag selber war aus meiner Sicht ein sehr gelungener, alles hat funktioniert, die Zeit wurde etwas knapp aber auch daran kann man zukünftig arbeiten/nachbessern.

Ich wollte mit diesem kurzen Beitrag nur schnell die Slides online stellen und mich bei den Organisatoren und Sponsoren des Cloud Summits recht herzlich bedanken !

Cloud Summit 2021 – Bjoern Peters – Azure Arc-enabled data services

Data Saturday #14 – Oslo 2021 – Einführung in Azure Arc Data Services

Heute war es soweit – ich durfte endlich einmal auf dem Data Saturday (ehemals SQLSaturday) in Oslo sprechen… das endlich lag nicht an den Organisatoren sondern eher an mir bzw an der Pandemie, da ich mich bis 2020 nicht getraut hatte, Vorträge auf Englisch zu halten, hatte ich auch keine Sessions für Oslo eingereicht. Am liebsten wäre ich natürlich vor Ort gewesen, denn Norwegen bzw Oslo sind wunderschön, ich kenne mittlerweile auch mehrere Community-Member in der Region die ich nun auch schon lange Zeit nicht mehr gesehen habe, aber es musste dieses Jahr erst einmal virtuell bleiben, vielleicht ja im nächsten Jahr wieder in person.

Nun aber zu meinem Vortrag zur Einführung in Azure Arc bzw Azure Arc Data Services, um den es am Samstag, den 04. September 2021 um 9:45 ging. Azure Arc selber ist erst einmal eine Plattform, ein Service den Microsoft in Azure bereitstellt, um die Verwaltung von verschiedenen Umgebungen – Hardware, virtuelle Maschinen, Windows, Linux, AWS, GCP oder was auch immer – in einer zentralen Stelle zu verwalten und zu administrieren.

Einführung in Azure Arc

Damit kann man nun beispielsweise seine on-premise Windows oder Linux Server mit dem Azure Portal verbinden, um diese von dort aus zu administrieren. Oder auch von der Vielzahl an Services aus der Cloud wie zum Beispiel Security oder Compliance, diese Benefits bringt eben Azure Arc mit sich, in dem man seine on-premise Systeme in die Analysen dieser Azure-Services mit einbinden kann. Des weiteren kann man auch Automatisierungen wie zum Beispiel Patching oder Backups aus dem Azure Portal oder anderen Azure Services heraus erstellen und administrieren, was einen erhebliche Vorteil in der Vereinheitlichung der Systeme und Prozesse bedeutet.

Und das nicht nur mit on-premise Servern bzw Systemen sondern eben auch Multi-Cloud und auch “disconnected” Systemen, auch mit Kubernetes Clustern oder SQL Servern

  • Azure Arc-enabled servers
  • Azure Arc-enabled Kubernetes
  • SQL Server auf Azure Arc-enabled Servers
Alle Applikationen, Systeme und Umgebungen zentral vereint

Azure Arc Data Services

Unter Azure Arc Data Services versteht man nun die Möglichkeit eine Azure SQL Managed Instance oder eine Postgres Hyperscale auf einem “x-beliebigen” Kubernetes Cluster zu betreiben, ob dieses Kubernetes Cluster nun im eigenen Rechenzentrum oder in einer anderen Cloud steht, ist erst einmal egal, Hauptsache es handelt sich um ein CNCF-zertifiziertes Kubernetes-Cluster.

Um aber eben eine Managed Instance in seinem eigenen Rechenzentrum zu betreiben, muss man mehrere Schritte befolgen… zum einen sollte man das Kubernetes-Cluster zu einem Azure Arc eneabled Kubernetes machen, zum anderen muss man einen “Connector/Agent” auf diesem Cluster ausrollen, den Data-Controller. Dieser Data Controller stellt die Schnittstelle zwischen Azure, dem Azure Portal und der SQL Managed Instance her. Nun kann man über verschiedene Wege – Azure Portal, Azure CLI oder Azure Data Studio – auf diesem Cluster eine voll funktionsfähige SQL Managed Instance deployen und nutzen.

Deployment einer Azure SQL Managed Instance auf einem Data Controller
auf dem eigenen Kubernetes Cluster

Aus persönlicher Sicht, ist dies eine großartige Geschichte, einen zentralen Anlaufpunkt für alle genutzten Services und Applikationen zu haben und somit auch die zusätzlichen (Sicherheit bringenden) Features aus Azure auf allen Systemen zu nutzen. Alles in allem ein Zugewinn für das Unternehmen!

Meine Slides und weiterführende Links

DataSaturday-Oslo-2021-Azure-Arc-Data-Services.pdf

Microsoft Dokumentation

Wenn man selber diese Möglichkeit des Rollouts von Azure Data Services ausprobieren möchte, dann kann ich jedem nur empfehlen sich mit den Jumpstart Szeanarien von Microsoft zu beschäftigen, hier werden vorgefertige Umgebungen ausgerollt mit denen man dann problemlos testen kann, was wie wo funktioniert:

https://azurearcjumpstart.io/overview/

Bleibt mir nur noch DANKE an alle Zuhörer und die Organisatoren zu sagen, es war mir eine Freude und hat viel Spaß gemacht. #CommunityRocks

Warum “SQL aus Hamburg” oder “Nord DBA” ?

Eigentlich hätte ich diesen Beitrag schon vor Jahren mal schreiben sollen ;-), um die Historie bzw die Entstehungsgeschichte dieses Blogs zu beleuchten. Aber wie heißt es so schön… es ist nie zu spät.

Damals hatte ich meine ersten Initiativen und Aktivitäten mit der deutschen SQL Server Community unternommen, die ersten Veranstaltungen besucht und die ersten Kontakte geknüpft und musste leider feststellen, dass meine Kenntnis vom SQL Server auch nach mehr als 10 Jahren eher gering ausfiel. Dies gefiel mir selber nicht und ich habe mir das Ziel gesetzt mich mehr mit dem Produkt zu beschäftigen, also im Grunde genau die Geschichte warum ich in der Community aktiv bin. Zu der zeit war ich als Datenbank-Administrator beschäftigt und habe gemeinsam mit meinem Kollegen Thomas, die SQL Server unserer Kunden betreut. Thomas wusste aus anderen Bereich zum SQL Server viel und ich wusste ja auch schon viel, so haben wir uns wunderbar ergänzt. Gemeinsam wollten wir diesen Blog betreiben und über unsere täglichen Erlebnisse, Probleme oder Herausforderungen schreiben. Da wir beide – in einem größeren Team verteilt über Deutschland – aus Hamburg kamen und es um unsere Hauptaufgabe – den SQL Server – ging, war die Suche nach einem Namen relativ einfach…

Aufgrund meiner – damals noch aktiven Selbstständigkeit – war ich bereits im Besitz eines entsprechenden Webspace und die Domäne “SQL-aus-Hamburg.de” war schnell registriert. Der erste Blogbeitrag ließ auch nicht lange auf sich warten, dann wurde es etwas ruhiger 🙁
Wir hatten uns das wahrscheinlich einfacher vorgestellt, die Arbeit wurde mehr… ich kann nicht mehr genau sagen, warum wir nichts geschrieben haben… vielleicht war es oder wir damals einfach noch nicht so weit… Thomas hatte immer gute Ideen und hat mir sozusagen die Überschriften geliefert… aber leider nie selber geschrieben (soll kein Vorwurf sein!)… und dann kam alles anders… Leider ist Thomas unerwartet und plötzlich verstorben, ich musste und habe dann diesen Blog unter demselben Namen weitergeführt.

Für mich ist dieser Blog im Grunde immer noch, siehe die letzten Posts zum Azure SQL Database Refresh, nur ein Notizbuch, in dem ich meine eigenen Erfahrungen für mich selber Revue passieren lasse, um sie vielleicht irgendwann doch einmal herauszusuchen oder mich daran zu erinnern, wann ich was wie erfolgreich lösen konnte.

Warum SQL-aus-HH ???

In den sozialen Medien findet man mich entsprechend auch unter @SQL_aus_HH, für den deutschsprachigen Leser überhaupt kein Problem eine Verbindung zwischen Hamburg und HH zu ziehen… ursprünglich hatte ich auch nie mit dem Gedanken gespielt, dass ich irgendwann auch mal englischsprachige Beiträge schreibe oder sogar Vorträge auf internationalen Veranstaltungen halte… daher hier noch einmal zur Verdeutlichung für die “Ausländer”.

Hamburg ist eine Hansestadt und trägt daher auf dem deutschen KFZ-Nummernschild die Abkürzung HH für “Hansestadt Hamburg“.

Bereits im Mittelalter verdienten sich Kaufleute mit dem Fernhandel eine goldene Nase. Besonders erfolgreich war die Hanse. So nannte sich vor etwa 700 Jahren ein Bündnis aus Städten und Kaufmannsverbänden. Der Hansebund wurde geschlossen, um den Handel zwischen den Mitgliedern, den Hansestädten, zu vereinfachen. Damals erschwerten zahlreiche Zölle, verschiedene Währungen und Maßeinheiten den Fernhandel.
[…]
Letztendlich trugen nur noch Hamburg, Bremen und Lübeck offiziell den Titel einer Hansestadt. Hamburg und Bremen haben ihre hanseatische Eigenständigkeit zum Teil sogar bis heute bewahrt. Sie sind – neben Berlin – die einzigen deutschen Städte, die gleichzeitig ein eigenes Bundesland sind. Auch ihre Autokennzeichen weisen auf den mittelalterlichen Städtebund hin: HH steht für die Hansestadt Hamburg und HB für die Hansestadt Bremen.

http://stadtgeschichtchen.de/artikel/stadtgeschichte/was-ist-eine-hansestadt/

Da dieser Blog damals von zwei Personen geführt werden sollte, hatte ich mir auch Gedanken über einen Namen für meinen “persönlichen Auftritt” gemacht bzw wollte im Zusammenhang mit einem Favicon für den Blog etwas “kreativer” sein… als “Nord-DBA”… bitte fragt mich nicht nach den Gründen/Gedanken, die zu diesem Namen geführt haben… ich kann es schlicht weg nicht mehr sagen, aber seit gut 10 Jahren gibt es eben dieses Favicon als “Erkennungszeichen” für diesen Blog.

Solltet ihr noch Fragen zu der Entstehungsgeschichte meines Blogs haben… so schreibt mich einfach an.

Hochverfügbarkeit beim SQL Server – DBCC 2021 – Teil 1

Jeder meiner Kunden hat sich irgendwann mal die Frage gestellt oder zumindest sollte er sich diese Frage stellen, “brauche ich für meine SQL Server oder einen meiner SQL Server eine gewisse Hochverfügbarkeit”. Leider enden diese Überlegungen immer bei der Frage nach dem Budget… natürlich kosten solche HA-Lösungen mehr Geld, je nach Auswahl der Lösung und der Ausstattung der Umgebung müssen entsprechende Lizenzen zur Verfügung gestellt werden. Aber wenn man die im “worst-case” anfallenden Kosten während oder durch einen Ausfall dagegen rechnet, sollte man ganz klar zur Einsicht kommen, dass diese Kosten vertretbar sind.

Ich durfte heute auf der Data Blaster Community Conference 2021 einen Vortrag dazu halten (Vielen Dank liebe SQLPASS Deutschland), hier kommt eine kleine Zusammenfassung aus meinem Vortrag.

Ich habe direkt am Anfang dargestellt, wie hoch solche Kosten sein können, hierzu habe ich mit Hilfe eines Online-Rechners von Percona eine beispielhafte Rechnung aufgemacht. Der SQL Server fällt für 1-2 Stunden aus, 5 Mitarbeiter sind an dem Restore beschöftigt, jeder von ihnen verdient 100.000 pro Jahr, 100 weitere Mitarbeiter können nicht richtig arbeiten, diese verdienen durchschnittlich 50.000 pro Jahr. Im folgenden Screenshot könnt ihr die Zahlen lesen, die unter Umständen während des Ausfalls, bei der Behebung und deren Nachwirkungen entstehen können.

Warum SQLServer Hochverfuegbarkeit sich rechnet - Percona Calculator

Bei Gesamtkosten von rund 8.000.000 Euro für einen Ausfall eines SQL Servers von rund 2 Stunden, würde ich mir schon vorher überlegen, ob ich z.B. 250.000 Euro im Rahmen der Installation mehr ausgebe, um einen zweiten Server hinzustellen und mit den jeweiligen Lizenzen auszustatten. Aber wie können solche Hochverfügbarkeiten im SQL Server Umfeld aussehen, dazu komme ich in den nächsten Abschnitten, aber erst einmal sollten wir die Überschriften klären… 😉

Hochverfügbarkeit vs Desaster Recovery

Die Definition von Hochverfügbarkeit auf wikipedia.de lautet wie folgt :

Hochverfügbarkeit (englisch high availabilityHA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten. In Abgrenzung zur Fehlertoleranz kann es bei dem Betrieb im Fehlerfall zu einer Unterbrechung kommen.

https://de.wikipedia.org/wiki/Hochverf%C3%BCgbarkeit

Im Vergleich dazu die Definition von Desaster Recovery

Der englische Begriff Disaster Recovery (im Deutschen auch Katastrophenwiederherstellung oder Notfallwiederherstellung genannt) bezeichnet Maßnahmen, die nach einem Ausfall von Komponenten in der Informationstechnik eingeleitet werden. Dazu zählt sowohl die Datenwiederherstellung als auch das Ersetzen nicht mehr benutzbarer InfrastrukturHardware und Organisation. Umfassender als Disaster Recovery ist der Begriff Business Continuity, der nicht die Wiederherstellung der IT-Dienste, sondern unterbrechungsfreie Geschäftsabläufe in den Vordergrund stellt.

https://de.wikipedia.org/wiki/Disaster_Recovery

Bei der Hochverfügbarkeit geht es eben mehr darum, die eintretende Zeit des Ausfalls, also die Downtime möglichst gering zu halten, so dass alle angeschlossenen Systeme möglichst ohne Datenverlust und manuellen Eingriff schnellstmöglich weiterlaufen. Hierzu sollte man sich vor der Installation natürlich Gedanken zur Prozessgestaltung, den zu erreichenden Zielen und der Notwendigkeit zu machen.

  • Was braucht das Business?
  • Was kostet es das Business wenn sie nicht mehr arbeiten können?
  • Gibt es ggfs einen Kompromiss zwischen Technik und Business? Müssen es wirklich die minimalsten Ausfallzeiten (< 10 Sekunden) sein oder reichen vielleicht auch maximale Ausfallzeiten von kleiner einer Minute?
  • Was kann die Technik überhaupt abbilden? Wissen, Prozesse u.ä.
  • Welceh rechtlichen Rahmen müssen ggfs eingehalten werden?

Und erst wenn man diese Fragen vorher geklärt hat, kann man sich Gedanken über die eigentliche Hochverfügbarkeitslösung machen und wie diese implementiert werden kann/soll.

Das AlwaysOn Failover-Cluster (FCI)

Hochverfuegbarkeit - SQLServer - AlwaysOn Failover Cluster

Kommen wir zu einer der möglichen Lösungen zur Realisierung der Hochverfügbarkeit des SQL Servers innerhalb des eigenen Rechenzentrums, das Windows Failover Cluster (im Grunde identisch zu einem Linux Failover Cluster, hier sollte man sich an die Angaben/Dokumentation der jeweiligen Distribution und eingesetzten Cluster-Software halten).

Initial erstellt man aus zwei Windows Servern mit dem zusätzlich installierten Failover-Cluster Feature ein Windows Failover Cluster, grob gesagt, man verbindet beide Server logisch (und im AD) miteinander. Beide kennen sich und wissen nun, dass sie zusammengehören und tauschen mehrere entsprechenden Health-Status Informationen untereinander aus. Dieses Windows Failover Cluster erhält eine eigene IP und einen eigenen DNS Namen, sowie ein Cluster-Named-Object im AD, dieses CNO “steuert” später das Cluster im AD.

Zu den notwendigen Storage-Requirements kann ich hier wenig sagen, da dies von den jeweiligen Umgebungen abhängt… SAN, NAS, NFS, HCI oder ähnliches, auf jeden Fall muss es sich um einen Storage handeln, der in der Lage ist beiden Servern Zugriff zu gewähren. Microsoft schreibt dazu folgendes:

Storage

Im Gegensatz zur Verfügbarkeitsgruppe muss eine FCI freigegebenen Speicher zwischen allen Knoten der FCI für Datenbank und Protokolle verwenden. Der freigegebene Speicher kann die Form von WSFC-Clusterdatenträgern, direkten Speicherplätzen (Storage Spaces Direct, S2D), Datenträgern auf einem SAN oder Dateifreigaben auf einem SMB aufweisen. Auf diese Weise verfügen alle Knoten in der FCI immer dann über die gleiche Sicht der Instanzdaten, wenn ein Failover auftritt. Dies bedeutet jedoch, dass der freigegebene Speicher das Potenzial hat, die einzelne Fehlerquelle zu sein. Die FCI hängt zudem von der zugrunde liegenden Speicherlösung ab, um Datenschutz sicherzustellen.

https://docs.microsoft.com/de-de/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server?view=sql-server-ver15&WT.mc_id=DP-MVP-5002576#Recommendations

Nun kann man mit der eigentlichen Installation des SQL Servers beginnen, auf dem Node 1 wird die Basis-Installation für das SQL Server Failover Cluster geschaffen “Erstellung eines Failover-Clusters”, während auf dem Node 2 “nur” ein Knoten zu einem bestehenden SQL Server Cluster hinzugefügt wird.

Je nach Ausgestaltung dieses Cluster – nur eine Instanz oder mehrere Instanzen – müssen SQL Server Lizenzen beschafft werden. Hierbei kann man zwischen zwei Betriebsmodis unterscheiden, aktiv/passiv oder aktiv/aktiv. Bei aktiv/passiv dürfen die SQL Server Instanzen immer nur auf einem Knoten des Clusters laufen, im Fehlerfall für einen begrenzten Zeitraum auch auf beiden Knoten. Bei aaktiv/aktiv können beide Knoten gleichermaßen und zeitlich unbegrenzt voll genutzt werden, was gerade bei mehreren Instanzen unter Umständen Sinn machen kann, da man so eine gewisse Last-Aufteilung vornehmen kann.

Sollte nun ein Knoten im Cluster ausfallen, so kann der zweite Knoten vereinfacht gesagt nicht mehr der anderen Seite kommunizieren und versucht schnellstmöglich die ausgefallenen Services auf seine Seite zu holen und dort zu starten.

Ein hybrides Szenario ist hierbei leider nicht möglich, da es keine Möglichkeit der gesharten Ressourcen zwischen on-premise und Cloud gibt. Aber man kann alternativ auch ein Failover-Cluster in der Azure Cloud aufbauen. Hierzu benötigt man eine Proximity Placement Group, entsprechende Managed Disks mit aktiviertem “Shared Storage” Feature und die beschriebenen zwei virtuellen Maschinen, die eigentliche Installation und Betrieb ist im Grunde identisch.

Hochverfügbarkeit Azure SQLServer Failover Cluster - DBCC2021

Mehr zu Hochverfügbarkeiten des SQL Servers kommt demnächst in einem zweiten Beitrag.

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