Partager via

Fiabilité dans Azure HDInsight sur Azure Kubernetes Service

  • Article

Cet article décrit la prise en charge de la fiabilité dans Azure HDInsight sur Azure Kubernetes Service (AKS), et couvre à la fois des recommandations de fiabilité spécifiques ainsi que la récupération d'urgence et la continuité des activités. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez fiabilité d’Azure.

Recommandations en matière de fiabilité

Cette section contient des recommandations pour atteindre la résilience et la disponibilité. Chaque recommandation appartient à l’une des deux catégories suivantes :

  • Les éléments d’intégrité couvrent des domaines tels que les éléments de configuration et le bon fonctionnement des principaux composants de votre charge de travail Azure, tels que les paramètres de configuration des ressources Azure, les dépendances vis-à-vis d’autres services, etc.

  • Les éléments de risque couvrent des domaines tels que les exigences de disponibilité et de reprise d’activité, les tests, le monitoring, le déploiement et d’autres éléments qui, s’ils ne sont pas résolus, augmentent les risques de problèmes dans l’environnement.

Matrice de priorité des recommandations de fiabilité

Chaque recommandation est marquée conformément à la matrice de priorité suivante :

Image Priority Description
Élevé Correctif immédiat nécessaire.
Moyenne Corriger dans les 3 à 6 mois.
Faible Doit être examiné.

Résumé des recommandations en matière de fiabilité

Category Priorité Recommandation
Disponibilité Recommandations par défaut et taille minimale des machines virtuelles
Mise à l’échelle automatique de clusters HDInsight sur AKS
Surveillance Comment intégrer Log Analytics
Monitoring avec Azure Managed Prometheus et Grafana
Sécurité Utiliser NSG pour restreindre le trafic vers HDInsight sur AKS

Prise en charge des zones de disponibilité

Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.

Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.

Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

Azure HDInsight sur AKS prend en charge la zone de disponibilité en tirant parti de la capacité d’Azure Kubernetes Service à créer des pools de nœuds redondants interzone. Vous pouvez sélectionner les zones de disponibilité dans lesquelles déployer le pool de clusters et le cluster lors de leur création. Une fois le pool de clusters ou le cluster créé, vous ne pouvez pas modifier les zones de disponibilité.

Prérequis

  • Les zones de disponibilité sont uniquement prises en charge pour la version du pool de clusters > = 1.2 et la version du cluster > = 1.2.1.

  • Azure HDInsight sur AKS n’a qu’une seule référence SKU par défaut et prend en charge AZ tant que la région Azure prend en charge AZ.

    Les régions ci-dessous ne prennent pas en charge AZ :

    Amérique Europe Moyen-Orient Afrique Asie-Pacifique
    USA Ouest Allemagne Nord

  • Certaines références SKU de machine virtuelle peuvent ne pas prendre en charge toutes les zones de disponibilité d’une région. Si vous sélectionnez ces références SKU, les pools de clusters ou les clusters HDInsight sur AKS ne prennent pas non plus en charge les zones de disponibilité correspondantes.

Améliorations du SLA

Il n’existe aucune augmentation des contrats SLA pour les clusters Azure HDInsight sur AKS avec les zones de disponibilité activées.

Créer une ressource avec la zone de disponibilité activée

  • Pools de clusters Vous pouvez sélectionner une ou plusieurs zones de disponibilité lors de la création du pool de clusters après avoir sélectionné la région.

  • Clusters Vous pouvez sélectionner une ou plusieurs zones de disponibilité lors de la création du cluster.

Tolérance de panne

Pour vous préparer à une défaillance de zone de disponibilité, il est recommandé de sur-approvisionner la capacité de service pour vous assurer que votre cluster peut tolérer la perte de capacité d’une zone de disponibilité défaillante et continuer à fonctionner sans dégrader les performances pendant les pannes à l’échelle de la zone. Par exemple, si vous activez trois zones de disponibilité, votre cluster doit tolérer 1/3 des nœuds défaillants (arrondi à l’entier le plus proche).

Expérience en cas de panne de zone

Le service Azure HDInsight sur AKS est redondant interzone. Pendant une panne à l’échelle de la zone, le client doit s’attendre à une dégradation des performances en raison d’une baisse de capacité. Les clients peuvent toujours créer des pools de clusters et des clusters dans les zones de disponibilité qui ne sont pas affectées. Les clusters existants peuvent fonctionner avec une capacité réduite. Les recommandations et les bonnes pratiques relatives aux charges de travail open source individuelles sont fournies dans la documentation.

Récupération d'urgence et continuité d’activité

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Le service et les bases de données du plan de contrôle Azure HDInsight sur AKS sont déployés dans différentes régions d’Azure. Parmi ces régions, les instances Azure HDInsight sur AKS et les instances de bases de données sont isolées. Lorsqu’une panne se produit au niveau de la région, une région est en panne. Toutes les ressources de cette région, notamment le fournisseur de ressources du plan de contrôle Azure HDInsight sur AKS, de la base de données du plan de contrôle Azure HDInsight sur AKS et de tous les clusters clients de cette région. Dans ce cas, nous devons simplement attendre que la panne régionale se termine. Lorsque la panne zonale est entièrement récupérée, le service Azure HDInsight sur AKS est de retour et tous les clusters clients sont de retour à la normale. Il est possible que vous rencontriez des problèmes en raison d’incohérences de données après la panne et que vous ayez peut-être besoin d’un correctif manuel en fonction de vos charges de travail d’application.

Reprise d’activité multi-régionale

Azure HDInsight sur AKS ne prend actuellement pas en charge la bascule d'une région à l'autre. L’amélioration de la continuité de l’activité à l’aide de la récupération d’urgence à haute disponibilité entre les régions nécessite des conceptions architecturales plus complexes et plus coûteuses. Les clients peuvent choisir de concevoir leur propre solution pour sauvegarder les données clés et l’état du travail dans différentes régions.

Détection, notification et gestion des pannes

  • Utilisez les outils d’analyse Azure sur HDInsight sur AKS pour détecter un comportement anormal dans le cluster et définir les notifications d’alerte correspondantes. Vous pouvez activer Log Analytics de différentes façons et utiliser le service Prometheus géré avec des tableaux de bord Azure Grafana pour la supervision. Pour plus d’informations, consultez Intégration Azure Monitor.

  • Abonnez-vous aux alertes d’intégrité Azure pour être informé des problèmes de service, de la maintenance planifiée et des conseils en matière d’intégrité et de sécurité pour un abonnement, un service ou une région. Les notifications d’intégrité qui incluent la cause du problème et une estimation de l’heure de résolution vous aident à mieux exécuter le basculement et les restaurations. Pour plus d’informations, consultez Gérer l’état du service et documentation Azure Service Health.

Reprise d’activité dans une seule région

Actuellement, Azure HDInsight sur AKS n’a qu’une seule offre de service standard et des clusters sont créés dans une zone géographique à une seule région. Les clients sont responsables des paramètres de récupération d’urgence en fonction des exigences de l’application.

Capacité et résilience proactive de la récupération d’urgence

Azure HDInsight sur AKS et ses clients opèrent selon le modèle de responsabilité partagée, ce qui signifie que le client doit traiter la récupération d’urgence pour le service qu’il déploie et contrôle. Pour garantir une récupération proactive, les clients doivent toujours prédéployer les régions secondaires, car, à défaut de préallocation, la capacité n’est pas garantie au moment de l’impact.

Contrairement à HDInsight, les machines virtuelles utilisées dans les clusters HDInsight sur AKS nécessitent le même quota que les machines virtuelles Azure. Pour plus d’informations, consultez Planification de la capacité.

Contenu connexe

Pour en savoir plus sur les fonctionnalités présentées dans cet article, voir :