Redigera

Dela via


Skapa arbetsbelastningar på virtuella datorer med oanvänd kapacitet

Azure Virtual Machines

I den här artikeln beskrivs metodtips för hur du bygger på virtuella Azure Spot-datorer. Den innehåller ett distributionsbart exempelscenario. Virtuella datorer med oanvänd kapacitet (virtuella datorer med oanvänd kapacitet) ger åtkomst till beräkningskapacitet till lägre priser än vanliga virtuella datorer. Den här rabatten gör dem till ett bra alternativ för organisationer som vill optimera kostnaderna. Men besparingarna kommer med en kompromiss. Virtuella datorer med oanvänd kapacitet kan avlägsnas när som helst, vilket innebär att de förlorar åtkomst till beräkningsresurser. Arbetsbelastningar som körs på virtuella datorer med oanvänd kapacitet måste kunna hantera dessa avbrott i beräkningen. Rätt arbetsbelastning och en flexibel orkestreringsmekanism är nycklarna till framgång. Följande rekommendationer beskriver hur du bygger på virtuella datorer med oanvänd kapacitet.

Förstå virtuella datorer med oanvänd kapacitet

På teknisk nivå är virtuella datorer med oanvänd kapacitet samma som vanliga virtuella datorer. De använder samma avbildningar, maskinvara och diskar som översätter till samma prestanda. Den viktigaste skillnaden mellan virtuella datorer med oanvänd kapacitet och vanliga virtuella datorer är deras prioritet och tillgänglighet. Virtuella datorer med oanvänd kapacitet har ingen prioritet att komma åt beräkningskapaciteten och de har inga tillgänglighetsgarantier när de har åtkomst till beräkningskapaciteten.

  • Ingen prioritetsåtkomst. Vanliga virtuella datorer har prioritetsåtkomst till beräkningskapacitet. De kommer åt beräkningskapaciteten när de begär den. Virtuella datorer med oanvänd kapacitet distribueras dock bara när det finns extra beräkningskapacitet. Och de fortsätter bara att köras när en vanlig virtuell dator inte behöver den underliggande maskinvaran.

  • Ingen tillgänglighetsgaranti. Virtuella datorer med oanvänd kapacitet har inga tillgänglighetsgarantier eller serviceavtal (SLA). Virtuella datorer med oanvänd kapacitet kan förlora åtkomsten till beräkningskapaciteten omedelbart, eller när som helst efter distributionen eller borttagningen. Virtuella datorer med oanvänd kapacitet är billigare eftersom de kan avlägsnas. När Azure behöver beräkningskapaciteten tillbaka skickas ett borttagningsmeddelande och tar bort den virtuella datorn för oanvänd kapacitet. Azure tillhandahåller minst 30 sekunders förvarning innan den faktiska borttagningen sker. Mer information finns i Kontinuerligt övervaka för borttagning.

Förstå priser för virtuella datorer med oanvänd kapacitet

Virtuella datorer med oanvänd kapacitet kan vara upp till 90% billigare än vanliga virtuella datorer med användningsbaserad betalning. Rabatten varierar beroende på efterfrågan, VM-storlek, distributionsregion och operativsystem. En kostnadsberäkning finns i prisöversikten azure spot virtual machines och Spot Virtual Machines. Du kan också köra frågor mot API:et Azure-detaljhandelspriser för att programmatiskt få spotpriser för alla SKU:er.

Förstå avbrottsbara arbetsbelastningar

Virtuella datorer med oanvänd kapacitet är idealiska för avbrottsbara arbetsbelastningar som har flera vanliga egenskaper. Avbrottsbara arbetsbelastningar har minimala eller inga tidsbegränsningar, låg organisationsprioritet och korta bearbetningstider. De kör processer som kan stoppas plötsligt och återupptas senare utan att skada viktiga organisationsprocesser. Exempel på avbrottsbara arbetsbelastningar är batchbearbetningsprogram, dataanalys och arbetsbelastningar som skapar en kontinuerlig integrerings- och kontinuerlig distributionsagent för en icke-produktionsmiljö. Dessa funktioner kan jämföras med vanliga eller verksamhetskritiska arbetsbelastningar som har serviceavtal, klibbiga sessioner och tillståndskänsliga data.

Du kan använda virtuella datorer med oanvänd kapacitet i icke-avbrottsfria arbetsbelastningar, men de bör inte vara den enda källan till beräkningskapacitet. Använd så många vanliga virtuella datorer som du behöver för att uppfylla dina drifttidskrav.

Förstå borttagning

Virtuella datorer med oanvänd kapacitet har inga serviceavtal när de har skapats, och de kan förlora åtkomsten till beräkning när som helst. Vi kallar den här beräkningsförlusten för en borttagning. Borttagning av beräkningstillgång och efterfrågan. När efterfrågan på en specifik VM-storlek överskrider en viss nivå avlägsnar Azure virtuella datorer med oanvänd kapacitet för att göra beräkningen tillgänglig för vanliga virtuella datorer. Efterfrågan är platsspecifik. En ökad efterfrågan i region A påverkar till exempel inte virtuella datorer med oanvänd kapacitet i region B.

Virtuella datorer med oanvänd kapacitet har två konfigurationsalternativ som påverkar borttagningen. Dessa konfigurationer är borttagningstyp och borttagningsprincip för den virtuella datorn med oanvänd kapacitet. Du anger dessa konfigurationer när du skapar den virtuella datorn för oanvänd kapacitet. Avlägsningstypen definierar villkoren för en borttagning. Borttagningsprincipen avgör vad borttagning gör med den virtuella datorn för oanvänd kapacitet.

Borttagningstyp

Kapacitetsändringar eller prisändringar orsakar borttagningar. Hur kapacitets- och prisändringar påverkar virtuella datorer med oanvänd kapacitet beror på vilken borttagningstyp du väljer när den virtuella datorn skapas. Typen av borttagning definierar villkoren för en borttagning. Avhysningstyperna är endast kapacitetsavhysning och pris- eller kapacitetsavhysning.

  • Endast kapacitetsavhysning: Den här avlägsningstypen utlöser en borttagning när överskjutande beräkningskapacitet inte längre är tillgänglig. Som standard är priset begränsat till betala per användning-priset. Använd den här avhysningstypen när du inte vill betala mer än priset för den virtuella datorn med användningsbaserad betalning.

  • Pris- eller kapacitetsavhysning: Den här borttagningstypen har två utlösare. Azure tar bort en virtuell dator med oanvänd kapacitet när överskottskapaciteten inte längre är tillgänglig eller kostnaden för den virtuella datorn överskrider det högsta pris som du har angett. Med den här avhysningstypen kan du ange ett högsta pris långt under priset betala per användning. Använd den här borttagningstypen för att ange ett eget pristak.

Borttagningsprincip

Den borttagningsprincip som du väljer för en virtuell dator med oanvänd kapacitet påverkar dess orkestrering. Orkestrering är processen för att hantera en borttagning och beskrivs senare i den här artikeln. Borttagningsprinciperna är Stop/Deallocate-principen och Delete-principen.

Stop/Deallocate-princip: Principen Stoppa/frigöra är idealisk när arbetsbelastningen kan vänta på versionskapacitet på samma plats och vm-typ. Principen Stop/Deallocate stoppar den virtuella datorn och avslutar lånet med den underliggande maskinvaran. Att stoppa och frigöra en virtuell dator för oanvänd kapacitet är detsamma som att stoppa och frigöra en vanlig virtuell dator. Den virtuella datorn är fortfarande tillgänglig i Azure och du kan starta om samma virtuella dator senare. Den virtuella datorn förlorar beräkningskapacitet och icke-statiska IP-adresser med principen Stop/Deallocate. De virtuella datordatadiskarna finns dock kvar och fortsätter att debiteras. Den virtuella datorn upptar också kärnor i prenumerationen. Virtuella datorer kan inte flyttas från sin region eller zon även när de stoppas eller frigörs. Mer information finns i Power-tillstånd och fakturering.

Ta bort princip: Använd principen Ta bort om arbetsbelastningen kan ändra plats eller vm-storlek. Om du ändrar plats- eller VM-storlek kan den virtuella datorn distribueras snabbare. Principen Ta bort tar bort den virtuella datorn och alla datadiskar. Den virtuella datorn upptar inte kärnor i prenumerationer. Mer information finns i Borttagningsprincip.

Design för flexibel orkestrering

Orkestrering är processen att ersätta en virtuell dator med oanvänd kapacitet efter en borttagning. Det är grunden för att skapa en tillförlitligt avbrottsbar arbetsbelastning. Ett bra orkestreringssystem har inbyggd flexibilitet. Flexibilitet innebär att du utformar orkestreringen så att den har alternativ, använder flera VM-storlekar, distribuerar till olika regioner, har borttagningsmedvetenhet och tar hänsyn till olika borttagningsscenarier för att förbättra arbetsbelastningens tillförlitlighet och hastighet.

Design för hastighet

För en arbetsbelastning som körs på virtuella datorer med oanvänd kapacitet är beräkningskapacitet avgörande. På grund av risken för borttagning ser du till att du förstår den allokerade beräkningstiden så att du kan fatta välgrundade designbeslut som prioriterar arbetsbelastningshastigheten. I allmänhet bör du optimera den beräkningstid som du har. Skapa en VM-avbildning som har all nödvändig programvara förinstallerad. Förinstallerad programvara hjälper till att minimera tiden mellan borttagning och ett fullt fungerande program. Undvik att använda beräkningstid för processer som inte bidrar till arbetsbelastningssyftet. En arbetsbelastning för dataanalys bör till exempel fokusera större delen av sin beräkningstid på databearbetning och så lite tid som möjligt på insamling av borttagningsmetadata. Eliminera nonessential-processer från ditt program.

Använda flera VM-storlekar och platser

Skapa en orkestrering för att använda flera typer och storlekar av virtuella datorer för att öka flexibiliteten. Målet är att ge orkestreringsalternativen för att ersätta en borttagen virtuell dator. Azure har olika typer och storlekar på virtuella datorer som tillhandahåller liknande funktioner för ungefär samma pris. Filtrera efter de minsta vCPU:erna eller kärnorna, det minsta RAM-minnet för virtuella datorer och det högsta priset. Den här processen hjälper dig att hitta flera virtuella datorer som passar i din budget och har tillräckligt med ström för att köra din arbetsbelastning.

Varje typ av virtuell dator har en borttagningshastighet som uttrycks som ett procentintervall, till exempel 0%-5%, 5%-10%, 10%-15%, 15%-20%eller 20+%. Borttagningsfrekvensen kan variera mellan regioner. Du kan hitta en bättre borttagningshastighet för samma typ av virtuell dator i en annan region. Du hittar borttagningshastigheterna för varje typ av virtuell dator i portalen under fliken Grundläggande. Bredvid Storlekväljer du Visa prishistorik eller Visa alla storlekar. Du kan också programmatiskt hämta vm-data för oanvänd kapacitet med hjälp av Azure Resource Graph.

I orkestreringssystemet bör du överväga att använda funktionen för platsplaceringspoäng för att utvärdera sannolikheten för lyckade distributioner av enskilda platser.

Mer information finns i följande resurser:

Använd den mest flexibla borttagningsprincipen

Borttagningsprincipen för den avlägsnade virtuella datorn för oanvänd kapacitet påverkar ersättningsprocessen. Till exempel är en borttagningsprincip mer flexibel än en Stop/Deallocate-princip.

  • Överväg att ta bort principen först: Använd en borttagningsprincip om din arbetsbelastning kan hantera den. Borttagning gör att orkestreringen kan distribuera virtuella datorer med ersättningsplatsen till nya zoner och regioner. Den här distributionsflexinstansen kan hjälpa din arbetsbelastning att hitta extra beräkningskapacitet snabbare än en stoppad eller frigjord virtuell dator. Stoppade eller frigjorda virtuella datorer måste vänta på extra beräkningskapacitet i samma zon som de skapades i. För principen Ta bort behöver du en extern process för att övervaka borttagning och orkestrering av distributioner till olika regioner, använda olika VM-SKU:er eller båda.

  • Förstå principen Stoppa/frigör: Principen Stoppa/frigör har mindre flexibilitet än principen Ta bort. De virtuella datorerna för oanvänd kapacitet måste vara kvar i samma region och zon. Du kan inte flytta en stoppad eller frigjord virtuell dator till en annan plats. Eftersom de virtuella datorerna har en fast plats behöver du något på plats för att omallokera den virtuella datorn när beräkningskapaciteten blir tillgänglig. Det finns inget sätt att förutsäga tillgängligheten för beräkningskapacitet. Du bör därför använda en automatiserad schemapipeline för att försöka distribuera om efter en borttagning. En borttagning bör utlösa schemapipelinen och omdistributionsförsöken bör kontinuerligt söka efter beräkningskapacitet tills den blir tillgänglig.

Politik När principen ska användas
Ta bort princip – Tillfälliga beräkningar och data

– Vill inte betala för datadiskar

– Minimal budget
Stoppa/frigöra princip – Behöver en specifik VM-storlek

– Det går inte att ändra plats

– Lång programinstallationsprocess

- Obestämd väntetid

– Inte enbart på grund av kostnadsbesparingar

Övervaka kontinuerligt för borttagning

Övervakning är nyckeln till arbetsbelastningens tillförlitlighet på virtuella datorer med oanvänd kapacitet. Virtuella datorer med oanvänd kapacitet har inget serviceavtal när de har skapats och kan tas bort när som helst. Det bästa sättet att förbättra arbetsbelastningens tillförlitlighet på virtuella datorer på plats är att förutse när de kommer att avlägsnas. Om du har den här informationen kan du försöka utföra en korrekt avstängning av arbetsbelastningen och utlösa automatisering för att orkestrera ersättningen.

  • Använd schemalagda händelser: Använda tjänsten Schemalagda händelser för varje virtuell dator. Azure skickar signaler till virtuella datorer när infrastrukturunderhållet kommer att påverka dem. Avhysningar kvalificerar sig som infrastrukturunderhåll. Azure skickar ut Preempt-signalen till alla virtuella datorer minst 30 sekunder innan de avlägsnas. Med tjänsten Schemalagda händelser kan du samla in den här Preempt signalen genom att fråga en slutpunkt på den statiska, icke-utfällbara IP-adressen 169.254.169.254.

  • Använd vanliga frågor: Köra frågor mot slutpunkten Schemalagda händelser tillräckligt ofta för att orkestrera en graciös avstängning. Du kan köra frågor mot slutpunkten Schemalagda händelser upp till varje sekund, men en ensekundersfrekvens kanske inte behövs för alla användningsfall. Dessa frågor måste komma från ett program som körs på den virtuella datorn för oanvänd kapacitet. Frågan kan inte komma från en extern källa. Därför förbrukar frågorna vm-beräkningskapacitet och stjäl bearbetningskraft från huvudarbetsbelastningen. Du måste balansera dessa konkurrerande prioriteringar för att uppfylla din specifika situation.

  • Automatisera orkestrering: När du har samlat in Preempt signalen bör orkestreringen agera på den signalen. Med tanke på tidsbegränsningarna bör den Preempt signalen försöka stänga av din arbetsbelastning på ett korrekt sätt och starta en automatiserad process som ersätter den virtuella datorn med oanvänd kapacitet. Mer information finns i följande resurser:

Skapa ett distributionssystem

Orkestreringen behöver en automatiserad pipeline för att distribuera nya virtuella datorer med oanvänd kapacitet efter borttagningen. Pipelinen bör köras utanför den avbrottsbara arbetsbelastningen för att säkerställa beständighet. Distributionspipelinen bör fungera enligt den borttagningsprincip som du väljer för dina virtuella datorer för oanvänd kapacitet.

För en borttagningsprincip rekommenderar vi att du skapar en pipeline som använder olika VM-storlekar och distribuerar till olika regioner. För en Stop/Deallocate-princip behöver distributionspipelinen två distinkta åtgärder. För att kunna skapa en virtuell dator måste pipelinen distribuera rätt storlek på virtuella datorer till rätt plats. För en borttagen virtuell dator måste pipelinen försöka starta om den virtuella datorn tills den fungerar. En kombination av Azure Monitor-aviseringar och Azure-funktioner är ett sätt att automatisera ett distributionssystem. Pipelinen kan använda bicep-mallar. De är deklarativa och idempotent och representerar bästa praxis för infrastrukturdistribution.

Förbered för omedelbar borttagning

Det är möjligt för Azure att ta bort en virtuell dator med oanvänd kapacitet så snart du skapar den och innan arbetsbelastningen körs. I vissa fall kan det finnas tillräckligt med kapacitet för att skapa en virtuell dator med oanvänd kapacitet, men den håller inte. Virtuella datorer med oanvänd kapacitet har inga tillgänglighetsgarantier, eller serviceavtal, när de har skapats. Orkestreringen måste ta hänsyn till omedelbara borttagningar. Den Preempt signalen ger minst 30 sekunders förvarning om borttagningen.

Införliva hälsokontroller för virtuella datorer i orkestreringen för att förbereda för omedelbara borttagningar. Orkestrering för omedelbara borttagningar kan inte bero på schemalagda händelser Preempt signal. Endast själva den virtuella datorn kan köra frågor mot Preempt-signalen och det finns inte tillräckligt med tid för att starta ett program, köra frågor mot slutpunkten Schemalagda händelser och stänga av den på ett korrekt sätt. Hälsokontrollen måste därför finnas utanför arbetsbelastningsmiljön. Hälsokontrollerna måste övervaka statusen för den virtuella datorn för oanvänd kapacitet och starta distributionspipelinen för att ersätta den virtuella datorn med oanvänd kapacitet när statusen ändras till frigöra eller stoppa.

Planera för flera samtidiga borttagningar

Om du kör ett kluster med virtuella datorer med oanvänd kapacitet skapar du arbetsbelastningen för att klara flera samtidiga borttagningar. Flera virtuella datorer med oanvänd kapacitet i arbetsbelastningen kan tas bort samtidigt. En samtidig borttagning av flera virtuella datorer kan påverka programmets dataflöde. För att förhindra den här situationen bör distributionspipelinen kunna samla in signaler från flera virtuella datorer och distribuera flera ersättande virtuella datorer samtidigt.

Design för en graciös avstängning

Avstängningsprocessen för den virtuella datorn bör vara mindre än 30 sekunder och tillåta att den virtuella datorn stängs av innan en borttagning. Hur lång tid avstängningen ska ta beror på hur ofta arbetsbelastningen frågar slutpunkten Schemalagda händelser. Ju oftare du frågar slutpunkten, desto längre kan avstängningsprocessen ta. Avstängningsprocessen bör frigöra resurser, tömma anslutningar och rensa händelseloggar. Du bör regelbundet skapa och spara kontrollpunkter för att behålla kontexten och skapa en effektivare återställningsstrategi. Kontrollpunkten är bara information om vilka processer eller transaktioner som nästa virtuella dator behöver starta på. De bör ange om den virtuella datorn ska återupptas där den tidigare virtuella datorn slutade eller om den nya virtuella datorn ska återställa ändringarna och starta hela processen igen. Lagra kontrollpunkterna utanför vm-miljön för oanvänd kapacitet, till exempel i ett lagringskonto.

Testa orkestreringen

Simulera borttagningshändelser för att testa orkestrering i utvecklings-/testmiljöer. Mer information finns i Simulera borttagning.

Utforma en idempotent arbetsbelastning

Vi rekommenderar att du utformar en idempotent arbetsbelastning. Resultatet av bearbetningen av en händelse mer än en gång bör vara detsamma som att bearbeta den en gång. Avhysningar kan leda till framtvingade avstängningar, trots försök att säkerställa graciösa avstängningar. Framtvingade avstängningar kan avsluta processer innan de slutförs. Idempotenta arbetsbelastningar kan ta emot samma meddelande mer än en gång utan att ändra resultatet. Mer information finns i Idempotens.

Använda en programuppvärmningsperiod

De flesta avbrottsbara arbetsbelastningar kör program. Program behöver tid att installera och starta. De behöver också tid för att ansluta till extern lagring och samla in information från kontrollpunkter. Ha en programuppvärmningsperiod innan du tillåter att den börjar bearbetas. Under uppvärmningsperioden bör programmet starta, upprätta anslutningar och förbereda för att bidra. Tillåt endast att ett program börjar bearbeta data när du har verifierat programmets hälsotillstånd.

Diagram över arbetsbelastningens livscykel med en programuppvärmningsperiod.

Konfigurera användartilldelade hanterade identiteter

Tilldela användartilldelade hanterade identiteter för att effektivisera autentiserings- och auktoriseringsprocessen. Med användartilldelade hanterade identiteter kan du undvika att ange autentiseringsuppgifter i kod och inte är knutna till en enda resurs som systemtilldelade hanterade identiteter. De användartilldelade hanterade identiteterna innehåller behörigheter och åtkomsttoken från Microsoft Entra-ID som kan återanvändas och tilldelas för att upptäcka virtuella datorer under orkestreringen. Tokenkonsekvens mellan virtuella datorer med oanvänd kapacitet hjälper till att effektivisera orkestreringen och förenklar åtkomsten till de arbetsbelastningsresurser som de virtuella datorerna för oanvänd kapacitet har.

Om du använder systemtilldelade hanterade identiteter kan en ny virtuell dator för oanvänd kapacitet få en annan åtkomsttoken från Microsoft Entra-ID. Om du behöver använda systemtilldelade hanterade identiteter gör du arbetsbelastningarna motståndskraftiga mot 403 Forbidden Error svar. Orkestreringen måste hämta token från Microsoft Entra-ID med rätt behörigheter. Mer information finns i Hanterade identiteter.

Exempelscenario

Exempelscenariot distribuerar ett köbearbetningsprogram som kvalificerar sig som en avbrottsbar arbetsbelastning. Skripten i scenariot fungerar som exempel. Scenariot vägleder dig genom en manuell push-överföring en gång för att distribuera resurser. Den här implementeringen har ingen distributionspipeline. En distributionspipeline är dock nödvändig för att automatisera orkestreringsprocessen. Följande diagram visar arkitekturen i exempelscenariot.

diagram som visar exempelscenarioarkitekturen.

Ladda ned en Visio-fil av den här arkitekturen.

Följande arbetsflöde motsvarar föregående diagram:

  1. vm-programdefinition: Vm-programdefinitionen skapas i Azure-beräkningsgalleriet. Den definierar programnamn, plats, operativsystem och metadata. Programversionen är en numrerad version av den virtuella datorns programdefinition. Programversionen representerar det virtuella datorprogrammet. Den måste finnas i samma region som den virtuella datorn för oanvänd kapacitet. Programversionen länkar till källprogrampaketet i lagringskontot.

  2. Storage-konto: Lagringskontot lagrar källprogrampaketet. I den här arkitekturen är det en komprimerad tjärfil med namnet worker-0.1.0.tar.gz. Den innehåller två filer. En fil är det orchestrate.sh bash-skriptet som installerar .NET-arbetsprogrammet.

  3. VM för oanvänd kapacitet: Den virtuella datorn för oanvänd kapacitet distribueras. Den måste finnas i samma region som programversionen. Den laddar ned worker-0.1.0.tar.gz till den virtuella datorn efter distributionen. bicep-mallen distribuerar en Ubuntu-avbildning på en virtuell standardfamiljedator. De här konfigurationerna uppfyller programmets behov och är inte allmänna rekommendationer för dina program.

  4. Storage-kö: Den andra tjänsten som körs i .NET-arbetaren innehåller meddelandekölogik. Microsoft Entra-ID ger den virtuella datorn åtkomst till lagringskön i Azure Queue Storage med en användartilldelad identitet med hjälp av rollbaserad åtkomstkontroll.

  5. .NET-arbetsprogram: Skriptet orchestrate.sh installerar ett .NET-arbetsprogram som kör två bakgrundstjänster. Den första tjänsten frågar slutpunkten Schemalagda händelser, letar efter den Preempt signalen och skickar den här signalen till den andra tjänsten. Den andra tjänsten bearbetar meddelanden från lagringskön och lyssnar efter den Preempt signalen från den första tjänsten. När den andra tjänsten tar emot signalen avbryter den lagringsköbearbetningen och börjar stängas av.

  6. Slutpunkt för schemalagda frågehändelser: en API-begäran skickas till en statisk ip-adress som inte kan skickas 169.254.169.254. API-begäran frågar slutpunkten Schemalagda händelser för infrastrukturunderhållssignaler.

  7. Application Insights: Arkitekturen använder Endast Application Insights i utbildningssyfte. Det är inte en viktig komponent i dirigering av avbrottsbar arbetsbelastning, men gör att du kan verifiera telemetrin från .NET-arbetsprogrammet. .NET-arbetsprogrammet skickar telemetri till Application Insights. Mer information finns i Aktivera livemått från .NET-programmet.

Distribuera det här scenariot

GitHub-logotypen Det finns en GitHub-lagringsplats som heter avbrottsbar arbetsbelastning på plats som har mallar, skript och stegvisa instruktioner för att distribuera den här arkitekturen.

Nästa steg