Odzyskiwanie po awarii

Odzyskiwanie po awarii (DR) dla Azure Databricks replikuje obszary robocze, dane i konfiguracje w regionach chmury, aby zespoły działały, gdy awaria regionalna przełączy podstawowe wdrożenie w tryb offline. Kompletny plan odzyskiwania po awarii obejmuje nie tylko Azure Databricks, ale źródła danych, narzędzia pozyskiwania, narzędzia analizy biznesowej i harmonogramy, z którymi się łączy.

Ta strona omawia pojęcia, strategie, narzędzia i procedury testowe potrzebne do zaprojektowania i uruchomienia rozwiązania do odzyskiwania po awarii obejmującego wiele regionów.

Nie znasz jeszcze planowania odzyskiwania po awarii? Zacznij od Terminologii branżowej dotyczącej odzyskiwania po awarii, aby poznać definicje RPO i RTO.

Ważne

Użyj zarządzanego odzyskiwania po awarii. Azure Databricks zaleca zarządzane odzyskiwanie po awarii dla odzyskiwania po awarii między regionami na platformie AWS i Azure. Replikuje metadane Unity Catalog, dane tabel zarządzanych oraz zasoby obszaru roboczego w sposób ciągły, zapewnia stabilny adres URL, który pozostaje niezmienny po przełączeniu awaryjnym, i umożliwia zainicjowanie przełączenia awaryjnego z konsoli konta. Brak skryptów replikacji do napisania ani utrzymania. Korzystaj ze wskazówek DIY na tej stronie tylko w przypadku zasobów, których zarządzane odzyskiwanie po awarii nie replikuje, albo jeśli potrzebujesz topologii aktywne-aktywne, replikacji między chmurami lub szczegółowej kontroli nad procesem replikacji.

Gwarancje wysokiej dostępności wewnątrz regionu

Pozostała część informacji na tej stronie dotyczy odzyskiwania po awarii międzyregionalnej, ale usługa Azure Databricks zapewnia również wysoką dostępność (HA) w obrębie jednego regionu. Najpierw zapoznaj się z tymi gwarancjami. Określają, czy potrzebujesz osobnej strategii DR.

HA i DR rozwiązują różne problemy:

HA korzysta z nadmiarowości stref dostępności (AZ) w obrębie regionu. Jeśli jedna strefa ulegnie awarii, usługi będą nadal działać w innych.
DR korzysta z replikacji między regionami. Uruchamiasz pomocnicze obszary robocze usługi Azure Databricks w innym regionie i replikujesz do nich dane oraz konfiguracje, a następnie przełączasz się na nie podczas awarii regionu.

Jeśli nie potrzebujesz odzyskiwania po awarii obejmującego wiele regionów, wysoka dostępność usługi Azure Databricks może wystarczyć. HA pozwala uniknąć złożoności związanej z wieloma regionami, ale nie chroni przed awarią całego regionu. Jeśli polegasz wyłącznie na HA jako rozwiązaniu DR, zweryfikuj odseparowanie i redundancję swojego regionu chmurowego.

Gwarancje HA w obrębie regionu obejmują płaszczyznę sterowania i płaszczyznę obliczeniową.

Dostępność płaszczyzny sterowania Azure Databricks

Warstwa sterowania Azure Databricks jest odporna na awarie stref i automatycznie wraca do działania w ciągu około 15 minut od awarii strefy. Regularne testy awarii strefy to potwierdzają.

Wszystkie bezstanowe usługi płaszczyzny sterowania mogą stracić poszczególne maszyny wirtualne lub wszystkie maszyny wirtualne w całej strefie bez przerywania działania usługi. Dane obszaru roboczego są przechowywane w bazach danych replikowanych między strefami w regionie. Konta magazynowe, które udostępniają obrazy środowiska Databricks Runtime, są również nadmiarowe w obrębie regionu, a we wszystkich regionach istnieją pomocnicze konta magazynowe, które przejmują ich rolę, gdy podstawowe konto jest niedostępne.

Note

Powyższe gwarancje płaszczyzny sterowania dotyczą infrastruktury zarządzanej Azure Databricks. Odpowiadasz za nadmiarowość strefy obliczeniowej, na przykład wybór magazynu strefowo nadmiarowego dla zasobnika głównego obszaru roboczego i używanie pul wystąpień obejmujących strefy dostępności.

Niektóre regiony Azure korzystają z płaszczyzny sterowania wdrożonej w sparowanym regionie. Zobacz regiony usługi Azure Databricks .

Odporność na awarię strefy obsługuje niedostępność co najwyżej jednej strefy i jest dostępna tylko w regionach platformy Azure, które obsługują wiele stref.

Dostępność płaszczyzny obliczeniowej

Dostępność obszaru roboczego zależy od dostępności płaszczyzny sterowania.

Nie ma to wpływu na dane główne systemu plików DBFS, jeśli konto magazynu jest skonfigurowane z magazynem strefowo nadmiarowym (ZRS) lub magazynem geograficznie nadmiarowym (GZRS). Wartość domyślna to magazynowanie geograficznie nadmiarowe (GRS).

Węzły klastra są pozyskiwane z różnych stref dostępności poprzez żądanie węzłów od dostawcy usług obliczeniowych Azure, przy założeniu, że w pozostałych strefach są dostępne wystarczające zasoby. W przypadku utraty węzła menedżer klastra żąda węzłów zastępczych od dostawcy zasobów obliczeniowych platformy Azure, który pobiera je z dostępnych stref dostępności. Wyjątek dotyczy utraty węzła sterownika. W takim przypadku menedżer klastra ponownie uruchamia zadanie i klaster.

Aby potwierdzić obsługę wielu stref dostępności, zobacz listę regionów platformy Azure. W przypadku wielostrefowej odporności płaszczyzny obliczeniowej należy użyć magazynu z nadmiarowością strefową.

Terminologia

Używaj tych definicji konsekwentnie podczas omawiania DR z zespołem.

Terminologia dotycząca regionów

Na tej stronie są używane następujące definicje regionów:

Region podstawowy: region, w którym użytkownicy uruchamiają codzienne interaktywne i zautomatyzowane obciążenia analizy danych.
Region pomocniczy: region, w którym zespoły IT tymczasowo przenoszą obciążenia podczas awarii w regionie podstawowym.
Magazynowanie geonadmiarowe: Asynchroniczna replikacja trwałego magazynu danych między regionami. Zapoznaj się z dokumentacją chmury:

Magazynowanie geograficznie nadmiarowe między regionami (Azure).

Ważne

Nie należy polegać na magazynie geonadmiarowym do powielania głównego magazynu Azure Databricks między regionami (na przykład usługi ADLS, którą Azure Databricks tworzy dla każdego obszaru roboczego, a w przypadku obszarów roboczych utworzonych przed 6 marca 2023 r. — usługi Azure Blob Storage). Aby replikować dane w tabeli zarządzanej, użyj funkcji Delta Deep Clone, a w przypadku danych innych niż Delta najpierw przekonwertuj je do formatu Delta, jeśli to możliwe.

Terminologia dotycząca stanu wdrożenia

Na tej stronie są używane następujące definicje stanu wdrożenia:

Aktywne wdrożenie (nazywane czasem gorącym wdrożeniem): użytkownicy łączą się z nim i uruchamiają obciążenia. Zadania i strumienie danych są uruchamiane tutaj zgodnie z harmonogramem.
Wdrożenie pasywne (nazywane czasem zimnym wdrożeniem): w tym miejscu nie są uruchamiane żadne procesy. Zespoły IT utrzymują gotowość tego środowiska, automatyzując wdrażanie kodu, konfiguracji i innych obiektów platformy Azure Databricks. Wdrożenie pasywne staje się aktywne tylko wtedy, gdy aktywne wdrożenie ulegnie awarii.

Ważne

Projekt może obejmować wiele pasywnych wdrożeń w różnych regionach w celu uzyskania dodatkowej odporności.

Większość zespołów uruchamia jedno aktywne wdrożenie naraz— strategię aktywne-pasywne . Rzadziej spotykana strategia active-active obejmuje dwa jednocześnie aktywne wdrożenia.

Terminologia branżowa odzyskiwania po awarii

Zdefiniuj te dwa terminy branżowe z zespołem:

Cel punktu odzyskiwania (RPO): maksymalny okres utraty danych, który usługa może tolerować podczas poważnego incydentu. Zobacz RPO.

Azure Databricks nie przechowuje podstawowych danych klienta. Znajduje się to w usłudze ADLS (w przypadku obszarów roboczych utworzonych przed 6 marca 2023 r. — w usłudze Azure Blob Storage) lub w innych systemach, które kontrolujesz. Płaszczyzna sterowania Azure Databricks przechowuje niektóre obiekty (takie jak zadania i notesniki), więc wskaźnik RPO usługi Azure Databricks to maksymalny okres, w którym zmiany w tych obiektach mogą zostać utracone. Odpowiadasz za zdefiniowanie wskaźnika RPO dla danych klienta w usłudze ADLS (w przypadku obszarów roboczych utworzonych przed 6 marca 2023 r. — w usłudze Azure Blob Storage) oraz w innych źródłach danych, które kontrolujesz.
Cel czasu odzyskiwania (RTO) : maksymalny czas, w którym proces biznesowy musi zostać przywrócony po awarii. Zobacz RTO.

Odzyskiwanie po awarii i uszkodzenie danych

Rozwiązanie odzyskiwania po awarii nie ogranicza uszkodzenia danych. Uszkodzone dane w regionie podstawowym są replikowane do regionu pomocniczego i są uszkodzone w obu regionach. Aby ograniczyć skutki tego rodzaju błędu, użyj Delta time travel, podobnych narzędzi lub narzędzi do tworzenia kopii zapasowych danych.

Typowy przepływ pracy związanej z odzyskiwaniem

Scenariusz odzyskiwania po awarii Azure Databricks zwykle występuje w następujący sposób:

Awaria uderza w usługę krytyczną w regionie podstawowym: źródło danych, sieć lub inna zależność, na którym opiera się wdrożenie Azure Databricks.
Prowadzisz dochodzenie wraz ze swoim dostawcą usług chmurowych.
Jeśli oczekiwanie jest niedopuszczalne, zdecydujesz się przejść w tryb failover do regionu pomocniczego.
Upewnij się, że ten sam problem nie ma wpływu na region pomocniczy.
Przełącz awaryjnie (szczegółowe instrukcje znajdują się w sekcji Test przełączenia awaryjnego):
1. Zatrzymaj całą aktywność w obszarze roboczym. Użytkownicy zatrzymują obciążenia i tworzą kopię zapasową najnowszych zmian tam, gdzie to możliwe. Zadania są zatrzymywane (jeśli awaria nie spowodowała już ich niepowodzenia).
2. Uruchom procedurę odzyskiwania w regionie pomocniczym, aby zaktualizować routing oraz przekierować połączenia i ruch sieciowy.
3. Przekieruj systemy podrzędne (narzędzia BI, harmonogramy zadań, integracje zewnętrzne) do pomocniczego obszaru roboczego i przywróć ich połączenia.
4. Po przetestowaniu zadeklaruj działanie regionu pomocniczego. Użytkownicy logują się do już aktywnego wdrożenia, a Ty ponownie uruchamiasz zaplanowane lub opóźnione zadania.
Po rozwiązaniu problemu z regionem podstawowym potwierdź poprawkę.
Powrót po awarii (aby uzyskać szczegółowe informacje, zobacz Testowanie przywracania (powrót po awarii)):
1. Zatrzymaj wszystkie działania w regionie zapasowym.
2. Uruchom procedurę odzyskiwania w regionie podstawowym, aby przekierować routing z powrotem.
3. Replikuj wszystkie nowe dane z powrotem do regionu podstawowego. Zminimalizuj to, co należy replikować. Na przykład zadania tylko do odczytu uruchomione we wdrożeniu pomocniczym mogą nie wymagać zapisu zwrotnego.
4. Przetestuj wdrożenie w regionie podstawowym.
5. Zadeklaruj aktywny region podstawowy i wznawiaj obciążenia produkcyjne.

Ważne

Podczas tych kroków może wystąpić utrata danych. Zdefiniuj, ile strat jest akceptowalna dla organizacji i jak można ją wyeliminować.

Krok 1. Zrozumienie potrzeb biznesowych

Określ, które usługi związane z danymi mają krytyczne znaczenie, i zdefiniuj ich docelowe RPO i RTO. Zbadaj rzeczywistą tolerancję każdego systemu.

Odzyskiwanie po awarii, failover i failback wiążą się z realnymi kosztami i ryzykiem, w tym z uszkodzeniem danych, duplikacją danych (zapisywaniem w niewłaściwej lokalizacji pamięci masowej) oraz wprowadzaniem zmian przez użytkowników w niewłaściwym regionie.

Zamapuj każdy punkt integracji Azure Databricks, który ma wpływ na Twoją firmę, i wybierz narzędzia i kanały komunikacyjne używane przez plan.

Punkty integracji do mapowania

Czy rozwiązanie odzyskiwania po awarii musi obsługiwać interaktywne procesy, zautomatyzowane procesy lub oba te procesy?
Jakich usług danych używasz? Niektóre mogą być wdrożone lokalnie.
Jak dane trafiają do chmury?
Kto korzysta z tych danych? Jakie procesy zużywają go podrzędnie?
Czy istnieją integracje firm trzecich, które należy uwzględnić w związku ze zmianami DR?

Narzędzia i komunikacja do planowania

Czy można wstępnie zdefiniować konfigurację i uczynić ją modułową, tak aby w naturalny i łatwy w utrzymaniu sposób uwzględniała rozwiązania do odtwarzania po awarii?
Które narzędzia i kanały komunikacji powiadamiają zespoły wewnętrzne oraz podmioty zewnętrzne (integracje, odbiorców zależnych) o zmianach związanych z przełączeniem awaryjnym i powrotem po awarii w planie DR? Jak potwierdzić potwierdzenie?
Jakie usługi, jeśli w ogóle, zostaną wyłączone do czasu pełnego przywrócenia działania?

Krok 2. Wybieranie procesu spełniającego potrzeby biznesowe

Ustaw domyślnie zarządzane odzyskiwanie po awarii. Obsługuje replikację obszarów roboczych, metadane Unity Catalog, dane tabel zarządzanych oraz orkiestrację przełączania awaryjnego bez niestandardowych skryptów. Skorzystaj z poniższych wskazówek dotyczących samodzielnej konfiguracji tylko wtedy, gdy Twój przypadek użycia wykracza poza ich zakres, na przykład gdy chodzi o zasoby, których usługa zarządzanego odzyskiwania po awarii nie replikuje, topologie active-active, replikację między chmurami lub precyzyjną kontrolę nad potokiem replikacji.

Rozwiązanie DIY musi replikować poprawne dane na płaszczyźnie sterowania, płaszczyźnie obliczeniowej i źródłach danych. Nadmiarowe obszary robocze są mapowane na różne płaszczyzny sterowania w różnych regionach, dlatego utrzymuje się ich synchronizację za pomocą rozwiązania opartego na skryptach, albo narzędzia do synchronizacji, albo przepływu pracy CI/CD. W przypadku samych danych większość zespołów używa zadań Azure Databricks (często zaplanowanych) lub delta Deep Clone do kopiowania tabel między regionami. Nie musisz synchronizować danych z płaszczyzny obliczeniowej (na przykład z procesów roboczych środowiska Databricks Runtime).

Jeśli używasz funkcji iniekcji sieci wirtualnej (niedostępnej dla wszystkich subskrypcji i typów wdrożeń), wdrażaj sieci spójnie w obu regionach przy użyciu narzędzi opartych na szablonach, takich jak Terraform.

W razie potrzeby zreplikuj źródła danych w różnych regionach.

Rozwiązania odzyskiwania po awarii zazwyczaj obejmują dwa (lub więcej) środowiska robocze. Wybierz między następującymi strategiami na podstawie długości zakłóceń, które należy tolerować, nakład pracy operacyjnej i koszt powrotu po awarii do regionu podstawowego.

Ogólne najlepsze rozwiązania

Ogólne sprawdzone metody postępowania

Ogólne najlepsze praktyki dotyczące skutecznego planu odzyskiwania po awarii obejmują:

Określ, które procesy są krytyczne dla działalności firmy i muszą działać w ramach DR.
Jasno określ, które usługi są zaangażowane, które dane są przetwarzane, jaki jest przepływ danych i gdzie są przechowywane.
Izoluj usługi i dane jak najwięcej. Na przykład utwórz specjalny kontener w magazynie w chmurze dla danych na potrzeby odzyskiwania po awarii lub przenieś obiekty Azure Databricks potrzebne w razie awarii do oddzielnego obszaru roboczego.
Odpowiadasz za utrzymanie integralności między wdrożeniami podstawowymi i pomocniczymi obiektów, które nie są przechowywane na płaszczyźnie sterowania Azure Databricks.
W przypadku źródeł danych użyj natywnych narzędzi Azure do replikowania danych do regionów odzyskiwania po awarii tam, gdzie to możliwe.

Ostrzeżenie

Nie przechowuj danych w głównym magazynie ADLS (w obszarach roboczych utworzonych przed 6 marca 2023 r. — Azure Blob Storage) używanym do dostępu do katalogu głównego DBFS. Podstawowa pamięć DBFS nie nadaje się do przechowywania danych produkcyjnych klientów. Azure Databricks również odradza przechowywanie w tym miejscu bibliotek, plików konfiguracyjnych lub skryptów inicjalizacyjnych.

Strategia rozwiązania aktywne-pasywne

Ta sekcja koncentruje się na strategii aktywne-pasywne, ponieważ jest to najbardziej typowe, najprostsze i najbardziej ekonomiczne. Rozwiązanie aktywne-pasywne synchronizuje dane i zmiany w obiektach z aktywnego wdrożenia do pasywnego wdrożenia w regionie zapasowym. Podczas zdarzenia odzyskiwania po awarii pasywne wdrożenie staje się aktywne.

Dwa typowe warianty:

Ujednolicone (dla całego przedsiębiorstwa): jeden zestaw wdrożeń aktywnych i pasywnych obsługuje całą organizację.
Na poziomie działu lub projektu: Każdy obszar utrzymuje własne rozwiązanie do odtwarzania po awarii z regionem głównym i zapasowym dostosowanymi do swoich potrzeb.

Można również użyć wdrożenia pasywnego dla obciążeń tylko do odczytu, takich jak zapytania użytkowników, które nie modyfikują danych ani Azure Databricks obiektów.

Strategia rozwiązania aktywne-aktywne

W rozwiązaniu typu active-active wszystkie procesy przetwarzania danych działają równolegle w obu regionach przez cały czas. Zespół operacyjny musi oznaczyć każde zadanie jako ukończone dopiero po pomyślnym zakończeniu w obu regionach. Obiektów nie można zmieniać w środowisku produkcyjnym i muszą one podlegać ścisłemu procesowi promowania CI/CD ze środowiska deweloperskiego/testowego do środowiska produkcyjnego.

Strategia active-active jest najbardziej złożona i kosztowniejsza, ponieważ zadania działają w obu regionach, ale zapewnia najniższe wartości RTO i RPO.

Możesz wdrożyć active-active w całym przedsiębiorstwie lub na poziomie działów. Nie potrzebujesz zduplikowanego obszaru roboczego dla każdego obciążenia. Na przykład obszary robocze deweloperskie lub przejściowe są często łatwiejsze do odtworzenia z potoku programowania niż synchronizowania.

Wybieranie narzędzi

Istnieją dwa główne podejścia do synchronizowania danych między obszarami roboczymi w regionach podstawowych i pomocniczych:

Klient synchronizacji, który kopiuje z podstawowej do pomocniczej: klient synchronizacji wypycha dane produkcyjne i zasoby z regionu podstawowego do regionu pomocniczego. Zazwyczaj proces ten jest uruchamiany cyklicznie według harmonogramu, a częstotliwość jego wykonywania zależy od docelowych wartości RTO i RPO.
Narzędzia ciągłej integracji/ciągłego wdrażania do wdrażania równoległego: w przypadku kodu produkcyjnego i zasobów użyj narzędzi ciągłej integracji/ciągłego wdrażania, które wprowadzają zmiany do systemów produkcyjnych jednocześnie w obu regionach. Na przykład podczas wypychania kodu i zasobów z etapu przejściowego/rozwoju do środowiska produkcyjnego system CI/CD udostępnia je w obu regionach w tym samym czasie. Podstawowym pomysłem jest traktowanie wszystkich artefaktów w obszarze roboczym usługi Azure Databricks jako infrastruktury jako kodu. Większość artefaktów można wdrożyć zarówno w podstawowym, jak i zapasowym obszarze roboczym, podczas gdy niektóre artefakty mogą wymagać wdrożenia dopiero po wystąpieniu zdarzenia odzyskiwania po awarii. Aby zapoznać się z narzędziami, zobacz Skrypty automatyzacji, przykłady i prototypy.

W zależności od potrzeb można połączyć podejścia. Na przykład użyj CI/CD dla kodu źródłowego notesu, ale synchronizacji dla konfiguracji, takich jak pule i mechanizmy kontroli dostępu.

W poniższej tabeli opisano sposób obsługi poszczególnych typów danych przy użyciu każdej opcji narzędzi.

opis	Jak obsługiwać narzędzia ciągłej integracji/ciągłego wdrażania	Jak obsługiwać narzędzie do synchronizacji
Kod źródłowy: eksporty źródła notatnika i kod źródłowy dla spakowanych bibliotek	Wdrożyć jednocześnie zarówno w środowisku głównym, jak i pomocniczym.	Zsynchronizuj kod źródłowy z podstawowego na pomocniczy.
Użytkownicy i grupy	Zarządzaj metadanymi jako konfiguracją w usłudze Git. Alternatywnie użyj tego samego dostawcy tożsamości (IdP) dla obu obszarów roboczych. Wspólne wdrażanie danych użytkowników i grup do wdrożeń podstawowych i pomocniczych.	Użyj SCIM lub innej automatyzacji w obu regionach. Ręczne tworzenie jest niezalecane, ale jeśli to jest używane, należy je wykonać dla obu jednocześnie. Jeśli używasz konfiguracji ręcznej, utwórz zaplanowany proces zautomatyzowany, aby porównać listę użytkowników i grup między dwoma wdrożeniami.
Konfiguracje puli	Może to być szablony w usłudze Git. Współdzielone wdrożenie do podstawowego i pomocniczego systemu. Jednak `min_idle_instances` w systemie pomocniczym musi mieć wartość zero do momentu wystąpienia zdarzenia DR.	Zestawy utworzone z dowolnym `min_idle_instances` są synchronizowane z pomocniczym obszarem roboczym za pomocą interfejsu API lub interfejsu wiersza poleceń.
Konfiguracje zadań	Użyj Databricks Asset Bundles z celami wdrożenia dla poszczególnych środowisk (na przykład `prod` i `dr`), aby wdrożyć tę samą definicję zadania w obu regionach. W przypadku wdrożenia wtórnego ustaw poziom współbieżności na zero, aby zadanie zostało przygotowane do uruchomienia, ale nie zostało uruchomione. Zmień wartość współbieżności po tym, jak wdrożenie pomocnicze stanie się aktywne.	Jeśli z jakiegoś powodu zadania są uruchamiane w istniejących `<interactive>` klastrach, to klient synchronizacji musi odwzorować je na odpowiednie `cluster_id` w pomocniczym obszarze roboczym.
Listy kontroli dostępu (ACL)	Może to być szablony w usłudze Git. Jednoczesne wdrażanie do podstawowych i pomocniczych wdrożeń dla notesów, folderów i klastrów. Należy jednak przechowywać dane dotyczące zadań do czasu wystąpienia zdarzenia DR.	Interfejs API uprawnień może ustawiać mechanizmy kontroli dostępu dla klastrów, zadań, pul, notesów i folderów. Klient synchronizacji musi mapować odpowiednie identyfikatory obiektów dla każdego obiektu w pomocniczym obszarze roboczym. Usługa Databricks zaleca utworzenie mapy identyfikatorów obiektów z podstawowego do pomocniczego obszaru roboczego podczas synchronizowania tych obiektów przed replikowaniem kontrolek dostępu.
Biblioteki	Uwzględnij w kodzie źródłowym i szablonach klastra/zadań.	Zsynchronizuj biblioteki niestandardowe ze scentralizowanych repozytoriów, systemu plików DBFS lub magazynu w chmurze (można je instalować).
Skrypty inicjowania klastra	Jeśli wolisz, dołącz kod źródłowy.	Aby uzyskać prostszą synchronizację, przechowuj skrypty inicjowania w podstawowym obszarze roboczym we wspólnym folderze lub w małym zestawie folderów, jeśli to możliwe.
Punkty montowania	Uwzględnij kod źródłowy, jeśli jest tworzony tylko za pomocą zadań opartych na notesie lub interfejsu API poleceń.	Użyj zadań, które mogą być uruchamiane jako działania usługi Azure Data Factory (ADF). Należy pamiętać, że punkty końcowe magazynu mogą ulec zmianie, biorąc pod uwagę, że obszary robocze będą znajdować się w różnych regionach. To również w dużej mierze zależy od Twojej strategii odtwarzania danych po awarii.
Metadane tabeli	W przypadku obiektów Unity Catalog (katalogów, schematów, tabel, woluminów i uprawnień) należy wdrażać je razem z dostawcą Terraform Databricks lub Databricks Asset Bundles. W przypadku starszych tabel magazynu metadanych Hive dołącz instrukcje create-table z kodem źródłowym, jeśli zostały utworzone za pomocą zadań opartych na notesie lub interfejsu API poleceń.	W przypadku obiektów Unity Catalog odczytaj metadane źródłowe z tabel systemowych lub `information_schema`, a następnie zreplikuj je do pomocniczego obszaru roboczego przy użyciu Databricks SDK. W przypadku starszych tabel w metastore Hive porównaj definicje metadanych między metastore'ami przy użyciu interfejsu API katalogu Spark albo w notesie lub za pomocą `SHOW CREATE TABLE`skryptów. Podstawowe ścieżki magazynowania mogą zależeć od regionu i różnić się między instancjami magazynu metadanych.
Wpisy tajne	Uwzględnij w kodzie źródłowym, jeśli został utworzony tylko za pomocą Command API. Należy pamiętać, że niektóre wpisy tajne mogą wymagać zmiany między podstawową i pomocniczą.	Wpisy tajne są tworzone w obu obszarach roboczych za pośrednictwem interfejsu API. Należy pamiętać, że niektóre wpisy tajne mogą wymagać zmiany między podstawową i pomocniczą.
Konfiguracje klastrów	Może to być szablony w usłudze Git. Wdróż równolegle w środowisku podstawowym i zapasowym, chociaż wdrożenia w środowisku zapasowym powinny pozostać wyłączone do czasu wystąpienia zdarzenia DR.	Klastry są tworzone po zsynchronizowaniu z pomocniczym obszarem roboczym przy użyciu interfejsu API lub interfejsu wiersza polecenia. Można je jawnie zakończyć, jeśli chcesz, w zależności od ustawień automatycznego kończenia.
Uprawnienia notesu, pracy i folderu	Może to być szablony w usłudze Git. Wdrażaj jednocześnie do środowisk podstawowych i pomocniczych.	Replikuj przy użyciu API uprawnień.

Wybierz regiony i wiele dodatkowych obszarów roboczych

Wybieranie regionów i wielu pomocniczych obszarów roboczych

Kontrolujesz wyzwalacze odzyskiwania po awarii i region pomocniczy, do którego należy przejść w tryb failover. Odpowiadasz również za ustabilizowanie środowiska odzyskiwania po awarii przed wznowieniem normalnych operacji. Zazwyczaj oznacza to utworzenie wielu obszarów roboczych usługi Azure Databricks na potrzeby środowiska produkcyjnego i odtwarzania po awarii, a następnie wybranie pomocniczego regionu przełączenia awaryjnego.

Przed wybraniem regionu pomocniczego upewnij się, że wszystkie zasoby i usługi, od których zależy (typy obliczeniowe, produkty, integracje) są dostępne. Niektóre usługi Azure Databricks są dostępne tylko w określonych regionach.

Sprawdź również dostępność replikacji danych i typu maszyny wirtualnej.

Krok 3. Przygotowywanie obszarów roboczych i wykonanie jednorazowej kopii

Najpierw utwórz zapasowy obszar roboczy Azure Databricks (lub zapasowe obszary robocze) oraz obsługujący go magazyn metadanych w wybranym regionie zapasowym. Pomocniczy obszar roboczy musi odzwierciedlać konto, region i konfigurację tożsamości podstawowego obszaru roboczego, zanim będzie można replikować do niego dane lub zasoby.

Jeśli używasz zarządzanego odzyskiwania po awarii, usługa Azure Databricks przeprowadza początkową konfigurację katalogów objętych zakresem i zasobów obszaru roboczego podczas tworzenia grupy przełączenia awaryjnego. Nie musisz uruchamiać jednorazowej kopii dla tych zasobów. Przejdź do dalszej części tej sekcji w przypadku wszelkich źródeł danych lub zasobów, których zarządzane odzyskiwanie po awarii nie replikuje.

W przypadku produkcyjnego obszaru roboczego działającego poza zakresem zarządzanego odzyskiwania po awarii uruchom jednorazowe kopiowanie, aby zsynchronizować wdrożenie pasywne z wdrożeniem aktywnym. Ta kopia obsługuje:

Replikacja danych: użyj rozwiązania replikacji w chmurze lub funkcji Delta Deep Clone.
Generowanie tokenów: automatyzowanie replikacji i przyszłych obciążeń przy użyciu wygenerowanych tokenów.
Replikacja obszaru roboczego: Replikuj przy użyciu metod w kroku 4: Przygotowywanie źródeł danych. Aby uzyskać kompleksowe wskazówki dotyczące eksportowania konfiguracji, danych i zasobów sztucznej inteligencji/uczenia maszynowego, zobacz Eksportowanie danych obszaru roboczego.
Walidacja obszaru roboczego: przetestuj obszar roboczy i proces, aby potwierdzić pomyślne wykonanie i wygenerować oczekiwane wyniki.

Kolejne synchronizacje działają szybciej niż kopia początkowa, a dzienniki narzędzi rejestrują, co się zmieniło i kiedy.

Krok 4. Przygotowanie źródeł danych

Usługa Azure Databricks może przetwarzać wiele różnych źródeł danych przy użyciu przetwarzania wsadowego lub strumieni danych.

Przetwarzanie wsadowe ze źródeł danych

Dane wsadowe zwykle są przechowywane w źródle, które można replikować lub przenieść do innego regionu.

Na przykład dane często są przekazywane do magazynu w chmurze zgodnie z harmonogramem. W trybie odzyskiwania po awarii kieruj te przesyłane dane do magazynu w regionie pomocniczym i zaktualizuj obciążenia robocze tak, aby odczytywały dane z tego magazynu i zapisywały je w nim.

Strumienie danych

Przetwarzanie strumienia danych jest większym wyzwaniem. Dane przesyłane strumieniowo mogą być pozyskiwane z różnych źródeł, przetwarzanych i wysyłanych do rozwiązania do przesyłania strumieniowego:

Kolejka komunikatów, taka jak Kafka
Strumień przechwytywania zmian w bazie danych
Przetwarzanie ciągłe oparte na plikach
Zaplanowane przetwarzanie oparte na plikach, nazwane także jednorazowym wyzwalaczem

We wszystkich tych przypadkach należy skonfigurować źródła danych tak, aby obsługiwały tryb DR oraz korzystały z wdrożenia pomocniczego w swoim regionie pomocniczym.

Składnik zapisujący do strumienia przechowuje punkt kontrolny z informacjami o przetworzonych danych. Ten punkt kontrolny może zawierać lokalizację danych (zazwyczaj magazyn w chmurze), która musi zostać zmodyfikowana w nowej lokalizacji, aby zapewnić pomyślne ponowne uruchomienie strumienia. Na przykład source podfolder w punkcie kontrolnym może przechowywać folder w chmurze oparty na plikach.

Ten punkt kontrolny musi być replikowany w odpowiednim czasie. Rozważ synchronizację interwału punktu kontrolnego z dowolnym nowym rozwiązaniem replikacji w chmurze.

Aktualizacja punktu kontrolnego jest funkcją modułu zapisującego i dlatego ma zastosowanie do pozyskiwania lub przetwarzania przepływu danych oraz przechowywania ich w innym źródle strumieniowym.

W przypadku obciążeń przesyłania strumieniowego upewnij się, że punkty kontrolne są skonfigurowane w magazynie zarządzanym przez klienta, aby można je było replikować do regionu pomocniczego w celu wznowienia obciążenia od momentu ostatniej awarii. Możesz również uruchomić pomocniczy proces przesyłania strumieniowego równolegle do procesu podstawowego.

Krok 5. Implementowanie i testowanie rozwiązania

Jeśli używasz zarządzanego odtwarzania po awarii, możesz uruchomić planowane przełączenie awaryjne z poziomu konsoli konta, aby zweryfikować, że konfiguracja działa od początku do końca. Ta sama procedura obejmuje zarówno testy odzyskiwania po awarii, jak i rzeczywiste awarie. Zobacz Przełączanie awaryjne i powrót po przełączeniu awaryjnym.

Regularnie testuj konfigurację odzyskiwania po awarii. Nietestowany plan odtwarzania po awarii często zawodzi, kiedy jest potrzebny. Niektóre zespoły zgodnie z harmonogramem przełączają aktywne regiony co kilka miesięcy, aby weryfikować założenia, przećwiczyć procedury i dbać o to, by zespół dobrze znał runbook.

Ważne

Przetestuj rozwiązanie odzyskiwania po awarii w warunkach rzeczywistych zgodnie z harmonogramem.

Jeśli test ujawni brakujący obiekt lub szablon, zaktualizuj plan: usuń zależność, zreplikuj ją do pomocniczego obszaru roboczego lub udostępnij w inny sposób.

Przetestuj zmiany organizacyjne i konfiguracyjne. Plan odzyskiwania po awarii wpływa na potok wdrażania, więc zespół musi wiedzieć, co należy zachować w synchronizacji. Po skonfigurowaniu obszarów roboczych odzyskiwania po awarii upewnij się, że infrastruktura, zadania, notesy, biblioteki i inne obiekty obszaru roboczego są dostępne w regionie pomocniczym.

Rozszerz standardowe procesy pracy i potoki konfiguracyjne, tak aby wdrażać zmiany we wszystkich przestrzeniach roboczych. Zarządzanie tożsamościami użytkowników w obszarach roboczych oraz konfigurowanie automatyzacji zadań i monitorowania dla nowych obszarów roboczych.

Zaplanuj i przetestuj zmiany w narzędziu konfiguracji.

Zmiany konfiguracji dotyczące planowania i testowania

Dla każdego z następujących elementów przygotuj plan przejścia w tryb failover i przetestuj wszystkie założenia:

Pozyskiwanie: dowiedz się, gdzie znajdują się źródła danych i gdzie te źródła pobierają swoje dane. Jeśli to możliwe, sparametryzuj źródło i użyj oddzielnego szablonu konfiguracji dla wdrożenia pomocniczego i regionu.
Zmiany wykonywania: jeśli masz harmonogram do wyzwalania zadań lub innych akcji, może być potrzebny oddzielny harmonogram, który współpracuje z wdrożeniem pomocniczym lub jego źródłami danych.
Łączność interaktywna: rozważ, jak konfiguracja, uwierzytelnianie i połączenia sieciowe mogą mieć wpływ na regionalne zakłócenia w przypadku dowolnego użycia interfejsów API REST, narzędzi interfejsu wiersza polecenia lub innych usług, takich jak JDBC/ODBC.
Zmiany automatyzacji: dla wszystkich narzędzi automatyzacji.
Dane wyjściowe: w przypadku wszystkich narzędzi generujących dane wyjściowe lub dzienniki.
Zmiany podrzędne: w przypadku narzędzi analizy biznesowej, pulpitów nawigacyjnych, harmonogramów i integracji innych firm, które odczytują lub zapisują do Azure Databricks, zaplanuj sposób ponownego ustawiania ich w pomocniczym obszarze roboczym i powiadamiania ich właścicieli.

Testowanie pracy w trybie failover

Wiele scenariuszy może uruchamiać DR: nieoczekiwana awaria sieci chmurowej, pamięci masowej w chmurze lub innej kluczowej usługi, gdy nie można przeprowadzić bezpiecznego zamknięcia; planowane zamknięcie lub awaria; a nawet okresowe przełączanie między regionami w ramach cyklu testowego.

Aby przetestować tryb failover, połącz się z systemem i uruchom zamknięcie. Upewnij się, że wszystkie zadania zostały ukończone, a klastry zakończą działanie.

Klient synchronizacji (lub narzędzia CI/CD) kopiuje odpowiednie obiekty i zasoby Azure Databricks do pomocniczego obszaru roboczego. Aby aktywować pomocniczy obszar roboczy, proces może obejmować niektóre lub wszystkie następujące elementy:

Uruchom testy, aby potwierdzić, że platforma jest aktualna.
Wyłącz pule i klastry w regionie podstawowym, aby w przypadku powrotu usługi, która zakończyła się niepowodzeniem, region podstawowy nie rozpoczyna przetwarzania nowych danych.
Uruchom proces odzyskiwania dla źródeł danych (zobacz poniżej).
Uruchom odpowiednie pule (lub zwiększ min_idle_instances do odpowiedniej liczby).
Uruchom odpowiednie klastry (jeśli nie zostaną zakończone).
Zmień równoczesne uruchamianie zadań i uruchom właściwe zadania. Mogą to być jednorazowe uruchomienia lub okresowe uruchomienia.
W przypadku dowolnego zewnętrznego narzędzia korzystającego z adresu URL lub nazwy domeny dla obszaru roboczego usługi Azure Databricks zaktualizuj konfiguracje, aby uwzględnić nową płaszczyznę sterowania. Na przykład zaktualizuj adresy URL dla interfejsów API REST i połączeń JDBC/ODBC. Adres URL aplikacji internetowej usługi Azure Databricks zmienia się po zmianie płaszczyzny sterowania, dlatego powiadamiaj użytkowników organizacji o nowym adresie URL.

Szczegóły procesu odzyskiwania

Sprawdź datę najnowszych zsynchronizowanych danych. Zobacz Terminologia branżowa odzyskiwania po awarii. Szczegóły tego kroku różnią się w zależności od sposobu synchronizowania danych i unikatowych potrzeb biznesowych.
Stabilizuj źródła danych i upewnij się, że są one dostępne. Uwzględnij wszystkie zewnętrzne źródła danych, takie jak Azure Cloud SQL, oraz swoje pliki Delta Lake, Parquet lub inne.
Znajdź punkt przywracania streamingu. Skonfiguruj proces ponownego uruchomienia z tego miejsca i przygotuj proces do identyfikowania i eliminowania potencjalnych duplikatów (usługa Delta Lake ułatwia to).
Ukończ proces przepływu danych i poinformuj użytkowników.

Przywracanie testowe (powrót po awarii)

Testowanie przywracania (powrót po awarii)

Powrót po awarii jest łatwiejszy do kontrolowania i można go wykonać w oknie obsługi. Zaplanuj niektóre lub wszystkie następujące kroki:

Uzyskaj potwierdzenie przywrócenia regionu podstawowego.
Wyłącz pule i klastry w regionie pomocniczym, aby nie rozpoczynało przetwarzania nowych danych.
Zsynchronizuj wszystkie nowe lub zmodyfikowane zasoby w pomocniczym obszarze roboczym z powrotem do wdrożenia podstawowego. W zależności od projektu skryptów trybu failover może być możliwe uruchomienie tych samych skryptów w celu zsynchronizowania obiektów z regionu pomocniczego (DR) z regionem podstawowym (produkcyjnym).
Zsynchronizuj wszystkie nowe aktualizacje danych z powrotem do wdrożenia podstawowego. Możesz użyć śladów audytu i tabel delty, aby zagwarantować brak utraty danych.
Wyłącz wszystkie obciążenia robocze w regionie DR.
Zmień adres URL zadań i użytkowników na region podstawowy, a następnie przekierzykuj połączenia podrzędne (narzędzia analizy biznesowej, harmonogramy, integracje innych firm) z powrotem do niego.
Uruchom testy, aby potwierdzić, że platforma jest aktualna.
Uruchom odpowiednie pule (lub zwiększ min_idle_instances do odpowiedniej liczby).
Uruchom odpowiednie klastry (jeśli nie zostaną zakończone).
Zmień równoczesne uruchamianie dla zadań i uruchom odpowiednie zadania. Mogą to być jednorazowe uruchomienia lub okresowe uruchomienia.
W razie potrzeby skonfiguruj ponownie region pomocniczy na potrzeby przyszłego odzyskiwania po awarii.

Skrypty automatyzacji, przykłady i prototypy

W przypadku usług AWS i Azure zarządzane odzyskiwanie po awarii obsługuje replikację obszaru roboczego i zarządzanej tabeli bez niestandardowej automatyzacji. Poniższe materiały referencyjne mają zastosowanie tylko wtedy, gdy tworzysz rozwiązanie DIY poza zakresem usługi zarządzanego odzyskiwania po awarii.

W przypadku potoków DIY DR użyj dostawcy Databricks dla narzędzia Terraform, aby zarządzać zasobami obszaru roboczego w formie kodu i wdrażać je równolegle w regionach głównym i zapasowym.

Jeśli koordynujesz usługę Azure Databricks z poziomu Azure Data Factory, zreplikuj odpowiednie potoki ADF, aby odwoływały się do usługi połączonej powiązanej z pomocniczym obszarem roboczym.

Dodatkowe zasoby

Opinia

Czy ta strona była pomocna?

Last updated on 2026-09-11