Dela via

Tillförlitlighet i Azure HDInsight

  • Artikel

Den här artikeln beskriver tillförlitlighetsstöd i Azure HDInsight och omfattar tillgänglighetszoner och återställning mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitligheten i Azure finns i Azures tillförlitlighet.

Stöd för tillgänglighetszon

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Mer information om tillgänglighetszoner i Azure finns i Vad är tillgänglighetszoner?.

Azure HDInsight stöder en zonindelad distributionskonfiguration. Azure HDInsight-klusternoder placeras i en enda zon som du väljer i den valda regionen. Ett zonindelade HDInsight-kluster är isolerat från eventuella avbrott som inträffar i andra zoner. Men om ett avbrott påverkar den specifika zon som valts för HDInsight-klustret blir klustret inte tillgängligt. Den här distributionsmodellen ger billig nätverksanslutning med låg svarstid i klustret. Att replikera den här distributionsmodellen till flera tillgänglighetszoner kan ge en högre tillgänglighetsnivå för att skydda mot maskinvarufel.

Viktigt!

För distributioner där användare inte anger en specifik zon är nodtyperna inte zontåliga och kan uppleva avbrott under ett avbrott i en zon i den regionen.

Förutsättningar

  • Tillgänglighetszoner stöds endast för kluster som skapats efter den 15 juni 2023. Inställningar för tillgänglighetszoner kan inte uppdateras när klustret har skapats. Du kan inte heller uppdatera ett befintligt, icke-tillgänglighetszonkluster för att använda tillgänglighetszoner.

  • Kluster måste skapas under ett anpassat virtuellt nätverk.

  • Du måste ta med din egen SQL DB för Ambari DB och externt metaarkiv, till exempel Hive-metaarkiv, så att du kan konfigurera dessa DATABASER i samma tillgänglighetszon.

  • Dina HDInsight-kluster måste skapas med alternativet tillgänglighetszon i någon av följande regioner:

    • Australien, östra
    • Brasilien, södra
    • Kanada, centrala
    • Central US
    • East US
    • USA, östra 2
    • Frankrike, centrala
    • Tyskland, västra centrala
    • Japan, östra
    • Sydkorea, centrala
    • Europa, norra
    • Qatar, centrala
    • Sydostasien
    • USA, södra centrala
    • Södra Storbritannien
    • US Gov, Virginia
    • Västeuropa
    • Västra USA 2

Skapa ett HDInsight-kluster med hjälp av tillgänglighetszonen

Du kan använda EN ARM-mall (Azure Resource Manager) för att starta ett HDInsight-kluster i en angiven tillgänglighetszon.

I avsnittet resurser måste du lägga till ett avsnitt av "zoner" och ange vilken tillgänglighetszon du vill att klustret ska distribueras till.

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

Verifiera noder i en tillgänglighetszon mellan zoner

När HDInsight-klustret är klart kan du kontrollera platsen för att se vilken tillgänglighetszon de distribueras i.

Skärmbild som visar information om tillgänglighetszoner i klusteröversikt.

Hämta API-svar:

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

Skala upp klustret

Du kan skala upp ett HDInsight-kluster med fler arbetsnoder. De nyligen tillagda arbetsnoderna placeras i samma tillgänglighetszon i det här klustret.

Migrering av tillgänglighetszon

Azure HDInsight-kluster stöder för närvarande inte migrering på plats av befintliga klusterinstanser till stöd för tillgänglighetszoner. Du kan dock välja att återskapa klustret och välja en annan tillgänglighetszon eller region när klustret skapas. Ett sekundärt väntelägeskluster i en annan region och en annan tillgänglighetszon kan användas i haveriberedskapsscenarier.

Zon-ned-upplevelse

När en tillgänglighetszon slutar fungera:

  • Du kan inte ssh till det här klustret.
  • Du kan inte ta bort eller skala upp eller skala ned det här klustret.
  • Du kan inte skicka jobb eller se jobbhistorik.
  • Du kan fortfarande skicka en begäran om att skapa nya kluster i en annan region.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

Azure HDInsight-kluster är beroende av många Azure-tjänster som lagring, databaser, Active Directory, Active Directory-domän Services, nätverk och Key Vault. Ett väl utformat, högtillgängligt och feltolerant analysprogram bör utformas med tillräcklig redundans för att klara regionala eller lokala störningar i en eller flera av dessa tjänster. Det här avsnittet ger en översikt över metodtips, tillgänglighet för enskilda regioner och flera regioner samt optimeringsalternativ för planering av affärskontinuitet.

Haveriberedskap i geografi för flera regioner

För att förbättra affärskontinuiteten med haveriberedskap mellan regioner krävs arkitekturdesign med högre komplexitet och högre kostnader. I följande tabeller beskrivs några tekniska områden som kan öka den totala ägandekostnaden.

Kostnadsoptimeringar

Ytdiagram Orsak till kostnadseskalering Optimeringsstrategier
Datalagring Duplicera primära data/tabeller i en sekundär region Replikera endast kurerade data
Utgående data Utgående dataöverföringar mellan regioner har ett pris. Granska riktlinjerna för bandbreddspriser Replikera endast kurerade data för att minska regionens utgående fotavtryck
Klusterberäkning Ytterligare HDInsight-kluster/s i sekundär region Använd automatiserade skript för att distribuera sekundär beräkning efter primärt fel. Använd Autoskalning för att hålla den sekundära klusterstorleken till ett minimum. Använd billigare VM-SKU:er. Skapa sekundärfiler i regioner där VM-SKU:er kan rabatteras.
Autentisering Scenarier med flera användare i den sekundära regionen medför extra Installationer av Microsoft Entra Domain Services Undvik installationer av fleraanvändare i den sekundära regionen.

Komplexitetsoptimeringar

Ytdiagram Orsak till komplexitetseskalering Optimeringsstrategier
Läs skrivningsmönster Kräver att både primär och sekundär är läs- och skrivaktiverad Utforma den sekundära så att den är skrivskyddad
Noll RPO och RTO Kräver noll dataförlust (RPO=0) och noll stilleståndstid (RTO=0) Utforma RPO och RTO på ett sätt som minskar antalet komponenter som behöver redundansväxla. Mer information om RTO och RPO finns i Återställningsmål.
Affärsfunktion Kräver fullständig affärsfunktionalitet för primär i sekundär Utvärdera om du kan köra med den minsta kritiska delmängden av affärsfunktionerna i sekundär.
Anslutning Kräver att alla överordnade och underordnade system från primärt ansluter till den sekundära samt Begränsa den sekundära anslutningen till en minsta kritisk delmängd.

När du skapar en haveriberedskapsplan för flera regioner bör du överväga följande rekommendationer:

  • Fastställ den minimala affärsfunktion du behöver om det uppstår en katastrof och varför. Du kan till exempel utvärdera om du behöver redundansfunktioner för datatransformeringslagret (visas i gult) och dataserverlagret (visas i blått) eller om du bara behöver redundans för datatjänstlagret.

    datatransformerings- och databetjäningslager

  • Segmentera dina kluster baserat på arbetsbelastning, utvecklingslivscykel och avdelningar. Att ha fler kluster minskar risken för ett enda stort fel som påverkar flera olika affärsprocesser.

  • Gör dina sekundära regioner skrivskyddade. Redundansregioner med både läs- och skrivfunktioner kan leda till komplexa arkitekturer.

  • Tillfälliga kluster är enklare att hantera när det uppstår en katastrof. Utforma dina arbetsbelastningar på ett sätt som kluster kan växlas och inget tillstånd underhålls i kluster.

  • Ofta lämnas arbetsbelastningar oavslutade om det uppstår ett haveri och behöver startas om i den nya regionen. Utforma dina arbetsbelastningar så att de är idempotent till sin natur.

  • Använd automatisering under klusterdistributioner och se till att klusterkonfigurationsinställningarna är skriptade så långt som möjligt för att säkerställa snabb och helt automatiserad distribution om det uppstår en katastrof.

Identifiering, avisering och hantering av avbrott

  • Använd Azure-övervakningsverktyg i HDInsight för att identifiera onormalt beteende i klustret och ange motsvarande aviseringsmeddelanden. Du kan distribuera de förkonfigurerade HDInsight-klusterspecifika hanteringslösningarna som samlar in viktiga prestandamått av den specifika klustertypen. Mer information finns i Azure Monitoring for HDInsight.

  • Prenumerera på Azure-hälsoaviseringar som ska meddelas om tjänstproblem, planerat underhåll, hälso- och säkerhetsrekommendationer för en prenumeration, tjänst eller region. Hälsomeddelanden som innehåller orsaken till problemet och resolut ETA hjälper dig att bättre köra redundans och återställning efter fel. Mer information finns i Dokumentation om Azure Service Health.

Haveriberedskap i geografi för en region

Varje komponent i ett grundläggande HDInsight-system har sina egna mekanismer för feltolerans för en enda region. Tänk på att det inte alltid krävs en katastrofal händelse för att påverka affärsfunktionerna. Tjänstincidenter i en eller flera av följande tjänster i en enda region kan också leda till förlust av förväntade affärsfunktioner.

  • Beräkning (virtuella datorer): Azure HDInsight-kluster. HDInsight erbjuder ett serviceavtal för tillgänglighet på 99,9 %. För att tillhandahålla hög tillgänglighet i en enda distribution åtföljs HDInsight av många tjänster som är i läget för hög tillgänglighet som standard. Mekanismer för feltolerans i HDInsight tillhandahålls av både Microsofts och Apache OSS-ekosystemens tjänster för hög tillgänglighet.

    Följande infrastrukturkomponenter är utformade för att vara mycket tillgängliga:

    • Aktiva och väntelägeshuvudnoder
    • Flera gatewaynoder
    • Tre Zookeeper Quorum-noder
    • Arbetsnoder som distribueras av fel- och uppdateringsdomäner

    Följande tjänster är också utformade för att vara mycket tillgängliga:

    • Apache Ambari Server
    • Programtidslinje för YARN
    • Jobbhistorikserver för Hadoop MapReduce
    • Apache Livy
    • HDFS
    • YARN Resource Manager
    • HBase-huvud

    Mer information finns i tjänster med hög tillgänglighet som stöds av Azure HDInsight.

  • Metaarkiv: Azure SQL Database. HDInsight använder Azure SQL Database som ett metaarkiv, vilket ger ett serviceavtal på 99,99 %. Tre datarepliker bevaras i ett datacenter med synkron replikering. Om det uppstår en replikförlust hanteras en alternativ replik sömlöst. Aktiv geo-replikering stöds direkt med högst fyra datacenter. När det sker en redundansväxling, antingen manuellt eller i datacenter, blir den första repliken i hierarkin automatiskt läs- och skrivkompatibel. Mer information finns i Affärskontinuitet i Azure SQL Database.

  • Lagring: Azure Data Lake Gen2 eller Blob Storage. HDInsight rekommenderar Azure Data Lake Storage Gen2 som det underliggande lagringslagret. Azure Storage, inklusive Azure Data Lake Storage Gen2, tillhandahåller ett serviceavtal på 99,9 %. HDInsight använder LRS-tjänsten där tre datarepliker bevaras i ett datacenter och replikeringen är synkron. När det uppstår en replikförlust hanteras en replik sömlöst.

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

  • Valfria tjänster, till exempel Azure Key Vault och Azure Data Factory.

HDInsight-komponenter

Relaterat innehåll