Margir glíma við Elasticsearch. En hvað gerist þegar þú vilt nota það til að geyma annála „í sérstaklega miklu magni“? Og er það líka sársaukalaust að upplifa bilun í einhverjum af nokkrum gagnaverum? Hvers konar arkitektúr ættir þú að gera og hvaða gildrur muntu rekast á?
Við hjá Odnoklassniki ákváðum að nota elasticsearch til að leysa vandamálið um logstjórnun og nú deilum við reynslu okkar með Habr: bæði um arkitektúr og um gildrur.
Ég er Pyotr Zaitsev, ég vinn sem kerfisstjóri hjá Odnoklassniki. Þar áður var ég líka admin, vann með Manticore Search, Sphinx search, Elasticsearch. Kannski, ef önnur ...leit birtist, mun ég líklega vinna með hana líka. Ég tek einnig þátt í fjölda opinna verkefna í sjálfboðavinnu.
Þegar ég kom til Odnoklassniki sagði ég kæruleysislega í viðtalinu að ég gæti unnið með Elasticsearch. Eftir að ég náði tökum á því og kláraði nokkur einföld verkefni fékk ég það stóra verkefni að endurbæta logstjórnunarkerfið sem var til á þeim tíma.
Kröfur
Kerfiskröfurnar voru mótaðar sem hér segir:
- Graylog átti að nota sem framenda. Vegna þess að fyrirtækið hafði þegar reynslu af því að nota þessa vöru vissu forritarar og prófunaraðilar það, það var þeim kunnuglegt og þægilegt.
- Gagnamagn: að meðaltali 50-80 þúsund skilaboð á sekúndu en ef eitthvað bilar þá takmarkast umferðin ekki af neinu, hún getur verið 2-3 milljónir línur á sekúndu
- Eftir að hafa rætt við viðskiptavini kröfurnar um hraða vinnslu leitarfyrirspurna komumst við að því að dæmigert mynstur þess að nota slíkt kerfi er þetta: fólk er að leita að skrám yfir umsókn sína síðustu tvo daga og vill ekki bíða lengur en kl. annað fyrir niðurstöðu mótaðrar fyrirspurnar.
- Stjórnendur kröfðust þess að auðvelt væri að skala kerfið ef þörf krefur, án þess að þurfa að kafa djúpt í hvernig það virkar.
- Þannig að eina viðhaldsverkefnið sem þessi kerfi þurfa reglulega er að breyta einhverjum vélbúnaði.
- Að auki hefur Odnoklassniki framúrskarandi tæknihefð: sérhver þjónusta sem við ræsum verður að lifa af bilun í gagnaveri (skyndilega, ófyrirséð og algerlega hvenær sem er).
Síðasta krafan í framkvæmd þessa verkefnis kostaði okkur mest, sem ég mun fjalla nánar um.
miðvikudagur
Við vinnum í fjórum gagnaverum á meðan Elasticsearch gagnahnútar geta aðeins verið staðsettir í þremur (af ýmsum ótæknilegum ástæðum).
Þessar fjórar gagnaver innihalda um það bil 18 þúsund mismunandi annálauppsprettur - vélbúnað, gáma, sýndarvélar.
Mikilvægur eiginleiki: þyrpingin byrjar í gámum ekki á líkamlegum vélum, heldur á . Gámarnir eru tryggðir 2 kjarna, svipað og 2.0Ghz v4, með möguleika á að endurvinna þá kjarna sem eftir eru ef þeir eru aðgerðalausir.
Með öðrum orðum:
Grunnfræði
Ég sá upphaflega almennt form lausnarinnar sem hér segir:
- 3-4 VIP eru á bak við A-skrá Graylog lénsins, þetta er heimilisfangið sem logs eru sendar á.
- hver VIP er LVS jafnvægismaður.
- Eftir það fara logarnir í Graylog rafhlöðuna, sum gagna eru á GELF sniði, önnur á syslog sniði.
- Síðan er þetta allt skrifað í stórum lotum á rafhlöðu Elasticsearch samræmingaraðila.
- Og þeir senda aftur á móti skrifa og lesa beiðnir til viðkomandi gagnahnúta.
Terminology
Kannski skilja ekki allir hugtökin í smáatriðum og því langar mig að staldra aðeins við það.
Elasticsearch hefur nokkrar gerðir af hnútum - meistari, samræmingarstjóri, gagnahnútur. Það eru tvær aðrar gerðir fyrir mismunandi annálabreytingar og samskipti milli mismunandi klasa, en við notuðum aðeins þær sem taldar eru upp.
Meistari
Það smellir öllum hnútum sem eru til staðar í þyrpingunni, heldur uppfærðu klasakorti og dreifir því á milli hnúta, vinnur úr atburðarrökfræði og framkvæmir ýmis konar þrif á þyrpingum.
Umsjónarmann
Framkvæmir eitt verkefni: tekur við lestrar- eða skrifbeiðnum frá viðskiptavinum og leiðir þessa umferð. Ef það er skrifbeiðni, líklega, mun það spyrja meistara hvaða brot af viðkomandi vísitölu það ætti að setja það í, og mun beina beiðninni áfram.
Gagnahnútur
Geymir gögn, framkvæmir leitarfyrirspurnir sem berast utan frá og framkvæmir aðgerðir á brotum sem eru á þeim.
grásleppu
Þetta er eitthvað eins og samruni Kibana með Logstash í ELK stafla. Graylog sameinar bæði notendaviðmót og annálavinnsluleiðslu. Undir hettunni rekur Graylog Kafka og Zookeeper, sem veita tengingu við Graylog sem þyrping. Graylog getur vistað annála (Kafka) ef Elasticsearch er ekki tiltækt og endurtekið misheppnaðar lestrar- og skrifbeiðnir, flokkað og merkt annála samkvæmt tilgreindum reglum. Eins og Logstash hefur Graylog virkni til að breyta línum áður en þær eru skrifaðar í Elasticsearch.
Að auki er Graylog með innbyggða þjónustuuppgötvun sem gerir, byggt á einum tiltækum Elasticsearch hnút, kleift að ná í allt klasakortið og sía það eftir ákveðnu merki, sem gerir það mögulegt að beina beiðnum til ákveðinna gáma.
Sjónrænt lítur það einhvern veginn svona út:
Þetta er skjáskot frá ákveðnu tilviki. Hér byggjum við sögurit byggt á leitarfyrirspurninni og birtum viðeigandi línur.
Vísitölur
Aftur að kerfisarkitektúrnum langar mig að staldra nánar við hvernig við byggðum vísitölulíkanið þannig að þetta virkaði allt rétt.
Í skýringarmyndinni hér að ofan er þetta lægsta stigið: Elasticsearch gagnahnútar.
Vísitalan er stór sýndareining sem samanstendur af Elasticsearch-brotum. Í sjálfu sér er hver brotin ekkert annað en Lucene vísitala. Og hver Lucene vísitala, aftur á móti, samanstendur af einum eða fleiri hlutum.
Við hönnun komumst við að því að til að uppfylla kröfuna um leshraða á miklu magni gagna þyrftum við að „dreifa“ þessum gögnum jafnt yfir gagnahnúta.
Þetta leiddi til þess að fjöldi brota á hverja vísitölu (með eftirmyndum) ætti að vera nákvæmlega jafn fjölda gagnahnúta. Í fyrsta lagi, til að tryggja afritunarstuðul sem er jafn og tveir (það er, við getum tapað helmingi þyrpingarinnar). Og í öðru lagi til að vinna úr lestrar- og skrifbeiðnum á að minnsta kosti helming þyrpingarinnar.
Við ákváðum fyrst geymslutímann sem 30 daga.
Hægt er að sýna dreifingu brota á myndrænan hátt sem hér segir:
Allur dökkgrái rétthyrningurinn er vísir. Vinstri rauði ferningurinn í honum er frumbrotinn, sá fyrsti í vísitölunni. Og blái ferningurinn er eftirlíking af broti. Þau eru staðsett í mismunandi gagnaverum.
Þegar við bætum við öðru broti fer það í þriðja gagnaverið. Og á endanum fáum við þessa uppbyggingu, sem gerir það mögulegt að missa DC án þess að missa samkvæmni gagna:
Snúningur á vísitölum, þ.e. að búa til nýjan vísitölu og eyða þeirri elstu, við gerðum hana jafngilda 48 klukkustundum (samkvæmt mynstri vísitölunotkunar: oftast er leitað í síðustu 48 klukkustundum).
Þetta vísitölusnúningsbil er vegna eftirfarandi ástæðna:
Þegar leitarbeiðni berst á tiltekinn gagnahnút, þá er það, frá frammistöðusjónarmiði, arðbærara þegar spurt er um eitt brot, ef stærð hans er sambærileg við stærð mjöðm hnútsins. Þetta gerir þér kleift að halda „heitum“ hluta vísitölunnar í hrúgu og fá fljótt aðgang að honum. Þegar það er mikið af „heitum hlutum“ minnkar hraði vísitöluleitar.
Þegar hnútur byrjar að keyra leitarfyrirspurn á einni brotnu, úthlutar hann fjölda þráða sem jafngildir fjölda ofþráðskjarna í líkamlegu vélinni. Ef leitarfyrirspurn hefur áhrif á mikinn fjölda brota, þá vex fjöldi þráða hlutfallslega. Þetta hefur neikvæð áhrif á leitarhraða og hefur neikvæð áhrif á flokkun nýrra gagna.
Til að veita nauðsynlega leitartíma ákváðum við að nota SSD. Til að vinna hratt úr beiðnum þurftu vélarnar sem hýstu þessa gáma að hafa að minnsta kosti 56 kjarna. Myndin 56 var valin sem skilyrt nægilegt gildi sem ákvarðar fjölda þráða sem Elasticsearch mun búa til við notkun. Í Elasitcsearch eru margar þráðasundsfæribreytur beint háðar fjölda tiltækra kjarna, sem aftur hefur bein áhrif á nauðsynlegan fjölda hnúta í þyrpingunni samkvæmt meginreglunni „færri kjarna - fleiri hnútar“.
Fyrir vikið komumst við að því að að meðaltali vegur brot um 20 gígabæt og það eru 1 brot á hverri vísitölu. Í samræmi við það, ef við snúum þeim einu sinni á 360 klukkustunda fresti, þá höfum við 48 af þeim. Hver vísitala inniheldur gögn fyrir 15 daga.
Gagnaritun og lestrarrásir
Við skulum reikna út hvernig gögn eru skráð í þessu kerfi.
Segjum að einhver beiðni berist frá Graylog til umsjónarmannsins. Til dæmis viljum við verðtryggja 2-3 þúsund línur.
Eftir að hafa fengið beiðni frá Graylog spyr umsjónarmaðurinn meistarann: „Í flokkunarbeiðninni tilgreindum við sérstaklega vísitölu, en í hvaða broti á að skrifa hana var ekki tilgreint.
Skipstjórinn svarar: „Skrifaðu þessar upplýsingar á brot númer 71,“ eftir það eru þær sendar beint á viðkomandi gagnahnút, þar sem frumbrot númer 71 er staðsett.
Eftir það er færsluskráin afrituð í eftirmyndarbrot, sem er staðsett í öðru gagnaveri.
Leitarbeiðni berst frá Graylog til umsjónarmanns. Umsjónarmaðurinn vísar því áfram í samræmi við vísitöluna, en Elasticsearch dreifir beiðnum á milli aðal-shard og eftirmyndar-shard með því að nota round-robin meginregluna.
180 hnútarnir bregðast misjafnlega við og á meðan þeir eru að svara safnar samræmingarstjórinn upplýsingum sem þegar hefur verið „spýtt út“ af hraðari gagnahnútum. Eftir þetta, þegar annað hvort allar upplýsingar hafa borist, eða beiðnin hefur náð tímamörkum, gefur það allt beint til viðskiptavinarins.
Allt þetta kerfi vinnur að meðaltali úr leitarfyrirspurnum síðustu 48 klukkustundirnar á 300-400 ms, að undanskildum þeim fyrirspurnum með fremstu algildisstaf.
Blóm með Elasticsearch: Java uppsetning
Til að allt virki eins og við vildum upphaflega eyddum við mjög löngum tíma í að kemba margs konar hluti í þyrpingunni.
Fyrsti hluti vandamálanna sem uppgötvaðist tengdist því hvernig Java er sjálfgefið forstillt í Elasticsearch.
Vandamál eitt
Við höfum séð mjög mikinn fjölda skýrslna um að á Lucene stigi, þegar bakgrunnsverk eru í gangi, mistekst Lucene hluti sameiningarinnar með villu. Jafnframt var ljóst í loggunum að þetta var OutOfMemoryError villa. Við sáum af fjarmælingum að mjöðmin var laus og það var ekki ljóst hvers vegna þessi aðgerð misheppnaðist.
Það kom í ljós að Lucene index sameining eiga sér stað utan mjöðm. Og gámar eru frekar takmarkaðir hvað varðar auðlindir sem neytt er. Aðeins hrúga gæti passað inn í þessar auðlindir (gildið heap.size var um það bil jafnt og vinnsluminni) og sumar aðgerðir utan hrúgu hrundu með minnisúthlutunarvillu ef þær af einhverjum ástæðum pössuðu ekki inn í ~500MB sem voru eftir fyrir mörkin.
Lagfæringin var frekar léttvæg: magn vinnsluminni sem var tiltækt fyrir gáminn var aukið, eftir það gleymdum við að við áttum jafnvel í slíkum vandamálum.
Vandamál tvö
4-5 dögum eftir að þyrpingin var ræst tókum við eftir því að gagnahnútar fóru að detta reglulega út úr þyrpingunni og fara inn í hann eftir 10-20 sekúndur.
Þegar við byrjuðum að átta okkur á því kom í ljós að þessu off-heap minni í Elasticsearch er ekki stjórnað á nokkurn hátt. Þegar við gáfum meira minni í ílátið gátum við fyllt beinu biðminni af ýmsum upplýsingum og það var hreinsað aðeins eftir að skýr GC var ræst úr Elasticsearch.
Í sumum tilfellum tók þessi aðgerð nokkuð langan tíma og á þessum tíma tókst þyrpingunni að merkja þennan hnút sem þegar farinn. Þessu vandamáli er vel lýst .
Lausnin var sem hér segir: við takmörkuðum getu Java til að nota megnið af minni utan haugsins fyrir þessar aðgerðir. Við takmörkuðum það við 16 gígabæt (-XX:MaxDirectMemorySize=16g), sem tryggðum að skýrt GC væri kallað mun oftar og unnið mun hraðar, þannig að ekki lengur óstöðugleika þyrpingarinnar.
Vandamál þrjú
Ef þú heldur að vandamálunum með „hnútar sem fara úr þyrpingunni á óvæntasta augnabliki“ sé lokið, þá hefurðu rangt fyrir þér.
Þegar við stilltum verkið með vísitölum völdum við mmapfs til á ferskum brotum með mikilli skiptingu. Þetta var talsverð klúður, því þegar mmapfs er notað er skránni varpað inn í vinnsluminni og síðan er unnið með kortlagða skrána. Vegna þessa kemur í ljós að þegar GC reynir að stöðva þræði í forritinu förum við í öryggispunktinn í mjög langan tíma og á leiðinni að honum hættir forritið að svara beiðnum húsbóndans um hvort það sé lifandi . Í samræmi við það telur meistari að hnúturinn sé ekki lengur til staðar í þyrpingunni. Eftir þetta, eftir 5-10 sekúndur, virkar sorpið, hnúturinn lifnar við, fer inn í þyrpinguna aftur og byrjar að frumstilla brot. Þetta leið allt mjög eins og „framleiðslan sem við áttum skilið“ og hentaði ekki fyrir neitt alvarlegt.
Til að losna við þessa hegðun skiptum við fyrst yfir í staðlaða niofs og síðan, þegar við fluttum frá fimmtu útgáfunni af Elastic yfir í þá sjöttu, reyndum við hybridfs, þar sem þetta vandamál var ekki endurskapað. Þú getur lesið meira um tegundir geymslu .
Vandamál fjögur
Svo kom annað mjög áhugavert vandamál sem við fengum að meðhöndla í mettíma. Við náðum því í 2-3 mánuði því mynstur hans var algjörlega óskiljanlegt.
Stundum fóru umsjónarmenn okkar á Full GC, venjulega einhvern tíma eftir hádegismat, og komu aldrei aftur þaðan. Á sama tíma, þegar þú skráir GC seinkunina, leit það svona út: allt gengur vel, jæja, jæja, og svo allt í einu er allt að fara mjög illa.
Í fyrstu héldum við að við værum með vondan notanda sem væri að setja af stað einhvers konar beiðni sem sló umsjónarmanninn úr vinnuham. Við skráðum beiðnir í mjög langan tíma og reyndum að komast að því hvað var að gerast.
Fyrir vikið kom í ljós að á því augnabliki sem notandi setur risastóra beiðni, og það kemst til ákveðins Elasticsearch samræmingaraðila, svara sumir hnútar lengur en aðrir.
Og á meðan samræmingarstjórinn bíður eftir svari frá öllum hnútunum, safnar hann niðurstöðunum sem sendar eru frá hnútunum sem þegar hafa svarað. Fyrir GC þýðir þetta að hrúganotkunarmynstur okkar breytast mjög hratt. Og GC sem við notuðum gat ekki ráðið við þetta verkefni.
Eina leiðréttingin sem við fundum til að breyta hegðun klasans í þessum aðstæðum er flutningur yfir í JDK13 og notkun á Shenandoah sorphirðu. Þetta leysti vandamálið, umsjónarmenn okkar hættu að detta.
Þetta er þar sem vandamálin með Java enduðu og bandbreiddarvandamálin hófust.
„Berries“ með Elasticsearch: afköst
Vandamál með afköst gera það að verkum að þyrpingin okkar virkar stöðugt, en þegar fjöldi verðtryggðra skjala er hámarki og meðan á hreyfingum stendur er árangur ófullnægjandi.
Fyrsta einkennin sem kom upp: við sumar „sprengingar“ í framleiðslu, þegar mjög mikill fjöldi annála myndast skyndilega, byrjar vísitöluvillan es_rejected_execution að blikka oft í Graylog.
Þetta var vegna þess að thread_pool.write.queue á einum gagnahnút, þar til Elasticsearch er fær um að vinna úr flokkunarbeiðninni og hlaðið upp upplýsingum á brotið á disknum, getur sjálfgefið aðeins 200 beiðnir í skyndiminni. Og í Mjög lítið er sagt um þessa breytu. Aðeins hámarksfjöldi þráða og sjálfgefin stærð eru tilgreind.
Auðvitað fórum við að snúa þessu gildi og komumst að eftirfarandi: nánar tiltekið, í uppsetningunni okkar eru allt að 300 beiðnir í skyndiminni nokkuð vel og hærra gildi fylgir því að við fljúgum aftur inn í Full GC.
Þar að auki, þar sem þetta eru lotur af skilaboðum sem berast innan einni beiðni, var nauðsynlegt að fínstilla Graylog þannig að það skrifist ekki oft og í litlum lotum, heldur í stórum lotum eða einu sinni á 3 sekúndna fresti ef lotan er enn ekki fullbúin. Í þessu tilviki kemur í ljós að upplýsingarnar sem við skrifum í Elasticsearch verða ekki tiltækar á tveimur sekúndum, heldur á fimm (sem hentar okkur nokkuð vel), en fjöldi endurvarpa sem þarf að gera til að ýta í gegnum stóra stafli upplýsinga minnkar.
Þetta er sérstaklega mikilvægt á þeim augnablikum þegar eitthvað hefur hrunið einhvers staðar og tilkynnir um það í reiði til að fá ekki alveg ruslpóst Elastic, og eftir nokkurn tíma - Graylog hnúðar sem eru óstarfhæfar vegna stíflaðra biðminni.
Þar að auki, þegar við fengum þessar sömu sprengingar í framleiðslu, fengum við kvartanir frá forriturum og prófurum: á því augnabliki sem þeir þurftu virkilega á þessum annálum að halda, fengu þeir þær mjög hægt.
Þeir fóru að átta sig á því. Annars vegar var ljóst að bæði leitarfyrirspurnir og flokkunarfyrirspurnir voru unnar, í raun og veru, á sömu líkamlegu vélunum og með einum eða öðrum hætti yrðu ákveðin niðurfellingar.
En þetta gæti verið sniðgengið að hluta vegna þess að í sjöttu útgáfunni af Elasticsearch birtist reiknirit sem gerir þér kleift að dreifa fyrirspurnum á milli viðeigandi gagnahnúta sem eru ekki samkvæmt handahófskenndu round-robin meginreglunni (ílátið sem gerir flokkun og geymir aðal -shard getur verið mjög upptekið, það verður engin leið til að bregðast fljótt við), heldur áframsenda þessa beiðni til minna hlaðinn ílát með eftirmynd-shard, sem mun bregðast miklu hraðar. Með öðrum orðum, við komumst að use_adaptive_replica_selection: satt.
Lesmyndin byrjar að líta svona út:
Umskiptin yfir í þetta reiknirit gerði það mögulegt að bæta fyrirspurnartíma verulega á þeim augnablikum þegar við áttum mikið flæði af annálum til að skrifa.
Að lokum var aðalvandamálið sársaukalaus fjarlæging gagnaversins.
Það sem við vildum frá þyrpingunni strax eftir að tengingin við einn DC rofnaði:
- Ef við höfum núverandi skipstjóra í biluðu gagnaverinu, þá verður það endurvalið og flutt sem hlutverk í annan hnút í öðru DC.
- Skipstjórinn mun fljótt fjarlægja alla óaðgengilega hnúta úr þyrpingunni.
- Miðað við þær sem eftir eru mun hann skilja: í týndu gagnaverinu vorum við með svona og slíka aðalbrot, hann mun fljótt kynna viðbótar eftirmyndarbrot í þeim gagnaverum sem eftir eru og við munum halda áfram að skrá gögnin.
- Afleiðingin er sú að rit- og lestrarstreymi klasans minnkar smám saman, en almennt mun allt virka, að vísu hægt, en stöðugt.
Eins og það kom í ljós, vildum við eitthvað á þessa leið:
Og við fengum eftirfarandi:
Hvernig gerðist þetta?
Þegar gagnaverið féll varð húsbóndi okkar flöskuhálsinn.
Hvers vegna?
Staðreyndin er sú að meistarinn er með TaskBatcher, sem sér um að dreifa ákveðnum verkefnum og viðburðum í klasanum. Hvaða hnútaútgang sem er, hvaða kynning sem er á broti frá eftirmynd til aðal, hvaða verkefni sem er til að búa til brot einhvers staðar - allt þetta fer fyrst í TaskBatcher, þar sem það er unnið í röð og í einum þræði.
Þegar eitt gagnaver var afturkallað kom í ljós að allir gagnahnútar í eftirlifandi gagnaverum töldu það skyldu sína að tilkynna skipstjóranum „við höfum týnt svona og þvílíkum brotum og svona og þvílíkum gagnahnútum.
Á sama tíma sendu eftirlifandi gagnahnútar allar þessar upplýsingar til núverandi skipstjóra og reyndu að bíða eftir staðfestingu á því að hann samþykkti þær. Þeir biðu ekki eftir þessu, þar sem húsbóndinn fékk verkefni hraðar en hann gat svarað. Hnútarnir tóku út endurteknar beiðnir og skipstjórinn á þessum tíma reyndi ekki einu sinni að svara þeim, heldur var algjörlega upptekinn af því verkefni að flokka beiðnir eftir forgangi.
Í flugstöðvaformi kom í ljós að gagnahnútarnir spammaðu masterinn að því marki að hann fór í fullan GC. Eftir það færðist meistarahlutverkið okkar yfir á einhvern næsta hnút, nákvæmlega það sama gerðist við hann og í kjölfarið hrundi þyrpingin algjörlega.
Við tókum mælingar og fyrir útgáfu 6.4.0, þar sem þetta var lagað, var nóg fyrir okkur að senda samtímis aðeins 10 gagnahnúta af 360 til að slökkva algjörlega á þyrpingunni.
Það leit eitthvað á þessa leið:
Eftir útgáfu 6.4.0, þar sem þessi hræðilega villa var lagfærð, hættu gagnahnútar að drepa meistarann. En það gerði hann ekki „snjallari“. Nefnilega: þegar við sendum út 2, 3 eða 10 (hvaða sem er annað en einn) gagnahnúta, fær skipstjórinn einhver fyrstu skilaboð sem segja að hnútur A sé farinn og reynir að segja hnút B, hnút C frá þessu, hnút D.
Og í augnablikinu er aðeins hægt að bregðast við þessu með því að setja tímamörk fyrir tilraunir til að segja einhverjum frá einhverju, jafngildir um 20-30 sekúndum, og stjórna þannig hraða gagnaversins sem færist út úr þyrpingunni.
Í grundvallaratriðum passar þetta inn í þær kröfur sem upphaflega voru settar fram til lokaafurðarinnar sem hluti af verkefninu, en frá sjónarhóli „hreinra vísinda“ er þetta galli. Sem, við the vegur, tókst að laga af hönnuðum í útgáfu 7.2.
Þar að auki, þegar ákveðinn gagnahnút slokknaði, kom í ljós að miðla upplýsingum um útgöngu hans var mikilvægara en að segja öllum klasanum að það væru svona og svo frumbrot á honum (til að stuðla að eftirmyndarbroti í öðrum gögnum miðstöð í prófkjöri, og í upplýsingar mætti skrifa á þær).
Þess vegna, þegar allt hefur þegar dofnað, eru útgefnu gagnahnútarnir ekki strax merktir sem gamlir. Í samræmi við það, neyðumst við til að bíða þar til öll ping hafa runnið út á útgefna gagnahnúta, og aðeins eftir það byrjar þyrpingin okkar að segja okkur að þar, þar og þar þurfum við að halda áfram að skrá upplýsingar. Þú getur lesið meira um þetta .
Þar af leiðandi tekur aðgerðin við að taka gagnaver í dag um 5 mínútur á álagstímum. Fyrir svona stóran og klaufalegan kóloss er þetta nokkuð góður árangur.
Í kjölfarið komumst við að eftirfarandi ákvörðun:
- Við höfum 360 gagnahnúta með 700 gígabæta diskum.
- 60 samræmingarstjórar til að beina umferð um þessa sömu gagnahnúta.
- 40 meistarar sem við höfum skilið eftir sem einskonar arfleifð frá útgáfum fyrir 6.4.0 - til að lifa af afturköllun gagnaversins vorum við andlega reiðubúin að missa nokkrar vélar til að vera tryggð að vera með meistaradeild jafnvel í versta tilfelli
- Allar tilraunir til að sameina hlutverk á einum gám voru mætt með þeirri staðreynd að fyrr eða síðar myndi hnúturinn brotna undir álagi.
- Allur þyrpingin notar hrúgu.stærð upp á 31 gígabæta: allar tilraunir til að minnka stærðina leiddu annað hvort til að drepa nokkra hnúta á þungum leitarfyrirspurnum með fremstu algildisstafi eða fá aflrofann í Elasticsearch sjálfri.
- Að auki, til að tryggja árangur leitar, reyndum við að halda fjölda hluta í klasanum eins litlum og hægt er, til að vinna úr sem fæstum atburðum í flöskuhálsinum sem við fengum í masternum.
Að lokum um eftirlit
Til að tryggja að allt þetta virki eins og ætlað er, fylgjumst við með eftirfarandi:
- Hver gagnahnútur tilkynnir skýinu okkar að það sé til, og það eru svona og svo brot á því. Þegar við slökktum eitthvað einhvers staðar, þá tilkynnir þyrpingin eftir 2-3 sekúndur að í miðju A slökktum við hnúta 2, 3 og 4 - þetta þýðir að í öðrum gagnaverum getum við ekki undir neinum kringumstæðum slökkt á þeim hnútum þar sem það er aðeins eitt brot vinstri.
- Þegar við vitum hvers eðlis hegðun meistarans er, lítum við mjög vel á fjölda verkefna sem bíða. Vegna þess að jafnvel eitt fast verkefni, ef það rennur ekki út í tíma, getur fræðilega í einhverjum neyðartilvikum orðið ástæðan fyrir því að til dæmis kynning á eftirmyndarbroti í prófkjörinu virkar ekki, sem er ástæðan fyrir því að verðtrygging hættir að virka.
- Við skoðum líka tafir á sorphirðu mjög vel því við höfum þegar átt í miklum erfiðleikum með þetta við hagræðingu.
- Hafnar með þræði til að skilja fyrirfram hvar flöskuhálsinn er.
- Jæja, staðlaðar mælingar eins og hrúga, vinnsluminni og I/O.
Þegar þú byggir upp vöktun verður þú að taka tillit til eiginleika þráðalaugar í Elasticsearch. lýsir stillingarvalkostum og sjálfgefnum gildum fyrir leit og flokkun, en er algjörlega hljóður um thread_pool.management. Þessir þræðir vinna sérstaklega með fyrirspurnir eins og _cat/shards og aðrar svipaðar, sem þægilegt er að nota þegar eftirlit er skrifað. Því stærri sem þyrpingin er, því fleiri slíkar beiðnir eru framkvæmdar á tímaeiningu og áðurnefnd thread_pool.management er ekki aðeins ekki kynnt í opinberu skjölunum, heldur er hún einnig sjálfgefið takmörkuð við 5 þræði, sem er mjög fljótt eytt, eftir sem eftirlit hættir að virka rétt.
Það sem ég vil segja að lokum: við gerðum það! Okkur tókst að gefa forriturum okkar og þróunaraðilum tól sem, í næstum öllum aðstæðum, getur fljótt og áreiðanlega veitt upplýsingar um hvað er að gerast í framleiðslu.
Já, þetta reyndist frekar flókið, en engu að síður tókst okkur að passa óskir okkar inn í núverandi vörur sem við þurftum ekki að laga og endurskrifa fyrir okkur.
Heimild: www.habr.com