Share via

Tillförlitlighet i Azure Batch

  • Artikel

Den här artikeln beskriver tillförlitlighetsstöd i Azure Batch och beskriver både intraregional återhämtning med tillgänglighetszoner och länkar till information om återställning mellan regioner och affärskontinuitet.

Stöd för tillgänglighetszon

Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.

Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.

Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

Batch upprätthåller paritet med Azure när det gäller stöd för tillgänglighetszoner.

Förutsättningar

  • För batchkonton i användarprenumerationsläge kontrollerar du att prenumerationen där du skapar din pool inte har någon zonerbjudandebegränsning för den begärda virtuella datorns SKU. Om du vill se om din prenumeration inte har några begränsningar anropar du API:et Resurs-Skus-lista och kontrollerar ResourceSkuRestrictions. Om det finns en zonbegränsning kan du skicka ett supportärende för att ta bort zonbegränsningen.

  • Eftersom InfiniBand inte stöder kommunikation mellan zoner kan du inte skapa en pool med en zonindelad princip om kommunikation mellan noder är aktiverad och använder en VM-SKU som stöder InfiniBand.

  • Batch upprätthåller paritet med Azure när det gäller stöd för tillgänglighetszoner. Om du vill använda zonindelningsalternativet måste din pool skapas i en Azure-region med stöd för tillgänglighetszoner.

  • Om du vill allokera batchpoolen mellan tillgänglighetszoner måste Den Azure-region där poolen skapades ha stöd för den begärda VM-SKU:n i mer än en zon. Om du vill verifiera att regionen stöder den begärda virtuella dator-SKU:n i mer än en zon anropar du API:et För Resurs-Skus-lista och kontrollerar locationInfo fältet resourceSkui . Kontrollera att mer än en zon stöds för den begärda virtuella dator-SKU:n. Du kan också använda Azure CLI för att lista alla tillgängliga resurs-SKU:er med följande kommando:

    
    az vm list-skus

Skapa en Azure Batch-pool mellan tillgänglighetszoner

Exempel på hur du skapar en Batch-pool mellan tillgänglighetszoner finns i Skapa en Azure Batch-pool mellan tillgänglighetszoner.

Läs mer om att skapa Batch-konton med Azure-portalen, Azure CLI, PowerShell eller Batch-hanterings-API:et.

Zon-ned-upplevelse

Under ett avbrott i zonen blir noderna i den zonen otillgängliga. Noder i samma nodpool från andra zoner påverkas inte och fortsätter att vara tillgängliga.

Azure Batch-kontot omallokerar eller skapar inte nya noder för att kompensera för noder som har gått ned på grund av avbrott. Användarna måste lägga till fler noder i nodpoolen, som sedan allokeras från andra felfria zoner.

Feltolerans

För att förbereda dig för ett eventuellt fel i tillgänglighetszonen bör du överetablera tjänstens kapacitet för att säkerställa att lösningen kan tolerera kapacitetsförluster på 1/3 och fortsätta att fungera utan försämrad prestanda vid zonomfattande avbrott. Eftersom plattformen sprider virtuella datorer över tre zoner och du måste ta hänsyn till minst fel i en zon multiplicerar du antalet högsta arbetsbelastningsinstanser med en faktor för zoner/(zon 1) eller 3/2. Om din vanliga högsta arbetsbelastning till exempel kräver fyra instanser bör du etablera sex instanser: (2/3 * 6 instanser) = 4 instanser.

Migrering av tillgänglighetszon

Du kan inte migrera en befintlig Batch-pool till stöd för tillgänglighetszoner. Om du vill återskapa batchpoolen mellan tillgänglighetszoner kan du läsa Skapa en Azure Batch-pool mellan tillgänglighetszoner.

Haveriberedskap och affärskontinuitet mellan regioner

Azure Batch är tillgängligt i alla Azure-regioner. Men när ett Batch-konto skapas måste det associeras med en specifik region. Alla efterföljande åtgärder för det Batch-kontot gäller endast för den regionen. Pooler och associerade virtuella datorer skapas till exempel i samma region som Batch-kontot.

När du utformar ett program som använder Batch måste du överväga möjligheten att Batch kanske inte är tillgängligt i en region. Det är möjligt att stöta på en sällsynt situation där det finns ett problem med regionen som helhet, hela Batch-tjänsten i regionen eller ditt specifika Batch-konto.

Om programmet eller lösningen som använder Batch alltid måste vara tillgänglig bör den utformas för att antingen redundansväxlara till en annan region eller alltid ha arbetsbelastningen uppdelad mellan två eller flera regioner. Båda metoderna kräver minst två Batch-konton, där varje konto finns i en annan region.

Du ansvarar för att konfigurera haveriberedskap mellan regioner med Azure Batch. Om du kör flera Batch-konton i specifika regioner och drar nytta av tillgänglighetszoner kan programmet uppfylla dina haveriberedskapsmål när ett av dina Batch-konton blir otillgängligt.

När du ger möjlighet att redundansväxling till en alternativ region måste alla komponenter i en lösning beaktas. Det räcker inte att bara ha ett andra Batch-konto. I de flesta Batch-program krävs till exempel ett Azure-lagringskonto. Lagringskontot och Batch-kontot måste finnas i samma region för godtagbara prestanda.

Tänk på följande när du utformar en lösning som kan redundans:

  • Skapa alla nödvändiga tjänster i varje region i förväg, till exempel Batch-kontot och lagringskontot. Det debiteras ofta ingen avgift för att skapa konton, och avgifter uppstår endast när kontot används eller när data lagras.

  • Kontrollera i förväg att lämpliga kvoter har angetts för alla Batch-konton för användarprenumeration för att allokera det nödvändiga antalet kärnor med batchkontot.

  • Använd mallar och/eller skript för att automatisera distributionen av programmet i en region.

  • Håll programbinärfiler och referensdata uppdaterade i alla regioner. Om du håller dig uppdaterad ser du till att regionen kan anslutas snabbt utan att behöva vänta på uppladdning och distribution av filer. Tänk till exempel på det fall där ett anpassat program som ska installeras på poolnoder lagras och refereras till med hjälp av Batch-programpaket. När en uppdatering av programmet släpps ska den laddas upp till varje Batch-konto och refereras av poolkonfigurationen (eller göra den senaste versionen till standardversion).

  • I programmet som anropar Batch, lagring och andra tjänster gör det enkelt att växla över klienter eller belastningen till olika regioner.

  • Överväg att ofta växla över till en alternativ region som en del av normal drift. Med två distributioner i separata regioner växlar du till exempel över till den alternativa regionen varje månad.

Hur lång tid det tar att återställa efter en katastrof beror på vilken konfiguration du väljer. Själva Batch är oberoende när det gäller om du använder flera konton eller ett enda konto. I aktiva-aktiva konfigurationer, där två Batch-instanser tar emot trafik samtidigt, är haveriberedskapen snabbare än för en aktiv-passiv konfiguration. Vilken konfiguration du väljer ska baseras på affärsbehov (olika regioner, svarstidskrav) och tekniska överväganden.

Haveriberedskap för en region

Hur du implementerar haveriberedskap i Batch är detsamma, oavsett om du arbetar i ett geografiskt område med en region eller flera regioner. De enda skillnaderna är vilka SKU:er som du använder för lagring och om du tänker använda samma eller olika lagringskonto i alla regioner.

Haveriberedskapstestning

Du bör utföra en egen haveriberedskapstestning av din Batch-aktiverade lösning. Det anses vara en bra idé att enkelt växla mellan klient- och tjänstbelastning i olika regioner.

Att testa din haveriberedskapsplan för Batch kan vara så enkelt som att växla Batch-konton. Du kan till exempel förlita dig på ett enda Batch-konto i en viss region under en driftsdag. Nästa dag kan du sedan växla till ett andra Batch-konto i en annan region. Haveriberedskap hanteras främst på klientsidan. Den här metoden med flera konton för haveriberedskap tar hand om RTO- och RPO-förväntningar i geografiska områden med antingen en region eller flera regioner.

Återhämtning av kapacitet och proaktiv haveriberedskap

Microsoft och dess kunder arbetar enligt modellen delat ansvar. Microsoft ansvarar för plattforms- och infrastrukturåterhämtning. Du ansvarar för att hantera haveriberedskap för alla specifika tjänster som du distribuerar och kontrollerar. Så här ser du till att återställningen är proaktiv:

  • Du bör alltid fördistribuera sekundärfiler. Fördistributionen av sekundärfiler är nödvändig eftersom det inte finns någon garanti för kapacitet vid tidpunkten för påverkan för dem som inte har förallokerat sådana resurser.

  • Skapa alla nödvändiga tjänster i varje region, till exempel dina Batch-konton och associerade lagringskonton. Det kostar inget att skapa nya konton. avgifter ackumuleras endast när kontot används eller när data lagras.

  • Kontrollera att lämpliga kvoter har angetts för alla prenumerationer i förväg, så att du kan allokera det nödvändiga antalet kärnor med hjälp av Batch-kontot. Precis som med andra Azure-tjänster finns det gränser för vissa resurser som är associerade med Batch-tjänsten. Många av dessa gränser är standardkvoter som tillämpas av Azure på prenumerations- eller kontonivå. Tänk på dessa kvoter när du utformar och skalar upp dina Batch-arbetsbelastningar.

Kommentar

Om du planerar att köra produktionsarbetsbelastningar i Batch kan du behöva öka en eller flera av kvoterna över standardvärdet. Om du vill höja en kvot kan du begära en kvotökning utan kostnad. Mer information finns i Begära en kvotökning.

Lagring

Du måste konfigurera Batch Storage för att säkerställa att data säkerhetskopieras mellan regioner. kundansvar är standard. De flesta Batch-lösningar använder Azure Storage för att lagra resursfiler och utdatafiler. Till exempel brukar Batch-aktiviteterna (inklusive standardaktiviteter, startaktiviteter, jobbförberedelse- och jobbpubliceringsaktiviteter) definiera resursfiler som finns i ett lagringskonto. Lagringskonton lagrar även data som bearbetas och utdata som genereras. Det är viktigt att du förstår möjliga dataförluster i dina tjänståtgärders regioner. Du måste också bekräfta om data är skrivbara eller skrivskyddade.

Batch stöder följande typer av Azure Storage-konton:

  • GPv2-konton (General-purpose v2)
  • GPv1-konton (General-purpose v1)
  • Blob Storage-konton (stöds för närvarande för pooler i VM-konfigurationen)

Mer information om lagringskonton finns i kontoöversikten för Azure Storage.

Du kan associera ett lagringskonto med ditt Batch-konto när du skapar kontot eller gör det här steget senare.

Om du konfigurerar ett separat lagringskonto för varje region som din tjänst är tillgänglig i måste du använda zonredundanta lagringskonton (ZRS). Använd GZRS-konton (geo-zone-redundant lagring) om du använder samma lagringskonto i flera parkopplade regioner. För geografiska områden som innehåller en enda region måste du skapa ett zonredundant lagringskonto (ZRS) eftersom GZRS inte är tillgängligt.

Kapacitetsplanering är en annan viktig faktor när det gäller lagring och bör hanteras proaktivt. Betänk dina kostnads- och prestandakrav när du väljer lagringskonto. Till exempel har alternativen med GPv2- och blob storage-konto stöd för större kapacitet och skalbarhet jämfört med GPv1. (Kontakta Azure-supporten för att begära en ökning av en lagringsgräns.) De här kontoalternativen kan förbättra prestandan för Batch-lösningar som innehåller ett stort antal parallella uppgifter som läser från eller skriver till lagringskontot.

När ett lagringskonto är länkat till ett Batch-konto bör du se det som ett konto för automatisk lagring. Ett konto för automatisk lagring krävs om du planerar att använda funktionen programpaket , eftersom det används för att lagra programpaketet .zip filer. Ett konto för automatisk lagring kan också användas för aktivitetsresursfiler. Eftersom kontot för automatisk lagring redan är länkat till Batch-kontot undviker detta behovet av SAS-URL:er (signatur för delad åtkomst) för åtkomst till resursfilerna.

Nästa steg