Watu wengi wanapambana na Elasticsearch. Lakini nini kinatokea unapotaka kuitumia kuhifadhi magogo "kwa kiasi kikubwa sana"? Na pia haina uchungu kupata kutofaulu kwa kituo chochote cha data? Je, ni usanifu wa aina gani unapaswa kutengeneza, na ni mitego gani utajikwaa?
Sisi katika Odnoklassniki tuliamua kutumia elasticsearch kutatua suala la usimamizi wa logi, na sasa tunashiriki uzoefu wetu na Habr: wote kuhusu usanifu na kuhusu mitego.
Mimi ni Pyotr Zaitsev, ninafanya kazi kama msimamizi wa mfumo katika Odnoklassniki. Kabla ya hapo, nilikuwa pia msimamizi, nilifanya kazi na Manticore Search, Sphinx search, Elasticsearch. Labda, ikiwa ... utaftaji mwingine utaonekana, labda nitafanya kazi nayo pia. Pia ninashiriki katika miradi kadhaa ya chanzo huria kwa hiari.
Nilipofika Odnoklassniki, nilisema bila kujali kwenye mahojiano kwamba naweza kufanya kazi na Elasticsearch. Baada ya kuielewa na kukamilisha kazi kadhaa rahisi, nilipewa kazi kubwa ya kurekebisha mfumo wa usimamizi wa kumbukumbu uliokuwepo wakati huo.
Mahitaji
Mahitaji ya mfumo yameundwa kama ifuatavyo:
- Graylog ilipaswa kutumika kama sehemu ya mbele. Kwa sababu kampuni tayari ilikuwa na uzoefu wa kutumia bidhaa hii, watayarishaji programu na wanaojaribu waliijua, ilikuwa inajulikana na inafaa kwao.
- Kiasi cha data: kwa wastani ujumbe elfu 50-80 kwa sekunde, lakini ikiwa kitu kitavunjika, basi trafiki haizuiliwi na chochote, inaweza kuwa mistari milioni 2-3 kwa sekunde.
- Baada ya kujadiliana na wateja mahitaji ya kasi ya usindikaji wa maswali ya utaftaji, tuligundua kuwa muundo wa kawaida wa kutumia mfumo kama huu ni huu: watu wanatafuta kumbukumbu za maombi yao kwa siku mbili zilizopita na hawataki kungoja zaidi pili kwa matokeo ya swala iliyoundwa.
- Wasimamizi hao walisisitiza kuwa mfumo huo unaweza kuongezwa kwa urahisi ikiwa ni lazima, bila kuwahitaji kuchunguza kwa kina jinsi unavyofanya kazi.
- Ili kazi pekee ya matengenezo ambayo mifumo hii inahitaji mara kwa mara ni kubadilisha vifaa vingine.
- Kwa kuongeza, Odnoklassniki ina mila bora ya kiufundi: huduma yoyote ambayo tunazindua lazima iokoe kushindwa kwa kituo cha data (ghafla, bila mpango na kabisa wakati wowote).
Sharti la mwisho katika utekelezaji wa mradi huu lilitugharimu zaidi, ambalo nitalizungumza kwa undani zaidi.
Jumatano
Tunafanya kazi katika vituo vinne vya data, ilhali nodi za data za Elasticsearch zinaweza kupatikana katika tatu pekee (kwa sababu kadhaa zisizo za kiufundi).
Vituo hivi vinne vya data vina takriban vyanzo tofauti vya kumbukumbu elfu 18 - maunzi, vyombo, mashine pepe.
Kipengele muhimu: nguzo huanza kwenye vyombo si kwa mashine za kimwili, lakini juu . Vyombo vimehakikishiwa cores 2, sawa na 2.0Ghz v4, na uwezekano wa kuchakata cores zilizobaki ikiwa hazifanyi kazi.
Kwa maneno mengine:
Topolojia
Hapo awali niliona fomu ya jumla ya suluhisho kama ifuatavyo:
- VIP 3-4 ziko nyuma ya rekodi ya A ya kikoa cha Graylog, hii ndiyo anwani ambayo magogo yanatumwa.
- kila VIP ni mizani ya LVS.
- Baada yake, magogo huenda kwenye betri ya Graylog, baadhi ya data iko katika muundo wa GELF, baadhi katika muundo wa syslog.
- Kisha yote haya yameandikwa kwa makundi makubwa kwa betri ya waratibu wa Elasticsearch.
- Nao, kwa upande wake, hutuma maombi ya kuandika na kusoma kwa nodi za data husika.
Terminology
Labda sio kila mtu anaelewa istilahi kwa undani, kwa hivyo ningependa kukaa juu yake kidogo.
Elasticsearch ina aina kadhaa za nodes - bwana, mratibu, node ya data. Kuna aina zingine mbili za mabadiliko tofauti ya kumbukumbu na mawasiliano kati ya vikundi tofauti, lakini tulitumia zile tu zilizoorodheshwa.
Mwalimu
Huunganisha nodi zote zilizopo kwenye nguzo, hudumisha ramani ya nguzo iliyosasishwa na kuisambaza kati ya nodi, huchakata mantiki ya tukio, na hufanya aina mbalimbali za utunzaji wa nyumba kwa nguzo.
Mratibu wa
Hufanya kazi moja: inakubali maombi ya kusoma au kuandika kutoka kwa wateja na kuelekeza trafiki hii. Ikiwa kuna ombi la kuandika, uwezekano mkubwa, itauliza bwana ni sehemu gani ya faharisi inayofaa inapaswa kuiweka, na itaelekeza ombi tena.
Nodi ya data
Huhifadhi data, hufanya maswali ya utafutaji kutoka nje na kufanya shughuli kwenye shards ziko juu yake.
Kijivu
Hiki ni kitu kama muunganiko wa Kibana na Logstash kwenye rafu ya ELK. Graylog inachanganya UI na bomba la usindikaji wa kumbukumbu. Chini ya kofia, Graylog huendesha Kafka na Zookeeper, ambayo hutoa muunganisho kwa Graylog kama nguzo. Graylog inaweza kuweka akiba kumbukumbu (Kafka) endapo Elasticsearch haipatikani na kurudia maombi ambayo hayajafaulu ya kusoma na kuandika, panga na utie alama kumbukumbu kulingana na sheria zilizobainishwa. Kama Logstash, Graylog ina utendakazi wa kurekebisha safu mlalo kabla ya kuziandika kwa Elasticsearch.
Kwa kuongeza, Graylog ina ugunduzi wa huduma iliyojengwa ambayo inaruhusu, kulingana na nodi moja ya Elasticsearch, kupata ramani nzima ya nguzo na kuichuja kwa lebo maalum, ambayo inafanya uwezekano wa kuelekeza maombi kwa vyombo maalum.
Kwa kuibua inaonekana kitu kama hiki:
Hii ni picha ya skrini kutoka kwa mfano maalum. Hapa tunaunda histogram kulingana na hoja ya utafutaji na kuonyesha safu mlalo husika.
Faharisi
Kurudi kwenye usanifu wa mfumo, ningependa kukaa kwa undani zaidi juu ya jinsi tulivyojenga mfano wa index ili yote ifanye kazi kwa usahihi.
Katika mchoro hapo juu, hii ndiyo kiwango cha chini kabisa: Nodi za data za Elasticsearch.
Faharasa ni huluki kubwa pepe inayoundwa na shadi za Elasticsearch. Katika yenyewe, kila shards si kitu zaidi kuliko index Lucene. Na kila faharisi ya Lucene, kwa upande wake, ina sehemu moja au zaidi.
Wakati wa kubuni, tuligundua kuwa ili kukidhi mahitaji ya kasi ya kusoma kwenye kiasi kikubwa cha data, tulihitaji "kueneza" data hii kwa usawa katika nodi za data.
Hii ilisababisha ukweli kwamba idadi ya shards kwa kila index (iliyo na nakala) inapaswa kuwa sawa kabisa na idadi ya nodi za data. Kwanza, ili kuhakikisha sababu ya kurudia sawa na mbili (yaani, tunaweza kupoteza nusu ya nguzo). Na, pili, ili kushughulikia maombi ya kusoma na kuandika kwenye angalau nusu ya nguzo.
Kwanza tulibaini muda wa kuhifadhi kama siku 30.
Usambazaji wa shards unaweza kuwakilishwa graphically kama ifuatavyo:
Mstatili mzima wa kijivu giza ni index. Mraba nyekundu ya kushoto ndani yake ni shard ya msingi, ya kwanza katika index. Na mraba wa bluu ni shard replica. Ziko katika vituo tofauti vya data.
Tunapoongeza shard nyingine, huenda kwenye kituo cha data cha tatu. Na, mwishowe, tunapata muundo huu, ambayo inafanya uwezekano wa kupoteza DC bila kupoteza uthabiti wa data:
Mzunguko wa indexes, i.e. kuunda index mpya na kufuta ya zamani zaidi, tuliifanya kuwa sawa na saa 48 (kulingana na muundo wa matumizi ya index: saa 48 zilizopita hutafutwa mara nyingi).
Kipindi hiki cha mzunguko wa fahirisi ni kwa sababu zifuatazo:
Wakati ombi la utafutaji linapofika kwenye node maalum ya data, basi, kutoka kwa mtazamo wa utendaji, ni faida zaidi wakati shard moja inapoulizwa, ikiwa ukubwa wake unalinganishwa na ukubwa wa hip ya node. Hii inakuwezesha kuweka sehemu ya "moto" ya index kwenye lundo na kuifikia haraka. Wakati kuna mengi ya "sehemu za moto", kasi ya utafutaji wa index hupungua.
Wakati nodi inapoanza kutekeleza swala la utaftaji kwenye shard moja, hutenga idadi ya nyuzi sawa na idadi ya alama za hyperthreading za mashine halisi. Ikiwa swali la utafutaji linaathiri idadi kubwa ya shards, basi idadi ya nyuzi inakua kwa uwiano. Hii ina athari mbaya kwa kasi ya utafutaji na huathiri vibaya uwekaji faharasa wa data mpya.
Ili kutoa latency muhimu ya utafutaji, tuliamua kutumia SSD. Ili kushughulikia maombi kwa haraka, mashine zilizohifadhi kontena hizi zililazimika kuwa na angalau cores 56. Nambari ya 56 ilichaguliwa kama thamani ya kutosha kwa masharti ambayo huamua idadi ya nyuzi ambazo Elasticsearch itazalisha wakati wa operesheni. Katika Elasitcsearch, vigezo vingi vya dimbwi la nyuzi hutegemea moja kwa moja idadi ya cores zinazopatikana, ambazo huathiri moja kwa moja nambari inayotakiwa ya nodi kwenye nguzo kulingana na kanuni "cores chache - nodi zaidi".
Kama matokeo, tuligundua kuwa kwa wastani shard ina uzito wa gigabytes 20, na kuna shards 1 kwa kila index. Ipasavyo, ikiwa tutazizungusha mara moja kila masaa 360, basi tunayo 48 kati yao. Kila faharasa ina data ya siku 15.
Mizunguko ya kuandika na kusoma data
Wacha tuone jinsi data inavyorekodiwa katika mfumo huu.
Wacha tuseme ombi fulani hufika kutoka kwa Graylog hadi kwa mratibu. Kwa mfano, tunataka kuashiria safu 2-3 elfu.
Mratibu, akipokea ombi kutoka kwa Graylog, anauliza bwana: "Katika ombi la kuorodhesha, tulitaja faharisi haswa, lakini ambayo shard ya kuandika haikuainishwa."
Bwana anajibu: "Andika habari hii kwa nambari ya shard 71," baada ya hapo inatumwa moja kwa moja kwenye node ya data husika, ambapo nambari ya msingi-shard 71 iko.
Baada ya hapo logi ya muamala inaigwa kwa replica-shard, ambayo iko katika kituo kingine cha data.
Ombi la utafutaji linafika kutoka kwa Graylog hadi kwa mratibu. Mratibu huielekeza upya kulingana na faharasa, huku Elasticsearch inasambaza maombi kati ya sehemu ya msingi na sehemu ya kuiga kwa kutumia kanuni ya robin-raundi.
Node 180 hujibu kwa usawa, na wakati wanajibu, mratibu anakusanya taarifa ambazo tayari "zimepigwa mate" na nodi za data za kasi zaidi. Baada ya hayo, wakati ama taarifa zote zimefika, au ombi limefikia wakati, inatoa kila kitu moja kwa moja kwa mteja.
Mfumo huu mzima kwa wastani huchakata hoja za utafutaji kwa saa 48 zilizopita katika 300-400ms, bila kujumuisha hoja hizo zilizo na kadi-mwitu inayoongoza.
Maua yenye Elasticsearch: usanidi wa Java
Ili kuifanya yote ifanye kazi jinsi tulivyotaka awali, tulitumia muda mrefu sana kutatua aina mbalimbali za vitu kwenye nguzo.
Sehemu ya kwanza ya matatizo yaliyogunduliwa ilihusiana na jinsi Java inavyosanidiwa awali na chaguo-msingi katika Elasticsearch.
Tatizo moja
Tumeona idadi kubwa sana ya ripoti kwamba katika kiwango cha Lucene, wakati kazi za chinichini zinapoendelea, muunganisho wa sehemu ya Lucene hushindwa na hitilafu. Wakati huo huo, ilikuwa wazi katika kumbukumbu kwamba hii ilikuwa kosa la OutOfMemoryError. Tuliona kutoka kwa telemetry kwamba hip ilikuwa bure, na haikuwa wazi kwa nini operesheni hii ilikuwa ikishindwa.
Ilibadilika kuwa index ya Lucene inaunganisha hutokea nje ya hip. Na vyombo ni madhubuti kabisa katika suala la rasilimali zinazotumiwa. Lundo pekee lingeweza kutoshea kwenye rasilimali hizi (thamani ya heap.size ilikuwa takriban sawa na RAM), na baadhi ya shughuli za nje ya lundo ziligonga na hitilafu ya ugawaji kumbukumbu ikiwa kwa sababu fulani hazikutoshea kwenye ~500MB iliyosalia kabla ya kikomo.
Marekebisho yalikuwa madogo kabisa: kiasi cha RAM kilichopatikana kwa chombo kiliongezeka, baada ya hapo tulisahau kwamba hata tulikuwa na matatizo hayo.
Tatizo la pili
Siku 4-5 baada ya kuzinduliwa kwa nguzo, tuliona kwamba nodi za data zilianza mara kwa mara kuanguka nje ya nguzo na kuiingiza baada ya sekunde 10-20.
Tulipoanza kuitambua, ikawa kwamba kumbukumbu hii ya mbali katika Elasticsearch haidhibitiwi kwa njia yoyote. Tulipotoa kumbukumbu zaidi kwa kontena, tuliweza kujaza vidimbwi vya akiba vya moja kwa moja na taarifa mbalimbali, na iliondolewa tu baada ya GC ya uwazi kuzinduliwa kutoka Elasticsearch.
Katika baadhi ya matukio, operesheni hii ilichukua muda mrefu sana, na wakati huu nguzo iliweza kuashiria nodi hii kama tayari imetoka. Tatizo hili limeelezwa vizuri .
Suluhisho lilikuwa kama ifuatavyo: tulipunguza uwezo wa Java wa kutumia kumbukumbu nyingi nje ya lundo kwa shughuli hizi. Tuliiwekea gigabaiti 16 (-XX:MaxDirectMemorySize=16g), ili kuhakikisha kuwa GC ya lugha chafu iliitwa mara nyingi zaidi na kuchakatwa kwa haraka zaidi, kwa hivyo haikuharibu tena nguzo.
Tatizo la tatu
Ikiwa unafikiri kwamba matatizo na "nodi zinazoacha nguzo kwa wakati usiotarajiwa" zimekwisha, umekosea.
Tuliposanidi kazi na faharasa, tulichagua mmapfs kwa juu ya shards safi na segmentation kubwa. Hili lilikuwa kosa kabisa, kwa sababu wakati wa kutumia mmapfs faili imepangwa kwenye RAM, na kisha tunafanya kazi na faili iliyopangwa. Kwa sababu ya hili, zinageuka kuwa wakati GC inapojaribu kusimamisha nyuzi katika maombi, tunaenda kwa salama kwa muda mrefu sana, na tukiwa njiani, maombi yanaacha kujibu maombi ya bwana kuhusu ikiwa iko hai. . Ipasavyo, bwana anaamini kuwa nodi haipo tena kwenye nguzo. Baada ya hayo, baada ya sekunde 5-10, mtoza takataka hufanya kazi, node inakuja hai, inaingia kwenye kikundi tena na huanza kuanzisha shards. Yote ilihisi kama "uzalishaji tuliostahili" na haukufaa kwa chochote kikubwa.
Ili kuondokana na tabia hii, tulibadilisha kwanza kwenye niofs za kawaida, na kisha, tulipohamia kutoka kwa matoleo ya tano ya Elastic hadi ya sita, tulijaribu hybridfs, ambapo tatizo hili halikuzalishwa tena. Unaweza kusoma zaidi kuhusu aina za hifadhi .
Tatizo la nne
Kisha kulikuwa na tatizo lingine la kuvutia sana ambalo tulishughulikia kwa muda wa rekodi. Tuliikamata kwa miezi 2-3 kwa sababu muundo wake haukueleweka kabisa.
Wakati mwingine waratibu wetu walienda kwa Full GC, kwa kawaida wakati fulani baada ya chakula cha mchana, na hawakurudi kutoka hapo. Wakati huo huo, wakati wa kuingia kuchelewa kwa GC, ilionekana kama hii: kila kitu kinaendelea vizuri, vizuri, vizuri, na kisha ghafla kila kitu kinakwenda vibaya sana.
Mwanzoni tulifikiri kwamba tulikuwa na mtumiaji mwovu ambaye alikuwa akizindua aina fulani ya ombi ambalo liliondoa mratibu kutoka katika hali ya kufanya kazi. Tuliandika maombi kwa muda mrefu sana, tukijaribu kujua kinachotokea.
Kama matokeo, ikawa kwamba wakati mtumiaji anapozindua ombi kubwa, na anapata mratibu maalum wa Elasticsearch, nodi zingine hujibu kwa muda mrefu zaidi kuliko zingine.
Na wakati mratibu anasubiri majibu kutoka kwa nodes zote, hujilimbikiza matokeo yaliyotumwa kutoka kwa nodes ambazo tayari zimejibu. Kwa GC, hii inamaanisha kuwa mifumo yetu ya utumiaji lundo hubadilika haraka sana. Na GC ambayo tulitumia haikuweza kukabiliana na kazi hii.
Marekebisho pekee tuliyopata ya kubadilisha tabia ya nguzo katika hali hii ni kuhamia JDK13 na matumizi ya kikusanya takataka cha Shenandoah. Hili lilitatua tatizo, waratibu wetu waliacha kuanguka.
Hapa ndipo shida na Java ziliisha na shida za bandwidth zilianza.
"Berries" pamoja na Elasticsearch: throughput
Matatizo ya matokeo yanamaanisha kuwa nguzo yetu inafanya kazi kwa uthabiti, lakini katika kilele cha idadi ya hati zilizoorodheshwa na wakati wa ujanja, utendakazi hautoshi.
Dalili ya kwanza inakabiliwa: wakati wa baadhi ya "milipuko" katika uzalishaji, wakati idadi kubwa sana ya magogo huzalishwa kwa ghafla, kosa la indexing es_rejected_execution huanza kuangaza mara kwa mara katika Graylog.
Hii ilitokana na ukweli kwamba thread_pool.write.queue kwenye nodi moja ya data, hadi wakati Elasticsearch inapoweza kuchakata ombi la kuorodhesha na kupakia habari kwenye shard kwenye diski, inaweza kuweka akiba maombi 200 tu kwa chaguo-msingi. Na katika Kidogo sana kinasemwa kuhusu parameter hii. Idadi ya juu tu ya nyuzi na saizi chaguo-msingi ndizo zimeonyeshwa.
Kwa kweli, tulienda kupotosha thamani hii na tukagundua yafuatayo: haswa, katika usanidi wetu, hadi maombi 300 yamehifadhiwa vizuri, na dhamana ya juu imejaa ukweli kwamba tunaruka tena kwenye GC Kamili.
Kwa kuongeza, kwa kuwa haya ni makundi ya ujumbe unaofika ndani ya ombi moja, ilikuwa ni lazima kurekebisha Graylog ili iandike si mara nyingi na kwa makundi madogo, lakini kwa makundi makubwa au mara moja kila sekunde 3 ikiwa kundi bado halijakamilika. Katika kesi hii, zinageuka kuwa habari tunayoandika katika Elasticsearch haipatikani kwa sekunde mbili, lakini kwa tano (ambayo inatufaa vizuri), lakini idadi ya retrays ambazo zinapaswa kufanywa ili kusukuma kwa njia kubwa. msururu wa habari umepunguzwa.
Hii ni muhimu sana katika nyakati hizo wakati kitu kimeanguka mahali fulani na kinaripoti kwa hasira juu yake, ili usipate Elastic iliyotumwa kabisa, na baada ya muda - nodi za Greylog ambazo hazifanyi kazi kwa sababu ya buffers iliyoziba.
Kwa kuongezea, tulipokuwa na milipuko kama hiyo katika uzalishaji, tulipokea malalamiko kutoka kwa waandaaji wa programu na wajaribu: kwa sasa wakati walihitaji magogo haya, walipewa polepole sana.
Walianza kubaini. Kwa upande mmoja, ilikuwa wazi kwamba maswali yote ya utafutaji na maswali ya indexing yalichakatwa, kimsingi, kwenye mashine sawa za kimwili, na kwa njia moja au nyingine kutakuwa na vikwazo fulani.
Lakini hii inaweza kuzungushwa kwa sababu ya ukweli kwamba katika matoleo ya sita ya Elasticsearch, algorithm ilionekana ambayo hukuruhusu kusambaza maswali kati ya nodi za data zinazofaa sio kulingana na kanuni ya nasibu-robin (chombo ambacho hufanya indexing na kushikilia msingi. -shard inaweza kuwa na shughuli nyingi, hakutakuwa na njia ya kujibu haraka), lakini kupeleka ombi hili kwa chombo kidogo kilichopakiwa na replica-shard, ambayo itajibu kwa kasi zaidi. Kwa maneno mengine, tulifikia use_adaptive_replica_selection: true.
Picha ya kusoma huanza kuonekana kama hii:
Mpito kwa algoriti hii ulifanya iwezekane kuboresha kwa kiasi kikubwa muda wa hoja katika nyakati hizo ambapo tulikuwa na mtiririko mkubwa wa kumbukumbu za kuandika.
Hatimaye, tatizo kuu lilikuwa kuondolewa bila maumivu kwa kituo cha data.
Tulichotaka kutoka kwa nguzo mara baada ya kupoteza uhusiano na DC mmoja:
- Ikiwa tunayo bwana wa sasa katika kituo cha data kilichoshindwa, basi kitachaguliwa tena na kuhamishwa kama jukumu kwa nodi nyingine katika DC nyingine.
- Bwana ataondoa haraka nodi zote zisizoweza kufikiwa kutoka kwa nguzo.
- Kulingana na zile zilizobaki, ataelewa: katika kituo cha data kilichopotea tulikuwa na shards vile na vile vya msingi, atakuza haraka shards za replica katika vituo vilivyobaki vya data, na tutaendelea kuorodhesha data.
- Kama matokeo ya hili, uandishi wa nguzo na usomaji wa usomaji utapungua polepole, lakini kwa ujumla kila kitu kitafanya kazi, polepole, lakini kwa utulivu.
Kama ilivyotokea, tulitaka kitu kama hiki:
Na tulipata yafuatayo:
Hii ilitokeaje?
Wakati kituo cha data kilianguka, bwana wetu akawa kizuizi.
Kwa nini?
Ukweli ni kwamba bwana ana TaskBatcher, ambayo ni wajibu wa kusambaza kazi fulani na matukio katika nguzo. Toka kwa nodi yoyote, ukuzaji wowote wa shard kutoka nakala hadi msingi, kazi yoyote ya kuunda shard mahali fulani - yote haya huenda kwanza kwa TaskBatcher, ambapo huchakatwa kwa kufuatana na kwa uzi mmoja.
Wakati wa uondoaji wa kituo kimoja cha data, iliibuka kuwa nodi zote za data katika vituo vilivyobaki vya data ziliona kuwa ni jukumu lao kumjulisha bwana "tumepoteza sehemu kama hizi na nodi za data."
Wakati huo huo, nodi za data zilizobaki zilituma habari hii yote kwa bwana wa sasa na kujaribu kungojea uthibitisho kwamba aliikubali. Hawakungoja hii, kwani bwana alipokea kazi haraka kuliko angeweza kujibu. Nodi zilimaliza maombi ya kurudia, na bwana kwa wakati huu hakujaribu hata kujibu, lakini aliingizwa kabisa katika kazi ya kupanga maombi kwa kipaumbele.
Katika fomu ya terminal, ikawa kwamba nodi za data zilimwaga barua taka hadi kufikia GC kamili. Baada ya hapo, jukumu letu kuu lilihamia kwenye nodi iliyofuata, jambo lile lile lilifanyika kwake, na matokeo yake nguzo hiyo ikaanguka kabisa.
Tulichukua vipimo, na kabla ya toleo la 6.4.0, ambapo hii ilirekebishwa, ilitosha sisi kutoa wakati huo huo nodi 10 za data kati ya 360 ili kuzima kabisa nguzo.
Ilionekana kitu kama hiki:
Baada ya toleo la 6.4.0, ambapo hitilafu hii mbaya ilirekebishwa, nodi za data ziliacha kumuua bwana. Lakini hilo halikumfanya kuwa βmwerevu zaidi.β Yaani: tunapotoa nodi za data 2, 3 au 10 (nambari yoyote isipokuwa moja), bwana hupokea ujumbe wa kwanza unaosema kwamba nodi A imeondoka, na anajaribu kuwaambia nodi B, nodi C kuhusu hili, nodi D.
Na kwa sasa, hii inaweza tu kushughulikiwa kwa kuweka muda wa kujaribu kumwambia mtu kuhusu jambo fulani, sawa na sekunde 20-30, na hivyo kudhibiti kasi ya kituo cha data kinachohamia nje ya nguzo.
Kimsingi, hii inalingana na mahitaji ambayo hapo awali yaliwasilishwa kwa bidhaa ya mwisho kama sehemu ya mradi, lakini kutoka kwa mtazamo wa "sayansi safi" hii ni mdudu. Ambayo, kwa njia, iliwekwa kwa ufanisi na watengenezaji katika toleo la 7.2.
Kwa kuongezea, wakati nodi fulani ya data ilipotoka, iliibuka kuwa kusambaza habari juu ya kutoka kwake ilikuwa muhimu zaidi kuliko kuwaambia nguzo nzima kwamba kulikuwa na sehemu kama hizo za msingi juu yake (ili kukuza nakala ya nakala kwenye data nyingine. katikati katika shule ya msingi, na katika habari inaweza kuandikwa juu yao).
Kwa hivyo, wakati kila kitu tayari kimekufa, nodi za data zilizotolewa hazijawekwa alama mara moja kama za zamani. Ipasavyo, tunalazimika kungoja hadi pings zote zimeisha kwa nodi za data zilizotolewa, na tu baada ya kuwa nguzo yetu huanza kutuambia kwamba huko, huko, na huko tunahitaji kuendelea kurekodi habari. Unaweza kusoma zaidi kuhusu hili .
Kwa hivyo, operesheni ya kuondoa kituo cha data leo hutuchukua kama dakika 5 wakati wa saa ya haraka sana. Kwa colossus kubwa na dhaifu kama hii, hii ni matokeo mazuri.
Kama matokeo, tulifikia uamuzi ufuatao:
- Tuna nodi za data 360 zilizo na diski 700 za gigabyte.
- Waratibu 60 wa kuelekeza trafiki kupitia nodi hizi za data.
- Mabwana 40 ambao tumewaacha kama aina ya urithi tangu matoleo kabla ya 6.4.0 - ili kunusurika uondoaji wa kituo cha data, tulijitayarisha kiakili kupoteza mashine kadhaa ili kuhakikishiwa kuwa na akidi ya mabwana hata katika hali mbaya zaidi
- Majaribio yoyote ya kuchanganya majukumu kwenye chombo kimoja yalikutana na ukweli kwamba mapema au baadaye node ingevunja chini ya mzigo.
- Kundi zima linatumia heap.size ya gigabaiti 31: majaribio yote ya kupunguza ukubwa yalisababisha ama kuua baadhi ya nodi kwenye hoja nzito za utafutaji kwa kutumia kadi-mwitu inayoongoza au kupata kivunja mzunguko katika Elasticsearch yenyewe.
- Kwa kuongeza, ili kuhakikisha utendaji wa utafutaji, tulijaribu kuweka idadi ya vitu kwenye nguzo ndogo iwezekanavyo, ili kuchakata matukio machache iwezekanavyo katika kizuizi ambacho tulipata katika bwana.
Hatimaye kuhusu ufuatiliaji
Ili kuhakikisha kuwa haya yote yanafanya kazi kama ilivyokusudiwa, tunafuatilia yafuatayo:
- Kila nodi ya data inaripoti kwa wingu letu kuwa iko, na kuna vijisehemu hivi na vile juu yake. Tunapozima kitu mahali fulani, nguzo hiyo inaripoti baada ya sekunde 2-3 kwamba katikati A tulizima nodi 2, 3, na 4 - hii inamaanisha kuwa katika vituo vingine vya data sisi kwa hali yoyote hatuwezi kuzima nodi hizo ambazo kuna shard moja tu. kushoto.
- Kujua asili ya tabia ya bwana, tunaangalia kwa makini sana idadi ya kazi zinazosubiri. Kwa sababu hata kazi moja iliyokwama, ikiwa haijaisha kwa wakati, kinadharia katika hali fulani ya dharura inaweza kuwa sababu kwa nini, kwa mfano, uendelezaji wa shard ya replica katika msingi haufanyi kazi, ndiyo sababu indexing itaacha kufanya kazi.
- Pia tunaangalia kwa karibu sana ucheleweshaji wa wakusanyaji taka, kwa sababu tayari tumekuwa na shida kubwa na hii wakati wa uboreshaji.
- Inakataa kwa thread ili kuelewa mapema ambapo kizuizi ni.
- Vipimo vya kawaida kama vile lundo, RAM na I/O.
Wakati wa kujenga ufuatiliaji, lazima uzingatie vipengele vya Thread Pool katika Elasticsearch. inafafanua chaguo za usanidi na thamani chaguomsingi za utafutaji na uwekaji faharasa, lakini haiko kimya kuhusu thread_pool.management. Minyororo hii huchakata, hasa, hoja kama vile _cat/shards na zingine zinazofanana, ambazo ni rahisi kutumia wakati wa kuandika ufuatiliaji. Kadiri kundi linavyokuwa kubwa, ndivyo maombi kama hayo yanavyotekelezwa kwa kila kitengo cha muda, na thread_pool.management iliyotajwa hapo juu haiwakilishwi tu katika hati rasmi, lakini pia inadhibitiwa kwa chaguo-msingi kwa nyuzi 5, ambazo hutupwa haraka sana, baada ya. ambayo ufuatiliaji unaacha kufanya kazi kwa usahihi.
Ninachotaka kusema kwa kumalizia: tulifanya hivyo! Tuliweza kuwapa waandaaji programu na watengenezaji wetu zana ambayo, karibu na hali yoyote, inaweza kutoa taarifa kwa haraka na kwa uhakika kuhusu kile kinachotokea katika uzalishaji.
Ndio, iligeuka kuwa ngumu sana, lakini, hata hivyo, tuliweza kutoshea matakwa yetu katika bidhaa zilizopo, ambazo hatukulazimika kuziweka na kujiandikia tena.
Chanzo: mapenzi.com