Exécuter des workloads d'entreprise dans le Cloud avec Cloudbreak

Cet article se base sur la conférence de Peter Darvasi et Richard Doktorics “Running Enterprise Workloads in the Cloud” au DataWorks Summit 2018 à Berlin.

Il présentera l’outil de déploiement automatique d’Hortonworks pour le Cloud : Cloudbreak, décrira et commentera certaines fonctionnalités expliquées par Peter et Richard, et donnera des recommandations personnelles sur quand et pourquoi l’utiliser.

Qu’est ce que Cloudbreak

Hortonworks défini Cloudbreak de la façon suivante :

Cloudbreak simplifies the deployment of Hortonworks platforms in Cloud environments [… and] enables the enterprise to quickly run Big Data workloads in the Cloud while optimizing the use of Cloud resources.

Ce qui signifie littéralement :

Cloudbreak simplifie le déploiement de plateformes Hortonworks sur des environnements Cloud [… et] permet aux entreprises de rapidement exécuter des workloads Big Data dans le Cloud tout en optimisant l’usage de ses ressources.

En d’autres mots, Cloudbreak permet de provisionner l’infrastructure de vos clusters à travers les fournisseurs de services Cloud, d’installer Apache Ambari, et de lui soumettre une requête de déploiement de cluster. Gardez cependant en mémoire que Cloudbreak s’occupe uniquement de l’infrastructure et de l’installation d’Ambari. Le déploiement du cluster est encore effectué par ce dernier.

License

Bien qu’absent de la liste des projets portés par la fondation Apache et son incubateur, Cloudbreak est tout de même open-source et disponible sous la license Apache.

Contrairement à des projets tels que Apache Ambari ou Apache Ranger, Cloudbreak est presque développé à 100% par Hortonworks, et de ce fait n’a pas l’obligation de supporter d’autres distributions que HDP et HDF.

Ceci présente des avantages et des inconvénients. Hortonworks va garantir que Cloudbreak soit optimisé pour Ambari et HDP/HDF, et aura plus de flexibilité via le contrôle total sur le repository du projet. Cependant, il sera bien plus difficile d’ajouter à l’outil une fonctionnalité personnalisée pour votre métier de la même manière que vous pouviez en avoir l’habitude avec des produits comme Apache Ranger.

Support d’infrastructure

Puisque Cloudbreak est conçu pour exécuter des déploiements de clusters sur des environnements Cloud, il nécessite des moyens afin de créer et d’interagir avec ses infrastructures. Ceci lui est fourni à travers les divers fournisseurs de services Cloud sur lesquels les clusters HDP/HDF doivent être poussés.

Actuellement, voici les fournisseurs supportés par Cloudbreak :

Comment l’utiliser

La première chose dont vous aurez besoin est une instance de Cloudbreak Deployer. Depuis celle-ci vous serez en mesure de lancer les déploiements de vos clusters sur les multiples fournisseurs de services Cloud disponibles.

Cloudbreak Deployer

Ici, deux choix s’offrent à vous : image pré-buildée ou VM personnalisée.

Des images pré-buildées existent pour chaque fournisseur de services supportés. Celui-ci peut être différent de ceux sur lesquels vous souhaitez déployer vos clusters. Vous pouvez donc faire tourner le Cloudbreak Deployer sur une instance AWS, et déployer vos clusters sur Azure et GCP.

Chaque fournisseur de services a ses propres prérequis. Par exemple, les images AWS n’existent qu’en AMI, alors qu’OpenStack est uniquement supporté avec Centos 7.X.

Alternativement, vous pouvez installer Cloudbreak Deployer sur votre propre VM personnalisée. Ceci est particulièrement utile pour les environnements de production en entreprise qui présentent souvent des contraintes système et logicielles auxquelles ne répondent pas les images pré-buildées.

Les prérequis systèmes décrits par Hortonworks pour la VM hébergeant Cloudbreak Deployer sont les suivants :
- minimum de 16GB de RAM, 4 cpu, et 40GB de disques
- RHEL, CentOS, et Oracle Linux 7 (varie en fonction des images pré-buildées)
- Docker 1.9.1

Pour chaque Cloud sur lequel Cloudbreak doit gérer des infrastructures, Cloudbreak Deployer nécessite des accès privilégiés au fournisseur de service correspondant.

Déployer un cluster partie 1 - Ambari Blueprints

Maintenant que Cloudbreak Deployer est fonctionnel, un premier cluster peut être déployé. Pour cela Cloudbreak nécessite deux types d’informations. La première est la définition du cluster.

La définition du cluster est directement passée par Cloudbreak à Ambari. [Ambari. requiert la définition d’un Blueprint pour déployer un cluster.

Vous pouvez soit utiliser une des configurations de cluster disponibles par défaut dans Cloudbreak, ou utiliser un blueprint personnalisé créé en avance. Pour plus d’information sur comment créer un blueprint personnalisé, venez lire cet article sur notre blog.

Attention ! Comme vous le savez peut-être, le blueprint JSON d’Ambari ne gère qu’une partie de la définition d’un cluster. L’autre partie, qui est passée au moment de l’exécution du déploiement, doit être définie séparément dans Cloudbreak. Certaines informations sont automatiquement renseignées par Cloudbreak, telles que le mapping des hosts à leurs hostgroups respectifs. D’autres cependant, comme le nom du blueprint ou les sources externes d’authentification (LDAP par exemple) ou bases de données, doivent être spécifiées manuellement dans les champs adéquats dans Cloudbreak. La documentation officielle contient une liste exhaustive des étapes à ce sujet.

Déployer un cluster partie 2 - Infrastructure

Le second type d’information concerne les environnements Clouds sur lesquels le cluster doit être déployé.

Cette partie est relativement intuitive, puisqu’il suffit de suivre les étapes du CLI en ligne de commande ou du Wizard Cloudbreak et de remplir les champs avec les informations adéquates.

Cela comprend :

Des informations générales sur le cluster, tels que son nom, le fournisseur de services Cloud, la région choisie pour l’héberger et la version HDP à déployer,
Le type d’instances pour chaque hostgroup, leur nombre, et le noeud sur lequel installer Ambariserver,
Des informations réseau et sécurité (définies par le fournisseur de services Cloud, et non pour les composants mêmes du cluster),
Les credentials administrateur d’Ambari.

Fonctionnalités présentées

Peter et Richard ont parlé de plusieurs fonctionnalités, dont certaines sont déjà bien connues et prêtes pour un déploiement en production, d’autres arrivées plus récemment et des avant-premières techniques.

Mise à l’échelle automatique et Alertes

Le cas d’usage principal que Cloudbreak vise à gérer est l’allocation dynamique de clusters et le dimensionnement en fonction du workload. Pour répondre à cette problématique, une fonctionnalité pas si nouvelle pour Cloudbreak est la mise à l’échelle automatique de l’infrastructure d’un cluster.

Pour exécuter une mise à l’échelle, vous devez d’abord définir un événement qui le déclenchera. Ceci est fait via des alertes. Celles-ci peuvent être basées sur des métriques (par exemple l’utilisation de YARN est supérieure à 80% pendant au moins 2 heures) ou basée sur le temps (par exemple, vérifier toutes les 12 heures si l’utilisation de YARN est supérieure à 80%).

Ces alertes, pour induire une mise à l’échelle de l’infrastructure, doivent être mappées à une politique de mise à l’échelle. Cette politique définit quels hostgroups doivent être rééchelonnés, quels ajustements doivent être effectués et quelle alerte la déclenche.

Cloudbreak supporte les alertes d’Ambari et de Prometheus en tant que sources. Des alertes personnalisées peuvent être définies via l’UI de Cloudbreak.

Dans les faits, il s’agit d’une fonctionnalité très pratique qui est requise par la plupart des équipes d’infrastructure avec lesquelles nous avons eu à travailler.

Certaines ont même leur propre processus d’alerte personnalisé qui, avec un peu de développement, peut utiliser la fonctionnalité de “remise à l’échelle par alerte” de Cloudbreak.

Images personnalisées

Dans cette section, Peter et Richard ont présenté deux fonctions distinctes autour des images utilisées par Cloudbreak.

La première est de pouvoir utiliser vos propres images personnalisées au lieu des images par défaut de chaque fournisseur de Cloud (AMI pour AWS, Centos 7.X pour les autres). Ceci est généralement une exigence pour un outil d’entreprise, car la plupart des entreprises ont un contrat avec un fournisseur de système particulier comme RedHat ou ont leur propre image personnalisée pour un usage interne.

La seconde consiste à utiliser des images prêtes à l’emploi. Cela signifie des images sur lesquelles Ambari et/ou HDP sont pré-installées. Les principaux avantages des images prêtes à l’emploi sont le temps de déploiement plus rapide et l’absence de pré-requis d’accès à des référentiels pouvant se trouver sur un autre réseau. Cependant, cela vient avec un manque important de flexibilité car ces images sont bloquées sur une version d’Ambari et de HDP.

À moins que vous n’ayez besoin d’une rapidité de déploiement supplémentaire pour le déploiement d’un cluster éphémère ou avec une durée de vie courte, il est habituellement recommandé de rester avec les images froides standard. Le peu de travail épargné par l’impossibilité d’accéder à des référentiels distants (avec un proxy par exemple, voir la section suivante) ne justifie pas les coûts opérationnels de reconstruction d’une nouvelle image prête à l’emploi chaque fois qu’Ambari ou HDP sont mis à jour.

Configurations de proxy mutualisées

Voici un cas d’usage courant dans le Cloud : vous disposez d’une instance Cloudbreak qui gère plusieurs clusters dynamiquement échelonnés, répartis en plusieurs dizaines à plusieurs centaines de nœuds de type et d’utilisation différents, sur plusieurs fournisseurs de services Cloud.

Les entreprises avec ce cas d’usage exigent habituellement une certaine sécurité et demanderont une isolation du réseau afin que leur infrastructure ne soit pas accessible de l’extérieur. Mais il existe toujours des exceptions telles que les dépendances logicielles ou les référentiels publics requis par les composants internes, qui nécessiteront ces accès distants.

C’est là qu’interviennent les proxy. Mais pour une infrastructure comme celle décrite précédemment, la mise en place d’un proxy simple devient une véritable corvée. Cloudbreak a donc implémenté une fonctionnalité relativement mineure mais pratique qui vous permet de définir des informations de proxy à un seul endroit, et de les appliquer au composant Cloudbreak Deployer sur certains ou tous vos clusters. Cloudbreak appliquera ensuite les informations proxy à divers endroits tels que les configurations Ambari et yum, ou les variables d’environnement HTTP_PROXY et HTTPS_PROXY.

Conclusion

Seule une partie des fonctionnalités abordées par Peter et Richard dans leur présentation ont été discutées dans cet article. J’ai choisi celles-ci parce qu’elles me paraissaient soit uniques à Cloudbreak, soit ont corrigé d’une certaine manière une problématique que j’ai rencontrée chez un client, soit étaient simplement intéressants à partager et à discuter. Beaucoup d’autres fonctionnalités ont été présentées dans leur discours, telles que les mises à jour de l’interface utilisateur et de la commande CLI de Cloudbreak, l’intégration de fonctionnalités de sécurité comme l’authentification Kerberos et LDAP/AD, le support de HDF, etc…

Dans l’ensemble, Cloudbreak est un projet intéressant, qui aura certainement son utilité à l’avenir au vu de la croissance des solutions basées sur le cloud et les conteneurs, mais n’est à mon avis pas encore prêt pour des projets d’entreprise en production. Le coût d’entrée pour tester la technologie est également trop élevé. La seule utilisation réelle dans laquelle je recommanderais l’utilisation de Cloudbreak pour le moment serait pour les entreprises qui bénéficieraient grandement d’un outil de gestion unique pour administrer l’infrastructure de plusieurs clusters de courte/moyenne durée partagés entre différents fournisseurs de services cloud.

Partagez cet article