Tillförlitlighet i Azure Storage Actions

Azure Storage Actions är en fullständigt hanterad plattform som automatiserar datahanteringsuppgifter för Azure Blob Storage och Azure Data Lake Storage. Du schemalägger lagringsuppgifter som ska köras mot dina lagringskonton. Du kan konfigurera uppgifter för att ta bort blobar, ange blobtaggar och ändra åtkomstnivåer baserat på dina datas ålder.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur du gör Azure Storage Actions motståndskraftiga mot tillfälliga fel, konfigurationsproblem, fel i tillgänglighetszonen, regionomfattande fel och serviceunderhåll. Den beskriver även alternativ för säkerhetskopiering och återställning samt viktig information om serviceavtalet Azure Storage Actions (SLA).

Rekommendationer för produktionsdistribution för tillförlitlighet

För produktionsarbetsbelastningar rekommenderar vi att du:

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

När du använder Azure Storage Actions skapar du en eller flera lagringsuppgift-resurser. Varje lagringsaktivitet innehåller villkor som väljer objekt och åtgärder som ska utföras på matchande objekt. Om du vill köra en lagringsaktivitet mot ett lagringskonto skapar du en tilldelning för lagringsaktivitet. Tilldelningen lagras som en del av lagringskontoresursen för lagringskontot och identifierar de objekt som ska vara mål, när och hur ofta aktiviteten körs och var körningsrapporter lagras. När en aktivitetskörning når statusen Completed skriver tjänsten en körningsrapport till den plats som anges i tilldelningen.

Du ansvarar för att konfigurera varje tilldelning och att tilldela en lämplig Azure roll till lagringsuppgiftens hanterade identitet.

Fysisk arkitektur

Azure Storage Actions har två skikt som är relevanta för tillförlitlighet:

• Styrningsplan: Begäranden flödar genom Azure Resource Manager till resursprovidern Azure Storage Actions, som hanterar hanteringsåtgärder och asynkrona etableringsarbetsflöden för lagringsuppgifter och tilldelningar.

• Dataplan: Innehåller schemaläggaren, arbetsprocesser som utvärderar lagringsaktivitetsvillkor och utför de konfigurerade åtgärderna mot mållagringskonton samt rapporteringskomponenter. Dessa komponenter körs på Azure Storage infrastruktur.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av övergående fel.

Tillfälliga fel kan påverka Azure Storage Actions på två huvudsakliga sätt:

• Hanteringsoperationer: Om du automatiserar hanteringen av lagringsåtgärder, till exempel att driftsätta eller ändra lagringsaktiviteter, ansvarar du för att hantera tillfälliga fel i automatiseringen. Använd begränsade återförsök med en lämplig fördröjning mellan försöken.

• Uppgiftskörning: När ett mållagringskonto begränsar åtgärder gör Azure Storage Actions ett uppehåll och försöker igen efter en fördröjning. Så länge tilldelningen fortsätter att göra framsteg fortsätter Storage Actions att försöka igen under arbetsflödets livslängd. Om tilldelningen inte gör några framsteg med att lista eller bearbeta blobar på fyra timmar avslutar Lagringsåtgärder körningen så att en annan tilldelning kan skickas.

Azure Storage Actions bearbetar endast en tilldelning i taget för varje mållagringskonto. Den självreglerar uppgiftskörningen så att programarbetsbelastningar på mållagringskontot har företräde. Exekveringsskalan beror på vilken transaktionskapacitet som är tillgänglig i kontot. När mindre transaktionskapacitet är tillgänglig kan en taskkörning begränsas och ta längre tid att slutföra. Mer information finns i Skalberoende för transaktionskapacitet som är tillgänglig för lagringskontot.

Alla fel vid aktivitetskörning är inte tillfälliga. En uppgift kan till exempel misslyckas eftersom dess hanterade identitet saknar de behörigheter som krävs, antalet begäranden överskrider en skalningsgräns eller mållagringskontot blockerar nätverksåtkomst. Du ansvarar för att övervaka uppgiftsstatus, mätvärden och översikter och korrigera dessa fel. En körningsrapport skapas endast för en körning som når statusen Completed . Misslyckade och överhoppade körningar genererar ingen körningsrapport. Jämför faktiska körningstider med tilldelningsschemat för att identifiera körningar som inte genomfördes. Information om hur du identifierar och löser fel i lagringsuppgifter finns i Felsökning av lagringsuppgifter.

Motståndskraft mot konfigurationsproblem

Villkor för lagringsuppgift avgör vilka objekt en uppgift påverkar, och ett felaktigt villkor eller en felaktig åtgärd kan påverka oavsiktliga objekt. Microsoft kör varje jobb enligt dess konfiguration. Du ansvarar för att verifiera tilldelningsuttrycket innan du tillåter att det ändrar data, särskilt när det innehåller destruktiva eller oåterkalleliga åtgärder.

Använd följande valideringsmetoder:

• Förhandsgranskning av villkor: När du skapar uppgiftsvillkor använder du förhandsgranskningsfunktionen i Azure-portalen eller REST-API:et Preview Actions för att utvärdera ett exempel på upp till 5 000 blobar. En förhandsgranskning returnerar omedelbara resultat och genererar ingen körningsrapport.

• Mock run: Innan du aktiverar tilldelningen för att utföra åtgärder skapar du en mock run för slutlig validering. En mock-körning utvärderar varje blob i tilldelningsomfånget utan att utföra de konfigurerade åtgärderna. Den körs asynkront som en vanlig tilldelning och skapar en CSV-körningsrapport. Granska rapporten för att kontrollera vilka blobar som matchar villkoren och vilka åtgärder uppgiften skulle utföra.

Validering minskar risken för oavsiktliga åtgärder, men ersätter inte dataskyddet. Innan du använder lagringsuppgifter för att ta bort blobar aktiverar du mjuk borttagning för blobar på varje mållagringskonto. Med mjuk borttagning kan du återställa borttagna blobar under den konfigurerade kvarhållningsperioden.

Granska tilldelningar av lagringsuppgift tillsammans med andra datahanteringsprinciper som fungerar på samma blobar. Konfigurera inte överlappande uppgifter eller policyer för att utföra motstridiga åtgärder. En borttagningsåtgärd i en lagringsuppgift kan till exempel misslyckas om en Blob Storage livscykelhanteringsprincip försöker ta bort samma blob.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Kontrollplanet Azure Storage Actions är zonredundant. Microsoft hanterar automatiskt distributionen mellan flera tillgänglighetszoner och du väljer inte zonerna. Under ett fel i tillgänglighetszonen kan du fortsätta att hantera lagringsuppgifter och tilldelningar.

Motståndskraften för körning av uppgifter beror på redundanskonfigurationen för varje mållagringskonto eftersom uppgifterna arbetar med data i dessa konton. Om aktivitetskörningen måste fortsätta under ett zonfel konfigurerar du varje målkonto med ett zonredundant lagringsalternativ (ZRS, GZRS eller RA-GZRS).

I följande exempel visas kontrollplanet för Lagringsåtgärder och en uppgift som riktar sig mot ett zonredundant konto i en region med tre zoner. Både kontrollplanet och målkontot kan fortsätta att fungera om en zon blir otillgänglig:

Ett LRS-målkonto är däremot inte zonredundant. I följande exempel sträcker sig kontrollplanet över alla tre zonerna och målkontot visas i tillgänglighetszon 1 för att illustrera ett konto som inte sträcker sig över zoner. Om zonen som är värd för målkontot blir otillgänglig förblir kontrollplanet tillgängligt, men uppgiften kan inte köras mot målkontot förrän kontot återställs:

Requirements

• Regionstöd: När du konfigurerar en tilldelning av lagringsaktivitet måste lagringsaktiviteten och mållagringskontot finnas i samma region. Om du vill göra aktivitetskörningen elastisk för zonfel väljer du en region som stöder både Azure Storage Actions och tillgänglighetszoner.

• Konfiguration av lagringskonto: Konfigurera varje målkonto med ett zonredundant lagringsalternativ. Lokalt redundant lagring (LRS), geo-redundant lagring (GRS) och geo-redundant lagring med läsåtkomst (RA-GRS) ger inte zonredundans i den primära regionen.

Considerations

Redundans för kontrollplanszoner gör inte uppgiftskörningen motståndskraftig mot zonfel när ett mållagringskonto inte är tillgängligt. Utvärdera redundanskonfigurationen för varje målkonto separat.

Cost

Zonredundans för kontrollplanet Lagringsåtgärder sker automatiskt och det finns ingen extra kostnad för lagringsåtgärder för att aktivera det. Standardanvändningsavgifter för uppgiftskörningar, målobjekt och anropade operationer gäller fortfarande. Mer information finns i prissättningen för Azure Storage Actions.

Redundansalternativet som du väljer för varje mållagringskonto påverkar dina Azure Storage avgifter. Mer information finns i Priser för Blob Storage.

Konfigurera stöd för tillgänglighetszoner

Zonredundansen är automatisk för kontrollplanet för Storage Actions. Du konfigurerar inte zonredundans separat för lagringsuppgifter eller tilldelningar.

Om du vill göra aktivitetskörningen motståndskraftig mot fel i tillgänglighetszoner väljer du ett zonredundant lagringsalternativ när du skapar varje mållagringskonto eller ändrar redundanskonfigurationen för ett befintligt konto.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när kontrollplanet Lagringsåtgärder är tillgängligt, mållagringskonton använder ett zonredundant lagringsalternativ och alla tillgänglighetszoner är i drift.

• Drift över zoner: Microsoft distribuerar infrastruktur för kontrollplan för lagringsåtgärder mellan tillgänglighetszoner. Aktivitetskörningar körs mot varje mållagringskonto och Azure Storage distribuerar förfrågningar transparent över infrastrukturen som är värd för kontot.

• Datareplikering mellan zoner: Storage Actions lagrar eller replikerar inte de blobdata som uppgifter bearbetar.

  Azure Storage replikerar synkront data i konton som använder ett zonredundant lagringsalternativ i tillgänglighetszoner i den primära regionen. Azure Storage slutför inte en skrivåtgärd förrän den replikerar data över de zoner som används av kontot.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när kontrollplanet Storage Actions är tillgängligt, mållagringskonton använder ett zonredundant lagringsalternativ och ett avbrott uppstår i en tillgänglighetszon.

• Identifiering och åtgärd: Microsoft identifierar och åtgärdar fel som påverkar kontrollplanet för Lagringsåtgärder.

  För målkonton som använder ett zonredundant lagringsalternativ dirigerar Azure Storage automatiskt uppgiftskörning och lagringsåtgärder till felfria zoner. Du behöver inte starta failover.

• Anmälan: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva begäranden: Lagringsuppgifter som riktar sig mot tillgängliga zonredundanta konton fortsätter att göra framsteg. Uppgifter som är avsedda för ett otillgängligt konto kan misslyckas.

  Väntande run-once-tilldelningar kan fortfarande hämtas. Körningar som avbröts eller misslyckades kan kräva att du manuellt schemalägger om dem, beroende på var bearbetningen stoppades.

• Beräknad dataförlust: Lagringsåtgärder lagrar inte en separat kopia av dina blobdata. Den förväntade dataförlusten beror på redundanskonfigurationen för varje målkonto. När ett konto använder ett zonredundant lagringsalternativ replikerar Azure Storage synkront sina data mellan tillgänglighetszoner i den primära regionen, så ett zonfel förväntas inte orsaka dataförlust för slutförda skrivningar.

• Förväntad stilleståndstid: Storage Actions-kontrollplanet är fortfarande tillgängligt under ett fel i en zon.

  Uppgiftskörningen fortsätter så länge mållagringskontot förblir tillgängligt. Om kontot blir otillgängligt, till exempel ett LRS-lagringskonto i en berörd zon, kan berörda körningar misslyckas.

• Omfördelning: Microsoft hanterar svaret och omfördelningen av kontrollplanet för Lagringsåtgärder.

  Azure Storage dirigerar automatiskt åtgärder för konton som använder ett zonredundant lagringsalternativ till felfria zoner. Ingen kundåtgärd krävs.

Zonåterställning

När zonen som har fallerat återställs återställer Microsoft normal kontrollplansdistribution. Azure Storage återställer normal drift för zonredundanta konton. Schemalagda uppgiftstilldelningar fortsätter enligt sina scheman.

Återkommande tilldelningar återupptas enligt deras konfigurerade scheman. Väntande run-once-tilldelningar kan fortfarande hämtas. Kontrollera statusen för körningar som påverkas av avbrottet. Beroende på var bearbetningen stoppades kan du behöva schemalägga om avbrutna eller misslyckade körningar.

Test för zonfel

Microsoft hanterar zondistribution, redundansväxling och återställning för kontrollplanet Lagringsåtgärder och för zonredundanta lagringskonton. Du behöver inte testa plattformzonsfel. Testa dina operativa procedurer genom att kontrollera att du kan identifiera misslyckade åtgärder och köra dem på ett säkert sätt igen.

Motståndskraft mot regionomfattande fel

Motståndskraften hos körningen av lagringsuppgifter under ett regionomfattande fel beror på redundanskonfigurationen för varje mållagringskonto. Om ett målkonto använder ett geo-redundant lagringsalternativ (GRS, GZRS, RA-GRS och RA-GZRS) kan lagringskontot växla över till sin kopplade region och framtida lagringsaktivitetskörningar kan fortsätta i den nya primära regionen.

Geo-redundanta mållagringskonton

För ett geo-redundant lagringskonto är den region som för närvarande accepterar skrivåtgärder den primära regionen. Azure Storage replikerar asynkront data till kontots kopplade region, som är den sekundära regionen.

Lagringsuppgifter utförs mot kontot i dess primära region. När kontot redundansväxlar blir den tidigare sekundära regionen den nya primära regionen, och framtida körningar av lagringsuppgifter körs automatiskt där. Azure Storage Actions kräver ingen separat redundansväxlingsåtgärd.

Requirements

• Regionstöd: Mållagringskontot måste finnas i en Azure-region som har en parad region.

• Konfiguration av lagringskonto: Konfigurera målkontot så att det använder ett geo-redundant lagringsalternativ.

Cost

Geo-redundanta lagringskonfigurationer medför avgifter för replikering och lagring i den sekundära regionen. Mer information finns i Priser för Blob Storage.

Konfigurera stöd för flera regioner

Välj ett geo-redundant lagringsalternativ när du skapar mållagringskontot eller ändrar redundanskonfigurationen för ett befintligt konto.

Om du skapar en tilldelning av lagringsuppgift medan målkontot använder ett icke-geo-redundant alternativ och senare konverterar kontot till GRS, GZRS, RA-GRS eller RA-GZRS uppdaterar du tilldelningen innan du initierar en kundhanterad kontofailover. Du kan ändra valfri tilldelningsegenskap. Uppdateringen gör att kontrollplanet för Storage Actions identifierar kontots nya geo-redundanta konfiguration.

Beteende när alla regioner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när ett mållagringskonto använder ett geo-redundant lagringsalternativ och både de primära och sekundära regionerna är i drift.

• Drift mellan regioner: Under normal drift finns lagringsaktivitetsdefinitionen, tilldelningen och mållagringskontot i den primära regionen. Den sekundära regionen bearbetar inte åtgärder för lagringsuppgifter.

• Datareplikering mellan regioner: Azure Storage Actions replikerar inte blobdata som uppgifter bearbetar separat.

  Azure Storage replikerar asynkront data från den primära regionen till den sekundära regionen. Eftersom replikeringen är asynkron kanske de senaste ändringarna ännu inte finns i den sekundära regionen.

Beteende under ett regionfel

I det här avsnittet beskrivs vad du kan förvänta dig när den primära regionen för ett mållagringskonto som använder ett geo-redundant lagringsalternativ inte är tillgängligt.

• Identifiering och åtgärd: Redundansväxling av lagringskonton kan vara kundhanterad eller Microsoft-hanterad. Microsoft-hanterad redundansväxling är reserverad för exceptionella omständigheter och kan inträffa först efter ett utökat avbrott, så förlita dig inte på det för din haveriberedskapsplan. Följ vägledningen för redundansväxling i Blob Storage för att avgöra om och när du ska initiera kundhanterad redundansväxling.

  Azure Storage Actions kräver ingen separat redundansväxlingsåtgärd. Men om du skapade tilldelningen medan målkontot använde LRS och senare konverterade kontot till GRS eller GZRS uppdaterar du tilldelningen innan du initierar kundhanterad redundansväxling för kontot. Mer information finns i Konfigurera stöd för flera regioner.

• Anmälan: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

• Aktiva förfrågningar: Under redundansväxling av lagringskontot är slutpunkterna för det primära och sekundära lagringskontot tillfälligt otillgängliga. Lagringsaktivitetskörningar som pågår kan misslyckas. Efter failover kontrollerar du statusen för berörda task-körningar och kör om misslyckade eller ofullständiga åtgärder efter behov.

  Om den tidigare iterationen pågår när nästa iteration schemaläggs för en återkommande tilldelning hoppar Storage Actions över den nya iterationen. Nästa iteration körs vid dess avsedda utlösartid när den tidigare iterationen har slutförts.

• Förväntad dataförlust: Azure Storage Actions underhåller inte en separat kopia av dina blobdata.

  Under en oplanerad failover kan de senaste ändringarna gå förlorade om de inte har replikerats till den sekundära regionen. En uppgift som misslyckas medan den pågår kan också ha slutfört åtgärder på endast några av dess målobjekt. Efter failover kontrollerar du statusen för berörda taskkörningar och kör om misslyckade eller ofullständiga åtgärder efter behov. Mer information om återställningspunkter för lagringskonton och dataförlust finns i Förväntad dataförlust under ett Blob Storage-regionfel.

• Förväntad stilleståndstid: Innan redundansväxling kan lagringsuppgifter inte fortsätta när mållagringskontot inte är tillgängligt.

  Under redundansväxlingen förblir lagringskontoslutpunkterna otillgängliga, så aktivitetskörningar kan inte göra framsteg och kan misslyckas.

  När redundansväxlingen är klar bearbetar lagringsåtgärdernas dataplanskomponenter i lagringskontots nya primära region framtida körningar av uppgiftstilldelning. Lagringsaktivitetsresursen finns kvar i den ursprungliga regionen, så rapportering för aktivitetsdefinitionen kan fortsätta att påverkas medan den regionen inte är tillgänglig. Rapportering för andra delar av resursen fortsätter att fungera.

  Det totala avbrottet inkluderar tiden för att identifiera avbrott, bestämma om redundansväxling ska initieras och slutföra redundansväxlingen för lagringskontot.

  Om ingen failover sker förblir uppgiftskörningen otillgänglig tills den ursprungliga primära regionen återställs.

  Hanteringsoperationer är fortfarande tillgängliga under ett regionfel.

• Omfördelning: Azure Storage uppdaterar lagringskontots slutpunkter när redundansväxlingen slutförs. Framtida körningar för uppgiftstilldelning körs automatiskt mot kontot i den nya primära regionen. Du behöver inte konfigurera om lagringsuppgiften eller tilldelningen.

Regionåterställning

Failback-processen beror på redundansväxlingstypen för lagringskontot. Följ riktlinjerna för Blob Storage-regionåterställning för att växla tillbaka mållagringskontot. Azure Storage Actions kräver inte ytterligare konfiguration efter återgång för lagringskontot.

Test för regionfel

Om du vill testa återställningsförfarandet utan den dataförlust som är associerad med en oplanerad redundansväxling skapar du representativa lagringsuppgiftstilldelningar mot ett icke-produktionslagringskonto som använder ett geo-redundant lagringsalternativ och initierar sedan en kundhanterad planerad redundansväxling. Granska pågående körning och kontrollera att en framtida schemalagd körning körs mot kontot i den nya primära regionen. Vägledning för testning av redundansväxling finns i Testa för regionfel i Azure Blob Storage.

Anpassade lösningar för flera regioner för återhämtning

Inbyggt stöd för regional redundansväxling för Azure Storage Actions är endast tillgängligt när mållagringskontot finns i en parad region och använder ett geo-redundant lagringsalternativ.

Om lagringslösningen för flera regioner använder oberoende lagringskonton i varje region i stället för redundansväxling för lagringskonto, kan du distribuera en lagringsuppgift i samma region som varje målkonto och skapa en tilldelning för varje konto. Du ansvarar för att replikera data mellan kontona, hålla uppgiftsdefinitioner och tilldelningar synkroniserade och kontrollera vilka tilldelningar som körs under normal drift och felväxling. Se till att tilldelade uppgifter i olika regioner inte utför motstridiga åtgärder på replikerade data.

Säkerhetskopiering och återställning

Om du vill återställa konfigurationen av Azure Storage Actions efter oavsiktlig borttagning definierar du dina lagringsuppgifter och tilldelningar som infrastruktur som kod (IaC) och lagrar definitionerna i versionshantering. Inkludera uppgiftsvillkor och operationer, scheman, omfång för mållagringskonton, inställningar för rapportcontainer, hanterade identiteter och nödvändiga rolltilldelningar. Du kan driftsätta en lagringsaktivitet med hjälp av Bicep och du kan definiera tilldelningar av lagringsaktivitet i Bicep.

Lagringsuppgifter och tilldelade uppgifter består av konfiguration och innehåller inte kunddata som uppgifterna bearbetar. Använd den IaC-metod som beskrevs tidigare för att återställa den här konfigurationen. Du ansvarar för att skydda och återhämta data i dina mållagringskonton separat. Information om Azure Storage dataskyddsalternativ finns i Översikt över dataskydd.

Testa återställningsproceduren i en icke-produktionsmiljö. Innan du aktiverar återskapade tilldelningar använder du villkorsförhandsgranskningar och mock-körningar för att kontrollera att uppgiften riktar sig mot de avsedda blobarna. Mer information finns i Bästa praxis för att använda lagringsaktiviteter.

Motståndskraft mot serviceunderhåll

Microsoft tillämpar regelbundet tjänstuppdateringar och utför annat underhåll. Den Azure plattformen hanterar dessa aktiviteter automatiskt, vilket säkerställer att underhållet är sömlöst och transparent för dig. Ingen driftstopp förväntas under underhållshändelser om du inte har blivit informerad via Azure Service Health planerat underhåll.

Serviceavtal

Azure Storage Actions erbjuder inte något servicenivåavtal (SLA) för tillgänglighet.

Relaterat innehåll

• Översikt över Azure Storage Actions
• Bästa praxis för att använda lagringsaktiviteter
• Övervaka Azure Storage-åtgärder
• Tillförlitlighet i Azure Blob Storage
• Tillförlitlighet i Azure