Tillförlitlighet i Azure Storage Actions

Den här artikeln beskriver tillförlitlighetsstöd i Azure Storage Actions och beskriver både intraregional återhämtning med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitlighetsprinciper i Azure finns i Azures tillförlitlighet.

Azure Storage Actions är ett serverlöst ramverk som du kan använda för att utföra vanliga dataåtgärder på miljontals objekt i flera lagringskonton. Själva tjänsten är regional och har inte SKU:er eller stöd för tillgänglighetszoner. Kontrollplanet för tjänsten stöder dock automatiskt zonredundans. Dataplanet kan också ha stöd för redundans beroende på om lagringskontot körs på en zonredundant konfiguration.

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.

Även om Azure Storage Actions-tjänsten är regional och inte erbjuder SKU:er eller tillgänglighetszoner, är zonredundans tillgänglig från kontrollplanet och villkorligt från dataplanet:

• Kontrollplanet för tjänsten är zonredundant. När en zon är nere i en region fortsätter kontrollplanet att vara tillgängligt. Under ett zon-ned-scenario kan du fortsätta att hantera uppgiftsdefinition och tilldelning.

• Dataplanet (körning av aktivitetstilldelning) ärver zonegenskaperna från det överordnade lagringskontot. Om lagringskontot distribueras till en misslyckad zon blir kontot otillgängligt och från kundens perspektiv är dataplanen inte tillgänglig. Om lagringskontot är zonredundant fortsätter kontot att vara tillgängligt och tjänsten fortsätter att utföra åtgärden på kontot.

Zon-ned-upplevelse

I ett zon färdigt scenario fortsätter tjänsten Storage Action att vara tillgänglig. Förloppet för aktiviteter beror på tillgänglighetszonens stöd för lagringskonton som de körs mot. Om kontot inte påverkas av den nedfallna zonen fortsätter aktiviteterna att göra framsteg. Annars misslyckas uppgifterna.

Förberedelse och återställning av zonstopp

Tjänsten Storage Action är inte zonindelad, men lagringskontot är det. Om lagringskontot påverkas av ett zonfel misslyckas lagringsuppgifter som har tilldelats kontot. När zon- och lagringskontot har blivit tillgängligt fortsätter schemalagda aktiviteter att köras enligt schemat. Om aktiviteten är konfigurerad att köras en gång kan du behöva schemalägga aktiviteten så att den körs igen.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

Lagringsåtgärden är en regional tjänst och körs mot konton i samma region. När en region är nere är både lagringskontot och tjänsten också nere. Tjänsten stöder inte haveriberedskap mellan regioner. Om du utlöser en redundansväxling av lagringskontot till en annan region kan lagringsuppgifter inte köras mot lagringskontot förrän det återgår till den ursprungliga regionen. Så även om du kanske kan återställa lagringskontot kan lagringsuppgiften inte köras mot det.

Identifiering, avisering och hantering av avbrott

Lagringsuppgifter skickar inga meddelanden när det uppstår ett avbrott i själva tjänsten. Det är viktigt att du kontrollerar status för lagringsaktiviteten och försöker utföra uppgifter igen när tjänsten/regionen har återställts.

Nästa steg

• Självstudie: Skapa en app med hög tillgänglighet för flera regioner i Azure App Service
• Tillförlitlighet i Azure