Bästa praxis för Azure Batch

  • Artikel
  • 16 minuter för att läsa

I den här artikeln beskrivs metodtips och användbara tips för att Azure Batch tjänsten på ett effektivt sätt. De här tipsen kan hjälpa dig att förbättra prestanda och undvika fallgropar i dina Batch-lösningar.

Tips

Vägledning om säkerhet i Azure Batch finns i Metodtips för batchsäkerhet och efterlevnad.

Pooler

Pooler är beräkningsresurser för att köra jobb i Batch-tjänsten. Följande avsnitt innehåller rekommendationer för att arbeta med Batch-pooler.

Poolkonfiguration och namngivning

  • Poolallokeringsläge: När du skapar ett Batch-konto kan du välja mellan två poolallokeringslägen: Batch-tjänsten eller användarprenumerationen. I de flesta fall bör du använda standardläget för Batch-tjänsten, där pooler allokeras i bakgrunden i Batch-hanterade prenumerationer. I det alternativa användarprenumerationsläget skapas virtuella Batch-datorer och andra resurser direkt i din prenumeration när en pool skapas. Användarkonton används främst för att möjliggöra en liten men viktig delmängd av scenarier. Mer information finns i Ytterligare konfiguration för användarprenumerationsläge.

  • "virtualMachineConfiguration" eller "cloudServiceConfiguration": Du kan för närvarande skapa pooler med någon av konfigurationerna, men nya pooler bör konfigureras med "virtualMachineConfiguration" och inte "cloudServiceConfiguration". Alla aktuella och nya Batch-funktioner kommer att stödjas av konfigurationspooler för virtuella datorer. Cloud Services konfigurationspooler har inte stöd för alla funktioner och inga nya funktioner planeras. Du kommer inte att kunna skapa nya "cloudServiceConfiguration"-pooler eller lägga till nya noder i befintliga pooler efter den 29 februari 2024. Mer information finns i Migrera Batch-poolkonfiguration från Cloud Services till virtuell dator.

  • Överväganden för jobb- och aktivitetskörning: Om du har jobb som främst består av kortvariga aktiviteter och det förväntade totala antalet aktiviteter är små, så att den totala förväntade körningstiden för jobbet inte är lång, ska du inte allokera en ny pool för varje jobb. Allokeringstiden för noderna minskar körningstiden för jobbet.

  • Flera beräkningsnoder: Enskilda noder är inte garanterade att alltid vara tillgängliga. Även om det är ovanligt kan maskinvarufel, uppdateringar av operativsystemet och en mängd andra problem göra att enskilda noder är offline. Om Batch-arbetsbelastningen kräver deterministisk och garanterad förlopp bör du allokera pooler med flera noder.

  • Avbildningar med nära förestående EOL-datum (end-of-life): Vi rekommenderar starkt att du undviker avbildningar med nära förestående EOL-datum (Batch Support End of Life). Dessa datum kan identifieras via ListSupportedImages API:et, PowerShelleller Azure CLI. Det är ditt ansvar att regelbundet uppdatera din vy över de EOL-datum som är relevanta för dina pooler och migrera dina arbetsbelastningar innan EOL-datumet inträffar. Om du använder en anpassad avbildning med en angiven nodagent ska du se till att du följer Batch-stöd för slutdatum för avbildningen som den anpassade avbildningen härleds eller justeras med.

  • Unika resursnamn: Batch-resurser (jobb, pooler osv.) kommer ofta och går över tid. Du kan till exempel skapa en pool på måndag, ta bort den på tisdag och sedan skapa en till liknande pool på torsdag. Varje ny resurs som du skapar ska få ett unikt namn som du inte har använt tidigare. Du kan göra detta genom att använda ett GUID (antingen som hela resursnamnet eller som en del av det) eller genom att bädda in datum och tid då resursen skapades i resursnamnet. Batch stöder DisplayName, som kan ge en resurs ett mer lättläst namn även om det faktiska resurs-ID:t är något som inte är användarvänligt för människor. Genom att använda unika namn blir det enklare för dig att särskilja vilken viss resurs som gjorde något i loggar och mått. Det tar också bort tvetydigheten om du skulle behöva skapa ett supportfall för en resurs.

  • Kontinuitet vid underhåll och fel i pooler: Det är bäst att dina jobb använder pooler dynamiskt. Om jobben använder samma pool för allt finns det en risk att jobben inte körs om något går fel med poolen. Detta är särskilt viktigt för tidskänsliga arbetsbelastningar. Du kan åtgärda detta genom att välja eller skapa en pool dynamiskt när du schemalägger varje jobb, eller så kan du åsidosätta poolnamnet så att du kan kringgå en pool med feltillstånd.

  • Affärskontinuhet vid underhåll och fel i pooler: Det finns många orsaker till varför en pool kanske inte växer till den storlek du önskar, till exempel interna fel eller kapacitetsbegränsningar. Se till att du kan återrikta jobb till en annan pool (eventuellt med en annan VM-storlek; Batch stöder detta via UpdateJob) om det behövs. Undvik att förlita dig på ett statiskt pool-ID med förväntningen att det aldrig tas bort och aldrig ändras.

Livslängd och fakturering för pooler

Poolens livslängd kan variera beroende på allokeringsmetoden och de alternativ som tillämpas på poolkonfigurationen. Pooler kan ha en godtycklig livslängd och ett varierande antal beräkningsnoder vid en valfri tidpunkt. Det är ditt ansvar att uttryckligen hantera beräkningsnoderna i poolen eller via funktioner som tillhandahålls av tjänsten (autoskalning eller autopool).

  • Pool-freshness: Ändra storlek på dina pooler till noll varannan månad för att säkerställa att du får de senaste uppdateringarna för nodagenten och felkorrigeringar. Din pool får inte uppdateringar av nodagenten om den inte har återskapats (eller om storleken har ändrats till 0 beräkningsnoder). Innan du återskapar eller ändrar storlek på poolen bör du ladda ned eventuella nodagentloggar för felsökning, enligt vad som beskrivs i avsnittet Noder.

  • Poolpool: Undvik att ta bort och återskapa pooler dagligen. Skapa i stället en ny pool och uppdatera sedan dina befintliga jobb så att de pekar på den nya poolen. När alla uppgifter har flyttats till den nya poolen tar du bort den gamla poolen.

  • Pooleffektivitet och fakturering: Själva Batch medför inga extra avgifter, men du debiteras för de beräkningsresurser som används. Du debiteras för varje beräkningsnod i poolen, oavsett i vilket tillstånd den finns. Detta inkluderar eventuella avgifter som krävs för att noden ska köras, till exempel kostnader för lagring och nätverk. Mer information finns i Kostnadsanalys och budgetar för Azure Batch.

  • Tillfälliga OS-diskar: Konfigurationspooler för virtuella datorer kan använda tillfälliga OS-diskar, som skapar OS-disken på VM-cachen eller tillfällig SSD, för att undvika extra kostnader associerade med hanterade diskar.

Poolallokeringsfel

Poolallokeringsfel kan inträffa när som helst under den första allokeringen eller efterföljande storleksändringar. Detta kan bero på tillfällig kapacitetsutmattning i en region eller fel i andra Azure-tjänster som Batch förlitar sig på. Din kärnkvot är inte en garanti, utan snarare en gräns.

Oplanerat stillestånd

Det är möjligt för Batch-pooler att uppleva avbrottshändelser i Azure. Tänk på detta när du planerar och utvecklar ditt scenario eller arbetsflöde för Batch. Om noderna misslyckas försöker Batch automatiskt återställa dessa beräkningsnoder åt dig. Detta kan utlösa omplanering av alla aktiviteter som körs på noden som återställs. Mer information om avbrutna uppgifter finns i Designing for retries(Utforma för återförsök).

Anpassade avbildningspooler

När du skapar en Azure Batch-pool med vm-konfigurationen anger du en VM-avbildning som tillhandahåller operativsystemet för varje beräkningsnod i poolen. Du kan skapa poolen med en Azure Marketplace eller skapa en anpassad avbildning med en Azure Compute galleriavbildning. Du kan också använda en hanterad avbildning för att skapa en anpassad avbildningspool, men vi rekommenderar att du skapar anpassade avbildningar med hjälp Azure Compute-galleriet när det är möjligt. Med hjälp Azure Compute Gallery kan du etablera pooler snabbare, skala större mängder virtuella datorer och förbättra tillförlitligheten när du etablerar virtuella datorer.

Avbildningar från tredje part

Pooler kan skapas med avbildningar från tredje part som publicerats för Azure Marketplace. Med Batch-konton i användarprenumerationsläge kan du se felet "Allokeringen misslyckades på grund av kontroll av köpberättigande på Marketplace" när du skapar en pool med vissa avbildningar från tredje part. Lös problemet genom att acceptera de villkor som angetts av utgivaren av avbildningen. Du kan göra det med hjälp Azure PowerShell eller Azure CLI.

Beroende för Azure-region

Du bör inte förlita dig på en enda Azure-region om du har en tidskänslig arbetsbelastning eller produktionsarbetsbelastning. Även om det är ovanligt finns det problem som kan påverka en hel region. Om bearbetningen till exempel måste starta vid en viss tidpunkt bör du överväga att skala upp poolen i din primära region långt före din starttid. Om poolskalan misslyckas kan du gå tillbaka till att skala upp en pool i en säkerhetskopieringsregion (eller regioner).

Pooler över flera konton i olika regioner ger en klar och lättillgänglig säkerhetskopiering om något går fel med en annan pool. Mer information finns i Utforma ditt program för hög tillgänglighet.

Jobb

Ett jobb är en container som utformats för att innehålla hundratals, tusentals eller till och med miljontals uppgifter. Följ dessa riktlinjer när du skapar jobb.

Färre jobb, fler uppgifter

Det är ineffektivt att använda ett jobb för att köra en enskild uppgift. Det är till exempel effektivare att använda ett enda jobb som innehåller 1 000 aktiviteter i stället för att skapa 100 jobb som innehåller 10 aktiviteter vardera. Att köra 1 000 jobb, var och en med en enda uppgift, skulle vara den minst effektiva, långsammaste och dyraste metoden.

Därför bör du undvika att utforma en Batch-lösning som kräver tusentals aktiva jobb samtidigt. Det finns ingen kvot för aktiviteter, så om du kör många aktiviteter under så få jobb som möjligt används jobb- och jobbschemakvoterna effektivt.

Jobbets livslängd

Ett Batch-jobb har obegränsad livslängd tills det tas bort från systemet. Dess tillstånd anger om den kan acceptera fler uppgifter för schemaläggning eller inte.

Ett jobb flyttas inte automatiskt till slutfört tillstånd om det inte uttryckligen avslutas. Detta kan utlösas automatiskt via egenskapen onAllTasksComplete eller maxWallClockTime.

Det finns ett aktivt standardjobb och en kvot för jobbschemat. Jobb och jobbscheman i slutfört tillstånd räknas inte mot den här kvoten.

Uppgifter

Uppgifter är enskilda arbetsenheter som utgör ett jobb. Aktiviteter skickas av användaren och schemaläggs av Batch på för beräkningsnoder. Följande avsnitt innehåller förslag på hur du utformar dina uppgifter för att hantera problem och utföra effektivt.

Spara uppgiftsdata

Beräkningsnoder är tillfälliga. Batch-funktioner som autopool och autoskalning kan göra det enkelt för noder att försvinna. När noder lämnar en pool (på grund av en storleksändring eller en pool borttagning) tas även alla filer på dessa noder bort. Därför bör en uppgift flytta sina utdata från noden som den körs på och till ett varaktigt lager innan den slutförs. Om en aktivitet misslyckas bör den på samma sätt flytta de loggar som krävs för att diagnostisera felet till ett varaktigt lager.

Batch har integrerat stöd Azure Storage att ladda upp data via OutputFiles,samt en mängd olika delade filsystem, eller så kan du utföra uppladdningen själv i dina uppgifter.

Hantera aktivitetens livslängd

Ta bort aktiviteter när de inte längre behövs eller ange en retentionTime-uppgiftsbegränsning. Om en retentionTime har angetts rensar Batch automatiskt det diskutrymme som används av aktiviteten när retentionTime upphör att gälla.

Att ta bort uppgifter åstadkommer två saker. Det säkerställer att du inte har någon uppgiftsbygge i jobbet, vilket kan göra det svårare att fråga efter/hitta den uppgift som du är intresserad av (eftersom du måste filtrera igenom slutförda uppgifter). Den rensar också motsvarande uppgiftsdata på noden (förutsatt att retentionTime inte redan har använts). Detta säkerställer att noderna inte fylls med uppgiftsdata och får slut på diskutrymme.

Skicka in ett stort antal uppgifter i samlingen

Uppgifter kan skickas individuellt eller i samlingar. Skicka uppgifter i samlingar på upp till 100 i taget när du gör massinskickning av uppgifter för att minska omkostnaderna och sändningstiden.

Ange maximalt antal aktiviteter per nod på lämpligt sätt

Batch stöder överprenumereringar på noder (körning av fler aktiviteter än en nod har kärnor). Det är upp till dig att se till att dina uppgifter "passar" i noderna i poolen. Du kan till exempel ha en försämrad upplevelse om du försöker schemalägga åtta aktiviteter som var och en förbrukar 25 % CPU-användning på en nod (i en pool med taskSlotsPerNode = 8 ).

Designa för återförsök och omkörning

Aktiviteter kan automatiskt utföras av Batch. Det finns två typer av återförsök: användarkontrollerade och interna. Användarkontrollerade återförsök anges av aktivitetens maxTaskRetryCount. När ett program som anges i aktiviteten avslutas med en slutkod som inte är noll, försöker aktiviteten igen upp till värdet för maxTaskRetryCount .

Även om det är ovanligt kan ett nytt uppgiftsfel göras internt på grund av fel på beräkningsnoden, till exempel att det inte går att uppdatera det interna tillståndet eller ett fel på noden medan aktiviteten körs. Om möjligt kommer uppgiften att försökas igen på samma beräkningsnod, om möjligt, upp till en intern gräns innan du ger upp uppgiften och skjuter upp uppgiften så att den omplaneras av Batch, eventuellt på en annan beräkningsnod.

Det finns inga designskillnader när du kör dina uppgifter på dedikerade noder eller noder med låg prioritet. Oavsett om en uppgift avbryts när den körs på en nod med låg prioritet eller avbryts på grund av ett fel på en dedikerad nod, minimeras båda situationerna genom att uppgiften utformas för att hantera fel.

Skapa beständiga uppgifter

Uppgifter bör utformas för att klara fel och hantera återförsök. Detta är särskilt viktigt för långvariga uppgifter. Det gör du genom att se till att aktiviteterna genererar samma enskilda resultat även om de körs mer än en gång. Ett sätt att uppnå detta är att göra dina uppgifter "målsökning". Ett annat sätt är att se till att dina aktiviteter är idempotenta (aktiviteterna får samma resultat oavsett hur många gånger de körs).

Ett vanligt exempel är en uppgift att kopiera filer till en beräkningsnod. En enkel metod är en uppgift som kopierar alla angivna filer varje gång den körs, vilket är ineffektivt och inte har skapats för att klara fel. Skapa i stället en uppgift för att se till att filerna finns på beräkningsnoden. en uppgift som inte omkopiera filer som redan finns. På så sätt hämtas aktiviteten där den slutade om den avbröts.

Undvik kort körningstid

Uppgifter som bara körs i en till två sekunder är inte idealiska. Försök att utföra en betydande mängd arbete i en enskild uppgift (minst 10 sekunder, upp till timmar eller dagar). Om varje uppgift körs i en minut (eller mer) är schemaläggningskostnad som en bråkdel av den totala beräkningstiden liten.

Använda poolomfång för korta uppgifter på Windows noder

När du schemalägger en aktivitet på Batch-noder kan du välja om du vill köra den med uppgiftsomfång eller poolomfång. Om aktiviteten bara körs under en kort tid kan uppgiftsomfånget vara ineffektivt på grund av de resurser som behövs för att skapa det automatiska användarkontot för uppgiften. För större effektivitet bör du överväga att ställa in dessa uppgifter på poolomfång. Mer information finns i Köra en uppgift som en automatisk användare med poolomfånget.

Noder

En beräkningsnod är en virtuell Azure-dator (VM) eller en virtuell molntjänstdator som är dedikerad för bearbetning av en del av programmets arbetsbelastning. Följ dessa riktlinjer när du arbetar med noder.

Idempotenta startuppgifter

Precis som med andra aktiviteter ska nodstartaktiviteten vara idempotent, eftersom den kommer att köras igen varje gång noden startas. En idempotent uppgift är helt enkelt en som ger ett konsekvent resultat när den körs flera gånger.

Isolerade noder

Överväg att använda isolerade VM-storlekar för arbetsbelastningar med efterlevnads- eller regelkrav. Isolerade storlekar som stöds i konfigurationsläget för virtuella datorer Standard_E80ids_v4 är , , , , och Standard_M128ms Standard_F72s_v2 Standard_G5 Standard_GS5 Standard_E64i_v3 . Mer information om isolerade VM-storlekar finns i Isolering av virtuella datorer i Azure.

Hantera långvariga tjänster via gränssnittet för operativsystemtjänster

Ibland behöver du köra en annan agent tillsammans med Batch-agenten i noden. Du kanske till exempel vill samla in data från noden och rapportera dem. Vi rekommenderar att dessa agenter distribueras som OPERATIVSYSTEMtjänster, till exempel en Windows tjänst eller en systemd Linux-tjänst.

När dessa tjänster körs får de inte ta fillås på några filer i Batch-hanterade kataloger på noden, eftersom Batch annars inte kan ta bort dessa kataloger på grund av fillåsen. Om du till exempel installerar en Windows-tjänst i en startaktivitet, i stället för att starta tjänsten direkt från arbetskatalogen för startaktiviteten, kopierar du filerna någon annanstans (eller om filerna finns hoppar du bara över kopian). Installera sedan tjänsten från den platsen. När Batch kör startaktiviteten igen tar den bort arbetskatalogen för startaktiviteten och skapar den igen. Detta fungerar eftersom tjänsten har fillås i den andra katalogen, inte arbetskatalogen för startaktiviteten.

Undvik att skapa katalogövergångar i Windows

Kataloglänkar, som ibland kallas för kataloghårdlänkar, är svåra att hantera under rensning av uppgifter och jobb. Använd symlinks (mjuka länkar) i stället för hårda länkar.

Samla in Batch-agentloggar

Om du upptäcker ett problem som rör beteendet för en nod eller aktiviteter som körs på en nod samlar du in Batch-agentloggarna innan du tar bort noderna i fråga. Batch-agentloggarna kan samlas in med hjälp Upload Batch-tjänstens logg-API. Dessa loggar kan tillhandahållas som en del av en supportbiljett till Microsoft och hjälper till med felsökning och lösning av problem.

Hantera OS-uppgraderingar

För Batch-konton i användarprenumerationsläge kan automatiserade OS-uppgraderingar avbryta aktivitetsförloppet, särskilt om aktiviteterna körs länge. Att skapa idempotenta uppgifter kan bidra till att minska fel som orsakas av dessa avbrott. Vi rekommenderar också att du schemalägger uppgraderingar av OS-avbildningar för tider när aktiviteter inte förväntas köra.

För Windows-pooler enableAutomaticUpdates är inställt true på som standard. Att tillåta automatiska uppdateringar rekommenderas, men du kan ange det här värdet till om du behöver se till att en false OS-uppdatering inte sker oväntat.

Isoleringssäkerhet

Om scenariot kräver isolering av jobb från varandra kan du isolera dem genom att ha dem i separata pooler. En pool är säkerhetsisoleringsgränsen i Batch och som standard är två pooler inte synliga eller kan kommunicera med varandra. Undvik att använda separata Batch-konton som ett sätt att isolera.

Anslutning

Läs följande riktlinjer för anslutning i dina Batch-lösningar.

Nätverkssäkerhetsgrupper (NSG: er) och användardefinierade vägar (UDR: er)

När du etablerarBatch-pooler i ett virtuellt nätverk måste du noggrant följa riktlinjerna för användning av BatchNodeManagement tjänsttaggen, portar, protokoll och riktning för regeln. Användning av tjänsttaggen rekommenderas starkt i stället för att använda de underliggande IP-adresserna för Batch-tjänsten. Det beror på att IP-adresserna kan ändras med tiden. Direkt användning av IP-adresser för Batch-tjänsten kan orsaka instabilitet, avbrott eller avbrott för dina Batch-pooler.

För användardefinierade vägar (UDR) kontrollerar du att du har en process för att uppdatera Batch-tjänstens IP-adresser regelbundet i din vägtabell, eftersom dessa adresser ändras med tiden. Information om hur du hämtar listan över BATCH-tjänstens IP-adresser finns i Tjänsttaggar lokalt. IP-adresserna för Batch-tjänsten associeras med BatchNodeManagement tjänsttaggen (eller den regionala variant som matchar din Batch-kontoregion).

Respektera DNS

Se till att dina system respekterar DNS Time-to-Live (TTL) för Batch-kontots tjänst-URL. Kontrollera dessutom att Batch-tjänstklienterna och andra anslutningsmekanismer till Batch-tjänsten inte förlitar sig på IP-adresser (eller skapa en pool med statiska offentliga IP-adresser enligt beskrivningen nedan).

Om dina begäranden får HTTP-svar på 5xx-nivå och det finns ett "Anslutning: stäng"-huvud i svaret bör Batch-tjänstklienten följa rekommendationen genom att stänga den befintliga anslutningen, matcha OM DNS för Batch-kontots tjänst-URL och försöka följa begäranden på en ny anslutning.

Försök att göra om begäranden automatiskt

Se till att Batch-tjänstklienterna har lämpliga återförsöksprinciper för att automatiskt försöka igen, även under normal drift och inte exklusivt under några tidsperioder för tjänstunderhåll. Dessa återförsöksprinciper bör sträcka sig över ett intervall på minst 5 minuter. Automatiska återförsöksfunktioner tillhandahålls med olika Batch-SDK:er, till exempel klassen .NET RetryPolicyProvider.

Statiska offentliga IP-adresser

Vanligtvis nås virtuella datorer i en Batch-pool via offentliga IP-adresser som kan ändras under poolens livslängd. Detta kan göra det svårt att interagera med en databas eller annan extern tjänst som begränsar åtkomsten till vissa IP-adresser. För att säkerställa att de offentliga IP-adresserna i poolen inte ändras oväntat kan du skapa en pool med hjälp av en uppsättning statiska offentliga IP-adresser som du styr. Mer information finns i Skapa en Azure Batch med angivna offentliga IP-adresser.

Testa anslutningen med Cloud Services konfiguration

Du kan inte använda det normala "ping"/ICMP-protokollet med molntjänster, eftersom ICMP-protokollet inte tillåts via Azure Load Balancer. Mer information finns i Anslutningar och nätverk för Azure Cloud Services.

Underliggande beroenden för Batch-noder

Tänk på följande beroenden och begränsningar när du utformar dina Batch-lösningar.

Systemskapade resurser

Azure Batch skapar och hanterar en uppsättning användare och grupper på den virtuella datorn, som inte ska ändras. Det här är skillnaderna:

Windows:

  • En användare med namnet PoolNonAdmin
  • En användargrupp med namnet WATaskCommon

Linux:

  • En användare med namnet _azbatch

Filrensning

Batch försöker aktivt rensa arbetskatalogen som aktiviteterna körs i när deras kvarhållningstid upphör att gälla. Filer som skrivs utanför den här katalogen är ditt ansvar att rensa för att undvika att fylla på diskutrymme.

Den automatiserade rensningen för arbetskatalogen blockeras om du kör en tjänst på Windows från arbetskatalogen startTask på grund av att mappen fortfarande används. Detta resulterar i försämrad prestanda. Du kan åtgärda detta genom att ändra katalogen för tjänsten till en separat katalog som inte hanteras av Batch.

Nästa steg