Haveriberedskap

Haveriberedskap (DR) för Azure Databricks replikerar arbetsytor, data och konfigurationer i molnregioner så att dina team fortsätter att arbeta när ett regionalt avbrott tar din primära distribution offline. En fullständig DR-plan omfattar inte bara Azure Databricks utan även datakällor, inmatningsverktyg, BI-verktyg och schemaläggare som den ansluter till.

Den här sidan beskriver de begrepp, strategier, verktyg och testprocedurer som du behöver för att utforma och köra en dr-lösning mellan regioner.

Är du nybörjare på DR-planering? Börja med terminologi för haveriberedskapsindustrin för definitioner av RPO och RTO.

Viktigt!

Använd hanterad katastrofåterställning. Azure Databricks rekommenderar hanterad katastrofåterställning för katastrofåterställning mellan regioner på AWS och Azure. Den replikerar Unity Catalog-metadata, hanterade tabelldata och arbetsytetillgångar enligt ett kontinuerligt schema, ger en stabil URL som överlever redundans och låter dig utlösa redundans från kontokonsolen. Inga replikeringsskript att skriva eller underhålla. Använd DIY-vägledningen på den här sidan endast för resurser som hanterad DR inte replikerar, eller om du behöver aktiv-aktiv-topologier, replikering mellan moln eller finjusterad kontroll över replikeringspipelinen.

Garantier för hög tillgänglighet inom regionen

Resten av den här sidan omfattar dr-program för flera regioner, men Azure Databricks ger också hög tillgänglighet (HA) i en enda region. Förstå dessa garantier först. De avgör om du behöver en separat DR-strategi.

HA och DR löser olika problem:

HA använder redundans för tillgänglighetszoner (AZ) i en region. Om en zon misslyckas fortsätter tjänsterna att köras i de andra.
DR använder replikering mellan regioner. Du kör sekundära Azure Databricks-arbetsytor i en annan region och replikerar data och konfigurationer till dem, och växlar sedan över vid ett regionalt avbrott.

Om du inte behöver dr för flera regioner kan Azure Databricks ha vara tillräckligt. Ha undviker komplexitet mellan regioner men skyddar inte mot ett avbrott i hela regionen. Om du förlitar dig enbart på HA för DR, verifiera din molnregions separation och redundans.

Ha-garantierna inom regionen täcker kontrollplanet och beräkningsplanet.

Tillgänglighet för Azure Databricks kontrollplanet

Det Azure Databricks kontrollplanet är motståndskraftigt mot zonfel och återställs automatiskt inom cirka 15 minuter efter ett zonfel. Regelbundna zonfelstester bekräftar detta.

Alla tillståndslösa kontrollplanstjänster kan förlora enskilda virtuella datorer, eller alla virtuella datorer i en hel zon, utan att ta bort tjänsten. Arbetsytedata lagras i databaser som replikeras mellan zoner i regionen. Lagringskonton som hanterar Databricks Runtime-avbildningar är också redundanta i regionen och alla regioner har sekundära lagringskonton som tar över när den primära är nere.

Note

Ovanstående kontrollplansgarantier gäller för Azure Databricks hanterad infrastruktur. Du ansvarar för redundans för beräkningsplanets zon, till exempel genom att välja zonredundant lagring för arbetsytans rot bucket och använda instanspooler som omfattar tillgänglighetszoner.

Vissa Azure-regioner använder ett styrplan som är distribuerat i en parregion. Se vidare Azure Databricks-regioner.

Resiliens mot zonfel innebär stöd för att högst en zon är nere och är endast tillgängligt i Azure-regioner som har stöd för flera zoner.

Tillgänglighet för beräkningsplanet

Tillgängligheten för arbetsytan beror på tillgängligheten för kontrollplanet.

DBFS-rotdata påverkas inte om lagringskontot har konfigurerats med zonredundant lagring (ZRS) eller geo-zonredundant lagring (GZRS). Standardvärdet är Geo-redundant lagring (GRS).

Klusternoder hämtas ur olika tillgänglighetszoner genom att begära noder från Azures beräkningsleverantör, förutsatt att det finns tillräckligt med kapacitet i de återstående zonerna. Om en nod går förlorad begär klusterhanteraren ersättningsnoder från Azure-beräkningsprovidern, vilket hämtar dem från de tillgängliga AZ:erna. Undantaget är när drivrutinsnoden går förlorad. I så fall startar klusterhanteraren om jobbet och klustret.

Information om hur du bekräftar multi-AZ-stöd finns i listan över Azure regioner. Använd zonredundant lagring för resiliens i flera AZ i beräkningsenheten.

Terminologi

Använd dessa definitioner konsekvent när du diskuterar DR med ditt team.

Terminologi för regioner

Regionterminologi

Den här sidan använder följande regiondefinitioner:

Primär region: Den region där användarna kör dagliga interaktiva och automatiserade arbetsbelastningar för dataanalys.
Sekundär region: Den region där IT-teamen tillfälligt flyttar arbetsbelastningar under ett avbrott i den primära regionen.
Geo-redundant lagring: Asynkron replikering mellan regioner av sparad lagring. Se dokumentationen för ditt moln:

Geo-redundant lagring mellan regioner (Azure).

Viktigt!

Förlita dig inte på geo-redundant lagring för att duplicera Azure Databricks rotlagring mellan regioner (till exempel den ADLS-lagring som Azure Databricks skapar för varje arbetsyta, eller Azure Blob Storage för arbetsytor som skapades före den 6 mars 2023). Om du vill replikera hanterade tabelldata använder du Delta Deep Clone och konverterar först till Delta där det är möjligt för icke-Delta-data.

Terminologi för distributionsstatus

Den här sidan använder följande definitioner för distributionsstatus:

Aktiv distribution (kallas ibland frekvent distribution): Användare ansluter till den och kör arbetsbelastningar. Jobb och dataströmmar körs här enligt schemat.
Passiv distribution (kallas ibland kall distribution): Inga processer körs här. IT-teamen håller det redo genom att automatisera distributionen av kod, konfiguration och andra Azure Databricks objekt till den. En passiv distribution blir endast aktiv när den aktiva distributionen slutar fungera.

Viktigt!

Ett projekt kan innehålla flera passiva distributioner i olika regioner för ytterligare motståndskraft.

De flesta team kör en aktiv distribution i taget, den aktiva-passiva strategin. Den mindre vanliga active-active-strategin kör två samtidiga aktiva driftsättningar.

Terminologi för haveriberedskapsindustrin

Definiera dessa två branschvillkor med ditt team:

Mål för återställningspunkt (RPO): Den maximala dataförlustperiod som tjänsten kan tolerera under en större incident. Se RPO.

Azure Databricks lagrar inte dina primära kunddata. Det finns i ADLS (för arbetsytor som skapats före 6 mars 2023, Azure Blob Storage) eller andra system som du styr. Det Azure Databricks kontrollplanet lagrar vissa objekt (till exempel jobb och anteckningsböcker), så Azure Databricks RPO är den maximala period då ändringar av dessa objekt kan gå förlorade. Du ansvarar för att definiera RPO för dina kunddata i ADLS (för arbetsytor som skapats före den 6 mars 2023 Azure Blob Storage) och andra datakällor som du styr.
Mål för återställningstid (RTO): Den maximala tid inom vilken en affärsprocess måste återställas efter ett haveri. Se RTO.

Haveriberedskap och skadade data

Katastrofåterställning och datakorruption

En DR-lösning minimerar inte skadade data. Skadade data i den primära regionen replikeras till den sekundära regionen och är skadade i båda regionerna. Du kan åtgärda den här typen av fel genom att använda Delta-tidsresor, liknande verktyg eller verktyg för säkerhetskopiering av data.

Typiskt återställningsarbetsflöde

Ett Azure Databricks DR-scenario utspelar sig vanligtvis på följande sätt:

Ett fel drabbar en kritisk tjänst i din primära region: en datakälla, ett nätverk eller ett annat beroende som Azure Databricks distributionen förlitar sig på.
Du undersöker med din molnleverantör.
Om väntan är oacceptabel väljer du att växla över till din sekundära region.
Bekräfta att samma problem inte påverkar den sekundära regionen.
Växla över (för detaljerade steg, se Testa redundans):
1. Stoppa all aktivitet på arbetsytan. Användare stoppar arbetsbelastningar och säkerhetskopierar de senaste ändringarna där det är möjligt. Jobben stängs av (om de inte redan har misslyckats på grund av avbrottet).
2. Kör återställningsproceduren för sekundär region för att uppdatera routnings- och omdirigeringsanslutningar och nätverkstrafik.
3. Peka om efterföljande system (BI-verktyg, schemaläggare, tredjepartsintegreringar) till den sekundära arbetsytan och återuppta anslutningarna.
4. Efter testningen deklarerar du att den sekundära regionen är i drift. Användare loggar in på den nu aktiva distributionen och du återställer schemalagda eller fördröjda jobb.
När problemet med den primära regionen har åtgärdats bekräftar du korrigeringen.
Återställning efter fel (mer information finns i Teståterställning (återställning efter fel)):
1. Stoppa allt arbete i den sekundära regionen.
2. Kör återställningsproceduren för primär region för att omdirigera routning tillbaka.
3. Replikera nya data tillbaka till den primära regionen. Minimera vad som behöver replikeras. Till exempel kanske skrivskyddade jobb som kördes i den sekundära distributionen inte kräver återskrivning.
4. Testa distributionen i den primära regionen.
5. Ange att den primära regionen är aktiv och återuppta produktionsarbetslaster.

Viktigt!

Vissa dataförluster kan inträffa under de här stegen. Definiera hur mycket förlust som är acceptabelt för din organisation och hur du minimerar det.

Steg 1: Förstå dina affärsbehov

Identifiera vilka datatjänster som är kritiska och definiera deras målvärden för RPO och RTO. Undersök varje systems faktiska tolerans i verkliga förhållanden.

DR, redundans och återställning efter fel medför verkliga kostnader och risker, inklusive skadade data, dataduplicering (skrivning till fel lagringsplats) och användare som gör ändringar i fel region.

Mappa varje Azure Databricks integrationsplats som påverkar ditt företag och välj de verktyg och kommunikationskanaler som din plan använder.

Integreringspunkter att mappa

Behöver din DR-lösning hantera interaktiva processer, automatiserade processer eller både och?
Vilka datatjänster använder du? Vissa kan vara installerade lokalt.
Hur kommer indata till molnet?
Vem använder dessa data? Vilka processer använder det nedströms?
Finns det tredjepartsintegrationer som behöver ta hänsyn till DR-ändringar?

Verktyg och kommunikation för planering

Kan du fördefinierade konfigurationen och göra den modulär för att hantera DR-lösningar på ett naturligt och underhållsbart sätt?
Vilka kommunikationsverktyg och kanaler används för att informera interna team och tredjeparter (integrationer, nedströmskonsumenter) om ändringar i DR-failover och failback? Hur bekräftar du deras bekräftelse?
Vilka tjänster, om några, stänger du av tills fullständig återställning är på plats?

Steg 2: Välj en process som uppfyller dina affärsbehov

Använd hanterad katastrofåterställning som standard. Den hanterar replikering av arbetsytor, Unity Catalog-metadata, hanterade tabelldata och redundansorkestrering utan anpassade skript. Använd endast DIY-vägledningen nedan om ditt scenario faller utanför dess omfattning, till exempel om hanterad DR inte replikerar vissa resurser, vid aktiv-aktiv-topologier, replikering mellan moln eller om du behöver finkornig kontroll över replikeringsflödet.

En DIY-lösning måste replikera rätt data över kontrollplanet, beräkningsplanet och datakällorna. Redundanta arbetsytor mappar till olika kontrollplan i olika regioner, så du håller dem synkroniserade med en skriptbaserad lösning, antingen ett synkroniseringsverktyg eller ett CI/CD-arbetsflöde. För själva data använder de flesta team Azure Databricks jobb (ofta schemalagda) eller Delta Deep Clone för att kopiera tabeller mellan regioner. Du behöver inte synkronisera data inifrån beräkningsplanet (till exempel från Databricks Runtime-arbetare).

Om du använder funktionen VNet-inmatning (inte tillgänglig med alla prenumerations- och distributionstyper) distribuerar du nätverk konsekvent i båda regionerna med hjälp av mallbaserade verktyg som Terraform.

Replikera dina datakällor mellan regioner efter behov.

DR-lösningar omfattar vanligtvis två (eller flera) arbetsytor. Välj mellan följande strategier baserat på den avbrottslängd som du måste tolerera, driftsinsats och kostnaden för att växla tillbaka till den primära regionen.

Allmänna metodtips

Allmänna metodtips för en lyckad DR-plan är:

Förstå vilka processer som är viktiga för verksamheten och måste köras i DR.
Identifiera tydligt vilka tjänster som ingår, vilka data som bearbetas, vad dataflödet är och var de lagras.
Isolera tjänsterna och data så mycket som möjligt. Du kan till exempel skapa en särskild molnlagringscontainer för DR-data eller flytta Azure Databricks objekt som behövs vid en katastrof till en separat arbetsyta.
Du ansvarar för att upprätthålla integriteten mellan primära och sekundära distributioner för objekt som inte lagras i Azure Databricks kontrollplanet.
För datakällor använder du interna Azure verktyg för att replikera data till dina DR-regioner där det är möjligt.

Varning

Lagra inte data i rot-ADLS (för arbetsytor som skapats före den 6 mars 2023 Azure Blob Storage) som används för DBFS-rotåtkomst. DBFS-rotlagring stöds inte för produktionskunddata. Azure Databricks rekommenderar också att du inte lagrar bibliotek, konfigurationsfiler eller init-skript där.

Strategi för aktiv-passiv lösning

Det här avsnittet fokuserar på den aktiva-passiva strategin eftersom den är den vanligaste, enklaste och mest kostnadseffektiva. En aktiv-passiv lösning synkroniserar data och objektändringar från din aktiva distribution till en passiv distribution i en sekundär region. Vid en DR-händelse aktiveras den passiva driftsättningen.

Två vanliga varianter:

Enhetlig (hela företaget): En uppsättning aktiva och passiva distributioner stöder hela organisationen.
Efter avdelning eller projekt: Varje domän har en egen DR-lösning med primära och sekundära regioner som är skräddarsydda för dess behov.

Du kan också använda en passiv distribution för skrivskyddade arbetsbelastningar, till exempel användarfrågor, som inte ändrar data eller Azure Databricks objekt.

Strategi för aktiv-aktiv lösning

I en aktiv-aktiv lösning körs alla dataprocesser i båda regionerna parallellt hela tiden. Driftteamet måste markera varje jobb som slutförts först när det har lyckats i båda regionerna. Objekt kan inte ändras i produktionsmiljön och måste följa en strikt CI/CD-process från utvecklings-/stagingmiljö till produktion.

Aktiv-aktiv är den mest komplexa strategin och kostar mer eftersom jobb körs i båda regionerna, men det erbjuder den lägsta RTO och RPO.

Du kan implementera aktiv-aktiv i hela företaget eller per avdelning. Du behöver ingen duplicerad arbetsyta för varje arbetsbelastning. Till exempel är utvecklings- eller mellanlagringsarbetsytor ofta enklare att rekonstruera från en utvecklingspipeline än att hålla synkroniseringen.

Välj verktyg

Det finns två huvudsakliga metoder för att hålla data synkroniserade mellan arbetsytor i dina primära och sekundära regioner:

Synkroniseringsklient som kopierar från primär till sekundär: En synkroniseringsklient skickar produktionsdata och tillgångar från den primära regionen till den sekundära regionen. Detta körs vanligtvis enligt schema och schemafrekvensen beror på mål-RTO och RPO.
CI/CD-verktyg för parallell distribution: För produktionskod och tillgångar använder du CI/CD-verktyg som push-överför ändringar till produktionssystem samtidigt till båda regionerna. Till exempel, när du överför kod och resurser från staging/utveckling till produktion, gör ett CI/CD-system det tillgängligt i båda regionerna samtidigt. Huvudidén är att behandla alla artefakter på en Azure Databricks-arbetsyta som infrastruktur som kod. De flesta artefakter kan samdistribueras till både primära och sekundära arbetsytor, medan vissa artefakter kan behöva distribueras först efter en DR-händelse. Verktyg finns i Automation-skript, exempel och prototyper.

Beroende på dina behov kan du kombinera metoderna. Använd till exempel CI/CD för notebook-källkod, men använd synkronisering för konfiguration som pooler och åtkomstkontroller.

I följande tabell beskrivs hur du hanterar varje typ av data med varje verktygsalternativ.

beskrivning	Hur man hanterar CI/CD-verktyg	Så här hanterar du med synkroniseringsverktyget
Källkod: export av källkod från notebookar och för paketerade programvarubibliotek	Distribuera både till primär och sekundär.	Synkronisera källkod från primär till sekundär.
Användare och grupper	Hantera metadata som konfiguration i Git. Du kan också använda samma identitetsprovider (IdP) för båda arbetsytorna. Samtidigt distribuera användar- och gruppdata till primära och sekundära etableringar.	Använd SCIM eller annan automatisering för båda regionerna. Manuellt skapande rekommenderas inte , men om det används måste det göras för båda samtidigt. Om du använder en manuell installation skapar du en schemalagd automatiserad process för att jämföra listan över användare och grupper mellan de två distributionerna.
Poolkonfigurationer	Kan vara mallar i Git. Samdistribuering till primär och sekundär. I sekundärt måste dock `min_idle_instances` vara noll tills DR-händelsen.	Pooler som skapas med valfria `min_idle_instances` när de synkroniseras till en sekundär arbetsyta med hjälp av API:et eller CLI.
Jobbkonfigurationer	Använd Databricks-tillgångspaket med mål per miljö (till exempel `prod` och `dr`) för att distribuera samma jobbdefinition till båda regionerna. För den sekundära distributionen anger du samtidighet till noll så att jobbet mellanlagras men inte körs. Ändra samtidighetsvärdet när den sekundära distributionen blir aktiv.	Om jobben av någon anledning körs på befintliga `<interactive>` kluster måste synkroniseringsklienten koppla till motsvarande `cluster_id` i den sekundära arbetsytan.
Åtkomstkontrollistorna (ACL)	Kan vara mallar i Git. Distribuera till huvud- och sekundärdistributioner av notebooks, mappar och kluster. Behåll dock jobbdata fram till DR-händelsen.	Permissions API kan ange åtkomstkontroller för kluster, jobb, pooler, anteckningsböcker och mappar. En synkroniseringsklient måste mappa till motsvarande objekt-ID:er för varje objekt på den sekundära arbetsytan. Databricks rekommenderar att du skapar en karta över objekt-ID:t från den primära till den sekundära arbetsytan medan du synkroniserar objekten innan du replikerar åtkomstkontrollerna.
Bibliotek	Inkludera i källkods- och kluster-/jobbmallar.	Synkronisera anpassade bibliotek från centraliserade lagringsplatser, DBFS eller molnlagring (kan monteras).
Init-skript för kluster	Inkludera i källkoden om du vill.	För enklare synkronisering lagrar du init-skript på den primära arbetsytan i en gemensam mapp eller i en liten uppsättning mappar om möjligt.
Monteringspunkter	Inkludera i källkoden om den bara skapas via notebook-baserade jobb eller kommando-API.	Använd jobb som kan köras som Azure Data Factory-aktiviteter (ADF). Observera att lagringsslutpunkterna kan ändras med tanke på att arbetsytor finns i olika regioner. Detta beror mycket på din datadR-strategi också.
Metadata för tabell	För Unity Catalog-objekt (kataloger, scheman, tabeller, volymer och bidrag) distribuerar du tillsammans med Databricks Terraform-providern eller Databricks-tillgångspaketen. För äldre Hive-metaarkivtabeller inkluderar du create-table-instruktioner med källkod om de skapas via notebook-baserade jobb eller kommando-API:et.	För Unity Catalog-objekt läser du källmetadata från systemtabeller eller `information_schema` replikerar till den sekundära arbetsytan med hjälp av Databricks SDK. För äldre Hive-metaarkivtabeller jämför du metadatadefinitioner mellan metaarkiv med hjälp av Spark Catalog-API :et eller `SHOW CREATE TABLE` via en notebook-fil eller skript. Underliggande lagringssökvägar kan vara regionbaserade och kan skilja sig mellan metaarkivinstanser.
Hemligheter	Inkludera i källkoden om den bara skapas via Kommando-API. Observera att visst hemlighetsinnehåll kan behöva ändras mellan det primära och det sekundära.	Hemligheter skapas på båda arbetsytorna via API:et. Observera att visst hemlighetsinnehåll kan behöva ändras mellan det primära och det sekundära.
Klusterkonfigurationer	Kan vara mallar i Git. Samdistribution till primära och sekundära distributioner, även om de i den sekundära distributionen bör avslutas tills DR-händelsen.	Kluster skapas när de har synkroniserats till den sekundära arbetsytan med hjälp av API:et eller CLI. De kan uttryckligen avslutas om du vill, beroende på inställningar för automatisk avslutning.
Behörigheter för anteckningsbok-, jobb- och mapp	Kan vara mallar i Git. Samdistribuera till primära och sekundära utplaceringar.	Replikera med hjälp av API:et Behörigheter.

Välj regioner och flera sekundära arbetsytor

Du styr när DR utlöses och vilken sekundär region du redundansväxlar till. Du ansvarar också för att stabilisera DR-miljön innan du återupptar normal drift. Det innebär vanligtvis att skapa flera Azure Databricks arbetsytor för produktion och dr och sedan välja en sekundär redundansregion.

Innan du väljer den sekundära regionen kontrollerar du att alla resurser och tjänster som du är beroende av (beräkningstyper, produkter, integreringar) är tillgängliga där. Vissa Azure Databricks tjänster är bara tillgängliga i specifika regioner.

Kontrollera även tillgängligheten för datareplikering och VM-typ.

Steg 3: Förbereda arbetsytor och göra en engångskopia

Skapa först en sekundär Azure Databricks-arbetsyta (eller flera arbetsytor) och dess tillhörande metastore i den sekundära region som du har valt. Den sekundära arbetsytan måste spegla den primäras konto-, region- och identitetskonfiguration innan du kan replikera data eller tillgångar till den.

Om du använder hanterad haveriberedskap hanterar Azure Databricks den första bootstrapen för kataloger och arbetsytetillgångar inom omfånget när du skapar en redundansgrupp. Du behöver inte köra en engångskopia för dessa resurser. Fortsätt med återstoden av det här avsnittet för eventuella datakällor eller tillgångar som inte replikeras av hanterad DR.

För en produktionsarbetsyta som inte omfattas av hanterad DR kör du en engångskopiering för att synkronisera den passiva driftsättningen med den aktiva driftsättningen. Den här kopian hanterar:

Datareplikering: Använd en molnreplikeringslösning eller Delta Deep Clone.
Tokengenerering: Automatisera replikering och framtida arbetsbelastningar med genererade token.
Replikering av arbetsyta: Replikera med hjälp av metoderna i steg 4: Förbered dina datakällor. Omfattande vägledning om hur du exporterar arbetsytekonfiguration, data och AI/ML-tillgångar finns i Exportera arbetsytedata.
Validering av arbetsyta: Testa arbetsytan och processen för att bekräfta att de körs korrekt och generera förväntade resultat.

Efterföljande synkroniseringar körs snabbare än den första kopian, och verktygsloggarna registrerar vad som har ändrats och när.

Steg 4: Förbereda dina datakällor

Azure Databricks kan bearbeta en mängd olika datakällor med hjälp av batchbearbetning eller dataströmmar.

Batchbearbetning från datakällor

Batchdata finns vanligtvis i en källa som du kan replikera eller leverera till en annan region.

Data laddas till exempel ofta upp till molnlagring enligt ett schema. I DR-läge dirigerar du dessa uppladdningar till lagring i sekundärregionen och uppdaterar arbetsbelastningarna så att de läser från och skriver till den lagringen.

Dataströmmar

Att bearbeta en dataström är en större utmaning. Strömmande data kan matas in från olika källor, bearbetas och skickas till en strömningslösning:

Meddelandekö, till exempel Kafka
Datainsamlingsström för databasändring
Filbaserad kontinuerlig bearbetning
Filbaserad schemalagd bearbetning, även kallad att aktivera en gång

I alla dessa fall måste du konfigurera dina datakällor för att hantera DR-läge och använda den sekundära distributionen i den sekundära regionen.

En strömskrivare lagrar en kontrollpunkt med information om de data som har bearbetats. Den här kontrollpunkten kan innehålla en dataplats (vanligtvis molnlagring) som måste ändras till en ny plats för att säkerställa en lyckad omstart av strömmen. Undermappen source under kontrollpunkten kan till exempel lagra den filbaserade molnmappen.

Den här kontrollpunkten måste replikeras i tid. Överväg att synkronisera kontrollpunktsintervallet med valfri ny molnreplikeringslösning.

Kontrollpunktsuppdateringen är en funktion av skrivaren och gäller därför för dataströminmatning eller bearbetning och lagring på en annan strömningskälla.

För strömningsarbetsbelastningar kontrollerar du att kontrollpunkter konfigureras i kundhanterad lagring så att de kan replikeras till den sekundära regionen för arbetsbelastningens återupptagande från tidpunkten för det senaste felet. Du kan också välja att köra den sekundära strömningsprocessen parallellt med den primära processen.

Steg 5: Implementera och testa din lösning

Om du använder hanterad katastrofåterställning, kan du utlösa en planerad växling till reservsystem i kontokonsolen för att verifiera att din konfiguration fungerar hela vägen. Samma procedur omfattar både DR-tester och verkliga avbrott. Se Redundansväxling och återställning efter fel.

Testa din DR-konfiguration regelbundet. En oprövad DR-plan misslyckas ofta när du behöver den. Vissa team byter aktiva regioner med några månaders mellanrum enligt ett schema för att validera antaganden, träningsprocesser och hålla teamet bekant med runbooken.

Viktigt!

Testa din DR-lösning under verkliga förhållanden enligt ett regelbundet schema.

Om ett test visar ett objekt eller en mall som saknas uppdaterar du planen: ta bort beroendet, replikera det till den sekundära arbetsytan eller gör det tillgängligt på ett annat sätt.

Testa även organisations- och konfigurationsändringarna. Din DR-plan påverkar din distributionspipeline, så teamet måste veta vad som ska synkroniseras. När du har konfigurerat DR-arbetsytor kontrollerar du att infrastruktur, jobb, notebook-filer, bibliotek och andra arbetsyteobjekt är tillgängliga i den sekundära regionen.

Expandera dina standardarbetsprocesser och konfigurationspipelines för att distribuera ändringar till alla arbetsytor. Hantera användaridentiteter mellan arbetsytor och konfigurera jobbautomatisering och övervakning för de nya arbetsytorna.

Planera och testa ändringar i konfigurationsverktyget.

Konfigurationsändringar för att planera och testa

Förbered en plan för redundans och testa alla antaganden för vart och ett av följande:

Inmatning: Förstå var dina datakällor finns och var dessa källor hämtar sina data. Om möjligt parametriserar du källan och använder en separat konfigurationsmall för den sekundära distributionen och regionen.
Körningsändringar: Om du har en schemaläggare för att utlösa jobb eller andra åtgärder kan du behöva en separat schemaläggare som fungerar med den sekundära distributionen eller dess datakällor.
Interaktiv anslutning: Överväg hur konfigurations-, autentiserings- och nätverksanslutningar kan påverkas av regionala störningar för all användning av REST-API:er, CLI-verktyg eller andra tjänster som JDBC/ODBC.
Automatiseringsändringar: För alla automatiseringsverktyg.
Utdata: För alla verktyg som genererar utdata eller loggar.
Efterföljande ändringar: För BI-verktyg, instrumentpaneler, schemaläggare och tredjepartsintegreringar som läser från eller skriver till Azure Databricks, planera hur de ska omdirigeras till den sekundära arbetsytan och meddela deras ägare.

Testa redundansväxling

Testa felövergång

Många scenarier kan utlösa haveriåterställning: ett oväntat avbrott i molnnätverket, molnlagringen eller en annan kärntjänst där du inte kan stänga ned kontrollerat; en planerad avstängning eller ett avbrott; eller till och med regelbunden växling mellan regioner som en del av testcykeln.

Om du vill testa redundans ansluter du till systemet och kör en avstängning. Bekräfta att alla jobb har slutförts och att kluster avslutas.

En synkroniseringsklient (eller CI/CD-verktyg) replikerar relevanta Azure Databricks objekt och resurser till den sekundära arbetsytan. Om du vill aktivera den sekundära arbetsytan kan processen innehålla några eller alla av följande:

Kör tester för att bekräfta att plattformen är uppdaterad.
Inaktivera pooler och kluster i den primära regionen så att den primära regionen inte börjar bearbeta nya data om den misslyckade tjänsten returnerar online.
Kör återställningsprocessen för dina datakällor (se nedan).
Starta relevanta pooler (eller öka min_idle_instances till ett relevant tal).
Starta relevanta kluster (om de inte har avslutats).
Ändra den parallella körningen för jobb och utför de relevanta jobben. Det kan vara engångskörningar eller periodiska körningar.
För alla externa verktyg som använder en URL eller ett domännamn för din Azure Databricks-arbetsyta uppdaterar du konfigurationerna för att ta hänsyn till det nya kontrollplanet. Du kan till exempel uppdatera URL:er för REST-API:er och JDBC/ODBC-anslutningar. Azure Databricks-webbprogrammets kundriktade URL ändras när kontrollplanet ändras, så meddela organisationens användare om den nya URL:en.

Information om återställningsprocessen

Kontrollera datumet för de senaste synkroniserade data. Se Terminologi för haveriberedskapsindustrin. Informationen om det här steget varierar beroende på hur du synkroniserar data och dina unika affärsbehov.
Stabilisera dina datakällor och se till att alla är tillgängliga. Inkludera alla externa datakällor, till exempel Azure Cloud SQL, delta lake, parquet eller andra filer.
Hitta din återställningspunkt för direktuppspelning. Konfigurera processen för att starta om därifrån och ha en process redo att identifiera och eliminera potentiella dubbletter (Delta Lake gör det enklare).
Slutför dataflödesprocessen och informera användarna.

Teståterställning (återgång efter fel)

Teståterställning (failback)

Återställning efter fel är enklare att kontrollera och kan utföras i ett underhållsfönster. Planera för några eller alla av följande steg:

Få en bekräftelse på att den primära regionen har återställts.
Inaktivera pooler och kluster i den sekundära regionen så att de inte börjar bearbeta nya data.
Synkronisera alla nya eller ändrade tillgångar på den sekundära arbetsytan tillbaka till den primära distributionen. Beroende på utformningen av redundansskripten kanske du kan köra samma skript för att synkronisera objekt från den sekundära regionen (DR) till den primära regionen (produktion).
Synkronisera eventuella nya datauppdateringar tillbaka till den primära distributionen. Du kan använda granskningsspår av loggar och Delta-tabeller för att garantera att ingen data går förlorad.
Stäng av alla arbetsbelastningar i DR-regionen.
Ändra URL:erna för jobb och användare så att de pekar på den primära regionen, och peka om nedströmsanslutningar (BI-verktyg, schemaläggare, tredjepartsintegreringar) till den primära regionen.
Kör tester för att bekräfta att plattformen är uppdaterad.
Starta relevanta pooler (eller öka min_idle_instances till ett relevant tal).
Starta relevanta kluster (om de inte har avslutats).
Ändra den samtidiga körningen för jobb och kör relevanta jobb. Det kan vara engångskörningar eller periodiska körningar.
Vid behov ställer du in den sekundära regionen igen för framtida DR.

Automation-skript, exempel och prototyper

För AWS och Azure hanterar hanterad katastrofåterställning replikering av arbetsytor och hanterade tabeller utan anpassad automatisering. Referenserna nedan gäller endast om du bygger en gör-det-själv-lösning utanför den hanterade DR-lösningens omfattning.

För DIY DR-pipelines använder du Databricks Terraform-providern för att hantera arbetsytetillgångar som kod och samdistribution till primära och sekundära regioner.

Om du samordnar Azure Databricks från Azure Data Factory replikerar du relevanta ADF-pipelines så att de refererar till en länkad tjänst som mappats till den sekundära arbetsytan.

Ytterligare resurser

Feedback

Var den här sidan till hjälp?

Last updated on 2026-06-24