Best practices van Azure Batch

  • Artikel

In dit artikel worden aanbevolen procedures en handige tips besproken voor het effectief gebruik van de Azure Batch-service. Deze tips kunnen u helpen bij het verbeteren van de prestaties en het voorkomen van valkuilen in uw Batch-oplossingen.

Tip

Zie de best practices voor beveiliging en naleving van Batch voor hulp bij beveiliging in Azure Batch.

Groepen

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

Poolconfiguratie en -naamgeving

  • Pooltoewijzingsmodus: Bij het maken van een Batch-account kunt u kiezen tussen twee pooltoewijzingsmodi: Batch-service of gebruikersabonnement. In de meeste gevallen moet u de standaardmodus van de Batch-service gebruiken, waarin pools achter de schermen worden toegewezen in door 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. Accounts voor gebruikersabonnementen worden voornamelijk gebruikt om een kleine maar belangrijke subset van scenario's mogelijk te maken. Zie de configuratie voor de modus gebruikersabonnement 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 cloudServiceConfiguration. Alle huidige en nieuwe Batch-functies worden ondersteund door configuratiegroepen voor virtuele machines. CloudServiceconfiguratiegroepen bieden geen ondersteuning voor alle functies en er zijn geen nieuwe mogelijkheden gepland. U kunt geen nieuwe cloudServiceConfiguration pools maken of nieuwe knooppunten toevoegen aan bestaande pools na 29 februari 2024. Zie Batch-poolconfiguratie migreren van Cloud Services naar virtuele machine voor meer informatie.

  • classic of simplified knooppuntcommunicatiemodus: Pools kunnen worden geconfigureerd in een van de twee communicatiemodi voor knooppunten, klassiek of vereenvoudigd. In het klassieke communicatiemodel voor knooppunten initieert de Batch-service communicatie met de rekenknooppunten en moeten rekenknooppunten ook communiceren met Azure Storage. In het vereenvoudigde communicatiemodel voor knooppunten starten rekenknooppunten de communicatie met de Batch-service. Vanwege het beperkte bereik van binnenkomende/uitgaande verbindingen die vereist zijn en geen uitgaande toegang van Azure Storage voor basislijnbewerking vereist, is het raadzaam het vereenvoudigde communicatiemodel voor knooppunten te gebruiken. Voor sommige toekomstige verbeteringen in de Batch-service is ook het vereenvoudigde communicatiemodel voor knooppunten vereist. Het klassieke communicatiemodel voor knooppunten wordt op 31 maart 2026 buiten gebruik gesteld.

  • Overwegingen voor taak- en taakuitvoeringstijd: Als u taken hebt die voornamelijk bestaan uit kortlopende taken en de verwachte totale taakaantallen klein zijn, zodat de totale verwachte uitvoeringstijd van de taak niet lang is, wijst u geen nieuwe pool toe voor elke taak. De toewijzingstijd van de knooppunten vermindert de uitvoeringstijd van de taak.

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

  • Afbeeldingen met dreigende EOL-datums (end-of-life): het wordt sterk aanbevolen om afbeeldingen te voorkomen met impenderende EOL-datums (End-Of-Life) van Batch. Deze datums kunnen worden gedetecteerd via de API, PowerShell of Azure CLI. ListSupportedImages Het is uw verantwoordelijkheid om regelmatig uw weergave van de EOL-datums te vernieuwen die relevant zijn voor uw pools en uw workloads te migreren voordat de EOL-datum plaatsvindt. Als u een aangepaste installatiekopieën met een opgegeven knooppuntagent gebruikt, moet u ervoor zorgen dat u batch-einddatums volgt voor de installatiekopieën waarvoor uw aangepaste installatiekopieën zijn afgeleid of zijn uitgelijnd. Een afbeelding zonder een opgegeven batchSupportEndOfLife datum geeft aan dat een dergelijke datum nog niet is bepaald door de Batch-service. Afwezigheid van een datum geeft niet aan dat de betreffende installatiekopie voor onbepaalde tijd wordt ondersteund. Een EOL-datum kan op elk gewenst moment worden toegevoegd of bijgewerkt.

  • VM-SKU's met impenderende end-of-life-datums (EOL): Net als bij VM-installatiekopieën kunnen VM-SKU's of families ook het einde van de levensduur (EOL) van Batch bereiken. Deze datums kunnen worden gedetecteerd via de API, PowerShell of Azure CLI. ListSupportedVirtualMachineSkus Plan de migratie van uw workload naar een niet-EOL VM-SKU door een nieuwe pool te maken met een geschikte ondersteunde VM-SKU. Afwezigheid van een gekoppelde batchSupportEndOfLife datum voor een VM-SKU geeft niet aan dat bepaalde VM-SKU voor onbepaalde tijd wordt ondersteund. Een EOL-datum kan op elk gewenst moment worden toegevoegd of bijgewerkt.

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

  • Continuïteit tijdens onderhoud en storing van pools: u kunt het beste pools dynamisch laten gebruiken voor uw taken. Als uw taken voor alles dezelfde pool gebruiken, is er een kans dat taken niet worden uitgevoerd als er iets misgaat met de pool. Dit principe is vooral belangrijk voor tijdgevoelige workloads. Selecteer of maak bijvoorbeeld dynamisch een pool wanneer u elke taak plant of u kunt de naam van de pool overschrijven, zodat u een beschadigde pool kunt omzeilen.

  • Bedrijfscontinuïteit tijdens het onderhoud en de storing van de pool: er zijn veel redenen waarom een pool mogelijk niet groter wordt dan de gewenste grootte, zoals interne fouten of capaciteitsbeperkingen. Zorg ervoor dat u taken in een andere pool (mogelijk met een andere VM-grootte met behulp van UpdateJob) indien nodig opnieuw kunt instellen. Vermijd het vertrouwen op een statische pool-id met de verwachting dat deze nooit wordt verwijderd en nooit wordt gewijzigd.

Poolbeveiliging

Isolatiegrens

Als voor uw scenario isolatie taken of taken van elkaar moeten worden geïsoleerd, moet u dit doen door ze in afzonderlijke pools te hebben. Een pool is de beveiligingsisolatiegrens in Batch en twee pools zijn standaard niet zichtbaar of kunnen niet met elkaar communiceren. Vermijd het gebruik van afzonderlijke Batch-accounts als een beveiligingsisolatie, tenzij de grotere omgeving van waaruit het Batch-account werkt, isolatie vereist.

Updates voor Batch Node Agent

Batch-knooppuntagents worden niet automatisch bijgewerkt voor pools met niet-zero-rekenknooppunten. Om ervoor te zorgen dat uw Batch-pools de meest recente beveiligingsoplossingen en updates voor de Batch-knooppuntagent ontvangen, moet u de grootte van de pool wijzigen in nul rekenknooppunten of de pool opnieuw maken. Het is raadzaam om de releaseopmerkingen van de Batch Node Agent te controleren om inzicht te hebben in wijzigingen in nieuwe versies van de Batch-knooppuntagent. Regelmatig controleren op updates wanneer ze zijn uitgebracht, kunt u upgrades plannen naar de nieuwste agentversie.

Voordat u de pool opnieuw maakt of het formaat ervan wijzigt, moet u knooppuntagentlogboeken downloaden voor foutopsporing als u problemen ondervindt met uw Batch-pool of rekenknooppunten. Dit proces wordt verder besproken in de sectie Knooppunten .

Notitie

Zie de best practices voor beveiliging en naleving van Batch voor algemene richtlijnen over beveiliging in Azure Batch.

Updates van het besturingssysteem

Het is raadzaam dat de VM-installatiekopieën die voor een Batch-pool zijn geselecteerd, up-to-date moeten zijn met de nieuwste uitgever beveiligingsupdates. Sommige installatiekopieën kunnen automatische updates uitvoeren bij het opstarten (of kort daarna), wat kan interfereren met bepaalde door de gebruiker gerichte acties, zoals het ophalen van updates voor pakketopslagplaats (bijvoorbeeld apt update) of het installeren van pakketten tijdens acties zoals een StartTask.

Azure Batch controleert of garandeert niet dat installatiekopieën die zijn toegestaan voor gebruik met de service, de meest recente beveiligingsupdates hebben. Updates voor installatiekopieën bevinden zich onder de weergave van de uitgever van de installatiekopieën en niet die van Azure Batch. Voor bepaalde afbeeldingen die worden gepubliceerd onder microsoft-azure-batch, is er geen garantie dat deze afbeeldingen up-to-date blijven met hun upstream afgeleide installatiekopieën.

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 gewenst moment een willekeurige levensduur en een verschillend aantal rekenknooppunten hebben. Het is uw verantwoordelijkheid om de rekenknooppunten in de pool expliciet te beheren, of via functies van de service (automatische schaalaanpassing of autopool).

  • Zwembadrecreatie: Vermijd het dagelijks verwijderen en opnieuw maken van pools. Maak in plaats daarvan een nieuwe pool en werk vervolgens uw bestaande taken bij om naar de nieuwe pool te verwijzen. Nadat alle taken zijn verplaatst naar de nieuwe pool, verwijdert u de oude pool.

  • Poolefficiëntie en facturering: Batch zelf brengt geen extra kosten in rekening. Er worden echter kosten in rekening gebracht voor Azure-resources die worden gebruikt, zoals rekenkracht, opslag, netwerken en andere resources die mogelijk nodig zijn voor uw Batch-workload. U wordt gefactureerd voor elk rekenknooppunt in de pool, ongeacht de status waarin het zich bevindt. Zie Kostenanalyse en budgetten voor Azure Batch voor meer informatie.

  • Tijdelijke besturingssysteemschijven: Virtuele-machineconfiguratiegroepen kunnen tijdelijke besturingssysteemschijven gebruiken, die de besturingssysteemschijf in de VM-cache of tijdelijke SSD maken, om extra kosten te voorkomen die zijn gekoppeld aan beheerde schijven.

Pooltoewijzingsfouten

Pooltoewijzingsfouten kunnen zich op elk moment voordoen tijdens de eerste toewijzing of de volgende grootten. Deze fouten kunnen worden veroorzaakt door tijdelijke capaciteitsuitputting in een regio of fouten in andere Azure-services waarop Batch afhankelijk is. Uw kernquotum is geen garantie, maar eerder een limiet.

Niet-geplande uitvaltijd

Batch-pools kunnen downtimegebeurtenissen ervaren in Azure. Begrijpen dat er problemen kunnen optreden en u moet uw werkstroom ontwikkelen om bestand te zijn tegen nieuwe uitvoeringen. Als knooppunten mislukken, probeert Batch deze rekenknooppunten automatisch namens u te herstellen. Dit herstel kan leiden tot het opnieuw plannen van een actieve taak op het knooppunt dat is hersteld of op een ander, beschikbaar knooppunt. Zie Ontwerpen voor nieuwe pogingen voor meer informatie over onderbroken taken.

Aangepaste installatiekopieënpools

Wanneer u een Azure Batch-pool maakt met behulp van de configuratie van de virtuele machine, geeft u een VM-installatiekopieën op die het besturingssysteem biedt voor elk rekenknooppunt in de pool. U kunt de pool maken met een ondersteunde Azure Marketplace-installatiekopieën of u kunt een aangepaste installatiekopieën maken met een installatiekopieën in de Azure Compute Gallery. Hoewel u ook een beheerde installatiekopieën kunt gebruiken om een aangepaste installatiekopieëngroep te maken, raden we u aan om waar mogelijk aangepaste installatiekopieën te maken met behulp van de Azure Compute Gallery. Met behulp van de Azure Compute Gallery kunt u pools sneller inrichten, grotere hoeveelheden VM's schalen en de betrouwbaarheid verbeteren bij het inrichten van VM's.

Installatiekopieën van derden

Pools kunnen worden gemaakt met behulp van installatiekopieën van derden die zijn gepubliceerd naar Azure Marketplace. Met Batch-accounts voor gebruikersabonnementsmodus ziet u mogelijk de fout 'Toewijzing is mislukt vanwege geschiktheidscontrole voor marketplace-aankopen' bij het maken van een pool met bepaalde installatiekopieën van derden. Als u deze fout wilt oplossen, accepteert u de voorwaarden die zijn ingesteld door de uitgever van de installatiekopieën. U kunt dit doen met behulp van Azure PowerShell of Azure CLI.

Azure-regioafhankelijkheid

U moet niet afhankelijk zijn van één Azure-regio als u een tijdgevoelige 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 omhoog te schalen. Als de schaal van die pool mislukt, kunt u terugvallen op het omhoog schalen van een pool in een back-upregio (of regio's).

Pools in meerdere accounts in verschillende regio's bieden een kant-en-klare, eenvoudig toegankelijke back-up als er iets misgaat met een andere pool. Zie Uw toepassing ontwerpen voor hoge beschikbaarheid voor meer informatie.

Projecten

Een taak is een container die is ontworpen voor honderden, duizenden of zelfs miljoenen taken. Volg deze richtlijnen bij het maken van taken.

Minder taken, meer taken

Het gebruik van een taak om één taak uit te voeren, is inefficiënt. Het is bijvoorbeeld efficiënter om één taak te gebruiken die 1000 taken bevat in plaats van 100 taken te maken die elk 10 taken bevatten. Als u 1000 taken hebt gebruikt, elk met één taak die de minst efficiënte, langzaamste en duurste aanpak zou zijn.

Vermijd het ontwerpen van een Batch-oplossing waarvoor duizenden gelijktijdig actieve taken nodig zijn. Er is geen quotum voor taken, dus het efficiënt uitvoeren van veel taken onder zo weinig mogelijk taken maakt efficiënt gebruik van uw taak- en taakplanningsquota.

Levensduur van taken

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

Een taak wordt niet automatisch verplaatst naar de voltooide status, tenzij deze expliciet is beëindigd. Deze actie kan automatisch worden geactiveerd via de eigenschap onAllTasksComplete of maxWallClockTime.

Er is een standaardquotum voor actieve taken en taakplanning. Taken en taakplanningen met de voltooide status tellen niet mee voor dit quotum.

Verwijder taken wanneer ze niet meer nodig zijn, zelfs als ze zijn voltooid. Hoewel voltooide taken niet tellen voor het actieve taakquotum, is het handig om voltooide taken periodiek op te schonen. Het weergeven van taken is bijvoorbeeld efficiënter wanneer het totale aantal taken een kleinere set is (zelfs als de juiste filters op de aanvraag worden toegepast).

Opdrachten

Taken zijn afzonderlijke werkeenheden die deel uitmaken van een taak. Taken worden verzonden door de gebruiker en gepland door Batch op rekenknooppunten. De volgende secties bevatten suggesties voor het ontwerpen van uw taken om problemen op te lossen en efficiënt uit te voeren.

Taakgegevens opslaan

Rekenknooppunten zijn op hun aard kortstondig. Batchfuncties zoals autopool en automatische schaalaanpassing kunnen ervoor zorgen dat knooppunten eenvoudig verdwijnen. Wanneer knooppunten een pool verlaten (vanwege een formaat wijzigen of een pool verwijderen), worden ook alle bestanden op deze knooppunten verwijderd. Vanwege dit gedrag moet een taak de uitvoer van het knooppunt verplaatsen waarop deze wordt uitgevoerd en naar een duurzame opslag voordat deze wordt voltooid. Als een taak mislukt, moeten logboeken worden verplaatst die nodig zijn om de fout in een duurzaam archief vast te stellen.

Batch biedt geïntegreerde ondersteuning voor Azure Storage voor het uploaden van gegevens via OutputFiles, en met verschillende gedeelde bestandssystemen, of u kunt het uploaden 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 retentionTime is ingesteld, schoont Batch automatisch de schijfruimte op die door de taak wordt gebruikt wanneer de retentionTime taak verloopt.

Als u taken verwijdert, worden twee dingen uitgevoerd:

  • Zorgt ervoor dat u geen opbouw van taken in de taak hebt. Met deze actie voorkomt u problemen bij het vinden van de taak waarin u geïnteresseerd bent, omdat u door de voltooide taken moet filteren.
  • Hiermee worden de bijbehorende taakgegevens op het knooppunt opgeschoond (opgegeven retentionTime is nog niet bereikt). Met deze actie kunt u ervoor zorgen dat uw knooppunten niet invullen met taakgegevens en onvoldoende schijfruimte hebben.

Notitie

Voor taken die zojuist naar Batch zijn verzonden, duurt het maximaal 10 minuten voordat de DeleteTask-API-aanroep is doorgevoerd. Voordat deze van kracht wordt, kunnen andere taken mogelijk niet worden gepland. Dit komt doordat Batch Scheduler nog steeds probeert de zojuist verwijderde taken te plannen. Als u één taak kort nadat deze is verzonden, wilt verwijderen, beëindigt u de taak in plaats daarvan (omdat de aanvraag voor de beëindigingstaak onmiddellijk van kracht wordt). En verwijder de taak 10 minuten later.

Grote aantallen taken in verzameling verzenden

Taken kunnen op individuele basis of in verzamelingen worden ingediend. Verzend taken in verzamelingen van maximaal 100 tegelijk wanneer taken bulksgewijs worden verzonden om de overhead en indieningstijd te verminderen.

Het maximum aantal taken per knooppunt instellen

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

Ontwerpen voor nieuwe pogingen en opnieuw uitvoeren

Taken kunnen automatisch opnieuw worden geprobeerd door Batch. Er zijn twee soorten nieuwe pogingen: door de gebruiker beheerd en intern. Door de gebruiker beheerde nieuwe pogingen worden opgegeven door de maxTaskRetryCount van de taak. Wanneer een programma dat is opgegeven in de taak wordt afgesloten met een niet-nul-afsluitcode, wordt de taak opnieuw geprobeerd tot de waarde van de maxTaskRetryCount.

Hoewel een taak zelden opnieuw kan worden uitgevoerd vanwege fouten op het rekenknooppunt, 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 geprobeerd op hetzelfde rekenknooppunt, tot een interne limiet voordat u de taak opgeeft en de taak uitstelt om opnieuw te worden gepland door Batch, mogelijk op een ander rekenknooppunt.

Er zijn geen ontwerpverschillen bij het uitvoeren van uw taken op toegewezen of Spot-knooppunten. Of een taak wordt uitgesteld tijdens het uitvoeren op een Spot-knooppunt of wordt onderbroken vanwege een fout op een toegewezen knooppunt, beide situaties worden beperkt door de taak te ontwerpen om bestand te zijn tegen fouten.

Duurzame taken bouwen

Taken moeten zo zijn ontworpen dat ze bestand zijn tegen fouten en dat ze opnieuw moeten worden geprobeerd. Dit principe is vooral belangrijk voor langlopende taken. Zorg ervoor dat uw taken hetzelfde, één resultaat genereren, zelfs als ze meerdere keren worden uitgevoerd. Een manier om dit resultaat 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 veelvoorkomend voorbeeld is een taak voor het kopiëren van bestanden naar een rekenknooppunt. Een eenvoudige benadering is een taak waarmee alle opgegeven bestanden worden gekopieerd telkens wanneer deze wordt uitgevoerd, wat inefficiënt is en niet is gebouwd om fouten te weerstaan. Maak in plaats daarvan een taak om ervoor te zorgen dat de bestanden zich op het rekenknooppunt bevinden; een taak die geen bestanden die al aanwezig zijn, opnieuw kopieert. Op deze manier wordt de taak opgehaald 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 fractie van de totale rekentijd klein.

Poolbereik gebruiken voor korte taken op Windows-knooppunten

Wanneer u een taak plant 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 automatische gebruikersaccount voor die taak te maken. Voor een grotere efficiëntie kunt u overwegen deze taken in te stellen op poolbereik. Zie Een taak uitvoeren als een automatische gebruiker met poolbereik voor meer informatie.

Knooppunten

Een rekenknooppunt 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.

Begintaken: levensduur en idempotentie

Net als bij andere taken moet de begintaak van het knooppunt idempotent zijn. Starttaken worden opnieuw uitgevoerd wanneer het rekenknooppunt opnieuw wordt opgestart of wanneer de Batch-agent opnieuw wordt opgestart. Een idempotente taak is gewoon een taak die een consistent resultaat produceert wanneer deze meerdere keren wordt uitgevoerd.

Begintaken mogen niet lang worden uitgevoerd of gekoppeld aan de levensduur van het rekenknooppunt. Als u programma's wilt starten die services of services van aard zijn, maakt u een begintaak waarmee deze programma's kunnen worden gestart en beheerd door besturingssysteemfaciliteiten zoals systemd Linux of Windows Services. De begintaak moet nog steeds worden samengesteld als idempotent, zodat de volgende uitvoering van de begintaak correct wordt afgehandeld als deze programma's eerder als services zijn geïnstalleerd.

Tip

Wanneer batch de begintaak opnieuw uitvoert, wordt geprobeerd de begintaakmap te verwijderen en opnieuw te maken. Als batch de begintaakmap niet opnieuw kan maken, kan de begintaak niet worden gestart door het rekenknooppunt.

Deze services mogen geen bestandsvergrendelingen uitvoeren op bestanden in door Batch beheerde mappen op het knooppunt, omdat deze mappen anders niet kunnen worden verwijderd vanwege de bestandsvergrendelingen. In plaats van bijvoorbeeld het starten van de service rechtstreeks vanuit de begintaakwerkmap te configureren, kopieert u de bestanden ergens anders op een idempotente manier. Installeer vervolgens de service vanaf die locatie met behulp van de besturingssysteemfaciliteiten.

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 voor virtuele machines zijn onder andere , , , , en Standard_E64i_v3Standard_GS5. Standard_G5Standard_F72s_v2Standard_M128msStandard_E80ids_v4 Zie Isolatie van virtuele machines in Azure voor meer informatie over geïsoleerde VM-grootten.

Vermijd het maken van adreslijstkoppelingen in Windows

Adreslijstverbindingen, ook wel maphardkoppelingen genoemd, zijn moeilijk om mee te maken tijdens het opschonen van taken en taken. Gebruik symlinks (soft-links) in plaats van vaste koppelingen.

Tijdelijke schijven en AZ_BATCH_NODE_ROOT_DIR

Batch is afhankelijk van tijdelijke VM-schijven, voor vm-compatibele VM-grootten, om metagegevens op te slaan die betrekking hebben op taakuitvoering, samen met artefacten van elke taakuitvoering op deze tijdelijke schijf. Voorbeelden van deze tijdelijke schijfkoppelingspunten of mappen zijn: /mnt/batch, /mnt/resource/batchen D:\batch\tasks. Vervangen, opnieuw koppelen, koppelen, symlinken of anderszins omleiden van deze koppelpunten en mappen of een van de bovenliggende mappen wordt niet ondersteund en kan leiden tot instabiliteit. Als u meer schijfruimte nodig hebt, kunt u overwegen om een VM-grootte of -familie te gebruiken met tijdelijke schijfruimte die voldoet aan uw vereisten of gegevensschijven te koppelen. Zie de volgende sectie over het koppelen en voorbereiden van gegevensschijven voor rekenknooppunten voor meer informatie.

Het koppelen en voorbereiden van gegevensschijven

Aan elk afzonderlijk rekenknooppunt is exact dezelfde gegevensschijfspecificatie gekoppeld als deze is opgegeven als onderdeel van het Batch-poolexemplaren. Alleen nieuwe gegevensschijven kunnen worden gekoppeld aan Batch-pools. Deze gegevensschijven die zijn gekoppeld aan rekenknooppunten, worden niet automatisch gepartitioneerd, geformatteerd of gekoppeld. Het is uw verantwoordelijkheid om deze bewerkingen uit te voeren als onderdeel van uw begintaak. Deze begintaken moeten worden gemaakt om idempotent te zijn. Het opnieuw uitvoeren van de begintaken op rekenknooppunten is mogelijk. Als de begintaak niet idempotent is, kan er mogelijk gegevensverlies optreden op de gegevensschijven.

Tip

Wanneer u een gegevensschijf in Linux koppelt, moet u ervoor zorgen dat er geen afhankelijkheidsraces worden geïntroduceerd bij het nesten van het koppelpunt van de schijf onder de tijdelijke Azure-koppelpunten, zoals /mnt of /mnt/resource. Als deze koppelingen bijvoorbeeld automatisch worden uitgevoerd door het besturingssysteem, kan er een race zijn tussen de tijdelijke schijf die wordt gekoppeld en uw gegevensschijven die onder het bovenliggende item worden gekoppeld. Er moeten stappen worden ondernomen om ervoor te zorgen dat de juiste afhankelijkheden worden afgedwongen door faciliteiten die beschikbaar zijn, zoals systemd of het koppelen van de gegevensschijf uitstellen aan de begintaak als onderdeel van uw idempotent script voor het voorbereiden van de gegevensschijf.

Gegevensschijven voorbereiden in Linux Batch-pools

Azure-gegevensschijven in Linux worden weergegeven als blokapparaten en toegewezen aan een typische sd[X] id. U moet niet afhankelijk zijn van statische sd[X] toewijzingen, omdat deze labels dynamisch worden toegewezen tijdens het opstarten en niet gegarandeerd consistent zijn tussen de eerste en eventuele volgende opstartbewerkingen. U moet uw gekoppelde schijven identificeren via de toewijzingen die worden weergegeven in /dev/disk/azure/scsi1/. Als u bijvoorbeeld LUN 0 hebt opgegeven voor uw gegevensschijf in de AddPool-API, zou deze schijf als manifest zijn /dev/disk/azure/scsi1/lun0. Als u bijvoorbeeld deze map wilt vermelden, kunt u mogelijk het volgende zien:

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

U hoeft de verwijzing niet terug te zetten naar de sd[X] toewijzing in uw voorbereidingsscript. Raadpleeg in plaats daarvan rechtstreeks naar het apparaat. In dit voorbeeld is /dev/disk/azure/scsi1/lun0dit apparaat . U kunt deze id rechtstreeks opgeven bij fdisk, mkfsen andere hulpprogramma's die nodig zijn voor uw werkstroom. U kunt ook de lsblkblkid UUID voor de schijf toewijzen.

Zie dit artikel voor meer informatie over Azure-gegevensschijven in Linux, waaronder alternatieve methoden voor het vinden van gegevensschijven en /etc/fstab opties. Zorg ervoor dat er geen afhankelijkheden of races zijn zoals beschreven in de Tip-notitie voordat u uw methode in productiegebruik promoveert.

Gegevensschijven voorbereiden in Windows Batch-pools

Azure-gegevensschijven die zijn gekoppeld aan Batch Windows-rekenknooppunten worden niet-gepartitioneerd en niet-opgemaakt weergegeven. U moet schijven met partities RAW opsommen voor actie als onderdeel van uw begintaak. Deze informatie kan worden opgehaald met behulp van de Get-Disk PowerShell-cmdlet. U kunt bijvoorbeeld het volgende zien:

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

Waarbij schijfnummer 2 de niet-geïnitialiseerde gegevensschijf is die is gekoppeld aan dit rekenknooppunt. Deze schijven kunnen vervolgens worden geïnitialiseerd, gepartitioneerd en geformatteerd zoals vereist voor uw werkstroom.

Zie dit artikel voor meer informatie over Azure-gegevensschijven in Windows, inclusief PowerShell-voorbeeldscripts. Zorg ervoor dat voorbeeldscripts worden gevalideerd voor idempotentie voordat promotie in productiegebruik wordt uitgevoerd.

Logboeken van Batch-agent verzamelen

Als u een probleem ondervindt met betrekking tot het gedrag van een knooppunt of taken die op een knooppunt worden uitgevoerd, verzamelt u de Logboeken van de Batch-agent voordat u de toewijzing van de betreffende knooppunten ongedaan kunt maken. De Logboeken van de Batch-agent kunnen worden verzameld met behulp van de API voor logboeken van de Batch-service uploaden. Deze logboeken kunnen worden opgegeven als onderdeel van een ondersteuningsticket voor Microsoft en helpen bij het oplossen van problemen en oplossingen.

Upgrades van het besturingssysteem beheren

Voor Batch-accounts in de gebruikersabonnementsmodus kunnen geautomatiseerde besturingssysteemupgrades 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 u ook aan om upgrades van installatiekopieën van het besturingssysteem te plannen voor tijden waarop taken niet worden uitgevoerd.

Voor Windows-pools enableAutomaticUpdates is standaard ingesteld true op. Het toestaan van automatische updates wordt aanbevolen, maar u kunt deze waarde false instellen op als u ervoor moet zorgen dat een update van het besturingssysteem niet onverwacht plaatsvindt.

Batch-API

Time-outfouten

Time-outfouten geven niet noodzakelijkerwijs aan dat de service de aanvraag niet heeft verwerkt. Wanneer er een time-outfout optreedt, moet u de bewerking opnieuw proberen of de status van de resource ophalen, afhankelijk van de situatie, om te controleren of de bewerking is geslaagd of mislukt.

Connectiviteit

Bekijk 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 in een virtueel netwerk voor dat u de richtlijnen met betrekking tot het gebruik van BatchNodeManagement nauw volgt.regioservicetag , poorten, protocollen en richting van de regel. Het gebruik van de servicetag wordt ten zeerste aanbevolen; gebruik geen onderliggende IP-adressen van de Batch-service, omdat ze na verloop van tijd kunnen worden gewijzigd. Het rechtstreeks gebruiken van IP-adressen van de Batch-service kan instabiliteit, onderbrekingen of storingen voor uw Batch-pools veroorzaken.

Voor door de gebruiker gedefinieerde routes (UDR's) is het raadzaam BatchNodeManagement te gebruiken.regioservicetags in plaats van IP-adressen van Batch-services, omdat ze na verloop van tijd kunnen worden gewijzigd.

DNS respecteren

Zorg ervoor dat uw systemen de DNS Time-to-Live (TTL) voor de URL van uw Batch-accountservice respecteren. Zorg er bovendien voor dat uw Batch-serviceclients en andere connectiviteitsmechanismen voor de Batch-service niet afhankelijk zijn van IP-adressen.

Voor HTTP-aanvragen met statuscodes op 5xx-niveau, samen met een header 'Verbinding maken ion: close' in het antwoord, moet u het gedrag van de Batch-serviceclient aanpassen. Uw Batch-serviceclient moet de aanbeveling observeren door de bestaande verbinding te sluiten, DNS opnieuw op te lossen voor de URL van de Batch-accountservice en de volgende aanvragen voor een nieuwe verbinding uit te voeren.

Aanvragen voor opnieuw proberen automatisch

Zorg ervoor dat uw Batch-serviceclients geschikte beleidsregels voor opnieuw proberen hebben om uw aanvragen automatisch opnieuw uit te voeren, zelfs tijdens normale werking en niet uitsluitend tijdens serviceonderhoudsperioden. Deze beleidsregels voor opnieuw proberen moeten een interval van ten minste 5 minuten omvatten. Automatische mogelijkheden voor opnieuw proberen worden geleverd met verschillende Batch-SDK's, zoals de klasse .NET RetryPolicyProvider.

Statische openbare IP-adressen

Doorgaans worden virtuele machines in een Batch-pool geopend via openbare IP-adressen die gedurende de levensduur van de pool kunnen worden gewijzigd. Deze dynamische aard kan het lastig maken om te communiceren met een database of een andere externe service die de toegang tot bepaalde IP-adressen beperkt. U kunt dit probleem oplossen door een groep te maken met behulp van een set statische openbare IP-adressen die u bepaalt. Zie Een Azure Batch-pool met opgegeven openbare IP-adressen maken 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 Verbinding maken iviteit en netwerken voor Azure Cloud Services voor meer informatie.

Onderliggende afhankelijkheden van Batch-knooppunten

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 virtuele machine, die niet mag worden gewijzigd:

Windows:

  • Een gebruiker met de naam PoolNon Beheer
  • Een gebruikersgroep met de naam WATaskCommon

Linux:

  • Een gebruiker met de naam _azbatch

Tip

Naamgeving van deze gebruikers of groepen zijn implementatieartefacten en kunnen op elk gewenst moment worden gewijzigd.

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 zijn geschreven, zijn uw verantwoordelijkheid om op te schonen om te voorkomen dat schijfruimte wordt gevuld.

Het automatisch opschonen van de werkmap wordt geblokkeerd als u een service uitvoert in Windows vanuit de werkmap starttaak, omdat de map nog steeds in gebruik is. Deze actie leidt tot verminderde prestaties. U kunt dit probleem oplossen door de map voor die service te wijzigen in een afzonderlijke map die niet wordt beheerd door Batch.

Volgende stappen