Shumë njerëz luftojnë me Elasticsearch. Por çfarë ndodh kur dëshironi ta përdorni për të ruajtur regjistrat "në një vëllim veçanërisht të madh"? Dhe a është gjithashtu pa dhimbje të përjetosh dështimin e ndonjë prej disa qendrave të të dhënave? Çfarë lloj arkitekture duhet të bëni dhe në cilat gracka do të pengoheni?
Ne në Odnoklassniki vendosëm të përdorim elasticsearch për të zgjidhur çështjen e menaxhimit të regjistrave dhe tani ndajmë përvojën tonë me Habr: si për arkitekturën ashtu edhe për grackat.
Unë jam Pyotr Zaitsev, punoj si administrator sistemi në Odnoklassniki. Para kësaj, unë kam qenë gjithashtu një administrator, kam punuar me Manticore Search, Sphinx search, Elasticsearch. Ndoshta, nëse shfaqet një ...kërkim tjetër, ndoshta do të punoj edhe unë me të. Unë gjithashtu marr pjesë në një sërë projektesh me burim të hapur mbi baza vullnetare.
Kur erdha në Odnoklassniki, thashë pamatur në intervistë se mund të punoja me Elasticsearch. Pasi ia dola mbanë dhe përfundova disa detyra të thjeshta, më dhanë detyrën e madhe për të reformuar sistemin e menaxhimit të regjistrave që ekzistonte në atë kohë.
Kërkesat
Kërkesat e sistemit janë formuluar si më poshtë:
- Graylog do të përdorej si frontend. Për shkak se kompania kishte tashmë përvojë në përdorimin e këtij produkti, programuesit dhe testuesit e dinin atë, ishte i njohur dhe i përshtatshëm për ta.
- Vëllimi i të dhënave: mesatarisht 50-80 mijë mesazhe në sekondë, por nëse diçka prishet, atëherë trafiku nuk kufizohet nga asgjë, mund të jetë 2-3 milion linja në sekondë
- Pasi diskutuam me klientët kërkesat për shpejtësinë e përpunimit të pyetjeve të kërkimit, kuptuam se modeli tipik i përdorimit të një sistemi të tillë është ky: njerëzit po kërkojnë regjistrat e aplikacionit të tyre për dy ditët e fundit dhe nuk duan të presin më shumë se një e dyta për rezultatin e një pyetjeje të formuluar.
- Administratorët këmbëngulën që sistemi të jetë lehtësisht i shkallëzueshëm nëse është e nevojshme, pa kërkuar që ata të thellohen në mënyrën se si funksionon.
- Kështu që e vetmja detyrë e mirëmbajtjes që këto sisteme kërkojnë periodikisht është ndryshimi i disa pajisjeve.
- Për më tepër, Odnoklassniki ka një traditë të shkëlqyer teknike: çdo shërbim që ne lëshojmë duhet t'i mbijetojë një dështimi të qendrës së të dhënave (të papritur, të paplanifikuar dhe absolutisht në çdo kohë).
Kërkesa e fundit në zbatimin e këtij projekti na ka kushtuar më së shumti, për të cilën do të flas më gjerësisht.
E mërkurë
Ne punojmë në katër qendra të dhënash, ndërsa nyjet e të dhënave Elasticsearch mund të vendosen vetëm në tre (për një sërë arsyesh jo-teknike).
Këto katër qendra të të dhënave përmbajnë afërsisht 18 mijë burime të ndryshme regjistrash - harduer, kontejnerë, makina virtuale.
Karakteristikë e rëndësishme: grupi fillon në kontejnerë jo në makina fizike, por në . Kontejnerët kanë 2 bërthama të garantuara, të ngjashme me 2.0 Ghz v4, me mundësinë e riciklimit të bërthamave të mbetura nëse janë boshe.
Me fjale te tjera:
Topologji
Fillimisht e pashë formën e përgjithshme të zgjidhjes si më poshtë:
- 3-4 VIP janë prapa rekordit A të domenit Graylog, kjo është adresa në të cilën dërgohen regjistrat.
- çdo VIP është një balancues LVS.
- Pas tij, regjistrat shkojnë në baterinë Graylog, disa nga të dhënat janë në formatin GELF, disa në formatin syslog.
- Pastaj e gjithë kjo shkruhet në tufa të mëdha në një bateri koordinatorësh të Elasticsearch.
- Dhe ata, nga ana tjetër, dërgojnë kërkesa për shkrim dhe lexim në nyjet përkatëse të të dhënave.
terminologji
Ndoshta jo të gjithë e kuptojnë terminologjinë në detaje, kështu që unë do të doja të ndalem pak në të.
Elasticsearch ka disa lloje të nyjeve - master, koordinator, nyje të dhënash. Ekzistojnë dy lloje të tjera për transformime të ndryshme të regjistrave dhe komunikim midis grupimeve të ndryshme, por ne kemi përdorur vetëm ato të listuara.
Mjeshtër
Ai bën ping për të gjitha nyjet e pranishme në grup, mban një hartë të përditësuar të grupimit dhe e shpërndan atë midis nyjeve, përpunon logjikën e ngjarjeve dhe kryen lloje të ndryshme të mbajtjes së një grupi të gjerë.
Koordinues
Kryen një detyrë të vetme: pranon kërkesa për lexim ose shkrim nga klientët dhe drejton këtë trafik. Në rast se ka një kërkesë për shkrim, ka shumë të ngjarë, ai do të pyesë masterin se në cilin copëz të indeksit përkatës duhet ta vendosë dhe do ta ridrejtojë kërkesën më tej.
Nyja e të dhënave
Ruan të dhënat, kryen pyetje kërkimi që vijnë nga jashtë dhe kryen operacione në copëzat e vendosura në të.
graylog
Kjo është diçka si një shkrirje e Kibana me Logstash në një pirg ELK. Graylog kombinon një UI dhe një tubacion përpunimi të regjistrave. Nën kapuç, Graylog ka Kafka dhe Zookeeper, të cilat ofrojnë lidhje me Graylog si një grup. Graylog mund të ruajë memorien e regjistrave (Kafka) në rast se Elasticsearch nuk është i disponueshëm dhe të përsërisë kërkesat e pasuksesshme të leximit dhe shkrimit, të grupojë dhe shënojë regjistrat sipas rregullave të specifikuara. Ashtu si Logstash, Graylog ka funksionalitet për të modifikuar rreshtat përpara se t'i shkruani ato në Elasticsearch.
Për më tepër, Graylog ka një zbulim të integruar të shërbimit që lejon, bazuar në një nyje të disponueshme Elasticsearch, të marrë të gjithë hartën e grupit dhe ta filtojë atë nga një etiketë specifike, e cila bën të mundur drejtimin e kërkesave në kontejnerë të veçantë.
Vizualisht duket diçka si kjo:
Kjo është një pamje e ekranit nga një shembull specifik. Këtu ndërtojmë një histogram bazuar në pyetjen e kërkimit dhe shfaqim rreshtat përkatës.
Tregues
Duke iu rikthyer arkitekturës së sistemit, do të doja të ndalesha më në detaje se si e ndërtuam modelin e indeksit në mënyrë që të gjitha të funksionojnë si duhet.
Në diagramin e mësipërm, ky është niveli më i ulët: nyjet e të dhënave Elasticsearch.
Një indeks është një entitet i madh virtual i përbërë nga copëza Elasticsearch. Në vetvete, secila prej copave nuk është gjë tjetër veçse një indeks Lucene. Dhe çdo indeks Lucene, nga ana tjetër, përbëhet nga një ose më shumë segmente.
Gjatë projektimit, ne kuptuam se për të përmbushur kërkesat për shpejtësinë e leximit në një sasi të madhe të dhënash, ne duhej t'i "përhapnim" këto të dhëna në mënyrë të barabartë në nyjet e të dhënave.
Kjo rezultoi në faktin se numri i copëzave për indeks (me kopje) duhet të jetë rreptësisht i barabartë me numrin e nyjeve të të dhënave. Së pari, për të siguruar një faktor replikimi të barabartë me dy (d.m.th., ne mund të humbasim gjysmën e grupit). Dhe, së dyti, për të përpunuar kërkesat për lexim dhe shkrim në të paktën gjysmën e grupit.
Fillimisht përcaktuam kohën e ruajtjes si 30 ditë.
Shpërndarja e copëzave mund të paraqitet grafikisht si më poshtë:
I gjithë drejtkëndëshi gri i errët është një indeks. Sheshi i kuq i majtë në të është copëza kryesore, e para në indeks. Dhe katrori blu është një copëz kopje. Ato janë të vendosura në qendra të ndryshme të të dhënave.
Kur shtojmë një copë tjetër, ai shkon në qendrën e tretë të të dhënave. Dhe, në fund, marrim këtë strukturë, e cila bën të mundur humbjen e DC pa humbur konsistencën e të dhënave:
Rrotullimi i indekseve, d.m.th. duke krijuar një indeks të ri dhe duke fshirë më të vjetrin, e bëmë atë të barabartë me 48 orë (sipas modelit të përdorimit të indeksit: 48 orët e fundit kërkohen më shpesh).
Ky interval i rrotullimit të indeksit është për shkak të arsyeve të mëposhtme:
Kur një kërkesë kërkimi arrin në një nyje specifike të dhënash, atëherë, nga pikëpamja e performancës, është më fitimprurëse kur kërkohet një copëz, nëse madhësia e tij është e krahasueshme me madhësinë e kofshës së nyjës. Kjo ju lejon të mbani pjesën "e nxehtë" të indeksit në një grumbull dhe të përdorni shpejt atë. Kur ka shumë "pjesë të nxehta", shpejtësia e kërkimit të indeksit degradon.
Kur një nyje fillon të ekzekutojë një pyetje kërkimi në një copëz, ajo shpërndan një numër thread-sh të barabartë me numrin e bërthamave hiperthreading të makinës fizike. Nëse një pyetje kërkimi prek një numër të madh copëzash, atëherë numri i thread-ve rritet proporcionalisht. Kjo ka një ndikim negativ në shpejtësinë e kërkimit dhe ndikon negativisht në indeksimin e të dhënave të reja.
Për të siguruar vonesën e nevojshme të kërkimit, vendosëm të përdorim një SSD. Për të përpunuar shpejt kërkesat, makinat që strehonin këto kontejnerë duhej të kishin të paktën 56 bërthama. Shifra 56 u zgjodh si një vlerë e mjaftueshme me kusht që përcakton numrin e fijeve që Elasticsearch do të gjenerojë gjatë funksionimit. Në Elasitcsearch, shumë parametra të grupit të fijeve varen drejtpërdrejt nga numri i bërthamave të disponueshme, gjë që nga ana tjetër ndikon drejtpërdrejt në numrin e kërkuar të nyjeve në grup sipas parimit "më pak bërthama - më shumë nyje".
Si rezultat, ne zbuluam se mesatarisht një copëz peshon rreth 20 gigabajt dhe ka 1 copëza për indeks. Prandaj, nëse i rrotullojmë një herë në 360 orë, atëherë kemi 48 prej tyre. Çdo indeks përmban të dhëna për 15 ditë.
Qarqet e shkrimit dhe leximit të të dhënave
Le të kuptojmë se si regjistrohen të dhënat në këtë sistem.
Le të themi se vjen një kërkesë nga Graylog te koordinatori. Për shembull, ne duam të indeksojmë 2-3 mijë rreshta.
Koordinatori, pasi mori një kërkesë nga Graylog, pyet masterin: "Në kërkesën e indeksimit, ne specifikuam në mënyrë specifike një indeks, por në cilën copëza për ta shkruar nuk ishte specifikuar."
Masteri përgjigjet: "Shkruaje këtë informacion në numrin e copëzave 71", pas së cilës ai dërgohet drejtpërdrejt në nyjen përkatëse të të dhënave, ku ndodhet numri primar-shard 71.
Pas së cilës regjistri i transaksioneve kopjohet në një copë-kopje, e cila ndodhet në një qendër tjetër të dhënash.
Një kërkesë kërkimi arrin nga Graylog te koordinatori. Koordinatori e ridrejton atë sipas indeksit, ndërsa Elasticsearch shpërndan kërkesat midis primar-shard dhe replica-shard duke përdorur parimin round-robin.
180 nyjet përgjigjen në mënyrë të pabarabartë, dhe ndërkohë që ata përgjigjen, koordinatori po grumbullon informacione që tashmë janë "shkëputur" nga nyjet më të shpejta të të dhënave. Pas kësaj, kur të gjitha informacionet kanë mbërritur, ose kërkesa ka arritur një afat kohor, ajo i jep gjithçka direkt klientit.
I gjithë ky sistem mesatarisht përpunon pyetjet e kërkimit për 48 orët e fundit në 300-400 ms, duke përjashtuar ato pyetje me një gërshërë kryesore.
Lule me Elasticsearch: konfigurimi i Java
Për t'i bërë të gjitha të funksionojnë ashtu siç dëshironim fillimisht, kaluam një kohë shumë të gjatë duke korrigjuar një shumëllojshmëri të gjerë gjërash në grup.
Pjesa e parë e problemeve të zbuluara lidhej me mënyrën se si Java është para-konfiguruar si parazgjedhje në Elasticsearch.
Problemi një
Ne kemi parë një numër shumë të madh raportimesh që në nivelin Lucene, kur punët në sfond po ekzekutohen, bashkimet e segmentit Lucene dështojnë me një gabim. Në të njëjtën kohë, ishte e qartë në regjistrat se ky ishte një gabim OutOfMemoryError. Ne pamë nga telemetria që ijë ishte i lirë dhe nuk ishte e qartë pse ky operacion po dështonte.
Doli se bashkimet e indeksit Lucene ndodhin jashtë ijeve. Dhe kontejnerët janë mjaft të kufizuar për sa i përket burimeve të konsumuara. Vetëm grumbulli mund të futej në këto burime (vlera heap.size ishte përafërsisht e barabartë me RAM-in) dhe disa operacione jashtë grumbullit u rrëzuan me një gabim në ndarjen e memories nëse për ndonjë arsye nuk përshtateshin në ~500 MB që mbeti përpara kufirit.
Rregullimi ishte mjaft i parëndësishëm: sasia e RAM-it në dispozicion për kontejnerin u rrit, pas së cilës harruam se kishim edhe probleme të tilla.
Problemi dy
4-5 ditë pas nisjes së grupit, vumë re që nyjet e të dhënave filluan të bien periodikisht nga grupi dhe të futen në të pas 10-20 sekondash.
Kur filluam ta kuptonim, doli që kjo memorie e pandërprerë në Elasticsearch nuk kontrollohet në asnjë mënyrë. Kur i dhamë më shumë memorie kontejnerit, ne mundëm të mbushnim rezervat e drejtpërdrejta të tamponit me informacione të ndryshme dhe ai u fshi vetëm pasi GC-ja e qartë u lëshua nga Elasticsearch.
Në disa raste, ky operacion zgjati mjaft kohë dhe gjatë kësaj kohe grupi arriti ta shënonte këtë nyje si tashmë të dalë. Ky problem është përshkruar mirë .
Zgjidhja ishte si më poshtë: ne kufizuam aftësinë e Java për të përdorur pjesën më të madhe të kujtesës jashtë grumbullit për këto operacione. Ne e kufizuam atë në 16 gigabajt (-XX:MaxDirectMemorySize=16g), duke siguruar që GC eksplicite të thirrej shumë më shpesh dhe të përpunohej shumë më shpejt, duke mos e destabilizuar më grupin.
Problemi i tretë
Nëse mendoni se problemet me "nyjet që largohen nga grupi në momentin më të papritur" kanë mbaruar, gaboheni.
Kur konfiguruam punën me indekse, zgjodhëm mmapfs për të në copa të freskëta me segmentim të madh. Kjo ishte një gabim i madh, sepse kur përdorni mmapfs skedari vendoset në RAM dhe më pas ne punojmë me skedarin e hartuar. Për shkak të kësaj, rezulton se kur GC përpiqet të ndalojë temat në aplikacion, ne shkojmë në pikën e sigurt për një kohë shumë të gjatë, dhe gjatë rrugës për në të, aplikacioni nuk i përgjigjet kërkesave të zotit nëse është gjallë . Prandaj, master beson se nyja nuk është më e pranishme në grup. Pas kësaj, pas 5-10 sekondash, mbledhësi i plehrave punon, nyja merr jetë, hyn përsëri në grup dhe fillon të inicializojë copëzat. E gjithë kjo ndihej shumë si "produksioni që meritonim" dhe nuk ishte i përshtatshëm për asgjë serioze.
Për të hequr qafe këtë sjellje, fillimisht kaluam në niofs standarde, dhe më pas, kur migruam nga versioni i pestë i Elastic në të gjashtin, provuam hibridf, ku ky problem nuk u riprodhua. Mund të lexoni më shumë rreth llojeve të ruajtjes .
Problemi katër
Pastaj ishte një problem tjetër shumë interesant që e trajtuam për një kohë rekord. E kapëm për 2-3 muaj sepse modeli i saj ishte absolutisht i pakuptueshëm.
Ndonjëherë koordinatorët tanë shkonin në GC të plotë, zakonisht diku pas drekës dhe nuk ktheheshin më prej andej. Në të njëjtën kohë, gjatë regjistrimit të vonesës së GC, dukej kështu: gjithçka po shkon mirë, mirë, mirë, dhe pastaj papritmas gjithçka po shkon shumë keq.
Fillimisht menduam se kishim një përdorues të keq që po lëshonte një lloj kërkese që e nxori nga modaliteti i punës koordinatorin. Kemi regjistruar kërkesat për një kohë shumë të gjatë, duke u përpjekur të kuptojmë se çfarë po ndodhte.
Si rezultat, rezultoi se në momentin kur një përdorues lëshon një kërkesë të madhe dhe arrin te një koordinator specifik Elasticsearch, disa nyje përgjigjen më gjatë se të tjerët.
Dhe ndërsa koordinatori pret një përgjigje nga të gjitha nyjet, ai grumbullon rezultatet e dërguara nga nyjet që tashmë janë përgjigjur. Për GC, kjo do të thotë që modelet tona të përdorimit të grumbullit ndryshojnë shumë shpejt. Dhe GC që përdorëm nuk mund ta përballonte këtë detyrë.
E vetmja zgjidhje që gjetëm për të ndryshuar sjelljen e grupit në këtë situatë është migrimi në JDK13 dhe përdorimi i kolektorit të plehrave Shenandoah. Kjo e zgjidhi problemin, koordinatorët tanë pushuan së rrëzuari.
Këtu përfunduan problemet me Java dhe filluan problemet me gjerësinë e brezit.
"Berries" me Elasticsearch: xhiros
Problemet me xhiros nënkuptojnë që grupi ynë funksionon në mënyrë të qëndrueshme, por në kulmin e numrit të dokumenteve të indeksuar dhe gjatë manovrave, performanca është e pamjaftueshme.
Simptoma e parë e hasur: gjatë disa "shpërthimeve" në prodhim, kur një numër shumë i madh regjistrash gjenerohen papritmas, gabimi i indeksimit es_rejected_execution fillon të pulsojë shpesh në Graylog.
Kjo për faktin se thread_pool.write.queue në një nyje të dhënash, deri në momentin kur Elasticsearch është në gjendje të përpunojë kërkesën e indeksimit dhe të ngarkojë informacionin në copëzën në disk, është në gjendje të ruajë vetëm 200 kërkesa si parazgjedhje. Dhe ne Për këtë parametër flitet shumë pak. Tregohen vetëm numri maksimal i temave dhe madhësia e paracaktuar.
Sigurisht, ne shkuam ta kthenim këtë vlerë dhe zbuluam sa vijon: në mënyrë specifike, në konfigurimin tonë, deri në 300 kërkesa ruhen mjaft mirë në memorie, dhe një vlerë më e lartë është e mbushur me faktin që ne përsëri fluturojmë në Full GC.
Për më tepër, duke qenë se këto janë grupe mesazhesh që mbërrijnë brenda një kërkese, ishte e nevojshme të ndryshoni Graylog në mënyrë që të shkruante jo shpesh dhe në grupe të vogla, por në grupe të mëdha ose një herë në 3 sekonda nëse grupi ende nuk është i plotë. Në këtë rast, rezulton se informacioni që ne shkruajmë në Elasticsearch bëhet i disponueshëm jo në dy sekonda, por në pesë (që na përshtatet mjaft mirë), por numri i regjistrave që duhen bërë për të kaluar një pjesë të madhe. grumbulli i informacionit është zvogëluar.
Kjo është veçanërisht e rëndësishme në ato momente kur diçka është rrëzuar diku dhe raporton me furi për të, në mënyrë që të mos merrni një Elastic plotësisht të spamuar, dhe pas ca kohësh - nyjet Graylog që nuk funksionojnë për shkak të bllokimit të tamponëve.
Për më tepër, kur kishim të njëjtat shpërthime në prodhim, morëm ankesa nga programuesit dhe testuesit: në momentin kur ata vërtet kishin nevojë për këto shkrime, ato u jepeshin shumë ngadalë.
Filluan ta kuptonin. Nga njëra anë, ishte e qartë se si pyetjet e kërkimit ashtu edhe ato të indeksimit u përpunuan, në thelb, në të njëjtat makina fizike, dhe në një mënyrë ose në një tjetër do të kishte disa tërheqje.
Por kjo mund të anashkalohej pjesërisht për shkak të faktit se në versionet e gjashtë të Elasticsearch u shfaq një algoritëm që ju lejon të shpërndani pyetje midis nyjeve përkatëse të të dhënave jo sipas parimit të rastësishëm të rrumbullakët (kontejneri që bën indeksimin dhe mban primare- copëza mund të jetë shumë e zënë, nuk do të ketë asnjë mënyrë për t'u përgjigjur shpejt), por për ta përcjellë këtë kërkesë në një enë më pak të ngarkuar me një copë-kopje, e cila do të përgjigjet shumë më shpejt. Me fjalë të tjera, arritëm në use_adaptive_replica_selection: e vërtetë.
Fotografia e leximit fillon të duket kështu:
Kalimi në këtë algoritëm bëri të mundur përmirësimin e ndjeshëm të kohës së kërkimit në ato momente kur kishim një fluks të madh regjistrash për të shkruar.
Së fundi, problemi kryesor ishte heqja pa dhimbje e qendrës së të dhënave.
Çfarë donim nga grupi menjëherë pasi humbëm lidhjen me një DC:
- Nëse kemi një master aktual në qendrën e të dhënave të dështuar, atëherë ai do të zgjidhet përsëri dhe do të zhvendoset si një rol në një nyje tjetër në një DC tjetër.
- Masteri do të heqë shpejt të gjitha nyjet e paarritshme nga grupi.
- Bazuar në ato të mbetura, ai do të kuptojë: në qendrën e humbur të të dhënave kishim fragmente primare të tilla dhe të tilla, ai do të promovojë shpejt copëzat e kopjeve plotësuese në qendrat e mbetura të të dhënave dhe ne do të vazhdojmë të indeksojmë të dhënat.
- Si rezultat i kësaj, xhiroja e shkrimit dhe leximit të grupit do të degradohet gradualisht, por në përgjithësi gjithçka do të funksionojë, megjithëse ngadalë, por në mënyrë të qëndrueshme.
Siç doli, ne donim diçka të tillë:
Dhe ne morëm sa vijon:
Si ndodhi kjo?
Kur qendra e të dhënave ra, mjeshtri ynë u bë pengesa.
Pse?
Fakti është se master ka një TaskBatcher, i cili është përgjegjës për shpërndarjen e detyrave dhe ngjarjeve të caktuara në grup. Çdo dalje nga nyja, çdo promovim i një copëze nga replika në primare, çdo detyrë për të krijuar një copëz diku - e gjithë kjo shkon së pari te TaskBatcher, ku përpunohet në mënyrë sekuenciale dhe në një fill.
Në kohën e tërheqjes së një qendre të dhënash, doli që të gjitha nyjet e të dhënave në qendrat e të dhënave të mbijetuara e konsideruan detyrën e tyre të informonin masterin "ne kemi humbur filan copëza dhe nyje të tilla e të tilla".
Në të njëjtën kohë, nyjet e të dhënave të mbijetuara i dërguan të gjithë këtë informacion masterit aktual dhe u përpoqën të prisnin konfirmimin se ai e pranoi atë. Ata nuk e prisnin këtë, pasi mjeshtri i mori detyrat më shpejt se sa mund të përgjigjej. Nyjet mbaruan kërkesat e përsëritura, dhe mjeshtri në këtë kohë as nuk u përpoq t'u përgjigjej atyre, por u zhyt plotësisht në detyrën e renditjes së kërkesave sipas përparësisë.
Në formën e terminalit, rezultoi se nyjet e të dhënave dërguan spam masterin deri në pikën që ai shkoi në GC të plotë. Pas kësaj, roli ynë kryesor u zhvendos në një nyje tjetër, absolutisht e njëjta gjë ndodhi me të, dhe si rezultat grupi u shemb plotësisht.
Ne morëm matje dhe përpara versionit 6.4.0, ku kjo ishte rregulluar, mjaftonte që të nxirrnim njëkohësisht vetëm 10 nyje të dhënash nga 360 në mënyrë që të mbyllnim plotësisht grupin.
Dukej diçka si kjo:
Pas versionit 6.4.0, ku u ndreq ky gabim i tmerrshëm, nyjet e të dhënave ndaluan së vrari masterin. Por kjo nuk e bëri atë "më të zgjuar". Domethënë: kur nxjerrim 2, 3 ose 10 (çdo numër tjetër përveç njërit) nyje të dhënash, master merr një mesazh të parë që thotë se nyja A është larguar dhe përpiqet t'i tregojë nyjes B, nyjes C për këtë, nyjes D.
Dhe për momentin, kjo mund të trajtohet vetëm duke vendosur një afat kohor për përpjekjet për t'i treguar dikujt për diçka, e barabartë me rreth 20-30 sekonda, dhe kështu të kontrollohet shpejtësia e qendrës së të dhënave që lëviz jashtë grupit.
Në parim, kjo përshtatet me kërkesat që fillimisht iu paraqitën produktit përfundimtar si pjesë e projektit, por nga pikëpamja e "shkencës së pastër" kjo është një gabim. E cila, nga rruga, u rregullua me sukses nga zhvilluesit në versionin 7.2.
Për më tepër, kur një nyje e caktuar e të dhënave doli, doli se shpërndarja e informacionit rreth daljes së saj ishte më e rëndësishme sesa t'i thuash të gjithë grupit se kishte disa copëza primare në të (për të promovuar një copëz të kopjes në një të dhënë tjetër qendër në fillore, dhe në informacion mund të shkruhej mbi to).
Prandaj, kur gjithçka tashmë ka rënë, nyjet e të dhënave të lëshuara nuk shënohen menjëherë si bajate. Në përputhje me rrethanat, ne jemi të detyruar të presim derisa të gjitha ping-t të kenë kaluar në nyjet e të dhënave të lëshuara, dhe vetëm pas kësaj grupi ynë fillon të na thotë se atje, atje dhe atje duhet të vazhdojmë të regjistrojmë informacionin. Ju mund të lexoni më shumë për këtë .
Si rezultat, operacioni i tërheqjes së një qendre të dhënash sot na merr rreth 5 minuta gjatë orës së pikut. Për një kolos kaq të madh dhe të ngathët, ky është një rezultat mjaft i mirë.
Si rezultat, arritëm në vendimin e mëposhtëm:
- Ne kemi 360 nyje të dhënash me disqe 700 gigabajt.
- 60 koordinatorë për drejtimin e trafikut nëpër të njëjtat nyje të dhënash.
- 40 mjeshtra që kemi lënë si një lloj trashëgimie që nga versionet para 6.4.0 - për t'i mbijetuar tërheqjes së qendrës së të dhënave, ne ishim të përgatitur mendërisht të humbnim disa makineri në mënyrë që të garantoheshim të kishim një kuorum masterësh edhe në skenari më i keq
- Çdo përpjekje për të kombinuar rolet në një enë u përball me faktin se herët a vonë nyja do të thyhej nën ngarkesë.
- I gjithë grupi përdor një grumbull.madhësi prej 31 gigabajt: të gjitha përpjekjet për të zvogëluar madhësinë rezultuan ose në vrasjen e disa nyjeve në pyetjet e rënda të kërkimit me karakterin kryesor ose në marrjen e ndërprerësit në vetë Elasticsearch.
- Për më tepër, për të siguruar performancën e kërkimit, ne u përpoqëm të mbanim sa më të vogël numrin e objekteve në grup, në mënyrë që të përpunojmë sa më pak ngjarje të jetë e mundur në bllokimin që morëm në master.
Më në fund për monitorimin
Për t'u siguruar që e gjithë kjo funksionon siç synohet, ne monitorojmë sa vijon:
- Çdo nyje e të dhënave i raporton resë sonë se ekziston, dhe ka copëza të tilla e të tilla në të. Kur shuajmë diçka diku, grupi raporton pas 2-3 sekondash se në qendrën A kemi shuar nyjet 2, 3 dhe 4 - kjo do të thotë se në qendrat e tjera të të dhënave ne në asnjë rrethanë nuk mund t'i shuajmë ato nyje në të cilat ka vetëm një copëz. majtas.
- Duke ditur natyrën e sjelljes së mjeshtrit, ne shikojmë me shumë kujdes numrin e detyrave në pritje. Sepse edhe një detyrë e mbërthyer, nëse nuk mbaron në kohë, teorikisht në një situatë emergjente mund të bëhet arsyeja pse, për shembull, promovimi i një copëze kopje në fillore nuk funksionon, kjo është arsyeja pse indeksimi do të ndalojë së funksionuari.
- Ne i shikojmë gjithashtu me shumë vëmendje vonesat e grumbulluesve të plehrave, sepse tashmë kemi pasur vështirësi të mëdha me këtë gjatë optimizimit.
- Refuzon me fije për të kuptuar paraprakisht se ku është pengesa.
- Epo, metrikat standarde si grumbulli, RAM dhe I/O.
Kur ndërtoni monitorimin, duhet të merrni parasysh veçoritë e Thread Pool në Elasticsearch. përshkruan opsionet e konfigurimit dhe vlerat e paracaktuara për kërkimin dhe indeksimin, por është plotësisht i heshtur për thread_pool.management. Këto thread përpunojnë, në veçanti, pyetje si _cat/shards dhe të tjera të ngjashme, të cilat janë të përshtatshme për t'u përdorur kur shkruani monitorimin. Sa më i madh të jetë grupi, aq më shumë kërkesa të tilla ekzekutohen për njësi kohore dhe thread_pool.management i lartpërmendur jo vetëm që nuk paraqitet në dokumentacionin zyrtar, por gjithashtu kufizohet si parazgjedhje në 5 threads, të cilat asgjësohen shumë shpejt, pas i cili monitorim ndalon së punuari si duhet.
Ajo që dua të them në përfundim: ne ia dolëm! Ne ishim në gjendje t'u jepnim programuesve dhe zhvilluesve tanë një mjet që, pothuajse në çdo situatë, mund të sigurojë shpejt dhe me besueshmëri informacion për atë që po ndodh në prodhim.
Po, doli të ishte mjaft e ndërlikuar, por, megjithatë, ne arritëm t'i përshtatnim dëshirat tona në produktet ekzistuese, të cilat nuk duhej t'i rregullonim dhe t'i rishkruam vetë.
Burimi: www.habr.com