Noder och pooler i Azure Batch

I ett Azure Batch arbetsflöde är en beräkningsnod (eller nod) en virtuell dator som bearbetar en del av programmets arbetsbelastning. En pool är en samling av dessa noder som ditt program kan köras på. Den här artikeln förklarar mer om noder och pooler, tillsammans med överväganden när du skapar och använder dem i ett Azure Batch arbetsflöde.

Noder

En nod är en virtuell Azure-dator (VM) eller en virtuell molntjänstdator som är dedikerad för bearbetning av en del av programmets arbetsbelastning. Storleken på en nod avgör antalet CPU-kärnor, minneskapaciteten och storleken på det lokala filsystemet som allokeras till noden.

Du kan skapa pooler för Windows- eller Linux-noder med Azure Cloud Services eller Marketplace-avbildningar för Azure Virtual Machines eller anpassade avbildningar du förbereder.

Noder kan köra alla körbara filer eller skript som stöds av nodens operativsystemmiljö, Körbara filer eller skript innehåller *.exe-, * .cmd-,.bat- och * PowerShell-skript (för Windows) och binärfiler, shell- och Python-skript (för Linux).

Alla beräkningsnoder i Batch innehåller också:

• En fördefinierad mappstruktur och associerade miljövariabler som är tillgängliga som referens för aktiviteterna.
• Brandväggsinställningar som konfigureras för att styra åtkomsten.
• Fjärråtkomst till både Windows -noder (Remote Desktop Protocol (RDP)) och Linux-noder (Secure Shell (SSH)) (såvida du inte skapar din pool med fjärråtkomst inaktiverad).

Noder kan som standard kommunicera med varandra, men de kan inte kommunicera med virtuella datorer som inte ingår i samma pool. Om du vill tillåta att noder kommunicerar säkert med andra virtuella datorer, eller med ett lokalt nätverk, kan du etablera poolen i ett undernät i ett virtuellt Azure-nätverk (VNet). När du gör det kan noderna nås via offentliga IP-adresser. Dessa offentliga IP-adresser skapas av Batch och kan ändras under poolens livslängd. Du kan också skapa en pool med statiska offentliga IP-adresser som du kontrollerar, vilket säkerställer att de inte ändras oväntat.

Pooler

En pool är den samling noder som programmet körs på.

Azure Batch-pooler baseras på den grundläggande Azure-beräkningsplattformen. De tillhandahåller storskalig allokering, programinstallation, datadistribution, hälsoövervakning och flexibel justering(skalning)av antalet beräkningsnoder i en pool.

Varje nod som läggs till i en pool tilldelas ett unikt namn och en IP-adress. När en nod tas bort från en pool försvinner alla ändringar som gjorts i operativsystemet eller filer, och dess namn och IP-adress frisläpps för framtida användning. När en nod lämnar poolen är dess livslängd över.

En pool kan endast användas av det Batch-konto som den skapades under. Ett Batch-konto kan skapa flera pooler för att uppfylla resurskraven för de program som körs.

Poolen kan skapas manuellt eller automatiskt av Batch-tjänsten när du anger vilket arbete som ska utföras. När du skapar en pool kan du ange följande attribut:

• Node-operativsystem och version
• Nodtyp och målantal noder
• Nodstorlek
• Princip för automatisk skalning
• Schemaläggningsprincip för aktiviteter
• Kommunikationsstatus
• Starta uppgifter
• Programpaket
• Konfiguration av virtuella nätverk (VNet) och brandväggar
• Livstid

Operativsystem och version

När du skapar en Batch-pool anger du den virtuella Azure-datorkonfigurationen och vilken typ av operativsystem du vill köra på varje beräkningsnod i poolen.

Konfigurationer

Det finns två typer av poolkonfigurationer i Batch.

Konfiguration av virtuell dator

Konfiguration av virtuell dator anger att poolen består av virtuella Azure-datorer. Dessa virtuella datorer kan skapas från Linux- eller Windows-avbildningar.

Batch-nodagenten är ett program som körs på varje nod i poolen och som tillhandahåller kommando- och kontrollgränssnittet mellan noden och Batch-tjänsten. Det finns olika implementeringar av nodagenten, som kallas SKU:er, för olika operativsystem. När du skapar en pool med noder i en konfiguration av en virtuell dator måste du inte bara ange storleken på noderna och källan för avbildningarna som användes för att skapa dem, utan även referensen till avbildningen av den virtuella datorn och Batch-nodagentens SKU som ska installeras på noderna. Mer information om hur du anger dessa poolegenskaper finns i Etablera Linux-beräkningsnoder i Azure Batch-pooler. Om du vill kan du koppla en eller flera tomma datadiskar till en pool med virtuella datorer som skapats av Microsoft Azure Marketplace-avbildningar. Alternativt kan du inkludera datadiskar i de anpassade avbildningar som används för att skapa de virtuella datorerna. När du inkluderar datadiskar måste du montera och formatera diskarna från en virtuell dator för att använda dem.

Cloud Services konfiguration

I Cloud Services Configuration anges att poolen består av Azure Cloud Services noder. Cloud Services endast Windows beräkningsnoder.

Tillgängliga operativsystem för Cloud Services Configuration-pooler visas i kompatibilitetsmatrisenför Azure-gästoperativsystem och SDK,, och tillgängliga storlekar för beräkningsnoder visas i Storlekar för Cloud Services. När du skapar en pool som innehåller Cloud Services noder anger du nodstorleken och dess operativsystemfamilj (som avgör vilka versioner av .NET som installeras med operativsystemet). Cloud Services distribueras till Azure snabbare än virtuella datorer som kör Windows. Om du vill ha pooler med Windows-beräkningsnoder får du bättre distributionstid med Cloud Services.

Precis som med arbetsroller i Cloud Services kan du ange en operativsystemversion. Vi rekommenderar att du anger för os-versionen så att noderna uppgraderas automatiskt, och det krävs inget arbete för att hantera nyligen Latest (*) utgivna versioner. Det huvudsakliga skälet till att välja en viss operativsystemversion är att säkerställa programkompatibiliteten, så att du kan testa bakåtkompatibiliteten innan versionen uppdateras. Efter verifieringen kan operativsystemets version för poolen uppdateras och den nya OPERATIVSYSTEMavbildningen kan installeras. Alla aktiviteter som körs avbryts och tas i rad igen.

Node Agent-SKU:er

När du skapar en pool måste du välja lämplig nodeAgentSkuId, beroende på vilket operativsystem din VHD-basavbildning har. Du kan hämta en mappning av tillgängliga nodagent-SKU-ID:er till deras OS-avbildningsreferenser genom att anropa åtgärden List Supported Node Agent SKU:er.

Anpassade avbildningar för virtuell datorpooler

Information om hur du skapar en pool med anpassade avbildningar finns i Använda Azure Compute-galleriet för att skapa en anpassad pool.

Du kan också skapa en anpassad pool med virtuella datorer med hjälp av en hanterad avbildningsresurs. Information om hur man förbereder anpassade Linux-avbildningar från virtuella Azure-datorer finns i Så här skapar du en avbildning av en virtuell dator eller VHD. Information om att förbereda anpassade Windows-avbildningar från virtuella Azure-datorer finns i Skapa en hanterad avbildning av en generaliserad virtuell dator i Azure.

Stöd för containrar i pooler med virtuella datorer

När du skapar en pool med virtuella datorer med hjälp av Batch-API:er kan du ställa in poolen på att köra uppgifter i Docker-containrar. För närvarande måste du skapa poolen med hjälp av en avbildning som stöder Docker-container. Använd Windows Server 2016 Datacenter och en containeravbildning från Microsoft Azure Marketplace. Alternativt kan du ange en anpassad VM-avbildning som innehåller Docker Community Edition eller Enterprise Edition och alla nödvändiga drivrutiner. Poolinställningarna måste innehålla en containerkonfiguration som kopierar containeravbildningar till de virtuella datorerna när poolen skapas. Uppgifter som körs i poolen kan sedan referera till containeravbildningar och körningsalternativ för containrar.

Mer information finns i Run Docker container applications on Azure Batch (Köra Docker-behållarprogram på Azure Batch).

Nodtyp och mål

När du skapar en pool kan du ange vilka typer av noder du vill ha och målnumret för var och en. De två typerna av noder är:

• Dedikerade noder. Dedikerade beräkningsnoder är reserverade för dina arbetsbelastningar. De kostar mer än noder med låg prioritet, men de avbryts aldrig.
• Noder med låg prioritet. Noder med låg prioritet utnyttjar överkapacitet i Azure för att köra Batch-arbetsbelastningar. Noder med låg prioritet är billigare per timme än dedikerade noder och möjliggör arbetsbelastningar som kräver betydande beräkningskraft. Mer information finns i Use low-priority VMs with Batch (Använda virtuella datorer med låg prioritet med Batch).

Noder med låg prioritet kan tas bort när Azure inte har tillräckligt med överkapacitet. Om en nod avbryts när aktiviteter körs placeras aktiviteterna i kö igen och körs när en beräkningsnod blir tillgänglig igen. Noder med låg prioritet är ett bra alternativ för arbetsbelastningar om tiden för slutförande av jobbet är flexibelt och om arbetet är fördelat på flera noder. Innan du bestämmer dig för att använda noder med låg prioritet för ditt scenario måste du se till att arbetet som går förlorat på grund av avbrott är minimalt och enkelt att återskapa.

Du kan ha både noder med låg prioritet och dedikerade beräkningsnoder i samma pool. Varje typ av nod har en egen målinställning som du kan ange önskat antal noder för.

Antalet beräkningsnoder kallas mål eftersom din pool i vissa fall kanske inte når det önskade antalet noder. Detta kan hända om poolen först nått kärnkvoten för ditt Batch-konto. Eller så kanske inte poolen uppnår målet om du har tillämpat en formel för automatisk skalning på poolen som begränsar det maximala antalet noder.

Prisinformation för både lågprioriterade och dedikerade noder finns i Batch-priser.

Nodstorlek

När du skapar en Azure Batch-pool kan du välja bland nästan alla VM-familjer och storlekar i Azure. Azure erbjuder ett utbud av VM-storlekar för olika arbetsbelastningar, som särskilda HPC- eller GPU-aktiverade VM-storlekar. Observera att nodstorlekar bara kan väljas när en pool skapas. När en pool har skapats går det med andra ord inte att ändra dess nodstorlek.

Mer information finns i Choose a VM size for compute nodes in an Azure Batch pool (Välja VM-storlek för beräkningsnoder i Azure Batch-poolen).

Princip för automatisk skalning

För dynamiska arbetsbelastningar kan du tillämpa en princip för automatisk skalning på en pool. Batch-tjänsten utvärderar regelbundet formeln och justerar dynamiskt antalet noder i poolen enligt den aktuella arbetsbelastningen och resursanvändningen i beräkningsscenariot. På så sätt kan du sänka den totala kostnaden för programkörning genom att endast använda de resurser som du behöver och frisläppa de som du inte behöver.

Du aktiverar automatisk skalning genom att skriva en formel för automatisk skalning och associera formeln med en pool. Batch-tjänsten använder formeln för att bestämma antalet noder i poolen för nästa skalningsintervall (ett intervall som du kan konfigurera). Du kan ange inställningarna för automatisk skalning för en pool när du skapar den eller aktivera skalning för en pool senare. Du kan också uppdatera skalningsinställningarna för en skalningsaktiverad pool.

Ett exempel kan vara att ett jobb kräver att du skickar ett stort antal uppgifter som ska köras. Du kan tilldela en skalningsformel till poolen som justerar antalet noder i poolen baserat på antalet köade aktiviteter och aktiviteternas slutförandefrekvens. Batch-tjänsten utvärderar med jämna mellanrum formeln och ändrar storlek på poolen baserat på arbetsbelastningen och dina övriga formelinställningar. Tjänsten lägger till noder efter behov när det finns ett stort antal köade aktiviteter och tar bort noder när det inte finns några uppgifter i kö eller inte körs några uppgifter.

En skalningsformel kan baseras på följande mått:

• Tidsmått baseras på statistik som samlas in var femte minut under angivet antalet timmar.
• Resursmått baseras på processoranvändning, bandbreddsanvändning, minnesanvändning och antalet noder.
• Aktivitetsmått baseras på aktivitetens tillstånd, t.ex. Aktiv (köad), Körs eller Slutförd.

Om den automatiska skalningen minskar antalet beräkningsnoder i en pool måste du bestämma hur pågående aktiviteter ska hanteras vid nedskalningen. För att hantera detta tillhandahåller Batch ett alternativ för nodtilldelning som du kan inkludera i dina formler. Du kan till exempel ange att pågående aktiviteter ska stoppas direkt och sedan placeras i kö för att köras på en annan nod eller att de ska slutföras innan noden tas bort från poolen. Observera att om du anger alternativet för nodtilldelning som eller förhindras åtgärder för pooländring tills alla aktiviteter har slutförts, eller alla kvarhållningsperioder för aktiviteter taskcompletion retaineddata har upphört att gälla.

Mer information om automatisk skalning av program finns i Skala beräkningsnoder automatiskt i en Azure Batch-pool.

Schemaläggningsprincip för aktiviteter

Konfigurationsalternativet för högsta antal aktiviteter per nod anger det högsta antal aktiviteter som kan köras parallellt på varje beräkningsnod i poolen.

Standardkonfigurationen specificerar att en aktivitet i taget ska köras på en nod, men det finns scenarier där det kan vara bra om två eller fler aktiviteter kan köras samtidigt på en nod. Information om hur du kan dra fördel av flera aktiviteter per nod finns i exempelscenariot i artikeln om samtidiga nodaktiviteter.

Du kan också ange en fyllningstyp som avgör om Batch sprider ut aktiviteterna jämnt över alla noder i en pool eller om varje nod har det maximala antalet aktiviteter innan aktiviteter tilldelas till en annan nod.

Kommunikationsstatus

I de flesta fall körs aktiviteterna oberoende av varandra och behöver inte kommunicera med varandra. Det kan dock finnas program där aktiviteterna måste kommunicera (till exempel i MPI-scenarier).

Du kan konfigurera en pool så att den tillåter kommunikation mellan noder så att noder i en pool kan kommunicera vid körning. När kommunikation mellan noder är aktiverat kan noderna i pooler med Cloud Services-konfiguration kommunicera med varandra på portar som är större än 1100, och pooler med VM-konfiguration begränsar inte trafiken på någon port.

Aktivering av kommunikation mellan noder påverkar också placeringen av noder i kluster och kan begränsa det maximala antalet noder i en pool på grund av distributionsbegränsningar. Om programmet inte kräver kommunikation mellan noder kan Batch-tjänsten allokera ett potentiellt stort antal noder till poolen från många olika kluster och datacenter för ökad parallell bearbetningskapacitet.

Starta uppgifter

Om du vill kan du lägga till en startaktivitet som körs på varje nod när noden ansluter till poolen, och varje gång en nod startas om eller återställs. Startaktiviteten är särskilt användbar för att förbereda beräkningsnoder för körningen av aktiviteter, till exempel installationen av de program som aktiviteterna kör på beräkningsnoderna.

Programpaket

Du kan ange programpaket som ska distribueras till beräkningsnoderna i poolen. Programpaket underlättar distributionen och versionshanteringen för de program som dina aktiviteter kör. Programpaket som du anger för en pool installeras på varje nod som ansluter till den poolen, samt varje gång en nod startas om och varje gång nodens avbildning återställs.

Mer information om hur du använder programpaket för att distribuera program till dina Batch-noder finns i Deploy applications to compute nodes with Batch application packages (Distribuera program till beräkningsnoder med Batch-programpaket).

Konfiguration av virtuella nätverk (VNet) och brandväggar

När du etablerar en pool av beräkningsnoder i Batch kan du associera poolen med ett undernät för ett virtuellt Azure-nätverk (VNet). Om du vill använda ett Azure VNet-nätverk måste Batch-klientens API använda Azure Active Directory-autentisering (AD). Mer dokumentation om stödet för Azure Batch i Azure Active Directory finns i Authenticate Batch service solutions with Active Directory (Autentisera lösningar för Batch-tjänsten med Active Directory).

VNet-krav

Allmänna krav

• Det virtuella nätverket måste vara i samma prenumeration och region som det Batch-konto som du använder för att skapa din pool.

• Det undernät som anges för poolen måste ha tillräckliga otilldelade IP-adresser för det antal virtuella datorer som är mål för poolen. Summan av egenskaperna targetDedicatedNodes och targetLowPriorityNodes för poolen. Om undernätet inte har tillräckligt med lediga IP-adresser, allokerar poolen datornoderna partiellt och ett storleksändringsfel inträffar.

• Azure Storage-slutpunkt behöver matchas av eventuella anpassade DNS-servrar som servar ditt virtuella nätverk. Mer specifikt, ska URL:er av formen <account>.table.core.windows.net, <account>.queue.core.windows.net och <account>.blob.core.windows.net vara matchningsbara.

• Flera pooler kan skapas i samma virtuella nätverk eller i samma undernät (så länge det har tillräckligt med adressutrymme). En enda pool kan inte finnas i flera virtuella nätverk eller undernät.

Ytterligare krav för virtuella nätverk varierar beroende på huruvida Batch-poolen finns i den virtuella datorkonfigurationen eller Cloud Services-konfigurationen. För nya pooldistributioner till ett virtuellt nätverk rekommenderas konfigurationen för virtuell dator.

Pooler i konfigurationen för virtuell dator

Virtuella nätverk som stöds – endast Azure Resource Manager-baserade virtuella nätverk

Undernät-ID – när du anger undernätet med hjälp av Batch API:er använder du resursidentifieraren för undernätet. Undernät-ID har formatet:

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.Network/virtualNetworks/{network}/subnets/{subnet}

Behörigheter – kontrollera huruvida dina säkerhetsprinciper eller lås på det virtuella nätverkets prenumeration eller resursgruppen begränsar en användares behörigheter att hantera det virtuella nätverket.

Ytterligare nätverksresurser – Batch skapar automatiskt ytterligare nätverksresurser i resursgruppen som innehåller det virtuella nätverket.

Nätverkssäkerhetsgrupper: Batch-standard

Undernätet måste tillåta inkommande kommunikation från Batch-tjänsten för att kunna schemalägga aktiviteter på beräkningsnoderna och utgående kommunikation för att kommunicera med Azure Storage eller andra resurser efter behov av din arbetsbelastning. För pooler i konfigurationen av den virtuella datorn lägger Batch till NSG:er på nätverksgränssnittsnivån (NIC) som är kopplad till beräkningsnoder. Dessa NSG:er konfigureras med följande ytterligare regler:

• Inkommande TCP-trafik på portarna 29876 och 29877 från Batch-tjänstens IP-adresser som motsvarar BatchNodeManagement tjänsttaggen.
• Inkommande TCP-trafik på port 22 (Linux-noder) eller port 3389 (Windows-noder) för att tillåta fjärråtkomst. För vissa typer av aktiviteter med flera instanser i Linux (till exempel MPI) måste du även tillåta SSH-port 22-trafik för IP-adresser i undernätet som innehåller Batch-beräkningsnoderna. Detta kan blockeras per NSG-regler på undernätsnivå (se nedan).
• Utgående trafik på vilken port som helst till det virtuella nätverket. Detta kan ändras för NSG-regler på undernätsnivå (se nedan).
• Utgående trafik på valfri port till Internet. Detta kan ändras för NSG-regler på undernätsnivå (se nedan).

Nätverkssäkerhetsgrupper: Ange regler på undernätsnivå

Om du har en NSG som är associerad med undernätet där Batch-beräkningsnoder distribueras, eller om du vill tillämpa anpassade NSG-regler för att åsidosätta de tillämpade standardvärdena, måste du konfigurera den här NSG:n med minst de inkommande och utgående säkerhetsregler som visas i följande tabeller.

Konfigurera inkommande trafik på port 3389 (Windows) eller 22 (Linux) endast om du behöver tillåta fjärråtkomst till beräkningsnoderna från externa källor. Du kan behöva aktivera port 22-regler på Linux om du behöver stöd för aktiviteter med flera instanser med vissa MPI-körningar. Det är inte absolut nödvändigt att tillåta trafik på dessa portar för att beräkningsnoderna i poolen ska kunna användas.

Säkerhetsregler för inkommande trafik

Säkerhetsregler för utgående trafik

Utgående till BatchNodeManagement krävs för att kontakta Batch-tjänsten från beräkningsnoderna, till exempel för Job Manager-aktiviteter.

Pooler i Cloud Services-konfigurationen

Virtuella nätverk som stöds – endast klassiska virtuella nätverk

Undernät-ID – när du anger undernätet med hjälp av Batch API:er använder du resursidentifieraren för undernätet. Undernät-ID har formatet:

/subscriptions/{subscription}/resourceGroups/{group}/providers/Microsoft.ClassicNetwork /virtualNetworks/{network}/subnets/{subnet}

Behörigheter – Microsoft Azure Batch Tjänstens huvudnamn måste ha Classic Virtual Machine Contributor Azure-rollen för det angivna virtuella nätverket.

Nätverkssäkerhetsgrupper

Undernätet måste tillåta inkommande kommunikation från Batch-tjänsten för att kunna schemalägga uppgifter på beräkningsnoderna samt utgående kommunikation för att kommunicera med Azure Storage eller andra resurser.

Du behöver inte ange en NSG eftersom Batch endast konfigurerar inkommande kommunikation från Batch-IP-adresser till poolnoderna. Om det angivna undernätet dock har associerade NSG:er (NSG:er) och/eller en brandvägg konfigurerar du säkerhetsreglerna för inkommande och utgående trafik enligt det som visas i följande tabeller. Om kommunikationen till beräkningsnoderna i det angivna undernätet nekas av en NSG anger Batch-tjänsten tillståndet för beräkningsnoderna till oanvändbar.

Konfigurera inkommande trafik på port 3389 för Windows om du behöver tillåta RDP-åtkomst till poolnoderna. Detta krävs inte för att poolnoderna ska kunna användas.

Säkerhetsregler för inkommande trafik

Säkerhetsregler för utgående trafik

Läs mer om hur du konfigurerar en Batch-pool i ett VNet i Create a pool of virtual machines with your virtual network (Skapa en pool av virtuella datorer med det virtuella nätverket).

Livslängd för pooler och beräkningsnoder

När du utformar Azure Batch lösning måste du ange hur och när pooler skapas och hur länge beräkningsnoder i dessa pooler ska vara tillgängliga.

Ett alternativ är att skapa en pool för varje jobb som du skickar och sedan ta bort poolen så fort aktiviteterna har slutförts. Detta maximerar användningen eftersom noderna endast allokeras när det behövs, och de stängs av när de är inaktiva. Det innebär att jobbet måste vänta tills noderna har allokerats, men det är viktigt att observera att aktiviteterna schemaläggs för körning så snart noderna allokeras individuellt och startaktiviteten har slutförts. Batch väntar inte tills alla noderna i en pool är tillgängliga innan aktiviteterna tilldelas till noderna. vilket säkerställer maximal användning av alla tillgängliga noder.

Å andra sidan, om det är högsta prioritet att jobben startar direkt, kan en pool skapas i förväg och dess noder göras tillgängliga innan jobben skickas. I det här scenariot kan aktiviteterna starta direkt, men noderna kan vara inaktiva medan de väntar på att aktiviteter ska tilldelas.

En kombinerad metod används vanligtvis för att hantera en variabel men kontinuerlig belastning. Du kan ha en pool där flera jobb skickas och kan skala upp eller ned antalet noder enligt jobbbelastningen. Detta kan göras reaktivt baserat på den aktuella belastningen eller proaktivt om det går att förutse belastningen. Mer information finns i Automatisk skalningsprincip.

Automatiska buffertar

En automatisk pool är en pool som skapas av Batch-tjänsten när ett jobb skickas, i stället för att skapas före de jobb som ska köras i poolen. Batch-tjänsten hanterar livslängden för en autopool enligt de egenskaper som du anger. Oftast är dessa pooler också inställda på att tas bort automatiskt när deras jobb har slutförts.

Säkerhet med certifikat

Vanligtvis måste du använda certifikat när du krypterar eller avkrypterar känslig aktivitetsinformation, till exempel nyckeln för ett Azure Storage-konto. För detta ändamål kan du installera certifikat på noderna. Krypterade hemligheter skickas till aktiviteter via kommandoradsparametrar eller bäddas in i någon av aktivitetsresurserna, och de installerade certifikaten kan användas för att dekryptera dem.

Du använder åtgärden Lägg till certifikat (Batch REST) eller metoden CertificateOperations.CreateCertificate (Batch .NET) för att lägga till ett certifikat till ett Batch-konto. Därefter kan du associera certifikatet med en ny eller befintlig pool.

När ett certifikat associeras med en pool installeras certifikatet av Batch-tjänsten på varje nod i poolen. Batch-tjänsten installerar lämpliga certifikat när noden startas innan aktiviteter startas (inklusive startaktiviteten och Job Manager-aktiviteten).

Om du lägger till ett certifikat i en befintlig pool måste du starta om dess beräkningsnoder för att certifikatet ska tillämpas på noderna.

Nästa steg

• Lär dig mer om jobb och uppgifter.
• Lär dig hur du identifierar och undviker fel i bakgrundsåtgärder för pooler och noder.