Partager via

Effectuer la migration de clusters Apache Hadoop locaux vers Azure HDInsight

  • Article

Cet article fournit des recommandations pour le stockage de données dans les systèmes Azure HDInsight. Il fait partie d’une série qui propose des bonnes pratiques pour aider à la migration des systèmes Apache Hadoop locaux vers Azure HDInsight.

Choisir le système de stockage approprié pour les clusters HDInsight

La structure des répertoires du système de fichiers Apache Hadoop (HDFS) local peut être recréée dans le stockage Blob Azure ou dans Azure Data Lake Storage. Vous pouvez alors supprimer sans problème les clusters HDInsight utilisés pour le traitement, sans perte de données utilisateur. Les deux services peuvent être utilisés comme système de fichiers par défaut et comme système de fichiers supplémentaire pour un cluster HDInsight. Le cluster HDInsight et le compte de stockage doivent être hébergés dans la même région.

Stockage Azure

Les clusters HDInsight peuvent utiliser le conteneur d’objets blob dans Stockage Azure comme système de fichiers par défaut ou comme système de fichiers supplémentaire. Le compte de stockage de niveau Standard est pris en charge pour une utilisation avec des clusters HDInsight. Le niveau Premier n’est pas pris en charge. Le conteneur d’objets blob par défaut stocke les informations spécifiques de cluster telles que l’historique et les journaux d’activité des travaux. Le partage d’un conteneur blob en tant que système de fichiers par défaut sur plusieurs clusters n’est pas pris en charge.

Les comptes de stockage définis lors du processus de création et leurs clés respectives sont stockés dans %HADOOP_HOME%/conf/core-site.xml sur les nœuds du cluster. Ils sont également accessibles sous la section « Custom core site » dans la configuration HDFS, dans l’interface utilisateur d’Ambari. La clé du compte de stockage est chiffrée par défaut et un script de déchiffrement personnalisé est utilisé pour déchiffrer les clés avant de les passer aux démons Hadoop. Les tâches, notamment Hive, MapReduce, le streaming Hadoop et Pig, véhiculent avec elles une description des comptes de stockage et des métadonnées.

Vous pouvez géorépliquer le stockage Azure. Si la géoréplication permet la récupération à partir d’autres régions géographiques et la redondance des données, un basculement vers un emplacement géorépliqué affecte sérieusement les performances et peut entraîner des frais supplémentaires. Nous vous recommandons de choisir la géoréplication en connaissance de cause et seulement si la valeur des données justifie le coût supplémentaire.

Vous pouvez utiliser un des formats suivants pour accéder aux données stockées dans Stockage Azure :

Format d’accès aux données Description
wasb:/// Accédez au stockage par défaut à l’aide d’une communication non chiffrée.
wasbs:/// Accédez au stockage par défaut à l’aide d’une communication chiffrée.
wasb://<container-name>@<account-name>.blob.core.windows.net/ Utilisé pour communiquer avec un compte de stockage autre que celui par défaut. 

Objectifs d’extensibilité pour les compte de stockage standard liste les limites actuelles des comptes de stockage Azure. Si les besoins de votre application dépassent cibles de scalabilité d’un seul compte de stockage, vous pouvez concevoir votre application pour qu’elle utilise plusieurs comptes de stockage, puis partitionner vos objets de données entre ces comptes.

Azure Storage Analytics fournit des métriques pour tous les services de stockage et le portail Azure peut être configuré pour la visualisation des métriques collectées via des graphiques. Vous pouvez créer des alertes pour avertir quand des seuils ont été atteints pour les métriques des ressources de stockage.

Stockage Azure offre une fonctionnalité de suppression réversible pour les objets blob, qui vous permet de récupérer plus facilement vos données en cas de modification ou de suppression accidentelles de celles-ci par une application ou par un autre utilisateur du compte de stockage.

Vous pouvez créer des instantanés d’objets blob. Un instantané est une version en lecture seule d’un objet blob, qui est capturé à un instant donné, fournissant ainsi une façon de sauvegarder un objet blob. Un instantané peut être lu, copié ou supprimé, mais pas modifié.

Notes

Pour une version antérieure des distributions Hadoop locales qui n’a pas le certificat « wasbs », il doit être importé dans le magasin d’approbations Java.

Vous pouvez utiliser les méthodes suivantes pour importer des certificats dans le magasin d’approbations Java :

Télécharger le certificat SSL/TLS de l’objet blob Azure dans un fichier

echo -n | openssl s_client -connect <storage-account>.blob.core.windows.net:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > Azure_Storage.cer

Importer le fichier ci-dessus dans le magasin d’approbations Java sur tous les nœuds

keytool -import -trustcacerts -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -alias blobtrust -file Azure_Storage.cer

Vérifier que le certificat ajouté figure dans le magasin d’approbations

keytool -list -v -keystore /path/to/jre/lib/security/cacerts

Pour plus d’informations, consultez les articles suivants :

Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 est la l’offre de stockage la plus récente. Elle unifie les capacités de base de la première génération d’Azure Data Lake Storage Gen1 avec un point de terminaison de système de fichiers compatible Hadoop, directement intégré dans le stockage Blob Azure. Cette amélioration combine les avantages de la mise à l’échelle et du coût de stockage des objets, avec la fiabilité et les performances généralement associées seulement à des systèmes de fichiers locaux.

Azure Data Lake Storage Gen 2 repose sur le Stockage Blob Azure et vous permet d’interagir avec les données selon les deux paradigmes du système de fichiers et du stockage d’objets. Les fonctionnalités d’Azure Data Lake Storage Gen1, comme la sémantique des systèmes de fichiers, la sécurité au niveau du fichier et la mise à l’échelle, sont combinées à celles du Stockage Blob Azure, comme le stockage hiérarchisé économique, la haute disponibilité/reprise après sinistre et le grand écosystème de SDK/d’outils. Dans Data Lake Storage Gen2, toutes les qualités du stockage d’objets sont conservées, avec en plus les avantages d’une interface de système de fichiers optimisée pour les charges de travail analytiques.

Une fonctionnalité fondamentale de Data Lake Storage Gen 2 est l’ajout d’un espace de noms hiérarchique au service de stockage Blob qui organise les objets et les fichiers en une hiérarchie de répertoires pour optimiser l’accès aux données. La structure hiérarchique fait que les opérations comme le renommage ou la suppression d’un répertoire sont des opérations atomiques uniques de métadonnées sur le répertoire, au lieu de l’énumération et du traitement de tous les objets qui partagent le préfixe du nom de répertoire.

Dans le passé, l’analytique cloud devait trouver le meilleur compromis entre les performances, la gestion et la sécurité. Les principales fonctionnalités d’Azure Data Lake Storage Gen2 sont les suivantes :

  • Accès compatible Hadoop : Azure Data Lake Storage Gen2 vous permet de gérer les données et d'y accéder comme vous le feriez avec un système de fichiers HDFS (Hadoop Distributed File System). Le nouveau pilote ABFS est disponible dans tous les environnements Apache Hadoop inclus dans Azure HDInsight. Ce pilote vous permet d’accéder aux données stockées dans Data Lake Storage Gen2.

  • Surensemble d’autorisations POSIX : Le modèle de sécurité pour Data Lake Gen2 prend entièrement en charge les autorisations ACL et POSIX ainsi que certaines granularités supplémentaires spécifiques de Data Lake Storage Gen2. Les paramètres peuvent être configurés via les outils d’administration ou des infrastructures telles que Hive et Spark.

  • Rentabilité : Data Lake Storage Gen2 intègre une capacité de stockage et des transactions économiques. Tout au long du cycle de vie des données, les frais facturés changent de façon à minimiser les coûts via des fonctionnalités intégrées, comme le cycle de vie du Stockage Blob Azure.

  • Fonctionne avec les outils, les frameworks et les applications de stockage Blob : Data Lake Storage Gen2 continue de fonctionner avec une large gamme d’outils, de frameworks et d’applications qui existent aujourd’hui pour Stockage Blob.

  • Pilote optimisé : Le pilote ABFS (Azure Blob Filesystem) est optimisé spécifiquement pour l’analytique du Big Data. Les API REST correspondantes sont exposées via le point de terminaison dfs, dfs.core.windows.net.

Vous pouvez utiliser un des formats suivants pour accéder aux données stockées dans Azure Data Lake Storage Gen2 :

  • abfs:///: Accédez au stockage Data Lake par défaut pour le cluster.
  • abfs://file_system@account_name.dfs.core.windows.net: Utilisé pour communiquer avec un stockage Data Lake autre que celui par défaut.

Notes

La mise à niveau du compte de stockage principal ou secondaire d’un cluster en cours d’exécution avec des fonctionnalités Azure Data Lake Storage Gen2 n’est pas prise en charge. Pour modifier le type de stockage d’un cluster HDInsight existant en Data Lake Storage Gen2, vous devez recréer le cluster et sélectionner un compte de stockage avec espace de noms hiérarchique.

Pour plus d’informations, consultez les articles suivants :

Sécuriser les clés de Stockage Azure au sein de la configuration de cluster Hadoop local

Les clés de Stockage Azure qui sont ajoutées aux fichiers de configuration Hadoop établissent la connectivité entre le stockage HDFS local et Stockage Blob Azure. Vous pouvez protéger ces clés en les chiffrant avec l’infrastructure du fournisseur d’informations d’identification Hadoop. Une fois qu’elles sont chiffrées, vous pouvez les stocker et y accéder de façon sécurisée.

Pour provisionner les informations d’identification :

hadoop credential create fs.azure.account.key.account.blob.core.windows.net -value <storage key> -provider jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks/file

Pour ajouter le chemin du fournisseur ci-dessus au fichier core-site.xml ou à la configuration Ambari sous Custom core-site :

<property>
    <name>hadoop.security.credential.provider.path</name>
        <value>
        jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks
        </value>
    <description>Path to interrogate for protected credentials.</description>
</property>

Notes

La propriété de chemin du fournisseur peut également être ajoutée à la ligne de commande distcp, au lieu de stocker la clé au niveau du cluster dans le fichier core-site.xml, comme suit :

hadoop distcp -D hadoop.security.credential.provider.path=jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks /user/user1/ wasb:<//yourcontainer@youraccount.blob.core.windows.net/>user1

Restreindre l’accès aux données de Stockage Azure à l’aide de SAP

Par défaut, HDInsight dispose d’un accès total aux données dans les comptes Stockage Azure associés au cluster. Vous pouvez utiliser des signatures d’accès partagé sur le conteneur d’objets blob pour restreindre l’accès aux données, comme fournir aux utilisateurs un accès en lecture seule aux données.

Utilisation du jeton de signature d’accès partagé créé avec python

  1. Ouvrez le fichier SASToken.py et modifiez les valeurs suivantes :

    Propriété de jeton Description
    policy_name nom à utiliser pour la stratégie stockée à créer.
    storage_account_name nom de votre compte de stockage.
    storage_account_key Clé du compte de stockage.
    storage_container_name conteneur du compte de stockage auquel vous souhaitez restreindre l’accès.
    example_file_path chemin d’un fichier qui est chargé dans le conteneur.

  2. Le fichier SASToken.py est fourni avec les autorisations ContainerPermissions.READ + ContainerPermissions.LIST et peut être ajusté en fonction du cas d’usage.

  3. Exécutez le script comme suit : python SASToken.py

  4. Quand il se termine, le script affiche le jeton de signature d’accès partagé, qui est similaire au texte suivant : sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

  5. Pour limiter l’accès à un conteneur avec une signature d’accès partagé, ajoutez une entrée personnalisée à la configuration de core-site pour le cluster sous Ambari > HDFS > Configs > Advanced > Custom core-site > Add property.

  6. Utilisez les valeurs suivantes pour les champs Clé et Valeur :

    Key : fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netValue : clé de signature d’accès partagé retournée l’application de l’étape Python 4 ci-dessus.

  7. Cliquez sur le bouton Ajouter pour enregistrer cette clé et cette valeur, puis cliquez sur le bouton Enregistrer pour enregistrer les modifications de configuration. Lorsque vous y êtes invité, ajoutez une description de la modification (« Ajout d’accès de stockage SAP », par exemple), puis cliquez sur Enregistrer.

  8. Dans l’interface utilisateur web Ambari, sélectionnez HDFS dans la liste sur la gauche, puis sélectionnez Restart All Affected (Redémarrer tous les éléments affectés) dans la liste déroulante Actions de service située à droite. Lorsque vous y êtes invité, sélectionnez Confirm Restart All (Confirmer le redémarrage).

  9. Répétez ce processus pour les entrées MapReduce2 et YARN.

Trois points sont importants à retenir pour l’utilisation de jetons de signature d’accès partagé dans Azure :

  1. Quand des jetons de signature d’accès partagé sont créés avec les autorisations « READ + LIST » (LECTURE + LISTE), les utilisateurs qui accèdent au conteneur d’objets blob avec ce jeton de signature d’accès partagé ne peuvent pas « écrire et supprimer » des données. Les utilisateurs qui accèdent au conteneur d’objets blob avec ce jeton de signature d’accès partagé, et qui essayent d’effectuer une opération d’écriture ou de suppression, reçoivent un message indiquant "This request is not authorized to perform this operation".

  2. Quand les jetons de signature d’accès partagé sont générés avec des autorisations READ + LIST + WRITE (pour interdire seulement DELETE), des commandes comme hadoop fs -put écrivent d’abord dans un fichier \_COPYING\_, puis essayent de renommer le fichier. Cette opération HDFS est mappée à une opération copy+delete pour WASB. Dans la mesure où l’autorisation DELETE n’a pas été accordée, le « put » échoue. L’opération \_COPYING\_ est une fonctionnalité de Hadoop destinée à fournir un contrôle des accès concurrentiels. Il n’existe actuellement aucun moyen d’interdire simplement l’opération « DELETE » (SUPPRESSION) sans affecter également les opérations « WRITE » (ÉCRITURE).

  3. Malheureusement, le fournisseur d’informations d’identification Hadoop et le fournisseur de clé de déchiffrement (ShellDecryptionKeyProvider) ne fonctionnent actuellement pas avec les jetons de signature d’accès partagé, et une protection contre la visibilité est donc actuellement impossible.

Pour plus d’informations, consultez Utiliser des signatures d’accès partagé de Stockage Azure pour restreindre l’accès aux données dans HDInsight.

Utiliser le chiffrement et la réplication des données

Toutes les données écrites dans le stockage Azure sont automatiquement chiffrées à l’aide du Storage Service Encryption (SSE). Les données placées dans le compte de Stockage Azure sont toujours répliquées de façon à garantir une haute disponibilité. Quand vous créez un compte de stockage, vous pouvez choisir une des options de réplication suivantes :

Le stockage Azure fournit un stockage localement redondant (LRS), mais il est également recommandé de copier les données critiques vers un autre compte de stockage Azure d’une autre région, selon une périodicité adaptée aux besoins du plan de reprise d’activité. Il existe différents moyens de copier des données, notamment ADLCopy, DistCp, Azure PowerShell ou Azure Data Factory. Il est également recommandé d’appliquer des stratégies d’accès pour le compte de stockage Azure, afin d’éviter toute suppression accidentelle.

Pour plus d’informations, consultez les articles suivants :

Attacher des comptes de Stockage Azure supplémentaires au cluster

Lors du processus de création de HDInsight, un compte de stockage Azure, Azure Data Lake Storage Gen1 ou Azure Data Lake Storage Gen2 est choisi comme système de fichiers par défaut. Lors du processus de création ou à l’issue de la création d’un cluster, à ce compte de stockage par défaut, vous pouvez ajouter d’autres comptes provenant du même abonnement Azure ou d’autres abonnements Azure.

Vous pouvez ajouter un compte de stockage supplémentaire de l’une des façons suivantes :

  • Ambari > HDFS > Configs > Advanced > Custom core-site > Add the storage > Account Name and key > Restarting the services
  • Avec une action de script en passant le nom et la clé du compte de stockage

Notes

Dans les cas d’utilisation valides, les limites sur le stockage Azure peuvent être augmentées via une demande adressée au support technique d’Azure.

Pour plus d’informations, consultez Ajouter des comptes de stockage supplémentaires à HDInsight.

Étapes suivantes

Lisez l’article suivant de cette série : Bonnes pratiques concernant la migration de données d’une infrastructure locale vers Azure HDInsight Hadoop.