Mūsdienu tīmeklis ir gandrīz neiedomājams bez mediju satura: gandrīz katrai vecmāmiņai ir viedtālrunis, visi ir sociālajos tīklos, un uzturēšanas dīkstāves uzņēmumiem izmaksā dārgi. Šeit ir uzņēmuma stāsta atšifrējums par to, kā viņa organizēja fotoattēlu piegādi, izmantojot aparatūras risinājumu, ar kādām veiktspējas problēmām viņa saskārās šajā procesā, kas tās izraisīja un kā šīs problēmas tika atrisinātas, izmantojot programmatūras risinājumu, kura pamatā ir Nginx, vienlaikus nodrošinot kļūdu toleranci visos līmeņos (). Pateicamies Oļega stāsta autoriem Efimova un Aleksandra Dimova, kuras konferencē dalījās pieredzē .
— Sāksim ar nelielu ievadu par to, kā mēs saglabājam un saglabājam fotoattēlus kešatmiņā. Mums ir slānis, kurā mēs tos glabājam, un slānis, kurā mēs saglabājam fotoattēlus kešatmiņā. Tajā pašā laikā, ja vēlamies sasniegt augstu viltības ātrumu un samazināt krātuves slodzi, mums ir svarīgi, lai katra atsevišķa lietotāja fotogrāfija atrastos vienā kešatmiņas serverī. Pretējā gadījumā mums būtu jāinstalē tik reižu vairāk disku, cik mums ir vairāk serveru. Mūsu viltības līmenis ir aptuveni 99%, tas ir, mēs samazinām krātuves slodzi 100 reizes, un, lai to izdarītu, pirms 10 gadiem, kad tas viss tika būvēts, mums bija 50 serveri. Attiecīgi, lai apkalpotu šīs fotogrāfijas, mums būtībā bija nepieciešami 50 ārējie domēni, kurus apkalpo šie serveri.
Protams, uzreiz radās jautājums: ja kāds no mūsu serveriem pazūd un kļūst nepieejams, kādu trafika daļu mēs zaudējam? Apskatījām, kas ir tirgū, un nolēmām iegādāties kādu aparatūru, lai tā atrisinātu visas mūsu problēmas. Izvēle krita uz F5 tīkla uzņēmuma risinājumu (kurš, starp citu, nesen iegādājās NGINX, Inc): BIG-IP Local Traffic Manager.
Ko dara šī aparatūra (LTM): tas ir dzelzs maršrutētājs, kas nodrošina ārējo portu dzelžainu dublēšanu un ļauj maršrutēt trafiku, pamatojoties uz tīkla topoloģiju, dažiem iestatījumiem un veic veselības pārbaudes. Mums bija svarīgi, lai šo aparatūru varētu ieprogrammēt. Attiecīgi mēs varētu aprakstīt loģiku, kā konkrēta lietotāja fotogrāfijas tika pasniegtas no konkrētas kešatmiņas. Kā tas izskatās? Ir aparatūras daļa, kas skatās internetu vienā domēnā, vienā IP, veic SSL izkraušanu, parsē http pieprasījumus, atlasa kešatmiņas numuru no IRule, kur iet, un ļauj trafikam iet uz turieni. Tajā pašā laikā tas veic veselības pārbaudes, un gadījumā, ja kāda mašīna nav pieejama, mēs toreiz izdarījām tā, lai trafika tiktu uz vienu rezerves serveri. No konfigurācijas viedokļa, protams, ir dažas nianses, taču kopumā viss ir diezgan vienkārši: mēs reģistrējam karti, noteikta numura atbilstību mūsu IP tīklā, mēs sakām, ka klausīsimies portos 80 un 443, mēs sakām, ka, ja serveris nav pieejams, jums ir jānosūta trafika uz rezerves serveri, šajā gadījumā uz 35., un mēs aprakstām virkni loģikas par to, kā šī arhitektūra ir jāizjauc. Vienīgā problēma bija tā, ka valoda, kurā tika programmēta aparatūra, bija Tcl. Ja kāds to vispār atceras... šī valoda ir vairāk tikai rakstīšanai nekā programmēšanai ērta valoda:
Ko mēs saņēmām? Mēs saņēmām aparatūras daļu, kas nodrošina augstu mūsu infrastruktūras pieejamību, maršrutē visu mūsu satiksmi, sniedz labumu veselībai un vienkārši darbojas. Turklāt tas darbojas diezgan ilgu laiku: pēdējo 10 gadu laikā par to nav bijis sūdzību. 2018. gada sākumā mēs jau sūtījām aptuveni 80 80 fotoattēlu sekundē. Tā ir aptuveni XNUMX gigabitu trafika no abiem mūsu datu centriem.
Bet…
2018. gada sākumā topos ieraudzījām neglītu attēlu: fotogrāfiju nosūtīšanas laiks bija nepārprotami pieaudzis. Un tas pārstāja mums piemēroties. Problēma ir tā, ka šāda uzvedība bija redzama tikai satiksmes maksimuma laikā - mūsu uzņēmumam šī ir nakts no svētdienas uz pirmdienu. Bet pārējā laikā sistēma darbojās kā parasti, bez kļūmes pazīmēm.
Tomēr problēma bija jāatrisina. Mēs noskaidrojām iespējamās vājās vietas un sākām tās novērst. Pirmkārt, mēs, protams, paplašinājām ārējās augšupsaites, veicām pilnīgu iekšējo augšupsaišu auditu un atklājām visas iespējamās vājās vietas. Bet tas viss nedeva acīmredzamu rezultātu, problēma nepazuda.
Vēl viens iespējamais sašaurinājums bija pašu fotoattēlu kešatmiņu veiktspēja. Un mēs nolēmām, ka, iespējams, problēma ir viņu rokās. Mēs paplašinājām veiktspēju - galvenokārt tīkla porti fotoattēlu kešatmiņās. Bet atkal nekādi acīmredzami uzlabojumi netika novēroti. Beigās mēs pievērsām lielu uzmanību paša LTM veiktspējai, un šeit grafikos redzējām skumju attēlu: slodze uz visiem CPU sāk iet gludi, bet tad pēkšņi nonāk plato. Tajā pašā laikā LTM pārstāj adekvāti reaģēt uz veselības pārbaudēm un augšupsaites un sāk nejauši tos izslēgt, kas izraisa nopietnu veiktspējas pasliktināšanos.
Tas ir, mēs esam identificējuši problēmas avotu, identificējuši vājo vietu. Atliek izlemt, ko mēs darīsim.
Pirmā, acīmredzamākā lieta, ko mēs varētu darīt, ir kaut kā modernizēt pašu LTM. Bet šeit ir dažas nianses, jo šī aparatūra ir diezgan unikāla, jūs neaiziesit uz tuvāko lielveikalu un nenopirksit. Tas ir atsevišķs līgums, atsevišķs licences līgums, un tas prasīs daudz laika. Otrs variants ir sākt domāt pašam, nākt klajā ar savu risinājumu, izmantojot savus komponentus, vēlams izmantojot atvērtās piekļuves programmu. Atliek vien izlemt, ko tieši šim izvēlēsimies un cik daudz laika veltīsim šīs problēmas risināšanai, jo lietotāji nesaņēma pietiekami daudz fotoattēlu. Tāpēc mums tas viss ir jādara ļoti, ļoti ātri, varētu teikt vakar.
Tā kā uzdevums izklausījās šādi: "Dariet kaut ko pēc iespējas ātrāk un izmantojot mūsu rīcībā esošo aparatūru", pirmais, ko mēs domājām, bija vienkārši noņemt dažas ne pārāk jaudīgas mašīnas no priekšpuses, ievietot Nginx, ar kuru mēs zinām, kā strādājiet un mēģiniet ieviest visu to pašu loģiku, ko izmantoja aparatūra. Tas ir, faktiski mēs atstājām savu aparatūru, uzstādījām vēl 4 serverus, kas mums bija jākonfigurē, izveidojām tiem ārējos domēnus, līdzīgi kā tas bija pirms 10 gadiem... Nedaudz zaudējām pieejamību, ja šīs mašīnas kritās, bet vēl mazāk, viņi atrisināja mūsu lietotāju problēmu lokāli.
Attiecīgi loģika paliek nemainīga: mēs instalējam Nginx, tas var veikt SSL izkraušanu, mēs varam kaut kā ieprogrammēt maršrutēšanas loģiku, veikt veselības pārbaudes konfigurācijās un vienkārši dublēt loģiku, kas mums bija iepriekš.
Sēdēsim rakstīt konfigurācijas. Sākumā šķita, ka viss ir ļoti vienkārši, bet diemžēl katram uzdevumam ir ļoti grūti atrast rokasgrāmatas. Tāpēc mēs neiesakām vienkārši googlēt “kā konfigurēt Nginx fotoattēliem”: labāk ir atsaukties uz oficiālo dokumentāciju, kas parādīs, kuri iestatījumi ir jāpieskaras. Bet konkrēto parametru labāk izvēlēties pats. Nu tad viss ir vienkārši: aprakstam serverus, kas mums ir, aprakstam sertifikātus... Bet pats interesantākais patiesībā ir pati maršrutēšanas loģika.
Sākumā mums šķita, ka mēs vienkārši aprakstām savu atrašanās vietu, saskaņojot tajā esošās fotoattēlu kešatmiņas numuru, izmantojot rokas vai ģeneratoru, lai aprakstītu, cik daudz augšējo straumi mums ir nepieciešams, katrā augšējā straumē mēs norādām serveri, uz kuru trafikam vajadzētu būt. go un rezerves serveris — ja galvenais serveris nav pieejams:
Bet, iespējams, ja viss būtu tik vienkārši, mēs vienkārši ietu mājās un neko neteiktu. Diemžēl ar noklusējuma Nginx iestatījumiem, kas kopumā tika veikti daudzu gadu izstrādes laikā un nav pilnībā piemēroti šim gadījumam... konfigurācija izskatās šādi: ja kādam augšpus serverim ir pieprasījuma kļūda vai taimauts, Nginx vienmēr pārslēdz satiksmi uz nākamo. Turklāt pēc pirmās kļūmes 10 sekunžu laikā serveris arī tiks izslēgts gan kļūdas, gan taimauta dēļ - to pat nevar konfigurēt nekādā veidā. Tas ir, ja mēs noņemsim vai atiestatīsim taimauta opciju augšupējā direktīvā, tad, lai gan Nginx neapstrādās šo pieprasījumu un atbildēs ar kādu ne pārāk labu kļūdu, serveris tiks izslēgts.
Lai no tā izvairītos, mēs veicām divas darbības:
a) viņi aizliedza Nginx to darīt manuāli - un diemžēl vienīgais veids, kā to izdarīt, ir vienkārši iestatīt maksimālās atteices iestatījumus.
b) atcerējāmies, ka citos projektos izmantojam moduli, kas ļauj veikt iepriekšējās veselības pārbaudes - attiecīgi veicām diezgan biežas veselības pārbaudes, lai dīkstāves avārijas gadījumā būtu minimālas.
Diemžēl arī tas vēl nav viss, jo burtiski pirmās divas šīs shēmas darbības nedēļas parādīja, ka arī TCP veselības pārbaude ir neuzticama lieta: augšējā serverī tā var nebūt Nginx vai Nginx D stāvoklī, un šajā gadījumā kodols pieņems savienojumu, veselības pārbaude izdosies, bet nedarbosies. Tāpēc šo uzreiz nomainījām ar veselības pārbaudes http, uztaisījām konkrētu, kas, ja atgriež 200, tad šajā skriptā viss strādā. Varat veikt papildu loģiku - piemēram, kešatmiņas serveru gadījumā pārbaudiet, vai failu sistēma ir pareizi uzstādīta:
Un tas mums būtu piemērots, izņemot to, ka šobrīd ķēde pilnībā atkārtoja to, ko darīja aparatūra. Bet mēs gribējām darīt labāk. Iepriekš mums bija viens rezerves serveris, un tas, iespējams, nav īpaši labi, jo, ja jums ir simts serveru, tad, ja vairāki vienlaikus neizdodas, viens rezerves serveris, visticamāk, netiks galā ar slodzi. Tāpēc mēs nolēmām sadalīt rezervāciju pa visiem serveriem: mēs vienkārši izveidojām vēl vienu atsevišķu augšup, ierakstījām visus serverus ar noteiktiem parametriem atbilstoši slodzei, ko tie var apkalpot, pievienojām tās pašas veselības pārbaudes, kuras mums bija iepriekš:
Tā kā vienas augšteces ietvaros nav iespējams pāriet uz citu augšteci, bija jāpārliecinās, ka gadījumā, ja galvenā augštece, kurā mēs vienkārši ierakstījām pareizo, nepieciešamo fotoattēlu kešatmiņu, nebija pieejama, mēs vienkārši izgājām kļūdu_lapu, lai atgrieztos, no plkst. kur mēs devāmies uz dublējumu augšup pa straumi:
Un burtiski pievienojot četrus serverus, tas ir tas, ko mēs saņēmām: mēs nomainījām daļu slodzes - noņēmām to no LTM uz šiem serveriem, ieviesām tur to pašu loģiku, izmantojot standarta aparatūru un programmatūru, un uzreiz saņēmām bonusu, ko šie serveri var mērogot, jo tos var vienkārši piegādāt tik daudz, cik nepieciešams. Vienīgais negatīvais ir tas, ka esam zaudējuši augstu pieejamību ārējiem lietotājiem. Bet tajā brīdī mums tas bija jāupurē, jo bija nepieciešams nekavējoties atrisināt problēmu. Tātad, mēs noņēmām daļu slodzes, tajā laikā tas bija aptuveni 40%, LTM jutās labi, un burtiski divas nedēļas pēc problēmas sākuma mēs sākām sūtīt nevis 45 55 pieprasījumu sekundē, bet 20 XNUMX. Faktiski mēs pieaugām par XNUMX% — šī ir nepārprotami trafika, kuru mēs lietotājam nenodevām. Un pēc tam viņi sāka domāt, kā atrisināt atlikušo problēmu - nodrošināt augstu ārējo pieejamību.
Mums bija neliela pauze, kuras laikā apspriedām, kādu risinājumu šim nolūkam izmantosim. Bija priekšlikumi nodrošināt uzticamību, izmantojot DNS, izmantojot dažus mājās rakstītus skriptus, dinamiskos maršrutēšanas protokolus... bija daudz iespēju, taču jau kļuva skaidrs, ka patiesi uzticamai fotoattēlu piegādei ir jāievieš vēl viens slānis, kas to uzraudzīs. . Mēs šīs mašīnas saucām par fotorežisoriem. Programmatūra, uz kuru mēs paļāvāmies, bija Keepalived:
Pirmkārt, no kā sastāv Keepalived? Pirmais ir VRRP protokols, kas plaši pazīstams tīkla lietotājiem un atrodas tīkla iekārtās, kas nodrošina kļūdu toleranci ārējai IP adresei, ar kuru klienti pieslēdzas. Otrā daļa ir IPVS, IP virtuālais serveris, lai balansētu starp foto maršrutētājiem un nodrošinātu kļūdu toleranci šajā līmenī. Un trešais – veselības pārbaudes.
Sāksim ar pirmo daļu: VRRP – kā tas izskatās? Ir noteikts virtuālais IP, kuram ir ieraksts dns badoocdn.com, kur klienti savienojas. Kādā brīdī mums ir IP adrese vienā serverī. Keepalived paketes darbojas starp serveriem, izmantojot VRRP protokolu, un, ja master pazūd no radara - serveris ir pārstartējis vai kas cits, tad rezerves serveris automātiski paņem šo IP adresi - nekādas manuālas darbības nav nepieciešamas. Atšķirība starp galveno un rezerves kopiju galvenokārt ir prioritāte: jo augstāks tas ir, jo lielāka iespēja, ka iekārta kļūs par galveno. Ļoti liela priekšrocība ir tā, ka jums nav jākonfigurē IP adreses pašā serverī, pietiek ar to aprakstu konfigurācijā, un, ja IP adresēm ir nepieciešami pielāgoti maršrutēšanas noteikumi, tas ir aprakstīts tieši konfigurācijā, izmantojot tāda pati sintakse, kā aprakstīts VRRP pakotnē. Jūs nesaskarsities ar nepazīstamām lietām.
Kā tas izskatās praksē? Kas notiek, ja kāds no serveriem neizdodas? Tiklīdz meistars pazūd, mūsu dublieris pārstāj saņemt sludinājumus un automātiski kļūst par meistaru. Pēc kāda laika saremontējām galveno, pārstartējām, paaugstinājām Keepalived - sludinājumi pienāk ar augstāku prioritāti nekā dublējums, un dublējums automātiski atgriežas atpakaļ, noņem IP adreses, nekādas manuālas darbības nav jāveic.
Tādējādi esam nodrošinājuši ārējās IP adreses kļūdu toleranci. Nākamā daļa ir kaut kādā veidā līdzsvarot trafiku no ārējās IP adreses uz fotoattēlu maršrutētājiem, kas to jau pārtrauc. Ar balansēšanas protokoliem viss ir diezgan skaidrs. Tas ir vai nu vienkāršs aplis, vai nedaudz sarežģītākas lietas, wrr, saraksta savienojums un tā tālāk. Tas būtībā ir aprakstīts dokumentācijā, nekas īpašs nav. Bet piegādes veids... Šeit mēs sīkāk aplūkosim, kāpēc mēs izvēlējāmies kādu no tiem. Tie ir NAT, tiešais maršrutēšana un TUN. Fakts ir tāds, ka mēs nekavējoties plānojām piegādāt 100 gigabitu trafiku no vietnēm. Ja jūs aplēšat, jums ir vajadzīgas 10 gigabitu kartes, vai ne? 10 gigabitu kartes vienā serverī jau ir ārpus vismaz mūsu “standarta aprīkojuma” koncepcijas. Un tad mēs atcerējāmies, ka mēs ne tikai atdodam daļu satiksmes, bet arī fotogrāfijas.
Kas ir īpašs? — Milzīga atšķirība starp ienākošo un izejošo satiksmi. Ienākošā trafika ir ļoti maza, izejošā trafika ir ļoti liela:
Ja paskatās uz šiem grafikiem, var redzēt, ka šobrīd režisors saņem apmēram 200 MB sekundē, šī ir ļoti parasta diena. Mēs atdodam 4,500 MB sekundē, mūsu attiecība ir aptuveni 1/22. Jau tagad ir skaidrs, ka, lai pilnībā nodrošinātu izejošo trafiku 22 darbinieku serveriem, mums ir nepieciešams tikai viens, kas pieņem šo savienojumu. Šeit mums palīdz tiešās maršrutēšanas algoritms.
Kā tas izskatās? Mūsu fotorežisors, saskaņā ar viņa tabulu, pārraida savienojumus ar fotoattēlu maršrutētājiem. Bet foto maršrutētāji atgriežas trafiku sūta tieši uz internetu, nosūta klientam, tas neiet atpakaļ caur foto režisoru, tādējādi ar minimālu mašīnu skaitu nodrošinām pilnīgu kļūdu toleranci un visas trafika pumpēšanu. Konfigurācijās tas izskatās šādi: mēs norādām algoritmu, mūsu gadījumā tas ir vienkāršs rr, sniedzam tiešās maršrutēšanas metodi un tad sākam uzskaitīt visus reālos serverus, cik mums no tiem ir. Kas noteiks šo trafiku. Ja mums tur ir vēl viens vai divi serveri vai vairāki serveri, šāda vajadzība rodas - mēs vienkārši pievienojam šo sadaļu konfigurācijai un pārāk neuztraucamies. No reālu serveru puses, no fotoattēlu maršrutētāja puses, šī metode prasa minimālo konfigurāciju, tā ir lieliski aprakstīta dokumentācijā, un tur nav nekādu slazdu.
Īpaši jauki ir tas, ka šāds risinājums neparedz radikālu lokālā tīkla pārveidošanu; tas mums bija svarīgi, mums tas bija jāatrisina ar minimālām izmaksām. Ja paskatās , tad redzēsim, kā tas izskatās. Šeit mums ir noteikts virtuālais serveris, portā 443, klausās, pieņem savienojumu, ir uzskaitīti visi strādājošie serveri, un jūs varat redzēt, ka savienojums ir, dod vai ņem, tas pats. Ja paskatāmies statistiku uz tā paša virtuālā servera, mums ir ienākošās paketes, ienākošie savienojumi, bet izejošo nav absolūti. Izejošie savienojumi nonāk tieši pie klienta. Labi, mēs varējām to līdzsvarot. Kas notiek, ja kāds no mūsu fotoattēlu maršrutētājiem neizdodas? Galu galā dzelzs ir dzelzs. Tas var nonākt kodola panikā, var salūzt, strāvas padeve var izdegt. Jebkas. Tāpēc ir nepieciešamas veselības pārbaudes. Tie var būt tikpat vienkārši kā porta atvērtības pārbaude vai kaut kas sarežģītāks, līdz pat dažiem mājās rakstītiem skriptiem, kas pat pārbaudīs biznesa loģiku.
Mēs apstājāmies kaut kur pa vidu: mums ir https pieprasījums uz konkrētu vietu, tiek izsaukts skripts, ja tas atbild ar 200. atbildi, mēs uzskatām, ka ar šo serveri viss ir kārtībā, ka tas ir dzīvs un var ieslēgties diezgan viegli.
Kā tas atkal izskatās praksē? Izslēgsim serveri apkopei - piemēram, BIOS mirgošanai. Žurnālos mums uzreiz ir taimauts, mēs redzam pirmo rindiņu, pēc tam pēc trim mēģinājumiem tas tiek atzīmēts kā “neizdevies” un vienkārši tiek noņemts no saraksta.
Ir iespējama arī otra uzvedības iespēja, kad VS ir vienkārši iestatīts uz nulli, bet, ja fotogrāfija tiek atgriezta, tas nedarbojas labi. Parādās serveris, tur sākas Nginx, veselības pārbaude uzreiz saprot, ka savienojums darbojas, ka viss ir kārtībā, un serveris parādās mūsu sarakstā, un tam nekavējoties tiek piemērota slodze. Dežūras administratoram nav jāveic nekādas manuālas darbības. Serveris atsāknējās naktī - uzraudzības nodaļa mums par to naktī nezvana. Viņi informē, ka tas noticis, viss ir kārtībā.
Tātad diezgan vienkāršā veidā ar neliela serveru skaita palīdzību mēs atrisinājām ārējo kļūdu tolerances problēmu.
Atliek vien piebilst, ka tas viss, protams, ir jāuzrauga. Atsevišķi jāatzīmē, ka Keepalivede kā programmatūra, kas rakstīta jau sen, ir daudz veidu, kā to uzraudzīt, gan izmantojot pārbaudes, izmantojot DBus, SMTP, SNMP un standarta Zabbix. Turklāt viņš pats prot rakstīt burtus gandrīz par katru šķaudīšanu, un, godīgi sakot, mēs kaut kādā brīdī pat domājām to izslēgt, jo viņš raksta daudz burtu par jebkuru trafika pārslēgšanu, ieslēgšanu, par katru IP savienojumu, un tā tālāk . Protams, ja serveru ir daudz, tad ar šiem burtiem var sevi apbērt. Mēs uzraugām nginx fotoattēlu maršrutētājos, izmantojot standarta metodes, un aparatūras uzraudzība nav pazudusi. Mēs, protams, ieteiktu vēl divas lietas: pirmkārt, ārējās veselības pārbaudes un pieejamību, jo, pat ja viss darbojas, iespējams, lietotāji nesaņem fotogrāfijas, jo ir problēmas ar ārējiem pakalpojumu sniedzējiem vai kaut kas sarežģītāks. Vienmēr ir vērts kaut kur citā tīklā, Amazon vai kaut kur citur paturēt atsevišķu mašīnu, kas var ping jūsu serveriem no ārpuses, kā arī ir vērts izmantot vai nu anomāliju noteikšanu, tiem, kas zina, kā veikt viltīgu mašīnmācīšanos, vai vienkārša uzraudzība, vismaz lai izsekotu, vai pieprasījumi ir strauji samazinājušies vai, gluži pretēji, palielinājušies. Tas var būt arī noderīgi.
Apkoposim: mēs faktiski nomainījām dzelžaino risinājumu, kas kādā brīdī mums vairs nederēja, ar diezgan vienkāršu sistēmu, kas visu dara tāpat, tas ir, nodrošina HTTPS trafika pārtraukšanu un tālāku viedo maršrutēšanu ar nepieciešamās veselības pārbaudes. Mēs esam palielinājuši šīs sistēmas stabilitāti, tas ir, mums joprojām ir augsta pieejamība katram slānim, kā arī pluss ir tas, ka ir diezgan viegli to visu mērogot katrā slānī, jo tā ir standarta aparatūra ar standarta programmatūru, tas ir. , esam vienkāršojuši iespējamo problēmu diagnostiku.
Ar ko mēs tikām galā? Mums radās problēma 2018. gada janvāra brīvdienās. Pirmajos sešos mēnešos, kamēr ieviesām šo shēmu, mēs to paplašinājām uz visu trafiku, lai noņemtu visu trafiku no LTM, pieaugām tikai viena datu centra trafika apjoms no 40 gigabitiem līdz 60 gigabitiem, un tajā pašā laikā visu 2018. gadu varēja nosūtīt gandrīz trīs reizes vairāk fotoattēlu sekundē.
Avots: www.habr.com