Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Azure Databricks är en Apache Spark-baserad data- och AI-plattform som är optimerad för Microsoft Azure. Det ger en enhetlig miljö för stordata- och AI-arbetsbelastningar och kombinerar det bästa av Databricks och Azure för att förenkla datateknik, datavetenskap och maskininlärning.
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 Azure Databricks upprätthåller återhämtning mot olika potentiella avbrott och problem och hur du kan konfigurera återhämtning för att uppfylla dina krav. Vägledningen omfattar tillfälliga fel, avbrott i tillgänglighetszonen, regionstopp och serviceunderhåll. Den här artikeln beskriver också hur du använder säkerhetskopior för att återställa från andra problem och visar viktig information om serviceavtalet för Azure Databricks (SLA).
Rekommendationer för produktionsdistribution
Information om hur du distribuerar Azure Databricks för att stödja lösningens tillförlitlighetskrav och hur tillförlitlighet påverkar andra aspekter av din arkitektur finns i Metodtips för arkitektur för Azure Databricks.
Översikt över tillförlitlighetsarkitektur
Du måste förstå tillförlitligheten för varje primär komponent i Azure Databricks:
Kontrollplanet är en samling tillståndslösa tjänster som hanterar arbetsytemetadata, användaråtkomst, schemaläggning av jobb och klusterhantering. Dessa tjänster backas upp av databaser som replikeras mellan tillgänglighetszoner i regioner som stöds.
Databricks-filsystemroten (DBFS) är ett lagringskonto som Azure Databricks automatiskt etablerar när du skapar en Azure Databricks-arbetsyta i ditt molnkonto. Vi rekommenderar att du inte lagrar data på DBFS-roten och inaktiverar det här lagringskontot om möjligt.
Unity Catalog-lagring innehåller ett eller flera lagringskonton som lagrar dina Unity Catalog-data i ditt molnkonto. Mer information finns i Översikt över Unity Catalog.
Beräkningsplanet kör arbetsbelastningar för databearbetning med hjälp av kluster av virtuella datorer (VM). Beräkningsplanet hanterar tillfälliga fel och ersätter automatiskt misslyckade noder utan användarintervention. Du kan välja mellan flera typer av beräkningsresurser. Mer information finns i Beräkning.
Tillgängligheten för arbetsytan beror på tillgängligheten för kontrollplanet, men beräkningskluster kan fortsätta att bearbeta jobb även under kontrollplansavbrott.
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 tillfälliga fel.
Du kan styra återförsök för aktiviteter i Lakeflow-jobb för att återställa från tillfälliga fel.
För program som körs på Azure Databricks implementerar du återförsökslogik med exponentiell backoff när du ansluter till externa tjänster eller Azure-tjänster, till exempel Storage, Azure SQL Database eller Azure Event Hubs. Databricks Runtime innehåller inbyggd motståndskraft för många Azure-tjänster, men programkoden ska hantera tjänstspecifika tillfälliga fel.
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.
Azure Databricks stöder zonredundans för varje komponent:
Kontrollplan: I regioner som stöder tillgänglighetszoner körs kontrollplanet i flera tillgänglighetszoner. Kontrollplanet hanterar zonfel automatiskt, med minimal påverkan och inga användaråtgärder krävs.
Kontrollplansarbetsytedata lagras i databaser. I regioner som stöder tillgänglighetszoner replikeras databaserna över flera zoner i regionen. Lagringskonton som hanterar Databricks Runtime-avbildningar är också redundanta i regionen. Alla regioner har sekundära lagringskonton som används när det primära lagringskontot är nere.
DBFS-rot: I regioner som stöder tillgänglighetszoner kan du konfigurera lagringskontot för DBFS-roten till att använda zonredundant lagring (ZRS). I parkopplade regioner som stöder tillgänglighetszoner kan du välja att använda geo-zonredundant lagring (GZRS).
Beräkningsplan: Databricks stöder automatisk zondistribution för beräkningsresurser, vilket innebär att dina resurser distribueras över flera tillgänglighetszoner. Den här distributionen hjälper dina produktionsarbetsbelastningar att uppnå motståndskraft mot zonavbrott.
När du använder serverlös beräkning väljer du inte uttryckligen zoner för din beräkning. Databricks hanterar zonval av virtuella datorer och ersättning av virtuella datorer som kan gå förlorade på grund av zonfel.
Kravspecifikation
Om du vill använda stöd för tillgänglighetszoner i Azure Databricks behöver du följande krav:
Regionstöd: Stöd för Azure Databricks-tillgänglighetszoner är tillgängligt i alla Azure-regioner som stöder Azure Databricks och tillhandahåller tillgänglighetszoner. En lista över regioner som stöder Azure Databricks finns i Produkter tillgängliga per region. En fullständig lista över regioner som stöder tillgänglighetszoner finns i Azure-regioner som stöder tillgänglighetszoner.
Lagringsreplikering: Konfigurera lagringskonton för arbetsytan så att de använder ZRS eller GZRS (där det är tillgängligt).
Beräkningskapacitet: Se till att det finns tillräckligt med beräkningskapacitet i flera zoner i målregionen. Azure Databricks distribuerar automatiskt klusternoder mellan zoner, men du bör kontrollera att dina valda instanstyper är tillgängliga i alla målzoner.
Överväganden
Azure Databricks distribuerar automatiskt klusternoder mellan tillgänglighetszoner. Fördelningen beror på tillgänglig kapacitet i varje zon. Under perioder med hög efterfrågan kan ett klusters noder koncentreras till färre zoner. När du använder serverlös beräkning hanterar Azure Databricks zonval av virtuella datorer och ersättning av virtuella datorer som kan gå förlorade på grund av zonfel.
Kostnad
Zonfördelningen påverkar inte beräkningskostnaderna eftersom du betalar för samma antal virtuella datorer oavsett deras placering i tillgänglighetszonen. Mer information finns i Prissättning för Azure Databricks-beräkning.
Standardredundansen för det hanterade lagringskontot, eller DBFS-roten, är geo-redundant lagring (GRS). Att byta till ZRS eller GZRS kan påverka dina lagringskostnader. Mer information finns i Priser för Azure Blob Storage.
Konfigurera stöd för tillgänglighetszoner
Kontrollplan: Kontrollplanet stöder automatiskt zonredundans i regioner som har tillgänglighetszoner. Du behöver inte konfigurera något.
DBFS-rot: Du kan konfigurera zonredundans för DBFS-rotlagring när du skapar en ny arbetsyta eller ändrar en befintlig arbetsyta:
Skapa ny arbetsyta med zonredundant DBFS-rotlagring: När du skapar en ny Azure Databricks-arbetsyta kan du konfigurera det associerade lagringskontot så att det använder ZRS eller GZRS i stället för standard-GRS. Mer information finns i Ändra redundansalternativ för arbetsytor.
Aktivera zonredundans på DBFS-rotlagring: För befintliga arbetsytor kan du ändra redundanskonfigurationen för arbetsytans lagringskonto till ZRS eller GZRS. Mer information om hur du aktiverar zonredundans finns i Ändra replikeringsinställningar för ett lagringskonto.
Beräkningsplan: Klusternoder distribueras automatiskt mellan tillgänglighetszoner. Ingen kundkonfiguration krävs för zondistribution.
Beteende när alla zoner är felfria
Det här avsnittet beskriver vad du kan förvänta dig när en arbetsyta konfigureras med stöd för tillgänglighetszoner och alla tillgänglighetszoner är i drift.
Datareplikering mellan zoner: Datareplikering för lagring av arbetsytor sker synkront mellan zoner när DBFS-roten använder ett ZRS- eller GZRS-konto. Den här metoden säkerställer stark konsekvens med minimal prestandapåverkan.
Trafikroutning mellan zoner: Azure Databricks distribuerar automatiskt klusternoder mellan zoner när klustret skapas. Tjänsten balanserar beräkningsbelastningen mellan zoner medan den upprätthåller datalokaliteten för optimala prestanda.
Beteende vid ett zonfel
Det här avsnittet beskriver vad du kan förvänta dig när en arbetsyta har konfigurerats med stöd för tillgänglighetszoner och det uppstår ett avbrott i tillgänglighetszonen.
Identifiering och svar: Microsoft identifierar automatiskt zonfel och initierar svarsprocedurer. Du behöver inte vidta några åtgärder för redundans på zonnivå.
Anmälan: Microsoft meddelar dig inte automatiskt när en zon är nere. Men du kan använda statussidan för Azure Databricks för att se en översikt över alla grundläggande Azure Databricks-tjänster. Du kan också prenumerera på statusuppdateringar för enskilda tjänstkomponenter och få en avisering när statusen för den tjänst som du prenumererar på ändras.
Aktiva begäranden: Kluster som körs kan förlora noder i den berörda zonen. Klusterhanteraren begär automatiskt ersättningsnoder från återstående zoner. Om drivrutinsnoden går förlorad startas klustret och jobbet om helt.
Förväntad dataförlust:
Kontrollplanet: Förvänta dig ingen dataförlust under ett zonavbrott.
DBFS-rot: Arbetsytedata är fortfarande tillgängliga om de använder ZRS- eller GZRS-lagringskonfigurationer.
Beräkningsplan: Data som cachelagras på virtuella datorer är tillfälliga. Data som förloras från virtuella datorer under ett zonfel återställs från lagringen. Om drivrutinsnoden går förlorad startar jobbet om och beräknar om resultatet.
Förväntad stilleståndstid:
Kontrollplan: Databricks-kontrollplanet utför automatisk redundans till felfria zoner inom cirka 15 minuter.
DBFS-rot: Förvänta dig ingen stilleståndstid för lagringskonton som använder ZRS eller GZRS.
Beräkningsplan: Om noder går förlorade på grund av att deras virtuella datorer finns i den berörda tillgänglighetszonen begär Azure-klusterhanteraren ersättningsnoder från Azure-beräkningsprovidern. Om de återstående felfria zonerna har tillräcklig kapacitet för att uppfylla begäran hämtar beräkningsprovidern noder från de felfria zonerna för att ersätta de förlorade noderna. Den här processen kan ta flera minuter.
Om drivrutinsnoden går förlorad på grund av zonfelet startas hela klustret om, vilket kan orsaka längre återställningstider jämfört med att förlora arbetsnoder. Planera för det här beteendet i dina strategier för schemaläggning och övervakning av jobb.
Du kan använda serverlösa pooler eller instanspooler för att minska den här gången.
Omdistribution av trafik:
Kontrollplan: Databricks-kontrollplanet utför automatisk övergång till fungerande zoner inom cirka 15 minuter.
DBFS-rot: Azure Storage omdirigerar automatiskt begäranden till lagringskluster i felfria zoner.
Beräkningsplan: Klusterhanteraren växlar automatiskt till noder i felfria zoner.
Zonåterställning
När den misslyckade tillgänglighetszonen återställs återupptar Azure Databricks automatiskt normala åtgärder i alla zoner. Klusterhanteraren kan balansera om nodfördelningen under efterföljande nodskapanden, men befintliga noder fortsätter att köras i sina aktuella zoner tills de avslutas.
Du behöver inte vidta några åtgärder för failback-processer. Normal zondistribution återupptas för nya klusterdistributioner.
Test för zonfel
Azure Databricks är en hanterad tjänst där Microsoft hanterar zonredundans automatiskt och utför regelbundna zon-down-tester. Du behöver inte testa zonfelscenarier för själva tjänsten.
För dina program som körs på Azure Databricks testar du jobbresiliens genom att simulera drivrutinsnodfel och övervaka omstartsbeteendet för kluster. Kontrollera att dina databearbetningsjobb kan hantera klusteromstarter och återuppta från lämpliga kontrollpunkter.
Motståndskraft mot regionomfattande fel
Azure Databricks är en tjänst med en region. Om regionen inte är tillgänglig är arbetsytan inte heller tillgänglig. Om du behöver distribuera till flera regioner kan du läsa Azure Databricks återställning vid katastrofer.
Anpassade lösningar för flera regioner för återhämtning
Azure Databricks tillhandahåller inte inbyggda funktioner för flera regioner. För omfattande skydd i flera regioner av dina analysarbetsbelastningar måste du implementera din egen metod.
Typiska lösningar för flera regioner omfattar två eller flera arbetsytor. Du kan välja mellan flera strategier, inklusive aktiv-passiva och aktiva-aktiva arkitekturer.
Tänk på följande faktorer för att välja en arkitektur:
- Arbetsbelastningens allvarlighetsgrad för ditt företag
- Den potentiella varaktigheten för ett avbrott (timmar eller eventuellt en hel dag)
- Det arbete som krävs för att arbetsytan ska fungera fullt ut
- Det arbete som krävs för att återställa eller återgå till den primära regionen
Information om arbetsbelastningar som kräver skydd i flera regioner finns i Haveriberedskap för Azure Databricks.
Säkerhetskopiering och återställning
Azure Databricks säkerhetskopierar automatiskt databaser som en del av tjänstens hanterade åtgärder. Den här processen omfattar notebook-innehåll, jobbdefinitioner, klusterkonfigurationer och inställningar för åtkomstkontroll.
Anmärkning
Om ett zonfel inträffar förväntar sig Azure Databricks ingen dataförlust.
Vi rekommenderar att du lagrar dina data på Unity Catalog-lagring. Du kan replikera data via lagringsreplikering eller deltakloning.
Säkerhetskopierings- och återställningsfunktioner på arbetsytan är inte direkt tillgängliga. Planera för procedurer för att återskapa arbetsytor som omfattar återställning av konfigurationer, användare och åtkomstkontroller från dina synkroniseringsprocesser.
Motståndskraft mot serviceunderhåll
Azure Databricks utför automatiskt plattformsunderhåll för att tillämpa säkerhetsuppdateringar, distribuera nya funktioner och förbättra tjänstens tillförlitlighet. Du kan konfigurera underhållsperioderna för klustret för att minska sannolikheten för underhåll som påverkar dina produktionsarbetsbelastningar. Mer information finns i Automatisk klusteruppdatering.
Serviceavtal
Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.