Betrouwbaarheid in Azure Batch

Azure Batch voert grootschalige parallelle en HPC-batchtaken (High Performance Computing) uit in Azure. Batch maakt en beheert pools van rekenknooppunten, installeert de toepassingen die u wilt uitvoeren en plant jobs om op de knooppunten te worden uitgevoerd.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure Batch weerbaar maakt tegen tijdelijke fouten, rekenknooppuntfouten, storingen in de beschikbaarheidszone, regiobrede fouten en serviceonderhoud. Ook worden aanbevelingen voor productie-implementaties beschreven, de Architectuur voor betrouwbaarheid van Batch, back-up en herstel en belangrijke informatie over de Azure Batch sla (Service Level Agreement).

Aanbevelingen voor productie-implementatie

Voor productieworkloads volgt u de aanbevolen procedures voor Azure Batch, waaronder deze aanbevelingen voor betrouwbaarheid:

• Ontwerp taken die onderbrekingen en heruitvoering tolereren. Maak taken idempotent, maak controlepunten voor langlopende taken en sla de vereiste uitvoer- en diagnostische gegevens op in duurzame opslag. Zie Tolerantie voor tijdelijke fouten en tolerantie voor rekenknooppuntfouten voor meer informatie.

• Gebruik meerdere rekenknooppunten wanneer uw workload moet doorgaan na een storing in een knooppunt. Afzonderlijke rekenknooppunten blijven niet gegarandeerd beschikbaar. Voorzie voldoende knooppunten, zodat de resterende bruikbare knooppunten opnieuw geplande taken kunnen uitvoeren.

• Gebruik plaatsing van beschikbaarheidszones wanneer dit wordt ondersteund. Configureer plaatsing in beschikbaarheidszones wanneer de regio, de VM-SKU (virtuele machine) en de workloadconfiguratie deze ondersteunen. Knooppunten in gezonde zones kunnen taken blijven uitvoeren tijdens een zonestoring, maar houd rekening met verminderde capaciteit omdat de vervangingscapaciteit afhankelijk is van het quotum en de beschikbaarheid van vm's in de zones die in orde zijn. Zie Tolerantie voor fouten in beschikbaarheidszones voor meer informatie.

• Ontwerp taken om dynamisch doelpools te targeten in plaats van een vaste pool-id. Met dit ontwerp kunt u een taak omleiden naar een gezonde pool als de oorspronkelijke pool niet meer beschikbaar is of niet kan worden geschaald naar de gewenste capaciteit. Het verbetert de bedrijfscontinuïteit tijdens onderhoud aan of uitval van de pool.

• Poolconfiguraties actueel houden. Bewaak einde-ondersteuningsdatums (EOL) voor Batch voor VM-installatiekopieën en SKU's en migreer pools vóór EOL. Volg de richtlijnen voor serviceonderhoud om de Batch-knooppuntagent actueel te houden.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

Azure Batch gebruikt verschillende resourcetypen om batchworkloads uit te voeren. De configuratie van deze resources bepaalt hoe uw workload reageert op fouten.

Alle Batch-verwerking en -resources zijn gekoppeld aan een Batch-account. Een Batch-oplossing maakt gebruik van de volgende logische onderdelen:

• Batch-account: Een regionale resource waarmee pools, jobs, taken en andere Batch-resources zijn gekoppeld. U maakt het account en selecteert de regio, de pooltoewijzingsmodus en de authenticatie-instellingen.

• Pool: Een verzameling rekenknooppunten waarop taken worden uitgevoerd. De configuratie van een pool definieert de VM-image en -grootte, het aantal doelknooppunten, schaalgedrag, netwerken en zoneplaatsing. U configureert elke pool om de capaciteit, plaatsing en operationele omgeving te bieden die uw workload nodig heeft. Het aantal doelknooppunten is de aangevraagde capaciteit, maar het aantal toegewezen knooppunten kan lager zijn vanwege quotumlimieten, capaciteitsbeperkingen of toewijzingsfouten.

• Jobs en taken: Een job beheert een verzameling taken en is gekoppeld aan een pool. Een taak voert een toepassing of script uit op een rekenknooppunt. U definieert jobs, taken, beperkingen, afhankelijkheden, gedrag voor opnieuw proberen en de pool waarop elke taak wordt uitgevoerd.

• Gekoppeld opslagaccount: Een Azure Storage-account dat u optioneel koppelt aan een Batch-account. De meeste Batch-oplossingen gebruiken een gekoppeld opslagaccount voor toepassingsbestanden, resourcebestanden voor taken, invoergegevens en uitvoergegevens.

  Nadat u een opslagaccount aan een Batch-account hebt gekoppeld, verwijst Batch ernaar als het autostorage-account. Een autostorage-account is vereist voor toepassingspakketten en kan ook taakresourcebestanden opslaan.

  De betrouwbaarheid van een Batch-oplossing is afhankelijk van de opslagresources. U bent verantwoordelijk voor het selecteren van een configuratie voor opslagredundantie die voldoet aan uw herstelvereisten wanneer u het opslagaccount maakt. Verplaats taakuitvoer en andere duurzame gegevens van rekenknooppunten naar opslag. Zie Betrouwbaarheid in Azure Blob Storage voor meer informatie over Azure Storage betrouwbaarheidsopties.

Zie de werkstroom en resources van de Batch-service en batchaccounts en Azure Storage accounts voor meer informatie.

Fysieke architectuur

Azure Batch heeft een regionaal control plane waarmee beheerbewerkingen worden verwerkt voor Batch-accounts en andere Batch-resources, zoals pools, jobs en taken. Het staat los van de rekenknooppunten die taken uitvoeren.

Azure Batch pools gebruiken Azure Virtuele Machines en Virtual Machine Scale Sets. Een rekenknooppunt is een VIRTUELE machine die onderdeel van een Batch-workload verwerkt. Elk knooppunt behoort tot een pool en voert taken uit die de Batch-service eraan toewijst. De Batch-knooppuntagent wordt uitgevoerd op elk knooppunt en biedt de opdracht- en besturingsinterface tussen het knooppunt en de Batch-service. Rekenknooppunten en hun lokale opslag zijn tijdelijk. Wanneer een knooppunt een pool verlaat, gaan wijzigingen in het besturingssysteem en de bestanden verloren.

De pooltoewijzingsmodus van het Batch-account bepaalt waar Batch de reken- en VM-gerelateerde resources maakt:

• Batch-pooltoewijzingsmodus: Batch wijst de resources toe in door de Batch-service beheerde Azure-abonnementen.
• Toewijzingsmodus van de gebruikersabonnementspool: Batch maakt de resources rechtstreeks in het abonnement dat het Batch-account bevat.

De verantwoordelijkheden voor de fysieke architectuur zijn als volgt verdeeld:

• Microsoft: Microsoft beheert het regionale Batch-besturingsvlak en de service-infrastructuur. Batch richt rekenknooppunten in op basis van de poolconfiguratie en beschikbare capaciteit, plant taken, bewaakt de status van de knooppunten en probeert knooppunten te herstellen na infrastructuurfouten. Batch kan onderbroken taken opnieuw in de wachtrij plaatsen voor uitvoering op een ander beschikbaar knooppunt.

• U: U selecteert de VM-image en -grootte, knooppunttypen, het aantal doelknooppunten, schaalconfiguratie, netwerken en plaatsing in beschikbaarheidszones.

  U bent ook verantwoordelijk voor het onderhouden van voldoende capaciteit om knooppuntfouten te tolereren, statussen van knooppunten en taakstatussen te bewaken, het gastbesturingssysteem en de knooppuntagent actueel te houden, taken zo te ontwerpen dat ze opnieuw kunnen worden uitgevoerd en duurzame gegevens van de rekenknooppunten te verplaatsen.

Herstel van Batch-knooppunten garandeert niet dat een workload zonder onderbreking wordt voortgezet. Zie Tolerantie voor fouten in rekenknooppunten voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke fouten voor meer informatie.

Binnen een Batch-oplossing kunnen tijdelijke fouten van invloed zijn op zowel de toepassingen als scripts die worden uitgevoerd als taken en toepassingen die Batch-API's aanroepen om Batch-resources te beheren. Batch biedt mechanismen voor opnieuw proberen op taakniveau. U bent verantwoordelijk voor het configureren van taakbeperkingen, het maken van taken idempotent (veilig om meerdere keren uit te voeren) en het configureren van gedrag voor opnieuw proberen voor aanroepen naar de Batch-service en andere afhankelijkheden.

Nieuwe pogingen en tijdslimieten voor taken

Configureer maxTaskRetryCount om te bepalen hoe vaak Batch een taak opnieuw probeert uit te voeren nadat het proces is afgesloten met een niet-nul-afsluitcode:

• De standaardwaarde, 0betekent dat Batch de taak niet opnieuw probeert uit te voeren na een niet-nul afsluitcode.
• Een positief geheel getal stelt een maximum aantal nieuwe pogingen in na de eerste poging.
• Een waarde van -1 staat onbeperkte nieuwe pogingen toe. Deze waarde wordt niet aanbevolen omdat een aanhoudende fout ertoe kan leiden dat de taak voor onbepaalde tijd wordt uitgevoerd.

Ontwerp elke taak om idempotent te zijn, zodat nieuwe pogingen geen beschadigde gegevens of dubbele uitvoer veroorzaken. Voor langlopende taken gebruikt u checkpointing, zodat een nieuwe poging kan doorgaan vanaf de opgeslagen voortgang. Zie Ontwerpen voor nieuwe pogingen en opnieuw uitvoeren voor meer informatie.

Stel de maxWallClockTime constraint in voor een taak of job om werk te beëindigen dat geen voortgang maakt binnen een acceptabele periode. Een tijdslimiet begrenst ook het effect van herhaalde fouten. Selecteer aantallen nieuwe pogingen en tijdslimieten die overeenkomen met de hersteldoelstellingen van de workload.

Tijdelijke fouten in taakafhankelijkheden

Toepassingen en scripts die als Batch-taken worden uitgevoerd, roepen vaak andere onderdelen aan, zoals Azure Storage, databases of API's. Batch beheert niet de afzonderlijke verzoeken die de taakcode naar deze afhankelijkheden verzendt. Implementeer afhandeling van tijdelijke fouten in de taakcode of gebruik functies voor opnieuw proberen die worden geleverd door de SDK van de afhankelijkheid. Volg de richtlijnen van elke service om fouten te identificeren waarvoor opnieuw proberen mogelijk is, selecteer de juiste instellingen voor uitstel en time-out en volg instructies voor opnieuw proberen, zoals de Retry-After header. Probeer alleen bewerkingen opnieuw die veilig kunnen worden herhaald.

Als een afhankelijkheidsfout ervoor zorgt dat het taakproces wordt afgesloten met een niet-nul-afsluitcode, kan Batch de hele taak opnieuw proberen op basis van maxTaskRetryCount. Batch probeert echter geen afzonderlijke afhankelijkheidsaanvraag opnieuw uit te voeren binnen een actieve taak.

Batch-API-aanvragen opnieuw proberen

Uw toepassingen die buiten de service worden uitgevoerd, kunnen Batch-API's aanroepen om pools, jobs, taken, rekenknooppunten en andere Batch-resources te maken en te beheren. Configureer deze clienttoepassingen met beleid voor nieuwe pogingen dat ten minste vijf minuten beslaat om tijdelijke Batch-service- of netwerkfouten af te handelen.

Gebruik ingebouwde SDK-ondersteuning voor opnieuw proberen wanneer deze beschikbaar is. Bijvoorbeeld stelt de Azure.Compute.Batch client library for .NET nieuw probeergedrag beschikbaar via Azure.Core opties voor opnieuw proberen.

Als u rechtstreeks met de API's van de Batch-service vanuit uw code communiceert, wacht u enkele seconden voordat u het opnieuw probeert, gebruik exponentiële back-off met randomisatie (jitter) om gesynchroniseerde nieuwe pogingen te voorkomen en respecteer de header Retry-After die wordt geretourneerd bij throttlingreacties zoals 429 Too Many Requests en 503 Service Unavailable.

Een time-out van een aanvraag betekent niet noodzakelijkerwijs dat Batch de aanvraag niet heeft verwerkt. Voer na een time-out de bewerking opnieuw uit wanneer dit veilig is, of haal de resourcestatus op om te bepalen of de oorspronkelijke bewerking is geslaagd. Zie Foutafhandeling en -detectie in Azure Batch voor meer informatie.

Tolerantie voor uitval van rekenknooppunten

Een rekenknooppunt kan onbeschikbaar worden vanwege een infrastructuurfout, een probleem met het besturingssysteem of een configuratieprobleem. Batch probeert knooppunten te herstellen die worden beïnvloed door infrastructuurfouten, maar kan niet automatisch elke configuratiegerelateerde storing herstellen. Als een toepassingspakket of container bijvoorbeeld niet kan worden geïnstalleerd, moet u het onderliggende probleem corrigeren en mogelijk het betreffende knooppunt verwijderen en vervangen.

Als een knooppuntfout een taak onderbreekt, kan Batch de taak opnieuw uitvoeren op hetzelfde knooppunt, indien mogelijk, tot een interne limiet. Als de taak niet kan doorgaan op dat knooppunt, kan Batch deze opnieuw in de wachtrij plaatsen voor uitvoering op een ander beschikbaar knooppunt. Deze door services gestuurde herstelpogingen zijn onafhankelijk van maxTaskRetryCount en kunnen zelfs optreden wanneer de waarde 0 is.

herstelproces voor Microsoft beheerde knooppunten

Microsoft beheert servicegestuurd knooppuntherstel en het opnieuw in de wachtrij plaatsen van taken. Als de Batch-service lang genoeg geen heartbeats meer ontvangt van een knooppunt om herstel te activeren, kan Batch de volgende acties uitvoeren:

1. Het knooppunt isoleren: Batch behandelt het knooppunt als ongezond, stelt de status in op unusable en stopt met het plannen van nieuwe taken op het knooppunt.
2. Betrokken taken identificeren: Batch identificeert taken die op het knooppunt werden uitgevoerd als kandidaten voor het opnieuw plannen.
3. Geschikte taken opnieuw in de wachtrij plaatsen: Als een betrokken taak nog steeds in de running status blijft staan, kan Batch deze opnieuw instellen op active zodat de planner deze kan toewijzen aan een ander knooppunt. Batch stelt een taak die al in de status completed gepersistent is niet opnieuw in en voert deze niet opnieuw uit.
4. Het knooppunt herstellen: Batch probeert het knooppunt te herstellen naar een goede status of de onderliggende VM te vervangen.

Herstel is niet ogenblikkelijk. Een taak kan in de status running blijven terwijl Batch de knooppuntfout detecteert en probeert de taak opnieuw te plannen. Als er geen ander rekenknooppunt beschikbaar is, kan de taak in die status blijven totdat Batch het opnieuw kan plannen. Zie Bekende beperkingen voor Batch-taken voor meer informatie.

Als het oorspronkelijke knooppunt de gezonde heartbeats hervat voordat de vervanging begint, kan Batch het herstellen naar een stabiele status. Als de vervanging al is gestart, kan Batch in plaats daarvan de oorspronkelijke VM verwijderen en een vervanging inrichten.

Uw verantwoordelijkheden

Servicegestuurd herstel garandeert geen ononderbroken uitvoering van taken of voldoende resterende capaciteit. U bent verantwoordelijk voor de volgende acties:

• Voldoende capaciteit behouden: Als uw werkbelasting moet doorgaan terwijl een knooppunt niet beschikbaar is, moet u genoeg knooppunten inrichten zodat de resterende knooppunten opnieuw geplande taken kunnen uitvoeren. Zonder een ander bruikbaar knooppunt moeten onderbroken taken wachten.

• Bruikbare capaciteit bewaken: Houd het aantal en statussen van knooppunten bij zodat u kunt detecteren wanneer een pool niet meer over voldoende bruikbare knooppunten beschikt voor uw workload. Statussen zoals unusable, startTaskFailed, unknown en preempted geven een verminderde capaciteit aan. Zie Batch-oplossingen bewaken door taken en knooppunten te tellen op status voor meer informatie.

• Probleemknooppunten onderzoeken: Als taken herhaaldelijk mislukken, opnieuw in de wachtrij worden geplaatst of in de status running blijven nadat het toegewezen knooppunt onbruikbaar is geworden of de pool verlaat, gebruikt u taakmetagegevens om te bepalen of de problemen aan een specifiek knooppunt zijn gekoppeld.

  Voordat u een probleemknooppunt verwijdert, uploadt u de logboeken van de Batch-knooppuntagent en behoudt u relevante taaklogboeken omdat het verwijderen van het knooppunt de lokale bestanden verwijdert. Logboeken van knooppuntagenten kunnen Microsoft Ondersteuning helpen bij het diagnosticeren van Batch-service- of knooppuntproblemen, terwijl taaklogboeken zoals stdout en stderr u kunnen helpen bij het identificeren van problemen met toepassingen en configuratie. Zie Logboekbestanden van de Node-agent voor meer informatie.

• Taakvoortgang en -gegevens beveiligen: Ontwerp taken zo dat ze onderbrekingen tolereren en opnieuw kunnen worden uitgevoerd. Verplaats checkpoints, uitvoer en andere duurzame gegevens van rekenknooppunten omdat hun lokale opslag kortstondig is.

Zie Azure Batch pool- en knooppuntfouten en foutafhandeling en detectie in Azure Batch voor meer informatie.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Batch ondersteunt beschikbaarheidszones op twee belangrijke manieren:

• Control plane: Het Batch-control plane is zonetolerant in veel regio's. In deze regio's kunnen beheerbewerkingen op Batch-accounts en andere Batch-resources worden voortgezet tijdens een zonefout. Microsoft publiceert niet welke regio's deze veerkracht van het besturingsvlak bieden.

• Pools: U kunt een Batch-pool configureren voor het gebruik van plaatsing in beschikbaarheidszones. Als een zone niet beschikbaar is, blijven rekenknooppunten in gezonde zones beschikbaar voor taakplanning.

  Voor plaatsing van rekenknooppunten is dit ondersteuningsmodel vergelijkbaar met zoneredundantie in andere Azure-services, omdat één pool rekenknooppunten in meerdere beschikbaarheidszones kan bevatten. Batch distribueert echter knooppunten over zones op basis van best effort. Het probeert alle zones in de regio te gebruiken, maar garandeert geen plaatsing in elke zone of een gelijkmatige distributie. U kunt geen specifieke zones selecteren of het aantal knooppunten beheren dat in elke zone is geplaatst.

In het volgende diagram ziet u een voorbeeld van een Batch-account. Het account heeft één pool met de bijbehorende knooppunten verdeeld over drie beschikbaarheidszones:

In het diagram ziet u een Batch-account dat één pool bevat. De pool heeft drie rekenknooppunten, met één knooppunt dat wordt weergegeven in elk van de beschikbaarheidszones 1, 2 en 3. plaatsing in beschikbaarheidszones is van toepassing op de rekenknooppunten en bepaalt niet de zoneredundantie van het Batch-besturingsvlak. De distributie is een voorbeeld omdat Batch gebruikmaakt van best-effort-balancering en niet één knooppunt in elke zone garandeert.

U bent verantwoordelijk voor het bestand tegen zone-uitval maken van andere afhankelijke resources, zoals opslagaccounts. Bekijk de betrouwbaarheidsgidsen voor elke dienst. Zie Reliability guides for Azure services (Betrouwbaarheidshandleidingen voor Azure services) voor meer informatie.

Requirements

• Regioondersteuning: Maak de pool in een Azure regio die ondersteuning biedt voor beschikbaarheidszones.

• Beschikbaarheid van VM-SKU: De geselecteerde VM-SKU moet beschikbaar zijn in meer dan één zone in de regio. Gebruik de Resource SKUs List API om het locationInfo-veld voor de VM-SKU te controleren.

• Abonnementstoegang: Voor de gebruikersabonnementspool-toewijzingsmodus mag het abonnement geen zoneaanbiedingsbeperking hebben voor de geselecteerde VM-SKU. Controleer ResourceSkuRestrictions in het API-antwoord van de lijst met resource-SKU's. Als er een beperking bestaat, dient u een supportverzoek in om de verwijdering ervan aan te vragen.

• Communicatie tussen knooppunten: Een pool kan geen plaatsingsbeleid voor beschikbaarheidszones gebruiken wanneer communicatie tussen knooppunten is ingeschakeld met een VM-SKU met infiniBand.

Exemplaardistributie tussen zones

Wanneer u plaatsing in beschikbaarheidszones inschakelt, probeert Batch rekenknooppunten toe te wijzen over alle beschikbaarheidszones in de geselecteerde regio. Deze toewijzing wordt op basis van best effort uitgevoerd. Batch bepaalt de distributie en het aantal knooppunten in elke zone is mogelijk niet gelijk.

Cost

AWS Batch voegt geen kosten toe voor het inschakelen van plaatsing van beschikbaarheidszones. U wordt gefactureerd voor de reken-, opslag-, netwerk- en andere Azure resources die door de workload worden gebruikt. Als u extra knooppunten inricht om het verlies van een zone te tolereren, worden voor deze knooppunten normale kosten in rekening gebracht. Zie Azure Batch prijzen voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

• Maak een nieuwe pool met plaatsing in beschikbaarheidszones: Zie Een Batch-pool maken in verschillende beschikbaarheidszones om een pool te maken waarvoor plaatsing in beschikbaarheidszones is ingeschakeld.

• Plaatsing in beschikbaarheidszones voor een bestaande pool wijzigen: U moet plaatsing in beschikbaarheidszones selecteren wanneer u de pool maakt. U kunt een bestaande pool niet wijzigen om beschikbaarheidszones te gebruiken.

  U kunt een vervangende pool maken en elk van uw jobs bijwerken om deze te gebruiken met behulp van de volgende stappen:

  1. Schakel de job uit: Gebruik de bewerking Job uitschakelen en selecteer hoe Batch omgaat met taken die worden uitgevoerd wanneer u de aanvraag indient:

     • Wacht: Batch stopt met het starten van nieuwe taken en laat actieve taken op de bestaande pool worden voltooid. De taak blijft in de disabling status totdat de actieve taken zijn voltooid.
     • Opnieuw in wachtrij plaatsen: Batch onderbreekt actieve taken en retourneert ze naar de wachtrij. De taken kunnen opnieuw worden uitgevoerd nadat u de job hebt ingeschakeld.
     • Beëindigen: Batch onderbreekt actieve taken en markeert ze als voltooid met foutinformatie die aangeeft dat ze zijn beëindigd. De taken worden niet opnieuw uitgevoerd nadat u de job hebt ingeschakeld.

     Taken die al de status active hebben, wat betekent dat ze in de wachtrij staan maar niet worden uitgevoerd, blijven met elke optie in de wachtrij.

     Wacht totdat de taak de disabled status bereikt voordat u doorgaat. Op dat moment worden er geen taken uitgevoerd en plant Batch geen nieuwe taken.

  2. De pool van de taak bewerken: Gebruik de bewerking Taak bijwerken om de poolInfo.poolId van de taak in te stellen op de vervangende pool. In Batch kan deze eigenschap alleen worden gewijzigd terwijl de taak de disabled status heeft. Zorg ervoor dat de vervangende pool bestaat en bruikbare capaciteit heeft voordat u de job inschakelt. Als de pool niet bestaat, accepteert Batch de update, maar kan deze pas taken plannen nadat u de pool hebt gemaakt.

  3. Schakel de taak in: Gebruik de bewerking Taak inschakelen . De taak gaat via de enabling-status naar de active-status. Batch plant vervolgens taken in de wachtrij, inclusief taken die door de optie Opnieuw in wachtrij plaatsen worden geretourneerd, op de vervangingspool. Taken die zijn voltooid terwijl Batch de optie Wachten heeft toegepast en taken die met de optie Beëindigen zijn voltooid, worden niet opnieuw uitgevoerd.

Capaciteitsplanning en -beheer

Het normale knooppuntherstelproces van Batch probeert knooppunten te vervangen die onbruikbaar worden tijdens een zonefout en de pool te herstellen naar het geconfigureerde aantal doelknooppunten. Dat doel wordt niet verhoogd. Als u voldoende capaciteit wilt behouden voor de workload om door te gaan wanneer één zone niet beschikbaar is, kunt u overwegen de capaciteit van de pool te overprovisioneren met behulp van automatisch schalen of handmatig:

• Als u automatische schaalaanpassing gebruikt: Verwijs naar de door de $UsableNodeCount service gedefinieerde variabele in de formule voor automatische schaalaanpassing van de pool om te detecteren wanneer bruikbare capaciteit lager is dan de basislijn die uw workload nodig heeft. $UsableNodeCountis een variabele voor automatische schaalaanpassing van Batch voor de pool waarvan de formule wordt geëvalueerd, niet een Azure Monitor metrische waarde. Azure Monitor publiceert metrische gegevens van Batch-knooppunten op het bereik van het Batch-account en deze metrische gegevens hebben geen poolId-dimensie.

• Als u de capaciteit handmatig beheert: Gebruik de bewerking List Pool Node Counts om het aantal toegewezen knooppunten en Spot-knooppunten in elke status voor elke pool op te halen. De bewerking levert geen afzonderlijk aantal bruikbare knooppunten op. Evalueer taakstatussen zoals idle en running ten opzichte van niet-beschikbare statussen of probleemstatussen zoals unusable, unknown, offline en startTaskFailed. De geretourneerde aantallen zijn mogelijk niet actueel, dus inventariseer de rekenknooppunten van de pool wanneer u een exacte telling nodig hebt.

Batch distribueert knooppunten over zones op basis van best effort, zodat de werkelijke verdeling mogelijk niet gelijk is. Ga er niet van uit dat knooppunten gelijkmatig worden verdeeld over zones wanneer u capaciteit plant. Valideer of uw workload kan voldoen aan de hersteldoelstellingen met verminderde poolcapaciteit.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Batch-pool de plaatsing van de beschikbaarheidszone gebruikt en alle zones operationeel zijn.

• Cross-zone-bewerking: Batch plant taken op beschikbare rekenknooppunten in de hele pool, ongeacht de zone waarin elk knooppunt zich bevindt.

• Replicatie van gegevens in meerdere zones: Batch-rekenknooppunten zijn kortstondig en Batch repliceert geen taakbestanden tussen zones. U bent verantwoordelijk voor het verplaatsen van invoer, uitvoer, controlepunten en diagnostische gegevens die bij uitval van een knooppunt in duurzame opslag bewaard moeten blijven. Configureer de redundantie van het opslagaccount om te voldoen aan uw beschikbaarheidsvereisten.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Batch-pool de plaatsing van de beschikbaarheidszone gebruikt en één beschikbaarheidszone niet beschikbaar is.

• Detectie en reactie: Microsoft bewaakt de Batch-service en de status van de rekenknooppunten. Tijdens een zonefout detecteert Batch aanhoudende heartbeatverlies van betrokken knooppunten en start het normale herstelproces voor knooppunten. Knooppunten in zones met een goede status blijven beschikbaar en Batch kan er taken op blijven plannen.

  Batch probeert de pool te herstellen naar het geconfigureerde doelknooppuntaantal via het normale herstelproces, maar het verhoogt dat doel niet. U bent verantwoordelijk voor het aanvragen van extra capaciteit als de doelresource onvoldoende capaciteit biedt voor de workload.

• Notification: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve taken: Taken die worden uitgevoerd op betrokken knooppunten, worden onderbroken. Batch kan taken op beschikbare knooppunten opnieuw plannen als onderdeel van het interne herstelgedrag. Ontwerp taken zodanig dat ze opnieuw proberen en heruitvoering kunnen verdragen, zoals beschreven in Tolerantie voor tijdelijke fouten en tolerantie voor fouten in rekenknooppunten.

• Verwacht gegevensverlies: Bestanden op betrokken rekenknooppunten zijn niet beschikbaar tijdens de storing en gaan verloren als de knooppunten opnieuw worden ingericht of verwijderd uit de pool. Batch repliceert deze bestanden niet over zones heen. Gegevens die worden bewaard in persistente opslag, blijven beschikbaar volgens de redundantieconfiguratie van die opslagresource.

• Verwachte uitvaltijd: Taken op gezonde knooppunten gaan door. Onderbroken taken ondervinden downtime totdat Batch ze opnieuw kan plannen op bruikbare knooppunten. Als er geen bruikbaar knooppunt beschikbaar is, kan een taak in de status running blijven totdat Batch het opnieuw kan plannen. De hersteltijd is afhankelijk van de beschikbare poolcapaciteit en de workload in de wachtrij.

  Beheerbewerkingen voor Batch-accounts en andere Batch-resources worden voortgezet als het account zich in een regio bevindt waarin het besturingsvlak zonebestendig is. In andere regio's zijn beheerbewerkingen mogelijk niet beschikbaar totdat de betrokken zone wordt hersteld.

• Herdistributie: Na aanhoudend heartbeatverlies markeert Batch de betrokken knooppunten als unusable en verzendt deze voor vervanging via het normale herstelproces voor knooppunten. Batch probeert de pool te herstellen naar het geconfigureerde aantal doelknooppunten, maar de vervangingscapaciteit is afhankelijk van het quotum en de beschikbaarheid van vm's in de zones die in orde zijn.

  Taken blijven tijdens dit proces gekoppeld aan de pool. Batch blijft taken plannen van actieve jobs op bruikbare knooppunten in gezonde zones. Als er vervangingsknooppunten worden toegewezen en bruikbaar worden, kan Batch ook taken op die knooppunten plannen.

  Met dit herstelproces wordt het aantal geconfigureerde doelknooppunten niet verhoogd. Als voor uw workload capaciteit buiten dat doel is vereist, verhoogt u deze handmatig of configureert u de formule voor automatische schaalaanpassing van de pool om dit te doen.

Herstel van zone

Batch beheert het herstelproces wanneer een zone herstelt na een fout. Batch volgt hetzelfde proces dat is gedefinieerd in Tolerantie voor fouten in rekenknooppunten.

Batch garandeert niet dat knooppunten na herstel gelijkmatig worden verdeeld over beschikbaarheidszones. De plaatsing van zones blijft op basis van best effort.

Testen op zonefouten

U kunt voor testdoeleinden geen werkelijke storing in een Azure-beschikbaarheidszone simuleren. Gebruik in plaats daarvan een niet-productiegroep om representatieve taken te onderbreken en voldoende rekenknooppunten buiten gebruik te nemen om het verwachte capaciteitsverlies te benaderen. Overweeg het gebruik van de volgende ondersteunde knooppuntbewerkingen:

• Geselecteerde knooppunten opnieuw opstarten.
• Taakplanning op geselecteerde knooppunten uitschakelen.
• Geselecteerde knooppunten uit de pool verwijderen.

Wanneer u met een bewerking kunt kiezen hoe u actieve taken afhandelt, selecteert u de optie Opnieuw in wachtrij plaatsen, zodat Batch de onderbroken taken op de resterende knooppunten kan plannen.

Controleer tijdens de test of Batch onderbroken taken opnieuw inplant en dat opnieuw uitvoeren niet leidt tot dubbele of inconsistente uitvoer. Controleer of controlepunten en uitvoer beschikbaar blijven in duurzame opslag, bewaking detecteert knooppuntverlies en verminderde capaciteit en de workload kan worden voltooid met de resterende capaciteit.

Deze bewerkingen valideren taakonderbrekingen en opnieuw plannen, idempotentie, controlepunten en duurzame uitvoerafhandeling. Ze reproduceren echter niet elk effect van een zonebrede storing.

Tolerantie voor storingen in de hele regio

Een Batch-account en de bijbehorende pools zijn beperkt tot één Azure-regio. Als er een fout optreedt in de regio, kunnen uw Batch-taken en -pools worden beïnvloed.

Batch repliceert geen accounts, poolconfiguratie, jobs, taken, toepassingspakketten of taakgegevens naar een andere regio en biedt geen ingebouwde failover tussen regio's. U bent verantwoordelijk voor het implementeren en uitvoeren van een Batch-oplossing voor meerdere regio's wanneer uw workload een storing in de hele regio moet tolereren.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Als u een oplossing voor meerdere regio's wilt bouwen, implementeert u ten minste één Batch-account in elke regio die door uw herstelontwerp wordt gebruikt. Batchaccounts werken onafhankelijk in verschillende regio's. U bent verantwoordelijk voor het selecteren van de regio's, het implementeren en beheren van de resources in elke regio en het coördineren van configuratie, replicatie, failover en failback.

U kunt een actief-actief benadering ontwerpen waarmee tijdens normale werking werk in meerdere regio's wordt verzonden of een actief-passieve benadering waarmee de secundaire implementatie gereed blijft voor failover. Actief-actieve ontwerpen kunnen de hersteltijd verminderen omdat beide implementaties werk verwerken tijdens normale werking, terwijl actief-passieve ontwerpen de doorlopende rekenkosten kunnen verminderen.

De volgende lijst bevat voorbeelden van uw verantwoordelijkheden bij het ontwerpen van de oplossing:

• Uitrol: Maak de Batch-accounts, pools of poolimplementatiedefinities, opslagaccounts, netwerkresources en andere afhankelijkheden in elke regio vooraf. Controleer of elke geselecteerde regio ondersteuning biedt voor de Batch-functies, VM-grootten en afhankelijke services die uw workload nodig heeft. Bewaar elk Batch-account en de opslagbronnen die door de bijbehorende taken worden gebruikt indien mogelijk in dezelfde regio om onnodige latentie te voorkomen. Definieer Batch-accounts, -pools en ondersteunende resources met behulp van infrastructuur als code, zodat de configuratie consistent kan worden gereproduceerd in verschillende regio's.

• Quota en capaciteit: Controleer de toepasselijke Batch-account-, abonnements- en VM-familiequota in elke herstelregio en vraag zo nodig om verhogingen voordat er een storing optreedt. Een quotum is een limiet, geen capaciteitsgarantie. Beschikbaarheid van VM's verschilt per regio, VM-familie en in de tijd. Zie Batch-account- en corequota voor meer informatie.

• Gegevensreplicatie: Houd toepassingspakketten, containerimages, invoergegevens en referentiegegevens beschikbaar in elke herstelregio. Batch repliceert deze items niet voor u.

• Opslagreplicatie: Configureer opslagredundantie en replicatie van gegevens in meerdere regio's op basis van uw herstelpuntdoelstelling. Controleer of gerepliceerde gegevens toegankelijk zijn vanuit elke herstelregio. Zie Betrouwbaarheid in Azure Blob Storage voor opties voor betrouwbaarheid van opslag.

• Doelregio: Als uw toepassingen met uw Batch-account werken, ontwerpt u deze zo dat ze een ander Batch-account en de bijbehorende opslagbronnen kunnen selecteren zonder dat hiervoor een code-implementatie is vereist.

• Failover: Batch verplaatst uw workload niet automatisch naar een andere regio. U bent verantwoordelijk voor het detecteren van een storing, het bepalen hoe de storing van invloed is op uw workload, het stoppen van inzendingen naar het betrokken Batch-account, het doorsturen van nieuw werk naar een Batch-account in een gezonde regio en het beslissen of u onderbroken taken opnieuw wilt indienen. Werk- of taakuitvoer die u niet buiten de betrokken regio hebt gerepliceerd, is mogelijk niet beschikbaar of verloren gegaan. Uw hersteltijd is afhankelijk van uw implementatiemodel, beschikbare capaciteit, gegevensreplicatie en automatisering.

• Regioherstel: Nadat de beschikbaarheid van de service is hersteld in de betrokken regio, valideert u het Batch-account, de pools, de opslagafhankelijkheden en de taakstatus voordat u het werk naar die regio leidt. Dubbele of gedeeltelijk voltooide taken afhandelen voordat ze opnieuw worden ingediend. Batch coördineert dit proces niet en synchroniseert de status niet tussen regionale accounts.

• Testen: Test regelmatig het volledige regionale herstelproces in een niet-productieomgeving. Simuleer dat één regionale implementatie niet beschikbaar wordt, stuur inzendingen door naar een ander regionaal Batch-account, valideer de toegang tot toepassingspakketten en invoergegevens, voer representatieve taken uit, verzamel uitvoer en oefen met het terug in gebruik nemen van de herstelde implementatie. Meet de resultaten af tegen uw beoogde hersteltijd en herstelpuntdoelstelling.

Back-up maken en terugzetten

Azure Batch is geen duurzame opslag voor de invoer- en uitvoergegevens van de workload. Microsoft onderhoudt de Batch-service, maar u bent verantwoordelijk voor het behouden van de configuratie en gegevens die nodig zijn om uw workload opnieuw te maken:

• Batchconfiguratie: Definieer Batch-accounts, -pools, -jobs en ondersteunende resources met behulp van infrastructuur als code, zoals Bicep en door versie beheerde taakdefinities. Deze artefacten bieden een herhaalbare manier om de configuratie in dezelfde regio of een andere regio opnieuw te maken. Test regelmatig of de definities een pool kunnen uitrollen en een representatieve taak kunnen uitvoeren.

• Batchmetagegevens: Batch bewaart job- en taakrecords totdat u de bijbehorende job of taak verwijdert, maar deze records zijn geen back-up. Als u deze geschiedenis wilt behouden, moet u de vereiste records buiten Batch behouden.

• Gegevens op rekenknooppunten: Rekenknooppunten zijn kortstondig en hun bestandssystemen zijn geen back-up of duurzame opslag. Gegevens op een knooppunt gaan verloren wanneer het knooppunt opnieuw van een image wordt voorzien of een pool verlaat. Batch kan ook taakbestanden verwijderen nadat de bewaarperiode is verlopen. Bewaar de vereiste uitvoer- en diagnostische logboeken naar duurzame opslag voordat een taak wordt voltooid. Voor langlopende taken moet u checkpoints opslaan tijdens de uitvoering. Zie Job- en taakuitvoer behouden en Azure Batch bewaken voor meer informatie.

• Gegevens in autostorage-accounts: Een gekoppeld autostorage-account kan toepassingspakketten en taakresourcebestanden bevatten. Naast het configureren van redundantie die voldoet aan uw hersteldoelstellingen, moet u overwegen of u deze gegevens moet beschermen tegen onbedoelde verwijdering of beschadiging. Zie Back-up en herstel in Azure Blob Storage voor meer informatie.

Testen van terugzetten en herstel

Om te herstellen, implementeert u de Batch- en ondersteunende resourceconfiguratie, herstelt of verbindt u de vereiste invoergegevens en toepassingsartefacten opnieuw en dient u werk dat niet is voltooid opnieuw in. Test periodiek zowel resourcereconstructie als herstel van gegevens in een geïsoleerde of niet-productieherstelomgeving. Gebruik versiebeheerde definities en back-upgegevens, voer een representatieve taak uit, controleer de resulterende uitvoer en toegang tot afhankelijkheden en meet de bereikte hersteltijd en het herstelpunt op basis van uw doelstellingen. Controleer of taken idempotent zijn, zodat het opnieuw indienen van werk met onzekere status geen gegevens beschadigt of dubbele uitvoer maakt.

Tolerantie voor serviceonderhoud

Microsoft voert platformonderhoud uit en coördineert infrastructuurupdates voor Azure Batch en andere services. U bent verantwoordelijk voor het configureren van het gedrag van poolupdates en het ontwerpen van taken om onderbrekingen te verdragen.

• Hostonderhoud: Azure maakt gebruik van onderhoudstechnieken zoals livemigratie, indien mogelijk. Als onderhoud vereist dat een rekenknooppunt opnieuw wordt opgestart of verplaatst, kunnen actieve taken worden onderbroken en kan Batch deze opnieuw plannen. Maak taken idempotent en sla controlepunten en uitvoer op in duurzame opslag.

• Gastbesturingssysteem: U bent verantwoordelijk voor het actueel houden van het gastbesturingssysteem en de Batch-knooppuntagent. Het updategedrag van het besturingssysteem is afhankelijk van de installatiekopie en updateconfiguratie. Met de juiste configuratie kunnen automatische upgrades van installatiekopieën van het besturingssysteem voor Batch-pools poolknooppunten bijwerken zonder actieve taken te onderbreken. Automatische upgrades van installatiekopieën van het besturingssysteem ondersteunen niet elke installatiekopie van het Batch-besturingssysteem.

• Updates van knooppuntagent: Automatische upgrades van installatiekopieën van het besturingssysteem werken de Batch-knooppuntagent niet automatisch bij. Batch-knooppuntagents worden niet automatisch bijgewerkt zolang een pool rekenknooppunten heeft. Als u een nieuwere node agent wilt ontvangen, wijzigt u de grootte van de pool in nul knooppunten en schaalt u deze opnieuw op of vervangt u de pool. Voordat u knooppunten verwijdert, moet u alle vereiste taakuitvoer- en diagnostische logboeken behouden. Zie Updates van Batch-knooppuntagenten voor meer informatie.

Volg de aanbevelingen voor de productie-implementatie en richtlijnen voor rekenknooppuntfouten om uw workload draaiende te houden of te herstellen wanneer onderhoud taken onderbreekt of rekenknooppunten niet beschikbaar maakt.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

De SLA voor Azure Batch-beschikbaarheid is van toepassing op bewerkingen die u via de Batch-API uitvoert. Raadpleeg de SLA-formulering voor gedetailleerde informatie over de typen activiteiten die zijn opgenomen. De grootte van uw pool, zonedistributie en afhankelijke services zijn van invloed op de end-to-end beschikbaarheid van de workload, maar wijzigen de voorwaarden van de Batch SLA niet.

Verwante onderwerpen

• Documentatie voor Azure Batch
• Aanbevolen werkwijzen voor Azure Batch
• Betrouwbaarheid in Azure