Daugelis žmonių kovoja su Elasticsearch. Bet kas nutinka, kai norite jį naudoti rąstų saugojimui „ypač dideliu kiekiu“? Ar taip pat neskausminga patirti kurio nors iš kelių duomenų centrų gedimą? Kokią architektūrą turėtumėte sukurti ir į kokias spąstus susidursite?
Mes, Odnoklassniki, nusprendėme naudoti elasticsearch, kad išspręstume rąstų valdymo problemą, o dabar dalijamės savo patirtimi su Habru: tiek apie architektūrą, tiek apie spąstus.
Esu Piotras Zaicevas, dirbu sistemos administratoriumi Odnoklassniki. Prieš tai taip pat buvau admin, dirbau su Manticore Search, Sphinx search, Elasticsearch. Galbūt, jei atsiras kita ...paieška, tikriausiai ir aš su ja dirbsiu. Taip pat savanoriškai dalyvauju daugelyje atvirojo kodo projektų.
Kai atvykau į „Odnoklassniki“, interviu metu neapgalvotai pasakiau, kad galėčiau dirbti su „Elasticsearch“. Įpratau ir atlikau keletą paprastų užduočių, gavau didelę užduotį reformuoti tuo metu egzistavusią žurnalų valdymo sistemą.
Reikalavimai
Sistemos reikalavimai buvo suformuluoti taip:
- Graylog turėjo būti naudojamas kaip priekinė dalis. Kadangi įmonė jau turėjo patirties naudojant šį produktą, programuotojai ir testuotojai tai žinojo, jiems tai buvo pažįstama ir patogu.
- Duomenų apimtis: vidutiniškai 50-80 tūkstančių pranešimų per sekundę, bet jei kažkas sugenda, tai srauto niekas neriboja, gali būti 2-3 milijonai eilučių per sekundę
- Aptarę su klientais paieškos užklausų apdorojimo spartos reikalavimus, supratome, kad įprastas tokios sistemos naudojimo modelis yra toks: žmonės ieško pastarųjų dviejų dienų savo programos žurnalų ir nenori laukti ilgiau nei antrasis suformuluotos užklausos rezultatui.
- Administratoriai reikalavo, kad prireikus sistema būtų lengvai keičiama, nereikalaujant, kad jie gilintųsi į jos veikimą.
- Vienintelė priežiūros užduotis, kurios reikia periodiškai šioms sistemoms, yra tam tikros aparatinės įrangos keitimas.
- Be to, Odnoklassniki turi puikias technines tradicijas: bet kuri paslauga, kurią paleidžiame, turi išgyventi duomenų centro gedimą (staigų, neplanuotą ir absoliučiai bet kuriuo metu).
Labiausiai mums kainavo paskutinis reikalavimas įgyvendinant šį projektą, apie kurį pakalbėsiu plačiau.
Trečiadienis
Dirbame keturiuose duomenų centruose, o Elasticsearch duomenų mazgai gali būti tik trijuose (dėl daugelio netechninių priežasčių).
Šiuose keturiuose duomenų centruose yra apie 18 tūkstančių skirtingų žurnalų šaltinių – techninės įrangos, konteinerių, virtualių mašinų.
Svarbi savybė: klasteris prasideda konteineriuose ne fizinėse mašinose, o ant . Konteineriams garantuojami 2 branduoliai, panašūs į 2.0 GHz v4, su galimybe perdirbti likusius branduolius, jei jie neveikia.
Kitaip tariant:
Topologija
Iš pradžių aš pamačiau bendrą sprendimo formą taip:
- 3-4 VIP yra už Graylog domeno A įrašo, tai yra adresas, kuriuo siunčiami žurnalai.
- kiekvienas VIP yra LVS balansuotojas.
- Po jo žurnalai patenka į Graylog bateriją, dalis duomenų yra GELF formatu, dalis syslog formatu.
- Tada visa tai didelėmis partijomis įrašoma į Elasticsearch koordinatorių bateriją.
- Ir jie savo ruožtu siunčia rašymo ir skaitymo užklausas į atitinkamus duomenų mazgus.
terminologija
Galbūt ne visi išsamiai supranta terminiją, todėl norėčiau prie jos šiek tiek pasilikti.
Elasticsearch turi kelių tipų mazgus – pagrindinį, koordinatorių, duomenų mazgą. Yra dar du tipai, skirti skirtingoms žurnalų transformacijoms ir bendravimui tarp skirtingų grupių, tačiau mes naudojome tik išvardytus.
Meistras
Jis ping nusiunčia visus klasteryje esančius mazgus, palaiko atnaujintą klasterio žemėlapį ir paskirsto jį tarp mazgų, apdoroja įvykių logiką ir atlieka įvairius klasterio masto namų tvarkymo veiksmus.
Koordinatorius
Atlieka vieną užduotį: priima skaitymo arba rašymo užklausas iš klientų ir nukreipia šį srautą. Jei bus rašymo užklausa, greičiausiai jis paklaus pagrindinio vadovo, į kurį atitinkamo indekso skeveldrą jį įtraukti, ir nukreips užklausą toliau.
Duomenų mazgas
Saugo duomenis, atlieka iš išorės gaunamas paieškos užklausas ir atlieka operacijas su jame esančiomis skeveldromis.
pilkšvas
Tai kažkas panašaus į „Kibana“ ir „Logstash“ sintezę ELK krūvoje. „Graylog“ sujungia ir vartotojo sąsają, ir žurnalų apdorojimo dujotiekį. Po gaubtu „Graylog“ veikia „Kafka“ ir „Zookeeper“, kurie suteikia ryšį su „Graylog“ kaip klasterį. Graylog gali talpykloje išsaugoti žurnalus (Kafka), jei Elasticsearch nepasiekiamas, ir kartoti nesėkmingas skaitymo ir rašymo užklausas, grupuoti ir pažymėti žurnalus pagal nurodytas taisykles. Kaip ir „Logstash“, „Graylog“ turi galimybę keisti eilutes prieš įrašant jas į „Elasticsearch“.
Be to, „Graylog“ turi integruotą paslaugų atradimą, leidžiantį, remiantis vienu turimu „Elasticsearch“ mazgu, gauti visą klasterio žemėlapį ir filtruoti jį pagal konkrečią žymą, o tai leidžia nukreipti užklausas į konkrečius konteinerius.
Vizualiai tai atrodo maždaug taip:
Tai ekrano kopija iš konkretaus atvejo. Čia mes sukuriame histogramą pagal paieškos užklausą ir rodome atitinkamas eilutes.
Indeksai
Grįžtant prie sistemos architektūros, norėčiau išsamiau pakalbėti apie tai, kaip mes sukūrėme indekso modelį, kad jis veiktų tinkamai.
Aukščiau pateiktoje diagramoje tai yra žemiausias lygis: „Elasticsearch“ duomenų mazgai.
Indeksas yra didelis virtualus subjektas, sudarytas iš Elasticsearch skeveldrų. Pati savaime kiekviena šukė yra ne kas kita, kaip Lucene indeksas. Ir kiekvienas Lucene indeksas, savo ruožtu, susideda iš vieno ar kelių segmentų.
Kurdami supratome, kad norint patenkinti didelio duomenų kiekio nuskaitymo greičio reikalavimą, turime „paskirstyti“ šiuos duomenis tolygiai tarp duomenų mazgų.
Tai lėmė faktą, kad skeveldrų skaičius viename indekse (su kopijomis) turėtų būti griežtai lygus duomenų mazgų skaičiui. Pirma, siekiant užtikrinti replikacijos koeficientą, lygų dviem (tai yra, galime prarasti pusę klasterio). Ir, antra, norint apdoroti skaitymo ir rašymo užklausas bent pusėje klasterio.
Pirmiausia nustatėme 30 dienų saugojimo laiką.
Skeveldrų pasiskirstymas gali būti grafiškai pavaizduotas taip:
Visas tamsiai pilkas stačiakampis yra indeksas. Kairysis raudonas kvadratas jame yra pirminė skeveldra, pirmoji indekse. O mėlynas kvadratas yra kopijos šukė. Jie yra skirtinguose duomenų centruose.
Kai pridedame dar vieną skeveldrą, ji patenka į trečiąjį duomenų centrą. Galų gale mes gauname šią struktūrą, kuri leidžia prarasti DC neprarandant duomenų nuoseklumo:
Indeksų rotacija, t.y. kurdami naują indeksą ir ištrynę seniausią, padarėme jį lygų 48 valandoms (pagal indekso naudojimo modelį: dažniausiai ieškoma paskutines 48 valandas).
Šis indekso pasukimo intervalas atsiranda dėl šių priežasčių:
Kai paieškos užklausa pasiekia konkretų duomenų mazgą, našumo požiūriu yra pelningiau, kai užklausiama viena skeveldra, jei jos dydis yra panašus į mazgo klubo dydį. Tai leidžia „karštą“ indekso dalį laikyti krūvoje ir greitai ją pasiekti. Kai yra daug „karštų dalių“, indekso paieškos greitis mažėja.
Kai mazgas pradeda vykdyti paieškos užklausą vienoje skiltyje, jis paskiria gijų skaičių, lygų fizinės mašinos hipersriegių branduolių skaičiui. Jei paieškos užklausa paveikia daug skeveldrų, tada gijų skaičius proporcingai didėja. Tai neigiamai veikia paieškos greitį ir neigiamai veikia naujų duomenų indeksavimą.
Norėdami užtikrinti reikiamą paieškos delsą, nusprendėme naudoti SSD. Norint greitai apdoroti užklausas, mašinos, kuriose buvo šie konteineriai, turėjo turėti bent 56 branduolius. Skaičius 56 buvo pasirinktas kaip sąlyginai pakankama reikšmė, kuri lemia gijų, kurias Elasticsearch sugeneruos veikimo metu, skaičių. „Elasitcsearch“ programoje daugelis gijų telkinio parametrų tiesiogiai priklauso nuo turimų branduolių skaičiaus, o tai savo ruožtu tiesiogiai veikia reikiamą mazgų skaičių klasteryje pagal principą „mažiau branduolių – daugiau mazgų“.
Dėl to mes nustatėme, kad vidutiniškai skeveldra sveria apie 20 gigabaitų, o viename indekse yra 1 skeveldrų. Atitinkamai, jei juos pasuksime kartą per 360 valandas, tada jų turėsime 48. Kiekviename indekse yra 15 dienų duomenys.
Duomenų rašymo ir skaitymo grandinės
Išsiaiškinkime, kaip duomenys įrašomi šioje sistemoje.
Tarkime, kad iš „Graylog“ koordinatoriui pateikiamas prašymas. Pavyzdžiui, mes norime indeksuoti 2-3 tūkstančius eilučių.
Koordinatorius, gavęs užklausą iš „Graylog“, klausia meistro: „Indeksavimo užklausoje mes konkrečiai nurodėme rodyklę, tačiau nebuvo nurodyta, kurioje skeveldroje jį įrašyti“.
Meistras atsako: „Įrašykite šią informaciją į skeveldros numerį 71“, po to ji siunčiama tiesiai į atitinkamą duomenų mazgą, kuriame yra pirminės skeveldros numeris 71.
Po to operacijų žurnalas yra kopijuojamas į replikos fragmentą, kuris yra kitame duomenų centre.
Iš „Graylog“ koordinatoriui atkeliauja paieškos užklausa. Koordinatorius peradresuoja jį pagal indeksą, o „Elasticsearch“ paskirsto užklausas tarp pirminės ir replikinės skeveldros, naudodamas apvalaus veikimo principą.
180 mazgų reaguoja netolygiai, o kol jie reaguoja, koordinatorius kaupia informaciją, kurią jau „išspjaudavo“ greitesni duomenų mazgai. Po to, kai arba visa informacija gaunama, arba užklausa baigiasi, viską perduoda tiesiogiai klientui.
Visa ši sistema vidutiniškai apdoroja pastarųjų 48 valandų paieškos užklausas per 300–400 ms, neįskaitant užklausų su pakaitos simboliu.
Gėlės su „Elasticsearch“: „Java“ sąranka
Kad viskas veiktų taip, kaip iš pradžių norėjome, labai ilgai praleidome derindami įvairius klasteryje esančius dalykus.
Pirmoji aptiktų problemų dalis buvo susijusi su tuo, kaip Java yra iš anksto sukonfigūruota pagal numatytuosius nustatymus Elasticsearch.
Problema viena
Stebėjome labai daug ataskaitų, kad Lucene lygiu, kai vykdomos foninės užduotys, Lucene segmento sujungimas nepavyksta ir atsiranda klaida. Tuo pačiu metu žurnaluose buvo aišku, kad tai buvo OutOfMemoryError klaida. Iš telemetrijos matėme, kad klubas laisvas, ir nebuvo aišku, kodėl ši operacija nepavyko.
Paaiškėjo, kad Lucene indekso susiliejimas vyksta už klubo ribų. O konteineriai yra gana griežtai ribojami sunaudojamų išteklių atžvilgiu. Į šiuos išteklius galėjo tilpti tik krūva (heap.size reikšmė buvo apytiksliai lygi RAM), o kai kurios off-heap operacijos nutrūko su atminties paskirstymo klaida, jei dėl kokių nors priežasčių jos netilpo į ~500 MB, likusių iki limito.
Pataisymas buvo gana nereikšmingas: buvo padidintas konteinerio RAM kiekis, po kurio pamiršome, kad tokių problemų net turėjome.
Antra problema
Praėjus 4-5 dienoms po klasterio paleidimo, pastebėjome, kad duomenų mazgai pradėjo periodiškai iškristi iš klasterio ir į jį patekti po 10-20 sekundžių.
Kai pradėjome tai išsiaiškinti, paaiškėjo, kad ši „Elasticsearch“ atmintis niekaip nekontroliuojama. Kai konteineriui suteikėme daugiau atminties, galėjome užpildyti tiesioginio buferio telkinius įvairia informacija ir ji buvo išvalyta tik po to, kai iš Elasticsearch buvo paleistas aiškus GC.
Kai kuriais atvejais ši operacija užtrukdavo gana ilgai ir per tą laiką klasteris sugebėjo pažymėti šį mazgą kaip jau išvestą. Ši problema yra gerai aprašyta .
Sprendimas buvo toks: apribojome „Java“ galimybę šioms operacijoms naudoti didžiąją dalį atminties už krūvos ribų. Apribojome jį iki 16 gigabaitų (-XX:MaxDirectMemorySize=16g), užtikrindami, kad aiškus GC būtų iškviečiamas daug dažniau ir apdorojamas daug greičiau, taip nebedestabilizuojant klasterio.
Trečia problema
Jei manote, kad problemos, susijusios su „mazgais, išeinančiais iš klasterio netikėčiausiu momentu“, baigėsi, klystate.
Kai sukonfigūravome darbą su indeksais, pasirinkome mmapfs to ant šviežių šukių su dideliu segmentavimu. Tai buvo nemaža klaida, nes naudojant mmapfs failas susiejamas su RAM, o tada dirbame su susietu failu. Dėl to paaiškėja, kad kai GC bando sustabdyti gijas programoje, mes labai ilgam einame į saugųjį tašką, o pakeliui į jį programa nustoja reaguoti į meistro užklausas, ar ji gyva. . Atitinkamai, meistras mano, kad mazgo klasteryje nebėra. Po to, po 5-10 sekundžių, suveikia šiukšlių surinkėjas, mazgas atgyja, vėl patenka į klasterį ir pradeda inicijuoti skeveldras. Visa tai atrodė kaip „produkcija, kurios nusipelnėme“ ir nebuvo tinkama niekam rimtam.
Norėdami atsikratyti šio elgesio, pirmiausia perėjome prie standartinių niofų, o tada, kai perėjome iš penktosios Elastic versijos į šeštąją, išbandėme hibridus, kur ši problema nebuvo atkurta. Galite perskaityti daugiau apie saugojimo tipus .
Ketvirta problema
Tada buvo dar viena labai įdomi problema, kurią gydėme rekordiškai ilgai. Mes jį gaudėme 2-3 mėnesius, nes jo raštas buvo visiškai nesuprantamas.
Kartais mūsų koordinatoriai eidavo į „Full GC“, paprastai po pietų, ir iš ten niekada negrįždavo. Tuo pačiu metu registruojant GC delsą atrodė taip: viskas gerai, gerai, gerai, o tada staiga viskas vyksta labai blogai.
Iš pradžių manėme, kad turime piktą vartotoją, kuris paleido kažkokią užklausą, kuri išmušė koordinatorių iš darbo režimo. Labai ilgai registravome prašymus, bandydami išsiaiškinti, kas vyksta.
Dėl to paaiškėjo, kad tuo metu, kai vartotojas pateikia didžiulę užklausą ir ji pasiekia konkretų Elasticsearch koordinatorių, kai kurie mazgai reaguoja ilgiau nei kiti.
Ir kol koordinatorius laukia atsakymo iš visų mazgų, jis kaupia rezultatus, atsiųstus iš jau atsiliepusių mazgų. GC atveju tai reiškia, kad mūsų krūvos naudojimo modeliai keičiasi labai greitai. Ir mūsų naudojamas GC negalėjo susidoroti su šia užduotimi.
Vienintelis pataisymas, kurį radome pakeitęs klasterio elgesį šioje situacijoje, yra perkėlimas į JDK13 ir Shenandoah šiukšlių rinktuvo naudojimas. Tai išsprendė problemą, mūsų koordinatoriai nustojo kristi.
Čia baigėsi „Java“ problemos ir prasidėjo pralaidumo problemos.
„Uogos“ su „Elasticsearch“: pralaidumas
Pralaidumo problemos reiškia, kad mūsų klasteris veikia stabiliai, tačiau esant dideliam indeksuotų dokumentų skaičiui ir atliekant manevrus, našumas yra nepakankamas.
Pirmasis pastebėtas simptomas: kai kurių gamybos „sprogimų“ metu, kai staiga sugeneruojamas labai daug žurnalų, „Graylog“ sistemoje pradeda dažnai mirksėti indeksavimo klaida es_rejected_execution.
Taip atsitiko dėl to, kad thread_pool.write.queue viename duomenų mazge iki to momento, kai Elasticsearch gali apdoroti indeksavimo užklausą ir įkelti informaciją į diske esančią skeveldrą, pagal numatytuosius nustatymus gali talpykloje išsaugoti tik 200 užklausų. Ir į Apie šį parametrą kalbama labai mažai. Nurodomas tik maksimalus siūlų skaičius ir numatytasis dydis.
Žinoma, mes pakeitėme šią vertę ir sužinojome štai ką: konkrečiai mūsų sąrankoje iki 300 užklausų yra gana gerai saugoma talpykloje, o didesnė vertė yra susijusi su tuo, kad vėl skrendame į „Full GC“.
Be to, kadangi tai yra pranešimų paketai, kurie gaunami per vieną užklausą, reikėjo pakoreguoti „Graylog“, kad jis rašytų ne dažnai ir mažomis partijomis, o didžiulėmis partijomis arba kartą per 3 sekundes, jei paketas vis dar nėra baigtas. Tokiu atveju paaiškėja, kad informacija, kurią rašome Elasticsearch, tampa prieinama ne per dvi sekundes, o per penkias (tai mums labai tinka), bet perdėjimų skaičius, kurį reikia atlikti, kad būtų pasiektas didelis sumažėja informacijos krūva.
Tai ypač svarbu tomis akimirkomis, kai kažkas kažkur užgriuvo ir įnirtingai apie tai praneša, kad nepatektų visiškai spam’o Elastic, o po kurio laiko – dėl užsikimšusių buferių neveikiantys Graylog mazgai.
Be to, kai turėjome tuos pačius sprogimus gamyboje, sulaukėme skundų iš programuotojų ir bandytojų: tuo metu, kai jiems labai reikėjo šių rąstų, jie buvo atiduodami labai lėtai.
Jie pradėjo tai suprasti. Viena vertus, buvo aišku, kad tiek paieškos, tiek indeksavimo užklausos buvo apdorojamos iš esmės tose pačiose fizinėse mašinose ir vienaip ar kitaip bus tam tikrų trūkumų.
Tačiau tai galima iš dalies apeiti dėl to, kad šeštosiose Elasticsearch versijose atsirado algoritmas, leidžiantis paskirstyti užklausas tarp atitinkamų duomenų mazgų ne pagal atsitiktinio apvalumo principą (konteineris, kuris atlieka indeksavimą ir turi pirminį -shard gali būti labai užimtas, nebus kaip greitai atsakyti), bet persiųsti šią užklausą į mažiau pakrautą konteinerį su replika-shard, kuris atsakys daug greičiau. Kitaip tariant, pasiekėme use_adaptive_replica_selection: true.
Skaitymo paveikslėlis pradeda atrodyti taip:
Perėjimas prie šio algoritmo leido žymiai pagerinti užklausos laiką tais momentais, kai turėjome daug rašyti žurnalų.
Galiausiai pagrindinė problema buvo neskausmingas duomenų centro pašalinimas.
Ko mes norėjome iš klasterio iškart po to, kai praradome ryšį su vienu DC:
- Jei sugedusiame duomenų centre turime dabartinį pagrindinį įrenginį, jis bus iš naujo pasirinktas ir perkeltas kaip vaidmuo į kitą mazgą kitame DC.
- Meistras greitai pašalins visus nepasiekiamus mazgus iš klasterio.
- Remdamasis likusiais, jis supras: prarastame duomenų centre turėjome tokių ir tokių pirminių šukių, jis greitai iškels papildomas replikų šukes likusiuose duomenų centruose, o mes ir toliau indeksuosime duomenis.
- Dėl to klasterio rašymo ir skaitymo pralaidumas palaipsniui blogės, tačiau apskritai viskas veiks, nors ir lėtai, bet stabiliai.
Kaip paaiškėjo, norėjome kažko panašaus:
Ir gavome štai ką:
Kaip tai nutiko?
Kai duomenų centras žlugo, mūsų meistras tapo kliūtimi.
Kodėl?
Faktas yra tas, kad pagrindinis kompiuteris turi TaskBatcher, kuris yra atsakingas už tam tikrų užduočių ir įvykių paskirstymą klasteryje. Bet koks mazgo išėjimas, bet koks skeveldros pakėlimas iš kopijos į pirminį, bet kokia užduotis kur nors sukurti skeveldrą – visa tai pirmiausia patenka į „TaskBatcher“, kur apdorojama nuosekliai ir vienoje gijoje.
Vieno duomenų centro pasitraukimo metu paaiškėjo, kad visi duomenų mazgai išlikusiuose duomenų centruose laikė savo pareiga informuoti šeimininką „pametėme tokių ir tokių šukių, tokių ir tokių duomenų mazgų“.
Tuo pačiu metu išlikę duomenų mazgai visą šią informaciją siuntė dabartiniam šeimininkui ir bandė laukti patvirtinimo, kad jis ją priėmė. Jie to nelaukė, nes meistras gavo užduotis greičiau, nei galėjo atsakyti. Mazgai baigėsi kartotinėms užklausoms, o šeimininkas šiuo metu net nebandė į juos atsakyti, bet buvo visiškai įsitraukęs į užklausų rūšiavimo pagal prioritetą užduotį.
Terminalo formoje paaiškėjo, kad duomenų mazgai šlamštą išsiuntė pagrindiniam kompiuteriui tiek, kad jis perėjo į visą GC. Po to mūsų pagrindinis vaidmuo persikėlė į kitą mazgą, su juo atsitiko visiškai tas pats, ir dėl to klasteris visiškai žlugo.
Atlikome matavimus ir iki 6.4.0 versijos, kur tai buvo ištaisyta, mums užteko vienu metu išvesti tik 10 duomenų mazgų iš 360, kad visiškai išjungtume klasterį.
Tai atrodė maždaug taip:
Po 6.4.0 versijos, kurioje buvo ištaisyta ši baisi klaida, duomenų mazgai nustojo žudyti pagrindinį kompiuterį. Bet tai nepadarė jo „gudresnio“. Būtent: kai išvedame 2, 3 arba 10 (bet kokį skaičių, išskyrus vieną) duomenų mazgų, pagrindinis kompiuteris gauna pirmą pranešimą, kad mazgas A išėjo, ir bando apie tai pasakyti mazgui B, mazgui C, mazgui D.
O šiuo metu tai galima išspręsti tik nustatant bandymų kam nors apie ką nors pasakyti laiko ribą, lygią maždaug 20-30 sekundžių, ir taip kontroliuoti duomenų centro judėjimo iš klasterio greitį.
Iš esmės tai atitinka reikalavimus, kurie iš pradžių buvo pateikti galutiniam produktui kaip projekto dalis, tačiau „grynojo mokslo“ požiūriu tai yra klaida. Kurį, beje, kūrėjai sėkmingai ištaisė 7.2 versijoje.
Be to, kai užgeso tam tikras duomenų mazgas, paaiškėjo, kad skleisti informaciją apie jo išėjimą buvo svarbiau nei pasakyti visam klasteriui, kad jame yra tokių ir tokių pirminių skeveldrų (siekiant reklamuoti repliką kituose duomenyse centras pirminėje, o informacija galėtų būti įrašyta ant jų).
Todėl, kai jau viskas aprimo, išleisti duomenų mazgai ne iš karto pažymimi kaip pasenę. Atitinkamai, esame priversti laukti, kol baigsis visų pingų laikas iki išleistų duomenų mazgų, ir tik po to mūsų klasteris pradeda mums pasakyti, kad ten, ten ir ten turime tęsti informacijos įrašymą. Daugiau apie tai galite paskaityti .
Todėl šiandien duomenų centro išėmimo operacija piko metu mums užtrunka apie 5 minutes. Tokiam dideliam ir gremėzdiškam kolosui tai gana geras rezultatas.
Dėl to priėjome prie tokio sprendimo:
- Turime 360 duomenų mazgus su 700 gigabaitų diskais.
- 60 koordinatorių, nukreipiančių srautą per tuos pačius duomenų mazgus.
- 40 meistrų, kuriuos palikome kaip savotišką palikimą nuo versijų iki 6.4.0 – norėdami išgyventi duomenų centro pasitraukimą, buvome psichiškai pasiruošę prarasti kelias mašinas, kad būtume garantuoti, kad turėsime meistrų kvorumą net m. blogiausiu atveju
- Bet kokie bandymai sujungti vaidmenis viename konteineryje buvo sutikti su tuo, kad anksčiau ar vėliau mazgas nutrūks veikiant apkrovai.
- Visame klasteryje naudojamas 31 gigabaito heap.size: visi bandymai sumažinti dydį baigdavosi kai kurių sunkių paieškos užklausų mazgais, naudojant pagrindinį pakaitos simbolį, arba gaudavo grandinės pertraukiklį pačioje Elasticsearch.
- Be to, siekdami užtikrinti paieškos našumą, stengėmės, kad objektų skaičius klasteryje būtų kuo mažesnis, kad būtų galima apdoroti kuo mažiau įvykių, susijusių su kliūtimi, kurią gavome pagrindiniame kompiuteryje.
Galiausiai apie stebėjimą
Siekdami užtikrinti, kad visa tai veiktų taip, kaip numatyta, stebime šiuos dalykus:
- Kiekvienas duomenų mazgas praneša mūsų debesiui, kad jis egzistuoja, ir jame yra tokių ir tokių šukių. Kai ką nors kur nors užgesiname, klasteris po 2-3 sekundžių praneša, kad centre A užgesinome 2, 3 ir 4 mazgus – tai reiškia, kad kituose duomenų centruose jokiu būdu negalime užgesinti tų mazgų, ant kurių yra tik viena skeveldra. paliko.
- Žinodami meistro elgesio pobūdį, labai atidžiai žiūrime į laukiančių užduočių skaičių. Nes net ir viena užstrigusi užduotis, jei laiku nepasibaigs laikas, teoriškai kokioje nors avarinėje situacijoje gali tapti priežastimi, kodėl, pavyzdžiui, replikos šukės reklamavimas pirminėje neveikia, todėl indeksavimas nustos veikti.
- Taip pat labai atidžiai žiūrime į šiukšlių surinkėjų vėlavimus, nes optimizuodami jau turėjome didelių sunkumų.
- Atmeta pagal siūlą, kad iš anksto suprastų, kur yra kliūtis.
- Na, standartinės metrikos, tokios kaip krūva, RAM ir I/O.
Kurdami stebėjimą turite atsižvelgti į Elasticsearch Thread Pool ypatybes. aprašo konfigūracijos parinktis ir numatytąsias paieškos ir indeksavimo reikšmes, bet visiškai tyli apie thread_pool.management. Šios gijos ypač apdoroja tokias užklausas kaip _cat/shards ir kitas panašias, kurias patogu naudoti rašant stebėjimą. Kuo didesnis klasteris, tuo daugiau tokių užklausų įvykdoma per laiko vienetą, o minėtas thread_pool.management ne tik nepateikiamas oficialioje dokumentacijoje, bet ir pagal nutylėjimą yra apribotas iki 5 gijų, kurios labai greitai pašalinamos, po to kurios stebėjimas nustoja tinkamai veikti.
Baigdamas noriu pasakyti: mes tai padarėme! Savo programuotojams ir kūrėjams galėjome suteikti įrankį, kuris beveik bet kokioje situacijoje gali greitai ir patikimai pateikti informaciją apie tai, kas vyksta gamyboje.
Taip, tai pasirodė gana sudėtinga, bet vis dėlto sugebėjome savo norus sutalpinti į esamus gaminius, kurių nereikėjo patiems lopyti ir perrašyti.
Šaltinis: www.habr.com