Udostępnij za pośrednictwem

Niezawodność w usłudze Azure HDInsight

  • Artykuł

W tym artykule opisano obsługę niezawodności w usłudze Azure HDInsight oraz omówiono strefy dostępności oraz odzyskiwanie między regionami i ciągłość działalności biznesowej. Aby uzyskać bardziej szczegółowe omówienie niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.

Obsługa strefy dostępności

Strefy dostępności platformy Azure to co najmniej trzy fizycznie oddzielne grupy centrów danych w każdym regionie świadczenia usługi Azure. Centra danych w każdej strefie są wyposażone w niezależną infrastrukturę zasilania, chłodzenia i sieci. W przypadku awarii strefy lokalnej strefy strefy dostępności są zaprojektowane tak, aby w przypadku wystąpienia problemu z jedną strefą usługi regionalne, pojemność i wysoka dostępność są obsługiwane przez pozostałe dwie strefy.

Awarie mogą wahać się od awarii oprogramowania i sprzętu po zdarzenia, takie jak trzęsienia ziemi, powodzie i pożary. Tolerancja awarii jest osiągana z nadmiarowością i logiczną izolacją usług platformy Azure. Aby uzyskać bardziej szczegółowe informacje na temat stref dostępności na platformie Azure, zobacz Regiony i strefy dostępności.

Usługi z obsługą stref dostępności platformy Azure zostały zaprojektowane w celu zapewnienia odpowiedniego poziomu niezawodności i elastyczności. Można je skonfigurować na dwa sposoby. Mogą być strefowo nadmiarowe, z automatyczną replikacją między strefami lub strefami, z wystąpieniami przypiętymi do określonej strefy. Możesz również połączyć te podejścia. Aby uzyskać więcej informacji na temat architektury strefowej i strefowo nadmiarowej, zobacz Rekomendacje na potrzeby korzystania ze stref dostępności i regionów.

Usługa Azure HDInsight obsługuje konfigurację wdrożenia strefowego. Węzły klastra usługi Azure HDInsight są umieszczane w jednej strefie wybranej w wybranym regionie. Strefowy klaster usługi HDInsight jest odizolowany od wszelkich awarii występujących w innych strefach. Jeśli jednak awaria wpłynie na konkretną strefę wybraną dla klastra usługi HDInsight, klaster nie będzie dostępny. Ten model wdrażania zapewnia niedrogie, małe opóźnienia łączności sieciowej w klastrze. Replikowanie tego modelu wdrażania do wielu stref dostępności może zapewnić wyższy poziom dostępności w celu ochrony przed awariami sprzętowymi.

Ważne

W przypadku wdrożeń, w których użytkownicy nie określają określonej strefy, typy węzłów nie są odporne na strefy i mogą wystąpić przestoje podczas przestoju w dowolnej strefie w tym regionie.

Wymagania wstępne

  • Strefy dostępności są obsługiwane tylko w przypadku klastrów utworzonych po 15 czerwca 2023 r. Nie można zaktualizować ustawień strefy dostępności po utworzeniu klastra. Nie można również zaktualizować istniejącego klastra strefy niedostępnej w celu korzystania ze stref dostępności.

  • Klastry muszą być tworzone w ramach niestandardowej sieci wirtualnej.

  • Musisz przenieść własną bazę danych SQL db dla bazy danych Ambari i zewnętrznego magazynu metadanych, takiego jak magazyn metadanych Hive, aby można było skonfigurować te bazy danych w tej samej strefie dostępności.

  • Klastry usługi HDInsight należy utworzyć z opcją strefy dostępności w jednym z następujących regionów:

    • Australia Wschodnia
    • Brazylia Południowa
    • Kanada Środkowa
    • Central US
    • East US
    • Wschodnie stany USA 2
    • Francja Środkowa
    • Niemcy Środkowo-Zachodnie
    • Japonia Wschodnia
    • Korea Środkowa
    • Europa Północna
    • Katar Środkowy
    • Southeast Asia
    • South Central US
    • Południowe Zjednoczone Królestwo
    • US Gov Wirginia
    • West Europe
    • Zachodnie stany USA 2

Tworzenie klastra usługi HDInsight przy użyciu strefy dostępności

Szablon usługi Azure Resource Manager (ARM) umożliwia uruchomienie klastra usługi HDInsight w określonej strefie dostępności.

W sekcji resources (zasoby) należy dodać sekcję "zones" (strefy) i określić strefę dostępności, do której ma zostać wdrożony ten klaster.

   "resources": [
        {
            "type": "Microsoft.HDInsight/clusters",
            "apiVersion": "2021-06-01",
            "name": "[parameters('cluster name')]",
            "location": "East US 2",
            "zones": [
                "1"
            ],
        }
   ]

Weryfikowanie węzłów w jednej strefie dostępności między strefami

Gdy klaster usługi HDInsight jest gotowy, możesz sprawdzić lokalizację, aby sprawdzić, w której strefie dostępności są one wdrażane.

Zrzut ekranu przedstawiający informacje o strefie dostępności w przeglądzie klastra.

Uzyskiwanie odpowiedzi interfejsu API:

 [
        {
            "location": "East US 2",
            "zones": [
                "1"
            ],
        }
 ]

Skalowanie klastra w górę

Klaster usługi HDInsight można skalować w górę przy użyciu większej liczby węzłów roboczych. Nowo dodane węzły robocze zostaną umieszczone w tej samej strefie dostępności tego klastra.

Migracja strefy dostępności

Klastry usługi Azure HDInsight obecnie nie obsługują migracji istniejących wystąpień klastra do obsługi stref dostępności. Można jednak ponownie utworzyć klaster i wybrać inną strefę dostępności lub region podczas tworzenia klastra. Pomocniczy klaster rezerwowy w innym regionie i inną strefę dostępności można używać w scenariuszach odzyskiwania po awarii.

Środowisko strefowe w dół

Gdy strefa dostępności ulegnie awarii:

  • Nie można połączyć się z tym klastrem za pomocą protokołu SSH.
  • Nie można usunąć ani skalować w górę ani skalować w dół tego klastra.
  • Nie można przesyłać zadań ani wyświetlać historii zadań.
  • Nadal możesz przesłać nowe żądanie utworzenia klastra w innym regionie.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii dotyczy odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Rekomendacje na potrzeby projektowania strategii odzyskiwania po awarii.

Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania planu odzyskiwania po awarii.

Klastry usługi Azure HDInsight zależą od wielu usług platformy Azure, takich jak magazyn, bazy danych, usługa Active Directory, usługi domena usługi Active Directory, sieć i usługa Key Vault. Dobrze zaprojektowana, wysoce dostępna i odporna na uszkodzenia aplikacja analityczna powinna być zaprojektowana z wystarczającą nadmiarowością, aby wytrzymać regionalne lub lokalne zakłócenia w co najmniej jednej z tych usług. Ta sekcja zawiera omówienie najlepszych rozwiązań, dostępności pojedynczego i wielu regionów oraz opcji optymalizacji planowania ciągłości działania.

Odzyskiwanie po awarii w lokalizacji geograficznej obejmującej wiele regionów

Zwiększenie ciągłości działalności biznesowej przy użyciu odzyskiwania po awarii o wysokiej dostępności między regionami wymaga projektów architektury o większej złożoności i wyższych kosztach. W poniższych tabelach opisano niektóre obszary techniczne, które mogą zwiększyć całkowity koszt posiadania.

Optymalizacje kosztów

Obszar Przyczyna eskalacji kosztów Strategie optymalizacji
Magazyn danych Duplikowanie podstawowych danych/tabel w regionie pomocniczym Replikowanie tylko wyselekcjonowanych danych
Ruch wychodzący danych Transfery danych wychodzących między regionami są dostępne w cenie. Zapoznaj się z wytycznymi dotyczącymi cen przepustowości Replikowanie tylko wyselekcjonowanych danych w celu zmniejszenia zużycia ruchu wychodzącego w regionie
Obliczenia klastra Dodatkowy klaster/s usługi HDInsight w regionie pomocniczym Użyj zautomatyzowanych skryptów, aby wdrożyć pomocnicze zasoby obliczeniowe po awarii podstawowej. Użyj skalowania automatycznego, aby zachować minimalny rozmiar klastra pomocniczego. Użyj tańszych jednostek SKU maszyn wirtualnych. Utwórz pomocnicze w regionach, w których jednostki SKU maszyn wirtualnych mogą być dyskontowane.
Uwierzytelnianie Scenariusze z wieloma użytkownikami w regionie pomocniczym powodują dodatkowe konfiguracje usług Microsoft Entra Domain Services Unikaj konfiguracji wielu użytkowników w regionie pomocniczym.

Optymalizacje złożoności

Obszar Przyczyna eskalacji złożoności Strategie optymalizacji
Odczytywanie wzorców zapisu Wymaganie włączenia odczytu i zapisu zarówno podstawowego, jak i pomocniczego Projektowanie pomocniczego jako tylko do odczytu
Zero celu punktu odzyskiwania i celu punktu odzyskiwania Wymaganie zerowej utraty danych (RPO=0) i zerowego przestoju (RTO=0) Zaprojektuj cel punktu odzyskiwania i cel czasu odzyskiwania w celu zmniejszenia liczby składników, które muszą przejść w tryb failover. Aby uzyskać więcej informacji na temat celu odzyskiwania i celu punktu odzyskiwania, zobacz Cele odzyskiwania.
Funkcje biznesowe Wymaganie pełnej funkcjonalności biznesowej podstawowej w pomocniczej wersji Oceń, czy można uruchomić z minimalnym krytycznym podzbiorem funkcjonalności biznesowej w pomocniczej wersji.
Łączność Wymaganie, aby wszystkie systemy nadrzędne i podrzędne z podstawowego łączyły się z pomocniczym, jak również Ogranicz łączność pomocniczą z minimalnym podzestawem krytycznym.

Podczas tworzenia planu odzyskiwania po awarii w wielu regionach należy wziąć pod uwagę następujące zalecenia:

  • Określ minimalną funkcjonalność biznesową, której potrzebujesz, jeśli wystąpi awaria i dlaczego. Na przykład oceń, czy potrzebujesz możliwości trybu failover dla warstwy przekształcania danych (pokazanej na żółtym) i warstwie obsługującej dane (pokazanej na niebiesko) lub jeśli potrzebujesz tylko trybu failover dla warstwy usługi danych.

    przekształcanie danych i warstwy obsługujące dane

  • Segmentuj klastry na podstawie obciążenia, cyklu projektowania i działów. Posiadanie większej liczby klastrów zmniejsza prawdopodobieństwo wystąpienia pojedynczego dużego błędu wpływającego na wiele różnych procesów biznesowych.

  • Ustaw regiony pomocnicze tylko do odczytu. Regiony trybu failover z możliwościami odczytu i zapisu mogą prowadzić do złożonych architektur.

  • Klastry przejściowe są łatwiejsze do zarządzania w przypadku awarii. Zaprojektuj obciążenia w taki sposób, aby klastry mogły być cyklowane i nie są przechowywane w klastrach.

  • Często obciążenia pozostają niedokończone w przypadku awarii i konieczności ponownego uruchomienia w nowym regionie. Zaprojektuj obciążenia jako idempotentne w naturze.

  • Użyj automatyzacji podczas wdrożeń klastra i upewnij się, że ustawienia konfiguracji klastra są skrypty tak daleko, jak to możliwe, aby zapewnić szybkie i w pełni zautomatyzowane wdrażanie, jeśli wystąpi awaria.

Wykrywanie, powiadamianie i zarządzanie awariami

  • Użyj narzędzi do monitorowania platformy Azure w usłudze HDInsight, aby wykryć nietypowe zachowanie w klastrze i ustawić odpowiednie powiadomienia o alertach. Możesz wdrożyć wstępnie skonfigurowane rozwiązania do zarządzania specyficzne dla klastra usługi HDInsight, które zbierają ważne metryki wydajności określonego typu klastra. Aby uzyskać więcej informacji, zobacz Azure Monitoring for HDInsight (Monitorowanie platformy Azure dla usługi HDInsight).

  • Subskrybuj alerty dotyczące kondycji platformy Azure, aby otrzymywać powiadomienia o problemach z usługą, planowanej konserwacji, kondycji i biuletynach zabezpieczeń dla subskrypcji, usługi lub regionu. Powiadomienia o kondycji, które obejmują przyczynę problemu i zdecydowaną ETA, pomagają lepiej wykonywać tryb failover i powroty po awarii. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Service Health.

Odzyskiwanie po awarii w lokalizacji geograficznej z jednym regionem

Każdy składnik w podstawowym systemie usługi HDInsight ma własne mechanizmy odporności na uszkodzenia w jednym regionie. Należy pamiętać, że nie zawsze ma katastrofalne zdarzenie, aby wpłynąć na funkcjonalność biznesową. Zdarzenia usługi w co najmniej jednej z następujących usług w jednym regionie mogą również prowadzić do utraty oczekiwanych funkcji biznesowych.

  • Obliczenia (maszyny wirtualne): klaster usługi Azure HDInsight. Usługa HDInsight oferuje umowę SLA dostępności na 99,9%. Aby zapewnić wysoką dostępność w jednym wdrożeniu, usługa HDInsight jest domyślnie dołączona do wielu usług, które są w trybie wysokiej dostępności. Mechanizmy odporności na uszkodzenia w usłudze HDInsight są udostępniane zarówno przez usługi firmy Microsoft, jak i apache OSS ekosystem wysokiej dostępności.

    Następujące składniki infrastruktury zostały zaprojektowane pod kątem wysokiej dostępności:

    • Aktywne i rezerwowe węzły główne
    • Wiele węzłów bramy
    • Trzy węzły kworum dozorcy
    • Węzły procesu roboczego dystrybuowane przez domeny błędów i aktualizacji

    Następujące usługi są również zaprojektowane pod kątem wysokiej dostępności:

    • Serwer Apache Ambari
    • Serwer osi czasu aplikacji dla usługi YARN
    • Serwer historii zadań dla usługi Hadoop MapReduce
    • Apache Livy
    • SYSTEM PLIKÓW HDFS
    • YARN Resource Manager
    • Wzorzec bazy danych HBase

    Aby dowiedzieć się więcej, zobacz usługi wysokiej dostępności obsługiwane przez usługę Azure HDInsight.

  • Magazyny metadanych: Azure SQL Database. Usługa HDInsight używa usługi Azure SQL Database jako magazynu metadanych, który zapewnia umowę SLA na 99,99%. Trzy repliki danych są utrwalane w centrum danych z replikacją synchroniczną. Jeśli wystąpi utrata repliki, replika alternatywna jest obsługiwana bezproblemowo. Aktywna replikacja geograficzna jest obsługiwana poza ramką z maksymalnie czterema centrami danych. W przypadku przejścia w tryb failover , ręcznego lub centrum danych pierwsza replika w hierarchii automatycznie staje się w stanie odczytywać i zapisywać. Aby uzyskać więcej informacji, zobacz Ciągłość działalności biznesowej usługi Azure SQL Database.

  • Magazyn: Azure Data Lake Gen2 lub Blob Storage. Usługa HDInsight zaleca usługę Azure Data Lake Storage Gen2 jako podstawową warstwę magazynu. Usługa Azure Storage, w tym usługa Azure Data Lake Storage Gen2, zapewnia umowę SLA na 99,9%. Usługa HDInsight używa usługi LRS, w której trzy repliki danych są utrwalane w centrum danych, a replikacja jest synchroniczna. W przypadku utraty repliki replika jest obsługiwana bezproblemowo.

  • Uwierzytelnianie: Microsoft Entra ID, Microsoft Entra Domain Services, Enterprise Security Package.

  • Opcjonalne usługi, takie jak Azure Key Vault i Azure Data Factory.

Składniki usługi HDInsight

Powiązana zawartość