Dela via

Bästa praxis för Azure Batch

  • Artikel

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

Dricks

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

Pooler

Pooler är beräkningsresurserna 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änst eller användarprenumeration. 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 aktivera en liten men viktig delmängd av scenarier. Mer information finns i konfiguration för användarprenumerationsläge.

  • classic eller simplified nodkommunikationsläge: Pooler kan konfigureras i något av två nodkommunikationslägen, klassiskt eller förenklat. I den klassiska nodkommunikationsmodellen initierar Batch-tjänsten kommunikation till beräkningsnoderna, och beräkningsnoder kräver även kommunikation till Azure Storage. I den förenklade nodkommunikationsmodellen initierar beräkningsnoder kommunikation med Batch-tjänsten. På grund av det begränsade omfånget för inkommande/utgående anslutningar som krävs och inte kräver utgående åtkomst i Azure Storage för baslinjeåtgärd, rekommenderar vi att du använder den förenklade nodkommunikationsmodellen. Vissa framtida förbättringar av Batch-tjänsten kräver också den förenklade nodkommunikationsmodellen. Den klassiska nodkommunikationsmodellen dras tillbaka den 31 mars 2026.

  • Överväganden för jobb- och aktivitetskörningstid: 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, operativsystemuppdateringar och en mängd andra problem orsaka att enskilda noder är offline. Om Batch-arbetsbelastningen kräver deterministiska, garanterade framsteg bör du allokera pooler med flera noder.

  • Bilder med förestående EOL-datum (end-of-life): Vi rekommenderar starkt att du undviker bilder med förestående Datum för Batch-supportens livslängd (EOL). Dessa datum kan identifieras via API:etListSupportedImages, PowerShell eller Azure CLI. Det är ditt ansvar att regelbundet uppdatera din vy över EOL-datumen 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 kontrollerar du att du följer Batch-supportens slutdatum för den avbildning som den anpassade avbildningen härleds till eller justeras för. En bild utan ett angivet batchSupportEndOfLife datum anger att ett sådant datum ännu inte har fastställts av Batch-tjänsten. Frånvaro av ett datum anger inte att respektive bild kommer att stödjas på obestämd tid. Ett EOL-datum kan läggas till eller uppdateras i framtiden när som helst.

  • VM-SKU:er med förestående EOL-datum (end-of-life): Precis som med VM-avbildningar kan även VM-SKU:er eller familjer nå Batch-supportens livslängd (EOL). Dessa datum kan identifieras via API:etListSupportedVirtualMachineSkus, PowerShell eller Azure CLI. Planera migreringen av din arbetsbelastning till en SKU för en virtuell dator som inte är EOL genom att skapa en ny pool med en lämplig VM-SKU som stöds. Avsaknad av ett associerat batchSupportEndOfLife datum för en VIRTUELL DATOR-SKU anger inte att viss VM SKU kommer att stödjas på obestämd tid. Ett EOL-datum kan läggas till eller uppdateras i framtiden när som helst.

  • 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 annan liknande pool på torsdag. Varje ny resurs som du skapar bör få ett unikt namn som du inte har använt tidigare. Du kan skapa unikhet med hjälp av ett GUID (antingen som hela resursnamnet eller som en del av det) eller genom att bädda in datum och tid som resursen skapades i resursnamnet. Batch stöder DisplayName, vilket kan ge en resurs ett mer läsbart namn även om det faktiska resurs-ID:t är något som inte är mänskligt. Genom att använda unika namn blir det enklare för dig att särskilja vilken resurs som gjorde något i loggar och mått. Det tar också bort tvetydighet om du någonsin behöver lämna in ett supportärende för en resurs.

  • Kontinuitet under poolunderhåll och fel: Det är bäst att dina jobb använder pooler dynamiskt. Om dina jobb använder samma pool för allt finns det en chans att jobb inte körs om något går fel med poolen. Den här principen är särskilt viktig för tidskänsliga arbetsbelastningar. Du kan till exempel välja eller skapa en pool dynamiskt när du schemalägger varje jobb eller har ett sätt att åsidosätta poolnamnet så att du kan kringgå en pool som inte är felfri.

  • Affärskontinuitet under poolunderhåll och fel: Det finns många orsaker till varför en pool kanske inte växer till den storlek som du vill ha, till exempel interna fel eller kapacitetsbegränsningar. Se till att du kan ommåla jobb i en annan pool (eventuellt med en annan VM-storlek med Hjälp av UpdateJob) om det behövs. Undvik att förlita dig på ett statiskt pool-ID med förväntningen att det aldrig kommer att tas bort och aldrig ändras.

Poolsäkerhet

Isoleringsgräns

Om ditt scenario kräver isolering av jobb eller uppgifter från varandra i isoleringssyfte, gör du det 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 säkerheten såvida inte den större miljö som Batch-kontot arbetar från kräver isolering.

Uppdateringar av Batch Node Agent

Batchnodagenter uppgraderas inte automatiskt för pooler som inte har beräkningsnoder utan noll. För att säkerställa att dina Batch-pooler får de senaste säkerhetskorrigeringarna och uppdateringarna av Batch-nodagenten måste du antingen ändra storlek på poolen till noll beräkningsnoder eller återskapa poolen. Vi rekommenderar att du övervakar viktig information om Batch Node Agent för att förstå ändringar i nya Batch-nodagentversioner. Genom att regelbundet söka efter uppdateringar när de släpptes kan du planera uppgraderingar till den senaste agentversionen.

Innan du återskapar eller ändrar storlek på poolen bör du ladda ned eventuella nodagentloggar i felsökningssyfte om du har problem med batchpoolen eller beräkningsnoderna. Den här processen beskrivs ytterligare i avsnittet Noder .

Kommentar

Allmän vägledning om säkerhet i Azure Batch finns i Metodtips för Batch-säkerhet och efterlevnad.

Uppdtaeringar av operativsystemet

Vi rekommenderar att den virtuella datoravbildning som valts för en Batch-pool ska vara uppdaterad med den senaste utgivaren som tillhandahålls säkerhetsuppdateringar. Vissa avbildningar kan utföra automatiska paketuppdateringar vid start (eller kort därefter), vilket kan störa vissa användarriktade åtgärder, till exempel att hämta paketlagringsplatsuppdateringar (till exempel apt update) eller installera paket under åtgärder som en StartTask.

Vi rekommenderar att du aktiverar automatisk os-uppgradering för Batch-pooler, vilket gör att den underliggande Azure-infrastrukturen kan samordna uppdateringar över hela poolen. Det här alternativet kan konfigureras så att det inte indisrupteras för aktivitetskörning. Automatisk operativsystemuppgradering stöder inte alla operativsystem som Batch stöder. Mer information finns i stödmatrisen för automatisk os-uppgradering av vm-skalningsuppsättningar. För Windows-operativsystem kontrollerar du att du inte aktiverar egenskapen virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates när du använder automatisk operativsystemuppgradering i Batch-poolen.

Azure Batch verifierar inte eller garanterar inte att avbildningar som tillåts för användning med tjänsten har de senaste säkerhetsuppdateringarna. Uppdateringar av avbildningar finns under visning av utgivaren av avbildningen och inte i Azure Batch. För vissa bilder som publiceras under microsoft-azure-batchfinns det ingen garanti för att dessa bilder hålls uppdaterade med sin överordnade härledda avbildning.

Poollivslängd och fakturering

Poolens livslängd kan variera beroende på vilken metod för allokering och alternativ som tillämpas på poolkonfigurationen. Pooler kan ha en godtycklig livslängd och ett varierande antal beräkningsnoder när som helst. Det är ditt ansvar att hantera beräkningsnoderna i poolen antingen explicit eller via funktioner som tillhandahålls av tjänsten (autoskalning eller autopool).

  • Pool rekreation: 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 aktiviteter har flyttats till den nya poolen tar du bort den gamla poolen.

  • Pooleffektivitet och fakturering: Själva Batch medför inga extra avgifter. Du debiteras dock avgifter för Azure-resurser som används, till exempel beräkning, lagring, nätverk och andra resurser som kan krävas för din Batch-arbetsbelastning. Du debiteras för varje beräkningsnod i poolen, oavsett vilket tillstånd den befinner sig i. 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å den virtuella datorns cacheminne eller tillfälliga SSD, för att undvika extra kostnader som är associerade med hanterade diskar.

Poolallokeringsfel

Poolallokeringsfel kan inträffa när som helst under den första allokeringen eller efterföljande storleksändringar. Dessa fel kan bero på tillfällig kapacitetsöverbelastning 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. Förstå att problem kan uppstå och du bör utveckla arbetsflödet så att det är motståndskraftigt mot omkörningar. Om noderna misslyckas försöker Batch automatiskt återställa dessa beräkningsnoder åt dig. Den här återställningen kan utlösa omplanering av alla aktiviteter som körs på noden som återställs eller på en annan, tillgänglig nod. Mer information om avbrutna uppgifter finns i Designa för återförsök.

Anpassade avbildningspooler

När du skapar en Azure Batch-pool med hjälp av konfigurationen för virtuella datorer anger du en VM-avbildning som tillhandahåller operativsystemet för varje beräkningsnod i poolen. Du kan skapa poolen med en Azure Marketplace-avbildning som stöds eller skapa en anpassad avbildning med en Azure Compute Gallery-avbildning. 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 av Azure Compute-galleriet när det är möjligt. Med Hjälp av Azure Compute Gallery kan du etablera pooler snabbare, skala större mängder virtuella datorer och förbättra tillförlitligheten vid etablering av virtuella datorer.

Bilder från tredje part

Pooler kan skapas med avbildningar från tredje part som publicerats på Azure Marketplace. Med Batch-konton i användarprenumerationsläge kan du se felet "Allokering misslyckades på grund av berättigandekontroll för marketplace-köp" när du skapade en pool med vissa bilder från tredje part. Lös det här felet genom att acceptera de villkor som angetts av avbildningens utgivare. Du kan göra det med hjälp av Azure PowerShell eller Azure CLI.

Containerpooler

När du skapar en Batch-pool med ett virtuellt nätverk kan det finnas interaktionseffekter mellan det angivna virtuella nätverket och standardbryggan för Docker. Docker skapar som standard en nätverksbrygga med en undernätsspecifikation på 172.17.0.0/16. Se till att det inte finns några motstridiga IP-intervall mellan Docker-nätverksbryggan och det virtuella nätverket.

Docker Hub begränsar antalet avbildningshämtningar. Se till att din arbetsbelastning inte överskrider publicerade hastighetsgränser för Docker Hub-baserade avbildningar. Vi rekommenderar att du använder Azure Container Registry direkt eller använder Artefaktcache i ACR.

Beroende av 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 behöver starta vid en viss tidpunkt bör du överväga att skala upp poolen i din primära region långt före starttiden. Om poolskalan misslyckas kan du återgå 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 Designa ditt program för hög tillgänglighet.

Projekt

Ett jobb är en container som är utformad 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 mer effektivt 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 uppgifter vardera. Om du använde 1 000 jobb, var och en med en enda uppgift som skulle vara den minst effektiva, långsammaste och dyraste metoden att ta.

Undvik att utforma en Batch-lösning som kräver tusentals aktiva jobb samtidigt. Det finns ingen kvot för aktiviteter, så att köra många aktiviteter under så få jobb som möjligt använder effektivt dina jobb- och jobbschemakvoter.

Jobblivslängd

Ett Batch-jobb har en obegränsad livslängd tills det tas bort från systemet. Dess tillstånd anger om det 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. Den här åtgärden kan utlösas automatiskt via egenskapen onAllTasksComplete eller maxWallClockTime.

Det finns en standardkvot för aktivt jobb och jobbschema. Jobb och jobbscheman i slutfört tillstånd räknas inte mot den här kvoten.

Ta bort jobb när de inte längre behövs, även om de är i slutfört tillstånd. Även om slutförda jobb inte räknas mot en aktiv jobbkvot är det fördelaktigt att regelbundet rensa slutförda jobb. Till exempel blir listning av jobb effektivare när det totala antalet jobb är en mindre uppsättning (även om rätt filter tillämpas på begäran).

Uppgifter

Uppgifter är enskilda arbetsenheter som utgör ett jobb. Uppgifter skickas av användaren och schemaläggs av Batch till 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 till sin natur 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 poolborttagning) tas även alla filer på dessa noder bort. På grund av det här beteendet bör en aktivitet flytta utdata från noden som den körs på och till ett beständigt arkiv innan den slutförs. Om en uppgift misslyckas bör den på samma sätt flytta loggar som krävs för att diagnostisera felet till ett beständigt lager.

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

Hantera uppgiftslivslängd

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

Om du tar bort uppgifter utförs två saker:

  • Ser till att du inte har någon uppbyggnad av uppgifter i jobbet. Den här åtgärden hjälper dig att undvika problem med att hitta den uppgift som du är intresserad av eftersom du måste filtrera igenom slutförda uppgifter.
  • Rensar motsvarande uppgiftsdata på noden (har retentionTime inte redan träffats). Den här åtgärden hjälper till att säkerställa att noderna inte fylls med uppgiftsdata och att diskutrymmet tar slut.

Kommentar

För uppgifter som just har skickats till Batch tar det upp till 10 minuter innan DeleteTask API-anropet börjar gälla. Innan den börjar gälla kan andra aktiviteter förhindras från att schemaläggas. Det beror på att Batch Scheduler fortfarande försöker schemalägga de uppgifter som just har tagits bort. Om du vill ta bort en aktivitet kort efter att den har skickats avslutar du aktiviteten i stället (eftersom begäran om att avsluta aktiviteten börjar gälla omedelbart). Och ta sedan bort uppgiften 10 minuter senare.

Skicka ett stort antal uppgifter i samlingen

Uppgifter kan skickas individuellt eller i samlingar. Skicka uppgifter i samlingar på upp till 100 åt gången när du gör massöverföring av uppgifter för att minska kostnaderna och sändningstiden.

Ange maximalt antal uppgifter per nod på rätt sätt

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

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

Uppgifter kan göras om automatiskt av Batch. Det finns två typer av återförsök: användarstyrda och interna. Användarkontrollerade återförsök anges av aktivitetens maxTaskRetryCount. När ett program som anges i aktiviteten avslutas med en icke-nollavslutskod görs en ny åtgärd upp till värdet för maxTaskRetryCount.

Även om det är ovanligt kan en uppgift göras om internt på grund av fel på beräkningsnoden, till exempel att inte kunna uppdatera det interna tillståndet eller ett fel på noden när aktiviteten körs. Uppgiften görs om på samma beräkningsnod, om möjligt upp till en intern gräns innan den ger upp aktiviteten och skjuter upp uppgiften som ska schemaläggas om av Batch, eventuellt på en annan beräkningsnod.

Det finns inga designskillnader när du kör dina uppgifter på dedikerade noder eller dekornoder. Oavsett om en aktivitet föregrips när den körs på en nod för oanvänd kapacitet eller avbryts på grund av ett fel på en dedikerad nod, minimeras båda situationerna genom att uppgiften utformas för att motstå fel.

Skapa varaktiga uppgifter

Uppgifter bör utformas för att klara fel och hantera återförsök. Den här principen är särskilt viktig för tidskrävande uppgifter. Se till att dina uppgifter genererar samma enskilda resultat även om de körs mer än en gång. Ett sätt att uppnå detta resultat är att göra dina uppgifter "målsökande". Ett annat sätt är att se till att dina uppgifter är idempotent (aktiviteter har 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 är byggt för att motstå fel. Skapa i stället en uppgift för att säkerställa att filerna finns på beräkningsnoden. en uppgift som inte kopierar om filer som redan finns. På så sätt fortsätter uppgiften 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 aktivitet körs i en minut (eller mer) är schemaläggningskostnaderna som en bråkdel av den totala beräkningstiden små.

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 aktivitetsomfång eller poolomfång. Om aktiviteten bara körs under en kort tid kan aktivitetsomfånget vara ineffektivt på grund av de resurser som behövs för att skapa autoanvändarkontot för aktiviteten. Om du vill ha 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 automatisk användare med poolomfång.

Noder

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

Startuppgifter: livslängd och idempotens

Precis som med andra aktiviteter bör nodstartaktiviteten vara idempotent. Startaktiviteter körs igen när beräkningsnoden startas om eller när Batch-agenten startas om. En idempotent uppgift är helt enkelt en uppgift som ger ett konsekvent resultat när den körs flera gånger.

Startaktiviteter bör inte vara tidskrävande eller kopplas till beräkningsnodens livslängd. Om du behöver starta program som är tjänster eller tjänstliknande kan du skapa en startuppgift som gör att dessa program kan startas och hanteras av operativsystemanläggningar som systemd i Linux eller Windows-tjänster. Startaktiviteten bör fortfarande konstrueras som idempotent så att efterföljande körning av startaktiviteten hanteras korrekt om dessa program tidigare har installerats som tjänster.

Dricks

När Batch kör startaktiviteten igen försöker den ta bort katalogen starta aktivitet och skapa den igen. Om Batch inte kan återskapa startaktivitetskatalogen kommer beräkningsnoden inte att starta startaktiviteten.

Dessa tjänster får inte ta fillås på filer i Batch-hanterade kataloger på noden, eftersom Batch annars inte kan ta bort dessa kataloger på grund av fillåsen. I stället för att till exempel konfigurera start av tjänsten direkt från arbetskatalogen för startaktivitet kopierar du filerna någon annanstans på ett idempotent sätt. Installera sedan tjänsten från den platsen med hjälp av operativsystemets anläggningar.

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 är Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5, Standard_GS5och Standard_E64i_v3. Mer information om isolerade VM-storlekar finns i Isolering av virtuella datorer i Azure.

Undvik att skapa katalogkorsningar i Windows

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

Tillfälliga diskar och AZ_BATCH_NODE_ROOT_DIR

Batch förlitar sig på virtuella datortillfälliga diskar, för Batch-kompatibla VM-storlekar, för att lagra metadata relaterade till aktivitetskörning tillsammans med artefakter för varje aktivitetskörning på den här tillfälliga disken. Exempel på dessa tillfälliga diskmonteringspunkter eller kataloger är: /mnt/batch, /mnt/resource/batchoch D:\batch\tasks. Ersättning, återmontering, koppling, symlänkning eller på annat sätt omdirigering av dessa monteringspunkter och kataloger eller någon av de överordnade katalogerna stöds inte och kan leda till instabilitet. Om du behöver mer diskutrymme bör du överväga att använda en vm-storlek eller familj som har tillfälligt diskutrymme som uppfyller dina krav eller kopplar datadiskar. Mer information finns i nästa avsnitt om att ansluta och förbereda datadiskar för beräkningsnoder.

Ansluta och förbereda datadiskar

Varje enskild beräkningsnod har exakt samma datadiskspecifikation kopplad om den anges som en del av Batch-poolinstansen. Endast nya datadiskar kan kopplas till Batch-pooler. Dessa datadiskar som är anslutna till beräkningsnoder partitioneras, formateras eller monteras inte automatiskt. Det är ditt ansvar att utföra dessa åtgärder som en del av din startuppgift. Dessa startuppgifter måste utformas för att vara idempotent. Det är möjligt att köra startuppgifterna på beräkningsnoderna igen. Om startaktiviteten inte är idempotent kan potentiell dataförlust inträffa på datadiskarna.

Dricks

Om du monterar en datadisk i Linux, om du kapslar diskmonteringspunkten under de tillfälliga Monteringspunkterna i Azure, till exempel /mnt eller /mnt/resource, bör du vara försiktig så att inga beroendekörningar introduceras. Om dessa monteringar till exempel utförs automatiskt av operativsystemet kan det finnas en kapplöpning mellan den tillfälliga disken som monteras och dina datadiskar som monteras under den överordnade disken. Åtgärder bör vidtas för att säkerställa att lämpliga beroenden framtvingas av tillgängliga faciliteter, till exempel systemd eller skjuta upp monteringen av datadisken till startaktiviteten som en del av ditt idempotent datadiskförberedelseskript.

Förbereda datadiskar i Linux Batch-pooler

Azure-datadiskar i Linux visas som blockenheter och tilldelas en typisk sd[X] identifierare. Du bör inte förlita dig på statiska sd[X] tilldelningar eftersom dessa etiketter tilldelas dynamiskt vid starttiden och inte garanteras vara konsekventa mellan den första och efterföljande starten. Du bör identifiera dina anslutna diskar via de mappningar som visas i /dev/disk/azure/scsi1/. Om du till exempel har angett LUN 0 för datadisken i AddPool-API:et visas den här disken som /dev/disk/azure/scsi1/lun0. Om du till exempel skulle visa en lista över den här katalogen kan du se:

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

Du behöver inte översätta referensen tillbaka till mappningen sd[X] i förberedelseskriptet, i stället referera till enheten direkt. I det här exemplet skulle den här enheten vara /dev/disk/azure/scsi1/lun0. Du kan ange det här ID:t direkt till fdisk, mkfsoch andra verktyg som krävs för arbetsflödet. Du kan också använda lsblk med blkid för att mappa UUID för disken.

Mer information om Azure-datadiskar i Linux, inklusive alternativa metoder för att hitta datadiskar och /etc/fstab alternativ finns i den här artikeln. Se till att det inte finns några beroenden eller raser enligt beskrivningen i tipsanteckningen innan du befordrar din metod till produktionsanvändning.

Förbereda datadiskar i Windows Batch-pooler

Azure-datadiskar som är anslutna till Batch Windows-beräkningsnoder visas opartitionerade och oformaterade. Du måste räkna upp diskar med RAW partitioner för åtgärder som en del av startuppgiften. Den här informationen kan hämtas med powershell-cmdleten Get-Disk . Som ett exempel kan du potentiellt se:

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

Där disknummer 2 är den onitialiserade datadisken som är ansluten till den här beräkningsnoden. Dessa diskar kan sedan initieras, partitioneras och formateras efter behov för arbetsflödet.

Mer information om Azure-datadiskar i Windows, inklusive PowerShell-exempelskript, finns i den här artikeln. Se till att alla exempelskript verifieras för idempotens innan befordran till produktionsanvändning.

Samla in Batch-agentloggar

Om du märker ett problem med beteendet för en nod eller aktiviteter som körs på en nod samlar du in Batch-agentloggarna innan du frigör de aktuella noderna. Batch-agentloggarna kan samlas in med api:et Ladda upp Batch-tjänstloggar. Dessa loggar kan tillhandahållas som en del av ett supportärende till Microsoft och hjälper till med felsökning och lösning av problem.

Batch-API

Timeoutfel

Tidsgränsfel indikerar inte nödvändigtvis att tjänsten inte kunde bearbeta begäran. När ett timeoutfel inträffar bör du antingen försöka utföra åtgärden igen eller hämta tillståndet för resursen, beroende på vad som är lämpligt för situationen, för att kontrollera statusen för om åtgärden lyckades eller misslyckades.

Anslutning

Läs följande vägledning om anslutning i dina Batch-lösningar.

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

När du etablerar Batch-pooler i ett virtuellt nätverk bör du noga följa riktlinjerna för användningen av BatchNodeManagement.regiontjänsttagg , portar, protokoll och regelriktning. Användning av tjänsttaggen rekommenderas starkt. använd inte underliggande IP-adresser för Batch-tjänsten eftersom de kan ändras över tid. Användning av Batch-tjänstens IP-adresser direkt kan orsaka instabilitet, avbrott eller avbrott för dina Batch-pooler.

För användardefinierade vägar (UDR) rekommenderar vi att du använder BatchNodeManagement.regiontjänsttaggar i stället för Batch-tjänstens IP-adresser eftersom de kan ändras över tid.

Respektera DNS

Se till att dina system respekterar DNS Time-to-Live (TTL) för din Batch-kontotjänst-URL. Se dessutom till att dina Batch-tjänstklienter och andra anslutningsmekanismer till Batch-tjänsten inte förlitar sig på IP-adresser.

Alla HTTP-begäranden med statuskoder på 5xx-nivå tillsammans med rubriken "Anslutning: stäng" i svaret kräver att du justerar batchtjänstens klientbeteende. Batch-tjänstklienten bör följa rekommendationen genom att stänga den befintliga anslutningen, matcha DNS igen för Batch-kontotjänstens URL och försöka följa begäranden om en ny anslutning.

Försök igen automatiskt

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

Statiska offentliga IP-adresser

Virtuella datorer i en Batch-pool används vanligtvis via offentliga IP-adresser som kan ändras under poolens livslängd. Den här dynamiska karaktären 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 åtgärda detta problem 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-pool med angivna offentliga IP-adresser.

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 bör ändras:

Windows:

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

Linux:

  • En användare med namnet _azbatch

Dricks

Namngivning av dessa användare eller grupper är implementeringsartefakter och kan ändras när som helst.

Rensning av fil

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

Den automatiska rensningen för arbetskatalogen blockeras om du kör en tjänst i Windows från arbetskatalogen för startaktiviteten på grund av att mappen fortfarande används. Den här åtgärden leder till försämrade prestanda. Åtgärda problemet genom att ändra katalogen för tjänsten till en separat katalog som inte hanteras av Batch.

Nästa steg