So erstellen Sie Workloads auf virtuellen Spotcomputern

In diesem Artikel erläutern wir die bewährten Methoden für die Erstellung auf virtuellen Azure-Computern (VMs) und enthalten ein bereitstellungsfähiges Beispielszenario. Spot-VMs bieten Zugriff auf die Berechnungskapazität bei erheblichen Rabatten auf normale virtuelle Computer. Dieser Rabatt macht sie zu einer attraktiven Lösung für Organisationen, die kostenoptimieren möchten, aber die Einsparungen sind mit einer Bedingung verbunden. Spot-VMs können jederzeit den Zugriff auf die Berechnung verlieren. Wir nennen diesen Prozess als Einweisung. Workloads, die vor Ort ausgeführt werden, müssen in der Lage sein, diese Unterbrechungen bei der Berechnung zu verarbeiten. Die richtige Arbeitsauslastung und ein flexibler Orchestrierungsmechanismus sind die Schlüssel zum Erfolg. Hier finden Sie unsere Empfehlungen für die Erstellung von VMs vor Ort.

Grundlegendes zu virtuellen Spotcomputern

Auf technischer Ebene sind Spot-VMs identisch mit normalen VMs. Sie verwenden dieselben Images, Hardware und Datenträger, die in die gleiche Leistung übersetzt werden. Der Unterschied zwischen Spot- und regulären VMs kommt auf Priorität und Verfügbarkeit zurück. Spot-VMs haben keine Priorität für den Zugriff auf die Computekapazität, und sie haben keine Verfügbarkeitsgarantien nach dem Zugriff auf diese Computekapazität. Lassen Sie uns die Priorität und Verfügbarkeit ausführlicher besprechen.

Kein Prioritätszugriff. Normale virtuelle Computer haben Prioritätszugriff auf die Computekapazität. Sie greifen immer dann auf die Computekapazität zu, wenn sie sie anfordern. Spot-VMs hingegen nur bereitstellen, wenn es eine ersatzmäßige Computekapazität gibt und sie nur ausgeführt werden, wenn eine normale VM die zugrunde liegende Hardware nicht benötigt.

Keine Verfügbarkeitsgarantie. Spot-VMs haben keine Verfügbarkeitsgarantien. Sie haben keine Vereinbarungen zum Servicelevel (SLAs). Spot-VMs können den Zugriff auf die Computekapazität sofort oder jederzeit nach der Bereitstellung (Eviction) verlieren. Spot-VMs sind aufgrund der Vertreibungsmöglichkeit billiger. Wann immer Azure die Computekapazität zurück benötigt, wird ein Eviction-Hinweis gesendet und die Spot-VM ausgeräumt. Azure stellt mindestens 30 Sekunden voraus, bevor die tatsächliche Eviction stattfindet. Weitere Informationen finden Sie unter kontinuierlicher Überwachung der Entfernung in diesem Artikel.

Grundlegendes zu Spotpreisen für virtuelle Computer

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

• Azure Spot VM-Preistool
• übersicht über Spot VM-Preise

Sie können auch die Azure-Einzelhandelspreise-API abfragen, um programmgesteuert die Spotpreise für eine beliebige SKU von Interesse zu erhalten.

Grundlegendes zu unterbrechungsfähigen Arbeitsauslastungen

Unterbrechungsfähige Workloads sind der beste Anwendungsfall für Spot-VMs. Unterbrechungsfähige Workloads weisen einige häufige Merkmale auf. Sie haben nur minimale Zeiteinschränkungen, geringe Organisationspriorität und kurze Verarbeitungszeiten. Sie führen Prozesse aus, die plötzlich beendet und fortgesetzt werden können, ohne wesentliche Organisationsprozesse zu beeinträchtigen. Beispiele für unterbrechungsfähige Workloads sind Batchverarbeitungsanwendungen, Datenanalysen und Workloads, die einen kontinuierlichen Integrations-kontinuierlichen Bereitstellungs-Agent für eine Nicht-Produktionsumgebung erstellen. Diese Features stehen im Gegensatz zu regulären oder unternehmenskritischen Workloads mit Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs), Kurzsitzungen und zustandsbehafteten Daten. Die Tabelle enthält Beispiele für beide Workloadtypen.

Sie können Spot-VM in nicht unterbrechbaren Workloads verwenden, aber sie sollten nicht die einzige Quelle der Computekapazität sein. Verwenden Sie so viele normale VMs, wie Sie ihre Uptime-Anforderungen erfüllen müssen.

Verstehen der Vertreibung

Spot-VMs haben keine Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs), nachdem sie erstellt wurden, und können jederzeit den Zugriff auf die Berechnung verlieren. Wir nennen diesen Berechnungsverlust als Eviction. Compute supply and demand drives eviction. Wenn die Nachfrage nach einer bestimmten VM-Größe eine bestimmte Ebene überschreitet, werden virtuelle Computer von Azure entfernt, um die Berechnung für normale virtuelle Computer verfügbar zu machen. Die Nachfrage ist standortspezifisch. Eine Zunahme der Nachfrage in Region A wirkt sich nicht auf Spot-VMs in Region B aus.

Spot-VMs verfügen über zwei Konfigurationsoptionen, die sich auf die Entfernung auswirken. Diese Konfigurationen sind der "eviction type" und "eviction policy" der Spot-VM. Sie legen diese Konfigurationen fest, wenn Sie die Spot-VM erstellen. Der "Eviction-Typ" definiert die Bedingungen einer Eviction. Die "Eviction Policy" bestimmt, was die Eviction für Ihre Spot-VM tut. Lassen Sie uns beide Konfigurationsoptionen behandeln.

Eviction-Typ

Kapazitätsänderungen oder Preisänderungen führen zu Vertreibungen. Die Art und Weise, in der sich Kapazitäts- und Preisänderungen auf Spot-VMs auswirken, hängt vom Eviction-Typ ab, der beim Erstellen der VM ausgewählt wurde. Der Eviction-Typ definiert die Bedingungen einer Eviction. Die Eviction-Typen sind "nur Eviction" und "Preis oder Kapazität Eviction".The eviction types are "capacity only eviction" and "price or capacity eviction".

Kapazität nur Eviction: Dieser Eviction-Typ löst eine Auslösung aus, wenn übermäßige Rechenkapazität verschwindet. Standardmäßig wird der Preis mit dem Pay-as-You-Go-Satz gedeckelt. Verwenden Sie diesen Eviction-Typ, wenn Sie bereit sind, bis zum Pay-as-you-go-VM-Preis zu bezahlen.

Preis- oder Kapazitätsräumung: Dieser Eviction-Typ hat zwei Auslöser. Azure entfernt eine Spot-VM, wenn übermäßige Computekapazität verschwindet oder die Kosten der VM den von Ihnen festgelegten maximalen Preis überschreiten. Dieser Eviction-Typ ermöglicht es Ihnen, einen höchstpreis deutlich unter dem pay-as-you-go-Preis festzulegen. Verwenden Sie diesen Eviction-Typ, um Ihre eigene Preisobergrenze festzulegen.

Eviction-Richtlinie

Die für einen Spot-VM gewählte Eviction-Richtlinie wirkt sich auf die Orchestrierung aus. Durch die Orchestrierung meinen wir den Prozess des Umgangs mit einer Vertreibung. Später behandeln wir die Orchestrierung ausführlich. Die Löschrichtlinien sind die "Stop/Deallocate policy" und "Delete policy".

Stop/Deallocate Policy: Die Richtlinie "Stop/Deallocate eviction" ist am besten geeignet, wenn die Workload auf die Freigabekapazität innerhalb desselben Standorts und vm-Typs warten kann. Die Stop/Deallocate-Richtlinie stoppt den virtuellen Computer und beendet seine Lease mit der zugrunde liegenden Hardware. Das Beenden und Behandeln einer Spot-VM ist identisch mit dem Beenden und Behandeln einer normalen VM. Auf den virtuellen Computer kann in Azure zugegriffen werden, und Sie können denselben virtuellen Computer später neu starten. Mit der Stop/Deallocate-Richtlinie verliert der virtuelle Computer die Computekapazität und nicht statische IP-Adressen. Die DATENTRÄGER der VM-Daten bleiben jedoch erhalten und verursachen weiterhin Gebühren. Der virtuelle Computer belegt auch Kerne im Abonnement. VMs können nicht aus ihrer Region oder Zone verschoben werden, auch wenn sie angehalten/deallocated sind. Weitere Informationen finden Sie unter Vm Power States und Abrechnung.

Richtlinie löschen: Verwenden Sie die "Richtlinie löschen", wenn die Workload den Standort oder die VM-Größe ändern kann. Durch ändern der Standort- und/oder VM-Größe kann der virtuelle Computer schneller erneut bereitgestellt werden. Die Delete-Richtlinie löscht den virtuellen Computer und einen beliebigen Datenträger. Der virtuelle Computer belegt keine Kerne in Abonnements. Weitere Informationen zu Dentreibungsrichtlinien finden Sie unter Eviction Policy.

Design für flexible Orchestrierung

Die Orchestrierung ist der Prozess des Ersetzens einer Spot-VM nach einer Vertreibung. Es ist die Grundlage für die Erstellung einer zuverlässig unterbrechungsfähigen Arbeitsauslastung. Ein gutes Orchestrierungssystem verfügt über integrierte Flexibilität. Durch Flexibilität bedeuten wir, dass Sie Ihre Orchestrierung so gestalten, dass Sie Optionen haben, mehrere VM-Größen verwenden, in verschiedenen Regionen bereitstellen, Eviction beachten und unterschiedliche Eviction-Szenarien berücksichtigen, um die Zuverlässigkeit und Geschwindigkeit der Arbeitsauslastung zu verbessern.

Design für Geschwindigkeit

Für eine Workload, die auf VMs vor Ort ausgeführt wird, ist die Rechenkapazität ein Schatz. Das bevorstehende Potenzial für Dieräumung sollte Ihre Wertschätzung für die berechnete Zeit erhöhen und in sinnvolle Entwurfsentscheidungen übersetzt werden, die die Arbeitsauslastungsgeschwindigkeit priorisieren. Im Allgemeinen sollten Sie die Rechenzeit optimieren, die Sie haben. Sie sollten ein VM-Image mit allen erforderlichen vorinstallierten Software erstellen. Vorinstallierte Software trägt dazu bei, die Zeit zwischen Zwängung und einer vollständig ausgeführten Anwendung zu minimieren. Sie möchten die Berechnungszeit für Prozesse vermeiden, die nicht zu Arbeitsauslastungszwecken beitragen. Eine Arbeitsauslastung für Datenanalysen sollte sich beispielsweise auf die Berechnungszeit der Datenverarbeitung und so wenig wie möglich auf das Sammeln von Entfernungsmetadaten konzentrieren. Beseitigen Sie nicht wesentliche Prozesse aus Ihrer Anwendung.

Verwenden mehrerer VM-Größen und Speicherorte

Es wird empfohlen, eine Orchestrierung zu erstellen, um mehrere VM-Typen und -Größen zu verwenden, um die Flexibilität zu erhöhen. Das Ziel ist es, Ihren Orchestrierungsoptionen zu geben, um eine geräumte VM zu ersetzen. Azure verfügt über unterschiedliche VM-Typen und Größen, die ähnliche Funktionen für ungefähr denselben Preis bieten. Sie sollten VMs min vCPUs/Cores und/oder min RAM und max. Preis filtern, um mehrere virtuelle Computer zu finden, die über die Leistung verfügen, um Ihre Workload auszuführen und in Ihr Budget zu passen.

Jeder VM-Typ verfügt über eine Entfernungsrate, die als Prozentsatzbereich ausgedrückt wird (0-5%, 5-10%, 10-15%, 15-20%, 20 +%). Die Vertreibungsraten können in verschiedenen Regionen variieren. Möglicherweise finden Sie eine bessere Entfernungsrate für denselben VM-Typ in einer anderen Region. Sie finden die Entfernungsraten für jeden VM-Typ im Portal unter der Registerkarte "Grundlagen". Wählen Sie die Links "Größe" aus ("Preisverlauf anzeigen" oder "Alle Größen anzeigen"). Sie können auch programmgesteuert virtuelle Spotdaten mithilfe von Azure Resource Graph abrufen.

Darüber hinaus sollten Sie die Spotplatzierungsbewertung verwenden, um die Erfolgswahrscheinlichkeit einzelner Spotbereitstellungen im Rahmen Ihres Orchestrierungssystems zu bewerten. Weitere Informationen finden Sie unter:

• Eviction-Raten
• Azure Resource Graph
• Spotplatzierungsbewertung (Vorschau)

Verwenden der flexibelsten Eviction-Richtlinie

Die Vertreibungsrichtlinie der ausgesetzten Spot-VM wirkt sich auf den Ersetzungsprozess aus. Eine Lösch-Löschrichtlinie ist flexibler als eine beendete/deallocated-Eviction-Richtlinie.

Erwägen Sie zuerst die Löschrichtlinie: Es wird empfohlen, eine Löschrichtlinie zu verwenden, wenn Ihre Workload sie verarbeiten kann. Durch das Löschen kann die Orchestrierung Ersatzplatz-VMs in neuen Zonen und Regionen bereitstellen. Diese Flexibilität bei der Bereitstellung könnte Ihrer Workload helfen, die Kapazitätsfreigabe schneller als eine angehaltene/deallocated VM zu finden. Beendete/Deallocated-VMs müssen warten, bis in derselben Zone, in der sie erstellt wurde, auf die Noch-Computekapazität gewartet wurde. Für die Löschrichtlinie benötigen Sie einen Prozess zum Überwachen von Entfernungen, die sich außerhalb der Anwendung befinden, und koordiniert Bereitstellungen in verschiedenen Regionen und/oder mit unterschiedlichen VM-SKUs.

Verstehen der richtlinie "beendet/deallocated": Die Richtlinie für beendete/deallocated hat weniger Flexibilität als die Löschrichtlinie. Die Spot-VMs müssen sich in derselben Region und Zone befinden. Sie können eine angehaltene/deallocated VM nicht an einen anderen Speicherort verschieben. Da die virtuellen Computer über einen festen Speicherort verfügen, benötigen Sie etwas, um den virtuellen Computer neu zu ordnen, wenn die Computekapazität verfügbar wird. Es gibt keine Möglichkeit, die Verfügbarkeit der Computekapazität vorherzusagen. Sie sollten also eine automatisierte Zeitplanpipeline verwenden, um eine erneute Bereitstellung nach einer Entfernung zu versuchen. Eine Auslösung sollte die Zeitplanpipeline auslösen, und die Wiederholungsversuche sollten kontinuierlich auf die Berechnungskapazität prüfen, bis sie verfügbar ist.

Kontinuierliche Überwachung auf Äumung

Die Überwachung ist der Schlüssel zur Arbeitsauslastungszuverlässigkeit vor Ort-VMs. Spot-VMs haben nach der Erstellung keine SLA und können jederzeit ausgelassen werden. Die beste Möglichkeit zur Verbesserung der Arbeitsauslastungszuverlässigkeit vor Ort VMs besteht darin, vorherzusehen, wann sie weggeräumt werden. Mit diesen Informationen können Sie versuchen, eine Workload ordnungsgemäß herunterzufahren und die Automatisierung auszulösen, die den Ersatz koordiniert.

Verwenden von geplanten Ereignissen: Verwenden Sie den Dienst "Geplante Ereignisse" für jeden virtuellen Computer. Azure sendet Signale an VMs, wenn sich die Infrastrukturwartung darauf auswirken wird. Evictions gelten als Infrastrukturwartung. Azure sendet das Preempt Signal mindestens 30 Sekunden an alle virtuellen Computer, bevor sie ausgeräumt werden. Mit einem Dienst namens "Schedule Events" können Sie dieses Preempt Signal erfassen, indem Sie einen Endpunkt an einer statischen, nicht routingfähigen IP-Adresse 169.254.169.254abfragen.

Häufig verwendete Abfragenverwenden: Abfragen des Endpunkts "Ereignisse planen" häufig genug, um ein ordnungsgemäßes Herunterfahren zu koordinieren. Sie können den Endpunkt "Geplante Ereignisse" bis zu jeder Sekunde abfragen, aber für alle Anwendungsfälle ist möglicherweise nicht eine Sekunde erforderlich. Diese Abfragen müssen von einer Anwendung stammen, die vor Ort ausgeführt wird. Die Abfrage kann nicht aus einer externen Quelle stammen. Daher verbrauchen die Abfragen VM-Computekapazität und stehlen die Verarbeitungsleistung von der Hauptarbeitslast. Sie müssen diese konkurrierenden Prioritäten ausgleichen, um Ihre spezifische Situation zu erfüllen.

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, ein ordnungsgemäßes Herunterfahren Ihrer Workload zu versuchen und einen automatisierten Prozess zu starten, der die spot-VM ersetzt. Weitere Informationen finden Sie unter:

• geplante Ereignisse
• Endpunktabfragehäufigkeit

Erstellen eines Bereitstellungssystems

Ihre Orchestrierung benötigt eine automatisierte Pipeline, um neue Spot-VMs bereitzustellen, wenn sie aussortiert werden. Die Pipeline sollte außerhalb der unterbrechungsfähigen Workload selbst ausgeführt werden, um die Sicherheit zu gewährleisten. Die Funktionsweise der Bereitstellungspipeline hängt von der Eviction-Richtlinie ab, die Sie für Ihre VMs vor Ort auswählen.

Für eine Löschrichtlinie wird empfohlen, eine Pipeline zu erstellen, die unterschiedliche VM-Größen verwendet und in verschiedenen Regionen bereitgestellt wird. Für eine Stop/Deallocated-Richtlinie benötigt die Bereitstellungspipeline zwei unterschiedliche Aktionen. Für die anfängliche Erstellung eines virtuellen Computers muss die Pipeline die richtigen VMs an dem richtigen Speicherort bereitstellen. Für einen entfernten virtuellen Computer muss die Pipeline versuchen, den virtuellen Computer neu zu starten, bis er funktioniert. Eine Kombination aus Azure Monitor-Warnungen und Azure-Funktionen ist eine von mehreren Möglichkeiten zum Automatisieren eines Bereitstellungssystems. Die Pipeline könnte Bicep-Vorlagen verwenden. Sie sind deklarativ und idempotent und stellen eine bewährte Methode für die Infrastrukturbereitstellung dar.

Vorbereiten der sofortigen Entfernung

Es ist möglich, dass Azure einen spot-virtuellen Computer wiederherstellen kann, sobald Sie ihn erstellen und bevor Ihre Workload ausgeführt wird. Nur weil es Kapazität zum Erstellen einer Spot-VM gab, bedeutet dies nicht, dass sie weiterhin besteht. Spot-VMs haben nach der Erstellung keine Verfügbarkeitsgarantien (SLAs). Ihre Orchestrierung muss sofortige Vertreibungen berücksichtigen. Das Preempt Signal stellt mindestens 30 Sekunden voraus eine Benachrichtigung über die Vertreibung bereit.

Integrieren Sie VM-Integritätsprüfungen in Ihre Orchestrierung, um sich auf sofortige Entfernungen vorzubereiten. Die Orchestrierung für sofortige Zwänge kann sich nicht auf das Signal "Terminplanereignisse" Preempt verlassen. Nur der virtuelle Computer selbst kann das Preempt-Signal abfragen, und es ist nicht genug Zeit, eine Anwendung zu starten, den Endpunkt "Terminplanungsereignisse" abzufragen und ordnungsgemäß herunterzufahren. Daher muss sich die Integritätsprüfung außerhalb der Workloadumgebung befinden. Die Integritätsprüfungen müssen den Status der Spot-VM überwachen und die Bereitstellungspipeline starten, um die Spot-VM zu ersetzen, wenn sich der Status ändert, um die Zuordnung zu behandeln oder zu beenden.

Planen mehrerer gleichzeitiger Entfernungen

Wenn Sie einen Cluster von Spot-VMs ausführen, sollten Sie die Workload so entwerfen, dass sie mehreren gleichzeitigen Vertreibungen standhält. Mehrere Spot-VMs in der Arbeitsauslastung können gleichzeitig aussortiert 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 virtuellen Computern zu sammeln und mehrere Ersatz-VMs gleichzeitig bereitzustellen.

Entwerfen eines ordnungsgemäßen Herunterfahrens

Die Prozesse zum Herunterfahren des virtuellen Computers sollten weniger als 30 Sekunden betragen und ihrem virtuellen Computer das Herunterfahren vor einer Auslassung ermöglichen. Die Dauer des Herunterfahrens hängt davon ab, wie häufig Ihre Workload den Endpunkt "Geplante Ereignisse" abfragt. Je häufiger Sie den Endpunkt abfragen, desto länger kann der Herunterfahrenprozess sein. Der Herunterfahrensprozess sollte Ressourcen freigeben, Verbindungen entwässern und Ereignisprotokolle leeren. Sie sollten regelmäßig Prüfpunkte erstellen und speichern, um den Kontext zu speichern und eine effizientere Wiederherstellungsstrategie zu erstellen. Der Prüfpunkt ist nur Informationen darüber, welche Prozesse oder Transaktionen der nächste virtuelle Computer starten muss. Sie sollten angeben, ob der virtuelle Computer fortgesetzt werden soll, wo der vorherige virtuelle Computer aufgehört hat oder ob der neue virtuelle Computer die Änderungen zurücksetzen und den gesamten Prozess erneut starten soll. Sie sollten die Prüfpunkte außerhalb der Spot-VM-Umgebung speichern. Ein Speicherkonto würde funktionieren.

Testen der Orchestrierung

Es wird empfohlen, Eviction-Ereignisse zum Testen der Orchestrierung in Entwicklungs-/Testumgebungen zu simulieren. Weitere Informationen finden Sie unter simulieren Eviction.

Entwerfen einer idempotenten Arbeitsauslastung

Es wird empfohlen, eine idempotente Workload zu entwerfen. Das Ergebnis der Verarbeitung eines Ereignisses sollte mehrmals mit der Verarbeitung übereinstimmen. Evictions können trotz der Bemühungen zu erzwungenen Herunterfahren führen, um ein ordnungsgemäßes Herunterfahren zu gewährleisten. Erzwungene Herunterfahren können Prozesse vor Abschluss beenden. Idempotente Workloads können dieselbe Nachricht mehrmals empfangen, und das Ergebnis bleibt gleich. Weitere Informationen finden Sie unter idempotency.

Verwenden eines Aufwärmezeitraums der Anwendung

Die meisten unterbrechungsfähigen Workloads führen Anwendungen aus. Anwendungen benötigen Zeit zum Installieren und Starten. Sie benötigen Zeit, um eine Verbindung mit externem Speicher herzustellen und Informationen aus Prüfpunkten zu sammeln. Es wird empfohlen, eine Anwendung warmup-Periode zu haben, bevor sie die Verarbeitung starten kann. Während des Warmupzeitraums sollte die Anwendung gestartet, verbunden und vorbereitet werden, um beiträge zu leisten. Sie sollten einer Anwendung nur erlauben, die Verarbeitung von Daten zu starten, nachdem Sie die Integrität der Anwendung überprüft haben.

Konfigurieren von vom Benutzer zugewiesenen verwalteten Identitäten

Wir empfehlen die Verwendung von vom Benutzer zugewiesenen verwalteten Identitäten, um den Authentifizierungs- und Autorisierungsprozess zu optimieren. Durch vom Benutzer zugewiesene verwaltete Identitäten vermeiden Sie das Einfügen von Anmeldeinformationen in Code und sind nicht an eine einzelne Ressource wie vom System zugewiesene verwaltete Identitäten gebunden. Die vom Benutzer zugewiesenen verwalteten Identitäten enthalten Berechtigungen und Zugriffstoken aus der Microsoft Entra-ID, die während der Orchestrierung wiederverwendet und zugewiesen werden können. Die Tokenkonsistenz über Spot-VMs hinweg hilft, die Orchestrierung und den Zugriff auf Arbeitsauslastungsressourcen zu optimieren, über die VMs verfügen.

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

Beispielszenario

Im Beispielszenario wird eine Anwendung für die Warteschlangenverarbeitung bereitgestellt, die als unterbrechungsfähige Arbeitsauslastung qualifiziert ist. Die Skripts im Szenario sind illustrativ. Das Szenario führt Sie durch einen einmaligen manuellen Push, um Ressourcen bereitzustellen. Es gibt keine Bereitstellungspipeline mit dieser Implementierung. Eine Bereitstellungspipeline ist jedoch unerlässlich, um den Orchestrierungsprozess zu automatisieren. Das Diagramm veranschaulicht die Architektur des Beispielszenarios.

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

1. VM-Anwendungsdefinition: Die VM-Anwendungsdefinition wird im Azure Compute Gallery erstellt. Er definiert den Anwendungsnamen, den Speicherort, das Betriebssystem und die Metadaten. Die Anwendungsversion ist eine nummerierte Version der VM-Anwendungsdefinition. Die Anwendungsversion ist eine Instanziierung der VM-Anwendung. Er muss sich in derselben Region befinden wie die Spot-VM. Die Anwendungsversion verweist auf das Quellanwendungspaket im Speicherkonto.
2. Speicherkonto: Das Speicherkonto speichert das Quellanwendungspaket. In dieser Architektur handelt es sich um eine komprimierte Tar-Datei mit dem Namen worker-0.1.0.tar.gz. Sie enthält zwei Dateien. Eine Datei ist das orchestrate.sh Bash-Skripts, das die .NET-Workeranwendung installiert.
3. Spot-VM: Die Spot-VM wird bereitgestellt. Er muss sich in derselben Region wie die Anwendungsversion befinden. Sie lädt worker-0.1.0.tar.gz nach der Bereitstellung auf den virtuellen Computer herunter. Die Bicep-Vorlage stellt ein Ubuntu-Image auf einer Standardfamilie-VM bereit. Diese Konfigurationen erfüllen die Anforderungen dieser Anwendung und sind keine allgemeinen Empfehlungen für Ihre Anwendungen.
4. Speicherwarteschlange: Der andere Dienst, der im .NET-Worker ausgeführt wird, enthält nachrichtenwarteschlangenlogik. Die Microsoft Entra-ID gewährt der Spot-VM Zugriff auf die Speicherwarteschlange mit einer benutzer zugewiesenen Identität mithilfe von RBAC.
5. .Net-Workeranwendung: Das skript orchestrate.sh installiert eine .NET-Workeranwendung, die zwei Hintergrunddienste ausführt. Der erste Dienst fragt den Endpunkt "Zeitplanereignisse" ab und 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 vom ersten Dienst. Wenn der zweite Dienst das Signal empfängt, unterbricht er die Verarbeitung der Speicherwarteschlange und beginnt mit dem Herunterfahren.
6. Endpunkt für geplante Abfrageereignisse: Eine API-Anforderung wird an eine statische, nicht routingfähige IP-Adresse 169.254.169.254 gesendet. Die API-Anforderung fragt den Endpunkt "Geplantes Ereignis" nach Wartungssignalen für die Infrastruktur ab.
7. Application Insights: Die Architektur verwendet Application Insights nur zu Lernzwecken. Es ist keine wesentliche Komponente der unterbrechungsfähigen Workload-Orchestrierung. Es ist eine Möglichkeit, die Telemetrie aus der .NET-Workeranwendung zu überprüfen. Die .NET-Workeranwendung sendet Telemetrie an Application Insights. Weitere Informationen finden Sie unter Aktivieren von Livemetriken aus .NET-Anwendung.

Bereitstellen dieses Szenarios

Es gibt ein GitHub-Repository namens unterbrechungsfähige Workload vor Ort mit Vorlagen, Skripts und schrittweisen Anleitungen zur Bereitstellung dieser Architektur.

Nächster Schritt

Weitere Informationen zu virtuellen Spotcomputern finden Sie unter virtuellen Azure Spot-Computer.

Verwandte Ressourcen

• Architekturansätze für Kostenmanagement und Zuordnung in einer multiinstanzenübergreifenden Lösung
• Ausführen einer Windows-VM auf Azure
• Ausführen einer Linux-VM auf Azure