Rrjeti modern është pothuajse i paimagjinueshëm pa përmbajtje mediatike: pothuajse çdo gjyshe ka një smartphone, të gjithë janë në rrjetet sociale dhe koha e ndërprerjes së shërbimit është e kushtueshme për kompanitë. Për vëmendjen tuaj, një transkriptim i historisë së kompanisë në lidhje me mënyrën se si ajo organizoi shpërndarjen e fotove duke përdorur një zgjidhje harduerike, çfarë problemesh të performancës hasi në proces, çfarë i shkaktoi ato dhe si u zgjidhën këto probleme duke përdorur një zgjidhje softuerike të bazuar në Nginx, duke siguruar njëkohësisht tolerancë ndaj gabimeve në të gjitha nivelet (). Falënderojmë autorët e tregimit Oleg Efimova dhe Alexandra Dymova, të cilat ndanë përvojën e tyre në konferencë .
Le të fillojmë me një hyrje të vogël se si i ruajmë dhe ruajmë fotografitë. Ne kemi një shtresë ku i ruajmë ato dhe një shtresë ku i ruajmë fotografitë. Në të njëjtën kohë, nëse duam të arrijmë një mashtrim të madh dhe të zvogëlojmë ngarkesën në ruajtje, është e rëndësishme për ne që çdo foto e një përdoruesi individual të shtrihet në një server të memorizimit. Përndryshe, do të na duhej të instalonim sa herë më shumë disqe sa kemi më shumë serverë. Norma jonë e goditjes është rreth 99%, domethënë, ne e zvogëlojmë ngarkesën në hapësirën tonë me 100 herë, dhe për ta bërë këtë, 10 vjet më parë, kur po ndërtohej e gjithë kjo, kishim 50 serverë. Rrjedhimisht, për të dhënë këto foto, na duheshin, në fakt, 50 domene të jashtme që shërbejnë këta serverë.
Natyrisht, menjëherë u ngrit pyetja: nëse një nga serverët tanë shkon poshtë dhe bëhet i padisponueshëm, çfarë pjese të trafikut humbasim? Ne shikuam se çfarë ishte në treg dhe vendosëm të blinim një copë hekuri që të na zgjidhte të gjitha problemet. Zgjedhja ra në zgjidhjen e kompanisë së rrjetit F5 (e cila, nga rruga, bleu NGINX, Inc jo shumë kohë më parë): BIG-IP Local Traffic Manager.
Çfarë bën kjo copë hekuri (LTM): është një ruter hekuri që bën tepricë hekuri të portave të tij të jashtme dhe ju lejon të drejtoni trafikun bazuar në topologjinë e rrjetit, në disa cilësime dhe bën kontrolle shëndetësore. Ishte e rëndësishme për ne që kjo copë hekuri të mund të programohej. Prandaj, ne mund të përshkruanim logjikën se si fotot e një përdoruesi të caktuar u kthyen nga një cache e veçantë. Si duket? Ekziston një pjesë e harduerit që shikon internetin për një domen, një ip, bën shkarkimin e ssl, analizon kërkesat http, zgjedh një numër cache nga IRule, ku të shkojë dhe lejon trafikun të shkojë atje. Në të njëjtën kohë, ai bën kontrolle shëndetësore dhe në rast të mungesës së një makinerie, ne e bëmë atë që trafiku të shkonte në një server rezervë në atë kohë. Nga pikëpamja e konfigurimit, natyrisht, ka disa nuanca, por në përgjithësi gjithçka është mjaft e thjeshtë: ne përshkruajmë një hartë, një numër i caktuar korrespondon me IP-në tonë në rrjet, ne themi se do të dëgjojmë në portet 80 dhe 443, ne themi se nëse serveri nuk është i disponueshëm, atëherë duhet të lini trafikun të shkojë në rezervë, në këtë rast, në datën 35, dhe ne përshkruajmë një sërë logjike se si duhet të çmontohet kjo arkitekturë. Problemi i vetëm ishte se gjuha në të cilën është programuar copa e hekurit është gjuha Tcl. Nëse dikush e mban mend këtë ... kjo gjuhë është më shumë vetëm për shkrim sesa një gjuhë e përshtatshme për programim:
Çfarë morëm? Ne morëm një pjesë të harduerit që siguron disponueshmëri të lartë të infrastrukturës sonë, drejton të gjithë trafikun tonë, ofron kontrolle shëndetësore dhe thjesht funksionon. Për më tepër, ajo ka funksionuar për një kohë mjaft të gjatë: gjatë 10 viteve të fundit, nuk ka pasur ankesa për të. Nga fillimi i vitit 2018, ne tashmë po bënim rreth 80 mijë foto në sekondë. Kjo është diku rreth 80 gigabit trafik nga të dyja qendrat tona të të dhënave.
Megjithatë…
Në fillim të vitit 2018, pamë një pamje të shëmtuar në tabela: koha për të kthyer fotot është rritur qartë. Dhe nuk na përshtatej më. Problemi është se kjo sjellje ishte e dukshme vetëm në kulmin e trafikut - për kompaninë tonë kjo është nata nga e diela në të hënë. Por pjesën tjetër të kohës sistemi u soll si zakonisht, pa shenja thyerjeje.
Megjithatë, problemi duhej zgjidhur. Ne identifikuam pengesat e mundshme dhe filluam t'i eliminojmë ato. Para së gjithash, natyrisht, ne zgjeruam lidhjet e jashtme, kryem një rishikim të plotë të lidhjeve të brendshme dhe gjetëm të gjitha pengesat e mundshme. Por e gjithë kjo nuk dha një rezultat të dukshëm, problemi nuk u zhduk.
Një tjetër pengesë e mundshme ishte performanca e vetë skedarëve të fotografive. Dhe ne vendosëm që ndoshta problemi qëndron tek ata. Epo, ne kemi zgjeruar performancën - në thelb, portet e rrjetit në cache fotografish. Por përsëri, nuk u pa ndonjë përmirësim i qartë. Në fund, i kushtuam shumë vëmendje performancës së vetë LTM, dhe këtu pamë një pamje të trishtuar në grafikët: ngarkimi i të gjithë CPU-ve fillon të ecë pa probleme, por më pas qëndron ashpër në raft. Në të njëjtën kohë, LTM ndalon t'i përgjigjet në mënyrë adekuate kontrolleve shëndetësore dhe lidhjeve dhe fillon t'i çaktivizojë ato në mënyrë të rastësishme, gjë që çon në degradim serioz të performancës.
Kjo do të thotë, ne kemi identifikuar burimin e problemit, kemi identifikuar pengesën. Mbetet për të vendosur se çfarë do të bëjmë.
Gjëja e parë e dukshme që mund të bëjmë është të modernizojmë disi vetë LTM. Por këtu ka disa nuanca, sepse ky hekur është mjaft unik, nuk do të shkoni në supermarketin më të afërt dhe ta blini. Është një kontratë e veçantë, një kontratë e veçantë licence dhe do të marrë shumë kohë. Opsioni i dytë është të filloni të mendoni vetë, të dilni me zgjidhjen tuaj për komponentët tuaj, mundësisht duke përdorur një program me burim të hapur. Mbetet vetëm për të vendosur se çfarë saktësisht do të zgjedhim për këtë dhe sa kohë do të shpenzojmë për zgjidhjen e këtij problemi, sepse përdoruesit nuk morën foto. Prandaj, është e nevojshme të bëhet e gjithë kjo shumë, shumë shpejt, mund të thuhet - dje.
Meqenëse detyra dukej si "bëni diçka sa më shpejt të jetë e mundur dhe duke përdorur pajisjen që kemi", gjëja e parë që menduam ishte thjesht të hiqnim disa makina jo më të fuqishme nga përpara, vendosëm Nginx atje, me të cilin ne dimë se si për të punuar dhe përpiquni të zbatoni të njëjtën logjikë që bënte dikur pjesa e hekurit. Kjo do të thotë, në fakt, ne lamë pajisjen tonë, instaluam 4 serverë të tjerë që duhej të konfiguronim, bëmë domene të jashtme për ta në analogji me atë si ishte 10 vjet më parë ... Ne humbëm pak disponueshmërinë nëse këto makina binin. , por, megjithatë më pak, zgjidhi problemin e përdoruesve tanë në nivel lokal.
Prandaj, logjika mbetet e njëjtë: ne instalojmë Nginx, ai mund të bëjë shkarkimin SSL, ne mund të programojmë disi logjikën e rrugëzimit, kontrollet e shëndetit në konfigurimet dhe thjesht dublikojmë logjikën që kishim më parë.
Ne ulemi për të shkruar konfigurimet. Në fillim dukej se gjithçka ishte shumë e thjeshtë, por, për fat të keq, është shumë e vështirë të gjesh manuale për secilën detyrë. Prandaj, ne nuk ju këshillojmë që thjesht të kërkoni në Google "si të konfiguroni Nginx për foto": është më mirë t'i referoheni dokumentacionit zyrtar, i cili do të tregojë se cilat cilësime duhet të preken. Por është më mirë të zgjidhni vetë një parametër specifik. Epo, atëherë gjithçka është e thjeshtë: ne përshkruajmë serverët që kemi, përshkruajmë certifikatat ... Por gjëja më interesante është, në fakt, vetë logjika e rrugëzimit.
Në fillim, na u duk se thjesht përshkruajmë vendndodhjen tonë, përputhim numrin tonë të cache-it të fotografive në të, përshkruajmë me duart tona ose një gjenerator se sa rrjedha të sipërme na duhen, në secilën rrjedhë të sipërme tregojmë serverin në të cilin duhet të shkojë trafiku dhe serveri rezervë - në rast se serveri kryesor nuk është i disponueshëm:
Por, me siguri, nëse gjithçka do të ishte kaq e thjeshtë, do të shkonim në shtëpi dhe nuk do të tregonim asgjë. Fatkeqësisht, me cilësimet e paracaktuara të Nginx, të cilat, në përgjithësi, janë bërë gjatë shumë viteve të zhvillimit dhe jo tamam për këtë rast ... konfigurimi duket si ky: në rast se ndonjë server në rrjedhën e sipërme ka një gabim kërkese ose afat kohor, Nginx gjithmonë kalon trafikun në tjetrin. Në të njëjtën kohë, pas dështimit të parë, serveri gjithashtu do të fiket brenda 10 sekondave, si gabimisht ashtu edhe me kohë - kjo as nuk mund të konfigurohet në asnjë mënyrë. Kjo do të thotë, nëse heqim ose rivendosim opsionin e afatit në direktivën e sipërme, atëherë, megjithëse Nginx nuk do ta përpunojë këtë kërkesë dhe do të përgjigjet me ndonjë gabim jo shumë të mirë, serveri do të fiket.
Për të shmangur këtë, ne bëmë dy gjëra:
a) ata e ndaluan Nginx që ta bënte këtë me dorë - dhe për fat të keq, mënyra e vetme për ta bërë këtë është thjesht të vendosni cilësimet maksimale të dështimit.
b) kujtuam se në projekte të tjera përdorim një modul që ju lejon të bëni kontrolle shëndetësore në sfond - në përputhje me rrethanat, kemi bërë kontrolle shëndetësore mjaft të shpeshta në mënyrë që të kemi kohë minimale joproduktive në rast aksidenti.
Fatkeqësisht, as kjo nuk është e gjitha, sepse fjalë për fjalë dy javët e para të funksionimit të kësaj skeme treguan se kontrolli shëndetësor i TCP është gjithashtu një gjë jo e besueshme: jo Nginx, ose Nginx në gjendjen D nuk mund të lançohen në serverin në rrjedhën e sipërme, dhe në në këtë rast kerneli do të pranojë lidhjen, kontrolli shëndetësor do të kalojë, por nuk do të funksionojë. Prandaj, menjëherë e zëvendësuam me kontrollin shëndetësor të http, bëmë një specifik, i cili, nëse tashmë jep 200, atëherë gjithçka funksionon në këtë skenar. Ju mund të bëni logjikë shtesë - për shembull, në rastin e serverëve të memorizimit, kontrolloni që sistemi i skedarëve të jetë montuar saktë:
Dhe kjo do të na përshtatej, përveç se në momentin qarku përsëriti plotësisht atë që bëri copa e hekurit. Por ne donim të bënim më mirë. Më parë, ne kishim një server rezervë, dhe kjo ndoshta nuk është shumë e mirë, sepse nëse keni njëqind serverë, atëherë kur disa bien menjëherë, një server rezervë nuk ka gjasa të përballojë ngarkesën. Prandaj, vendosëm të shpërndajmë rezervimin midis të gjithë serverëve: thjesht bëmë një tjetër të veçantë në rrjedhën e sipërme, regjistruam të gjithë serverët atje me parametra të caktuar në përputhje me atë ngarkesë që mund të shërbejnë, shtuam të njëjtat kontrolle shëndetësore që kishim më parë:
Meqenëse nuk mund të shkosh në një rrjedhë tjetër në rrjedhën e sipërme brenda një rrjedhe në rrjedhën e sipërme, ishte e nevojshme të siguroheshim që nëse pjesa kryesore në rrjedhën e sipërme, në të cilën thjesht shkruanim cache-in e duhur dhe të nevojshëm të fotografive, nuk ishte e disponueshme, ne thjesht shkuam në rikthim përmes error_page, nga ku shkuam në rezervimin në rrjedhën e sipërme:
Dhe fjalë për fjalë duke shtuar katër serverë, ne morëm këtë: ne zëvendësuam një pjesë të ngarkesës - hoqëm nga LTM në këta serverë, zbatuam të njëjtën logjikë atje duke përdorur pajisje standarde dhe softuer, menjëherë morëm një bonus që këta serverë mund të shkallëzohen, sepse ato mund të jenë thjesht vendosni aq sa ju nevojitet. Epo, e vetmja negative është se kemi humbur disponueshmërinë e lartë për përdoruesit e jashtëm. Por në atë kohë më duhej ta sakrifikoja këtë, sepse ishte e nevojshme ta zgjidhja menjëherë problemin. Pra, hoqëm një pjesë të ngarkesës, ishte rreth 40% në atë kohë, LTM u bë më mirë dhe fjalë për fjalë dy javë pasi filloi problemi, filluam të japim jo 45 mijë kërkesa në sekondë, por 55 mijë. Në fakt, ne u rritëm me 20% - ky është qartë trafiku që nuk i dhamë përdoruesit. Dhe pas kësaj, ata filluan të mendojnë se si të zgjidhin problemin e mbetur - për të siguruar disponueshmëri të lartë të jashtme.
Patëm një pauzë gjatë së cilës diskutuam se çfarë zgjidhje do të përdornim për këtë. Kishte propozime për të siguruar besueshmërinë duke përdorur DNS, me ndihmën e disa skripteve të vetë-shkruara, protokolleve dinamike të rrugëtimit ... kishte shumë opsione, por tashmë u bë e qartë se për një kthim vërtet të besueshëm të fotografive, duhet të futni një shtresë tjetër që do ta monitorojë këtë. Ne i quajtëm këto makina regjisorë fotografish. Softueri në të cilin u mbështetëm ishte Keepalived:
Për të filluar, nga ajo që përbëhet Keepalived. I pari është protokolli VRRP, i njohur gjerësisht për rrjetet, i vendosur në pajisjet e rrjetit që ofron tolerancë ndaj gabimeve për adresën IP të jashtme me të cilën lidhen klientët. Pjesa e dytë është IPVS, serveri virtual IP, për të balancuar ndërmjet ruterave të fotografive dhe për të siguruar tolerancë ndaj gabimeve në këtë nivel. Dhe e treta është kontrolli shëndetësor.
Le të fillojmë me pjesën e parë: VRRP - si duket? Ekziston një IP e caktuar virtuale, e cila ka një hyrje në dns badoocdn.com, ku lidhen klientët. Në një moment në kohë, ne kemi një adresë IP në një server. Paketat e Keepalived ekzekutohen midis serverëve duke përdorur protokollin VRRP, dhe nëse masteri zhduket nga radari - serveri është rindezur ose diçka tjetër, atëherë serveri rezervë e ngre automatikisht këtë adresë IP - nuk nevojiten veprime manuale. Master dhe rezervë ndryshojnë, kryesisht prioritet: sa më i lartë të jetë, aq më shumë ka të ngjarë që makina të bëhet master. Një avantazh shumë i madh është se nuk keni nevojë të konfiguroni adresat IP në vetë serverin, mjafton t'i përshkruani ato në konfigurim, dhe nëse adresat IP kanë nevojë për disa rregulla të personalizuara të rrugëtimit, kjo përshkruhet drejtpërdrejt në konfigurim, në e njëjta sintaksë siç përshkruhet në paketën VRRP. Nuk do të takoni gjëra të panjohura.
Si duket në praktikë? Çfarë ndodh nëse një nga serverët bie? Sapo masteri të zhduket, rezerva jonë ndalon marrjen e promovimeve dhe bëhet automatikisht master. Pas ca kohësh, ne riparuam masterin, rindizëm, ngritëm Keepalived - mbërrijnë reklamat me një përparësi më të lartë se kopja rezervë, dhe kopja rezervë kthehet automatikisht, heq adresat IP nga vetja, nuk nevojiten veprime manuale.
Kështu, ne kemi siguruar tolerancën e gabimeve të adresës së jashtme IP. Pjesa tjetër është të balanconi disi trafikun nga një adresë IP e jashtme në ruterat e fotografive që tashmë e mbyllin atë. Me protokollet e balancimit, gjithçka është mjaft e qartë. Kjo është ose një lidhje e thjeshtë e rrumbullakët, ose gjëra pak më komplekse, lidhje wrr, lista etj. Kjo në thelb përshkruhet në dokumentacion, nuk ka asgjë të veçantë në lidhje me të. Por metoda e dorëzimit ... Këtu do të ndalemi më në detaje - pse zgjodhëm njërën prej tyre. Këto janë NAT, Direct Routing dhe TUN. Fakti është se ne vendosëm menjëherë kthimin e 100 gigabit trafikut nga faqet. Kjo është nëse e kuptoni, ju duhen karta 10 gigabit, apo jo? 10 karta gigabit në një server - kjo është tashmë përtej, të paktën, konceptit tonë të "pajisjeve standarde". Dhe pastaj u kujtuam se nuk dhurojmë vetëm pak trafik, por dhurojmë foto.
Cila është veçoria? - Një ndryshim i madh midis trafikut hyrës dhe atij dalës. Trafiku në hyrje është shumë i vogël, trafiku dalës është shumë i madh:
Nëse shikoni këto grafikë, mund të shihni se për momentin po i dërgohen drejtorit rreth 200 Mb në sekondë, kjo është dita më tipike. Ne japim 4,500 MB për sekondë, raporti është rreth 1/22. Tashmë është e qartë se për të siguruar plotësisht trafikun dalës në 22 serverë që punojnë, mjafton një që pranon këtë lidhje. Këtu na vjen në ndihmë algoritmi i drejtimit të drejtpërdrejtë, algoritmi i rrugëzimit.
Si duket? Drejtori ynë i fotografive, sipas tabelës së tij, transferon lidhjet me ruterat e fotografive. Por ruterët e fotografive dërgojnë trafikun e kundërt direkt në internet, dërgojnë atë te klienti, ai nuk kthehet mbrapa përmes drejtorit të fotografisë, kështu, me një numër minimal makinerish, ne ofrojmë tolerancë të plotë të gabimeve dhe pompim të të gjithë trafikut. Në konfigurimet, duket kështu: ne specifikojmë algoritmin, në rastin tonë është një rr e thjeshtë, ne ofrojmë metodën e drejtimit të drejtpërdrejtë dhe më pas fillojmë të listojmë të gjithë serverët e vërtetë, sa prej tyre kemi. Që do të përcaktojë këtë trafik. Në rast se kemi një ose dy të tjerë, disa serverë që shfaqen atje, lind një nevojë e tillë - ne thjesht e shtojmë këtë seksion në konfigurim dhe mos u shqetësoni shumë. Nga ana e serverëve të vërtetë, nga ana e një ruteri fotografik, kjo metodë kërkon konfigurimin më minimal, është përshkruar në mënyrë të përsosur në dokumentacion dhe nuk ka kurthe atje.
Ajo që është veçanërisht e këndshme është se një zgjidhje e tillë nuk nënkupton një ndryshim rrënjësor të rrjetit lokal, kjo ishte e rëndësishme për ne, duhej ta zgjidhnim me kosto minimale. Nëse shikoni atëherë do të shohim se si duket. Këtu kemi një server të caktuar virtual, në portin 443, dëgjon, pranon një lidhje, renditen të gjithë serverët që punojnë dhe shihet se lidhja është, plus ose minus, e njëjtë. Nëse shikojmë statistikat në të njëjtin server virtual, ne kemi pako hyrëse, lidhje hyrëse, por absolutisht jo ato dalëse. Lidhjet dalëse shkojnë drejtpërdrejt te klienti. Epo, arritëm të çekuilibrojmë. Tani, çfarë ndodh nëse një nga ruterët tanë të fotografisë dështon? Në fund të fundit, hekuri është hekur. Mund të shkojë në një panik të bërthamës, mund të prishet, furnizimi me energji elektrike mund të digjet. Çdo gjë. Për këtë shërbejnë kontrollet shëndetësore. Ato mund të jenë aq të thjeshta sa të kontrollojmë se si është hapur porti me ne, ose disa më komplekse, deri në disa skripta të shkruar vetë që do të kontrollojnë edhe logjikën e biznesit.
Ne u ndalëm diku në mes: kemi një kërkesë https për një vendndodhje specifike, një skript thirret nëse përgjigjet me një përgjigje të 200-të, ne besojmë se gjithçka është në rregull me këtë server, se ai është i gjallë dhe mund të ndizet mjaft lehtë .
Si duket kjo, përsëri, në praktikë. Serveri i fikur, i lejueshëm për mirëmbajtje - ndezja e BIOS-it, për shembull. Në regjistra, ne kemi menjëherë një afat, shohim rreshtin e parë, pastaj pas tre përpjekjesh shënohet si "i dështuar" dhe thjesht hiqet nga lista.
Një sjellje e dytë është gjithashtu e mundur, kur thjesht VS është vendosur në zero, por në rastin e kthimit të një fotoje, kjo nuk funksionon mirë. Serveri ngrihet, Nginx fillon atje lart, menjëherë kontrollet shëndetësore kuptojnë që lidhja po kalon, se gjithçka është në rregull, dhe serveri shfaqet në listën tonë dhe ngarkesa menjëherë fillon të aplikohet në të automatikisht. Asnjë veprim manual nuk kërkohet nga administratori i detyrës. Natën, serveri u rindez - departamenti i monitorimit nuk na telefonon për këtë gjatë natës. Ata ju njoftuan se çfarë ndodhi, gjithçka është në rregull.
Pra, në një mënyrë mjaft të thjeshtë, me ndihmën e një numri të vogël serverësh, zgjidhëm problemin e tolerancës së gabimeve të jashtme.
Mbetet të thuhet se e gjithë kjo, natyrisht, duhet të monitorohet. Më vete, duhet të theksohet se Keepalivede, si një softuer i shkruar shumë kohë më parë, ka një mori mënyrash për ta monitoruar atë, si duke përdorur kontrolle nëpërmjet DBus, SMTP, SNMP dhe Zabbix standarde. Plus, ai vetë di të shkruajë letra për pothuajse çdo teshtitje, dhe të them të drejtën, në një moment menduam ta fikim, sepse ai shkruan shumë letra për çdo ndërprerës trafiku, përfshirje, për çdo IP-shnik dhe kështu me radhë. Sigurisht, nëse ka shumë serverë, atëherë mund të vërshoni veten me këto letra. Duke përdorur metoda standarde, ne monitorojmë nginx në ruterat e fotografive dhe monitorimi i harduerit nuk është zhdukur. Natyrisht, ne do të këshillonim edhe dy gjëra të tjera: së pari, kontrolle të jashtme shëndetësore dhe aksesueshmëri, sepse edhe nëse gjithçka funksionon, në fakt, është e mundur që përdoruesit të mos marrin foto për shkak të problemeve me ofruesit e jashtëm ose diçka më komplekse. Gjithmonë ia vlen të mbash diku në një rrjet tjetër, në amazon ose diku tjetër, një makinë të veçantë që mund t'i bëjë ping serverët tuaj nga jashtë, dhe gjithashtu ia vlen të përdorni ose zbulimin e anomalive, për ata që janë të mirë në mësimin e ndërlikuar të makinerive, ose të thjeshtë. monitorimi, të paktën për të gjurmuar nëse kërkesat kanë rënë ndjeshëm, apo anasjelltas, janë rritur. Është gjithashtu e dobishme.
Për ta përmbledhur: ne, në fakt, zëvendësuam zgjidhjen e hekurit, e cila në një moment pushoi së na përshtatet, me një sistem mjaft të thjeshtë që bën gjithçka njësoj, domethënë siguron ndërprerjen e trafikut HTTPS dhe rrugëtim të mëtejshëm të zgjuar me shëndetin e nevojshëm. -çeqe. Ne kemi rritur stabilitetin e këtij sistemi, domethënë kemi akoma disponueshmëri të lartë për secilën shtresë, plus kemi marrë bonusin se është mjaft e lehtë të shkallëzojmë të gjitha në secilën shtresë, sepse ky është një pajisje standarde me softuer standard, d.m.th. , duke vepruar kështu, ne e kemi thjeshtuar veten duke diagnostikuar problemet e mundshme.
Me çfarë përfunduam? Ne patëm një problem në festat e janarit 2018. Gjatë gjashtë muajve të parë, ndërsa ne po e vendosnim këtë skemë në funksion, duke e zgjeruar atë në të gjithë trafikun, për të hequr të gjithë trafikun nga LTM, ne u rritëm vetëm në trafik në një qendër të dhënash nga 40 gigabit në 60 gigabit, dhe në të njëjtën kohë. kohë për të gjithë vitin 2018 ishin në gjendje të jepnin pothuajse tre herë më shumë foto në sekondë.
Burimi: www.habr.com