Multaj homoj luktas kun Elasticsearch. Sed kio okazas kiam vi volas uzi ĝin por stoki ŝtipojn "en aparte granda volumeno"? Kaj ĉu estas ankaŭ sendanĝere sperti la fiaskon de iu el pluraj datumcentroj? Kian arkitekturon vi faru, kaj pri kiaj kaptiloj vi trovos?
Ni ĉe Odnoklassniki decidis uzi elastikserĉon por solvi la problemon pri ŝtipadministrado, kaj nun ni dividas nian sperton kun Habr: kaj pri arkitekturo kaj pri faŭltoj.
Mi estas Pjotr Zaitsev, mi laboras kiel sistemadministranto ĉe Odnoklassniki. Antaŭ tio, mi ankaŭ estis administranto, laboris kun Manticore Search, Sphinx-serĉo, Elasticsearch. Eble, se aperos alia ...serĉo, ankaŭ mi verŝajne laboros kun ĝi. Mi ankaŭ partoprenas en kelkaj malfermfontaj projektoj libervole.
Kiam mi venis al Odnoklassniki, mi senpripense diris ĉe la intervjuo, ke mi povus labori kun Elasticsearch. Post kiam mi ekkomprenis ĝin kaj kompletigis kelkajn simplajn taskojn, mi ricevis la grandan taskon reformi la ŝtipan administradsistemon kiu ekzistis en tiu tempo.
postuloj
La sistemaj postuloj estis formulitaj jene:
- Graylog estis uzota kiel la fasado. Ĉar la firmao jam havis sperton uzante ĉi tiun produkton, programistoj kaj testistoj sciis ĝin, ĝi estis konata kaj oportuna al ili.
- Volumo de datumoj: averaĝe 50-80 mil mesaĝoj sekundo, sed se io rompiĝas, tiam la trafiko ne estas limigita per io, ĝi povas esti 2-3 milionoj da linioj sekundo.
- Diskutinte kun klientoj la postulojn por la rapideco de prilaborado de serĉdemandoj, ni rimarkis, ke la tipa ŝablono uzi tian sistemon estas jena: homoj serĉas protokolojn de sia aplikaĵo dum la lastaj du tagoj kaj ne volas atendi pli ol unu. dua por la rezulto de formulita demando.
- La administrantoj insistis, ke la sistemo estu facile skalebla se necese, sen postuli, ke ili profundu pri kiel ĝi funkcias.
- Por ke la sola prizorga tasko, kiun ĉi tiuj sistemoj postulas periode, estas ŝanĝi iun aparataron.
- Krome, Odnoklassniki havas bonegan teknikan tradicion: ajna servo, kiun ni lanĉas, devas postvivi al fiasko de datumcentro (subita, neplanita kaj absolute iam ajn).
Plej multe kostis al ni la lasta postulo en la efektivigo de ĉi tiu projekto, pri kiu mi parolos pli detale.
Medio
Ni laboras en kvar datumcentroj, dum Elasticsearch-datumnodoj povas troviĝi nur en tri (pro kelkaj ne-teknikaj kialoj).
Ĉi tiuj kvar datumcentroj enhavas proksimume 18 mil malsamajn protokolojn - aparataron, ujojn, virtualajn maŝinojn.
Grava trajto: la areto komenciĝas en ujoj ne sur fizikaj maŝinoj, sed sur . Ujoj estas garantiitaj 2 kernoj, similaj al 2.0Ghz v4, kun la ebleco recikli la ceterajn kernojn se ili estas neaktivaj.
Alivorte:
Topologio
Mi komence vidis la ĝeneralan formon de la solvo jene:
- 3-4 VIP-oj estas malantaŭ la A-rekordo de la Graylog-domajno, ĉi tiu estas la adreso al kiu la protokoloj estas senditaj.
- ĉiu VIP estas LVS-ekvilibristo.
- Post ĝi, la protokoloj iras al la Graylog-baterio, iuj el la datumoj estas en GELF-formato, iuj en syslog-formato.
- Tiam ĉio ĉi estas skribita en grandaj aroj al baterio de Elasticsearch-kunordigantoj.
- Kaj ili, siavice, sendas skribajn kaj legajn petojn al la koncernaj datennodoj.
Terminologio
Eble ne ĉiuj komprenas la terminologion detale, do mi ŝatus iom trankviliĝi pri ĝi.
Elasticsearch havas plurajn specojn de nodoj - majstro, kunordiganto, datumnodo. Estas du aliaj tipoj por malsamaj protokolaj transformoj kaj komunikado inter malsamaj aretoj, sed ni uzis nur tiujn listigitajn.
majstro
Ĝi pingas ĉiujn nodojn ĉeestantaj en la areto, konservas ĝisdatigitan aretmapon kaj distribuas ĝin inter nodoj, prilaboras okazaĵlogikon, kaj elfaras diversajn specojn de areto larĝa mastrumado.
Kunordiganto
Faras unu solan taskon: akceptas legi aŭ skribpetojn de klientoj kaj direktas ĉi tiun trafikon. Se estas skribpeto, plej verŝajne, ĝi demandos majstron, kiun peceton de la koncerna indekso ĝi devas meti ĝin, kaj alidirektos la peton plu.
Datuma nodo
Stokas datumojn, faras serĉdemandojn alvenantajn de ekstere kaj faras operaciojn sur fragmentoj situantaj sur ĝi.
graylog
Ĉi tio estas io kiel kunfandado de Kibana kun Logstash en ELK-stako. Graylog kombinas kaj UI kaj protokolan dukton. Sub la kapuĉo, Graylog prizorgas Kafka kaj Zookeeper, kiuj disponigas konekteblecon al Graylog kiel areto. Graylog povas konservi protokolojn (Kafka) en kazo Elasticsearch ne disponeblas kaj ripeti malsukcesajn legi- kaj verki petojn, grupigi kaj marki protokolojn laŭ specifitaj reguloj. Kiel Logstash, Graylog havas funkciojn por modifi vicojn antaŭ skribi ilin al Elasticsearch.
Krome, Graylog havas enkonstruitan servo-malkovron kiu permesas, surbaze de unu disponebla Elasticsearch-nodo, akiri la tutan aretmapon kaj filtri ĝin per specifa etikedo, kiu ebligas direkti petojn al specifaj ujoj.
Vide ĝi aspektas kiel ĉi tio:
Ĉi tio estas ekrankopio de specifa okazo. Ĉi tie ni konstruas histogramon bazitan sur la serĉdemando kaj montras rilatajn vicojn.
Indeksoj
Revenante al la sistema arkitekturo, mi ŝatus pli detale detale kiel ni konstruis la indeksan modelon por ke ĉio funkciu ĝuste.
En la supra diagramo, ĉi tiu estas la plej malalta nivelo: Elasticsearch-datumnodoj.
Indekso estas granda virtuala ento formita de Elasticsearch-pecetoj. En si mem, ĉiu el la pecetoj estas nenio pli ol Lucene-indekso. Kaj ĉiu Lucene-indekso, siavice, konsistas el unu aŭ pluraj segmentoj.
Dum desegnado, ni supozis, ke por plenumi la postulon pri legado de rapideco sur granda kvanto da datumoj, ni bezonas "disvastigi" ĉi tiujn datumojn egale tra datennodoj.
Ĉi tio rezultigis la fakton, ke la nombro da pecetoj per indekso (kun kopioj) devus esti strikte egala al la nombro da datennodoj. Unue, por certigi reproduktan faktoron egala al du (tio estas, ni povas perdi duonon de la areto). Kaj, due, por procesi legi kaj skribi petojn sur almenaŭ duono de la areto.
Ni unue determinis la stoktempon kiel 30 tagojn.
La distribuado de pecetoj povas esti reprezentita grafike jene:
La tuta malhelgriza rektangulo estas indekso. La maldekstra ruĝa kvadrato en ĝi estas la primara peceto, la unua en la indekso. Kaj la blua kvadrato estas kopia peceto. Ili situas en malsamaj datumcentroj.
Kiam ni aldonas alian peceton, ĝi iras al la tria datumcentro. Kaj, finfine, ni ricevas ĉi tiun strukturon, kiu ebligas perdi DC sen perdi datuman konsistencon:
Rotacio de indeksoj, t.e. kreante novan indekson kaj forigante la plej malnovan, ni egaligis ĝin al 48 horoj (laŭ la ŝablono de indeksa uzo: la lastaj 48 horoj estas serĉataj plej ofte).
Ĉi tiu indeksa rotacia intervalo ŝuldiĝas al la sekvaj kialoj:
Kiam serĉpeto alvenas al specifa datennodo, tiam, de agado-perspektivo, ĝi estas pli enspeziga kiam unu breĉeto estas pridemandita, se ĝia grandeco estas komparebla al la grandeco de la kokso de la nodo. Ĉi tio permesas vin konservi la "varman" parton de la indekso en amaso kaj rapide aliri ĝin. Kiam estas multaj "varmaj partoj", la rapideco de indeksa serĉado malpliiĝas.
Kiam nodo komencas efektivigi serĉdemandon sur unu peceto, ĝi asignas kelkajn fadenojn egalajn al la nombro da hiperfadenaj kernoj de la fizika maŝino. Se serĉdemando influas grandan nombron da fragmentoj, tiam la nombro da fadenoj kreskas proporcie. Ĉi tio havas negativan efikon al serĉrapideco kaj negative influas la indeksadon de novaj datumoj.
Por provizi la necesan serĉan latentecon, ni decidis uzi SSD. Por rapide procesi petojn, la maŝinoj, kiuj gastigis ĉi tiujn ujojn, devis havi almenaŭ 56 kernojn. La figuro de 56 estis elektita kiel kondiĉe sufiĉa valoro kiu determinas la nombron da fadenoj kiujn Elasticsearch generos dum operacio. En Elasitcsearch, multaj fadenaj naĝejoj parametroj rekte dependas de la nombro da disponeblaj kernoj, kiu siavice rekte influas la postulatan nombron da nodoj en la areto laŭ la principo "malpli da kernoj - pli da nodoj".
Kiel rezulto, ni trovis, ke averaĝe peceto pezas ĉirkaŭ 20 gigabajtojn, kaj estas 1 pecetoj po indekso. Sekve, se ni turnas ilin unufoje ĉiujn 360 horojn, tiam ni havas 48 el ili. Ĉiu indekso enhavas datumojn dum 15 tagoj.
Cirkvitoj pri skribado kaj legado de datumoj
Ni eltrovu kiel datumoj estas registritaj en ĉi tiu sistemo.
Ni diru, ke iu peto alvenas de Graylog al la kunordiganto. Ekzemple, ni volas indeksi 2-3 mil vicojn.
La kunordiganto, ricevinte peton de Graylog, demandas la majstron: "En la indeksa peto, ni specife specifis indekson, sed en kiu peceto skribi ĝin ne estis precizigita."
La majstro respondas: "Skribu ĉi tiun informon al breĉeto numero 71", post kio ĝi estas sendita rekte al la koncerna datuma nodo, kie troviĝas la primara breĉeto numero 71.
Post tio la transakcia protokolo estas reproduktita al kopio-shard, kiu situas en alia datumcentro.
Serĉpeto alvenas de Graylog al la kunordiganto. La kunordiganto redirektas ĝin laŭ la indekso, dum Elasticsearch distribuas petojn inter la primara-shard kaj kopio-shard uzante la cirkla-subskribolistan principon.
La 180 nodoj respondas malegale, kaj dum ili respondas, la kunordiganto amasigas informojn, kiuj jam estis "elkraĉitaj" de pli rapidaj datennodoj. Post ĉi tio, kiam aŭ ĉiuj informoj alvenis, aŭ la peto atingis tempon, ĝi donas ĉion rekte al la kliento.
Ĉi tiu tuta sistemo averaĝe prilaboras serĉdemandojn dum la lastaj 48 horoj en 300-400ms, ekskludante tiujn demandojn kun gvida ĵokero.
Floroj kun Elasticsearch: Java agordo
Por ke ĉio funkciu kiel ni origine volis, ni pasigis tre longan tempon sencimigi diversajn aferojn en la areto.
La unua parto de la malkovritaj problemoj rilatis al la maniero kiel Java estas antaŭ-agordita defaŭlte en Elasticsearch.
Problemo unu
Ni vidis tre grandan nombron da raportoj, ke ĉe la Lucene-nivelo, kiam fonaj laboroj funkcias, Lucene-segmento-kunfandiĝo malsukcesas kun eraro. Samtempe, estis klare en la protokoloj, ke tio estis OutOfMemoryError-eraro. Ni vidis de telemetrio, ke la kokso estas libera, kaj ne estis klare kial ĉi tiu operacio malsukcesas.
Montriĝis, ke Lucene-indekso kunfandiĝas ekster la kokso. Kaj ujoj estas sufiĉe strikte limigitaj laŭ konsumitaj rimedoj. Nur amaso povis konveni en ĉi tiujn rimedojn (la heap.size-valoro estis proksimume egala al RAM), kaj kelkaj eksterheap operacioj kraŝis kun memorasigno-eraro se ial ili ne konvenis en la ~500MB kiu restis antaŭ la limo.
La riparo estis sufiĉe bagatela: la kvanto de disponebla RAM por la ujo estis pliigita, post kio ni forgesis, ke ni eĉ havis tiajn problemojn.
Problemo du
4-5 tagojn post la lanĉo de la areto, ni rimarkis, ke datumaj nodoj komencis periode fali el la areto kaj eniri ĝin post 10-20 sekundoj.
Kiam ni komencis eltrovi ĝin, montriĝis, ke ĉi tiu ekstera memoro en Elasticsearch neniel estas kontrolita. Kiam ni donis pli da memoro al la ujo, ni povis plenigi la rektajn bufrojn per diversaj informoj, kaj ĝi estis purigita nur post kiam la eksplicita GC estis lanĉita de Elasticsearch.
En iuj kazoj, ĉi tiu operacio daŭris sufiĉe longan tempon, kaj dum ĉi tiu tempo la areto sukcesis marki ĉi tiun nodon kiel jam elirinta. Ĉi tiu problemo estas bone priskribita .
La solvo estis jena: ni limigis la kapablon de Java uzi la plej grandan parton de memoro ekster la amaso por ĉi tiuj operacioj. Ni limigis ĝin al 16 gigabajtoj (-XX:MaxDirectMemorySize=16g), certigante ke eksplicita GC estis vokita multe pli ofte kaj prilaborita multe pli rapide, tiel ne plu malstabiligante la areton.
Problemo tri
Se vi pensas, ke la problemoj kun "nodoj forlasantaj la areton en la plej neatendita momento" finiĝis, vi eraras.
Kiam ni agordis la laboron kun indeksoj, ni elektis mmapfs al sur freŝaj pecetoj kun granda segmentado. Ĉi tio estis sufiĉe fuŝaĵo, ĉar kiam oni uzas mmapfs, la dosiero estas mapita en RAM, kaj tiam ni laboras kun la mapita dosiero. Pro tio, rezultas, ke kiam la GC provas ĉesigi fadenojn en la aplikaĵo, ni iras al la sekurpunkto por tre longa tempo, kaj survoje al ĝi, la aplikaĵo ĉesas respondi al la petoj de la majstro pri ĉu ĝi vivas. . Sekve, majstro kredas, ke la nodo ne plu ĉeestas en la areto. Post ĉi tio, post 5-10 sekundoj, la rubkolektanto funkcias, la nodo reviviĝas, denove eniras la areton kaj komencas pravalorigi fragmentojn. Ĉio sentis tre kiel "la produktado, kiun ni meritis" kaj ne estis taŭga por io serioza.
Por forigi ĉi tiun konduton, ni unue ŝanĝis al normaj niof-oj, kaj poste, kiam ni migris de la kvinaj versioj de Elastic al la sesa, ni provis hibridojn, kie ĉi tiu problemo ne estis reproduktita. Vi povas legi pli pri stokaj tipoj .
Problemo kvar
Poste estis alia tre interesa problemo, kiun ni traktis dum rekorda tempo. Ni kaptis ĝin dum 2-3 monatoj ĉar ĝia ŝablono estis absolute nekomprenebla.
Foje niaj kunordigantoj iris al Plena GC, kutime iam post tagmanĝo, kaj neniam revenis de tie. Samtempe, kiam registrinte la GC-prokraston, ĝi aspektis jene: ĉio iras bone, nu, bone, kaj tiam subite ĉio iras tre malbone.
Komence ni pensis, ke ni havas malbonan uzanton, kiu lanĉis ian peton, kiu eligis la kunordiganton el laborreĝimo. Ni registris petojn dum tre longa tempo, provante eltrovi kio okazas.
Kiel rezulto, montriĝis, ke en la momento, kiam uzanto lanĉas grandegan peton, kaj ĝi atingas specifan kunordiganton de Elasticsearch, iuj nodoj respondas pli longe ol aliaj.
Kaj dum la kunordiganto atendas respondon de ĉiuj nodoj, li amasigas la rezultojn senditajn de la nodoj, kiuj jam respondis. Por GC, tio signifas, ke niaj amasuzaj ŝablonoj ŝanĝiĝas tre rapide. Kaj la GC, kiun ni uzis, ne povis elteni ĉi tiun taskon.
La nura solvo, kiun ni trovis por ŝanĝi la konduton de la areto en ĉi tiu situacio, estas migrado al JDK13 kaj uzo de la rubkolektilo Shenandoah. Ĉi tio solvis la problemon, niaj kunordigantoj ĉesis fali.
Ĉi tie finiĝis la problemoj kun Java kaj komenciĝis la problemoj de larĝa bando.
"Beroj" kun Elasticsearch: trairo
Problemoj kun trafluo signifas, ke nia areto funkcias stabile, sed ĉe pintoj en la nombro da indeksitaj dokumentoj kaj dum manovroj, rendimento estas nesufiĉa.
La unua simptomo renkontita: dum kelkaj "eksplodoj" en produktado, kiam tre granda nombro da protokoloj estas subite generita, la indeksada eraro es_rejected_execution komencas ekbrili ofte en Graylog.
Ĉi tio ŝuldiĝis al tio, ke thread_pool.write.queue sur unu datumnodo, ĝis la momento, Elasticsearch kapablas prilabori la indeksan peton kaj alŝuti la informojn al la shard sur disko, kapablas kaŝmemori nur 200 petojn defaŭlte. Kaj en Tre malmulte estas dirita pri ĉi tiu parametro. Nur la maksimuma nombro da fadenoj kaj la defaŭlta grandeco estas indikitaj.
Kompreneble, ni iris tordi ĉi tiun valoron kaj eksciis la jenon: specife, en nia aranĝo, ĝis 300 petoj estas sufiĉe bone konservitaj en kaŝmemoro, kaj pli alta valoro estas plena de tio, ke ni denove flugas en Plenan GC.
Krome, ĉar ĉi tiuj estas aroj da mesaĝoj kiuj alvenas ene de unu peto, estis necese ĝustigi Graylog por ke ĝi skribu ne ofte kaj en malgrandaj aroj, sed en grandegaj aroj aŭ unufoje ĉiujn 3 sekundojn se la aro ankoraŭ ne estas kompleta. En ĉi tiu kazo, rezultas, ke la informoj, kiujn ni skribas en Elasticsearch, disponeblas ne en du sekundoj, sed en kvin (kio sufiĉe bone konvenas al ni), sed la nombro da retransdonadoj, kiujn oni devas fari por trapasi grandan stako de informoj estas reduktita.
Ĉi tio gravas precipe en tiuj momentoj, kiam io kraŝis ie kaj furioze raportas pri tio, por ne ricevi tute spamitan Elastikon, kaj post iom da tempo - Graylog-nodoj, kiuj estas nefunkcieblaj pro ŝtopitaj bufroj.
Krome, kiam ni havis ĉi tiujn samajn eksplodojn en produktado, ni ricevis plendojn de programistoj kaj testistoj: en la momento, kiam ili vere bezonis ĉi tiujn protokolojn, ili ricevis ilin tre malrapide.
Ili komencis eltrovi ĝin. Unuflanke, estis klare, ke kaj serĉdemandoj kaj indeksaj demandoj estis prilaboritaj, esence, sur la samaj fizikaj maŝinoj, kaj iel aŭ alie estus certaj malaltiĝoj.
Sed ĉi tio povus esti parte evitita pro la fakto, ke en la sesaj versioj de Elasticsearch aperis algoritmo, kiu ebligas distribui demandojn inter koncernaj datumnodoj ne laŭ la hazarda cirkla-subskribolista principo (la ujo, kiu faras indeksadon kaj tenas la ĉefan). -shard povas esti tre okupata, ne estos maniero respondi rapide), sed plusendi ĉi tiun peton al malpli ŝarĝita ujo kun kopio-shard, kiu respondos multe pli rapide. Alivorte, ni alvenis al use_adaptive_replica_selection: true.
La leganta bildo komencas aspekti jene:
La transiro al ĉi tiu algoritmo ebligis signife plibonigi la demandotempon en tiuj momentoj, kiam ni havis grandan fluon de protokoloj por skribi.
Fine, la ĉefa problemo estis la sendolora forigo de la datumcentro.
Kion ni deziris de la areto tuj post perdo de rilato kun unu DC:
- Se ni havas nunan majstron en la malsukcesa datumcentro, tiam ĝi estos reelektita kaj movita kiel rolo al alia nodo en alia DC.
- La majstro rapide forigos ĉiujn neatingeblajn nodojn de la areto.
- Surbaze de la ceteraj, li komprenos: en la perdita datumcentro ni havis tiajn kaj tiajn primarajn pecetojn, li rapide antaŭenigos komplementajn kopiajn pecetojn en la ceteraj datumcentroj, kaj ni daŭrigos indeksadon de la datumoj.
- Sekve de tio, la skribo kaj legado de la grapolo iom post iom malboniĝos, sed ĝenerale ĉio funkcios, kvankam malrapide, sed stabile.
Kiel evidentiĝis, ni volis ion tian:
Kaj ni ricevis la jenon:
Kiel ĝi okazis?
Kiam la datumcentro falis, nia mastro fariĝis la botelkolo.
Kial?
Fakte, la majstro havas TaskBatcher, kiu respondecas pri distribui iujn taskojn kaj eventojn en la areto. Ajna noda eliro, ajna promocio de peceto de kopio ĝis primara, ajna tasko por krei peceton ie - ĉio ĉi iras unue al TaskBatcher, kie ĝi estas prilaborita sinsekve kaj en unu fadeno.
En la momento de la retiriĝo de unu datumcentro, montriĝis, ke ĉiuj datumnodoj en la pluvivaj datumcentroj konsideris sian devon informi la majstron "ni perdis tiajn fragmentojn kaj tiajn datumnodojn."
Samtempe, la pluvivaj datumnodoj sendis ĉiujn ĉi tiujn informojn al la nuna majstro kaj provis atendi konfirmon, ke li akceptis ĝin. Ili ne atendis tion, ĉar la majstro ricevis taskojn pli rapide ol li povis respondi. La nodoj eltempigis ripetantajn petojn, kaj la majstro en ĉi tiu momento eĉ ne provis respondi ilin, sed estis tute absorbita en la tasko ordigi petojn laŭ prioritato.
En fina formo, montriĝis, ke la datumnodoj spamis la majstron ĝis la punkto, ke ĝi eniris plenan GC. Post tio, nia majstra rolo moviĝis al iu sekva nodo, absolute la sama afero okazis al ĝi, kaj kiel rezulto la areto tute kolapsis.
Ni faris mezurojn, kaj antaŭ la versio 6.4.0, kie ĉi tio estis riparita, sufiĉis por ni samtempe eligi nur 10 datumnodojn el 360 por tute malŝalti la areton.
Ĝi aspektis kiel ĉi tio:
Post versio 6.4.0, kie ĉi tiu terura cimo estis riparita, datumnodoj ĉesis mortigi la majstron. Sed tio ne igis lin "pli saĝa". Nome: kiam ni eligas 2, 3 aŭ 10 (ajna nombro krom unu) datumnodoj, la majstro ricevas iun unuan mesaĝon kiu diras ke nodo A foriris, kaj provas rakonti nodo B, nodo C pri tio, nodo D.
Kaj nuntempe, ĉi tio povas esti traktita nur per fikso de tempodaŭro por provoj diri iun pri io, egala al ĉirkaŭ 20-30 sekundoj, kaj tiel kontroli la rapidecon de la datumcentro moviĝanta el la areto.
Principe ĉi tio kongruas kun la postuloj, kiuj estis komence prezentitaj al la fina produkto kiel parto de la projekto, sed el la vidpunkto de "pura scienco" ĉi tio estas cimo. Kiu, cetere, estis sukcese riparita de la programistoj en versio 7.2.
Plie, kiam certa datuma nodo estingiĝis, montriĝis, ke disvastigi informojn pri ĝia eliro estis pli grava ol diri al la tuta areto, ke estas tiaj kaj tiaj primaraj fragmentoj sur ĝi (por promocii kopion en alia datumo. centro en la primara, kaj en informoj povus esti skribitaj sur ili).
Tial, kiam ĉio jam estingiĝis, la liberigitaj datumnodoj ne estas tuj markitaj kiel malfreŝaj. Sekve, ni estas devigitaj atendi ĝis ĉiuj ping-oj finiĝos al la liberigitaj datumnodoj, kaj nur post tio nia areto komencas diri al ni, ke tie, tie kaj tie ni devas daŭrigi registri informojn. Vi povas legi pli pri ĉi tio .
Kiel rezulto, la operacio de retiro de datumcentro hodiaŭ daŭras nin ĉirkaŭ 5 minutojn dum hasthoro. Por tia granda kaj mallerta koloso, ĉi tio estas sufiĉe bona rezulto.
Kiel rezulto, ni venis al la sekva decido:
- Ni havas 360 datumnodojn kun 700 gigabajtaj diskoj.
- 60 kunordigantoj por direkti trafikon tra ĉi tiuj samaj datennodoj.
- 40 majstroj kiujn ni lasis kiel speco de heredaĵo ekde versioj antaŭ 6.4.0 - por postvivi la retiron de la datumcentro, ni estis mense pretaj perdi plurajn maŝinojn por esti garantiitaj havi kvorumon de majstroj eĉ en la plej malbona kazo
- Ajnaj provoj kombini rolojn sur unu ujo estis renkontitaj kun la fakto, ke pli aŭ malpli frue la nodo rompiĝus sub ŝarĝo.
- La tuta areto uzas amason de 31 gigabajtoj: ĉiuj provoj redukti la grandecon rezultigis aŭ mortigi kelkajn nodojn en pezaj serĉdemandoj kun la gvida ĵokero aŭ ricevi la ŝaltilon en Elasticsearch mem.
- Krome, por certigi serĉan rendimenton, ni provis konservi la nombron da objektoj en la areto kiel eble plej malgranda, por prilabori kiel eble plej malmultajn eventojn en la botelkolo, kiun ni ricevis en la majstro.
Fine pri monitorado
Por certigi, ke ĉio ĉi funkcias kiel celite, ni kontrolas la jenajn:
- Ĉiu datumnodo raportas al nia nubo, ke ĝi ekzistas, kaj estas tiaj kaj tiaj pecetoj sur ĝi. Kiam ni estingas ion ie, la areto raportas post 2-3 sekundoj, ke en la centro A ni estingis nodojn 2, 3 kaj 4 - tio signifas, ke en aliaj datumcentroj ni neniel povas estingi tiujn nodojn, sur kiuj estas nur unu peceto. foriris.
- Sciante la naturon de la konduto de la majstro, ni tre zorge rigardas la nombron de pritraktataj taskoj. Ĉar eĉ unu ŝtopita tasko, se ĝi ne elĉerpas ĝustatempe, teorie en iu kriz-situacio povas fariĝi la kialo, kial, ekzemple, la promocio de kopia peceto en la primara ne funkcias, tial indeksado ĉesos funkcii.
- Ni ankaŭ tre atente rigardas malfruojn de rubkolektisto, ĉar ni jam havis grandajn malfacilaĵojn pri tio dum optimumigo.
- Malakceptas per fadeno por kompreni anticipe kie estas la botelkolo.
- Nu, normaj metrikoj kiel amaso, RAM kaj I/O.
Konstruante monitoradon, vi devas konsideri la funkciojn de Thread Pool en Elasticsearch. priskribas agordajn opciojn kaj defaŭltajn valorojn por serĉado kaj indeksado, sed tute silentas pri thread_pool.management.Ĉi tiuj fadenoj prilaboras, precipe, demandojn kiel _cat/shards kaj aliajn similajn, kiuj estas konvene uzi dum verkado de monitorado. Ju pli granda la areto, des pli tiaj petoj estas ekzekutitaj po unuo de tempo, kaj la menciita thread_pool.management ne nur ne estas prezentita en la oficiala dokumentaro, sed ankaŭ estas limigita defaŭlte al 5 fadenoj, kiu estas tre rapide forigita, post kiu monitorado ĉesas funkcii ĝuste.
Kion mi volas diri konklude: ni faris ĝin! Ni povis doni al niaj programistoj kaj programistoj ilon kiu, en preskaŭ ajna situacio, povas rapide kaj fidinde provizi informojn pri tio, kio okazas en produktado.
Jes, ĝi montriĝis sufiĉe komplika, sed, tamen, ni sukcesis alĝustigi niajn dezirojn en ekzistantajn produktojn, kiujn ni ne devis fliki kaj reverki por ni mem.
fonto: www.habr.com