{"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\/it\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Cluster Elasticsearch da oltre 200 TB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>In molti si imbattono in Elasticsearch. Ma cosa succede quando si desidera utilizzarlo per memorizzare i log \"in grande quantit\u00e0\"? E come affrontare senza difficolt\u00e0 il guasto di uno dei numerosi data center? Quale architettura si dovrebbe realizzare e quali insidie si possono incontrare?<\/p>\n<p><\/p>\n<p>Noi di Odnoklassniki abbiamo deciso di affrontare la questione della gestione dei log usando Elasticsearch e ora condividiamo la nostra esperienza su Habr: parliamo sia di architettura che di possibili problematiche.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>\u042f \u2014 \u041f\u0451\u0442\u0440 \u0417\u0430\u0439\u0446\u0435\u0432, \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u0442\u043e\u0436\u0435 \u0431\u044b\u043b \u0430\u0434\u043c\u0438\u043d\u043e\u043c, \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0441 Manticore Search, Sphinx search, Elasticsearch. \u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0435\u0441\u043b\u0438 \u043f\u043e\u044f\u0432\u0438\u0442\u0441\u044f \u0435\u0449\u0451 \u043a\u0430\u043a\u043e\u0439-\u043d\u0438\u0431\u0443\u0434\u044c &#8230;search, \u0432\u0435\u0440\u043e\u044f\u0442\u043d\u043e \u0431\u0443\u0434\u0443 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0438 \u0441 \u043d\u0438\u043c. \u0422\u0430\u043a\u0436\u0435 \u0443\u0447\u0430\u0441\u0442\u0432\u0443\u044e \u0432 \u0440\u044f\u0434\u0435 \u043e\u043f\u0435\u043d\u0441\u043e\u0440\u0441\u043d\u044b\u0445 \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u043d\u0430 \u0434\u043e\u0431\u0440\u043e\u0432\u043e\u043b\u044c\u043d\u043e\u0439 \u043e\u0441\u043d\u043e\u0432\u0435.<\/p>\n<p><\/p>\n<p>Quando sono arrivato in Odnoklassniki, ho avventatamente affermato durante il colloquio che sapevo lavorare con Elasticsearch. Dopo aver preso confidenza e aver completato alcuni compiti semplici, mi \u00e8 stata assegnata una grande sfida: riformare il sistema di gestione dei log esistente in quel momento. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Requisiti<\/h2>\n<p><\/p>\n<p>I requisiti del sistema sono stati formulati come segue:<\/p>\n<p><\/p>\n<ul>\n<li>Come front-end doveva essere utilizzato Graylog. Questo perch\u00e9 l'azienda aveva gi\u00e0 esperienza nell'uso di questo prodotto, e programmatori e tester lo conoscevano, era familiare e comodo per loro.<\/li>\n<li>Volume dei dati: in media 50-80 mila messaggi al secondo, ma se qualcosa va storto, il traffico non \u00e8 limitato, pu\u00f2 arrivare a 2-3 milioni di righe al secondo.<\/li>\n<li>Discutendo con i clienti i requisiti per la velocit\u00e0 di elaborazione delle richieste di ricerca, abbiamo capito che il modello tipico di utilizzo di un sistema simile \u00e8 questo: le persone cercano i log della loro applicazione degli ultimi due giorni e non vogliono aspettare pi\u00f9 di un secondo per i risultati della richiesta formulata. <\/li>\n<li>Gli amministratori insistevano affinch\u00e9 il sistema potesse facilmente scalare, se necessario, senza richiedere loro una profonda comprensione di come fosse strutturato. <\/li>\n<li>L'unica operazione di manutenzione di cui questi sistemi avevano bisogno periodicamente era la sostituzione dell'hardware.<\/li>\n<li>Inoltre, in Odnoklassniki c'\u00e8 una splendida tradizione tecnica: qualsiasi servizio che lanciamo deve resistere all'interruzione di un data center (improvvisa, imprevista e in qualsiasi momento).<\/li>\n<\/ul>\n<p><\/p>\n<p>L'ultimo requisito nella realizzazione di questo progetto ci \u00e8 costato molto, di cui parler\u00f2 pi\u00f9 in dettaglio.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Ambiente<\/h2>\n<p><\/p>\n<p>Operiamo su quattro data center, mentre i nodi dati Elasticsearch possono trovarsi solo in tre (per una serie di motivi non tecnici).<\/p>\n<p><\/p>\n<p>In questi quattro data center ci sono circa 18.000 diverse sorgenti di log: hardware, container, macchine virtuali.<\/p>\n<p><\/p>\n<p>Una caratteristica importante: il cluster viene avviato in container <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> non su macchine fisiche, ma su <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">un prodotto cloud proprietario one-cloud<\/a><\/noindex>. Ai container vengono garantiti 2 core, equivalenti a 2.0Ghz v4, con la possibilit\u00e0 di utilizzare gli altri core in caso di inattivit\u00e0. <\/p>\n<p><\/p>\n<p>In altre parole:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topologia<\/h2>\n<p><\/p>\n<p>L'aspetto generale della soluzione mi era inizialmente apparso nel seguente modo:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP sono dietro il record A del dominio Graylog, \u00e8 l'indirizzo al quale vengono inviati i log.<\/li>\n<li>ogni VIP \u00e8 un bilanciatore LVS.<\/li>\n<li>Dopo di ci\u00f2, i log arrivano a una batteria Graylog, parte dei dati \u00e8 in formato GELF, parte in formato syslog.<\/li>\n<li>Successivamente, tutto questo viene scritto in grandi batch in una batteria di coordinatori Elasticsearch. <\/li>\n<li>E loro, a loro volta, inviano richieste di scrittura e lettura ai nodi dati pertinenti. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Terminologia<\/h2>\n<p><\/p>\n<p>\u00c8 possibile che non tutti abbiano familiarit\u00e0 con la terminologia, quindi vorremmo soffermarci un momento su di essa.<\/p>\n<p><\/p>\n<p>In Elasticsearch ci sono diversi tipi di nodi: master, coordinatore e nodo dati. Esistono anche altri due tipi per diverse trasformazioni dei log e per la connessione tra diversi cluster, ma noi abbiamo utilizzato solo quelli elencati. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nControlla tutti i nodi presenti nel cluster, mantiene la mappa del cluster aggiornata e la distribuisce tra i nodi, gestisce la logica degli eventi e si occupa di vari aspetti della manutenzione del cluster. <\/p>\n<p><\/p>\n<p><strong>Coordinatore<\/strong><br \/>\nSvolge un compito unico: accetta richieste dai clienti per la lettura o la scrittura e smista questo traffico. Nel caso di una richiesta di scrittura, probabilmente chieder\u00e0 al master in quale shard del relativo indice deve collocarlo e reindirizzer\u00e0 la richiesta. <\/p>\n<p><\/p>\n<p><strong>Nodo dati<\/strong><br \/>\nMemorizza i dati ed esegue le ricerche e le operazioni sugli shard ad essa associati.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nSi tratta di una sorta di fusione tra Kibana e Logstash nell'ELK stack. Graylog combina un'interfaccia utente e una pipeline per l'elaborazione dei log. Sotto il cofano, Graylog utilizza Kafka e Zookeeper, che garantiscono la connettivit\u00e0 del cluster Graylog. Graylog \u00e8 in grado di memorizzare in cache i log (Kafka) in caso di indisponibilit\u00e0 di Elasticsearch e ripetere le richieste di lettura e scrittura non riuscite, raggruppando e contrassegnando i log in base a regole predefinite. Proprio come Logstash, Graylog offre funzionalit\u00e0 per modificare le stringhe prima di scriverle in Elasticsearch.<\/p>\n<p><\/p>\n<p>Inoltre, Graylog ha un service discovery integrato che consente, partendo da un nodo Elasticsearch disponibile, di ottenere l'intera mappa del cluster e di filtrarla in base a un determinato tag, permettendo di indirizzare le richieste verso contenitori specifici.<\/p>\n<p><\/p>\n<p>Visualmente, appare pi\u00f9 o meno cos\u00ec:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Questo \u00e8 uno screenshot di un'istanza specifica. Qui costruiamo un istogramma in base alla query di ricerca, mostrando le righe pertinenti.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indici<\/h2>\n<p><\/p>\n<p>Tornando all'architettura del sistema, vorrei soffermarmi pi\u00f9 dettagliatamente su come abbiamo costruito il modello degli indici affinch\u00e9 tutto funzionasse correttamente. <\/p>\n<p><\/p>\n<p>Nello schema mostrato in precedenza, questo \u00e8 il livello pi\u00f9 basso: i nodi dati di Elasticsearch.<\/p>\n<p><\/p>\n<p>L'indice \u00e8 una grande entit\u00e0 virtuale composta da shard Elasticsearch. Ogni shard, a sua volta, non \u00e8 altro che un indice Lucene. E ogni indice Lucene, a sua volta, \u00e8 composto da uno o pi\u00f9 segmenti. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nella progettazione, abbiamo stimato che per soddisfare il requisito di velocit\u00e0 di lettura su un grande volume di dati, fosse necessario 'spalmare' uniformemente questi dati sui data node. <\/p>\n<p><\/p>\n<p>Questo si \u00e8 tradotto nel fatto che il numero di shard per indice (con repliche) deve essere strettamente uguale al numero di data node. In primo luogo, per garantire un fattore di replica pari a due (cio\u00e8 possiamo perdere met\u00e0 del cluster). In secondo luogo, per elaborare le richieste di lettura e scrittura, almeno su met\u00e0 del cluster.<\/p>\n<p><\/p>\n<p>Il tempo di conservazione inizialmente \u00e8 stato definito in 30 giorni.<\/p>\n<p><\/p>\n<p>La distribuzione degli shard pu\u00f2 essere rappresentata graficamente come segue:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>L'intero rettangolo grigio scuro rappresenta l'indice. Il quadrato rosso a sinistra \u00e8 il primary shard, il primo nell'indice. Il quadrato blu \u00e8 il replica shard. Si trovano in diversi data center.<\/p>\n<p><\/p>\n<p>Quando aggiungiamo un'altra shard, questa va nel terzo data center. E, alla fine, otteniamo una struttura come questa, che garantisce la possibilit\u00e0 di perdere un DC senza compromettere la coerenza dei dati:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo impostato la rotazione degli indici, ovvero la creazione di un nuovo indice e la rimozione di quello pi\u00f9 vecchio, a 48 ore (in base al modello di utilizzo dell'indice: nelle ultime 48 ore le ricerche avvengono pi\u00f9 frequentemente).<\/p>\n<p><\/p>\n<p>Questo intervallo di rotazione degli indici \u00e8 legato alle seguenti ragioni:<\/p>\n<p><\/p>\n<p>Quando una richiesta di ricerca arriva a una specifica data node, dal punto di vista delle prestazioni \u00e8 pi\u00f9 vantaggioso interrogare un solo shard, a condizione che la sua dimensione sia comparabile a quella della memoria della node. Questo consente di tenere la parte 'calda' dell'indice in memoria e accedervi rapidamente. Quando ci sono molte 'parti calde', la velocit\u00e0 di ricerca nell'indice ne risente.<\/p>\n<p><\/p>\n<p>Quando il nodo inizia a eseguire una query di ricerca su uno shard, assegna un numero di thread pari al numero di core fisici con hyper-threading nel server. Se la query di ricerca coinvolge un gran numero di shard, il numero di thread aumenta proporzionalmente. Questo influisce negativamente sulla velocit\u00e0 di ricerca e compromette l'indicizzazione di nuovi dati. <\/p>\n<p><\/p>\n<p>\u0427\u0442\u043e\u0431\u044b \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u044b\u0439 latency \u043f\u043e\u0438\u0441\u043a\u0430, \u043c\u044b \u0440\u0435\u0448\u0438\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c SSD. \u0414\u043b\u044f \u0431\u044b\u0441\u0442\u0440\u043e\u0439 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u043c\u0430\u0448\u0438\u043d\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0440\u0430\u0437\u043c\u0435\u0449\u0430\u043b\u0438\u0441\u044c \u044d\u0442\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b, \u0434\u043e\u043b\u0436\u043d\u044b \u0431\u044b\u043b\u0438 \u043e\u0431\u043b\u0430\u0434\u0430\u0442\u044c \u043f\u043e \u043c\u0435\u043d\u044c\u0448\u0435\u0439 \u043c\u0435\u0440\u0435 56 \u044f\u0434\u0440\u0430\u043c\u0438. \u0426\u0438\u0444\u0440\u0430 \u0432 56 \u0432\u044b\u0431\u0440\u0430\u043d\u0430 \u043a\u0430\u043a \u0443\u0441\u043b\u043e\u0432\u043d\u043e-\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u0430\u044f \u0432\u0435\u043b\u0438\u0447\u0438\u043d\u0430, \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u044e\u0449\u0430\u044f \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0442\u0440\u0435\u0434\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u0440\u043e\u0436\u0434\u0430\u0442\u044c Elasticsearch \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0440\u0430\u0431\u043e\u0442\u044b. \u0412 Elasitcsearch \u043c\u043d\u043e\u0433\u0438\u0435 \u043f\u0430\u0440\u0430\u043c\u0435\u0442\u0440\u044b thread pool \u043d\u0430\u043f\u0440\u044f\u043c\u0443\u044e \u0437\u0430\u0432\u0438\u0441\u044f\u0442 \u043e\u0442 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u044f\u0434\u0435\u0440, \u0447\u0442\u043e \u0432 \u0441\u0432\u043e\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u043f\u0440\u044f\u043c\u043e \u0432\u043b\u0438\u044f\u0435\u0442 \u043d\u0430 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0435 \u043a\u043e\u043b-\u0432\u043e \u043d\u043e\u0434 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443 &quot;\u043c\u0435\u043d\u044c\u0448\u0435 \u044f\u0434\u0435\u0440 \u2014 \u0431\u043e\u043b\u044c\u0448\u0435 \u043d\u043e\u0434&quot;. <\/p>\n<p><\/p>\n<p>Alla fine, abbiamo ottenuto che in media uno shard pesa circa 20 gigabyte, e per 1 indice ci sono 360 shard. Di conseguenza, se li ruotiamo ogni 48 ore, ne abbiamo 15. Ogni indice contiene dati per 2 giorni.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Schema di scrittura e lettura dei dati<\/h2>\n<p><\/p>\n<p>Vediamo come vengono registrati i dati in questo sistema.<\/p>\n<p><\/p>\n<p>Supponiamo di ricevere una richiesta da Graylog nel coordinatore. Ad esempio, vogliamo indicizzare 2-3 mila righe. <\/p>\n<p><\/p>\n<p>Il coordinatore, ricevuta la richiesta da Graylog, interroga il master: \"Nella richiesta di indicizzazione \u00e8 stato specificato un indice, ma non \u00e8 stato indicato in quale shard scrivere\". <\/p>\n<p><\/p>\n<p>Il Master risponde: \"Scrivi queste informazioni nello shard numero 71\", dopodich\u00e9 vengono inviate direttamente al nodo dati rilevante, dove si trova il primary-shard numero 71.<\/p>\n<p><\/p>\n<p>Successivamente, il log delle transazioni viene replicato sul replica-shard, che si trova gi\u00e0 in un altro data center.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Da Graylog arriva una richiesta di ricerca al coordinatore. Il coordinatore la reindirizza in base all'indice, mentre Elasticsearch distribuisce le richieste tra primary-shard e replica-shard secondo il principio del round-robin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Le nodi, in numero di 180, rispondono in modo non uniforme, e mentre rispondono, il coordinatore accumula informazioni che gi\u00e0 gli sono state \"spit out\" da nodi dati pi\u00f9 veloci. Dopo che tutte le informazioni sono arrivate o quando \u00e8 scaduto il timeout della richiesta, restituisce tutto direttamente al cliente. <\/p>\n<p><\/p>\n<p>L'intero sistema gestisce in media le richieste di ricerca negli ultimi 48 ore in 300-400 ms, escludendo quelle con carattere jolly iniziale.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u00abFiorellini\u00bb con Elasticsearch: configurazione di Java<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Affinch\u00e9 tutto questo funzionasse come volevamo inizialmente, abbiamo dedicato molto tempo a risolvere vari problemi nel cluster. <\/p>\n<p><\/p>\n<p>La prima parte dei problemi riscontrati riguardava la configurazione predefinita di Java in Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>Primo problema<\/strong><br \/>\n\u041c\u044b \u043d\u0430\u0431\u043b\u044e\u0434\u0430\u043b\u0438 \u043e\u0447\u0435\u043d\u044c \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u0443 \u043d\u0430\u0441 \u043d\u0430 \u0443\u0440\u043e\u0432\u043d\u0435 Lucene, \u043a\u043e\u0433\u0434\u0430 \u0437\u0430\u043f\u0443\u0449\u0435\u043d\u044b background job&#8217;\u044b, \u043c\u0435\u0440\u0434\u0436\u0438 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u043e\u0432 Lucene \u0437\u0430\u0432\u0435\u0440\u0448\u0430\u044e\u0442\u0441\u044f \u0441 \u043e\u0448\u0438\u0431\u043a\u043e\u0439. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u0432 \u043b\u043e\u0433\u0430\u0445 \u0431\u044b\u043b\u043e \u0432\u0438\u0434\u043d\u043e, \u0447\u0442\u043e \u044d\u0442\u043e OutOfMemoryError-\u043e\u0448\u0438\u0431\u043a\u0430. \u041f\u043e \u0442\u0435\u043b\u0435\u043c\u0435\u0442\u0440\u0438\u0438 \u043c\u044b \u0432\u0438\u0434\u0435\u043b\u0438, \u0447\u0442\u043e \u0445\u0438\u043f \u0441\u0432\u043e\u0431\u043e\u0434\u0435\u043d, \u0438 \u043d\u0435 \u0431\u044b\u043b\u043e \u043f\u043e\u043d\u044f\u0442\u043d\u043e, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u044f \u043f\u0430\u0434\u0430\u0435\u0442. <\/p>\n<p><\/p>\n<p>Si \u00e8 scoperto che i merge degli indici di Lucene avvenivano al di fuori dell'heap. Inoltre, i container sono piuttosto rigidamente limitati nelle risorse consumate. Queste risorse rientravano solo nell'heap (il valore heap.size era approssimativamente uguale alla RAM), mentre alcune operazioni off-heap fallivano con errori di allocazione di memoria se, per qualche motivo, non rientravano nei ~500 MB che rimanevano fino al limite.<\/p>\n<p><\/p>\n<p>La soluzione \u00e8 stata piuttosto semplice: abbiamo aumentato la quantit\u00e0 di RAM disponibile per il container, dopodich\u00e9 abbiamo smesso di avere problemi di questo tipo.<\/p>\n<p><\/p>\n<p><strong>Problema due<\/strong><br \/>\nDopo circa 4-5 giorni dal lancio del cluster, abbiamo notato che i nodi di dati cominciavano a disconnettersi periodicamente dal cluster, per poi riconnettersi dopo circa 10-20 secondi. <\/p>\n<p><\/p>\n<p>Quando abbiamo iniziato a indagare, ci siamo resi conto che la memoria off-heap in Elasticsearch non \u00e8 praticamente controllata. Quando abbiamo dato pi\u00f9 memoria al container, abbiamo potuto riempire i pool di buffer diretti con varie informazioni, e veniva liberata solo dopo l'attivazione di un GC esplicito da parte di Elasticsearch. <\/p>\n<p><\/p>\n<p>In alcuni casi, questa operazione avveniva piuttosto lentamente, e nel frattempo il cluster riusciva a contrassegnare quel nodo come gi\u00e0 disconnesso. Questo problema \u00e8 ben documentato. <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">qui<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>La soluzione \u00e8 stata la seguente: abbiamo limitato a Java la possibilit\u00e0 di utilizzare la maggior parte della memoria fuori dal heap per queste operazioni. L'abbiamo limitata a 16 gigabyte (-XX:MaxDirectMemorySize=16g), ottenendo cos\u00ec che il GC esplicito venisse attivato molto pi\u00f9 frequentemente e si esaurisse molto pi\u00f9 rapidamente, stabilizzando il cluster.<\/p>\n<p><\/p>\n<p><strong>Il terzo problema<\/strong><br \/>\nSe pensi che i problemi con i \"nodi che abbandonano il cluster nel momento pi\u00f9 inaspettato\" siano finiti, ti sbagli. <\/p>\n<p><\/p>\n<p>Quando abbiamo configurato il lavoro con gli indici, abbiamo scelto mmapfs per <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">ridurre il tempo di ricerca<\/a><\/noindex> sui nuovi shard con alta segmentazione. Questo si \u00e8 rivelato un errore piuttosto grossolano, perch\u00e9 con mmapfs il file viene mappato in memoria RAM, e poi lavoriamo gi\u00e0 con il file mappato. Di conseguenza, quando il garbage collector cerca di fermare i thread nell'applicazione, impieghiamo molto tempo per raggiungere il safepoint, e lungo il percorso l'applicazione smette di rispondere alle richieste del master riguardo alla sua disponibilit\u00e0. Pertanto, il master considera che il nodo non sia pi\u00f9 presente nel cluster. Dopo circa 5-10 secondi, il garbage collector entra in azione, il nodo si riprende, rientra nel cluster e inizia l'inizializzazione degli shard. Tutto questo ricordava molto il \u201cproduzione che ci meritavamo\u201d e non era adatto per nulla di serio.<\/p>\n<p><\/p>\n<p>Per risolvere questo comportamento, abbiamo prima migrato su standard niofs e poi, quando siamo passati dalle versioni 5 a quelle 6 di Elastic, abbiamo provato hybridfs, dove questo problema non si \u00e8 ripresentato. Puoi leggere di pi\u00f9 sui tipi di storage. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">qui<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Il quarto problema<\/strong><br \/>\nPoi c'\u00e8 stato un problema molto intrigante, che abbiamo affrontato per un tempo record. Lo abbiamo inseguito per 2-3 mesi, perch\u00e9 il suo schema era assolutamente incomprensibile. <\/p>\n<p><\/p>\n<p>A volte i nostri coordinatori andavano in Full GC, solitamente dopo pranzo, e non tornavano pi\u00f9. Durante il logging delle latenze GC, sembrava che tutto andasse bene, bene, bene, e poi all'improvviso \u2014 tutto andava male. <\/p>\n<p><\/p>\n<p>All'inizio pensavamo che avessimo un utente malintenzionato, che lanciava qualche richiesta che interrompeva il coordinatore dallo stato di lavoro. Abbiamo registrato le richieste a lungo, cercando di capire cosa stesse succedendo. <\/p>\n<p><\/p>\n<p>Alla fine si \u00e8 scoperto che nel momento in cui un utente invia una grande richiesta, e questa arriva su un coordinatore Elasticsearch specifico, alcune nodi rispondono pi\u00f9 lentamente delle altre. <\/p>\n<p><\/p>\n<p>E durante il tempo in cui il coordinatore attende la risposta da tutti i nodi, accumula in s\u00e9 i risultati inviati dai nodi che hanno gi\u00e0 risposto. Per il GC, questo significa che il nostro pattern di utilizzo della heap cambia molto rapidamente. E il GC che abbiamo utilizzato non riusciva a gestire questo compito. <\/p>\n<p><\/p>\n<p>L'unica soluzione che abbiamo trovato per cambiare il comportamento del cluster in questa situazione \u00e8 stata la migrazione a JDK13 e l'utilizzo del garbage collector Shenandoah. Questo ha risolto il problema, e i coordinatori hanno smesso di cadere. <\/p>\n<p><\/p>\n<p>In questo modo, i problemi con Java si sono conclusi e sono iniziati i problemi con la capacit\u00e0 di elaborazione. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u00abBacche\u00bb con Elasticsearch: capacit\u00e0 di elaborazione<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I problemi con la capacit\u00e0 di elaborazione significano che il nostro cluster funziona in modo stabile, ma nei picchi del numero di documenti indicizzati e nei momenti di manovra, le prestazioni non sono sufficienti.<\/p>\n<p><\/p>\n<p>Il primo sintomo riscontrato: durante alcuni \u00abesplosioni\u00bb in produzione, quando viene generata improvvisamente una grande quantit\u00e0 di log, in Graylog inizia a comparire frequentemente l'errore di indicizzazione es_rejected_execution. <\/p>\n<p><\/p>\n<p>Questo accade perch\u00e9 il thread_pool.write.queue su un nodo dati, fino a quando Elasticsearch riesce a elaborare la richiesta di indicizzazione e inviare le informazioni al shard su disco, per impostazione predefinita pu\u00f2 cacheare solo 200 richieste. E in <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">documentazione di Elasticsearch<\/a><\/noindex> si parla ben poco di questo parametro. Viene indicato solo il numero massimo di thread e la dimensione predefinita.<\/p>\n<p><\/p>\n<p>Naturalmente, abbiamo deciso di modificare questo valore e abbiamo scoperto quanto segue: specificamente nella nostra configurazione, \u00e8 possibile cacheare fino a 300 richieste, mentre un valore pi\u00f9 elevato comporta di nuovo il rischio di entrare in Full GC.<\/p>\n<p><\/p>\n<p>Inoltre, poich\u00e9 si tratta di blocchi di messaggi che arrivano all'interno di una sola richiesta, \u00e8 stato necessario anche regolare Graylog affinch\u00e9 scrivesse non frequentemente e in piccoli blocchi, ma in blocchi grandi o ogni 3 secondi, se il blocco non \u00e8 ancora completo. In questo caso, le informazioni che scriviamo in Elasticsearch diventano disponibili non dopo due secondi, ma dopo cinque (cosa che ci va bene), ma diminuisce il numero di retry necessari per inviare un grande pacchetto di informazioni.<\/p>\n<p><\/p>\n<p>Questo \u00e8 particolarmente importante nei momenti in cui qualcosa \u00e8 andato in crash e ci manda notifiche accanite, per evitare di sovraccaricare completamente Elastic, e dopo un po' di tempo avere nodi Graylog non funzionanti a causa di buffer pieni.<\/p>\n<p><\/p>\n<p>Inoltre, nel momento in cui abbiamo avuto queste esplosioni in produzione, ci sono arrivate lamentele da parte di programmatori e tester: quando avevano davvero bisogno di quei log, venivano forniti a loro con grande lentezza.<\/p>\n<p><\/p>\n<p>Abbiamo iniziato a indagare. Da un lato, era chiaro che le query di ricerca e le richieste di indicizzazione venivano elaborate, sostanzialmente, sulle stesse macchine fisiche, e ci sarebbero state, in un modo o nell'altro, delle cali di prestazioni. <\/p>\n<p><\/p>\n<p>Ma questo poteva essere in parte aggirato grazie al fatto che nelle versioni sei di Elasticsearch \u00e8 stato introdotto un algoritmo che consente di distribuire le richieste tra nodi data rilevanti non in base a un principio casuale round-robin (il container che si occupa dell'indicizzazione e tiene il primary-shard potrebbe essere molto occupato, e non ci sarebbe la possibilit\u00e0 di rispondere rapidamente), ma di indirizzare questa richiesta su un container meno carico con replica-shard, che risponder\u00e0 significativamente pi\u00f9 velocemente. In altre parole, siamo arrivati a use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>I quadri di lettura cominciano a presentarsi cos\u00ec:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Il passaggio a questo algoritmo ha permesso di migliorare notevolmente il tempo di query nei momenti in cui avevamo un grande flusso di log in scrittura.<\/p>\n<p><\/p>\n<p>Finalmente, il problema principale riguardava la gestione indolore del data center.<\/p>\n<p><\/p>\n<p>Cosa volevamo dal cluster subito dopo la perdita di connessione con un DC: <\/p>\n<p><\/p>\n<ul>\n<li>Se il master attuale si trova nel data center disconnesso, verr\u00e0 ripristinato e trasferito come ruolo su un altro nodo in un altro DC.<\/li>\n<li>Il master rimuover\u00e0 rapidamente dal cluster tutti i nodi non disponibili.<\/li>\n<li>Sulla base di quelli rimanenti, comprender\u00e0: nel data center perso avevamo spazi primari di questo tipo, promuover\u00e0 rapidamente gli shard replica complementari nei data center rimanenti, e continueremo a indicizzare i dati. <\/li>\n<li>Di conseguenza, la capacit\u00e0 del cluster in scrittura e lettura degrader\u00e0 gradualmente, tuttavia in generale tutto funzioner\u00e0, anche se lentamente, ma stabilmente.<\/li>\n<\/ul>\n<p><\/p>\n<p>Come si \u00e8 scoperto, volevamo qualcosa del genere:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>E abbiamo ottenuto quanto segue:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Come \u00e8 potuto accadere? <\/p>\n<p><\/p>\n<p>Nel momento della caduta del data center, il collo di bottiglia \u00e8 diventato il master.<\/p>\n<p><\/p>\n<p>Perch\u00e9?<\/p>\n<p><\/p>\n<p>La questione \u00e8 che nel master c'\u00e8 un TaskBatcher, responsabile della distribuzione di determinate attivit\u00e0 ed eventi nel cluster. Qualsiasi uscita di un nodo, qualsiasi promozione di uno shard da replica a primary, qualsiasi attivit\u00e0 di creazione di uno shard da qualche parte \u2014 tutto questo passa prima nel TaskBatcher, dove viene elaborato in sequenza e in un unico flusso.<\/p>\n<p><\/p>\n<p>Nel momento in cui un data center viene disconnesso, si verificava che tutti i data node nei data center sopravvissuti si sentissero obbligati a comunicare al master: \u00ababbiamo perso tali shard e tali data node\u00bb. <\/p>\n<p><\/p>\n<p>A questo punto, i data node sopravvissuti inviavano tutte queste informazioni al master attuale e cercavano di attendere una conferma che le avesse ricevute. Non ricevevano mai questa conferma, poich\u00e9 il master riceveva le attivit\u00e0 pi\u00f9 rapidamente di quanto riuscisse a rispondere. I nodi ripetevano le richieste dopo un timeout, mentre il master in quel momento non cercava nemmeno di rispondere, essendo completamente assorbito dall'attivit\u00e0 di ordinamento delle richieste per priorit\u00e0.<\/p>\n<p><\/p>\n<p>Nei log sono emerse problematiche in cui i nodi dati sovraccaricavano il master fino a causare un garbage collection completo. Successivamente, il ruolo del master veniva spostato su un altro nodo, e accadeva esattamente la stessa cosa, portando infine al completo crollo del cluster. <\/p>\n<p><\/p>\n<p>Abbiamo effettuato delle misurazioni e fino alla versione 6.4.0, dove questo problema \u00e8 stato risolto, ci bastava disattivare simultaneamente solo 10 nodi dati su 360 per mandare completamente in crash il cluster.<\/p>\n<p><\/p>\n<p>A questo punto, si presentava all'incirca in questo modo:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo la versione 6.4.0, dove \u00e8 stato risolto quel fastidioso bug, i nodi dati hanno smesso di sovraccaricare il master. Tuttavia, non \u00e8 diventato \u00abpi\u00f9 intelligente\u00bb. In particolare: quando disattiviamo 2, 3 o 10 (qualunque numero diverso da uno) nodi dati, il master riceve un primo messaggio che informa che il nodo A \u00e8 fuori servizio e cerca di comunicare questo nodo B, nodo C, nodo D. <\/p>\n<p><\/p>\n<p>Al momento, l'unico modo per affrontare questo problema \u00e8 impostare un timeout per i tentativi di comunicazione, pari a circa 20-30 secondi, gestendo cos\u00ec la velocit\u00e0 di disattivazione del data center dal cluster.<\/p>\n<p><\/p>\n<p>In linea di principio, questo rientra nei requisiti che erano stati inizialmente forniti per il prodotto finale all'interno del progetto, ma da un punto di vista di 'pura scienza', si tratta di un bug. Che, tra l'altro, \u00e8 stato risolto con successo dagli sviluppatori nella versione 7.2.<\/p>\n<p><\/p>\n<p>Infatti, quando un nodo datale si disconnetteva, risultava che diffondere l'informazione riguardo alla sua disconnessione fosse pi\u00f9 importante che comunicare a tutto il cluster che su di esso si trovavano tali primary-shard (per promuovere il replica-shard in un altro data center come primary, e poterci scrivere informazioni).<\/p>\n<p><\/p>\n<p>Pertanto, quando tutto si \u00e8 'calmato', i nodi datale fuori servizio non vengono immediatamente etichettati come stale. Di conseguenza, siamo costretti ad aspettare che tutti i ping ai nodi datale disconnessi timeout e solo dopo ci\u00f2 il nostro cluster inizia a comunicare che l\u00e0, l\u00e0 e l\u00e0 \u00e8 necessario continuare a scrivere informazioni. Maggiori dettagli possono essere letti qui. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">qui<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Alla fine, l'operazione di disconnessione del data center oggi ci richiede circa 5 minuti durante l'ora di punta. Per una macchina cos\u00ec grande e ingombrante, \u00e8 un risultato piuttosto buono.<\/p>\n<p><\/p>\n<p>Di conseguenza, siamo giunti alla seguente soluzione:<\/p>\n<p><\/p>\n<ul>\n<li>Abbiamo 360 nodi datale con dischi da 700 gigabyte.<\/li>\n<li>60 coordinatori per il routing del traffico verso questi nodi di dati.<\/li>\n<li>40 nodi che ci sono rimasti come un'eredit\u00e0 dalle versioni precedenti alla 6.4.0 \u2014 per affrontare la chiusura del data center, eravamo moralmente pronti a perdere alcune macchine, per garantire di avere un quorum di nodi anche nel peggiore dei scenari.<\/li>\n<li>Qualsiasi tentativo di combinare ruoli su un singolo container si \u00e8 scontrato con il fatto che prima o poi un nodo si rompeva sotto carico. <\/li>\n<li>In tutto il cluster viene utilizzato un heap.size pari a 31 gigabyte: tutti i tentativi di ridurre la dimensione portavano al fatto che durante pesanti query di ricerca con leading wildcard o si danneggiavano alcuni nodi, oppure si attivava il circuito di protezione in Elasticsearch stesso.<\/li>\n<li>Inoltre, per garantire le prestazioni di ricerca, cercavamo di mantenere il numero di oggetti nel cluster il pi\u00f9 minimo possibile, in modo da gestire il minor numero di eventi nel punto pi\u00f9 critico che abbiamo individuato nel master.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Infine, sul monitoraggio<\/h2>\n<p><\/p>\n<p>Per far funzionare tutto come previsto, monitoriamo quanto segue:<\/p>\n<p><\/p>\n<ul>\n<li>Ogni nodo di dati comunica al nostro cloud la sua presenza e quali shard ospita. Quando spegniamo qualcosa, il cluster riporta entro 2-3 secondi che nel centro A abbiamo spento i nodi 2, 3 e 4 \u2014 questo significa che non possiamo in alcun modo spegnere i nodi in altri data center che ospitano shard in singolo esemplare.<\/li>\n<li>Conoscendo il comportamento del master, monitoriamo attentamente il numero di task pending. Perch\u00e9 anche un singolo task bloccato, se non viene timeoutato in tempo, potrebbe teoricamente in una situazione critica diventare la causa per cui non riusciremo ad effettuare, ad esempio, la promozione dello shard replica in primario, il che interromperebbe l'indicizzazione.<\/li>\n<li>Inoltre, prestiamo particolare attenzione ai ritardi del garbage collector, poich\u00e9 in passato abbiamo avuto grandi difficolt\u00e0 con l'ottimizzazione in questo ambito.<\/li>\n<li>Il monitoraggio dei reject per i thread, per comprendere in anticipo dove si trova il \"coll bottleneck\".<\/li>\n<li>E le metriche standard, come heap, RAM e I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Quando si costruisce il monitoraggio, \u00e8 fondamentale considerare le peculiarit\u00e0 del Thread Pool in Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Documentazione di Elasticsearch<\/a><\/noindex> descrive le opzioni di configurazione e i valori predefiniti per la ricerca e l'indicizzazione, ma non menziona affatto thread_pool.management. Questi thread elaborano, in particolare, richieste tipo _cat\/shards e altre simili, che sono utili per scrivere monitoraggi. Pi\u00f9 grande \u00e8 il cluster, pi\u00f9 richieste di questo tipo vengono eseguite in un dato momento, e il thread_pool.management menzionato sopra non solo non \u00e8 presente nella documentazione ufficiale, ma \u00e8 anche limitato di default a 5 thread, che vengono rapidamente utilizzati, dopo di che il monitoraggio smette di funzionare correttamente.<\/p>\n<p><\/p>\n<p>Cosa voglio dire in conclusione: ce l'abbiamo fatta! Siamo riusciti a fornire ai nostri programmatori e sviluppatori uno strumento che pu\u00f2 fornire rapidamente e accuratamente informazioni su ci\u00f2 che sta accadendo in produzione in quasi ogni situazione.<\/p>\n<p><\/p>\n<p>S\u00ec, \u00e8 stato piuttosto complicato, ma, tuttavia, siamo riusciti a racchiudere le nostre richieste nei prodotti gi\u00e0 esistenti, senza doverli patchare o riscrivere per le nostre esigenze.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da oltre 200 TB\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Fonte: <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 4.9.10 - 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. \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\" \/>\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\/it\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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. \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\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/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 su 200 TB+ | ProHoster","description":"Molti si confrontano con Elasticsearch. Ma cosa succede quando vuoi usarlo per memorizzare registri \"in quantit\u00e0 considerevoli\"? E come affrontare senza problemi il fallimento di uno dei diversi data center? Quale architettura dovresti adottare e quali insidie potresti incontrare? Noi di Odnoklassniki abbiamo deciso di utilizzare Elasticsearch per risolvere il problema della gestione dei log, e ora condividiamo la nostra esperienza con Habrahabr.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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. \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","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}