Sorties

ECE 2.0 : host tagging, Machine Learning, architecture hot-warm, et plus encore

Lorsque nous avons lancé Elastic Cloud Enterprise (ECE) pour la première fois il y a plus d'un an, nous étions tous très enthousiastes et prudemment optimistes. Nous avions conçu ECE pour vous permettre de provisionner, gérer, monitorer et scaler l'ensemble de vos déploiements Elasticsearch depuis une seule et même console centralisée qui rime avec simplicité. Nous ne connaissions que trop bien les défis associés au développement d'une solution conçue pour gérer d'énormes déploiements Elasticsearch – et pour cause : nous avions rencontré les mêmes au moment ou nous mettions en place Elasticsearch Service.

Nous avons développé ECE sur exactement la même base de code qu'Elasticsearch Service. La seule différence est que nous l'avons packagée de manière à ce que les utilisateurs puissent déployer ECE où bon leur semble, tout en exploitant les mêmes logiciels éprouvés et les mêmes ensembles de fonctionnalités que ceux qui servent à gérer des milliers de clusters hébergés chez différents fournisseurs de services cloud.

Mais nous n'avons pas tardé à découvrir qu'ECE avait autant de succès auprès de grandes entreprises gérant une multitude de clusters qu'auprès d'entreprises dont la charge de travail est moindre. Tout le monde avait visiblement une bonne raison d'opter pour ECE.

L'année qui s'est écoulée nous a donné l'occasion d'apprendre des utilisateurs d'ECE, d'améliorer notre offre et de comprendre comment elle devait évoluer. Nous sommes donc ravis d'annoncer le lancement d'une version revue, corrigée et plus performante que jamais : ECE 2.0.

Cette version fait le plein d'avantages. Nous ne résistons pas au plaisir de vous dévoiler quelques-unes de nos fonctionnalités préférées. 

N'importe quel cas d'utilisation à n'importe quelle échelle

Avec ECE 2.0, l'une de nos priorités était la prise en charge de cas d'utilisation plus complexes et de plus grande envergure, comme le logging et les données de séries temporelles. Nous voulions aussi accorder un plus grand contrôle aux administrateurs concernant le déploiement et la configuration de ces cas d'utilisation par le propriétaire du cluster. Voici les principales fonctionnalités qui ont rendu tout cela possible.

Posez vos balises et faites comme chez vous

Les balises sont des paires clé-valeur ajoutées à chaque machine hébergeant l'allocator. Il s'agit d'un concept bien connu des professionnels du cloud et de l'orchestration de conteneurs, où le couplage se fait grâce à des étiquettes et des sélecteurs. ECE 2.0 permet désormais l'ajout de balises à l'allocator : autrement dit, vous pouvez maintenant intégrer des balises arbitraires à un allocator afin d'en faciliter la classification. Ces balises peuvent indiquer à quelle équipe appartient l'allocator, les caractéristiques du hardware sous-jacent auquel il est associé et, d'une manière générale, tout autre identificateur permettant de le classifier. Ces balises servent ensuite à associer les nœuds de cluster et les instances Kibana à l'allocator le mieux indiqué pour les héberger. 

host_tagging.png

Configuration d'instance personnalisée

Dans les premières versions d'ECE, tous les nœuds Elasticsearch étaient identiques. C'est-à-dire qu'ils partageaient la même configuration et les mêmes rôles. Par conséquent, lorsqu'un utilisateur voulait gérer chaque type de nœud séparément (ce qui est nécessaire dans bien des cas d'utilisation), les possibilités étaient limitées. 

Avec ECE 2.0, vous pouvez désormais déployer, gérer et scaler chaque composant de votre cluster indépendamment des autres. Les configurations d'instance disponibles avec ECE 2.0 vous permettent de définir les rôles à activer sur chaque nœud, de configurer des filtres qui associent un nœud à une machine hébergeant l'allocator grâce aux balises précédemment citées, et de définir le ratio RAM-stockage en fonction de l'utilisation prévue pour le nœud.

creating_instance_config.gif

Autre nouveauté : les modèles de déploiement

Les nouveaux modèles de déploiement personnalisables font sans conteste partie des outils les plus polyvalents de la console. En effet, un modèle de déploiement permet de regrouper un ensemble de configurations d'instance associés à différents types de nœuds, ce qui sert de structure à votre cluster. Avec les modèles de déploiement, vous pouvez définir les valeurs et les configurations par défaut de chaque type de nœud (taille du nœud, nombre de zones de disponibilité, etc.).

Vous pouvez aussi créer vos propres modèles et les configurer en fonction de votre cas d'utilisation, de votre équipe, ou de tout autre élément nécessitant un ensemble unique d'allocators. Lorsque vous créez un nouveau cluster, les modèles de déploiement vous proposent en outre des paramètres prédéfinis, ce qui vous permet de rationaliser votre processus de déploiement à chaque étape.

deployment_template.png

Gérer les index des séries temporelles avec la Suite Elastic ? Une fonctionnalité dont vous ne pourrez plus vous passer.

L'ingestion des données de séries temporelles (messages de log, par exemple) fait partie des cas d'utilisation fréquents avec la Suite Elastic. Dans ces cas-là, nous recommandons souvent de recourir à une architecture hot-warm, notamment pour les déploiements de grande envergure. 

Avec ECE 2.0, vous disposez d'un modèle d'architecture hot-warm intégré, qui vous permet de configurer deux niveaux de nœuds de données. Les nœuds de données hot servent ainsi à ingérer les données et à stocker les index les plus récents (ceux-ci étant plus susceptibles d'être exploités pour les recherches, ils doivent être déployés sur des hôtes plus puissants, qui affichent de bonnes performances E/S). Les nœuds de données warm, quant à eux, sont prévus pour le stockage et la conservation de grands volumes de données à long terme. Dans la majorité des cas, les anciennes données sont immuables et l'accès à ces dernières est beaucoup moins fréquent. Ce qui signifie que vous pouvez les stocker sur des machines hébergeant des allocators plus économiques. Moins performants, ceux-ci s'avèrent aussi beaucoup moins onéreux pour le stockage des données.

Pour définir le moment où les index doivent passer du niveau hot au niveau warm, ECE 2.0 prévoit une fonctionnalité de curation d'index intégrée qui vous permet de configurer ces périodes. Vous avez l'esprit tranquille. ECE se charge du reste.

index_curation.png

Des fonctionnalités qui convergent pour répondre à votre cas d'utilisation

Ce n'est un secret pour personne : la Suite Elastic est polyvalente et peut prendre en charge une multitude de cas d'utilisation – depuis l'analyse des logs et de la sécurité jusqu'à la recherche, en passant par les indicateurs, et plus encore. Lorsqu'ils procèdent à un déploiement, les utilisateurs peuvent se rendre compte que certains cas d'utilisation sont plus performants lorsqu'ils sont associés à un hardware donné. De plus, même au sein d'un même cluster, il peut être judicieux d'exécuter chaque type de nœud sur une machine hébergeant l'allocator qui soit associée au type de hardware approprié. Par exemple, il est possible que vos instances Kibana affichent des performances optimales lorsque vous les exécutez sur un hôte disposant d'une mémoire RAM importante, mais d'un stockage limité ; alors que vos nœuds Machine Learning, sans nécessiter un stockage important, soient plus performants sur un hôte disposant d'un processeur un peu plus puissant. 

Les fonctionnalités de host tagging, de configurations d'instance et de modèle de déploiement intégrées à ECE 2.0 vous permettent de gérer vos clusters de manière bien plus flexible, tout en vous offrant un plus grand contrôle. Sans compter qu'elles rendent possible la prise en charge native de différents types de hardware, optimisant ainsi leur utilisation, tout en améliorant les performances et en réduisant les coûts. 

Il existe mille et une manière de capitaliser sur ces fonctionnalités dans votre cas d'utilisation. Nous y consacrerons d'ailleurs un post prochainement pour les examiner de plus près. De même, nous verrons comment implémenter la configuration adaptée à vos besoins à travers quelques exemples.

Libérez toute la puissance de Machine Learning

Comme nous l'avons vu plus haut au paragraphe traitant des configurations d'instance, les précédentes versions d'ECE ne permettaient pas aux utilisateurs d'activer des rôles différents sur chaque nœud du cluster. Cela empêchait la prise en charge de Machine Learning dans les clusters hébergés, puisque l'exécution de tâches Machine Learning dans un environnement de production nécessitait des nœuds Machine Learning. 

Avec l'arrivée des configurations d'instance, vous pouvez maintenant configurer des nœuds Machine Learning dédiés, que vous pouvez gérer et scaler indépendamment des autres nœuds du cluster.

Vous pouvez aussi exploiter les configurations d'instance pour créer des nœuds maîtres dédiés, nécessaires à la prise en charge des grands clusters ou des nœuds d'ingestion dédiés. Cela s'avère particulièrement pratique si le traitement génère des durées d'ingestion importantes, et que vous voulez scaler votre couche d'ingestion à mesure que vous ajoutez des pipelines pour enrichir vos données.

scaling_instance.gif

Compatibilité avec la dernière version de Docker sur Ubuntu

Vous pouvez maintenant installer ECE sur Ubuntu 16.04 avec Docker 18.03. Voilà une importante nouveauté, puisque ECE 1.x n'était compatible qu'avec Docker 1.11, qui a officiellement atteint sa fin de vie il y a un certain temps. Vous pouvez maintenant mettre à niveau le moteur Docker sur tous les nœuds ECE.

À l'avenir, nous annoncerons la prise en charge des nouvelles versions de Docker de façon plus régulière, de manière à nous aligner sur la version LTS de Docker, qui sort tous les deux ans.

Authentification SAML pour les déploiements

ECE proposait déjà des intégrations de sécurité et d'authentification, telles que LDAP/AD, pour tous vous déploiements. Avec ECE 2.0, nous passons à l'étape supérieure avec l'authentification SAML.

Compatibilité de la mise à niveau

Bien qu'ECE 2.0.0 soit une version importante, toutes les fonctionnalités décrites ci-dessus sont rétrocompatibles. Cela signifie que vous pouvez mettre à niveau ECE 1.x vers ECE 2.0.0, tout en bénéficiant de l'ensemble des avantages de la nouvelle version.

Une interface plus conviviale

Côté console utilisateur, nous avons apporté beaucoup d'améliorations pour vous faciliter la vie. En voici quelques-unes :

  • Exit, les clusters. Bienvenue aux déploiements : avec la prise en charge d'autres produits de la Suite Elastic, il était plus logique d'employer un terme plus générique pour désigner ce que vous créez avec ECE. Bien que les clusters Elasticsearch soient des éléments essentiels de tout déploiement, le terme "déploiement" reflète mieux la façon dont la Suite Elastic est gérée dans ECE.
  • Workflow "Create Deployment" : un nouveau workflow "Create Deployment" était nécessaire à la prise en charge des configurations d'instance et des modèles de déploiement. Ce nouveau workflow vous permet d'affiner vos configurations, d'enregistrer les valeurs et configurations par défaut de vos déploiements et de sélectionner le modèle de votre choix pour en créer de nouveaux.
  • Simplification de la navigation : nous avons revu la navigation pour vous permettre de vous y retrouver plus facilement dans l'IU et de modifier vos déploiements plus simplement. De même, la page d'aperçu de tous les déploiements et l'aperçu détaillé d'un déploiement donné ont fait peau neuve : ils affichent maintenant les informations et les actions possibles de manière plus pertinente.
  • Nous pensons aussi à ceux qui sont plutôt du soir : si vous aimez travailler lorsque le soleil se couche, ECE vous permet de définir un "thème nuit" plus reposant pour les yeux.

Et ce ne sont là que quelques-unes des nouvelles fonctionnalités que vous réserve ECE 2.0. Pour en savoir plus, reportez-vous aux notes de publication. Envie de juger ECE 2.0 par vous-même ? Lancez-vous grâce à notre essai gratuit de 30 jours et dites-nous ce que vous en pensez.