Þetta er framhald af langri sögu um þyrniruga leið okkar að því að búa til öflugt og mikið álagskerfi sem tryggir rekstur Kauphallarinnar. Fyrsti hlutinn er hér:
Dularfull villa
Eftir fjölmargar prófanir var uppfært viðskipta- og hreinsunarkerfi tekið í notkun og við lentum í villu sem við gátum skrifað spæjara-dulræna sögu um.
Stuttu eftir ræsingu á aðalþjóninum var ein af færslunum unnin með villu. Hins vegar var allt í lagi á afritunarþjóninum. Það kom í ljós að einföld stærðfræðileg aðgerð við að reikna veldisvísis á aðalþjóninum gaf neikvæða niðurstöðu úr raunverulegum rökum! Við héldum áfram rannsóknum okkar og í SSE2 skránni fundum við mun á einum bita sem er ábyrgur fyrir námundun þegar unnið er með flottölur.
Við skrifuðum einfalt prófunartól til að reikna út veldisvísi með námundunarbitasettinu. Það kom í ljós að í útgáfunni af RedHat Linux sem við notuðum var galli við að vinna með stærðfræðiaðgerðina þegar illa meinti bitinn var settur inn. Við tilkynntum þetta til RedHat, eftir smá stund fengum við plástur frá þeim og rúlluðum honum út. Villan kom ekki lengur upp, en það var óljóst hvaðan þessi biti kom? Aðgerðin bar ábyrgð á því fesetround frá tungumálinu C. Við greindum kóðann okkar vandlega í leit að meintri villu: við athuguðum allar mögulegar aðstæður; skoðaði allar aðgerðir sem notuðu námundun; reyndi að endurskapa misheppnaða lotu; notaði mismunandi þýðendur með mismunandi valkostum; Notuð var statísk og kraftmikil greining.
Orsök villunnar fannst ekki.
Síðan fóru þeir að athuga vélbúnaðinn: þeir framkvæmdu álagsprófun á örgjörvunum; athugaði vinnsluminni; Við keyrðum meira að segja próf fyrir mjög ólíklega atburðarás um margra bita villu í einum reit. Án árangurs.
Á endanum komumst við að kenningu úr heimi háorkueðlisfræðinnar: Einhver háorkuögn flaug inn í gagnaverið okkar, skarst í vegginn, rakst á örgjörvann og varð til þess að kveikjulásinn festist einmitt í því. Þessi fáránlega kenning var kölluð „neutrínó“. Ef þú ert langt frá eðlisfræði agna: neutrinos hafa nánast ekki samskipti við umheiminn og geta vissulega ekki haft áhrif á virkni örgjörvans.
Þar sem ekki var hægt að finna orsök bilunarinnar var „móðgandi“ netþjónninn tekinn úr rekstri til öryggis.
Eftir nokkurn tíma fórum við að bæta heita öryggisafritunarkerfið: við kynntum svokallaða „hlýja forða“ (hlýtt) - ósamstilltar eftirmyndir. Þeir fengu straum af færslum sem gætu verið staðsettir í mismunandi gagnaverum, en warms höfðu ekki virkan samskipti við aðra netþjóna.
Hvers vegna var þetta gert? Ef afritunarþjónninn bilar, þá verður heitt bundið við aðalþjóninn nýja öryggisafritið. Það er að segja að eftir bilun er kerfið ekki áfram með einum aðalþjóni fyrr en í lok viðskiptalotunnar.
Og þegar nýja útgáfan af kerfinu var prófuð og tekin í notkun kom námundunarbitavillan aftur upp. Þar að auki, með auknum fjölda heitra netþjóna, byrjaði villan að birtast oftar. Á sama tíma hafði seljandinn ekkert að sýna, þar sem engar áþreifanlegar sannanir voru fyrir hendi.
Við næstu greiningu á ástandinu kom upp kenning um að vandamálið gæti tengst stýrikerfinu. Við skrifuðum einfalt forrit sem kallar á fall í endalausri lykkju fesetround, man núverandi ástand og athugar það í gegnum svefn, og þetta er gert í mörgum samkeppnisþráðum. Eftir að hafa valið færibreytur fyrir svefn og fjölda þráða, fórum við að endurskapa bitabilunina stöðugt eftir um það bil 5 mínútur að keyra tólið. Hins vegar gat Red Hat stuðningur ekki endurskapað það. Prófanir á öðrum netþjónum okkar hafa sýnt að aðeins þeir sem eru með ákveðna örgjörva eru viðkvæmir fyrir villunni. Á sama tíma leysti það vandamálið að skipta yfir í nýjan kjarna. Að lokum skiptum við einfaldlega út stýrikerfinu og hin raunverulega orsök villunnar var enn óljós.
Og skyndilega í fyrra birtist grein á Habré “" Aðstæður sem lýst er í henni voru mjög svipaðar okkar, en höfundur tók rannsóknina lengra og setti fram kenningu um að villan væri í örkóðanum. Og þegar Linux kjarna eru uppfærðir, uppfæra framleiðendur líka örkóðann.
Frekari þróun kerfisins
Þrátt fyrir að við höfum losnað við villuna neyddi þessi saga okkur til að endurskoða kerfisarkitektúrinn. Þegar öllu er á botninn hvolft vorum við ekki varin fyrir endurtekningu slíkra galla.
Eftirfarandi meginreglur lágu til grundvallar næstu endurbótum á bókunarkerfinu:
- Þú getur ekki treyst neinum. Netþjónar virka kannski ekki rétt.
- Meirihlutafyrirvari.
- Að tryggja samstöðu. Sem rökrétt viðbót við meirihlutafyrirvara.
- Tvöfaldar bilanir eru mögulegar.
- Lífskraftur. Nýja heita biðkerfið ætti ekki að vera verra en það fyrra. Viðskipti ættu að halda áfram án truflana þar til síðasta netþjónninn er.
- Lítilsháttar aukning á leynd. Sérhver niður í miðbæ hefur í för með sér mikið fjárhagslegt tjón.
- Lágmarks netsamskipti til að halda leynd eins lágri og mögulegt er.
- Að velja nýjan aðalþjón á nokkrum sekúndum.
Engin af þeim lausnum sem til voru á markaðnum hentaði okkur og Raft siðareglurnar voru enn á byrjunarstigi, þannig að við bjuggum til okkar eigin lausn.
Netkerfi
Auk bókunarkerfisins byrjuðum við að nútímavæða netsamskipti. I/O undirkerfið samanstóð af mörgum ferlum, sem höfðu verst áhrif á jitter og leynd. Með hundruð ferla sem annast TCP-tengingar neyddumst við til að skipta stöðugt á milli þeirra og á míkrósekúndna mælikvarða er þetta frekar tímafrekt aðgerð. En það versta er að þegar ferli fékk pakka til vinnslu sendi það hann í eina SystemV biðröð og beið svo eftir atburði úr annarri SystemV biðröð. Hins vegar, þegar það er mikill fjöldi hnúta, táknar komu nýs TCP pakka í einu ferli og móttaka gagna í biðröðinni í öðru tvo samkeppnisviðburði fyrir stýrikerfið. Í þessu tilviki, ef engir líkamlegir örgjörvar eru tiltækir fyrir bæði verkefnin, verður annar afgreiddur og sá síðari settur í biðröð. Það er ómögulegt að spá fyrir um afleiðingarnar.
Í slíkum aðstæðum er hægt að nota kraftmikla forgangsstýringu ferlis, en það mun krefjast notkunar á auðlindafrekum kerfiskallum. Fyrir vikið fórum við yfir í einn þráð með því að nota klassíska epoll, þetta jók hraðann til muna og minnkaði vinnslutíma viðskiptanna. Við losuðum líka við aðskilda netsamskiptaferla og samskipti í gegnum SystemV, fækkuðum verulega kerfissímtölum og fórum að stjórna forgangsröðun starfseminnar. Á I/O undirkerfinu einu var hægt að spara um 8-17 míkrósekúndur, allt eftir atburðarás. Þetta einþráða kerfi hefur verið notað óbreytt síðan þá; einn epoll þráður með spássíu nægir til að þjóna öllum tengingum.
Færsluvinnsla
Vaxandi álag á kerfið okkar krafðist uppfærslu á næstum öllum íhlutum þess. En því miður hefur stöðnun í vexti klukkuhraða örgjörva á undanförnum árum ekki lengur gert það mögulegt að skala ferla beint. Þess vegna ákváðum við að skipta vélarferlinu í þrjú stig, þar sem annasamast er áhættueftirlitskerfið, sem metur framboð á fjármunum á reikningum og býr til viðskiptin sjálf. En peningar geta verið í mismunandi gjaldmiðlum og það þurfti að reikna út á hvaða grundvelli ætti að skipta afgreiðslu beiðna.
Rökrétta lausnin er að skipta því eftir gjaldmiðli: einn netþjónn verslar í dollurum, annar í pundum og þriðji í evrum. En ef, með slíku kerfi, eru sendar tvær færslur til að kaupa mismunandi gjaldmiðla, þá mun vandamálið við afsamstillingu veskis koma upp. En samstilling er erfið og dýr. Því væri rétt að skera sérstaklega með veski og sérstaklega með tækjum. Við the vegur, flest vestræn kauphallir hafa ekki það verkefni að athuga áhættu eins nákvæmlega og við, svo oftast er þetta gert án nettengingar. Við þurftum að innleiða sannprófun á netinu.
Við skulum útskýra með dæmi. Kaupmaður vill kaupa $30 og beiðnin fer í staðfestingu viðskipta: við athugum hvort þessi kaupmaður hafi leyfi til að nota þennan viðskiptaham og hvort hann hafi nauðsynleg réttindi. Ef allt er í lagi fer beiðnin í áhættusannprófunarkerfið, þ.e. til að kanna hvort fjármunir séu nægir til að ljúka viðskiptum. Það er aths. að nauðsynleg upphæð sé læst. Beiðnin er síðan send til viðskiptakerfisins sem samþykkir eða hafnar viðskiptunum. Segjum að viðskiptin séu samþykkt - þá merkir áhættusannprófunarkerfið að peningarnir séu opnaðir og rúblurnar breytast í dollur.
Almennt séð inniheldur áhættueftirlitskerfið flókið reiknirit og framkvæmir mikið magn af mjög auðlindafrekum útreikningum og athugar ekki einfaldlega „reikningsjöfnuð“ eins og það kann að virðast við fyrstu sýn.
Þegar við byrjuðum að skipta vélarferlinu í stig, lentum við í vandræðum: kóðinn sem var tiltækur á þeim tíma notaði virkan sama gagnamagn á staðfestingar- og sannprófunarstigum, sem krafðist þess að endurskrifa allan kóðagrunninn. Fyrir vikið fengum við lánaða tækni til að vinna úr leiðbeiningum frá nútíma örgjörvum: hverju þeirra er skipt í lítil þrep og nokkrar aðgerðir eru gerðar samhliða í einni lotu.
Eftir smá aðlögun á kóðanum bjuggum við til leiðslu fyrir samhliða færsluvinnslu, þar sem viðskiptunum var skipt í 4 stig leiðslunnar: netsamskipti, löggilding, framkvæmd og birting niðurstöðunnar
Við skulum skoða dæmi. Við erum með tvö vinnslukerfi, rað- og samhliða. Fyrsta færslan kemur og er send til staðfestingar í báðum kerfum. Önnur færslan kemur strax: í samhliða kerfi er það strax tekið til starfa og í raðkerfi er það sett í biðröð sem bíður eftir að fyrsta færslan fari í gegnum núverandi vinnslustig. Það er að segja, helsti kosturinn við leiðsluvinnslu er að við vinnum færsluröðina hraðar.
Svona komum við með ASTS+ kerfið.
Að vísu er ekki allt svo slétt með færiböndum heldur. Segjum að við séum með viðskipti sem hafa áhrif á gagnafylki í nálægum viðskiptum; þetta er dæmigert ástand fyrir skipti. Ekki er hægt að framkvæma slík viðskipti í leiðslu vegna þess að þau geta haft áhrif á aðra. Þetta ástand er kallað gagnahætta og slík viðskipti eru einfaldlega unnin sérstaklega: þegar „hröðu“ færslurnar í biðröðinni klárast stoppar leiðslan, kerfið vinnur úr „hægu“ færslunni og byrjar síðan leiðsluna aftur. Sem betur fer er hlutfall slíkra viðskipta í heildarflæðinu mjög lítið, þannig að leiðslan stöðvast svo sjaldan að hún hefur ekki áhrif á heildarafköst.
Síðan fórum við að leysa vandamálið við að samstilla þrjá framkvæmdaþræði. Niðurstaðan var kerfi byggt á hringjapúða með fastri stærð frumum. Í þessu kerfi er allt háð vinnsluhraða, gögn eru ekki afrituð.
- Allir komandi netpakkar fara í úthlutunarstigið.
- Við setjum þau í fylki og merkjum þau sem tiltæk fyrir stig #1.
- Önnur viðskiptin eru komin, hún er aftur í boði fyrir stig nr.
- Fyrsti vinnsluþráðurinn sér tiltækar færslur, vinnur úr þeim og færir þær á næsta stig seinni vinnsluþráðarins.
- Það vinnur síðan úr fyrstu færslunni og merkir samsvarandi reit
deleted— það er nú fáanlegt til nýrrar notkunar.
Öll röðin er unnin á þennan hátt.
Vinnsla á hverju stigi tekur einingar eða tugi míkrósekúndna. Og ef við notum staðlað OS samstillingarkerfi, þá munum við tapa meiri tíma á samstillingunni sjálfri. Þess vegna byrjuðum við að nota spinlock. Hins vegar er þetta mjög slæmt form í rauntímakerfi og RedHat mælir stranglega ekki með því að gera þetta, þannig að við notum snúningslás í 100 ms og skiptum svo yfir í semafórham til að útiloka möguleikann á stoppi.
Fyrir vikið náðum við frammistöðu upp á um 8 milljónir viðskipta á sekúndu. Og bókstaflega tveimur mánuðum síðar um LMAX Disruptor sáum við lýsingu á hringrás með sömu virkni.
Nú gætu verið nokkrir aftökuþræðir á einu stigi. Öll viðskipti voru afgreidd ein af öðrum, í þeirri röð sem þau bárust. Fyrir vikið jókst hámarksafköst úr 18 þúsund í 50 þúsund færslur á sekúndu.
Skiptaáhættustjórnunarkerfi
Það eru engin takmörk fyrir fullkomnun og fljótlega hófum við nútímavæðingu aftur: innan ramma ASTS+ byrjuðum við að færa áhættustýringar- og uppgjörsreksturskerfi í sjálfstæða þætti. Við þróuðum sveigjanlegan nútíma arkitektúr og nýtt stigveldis áhættulíkan og reyndum að nota bekkinn þar sem það var hægt fixed_point í staðinn fyrir double.
En vandamál kom strax upp: hvernig á að samstilla alla viðskiptarökfræði sem hefur virkað í mörg ár og flytja hana yfir í nýja kerfið? Fyrir vikið varð að yfirgefa fyrstu útgáfuna af frumgerð nýja kerfisins. Önnur útgáfan, sem nú er að vinna í framleiðslu, er byggð á sama kóða, sem virkar bæði í viðskipta- og áhættuhlutanum. Við þróun var erfiðast að gera að sameina tvær útgáfur. Samstarfsmaður okkar Evgeniy Mazurenok framkvæmdi þessa aðgerð í hverri viku og í hvert skipti sem hann bölvaði í mjög langan tíma.
Þegar nýtt kerfi var valið þurftum við strax að leysa vandamálið við samspilið. Við val á gagnastrætó var nauðsynlegt að tryggja stöðugt jitter og lágmarks leynd. InfiniBand RDMA netið hentaði best fyrir þetta: meðalvinnslutími er 4 sinnum styttri en í 10 G Ethernet netkerfum. En það sem heillaði okkur var munurinn á hundraðshlutum - 99 og 99,9.
Auðvitað hefur InfiniBand sínar áskoranir. Í fyrsta lagi annað API - ibverbs í stað fals. Í öðru lagi eru nánast engar almennar opnar skilaboðalausnir til. Við reyndum að búa til okkar eigin frumgerð, en það reyndist mjög erfitt, svo við völdum viðskiptalausn - Confinity Low Latency Messaging (áður IBM MQ LLM).
Þá vaknaði það verkefni að skipta áhættukerfinu almennilega upp. Ef þú fjarlægir einfaldlega áhættuvélina og býrð ekki til millihnút, þá er hægt að blanda saman viðskiptum frá tveimur aðilum.
Svokallaðar Ultra Low Latency lausnir eru með endurpöntunarstillingu: hægt er að raða færslum frá tveimur aðilum í tilskildri röð við móttöku; þetta er útfært með því að nota sérstaka rás til að skiptast á upplýsingum um pöntunina. En við notum ekki þessa stillingu ennþá: það flækir allt ferlið og í mörgum lausnum er það alls ekki stutt. Að auki þyrfti að úthluta hverri færslu samsvarandi tímastimplum og í kerfi okkar er mjög erfitt að útfæra þetta kerfi á réttan hátt. Þess vegna notuðum við klassíska kerfið með skilaboðamiðlara, það er með sendanda sem dreifir skilaboðum á milli áhættuvélarinnar.
Annað vandamálið var tengt aðgangi viðskiptavinar: ef það eru nokkrar áhættugáttir þarf viðskiptavinurinn að tengjast hverri þeirra og það mun krefjast breytinga á laginu viðskiptavinarins. Við vildum komast í burtu frá þessu á þessu stigi, þannig að núverandi hönnun áhættugáttar vinnur úr öllum gagnastraumnum. Þetta takmarkar mjög hámarksafköst, en einfaldar kerfissamþættingu til muna.
Tvíverknaður
Kerfið okkar ætti ekki að hafa einn bilunarpunkt, það er að allir íhlutir verða að vera afritaðir, þar á meðal skilaboðamiðlari. Við leystum þetta vandamál með því að nota CLLM kerfið: það inniheldur RCMS þyrping þar sem tveir sendendur geta unnið í master-slave ham og þegar annar mistekst skiptir kerfið sjálfkrafa yfir í hinn.
Vinna með öryggisafrit gagnaver
InfiniBand er fínstillt fyrir rekstur sem staðbundið net, það er til að tengja búnað fyrir rekki, og InfiniBand net er ekki hægt að leggja á milli tveggja landfræðilega dreifðra gagnavera. Þess vegna innleiddum við brú/sendimann, sem tengist skilaboðageymslunni í gegnum venjulegt Ethernet net og miðlar öllum viðskiptum yfir á annað IB net. Þegar við þurfum að flytja úr gagnaveri getum við valið hvaða gagnaver við vinnum með núna.
Niðurstöður
Allt ofangreint var ekki gert í einu; það tók nokkrar endurtekningar að þróa nýjan arkitektúr. Við bjuggum til frumgerðina á mánuði en það tók meira en tvö ár að koma henni í gang. Við reyndum að ná bestu málamiðluninni á milli þess að auka vinnslutíma viðskipta og auka áreiðanleika kerfisins.
Þar sem kerfið var mikið uppfært, innleiddum við endurheimt gagna frá tveimur óháðum aðilum. Ef skilaboðageymslan virkar ekki rétt af einhverjum ástæðum geturðu tekið færsluskrána frá öðrum uppruna - frá áhættuvélinni. Þessari meginreglu er gætt í öllu kerfinu.
Meðal annars gátum við varðveitt forritaskil viðskiptavinarins þannig að hvorki miðlarar né aðrir þyrftu verulega endurvinnslu fyrir nýja arkitektúrinn. Við þurftum að breyta nokkrum viðmótum en það var engin þörf á að gera verulegar breytingar á rekstrarlíkaninu.
Við kölluðum núverandi útgáfu af pallinum okkar Rebus - sem skammstöfun fyrir tvær mest áberandi nýjungarnar í arkitektúrnum, Risk Engine og BUS.
Upphaflega vildum við aðeins úthluta hreinsunarhlutanum, en niðurstaðan varð risastórt dreift kerfi. Viðskiptavinir geta nú átt samskipti við annað hvort viðskiptagáttina, greiðslugáttina eða bæði.
Það sem við náðum á endanum:
Dregið úr biðtíma. Með litlu magni viðskipta virkar kerfið eins og fyrri útgáfan, en þolir á sama tíma mun meira álag.
Hámarksafköst jukust úr 50 þúsund í 180 þúsund færslur á sekúndu. Frekari aukning er hindruð af eini straumi pöntunarsamsvörunar.
Það eru tvær leiðir til frekari umbóta: samhliða samsvörun og breyta því hvernig það virkar með Gateway. Nú starfa allar hliðar samkvæmt afritunarkerfi, sem, við slíkt álag, hættir að virka eðlilega.
Að lokum get ég gefið nokkur ráð til þeirra sem eru að leggja lokahönd á fyrirtækjakerfi:
- Vertu alltaf viðbúinn því versta. Vandamál koma alltaf upp óvænt.
- Það er venjulega ómögulegt að endurgera arkitektúr fljótt. Sérstaklega ef þú þarft að ná hámarks áreiðanleika yfir marga vísbendingar. Því fleiri hnútar, því meira fjármagn þarf til stuðnings.
- Allar sérsniðnar og sérlausnir munu krefjast viðbótarauðlinda fyrir rannsóknir, stuðning og viðhald.
- Ekki fresta því að leysa vandamál varðandi áreiðanleika kerfisins og endurheimt eftir bilanir; taktu tillit til þeirra á fyrstu hönnunarstigi.
Heimild: www.habr.com