Microsoft Azure ist schon eine feine Sache. In Windeseile hat man neue Server instantiiert und deployt. Allerdings erfordert eine geteilte Infrastruktur wie sie Azure darstellt auch eine andere Denkweise als die klassischen Servern in In-House Rechenzentren. Bei Azure bezahlt man für die Bereitstellung und Leistung einer virtuellen Maschine, d.h. wenn man einen virtuellen Server einfach „durchlaufen“ lässt kann das ganz schön ins Geld gehen. Im heimischen Rechenzentrum konnte man bisher Server einfach durchlaufen lassen, da es „Eh-Da-Kosten“ sind, d.h. ob der Server läuft oder nicht ist hier aus Kostengesichtspunkten egal bzw. schlägt nicht so ins Geld. Das ein durchlaufender Server in Azure recht teuer werden kann ist auch klar, da Microsoft die zugrunde liegende Infrastruktur vermietet und es den Kollegen aus Redmond ziemlich egal ist ob der von uns gemietete Server etwas sinnvolles macht oder nur vor sich „hinidelt“. Fakt ist, solange wir einen Server hochgefahren haben und dieser Ressourcen belegt können diese nicht von anderen Kunden genutzt werden und müssen uns dementsprechend auch, zu Recht, in Rechnung gestellt werden.

In diesem kleinen Artikel möchte ich einmal aufzeigen wie man in Azure Automatisierungsscripte schreiben kann die Server automatisch hoch- und runterfahren um so unnötige Kosten zu vermeiden. Unter Azure gilt – wird der Server nicht gebraucht, so können wir ihn deallokieren – dann kostet er auch nichts. Hat man hier eine intelligente Strategie entwickelt wie Server hoch und runtergefahren werden, so lässt sich auf jeden Fall eine Menge Geld sparen.

Dreh- und Angelpunkt für unser Vorhaben stellt die Azure Automation dar. Die Azure Automation ist eine Prozess- und Workflow Engine über die man viele Aspekte der Azure Plattform wie beispielsweise Virtuelle Maschinen, Websites oder Cloud Services automatisieren kann. Wichtige Funktionalitäten der Azure Automation sind:

• Graphische Benuzeroberfläche über die man Runbooks erstellen kann.
• Integration einer Runbook-Gallery
• Unterstützung von PowerShell DSC (Desired State Configuration) und ARM (Azure Resource Manager)

Um die Azure Automatisierung nutzen zu können muss man zunächst ein Azure Automatisierungskonto besitzen. Mit diesem kann man dann Runbooks erstellen die PowerShell Workflows mit der benötigten Funktionalität enthalten. In unserem Beispiel werden wir Azure VMs automatisch starten und beenden. Diese Runbooks werden dann mit einem Zeitplan verknüpft und zu den dort definierten Zeiten ausgeführt.

Ich werde nun erklären, wie man mit Hilfe der Azure Automatisierung Azure VMs zu einem bestimmten Zeitpunkt automatisch starten und zu einem anderen Zeitpunkt wieder automatisch beenden kann. Im hier vorgestellten Szenario gibt es zwei Server in der Subscription. Der eine Server ist ein Domänencontroller, der andere Server ein Terminalserver. Die Aufgabe ist es die beiden Server unabhängig voneinander zeitgesteuert hoch und runter zu fahren. Außerhalb der Office-Zeiten und am Wochenende sollen die Server nicht zur Verfügung stehen, während der Büro-Öffnungszeiten stehen die Server zur Verfügung.

Für die Automatisierung benötigen wir zunächst ein Automatisierungskonto. Dies wird unter Monitoring + management -> Automation hinzugefügt

Im Detailbereich müssen dann die entsprechenden grundlegenden Informationen eingegeben werden. Wichtig hier ist der Name und die Zuordnung zum Abonnement und der Ressourcengruppe.

Nachdem das Automatisierungskonto angelegt wurde kann man es im Bereich Automation-Konten sehen.

Durch einen Klick auf das Automatisierungskonto kann man alle damit verknüpften Resourcen sehen und auch neue Jobs, Runbooks etc. anlegen.

Damit man nun PowerShell Scripte ausführen kann benötigt Azure Anmeldeinformationen. In unserem Beispiel werden wir als Anmeldeinformation einen Azure RM AD Dienstkonto verwenden. Diesem können dann fein granulare Berechtigungen auf die Ressourcen im Azure Active Directory zugewiesen werden. So ist es beispielsweise möglich ein solches Konto auf eine einzige Resource Gruppe zu beschränken. Es gibt bereits viele vordefinierte Rollen aber natürliche können auch eigene Rollen angelegt werden. Wie das genau geht kann man hier finden.

Beim Anlegen des Automatisierungskontos wurde bereits Konten angelegt unter denen die Runbooks ausgeführt werden können, d.h. man muss nicht – wie das früher der Fall war – einen Dienstkonto-Prinzipal anlegen.

Nach diesen Vorarbeiten können wir nun endlich die Runbooks erstellen. Zum Glück gibt es bereits Runbooks die unsere Aufgabenstellung erfüllen können. Um diese auszuwählen klickt man zunächst auf Runbooks und dann oben auf den Menüpunkt Katalog durchsuchen.

 

Im Katalog gibt es die beiden Runbooks „Stop Azure V2 VMs“ und „Start Azure V2 VMs“ die wir für unser Szenario nutzen wollen.

Zunächst erstellen wir das Runbook für den Terminalserver das diesen startet. Hierzu klicke ich auf „Start Azure V2 VMs“ und es wird ein grafisches Runbook angezeigt das alle Schritte enthält um einen Server zu starten.

Um das Runbook in den Azure-Account zu übernehmen muss man auf die Schaltfläche Importieren klicken.

Dann gibt man dem Runbook einen Namen und klickt auf OK.

Wenn wir nun auf die Schaltfläche Bearbeiten klicken können wir das importierte Runbook nun anpassen und auch einen Testlauf durchführen.

Um einen Testlauf durchzuführen muss man oben auf die Schaltfläche Testbereich klicken.

Nun wird ein Fenster angezeigt in dem man die optionalen Parameter für den Testlauf eingeben kann. Gibt man dort keine Werte an, so werden alle ARM-AzureVMs der Subscription gestartet. Gibt man einen Parameter für die Resourcegruppe an und lässt den Maschinennamen offen werden alle ARM-AzureVMs der Resourcegruppe gestartet. Gibt man den Maschinennamen auch an wird nur die entsprechende Maschine gestartet.

Nach dem Speichern des Testlaufs wird dieser in die Warteschlange eingereiht und dann irgendwann ausgeführt.

Als Ergebnis läuft unsere virtuelle Maschine. Da der Test positiv verlaufen ist müssen wir das Runbook jetzt veröffentlichen um dann einen Zeitplan für das Runbook zu erzeugen. Dazu klickt man einfach auf die Schaltfläche „Veröffentlichen“ und bei der Abfrage ob das Runbook überschrieben werden soll klickt man einfach auf „Ja“.

Als nächstes müssen wir einen Zeitplan hinzufügen. Hierzu klickt man zunächst auf Zeitplan und dann auf die Schaltfläche „Zeitplan hinzufügen“.

Nun muss man zunächst auf Zeitplan und dann auf Neuen Zeitplan erstellen klicken. Ich habe hier zunächst alle Informationen angegeben, dass der Terminal-Server jeden Tag um 06:30 gestartet wird. Dies soll jeden Tag wiederholt werden.

Da das von uns verwendete Runbook über Parameter verfügt müssen wir diese für den definierten Zeitplan auch festlegen. Hierdurch ist es uns mit einem einzigen Script möglich mehrere Server zu unterschiedlichen Zeiten zu starten. Um das zu tun muss man auf „Parameter und Ausführungseinstellungen“ klicken und dann genau dieselben Werte für die Parameter eingeben die wir auch oben für den Test genutzt haben.

Nun haben wir einen Zeitplan für den Terminal-Server erstellt. Genau das Gleiche müssen wir jetzt noch für den Domänencontroller machen. Außerdem sollten wir auch noch das Stop-Runbook das ich oben erwähnt habe in unsere Azure Subscription importieren und es genau so wie das Start-Runbook konfigurieren. Die ausführlichen Schritte spare ich mir hier einmal, da das genau so funktioniert wie beschrieben, nur mit anderen Werten.

Es bleibt festzuhalten, dass die Option Azure Maschinen mit Runbooks zeitgesteuert hoch und runter zu fahren eine große Kostenersparnis mit sich bringen kann. Geht man beispielsweise davon aus, dass man Azure Maschinen nur zu den Bürozeiten 8 Stunden ausführt, so hat man eine recht große Kostenersparnis, da die Maschinen 67% der Zeit keine bzw. nur sehr gering (für den Speicherplatz) Kosten produzieren.