La moderna retejo estas preskaŭ nepensebla sen amaskomunikila enhavo: preskaŭ ĉiu avino havas inteligentan telefonon, ĉiuj estas en sociaj retoj, kaj malfunkcio en prizorgado estas multekosta por kompanioj. Jen transskribo de la rakonto de la kompanio pri kiel ŝi organizis la liveron de fotoj uzante aparatan solvon, kiajn rendimentajn problemojn ŝi renkontis en la procezo, kio kaŭzis ilin, kaj kiel ĉi tiuj problemoj estis solvitaj uzante programaran solvon bazitan sur Nginx, certigante misfunkciadon je ĉiuj niveloj (). Ni dankas la aŭtorojn de la rakonto de Oleg Efimova kaj Alexandra Dymova, kiuj dividis sian sperton ĉe la konferenco .
— Ni komencu per eta enkonduko pri kiel ni konservas kaj konservas fotojn. Ni havas tavolon, kie ni stokas ilin, kaj tavolon, kie ni konservas la fotojn. Samtempe, se ni volas atingi altan lertrapidecon kaj redukti la ŝarĝon de stokado, gravas por ni, ke ĉiu foto de individua uzanto estas sur unu kaŝmemorservilo. Alie, ni devus instali tiom da fojoj pli da diskoj kiom ni havas pli da serviloj. Nia lertaĵo estas ĉirkaŭ 99%, tio estas, ni reduktas la ŝarĝon de nia stokado je 100 fojojn, kaj por fari tion, antaŭ 10 jaroj, kiam ĉio ĉi estis konstruita, ni havis 50 servilojn. Sekve, por servi ĉi tiujn fotojn, ni esence bezonis 50 eksterajn domajnojn, kiujn ĉi tiuj serviloj servas.
Kompreneble tuj aperis la demando: se unu el niaj serviloj malfunkcias kaj fariĝas neatingebla, kian parton de la trafiko ni perdas? Ni rigardis kio estas sur la merkato kaj decidis aĉeti pecon da aparataro por ke ĝi solvu ĉiujn niajn problemojn. La elekto falis sur la solvo de la kompanio F5-reto (kiu, cetere, lastatempe aĉetis NGINX, Inc): BIG-IP Loka Trafika Administranto.
Kion ĉi tiu aparataro (LTM) faras: ĝi estas fera enkursigilo, kiu faras feran redundon de siaj eksteraj havenoj kaj permesas vin direkti trafikon laŭ la reto-topologio, laŭ iuj agordoj, kaj faras sankontrolojn. Gravis por ni, ke ĉi tiu aparataro povus esti programita. Sekve, ni povus priskribi la logikon de kiel fotoj de specifa uzanto estis servataj de specifa kaŝmemoro. Kiel ĝi aspektas? Estas aparataro, kiu rigardas la Interreton sur unu domajno, unu IP, faras ssl-elŝuton, analizas http-petojn, elektas kaŝmemornumeron de IRule, kien iri, kaj lasas trafikon iri tien. Samtempe ĝi faras sankontrolojn, kaj se iu maŝino ne disponeblas, tiam ni faris ĝin tiel, ke la trafiko iris al unu rezerva servilo. De agorda vidpunkto, estas kompreneble iuj nuancoj, sed ĝenerale ĉio estas sufiĉe simpla: ni registras karton, korespondado de certa nombro al nia IP en la reto, ni diras, ke ni aŭskultos en havenoj 80. kaj 443, ni diras, ke se la servilo ne disponeblas, tiam vi devas sendi trafikon al la rezerva, ĉi-kaze la 35-a, kaj ni priskribas amason da logiko pri kiel ĉi tiu arkitekturo estu malmuntita. La nura problemo estis ke la lingvo en kiu la aparataro estis programita estis Tcl. Se iu ajn memoras tion ĉi... ĉi tiu lingvo estas pli nur skribebla ol lingvo konvena por programado:
Kion ni ricevis? Ni ricevis aparataron, kiu certigas altan haveblecon de nia infrastrukturo, direktas nian tutan trafikon, provizas sanajn avantaĝojn kaj nur funkcias. Krome, ĝi funkcias sufiĉe longe: dum la lastaj 10 jaroj ne estis plendoj pri ĝi. Komence de 2018, ni jam sendis ĉirkaŭ 80k fotojn por sekundo. Ĉi tio estas ie ĉirkaŭ 80 gigabitoj da trafiko de niaj ambaŭ datumcentroj.
Tamen…
Komence de 2018, ni vidis malbelan bildon sur la furorlisto: la tempo necesa por sendi fotojn klare pliiĝis. Kaj ĝi ĉesis konveni al ni. La problemo estas, ke ĉi tiu konduto estis videbla nur dum la pinto de trafiko - por nia kompanio ĉi tiu estas la nokto de dimanĉo ĝis lundo. Sed la resto de la tempo la sistemo kondutis kiel kutime, neniu signo de fiasko.
Tamen, la problemo devis esti solvita. Ni identigis eblajn proplempunktojn kaj komencis forigi ilin. Unue, kompreneble, ni vastigis eksterajn suprenligojn, faris kompletan revizion de internaj suprenligiloj, kaj trovis ĉiujn eblajn botelojn. Sed ĉio ĉi ne donis evidentan rezulton, la problemo ne malaperis.
Alia ebla proplemkolo estis la agado de la fotokaŝmemoroj mem. Kaj ni decidis, ke eble la problemo apartenas al ili. Nu, ni pligrandigis la agadon - ĉefe retajn havenojn sur fotaj kaŝmemoroj. Sed denove neniu evidenta plibonigo estis vidita. Al la fino, ni tre atentis la agadon de la LTM mem, kaj ĉi tie ni vidis malĝojan bildon sur la grafikaĵoj: la ŝarĝo sur ĉiuj CPUoj komencas glate, sed tiam subite venas al altebenaĵo. Samtempe, LTM ĉesas respondi adekvate al sankontroloj kaj suprenligiloj kaj komencas hazarde malŝalti ilin, kio kondukas al serioza rendimento-degradado.
Tio estas, ni identigis la fonton de la problemo, identigis la botelon. Restas decidi, kion ni faros.
La unua, plej evidenta afero, kiun ni povus fari, estas iel modernigi la LTM mem. Sed estas iuj nuancoj ĉi tie, ĉar ĉi tiu aparataro estas sufiĉe unika, vi ne iros al la plej proksima superbazaro kaj aĉetos ĝin. Ĉi tio estas aparta kontrakto, aparta licenca kontrakto, kaj ĝi prenos multe da tempo. La dua opcio estas komenci pensi mem, elpensi vian propran solvon uzante viajn proprajn komponantojn, prefere uzante programon de malferma aliro. Restas nur decidi, kion ĝuste ni elektos por tio kaj kiom da tempo ni elspezos por solvi ĉi tiun problemon, ĉar uzantoj ne ricevis sufiĉe da fotoj. Tial ni devas fari ĉion ĉi tre, tre rapide, oni povus diri hieraŭ.
Ĉar la tasko sonis kiel "fari ion kiel eble plej rapide kaj uzante la aparataron, kiun ni havas", la unua afero, kiun ni pensis, estis simple forigi kelkajn ne tre potencajn maŝinojn de la fronto, meti Nginx tie, per kiu ni Ni scias kiel fari. laboru kaj provu efektivigi la saman logikon, kiun kutimis fari aparataro. Tio estas, fakte, ni forlasis nian aparataron, instalis 4 pliajn servilojn, kiujn ni devis agordi, kreis eksterajn domajnojn por ili, simile kiel antaŭ 10 jaroj... Ni iom perdis en havebleco se ĉi tiuj maŝinoj falis, sed ankoraŭ malpli, ili solvis la problemon de niaj uzantoj loke.
Sekve, la logiko restas la sama: ni instalas Nginx, ĝi povas fari SSL-malŝarĝon, ni povas iel programi la enrutigan logikon, sankontrolojn en la agordoj kaj simple duobligi la logikon, kiun ni havis antaŭe.
Ni sidiĝu por skribi agordojn. Komence ŝajnis, ke ĉio estis tre simpla, sed, bedaŭrinde, estas tre malfacile trovi manlibrojn por ĉiu tasko. Tial ni ne rekomendas simple gugli "kiel agordi Nginx por fotoj": estas pli bone raporti al la oficiala dokumentaro, kiu montros, kiujn agordojn oni devas tuŝi. Sed estas pli bone elekti la specifan parametron mem. Nu, do ĉio estas simpla: ni priskribas la servilojn, kiujn ni havas, ni priskribas la atestojn... Sed la plej interesa afero estas, fakte, la enrutiga logiko mem.
Komence ŝajnis al ni, ke ni simple priskribas nian lokon, kongruas kun la nombro de nia fotkaŝmemoro en ĝi, uzante niajn manojn aŭ generatoron por priskribi kiom da kontraŭfluoj ni bezonas, en ĉiu kontraŭflue ni indikas la servilon al kiu la trafiko devus. iru, kaj rezerva servilo - se la ĉefa servilo ne disponeblas:
Sed, verŝajne, se ĉio estus tiel simpla, ni simple irus hejmen kaj nenion dirus. Bedaŭrinde, kun la defaŭltaj agordoj de Nginx, kiuj, ĝenerale, estis faritaj dum multaj jaroj da evoluo kaj ne tute taŭgas por ĉi tiu kazo... la agordo aspektas jene: se iu kontraŭflua servilo havas petan eraron aŭ maltempon, Nginx ĉiam ŝanĝas trafikon al la sekva. Krome, post la unua malsukceso, ene de 10 sekundoj la servilo ankaŭ estos malŝaltita, kaj erare kaj pro tempodaŭro - ĉi tio eĉ ne povas esti agordita iel ajn. Tio estas, se ni forigas aŭ restarigas la opcion de tempodaŭro en la kontraŭflua direktivo, tiam, kvankam Nginx ne prilaboros ĉi tiun peton kaj respondos per iu ne tre bona eraro, la servilo malŝaltos.
Por eviti ĉi tion, ni faris du aferojn:
a) ili malpermesis al Nginx fari tion permane - kaj bedaŭrinde, la sola maniero fari tion estas simple agordi la agordojn de maksimumaj malsukcesoj.
b) ni memoris, ke en aliaj projektoj ni uzas modulon, kiu ebligas al ni fari fonajn sankontrolojn - sekve, ni faris sufiĉe oftajn sankontrolojn, por ke malfunkcio en okazo de akcidento estu minimuma.
Bedaŭrinde, ankaŭ ĉi tio ne estas ĉio, ĉar laŭvorte la unuaj du semajnoj de funkciado de ĉi tiu skemo montris, ke TCP-sankontrolo ankaŭ estas nefidinda afero: sur la kontraŭflua servilo ĝi eble ne estas Nginx, aŭ Nginx en D-stato, kaj en ĉi tiu kazo la kerno akceptos la konekton, sankontrolo pasos, sed ne funkcios. Tial ni tuj anstataŭigis ĉi tion per sankontrolo http, faris specifan, kiu, se ĝi redonas 200, tiam ĉio funkcias en ĉi tiu skripto. Vi povas fari plian logikon - ekzemple, en la kazo de kaŝmemorserviloj, kontrolu, ke la dosiersistemo estas muntita ĝuste:
Kaj ĉi tio konvenus al ni, krom ke nuntempe la cirkvito tute ripetis tion, kion faris la aparataro. Sed ni volis fari pli bone. Antaŭe, ni havis unu rezervan servilon, kaj ĉi tio verŝajne ne estas tre bona, ĉar se vi havas cent servilojn, tiam kiam pluraj malsukcesas samtempe, unu rezerva servilo verŝajne ne elportos la ŝarĝon. Tial ni decidis distribui la rezervon tra ĉiuj serviloj: ni simple faris alian apartan kontraŭflue, skribis ĉiujn servilojn tie kun certaj parametroj konforme al la ŝarĝo, kiun ili povas servi, aldonis la samajn sankontrolojn, kiujn ni havis antaŭe:
Ĉar estas neeble iri al alia kontraŭflue ene de unu kontraŭflue, estis necese certigi, ke se la ĉefa kontraŭfluo, en kiu ni simple registris la ĝustan, necesan fotkaŝmemoron, estis nedisponebla, ni simple trapasis la erar_paĝon al falo, de kie ni iris al la sekurkopio kontraŭflue:
Kaj laŭvorte aldonante kvar servilojn, jen kion ni ricevis: ni anstataŭigis parton de la ŝarĝo - ni forigis ĝin de LTM al ĉi tiuj serviloj, efektivigis la saman logikon tie, uzante norman aparataron kaj programaron, kaj tuj ricevis la gratifikon, kiun ĉi tiuj serviloj povas. estu skalitaj, ĉar ili povas esti simple provizi tiom multe kiom necesas. Nu, la sola negativa estas, ke ni perdis altan haveblecon por eksteraj uzantoj. Sed en tiu momento ni devis oferi tion, ĉar necesis tuj solvi la problemon. Do, ni forigis parton de la ŝarĝo, ĝi estis proksimume 40% tiutempe, LTM sentis bone, kaj laŭvorte du semajnojn post kiam la problemo komenciĝis, ni komencis sendi ne 45k petojn por sekundo, sed 55k. Fakte, ni kreskis je 20% - ĉi tio klare estas la trafiko, kiun ni ne donis al la uzanto. Kaj post tio ili komencis pensi pri kiel solvi la restantan problemon - por certigi altan eksteran alireblecon.
Ni havis iom da paŭzo, dum kiu ni diskutis, kian solvon ni uzos por tio. Estis proponoj por certigi fidindecon uzante DNS, uzante kelkajn hejmskribitajn skriptojn, dinamikajn enrutigajn protokolojn... estis multaj ebloj, sed jam evidentiĝis, ke por vere fidinda livero de fotoj, vi devas enkonduki alian tavolon, kiu kontrolos tion. . Ni nomis ĉi tiujn maŝinojn fotodirektoroj. La programaro, je kiu ni fidis, estis Keepalived:
Por komenci, el kio konsistas Keepalived? La unua estas la VRRP-protokolo, vaste konata al retumantoj, situanta sur retaj ekipaĵoj, kiu disponigas misfunkciadon al la ekstera IP-adreso al kiu klientoj konektas. La dua parto estas IPVS, IP virtuala servilo, por ekvilibrigi inter foto-enkursigiloj kaj certigi misfunkciadon ĉe ĉi tiu nivelo. Kaj trie - sankontroloj.
Ni komencu per la unua parto: VRRP - kiel ĝi aspektas? Estas certa virtuala IP, kiu havas eniron en la dns badoocdn.com, kie klientoj konektas. En iu momento, ni havas IP-adreson sur unu servilo. Keepalived-pakaĵoj funkcias inter la serviloj uzante la VRRP-protokolon, kaj se la majstro malaperas de la radaro - la servilo rekomencis aŭ io alia, tiam la rezerva servilo aŭtomate prenas ĉi tiun IP-adreson - ne necesas manaj agoj. La diferenco inter majstro kaj sekurkopio estas ĉefe prioritata: ju pli alta ĝi estas, des pli granda la ŝanco ke la maŝino fariĝos majstro. Tre granda avantaĝo estas, ke vi ne bezonas agordi IP-adresojn sur la servilo mem, sufiĉas priskribi ilin en la agordo, kaj se la IP-adresoj bezonas iujn kutimajn enrutigajn regulojn, ĉi tio estas priskribita rekte en la agordo, uzante la sama sintakso kiel priskribita en la VRRP-pakaĵo. Vi ne renkontos nekonatajn aferojn.
Kiel ĉi tio aspektas en la praktiko? Kio okazas se unu el la serviloj malsukcesas? Tuj kiam la majstro malaperas, nia sekurkopio ĉesas ricevi reklamojn kaj aŭtomate fariĝas majstro. Post iom da tempo, ni riparis la majstron, rekomencis, levis Keepalived - reklamoj alvenas kun pli alta prioritato ol la sekurkopio, kaj la sekurkopio aŭtomate revenas, forigas IP-adresojn, ne necesas fari manajn agojn.
Tiel, ni certigis la misfunkciadon de la ekstera IP-adreso. La sekva parto estas iel ekvilibrigi la trafikon de la ekstera IP-adreso al la fotaj enkursigiloj, kiuj jam ĉesigas ĝin. Ĉio estas sufiĉe klara kun la ekvilibraj protokoloj. Ĉi tio estas aŭ simpla cirkla-subskribolista, aŭ iomete pli kompleksaj aferoj, wrr, listkonekto ktp. Ĉi tio estas esence priskribita en la dokumentado, estas nenio speciala. Sed la livera metodo... Ĉi tie ni rigardos pli detale kial ni elektis unu el ili. Ĉi tiuj estas NAT, Direct Routing kaj TUN. La fakto estas, ke ni tuj planis liveri 100 gigabitojn da trafiko de la retejoj. Se vi taksas, vi bezonas 10 gigabit-kartojn, ĉu ne? 10 gigabit-kartoj en unu servilo jam superas la amplekson de, almenaŭ, nia koncepto de "norma ekipaĵo". Kaj tiam ni memoris, ke ni ne nur fordonas iom da trafiko, ni fordonas fotojn.
Kio estas speciala? — Grandega diferenco inter envenanta kaj elira trafiko. Envenanta trafiko estas tre malgranda, elira trafiko estas tre granda:
Se vi rigardas ĉi tiujn grafikaĵojn, vi povas vidi, ke nuntempe la direktoro ricevas ĉirkaŭ 200 MB sekundo, tio estas tre ordinara tago. Ni redonas 4,500 MB sekundo, nia proporcio estas proksimume 1/22. Jam estas klare, ke por plene provizi elirantan trafikon al 22 laboristaj serviloj, ni bezonas nur unu kiu akceptas ĉi tiun konekton. Jen kie la rekta vojigo-algoritmo venas al nia helpo.
Kiel ĝi aspektas? Nia fotodirektoro, laŭ sia tabelo, transdonas konektojn al fotaj enkursigiloj. Sed fotaj enkursigiloj sendas revenan trafikon rekte al la Interreto, sendas ĝin al la kliento, ĝi ne revenas tra la fotodirektoro, tiel, kun minimuma nombro da maŝinoj, ni certigas kompletan misfunkciadon kaj pumpadon de la tuta trafiko. En la agordoj ĝi aspektas jene: ni specifas la algoritmon, en nia kazo ĝi estas simpla rr, provizas la rektan enrutigan metodon kaj poste komencas listigi ĉiujn verajn servilojn, kiom da ili ni havas. Kiu determinos ĉi tiun trafikon. Se ni havas unu aŭ du pliajn servilojn tie, aŭ plurajn servilojn, tia bezono aperas - ni simple aldonas ĉi tiun sekcion al la agordo kaj ne tro zorgu. De la flanko de realaj serviloj, de la flanko de la foto-enkursigilo, ĉi tiu metodo postulas la plej minimuman agordon, ĝi estas perfekte priskribita en la dokumentado, kaj tie ne estas faŭltoj.
Kio estas precipe agrable estas, ke tia solvo ne implicas radikalan restrukturadon de la loka reto; tio estis grava por ni; ni devis solvi ĉi tion per minimumaj kostoj. Se vi rigardas , tiam ni vidos kiel ĝi aspektas. Ĉi tie ni havas certan virtualan servilon, sur la haveno 443, aŭskultas, akceptas la konekton, ĉiuj laborantaj serviloj estas listigitaj, kaj vi povas vidi, ke la konekto estas, donu aŭ prenas, la sama. Se ni rigardas la statistikojn sur la sama virtuala servilo, ni havas envenantajn pakaĵojn, envenantajn konegojn, sed absolute neniujn elirantajn. Eksiĝintaj konektoj iras rekte al la kliento. Bone, ni povis malekvilibrigi ĝin. Nun, kio okazas se unu el niaj foto-enkursigiloj malsukcesas? Post ĉio, fero estas fero. Ĝi povas eniri en kernan paniko, ĝi povas rompi, la nutrado povas forbruli. Io ajn. Tial necesas sankontroloj. Ili povas esti tiel simplaj kiel kontroli kiel la haveno estas malfermita, aŭ io pli kompleksa, ĝis kelkaj hejme skribitaj skriptoj, kiuj eĉ kontrolos la komercan logikon.
Ni haltis ie en la mezo: ni havas https-peton al specifa loko, la skripto estas vokita, se ĝi respondas per 200-a respondo, ni kredas, ke ĉio estas en ordo ĉe ĉi tiu servilo, ke ĝi vivas kaj povas esti ŝaltita sufiĉe. facile.
Kiel tio, denove, aspektas en la praktiko? Ni malŝaltu la servilon por prizorgado - ekbriligi la BIOS, ekzemple. En la protokoloj ni tuj havas tempon, ni vidas la unuan linion, tiam post tri provoj ĝi estas markita kiel "malsukcesa", kaj ĝi estas simple forigita de la listo.
Dua kondut-opcio ankaŭ eblas, kiam VS estas simple agordita al nulo, sed se la foto estas resendita, tio ne funkcias bone. La servilo aperas, Nginx ekiras tie, sankontrolo tuj komprenas, ke la konekto funkcias, ke ĉio estas en ordo, kaj la servilo aperas en nia listo, kaj la ŝarĝo tuj komencas aplikiĝi al ĝi. Neniuj manaj agoj estas postulataj de la devo-administranto. La servilo rekomencis nokte - la kontrola fako ne vokas nin pri tio nokte. Ili informas vin, ke tio okazis, ĉio estas en ordo.
Do, en sufiĉe simpla maniero, kun la helpo de malgranda nombro da serviloj, ni solvis la problemon de ekstera misfunkciadotoleremo.
Restas nur diri, ke ĉio ĉi, kompreneble, devas esti kontrolata. Aparte, oni devas rimarki, ke Keepalivede, kiel programaro skribita antaŭ longe, havas multajn manierojn kontroli ĝin, ambaŭ uzante kontrolojn per DBus, SMTP, SNMP kaj norma Zabbix. Krome, li mem scias skribi leterojn por preskaŭ ĉiu terno, kaj sincere, iam ni eĉ pensis malŝalti ĝin, ĉar li skribas multajn leterojn por ajna trafika ŝaltado, ŝaltado, por ĉiu IP-konekto, kaj tiel plu. Kompreneble, se estas multaj serviloj, tiam vi povas superŝuti vin per ĉi tiuj leteroj. Ni monitoras nginx sur fotaj enkursigiloj uzante normajn metodojn, kaj aparatara monitorado ne malaperis. Ni, kompreneble, konsilus du pliajn aferojn: unue, eksterajn sankontrolojn kaj haveblecon, ĉar eĉ se ĉio funkcias, fakte, eble uzantoj ne ricevas fotojn pro problemoj kun eksteraj provizantoj aŭ io pli kompleksa. Ĉiam indas konservi ie en alia reto, en Amazon aŭ ie aliloke, apartan maŝinon, kiu povas pingvi viajn servilojn de ekstere, kaj ankaŭ indas uzi aŭ detekton de anomalioj, por tiuj, kiuj scias fari malfacilan maŝinlernadon, aŭ simplan monitoradon. , almenaŭ por spuri ĉu la petoj forte malpliiĝis, aŭ male, pliiĝis. Ĝi ankaŭ povas esti utila.
Ni resumu: ni, fakte, anstataŭigis la ferkovritan solvon, kiu iam ĉesis konveni al ni, per sufiĉe simpla sistemo, kiu faras ĉion same, tio estas, ĝi provizas ĉesigon de HTTPS-trafiko kaj plian inteligentan vojigon per la necesaj sankontroloj. Ni pliigis la stabilecon de ĉi tiu sistemo, tio estas, ni ankoraŭ havas altan haveblecon por ĉiu tavolo, krome ni ricevis la gratifikon, ke estas sufiĉe facile grimpi ĉion sur ĉiu tavolo, ĉar ĝi estas norma aparataro kun norma programaro, tio estas. , ni simpligis diagnozon de eblaj problemoj.
Kion ni finis? Ni havis problemon dum la januara feriado de 2018. En la unuaj ses monatoj dum ni funkciigas ĉi tiun skemon, ni vastigis ĝin al la tuta trafiko por forigi la tutan trafikon de LTM, ni kreskis nur en trafiko en unu datumcentro de 40 gigabitoj ĝis 60 gigabitoj, kaj samtempe por la tuta jaro 2018 povis sendi preskaŭ trioble pli da fotoj sekundo.
fonto: www.habr.com