Udostępnij za pośrednictwem

Analiza przypadku architektury rozwiązania o wysokiej dostępności w usłudze Azure HDInsight

  • Artykuł

Mechanizmy replikacji usługi Azure HDInsight można zintegrować z architekturą rozwiązania o wysokiej dostępności. W tym artykule fikcyjne badanie przypadku dla firmy Contoso Retail służy do wyjaśnienia możliwych podejść odzyskiwania po awarii o wysokiej dostępności, zagadnień dotyczących kosztów i odpowiednich projektów.

Rekomendacje dotyczące odzyskiwania po awarii o wysokiej dostępności mogą mieć wiele permutacji i kombinacji. Te rozwiązania mają zostać dostarczone po zapoznaniu się z zaletami i wadami każdej opcji. W tym artykule omówiono tylko jedno możliwe rozwiązanie.

Architektura klienta

Na poniższej ilustracji przedstawiono podstawową architekturę firmy Contoso Retail. Architektura składa się z obciążenia przesyłania strumieniowego, obciążenia wsadowego, obsługi warstwy, warstwy zużycia, warstwy magazynu i kontroli wersji.

Contoso Retail architecture.

Obciążenie przesyłania strumieniowego

Urządzenia i czujniki tworzą dane w usłudze HDInsight Kafka, która stanowi platformę obsługi komunikatów. Użytkownik platformy Spark usługi HDInsight odczytuje z tematów platformy Kafka. Platforma Spark przekształca komunikaty przychodzące i zapisuje je w klastrze HBase usługi HDInsight w warstwie obsługującej.

Obciążenie wsadowe

Klaster hadoop usługi HDInsight z uruchomionym programem Hive i usługą MapReduce pozyskuje dane z lokalnych systemów transakcyjnych. Nieprzetworzone dane przekształcone przez hive i MapReduce są przechowywane w tabelach hive na partycji logicznej magazynu typu data lake wspieranego przez usługę Azure Data Lake Storage Gen2. Dane przechowywane w tabelach Programu Hive są również udostępniane usłudze Spark SQL, która przekształca dane wsadowe przed zapisanie wyselekcjonowanych danych w bazie HBase na potrzeby obsługi.

Warstwa obsługująca

Klaster HBase usługi HDInsight z usługą Apache Phoenix służy do udostępniania danych aplikacjom internetowym i pulpitom nawigacyjnym wizualizacji. Klaster LLAP usługi HDInsight służy do spełnienia wymagań wewnętrznych raportowania.

Warstwa zużycia

Usługa Azure API Apps i warstwa usługi API Management z powrotem publiczną stronę internetową. Wewnętrzne wymagania dotyczące raportowania są spełnione przez usługę Power BI.

Warstwa magazynu

Logicznie podzielone na partycje usługi Azure Data Lake Storage Gen2 są używane jako magazyn data lake przedsiębiorstwa. Magazyny metadanych usługi HDInsight są wspierane przez usługę Azure SQL DB.

Wersja systemu kontroli źródła

System kontroli wersji zintegrowany z usługą Azure Pipelines i hostowany poza platformą Azure.

Wymagania dotyczące ciągłości działania klienta

Ważne jest, aby określić minimalną funkcjonalność biznesową, której potrzebujesz, jeśli wystąpi awaria.

Wymagania dotyczące ciągłości działania firmy Contoso Retail

  • Musimy być chronieni przed awarią regionalną lub problemem z kondycją usługi regionalnej.
  • Moi klienci nigdy nie muszą widzieć błędu 404. Zawartość publiczna musi być zawsze obsługiwana. (Cel czasu odzyskiwania = 0)
  • W większości lat możemy pokazać zawartość publiczną, która jest nieaktualna o 5 godzin. (Cel punktu odzyskiwania = 5 godzin)
  • W okresie świątecznym nasza publiczna zawartość musi być zawsze aktualna. (Cel punktu odzyskiwania = 0)
  • Moje wewnętrzne wymagania dotyczące raportowania nie są uważane za krytyczne dla ciągłości działania.
  • Optymalizowanie kosztów ciągłości działania.

Proponowane rozwiązanie

Na poniższej ilustracji przedstawiono architekturę odzyskiwania po awarii wysokiej dostępności firmy Contoso Retail.

Contoso solution.

Platforma Kafka używa replikacji aktywnej — pasywnej do dublowania tematów platformy Kafka z regionu podstawowego do regionu pomocniczego. Alternatywą dla replikacji platformy Kafka może być utworzenie na platformie Kafka w obu regionach.

Usługi Hive i Spark używają aktywnych modeli replikacji podstawowej — pomocniczej na żądanie w normalnych czasach. Proces replikacji programu Hive jest okresowo uruchamiany i towarzyszy replikacji magazynu metadanych Azure SQL hive i konta magazynu Hive. Konto magazynu platformy Spark jest okresowo replikowane przy użyciu narzędzia ADF DistCP. Przejściowy charakter tych klastrów pomaga zoptymalizować koszty. Replikacje są zaplanowane co 4 godziny, aby dotrzeć do celu punktu odzyskiwania, który jest dobrze w ciągu pięciu godzin.

Replikacja bazy danych HBase używa modelu Leader — Follower w normalnych czasach, aby upewnić się, że dane są zawsze obsługiwane niezależnie od regionu, a cel punktu odzyskiwania jest bardzo niski.

Jeśli w regionie podstawowym wystąpi awaria regionalna, strona internetowa i zawartość zaplecza są obsługiwane z regionu pomocniczego przez 5 godzin z pewnym stopniem nieaktualności. Jeśli pulpit nawigacyjny kondycji usługi platformy Azure nie wskazuje wartości ETA odzyskiwania w pięciogodzinnym oknie, firma Contoso Retail utworzy warstwę transformacji Hive i Spark w regionie pomocniczym, a następnie wskaże wszystkie nadrzędne źródła danych do regionu pomocniczego. Tworzenie zapisu w regionie pomocniczym spowodowałoby proces powrotu po awarii, który obejmuje replikację z powrotem do podstawowego.

Podczas szczytowego sezonu zakupów cały pomocniczy potok jest zawsze aktywny i działa. Producenci platformy Kafka tworzą produkty w obu regionach, a replikacja bazy danych HBase zostałaby zmieniona z Leader-Follower na Leader-Leader, aby zapewnić, że zawartość publiczna jest zawsze aktualna.

Nie trzeba projektować rozwiązania trybu failover na potrzeby raportowania wewnętrznego, ponieważ nie ma krytycznego wpływu na ciągłość działalności biznesowej.

Następne kroki

Aby dowiedzieć się więcej o elementach omówionych w tym artykule, zobacz: