How to: Das Windows AzureVM On/Off Szenario (IaaS)

Hallo @all,

[update: read this article in english, try bing translate]

im Anschluss an den Dynamic Infrastructure Day und die IT-Camps mit Windows Azure möchte ich das Skript zur Verfügung stellen und zeigen, wie man Cloud Computing für Infrastructure as a Service (IaaS) für das ressourcenschonende Arbeiten einsetzt.

Ich hole etwas aus, um zu zeigen, wie ich früher ohne Cloud gearbeitet habe und wie sich meine Arbeits- und Sichtweise mit der Cloud (Windows Azure) verändert haben. Skript und Vorgehensweise findet Ihr ganz unten.

Früher: Für die Projektarbeit, Trainings und Vortragsdemos für meine benötigten Technologien brauche ich als Evangelist eine Demo-, Entwicklungs- und Testumgebung. In meinem Fall besteht die aus SharePoint, SQL Server und diversen Business Intelligence-Szenarios. Zusätzlich benötige ich als Basis Windows Server und mindestens einen Domain Controller, um mehrere Maschinen im Verbund zu betreiben. Insgesamt hatten diese Anforderungen zur Folge, dass ich zwischen 5 und 10 virtuelle Maschinen auf meinem HyperV-Server betrieb. Um die VM-Images zuverlässig starten zu können, waren die Ressourcen in der Regel aufmerksam zu verwalten: Ich musste im HyperV-Server die Anzahl der ausgelasteten CPU-Kerne, den verfügbaren RAM und den verfügbaren Speicherplatz beobachten. Nach dem Arbeitstag wurden entweder alle virtuellen Maschinen heruntergefahren oder sie liefen einfach bis zum nächsten Tag weiter. Je nach Situation schaltete ich den HyperV-Server auch mal aus, um Strom zu sparen; die Belohnung für ressourcenschonendes Arbeiten war also einzig und allein die Stromersparnis. Darüber hinaus war ich dafür verantwortlich, meinem HyperV-Server stets die aktuellen Patchs und Service Packs zukommen zu lassen. In Summe bedeutete das alles sehr viel Zusatzaufwand, nur um vernünftig arbeiten zu können. Ist man dann noch viel unterwegs und arbeitet häufig remote, dann kann es schon vorkommen, dass der Server praktisch nie heruntergefahren wird und der Strom läuft und läuft und läuft. Auch mit Patchs geht man dann eher zurückhaltend um.

Rückblickend hätte ich da wohl gern früher etwas geändert. Aber besser spät als nie!

Jetzt: Mit der Cloud – Windows Azure Virtuell Machines – habe ich etwas, nein, sehr viel geändert! Heute schalte ich meine Cloud-Infrastructure an und aus wie es mir beliebt und nutze je nach Bedarf mehr oder weniger Hardware-Ressourcen, von einer Minute zur anderen. Brauche ich für einen Test schnell mal 50 CPU-Kerne, stehen mir diese sofort zur Verfügung. Unmittelbar nach dem Test gebe ich sie postwendend wieder zurück. Und wieso mache ich das? Weil ich jetzt richtig belohnt werde! In den stundengenau erfassten Compute-Stunden von Windows Azure sind die Windows Server-Lizenzkosten bereits enthalten. Befindet sich meine VM also im Zustand „Azure Off“, dann fallen auch keine Lizenzkosten, keine Stromkosten, alles in allem keinerlei Compute-Kosten an. Anfangs hatte ich aus Gewohnheit auch in Azure meine Maschinen immer überdimensioniert. Doch immer die XL-Maschine zu verwenden, ist weder kosteneffizient noch nötig, da ich mein Ziel meist auch mit einer S-, M- oder L-Instance erreiche und dabei wesentlich günstiger bin. Das lehrt mich ressourcenschonender zu arbeiten. Ein Beispiel: Ein Domain Controller erfordert keine XL-Größe, sondern funktioniert auch mit der Größe S oder gar XS sehr gut. Am meisten Ressourcen und Geld spart man bei aktiver Verwendung von „Azure On/Off“, denn wenn ich VM-Instanzen nicht mehr benötige, dann bringe ich sie in einen Zustand, in dem die VM nur noch Cloud-Speicher verbraucht, also wenige Cent pro GB im Monat kostet.

Voraussetzung:

Um das Szenario „Azure On/Off“ nutzen zu können, habe ich mich für die Azure-SDK Version 1.7 SP1 entschieden. Installiert habe ich es auf Windows 7 in der VS2010-Variante und auf Windows 8 in der VS2012-Variante, und zwar jeweils über den Web Installer von folgender Webseite: (Download)

Wie man sie eine Arbeitsumgebung zum Verwalten von Azure-Ressoursen einrichtet, zeigt mein früherer BlogPost: “How to Setup/Einrichten einer Azure Management Machine”.

Ich nutze einfach einen der folgenden beiden Links:

• • VS 2010 SP1 –> Dieser Link führt direkt zum Web-Plattform-Installer mit allen Komponenten für VS2010SP1.
  • VS 2012 –> Dieser Link führt direkt zum Web-Plattform-Installer mit allen Komponenten für VS2012.

Bei „Azure On/Off“ nutze ich die „PowerShell cmdlets“ für Azure, da dies vieles vereinfacht und automatisiert.

Was bringt Azure On/Off unter dem Strich?

Bei der Abrechnung von Diensten in der Cloud möchte ich meine Test-, Entwicklungs‑ bzw. Demo- oder Workshop-Umgebungen nur temporär betreiben. Doch was ist mit temporär konkret gemeint, wenn zum Beispiel ein Training um 9 Uhr beginnt und um 17 Uhr endet? Ganz einfach: Davor und danach wird die Umgebung schlicht nicht benötigt, denn alle Compute-Ressourcen bezüglich CPU und RAM müssen nur während des Training bereit stehen. Ich starte also 5 min. vor dem Training eine Hardwarereservierung, und damit ist meine Umgebung gleichzeitig mit einem Skript erstellt. Das klingt eindrucksvoller als es ist, denn de facto ist das Skript genau eine Zeile lang .
Mit der Hardwarereservierung entstehen Kosten; wie hoch die sind, erkläre ich unten. Sind Training, Demo oder Test vorbei, löse ich die Umgebung von der Hardwarereservierung, und zwar so lange, bis ich die Umgebung vielleicht Tage später mal wieder benötige.

Was kostet „Azure On/Off“ für virtuelle Maschinen?
Cloud-Computing für IaaS ist eine Hosting-Variante, erfordert jedoch keine 24x7‑Verfügbarkeit – zumindest im üblichen Sinn. Bei Cloud Computing geht es um die bedarfsgenaue Abrechnung: Wird eine Umgebung, d. h. eine Hardwarereservierung, aktiv, erst dann entstehen Kosten. Ist die Umgebung inaktiv, dann fallen keine Kosten an. Im Prinzip läuft das wie bei einem Mietwagen: Will ich ihn verwenden, leihe ich mir ihn und starte den Motor (analog die Compute-Units); bin ich am Ziel angekommen, schalte ich den Motor ab und gebe das Fahrzeug zurück. Setze ich analog dazu Azure Virtual Machines für das o. g. Training ein, dann „schalte ich den Motor“ um 9 Uhr ein. Pünktlich nach Ende des Trainings um 17 Uhr schalte ich „den Motor“, sprich die Umgebung, aus. Damit ergibt sich effektiv eine Dauer von 8 Stunden, für die ich die Cloud-Hardware (Hardwarereservierung) benötige – und genau für die zahle ich auch.

Was kostet eine Hardwarereservierung?

Folgende Berechnung dient nur als Beispiel und basiert auf den tagesaktuellen Preisen vom 7.12.2012. Danach kostet eine CPU/h: 0,08 € (VM Size: Small, ein Kern). Je nach VM-Größe werden unterschiedlich viele CPUs reserviert und entsprechend auch das Vielfache dieses Betrags pro Stunde berechnet. (M = 2 Kerne, L = 4 Kerne, XL = 8 Kerne ) Eine Ausnahme bildet die VM-Größe „XS“. Diese „Shared CPU“ kostet ein Drittel einer CPU. Im Überblick: Bei der VM-Größe „M“ ist der Ressourcenverbrauch doppelt so hoch wie bei VM-Größe „S“. Er verdoppelt sich jeweils wieder bei „L“ (4 Kerne) und bei „XL“ (8 Kerne). Um im Bild zu bleiben, auch ein Mietwagen für mehr Personen und mit stärkerem Motor wird teurer.

Zurück zum Beispieltraining von 9–17 Uhr: Ich benötige 8 h lang beispielsweise eine Umgebung mit 5 virtuellen Maschinen jeweils in XL-Größe (8 Kerne, 14 GB RAM). Daraus entsteht ein Gesamtressourcenverbrauch von:

8 h x 8 Kerne x 5 VMs = 320 CPU-Stunden (mit 0,08 €/h) entsprechen: 25,60 €

Komme ich mit Größe L (4 Kerne, 7,5 GB RAM) hin, dann halbiert sich auch der Ressourcenverbrauch:

8 h x 4 Kerne x 5 VMs = 160 CPU-Stunden (mit 0,08 €/h) entsprechen: 12,80 €

Hinzu kommt der Storage: Der Einfachheit halber gehe ich davon aus, dass nicht mehr als 1 TB Daten in den VHDs enthalten sind. Würden die VHDs über einen ganzen Monat in der Cloud liegen, dann wären die Kosten je nach Storage-Typ (Locally Redundant oder Geo Redundant) unterschiedlich hoch. Auch Cloud-Speicher wird im Übrigen stundengenau abgerechnet, d. h. kurzfristiges Hochladen und schnelles Bereinigen wird mit Kostenersparnis belohnt.

Für meine Demos, Trainings und Workshops reicht mir die billigere Speichervariante „Locally Redundant“ vollkommen aus . Bei Verwendung von Locally Redundant Storage im Volumen von 1 TB ergeben sich Stand 7.12.2012 monatliche Kosten von: 65,96 € bzw. ~2.13 € am Tag. Von Bedeutung ist also durchaus die Frage: Wie lange benötige ich die VHDs in der Cloud wirklich – einen Monat lang oder kürzer?

Auch hier spart die stundengenaue Abrechnung Ressourcen und bares Geld. Bei einem 8-stündigen Training, für das ich die VHDs einen Tag vorher in die Cloud hochlade, dann den Cloud-Storage vielleicht 2–3 Tage bei einer Größe von 1 TB belasse und dann wieder entferne, kann ich in Sachen Speicherkosten viel Geld sparen: Speicherkosten von 65,96 € für einen ganzen Monat stehen Kosten von 2,13 € pro Tag gegenüber, sprich ca. 8,50 € für vier Tage.

(Hinweis: Eine VHD mit einer Größe von 1 TB produziert nicht notwendigerweise Kosten für 1 TB an Storage. Es wird nur berechnet, was in der VHD an Daten effektiv enthalten ist. Sind also in der 1 TB-VHD nur 100 GB an Daten (Dateien) enthalten, dann werden auch nur 100 GB berechnet.) Das ist eine sehr angenehme Eigenschaft von Cloud-Speicher. Aus 65,96 €/Monat werden so bei effektiv 100 GB gerade einmal 6,596 €/Monat)

Das Endergebnis: Ein 8 h-Workshop mit einem Storage-Zeitraum von 2 Tagen verursacht für 5 VMs mit 1 TB an wirklichen Daten folgende Kosten:

8 h * 8 Kerne * 5 VMs = 320 CPU-Stunden (á 0,08 €/h) ergeben: 25,60 €
8 h * 4 Kerne * 5 VMs = 160 CPU-Stunden (á 0,08 €/h) ergeben: 12,80 €
8 h * 2 Kerne * 5 VMs = 80 CPU-Stunden (á 0,08 €/h) ergeben: 6,40 €

Wie sieht es mit dem Traffic aus? Der Vorteil: Bei der Microsoft Cloud wird nur ausgehender Traffic in Rechnung gestellt, ist also stark abhängig vom jeweiligen Szenario. Bisher noch nicht beachtet wurde, dass auch einzelne Storage-Zugriffe (pro Transaktion) einen kleinen Kostenfaktor darstellen. Bisher hatte ich bei meinen VMs in der Summe am Ende des Monats nie mehr als 2–4 Mio. Transaktionen produziert. (Achtung: Das ist meine persönliche Erfahrung aus der Art, wie ich meine Cloud verwende!)

    
Beispiel: Nach 227,89 Comute-Stunden hatte ich 1.797.700 = 1.8 Mio. Transaktionen.

Bei 4 Mio. Transaktionen auf dem Storage kämen 0,29 € im Monat zusammen. *Das ist somit nicht der wirklich entscheidende Faktor. Je nach Anwendungsfall kann also es noch etwas mehr oder weniger sein und diese Aufschlüsselung ist nur meine persönliche Erfahrung. Kostentreiber sind die Compute-Ressourcen gefolgt von Storage, und hier setzt das „Azure On/Off“-Szenario an*.

Wie funktioniert nun „Azure On/Off“?

Ganz einfach: Wer eine virtuelle Maschine in Azure betreibt, kann die AzureVM-Konfiguration in einer XML-Datei abspeichern. Dazu eignet sich das „PowerShell cmdlet“: Export-AzureVM

Export-AzureVM –ServiceName <cloudServiceName> –Name <VMname> –Path <c:\temp\vm1.xml>

Als komfortable Bulk-Operation sieht das Ganze so aus:

$Path = “c:\Azure\VMConfig”
Get-AzureVM | foreach { Export-AzureVM -ServiceName $_.ServiceName -Name $_.Name -Path ($Path+"\"+$_.Name+".xml").ToString() }

Nach erfolgreicher Ausführung finden wir im Ordner c:\Azure\VMConfig von jeder VM eine XML-Datei mit der VM-Konfiguration.

Jetzt schalten wir die VMs in den ressourcenschonenden Zustand und geben die Compute-Hardwarereservierung frei („Azure Off“ ):

#Bulk Azure Off , alle VMs werden in den Zustand gebracht
Get-AzureVM | Remove-AzureVM

VMs können auch getrennt angesprochen und einzeln in den „Azure Off“-Zustand gebracht werden:

# eine VM in den Zustand Azure Off bringen
Get-AzureVM –ServiceName <ServiceName> –Name <VMName> | Remove-AzureVM

Nach wenigen Minuten ist die Umgebung im Zustand „Azure Off“ . Eine Compute-Reservierung ist nicht mehr vorhanden, das heißt, ab jetzt verbrauchen nur noch die VHDs im Storage Ressourcen.

Wenn ich die Umgebung nun in diesem Zustand belasse, dann entstehen bezogen auf das o. g. Trainingsbeispiel Ressourcenkosten von 1 TB Storage pro Tag, das entspricht rund 2,13 €.

„Azure On“: Wenn ich die Umgebung zu einem späteren Zeitpunkt wieder verwenden möchte, führe ich einfach eine Hardwarereservierung aus und verwende hierzu ganz komfortabel die abgespeicherte XML-Konfiguration.

Pro XML-Datei (also pro VM) führe ich folgenden Befehl aus:

Import-AzureVM -Path "c:\Azure\VMConfig”\dc01.xml" |
New-AzureVM –ServiceName <hier Azure ServiceName>

Für den Netzwerkplaner in Azure kann man die VM auch gleich in ein Azure-Netzwerk einbinden (sofern das vorher definiert worden ist):

Import-AzureVM -Path "c:\Azure\VMConfig”\dc01.xml" |
New-AzureVM –ServiceName <hier Azure ServiceName> –VNetName <AzureNetzwerkName>

Wenige Minuten später ist die VM im alten Zustand wieder voll aktiv. Ist das nicht lässig?

Weiterhin viel Spaß mit Windows Azure Virtual Machines.

Liebe Grüße

Patrick