Erstellen von Workloads auf Spot-VMs

In diesem Artikel werden die bewährten Methoden für die Erstellung auf virtuellen Azure-Spot-Computern (VMs) beschrieben und ein bereitstellbares Beispielszenario einbezogen. Spot-VMs bieten Zugriff auf Computekapazitäten mit erheblichen Rabatten gegenüber regulären virtuellen Computern. Dieser Rabatt macht sie zu einer attraktiven Lösung für Organisationen, die Kosten optimieren möchten, aber die Einsparungen sind mit einer Bedingung verbunden. Spot-VMs können jederzeit den Zugriff auf die Compute-Instanz verlieren. Dieser Vorgang wird als „Entfernung“ bezeichnet. Workloads, die auf Spot-VMs ausgeführt werden, müssen in der Lage sein, diese Unterbrechungen in der Compute-Instanz zu bewältigen. Die richtige Workload und ein flexibler Orchestrierungsmechanismus sind die Schlüssel zum Erfolg. Hier folgen unsere Empfehlungen für das Erstellen von Spot-VMs.

Informationen zu Spot-VMs

Auf technischer Ebene sind Spot-VMs mit normalen VMs identisch. Sie verwenden die gleichen Images, Hardware und Datenträger und bieten somit dieselbe Leistung. Der Unterschied zwischen Spot-VMs und normalen VMs liegt im Bereich der Priorität und Verfügbarkeit. Spot-VMs haben keine Priorität für den Zugriff auf Computekapazität, und sie haben keine Verfügbarkeitsgarantien nach dem Zugriff auf diese Computekapazität. Hier erfahren Sie mehr über die Priorität und Verfügbarkeit.

Kein Zugriff mit erhöhter Priorität. Normale VMs haben Zugriff mit erhöhter Priorität auf Computekapazität. Sie greifen auf Computekapazitäten zu, wann immer sie diese anfordern. Spot-VMs hingegen werden nur bereitgestellt, wenn freie Computekapazitäten vorhanden sind, und sie werden nur ausgeführt, wenn eine reguläre VM die zugrunde liegende Hardware nicht benötigt.

Keine Verfügbarkeitsgarantie: Spot-VMs haben keine Verfügbarkeitsgarantien. Es bestehen keine Vereinbarungen zum Servicelevel (Service Level Agreement, SLA). Spot-VMs können den Zugriff auf Computekapazitäten sofort oder zu einem beliebigen Zeitpunkt nach der Bereitstellung verlieren (Entfernung). Spot-VMs sind aufgrund der Entfernungsmöglichkeit günstiger. Wenn Azure die Computekapazität wieder benötigt, wird eine Entfernungsbenachrichtigung gesendet, und die Spot-VM wird entfernt. Azure gibt mindestens 30 Sekunden vor der tatsächlichen Entfernung eine Benachrichtigung aus. Weitere Informationen finden Sie unter dem Abschnitt „Kontinuierliche Überwachung auf Entfernungen“ in diesem Artikel.

Preise für Spot-VMs

Spot-VMs können bis zu 90 Prozent günstiger sein als normale VMs (nutzungsbasierte Bezahlung). Der Rabatt variiert je nach Bedarf, VM-Größe, Bereitstellungsregion und Betriebssystem. Es wird empfohlen, das Spot-VM-Preistool von Azure zu verwenden, um eine Schätzung der Kosteneinsparungen zu erhalten. Weitere Informationen finden Sie unter

• Azure-Preistool für Spot-VMs
• Übersicht über Spot-VM-Preise

Sie können auch die API für Azure-Einzelhandelspreise abfragen, um die Spot-Preise für jede interessante SKU programmgesteuert abzurufen.

Grundlegende Informationen zu unterbrechbaren Workloads

Unterbrechbare Workloads sind der beste Anwendungsfall für Spot-VMs. Sie weisen einige gemeinsame Merkmale auf. Zudem weisen unterbrechbare Workloads minimale bis keine Zeiteinschränkungen, eine niedrige Organisationspriorität und kurze Verarbeitungszeiten auf. Sie führen Prozesse aus, die plötzlich beendet und später fortgesetzt werden können, ohne wesentliche Organisationsprozesse zu beeinträchtigen. Beispiele für unterbrechbare Workloads sind Batchverarbeitungsanwendungen, Datenanalysen und Workloads, die einen CI/CD-Agent (Continuous Integration/Continuous Deployment) für eine Nicht-Produktionsumgebung erstellen. Diese Features stehen im Gegensatz zu normalen oder unternehmenskritischen Workloads mit Vereinbarungen zum Servicelevel (SLAs), persistenten Sitzungen und zustandsbehafteten Daten. Die Tabelle enthält Beispiele für beide Workloadtypen.

Sie können Spot-VM bei nicht unterbrechbaren Workloads verwenden, aber sie sollten nicht die einzige Quelle für Computekapazität sein. Verwenden Sie so viele normale VMs, wie Sie benötigen, um Ihre Uptimeanforderungen zu erfüllen.

Grundlegendes zur Entfernung

Spot-VMs verfügen nach der Erstellung über keine Vereinbarungen zum Servicelevel (SLAs) und können jederzeit die Zugriffsberechtigung auf die Compute-Instanz verlieren. Wir bezeichnen diesen Computeverlust als „Entfernung“. Compute-Angebot und -Nachfrage steuern die Entfernung. Wenn die Nachfrage nach einer bestimmten VM-Größe ein bestimmtes Niveau überschreitet, entfernt Azure entsprechende Spot-VMs, um Compute für reguläre VMs bereitzustellen. Die Nachfrage ist standortspezifisch. Ein Anstieg der Nachfrage in Region A hat keine Auswirkungen auf Spot-VMs in Region B.

Spot-VMs verfügen über zwei Konfigurationsoptionen, die sich auf die Entfernung auswirken. Diese Konfigurationen sind der „Entfernungstyp“ und die „Entfernungsrichtlinie“ der Spot-VM. Sie legen diese Konfigurationen fest, wenn Sie die Spot-VM erstellen. Der Entfernungstyp definiert die Bedingungen einer Entfernung. Die „Entfernungsrichtlinie“ bestimmt, was bei einer Entfernung mit Ihrer Spot-VM geschieht. Lassen Sie uns auf beide Konfigurationsmöglichkeiten eingehen.

Entfernungstyp

Die Entfernung wird durch Kapazitätsänderungen oder Preisänderungen verursacht. Wie sich diese auf Spot-VMs auswirken, hängt vom Entfernungstyp ab, der beim Erstellen des virtuellen Computers ausgewählt wurde. Der Entfernungstyp definiert die Bedingungen einer Entfernung. Die Entfernungstypen lauten „Nur Kapazitätsentfernung“ und „Preis- oder Kapazitätsentfernung“.

Nur Kapazitätsentfernung: Dieser Entfernungstyp löst eine Entfernung aus, wenn überschüssige Computekapazität verschwindet. Der Preis ist standardmäßig durch die Rate für nutzungsbasierte Bezahlung gedeckelt. Verwenden Sie diesen Entfernungstyp, wenn Sie bereit sind, den Preis für die nutzungsbasierte Bezahlung für VMs zu zahlen.

Preis- oder Kapazitätsentfernung: Dieser Entfernungstyp hat zwei Trigger. Azure entfernt eine Spot-VM, wenn die überschüssige Computekapazität verschwindet oder die Kosten für den virtuellen Computer den von Ihnen festgelegten Höchstpreis überschreiten. Bei diesem Entfernungstyp können Sie einen Höchstpreis festlegen, der deutlich unter dem Preis der nutzungsbasierten Bezahlung liegt. Verwenden Sie diesen Entfernungstyp, um Ihre eigene Preisobergrenze festzulegen.

Entfernungsrichtlinie

Die für eine Spot-VM ausgewählte Entfernungsrichtlinie wirkt sich auf die Orchestrierung aus. Mit Orchestrierung ist der Vorgang der Verarbeitung einer Entfernung gemeint. Die Orchestrierung wird später ausführlich erläutert. Die Entfernungsrichtlinien lauten „Beenden/Zuordnung aufheben“ und „Löschen“.

Richtlinie „Beenden/Zuordnung aufheben“: Die Entfernungsrichtlinie zum Beenden bzw. Aufheben der Zuordnung ist am besten geeignet, wenn die Workload auf freigegebene Kapazität an demselben Ort und mit demselben VM-Typ warten kann. Die Richtlinie „Beenden/Zuordnung aufheben“ beendet die VM und die Leasedauer für die zugrunde liegende Hardware. Das Beenden und Aufheben der Zuordnung einer Spot-VM entspricht dem Beenden und Aufheben der Zuordnung eines normalen virtuellen Computers. Auf den virtuellen Computer kann in Azure weiterhin zugegriffen werden, und Sie können denselben virtuellen Computer später neu starten. Durch die Richtlinie „Beenden/Zuordnung aufheben“ verliert die VM Computekapazität und nicht statische IP-Adressen. Die VM-Datenträger bleiben jedoch erhalten, und es fallen weiterhin Gebühren an. Der virtuelle Computer belegt auch Kerne im Abonnement. VMs können nicht aus ihrer Region oder Zone verschoben werden, auch wenn sie beendet werden bzw. die Zuordnung aufgehoben wird. Weitere Informationen finden Sie unter Betriebszustand und Abrechnung.

Richtlinie „Löschen“: Verwenden Sie die Richtlinie „Löschen“, wenn die Workload den Ort oder die VM-Größe ändern kann. Durch das Ändern des Orts und/oder der VM-Größe kann die VM schneller erneut bereitgestellt werden. Die Richtlinie „Löschen“ löscht den virtuellen Computer und alle Datenträger. Die VM beansprucht keine Kerne in Abonnements. Weitere Informationen zu Entfernungsrichtlinien finden Sie unter Entfernungsrichtlinie.

Berücksichtigen der flexiblen Orchestrierung

Orchestrierung ist der Vorgang, bei dem eine Spot-VM nach einer Entfernung ersetzt wird. Dies ist die Grundlage für die Erstellung einer zuverlässig unterbrechbaren Workload. Ein gutes Orchestrierungssystem bietet integrierte Flexibilität. Mit Flexibilität ist ein Orchestrierungsentwurf gemeint, der verschiedene Optionen bietet, die Verwendung mehrerer VM-Größen und die Bereitstellung in verschiedenen Regionen ermöglicht, ein Bewusstsein für die Entfernung von Spot-VMs schafft und verschiedene Entfernungsszenarios berücksichtigt, um die Zuverlässigkeit und Geschwindigkeit der Workload zu verbessern.

Im Folgenden finden Sie Empfehlungen, die Ihnen beim Entwerfen einer flexiblen Orchestrierung für Ihre unterbrechbare Workload helfen.

Berücksichtigen der Geschwindigkeit

Für eine Workload, die auf Spot-VMs ausgeführt wird, ist Computekapazität von essenzieller Bedeutung. Das unmittelbare Entfernungspotenzial sollte die Wertschätzung für die zugewiesene Computezeit erhöhen und zu sinnvollen Entwurfsentscheidungen führen, bei denen die Workloadgeschwindigkeit priorisiert wird. Im Allgemeinen empfiehlt es sich, die Ihnen zur Verfügung stehende Computezeit zu optimieren. Sie sollten ein VM-Image erstellen, in dem die gesamte erforderliche Software vorinstalliert ist. Vorinstallierte Software trägt dazu bei, die Zeit zwischen der Entfernung und einer vollständig ausgeführten Anwendung zu minimieren. Es soll vermieden werden, Computezeit für Vorgänge zu verwenden, die nicht dem Workloadzweck dienen. Bei einer Workload für die Datenanalyse sollte beispielsweise möglichst viel Computezeit für die Datenverarbeitung und möglichst wenig für das Sammeln von Entfernungsmetadaten genutzt werden. Entfernen Sie nicht wesentliche Prozesse aus Ihrer Anwendung.

Verwenden mehrerer VM-Größen und Orte

Es wird empfohlen, eine Orchestrierung zu erstellen, um mehrere VM-Typen und -Größen zu verwenden und somit die Flexibilität zu erhöhen. Das Ziel besteht darin, das Ersetzen einer entfernten VM im Rahmen Ihrer Orchestrierung zu ermöglichen. Azure verfügt über unterschiedliche VM-Typen und -Größen, die ähnliche Funktionen für etwa den gleichen Preis bieten. Sie sollten nach VMs mit minimaler vCPU/Kern und/oder minimalem RAM sowie dem Höchstpreis filtern, um mehrere VMs zu ermitteln, die über die Leistungsfähigkeit zum Ausführen Ihrer Workload verfügen und Ihrem Budget entsprechen. Jeder VM-Typ verfügt über eine Entfernungsrate, ausgedrückt als Prozentsatzbereich (0–5 %, 5–10 %, 10–15 %, 15–20 %, 20+ %). Die Entfernungsraten können je nach Region variieren. Möglicherweise finden Sie eine bessere Entfernungsrate für denselben VM-Typ in einer anderen Region. Die Entfernungsraten für jeden VM-Typ finden Sie im Portal unter der Registerkarte „Grundeinstellungen“. Klicken Sie auf die Links für „Größe“ („Preisverlauf anzeigen“ oder „Alle Größen anzeigen“). Sie können mithilfe von Azure Resource Graph auch programmgesteuert Spot-VM-Daten abrufen. Weitere Informationen finden Sie unter

• Entfernungsraten
• Azure Resource Graph

Verwenden der flexibelsten Entfernungsrichtlinie

Die Entfernungsrichtlinie der entfernten Spot-VM wirkt sich auf den Ersetzungsprozess aus. Eine Entfernungsrichtlinie zum Löschen ist flexibler als eine Entfernungsrichtlinie zum Beenden bzw. Aufheben der Zuordnung.

Erwägen der Verwendung einer Richtlinie zum Löschen: Es wird empfohlen, eine Entfernungsrichtlinie zum Löschen zu verwenden, wenn Ihre Workload dies verarbeiten kann. Durch das Löschen kann die Orchestrierung Ersatz-Spot-VMs in neuen Zonen und Regionen bereitstellen. Diese Bereitstellungsflexibilität kann Ihrer Workload helfen, freie Computekapazität schneller zu finden als eine beendete VM bzw. eine VM, deren Zuordnung aufgehoben wurde. Letztere müssen auf freie Computekapazität in der Zone warten, in der sie erstellt wurden. Für die Löschrichtlinie benötigen Sie einen Prozess zur Überwachung von Entfernungen, der außerhalb der Anwendung liegt und die Bereitstellung in verschiedenen Regionen und/oder mit verschiedenen VM-SKUs orchestriert.

Verstehen der Richtlinie zum Beenden bzw. Aufheben der Zuordnung: Die Richtlinie zum Beenden bzw. Aufheben der Zuordnung bietet weniger Flexibilität als die Richtlinie zum Löschen. Die Spot-VMs müssen in derselben Region und Zone verbleiben. Sie können eine beendete VM bzw. eine VM, deren Zuordnung aufgehoben wurde, nicht an einen anderen Ort verschieben. Da die virtuellen Computer über einen festen Ort verfügen, benötigen Sie etwas, um den virtuellen Computer neu zuzuordnen, sobald Computekapazität verfügbar wird. Es gibt keine Möglichkeit, vorherzusagen, wann Computekapazität verfügbar sein wird. Daher wird die Verwendung einer automatisierten Zeitplanpipeline empfohlen, um nach einer Entfernung den Versuch einer erneuten Bereitstellung zu starten. Eine Entfernung sollte die Zeitplanpipeline auslösen, und im Zuge der Neubereitstellungsversuche sollte kontinuierlich überprüft werden, ob Computekapazität verfügbar ist, bis dies schließlich der Fall ist.

Kontinuierliche Überwachung auf Entfernungen:

Überwachung ist der Schlüssel zu Workloadzuverlässigkeit auf Spot-VMs. Spot-VMs verfügen nach der Erstellung über keine SLA und können jederzeit entfernt werden. Die beste Möglichkeit zur Verbesserung der Workloadzuverlässigkeit auf Spot-VMs besteht darin, vorherzusagen, wann sie entfernt werden. Mit diesen Informationen können Sie versuchen, die Workload ordnungsgemäß zu beenden und eine Automatisierung auszulösen, die den Austausch orchestriert.

Verwenden von „Scheduled Events“: Es wird empfohlen, für jede VM den Dienst „Scheduled Events“ zu verwenden. Azure sendet Signale an VMs, wenn diese von der Infrastrukturwartung betroffen sind. Auslagerungen gelten als Infrastrukturwartung. Azure sendet das Preempt-Signal an alle VMs mindestens 30 Sekunden, bevor sie entfernt werden. Mit einem Dienst namens Scheduled Events können Sie dieses Preempt-Signal erfassen, indem Sie einen Endpunkt an einer statischen, nicht routingfähigen IP-Adresse 169.254.169.254abfragen.

Verwenden häufiger Abfragen: Es wird empfohlen, den Scheduled Events-Endpunkt oft genug abzufragen, um ein geordnetes Herunterfahren zu orchestrieren. Sie können den Scheduled Events-Endpunkt sogar sekündlich abfragen, aber diese hohe Frequenz ist möglicherweise nicht für alle Anwendungsfälle erforderlich. Diese Abfragen müssen von einer Anwendung stammen, die auf der Spot-VM ausgeführt wird. Die Abfrage darf nicht von einer externen Quelle stammen. Daher verbrauchen die Abfragen die VM-Computekapazität und die Verarbeitungsleistung der Hauptworkload. Sie müssen diese konkurrierenden Prioritäten ausbalancieren, um Ihrer spezifischen Situation gerecht zu werden.

Automatisieren der Orchestrierung: Nachdem Sie das Preempt-Signal erfasst haben, sollte Ihre Orchestrierung auf dieses Signal reagieren. Angesichts der zeitlichen Einschränkungen sollte das Preempt-Signal versuchen, Ihre Workload ordnungsgemäß zu beenden und einen automatisierten Prozess zu starten, mit dem die Spot-VM ersetzt wird. Weitere Informationen finden Sie unter

• Geplante Ereignisse
• Scheduled Event-Typen
• Endpunktabfragehäufigkeit

Erstellen eines Bereitstellungssystems

Ihre Orchestrierung benötigt eine automatisierte Pipeline, um im Falle einer Entfernung neue Spot-VMs bereitzustellen. Die Pipeline sollte außerhalb der unterbrechbaren Workload selbst ausgeführt werden, um die Dauerhaftigkeit sicherzustellen. Die Funktionsweise der Bereitstellungspipeline hängt von der Entfernungsrichtlinie ab, die Sie für Ihre Spot-VMs ausgewählt haben.

Für eine Richtlinie zum Löschen wird empfohlen, eine Pipeline zu erstellen, die unterschiedliche VM-Größen verwendet und in verschiedenen Regionen bereitstellt. Für eine Richtlinie zum Beenden bzw. Aufheben der Zuordnung benötigt die Bereitstellungspipeline zwei unterschiedliche Aktionen. Für die anfängliche Erstellung eines virtuellen Computers muss die Pipeline VMs mit der richtigen Größe am richtigen Ort bereitstellen. Bei einem entfernten virtuellen Computer muss die Pipeline versuchen, den virtuellen Computer neu zu starten, bis dieser funktioniert. Eine Kombination aus Azure Monitor-Warnungen und Azure Functions ist eine von mehreren Möglichkeiten, ein Bereitstellungssystem zu automatisieren. Die Pipeline kann Bicep-Vorlagen verwenden. Sie sind deklarativ und idempotent und stellen eine bewährte Methode für die Infrastrukturbereitstellung dar.

Vorbereiten auf sofortige Entfernungen

Es ist möglich, dass für Ihre Spot-VM die Entfernung festgelegt wird, sobald sie erstellt wurde und noch bevor Ihre Workload ausgeführt wird. Nur weil Kapazität zum Erstellen einer Spot-VM vorhanden war, bedeutet dies nicht, dass diese weiterhin vorhanden ist. Spot-VMs verfügen nach der Erstellung über keine Verfügbarkeitsgarantien (SLAs). Ihre Orchestrierung muss sofortige Entfernungen berücksichtigen. Das Preempt-Signal umfasst eine Benachrichtigung, die mindestens 30 Sekunden vor der Entfernung ausgegeben wird.

Es wird empfohlen, VM-Integritätsprüfungen in Ihre Orchestrierung zu integrieren, um sich auf sofortige Entfernungen vorzubereiten. Die Orchestrierung für sofortige Entfernungen kann nicht vom Scheduled Events-Signal Preempt abhängen. Nur der virtuelle Computer selbst kann das Preempt-Signal abfragen, und es bleibt nicht genügend Zeit, um eine Anwendung zu starten, den Scheduled Events-Endpunkt abzufragen und ordnungsgemäß herunterzufahren. Daher muss die Integritätsprüfung außerhalb der Workloadumgebung stattfinden. Die Integritätsprüfungen müssen den Status der Spot-VM überwachen und die Bereitstellungspipeline zum Ersetzen der Spot-VM starten, wenn der Status in „Zuordnung wird aufgehoben“ oder „Wird beendet“ geändert wird.

Einplanen mehrerer gleichzeitiger Entfernungen

Wenn Sie einen Cluster von Spot-VMs ausführen, sollten Sie die Workload so entwerfen, dass mehrere gleichzeitige Entfernungen möglich sind. Mehrere Spot-VMs in der Workload können gleichzeitig entfernt werden. Eine gleichzeitige Entfernung mehrerer VMs kann sich auf den Durchsatz der Anwendung auswirken. Um diese Situation zu vermeiden, sollte Ihre Bereitstellungspipeline in der Lage sein, Signale von mehreren VMs zu sammeln und mehrere Ersatz-VMs gleichzeitig bereitzustellen.

Entwerfen für ordnungsgemäßes Herunterfahren

Die Vorgänge zum Herunterfahren der VM sollten weniger als 30 Sekunden dauern und das Herunterfahren Ihrer VM vor einer Entfernung ermöglichen. Wie lange das Herunterfahren dauern sollte, hängt davon ab, wie häufig Ihre Workload den Scheduled Events-Endpunkt abfragt. Je häufiger Sie den Endpunkt abfragen, desto länger kann der Vorgang zum Herunterfahren dauern. Beim Herunterfahren sollten Ressourcen freigegeben, Verbindungen aufgehoben und Ereignisprotokolle geleert werden. Sie sollten regelmäßig Prüfpunkte erstellen und speichern, um den Kontext zu speichern und eine effizientere Wiederherstellungsstrategie zu ermöglichen. Der Prüfpunkt bietet nur Informationen darüber, welche Prozesse oder Transaktionen die nächste VM starten muss. Er sollte angeben, ob die VM an der Stelle fortgesetzt werden soll, an der die vorherige VM aufgehört hat, oder ob der neue virtuelle Computer ein Rollback für die Änderungen ausführen und den gesamten Prozess erneut starten soll. Sie sollten die Prüfpunkte außerhalb der Spot-VM-Umgebung speichern. Hierfür eignet sich beispielsweise ein Speicherkonto.

Testen der Orchestrierung

Es wird empfohlen, Entfernungsereignisse zu simulieren, um die Orchestrierung in Dev/Test-Umgebungen zu testen. Weitere Informationen finden Sie unter Simulieren einer Entfernung.

Entwerfen einer idempotenten Workload

Es wird empfohlen, eine idempotente Workload zu entwerfen. Das Ergebnis einer mehrmaligen Verarbeitung eines Ereignisses sollte mit dem einer einmaligen Verarbeitung identisch sein. Entfernungen können zu erzwungenem Herunterfahren führen, trotz aller Bemühungen, ein ordnungsgemäßes Herunterfahren sicherzustellen. Bei dem erzwungenen Herunterfahren können Prozesse beendet werden, bevor sie abgeschlossen sind. Idempotente Workloads können dieselbe Meldung mehrmals empfangen, und das Ergebnis bleibt gleich. Weitere Informationen finden Sie unter Idempotenz.

Verwenden einer Aufwärmphase für die Anwendung

Die meisten unterbrechbaren Workloads führen Anwendungen aus. Anwendungen benötigen Zeit für die Installation und Zeit zum Starten. Sie benötigen Zeit, um eine Verbindung mit externen Speichern herzustellen und Informationen von Prüfpunkten zu sammeln. Es wird empfohlen, eine Aufwärmphase für die Anwendung einzurichten, bevor diese mit der Verarbeitung beginnen kann. Während der Aufwärmphase sollte die Anwendung starten, Verbindungen herstellen und weitere Vorgänge vorbereiten. Sie sollten erst zulassen, dass eine Anwendung mit der Verarbeitung von Daten beginnt, nachdem Sie die Integrität der Anwendung überprüft haben.

Konfigurieren benutzerseitig zugewiesener verwalteter Identitäten

Es wird empfohlen, benutzerseitig zugewiesene verwaltete Identitäten zu verwenden, um den Authentifizierungs- und Autorisierungsprozess zu optimieren. Mit benutzerseitig zugewiesenen verwalteten Identitäten kann vermieden werden, Anmeldeinformationen in Code einzufügen, und sie sind nicht wie systemseitig zugewiesene Identitäten an eine einzelne Ressource gebunden. Die benutzerseitig zugewiesenen verwalteten Identitäten enthalten Berechtigungen und Zugriffstoken aus Microsoft Entra ID, die während der Orchestrierung wiederverwendet und Spot-VMs zugewiesen werden können. Tokenkonsistenz bei Spot-VMs trägt dazu bei, die Orchestrierung und den Zugriff auf Workloadressourcen der Spot-VMs zu optimieren.

Bei systemseitig zugewiesenen verwalteten Identitäten erhält eine neue Spot-VM möglicherweise ein anderes Zugriffstoken von Microsoft Entra ID. Wenn Sie systemseitig zugewiesene verwaltete Identitäten verwenden müssen, empfiehlt es sich, die Workloads für 403 Forbidden Error-Antworten resilient zu machen. Ihre Orchestrierung muss Token aus Microsoft Entra ID mit den richtigen Berechtigungen abrufen. Weitere Informationen finden Sie unter Verwaltete Identitäten.

Beispielszenario

Im Beispielszenario wird eine Warteschlangenverarbeitungsanwendung bereitgestellt, die sich als unterbrechbare Workload eignet. Die Skripts im Szenario sind illustrativ. Das Szenario führt Sie durch einen einmaligen, manuellen Push zum Bereitstellen von Ressourcen. Bei dieser Implementierung wurde keine Bereitstellungspipeline bereitgestellt. Eine Bereitstellungspipeline ist jedoch unerlässlich, um den Orchestrierungsprozess zu automatisieren. Das Diagramm veranschaulicht die Architektur des Beispielszenarios.

In den folgenden Hinweisen werden die wichtigsten Aspekte der Architektur erläutert:

1. VM-Anwendungsdefinition: Die VM-Anwendungsdefinition wird in der Azure Compute Gallery erstellt. Sie definiert den Anwendungsnamen, den Ort, das Betriebssystem und die Metadaten. Die Anwendungsversion ist eine nummerierte Version der VM-Anwendungsdefinition. Die Anwendungsversion ist eine Instanziierung der VM-Anwendung. Sie muss sich in derselben Region wie die Spot-VM befinden. Die Anwendungsversion ist mit dem Quellanwendungspaket im Speicherkonto verknüpft.
2. Speicherkonto: Das Speicherkonto speichert das Quellanwendungspaket. In dieser Architektur handelt es sich um eine komprimierte TAR-Datei namens worker-0.1.0.tar.gz. Sie enthält zwei Dateien. Eine der Dateien ist das orchestrate.sh-Bash-Skript, das die .NET-Workeranwendung installiert.
3. Spot-VM: Die Spot-VM stellt Komponenten bereit. Sie muss sich in derselben Region wie die Anwendungsversion befinden. Nach der Bereitstellung lädt sie worker-0.1.0.tar.gz auf die VM herunter. Die Bicep-Vorlage stellt ein Ubuntu-Image auf einer Standard-VM bereit. Diese Konfigurationen erfüllen die Anforderungen dieser Anwendung und sind keine allgemeinen Empfehlungen für Ihre Anwendungen.
4. Storage Queue: Der andere Dienst, der mit der .NET-Workerrolle ausgeführt wird, enthält Nachrichtenwarteschlangenlogik. Microsoft Entra ID gewährt der Spot-VM mithilfe der rollenbasierten Zugriffssteuerung über eine benutzerseitig zugewiesene Identität Zugriff auf die Speicherwarteschlange.
5. .NET-Workeranwendung: Das Skript „orchestrate.sh“ installiert eine .NET-Workeranwendung, die zwei Hintergrunddienste ausführt. Der erste Dienst fragt den Scheduled Events-Endpunkt ab, sucht nach dem Preempt-Signal und sendet dieses Signal an den zweiten Dienst. Der zweite Dienst verarbeitet Nachrichten aus der Speicherwarteschlange und lauscht auf das Preempt-Signal des ersten Diensts. Wenn der zweite Dienst das Signal empfängt, unterbricht er die Speicherwarteschlangenverarbeitung und startet den Vorgang zum Herunterfahren.
6. Abfragen des Scheduled Events-Endpunkts: Eine API-Anforderung wird an eine statische, nicht routingfähige IP-Adresse (169.254.169.254) gesendet. Die API-Anforderung fragt den Scheduled Event-Endpunkt nach Infrastrukturwartungssignalen ab.
7. Application Insights: Die Architektur verwendet Application Insights nur zu Lernzwecken. Hierbei handelt es sich um keine wesentliche Komponente der Orchestrierung für unterbrechbare Workloads. Das Feature wurde als Möglichkeit einbezogen, die Telemetriedaten von der .NET-Workeranwendung zu überprüfen. Die .NET-Workeranwendung wurde so konfiguriert, dass Telemetriedaten an Application Insights gesendet werden. Weitere Informationen finden Sie unter Livemetriken: Überwachen und Diagnostizieren mit einer Wartezeit von einer Sekunde.

Bereitstellen dieses Szenarios

Es wurde ein GitHub-Repository namens Unterbrechbare Workloads auf Spot-VMs mit Vorlagen, Skripts und ausführlichen Anweisungen zum Bereitstellen dieser Architektur erstellt. Weitere technische Details zur Architektur und zum Erstellen von Artefakten finden Sie in diesem Repository.

Nächster Schritt

Weitere Informationen zu Spot Virtual Machines finden Sie unter Verwenden von Azure-Spot-VMs.

Zugehörige Ressourcen

• Architekturansätze für Kostenverwaltung und -zuteilung in mehrinstanzenfähigen Lösungen
• Ausführen eines virtuellen Windows-Computers in Azure
• Ausführen eines virtuellen Linux-Computers in Azure