Udostępnij za pośrednictwem

Omówienie ciągłości działania i odzyskiwania po awarii

  • Artykuł

Ciągłość działania i odzyskiwanie po awarii na platformie Azure Data Explorer umożliwia firmie kontynuowanie działania w obliczu zakłóceń. W tym artykule omówiono dostępność (wewnątrz regionu) i odzyskiwanie po awarii. Zawiera szczegółowe informacje o możliwościach natywnych i zagadnieniach dotyczących architektury dla odpornego wdrożenia usługi Azure Data Explorer. Szczegóły odzyskiwania po błędach ludzkich, wysoka dostępność, a następnie wiele konfiguracji odzyskiwania po awarii. Te konfiguracje zależą od wymagań dotyczących odporności, takich jak cel punktu odzyskiwania (RPO) i cel czasu odzyskiwania (RTO), wymagane nakłady pracy i koszty.

Eliminowanie zdarzeń zakłócających działanie

Błąd ludzki

Błędy ludzkie są nieuniknione. Użytkownicy mogą przypadkowo usunąć klaster, bazę danych lub tabelę.

Przypadkowe usunięcie klastra lub bazy danych

Przypadkowe usunięcie klastra lub bazy danych jest niemożliwą do odzyskania akcją. Jako właściciel zasobu usługi Azure Data Explorer możesz zapobiec utracie danych, włączając funkcję blokowania usuwania dostępną na poziomie zasobu platformy Azure.

Przypadkowe usunięcie tabeli

Użytkownicy z uprawnieniami administratora tabeli lub wyższymi mogą upuszczać tabele. Jeśli jeden z tych użytkowników przypadkowo spadnie tabelę, możesz go odzyskać przy użyciu .undo drop table polecenia . Aby to polecenie zakończyło się pomyślnie, należy najpierw włączyć właściwość możliwości odzyskiwania w zasadach przechowywania.

Przypadkowe usunięcie tabeli zewnętrznej

Tabele zewnętrzne to jednostki schematu zapytań Kusto odwołujące się do danych przechowywanych poza bazą danych. Usunięcie tabeli zewnętrznej powoduje usunięcie tylko metadanych tabeli. Możesz go odzyskać, wykonując ponownie polecenie tworzenia tabeli. Użyj funkcji usuwania nietrwałego , aby chronić przed przypadkowym usunięciem lub zastąpieniem pliku/obiektu blob przez czas skonfigurowany przez użytkownika.

Wysoka dostępność usługi Azure Data Explorer

Wysoka dostępność odnosi się do odporności na uszkodzenia platformy Azure Data Explorer, jej składników i podstawowych zależności w regionie świadczenia usługi Azure. Ta odporność na uszkodzenia pozwala uniknąć pojedynczych punktów awarii (SPOF) w implementacji. W usłudze Azure Data Explorer wysoka dostępność obejmuje warstwę trwałości, warstwę obliczeniową i konfigurację lidera.

Warstwa trwałości

Usługa Azure Data Explorer korzysta z usługi Azure Storage jako trwałej warstwy trwałości. Usługa Azure Storage automatycznie zapewnia odporność na uszkodzenia, a domyślne ustawienie oferuje magazyn lokalnie nadmiarowy (LRS) w centrum danych. Trzy repliki są utrwalane. Jeśli replika zostanie utracona podczas używania, zostanie wdrożona bez zakłóceń. Dalsza odporność jest możliwa w przypadku magazynu strefowo nadmiarowego (ZRS), który umieszcza repliki inteligentnie w regionalnych strefach dostępności platformy Azure w celu zapewnienia maksymalnej odporności na uszkodzenia po dodatkowym koszcie. Magazyn z włączonym magazynem ZRS jest automatycznie konfigurowany po wdrożeniu klastra usługi Azure Data Explorer w Strefy dostępności.

Warstwa obliczeniowa

Usługa Azure Data Explorer to rozproszona platforma obliczeniowa i może mieć od dwóch do wielu węzłów w zależności od typu roli skalowania i węzła. W czasie aprowizacji wybierz strefy dostępności, aby rozproszyć wdrożenie węzła w różnych strefach w celu zapewnienia maksymalnej odporności wewnątrz regionu. Niepowodzenie strefy dostępności nie spowoduje całkowitej awarii, ale zamiast tego obniżenie wydajności do momentu odzyskania strefy.

Konfiguracja klastra obserwowanego przez lidera

Usługa Azure Data Explorer zapewnia opcjonalną możliwość obserwowania przez klaster liderów, a następnie inne klastry obserwowane w celu uzyskania dostępu tylko do odczytu do danych i metadanych lidera. Zmiany w liderze, takie jak create, appendi drop są automatycznie synchronizowane z obserwowanym. Chociaż liderzy mogą obejmować regiony platformy Azure, następujące klastry powinny być hostowane w tych samych regionach co lider. Jeśli klaster liderów nie działa lub bazy danych lub tabele zostaną przypadkowo porzucone, klastry obserwowane utracą dostęp do momentu odzyskania dostępu do lidera.

Awaria strefy dostępności platformy Azure

Strefy dostępności platformy Azure to unikatowe lokalizacje fizyczne w tym samym regionie świadczenia usługi Azure. Mogą chronić zasoby obliczeniowe i dane klastra usługi Azure Data Explorer przed awarią częściowego regionu. Awaria strefy jest scenariuszem dostępności, ponieważ jest w regionie.

Przypnij klaster usługi Azure Data Explorer do tej samej strefy co inne połączone zasoby platformy Azure. Aby uzyskać więcej informacji na temat włączania stref dostępności, zobacz tworzenie klastra.

Uwaga

Wdrożenie w strefach dostępności jest możliwe podczas tworzenia klastra lub może zostać zmigrowane później.

Awaria centrum danych platformy Azure

Strefy dostępności platformy Azure są dostarczane z kosztami, a niektórzy klienci zdecydują się wdrożyć bez nadmiarowości strefowej. W przypadku takiego wdrożenia usługi Azure Data Explorer awaria centrum danych platformy Azure spowoduje awarię klastra. Obsługa awarii centrum danych platformy Azure jest zatem identyczna z awarią regionu platformy Azure.

Awaria regionu świadczenia usługi Azure

Usługa Azure Data Explorer nie zapewnia automatycznej ochrony przed awarią całego regionu platformy Azure. Aby zminimalizować wpływ biznesowy, jeśli wystąpi taka awaria, wiele klastrów platformy Azure Data Explorer w sparowanych regionach platformy Azure. Na podstawie celu czasu odzyskiwania (RTO), celu punktu odzyskiwania (RPO), a także nakładu pracy i kosztów, istnieje wiele konfiguracji odzyskiwania po awarii. Optymalizacje kosztów i wydajności są możliwe dzięki rekomendacjom usługi Azure Advisor i konfiguracji skalowania automatycznego .

Konfiguracje odzyskiwania po awarii

W tej sekcji przedstawiono wiele konfiguracji odzyskiwania po awarii w zależności od wymagań dotyczących odporności (RPO i RTO), wymaganych wysiłków i kosztów.

Cel czasu odzyskiwania (RTO) odnosi się do czasu odzyskiwania po awarii. Na przykład cel czasu odzyskiwania po 2 godzinach oznacza, że aplikacja musi być uruchomiona w ciągu dwóch godzin od zakłócenia. Cel punktu odzyskiwania (RPO) odnosi się do interwału czasu, który może przechodzić podczas zakłóceń, zanim ilość utraconych danych w tym okresie jest większa niż dozwolony próg. Jeśli na przykład cel punktu odzyskiwania wynosi 24 godziny, a aplikacja ma dane rozpoczynające się od 15 lat temu, są one nadal w parametrach uzgodnionego celu punktu odzyskiwania.

Procesy pozyskiwania, przetwarzania i curation wymagają starannego projektowania z góry podczas planowania odzyskiwania po awarii. Pozyskiwanie odnosi się do danych zintegrowanych z usługą Azure Data Explorer z różnych źródeł; przetwarzanie odnosi się do przekształceń i podobnych działań; curation odnosi się do zmaterializowanych widoków, eksportów do usługi Data Lake itd.

Poniżej przedstawiono popularne konfiguracje odzyskiwania po awarii, a każda z nich została szczegółowo opisana poniżej.

Konfiguracja active-active-active-active

Ta konfiguracja jest również nazywana "always-on". W przypadku krytycznych wdrożeń aplikacji bez tolerancji dla awarii należy użyć wielu klastrów usługi Azure Data Explorer w sparowanych regionach platformy Azure. Skonfiguruj pozyskiwanie, przetwarzanie i curation równolegle do wszystkich klastrów. Jednostka SKU klastra musi być taka sama w różnych regionach. Platforma Azure zapewni, że aktualizacje są wdrażane i skalowane w sparowanych regionach platformy Azure. Awaria regionu platformy Azure nie spowoduje awarii aplikacji. Może wystąpić pewne opóźnienie lub obniżenie wydajności.

Konfiguracja Active-active-active-n.

Konfiguracja Cel punktu odzyskiwania Cel czasu odzyskiwania Nakład pracy Koszty
Active-Active-Active-N 0 godzin 0 godzin Niższa Najwyższy

konfiguracja Active-Active

Ta konfiguracja jest identyczna z konfiguracją active-active-active,ale obejmuje tylko dwa sparowane regiony platformy Azure. Skonfiguruj podwójne pozyskiwanie, przetwarzanie i curation. Użytkownicy są kierowani do najbliższego regionu. Jednostka SKU klastra musi być taka sama w różnych regionach.

Konfiguracja aktywna-aktywna.

Konfiguracja Cel punktu odzyskiwania Cel czasu odzyskiwania Nakład pracy Koszty
Aktywny-aktywny 0 godzin 0 godzin Niższa Wys.

konfiguracja rezerwowa Active-Hot

Konfiguracja Active-Hot jest podobna do konfiguracji Active-Active w podwójnej pozyskiwaniu, przetwarzaniu i curation. Gdy klaster rezerwowy jest w trybie online na potrzeby pozyskiwania, przetwarzania i curation, nie jest dostępny do wykonywania zapytań. Klaster rezerwowy nie musi znajdować się w tej samej jednostce SKU co klaster podstawowy. Może to być mniejsza jednostka SKU i skala, co może spowodować, że jest mniej wydajne. W scenariuszu awarii użytkownicy są przekierowywani do klastra rezerwowego, który opcjonalnie można skalować w górę, aby zwiększyć wydajność.

Konfiguracja rezerwy aktywnej na gorąco.

Konfiguracja Cel punktu odzyskiwania Cel czasu odzyskiwania Nakład pracy Koszty
Rezerwa aktywna-gorąca 0 godzin Niski Średnia Średnia

Konfiguracja odzyskiwania danych na żądanie

To rozwiązanie oferuje najmniejszą odporność (najwyższy cel punktu odzyskiwania i cel punktu odzyskiwania), jest najniższym kosztem i najwyższym nakładem pracy. W tej konfiguracji nie ma klastra odzyskiwania danych. Skonfiguruj ciągły eksport wyselekcjonowanych danych (chyba że wymagane są również nieprzetworzone i pośrednie dane) na koncie magazynu skonfigurowanego magazynu GRS (magazyn geograficznie nadmiarowy). Klaster odzyskiwania danych jest inicjowany, jeśli istnieje scenariusz odzyskiwania po awarii. W tym czasie są stosowane listy DDLs, konfiguracja, zasady i procesy. Dane są pozyskiwane z magazynu z właściwością pozyskiwania kustoCreationTime , aby przejeżdżać czas pozyskiwania, który jest domyślnie domyślny dla czasu systemowego.

Konfiguracja klastra odzyskiwania danych na żądanie.

Konfiguracja Cel punktu odzyskiwania Cel czasu odzyskiwania Nakład pracy Koszty
Klaster odzyskiwania danych na żądanie Najwyższy Najwyższy Najwyższy Najniższej

Podsumowanie opcji konfiguracji odzyskiwania po awarii

Konfiguracja Odporność Cel punktu odzyskiwania Cel czasu odzyskiwania Nakład pracy Koszty
Active-Active-Active-N Najwyższy 0 godzin 0 godzin Niższa Najwyższy
Aktywny-aktywny Wys. 0 godzin 0 godzin Niższa Wys.
Rezerwa aktywna-gorąca Śred. 0 godzin Niski Średnia Średnia
Klaster odzyskiwania danych na żądanie Najniższej Najwyższy Najwyższy Najwyższy Najniższej

Najlepsze rozwiązania

Niezależnie od wybranej konfiguracji odzyskiwania po awarii wykonaj następujące najlepsze rozwiązania:

  • Wszystkie obiekty bazy danych, zasady i konfiguracje powinny być utrwalane w kontroli źródła, aby można było je zwolnić do klastra z narzędzia automatyzacji wydania. Aby uzyskać więcej informacji, zobacz Obsługa usługi Azure DevOps dla usługi Azure Data Explorer.
  • Projektowanie, opracowywanie i implementowanie procedur weryfikacji w celu zapewnienia synchronizacji wszystkich klastrów z perspektywy danych. Usługa Azure Data Explorer obsługuje sprzężenia między klastrami. Prosta liczba lub wiersze między tabelami mogą pomóc w zweryfikowaniu.
  • Procedury wydawania powinny obejmować kontrole ładu i salda, które zapewniają dublowanie klastrów.
  • Bądź w pełni świadomi tego, co potrzeba do utworzenia klastra od podstaw.
  • Utwórz listę kontrolną jednostek wdrażania. Lista będzie unikatowa dla Twoich potrzeb, ale powinna zawierać: skrypty wdrażania, połączenia pozyskiwania, narzędzia analizy biznesowej i inne ważne konfiguracje.

Następny krok

Tworzenie rozwiązań do zapewnienia ciągłości działania i odzyskiwania po awarii