Azure VM Right-Sizing: ein praktischer Leitfaden

Azure VM Right-Sizing ist die Praxis, die Größe einer virtuellen Maschine, also ihre SKU, an die CPU, den Speicher und das Netzwerk anzupassen, die sie tatsächlich nutzt, statt an die Größe, mit der sie zufällig bereitgestellt wurde. In den meisten Umgebungen wurden einige Maschinen für eine Launch-Spitze dimensioniert oder von On-Premises-Hardware übernommen und laufen seither unter dieser Obergrenze. Um virtuelle Azure-Maschinen richtig zu dimensionieren, sammeln Sie über einen repräsentativen Zeitraum, meist 30 Tage, Auslastungsnachweise, finden die Maschinen, deren anhaltende und Spitzenauslastung deutlich unter ihrer bereitgestellten Kapazität liegt, und verschieben sie dann mit vernünftigem Puffer auf eine kleinere SKU. Mit Evidenz statt einem Bauchgefühl umgesetzt, ist es eine der am besten wiederholbaren Möglichkeiten, die Azure-Compute-Kosten zu senken, während die Workload weiterläuft.

Dieser Leitfaden geht die vollständige Schleife durch: warum Maschinen überdimensioniert enden, wie Sie die Evidenz sammeln, die Advisor-Empfehlungen lesen, eine Zielgröße wählen, eine virtuelle Azure-Maschine sicher neu dimensionieren und das Ergebnis festhalten. Die Zahlen sind richtungsweisend, weil sie von Ihrer Umgebung abhängen, doch die Methode gilt überall.

Warum virtuelle Maschinen überdimensioniert enden

Überdimensionierung beginnt selten als Fehler. Sie beginnt als Vorsicht, die nie erneut betrachtet wird.

• Für die Launch-Spitze dimensioniert. Eine Maschine wird für den geschäftigsten Tag bereitgestellt, den sie je erleben könnte, einen Migrationsumstieg, einen Launch, eine saisonale Spitze, dann geht der geschäftige Tag vorbei und die Größe bleibt.
• Gewohnheiten aus Lift-and-Shift. Wenn eine Workload von einem physischen oder On-Premises-Server umzieht, gleichen Teams oft die alten Kern- und Speicherzahlen eins zu eins ab, obwohl diese Maschine selbst mit jahrelangem eingebautem Puffer gekauft wurde.
• Puffer als Versicherung. Eine größere Größe fühlt sich sicherer an als eine Entscheidung, die sich als leicht zu knapp herausstellt, sodass die sicherer wirkende Option standardmäßig gewinnt.
• Niemand verantwortet die Überprüfung. Die Größe wird einmal bei der Bereitstellung festgelegt und nie mit dem abgeglichen, was die Maschine tut, sodass die Rechnung stillschweigend eine Entscheidung widerspiegelt, die nicht mehr gilt.

Keine davon ist im Moment unvernünftig. Das Problem ist, dass der Moment endet und die Größe nicht.

Die Evidenz mit Azure Monitor sammeln

Right-Sizing ohne Daten ist Raten mit zusätzlichen Schritten, beginnen Sie also mit der Auslastung. Azure Monitor sammelt automatisch Plattformmetriken für jede virtuelle Maschine, ohne Agent oder Konfiguration.

Öffnen Sie im Portal Virtual machines, wählen Sie die Maschine aus und wählen Sie dann unter Monitoring entweder Metrics für Rohdiagramme oder Insights und dann die Registerkarte Performance für eine aufbereitete Ansicht. Die für die Compute-Dimensionierung wichtigste Metrik ist Percentage CPU, eine Plattformmetrik auf Hostebene, die als Prozentsatz mit einer Granularität von einer Minute und einer standardmäßigen Durchschnittsaggregation gemeldet wird. Urteilen Sie nicht allein anhand des Durchschnitts: Zeichnen Sie die anhaltende Linie und das 95. Perzentil zusammen, denn eine Maschine kann im Durchschnitt ruhig wirken und dennoch Puffer für kurze, regelmäßige Lastspitzen benötigen. Das CPU-Auslastungsdiagramm der Performance-Ansicht zeigt standardmäßig den Durchschnitt und das obere 95. Perzentil.

Beim Speicher ist etwas Sorgfalt nötig. Die Plattformmetriken auf Hostebene stellen Available Memory Bytes bereit, doch die granularen Zähler auf Gastebene, die verfolgen, wie viel Speicher das Betriebssystem tatsächlich belegt, werden über den Azure Monitor Agent innerhalb der Maschine gesammelt, nicht standardmäßig. Wenn Sie zusätzlich zur CPU auch nach dem Speicher dimensionieren wollen, bringen Sie den Agent zuerst ins Spiel und lesen Sie dann den verfügbaren Speicher über dasselbe Zeitfenster. Das Diagramm für verfügbaren Speicher der Performance-Ansicht zeigt standardmäßig den Durchschnitt plus das obere 5. und 10. Perzentil und zeigt so die knappen Momente statt der bequemen.

Betrachten Sie mindestens 30 Tage, damit ein ruhiges Wochenende oder eine geschäftige Woche das Bild nicht verzerrt. Was Sie vor dem Handeln wollen, ist eine Maschine, deren CPU im 95. Perzentil und deren niedrigster verfügbarer Speicher beide bequem unter ihrer bereitgestellten Größe liegen.

Die Right-Sizing-Schleife läuft auf Evidenz: messen, eine engere Auswahl treffen, Beschränkungen prüfen, neu dimensionieren, dann überprüfen und festhalten.

Die Empfehlungen von Azure Advisor lesen

Sobald Sie ein Gefühl für die Auslastung haben, lassen Sie Azure Advisor die schwere Mustererkennung übernehmen. Suchen Sie unter Advisor und dann der Registerkarte Cost nach Right-size or shutdown underutilised virtual machines. Advisor nutzt Machine-Learning-Modelle über Ihre Nutzung, um für jeden Kandidaten eine Neudimensionierung oder ein Herunterfahren vorzuschlagen, und zeigt für eine Neudimensionierung die aktuelle und die Zielgröße.

Es hilft, auf hoher Ebene zu wissen, wie diese abgeleitet werden, damit Sie ihnen vertrauen können, ohne sie als in Stein gemeißelt zu behandeln:

• Empfehlungen zum Herunterfahren kennzeichnen Maschinen, die über das Rückblickfenster effektiv ungenutzt sind. Die Kriterien nutzen die CPU- und die ausgehende Netzwerkauslastung, nicht den Speicher, und ein Herunterfahren wird zum Beispiel vorgeschlagen, wenn das 95. Perzentil der maximalen, über die Kerne summierten CPU unter 3 Prozent und das ausgehende Netzwerk unter 2 Prozent bleibt.
• Empfehlungen zur Neudimensionierung können SKU-Familie und -Version überschreiten und berücksichtigen Beschränkungen wie die Frage, ob das Ziel Accelerated Networking und Premium Storage unterstützt, ob es in der Region verfügbar ist und ob die Maschine in einer Verfügbarkeitsgruppe liegt.
• Der Rückblickzeitraum beträgt standardmäßig sieben Tage, lässt sich aber auf 7, 14, 21, 30, 60 oder 90 Tage konfigurieren, und eine Änderung kann bis zu 48 Stunden brauchen, bis sie durchläuft. Sie können außerdem filtern, welche Maschinen erscheinen, indem Sie unter Configuration und dann der Registerkarte VM/VMSS right sizing einen durchschnittlichen CPU-Schwellenwert festlegen (Rechte als Abonnementbesitzer, bis zu 24 Stunden bis zur Anwendung), was ändert, was Sie sehen, nicht, wie Empfehlungen erzeugt werden.

Zwei ehrliche Vorbehalte. Die Einsparungszahlen von Advisor nutzen Einzelhandelspreise und ignorieren etwaige Reservierungs- oder Savings-Plan-Rabatte, die Sie halten, sodass die Überschriftszahl höher ausfallen kann, als Sie realisieren werden. Und die angezeigte volle mögliche Jahreseinsparung gilt für das Herunterfahren oder Entfernen einer Maschine; eine Neudimensionierung spart in der Regel echtes Geld, aber nicht diesen vollen Betrag. Behandeln Sie die Empfehlungen als eine stark belegte engere Auswahl, nicht als ein Versprechen.

Die Ziel-SKU wählen

Der Vorschlag von Advisor ist ein Ausgangspunkt, nicht die einzige Option. Wenn Sie eine Zielgröße wählen, wägen Sie einige Dinge gemeinsam ab.

• Passung der Familie. Die allzweckfähige D-Serie eignet sich für ausgewogene Workloads, die speicheroptimierte E-Serie für Datenbanken und Caches, die compute-optimierte F-Serie für CPU-gebundene Arbeit und die burstfähige B-Serie für Workloads mit niedrigem Durchschnitt und Spitzen. Innerhalb der richtigen Familie nach unten zu wechseln ist sauberer, als über Familien hinwegzuspringen.
• Größen mit beschränkten Kernen. Wo die Lizenzierung pro Kern der eigentliche Kostentreiber ist, behalten Größen mit beschränkter vCPU-Anzahl den Speicher, den Storage und die Bandbreite einer größeren SKU, während sie die abrechenbare Kernzahl reduzieren.
• Verfügbarkeit in der Region. Eine Größe, die in einer Region angeboten wird, existiert in einer anderen möglicherweise nicht, bestätigen Sie also, dass das Ziel dort verfügbar ist, wo die Maschine lebt.
• Festplatten- und Netzwerkbeschränkungen. Die maximale Anzahl an Datenfestplatten, IOPS, Durchsatz und Netzwerkschnittstellen ist alles an die Größe gebunden. Zu weit nach unten zu gehen kann eine Maschine drosseln, die nie CPU-gebunden war, prüfen Sie also die Beschränkungen des Ziels gegen das, was die Workload anbindet und treibt.

Lassen Sie Puffer. Das Ziel ist eine Größe, die die Last im 95. Perzentil bequem abdeckt, nicht eine, die am ersten geschäftigen Nachmittag heißläuft.

Die Neudimensionierung durchführen, und mit einem Neustart rechnen

Die Neudimensionierung geht schnell, ist aber störend, planen Sie sie also entsprechend. Das Ändern der Größe einer laufenden virtuellen Maschine bewirkt einen Neustart, der am besten außerhalb der Spitzenzeiten erfolgt. Ist die Zielgröße auf dem Hardwarecluster, der die Maschine derzeit hostet, nicht verfügbar, müssen Sie sie zuerst deallozieren, was die Maschine stoppt, jede dynamische öffentliche IP-Adresse freigibt und die temporäre Festplatte leeren kann; die Betriebssystem- und Datenfestplatten bleiben unberührt.

Es gibt drei gängige Wege, es zu tun:

• Portal. Öffnen Sie die Maschine, gehen Sie zu Availability + scale und dann Size, wählen Sie aus der verfügbaren Liste und wählen Sie Resize.
• Azure CLI. Listen Sie die Clusteroptionen mit az vm list-vm-resize-options auf und führen Sie dann az vm resize --size <NewSize> aus. Ist die Größe nicht gelistet, zuerst az vm deallocate, neu dimensionieren, dann az vm start.
• PowerShell. Listen Sie die Optionen mit Get-AzVMSize auf, setzen Sie $vm.HardwareProfile.VmSize und wenden Sie es dann mit Update-AzVM an.

Liegt die Maschine in einer Verfügbarkeitsgruppe und die neue Größe befindet sich nicht auf dem aktuellen Cluster, müssen Sie unter Umständen zuerst jede Maschine in der Gruppe deallozieren. Planen Sie es und informieren Sie den Workload-Eigentümer vorher, nicht nachher.

Die Änderung überprüfen und die Einsparung festhalten

Eine Neudimensionierung ist nicht abgeschlossen, wenn die Maschine neu startet. Prüfen Sie in den folgenden Tagen dieselben CPU-Auslastungs- und Verfügbarspeicher-Metriken aus Azure Monitor erneut, um zu bestätigen, dass die kleinere Größe unter realer Last mit intaktem Puffer standhält. Läuft sie heiß, gehen Sie einen Schritt zurück nach oben; das ist Teil der Schleife, kein Fehler.

Halten Sie dann die Evidenz fest. Notieren Sie die Größe vorher und nachher sowie die monatliche Kostenbewegung und behalten Sie den Advisor-Kostenexport (Advisor-Registerkarte Cost, Download als CSV) als Baseline. Dieser Vorher-nachher-Datensatz verwandelt eine technische Änderung in eine belegbare Einsparung, wenn die Finanzabteilung oder ein Eigentümer fragt, was sich geändert hat.

Machen Sie es zu einem Rhythmus, nicht zu einer Einmalaktion

Größendrift ist kontinuierlich, ein einzelner Durchgang reicht also nicht. Nutzungsmuster verschieben sich und Workloads ziehen um, sodass die gestern richtige Entscheidung zur Überdimensionierung des nächsten Quartals wird. Setzen Sie Right-Sizing auf eine monatliche oder vierteljährliche Überprüfung, damit die Umgebung weiter die beobachtete Auslastung nachverfolgt statt eine Schätzung vom Tag der Bereitstellung. Es steht neben dem umfassenderen Beseitigen von Verschwendung; für Ressourcen, die abrechnen und dabei wenig oder nichts leisten, sehen Sie, wie ungenutzte Azure-Ressourcen zu Design-Schulden auf der Rechnung werden.

Wo EtherInsights ansetzt

Diese Schleife von Hand über eine Handvoll Maschinen zu betreiben, ist machbar. Über eine wachsende Umgebung hinweg, oder über viele Kunden für einen Managed-Service-Provider, wird sie schnell zu einer Aufgabe für sich, und genau hier verdient sich EtherInsights seinen Platz. Es macht überdimensionierte und wenig genutzte virtuelle Maschinen aus Auslastungsnachweisen sichtbar, rahmt jede als eine von Eigentümern getragene Maßnahme statt als eine rohe Metrik und verfolgt das Vorher und Nachher, sodass eine Neudimensionierung auf Nachweisen ruht statt auf einem Bauchgefühl.

Dieser Evidenz-zuerst-Ansatz ist der ganze Sinn unseres Dienstes Azure VM Right-Sizing, der Auslastungsdaten in Neudimensionierungsmaßnahmen verwandelt, die Ihr Team bewerten und verantworten kann, mit den Zahlen, die sie stützen. Compute ist nur eine Position auf der Rechnung, sodass das Zusammenführen von Right-Sizing mit der Arbeit an Lizenzen, Speicher und ungenutzten Ressourcen unter einem einzigen Programm zur Cloud-Kostenoptimierung die Umgebung für die Arbeit zahlen lässt, die sie tatsächlich leistet, nicht für die Form, die ihr zuerst gegeben wurde.

Right-Sizing ist keine einmalige Bereinigung und keine grobe Kostenkürzung. Es ist eine disziplinierte, evidenzgeführte Schleife: messen, eine engere Auswahl treffen, die Beschränkungen prüfen, mit Sorgfalt neu dimensionieren, dann überprüfen und festhalten. Betreiben Sie es in einem Rhythmus, und Azure Compute passt sich weiter der realen Nachfrage an statt einer Annahme, die längst abgelaufen ist.

Azure VM Right-Sizing entdecken, um zu sehen, wie Auslastungsnachweise zu von Eigentümern getragenen Neudimensionierungsmaßnahmen mit den Belegen werden, die sie stützen.