Здраво, Хабр! Ја сам Артем Карамисхев, шеф тима за системску администрацију . Имали смо много лансирања нових производа током прошле године. Желели смо да обезбедимо да АПИ услуге буду лако скалабилне, толерантне на грешке и спремне за брзи раст броја корисника. Наша платформа је имплементирана на ОпенСтацк-у и желим да вам кажем које проблеме толеранције грешака компоненти смо морали да решимо да бисмо добили систем отпоран на грешке. Мислим да ће ово бити интересантно за оне који такође развијају производе на ОпенСтацк-у.
Укупна отпорност на грешке платформе састоји се од отпорности њених компоненти. Тако да ћемо постепено пролазити кроз све нивое на којима смо идентификовали ризике и затворили их.
Видео верзија ове приче, чији је примарни извор био извештај са конференције Уптиме даи 4, коју је организовао , можете видети .
Отпорност физичке архитектуре
Јавни део МЦС облака је сада базиран у два Тиер ИИИ дата центра, између њих постоји сопствено тамно влакно, резервисано на физичком нивоу различитим рутама, са пропусношћу од 200 Гбит/с. Ниво ИИИ обезбеђује неопходан ниво толеранције на грешке за физичку инфраструктуру.
Тамна влакна су резервисана и на физичком и на логичком нивоу. Процес резервације канала је био итеративан, појавили су се проблеми и стално побољшавамо комуникацију између дата центара.
На пример, не тако давно, док је радио у бунару у близини једног од дата центара, багер је сломио цев, а унутар ове цеви је био и главни и резервни оптички кабл. Наш комуникациони канал отпоран на грешке са центром података показао се рањивим у једном тренутку, у бушотини. Сходно томе, изгубили смо део инфраструктуре. Извукли смо закључке и предузели низ радњи, укључујући уградњу додатне оптике у суседни бунар.
У дата центрима постоје тачке присуства комуникационих провајдера којима емитујемо наше префиксе преко БГП-а. За сваки мрежни правац бира се најбоља метрика, која омогућава различитим клијентима да добију најбољи квалитет везе. Ако комуникација преко једног провајдера нестане, поново градимо наше рутирање преко доступних провајдера.
Ако провајдер не успе, аутоматски прелазимо на следећег. У случају квара једног од дата центара, имамо пресликану копију наших услуга у другом дата центру, који преузимају целокупно оптерећење.
Отпорност физичке инфраструктуре
Оно што користимо за толеранцију грешака на нивоу апликације
Наша услуга је изграђена на бројним компонентама отвореног кода.
ЕкаБГП је услуга која имплементира бројне функције користећи БГП базиран динамички протокол рутирања. Активно га користимо за оглашавање наших ИП адреса са беле листе преко којих корисници приступају АПИ-ју.
ХАПроки је балансатор високог оптерећења који вам омогућава да конфигуришете веома флексибилна правила балансирања саобраћаја на различитим нивоима ОСИ модела. Користимо га за балансирање испред свих сервиса: база података, брокера порука, АПИ сервиса, веб сервиса, наших интерних пројеката - све је иза ХАПроки-а.
АПИ апликација — веб апликација написана на питону, помоћу које корисник управља својом инфраструктуром и својим сервисом.
Радничка пријава (у даљем тексту једноставно радник) - у ОпенСтацк услугама, ово је инфраструктурни демон који вам омогућава да емитујете АПИ команде на инфраструктуру. На пример, креирање диска се дешава у воркер-у, а захтев за креирање се јавља у АПИ-ју апликације.
Стандардна ОпенСтацк архитектура апликације
Већина услуга које су развијене за ОпенСтацк покушавају да прате једну парадигму. Сервис се обично састоји од 2 дела: АПИ-ја и радника (бацкенд екецуторс). По правилу, АПИ је ВСГИ апликација у Питхон-у, која се покреће или као независан процес (даемон), или помоћу готовог Нгинк или Апацхе веб сервера. АПИ обрађује кориснички захтев и прослеђује даље инструкције радној апликацији за извршење. Пренос се врши помоћу посредника порука, обично РаббитМК, остали су слабо подржани. Када поруке стигну до брокера, радници их обрађују и, ако је потребно, враћају одговор.
Ова парадигма укључује изоловане заједничке тачке неуспеха: РаббитМК и базу података. Али РаббитМК је изолован у оквиру једне услуге и, у теорији, може бити индивидуалан за сваку услугу. Тако у МЦС-у раздвајамо ове услуге колико год је то могуће; за сваки појединачни пројекат креирамо засебну базу података, засебан РаббитМК. Овај приступ је добар јер се у случају незгоде на неким рањивим тачкама не квари цео сервис, већ само део.
Број радних апликација је неограничен, тако да се АПИ може лако хоризонтално скалирати иза балансера како би се повећале перформансе и толеранција грешака.
Неке услуге захтевају координацију унутар услуге када се између АПИ-ја и радника јављају сложене секвенцијалне операције. У овом случају се користи један координациони центар, кластер систем као што су Редис, Мемцацхе, итд, који омогућава једном раднику да каже другом да му је овај задатак додељен („молим немој да га узимаш“). Користимо етцд. По правилу, радници активно комуницирају са базом података, пишу и читају информације одатле. Користимо мариадб као базу података, која се налази у мултимастер кластеру.
Ова класична појединачна услуга организована је на начин који је општеприхваћен за ОпенСтацк. Може се сматрати затвореним системом, за који су методе скалирања и толеранције грешака прилично очигледне. На пример, за толеранцију грешака АПИ-ја, довољно је ставити балансер испред њих. Скалирање радника постиже се повећањем њиховог броја.
Слаба тачка у целој шеми су РаббитМК и МариаДБ. Њихова архитектура заслужује посебан чланак.У овом чланку желим да се фокусирам на толеранцију грешака АПИ-ја.
Архитектура Опенстацк апликација. Балансирање и толеранција грешака клауд платформе
Прављење ХАПроки балансера отпорним на грешке користећи ЕкаБГП
Да би наши АПИ-ји били скалабилни, брзи и толерантни на грешке, стављамо балансер оптерећења испред њих. Изабрали смо ХАПроки. По мом мишљењу, има све потребне карактеристике за наш задатак: балансирање на неколико ОСИ нивоа, интерфејс за управљање, флексибилност и скалабилност, велики број метода балансирања, подршку за табеле сесија.
Први проблем који је требало решити била је толеранција грешака самог балансера. Једноставно инсталирање балансера такође ствара тачку квара: балансер се поквари и услуга се руши. Да бисмо спречили да се то догоди, користили смо ХАПроки заједно са ЕкаБГП.
ЕкаБГП вам омогућава да имплементирате механизам за проверу стања услуге. Користили смо овај механизам да проверимо функционалност ХАПроки-а и, у случају проблема, онемогућимо ХАПроки услугу из БГП-а.
ЕкаБГП+ХАПроки шема
- Инсталирамо потребан софтвер ЕкаБГП и ХАПроки на три сервера.
- На сваком серверу креирамо лоопбацк интерфејс.
- На сва три сервера овом интерфејсу додељујемо исту белу ИП адресу.
- Бела ИП адреса се оглашава на Интернету преко ЕкаБГП-а.
Толеранција грешака се постиже оглашавањем исте ИП адресе са сва три сервера. Са тачке гледишта мреже, истој адреси се може приступити са три различита следећа скока. Рутер види три идентичне руте, бира највећи приоритет од њих на основу сопствене метрике (ово је обично иста опција), а саобраћај иде само на један од сервера.
У случају проблема са радом ХАПроки-а или квара сервера, ЕкаБГП престаје да најављује руту, а саобраћај се глатко пребацује на други сервер.
Тиме смо постигли отпорност на грешке балансера.
Толеранција грешака ХАПроки балансера
Показало се да је шема несавршена: научили смо како да резервишемо ХАПроки, али нисмо научили како да распоредимо оптерећење унутар услуга. Стога смо ову шему мало проширили: прешли смо на балансирање између неколико белих ИП адреса.
Балансирање засновано на ДНС плус БГП
Питање балансирања оптерећења за наш ХАПроки остаје нерешено. Међутим, то се може решити прилично једноставно, као што смо то урадили овде.
За балансирање три сервера биће вам потребне 3 беле ИП адресе и стари добри ДНС. Свака од ових адреса се одређује на интерфејсу повратне петље сваког ХАПроки сервера и оглашава се на Интернету.
У ОпенСтацк-у, за управљање ресурсима, користи се сервисни директоријум који наводи АПИ крајње тачке одређене услуге. У овом директоријуму региструјемо име домена - публиц.инфра.маил.ру, које се преко ДНС-а решава са три различите ИП адресе. Као резултат, добијамо расподелу оптерећења између три адресе преко ДНС-а.
Али пошто приликом објављивања белих ИП адреса не контролишемо приоритете избора сервера, ово још увек није балансирање. Обично ће само један сервер бити изабран на основу сениоритета ИП адресе, а друга два ће бити неактивна јер у БГП-у нису наведене метрике.
Почели смо да шаљемо руте преко ЕкаБГП-а са различитим метрикама. Сваки балансер рекламира све три беле ИП адресе, али једна од њих, главна за овај балансер, се оглашава са минималном метриком. Дакле, док су сва три балансера у функцији, позиви на прву ИП адресу иду на први балансер, позиви на други на други, а позиви на трећу на трећу.
Шта се дешава када један од балансера падне? Ако било који балансер поквари, његова главна адреса се и даље оглашава са друга два, а саобраћај се редистрибуира између њих. Тако дајемо кориснику неколико ИП адреса одједном преко ДНС-а. Балансирањем помоћу ДНС-а и различитих метрика, добијамо равномерну расподелу оптерећења на сва три балансера. И у исто време не губимо толеранцију на грешке.
Балансирање ХАПроки-а на основу ДНС + БГП
Интеракција између ЕкаБГП и ХАПроки
Дакле, имплементирали смо толеранцију грешака у случају да сервер напусти, на основу заустављања најаве рута. Али ХАПроки може да се угаси из других разлога осим грешке сервера: грешке администрације, кварови унутар услуге. И у овим случајевима желимо да уклонимо покварени баланс испод оптерећења и потребан нам је другачији механизам.
Стога смо, проширујући претходну шему, имплементирали откуцаје срца између ЕкаБГП и ХАПроки. Ово је софтверска имплементација интеракције између ЕкаБГП и ХАПроки, када ЕкаБГП користи прилагођене скрипте за проверу статуса апликација.
Да бисте то урадили, потребно је да конфигуришете проверу здравља у ЕкаБГП конфигурацији, која може да провери статус ХАПроки. У нашем случају, конфигурисали смо позадину здравља у ХАПроки-у, а са ЕкаБГП стране проверавамо једноставним ГЕТ захтевом. Ако најава престане да се дешава, онда ХАПроки највероватније не ради и нема потребе да га оглашавате.
ХАПроки провера здравља
ХАПроки Пеерс: синхронизација сесије
Следеће што је требало да урадите је да синхронизујете сесије. Када радите преко дистрибуираних балансера, тешко је организовати складиштење информација о клијентским сесијама. Али ХАПроки је један од ретких балансера који то могу да ураде захваљујући Пеерс функционалности – могућности преноса табела сесија између различитих ХАПроки процеса.
Постоје различите методе балансирања: једноставне као нпр , и продужен, када се сесија клијента запамти, и сваки пут када заврши на истом серверу као и раније. Желели смо да применимо другу опцију.
ХАПроки користи стицк-табеле да би сачувао клијентске сесије овог механизма. Они чувају оригиналну ИП адресу клијента, изабрану циљну адресу (позадину) и неке информације о услузи. Типично, стицк табеле се користе за складиштење пара извор-ИП + одредиште-ИП, што је посебно корисно за апликације које не могу да пренесу контекст корисничке сесије када се пребаце на други балансер, на пример, у РоундРобин режиму балансирања.
Ако се табела са штапом научи да се креће између различитих ХАПроки процеса (између којих се дешава балансирање), наши балансери ће моћи да раде са једним скупом штап табела. Ово ће омогућити неприметно пребацивање клијентове мреже ако један од балансера не успе; рад са клијентским сесијама ће се наставити на истим позадинским системима који су раније изабрани.
За правилан рад, проблем изворне ИП адресе балансера са којег је успостављена сесија мора бити решен. У нашем случају, ово је динамичка адреса на интерфејсу повратне петље.
Исправан рад вршњака постиже се само под одређеним условима. То јест, временска ограничења ТЦП-а морају бити довољно велика или пребацивање мора бити довољно брзо тако да ТЦП сесија нема времена да се заврши. Међутим, омогућава беспрекорно пребацивање.
У ИааС-у имамо услугу изграђену користећи исту технологију. Ово , која се зове Октавија. Заснован је на два ХАПроки процеса и у почетку укључује подршку за колеге. Одлично су се доказали у овој служби.
Слика шематски приказује кретање равноправних табела између три ХАПроки инстанце, предложена је конфигурација како се ово може конфигурисати:
ХАПроки Пеерс (синхронизација сесије)
Ако имплементирате исту шему, њен рад мора бити пажљиво тестиран. Није чињеница да ће радити на исти начин 100% времена. Али барем нећете изгубити штап табеле када треба да запамтите клијентов изворни ИП.
Ограничавање броја истовремених захтева од истог клијента
Све услуге које су јавно доступне, укључујући наше АПИ-је, могу бити предмет лавина захтева. Разлози за њих могу бити потпуно различити, од грешака корисника до циљаних напада. Ми смо периодично ДДоСед ИП адресама. Клијенти често праве грешке у својим скриптама и дају нам мини-ДДоС-ове.
На овај или онај начин, мора се обезбедити додатна заштита. Очигледно решење је ограничити број АПИ захтева и не губити ЦПУ време на обраду злонамерних захтева.
Да бисмо применили таква ограничења, користимо ограничења стопе, организована на основу ХАПроки-а, користећи исте штап табеле. Постављање ограничења је прилично једноставно и омогућава вам да ограничите корисника бројем захтева ка АПИ-ју. Алгоритам памти изворну ИП адресу са које се упућују захтеви и ограничава број истовремених захтева од једног корисника. Наравно, израчунали смо просечни профил оптерећења АПИ-ја за сваку услугу и поставили ограничење од ≈ 10 пута ове вредности. Настављамо да помно пратимо ситуацију и држимо прст на пулсу.
Како ово изгледа у пракси? Имамо клијенте који стално користе наше АПИ-је за аутоматско скалирање. Ујутру креирају отприлике две до три стотине виртуелних машина, а увече их бришу. За ОпенСтацк, креирање виртуелне машине, такође са ПааС услугама, захтева најмање 1000 АПИ захтева, пошто се интеракција између услуга такође дешава преко АПИ-ја.
Такав пренос задатака узрокује прилично велико оптерећење. Процијенили смо ово оптерећење, прикупили дневне пикове, повећали их десет пута и то је постало наша граница стопе. Држимо прст на пулсу. Често виђамо ботове и скенере који покушавају да нас погледају да виде да ли имамо неку ЦГА скрипту која се може покренути, ми их активно сечемо.
Како да ажурирате своју базу кодова, а да корисници то не примете
Такође имплементирамо толеранцију грешака на нивоу процеса имплементације кода. Може доћи до кварова током увођења, али њихов утицај на доступност услуге може бити минимизиран.
Стално ажурирамо наше услуге и морамо осигурати да се база кодова ажурира без утицаја на кориснике. Успели смо да решимо овај проблем коришћењем могућности управљања ХАПроки-а и имплементације Грацефул Схутдовн-а у нашим сервисима.
Да би се решио овај проблем, било је неопходно обезбедити контролу балансера и „исправно“ гашење услуга:
- У случају ХАПроки-а, контрола се врши преко статистичке датотеке, која је у суштини сокет и дефинисана је у ХАПроки конфигурацији. Можете му послати команде путем стдио-а. Али наш главни алат за контролу конфигурације је ансибле, тако да има уграђени модул за управљање ХАПроки-ом. Које активно користимо.
- Већина наших услуга АПИ-ја и Енгине-а подржавају грациозне технологије искључивања: када се искључују, чекају да се тренутни задатак заврши, било да се ради о хттп захтеву или неком сервисном задатку. Иста ствар се дешава и са радником. Зна све задатке које обавља и завршава када све успешно заврши.
Захваљујући ове две тачке, безбедан алгоритам за наше распоређивање изгледа овако.
- Програмер саставља нови пакет кода (за нас је ово РПМ), тестира га у дев окружењу, тестира га у фази и оставља у спремишту фазе.
- Програмер поставља задатак за примену са најдетаљнијим описом „артефаката“: верзијом новог пакета, описом нове функционалности и другим детаљима о примени ако је потребно.
- Администратор система започиње ажурирање. Покреће Ансибле плаибоок, који заузврат ради следеће:
- Узима пакет из спремишта фазе и користи га за ажурирање верзије пакета у спремишту производа.
- Саставља листу позадина ажуриране услуге.
- Искључује прву услугу која се ажурира у ХАПроки-у и чека да се њени процеси заврше са радом. Захваљујући грациозном затварању, уверени смо да ће сви тренутни захтеви клијената бити успешно завршени.
- Након што су АПИ и радници потпуно заустављени, а ХАПроки искључен, код се ажурира.
- Ансибле покреће услуге.
- За сваку услугу се повлаче одређене „ручице“, које врше тестирање јединица на низу унапред дефинисаних кључних тестова. Основна провера новог кода се одвија.
- Ако у претходном кораку није пронађена ниједна грешка, позадински део се активира.
- Пређимо на следећи бацкенд.
- Након што се ажурирају сви бацкендови, покрећу се функционални тестови. Ако недостају, програмер прегледа сваку нову функционалност коју је направио.
Ово завршава распоређивање.
Циклус ажурирања услуге
Ова шема не би функционисала да немамо једно правило. Подржавамо и стару и нову верзију у борби. Унапред, у фази развоја софтвера, прописано је да чак и ако дође до промена у бази података услуге, оне неће разбити претходни код. Као резултат, база кодова се постепено ажурира.
Закључак
Делећи своја размишљања о ВЕБ архитектури отпорној на грешке, желео бих још једном да приметим њене кључне тачке:
- физичка толеранција грешака;
- толеранција на грешке мреже (балансери, БГП);
- толеранција грешака коришћеног и развијеног софтвера.
Свима стабилно време рада!
Извор: ввв.хабр.цом
