{"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 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Molti si confrontano con Elasticsearch. Ma cosa succede quando desideri usarlo per memorizzare log in \"grandi quantit\u00e0\"? E come affrontare senza problemi il fallimento di uno dei diversi data center? Quale architettura dovresti adottare e quali insidie potresti incontrare?<\/p>\n<p><\/p>\n<p>Noi di Odnoklassniki abbiamo deciso di affrontare il problema della gestione dei log usando Elasticsearch e ora condividiamo con Habr la nostra esperienza: sia riguardo all'architettura che alle insidie.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Sono Pietro Zaitsev, lavoro come amministratore di sistema in Odnoklassniki. Prima ero anche un admin e ho lavorato con Manticore Search, Sphinx Search, Elasticsearch. Probabilmente, se apparir\u00e0 qualche altro ...search, lavorer\u00f2 anche con quello. Partecipo anche a diversi progetti open source su base volontaria.<\/p>\n<p><\/p>\n<p>Quando sono arrivato in Odnoklassniki, ho imprudentemente affermato durante il colloquio che sapevo usare Elasticsearch. Dopo essermi ambientato e aver svolto alcune semplici attivit\u00e0, mi \u00e8 stata affidata una grande operazione di riforma del sistema di gestione dei log esistente. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Requisiti<\/h2>\n<p><\/p>\n<p>I requisiti per il sistema sono stati formulati come segue:<\/p>\n<p><\/p>\n<ul>\n<li>Come frontend doveva essere utilizzato Graylog. Perch\u00e9 in azienda avevano gi\u00e0 esperienza con questo prodotto, i programmatori e i tester lo conoscevano, era familiare e comodo per loro.<\/li>\n<li>Volume di dati: in media 50-80 mila messaggi al secondo, ma se qualcosa si rompe, 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 query, ci siamo resi conto che il modello tipico di utilizzo di un sistema simile \u00e8 il seguente: le persone cercano i log della loro applicazione negli ultimi due giorni e non vogliono aspettare pi\u00f9 di un secondo per il risultato della query formulata. <\/li>\n<li>Gli amministratori insistettero affinch\u00e9 il sistema potesse essere facilmente scalabile se necessario, senza richiedere loro una profonda comprensione di come fosse strutturato. <\/li>\n<li>L'unico compito di manutenzione che questi sistemi necessitavano periodicamente era sostituire qualche hardware.<\/li>\n<li>Inoltre, in Odnoklassniki esiste una meravigliosa tradizione tecnica: ogni servizio che lanciamo deve sopportare il guasto di un data center (improvviso, non pianificato e in qualsiasi momento).<\/li>\n<\/ul>\n<p><\/p>\n<p>L'ultima richiesta per l'implementazione di questo progetto ci \u00e8 costata molto, di cui parler\u00f2 pi\u00f9 in dettaglio.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Ambiente<\/h2>\n<p><\/p>\n<p>Lavoriamo su quattro data center, ma i nodi dati di 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 fonti di log \u2014 hardware, contenitori, macchine virtuali.<\/p>\n<p><\/p>\n<p>Una caratteristica importante: l'avvio del cluster avviene nei contenitori <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\/\">prodotto cloud proprietario one-cloud<\/a><\/noindex>. Ai contenitori vengono garantiti 2 core, equivalenti a 2.0Ghz v4, con la possibilit\u00e0 di utilizzare i restanti 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 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 \u00e8 sembrato inizialmente il seguente:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIP sono dietro il record A del dominio Graylog, questo \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 un'unit\u00e0 Graylog, parte dei dati va nel formato GELF e parte nel formato syslog.<\/li>\n<li>Successivamente, tutto questo viene scritto in grandi batch a un'unit\u00e0 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 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>Forse non tutti hanno familiarit\u00e0 con la terminologia, quindi vorrei soffermarmi un attimo su di essa.<\/p>\n<p><\/p>\n<p>In Elasticsearch ci sono diversi tipi di nodi: master, coordinator, data node. Ci sono anche altri due tipi per diverse trasformazioni dei log e per la comunicazione tra diversi cluster, ma noi abbiamo utilizzato solo quelli elencati. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPinge tutti i nodi presenti nel cluster, mantiene aggiornata la mappa del cluster e la distribuisce tra i nodi, gestisce la logica degli eventi e si occupa di diverse operazioni di housekeeping su scala cluster. <\/p>\n<p><\/p>\n<p><strong>Coordinator<\/strong><br \/>\nSvolge un'unica funzione: accetta richieste dai clienti per la lettura o la scrittura e instrada questo traffico. Nel caso di una richiesta di scrittura, probabilmente chieder\u00e0 al master in quale shard dell'indice pertinente deve essere inserita e reindirizzer\u00e0 la richiesta. <\/p>\n<p><\/p>\n<p><strong>Data node<\/strong><br \/>\nConserva i dati e gestisce le query di ricerca e le operazioni sugli shard in essa collocati.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\n\u00c8 una sorta di fusione tra Kibana e Logstash nel stack ELK. Graylog combina un'interfaccia utente e un pipeline per la gestione dei log. Sotto il cofano, Graylog utilizza Kafka e Zookeeper, che garantiscono la connettivit\u00e0 di Graylog come cluster. Graylog pu\u00f2 memorizzare nella 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 secondo le regole impostate. Come Logstash, Graylog ha funzionalit\u00e0 di modifica delle stringhe prima di scriverle in Elasticsearch.<\/p>\n<p><\/p>\n<p>Inoltre, Graylog dispone di un servizio di discovery integrato che consente di ottenere l'intera mappa del cluster sulla base di un nodo Elasticsearch disponibile e di filtrarla in base a un tag specifico, consentendo di indirizzare le richieste verso contenitori specifici.<\/p>\n<p><\/p>\n<p>Visivamente, appare pi\u00f9 o meno cos\u00ec:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 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 sulla base di una query di ricerca, mostrando righe pertinenti.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indici<\/h2>\n<p><\/p>\n<p>Tornando all'architettura del sistema, vorrei entrare nei dettagli su come abbiamo costruito il modello degli indici affinch\u00e9 tutto funzionasse correttamente. <\/p>\n<p><\/p>\n<p>Nello schema precedente, questo \u00e8 il livello pi\u00f9 basso: i nodi dati di Elasticsearch.<\/p>\n<p><\/p>\n<p>Un indice \u00e8 una grande entit\u00e0 virtuale composta da shard di Elasticsearch. Ogni shard \u00e8, in effetti, un indice Lucene. 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 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nella progettazione, avevamo previsto che per soddisfare i requisiti di velocit\u00e0 di lettura su un grande volume di dati, fosse necessario \"spalmare\" equamente questi dati sui nodi dati. <\/p>\n<p><\/p>\n<p>Questo ha portato a stabilire che il numero di shard per indice (con repliche) dovesse essere esattamente uguale al numero di nodi dati. In primo luogo, per garantire un fattore di replica pari a due (ci\u00f2 significa che possiamo perdere met\u00e0 del cluster). In secondo luogo, per gestire le richieste di lettura e scrittura su almeno met\u00e0 del cluster.<\/p>\n<p><\/p>\n<p>Il tempo di conservazione \u00e8 stato inizialmente fissato a 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 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 \u00e8 l'indice. Il quadrato rosso a sinistra \u00e8 il primary shard, il primo nell'indice. E il quadrato blu \u00e8 il replica shard. Si trovano in diversi data center.<\/p>\n<p><\/p>\n<p>Quando aggiungiamo un altro shard, esso finisce nel terzo data center. E, alla fine, otteniamo una struttura del genere, che consente la perdita di un DC senza compromettere la consistenza dei dati:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 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 l'eliminazione del pi\u00f9 vecchio, a 48 ore (in base al pattern di utilizzo dell'indice: negli ultimi 48 ore si cercano 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 un nodo di data riceve una richiesta di ricerca, dal punto di vista delle prestazioni \u00e8 pi\u00f9 vantaggioso interrogare un solo shard, se la sua dimensione \u00e8 comparabile con quella della memoria della macchina. Questo permette di mantenere la parte \"calda\" dell'indice nella memoria e di accedervi rapidamente. Quando ci sono molte \"parti calde\", la velocit\u00e0 di ricerca per l'indice degrada.<\/p>\n<p><\/p>\n<p>Quando un nodo inizia a eseguire una richiesta di ricerca su uno shard, assegna un numero di thread pari al numero di core fisici nella macchina attivata per l'hyper-threading. Se la richiesta di ricerca coinvolge un gran numero di shard, il numero di thread aumenta in proporzione. Questo ha un effetto negativo sulla velocit\u00e0 di ricerca e influisce negativamente sull indicizzazione di nuovi dati. <\/p>\n<p><\/p>\n<p>Per garantire il necessario latency nella ricerca, abbiamo deciso di utilizzare SSD. Per una rapida elaborazione delle richieste, le macchine su cui erano ospitati questi container dovevano avere almeno 56 core. Il numero 56 \u00e8 stato scelto come valore condizionalmente sufficiente, determinando il numero di thread che Elasticsearch generer\u00e0 durante il funzionamento. In Elasticsearch, molti parametri del thread pool dipendono direttamente dal numero di core disponibili, il che influisce direttamente sul numero necessario di nodi nel cluster secondo il principio \"meno core \u2014 pi\u00f9 nodi\". <\/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\">Schemi di scrittura e lettura dei dati<\/h2>\n<p><\/p>\n<p>Analizziamo come vengono scritti i dati in questo sistema.<\/p>\n<p><\/p>\n<p>Supponiamo che riceviamo una richiesta da Graylog nel coordinatore. Ad esempio, vogliamo indicizzare 2-3 mila righe. <\/p>\n<p><\/p>\n<p>Il coordinatore, ricevuto il comando da Graylog, interroga il master: \u00abNella richiesta di indicizzazione abbiamo specificato esattamente l'indice, ma non \u00e8 stato indicato in quale shard scrivere\u00bb. <\/p>\n<p><\/p>\n<p>Il master risponde: \u00abScrivi queste informazioni nello shard numero 71\u00bb, dopodich\u00e9 viene indirizzato 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'altra data center.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 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 round-robin. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I nodi, per un totale di 180, rispondono in modo non uniforme e, mentre stanno rispondendo, il coordinatore accumula le informazioni che i nodi dati pi\u00f9 veloci hanno gi\u00e0 \u00abespulso\u00bb in lui. Dopo di che, quando tutte le informazioni sono arrivate o quando \u00e8 scaduto il timeout della richiesta, restituisce tutto direttamente al cliente. <\/p>\n<p><\/p>\n<p>Tutto questo sistema gestisce in media richieste di ricerca degli ultimi 48 ore in 300-400ms, escludendo quelle richieste con leading wildcard.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u00abFioriture\u00bb con Elasticsearch: configurazione di Java<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 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 all'inizio, abbiamo a lungo affinato le pi\u00f9 varie cose nel cluster. <\/p>\n<p><\/p>\n<p>La prima parte dei problemi riscontrati era legata a come Java \u00e8 preconfigurata per impostazione predefinita in Elasticsearch. <\/p>\n<p><\/p>\n<p><strong>Primo problema<\/strong><br \/>\nAbbiamo osservato un numero molto elevato di messaggi riguardanti il nostro livello Lucene, quando i job in background sono in esecuzione, i merge dei segmenti Lucene terminano con errore. Inoltre, nei log si vedeva che si trattava di un errore di OutOfMemoryError. Dalla telemetria abbiamo visto che l'heap era libero, e non era chiaro perch\u00e9 questa operazione fallisse. <\/p>\n<p><\/p>\n<p>Si \u00e8 scoperto che le fusioni degli indici Lucene avvengono fuori dall'heap. E i contenitori sono piuttosto rigidi in termini di risorse consumate. Queste risorse erano accessibili solo all'heap (il valore heap.size era circa uguale alla RAM), mentre alcune operazioni off-heap fallivano con un errore di allocazione di memoria se per qualche motivo non rientravano nei ~500MB che restavano prima del limite.<\/p>\n<p><\/p>\n<p>La soluzione era piuttosto semplice: abbiamo aumentato la quantit\u00e0 di RAM disponibile per il contenitore, dopo di che abbiamo dimenticato che avevamo mai avuto tali problemi.<\/p>\n<p><\/p>\n<p><strong>Secondo problema<\/strong><br \/>\nDopo circa 4-5 giorni dal lancio del cluster, abbiamo notato che i nodi dati iniziano a uscire periodicamente dal cluster e ad entrarvi dopo circa 10-20 secondi. <\/p>\n<p><\/p>\n<p>Quando abbiamo iniziato a indagare, \u00e8 emerso che la memoria off-heap in Elasticsearch non era praticamente controllata. Quando abbiamo allocato pi\u00f9 memoria al contenitore, abbiamo ottenuto la possibilit\u00e0 di riempire i pool di buffer diretti con diverse informazioni, e questi venivano ripuliti solo dopo che un GC esplicito veniva attivato da Elasticsearch. <\/p>\n<p><\/p>\n<p>In alcuni casi, questa operazione richiedeva molto tempo, e durante questo periodo il cluster riusciva a contrassegnare questo nodo come gi\u00e0 non disponibile. 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 al di fuori dell'heap per queste operazioni. Abbiamo limitato questa memoria a 16 gigabyte (-XX:MaxDirectMemorySize=16g), ottenendo che il GC esplicito fosse invocato molto pi\u00f9 frequentemente e funzionasse significativamente pi\u00f9 velocemente, stabilizzando cos\u00ec il cluster.<\/p>\n<p><\/p>\n<p><strong>Problema tre<\/strong><br \/>\nSe pensi che i problemi con \"i nodi che lasciano il cluster nel momento pi\u00f9 imprevisto\" siano finiti qui, 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 i tempi di ricerca<\/a><\/noindex> sui nuovi shard con una forte segmentazione. \u00c8 stato un errore piuttosto grossolano, perch\u00e9 usando mmapfs il file viene mappato nella memoria RAM, e poi lavoriamo gi\u00e0 con il file mappato. Di conseguenza, quando il GC cerca di fermare i thread nell'applicazione, impieghiamo molto tempo per arrivare al safepoint, e durante il tragitto l'applicazione smette di rispondere alle richieste del master su se sia viva o meno. Di conseguenza, il master pensa che il nodo non sia pi\u00f9 presente nel cluster. Dopo circa 5-10 secondi il garbage collector entra in azione, il nodo si riattiva, rientra nel cluster e inizia l'inizializzazione degli shard. Tutto ci\u00f2 somigliava molto a \"un sistema di produzione che abbiamo meritato\" e non era adatto per qualcosa di serio.<\/p>\n<p><\/p>\n<p>Per eliminare tale comportamento, inizialmente siamo passati a standard niofs, e poi, quando siamo migriati dalle versioni cinque di Elastic alle sei, abbiamo provato hybridfs, dove questo problema non si \u00e8 presentato. Maggiori dettagli sui tipi di storage possono essere letti. <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>Problema quattro<\/strong><br \/>\nPoi c'era un altro problema molto interessante, che abbiamo risolto in tempi record. L'abbiamo affrontato per 2-3 mesi, perch\u00e9 il suo schema era completamente incomprensibile. <\/p>\n<p><\/p>\n<p>A volte i nostri coordinatori andavano in Full GC, di solito dopo pranzo, e non tornavano mai indietro. Durante il log delle latenze GC, appariva cos\u00ec: tutto va bene, bene, bene e poi all'improvviso \u2014 tutto va a rotoli. <\/p>\n<p><\/p>\n<p>Inizialmente pensavamo che ci fosse un utente cattivo che avviava qualche richiesta che portava il coordinatore a uscire dalla modalit\u00e0 operativa. Abbiamo loggato a lungo le richieste cercando di capire cosa stesse succedendo. <\/p>\n<p><\/p>\n<p>Alla fine si \u00e8 scoperto che nel momento in cui un utente lanciava una grande richiesta e questa arrivava a un coordinatore Elasticsearch specifico, alcuni nodi rispondevano pi\u00f9 lentamente degli altri. <\/p>\n<p><\/p>\n<p>E mentre il coordinatore attendeva la risposta da tutti i nodi, accumulava i risultati inviati dai nodi che avevano gi\u00e0 risposto. Per il GC questo significa che il nostro modello di utilizzo dell'heap cambia rapidamente. E il GC che stavamo utilizzando 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'uso del garbage collector Shenandoah. Questo ha risolto il problema, i nostri coordinatori hanno smesso di cadere. <\/p>\n<p><\/p>\n<p>Cos\u00ec i problemi con Java sono finiti e sono iniziate le problematiche di throughput. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\"Frutti\" con Elasticsearch: throughput<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I problemi di throughput significano che il nostro cluster funziona in modo stabile, ma nei picchi di documenti indicizzati e durante le operazioni, le prestazioni non sono sufficienti.<\/p>\n<p><\/p>\n<p>Primo sintomo riscontrato: durante alcuni \"esplosioni\" in produzione, quando viene generata improvvisamente una grande quantit\u00e0 di log, su Graylog inizia a comparire frequentemente l'errore di indicizzazione es_rejected_execution. <\/p>\n<p><\/p>\n<p>Questo accadeva perch\u00e9 thread_pool.write.queue su un dato nodo, fino a quando Elasticsearch non \u00e8 in grado di elaborare la richiesta di indicizzazione e inviare le informazioni nel shard su disco, per impostazione predefinita pu\u00f2 memorizzare solo 200 richieste. E <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">nella documentazione di Elasticsearch<\/a><\/noindex> si parla molto poco di questo parametro. Viene indicato solo il numero massimo di thread e la dimensione predefinita.<\/p>\n<p><\/p>\n<p>Naturalmente, abbiamo iniziato a modificare questo valore e abbiamo scoperto che nel nostro setup si possono memorizzare abbastanza bene fino a 300 richieste, e valori maggiori comportano che torniamo a Full GC.<\/p>\n<p><\/p>\n<p>Inoltre, poich\u00e9 si tratta di pacchetti di messaggi che arrivano all'interno di una singola richiesta, \u00e8 stato necessario ottimizzare Graylog affinch\u00e9 scriva non frequentemente e in piccoli batch, ma in enormi batch o ogni 3 secondi, se il batch non \u00e8 ancora pieno. In questo modo, l'informazione che scriviamo in Elasticsearch diventa disponibile non dopo due secondi, ma dopo cinque (il che ci va bene), ma diminuisce il numero di retry necessari per inoltrare un grande pacchetto di informazioni.<\/p>\n<p><\/p>\n<p>Questo \u00e8 particolarmente importante nei momenti in cui abbiamo qualche malfunzionamento e lo segnala vigorosamente, per non ricevere Elastic completamente intasato di spam e, dopo un po', nodi Graylog non funzionanti a causa dei buffer pieni.<\/p>\n<p><\/p>\n<p>Inoltre, quando si verificavano queste esplosioni in produzione, ricevevamo lamentele da programmatori e tester: nel momento in cui avevano veramente bisogno di questi log, venivano loro forniti molto lentamente.<\/p>\n<p><\/p>\n<p>Abbiamo iniziato a indagare. Da un lato, era chiaro che sia le query di ricerca che le richieste di indicizzazione venivano elaborate, in sostanza, sulle stesse macchine fisiche e che, in un modo o nell'altro, ci sarebbero stati determinate fluttuazioni. <\/p>\n<p><\/p>\n<p>Ma questo poteva essere parzialmente aggirato grazie al fatto che nelle versioni sei di Elasticsearch \u00e8 stato introdotto un algoritmo che consente di distribuire le richieste tra i nodi dati rilevanti non secondo il principio casuale round-robin (il contenitore che si occupa dell'indicizzazione e detiene il primary-shard potrebbe essere molto occupato e non avere la possibilit\u00e0 di rispondere rapidamente), ma indirizzare questa richiesta a un contenitore meno sovraccarico con replica-shard, che risponder\u00e0 in modo significativamente pi\u00f9 veloce. In altre parole, siamo giunti all'uso di use_adaptive_replica_selection: true.<\/p>\n<p><\/p>\n<p>L'immagine di lettura inizia a apparire cos\u00ec:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>La transizione a questo algoritmo ha notevolmente migliorato il tempo di query nei momenti in cui abbiamo avuto un grande flusso di log in scrittura.<\/p>\n<p><\/p>\n<p>Infine, il problema principale era l'uscita 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 nel data center disconnesso si trova l'attuale master, questo verr\u00e0 riassegnato e trasferito come ruolo su un'altra node in un altro DC.<\/li>\n<li>Il master espeller\u00e0 rapidamente dal cluster tutti i nodi non disponibili.<\/li>\n<li>In base ai dati rimanenti, capir\u00e0: nel data center perso avevamo determinati shard primari, promuover\u00e0 rapidamente gli shard replica complementari nei data center rimanenti e continueremo con l indicizzazione dei dati. <\/li>\n<li>Di conseguenza, la capacit\u00e0 di scrittura e lettura del cluster degrader\u00e0 gradualmente, tuttavia, in generale, tutto continuer\u00e0 a funzionare, anche se lentamente, ma in modo stabile.<\/li>\n<\/ul>\n<p><\/p>\n<p>Come abbiamo scoperto, volevamo qualcosa di simile:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 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 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 succedere? <\/p>\n<p><\/p>\n<p>Nel momento in cui \u00e8 crollato il data center, il nostro collo di bottiglia \u00e8 stato il master.<\/p>\n<p><\/p>\n<p>Perch\u00e9?<\/p>\n<p><\/p>\n<p>Il fatto \u00e8 che nel master c'\u00e8 un TaskBatcher, responsabile della diffusione nel cluster di determinate attivit\u00e0 ed eventi. Qualsiasi uscita di un nodo, qualsiasi promozione di uno shard da replica a primario, qualsiasi compito di creazione di uno shard altrove \u2014 tutto questo passa prima nel TaskBatcher, dove viene elaborato in sequenza e in un solo thread.<\/p>\n<p><\/p>\n<p>Nel momento in cui un data center veniva disattivato, risultava che tutti i data node nei data center sopravvissuti si sentivano in dovere di comunicare al master \"ci sono mancati determinati shard e determinati data node\". <\/p>\n<p><\/p>\n<p>Nel frattempo, i data node sopravvissuti inviavano tutte queste informazioni all'attuale master e cercavano di attendere una conferma che lui le avesse ricevute. Non attendevano questa conferma, poich\u00e9 il master riceveva i compiti pi\u00f9 velocemente di quanto potesse rispondere. I nodi ripetevano le richieste dopo un timeout, e il master nel frattempo non cercava nemmeno di rispondere, ma era completamente assorbito dal compito di ordinare le richieste in base alla priorit\u00e0.<\/p>\n<p><\/p>\n<p>In forma terminale risultava che i data node spamavano il master fino a farlo andare in full GC. Dopo questo, il compito del master passava a un altro nodo, e succedeva esattamente la stessa cosa, e in definitiva il cluster si distruggeva completamente. <\/p>\n<p><\/p>\n<p>Effettuavamo misurazioni e fino alla versione 6.4.0, dove questo \u00e8 stato corretto, ci bastava disattivare contemporaneamente solo 10 data node su 360 per far collassare completamente il cluster.<\/p>\n<p><\/p>\n<p>Questo si presentava all'incirca cos\u00ec:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 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 questo brutto bug, i data node hanno smesso di far morire il master. Ma non \u00e8 diventato \"pi\u00f9 intelligente\" in questo modo. Cio\u00e8: quando disattiviamo 2, 3 o 10 (un qualsiasi numero diverso da uno) data node, il master riceve un primo messaggio che dice che il nodo A \u00e8 uscito e cerca di comunicare di questo al nodo B, nodo C, nodo D. <\/p>\n<p><\/p>\n<p>Attualmente, l'unico modo per affrontare questa situazione \u00e8 impostare un timeout per tentativi di comunicazione che durino circa 20-30 secondi, gestendo cos\u00ec la velocit\u00e0 di uscita del data center dal cluster.<\/p>\n<p><\/p>\n<p>Fondamentalmente, questo rientra nei requisiti inizialmente posti al prodotto finale all'interno del progetto, ma dal punto di vista della 'scienza pura' \u00e8 un bug. Che, tra l'altro, \u00e8 stato risolto con successo dagli sviluppatori nella versione 7.2.<\/p>\n<p><\/p>\n<p>In effetti, quando un certo nodo dati andava offline, risultava che diffondere informazioni sulla sua uscita fosse pi\u00f9 importante che informare tutto il cluster su quali primary-shard fossero presenti su di esso (per promuovere la replica-shard in un altro data center a primary, permettendo cos\u00ec di scrivere informazioni).<\/p>\n<p><\/p>\n<p>Pertanto, quando tutto \u00e8 finito, i nodi dati usciti non vengono immediatamente contrassegnati come obsoleti. Di conseguenza, dobbiamo aspettare che tutti i ping ai nodi dati non pi\u00f9 attivi scadano, e solo dopo il nostro cluster inizia a comunicare che in tal punto, tal altro punto e in tal altro punto \u00e8 necessario continuare a registrare informazioni. Per maggiori dettagli, puoi leggere qui. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">qui<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Di conseguenza, l'operazione di uscita dal data center oggi ci richiede circa 5 minuti durante le ore di punta. Per una macchina cos\u00ec grande e poco agile, \u00e8 un risultato piuttosto buono.<\/p>\n<p><\/p>\n<p>Alla fine, siamo giunti alla seguente soluzione:<\/p>\n<p><\/p>\n<ul>\n<li>Abbiamo 360 nodi dati con dischi da 700 gigabyte.<\/li>\n<li>60 coordinatori per instradare il traffico su questi nodi dati.<\/li>\n<li>40 nodi master, rimasti come un certo eredit\u00e0 dalle versioni precedenti alla 6.4.0 \u2014 per affrontare l'uscita dal data center, eravamo psicologicamente pronti a perdere alcune macchine, per garantire di avere sempre un quorum di master anche nel peggior scenario.<\/li>\n<li>Qualsiasi tentativo di combinare ruoli in un unico contenitore si \u00e8 scontrato con il fatto che, prima o poi, il nodo si rompeva sotto carico. <\/li>\n<li>In tutto il cluster \u00e8 impostato un heap.size pari a 31 gigabyte: ogni tentativo di ridurre la dimensione portava al fatto che, durante le ricerche pesanti con un leading wildcard, qualche nodo veniva ucciso oppure si attivava il circuit breaker in Elasticsearch stesso.<\/li>\n<li>Inoltre, per garantire le prestazioni di ricerca, abbiamo cercato di mantenere il numero di oggetti nel cluster al minimo possibile, per elaborare il minor numero di eventi possibile nel punto pi\u00f9 critico che abbiamo individuato nel master.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Infine, parliamo del monitoraggio.<\/h2>\n<p><\/p>\n<p>Affinch\u00e9 tutto funzioni come previsto, monitoriamo quanto segue:<\/p>\n<p><\/p>\n<ul>\n<li>Ogni nodo di data comunica al nostro cloud che esiste e su di esso ci sono determinati shard. Quando spegniamo qualcosa, il cluster riporta dopo 2-3 secondi che nel centro A abbiamo spento i nodi 2, 3 e 4 \u2014 questo significa che negli altri data center non possiamo assolutamente spegnere quei nodi su cui sono rimasti shard in esemplare unico.<\/li>\n<li>Conoscendo il comportamento del master, poniamo molta attenzione al numero di task in attesa. Perch\u00e9 anche un solo task bloccato, se non viene esaurito in tempo, pu\u00f2 teoricamente in una situazione di emergenza diventare la causa per cui il nostro processo di promozione dello shard replica nel primario non va a buon fine, causando l'arresto dell'indicizzazione.<\/li>\n<li>Inoltre, monitoriamo attentamente i ritardi del garbage collector, poich\u00e9 abbiamo gi\u00e0 avuto grandi difficolt\u00e0 con questo durante l'ottimizzazione.<\/li>\n<li>Rifiuti per i thread, per comprendere in anticipo dove si trova il collo di bottiglia.<\/li>\n<li>E le metriche standard, come heap, RAM e I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Quando costruiamo il monitoraggio, \u00e8 fondamentale tenere conto delle caratteristiche del Thread Pool in Elasticsearch. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">La documentazione di Elasticsearch<\/a><\/noindex> descrive le possibilit\u00e0 di configurazione e i valori predefiniti per la ricerca e l'indicizzazione, ma omette completamente il thread_pool.management. Questi thread gestiscono, tra l'altro, richieste tipo _cat\/shards e altre simili, che sono comode da usare per scrivere il monitoraggio. Pi\u00f9 grande \u00e8 il cluster, pi\u00f9 richieste di questo tipo vengono eseguite in unit\u00e0 di tempo, e il thread_pool.management menzionato sopra, non solo non \u00e8 presentato nella documentazione ufficiale, ma \u00e8 anche limitato di default a 5 thread, che vengono rapidamente esauriti, dopo di che il monitoraggio smette di funzionare correttamente.<\/p>\n<p><\/p>\n<p>In conclusione, ci tengo a dire: ce l'abbiamo fatta! Siamo riusciti a fornire ai nostri programmatori e sviluppatori uno strumento che \u00e8 in grado di fornire rapidamente e in modo affidabile informazioni su ci\u00f2 che accade in produzione in praticamente qualsiasi situazione.<\/p>\n<p><\/p>\n<p>S\u00ec, \u00e8 stata un'impresa piuttosto complessa, ma, tuttavia, siamo riusciti a integrare le nostre esigenze nei prodotti esistenti, senza doverli patchare o riscrivere per adattarli.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Cluster Elasticsearch da 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 5.0.1.1 - 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\/it\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\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.\" \/>\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 da oltre 200 TB | ProHoster","description":"Molti si confrontano con Elasticsearch.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}