Parfois, la réduction du nombre de shards dans un cluster tout en conservant la même quantité de données conduira à une utilisation plus efficace des ressources système (CPU, RAM, IO).
Dans ces situations, nous considérons le cluster comme “oversharded”.
Le nombre de shards où cette definition se produit dépend de divers facteurs, notamment le matériel disponible, la charge d’indexation, le volume de données, les types de requêtes exécutées sur le cluster, le volume de ces requêtes et le volume de données interrogées.
Les tests sur des données de production avec des requêtes de production sur le matériel de production sont le seul moyen de calibrer les tailles de shards optimales. Des tailles de shard de dizaines de Go sont couramment utilisées, et cela peut être un point de départ utile pour expérimenter. Les metriques Elasticsearch présentes dans Kibana fournissent une vue utile des performances historiques du cluster lors de l’évaluation de l’impact de différentes tailles de shard.
Veuillez consulter le guide des bonnes pratiques suivant pour garder les shards sous contrôle :
Chaque segment contient des métadonnées qui doivent être conservées dans la mémoire (heap). Ceux-ci incluent des listes de champs, le nombre de documents et des dictionnaires de termes. Au fur et à mesure qu’un shard grandit, la taille de ses segments augmente généralement car les segments plus petits sont fusionnés en segments moins nombreux et plus grands. Cela réduit généralement la quantité de heap requise par les métadonnées de segments d’un shard pour un volume de données donné. Au strict minimum, les shards doivent être au moins supérieurs à 1 Go pour optimiser l’utilisation de la mémoire.
Cependant, même si les shards commencent à être plus économes en mémoire autour de 1 Go, un cluster plein de shards de 1 Go fonctionnera probablement encore mal. En effet, le fait d’avoir de nombreux petits shards peut également avoir un impact négatif sur les opérations de recherche et d’indexation. Chaque requête ou opération d’indexation est exécutée dans un seul thread par shard d’index interrogé ou indexé. Le nœud recevant une demande d’un client devient responsable de la distribution de cette demande aux shards appropriés, ainsi que de la fusion des résultats de ces shards en une seule réponse. Même en supposant qu’un cluster ait suffisamment de thread disponibles dans les thread pool d’écriture et de recherche pour traiter immédiatement l’action demandée contre tous les shards requis par la requête. La surcharge associée à l’envoi de requêtes réseau aux nœuds contenant ces shards et à la nécessité de fusionner les résultats de nombreux petits shards peut entraîner une latence accrue. Cela peut à son tour entraîner l’épuisement des thread pool et par conséquent, une diminution du débit.
Le paramètre index.number_of_shards peut être spécifié pour les nouveaux index créés avec l’API Create Index ou dans le cadre d’index template pour les index créés automatiquement par Index Lifecycle Management.
(avertissement) Pour les versions d’Elasticsearch < 7.0, la valeur par défaut de ce paramètre était 5. Pour les versions >= 7.0, la valeur par défaut de ce paramètre est 1 !!
Le body d’une requête de rollover peut également remplacer ce même paramètre index.number_of_shards.
Créez des shard plus grand en augmentant les seuils de rollover Si les index sont rollover soit directement à l’aide de l’API de rollover, soit en spécifiant l’action de rollover de l’Index Lifecycle Management, les seuils de condition de rollover (max_age, max_docs, max_size) peuvent être augmentés pour permettre aux index d’atteindre une taille plus grande avant d’être rollover, générant ainsi des shard plus grands.
Créez des shard plus grand en utilisant des index patterns couvrant des périodes plus longues La création d’index couvrant des périodes plus longues réduira également l’index, par conséquent le nombre de shard et augmentera la taille des index. Par exemple, au lieu d’indices quotidiens, créez des indices mensuels, voire annuels.
Si vous créez des index à l’aide de Logstash, la propriété index de la sortie Elasticsearch peut être modifiée en une expression mathématique de date couvrant une période plus longue. Par exemple, utilisez logstash-%{+YYYY.MM} au lieu de logstash-%{+YYYY.MM.dd} pour créer des index mensuels plutôt que quotidiens. Beats permet également de modifier l’expression mathématique de date définie dans la propriété index de la sortie Elasticsearch, comme pour Filebeat.
Cependant nous vous rappelons qu’il est conseillé d’utiliser l’Index Lifecycle Management.
Réduire (Shrink) un index existant en moins de shard L’API Shrink peut réduire un index existant en moins de shard.
Index Lifecycle Management dispose également d’une action de shrink disponible dans le cadre de sa phase Warm.
Réindexer un index existant sur moins de shard L’API de réindexation peut être utilisée pour réindexer un index existant vers un nouvel index avec moins de shard. Une fois les données réindexées, l’index initial surdimensionné peut être supprimé.
Réindexer les indices de périodes plus courtes sur des périodes plus longues L’API de réindexation peut être utilisée pour réindexer plusieurs petits index couvrant des périodes plus courtes dans un index plus grand couvrant une période plus longue. Par exemple, les index quotidiens de mai avec des patterns tels que foo-2023.05.11 pourraient être combinés en un index mensuel foo-2023.05 comme ceci :
POST _reindex
{
"source": {
"index": "foo-2023.05.*"
},
"dest": {
"index": "foo-2023.05"
}
}
Gérer les shard vides Faites particulièrement attention a tous les index qui sont vides. Ceux-ci peuvent être gérées par une politique d’Index Lifecycle Management ou un datastream qui rollover car le seuil max_age est atteint. Dans ce cas, vous devrez peut-être ajuster la stratégie pour utiliser les propriétés max_docs ou max_size à la place afin d’empêcher la création de ces index vides. Un exemple où cela peut se produire est si un ou plusieurs Beats arrêtent d’envoyer des données. Si les index gérés pour ces Beats sont configurés pour être rollover quotidiennement, de nouveaux index vides seront générés chaque jour. Les index vides peuvent être identifiés à l’aide du cat indices suivant :
GET _cat/indices?v&s=docs.count
Remarque : Certains des index ci-dessus peuvent être requis par le système et se trouvent être vides, si vous n’êtes pas sûr d’un index, veuillez nous contacter avant de les supprimer. En général, ne supprimez pas les index commençant par un .
Dans certains cas, ces index ont été créés par erreur sans faute de votre part, ce sont très souvent des index comme apm*, .ent*, etc. sans documents à l’intérieur, si ces index ont été créés par erreur, par défaut ou vous savez que vous n’en avez plus besoin vous pouvez simplement les supprimer avec la commande suivante :
DELETE <index>
Curator peut également aider à réindexer les index temporels.