Använda virtuella datorer med oanvänd kapacitet i Azure CycleCloud

Azure CycleCloud stöder distribution av virtuella datorer med oanvänd kapacitet i nodearrays för att avsevärt minska driftkostnaden för kluster.

Varning

Virtuella datorer med oanvänd kapacitet är inte lämpliga för alla arbetsbelastningar och klustertyper. De erbjuder inget serviceavtal för tillgänglighet eller kapacitet. De är "fördefinierade" eller "lågprioriterade" instanser och kan tas bort av Azure-infrastrukturresurserna för att hantera kapacitet och när spotpriset ändras.

Konfigurera en Nodearray för spot

Om du vill aktivera Spot för en nodearray anger du Interruptible helt enkelt till sant i [[nodearray]] avsnittet.

CycleCloud gör att kluster kan ange en MaxPrice för Spot-instanser. Eftersom spotpriset kan justeras regelbundet och kan variera avsevärt mellan regioner och SKU:er kan MaxPrice användarna styra det högsta pris (i $/timme) som de är villiga att betala för en virtuell dator. Som standard anger MaxPrice=-1 CycleCloud när inget annat anges, vilket innebär att "ta inte bort baserat på spotpris". Med den här inställningen tas instanser bara bort på grund av ändringar i kapacitetskrav eller andra beslut på plattformsnivå.

Se Spotprissättning för information om variabel prissättning för spotinstanser.

För de flesta HPC-program MaxPrice=-1 är ett bra standardval. Men om en nodearray stöder automatisk skalning med flera val över en rad vm-SKU:er kan du MaxPrice också anpassa den för att skapa en inställning för SKU:er med lägre priser i listan med flerval.

[cluster demo]

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

Fullständig information finns i Spot Virtual Machines i guiden för klustermallar.

Borttagning av virtuell dator för oanvänd kapacitet

CycleCloud-övervakare för borttagning av oanvänd kapacitet via funktionen Schemalagda händelser . När en platsförvalshändelse identifieras meddelas CycleCloud av den virtuella datorn och instansen flyttas till tillståndet "väntar på borttagning".

Vanliga frågor och svar

Att använda Spot med CycleCloud har vissa överväganden som är specifika för HPC-arbetsbelastningar och automatisk skalning av CycleCloud.

När bör jag överväga att använda Spot?

• Är dina enskilda jobb relativt korta?
  • En bra tumregel är att jobb som körs på mindre än en timme kan passa bra för Spot-instanser, eftersom relativt lite framåtförlopp går förlorade om instansen tas bort.
• Försöker schemaläggaren automatiskt om jobb på värdar som inte fungerar?
• Är dina jobb säkra att köra om värden tas bort under körningen?
  • I allmänhet är instanser av oanvänd kapacitet bäst för tillståndslösa arbetsbelastningar.
• Är det viktigare att minimera kostnaden för körningen än slutförandetiden?
  • Spot är ofta perfekt för arbetsbelastningar som kan schemaläggas i köer med låg prioritet eller serverfyllning lokalt.
  • Detta är ett av de fall där spot kan vara lämpligt även för korta MPI-jobb.

När ska jag undvika att använda Spot?

• Om dina jobb är nära kopplade HPC-jobb (till exempel MPI-jobb) är de sannolikt inte bra kandidater för Spot.
• Om jobbet är kritiskt och/eller har en tidsgräns för slutförande kan vanliga prioritetsinstanser passa bättre eftersom borttagningar och återförsök kan förlänga tiden till slutförande.
  • Detta kan dock vara ett utmärkt tillfälle att konfigurera klustret så att det använder en blandning av vanliga prioritets- och spotinstanser för att säkerställa att tidsgränsen uppfylls samtidigt som körningen och kostnaden minskas genom att lägga till Spot-instanser.
• Om dina jobb inte är säkra att köra igen bör spot undvikas.
  • Om ditt jobb till exempel ändrar en databas under körningen kan det orsaka fel eller ogiltiga resultat att automatiskt köra jobbet igen.
• Om dina jobbkörningar är mycket långa kanske spot inte passar bra.
  • För långa processer ökar både risken för spotavhysning och dollar och tidskostnaderna för återförsök.
  • Detta är dock ett fall som kan kräva mätning från fall till fall.

Borttagning/preemption

Mer information om borttagning av oanvänd kapacitet i Azure finns i Borttagningsprincip för oanvänd kapacitet.

F. Kan CycleCloud spåra avhysningar/preemptioner för spotinstanser?

A. Ja. En händelse för borttagning av oanvänd kapacitet genererar ett händelseloggmeddelande på sidan Klustergränssnitt.

F. Hur meddelas användare om avhysning?

A. När en CycleCloud-nod har avlägsnats ser användarna ett loggmeddelande i CycleCloud-användargränssnittets händelselogg för klustret. Användare kan också registrera sig för att ta emot en händelse från CycleCloud via Azure EventGrid när en instans av oanvänd kapacitet har avlägsnats.

• Användare kan söka efter ett borttagningsmeddelande på datorn 30 sekunder före borttagningen. Mer information om hur du registrerar dig för händelsen finns i Schemalagda händelser .
• I allmänhet bör borttagning betraktas som att dra ur kontakten på en lokal dator, och den bör hanteras på samma sätt.
• VIKTIGT Händelsehanterare bör inte bekräfta spotavlägsningshändelsen, eftersom Cyclecloud-händelsehanteraren kanske inte får händelsen om den bekräftas.

F. Hur ofta sker borttagning?

A. Borttagningsfrekvensen är mycket varierande och till stor del beroende av förändringar i efterfrågan i hela regionen.

F. Varför avlägsnas instanser?

A. Virtuella datorer med oanvänd kapacitet ger inga garantier om tillgänglighet och kan avlägsnas när som helst. Mer information finns i dokumentationen för virtuella datorer med oanvänd kapacitet . Om en nodearray har angett en MaxPrice tas instanser bort om spotpriset stiger över MaxPrice. Detta tenderar att vara sällsynt eftersom spotpriset rör sig mycket långsamt. Här är några scenarier som kan utlösa en borttagning:

1. Minskad kapacitet för oanvänd kapacitet när efterfrågan på vanliga virtuella datorer med prioritet ökar.
2. Händelser på plattformsnivå, till exempel planerat maskinvaruunderhåll.

Hur påverkas mitt arbetsflöde av borttagning?

F. Vad händer med mina jobb när en Spot-instans tas bort?

A. Såvida inte jobben är kodade för att hantera 30 sekunders borttagningsavisering och hantera det på rätt sätt, avslutas noden helt enkelt och jobbet misslyckas (och förhoppningsvis försöker igen).

F. Tas noderna bort från klustret?

A. Ja, noderna rensas i CycleCloud-användargränssnittet. I schemaläggare som stöds rensas noderna också i schemaläggaren.

F. Måste jobb köras på nytt?

A. I allmänhet är det schemaläggarens jobb att försöka/köra om jobben som tas bort. Många jobbklasser är dock inte toleranta mot omförsök (till exempel om de skriver partiella data till beständig lagring när de körs). Dessa jobb kanske inte är bra kandidater för körning på spot-instanser.

F. Kan jag använda en blandning av virtuella datorer med oanvänd kapacitet och på begäran/normal prioritet?

A. Ja. Du kan använda separata noder för oanvänd kapacitet (Interruptible) och noder utan oanvänd kapacitet för att skapa en blandning av Spot och Regular-Priority. Att använda en blandning av instanstyper kräver vanligtvis att vissa konfigurationsbeslut fattas beroende på kraven och den schemaläggare som användaren har valt. Här är några vanliga konfigurationer:

• Separera spot och Regular-Priority virtuella datorer i separata köer i schemaläggaren.
  • Den här konfigurationen gör det möjligt för inskickarna att enkelt rikta jobben mot lämplig typ av virtuell dator
• Skapa en enda stor resurspool med både spot- och Regular-Priority-instanser.
  • Den här konfigurationen kan vara användbar för mycket skalbara arbetsbelastningar som använder en liten procentandel vanliga prioritetsinstanser för att säkerställa framåtskridande och en stor procentandel av Spot för att minska kostnader och körning.

F. Kan jag ändra borttagningsprincipen för oanvänd kapacitet för CycleCloud-noder?

A. Ja. Du kan ange EvictionPolicy attributet direkt i nodearray för att ändra principen till antingen Delete eller Deallocate (standard: Delete). Detta är dock för närvarande endast användbart för anpassade autoskalningar som hanterar frilokaliseringar på lämpligt sätt. De aktuella Azure CycleCloud-autoskalningarna förväntar sig att Spot-instanser tas bort vid avlägsning.

Scheduler-stöd för avlägsning av oanvänd kapacitet i CycleCloud

Se den schemaläggarspecifika guiden för detaljerad information om CycleCloud-implementeringen för schemaläggaren.

F. Hur hanterar autoskalning för min Scheduler avlägsning av oanvänd kapacitet?

A. Alla autoskalningar för de inbyggda/stödda schemaläggarna (HTCondor, GridEngine, PBS Professional, Slurm, LSF) försöker hantera Spot-borttagningar på ett smidigt sätt. I allmänhet tas den avlägsnade instansen bort från Scheduler och om kapacitetsefterfrågan är högre än den nya tillgängliga kapaciteten efter borttagningen ersätter autoskalningen instansen.

Anpassade autoskalningar bör skapas för att förvänta sig avlägsning av oanvänd kapacitet eller allmänna datorfel och hantera dem på ett smidigt sätt.

F. Vad ska jag förvänta mig att hända med de jobb som kördes på den avlägsnade instansen?

A. Detta är till stor del upp till användaren att konfigurera när jobbet skickas. Vissa schemaläggare, till exempel GridEngine, tillåter att standardåtgärden också konfigureras per kö. Som standard konfigureras alla inbyggda CycleCloud-schemaläggningsdistributioner, med undantag för HTCondor, för att markera jobben som misslyckade när noden de körs på avlägsnas eller oväntat avslutas. Det här beteendet är avsiktligt eftersom endast användaren kan veta om deras jobb kan försökas igen på ett säkert sätt.