Azure Burstable VM's

Für eine VM mit der Grösse D2ds_v4 mit Windows Server Lizenz fallen mit 3-jähriger Reservation ca. 97.-/Monat an. Die gleiche VM kostet ohne Windows Lizenz oder mit Hybrid Benefit nur 37.-/Monat. 60.- also nur für die Windows Server Lizenz.

Die B2ms kostet mit 3-jähriger Reservation mit Windows Lizenz 31.-/Monat. und ohne Lizenz nur 26.-/Monat. Hier zahlt man also für die Windows Server Lizenz etwas mehr wie 5.- pro Monat!

Setzt man Linux als Betriebssystem ein oder bringt eigene Windows Lizenzen mit, ist die Preisdifferenz zu anderen VM-Grössen deutlich geringer. Im obigen Beispiel wäre die Bsv2_v2 ohne Lizenz "nur" ungefähr 20% günstiger als die D2_v4.

Azure Burstable VM's

Während herkömmliche virtuelle Azure-Maschinen eine feste CPU-Leistung bieten, sind virtuelle Maschinen der B-Serie der einzige VM-Typ, der Credits für die Bereitstellung der CPU-Leistung verwendet. Die virtuelle Maschine sammelt CPU-Guthaben an, wenn ein Workload unterhalb der Basis-CPU-Leistungsschwelle läuft und verbraucht Guthaben, wenn sie oberhalb der Basis-CPU-Leistungsschwelle läuft, bis das Guthaben aufgebraucht ist. Wenn das gesamte CPU-Guthaben verbraucht ist, wird die virtuelle Maschine auf ihre Basis-CPU-Leistung zurück gedrosselt, bis sie das Guthaben für einen erneuten CPU-Burst angesammelt hat.

Das Modell ist vergleichbar mit einem Mobile-Abo mit Datenlimit. Sobald das Datenlimit erreicht wurde, wird die Geschwindigkeit gedrosselt, bis Guthaben aufgeladen wird oder ein neuer Abrechnungszeitraum beginnt. Eine VM der B-Serie lädt sich jedoch von selbst wieder auf, wenn die CPU-Last unter einen bestimmten Grenzwert fällt.

CPU-Credits im Detail

Schauen wir uns die VM-Grössen der B-Serie genauer an. Aufgrund Quota-Limits in meiner Test-Umgebung beziehe ich mich in diesem Abschnitt auf VM-Grössen der B-Serie V1

Die Base CPU Performance ist die CPU-Leistung, die einer VM immer zur Verfügung steht. Liegt die CPU-Last unter diesem Grenzwert, werden CPU-Credits akkumuliert. Liegt die Last über dem Grenzwert, werden CPU-Credits verbraucht.

Einige Beispiele anhand der Grösse "Standard_B2ms":

• Liegt die CPU-Last bei 0 %, werden pro Stunde 36 Credits akkumuliert, bis zu einem Maximalwert von 864 Credits.

• Liegt die CPU-Last bei 100 %, werden pro Stunde 84 Credits verbraucht, bis alle Credits aufgebraucht wurden.

• Wurden alle Credits aufgebraucht, wird die CPU-Performance auf 30 % gedrosselt.

• Stehen Credits zur Verfügung, kann die VM im Burst-Modus betrieben werden und 100 % der angegebenen CPU-Leistung nutzen.

Mithilfe dieser Formel kann der Credit-Verbrauch pro Minute kalkuliert werden:
((Base CPU performance * number of vCPU) - (Percentage CPU * number of vCPU))/100

Angenommen, die CPU-Last liegt bei 65 %, lautet die Rechnung:
((30* 2) - (65 * 2))/100 = -0.7
Bei einer CPU-Last von 65 % werden pro Minute 0.7 Credits und pro Stunde 42 Credits verbraucht.

Wie lange dauert es bei einer CPU-Auslastung von 100 %, bis alle Credits aufgebraucht wurden?
864 / (((30* 2) - (100 * 2))/100) = 617 Minuten oder ungefähr 10 Stunden

Wie lange dauert es bei einer CPU-Last von 0 %, bis das maximale Guthaben von 864 erreicht wird?
864 / (((30* 2) - (0 * 2))/100) = 1140 Minuten oder 24 Stunden

Die Erkenntnis aus den Berechnungen: Die Akkumulation und der Verbrauch der Credits sind den Berechnungen zufolge relativ träge. Trotzdem besteht die Gefahr, dass bei anhaltender hoher Last die VM innerhalb weniger Stunden auf die Basis-Performance gedrosselt wird.

Die CPU-Credits sollten deshalb im Betrieb laufend überwacht werden.

Monitoring der CPU-Credits

Für die Tests habe ich eine virtuelle Maschine der Grösse "Standard_B2ms" mit Windows Server 2022 bereitgestellt. Die CPU-Credits lassen sich im Azure-Monitor über die Metriken "CPU Credits Consumed" und "CPU Credits Remaining" überwachen. Auch Alarmierungen per E-Mail oder SMS lassen sich einrichten.

Mithilfe von Azure Chaos Studio habe ich verschiedene Prozessor-Lasten simuliert.

1. Nach Provisionierung der VM stehen die initialen 60 Credits zur Verfügung.

2. Ohne CPU-Last bis innert 24 Stunden auf max 916 Credits (interessanterweise höher als die angegebenen 864 Credits)

3. CPU Last 99% über 1 Stunde -> ca. -80 Credits

4. CPU Last 50% über 1 Stunde -> ca. -24 Credits

5. CPU Last 20% über 1 Stunde -> ca. +12 Credits

An dieser Stelle noch der Hinweis, dass der Datendurchsatz zusätzlich von der Disk abhängt. Eine Premium SSD mit 128 GB unterstützt beispielsweise 100 Mb/s und 170 Mb/s im Burst-Mode.

Die älteren B-Serien unterstützen gemäss dieser Seite kein Hyperthreading Serien virtueller Computer | Microsoft Azure. Bei den neueren Serien wird Hyperthreading gemäss dieser Seite unterstützt: Bsv2 Series (preview) - Azure Virtual Machines | Microsoft Learn.

B-Serie einer der Meistgenutzten?

Zwei Fun-Facts, auf die ich gestossen bin...

Wenn man im Azure Portal eine VM erstellt, erscheint bei der Auswahl der VM-Grösse eine Übersicht der meistgenutzten VM-Grössen. Hier ist die B-Serie relativ prominent vertreten. Wie diese VM's eingesetzt werden, lässt sich daraus jedoch nicht schliessen.

Das Betreiben von Virtual Machines (VMs) in Azure kann kostspielig sein, wenn nicht die passende und kosteneffizienteste VM-Grösse gewählt wird. Die Burstable-Serie bietet im Vergleich zu anderen Serien erhebliche Kosteneinsparungen. Doch was sind Burstable-VM's? Sind Burstable-VM's für produktive Workloads geeignet? Falls ja, welche Faktoren müssen berücksichtigt werden?

VM-Grössen

Die Leistung einer VM (virtuelle Maschine) in Azure wird durch die sogenannte "Grösse" definiert. Die geeignete VM-Grösse wird auf der Grundlage von Anforderungen wie Prozessor (CPU), Arbeitsspeicher, Speicher und Netzwerkbandbreite ausgewählt. Die Grössen werden in verschiedene Familien und Typen eingeteilt, die jeweils für bestimmte Zwecke optimiert sind.

• B-Serie: Universelle VM-Grössen, mit CPU-Guthabenmodell

• D-Serie: Universelle VM-Grössen

• E-Serie: Arbeitsspeicheroptimiert, für relationale Datenbanken, mittelgrosse bis grosse Caches und In-Memory-Analysen

• F-Serie: Für Compute optimiertert, geeignet für Webserver, Netzwerkgeräte, Batchvorgänge und Anwendungsserver mit mittlerer Auslastung

• NV-Serie: GPU-optimiert, für rechen- und grafikintensive Workloads
  
  

Mehr zu den Grössen findest du unter: https://learn.microsoft.com/de-de/azure/virtual-machines/sizes/

Die Auswahl der passenden Grösse ist entscheidend. Zum einen hängen die Betriebskosten einer VM von ihrer Grösse ab, zum anderen möchte man der VM ausreichend Ressourcen bereitstellen, damit sie nicht an ihre Kapazitätsgrenzen stösst.

Die unten stehende Tabelle zeigt beispielhaft einige Grössen und Kosten bei einer Reservation der Ressourcen über 3 Jahre mit enthaltener Windows-Server-Lizenz in der Region "Switzerland North" (Stand Juli 2024). Weitere Preise können dem Microsoft Azure Preisrechner entnommen werden.

Auch weitere Eigenschaften wie Prozessortyp, Datendurchsatz von Speicher und Netzwerk, etc. werden über die VM-Grösse festgelegt. Diese Eigenschaften sollten bei der Wahl der Grösse berücksichtigt werden. Ein direkter Vergleich anhand der Werte in der obigen Tabelle ist nicht ausreichend.

Ist dir in der obigen Tabelle aufgefallen, dass die Grössen der B-Serie (B für Burstable) deutlich günstiger sind als die der D-Serie, obwohl sie ungefähr die gleichen Leistungsmerkmale aufweisen?

Windows Lizenz macht den Unterschied

Der grösste Teil des Preisunterschieds macht die enthaltene Windows Server Lizenz aus, die bei den B-Serien viel günstiger zu haben ist.

Ausserdem konnte ich der Region "East US" keine Maschine der Grösse "b2s_v2" aufgrund zu grosser Nachfrage erstellen. Ich musste auf eine andere Region ausweichen.

Fazit

Aus Gründen der Sicherheit, Redundanz, Skalierbarkeit und Manageability werden Dienste in der Regel auf mehrere VM's verteilt. Oft schlummern diese VM's den ganzen Tag vor sich hin und sind selten ausgelastet.

Wenn der Workload einer virtuellen Maschine einigermassen vorhersehbar ist, können bzw. sollten virtuelle Maschinen der B-Serie in Betracht gezogen werden - auch für produktive Systeme. Das Kosteneinsparungspotenzial bei der B-Serie ist zumindest bei VM's mit dem Windows-Server-Betriebssystem schlicht zu gross, als dass sie ausser Betracht gelassen werden könnte. Eine überprovisionierte VM der B-Serie kann unter Umständen günstiger sein als eine unterprovisionierte VM einer anderen Serie.

Aus eigener Erfahrung kann ich berichten, dass sich die B-Serie bewährt hat. Beispielsweise bei Domain-Controllern, Jump-Hosts, Print-Server, Monitoring-Server, kleinere Web-, SQL- und Anwendungs-Server, usw. In Testumgebungen ist die B-Serie sowieso ein No-Brainer.

Es ist empfehlenswert, die B-Serie kontinuierlich zu überwachen, da unerwartete und anhaltende CPU-Belastungen die Leistung der VM massiv beeinträchtigen können.

Achtung: Bei den Tests ist mir aufgefallen, dass bei einem Neustart der VM die CPU-Credits auf die initialen 60 Credits zurückgesetzt wird. Alle akkumulierten Credits gehen bei einem Neustart verloren.

B-Serie nur für Test-Umgebungen?

Die Annahme, dass die VM-Grössen der B-Serie nur für Testzwecke geeignet sind, scheint weit verbreitet. Aber ist das wirklich so?

Gemäss Microsoft offensichtlich nicht - hier ein Auszug der Beschreibung der Bsv2-Serie:
Bsv2 Series (preview) - Azure Virtual Machines | Microsoft Learn
"Bsv2-series (...) are a cost-effective way to run a broad spectrum of general-purpose workloads, including large-scale micro-services, small and medium databases, virtual desktops, and business-critical applications"

Auch auf dem Papier muss sich die B-Serie nicht verstecken, wie folgender Vergleich zwischen den Grössen "B2s_v2" und "D2s_v4" zeigt: