Delen via


Betrouwbaarheid in Azure HDInsight in Azure Kubernetes Service

Notitie

Op 31 januari 2025 wordt Azure HDInsight buiten gebruik gesteld op AKS. Vóór 31 januari 2025 moet u uw workloads migreren naar Microsoft Fabric of een gelijkwaardig Azure-product om te voorkomen dat uw workloads plotseling worden beëindigd. De resterende clusters in uw abonnement worden gestopt en verwijderd van de host.

Alleen basisondersteuning is beschikbaar tot de buitengebruikstellingsdatum.

Belangrijk

Deze functie is momenteel beschikbaar in preview. De aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews bevatten meer juridische voorwaarden die van toepassing zijn op Azure-functies die bèta, in preview of anderszins nog niet beschikbaar zijn in algemene beschikbaarheid. Zie Azure HDInsight op AKS Preview-informatie voor meer informatie over deze specifieke preview. Voor vragen of suggesties voor functies dient u een aanvraag in op AskHDInsight met de details en volgt u ons voor meer updates in de Azure HDInsight-community.

In dit artikel wordt de betrouwbaarheidsondersteuning in Azure HDInsight in Azure Kubernetes Service (AKS) en herstel na noodgevallen en bedrijfscontinuïteit beschreven.

Ondersteuning voor beschikbaarheidszone

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.

Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?

Azure HDInsight in AKS ondersteunt beschikbaarheidszone door gebruik te maken van de mogelijkheid van Azure Kubernetes Service om zone-redundante knooppuntgroepen te maken. U kunt tijdens het maken selecteren welke beschikbaarheidszones de clustergroep en het cluster moeten implementeren. Zodra de clustergroep of het cluster is gemaakt, kunt u de beschikbaarheidszones niet meer wijzigen.

Vereisten

  • Beschikbaarheidszones worden alleen ondersteund voor clustergroepversie >= 1.2 en clusterversie >= 1.2.1.

  • Azure HDInsight in AKS heeft slechts één standaard-SKU en ondersteunt AZ zolang de Azure-regio AZ-ondersteuning heeft.

    Onderstaande regio's bieden geen ondersteuning voor AZ:

    Noord- en Zuid-Amerika Europa Midden-Oosten Afrika Azië en Stille Oceaan
    VS - west Duitsland - noord
  • Sommige VM-SKU's ondersteunen mogelijk niet alle beschikbaarheidszones in een regio. Als u deze SKU's selecteert, biedt HDInsight in AKS-clustergroepen of -clusters ook geen ondersteuning voor bijbehorende beschikbaarheidszones.

SLA-verbeteringen

Er zijn geen verhoogde SLA's voor Azure HDInsight in AKS-clusters waarvoor beschikbaarheidszones zijn ingeschakeld.

Een resource maken waarvoor beschikbaarheidszone is ingeschakeld

  • Clustergroepen U kunt een of meer beschikbaarheidszones selecteren tijdens het maken van de clustergroep nadat u de regio hebt geselecteerd.

  • Clusters U kunt een of meer beschikbaarheidszones selecteren tijdens het maken van het cluster.

Fouttolerantie

Als u zich wilt voorbereiden op een storing in de beschikbaarheidszone, is het raadzaam om de capaciteit van de service te over-inrichten om ervoor te zorgen dat uw cluster het verlies van capaciteit van één beschikbaarheidszone naar beneden tolereert en blijft functioneren zonder verminderde prestaties tijdens storingen in de hele zone. Als u bijvoorbeeld drie beschikbaarheidszones inschakelt, moet uw cluster 1/3 van de knooppunten naar beneden tolereren (afronden op het dichtstbijzijnde gehele getal).

Zone-down-ervaring

Azure HDInsight in AKS-service is zone-redundant. Tijdens een zonebrede storing moet de klant de prestaties verwachten vanwege een daling van de capaciteit. Klanten kunnen nog steeds nieuwe clustergroepen en clusters maken in de beschikbaarheidszones die niet worden beïnvloed. Bestaande clusters kunnen werken met verminderde capaciteit. Aanbevelingen en best practices voor afzonderlijke opensource-workloads worden gegeven in de documentatie.

Herstel na noodgevallen en bedrijfscontinuïteit

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 voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken 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 op de AKS-besturingsvlakservice en -databases worden geïmplementeerd in regio's van Azure. Tussen deze regio's worden de Azure HDInsight op AKS-exemplaren en database-exemplaren geïsoleerd. Wanneer er een storing op regioniveau optreedt, is één regio offline. Alle resources in deze regio, inclusief de RP (Resource Provider) van Azure HDInsight op het AKS-besturingsvlak, de database van Azure HDInsight op het AKS-besturingsvlak en alle klantclusters in deze regio. In dit geval kunnen we alleen wachten tot de regionale storing is beëindigd. Wanneer de zonegebonden storing volledig is hersteld, is azure HDInsight in de AKS-service terug en zijn alle klantclusters weer normaal. Het is mogelijk dat u problemen ondervindt vanwege inconsistentie van gegevens na de storing en mogelijk een handmatige oplossing nodig heeft op basis van uw toepassingsworkloads.

Herstel na noodgevallen voor meerdere regio's

Azure HDInsight in AKS biedt momenteel geen ondersteuning voor failover tussen 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. Klanten kunnen ervoor kiezen om hun eigen oplossing te ontwerpen om een back-up te maken van belangrijke gegevens en taakstatus in verschillende regio's.

Detectie, melding en beheer van storingen

  • Gebruik Azure-bewakingshulpprogramma's in HDInsight in AKS om abnormaal gedrag in het cluster te detecteren en bijbehorende waarschuwingsmeldingen in te stellen. U kunt Log Analytics op verschillende manieren inschakelen en beheerde Prometheus-service gebruiken met Azure Grafana-dashboards voor bewaking. Zie Azure Monitor-integratie 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 servicestatus en Azure Service Health beheren voor meer informatie.

Herstel na noodgevallen in één regio

Op dit moment heeft Azure HDInsight op AKS slechts één standaardserviceaanbod en worden clusters gemaakt in een geografie met één regio. Klanten zijn verantwoordelijk voor herstelinstellingen voor diaster op basis van de toepassingsvereisten.

Tolerantie voor capaciteit en proactief herstel na noodgevallen

Azure HDInsight in AKS en de bijbehorende klanten werken onder het model voor gedeelde verantwoordelijkheid. Dit betekent dat de klant moet voldoen aan vereisten voor herstel na noodgevallen voor de service die ze implementeren en beheren. Om ervoor te zorgen dat herstel proactief is, moeten klanten altijd secundaire databases vooraf implementeren, omdat er geen garantie is voor capaciteit op het moment van impact voor degenen die de toewijzing niet vooraf hebben toegewezen.

In tegenstelling tot HDInsight hebben de virtuele machines die worden gebruikt in HDInsight op AKS-clusters hetzelfde quotum als virtuele Azure-machines nodig. Zie Capaciteitsplanning voor meer informatie.

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