Partager via

Effectuer la migration d’un cluster HDInsight vers une version plus récente

  • Article

Pour tirer parti des dernières fonctionnalités proposées par HDInsight, nous vous recommandons d’effectuer régulièrement la migration des clusters HDInsight vers la version la plus récente. HDInsight ne prend pas en charge les mises à niveau sur place lorsqu’un cluster existant est mis à niveau vers une nouvelle version de composant. Vous devez créer un nouveau cluster avec la version de composant et la version de plateforme souhaitées, puis effectuer la migration de vos applications pour qu’elles utilisent le nouveau cluster. Suivez les instructions ci-dessous pour effectuer la migration de vos clusters HDInsight.

Notes

Si vous créez un cluster Hive avec un conteneur de stockage principal, copiez-le à partir d’un cluster HDInsight existant. Ne copiez pas le contenu complet. Copiez uniquement les dossiers de données configurés.

Tâches de migration

Le workflow pour mettre à niveau un cluster HDInsight est le suivant : Diagramme du workflow de mise à niveau d’HDInsight.

  1. Lisez chaque section de ce document pour comprendre les modifications qui peuvent être nécessaires lors de la mise à jour de votre cluster HDInsight.
  2. Créez un cluster comme environnement de test ou d’assurance qualité. Pour plus d’informations sur la création d’un cluster, consultez Création de clusters Hadoop basés sur Linux dans HDInsight.
  3. Copiez les travaux, sources de données et récepteurs existants dans le nouvel environnement.
  4. Effectuez des tests de validation pour vérifier que vos tâches fonctionnent comme prévu sur le nouveau cluster.

Une fois que vous avez vérifié que tout fonctionne comme prévu, planifiez un temps d’arrêt pour la migration. Pendant ce temps d’arrêt, effectuez les actions suivantes :

  1. Sauvegardez toutes les données temporaires stockées localement sur les nœuds du cluster, par exemple si vous avez des données stockées directement sur un nœud principal.
  2. Supprimez le cluster existant.
  3. Créez un cluster dans le même sous-réseau de réseau virtuel avec la version HDI la plus récente (ou prise en charge) à l’aide du même magasin de données par défaut que le cluster précédent a utilisé. Cela permet au nouveau cluster de continuer à travailler sur vos données de production existantes.
  4. Importez toutes les données temporaires que vous avez sauvegardées.
  5. Démarrez des tâches ou poursuivez le traitement avec le nouveau cluster.

Recommandations relatives aux charges de travail

Les documents suivants fournissent des conseils sur la migration de certaines charges de travail :

Sauvegarde et restauration

Pour plus d’informations sur la sauvegarde et la restauration d’une base de données, consultez Récupérer une base de données dans Azure SQL Database à l’aide des sauvegardes de base de données automatisées.

Scénarios de mise à niveau

Comme mentionné plus haut, Microsoft recommande de migrer régulièrement les clusters HDInsight vers la dernière version afin de bénéficier des nouvelles fonctionnalités et des derniers correctifs. Consultez les différentes raisons listées ci-dessous pour lesquelles nous pourrions vous demander de supprimer et redéployer un cluster :

  • La version du cluster est mise hors service ou vous rencontrez un problème de cluster qui serait résolu avec une version plus récente.
  • La cause racine d’un problème de cluster a été identifiée comme étant en lien avec une machine virtuelle sous-dimensionnée. Consultez la configuration de nœuds recommandée par Microsoft.
  • Un client ouvre un cas de support et l’équipe technique de Microsoft détermine que le problème a déjà été résolu dans une version du cluster plus récente.
  • Une base de données du metastore par défaut (Ambari, Hive, Oozie, Ranger) a atteint sa limite d’utilisation. Dans ce cas, Microsoft vous demande de recréer le cluster avec une base de données d’un metastore personnalisé.
  • La cause racine d’un problème de cluster est liée à une opération non prise en charge. Voici quelques opérations courantes non prises en charge :
    • Déplacement ou ajout d’un service dans Ambari. Quand vous affichez des informations sur les services de cluster dans Ambari, l’une des actions disponibles dans le menu Service Actions (Actions de service) est Move [Service Name] (Déplacer [Nom du service]). Une autre action est Add [Service Name] (Ajouter [Nom du service]). Ces deux options ne sont pas prises en charge.
    • Altération du package Python. Les clusters HDInsight sont basés sur les environnements Python intégrés, Python 2.7 et Python 3.5. L’installation directe de packages personnalisés dans ces environnements intégrés par défaut peut entraîner des modifications inattendues de la version de la bibliothèque et arrêter le cluster. Découvrez comment effectuer une installation sécurisée des packages Python externes personnalisés pour vos applications Spark.
    • Logiciels tiers. Les clients ont la possibilité d’installer des logiciels tiers sur leurs clusters HDInsight. Toutefois, nous recommandons de recréer le cluster en cas d’arrêt des fonctionnalités existantes.
    • Plusieurs charges de travail sur le même cluster. Dans HDInsight 4.0, Hive Warehouse Connector nécessite des clusters distincts pour les charges de travail Spark et Interactive Query. Suivez les étapes ci-dessous pour configurer les deux clusters dans Azure HDInsight. De même, l’intégration de Spark avec HBASE nécessite deux clusters différents.
    • Changement du mot de passe de la base de données Ambari personnalisée. Le mot de passe de la base de données Ambari est défini au moment de la création du cluster et il n’existe pas de mécanisme pour le changer. Quand un client déploie le cluster avec une base de données Ambari personnalisée, il peut changer le mot de passe de cette base de données sur SQL DB ; en revanche, il n’y a aucune possibilité de changer ce mot de passe pour un cluster HDInsight déjà en cours d’exécution.
    • Modification des équilibreurs de charge HDInsight. Les équilibreurs de charge HDInsight, automatiquement déployés pour l’accès Ambari et SSH, ne doivent pas être modifiés ou supprimés. Si vous modifiez le ou les équilibreurs de charge HDInsight et que cela interrompt les fonctionnalités du cluster, nous vous recommandons de redéployer le cluster.
    • Réutilisation de bases de données Ranger 4.X dans 5.X. HDInsight 5.1 inclut Apache Ranger version 2.3.0, qui est la mise à niveau majeure depuis la version 1.2.0 dans les clusters HDInsight 4.X. La réutilisation d’une base de données Ranger 4.X HDInsight dans HDInsight 5.1 empêcherait le service Ranger de démarrer en raison de différences dans le schéma de base de données. Vous devez créer une base de données Ranger vide pour déployer correctement des clusters HDInsight 5.1 ESP.

Étapes suivantes