Udostępnij za pośrednictwem

Odzyskiwanie po awarii

Jasny wzorzec odzyskiwania po awarii ma kluczowe znaczenie dla natywnej dla chmury platformy analizy danych, takiej jak Azure Databricks. Ważne jest, aby zespoły danych mogły korzystać z platformy Azure Databricks nawet w rzadkich przypadkach awarii dostawcy usług w chmurze w całej regionie, niezależnie od tego, czy jest to spowodowane katastrofą regionalną, np. huraganem, trzęsieniem ziemi, czy innym źródłem.

Usługa Azure Databricks jest często główną częścią ogólnego ekosystemu danych, który obejmuje wiele usług, w tym usługi pozyskiwania danych źródłowych (batch/streaming), natywny magazyn w chmurze, taki jak ADLS (dla obszarów roboczych utworzonych przed 6 marca 2023 r., Azure Blob Storage), narzędzia i usługi końcowe, takie jak aplikacje analizy biznesowej i narzędzia do orkiestracji. Niektóre przypadki użycia mogą być szczególnie wrażliwe na awarię regionalnej usługi.

W tym artykule opisano pojęcia i najlepsze rozwiązania dotyczące pomyślnego rozwiązania do odzyskiwania po awarii między regionami dla platformy Databricks.

Gwarancje wysokiej dostępności wewnątrz regionu

W pozostałej części tego tematu skupiono się na implementacji odzyskiwania po awarii między regionami, ale ważne jest, aby zrozumieć gwarancje wysokiej dostępności oferowane przez usługę Azure Databricks w jednym regionie. Gwarancje wysokiej dostępności w regionie obejmują następujące składniki:

Dostępność platformy kontrolnej usługi Databricks

Płaszczyzna sterowania usługi Databricks jest odporna na błędy strefowe i powinna zostać automatycznie odzyskana w ciągu około 15 minut od awarii strefowej. Rutynowe testy niepowodzeń strefowych weryfikują to.

Wszystkie bezstanowe usługi płaszczyzny sterowania mogą automatycznie obsługiwać utratę poszczególnych maszyn wirtualnych, a także wszystkich maszyn wirtualnych w całej strefie. Dane obszaru roboczego są przechowywane w bazach danych replikowanych między strefami w regionie. Konta pamięci masowej używane do udostępniania obrazów środowiska Databricks Runtime są również zapasowe w danym regionie, a wszystkie regiony mają zapasowe konta pamięci masowej, używane, gdy konto podstawowe jest niedostępne. Zobacz Regiony usługi Azure Databricks.

Odporność na awarie strefowe obsługuje na co najwyżej jedną strefę będącą w stanie awarii i jest dostępna tylko w regionach Azure obsługujących wiele stref.

Dostępność płaszczyzny obliczeniowej

Dostępność obszaru roboczego zależy od dostępności płaszczyzny sterowania (zgodnie z powyższym opisem). Dane w Root DBFS nie są zagrożone, jeśli konto magazynu dla Root DBFS jest skonfigurowane z magazynem strefowo nadmiarowym (ZRS) lub magazynem geograficznie-strefowo nadmiarowym (GZRS) (domyślnie jest to magazyn geograficznie nadmiarowy (GRS)).

Węzły dla klastrów są pobierane z różnych stref dostępności poprzez żądanie ich od dostawcy obliczeniowego Azure, zakładając wystarczającą pojemność w pozostałych strefach, aby spełnić żądanie. 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. Jedynym wyjątkiem jest utrata węzła sterownika. W takim przypadku menedżer klastra ponownie uruchamia zadanie i klaster.

Omówienie odzyskiwania po awarii

Odzyskiwanie po awarii obejmuje zestaw zasad, narzędzi i procedur, które umożliwiają odzyskiwanie lub kontynuację istotnej infrastruktury technologicznej i systemów po klęskach żywiołowych lub wywołanych przez człowieka. Duża usługa w chmurze, podobna do platformy Azure, obsługuje wielu klientów i ma wbudowane zabezpieczenia przed pojedynczym niepowodzeniem. Na przykład region to grupa budynków połączonych z różnymi źródłami zasilania, aby zagwarantować, że jedna utrata energii nie spowoduje zamknięcia regionu. Jednak mogą wystąpić awarie regionów chmury, a stopień zakłóceń i jego wpływu na organizację może się różnić.

Przed wdrożeniem planu odzyskiwania po awarii należy zrozumieć różnicę między odzyskiwaniem po awarii (DR) i wysoką dostępnością .

Wysoka dostępność to cecha odporności systemu. Wysoka dostępność zapewnia minimalny poziom wydajności operacyjnej, który jest zwykle zdefiniowany pod względem spójnego czasu pracy lub procentu czasu pracy. Wysoka dostępność jest implementowana (w tym samym regionie co system podstawowy), projektując ją jako funkcję systemu podstawowego. Na przykład usługi w chmurze, takie jak Platforma Azure, mają usługi wysokiej dostępności, takie jak ADLS (dla obszarów roboczych utworzonych przed 6 marca 2023 r., Azure Blob Storage). Wysoka dostępność nie wymaga znaczącego jawnego przygotowania od klienta usługi Azure Databricks.

Z kolei plan odzyskiwania po awarii wymaga decyzji i rozwiązań, które działają dla określonej organizacji w celu obsługi większej awarii regionalnej w przypadku krytycznych systemów. W tym artykule omówiono typową terminologię odzyskiwania po awarii, typowe rozwiązania i niektóre najlepsze rozwiązania dotyczące planów odzyskiwania po awarii za pomocą usługi Azure Databricks.

Terminologia

Terminologia dotycząca regionów

W tym artykule użyto następujących definicji dla regionów:

  • Region podstawowy: region geograficzny, w którym użytkownicy uruchamiają typowe codzienne obciążenia interaktywnej i zautomatyzowanej analizy danych.

  • Region pomocniczy: region geograficzny, w którym zespoły IT tymczasowo przenoszą obciążenia analizy danych podczas awarii w regionie podstawowym.

  • Magazyn geograficznie zreplikowany: Azure oferuje magazyn z geograficzną replikacją w różnych regionach dla trwałego przechowywania danych przy użyciu asynchronicznego procesu replikacji magazynu.

    Ważne

    W przypadku procesów odzyskiwania po awarii usługa Databricks zaleca, aby nie polegać na magazynie geograficznie nadmiarowym na potrzeby duplikowania danych między regionami, takich jak usługa ADLS (w przypadku obszarów roboczych utworzonych przed 6 marca 2023 r. usługa Azure Blob Storage) tworzona przez usługę Azure Databricks dla każdego obszaru roboczego w ramach subskrypcji platformy Azure. Ogólnie rzecz biorąc, należy użyć Deep Clone dla tabel Delta i przekonwertować dane na format Delta, aby użyć Deep Clone, jeśli jest to możliwe w przypadku innych formatów danych.

Terminologia dotycząca stanu wdrożenia

W tym artykule użyto następujących definicji stanu wdrożenia:

  • Aktywne wdrażanie: użytkownicy mogą łączyć się z aktywnym wdrożeniem obszaru roboczego usługi Azure Databricks i uruchamiać obciążenia. Zadania są okresowo planowane przy użyciu harmonogramu usługi Azure Databricks lub innych mechanizmów. Strumienie danych można również uruchomić w tym środowisku wdrożeniowym. Niektóre dokumenty mogą odnosić się do aktywnego wdrożenia jako gorącego wdrożenia.

  • Wdrożenie pasywne: procesy nie są uruchamiane we wdrożeniu pasywnym. Zespoły IT mogą skonfigurować zautomatyzowane procedury wdrażania kodu, konfiguracji i innych obiektów re:[Databricks] do wdrożenia pasywnego. Wdrożenie staje się aktywne tylko wtedy, gdy bieżące aktywne wdrożenie nie działa. Niektóre dokumenty mogą odnosić się do wdrożenia pasywnego jako zimne wdrożenie.

    Ważne

    Projekt może opcjonalnie obejmować wiele pasywnych wdrożeń w różnych regionach, aby zapewnić dodatkowe opcje rozwiązywania regionalnych awarii.

Zazwyczaj zespół ma tylko jedno aktywne wdrożenie w danym momencie, co nazywa się strategią odzyskiwania po awarii aktywny-pasywny. Istnieje mniej typowa strategia rozwiązania odzyskiwania po awarii o nazwie aktywne-aktywne, w której istnieją dwa jednoczesne aktywne wdrożenia.

Terminologia branżowa odzyskiwania po awarii

Istnieją dwa ważne terminy branżowe, które należy zrozumieć i zdefiniować dla zespołu:

  • Cel punktu odzyskiwania: cel punktu odzyskiwania (RPO) to maksymalny docelowy okres, w którym dane (transakcje) mogą zostać utracone z usługi IT z powodu poważnego zdarzenia. Wdrożenie usługi Azure Databricks nie przechowuje głównych danych klientów. Jest przechowywane w oddzielnych systemach, takich jak ADLS (dla obszarów roboczych utworzonych przed 6 marca 2023 r.) lub Azure Blob Storage i innych źródeł danych pod twoją kontrolą. Warstwa kontrolna usługi Azure Databricks zapisuje niektóre obiekty częściowo lub w całości, takie jak zadania i notatniki. W przypadku usługi Azure Databricks RPO (Recovery Point Objective) jest definiowany jako maksymalny docelowy okres, w którym można utracić obiekty, takie jak zadania i zmiany notatnika. Ponadto odpowiadasz za zdefiniowanie celu punktu odzyskiwania danych (RPO) dla własnych danych klientów w usłudze ADLS (dla obszarów roboczych utworzonych przed 6 marca 2023 r. w usłudze Azure Blob Storage) lub innymi źródłami danych, które kontrolujesz.

  • Cel czasu odzyskiwania: cel czasu odzyskiwania (RTO) to docelowy czas trwania i poziom usługi, w ramach którego proces biznesowy musi zostać przywrócony po awarii.

    Cel punktu odzyskiwania po awarii i cel czasu odzyskiwania po awarii

Odzyskiwanie po awarii i uszkodzenie danych

Rozwiązanie odzyskiwania po awarii nie ogranicza uszkodzenia danych. Uszkodzone dane w regionie podstawowym są replikowane z regionu podstawowego do regionu pomocniczego i są uszkodzone w obu regionach. Istnieją inne sposoby łagodzenia tego rodzaju awarii, na przykład Podróżowanie w czasie typu Delta.

Typowy przepływ pracy związanej z odzyskiwaniem

Scenariusz odzyskiwania po awarii usługi Azure Databricks zwykle jest następujący:

  1. Awaria występuje w usłudze krytycznej używanej w regionie podstawowym. Może to być usługa źródła danych lub sieć, która ma wpływ na wdrożenie usługi Azure Databricks.

  2. Zbadasz sytuację u dostawcy usług w chmurze.

  3. Jeśli stwierdzisz, że twoja firma nie może poczekać na rozwiązanie problemu w regionie podstawowym, możesz zdecydować się na przejście w tryb failover do regionu pomocniczego.

  4. Sprawdź, czy ten sam problem nie ma również wpływu na region pomocniczy.

  5. Przełącz się na region pomocniczy.

    1. Zatrzymaj wszystkie działania w obszarze roboczym. Użytkownicy zatrzymują obciążenia. Użytkownicy lub administratorzy są poinstruowani, aby w miarę możliwości utworzyć kopię zapasową ostatnich zmian. Zadania są zamykane, jeśli jeszcze nie powiodły się z powodu awarii.
    2. Uruchom procedurę odzyskiwania w regionie zapasowym. Mechanizm odzyskiwania aktualizuje trasowanie, zmienia nazwy połączeń oraz przekierowuje ruch sieciowy do regionu zapasowego.
    3. Po przetestowaniu zadeklaruj działanie regionu pomocniczego. Obciążenia produkcyjne można teraz wznowić. Użytkownicy mogą logować się do aktualnie aktywnego wdrożenia. Możesz ponownie uruchomić zaplanowane lub opóźnione zadania.

    Aby uzyskać szczegółowe instrukcje w kontekście usługi Azure Databricks, zobacz Testowanie trybu failover.

  6. W pewnym momencie problem w regionie głównym zostaje rozwiązany, a ty potwierdzasz ten fakt.

  7. Przywracanie (powrót po awarii) do regionu podstawowego.

    1. Zatrzymaj całą pracę w regionie pomocniczym.
    2. Uruchom procedurę odzyskiwania w regionie podstawowym. Procedura odzyskiwania obsługuje routing i zmianę nazwy połączenia i ruchu sieciowego z powrotem do regionu podstawowego.
    3. Replikuj dane z powrotem do regionu podstawowego zgodnie z potrzebami. Aby zmniejszyć złożoność, być może zminimalizuj ilość danych, które należy replikować. Jeśli na przykład niektóre zadania są tylko do odczytu po uruchomieniu we wdrożeniu pomocniczym, może nie być konieczne zreplikowanie tych danych z powrotem do podstawowego wdrożenia w regionie podstawowym. Można jednak mieć jedno zadanie produkcyjne, które musi zostać uruchomione i może wymagać replikacji danych z powrotem do regionu podstawowego.
    4. Przetestuj wdrożenie w regionie podstawowym.
    5. Zadeklaruj działanie regionu podstawowego i że jest to aktywne wdrożenie. Wznawianie obciążeń produkcyjnych.

    Aby uzyskać więcej informacji na temat przywracania do regionu podstawowego, zobacz Przywracanie testowe (powrót po awarii).

Ważne

W tych krokach może wystąpić utrata danych. Twoja organizacja musi zdefiniować, ile utraty danych jest akceptowalna i co można zrobić, aby ograniczyć tę utratę.

Krok 1. Zrozumienie potrzeb biznesowych

Pierwszym krokiem jest zdefiniowanie i zrozumienie potrzeb biznesowych. Określ, które usługi danych są krytyczne, oraz jakie są ich oczekiwane punkty odzyskiwania danych (RPO) i czasy przywrócenia danych (RTO).

Zbadaj rzeczywistą tolerancję każdego systemu. Pamiętaj, że odzyskiwanie po awarii, przełączenie na tryb awaryjny i powrót po awarii mogą być kosztowne i wiązać się z innymi ryzykami. Inne zagrożenia mogą obejmować uszkodzenie danych, duplikowanie danych (w przypadku zapisywania w niewłaściwej lokalizacji magazynu) oraz użytkowników, którzy logują się i wprowadzają zmiany w nieprawidłowych miejscach.

Mapuj wszystkie punkty integracji usługi Azure Databricks, które wpływają na Twoją firmę:

  • 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ć na miejscu.
  • Jak dane trafiają do chmury?
  • Kto korzysta z tych danych? Jakie procesy zużywają go podrzędnie?
  • Czy istnieją integracje innych firm, które muszą mieć świadomość zmian odzyskiwania po awarii?

Określ narzędzia lub strategie komunikacji, które mogą obsługiwać plan odzyskiwania po awarii:

  • Jakich narzędzi użyjesz do szybkiego modyfikowania konfiguracji sieci?
  • Czy można wstępnie zdefiniować konfigurację i uczynić ją modułową, aby uwzględnić rozwiązania odzyskiwania po awarii w naturalny i konserwowalny sposób?
  • Które narzędzia komunikacyjne i kanały będą powiadamiać wewnętrzne zespoły i osoby trzecie (integracje, odbiorców końcowych) o zmianach dotyczących przełączenia awaryjnego (failover) i powrotu awaryjnego (failback)? Jak potwierdzisz ich potwierdzenie?
  • Jakie narzędzia lub specjalne wsparcie będą potrzebne?
  • Jakie usługi, jeśli istnieją, zostaną zamknięte do czasu zakończenia odzyskiwania?

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

Rozwiązanie musi replikować poprawne dane na płaszczyźnie sterowania, płaszczyźnie obliczeniowej i źródłach danych. Zapasowe obszary robocze na potrzeby odzyskiwania po awarii muszą być mapowane do różnych płaszczyzn sterowania w różnych regionach. Musisz utrzymywać te dane w synchronizacji okresowo przy użyciu rozwiązania opartego na skryptach, takiego jak narzędzie do synchronizacji lub przepływ pracy CI/CD. Nie ma potrzeby synchronizowania danych z samej sieci 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ń), możesz konsekwentnie wdrażać te sieci w obu regionach przy użyciu narzędzi opartych na szablonach, takich jak Terraform.

Ponadto należy upewnić się, że źródła danych są replikowane zgodnie z potrzebami w różnych regionach.

Odzyskiwanie po awarii — co należy zreplikować?

Ogólne sprawdzone metody postępowania

Ogólne najlepsze rozwiązania dotyczące pomyślnego planu odzyskiwania po awarii obejmują:

  1. Zrozumienie, które procesy są kluczowe dla firmy i muszą działać podczas odzyskiwania po awarii.

  2. Jasno określ, które usługi są zaangażowane, które dane są przetwarzane, jaki jest przepływ danych i gdzie są przechowywane.

  3. Izoluj usługi i dane jak najwięcej. Na przykład utwórz specjalny kontener magazynu w chmurze dla danych na potrzeby odzyskiwania po awarii lub przenieś obiekty usługi Azure Databricks potrzebne podczas awarii do oddzielnego obszaru roboczego.

  4. Twoim zadaniem jest utrzymanie integralności między wdrożeniami podstawowymi i pomocniczymi dla innych obiektów, które nie są przechowywane w warstwie kontrolnej usługi Databricks.

    Ostrzeżenie

    Najlepszym rozwiązaniem jest to, że nie przechowujesz danych w głównej usłudze ADLS (w przypadku obszarów roboczych utworzonych przed 6 marca 2023 r. usługa Azure Blob Storage), która jest używana do dostępu głównego systemu plików DBFS dla obszaru roboczego. Podstawowa pamięć DBFS nie nadaje się do przechowywania danych produkcyjnych klientów. Usługa Databricks zaleca również, aby w tej lokalizacji nie przechowywać bibliotek, plików konfiguracji ani skryptów inicjowania.

  5. W przypadku źródeł danych, jeśli to możliwe, zaleca się używanie natywnych narzędzi platformy Azure do replikacji i nadmiarowości w celu replikacji danych do regionów odzyskiwania po awarii.

Wybierz strategię rozwiązania kwestii odzyskiwania

Typowe rozwiązania odzyskiwania po awarii obejmują dwa (lub więcej) obszary robocze. Możesz wybrać jedną z kilku strategii. Rozważ potencjalną długość zakłóceń (godziny, a może nawet dzień), wysiłek w celu upewnienia się, że środowisko pracy jest w pełni operacyjne, oraz nakład pracy na przywrócenie (powrót po awarii) do regionu podstawowego.

Strategia rozwiązania aktywne-pasywne

Rozwiązanie aktywne-pasywne jest najczęściej spotykanym i najprostszym rozwiązaniem, a ten typ rozwiązania koncentruje się na tym artykule. Rozwiązanie aktywne-pasywne synchronizuje zmiany danych i obiektów z aktywnego wdrożenia do wdrożenia pasywnego. Jeśli wolisz, możesz mieć wiele pasywnych wdrożeń w różnych regionach, ale ten artykuł koncentruje się na podejściu z jednym pasywnym wdrożeniem. Podczas procesu odzyskiwania po awarii pasywne wdrożenie w regionie zapasowym staje się aktywnym wdrożeniem.

Istnieją dwa główne warianty tej strategii:

  • Ujednolicone (mądre dla przedsiębiorstw) rozwiązanie: dokładnie jeden zestaw aktywnych i pasywnych wdrożeń, które obsługują całą organizację.
  • Rozwiązanie według działu lub projektu: każdy dział lub domena projektu obsługuje oddzielne rozwiązanie odzyskiwania po awarii. Niektóre organizacje chcą rozdzielić szczegóły odzyskiwania po awarii między działami i używać różnych regionów podstawowych i pomocniczych dla każdego zespołu na podstawie unikatowych potrzeb każdego zespołu.

Dostępne są inne warianty, takie jak użycie wdrożenia pasywnego dla przypadków użycia tylko do odczytu. Jeśli masz obciążenia, które są tylko do odczytu, na przykład zapytania użytkowników, mogą być uruchamiane w rozwiązaniu pasywnym w dowolnym momencie, jeśli nie modyfikują danych lub obiektów usługi Azure Databricks, takich jak notesy lub zadania.

Strategia rozwiązania aktywne-aktywne

W rozwiązaniu aktywne-aktywne uruchamiasz wszystkie procesy danych w obu regionach przez cały czas równolegle. Zespół operacyjny musi upewnić się, że proces danych, taki jak zadanie, jest oznaczony jako ukończony tylko wtedy, gdy zakończy się pomyślnie w obu regionach. Obiekty nie mogą być zmieniane w środowisku produkcyjnym i muszą przechodzić przez ścisły proces CI/CD od środowiska rozwoju/testowego do produkcji.

Rozwiązanie aktywne-aktywne jest najbardziej złożoną strategią, a ponieważ zadania są uruchamiane w obu regionach, istnieje dodatkowy koszt finansowy.

Podobnie jak w przypadku strategii aktywne-pasywne, można zaimplementować je jako ujednolicone rozwiązanie organizacji lub według działu.

Może się okazać, że nie potrzebujesz równoważnego obszaru roboczego w systemie pomocniczym dla wszystkich obszarów roboczych, w zależności od przepływu pracy. Na przykład obszar roboczy rozwojowy lub testowy może nie wymagać duplikatu. W przypadku dobrze zaprojektowanego procesu tworzenia oprogramowania możesz łatwo odtworzyć te obszary robocze w razie potrzeby.

Wybieranie narzędzi

Istnieją dwa główne podejścia dla narzędzi, aby utrzymać dane jak najbardziej zbliżone w obrębie obszarów roboczych w regionach podstawowym i pomocniczym.

  • Klient synchronizacji, który kopiuje z podstawowej do pomocniczej: klient synchronizacji wypycha dane produkcyjne i zasoby z regionu podstawowego do regionu pomocniczego. Zazwyczaj jest to uruchamiane zgodnie z harmonogramem.
  • 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ć w obu obszarach roboczych, zarówno podstawowym, jak i pomocniczym, podczas gdy niektóre artefakty mogą być wdrażane dopiero po wystąpieniu zdarzenia związanego z odzyskiwaniem po awarii. Aby zapoznać się z narzędziami, zobacz Skrypty automatyzacji, przykłady i prototypy.

Poniższy diagram kontrastuje z tymi dwoma metodami.

Opcje odzyskiwania po awarii

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 różnych 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 wersji pomocniczej musi być zero aż do zdarzenia odzyskiwania danych po awarii. Zestawy utworzone z dowolnym min_idle_instances są synchronizowane z pomocniczym obszarem roboczym za pomocą interfejsu API lub interfejsu wiersza poleceń.
Konfiguracje zadań Może to być szablony w usłudze Git. W przypadku wdrożenia podstawowego wdróż definicję zadania w następujący sposób. W przypadku wdrożenia pomocniczego wdróż zadanie i ustaw współbieżność na zero. Spowoduje to wyłączenie zadania w tym wdrożeniu i uniemożliwia wykonywanie dodatkowych uruchomień. 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. Jednak dane dla zadań będą przechowywane do momentu wystąpienia zdarzenia odzyskiwania po awarii. 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. Jest to bardzo zależne od strategii odzyskiwania po awarii danych.
Metadane tabeli Dołącz do kodu źródłowego, jeśli jest tworzony tylko za pomocą zadań opartych na notesie lub interfejsu API poleceń. Dotyczy to zarówno wewnętrznego magazynu metadanych usługi Azure Databricks, jak i zewnętrznego skonfigurowanego magazynu metadanych. Porównaj definicje metadanych między magazynami metadanych przy użyciu Spark Catalog API lub "Show Create Table" za pomocą notatnika lub skryptów. Należy pamiętać, że tabele magazynu bazowego mogą być oparte na regionie i różnią się między wystąpieniami 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. Równoczesne wdrożenia w ramach wdrożeń głównych i pomocniczych, chociaż te w ramach wdrożenia pomocniczego powinny zostać zakończone do czasu wystąpienia zdarzenia odzyskiwania po awarii. 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ń.

Wybieranie regionów i wielu pomocniczych obszarów roboczych

Potrzebujesz pełnej kontroli nad wyzwalaczem odzyskiwania po awarii. Możesz zdecydować się na uruchomienie tego w dowolnym momencie lub z jakiegokolwiek powodu. Musisz wziąć na siebie odpowiedzialność za stabilizację systemów po awarii, zanim będziesz mógł ponownie uruchomić operację w trybie powrotu do produkcji. Zazwyczaj oznacza to, że musisz utworzyć wiele obszarów roboczych usługi Azure Databricks, aby obsługiwać potrzeby środowiska produkcyjnego i odzyskiwania po awarii, a następnie wybrać pomocniczy region trybu failover.

Na platformie Azure sprawdź dostępność replikacji danych, a także dostępność typów produktów i maszyn wirtualnych.

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

Jeśli obszar roboczy jest już w środowisku produkcyjnym, zazwyczaj należy uruchomić jednorazową operację kopiowania w celu zsynchronizowania pasywnego wdrożenia z aktywnym wdrożeniem. Ta jednorazowa kopia obsługuje następujące elementy:

  • Replikacja danych: replikowanie przy użyciu rozwiązania replikacji w chmurze lub operacji delta Deep Clone.
  • Generowanie tokenu: użyj generowania tokenów, aby zautomatyzować replikację i przyszłe obciążenia.
  • Replikacja obszaru roboczego: użyj replikacji obszaru roboczego przy użyciu metod opisanych w kroku 4: Przygotowywanie źródeł danych.
  • Walidacja obszaru roboczego: — test, aby upewnić się, że obszar roboczy i proces mogą zostać wykonane pomyślnie i dostarczyć oczekiwane wyniki.

Kolejne akcje kopiowania i synchronizacji są szybsze po początkowej operacji kopiowania jednorazowego. Rejestrowanie z twoich narzędzi także rejestruje, 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

Gdy dane są przetwarzane w partiach, zwykle znajdują się w źródle danych, które można łatwo replikować lub dostarczać do innego regionu.

Na przykład dane mogą być regularnie przekazywane do lokalizacji przechowywania w chmurze. W trybie odzyskiwania po awarii dla regionu pomocniczego należy upewnić się, że pliki zostaną przekazane do magazynu w regionie pomocniczym. Obciążenia muszą odczytywać dane z magazynu w regionie pomocniczym i zapisywać w magazynie w regionie pomocniczym.

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 odzyskiwania po awarii i korzystały z wdrożenia pomocniczego w 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

Okresowo testuj konfigurację odzyskiwania po awarii, aby upewnić się, że działa prawidłowo. Nie ma żadnej wartości w utrzymywaniu rozwiązania odzyskiwania po awarii, jeśli nie można go używać, gdy jest potrzebny. Niektóre firmy przełączają się między regionami co kilka miesięcy. Przełączanie regionów zgodnie z regularnym harmonogramem pozwala przetestować założenia i procesy, aby upewnić się, że odpowiadają na potrzeby związane z odzyskiwaniem. Dzięki temu organizacja zapozna się również z zasadami i procedurami w nagłych wypadkach.

Ważne

Regularnie testuj rozwiązanie odzyskiwania po awarii w rzeczywistych warunkach.

Jeśli okaże się, że brakuje obiektu lub szablonu i nadal musisz polegać na informacjach przechowywanych w podstawowym obszarze roboczym, zmodyfikuj plan, aby usunąć te przeszkody, zreplikuj te informacje w systemie pomocniczym lub udostępnij je w inny sposób.

Przetestuj wszelkie wymagane zmiany organizacyjne w procesach oraz zmiany w konfiguracji. Plan odzyskiwania po awarii ma wpływ na potok wdrażania i ważne jest, aby zespół wiedział, co musi być zsynchronizowane. Po skonfigurowaniu obszarów roboczych odzyskiwania po awarii należy upewnić się, że infrastruktura (ręcznie lub kod), zadania, notes, biblioteki i inne obiekty obszaru roboczego są dostępne w regionie pomocniczym.

Porozmawiaj z zespołem o sposobie rozszerzania standardowych procesów roboczych i potoków konfiguracji w celu wdrożenia zmian we wszystkich obszarach roboczych. Zarządzanie tożsamościami użytkowników we wszystkich obszarach roboczych. Pamiętaj, aby skonfigurować narzędzia, takie jak automatyzacja zadań i monitorowanie nowych obszarów roboczych.

Planowanie i testowanie zmian w narzędziach konfiguracji:

  • 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 upewnij się, że masz oddzielny szablon konfiguracji do pracy z wdrożeniami pomocniczymi i regionami pomocniczymi. Przygotuj plan przejścia w tryb failover i przetestuj wszystkie założenia.
  • Zmiany wykonywania: jeśli masz harmonogram wyzwalający zadania lub inne akcje, może być konieczne skonfigurowanie oddzielnego harmonogramu, który współpracuje z wdrożeniem pomocniczym lub jego źródłami danych. Przygotuj plan przejścia w tryb failover i przetestuj wszystkie założenia.
  • Łą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. Przygotuj plan przejścia w tryb failover i przetestuj wszystkie założenia.
  • Zmiany automatyzacji: dla wszystkich narzędzi automatyzacji przygotuj plan przejścia w tryb failover i przetestuj wszystkie założenia.
  • Dane wyjściowe: w przypadku wszystkich narzędzi, które generują dane wyjściowe lub dzienniki, przygotuj plan przejścia w tryb failover i przetestuj wszystkie założenia.

Testowanie pracy w trybie failover

Odzyskiwanie po awarii może być wyzwalane przez wiele różnych scenariuszy. Może zostać uruchomiony przez nieoczekiwaną przerwę. Niektóre podstawowe funkcje mogą nie działać, w tym sieć w chmurze, magazyn w chmurze lub inna podstawowa usługa. Nie masz dostępu do wyłączenia systemu w bezpieczny sposób i musisz spróbować przywrócić jego działanie. Jednak proces może zostać wyzwolony przez zamknięcie lub planowaną awarię, a nawet przez okresowe przełączanie aktywnych wdrożeń między dwoma regionami.

Podczas testowania trybu failover połącz się z systemem i uruchom proces zamykania. Upewnij się, że wszystkie zadania zostały ukończone, a klastry zostaną zakończone.

Klient synchronizacji (lub narzędzia ciągłej integracji/ciągłego wdrażania) może replikować odpowiednie obiekty i zasoby usługi Azure Databricks do drugorzędnego obszaru roboczego. Aby aktywować pomocniczy obszar roboczy, proces może obejmować niektóre lub wszystkie następujące elementy:

  1. Uruchom testy, aby potwierdzić, że platforma jest aktualna.
  2. 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.
  3. Proces odzyskiwania:
    1. Sprawdź datę najnowszych zsynchronizowanych danych. Zobacz [_](# dr-terminologia). Szczegóły tego kroku różnią się w zależności od sposobu synchronizowania danych i unikatowych potrzeb biznesowych.
    2. 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.
    3. 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).
    4. Ukończ proces przepływu danych i poinformuj użytkowników.
  4. Uruchom odpowiednie pule (lub zwiększ min_idle_instances do odpowiedniej liczby).
  5. Uruchom odpowiednie klastry (jeśli nie zostaną zakończone).
  6. Zmień równoczesne uruchamianie zadań i uruchom właściwe zadania. Mogą to być jednorazowe uruchomienia lub okresowe uruchomienia.
  7. 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.

Testowanie przywracania (powrót po awarii)

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

  1. Uzyskaj potwierdzenie przywrócenia regionu podstawowego.
  2. Wyłącz pule i klastry w regionie pomocniczym, aby nie rozpocząć przetwarzania nowych danych.
  3. 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 (odzyskiwania po awarii) do regionu podstawowego (produkcyjnego).
  4. 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.
  5. Wyłącz wszystkie obciążenia w regionie odzyskiwania po awarii.
  6. Zmień adres URL zadań i użytkowników na region podstawowy.
  7. Uruchom testy, aby potwierdzić, że platforma jest aktualna.
  8. Uruchom odpowiednie pule (lub zwiększ min_idle_instances do odpowiedniej liczby).
  9. Uruchom odpowiednie klastry (jeśli nie zostaną zakończone).
  10. Zmień równoczesne uruchamianie dla zadań i uruchom odpowiednie zadania. Mogą to być jednorazowe uruchomienia lub okresowe uruchomienia.
  11. W razie potrzeby skonfiguruj ponownie region pomocniczy na potrzeby przyszłego odzyskiwania po awarii.

Skrypty automatyzacji, przykłady i prototypy

Skrypty automatyzacji do rozważenia dla projektów odzyskiwania po awarii:

Dodatkowe zasoby