Mae llawer o bobl yn wynebu Elasticsearch. Ond beth sy'n digwydd pan fyddwch chi am ei ddefnyddio i storio logiau "mewn cyfaint arbennig o fawr"? Ie, ac yn ddi-boen goroesi methiant unrhyw un o nifer o ganolfannau data? Pa fath o bensaernïaeth y dylid ei wneud, a pha beryglon y byddwch chi'n baglu arnyn nhw?
Fe benderfynon ni yn Odnoklassniki ddefnyddio elasticsearch i ddatrys y mater o reoli boncyffion, a nawr rydyn ni'n rhannu ein profiad gyda Habr: am bensaernïaeth ac am beryglon.
Pyotr Zaitsev ydw i, rwy'n gweithio fel gweinyddwr system yn Odnoklassniki. Cyn hynny, roedd hefyd yn weinyddwr, yn gweithio gyda Manticore Search, Sphinx search, Elasticsearch. Efallai os bydd ... chwiliad arall yn ymddangos, mae'n debyg y byddaf yn gweithio gydag ef hefyd. Rwyf hefyd yn cymryd rhan mewn nifer o brosiectau ffynhonnell agored yn wirfoddol.
Pan ddes i Odnoklassniki, dywedais yn ddi-hid yn y cyfweliad y gallwn weithio gydag Elasticsearch. Ar ôl i mi gael gafael arno a chwblhau rhai tasgau syml, cefais y dasg fawr o ddiwygio'r system rheoli boncyffion a oedd yn bodoli bryd hynny.
Gofynion
Lluniwyd y gofynion ar gyfer y system fel a ganlyn:
- Roedd Graylog i fod i gael ei ddefnyddio fel blaen. Oherwydd bod gan y cwmni brofiad o ddefnyddio'r cynnyrch hwn eisoes, roedd rhaglenwyr a phrofwyr yn ei wybod, roedd yn gyfarwydd ac yn gyfleus iddynt.
- Cyfaint data: ar gyfartaledd 50-80 mil o negeseuon yr eiliad, ond os bydd rhywbeth yn torri, yna nid yw'r traffig wedi'i gyfyngu gan unrhyw beth, gall fod yn 2-3 miliwn o linellau yr eiliad
- Ar ôl trafod gyda chwsmeriaid y gofynion ar gyfer cyflymder prosesu ymholiadau chwilio, sylweddolom mai patrwm nodweddiadol ar gyfer defnyddio system o'r fath yw hyn: mae pobl yn edrych am eu logiau cais am y ddau ddiwrnod diwethaf ac nid ydynt am aros mwy nag eiliad am canlyniad ar gyfer ymholiad wedi'i lunio.
- Mynnodd y gweinyddwyr y dylid graddio'r system yn hawdd os oedd angen, heb ei gwneud yn ofynnol iddynt ddeall yn ddwfn sut mae'n gweithio.
- Fel mai'r unig dasg cynnal a chadw yr oedd ei hangen ar y systemau hyn o bryd i'w gilydd oedd newid rhyw fath o galedwedd.
- Yn ogystal, mae gan Odnoklassniki draddodiad technegol gwych: rhaid i unrhyw wasanaeth rydyn ni'n ei lansio oroesi methiant canolfan ddata (yn sydyn, heb ei gynllunio ac yn hollol ar unrhyw adeg).
Rhoddwyd y gofyniad olaf yng ngweithrediad y prosiect hwn inni â’r tywallt gwaed mwyaf, y byddaf yn siarad amdano’n fanylach.
Dydd Mercher
Rydym yn gweithio ar bedair canolfan ddata, tra bod nodau data Elasticsearch ond yn gallu cael eu lleoli mewn tair (am nifer o resymau annhechnegol).
Yn y pedair canolfan ddata hyn mae tua 18 mil o wahanol ffynonellau o foncyffion - darnau o haearn, cynwysyddion, peiriannau rhithwir.
Nodwedd bwysig: mae'r clwstwr yn cael ei lansio mewn cynwysyddion nid ar beiriannau corfforol, ond ymlaen . Mae cynhwyswyr yn sicr o 2 graidd tebyg i 2.0Ghz v4 gyda'r gallu i ailgylchu gweddill y creiddiau os ydynt yn segur.
Mewn geiriau eraill:
Topoleg
Y farn gyffredinol am yr ateb a welais i ddechrau fel a ganlyn:
- Mae 3-4 VIPs y tu ôl i gofnod A parth Graylog, dyma'r cyfeiriad yr anfonir y logiau iddo.
- mae pob VIP yn gydbwysydd LVS.
- Ar ôl hynny, mae'r logiau'n mynd i'r batri Graylog, mae peth o'r data yn mynd yn y fformat GELF, rhai yn y fformat syslog.
- Yna mae hyn i gyd yn cael ei ysgrifennu mewn sypiau mawr i'r batri gan y cydlynwyr Elasticsearch.
- Ac maen nhw, yn eu tro, yn anfon ceisiadau am ysgrifennu a darllen i'r nodau data perthnasol.
Terminoleg
Efallai nad yw pawb yn deall y derminoleg yn fanwl, felly hoffwn drigo arni ychydig.
Mae sawl math o nodau yn Elasticsearch - meistr, cydlynydd, nod data. Mae dau fath arall ar gyfer gwahanol drawsnewidiadau o foncyffion a chysylltiad gwahanol glystyrau â'i gilydd, ond dim ond y rhai a restrir a ddefnyddiwyd gennym.
Meistr
Mae'n pingio'r holl nodau sy'n bresennol yn y clwstwr, yn cynnal map clwstwr cyfoes ac yn ei ddosbarthu rhwng nodau, yn prosesu rhesymeg digwyddiadau, ac yn gwneud gwahanol fathau o waith cadw tŷ ar draws y clwstwr.
Cydlynydd
Mae'n cyflawni un dasg unigol: mae'n derbyn ceisiadau gan gleientiaid am ddarllen neu ysgrifennu ac yn llwybro'r traffig hwn. Rhag ofn y bydd cais ysgrifenedig, mae'n debygol y bydd yn gofyn i'r meistr pa ddarn o'r mynegai perthnasol i'w roi ynddo, ac yn ailgyfeirio'r cais ymhellach.
nod data
Yn storio data, yn perfformio ymholiadau chwilio sy'n cyrraedd o'r tu allan ac yn perfformio gweithrediadau ar ddarnau sydd wedi'u lleoli arno.
Llwydlog
Mae'n debyg i uno Kibana â Logstash yn y pentwr ELK. Mae Graylog yn cyfuno'r UI a'r biblinell prosesu boncyffion. O dan y cwfl, mae Graylog yn rhedeg Kafka a Zookeeper, sy'n darparu cysylltedd â Graylog fel clwstwr. Gall Graylog storio logiau (Kafka) rhag ofn na fydd Elasticsearch ar gael ac ailadrodd ceisiadau darllen ac ysgrifennu aflwyddiannus, grwpio a marcio logiau yn unol â rheolau penodedig. Fel Logstash, mae gan Graylog y swyddogaeth i addasu llinynnau cyn ysgrifennu at Elasticsearch.
Yn ogystal, mae gan Graylog ddarganfyddiad gwasanaeth adeiledig sy'n caniatáu, yn seiliedig ar un nod Elasticsearch sydd ar gael, i gael y map clwstwr cyfan a'i hidlo trwy dag penodol, sy'n ei gwneud hi'n bosibl cyfeirio ceisiadau at gynwysyddion penodol.
Yn weledol mae'n edrych fel hyn:
Dyma sgrinlun o enghraifft benodol. Yma rydym yn adeiladu histogram yn seiliedig ar yr ymholiad chwilio ac yn arddangos llinellau perthnasol.
Mynegeion
Gan ddychwelyd at bensaernïaeth y system, hoffwn edrych yn fanylach ar sut y gwnaethom adeiladu'r model mynegai fel ei fod i gyd yn gweithio'n gywir.
Yn y diagram uchod, dyma'r lefel isaf: nodau data Elasticsearch.
Mae mynegai yn endid rhithwir mawr sy'n cynnwys darnau Elasticsearch. Ar ei ben ei hun, nid yw pob un o'r darnau yn ddim mwy na mynegai Lucene. Ac mae pob mynegai Lucene, yn ei dro, yn cynnwys un neu fwy o segmentau.
Wrth ddylunio, gwnaethom gyfrifo, er mwyn bodloni'r gofyniad am gyflymder darllen ar lawer iawn o ddata, bod angen i ni “lledaenu” y data hwn yn gyfartal ar draws nodau data.
Arweiniodd hyn at y ffaith y dylai nifer y darnau fesul mynegai (gyda chopïau) fod yn hollol gyfartal â nifer y nodau data. Yn gyntaf, er mwyn sicrhau ffactor atgynhyrchu o ddau (hynny yw, gallwn golli hanner y clwstwr). Ac, yn ail, er mwyn prosesu ceisiadau darllen ac ysgrifennu ar o leiaf hanner y clwstwr.
Fe wnaethom bennu'r amser storio ar y dechrau fel 30 diwrnod.
Gellir cynrychioli dosbarthiad shards yn graffigol fel a ganlyn:
Y petryal llwyd tywyll cyfan yw'r mynegai. Y sgwâr coch chwith ynddo yw'r darn cynradd, y cyntaf yn y mynegai. Ac mae'r sgwâr glas yn shard replica. Maent wedi'u lleoli mewn gwahanol ganolfannau data.
Pan fyddwn yn ychwanegu shard arall, mae'n mynd i'r drydedd ganolfan ddata. Ac, yn y diwedd, rydym yn cael strwythur o'r fath sy'n darparu'r posibilrwydd o golli DC heb golli cysondeb data:
Cylchdroi mynegai, h.y. creu mynegai newydd a dileu'r un hynaf, fe'i gwnaed yn hafal i 48 awr (yn ôl patrwm defnydd y mynegai: mae'r 48 awr olaf yn cael eu chwilio amlaf).
Mae'r cyfwng cylchdroi mynegai hwn oherwydd y rhesymau canlynol:
Pan fydd cais chwilio yn cyrraedd nod data penodol, yna, o safbwynt perfformiad, mae'n fwy proffidiol pan fydd un shard yn cael ei boli os yw ei faint yn debyg i faint clun y nod. Mae hyn yn caniatáu ichi gadw'r rhan "boeth" o'r mynegai yn y domen a'i chyrchu'n gyflym. Pan fo llawer o “rhannau poeth”, mae'r cyflymder chwilio mynegai yn diraddio.
Pan fydd nod yn dechrau gweithredu ymholiad chwilio ar un darn, mae'n dyrannu nifer o edafedd sy'n hafal i nifer creiddiau hyper-threaded y peiriant ffisegol. Os yw'r ymholiad chwilio yn effeithio ar nifer fawr o ddarnau, yna mae nifer yr edafedd yn tyfu'n gymesur. Mae hyn yn cael effaith wael ar gyflymder chwilio ac yn effeithio'n negyddol ar fynegeio data newydd.
Er mwyn darparu'r hwyrni chwilio angenrheidiol, fe wnaethom benderfynu defnyddio SSD. Er mwyn prosesu ceisiadau'n gyflym, roedd angen i'r peiriannau a oedd yn cynnal y cynwysyddion hyn gael o leiaf 56 craidd. Dewisir y rhif 56 fel gwerth amodol digonol sy'n pennu nifer yr edafedd y bydd Elasticsearch yn eu cynhyrchu yn ystod y llawdriniaeth. Yn Elasitcsearch, mae llawer o baramedrau pwll edau yn dibynnu'n uniongyrchol ar nifer y creiddiau sydd ar gael, sydd yn ei dro yn effeithio'n uniongyrchol ar y nifer gofynnol o nodau yn y clwstwr yn ôl yr egwyddor "llai o greiddiau - mwy o nodau".
O ganlyniad, canfuom fod darn ar gyfartaledd yn pwyso tua 20 gigabeit, ac mae yna 1 shards fesul mynegai. Yn unol â hynny, os ydym yn eu cylchdroi unwaith bob 360 awr, yna mae gennym 48 ohonynt. Mae pob mynegai yn cynnwys data am 15 ddiwrnod.
Cynlluniau ar gyfer ysgrifennu a darllen data
Gadewch i ni weld sut mae data yn cael ei gofnodi yn y system hon.
Gadewch i ni ddweud bod rhywfaint o gais yn cyrraedd o Graylog i'r cydlynydd. Er enghraifft, rydym am fynegai 2-3 rhesi.
Mae’r cydlynydd, ar ôl derbyn cais gan Graylog, yn gofyn i’r meistr: “Yn y cais am fynegeio, fe wnaethom nodi’r mynegai yn benodol, ond ni nodwyd ym mha ddarn y dylid ysgrifennu hwn.”
Mae'r meistr yn ateb: "Ysgrifennwch y wybodaeth hon i rif shard 71", ac ar ôl hynny fe'i hanfonir yn uniongyrchol i'r nod data perthnasol, lle mae prif-shard rhif 71 wedi'i leoli.
Ar ôl hynny mae'r log trafodion yn cael ei ailadrodd i replica-shad, sydd wedi'i leoli mewn canolfan ddata arall.
Mae cais am chwiliad yn cyrraedd o Graylog i'r cydlynydd. Mae'r cydlynydd yn ei ailgyfeirio yn ôl mynegai, tra bod Elasticsearch yn dosbarthu ceisiadau rhwng cynradd-shard a replica-shard yn unol â'r egwyddor rownd-robin.
Mae nodau yn y swm o 180 yn ymateb yn anwastad, ac wrth ymateb, mae'r cydlynydd yn cronni gwybodaeth bod nodau data cyflymach eisoes wedi "poeri allan" iddo. Ar ôl hynny, pan fydd naill ai'r holl wybodaeth wedi cyrraedd, neu pan fydd terfyn amser wedi'i gyrraedd ar y cais, mae'n rhoi popeth yn uniongyrchol i'r cleient.
Mae'r system gyfan hon, ar gyfartaledd, yn cyflawni ceisiadau chwilio am y 48 awr olaf mewn 300-400ms, heb gynnwys y ceisiadau hynny sydd â'r cerdyn chwilio mwyaf blaenllaw.
Blodau gydag Elasticsearch: setup Java
Er mwyn gwneud i'r cyfan weithio fel yr oedden ni ei eisiau yn wreiddiol, fe wnaethon ni dreulio amser hir iawn yn dadfygio amrywiaeth eang o bethau yn y clwstwr.
Roedd rhan gyntaf y problemau a ddarganfuwyd yn gysylltiedig â sut mae Java wedi'i ffurfweddu ymlaen llaw yn Elasticsearch yn ddiofyn.
Problem un
Rydym wedi gweld nifer fawr iawn o adroddiadau sydd gennym ar lefel Lucene, pan fydd swyddi cefndir yn rhedeg, mae uno segment Lucene yn methu. Ar yr un pryd, roedd yn amlwg yn y logiau mai gwall OutOfMemoryError oedd hwn. O delemetreg, gwelsom fod y glun yn rhydd, ac nid oedd yn glir pam roedd y llawdriniaeth hon yn gostwng.
Mae'n troi allan bod cyfuniadau mynegai Lucene yn digwydd y tu allan i'r glun. Ac mae cynwysyddion yn gyfyngedig iawn o ran adnoddau a ddefnyddir. Dim ond y domen oedd yn ffitio i'r adnoddau hyn (roedd gwerth heap.size fwy neu lai'n hafal i RAM), a gostyngodd rhai gweithrediadau oddi ar y domen gyda gwall dyrannu cof os nad oeddent am ryw reswm yn ffitio i'r ~ 500MB hynny a oedd ar ôl cyn y terfyn .
Roedd yr atgyweiriad yn eithaf dibwys: cynyddwyd faint o RAM oedd ar gael ar gyfer y cynhwysydd, ac ar ôl hynny fe wnaethant anghofio ein bod wedi cael problemau o'r fath o gwbl.
Problem dau
4-5 diwrnod ar ôl lansio'r clwstwr, gwnaethom sylwi bod y nodau data yn dechrau cwympo allan o'r clwstwr o bryd i'w gilydd a'i nodi ar ôl 10-20 eiliad.
Wrth ddringo i'w ddarganfod, daeth yn amlwg nad yw'r atgof hynod ddi-ben-draw hwn yn Elasticsearch bron yn cael ei reoli mewn unrhyw ffordd. Pan wnaethom roi mwy o gof i'r cynhwysydd, cawsom gyfle i lenwi pyllau clustogi uniongyrchol gyda gwybodaeth amrywiol, a dim ond ar ôl lansio'r GC penodol gan Elasticsearch y cafodd ei glirio.
Mewn rhai achosion, cymerodd y llawdriniaeth hon amser eithaf hir, ac yn ystod yr amser hwn llwyddodd y clwstwr i nodi'r nod hwn fel y'i rhyddhawyd eisoes. Disgrifir y mater hwn yn dda. .
Yr ateb oedd fel a ganlyn: cyfyngwyd ar allu Java i ddefnyddio'r rhan fwyaf o'r cof y tu allan i'r domen ar gyfer y gweithrediadau hyn. Fe wnaethom ei gyfyngu i 16 gigabeit (-XX:MaxDirectMemorySize=16g), gan sicrhau bod GC penodol yn cael ei alw'n llawer amlach, a'i weithio allan yn llawer cyflymach, gan roi'r gorau i ansefydlogi'r clwstwr.
Problem tri
Os ydych chi’n meddwl bod y problemau gyda “nodau’n gadael y clwstwr ar yr eiliad fwyaf annisgwyl” ar ben, rydych chi’n camgymryd.
Pan wnaethom ffurfweddu'r gwaith gyda mynegeion, fe wnaethom ddewis mmapfs er mwyn gwneud hynny ar ddarnau ffres gyda segmentiad uchel. Roedd hwn yn gamgymeriad eithaf dybryd, oherwydd wrth ddefnyddio mmapfs, mae'r ffeil yn cael ei mapio i mewn i RAM, ac yna rydym yn gweithio gyda'r ffeil wedi'i fapio. Oherwydd hyn, mae'n ymddangos, pan fydd y GC yn ceisio atal yr edafedd yn y cais, rydym yn mynd i safepoint am amser hir iawn, ac ar y ffordd iddo, mae'r cais yn stopio ymateb i geisiadau'r dewin ynghylch a yw'n fyw. . Yn unol â hynny, mae meistr yn credu nad yw'r nod bellach yn bresennol yn ein clwstwr. Ar ôl hynny, ar ôl 5-10 eiliad, mae'r casglwr sbwriel yn gweithio allan, mae'r nod yn dod yn fyw, yn mynd i mewn i'r clwstwr eto ac yn dechrau cychwyn y darnau. Roedd hyn oll yn ymdebygu’n gryf i “y cynhyrchiad yr oeddem yn ei haeddu” ac nid oedd yn addas ar gyfer unrhyw beth difrifol.
I gael gwared ar yr ymddygiad hwn, fe wnaethom newid yn gyntaf i'r niofs safonol, ac yna, pan wnaethom fudo o'r pumed fersiwn o Elastig i'r chweched rhai, fe wnaethom roi cynnig ar hybridfs, lle na chafodd y broblem hon ei hatgynhyrchu. Gallwch ddarllen mwy am fathau o storfa .
Problem pedwar
Yna roedd problem ddifyr iawn arall y gwnaethom ei thrin am amser hir erioed. Fe wnaethon ni ei dal am 2-3 mis, oherwydd roedd ei phatrwm yn gwbl annealladwy.
Weithiau byddai ein cydlynwyr yn mynd i GC Llawn, fel arfer rhywle yn y prynhawn, a byth yn dychwelyd oddi yno. Ar yr un pryd, wrth logio'r oedi GC, roedd yn edrych fel hyn: mae popeth yn mynd yn dda i ni, yn dda, yn dda, ac yna unwaith - ac mae popeth yn ddrwg iawn.
Ar y dechrau, roeddem yn meddwl bod gennym ddefnyddiwr drwg sy'n lansio rhyw fath o gais sy'n curo'r cydlynydd allan o'r modd gwaith. Fe wnaethom gofnodi ceisiadau am amser hir iawn, gan geisio darganfod beth oedd yn digwydd.
O ganlyniad, ar hyn o bryd pan fydd defnyddiwr yn lansio cais enfawr, ac yn cyrraedd cydlynydd Elasticsearch penodol, mae rhai nodau'n ymateb yn hirach nag eraill.
Ac er bod y cydlynydd yn aros am ymateb yr holl nodau, mae'n cronni ynddo'i hun y canlyniadau a anfonwyd o'r nodau sydd eisoes wedi ymateb. Ar gyfer y GC, mae hyn yn golygu bod ein patrwm defnydd clun yn newid yn gyflym iawn. Ac ni allai'r GC a ddefnyddiwyd gennym ymdopi â'r dasg hon.
Yr unig ateb a welsom i newid ymddygiad y clwstwr yn y sefyllfa hon yw mudo i JDK13 a defnyddio casglwr sbwriel Shenandoah. Roedd hyn yn datrys y broblem, rhoddodd ein cydlynwyr y gorau i ddisgyn.
Dyma lle daeth y problemau gyda Java i ben a dechreuodd y problemau gyda lled band.
"Aeron" gydag Elasticsearch: trwybwn
Mae problemau trwybwn yn golygu bod ein clwstwr yn sefydlog, ond ar anterth nifer y dogfennau wedi'u mynegeio ac ar adeg symudiadau, mae'r perfformiad yn annigonol.
Y symptom cyntaf y deuthum ar ei draws: yn ystod rhyw fath o “ffrwydrad” wrth gynhyrchu, pan fydd nifer fawr iawn o foncyffion yn cael eu cynhyrchu'n sydyn, mae gwall mynegeio es_rejected_execution yn aml yn fflachio yn Graylog.
Roedd hyn oherwydd y ffaith bod y thread_pool.write.queue ar un nod data nes bod Elasticsearch yn gallu prosesu'r cais mynegai a thaflu'r wybodaeth i'r darn ar ddisg, yn ddiofyn dim ond 200 o geisiadau y gall eu cuddio. Ac yn ychydig iawn a ddywedir am y paramedr hwn. Dim ond nifer terfyn yr edafedd a'r maint rhagosodedig a nodir.
Wrth gwrs, fe aethon ni i droelli'r gwerth hwn a darganfod y canlynol: yn benodol yn ein gosodiad, mae hyd at 300 o geisiadau wedi'u storio'n eithaf da, ac mae gwerth mwy yn llawn y ffaith ein bod ni eto'n hedfan i ffwrdd i Full GC.
Yn ogystal, gan fod y rhain yn sypiau o negeseuon sy'n cyrraedd o fewn un cais, roedd hefyd angen tweak Graylog fel ei fod yn ysgrifennu nid yn aml ac mewn sypiau bach, ond mewn sypiau enfawr neu bob 3 eiliad os nad yw'r swp yn llawn o hyd. Yn yr achos hwn, mae'n ymddangos bod y wybodaeth rydyn ni'n ei hysgrifennu yn Elasticsearch ar gael nid ar ôl dwy eiliad, ond ar ôl pump (sy'n addas i ni yn eithaf da), ond mae nifer yr ôl-olion y mae'n rhaid eu gwneud i wthio bwndel mawr o wybodaeth. yn lleihau.
Mae hyn yn arbennig o bwysig ar yr eiliadau hynny pan fydd rhywbeth wedi damwain yn rhywle ac yn adrodd yn ffyrnig amdano, er mwyn peidio â chael ei sbamio'n Elastig yn llwyr, ac ar ôl peth amser - nodau Graylog sy'n anweithredol oherwydd byfferau rhwystredig.
Yn ogystal, pan gawsom y ffrwydradau iawn hyn wrth gynhyrchu, cawsom gwynion gan raglenwyr a phrofwyr: ar hyn o bryd pan fydd gwir angen y logiau hyn arnynt, maent yn cael eu rhoi iddynt yn araf iawn.
Dechreuon nhw ei chyfrifo. Ar y naill law, roedd yn amlwg bod ymholiadau chwilio ac ymholiadau mynegeio yn cael eu prosesu, mewn gwirionedd, ar yr un peiriannau ffisegol, ac un ffordd neu'r llall, bydd rhai anfanteision.
Ond gellid osgoi hyn yn rhannol oherwydd bod algorithm wedi ymddangos yn y chweched fersiwn o Elasticsearch sy'n eich galluogi i ddosbarthu ceisiadau rhwng nodau data perthnasol nid yn unol â'r egwyddor rownd-robin ar hap (y cynhwysydd sy'n mynegeio ac yn dal y prif-shard). Gall fod yn brysur iawn, ni fydd unrhyw ffordd i ymateb yn gyflym), ond i gyfeirio'r cais hwn i gynhwysydd llai llwythog gyda replica-shard, a fydd yn ymateb yn sylweddol gyflymach. Mewn geiriau eraill, daeth use_adaptive_replica_selection: true.
Mae'r llun darllen yn dechrau edrych fel hyn:
Roedd y newid i'r algorithm hwn yn ein galluogi i wella'r amser ymholi yn sylweddol yn yr eiliadau hynny pan oedd gennym lif mawr o logiau ar gyfer ysgrifennu.
Yn olaf, y brif broblem oedd cael gwared ar y ganolfan ddata yn ddi-boen.
Yr hyn yr oeddem ei eisiau gan y clwstwr yn syth ar ôl colli cyfathrebu ag un DC:
- Os oes gennym y meistr presennol yn y ganolfan ddata syrthiedig, yna bydd yn cael ei ail-ethol a'i symud fel rôl i nod arall mewn DC arall.
- Bydd y meistr yn cicio pob nod anhygyrch o'r clwstwr yn gyflym.
- Yn seiliedig ar y gweddill, bydd yn deall: yn y ganolfan ddata a gollwyd cawsom ddarnau cynradd o'r fath ac o'r fath, bydd yn hyrwyddo shards replica cyflenwol yn gyflym yn y canolfannau data sy'n weddill, a byddwn yn parhau i fynegeio data.
- O ganlyniad i hyn, bydd lled band y clwstwr ar gyfer ysgrifennu a darllen yn diraddio'n esmwyth, ond yn gyffredinol, bydd popeth yn gweithio, er yn araf, ond yn gyson.
Fel mae'n digwydd, roedden ni eisiau rhywbeth fel hyn:
A chawsom y canlynol:
Sut ddigwyddodd?
Pan syrthiodd y ganolfan ddata, daeth ein meistr yn dagfa.
Pam?
Y ffaith yw bod gan y meistr TaskBatcher sy'n gyfrifol am ddosbarthu rhai tasgau a digwyddiadau yn y clwstwr. Unrhyw allbwn nod, unrhyw hyrwyddo shard o replica i gynradd, unrhyw dasg i greu rhyw fath o shard yn rhywle - mae hyn i gyd yn gyntaf yn mynd i mewn i'r TaskBatcher, lle mae'n cael ei brosesu yn olynol ac mewn un edefyn.
Ar adeg tynnu un ganolfan ddata yn ôl, daeth i'r amlwg bod yr holl nodau data yn y canolfannau data sydd wedi goroesi yn ystyried ei bod yn ddyletswydd arnynt hysbysu'r meistr “rydym wedi colli darnau o'r fath ac o'r fath a nodau data o'r fath ac o'r fath.”
Ar yr un pryd, anfonodd y nodau data sydd wedi goroesi yr holl wybodaeth hon at y meistr presennol a cheisio aros am gadarnhad ei fod wedi ei dderbyn. Nid oeddent yn disgwyl hyn, gan fod y meistr yn derbyn tasgau yn gyflymach nag yr oedd ganddo amser i'w hateb. Roedd y nodau'n ailadrodd ceisiadau erbyn terfyn amser, ac nid oedd y meistr bryd hynny hyd yn oed yn ceisio eu hateb, ond roedd wedi'i amsugno'n llwyr yn y dasg o ddidoli ceisiadau yn ôl blaenoriaeth.
Yn y ffurf derfynell, daeth i'r amlwg bod y nodau data wedi sbamio'r meistr i'r pwynt ei fod wedi mynd i mewn i GC llawn. Wedi hynny, symudodd rôl y meistr i ryw nod nesaf, yn hollol yr un peth a ddigwyddodd iddo, ac o ganlyniad, syrthiodd y clwstwr yn gyfan gwbl.
Fe wnaethom fesuriadau, a chyn fersiwn 6.4.0, lle'r oedd yn sefydlog, roedd yn ddigon i ni dynnu'n ôl ar yr un pryd dim ond 10 allan o 360 o nodau data er mwyn rhoi'r clwstwr yn llwyr.
Roedd yn edrych rhywbeth fel hyn:
Ar ôl fersiwn 6.4.0, lle gosodwyd y byg rhyfedd hwn, rhoddodd y nodau data y gorau i ladd y meistr. Ond nid oedd yn ei wneud yn gallach. Sef: pan fyddwn yn allbwn nodau data 2, 3 neu 10 (unrhyw rif heblaw un), mae'r meistr yn derbyn neges gyntaf sy'n dweud bod nod A wedi gadael, ac yn ceisio dweud wrth nod B, nod C, nod D.
Ac ar hyn o bryd, dim ond trwy osod terfyn amser ar gyfer ymdrechion i ddweud wrth rywun am rywbeth, sy'n hafal i rywle o gwmpas 20-30 eiliad, y gellir delio â hyn, a thrwy hynny reoli cyflymder tynnu'r ganolfan ddata o'r clwstwr.
Mewn egwyddor, mae hyn yn cyd-fynd â'r gofynion a osodwyd yn wreiddiol ar gyfer y cynnyrch terfynol o fewn fframwaith y prosiect, ond o safbwynt "gwyddoniaeth pur" mae hwn yn fyg. Sydd, gyda llaw, wedi'i osod yn llwyddiannus gan y datblygwyr yn fersiwn 7.2.
Ar ben hynny, pan aeth nod data penodol allan, daeth i'r amlwg bod lledaenu gwybodaeth am ei ymadawiad yn bwysicach na dweud wrth y clwstwr cyfan bod cymaint ac o'r fath yn cynnwys darnau cynradd arno (er mwyn hyrwyddo atgynhyrchiad mewn data arall ganolfan yn y cynradd, ac mewn gwybodaeth gellid ei ysgrifennu arnynt).
Felly, pan fydd popeth eisoes wedi marw, nid yw'r nodau data a ryddhawyd wedi'u nodi ar unwaith fel rhai hen. Yn unol â hynny, rydym yn cael ein gorfodi i aros nes bod yr holl pings wedi'u hamseru cyn i'r nodau data gael eu rhyddhau, a dim ond ar ôl hynny mae ein clwstwr yn dechrau siarad am y ffaith bod yno, ac yno, mae angen parhau i gofnodi gwybodaeth. Gallwch ddarllen mwy am hyn .
O ganlyniad, mae gweithrediad tynnu'r ganolfan ddata heddiw yn cymryd tua 5 munud ar yr awr frys. Ar gyfer colossus mor fawr a thrwsgl, mae hwn yn ganlyniad eithaf da.
O ganlyniad, daethom at yr ateb canlynol:
- Mae gennym 360 nodau data gyda 700 o ddisgiau gigabyte.
- 60 o gydlynwyr ar gyfer llwybro traffig drwy'r un nodau data hyn.
- Meistri 40 yr ydym wedi'u gadael fel rhyw fath o etifeddiaeth o amser fersiynau cyn 6.4.0 - er mwyn goroesi tynnu'r ganolfan ddata yn ôl, roeddem yn barod yn feddyliol i golli sawl peiriant er mwyn gwarantu cworwm o feistri hyd yn oed yn y senario gwaethaf
- Roedd unrhyw ymdrechion i gyfuno rolau ar un cynhwysydd gyda ni yn dibynnu ar y ffaith bod y nod wedi torri dan lwyth yn hwyr neu'n hwyrach.
- Mae'r clwstwr cyfan yn defnyddio heap.size o 31 gigabeit: arweiniodd pob ymgais i leihau'r maint at naill ai ladd rhai nodau ar ymholiadau chwilio trwm gyda'r cerdyn gwyllt blaenllaw neu gael y torrwr cylched yn Elasticsearch ei hun.
- Yn ogystal, er mwyn sicrhau perfformiad chwilio, ceisiwyd cadw nifer y gwrthrychau yn y clwstwr mor fach â phosibl er mwyn prosesu cyn lleied o ddigwyddiadau â phosibl ar y dagfa a gawsom yn y dewin.
Yn olaf am fonitro
Er mwyn sicrhau bod hyn i gyd yn gweithio yn ôl y bwriad, rydym yn monitro’r canlynol:
- Mae pob nod data yn adrodd i'n cwmwl ei fod yn bodoli, ac mae darnau o'r fath ac o'r fath arno. Pan fyddwn yn diffodd rhywbeth yn rhywle, mae'r clwstwr yn adrodd ar ôl 2-3 eiliad ein bod wedi diffodd nodau 2, 3, a 4 yng nghanol A - mae hyn yn golygu na allwn ddiffodd y nodau hynny mewn canolfannau data eraill gyda dim ond un darn ar ôl.
- Gan wybod ymddygiad y meistr, edrychwn yn ofalus iawn ar nifer y tasgau sydd ar y gweill. Oherwydd gall hyd yn oed un dasg grog, os nad yw'n amser i ffwrdd, yn ddamcaniaethol, mewn rhai sefyllfaoedd brys, ddod yn rheswm pam, er enghraifft, nid yw hyrwyddo shard replica yn y cynradd yn gweithio i ni, a fydd yn dod i ben. mynegeio.
- Rydym hefyd yn edrych yn agos iawn ar oedi gyda chasglu sbwriel, oherwydd rydym eisoes wedi cael anawsterau mawr gyda hyn yn ystod optimeiddio.
- Gwrthod edafedd i ddeall ymlaen llaw ble mae'r “dagfa”.
- Wel, metrigau safonol fel pentwr, RAM ac I/O.
Wrth adeiladu monitro, gofalwch eich bod yn cymryd i ystyriaeth nodweddion y Pwll Thread yn Elasticsearch. yn disgrifio opsiynau cyfluniad a gwerthoedd rhagosodedig ar gyfer chwilio a mynegeio, ond yn gwbl dawel am thread_pool.management Mae'r edafedd hyn yn prosesu, yn arbennig, ymholiadau fel _cat/shards a rhai tebyg eraill, sy'n gyfleus i'w defnyddio wrth ysgrifennu monitro. Po fwyaf yw'r clwstwr, y mwyaf o geisiadau o'r fath sy'n cael eu gweithredu fesul uned o amser, ac nid yn unig y cyflwynir yr thread_pool.management uchod yn y ddogfennaeth swyddogol, ond mae hefyd yn gyfyngedig yn ddiofyn i 5 edafedd, sy'n cael ei waredu'n gyflym iawn, ar ôl pa fonitro sy'n stopio gweithio'n gywir.
Yr hyn yr wyf am ei ddweud i gloi: fe wnaethom ni! Llwyddom i roi offeryn i'n rhaglenwyr a'n datblygwyr sy'n gallu darparu gwybodaeth yn gyflym ac yn ddibynadwy am yr hyn sy'n digwydd ym maes cynhyrchu mewn unrhyw sefyllfa bron.
Do, daeth yn eithaf anodd, ond, serch hynny, fe wnaethom lwyddo i ffitio ein Rhestr Ddymuniadau i mewn i gynhyrchion presennol, nad oedd, ar yr un pryd, yn gorfod cael eu clytio a'u hailysgrifennu i ni ein hunain.
Ffynhonnell: hab.com