Jende askok Elasticsearch-ekin borrokatzen du. Baina zer gertatzen da erregistroak "bereziki bolumen handian" gordetzeko erabili nahi duzunean? Eta, gainera, minik al da hainbat datu-zentroren porrota bizitzea? Nolako arkitektura egin behar duzu, eta zer tranparekin topo egingo duzu?
Odnoklassniki-n elasticsearch erabiltzea erabaki genuen erregistroen kudeaketaren arazoa konpontzeko, eta orain gure esperientzia partekatzen dugu Habr-ekin: bai arkitekturari buruz, bai akatsei buruz.
Pyotr Zaitsev naiz, Odnoklassniki-n sistema administratzaile gisa lan egiten dut. Aurretik, administratzaile ere izan nintzen, Manticore Search, Sphinx search, Elasticsearch-ekin lan egin nuen. Agian, beste ... bilaketa bat agertzen bada, seguruenik ere lan egingo dut. Kode irekiko hainbat proiektutan ere parte hartzen dut borondatez.
Odnoklassnikira etorri nintzenean, arduragabekeriaz Elasticsearch-ekin lan egin nezakeela esan nuen elkarrizketan. Ondo ulertu eta zeregin erraz batzuk burutu ondoren, garai hartan zegoen erregistroak kudeatzeko sistema erreformatzeko zeregin handia eman zidaten.
Baldintzak
Sistemaren eskakizunak honela formulatu ziren:
- Graylog frontend gisa erabili behar zen. Konpainiak jada produktu hau erabiltzeko esperientzia zuenez, programatzaileek eta probatzaileek bazekiten, ezaguna eta erosoa zitzaien.
- Datu-bolumena: batez beste 50-80 mila mezu segundoko, baina zerbait apurtzen bada, orduan trafikoa ez da ezer mugatzen, 2-3 milioi linea izan daitezke segundoko
- Bezeroekin bilaketa-kontsultak prozesatzeko abiaduraren eskakizunak eztabaidatu ondoren, sistema hori erabiltzeko ohiko eredua hauxe dela konturatu ginen: jendeak azken bi egunetan bere aplikazioaren erregistroak bilatzen ari dira eta ez dute itxaron nahi. bigarrena formulatutako kontsulta baten emaitzarako.
- Administratzaileek azpimarratu dute sistema erraz eskala daitekeela behar izanez gero, funtzionamenduan sakondu beharrik gabe.
- Beraz, sistema hauek aldian-aldian eskatzen duten mantentze-lan bakarra hardware batzuk aldatzea da.
- Horrez gain, Odnoklassnikik tradizio tekniko bikaina du: abiarazten dugun edozein zerbitzuk datu-zentroko hutsegite batetik bizirik iraun behar du (bat-batekoa, aurreikusi gabekoa eta erabat edozein unetan).
Proiektu hau gauzatzeko azken eskakizuna kostatu zitzaigun gehien, zehatzago hitz egingo dudana.
Asteazkena
Lau datu-zentrotan lan egiten dugu, eta Elasticsearch datu-nodoak hirutan bakarrik egon daitezke (arrazoi ez-teknikoak direla medio).
Lau datu-zentro hauek 18 mila erregistro-iturri ezberdin dituzte gutxi gorabehera: hardwarea, edukiontziak, makina birtualak.
Ezaugarri garrantzitsua: kluster ontzietan hasten da ez makina fisikoetan, baizik . Edukiontziek 2 nukleo bermatuta dituzte, 2.0Ghz v4-ren antzekoa, gainerako nukleoak birziklatzeko aukerarekin, inaktibo egonez gero.
Beste hitz batzutan:
Topologia
Hasieran, irtenbidearen forma orokorra honela ikusi nuen:
- 3-4 VIP Graylog domeinuaren A-erregistroaren atzean daude, hau da erregistroak bidaltzen diren helbidea.
- VIP bakoitza LVS orekatzailea da.
- Horren ondoren, erregistroak Graylog bateriara doaz, datu batzuk GELF formatuan daude, beste batzuk syslog formatuan.
- Ondoren, hori guztia sorta handietan idazten da Elasticsearch koordinatzaileen bateria bati.
- Eta haiek, aldi berean, idazteko eta irakurtzeko eskaerak bidaltzen dituzte dagozkion datu-nodoetara.
terminologia
Beharbada, denek ez dute terminologia zehatz-mehatz ulertzen, beraz, pixka bat sakondu nahiko nuke.
Elasticsearch-ek hainbat nodo mota ditu: maisua, koordinatzailea, datu-nodoa. Beste bi mota daude log eraldaketa desberdinetarako eta kluster ezberdinen arteko komunikaziorako, baina zerrendatutakoak bakarrik erabili ditugu.
Master
Klusterrean dauden nodo guztiei ping egiten die, kluster-mapa eguneratua mantentzen du eta nodoen artean banatzen du, gertaeren logika prozesatzen du eta kluster osoko garbiketa mota desberdinak egiten ditu.
Koordinatzailea
Zeregin bakarra egiten du: bezeroen irakurketa edo idazketa eskaerak onartzen ditu eta trafiko hori bideratzen du. Idazteko eskaera badago, ziurrenik, masterrari galdetuko dio dagokion indizeko zein zatitan jarri behar duen, eta eskaera gehiago birbideratuko du.
Datu-nodoa
Datuak gordetzen ditu, kanpotik iristen diren bilaketa-kontsultak egiten ditu eta bertan dauden zatietan eragiketak egiten ditu.
greylog
Hau Kibanaren fusioa bezalako zerbait da Logstash-ekin ELK pila batean. Graylog-ek UI bat eta erregistroak prozesatzeko kanalizazioa konbinatzen ditu. Kanpaiaren azpian, Graylog-ek Kafka eta Zookeeper exekutatzen ditu, Graylog-i kluster gisa konektibitatea ematen diotenak. Graylog-ek erregistroak gorde ditzake (Kafka) Elasticsearch erabilgarri ez badago eta arrakastarik gabeko irakurketa eta idazketa eskaerak errepikatu, taldekatu eta markatu erregistroak zehaztutako arauen arabera. Logstash-ek bezala, Graylog-ek Elasticsearch-en idatzi aurretik errenkadak aldatzeko funtzionaltasuna du.
Horrez gain, Graylog-ek zerbitzu-aurkikuntza bat dauka eta horrek, eskuragarri dagoen Elasticsearch nodo batean oinarrituta, kluster mapa osoa lortu eta etiketa zehatz baten bidez iragaztea ahalbidetzen du, eskaerak edukiontzi zehatzetara bideratzea ahalbidetzen duena.
Ikusmenean honelako itxura du:
Hau instantzia zehatz bateko pantaila-argazkia da. Hemen bilaketa-kontsultetan oinarritutako histograma bat eraikitzen dugu eta errenkada garrantzitsuak bistaratzen ditugu.
Indizeak
Sistemaren arkitekturara itzuliz, indize-eredua nola eraiki genuen zehatzago azaldu nahiko nuke, guztiak behar bezala funtzionatzeko.
Goiko diagraman, hau da maila baxuena: Elasticsearch datu-nodoak.
Indize bat Elasticsearch shardez osatutako entitate birtual handi bat da. Berez, zati bakoitza Lucene indize bat baino ez da. Eta Lucene indize bakoitza, aldi berean, segmentu bat edo gehiagoz osatuta dago.
Diseinatzerakoan, datu kopuru handi batean irakurtzeko abiaduraren eskakizuna betetzeko, datu horiek datu-nodoetan uniformeki "zabaldu" behar genituela pentsatu genuen.
Horren ondorioz, indize bakoitzeko zati kopurua (erreplikekin) datu-nodo kopuruaren berdina izan behar da. Lehenik eta behin, bi berdineko erreplikazio-faktore bat ziurtatzeko (hau da, kluster erdia gal dezakegu). Eta, bigarrenik, gutxienez klusterraren erdian irakurtzeko eta idazteko eskaerak prozesatzeko.
Lehenengo biltegiratze-denbora 30 egun gisa zehaztu genuen.
Zatiren banaketa grafikoki honela irudika daiteke:
Laukizuzen gris ilun osoa indize bat da. Bertan dagoen ezkerreko karratu gorria zati nagusia da, indizeko lehena. Eta karratu urdina zati erreplika bat da. Datu-zentro ezberdinetan kokatzen dira.
Beste zati bat gehitzen dugunean, hirugarren datu-zentrora joaten da. Eta, azkenean, egitura hau lortzen dugu, datuen koherentzia galdu gabe DC galtzea posible egiten duena:
Indizeen biraketa, hau da. indize berri bat sortuz eta zaharrena ezabatuz, 48 orduren berdina egin dugu (indizearen erabilera ereduaren arabera: azken 48 orduak bilatzen dira gehienetan).
Indizearen biraketa-tarte hau arrazoi hauengatik gertatzen da:
Bilaketa-eskaera bat datu-nodo zehatz batera iristen denean, orduan, errendimenduaren ikuspuntutik, errentagarriagoa da zati bat kontsultatzen denean, bere tamaina nodoaren aldaka-tamainaren parekoa bada. Horri esker, indizearen zati "beroa" pila batean gorde dezakezu eta azkar sartzeko. "Zati beroak" asko daudenean, indizearen bilaketaren abiadura hondatzen da.
Nodo bat zati batean bilaketa-kontsulta exekutatzen hasten denean, makina fisikoaren hyperthreading-nukleoen adina hari-kopurua esleitzen du. Bilaketa-kontsulta batek zati kopuru handi bati eragiten badio, hari kopurua proportzionalki hazten da. Horrek eragin negatiboa du bilaketa-abiaduran eta datu berrien indexazioari negatiboki eragiten dio.
Beharrezko bilaketa-latentzia emateko, SSD bat erabiltzea erabaki genuen. Eskaerak azkar prozesatzeko, edukiontzi hauek hartzen zituzten makinek gutxienez 56 nukleo izan behar zituzten. 56 zifra aukeratu da Elasticsearch-ek funtzionamenduan zehar sortuko duen hari kopurua zehazten duen baldintza nahikoa den balio gisa. Elasitcsearch-en, hari multzoko parametro asko eskuragarri dauden nukleoen kopuruaren araberakoak dira zuzenean, eta horrek zuzenean eragiten dio klusterrean beharrezko nodo kopuruari "nukleo gutxiago - nodo gehiago" printzipioaren arabera.
Ondorioz, zati batek batez beste 20 gigabyte inguruko pisua duela ikusi dugu, eta indize bakoitzeko 1 zati daudela. Horren arabera, 360 orduz behin biratzen baditugu, 48 ditugu. Indize bakoitzak 15 eguneko datuak ditu.
Datuak idazteko eta irakurtzeko zirkuituak
Ikus dezagun nola erregistratzen diren datuak sistema honetan.
Demagun Graylog-etik koordinatzaileari eskaera batzuk iristen zaizkiola. Adibidez, 2-3 mila errenkada indexatu nahi ditugu.
Koordinatzaileak, Graylog-en eskaera jaso ondoren, maisuari galdetzen dio: "Indexatzeko eskaeran, indize bat zehaztu genuen zehazki, baina zein zatitan idatzi ez zen zehaztu".
Maisuak erantzuten du: "Idatzi informazio hau 71 zenbakiko zatian", eta, ondoren, zuzenean dagokion datu-nodora bidaltzen da, 71 zenbaki nagusia dagoen tokira.
Horren ondoren, transakzioen erregistroa beste datu-zentro batean dagoen erreplika-zati batean errepikatzen da.
Bilaketa eskaera bat iristen zaio Graylog-etik koordinatzaileari. Koordinatzaileak indizearen arabera birbideratzen du, eta Elasticsearch-ek, berriz, zati nagusia eta erreplika zatiaren artean banatzen ditu eskaerak round-robin printzipioa erabiliz.
180 nodoek modu irregularrean erantzuten dute, eta erantzuten ari diren bitartean, koordinatzailea datu-nodo azkarragoek dagoeneko "itxuratu" duten informazioa pilatzen ari da. Horren ostean, informazio guztia iristen denean edo eskaerak denbora-muga batera iritsi denean, dena zuzenean ematen dio bezeroari.
Sistema oso honek, batez beste, azken 48 orduetako bilaketa-kontsultak 300-400 ms-tan prozesatzen ditu, komodin nagusia duten kontsultak kenduta.
Loreak Elasticsearch-ekin: Java konfigurazioa
Hasiera batean nahi genuen moduan funtzionatzeko, oso denbora luzea eman genuen klusterreko hainbat gauza arazketan.
Aurkitutako arazoen lehen zatia Elasticsearch-en Java lehenespenez konfiguratuta dagoen moduari dagokio.
Arazo bat
Oso txosten ugari ikusi ditugu Lucene mailan, atzeko planoko lanak abian daudenean, Lucene segmentuak bateratzeak huts egiten duela errore batekin. Aldi berean, erregistroetan argi zegoen OutOfMemoryError errore bat zela. Telemetriatik ikusi genuen aldaka libre zegoela, eta ez zegoen argi ebakuntza horrek zergatik huts egiten zuen.
Agertu zen Lucene indizea batzeak aldakatik kanpo gertatzen direla. Eta edukiontziak nahiko mugatuta daude kontsumitutako baliabideei dagokienez. Baliabide hauetan heap bakarrik sartu zitekeen (heap.size balioa RAMaren berdina zen gutxi gorabehera), eta memoria-esleipen-errore batekin huts egin zuten heap-etik kanpoko eragiketa batzuk, arrazoiren batengatik muga baino lehen geratzen ziren ~ 500MB-etan sartzen ez baziren.
Konponketa nahiko hutsala izan zen: edukiontzirako erabilgarri zegoen RAM kopurua handitu zen, eta ondoren, horrelako arazoak genezala ahaztu genuen.
Bigarren arazoa
Klusterra abiarazi eta 4-5 egun igaro ondoren, datu-nodoak aldian-aldian klustertik ateratzen hasi eta 10-20 segundoren buruan sartzen hasi zirela ohartu ginen.
Asmatzen hasi ginenean, ondorioztatu zen Elasticsearch-en off-heap memoria hori ez dagoela inola ere kontrolatzen. Edukiontziari memoria gehiago eman genionean, zuzeneko buffer multzoak hainbat informaziorekin bete ahal izan genituen, eta Elasticsearch-etik GC esplizitua abiarazi ondoren bakarrik garbitu zen.
Zenbait kasutan, eragiketa honek denbora nahiko luzea izan zuen, eta denbora horretan klusterrak nodo hau jada irtendako gisa markatzea lortu zuen. Arazo hau ondo deskribatuta dago .
Irtenbidea hauxe izan zen: Javaren gaitasuna mugatu genuen pilatik kanpo memoriaren zatirik handiena eragiketa hauetarako erabiltzeko. 16 gigabytera mugatu genuen (-XX:MaxDirectMemorySize=16g), GC esplizitua askoz maizago deitzen zela eta askoz azkarrago prozesatzen zela ziurtatuz, eta, ondorioz, ez zen klusterra desegonkortu.
Hirugarren arazoa
“Nodoak ezusteko momentuan klustertik irteten diren” arazoak amaitu direla uste baduzu, oker zaude.
Indizeekin lana konfiguratu genuenean, mmapfs aukeratu genuen segmentazio handiko zati freskoetan. Hau nahiko hutsala izan zen, mmapfs erabiltzean fitxategia RAM-era mapatzen delako, eta gero mapatutako fitxategiarekin lan egiten dugu. Hori dela eta, GC aplikazioan hariak gelditzen saiatzen denean, denbora luzez joango gara seguru puntura, eta bertara bidean, aplikazioak maisuaren eskaerei erantzutea uzten du bizirik dagoen ala ez. . Horren arabera, masterrak uste du nodoa jada ez dagoela klusterrean. Honen ostean, 5-10 segundoren buruan, zabor-biltzaileak funtzionatzen du, nodoa bizia hartzen du, berriro klusterean sartzen da eta zatiak hasieratzen hasten da. Dena oso “merezi genuen ekoizpena” bezalakoa zen eta ez zen ezer seriorako egokia.
Jokabide hori kentzeko, lehenik niof estandarretara aldatu ginen, eta gero, Elastic-en bosgarren bertsioetatik seigarrenera migratzean, hibridoak probatu genituen, non arazo hau erreproduzitzen ez zen. Biltegiratze motei buruzko informazio gehiago irakur dezakezu .
Lau arazoa
Gero, beste arazo oso interesgarri bat egon zen denbora errekor batean tratatu genuena. 2-3 hilabetez harrapatu genuen bere eredua guztiz ulertezina zelako.
Batzuetan gure koordinatzaileak Full GCra joaten ziren, normalean bazkalostean noizbait, eta ez ziren handik bueltatzen. Aldi berean, GC atzerapena erregistratzean, honelakoa zen: dena ondo doa, ondo, ondo, eta, bat-batean, dena oso gaizki doa.
Hasieran pentsatu genuen erabiltzaile gaizto bat genuela, koordinatzailea lan-modutik atera zuen eskaera mota bat abiarazten zuena. Oso denbora luzez erregistratu genituen eskaerak, gertatzen ari zena asmatu nahian.
Ondorioz, erabiltzaile batek eskaera handi bat abiarazten duen unean eta Elasticsearch koordinatzaile jakin batera iristen den unean, nodo batzuek besteek baino denbora luzeagoan erantzuten dute.
Eta koordinatzailea nodo guztien erantzunaren zain dagoen bitartean, dagoeneko erantzun duten nodoetatik bidalitako emaitzak pilatzen ditu. GCrentzat, horrek esan nahi du gure heap erabilera-ereduak oso azkar aldatzen direla. Eta erabili genuen GC-k ezin izan zion zeregin horri aurre egin.
Egoera honetan klusterraren portaera aldatzeko aurkitu dugun konponketa bakarra JDK13ra migratzea eta Shenandoah zabor-biltzailea erabiltzea da. Honek arazoa konpondu zuen, gure koordinatzaileak erortzeari utzi zioten.
Hemen amaitu ziren Javarekin arazoak eta hasi ziren banda zabalera arazoak.
"Baia" Elasticsearch-ekin: errendimendua
Errendimenduarekin lotutako arazoek gure klusterrak egonkor funtzionatzen duela esan nahi du, baina indexatutako dokumentu-kopuruaren gailurretan eta maniobretan, errendimendua ez da nahikoa.
Aurkitutako lehen sintoma: produkzioko "leherketa" batzuetan, bat-batean erregistro kopuru oso handia sortzen denean, es_rejected_execution indexazio-errorea maiz keinuka hasten da Graylog-en.
Izan ere, thread_pool.write.queue datu-nodo batean, Elasticsearch indexatzeko eskaera prozesatu eta informazioa diskoan kargatzeko gai den unera arte, lehenespenez 200 eskaera bakarrik gorde ditzakeela. Eta barruan Oso gutxi esaten da parametro honi buruz. Hari-kopuru maximoa eta tamaina lehenetsia bakarrik adierazten dira.
Noski, balio hori bihurritzera joan ginen eta honako hau aurkitu genuen: zehazki, gure konfigurazioan, 300 eskaera nahiko ondo gordetzen dira eta balio handiagoa GC osoa hegan egiten dugulako.
Horrez gain, eskaera bakarrean iristen diren mezu sortak direnez, beharrezkoa zen Graylog-a moldatu, sarritan eta sorta txikietan idazteko, baina sorta handitan edo 3 segunduro behin lotea osatu gabe badago. Kasu honetan, Elasticsearch-en idazten dugun informazioa ez bi segundotan, bostetan baizik (nahiko ongi datorkiguna), eskura daitekeela ikusten da (nahiko ongi datorkigu), baizik eta handi bat aurrera eramateko egin behar den birsortze kopurua. informazio pila murrizten da.
Hau bereziki garrantzitsua da zerbaitek nonbait huts egin duen eta horri buruz amorruz ematen duen une horietan, guztiz spamatutako Elastic bat ez lortzeko, eta denbora pixka bat igaro ondoren - Buffer bufferengatik funtzionatzen ez duten Graylog nodoak.
Gainera, produkzioan eztanda hauek izan genituenean, programatzaileen eta probatzaileen kexak jaso genituen: erregistro hauek benetan behar zituzten momentuan, oso poliki ematen zitzaizkien.
Asmatzen hasi ziren. Alde batetik, argi zegoen bai bilaketa-kontsultak, bai indexazio-kontsultak, funtsean, makina fisiko berdinetan prozesatzen zirela, eta modu batera edo bestera zenbait mozketa egongo zirela.
Baina hori partzialki saihestu liteke Elasticsearch-en seigarren bertsioetan, datu-nodo garrantzitsuen artean kontsultak banatzeko aukera ematen duen algoritmo bat agertu zelako, ausazko round-robin printzipioaren arabera (indexatzea egiten duen edukiontzia eta lehen mailakoa gordetzen duena). -shard oso lanpetuta egon daiteke, ez da azkar erantzuteko modurik egongo), baina eskaera hau erreplika-shard duen edukiontzi gutxiago kargatu batera bidaltzea, askoz azkarrago erantzungo duena. Beste era batera esanda, use_adaptive_replica_selection-era iritsi gara: egia.
Irakurketa irudia honela hasten da:
Algoritmo honetarako trantsizioak kontsulta-denbora nabarmen hobetzea ahalbidetu zuen idazteko erregistro-fluxu handia genuen une horietan.
Azkenik, arazo nagusia datu-zentroa minik gabe kentzea izan zen.
Klusterretik nahi genuena DC batekin konexioa galdu eta berehala:
- Huts egin duen datu-zentroan uneko maisu bat badugu, berriro hautatuko da eta rol gisa eramango da beste DC bateko beste nodo batera.
- Maisuak azkar kenduko ditu klusterretik eskuraezinak diren nodo guztiak.
- Gainerakoetan oinarrituta, ulertuko du: galdutako datu-zentroan halako eta halako zati primarioak genituen, azkar sustatuko ditu erreplika zati osagarriak gainerako datu-zentroetan, eta datuak indexatzen jarraituko dugu.
- Horren ondorioz, klusterraren idazketa- eta irakurketa-araubidea apurka-apurka hondatuko da, baina, oro har, dena funtzionatuko du, poliki-poliki bada ere, baina egonkor.
Gauzak horrela, honelako zerbait nahi genuen:
Eta honako hau lortu dugu:
Nola gertatu da hau?
Datu zentroa erori zenean, gure maisua botila-lepo bihurtu zen.
Zergatik?
Kontua da maisuak TaskBatcher bat duela, zeina klusterrean zenbait zeregin eta gertakari banatzeaz arduratzen dena. Edozein nodo-irteera, zati baten edozein sustapen erreplikatik lehenera, zati bat nonbait sortzeko edozein zeregin - hau guztia TaskBatcher-era doa lehenik, non sekuentzialki eta hari batean prozesatzen den.
Datu-zentro bat erretiratu zenean, ondorioztatu zen bizirik dauden datu-zentroetako datu-nodo guztiek maisuari jakinaraztea beren betebeharra zela "halako eta halako zatiak eta halako eta halako datu-nodoak galdu ditugu".
Aldi berean, bizirik dauden datu-nodoek informazio hori guztia uneko maisuari bidali zioten eta onartu zuen baieztapenaren zain itxaron saiatu ziren. Ez zuten horren itxaron, maisuak berak erantzun zezakeen baino azkarrago jasotzen baitzituen zereginak. Nodoek eskaerak errepikatzen zituzten denbora igaro zuten, eta une honetan maisua ez zen haiek erantzuten saiatu ere egin, baina eskaerak lehentasunaren arabera ordenatzeko zereginean erabat barneratuta zegoen.
Terminal moduan, datu-nodoek maisuari spam egin ziotela GC osoa sartu arte. Horren ostean, gure rol nagusia hurrengo nodo batera joan zen, guztiz berdina gertatu zitzaion eta, ondorioz, klusterra erabat erori zen.
Neurketak egin genituen, eta 6.4.0 bertsioa baino lehen, non hau konpondu zen, nahikoa zen aldi berean 10tik 360 datu-nodo soilik ateratzea klusterra erabat itzaltzeko.
Honelako itxura zuen:
6.4.0 bertsioaren ondoren, non akats izugarri hau konpondu zen, datu-nodoek maisua hiltzeari utzi zioten. Baina horrek ez zuen "adimentsuago" bihurtu. Hots: 2, 3 edo 10 (bat ez den edozein zenbaki) datu-nodo ateratzen ditugunean, maisuak A nodoa utzi duela dioen lehen mezu bat jasotzen du, eta B nodoari, C nodoari, D nodoari buruz esaten saiatzen da.
Eta, momentuz, horri aurre egin ahal izango zaio norbaiti zerbaiti buruz kontatzeko saiakerei denbora-muga ezarriz, 20-30 segundo ingurukoa, eta, horrela, klustertik ateratzen den datu-zentroaren abiadura kontrolatu.
Printzipioz, hasiera batean proiektuaren barruan azken produktuari aurkezten zitzaizkion eskakizunetara egokitzen da, baina “zientzia puruaren” ikuspuntutik hau akats bat da. Hori, bide batez, garatzaileek arrakastaz konpondu zuten 7.2 bertsioan.
Gainera, datu-nodo jakin bat itzali zenean, bere irteerari buruzko informazioa zabaltzea garrantzitsuagoa zela kluster osoari esatea baino lehen zatiak zeudela esatea baino (beste datu batean erreplika zati bat sustatzeko. zentroan lehen hezkuntzan, eta informazioan idatz liteke haietan).
Hori dela eta, dena jada hiltzen denean, kaleratutako datu-nodoak ez dira berehala zaharkituta bezala markatzen. Horrenbestez, kaleratutako datu-nodoetarako ping guztiak denbora igaro arte itxaron behar dugu, eta horren ostean bakarrik hasten zaigu gure kluster-a esaten han, han eta hemen informazioa grabatzen jarraitu behar dugula. Honi buruz gehiago irakur dezakezu .
Ondorioz, gaur egun datu-zentro bat erretiratzeko eragiketak 5 minutu inguru hartzen gaitu puntako orduetan. Koloso handi eta baldarrarentzat nahiko emaitza ona da.
Ondorioz, erabaki hau hartu genuen:
- 360 datu-nodo ditugu 700 gigabyte-ko diskoekin.
- Datu-nodo horien bidez trafikoa bideratzeko 60 koordinatzaile.
- 40 aurreko bertsioetatik ondare moduko gisa utzi ditugun 6.4.0 maisu - datu-zentroaren erretiratzean bizirik irauteko, mentalki prestatuta geunden hainbat makina galtzeko, baita maisuen quoruma bermatzeko ere. agertokirik txarrena
- Edukiontzi batean rolak konbinatzeko saiakerak, lehenago edo beranduago nodoa kargapean hautsiko zen.
- Kluster osoak 31 gigabyte-ko heap.size bat erabiltzen du: tamaina murrizteko saiakera guztiek nodo batzuk hiltzea edo Elasticsearch-en bertan etengailua hautsi zuten bilaketa-kontsulta astunetan komodin nagusiarekin.
- Horrez gain, bilaketa-errendimendua ziurtatzeko, klusterreko objektu kopurua ahalik eta txikiena izaten saiatu gara, masterrean lortu dugun botila-lepoan ahalik eta gertakari gutxien prozesatzeko.
Azkenik monitorizazioari buruz
Guzti honek nahi bezala funtzionatzen duela ziurtatzeko, honako hauen jarraipena egiten dugu:
- Datu-nodo bakoitzak gure hodeiari ematen dio existitzen dela, eta halako eta halako zatiak daude bertan. Nonbait zerbait itzaltzen dugunean, klusterrak 2-3 segundoren buruan jakinarazi du A zentroan 2, 3 eta 4 nodoak itzali ditugula; horrek esan nahi du beste datu-zentro batzuetan ezin ditugula inolaz ere itzali zati bakarra duten nodoak. ezker.
- Maisuaren portaeraren nondik norakoak ezagututa, arreta handiz begiratzen dugu zain dauden zereginen kopurua. Trabatuta dagoen zeregin bat ere, denboraz denbora igarotzen ez bada, teorikoki larrialdi egoeraren batean, adibidez, lehen mailako erreplika zati baten sustapena ez dadin funtzionatzen duen arrazoia izan daiteke, eta horregatik indexatzeak funtzionatzeari utziko dio.
- Zabor biltzaileen atzerapenak ere oso ondo aztertzen ditugu, optimizazio garaian dagoeneko zailtasun handiak izan baititugu honekin.
- Hari bidez errefusak aldez aurretik ulertzeko non dagoen botila-lepoa.
- Beno, neurri estandarrak, esate baterako, pila, RAM eta I/O.
Eraikuntzaren monitorizazioan, Elasticsearch-en Thread Pool-en ezaugarriak hartu behar dituzu kontuan. bilaketa eta indexatzeko konfigurazio-aukerak eta balio lehenetsiak deskribatzen ditu, baina thread_pool.management-en inguruan erabat isiltzen da.Hari hauek prozesatzen dituzte, bereziki, _cat/shards eta antzeko beste kontsulta batzuk, monitorizazioa idaztean erabiltzeko erosoak direnak. Zenbat eta handiagoa izan klusterra, orduan eta eskaera gehiago exekutatzen dira denbora-unitate bakoitzeko, eta aipatutako thread_pool.management dokumentazio ofizialean ez ezik, 5 hari ere mugatzen da lehenespenez, oso azkar ezabatzen dena, ondoren. zein monitorizazioak behar bezala funtzionatzeari uzten dion.
Bukatzeko esan nahi dudana: egin dugu! Gure programatzaileei eta garatzaileei, ia edozein egoeratan, ekoizpenean gertatzen ari denari buruzko informazioa azkar eta fidagarrian eman diezaiekeen tresna bat eman ahal izan diegu.
Bai, nahiko konplikatua izan zen, baina, hala ere, gure nahiak lehendik zeuden produktuetan egokitzea lortu genuen, guk geuk adabaki eta berridatzi behar izan ez genituenak.
Iturria: www.habr.com