Comment concevoir l’architecture du stockage de vos données Elasticsearch afin d’en garantir la scalabilité

Elasticsearch vous permet de stocker, de rechercher et d’analyser d’importants volumes de données structurées ou non. Grâce à sa vitesse, sa scalabilité et sa flexibilité, la Suite Elastic représente une solution puissante pour un vaste éventail de cas d'utilisation, notamment l’observabilité des systèmes, la sécurité (l’identification et la prévention des menaces) et la recherche pour l’entreprise. Compte tenu de cette flexibilité, il est essentiel de concevoir une architecture efficace pour le stockage des données de votre déploiement afin d’en assurer la scalabilité.

Par conséquent, il est logique de penser que chaque cas d'utilisation d’Elasticsearch est différent. Vos cas d'utilisation, déploiements ou situations commerciales présenteront certains seuils et tolérances pour divers éléments, comme le coût total de possession, les performances d’ingestion et de recherche, le nombre et la taille des sauvegardes ou encore le temps moyen de récupération.

Tandis que vous commencez à vous pencher sur ces différents facteurs, posez-vous aussi les 3 questions suivantes qui pourraient vous aider à prendre des décisions plus rapidement.

• Quelle quantité de perte de données votre cas d'utilisation/déploiement peut-il supporter ?
• Quel impact les performances ont-elles sur vos objectifs commerciaux ?
• Quelle indisponibilité votre projet peut-il gérer ?

Dans cet article, nous allons passer en revue plusieurs possibilités de stockage de données que vous pouvez utiliser. Nous vous présenterons les avantages et les inconvénients de chaque option. À la fin de votre lecture, vous saurez mieux comment établir l’architecture du stockage des données de votre propre (et unique) déploiement Elasticsearch en vue d’en assurer la scalabilité.

Peut-être préférez-vous déléguer toutes ces tâches ? Ne vous inquiétez pas : si vous adoptez Elasticsearch Service sur Elastic Cloud, nous nous chargeons de scaler l’architecture pour vous.

Présentation des options

Dans cet article, nous allons aborder les différentes possibilités d’architecture pour le stockage de vos données avec Elasticsearch. Nous vous en présenterons plus en détail les avantages et les inconvénients mais aussi ce que vous pouvez en attendre concernant la perte de données, les performances et l’indisponibilité.

Quand vous commencez à envisager de scaler la capacité de vos disques, vous avez le choix entre plusieurs bonnes options. Penchons-nous sur quelques-unes d’entre elles afin d’étudier leurs avantages et inconvénients. Chaque situation étant unique, il n’existe donc pas de solution universelle.

RAID 0

RAID est la pierre angulaire de l’association de plusieurs disques depuis des décennies. RAID est composé de trois fonctions, à savoir la mise en miroir, la répartition et la parité. Dans RAID, chaque numéro indique une combinaison unique de ces composantes.

Le numéro 0 représente la répartition dans RAID. Elle consiste à séparer les données en morceaux enregistrés sur tous les disques du volume.

Performances et capacité

La répartition améliore les performances de lecture et d’écriture étant donné que tous les disques peuvent fonctionner en parallèle. Ainsi, votre capacité d’écriture et de lecture est multipliée en fonction du nombre de disques dont vous disposez dans le tableau. Si votre tableau RAID 0 est composé de 6 disques, vous bénéficiez d’une vitesse de lecture et d’écriture environ 6 fois plus rapide.

Récupération

RAID 0 ne propose aucune récupération. Par conséquent, Elasticsearch doit prendre en charge cette opération à l’aide de snapshots ou de répliques. Cette étape peut être très chronophage, selon la taille des disques et le système de transport utilisé pour copier les données dans tout le tableau. Lors de la récupération, les performances du trafic réseau et d’autres nœuds peuvent être diminuées.

Avertissements

Les index Elasticsearch étant composés de plusieurs partitions, si l’une d’entre elles se trouve sur un volume RAID 0 connaissant une défaillance de disque, l’index correspondant peut également être corrompu si aucune autre réplique n’existe. Cela peut entraîner une perte de données permanente si vous ne disposez pas d’une solution de gestion du cycle de vie des snapshots pour gérer vos sauvegardes ou si vous n’avez pas configuré Elasticsearch afin de créer des répliques.

Avantages et inconvénients

RAID 1

Performances et capacité

Dans RAID, le numéro 1 représente la mise en miroir. Ce processus consiste à écrire les mêmes données sur un autre disque. En d’autres termes, une copie des données est réalisée. Même si les données sont enregistrées sur deux disques distincts, la plupart des mises en œuvre RAID ne les utilisent pas tous les deux en lecture. Ainsi, les performances de lecture et d’écriture sont partagées en deux de manière efficace. De plus, la copie des mêmes données sur deux disques entraîne la perte de la moitié de votre capacité.

Récupération

RAID 1 est conçu pour gérer seulement deux disques. Par conséquent, en cas de défaillance d’un disque, les données sont toujours conservées sur l’autre disque. La redondance des données est donc élevée au détriment des performances et de la capacité. En cas de défaillance d’un disque, il suffit de le remplacer. Les données sont ensuite copiées sur le nouveau disque.

Avertissements

Comme il ne prend en charge que 2 disques, RAID 1 est dans la plupart des cas associé à RAID 0. En d’autres termes, vous pouvez associer plusieurs volumes RAID 1 sur un RAID 0 fractionné. Le résultat, appelé RAID 10, vous permet de gérer quatre disques ou plus.

Ainsi, vous bénéficiez de certains des avantages de RAID 0 en matière de performances en plus de la redondance de RAID 1. Les performances de RAID 10 dépendent du nombre de disques dans le tableau. Les performances de RAID 10 sont Nx/2.

Avantages et inconvénients

RAID 5 et 6

Performances et capacité

Dans RAID, plusieurs numéros représentent la parité : 2, 3, 4, 5 et 6. Nous parlerons seulement de 5 et 6, car 2, 3 et 4 sont la plupart du temps remplacés par d’autres RAID. La parité permet aux ordinateurs de réparer ou calculer les données manquantes suite à la défaillance d’un disque. Elle ajoute la protection des données à la répartition. Or, la récupération des données ne s’effectue pas sans conséquence. Pour la parité, RAID 5 utilise la capacité d’un disque et RAID 6 celle de deux disques.

Récupération

Le temps de reconstruction et récupération doit également être pris en compte avec RAID 5 et 6. La reconstruction consiste à ajouter un disque dans le tableau afin d’en remplacer un défaillant. Quand vous disposez de supports rotatifs, au lieu d’augmenter la capacité de vos disques, ajoutez-en de nouveaux. Ainsi, vous augmenterez les temps de lecture et d’écriture mais aussi de reconstruction. Si vous avez des SSD, déterminez si des disques à capacité plus élevée fournissent des performances plus rapides en lecture et écriture. Nombre de SSD à capacité plus élevée le garantissent. Si c’est votre cas, de tels disques à capacité plus élevée sont la solution idéale pour améliorer les performances en lecture et écriture. Dans RAID 5, un disque peut connaître une défaillance avant que les données du tableau ne soient perdues. Dans RAID 6, deux disques peuvent connaître une défaillance.

Avertissements

RAID 5 et 6 peuvent supporter une défaillance de disque. Cependant, cela a des conséquences. Vos données dans RAID 5 sont aussi fragiles que sous RAID 0 tant que vous n’ajoutez pas de disque. Si un autre disque connaît une défaillance, toutes les données du tableau seront perdues et vous devrez récupérer celle d’autres partitions ou un snapshot. Étant donné que des lots de disques peuvent connaître des défaillances à peu près au même moment, il est souvent recommandé d’opter pour RAID 6. Comme nous l’expliquions au début de cet article, il est essentiel de bien comprendre la tolérance de votre projet à l’intégrité des données et aux performances afin de prendre la bonne décision.

Par ailleurs, la perte d’un disque altère considérablement la performance de RAID 5 et 6, car le tableau doit utiliser la parité pour recalculer les données en lecture sur les disques.

Avantages et inconvénients

Divers chemins d’accès aux données dans Elasticsearch

Elasticsearch comprend un paramètre appelé path.data, qui permet de configurer le ou les emplacements du système de fichiers contenant ses données. Quand une liste est indiquée pour path.data, Elasticsearch stocke les fichiers de données dans plusieurs emplacements. Par exemple, si votre elasticsearch.yml comprend les éléments suivants :

path.data: [ /mnt/path1, /mnt/path2, /mnt/path3 ]

Elasticsearch l’écrira dans plusieurs emplacements du système de fichiers. Chacun de ces chemins d’accès pourrait être un disque distinct.

En définissant plusieurs chemins d’accès aux données, les utilisateurs peuvent configurer Elasticsearch afin qu’il prenne en charge différents datastores.

Performances et capacité

Elasticsearch répartit les données sur plusieurs partitions qui sont écrites sur le chemin d’accès ayant le plus d’espace libre. Si une partition contient la plupart des données en écriture, vos performances sont limitées à la vitesse d’un seul chemin d’accès. En revanche, si vos données sont réparties de manière équitable sur plusieurs chemins d’accès, vous bénéficiez de la vitesse d’écriture de tous les disques utilisés. Elasticsearch ne garantit pas l’écriture des données sur plusieurs chemins d’accès. Par conséquent, les performances sont variables et incohérentes.

Utiliser divers chemins d’accès ne permet pas de bénéficier de la mise en miroir ni de la parité des données. Par conséquent, la capacité de tous les disques peut être utilisée pour héberger les données, sauf si un niveau est atteint, comme expliqué plus en détail dans le tableau des avantages et des inconvénients ci-dessous. Pour utiliser la pleine capacité des disques, vous devez disposer d’un nombre au moins identique de partitions et de chemins d’accès aux données.

Si vous ajoutez un nouveau chemin d’accès à un nœud contenant déjà des données sur d’autres chemins d’accès, cela peut entraîner un hot spot sur le nouveau disque. Elasticsearch n’équilibre pas les partitions entre les différents chemins d’accès. Par conséquent, toutes les nouvelles partitions sont envoyées vers le nouveau chemin d’accès ayant le plus d’espace libre. En outre, Elasticsearch lit uniquement les mises à jour d’elasticsearch.yml au démarrage. Vous devez donc redémarrer complètement le nœud pour ajouter un disque.

Récupération

Les disques connaissent une défaillance. Quand un périphérique de stockage configuré sur les divers chemins d’accès aux données s’interrompt, le nœud devient jaune et les données contenues sur ce périphérique ne sont plus accessibles. Or, Elasticsearch peut continuer à enregistrer en écriture des données sur le chemin d’accès défaillant qui lève des exceptions de type IOExceptions. Pour éviter cette situation, il est important de supprimer le chemin d’accès problématique de la configuration de nœud d’Elasticsearch. Pour ce faire, procédez comme suit :

1. Désactivez l’allocation des partitions.
2. Arrêtez le nœud.
3. Supprimez le chemin d’accès aux données défaillant de la configuration d’Elasticsearch.
4. Redémarrez le nœud.
5. Réactivez l’allocation des partitions.

Pour éviter toute perte de données permanente, vérifiez que la configuration d’Elasticsearch a activé la fonction de réplication. Par défaut, chaque partition contient une réplique.

Ainsi, Elasticsearch peut rééquilibrer les partitions d’autres nœuds. Elasticsearch n’équilibre pas les partitions entre les divers chemins d’accès aux données. Pour en savoir plus à ce sujet, lisez la section « Avertissements ». Si le cluster dispose de suffisamment de capacité pour le rééquilibrage, le nœud restera jaune.

Pour remplacer un nouveau disque, pensez à bien le démonter et à désactiver tout groupe LVM. Ainsi, les entrées et sorties peuvent gérer le nouveau disque de manière appropriée. Une fois le nouveau disque installé, vous devez ajouter le chemin d’accès dans le paramètre path.data d’Elasticsearch. Après avoir remplacé le disque défaillant, Elasticsearch commence à utiliser le nouveau chemin d’accès.

Avertissements

Quand un périphérique indiqué dans plusieurs chemins d’accès aux données s’interrompt, le chemin d’accès est ignoré lors de la prochaine allocation des partitions. Toutefois, les prochaines phases tiendront à nouveau compte du chemin d’accès éligible aux allocations des partitions. Cela peut entraîner des erreurs de type IOException sauf si les étapes expliquées ci-dessus sont respectées.

Elasticsearch gère les niveaux en fonction des nœuds. Il est important de garder cela à l’esprit. En effet, si un chemin d’accès atteint le niveau le plus élevé, le nœud tout entier passera à ce niveau, et ce, même si d’autres chemins d’accès aux données ont suffisamment d’espace libre. Par conséquent, le nœud ayant atteint le niveau n’acceptera plus de nouvelles partitions, déplacera les partitions hors du nœud ou passera le nœud en lecture seule.

Prenons comme exemple un nœud doté de 6 chemins d’accès de 500 Go chacun, soit une capacité totale d’environ 3 To. Un seul chemin d’accès aux données peut utiliser les disques à 90 %. Ainsi, tout le nœud atteint le niveau d’inondation et passe en lecture seule. Cette situation peut survenir même si d’autres disques du nœud sont utilisés à moins de 50 %.

Elasticsearch ne gère pas l’équilibrage des partitions dans un seul nœud : il n’équilibre pas les partitions entre les chemins d’accès aux données. Par conséquent, si un utilisateur a recours à divers chemins d’accès aux données, Elasticsearch placera les partitions sur le disque ayant le plus d’espace libre disponible au moment concerné. Si une partition contient plus de données que d’autres et utilise un disque entier, Elasticsearch n’équilibrera pas les partitions. Si vous ne savez pas que cette situation peut survenir, la charge des entrées et sorties peut se retrouver distribuée de manière inéquitable. En outre, l’ajoute un disque à un nœud contenant des données sur d’autres chemins d’accès peut engendrer une charge d’entrées et de sorties élevée sur le nouveau chemin d’accès.

Avantages et inconvénients

Conclusion

Comme il est existant de devoir gérer un volume de données croissant ! Dans cet article, nous vous avons présenté quelques options et outils pouvant vous aidant dans votre tâche. Toutefois, n’oubliez pas qu’il n’existe aucune solution universelle pour concevoir l’architecture du stockage de vos données qui en garantira la scalabilité.

Si vous avez des questions sur l’architecture du stockage de votre déploiement Elasticsearch pour en garantir la scalabilité, n’hésitez pas à consulter nos forums de discussion où je suis à votre disposition à l’instar de notre communauté d’utilisateurs en perpétuelle croissance.

Mieux encore, si vous ne vous sentez pas capable de gérer tout cela par vous-même, je me permets de vous répéter la bonne nouvelle annoncée en début d’article : Elastic Cloud gère tout cela pour vous. La gestion du volume croissant de vos données est aussi facile que l’ajout d’un nœud. Vous n’avez pas besoin de nouveaux serveurs à aménager en racks et à gérer. En outre, notre solution est compatible avec les hébergements que vous utilisez (probablement) déjà, comme Amazon Web Services, Google Cloud Platform et Microsoft Azure. Pourquoi ne pas la tester gratuitement dès aujourd’hui ?