Herstel na noodgeval

Herstel na noodgevallen (DR) voor Azure Databricks repliceert werkruimten, gegevens en configuraties in cloudregio's, zodat uw teams blijven werken wanneer een regionale storing uw primaire implementatie offline haalt. Een volledig DR-plan omvat niet alleen Azure Databricks, maar ook de gegevensbronnen, opnamehulpprogramma's, BI-hulpprogramma's en planners waarmee het verbinding maakt.

Op deze pagina worden de concepten, strategieën, hulpprogramma's en testprocedures beschreven die u nodig hebt om een noodhersteloplossing voor meerdere regio's te ontwerpen en uit te voeren.

Nog niet bekend met DR-planning? Begin met terminologie van de branche voor herstel na noodgevallen voor definities van RPO en RTO.

Belangrijk

Gebruik beheerd herstel na noodgevallen. Azure Databricks raadt beheerd noodherstel aan voor noodherstel tussen regio's in AWS en Azure. Het repliceert metagegevens van Unity Catalog, beheerde tabelgegevens en werkruimteassets volgens een doorlopend schema, biedt een stabiele URL die failover naleeft en waarmee u failover kunt activeren vanuit de accountconsole. Er zijn geen replicatiescripts om te schrijven of te onderhouden. Gebruik de doe-het-zelfrichtlijnen op deze pagina alleen voor resources die niet door managed DR worden gerepliceerd, of als u active-active-topologieën, replicatie tussen clouds of gedetailleerde controle over de replicatiepijplijn nodig hebt.

Garanties voor hoge beschikbaarheid binnen regio's

De rest van deze pagina gaat over noodherstel tussen regio’s, maar Azure Databricks biedt ook hoge beschikbaarheid (HA) binnen één regio. Deze garanties eerst begrijpen. Ze bepalen of u een aparte DR-strategie nodig hebt.

HA en DR lossen verschillende problemen op:

HA maakt gebruik van beschikbaarheidszoneredundantie (AZ) binnen een regio. Als één zone mislukt, blijven services actief in de andere.
DR maakt gebruik van replicatie tussen regio's. U voert secundaire Azure Databricks werkruimten uit in een andere regio en repliceert gegevens en configuraties naar deze werkruimten en voert vervolgens een failover uit tijdens een regionale storing.

Als u dr voor meerdere regio's niet nodig hebt, is Azure Databricks hoge beschikbaarheid mogelijk voldoende. Hoge beschikbaarheid vermijdt regio-overschrijdende complexiteit, maar biedt geen bescherming tegen een uitval van een volledige regio. Als u voor DR alleen op HA vertrouwt, controleer dan de scheiding en redundantie van uw cloudregio's.

HA-garanties binnen de regio dekken zowel het besturingsvlak als de computerlaag.

Beschikbaarheid van het Azure Databricks besturingsvlak

Het Azure Databricks besturingsvlak is bestand tegen zonefouten en herstelt automatisch binnen ongeveer 15 minuten na een zonefout. Regelmatige tests op zone-uitval bevestigen dit.

Alle stateless besturingsvlakservices kunnen afzonderlijke VM's of alle VM's in een hele zone verliezen zonder de service uit te schakelen. Werkruimtegegevens worden opgeslagen in databases die worden gerepliceerd tussen zones in de regio. Opslagaccounts die Databricks Runtime-installatiekopieën hosten, zijn ook redundant binnen de regio, en alle regio's hebben secundaire opslagaccounts die het overnemen wanneer het primaire opslagaccount uitvalt.

Note

De bovenstaande garanties voor het besturingsvlak zijn van toepassing op Azure Databricks beheerde infrastructuur. U bent verantwoordelijk voor zoneredundantie op het rekenvlak, bijvoorbeeld het kiezen van zone-redundante opslag voor de hoofdbucket van de werkruimte en het gebruik van exemplaargroepen die beschikbaarheidszones omvatten.

Sommige Azure regio's maken gebruik van een besturingsvlak dat is geïmplementeerd in een gekoppelde regio. Bekijk Azure Databricks regio's.

De tolerantie voor zonefouten ondersteunt maximaal één zone die niet beschikbaar is en is alleen beschikbaar in Azure regio's die meerdere zones ondersteunen.

Beschikbaarheid van het rekenvlak

De beschikbaarheid van de werkruimte is afhankelijk van de beschikbaarheid van het besturingsvlak.

DBFS-hoofdgegevens worden niet beïnvloed als het opslagaccount is geconfigureerd met zone-redundante opslag (ZRS) of geografisch zone-redundante opslag (GZRS). De standaardwaarde is Geografisch redundante opslag (GRS).

Clusterknooppunten worden opgehaald uit verschillende beschikbaarheidszones door knooppunten aan te vragen bij de Azure rekenprovider, uitgaande van voldoende capaciteit in de resterende zones. Als een knooppunt verloren gaat, vraagt de clusterbeheerder vervangende knooppunten aan bij de Azure-rekenprovider, die deze ophaalt uit de beschikbare AZ's. De uitzondering doet zich voor wanneer de drivernode uitvalt. In dat geval start de clusterbeheerder de taak en het cluster opnieuw op.

Zie de lijst met Azure regio's om ondersteuning voor meerdere AZ's te bevestigen. Gebruik zone-redundante opslag voor multi-AZ veerkracht in de rekenomgeving.

Terminologie

Gebruik deze definities consistent bij het bespreken van herstel na noodgevallen met uw team.

Regioterminologie

Op deze pagina worden de volgende regiodefinities gebruikt:

Primaire regio: de regio waar gebruikers dagelijkse interactieve en geautomatiseerde workloads voor gegevensanalyse uitvoeren.
Secundaire regio: de regio waar IT-teams workloads tijdelijk verplaatsen tijdens een storing in de primaire regio.
Geografisch redundante opslag: Asynchrone replicatie tussen regio's van permanente opslag. Raadpleeg de documentatie van uw cloud:

Geografisch redundante opslag tussen regio's (Azure).

Belangrijk

Vertrouw niet op geografisch redundante opslag om de Azure Databricks-basisopslag (zoals de ADLS die Azure Databricks voor elke werkruimte maakt; voor werkruimten die vóór 6 maart 2023 zijn gemaakt, is dit Azure Blob Storage) tussen regio's te dupliceren. Als u beheerde tabelgegevens wilt repliceren, gebruikt u Delta Deep Clone en voor niet-Delta-gegevens, converteert u deze eerst naar Delta, waar mogelijk.

Terminologie voor implementatiestatus

Op deze pagina worden de volgende definities van de implementatiestatus gebruikt:

Actieve implementatie (ook wel dynamische implementatie genoemd): gebruikers maken er verbinding mee en voeren workloads uit. Taken en gegevensstromen worden hier volgens planning uitgevoerd.
Passieve implementatie (ook wel koude implementatie genoemd): Hier worden geen processen uitgevoerd. IT-teams houden het gereed door de implementatie van code, configuratie en andere Azure Databricks objecten te automatiseren. Een passieve implementatie wordt alleen actief wanneer de actieve implementatie uitvalt.

Belangrijk

Een project kan meerdere passieve implementaties in verschillende regio's bevatten voor extra tolerantie.

De meeste teams voeren één actieve implementatie tegelijk uit, de actief-passieve strategie. De minder gangbare actief-actieve strategie voert twee gelijktijdige actieve implementaties uit.

Terminologie van de industrie voor herstel na noodgevallen

Definieer deze twee branchetermen met uw team:

Herstelpuntdoelstelling (RPO):de maximale periode van gegevensverlies die uw service kan tolereren tijdens een groot incident. Zie RPO.

Azure Databricks slaat uw primaire klantgegevens niet op. Dat bevindt zich in ADLS (voor werkruimten die zijn gemaakt vóór 6 maart 2023, Azure Blob Storage) of andere systemen die u beheert. In het Azure Databricks besturingsvlak worden enkele objecten (zoals taken en notebooks) opgeslagen, zodat de Azure Databricks RPO de maximale periode is waarin wijzigingen in deze objecten verloren kunnen gaan. U bent verantwoordelijk voor het definiëren van de RPO voor uw klantgegevens in ADLS (voor werkruimten die zijn gemaakt vóór 6 maart 2023, Azure Blob Storage) en andere gegevensbronnen die u beheert.
Beoogde hersteltijd (RTO): de maximale tijd waarin een bedrijfsproces moet worden hersteld na een noodgeval. Zie RTO.

Herstel na noodgevallen en beschadiging van gegevens

Een DR-oplossing beperkt gegevensbeschadiging niet . Beschadigde gegevens in de primaire regio worden gerepliceerd naar de secundaire regio en zijn beschadigd in beide regio's. Als u dit soort fouten wilt verhelpen, gebruikt u Delta-tijdreizen, vergelijkbare hulpprogramma's of hulpprogramma's voor gegevensback-ups.

Typisch herstelproces

Een Azure Databricks dr-scenario wordt doorgaans als volgt uitgespeeld:

Een fout raakt een kritieke service in uw primaire regio: een gegevensbron, een netwerk of een andere afhankelijkheid waarop de Azure Databricks implementatie afhankelijk is.
U onderzoekt dit met uw cloudprovider.
Als de wachttijd onaanvaardbaar is, besluit u over te schakelen naar uw secundaire regio.
Controleer of hetzelfde probleem geen invloed heeft op uw secundaire regio.
Failover (zie Testfailover voor gedetailleerde stappen):
1. Stop alle activiteiten in de werkruimte. Gebruikers stoppen workloads en maken waar mogelijk een back-up van recente wijzigingen. Taken worden stopgezet (als de storing ze niet al heeft laten mislukken).
2. Voer de herstelprocedure voor secundaire regio's uit om routerings- en omleidingsverbindingen en netwerkverkeer bij te werken.
3. Verwerk downstreamsystemen (BI-hulpprogramma's, planners, integraties van derden) naar de secundaire werkruimte en hervat hun verbindingen.
4. Verklaar de secundaire regio operationeel na het testen. Gebruikers melden zich aan bij de nu-actieve implementatie en u kunt geplande of vertraagde taken opnieuw activeren.
Nadat het probleem met de primaire regio is verholpen, bevestig de oplossing.
Terugschakelen (raadpleeg Testterugzetting (terugschakelen)):
1. Stop al het werk in de secundaire regio.
2. Voer de herstelprocedure voor de primaire regio uit om de routering terug te leiden.
3. Repliceer nieuwe gegevens terug naar de primaire regio. Minimaliseer wat er moet worden gerepliceerd. Voor alleen-lezentaken die in de secundaire implementatie zijn uitgevoerd, is bijvoorbeeld mogelijk geen write-back vereist.
4. Test de implementatie in de primaire regio.
5. Declareer de primaire regio die actief is en hervat productieworkloads.

Belangrijk

Sommige gegevensverlies kunnen optreden tijdens deze stappen. Definieer hoeveel verlies acceptabel is voor uw organisatie en hoe u dit beperkt.

Stap 1: Inzicht in uw bedrijfsbehoeften

Bepaal welke gegevensservices essentieel zijn en definieer hun doel-RPO en RTO. Onderzoek de echte tolerantie van elk systeem.

DR, failover en failback dragen werkelijke kosten en risico's, waaronder beschadiging van gegevens, duplicatie van gegevens (schrijven naar de verkeerde opslaglocatie) en gebruikers die wijzigingen aanbrengen in de verkeerde regio.

Wijs elk Azure Databricks integratiepunt toe dat van invloed is op uw bedrijf en kies de hulpprogramma's en communicatiekanalen die uw plan gebruikt.

Integratiepunten om toe te wijzen

Moet uw DR-oplossing voldoen aan interactieve processen, geautomatiseerde processen of beide?
Welke gegevensservices gebruikt u? Sommige daarvan bevinden zich mogelijk on-premises.
Hoe worden invoergegevens naar de cloud verzonden?
Wie gebruikt deze gegevens? Welke processen verbruiken het downstream?
Zijn er integraties van derden die rekening moeten houden met wijzigingen in DR?

Hulpmiddelen en communicatie voor planning

Kunt u uw configuratie vooraf gedefinieerd en modulair maken om dr-oplossingen op een natuurlijke en onderhoudbare manier aan te bieden?
Welke communicatiemiddelen en kanalen informeren interne teams en externe partijen (integraties, afnemende systemen) over DR-failover- en failbackwijzigingen? Hoe bevestigt u hun bevestiging?
Welke services, indien aanwezig, sluit u af totdat volledig herstel is uitgevoerd?

Stap 2: Kies een proces dat voldoet aan de behoeften van uw bedrijf

Standaard ingesteld op beheerde disaster recovery. Het verzorgt de replicatie van werkruimten, Unity Catalog-metagegevens, gegevens van beheerde tabellen en failovercoördinatie zonder aangepaste scripts. Gebruik de onderstaande DIY-richtlijnen alleen als uw situatie buiten het toepassingsgebied ervan valt, bijvoorbeeld bij resources die niet door beheerde disaster recovery (DR) worden gerepliceerd, actief-actieftopologieën, cross-cloud-replicatie of fijnmazige controle over de replicatiepijplijn.

Een DIY-oplossing moet de juiste gegevens repliceren over het besturingsvlak, het rekenvlak en de gegevensbronnen. Redundante werkruimten worden toegewezen aan verschillende besturingsvlakken in verschillende regio's, zodat u ze gesynchroniseerd houdt met een op scripts gebaseerde oplossing, ofwel een synchronisatieprogramma of een CI/CD-werkstroom. Voor de gegevens zelf gebruiken de meeste teams Azure Databricks taken (vaak gepland) of Delta Deep Clone om tabellen tussen regio's te kopiëren. U hoeft geen gegevens te synchroniseren vanuit het rekenvlak (zoals van Databricks Runtime-werkrollen).

Als u de functie VNet-injectie gebruikt (niet beschikbaar voor alle abonnements- en implementatietypen), implementeert u netwerken consistent in beide regio's met behulp van hulpprogramma's op basis van sjablonen, zoals Terraform.

Repliceer uw gegevensbronnen naar behoefte in verschillende regio's.

DR-oplossingen hebben meestal betrekking op twee (of meer) werkruimten. Kies tussen de volgende strategieën op basis van de onderbrekingslengte die u moet tolereren, operationele inspanningen en de kosten om een failback naar de primaire regio uit te voeren.

Algemene aanbevolen procedures

Algemene best practices voor een succesvol disaster recovery-plan zijn onder andere:

Begrijp welke processen van cruciaal belang zijn voor het bedrijf en in DR moeten worden uitgevoerd.
Identificeer duidelijk welke services betrokken zijn, welke gegevens worden verwerkt, wat de gegevensstroom is en waar deze worden opgeslagen.
De services en gegevens zoveel mogelijk isoleren. Maak bijvoorbeeld een speciale cloudopslagcontainer voor de DR-gegevens of verplaats Azure Databricks objecten die nodig zijn tijdens een noodgeval naar een afzonderlijke werkruimte.
U bent verantwoordelijk voor het onderhouden van integriteit tussen primaire en secundaire implementaties voor objecten die niet zijn opgeslagen in het Azure Databricks besturingsvlak.
Gebruik voor gegevensbronnen systeemeigen Azure hulpprogramma's om waar mogelijk gegevens te repliceren naar uw DR-regio's.

Waarschuwing

Sla geen gegevens op in de hoofd-ADLS (voor werkruimten die zijn gemaakt vóór 6 maart 2023 Azure Blob Storage) die worden gebruikt voor DBFS-hoofdtoegang. DBFS-hoofdopslag wordt niet ondersteund voor productieklantgegevens. Azure Databricks raadt het ook af om daar bibliotheken, configuratiebestanden of init-scripts op te slaan.

Strategie voor actief-passieve oplossingen

Deze sectie is gericht op de actief-passieve strategie, omdat het de meest voorkomende, de eenvoudigste en de meest rendabele is. Een actief-passieve oplossing synchroniseert gegevens en objectwijzigingen van uw actieve implementatie naar een passieve implementatie in een secundaire regio. Tijdens een DR-gebeurtenis wordt de passieve implementatie actief.

Twee veelvoorkomende varianten:

Unified (bedrijfsbrede): één set actieve en passieve implementaties ondersteunt de hele organisatie.
Per afdeling of project: elk domein onderhoudt een eigen DR-oplossing met primaire en secundaire regio's die zijn afgestemd op de behoeften.

U kunt ook een passieve implementatie gebruiken voor read-only-workloads, zoals gebruikersquery’s, die geen gegevens of Azure Databricks-objecten wijzigen.

Strategie voor actief-actieve oplossingen

In een actief-actief oplossing worden alle gegevensprocessen altijd parallel uitgevoerd in beide regio's. Uw operationsteam mag elke taak pas als voltooid markeren nadat deze in beide regio's succesvol is uitgevoerd. Objecten kunnen niet worden gewijzigd in productie en moeten een strikt CI/CD-promotieproces volgen van ontwikkeling/staging naar productie.

Actief-actief is de meest complexe strategie en kost meer omdat jobs in beide regio's draaien, maar biedt wel de laagste RTO en RPO.

U kunt actief-actief bedrijfsbreed of per afdeling implementeren. U hebt geen dubbele werkruimte nodig voor elke workload. Ontwikkel- of faseringswerkruimten zijn bijvoorbeeld vaak gemakkelijker te reconstrueren vanuit een ontwikkelingspijplijn dan om gesynchroniseerd te blijven.

Kies uw tools

Uw hulpprogramma's kiezen

Er zijn twee belangrijke benaderingen voor het synchroniseren van gegevens tussen werkruimten in uw primaire en secundaire regio's:

Synchronisatieclient die kopieert van primair naar secundair: een synchronisatieclient pusht productiegegevens en assets van de primaire regio naar de secundaire regio. Dit wordt doorgaans op geplande basis uitgevoerd en de planningsfrequentie is afhankelijk van uw doel-RTO en RPO.
CI/CD-hulpprogramma's voor parallelle implementatie: voor productiecode en assets gebruikt u CI/CD-hulpprogramma's waarmee wijzigingen in productiesystemen tegelijkertijd naar beide regio's worden gepusht. Wanneer u bijvoorbeeld code en assets pusht van fasering/ontwikkeling naar productie, maakt een CI/CD-systeem het tegelijkertijd beschikbaar in beide regio's. Het belangrijkste idee is om alle artefacten in een Azure Databricks-werkruimte als infrastructuur als code te behandelen. De meeste artefacten kunnen gezamenlijk worden geïmplementeerd in zowel primaire als secundaire werkruimten, terwijl sommige artefacten mogelijk pas na een DR-gebeurtenis moeten worden geïmplementeerd. Zie Automation-scripts, -voorbeelden en -prototypes voor hulpprogramma's.

Afhankelijk van uw behoeften kunt u de benaderingen combineren. Gebruik bijvoorbeeld CI/CD voor de broncode van notebooks, maar gebruik synchronisatie voor configuratie zoals pools en toegangsrechten.

In de volgende tabel wordt beschreven hoe u elk type gegevens kunt verwerken met elke optie voor hulpprogramma's.

Beschrijving	Hoe om te gaan met CI/CD-hulpprogramma's	Hoe om te gaan met het synchronisatieprogramma
Broncode: notebook source exports en broncode voor verpakte bibliotheken	Implementeer zowel op de primaire als de secundaire locatie.	Synchroniseer de broncode van de primaire naar de secundaire.
Gebruikers en groepen	Metagegevens beheren als configuratie in Git. U kunt ook dezelfde id-provider (IdP) gebruiken voor beide werkruimten. Implementeer gebruikers- en groepsgegevens samen naar primaire en secundaire implementaties.	Gebruik SCIM of andere automatisering voor beide regio's. Handmatig maken wordt niet aanbevolen, maar als het wordt gebruikt moet het voor beiden tegelijk uitgevoerd worden. Als u een handmatige installatie gebruikt, maakt u een gepland geautomatiseerd proces om de lijst met gebruikers en groepen tussen de twee implementaties te vergelijken.
Poolconfiguraties	Dit kunnen sjablonen zijn in Git. Co-implementatie naar primaire en secundaire. Echter moet `min_idle_instances` aan de secundaire zijde nul zijn tot de DR-gebeurtenis.	Pools die met `min_idle_instances` zijn gemaakt, worden gesynchroniseerd naar een secundaire werkruimte met behulp van de API of CLI.
Taakconfiguraties	Gebruik Databricks Asset Bundles met doelen per omgeving (bijvoorbeeld `prod` en `dr`) om dezelfde taakdefinitie in beide regio's te implementeren. Stel voor de secundaire implementatie gelijktijdigheid in op nul, zodat de taak is gefaseerd, maar niet wordt uitgevoerd. Wijzig de gelijktijdigheidswaarde nadat de secundaire implementatie actief is.	Als de taken om een of andere reden worden uitgevoerd op bestaande `<interactive>` clusters, moet de synchronisatieclient worden toegewezen aan de bijbehorende `cluster_id` in de secundaire werkruimte.
ACL’s (toegangsbeheerlijsten)	Dit kunnen sjablonen zijn in Git. Implementeer samen naar primaire en secundaire implementaties voor notebooks, mappen en clusters. Bewaar de gegevens voor jobs echter tot aan de DR-gebeurtenis.	De Machtigingen-API kan toegangsbeheer instellen voor clusters, taken, pools, notebooks en mappen. Een synchronisatieclient moet worden gekoppeld aan de bijbehorende object-ID's voor elk object in de secundaire werkruimte. Databricks raadt u aan een kaart te maken van object-id's van primaire naar secundaire werkruimte tijdens het synchroniseren van deze objecten voordat u de toegangsbeheerreplicaties repliceert.
Bibliotheken	Opnemen in broncode- en cluster-/opdrachtsjablonen.	Aangepaste bibliotheken synchroniseren vanuit gecentraliseerde opslagplaatsen, DBFS of cloudopslag (kan worden gekoppeld).
Cluster-init-scripts	Voeg de broncode toe als je dat wilt.	Voor eenvoudigere synchronisatie slaat u init-scripts op in de primaire werkruimte in een gemeenschappelijke map of in een kleine set mappen, indien mogelijk.
Koppelpunten	Opnemen in broncode als deze alleen wordt gemaakt via op notebooks gebaseerde taken of opdracht-API.	Gebruik taken die kunnen worden uitgevoerd als ADF-activiteiten (Azure Data Factory ). Houd er rekening mee dat de opslageindpunten kunnen veranderen, gezien de werkruimten zich in verschillende regio's bevinden. Dit hangt ook sterk af van uw disaster recovery-strategie voor data.
Metagegevens van tabel	Voor Unity Catalog-objecten (catalogi, schema's, tabellen, volumes en subsidies) implementeert u samen met de Databricks Terraform-provider of Databricks Asset Bundles. Neem voor oude Hive-metastoretabellen CREATE TABLE-instructies op in de broncode als ze zijn gemaakt met notebookgebaseerde taken of de Command API.	Lees voor Unity Catalog-objecten de bronmetadata uit systeemtabellen of `information_schema` en repliceer deze naar de secundaire werkruimte met behulp van de Databricks SDK. Voor verouderde Hive-metastoretabellen vergelijkt u metagegevensdefinities tussen metastores met behulp van de Spark Catalog-API of `SHOW CREATE TABLE` via een notebook of scripts. Onderliggende opslagpaden kunnen op regio's zijn gebaseerd en kunnen verschillen tussen metastore-exemplaren.
Geheimen	Opnemen in broncode als deze alleen is gemaakt via de Opdracht-API. Houd er rekening mee dat bepaalde geheime inhoud mogelijk moet worden gewijzigd tussen de primaire en secundaire inhoud.	Geheimen worden via de API gemaakt in beide werkruimten. Houd er rekening mee dat bepaalde geheime inhoud mogelijk moet worden gewijzigd tussen de primaire en secundaire inhoud.
Clusterconfiguraties	Dit kunnen sjablonen zijn in Git. Gelijktijdig implementeren naar primaire en secundaire omgevingen, hoewel de implementaties in de secundaire omgeving tot de DR-gebeurtenis uitgeschakeld moeten blijven.	Clusters worden gemaakt nadat ze zijn gesynchroniseerd met de secundaire werkruimte met behulp van de API of CLI. Deze kunnen desgewenst expliciet worden beëindigd, afhankelijk van instellingen voor automatische beëindiging.
Machtigingen voor notitieblokken, taken en mappen	Dit kunnen sjablonen zijn in Git. Gezamenlijk uitvoeren bij primaire en secundaire implementaties.	Repliceren met behulp van de Machtigingen-API.

Regio's en meerdere secundaire werkruimten kiezen

U bepaalt wanneer DR wordt geactiveerd en naar welke secundaire regio u failover uitvoert. U bent ook verantwoordelijk voor het stabiliseren van de DR-omgeving voordat u de normale bewerkingen hervat. Dit betekent meestal dat u meerdere Azure Databricks werkruimten maakt voor productie en herstel na noodgevallen en vervolgens een secundaire failoverregio kiest.

Voordat u uw secundaire regio selecteert, controleert u of alle resources en services die u afhankelijk bent van (rekentypen, producten, integraties) daar beschikbaar zijn. Sommige Azure Databricks services zijn alleen beschikbaar in specifieke regio's.

Controleer ook de beschikbaarheid van gegevensreplicatie en vm-type.

Stap 3: Werkruimten voorbereiden en eenmalige kopie maken

Maak eerst een secundaire Azure Databricks werkruimte (of werkruimten) en de bijbehorende ondersteunende metastore in uw gekozen secundaire regio. De secundaire werkruimte moet de configuratie van het primaire account, de regio en de identiteit spiegelen voordat u er gegevens of assets naar kunt repliceren.

Als u beheerd noodherstel gebruikt, handelt Azure Databricks de initiële configuratie af van catalogi en werkruimte-assets die binnen het bereik vallen wanneer u een failovergroep maakt. U hoeft voor deze bronnen geen eenmalige kopie uit te voeren. Ga in de rest van deze sectie verder met eventuele gegevensbronnen of assets die beheerde disaster recovery niet repliceert.

Voor een productiewerkruimte die buiten de reikwijdte van beheerde disaster recovery valt, voert u een eenmalige kopieeractie uit om de passieve implementatie te synchroniseren met de actieve implementatie. Deze kopieergrepen:

Gegevensreplicatie: gebruik een cloudreplicatieoplossing of Delta Deep Clone.
Token genereren: automatiseer replicatie en toekomstige workloads met gegenereerde tokens.
Werkruimtereplicatie: Repliceren met behulp van de methoden in stap 4: Uw gegevensbronnen voorbereiden. Zie Werkruimtegegevens exporteren voor uitgebreide richtlijnen voor het exporteren van werkruimteconfiguratie, -gegevens en AI/ML-assets.
Werkruimtevalidatie: test de werkruimte en het proces om te bevestigen dat ze correct worden uitgevoerd en de verwachte resultaten opleveren.

Volgende synchronisaties worden sneller uitgevoerd dan de eerste kopie en uw hulpprogrammalogboeken registreren wat er is gewijzigd en wanneer.

Stap 4: Uw gegevensbronnen voorbereiden

Azure Databricks kan een grote verscheidenheid aan gegevensbronnen verwerken met behulp van batchverwerking of gegevensstromen.

Batchverwerking vanuit gegevensbronnen

Batchgegevens bevinden zich meestal in een bron die u kunt repliceren of leveren aan een andere regio.

Gegevens worden bijvoorbeeld vaak volgens een planning geüpload naar cloudopslag. Wijs die uploads in de DR-modus naar uw opslag in de secundaire regio en pas de workloads aan zodat ze van die opslag lezen en ernaar schrijven.

Gegevensstromen

Het verwerken van een gegevensstroom is een grotere uitdaging. Streaminggegevens kunnen worden opgenomen uit verschillende bronnen, verwerkt en verzonden naar een streamingoplossing:

Berichtenwachtrij zoals Kafka
Gegevensopnamestroom voor databasewijziging
Continue verwerking op basis van bestanden
Geplande verwerking op basis van bestanden, ook wel bekend als eenmalige trigger

In al deze gevallen moet u uw gegevensbronnen zo configureren dat ze de DR-modus ondersteunen en uw secundaire deployment in uw secundaire regio gebruiken.

Een streamschrijver slaat een controlepunt op met informatie over de gegevens die zijn verwerkt. Dit controlepunt kan een gegevenslocatie (meestal cloudopslag) bevatten die moet worden gewijzigd in een nieuwe locatie om ervoor te zorgen dat de stream opnieuw wordt opgestart. De submap bij het controlepunt kan bijvoorbeeld de bestandgebaseerde cloudmap opslaan.

Dit controlepunt moet tijdig worden gerepliceerd. Overweeg synchronisatie van het controlepuntinterval met een nieuwe cloudreplicatieoplossing.

De controlepuntupdate is een functie van de schrijver en is daarom van toepassing op opname of verwerking van gegevensstromen en opslaan op een andere streamingbron.

Voor streamingworkloads moet u ervoor zorgen dat controlepunten zijn geconfigureerd in door de klant beheerde opslag, zodat ze kunnen worden gerepliceerd naar de secundaire regio voor het hervatten van workloads vanaf het punt van de laatste fout. U kunt er ook voor kiezen om het secundaire streamingproces parallel aan het primaire proces uit te voeren.

Stap 5: Uw oplossing implementeren en testen

Als u beheerd herstel na noodgevallen gebruikt, kunt u een geplande failover activeren vanuit de accountconsole om te controleren of uw installatie end-to-end werkt. Dezelfde procedure omvat zowel DR-tests als echte storingen. Zie Failover en failback.

Test uw DR-installatie regelmatig. Een niet-getest dr-plan mislukt vaak wanneer u dit nodig hebt. Sommige teams schakelen elke paar maanden tussen actieve regio's volgens een planning om veronderstellingen, oefeningsprocessen te valideren en het team vertrouwd te houden met het runbook.

Belangrijk

Test uw DR-oplossing in praktijkomstandigheden volgens een regelmatig schema.

Als bij een test een ontbrekend object of sjabloon wordt weergegeven, werkt u uw plan bij: verwijder de afhankelijkheid, repliceer deze naar de secundaire werkruimte of maak het beschikbaar op een andere manier.

Test ook de wijzigingen in de organisatie en configuratie. Uw DR-plan is van invloed op uw implementatiepijplijn, dus het team moet weten wat er gesynchroniseerd moet blijven. Nadat u DR-werkruimten hebt ingesteld, controleert u of uw infrastructuur, taken, notebooks, bibliotheken en andere werkruimteobjecten beschikbaar zijn in de secundaire regio.

Breid uw standaardwerkprocessen en configuratiepijplijnen uit om wijzigingen in alle werkruimten te implementeren. Beheer gebruikersidentiteiten in werkruimten en configureer taakautomatisering en -bewaking voor de nieuwe werkruimten.

Plan en test wijzigingen in uw configuratiehulpmiddelen.

Configuratiewijzigingen voor het plannen en testen

Bereid voor elk van de volgende zaken een plan voor voor failover en test alle veronderstellingen:

Opname: inzicht krijgen in waar uw gegevensbronnen zich bevinden en waar deze bronnen hun gegevens ophalen. Indien mogelijk kunt u de bron parameteriseren en een afzonderlijke configuratiesjabloon gebruiken voor de secundaire implementatie en regio.
Wijzigingen in de uitvoering: Als u een planner hebt om taken of andere acties te activeren, hebt u mogelijk een afzonderlijke planner nodig die werkt met de secundaire implementatie of de bijbehorende gegevensbronnen.
Interactieve connectiviteit: Overweeg hoe configuratie-, verificatie- en netwerkverbindingen kunnen worden beïnvloed door regionale onderbrekingen voor het gebruik van REST API's, CLI-hulpprogramma's of andere services, zoals JDBC/ODBC.
Automatiseringswijzigingen: voor alle automatiseringsprogramma's.
Uitvoer: Voor alle hulpprogramma's die uitvoergegevens of logboeken genereren.
Downstreamwijzigingen: Voor BI-hulpprogramma's, dashboards, planners en integraties van derden die lezen van of schrijven naar Azure Databricks, plant u hoe u ze opnieuw kunt aanwijzen in de secundaire werkruimte en hun eigenaren hiervan op de hoogte stelt.

Testfailover

Test-failover

Veel scenario's kunnen disaster recovery (DR) in gang zetten: een onverwachte storing in het cloudnetwerk, de cloudopslag of een andere kernservice, waarbij u niet gecontroleerd kunt afsluiten; een geplande uitschakeling of storing; of zelfs periodiek schakelen tussen regio's als onderdeel van uw testcyclus.

Als u failover wilt testen, maakt u verbinding met het systeem en voert u een afsluiting uit. Controleer of alle taken zijn voltooid en dat clusters worden beëindigd.

Een synchronisatieclient (of CI/CD-hulpprogramma's) repliceert relevante Azure Databricks objecten en resources naar de secundaire werkruimte. Als u de secundaire werkruimte wilt activeren, bevat uw proces mogelijk een of meer van de volgende opties:

Voer tests uit om te controleren of het platform up-to-date is.
Schakel pools en clusters in de primaire regio uit, zodat als de mislukte service online wordt geretourneerd, de primaire regio niet begint met het verwerken van nieuwe gegevens.
Voer het herstelproces voor uw gegevensbronnen uit (zie hieronder).
Start relevante pools (of verhoog het min_idle_instances naar een relevant getal).
Start de relevante clusters (indien niet gestopt).
Wijzig de parallelle uitvoering voor taken en voer de relevante taken uit. Dit kunnen eenmalige uitvoeringen of periodieke uitvoeringen zijn.
Voor elk extern hulpprogramma dat gebruikmaakt van een URL of domeinnaam voor uw Azure Databricks-werkruimte, werkt u configuraties bij om rekening te houden met het nieuwe besturingsvlak. Werk bijvoorbeeld URL's voor REST API's en JDBC-/ODBC-verbindingen bij. De klantgerichte URL van de Azure Databricks-webtoepassing wordt gewijzigd wanneer het besturingsvlak wordt gewijzigd, dus informeer de gebruikers van uw organisatie over de nieuwe URL.

Details van herstelproces

Controleer de datum van de meest recente gesynchroniseerde gegevens. Zie de terminologie van de branche voor herstel na noodgevallen. De details van deze stap variëren, afhankelijk van hoe u gegevens en uw unieke bedrijfsbehoeften synchroniseert.
Stabiliseer uw gegevensbronnen en zorg ervoor dat ze allemaal beschikbaar zijn. Neem alle externe gegevensbronnen op, zoals Azure Cloud SQL en uw Delta Lake, Parquet of andere bestanden.
Zoek uw streaming-herstelpunt. Stel het proces in om van daaruit opnieuw op te starten en een proces gereed te hebben om potentiële duplicaten te identificeren en te elimineren (Delta Lake maakt dit eenvoudiger).
Voltooi het gegevensstroomproces en informeer de gebruikers.

Herstel testen (failback)

Test herstel (failback)

Failback is eenvoudiger te beheren en kan worden uitgevoerd in een onderhoudsvenster. Plan een of meer van de volgende stappen:

Bevestiging ontvangen dat de primaire regio is hersteld.
Schakel pools en clusters in de secundaire regio uit, zodat er geen nieuwe gegevens worden verwerkt.
Synchroniseer nieuwe of gewijzigde assets in de secundaire werkruimte terug naar de primaire implementatie. Afhankelijk van het ontwerp van uw failoverscripts, kunt u mogelijk dezelfde scripts uitvoeren om objecten van de secundaire regio (DR) te synchroniseren naar de primaire (productie) regio.
Synchroniseer eventuele nieuwe gegevensupdates terug naar de primaire implementatie. U kunt de audittrails van logboeken en Delta-tabellen gebruiken om geen gegevensverlies te garanderen.
Schakel alle workloads in de DR-regio uit.
Wijzig de URL van taken en gebruikers in de primaire regio en verwijs downstreamverbindingen (BI-hulpprogramma's, planners, integraties van derden) terug naar deze regio.
Voer tests uit om te controleren of het platform up-to-date is.
Start relevante pools (of verhoog het min_idle_instances naar een relevant getal).
Start de relevante clusters (indien niet gestopt).
Wijzig de gelijktijdige runs voor taken en voer relevante taken uit. Dit kunnen eenmalige uitvoeringen of periodieke uitvoeringen zijn.
Stel indien nodig uw secundaire regio opnieuw in voor toekomstige disaster recovery.

Automatiseringsscripts, voorbeelden en prototypen

Voor AWS en Azure zorgt beheerde disaster recovery voor replicatie van werkruimten en beheerde tabellen zonder maatwerkautomatisering. De onderstaande referenties zijn alleen van toepassing als u een doe-het-zelfoplossing maakt buiten de reikwijdte van beheerde disaster recovery.

Voor DIY DR-pijplijnen gebruikt u de Databricks Terraform-provider om werkruimteassets te beheren als code en gezamenlijk te implementeren in primaire en secundaire regio's.

Als u Azure Databricks vanuit Azure Data Factory orkestreert, repliceer dan de relevante ADF-pipelines zodat deze verwijzen naar een gekoppelde service die is gekoppeld aan de secundaire werkruimte.

Aanvullende bronnen

Feedback

Is deze pagina nuttig?

Last updated on 2026-06-23

Herstel na noodgeval

Garanties voor hoge beschikbaarheid binnen regio's

Beschikbaarheid van het Azure Databricks besturingsvlak

Beschikbaarheid van het rekenvlak

Terminologie

Regioterminologie

Terminologie voor implementatiestatus

Terminologie van de industrie voor herstel na noodgevallen