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 beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.

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.

Vereisten

• 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:

  • Australië - oost
  • Brazilië - zuid
  • Canada - midden
  • VS - centraal
  • VS - oost
  • VS - oost 2
  • Frankrijk - centraal
  • Duitsland - west-centraal
  • Japan - oost
  • Korea - centraal
  • Europa - noord
  • Qatar - centraal
  • Azië - zuidoost
  • VS - zuid-centraal
  • Verenigd Koninkrijk Zuid
  • VS (overheid) - Virginia
  • Europa -west
  • VS - west 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.

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.

Zone-down-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) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. 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 voordat u nadenkt over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze 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 ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

Azure HDInsight-clusters zijn afhankelijk van veel Azure-services, zoals opslag, databases, Active Directory, Active Directory-domein 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 na noodgevallen in geografie 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

Complexiteitsoptimalisaties

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.

  

• 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 onvoltooid als er een noodgeval is en opnieuw moeten worden opgestart in de nieuwe regio. Ontwerp uw workloads als idempotent in de natuur.

• 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. Statusmeldingen met de oorzaak van het probleem en een resolute ETA helpen u om failover- 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 headnodes
  • Meerdere gatewayknooppunten
  • Drie Zookeeper Quorum-knooppunten
  • Werkknooppunten gedistribueerd door fout- en updatedomeinen

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

  • Apache Ambari-server
  • Tijdlijnen van toepassingen voor YARN
  • Taakgeschiedenisserver voor Hadoop MapReduce
  • Apache Livy
  • HDFS
  • YARN Resource Manager
  • 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, 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, inclusief 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.

  • Microsoft Entra ID biedt een SLA van 99,9%. Active Directory is een globale service met meerdere niveaus van interne redundantie en automatische herstelbaarheid. Zie voor meer informatie hoe Microsoft voortdurend de betrouwbaarheid van Microsoft Entra ID verbetert.
  • Microsoft Entra Domain Services biedt een SLA van 99,9%. Microsoft Entra Domain Services is een maximaal beschikbare service die wordt gehost in wereldwijd gedistribueerde datacenters. Replicasets zijn een preview-functie in Microsoft Entra Domain Services waarmee geografisch herstel na noodgevallen mogelijk is als een Azure-regio offline gaat. Zie concepten en functies van replicasets voor Microsoft Entra Domain Services voor meer informatie.
  • Azure DNS biedt een SLA van 100%. HDInsight gebruikt Azure DNS op verschillende plaatsen voor domeinnaamomzetting.

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

Volgende stappen

Zie voor meer informatie over de items die in dit artikel worden besproken:

• Azure HDInsight-architecturen voor bedrijfscontinuïteit
• Casestudy voor azure HDInsight-oplossingsarchitectuur met hoge beschikbaarheid
• Wat is Apache Hive en HiveQL in Azure HDInsight?