Betrouwbaarheid in Azure Batch

In dit artikel wordt betrouwbaarheidsondersteuning in Azure Batch beschreven en wordt zowel binnen regionale tolerantie behandeld als beschikbaarheidszones en koppelingen naar informatie over herstel in meerdere regio's en bedrijfscontinuïteit.

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's voor meer informatie over zone-redundante architectuur en zone-redundante architectuur.

Batch onderhoudt pariteit met Azure voor ondersteunende beschikbaarheidszones.

Vereisten

• 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 API resource-SKU's 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.

Zone-down-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 knooppuntgroep, die vervolgens worden toegewezen vanuit andere zone(s) die in orde zijn.

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 fout van één zone, vermenigvuldigt u het aantal piekwerkbelastingexemplaren 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 overschakelen naar clients of de belasting 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 best practice om eenvoudig te 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 benadering van meerdere accounts voor herstel na noodgevallen zorgt voor RTO- en RPO-verwachtingen in regio's met één regio of meerdere regio's.

Tolerantie voor capaciteit en proactief herstel na 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:

• U moet altijd secundaire secundaire bestanden vooraf implementeren. De predeployment van secundaire databases is noodzakelijk omdat er geen garantie is voor capaciteit op het moment van impact voor degenen die deze 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.

Notitie

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.

Storage

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 controleren 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 toepassingen 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 de mogelijkheid van 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 account voor automatisch opslaan al is gekoppeld aan het Batch-account, voorkomt u dat er SAS-URL's (Shared Access Signature) nodig zijn voor toegang tot de resourcebestanden.

Volgende stappen

• Betrouwbaarheid in Azure