In diesem Artikel werden bewährte Methoden zum Erstellen auf virtuellen Azure Spot-Computern beschrieben. Es enthält ein bereitstellungsfähiges Beispielszenario. Spot virtual machines (spot VMs) bieten Zugriff auf die Computekapazität zu niedrigeren Preisen als normale virtuelle Computer. Dieser Rabatt macht sie zu einer guten Option für Organisationen, die Kosten optimieren möchten. Aber die Einsparungen kommen mit einem Kompromiss. Spot-VMs können jederzeit aussortiert werden, was bedeutet, dass sie den Zugriff auf Computeressourcen verlieren. 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. In den folgenden Empfehlungen wird beschrieben, wie VMs vor Ort erstellt werden.
Grundlegendes zu Spot-VMs
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 hauptunterschied zwischen Spot-VMs und regulären VMs ist ihre Priorität und Verfügbarkeit. Spot-VMs haben keine Priorität für den Zugriff auf die Computekapazität, und sie haben keine Verfügbarkeitsgarantien, nachdem sie auf diese Computekapazität zugreifen.
Kein Prioritätszugriff. Normale virtuelle Computer haben Prioritätszugriff auf die Computekapazität. Sie greifen auf die Computekapazität zu, wenn sie sie anfordern. Stellen Sie jedoch fest, dass VMs nur bereitgestellt werden, wenn es eine zusätzliche Computekapazität gibt. Und sie werden nur ausgeführt, wenn eine normale VM die zugrunde liegende Hardware nicht benötigt.
Keine Verfügbarkeitsgarantie. Spot-VMs verfügen nicht über Verfügbarkeitsgarantien oder Vereinbarungen auf Servicelevel (SLAs). Spot-VMs können den Zugriff auf die Computekapazität sofort oder jederzeit nach der Bereitstellung oder Entfernung verlieren. Spot-VMs sind billiger, da sie weggeräumt werden können. Wenn Azure die Computekapazität zurück benötigt, wird eine Eviction-Benachrichtigung gesendet und die Spot-VM ausgeräumt. Azure stellt mindestens 30 Sekunden voraus, bevor die tatsächliche Vertreibung erfolgt. Weitere Informationen finden Sie unter Fortlaufende Überwachung auf Eviction.
Grundlegendes zu Spot-VM-Preisen
Spot-VMs können bis zu 90% günstiger sein als normale VMs für Die Bezahlung. Der Rabatt variiert je nach Bedarf, VM-Größe, Bereitstellungsregion und Betriebssystem. Um eine Kosteneinsparungenschätzung zu erhalten, lesen Sie Azure Spot Virtual Machines-Preistool und Übersicht über die Preise virtueller Computer spot virtual machines. Sie können auch die Azure-Einzelhandelspreise-API abfragen, um programmgesteuert die Spotpreise für jede SKU abzurufen.
Grundlegendes zu unterbrechungsfähigen Arbeitsauslastungen
Spot-VMs eignen sich ideal für unterbrechungsfähige Workloads, die mehrere gemeinsame Merkmale aufweisen. Unterbrechungsfähige Arbeitslasten 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- und kontinuierlichen Bereitstellungs-Agent für eine Nichtproduktumgebung erstellen. Diese Features vergleichen sich mit regulären oder unternehmenskritischen Workloads, die SLAs, Haftsitzungen und zustandsbehaftete Daten enthalten.
Sie können Spot-VMs in nicht unterbrechbaren Workloads verwenden, sie sollten jedoch 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 nach der Erstellung keine SLAs, und sie können jederzeit den Zugriff auf die Berechnung verlieren. Wir nennen diesen Berechnungsverlust als Eviction. Berechnen von Versorgungs- und Nachfrageantrieben. 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. Beispielsweise wirkt sich eine Zunahme der Nachfrage in Region A nicht auf 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 of the spot VM. Sie legen diese Konfigurationen fest, wenn Sie die Spot-VM erstellen. Der Eviction-Typ definiert die Bedingungen einer Eviction. Die Eviction-Richtlinie bestimmt, was die Eviction für Ihre Spot-VM tut.
Eviction-Typ
Kapazitätsänderungen oder Preisänderungen führen zu Vertreibungen. Die Art und Weise, wie Kapazitäts- und Preisänderungen sich auf Spot-VMs auswirken, hängt vom Eviction-Typ ab, den Sie beim Erstellen der VM auswählen. Der Typ der Eviction definiert die Bedingungen einer Vertreibung. Die Eviction-Typen sind Nur-Kapazitäts-Eviction und Preis- oder Kapazitätsräumung.
Nur-Kapazitäts-Eviction: Dieser Eviction-Typ löst eine Auslösung aus, wenn nicht mehr überzählige Rechenkapazität verfügbar ist. Standardmäßig wird der Preis mit dem Pay-as-You-Go-Satz gedeckelt. Verwenden Sie diesen Eviction-Typ, wenn Sie nicht mehr bezahlen möchten als der pay-as-you-go VM-Preis.
Preis- oder Kapazitätsräumung: Dieser Eviction-Typ hat zwei Auslöser. Azure entfernt einen spot-virtuellen Computer, wenn keine übermäßig hohe Computekapazität mehr verfügbar ist oder die Kosten der VM den von Ihnen festgelegten Höchstpreis überschreiten. Dieser Eviction-Typ ermöglicht es Ihnen, einen maximalen Preis weit unter dem pay-as-you-go-Preis festzulegen. Verwenden Sie diesen Eviction-Typ, um Ihre eigene Preisobergrenze festzulegen.
Eviction-Richtlinie
Die Eviction-Richtlinie, die Sie für eine Spot-VM auswählen, wirkt sich auf die Orchestrierung aus. Die Orchestrierung ist der Prozess der Behandlung einer Vertreibung und wird später in diesem Artikel erläutert. Die Löschrichtlinien sind die Stop/Deallocate policy und die Delete policy.
Stop/Deallocate-Richtlinie: Die Stop/Deallocate-Richtlinie ist ideal, 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. Der virtuelle Computer verliert die Computekapazität und nicht statische IP-Adressen mit der Stop/Deallocate-Richtlinie. Die VM-Datenträger 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 oder deallocated werden. Weitere Informationen finden Sie unter Power states and billing.
Richtlinie "Löschen": Verwenden Sie die Richtlinie "Löschen", wenn die Workload die Größe des Speicherorts oder der VM ändern kann. Wenn Sie den Speicherort oder die VM-Größe ändern, 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 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. Flexibilität bedeutet, ihre Orchestrierung so zu gestalten, dass Sie Optionen haben, mehrere VM-Größen verwenden, in verschiedenen Regionen bereitstellen, Eviction-Bewusstsein haben 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 vor Ort ausgeführt wird, ist die Computekapazität von entscheidender Bedeutung. Stellen Sie aufgrund des Potenzials für die Entfernung sicher, dass Sie die zugeordnete Berechnungszeit verstehen, damit Sie fundierte Entwurfsentscheidungen treffen können, die die Arbeitsauslastungsgeschwindigkeit priorisieren. Im Allgemeinen sollten Sie die berechnete Zeit optimieren, die Sie haben. Erstellen Sie ein VM-Image, das alle erforderlichen Software vorinstalliert hat. Vorinstallierte Software trägt dazu bei, die Zeit zwischen Deräumung und einer vollständig betriebsbereiten Anwendung zu minimieren. Vermeiden Sie die Verwendung von Berechnungszeit für Prozesse, die nicht zum Arbeitsauslastungszweck beitragen. Beispielsweise sollte sich eine Arbeitsauslastung für datenanalysen die meiste Rechenzeit auf die Datenverarbeitung und so wenig Zeit wie möglich auf das Sammeln von Entfernungsmetadaten konzentrieren. Beseitigen Sie nicht wesentliche Prozesse aus Ihrer Anwendung.
Verwenden mehrerer VM-Größen und Speicherorte
Um die Flexibilität zu erhöhen, erstellen Sie eine Orchestrierung, um mehrere Typen und Größen von VMs zu verwenden. Das Ziel ist es, Ihren Orchestrierungsoptionen zu geben, um eine geräumte VM zu ersetzen. Azure verfügt über unterschiedliche Typen und Größen von VMs, die ähnliche Funktionen für ungefähr denselben Preis bieten. Filtern Sie nach den minimalen vCPUs oder Kernen, dem minimalen RAM für VMs und dem maximalen Preis. Dieser Prozess hilft Ihnen, mehrere virtuelle Computer zu finden, die in Ihr Budget passen und genügend Energie haben, um Ihre Workload auszuführen.
Jeder VM-Typ verfügt über eine Entfernungsrate, die als Prozentsatzbereich ausgedrückt wird, z. B. 0%-5%, 5%-10%, 10%-15%, 15%-20%oder 20+%. Die Eviction-Raten können in verschiedenen Regionen variieren. Möglicherweise finden Sie eine bessere Entfernungsrate für denselben Virtuellen Computertyp in einer anderen Region. Sie finden die Entfernungsraten für jeden Virtuellen Computertyp im Portal unter der Registerkarte Grundlagen. Wählen Sie neben GrößePreisverlauf anzeigen oder Alle Größenanzeigen. Mithilfe von Azure Resource Graph können Sie auch spot-VM-Daten programmgesteuert abrufen.
Berücksichtigen Sie in Ihrem Orchestrierungssystem die Verwendung der Spotplatzierungsbewertungsfunktion, um die Wahrscheinlichkeit des Erfolgs für einzelne Spotbereitstellungen zu bewerten.
Weitere Informationen finden Sie in den folgenden Ressourcen:
Verwenden der flexibelsten Eviction-Richtlinie
Die Vertreibungsrichtlinie der ausgesetzten Spot-VM wirkt sich auf den Ersetzungsprozess aus. Beispielsweise ist eine Löschrichtlinie flexibler als eine Stop/Deallocate-Richtlinie.
Erwägen Sie zuerst die Löschrichtlinie: Verwenden einer Löschrichtlinie, 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 oder abgeglichene VM zu finden. Beendete oder abgeglichene VMs müssen warten, bis in derselben Zone, in der sie erstellt wurden, auf die Noch-Computekapazität gewartet wird. Für die Löschrichtlinie benötigen Sie einen externen Prozess, um Lösch- und Orchestrierungsbereitstellungen für verschiedene Regionen zu überwachen, unterschiedliche VM-SKUs oder beides zu verwenden.
Verstehen der Stop/Deallocate-Richtlinie: Die Richtlinie "Stop/Deallocate" hat weniger Flexibilität als die Delete-Richtlinie. Die Spot-VMs müssen sich in derselben Region und Zone befinden. Sie können einen angehaltenen oder abgeglichenen virtuellen Computer 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.
| Politik | Wann die Richtlinie verwendet werden soll |
|---|---|
| Richtlinie löschen | - Ephemerale Berechnung und Daten - Möchten Sie nicht für Datenträger bezahlen - Minimales Budget |
| Stop/Deallocate policy | – Benötigen Sie eine bestimmte VM-Größe. - Speicherort kann nicht geändert werden - Langer Anwendungsinstallationsprozess - Unbestimmte Wartezeit - Nicht allein durch Kosteneinsparungen gesteuert |
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. Wenn Sie diese Informationen haben, können Sie versuchen, eine Workload ordnungsgemäß herunterzufahren und die Automatisierung auszulösen, um den Ersatz zu koordinieren.
Geplante Ereignisse verwenden: Verwenden des Diensts "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
PreemptSignal mindestens 30 Sekunden an alle virtuellen Computer, bevor sie ausgeräumt werden. Mit dem Dienst "Geplante Ereignisse" können Sie diesesPreemptSignal erfassen, indem Sie einen Endpunkt an der statischen, nicht routingfähigen IP-Adresse169.254.169.254abfragen.Häufig verwendete Abfragen verwenden: Abfrage des Endpunkts "Geplante Ereignisse" häufig genug, um ein ordnungsgemäßes Herunterfahren zu koordinieren. Sie können den Endpunkt "Geplante Ereignisse" bis zu jeder Sekunde abfragen, eine 1-Sekunden-Häufigkeit ist jedoch für alle Anwendungsfälle möglicherweise nicht erforderlich. Diese Abfragen müssen aus 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
PreemptSignal gesammelt haben, sollte Ihre Orchestrierung auf dieses Signal reagieren. Angesichts der Zeitlichen Einschränkungen sollte dasPreemptSignal versuchen, ein ordnungsgemäßes Herunterfahren Ihrer Workload zu versuchen und einen automatisierten Prozess zu starten, der die spot-VM ersetzt. Weitere Informationen finden Sie in den folgenden Ressourcen:
Erstellen eines Bereitstellungssystems
Ihre Orchestrierung benötigt eine automatisierte Pipeline, um neue Spot-VMs nach der Entfernung bereitzustellen. Die Pipeline sollte außerhalb der unterbrechungsfähigen Workload ausgeführt werden, um die Sicherheit zu gewährleisten. Die Bereitstellungspipeline sollte gemäß der Eviction-Richtlinie funktionieren, die Sie für Ihre VMs vor Ort auswählen.
Für eine Löschrichtlinie empfehlen wir, eine Pipeline zu erstellen, die unterschiedliche VM-Größen verwendet und in verschiedenen Regionen bereitgestellt wird. Für eine Stop/Deallocate-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 Möglichkeit, ein Bereitstellungssystem zu automatisieren. 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 räumt, sobald Sie ihn erstellen und bevor Ihre Workload ausgeführt wird. In einigen Fällen gibt es möglicherweise genügend Kapazität, um eine spot-VM zu erstellen, aber sie wird nicht zuletzt verwendet. Spot-VMs haben nach der Erstellung keine Verfügbarkeitsgarantien oder 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 nicht von den geplanten Ereignissen Preempt Signal abhängen. Nur der virtuelle Computer selbst kann das Preempt-Signal abfragen, und es ist nicht genug Zeit, eine Anwendung zu starten, den Endpunkt für geplante Ereignisse 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 den virtuellen Spotcomputer zu ersetzen, wenn sich der Status in deallocating ändert oder beenden.
Planen mehrerer gleichzeitiger Entfernungen
Wenn Sie einen Cluster von Spot-VMs ausführen, entwerfen Sie die Arbeitsauslastung so, dass sie mehreren gleichzeitigen Vertreibungen standhält. Mehrere Spot-VMs in der Workload können gleichzeitig aussortiert werden. Eine gleichzeitige Entfernung mehrerer VMs kann sich auf den Durchsatz der Anwendung auswirken. Um diese Situation zu verhindern, 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
Der Prozess zum Herunterfahren des virtuellen Computers sollte weniger als 30 Sekunden betragen und es Ihrer VM ermöglichen, vor einer Auslassung herunterzufahren. 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 Herunterfahrenvorgang dauern. Der Herunterfahrensprozess sollte Ressourcen freigeben, Verbindungen entwässern und Ereignisprotokolle leeren. Sie sollten regelmäßig Prüfpunkte erstellen und speichern, um den Kontext beizubehalten 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 die neue VM die Änderungen wiederherstellen und den gesamten Prozess erneut starten soll. Speichern Sie die Prüfpunkte außerhalb der Spot-VM-Umgebung, z. B. in einem Speicherkonto.
Testen der Orchestrierung
Simulieren sie Eviction-Ereignisse zum Testen der Orchestrierung in Entwicklungs-/Testumgebungen. Weitere Informationen finden Sie unter Simulieren der Entfernung.
Entwerfen einer idempotenten Arbeitsauslastung
Es wird empfohlen, eine idempotente Workload zu entwerfen. Das Ergebnis der Gleichzeitigkeit der Verarbeitung eines Ereignisses sollte mit der einmaligen Verarbeitung übereinstimmen. Evictions können zu erzwungenen Herunterfahren führen, trotz der Bemühungen, ordnungsgemäß heruntergefahren zu werden. Erzwungene Herunterfahren können Prozesse vor Abschluss beenden. Idempotente Workloads können dieselbe Nachricht mehrmals empfangen, ohne das Ergebnis zu ändern. 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 auch Zeit, um eine Verbindung mit externem Speicher herzustellen und Informationen aus Prüfpunkten zu sammeln. Führen Sie eine Aufwärmphase der Anwendung aus, bevor Sie die Verarbeitung starten können. Während des Warmupzeitraums sollte die Anwendung beginnen, Verbindungen herstellen und sich darauf vorbereiten, mitzuwirken. Nur zulassen, dass eine Anwendung mit der Verarbeitung von Daten beginnt, nachdem Sie die Integrität der Anwendung überprüft haben.
Konfigurieren von vom Benutzer zugewiesenen verwalteten Identitäten
Weisen Sie vom Benutzer zugewiesene verwaltete Identitäten zu, um den Authentifizierungs- und Autorisierungsprozess zu optimieren. Mit vom Benutzer zugewiesenen verwalteten Identitäten vermeiden Sie das Einfügen von Anmeldeinformationen in Code und sind nicht an eine einzelne Ressource gebunden, z. B. vom System zugewiesene verwaltete Identitäten. 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 bei der Optimierung der Orchestrierung und vereinfacht den Zugriff auf Workloadressourcen, über die VMs verfügen.
Wenn Sie vom System zugewiesene verwaltete Identitäten verwenden, 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, stellen Sie die Workloads für 403 Forbidden Error Antworten widerstandsfähig. Ihre Orchestrierung muss Token aus der Microsoft Entra-ID mit den richtigen Berechtigungen abrufen. Weitere Informationen finden Sie unter verwaltete Identitäten.
Beispielszenario
Im Beispielszenario wird eine Anwendung für die Warteschlangenverarbeitung bereitgestellt, die als unterbrechungsfähige Arbeitsauslastung qualifiziert ist. Die Skripts im Szenario dienen als Beispiele. Das Szenario führt Sie durch einen einmaligen manuellen Push, um Ressourcen bereitzustellen. Diese Implementierung verfügt nicht über eine Bereitstellungspipeline. Eine Bereitstellungspipeline ist jedoch unerlässlich, um den Orchestrierungsprozess zu automatisieren. Das folgende Diagramm zeigt die Architektur des Beispielszenarios.
Eine Visio-Datei dieser Architektur herunterladen.
Der folgende Workflow entspricht dem vorherigen Diagramm:
VM-Anwendungsdefinition: Die VM-Anwendungsdefinition wird im Azure-Computekatalog erstellt. Er definiert den Anwendungsnamen, den Speicherort, das Betriebssystem und die Metadaten. Die Anwendungsversion ist eine nummerierte Version der VM-Anwendungsdefinition. Die Anwendungsversion stellt die VM-Anwendung dar. Er muss sich in derselben Region befinden wie die Spot-VM. Die Anwendungsversion verweist auf das Quellanwendungspaket im Speicherkonto.
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 dasorchestrate.shBash-Skripts, das die .NET-Workeranwendung installiert.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.gznach der Bereitstellung auf den virtuellen Computer herunter. Die Bicep-Vorlage stellt ein Ubuntu-Image auf einem virtuellen Standardcomputer der Familie bereit. Diese Konfigurationen erfüllen die Anforderungen dieser Anwendung und sind keine allgemeinen Empfehlungen für Ihre Anwendungen.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 im Azure Queue Storage mit einer vom Benutzer zugewiesenen Identität mithilfe der rollenbasierten Zugriffssteuerung.
.NET-Workeranwendung: Das skript
orchestrate.shinstalliert eine .NET-Workeranwendung, die zwei Hintergrunddienste ausführt. Der erste Dienst fragt den Endpunkt "Geplante Ereignisse" ab, sucht nach demPreempt-Signal und sendet dieses Signal an den zweiten Dienst. Der zweite Dienst verarbeitet Nachrichten aus der Speicherwarteschlange und lauscht auf dasPreemptSignal vom ersten Dienst. Wenn der zweite Dienst das Signal empfängt, unterbricht er die Verarbeitung der Speicherwarteschlange und beginnt mit dem Herunterfahren.Endpunkt für geplante Ereignisse der Abfrage: Eine API-Anforderung wird an eine statische, nicht routingfähige IP-Adresse
169.254.169.254gesendet. Die API-Anforderung fragt den Endpunkt "Geplante Ereignisse" nach Wartungssignalen für die Infrastruktur ab.Application Insights: Die Architektur verwendet Application Insights nur zu Lernzwecken. Es ist keine wesentliche Komponente der unterbrechungsfähigen Workload-Orchestrierung, ermöglicht ihnen jedoch die Überprüfung der Telemetrie aus der .NET-Workeranwendung. Die .NET-Workeranwendung sendet Telemetrie an Application Insights. Weitere Informationen finden Sie unter Aktivieren von Livemetriken aus der .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.