Delen via

Betrouwbaarheid in Azure Batch

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Batch beschreven. Hierin wordt beschreven hoe u de tolerantie binnen de regio kunt verbeteren met behulp van beschikbaarheidszones, batchgroepen en rekenknooppunten om downtime en gegevensverlies te minimaliseren. Het bevat ook koppelingen naar informatie over herstel in meerdere regio's en bedrijfscontinuïteit.

Ondersteuning voor 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 onderhoudt pariteit met Azure voor ondersteunende beschikbaarheidszones.

Vereiste voorwaarden

  • Voor Batch-accounts voor gebruikersabonnementsmodus moet u ervoor zorgen dat het abonnement waarin u uw pool maakt, geen zoneaanbiedingsbeperking heeft voor de aangevraagde VM-SKU. Als u wilt zien of uw abonnement geen beperkingen heeft, roept u de API voor de lijst met resource-Sku's aan en controleert u het ResourceSkuRestrictions. Als er een zonebeperking bestaat, kunt u een ondersteuningsticket indienen om de zonebeperking te verwijderen.

  • Omdat InfiniBand geen ondersteuning biedt voor communicatie tussen zones, kunt u geen pool maken met een zonegebonden beleid als communicatie tussen knooppunten is ingeschakeld en een VM-SKU gebruikt die InfiniBand ondersteunt.

  • Batch onderhoudt pariteit met Azure voor ondersteunende beschikbaarheidszones. Als u de zonegebonden optie wilt gebruiken, moet uw pool worden gemaakt in een Azure-regio met ondersteuning voor beschikbaarheidszones.

  • Als u uw Batch-pool wilt toewijzen aan meerdere beschikbaarheidszones, moet de Azure-regio waarin de pool is gemaakt, de aangevraagde VM-SKU in meer dan één zone ondersteunen. Als u wilt controleren of de regio de aangevraagde VM SKU in meer dan één zone ondersteunt, roept u de Resource Skus Lijst-API aan en controleert u het locationInfo veld van resourceSku. Zorg ervoor dat meer dan één zone wordt ondersteund voor de aangevraagde VM-SKU. U kunt de Azure CLI ook gebruiken om alle beschikbare resource-SKU's weer te geven met de volgende opdracht:

    
    az vm list-skus

Een Azure Batch-pool maken tussen beschikbaarheidszones

Zie Een Azure Batch-pool maken tussen beschikbaarheidszones voor voorbeelden van het maken van een Batch-pool tussen beschikbaarheidszones.

Meer informatie over het maken van Batch-accounts met Azure Portal, de Azure CLI, PowerShell of de Batch-beheer-API.

Ontspannende ervaring

Tijdens een storing in een zone zijn de knooppunten binnen die zone niet meer beschikbaar. Knooppunten binnen dezelfde knooppuntgroep van andere zone(s) worden niet beïnvloed en blijven beschikbaar.

Het Azure Batch-account kan geen nieuwe knooppunten opnieuw toewijzen of maken om te compenseren voor knooppunten die zijn uitgevallen vanwege de storing. Gebruikers moeten meer knooppunten toevoegen aan de nodepool, die vervolgens worden toegewezen vanuit andere gezonde zone(s).

Fouttolerantie

Als u zich wilt voorbereiden op een mogelijke storing in de beschikbaarheidszone, moet u de capaciteit van de service overschakelen om ervoor te zorgen dat de oplossing 1/3 verlies van capaciteit tolereert en blijft functioneren zonder verminderde prestaties tijdens storingen in de hele zone. Omdat het platform VM's verspreidt over drie zones en u rekening moet houden met ten minste de uitval van één zone, vermenigvuldigt u het aantal piekwerklastinstanties met een factor zones/(zones-1) of 3/2. Als uw typische piekworkload bijvoorbeeld vier exemplaren vereist, moet u zes exemplaren inrichten: (2/3 * 6 exemplaren) = 4 exemplaren.

Migratie van beschikbaarheidszone

U kunt een bestaande Batch-pool niet migreren naar ondersteuning voor beschikbaarheidszones. Als u uw Batch-pool opnieuw wilt maken in meerdere beschikbaarheidszones, raadpleegt u Een Azure Batch-pool maken tussen beschikbaarheidszones.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Azure Batch is beschikbaar in alle Azure-regio's. Wanneer er echter een Batch-account wordt gemaakt, moet dit zijn gekoppeld aan één specifieke regio. Alle volgende bewerkingen voor dat Batch-account zijn alleen van toepassing op die regio. Pools en gekoppelde virtuele machines (VM's) worden bijvoorbeeld gemaakt in dezelfde regio als het Batch-account.

Bij het ontwerpen van een toepassing die gebruikmaakt van Batch, moet u rekening houden met de mogelijkheid dat Batch mogelijk niet beschikbaar is in een regio. Het is mogelijk om een zeldzame situatie tegen te komen waarbij er een probleem is met de regio als geheel, de volledige Batch-service in de regio of uw specifieke Batch-account.

Als de toepassing of oplossing die Gebruikmaakt van Batch altijd beschikbaar moet zijn, moet deze worden ontworpen om een failover naar een andere regio uit te voeren of altijd de werkbelasting te laten splitsen tussen twee of meer regio's. Voor beide benaderingen zijn ten minste twee Batch-accounts vereist, waarbij elk account zich in een andere regio bevindt.

U bent verantwoordelijk voor het instellen van herstel na noodgevallen tussen regio's met Azure Batch. Als u meerdere Batch-accounts uitvoert in specifieke regio's en profiteert van beschikbaarheidszones, kan uw toepassing voldoen aan uw doelstellingen voor herstel na noodgevallen wanneer een van uw Batch-accounts niet meer beschikbaar is.

Wanneer u de mogelijkheid biedt om een failover naar een alternatieve regio uit te voeren, moeten alle onderdelen in een oplossing worden overwogen; Het is niet voldoende om gewoon een tweede Batch-account te hebben. In de meeste Batch-toepassingen is bijvoorbeeld een Azure-opslagaccount vereist. Het opslagaccount en het Batch-account moeten zich in dezelfde regio bevinden voor acceptabele prestaties.

Houd rekening met de volgende punten bij het ontwerpen van een oplossing die failover kan uitvoeren:

  • Maak alle vereiste services in elke regio vooraf, zoals het Batch-account en het opslagaccount. Er worden vaak geen kosten in rekening gebracht voor het maken van accounts en er worden alleen kosten in rekening gebracht wanneer het account wordt gebruikt of wanneer gegevens worden opgeslagen.

  • Zorg ervoor dat de juiste quota zijn ingesteld voor alle Batch-accounts voor gebruikersabonnementen om het vereiste aantal kernen toe te wijzen met behulp van het Batch-account.

  • Gebruik sjablonen en/of scripts om de implementatie van de toepassing in een regio te automatiseren.

  • Houd binaire toepassingsbestanden en referentiegegevens up-to-date in alle regio's. Als u up-to-date blijft, zorgt u ervoor dat de regio snel online kan worden gebracht zonder dat u hoeft te wachten op het uploaden en implementeren van bestanden. Denk bijvoorbeeld aan het geval waarin een aangepaste toepassing die moet worden geïnstalleerd op poolknooppunten wordt opgeslagen en waarnaar wordt verwezen met behulp van Batch-toepassingspakketten. Wanneer een update van de toepassing wordt uitgebracht, moet deze worden geüpload naar elk Batch-account en waarnaar wordt verwezen door de poolconfiguratie (of de nieuwste versie de standaardversie maken).

  • In de toepassing die Batch, opslag en andere services aanroept, kunt u eenvoudig clients en de belasting overzetten naar verschillende regio's.

  • Overweeg regelmatig over te schakelen naar een alternatieve regio als onderdeel van normale werking. Met twee implementaties in afzonderlijke regio's schakelt u bijvoorbeeld elke maand over naar de alternatieve regio.

De tijdsduur voor het herstellen van een noodgeval is afhankelijk van de installatie die u kiest. Batch zelf is agnostisch met betrekking tot of u meerdere accounts of één account gebruikt. In actief-actieve configuraties, waarbij twee Batch-exemplaren gelijktijdig verkeer ontvangen, is herstel na noodgevallen sneller dan voor een actief-passieve configuratie. Welke configuratie u kiest, moet zijn gebaseerd op bedrijfsbehoeften (verschillende regio's, latentievereisten) en technische overwegingen.

Herstel na noodgevallen in één regio

Hoe u herstel na noodgevallen in Batch implementeert, is hetzelfde, ongeacht of u in één regio of in meerdere regio's werkt. De enige verschillen zijn welke SKU u voor opslag gebruikt en of u hetzelfde of een ander opslagaccount in alle regio's wilt gebruiken.

Tests voor herstel na noodgevallen

U moet uw eigen noodhersteltest uitvoeren van uw oplossing met Batch. Het wordt beschouwd als een goede praktijk om eenvoudig te kunnen schakelen tussen client- en servicebelasting in verschillende regio's.

Het testen van uw plan voor herstel na noodgevallen voor Batch kan net zo eenvoudig zijn als het wisselen van Batch-accounts. U kunt bijvoorbeeld afhankelijk zijn van één Batch-account in een specifieke regio voor één operationele dag. Vervolgens kunt u op de volgende dag overschakelen naar een tweede Batch-account in een andere regio. Herstel na noodgevallen wordt voornamelijk beheerd aan de clientzijde. Deze aanpak met meerdere accounts voor disaster recovery houdt rekening met RTO- en RPO-verwachtingen in regio's met één of meerdere geografische gebieden.

Capaciteit en proactieve veerkracht voor herstel bij noodgevallen

Microsoft en haar klanten werken onder het model gedeelde verantwoordelijkheid. Microsoft is verantwoordelijk voor platform- en infrastructuurtolerantie. U bent verantwoordelijk voor het aanpakken van herstel na noodgevallen voor elke specifieke service die u implementeert en controleert. Om ervoor te zorgen dat herstel proactief is:

  • Je moet altijd secundaire elementen vooraf implementeren. De predeployment van secundaire systemen is noodzakelijk omdat er geen garantie is voor voldoende capaciteit op het moment van impact voor degenen die dergelijke resources niet vooraf hebben toegewezen.

  • Maak alle vereiste services in elke regio vooraf, zoals uw Batch-accounts en gekoppelde opslagaccounts. Er worden geen kosten in rekening gebracht voor het maken van nieuwe accounts; kosten worden alleen opgebouwd wanneer het account wordt gebruikt of wanneer gegevens worden opgeslagen.

  • Zorg ervoor dat de juiste quota zijn ingesteld voor alle abonnementen, zodat u het vereiste aantal kernen kunt toewijzen met behulp van het Batch-account. Net als bij andere Azure-services gelden er limieten voor bepaalde resources die zijn gekoppeld aan de Batch-service. Veel van deze limieten zijn standaardquota die door Azure worden toegepast op abonnements- of accountniveau. Houd rekening met deze quota wanneer u uw Batch-workloads ontwerpt en omhoog schaalt.

Opmerking

Als u van plan bent productieworkloads uit te voeren in Batch, moet u mogelijk een of meer van de quota verhogen boven de standaardinstelling. Als u een quotum wilt verhogen, kunt u gratis een quotumverhoging aanvragen. Zie Een quotumverhoging aanvragen voor meer informatie.

Opslag

U moet Batch-opslag configureren om ervoor te zorgen dat er een back-up wordt gemaakt van gegevens in meerdere regio's; klantverantwoordelijkheid is de standaardinstelling. De meeste Batch-oplossingen maken gebruik van Azure Storage voor het opslaan van resourcebestanden en uitvoerbestanden. Uw Batch-taken (inclusief standaardtaken, begintaken, jobvoorbereidingstaken en jobvrijgevingstaken) geven bijvoorbeeld gewoonlijk bronbestanden op die zich in een opslagaccount bevinden. Opslagaccounts slaan ook gegevens op die worden verwerkt en eventuele uitvoergegevens die worden gegenereerd. Het is belangrijk om inzicht te krijgen in mogelijk gegevensverlies in de regio's van uw servicebewerkingen. U moet ook bevestigen of gegevens herschrijfbaar of alleen lezen zijn.

Batch biedt ondersteuning voor de volgende typen Azure Storage-account:

  • Accounts voor algemeen gebruik v2 (GPv2-accounts)
  • Accounts voor algemeen gebruik v1 (GPv1-accounts)
  • Blob-opslagaccounts (momenteel ondersteund voor pools in de configuratie van de virtuele machine)

Zie Overzicht van Azure-opslagaccount voor meer informatie over opslagaccounts.

U kunt een opslagaccount koppelen aan uw Batch-account wanneer u het account maakt of deze stap later uitvoeren.

Als u een afzonderlijk opslagaccount instelt voor elke regio waarin uw service beschikbaar is, moet u ZRS-accounts (zone-redundante opslag) gebruiken. Gebruik geografisch zone-redundante opslagaccounts (GZRS) als u hetzelfde opslagaccount gebruikt in meerdere gekoppelde regio's. Voor geografische gebieden die één regio bevatten, moet u een ZRS-account (zone-redundante opslag) maken omdat GZRS niet beschikbaar is.

Capaciteitsplanning is een andere belangrijke overweging met opslag en moet proactief worden aangepakt. Denk bij het kiezen van een opslagaccount aan de kosten- en prestatievereisten. Het GPv2-account en het Blob Storage-account bieden, vergeleken met een GPv1-account, bijvoorbeeld hogere limieten voor capaciteit en schaalbaarheid. (Neem contact op met de ondersteuning van Azure om een verhoging van een opslaglimiet aan te vragen.) Deze accountopties kunnen de prestaties van Batch-oplossingen verbeteren die een groot aantal parallelle taken bevatten die lezen van of schrijven naar het opslagaccount.

Wanneer een opslagaccount is gekoppeld aan een Batch-account, kunt u dit beschouwen als het automatische opslagaccount. Een autostorage-account is vereist als u van plan bent om de mogelijkheid voor toepassingspakketten te gebruiken, omdat het wordt gebruikt voor het opslaan van het toepassingspakket .zip bestanden. Een autostorage-account kan ook worden gebruikt voor taakresourcebestanden; omdat het autostorage-account al is gekoppeld aan het Batch-account, voorkomt u dat SAS-URL's (Shared Access Signature) toegang hebben tot de resourcebestanden.

Volgende stappen

  • Last updated on