Како су приоритети под у Кубернетес-у изазвали застоје у Графана Лабс-у

Белешка. трансл.: Представљамо вашој пажњи техничке детаље о разлозима недавног застоја у цлоуд сервису који су одржавали креатори Графане. Ово је класичан пример како нова и наизглед изузетно корисна карактеристика дизајнирана да побољша квалитет инфраструктуре... може нанети штету ако не обезбедите бројне нијансе њене примене у стварности производње. Сјајно је када се појаве овакви материјали који вам омогућавају да учите не само на својим грешкама. Детаљи су у преводу овог текста од потпредседника производа Графана Лабс.

Како су приоритети под у Кубернетес-у изазвали застоје у Графана Лабс-у

У петак, 19. јула, услуга Хостед Прометхеус у Графана Цлоуду престала је да функционише на отприлике 30 минута. Извињавам се свим купцима погођеним прекидом рада. Наш посао је да обезбедимо алате за праћење који су вам потребни, а ми разумемо да ако их немате на располагању, то вам може отежати живот. Овај инцидент схватамо изузетно озбиљно. Ова белешка објашњава шта се догодило, како смо реаговали и шта радимо да се то више не догоди.

praistorija

Графана Цлоуд Хостед Прометхеус услуга је заснована на Кортекс — ЦНЦФ пројекат за креирање хоризонтално скалабилног, високо доступног Прометхеус услуге са више закупаца. Архитектура Цортек-а се састоји од скупа појединачних микросервиса, од којих свака обавља своју функцију: репликацију, складиштење, упите итд. Цортек је у активном развоју и стално додаје нове функције и побољшава перформансе. Редовно примењујемо нова издања Цортек-а у кластере тако да купци могу да искористе предности ових функција - на срећу, Цортек се може ажурирати без застоја.

За беспрекорна ажурирања, услуга Ингестер Цортек захтева додатну Ингестер реплику током процеса ажурирања. (Белешка. трансл.: Ингестер - основна компонента кортекса. Његов посао је да прикупи константан ток узорака, групише их у Прометхеус комаде и складишти их у бази података као што је ДинамоДБ, БигТабле или Цассандра.) Ово омогућава старим корисницима да проследе тренутне податке новим ингесторима. Вреди напоменути да су Ингестери захтевни за ресурсе. Да би радили, потребно је да имате 4 језгра и 15 ГБ меморије по капсули, тј. 25% процесорске снаге и меморије основне машине у случају наших Кубернетес кластера. Генерално, обично имамо много више неискоришћених ресурса у кластеру од 4 језгра и 15 ГБ меморије, тако да можемо лако да покренемо ове додатне уносе током надоградње.

Међутим, често се дешава да током нормалног рада ниједна машина нема ових 25% неискоришћених ресурса. Да, чак и не тежимо: ЦПУ и меморија ће увек бити корисни за друге процесе. Да бисмо решили овај проблем, одлучили смо да користимо Приоритети Кубернетес Под. Идеја је да се Ингестери дају већи приоритет од других (без државности) микросервиса. Када треба да покренемо додатни (Н+1) Ингестер, привремено замењујемо друге, мање махуне. Ове махуне се преносе на слободне ресурсе на другим машинама, остављајући довољно велику „рупу“ за покретање додатног Ингестер-а.

У четвртак, 18. јула, увели смо четири нова нивоа приоритета за наше кластере: критичан, висок, просек и низак. Тестирани су на интерном кластеру без промета клијената око недељу дана. Подразумевано су примљене махуне без одређеног приоритета просек приоритет, класа је постављена за Ингестерс витх висок приоритет. Критичан је резервисано за праћење (Прометхеус, Алертманагер, ноде-екпортер, кубе-стате-метрицс, итд.). Наша конфигурација је отворена и можете погледати ПР овде.

Црасх

У петак, 19. јула, један од инжењера је покренуо нови наменски Цортек кластер за великог клијента. Конфигурација за овај кластер није укључивала нове приоритете подова, тако да је свим новим подовима додељен подразумевани приоритет - просек.

Кубернетес кластер није имао довољно ресурса за нови Цортек кластер, а постојећи производни Цортек кластер није ажуриран (Ингестери су остали без високо приоритет). Пошто су Ингестори новог кластера подразумевано имали просек приоритет, а постојеће махуне у производњи су уопште радиле без приоритета, Ингестери новог кластера заменили су Ингестерс из постојећег Цортек производног кластера.

РеплицаСет за избачени Ингестер у производном кластеру је открио исељену капсулу и креирао нову за одржавање наведеног броја копија. Нова подлога је подразумевано додељена просек приоритет, а други „стари“ Ингестер у производњи изгубио је своје ресурсе. Резултат је био лавински процес, што је довело до измештања свих махуна из Ингестер-а за Цортек производне кластере.

Ингестори су у стању да сачувају податке за претходних 12 сати. Ово нам омогућава да их ефикасније компресујемо пре него што их запишемо у дуготрајно складиштење. Да би се то постигло, Цортек дели податке у низове користећи Дистрибутед Хасх Табле (ДХТ) и реплицира сваку серију преко три Ингестера користећи конзистентност кворума у ​​Динамо стилу. Цортек не уписује податке у Ингестерс који су онемогућени. Стога, када велики број Ингестера напусти ДХТ, Цортек не може да обезбеди довољну репликацију уноса и они се падају.

Детекција и санација

Нова обавештења о Прометеју заснована на "буџету грешке" (заснован на буџету за грешке — детаљи ће се појавити у будућем чланку) почео да се огласи алармом 4 минута након почетка гашења. Током наредних пет минута, извршили смо неку дијагностику и повећали основни Кубернетес кластер да угости и нове и постојеће производне кластере.

Након још пет минута, стари Ингестери су успешно уписали своје податке, нови су се покренули, а Цортек кластери су поново постали доступни.

Још 10 минута је потрошено на дијагностицирање и исправљање грешака у недостатку меморије (ООМ) из реверзних проксија за аутентификацију који се налазе испред Цортек-а. ООМ грешке су узроковане десетоструким повећањем КПС-а (верујемо због превише агресивних захтева са Прометхеус сервера клијента).

Последица

Укупно време застоја је било 26 минута. Ниједан податак није изгубљен. Ингестери су успешно учитали све податке у меморији у дуготрајно складиште. Током гашења, клијентски Прометхеус сервери у баферу су избрисани (на даљину) снимци користећи нови АПИ ремоте_врите засновано на ВАЛ-у (аутор Цаллум Стиан из Графана Лабс) и поновио неуспело писање након пада.

Како су приоритети под у Кубернетес-у изазвали застоје у Графана Лабс-у
Операције писања производног кластера

Налази

Важно је извући поуке из овог инцидента и предузети неопходне кораке да се избегне његово понављање.

Гледајући уназад, није требало да поставимо подразумевану вредност просек приоритет док сви Ингестори у производњи не добију висок приоритет. Поред тога, било је потребно унапред водити рачуна о њима високо приоритет. Сада је све поправљено. Надамо се да ће наше искуство помоћи другим организацијама које разматрају коришћење приоритета под у Кубернетес-у.

Додаћемо додатни ниво контроле над распоређивањем свих додатних објеката чије су конфигурације глобалне у кластер. Од сада ће се такве промене процењивати бовише људи. Поред тога, модификација која је изазвала пад сматрала се сувише малом за посебан пројектни документ – о њој се расправљало само у издању ГитХуб-а. Од сада ће све овакве измене конфигурација бити пропраћене одговарајућом пројектном документацијом.

Коначно, аутоматизоваћемо промену величине обрнутог проксија за аутентификацију да бисмо спречили преоптерећење ООМ-а којем смо били сведоци, и прегледаћемо Прометхеус подразумеване поставке у вези са резервним и скалирањем како бисмо спречили сличне проблеме у будућности.

Неуспех је имао и неке позитивне последице: пошто је добио потребне ресурсе, Цортек се аутоматски опоравио без додатне интервенције. Такође смо стекли драгоцено искуство у раду са Графана Локи - наш нови систем агрегације дневника - који је помогао да се осигура да су се сви Ингестери правилно понашали током и након квара.

ПС од преводиоца

Прочитајте и на нашем блогу:

Извор: ввв.хабр.цом

Додај коментар