Azure Batch-pool- och nodfel

Vissa åtgärder för att skapa och hantera Azure Batch-pooler sker omedelbart. Det är enkelt att identifiera fel för dessa åtgärder eftersom fel vanligtvis returneras omedelbart från API:et, kommandoraden eller användargränssnittet. Vissa åtgärder är dock asynkrona, körs i bakgrunden och tar flera minuter att slutföra. I den här artikeln beskrivs olika sätt att identifiera och undvika fel som kan inträffa i bakgrundsåtgärderna för pooler och noder.

Se till att ställa in dina program så att de implementerar omfattande felkontroll, särskilt för asynkrona åtgärder. Omfattande felkontroll kan hjälpa dig att snabbt identifiera och diagnostisera problem.

Poolfel

Poolfel kan vara relaterade till storleksändring av timeout eller fel, automatiskt skalningsfel eller fel vid borttagning av pooler.

Ändra storlek på tidsgränsöverskridning eller fel

När du skapar en ny pool eller ändrar storlek på en befintlig pool anger du målantalet noder. Åtgärden för att skapa eller ändra storlek slutförs omedelbart, men den faktiska fördelningen av nya noder eller borttagning av befintliga noder kan ta flera minuter. Du kan ange tidsgränsen för storleksändring i poolen – Lägg till eller Pool – Ändra storlek på API:er. Om Batch inte kan allokera målantalet noder under tidsgränsen för storleksändringen hamnar poolen i ett stabilt tillstånd och rapporter ändrar storlek på fel.

Egenskapen resizeError visar de fel som inträffade för den senaste utvärderingen.

Vanliga orsaker till storleksändringsfel är:

• Ändra storlek på tidsgränsen för kort. Standardtimeouten på 15 minuter är vanligtvis tillräckligt lång för att allokera eller ta bort poolnoder. Om du allokerar ett stort antal noder, till exempel mer än 1 000 noder från en Azure Marketplace-avbildning eller mer än 300 noder från en anpassad virtuell datoravbildning, kan du ange tidsgränsen för storleksändringen till 30 minuter.

• Otillräcklig kärnkvot. Ett Batch-konto är begränsat i antalet kärnor som det kan allokera över alla pooler och slutar allokera noder när det når den kvoten. Du kan öka kärnkvoten så att Batch kan allokera fler noder. Mer information finns i Batch-tjänstkvoter och -gränser.

• Otillräckliga IP-adresser för undernätet när en pool finns i ett virtuellt nätverk. Ett virtuellt nätverksundernät måste ha tillräckligt med IP-adresser för att allokera till varje begärd poolnod. Annars går det inte att skapa noderna. Mer information finns i Skapa en Azure Batch-pool i ett virtuellt nätverk.

• Otillräckliga resurser när en pool finns i ett virtuellt nätverk. När du skapar en pool i ett virtuellt nätverk kan du skapa resurser som lastbalanserare, offentliga IP-adresser och nätverkssäkerhetsgrupper (NSG:er) i samma prenumeration som Batch-kontot. Kontrollera att prenumerationskvoterna är tillräckliga för dessa resurser.

• Stora pooler med anpassade VM-avbildningar. Stora pooler som använder anpassade VM-avbildningar kan ta längre tid att allokera och ändra storlek på tidsgränser kan inträffa. Rekommendationer om gränser och konfiguration finns i Skapa en pool med Azure Compute Gallery.

Automatiska skalningsfel

Du kan ange att Azure Batch automatiskt skalar antalet noder i en pool och du definierar parametrarna för den automatiska skalningsformeln för poolen. Batch-tjänsten använder sedan formeln för att regelbundet utvärdera antalet noder i poolen och ange nya målnummer. Mer information finns i Skapa en automatisk formel för skalning av beräkningsnoder i en Batch-pool.

Följande problem kan uppstå när du använder automatisk skalning:

• Den automatiska skalningsutvärderingen misslyckas.
• Den resulterande storleksändringen misslyckas och tidsgränsen uppnås.
• Ett problem med den automatiska skalningsformeln leder till felaktiga nodmålvärden. Storleksändringen kan antingen fungera eller överskrida tidsgränsen.

Om du vill få information om den senaste automatiska skalningsutvärderingen använder du egenskapen autoScaleRun . Den här egenskapen rapporterar utvärderingstid, värden och resultat samt eventuella prestandafel.

Poolen ändrar storlek på fullständig händelse samlar in information om alla utvärderingar.

Fel vid borttagning av pooler

Om du vill ta bort en pool som innehåller noder tar Batch först bort noderna, vilket kan ta flera minuter att slutföra. Batch tar sedan bort själva poolobjektet.

Batch anger poolState till deleting under borttagningsprocessen. Det anropande programmet kan identifiera om borttagningen av poolen tar för lång tid med hjälp state av egenskaperna och stateTransitionTime .

Om borttagningen av poolen tar längre tid än förväntat försöker Batch regelbundet tills poolen har tagits bort. I vissa fall beror fördröjningen på ett avbrott i Azure-tjänsten eller andra tillfälliga problem. Andra faktorer som förhindrar att poolen tas bort kan kräva att du vidtar åtgärder för att åtgärda problemet. Dessa faktorer kan omfatta följande problem:

• Resurslås kan placeras på Batch-skapade resurser eller på nätverksresurser som Batch använder.

• Resurser som du har skapat kan bero på en Batch-skapad resurs. Om du till exempel skapar en pool i ett virtuellt nätverk skapar Batch en NSG, en offentlig IP-adress och en lastbalanserare. Om du använder dessa resurser utanför poolen kan du inte ta bort poolen.

• Resursprovidern Microsoft.Batch kan avregistreras från prenumerationen som innehåller din pool.

• För Batch-konton Microsoft Azure Batch i användarprenumerationsläge kanske du inte längre har rollen Deltagare eller Ägare i den prenumeration som innehåller din pool. Mer information finns i Tillåt Batch att komma åt prenumerationen.

Nodfel

Även när Batch allokerar noder i en pool kan olika problem orsaka att vissa noder inte är felfria och inte kan köra uppgifter. Dessa noder debiteras fortfarande, så det är viktigt att identifiera problem för att undvika att betala för noder som du inte kan använda. Att känna till vanliga nodfel och känna till det aktuella jobbetState är användbart för felsökning.

Starta aktivitetsfel

Du kan ange en valfri startTask för en pool. Precis som med alla aktiviteter använder startaktiviteten en kommandorad och kan ladda ned resursfiler från lagring. Startaktiviteten körs för varje nod när noden startar. Egenskapen waitForSuccess anger om Batch väntar tills startaktiviteten har slutförts innan någon aktivitet schemaläggs till en nod. Om du konfigurerar noden att vänta tills startaktiviteten har slutförts, men startaktiviteten misslyckas, kan noden inte användas men debiteras fortfarande.

Du kan identifiera startaktivitetsfel med hjälp av egenskaperna taskExecutionResult och taskFailureInformation för egenskapen startTaskInformation på den översta nivån.

En misslyckad startaktivitet gör också att Batch anger computeNodeState till starttaskfailed, om waitForSuccess har angetts till true.

Precis som med alla aktiviteter kan det finnas många orsaker till ett startaktivitetsfel. Om du vill felsöka kontrollerar du stdout, stderr och andra aktivitetsspecifika loggfiler.

Startaktiviteter måste återaktiveras eftersom startaktiviteten kan köras flera gånger på samma nod, till exempel när noden återskapas eller startas om. I sällsynta fall, när en startaktivitet körs efter en händelse orsakar en nodomstart, återskapas ett operativsystem (OS) eller tillfälliga diskar medan den andra inte gör det. Eftersom Batch-startuppgifter och alla Batch-uppgifter körs från den tillfälliga disken är den här situationen vanligtvis inte ett problem. I fall där startuppgiften installerar ett program på OS-disken och behåller andra data på den tillfälliga disken kan det dock uppstå synkroniseringsproblem. Skydda programmet om du använder båda diskarna.

Nedladdningsfel för programpaket

Du kan ange ett eller flera programpaket för en pool. Batch laddar ned de angivna paketfilerna till varje nod och avkomprimerar filerna när noden startar, men innan den schemalägger uppgifter. Det är vanligt att använda ett startaktivitetskommando med programpaket, till exempel för att kopiera filer till en annan plats eller för att köra installationsprogrammet.

Om ett programpaket inte hämtar och avkomprimera rapporterar egenskapen computeNodeError felet och anger nodtillståndet till unusable.

Containernedladdningsfel

Du kan ange en eller flera containerreferenser i en pool. Batch laddar ned de angivna containrarna till varje nod. Om containern inte kan laddas ned rapporterar egenskapen computeNodeError felet och anger nodtillståndet till unusable.

Uppdateringar av nodoperativsystem

För Windows-pooler enableAutomaticUpdates är inställt på true som standard. Även om det rekommenderas att tillåta automatiska uppdateringar kan uppdateringar avbryta aktivitetsförloppet, särskilt om aktiviteterna är tidskrävande. Du kan ange det här värdet till false om du behöver se till att en OS-uppdatering inte inträffar oväntat.

Nod i oanvändbart tillstånd

Batch kan ange computeNodeState till unusable av många orsaker. Du kan inte schemalägga aktiviteter till en unusable nod, men noden debiteras fortfarande.

Om Batch kan fastställa orsaken rapporterar egenskapen computeNodeError den. Om en nod är i ett unusable tillstånd, men inte har någon computeNodeError, innebär det att Batch inte kan kommunicera med den virtuella datorn. I det här fallet försöker Batch alltid återställa den virtuella datorn. Batch försöker dock inte automatiskt återställa virtuella datorer som inte kunde installera programpaket eller containrar, även om deras tillstånd är unusable.

Andra orsaker till unusable noder kan vara följande orsaker:

• En anpassad VM-avbildning är ogiltig. Bilden är till exempel inte korrekt förberedd.
• En virtuell dator flyttas på grund av ett infrastrukturfel eller en uppgradering på låg nivå. Batch återställer noden.
• En VM-avbildning har distribuerats på maskinvara som inte stöder den.
• De virtuella datorerna finns i ett virtuellt Azure-nätverk och trafiken har blockerats till nyckelportar.
• De virtuella datorerna finns i ett virtuellt nätverk, men utgående trafik till Azure Storage blockeras.
• De virtuella datorerna finns i ett virtuellt nätverk med en anpassad DNS-konfiguration och DNS-servern kan inte matcha Azure Storage.

Nodagentloggfiler

Batch-agentprocessen som körs på varje poolnod innehåller loggfiler som kan hjälpa dig om du behöver kontakta supporten om ett problem med poolnoden. Du kan ladda upp loggfiler för en nod via Azure-portalen, Batch Explorer eller API:et Compute Node – Upload Batch Service Logs . När du har laddat upp och sparat loggfilerna kan du ta bort noden eller poolen för att spara kostnaden för att köra noderna.

Noddisken är full

Batch använder den tillfälliga enheten på en virtuell nodpool för att lagra filer som följande jobbfiler, aktivitetsfiler och delade filer:

• Programpaketfiler
• Resursfiler för uppgifter
• Programspecifika filer som laddats ned till en av Batch-mapparna
• Stdout - och stderr-filer för varje aktivitetsprogramkörning
• Programspecifika utdatafiler

Filer som programpaket eller starta aktivitetsresursfiler skrivs bara en gång när Batch skapar poolnoden. Även om de bara skriver en gång kan de fylla den tillfälliga enheten om filerna är för stora.

Andra filer, till exempel stdout och stderr, skrivs för varje uppgift som en nod kör. Om ett stort antal aktiviteter körs på samma nod, eller om aktivitetsfilerna är för stora, kan de fylla den tillfälliga enheten.

Noden behöver också en liten mängd utrymme på OS-disken för att skapa användare när den har startats.

Storleken på den tillfälliga enheten beror på storleken på den virtuella datorn. Ett övervägande när du väljer en VM-storlek är att se till att den tillfälliga enheten har tillräckligt med utrymme för den planerade arbetsbelastningen.

När du lägger till en pool i Azure-portalen kan du visa en fullständig lista över VM-storlekar, inklusive kolumnen Resursdiskstorlek . Artiklarna som beskriver VM-storlekar har tabeller med en Temp Storage-kolumn . Mer information finns i Beräkningsoptimerade storlekar för virtuella datorer. Ett exempel på en storlekstabell finns i Fsv2-serien.

Du kan ange en kvarhållningstid för filer som skrivs av varje aktivitet. Kvarhållningstiden avgör hur länge aktivitetsfilerna ska behållas innan de rensas automatiskt. Du kan minska kvarhållningstiden till lägre lagringskrav.

Om den tillfälliga disken eller OS-disken får slut på utrymme, eller är nära att få slut på utrymme, flyttas noden till unusablecomputeNoteState och nodfelet säger att disken är full.

Om du inte är säker på vad som tar upp utrymme på noden kan du prova att fjärransluta till noden och undersöka manuellt. Du kan också använda API:et File - List From Compute Node för att undersöka filer, till exempel aktivitetsutdata, i Batch-hanterade mappar. Det här API:et visar endast filer i batchhanterade kataloger. Om dina uppgifter har skapat filer någon annanstans visar inte det här API:et dem.

När du har hämtat alla data som du behöver från noden eller överför dem till ett beständigt lager kan du ta bort data efter behov för att frigöra utrymme.

Du kan ta bort gamla slutförda jobb eller aktiviteter vars uppgiftsdata fortfarande finns på noderna. Titta i samlingen i taskInformation på noden eller använd API:et Arkiv – lista från beräkningsnod.recentTasks Om du tar bort ett jobb tas alla aktiviteter i jobbet bort. Om du tar bort aktiviteterna i jobbet utlöses borttagning av data i aktivitetskatalogerna på noderna och frigör utrymme. När du har frigjort tillräckligt med utrymme startar du om noden. Noden bör flytta ut ur unusable tillstånd och till idle igen.

Om du vill återställa en oanvändbar nod i VirtualMachineConfiguration-pooler kan du ta bort noden från poolen med hjälp av API:et Pool – Ta bort noder . Sedan kan du utöka poolen igen för att ersätta den felaktiga noden med en ny. För CloudServiceConfiguration-pooler kan du återskapa noden med hjälp av API:et Compute Node – Reimage för att rensa hela disken. Omimering stöds för närvarande inte för VirtualMachineConfiguration-pooler .

Nästa steg

• Läs mer om felkontroll av jobb och uppgift.
• Lär dig mer om metodtips för att arbeta med Azure Batch.