Best practices van Azure Batch

In dit artikel worden best practices en nuttige tips beschreven voor een effectieve Azure Batch service. Deze tips kunnen u helpen de prestaties te verbeteren en ontwerpval in uw Batch-oplossingen te voorkomen.

Tip

Zie Best practices voor Batch-beveiliging Azure Batch naleving voor richtlijnen over beveiliging in Azure Batch.

Pools

Pools zijn de rekenbronnen voor het uitvoeren van taken in de Batch-service. De volgende secties bieden aanbevelingen voor het werken met Batch-pools.

Poolconfiguratie en -naamgeving

  • Pooltoewijzingsmodus: Wanneer u een Batch-account maakt, kunt u kiezen uit twee pooltoewijzingsmodi: Batch-service of gebruikersabonnement. In de meeste gevallen moet u de standaardmodus Batch-service gebruiken, waarbij pools achter de schermen worden toegewezen in batch-beheerde abonnementen. In de alternatieve modus Gebruikersabonnement worden Batch-VM's en andere resources rechtstreeks in uw abonnement gemaakt wanneer er een groep wordt gemaakt. Gebruikersabonnementaccounts worden voornamelijk gebruikt om een kleine maar belangrijke subset van scenario's mogelijk te maken. Zie Aanvullende configuratie voor gebruikersabonnementmodus voor meer informatie.

  • 'virtualMachineConfiguration' of 'cloudServiceConfiguration': Hoewel u momenteel pools kunt maken met behulp van een van beide configuraties, moeten nieuwe pools worden geconfigureerd met 'virtualMachineConfiguration' en niet met 'cloudServiceConfiguration'. Alle huidige en nieuwe Batch-functies worden ondersteund door virtuele-machineconfiguratiegroepen. Cloud Services configuratiegroepen bieden geen ondersteuning voor alle functies en er zijn geen nieuwe mogelijkheden gepland. U kunt na 29 februari 2024geen nieuwe cloudServiceConfiguration-pools meer maken of nieuwe knooppunten toevoegen aan bestaande pools. Zie Batch-poolconfiguratie migreren van Cloud Services naar virtuele machine voor meer informatie.

  • Overwegingen voor taak- en taakrun time: Als u taken hebt die voornamelijk uit kortlopende taken bestaan en het verwachte totale aantal taken klein is, zodat de totale verwachte run time van de job niet lang is, moet u geen nieuwe pool toewijzen voor elke job. De toewijzingstijd van de knooppunten vermindert de run time van de taak.

  • Meerdere rekenknooppunten: Afzonderlijke knooppunten zijn niet gegarandeerd altijd beschikbaar. Hoewel dit ongebruikelijk is, kunnen hardwarefouten, updates van het besturingssysteem en een groot aantal andere problemen ertoe leiden dat afzonderlijke knooppunten offline zijn. Als uw Batch-workload deterministische, gegarandeerde voortgang vereist, moet u pools met meerdere knooppunten toewijzen.

  • Afbeeldingen met aanstaande EOL-datums (end-of-life) : We raden u ten zeerste aan om afbeeldingen te vermijden met aankomende Datums voor einde van levensduur (EOL) voor Batch-ondersteuning. Deze datums kunnen worden ontdekt via de ListSupportedImages API, PowerShellof Azure CLI. Het is uw verantwoordelijkheid om uw weergave van de EOL-datums die relevant zijn voor uw pools regelmatig te vernieuwen en uw workloads te migreren voordat de EOL-datum plaatsvindt. Als u een aangepaste afbeelding met een opgegeven knooppuntagent gebruikt, moet u ervoor zorgen dat u de datums voor het einde van de levensduur van Batch volgt voor de afbeelding waarvan uw aangepaste afbeelding is afgeleid of uitgelijnd.

  • Unieke resourcenamen: Batch-resources (jobs, pools, enzovoort) komen en gaan vaak in de tijd. U kunt bijvoorbeeld een pool maken op maandag, deze op dinsdag verwijderen en vervolgens op donderdag een andere vergelijkbare pool maken. Elke nieuwe resource die u maakt, moet een unieke naam krijgen die u nog niet eerder hebt gebruikt. U kunt dit doen met behulp van een GUID (als de volledige resourcenaam of als onderdeel ervan) of door de datum en tijd in tesluiten waarop de resource is gemaakt in de resourcenaam. Batch ondersteunt DisplayName,waarmee een resource een beter leesbare naam kan krijgen, zelfs als de werkelijke resource-id iets is dat niet gebruiksvriendelijk is. Door unieke namen te gebruiken, kunt u gemakkelijker onderscheid maken tussen welke specifieke resource iets heeft gedaan in logboeken en metrische gegevens. Het verwijdert ook dubbelzinnigheid als u ooit een ondersteuningscase voor een resource moet indienen.

  • Continuïteit tijdens het onderhoud van de pool en fouten: Het is het beste om voor uw taken dynamisch pools te laten gebruiken. Als uw taken voor alles dezelfde pool gebruiken, bestaat de kans dat taken niet worden uitgevoerd als er iets misgaat met de pool. Dit is vooral belangrijk voor tijdgevoelige workloads. Als u dit wilt oplossen, selecteert of maakt u een pool dynamisch wanneer u elke taak inplant, of hebt u een manier om de naam van de pool te overschrijven, zodat u een slechte pool kunt omzeilen.

  • Bedrijfscontinuïteit tijdens poolonderhoud en -fouten: Er zijn veel redenen waarom een pool mogelijk niet groter wordt dan u wilt, zoals interne fouten of capaciteitsbeperkingen. Zorg ervoor dat u taken in een andere pool kunt retargeten (mogelijk met een andere VM-grootte; Batch ondersteunt dit indien nodig via UpdateJob. Vertrouw niet op een statische pool-id met de verwachting dat deze nooit wordt verwijderd en nooit wordt gewijzigd.

Levensduur en facturering van pool

De levensduur van de pool kan variëren, afhankelijk van de toewijzingsmethode en opties die zijn toegepast op de poolconfiguratie. Pools kunnen op elk moment een willekeurige levensduur en een wisselend aantal rekenknooppunten hebben. Het is uw verantwoordelijkheid om de rekenknooppunten in de pool expliciet te beheren of via functies die worden geleverd door de service (automatisch schalen of autopool).

  • Nieuwheid van pool: Pas elke paar maanden de ize van uw pools aan op nul om ervoor te zorgen dat u de meest recente updates voor knooppuntagents en foutfixes krijgt. Uw pool ontvangt geen updates voor de knooppuntagent, tenzij deze opnieuw wordt gemaakt (of als het wordt geseed tot 0 rekenknooppunten). Voordat u de pool opnieuw maakt of het ize ervan kunt bepalen, moet u de logboeken van knooppuntagents downloaden voor het gebruik van debugging, zoals besproken in de sectie Knooppunten.

  • Poolpool: Vermijd groepen op een vergelijkbare manier dagelijks te verwijderen en opnieuw te maken. Maak in plaats daarvan een nieuwe pool en werk vervolgens uw bestaande taken bij om naar de nieuwe pool te wijzen. Zodra alle taken naar de nieuwe pool zijn verplaatst, verwijdert u de oude pool.

  • Efficiëntie en facturering van de pool: Voor Batch zelf worden geen extra kosten in rekening gebracht, maar er worden wel kosten in rekening gebracht voor de gebruikte rekenbronnen. U wordt gefactureerd voor elk rekenpunt in de pool, ongeacht de status ervan. Dit omvat alle kosten die nodig zijn om het knooppunt uit te voeren, zoals opslag- en netwerkkosten. Zie Kostenanalyse en budgetten voorAzure Batch.

Pooltoewijzingsfouten

Pooltoewijzingsfouten kunnen zich op elk moment voor doen tijdens de eerste toewijzing of latere wijzigingen. Dit kan worden veroorzaakt door tijdelijke capaciteitsuitputting in een regio of fouten in andere Azure-services waar Batch van afhankelijk is. Uw kernquotum is geen garantie, maar eerder een limiet.

Niet-geplande uitvaltijd

Het is mogelijk dat Batch-pools uitvalgebeurtenissen ervaren in Azure. Houd hier rekening mee bij het plannen en ontwikkelen van uw scenario of werkstroom voor Batch. Als knooppunten mislukken, probeert Batch deze rekenknooppunten automatisch namens u te herstellen. Hierdoor kan het opnieuw plannen van een taak worden uitgevoerd op het knooppunt dat wordt hersteld. Zie Ontwerpen voor nieuwe opdrachten voor meer informatie over onderbroken taken.

Aangepaste afbeeldingspools

Wanneer u een Azure Batch maakt met behulp van de configuratie van de virtuele machine, geeft u een VM-installatiebestand op dat het besturingssysteem biedt voor elk rekenpunt in de pool. U kunt de pool maken met een ondersteunde Azure Marketplace of u kunt een aangepaste afbeelding maken met een Shared Image Gallery afbeelding. Hoewel u ook een beheerde afbeelding kunt gebruiken om een aangepaste groep met afbeeldingen te maken, raden we u aan om waar mogelijk aangepaste afbeeldingen te maken met behulp van de Shared Image Gallery afbeelding. Met behulp Shared Image Gallery kunt u pools sneller inrichten, grotere hoeveelheden VM's schalen en de betrouwbaarheid verbeteren bij het inrichten van VM's.

Afbeeldingen van derden

Pools kunnen worden gemaakt met behulp van externe afbeeldingen die zijn gepubliceerd naar Azure Marketplace. In de modus Batch-accounts voor gebruikersabonnementen ziet u mogelijk de fout 'Toewijzing is mislukt vanwege de geschiktheidscontrole voor Marketplace-aankopen' bij het maken van een pool met bepaalde externe afbeeldingen. Accepteer de voorwaarden die zijn ingesteld door de uitgever van de afbeelding om deze fout op te lossen. U kunt dit doen met behulp van Azure PowerShell of Azure CLI.

Afhankelijkheid van Azure-regio

U moet niet vertrouwen op één Azure-regio als u een tijdsgevoelige of productieworkload hebt. Hoewel dit zeldzaam is, zijn er problemen die van invloed kunnen zijn op een hele regio. Als uw verwerking bijvoorbeeld op een bepaald tijdstip moet beginnen, kunt u overwegen om de pool in uw primaire regio ruim vóór de begintijd op te schalen. Als deze poolschaal mislukt, kunt u terugvallen op het omhoog schalen van een pool in een back-upregio (of regio's).

Pools voor meerdere accounts in verschillende regio's bieden een kant-en-klaar back-up die gemakkelijk toegankelijk is als er iets misgaat met een andere pool. Zie Uw toepassing ontwerpen voor hoge beschikbaarheid voor meer informatie.

Taken

Een job is een container die is ontworpen om honderden, duizenden of zelfs miljoenen taken te bevatten. Volg deze richtlijnen bij het maken van taken.

Minder jobs, meer taken

Het is inefficiënt om een taak te gebruiken om één taak uit te voeren. Het is bijvoorbeeld efficiënter om één job met 1000 taken te gebruiken in plaats van 100 jobs te maken die elk 10 taken bevatten. Het uitvoeren van 1000 taken, elk met één taak, is de minst efficiënte, langzaamste en duurste aanpak.

Daarom moet u voorkomen dat u een Batch-oplossing ontwerpt die duizenden gelijktijdig actieve taken vereist. Er is geen quotum voor taken, dus bij het uitvoeren van een groot aantal taken onder zo weinig mogelijk jobs wordt efficiënt gebruikgemaakt van uw job- en jobplanningsquota.

Levensduur van de taak

Een Batch-taak heeft een onbeperkte levensduur totdat deze uit het systeem wordt verwijderd. De status geeft aan of het meer taken voor planning kan accepteren of niet.

Een taak wordt niet automatisch overgeslagen naar de status Voltooid, tenzij deze expliciet wordt beëindigd. Dit kan automatisch worden geactiveerd via de eigenschap onAllTasksComplete of maxWallClockTime.

Er is een standaardquotum voor actieve taak en taakplanning. Jobs en jobplanningen met de status Voltooid tellen niet mee voor dit quotum.

Taken

Taken zijn afzonderlijke werkeenheden waar een job uit bestaat. Taken worden door de gebruiker verzonden en door Batch gepland op rekenknooppunten. De volgende secties bieden suggesties voor het ontwerpen van uw taken voor het afhandelen van problemen en het efficiënt uitvoeren van taken.

Taakgegevens opslaan

Rekenknooppunten zijn van nature kortstondig. Met Batch-functies, zoals autopool en automatisch schalen, kunnen knooppunten gemakkelijk verdwijnen. Wanneer knooppunten een pool verlaten (vanwege een resize of een pool verwijderen), worden ook alle bestanden op die knooppunten verwijderd. Daarom moet de uitvoer van een taak worden verplaatst van het knooppunt waar deze wordt uitgevoerd en naar een duurzame opslag voordat deze is voltooid. En als een taak mislukt, moeten logboeken worden verplaatst die nodig zijn om de fout te diagnosticeren in een duurzame opslag.

Batch heeft geïntegreerde Azure Storage voor het uploaden van gegevens via OutputFiles,evenals verschillende gedeelde bestandssystemen, of u kunt de upload zelf uitvoeren in uw taken.

Levensduur van taken beheren

Verwijder taken wanneer ze niet meer nodig zijn of stel een retentionTime-taakbeperking in. Als een is ingesteld, schoont Batch automatisch de schijfruimte op die door de taak wordt retentionTime gebruikt wanneer retentionTime de verloopt.

Door taken te verwijderen, worden twee dingen uitgevoerd. Het zorgt ervoor dat u geen opbouw van taken in de job hebt, waardoor het moeilijker wordt om de taak te zoeken/vinden waarin u geïnteresseerd bent (omdat u de voltooide taken moet filteren). Ook worden de bijbehorende taakgegevens op het knooppunt opgeslagen (opgegeven retentionTime is nog niet bereikt). Dit zorgt ervoor dat uw knooppunten niet vol zitten met taakgegevens en geen schijfruimte meer hebben.

Grote aantallen taken in verzameling verzenden

Taken kunnen afzonderlijk of in verzamelingen worden verzonden. Verzend taken in verzamelingen van maximaal 100 tegelijk bij het bulksgewijs verzenden van taken om de overhead en indieningstijd te verminderen.

Stel het maximum aantal taken per knooppunt op de juiste wijze in

Batch ondersteunt oversubsubribing-taken op knooppunten (meer taken uitvoeren dan een knooppunt kernen heeft). Het is aan u om ervoor te zorgen dat uw taken 'passen' in de knooppunten in uw pool. U kunt bijvoorbeeld een gedegradeerde ervaring hebben als u acht taken probeert te plannen die elk 25% CPU-gebruik verbruiken op één knooppunt (in een pool met taskSlotsPerNode = 8 ).

Ontwerpen voor nieuwe proberen en opnieuw uitvoeren

Taken kunnen automatisch opnieuw worden uitgevoerd door Batch. Er zijn twee soorten nieuwe proberen: door de gebruiker beheerd en intern. Door de gebruiker beheerde nieuwe poging wordt opgegeven door maxTaskRetryCount van de taak. Wanneer een programma dat is opgegeven in de taak wordt afgesloten met een afsluitende code die niet nul is, wordt de taak opnieuw tot de waarde van de maxTaskRetryCount .

Hoewel dit zelden gebeurt, kan een taak intern opnieuw worden uitgevoerd vanwege fouten op het rekenpunt, zoals het niet kunnen bijwerken van de interne status of een fout op het knooppunt terwijl de taak wordt uitgevoerd. De taak wordt, indien mogelijk, opnieuw proberen uit te voeren op hetzelfde reken knooppunt, tot een interne limiet voordat de taak wordt opgeslagen en de taak wordt uitgesteld om opnieuw te worden gepland door Batch, mogelijk op een ander reken knooppunt.

Er zijn geen ontwerpverschillen bij het uitvoeren van uw taken op toegewezen knooppunten of knooppunten met lage prioriteit. Of een taak nu wordt verordend tijdens het uitvoeren op een knooppunt met lage prioriteit of wordt onderbroken als gevolg van een storing op een toegewezen knooppunt, beide situaties worden vereenigd door de taak zo te ontwerpen dat deze bestand is tegen fouten.

Duurzame taken bouwen

Taken moeten zodanig worden ontworpen dat ze bestand zijn tegen fouten en dat nieuwe pogingen mogelijk zijn. Dit is vooral belangrijk voor langlopende taken. Om dit te doen, zorgt u ervoor dat taken hetzelfde en hetzelfde resultaat genereren, zelfs als ze meer dan één keer worden uitgevoerd. Een manier om dit te bereiken, is door uw taken 'doelzoekend' te maken. Een andere manier is om ervoor te zorgen dat uw taken idempotent zijn (taken hebben hetzelfde resultaat, ongeacht hoe vaak ze worden uitgevoerd).

Een veelvoorkomende voorbeeld is een taak om bestanden te kopiëren naar een reken knooppunt. Een eenvoudige benadering is een taak die alle opgegeven bestanden kopieert telkens wanneer deze wordt uitgevoerd, wat inefficiënt is en niet is gebouwd om fouten te voorkomen. Maak in plaats daarvan een taak om ervoor te zorgen dat de bestanden zich op het reken knooppunt staan; een taak die geen bestanden hercopyeert die al aanwezig zijn. Op deze manier gaat de taak verder waar deze was gebleven als deze werd onderbroken.

Korte uitvoeringstijd voorkomen

Taken die slechts één tot twee seconden worden uitgevoerd, zijn niet ideaal. Probeer een aanzienlijke hoeveelheid werk uit te voeren in een afzonderlijke taak (minimaal 10 seconden, maximaal uren of dagen). Als elke taak één minuut (of meer) wordt uitgevoerd, is de planningsoverhead als een fractie van de totale rekentijd klein.

Poolbereik gebruiken voor korte taken op Windows knooppunten

Bij het plannen van een taak op Batch-knooppunten kunt u kiezen of u deze wilt uitvoeren met een taakbereik of poolbereik. Als de taak slechts korte tijd wordt uitgevoerd, kan het taakbereik inefficiënt zijn vanwege de resources die nodig zijn om het account voor de automatische gebruiker voor die taak te maken. Voor een grotere efficiëntie kunt u deze taken instellen op poolbereik. Zie Een taak uitvoeren als een automatische gebruiker met poolbereik voor meer informatie.

Knooppunten

Een reken knooppunt is een virtuele Azure-machine (VM) of cloudservice-VM die is toegewezen aan het verwerken van een deel van de workload van uw toepassing. Volg deze richtlijnen wanneer u met knooppunten werkt.

Idempotente begintaken

Net als bij andere taken moet de begintaak van het knooppunt idempotent zijn, omdat deze telkens opnieuw wordt uitgevoerd wanneer het knooppunt wordt opstart. Een idempotente taak is gewoon een taak die een consistent resultaat produceert wanneer deze meerdere keren wordt uitgevoerd.

Geïsoleerde knooppunten

Overweeg het gebruik van geïsoleerde VM-grootten voor workloads met nalevings- of wettelijke vereisten. Ondersteunde geïsoleerde grootten in de configuratiemodus van virtuele machines zijn Standard_E80ids_v4 , , , , en Standard_M128ms Standard_F72s_v2 Standard_G5 Standard_GS5 Standard_E64i_v3 . Zie Isolatie van virtuele machines in Azure voor meer informatie over geïsoleerde VM-grootten.

Langlopende services beheren via de interface voor besturingssysteemservices

Soms is het nodig om een andere agent naast de Batch-agent in het knooppunt uit te voeren. U kunt bijvoorbeeld gegevens verzamelen van het knooppunt en deze rapporteren. We raden u aan deze agents te gebruiken als os-services, zoals een Windows service of een systemd Linux-service.

Wanneer deze services worden uitgevoerd, moeten ze geen bestandsvergrendelingen uitvoeren voor bestanden in door Batch beheerde mappen op het knooppunt, omdat Batch deze mappen anders niet kan verwijderen vanwege de bestandsvergrendelingen. Als u bijvoorbeeld een Windows-service in een begintaak installeert, kopieert u de bestanden elders in in plaats van de service rechtstreeks vanuit de begintaak te starten (of als de bestanden bestaan, slaat u de kopie over). Installeer vervolgens de service vanaf die locatie. Wanneer Batch de begintaak opnieuw heeft, wordt de begintaakmap verwijderd en opnieuw aan de slag. Dit werkt omdat de service bestandsvergrendelingen heeft op de andere map, niet de begintaakwerkmap.

Vermijd het maken van mapverbinding in Windows

Mapkoppelingen, ook wel maphardkoppelingen genoemd, zijn moeilijk te gebruiken tijdens het opschonen van taken en taken. Gebruik symlinks (zachte koppelingen) in plaats van harde koppelingen.

Logboeken van Batch-agent verzamelen

Als u een probleem ziet met betrekking tot het gedrag van een knooppunt of taken die worden uitgevoerd op een knooppunt, verzamelt u de logboeken van de Batch-agent voordat u de toewijzing van de knooppunten in kwestie opzegt. De Logboeken van de Batch-agent kunnen worden verzameld met behulp van Upload Api voor Batch-servicelogboeken. Deze logboeken kunnen worden aangeleverd als onderdeel van een ondersteuningsticket voor Microsoft en helpen bij het oplossen van problemen.

Upgrades van het besturingssysteem beheren

Voor Batch-accounts in de gebruikersabonnementmodus kunnen geautomatiseerde upgrades van het besturingssysteem de voortgang van taken onderbreken, met name als de taken lang worden uitgevoerd. Het bouwen van idempotente taken kan helpen bij het verminderen van fouten die worden veroorzaakt door deze onderbrekingen. We raden ook aan om upgrades van besturingssysteemafbeeldingen te plannen voor tijden waarop taken naar verwachting niet worden uitgevoerd.

Voor Windows enableAutomaticUpdates is standaard ingesteld true op . Automatische updates toestaan wordt aanbevolen, maar u kunt deze waarde instellen op als u ervoor wilt zorgen dat er niet onverwacht een update van het false besturingssysteem wordt geïnstalleerd.

Isolatiebeveiliging

Voor isolatiedoeleinden, als voor uw scenario het isoleren van taken van elkaar is vereist, doet u dit door ze in afzonderlijke pools te hebben. Een pool is de beveiligingsisolatiegrens in Batch en standaard zijn twee pools niet zichtbaar of kunnen ze niet met elkaar communiceren. Vermijd het gebruik van afzonderlijke Batch-accounts als isolatiemiddel.

Connectiviteit

Lees de volgende richtlijnen met betrekking tot connectiviteit in uw Batch-oplossingen.

Netwerkbeveiligingsgroepen (NSG's) en door de gebruiker gedefinieerde routes (UDR's)

Zorg er bij het inrichten van Batch-pools ineen virtueel netwerk voor dat u de richtlijnen met betrekking tot het gebruik van de servicetag, poorten, protocollen en richting van de regel BatchNodeManagement nauwkeurig volgt. Het gebruik van de servicetag wordt sterk aanbevolen, in plaats van de onderliggende IP-adressen van de Batch-service te gebruiken. Dit komt doordat de IP-adressen na een periode kunnen veranderen. Het rechtstreeks gebruiken van IP-adressen van de Batch-service kan leiden tot instabiliteit, onderbrekingen of storingen voor uw Batch-pools.

Zorg ervoor dat u voor door de gebruiker gedefinieerde routes (UDR's) een proces hebt om IP-adressen van batch-service periodiek bij te werken in uw routetabel, omdat deze adressen na een bepaalde periode veranderen. Zie Servicetags on-premises voor meer informatie over het verkrijgen van de lijst met IP-adressen van de Batch-service. De IP-adressen van de Batch-service worden gekoppeld aan de BatchNodeManagement servicetag (of de regionale variant die overeenkomt met de regio van uw Batch-account).

DNS respecteren

Zorg ervoor dat uw systemen DNS Time-to-Live (TTL) voor de SERVICE-URL van uw Batch-account volgen. Zorg er bovendien voor dat uw Batch-service-clients en andere connectiviteitsmechanismen voor de Batch-service niet afhankelijk zijn van IP-adressen (of maak een pool met statische openbare IP-adressen, zoals hieronder wordt beschreven).

Als uw aanvragen HTTP-antwoorden op 5xx-niveau ontvangen en er een header 'Verbinding: sluiten' in het antwoord staat, moet uw Batch-serviceclient de aanbeveling observeren door de bestaande verbinding te sluiten, DNS opnieuw op te lossen voor de SERVICE-URL van het Batch-account en de aanvragen te volgen bij een nieuwe verbinding.

Aanvragen automatisch opnieuw proberen

Zorg ervoor dat uw Batch-service-clients het juiste beleid voor opnieuw proberen hebben om uw aanvragen automatisch opnieuw uit te voeren, zelfs tijdens normale werking en niet uitsluitend tijdens onderhoudsperioden van de service. Deze beleidsregels voor opnieuw proberen moeten een interval van ten minste 5 minuten bespannen. Mogelijkheden voor automatisch opnieuw proberen worden geleverd met verschillende Batch-SDK's, zoals de .NET RetryPolicyProvider-klasse.

Statische openbare IP-adressen

Virtuele machines in een Batch-pool zijn doorgaans toegankelijk via openbare IP-adressen die gedurende de levensduur van de pool kunnen worden gewijzigd. Dit kan het lastig maken om te communiceren met een database of andere externe service die de toegang tot bepaalde IP-adressen beperkt. Om ervoor te zorgen dat de openbare IP-adressen in uw pool niet onverwacht veranderen, kunt u een groep maken met behulp van een set statische openbare IP-adressen die u controleert. Zie Create an Azure Batch pool with specified public IP addresses (Een groep Azure Batch met opgegeven openbare IP-adressen) voor meer informatie.

Connectiviteit testen met Cloud Services configuratie

U kunt het normale ping-/ICMP-protocol niet gebruiken met cloudservices, omdat het ICMP-protocol niet is toegestaan via de Azure load balancer. Zie Connectiviteit en netwerken voor meer informatie Azure Cloud Services.

Onderliggende afhankelijkheden van Batch-knooppunt

Houd rekening met de volgende afhankelijkheden en beperkingen bij het ontwerpen van uw Batch-oplossingen.

Door het systeem gemaakte resources

Azure Batch maakt en beheert een set gebruikers en groepen op de VM, die niet mogen worden gewijzigd. De verschillen zijn als volgt:

Windows:

  • Een gebruiker met de naam PoolNonAdmin
  • Een gebruikersgroep met de naam WATaskCommon

Linux:

  • Een gebruiker met de naam _azbatch

Bestand opschonen

Batch probeert actief de werkmap op te schonen waarin taken worden uitgevoerd, zodra de bewaartijd is verstreken. Alle bestanden die buiten deze map worden geschreven, zijn uw verantwoordelijkheid om op te schonen om te voorkomen dat de schijfruimte wordt gevuld.

Het automatisch opschonen van de werkmap wordt geblokkeerd als u een service op Windows vanuit de werkmap startTask hebt uitgevoerd, omdat de map nog steeds in gebruik is. Dit leidt tot slechtere prestaties. Als u dit wilt oplossen, wijzigt u de map voor die service in een afzonderlijke map die niet wordt beheerd door Batch.

Volgende stappen