Nútímavefurinn er nánast óhugsandi án fjölmiðlaefnis: næstum allar ömmur eru með snjallsíma, allir eru á samfélagsnetum og tími í viðhaldi er dýr fyrir fyrirtæki. Hér er afrit af sögu félagsins um hvernig hún skipulagði afhendingu mynda með því að nota vélbúnaðarlausn, hvaða frammistöðuvandamál hún lenti í í ferlinu, hvað olli þeim og hvernig þessi vandamál voru leyst með hugbúnaðarlausn byggða á Nginx, á sama tíma og hún tryggði bilanaþol á öllum stigum (). Við þökkum höfundum sögu Olegs Efimova og Alexandra Dymova, sem deildu reynslu sinni á ráðstefnunni .
— Við skulum byrja á smá kynningu um hvernig við geymum og geymum myndir. Við höfum lag þar sem við geymum þær og lag þar sem við vistum myndirnar. Á sama tíma, ef við viljum ná háum brelluhraða og draga úr álagi á geymslu, er mikilvægt fyrir okkur að hver mynd af einstökum notanda sé á einum skyndiminniþjóni. Annars þyrftum við að setja upp jafn oft fleiri diska og við erum með fleiri netþjóna. Bragðahlutfallið okkar er um 99%, það er að segja að við erum að minnka álagið á geymsluna okkar um 100 sinnum, og til þess að gera þetta, fyrir 10 árum, þegar verið var að byggja allt þetta, vorum við með 50 netþjóna. Í samræmi við það, til þess að þjóna þessum myndum, þurftum við í meginatriðum 50 ytri lén sem þessir netþjónar þjóna.
Auðvitað vaknaði spurningin strax: Ef einn af netþjónum okkar fer niður og verður óaðgengilegur, hvaða hluta af umferðinni missum við? Við skoðuðum hvað væri á markaðnum og ákváðum að kaupa vélbúnað svo hann leysti öll vandamál okkar. Valið féll á lausn F5-netfyrirtækisins (sem, við the vegur, keypti nýlega NGINX, Inc): BIG-IP Local Traffic Manager.
Það sem þessi vélbúnaður (LTM) gerir: þetta er járnbeini sem gerir járnofþörf á ytri höfnum sínum og gerir þér kleift að beina umferð út frá svæðisfræði netkerfisins, á sumum stillingum og gerir heilsufarsskoðun. Það var mikilvægt fyrir okkur að hægt væri að forrita þennan vélbúnað. Í samræmi við það gætum við lýst rökfræðinni um hvernig ljósmyndir af tilteknum notanda voru birtar úr tilteknu skyndiminni. Hvernig lítur það út? Það er vélbúnaður sem horfir á internetið á einu léni, einu IP, gerir ssl afhleðslu, greinir http beiðnir, velur skyndiminni númer frá IRule, hvert á að fara og hleypir umferð þangað. Á sama tíma gerir það heilsufarsskoðun og ef einhver vél var ekki tiltæk, þá gerðum við það þannig að umferðin fór á einn varaþjón. Frá sjónarhóli stillingar eru auðvitað nokkur blæbrigði, en almennt er allt frekar einfalt: við skráum kort, samsvörun ákveðins númers við IP okkar á netinu, við segjum að við munum hlusta á tengi 80 og 443, segjum við að ef þjónninn er ekki tiltækur, þá þarftu að senda umferð á varaafritið, í þessu tilviki þann 35., og við lýsum fullt af rökfræði um hvernig ætti að taka þennan arkitektúr í sundur. Eina vandamálið var að tungumálið sem vélbúnaðurinn var forritaður á var Tcl. Ef einhver man þetta yfirhöfuð... þetta tungumál er frekar skriflegt en tungumál sem hentar til forritunar:
Hvað fengum við? Við fengum vélbúnað sem tryggir mikið framboð á innviðum okkar, beinir allri umferð okkar, veitir heilsufarslegum ávinningi og virkar bara. Þar að auki virkar það í nokkuð langan tíma: undanfarin 10 ár hefur ekki verið kvartað yfir því. Í byrjun árs 2018 vorum við þegar að senda um 80 þúsund myndir á sekúndu. Þetta er einhvers staðar í kringum 80 gígabita umferð frá báðum gagnaverum okkar.
En ...
Í byrjun árs 2018 sáum við ljóta mynd á vinsældarlistanum: tíminn sem það tók að senda myndir hafði greinilega aukist. Og það hætti að henta okkur. Vandamálið er að þessi hegðun var aðeins sýnileg þegar umferðin var sem mest - hjá fyrirtækinu okkar er þetta nóttin frá sunnudag til mánudags. En restina af tímanum hegðaði kerfið sér eins og venjulega, engin merki um bilun.
Engu að síður varð að leysa vandann. Við greindum hugsanlega flöskuhálsa og fórum að útrýma þeim. Fyrst af öllu, auðvitað, stækkuðum við ytri upptengla, gerðum heildarúttekt á innri upptengingum og fundum alla hugsanlega flöskuhálsa. En allt þetta gaf ekki augljósa niðurstöðu, vandamálið hvarf ekki.
Annar mögulegur flöskuháls var frammistaða myndageymslunnar sjálfra. Og við ákváðum að kannski væri vandamálið hjá þeim. Jæja, við stækkuðum afköst - aðallega nettengi á myndaskyndiminni. En aftur sást engin augljós framför. Í lokin fylgdumst við vel með frammistöðu LTM sjálfs og hér sáum við sorglega mynd á línuritunum: álagið á alla örgjörva fer að ganga snurðulaust, en kemur svo skyndilega á hásléttu. Á sama tíma hættir LTM að bregðast fullnægjandi við heilsufarsskoðunum og upptengingum og byrjar að slökkva á þeim af handahófi, sem leiðir til alvarlegs skerðingar á frammistöðu.
Það er, við höfum greint upptök vandans, greint flöskuhálsinn. Það á eftir að ákveða hvað við gerum.
Það fyrsta, augljósasta sem við gætum gert er að nútímavæða LTM sjálft á einhvern hátt. En það eru nokkur blæbrigði hér, vegna þess að þessi vélbúnaður er alveg einstakur, þú munt ekki fara í næsta matvörubúð og kaupa hann. Þetta er sérsamningur, sérstakur leyfissamningur og mun taka mikinn tíma. Annar kosturinn er að byrja að hugsa sjálfur, koma með þína eigin lausn með eigin íhlutum, helst með opnum aðgangsforriti. Allt sem er eftir er að ákveða hvað nákvæmlega við munum velja fyrir þetta og hversu miklum tíma við munum eyða í að leysa þetta vandamál, vegna þess að notendur fengu ekki nógu margar myndir. Þess vegna þurfum við að gera þetta allt mjög, mjög hratt, mætti segja í gær.
Þar sem verkefnið hljómaði eins og "gera eitthvað eins fljótt og auðið er og nota vélbúnaðinn sem við höfum," það fyrsta sem við hugsuðum var einfaldlega að fjarlægja nokkrar ekki mjög öflugar vélar að framan, setja Nginx þar, sem við vitum hvernig á að gera. vinna og reyndu að innleiða alla sömu rökfræði og vélbúnaður notaði til að gera. Það er að segja að við fórum frá vélbúnaðinum okkar, settum upp 4 netþjóna í viðbót sem við þurftum að stilla, bjuggum til ytri lén fyrir þá, svipað og það var fyrir 10 árum síðan... Við misstum aðeins í framboði ef þessar vélar féllu, en enn síður, þeir leystu vandamál notenda okkar á staðnum.
Samkvæmt því er rökfræðin sú sama: við setjum upp Nginx, það getur gert SSL-afhleðslu, við getum einhvern veginn forritað leiðarrökfræðina, heilsufarsskoðanir í stillingum og einfaldlega afritað rökfræðina sem við höfðum áður.
Við skulum setjast niður til að skrifa stillingar. Í fyrstu virtist allt vera mjög einfalt, en því miður er mjög erfitt að finna handbækur fyrir hvert verkefni. Þess vegna mælum við ekki með því að googla einfaldlega „hvernig á að stilla Nginx fyrir myndir“: það er betra að vísa í opinberu skjölin sem sýna hvaða stillingar ætti að snerta. En það er betra að velja tiltekna breytu sjálfur. Jæja, þá er allt einfalt: við lýsum netþjónunum sem við höfum, við lýsum skilríkjunum... En það áhugaverðasta er í raun leiðarrökfræðin sjálf.
Í fyrstu virtist okkur sem við værum einfaldlega að lýsa staðsetningu okkar, passa við númer myndaskyndiminnis okkar í því, nota hendur okkar eða rafall til að lýsa hversu mörg uppstreymi við þurfum, í hverjum andstreymis tilgreinum við netþjóninn sem umferðin á að fara, og varaþjónn - ef aðalþjónninn er ekki tiltækur:
En líklega, ef allt væri svona einfalt, myndum við einfaldlega fara heim og ekki segja neitt. Því miður, með sjálfgefnum Nginx stillingum, sem almennt voru gerðar í margra ára þróun og henta ekki alveg fyrir þetta tilfelli... lítur stillingin svona út: ef einhver andstreymisþjónn hefur beiðnivillu eða tímamörk, Nginx alltaf skiptir umferð yfir á næsta. Þar að auki, eftir fyrstu bilun, innan 10 sekúndna verður einnig slökkt á þjóninum, bæði fyrir mistök og með tímamörkum - þetta er ekki einu sinni hægt að stilla á nokkurn hátt. Það er að segja, ef við fjarlægjum eða endurstillum tímamörk í andstreymistilskipuninni, þá, þó Nginx muni ekki vinna úr þessari beiðni og bregðast við með einhverjum ekki mjög góðri villu, mun þjónninn lokast.
Til að forðast þetta gerðum við tvennt:
a) þeir bönnuðu Nginx að gera þetta handvirkt - og því miður er eina leiðin til að gera þetta einfaldlega að stilla max fails stillingar.
b) við minntumst þess að í öðrum verkefnum notum við einingu sem gerir okkur kleift að gera bakgrunnsheilbrigðisskoðanir - í samræmi við það gerðum við nokkuð tíðar heilsufarsskoðanir þannig að niður í miðbæ ef slys yrði.
Því miður er þetta ekki allt heldur, því bókstaflega fyrstu tvær vikurnar af notkun þessa kerfis sýndu að TCP heilsufarsskoðun er líka óáreiðanlegur hlutur: á andstreymisþjóninum er það kannski ekki Nginx, eða Nginx í D-stöðu, og í Í þessu tilviki mun kjarninn samþykkja tenginguna, heilsufarsskoðun mun standast, en mun ekki virka. Þess vegna skiptum við þessu strax út fyrir heilsuskoðun http, gerðum sérstakan, sem, ef hann skilar 200, þá virkar allt í þessu handriti. Þú getur gert frekari rökfræði - til dæmis, ef um er að ræða skyndiminni netþjóna, athugaðu hvort skráarkerfið sé rétt tengt:
Og þetta myndi henta okkur, nema að í augnablikinu endurtók hringrásin algjörlega það sem vélbúnaðurinn gerði. En við vildum gera betur. Áður höfðum við einn afritunarþjón og það er líklega ekki mjög gott, því ef þú ert með hundrað netþjóna, þá er ólíklegt að einn afritunarþjónn ráði við álagið þegar nokkrir bila í einu. Þess vegna ákváðum við að dreifa pöntuninni á alla netþjóna: við gerðum einfaldlega annan aðskilinn andstreymis, skrifuðum alla netþjóna þar með ákveðnum breytum í samræmi við álagið sem þeir geta þjónað, bættum við sömu heilsufarsskoðunum og við höfðum áður:
Þar sem það er ómögulegt að fara í annan andstreymis innan eins andstreymis, var nauðsynlegt að ganga úr skugga um að ef aðal andstreymis, þar sem við skráðum einfaldlega rétta, nauðsynlega myndaskyndiminni, væri ekki tiltækur, fórum við einfaldlega í gegnum error_page til fallback, frá kl. þar sem við fórum í öryggisafritið andstreymis:
Og með því að bæta bókstaflega við fjórum netþjónum, þá er þetta það sem við fengum: við skiptum út hluta af álaginu - við fjarlægðum það úr LTM yfir á þessa netþjóna, innleiddum sömu rökfræði þar, með venjulegum vélbúnaði og hugbúnaði, og fengum strax þann bónus sem þessir netþjónar geta. vera stækkuð, vegna þess að þeir geta einfaldlega verið útvegaðir eins mikið og þarf. Jæja, eina neikvæða er að við höfum misst mikið framboð fyrir utanaðkomandi notendur. En á þeirri stundu urðum við að fórna þessu, því það var nauðsynlegt að leysa vandann strax. Þannig að við fjarlægðum hluta af álaginu, það var um 40% á þeim tíma, LTM leið vel og bókstaflega tveimur vikum eftir að vandamálið byrjaði fórum við að senda ekki 45 þúsund beiðnir á sekúndu heldur 55 þúsund. Reyndar jókst við um 20% - þetta er greinilega umferðin sem við gáfum notandanum ekki. Og eftir það fóru þeir að hugsa um hvernig ætti að leysa vandamálið sem eftir er - til að tryggja mikið ytra aðgengi.
Við gerðum smá pásu þar sem við ræddum hvaða lausn við myndum nota fyrir þetta. Það voru tillögur um að tryggja áreiðanleika með því að nota DNS, nota nokkur heimaskrifuð forskrift, kraftmikla leiðarreglur... það voru margir möguleikar, en það var þegar ljóst að til að fá raunverulega áreiðanlega afhendingu mynda þarftu að kynna annað lag sem mun fylgjast með þessu . Við kölluðum þessar vélar ljósmyndastjóra. Hugbúnaðurinn sem við treystum á var Keepalived:
Til að byrja með, hvað samanstendur Keepalved af? Í fyrsta lagi er VRRP samskiptareglan, sem netverjar þekkja víða, staðsett á netbúnaði sem veitir bilunarþol gagnvart ytri IP tölunni sem viðskiptavinir tengjast. Annar hlutinn er IPVS, IP sýndarþjónn, til að koma jafnvægi á milli myndabeina og tryggja bilanaþol á þessu stigi. Og í þriðja lagi - heilsufarsskoðun.
Byrjum á fyrsta hlutanum: VRRP - hvernig lítur það út? Það er ákveðin sýndar-IP, sem hefur færslu í dns badoocdn.com, þar sem viðskiptavinir tengjast. Á einhverjum tímapunkti höfum við IP tölu á einum netþjóni. Keepalive pakkar keyra á milli netþjóna með því að nota VRRP samskiptareglur, og ef skipstjórinn hverfur af radarnum - þjónninn hefur endurræst eða eitthvað annað, þá tekur öryggisafritunarþjónninn sjálfkrafa upp þetta IP tölu - engar handvirkar aðgerðir eru nauðsynlegar. Munurinn á skipstjóra og öryggisafriti hefur aðallega forgang: því hærri sem hann er, því meiri líkur eru á að vélin verði skipstjóri. Mjög stór kostur er að þú þarft ekki að stilla IP tölur á þjóninum sjálfum, það er nóg að lýsa þeim í stillingunni, og ef IP tölurnar þurfa einhverjar sérsniðnar leiðarreglur er þessu lýst beint í stillingunni, með því að nota sama setningafræði og lýst er í VRRP pakkanum. Þú munt ekki lenda í neinum ókunnugum hlutum.
Hvernig lítur þetta út í reynd? Hvað gerist ef einn af netþjónunum bilar? Um leið og meistarinn hverfur hættir öryggisafritið okkar að fá auglýsingar og verður sjálfkrafa meistari. Eftir nokkurn tíma gerðum við meistarann, endurræstum, hækkuðum Keepalived - auglýsingar berast með hærri forgang en öryggisafritið og öryggisafritið snýr sjálfkrafa til baka, fjarlægir IP tölur, engar handvirkar aðgerðir þurfa að gera.
Þannig höfum við tryggt bilanaþol ytri IP tölu. Næsti hluti er að koma á einhvern hátt jafnvægi á umferðina frá ytri IP-tölu til myndabeina sem eru þegar að loka henni. Allt er alveg skýrt með jöfnunarreglurnar. Þetta er annað hvort einfalt round-robin, eða aðeins flóknari hlutir, wrr, listatenging og svo framvegis. Þessu er í grundvallaratriðum lýst í skjölunum, það er ekkert sérstakt. En afhendingaraðferðin... Hér munum við skoða nánar hvers vegna við völdum einn þeirra. Þetta eru NAT, Direct Routing og TUN. Staðreyndin er sú að við ætluðum strax að skila 100 gígabitum af umferð frá síðunum. Ef þú áætlar, þú þarft 10 gígabit kort, ekki satt? 10 gígabitakort á einum netþjóni eru nú þegar utan ramma, að minnsta kosti, hugmynd okkar um „staðlaðan búnað“. Og svo minntum við þess að við gefum ekki bara upp smá umferð, við gefum myndir.
Hvað er sérstakt? — Gífurlegur munur á komandi og áleiðis umferð. Komandi umferð er mjög lítil, umferð á útleið er mjög mikil:
Ef þú skoðar þessi línurit má sjá að í augnablikinu er leikstjórinn að fá um 200 MB á sekúndu, þetta er ósköp venjulegur dagur. Við gefum til baka 4,500 MB á sekúndu, hlutfallið okkar er um það bil 1/22. Það er nú þegar ljóst að til að veita útleið að fullu til 22 starfsmannaþjóna þurfum við aðeins einn sem samþykkir þessa tengingu. Þetta er þar sem beina leiðaralgrímið kemur okkur til hjálpar.
Hvernig lítur það út? Ljósmyndastjórinn okkar, samkvæmt töflunni hans, sendir tengingar til myndabeina. En myndabeinir senda aftur umferð beint á netið, senda hana til viðskiptavinarins, hún fer ekki aftur í gegnum myndastjórann, þannig, með lágmarksfjölda véla, tryggjum við algjört bilanaþol og dælingu á allri umferð. Í stillingunum lítur það svona út: við tilgreinum reikniritið, í okkar tilfelli er það einfalt rr, gefum upp beina leiðaraðferðina og byrjum síðan að skrá alla raunverulegu netþjóna, hversu marga af þeim við höfum. Sem mun ráða þessari umferð. Ef við erum með einn eða tvo netþjóna í viðbót þar, eða nokkra netþjóna, þá kemur slík þörf - við bætum bara þessum hluta við stillinguna og höfum ekki of miklar áhyggjur. Frá hlið raunverulegra netþjóna, frá hlið ljósmyndabeins, krefst þessi aðferð lágmarks stillingar, henni er fullkomlega lýst í skjölunum og það eru engar gildrur þar.
Það sem er sérstaklega gaman er að slík lausn felur ekki í sér róttæka endurhönnun á staðarnetinu; þetta var mikilvægt fyrir okkur; við þurftum að leysa þetta með lágmarks kostnaði. Ef þú horfir á , þá munum við sjá hvernig það lítur út. Hér erum við með ákveðinn sýndarþjónn, á port 443, hlustar, tekur við tengingunni, allir virkir netþjónar eru skráðir og þú getur séð að tengingin er, gefa eða taka, sú sama. Ef við skoðum tölfræðina á sama sýndarþjóninum þá erum við með komandi pakka, komandi tengingar, en nákvæmlega engar sendar. Sendandi tengingar fara beint til viðskiptavinarins. Allt í lagi, okkur tókst að koma þessu úr jafnvægi. Nú, hvað gerist ef einn af ljósmyndabeinum okkar bilar? Enda er járn járn. Það gæti farið í kjarna læti, það gæti brotnað, aflgjafinn gæti brunnið út. Hvað sem er. Þess vegna er þörf á heilbrigðiseftirliti. Þau geta verið eins einföld og að athuga hvernig gáttin er opin, eða eitthvað flóknara, upp í heimaskrifuð forskrift sem mun jafnvel athuga viðskiptarökfræðina.
Við stoppuðum einhvers staðar í miðjunni: við erum með https beiðni á ákveðna staðsetningu, forskriftin er kölluð, ef það svarar með 200. svari, teljum við að allt sé í lagi með þennan netþjón, að hann sé lifandi og hægt sé að kveikja á honum alveg auðveldlega.
Hvernig lítur þetta aftur út í reynd? Við skulum slökkva á þjóninum til viðhalds - blikkar BIOS, til dæmis. Í annálunum höfum við strax tímamörk, við sjáum fyrstu línuna, síðan eftir þrjár tilraunir er hún merkt sem „mistókst“ og hún er einfaldlega fjarlægð af listanum.
Annar hegðunarvalkostur er líka mögulegur, þegar VS er einfaldlega stillt á núll, en ef myndinni er skilað virkar þetta ekki vel. Miðlarinn kemur upp, Nginx byrjar þar, heilsufarsskoðun skilur strax að tengingin er að virka, að allt sé í lagi og þjónninn birtist á listanum okkar og álagið byrjar strax að setja á hann. Engar handvirkar aðgerðir eru nauðsynlegar frá vaktstjóra. Miðlarinn endurræsti á nóttunni - eftirlitsdeildin hringir ekki í okkur um þetta á nóttunni. Þeir tilkynna þér að þetta hafi gerst, allt er í lagi.
Svo, á frekar einfaldan hátt, með hjálp fárra netþjóna, leystum við vandamálið með ytri bilanaþol.
Eftir er að segja að allt þetta þarf auðvitað að fylgjast með. Sérstaklega skal tekið fram að Keepalivede, sem hugbúnaður skrifaður fyrir löngu síðan, hefur fullt af leiðum til að fylgjast með því, bæði með því að nota athuganir í gegnum DBus, SMTP, SNMP og staðlaða Zabbix. Auk þess veit hann sjálfur hvernig á að skrifa stafi fyrir næstum hvert hnerra, og satt best að segja datt okkur á einhverjum tímapunkti jafnvel í hug að slökkva á því, því hann skrifar fullt af bréfum fyrir hverja umferð sem skiptir, kveikir á, fyrir hverja IP-tengingu, og svo framvegis . Auðvitað, ef það eru margir netþjónar, þá geturðu yfirbugað þig með þessum stöfum. Við fylgjumst með nginx á myndabeinum með stöðluðum aðferðum og vélbúnaðarvöktun hefur ekki horfið. Við viljum að sjálfsögðu ráðleggja tvennt til viðbótar: Í fyrsta lagi ytri heilsufarsskoðun og aðgengi, því jafnvel þótt allt virki, þá fá notendur kannski ekki myndir vegna vandamála við utanaðkomandi þjónustuaðila eða eitthvað flóknara. Það er alltaf þess virði að hafa einhvers staðar á öðru neti, í Amazon eða annars staðar, sérstaka vél sem getur pingað netþjóna þína utan frá, og það er líka þess virði að nota annaðhvort fráviksgreiningu, fyrir þá sem vita hvernig á að gera erfiðan vélanám, eða einfalt eftirlit. , að minnsta kosti til að fylgjast með því hvort beiðnum hefur fækkað mikið, eða þvert á móti fjölgað. Það getur líka verið gagnlegt.
Við skulum draga saman: við skiptum í rauninni út járnklæddu lausninni, sem á einhverjum tímapunkti hætti að henta okkur, fyrir frekar einfalt kerfi sem gerir allt eins, það er að segja, það veitir stöðvun á HTTPS umferð og frekari snjalla leið með nauðsynlegar heilbrigðisskoðanir. Við höfum aukið stöðugleika þessa kerfis, það er að segja, við höfum enn mikið framboð fyrir hvert lag, auk þess sem við höfum þann bónus að það er frekar auðvelt að skala það allt á hverju lagi, því það er staðall vélbúnaður með stöðluðum hugbúnaði, þ.e. , við höfum einfaldað greiningu á hugsanlegum vandamálum.
Hvað enduðum við með? Við áttum í vandræðum í janúarfríinu 2018. Fyrstu sex mánuðina á meðan við tókum þetta kerfi í notkun, stækkuðum við það í alla umferð til að fjarlægja alla umferð frá LTM, við óxum aðeins í umferð í einni gagnaver úr 40 gígabitum í 60 gígabita og á sama tíma fyrir allt árið 2018 gátu sent næstum þrisvar sinnum fleiri myndir á sekúndu.
Heimild: www.habr.com