Redigera

Dela via

BCDR för Azure Data Factory- och Azure Synapse Analytics-pipelines

Azure Data Factory
Azure Repos
Azure Synapse Analytics
GitHub

Katastrofer kan vara maskinvarufel, naturkatastrofer eller programvarufel. Processen för att förbereda för och återställa från en katastrof kallas haveriberedskap (DR). I den här artikeln beskrivs rekommenderade metoder för att uppnå affärskontinuitet och haveriberedskap (BCDR) för Azure Data Factory- och Azure Synapse Analytics-pipelines.

BCDR-strategier omfattar redundans i tillgänglighetszoner, automatisk återställning som tillhandahålls av Azure-haveriberedskap och användarhanterad återställning med kontinuerlig integrering och kontinuerlig leverans (CI/CD).

Arkitektur

Diagram som visar tillgänglighetszoner och regioner för Azure Synapse Analytics- och Data Factory-pipelines BCDR.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

  1. Data Factory- och Azure Synapse-pipelines ger återhämtning med hjälp av Azure-regioner och Azure-tillgänglighetszoner.

    • Varje Azure-region har en uppsättning datacenter som distribueras inom en svarstidsdefinierad perimeter.
    • Azure-tillgänglighetszoner är fysiskt separata platser i varje Azure-region som är toleranta mot lokala fel.
    • Alla Azure-regioner och tillgänglighetszoner är anslutna via ett dedikerat, regionalt nätverk med låg latens och ett nätverk med höga prestanda.
    • Alla tillgänglighetszonaktiverade regioner har minst tre separata tillgänglighetszoner för att säkerställa återhämtning.

  2. När ett datacenter, en del av ett datacenter eller en tillgänglighetszon i en region går ner sker redundans med noll driftstopp för zontåliga Data Factory- och Azure Synapse-pipelines.

Komponenter

Information om scenario

Data Factory- och Azure Synapse-pipelines lagrar artefakter som innehåller följande data:

Metadata

  • Pipeline
  • Datauppsättningar
  • Länkade tjänster
  • Integration runtime
  • Utlösare

Övervaka data

  • Pipeline
  • Utlösare
  • Aktivitetskörningar

Katastrofer kan inträffa på olika sätt, till exempel maskinvarufel, naturkatastrofer eller programvarufel som orsakas av mänskliga fel eller cyberattacker. Beroende på typen av fel kan deras geografiska inverkan vara regional eller global. När du planerar en strategi för haveriberedskap bör du överväga både katastrofens natur och dess geografiska inverkan.

BCDR i Azure fungerar på en modell med delat ansvar. Många Azure-tjänster kräver att kunderna uttryckligen konfigurerar sin DR-strategi, medan Azure tillhandahåller baslinjeinfrastrukturen och plattformstjänsterna efter behov.

Du kan använda följande rekommenderade metoder för att uppnå BCDR för Data Factory- och Azure Synapse-pipelines under olika felscenarier. För implementering, se Distribuera det här scenariot.

Automatiserad återställning med Azure-haveriberedskap

Med automatiserad återställning tillhandahållen Azure Backup och haveriberedskap redundansväxlar Data Factory- eller Azure Synapse-pipelines automatiskt över till den kopplade regionen när du konfigurerar automatisk återställning när du konfigurerar automatisk återställning. Undantagen är regionerna Sydostasien och Brasilien, där kraven på datahemvist kräver att data finns kvar i dessa regioner.

Vid dr-redundans återställer Data Factory produktionspipelines. Om du behöver verifiera dina återställda pipelines kan du säkerhetskopiera Azure Resource Manager-mallarna för dina produktionspipelines i hemlig lagring och jämföra de återställda pipelinerna med säkerhetskopiorna.

Azure Global-teamet genomför regelbundna BCDR-övningar och Azure Data Factory och Azure Synapse Analytics deltar i dessa övningar. BCDR-detaljtestet simulerar ett regionfel och redundansväxlar Azure-tjänster till en länkad region utan någon kunds inblandning. Mer information om BCDR-detaljnivån finns i Testning av tjänster.

Användarhanterad redundans med CI/CD

För att uppnå BCDR i händelse av ett fel i hela regionen behöver du en datafabrik eller en Azure Synapse-arbetsyta i den sekundära regionen. Om datafabriken eller Azure Synapse-pipelinen tas bort av misstag, avbrott eller interna underhållshändelser kan du använda Git och CI/CD för att återställa pipelines manuellt.

Du kan också använda en aktiv/passiv implementering. Den primära regionen hanterar normala åtgärder och förblir aktiv, medan den sekundära DR-regionen kräver förplanerade steg, beroende på specifik implementering, som ska höjas till primär. I det här fallet är alla nödvändiga konfigurationer för infrastruktur tillgängliga i den sekundära regionen, men de är inte etablerade.

Potentiella användningsfall

Användarhanterad redundans är användbar i scenarier som:

  • Oavsiktlig borttagning av pipelineartefakter via mänskliga fel.
  • Utökade avbrott eller underhållshändelser som inte utlöser BCDR eftersom ingen katastrof har rapporterats.

Du kan snabbt flytta dina produktionsarbetsbelastningar till andra regioner och inte påverkas.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Data Factory- och Azure Synapse-pipelines är vanliga Azure-tjänster som stöder tillgänglighetszoner, och de är utformade för att ge rätt återhämtningsnivå och flexibilitet tillsammans med ultralåg svarstid.

Med den användarhanterade återställningsmetoden kan du fortsätta att arbeta om det finns underhållshändelser, avbrott eller mänskliga fel i den primära regionen. Genom att använda CI/CD kan datafabriken och Azure Synapse-pipelines integreras till en Git-lagringsplats och distribueras till en sekundär region för omedelbar återställning.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Användarhanterad återställning integrerar Data Factory med Git med hjälp av CI/CD och använder eventuellt en sekundär DR-region som har alla nödvändiga infrastrukturkonfigurationer som en säkerhetskopia. Det här scenariot kan medföra extra kostnader. Om du vill beräkna kostnaderna använder du Priskalkylatorn för Azure.

Exempel på priser för Data Factory och Azure Synapse Analytics finns i:

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

Genom att använda den användarhanterade CI/CD-återställningsmetoden kan du integrera till Azure Repos eller GitHub. Mer information om bästa CI/CD-metoder finns i Metodtips för CI/CD.

Distribuera det här scenariot

Utför följande åtgärder för att konfigurera automatiserade eller användarhanterade DR för Data Factory- och Azure Synapse-pipelines.

Konfigurera automatisk återställning

I Data Factory kan du ange IR-regionen (Azure Integration Runtime) för aktivitetskörningen eller sändningen i konfigurationen av Integration Runtime. Om du vill aktivera automatisk redundans vid ett fullständigt regionalt avbrott ställer du in regionen på Lös automatiskt.

Skärmbild som visar hur du väljer Lös automatiskt för att aktivera automatisk redundans i installationen av Integration Runtime.

I samband med integreringskörningarna redundansväxlar IR automatiskt till den kopplade regionen när du väljer Lös automatiskt som IR-region. För andra specifika platsregioner kan du skapa en sekundär datafabrik i en annan region och använda CI/CD för att etablera din datafabrik från Git-lagringsplatsen.

Länkade tjänster är inte helt aktiverade efter redundansväxling på grund av väntande privata slutpunkter i det nyare nätverket i regionen. Du måste konfigurera privata slutpunkter i den återställda regionen. Du kan automatisera skapandet av privata slutpunkter med hjälp av API:et för godkännande.

Konfigurera användarhanterad återställning via CI/CD

Du kan använda Git och CI/CD för att återställa pipelines manuellt vid borttagning eller avbrott i Data Factory- eller Azure Synapse-pipelinen.

När du distribuerar användarhanterad redundans med hjälp av CI/CD vidtar du följande åtgärder:

Inaktivera utlösare

Inaktivera utlösare i den ursprungliga primära datafabriken när den är online igen. Du kan inaktivera utlösarna manuellt eller implementera automatisering för att regelbundet kontrollera tillgängligheten för den ursprungliga primära. Inaktivera alla utlösare på den ursprungliga primära datafabriken omedelbart efter att fabriken har återställts.

Information om hur du använder Azure PowerShell för att inaktivera eller aktivera Data Factory-utlösare finns i Exempel på för- och efterdistributionsskript och CI/CD-förbättringar relaterade till distribution av pipelineutlösare.

Hantera duplicerade skrivningar

De flesta ETL-pipelines (extract, transform, load) är utformade för att hantera duplicerade skrivningar, eftersom återfyllnad och omformning kräver dem. Datamottagare som stöder transparent redundans kan hantera duplicerade skrivningar med sammanslagning av poster eller genom att ta bort och infoga alla poster inom det specifika tidsintervallet.

För datamottagare som ändrar slutpunkter efter redundansväxling kan den primära och sekundära lagringen ha duplicerade eller partiella data. Du måste sammanfoga data manuellt.

Kontrollera vittnet och kontrollera pipelineflödet (valfritt)

I allmänhet måste du utforma dina pipelines så att de omfattar aktiviteter, till exempel misslyckade aktiviteter och uppslagsaktiviteter, för att starta om misslyckade pipelines från den intressanta platsen.

  1. Lägg till en global parameter i datafabriken för att ange regionen, till exempel region='EastUS' i den primära och region='CentralUS' i den sekundära datafabriken.

  2. Skapa ett vittne i en tredje region. Vittnet kan vara ett REST-anrop eller någon typ av lagring. Vittnet returnerar den aktuella primära regionen, till exempel 'EastUS', som standard.

  3. När en katastrof inträffar uppdaterar du vittnet manuellt för att returnera den nya primära regionen, till exempel 'CentralUS'.

  4. Lägg till en aktivitet i pipelinen för att leta upp vittnet och jämföra det aktuella primära värdet med den globala parametern.

    • Om parametrarna matchar körs den här pipelinen i den primära regionen. Fortsätt med det verkliga arbetet.
    • Om parametrarna inte matchar körs den här pipelinen i den sekundära regionen. Returnera bara resultatet.

Kommentar

Den här metoden introducerar ett beroende av vittnessökningen i din pipeline. Det går inte att läsa vittnet stoppar alla pipelinekörningar.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

  • Mario Zimmermann | Principal Software Engineering Manager – Azure Data Factory-teamet

  • Wee Hyong Tok | Huvudansvarig för PM – Azure Data Factory-teamet

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg