Bv1 ablösen: ein Leitfaden in sechs Schritten

Schritt 1: Bestand erfassen

Diese Abfrage im Azure Resource Graph listet alle Bv1-VMs in den Subscriptions, auf die Sie Lesezugriff haben. Größen der zweiten Generation enden auf _v2 und werden nicht erfasst.

resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend size = tostring(properties.hardwareProfile.vmSize)
| where size matches regex @'(?i)^standard_b[0-9]+[a-z]*$'
| summarize vms = count() by size, location, subscriptionId
| order by vms desc

Ergänzen Sie die Liste um Betriebssystem, Zweck und Verantwortlichen. Ein Teil der VMs wird sich dabei als stilllegbar herausstellen.

Schritt 2: Credit-Verlauf auswerten

B-VMs sammeln CPU-Credits, solange sie unter ihrer Basisleistung laufen, und verbrauchen sie darüber. Sind die Credits aufgebraucht, drosselt Azure die VM auf die Basisleistung. Azure Monitor zeigt das über die Metriken „CPU Credits Remaining“ und „CPU Credits Consumed“.

Werten Sie 30 Tage aus. VMs, die regelmäßig bei null ankommen, gehören auf eine D-Größe mit fester Leistung. VMs, die ihre Credits kaum antasten, vertragen oft eine kleinere Zielgröße.

Schritt 3: Zielgröße nach Arbeitsspeicher wählen

Zur Wahl stehen Bsv2 mit Intel-Prozessoren, Basv2 mit AMD EPYC und Bpsv2 mit Arm64, wobei Bpsv2 praktisch nur für Linux mit Arm-Builds in Frage kommt. Bsv2 und Basv2 unterstützen Generation 1 und 2 sowie beschleunigten Netzwerkbetrieb, aber keine Ephemeral-OS-Datenträger.

Die Namen führen in die Irre. Eine B2s der ersten Generation hat 2 vCPU und 4 GiB, die B2s_v2 hat 8 GiB. Zuordnung nach Arbeitsspeicher:

• B2s (4 GiB): B2ls_v2 oder B2als_v2, Basisleistung 30 Prozent
• B2ms (8 GiB): B2s_v2 oder B2as_v2, Basisleistung 40 Prozent
• B4ms (16 GiB): B4s_v2 oder B4as_v2, Basisleistung 40 Prozent
• B1ls, B1s, B1ms: kein Nachfolger mit einer vCPU. Die kleinste Größe ist B2ts_v2 mit 1 GiB und 20 Prozent. Bei Windows steigt mit der zweiten vCPU auch der Lizenzanteil im VM-Preis.

Schritt 4: Migrationsweg festlegen

Bv1-Größen haben einen lokalen temporären Datenträger, die Nachfolger nicht. Für Linux erlaubt Azure die Größenänderung zwischen beiden Varianten, solange weder Swap noch Anwendungsdaten auf dem temporären Datenträger liegen.

Für Windows ist sie nicht erlaubt. Azure lehnt sie mit dem Hinweis ab, dass der Wechsel zwischen Größen mit und ohne Ressourcendatenträger nicht zulässig ist. Der dokumentierte Weg:

• Auslagerungsdatei von D: nach C: verlegen und die VM neu starten.
• Snapshot des Systemdatenträgers erstellen.
• Aus dem Snapshot eine neue VM in der Zielgröße erzeugen.

Schritt 5: Folgearbeiten an der neuen VM

Für Azure ist die neue VM eine neue Ressource. Prüfen und neu setzen:

• Backup-Schutz. Die Wiederherstellungspunkte der alten VM bleiben am alten Sicherungselement.
• Site-Recovery-Replikation.
• Erweiterungen, Monitoring-Agent und Zuordnungen zu Datensammlungsregeln.
• Tags, Rollenzuweisungen auf VM-Ebene, Defender-Einstellungen.
• Netzwerkkarte: Nach dem Löschen der alten VM lässt sich die bestehende NIC an die neue hängen, die private IP-Adresse bleibt erhalten.
• Alte und neue VM nie gleichzeitig mit demselben Systemstand im Netz betreiben. Gleicher Computername und gleiche Domänenidentität führen sonst zu Anmeldefehlern.

Schritt 6: Pilot, Wellen, Aufräumen

• Pilot mit einer unkritischen Windows-VM, einschließlich Backup und Wiederherstellungstest.
• Wellen nach Abhängigkeiten planen, nicht nach Größe.
• Reservierungen oder Savings Plan erst auf Basis des gemessenen Zielzustands kaufen.
• Alte Datenträger und Snapshots nach einer festgelegten Frist löschen.

Mehr dazu: Bv1-Reservierungen: Fragen und Antworten für Controlling und FinOps

Arbeitsteilung

Die Kosten- und Migrationsanalyse liefert die Schritte 1 bis 4 als Tabelle je VM: Bestand, Credit-Auswertung, Zielgröße und Migrationsweg, ergänzt um die Kostenrechnung. Die Schritte 5 und 6 setzt Ihr Team oder Ihr Dienstleister um.