Comment configurer un cluster ElasticSearch avec une mise à l'échelle automatique sur Amazon EC2?
Il existe un excellent tutoriel elasticsearch sur ec2 sur la configuration de ES sur Amazon EC2. Je l'ai étudié et appliqué toutes les recommandations.
Maintenant, j'ai une AMI et je peux exécuter n'importe quel nombre de nœuds du cluster à partir de cette AMI. La détection automatique est configurée et les nœuds rejoignent le cluster comme ils le devraient réellement.
La question est Comment configurer un cluster de manière à pouvoir lancer/terminer automatiquement des nœuds en fonction de la charge du cluster?
Par exemple, je veux avoir un seul nœud en cours d'exécution lorsque nous n'avons pas de charge et 12 nœuds en mode de pointe. Mais attendez, si je termine 11 nœuds en cluster, que se passera-t-il avec les fragments et les répliques? Comment être sûr de ne perdre aucune donnée dans le cluster si je termine 11 nœuds sur 12?
Je pourrais vouloir configurer passerelle S3 pour cela. Mais toutes les passerelles, à l'exception de locales, sont obsolètes.
Il y a un article dans le manuel sur allocation de fragments . Peut-être me manque-t-il quelque chose de très fondamental, mais je dois admettre que j’ai échoué à déterminer s’il il est possible de configurer un nœud pour qu’il contienne toujours toutes les copies de fragments. Mon objectif est de m'assurer que s'il s'agit du seul nœud exécuté dans le cluster, nous ne perdons toujours aucune donnée.
La seule solution que je peux imaginer maintenant est de configurer index pour avoir 12 fragments et 12 réplicas. Ensuite, lorsque jusqu'à 12 nœuds sont lancés, chaque nœud doit avoir une copie de chaque fragment. Mais je n'aime pas cette solution car je devrais reconfigurer un cluster si je souhaitais avoir plus de 12 nœuds en charge maximale.
La mise à l'échelle automatique n'a pas beaucoup de sens avec ElasticSearch.
Le déplacement et la réattribution de fragments ne sont pas un processus léger, surtout si vous avez beaucoup de données. Cela met l'accent sur IO et le réseau et peut dégrader les performances d'ElasticSearch. (Si vous souhaitez limiter l’effet, vous devez limiter la récupération de cluster à l’aide de paramètres tels que cluster.routing.allocation.cluster_concurrent_rebalance, indices.recovery.concurrent_streams, index.recovery.max_size_per_sec. récupération).
De plus, si vous vous souciez de vos données, vous ne voulez jamais avoir un seul nœud. Vous avez besoin que vos données soient répliquées. Vous aurez donc besoin d'au moins 2 nœuds (ou plus si vous vous sentez plus en sécurité avec un niveau de réplication supérieur).
Une autre chose à garder à l'esprit est que, même si vous pouvez modifier le nombre de réplicas, vous ne pouvez pas modifier le nombre de fragments. Ceci est configuré lorsque vous créez votre index et ne peut pas être modifié (si vous voulez plus de fragments, vous devez créer un autre index et réindexer toutes vos données). Ainsi, votre nombre de fragments devrait prendre en compte la taille des données et la taille du cluster, en tenant compte du nombre plus élevé de nœuds que vous souhaitez mais également de votre configuration minimale (un nombre inférieur de nœuds peut-il contenir tous les fragments et servir le trafic estimé?).
Donc, théoriquement, si vous voulez avoir 2 nœuds au plus bas temps et 12 nœuds au maximum, vous pouvez définir votre index pour avoir 6 fragments avec 1 réplica. Ainsi, lors des périodes basses, vous avez 2 nœuds contenant chacun 6 fragments, et au maximum, 12 nœuds contenant 1 fragment chacun.
Mais encore une fois, je suggère fortement de repenser cela et de tester l'impact du déplacement de fragment sur les performances de votre cluster.
Dans les cas où l'élasticité de votre application est déterminée par une charge de requête variable, vous pouvez configurer des nœuds ES configurés pour ne stocker aucune donnée (node.data = false, http.enabled = true), puis les insérer pour une mise à l'échelle automatique. Ces nœuds pourraient décharger tous les traitements de conflation HTTP et des résultats de vos nœuds de données principaux (en les libérant pour davantage d'indexation et de recherche).
Puisque des nœuds ne sont pas alloués à ces nœuds, leur mise en place de manière dynamique ne devrait pas poser de problème et la détection automatique devrait leur permettre de rejoindre le cluster.
Je peux vous donner une approche alternative en utilisant le service de recherche élastique aws (cela coûtera un peu plus cher que la commande ec2 elasticsearch normale). Écrivez un script simple qui surveille en permanence la charge (via api/cli) sur le service et si la charge dépasse les seuil, augmentez par programme les noeuds de votre cluster aws elasticsearch-service.Voici l’avantage, c’est aws qui s’occupera de la mise à l’échelle (selon la documentation, ils prennent un snaphost et lancent un tout nouveau cluster). .
En ce qui concerne l’approche de mise à l’échelle automatique, il existe des problèmes tels que le déplacement des fragments a un impact sur le cluster existant. Nous devons également faire preuve de plus de vigilance lors de la réduction. Vous pouvez trouver un bon article sur la réduction ici que j’ai testé. vous pouvez effectuer une sorte d’automatisation intelligente des étapes décrites dans le lien ci-dessus par le biais de scripts (python, Shell) ou d’outils d’automatisation tels que Ansible. La mise à l’échelle est donc réalisable.Mais encore, vous devez lancer la mise à l’échelle bien avant. les limites normales car les activités de développement peuvent avoir un impact sur le cluster existant.
Question: est-il possible de configurer un noeud pour qu'il contienne toujours toutes les copies de fragments?
Réponse: Oui, c’est possible par un routage de fragments explicite.Plus de détails ici
Je serais tenté de suggérer de résoudre ce problème différemment dans AWS. Je ne sais pas en quoi consistent les données ES, ni comment elles sont mises à jour, etc. - Partant de nombreuses hypothèses, je placerais l'instance ES derrière un ALB (équilibreur de charge d'application). J'aurais un processus planifié qui crée régulièrement des AMI mises à jour. (si vous le faites souvent, ce sera rapide), alors, en fonction de la charge de votre serveur unique, je déclencherais la création de plus d'instances à partir de la dernière instance disponible. Ajoutez les nouvelles instances à l'ALB pour partager une partie de la charge. En tant que cela, je déclencherais l'arrêt des instances temporaires. Si vous allez dans cette voie, voici quelques autres points à considérer
- Utilisez des instances ponctuelles car elles sont moins chères et si cela convient à votre cas d'utilisation
- Les instances "T" ne correspondent pas bien ici car ils ont besoin de temps pour accumuler des crédits
- Utilisez lambdas pour allumer et éteindre des objets. Si vous voulez avoir l’imagination, vous pouvez le déclencher sur la base d’une connexion Web à la passerelle aws.
- Si vous envisagez davantage votre cas d'utilisation, envisagez de placer un serveur Varnish devant votre machine ES afin de pouvoir proposer à moindre coût une mise à l'échelle basée sur une stratégie de cache (de nombreuses hypothèses ici) basée sur le stress que vous pouvez utiliser à droite TTL pour l'expulsion de cache. Découvrez la fonctionnalité de purge douce pour nos fichiers ES.
- si vous faites tout ce que je suggère ici, assurez-vous de faire en sorte que vos instances ES générées rapportent les journaux à un emplacement adressable central sur la machine ES persistante afin que vous ne perdiez pas les journaux lorsque les machines meurent.
Je pense que c'est une préoccupation générale lorsqu'il s'agit d'utiliser une architecture auto-évolutive pour répondre à des demandes temporaires, mais les données doivent encore être sauvegardées. Je pense qu'il existe une solution qui exploite EBS
mapper des fragments vers des volumes EBS spécifiques. Disons que nous avons besoin de 15 fragments. Nous aurons besoin de 15 volumes EBS
Amazon vous permet de monter plusieurs volumes. Ainsi, lorsque nous démarrons, nous pouvons commencer avec quelques instances auxquelles plusieurs volumes sont attachés.
à mesure que la charge augmente, nous pouvons créer une instance supplémentaire - jusqu'à 15.
La solution ci-dessus n’est conseillée que si vous connaissez vos besoins en capacité maximale.