Partager via

Fiabilité dans Azure HDInsight sur Azure Kubernetes Service

  • Article

Remarque

Nous allons mettre hors service Azure HDInsight sur AKS le 31 janvier 2025. Avant le 31 janvier 2025, vous devrez migrer vos charges de travail vers Microsoft Fabric ou un produit Azure équivalent afin d’éviter leur arrêt brutal. Les clusters restants de votre abonnement seront arrêtés et supprimés de l’hôte.

Seul le support de base est disponible jusqu’à la date de mise hors service.

Important

Cette fonctionnalité est disponible actuellement en mode Aperçu. Les Conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure contiennent davantage de conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou ne se trouvant pas encore en disponibilité générale. Pour plus d’informations sur cette préversion spécifique, consultez les Informations sur la préversion d’Azure HDInsight sur AKS. Pour toute question ou pour des suggestions à propos des fonctionnalités, veuillez envoyer vos requêtes et leurs détails sur AskHDInsight, et suivez-nous sur la Communauté Azure HDInsight pour plus de mises à jour.

Cet article décrit la prise en charge de la fiabilité dans Azure HDInsight sur Azure Kubernetes Service (AKS), ainsi que la récupération d'urgence et la continuité des activités.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes de centres de données physiquement séparés au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Pour plus d’informations sur les zones de disponibilité dans Azure, consultez Que sont les zones de disponibilité ?.

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 en charge 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 :