Delen via


Spot-VM's gebruiken in Azure CycleCloud

Azure CycleCloud biedt ondersteuning voor het implementeren van Spot-VM's in nodearrays om de operationele kosten van clusters aanzienlijk te verlagen.

Waarschuwing

Spot-VM's zijn niet geschikt voor alle workloads en clustertypen. Ze bieden geen SLA voor beschikbaarheid of capaciteit. Ze zijn 'preemptible' of 'low-priority'-exemplaren en kunnen worden verwijderd door de Azure-infrastructuur om capaciteit te beheren en naarmate de Spot-prijs verandert.

Een Nodearray configureren voor Spot

Als u Spot wilt inschakelen voor een knooppuntarray, stelt u Interruptible deze in op waar in de [[nodearray]] sectie.

Met CycleCloud kunnen clusters een MaxPrice spot-instantie opgeven. Aangezien de Spot-prijs periodiek kan worden aangepast en aanzienlijk kan variëren tussen regio's en SKU's, MaxPrice kunnen gebruikers de maximumprijs (in $/uur) beheren die ze bereid zijn voor een VIRTUELE machine te betalen. CycleCloud wordt standaard ingesteld MaxPrice=-1 wanneer dit niet anders is opgegeven, wat betekent dat 'niet worden verwijderd op basis van spotprijs'. Met deze instelling worden exemplaren alleen verwijderd vanwege wijzigingen in capaciteitsvereisten of andere beslissingen op platformniveau.

Zie Spot-prijzen voor meer informatie over variabele prijzen voor Spot-exemplaren.

Voor de meeste HPC-toepassingen MaxPrice=-1 is dit een goede standaardkeuze. Als een knooppuntarray echter ondersteuning biedt voor automatisch schalen met meerdere selecties voor een reeks VM-SKU's, kan het MaxPrice ook worden aangepast om een voorkeur te maken voor goedkopere SKU's in de lijst met meerdere selecties.

[cluster demo]

  [[nodearray execute]]
  Interruptible = true
  MaxPrice = 0.2

Zie Spot Virtual Machines in de handleiding voor clustersjablonen voor meer informatie.

Verwijdering van VM's herkennen

CycleCloud bewaakt op spot-verwijderingen via de functie Geplande gebeurtenissen . Wanneer een spot-premption-gebeurtenis wordt gedetecteerd, ontvangt CycleCloud een melding van de VIRTUELE machine en wordt het exemplaar verplaatst naar de status 'Wachten op verwijdering'.

Veelgestelde vragen

Het gebruik van Spot met CycleCloud heeft enkele overwegingen die specifiek zijn voor HPC-workloads en CycleCloud voor automatisch schalen.

Wanneer moet ik Overwegen Spot te gebruiken?

  • Zijn uw individuele taken relatief kort?
    • Een goede vuistregel is dat taken die binnen een uur worden uitgevoerd, mogelijk geschikt zijn voor Spot-exemplaren, omdat er relatief weinig voortgang verloren gaat als het exemplaar wordt verwijderd.
  • Probeert uw scheduler taken automatisch opnieuw uit te voeren/opnieuw te verzenden op hosts die mislukken?
  • Zijn uw taken veilig om opnieuw uit te voeren als de host tijdens de uitvoering wordt verwijderd?
    • In het algemeen zijn spot-exemplaren het beste voor stateless workloads.
  • Minimaliseert u de kosten van de uitvoering belangrijker dan de voltooiingstijd?
    • Spot is vaak perfect voor workloads die mogelijk on-premises in wachtrijen met lage prioriteit of back-fill worden gepland.
    • Dit is een van de gevallen waarin Spot geschikt kan zijn, zelfs voor korte MPI-taken.

Wanneer moet ik spot niet gebruiken?

  • Als uw taken nauw gekoppeld zijn aan HPC-taken (bijvoorbeeld MPI-taken), zijn ze waarschijnlijk geen goede kandidaten voor Spot.
  • Als uw taak kritiek is en/of een deadline heeft voor voltooiing, zijn instanties met regelmatige prioriteit mogelijk beter geschikt omdat verwijderingen en nieuwe pogingen de tijd tot voltooiing kunnen verlengen.
    • Dit kan echter een uitstekende kans zijn om uw cluster te configureren voor het gebruik van een combinatie van reguliere prioriteit en Spot-exemplaren om ervoor te zorgen dat aan de deadline wordt voldaan terwijl wordt geprobeerd runtime en kosten te verminderen door Spot-exemplaren toe te voegen.
  • Als uw taken niet veilig zijn om opnieuw uit te voeren, moet Spot worden vermeden.
    • Als uw taak bijvoorbeeld een database wijzigt tijdens de uitvoering, kan het automatisch opnieuw uitvoeren van de taak fouten of ongeldige resultaten veroorzaken.
  • Als uw Jobs-runtimes erg lang zijn, is Spot mogelijk niet geschikt.
    • Voor lange processen nemen zowel de kans op verwijdering van Spot als dollar en tijdkosten van nieuwe pogingen toe.
    • Dit is echter een geval dat metingen per geval kan vereisen.

Verwijdering/voorverwijdering

Zie Spot-verwijderingsbeleid voor meer informatie over spot-verwijdering in Azure.

V. Kan CycleCloud spot-exemplaar verwijderingen/verwijderingen/preemptions bijhouden?

A. Ja. Met een spot-verwijderingsbeurt wordt een melding over gebeurtenislogboeken gegenereerd op de pagina Clusters-gebruikersinterface.

V. Hoe worden gebruikers op de hoogte gesteld van verwijdering?

A. Nadat een CycleCloud-knooppunt is verwijderd, zien gebruikers een logboekbericht in het gebeurtenislogboek van de CycleCloud-gebruikersinterface voor het cluster. Gebruikers kunnen zich ook registreren om een gebeurtenis te ontvangen van CycleCloud via Azure EventGrid nadat een spot-exemplaar is verwijderd.

  • Gebruikers kunnen controleren op een verwijderingsmelding op de machine 30 seconden voordat ze worden verwijderd. Zie Geplande gebeurtenissen voor meer informatie over het registreren voor de gebeurtenis.
  • Over het algemeen moet verwijdering worden beschouwd als vergelijkbaar met het trekken van de stekker op een on-premises machine en moet deze op dezelfde manier worden verwerkt.
  • BELANGRIJK Gebeurtenis-handlers mogen de Spot-verwijderingsgebeurtenis niet erkennen , omdat de Cyclecloud-gebeurtenis-handler de gebeurtenis mogelijk niet ontvangt als deze wordt bevestigd.

V. Hoe vaak treedt verwijdering op?

A. Het verwijderingspercentage is zeer variabel en grotendeels afhankelijk van veranderingen in de vraag in de hele regio.

V. Waarom worden exemplaren verwijderd?

A. Spot-VM's geven geen garanties over beschikbaarheid en kunnen op elk gewenst moment worden verwijderd. Zie de spot-VM-documentatie voor meer informatie. Als een knooppuntarray een MaxPrice knooppunt heeft ingesteld, worden exemplaren verwijderd als de Spot-prijs hoger is dan de MaxPrice. Dit is meestal zeldzaam omdat de Spot-prijs heel langzaam beweegt. Hier volgen enkele scenario's die een verwijdering kunnen activeren:

  1. Reducties in spot-capaciteit naarmate de vraag naar vm's met een normale prioriteit toeneemt.
  2. Gebeurtenissen op platformniveau, zoals gepland hardwareonderhoud.

Hoe wordt mijn werkstroom beïnvloed door verwijdering?

V. Wat gebeurt er met mijn taken wanneer een Spot-exemplaar wordt verwijderd?

A. Tenzij de taken zijn gecodeerd om de verwijderingsmelding van 30 seconden af te handelen en deze op de juiste manier af te handelen, wordt het knooppunt gewoon beëindigd en is de taak mislukt (en hopelijk opnieuw geprobeerd).

V. Worden de knooppunten verwijderd uit het cluster?

A. Ja, de knooppunten worden opgeschoond in de gebruikersinterface van CycleCloud. In ondersteunde planners worden de knooppunten ook opgeschoond in de planner.

V. Moeten taken opnieuw worden uitgevoerd?

A. Over het algemeen is het de taak van de scheduler om de taken die zijn verwijderd, opnieuw uit te proberen/opnieuw uit te voeren. Veel taakklassen zijn echter niet tolerant voor nieuwe pogingen (bijvoorbeeld als ze gedeeltelijke gegevens schrijven naar permanente opslag terwijl ze worden uitgevoerd). Deze taken zijn mogelijk geen goede kandidaat voor uitvoering op Spot-exemplaren.

V. Kan ik een combinatie van spot- en on-demand/vm's met normale prioriteit gebruiken?

A. Ja. U kunt afzonderlijke Spot-knooppuntarrays enInterruptible niet-Spot-knooppuntarrays gebruiken om een combinatie van Spot en Regular-Priority te maken. Als u een combinatie van instantietypen gebruikt, moet u doorgaans enkele configuratiebeslissingen nemen, afhankelijk van de vereisten en de planner die de gebruiker heeft gekozen. Hier volgen enkele algemene configuraties:

  • Scheid spot- en Regular-Priority-VM's in afzonderlijke wachtrijen in de planner.
    • Met deze configuratie kan de verzender eenvoudig taken richten op het juiste VM-type
  • Maak één grote resourcegroep met zowel Spot- als Regular-Priority-exemplaren.
    • Deze configuratie kan handig zijn voor zeer schaalbare workloads die gebruikmaken van een klein percentage exemplaren van normale prioriteit om de voortgang en een groot percentage spot vooruit te helpen om de kosten en runtime te verlagen.

V. Kan ik het spot-verwijderingsbeleid voor CycleCloud-knooppuntarrays wijzigen?

A. Ja. U kunt het EvictionPolicy kenmerk rechtstreeks op de knooppuntarray instellen om het beleid te wijzigen in Delete of Deallocate (standaard: Delete). Dit is momenteel echter alleen nuttig voor aangepaste automatische schaalaanpassingen die deallocaties op de juiste manier verwerken. De huidige Automatische schaalaanpassing van Azure CycleCloud verwacht dat Spot-exemplaren worden verwijderd bij verwijdering.

Scheduler-ondersteuning voor spot-verwijdering in CycleCloud

Raadpleeg de planningsspecifieke handleiding voor gedetailleerde informatie over de CycleCloud-implementatie voor uw planner.

V. Hoe verwerkt de automatische schaalaanpassing voor mijn Scheduler Spot-verwijdering?

A. Alle automatische schaalaanpassingen voor de ingebouwde/ondersteunde schedulers (HTCondor, GridEngine, PBS Professional, Slurm, LSF) proberen spot-verwijderingen correct af te handelen. Over het algemeen wordt het verwijderde exemplaar verwijderd uit de Scheduler en als de capaciteitsvraag na verwijdering hoger is dan de nieuwe beschikbare capaciteit, wordt de instantie vervangen door de automatische schaalaanpassing.

Aangepaste automatische schaalaanpassingen moeten worden gebouwd om spot-verwijderingen of algemene machinefouten te verwachten en deze probleemloos af te handelen.

V. Wat moet ik verwachten van de taken die werden uitgevoerd op het verwijderde exemplaar?

A. Dit is grotendeels aan de gebruiker die moet configureren bij het indienen van de taak. Bij sommige planners, zoals GridEngine, kan de standaardactie ook per wachtrij worden geconfigureerd. Standaard worden alle ingebouwde CycleCloud-scheduler-implementaties, met uitzondering van HTCondor, geconfigureerd om de taken als mislukt te markeren wanneer het knooppunt waarop ze worden uitgevoerd, wordt verwijderd of onverwacht beëindigd. Dit gedrag is standaard omdat alleen de gebruiker kan weten of hun taken veilig opnieuw kunnen worden geprobeerd.