Pause / Resume / Backup einer Azure SQL Database mit Powershell – Teil 3

Viele Services in Azure erlauben durch Automatisierung eine gewisse Kostenersparnis, wie man das mit dem Platform-as-a-Service “Azure SQL Database” erreichen kann, darum geht es in diesem Blogbeitrag. Ganz so einfach wie z.B. beim Azure Analysis Service ist es hier leider nicht, denn es gibt eigentlich keine Pause-Resume Funktionalität – wie hier das Backup mitspielt, dazu kommen wir als erstes.

Azure SQL Database und das Thema Backup

Bevor wir einsteigen in das Thema Azure SQL Database und dessen Pause-Resume-Funktionalität müssen wir vorher kurz einen Blick auf das Thema Backup werfen, welches in diesem Zusammenhang nicht ganz unwichtig ist. Einen großen Vorteil gegenüber einem SQL Server (onpremise oder IaaS) hat die Azure SQL Database auf jeden Fall… man muss sich nicht explizit um das Backup kümmern, da dieses automatisch erstellt wird. Soll heißen, je nach Datenbank-Größe und dem Aufkommen von Datenveränderungen sichert Microsoft automatisch die Datenbanken in regelmäßigen Abständen! Was heißen soll, die Kosten für eine extra Backup-Software oder gar die Entwicklung eigener Services fallen schon einmal weg. Je nach PerformanceLevel gibt es unterschiedliche Backup Retention Zeiten:

  • beim Basis Level beträgt die Aufbewahrungszeit 7 Tage.
  • beim Standard Level beträgt die Aufbewahrungszeit 35 Tage.
  • beim Premium Level beträgt die Aufbewahrungszeit 35 Tage.

Wann wird meine Datenbank denn aber nun gesichert? Auch darauf gibt es eine Anwort…
Das Full-Backup erfolgt jede Woche (leider) zu nicht fest definierten Zeiten, differentielle Backups werden generell alle paar Stunden erstellt und eben je nach Datenaufkommen erfolgt die Sicherung der TransaktionsProtokolle alle 5-10 Minuten. Ein erste Voll-Sicherung wird innerhalb der ersten 30 Minuten nach Erstellung der Datenbank erstellt. Diese Sicherungen werden entsprechend des Service-Tiers (siehe oben) aufbewahrt (Kostenersparnis : man braucht keinen extra Storage-Account, da das Backup bereits im Preis inkludiert ist). Möchte man sein Backup aber länger als 35 Tage aufbewahren, so hat man die Möglichkeit ein “Long-Time-Retention-Backup” zu aktivieren, hierzu ist ein weitere Storage-Account notwendig auf dem dann die Backups parallel abgelegt werden und eben dauerhaft abgelegt werden können.

Backup Azure SQL Database

Pause und Resume zwecks Kostenersparnis

Diese Funktionalität gibt es leider bei Azure SQL Database nicht… Wie kann ich trotzdem eine Kostenersparnis erwirken, wenn ich diesen Platform-as-a-Service verwenden möchte… natürlich kann man – wie bereits in einem anderen Blogpost erläutert – die Datenbank Performance verändern, um die auftretenden Lastspitzen abzufangen. Aber wir möchten doch eigentlich mit der Migration in die Cloud auch eine gewisse Kostenersparnis erreichen… wenn die Fachabteilung nur tagsüber arbeitet (8-20 Uhr), dann brauche ich diese Datenbank(n) doch während der Nacht nicht… kann man die dann nicht einfach stoppen, da man doch nur zahlt, wenn die Datenbank online ist?

Für genau dieses Szenario – die Fachabteilung braucht die Datenbank nur tagsüber – gibt es eigentlich keine Lösung, aber einen Workaround, denn hier hilft abends nur ein “Drop Database” und am nächsten Morgen  ein “Create Database from Backup”. Aber dieses Vorgehen hat Microsoft ausgesprochen angenehm gelöst und bedeutet keinen großen Aufwand.

# Dropping DB to stop costs
Get-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -ev notPresent -ea 0
if ($notPresent) {
    Write-Host $databasename "already deleted" 
} else {
    Remove-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename
}

Hierzu sollte man beachten, dass man nur die Datenbank löscht/entfernt und nicht den logischen Server, denn die Backup-Historie hängt am Server. Man benötigt also das Datum des letzten Backups um diese Datenbank wieder herzustellen. Beim Neu-Erstellen der Datenbank am folgenden Morgen nutzt man dann diesen Backup-Zeitpunkt, um damit direkt einen Restore durchzuführen. In Powershell kann man diese Tätigkeiten sehr einfach kombinieren.

$deleteddatabase = Get-AzureRmSqlDeletedDatabaseBackup -ResourceGroupName $resourcegroupname -ServerName $servername #-DatabaseName $databasename
$deleteddatabase
# Do not continue until the cmdlet returns information about the deleted database.
 
Restore-AzureRmSqlDatabase -FromDeletedDatabaseBackup `
    -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -TargetDatabaseName $databasename `
    -ResourceId $deleteddatabase.ResourceID `
    -DeletionDate $deleteddatabase.DeletionDate `
    -Edition "Standard" `
    -ServiceObjectiveName "S0"

Weitere Beispiele-Skripte zum Thema Backup/Restore findet ihr hier => https://docs.microsoft.com/de-de/azure/sql-database/scripts/sql-database-restore-database-powershell

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

Resize einer Azure SQL Database mit Powershell – Teil 2

Nachdem ich im ersten Teil meiner Azure SQL Database Powershell Automation Reihe gezeigt habe, wie man sich die Ressource-Gruppe, den logischen SQL Server und die entsprechende Datenbank anlegt, möchte ich euch nun zeigen wie man ein Resize des Performance-Level dieser Datenbank umsetzen kann.
Warum soll man eine Datenbank resizen wollen? Nach oben – also mehr Leistung kann man vielleicht noch verstehen, aber warum auch wieder ein Downsizing machen? Also starte ich erst einmal mit den jeweiligen Gründen für eine Anpassung der gewählten Leistungsklasse.

Welche Leistung brauche ich wann?

Nehmen wir am besten ein Beispiel… eine größere Firma die Arbeitsplätze (Workspace) vermietet und nur in Deutschland aktiv ist, hat eine Applikation zur Verwaltung/Buchung ihrer Meetingräume bzw Arbeitsplätze. Diese Applikation wird von den Damen am Empfang nur während der “Öffnungszeiten” intensiv genutzt und außerhalb dieser Zeiten gelegentlich durch Mitarbeiter. Im Grunde benötigen die Empfangsdamen ihre Applikation und somit die Datenbank nur zwischen bestimmten Zeitpunkten, beispielsweise 7 – 20 Uhr, den Rest des Tages bleibt die Datenbank nahezu ungenutzt…
Was liegt also näher diese Datenbank tagsüber “schneller” zu machen? On-prem ist dies leider nicht möglich, da man einer einzelnen Datenbank nicht so ohne weiteres weitere Ressourcen zuweisen kann.

Ein weiteres Beispiel sind Auswertungen oder Verarbeitungen, hier können die betrieblichen Belange stark variieren, wenn am Monatsende der Abschluss ansteht wird mehr Rechenleistung in der Azure SQL Database benötigt, damit die Daten ausreichend schnell verarbeitet und bereitgestellt werden können.

  • je nach Applikation-Nutzung-Verhalten
  • je nach betrieblichen Anforderungen
    • nächtliche Verarbeitungen
    • Monatsabschluss
    • Jahres-End-Rally

Azure SQL Database

Was benötigen wir alles für einen Resize der Azure SQL Database

  • eine Resource Gruppe bzw deren Namen
  • einen Namen für den logischen SQL Server (der unique sein muss)
  • einen Datenbank Namen
  • das neue Performance-Level (DTU)

Die Anmeldung an Azure sowie die Auswahl der zu nutzenden Subscription lasse ich hier aussen vor und beginne mit dem eigentlichen Script.
Auch hier starte ich mit der Definition der notwendigen Variablen (siehe oben):

# Set the resource group name for your server
$resourcegroupname = "RG-AzureSQLDatabase-Demo"
# Set logical server name
$servername = "server-sqldbdemo"
# The sample database name
$databasename = "db-sqldbdemo"
# Set new performance-level
$newdbDTUsize = "S3"

Nun können wir die Azure SQL Database resizen

Dies ist wesentlich einfacher als die Neu-Anlage einer Datenbank, da wir weniger Variabeln (siehe oben) und nur eine Kommandozeile zur Ausführung benötigen. Aber auch frage ich vorsichtshalber das Vorhandensein der Datenbank ab, um sicherzustellen, dass das Script keinen “Blödsinn” macht.

# Resize Azure SQL Database to new performance-level
Get-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -ev notPresent -ea 0
if ($notPresent) {
    Write-Host $databasename "doesn't exist" 
} else {
    Set-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -Edition "Standard" -RequestedServiceObjectiveName $newdbDTUsize
}

Wie der Vorher-Nachher-Vergleich zeigt, ist ein Resize ohne Probleme möglich und dauert nur wenige Augenblicke.

Vorher-Nachher-Resize Azure SQL Database

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

Einstieg in Azure SQL Database mit Powershell – Teil 1

Neben der Möglichkeit in Azure sich einen virtuellen Server zu deployen auf dem ein SQL Server läuft, gibt es auch die “einfachere” Methode nur eine Datenbank on Demand zu deployen => die Azure SQL Database. Diese Database-as-a-Service kann man auch sehr gut und einfach für eine Vielzahl von Applikationen nutzen, wobei es auch eine Vielzahl an Optionen gibt über die man sich vorher Gedanken machen sollte.

  • reicht eine einfache Datenbank
  • lieber doch einen Elastic Pool
  • welche Region
  • oder doch lieber Geo-Redundant auslegen
  • reicht das “mitgelieferte” Backup
  • oder muss das Backup eine “Long Time Retention” erhalten
  • Wer greift von wo aus auf die Datenbank zu?
  • Welche Leistungsstufe brauche ich für die Datenbank bzw den Elastic Pool?

Eine Übersicht über die einzelnen Möglichkeiten und deren Verwendung für die jeweilige Solution, sowie eine großere Anzahl an Antworten auf viele Fragen findet man in der Dokumentation von Microsoft => https://docs.microsoft.com/en-us/azure/sql-database/

Beginn mit einer einfachen Azure SQL Database

Ein wichtiger Punkt in der Bereitstellung einer Azure SQL Database ist, dass man nicht nur eine Datenbank braucht sondern auch einen logischen SQL Server (=> Listener Endpunkt), ohne diese “Hülle” kann man keine Datenbanken hosten.

In meinem folgenden Beispiel legen wir mit Powershell eine Standard-Datenbank an, natürlich als Script, damit wir den Server und seine Datenbank oder nur die Datenbank immer wieder gleich (als Standard) anlegen können.

Was benötigen wir alles um eine Azure SQL Database anzulegen

  • eine Resource Gruppe bzw deren Namen
  • eine Location für die Resource Gruppe
  • Admin-Usernamen und Passwort
  • einen Namen für den logischen SQL Server (der unique sein muss)
  • einen Datenbank Namen
  • idealerweise auch die IP-Adressen/Ranges, die darauf zugreifen dürfen (die eigene IP reicht für den ersten Zugriff)

Die Anmeldung an Azure sowie die Auswahl der zu nutzenden Subscription lasse ich hier aussen vor und beginne mit dem eigentlichen Script.
Mein erstes Script startet also mit der Definition diverser Variablen (siehe oben):

# Set the resource group name and location for your server
$resourcegroupname = "RG-AzureSQLDatabase-Demo"
$location = "west europe"
# Set an admin login and password for your server
$adminlogin = "dbadmin"
$password = "DemoPwd@2017"
# Set server name - the logical server name has to be unique in the system
$servername = "server-sqldbdemo"
# The sample database name
$databasename = "db-sqldbdemo"
# The ip address range that you want to allow to access your server
$clientIP = (Invoke-WebRequest ifconfig.me/ip).Content
$startip = $clientIP
$endip = $clientIP

Nun das Erstellen des logischen Servers und der Azure SQL Database mit Beispiel-Daten

Nun kommt – wie in fast allen meinen Scripten – erst einmal die Abfrage ob die Resourcegruppe bereits exisitiert, wenn nicht wird sie angelegt. Nach der Resourcegruppe kommt als nächstes der logische Server in den wir zum Schluss unsere Azure SQL Database einbinden können. Dem logischen Server weisen wir noch die Credentials aus adminlogin und password zu, damit der Server als auch die Datenbanken geschützt sind. Apropos geschützt, auch die Firewall des Servers müssen wir natürlich für einen externen Zugriff öffnen, hierzu ermittel ich über eine zusätzliche Funktion und einen externen Dienst meine eigene Public-IP-Adresse. Mit dieser IP-Adresse konfigurieren wir nun den logischen SQL Server und zu guter Letzt prüfen wir ob die gewünschte Datenbank vielleicht schon existiert, wenn nicht wird diese mit den gewünschten Parametern erstellt.

# Create a resource group
Get-AzureRmResourceGroup -Name $resourcegroupname -ev notPresent -ea 0
if ($notPresent) {
    $resourcegroup = New-AzureRmResourceGroup -Name $resourcegroupname -Location $location
} else {
    Write-Host $resourcegroupname "already exists"
}
 
# Create a server with a system wide unique server name
Get-AzureRmSqlServer -ResourceGroupName $resourcegroupname -ServerName $servername -ev notPresent -ea 0
if ($notPresent) {
    $server = New-AzureRmSqlServer -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -Location $location `
    -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $adminlogin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
} else {
    Write-Host $servername "already exists"
}
 
# Create a server firewall rule that allows access from the specified IP range
Get-AzureRmSqlServerFirewallRule -ResourceGroupName $resourcegroupname -ServerName $servername -FirewallRuleName "AllowedIPs" -ev notPresent -ea 0
if ($notPresent) {
    $serverfirewallrule = New-AzureRmSqlServerFirewallRule -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -FirewallRuleName "AllowedIPs" -StartIpAddress $startip -EndIpAddress $endip
} else {
    Write-Host "FirewallRule already exists"
}
 
# Create a blank database with an S0 performance level
Get-AzureRmSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename -ev notPresent -ea 0
if ($notPresent) {
    $database = New-AzureRmSqlDatabase  -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -DatabaseName $databasename `
    -RequestedServiceObjectiveName "S0"
} else {
    Write-Host "Database" $databasename "already exists"
}

Nun können wir von unserer Workstation mittels SQL Server Tools – z.b. dem Management Studio – auf diese Datenbank zugreifen und die nutzende Applikation anbinden sowie testen.

Beispielzugriff - SSMS auf Azure SQL Database

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

dbatools – Copy-SqlLogin – Wie man Kunden beeindrucken kann

Für einen Kunden habe ich diese Woche einen neuen SQL Server 2016 SP1 + Management Studio installiert und konfiguriert, alle notwendigen Housekeeping-Jobs eingerichtet und mich um meine dokumentarischen Pflichten gekümmert. Über meine Rückmeldung, dass ich den Server bereits fertig hatte, freute sich mein Kunde und bat mich dann per Mail um folgendes:

[…]
Sent: Wednesday, June 21, 2017 3:43 PM

Außerdem sollten die SQL-User vom SQL01 übernommen werden (wenn möglich).
Geht das?
[…]

Vor zwei Jahren hätte ich wahrscheinlich geantwortet: “Ich versuche es, kann aber für nichts garantieren. Ich melde mich dann in 2 Tagen wenn ich fertig bin…”
Dann hätte ich mich daran gemacht und alle vorhanden Logins und deren Rechte auf Instanz- und Datenbankebene heraus geskriptet, auf dem neuen SQL Server eingespielt und den Kunden gebeten zu testen… (natürlich in der Hoffnung, dass alle Passwörter und Rechte passen) Mein Gott war das immer ein Aufwand, bei zwei oder drei Accounts war das ja gar nicht so das Problem, aber was wenn es plötzlich 100 Accounts sind 😮

Aber da gab es ja die Powershell-Modul-Sammlung von dbatools noch nicht, mit der ich ja bereits großartige Erfahrungen gemacht, schon in einigen Talks darauf hingewiesen und in meinem Blog darauf hingewiesen habe.

In dbatools gibt es eine Funktion “Copy-SqlLogin”, welcher laut Beschreibung alle meine gewünschten Aufgaben in einer Powershell Zeile vereint!

This command migrates logins from source to destination SQL Servers. Supports SQL Server versions 2000 and above. Migrates logins with SIDs, passwords, defaultdb, server roles & securables, database permissions & securables, login attributes (enforce password policy, expiration, etc).
By default, all logins with the exception of system (####Example Login## and local (SERVERNAME\administrators) logins are copied. The -Logins parameter is autopopulated for command-line completion and can be used to copy only specific logins.
If the login already exists on the destination, it will be skipped unless -Force is specified. Force drops and recreates the login.

Da die Anforderung des Kunden lautete “die SQL-User vom SQL01 übernommen werden”, brauchte ich nicht vorher zu analysieren, sondern einfach alle vorhandenen User des alten Servers auf den neuen Server migrieren. Dazu einfach die aktuelle Modul-Sammlung herunterladen, sicherstellen dass auf dem neuen Server auch mindestens Powershell 3 installiert ist. Wenn alles vorhanden ist, müssen die Module nur import werden und schon kann man mit den dbatools loslegen und alle Kommandos auf der Commandline ausführen oder in Scripten verwenden.

Um die Kundenanforderung zu erfüllen, nutze ich also die ganz einfache Kommandozeile:

Import-Module .\dbatools-master\dbatools.psd1
Copy-SqlLogin -Source SQL01 -Destination SQL02

Die Ausführung des Scriptes hat kaum 2 Minuten gedauert und alle User waren migriert!

Durch diese sehr starke Vereinfachung der Account Migration von einem SQL Server zum anderen, konnte ich dem Kunden sehr schnell eine Abschluss-Meldung schicken.

Gesendet: Mittwoch, 21. Juni 2017 15:56
Bitte sehen Sie diesen Task als erledigt an.

Die Antwort meines Kunden kam umgehend 😉

Sent: Wednesday, June 21, 2017 3:59 PM
Danke. Respekt!

(Man muss dazu wissen, dass diese Worte von diesem Kunden(-Mitarbeiter) schon “Gewicht” haben, da dieser sonst nicht so leicht zu beeindrucken ist, daher freuen mich diese Worte sehr!)

Vielen Dank an Chrissy LeMaire und die dbatools-Community für diese hervoragende Arbeit!

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

Azure Analysis Services – Powershell Automation im Tagesgeschäft

Im Rahmen des SQLGrillen 2017 hatte ich das Vergnügen mit Gabi Münster einen Vortrag über Azure Analysis Services und deren Automation halten zu dürfen. Diese Inhalte möchte ich euch nicht vorenthalten und im Folgenden näher erläutern, wobei es nicht um die Prozessautomatisierung der Datenbereitstellung geht sondern um die Automatisierung des Deployments bzw des eigentlichen Services, also Möglichkeiten wie man die Services dem Tagesgeschäft entsprechend optimal einsetzen kann. Die hierbei zum Einsatz kommenden Powershell Skripte habe ich versucht so einfach wie möglich zu halten um allen ein Verständnis zu ermöglichen.

Ausgangslage für die Powershell Automation

Sicherlich gibt es zahlreiche Möglichkeiten um die unterschiedlichen Funktionen, Services und VMs in Azure zu deployen oder bearbeiten, ob nun Azure Automation grafisch, als Runbook oder mit der Azure Command Line… ich habe mich als Ausgangslage dafür entschieden, dass die meisten im normalen Tagesgeschäft (meist on-prem) einen Server habe, der die Job-Steuerung übernimmt, dieser dient mir in meinen Beispielen als Ausgangspunkt für alle Skripte. Als weitere Voraussetzung nutze ich eine Active Directory (AD) Applikation und einen Service Principal um mich bzw meine Skripte an Azure anzumelden. Hierbei habe ich mich an die Beschreibung von Christos Matskas gehalten, die recht gut erläutert wie man sich einen Azure Automation Login erstellt.

Azure Analysis Services Automation programmieren

Diesen Login verwende ich nun entweder als Klartext oder als “INCLUDE” innerhalb meiner Skripte, um das Skript bei jeder Ausführung an Azure anzumelden.

$azureAccountName = "1234567-1234-1234-1234-012345678912" 
$azurePassword = ConvertTo-SecureString "Passwort@2017" -AsPlainText -Force 
$psCred = New-Object System.Management.Automation.PSCredential($azureAccountName, $azurePassword) 
Add-AzureRmAccount -Credential $psCred -ServicePrincipal -TenantId "1234567-1234-1234-1234-012345678912"

Was kann man nun automatisieren?

Mit Powershell kann man natürlich auch das Prozessieren der Datenbanken/Cubes automatisieren, aber darum soll es hier nicht gehen, sondern mehr darum was man als DBA oder DevOps “regelmäßig” machen kann/muss. Zum Beispiel benötigt man im Laufe des Tages nicht unbedingt die gleiche Leistung wie in der Nacht während der Verarbeitung. On-premise bleibt einem nichts anderes übrig als eine Hardware zu kaufen, die alle möglichen Lastzustände abdecken kann, in Azure ist das ein wenig anders, hier kann man entsprechend skalieren. Was unter Berücksichtgung eines gewissen Kostendrucks zu einem positiven Eindruck im Management führen kann, wenn man diesem erklären kann, dass die Kosten für eben diesen Azure Analysis Service durch Automatisierung variabl gestaltet werden kann. Aber fangen wir einmal vorne an…

Entsprechend der vorhandenen Umgebung oder der Konzeptionierung der Datenaufbereitung kann man sich zwischen horizontaler und vertikaler Skalierung entscheiden, bei der vertikalen Skalierung benötigen wir nur einen Azure Analysis Service, den wir nach Bedarf “größer” oder “kleiner” machen können. Bei horizontaler Skalierung könnte man sich zum Beispiel zu bestimmten Zeitpunkten weitere Azure Analysis Services hinzu deployen. Oder wenn man eine Testumgebung nur in bestimmten Zyklen braucht, dann kann man diese eben genauso automatisiert erstellen.

Deployment von Azure Analysis Services

Um den Azure Analysis Service neu oder weitere zu deployen benötigen wir den Powershell Befehl “New-AzureRmAnalysisServicesServer“, mit Anmeldung und weiterer Parametrisierung ergibt sich folgender Ablauf bzw folgendes Script:

  • Anmeldung an Azure
  • Variablen deklarieren (SubscriptionID, ResourceGroupName, AAS-Name, etc)
  • Prüfen ob die Ressource-Gruppe existiert, ggfs erstellen.
  • Prüfen ob der anzulegende Azure Analysis Service bereits existiert, ggfs erstellen
    • Angabe von ResourceGroupName, AAS-Name, Performance-Klasse und der EMail des Administrators
$myResourceGroupName = 'SQLGrillen2017'
$mySubscriptionID = '1234567-1234-1234-1234-012345678912'
$myLocation = 'West Europe'
$myAAServerName = 'asbeer01'
 
Set-AzureRmContext -SubscriptionId $mySubscriptionID
 
Get-AzureRmResourceGroup -Name $myResourceGroupName -ev notPresent -ea 0
if ($notPresent) {
    New-AzureRmResourceGroup -Name $myResourceGroupName -Location $myLocation
} else {
    write-host "ResourceGroup already exists"
}
 
Get-AzureRmAnalysisServicesServer -ResourceGroupName $myResourceGroupName -Name $myAAServerName -ev notPresent -ea 0
if ($notPresent) {
    New-AzureRmAnalysisServicesServer -ResourceGroupName $myResourceGroupName -Name $myAAServerName -Location $myLocation -Sku "S0" -Administrator "your-admin-mailadress@test-url.de"
} else {
    write-host "AAS Server already exists"
}

Die Ausführung dauert nicht wirklich lange, aber ein wenig Geduld muss schon aufbringen. (2-3 Minuten)

Geduld

Wieviel Leistung wann in Azure Analysis Services

Nun gibt es im Tagesverlauf oder Verlauf eines Monats unterschiedliche Last-Situationen, in der Nacht während der Verarbeitung wird mehr Leistung benötigt, als tagsüber wenn die Mitarbeiter nur ihre Reports ziehen oder Analysen machen. Weitere Möglichkeit sind der Monatsende, das Quartalsende oder der Jahresabschluss, hier wird wesentlich mehr Performance gebraucht als an anderen Tagen, wobei man on-Premise diese Kapazität von Anfang an bedenken muss und die Maschine entsprechend im voraus darauf auslegen, damit alle erdenklichen Last-Verhalten abgedeckt werden. Als Azure Analysis Services ist dies nun wesentlich einfacher, denn Azure bietet die Möglichkeit auf relativ einfache Art und Weise die Leistung des Service an die auftretende Last anzupassen. Auch hierzu benötigt man nur den Powershell Befehl “Set-AzureRmAnalysisServicesServer“, mit Anmeldung und weiterer Parametrisierung ergibt sich auch hier folgendes Script:

  • Anmeldung an Azure
  • Variablen deklarieren (SubscriptionID, ResourceGroupName, AAS-Name, etc)
  • Prüfen ob die Ressource-Gruppe existiert, ggfs erstellen.
  • Prüfen ob der anzulegende Azure Analysis Service existiert, um diese hoch oder runter zu skalieren
    • Angabe von ResourceGroupName, AAS-Name, neuer Performance-Klasse
$myResourceGroupName = 'SQLGrillen2017'
$mySubscriptionID = '1234567-1234-1234-1234-012345678912'
$myLocation = 'West Europe'
$myAAServerName = 'asbeer01'
 
Set-AzureRmContext -SubscriptionId $mySubscriptionID
 
# Upscale Azure Analysis Services
Get-AzureRmAnalysisServicesServer -ResourceGroupName $myResourceGroupName -Name $myAAServerName -ev notPresent -ea 0
if ($notPresent) {
    write-host "AAS Server does not exists"
} else {
    Set-AzureRmAnalysisServicesServer -Name $myAAServerName -ResourceGroupName $myResourceGroupName -SKU "S4"
}
 
# Downscale Azure Analysis Services
Get-AzureRmAnalysisServicesServer -ResourceGroupName $myResourceGroupName -Name $myAAServerName -ev notPresent -ea 0
if ($notPresent) {
    write-host "AAS Server does not exists"
} else {
    Set-AzureRmAnalysisServicesServer -Name $myAAServerName -ResourceGroupName $myResourceGroupName -SKU "S2"
}

Über das Skalieren des Azure Analysis Services kann man nun auch die Kosten reduzieren, da in der Nutzungsärmeren Zeit die benötigte Leistungsklasse verwendet wird und nur wenn die Verarbeitung läuft auf ein performanteres PerformanceModel skaliert. Dieses Skalieren funktioniert online, so dass man nicht einmal mit einer Unterbrechung des Services rechnen muss.

Resize Azure Analysis Services Demo

Kann man das auch abschalten?

In manchen Umgebungen und Lösungen ergibt sich unter Umständen auch die Notwendigkeit oder Möglichkeit den Azure Analysis Services komplett “abzuschalten”, entweder man hat horizontal skaliert und benötigt unter Tage kein Service oder die Solution gibt es her, dass nach der Verarbeitung kein Azure Analysis Service mehr benötigt wird. Hierzu bietet die Azure Powershell Automation ebenfalls ein Cmdlet (Suspend/Resume), mit dem man den Service pausieren bzw wieder starten kann. Da man dieses Skript nur einsetzt, wenn ein AAS bereits vorhanden ist, verzichte ich hier auf das Überprüfen der Ressourcen-Gruppe und prüfe nur, ob der Analysis Service mit dem gegebenen Namen tatsächlich vorhanden ist.

$myResourceGroupName = 'SQLGrillen2017'
$mySubscriptionID = '1234567-1234-1234-1234-012345678912'
$myLocation = 'West Europe'
$myAAServerName = 'asbeer01'
 
Set-AzureRmContext -SubscriptionId $mySubscriptionID
 
# Pause AAS
Get-AzureRmAnalysisServicesServer -ResourceGroupName $myResourceGroupName -Name $myAAServerName -ev notPresent -ea 0
if ($notPresent) {
    write-host "AAS Server does not exists"
} else {
    Suspend-AzureRmAnalysisServicesServer -Name $myAAServerName -ResourceGroupName $myResourceGroupName
}
 
# Resume AAS
Get-AzureRmAnalysisServicesServer -ResourceGroupName $myResourceGroupName -Name $myAAServerName -ev notPresent -ea 0
if ($notPresent) {
    write-host "AAS Server does not exists"
} else {
    Resume-AzureRmAnalysisServicesServer -Name $myAAServerName -ResourceGroupName $myResourceGroupName
}
Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.