Maraming tao ang nahihirapan sa Elasticsearch. Ngunit ano ang mangyayari kapag gusto mong gamitin ito upang mag-imbak ng mga log "sa isang partikular na malaking volume"? At hindi rin ba masakit na maranasan ang pagkabigo ng alinman sa ilang mga sentro ng data? Anong uri ng arkitektura ang dapat mong gawin, at anong mga pitfalls ang iyong madadapa?
Kami sa Odnoklassniki ay nagpasya na gumamit ng elasticsearch upang malutas ang isyu ng pamamahala ng log, at ngayon ay ibinabahagi namin ang aming karanasan sa Habr: kapwa tungkol sa arkitektura at tungkol sa mga pitfalls.
Ako si Pyotr Zaitsev, nagtatrabaho ako bilang isang system administrator sa Odnoklassniki. Bago iyon, isa rin akong admin, nagtrabaho sa Manticore Search, Sphinx search, Elasticsearch. Marahil, kung may lalabas na isa pang ...paghahanap, malamang na gagawin ko rin ito. Nakikilahok din ako sa ilang open source na proyekto sa boluntaryong batayan.
Pagdating ko sa Odnoklassniki, walang ingat kong sinabi sa panayam na maaari akong magtrabaho sa Elasticsearch. Matapos kong masanay ito at makumpleto ang ilang simpleng gawain, binigyan ako ng malaking gawain na baguhin ang sistema ng pamamahala ng log na umiiral noong panahong iyon.
Kinakailangan sa
Ang mga kinakailangan sa system ay nabuo tulad ng sumusunod:
- Ang Graylog ay gagamitin bilang frontend. Dahil may karanasan na ang kumpanya sa paggamit ng produktong ito, alam ito ng mga programmer at tester, pamilyar at maginhawa ito sa kanila.
- Dami ng data: sa average na 50-80 libong mga mensahe bawat segundo, ngunit kung may masira, kung gayon ang trapiko ay hindi limitado sa anumang bagay, maaari itong maging 2-3 milyong mga linya bawat segundo
- Napag-usapan sa mga customer ang mga kinakailangan para sa bilis ng pagproseso ng mga query sa paghahanap, napagtanto namin na ang karaniwang pattern ng paggamit ng naturang sistema ay ito: ang mga tao ay naghahanap ng mga log ng kanilang aplikasyon para sa huling dalawang araw at ayaw maghintay ng higit sa isang pangalawa para sa resulta ng isang nabuong query.
- Iginiit ng mga tagapangasiwa na ang sistema ay madaling masusukat kung kinakailangan, nang hindi nangangailangan ng kanilang malalim na pag-aralan kung paano ito gumagana.
- Upang ang tanging gawain sa pagpapanatili na kinakailangan ng mga sistemang ito sa pana-panahon ay ang pagbabago ng ilang hardware.
- Bilang karagdagan, ang Odnoklassniki ay may isang mahusay na teknikal na tradisyon: anumang serbisyo na aming ilulunsad ay dapat makaligtas sa isang pagkabigo sa data center (bigla, hindi planado at ganap na anumang oras).
Ang huling kinakailangan sa pagpapatupad ng proyektong ito ay may pinakamaraming gastos, na tatalakayin ko nang mas detalyado.
Miyerkules
Nagtatrabaho kami sa apat na data center, habang ang Elasticsearch data node ay matatagpuan lamang sa tatlo (para sa ilang hindi teknikal na dahilan).
Ang apat na data center na ito ay naglalaman ng humigit-kumulang 18 libong iba't ibang pinagmumulan ng log - hardware, container, virtual machine.
Mahalagang tampok: nagsisimula ang kumpol sa mga lalagyan hindi sa mga pisikal na makina, ngunit sa . Ang mga container ay ginagarantiyahan ng 2 core, katulad ng 2.0Ghz v4, na may posibilidad na i-recycle ang natitirang mga core kung sila ay idle.
Sa ibang salita:
Topology
Una kong nakita ang pangkalahatang anyo ng solusyon tulad ng sumusunod:
- 3-4 VIP ang nasa likod ng A-record ng Graylog domain, ito ang address kung saan ipinapadala ang mga log.
- bawat VIP ay isang LVS balancer.
- Pagkatapos nito, ang mga log ay mapupunta sa Graylog na baterya, ang ilan sa data ay nasa GELF na format, ang ilan ay nasa syslog na format.
- Pagkatapos ang lahat ng ito ay nakasulat sa malalaking batch sa isang baterya ng mga Elasticsearch coordinator.
- At sila naman ay nagpapadala ng mga kahilingan sa pagsulat at pagbabasa sa mga nauugnay na data node.
terminolohiya
Marahil hindi lahat ay nauunawaan nang detalyado ang terminolohiya, kaya nais kong pag-isipan ito nang kaunti.
Ang Elasticsearch ay may ilang uri ng mga node - master, coordinator, data node. Mayroong dalawang iba pang mga uri para sa iba't ibang pagbabago ng log at komunikasyon sa pagitan ng iba't ibang mga kumpol, ngunit ginamit lang namin ang mga nakalista.
Panginoon
Pina-ping nito ang lahat ng node na nasa cluster, nagpapanatili ng up-to-date na cluster map at ipinamahagi ito sa pagitan ng mga node, nagpoproseso ng event logic, at nagsasagawa ng iba't ibang uri ng cluster wide housekeeping.
Coordinator
Gumagawa ng isang solong gawain: tumatanggap ng mga kahilingan sa pagbasa o pagsulat mula sa mga kliyente at ruta ang trapikong ito. Kung sakaling mayroong kahilingan sa pagsulat, malamang, tatanungin nito ang master kung aling bahagi ng nauugnay na index ang dapat nitong ilagay, at ire-redirect pa ang kahilingan.
Data node
Nag-iimbak ng data, nagsasagawa ng mga query sa paghahanap na dumarating mula sa labas at nagsasagawa ng mga operasyon sa mga shards na matatagpuan dito.
graylog
Ito ay tulad ng isang pagsasanib ng Kibana sa Logstash sa isang ELK stack. Pinagsasama ng Graylog ang parehong UI at isang pipeline sa pagproseso ng log. Sa ilalim ng hood, pinapatakbo ng Graylog ang Kafka at Zookeeper, na nagbibigay ng koneksyon sa Graylog bilang isang cluster. Maaaring i-cache ng Graylog ang mga log (Kafka) kung sakaling hindi available ang Elasticsearch at ulitin ang hindi matagumpay na mga kahilingan sa pagbasa at pagsulat, pangkat at markahan ang mga log ayon sa tinukoy na mga panuntunan. Tulad ng Logstash, may functionality ang Graylog na baguhin ang mga row bago isulat ang mga ito sa Elasticsearch.
Bilang karagdagan, ang Graylog ay may built-in na pagtuklas ng serbisyo na nagbibigay-daan, batay sa isang available na Elasticsearch node, na makuha ang buong cluster map at i-filter ito sa pamamagitan ng isang partikular na tag, na ginagawang posible na idirekta ang mga kahilingan sa mga partikular na container.
Sa paningin, ganito ang hitsura nito:
Ito ay isang screenshot mula sa isang partikular na pagkakataon. Dito kami bumuo ng histogram batay sa query sa paghahanap at nagpapakita ng mga nauugnay na row.
Mga Index
Pagbabalik sa arkitektura ng system, gusto kong mag-detalye nang mas detalyado kung paano namin binuo ang modelo ng index upang gumana nang tama ang lahat.
Sa diagram sa itaas, ito ang pinakamababang antas: Elasticsearch data nodes.
Ang index ay isang malaking virtual entity na binubuo ng mga Elasticsearch shards. Sa sarili nito, ang bawat isa sa mga shards ay hindi hihigit sa isang Lucene index. At ang bawat Lucene index, sa turn, ay binubuo ng isa o higit pang mga segment.
Kapag nagdidisenyo, naisip namin na upang matugunan ang kinakailangan para sa bilis ng pagbabasa sa isang malaking halaga ng data, kailangan naming "ipakalat" ang data na ito nang pantay-pantay sa mga node ng data.
Nagresulta ito sa katotohanan na ang bilang ng mga shards bawat index (na may mga replika) ay dapat na mahigpit na katumbas ng bilang ng mga node ng data. Una, upang matiyak ang isang kadahilanan ng pagtitiklop na katumbas ng dalawa (iyon ay, maaari nating mawala ang kalahati ng kumpol). At, pangalawa, upang maproseso ang mga kahilingan sa pagbasa at pagsulat sa hindi bababa sa kalahati ng cluster.
Una naming tinukoy ang oras ng imbakan bilang 30 araw.
Ang pamamahagi ng mga shards ay maaaring ilarawan nang grapiko tulad ng sumusunod:
Ang buong dark gray na parihaba ay isang index. Ang kaliwang pulang parisukat dito ay ang pangunahing shard, ang una sa index. At ang asul na parisukat ay isang replica shard. Ang mga ito ay matatagpuan sa iba't ibang mga sentro ng data.
Kapag nagdagdag kami ng isa pang shard, pupunta ito sa ikatlong data center. At, sa huli, nakuha namin ang istrukturang ito, na ginagawang posible na mawala ang DC nang hindi nawawala ang pagkakapare-pareho ng data:
Pag-ikot ng mga index, i.e. paggawa ng bagong index at pagtanggal ng pinakaluma, ginawa namin itong katumbas ng 48 oras (ayon sa pattern ng paggamit ng index: ang huling 48 oras ay madalas na hinahanap).
Ang index rotation interval na ito ay dahil sa mga sumusunod na dahilan:
Kapag ang isang kahilingan sa paghahanap ay dumating sa isang partikular na data node, kung gayon, mula sa isang pananaw sa pagganap, ito ay mas kumikita kapag ang isang shard ay na-query, kung ang laki nito ay maihahambing sa laki ng balakang ng node. Ito ay nagbibigay-daan sa iyong panatilihin ang "mainit" na bahagi ng index sa isang bunton at mabilis na ma-access ito. Kapag maraming "mainit na bahagi", ang bilis ng paghahanap sa index ay bumababa.
Kapag nagsimulang magsagawa ang isang node ng query sa paghahanap sa isang shard, naglalaan ito ng bilang ng mga thread na katumbas ng bilang ng mga hyperthreading core ng pisikal na makina. Kung ang isang query sa paghahanap ay nakakaapekto sa isang malaking bilang ng mga shards, ang bilang ng mga thread ay lumalaki nang proporsyonal. Ito ay may negatibong epekto sa bilis ng paghahanap at negatibong nakakaapekto sa pag-index ng bagong data.
Upang maibigay ang kinakailangang latency sa paghahanap, nagpasya kaming gumamit ng SSD. Upang mabilis na maproseso ang mga kahilingan, ang mga machine na nagho-host ng mga container na ito ay kailangang magkaroon ng hindi bababa sa 56 na mga core. Ang figure ng 56 ay pinili bilang isang kondisyon na sapat na halaga na tumutukoy sa bilang ng mga thread na bubuo ng Elasticsearch sa panahon ng operasyon. Sa Elasitcsearch, maraming mga parameter ng thread pool ang direktang nakadepende sa bilang ng mga available na core, na direktang nakakaapekto sa kinakailangang bilang ng mga node sa cluster ayon sa prinsipyong "mas kaunting mga core - mas maraming node".
Bilang isang resulta, nalaman namin na sa karaniwan ang isang shard ay tumitimbang ng humigit-kumulang 20 gigabytes, at mayroong 1 ββshards bawat index. Alinsunod dito, kung paikutin natin ang mga ito isang beses bawat 360 oras, mayroon tayong 48 sa kanila. Ang bawat index ay naglalaman ng data para sa 15 araw.
Pagsusulat ng data at pagbabasa ng mga circuit
Alamin natin kung paano naitala ang data sa sistemang ito.
Sabihin nating may dumating na kahilingan mula sa Graylog patungo sa coordinator. Halimbawa, gusto naming mag-index ng 2-3 thousand row.
Ang coordinator, na nakatanggap ng isang kahilingan mula sa Graylog, ay nagtanong sa master: "Sa kahilingan sa pag-index, partikular na tinukoy namin ang isang index, ngunit kung saan isusulat ito ay hindi tinukoy."
Tumugon ang master: "Isulat ang impormasyong ito sa shard number 71," pagkatapos nito ay direktang ipinadala sa nauugnay na data node, kung saan matatagpuan ang primary-shard number 71.
Pagkatapos nito, ang log ng transaksyon ay ginagaya sa isang replica-shard, na matatagpuan sa isa pang data center.
Dumating ang isang kahilingan sa paghahanap mula sa Graylog patungo sa coordinator. Inire-redirect ito ng coordinator ayon sa index, habang ang Elasticsearch ay namamahagi ng mga kahilingan sa pagitan ng primary-shard at replica-shard gamit ang round-robin na prinsipyo.
Ang 180 node ay tumutugon nang hindi pantay, at habang sila ay tumutugon, ang coordinator ay nag-iipon ng impormasyon na "nailuwa na" ng mas mabilis na mga node ng data. Pagkatapos nito, kapag dumating na ang lahat ng impormasyon, o umabot na sa timeout ang kahilingan, direktang ibibigay nito ang lahat sa kliyente.
Ang buong system na ito sa average ay nagpoproseso ng mga query sa paghahanap para sa huling 48 oras sa 300-400ms, hindi kasama ang mga query na iyon na may nangungunang wildcard.
Mga Bulaklak na may Elasticsearch: Pag-setup ng Java
Para gumana ang lahat sa paraang orihinal na gusto namin, gumugol kami ng napakatagal na panahon sa pag-debug ng iba't ibang uri ng mga bagay sa cluster.
Ang unang bahagi ng mga problemang natuklasan ay nauugnay sa paraan ng pag-pre-configure ng Java bilang default sa Elasticsearch.
Problema isa
Nakakita kami ng napakalaking bilang ng mga ulat na sa antas ng Lucene, kapag tumatakbo ang mga trabaho sa background, nabigo ang pagsasama ng segment ng Lucene nang may error. Kasabay nito, malinaw sa mga log na isa itong OutOfMemoryError error. Nakita namin mula sa telemetry na ang balakang ay libre, at hindi malinaw kung bakit nabigo ang operasyong ito.
Ito ay lumabas na ang Lucene index merges ay nangyayari sa labas ng balakang. At ang mga lalagyan ay medyo mahigpit na limitado sa mga tuntunin ng mga mapagkukunang natupok. Tanging heap lang ang maaaring magkasya sa mga mapagkukunang ito (ang halaga ng heap.size ay humigit-kumulang katumbas ng RAM), at ang ilang mga off-heap na operasyon ay nag-crash na may error sa paglalaan ng memorya kung sa ilang kadahilanan ay hindi sila umaangkop sa ~500MB na nanatili bago ang limitasyon.
Ang pag-aayos ay medyo maliit: ang halaga ng RAM na magagamit para sa lalagyan ay nadagdagan, pagkatapos nito nakalimutan namin na mayroon pa kaming mga ganoong problema.
Dalawang problema
4-5 araw pagkatapos ng paglunsad ng cluster, napansin namin na ang mga node ng data ay nagsimulang pana-panahong mahulog sa labas ng cluster at ipasok ito pagkatapos ng 10-20 segundo.
Noong sinimulan naming alamin, lumabas na ang off-heap memory na ito sa Elasticsearch ay hindi kinokontrol sa anumang paraan. Kapag nagbigay kami ng mas maraming memorya sa lalagyan, napunan namin ang mga direktang buffer pool ng iba't ibang impormasyon, at na-clear lang ito pagkatapos na mailunsad ang tahasang GC mula sa Elasticsearch.
Sa ilang mga kaso, ang operasyon na ito ay tumagal ng medyo mahabang panahon, at sa panahong ito ay nagawa ng cluster na markahan ang node na ito bilang nakalabas na. Ang problemang ito ay mahusay na inilarawan .
Ang solusyon ay ang mga sumusunod: nilimitahan namin ang kakayahan ng Java na gamitin ang karamihan ng memorya sa labas ng heap para sa mga operasyong ito. Nilimitahan namin ito sa 16 gigabytes (-XX:MaxDirectMemorySize=16g), tinitiyak na ang tahasang GC ay tinawag nang mas madalas at mas mabilis na naproseso, at sa gayon ay hindi na destabilize ang cluster.
Ikatlong problema
Kung sa tingin mo ay tapos na ang mga problema sa "mga node na umaalis sa cluster sa hindi inaasahang sandali", nagkakamali ka.
Kapag na-configure namin ang trabaho gamit ang mga index, pinili namin ang mmapfs sa sa mga sariwang shards na may mahusay na segmentation. Ito ay isang pagkakamali, dahil kapag gumagamit ng mmapfs ang file ay nakamapa sa RAM, at pagkatapos ay nagtatrabaho kami sa nakamapang file. Dahil dito, lumalabas na kapag sinubukan ng GC na ihinto ang mga thread sa application, pumunta kami sa safepoint sa napakatagal na panahon, at habang papunta dito, huminto ang application sa pagtugon sa mga kahilingan ng master tungkol sa kung ito ay buhay. . Alinsunod dito, naniniwala ang master na ang node ay wala na sa cluster. Pagkatapos nito, pagkatapos ng 5-10 segundo, gumagana ang kolektor ng basura, nabubuhay ang node, muling pumasok sa kumpol at nagsimulang mag-initialize ng mga shards. Ang lahat ng ito ay parang "ang produksyon na nararapat sa atin" at hindi angkop para sa anumang seryoso.
Upang maalis ang pag-uugaling ito, lumipat muna kami sa mga karaniwang niof, at pagkatapos, nang lumipat kami mula sa ikalimang bersyon ng Elastic hanggang sa ikaanim, sinubukan namin ang mga hybridf, kung saan hindi na-reproduce ang problemang ito. Maaari kang magbasa nang higit pa tungkol sa mga uri ng imbakan .
Problema apat
Pagkatapos ay may isa pang napaka-kagiliw-giliw na problema na aming tinatrato para sa isang record na oras. Nahuli namin ito sa loob ng 2-3 buwan dahil ang pattern nito ay ganap na hindi maintindihan.
Minsan ang aming mga coordinator ay pumunta sa Full GC, kadalasan pagkatapos ng tanghalian, at hindi na bumalik mula doon. Kasabay nito, kapag nag-log ang pagkaantala ng GC, ganito ang hitsura: lahat ay maayos, mabuti, mabuti, at pagkatapos ay biglang ang lahat ay nangyayari nang napakasama.
Noong una, naisip namin na mayroon kaming masamang user na naglulunsad ng ilang uri ng kahilingan na nagpaalis sa coordinator sa working mode. Nag-log kami ng mga kahilingan nang napakatagal, sinusubukang malaman kung ano ang nangyayari.
Bilang isang resulta, ito ay lumabas na sa sandaling ang isang gumagamit ay naglunsad ng isang malaking kahilingan, at nakarating ito sa isang partikular na Elasticsearch coordinator, ang ilang mga node ay tumutugon nang mas matagal kaysa sa iba.
At habang naghihintay ang coordinator ng tugon mula sa lahat ng mga node, iniipon niya ang mga resulta na ipinadala mula sa mga node na tumugon na. Para sa GC, nangangahulugan ito na ang aming mga pattern ng paggamit ng heap ay mabilis na nagbabago. At ang GC na ginamit namin ay hindi nakayanan ang gawaing ito.
Ang tanging pag-aayos na nakita namin upang baguhin ang gawi ng cluster sa sitwasyong ito ay ang paglipat sa JDK13 at paggamit ng Shenandoah garbage collector. Nalutas nito ang problema, ang aming mga coordinator ay tumigil sa pagbagsak.
Dito natapos ang mga problema sa Java at nagsimula ang mga problema sa bandwidth.
"Berries" na may Elasticsearch: throughput
Ang mga problema sa throughput ay nangangahulugan na ang aming cluster ay gumagana nang matatag, ngunit sa mga taluktok sa bilang ng mga naka-index na dokumento at sa panahon ng mga maniobra, ang pagganap ay hindi sapat.
Ang unang sintomas na naranasan: sa ilang "pagsabog" sa produksyon, kapag ang isang napakalaking bilang ng mga log ay biglang nabuo, ang error sa pag-index na es_rejected_execution ay magsisimulang mag-flash nang madalas sa Graylog.
Ito ay dahil sa katotohanan na ang thread_pool.write.queue sa isang data node, hanggang sa sandaling maproseso ng Elasticsearch ang kahilingan sa pag-index at mag-upload ng impormasyon sa shard sa disk, ay makaka-cache lamang ng 200 kahilingan bilang default. At sa Napakakaunting sinabi tungkol sa parameter na ito. Tanging ang maximum na bilang ng mga thread at ang default na laki ay ipinahiwatig.
Siyempre, pinilit namin ang halagang ito at nalaman namin ang sumusunod: partikular, sa aming setup, hanggang sa 300 kahilingan ang na-cache nang maayos, at ang mas mataas na halaga ay puno ng katotohanang muli kaming lumipad sa Full GC.
Bilang karagdagan, dahil ito ay mga batch ng mga mensahe na dumarating sa loob ng isang kahilingan, kinailangan itong i-tweak ang Graylog upang hindi ito madalas at maliliit na batch, ngunit sa malalaking batch o isang beses bawat 3 segundo kung hindi pa rin kumpleto ang batch. Sa kasong ito, lumalabas na ang impormasyong isinulat namin sa Elasticsearch ay magagamit hindi sa loob ng dalawang segundo, ngunit sa lima (na angkop sa amin), ngunit ang bilang ng mga muling pagbabalik na kailangang gawin upang maisulong ang isang malaking nababawasan ang stack ng impormasyon.
Ito ay lalong mahalaga sa mga sandaling iyon kapag ang isang bagay ay nag-crash sa isang lugar at galit na galit na nag-uulat tungkol dito, upang hindi makakuha ng ganap na spammed Elastic, at pagkaraan ng ilang oras - Mga Graylog node na hindi mapapagana dahil sa mga barado na buffer.
Bilang karagdagan, noong nagkaroon kami ng parehong mga pagsabog sa produksyon, nakatanggap kami ng mga reklamo mula sa mga programmer at tester: sa sandaling talagang kailangan nila ang mga log na ito, nabigyan sila ng napakabagal.
Sinimulan nilang malaman ito. Sa isang banda, malinaw na ang parehong mga query sa paghahanap at mga query sa pag-index ay naproseso, sa pangkalahatan, sa parehong mga pisikal na makina, at sa isang paraan o iba pa ay magkakaroon ng ilang mga drawdown.
Ngunit ito ay maaaring bahagyang maiiwasan dahil sa katotohanan na sa ika-anim na bersyon ng Elasticsearch ay lumitaw ang isang algorithm na nagbibigay-daan sa iyong ipamahagi ang mga query sa pagitan ng mga nauugnay na data node na hindi ayon sa random na round-robin na prinsipyo (ang lalagyan na nag-i-index at may hawak ng pangunahing- Ang shard ay maaaring maging napaka-abala, walang paraan upang mabilis na tumugon), ngunit upang ipasa ang kahilingang ito sa isang hindi gaanong na-load na lalagyan na may isang replica-shard, na tutugon nang mas mabilis. Sa madaling salita, nakarating kami sa use_adaptive_replica_selection: true.
Ang larawan ng pagbabasa ay nagsisimulang magmukhang ganito:
Ang paglipat sa algorithm na ito ay naging posible upang makabuluhang mapabuti ang oras ng query sa mga sandaling iyon kung saan mayroon kaming malaking daloy ng mga log na isusulat.
Sa wakas, ang pangunahing problema ay ang walang sakit na pag-alis ng data center.
Ano ang gusto namin mula sa cluster kaagad pagkatapos mawalan ng koneksyon sa isang DC:
- Kung mayroon kaming kasalukuyang master sa nabigong data center, muli itong pipiliin at ililipat bilang isang papel sa isa pang node sa isa pang DC.
- Mabilis na aalisin ng master ang lahat ng hindi naa-access na mga node mula sa kumpol.
- Batay sa mga natitira, mauunawaan niya: sa nawalang data center mayroon kaming ganito at ganoong mga pangunahing shards, mabilis niyang ipo-promote ang mga complementary replica shards sa mga natitirang data center, at ipagpapatuloy namin ang pag-index ng data.
- Bilang resulta nito, unti-unting bababa ang pagsusulat at pagbabasa ng cluster, ngunit sa pangkalahatan ay gagana ang lahat, kahit na mabagal, ngunit matatag.
Tulad ng nangyari, gusto namin ng ganito:
At nakuha namin ang sumusunod:
Paano ito nangyari?
Nang bumagsak ang data center, naging bottleneck ang aming master.
Bakit?
Ang katotohanan ay ang master ay may TaskBatcher, na responsable para sa pamamahagi ng ilang mga gawain at kaganapan sa kumpol. Anumang paglabas ng node, anumang pag-promote ng isang shard mula sa replica hanggang sa pangunahin, anumang gawain upang lumikha ng isang shard sa isang lugar - ang lahat ng ito ay mauuna sa TaskBatcher, kung saan ito ay pinoproseso nang sunud-sunod at sa isang thread.
Sa oras ng pag-withdraw ng isang data center, lumabas na ang lahat ng mga data node sa mga nakaligtas na data center ay itinuturing na kanilang tungkulin na ipaalam sa master na "nawalan kami ng ganoon at ganoong mga shards at ganoon at ganoong mga data node."
Kasabay nito, ang mga nakaligtas na data node ay nagpadala ng lahat ng impormasyong ito sa kasalukuyang master at sinubukang maghintay para sa kumpirmasyon na tinanggap niya ito. Hindi nila ito hinintay, dahil ang master ay nakatanggap ng mga gawain nang mas mabilis kaysa sa masasagot niya. Ang mga node ay nag-time out ng paulit-ulit na mga kahilingan, at ang master sa oras na ito ay hindi man lang sinubukang sagutin ang mga ito, ngunit ganap na nasisipsip sa gawain ng pag-uuri ng mga kahilingan ayon sa priyoridad.
Sa terminal form, lumabas na ang mga data node ay nag-spam sa master hanggang sa punto na napunta ito sa buong GC. Pagkatapos nito, ang aming master role ay lumipat sa ilang susunod na node, ganap na pareho ang nangyari dito, at bilang isang resulta ang cluster ay ganap na gumuho.
Nagsagawa kami ng mga sukat, at bago ang bersyon 6.4.0, kung saan ito ay naayos, sapat na para sa amin na sabay-sabay na mag-output lamang ng 10 data node mula sa 360 upang ganap na maisara ang cluster.
Ito ay mukhang ganito:
Pagkatapos ng bersyon 6.4.0, kung saan naayos ang kakila-kilabot na bug na ito, huminto ang mga data node sa pagpatay sa master. Ngunit hindi iyon naging "mas matalino." Namely: kapag nag-output tayo ng 2, 3 o 10 (anumang numero maliban sa isa) data node, natatanggap ng master ang ilang unang mensahe na nagsasabing umalis na ang node A, at sinusubukang sabihin ang node B, node C tungkol dito, node D.
At sa ngayon, maaari lang itong matugunan sa pamamagitan ng pagtatakda ng timeout para sa mga pagtatangkang sabihin sa isang tao ang tungkol sa isang bagay, katumbas ng humigit-kumulang 20-30 segundo, at sa gayon ay kontrolin ang bilis ng paglipat ng data center palabas ng cluster.
Sa prinsipyo, umaangkop ito sa mga kinakailangan na unang ipinakita sa huling produkto bilang bahagi ng proyekto, ngunit mula sa punto ng view ng "purong agham" ito ay isang bug. Na, sa pamamagitan ng paraan, ay matagumpay na naayos ng mga developer sa bersyon 7.2.
Bukod dito, nang lumabas ang isang partikular na data node, lumabas na ang pagpapakalat ng impormasyon tungkol sa paglabas nito ay mas mahalaga kaysa sa pagsasabi sa buong cluster na mayroong ganito at ganoong mga pangunahing-shards dito (upang mag-promote ng replica-shard sa ibang data center sa primary, at sa impormasyon ay maaaring nakasulat sa kanila).
Samakatuwid, kapag ang lahat ay nawala na, ang mga inilabas na data node ay hindi agad mamarkahan bilang lipas. Alinsunod dito, napipilitan kaming maghintay hanggang ang lahat ng mga ping ay mag-time out sa mga inilabas na node ng data, at pagkatapos lamang na ang aming cluster ay magsisimulang sabihin sa amin na doon, doon, at doon kailangan naming ipagpatuloy ang pag-record ng impormasyon. Maaari mong basahin ang higit pa tungkol dito .
Bilang resulta, ang pagpapatakbo ng pag-withdraw ng data center ngayon ay tumatagal ng humigit-kumulang 5 minuto sa oras ng rush hour. Para sa tulad ng isang malaki at clumsy colossus, ito ay isang magandang resulta.
Bilang resulta, dumating kami sa sumusunod na desisyon:
- Mayroon kaming 360 ββdata node na may 700 gigabyte disk.
- 60 coordinator para sa pagruruta ng trapiko sa parehong mga node ng data na ito.
- 40 masters na iniwan namin bilang isang uri ng legacy mula noong mga bersyon bago ang 6.4.0 - upang makaligtas sa pag-withdraw ng data center, handa kaming mawalan ng ilang mga makina upang matiyak na magkaroon ng isang korum ng mga master kahit na sa ang pinakamasamang senaryo ng kaso
- Ang anumang mga pagtatangka na pagsamahin ang mga tungkulin sa isang lalagyan ay natugunan ng katotohanan na maaga o huli ay masisira ang node sa ilalim ng pagkarga.
- Ang buong cluster ay gumagamit ng heap.size na 31 gigabytes: lahat ng pagtatangka na bawasan ang laki ay nagresulta sa alinman sa pagpatay sa ilang mga node sa mabibigat na query sa paghahanap gamit ang nangungunang wildcard o pagkuha ng circuit breaker sa Elasticsearch mismo.
- Bilang karagdagan, upang matiyak ang pagganap ng paghahanap, sinubukan naming panatilihing maliit hangga't maaari ang bilang ng mga bagay sa cluster, upang maproseso ang kaunting mga kaganapan hangga't maaari sa bottleneck na nakuha namin sa master.
Panghuli tungkol sa pagsubaybay
Upang matiyak na gumagana ang lahat ng ito ayon sa nilalayon, sinusubaybayan namin ang sumusunod:
- Ang bawat node ng data ay nag-uulat sa aming cloud na ito ay umiiral, at mayroong ganoon at ganoong mga shards dito. Kapag pinapatay namin ang isang bagay sa isang lugar, ang cluster ay nag-uulat pagkatapos ng 2-3 segundo na sa gitna A ay pinatay namin ang mga node 2, 3, at 4 - nangangahulugan ito na sa iba pang mga data center, hindi namin maaaring patayin ang mga node kung saan mayroon lamang isang shard sa anumang pagkakataon. umalis.
- Alam ang likas na katangian ng pag-uugali ng master, tinitingnan namin nang mabuti ang bilang ng mga nakabinbing gawain. Dahil kahit isang natigil na gawain, kung hindi ito mag-time out sa oras, ayon sa teorya sa ilang sitwasyong pang-emergency ay maaaring maging dahilan kung bakit, halimbawa, ang pag-promote ng isang replica shard sa primary ay hindi gagana, kaya naman hihinto sa paggana ang pag-index.
- Tinitingnan din namin nang mabuti ang mga pagkaantala sa kolektor ng basura, dahil nagkaroon na kami ng malaking paghihirap dito sa panahon ng pag-optimize.
- Tinatanggihan sa pamamagitan ng thread upang maunawaan nang maaga kung nasaan ang bottleneck.
- Well, mga karaniwang sukatan gaya ng heap, RAM at I/O.
Kapag nagtatayo ng pagsubaybay, dapat mong isaalang-alang ang mga tampok ng Thread Pool sa Elasticsearch. naglalarawan ng mga opsyon sa pagsasaayos at mga default na halaga para sa paghahanap at pag-index, ngunit ganap na tahimik tungkol sa thread_pool.management. Pinoproseso ng mga thread na ito, lalo na, ang mga query tulad ng _cat/shards at iba pang katulad, na maginhawang gamitin kapag nagsusulat ng pagsubaybay. Kung mas malaki ang cluster, mas maraming mga kahilingan ang naisasagawa sa bawat yunit ng oras, at ang nabanggit na thread_pool.management ay hindi lamang hindi ipinakita sa opisyal na dokumentasyon, ngunit limitado rin bilang default sa 5 mga thread, na napakabilis na natapon, pagkatapos kung aling pagsubaybay ang huminto sa paggana ng tama.
Ang gusto kong sabihin sa konklusyon: ginawa namin ito! Nagawa naming bigyan ang aming mga programmer at developer ng isang tool na, sa halos anumang sitwasyon, ay mabilis at maaasahang makapagbibigay ng impormasyon tungkol sa kung ano ang nangyayari sa produksyon.
Oo, ito ay naging medyo kumplikado, ngunit, gayunpaman, nagawa naming magkasya ang aming mga kagustuhan sa mga umiiral na produkto, na hindi namin kailangang i-patch at muling isulat para sa aming sarili.
Pinagmulan: www.habr.com