Je me posais une question aujourd'hui, je travaille sur la future mutualisation des plateformes ELK de mon client. (Une plateforme en 6.4.2 et une en 5.4.2)
L'idée sera de passer notamment de la version 5.4.2 à la 6.8.0 et de la 6.4.2 à la 6.8.0.
Mais avant la migration, je souhaiterais déjà mettre d'aplomb la plateforme en version 5.
Aujourd'hui, les shards sont par défaut à la valeur de base, c'est à dire à 5 shards et 1 replicas.
Afin d'optimiser l'espace disque, je souhaiterais passer de 5 à 2 shards.
J'ai donc pour cela modifier le _template/default, et tout s'est bien passé. Mais à la création automatique de nouveaux indexes (basés sur un nommage bien précis), ils continuent à se créer avec 5 shards.
Dans la version 6, j'ai vu qu'il y avait une option index_patterns que je peux positionner sur ["*"] afin de prendre en compte tous les indexes, mais cette option n'a pas l'air d'exister sur la version 5.x.
Est-ce qu'il y a un moyen de forcer du coups les shards de 5 à 2 en prenant en compte le fait que des indexes portent déjà ce nom?
Je veux pas qu'il modifie les anciens, car impossible, mais bien que les prochains créés soient bien à 2 shards.
En espérant avoir été clair.
Elastiquement.
Jonathan
Ensuite il faut que tu regardes la liste complète des templates qui sont dans ton cluster. Ils sont appliqués suivant leur poids. Donc un index template peut en écraser un autre.
D'ailleurs, pourquoi deux shards ? Pourquoi pas un seul ?
Merci pour ce retour.
Je vois la nuance maintenant, je pensais qu'ils avaient dissocié les deux.
Par contre je ne savais pas que les templates était appliqués selon leur poids, j'ai d'ailleurs renseigné le champs "order" pour m'assurer qu'il soit bien pris en compte en premier.
Alors pourquoi deux shards, c'est une contrainte client, du coups je ne fais que suivre leurs directives de ce côté là.
C'est beaucoup moins sûr.
Je tente simplement d'optimiser avec ce que j'ai, c'est pas tous les jours facile et je découvre toujours de nouvelles blagues.
Merci pour l'information.
En fait c'est variable selon les clients, mais on a des shards avec bien plus de données, comme je joue sur une configuration d'un template par défaut pour l'ensemble des clients, je pense que 2 n'est pas déconnant. Je vais continuer l'inventaire et voir s'il serait pas plus intelligent de faire des templates dédiés selon l'utilisation.
Très bonne vidéo, ça permet d'avoir une notion plus claire du fonctionnement.
Et effectivement ça dépend ^^
Le client pour lequel je travaille fait au plus simple car personne ne maintenait les plateformes, si deux shards ont été choisis, c'est principalement pour répondre au besoin général par défaut. Nous avons des indexes dépassant les 100Go comme nous en avons de moins de 1Go... la marge est grande, et il faudrait faire des templates au cas par cas pour affiner l'infra actuelle, mais ça me demanderait bien trop de boulot en plus de ma mission.
Sur la vidéo, tu parles du round robin, est-ce que l'allocation sur les serveur est intelligente en fonction de l'espace disque disponible?
Je me retrouve avec cette problématique où des serveurs sont arrivés à 85% et où d'autres sont aux alentours de 50%
Un rééquilibrage de charge serait idéal pour lisser l'espace occupé sur la totalité du cluster.
Merci encore pour toutes tes réponses, et travaillant dans une société qui est mentionnée dans la vidéo, avoir une certification dans la suite elasticsearch serait vraiment bénéfique je pense pour moi.
Pas de rapport avec le round robin je pense. Mais pour répondre à ta question, Elasticsearch va décider de ne plus allouer de nouveaux shards sur un noeud en fonction de la taille dispo sur ce noeud. Regarde Disk-based shard allocation | Elasticsearch Guide [8.11] | Elastic
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.