Многи људи се боре са Еластицсеарцх-ом. Али шта се дешава када желите да га користите за складиштење дневника „у посебно великој количини“? И да ли је такође безболно доживети неуспех неког од неколико центара података? Какву архитектуру треба да направите и на које замке ћете наићи?
Ми у Одноклассники смо одлучили да користимо еластицсеарцх да решимо питање управљања евиденцијама, а сада делимо своје искуство са Хабром: и о архитектури и о замкама.
Ја сам Пјотр Зајцев, радим као систем администратор у Одноклассники. Пре тога сам такође био админ, радио са Мантицоре Сеарцх, Спхинк сеарцх, Еластицсеарцх. Можда, ако се појави још једна ...претрага, вероватно ћу и ја радити са њом. Такође учествујем у великом броју пројеката отвореног кода на добровољној основи.
Када сам дошао у Одноклассники, непромишљено сам рекао на интервјуу да могу да радим са Еластицсеарцх-ом. Након што сам се снашао и завршио неке једноставне задатке, добио сам велики задатак да реформишем систем управљања дневником који је постојао у то време.
Захтеви
Системски захтеви су формулисани на следећи начин:
- Граилог је требало да се користи као фронтенд. Пошто је компанија већ имала искуства са коришћењем овог производа, програмери и тестери су то знали, био им је познат и погодан.
- Обим података: у просеку 50-80 хиљада порука у секунди, али ако се нешто поквари, онда саобраћај није ограничен ничим, може бити 2-3 милиона линија у секунди
- Након што смо разговарали са клијентима о захтевима за брзину обраде упита за претрагу, схватили смо да је типичан образац коришћења оваквог система следећи: људи траже евиденције својих апликација за последња два дана и не желе да чекају више од друго за резултат формулисаног упита.
- Администратори су инсистирали на томе да систем буде лако скалабилан ако је потребно, а да се од њих не захтева да дубље уђу у то како функционише.
- Тако да је једини задатак одржавања који ови системи захтевају периодично да се промени неки хардвер.
- Поред тога, Одноклассники има одличну техничку традицију: свака услуга коју покренемо мора да преживи квар центра података (изненадни, непланирани и апсолутно у било ком тренутку).
Највише нас је коштао последњи услов у реализацији овог пројекта, о чему ћу детаљније говорити.
Среда
Радимо у четири дата центра, док се Еластицсеарцх чворови података могу лоцирати само у три (из више нетехничких разлога).
Ова четири дата центра садрже приближно 18 хиљада различитих извора евиденције - хардвер, контејнере, виртуелне машине.
Важна карактеристика: кластер почиње у контејнерима не на физичким машинама, већ на . Контејнери имају загарантована 2 језгра, слично 2.0Гхз в4, са могућношћу рециклирања преосталих језгара ако су неактивна.
Другим речима:
Топологија
У почетку сам видео општи облик решења на следећи начин:
- 3-4 ВИП-а се налазе иза А-записа Граилог домена, ово је адреса на коју се шаљу логови.
- сваки ВИП је ЛВС балансер.
- Након тога, дневници иду у Граилог батерију, неки од података су у ГЕЛФ формату, неки у сислог формату.
- Затим се све ово у великим серијама пише у батерију Еластицсеарцх координатора.
- А они, заузврат, шаљу захтеве за писање и читање релевантним чворовима података.
Терминологија
Можда не разумеју сви детаљно терминологију, па бих желео да се мало задржим на томе.
Еластицсеарцх има неколико типова чворова - главни, координатор, чвор података. Постоје још два типа за различите трансформације дневника и комуникацију између различитих кластера, али смо користили само оне наведене.
Мајстор
Он пингује све чворове присутне у кластеру, одржава ажурну мапу кластера и дистрибуира је између чворова, обрађује логику догађаја и обавља различите врсте одржавања домаћинства широм кластера.
Координатор
Обавља само један задатак: прихвата захтеве за читање или писање од клијената и усмерава овај саобраћај. У случају да постоји захтев за писање, највероватније ће питати мастер у који део релевантног индекса треба да га стави, и преусмериће захтев даље.
Дата ноде
Чува податке, извршава упите за претрагу који стижу споља и обавља операције на шардовима који се налазе на њима.
Граилог
Ово је нешто попут фузије Кибана са Логстасх-ом у ЕЛК стеку. Граилог комбинује и кориснички интерфејс и цевовод за обраду дневника. Испод хаубе, Граилог покреће Кафку и Зоокеепер, који обезбеђују повезивање са Грејлогом као кластером. Граилог може кеширати дневнике (Кафка) у случају да Еластицсеарцх није доступан и понавља неуспешне захтеве за читање и писање, групише и обележава евиденције према одређеним правилима. Као и Логстасх, Граилог има функцију да модификује редове пре него што их упише у Еластицсеарцх.
Поред тога, Граилог има уграђену услугу откривања која омогућава, на основу једног доступног Еластицсеарцх чвора, да добије целу мапу кластера и филтрира је према одређеној ознаци, што омогућава усмеравање захтева ка одређеним контејнерима.
Визуелно то изгледа отприлике овако:
Ово је снимак екрана из одређене инстанце. Овде градимо хистограм на основу упита за претрагу и приказујемо релевантне редове.
Индекси
Враћајући се на архитектуру система, желео бих да се детаљније задржим на томе како смо направили индексни модел тако да је све исправно функционисало.
У дијаграму изнад, ово је најнижи ниво: Еластицсеарцх чворови података.
Индекс је велики виртуелни ентитет састављен од Еластицсеарцх фрагмената. Сама по себи, свака од крхотина није ништа друго до Луцене индекс. А сваки Луцене индекс се, заузврат, састоји од једног или више сегмената.
Приликом пројектовања, схватили смо да је потребно да ове податке равномерно „распростремо“ по чворовима података, да бисмо испунили захтев за брзином читања велике количине података.
Ово је резултирало чињеницом да број фрагмената по индексу (са репликама) треба да буде стриктно једнак броју чворова података. Прво, да бисмо обезбедили фактор репликације једнак два (то јест, можемо изгубити половину кластера). И, друго, да би обрадили захтеве за читање и писање на најмање половини кластера.
Прво смо одредили време складиштења на 30 дана.
Дистрибуција фрагмената се може графички представити на следећи начин:
Цео тамно сиви правоугаоник је индекс. Леви црвени квадрат у њему је примарни комад, први у индексу. А плави квадрат је реплика крхотина. Налазе се у различитим дата центрима.
Када додамо још један део, он иде у трећи дата центар. И, на крају, добијамо ову структуру, која омогућава губитак ДЦ-а без губитка конзистентности података:
Ротација индекса, тј. креирањем новог индекса и брисањем најстаријег, поставили смо га једнаким 48 сати (према обрасцу коришћења индекса: најчешће се претражују последњих 48 сати).
Овај интервал ротације индекса је због следећих разлога:
Када захтев за претрагу стигне до одређеног чвора података, онда је, са тачке гледишта перформанси, исплативије када се постави упит за један део, ако је његова величина упоредива са величином кука чвора. Ово вам омогућава да задржите „врући“ део индекса у гомили и брзо му приступите. Када има много „врућих делова“, брзина претраживања индекса опада.
Када чвор почне да извршава упит за претрагу на једном сегменту, он додељује број нити једнак броју хипернитних језгара физичке машине. Ако упит за претрагу утиче на велики број фрагмената, онда број нити расте пропорционално. Ово има негативан утицај на брзину претраживања и негативно утиче на индексирање нових података.
Да бисмо обезбедили неопходно кашњење у претраживању, одлучили смо да користимо ССД. Да би брзо обрадиле захтеве, машине које су угостиле ове контејнере морале су да имају најмање 56 језгара. Број 56 је изабран као условно довољна вредност која одређује број нити које ће Еластицсеарцх генерисати током рада. У Еласитцсеарцх-у, многи параметри скупа нити директно зависе од броја доступних језгара, што заузврат директно утиче на потребан број чворова у кластеру по принципу „мање језгара – више чворова“.
Као резултат тога, открили смо да у просеку једна шарда тежи око 20 гигабајта, а по индексу има 1 фрагмената. Сходно томе, ако их окренемо једном у 360 сати, онда их имамо 48. Сваки индекс садржи податке за 15 дана.
Кола за писање и читање података
Хајде да схватимо како се подаци снимају у овом систему.
Рецимо да од Грејлога стигне неки захтев координатору. На пример, желимо да индексирамо 2-3 хиљаде редова.
Координатор, пошто је примио захтев од Грејлога, поставља питање мастеру: „У захтеву за индексирање смо посебно навели индекс, али није наведено у који шард да га упишемо.
Мастер одговара: „Упишите ову информацију у шард број 71“, након чега се шаље директно у релевантни чвор података, где се налази примарни део број 71.
Након тога се евиденција трансакција реплицира у реплику-схард, која се налази у другом центру података.
Од Грејлога координатору стиже захтев за претрагу. Координатор га преусмерава према индексу, док Еластицсеарцх дистрибуира захтеве између примарног-схарда и реплике-схард-а по принципу роунд-робин.
180 чворова реагује неједнако, а док они реагују, координатор акумулира информације које су већ „испљунули“ бржи чворови података. Након тога, када стигну све информације, или је захтев достигао временско ограничење, он све даје директно клијенту.
Цео овај систем у просеку обрађује упите за претрагу у последњих 48 сати за 300-400 мс, искључујући оне упите са водећим џокер знаком.
Цвеће са Еластицсеарцх: Јава подешавање
Да би све функционисало онако како смо првобитно желели, провели смо веома дуго времена на отклањању грешака у великом броју ствари у кластеру.
Први део откривених проблема односио се на начин на који је Јава унапред конфигурисана у Еластицсеарцх-у.
Проблем један
Видели смо веома велики број извештаја да на нивоу Луцене, када се извршавају позадински послови, спајање Луцене сегмента не успева са грешком. У исто време, у евиденцији је било јасно да је реч о грешци ОутОфМемориЕррор. Из телеметрије смо видели да је кук слободан и није било јасно зашто ова операција није успела.
Испоставило се да се спајање Луцене индекса дешава изван кука. А контејнери су прилично стриктно ограничени у смислу потрошених ресурса. Само хеап је могао да стане у ове ресурсе (вредност хеап.сизе је била приближно једнака РАМ-у), а неке операције ван гомиле су се срушиле са грешком у алокацији меморије ако се из неког разлога нису уклапале у ~500МБ који је остао пре ограничења.
Поправка је била прилично тривијална: повећана је количина РАМ-а који је доступан за контејнер, након чега смо заборавили да смо чак и имали таквих проблема.
Проблем два
4-5 дана након покретања кластера, приметили смо да су чворови података почели периодично да испадају из кластера и да улазе у њега након 10-20 секунди.
Када смо почели да схватамо, испоставило се да ова меморија ван гомиле у Еластицсеарцх-у није ни на који начин контролисана. Када смо дали више меморије контејнеру, могли смо да напунимо директне баферске групе разним информацијама, а оне су обрисане тек након што је експлицитни ГЦ покренут из Еластицсеарцх-а.
У неким случајевима, ова операција је трајала доста времена, а за то време кластер је успео да означи овај чвор као већ изашао. Овај проблем је добро описан .
Решење је било следеће: ограничили смо способност Јаве да користи највећи део меморије ван гомиле за ове операције. Ограничили смо га на 16 гигабајта (-КСКС:МакДирецтМемориСизе=16г), осигуравајући да се експлицитни ГЦ позива много чешће и много брже обрађује, чиме се више не дестабилизује кластер.
Проблем три
Ако мислите да су проблеми са „чворовима који напуштају кластер у најнеочекиванијем тренутку“ завршени, варате се.
Када смо конфигурисали рад са индексима, изабрали смо ммапфс на на свеже крхотине са великом сегментацијом. Ово је била поприлична грешка, јер када се користи ммапфс датотека се мапира у РАМ, а затим радимо са мапираном датотеком. Због тога се испоставља да када ГЦ покуша да заустави нити у апликацији, идемо до безбедне тачке веома дуго, а на путу до ње апликација престаје да одговара на захтеве мастера о томе да ли је жива . Сходно томе, мастер верује да чвор више није присутан у кластеру. Након тога, након 5-10 секунди, сакупљач смећа ради, чвор оживљава, поново улази у кластер и почиње да иницијализује шардове. Све је личило на „продукцију коју смо заслужили“ и није било прикладно за било шта озбиљно.
Да бисмо се решили овог понашања, прво смо прешли на стандардне ниоф-ове, а затим, када смо мигрирали са пете верзије Еластиц-а на шесту, покушали смо са хибридф-овима, где се овај проблем није репродуковао. Можете прочитати више о врстама складиштења .
Проблем четири
Затим се појавио још један веома интересантан проблем који смо лечили у рекордном року. Хватали смо га 2-3 месеца јер је његов образац био апсолутно неразумљив.
Понекад су наши координатори одлазили у Фулл ГЦ, обично негде после ручка, и никада се одатле нису враћали. У исто време, приликом евидентирања ГЦ кашњења, изгледало је овако: све иде добро, добро, добро, а онда одједном све иде веома лоше.
Прво смо мислили да имамо злог корисника који је покренуо неку врсту захтева који је избацио координатора из режима рада. Веома дуго смо бележили захтеве, покушавајући да схватимо шта се дешава.
Као резултат тога, испоставило се да у тренутку када корисник покрене огроман захтев, а он стигне до одређеног Еластицсеарцх координатора, неки чворови одговарају дуже од других.
И док координатор чека одговор од свих чворова, он акумулира резултате послате од чворова који су већ одговорили. За ГЦ, то значи да се наши обрасци коришћења гомиле мењају веома брзо. А ГЦ који смо користили није могао да се носи са овим задатком.
Једино решење које смо пронашли да промени понашање кластера у овој ситуацији је миграција на ЈДК13 и коришћење сакупљача смећа Схенандоах. Ово је решило проблем, наши координатори су престали да падају.
Ту су се завршили проблеми са Јавом и почели проблеми са пропусним опсегом.
"Бобице" са Еластицсеарцх: пропусност
Проблеми са пропусношћу значе да наш кластер ради стабилно, али на врхунцу броја индексираних докумената и током маневара, перформансе су недовољне.
Први симптом на који се наилази: током неких „експлозија“ у производњи, када се изненада генерише веома велики број дневника, грешка индексирања ес_рејецтед_екецутион почиње често да трепери у Граилог-у.
Ово је било због чињенице да тхреад_поол.врите.куеуе на једном чвору података, све до тренутка када Еластицсеарцх буде у стању да обради захтев за индексирање и отпреми информације у шард на диску, може подразумевано да кешира само 200 захтева. А у О овом параметру се врло мало говори. Назначени су само максимални број нити и подразумевана величина.
Наравно, отишли смо да изврнемо ову вредност и открили смо следеће: конкретно, у нашем подешавању, до 300 захтева се кешује прилично добро, а већа вредност је препуна чињенице да поново летимо у Фулл ГЦ.
Поред тога, пошто се ради о групама порука које стижу у оквиру једног захтева, било је потребно подесити Граилог тако да не пише често и у малим серијама, већ у огромним серијама или једном у 3 секунде ако серија још увек није комплетна. У овом случају, испада да информације које упишемо у Еластицсеарцх постају доступне не за две секунде, већ за пет (што нам сасвим одговара), али број понављања које треба да се уради да би се прогурао велики гомила информација је смањена.
Ово је посебно важно у оним тренуцима када се нешто негде срушило и фуриозно извештава о томе, да не би добили потпуно спамовани Еластиц, а после неког времена - Граилог чворови који су неоперативни због зачепљених бафера.
Осим тога, када смо имали ове исте експлозије у производњи, добијали смо жалбе од програмера и тестера: у тренутку када су им ови дневники заиста били потребни, давали су их веома споро.
Почели су да схватају. С једне стране, било је јасно да се и упити за претрагу и упити за индексирање обрађују, у суштини, на истим физичким машинама, и на овај или онај начин долазило би до одређених повлачења.
Али ово би се делимично могло заобићи због чињенице да се у шестој верзији Еластицсеарцх-а појавио алгоритам који вам омогућава да дистрибуирате упите између релевантних чворова података не према принципу случајног роунд-робин (контејнер који врши индексирање и држи примарни- шард може бити веома заузет, неће бити начина да се брзо одговори), али да се овај захтев проследи мање оптерећеном контејнеру са репликом-шардом, који ће одговорити много брже. Другим речима, дошли смо до усе_адаптиве_реплица_селецтион: труе.
Слика за читање почиње да изгледа овако:
Прелазак на овај алгоритам је омогућио да се значајно побољша време упита у оним тренуцима када смо имали велики ток дневника за писање.
Коначно, главни проблем је било безболно уклањање дата центра.
Шта смо желели од кластера одмах након губитка везе са једним ДЦ-ом:
- Ако имамо тренутни мастер у неуспешном центру података, онда ће он бити поново изабран и премештен као улога на други чвор у другом ДЦ.
- Мастер ће брзо уклонити све недоступне чворове из кластера.
- На основу преосталих схватиће: у изгубљеном дата центру смо имали такве и такве примарне шардове, он ће брзо промовисати комплементарне реплике шардова у преосталим дата центрима, а ми ћемо наставити да индексирамо податке.
- Као резултат тога, проток писања и читања кластера ће се постепено деградирати, али генерално све ће радити, иако споро, али стабилно.
Како се испоставило, желели смо нешто овако:
И добили смо следеће:
Како се то догодило?
Када је центар података пао, наш господар је постао уско грло.
Зашто?
Чињеница је да мастер има ТаскБатцхер, који је одговоран за дистрибуцију одређених задатака и догађаја у кластеру. Било који излаз из чвора, било која промоција шарда од реплике до примарног, било који задатак да се негде створи део - све ово иде прво у ТаскБатцхер, где се обрађује секвенцијално и у једној нити.
У тренутку повлачења једног дата центра, испоставило се да су сви чворови података у преживелим дата центрима сматрали својом дужношћу да обавесте господара „изгубили смо такве и такве делове и такве и такве чворове података“.
Истовремено, преживјели чворови података послали су све ове информације тренутном мастеру и покушали да сачекају потврду да их је прихватио. Ово нису чекали, јер је мајстор добијао задатке брже него што је могао да одговори. Чворови су истекли време за понављање захтева, а мастер у овом тренутку није ни покушао да одговори на њих, већ је био потпуно заокупљен задатком сортирања захтева по приоритету.
У терминалној форми, испоставило се да су чворови података спамовали мастер до те мере да је отишао у пуни ГЦ. Након тога, наша главна улога се преселила у неки следећи чвор, десило му се апсолутно исто, и као резултат тога кластер се потпуно урушио.
Извршили смо мерења, а пре верзије 6.4.0, где је то поправљено, било нам је довољно да истовремено избацимо само 10 чворова података од 360 да бисмо потпуно угасили кластер.
Изгледало је отприлике овако:
После верзије 6.4.0, где је исправљена ова страшна грешка, чворови података су престали да убијају мастера. Али то га није учинило „паметнијим“. Наиме: када избацимо 2, 3 или 10 (било који број осим једног) чворова података, мастер прима неку прву поруку која каже да је чвор А отишао, и покушава да каже чвору Б, чвору Ц о томе, чвору Д.
А тренутно се то може решити само постављањем тајм-аута за покушаје да се некоме нешто каже, једнако од око 20-30 секунди, и тако контролише брзину изласка центра података из кластера.
У принципу, ово се уклапа у захтеве који су првобитно представљени финалном производу као део пројекта, али са становишта „чисте науке“ ово је грешка. Што су, иначе, програмери успешно поправили у верзији 7.2.
Штавише, када је одређени чвор података угашен, испоставило се да је ширење информација о његовом излазу било важније него да се целом кластеру каже да се на њему налазе такви и такви примарни-схардови (како би се промовисала реплика-схард у другим подацима центар у основној, а на њима би се могле писати и информације).
Стога, када је све већ замрло, ослобођени чворови података се не означавају одмах као застарели. Сходно томе, принуђени смо да сачекамо док сви пингови не истекну до ослобођених чворова података, а тек након тога наш кластер почиње да нам говори да тамо, тамо и тамо треба да наставимо са снимањем информација. Можете прочитати више о овоме .
Као резултат тога, операција повлачења дата центра данас нам траје око 5 минута у шпицу. За тако великог и неспретног колоса, ово је прилично добар резултат.
Као резултат тога, дошли смо до следеће одлуке:
- Имамо 360 чворова података са дисковима од 700 гигабајта.
- 60 координатора за рутирање саобраћаја кроз те исте чворове података.
- 40 мајстора које смо оставили као својеврсно наслеђе од верзија пре 6.4.0 – да бисмо преживели повлачење дата центра, били смо психички спремни да изгубимо неколико машина како бисмо гарантовали да имамо кворум мајстора чак и у најгорем сценарију
- Сваки покушај комбиновања улога на једном контејнеру наишао је на чињеницу да би се пре или касније чвор покварио под оптерећењем.
- Цео кластер користи хеап.сизе од 31 гигабајта: сви покушаји да се смањи величина резултирали су или убијањем неких чворова на тешким упитима за претрагу са водећим џокер знаком или добијањем прекидача у самом Еластицсеарцх-у.
- Поред тога, да бисмо обезбедили перформансе претраге, трудили смо се да број објеката у кластеру буде што мањи, како бисмо обрадили што мање догађаја у уском грлу које смо добили у мастеру.
Коначно о праћењу
Да бисмо осигурали да све ово функционише како треба, пратимо следеће:
- Сваки чвор података јавља нашем облаку да постоји, а на њему се налазе такве и такве крхотине. Када негде угасимо нешто, кластер после 2-3 секунде јавља да смо у центру А угасили чворове 2, 3 и 4 - то значи да у другим центрима података ни под којим условима не можемо да угасимо оне чворове на којима постоји само једна крхотина. лево.
- Познавајући природу понашања мајстора, веома пажљиво посматрамо број задатака на чекању. Јер чак и један заглављени задатак, ако не истекне на време, теоретски у некој ванредној ситуацији може постати разлог зашто, на пример, промоција шарда реплике у примарној не функционише, због чега ће индексирање престати да ради.
- Такође пажљиво посматрамо кашњења сакупљача смећа, јер смо већ имали великих потешкоћа са овим током оптимизације.
- Одбија по нити да би унапред разумео где је уско грло.
- Па, стандардне метрике као што су хрпа, РАМ и И/О.
Када надгледате изградњу, морате узети у обзир карактеристике Тхреад Поол-а у Еластицсеарцх-у. описује опције конфигурације и подразумеване вредности за претрагу и индексирање, али потпуно не говори о тхреад_поол.манагемент. Ове нити обрађују, посебно, упите попут _цат/схардс и друге сличне, које је згодно користити приликом писања праћења. Што је кластер већи, то се више оваквих захтева извршава по јединици времена, а поменути тхреад_поол.манагемент не само да није представљен у званичној документацији, већ је и подразумевано ограничен на 5 нити, који се врло брзо уклања, након који надзор престаје да ради исправно.
Оно што желим да кажем у закључку: успели смо! Били смо у могућности да нашим програмерима и програмерима дамо алат који, у скоро свакој ситуацији, може брзо и поуздано да пружи информације о томе шта се дешава у производњи.
Да, испоставило се да је прилично компликовано, али смо, ипак, успели да своје жеље уклопимо у постојеће производе, које нисмо морали сами да крпимо и преписујемо.
Извор: ввв.хабр.цом