Савремени веб је готово незамислив без медијског садржаја: скоро свака бака има паметни телефон, сви су на друштвеним мрежама, а застоји у услугама су скупи за компаније. За вашу пажњу, транскрипт приче компаније о томе како је организовала испоруку фотографија користећи хардверско решење, на које проблеме у раду је наишла у процесу, шта их је изазвало и како су ови проблеми решени коришћењем софтверског решења заснованог на Нгинк-у, уз обезбеђивање толеранције грешака на свим нивоима (). Захваљујемо се ауторима приче Олегу Ефимова и Александра Димова, које су поделиле своја искуства на конференцији .
Почнимо са малим уводом о томе како чувамо и кеширамо фотографије. Имамо слој где их складиштимо и слој где кеширамо фотографије. Истовремено, ако желимо да постигнемо велики трик и смањимо оптерећење складишта, важно нам је да свака фотографија појединачног корисника лежи на једном серверу за кеширање. У супротном, морали бисмо да инсталирамо онолико пута више дискова колико имамо више сервера. Наша стопа погодака је око 99%, односно смањујемо оптерећење на нашем складишту за 100 пута, а да бисмо то урадили, пре 10 година, када се све ово градило, имали смо 50 сервера. Сходно томе, да бисмо дали ове фотографије, било нам је потребно, заправо, 50 спољних домена које ови сервери опслужују.
Наравно, одмах се поставило питање: ако се један од наших сервера поквари и постане недоступан, који део саобраћаја губимо? Погледали смо шта има на тржишту и одлучили да купимо комад гвожђа да би решио све наше проблеме. Избор је пао на решење компаније Ф5-мрежа (која је, иначе, не тако давно купила НГИНКС, Инц): БИГ-ИП Лоцал Траффиц Манагер.
Шта овај комад гвожђа (ЛТМ) ради: то је гвоздени рутер који чини редунданцију својих спољних портова и омогућава вам да усмерите саобраћај на основу топологије мреже, на неким подешавањима и врши проверу здравља. Било нам је важно да се овај комад гвожђа може програмирати. Сходно томе, могли бисмо описати логику како су фотографије одређеног корисника враћене из одређеног кеша. Како то изгледа? Постоји део хардвера који гледа на Интернет за један домен, једну ИП адресу, врши ссл оффлоад, анализира хттп захтеве, бира број кеша из ИРуле-а, где да иде и пушта саобраћај тамо. Истовремено, ради и здравствене провере, а у случају недоступности машине, направили смо тако да саобраћај у том тренутку иде на један резервни сервер. Са становишта конфигурације, постоје, наравно, неке нијансе, али генерално све је прилично једноставно: прописујемо мапу, одређени број одговара нашем ИП-у на мрежи, кажемо да ћемо слушати на портовима 80 и 443, кажемо да ако је сервер недоступан, онда треба пустити саобраћај у резервну копију, у овом случају 35., а ми описујемо гомилу логике како ову архитектуру треба раставити. Једини проблем је био у томе што је језик на којем је програмиран комад гвожђа језик Тцл. Ако се неко уопште сећа овога ... овај језик је више само за писање него језик погодан за програмирање:
Шта смо добили? Добили смо део хардвера који обезбеђује високу доступност наше инфраструктуре, усмерава сав наш саобраћај, обезбеђује здравствене прегледе и једноставно ради. Штавише, ради доста дуго: у протеклих 10 година није било притужби на то. До почетка 2018. већ смо рендеровали око 80 хиљада фотографија у секунди. Ово је негде око 80 гигабита саобраћаја из оба наша дата центра.
Али…
Почетком 2018. видели смо ружну слику на листама: време за враћање фотографија се очигледно повећало. И то је престало да нам одговара. Проблем је што је овакво понашање било видљиво само на самом врхунцу саобраћаја - за наше предузеће је ово ноћ са недеље на понедељак. Али остатак времена систем се понашао као и обично, без знакова лома.
Међутим, проблем је морао да се реши. Идентификовали смо могућа уска грла и почели да их отклањамо. Пре свега, наравно, проширили смо екстерне уплинкове, извршили потпуну ревизију унутрашњих уплинк-ова и пронашли сва могућа уска грла. Али све ово није дало очигледан резултат, проблем није нестао.
Још једно могуће уско грло је био учинак самих кеша фотографија. И одлучили смо да је проблем можда у њима. Па, проширили смо перформансе - у основи, мрежни портови на кеш меморији фотографија. Али опет, јасно побољшање није примећено. На крају, обратили смо велику пажњу на перформансе самог ЛТМ-а, и овде смо видели тужну слику на графиконима: учитавање свих ЦПУ-а почиње да иде глатко, али онда нагло лежи на полици. Истовремено, ЛТМ престаје да адекватно реагује на здравствене провере и уплинкове и почиње да их насумично искључује, што доводи до озбиљног смањења перформанси.
То јест, идентификовали смо извор проблема, идентификовали уско грло. Остаје да одлучимо шта ћемо.
Прва очигледна ствар коју бисмо могли да урадимо је да некако модернизујемо сам ЛТМ. Али овде постоје неке нијансе, јер је ово гвожђе прилично јединствено, нећете отићи у најближи супермаркет и купити га. То је посебан уговор, посебан уговор о лиценци, и биће потребно доста времена. Друга опција је да почнете да размишљате својом главом, да смислите сопствено решење на сопственим компонентама, по могућности користећи програм отвореног кода. Остаје само да одлучимо шта ћемо тачно изабрати за ово и колико времена ћемо потрошити на решавање овог проблема, јер корисници нису добили фотографије. Дакле, потребно је све ово урадити веома, веома брзо, могло би се рећи – јуче.
Пошто је задатак звучао као „урадите нешто што је брже могуће и користећи хардвер који имамо“, прво на шта смо помислили је само да уклонимо неке не најмоћније машине са предње стране, ставимо тамо Нгинк, са којим знамо како да раде, и покушају да спроведу сву исту логику коју је некада радио комад гвожђа. То јест, у ствари, оставили смо свој део хардвера, инсталирали још 4 сервера које смо морали да конфигуришемо, направили спољне домене за њих по аналогији како је било пре 10 година... Мало смо изгубили у доступности ако су ове машине пале , али је ипак мање решио проблем наших корисника локално.
Сходно томе, логика остаје иста: инсталирамо Нгинк, он може да уради ССЛ-оффлоад, можемо некако да програмирамо логику рутирања, провере здравља конфигурација и једноставно дуплирамо логику коју смо имали раније.
Седамо да напишемо конфигурације. У почетку се чинило да је све врло једноставно, али, нажалост, веома је тешко пронаћи приручнике за сваки задатак. Стога вам не саветујемо да једноставно прогуглате „како да конфигуришете Нгинк за фотографије“: боље је погледати званичну документацију која ће показати која подешавања треба додирнути. Али боље је сами одабрати одређени параметар. Па, онда је све једноставно: описујемо сервере које имамо, описујемо сертификате ... Али најинтересантнија ствар је, у ствари, сама логика рутирања.
У почетку нам се чинило да једноставно опишемо своју локацију, ускладимо број кеш меморије фотографија у њој, опишемо рукама или генератором колико нам је узводно потребно, у сваком узводном току означавамо сервер на који саобраћај треба да иде, а резервни сервер - у случају да главни сервер није доступан:
Али, вероватно, да је све тако једноставно, само бисмо отишли кући и ништа не бисмо рекли. Нажалост, са подразумеваним подешавањима Нгинк-а, која су, генерално, направљена током много година развоја и не баш за овај случај ... конфигурација изгледа овако: у случају да неки упстреам сервер има грешку у захтеву или временско ограничење, Нгинк увек пребацује саобраћај на следећи. Истовремено, након првог неуспеха, сервер ће се такође искључити у року од 10 секунди, грешком и тимеоутом - ово се ни на који начин не може конфигурисати. То јест, ако уклонимо или ресетујемо опцију временског ограничења у упстреам директиви, тада ће се сервер искључити, иако Нгинк неће обрадити овај захтев и одговорити неком не тако добром грешком.
Да бисмо ово избегли, урадили смо две ствари:
а) забранили су Нгинк-у да ово ради ручно - и нажалост, једини начин да то урадите је да једноставно поставите подешавања за максималне грешке.
б) сетили смо се да у другим пројектима користимо модул који вам омогућава да урадите здравствене провере у позадини – сходно томе, радили смо прилично честе здравствене провере тако да имамо минимално време застоја у случају несреће.
Нажалост, ни ово није све, јер су буквално прве две недеље рада ове шеме показале да је ТЦП провера здравља такође непоуздана ствар: на упстреам серверу то можда није Нгинк, или Нгинк у Д-стању, а у у овом случају кернел ће прихватити везу, провера здравља ће проћи, али неће радити. Стога смо ово одмах заменили са хттп-провера здравља, направили одређени, који, ако врати 200, онда све ради у овој скрипти. Можете да урадите додатну логику - на пример, у случају сервера за кеширање, проверите да ли је систем датотека правилно монтиран:
И то би нам одговарало, само што је тренутно коло у потпуности поновило оно што је урадио комад гвожђа. Али желели смо да будемо бољи. Раније смо имали један резервни сервер, а то вероватно није добро, јер ако имате сто сервера, онда када неколико падне одједном, један резервни сервер вероватно неће моћи да се носи са оптерећењем. Због тога смо одлучили да распоредимо резервацију на све сервере: једноставно смо направили још један одвојени упстреам, снимили све сервере тамо са одређеним параметрима у складу са којим оптерећењем могу да опслуже, додали исте провере здравља које смо имали раније:
Пошто не можете да идете на други узводно унутар једног узводног, било је потребно да се уверимо да ако главни узводни, у који смо једноставно уписали исправну, неопходну кеш меморију фотографија, није био доступан, једноставно смо отишли на резервни преко еррор_паге, одакле отишли смо до резервне копије узводно:
И буквално додавањем четири сервера, добили смо ово: заменили смо део оптерећења - уклонили са ЛТМ-а на ове сервере, имплементирали исту логику користећи стандардни хардвер и софтвер, одмах добили бонус да се ови сервери могу скалирати, јер се могу једноставно ставите онолико колико вам је потребно. Па, једина негативна је та што смо изгубили високу доступност за спољне кориснике. Али тада сам морао да жртвујем ово, јер је било неопходно одмах решити проблем. Дакле, уклонили смо део оптерећења, тада је било око 40%, ЛТМ се побољшао, а буквално две недеље након што је проблем почео, почели смо да дајемо не 45к захтева у секунди, већ 55к. У ствари, порасли смо за 20% - ово је очигледно промет који нисмо дали кориснику. И након тога, почели су да размишљају о томе како да реше преостали проблем - да обезбеде високу екстерну доступност.
Имали смо паузу током које смо разговарали које решење ћемо користити за ово. Било је предлога да се обезбеди поузданост коришћењем ДНС-а, уз помоћ неких самостално писаних скрипти, динамичких протокола рутирања ... било је много опција, али је већ постало јасно да за заиста поуздан повратак фотографија морате увести још један слој који ће ово пратити. Ове машине смо назвали директорима фотографија. Софтвер на који смо се ослањали био је Кеепаливед:
За почетак, од чега се састоји Кеепаливед. Први је ВРРП протокол, надалеко познат мрежама, смештен на мрежној опреми која обезбеђује толеранцију грешака за спољну ИП адресу на коју се клијенти повезују. Други део је ИПВС, ИП виртуелни сервер, за балансирање између фото рутера и обезбеђивање толеранције грешака на овом нивоу. И трећи су здравствени прегледи.
Почнимо са првим делом: ВРРП - како то изгледа? Постоји одређена виртуелна ИП адреса, која има унос у днс бадооцдн.цом, где се клијенти повезују. У неком тренутку имамо ИП адресу на једном серверу. Кеепаливед пакети се покрећу између сервера користећи ВРРП протокол, а ако мастер нестане са радара - сервер се поново покренуо или нешто друго, резервни сервер аутоматски подиже ову ИП адресу - нису потребне ручне акције. Мастер и резервна се разликују, углавном приоритет: што је већи, већа је вероватноћа да ће машина постати мастер. Веома велика предност је што не морате да конфигуришете ИП адресе на самом серверу, довољно је да их опишете у конфигурацији, а ако су за ИП адресе потребна нека прилагођена правила рутирања, то је описано директно у конфигурацији, у иста синтакса као што је описано у ВРРП пакету. Нећете срести никакве непознате ствари.
Како то изгледа у пракси? Шта се дешава ако се један од сервера поквари? Чим мастер нестане, наша резервна копија престаје да добија промоције и аутоматски постаје мастер. После неког времена поправили смо мастер, поново покренули, подигли Кеепаливед - стижу огласи са већим приоритетом од резервне копије, а резервна копија се аутоматски враћа назад, уклања ИП адресе из себе, нису потребне никакве ручне радње.
Тиме смо обезбедили толеранцију грешака спољне ИП адресе. Следећи део је да се некако избалансира саобраћај са спољне ИП адресе до рутера фотографија који га већ прекидају. Са протоколима за балансирање, све је довољно јасно. Ово је или једноставно кружно, или мало сложеније ствари, врр, повезивање листе и тако даље. Ово је у основи описано у документацији, ту нема ништа посебно. Али начин испоруке ... Овде ћемо се детаљније задржати - зашто смо изабрали један од њих. То су НАТ, Дирецт Роутинг и ТУН. Чињеница је да смо одмах поставили повратак 100 гигабита саобраћаја са сајтова. Ово је ако схватите, треба вам 10 гигабитних картица, зар не? 10 гигабитних картица на једном серверу – ово је већ изнад, барем, нашег концепта „стандардне опреме“. А онда смо се сетили да не поклањамо само неки саобраћај, ми поклањамо фотографије.
Која је карактеристика? - Огромна разлика између долазног и одлазног саобраћаја. Долазни саобраћај је веома мали, одлазни саобраћај је веома велик:
Ако погледате ове графиконе, можете видети да се тренутно директору шаље око 200 Мб у секунди, ово је најтипичнији дан. Враћамо 4,500 МБ у секунди, однос је око 1/22. Већ сада је јасно да нам је за потпуно обезбеђење одлазног саобраћаја на 22 радна сервера довољан један који прихвата ову везу. Овде нам у помоћ прискаче алгоритам директног рутирања, алгоритам рутирања.
Како то изгледа? Наш фото директор, према својој табели, преноси везе на фото рутере. Али рутери за фотографије шаљу обрнути саобраћај директно на Интернет, шаљу га клијенту, он се не враћа назад кроз фото директор, тако да са минималним бројем машина обезбеђујемо пуну толеранцију грешака и пумпање целокупног саобраћаја. У конфигурацијама то изгледа овако: наводимо алгоритам, у нашем случају то је једноставан рр, дајемо метод директног рутирања, а затим почињемо да наводимо све праве сервере, колико их имамо. Што ће одредити овај саобраћај. У случају да имамо још један или два, неколико сервера се појављује тамо, јавља се таква потреба - једноставно додамо овај одељак у конфигурацију и не брините превише. Са стране правих сервера, са стране фото-рутера, овај метод захтева минималну конфигурацију, савршено је описан у документацији и ту нема никаквих замки.
Оно што је посебно пријатно јесте да овакво решење не подразумева корените промене локалне мреже, то нам је било важно, морали смо то да решимо уз минималне трошкове. Ако погледате онда ћемо видети како то изгледа. Овде имамо одређени виртуелни сервер, на порту 443, слуша, прихвата везу, сви сервери који раде су излистани и јасно је да је веза, плус-минус, иста. Ако погледамо статистику на истом виртуелном серверу, имамо долазне пакете, долазне везе, али апсолутно нема одлазних. Одлазне везе иду директно до клијента. Па, успели смо да избалансирамо. Сада, шта се дешава ако један од наших фото рутера поквари? На крају крајева, гвожђе је гвожђе. Може доћи до панике кернела, може се покварити, напајање може прегорети. Било шта. Томе служе здравствени прегледи. Оне могу бити једноставне као провера отворености порта код нас, или неке сложеније, све до неких самостално писаних скрипти које ће чак проверити пословну логику.
Зауставили смо се негде на средини: имамо хттпс захтев за одређену локацију, скрипта се позива ако одговори са 200. одговором, верујемо да је са овим сервером све у реду, да је жив и да се може лако укључити .
Како то, опет, изгледа у пракси. Искључен сервер, дозвољен за одржавање - флешовање БИОС-а, на пример. У евиденцији, одмах имамо тајм-аут, видимо први ред, затим се након три покушаја означава као „неуспео“ и једноставно се уклања са листе.
Могуће је и друго понашање, када се ВС једноставно подеси на нулу, али у случају враћања фотографије то не функционише добро. Сервер се подиже, тамо се покреће Нгинк, одмах провере здравља схватају да веза пролази, да је све у реду и сервер се појављује на нашој листи и оптерећење одмах почиње да се примењује на њега аутоматски. Нису потребне никакве ручне радње од дежурног администратора. Ноћу се сервер поново покренуо - одељење за праћење нас не зове у вези са овим ноћу. Јавили су вам шта се догодило, све је у реду.
Дакле, на прилично једноставан начин, уз помоћ малог броја сервера, решили смо проблем спољне толеранције грешака.
Остаје да се каже да све ово, наравно, треба пратити. Одвојено, треба напоменути да Кеепаливеде, као софтвер написан веома давно, има гомилу начина да га надгледа, оба помоћу провера преко ДБус-а, СМТП-а, СНМП-а и стандардног Заббик-а. Осим тога, он сам зна како да напише писма на скоро свако кијање, и да будемо искрени, у неком тренутку смо чак помислили да га искључимо, јер пише много писама за било који прекидач саобраћаја, укључивање, за сваки ИП-схник и тако даље . Наравно, ако има много сервера, онда се можете преплавити овим словима. Користећи стандардне методе, пратимо нгинк на фото рутерима, а надзор хардвера није нестао. Наравно, саветовали бисмо још две ствари: прво, спољне здравствене провере и доступност, јер чак и ако све функционише, у ствари, могуће је да корисници не добијају фотографије због проблема са спољним провајдерима или нечег сложенијег. Увек је вредно држати негде на другој мрежи, на Амазону или негде другде, засебну машину која може да пингује ваше сервере споља, а такође је вредно користити било детекцију аномалија, за оне који су добри у лукавом машинском учењу, или једноставно праћење, барем да би се пратило да ли су захтеви нагло пали, или обрнуто, порасли. Такође је корисно.
Да резимирамо: гвоздено решење, које нам је у једном тренутку престало да одговара, ми смо, у ствари, заменили прилично једноставним системом који све ради исто, односно обезбеђује прекид ХТТПС саобраћаја и даље паметно рутирање уз неопходно здравље -провере. Повећали смо стабилност овог система, односно и даље имамо високу доступност за сваки слој, плус добили смо бонус да је прилично лако све то скалирати на сваком слоју, јер је ово стандардни хардвер са стандардним софтвером, тј. , на тај начин смо поједноставили дијагностицирање могућих проблема.
Шта смо завршили? Имали смо проблем за јануарске празнике 2018. Током првих шест месеци, док смо ову шему пуштали у рад, ширили је на сав саобраћај, како бисмо уклонили сав саобраћај са ЛТМ-а, само у једном дата центру смо порасли саобраћај са 40 гигабита на 60 гигабита, а истовремено времена за целу 2018. годину били у могућности да дају скоро три пута више фотографија у секунди.
Извор: ввв.хабр.цом