Модерната мрежа е речиси незамислива без медиумска содржина: речиси секоја баба има паметен телефон, сите се на социјалните мрежи, а времето за одржување е скапо за компаниите. Еве препис од приказната на компанијата за тоа како ја организирала испораката на фотографии користејќи хардверско решение, со какви проблеми со изведбата наишла во процесот, што ги предизвикало и како овие проблеми биле решени користејќи софтверско решение базирано на Nginx, истовремено обезбедувајќи толеранција на грешки на сите нивоа (). Им благодариме на авторите на приказната на Олег Ефимова и Александра Димова, кои го споделија своето искуство на конференцијата .
— Да почнеме со мал вовед за тоа како ги складираме и кешираме фотографиите. Имаме слој каде што ги складираме и слој каде што ги кешираме фотографиите. Во исто време, ако сакаме да постигнеме висока стапка на трикови и да го намалиме оптоварувањето на складирањето, за нас е важно секоја фотографија од поединечен корисник да биде на еден кеширање сервер. Во спротивно, ќе моравме да инсталираме толку пати повеќе дискови колку што имаме повеќе сервери. Нашата стапка на трикови е околу 99%, односно, го намалуваме оптоварувањето на нашиот склад за 100 пати, а за да го направиме тоа, пред 10 години, кога се градеше сето ова, имавме 50 сервери. Според тоа, за да ги сервираме овие фотографии, ни требаа суштински 50 надворешни домени кои ги опслужуваат овие сервери.
Секако, веднаш се појави прашањето: ако некој од нашите сервери се спушти и стане недостапен, кој дел од сообраќајот го губиме? Разгледавме што има на пазарот и решивме да купиме хардвер за да ни ги реши сите проблеми. Изборот падна на решението на компанијата со мрежата F5 (која, патем, неодамна ја купи NGINX, Inc): BIG-IP Local Traffic Manager.
Она што го прави овој хардвер (LTM): тоа е железен рутер што прави вишок железо од неговите надворешни порти и ви овозможува да го насочувате сообраќајот врз основа на мрежната топологија, на некои поставки и прави здравствени проверки. Нам ни беше важно ова парче хардвер да може да се програмира. Соодветно на тоа, би можеле да ја опишеме логиката за тоа како фотографиите на одреден корисник се сервираат од одреден кеш. Како изгледа? Има парче хардвер што гледа на Интернет на еден домен, една IP, прави ssl offload, анализира http барања, избира кеш број од IRule, каде да оди и дозволува сообраќајот да оди таму. Истовремено, прави здравствени проверки, а во случај некоја машина да биде недостапна, во тоа време го направивме сообраќајот да оди на еден резервен сервер. Од конфигурациска гледна точка, има, се разбира, некои нијанси, но генерално сè е прилично едноставно: регистрираме картичка, кореспонденција на одреден број на нашата IP на мрежата, велиме дека ќе слушаме на портите 80 и 443, велиме дека ако серверот е недостапен, тогаш треба да испратите сообраќај до резервниот, во случајов 35-тиот, и опишуваме куп логика за тоа како треба да се расклопи оваа архитектура. Единствениот проблем беше што јазикот на кој беше програмиран хардверот беше Tcl. Ако некој воопшто се сеќава на ова... овој јазик е повеќе само за пишување отколку јазик погоден за програмирање:
Што добивме? Добивме парче хардвер што обезбедува висока достапност на нашата инфраструктура, го насочува целиот наш сообраќај, обезбедува здравствени придобивки и само работи. Покрај тоа, таа работи доста долго: во текот на изминатите 10 години немаше поплаки за тоа. До почетокот на 2018 година, веќе испраќавме околу 80 илјади фотографии во секунда. Ова е некаде околу 80 гигабити сообраќај од двата наши центри за податоци.
Сепак…
На почетокот на 2018 година, видовме грда слика на топ листите: времето потребно за испраќање фотографии јасно се зголеми. И престана да ни одговара. Проблемот е што ваквото однесување беше видливо само за време на шпицот на сообраќајот - за нашата компанија ова е ноќта од недела кон понеделник. Но, остатокот од времето системот се однесуваше како и обично, без знаци на неуспех.
Сепак, проблемот мораше да се реши. Утврдивме можни тесни грла и почнавме да ги елиминираме. Пред се, се разбира, ги проширивме надворешните линкови, извршивме целосна ревизија на внатрешните линкови и ги најдовме сите можни тесни грла. Но, сето ова не даде очигледен резултат, проблемот не исчезна.
Друго можно тесно грло беше изведбата на самите фото кешови. И решивме дека можеби проблемот е кај нив. Па, ги проширивме перформансите - главно мрежни порти на кешот на фотографии. Но, повторно не беше забележано очигледно подобрување. На крајот, обрнавме големо внимание на перформансите на самиот LTM и овде видовме тажна слика на графиконите: оптоварувањето на сите процесори почнува да оди непречено, но потоа одеднаш доаѓа до плато. Во исто време, LTM престанува да реагира соодветно на здравствените проверки и надоврзувањата и почнува случајно да ги исклучува, што доведува до сериозно влошување на перформансите.
Односно, го идентификувавме изворот на проблемот, го идентификувавме тесното грло. Останува да одлучиме што ќе правиме.
Првото, најочигледно нешто што можевме да го направиме е некако да го модернизираме самиот LTM. Но, тука има некои нијанси, бидејќи овој хардвер е прилично уникатен, нема да одите до најблискиот супермаркет и да го купите. Ова е посебен договор, посебен договор за лиценца и ќе потрае многу време. Втората опција е да почнете да размислувате сами, да излезете со сопствено решение користејќи ги вашите сопствени компоненти, по можност користејќи програма за отворен пристап. Останува само да одлучиме што точно ќе избереме за ова и колку време ќе потрошиме за решавање на овој проблем, бидејќи корисниците не добиваа доволно фотографии. Затоа, сето ова треба да го направиме многу, многу брзо, може да се каже вчера.
Бидејќи задачата звучеше како „направете нешто што е можно побрзо и користејќи го хардверот што го имаме“, првото нешто што помисливме беше едноставно да отстраниме некои не многу моќни машини од предната страна, да го ставиме Nginx таму, со кој знаеме како да работете и обидете се да ја имплементирате истата логика што ја правеше хардверот. Тоа е, всушност, го оставивме нашиот хардвер, инсталиравме уште 4 сервери кои требаше да ги конфигурираме, им создадовме надворешни домени, слично како што беше пред 10 години... Малку изгубивме во достапноста ако паднеа овие машини, но уште помалку, локално го решија проблемот на нашите корисници.
Соодветно на тоа, логиката останува иста: инсталираме Nginx, може да направи SSL-offload, можеме некако да ја програмираме логиката на рутирање, здравствени проверки во конфигурациите и едноставно да ја дуплираме логиката што ја имавме претходно.
Ајде да седнеме да пишуваме конфигурации. На почетокот се чинеше дека сè е многу едноставно, но, за жал, многу е тешко да се најдат прирачници за секоја задача. Затоа, не препорачуваме едноставно гуглање „како да го конфигурирате Nginx за фотографии“: подобро е да се повикате на официјалната документација, која ќе покаже кои поставки треба да се допрат. Но, подобро е сами да го изберете конкретниот параметар. Па, тогаш сè е едноставно: ги опишуваме серверите што ги имаме, ги опишуваме сертификатите... Но, најинтересно е, всушност, самата логика на рутирање.
Отпрвин ни се чинеше дека едноставно ја опишуваме нашата локација, го совпаѓаме бројот на нашата фото-кеш во неа, ги користиме рацете или генератор за да опишеме колку возводни води ни требаат, во секој возводно го посочуваме серверот до кој треба да има сообраќај. оди и резервен сервер - ако главниот сервер не е достапен:
Но, веројатно, да беше сè толку едноставно, едноставно ќе си одевме дома и немаше да кажеме ништо. За жал, со стандардните Nginx поставки, кои, генерално, беа направени во текот на многу години на развој и не се целосно соодветни за овој случај... конфигурацијата изгледа вака: ако некој upstream сервер има грешка во барањето или истек на време, Nginx секогаш го префрла сообраќајот на следниот. Покрај тоа, по првиот неуспех, во рок од 10 секунди серверот исто така ќе биде исклучен, и по грешка и со истек - ова дури и не може да се конфигурира на кој било начин. Односно, ако ја отстраниме или ресетираме опцијата за истекот на времето во директивата нагоре, тогаш, иако Nginx нема да го обработи ова барање и ќе одговори со некоја не многу добра грешка, серверот ќе се исклучи.
За да го избегнеме ова, направивме две работи:
а) тие му забранија на Nginx да го прави ова рачно - и за жал, единствениот начин да го направите ова е едноставно да ги поставите поставките за максимум неуспех.
б) се сетивме дека во други проекти користиме модул што ни овозможува да правиме здравствени проверки во позадина - соодветно, правевме доста чести здравствени проверки, така што времето на застој во случај на несреќа ќе биде минимално.
За жал, ни ова не е сè, бидејќи буквално првите две недели од работењето на оваа шема покажаа дека проверката на здравјето на TCP е исто така несигурна работа: на серверот нагоре можеби не е Nginx или Nginx во D-состојба, а во во овој случај кернелот ќе ја прифати врската, здравствената проверка ќе помине, но нема да работи. Затоа, веднаш го заменивме ова со здравствена проверка http, направивме специфичен, кој ако врати 200, тогаш сè работи во оваа скрипта. Можете да направите дополнителна логика - на пример, во случај на кеширање на сервери, проверете дали датотечниот систем е правилно монтиран:
И ова ќе ни одговара, освен што во моментот колото целосно го повтори она што го направи хардверот. Но, сакавме да направиме подобро. Претходно, имавме еден резервен сервер, и ова веројатно не е многу добро, бидејќи ако имате сто сервери, тогаш кога неколку не успеат одеднаш, еден резервен сервер веројатно нема да се справи со оптоварувањето. Затоа, решивме да ја дистрибуираме резервацијата на сите сервери: едноставно направивме друг посебен возводно, ги напишавме сите сервери таму со одредени параметри во согласност со оптоварувањето што можат да го послужат, ги додадовме истите здравствени проверки што ги имавме претходно:
Бидејќи е невозможно да се оди на друг возводно во рамките на една возводно, неопходно беше да се увериме дека ако главната спротиводно, во која едноставно го снимивме точниот, неопходен фото кеш, е недостапна, едноставно отидовме преку error_page до резервна, од каде отидовме во резервната резервна копија горе:
И со буквално додавање на четири сервери, еве што добивме: заменивме дел од товарот - го отстранивме од LTM на овие сервери, ја имплементиравме истата логика таму, користејќи стандарден хардвер и софтвер и веднаш го добивме бонусот што овие сервери можат да бидат намалени, бидејќи тие можат едноставно да се снабдуваат онолку колку што е потребно. Па, единствената негатива е што изгубивме висока достапност за надворешни корисници. Но, во тој момент моравме да го жртвуваме ова, бидејќи беше неопходно веднаш да се реши проблемот. Така, отстранивме дел од товарот, тоа беше околу 40% во тоа време, LTM се чувствуваше добро, и буквално две недели откако започна проблемот, почнавме да испраќаме не 45k барања во секунда, туку 55k. Всушност, пораснавме за 20% - ова е јасно сообраќајот што не му го дадовме на корисникот. И после тоа почнаа да размислуваат како да го решат преостанатиот проблем - да обезбедат висока надворешна пристапност.
Имавме одредена пауза, при што разговаравме какво решение ќе користиме за ова. Имаше предлози да се обезбеди сигурност со користење на DNS, користење на некои домашно напишани скрипти, протоколи за динамично рутирање... имаше многу опции, но веќе стана јасно дека за навистина сигурна испорака на фотографии, треба да воведете друг слој што ќе го следи ова . Овие машини ги нарековме фоторежисери. Софтверот на кој се потпиравме беше Keepalived:
За почеток, од што се состои Keepalived? Првиот е протоколот VRRP, широко познат на мрежните лица, лоциран на мрежна опрема што обезбедува толеранција на дефекти на надворешната IP адреса на која се поврзуваат клиентите. Вториот дел е IPVS, IP виртуелен сервер, за балансирање помеѓу фото-рутери и обезбедување на толеранција на грешки на ова ниво. И трето - здравствени проверки.
Да почнеме со првиот дел: VRRP - како изгледа? Постои одредена виртуелна IP адреса, која има запис во dns badoocdn.com, каде што клиентите се поврзуваат. Во одреден момент во времето, имаме IP адреса на еден сервер. Keepalived пакетите се извршуваат помеѓу серверите со помош на протоколот VRRP, и ако господарот исчезне од радарот - серверот се рестартира или нешто друго, тогаш резервниот сервер автоматски ја зема оваа IP адреса - не се потребни рачни дејства. Разликата помеѓу мастер и резервна копија е главно приоритетна: колку е поголема, толку е поголема шансата машината да стане господар. Многу голема предност е што не треба да ги конфигурирате IP адресите на самиот сервер, доволно е да ги опишете во конфигурацијата, а ако на IP адресите им требаат некои сопствени правила за рутирање, ова е опишано директно во конфигурацијата, користејќи ја истата синтакса како што е опишано во пакетот VRRP. Нема да наидете на непознати работи.
Како изгледа ова во пракса? Што се случува ако еден од серверите не успее? Штом господарот исчезне, нашата резервна копија престанува да прима реклами и автоматски станува господар. По некое време, го поправивме главниот, рестартиравме, подигнавме Keepalived - рекламите пристигнуваат со повисок приоритет од резервната копија, а резервната копија автоматски се враќа назад, ги отстранува IP адресите, не треба да се прават рачни дејства.
Така, обезбедивме толеранција на дефекти на надворешната IP адреса. Следниот дел е некако да се балансира сообраќајот од надворешната IP адреса до фото-рутерите кои веќе го прекинуваат. Сè е сосема јасно со протоколите за балансирање. Ова е или едноставен круг, или малку посложени работи, wrr, поврзување со листа и така натаму. Ова во основа е опишано во документацијата, нема ништо посебно. Но, начинот на испорака... Овде ќе разгледаме подетално зошто избравме еден од нив. Тоа се NAT, Direct Routing и TUN. Факт е дека веднаш планиравме да испорачаме 100 гигабити сообраќај од сајтовите. Ако процените, ви требаат 10 гигабитни картички, нели? 10 гигабитни картички во еден сервер веќе се надвор од опсегот на, барем, нашиот концепт на „стандардна опрема“. И тогаш се сетивме дека не подаруваме само сообраќај, туку и фотографии.
Што е посебно? — Огромна разлика помеѓу дојдовниот и појдовниот сообраќај. Дојдовниот сообраќај е многу мал, појдовниот сообраќај е многу голем:
Ако ги погледнете овие графикони, можете да видите дека во моментот директорот добива околу 200 MB во секунда, ова е многу обичен ден. Ние враќаме 4,500 MB во секунда, нашиот сооднос е приближно 1/22. Веќе е јасно дека за целосно да обезбедиме појдовен сообраќај до 22 работнички сервери, потребен ни е само еден што ја прифаќа оваа врска. Тука ни доаѓа на помош алгоритмот за директно рутирање.
Како изгледа? Нашиот фото-директор, според неговата табела, пренесува врски со фото-рутери. Но, фото-рутерите испраќаат повратен сообраќај директно на Интернет, го испраќаат до клиентот, тој не се враќа назад преку фото-директорот, така што, со минимален број машини, обезбедуваме целосна толеранција на дефекти и пумпање на целиот сообраќај. Во конфигурациите изгледа вака: го одредуваме алгоритмот, во нашиот случај тоа е едноставен rr, обезбедуваме метод на директно рутирање и потоа почнуваме да ги наведуваме сите вистински сервери, колку од нив имаме. Што ќе го одреди овој сообраќај. Ако имаме уште еден или два сервери таму или неколку сервери, се појавува таква потреба - само го додаваме овој дел во конфигурацијата и не грижете се премногу. Од страната на вистинските сервери, од страната на фото-рутерот, овој метод бара најминимална конфигурација, тој е совршено опишан во документацијата и нема никакви замки.
Она што е особено убаво е што ваквото решение не подразбира радикален редизајн на локалната мрежа; ова беше важно за нас; моравме да го решиме ова со минимални трошоци. Ако погледнете во , тогаш ќе видиме како изгледа. Овде имаме одреден виртуелен сервер, на порта 443, слуша, ја прифаќа конекцијата, се наведени сите сервери кои работат и може да се види дека конекцијата е, дај или земи, иста. Ако ја погледнеме статистиката на истиот виртуелен сервер, имаме дојдовни пакети, дојдовни конекции, но апсолутно нема појдовни. Појдовните врски одат директно до клиентот. Во ред, успеавме да го дебалансираме. Сега, што ќе се случи ако еден од нашите фото-рутери не успее? На крајот на краиштата, железото е железо. Може да влезе во паника на јадрото, може да се скрши, напојувањето може да изгори. Било што. Затоа се потребни здравствени проверки. Тие можат да бидат едноставни како проверка како е отворена портата, или нешто покомплексно, до некои домашни напишани скрипти кои дури ќе ја проверат деловната логика.
Застанавме некаде на средина: имаме барање https до одредена локација, се вика скриптата, ако одговори со 200-ти одговор, веруваме дека се е во ред со овој сервер, дека е жив и може да се вклучи доста лесно.
Како изгледа ова, повторно, во пракса? Ајде да го исклучиме серверот за одржување - трепкање на BIOS-от, на пример. Во дневниците веднаш имаме тајмаут, ја гледаме првата линија, потоа по три обиди се означува како „неуспешно“ и едноставно се отстранува од списокот.
Можна е и втора опција за однесување, кога VS е едноставно поставена на нула, но ако фотографијата се врати, ова не функционира добро. Серверот се појавува, Nginx започнува таму, здравствената проверка веднаш разбира дека врската работи, дека сè е во ред, и серверот се појавува во нашата листа, а товарот веднаш почнува да се применува на него. Не се потребни никакви рачни дејства од дежурниот администратор. Серверот се рестартира ноќе - одделот за следење не ни се јавува за ова ноќе. Ве информираат дека ова се случило, се е во ред.
Така, на прилично едноставен начин, со помош на мал број сервери, го решивме проблемот со надворешната толеранција на дефекти.
Останува само да се каже дека сето ова, се разбира, треба да се следи. Одделно, треба да се забележи дека Keepalivede, како софтвер напишан одамна, има куп начини за негово следење, и со помош на проверки преку DBus, SMTP, SNMP и стандарден Zabbix. Плус, тој самиот знае да пишува букви за скоро секое кивавица, а да бидам искрен, во одреден момент дури помисливме да го исклучиме, бидејќи пишува многу букви за секое префрлување, вклучување, за секоја IP конекција. и така натаму. Се разбира, ако има многу сервери, тогаш можете да се преоптоварите со овие букви. Ние го следиме nginx на фото-рутери користејќи стандардни методи, а хардверскиот мониторинг не исчезна. Се разбира, би советувале уште две работи: прво, надворешни здравствени проверки и достапност, бидејќи дури и ако сè функционира, всушност, корисниците можеби не добиваат фотографии поради проблеми со надворешни провајдери или нешто покомплексно. Секогаш вреди да се задржи некаде на друга мрежа, во Амазон или на друго место, посебна машина што може да ги пингува вашите сервери однадвор, а исто така вреди да се користи или откривање аномалија, за оние кои знаат како да прават незгодно машинско учење или едноставно следење , барем за да се следи дали барањата нагло се намалиле, или, напротив, се зголемиле. Може да биде и корисно.
Да резимираме: ние, всушност, го заменивме решението обложено со железо, кое во одреден момент престана да ни одговара, со прилично едноставен систем кој прави сè исто, односно обезбедува прекин на сообраќајот HTTPS и дополнително паметно рутирање со неопходни здравствени проверки. Ја зголемивме стабилноста на овој систем, односно сè уште имаме висока достапност за секој слој, плус имаме бонус што е прилично лесно да се скалира сето тоа на секој слој, бидејќи тоа е стандарден хардвер со стандарден софтвер, т.е. , го поедноставивме дијагностицирањето на можните проблеми.
Со што завршивме? Имавме проблем за време на јануарските празници во 2018 година. Во првите шест месеци додека ја ставивме оваа шема во функција, ја проширивме на целиот сообраќај со цел да го отстраниме целиот сообраќај од LTM, пораснавме само во сообраќајот во еден центар за податоци од 40 гигабити на 60 гигабити, а во исто време за цела 2018 година беа во можност да испратат речиси три пати повеќе фотографии во секунда.
Извор: www.habr.com