{"id":75796,"date":"2020-03-28T19:42:18","date_gmt":"2020-03-28T17:42:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb"},"modified":"2020-03-28T19:42:18","modified_gmt":"2020-03-28T17:42:18","slug":"klaster-elasticsearch-na-200-tb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Cluster Elasticsearch de plus de 200 To","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>De nombreuses personnes se retrouvent face \u00e0 Elasticsearch. Mais que se passe-t-il lorsqu'on souhaite l'utiliser pour stocker des journaux 'en tr\u00e8s grande quantit\u00e9'? Et comment supporter sans douleur la d\u00e9faillance de l'un des plusieurs centres de donn\u00e9es? Quelle architecture doit-on adopter, et quels \u00e9cueils risque-t-on de rencontrer?<\/p>\n<p><\/p>\n<p>Nous, \u00e0 Odnoklassniki, avons d\u00e9cid\u00e9 d'utiliser Elasticsearch pour r\u00e9soudre le probl\u00e8me de gestion des journaux, et maintenant nous partageons notre exp\u00e9rience avec Habr : \u00e0 propos de l'architecture et des pi\u00e8ges rencontr\u00e9s.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Je suis Piotr Za\u00eftsev, administrateur syst\u00e8me chez Odnoklassniki. Avant cela, j'ai \u00e9galement \u00e9t\u00e9 administrateur, travaillant avec Manticore Search, Sphinx search et Elasticsearch. Peut-\u00eatre que si un autre type de &#8230;search appara\u00eet, je travaillerai aussi avec lui. Je participe \u00e9galement \u00e0 plusieurs projets open-source sur une base volontaire.<\/p>\n<p><\/p>\n<p>Lorsque je suis arriv\u00e9 chez Odnoklassniki, j'ai imprudemment d\u00e9clar\u00e9 en entretien que je savais travailler avec Elasticsearch. Apr\u00e8s m'\u00eatre familiaris\u00e9 et avoir r\u00e9alis\u00e9 quelques petites t\u00e2ches, on m'a confi\u00e9 une grande mission de r\u00e9forme du syst\u00e8me de gestion des journaux existant \u00e0 l'\u00e9poque. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Exigences<\/h2>\n<p><\/p>\n<p>Les exigences pour le syst\u00e8me ont \u00e9t\u00e9 formul\u00e9es comme suit :<\/p>\n<p><\/p>\n<ul>\n<li>Graylog devait \u00eatre utilis\u00e9 comme frontend. Parce que l'entreprise avait d\u00e9j\u00e0 de l'exp\u00e9rience avec ce produit, les d\u00e9veloppeurs et les testeurs le connaissaient, il leur \u00e9tait familier et confortable.<\/li>\n<li>Volume de donn\u00e9es : en moyenne 50 \u00e0 80 000 messages par seconde, mais si quelque chose se casse, le trafic n'est pas limit\u00e9, cela peut atteindre 2 \u00e0 3 millions de lignes par seconde.<\/li>\n<li>Apr\u00e8s avoir discut\u00e9 avec les clients des exigences concernant la vitesse de traitement des requ\u00eates, nous avons compris que le sch\u00e9ma typique d'utilisation d'un tel syst\u00e8me est le suivant : les gens recherchent les journaux de leur application des deux derniers jours et ne veulent pas attendre plus d'une seconde pour le r\u00e9sultat de leur requ\u00eate. <\/li>\n<li>Les admins ont insist\u00e9 pour que le syst\u00e8me puisse \u00eatre facilement \u00e9volutif si n\u00e9cessaire, sans n\u00e9cessiter d'eux une profonde compr\u00e9hension de son fonctionnement. <\/li>\n<li>Pour que la seule t\u00e2che de maintenance requise par ces syst\u00e8mes soit p\u00e9riodiquement de changer un mat\u00e9riel.<\/li>\n<li>De plus, chez Odnoklassniki, il y a une excellente tradition technique : tout service que nous lan\u00e7ons doit survivre \u00e0 la panne d'un centre de donn\u00e9es (brutale, impr\u00e9vue et \u00e0 tout moment).<\/li>\n<\/ul>\n<p><\/p>\n<p>La derni\u00e8re exigence dans la r\u00e9alisation de ce projet a \u00e9t\u00e9 particuli\u00e8rement difficile, dont je parlerai en d\u00e9tail par la suite.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Environnement<\/h2>\n<p><\/p>\n<p>Nous travaillons dans quatre centres de donn\u00e9es, tout en sachant que les n\u0153uds Elasticsearch ne peuvent \u00eatre situ\u00e9s que dans trois (pour diverses raisons non techniques).<\/p>\n<p><\/p>\n<p>Dans ces quatre centres de donn\u00e9es, il y a environ 18 000 sources de logs diff\u00e9rentes \u2014 mat\u00e9riel, conteneurs, machines virtuelles.<\/p>\n<p><\/p>\n<p>Caract\u00e9ristique importante : le cluster se lance dans des conteneurs <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> pas sur des machines physiques, mais sur <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">notre produit cloud one-cloud<\/a><\/noindex>. Les conteneurs disposent de 2 c\u0153urs, similaires \u00e0 2.0Ghz v4, avec la possibilit\u00e9 d'utiliser les autres c\u0153urs en cas d'inactivit\u00e9. <\/p>\n<p><\/p>\n<p>En d'autres termes :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topologie<\/h2>\n<p><\/p>\n<p>L'apparence g\u00e9n\u00e9rale de la solution m'est d'abord apparue comme suit :<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP sont derri\u00e8re l'enregistrement A du domaine Graylog, c'est l'adresse \u00e0 laquelle les logs sont envoy\u00e9s.<\/li>\n<li>Chaque VIP est un \u00e9quilibreur de charge LVS.<\/li>\n<li>Apr\u00e8s cela, les logs arrivent dans un cluster Graylog, une partie des donn\u00e9es est en format GELF, l'autre en format syslog.<\/li>\n<li>Ensuite, le tout est \u00e9crit par gros lots dans un groupe de coordinateurs Elasticsearch. <\/li>\n<li>Et eux, \u00e0 leur tour, envoient des requ\u00eates d'\u00e9criture et de lecture aux n\u0153uds de donn\u00e9es pertinents. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Terminologie<\/h2>\n<p><\/p>\n<p>Il est possible que tout le monde ne ma\u00eetrise pas la terminologie, c'est pourquoi je voudrais m'arr\u00eater un peu l\u00e0-dessus.<\/p>\n<p><\/p>\n<p>Dans Elasticsearch, il existe plusieurs types de n\u0153uds \u2014 master, coordinator, data node. Il y a aussi deux autres types pour diff\u00e9rents types de transformations de logs et la communication entre divers clusters, mais nous n'avons utilis\u00e9 que les types \u00e9num\u00e9r\u00e9s. <\/p>\n<p><\/p>\n<p><strong>Ma\u00eetre<\/strong><br \/>\nIl fait le ping de tous les n\u0153uds pr\u00e9sents dans le cluster, maintient une carte \u00e0 jour du cluster et la distribue entre les n\u0153uds, traite la logique \u00e9v\u00e9nementielle, et s'occupe de diverses t\u00e2ches de maintenance \u00e0 l'\u00e9chelle du cluster. <\/p>\n<p><\/p>\n<p><strong>Coordinateur<\/strong><br \/>\nEffectue une t\u00e2che unique : re\u00e7oit les requ\u00eates des clients pour la lecture ou l'\u00e9criture et redirige ce trafic. En cas de requ\u00eate d'\u00e9criture, il demandera probablement au master dans quel shard du bon index il faut l'ajouter et redirigera la requ\u00eate. <\/p>\n<p><\/p>\n<p><strong>N\u0153ud de donn\u00e9es<\/strong><br \/>\nStocke des donn\u00e9es, ex\u00e9cute les requ\u00eates de recherche et les op\u00e9rations sur les shards qui y sont stock\u00e9s.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nC'est une sorte de combinaison de Kibana et Logstash dans la pile ELK. Graylog allie UI et pipeline de traitement des journaux. Sous le capot, Graylog utilise Kafka et Zookeeper, qui assurent la connectivit\u00e9 de Graylog en tant que cluster. Graylog peut mettre en cache les journaux (Kafka) en cas d'indisponibilit\u00e9 d'Elasticsearch et r\u00e9p\u00e9ter les requ\u00eates de lecture et d'\u00e9criture \u00e9chou\u00e9es, en regroupant et en etiquetant les journaux selon des r\u00e8gles d\u00e9finies. Tout comme Logstash, Graylog dispose de fonctionnalit\u00e9s pour modifier les cha\u00eenes avant de les enregistrer dans Elasticsearch.<\/p>\n<p><\/p>\n<p>De plus, Graylog poss\u00e8de une d\u00e9couverte de services int\u00e9gr\u00e9e, permettant \u00e0 partir d'un n\u0153ud Elasticsearch accessible d'obtenir toute la carte du cluster et de la filtrer par un tag sp\u00e9cifique, ce qui permet d'orienter les requ\u00eates vers des conteneurs pr\u00e9cis.<\/p>\n<p><\/p>\n<p>Visuellement, cela ressemble \u00e0 ceci :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ceci est une capture d'\u00e9cran d'une instance sp\u00e9cifique. Ici, nous construisons un histogramme \u00e0 partir d'une requ\u00eate de recherche, affichant des lignes pertinentes.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indices<\/h2>\n<p><\/p>\n<p>Revenant \u00e0 l'architecture du syst\u00e8me, j'aimerais m'attarder sur la mani\u00e8re dont nous avons construit le mod\u00e8le d'index afin que tout fonctionne correctement. <\/p>\n<p><\/p>\n<p>Dans le sch\u00e9ma pr\u00e9sent\u00e9 pr\u00e9c\u00e9demment, c'est le niveau le plus inf\u00e9rieur : les n\u0153uds de donn\u00e9es Elasticsearch.<\/p>\n<p><\/p>\n<p>Un index est une grande entit\u00e9 virtuelle, compos\u00e9e de shards Elasticsearch. Chacun de ces shards n'est rien d'autre qu'un index Lucene. Et chaque index Lucene est compos\u00e9 d'un ou plusieurs segments. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Lors de la conception, nous avons estim\u00e9 que pour garantir la vitesse de lecture sur un grand volume de donn\u00e9es, nous devions uniform\u00e9ment \"\u00e9taler\" ces donn\u00e9es sur les n\u0153uds de donn\u00e9es. <\/p>\n<p><\/p>\n<p>Cela a conduit \u00e0 ce que le nombre de shards par index (avec r\u00e9pliques) doive \u00eatre strictement \u00e9gal au nombre de n\u0153uds de donn\u00e9es. Tout d'abord, pour garantir un facteur de r\u00e9plication de deux (c'est-\u00e0-dire que nous pouvons perdre la moiti\u00e9 du cluster). Ensuite, pour que les requ\u00eates de lecture et d'\u00e9criture soient trait\u00e9es sur au moins la moiti\u00e9 du cluster.<\/p>\n<p><\/p>\n<p>Nous avons d'abord d\u00e9fini le temps de conservation \u00e0 30 jours.<\/p>\n<p><\/p>\n<p>La distribution des shards peut \u00eatre repr\u00e9sent\u00e9e graphiquement comme suit :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Tout le rectangle gris fonc\u00e9 repr\u00e9sente l'index. Le carr\u00e9 rouge \u00e0 gauche en fait partie \u2014 c'est le shard primaire, le premier de l'index. Et le carr\u00e9 bleu \u2014 c'est le shard r\u00e9plique. Ils se trouvent dans diff\u00e9rents centres de donn\u00e9es.<\/p>\n<p><\/p>\n<p>Lorsque nous ajoutons un nouveau shard, il va dans le troisi\u00e8me data center. Et, finalement, nous obtenons une structure qui permet de perdre un DC sans perdre la coh\u00e9rence des donn\u00e9es :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nous avons d\u00e9fini la rotation des index, c'est-\u00e0-dire la cr\u00e9ation d'un nouvel index et la suppression de l'index le plus ancien, \u00e0 48 heures (selon le mod\u00e8le d'utilisation de l'index : il est le plus souvent recherch\u00e9 dans les derni\u00e8res 48 heures).<\/p>\n<p><\/p>\n<p>Ce type d'intervalle de rotation des index est li\u00e9 aux raisons suivantes :<\/p>\n<p><\/p>\n<p>Lorsque la node de donn\u00e9es re\u00e7oit une requ\u00eate de recherche, il est plus performant de consulter un seul shard, \u00e0 condition que sa taille soit comparable \u00e0 celle de la m\u00e9moire vive de la node. Cela permet de garder la partie \"chaude\" de l'index en m\u00e9moire et d'y acc\u00e9der rapidement. Lorsque le nombre de parties \"chaudes\" augmente, la vitesse de recherche dans l'index se d\u00e9grade.<\/p>\n<p><\/p>\n<p>Lorsque la node commence \u00e0 ex\u00e9cuter une requ\u00eate de recherche sur un shard, elle alloue un nombre de threads \u00e9gal au nombre de c\u0153urs hyper-threading de la machine physique. Si la requ\u00eate de recherche touche un grand nombre de shards, le nombre de threads augmente proportionnellement. Cela a un impact n\u00e9gatif sur la vitesse de recherche et affecte la nouvelle indexation des donn\u00e9es. <\/p>\n<p><\/p>\n<p>Pour garantir la latence n\u00e9cessaire \u00e0 la recherche, nous avons d\u00e9cid\u00e9 d'utiliser des SSD. Pour un traitement rapide des requ\u00eates, les machines h\u00e9bergeant ces conteneurs devaient avoir au moins 56 c\u0153urs. Ce chiffre de 56 a \u00e9t\u00e9 choisi comme une valeur conditionnellement suffisante, d\u00e9terminant le nombre de threads qu'Elasticsearch g\u00e9n\u00e9rera pendant son fonctionnement. Dans Elasticsearch, de nombreux param\u00e8tres du pool de threads d\u00e9pendent directement du nombre de c\u0153urs disponibles, ce qui influence directement le nombre de n\u0153uds n\u00e9cessaires dans le cluster selon le principe \"moins de c\u0153urs \u2014 plus de n\u0153uds\". <\/p>\n<p><\/p>\n<p>En fin de compte, nous avons obtenu qu'en moyenne, un shard p\u00e8se environ 20 gigaoctets, et qu'il y a 360 shards par index. Par cons\u00e9quent, si nous les faisons pivoter toutes les 48 heures, nous en avons 15. Chaque index contient des donn\u00e9es sur 2 jours.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Sch\u00e9mas d'\u00e9criture et de lecture des donn\u00e9es<\/h2>\n<p><\/p>\n<p>Examinons comment les donn\u00e9es sont \u00e9crites dans ce syst\u00e8me.<\/p>\n<p><\/p>\n<p>Supposons qu'une requ\u00eate nous parvienne de Graylog dans le coordinateur. Par exemple, nous souhaitons indexer 2 \u00e0 3 mille lignes. <\/p>\n<p><\/p>\n<p>Le coordinateur, ayant re\u00e7u une demande de Graylog, interroge le master : \u00ab Dans la demande d'indexation, nous avions sp\u00e9cifiquement indiqu\u00e9 l'index, mais il n'est pas pr\u00e9cis\u00e9 dans quel shard cela doit \u00eatre \u00e9crit \u00bb. <\/p>\n<p><\/p>\n<p>Le master r\u00e9pond : \u00ab Note cette information dans le shard num\u00e9ro 71 \u00bb, apr\u00e8s quoi elle est directement envoy\u00e9e au n\u0153ud de donn\u00e9es pertinent, o\u00f9 se trouve le primary-shard num\u00e9ro 71.<\/p>\n<p><\/p>\n<p>Ensuite, le journal des transactions est r\u00e9pliqu\u00e9 sur le replica-shard, qui se trouve dans un autre data center.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>De Graylog, une requ\u00eate de recherche arrive au coordinateur. Le coordinateur la redirige par index, tandis qu'Elasticsearch distribue les requ\u00eates entre le primary-shard et le replica-shard selon un principe de round-robin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Les n\u0153uds, au nombre de 180, r\u00e9pondent de mani\u00e8re in\u00e9gale et, pendant qu'ils r\u00e9pondent, le coordinateur accumule les informations qui ont d\u00e9j\u00e0 \u00e9t\u00e9 \u00ab crach\u00e9es \u00bb par les n\u0153uds de donn\u00e9es plus rapides. Ensuite, soit lorsque toutes les informations sont arriv\u00e9es, soit lorsque le d\u00e9lai d'attente de la requ\u00eate est atteint, il les renvoie directement au client. <\/p>\n<p><\/p>\n<p>Dans l'ensemble, ce syst\u00e8me traite en moyenne les requ\u00eates de recherche sur les derni\u00e8res 48 heures en 300-400 ms, \u00e0 l'exception des requ\u00eates avec un leading wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">Les \u00ab fleurs \u00bb d'Elasticsearch : configuration de Java<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Pour que tout cela fonctionne comme nous le souhaitions initialement, nous avons longuement ajust\u00e9 divers \u00e9l\u00e9ments dans le cluster. <\/p>\n<p><\/p>\n<p>La premi\u00e8re partie des probl\u00e8mes d\u00e9couverts \u00e9tait li\u00e9e \u00e0 la fa\u00e7on dont Java est pr\u00e9-configur\u00e9e par d\u00e9faut dans Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>Premier probl\u00e8me<\/strong><br \/>\nNous avons observ\u00e9 un nombre tr\u00e8s \u00e9lev\u00e9 de messages indiquant qu'au niveau de Lucene, lorsque des t\u00e2ches d'arri\u00e8re-plan sont lanc\u00e9es, les fusions de segments Lucene \u00e9chouent avec une erreur. Les journaux indicaient que cela correspondait \u00e0 une erreur OutOfMemoryError. Selon la t\u00e9l\u00e9m\u00e9trie, nous avons vu que le tas \u00e9tait libre, et il n'\u00e9tait pas clair pourquoi cette op\u00e9ration \u00e9chouait. <\/p>\n<p><\/p>\n<p>Il s'est av\u00e9r\u00e9 que les fusions des index Lucene se produisent hors du heap. Les conteneurs sont assez strictement limit\u00e9s en ressources consomm\u00e9es. Ces ressources \u00e9taient accessibles uniquement au heap (la valeur heap.size \u00e9tait \u00e0 peu pr\u00e8s \u00e9gale \u00e0 la RAM), et certaines op\u00e9rations hors heap \u00e9chouaient avec une erreur d'allocation de m\u00e9moire si, pour une raison quelconque, elles ne rentraient pas dans les ~500 Mo qui restaient avant le seuil.<\/p>\n<p><\/p>\n<p>Le correctif \u00e9tait relativement trivial : nous avons augment\u00e9 la quantit\u00e9 de RAM disponible pour le conteneur, apr\u00e8s quoi nous avons oubli\u00e9 que de tels probl\u00e8mes existent.<\/p>\n<p><\/p>\n<p><strong>Deuxi\u00e8me probl\u00e8me<\/strong><br \/>\nEnviron 4-5 jours apr\u00e8s le lancement du cluster, nous avons remarqu\u00e9 que les n\u0153uds de donn\u00e9es commen\u00e7aient \u00e0 se d\u00e9connecter p\u00e9riodiquement du cluster et \u00e0 y revenir 10-20 secondes plus tard. <\/p>\n<p><\/p>\n<p>Lorsque nous avons commenc\u00e9 \u00e0 enqu\u00eater, il est devenu clair que cette m\u00e9moire off-heap dans Elasticsearch n'est pratiquement pas contr\u00f4l\u00e9e. Lorsque nous avons allou\u00e9 plus de m\u00e9moire au conteneur, nous avons pu remplir les pools de buffer direct avec diverses informations, et elles \u00e9taient nettoy\u00e9es seulement apr\u00e8s qu'un GC explicite ait \u00e9t\u00e9 d\u00e9clench\u00e9 par Elasticsearch. <\/p>\n<p><\/p>\n<p>Dans certains cas, cette op\u00e9ration prenait assez longtemps, et pendant ce temps, le cluster avait le temps de marquer ce n\u0153ud comme hors service. Ce probl\u00e8me est bien document\u00e9. <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">voici ici<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>La solution a \u00e9t\u00e9 la suivante : nous avons restreint la capacit\u00e9 de Java \u00e0 utiliser la majeure partie de la m\u00e9moire hors heap pour ces op\u00e9rations. Nous l'avons limit\u00e9e \u00e0 16 gigaoctets (-XX:MaxDirectMemorySize=16g), ce qui a conduit \u00e0 un appel du GC explicite beaucoup plus fr\u00e9quent et plus rapide, stabilisant ainsi le cluster.<\/p>\n<p><\/p>\n<p><strong>Troisi\u00e8me probl\u00e8me<\/strong><br \/>\nSi vous pensez que les probl\u00e8mes de \u00ab n\u0153uds quittant le cluster au moment le plus inattendu \u00bb se sont arr\u00eat\u00e9s ici, vous vous trompez. <\/p>\n<p><\/p>\n<p>Lorsque nous avons configur\u00e9 le travail avec les indices, nous avons opt\u00e9 pour mmapfs afin de <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">r\u00e9duire le temps de recherche<\/a><\/noindex> pour les nouveaux shards avec une grande segmentation. C'\u00e9tait une erreur assez grossi\u00e8re, car lors de l'utilisation de mmapfs, le fichier est mapp\u00e9 dans la m\u00e9moire vive, et ensuite nous travaillons d\u00e9j\u00e0 avec le fichier mapp\u00e9. Cela signifie que lorsque le GC essaie d'arr\u00eater les threads dans l'application, nous atteignons tr\u00e8s lentement le safepoint, et en chemin, l'application ne r\u00e9pond plus aux requ\u00eates du ma\u00eetre sur son \u00e9tat. Par cons\u00e9quent, le ma\u00eetre pense que le n\u0153ud n'est plus pr\u00e9sent dans le cluster. Ensuite, apr\u00e8s environ 5 \u00e0 10 secondes, le garbage collector effectue son travail, le n\u0153ud rena\u00eet, rejoint \u00e0 nouveau le cluster et commence l'initialisation des shards. Tout cela ressemblait beaucoup \u00e0 un \u201cproduit que nous m\u00e9ritions\u201d et n'\u00e9tait pas adapt\u00e9 \u00e0 quoi que ce soit de s\u00e9rieux.<\/p>\n<p><\/p>\n<p>Pour rem\u00e9dier \u00e0 ce comportement, nous avons d'abord migr\u00e9 vers le standard niofs, puis, lorsque nous sommes pass\u00e9s des versions 5 d'Elastic aux versions 6, nous avons essay\u00e9 hybridfs, o\u00f9 ce probl\u00e8me ne se reproduisait pas. Pour en savoir plus sur les types de stockage, vous pouvez lire. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">ici<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Quatri\u00e8me probl\u00e8me<\/strong><br \/>\nEnsuite, il y a eu un probl\u00e8me tr\u00e8s int\u00e9ressant que nous avons trait\u00e9 pendant un temps record. Nous l'avons suivi pendant 2 \u00e0 3 mois, car son sch\u00e9ma \u00e9tait absolument incompr\u00e9hensible. <\/p>\n<p><\/p>\n<p>Parfois, nos coordinateurs entraient en Full GC, g\u00e9n\u00e9ralement apr\u00e8s le d\u00e9jeuner, et ne revenaient jamais. Lors de la journalisation des retards de GC, cela apparaissait comme suit : tout se passait bien, bien, bien, puis soudain, tout devenait soudainement mauvais. <\/p>\n<p><\/p>\n<p>Au d\u00e9but, nous pensions qu'il y avait un utilisateur malveillant qui lan\u00e7ait une requ\u00eate d\u00e9rangeant le fonctionnement du coordinateur. Nous avons pass\u00e9 beaucoup de temps \u00e0 enregistrer les requ\u00eates pour essayer de comprendre ce qui se passait. <\/p>\n<p><\/p>\n<p>Finalement, il s'est av\u00e9r\u00e9 que lorsque certains utilisateurs lan\u00e7aient de tr\u00e8s grosses requ\u00eates et qu'elles atterrissaient sur un coordinateur Elasticsearch sp\u00e9cifique, certains n\u0153uds r\u00e9pondaient plus lentement que d'autres. <\/p>\n<p><\/p>\n<p>Et pendant le temps que le coordinateur attendait les r\u00e9ponses de tous les n\u0153uds, il accumulait les r\u00e9sultats envoy\u00e9s par les n\u0153uds d\u00e9j\u00e0 r\u00e9pondus. Pour le GC, cela signifie que notre mod\u00e8le d'utilisation de la m\u00e9moire vive changeait rapidement. Et le GC que nous utilisions ne parvenait pas \u00e0 g\u00e9rer cette t\u00e2che. <\/p>\n<p><\/p>\n<p>Le seul correctif que nous avons trouv\u00e9 pour changer le comportement du cluster dans une telle situation est la migration vers JDK13 et l'utilisation du ramasse-miettes Shenandoah. Cela a r\u00e9solu le probl\u00e8me, les coordinateurs ne s'effondraient plus. <\/p>\n<p><\/p>\n<p>\u00c0 ce stade, les probl\u00e8mes li\u00e9s \u00e0 Java \u00e9taient r\u00e9solus et nous avons commenc\u00e9 \u00e0 rencontrer des probl\u00e8mes de bande passante. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u00ab Les cerises \u00bb avec Elasticsearch : bande passante<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Les probl\u00e8mes de bande passante signifient que notre cluster fonctionne de mani\u00e8re stable, mais lors des pics de documents index\u00e9s et pendant les man\u0153uvres, les performances sont insuffisantes.<\/p>\n<p><\/p>\n<p>Le premier sympt\u00f4me rencontr\u00e9 : lors de certains \u00ab pics \u00bb en production, o\u00f9 un tr\u00e8s grand nombre de journaux est soudainement g\u00e9n\u00e9r\u00e9, l'erreur d'indexation es_rejected_execution appara\u00eet fr\u00e9quemment dans Graylog. <\/p>\n<p><\/p>\n<p>Cela se produisait parce que thread_pool.write.queue sur un n\u0153ud de donn\u00e9es, avant qu'Elasticsearch puisse traiter la requ\u00eate d'indexation et envoyer les informations dans le shard sur disque, ne peut par d\u00e9faut mettre en cache que 200 requ\u00eates. Et dans <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">la documentation d'Elasticsearch<\/a><\/noindex> il est tr\u00e8s peu question de ce param\u00e8tre. Seule la limite du nombre de threads et la taille par d\u00e9faut sont mentionn\u00e9es.<\/p>\n<p><\/p>\n<p>Naturellement, nous avons commenc\u00e9 \u00e0 ajuster cette valeur et avons d\u00e9couvert que, sp\u00e9cifiquement dans notre configuration, il est possible de mettre en cache jusqu'\u00e0 300 requ\u00eates, mais que des valeurs plus \u00e9lev\u00e9es sont risqu\u00e9es car nous retombons \u00e0 nouveau dans le Full GC.<\/p>\n<p><\/p>\n<p>De plus, comme il s'agit de lots de messages arrivant dans une seule demande, nous devions \u00e9galement ajuster Graylog pour qu'il n'\u00e9crive pas souvent et par petits groupes, mais par de grands groupes ou une fois toutes les 3 secondes, si le groupe n'est toujours pas plein. Dans ce cas, les informations que nous \u00e9crivons dans Elasticsearch deviennent accessibles non pas apr\u00e8s deux secondes, mais apr\u00e8s cinq (ce qui nous convient parfaitement), mais le nombre de retries n\u00e9cessaires pour pousser un grand lot d'informations est r\u00e9duit.<\/p>\n<p><\/p>\n<p>C'est particuli\u00e8rement important \u00e0 ces moments o\u00f9 nous rencontrons un probl\u00e8me quelconque et que cela le signale de mani\u00e8re fr\u00e9n\u00e9tique, afin de ne pas obtenir un Elastic compl\u00e8tement spamm\u00e9, et apr\u00e8s un certain temps \u2014 des n\u0153uds Graylog non fonctionnels en raison de tampons satur\u00e9s.<\/p>\n<p><\/p>\n<p>De plus, lorsque ces explosions se produisaient en production, nous recevions des plaintes de la part des programmeurs et des testeurs : au moment o\u00f9 ils avaient vraiment besoin de ces logs, ceux-ci leur \u00e9taient fournis tr\u00e8s lentement.<\/p>\n<p><\/p>\n<p>Nous avons commenc\u00e9 \u00e0 examiner la situation. D'une part, il \u00e9tait clair que les requ\u00eates de recherche et les requ\u00eates d'indexation \u00e9taient trait\u00e9es essentiellement sur les m\u00eames machines physiques, et d'une mani\u00e8re ou d'une autre, des baisses de performance se produiraient. <\/p>\n<p><\/p>\n<p>Mais cela pouvait \u00eatre partiellement contourn\u00e9 gr\u00e2ce \u00e0 l'algorithme introduit dans les versions six d'Elasticsearch, qui permet de r\u00e9partir les requ\u00eates entre les n\u0153uds de donn\u00e9es pertinents, non pas selon un principe al\u00e9atoire de round-robin (le conteneur qui s'occupe de l'indexation et maintient le primary-shard peut \u00eatre tr\u00e8s occup\u00e9, n'ayant pas la possibilit\u00e9 de r\u00e9pondre rapidement), mais de diriger cette requ\u00eate vers un conteneur moins charg\u00e9 avec un replica-shard, qui r\u00e9pondra beaucoup plus rapidement. En d'autres termes, nous sommes pass\u00e9s \u00e0 use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>L'image de lecture commence \u00e0 ressembler \u00e0 ceci :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Le passage \u00e0 cet algorithme a permis d'am\u00e9liorer consid\u00e9rablement le temps de requ\u00eate lorsque nous avions un grand flux de logs \u00e0 \u00e9crire.<\/p>\n<p><\/p>\n<p>Enfin, le principal probl\u00e8me \u00e9tait de sortir le data center sans douleur.<\/p>\n<p><\/p>\n<p>Ce que nous voulions du cluster imm\u00e9diatement apr\u00e8s la perte de connexion avec un DC : <\/p>\n<p><\/p>\n<ul>\n<li>Si le master actuel se trouve dans le data center d\u00e9connect\u00e9, il sera r\u00e9\u00e9lu et d\u00e9plac\u00e9 comme r\u00f4le vers un autre n\u0153ud dans un autre DC.<\/li>\n<li>Le master \u00e9liminera rapidement tous les n\u0153uds inaccessibles du cluster.<\/li>\n<li>Sur la base des shards restants, il comprendra que dans le centre de donn\u00e9es perdu, nous avions tels primary shards, et rapidement il promouvra des replica shards compl\u00e9mentaires dans les centres de donn\u00e9es restants, et nous continuerons l'indexation des donn\u00e9es. <\/li>\n<li>En cons\u00e9quence, la bande passante du cluster pour les \u00e9critures et les lectures va progressivement diminuer, mais dans l'ensemble, tout fonctionnera, m\u00eame si lentement, de mani\u00e8re stable.<\/li>\n<\/ul>\n<p><\/p>\n<p>Comme il s'est av\u00e9r\u00e9, nous voulions quelque chose comme \u00e7a :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Et nous avons re\u00e7u ce qui suit :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Comment cela a-t-il pu se produire ? <\/p>\n<p><\/p>\n<p>Au moment de la chute du centre de donn\u00e9es, le ma\u00eetre est devenu le goulot d'\u00e9tranglement.<\/p>\n<p><\/p>\n<p>Pourquoi ?<\/p>\n<p><\/p>\n<p>En fait, dans le ma\u00eetre, il existe un TaskBatcher, responsable de la diffusion de certaines t\u00e2ches et \u00e9v\u00e9nements dans le cluster. Toute sortie d'un n\u0153ud, toute promotion d'un shard de replica \u00e0 primary, toute t\u00e2che de cr\u00e9ation d'un shard quelque part \u2014 tout cela passe d'abord par le TaskBatcher, o\u00f9 il est trait\u00e9 de mani\u00e8re s\u00e9quentielle et en un seul flux.<\/p>\n<p><\/p>\n<p>Au moment de la sortie d'un centre de donn\u00e9es, il semblait que tous les n\u0153uds de donn\u00e9es dans les centres de donn\u00e9es survivants avaient pour devoir de signaler au ma\u00eetre \u00ab nous avons perdu tels shards et tels n\u0153uds de donn\u00e9es \u00bb. <\/p>\n<p><\/p>\n<p>Dans le m\u00eame temps, les n\u0153uds de donn\u00e9es survivants envoyaient toutes ces informations au ma\u00eetre actuel et essayaient d'attendre une confirmation qu'il l'avait re\u00e7ue. Ils ne l'attendaient pas, car le ma\u00eetre recevait les t\u00e2ches plus vite qu'il ne pouvait r\u00e9pondre. Les n\u0153uds r\u00e9p\u00e9taient leurs requ\u00eates apr\u00e8s un d\u00e9lai, et pendant ce temps, le ma\u00eetre ne tentait m\u00eame pas de r\u00e9pondre, \u00e9tant compl\u00e8tement absorb\u00e9 par la t\u00e2che de tri des requ\u00eates par priorit\u00e9.<\/p>\n<p><\/p>\n<p>De mani\u00e8re terminale, il apparaissait que les n\u0153uds de donn\u00e9es spammaient le ma\u00eetre jusqu'\u00e0 ce qu'il soit en full GC. Apr\u00e8s cela, notre r\u00f4le de ma\u00eetre se d\u00e9pla\u00e7ait vers un autre n\u0153ud, avec lequel se passait exactement la m\u00eame chose, et finalement le cluster s'effondrait compl\u00e8tement. <\/p>\n<p><\/p>\n<p>Nous avons effectu\u00e9 des mesures, et jusqu'\u00e0 la version 6.4.0, o\u00f9 cela a \u00e9t\u00e9 corrig\u00e9, il suffisait de sortir simultan\u00e9ment seulement 10 n\u0153uds de donn\u00e9es sur 360 pour provoquer un effondrement complet du cluster.<\/p>\n<p><\/p>\n<p>Cela ressemblait \u00e0 peu pr\u00e8s \u00e0 ceci :<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Apr\u00e8s la version 6.4.0, o\u00f9 ce bug probl\u00e9matique a \u00e9t\u00e9 corrig\u00e9, les n\u0153uds de donn\u00e9es ont cess\u00e9 d'\u00e9craser le ma\u00eetre. Mais il n'est pas devenu \u00ab plus intelligent \u00bb pour autant. En effet : lorsque nous sortons 2, 3 ou 10 (quelque nombre autre que un) n\u0153uds de donn\u00e9es, le ma\u00eetre re\u00e7oit un certain premier message informant que le n\u0153ud A est sorti, et essaie d'en informer le n\u0153ud B, le n\u0153ud C, le n\u0153ud D. <\/p>\n<p><\/p>\n<p>\u00c0 l'heure actuelle, il n'est possible de lutter contre cela qu'en installant un d\u00e9lai d'attente pour les tentatives de raconter quelque chose \u00e0 quelqu'un, d'environ 20 \u00e0 30 secondes, et ainsi g\u00e9rer la vitesse de sortie du centre de donn\u00e9es du cluster.<\/p>\n<p><\/p>\n<p>En principe, cela correspond aux exigences initialement pos\u00e9es pour le produit final dans le cadre du projet, mais du point de vue de la \u00ab science pure \u00bb, c'est un bug. Qui, d'ailleurs, a \u00e9t\u00e9 corrig\u00e9 avec succ\u00e8s par les d\u00e9veloppeurs dans la version 7.2.<\/p>\n<p><\/p>\n<p>En fait, lorsque certaines data-nodes sortaient, il s'est av\u00e9r\u00e9 qu'il \u00e9tait plus important de diffuser l'information sur leur sortie que de pr\u00e9venir tout le cluster que sur celles-ci se trouvaient certaines primary-shard (pour promouvoir replica-shard dans un autre centre de donn\u00e9es en primary, pour pouvoir y \u00e9crire des informations).<\/p>\n<p><\/p>\n<p>Ainsi, une fois que tout \u00e9tait \u00ab fini \u00bb, les data-nodes sortants ne sont pas imm\u00e9diatement marqu\u00e9es comme obsol\u00e8tes. Par cons\u00e9quent, nous devons attendre que tous les pings vers les data-nodes sortants expirent et seulement apr\u00e8s cela notre cluster commence \u00e0 informer que l\u00e0-bas, ici et l\u00e0, il faut continuer \u00e0 enregistrer des informations. Vous pouvez lire plus en d\u00e9tail \u00e0 ce sujet. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">ici<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Au final, l'op\u00e9ration de sortie du centre de donn\u00e9es prend aujourd'hui environ 5 minutes aux heures de pointe. Pour une machine aussi grande et peu maniable, c'est un r\u00e9sultat assez bon.<\/p>\n<p><\/p>\n<p>Nous en sommes arriv\u00e9s \u00e0 la conclusion suivante :<\/p>\n<p><\/p>\n<ul>\n<li>Nous avons 360 data-nodes avec des disques de 700 gigaoctets.<\/li>\n<li>60 coordinateurs pour router le trafic entre ces data-nodes.<\/li>\n<li>40 ma\u00eetres, qui nous sont rest\u00e9s comme un h\u00e9ritage des versions pr\u00e9c\u00e9dentes \u00e0 partir de 6.4.0 \u2014 pour survivre \u00e0 la sortie du centre de donn\u00e9es, nous \u00e9tions moralement pr\u00eats \u00e0 perdre quelques machines, afin d'assurer m\u00eame dans le pire sc\u00e9nario avoir un quorum de ma\u00eetres.<\/li>\n<li>Toute tentative de combiner des r\u00f4les sur un m\u00eame conteneur se heurtait au fait qu'\u00e0 un moment donn\u00e9, la node tombait sous la charge. <\/li>\n<li>Dans tout le cluster, la taille de la heap est de 31 gigaoctets : toutes les tentatives de r\u00e9duire cette taille ont conduit \u00e0 ce que des requ\u00eates de recherche lourdes avec des wildcards en t\u00eate tuaient certaines nodes ou d\u00e9clenchaient un circuit breaker dans Elasticsearch.<\/li>\n<li>De plus, pour garantir la performance de recherche, nous essayions de maintenir le nombre d'objets dans le cluster aussi bas que possible, afin de traiter le moins d'\u00e9v\u00e9nements possible au point le plus \u00e9troit que nous avons obtenu dans le ma\u00eetre.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Enfin, concernant la surveillance<\/h2>\n<p><\/p>\n<p>Pour que tout cela fonctionne comme pr\u00e9vu, nous surveillons ce qui suit :<\/p>\n<p><\/p>\n<ul>\n<li>Chaque n\u0153ud de donn\u00e9es informe notre cloud de son existence et des shards qu'il g\u00e8re. Lorsque nous arr\u00eatons quelque chose quelque part, le cluster rend compte dans les 2-3 secondes qu'au centre A, nous avons \u00e9teint les n\u0153uds 2, 3 et 4 \u2014 cela signifie qu'aucun des autres centres de donn\u00e9es ne peut \u00e9teindre les n\u0153uds qui contiennent des shards en unique exemplaire.<\/li>\n<li>En connaissant le comportement du ma\u00eetre, nous surveillons de tr\u00e8s pr\u00e8s le nombre de t\u00e2ches en attente. Parce qu'une seule t\u00e2che suspendue, si elle n'expire pas \u00e0 temps, pourrait th\u00e9oriquement, dans une situation d'urgence, \u00eatre la raison pour laquelle, par exemple, la promotion d'un shard replica vers un primary ne fonctionne pas, ce qui stopperait l'indexation.<\/li>\n<li>Nous surveillons \u00e9galement de pr\u00e8s les d\u00e9lais du garbage collector, car nous avons d\u00e9j\u00e0 rencontr\u00e9 de grandes difficult\u00e9s avec cela lors de l'optimisation.<\/li>\n<li>Les rejets par threads, pour comprendre \u00e0 l'avance o\u00f9 se trouve le \"goulot d'\u00e9tranglement\".<\/li>\n<li>Et les m\u00e9triques standard, comme le heap, la RAM et l'I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Lors de la mise en place de la surveillance, il est essentiel de prendre en compte les sp\u00e9cificit\u00e9s du Thread Pool dans Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">La documentation d'Elasticsearch<\/a><\/noindex> d\u00e9crit les possibilit\u00e9s de configuration et les valeurs par d\u00e9faut pour la recherche, l'indexation, mais ne mentionne pas du tout thread_pool.management. Ces threads g\u00e8rent, entre autres, des requ\u00eates comme _cat\/shards et d'autres similaires, qui sont pratiques pour \u00e9crire des outils de surveillance. Plus le cluster est grand, plus ces requ\u00eates sont ex\u00e9cut\u00e9es en une seule fois, et le thread_pool.management mentionn\u00e9 ci-dessus, en plus de ne pas figurer dans la documentation officielle, est de plus limit\u00e9 par d\u00e9faut \u00e0 5 threads, ce qui est tr\u00e8s rapidement consomm\u00e9, apr\u00e8s quoi la surveillance cesse de fonctionner correctement.<\/p>\n<p><\/p>\n<p>En conclusion, je tiens \u00e0 dire : nous avons r\u00e9ussi ! Nous avons pu fournir \u00e0 nos programmeurs et d\u00e9veloppeurs un outil capable de fournir rapidement et fid\u00e8lement des informations sur ce qui se passe en production, dans presque toutes les situations.<\/p>\n<p><\/p>\n<p>Oui, cela a \u00e9t\u00e9 assez complexe, mais n\u00e9anmoins, nous avons pu int\u00e9grer nos exigences dans des produits existants, sans avoir \u00e0 les patcher ou \u00e0 les r\u00e9\u00e9crire selon nos besoins.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch de plus de 200 To\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/494260\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435. \u041d\u043e \u0447\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442, \u043a\u043e\u0433\u0434\u0430 \u0445\u043e\u0447\u0435\u0448\u044c \u0441 \u0435\u0433\u043e \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438 \u00ab\u0432 \u043e\u0441\u043e\u0431\u043e \u043a\u0440\u0443\u043f\u043d\u043e\u043c \u043e\u0431\u044a\u0451\u043c\u0435\u00bb? \u0414\u0430 \u0435\u0449\u0451 \u0438 \u0431\u0435\u0437\u0431\u043e\u043b\u0435\u0437\u043d\u0435\u043d\u043d\u043e \u043f\u0435\u0440\u0435\u0436\u0438\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u0438\u0437 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u043e\u0432? \u041a\u0430\u043a\u043e\u0439 \u0441\u0442\u043e\u0438\u0442 \u0434\u0435\u043b\u0430\u0442\u044c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443, \u0438 \u043d\u0430 \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0435 \u043a\u0430\u043c\u043d\u0438 \u043d\u0430\u0442\u043a\u043d\u0451\u0448\u044c\u0441\u044f? \u041c\u044b \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0435\u0448\u0438\u043b\u0438 \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 elasticsearch \u0440\u0435\u0448\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u043b\u043e\u0433-\u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442\u0430, \u0430 \u0442\u0435\u043f\u0435\u0440\u044c \u0434\u0435\u043b\u0438\u043c\u0441\u044f \u0441 \u0425\u0430\u0431\u0440\u043e\u043c \u043e\u043f\u044b\u0442\u043e\u043c: \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":75797,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-75796","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 Elasticsearch \u043d\u0430 200 \u0422\u0411+ | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-03-28T17:42:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-28T17:42:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cluster Elasticsearch de plus de 200 To | ProHoster","description":"Beaucoup de gens sont confront\u00e9s \u00e0 Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 Elasticsearch \u043d\u0430 200 \u0422\u0411+ | ProHoster","og:description":"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-28T17:42:18+00:00","article:modified_time":"2020-03-28T17:42:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"75796","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:49:32","updated":"2022-09-27 21:24:26","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}