Malpera nûjen bêyî naveroka medyayê hema bêje nayê fikirîn: hema hema her dapîr xwedan smartfonek e, her kes li ser torên civakî ne, û dema domandinê ji bo pargîdaniyan biha ye. Li vir vegotinek çîroka pargîdaniyê ye li ser ka wê çawa radestkirina wêneyan bi karanîna çareseriyek hardware organîze kir, çi pirsgirêkên performansê ew di pêvajoyê de rû bi rû man, çi bûn sedema wan, û çawa ev pirsgirêk bi karanîna çareseriyek nermalavê li ser bingeha Nginx hatin çareser kirin, di heman demê de ku tolerasyona xeletiyê di her astê de misoger dike (). Em spasiya nivîskarên çîroka Oleg dikin Efimova û Alexandra Dymova, ku ezmûna xwe di konferansê de parve kirin .
- Ka em bi destpêkek piçûk dest pê bikin ka em çawa wêneyan hildigirin û vedişêrin. Qatek me heye ku em wan lê hilînin, û qatek ku em wêneyan vedişêrin hene. Di heman demê de, heke em dixwazin bigihîjin rêjeyek xapandinê ya bilind û barkirina hilanînê kêm bikin, ji me re girîng e ku her wêneyek bikarhênerek kesane li ser serverek caching be. Wekî din, em neçar in ku bi qasî ku serverên me hene gelek caran dîskên saz bikin. Rêjeya fêlbaziya me li dora %99 e, ango em barkirina hilanîna xwe 100 carî kêm dikin û ji bo vê yekê 10 sal berê, dema ku ev hemî dihatin çêkirin, 50 serverên me hebûn. Li gorî vê yekê, ji bo ku em van wêneyan xizmet bikin, di esasê xwe de hewcedariya me bi 50 domên derveyî yên ku van serveran xizmetê dikin.
Bi xwezayî, pirs tavilê derket holê: ger yek ji serverên me têkeve û berdest nebe, em kîjan beşek seyrûseferê winda dikin? Me li tiştên ku li sûkê hene mêze kir û biryar da ku em perçeyek amûrek bikirin da ku ew hemî pirsgirêkên me çareser bike. Hilbijartin ket ser çareseriya pargîdaniya tora F5 (ya ku, bi awayê, vê dawiyê NGINX, Inc kirî): Rêvebirê Trafîka Herêmî ya BIG-IP.
Tiştê ku ev perçeyek hardware (LTM) dike: ew rêwerek hesin e ku ji benderên xwe yên derveyî hesin zêde dike û dihêle hûn li ser bingeha topolojiya torê, li ser hin mîhengan, seyrûseferê rêve bikin û kontrolên tenduristiyê dike. Ji me re girîng bû ku ev perçeyek hardware dikare were bernamekirin. Li gorî vê yekê, em dikarin mantiqê diyar bikin ka wêneyên bikarhênerek taybetî çawa ji cacheyek taybetî hatine pêşkêş kirin. Çawa xuya dike? Parçeyek hardware heye ku li ser yek domainê, yek IP-yê li Înternetê dinêre, ssl bar dike, daxwazên http par dike, jimareyek cache ji IRule hildibijêre, ku biçe ku derê, û dihêle ku seyrûsefer biçe wir. Di heman demê de, ew kontrolên tenduristiyê dike, û di bûyera ku hin makîneyek peyda nebe, wê demê me wisa kir ku seyrûsefer biçe ser serverek paşvekêşanê. Ji hêla veavakirinê ve, bê guman, hin nuwaze hene, lê bi gelemperî her tişt pir hêsan e: em qertek, jimareyek diyarkirî ji IP-ya xwe re li ser torê tomar dikin, em dibêjin ku em ê li portên 80 guhdarî bikin. û 443, em dibêjin ku ger server peyda nebe, wê hingê hûn hewce ne ku seyrûseferê bişînin ya paşverû, di vê rewşê de ya 35-an, û em komek mantiqê vedibêjin ka divê ev mîmarî çawa were hilweşandin. Pirsgirêk tenê ew bû ku zimanê ku hardware tê de hatî bername Tcl bû. Ger kesek vê yekê bi bîr bîne… ev ziman ji zimanek ji bo bernamekirinê rehettir tenê nivîsandinê ye:
Me çi girt? Me perçeyek hardware wergirt ku hebûna zêde ya binesaziya me misoger dike, hemî seyrûsefera me rê dike, feydeyên tenduristiyê peyda dike û tenê dixebite. Wekî din, ew ji bo demek pir dirêj dixebite: di van 10 salên çûyî de tu gilî li ser wê tune. Di destpêka sala 2018-an de, me jixwe di çirkekê de nêzî 80 hezar wêne dişand. Ev li derûdora 80 gigabit seyrûsefera ji her du navendên daneyên me ye.
Lebê…
Di destpêka sala 2018-an de, me li ser nexşeyan wêneyek xirab dît: dema şandina wêneyan bi eşkere zêde bû. Û ew li gorî me rawestiya. Pirsgirêk ev e ku ev tevger tenê di dema pezê trafîkê de xuya bû - ji bo pargîdaniya me ev şev ji Yekşemê heya Duşemê ye. Lê wextê mayî jî sîstem wekî berê tevdigere, ti nîşanên têkçûnê tune.
Lêbelê, diviyabû pirsgirêk çareser bibûya. Me astengiyên muhtemel tespît kirin û dest bi rakirina wan kir. Berî her tiştî, bê guman, me lînkên derveyî berfireh kir, vekolînek bêkêmasî ya girêdanên hundurîn kir, û hemî astengiyên gengaz dîtin. Lê van hemûyan encamek eşkere neda, pirsgirêk ji holê ranebûn.
Xemgîniyek din a mumkun performansa caşên wêneyan bixwe bû. Û me biryar da ku dibe ku pirsgirêk bi wan re bimîne. Welê, me performans berfireh kir - nemaze portên torê yên li ser kaşên wêneyan. Lê dîsa tu pêşketineke eşkere nehat dîtin. Di dawiyê de, me bi baldarî bala xwe da performansa LTM-ê bixwe, û li vir me wêneyek xemgîn li ser grafiyan dît: barkirina hemî CPU-yan dest pê dike ku bi rêkûpêk biçe, lê dûv re ji nişkê ve tê deverek. Di heman demê de, LTM bi têra xwe bersivê dide kontrolên tenduristî û girêdanan rawestîne û dest bi birêkûpêk qutkirina wan dike, ku dibe sedema xirabûna performansa cidî.
Yanî me çavkaniya pirsgirêkê tesbît kir, kêşe tesbît kir. Ew dimîne ku em biryar bidin ka em ê çi bikin.
Ya yekem, ya herî eşkere ya ku em dikarin bikin ev e ku bi rengekî LTM-ya xwe nûjen bikin. Lê li vir hin nuwaze hene, ji ber ku ev hardware pir bêhempa ye, hûn ê neçin supermarketa herî nêzîk û wê bikirin. Ev peymanek cuda ye, peymanek lîsansê ya cuda ye, û ew ê gelek dem bigire. Vebijarka duyemîn ev e ku hûn dest bi ramana xwe bikin, çareseriya xwe bi karanîna pêkhateyên xwe, bi tercîhî bernameyek gihîştina vekirî bikar bînin. Tiştê ku dimîne ev e ku em biryar bidin ka em ê bi rastî ji bo vê yekê hilbijêrin û em ê çiqas wext ji bo çareserkirina vê pirsgirêkê derbas bikin, ji ber ku bikarhêner têra wêneyan nedigirtin. Ji ber vê yekê, divê em van hemûyan pir û pir zû bikin, mirov dikare bêje duh.
Ji ber ku peywir dişibihe "tiştekî bi lez û bez bikin û hardware ku me heye bikar bînin," yekem tiştê ku me fikirî ev bû ku em bi hêsanî hin makîneyên ne pir hêzdar ji pêşiyê derxînin, Nginx bixin wir, ku em pê re dizanin. bixebitin û hewl bidin ku hemî heman mantiqa ku hardware berê dikir bicîh bikin. Yanî, bi rastî, me dev ji hardware xwe berda, 4 serverên din ên ku diviyabû em mîheng bikirana, saz kirin, ji wan re domên derveyî çêkirin, mîna 10 sal berê... Ger van makîneyan bikevin, me hinekî winda kir, lê hîn kêmtir, wan pirsgirêka bikarhênerên me yên herêmî çareser kir.
Li gorî vê yekê, mantiq heman dimîne: em Nginx saz dikin, ew dikare SSL-offload bike, em dikarin bi rengekî mentiqê rêvekirinê bername bikin, di mîhengan de kontrolên tenduristiyê û bi tenê mantiqa ku me berê hebû dubare bikin.
Ka em rûnin konfigurasyonan binivîsin. Di destpêkê de xuya bû ku her tişt pir hêsan e, lê, mixabin, pir dijwar e ku meriv ji bo her peywirê manualan bibîne. Ji ber vê yekê, em tenê googlêkirina "çawa mîhengkirina Nginx ji bo wêneyan" pêşniyar nakin: çêtir e ku hûn serî li belgeya fermî bidin, ku dê nîşan bide ka kîjan mîhengan divê were destgirtin. Lê çêtir e ku hûn bixwe pîvana taybetî hilbijêrin. Welê, wê hingê her tişt hêsan e: em serverên ku me hene vedibêjin, em sertîfîkayan vedibêjin... Lê ya herî balkêş, bi rastî, mantiqa rêgezê bixwe ye.
Di destpêkê de ji me re xuya bû ku em bi tenê cîhê xwe vedibêjin, hejmara cache wêneya xwe ya tê de li hev dikin, destên xwe an jeneratorek bikar tînin da ku diyar bikin ka çend jor hewcedariya me ne, di her jor de em servera ku divê seyrûsefer jê re tê de destnîşan bikin. herin, û serverek hilanînê - heke servera sereke peyda nebe:
Lê, belkî, heke her tişt ew qas hêsan bûya, em ê bi hêsanî biçin malê û tiştek nebêjin. Mixabin, bi mîhengên xwerû yên Nginx, yên ku bi gelemperî, di gelek salên pêşkeftinê de hatine çêkirin û bi tevahî ji bo vê rewşê ne maqûl in... veavakirin bi vî rengî xuya dike: heke hin serverek jorîn xeletiyek daxwazê an dema wextê hebe, Nginx her gav trafîkê diguhezîne ya din. Digel vê yekê, piştî têkçûna yekem, di nav 10 çirkeyan de dê server jî hem bi xeletî û hem jî bi demê ve were girtin - ev jî bi tu awayî nayê mîheng kirin. Ango, heke em vebijarka demajoyê ya di rêwerznameya jorîn de rakin an ji nû ve bikin, wê hingê, her çend Nginx dê vê daxwazê nexebite û dê bi hin xeletiyek ne pir baş bersivê bide, server dê biqede.
Ji bo ku em ji vê yekê dûr nekevin, me du tişt kirin:
a) wan Nginx ji kirina vê yekê bi destan qedexe kir - û mixabin, riya yekane ya kirina vê yekê ev e ku meriv bi tenê mîhengên têkçûna herî zêde saz bike.
b) me ji bîr kir ku di projeyên din de em modulek bikar tînin ku destûrê dide me ku em kontrolên tenduristiyê yên paşerojê bikin - li gorî vê yekê, me pir caran kontrolên tenduristiyê kir da ku di bûyerek qezayê de dema bêhnvedanê hindik be.
Mixabin, ev jî ne hemî ye, ji ber ku bi rastî du hefteyên pêşîn ên xebata vê planê destnîşan kir ku kontrolkirina tenduristiya TCP-ê jî tiştek nebawer e: li ser servera jorîn dibe ku ew ne Nginx, an jî Nginx di dewleta D-de be, û di di vê rewşê de kernel dê girêdanê qebûl bike, kontrolkirina tenduristiyê dê derbas bibe, lê dê nexebite. Ji ber vê yekê, me tavilê ev bi http-ya tenduristiyê veguhezand, yek taybetî çêkir, ku heke 200 vegere, wê hingê her tişt di vê nivîsarê de dixebite. Hûn dikarin mantiqa din jî bikin - mînakî, di doza serverên caching de, kontrol bikin ku pergala pelan rast hatî danîn:
Û ev ê ji me re xweş be, ji bilî ku di wê gavê de çerx bi tevahî tiştê ku hardware kir dubare kir. Lê me dixwest em çêtir bikin. Berê, me yek serverek hilanînê hebû, û ev belkî ne pir baş e, ji ber ku ger sed serverên we hebin, wê hingê gava ku çend yekcar têk diçin, ne gengaz e ku serverek hilanînê bi barkirinê re mijûl bibe. Ji ber vê yekê, me biryar da ku veqetandinê li ser hemî serveran belav bikin: me bi tenê jor veguhezek din a veqetandî çêkir, li wir hemî server bi hin parameteran re li gorî barkirina ku ew dikarin xizmet bikin nivîsandin, heman kontrolên tenduristiyê yên ku me berê hebûn lê zêde kirin:
Ji ber ku ne gengaz e ku meriv di nav herikek jorîn de biçe berveberek din, pêdivî bû ku meriv pê ewle bibûya ku ger hilika jorîn a sereke, ku me tê de tenê cache wêneya rast û pêwîst tomar kir, tune bûya, em bi tenê ji rûpela çewtiyê derbasî paşveçûnê bûn, ji cihê ku em çûne paşperdeya jorîn:
Û bi rastî bi lêzêdekirina çar pêşkêşkeran, ya ku me bi dest xist ev e: me beşek ji barkirinê guhezand - me ew ji LTM ji van serveran rakir, heman mantiqê li wir bicîh kir, bi karanîna nermalava standard û nermalava standard bikar anî, û tavilê bonûsa ku van serveran dikarin bikar bînin wergirtin. pîvaz bin, ji ber ku ew dikarin bi tenê bi qasî ku hewce be peyda bikin. Welê, tenê neyînî ev e ku me hebûna zêde ji bo bikarhênerên derveyî winda kiriye. Lê di wê kêliyê de me neçar ma ku vê yekê feda bike, ji ber ku pêwîst bû tavilê pirsgirêk çareser bibin. Ji ber vê yekê, me beşek barkirinê jê kir, ew di wê demê de bi qasî 40% bû, LTM xwe xweş hîs kir, û bi rastî du hefte piştî ku pirsgirêk dest pê kir, me dest bi şandina ne 45k daxwaz di çirkeyê de, lê 55k kir. Bi rastî, em ji% 20 mezin bûn - ev eşkere seyrûsefera ku me neda bikarhênerê. Û piştî wê wan dest pê kir ku bifikirin ka meriv çawa pirsgirêka mayî çareser bike - da ku gihîştina derveyî bilind peyda bike.
Me hinekî rawestand, di wê de me nîqaş kir ku em ê ji bo vê yekê çi çareserî bikar bînin. Pêşniyar hebûn ku pêbaweriya bi karanîna DNS-ê, karanîna hin nivîsarên malê-nivîsandî, protokolên rêveçûna dînamîkî… gelek vebijark hebûn, lê jixwe diyar bû ku ji bo radestkirina wêneyan bi rastî pêbawer, hûn hewce ne ku qatek din destnîşan bikin ku dê vê yekê bişopîne. . Me ji van makîneyan re got derhênerên wêneyan. Nermalava ku me pişta xwe dayê Keepalived bû:
Ji bo destpêkê, Keepalived ji çi pêk tê? Ya yekem protokola VRRP e, ku bi berfirehî ji torêvanan re tê zanîn, li ser alavên torê ye ku tolerasyona xeletiyê ji navnîşana IP-ya derveyî ya ku xerîdar pê ve girêdayî peyda dike peyda dike. Beşa duyemîn IPVS, servera virtual IP-yê ye, ji bo hevsengkirina di navbera routerên wêneyan de û dabînkirina tolerasyona xeletiyê di vê astê de. Û sêyemîn - kontrolên tenduristiyê.
Ka em bi beşa yekem dest pê bikin: VRRP - ew çawa xuya dike? Hin IP-ya virtual heye, ku têketinek di dns badoocdn.com de heye, ku xerîdar tê de têne girêdan. Di demekê de, me navnîşek IP-ê li ser yek serverê heye. Pakêtên Keepalived di navbera pêşkêşkeran de bi karanîna protokola VRRP dimeşin, û ger master ji radarê winda bibe - pêşkêşker ji nû ve dest pê kiribe an tiştek din, wê hingê servera hilanînê bixweber vê navnîşana IP-yê hildibijêre - tu kiryarên destan hewce ne. Cûdahiya di navbera master û paşvekişandinê de bi giranî pêşîn e: her ku bilindtir be, şansê ku makîne dê bibe master ew qas mezintir e. Awantajek pir mezin ev e ku hûn ne hewce ne ku hûn navnîşanên IP-yê li ser serverê bixwe mîheng bikin, bes e ku meriv wan di mîhengê de rave bike, û heke navnîşanên IP-yê hewceyê hin rêzikên rêveçûna xwerû hewce bike, ev rasterast di veavakirinê de, bi karanîna vebijarkê tê diyar kirin. heman hevoksaziya ku di pakêta VRRP de tête diyar kirin. Hûn ê bi tiştên nenas re rûbirû nebin.
Ev di pratîkê de çawa xuya dike? Ger yek ji serveran têk biçe çi diqewime? Hema ku master wenda dibe, paşgira me ji wergirtina reklaman raweste û bixweber dibe master. Piştî demekê, me master tamîr kir, ji nû ve dest pê kir, Keepalived bilind kir - reklam bi pêşanîyek ji paşvekişandinê bilindtir digihîjin, û paşgir bixweber paşde vedigere, navnîşanên IP-yê jê dike, ne hewce ye ku kiryarên destan werin kirin.
Bi vî rengî, me tolerasyona xeletiya navnîşana IP-ya derveyî piştrast kiriye. Beşa din ev e ku meriv bi rengekî seyrûseferê ji navnîşana IP-ya derveyî bigire heya rêwerên wêneyan ên ku berê wê biqedînin hevseng bikin. Bi protokolên hevsengiyê re her tişt pir zelal e. Ev an dor-robinek hêsan e, an jî tiştên hinekî tevlihevtir, wrr, girêdana navnîşê û hwd. Ev bi bingehîn di belgeyê de tête diyar kirin, tiştek taybetî tune. Lê rêbaza radestkirinê... Li vir em ê ji nêz ve binihêrin ka çima me yek ji wan hilbijart. Ev NAT, Rêvekirina Rasterê û TUN in. Rastî ev e ku me tavilê plan kir ku em 100 gigabit trafîkê ji malperan radest bikin. Ger hûn texmîn bikin, hûn hewceyê 10 kartên gigabit in, rast? 10 kartên gigabit di yek serverê de jixwe ji çarçoweya, bi kêmanî, têgeha me ya "amûrên standard" wêdetir e. Û paşê me bîr kir ku em ne tenê hin trafîkê didin, em wêneyan didin.
Çi taybet e? - Cûdahiya pir mezin di navbera seyrûsefera hatin û derketinê de. Trafîka hatinî pir hindik e, seyrûsefera derketinê pir mezin e:
Ger hûn li van grafîkan binerin, hûn dikarin bibînin ku di vê gavê de derhêner serê saniyeyê bi qasî 200 MB distîne, ev rojek pir asayî ye. Em serê saniyeyê 4,500 MB vedigerînin, rêjeya me bi qasî 1/22 ye. Jixwe diyar e ku ji bo bi tevahî seyrûsefera derketinê ji 22 serverên karker re peyda bikin, em tenê hewceyê yeka ku vê pêwendiyê qebûl dike. Li vir algorîtmaya rêveçûna rasterast tê alîkariya me.
Çawa xuya dike? Derhênerê me yê wêneyê, li gorî tabloya xwe, girêdanên bi routerên wêneyan re vediguhezîne. Lê routerên wêneyan seyrûsefera vegerê rasterast ji Înternetê re dişînin, wê ji xerîdar re dişînin, ew bi derhênerê wêneyê venagere, bi vî rengî, bi hejmareke hindiktirîn makîneyan, em tolerasyona xeletiya bêkêmasî û pompkirina hemî seyrûseferê misoger dikin. Di mîhengan de wiha xuya dike: em algorîtmayê destnîşan dikin, di rewşa me de ew rr-ya hêsan e, rêbaza rêveçûna rasterast peyda dikin û dûv re dest bi navnîşkirina hemî pêşkêşkerên rastîn dikin, ka çend ji wan hene. Ku dê vê trafîkê diyar bike. Ger li wir yek an du pêşkêşkerên din, an çend serverên me hebin, hewcedariyek wusa çêdibe - em tenê vê beşê li mîhengê zêde dikin û zêde meraq nakin. Ji hêla serverên rastîn ve, ji hêla routerê wêneyê ve, ev rêbaz konfigurasyona herî hindik hewce dike, ew di belgeyê de bi rengek bêkêmasî tête diyar kirin, û li wir çu xeletî tune.
Tiştê ku bi taybetî xweş e ev e ku çareseriyek wusa nayê wê wateyê ku ji nû ve dîzaynkirina tora herêmî ev yek ji bo me girîng bû ku em vê yekê bi lêçûnên herî kêm çareser bikin; Ger hûn lê binêrin , wê demê em ê bibînin ka ew çawa xuya dike. Li vir serverek meya virtual heye, li ser porta 443, guhdarî dike, pêwendiyê qebûl dike, hemî pêşkêşkerên xebatê têne navnîş kirin, û hûn dikarin bibînin ku girêdan, bidin an bistînin, yek e. Ger em li statîstîkên li ser heman servera virtual binêre, pakêtên me yên hatine, girêdanên me hene, lê bê guman ên derketinê tune. Têkiliyên derketinê rasterast diçin xerîdar. Okay, me karîbû hevsengiya wê derxînin. Naha, heke yek ji routerên wêneya me têk bibe, çi dibe? Jixwe hesin hesin e. Dibe ku ew bikeve nav panika kernelê, dibe ku bişkîne, dibe ku dabînkirina hêzê bişewite. Hemû. Ji ber vê yekê kontrolên tenduristiyê hewce ne. Ew dikarin bi qasî ku kontrol bikin ka port çawa vekirî ye, an tiştek tevlihevtir, heya hin nivîsarên malê-nivîsandî yên ku dê mantiqa karsaziyê jî kontrol bikin hêsan bin.
Em li deverek navîn sekinîn: me daxwazek https ji cîhek taybetî re heye, skrîptê tê gotin, heke ew bi bersivek 200-emîn bersivê bide, em bawer dikin ku her tişt bi vê serverê re baş e, ku ew zindî ye û dikare bi tevahî were veguheztin bi hêsanî.
Ev, dîsa, di pratîkê de çawa xuya dike? Werin em serverê ji bo lênihêrînê qut bikin - mînakî BIOS-ê bişewitînin. Di têketinan de, tavilê demek me heye, em rêza yekem dibînin, dûv re piştî sê hewldanan ew wekî "serneketî" tê nîşankirin, û ew bi tenê ji navnîşê tê derxistin.
Vebijarkek tevgerê ya duyemîn jî mimkun e, dema ku VS bi tenê li ser sifir were danîn, lê heke wêne were vegerandin, ev baş naxebite. Pêşkêşkar tê, Nginx li wir dest pê dike, kontrolkirina tenduristiyê tavilê fêm dike ku pêwendiyek dixebite, ku her tişt baş e, û server di navnîşa me de xuya dike, û bar tavilê dest pê dike ku li ser were sepandin. Ji rêvebirê peywirê re kiryarên destan ne hewce ne. Pêşkêşkar bi şev ji nû ve hat destpêkirin - beşa çavdêriyê bi şev li ser vê yekê gazî me nake. Ew we agahdar dikin ku ev çêbû, her tişt baş e.
Ji ber vê yekê, bi awayek hêsan, bi alîkariya hejmareke piçûk server, me pirsgirêka tolerasyona xeletiya derveyî çareser kir.
Tiştê ku tê gotin ev e ku ev hemî, bê guman, pêdivî ye ku were şopandin. Ji hev veqetandî, divê were zanîn ku Keepalivede, wekî nermalava ku demek berê hatî nivîsandin, gelek awayên çavdêriya wê hene, hem jî bi karanîna kontrolên DBus, SMTP, SNMP, û Zabbix standard. Zêdeyî, ew bi xwe dizane hema hema ji bo her pişikê nameyan dinivîse, û rast be, di demek de me jî fikirî ku wê vemirînin, ji ber ku ew ji bo her guheztina seyrûseferê, vekirina, ji bo her girêdana IP-yê gelek tîpan dinivîse. wate ya vê çîye . Bê guman, heke gelek server hebin, wê hingê hûn dikarin xwe bi van tîpan bişkînin. Em nginx-ê li ser routerên wêneyan bi karanîna rêbazên standard çavdêrî dikin, û çavdêriya hardware ji holê ranebûye. Bê guman, em ê du tiştên din jî şîret bikin: yekem, kontrolên tenduristiyê yên derveyî û hebûna, ji ber ku her çend her tişt kar bike jî, di rastiyê de, dibe ku bikarhêner ji ber pirsgirêkên bi pêşkêşkerên derveyî an tiştek tiştek tevlihevtir wêneyan wernegirin. Her gav hêja ye ku meriv li cîhek li ser torgilokek din, li Amazon-ê an cîhek din, makîneyek veqetandî ya ku dikare serverên we ji derve ping bike, bihêle, û di heman demê de hêja ye ku meriv an tespîtkirina anomalî bikar bîne, ji bo kesên ku dizanin fêrbûna makîneya xapînok, an çavdêriya hêsan çawa bikin. , bi kêmanî ji bo ku bişopînin ka daxwaz bi tundî kêm bûne, an, berevajî, zêde bûne. Ew jî dikare bikêr be.
Werin em kurt bikin: bi rastî, me çareseriya bi hesinî, ya ku di demekê de nema ji me re guncav kir, bi pergalek pir hêsan ku her tiştî heman tiştî dike, yanî ew bi dawîkirina seyrûsefera HTTPS-ê û rêvekirina bêtir aqilmend bi kontrolên tenduristiyê yên pêwîst. Me îstîqrara vê pergalê zêde kiriye, ango, hîna me ji bo her qatê hebûna zêde heye, ji bilî vê me bonusa wê heye ku meriv wê li ser her qatê pîvandinê pir hêsan e, ji ber ku ew bi nermalava standard re hardware standard e, yanî , me tespîtkirina pirsgirêkên gengaz hêsan kiriye.
Em bi çi dawî hatin? Di betlaneyên Çileya 2018'an de me pirsgirêkek hebû. Di şeş mehên ewil de dema ku me ev plan xiste meriyetê, me ew li hemî trafîkê berfireh kir da ku hemî seyrûseferê ji LTM derxînin, me tenê di seyrûsefera yek navendek daneyê de ji 40 gigabit berbi 60 gigabit mezin bû, û di heman demê de ji bo tevahiya sala 2018-an karîbûn hema hema sê qat zêdetir wêneyan di çirkekê de bişînin.
Source: www.habr.com