Zarządzane odzyskiwanie po awarii

Ważne

Ta funkcja jest dostępna w publicznej wersji testowej.

Zarządzane odzyskiwanie po awarii (DR) replikuje wdrożenie Azure Databricks do regionu zapasowego, dzięki czemu można przywrócić działanie po awarii regionalnej w ciągu kilku minut. Azure Databricks zarządza potokiem replikacji, stanem replikowanych katalogów w środowisku pomocniczym oraz procesem przełączania awaryjnego. Skrypty replikacji nie są zapisywane ani obsługiwane.

Aby zapoznać się z ręcznym podejściem do odzyskiwania po awarii, w tym ogólnymi pojęciami odzyskiwania po awarii i najlepszymi rozwiązaniami, zobacz Odzyskiwanie po awarii.

Ważne

Zarządzane odzyskiwanie po awarii jest objęte ograniczeniem dostępu. Złóż wniosek o dostęp za pośrednictwem zespołu obsługującego Twoje konto Azure Databricks. Azure Databricks umożliwia zarządzane odzyskiwanie po awarii dla Twojego konta po zaakceptowaniu Twojego zgłoszenia.

Co to jest zarządzane odzyskiwanie po awarii?

Zarządzane odzyskiwanie po awarii bazuje na przestrzeniach roboczych i magazynach metadanych, którymi już zarządzasz. Masz dwa obszary robocze usługi Azure Databricks, jeden w regionie podstawowym i jeden w regionie pomocniczym, oraz magazyn metadanych w każdym z regionów. Następnie: zarządzane odzyskiwanie po awarii:

  • Replikuje kategorie, do których decydujesz się z podstawowego do pomocniczego zgodnie z harmonogramem ciągłym. Obie kategorie są niezależnie opcjonalne: metadane Unity Catalog i dane tabel zarządzanych oraz zasoby obszaru roboczego, takie jak notatniki, zadania, magazyny SQL, klastry i listy ACL.
  • Udostępnia opcjonalny stabilny adres URL — pojedynczy ciąg połączenia, który zawsze wskazuje bieżący węzeł podstawowy, dzięki czemu klienci nadal działają po przełączeniu awaryjnym bez konieczności ponownej konfiguracji.
  • Umożliwia uruchomienie przełączenia awaryjnego wtedy, gdy tego chcesz — na potrzeby testu odzyskiwania po awarii lub rzeczywistej awarii.

Identyfikatory zasobów obszaru roboczego są zachowywane we wszystkich regionach, więc adresy URL, które odwołują się do zasobu obszaru roboczego za pomocą identyfikatora, nadal działają po przełączeniu awaryjnym.

Co jest replikowane

Zarządzane odzyskiwanie po awarii może replikować następujące elementy w każdym cyklu replikacji. Obie kategorie są opcjonalne, więc można włączyć jedną lub obie kategorie:

  • Metadane i dane Unity Catalog: tabele zarządzane w Unity Catalog w Delta Lake wraz z danymi, tabele zewnętrzne i woluminy (tylko metadane), widoki, funkcje oraz wszystkie przyznane uprawnienia. Tryb izolacji katalogu jest replikowany. Jeśli katalog źródłowy jest otwarty, replika jest otwarta. Jeśli źródło jest izolowane i powiązane z podstawowym obszarem roboczym, replika jest izolowana i powiązana z pomocniczym obszarem roboczym.
  • Zasoby obszaru roboczego: notesy, zadania, magazyny SQL, klastry, wersje robocze pulpitów nawigacyjnych sztucznej inteligencji/analizy biznesowej, pliki i foldery wraz z listami ACL. Magazyny SQL są replikowane w STOPPED stanie, klastry w TERMINATED stanie. Harmonogramy zadań w pomocniczym są wstrzymane.

Nic, czego nie ma na liście w poprzedniej sekcji, nie jest replikowane. Zobacz Ograniczenia, aby poznać szczegóły.

Requirements

  • Dodatek Obszar roboczy o znaczeniu krytycznym jest włączony w obu obszarach roboczych. Zobacz Włączanie funkcji Mission Critical w obu obszarach roboczych.
  • Bezserwerowe obliczenia włączone w obu obszarach roboczych. Bezserwerowe zasoby obliczeniowe są domyślnie dostępne w większości obszarów roboczych z włączonym Unity Catalog. Zobacz Połącz się z bezserwerową chmurą obliczeniową.
  • Rola administratora konta z wszystkimi UPRAWNIENIAmi w każdej lokalizacji zewnętrznej używanej przez katalogi, które mają być replikowane.
  • SSO na poziomie konta z włączonymi wszystkimi obszarami roboczymi oraz z tożsamościami synchronizowanymi z kontem za pośrednictwem SCIM, tak aby użytkownicy, grupy i jednostki główne usługi istniały w obu regionach.
  • Dla stabilnych adresów URL: niestandardowy adres URL udostępniony dla domeny Azure Databricks (skontaktuj się z opiekunem konta) oraz uwierzytelnianie OAuth na poziomie konta.
  • Zapasowy obszar roboczy i metastore usługi Unity Catalog w regionie zapasowym, na tym samym koncie Azure Databricks i w tej samej chmurze co podstawowy obszar roboczy. Pomocniczy obszar roboczy musi być zgodny z siecią podstawową, Private Link i konfiguracją klucza zarządzanego przez klienta. Pomocniczy magazyn metadanych nie może zawierać wykazów, które współużytkują nazwy z replikowanymi wykazami. W przypadku replikacji zasobów obszaru roboczego usługa Azure Databricks usuwa po zakończeniu replikacji początkowej wszystkie istniejące zasoby objęte zakresem replikacji w pomocniczym obszarze roboczym. Nie ma to wpływu na zasoby poza zakresem, więc pomocniczy obszar roboczy nie musi być pusty.
  • Odpowiadająca lokalizacja zewnętrzna i poświadczenie magazynu danych w regionie pomocniczym dla każdego elementu, do którego odwołują się katalogi podstawowe. Zarządzane odzyskiwanie awaryjne nie replikuje automatycznie lokalizacji zewnętrznych ani poświadczeń dostępu do magazynu; należy je utworzyć w środowisku pomocniczym.
  • Łącznik dostępu usługi Azure Databricks w regionie pomocniczym, z rolą Współautor danych obiektów blob usługi Storage na pomocniczych kontach magazynu, dodany jako poświadczenie magazynu w pomocniczym obszarze roboczym.
  • Konfiguracja łączności sieciowej (NCC) w regionie pomocniczym przypisana do pomocniczego obszaru roboczego.
  • Zatwierdzone prywatne punkty końcowe dla każdego źródłowego i pomocniczego konta magazynu, do których odwołuje się replikowane wykazy.

Włączanie funkcji Mission Critical w obu obszarach roboczych

Przed utworzeniem grupy pracy awaryjnej włącz dodatek Mission Critical w obu przestrzeniach roboczych — podstawowej i pomocniczej. Użycie zasobów obliczeniowych w każdym obszarze roboczym, w którym włączono dodatek, jest rozliczane według współczynnika misji krytycznej. Skontaktuj się z zespołem ds. kont Azure Databricks, aby uzyskać bieżącą stawkę.

  1. W konsoli konta kliknij pozycję Obszary robocze, a następnie kliknij obszar roboczy.
  2. Kliknij kartę Dodatki .
  3. Na karcie Mission Critical włącz przełącznik i potwierdź.

Powtórz w przypadku pomocniczego obszaru roboczego.

Konfigurowanie replikacji

Nowa grupa przełączania awaryjnego przechodzi kolejno przez CREATING → INITIAL_REPLICATION → ACTIVE. Pierwszy cykl replikacji kopiuje wszystkie dane objęte zakresem replikacji do lokalizacji pomocniczej. W przypadku dużych obszarów roboczych początkowa inicjalizacja zasobów obszaru roboczego może potrwać do dwóch tygodni. To oczekiwanie jest jednorazowe. Po zakończeniu początkowego ładowania replikacja działa nieprzerwanie.

Podczas replikacji wtórne katalogi objęte zakresem są dostępne tylko do odczytu, a moc obliczeniowa jest niedostępna w wtórnym obszarze roboczym. Aby uruchamiać zapytania sprawdzania poprawności bez zapisywania w pomocniczej wersji, Azure Databricks zaleca oddzielny obszar roboczy monitora tylko do odczytu w regionie pomocniczym.

Aby utworzyć grupę przełączania awaryjnego:

  1. W konsoli konta kliknij pozycję Odporność.
  2. Jeśli planujesz użyć stabilnego adresu URL, kliknij kartę Stabilne adresy URL, a następnie utwórz stabilny adres URL. Wprowadź nazwę, wybierz bieżący podstawowy obszar roboczy i utwórz stabilny adres URL. Skieruj klientów podrzędnych (JDBC, ODBC, internetowy interfejs użytkownika Azure Databricks, bezpośrednie żądania API) na stabilny adres URL zamiast oryginalnego adresu URL obszaru roboczego.
  3. Kliknij kartę Grupy trybu failover, a następnie Utwórz grupę trybu failover.
  4. Wypełnij formularz:
    • Nazwa grupy przełączania awaryjnego: nazwa wybrana dla grupy przełączania awaryjnego.
    • Podstawowy obszar roboczy: obszar roboczy, który jest Twoim podstawowym obszarem roboczym.
    • Obszar roboczy pomocniczy: Obszar roboczy w regionie pomocniczym.
    • Replikowanie zasobów obszaru roboczego (opcjonalnie): domyślnie wyłączone. Włącz replikację notesów, zadań, magazynów SQL, klastrów, pulpitów nawigacyjnych, plików i folderów (oraz ich list ACL) z podstawowej do pomocniczej. Wymaga włączenia dodatku Mission Critical dla obu obszarów roboczych. Jeśli włączysz replikację zasobów obszaru roboczego, Azure Databricks usunie wszystkie istniejące zasoby w zakresie pomocniczym po zakończeniu replikacji początkowej. Nie ma to wpływu na zasoby poza zakresem.
    • Stabilny adres URL (opcjonalnie): stabilny adres URL utworzony w kroku 2.
    • Zakres replikacji: Katalogi do replikacji. Aby to pole było dostępne, musisz wybrać podstawowy obszar roboczy.
    • Mapowania pamięci masowej: Dla każdej lokalizacji zewnętrznej używanej przez replikowane katalogi w regionie podstawowym dodaj wpis, który mapuje jej ścieżkę pamięci masowej na odpowiadającą jej lokalizację zewnętrzną utworzoną w regionie wtórnym (zobacz Wymagania). Można użyć * jako symbolu wieloznacznego do dopasowania prefiksów.
  5. Kliknij pozycję Utwórz grupę przełączania awaryjnego.

Na przykład mapowanie usługi Azure Storage może przypisywać abfss://data@primary.dfs.core.windows.net/* do abfss://data@secondary.dfs.core.windows.net/*.

Zasoby tworzone przez zarządzane odzyskiwanie po awarii

Podczas tworzenia grupy przełączania awaryjnego funkcja zarządzanego odzyskiwania po awarii (DR) tworzy pomocnicze zasoby Unity Catalog, których potok replikacji używa do kopiowania danych między regionami. Zarówno w głównych, jak i pomocniczych repozytoriach metadanych zarządzane odzyskiwanie po awarii (DR) tworzy:

  • Połączenie wskazujące obszar roboczy w innym regionie.
  • Wykaz obcy dla każdego zreplikowanego wykazu. Wykaz obcy odwołuje się do odpowiedniego wykazu w innym regionie.

Te zasoby są wyświetlane obok własnych katalogów w Eksploratorze wykazu. Można je zidentyfikować po komentarzu, w którym zaznaczono, że są tworzone i zarządzane przez funkcję odzyskiwania po awarii w usłudze Azure Databricks.

Ważne

Domyślnie tylko administrator magazynu metadanych może modyfikować lub usuwać te zasoby. Nie usuwaj połączeń ani katalogów obcych utworzonych przez usługę Managed DR. Usunięcie którejkolwiek z nich powoduje przerwanie replikacji w grupie failover.

Własność replikowanych zasobów

Gdy zarządzane odzyskiwanie po awarii tworzy replikowany obiekt zabezpieczany (katalog, schemat, tabelę, widok, funkcję lub wolumin) w lokalizacji pomocniczej, początkowym właścicielem jest jednostka usługi Azure Databricks uruchamiająca replikację, ponieważ Unity Catalog przypisuje własność tożsamości, która tworzy obiekt. Następnie funkcja Managed DR przenosi własność repliki, tak aby odpowiadała ona właścicielowi odpowiadającego jej zabezpieczalnego obiektu w podstawowej bazie danych.

Jeśli właścicielem obiektu zabezpieczalnego w podstawowej bazie danych jest użytkownik, który został usunięty z konta, zarządzane odzyskiwanie po awarii nie może przenieść własności na podmiot zabezpieczeń, który już nie istnieje. W takim przypadku zabezpieczalny obiekt repliki zachowuje jednostkę usługi Azure Databricks jako właściciela. Aby rozwiązać ten problem, przypisz prawidłowego właściciela do zabezpieczanego obiektu w bazie podstawowej. Zarządzane odzyskiwanie po awarii replikuje zaktualizowanego właściciela do repliki w oknie RPO.

Użyj stabilnego adresu URL

Stabilny adres URL zawsze wskazuje na aktualny podstawowy obszar roboczy, więc klienci łączący się za jego pośrednictwem nie wymagają ponownej konfiguracji po przełączeniu awaryjnym. Skieruj następujących klientów podrzędnych na stabilny adres URL zamiast oryginalnego adresu URL obszaru roboczego:

  • Internetowy interfejs użytkownika Azure Databricks.
  • Połączenia JDBC i ODBC z magazynami SQL.
  • Bezpośrednie żądania interfejsu API REST.

Stabilne adresy URL są obsługiwane przez przychodzące łącze prywatne frontonu (Private Link), ale format adresu URL różni się od standardowego formatu.

Oryginalny adres URL obszaru roboczego nadal działa, ale nie przetrwa przejścia w tryb failover. Azure Databricks zaleca migrowanie klientów do stabilnego adresu URL.

Monitorowanie replikacji

Na karcie Grupy pracy awaryjnej są wyświetlane bieżący stan każdej grupy pracy awaryjnej, punkt replikacji oraz wszelkie aktywne błędy. Możliwe stany:

State Meaning
CREATING Grupa trybu failover jest aprowizowana.
INITIAL_REPLICATION Pierwszy cykl replikacji jest w toku. Tryb failover nie jest jeszcze dostępny.
ACTIVE Replikacja jest w stanie stabilnym. Tryb failover jest dostępny.
FAILING_OVER Trwa przełączanie awaryjne.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED Operacja nie została ukończona. Sprawdź szczegóły stanu grupy przełączania awaryjnego, aby uzyskać wskazówki.

Wybierz nazwę grupy trybu failover, aby otworzyć jej stronę szczegółów. Punkt replikacji pokazuje, kiedy wszystkie zasoby w zakresie zostały ostatnio skopiowane. Dane zapisane po punkcie replikacji mogą nie istnieć w pomocniczej bazie danych i mogą zostać utracone podczas pracy w trybie failover.

Aby uzyskać historyczne trendy RPO i błędy replikacji dla poszczególnych zasobów, wykonaj zapytanie względem tabeli systemowej system.replication.states. Zobacz informacje referencyjne dotyczące tabeli systemowej replikacji.

Przechodzenie w tryb failover i powrót po awarii

Ta sama procedura obejmuje planowane przełączenia awaryjne (testy odzyskiwania po awarii, zaplanowana konserwacja) oraz nieplanowane przełączenia awaryjne (awaria w regionie). Aby powrócić po awarii, powtórz procedurę z odwróconymi regionami.

Po zainicjowaniu przełączenia awaryjnego platforma Azure Databricks:

  • Wskazuje stabilny adres URL, jeśli jest dołączony, do nowego regionu podstawowego.
  • Odwraca kierunek replikacji.
  • Wstrzymuje harmonogramy zadań w poprzednim podstawowym.
  • Przełącza grupę trybu failover z FAILING_OVER do INITIAL_REPLICATION.

Aby przełączyć się na system zapasowy:

  1. Powiadom zespół, że rozpoczyna się przełączenie awaryjne.

  2. Tylko w przypadku planowanego przejścia w tryb failover:

    1. W podstawowym obszarze roboczym zakończ wszystkie uruchomione klastry i zatrzymaj wszystkie magazyny SQL.
    2. Potwierdź, że zapisy do węzła podstawowego zostały wstrzymane, a następnie poczekaj, aż replikacja nadrobi opóźnienie. Aby to sprawdzić, otwórz stronę szczegółów grupy przełączania awaryjnego i upewnij się, że punkt replikacji różni się od chwili zatrzymania zapisów o najwyżej kilka sekund.

  3. W konsoli konta kliknij pozycję Odporność → Grupy przełączania awaryjnego, a następnie kliknij nazwę grupy przełączania awaryjnego.

  4. Kliknij Fail over.

  5. Wybierz nowy region podstawowy i potwierdź. Przejście w tryb failover zakończy się w ciągu kilku minut.

  6. Na nowym węźle podstawowym uruchom zasób obliczeniowy, który działał przed przełączeniem awaryjnym. Zreplikowane klastry i magazyny SQL pojawiają się w nowym środowisku podstawowym odpowiednio w stanie TERMINATED i STOPPED.

  7. Ręcznie wznów potrzebne harmonogramy zadań na nowym serwerze podstawowym. Harmonogramy byłego podstawowego są już wstrzymane.

Klienci połączeni za pośrednictwem stabilnego adresu URL kontynuują pracę po przejściu w tryb failover. Przekieruj klientów, którzy nadal używają oryginalnego adresu URL obszaru roboczego, tak aby korzystali ze stabilnego adresu URL lub adresu URL obszaru roboczego nowego podstawowego obszaru roboczego.

Ważne

Podczas nieplanowanego przełączenia awaryjnego dane zapisane w systemie podstawowym po ostatnim punkcie replikacji mogą zostać utracone. Upewnij się, że ewentualna utrata danych nie przekracza docelowej wartości RPO.

Tip

Regularnie testuj tryb failover, na przykład raz na kwartał, aby twój zespół zapoznał się z procedurą przed rzeczywistą awarią.

Typowe błędy replikacji

Możesz monitorować stan grup przełączania awaryjnego w tabeli systemowej system.replication.states. Tabela zawiera podsumowanie bieżących błędów dla grupy trybu failover. W poniższej tabeli wymieniono najczęściej występujące błędy, zaczynając od tych występujących najczęściej:

Klasa błędu Resolution
DR_INTERNAL_ERROR Błąd przejściowy lub po stronie systemu. System ponawia próbę automatycznie. Skontaktuj się z pomocą techniczną Azure Databricks, jeśli problem nie zostanie rozwiązany automatycznie.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION Zewnętrzna lokalizacja, w której znajduje się zasób, nie jest zarejestrowana w pomocniczym magazynie metadanych. Utwórz brakującą lokalizację zewnętrzną w regionie pomocniczym lub zaktualizuj mapowania magazynu grupy pracy awaryjnej tak, aby obejmowały tę ścieżkę.
DR_MISSING_DEPENDENCY.TABLE Zasób, zazwyczaj widok, odwołuje się do tabeli, która nie jest częścią grupy trybu failover. Dodaj tabelę do grupy trybu failover lub usuń zależny zasób.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING Schemat lub jego lokalizacja zarządzana nie ma mapowania magazynu między regionami podstawowymi i pomocniczymi. Dodaj mapowanie magazynu danych dla schematu do grupy pracy awaryjnej.
DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION Właściciel widoku nie ma uprawnień do obiektów międzykatalogowych, od których zależy ten widok, więc nie można go utworzyć w systemie pomocniczym. Sprawdź, czy wymagane dotacje istnieją w pomocniczej wersji, i w razie potrzeby przyznaj je ręcznie.

Zburzyć zarządzane odzyskiwanie po awarii

  1. W konsoli konta kliknij pozycję Odporność → Grupy trybu failover, a następnie kliknij nazwę grupy trybu failover i usuń ją. Nie można wyłączyć funkcji Mission Critical, gdy grupa trybu failover jest aktywna w obszarze roboczym.
  2. Aby zatrzymać naliczanie opłat według stawki Mission Critical, wyłącz Mission Critical na karcie Dodatki w każdym obszarze roboczym.

Limitations

Zarządzane odtwarzanie po awarii ma następujące ograniczenia:

  • Nie podlegają replikacji: widoki zmaterializowane, tabele strumieniowe, Lakeflow Spark Declarative Pipelines, dane zarządzanych woluminów (metadane są replikowane), secrety Unity Catalog i obszaru roboczego, modele ML, punkty końcowe serwowania modeli, indeksy wyszukiwania wektorowego, udziały Delta, opublikowane pulpity AI/BI (wersje robocze są replikowane) oraz Spark Structured Streaming poza Lakeflow Spark Declarative Pipelines. Tabele z filtrami wierszy lub maskami kolumn oraz zasoby oznaczone tagami ABAC są oznaczane w tabeli systemowej jako Replikacja nie powiodła się, a te niepowodzenia opóźniają realizację celu punktu odzyskiwania (RPO), dopóki nie usuniesz zasobu z zakresu działania grupy przełączania awaryjnego.
  • Drugorzędne katalogi objęte zakresem są tylko do odczytu. Tryb tylko do odczytu ma zastosowanie wyłącznie do replikowanych encji. Nadal możesz skonfigurować własną replikację dla zasobów podlegających zabezpieczeniu, które znajdują się poza zakresem zarządzanego odzyskiwania po awarii. Nie można jednak uruchamiać zadań obliczeniowych w pomocniczym obszarze roboczym, gdy włączone jest zarządzane odzyskiwanie po awarii, co ogranicza możliwość uruchomienia tam samodzielnie utworzonego potoku replikacji.
  • Zmiana nazwy obiektu zabezpieczanego w Unity Catalog powoduje usunięcie i ponowne utworzenie w systemie pomocniczym. W przypadku tabel zarządzanych zmiana nazwy ponownie replikuje dane tabeli w następnym cyklu. Unikaj zmieniania nazw podczas replikacji stanu stałego.
  • UNDROP nie jest propagowany do węzła pomocniczego.
  • Maksymalnie 300 katalogów na konto.
  • Maksymalnie 100 grup przełączania awaryjnego na koncie.
  • Początkowa inicjalizacja zasobów obszaru roboczego może potrwać do 2 tygodni w przypadku dużych obszarów roboczych.
  • Zarządzane odzyskiwanie po awarii nie jest zgodne z zaporą magazynu obszaru roboczego. Nie włączaj obsługi zapory sieciowej na kontach magazynu danych obszaru roboczego używanych z zarządzanym odzyskiwaniem po awarii.

Informacje o pojęciach DR i najlepszych praktykach można znaleźć w temacie Odzyskiwanie po awarii.

  • Last updated on