Ang modernong web ay halos hindi maiisip nang walang nilalamang media: halos lahat ng lola ay may isang smartphone, lahat ay nasa mga social network, at ang downtime sa pagpapanatili ay magastos para sa mga kumpanya. Narito ang isang transcript ng kuwento ng kumpanya tungkol sa kung paano niya inayos ang paghahatid ng mga larawan gamit ang isang solusyon sa hardware, anong mga problema sa pagganap ang naranasan niya sa proseso, kung ano ang naging sanhi ng mga ito, at kung paano nalutas ang mga problemang ito gamit ang isang solusyon sa software batay sa Nginx, habang tinitiyak ang pagpapahintulot sa fault sa lahat ng antas (). Nagpapasalamat kami sa mga may-akda ng kuwento ni Oleg Efimova at Alexandra Dymova, na nagbahagi ng kanilang karanasan sa kumperensya .
β Magsimula tayo sa kaunting panimula tungkol sa kung paano tayo nag-iimbak at nag-cache ng mga larawan. Mayroon kaming isang layer kung saan namin iniimbak ang mga ito, at isang layer kung saan namin ini-cache ang mga larawan. Kasabay nito, kung gusto naming makamit ang isang mataas na rate ng trick at bawasan ang pag-load sa storage, mahalaga para sa amin na ang bawat larawan ng isang indibidwal na user ay nasa isang cache server. Kung hindi, kailangan naming mag-install ng maraming beses na mas maraming mga disk dahil mayroon kaming mas maraming mga server. Ang aming trick rate ay humigit-kumulang 99%, ibig sabihin, binabawasan namin ang load sa aming storage ng 100 beses, at para magawa ito, 10 taon na ang nakakaraan, noong lahat ng ito ay binuo, mayroon kaming 50 server. Alinsunod dito, upang maihatid ang mga larawang ito, kailangan talaga namin ng 50 panlabas na domain na pinaglilingkuran ng mga server na ito.
Natural, ang tanong ay agad na lumitaw: kung ang isa sa aming mga server ay bumaba at naging hindi magagamit, anong bahagi ng trapiko ang mawawala sa amin? Tiningnan namin kung ano ang nasa merkado at nagpasya kaming bumili ng isang piraso ng hardware upang malutas nito ang lahat ng aming mga problema. Ang pagpipilian ay nahulog sa solusyon ng kumpanya ng F5-network (na, sa pamamagitan ng paraan, kamakailan ay bumili ng NGINX, Inc): BIG-IP Local Traffic Manager.
Ang ginagawa ng piraso ng hardware (LTM) na ito: ito ay isang bakal na router na gumagawa ng iron redundancy ng mga panlabas na port nito at nagbibigay-daan sa iyong iruta ang trapiko batay sa topology ng network, sa ilang setting, at gumagawa ng mga pagsusuri sa kalusugan. Mahalaga sa amin na ma-program ang piraso ng hardware na ito. Alinsunod dito, maaari naming ilarawan ang lohika kung paano inihatid ang mga larawan ng isang partikular na user mula sa isang partikular na cache. Anong itsura? Mayroong isang piraso ng hardware na tumitingin sa Internet sa isang domain, isang IP, nag-offload ng ssl, nag-parse ng mga kahilingan sa http, pumipili ng numero ng cache mula sa IRule, kung saan pupunta, at hinahayaan ang trapiko na pumunta doon. Kasabay nito, nagsasagawa ito ng mga pagsusuri sa kalusugan, at kung sakaling hindi available ang ilang makina, ginawa namin ito upang ang trapiko ay napunta sa isang backup na server. Mula sa isang punto ng pagsasaayos, siyempre, mayroong ilang mga nuances, ngunit sa pangkalahatan ang lahat ay medyo simple: nagrehistro kami ng isang card, pagsusulatan ng isang tiyak na numero sa aming IP sa network, sinasabi namin na makikinig kami sa mga port 80 at 443, sinasabi namin na kung hindi available ang server, kailangan mong magpadala ng trapiko sa backup, sa kasong ito sa ika-35, at inilalarawan namin ang isang grupo ng lohika kung paano dapat i-disassemble ang arkitektura na ito. Ang tanging problema ay ang wika kung saan na-program ang hardware ay Tcl. Kung sinuman ang nakakaalala nito... ang wikang ito ay mas write-only kaysa sa isang wikang maginhawa para sa programming:
Ano ang nakuha namin? Nakatanggap kami ng isang piraso ng hardware na nagsisiguro ng mataas na kakayahang magamit ng aming imprastraktura, ruta ang lahat ng aming trapiko, nagbibigay ng mga benepisyong pangkalusugan at gumagana lamang. Bukod dito, ito ay gumagana nang mahabang panahon: sa nakalipas na 10 taon ay walang mga reklamo tungkol dito. Sa simula ng 2018, nagpapadala na kami ng humigit-kumulang 80k larawan bawat segundo. Ito ay nasa isang lugar na humigit-kumulang 80 gigabits ng trapiko mula sa aming mga data center.
Gayunpaman ...
Sa simula ng 2018, nakakita kami ng isang pangit na larawan sa mga chart: malinaw na tumaas ang tagal ng pagpapadala ng mga larawan. At hindi na ito nababagay sa amin. Ang problema ay ang pag-uugaling ito ay makikita lamang sa panahon ng kasagsagan ng trapiko - para sa aming kumpanya ito ang gabi mula Linggo hanggang Lunes. Ngunit sa natitirang oras ang sistema ay kumilos gaya ng dati, walang mga palatandaan ng pagkabigo.
Gayunpaman, ang problema ay kailangang lutasin. Natukoy namin ang mga posibleng bottleneck at sinimulan naming alisin ang mga ito. Una sa lahat, siyempre, pinalawak namin ang mga panlabas na uplink, nagsagawa ng kumpletong pag-audit ng mga panloob na uplink, at nakita namin ang lahat ng posibleng mga bottleneck. Ngunit ang lahat ng ito ay hindi nagbigay ng isang malinaw na resulta, ang problema ay hindi nawala.
Ang isa pang posibleng bottleneck ay ang pagganap ng mga cache ng larawan mismo. At napagpasyahan namin na marahil ang problema ay nakasalalay sa kanila. Well, pinalawak namin ang pagganap - pangunahin ang mga network port sa mga cache ng larawan. Ngunit muli walang malinaw na pagpapabuti na nakita. Sa huli, binigyan namin ng pansin ang pagganap ng LTM mismo, at dito nakita namin ang isang malungkot na larawan sa mga graph: ang pag-load sa lahat ng mga CPU ay nagsisimula nang maayos, ngunit pagkatapos ay biglang dumating sa isang talampas. Kasabay nito, humihinto ang LTM sa pagtugon nang sapat sa mga pagsusuri sa kalusugan at mga uplink at nagsisimulang random na i-off ang mga ito, na humahantong sa malubhang pagkasira ng performance.
Ibig sabihin, natukoy na natin ang pinagmulan ng problema, natukoy ang bottleneck. Ito ay nananatiling magpasya kung ano ang aming gagawin.
Ang una, pinaka-halatang bagay na maaari naming gawin ay upang kahit papaano ay gawing moderno ang mismong LTM. Ngunit mayroong ilang mga nuances dito, dahil ang hardware na ito ay medyo kakaiba, hindi ka pupunta sa pinakamalapit na supermarket at bilhin ito. Ito ay isang hiwalay na kontrata, isang hiwalay na kontrata ng lisensya, at ito ay aabutin ng maraming oras. Ang pangalawang opsyon ay simulan ang pag-iisip para sa iyong sarili, makabuo ng iyong sariling solusyon gamit ang iyong sariling mga bahagi, mas mabuti gamit ang isang open access program. Ang natitira na lang ay magpasya kung ano ang eksaktong pipiliin namin para dito at kung gaano karaming oras ang aming gugugol sa paglutas ng problemang ito, dahil ang mga gumagamit ay hindi nakakatanggap ng sapat na mga larawan. Samakatuwid, kailangan nating gawin ang lahat ng ito nang napakabilis, maaaring sabihin ng isa kahapon.
Dahil ang gawain ay parang "gumawa ng isang bagay sa lalong madaling panahon at gamit ang hardware na mayroon kami," ang unang bagay na naisip namin ay alisin lamang ang ilang hindi masyadong makapangyarihang mga makina mula sa harapan, ilagay ang Nginx doon, kung saan alam namin kung paano gumana at subukang ipatupad ang lahat ng parehong lohika na ginagamit ng hardware. Iyon ay, sa katunayan, iniwan namin ang aming hardware, nag-install ng 4 pang server na kailangan naming i-configure, lumikha ng mga panlabas na domain para sa kanila, katulad ng kung paano ito 10 taon na ang nakakaraan... Nawalan kami ng kaunti sa availability kung nahulog ang mga machine na ito, ngunit mas kaunti pa rin, nalutas nila ang problema ng aming mga user nang lokal.
Alinsunod dito, ang lohika ay nananatiling pareho: nag-install kami ng Nginx, maaari itong gumawa ng SSL-offload, kahit papaano ay maaari naming i-program ang routing logic, mga pagsusuri sa kalusugan sa mga config at simpleng duplicate ang logic na mayroon kami noon.
Umupo tayo para magsulat ng mga config. Sa una tila ang lahat ay napaka-simple, ngunit, sa kasamaang-palad, napakahirap na makahanap ng mga manwal para sa bawat gawain. Samakatuwid, hindi namin inirerekumenda ang simpleng pag-googling "kung paano i-configure ang Nginx para sa mga larawan": mas mahusay na sumangguni sa opisyal na dokumentasyon, na magpapakita kung aling mga setting ang dapat hawakan. Ngunit mas mahusay na piliin ang partikular na parameter sa iyong sarili. Kaya, kung gayon ang lahat ay simple: inilalarawan namin ang mga server na mayroon kami, inilalarawan namin ang mga sertipiko... Ngunit ang pinaka-kagiliw-giliw na bagay ay, sa katunayan, ang routing logic mismo.
Sa una, tila sa amin ay naglalarawan lamang ng aming lokasyon, tumutugma sa bilang ng aming cache ng larawan sa loob nito, gamit ang aming mga kamay o isang generator upang ilarawan kung gaano karaming upstream ang kailangan namin, sa bawat upstream ay ipinapahiwatig namin ang server kung saan dapat ang trapiko. pumunta, at isang backup na server - kung ang pangunahing server ay hindi magagamit:
Pero, malamang, kung napakasimple lang ng lahat, uuwi na lang kami at hindi na magsasabi ng kahit ano. Sa kasamaang palad, sa mga default na setting ng Nginx, na, sa pangkalahatan, ay ginawa sa loob ng maraming taon ng pag-unlad at hindi ganap na angkop para sa kasong ito... ganito ang hitsura ng config: kung ang ilang upstream server ay may error sa kahilingan o timeout, palaging Nginx inilipat ang trapiko sa susunod. Bukod dito, pagkatapos ng unang pagkabigo, sa loob ng 10 segundo ang server ay mai-off din, kapwa sa pagkakamali at sa timeout - hindi ito maaaring i-configure sa anumang paraan. Iyon ay, kung aalisin o i-reset natin ang opsyon sa pag-timeout sa upstream na direktiba, kung gayon, bagama't hindi ipoproseso ng Nginx ang kahilingang ito at tutugon nang may ilang hindi masyadong magandang error, magsasara ang server.
Upang maiwasan ito, ginawa namin ang dalawang bagay:
a) ipinagbawal nila ang Nginx na gawin ito nang manu-mano - at sa kasamaang-palad, ang tanging paraan upang gawin ito ay ang simpleng itakda ang mga setting ng max fails.
b) naalala namin na sa ibang mga proyekto ay gumagamit kami ng isang module na nagbibigay-daan sa amin na magsagawa ng background na mga pagsusuri sa kalusugan - ayon dito, medyo madalas kaming gumawa ng mga pagsusuri sa kalusugan upang ang downtime sa kaganapan ng isang aksidente ay magiging minimal.
Sa kasamaang palad, hindi rin ito lahat, dahil literal na ang unang dalawang linggo ng pagpapatakbo ng scheme na ito ay nagpakita na ang TCP health-check ay isa ring hindi mapagkakatiwalaang bagay: sa upstream server ay maaaring hindi ito Nginx, o Nginx sa D-state, at sa sa kasong ito, tatanggapin ng kernel ang koneksyon, papasa ang pagsusuri sa kalusugan, ngunit hindi gagana. Samakatuwid, agad naming pinalitan ito ng health-check http, gumawa ng isang tiyak, kung saan, kung magbabalik ito ng 200, pagkatapos ay gumagana ang lahat sa script na ito. Maaari kang gumawa ng karagdagang lohika - halimbawa, sa kaso ng mga caching server, suriin kung ang file system ay naka-mount nang tama:
At ito ay angkop sa amin, maliban na sa sandaling ito ay ganap na inulit ng circuit kung ano ang ginawa ng hardware. Ngunit gusto naming gumawa ng mas mahusay. Noong nakaraan, mayroon kaming isang backup na server, at ito ay malamang na hindi napakahusay, dahil kung mayroon kang isang daang mga server, kung gayon kapag maraming nabigo nang sabay-sabay, ang isang backup na server ay malamang na hindi makayanan ang pagkarga. Samakatuwid, nagpasya kaming ipamahagi ang reserbasyon sa lahat ng mga server: gumawa lang kami ng isa pang hiwalay na upstream, isinulat ang lahat ng mga server doon na may ilang partikular na mga parameter alinsunod sa load na maaari nilang ihatid, idinagdag ang parehong mga pagsusuri sa kalusugan na mayroon kami noon :
Dahil imposibleng pumunta sa isa pang upstream sa loob ng isang upstream, kinakailangan upang matiyak na kung ang pangunahing upstream, kung saan naitala lang namin ang tama, kinakailangang cache ng larawan, ay hindi magagamit, dumaan lang kami sa error_page upang fallback, mula sa kung saan kami nagpunta sa backup upstream:
At sa literal na pagdaragdag ng apat na server, ito ang nakuha namin: pinalitan namin ang bahagi ng load - inalis namin ito mula sa LTM sa mga server na ito, ipinatupad ang parehong lohika doon, gamit ang karaniwang hardware at software, at agad na natanggap ang bonus na magagawa ng mga server na ito. i-scale, dahil maaari silang ibigay nang simple hangga't kinakailangan. Well, ang negatibo lang ay nawalan kami ng mataas na kakayahang magamit para sa mga external na user. Ngunit sa sandaling iyon kailangan nating isakripisyo ito, dahil kailangan itong malutas kaagad ang problema. Kaya, inalis namin ang bahagi ng load, ito ay tungkol sa 40% sa oras na iyon, LTM pakiramdam mabuti, at literal dalawang linggo pagkatapos ng problema ay nagsimula, nagsimula kaming magpadala ng hindi 45k kahilingan bawat segundo, ngunit 55k. Sa katunayan, lumaki kami ng 20% ββ- malinaw na ito ang trapiko na hindi namin ibinigay sa gumagamit. At pagkatapos nito ay nagsimula silang mag-isip tungkol sa kung paano malutas ang natitirang problema - upang matiyak ang mataas na panlabas na accessibility.
Nagkaroon kami ng ilang pause, kung saan tinalakay namin kung anong solusyon ang gagamitin namin para dito. Mayroong mga panukala upang matiyak ang pagiging maaasahan gamit ang DNS, sa tulong ng ilang mga script na isinulat sa bahay, mga dynamic na routing protocol... maraming mga pagpipilian, ngunit naging malinaw na para sa tunay na maaasahang paghahatid ng mga larawan, kailangan mong ipakilala ang isa pang layer na susubaybayan ito. Tinawag namin ang mga makinang ito na mga direktor ng larawan. Ang software na aming pinagkatiwalaan ay Keepalived:
Upang magsimula, ano ang binubuo ng Keepalived? Ang una ay ang VRRP protocol, na malawak na kilala sa mga networker, na matatagpuan sa network equipment na nagbibigay ng fault tolerance sa panlabas na IP address kung saan kumokonekta ang mga kliyente. Ang ikalawang bahagi ay IPVS, IP virtual server, para sa pagbabalanse sa pagitan ng mga router ng larawan at pagtiyak ng fault tolerance sa antas na ito. At pangatlo - mga pagsusuri sa kalusugan.
Magsimula tayo sa unang bahagi: VRRP - ano ang hitsura nito? Mayroong isang tiyak na virtual IP, na mayroong entry sa dns badoocdn.com, kung saan kumokonekta ang mga kliyente. Sa ilang mga punto sa oras, mayroon kaming isang IP address sa isang server. Ang mga keepalived na packet ay tumatakbo sa pagitan ng mga server gamit ang VRRP protocol, at kung mawala ang master sa radar - ang server ay nag-reboot o iba pa, pagkatapos ay awtomatikong kukunin ng backup server ang IP address na ito - walang kinakailangang mga manu-manong aksyon. Ang pagkakaiba sa pagitan ng master at backup ay pangunahing priyoridad: kung mas mataas ito, mas malaki ang pagkakataon na ang makina ay maging isang master. Ang isang napakalaking bentahe ay hindi mo kailangang i-configure ang mga IP address sa server mismo, sapat na upang ilarawan ang mga ito sa config, at kung ang mga IP address ay nangangailangan ng ilang pasadyang mga panuntunan sa pagruruta, ito ay direktang inilarawan sa config, gamit ang parehong syntax tulad ng inilarawan sa VRRP package. Hindi ka makakatagpo ng anumang hindi pamilyar na mga bagay.
Ano ang hitsura nito sa pagsasanay? Ano ang mangyayari kung nabigo ang isa sa mga server? Sa sandaling mawala ang master, hihinto ang aming backup sa pagtanggap ng mga advertisement at awtomatikong magiging master. Pagkaraan ng ilang oras, inayos namin ang master, na-reboot, itinaas ang Keepalived - dumarating ang mga ad na may mas mataas na priyoridad kaysa sa backup, at awtomatikong bumabalik ang backup, nag-aalis ng mga IP address, walang mga manu-manong aksyon na kailangang gawin.
Kaya, natiyak namin ang fault tolerance ng panlabas na IP address. Ang susunod na bahagi ay upang kahit papaano ay balansehin ang trapiko mula sa panlabas na IP address hanggang sa mga router ng larawan na tinatapos na ito. Ang lahat ay medyo malinaw sa pagbabalanse ng mga protocol. Ito ay alinman sa isang simpleng round-robin, o bahagyang mas kumplikadong mga bagay, wrr, listahan ng koneksyon at iba pa. Ito ay karaniwang inilarawan sa dokumentasyon, walang espesyal. Ngunit ang paraan ng paghahatid... Dito ay titingnan natin nang mas malapit kung bakit namin pinili ang isa sa kanila. Ito ay ang NAT, Direct Routing at TUN. Ang katotohanan ay agad naming binalak na maghatid ng 100 gigabits ng trapiko mula sa mga site. Kung tatantyahin mo, kailangan mo ng 10 gigabit card, di ba? Ang 10 gigabit card sa isang server ay lampas na sa saklaw ng, hindi bababa sa, ang aming konsepto ng "karaniwang kagamitan". At pagkatapos ay naalala namin na hindi lang kami namamahagi ng ilang trapiko, nagbibigay kami ng mga larawan.
Ano ang espesyal? β Napakalaking pagkakaiba sa pagitan ng papasok at papalabas na trapiko. Napakaliit ng papasok na trapiko, napakalaki ng papalabas na trapiko:
Kung titingnan mo ang mga graph na ito, makikita mo na sa sandaling ang direktor ay tumatanggap ng humigit-kumulang 200 MB bawat segundo, ito ay isang napaka-ordinaryong araw. Nagbabalik kami ng 4,500 MB bawat segundo, ang aming ratio ay humigit-kumulang 1/22. Malinaw na na para ganap na makapagbigay ng papalabas na trapiko sa 22 server ng manggagawa, kailangan lang namin ng isa na tumatanggap ng koneksyong ito. Dito nakakatulong sa amin ang direktang algorithm sa pagruruta.
Anong itsura? Ang aming direktor ng larawan, ayon sa kanyang talahanayan, ay nagpapadala ng mga koneksyon sa mga router ng larawan. Ngunit ang mga router ng larawan ay direktang nagpapadala ng trapiko sa pagbabalik sa Internet, ipinadala ito sa kliyente, hindi ito bumabalik sa direktor ng larawan, kaya, na may pinakamababang bilang ng mga makina, tinitiyak namin ang kumpletong pagpapahintulot sa kasalanan at pagbomba ng lahat ng trapiko. Sa mga config, ganito ang hitsura: tinukoy namin ang algorithm, sa aming kaso ito ay isang simpleng rr, ibigay ang direktang paraan ng pagruruta at pagkatapos ay simulan upang ilista ang lahat ng mga tunay na server, kung ilan sa kanila ang mayroon kami. Alin ang magpapasiya sa trapikong ito. Kung mayroon kaming isa o dalawa pang mga server doon, o ilang mga server, ang ganoong pangangailangan ay lumitaw - idinagdag lang namin ang seksyong ito sa config at huwag mag-alala nang labis. Mula sa gilid ng mga tunay na server, mula sa gilid ng router ng larawan, ang pamamaraang ito ay nangangailangan ng pinakamaliit na pagsasaayos, perpektong inilarawan ito sa dokumentasyon, at walang mga pitfalls doon.
Ang mas maganda ay ang ganitong solusyon ay hindi nagpapahiwatig ng isang radikal na muling pagdidisenyo ng lokal na network; ito ay mahalaga para sa amin; kailangan naming lutasin ito nang may kaunting gastos. Kung titingnan mo , pagkatapos ay makikita natin kung ano ang hitsura nito. Narito mayroon kaming isang tiyak na virtual server, sa port 443, nakikinig, tumatanggap ng koneksyon, lahat ng gumaganang server ay nakalista, at makikita mo na ang koneksyon ay, give or take, pareho. Kung titingnan natin ang mga istatistika sa parehong virtual server, mayroon tayong mga papasok na packet, mga papasok na koneksyon, ngunit talagang walang mga papalabas. Ang mga papalabas na koneksyon ay direktang napupunta sa kliyente. Okay, nagawa naming i-unbalance ito. Ngayon, ano ang mangyayari kung nabigo ang isa sa aming mga router ng larawan? Pagkatapos ng lahat, ang bakal ay bakal. Ito ay maaaring mapunta sa kernel panic, maaari itong masira, ang power supply ay maaaring masunog. Anumang bagay. Ito ang dahilan kung bakit kailangan ang mga pagsusuri sa kalusugan. Maaari silang maging kasing simple ng pagsuri kung paano bukas ang port, o isang bagay na mas kumplikado, hanggang sa ilang mga script na isinulat sa bahay na susuriin pa ang lohika ng negosyo.
Huminto kami sa isang lugar sa gitna: mayroon kaming https na kahilingan sa isang partikular na lokasyon, tinawag ang script, kung tumugon ito nang may ika-200 na tugon, naniniwala kami na maayos ang lahat sa server na ito, na ito ay buhay at maaaring i-on nang lubos madali.
Paano ito, muli, hitsura sa pagsasanay? I-off natin ang server para sa pagpapanatili - pag-flash ng BIOS, halimbawa. Sa mga log ay agad kaming may timeout, nakikita namin ang unang linya, pagkatapos pagkatapos ng tatlong pagtatangka ay minarkahan ito bilang "bigo", at ito ay tinanggal lamang mula sa listahan.
Posible rin ang pangalawang opsyon sa pag-uugali, kapag nakatakda lang ang VS sa zero, ngunit kung ibinalik ang larawan, hindi ito gagana nang maayos. Ang server ay lalabas, ang Nginx ay magsisimula doon, ang pagsusuri sa kalusugan ay agad na nauunawaan na ang koneksyon ay gumagana, na ang lahat ay maayos, at ang server ay lilitaw sa aming listahan, at ang pag-load ay agad na nagsisimulang mailapat dito. Walang kinakailangang mga manu-manong aksyon mula sa tagapangasiwa ng tungkulin. Nag-reboot ang server sa gabi - hindi kami tinatawagan ng monitoring department tungkol dito sa gabi. Ipinapaalam nila sa iyo na nangyari ito, maayos ang lahat.
Kaya, sa isang medyo simpleng paraan, sa tulong ng isang maliit na bilang ng mga server, nalutas namin ang problema ng panlabas na pagpapahintulot sa kasalanan.
Ang nananatiling sasabihin ay ang lahat ng ito, siyempre, ay kailangang subaybayan. Hiwalay, dapat tandaan na ang Keepalivede, bilang software na isinulat noong matagal na panahon, ay may maraming paraan upang masubaybayan ito, parehong gumagamit ng mga tseke sa pamamagitan ng DBus, SMTP, SNMP, at karaniwang Zabbix. Dagdag pa, alam niya mismo kung paano magsulat ng mga liham para sa halos bawat pagbahing, at sa totoo lang, sa isang punto ay naisipan pa naming i-off ito, dahil nagsusulat siya ng maraming mga titik para sa anumang paglipat ng trapiko, paglipat, para sa bawat koneksyon sa IP, at iba pa . Siyempre, kung mayroong maraming mga server, maaari mong puspusan ang iyong sarili sa mga liham na ito. Sinusubaybayan namin ang nginx sa mga router ng larawan gamit ang mga karaniwang pamamaraan, at hindi nawala ang pagsubaybay sa hardware. Siyempre, magpapayo kami ng dalawa pang bagay: una, ang mga panlabas na pagsusuri sa kalusugan at pagkakaroon, dahil kahit na gumagana ang lahat, sa katunayan, marahil ang mga gumagamit ay hindi nakakatanggap ng mga larawan dahil sa mga problema sa mga panlabas na provider o isang bagay na mas kumplikado. Palaging sulit na magtago sa isang lugar sa ibang network, sa Amazon o sa ibang lugar, ng isang hiwalay na makina na maaaring mag-ping sa iyong mga server mula sa labas, at sulit din ang paggamit ng alinman sa pagtuklas ng anomalya, para sa mga taong marunong gumawa ng nakakalito na machine learning, o simpleng pagsubaybay. , hindi bababa sa upang masubaybayan kung ang mga kahilingan ay bumaba nang husto, o, sa kabaligtaran, tumaas. Maaari rin itong maging kapaki-pakinabang.
Ibuod natin: sa katunayan, pinalitan namin ang solusyon na nakasuot ng bakal, na sa isang punto ay tumigil na umangkop sa amin, na may medyo simpleng sistema na ginagawa ang lahat ng pareho, iyon ay, nagbibigay ito ng pagwawakas ng trapiko ng HTTPS at higit pang matalinong pagruruta sa mga kinakailangang pagsusuri sa kalusugan. Nadagdagan namin ang katatagan ng system na ito, iyon ay, mayroon pa rin kaming mataas na kakayahang magamit para sa bawat layer, at mayroon kaming bonus na medyo madaling sukatin ang lahat ng ito sa bawat layer, dahil ito ay karaniwang hardware na may karaniwang software, iyon ay , pinasimple namin ang pag-diagnose ng mga posibleng problema.
Ano ang natapos namin? Nagkaroon kami ng problema noong mga pista opisyal ng Enero ng 2018. Sa unang anim na buwan habang ipinapatakbo namin ang scheme na ito, pinalawak namin ito sa lahat ng trapiko upang alisin ang lahat ng trapiko mula sa LTM, lumaki lamang kami sa trapiko sa isang data center mula 40 gigabits hanggang 60 gigabits, at kasabay nito para sa ang buong taong 2018 ay nakapagpadala ng halos tatlong beses na higit pang mga larawan bawat segundo.
Pinagmulan: www.habr.com