In dit artikel worden aanbevolen procedures beschreven voor het bouwen op Azure Spot Virtual Machines. Het bevat een voorbeeldscenario dat kan worden geïmplementeerd. Spot-VM's (spot-VM's) bieden toegang tot rekencapaciteit tegen lagere prijzen dan gewone VM's. Deze korting maakt ze een goede optie voor organisaties die kosten willen optimaliseren. Maar de besparingen komen met een compromis. Spot-VM's kunnen op elk gewenst moment worden verwijderd, wat betekent dat ze geen toegang meer hebben tot rekenresources. Workloads die op spot-VM's worden uitgevoerd, moeten deze onderbrekingen in de berekening kunnen afhandelen. De juiste werkbelasting en een flexibel indelingsmechanisme zijn de sleutels voor succes. In de volgende aanbevelingen wordt beschreven hoe u on-premises VM's bouwt.
Spot-VM's begrijpen
Op technisch niveau zijn spot-VM's hetzelfde als gewone VM's. Ze gebruiken dezelfde installatiekopieën, hardware en schijven die vertalen naar dezelfde prestaties. Het belangrijkste verschil tussen spot-VM's en reguliere VM's is hun prioriteit en beschikbaarheid. Spot-VM's hebben geen prioriteit voor toegang tot rekencapaciteit en ze hebben geen beschikbaarheidsgaranties nadat ze toegang hebben tot die rekencapaciteit.
Geen prioriteitstoegang. Normale VM's hebben prioriteitstoegang tot rekencapaciteit. Ze hebben toegang tot de rekencapaciteit wanneer ze deze aanvragen. Spot-VM's worden echter alleen geïmplementeerd wanneer er reserve-rekencapaciteit is. En ze blijven alleen worden uitgevoerd wanneer een gewone VIRTUELE machine de onderliggende hardware niet nodig heeft.
Geen beschikbaarheidsgarantie. Spot-VM's hebben geen beschikbaarheidsgaranties of serviceovereenkomsten (SLA's). Spot-VM's hebben direct geen toegang meer tot de rekencapaciteit, of op elk moment na de implementatie of verwijdering. Spot-VM's zijn goedkoper omdat ze kunnen worden verwijderd. Wanneer Azure de rekencapaciteit terug nodig heeft, wordt er een verwijderingsmelding verzonden en wordt de spot-VM verwijderd. Azure biedt minimaal 30 seconden voordat de daadwerkelijke verwijdering plaatsvindt. Zie continu controleren op verwijderingvoor meer informatie.
Inzicht in prijzen voor spot-VM's
Spot-VM's kunnen maximaal 90% goedkoper zijn dan gewone vm's met betalen per gebruik. De korting varieert op basis van de vraag, vm-grootte, implementatieregio en het besturingssysteem. Zie prijzenprogramma voor Virtuele machines van Azure Spot en prijzenoverzicht van Spot Virtual Machinesvoor een schatting van de kostenbesparingen. U kunt ook een query uitvoeren op de API voor retailprijzen van Azure om programmatisch de spotprijzen voor elke SKU te verkrijgen.
Inzicht in onderbreekbare workloads
Spot-VM's zijn ideaal voor onderbreekbare workloads, die verschillende algemene kenmerken delen. Interruptible-workloads hebben minimale tot geen tijdsbeperkingen, lage organisatieprioriteit en korte verwerkingstijden. Ze voeren processen uit die plotseling kunnen stoppen en later kunnen worden hervat zonder essentiële organisatieprocessen te beschadigen. Voorbeelden van interruptible-workloads zijn toepassingen voor batchverwerking, gegevensanalyse en workloads die een continue integratie- en continue implementatieagent maken voor een niet-productieomgeving. Deze functies zijn vergelijkbaar met normale of bedrijfskritieke workloads met SLA's, plaksessies en stateful gegevens.
U kunt spot-VM's gebruiken in niet-onderbrekende workloads, maar ze mogen niet de enige bron van rekencapaciteit zijn. Gebruik zo veel gewone VM's als u nodig hebt om te voldoen aan uw uptimevereisten.
Meer informatie over verwijdering
Spot-VM's hebben geen SLA's na het maken en ze hebben op elk gewenst moment geen toegang meer tot rekenkracht. We noemen dit rekenverlies een verwijdering. Verwijderingen van vraag- en aanbodstations berekenen. Wanneer de vraag naar een specifieke VM-grootte een specifiek niveau overschrijdt, verwijdert Azure spot-VM's om rekenkracht beschikbaar te maken voor gewone VM's. De vraag is locatiespecifiek. Een toename van de vraag in regio A heeft bijvoorbeeld geen invloed op spot-VM's in regio B.
Spot-VM's hebben twee configuratieopties die van invloed zijn op verwijdering. Deze configuraties zijn het verwijderingstype en verwijderingsbeleid van de spot-VM. U stelt deze configuraties in wanneer u de spot-VM maakt. Het verwijderingstype definieert de voorwaarden van een verwijdering. Het verwijderingsbeleid bepaalt wat verwijdering voor uw spot-VM doet.
Verwijderingstype
Capaciteitswijzigingen of prijswijzigingen veroorzaken verwijderingen. De manier waarop capaciteit en prijswijzigingen van invloed zijn op spot-VM's, is afhankelijk van het verwijderingstype dat u kiest wanneer de virtuele machine wordt gemaakt. Het type verwijdering definieert de voorwaarden van een verwijdering. De verwijderingstypen zijn verwijdering van alleen capaciteit en prijs of verwijdering van capaciteit.
verwijdering alleen capaciteit: Dit verwijderingstype activeert een verwijdering wanneer overtollige rekencapaciteit niet meer beschikbaar is. De prijs wordt standaard beperkt tot het tarief voor betalen per gebruik. Gebruik dit verwijderingstype als u niet meer wilt betalen dan de prijs voor betalen per gebruik- VM.
prijs of capaciteitsverwijdering: Dit verwijderingstype heeft twee triggers. Azure verwijdert een spot-VM wanneer overtollige rekencapaciteit niet meer beschikbaar is of de kosten van de VIRTUELE machine groter zijn dan de maximumprijs die u hebt ingesteld. Met dit verwijderingstype kunt u een maximumprijs instellen die ver onder de prijs betalen per gebruik ligt. Gebruik dit verwijderingstype om uw eigen prijslimiet in te stellen.
Verwijderingsbeleid
Het verwijderingsbeleid dat u voor een spot-VM kiest, is van invloed op de indeling ervan. Indeling is het proces voor het afhandelen van een verwijdering en wordt verderop in dit artikel besproken. Het verwijderingsbeleid is het beleid stoppen/toewijzing ongedaan maken en het Beleid verwijderen.
beleid stoppen/de toewijzing ongedaan maken: Het beleid voor stoppen/ongedaan maken is ideaal wanneer de werkbelasting kan wachten op releasecapaciteit binnen dezelfde locatie en hetzelfde VM-type. Het beleid Stoppen/Toewijzing ongedaan maken stopt de VM en beëindigt de lease met de onderliggende hardware. Het stoppen en ongedaan maken van de toewijzing van een spot-VM is hetzelfde als het stoppen en toewijzen van een gewone VIRTUELE machine. De VIRTUELE machine blijft toegankelijk in Azure en u kunt dezelfde VIRTUELE machine later opnieuw opstarten. De VM verliest rekencapaciteit en niet-statische IP-adressen met het beleid Stoppen/Toewijzing ongedaan maken. De VM-gegevensschijven blijven echter behouden en blijven kosten in rekening brengen. De VM neemt ook kernen in het abonnement in beslag. VM's kunnen niet worden verplaatst vanuit hun regio of zone, zelfs niet wanneer ze worden gestopt of de toewijzing ervan ongedaan wordt gemaakt. Zie Power-statussen en factureringsstatussen en facturerings-voor meer informatie.
Beleid verwijderen: Gebruik het beleid Verwijderen als de werkbelasting de locatie of VM-grootte kan wijzigen. Door de locatie of VM-grootte te wijzigen, kan de VM sneller opnieuw worden geïmplementeerd. Met het beleid Verwijderen worden de virtuele machine en een gegevensschijf verwijderd. De VIRTUELE machine bezet geen kernen in abonnementen. Zie verwijderingsbeleidvoor meer informatie.
Ontwerpen voor flexibele indeling
Indeling is het proces van het vervangen van een spot-VM na een verwijdering. Het is de basis voor het bouwen van een betrouwbare onderbreekbare workload. Een goed indelingssysteem heeft ingebouwde flexibiliteit. Flexibiliteit betekent dat u uw indeling ontwerpt om opties te hebben, meerdere VM-grootten te gebruiken, te implementeren in verschillende regio's, verwijderingsbewustzijn te hebben en rekening te houden met verschillende verwijderingsscenario's om de betrouwbaarheid en snelheid van de werkbelasting te verbeteren.
Ontwerp voor snelheid
Voor een workload die wordt uitgevoerd op spot-VM's, is rekencapaciteit cruciaal. Vanwege het potentieel voor verwijdering moet u ervoor zorgen dat u de toegewezen rekentijd begrijpt, zodat u weloverwogen ontwerpbeslissingen kunt nemen die prioriteit geven aan de werkbelastingsnelheid. Over het algemeen moet u de rekentijd optimaliseren die u hebt. Bouw een VM-installatiekopieën waarop alle vereiste software vooraf is geïnstalleerd. Vooraf geïnstalleerde software helpt de tijd tussen verwijdering en een volledig operationele toepassing te minimaliseren. Vermijd het gebruik van rekentijd voor processen die niet bijdragen aan het doel van de werkbelasting. Een workload voor gegevensanalyse moet bijvoorbeeld de meeste rekentijd richten op gegevensverwerking en zo weinig mogelijk tijd voor het verzamelen van verwijderingsmetagegevens. Elimineren van niet-essentiële processen uit uw toepassing.
Meerdere VM-grootten en -locaties gebruiken
Als u de flexibiliteit wilt vergroten, bouwt u een indeling voor het gebruik van meerdere typen en grootten van VM's. Het doel is om uw indelingsopties te geven om een verwijderde VM te vervangen. Azure heeft verschillende typen en grootten van VM's die vergelijkbare mogelijkheden bieden voor ongeveer dezelfde prijs. Filter op de minimale vCPU's of kernen, het minimale RAM-geheugen voor VM's en de maximumprijs. Dit proces helpt u bij het vinden van meerdere VM's die in uw budget passen en voldoende vermogen hebben om uw workload uit te voeren.
Elk type VM heeft een verwijderingspercentage dat wordt uitgedrukt als een percentagebereik, zoals 0%-5%, 5%-10%, 10%-15%, 15%-20%of 20+%. Verwijderingspercentages kunnen per regio verschillen. Mogelijk vindt u een beter verwijderingspercentage voor hetzelfde type VM in een andere regio. U vindt de verwijderingspercentages voor elk type VIRTUELE machine in de portal op het tabblad Basisinformatie. Selecteer naast GroottePrijsgeschiedenis weergeven of Alle grootten weergeven. U kunt ook programmatisch spot-VM-gegevens ophalen met behulp van Azure Resource Graph.
Overweeg in uw indelingssysteem de functie voor spotplaatsingsscore te gebruiken om de kans op succes voor afzonderlijke spot-implementaties te evalueren.
Zie de volgende bronnen voor meer informatie:
Het meest flexibele verwijderingsbeleid gebruiken
Het verwijderingsbeleid van de verwijderde spot-VM is van invloed op het vervangingsproces. Een verwijderingsbeleid is bijvoorbeeld flexibeler dan een beleid voor stoppen/ongedaan maken.
Overweeg eerst het beleid verwijderen: Een beleid verwijderen gebruiken als uw werkbelasting dit kan verwerken. Door te verwijderen kan de indeling vervangende spot-VM's implementeren in nieuwe zones en regio's. Deze implementatieflexibiliteit kan uw workload helpen bij het sneller vinden van reserve-rekencapaciteit dan een gestopte of niet-toegewezen VM. Gestopte of niet-toegewezen VM's moeten wachten op reserve-rekencapaciteit in dezelfde zone waarin ze zijn gemaakt. Voor het beleid Verwijderen hebt u een extern proces nodig om te controleren op verwijderingen en implementaties te organiseren in verschillende regio's, verschillende VM-SKU's of beide te gebruiken.
Inzicht in het beleid voor stoppen/ongedaan maken: Het beleid stoppen/ongedaan maken heeft minder flexibiliteit dan het beleid Verwijderen. De spot-VM's moeten zich in dezelfde regio en zone bevinden. U kunt een gestopte of niet-toegewezen VM niet verplaatsen naar een andere locatie. Omdat de VM's een vaste locatie hebben, hebt u iets nodig om de VIRTUELE machine opnieuw toe te wijzen wanneer de rekencapaciteit beschikbaar is. Er is geen manier om de beschikbaarheid van rekencapaciteit te voorspellen. U moet dus een geautomatiseerde planningspijplijn gebruiken om na een verwijdering opnieuw te implementeren. Een verwijdering moet de planningspijplijn activeren en de nieuwe implementatiepogingen moeten continu controleren op rekencapaciteit totdat deze beschikbaar is.
| Beleid | Wanneer gebruikt u het beleid? |
|---|---|
| Beleid verwijderen | - Kortstondige rekenkracht en gegevens - Wilt u niet betalen voor gegevensschijven - Minimaal budget |
| Beleid stoppen/de toewijzing ervan ongedaan maken | - Een specifieke VM-grootte nodig - Kan locatie niet wijzigen - Lang installatieproces voor toepassingen - Onbepaalde wachttijd - Niet gedreven door kostenbesparingen alleen |
Continu controleren op verwijdering
Bewaking is de sleutel tot de betrouwbaarheid van workloads op spot-VM's. Spot-VM's hebben geen SLA na het maken en kunnen op elk gewenst moment worden verwijderd. De beste manier om de betrouwbaarheid van workloads op spot-VM's te verbeteren, is te anticiperen wanneer ze worden verwijderd. Als u deze informatie hebt, kunt u proberen een werkbelasting zonder problemen af te sluiten en automatisering te activeren om de vervanging in te delen.
Geplande gebeurtenissen gebruiken: gebruik de service Geplande gebeurtenissen voor elke VIRTUELE machine. Azure verzendt signalen naar VM's wanneer het onderhoud van de infrastructuur van invloed is op deze machines. Verwijderingen komen in aanmerking als infrastructuuronderhoud. Azure verzendt het
Preemptsignaal minimaal 30 seconden naar alle VM's voordat ze worden verwijderd. Met de service Geplande gebeurtenissen kunt u ditPreemptsignaal vastleggen door een query uit te voeren op een eindpunt op het statische, niet-routable IP-adres169.254.169.254.Veelgebruikte query's gebruiken: Query uitvoeren op het eindpunt Geplande gebeurtenissen vaak genoeg om een probleemloos afsluiten in te delen. U kunt maximaal elke seconde een query uitvoeren op het eindpunt Geplande gebeurtenissen, maar een frequentie van één seconde is mogelijk niet nodig voor alle gebruiksscenario's. Deze query's moeten afkomstig zijn van een toepassing die wordt uitgevoerd op de spot-VM. De query kan niet afkomstig zijn van een externe bron. Als gevolg hiervan verbruiken de query's de rekencapaciteit van de VM en stelen ze verwerkingskracht van de hoofdworkload. U moet deze concurrerende prioriteiten in balans brengen om aan uw specifieke situatie te voldoen.
Indeling automatiseren: Nadat u het
Preemptsignaal hebt verzameld, moet uw indeling op dat signaal reageren. Gezien de tijdsbeperkingen moet hetPreemptsignaal proberen om uw workload correct af te sluiten en een geautomatiseerd proces starten dat de spot-VM vervangt. Zie de volgende bronnen voor meer informatie:
Een implementatiesysteem bouwen
Uw indeling heeft een geautomatiseerde pijplijn nodig om nieuwe spot-VM's te implementeren na verwijdering. De pijplijn moet buiten de onderbreekbare werkbelasting worden uitgevoerd om de permanentie te waarborgen. De implementatiepijplijn moet werken volgens het verwijderingsbeleid dat u kiest voor uw spot-VM's.
Voor een verwijderingsbeleid raden we u aan een pijplijn te bouwen die gebruikmaakt van verschillende VM-grootten en implementeert in verschillende regio's. Voor een beleid stoppen/toewijzing ongedaan maken heeft de implementatiepijplijn twee verschillende acties nodig. Voor het maken van een virtuele machine moet de pijplijn de juiste grootte van VM's implementeren op de juiste locatie. Voor een verwijderde VIRTUELE machine moet de pijplijn proberen de VIRTUELE machine opnieuw op te starten totdat deze werkt. Een combinatie van Azure Monitor-waarschuwingen en Azure-functies is een manier om een implementatiesysteem te automatiseren. De pijplijn kan bicep-sjablonen gebruiken. Ze zijn declaratief en idempotent en vormen een best practice voor de implementatie van infrastructuur.
Voorbereiden op onmiddellijke verwijdering
Azure kan een spot-VM verwijderen zodra u deze maakt en voordat uw workload wordt uitgevoerd. In sommige gevallen is er mogelijk voldoende capaciteit om een spot-VM te maken, maar dit duurt niet. Spot-VM's hebben na het maken geen beschikbaarheidsgaranties of SLA's. Uw indeling moet rekening houden met onmiddellijke verwijderingen. Het Preempt signaal biedt minimaal 30 seconden voor de kennisgeving van de verwijdering.
Neem VM-statuscontroles op in uw indeling om u voor te bereiden op onmiddellijke verwijderingen. Indeling voor onmiddellijke verwijderingen kan niet afhankelijk zijn van de geplande gebeurtenissen Preempt signaal. Alleen de VIRTUELE machine zelf kan een query uitvoeren op het Preempt signaal en er is onvoldoende tijd om een toepassing te starten, het eindpunt geplande gebeurtenissen op te vragen en op een juiste manier af te sluiten. De statuscontrole moet dus zich buiten de workloadomgeving bevinden. De statuscontroles moeten de status van de spot-VM controleren en de implementatiepijplijn starten om de spot-VM te vervangen wanneer de status verandert in toewijzing van of stoppen.
Plannen voor meerdere gelijktijdige verwijderingen
Als u een cluster met spot-VM's uitvoert, moet u de workload ontwerpen om meerdere gelijktijdige verwijderingen te weerstaan. Meerdere spot-VM's in de workload kunnen tegelijkertijd worden verwijderd. Een gelijktijdige verwijdering van meerdere VM's kan van invloed zijn op de doorvoer van de toepassing. Om deze situatie te voorkomen, moet uw implementatiepijplijn signalen van meerdere VM's kunnen verzamelen en tegelijkertijd meerdere vervangende VM's kunnen implementeren.
Ontwerpen voor een sierlijk afsluiten
Het proces voor het afsluiten van de VIRTUELE machine moet minder dan 30 seconden duren en ervoor zorgen dat uw VIRTUELE machine wordt afgesloten voordat deze wordt verwijderd. Hoe lang het afsluiten moet duren, is afhankelijk van hoe vaak uw workload het eindpunt Geplande gebeurtenissen opvraagt. Hoe vaker u een query uitvoert op het eindpunt, hoe langer het afsluitproces kan duren. Het afsluitproces moet resources vrijgeven, verbindingen leegmaken en gebeurtenislogboeken leegmaken. U moet regelmatig controlepunten maken en opslaan om de context te behouden en een efficiëntere herstelstrategie te bouwen. Het controlepunt is alleen informatie over welke processen of transacties de volgende VIRTUELE machine moet starten. Ze moeten aangeven of de VM moet hervatten waar de vorige VM was gebleven of als de nieuwe VIRTUELE machine de wijzigingen moet terugdraaien en het hele proces opnieuw moet starten. Sla de controlepunten buiten de spot-VM-omgeving op, zoals in een opslagaccount.
De indeling testen
Simuleer verwijderingsgebeurtenissen om indeling te testen in ontwikkel-/testomgevingen. Zie Verwijdering simulerenvoor meer informatie.
Een idempotente workload ontwerpen
U wordt aangeraden een idempotente workload te ontwerpen. Het resultaat van het verwerken van een gebeurtenis moet meer dan één keer hetzelfde zijn als wanneer deze eenmaal wordt verwerkt. Verwijderingen kunnen leiden tot geforceerde afsluitingen, ondanks de inspanningen om ervoor te zorgen dat het systeem correct wordt afgesloten. Geforceerde afsluitingen kunnen processen vóór voltooiing beëindigen. Idempotent werkbelastingen kunnen hetzelfde bericht meer dan één keer ontvangen zonder het resultaat te wijzigen. Zie Idempotentievoor meer informatie.
Een opwarmperiode voor toepassingen gebruiken
De meeste onderbrekende workloads voeren toepassingen uit. Toepassingen hebben tijd nodig om te installeren en te starten. Ze hebben ook tijd nodig om verbinding te maken met externe opslag en informatie van controlepunten te verzamelen. Een opwarmperiode voor een toepassing hebben voordat u de verwerking kunt starten. Tijdens de opwarmperiode moet de toepassing beginnen, verbindingen tot stand brengen en voorbereiden om een bijdrage te leveren. Sta alleen toe dat een toepassing begint met het verwerken van gegevens nadat u de status van de toepassing hebt gevalideerd.
Door de gebruiker toegewezen beheerde identiteiten configureren
Wijs door de gebruiker toegewezen beheerde identiteiten toe om het verificatie- en autorisatieproces te stroomlijnen. Door de gebruiker toegewezen beheerde identiteiten kunt u voorkomen dat u referenties in code plaatst en niet is gekoppeld aan één resource, zoals door het systeem toegewezen beheerde identiteiten. De door de gebruiker toegewezen beheerde identiteiten bevatten machtigingen en toegangstokens van Microsoft Entra-id die tijdens de indeling opnieuw kunnen worden gebruikt en toegewezen aan spot-VM's. Tokenconsistentie tussen spot-VM's helpt de indeling te stroomlijnen en vereenvoudigt de toegang tot workloadresources die de spot-VM's hebben.
Als u door het systeem toegewezen beheerde identiteiten gebruikt, krijgt een nieuwe spot-VM mogelijk een ander toegangstoken van Microsoft Entra ID. Als u door het systeem toegewezen beheerde identiteiten wilt gebruiken, maakt u de workloads tolerant voor 403 Forbidden Error antwoorden. Uw indeling moet tokens ophalen van Microsoft Entra ID met de juiste machtigingen. Zie Beheerde identiteitenvoor meer informatie.
Voorbeeldscenario
In het voorbeeldscenario wordt een toepassing voor wachtrijverwerking geïmplementeerd die in aanmerking komt als een onderbreekbare workload. De scripts in het scenario fungeren als voorbeelden. In het scenario wordt u begeleid bij een eenmalige, handmatige push om resources te implementeren. Deze implementatie heeft geen implementatiepijplijn. Een implementatiepijplijn is echter essentieel voor het automatiseren van het indelingsproces. In het volgende diagram ziet u de architectuur van het voorbeeldscenario.
Een Visio-bestand downloaden van deze architectuur.
De volgende werkstroom komt overeen met het vorige diagram:
vm-toepassingsdefinitie: de definitie van de VM-toepassing wordt gemaakt in de Azure-rekengalerie. Hiermee definieert u de naam, locatie, besturingssysteem en metagegevens van de toepassing. De toepassingsversie is een genummerde versie van de definitie van de VM-toepassing. De toepassingsversie vertegenwoordigt de VM-toepassing. Deze moet zich in dezelfde regio bevinden als de spot-VM. De toepassingsversie is gekoppeld aan het brontoepassingspakket in het opslagaccount.
Storage-account: Het opslagaccount slaat het brontoepassingspakket op. In deze architectuur is het een gecomprimeerd tar-bestand met de naam
worker-0.1.0.tar.gz. Het bevat twee bestanden. Eén bestand is hetorchestrate.shbash-script waarmee de .NET-werktoepassing wordt geïnstalleerd.spot-VM: de spot-VM wordt geïmplementeerd. Deze moet zich in dezelfde regio bevinden als de toepassingsversie. Na de implementatie wordt
worker-0.1.0.tar.gzgedownload naar de virtuele machine. Met de bicep-sjabloon wordt een Ubuntu-installatiekopie geïmplementeerd op een standaardfamilie-VM. Deze configuraties voldoen aan de behoeften van deze toepassing en zijn geen algemene aanbevelingen voor uw toepassingen.Storage-wachtrij: de andere service die wordt uitgevoerd in de .NET-werkrol, bevat logica voor de berichtenwachtrij. Microsoft Entra ID verleent de spot-VM toegang tot de opslagwachtrij in Azure Queue Storage met een door de gebruiker toegewezen identiteit met behulp van op rollen gebaseerd toegangsbeheer.
.NET-werktoepassing: Met het script
orchestrate.shwordt een .NET-werktoepassing geïnstalleerd waarop twee achtergrondservices worden uitgevoerd. De eerste service voert een query uit op het eindpunt Geplande gebeurtenissen, zoekt naar hetPreemptsignaal en verzendt dit signaal naar de tweede service. De tweede service verwerkt berichten uit de opslagwachtrij en luistert naar hetPreemptsignaal van de eerste service. Wanneer de tweede service het signaal ontvangt, wordt de verwerking van de opslagwachtrij onderbroken en wordt de computer afgesloten.Eindpunt geplande gebeurtenissen opvragen: een API-aanvraag wordt verzonden naar een statisch niet-routable IP-adres
169.254.169.254. De API-aanvraag vraagt het eindpunt Geplande gebeurtenissen op voor onderhoudssignalen van de infrastructuur.Application Insights: De architectuur maakt alleen gebruik van Application Insights voor leerdoeleinden. Het is geen essentieel onderdeel van onderbreekbare werkbelastingindeling, maar u kunt de telemetrie van de .NET-werkroltoepassing valideren. De .NET-werktoepassing verzendt telemetrie naar Application Insights. Zie Live metrics inschakelen vanuit de .NET-toepassingvoor meer informatie.
Dit scenario implementeren
Er is een GitHub-opslagplaats met de naam onderbreekbare workload ter plaatse met sjablonen, scripts en stapsgewijze instructies voor het implementeren van deze architectuur.