In protte minsken wrakselje mei Elasticsearch. Mar wat bart der as jo it wolle brûke om logs "yn in bysûnder grut folume" op te slaan? En is it ek pynlik om it mislearjen fan ien fan ferskate datasintra te belibjen? Hokker soarte fan arsjitektuer moatte jo meitsje, en hokker pitfalls sille jo stroffelje op?
Wy by Odnoklassniki besletten om elasticsearch te brûken om it probleem fan logboekbehear op te lossen, en no diele wy ús ûnderfining mei Habr: sawol oer arsjitektuer as oer pitfalls.
Ik bin Pyotr Zaitsev, ik wurkje as systeembehearder by Odnoklassniki. Dêrfoar wie ik ek in admin, wurke mei Manticore Search, Sphinx search, Elasticsearch. Miskien, as der in oare sykaksje ferskynt, sil ik der wierskynlik ek mei wurkje. Ik doch ek op frijwillige basis mei oan tal fan iepen boarne projekten.
Doe't ik by Odnoklassniki kaam, sei ik roekeloos by it ynterview dat ik mei Elasticsearch koe wurkje. Nei't ik it oan 'e hân hie en wat ienfâldige taken foltôge, krige ik de grutte taak om it logbehearsysteem dat op dat stuit bestie te herfoarmjen.
easken
De systeemeasken waarden formulearre as folget:
- Graylog soe brûkt wurde as frontend. Om't it bedriuw al ûnderfining hie mei it brûken fan dit produkt, wisten programmeurs en testers it, it wie har fertroud en handich.
- Data folume: gemiddeld 50-80 tûzen berjochten per sekonde, mar as der wat brekt, dan wurdt it ferkear net beheind troch alles, it kin 2-3 miljoen rigels per sekonde wêze
- Nei't wy mei klanten de easken besprutsen hawwe foar de snelheid fan it ferwurkjen fan sykfragen, realisearre wy dat it typyske patroan fan it brûken fan sa'n systeem dit is: minsken sykje logs fan har applikaasje foar de lêste twa dagen en wolle net mear wachtsje as in twadde foar it resultaat fan in formulearre query.
- De behearders stiene der op dat it systeem maklik skalberber wie as dat nedich is, sûnder dat se nedich binne om djip te ferdjipjen yn hoe't it wurket.
- Dat de ienige ûnderhâldstaak dy't dizze systemen periodyk fereaskje is wat hardware te feroarjen.
- Derneist hat Odnoklassniki in poerbêste technyske tradysje: elke tsjinst dy't wy lansearje moat in datacenterfal oerlibje (hommels, net pland en absolút op elk momint).
De lêste eask by de útfiering fan dit projekt kostet ús it measte, dêr't ik yn mear detail oer praat.
Woansdei
Wy wurkje yn fjouwer datasintra, wylst Elasticsearch-gegevensknooppunten allinich yn trije kinne lizze (foar in oantal net-technyske redenen).
Dizze fjouwer datasintra befetsje sawat 18 tûzen ferskillende logboarnen - hardware, konteners, firtuele masines.
Wichtige funksje: it kluster begjint yn konteners net op fysike masines, mar op . Containers wurde garandearre 2 kearnen, fergelykber mei 2.0Ghz v4, mei de mooglikheid fan recycling de oerbleaune kearnen as se idle.
Mei oare wurden:
Topology
Ik seach earst de algemiene foarm fan 'e oplossing as folget:
- 3-4 VIP's binne efter it A-record fan it Greylog-domein, dit is it adres wêr't de logs nei stjoerd wurde.
- eltse VIP is in LVS balancer.
- Dêrnei geane de logs nei de Graylog-batterij, guon fan 'e gegevens binne yn GELF-formaat, guon yn syslog-formaat.
- Dan wurdt dit alles yn grutte batches skreaun nei in batterij fan Elasticsearch-koördinatoren.
- En se stjoere op har beurt skriuw- en lêsfersiken nei de relevante gegevensknooppunten.
Terminology
Faaks begrypt net elkenien de terminology yn detail, dus ik soe der wol efkes by stilstean wolle.
Elasticsearch hat ferskate soarten knooppunten - master, koördinator, gegevensknooppunt. D'r binne twa oare soarten foar ferskate logtransformaasjes en kommunikaasje tusken ferskate klusters, mar wy brûkten allinich de neamde.
Master
It pingt alle knooppunten oanwêzich yn it kluster, ûnderhâldt in aktuele klusterkaart en ferspriedt it tusken knooppunten, ferwurket barrenslogika, en fiert ferskate soarten klusterbrede húshâlding út.
Koördinator
Fiert ien inkele taak út: aksepteart lês- of skriuwfersiken fan kliïnten en rûte dit ferkear. Yn it gefal dat d'r in skriuwfersyk is, sil it wierskynlik master freegje hokker shard fan 'e oanbelangjende yndeks it moat pleatse, en sil it fersyk fierder omliede.
Data node
Bewarret gegevens, fiert sykfragen út dy't fan bûten komme en fiert operaasjes út op shards dy't derop sitte.
Greylog
Dit is wat as in fúzje fan Kibana mei Logstash yn in ELK stack. Graylog kombineart sawol in UI as in logferwurkingspipeline. Under de motorkap rint Graylog Kafka en Zookeeper, dy't ferbining leverje mei Graylog as in kluster. Graylog kin logs (Kafka) cache yn it gefal dat Elasticsearch net beskikber is en mislearre lês- en skriuwfersiken werhelje, logs groepearje en markearje neffens spesifisearre regels. Lykas Logstash hat Graylog funksjonaliteit om rigen te feroarjen foardat se skriuwe nei Elasticsearch.
Dêrnjonken hat Graylog in ynboude tsjinstûntdekking dy't it mooglik makket, basearre op ien beskikbere Elasticsearch-knooppunt, de folsleine klusterkaart te krijen en troch in spesifike tag te filterjen, wat it mooglik makket om oanfragen nei spesifike konteners te rjochtsjen.
Visueel sjocht it der sa út:
Dit is in skermôfbylding fan in spesifyk eksimplaar. Hjir bouwe wy in histogram basearre op 'e sykfraach en litte relevante rigen sjen.
Yndeksen
Werom nei de systeemarsjitektuer, soe ik yn mear detail wolle wenje oer hoe't wy it yndeksmodel boud hawwe sadat it allegear goed wurke.
Yn it diagram hjirboppe is dit it leechste nivo: Elasticsearch gegevensknooppunten.
In yndeks is in grutte firtuele entiteit dy't bestiet út Elasticsearch-shards. Op himsels is elk fan 'e shards neat mear as in Lucene-yndeks. En elke Lucene-yndeks bestiet op syn beurt út ien of mear segminten.
By it ûntwerpen fûnen wy dat om te foldwaan oan 'e eask foar lêssnelheid op in grutte hoemannichte gegevens, wy dizze gegevens gelijkmatig moatte "fersprieden" oer gegevensknooppunten.
Dit resultearre yn it feit dat it oantal shards per yndeks (mei replika's) strikt gelyk wêze moatte oan it oantal gegevensknooppunten. As earste, om in replikaasjefaktor gelyk oan twa te garandearjen (dat is, wy kinne de helte fan it kluster ferlieze). En, as twadde, om lês- en skriuwfersiken op teminsten de helte fan it kluster te ferwurkjen.
Wy hawwe earst de opslachtiid bepaald as 30 dagen.
De ferdieling fan shards kin as folget grafysk werjûn wurde:
De hiele tsjustere grize rjochthoek is in yndeks. It linker reade fjouwerkant dêryn is de primêre shard, de earste yn 'e yndeks. En it blauwe plein is in replika shard. Se lizze yn ferskate datasintra.
As wy in oare shard tafoegje, giet it nei it tredde datasintrum. En op it lêst krije wy dizze struktuer, dy't it mooglik makket DC te ferliezen sûnder gegevenskonsistinsje te ferliezen:
Rotaasje fan yndeksen, d.w.s. in nije yndeks oanmeitsje en de âldste wiskje, hawwe wy it gelyk makke oan 48 oeren (neffens it patroan fan yndeksgebrûk: de lêste 48 oeren wurde it meast socht).
Dit yndeksrotaasje-ynterval komt troch de folgjende redenen:
As in sykopdracht oankomt op in spesifyk gegevensknooppunt, dan is it, út in prestaasjespunt, rendabeler as ien shard wurdt frege, as syn grutte is te fergelykjen mei de grutte fan 'e heup fan' e knooppunt. Hjirmei kinne jo it "hot" diel fan 'e yndeks yn in heap hâlde en fluch tagong krije ta it. As d'r in protte "hot dielen" binne, degradearret de snelheid fan yndekssykjen.
As in knooppunt begjint mei it útfieren fan in sykfraach op ien shard, allocates it in oantal triedden gelyk oan it oantal hyperthreading-kearnen fan 'e fysike masine. As in sykfraach in grut oantal shards beynfloedet, dan groeit it oantal triedden proporsjoneel. Dit hat in negative ynfloed op syksnelheid en hat in negative ynfloed op de yndeksearring fan nije gegevens.
Om de nedige syklatinsje te leverjen, hawwe wy besletten in SSD te brûken. Om oanfragen fluch te ferwurkjen, moasten de masines dy't dizze konteners hosten op syn minst 56 kearnen hawwe. De sifer fan 56 waard keazen as in betingst genôch wearde dy't it oantal triedden bepaalt dat Elasticsearch sil generearje tidens operaasje. Yn Elasitcsearch binne in protte threadpoolparameters direkt ôfhinklik fan it oantal beskikbere kearnen, wat op syn beurt direkt it fereaske oantal knopen yn it kluster beynfloedet neffens it prinsipe "minder kearnen - mear knopen".
As gefolch hawwe wy fûn dat gemiddeld in shard sawat 20 gigabyte weaget, en d'r binne 1 shards per yndeks. Dêrom, as wy se ien kear elke 360 oeren rotearje, dan hawwe wy 48 fan har. Elke yndeks befettet gegevens foar 15 dagen.
Gegevens skriuwen en lêzen circuits
Litte wy útfine hoe't gegevens yn dit systeem wurde opnommen.
Litte wy sizze dat der in fersyk komt fan Graylog nei de koördinator. Wy wolle bygelyks 2-3 tûzen rigen yndeksearje.
De koördinator, nei't er in fersyk fan Graylog krige, freget de master: "Yn it yndeksearingsfersyk spesifisearre wy spesifyk in yndeks, mar yn hokker shard om it te skriuwen waard net spesifisearre."
De master reagearret: "Skriuw dizze ynformaasje nei shard nûmer 71," wêrnei't it wurdt stjoerd direkt nei de oanbelangjende gegevens node, dêr't primêre-shard nûmer 71 leit.
Wêrnei't it transaksjelogboek wurdt replikearre nei in replika-shard, dy't yn in oar datasintrum leit.
In sykfersyk komt fan Graylog nei de koördinator. De koördinator ferwiist it neffens de yndeks, wylst Elasticsearch fersiken ferspriedt tusken de primêre-shard en replika-shard mei it round-robin-prinsipe.
De 180-knooppunten reagearje unjildich, en wylst se reagearje, sammelet de koördinator ynformaasje dy't al "útspykt" is troch rappere gegevensknooppunten. Hjirnei, as of alle ynformaasje is oankommen, of it fersyk hat berikt in time-out, jout alles direkt oan de klant.
Dit hiele systeem ferwurket gemiddeld sykfragen foar de lêste 48 oeren yn 300-400ms, útsein dy fragen mei in liedende jokerteken.
Blommen mei Elasticsearch: Java opset
Om it allegear te wurkjen sa't wy oarspronklik woenen, hawwe wy in heul lange tiid bestege oan it debuggen fan in breed ferskaat oan dingen yn it kluster.
It earste diel fan 'e ûntdutsen problemen wie relatearre oan' e manier wêrop Java standert is foarôf ynsteld yn Elasticsearch.
Probleem ien
Wy hawwe observearre in hiel grut oantal rapporten dat op Lucene nivo, doe't eftergrûn banen rinne, Lucene segment fusearret mislearre mei in flater. Tagelyk wie it dúdlik yn 'e logs dat dit in OutOfMemoryError-flater wie. Wy seagen út telemetry dat de heup wie frij, en it wie net dúdlik wêrom't dizze operaasje mislearre.
It die bliken dat Lucene yndeks gearfoegings foarkomme bûten de heup. En konteners binne frij strikt beheind yn termen fan konsumeare boarnen. Allinnich heap koe passe yn dizze boarnen (de heap.size wearde wie likernôch gelyk oan RAM), en guon off-heap operaasjes ferûngelokke mei in ûnthâld tawizing flater as se om ien of oare reden net passe yn de ~ 500MB dat bleau foar de limyt.
De fix wie frij triviaal: de hoemannichte RAM beskikber foar de kontener waard ferhege, wêrnei't wy fergetten dat wy sels sokke problemen hiene.
Probleem twa
4-5 dagen nei de lansearring fan it kluster hawwe wy opmurken dat gegevensknooppunten periodyk út it kluster begûnen te fallen en it nei 10-20 sekonden yn te fieren.
Doe't wy it begûnen út te finen, die bliken dat dit off-heap-ûnthâld yn Elasticsearch op gjin inkelde manier kontrolearre wurdt. Doe't wy joegen mear ûnthâld oan de kontener, wy wienen by steat om te foljen de direkte buffer pools mei ferskate ynformaasje, en it waard wiske pas nei de eksplisite GC waard lansearre út Elasticsearch.
Yn guon gefallen duorre dizze operaasje nochal lang, en yn dizze tiid slagge it kluster om dizze knooppunt te markearjen as al útgien. Dit probleem is goed beskreaun .
De oplossing wie as folget: wy beheine de mooglikheid fan Java om it grutste part fan it ûnthâld bûten de heap te brûken foar dizze operaasjes. Wy beheine it ta 16 gigabytes (-XX: MaxDirectMemorySize = 16g), en soargje derfoar dat eksplisite GC folle faker waard neamd en folle flugger ferwurke, wêrtroch it kluster net mear destabilisearret.
Probleem trije
As jo tinke dat de problemen mei "knooppunten dy't it kluster ferlitte op it meast ûnferwachte momint" foarby binne, binne jo ferkeard.
Doe't wy konfigurearre it wurk mei yndeksen, wy keas mmapfs oan op farske shards mei grutte segmintaasje. Dit wie nochal in flater, want by it brûken fan mmapfs wurdt it bestân yn kaart brocht yn RAM, en dan wurkje wy mei it yn kaart brochte bestân. Hjirtroch docht it bliken dat as de GC besiket diskusjes yn 'e applikaasje te stopjen, wy geane nei it safepoint foar in heul lange tiid, en op' e wei nei it, stopet de applikaasje te reagearjen op 'e oanfragen fan' e master oer oft it libbet . Dêrtroch is master fan betinken dat it knooppunt net mear oanwêzich is yn it kluster. Hjirnei, nei 5-10 sekonden, wurket de garbage collector, de knoop komt ta libben, komt wer yn 'e kluster en begjint te initialisearjen fan shards. It fielde allegear heul as "de produksje dy't wy fertsjinnen" en wie net geskikt foar wat serieus.
Om dit gedrach kwyt te reitsjen, skeakelen wy earst oer nei standert niofs, en doe, doe't wy migrearren fan 'e fyfde ferzje fan Elastic nei de seisde, hawwe wy hybridfs besocht, wêr't dit probleem net reprodusearre waard. Jo kinne mear lêze oer opslachtypen .
Probleem fjouwer
Dan wie der noch in hiel nijsgjirrich probleem dat wy in rekordtiid behannele hawwe. Wy fongen it foar 2-3 moannen, om't it patroan absolút ûnbegryplik wie.
Soms gongen ús koördinatoaren nei Full GC, meastentiids soms nei de middei, en kamen dêr noait werom. Tagelyk, by it loggen fan de GC-fertraging, seach it der sa út: alles giet goed, goed, goed, en dan ynienen giet alles hiel min.
Earst tochten wy dat wy in kweade brûker hiene dy't in soarte fan fersyk lansearre dy't de koördinator út 'e wurkmodus sloech. Wy hawwe in lange tiid fersiken oanmeld, besykje út te finen wat der bart.
As resultaat die bliken dat op it momint dat in brûker in enoarm fersyk lanseart, en it komt nei in spesifike Elasticsearch-koördinator, guon knooppunten langer reagearje as oaren.
En wylst de koördinator wachtet op in antwurd fan alle knooppunten, sammelet hy de resultaten dy't stjoerd binne fan 'e knooppunten dy't al reageare hawwe. Foar GC betsjut dit dat ús heapgebrûkspatroanen heul fluch feroarje. En de GC dy't wy brûkten koe dizze taak net oan.
De ienige fix dy't wy fûn hawwe om it gedrach fan 'e kluster yn dizze situaasje te feroarjen is migraasje nei JDK13 en gebrûk fan' e Shenandoah garbage collector. Dit loste it probleem op, ús koördinators stopten te fallen.
Dit is wêr't de problemen mei Java einige en de bânbreedteproblemen begûnen.
"Berries" mei Elasticsearch: trochfier
Problemen mei trochstreaming betsjutte dat ús kluster stabyl wurket, mar by peaks yn it oantal yndeksearre dokuminten en by manoeuvres is de prestaasjes net genôch.
It earste symptoom dat tsjinkaam: tidens guon "eksploazjes" yn produksje, as in heul grut oantal logs ynienen wurde generearre, begjint de yndeksfout es_rejected_execution faak te flitsen yn Graylog.
Dit wie te tankjen oan it feit dat thread_pool.write.queue op ien gegevensknooppunt, oant it momint dat Elasticsearch it yndeksearfersyk ferwurkje kin en de ynformaasje oplade nei de shard op skiif, standert allinich 200 fersiken kin cache. En yn Hiel lyts wurdt sein oer dizze parameter. Allinnich it maksimum oantal triedden en de standertgrutte wurde oanjûn.
Fansels gongen wy dizze wearde te draaien en fûnen it folgjende út: spesifyk, yn ús opset, wurde oant 300 oanfragen frij goed opslein, en in hegere wearde is beladen mei it feit dat wy wer yn Full GC fleane.
Derneist, om't dit batches fan berjochten binne dy't binnen ien fersyk komme, wie it nedich om Graylog sa oan te passen dat it net faak en yn lytse batches skriuwt, mar yn grutte batches of ien kear yn 'e 3 sekonden as de batch noch net kompleet is. Yn dit gefal docht bliken dat de ynformaasje dy't wy skriuwe yn Elasticsearch net yn twa sekonden beskikber wurdt, mar yn fiif (wat ús goed past), mar it oantal retrays dat makke wurde moat om in grutte troch te drukken steapel ynformaasje wurdt fermindere.
Dit is foaral wichtich yn dy mominten doe't wat is ferûngelokke earne en fûleindich berjochten oer it, om net te krijen in folslein spam Elastic, en nei in skoft - Graylog knopen dy't net wurkje fanwegen ferstoppe buffers.
Dêrneist, doe't wy hiene deselde eksploazjes yn produksje, wy krigen klachten fan programmeurs en testers: op it momint dat se echt nedich dizze logs, se krigen se hiel stadich.
Se begûnen it út te finen. Oan 'e iene kant wie it dúdlik dat sawol sykfragen as yndeksearingsfragen ferwurke waarden, yn essinsje, op deselde fysike masines, en op ien of oare manier soene d'r bepaalde ûntlûken wêze.
Mar dit koe foar in part omsmiten wurde troch it feit dat yn 'e sechsde ferzjes fan Elasticsearch in algoritme ferskynde wêrmei jo fragen kinne fersprieden tusken relevante gegevensknooppunten net neffens it willekeurige round-robin-prinsipe (de kontener dy't yndeksearret en hâldt de primêre -shard kin tige drok wêze, d'r sil gjin manier wêze om fluch te reagearjen), mar dit fersyk troch te stjoeren nei in minder laden kontener mei in replika-shard, dy't folle flugger reagearret. Mei oare wurden, wy kamen ta use_adaptive_replica_selection: wier.
De lêsôfbylding begjint der sa út te sjen:
De oergong nei dit algoritme makke it mooglik om de querytiid signifikant te ferbetterjen yn dy mominten dat wy in grutte stream fan logs hiene om te skriuwen.
Uteinlik wie it haadprobleem de pynlike ferwidering fan it datasintrum.
Wat wy woene fan it kluster fuort nei it ferliezen fan ferbining mei ien DC:
- As wy in aktuele master hawwe yn it mislearre datasintrum, dan wurdt it opnij selektearre en ferpleatst as in rol nei in oare knooppunt yn in oare DC.
- De master sil fluch alle ûnberikbere knopen út it kluster fuortsmite.
- Op grûn fan 'e oerbleaune sil hy begripe: yn' e ferlerne gegevenssintrum hienen wy sokke en sokke primêre shards, hy sil fluch komplemintêre replika shards befoarderje yn 'e oerbleaune gegevenssintra, en wy sille trochgean mei it yndeksearjen fan de gegevens.
- Dêrtroch sil de skriuw- en lêstrochslach fan it kluster stadichoan degradearje, mar yn it algemien sil alles wurkje, al is it stadich, mar stabyl.
As it die bliken, woene wy sa'n ding:
En wy krigen it folgjende:
Hoe is it bard?
Doe't it datasintrum foel, waard ús master de knelpunt.
Wêrom?
It feit is dat de master in TaskBatcher hat, dy't ferantwurdlik is foar it fersprieden fan bepaalde taken en eveneminten yn it kluster. Elke knooppuntútgong, elke promoasje fan in shard fan replika nei primêr, elke taak om earne in shard te meitsjen - dit alles giet earst nei TaskBatcher, wêr't it opfolgjend en yn ien thread wurdt ferwurke.
Yn 'e tiid fan' e weromlûking fan ien datasintrum die bliken dat alle gegevensknooppunten yn 'e oerbleaune datasintra it har plicht beskôgen om de master te ynformearjen "wy hawwe sokke en sokke shards en sokke en sokke gegevensknooppunten ferlern."
Tagelyk stjoerde de oerbleaune gegevensknooppunten al dizze ynformaasje nei de hjoeddeistige master en besochten te wachtsjen op befêstiging dat hy it akseptearre. Se wachtsje net op dit, om't de master taken flugger krige as hy koe antwurdzje. De knooppunten time-out werhelle fersiken, en de master op dit stuit net iens besykje te beäntwurdzjen se, mar waard folslein opnommen yn 'e taak fan sortearjen fersiken troch prioriteit.
Yn terminalfoarm die bliken dat de gegevensknooppunten de master spamden oant it punt dat it yn folsleine GC gie. Dêrnei, ús master rol ferhuze nei in folgjende knooppunt, absolút itselde ding barde mei it, en as gefolch it kluster folslein ynstoarte.
Wy namen mjittingen, en foar ferzje 6.4.0, wêr't dit fêst wie, wie it genôch foar ús om tagelyk mar 10 gegevensknooppunten út 360 út te fieren om it kluster folslein ôf te sluten.
It seach der sa út:
Nei ferzje 6.4.0, wêr't dizze skriklike brek waard reparearre, stopten gegevensknooppunten de master te fermoardzjen. Mar dat makke him net "slimmer". Nammentlik: as wy 2, 3 of 10 (elk nûmer oars as ien) gegevensknooppunten útfiere, ûntfangt de master in earste berjocht dat seit dat knooppunt A fuort is, en besiket knooppunt B, knooppunt C oer dit te fertellen, knooppunt D.
En op it stuit kin dit allinich behannele wurde troch it ynstellen fan in time-out foar besykjen om immen oer wat te fertellen, gelyk oan sawat 20-30 sekonden, en sadwaande de snelheid fan it datasintrum te kontrolearjen dat út it kluster beweecht.
Yn prinsipe past dit yn 'e easken dy't ynearsten as ûnderdiel fan it projekt oan it einprodukt presintearre waarden, mar út it eachpunt fan "reine wittenskip" is dit in brek. Wat, trouwens, mei súkses waard reparearre troch de ûntwikkelders yn ferzje 7.2.
Boppedat, doe't in bepaald gegevensknooppunt útgie, die bliken dat it fersprieden fan ynformaasje oer syn útgong wichtiger wie as it hiele kluster te fertellen dat d'r soksoarte en soksoarte primêr-shards op sieten (om in replika-shard yn in oare gegevens te befoarderjen sintrum yn 'e primêre, en yn ynformaasje koe wurde skreaun op harren).
Dêrom, as alles al ferstoarn is, wurde de frijjûne gegevensknooppunten net fuortendaliks markearre as ferâldere. Dêrtroch binne wy twongen om te wachtsjen oant alle pings binne time-out nei de frijjûne gegevensknooppunten, en pas dêrnei begjint ús kluster ús te fertellen dat wy dêr, dêr en dêr moatte trochgean mei opnimmen fan ynformaasje. Jo kinne hjir mear oer lêze .
As resultaat nimt de operaasje fan it weromlûken fan in datasintrum ús hjoed sawat 5 minuten yn 'e spits. Foar sa'n grutte en ûnhandige kolos is dit in aardich goed resultaat.
Dêrtroch kamen wy ta it folgjende beslút:
- Wy hawwe 360 gegevensknooppunten mei 700 gigabyte skiven.
- 60 koördinatoaren foar routing ferkear troch deselde gegevens knopen.
- 40 masters dy't wy hawwe efterlitten as in soarte fan erfenis sûnt ferzjes foar 6.4.0 - om it weromlûken fan it datasintrum te oerlibjen, wiene wy geastlik ree om ferskate masines te ferliezen om garandearre te wêzen in kworum fan masters sels yn it slimste gefal senario
- Elke besykjen om rollen te kombinearjen op ien kontener waard moete mei it feit dat ier of letter de knooppunt soe brekke ûnder lading.
- It hiele kluster brûkt in heap.size fan 31 gigabytes: alle besykjen om de grutte te ferminderjen resultearre yn it fermoardzjen fan guon knopen op swiere sykfragen mei de liedende jokerteken of it krijen fan de circuit breaker yn Elasticsearch sels.
- Dêrnjonken hawwe wy, om de sykprestaasjes te garandearjen, besocht it tal objekten yn it kluster sa lyts mooglik te hâlden, om sa min mooglik foarfallen te ferwurkjen yn it knelpunt dat wy yn de master krigen.
Ta beslút oer tafersjoch
Om te soargjen dat dit alles wurket lykas bedoeld, kontrolearje wy it folgjende:
- Elke gegevensknooppunt rapporteart oan ús wolk dat it bestiet, en d'r binne sokke en sokke stikken op. As wy earne wat útdouwe, meldt it kluster nei 2-3 sekonden dat wy yn sintrum A de knooppunten 2, 3 en 4 útlutsen hawwe - dit betsjut dat wy yn oare datasintra ûnder gjin omstannichheden dy knooppunten kinne blussen dêr't mar ien shard op is links.
- Troch de aard fan it gedrach fan 'e master te witten, sjogge wy heul foarsichtich nei it oantal oanhâldende taken. Om't sels ien fêste taak, as it net op 'e tiid útkomt, teoretysk yn guon needsituaasje de reden kin wurde wêrom't bygelyks de promoasje fan in replika-shard yn' e primêre net wurket, wêrtroch't yndeksearring ophâldt mei wurkjen.
- Wy sjogge ek hiel goed nei ôffalfertragers, om't wy dêr by optimalisaasje al grutte swierrichheden mei hân hawwe.
- Wegert troch tried om fan tefoaren te begripen wêr't de knelpunt is.
- No, standert metriken lykas heap, RAM en I / O.
By it bouwen fan tafersjoch moatte jo rekken hâlde mei de funksjes fan Thread Pool yn Elasticsearch. beskriuwt konfiguraasje-opsjes en standertwearden foar sykjen en yndeksearjen, mar is folslein stil oer thread_pool.management. Dizze diskusjes ferwurkje benammen fragen lykas _cat/shards en oare ferlykbere, dy't handich binne om te brûken by it skriuwen fan tafersjoch. Hoe grutter it kluster, hoe mear sokke fersiken wurde útfierd per ienheid fan tiid, en it earder neamde thread_pool.management wurdt net allinnich net presintearre yn de offisjele dokumintaasje, mar is ek standert beheind ta 5 triedden, dy't hiel fluch ôffierd, neidat hokker tafersjoch ophâldt goed te wurkjen.
Wat ik ta beslút sizze wol: wy hawwe it dien! Wy koene ús programmeurs en ûntwikkelders in ark jaan dat yn hast elke situaasje fluch en betrouber ynformaasje kin leverje oer wat der yn produksje bart.
Ja, it die bliken frij yngewikkeld te wêzen, mar wy binne lykwols slagge om ús winsken yn te passen yn besteande produkten, dy't wy net hoege te patchjen en foar ússels te herskriuwen.
Boarne: www.habr.com