4 Elasticsearch est un moteur de recherche qui offre une recherche plein texte distribuée avec une interface web HTTP. Les entreprises, dont de nombreux clients Scality, utilisent Elasticsearch pour retrouver rapidement pratiquement tout type de document ou d’information au sein de leur organisation. Avec un volume de données à indexer, rechercher et conserver qui ne cesse de croître, l’un des défis potentiels auxquels sont confrontés les clients d’Elasticsearch est le coût élevé du stockage SAN utilisé comme niveau de stockage principal. La bonne nouvelle, c’est qu’Elasticsearch intègre les snapshots interrogeables (en anglais), qui permettent de réaliser des snapshots d’index, voire de clusters entiers, et de les stocker sur du stockage objet compatible Amazon S3 comme les solutions de référence de Scality RING et ARTESCA. Scality offre une solution de stockage plus économique et plus évolutive que les systèmes SAN. Elle permet également aux clients de continuer à profiter de la puissance d’Elasticsearch tout en augmentant la durabilité des données et en réduisant le coût total de possession (TCO). Grâce aux snapshots interrogeables (en anglais) d’Elasticsearch, les clients peuvent stocker l’ensemble de leurs données inactives sur Scality. Cela libère le stockage SAN, plus coûteux, utilisé par Elasticsearch. Avec une évolutivité à l’échelle du pétaoctet et une durabilité des données pouvant atteindre onze 9, Scality protège non seulement vos précieuses données Elasticsearch, mais vous permet aussi de continuer à les interroger sans avoir à les rapatrier sur le SAN. Comment configurer Elasticsearch et Scality RING Dans cette section, nous allons passer en revue les étapes simples nécessaires pour configurer Scality comme référentiel de reprise après sinistre (DR) ou de snapshots interrogeables. Nous avons utilisé la console Elasticsearch Cloud à titre d’illustration ; toutefois, ces étapes sont identiques si vous exécutez Elasticsearch sur Amazon Web Services, Microsoft Azure, Google Cloud ou sur site. Plutôt que de stocker toutes nos données dans le cloud public, nous avons choisi de conserver nos snapshots et nos snapshots interrogeables dans une installation sur site de Scality RING. Notez que la configuration de Scality ARTESCA est identique. Ingestion des données Nous avons ajouté des données à l’aide de filebeat et simulé l’ingestion de logs Apache provenant d’un serveur web. Plutôt que de générer un véritable trafic web sur le serveur, nous avons utilisé gogen configuré dans une tâche crontab comme suit : Les logs sont envoyés vers le cluster Elasticsearch à l’aide de filebeat. Les instructions d’installation de filebeat sont détaillées dans l’interface Elasticsearch : Une fois que les logs commencent à être chargés dans le cluster Elasticsearch, Elasticsearch affiche le message « Data successfully received from this module. » Configurer Scality comme référentiel de snapshots Pour mettre en place des snapshots interrogeables, vous devez d’abord créer un bucket dans Scality, ce qui peut se faire à l’aide du navigateur S3. Notez que le paramètre facultatif de chiffrement du bucket peut être activé si le chiffrement des données au repos est requis. Une fois le bucket créé, vous pouvez l’enregistrer sur le cluster Elasticsearch via l’interface Kibana, dans « Dev Tools », puis créer la requête PUT suivante : Le référentiel « scality_s3_repository » nouvellement créé est désormais disponible pour stocker des snapshots de cluster (à des fins de DR) ou des snapshots interrogeables (dans les niveaux cold ou frozen). Créer des snapshots à des fins de DR Les snapshots de DR servent à restaurer l’ensemble des données d’un cluster Elasticsearch en cas de panne majeure. Utiliser une cible S3 est une solution simple pour externaliser ces données de sauvegarde sur un référentiel durable et garantir leur disponibilité en cas de besoin. Créer un snapshot Dans la section « snapshot & restore », il suffit de créer une nouvelle stratégie de snapshot en veillant à sélectionner « scality_s3_repository ». Les snapshots apparaissent ensuite dans la liste au fur et à mesure de leur création. Restaurer des snapshots Les snapshots sont autodescriptifs : vous pouvez donc à tout moment les restaurer sur un cluster Elasticsearch vierge si votre cluster Elasticsearch principal est perdu. Pour cela, vous devez d’abord enregistrer le référentiel S3 comme expliqué ci-dessus, puis suivre les étapes de la section « Snapshots and restore ». Une fois la restauration terminée, vous pouvez commencer à interroger vos données. Utiliser les snapshots pour les niveaux cold et frozen Une fois le référentiel de snapshots configuré, les snapshots interrogeables peuvent facilement être activés dans le niveau cold ou frozen en configurant une stratégie ILM (Index Lifecycle Management) qui fait passer les données d’un niveau à l’autre. Dans cet exemple, nous utilisons le panneau de configuration des stratégies ILM pour définir Scality comme niveau frozen. Les logs stockés dans le niveau frozen restent interrogeables et sont accessibles de manière transparente depuis l’interface ou les API d’Elasticsearch. Conclusion Comme la plupart des applications big data, Elasticsearch a été intégré au stockage objet afin de permettre aux clients de gérer efficacement des volumes de données toujours croissants, qui ne peuvent plus être stockés uniquement sur un stockage tier one coûteux. Avec Elasticsearch et Scality, les utilisateurs bénéficient des avantages suivants : Optimisation de l’infrastructure Elasticsearch, qui n’a plus à gérer que les données chaudes, ce qui réduit les coûts et la complexité Stockage des données moins fréquemment consultées sur un stockage hautement évolutif, très durable et économique Possibilité pour les utilisateurs d’interroger rapidement des données froides ou archivées, quelle que soit leur ancienneté
