Ambari – Comment utiliser les blueprints

Ambari – Comment utiliser les blueprints

En tant qu’ingénieurs d’infrastructure chez Adaltas, nous déployons des clusters. Beaucoup de clusters.

Généralement, nos clients choisissent d’utiliser une distribution telle que HDP ou CDH, qui viennent avec leurs solutions de déploiement: Ambari et Cloudera Manager respectivement.
Ces outils permettent de déployer des clusters facilement depuis leurs interfaces simples et bien documentées.

Bien que pratique pour le déploiement d’un ou deux clusters, devoir remplir plusieurs centaines de champs à coup d’innombrable copier/collés lors du déploiement d’une douzaine devient une tâche difficile. C’est ici qu’intervient l’automatisation.

Dans cet article, nous nous concentrerons sur l’outil de déploiement de HDP : Ambari, et ses fichiers de définition de cluster : les blueprints.

Que sont les blueprints

Il y a deux définitions aux blueprints dans un environnement Ambari. La première est celle donnée par la documentation d’Ambari :

Ambari Blueprints are a declarative definition of a cluster. With a Blueprint, you specify a Stack, the Component layout and the Configurations to materialize a Hadoop cluster instance (via a REST API) without having to use the Ambari Cluster Install Wizard.

Littéralement :

Ambari Blueprints sont une définition déclarative d’un cluster. Avec un Blueprint, vous spécifiez une Stack, la disposition des composants, et les configurations qui matérialisent une instance de cluster Hadoop (via une API REST), sans avoir à utiliser le Wizard d’installation de cluster Ambari.

Il s’agit de la définition de la technologie Ambari Blueprint dans sa globalité. En pratique, cette technologie se compose de la soumission de deux fichiers JSON l’un après l’autre via l’API REST d’Ambari.

Un de ces fichiers, le premier à être soumis, est la seconde définition d’un blueprint. Il représente un template qui peut être utilisé pour autant de déploiement de cluster que nécessaire.
Puisqu’il est utilisé pour définir plusieurs clusters à travers différents environnements, il doit être le plus générique possible.

Le second fichier quant-à lui est utilisé pour définir toutes les propriétés spécifiques à une instance de cluster. Nous l’appellerons ici le fichier cluster. Ambari utilise les informations du fichier blueprint complétées par celles du fichier cluster pour démarrer le processus de déploiement. Les propriétés définies dans le fichier cluster surchargent celles du fichier blueprint lorsque nécessaire.

Ceci est à quoi ressemble un déploiement de cluster utilisant les blueprints Ambari :

  1. Installation et configuration d’Ambari de façon à être pret à recevoir la requête de déploiement de cluster
  2. Création et soumission du fichier blueprint.json via l’API REST d’Ambari
  3. Création et soumission du fichier cluster.json via l’API REST d’Ambari
  4. Attente de la fin du processus de déploiement
  5. Tuning des configurations définies automatiquement par le stack advisor d’Ambari.

Structure de fichier – blueprint.json

Le fichier blueprint.json a trois catégories à sa racine :

  • Blueprints, les informations globales du blueprint, qui incluent le nom de la stack et sa version, ainsi que le type de la sécurité.
  • host_groups , le profil des hôtes et les composants déployés sur chacun d’eux.
  • configurations , la plupart des configurations de ses composants qui n’ont pas leurs valeurs par défaut.

A ce point, votre fichier JSON devrait ressembler à ceci :

Contenu de catégorie – blueprints

Ambari supporte le déploiement de plusieurs stacks. Celle pour laquelle il est le plus utilisé est la stack HDP d’hortonworks. C’est celle que nous utiliserons ici dans notre exemple.
Quant-à la sécurité, choisissez entre NONE et KERBEROS . Vous pouvez ajouter un kerberos_descriptor personnalisé, mais il n’a pas été requis dans notre cas et ne sera donc pas évoqué d’avantage ici.

Voici un exemple simple et fonctionnel de votre catégorie Blueprints pour un cluster HDP 2.6 kerbérisé :

Contenu de catégorie – host groups

Les host groups définissent un template à associer à un groupe d’hôtes au sein d’un cluster.

Voici les informations que vous pouvez définir comme template pour un groupe d’hôtes :

  • les composants qui seront déployés sur chacun des hôtes associé à ce profil
  • le nombre d’hôtes attendus pour un profil donné
  • certaines configurations personnalisées qui ne seront appliquées qu’aux hôtes de ce profil
  • un nom qui définit le mieux les hôtes de ce profil

Quelques exemples de groupes d’hôtes qui vous pouvez définir dans cette section : management nodes, worker nodes, master nodes, edge nodes…

Notez que vous devrez probablement définir plusieurs profils pour les master nodes, car ceux-ci ne partagent habituellement pas les même composants.

Pour HDP 2.6, voici la liste de composants disponibles :

Un exemple de groupe d’hôtes pour les worker nodes :

Contenu de catégorie – configurations

C’est à cet endroit que la majorité des configurations personnalisées sont positionnées.

Il n’est pas nécessaire de définir toutes les propriétés de chaque composant à déployer. La plupart ont des valeurs par défaut, et Ambari fournit un stack advisor qui en positionne automatiquement d’autres en fonction de l’infrastructure cible. Ajoutez uniquement celles que seuls vous pouvez définir.

La structure d’une entité de configuration est la suivante :

 

Une catégorie de configuration est un ensemble de propriétés habituellement retrouvées dans un fichier de configuration particuler. Quelques exemples de fichier de configuration sont : core-site, hdfs-site, hadoop-env, zookeeper-env, etc.

Pour récupérer la list exhaustive de catégories de configuration supportées par Ambari, vous pouvez soit exporter un blueprint d’un cluster existant qui a les même composants que vous souhaitez déployer, ou jeter un oeil aux sections de configurations sur l’UI. Cependant soyez vigilant, car Ambari divise certaines catégories en plusieurs sections. Par exemple, les propriétés de la catégorie “core-site” peuvent être trouvées dans les sections “Advanced core-site” et “Custom core-site”, mais seront définies dans une unique catégorie “core-site” dans un fichier blueprint.

De plus, une bonne pratique est de laisser Ambari définir les ressources allouées à vos composants dans un premier temps, et les tuner par la suite à travers l’UI.

Il y a une catégorie de configuration qui n’est pas dans l’UI et n’est pas associée à un composant à déployer : cluster-env. C’est une catégorie spéciale pour les propriétés propres à Ambari, et est utilisée par celui-ci pour définir comment exécuter le déploiement. Si vous avez déjà déployé un cluster à travers l’UI, vous remarquerez que ces propriétés correspondent à celles de l’onglet Misc.

Voici une partie de ce que pourrait contenir la catégorie de configuration :

 

Dans l’exemple précédent, vous avez pu remarquer une valeur HOSTGROUP::zk_node% . Il s’agit d’une variable qui sera remplacée par tous les noms d’hôtes correspondant au groupe d’hôtes “zk_node”. Soyez cependant vigilant lors de son utilisation car la conversion n’est pas supportée par toutes les propriétés.

Les propriétés connues qui gèrent la conversion des variables %HOSTGROUP::hg_name%  :

Lorsqu’elles ne sont pas supportées et que vous ètes contraints d’ajouter les noms d’hôtes réels, définissez ces propriétés dans le fichier cluster.json.

Structure de fichier – cluster.json

Là où le fichier blueprint.json représente le template d’un déploiement de cluster, le fichier cluster.json est l’instanciation d’un déploiement.
Ce dernier est donc spécifique à un déploiement de cluster, et contient des valeurs définies en dur.

Le fichier cluster.json a cinq catégories à sa racine :

  • blueprint , le nom du blueprint (template) créé précédemment. Son nom est définit à sa soumission.
  • host_groups , le mapping entre les noms d’hôtes réels de votre infrastructure et les profils auxquels ils appartiennent définits dans le blueprint.
  • configurations , les propriétés spécifiques à ce déploiement de cluster.
  • security , qui a la même valeur que a propriété de la section “Blueprints” du fichier blueprint.json.
  • credentials , les informations de connexion au KDC pour un cluster kerbérisé.

Votre fichier JSON devrait maintenant ressembler à ceci :

Contenu de catégorie – host groups

A l’inverse du blueprint, la section host_groups dans le fichier cluster.json sert à associer des hôtes existants à un template définit plus tôt.

Sa structure est relativement intuitive, puisqu’il suffit d’ajouter le nom d’un template, et de lui assigner une liste de noms hôtes :

En reprennant l’exemple du profil des workers nodes, voici ce que cela donnerait :

Contenu de catégorie – configurations

La majorité de vos configurations devraient déjà avoir été définies dans le fichier blueprint.json, puisqu’elles peuvent être utilisées pour différentes implémentations de cluster.

Il y a cependant deux types de propriétés qui sont limitées à un déploiement :

  • les configurations dépendantes de l’environnement (utilisateurs et infrastructure)
  • les configurations qui ne gèrent pas la conversion de la variable %HOSTGROUP::hg_name%

Vous pouvez également ajouter les propriétés qui utilisent celles mentionnées ci-dessus.

Dans la première catégorie, vous trouverez principalement les informations de connexion aux bases de données, d’authentification, et liées au métier comme par exemple les files YARN.

Voici est un exemple de ces configurations :

Les propriétés suivantes sont connues pour ne pas gérer la conversion de %HOSTGROUP::hg_name%  :

La catégorie configuration garde la même structure que dans le fichier blueprint.json. Voici un exemple :

Contenu de catégorie – credentials

Pour les même raisons que les propriétés définies dans cette section, les credentials du KDC d’un cluster sécurisé doivent être définies par déploiement.

Voici la structure de ceux-ci :

Usage de l’API REST Ambari

Avant de commencer, vérifier que le serveur et les agents Ambari auquel vous souhaitez soumettre le blueprint sont bien démarrés. Le répertoire ambari distant doit également être accessible pour l’installation de composants tels que Ambari-Infra ou Ambari-Metrics.

Repositories registration

Tout d’abord, reseignez les liens des répertoires HDP à utiliser pour ce déploiement. Ceci peut être fait via la requête suivante :

Pour renseigner les répertoires publics d’hortonworks pour HDP 2.6 sur redhat 7, utilisez ceci :

Soumission des fichiers blueprint

Comme vu précédemment, commencez par soumettre le fichier blueprint. Pour la valeur de ${blueprint_name} , utilisez la même que celle de la propriété blueprint du fichier cluster.json.

Enfin, soumettez la définition de ce cluster particulé. Il prendra le nom définit par la valeur ${cluster_name}.

Conclusion

Même en utilisant les blueprints, beaucoup de paramètres de configuration sont à définir. Il peut même être plus fastidieux de créer un seul blueprint que de remplir la multitude de champs pour chaque service dans le wizard d’Ambari. L’usage des blueprints sera utile lors du déploiement de multiple clusters ou de la création et destruction d’environnements à la volée.

Pour ceci, plus que les blueprints seront nécessaires. Pour l’un de nos clients par exemple, nous avons utilisé Puppet pour automatiser la préparation des serveurs et l’installation du serveur et des agents Ambari. Une fois ceci terminé, un script ruby personnalisé est exécuté pour générer les fichiers blueprint.json et cluster.json, et soumettre ceux-ci au Ambari nouvellement installé. Cette solution peut-être remplacée par Ansible ou même un outils d’orchestration personnalisé.

Pour conclure, les blueprints Ambari permettent l’automatisation du déploiement d’un cluster HDP (ou toute autre distribution), mais peuvent difficilement le faire seuls. Choisissez l’outil qui correspond le mieux à votre besoin ou qui est actuellement utilisé par votre société, et ajoutez-y un générateur JSON pour les fichiers blueprint.json et cluster.json.

By | 2018-03-20T13:54:04+00:00 January 17th, 2018|Big Data|0 Comments

About the Author:

Leave A Comment