Wskazówki dotyczące odzyskiwania po awarii specyficzne dla środowiska

Ten dokument zawiera szczegółowe wskazówki dotyczące odzyskiwania danych sieci szkieletowej w przypadku awarii regionalnej.

Przykładowy scenariusz

W kilku sekcjach wskazówek w tym dokumencie użyto następującego przykładowego scenariusza na potrzeby wyjaśnienia i ilustracji. W razie potrzeby zapoznaj się z tym scenariuszem.

Załóżmy, że masz pojemność C1 w regionie A z obszarem roboczym W1. Jeśli włączono odzyskiwanie po awarii dla pojemności C1, dane usługi OneLake zostaną zreplikowane do kopii zapasowej w regionie B. Jeśli w regionie A wystąpią zakłócenia, usługa sieci szkieletowej w języku C1 ulegnie awarii w regionie B.

Na poniższej ilustracji przedstawiono ten scenariusz. Pole po lewej stronie pokazuje zakłócony region. Pole w środku reprezentuje ciągłą dostępność danych po przejściu w tryb failover, a pole po prawej stronie pokazuje pełną sytuację po tym, jak klient działa w celu przywrócenia usług do pełnej funkcji.

Oto ogólny plan odzyskiwania:

1. Utwórz nową pojemność sieci szkieletowej C2 w nowym regionie.

2. Utwórz nowy obszar roboczy W2 w języku C2, w tym odpowiadające mu elementy o takich samych nazwach jak w C1. W1.

3. Skopiuj dane z zakłóconego C1. Od W1 do C2. W2.

4. Postępuj zgodnie z dedykowanymi instrukcjami dla każdego składnika, aby przywrócić elementy do pełnej funkcji.

Plany odzyskiwania specyficzne dla środowiska

W poniższych sekcjach przedstawiono przewodniki krok po kroku dla każdego środowiska sieci szkieletowej, które ułatwiają klientom proces odzyskiwania.

Inżynieria danych

Ten przewodnik przeprowadzi Cię przez procedury odzyskiwania środowiska inżynierowie danych. Obejmuje on magazyny lakehouse, notesy i definicje zadań platformy Spark.

Lakehouse

Lakehouses z oryginalnego regionu pozostają niedostępne dla klientów. Aby odzyskać usługę Lakehouse, klienci mogą ponownie utworzyć ją w obszarze roboczym C2. W2. Zalecamy dwa podejścia do odzyskiwania jezior:

Podejście 1. Używanie niestandardowego skryptu do kopiowania tabel i plików delty usługi Lakehouse

Klienci mogą ponownie utworzyć magazyny lakehouse przy użyciu niestandardowego skryptu Języka Scala.

1. Utwórz jezioro (na przykład LH1) w nowo utworzonym obszarze roboczym C2. W2.

2. Utwórz nowy notes w obszarze roboczym C2. W2.

3. Aby odzyskać tabele i pliki z oryginalnego magazynu lakehouse, zapoznaj się z danymi ze ścieżkami OneLake, takimi jak abfss (zobacz Łączenie z usługą Microsoft OneLake). Możesz użyć poniższego przykładu kodu (zobacz Wprowadzenie do programu Microsoft Spark Utilities) w notesie, aby uzyskać ścieżki ABFS plików i tabel z oryginalnego magazynu lakehouse. (Zastąp C1. W1 z rzeczywistą nazwą obszaru roboczego)

   mssparkutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Użyj poniższego przykładu kodu, aby skopiować tabele i pliki do nowo utworzonego magazynu lakehouse.

   1. W przypadku tabel delty należy skopiować tabelę pojedynczo, aby odzyskać dane w nowym lakehouse. W przypadku plików Lakehouse można skopiować pełną strukturę plików ze wszystkimi folderami bazowymi z pojedynczym wykonaniem.

   2. Skontaktuj się z zespołem pomocy technicznej, aby uzyskać znacznik czasu pracy w trybie failover wymaganym w skrypicie.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Po uruchomieniu skryptu tabele będą wyświetlane w nowym lakehouse.

Podejście 2. Używanie Eksplorator usługi Azure Storage do kopiowania plików i tabel

Aby odzyskać tylko określone pliki lub tabele lakehouse z oryginalnego lakehouse, użyj Eksplorator usługi Azure Storage. Aby uzyskać szczegółowe instrukcje, zobacz Integrowanie usługi OneLake z usługą Eksplorator usługi Azure Storage. W przypadku dużych rozmiarów danych użyj podejścia 1.

Uwaga

Dwa opisane powyżej podejścia odzyskują zarówno metadane, jak i dane dla tabel sformatowanych przez różnicę, ponieważ metadane są współlokowane i przechowywane z danymi w usłudze OneLake. W przypadku tabel bez formatowania różnicowego (e.g. CSV, Parquet itp.), które są tworzone przy użyciu skryptów/poleceń języka Spark Data Definition Language (DDL), użytkownik jest odpowiedzialny za konserwę i ponowne uruchamianie skryptów/poleceń spark DDL w celu ich odzyskania.

Notes

Notesy z regionu podstawowego pozostają niedostępne dla klientów, a kod w notesach nie będzie replikowany do regionu pomocniczego. Aby odzyskać kod notesu w nowym regionie, istnieją dwa podejścia do odzyskiwania zawartości kodu notesu.

Podejście 1. Nadmiarowość zarządzana przez użytkownika z integracją z usługą Git (w publicznej wersji zapoznawczej)

Najlepszym sposobem na łatwe i szybkie jest użycie integracji z usługą Fabric Git, a następnie zsynchronizowanie notesu z repozytorium ADO. Po przejściu usługi w tryb failover do innego regionu możesz użyć repozytorium, aby ponownie skompilować notes w nowo utworzonym obszarze roboczym.

1. Skonfiguruj integrację z usługą Git i wybierz pozycję Połącz i zsynchronizuj z repozytorium ADO.

   

   Na poniższej ilustracji przedstawiono zsynchronizowany notes.

   

2. Odzyskaj notes z repozytorium ADO.

   1. W nowo utworzonym obszarze roboczym ponownie połącz się z repozytorium usługi Azure ADO.

      

   2. Wybierz przycisk Kontrola źródła. Następnie wybierz odpowiednią gałąź repozytorium. Następnie wybierz pozycję Aktualizuj wszystko. Zostanie wyświetlony oryginalny notes.

      

      

   3. Jeśli oryginalny notes ma domyślny magazyn lakehouse, użytkownicy mogą odwoływać się do sekcji Lakehouse, aby odzyskać jezioro, a następnie połączyć nowo odzyskany lakehouse z nowo odzyskanym notesem.

      

   4. Integracja z usługą Git nie obsługuje synchronizowania plików, folderów ani migawek notesu w Eksploratorze zasobów notesu.

      1. Jeśli oryginalny notes zawiera pliki w Eksploratorze zasobów notesu:

         1. Pamiętaj, aby zapisać pliki lub foldery na dysku lokalnym lub w innym miejscu.

         2. Ponownie przekaż plik z dysku lokalnego lub dysków w chmurze do odzyskanego notesu.

      2. Jeśli oryginalny notes zawiera migawkę notesu, zapisz również migawkę notesu we własnym systemie kontroli wersji lub dysku lokalnym.

         

         

Aby uzyskać więcej informacji na temat integracji z usługą Git, zobacz Wprowadzenie do integracji z usługą Git.

Podejście 2. Ręczne podejście do tworzenia kopii zapasowej zawartości kodu

Jeśli nie wykonasz podejścia do integracji z usługą Git, możesz zapisać najnowszą wersję kodu, pliki w Eksploratorze zasobów i migawkę notesu w systemie kontroli wersji, takim jak Git, i ręcznie odzyskać zawartość notesu po awarii:

1. Użyj funkcji "Importuj notes", aby zaimportować kod notesu, który chcesz odzyskać.

   

2. Po zaimportowaniu przejdź do żądanego obszaru roboczego (na przykład "C2. W2") w celu uzyskania do niego dostępu.

3. Jeśli oryginalny notes ma domyślny magazyn lakehouse, zapoznaj się z sekcją Lakehouse. Następnie połącz nowo odzyskaną usługę lakehouse (która ma taką samą zawartość jak oryginalna domyślna usługa Lakehouse) do nowo odzyskanego notesu.

4. Jeśli oryginalny notes zawiera pliki lub foldery w Eksploratorze zasobów, przekaż ponownie pliki lub foldery zapisane w systemie kontroli wersji użytkownika.

Definicja zadania platformy Spark

Definicje zadań platformy Spark (SJD) z regionu podstawowego pozostają niedostępne dla klientów, a główny plik definicji i plik referencyjny w notesie zostaną zreplikowane do regionu pomocniczego za pośrednictwem usługi OneLake. Jeśli chcesz odzyskać dysk SJD w nowym regionie, możesz wykonać czynności ręczne opisane poniżej, aby odzyskać usługę SJD. Należy pamiętać, że historyczne uruchomienia usługi SJD nie zostaną odzyskane.

Elementy SJD można odzyskać, kopiując kod z oryginalnego regionu przy użyciu Eksplorator usługi Azure Storage i ręcznie ponownie łącząc odwołania usługi Lakehouse po awarii.

1. Utwórz nowy element SJD (na przykład SJD1) w nowym obszarze roboczym C2. W2 z tymi samymi ustawieniami i konfiguracjami co oryginalny element SJD (na przykład język, środowisko itp.).

2. Użyj Eksplorator usługi Azure Storage, aby skopiować biblioteki, pliki mains i migawki z oryginalnego elementu SJD do nowego elementu SJD.

   

3. Zawartość kodu zostanie wyświetlona w nowo utworzonym rozwiązaniu SJD. Musisz ręcznie dodać nowo odzyskane odwołanie lakehouse do zadania (zapoznaj się z krokami odzyskiwania usługi Lakehouse). Użytkownicy będą musieli ręcznie ponownie wprowadzić oryginalne argumenty wiersza polecenia.

   

Teraz możesz uruchomić lub zaplanować nowo odzyskane elementy SJD.

Aby uzyskać szczegółowe informacje na temat Eksplorator usługi Azure Storage, zobacz Integrowanie usługi OneLake z Eksplorator usługi Azure Storage.

Analiza danych

Ten przewodnik przeprowadzi Cię przez procedury odzyskiwania środowiska Nauka o danych. Obejmuje ona modele uczenia maszynowego i eksperymenty.

Model uczenia maszynowego i eksperyment

Nauka o danych elementy z regionu podstawowego pozostają niedostępne dla klientów, a zawartość i metadane w modelach uczenia maszynowego i eksperymenty nie będą replikowane do regionu pomocniczego. Aby w pełni odzyskać je w nowym regionie, zapisz zawartość kodu w systemie kontroli wersji (takim jak Git) i ręcznie ponownie uruchom zawartość kodu po awarii.

1. Odzyskaj notes. Zapoznaj się z krokami odzyskiwania notesu.

2. Konfiguracja, historycznie uruchamiane metryki i metadane nie będą replikowane do sparowanego regionu. Należy ponownie uruchomić każdą wersję kodu nauki o danych, aby w pełni odzyskać modele uczenia maszynowego i eksperymenty po awarii.

Magazyn danych

Ten przewodnik przeprowadzi Cię przez procedury odzyskiwania środowiska magazynu danych. Obejmuje ona magazyny.

Magazyn

Magazyny z oryginalnego regionu pozostają niedostępne dla klientów. Aby odzyskać magazyny, wykonaj następujące dwa kroki.

1. Utwórz nowy tymczasowy magazyn lakehouse w obszarze roboczym C2. W2 dla danych, które zostaną skopiowane z oryginalnego magazynu.

2. Wypełnij tabele delty magazynu, korzystając z Eksploratora magazynu i funkcji języka T-SQL (zobacz Tabele w magazynowaniu danych w usłudze Microsoft Fabric).

Uwaga

Zaleca się przechowywanie kodu magazynu (schematu, tabeli, widoku, procedury składowanej, definicji funkcji i kodów zabezpieczeń) w bezpiecznej lokalizacji (takiej jak Git) zgodnie z praktykami programistycznymi.

Pozyskiwanie danych za pośrednictwem usługi Lakehouse i kodu T-SQL

W nowo utworzonym obszarze roboczym C2. W2:

1. Utwórz tymczasowy lakehouse "LH2" w C2. W2.

2. Odzyskaj tabele delty w tymczasowym jeziorze z oryginalnego magazynu, wykonując kroki odzyskiwania usługi Lakehouse.

3. Utwórz nowy magazyn "WH2" w C2. W2.

4. Połącz tymczasowy magazyn lakehouse w Eksploratorze magazynu.

   

5. W zależności od tego, jak zamierzasz wdrożyć definicje tabel przed importem danych, rzeczywisty język T-SQL używany do importowania może się różnić. Możesz użyć metody INSERT INTO, SELECT INTO lub CREATE TABLE AS SELECT, aby odzyskać tabele magazynu z magazynów lakehouse. W tym przykładzie będziemy używać metody INSERT INTO. (Jeśli używasz poniższego kodu, zastąp przykłady rzeczywistymi nazwami tabel i kolumn)

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Na koniec zmień parametry połączenia w aplikacjach przy użyciu magazynu usługi Fabric.

Uwaga

W przypadku klientów, którzy potrzebują odzyskiwania po awarii między regionami i w pełni zautomatyzowanej ciągłości działania, zalecamy zachowanie dwóch konfiguracji magazynu sieci szkieletowej w oddzielnych regionach sieci szkieletowej oraz utrzymywanie parzystości kodu i danych przez regularne wdrożenia i pozyskiwanie danych w obu lokacjach.

Dublowana baza danych

Dublowane bazy danych z regionu podstawowego pozostają niedostępne dla klientów, a ustawienia nie są replikowane do regionu pomocniczego. Aby odzyskać ją w przypadku awarii regionalnej, należy ponownie utworzyć dublowaną bazę danych w innym obszarze roboczym z innego regionu.

Data Factory

Elementy usługi Data Factory z regionu podstawowego pozostają niedostępne dla klientów, a ustawienia i konfiguracja w potokach danych lub elementy gen2 przepływu danych nie będą replikowane do regionu pomocniczego. Aby odzyskać te elementy w przypadku awarii regionalnej, należy ponownie utworzyć Integracja danych elementów w innym obszarze roboczym z innego regionu. W poniższych sekcjach opisano szczegóły.

Przepływy danych Gen2

Jeśli chcesz odzyskać element Dataflow Gen2 w nowym regionie, musisz wyeksportować plik PQT do systemu kontroli wersji, takiego jak Git, a następnie ręcznie odzyskać zawartość usługi Dataflow Gen2 po awarii.

1. W elemencie Dataflow Gen2 na karcie Narzędzia główne edytora Power Query wybierz pozycję Eksportuj szablon.

   

2. W oknie dialogowym Eksportowanie szablonu wprowadź nazwę (obowiązkowe) i opis (opcjonalnie) dla tego szablonu. Gdy skończysz kliknij OK.

   

3. Po awarii utwórz nowy element Dataflow Gen2 w nowym obszarze roboczym "C2. W2".

4. W bieżącym okienku widoku edytora Power Query wybierz pozycję Importuj z szablonu dodatku Power Query.

   

5. W oknie dialogowym Otwieranie przejdź do domyślnego folderu pobierania i wybierz plik pqt zapisany w poprzednich krokach. Następnie wybierz pozycję Otwórz.

6. Szablon zostanie następnie zaimportowany do nowego elementu dataflow Gen2.

Potoki danych

Klienci nie mogą uzyskać dostępu do potoków danych w przypadku awarii regionalnej, a konfiguracje nie są replikowane do sparowanego regionu. Zalecamy utworzenie krytycznych potoków danych w wielu obszarach roboczych w różnych regionach.

Analiza w czasie rzeczywistym

Ten przewodnik przeprowadzi Cię przez procedury odzyskiwania środowiska analizy w czasie rzeczywistym. Obejmuje ona bazy danych KQL/zestawy zapytań i strumieni zdarzeń.

KQL Database/Queryset

Użytkownicy bazy danych/zestawu zapytań KQL muszą podejmować proaktywne działania w celu ochrony przed awarią regionalną. Poniższe podejście zapewnia, że w przypadku awarii regionalnej dane w zestawach zapytań baz danych KQL pozostają bezpieczne i dostępne.

Wykonaj poniższe kroki, aby zagwarantować efektywne rozwiązanie odzyskiwania po awarii dla baz danych I zestawów zapytań języka KQL.

1. Ustanów niezależne bazy danych KQL: skonfiguruj co najmniej dwie niezależne bazy danych KQL/zestawy zapytań na dedykowanych pojemnościach sieci szkieletowej. Należy je skonfigurować w dwóch różnych regionach świadczenia usługi Azure (najlepiej sparowanych regionach platformy Azure), aby zmaksymalizować odporność.

2. Replikowanie działań zarządzania: wszystkie działania związane z zarządzaniem podjęte w jednej bazie danych KQL powinny być dublowane w drugiej. Gwarantuje to, że obie bazy danych pozostaną zsynchronizowane. Kluczowe działania do replikacji obejmują:

   • Tabele: upewnij się, że struktury tabel i definicje schematów są spójne w bazach danych.

   • Mapowanie: Duplikuj wszystkie wymagane mapowania. Upewnij się, że źródła danych i miejsca docelowe są prawidłowo wyrównane.

   • Zasady: upewnij się, że obie bazy danych mają podobne zasady przechowywania, dostępu i innych odpowiednich zasad.

3. Zarządzanie uwierzytelnianiem i autoryzacją: dla każdej repliki skonfiguruj wymagane uprawnienia. Upewnij się, że zostały ustanowione odpowiednie poziomy autoryzacji, udzielając dostępu do wymaganego personelu przy zachowaniu standardów zabezpieczeń.

4. Równoległe pozyskiwanie danych: aby zapewnić spójność i gotowość danych w wielu regionach, załaduj ten sam zestaw danych do każdej bazy danych KQL w tym samym czasie, gdy je pozyskasz.

Strumień zdarzeń

Strumień zdarzeń to scentralizowane miejsce na platformie Sieci szkieletowej do przechwytywania, przekształcania i routingu zdarzeń w czasie rzeczywistym do różnych miejsc docelowych (na przykład lakehouses, baz danych KQL/zestawów zapytań) bez kodu. Tak długo, jak miejsca docelowe są obsługiwane przez odzyskiwanie po awarii, strumienie zdarzeń nie utracą danych. W związku z tym klienci powinni korzystać z możliwości odzyskiwania po awarii tych systemów docelowych, aby zagwarantować dostępność danych.

Klienci mogą również osiągnąć nadmiarowość geograficzną, wdrażając identyczne obciążenia strumienia zdarzeń w wielu regionach świadczenia usługi Azure w ramach wielolokalizowej strategii aktywne/aktywne. W przypadku podejścia obejmującego wiele lokacji aktywnych/aktywnych klienci mogą uzyskiwać dostęp do obciążenia w dowolnym z wdrożonych regionów. Takie podejście jest najbardziej złożonym i kosztownym podejściem do odzyskiwania po awarii, ale może skrócić czas odzyskiwania do niemal zera w większości sytuacji. Aby być w pełni nadmiarowym geograficznie, klienci mogą

1. Utwórz repliki swoich źródeł danych w różnych regionach.

2. Utwórz elementy strumienia zdarzeń w odpowiednich regionach.

3. Połącz te nowe elementy z identycznymi źródłami danych.

4. Dodaj identyczne miejsca docelowe dla każdego strumienia zdarzeń w różnych regionach.

Informacje pokrewne

• Przewodnik odzyskiwania po awarii w usłudze Microsoft Fabric