🥇Kluster Elasticsearch 200 TB+

Shumë njerëz janë përballur me Elasticsearch. Por çfarë ndodh kur doni ta përdorni për të ruajtur regjistra "shumë të mëdhenj"? Dhe gjithashtu për të mbijetuar pa dhimbje dështimin e ndonjë prej disa qendrave të të dhënave? Çfarë arkitekture duhet të zgjidhni dhe me çfarë grackash do të hasni?

Në Odnoklassniki, vendosëm të përdorim elasticsearch për të zgjidhur problemin tonë të menaxhimit të regjistrave, dhe tani po ndajmë përvojën tonë me Habr, duke mbuluar si arkitekturën ashtu edhe gabimet.

Unë jam Petr Zaitsev, administrator sistemesh në Odnoklassniki. Përpara kësaj, kam qenë edhe administrator, duke punuar me Manticore Search, Sphinx Search dhe Elasticsearch. Ndoshta, nëse del ndonjë motor tjetër kërkimi, ndoshta do të punoj edhe me të. Gjithashtu kontribuoj në një numër projektesh me burim të hapur në bazë vullnetare.

Kur u bashkova me Odnoklassniki-n, përmenda pa menduar në intervistën time se dija si të punoja me Elasticsearch. Pasi e mësova dhe përfundova disa detyra të thjeshta, më dhanë detyrën më të madhe të reformimit të sistemit të menaxhimit të regjistrave që ekzistonte në atë kohë.

Kërkesat

Kërkesat e sistemit u formuluan si më poshtë:

Graylog u zgjodh si frontend. Kompania kishte përvojë tashmë në përdorimin e këtij produkti; programuesit dhe testuesit ishin të njohur me të, dhe ishte i përshtatshëm dhe i rehatshë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 është i pakufizuar, mund të jetë 2-3 milion rreshta në sekondë
Pasi diskutuam me klientët tanë kërkesat e shpejtësisë së përpunimit të pyetjeve të kërkimit, kuptuam se modeli tipik i përdorimit për një sistem të tillë është si më poshtë: njerëzit kërkojnë në regjistrat e aplikacioneve të tyre gjatë dy ditëve të fundit dhe nuk duan të presin më shumë se një sekondë që të kthehet një rezultat.
Administratorët këmbëngulën që sistemi të ishte lehtësisht i shkallëzueshëm nëse ishte e nevojshme, pa kërkuar që ata të kishin një kuptim të thellë se si funksionon.
Kështu që e vetmja detyrë mirëmbajtjeje që këto sisteme kërkojnë periodikisht është zëvendësimi i disa pajisjeve.
Për më tepër, Odnoklassniki ka një traditë të mrekullueshme teknike: çdo shërbim që lançojmë 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 kushtoi më shumë gjak, për të cilën do të flas më hollësisht më vonë.

E mërkurë

Ne operojmë në katër qendra të dhënash, por nyjet e të dhënave Elasticsearch mund të gjenden vetëm në tre (për një numër arsyesh jo-teknike).

Këto katër qendra të dhënash përmbajnë afërsisht 18 burime të ndryshme regjistrash - pajisje, kontejnerë dhe makina virtuale.

Një veçori e rëndësishme: klasteri lançohet në kontejnerë podman jo në makina fizike, por në produkt vetanak cloud one-cloudKontejnerët kanë të garantuara dy bërthama, ekuivalente me 2.0Ghz v4, me mundësinë për të përdorur bërthamat e mbetura nëse janë në gjendje të papërdorur.

Me fjalë të tjera:

Topologji

Forma e përgjithshme e zgjidhjes fillimisht më dukej si më poshtë:

3-4 persona VIP janë pas regjistrimit A të domenit Graylog, i cili është adresa ku dërgohen regjistrimet.
Çdo VIP është një balancues i LVS.
Pas kësaj, regjistrat dërgohen në baterinë Graylog, disa nga të dhënat janë në formatin GELF, disa në formatin syslog.
Pastaj e gjithë kjo shkruhet në grupe të mëdha për një bateri koordinatorësh Elasticsearch.
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ë do të doja të ndalem pak në të.

Elasticsearch ka disa lloje nyjesh: kryesore, koordinatore dhe nyje të dhënash. Ekzistojnë dy lloje të tjera për transformime të ndryshme log dhe për lidhjen e klasterave të ndryshëm, por ne përdorëm vetëm ato të listuara.

Mjeshtër
Bën ping-un e të gjitha nyjeve të pranishme në klaster, mirëmban një hartë të klasterit të azhurnuar dhe e shpërndan atë midis nyjeve, përpunon logjikën e ngjarjeve dhe kryen lloje të ndryshme të mirëmbajtjes në të gjithë klasterin.

Koordinues
Kryen një detyrë të vetme: pranimin e kërkesave për lexim ose shkrim nga klientët dhe drejtimin e këtij trafiku. Nëse kërkesa është një shkrim, ka shumë të ngjarë që t'i kërkojë masterit se në cilin shard të indeksit përkatës ta vendosë atë dhe ta përçojë kërkesën më tej.

Nyja e të dhënave
Ruan të dhëna, ekzekuton pyetje kërkimi që vijnë nga jashtë dhe kryen operacione në shard-et e vendosura në të.

graylog
Është si një bashkim i Kibana dhe Logstash në një pirg ELK. Graylog kombinon si ndërfaqen e përdoruesit ashtu edhe tubacionin e përpunimit të regjistrave. Në brendësi, Graylog përdor Kafka dhe Zookeeper, të cilët sigurojnë kohezionin e grupeve Graylog. Graylog mund të ruajë në memorje regjistrat (Kafka) në rast se Elasticsearch nuk është i disponueshëm, të riprovojë kërkesat e dështuara për lexim dhe shkrim, si dhe të grupojë dhe etiketojë regjistrat sipas rregullave të personalizuara. Ashtu si Logstash, Graylog ka aftësinë të modifikojë vargjet para se të shkruajë në Elasticsearch.

Graylog gjithashtu ka zbulimin e shërbimit të integruar, i cili ju lejon të merrni të gjithë hartën e klasterit nga një nyje e vetme Elasticsearch e disponueshme dhe ta filtroni atë me një etiketë specifike, duke ju lejuar të drejtoni pyetjet në kontejnerë specifikë.

Vizualisht duket diçka si kjo:

Kjo është një pamje e ekranit nga një rast specifik. Këtu, po ndërtojmë një histogram bazuar në një pyetje kërkimi dhe po shfaqim rreshtat përkatës.

Tregues

Duke u kthyer te arkitektura e sistemit, do të doja të ndalem më në detaje se si e ndërtuam modelin e indeksit në mënyrë që gjithçka të funksionojë siç duhet.

Në diagramin më sipër, ky është niveli më i ulët: nyjet e të dhënave Elasticsearch.

Një indeks është një entitet i madh virtual që përbëhet nga copëza Elasticsearch. Çdo copëz në vetvete 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ë copëza.

Gjatë projektimit, ne supozuam se për të përmbushur kërkesën e shpejtësisë së leximit për një vëllim të madh të dhënash, do të na duhej t'i shpërndanim këto të dhëna në mënyrë të barabartë nëpër nyjet e të dhënave.

Kjo do të thotë që numri i shard-eve 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 prej dy (që do të thotë se mund të humbasim gjysmën e klasterit). Së dyti, për të siguruar që kërkesat për lexim dhe shkrim të përpunohen nga të paktën gjysma e klasterit.

Fillimisht e përcaktuam kohën e ruajtjes si 30 ditë.

Shpërndarja e copëzave mund të përfaqësohet grafikisht si më poshtë:

I gjithë drejtkëndëshi gri i errët është indeksi. Katrori i kuq në të majtë është shard-i kryesor, shard-i i parë në indeks. Dhe katrori blu është shard-i replikë. Ato ndodhen në qendra të ndryshme të dhënash.

Kur shtojmë një copë tjetër, ajo zhvendoset në një qendër të tretë të të dhënave. Në fund të fundit, marrim një strukturë që lejon humbjen e një qendre të dhënash pa humbur qëndrueshmërinë e të dhënave:

Ne e caktojmë rotacionin e indeksit, d.m.th. krijimin e një indeksi të ri dhe fshirjen e atij më të vjetrit, në 48 orë (bazuar në modelin e përdorimit të indeksit: 48 orët e fundit kërkohen më shpesh).

Ky interval rrotullimi i indeksit është për shkak të arsyeve të mëposhtme:

Kur një pyetje kërkimi mbërrin në një nyje specifike të dhënash, është më efikase nga perspektiva e performancës të kërkohet një copë e vetme nëse madhësia e saj është e krahasueshme me grumbullin e nyjes. Kjo e mban pjesën "e nxehtë" të indeksit në grumbull dhe lejon akses të shpejtë. Kur ka shumë pjesë "e nxehtë", performanca e kërkimit të indeksit përkeqësohet.

Kur një nyje fillon të ekzekutojë një pyetje kërkimi në një shard të vetëm, ajo ndan një numër thread-esh të barabartë me numrin e bërthamave të hyperthreading në makinën fizike. Nëse pyetja e kërkimit përfshin shard-e të shumta, numri i thread-eve rritet në mënyrë proporcionale. Kjo ndikon negativisht në performancën e kërkimit dhe ndikon negativisht në indeksimin e të dhënave të reja.

Për të siguruar vonesën e kërkuar të kërkimit, vendosëm të përdornim SSD. Për të përpunuar shpejt pyetjet, makinat që strehonin këto kontejnerë kishin nevojë për të paktën 56 bërthama. Shifra prej 56 u zgjodh si një vlerë e arsyeshme, duke përcaktuar numrin e fijeve që Elasticsearch do të krijonte gjatë funksionimit. Në Elasticsearch, 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ë grumbull, bazuar në parimin "më pak bërthama = më shumë nyje".

Si rezultat, zbuluam se një copëz mesatare peshon rreth 20 gigabajt, dhe ka 360 copëza për indeks. Prandaj, nëse i rrotullojmë çdo 48 orë, kemi 15 prej tyre. Çdo indeks përmban të dhëna me vlerë dy ditë.

Skemat e shkrimit dhe leximit të të dhënave

Le të shohim se si regjistrohen të dhënat në këtë sistem.

Le të themi se marrim një pyetje nga Graylog drejtuar koordinatorit. Për shembull, duam të indeksojmë 2-3 rreshta.

Koordinatori, pasi ka marrë një kërkesë nga Graylog, i kërkon masterit: "Në kërkesën e indeksimit, ne specifikuam posaçërisht indeksin, por në cilin shard do ta shkruanim nuk u specifikua."

Masteri përgjigjet: "Shkruaje këtë informacion në copën numër 71", pas së cilës dërgohet direkt në nyjen përkatëse të të dhënave, ku ndodhet copëza kryesore numër 71.

Pas kësaj, regjistri i transaksioneve replikohet në replica-shard, i cili ndodhet në një qendër tjetër të dhënash.

Një pyetje kërkimi mbërrin nga Graylog te koordinatori. Koordinatori e kalon atë përmes indeksit dhe Elasticsearch shpërndan pyetjet midis shard-it primar dhe shard-it replikë duke përdorur një parim round-robin.

180 nyjet përgjigjen në mënyrë të pabarabartë, dhe ndërsa ato përgjigjen, koordinatori grumbullon informacionin që tashmë "nxirret" nga nyjet më të shpejta të të dhënave. Më pas, kur të gjitha informacionet kanë mbërritur ose kërkesa skadon, ai ia dorëzon gjithçka direkt klientit.

I gjithë ky sistem përpunon pyetjet e kërkimit për 48 orët e fundit në mesatarisht 300-400ms, duke përjashtuar ato pyetje me një wildcard kryesor.

Elasticsearch: Konfigurimi i Java-s

Që gjithçka të funksiononte ashtu siç dëshironim fillimisht, kaluam shumë kohë duke debuguar një gamë të gjerë gjërash në klaster.

Grupi i parë i problemeve të zbuluara lidhej me mënyrën se si Java konfigurohet si parazgjedhje në Elasticsearch.

Problemi një
Po shihnim një numër të madh raportesh që bashkimet e segmenteve Lucene po dështonin kur punët në sfond po ekzekutoheshin në shtresën tonë Lucene. Regjistrat treguan se ky ishte një gabim OutOfMemoryError. Telemetria tregoi se grumbulli ishte i lirë, por nuk ishte e qartë pse ky operacion po dështonte.

Doli që bashkimet e indeksit Lucene po ndodhnin jashtë heap-it. Dhe kontejnerët ishin mjaft të kufizuar në konsumin e burimeve të tyre. Vetëm heap-i përshtatej (vlera heap.size ishte afërsisht e barabartë me RAM-in), dhe disa operacione jashtë heap-it dështuan me gabime të alokimit të memories nëse për ndonjë arsye ato nuk përshtateshin brenda limitit të mbetur prej ~500MB.

Zgjidhja ishte mjaft e thjeshtë: rritëm sasinë e RAM-it në dispozicion të kontejnerit dhe pastaj harruam se kishim probleme të tilla që në fillim.

Problemi dy
Rreth 4-5 ditë pas lançimit të klasterit, vumë re se nyjet e të dhënave filluan të dilnin periodikisht nga klasteri dhe të rihynin në të çdo 10-20 sekonda.

Kur e hulumtuam çështjen, doli që memoria jashtë heap-it në Elasticsearch është praktikisht e pakontrollueshme. Kur i caktuam më shumë memorie kontejnerit, ishim në gjendje të mbushnim rezervat e memorjes direkte me të dhëna të ndryshme, dhe kjo u pastrua vetëm pasi Elasticsearch ekzekutoi GC të qartë.

Në disa raste, ky operacion zgjati mjaft shumë dhe gjatë kësaj kohe, klasteri arriti ta shënonte nyjen si të mbyllur tashmë. Ky problem është përshkruar mirë. këtu.

Zgjidhja ishte kjo: ne kufizuam aftësinë e Java-s për të përdorur pjesën më të madhe të memories jo-heap për këto operacione. Ne e kufizuam atë në 16 gigabajt (-XX:MaxDirectMemorySize=16g), duke siguruar që GC-ja eksplicite të thirrej dukshëm më shpesh dhe të përfundonte dukshëm më shpejt, duke eliminuar kështu destabilizimin e grumbullimit.

Problemi tre
Nëse mendoni se problemet me "nyjet që largohen nga klasteri në momentin më të papritur" përfunduan këtu, gaboheni.

Kur konfiguruam punën me indekse, zgjodhëm mmapfs në mënyrë që zvogëloni kohën e kërkimit Në shard-e të freskëta me segmentim të lartë. Ky ishte një gabim mjaft serioz, sepse kur përdoret mmapfs, skedari lidhet me RAM-in dhe më pas ne punojmë me skedarin e lidhur. Për shkak të kësaj, kur GC përpiqet të ndalojë fijet në aplikacion, i duhet shumë kohë për të arritur në pikën e sigurt dhe gjatë rrugës, aplikacioni ndalon së iu përgjigjur pyetjeve të masterit nëse është aktiv. Si pasojë, masteri supozon se nyja nuk është më e pranishme në klaster. Pas 5-10 sekondash, mbledhësi i mbeturinave ekzekutohet, nyja rikthehet në jetë, ribashkohet me klasterin dhe fillon inicializimin e shard-eve. E gjithë kjo i ngjante fort "prodhimit që meritojmë" dhe ishte e papërshtatshme për asgjë serioze.

Për të hequr qafe këtë sjellje, së pari kaluam në niof-et standarde dhe më pas, kur migruam nga Elastic 5 në 6, provuam hybridfs, ku ky problem nuk u riprodhua. Mund të lexoni më shumë rreth llojeve të ruajtjes këtu. këtu.

Problemi katër
Pastaj pati një problem tjetër shumë interesant, të cilin e trajtuam për një kohë rekord. Po përpiqeshim ta kapnim për dy ose tre muaj sepse modeli i tij ishte plotësisht i paqartë.

Ndonjëherë koordinatorët tanë kalonin në modalitetin e plotë GC, zakonisht rreth kohës së drekës, dhe nuk ktheheshin më kurrë. Kur regjistrohej vonesa e GC, dukej kështu: gjithçka po shkonte mirë, mirë, mirë, dhe pastaj papritmas - gjithçka shkoi keq.

Në fillim, menduam se kishim një përdorues mashtrues që po ekzekutonte një lloj pyetjeje që po e nxirrte koordinatorin jashtë funksionit. Ne kaluam një kohë të gjatë duke regjistruar pyetjet, duke u përpjekur të kuptonim se çfarë po ndodhte.

Ajo që zbuluam ishte se kur një përdorues lëshon një pyetje të madhe dhe ajo godet një koordinator specifik Elasticsearch, disa nyje kërkojnë më shumë kohë për t'u përgjigjur sesa të tjerat.

Ndërsa koordinatori pret që të gjitha nyjet të përgjigjen, ai grumbullon rezultatet e dërguara nga nyjet që kanë përgjigjur tashmë. Për GC-në, kjo do të thotë që modeli ynë i përdorimit të grumbullit ndryshon shumë shpejt. Dhe GC-ja që po përdornim nuk mund ta përballonte këtë.

E vetmja zgjidhje që gjetëm për të ndryshuar sjelljen e klasterit në këtë situatë ishte migrimi në JDK13 dhe përdorimi i mbledhësit të mbeturinave Shenandoah. Kjo e zgjidhi problemin dhe koordinatorët tanë ndaluan së funksionuari pa sukses.

Këtu përfunduan problemet me Java-n dhe filluan problemet me gjerësinë e brezit.

"Manaferrat" e Elasticsearch: Produktiviteti

Problemet me rendimentin nënkuptojnë që klasteri ynë është i qëndrueshëm, por performanca është e pamjaftueshme gjatë kulmeve në numrin e dokumenteve të indeksuara dhe gjatë manovrave.

Simptoma e parë që hasa: gjatë një lloj "shpërthimi" në prodhim, kur një numër shumë i madh i regjistrave gjenerohen papritmas, gabimi i indeksimit es_rejected_execution fillon të ndizet shpesh në Graylog.

Kjo për shkak të faktit se thread_pool.write.queue në një nyje të dhënash, si parazgjedhje, mund të ruajë në memorje vetëm 200 kërkesa derisa Elasticsearch të jetë në gjendje të përpunojë kërkesën e indeksimit dhe të shkruajë informacionin në shard në disk. Dhe në Dokumentacioni i Elasticsearch Shumë pak thuhet për këtë parametër. Specifikohet vetëm numri maksimal i fijeve dhe madhësia e parazgjedhur.

Natyrisht, filluam të luanim me këtë vlerë dhe zbuluam sa vijon: në konfigurimin tonë të veçantë, deri në 300 kërkesa ruhen mjaft mirë në memorien e përkohshme, dhe një vlerë më e lartë na rrezikon të biem përsëri në Full GC.

Për më tepër, meqenëse këto janë grupe mesazhesh që mbërrijnë brenda një kërkese të vetme, Graylog duhej të përmirësohej në mënyrë që të mos shkruante shpesh dhe në grupe të vogla, por në grupe të mëdha ose çdo tre sekonda nëse grupi nuk ishte i plotë. Kjo do të thotë që informacioni që shkruajmë në Elasticsearch bëhet i disponueshëm në pesë sekonda në vend të dy (gjë që është krejtësisht e pranueshme), por gjithashtu zvogëlon numrin e ripërpjekjeve të nevojshme për të mbushur një grup të madh informacioni.

Kjo është veçanërisht e rëndësishme në ato momente kur diçka diku është rrëzuar dhe po e raporton me tërbim, në mënyrë që të mos përfundojë me një Elastic plotësisht të mbushur me spam, dhe pas një kohe, nyje Graylog që janë të paoperueshme për shkak të buffer-ave të bllokuara.

Për më tepër, kur patëm këto shpërthime në prodhim, morëm ankesa nga programuesit dhe testuesit: në momentin kur ata me të vërtetë kishin nevojë për këto regjistra, ato u jepeshin shumë ngadalë.

Ne filluam ta shqyrtonim çështjen. Nga njëra anë, ishte e qartë se si pyetjet e kërkimit ashtu edhe kërkesat e indeksimit përpunoheshin në thelb në të njëjtat makina fizike dhe, në një mënyrë ose në një tjetër, do të kishte disa rënie të performancës.

Por kjo mund të anashkalohet pjesërisht nga futja e një algoritmi në versionet 6 të Elasticsearch që shpërndan kërkesat midis nyjeve të të dhënave përkatëse jo rastësisht, duke përdorur një qasje round-robin (kontejneri i indeksimit që mban shard-in primar mund të jetë shumë i zënë dhe i paaftë të përgjigjet shpejt), por në vend të kësaj e drejton kërkesën në një kontejner më pak të ngarkuar që mban shard-in replikë, i cili do të përgjigjet dukshëm më shpejt. Me fjalë të tjera, arritëm në use_adaptive_replica_selection: true.

Fotografia e leximit fillon të duket kështu:

Kalimi në këtë algoritëm na lejoi të përmirësonim ndjeshëm kohën e pyetjeve gjatë atyre kohërave kur kishim një fluks të madh regjistrash për të shkruar.

Së fundmi, problemi kryesor ishte heqja pa dhimbje e qendrës së të dhënave.

Çfarë donim nga klasteri menjëherë pas humbjes së lidhjes me një qendër të dhënash:

Nëse kemi një master aktual në një qendër të dhënash të dështuar, ai do të rizgjidhet dhe do të zhvendoset si rol në një nyje tjetër në një DC tjetër.
Masteri do të përjashtojë shpejt të gjitha nyjet e padisponueshme nga klasteri.
Bazuar në të dhënat e mbetura, ai do të kuptojë: në qendrën e të dhënave të humbura kishim copëza primare të tilla e të tilla, ai do të promovojë shpejt copëza kopje plotësuese në qendrat e të dhënave të mbetura, dhe ne do të vazhdojmë indeksimin e të dhënave.
Si rezultat, do të përjetojmë një degradim gradual të shpejtësisë së shkrimit dhe leximit të klasterit, 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 morëm sa vijon:

Si ndodhi kjo?

Kur qendra e të dhënave u rrëzua, masteri ynë u bë pengesa kryesore.

Pse?

Çështja është se masteri ka një TaskBatcher, i cili është përgjegjës për shpërndarjen e detyrave dhe ngjarjeve specifike në të gjithë klasterin. Çdo dalje nga nyja, çdo promovim i një shard nga replika në primare, çdo detyrë për të krijuar një shard diku - e gjithë kjo shkon së pari në TaskBatcher, ku përpunohet në mënyrë sekuenciale dhe në një fije të vetme.

Kur një qendër të dhënash u shkatërrua, doli që të gjitha nyjet e të dhënave në qendrat e të dhënave që kishin mbijetuar e konsideronin detyrë të tyre të informonin kryesuesin: “Kemi humbur copëza të tilla dhe nyje të tilla të dhënash”.

Ndërkohë, nyjet e të dhënave që mbijetuan ia dërguan të gjithë këtë informacion masterit aktual dhe u përpoqën të prisnin për konfirmim se ai e kishte pranuar atë. Ata nuk pritën, pasi masteri i merrte detyrat më shpejt sesa mund të përgjigjej. Nyjet skaduan dhe përsëritën kërkesat, ndërsa masteri as nuk u përpoq më të përgjigjej, duke qenë plotësisht i zhytur në renditjen e kërkesave sipas përparësisë.

Në terminal, doli që nyjet e të dhënave po i dërgonin mesazhe të padëshiruara masterit derisa ai të kalonte në GC të plotë. Pas kësaj, roli i masterit do të zhvendosej në ndonjë nyje tjetër, e cila do të përjetonte saktësisht të njëjtën gjë dhe në fund klasteri do të shembej plotësisht.

Ne morëm matje, dhe para versionit 6.4.0, ku kjo u rregullua, mjaftonte që ne të hiqnim njëkohësisht vetëm 10 nyje të dhënash nga 360 në mënyrë që ta shkatërronim plotësisht grumbullin.

Duket diçka si kjo:

Pas versionit 6.4.0, i cili rregulloi këtë gabim të keq, nyjet e të dhënave ndaluan së funksionuari si master. Por kjo nuk e bëri atë aspak "më të zgjuar". Në mënyrë specifike, kur nxjerrim 2, 3 ose 10 (çdo numër tjetër përveç një) nyje të dhënash, masteri merr një mesazh fillestar që tregon se nyja A ka dalë dhe përpiqet të njoftojë nyjen B, nyjen C dhe nyjen D për këtë.

Dhe për momentin, e vetmja mënyrë për ta luftuar këtë është duke vendosur një kohëzgjatje për përpjekjet për t'i thënë dikujt diçka, të barabartë me diku rreth 20-30 sekonda, dhe kështu të kontrollohet shpejtësia me të cilën qendra e të dhënave hiqet nga klasteri.

Në parim, kjo përmbush kërkesat e përcaktuara fillimisht për produktin përfundimtar brenda projektit, por nga një perspektivë thjesht shkencore, është një gabim. Rastësisht, u rregullua me sukses nga zhvilluesit në versionin 7.2.

Për më tepër, kur një nyje e caktuar e të dhënave ra, doli që shpërndarja e informacionit në lidhje me daljen e saj ishte më e rëndësishme sesa t'i tregohej të gjithë klasterit se copëza të tilla primare ndodheshin në të (me qëllim që copëza replika në një qendër tjetër të dhënash të promovohej në atë primare, dhe informacioni mund të shkruhej në to).

Prandaj, pasi gjithçka të jetë qetësuar, nyjet e të dhënave të dala nuk shënohen menjëherë si të vjetra. Si pasojë, ne jemi të detyruar të presim derisa të gjitha ping-et në nyjet e të dhënave të dala të kenë skaduar, dhe vetëm atëherë klasteri ynë fillon të sinjalizojë se regjistrimi i të dhënave duhet të vazhdojë në një vendndodhje të caktuar. Mund të lexoni më shumë rreth kësaj këtu. këtu.

Si rezultat, operacioni i çmontimit të qendrës sonë të të dhënave aktualisht zgjat rreth 5 minuta gjatë orëve të pikut. Për një makinë kaq të madhe dhe të vështirë për t'u përdorur, 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ë të dhënave.
40 master-ët që kishim si një lloj trashëgimie nga versionet para 6.4.0—për t'i mbijetuar mbylljes së qendrës së të dhënave, ishim të përgatitur mendërisht të humbisnim disa makina për t'u siguruar që edhe në skenarin më të keq do të kishim një kuorum master-ësh.
Çdo përpjekje për të kombinuar rolet në një enë të vetme përfundoi me nyjen që përfundimisht u prish nën ngarkesë.
I gjithë klasteri përdor një heap.size prej 31 gigabajtësh: të gjitha përpjekjet për të zvogëluar madhësinë rezultuan në pyetje të shumta kërkimi me wildcards kryesore që ose shkatërruan disa nyje ose shkaktuan një ndërprerës qarku në vetë Elasticsearch.
Për më tepër, për të siguruar performancën e kërkimit, u përpoqëm ta mbanim numrin e objekteve në grumbull sa më të ulët të ishte e mundur, në mënyrë që të përpunonim sa më pak ngjarje të ishte e mundur në ngushticën që kishim në master.

Së fundmi, në lidhje me monitorimin

Për t'u siguruar që e gjithë kjo funksionon siç është menduar, ne monitorojmë sa vijon:

Çdo nyje të dhënash i raporton resë sonë se ekziston dhe se përmban shard-e të caktuara. Kur mbyllim diçka diku, klasteri raporton brenda 2-3 sekondave se në qendrën A kemi mbyllur nyjet 2, 3 dhe 4 - kjo do të thotë se në qendrat e tjera të të dhënave, absolutisht nuk mund t'i mbyllim nyjet që kanë vetëm një shard të mbetur.
Duke ditur modelet e sjelljes së masterit, ne i kushtojmë vëmendje të madhe numrit të detyrave në pritje. Sepse edhe një detyrë e bllokuar, nëse nuk skadon në kohë, në rast urgjence mund të parandalojë potencialisht, për shembull, promovimin e një shard-i replikë në atë kryesor, gjë që do të pengonte indeksimin.
Gjithashtu i kushtojmë vëmendje të madhe vonesës së mbledhësit të mbeturinave, pasi kemi pasur vështirësi të konsiderueshme me këtë në të kaluarën gjatë optimizimit.
Refuzon me fije për të kuptuar paraprakisht se ku është pengesa.
Epo, dhe metrika standarde, të tilla si heap, RAM dhe I/O.

Kur ndërtoni monitorim, është e rëndësishme të merren në konsideratë veçoritë e Thread Pool në Elasticsearch. Dokumentacioni Elasticsearch Ai përshkruan opsionet e konfigurimit dhe vlerat parazgjedhura për kërkimin dhe indeksimin, por nuk flet fare për thread_pool.management. Këto fije trajtojnë, ndër të tjera, pyetje si _cat/shards dhe të tjera të ngjashme, të cilat janë të përshtatshme për monitorimin e shkrimit. Sa më i madh të jetë klasteri, aq më shumë pyetje të tilla ekzekutohen për njësi të kohës, dhe thread_pool.management i lartpërmendur jo vetëm që nuk paraqitet në dokumentacionin zyrtar, por është gjithashtu i kufizuar si parazgjedhje në pesë fije, të cilat përdoren shpejt, pas së cilës monitorimi ndalon së funksionuari siç duhet.

Si përfundim, ia kemi dalë mbanë! U kemi ofruar programuesve dhe zhvilluesve tanë një mjet që mund të ofrojë shpejt dhe me besueshmëri informacion rreth asaj që po ndodh në prodhim në pothuajse çdo situatë.

Po, doli të ishte mjaft e vështirë, por megjithatë, arritëm t'i përshtasim dëshirat tona në produktet ekzistuese, të cilat nuk kërkonin rregullime ose rishkrime.