Daudzi cilvÄki cÄ«nÄs ar Elasticsearch. Bet kas notiek, ja vÄlaties to izmantot žurnÄlu glabÄÅ”anai āÄ«paÅ”i lielÄ apjomÄā? Un vai ir arÄ« nesÄpÄ«gi piedzÄ«vot kļūmi kÄdÄ no vairÄkiem datu centriem? KÄdu arhitektÅ«ru vajadzÄtu veidot, un uz kÄdÄm kļūmÄm jÅ«s paklupsiet?
MÄs, Odnoklassniki, nolÄmÄm izmantot elasticsearch, lai atrisinÄtu baļķu pÄrvaldÄ«bas problÄmu, un tagad mÄs dalÄmies pieredzÄ ar Habr: gan par arhitektÅ«ru, gan par nepilnÄ«bÄm.
Esmu Pjotrs Zaicevs, strÄdÄju par sistÄmas administratoru uzÅÄmumÄ Odnoklassniki. Pirms tam biju arÄ« admins, strÄdÄju ar Manticore Search, Sphinx search, Elasticsearch. IespÄjams, ja parÄdÄ«sies vÄl viens ...meklÄjums, iespÄjams, arÄ« es ar to strÄdÄÅ”u. Es arÄ« brÄ«vprÄtÄ«gi piedalos vairÄkos atvÄrtÄ pirmkoda projektos.
Kad ierados Odnoklassniki, intervijÄ neapdomÄ«gi teicu, ka varÄtu strÄdÄt ar Elasticsearch. PÄc tam, kad es to sapratu un izpildÄ«ju dažus vienkÄrÅ”us uzdevumus, man tika dots lielais uzdevums reformÄt tajÄ laikÄ pastÄvoÅ”o žurnÄlu pÄrvaldÄ«bas sistÄmu.
Prasības
SistÄmas prasÄ«bas tika formulÄtas Å”Ädi:
- Graylog bija paredzÄts izmantot kÄ priekÅ”galu. TÄ kÄ uzÅÄmumam jau bija Ŕī produkta lietoÅ”anas pieredze, programmÄtÄji un testÄtÄji to zinÄja, viÅiem tas bija pazÄ«stams un Ärts.
- Datu apjoms: vidÄji 50-80 tÅ«kstoÅ”i ziÅojumu sekundÄ, bet ja kaut kas saplÄ«st, tad trafiku nekas neierobežo, var bÅ«t 2-3 miljoni rindu sekundÄ
- PÄrrunÄjot ar klientiem prasÄ«bas meklÄÅ”anas vaicÄjumu apstrÄdes Ätrumam, mÄs sapratÄm, ka tipisks Å”Ädas sistÄmas izmantoÅ”anas modelis ir Å”Äds: cilvÄki meklÄ savas lietojumprogrammas žurnÄlus pÄdÄjo divu dienu laikÄ un nevÄlas gaidÄ«t ilgÄk par vienu otrais formulÄta vaicÄjuma rezultÄtam.
- Administratori uzstÄja, ka sistÄma ir viegli mÄrogojama, ja nepiecieÅ”ams, neprasot viÅiem dziļi iedziļinÄties tÄs darbÄ«bÄ.
- TÄ ka vienÄ«gais apkopes uzdevums, kas Ŕīm sistÄmÄm periodiski nepiecieÅ”ams, ir aparatÅ«ras maiÅa.
- TurklÄt Odnoklassniki ir lieliskas tehniskÄs tradÄ«cijas: jebkuram pakalpojumam, ko mÄs palaižam, ir jÄpÄrdzÄ«vo datu centra kļūme (pÄkÅ”Åa, neplÄnota un absolÅ«ti jebkurÄ laikÄ).
VisvairÄk mums izmaksÄja pÄdÄjÄ prasÄ«ba Ŕī projekta realizÄcijÄ, par ko pastÄstÄ«Å”u sÄ«kÄk.
treŔdiena
MÄs strÄdÄjam Äetros datu centros, savukÄrt Elasticsearch datu mezgli var atrasties tikai trijos (vairÄku netehnisku iemeslu dÄļ).
Å ajos Äetros datu centros ir aptuveni 18 tÅ«kstoÅ”i dažÄdu žurnÄlu avotu ā aparatÅ«ras, konteineri, virtuÄlÄs maŔīnas.
SvarÄ«ga iezÄ«me: klasteris sÄkas konteineros nevis uz fiziskÄm maŔīnÄm, bet gan uz . Konteineriem tiek garantÄti 2 kodoli, lÄ«dzÄ«gi kÄ 2.0 GHz v4, ar iespÄju atlikuÅ”os kodolus pÄrstrÄdÄt, ja tie ir dÄ«kstÄvÄ.
Citiem vÄrdiem sakot:
Topoloģija
SÄkotnÄji es redzÄju risinÄjuma vispÄrÄjo formu Å”Ädi:
- 3-4 VIP atrodas aiz Graylog domÄna A ieraksta, Ŕī ir adrese, uz kuru tiek nosÅ«tÄ«ti žurnÄli.
- katrs VIP ir LVS balansÄtÄjs.
- PÄc tam žurnÄli nonÄk Graylog akumulatorÄ, daži dati ir GELF formÄtÄ, daži syslog formÄtÄ.
- Tad tas viss lielÄs partijÄs tiek rakstÄ«ts Elasticsearch koordinatoru baterijai.
- Un tie, savukÄrt, nosÅ«ta rakstÄ«Å”anas un lasÄ«Å”anas pieprasÄ«jumus attiecÄ«gajiem datu mezgliem.
VÄrdu krÄjums
VarbÅ«t ne visi saprot terminoloÄ£iju detalizÄti, tÄpÄc es vÄlÄtos nedaudz pakavÄties pie tÄ.
Elasticsearch ir vairÄku veidu mezgli - galvenais, koordinators, datu mezgls. Ir divi citi veidi dažÄdÄm žurnÄlu transformÄcijÄm un saziÅai starp dažÄdÄm kopÄm, taÄu mÄs izmantojÄm tikai uzskaitÄ«tos.
Meistars
Tas nosÅ«ta ping visiem klasterÄ« esoÅ”ajiem mezgliem, uztur atjauninÄtu klasteru karti un izplata to starp mezgliem, apstrÄdÄ notikumu loÄ£iku un veic dažÄda veida klastera mÄroga uzkopÅ”anu.
Koordinators
Veic tikai vienu uzdevumu: pieÅem lasÄ«Å”anas vai rakstÄ«Å”anas pieprasÄ«jumus no klientiem un marÅ”rutÄ Å”o trafiku. Ja ir rakstÄ«Å”anas pieprasÄ«jums, visticamÄk, tas jautÄs kapteinim, kurÄ attiecÄ«gÄ indeksa fragmentÄ tas jÄievieto, un novirzÄ«s pieprasÄ«jumu tÄlÄk.
Datu mezgls
UzglabÄ datus, veic no Ärpuses ienÄkoÅ”us meklÄÅ”anas vaicÄjumus un veic darbÄ«bas ar uz tiem esoÅ”ajÄm lauskas.
Greylog
Tas ir kaut kas lÄ«dzÄ«gs Kibana saplÅ«Å”anai ar Logstash ELK kaudzÄ. Graylog apvieno gan lietotÄja saskarni, gan žurnÄlu apstrÄdes cauruļvadu. Zem pÄrsega Graylog darbojas Kafka un Zookeeper, kas nodroÅ”ina savienojumu ar Graylog kÄ kopu. Graylog var saglabÄt žurnÄlus (Kafka) keÅ”atmiÅÄ, ja Elasticsearch nav pieejams, un atkÄrtot neveiksmÄ«gus lasÄ«Å”anas un rakstÄ«Å”anas pieprasÄ«jumus, grupÄt un atzÄ«mÄt žurnÄlus saskaÅÄ ar noteiktiem noteikumiem. TÄpat kÄ Logstash, Graylog ir funkcionalitÄte, lai mainÄ«tu rindas pirms to rakstÄ«Å”anas Elasticsearch.
TurklÄt Graylog ir iebÅ«vÄts pakalpojumu atklÄjums, kas ļauj, pamatojoties uz vienu pieejamo Elasticsearch mezglu, iegÅ«t visu klastera karti un filtrÄt to pÄc noteikta taga, kas ļauj novirzÄ«t pieprasÄ«jumus uz konkrÄtiem konteineriem.
VizuÄli tas izskatÄs apmÄram Å”Ädi:
Å is ir ekrÄnuzÅÄmums no konkrÄta gadÄ«juma. Å eit mÄs izveidojam histogrammu, pamatojoties uz meklÄÅ”anas vaicÄjumu, un parÄdÄm atbilstoÅ”Äs rindas.
Indeksi
Atgriežoties pie sistÄmas arhitektÅ«ras, es vÄlos sÄ«kÄk pakavÄties pie tÄ, kÄ mÄs izveidojÄm indeksa modeli, lai tas viss darbotos pareizi.
IepriekÅ” redzamajÄ diagrammÄ tas ir zemÄkais lÄ«menis: Elasticsearch datu mezgli.
Indekss ir liela virtuÄla vienÄ«ba, kas sastÄv no Elasticsearch skaidiÅÄm. Pats par sevi katra no lauskas ir nekas vairÄk kÄ Lucene indekss. Un katrs Lucene indekss, savukÄrt, sastÄv no viena vai vairÄkiem segmentiem.
IzstrÄdÄjot, mÄs sapratÄm, ka, lai izpildÄ«tu prasÄ«bas par lasÄ«Å”anas Ätrumu lielam datu apjomam, mums Å”ie dati ir vienmÄrÄ«gi "jÄizplata" pa datu mezgliem.
TÄ rezultÄtÄ fragmentu skaitam vienÄ indeksÄ (ar replikÄm) jÄbÅ«t stingri vienÄdam ar datu mezglu skaitu. PirmkÄrt, lai nodroÅ”inÄtu replikÄcijas koeficientu, kas vienÄds ar diviem (tas ir, mÄs varam zaudÄt pusi no klastera). Un, otrkÄrt, lai apstrÄdÄtu lasÄ«Å”anas un rakstÄ«Å”anas pieprasÄ«jumus vismaz pusÄ klastera.
Vispirms mÄs noteicÄm glabÄÅ”anas laiku kÄ 30 dienas.
Skaldu sadalÄ«jumu grafiski var attÄlot Å”Ädi:
Viss tumÅ”i pelÄkais taisnstÅ«ris ir rÄdÄ«tÄjs. Kreisais sarkanais kvadrÄts tajÄ ir primÄrais shards, pirmais rÄdÄ«tÄjÄ. Un zilais kvadrÄts ir kopijas lauskas. Tie atrodas dažÄdos datu centros.
Kad mÄs pievienojam vÄl vienu Ŕķembu, tÄ nonÄk treÅ”ajÄ datu centrÄ. Un galu galÄ mÄs iegÅ«stam Å”o struktÅ«ru, kas ļauj zaudÄt lÄ«dzstrÄvu, nezaudÄjot datu konsekvenci:
Indeksu rotÄcija, t.i. izveidojot jaunu indeksu un dzÄÅ”ot vecÄko, mÄs to pielÄ«dzinÄjÄm 48 stundÄm (pÄc indeksa izmantoÅ”anas modeļa: visbiežÄk tiek meklÄtas pÄdÄjÄs 48 stundas).
Å is indeksa rotÄcijas intervÄls ir saistÄ«ts ar Å”Ädiem iemesliem:
Kad meklÄÅ”anas pieprasÄ«jums nonÄk noteiktÄ datu mezglÄ, tad no veiktspÄjas viedokļa ir izdevÄ«gÄk, ja tiek vaicÄts viens shards, ja tÄ izmÄrs ir salÄ«dzinÄms ar mezgla gūžas izmÄru. Tas ļauj saglabÄt ākarstoā indeksa daļu kaudzÄ un Ätri tai piekļūt. Ja ir daudz ākarstu daļuā, indeksa meklÄÅ”anas Ätrums samazinÄs.
Kad mezgls sÄk izpildÄ«t meklÄÅ”anas vaicÄjumu vienÄ fragmentÄ, tas pieŔķir pavedienu skaitu, kas ir vienÄds ar fiziskÄs maŔīnas hiperpavedienu kodolu skaitu. Ja meklÄÅ”anas vaicÄjums ietekmÄ lielu skaitu shardu, pavedienu skaits palielinÄs proporcionÄli. Tas negatÄ«vi ietekmÄ meklÄÅ”anas Ätrumu un negatÄ«vi ietekmÄ jaunu datu indeksÄÅ”anu.
Lai nodroÅ”inÄtu nepiecieÅ”amo meklÄÅ”anas latentumu, mÄs nolÄmÄm izmantot SSD. Lai Ätri apstrÄdÄtu pieprasÄ«jumus, iekÄrtÄm, kurÄs tika mitinÄti Å”ie konteineri, bija jÄbÅ«t vismaz 56 kodoliem. Skaitlis 56 tika izvÄlÄts kÄ nosacÄ«ti pietiekama vÄrtÄ«ba, kas nosaka pavedienu skaitu, ko Elasticsearch Ä£enerÄs darbÄ«bas laikÄ. ProgrammÄ Elasitcsearch daudzi pavedienu kopas parametri ir tieÅ”i atkarÄ«gi no pieejamo kodolu skaita, kas savukÄrt tieÅ”i ietekmÄ nepiecieÅ”amo mezglu skaitu klasterÄ« saskaÅÄ ar principu āmazÄk kodolu - vairÄk mezgluā.
RezultÄtÄ mÄs noskaidrojÄm, ka vidÄji shards sver aptuveni 20 gigabaitus, un vienÄ rÄdÄ«tÄjÄ ir 1 shards. AttiecÄ«gi, ja mÄs tos pagriežam reizi 360 stundÄs, tad mums ir 48 no tiem. Katrs rÄdÄ«tÄjs satur datus par 15 dienÄm.
Datu rakstÄ«Å”anas un nolasÄ«Å”anas shÄmas
IzdomÄsim, kÄ dati tiek ierakstÄ«ti Å”ajÄ sistÄmÄ.
PieÅemsim, ka kÄds pieprasÄ«jums no Greylog pienÄk koordinatoram. PiemÄram, mÄs vÄlamies indeksÄt 2-3 tÅ«kstoÅ”us rindu.
Koordinators, saÅÄmis pieprasÄ«jumu no Graylog, iztaujÄ meistaru: "IndeksÄÅ”anas pieprasÄ«jumÄ mÄs Ä«paÅ”i norÄdÄ«jÄm indeksu, bet nebija norÄdÄ«ts, kurÄ fragmentÄ tas jÄraksta."
Meistars atbild: āUzrakstiet Å”o informÄciju uz sharda numuru 71ā, pÄc tam tÄ tiek nosÅ«tÄ«ta tieÅ”i uz attiecÄ«go datu mezglu, kur atrodas primÄrÄ sharda numurs 71.
PÄc tam darÄ«jumu žurnÄls tiek pavairots reprodukcijas fragmentÄ, kas atrodas citÄ datu centrÄ.
No Graylog koordinatoram tiek saÅemts meklÄÅ”anas pieprasÄ«jums. Koordinators to novirza atbilstoÅ”i indeksam, savukÄrt Elasticsearch izplata pieprasÄ«jumus starp primÄro un reprodukcijas fragmentu, izmantojot apļa-robin principu.
180 mezgli reaÄ£Ä nevienmÄrÄ«gi, un, kamÄr tie reaÄ£Ä, koordinators uzkrÄj informÄciju, kuru jau ir āizspļÄvuÅ”iā ÄtrÄki datu mezgli. PÄc tam, kad vai nu ir saÅemta visa informÄcija, vai pieprasÄ«jums ir sasniedzis taimautu, tas visu nodod tieÅ”i klientam.
Visa Ŕī sistÄma vidÄji apstrÄdÄ meklÄÅ”anas vaicÄjumus pÄdÄjo 48 stundu laikÄ 300ā400 ms, izÅemot tos vaicÄjumus, kuriem ir vadoÅ”Ä aizstÄjÄjzÄ«me.
Ziedi ar Elasticsearch: Java iestatīŔana
Lai tas viss darbotos tÄ, kÄ mÄs sÄkotnÄji vÄlÄjÄmies, mÄs pavadÄ«jÄm ļoti ilgu laiku, lai atkļūdotu dažÄdas lietas klasterÄ«.
PirmÄ atklÄto problÄmu daļa bija saistÄ«ta ar veidu, kÄ Java pÄc noklusÄjuma ir iepriekÅ” konfigurÄta programmÄ Elasticsearch.
Viena problÄma
MÄs esam redzÄjuÅ”i ļoti daudzus ziÅojumus, ka Lucene lÄ«menÄ«, kad darbojas fona darbi, Lucene segmentu sapludinÄÅ”ana neizdodas un rodas kļūda. TajÄ paÅ”Ä laikÄ Å¾urnÄlos bija skaidrs, ka tÄ ir OutOfMemoryError kļūda. MÄs redzÄjÄm no telemetrijas, ka gūža ir brÄ«va, un nebija skaidrs, kÄpÄc Ŕī operÄcija neizdevÄs.
IzrÄdÄ«jÄs, ka Lucene indeksu saplÅ«Å”ana notiek Ärpus gūžas. Un konteineri ir diezgan stingri ierobežoti patÄrÄto resursu ziÅÄ. Å ajos resursos varÄja ietilpt tikai kaudze (vÄrtÄ«ba heap.size bija aptuveni vienÄda ar RAM), un dažas Ärpus kaudzes darbÄ«bas avarÄja ar atmiÅas pieŔķirÅ”anas kļūdu, ja kÄda iemesla dÄļ tÄs neietilpa ~500 MB, kas palika pirms ierobežojuma.
Labojums bija diezgan triviÄls: tika palielinÄts konteineram pieejamÄs RAM apjoms, pÄc kura mÄs aizmirsÄm, ka mums pat bija Å”Ädas problÄmas.
OtrÄ problÄma
4-5 dienas pÄc klastera palaiÅ”anas mÄs pamanÄ«jÄm, ka datu mezgli periodiski sÄka izkrist no klastera un iekļūt tajÄ pÄc 10-20 sekundÄm.
Kad mÄs sÄkÄm to izdomÄt, izrÄdÄ«jÄs, ka Ŕī Elasticsearch atmiÅa netiek kontrolÄta nekÄdÄ veidÄ. Kad konteineram pieŔķīrÄm vairÄk atmiÅas, mÄs varÄjÄm aizpildÄ«t tieÅ”os buferu baseinus ar dažÄdu informÄciju, un tas tika notÄ«rÄ«ts tikai pÄc tam, kad no Elasticsearch tika palaists skaidrais GC.
Dažos gadÄ«jumos Ŕī darbÄ«ba prasÄ«ja diezgan ilgu laiku, un Å”ajÄ laikÄ klasterim izdevÄs atzÄ«mÄt Å”o mezglu kÄ jau izietu. Å Ä« problÄma ir labi aprakstÄ«ta .
RisinÄjums bija Å”Äds: mÄs ierobežojÄm Java iespÄju Ŕīm darbÄ«bÄm izmantot lielÄko daļu atmiÅas Ärpus kaudzes. MÄs ierobežojÄm to lÄ«dz 16 gigabaitiem (-XX:MaxDirectMemorySize=16g), nodroÅ”inot, ka tieÅ”ais GC tiek izsaukts daudz biežÄk un apstrÄdÄts daudz ÄtrÄk, tÄdÄjÄdi vairs nedestabilizÄjot kopu.
TreÅ”Ä problÄma
Ja domÄjat, ka problÄmas ar āmezgliem, kas atstÄj klasteru visnegaidÄ«tÄkajÄ brÄ«dÄ«ā ir beiguÅ”ies, jÅ«s maldÄties.
Kad mÄs konfigurÄjÄm darbu ar indeksiem, mÄs izvÄlÄjÄmies mmapfs to uz svaigÄm skaidÄm ar lielu segmentÄciju. Å Ä« bija diezgan liela kļūda, jo, izmantojot mmapfs, fails tiek kartÄts RAM, un tad mÄs strÄdÄjam ar kartÄto failu. SakarÄ ar to izrÄdÄs, ka tad, kad GC mÄÄ£ina apturÄt pavedienus lietojumprogrammÄ, mÄs ļoti ilgu laiku dodamies uz droÅ”u punktu, un ceÄ¼Ä uz to aplikÄcija pÄrstÄj atbildÄt uz meistara pieprasÄ«jumiem par to, vai tÄ ir dzÄ«va. . AttiecÄ«gi kapteinis uzskata, ka mezgls vairs neatrodas klasterÄ«. PÄc tam, pÄc 5-10 sekundÄm, darbojas atkritumu savÄcÄjs, mezgls atdzÄ«vojas, atkal nonÄk klasterÄ« un sÄk inicializÄt lauskas. Tas viss ļoti Ŕķita kÄ "iestudÄjums, kuru mÄs pelnÄ«jÄm" un nebija piemÄrots nekam nopietnam.
Lai atbrÄ«votos no Ŕīs uzvedÄ«bas, mÄs vispirms pÄrgÄjÄm uz standarta niofs, un pÄc tam, kad mÄs migrÄjÄm no piektÄs Elastic versijas uz sesto, mÄs izmÄÄ£inÄjÄm hibrÄ«dus, kur Ŕī problÄma netika atkÄrtota. Varat lasÄ«t vairÄk par uzglabÄÅ”anas veidiem .
CeturtÄ problÄma
Tad radÄs vÄl viena ļoti interesanta problÄma, kuru mÄs risinÄjÄm rekordÄ«su laiku. MÄs to Ä·ÄrÄm 2-3 mÄneÅ”us, jo tÄ raksts bija absolÅ«ti nesaprotams.
Dažreiz mÅ«su koordinatori devÄs uz Full GC, parasti kaut kad pÄc pusdienÄm, un nekad no turienes neatgriezÄs. TajÄ paÅ”Ä laikÄ, reÄ£istrÄjot GC aizkavi, tas izskatÄ«jÄs Å”Ädi: viss notiek labi, labi, labi, un tad pÄkÅ”Åi viss iet ļoti slikti.
SÄkumÄ domÄjÄm, ka mums ir ļauns lietotÄjs, kurÅ” palaida kaut kÄdu pieprasÄ«jumu, kas izsita koordinatoru no darba režīma. MÄs ļoti ilgu laiku reÄ£istrÄjÄm pieprasÄ«jumus, mÄÄ£inot saprast, kas notiek.
RezultÄtÄ izrÄdÄ«jÄs, ka brÄ«dÄ«, kad lietotÄjs palaiž milzÄ«gu pieprasÄ«jumu un tas nonÄk pie konkrÄta Elasticsearch koordinatora, daži mezgli reaÄ£Ä ilgÄk nekÄ citi.
Un, kamÄr koordinators gaida atbildi no visiem mezgliem, viÅÅ” uzkrÄj rezultÄtus, kas nosÅ«tÄ«ti no mezgliem, kuri jau ir atbildÄjuÅ”i. AttiecÄ«bÄ uz GC tas nozÄ«mÄ, ka mÅ«su kaudzes izmantoÅ”anas modeļi mainÄs ļoti Ätri. Un mÅ«su izmantotais GC nevarÄja tikt galÄ ar Å”o uzdevumu.
VienÄ«gais labojums, ko atradÄm, lai mainÄ«tu klastera darbÄ«bu Å”ajÄ situÄcijÄ, ir migrÄcija uz JDK13 un Shenandoah atkritumu savÄcÄja izmantoÅ”ana. Tas atrisinÄja problÄmu, mÅ«su koordinatori pÄrstÄja krist.
Å eit beidzÄs problÄmas ar Java un sÄkÄs joslas platuma problÄmas.
"Ogas" ar Elasticsearch: caurlaidspÄja
ProblÄmas ar caurlaidspÄju nozÄ«mÄ, ka mÅ«su klasteris darbojas stabili, bet indeksÄto dokumentu skaita maksimuma un manevru laikÄ veiktspÄja ir nepietiekama.
Pirmais konstatÄtais simptoms: dažu ražoÅ”anas āsprÄdzienuā laikÄ, kad pÄkÅ”Åi tiek Ä£enerÄts ļoti liels skaits žurnÄlu, Graylog sÄk bieži mirgot indeksÄÅ”anas kļūda es_rejected_execution.
Tas bija saistÄ«ts ar faktu, ka thread_pool.write.queue vienÄ datu mezglÄ lÄ«dz brÄ«dim, kad Elasticsearch spÄj apstrÄdÄt indeksÄÅ”anas pieprasÄ«jumu un augÅ”upielÄdÄt informÄciju diskÄ esoÅ”ajÄ shardÄ, pÄc noklusÄjuma spÄj keÅ”atmiÅÄ saglabÄt tikai 200 pieprasÄ«jumus. Un iekÅ”Ä Par Å”o parametru tiek runÄts ļoti maz. Tiek norÄdÄ«ts tikai maksimÄlais pavedienu skaits un noklusÄjuma izmÄrs.
Protams, mÄs devÄmies sagrozÄ«t Å”o vÄrtÄ«bu un uzzinÄjÄm sekojoÅ”o: konkrÄti mÅ«su iestatÄ«jumos lÄ«dz 300 pieprasÄ«jumiem keÅ”atmiÅÄ ir diezgan labi, un lielÄka vÄrtÄ«ba ir saistÄ«ta ar faktu, ka mÄs atkal lidojam uz Full GC.
TurklÄt, tÄ kÄ Å”Ä«s ir ziÅojumu paketes, kas tiek saÅemtas viena pieprasÄ«juma ietvaros, bija nepiecieÅ”ams pielÄgot Graylog, lai tas nerakstÄ«tu bieži un mazÄs partijÄs, bet gan lielÄs partijÄs vai reizi 3 sekundÄs, ja partija joprojÄm nav pabeigta. Å ajÄ gadÄ«jumÄ izrÄdÄs, ka informÄcija, ko mÄs ierakstÄm Elasticsearch, kļūst pieejama nevis pÄc divÄm sekundÄm, bet pÄc piecÄm (kas mums der diezgan labi), bet gan pÄrkÄrtojumu skaits, kas jÄveic, lai izspiestu lielu tiek samazinÄta informÄcijas kaudze.
ÄŖpaÅ”i svarÄ«gi tas ir tajos brīžos, kad kaut kur kaut kas nobružÄjies un nikni par to ziÅo, lai nedabÅ«tu galÄ«gi spamotu Elastic, bet pÄc kÄda laika - Greylog mezglus, kas nedarbojas aizsÄrÄjuÅ”o buferu dÄļ.
TurklÄt, kad mums bija Å”ie paÅ”i sprÄdzieni ražoÅ”anÄ, mÄs saÅÄmÄm sÅ«dzÄ«bas no programmÄtÄjiem un testÄtÄjiem: brÄ«dÄ«, kad viÅiem patieÅ”Äm vajadzÄja Å”os baļķus, viÅiem tos iedeva ļoti lÄni.
ViÅi sÄka to izdomÄt. No vienas puses, bija skaidrs, ka gan meklÄÅ”anas vaicÄjumi, gan indeksÄÅ”anas vaicÄjumi bÅ«tÄ«bÄ tika apstrÄdÄti vienÄs un tajÄs paÅ”Äs fiziskajÄs iekÄrtÄs, un tÄ vai citÄdi bÅ«s zinÄmi trÅ«kumi.
TaÄu to var daļÄji apiet tÄdÄļ, ka sestajÄ Elasticsearch versijÄ parÄdÄ«jÄs algoritms, kas ļauj izplatÄ«t vaicÄjumus starp attiecÄ«gajiem datu mezgliem, nevis pÄc nejauŔības principa āround-robinā (konteiners, kas veic indeksÄÅ”anu un satur primÄro shard var bÅ«t ļoti aizÅemts, nebÅ«s iespÄjas Ätri atbildÄt), bet pÄrsÅ«tÄ«t Å”o pieprasÄ«jumu uz mazÄk ielÄdÄtu konteineru ar replika-shard, kas atbildÄs daudz ÄtrÄk. Citiem vÄrdiem sakot, mÄs nonÄcÄm pie use_adaptive_replica_selection: true.
LasÄ«Å”anas attÄls sÄk izskatÄ«ties Å”Ädi:
PÄreja uz Å”o algoritmu ļÄva bÅ«tiski uzlabot vaicÄjuma laiku tajos brīžos, kad mums bija jÄraksta liela žurnÄlu plÅ«sma.
Visbeidzot, galvenÄ problÄma bija nesÄpÄ«ga datu centra noÅemÅ”ana.
Ko mÄs vÄlÄjÄmies no klastera tÅ«lÄ«t pÄc savienojuma zaudÄÅ”anas ar vienu DC:
- Ja mums ir paÅ”reizÄjais galvenais galvenais datu centrs, tas tiks atkÄrtoti atlasÄ«ts un pÄrvietots kÄ loma uz citu mezglu citÄ DC.
- Kapteinis Ätri noÅems no klastera visus nepieejamos mezglus.
- Pamatojoties uz atlikuÅ”ajiem, viÅÅ” sapratÄ«s: pazaudÄtajÄ datu centrÄ mums bija Å”Ädas tÄdas primÄrÄs lauskas, atlikuÅ”ajos datu centros viÅÅ” Ätri virzÄ«s papildu replikas, un mÄs turpinÄsim indeksÄt datus.
- TÄ rezultÄtÄ klastera rakstÄ«Å”anas un lasÄ«Å”anas caurlaidspÄja pakÄpeniski pasliktinÄsies, taÄu kopumÄ viss darbosies, lai arÄ« lÄni, bet stabili.
KÄ izrÄdÄ«jÄs, mÄs vÄlÄjÄmies kaut ko lÄ«dzÄ«gu:
Un mÄs saÅÄmÄm sekojoÅ”o:
KÄ tas notika?
Kad datu centrs nokrita, mÅ«su meistars kļuva par vÄjo kaklu.
KÄpÄc?
Fakts ir tÄds, ka meistaram ir TaskBatcher, kas ir atbildÄ«gs par noteiktu uzdevumu un notikumu izplatÄ«Å”anu klasterÄ«. Jebkura mezgla izeja, jebkura fragmenta paaugstinÄÅ”ana no replikas uz primÄro, jebkurÅ” uzdevums, lai kaut kur izveidotu fragmentu ā tas viss vispirms tiek nosÅ«tÄ«ts uz TaskBatcher, kur tas tiek apstrÄdÄts secÄ«gi un vienÄ pavedienÄ.
Viena datu centra izÅemÅ”anas brÄ«dÄ« izrÄdÄ«jÄs, ka visi saglabÄjuÅ”os datu centru datu mezgli uzskatÄ«ja par savu pienÄkumu informÄt meistaru "mÄs esam pazaudÄjuÅ”i tÄdas un tÄdas lauskas un tÄdus un tÄdus datu mezglus."
TajÄ paÅ”Ä laikÄ izdzÄ«vojuÅ”ie datu mezgli nosÅ«tÄ«ja visu Å”o informÄciju paÅ”reizÄjam kapteinim un mÄÄ£inÄja gaidÄ«t apstiprinÄjumu, ka viÅÅ” to pieÅÄma. ViÅi to negaidÄ«ja, jo meistars uzdevumus saÅÄma ÄtrÄk, nekÄ spÄja atbildÄt. Mezglu atkÄrtotu pieprasÄ«jumu noildze beidzÄs, un kapteinis Å”ajÄ laikÄ pat nemÄÄ£inÄja uz tiem atbildÄt, bet bija pilnÄ«bÄ iesaistÄ«ts uzdevumÄ kÄrtot pieprasÄ«jumus pÄc prioritÄtes.
TerminÄļa formÄ izrÄdÄ«jÄs, ka datu mezgli nosÅ«tÄ«ja galveno sÅ«tÄ«jumu tiktÄl, ka tas pÄrgÄja pilnÄ GC. PÄc tam mÅ«su galvenÄ loma pÄrcÄlÄs uz kÄdu nÄkamo mezglu, ar to notika pilnÄ«gi tas pats, un rezultÄtÄ klasteris pilnÄ«bÄ sabruka.
MÄs veicÄm mÄrÄ«jumus, un pirms versijas 6.4.0, kur tas tika labots, mums pietika ar to, ka vienlaikus izvadÄ«jÄm tikai 10 datu mezglus no 360, lai pilnÄ«bÄ izslÄgtu klasteru.
Tas izskatÄ«jÄs apmÄram Å”Ädi:
PÄc versijas 6.4.0, kurÄ tika novÄrsta Ŕī briesmÄ«gÄ kļūda, datu mezgli pÄrtrauca nogalinÄt galveno. Bet tas viÅu nepadarÄ«ja "gudrÄku". Proti: kad mÄs izvadÄm 2, 3 vai 10 (jebkuru skaitu, izÅemot vienu) datu mezglus, kapteinis saÅem pirmo ziÅojumu, kas saka, ka mezgls A ir aizgÄjis, un mÄÄ£ina pastÄstÄ«t mezglam B, mezglam C par to, mezglam D.
Un Å”obrÄ«d to var atrisinÄt, tikai iestatot taimautu mÄÄ£inÄjumiem kÄdam par kaut ko pastÄstÄ«t, kas vienÄds ar aptuveni 20-30 sekundÄm un tÄdÄjÄdi kontrolÄjot datu centra pÄrvietoÅ”anÄs Ätrumu no klastera.
PrincipÄ tas iekļaujas prasÄ«bÄs, kas sÄkotnÄji tika izvirzÄ«tas gala produktam projekta ietvaros, taÄu no ātÄ«rÄs zinÄtnesā viedokļa tÄ ir kļūda. Ko, starp citu, izstrÄdÄtÄji veiksmÄ«gi salaboja versijÄ 7.2.
TurklÄt, kad kÄds datu mezgls nodzisa, izrÄdÄ«jÄs, ka informÄcijas izplatÄ«Å”ana par tÄ izieÅ”anu bija svarÄ«gÄka nekÄ stÄstÄ«t visam klasterim, ka tajÄ ir Å”Ädas un tÄdas primÄrÄs shards (lai veicinÄtu replikas fragmentu citos datos centrÄ primÄrajÄ, un uz tiem varÄtu rakstÄ«t informÄciju).
TÄpÄc, kad viss jau ir apstÄjies, atbrÄ«votie datu mezgli netiek uzreiz atzÄ«mÄti kÄ novecojuÅ”i. AttiecÄ«gi mÄs esam spiesti gaidÄ«t, kamÄr visi ping ir beidzies uz atbrÄ«votajiem datu mezgliem, un tikai pÄc tam mÅ«su klasteris sÄk mums pateikt, ka tur, tur un tur mums ir jÄturpina ierakstÄ«t informÄciju. JÅ«s varat lasÄ«t vairÄk par Å”o .
RezultÄtÄ datu centra izÅemÅ”anas operÄcija mÅ«sdienÄs aizÅem apmÄram 5 minÅ«tes sastrÄgumstundÄ. Tik lielam un neveiklam kolosam tas ir diezgan labs rezultÄts.
RezultÄtÄ mÄs nonÄcÄm pie Å”Äda lÄmuma:
- Mums ir 360 datu mezgli ar 700 gigabaitu diskiem.
- 60 koordinatori trafika marÅ”rutÄÅ”anai caur Å”iem paÅ”iem datu mezgliem.
- 40 meistari, kurus esam atstÄjuÅ”i kÄ sava veida mantojumu kopÅ” versijÄm pirms 6.4.0 - lai pÄrdzÄ«votu datu centra izÅemÅ”anu, bijÄm garÄ«gi gatavi zaudÄt vairÄkas maŔīnas, lai bÅ«tu garantÄts meistaru kvorums pat gadÄ. sliktÄkais scenÄrijs
- JebkurÅ” mÄÄ£inÄjums apvienot lomas vienÄ konteinerÄ tika apmierinÄts ar faktu, ka agrÄk vai vÄlÄk mezgls slodzes laikÄ saplÄ«sÄ«s.
- VisÄ klasterÄ« tiek izmantots 31 gigabaita lielums heap.size: visi mÄÄ£inÄjumi samazinÄt izmÄru izraisÄ«ja dažu mezglu iznÄ«cinÄÅ”anu smagos meklÄÅ”anas vaicÄjumos, izmantojot vadoÅ”o aizstÄjÄjzÄ«mi, vai arÄ« paÅ”a Elasticsearch Ä·Ädes pÄrtraucÄju.
- TurklÄt, lai nodroÅ”inÄtu meklÄÅ”anas veiktspÄju, mÄs centÄmies saglabÄt pÄc iespÄjas mazÄku objektu skaitu klasterÄ«, lai apstrÄdÄtu pÄc iespÄjas mazÄk notikumu saÅ”aurinÄtajÄ kaklÄ, ko ieguvÄm galvenajÄ.
Visbeidzot par uzraudzību
Lai nodroÅ”inÄtu, ka tas viss darbojas, kÄ paredzÄts, mÄs uzraugÄm sekojoÅ”o:
- Katrs datu mezgls ziÅo mÅ«su mÄkonim, ka tas eksistÄ, un uz tÄ ir tÄdas un tÄdas lauskas. Kad kaut kur kaut ko dzÄÅ”am, klasteris pÄc 2-3 sekundÄm ziÅo, ka centrÄ A esam dzÄsuÅ”i mezglus 2, 3 un 4 - tas nozÄ«mÄ, ka citos datu centros mÄs nekÄdÄ gadÄ«jumÄ nevaram nodzÄst tos mezglus, uz kuriem ir tikai viena lauskas. pa kreisi.
- Zinot meistara uzvedÄ«bas bÅ«tÄ«bu, mÄs ļoti rÅ«pÄ«gi aplÅ«kojam nepabeigto uzdevumu skaitu. Jo pat viens iestrÄdzis uzdevums, ja tas laicÄ«gi nebeidzas, teorÄtiski kÄdÄ ÄrkÄrtas situÄcijÄ var kļūt par iemeslu, kÄdÄļ, piemÄram, replikas Ŕķembas reklamÄÅ”ana primÄrajÄ nedarbojas, kÄdÄļ indeksÄÅ”ana pÄrstÄs darboties.
- MÄs arÄ« ļoti rÅ«pÄ«gi skatÄmies uz atkritumu savÄcÄju aizkavÄÅ”anos, jo mums jau ir bijuÅ”as lielas grÅ«tÄ«bas optimizÄcijas laikÄ.
- Noraida pÄc pavediena, lai jau iepriekÅ” saprastu, kur ir saÅ”aurinÄjums.
- Nu, standarta metrika, piemÄram, kaudze, RAM un I/O.
Veidojot uzraudzÄ«bu, jÄÅem vÄrÄ Elasticsearch Thread Pool funkcijas. apraksta konfigurÄcijas opcijas un noklusÄjuma vÄrtÄ«bas meklÄÅ”anai un indeksÄÅ”anai, bet pilnÄ«bÄ klusÄ par thread_pool.management. Å ie pavedieni Ä«paÅ”i apstrÄdÄ vaicÄjumus, piemÄram, _cat/shards un citus lÄ«dzÄ«gus, kurus ir Ärti izmantot, rakstot monitoringu. Jo lielÄks ir klasteris, jo vairÄk Å”Ädu pieprasÄ«jumu tiek izpildÄ«ts laika vienÄ«bÄ, un iepriekÅ”minÄtais thread_pool.management ne tikai nav uzrÄdÄ«ts oficiÄlajÄ dokumentÄcijÄ, bet arÄ« pÄc noklusÄjuma ir ierobežots lÄ«dz 5 pavedieniem, kas tiek ļoti Ätri atbrÄ«voties, pÄc tam kura uzraudzÄ«ba pÄrstÄj darboties pareizi.
NobeigumÄ es gribu teikt: mÄs to izdarÄ«jÄm! MÄs varÄjÄm saviem programmÄtÄjiem un izstrÄdÄtÄjiem dot rÄ«ku, kas gandrÄ«z jebkurÄ situÄcijÄ var Ätri un droÅ”i sniegt informÄciju par to, kas notiek ražoÅ”anÄ.
JÄ, tas izrÄdÄ«jÄs diezgan sarežģīts, bet, neskatoties uz to, mums izdevÄs ietilpinÄt savas vÄlmes esoÅ”ajos produktos, kas nebija jÄlÄpÄ« un jÄpÄrraksta paÅ”iem.
Avots: www.habr.com