Delen via

Betrouwbaarheid in Azure HDInsight

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure HDInsight beschreven en worden beschikbaarheidszones en herstel in meerdere regio's en bedrijfscontinuïteit behandeld. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.

Ondersteuning voor beschikbaarheidszones

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure HDInsight ondersteunt een zonegebonden implementatieconfiguratie. Azure HDInsight-clusterknooppunten worden in één zone geplaatst die u selecteert in de geselecteerde regio. Een zonegebonden HDInsight-cluster is geïsoleerd van storingen die zich in andere zones voordoen. Als een storing echter van invloed is op de specifieke zone die is gekozen voor het HDInsight-cluster, is het cluster niet beschikbaar. Dit implementatiemodel biedt goedkope netwerkconnectiviteit met lage latentie binnen het cluster. Het repliceren van dit implementatiemodel in meerdere beschikbaarheidszones kan een hoger beschikbaarheidsniveau bieden om te beschermen tegen hardwarefouten.

Belangrijk

Voor implementaties waarbij gebruikers geen specifieke zone opgeven, zijn knooppunttypen niet zonebestendig en kunnen er downtime optreden tijdens een storing in een zone in die regio.

Vereiste voorwaarden

  • Beschikbaarheidszones worden alleen ondersteund voor clusters die zijn gemaakt na 15 juni 2023. Instellingen voor beschikbaarheidszones kunnen niet worden bijgewerkt nadat het cluster is gemaakt. U kunt ook geen bestaand cluster met een niet-beschikbaarheidszone bijwerken om beschikbaarheidszones te gebruiken.

  • Clusters moeten worden gemaakt onder een aangepast VNet.

  • U moet uw eigen SQL DB voor Ambari DB en externe metastore, zoals Hive-metastore, gebruiken, zodat u deze DB's in dezelfde beschikbaarheidszone kunt configureren.

  • Uw HDInsight-clusters moeten worden gemaakt met de optie beschikbaarheidszone in een van de volgende regio's:

    • Oost-Australië
    • Brazilië Zuid
    • Centraal Canada
    • Centrale Verenigde Staten
    • Oostelijke VS
    • Oostelijke Verenigde Staten 2
    • Centraal Frankrijk
    • West-Centraal Duitsland
    • Oost-Japan
    • Centraal-Korea
    • Europa - noord
    • Qatar Centrale
    • Zuidoost-Azië
    • Zuid-Centraal Verenigde Staten
    • Verenigd Koninkrijk Zuid
    • VS overheid Virginia
    • West-Europa
    • Westelijke Verenigde Staten 2

Een HDInsight-cluster maken met behulp van beschikbaarheidszone

U kunt een ARM-sjabloon (Azure Resource Manager) gebruiken om een HDInsight-cluster te starten in een opgegeven beschikbaarheidszone.

In de sectie Resources moet u een sectie van 'zones' toevoegen en opgeven in welke beschikbaarheidszone u dit cluster wilt implementeren.

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

Knooppunten binnen één beschikbaarheidszone tussen zones controleren

Wanneer het HDInsight-cluster gereed is, kunt u de locatie controleren om te zien in welke beschikbaarheidszone ze zijn geïmplementeerd.

Schermopname van informatie over de beschikbaarheidszone in het clusteroverzicht.

API-antwoord ophalen:

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

Het cluster omhoog schalen

U kunt een HDInsight-cluster omhoog schalen met meer werkknooppunten. De zojuist toegevoegde werkknooppunten worden in dezelfde beschikbaarheidszone van dit cluster geplaatst.

Migratie van beschikbaarheidszone

Azure HDInsight-clusters bieden momenteel geen ondersteuning voor in-place migratie van bestaande clusterexemplaren naar ondersteuning voor beschikbaarheidszones. U kunt er echter voor kiezen om uw cluster opnieuw te maken en een andere beschikbaarheidszone of regio te kiezen tijdens het maken van het cluster. Een secundair stand-bycluster in een andere regio en een andere beschikbaarheidszone kan worden gebruikt in scenario's voor herstel na noodgevallen.

Ontspannende ervaring

Wanneer een beschikbaarheidszone uitvalt:

  • U kunt geen ssh naar dit cluster uitvoeren.
  • U kunt dit cluster niet verwijderen of omhoog schalen of omlaag schalen.
  • U kunt geen taken verzenden of de taakgeschiedenis bekijken.
  • U kunt nog steeds een aanvraag indienen voor het maken van een nieuw cluster in een andere regio.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) verwijst naar procedures die organisaties gebruiken om te herstellen van gebeurtenissen met hoge impact, zoals natuurrampen of mislukte implementaties die leiden tot downtime en gegevensverlies. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallenvoordat u begint met het maken van uw plan voor herstel na noodgevallen.

Voor DR maakt Microsoft gebruik van het model voor gedeelde verantwoordelijkheid. In dit model zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Veel Azure-services repliceren echter niet automatisch gegevens of vallen terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen voor ondersteuning van disaster recovery. U kunt servicespecifieke functies gebruiken om snelle herstelbewerkingen te ondersteunen en uw noodherstelplan te ontwikkelen.

Azure HDInsight-clusters zijn afhankelijk van veel Azure-services, zoals opslag, databases, Active Directory, Active Directory Domain Services, netwerken en Key Vault. Een goed ontworpen, maximaal beschikbare en fouttolerante analysetoepassing moet worden ontworpen met voldoende redundantie om regionale of lokale onderbrekingen in een of meer van deze services te weerstaan. In deze sectie vindt u een overzicht van aanbevolen procedures, beschikbaarheid van één en meerdere regio's en optimalisatieopties voor bedrijfscontinuïteitsplanning.

Herstel bij rampen in meerdere regio's

Voor het verbeteren van bedrijfscontinuïteit met herstel na noodgevallen in meerdere regio's zijn architectuurontwerpen van hogere complexiteit en hogere kosten vereist. In de volgende tabellen worden enkele technische gebieden beschreven die de totale eigendomskosten kunnen verhogen.

Kostenoptimalisaties

Gebied Oorzaak van escalatie van kosten Optimalisatiestrategieën
Gegevensopslag Primaire gegevens/tabellen dupliceren in een secundaire regio Alleen gecureerde gegevens repliceren
Uitgaand gegevensverkeer Uitgaande gegevensoverdrachten voor meerdere regio's hebben een prijs. Richtlijnen voor bandbreedteprijzen bekijken Alleen gecureerde gegevens repliceren om de impact van het regio-uitgaand verkeer te verminderen
Cluster Compute Extra HDInsight-cluster(s) in secundaire regio Gebruik geautomatiseerde scripts om secundaire berekeningen te implementeren na een primaire fout. Gebruik Automatisch schalen om de secundaire clustergrootte tot een minimum te beperken. Gebruik goedkopere VM-SKU's. Maak secundaire exemplaren in regio's waar VM-SKU's mogelijk korting krijgen.
Authenticatie Bij scenario's met meerdere gebruikers in de secundaire regio worden extra Setups voor Microsoft Entra Domain Services uitgevoerd Vermijd setups voor meerdere gebruikers in secundaire regio.

Complexiteitsoptimalisaties

Gebied Oorzaak van escalatie van complexiteit Optimalisatiestrategieën
Lees- en schrijfpatronen Vereisen dat zowel de primaire als secundaire modus voor lezen en schrijven ingeschakeld zijn Maak de secundaire versie alleen-lezen
Nul RPO & RTO Het vereisen van nul gegevensverlies (RPO=0) en nul downtime (RTO=0) Ontwerp RPO en RTO op manieren om het aantal onderdelen te verminderen dat een failover moet uitvoeren. Zie Wat zijn bedrijfscontinuïteit, hoge beschikbaarheid en herstel na noodgevallen voor meer informatie over RTO en RPO.
Bedrijfsfunctionaliteit Vereist volledige bedrijfsfunctionaliteit van primair naar secundair Evalueer of u kunt werken met een minimale kritieke subset van de bedrijfsfunctionaliteit in een secundaire omgeving.
Connectiviteit Vereisen dat alle upstream- en downstreamsystemen van primaire systemen verbinding maken met de secundaire Beperk de secundaire connectiviteit tot een minimale kritieke subset.

Wanneer u uw plan voor herstel na noodgevallen voor meerdere regio's maakt, moet u rekening houden met de volgende aanbevelingen:

  • Bepaal de minimale bedrijfsfunctionaliteit die u nodig hebt als er een noodgeval is en waarom. Evalueer bijvoorbeeld of u failovermogelijkheden nodig hebt voor de gegevenstransformatielaag (geel) en de gegevensservicelaag (blauw weergegeven) of als u alleen failover nodig hebt voor de gegevensservicelaag.

    gegevenstransformatie en gegevensbedienlagen

  • Segmenteer uw clusters op basis van workload, ontwikkelingslevenscyclus en afdelingen. Als u meer clusters hebt, vermindert u de kans op één grote fout die van invloed is op meerdere verschillende bedrijfsprocessen.

  • Zorg ervoor dat uw secundaire regio's alleen-lezen zijn. Failoverregio's met zowel lees- als schrijfmogelijkheden kunnen leiden tot complexe architecturen.

  • Tijdelijke clusters zijn gemakkelijker te beheren wanneer zich een noodgeval voordoet. Ontwerp uw workloads op een manier waarop clusters kunnen worden gecyclusd en er geen status wordt onderhouden in clusters.

  • Workloads worden vaak onafgemaakt als er een ramp is en moeten dan opnieuw worden opgestart in de nieuwe regio. Ontwerp uw workloads als idempotent van aard.

  • Gebruik automatisering tijdens clusterimplementaties en zorg ervoor dat de clusterconfiguratie-instellingen zoveel mogelijk worden gescript om snelle en volledig geautomatiseerde implementatie te garanderen als er zich een noodgeval voordoet.

Detectie, melding en beheer van storingen

  • Gebruik Azure-bewakingshulpprogramma's in HDInsight om abnormaal gedrag in het cluster te detecteren en bijbehorende waarschuwingsmeldingen in te stellen. U kunt de vooraf geconfigureerde HDInsight-clusterspecifieke beheeroplossingen implementeren die belangrijke prestatiegegevens van het specifieke clustertype verzamelen. Zie Azure Monitoring voor HDInsight voor meer informatie.

  • Abonneer u op Azure-statuswaarschuwingen om op de hoogte te worden gesteld van serviceproblemen, gepland onderhoud, status- en beveiligingsadviezen voor een abonnement, service of regio. Gezondheidsmeldingen met de oorzaak van het probleem en een verwachte oplossingstijd helpen u om failovers en failbacks beter uit te voeren. Zie de documentatie voor Azure Service Health voor meer informatie.

Herstel na noodgevallen in geografie met één regio

Elk onderdeel in een eenvoudig HDInsight-systeem heeft zijn eigen mechanismen voor fouttolerantie voor één regio. Houd er rekening mee dat er niet altijd een catastrofale gebeurtenis nodig is om de bedrijfsfunctionaliteit te beïnvloeden. Service-incidenten in een of meer van de volgende services in één regio kunnen ook leiden tot verlies van verwachte bedrijfsfunctionaliteit.

  • Compute (virtuele machines): Azure HDInsight-cluster. HDInsight biedt een SLA voor beschikbaarheid van 99.9%. Als u hoge beschikbaarheid in één implementatie wilt bieden, gaat HDInsight gepaard met veel services die standaard in de modus voor hoge beschikbaarheid staan. Fouttolerantiemechanismen in HDInsight worden geleverd door services voor hoge beschikbaarheid van microsoft- en Apache OSS-ecosysteem.

    De volgende infrastructuuronderdelen zijn ontworpen om maximaal beschikbaar te zijn:

    • Actieve en stand-by hoofdknopen
    • Meerdere gatewayknooppunten
    • Drie Zookeeper Quorum-knooppunten
    • Werkknooppunten gedistribueerd over fout- en updatedomeinen

    De volgende services zijn ook ontworpen om maximaal beschikbaar te zijn:

    • Apache Ambari-server
    • Tijdlijnservers voor applicaties in YARN
    • Taakgeschiedenisserver voor Hadoop MapReduce
    • Apache Livy
    • HDFS (Hadoop Distributed File System)
    • YARN Resourcebeheerder
    • HBase-Master

    Zie services voor hoge beschikbaarheid die worden ondersteund door Azure HDInsight voor meer informatie.

  • Metastore(s): Azure SQL Database. HDInsight maakt gebruik van Azure SQL Database als een metastore, die een SLA van 99.99%biedt. Drie replica's van gegevens blijven behouden in een datacenter met synchrone replicatie. Als er sprake is van een replicaverlies, wordt een alternatieve replica naadloos geleverd. Actieve geo-replicatie wordt standaard ondersteund met maximaal vier datacenters. Wanneer er een failover is, ofwel handmatig of datacenter, wordt de eerste replica in de hiërarchie automatisch geschikt voor lezen/schrijven. Zie De bedrijfscontinuïteit van Azure SQL Database voor meer informatie.

  • Opslag: Azure Data Lake Gen2 of Blob Storage. HDInsight raadt Azure Data Lake Storage Gen2 aan als de onderliggende opslaglaag. Azure Storage, waaronder Azure Data Lake Storage Gen2, biedt een SLA van 99.9%. HDInsight maakt gebruik van de LRS-service waarin drie replica's van gegevens zich in een datacenter bevinden en replicatie synchroon is. Wanneer er sprake is van een replicaverlies, wordt een replica naadloos geleverd.

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

  • Optionele services, zoals Azure Key Vault en Azure Data Factory.

HDInsight-onderdelen

Verwante inhoud