Pêşveçûna mîmariya pergala bazirganî û paqijkirina Borsaya Moskowê. Beş 1

Silav hemû! Navê min Sergey Kostanbaev e, li Exchange ez bingeha pergala bazirganiyê pêş dixe.

Dema ku fîlimên Hollywoodê Borsaya New Yorkê nîşan didin, her gav weha xuya dike: girseya mirovan, her kes tiştekî diqîre, kaxezan dihejîne, kaosek tam diqewime. Ev çu carî li vir li Borsaya Moskowê çênebûye, ji ber ku bazirganî ji destpêkê ve bi elektronîkî hatîye kirin û li ser bingeha du platformên sereke ye - Spectra (bazara forex) û ASTS (bazara biyanî, borsa û drav). Û îro ez dixwazim li ser pêşkeftina mîmariya pergala bazirganî û paqijkirina ASTS, li ser çareserî û dîtinên cihêreng biaxivim. Çîrok dê dirêj be, ji ber vê yekê ez neçar bûm ku wê bikim du beş.

Em yek ji kêm danûstendinên li cîhanê ne ku malên hemî çînan bazirganî dikin û karûbarên danûstendinê yên tevahî peyda dikin. Mînakî, sala borî em di warê qebareya bazirganiya bondoyan de di cîhanê de di rêza duyemîn de, di nav hemî borsayê de cîhê 25-an, di nav danûstendinên gelemperî de di warê kapîtalîzmê de cîhê 13-an.

Ji bo beşdarên bazirganiya profesyonel, pîvanên wekî dema bersivê, aramiya belavkirina demê (jitter) û pêbaweriya tevahî kompleks krîtîk in. Em niha rojane bi deh mîlyon danûstandinan pêvajoyê dikin. Pêvajoya her danûstendinê ji hêla kernelê pergalê ve bi dehan mîkroçirkeyan digire. Bê guman, operatorên mobîl di şeva Sersalê de an motorên lêgerînê bixwe xwedan bargiraniya kar ji ya me mezintir in, lê di warê bargiraniyê de, digel taybetmendiyên jorîn, hindik kes dikarin bi me re bidin ber hev, ji min re xuya dike. Di heman demê de, ji me re girîng e ku pergal yek duyemîn jî hêdî nebe, bêkêmasî bi îstîqrar bixebite, û hemî bikarhêner li ser bingehek wekhev bin.

Dîrokek piçûk

Di sala 1994 de, pergala ASTS ya Avusturalya li ser Borseya Diravî ya Navberî ya Moskowê (MICEX) hate destpêkirin, û ji wê gavê ve dîroka rûsî ya bazirganiya elektronîkî dikare were hesibandin. Di sala 1998 de, mîmariya danûstendinê hate nûjen kirin da ku bazirganiya Înternetê bide nasîn. Ji wê demê û vir ve, leza pêkanîna çareseriyên nû û guhertinên mîmarî di hemî pergal û jêrpergalan de tenê geş dibe.

Di wan salan de, pergala danûstendinê li ser hardware hi-end dixebitî - serverên HP Superdome 9000-a pir pêbawer (li ser PA-RISC), ku tê de bê guman her tişt dubare bû: jêrpergalên têketin / derketinê, torgilok, RAM (bi rastî, rêzek RAID ya RAM-ê hebû), pêvajoker (germ-guhezbar). Dikaribû bêyî sekinandina makîneyê her pêkhateyek serverê biguhezîne. Me pişta xwe da van amûran û wan bi rastî têkçûn-ewle hesibandin. Pergala xebitandinê pergalek HP UX-ya Unix-ê bû.

Lê ji dor 2010-an vir ve, fenomenek bi navê bazirganiya bi frekansa bilind (HFT), an bazirganiya frekansa bilind - bi hêsanî, robotên borsayê derketiye holê. Tenê di 2,5 salan de, barkirina ser serverên me 140 carî zêde bûye.

Bi mîmarî û amûrên kevnar re ne mimkûn bû ku li hember barekî wiha li ber xwe bide. Pêwîst bû ku bi rengekî adapteyî bihata kirin.

Destpêka

Daxwazên pergala danûstendinê dikare li du celeban were dabeş kirin:

• Transactions. Heke hûn dixwazin dolar, parve an tiştek din bikirin, hûn danûstendinek ji pergala bazirganiyê re dişînin û di derbarê serkeftinê de bersivek distînin.
• Daxwazên agahdariyê. Ger hûn dixwazin bihayê heyî fêr bibin, pirtûka fermanê an nîşanan bibînin, dûv re daxwazên agahdariyê bişînin.

Ji hêla şematîkî ve, bingeha pergalê dikare li sê astan were dabeş kirin:

• Asta xerîdar, ku tê de broker û xerîdar dixebitin. Ew hemî bi serverên gihîştinê re têkilî dikin.
• Pêşkêşkerên Gateway serverên caching in ku bi herêmî hemî daxwazên agahdariyê pêvajoyê dikin. Ma hûn dixwazin zanibin ku hîseyên Sberbank niha bi çi nirxê têne firotin? Daxwaz diçe servera gihîştinê.
• Lê heke hûn dixwazin parveyan bikirin, wê hingê daxwaz diçe servera navendî (Trade Engine). Ji bo her celeb sûkê serverek wusa heye, ew rolek girîng dileyzin, ji bo wan e ku me ev pergal çêkir.

Bingeha pergala bazirganiyê databasek aqilmend a bîranînê ye ku tê de hemî danûstendin danûstandinên danûstendinê ne. Bingeh bi C-yê hatibû nivîsandin, tenê girêdanên derveyî pirtûkxaneya libc bû û bi tevahî veqetandina bîranîna dînamîkî tune bû. Ji bo kêmkirina dema pêvajoyê, pergal bi komek rêzikên statîk û bi veguheztina daneya statîk dest pê dike: yekem, hemî daneyên roja heyî di bîranînê de têne barkirin, û çu gihîştina dîskê nayê kirin, hemî kar tenê di bîranînê de têne kirin. Dema ku pergal dest pê dike, hemî daneyên referansê jixwe têne rêz kirin, ji ber vê yekê lêgerîn pir bi bandor dixebite û di dema xebitandinê de hindik wext digire. Hemî tablo ji bo strukturên daneya dînamîkî bi navnîş û darên navber têne çêkirin da ku ew di dema xebitandinê de hewceyê veqetandina bîranînê nebin.

Ka em bi kurtî li ser dîroka pêşkeftina pergala xweya bazirganî û paqijkirinê bigerin.
Guhertoya yekem a mîmariya pergala bazirganî û paqijkirinê li ser pêwendiya ku jê re tê gotin Unix hate çêkirin: bîranîna hevbeş, semafor û dorê hatin bikar anîn, û her pêvajo ji yek têlekê pêk dihat. Ev nêzîkatî di destpêka salên 1990î de belav bû.

Guhertoya yekem a pergalê du astên Gateway û serverek navendî ya pergala bazirganiyê vedihewîne. Rêya xebatê wiha bû:

• Xerîdar daxwazek dişîne, ku digihîje Gateway. Ew rastdariya formatê (lê ne daneyê bixwe) kontrol dike û danûstendinên nerast red dike.
• Ger daxwazek agahdarî hatibe şandin, ew li herêmî tête bicîh kirin; heke em li ser danûstendinek dipeyivin, wê hingê ew berbi servera navendî ve tê verast kirin.
• Dûv re motora bazirganiyê danûstendinê pêvajo dike, bîranîna herêmî diguhezîne, û bersivek danûstendinê û danûstendinê bixwe ji bo dubarekirinê bi karanîna motorek dubarekirina cihêreng dişîne.
• Gateway bersivê ji girêka navendî distîne û ji xerîdar re dişîne.
• Piştî demekê, Gateway danûstendinê bi mekanîzmaya replikasyonê distîne, û vê carê ew wê li cîhê cîbicî dike, strukturên daneya xwe diguhezîne da ku daxwazên agahdariya paşîn daneyên herî dawî nîşan bide.

Bi rastî, ew modelek dubarekirinê diyar dike ku tê de Gateway bi tevahî kiryarên ku di pergala bazirganiyê de hatine kirin dubare dike. Kanalek veqetandî ya veqetandî piştrast kir ku danûstendin bi heman rêzê di nav gelek girêkên gihîştinê de hatine darve kirin.

Ji ber ku kod yek-têkilî bû, nexşeyek klasîk a bi qalikên pêvajoyê hate bikar anîn ku ji gelek xerîdaran re xizmet bike. Lêbelê, pir biha bû ku meriv tevahiya databasê bişewitîne, ji ber vê yekê pêvajoyên karûbarê sivik hatine bikar anîn ku pakêtên ji danişînên TCP berhev dikin û wan vediguhezînin yek rêzê (SystemV Message Queue). Gateway û Trade Engine tenê bi vê dorê re xebitîn, ji bo darvekirinê danûstandinan ji wir digirin. Êdî ne gengaz bû ku bersivek jê re were şandin, ji ber ku ne diyar bû ku kîjan pêvajoya karûbarê wê bixwîne. Ji ber vê yekê me serî li hîleyek da: her pêvajoyek birêkûpêk ji xwe re rêzek bersivê diafirand, û gava ku daxwazek ket rêza hatî, tagek ji bo rêza bersivê tavilê li wê hate zêdekirin.

Bi domdarî kopîkirina mîqdarên mezin ên daneyan ji dorê heya dorê pirsgirêkan diafirîne, nemaze ji bo daxwazên agahdariyê tîpîk. Ji ber vê yekê, me hîleyek din bikar anî: ji bilî rêza bersivê, her pêvajoyek bîranîna hevpar (SystemV Bîra Hevpar) jî çêkir. Pakêt bi xwe tê de hatibûn danîn, û tenê tagek di rêzê de hate hilanîn, ku dihêle meriv pakêta orîjînal bibîne. Vê yekê alîkariya hilanîna daneyan di cache ya pêvajoyê de kir.

SystemV IPC ji bo dîtina rewşa dorê, bîranîn û tiştên semaforê karûbaran vedihewîne. Me ev bi awayekî çalak bikar anî da ku fêm bikin ka di demek taybetî de çi diqewime, pakêt li ku kom bûne, çi hatine asteng kirin, hwd.

Nûjeniyên pêşîn

Berî her tiştî, me ji Gateway yek-pêvajoyê xilas kir. Kêmasiya wê ya girîng ev bû ku ew dikaribû yek danûstendina dubarekirinê an yek daxwazek agahdarî ji xerîdar bi rê ve bibe. Û her ku bar zêde dibe, Gateway dê demek dirêjtir bigire ku daxwazan bişopîne û dê nikaribe herikîna dubarekirinê pêvajoyê bike. Wekî din, heke xerîdar danûstendinek şandiye, wê hingê hûn tenê hewce ne ku rastdariya wê kontrol bikin û wê bêtir bişînin. Ji ber vê yekê, me pêvajoya yek Gateway bi gelek hêmanên ku dikarin paralel bimeşin guhezand: Agahdariya pir-tewra û pêvajoyên danûstendinê ji hev serbixwe li ser herêmek bîranîna hevbeş bi karanîna girtina RW-ê dimeşînin. Û di heman demê de me pêvajoyên şandin û dubarekirinê destnîşan kir.

Bandora Bazirganiya Frekansa Bilind

Guhertoya jorîn a mîmariyê heya 2010-an hebû. Di vê navberê de, em êdî ji performansa serverên HP Superdome ne razî bûn. Wekî din, mîmariya PA-RISC bi rastî mirî bû; firoşkar nûvekirinek girîng pêşkêş nekir. Wekî encamek, me dest pê kir ku ji HP UX/PA RISC berbi Linux/x86 ve biçin. Veguheztin bi adaptasyona serverên gihîştinê dest pê kir.

Çima em neçar bûn ku dîsa mîmarî biguherînin? Rastî ev e ku bazirganiya frekansa bilind bi girîngî profîla barkirinê li ser bingeha pergalê guhezandiye.

Ka em bibêjin danûstendinek me ya piçûk heye ku bû sedema guhertinek girîng a bihayê - kesek nîv mîlyar dolar kirî. Piştî çend milî çirkeyan, hemî beşdarên bazarê vê yekê dibînin û dest bi rastkirinê dikin. Bi xwezayî, daxwaz di rêzek mezin de têne rêz kirin, ku pergal dê demek dirêj dirêj bike ku paqij bike.

Di vê navbera 50 ms de, leza navîn di çirkekê de bi qasî 16 hezar danûstandinan e. Ger em paceyê kêm bikin 20 ms, em leza navînî 90 hezar danûstendinan di çirkeyê de digirin, bi 200 hezar danûstandinan di lûtkeyê de. Bi gotineke din, bar ne domdar e, bi teqînên ji nişka ve. Û rêza daxwazan divê her dem bi lez were pêvajo kirin.

Lê çima qet rêzek heye? Ji ber vê yekê, di mînaka me de, gelek bikarhêneran guheztina bihayê ferq kirin û li gorî wê danûstandin şandin. Ew têne Gateway, ew wan rêz dike, fermanek diyar dike û wan dişîne torê. Router pakêtan dihejînin û bi pêş ve diçin. Pakêta kê pêşî hat, ew danûstendin "serket". Wekî encamek, xerîdarên danûstendinê dest pê kir ku heke heman danûstendin ji çend Gateways were şandin, wê hingê şansên pêvajoyek bilez zêde dibin. Zû zû, robotên danûstendinê bi daxwazan dest bi bombebarankirina Gateway kirin, û berfek danûstendinan rabû.

Deverek nû ya pêşveçûnê

Piştî ceribandin û lêkolînek berfireh, me berê xwe da kernelê pergala xebitandinê ya rast. Ji bo vê yekê me RedHat Enterprise MRG Linux hilbijart, ku MRG tê wateya şandina tora rast-demê. Feydeya paçên rast-dem ev e ku ew pergalê ji bo darvekirina zûtirîn gengaz xweşbîn dikin: hemî pêvajo di rêzek FIFO de têne rêz kirin, naverok dikarin bêne veqetandin, bê derxistin, hemî danûstendin bi rêzek hişk têne kirin.

Sor - di kernelek birêkûpêk de bi dorê re dixebitin, kesk - di kernelek rast-dem de dixebitin.

Lê gihîştina derengiya kêm li ser serverên birêkûpêk ne ew çend hêsan e:

• Moda SMI, ku di mîmariya x86 de bingeha xebata bi dorhêlên girîng re ye, pir mudaxele dike. Pêvajoya her cûre bûyerên hardware û birêvebirina pêkhate û cîhazan ji hêla firmware ve di moda bi navê SMI-ya şefaf de tê kirin, ku tê de pergala xebitandinê qet nabîne ka firmware çi dike. Wekî qaîdeyek, hemî firoşkarên sereke ji bo serverên firmware-ê dirêjkirinên taybetî pêşkêş dikin ku destûrê didin kêmkirina mîqdara pêvajoya SMI-yê.
• Pêdivî ye ku kontrolek dînamîkî ya frekansa pêvajoyê tune be, ev dibe sedema demdirêjiya zêde.
• Dema ku têketina pergala pelan tê rijandin, hin pêvajo di kernelê de çêdibin ku dibin sedema derengiyên nediyar.
• Pêdivî ye ku hûn bala xwe bidin tiştên wekî CPU Affinity, Interrupt affinity, NUMA.

Divê ez bibêjim ku mijara sazkirina hardware û kernel Linux ji bo pêvajoyek rast-demê heqê gotarek cûda ye. Berî ku em encamek baş bi dest bixin, me gelek dem derbas kir û lêkolîn û ceribandin.

Dema ku ji serverên PA-RISC berbi x86 ve diçin, me bi pratîkî neçar ma ku koda pergalê pir biguhezînin, me tenê ew adapte kir û ji nû ve saz kir. Di heman demê de, me çend xeletî rast kirin. Mînakî, encamên vê rastiyê ku PA RISC pergalek Endianek Mezin bû, û x86 pergalek Endianek Biçûk bû, zû derket holê: mînakî, dane çewt hatin xwendin. Bûka dijwar ev bû ku PA RISC bikar tîne bi berdewamî hevgirtî (Bi rêzdarî hevgirtî) gihîştina bîranînê, di heman demê de ku x86 dikare karûbarên xwendinê ji nû ve rêz bike, ji ber vê yekê koda ku li ser platformek bêkêmasî derbasdar bû li ser platformek din şikest.

Piştî guheztina x86, performans hema hema sê qat zêde bû, dema navînî ya pêvajoya danûstendinê daket 60 μs.

Ka em naha ji nêz ve binihêrin ka çi guhertinên sereke di mîmariya pergalê de hatine çêkirin.

Destana rezerva germ

Dema ku guheztina serverên hilberê, me hay jê hebû ku ew kêmtir pêbawer in. Ji ber vê yekê, dema ku mîmariyek nû diafirîne, me berê xwe da îhtîmala têkçûna yek an çend girêkan. Ji ber vê yekê, pergalek standby-a germ hewce bû ku bikaribe pir zû veguhezîne makîneyên paşvekişandinê.

Wekî din, pêdiviyên din jî hebûn:

• Di bin şert û mercan de nabe ku hûn danûstandinên pêvajoyî winda bikin.
• Divê pergal ji binesaziya me re bi tevahî zelal be.
• Pêdivî ye ku xerîdar girêdanên daketî nebînin.
• Pêdivî ye ku veqetandî derengiyek girîng dernexîne ji ber ku ev ji bo danûstendinê faktorek krîtîk e.

Dema afirandina pergalek standby-ya germ, me senaryoyên weha wekî têkçûnek ducar nehesiband (mînak, tora li ser yek serverê rawestiya û servera sereke cemidand); îhtîmala xeletiyên di nermalavê de nehesiband ji ber ku ew di dema ceribandinê de têne nas kirin; û operasyona nerast a hardware nahesibîne.

Di encamê de, em gihîştin plana jêrîn:

• Pêşkêşkara sereke rasterast bi serverên Gateway re têkilî danî.
• Hemî danûstendinên ku li ser servera sereke hatine wergirtin tavilê bi kanalek veqetandî ve li servera hilanînê hatin dubare kirin. Hakem (walî) ger pirsgirêk çêbibin veguhertin koordîne kir.

  

• Pêşkêşkara sereke her danûstendinê pêvajo kir û li benda pejirandinê ji servera hilanînê bû. Ji bo ku derengiya herî hindik bihêle, me ji li benda qedandina danûstendinê li ser servera hilanînê dûr xist. Ji ber ku dema ku ew danûstendinek di nav torê de rêve çû bi dema darvekirinê re hevber bû, derengiyek zêde nehat zêdekirin.
• Me tenê dikarî statûya pêvajoyê ya pêşkêşkerên sereke û piştgir ji bo danûstendina berê kontrol bikin, û rewşa pêvajoyê ya danûstendina heyî nenas bû. Ji ber ku me hîn jî pêvajoyên yek-têl bikar tanîn, li benda bersivek Backup-ê dê tevahiya pêvajoyek pêvajoyê hêdî bike, ji ber vê yekê me lihevkirinek maqûl çêkir: me encama danûstendina berê kontrol kir.

Plan bi vî rengî xebitî.

Ka em bibêjin servera sereke bersivdayînê rawestîne, lê Gateways danûstandinê didomîne. Demek li ser servera hilanînê çêdibe, ew bi Walî re têkilî daynin, ku rola servera sereke jê re destnîşan dike, û hemî Gateways diguhezin servera sereke ya nû.

Ger servera sereke vegere serhêl, ew di heman demê de demek hundurîn jî çêdike, ji ber ku demek diyar ji Gateway-ê ji serverê re bangek çênebûye. Paşê jî berê xwe dide Walî û wî ji planê derdixe. Wekî encamek, danûstendin heya dawiya heyama bazirganiyê bi yek serverê re dixebite. Ji ber ku îhtîmala têkçûna serverê pir hindik e, ev nexşe bi tevahî pejirandî hate hesibandin; ew mantiqa tevlihev tune û ceribandina wê hêsan bû.

Pêdivî bimînin.

Source: www.habr.com