Workloads bouwen op virtuele machines ter plaatse

In dit artikel wordt een overzicht gegeven van de aanbevolen procedures voor het bouwen op virtuele Machines (VM's) van Azure-spot en het opnemen van een implementeerbaar voorbeeldscenario. Spot-VM's bieden toegang tot rekencapaciteit tegen aanzienlijke kortingen op reguliere VM's. Deze korting maakt ze een aantrekkelijke oplossing voor organisaties die kosten willen optimaliseren, maar de besparingen worden geleverd met een voorwaarde. Spot-VM's hebben op elk gewenst moment geen toegang meer tot berekeningen. We noemen dit proces een verwijdering. Workloads die worden uitgevoerd op spot-VM's, moeten deze onderbrekingen in de berekening kunnen afhandelen. De juiste werkbelasting en een flexibel indelingsmechanisme zijn de sleutels voor succes. Hier volgen onze aanbevelingen voor het bouwen van spot-VM's.

Inzicht in virtuele spot-machines

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 verschil tussen spot- en reguliere VM's komt neer op prioriteit en beschikbaarheid. Spot-VM's hebben geen prioriteit voor toegang tot rekencapaciteit en ze hebben geen beschikbaarheidsgaranties na toegang tot die rekencapaciteit. Laten we de prioriteit en beschikbaarheid in meer detail bespreken.

Geen prioriteitstoegang. Normale VM's hebben prioriteitstoegang tot rekencapaciteit. Ze hebben toegang tot de rekencapaciteit wanneer ze deze aanvragen. Spot-VM's daarentegen alleen wanneer er reserve-rekencapaciteit is en ze blijven actief wanneer een gewone VIRTUELE machine de onderliggende hardware niet nodig heeft.

Geen beschikbaarheidsgarantie. Spot-VM's hebben geen beschikbaarheidsgaranties. Ze hebben geen service level agreements (SLA's). Spot-VM's kunnen de toegang tot de rekencapaciteit onmiddellijk of op elk gewenst moment na de implementatie verliezen (verwijdering). Spot-VM's zijn goedkoper vanwege de verwijderingsmogelijkheid. 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 verwijdering in dit artikel voor meer informatie.

Prijzen voor spot-VM's begrijpen

Spot-VM's kunnen tot 90 procent goedkoper zijn dan gewone vm's (betalen per gebruik). De korting varieert op basis van vraag, VM-grootte, implementatieregio en besturingssysteem. U wordt aangeraden het prijshulpprogramma voor Azure Spot VM te gebruiken om een schatting te krijgen van de kostenbesparingen. Zie voor meer informatie:

• Prijshulpprogramma voor Azure Spot-VM's
• Overzicht van spot-VM-prijzen

U kunt ook een query uitvoeren op de API voor retailprijzen van Azure om programmatisch de spotprijzen te verkrijgen voor elke gewenste SKU.

Inzicht in onderbreekbare workloads

Interruptible-workloads zijn de beste use-case voor spot-VM's. Interruptible-workloads hebben enkele algemene kenmerken. Ze hebben minimale tot geen tijdsbeperkingen, lage prioriteit van de organisatie 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 batchverwerkingstoepassingen, gegevensanalyses en workloads die een continue integratie-continue implementatieagent maken voor een niet-productieomgeving. Deze functies contrasteren met normale of bedrijfskritieke workloads met service level agreements (SLA's), plaksessies en stateful gegevens. De tabel bevat voorbeelden voor beide workloadtypen.

U kunt spot-VM gebruiken in niet-interruptibele werkbelastingen, maar deze 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 service level agreements (SLA's) nadat ze zijn gemaakt en hebben op elk gewenst moment geen toegang meer tot rekenkracht. We noemen dit rekenverlies een verwijdering. Verwijdering van vraag- en aanbodstations berekenen. Wanneer de vraag naar een specifieke VM-grootte een bepaald 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 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. Laten we beide configuratieopties aanpakken.

Verwijderingstype

Verwijdering wordt veroorzaakt door capaciteitswijzigingen of prijswijzigingen. De manier waarop deze van invloed zijn op spot-VM's, is afhankelijk van het verwijderingstype dat is gekozen toen de VIRTUELE machine werd gemaakt. Het verwijderingstype definieert de voorwaarden van een verwijdering. De verwijderingstypen zijn 'alleen capaciteitsverwijdering' en 'prijs of capaciteitsverwijdering'.

Alleen verwijdering van capaciteit: Met dit verwijderingstype wordt een verwijdering geactiveerd wanneer overtollige rekencapaciteit verdwijnt. De prijs wordt standaard beperkt tot het tarief voor betalen per gebruik. Gebruik dit verwijderingstype wanneer u bereid bent om te betalen voor de vm-prijs voor betalen per gebruik.

Verwijdering van prijs of capaciteit: dit verwijderingstype heeft twee triggers. Azure verwijdert een spot-VM wanneer overtollige rekencapaciteit verdwijnt of de kosten van de VIRTUELE machine de maximale prijs overschrijden die u hebt ingesteld. Met dit verwijderingstype kunt u een maximumprijs instellen onder de prijs voor betalen per gebruik. Gebruik dit verwijderingstype om uw eigen prijslimiet in te stellen.

Verwijderingsbeleid

Het verwijderingsbeleid dat is gekozen voor een spot-VM, is van invloed op de indeling ervan. Door indeling bedoelen we het proces van het verwerken van een verwijdering. We behandelen indeling later in detail. Het verwijderingsbeleid is het beleid 'Beleid stoppen/toewijzing ongedaan maken' en 'Beleid verwijderen'.

Beleid stoppen/de toewijzing ongedaan maken: het verwijderingsbeleid stoppen/ongedaan maken is het beste wanneer de workload 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. Met het beleid Stoppen/Toewijzing ongedaan maken verliest de VM rekencapaciteit en niet-statische IP-adressen. De VM-gegevensschijven blijven echter behouden en er worden nog steeds kosten in rekening gebracht. 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 zijn gestopt/de toewijzing ervan ongedaan gemaakt. Zie de energiestatussen en facturering van VM's voor meer informatie.

Beleid verwijderen: gebruik het beleid Verwijderen als de werkbelasting de locatie of VM-grootte kan wijzigen. Door de locatie en/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 verwijderingsbeleid voor meer informatie over verwijderingsbeleid.

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. Door flexibiliteit bedoelen we het ontwerpen van uw indeling om opties te hebben, meerdere VM-grootten te gebruiken, te implementeren in verschillende regio's, bewust te zijn van verwijdering en rekening te houden met verschillende verwijderingsscenario's om de betrouwbaarheid en snelheid van de workload te verbeteren.

Hieronder vindt u aanbevelingen om u te helpen flexibele indeling te ontwerpen voor uw onderbreekbare workload.

Ontwerp voor snelheid

Voor een workload die wordt uitgevoerd op spot-VM's, is rekencapaciteit een schat. Het dreigende potentieel voor verwijdering moet uw waardering verhogen voor de toegewezen rekentijd en moet worden omgezet in zinvolle ontwerpbeslissingen die prioriteit geven aan de werkbelastingssnelheid. Over het algemeen raden we u aan de rekentijd te optimaliseren die u hebt. U moet een VM-installatiekopieën bouwen met alle vereiste software die vooraf is geïnstalleerd. Vooraf geïnstalleerde software helpt de tijd tussen verwijdering en een volledig actieve toepassing te minimaliseren. U wilt voorkomen dat u rekentijd gebruikt voor processen die niet bijdragen aan het doel van de workload. Een workload voor gegevensanalyse moet bijvoorbeeld de meeste rekentijd richten op gegevensverwerking en zo weinig mogelijk op het verzamelen van verwijderingsmetagegevens. Elimineren van niet-essentiële processen uit uw toepassing.

Meerdere VM-grootten en -locaties gebruiken

U wordt aangeraden een indeling te maken om meerdere VM-typen en -grootten te gebruiken om de flexibiliteit te vergroten. Het doel is om uw indelingsopties te geven om een verwijderde VM te vervangen. Azure heeft verschillende VM-typen en -grootten die vergelijkbare mogelijkheden bieden voor ongeveer dezelfde prijs. U moet VM's min vCPU's/cores en/of min RAM filteren, en de maximale prijs om meerdere VM's te vinden die de kracht hebben om uw workload uit te voeren en binnen uw budget te passen. Elk VM-type heeft een verwijderingspercentage dat wordt uitgedrukt als een percentagebereik (0-5%, 5-10%, 10-15%, 15-20%, 20+%). De verwijderingspercentages kunnen per regio verschillen. Mogelijk vindt u een beter verwijderingspercentage voor hetzelfde VM-type in een andere regio. U vindt de verwijderingspercentages voor elk VM-type in de portal op het tabblad Basisbeginselen. Selecteer de koppelingen 'Grootte' ('Prijsgeschiedenis weergeven' of 'Alle grootten weergeven'). U kunt ook programmatisch spot-VM-gegevens ophalen met behulp van Azure Resource Graph. Zie voor meer informatie:

• Verwijderingspercentages
• Azure Resource Graph

Het meest flexibele verwijderingsbeleid gebruiken

Het verwijderingsbeleid van de verwijderde spot-VM is van invloed op het vervangingsproces. Verwijderingsbeleid voor verwijderen is flexibeler dan een gestopt/ongedaan gemaakt verwijderingsbeleid.

Overweeg eerst het verwijderingsbeleid: u wordt aangeraden een verwijderingsbeleid voor verwijderen te 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 om sneller reserve-rekencapaciteit te vinden dan een gestopte/niet-toegewezen VM. Gestopte/niet-toegewezen VM's moeten wachten op reserve-rekencapaciteit in dezelfde zone waarin deze is gemaakt. Voor het verwijderingsbeleid hebt u een proces nodig om te controleren op verwijderingen die extern zijn voor de toepassing en implementaties in verschillende regio's en/of met verschillende VM-SKU's indelen.

Meer informatie over het beleid gestopt/de toewijzing ongedaan gemaakt: het beleid voor gestopt/ongedaan maken heeft minder flexibiliteit dan het verwijderingsbeleid. De spot-VM's moeten zich in dezelfde regio en zone bevinden. U kunt een gestopte/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 te voorspellen wanneer de rekencapaciteit beschikbaar is. Daarom raden we u aan een geautomatiseerde planningspijplijn te gebruiken om na een verwijdering een nieuwe implementatie uit te voeren. Een verwijdering moet de planningspijplijn activeren en de nieuwe implementatiepogingen moeten continu controleren op rekencapaciteit totdat deze beschikbaar is.

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. Met deze informatie kunt u proberen een werkbelasting zonder problemen af te sluiten en automatisering te activeren waarmee de vervanging wordt ingedeeld.

Geplande gebeurtenissen gebruiken: u wordt aangeraden de service Geplande gebeurtenissen voor elke VIRTUELE machine te gebruiken. Azure verzendt signalen naar VM's wanneer deze worden beïnvloed door infrastructuuronderhoud. Verwijderingen komen in aanmerking als infrastructuuronderhoud. Azure verzendt het Preempt signaal minimaal 30 seconden naar alle VM's voordat ze worden verwijderd. Met een service met de naam Schedule Events kunt u dit Preempt signaal vastleggen door een eindpunt op te vragen op een statisch, niet-routeerbaar IP-adres 169.254.169.254.

Gebruik frequente query's: het is raadzaam om vaak genoeg een query uit te voeren op het eindpunt Planningsevenementen om een probleemloos afsluiten in te delen. U kunt maximaal elke seconde een query uitvoeren op het eindpunt geplande gebeurtenissen, maar een-secondefrequentie 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 de verwerkingskracht van de hoofdworkload. U moet deze concurrerende prioriteiten in balans brengen om te voldoen aan uw specifieke situatie.

Orchestration automatiseren: zodra u het Preempt signaal hebt verzameld, moet uw indeling op dat signaal reageren. Gezien de tijdsbeperkingen moet het Preempt signaal proberen uw werkbelasting af te sluiten en een geautomatiseerd proces starten dat de spot-VM vervangt. Zie voor meer informatie:

• Geplande gebeurtenissen
• Geplande gebeurtenistypen
• Frequentie van query's voor eindpunten

Een implementatiesysteem bouwen

Uw indeling heeft een geautomatiseerde pijplijn nodig om nieuwe spot-VM's te implementeren wanneer deze worden verwijderd. De pijplijn moet buiten de onderbreekbare workload zelf worden uitgevoerd om de permanentie te garanderen. De manier waarop de implementatiepijplijn moet werken, is afhankelijk van het verwijderingsbeleid dat u hebt geselecteerd 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 voor het stoppen/ongedaan maken van toewijzing heeft de implementatiepijplijn twee afzonderlijke 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 Functions is een van de verschillende manieren 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

Het is mogelijk dat uw spot-VM wordt aangewezen voor verwijdering zodra deze is gemaakt en zelfs voordat uw workload wordt uitgevoerd. Omdat er capaciteit was om een spot-VM te maken, betekent dit niet dat deze blijft bestaan. Spot-VM's hebben geen beschikbaarheidsgaranties (SLA's) na het maken. Uw indeling moet rekening houden met onmiddellijke verwijderingen. Het Preempt signaal zal nog steeds minimaal 30 seconden van tevoren op de hoogte zijn van de verwijdering.

U wordt aangeraden VM-statuscontroles in uw indeling op te nemen om u voor te bereiden op onmiddellijke verwijderingen. Indeling voor onmiddellijke verwijderingen kan niet afhankelijk zijn van het signaal Schema-gebeurtenissen Preempt . Alleen de VM zelf kan een query uitvoeren op het Preempt signaal en er is onvoldoende tijd om een toepassing te starten, een query uit te voeren op het eindpunt Planningsevenementen en het probleemloos af te sluiten. De statuscontrole moet dus zich buiten de workloadomgeving bevinden. De statuscontroles moeten de status van de spot-VM bekijken en de implementatiepijplijn starten om de spot-VM te vervangen wanneer de status verandert om de toewijzing of stop te zetten.

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

De afsluitprocessen van de VIRTUELE machine moeten 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 zijn. Het afsluitproces moet resources vrijgeven, verbindingen leegmaken en gebeurtenislogboeken leegmaken. U moet regelmatig controlepunten maken en opslaan om de context op te slaan 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 VM de wijzigingen moet terugdraaien en het hele proces opnieuw moet starten. Sla de controlepunten buiten de spot-VM-omgeving op. Een opslagaccount zou werken.

De indeling testen

We raden u aan verwijderingsevenementen te simuleren om indeling te testen in ontwikkel-/testomgevingen. Zie verwijdering simuleren voor 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 het één keer verwerken. Verwijderingen kunnen leiden tot gedwongen afsluitingen, ondanks pogingen om ervoor te zorgen dat er geen problemen zijn met het afsluiten. Geforceerde afsluitingen kunnen processen vóór voltooiing beëindigen. Idempotent werkbelastingen kunnen hetzelfde bericht meer dan één keer ontvangen en het resultaat blijft hetzelfde. Zie idempotentie voor meer informatie.

Een opwarmperiode voor toepassingen gebruiken

De meeste onderbrekende workloads voeren toepassingen uit. Toepassingen hebben tijd nodig om te installeren en tijd om op te starten. Ze hebben tijd nodig om verbinding te maken met externe opslag en informatie te verzamelen van controlepunten. We raden u aan om een opwarmperiode voor een toepassing te hebben voordat deze kan worden verwerkt. Tijdens de opwarmperiode moet de toepassing opstarten, verbinding maken en bijdragen voorbereiden. U moet alleen toestaan 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

U wordt aangeraden door de gebruiker toegewezen beheerde identiteiten te gebruiken om het verificatie- en autorisatieproces te stroomlijnen. Door de gebruiker toegewezen beheerde identiteiten kunnen voorkomen dat referenties in code worden opgeslagen en niet zijn 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 op spot-VM's helpt de indeling en de toegang tot workloadresources die de spot-VM's hebben te stroomlijnen.

Met door het systeem toegewezen beheerde identiteiten kan een nieuwe spot-VM een ander toegangstoken krijgen van Microsoft Entra-id. Als u door het systeem toegewezen beheerde identiteiten wilt gebruiken, raden we u aan om de workloads tolerant te maken voor 403 Forbidden Error reacties. Uw indeling moet tokens ophalen van Microsoft Entra-id met de juiste machtigingen. Zie Beheerde identiteiten voor 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 zijn illustratief. Het scenario begeleidt u door een eenmalige, handmatige push om resources te implementeren. We hebben geen implementatiepijplijn opgegeven met deze implementatie. Maar een implementatiepijplijn is essentieel voor het automatiseren van het indelingsproces. Het diagram illustreert de architectuur van het voorbeeldscenario.

In de volgende opmerkingen worden belangrijke aspecten van de architectuur uitgelegd:

1. Vm-toepassingsdefinitie: de definitie van de VM-toepassing wordt gemaakt in de Azure Compute-galerie. 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 is een instantiëring van de VM-toepassing. Deze moet zich in dezelfde regio bevinden als de spot-VM. De toepassingsversie is gekoppeld aan het brontoepassingspakket in het opslagaccount.
2. Opslagaccount: 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 het orchestrate.sh bash-script waarmee de .NET-werkroltoepassing wordt geïnstalleerd.
3. Spot-VM: de spot-VM wordt geïmplementeerd. Deze moet zich in dezelfde regio bevinden als de toepassingsversie. Deze wordt worker-0.1.0.tar.gz na de implementatie gedownload naar de virtuele machine. Met de bicep-sjabloon wordt een Ubuntu-installatiekopie geïmplementeerd op een standard-vm van de serie. Deze configuraties voldoen aan de behoeften van deze toepassing en zijn geen algemene aanbevelingen voor uw toepassingen.
4. Opslagwachtrij: de andere service die wordt uitgevoerd in de .NET-werkrol bevat logica voor berichtenwachtrijen. Microsoft Entra ID verleent de spot-VM toegang tot de opslagwachtrij met een door de gebruiker toegewezen identiteit met behulp van RBAC.
5. .Net-werktoepassing: met het orchestrate.sh script wordt een .NET-werktoepassing geïnstalleerd waarop twee achtergrondservices worden uitgevoerd. De eerste service voert een query uit op het eindpunt Planningsevenementen en zoekt naar het Preempt signaal en verzendt dit signaal naar de tweede service. De tweede service verwerkt berichten uit de opslagwachtrij en luistert naar het Preempt signaal van de eerste service. Wanneer de tweede service het signaal ontvangt, wordt de verwerking van de opslagwachtrij onderbroken en wordt de computer afgesloten.
6. Eindpunt voor geplande gebeurtenissen opvragen: een API-aanvraag wordt verzonden naar een statisch niet-routeerbaar IP-adres 169.254.169.254. De API-aanvraag vraagt het eindpunt geplande gebeurtenis op voor onderhoudssignalen van de infrastructuur.
7. Application Insights: De architectuur maakt alleen gebruik van Application Insights voor leerdoeleinden. Het is geen essentieel onderdeel van de indeling van onderbreekbare werkbelastingen. We hebben deze opgenomen als een manier om de telemetrie van de .NET-werktoepassing te valideren. We hebben de .NET-werktoepassing geconfigureerd voor het verzenden van telemetrie naar Application Insights. Zie Live Metrics inschakelen vanuit de .NET-toepassing voor meer informatie.

Dit scenario implementeren

We hebben ter plaatse een GitHub-opslagplaats met de naam interruptible workload gemaakt met sjablonen, scripts en stapsgewijze instructies voor het implementeren van deze architectuur. In deze opslagplaats vindt u meer technische informatie over de architectuur en technische artefacten.

Volgende stap

Zie Azure Spot Virtual Machines voor meer informatie over spot-VM's.

Verwante resources

• Architectuurbenaderingen voor kostenbeheer en toewijzing in een multitenant-oplossing
• Een Windows VM uitvoeren op Azure
• Een Linux VM uitvoeren op Azure