Daghang mga tawo ang nakigbisog sa Elasticsearch. Apan unsa ang mahitabo kung gusto nimo kini gamiton sa pagtipig sa mga troso "sa usa ka dako nga gidaghanon"? Ug dili ba usab sakit nga masinati ang kapakyasan sa bisan unsang daghang mga sentro sa datos? Unsang matanga sa arkitektura ang kinahanglan nimong buhaton, ug unsang mga lit-ag ang imong mapandol?
Kami sa Odnoklassniki nakahukom sa paggamit sa elasticsearch aron masulbad ang isyu sa pagdumala sa log, ug karon among gipaambit ang among kasinatian sa Habr: mahitungod sa arkitektura ug mahitungod sa mga lit-ag.
Ako si Pyotr Zaitsev, nagtrabaho ko isip system administrator sa Odnoklassniki. Sa wala pa kana, usa usab ako ka admin, nagtrabaho kauban ang Manticore Search, Sphinx search, Elasticsearch. Tingali, kung adunay lain nga ... pangitaa nga makita, mahimo usab ako nga magtrabaho uban niini. Miapil usab ako sa daghang open source nga mga proyekto sa boluntaryong basehan.
Sa akong pag-abut sa Odnoklassniki, ako walay hunong nga miingon sa interbyu nga ako makatrabaho sa Elasticsearch. Human nako makasabot niini ug makompleto ang pipila ka yanong mga buluhaton, gihatagan ako ug dakong tahas sa pagreporma sa sistema sa pagdumala sa troso nga naglungtad niadtong panahona.
mga kinahanglanon
Ang mga kinahanglanon sa sistema giporma sama sa mosunod:
- Ang Graylog gamiton isip frontend. Tungod kay ang kompanya aduna nay kasinatian sa paggamit niini nga produkto, ang mga programmer ug mga tester nahibalo niini, kini pamilyar ug sayon ββalang kanila.
- Ang gidaghanon sa datos: sa aberids nga 50-80 ka libo nga mga mensahe kada segundo, apan kung adunay maguba, nan ang trapiko dili limitado sa bisan unsa, mahimo kini nga 2-3 milyon nga linya matag segundo
- Sa paghisgot sa mga kustomer sa mga kinahanglanon alang sa katulin sa pagproseso sa mga pangutana sa pagpangita, among naamgohan nga ang tipikal nga sumbanan sa paggamit sa maong sistema mao kini: ang mga tawo nangita og mga log sa ilang aplikasyon sa miaging duha ka adlaw ug dili gusto nga maghulat labaw pa sa usa ka ikaduha alang sa resulta sa usa ka pormula nga pangutana.
- Ang mga administrador miinsistir nga ang sistema dali nga ma-scalable kung gikinahanglan, nga dili kinahanglan nga sila mag-usisa pag-ayo kung giunsa kini molihok.
- Aron ang bugtong buluhaton sa pagmentinar nga gikinahanglan niini nga mga sistema matag karon ug unya mao ang pag-usab sa pipila ka hardware.
- Dugang pa, ang Odnoklassniki adunay usa ka maayo kaayo nga teknikal nga tradisyon: bisan unsang serbisyo nga among gilunsad kinahanglan nga mabuhi sa usa ka kapakyasan sa data center (kalit, wala giplano ug hingpit sa bisan unsang oras).
Ang katapusan nga kinahanglanon sa pagpatuman niini nga proyekto mao ang labing gasto kanamo, nga akong hisgutan sa mas detalyado.
Environment
Nagtrabaho kami sa upat ka mga sentro sa datos, samtang ang mga node sa datos sa Elasticsearch mahimo ra nga makit-an sa tulo (alang sa daghang dili teknikal nga mga hinungdan).
Kini nga upat ka mga sentro sa datos adunay gibana-bana nga 18 ka libo nga lainlaing mga gigikanan sa log - hardware, mga sudlanan, mga virtual nga makina.
Importante nga bahin: ang cluster magsugod sa mga sudlanan dili sa pisikal nga mga makina, apan sa . Ang mga sudlanan gigarantiyahan nga 2 ka mga core, susama sa 2.0Ghz v4, nga adunay posibilidad sa pag-recycle sa nahabilin nga mga cores kung sila walay pulos.
Sa laing pagkasulti:
Topology
Sa sinugdan akong nakita ang kinatibuk-ang porma sa solusyon sama sa mosunod:
- Ang 3-4 nga mga VIP anaa sa luyo sa A-record sa Graylog nga domain, kini ang adres diin gipadala ang mga troso.
- matag VIP usa ka LVS balancer.
- Human niini, ang mga troso moadto sa Graylog nga baterya, ang pipila sa mga datos anaa sa GELF format, ang uban sa syslog format.
- Pagkahuman kining tanan gisulat sa daghang mga batch sa usa ka baterya sa mga coordinator sa Elasticsearch.
- Ug sila, sa baylo, nagpadala sa pagsulat ug pagbasa sa mga hangyo sa may kalabutan nga mga node sa datos.
Terminolohiya
Tingali dili tanan nakasabut sa detalye sa terminolohiya, mao nga gusto nako nga hisgutan kini sa gamay.
Ang Elasticsearch adunay daghang mga matang sa mga node - master, coordinator, data node. Adunay duha ka lain nga mga tipo alang sa lainlaing mga pagbag-o sa log ug komunikasyon tali sa lainlaing mga cluster, apan gigamit ra namon ang mga nalista.
Magtutudlo
Nag-ping kini sa tanang node nga anaa sa cluster, nagmintinar sa pinakabag-o nga cluster map ug nag-apod-apod niini tali sa mga node, nagproseso sa logic sa panghitabo, ug nagpahigayon sa nagkalain-laing matang sa cluster wide housekeeping.
Coordinator
Nagbuhat sa usa ka buluhaton: modawat sa pagbasa o pagsulat sa mga hangyo gikan sa mga kliyente ug rota niini nga trapiko. Kung adunay usa ka hangyo sa pagsulat, lagmit, pangutan-on niini ang master kung unsang bahin sa may kalabutan nga indeks ang kinahanglan ibutang niini, ug i-redirect pa ang hangyo.
Data node
Nagtipig sa datos, nagpahigayon sa mga pangutana sa pagpangita nga nangabot gikan sa gawas ug naghimo sa mga operasyon sa mga shards nga nahimutang niini.
graylog
Kini usa ka butang sama sa usa ka fusion sa Kibana nga adunay Logstash sa usa ka ELK stack. Ang Graylog naghiusa sa usa ka UI ug usa ka pipeline sa pagproseso sa log. Ubos sa tabon, ang Graylog nagpadagan sa Kafka ug Zookeeper, nga naghatag koneksyon sa Graylog ingon usa ka kumpol. Mahimong i-cache sa Graylog ang mga log (Kafka) kung dili magamit ang Elasticsearch ug sublion ang dili malampuson nga pagbasa ug pagsulat sa mga hangyo, paggrupo ug pagmarka sa mga troso sumala sa piho nga mga lagda. Sama sa Logstash, ang Graylog adunay gamit sa pag-usab sa mga laray sa dili pa kini isulat sa Elasticsearch.
Dugang pa, ang Graylog adunay usa ka built-in nga service discovery nga nagtugot, base sa usa ka available nga Elasticsearch node, nga makuha ang tibuok cluster map ug i-filter kini pinaagi sa usa ka piho nga tag, nga nagpaposible sa pagdirekta sa mga hangyo ngadto sa piho nga mga sudlanan.
Biswal kini tan-awon sama niini:
Kini usa ka screenshot gikan sa usa ka piho nga higayon. Dinhi naghimo kami usa ka histogram base sa pangutana sa pagpangita ug gipakita ang mga may kalabotan nga linya.
Mga indeks
Pagbalik sa arkitektura sa sistema, gusto nako nga magpuyo nga mas detalyado kung giunsa namon gitukod ang modelo sa indeks aron kini tanan nagtrabaho sa husto.
Sa dayagram sa ibabaw, kini ang pinakaubos nga lebel: Elasticsearch data nodes.
Ang indeks usa ka dako nga virtual nga entidad nga gilangkoban sa Elasticsearch shards. Sa iyang kaugalingon, ang matag usa sa mga shards walaβy labaw sa usa ka indeks sa Lucene. Ug ang matag indeks sa Lucene, sa baylo, naglangkob sa usa o daghang mga bahin.
Kung nagdesinyo, among gihunahuna nga aron matubag ang kinahanglanon alang sa katulin sa pagbasa sa daghang mga datos, kinahanglan namon nga "ipakaylap" kini nga datos nga parehas sa mga node sa datos.
Kini miresulta sa kamatuoran nga ang gidaghanon sa mga shards kada index (nga adunay mga replika) kinahanglan nga hugot nga katumbas sa gidaghanon sa mga data node. Una, aron masiguro ang usa ka hinungdan sa pagkopya nga katumbas sa duha (nga mao, mahimo natong mawala ang katunga sa cluster). Ug, ikaduha, aron maproseso ang pagbasa ug pagsulat sa mga hangyo sa labing menos katunga sa cluster.
Una namon nga gitino ang oras sa pagtipig ingon 30 ka adlaw.
Ang pag-apod-apod sa mga shards mahimong irepresentar sa grapiko sama sa mosunod:
Ang tibuok itom nga gray nga rektanggulo usa ka indeks. Ang wala nga pula nga kwadro niini mao ang panguna nga shard, ang una sa indeks. Ug ang asul nga kuwadrado usa ka replica shard. Naa sila sa lainlaing mga sentro sa datos.
Kung magdugang kami og laing shard, moadto kini sa ikatulo nga sentro sa datos. Ug, sa katapusan, nakuha namon kini nga istruktura, nga nagpaposible nga mawala ang DC nga wala mawala ang pagkamakanunayon sa datos:
Pagtuyok sa mga indeks, i.e. paghimo og bag-ong index ug pagtangtang sa labing karaan, gihimo namo kini nga katumbas sa 48 ka oras (sumala sa sumbanan sa paggamit sa index: ang katapusang 48 ka oras gipangita kanunay).
Kini nga index rotation interval tungod sa mosunod nga mga rason:
Sa diha nga ang usa ka hangyo sa pagpangita moabut sa usa ka piho nga data node, nan, gikan sa usa ka performance point of view, kini mas mapuslanon kung ang usa ka shard gipangutana, kung ang gidak-on niini ikatandi sa gidak-on sa bat-ang sa node. Kini nagtugot kanimo sa pagpabilin sa "init" nga bahin sa indeks sa usa ka pundok ug dali nga ma-access kini. Kung adunay daghang "mainit nga mga bahin", ang katulin sa pagpangita sa index nadaot.
Sa diha nga ang usa ka node magsugod sa pagpatuman sa usa ka search query sa usa ka shard, kini naggahin ug usa ka gidaghanon sa mga hilo nga katumbas sa gidaghanon sa hyperthreading cores sa pisikal nga makina. Kung ang usa ka pangutana sa pagpangita makaapekto sa daghang mga shards, nan ang gidaghanon sa mga hilo motubo nga proporsyonal. Kini adunay negatibo nga epekto sa katulin sa pagpangita ug negatibo nga makaapekto sa pag-indeks sa bag-ong datos.
Aron mahatagan ang kinahanglan nga latency sa pagpangita, nakahukom kami nga mogamit usa ka SSD. Aron dali nga maproseso ang mga hangyo, ang mga makina nga nag-host niini nga mga sudlanan kinahanglan adunay labing menos 56 ka mga core. Ang numero sa 56 gipili ingon usa ka igo nga kondisyon nga kantidad nga nagtino sa gidaghanon sa mga hilo nga makuha sa Elasticsearch sa panahon sa operasyon. Sa Elasitcsearch, daghang mga parameter sa thread pool direkta nga nagdepende sa gidaghanon sa magamit nga mga cores, nga sa baylo direktang makaapekto sa gikinahanglan nga gidaghanon sa mga node sa cluster sumala sa prinsipyo nga "mas gamay nga mga cores - mas daghang mga node".
Ingon usa ka sangputanan, nahibal-an namon nga sa kasagaran ang usa ka shard adunay gibug-aton nga mga 20 gigabytes, ug adunay 1 ββmga shard matag indeks. Busa, kung atong i-rotate sila kausa sa matag 360 ka oras, nan aduna kitay 48 niini. Ang matag indeks adunay mga datos sulod sa 15 ka adlaw.
Mga sirkito sa pagsulat ug pagbasa sa datos
Atong hisgotan kung giunsa ang pagrekord sa datos niini nga sistema.
Ingnon ta nga ang pipila ka hangyo moabut gikan sa Graylog ngadto sa coordinator. Pananglitan, gusto namong i-index ang 2-3 ka libo nga mga laray.
Ang koordinetor, nga nakadawat usa ka hangyo gikan sa Graylog, nangutana sa agalon: "Sa hangyo sa pag-indeks, espesipiko nga gipiho namon ang usa ka indeks, apan kung diin isulat kini wala gitino."
Ang agalon mitubag: "Isulat kini nga impormasyon ngadto sa shard number 71," human nga kini ipadala direkta ngadto sa may kalabutan nga data node, diin nahimutang ang primary-shard number 71.
Pagkahuman niini ang log sa transaksyon gisundog sa usa ka replica-shard, nga nahimutang sa laing sentro sa datos.
Usa ka hangyo sa pagpangita moabut gikan sa Graylog ngadto sa coordinator. Gi-redirect kini sa coordinator sumala sa index, samtang ang Elasticsearch nag-apod-apod sa mga hangyo tali sa primary-shard ug replica-shard gamit ang round-robin nga prinsipyo.
Ang 180 ka mga node dili patas nga pagtubag, ug samtang sila nagtubag, ang koordinetor nagtigum og impormasyon nga "giluwa" sa mas paspas nga mga node sa datos. Pagkahuman niini, kung ang tanan nga kasayuran miabot na, o ang hangyo nakaabot sa usa ka timeout, kini naghatag sa tanan direkta sa kliyente.
Kining tibuok nga sistema sa kasagaran nagproseso sa mga pangutana sa pagpangita sulod sa katapusang 48 ka oras sa 300-400ms, walay labot niadtong mga pangutana nga adunay nag-unang wildcard.
Mga Bulak nga adunay Elasticsearch: Pag-setup sa Java
Aron mahimo kining tanan sa paagi nga gusto namong orihinal, migugol kami ug dugay kaayong panahon sa pag-debug sa nagkadaiyang mga butang sa cluster.
Ang unang bahin sa mga problema nga nadiskobrehan may kalabutan sa paagi sa Java nga pre-configure pinaagi sa default sa Elasticsearch.
Usa ka problema
Nakita namon ang daghan kaayo nga mga taho nga sa lebel sa Lucene, kung ang mga trabaho sa background nagdagan, ang bahin sa Lucene napakyas nga adunay sayup. Sa parehas nga oras, klaro sa mga troso nga kini usa ka sayup nga OutOfMemoryError. Nakita namon gikan sa telemetry nga libre ang bat-ang, ug dili klaro kung ngano nga napakyas kini nga operasyon.
Nahitabo nga ang Lucene index merges nahitabo sa gawas sa bat-ang. Ug ang mga sudlanan higpit nga limitado sa mga termino sa mga kapanguhaan nga gigamit. Ang heap ra ang mahimong mohaum niini nga mga kahinguhaan (ang kantidad sa heap.size gibana-bana nga katumbas sa RAM), ug pipila ka mga off-heap nga operasyon nahagsa nga adunay sayup nga alokasyon sa panumduman kung sa usa ka hinungdan wala sila mohaum sa ~500MB nga nahabilin sa wala pa ang limitasyon.
Ang pag-ayo gamay ra: ang kantidad sa RAM nga magamit alang sa sudlanan nadugangan, pagkahuman nakalimot kami nga kami adunay ingon nga mga problema.
Duha ka problema
4-5 ka adlaw pagkahuman sa paglansad sa cluster, among namatikdan nga ang mga data node nagsugod matag karon ug unya nga nahulog gikan sa cluster ug gisulod kini pagkahuman sa 10-20 segundos.
Sa diha nga nagsugod kami sa paghunahuna niini, kini nahimo nga kini nga off-heap nga panumduman sa Elasticsearch dili kontrolado sa bisan unsang paagi. Sa dihang gihatagan namo og dugang nga panumduman ang sudlanan, napuno namo ang direkta nga buffer pool sa nagkalain-laing impormasyon, ug kini nahaw-as lamang human gilusad ang klaro nga GC gikan sa Elasticsearch.
Sa pipila ka mga kaso, kini nga operasyon nagkinahanglan og taas nga panahon, ug niining panahona ang cluster nakahimo sa pagmarka niini nga node nga migawas na. Maayo nga gihulagway kini nga problema .
Ang solusyon mao ang mosunod: gilimitahan namo ang abilidad sa Java sa paggamit sa kinabag-an sa memorya sa gawas sa heap para niini nga mga operasyon. Gilimitahan namo kini sa 16 gigabytes (-XX:MaxDirectMemorySize=16g), pagsiguro nga ang klaro nga GC gitawag nga mas kanunay ug mas paspas nga maproseso, sa ingon dili na makaguba sa cluster.
Tulo nga problema
Kung sa imong hunahuna nga ang mga problema sa "mga node nga mibiya sa cluster sa labing wala damha nga higayon" nahuman na, nasayop ka.
Sa dihang among gi-configure ang trabaho gamit ang mga index, among gipili ang mmapfs sa sa mga lab-as nga shards nga adunay maayo nga pagkabahin. Kini usa ka sayup, tungod kay kung gigamit ang mmapfs ang file gi-mapa sa RAM, ug dayon nagtrabaho kami sa na-map nga file. Tungod niini, kini nahimo nga kung ang GC mosulay sa pagpahunong sa mga hilo sa aplikasyon, moadto kami sa safepoint sa dugay nga panahon, ug sa pagpaingon niini, ang aplikasyon mihunong sa pagtubag sa mga hangyo sa agalon bahin sa kung kini buhi. . Tungod niini, nagtuo ang agalon nga wala na ang node sa cluster. Pagkahuman niini, pagkahuman sa 5-10 segundos, nagtrabaho ang tigkolekta sa basura, nabuhi ang node, mosulod pag-usab sa cluster ug magsugod sa pagsugod sa mga shards. Ang tanan gibati kaayo nga "ang produksiyon nga angay kanamo" ug dili angay alang sa bisan unsang seryoso.
Aron mapapas kini nga kinaiya, una namong gibalhin ngadto sa standard niofs, ug unya, sa dihang mibalhin kami gikan sa ikalima nga bersyon sa Elastic ngadto sa ikaunom, among gisulayan ang mga hybridf, diin kini nga problema wala gipadaghan. Mahimo nimong mabasa ang dugang bahin sa mga tipo sa pagtipig .
Ikaupat nga problema
Unya adunay lain nga makaiikag kaayo nga problema nga among gitagad sa usa ka rekord nga oras. Gikuha namo kini sulod sa 2-3 ka bulan tungod kay ang sumbanan niini dili masabtan.
Usahay ang among mga coordinator moadto sa Full GC, kasagaran human sa paniudto, ug dili na mobalik gikan didto. Sa parehas nga oras, kung gi-log ang paglangan sa GC, ingon kini: maayo ang tanan, maayo, maayo, ug unya kalit nga ang tanan grabe kaayo.
Sa sinugdan naghunahuna kami nga kami adunay usa ka daotan nga tiggamit nga naglansad sa usa ka matang sa hangyo nga nagtuktok sa coordinator gikan sa mode sa pagtrabaho. Nag-log kami sa mga hangyo sa dugay nga panahon, naningkamot nga mahibal-an kung unsa ang nahitabo.
Ingon usa ka sangputanan, nahimo nga sa higayon nga ang usa ka tiggamit maglansad sa usa ka dako nga hangyo, ug kini moabut sa usa ka piho nga coordinator sa Elasticsearch, ang pipila nga mga node motubag nga mas dugay kaysa sa uban.
Ug samtang ang coordinator naghulat alang sa tubag gikan sa tanan nga mga node, iyang gitigum ang mga resulta nga gipadala gikan sa mga node nga nakatubag na. Para sa GC, kini nagpasabot nga ang atong mga sumbanan sa paggamit sa tapok dali kaayong mausab. Ug ang GC nga among gigamit dili makasagubang niini nga buluhaton.
Ang bugtong solusyon nga among nakit-an nga nagbag-o sa pamatasan sa cluster sa kini nga sitwasyon mao ang paglalin sa JDK13 ug paggamit sa tigkolekta sa basura sa Shenandoah. Nasulbad niini ang problema, ang among mga coordinator mihunong sa pagkahulog.
Dinhi natapos ang mga problema sa Java ug nagsugod ang mga problema sa bandwidth.
"Berries" nga adunay Elasticsearch: throughput
Ang mga problema sa throughput nagpasabot nga ang among cluster nagtrabaho nga lig-on, apan sa mga peak sa gidaghanon sa mga na-index nga mga dokumento ug sa panahon sa mga maniobra, ang performance dili igo.
Ang una nga simtomas nga nasugatan: sa panahon sa pipila ka mga "pagbuto" sa produksiyon, kung ang usa ka daghan kaayo nga mga troso kalit nga namugna, ang sayup sa pag-indeks nga es_rejected_execution nagsugod sa pagkidlap kanunay sa Graylog.
Kini tungod sa kamatuoran nga ang thread_pool.write.queue sa usa ka data node, hangtud nga ang Elasticsearch makahimo sa pagproseso sa hangyo sa pag-indeks ug pag-upload sa impormasyon ngadto sa shard sa disk, makahimo sa pag-cache lamang sa 200 ka mga hangyo pinaagi sa default. Ug sa Gamay ra ang giingon bahin sa kini nga parameter. Ang pinakataas nga gidaghanon sa mga hilo ug ang default nga gidak-on lamang ang gipakita.
Siyempre, gibalhin namon kini nga kantidad ug nahibal-an ang mga musunud: labi na, sa among pag-setup, hangtod sa 300 nga mga hangyo ang maayo nga naka-cache, ug ang usa ka mas taas nga kantidad napuno sa kamatuoran nga milupad na usab kami sa Full GC.
Dugang pa, tungod kay kini mga batch sa mga mensahe nga moabut sa sulod sa usa ka hangyo, kinahanglan nga i-tweak ang Graylog aron dili kini magsulat kanunay ug sa gagmay nga mga batch, apan sa daghang mga batch o kausa matag 3 segundo kung ang batch dili pa kompleto. Sa kini nga kaso, kini nahimo nga ang kasayuran nga among gisulat sa Elasticsearch mahimong magamit dili sa duha ka segundo, apan sa lima (nga haum kaayo kanamo), apan ang gidaghanon sa mga retray nga kinahanglan buhaton aron mapadayon ang usa ka dako. ang stack sa impormasyon gipakunhod.
Kini mao ang ilabi na nga importante sa mga higayon sa diha nga ang usa ka butang nga nahagsa sa usa ka dapit ug sa kasuko report mahitungod niini, aron nga dili sa usa ka bug-os nga spammed Elastic, ug human sa pipila ka mga panahon - Graylog nodes nga inoperable tungod sa barado buffers.
Dugang pa, sa diha nga kami adunay parehas nga mga pagbuto sa produksiyon, nakadawat kami mga reklamo gikan sa mga programmer ug mga tester: sa higayon nga kinahanglan gyud nila kini nga mga troso, gihatag kini sa hinay kaayo.
Nagsugod sila sa paghunahuna niini. Sa usa ka bahin, klaro nga ang mga pangutana sa pagpangita ug mga pangutana sa pag-indeks giproseso, sa tinuud, sa parehas nga pisikal nga mga makina, ug sa usa ka paagi o lain adunay pipila nga mga drawdown.
Apan kini mahimong partially circumvented tungod sa kamatuoran nga sa ikaunom nga bersyon sa Elasticsearch, nagpakita ang usa ka algorithm nga nagtugot kanimo sa pag-apod-apod sa mga pangutana tali sa mga may kalabutan nga data nodes dili sumala sa random round-robin nga prinsipyo (ang sudlanan nga nag-indeks ug naghupot sa nag-unang -shard mahimong puliki kaayo, wala'y paagi sa pagtubag dayon), apan ipasa kini nga hangyo sa usa ka dili kaayo puno nga sudlanan nga adunay usa ka replica-shard, nga mas paspas nga motubag. Sa laing pagkasulti, miabot kami sa use_adaptive_replica_selection: true.
Ang hulagway sa pagbasa nagsugod nga ingon niini:
Ang transisyon sa kini nga algorithm nagpaposible sa pagpauswag sa oras sa pangutana sa mga higayon nga kami adunay daghang dagan sa mga troso nga isulat.
Sa katapusan, ang nag-unang problema mao ang walay sakit nga pagtangtang sa data center.
Unsa ang gusto namon gikan sa cluster dayon pagkahuman nawala ang koneksyon sa usa ka DC:
- Kung kita adunay usa ka kasamtangan nga agalon sa napakyas nga data center, nan kini mapili pag-usab ug ibalhin isip usa ka papel ngadto sa laing node sa laing DC.
- Ang agalon dali nga tangtangon ang tanan nga dili ma-access nga mga node gikan sa cluster.
- Pinasukad sa nahabilin, masabtan niya: sa nawala nga sentro sa datos nga kami adunay ingon ug ingon nga panguna nga mga shards, dali niya nga i-promote ang mga complementary replica shards sa nahabilin nga mga sentro sa datos, ug magpadayon kami sa pag-index sa datos.
- Ingon usa ka sangputanan niini, ang pagsulat sa cluster ug ang pagbasa sa throughput anam-anam nga madaot, apan sa kinatibuk-an ang tanan molihok, bisan sa hinay, apan lig-on.
Ingon sa nahimo, gusto namon ang usa ka butang nga sama niini:
Ug nakuha namo ang mosunod:
Giunsa kini nahitabo?
Sa dihang nahulog ang data center, ang among agalon nahimong bottleneck.
ΠΠΎΡΠ΅ΠΌΡ?
Ang tinuod mao nga ang agalon adunay TaskBatcher, nga responsable sa pag-apod-apod sa pipila ka mga buluhaton ug mga panghitabo sa cluster. Bisan unsang node exit, bisan unsang promosyon sa usa ka shard gikan sa replika hangtod sa panguna, bisan unsang buluhaton sa paghimo usa ka shard sa usa ka lugar - kining tanan moadto una sa TaskBatcher, diin kini giproseso nga sunud-sunod ug sa usa ka hilo.
Sa panahon sa pag-atras sa usa ka sentro sa datos, nahimo nga ang tanan nga mga node sa datos sa nahabilin nga mga sentro sa datos nag-isip nga ilang katungdanan ang pagpahibalo sa agalon nga "nawala ang ingon ug ingon nga mga shards ug ingon ug ingon nga mga node sa datos."
Sa samang higayon, ang mga buhi nga data node nagpadala sa tanan niini nga impormasyon ngadto sa kasamtangan nga agalon ug misulay sa paghulat alang sa kumpirmasyon nga iyang gidawat kini. Wala sila maghulat niini, tungod kay ang agalon nakadawat sa mga buluhaton nga mas paspas kay sa iyang matubag. Ang mga node nag-time out sa pagbalik-balik nga mga hangyo, ug ang agalon niining panahona wala gani mosulay sa pagtubag niini, apan hingpit nga nasuhop sa buluhaton sa paghan-ay sa mga hangyo pinaagi sa prayoridad.
Sa porma sa terminal, nahimo nga ang mga node sa data nag-spam sa agalon hangtod sa punto nga kini nasulod sa tibuuk nga GC. Pagkahuman niana, ang among agalon nga papel mibalhin sa sunod nga node, hingpit nga parehas ang nahitabo niini, ug ingon usa ka sangputanan ang cluster hingpit nga nahugno.
Nagkuha kami og mga sukod, ug sa wala pa ang bersyon 6.4.0, diin kini naayo, igo na alang kanamo nga dungan nga magpagawas ug 10 ka data node gikan sa 360 aron hingpit nga mapalong ang cluster.
Kini tan-awon sama niini:
Human sa bersyon 6.4.0, diin kining makalilisang nga bug naayo, ang mga data node mihunong sa pagpatay sa agalon. Apan wala kana maghimo kaniya nga "mas maalamon." Sa ato pa: kung magpagawas kita og 2, 3 o 10 (bisan unsang numero gawas sa usa) nga mga node sa datos, ang agalon makadawat sa pipila ka unang mensahe nga nag-ingon nga ang node A mibiya na, ug misulay sa pagsulti sa node B, node C mahitungod niini, node D.
Ug sa pagkakaron, kini mahimo lamang nga atubangon pinaagi sa pagtakda sa usa ka timeout alang sa mga pagsulay sa pagsulti sa usa ka tawo mahitungod sa usa ka butang, nga katumbas sa mga 20-30 segundos, ug sa ingon makontrol ang katulin sa data center nga mobalhin gikan sa cluster.
Sa prinsipyo, kini mohaum sa mga kinahanglanon nga sa sinugdan gipresentar sa katapusan nga produkto isip bahin sa proyekto, apan gikan sa punto sa panglantaw sa "pure science" kini usa ka bug. Nga, sa dalan, malampuson nga giayo sa mga developer sa bersyon 7.2.
Dugang pa, kung ang usa ka piho nga data node migawas, nahimo nga ang pagsabwag sa kasayuran bahin sa paggawas niini labi ka hinungdanon kaysa pagsulti sa tibuuk nga kumpol nga adunay ingon ug ingon nga panguna nga mga shards niini (aron mapauswag ang usa ka replica-shard sa lain nga datos. sentro sa panguna, ug sa impormasyon mahimong isulat niini).
Busa, kung ang tanan nawala na, ang gipagawas nga mga node sa datos dili dayon mamarkahan nga guba. Tungod niini, napugos kami sa paghulat hangtud nga ang tanan nga mga ping ma-time out sa gipagawas nga mga node sa datos, ug pagkahuman nga ang among cluster magsugod sa pagsulti kanamo nga didto, didto, ug didto kinahanglan namon nga ipadayon ang pagrekord sa kasayuran. Makabasa ka ug dugang bahin niini .
Ingon usa ka sangputanan, ang operasyon sa pag-withdraw sa usa ka sentro sa datos karon mokabat sa mga 5 minuto sa oras sa pagdali. Alang sa ingon ka dako ug clumsy colossus, kini usa ka maayo nga sangputanan.
Ingon usa ka sangputanan, nakaabut kami sa mosunod nga desisyon:
- Adunay kami 360 nga data node nga adunay 700 gigabyte nga mga disk.
- 60 ka mga coordinator alang sa pag-ruta sa trapiko pinaagi niining parehas nga mga node sa datos.
- 40 ka mga agalon nga among gibilin isip usa ka matang sa kabilin sukad sa mga bersyon sa wala pa ang 6.4.0 - aron makalahutay sa pag-atras sa data center, kami andam sa mental nga mawad-an og daghang mga makina aron masiguro nga adunay korum sa mga agalon bisan sa ang worst case scenario
- Ang bisan unsang pagsulay sa paghiusa sa mga tahas sa usa ka sudlanan nasugatan sa kamatuoran nga sa madugay o sa madali ang node mabuak ubos sa karga.
- Ang tibuok cluster migamit ug heap.size nga 31 gigabytes: ang tanan nga pagsulay sa pagpakunhod sa gidak-on miresulta sa pagpatay sa pipila ka mga node sa bug-at nga mga pangutana sa pagpangita uban sa nag-unang wildcard o pagkuha sa circuit breaker sa Elasticsearch mismo.
- Dugang pa, aron masiguro ang pasundayag sa pagpangita, gisulayan namon nga ipadayon ang gidaghanon sa mga butang sa cluster nga gamay kutob sa mahimo, aron maproseso ang pipila nga mga panghitabo kutob sa mahimo sa bottleneck nga nakuha namon sa master.
Sa katapusan bahin sa pagmonitor
Aron masiguro nga kining tanan molihok sumala sa katuyoan, among gibantayan ang mga musunud:
- Ang matag data node nagreport sa among panganod nga kini naglungtad, ug adunay ingon ug ingon nga mga shards niini. Kung gipalong namon ang usa ka butang sa usa ka lugar, ang cluster nagtaho pagkahuman sa 2-3 segundos nga sa sentro A among gipalong ang mga node 2, 3, ug 4 - kini nagpasabut nga sa ubang mga sentro sa datos wala kami bisan unsang mga kahimtang nga mapalong ang mga node diin adunay usa ra ka shard. sa wala.
- Nahibal-an ang kinaiya sa pamatasan sa agalon, gitan-aw namon pag-ayo ang gidaghanon sa mga naghulat nga buluhaton. Tungod kay bisan ang usa ka natanggong nga buluhaton, kung dili kini matapos sa oras, sa teoriya sa pipila ka emerhensya nga sitwasyon mahimo nga hinungdan ngano, pananglitan, ang pag-promote sa usa ka replica shard sa panguna dili molihok, mao nga ang pag-indeks mohunong sa pagtrabaho.
- Gitan-aw usab namon pag-ayo ang mga paglangan sa mga tigkolekta sa basura, tungod kay naa na kami daghang mga kalisud niini sa panahon sa pag-optimize.
- Gisalikway pinaagi sa hilo aron masabtan daan kung asa ang bottleneck.
- Aw, standard metrics sama sa heap, RAM ug I/O.
Sa pag-monitor sa pagtukod, kinahanglan nimong tagdon ang mga bahin sa Thread Pool sa Elasticsearch. naghulagway sa mga opsyon sa pag-configure ug mga default nga bili alang sa pagpangita ug pag-indeks, apan hingpit nga hilom mahitungod sa thread_pool.management. Kini nga mga thread nagproseso, ilabi na, mga pangutana sama sa _cat/shards ug uban pang susama, nga sayon ββgamiton sa pagsulat sa pagmonitor. Kon mas dako ang cluster, mas daghan ang ingon nga mga hangyo nga gipatuman kada yunit sa panahon, ug ang gihisgutan nga thread_pool.management dili lamang wala gipresentar sa opisyal nga dokumentasyon, apan limitado usab pinaagi sa default ngadto sa 5 nga mga hilo, nga dali kaayong ilabay, human nga ang pagmonitor mihunong sa pagtrabaho sa husto.
Ang gusto nakong isulti sa konklusyon: gibuhat namo kini! Nakahatag kami sa among mga programmer ug developer og himan nga, sa halos bisan unsang sitwasyon, dali ug kasaligan nga makahatag kasayuran bahin sa kung unsa ang nahitabo sa produksiyon.
Oo, kini nahimo nga labi ka komplikado, apan, bisan pa, nakahimo kami nga ipahiangay ang among mga gusto sa mga naa na nga mga produkto, nga dili namon kinahanglan nga i-patch ug isulat pag-usab alang sa among kaugalingon.
Source: www.habr.com