Крајем прошле године одржан је још један директан пренос руске ПостгреСКЛ заједнице , током којег је њен суоснивач Николај Самокхвалов разговарао са техничким директором Фланта Дмитријем Стољаровом о овој ДБМС у контексту Кубернетеса.
Објављујемо транскрипт главног дела ове расправе, а на Постављен цео видео:
Базе података и Кубернетес
НС: О ВАКУУМУ и КОНТРОЛНИМ ТАЧКАМА данас нећемо. Желимо да разговарамо о Кубернетесу. Знам да имате дугогодишње искуство. Гледао сам ваше видео записе, па чак и неке од њих поново... Да пређемо директно на ствар: зашто уопште Постгрес или МиСКЛ у К8с?
ДС: Не постоји и не може бити дефинитивног одговора на ово питање. Али генерално, ово је једноставност и погодност... потенцијал. Сви желе управљане услуге.
НС: Како , само код куће?
ДС: Да: као РДС, било где.
НС: „Било где“ је добра поента. У великим компанијама све се налази на различитим местима. Зашто онда, ако је у питању велика компанија, не узети готово решење? На пример, Нутаник има свој развој, друге компаније (ВМваре...) имају исти „РДС, само код куће“.
ДС: Али говоримо о засебној имплементацији која ће радити само под одређеним условима. А ако говоримо о Кубернетесу, онда постоји огромна разноликост инфраструктуре (која може бити у К8с). У суштини ово је стандард за АПИ-је у облаку...
НС: Такође је бесплатно!
ДС: Није толико важно. Слобода је важна за не баш велики сегмент тржишта. Још нешто је важно... Вероватно се сећате извештаја „"?"
НС: Да.
ДС: Схватио сам да је примљено веома двосмислено. Неки су мислили да говорим: „Момци, хајде да убацимо све базе података у Кубернетес!“, док су други сматрали да су то све страшни бицикли. Али хтео сам да кажем нешто сасвим друго: „Погледајте шта се дешава, какви проблеми постоје и како се могу решити. Да ли сада треба да користимо Кубернетес базе података? Производња? Па, само ако волиш...да радиш одређене ствари. Али за програмере, могу рећи да га препоручујем. За програмере је веома важан динамизам креирања/брисања окружења.
НС: Под дев, да ли мислите на сва окружења која нису прод? Постављање, осигурање квалитета…
ДС: Ако говоримо о перф сталцима, онда вероватно не, јер су захтеви тамо специфични. Ако говоримо о посебним случајевима где је потребна веома велика база података за постављање, онда вероватно не... Ако је ово статичко, дуговечно окружење, која је онда корист од тога да се база података налази у К8с?
НС: Ниједан. Али где видимо статична окружења? Статичко окружење ће сутра постати застарело.
ДС: Постављање може бити статичко. Имамо клијенте...
НС: Да, и ја имам једну. Велики је проблем ако имате базу података од 10 ТБ и сцену од 200 ГБ...
ДС: Имам веома кул случај! Приликом постављања постоји база података о производима у којој се врше промене. А ту је и дугме: „пребацити у производњу“. Ове промене - делте - се додају (изгледа да су једноставно синхронизоване преко АПИ-ја) у производњи. Ово је веома егзотична опција.
НС: Видео сам стартапе у Долини који седе у РДС-у или чак у Херокуу - ово су приче од пре 2-3 године - и преузимају думп на свој лаптоп. Јер база података је и даље само 80 ГБ, а места на лаптопу има. Затим купују додатне дискове за свакога тако да имају 3 базе података за различите развоје. Тако се и то дешава. Такође сам видео да се не плаше да копирају прод у сцену - то у великој мери зависи од компаније. Али видео сам и да се јако плаше, и да често немају довољно времена и руку. Али пре него што пређемо на ову тему, желим да чујем о Кубернетесу. Да ли сам добро разумео да још нико није у продукцији?
ДС: Имамо мале базе података у прод. Реч је о обима од десетине гигабајта и некритичним сервисима за које смо били лењи да правимо реплике (а нема те потребе). И под условом да постоји нормално складиште под Кубернетес-ом. Ова база података је радила у виртуелној машини - условно у ВМваре-у, на врху система за складиштење. Ставили смо га и сада можемо да га преносимо са машине на машину.
НС: Базе података ове величине, до 100 ГБ, могу се покренути за неколико минута на добрим дисковима и доброј мрежи, зар не? Брзина од 1 ГБ у секунди више није егзотична.
ДС: Да, за линеарни рад то није проблем.
НС: У реду, морамо само да мислимо на прод. А ако разматрамо Кубернетес за не-производна окружења, шта треба да радимо? Видим то у Заланду , у Црунцхи , постоје неке друге опције. И постоји - ово је наш добар пријатељ Алваро из Шпаније: оно што они раде у суштини није праведно , и цела дистрибуција (), у који су, поред самог Постгреса, одлучили да убаце и резервну копију, Енвои проки...
ДС: Изасланик за шта? Балансирање Постгрес саобраћаја конкретно?
НС: Да. Односно, они то виде као: ако узмете Линук дистрибуцију и језгро, онда је обичан ПостгреСКЛ језгро, и они желе да направе дистрибуцију која ће бити прилагођена облаку и покретана на Кубернетес-у. Састављају компоненте (резервне копије, итд.) и отклањају грешке тако да добро функционишу.
ДС: Веома кул! У суштини ово је софтвер за креирање сопственог управљаног Постгреса.
НС: Линукс дистрибуције имају вечне проблеме: како направити драјвере тако да сав хардвер буде подржан. И имају идеју да ће радити у Кубернетесу. Знам да смо код оператера Заландо недавно видели везу са АВС-ом и ово више није добро. Не би требало да постоји веза са одређеном инфраструктуром - у чему је онда поента?
ДС: Не знам тачно у какву је ситуацију упао Заландо, али у Кубернетес-у је складиштење сада направљено тако да је немогуће направити резервну копију диска генеричком методом. Недавно у стандардној - најновијој верзији — омогућили смо снимке, али где је то имплементирано? Искрено, још је све тако сирово... Покушавамо са ЦСИ на врху АВС, ГЦЕ, Азуре, вСпхере, али чим почнете да га користите, видите да још није спреман.
НС: Зато се понекад морамо ослањати на инфраструктуру. Мислим да је ово још увек рана фаза - болови у расту. Питање: Шта бисте саветовали почетницима који желе да испробају ПгСКЛ у К8с? Који оператер можда?
ДС: Проблем је што нам је Постгрес 3%. Такође имамо веома велику листу различитог софтвера у Кубернетесу, нећу ни да наводим све. На пример, Еластицсеарцх. Постоји много оператера: неки се активно развијају, други не. За себе смо саставили захтеве, шта треба да буде у оператеру да бисмо то схватили озбиљно. У оператеру посебно за Кубернетес - не у "оператеру да уради нешто у Амазоновим условима"... У ствари, ми прилично широко (= скоро сви клијенти) користимо једног оператера - (ускоро ћемо објавити чланак о њему).
НС: А не и за МиСКЛ? Знам да Перцона... пошто сада раде на МиСКЛ-у, МонгоДБ-у и Постгресу, мораће да направе некакво универзално решење: за све базе података, за све клауд провајдере.
ДС: Нисмо имали времена да погледамо операторе за МиСКЛ. Ово тренутно није наш главни фокус. МиСКЛ добро функционише самостално. Зашто користити оператор ако можете само да покренете базу података... Можете покренути Доцкер контејнер са Постргес-ом или га можете покренути на једноставан начин.
НС: Постојало је питање и о овоме. Уопште нема оператера?
ДС: Да, 100% нас има ПостгреСКЛ који ради без оператера. До сада је тако. Активно користимо оператор за Прометхеус и Редис. Планирамо да пронађемо оператера за Еластицсеарцх – он је онај који највише „гори“, јер желимо да га инсталирамо у Кубернетес у 100% случајева. Баш као што желимо да осигурамо да је МонгоДБ такође увек инсталиран у Кубернетес. Овде се јављају одређене жеље - постоји осећај да се у овим случајевима нешто може учинити. А нисмо ни погледали Постгрес. Наравно, знамо да постоје различите опције, али у ствари имамо самосталну.
ДБ за тестирање у Кубернетесу
НС: Пређимо на тему тестирања. Како увести промене у базу података - из ДевОпс перспективе. Има микросервиса, много база података, стално се негде нешто мења. Како осигурати нормалан ЦИ/ЦД тако да све буде у реду из перспективе ДБМС-а. Какав је твој приступ?
ДС: Не може бити један одговор. Постоји неколико опција. Прва је величина основе коју желимо да разваљамо. Сами сте споменули да компаније имају различите ставове према томе да имају копију базе података производа на дев и бини.
НС: А под условима ГДПР-а, мислим да су све опрезнији... Могу рећи да су у Европи већ почели да изричу казне.
ДС: Али често можете написати софтвер који узима думп из производње и замагљује га. Прод подаци се добијају (снапсхот, думп, бинарна копија...), али су анонимизовани. Уместо тога, могу постојати скрипте за генерисање: то могу бити фиксне поставке или само скрипта која генерише велику базу података. Проблем је: колико времена је потребно да се направи основна слика? И колико времена је потребно да се постави у жељено окружење?
Дошли смо до шеме: ако клијент има фиксни скуп података (минимална верзија базе података), онда их подразумевано користимо. Ако говоримо о окружењима за рецензије, када смо креирали грану, поставили смо инстанцу апликације - ту смо избацили малу базу података. Али испало је добро , када једном дневно (ноћу) узмемо дамп из производње и направимо Доцкер контејнер са ПостгреСКЛ-ом и МиСКЛ-ом са овим учитаним подацима на основу њега. Ако треба да проширите базу података 50 пута са ове слике, то се ради прилично једноставно и брзо.
НС: Једноставним копирањем?
ДС: Подаци се чувају директно у Доцкер слици. Оне. Имамо готову слику, додуше 100 ГБ. Захваљујући слојевима у Доцкер-у, можемо брзо да применимо ову слику онолико пута колико нам је потребно. Метода је глупа, али добро функционише.
НС: Онда, када тестирате, мења се директно у Доцкер-у, зар не? Цопи-он-врите унутар Доцкер-а - баците га и идите поново, све је у реду. Класа! И да ли га већ користите у потпуности?
ДС: Дуже време.
НС: Радимо веома сличне ствари. Само ми не користимо Доцкер-ов цопи-он-врите, већ неки други.
ДС: Није генерички. А Доцкер ради свуда.
НС: У теорији, да. Али ту имамо и модуле, можете направити различите модуле и радити са различитим системима датотека. Какав тренутак овде. Са Постгресове стране на све ово гледамо другачије. Сада сам погледао са Доцкер стране и видео да све ради за вас. Али ако је база података огромна, на пример, 1 ТБ, онда све ово траје дуго: операције ноћу, и трпање свега у Доцкер... А ако се 5 ТБ угура у Доцкер... Или је све у реду?
ДС: Која је разлика: ово су мрље, само битови и бајтови.
НС: Разлика је следећа: да ли то радите кроз думп и рестаурацију?
ДС: Уопште није неопходно. Методе за генерисање ове слике могу бити различите.
НС: За неке клијенте смо направили тако да уместо редовног генерисања основне слике, стално је ажурирамо. У суштини је реплика, али не прима податке директно од мастера, већ преко архиве. Бинарна архива где се свакодневно преузимају ВАЛ-ови, где се праве резервне копије... Ови ВАЛ-ови онда са малим закашњењем (буквално 1-2 секунде) стигну до основне слике. Клонирамо из њега на било који начин - сада подразумевано имамо ЗФС.
ДС: Али са ЗФС-ом сте ограничени на један чвор.
НС: Да. Али ЗФС такође има магију : помоћу њега можете послати снимак и чак (ја ово још нисам стварно тестирао, али...) можете послати делта између два PGDATA. У ствари, имамо још један алат који нисмо заиста разматрали за такве задатке. ПостгреСКЛ има , који функционише као „паметни“ рсинц, прескачући много тога што не морате да гледате, јер се ту ништа није променило. Можемо извршити брзу синхронизацију између два сервера и премотати на исти начин.
Дакле, са ове, више ДБА стране, покушавамо да направимо алатку која нам омогућава да урадимо исто што сте рекли: имамо једну базу података, али желимо да тестирамо нешто 50 пута, скоро истовремено.
ДС: 50 пута значи да морате наручити 50 Спот инстанци.
НС: Не, све радимо на једној машини.
ДС: Али како ћете проширити 50 пута ако је ова база података, рецимо, терабајта. Највероватније јој треба условних 256 ГБ РАМ-а?
НС: Да, понекад вам треба много меморије - то је нормално. Али ово је пример из живота. Производна машина има 96 језгара и 600 ГБ. Истовремено, за базу података се користи 32 језгра (понекад чак 16 језгара) и 100-120 ГБ меморије.
ДС: И тамо стане 50 примерака?
НС: Дакле, постоји само једна копија, онда цопи-он-врите (ЗФС) ради... Рећи ћу вам детаљније.
На пример, имамо базу података од 10 ТБ. За њега су направили диск, ЗФС је такође компримовао његову величину за 30-40 одсто. Пошто не вршимо тестирање оптерећења, тачно време одговора нам није важно: нека буде до 2 пута спорије - у реду је.
Дајемо прилику програмерима, КА, ДБА итд. извршити тестирање у 1-2 нити. На пример, они могу покренути неку врсту миграције. Не захтева 10 језгара одједном - потребно му је 1 Постгрес позадину, 1 језгро. Миграција ће почети – можда ће и даље почети, онда ће се користити друго језгро. Имамо 16-32 језгра додељено, тако да 10 људи може да ради у исто време, нема проблема.
Јер физички PGDATA исто, испада да ми заправо обмањујемо Постгрес. Трик је следећи: на пример, истовремено се покреће 10 Постгреса. Шта је обично проблем? Су ставили , рецимо 25%. Сходно томе, ово је 200 ГБ. Нећете моћи да покренете више од три од њих, јер ће меморија понестати.
Али у неком тренутку смо схватили да то није потребно: поставили смо схаред_буфферс на 2 ГБ. ПостгреСКЛ има , а у стварности једино утиче . Поставили смо га на 0,5 ТБ. И није ни важно што они заправо не постоје: он прави планове као да постоје.
Сходно томе, када тестирамо неку врсту миграције, можемо да прикупимо све планове - видећемо како ће се то десити у производњи. Секунде ће тамо бити другачије (спорије), али подаци које заправо читамо, и сами планови (шта ЈОИН-ови постоје, итд.) испадају потпуно исти као у продукцији. И можете покренути многе такве провере паралелно на једној машини.
ДС: Зар не мислите да овде има неколико проблема? Прво је решење које ради само на ПостгреСКЛ-у. Овај приступ је веома приватан, није генерички. Други је да Кубернетес (и све што технологије облака сада иду) укључује много чворова, а ти чворови су ефемерни. А у вашем случају то је упорни чвор са стањем. Ове ствари ме чине конфликтним.
НС: Прво, слажем се, ово је чисто Постгрес прича. Мислим да ако имамо неку врсту директног ИО-а и пуфер бафера за скоро сву меморију, овај приступ неће радити – планови ће бити другачији. Али за сада радимо само са Постгресом, не размишљамо о другима.
О Кубернетесу. Сами нам свуда говорите да имамо постојану базу података. Ако инстанца не успе, главна ствар је да сачувате диск. Овде такође имамо целу платформу у Кубернетесу, а компонента са Постгрес-ом је одвојена (иако ће бити тамо једног дана). Дакле, све је овако: инстанца је пала, али смо њен ПВ сачували и једноставно спојили на другу (нову) инстанцу, као да се ништа није догодило.
ДС: Са моје тачке гледишта, ми креирамо подове у Кубернетесу. К8с - еластична: чворови се наручују по потреби. Задатак је да једноставно направите под и кажете да му је потребна Кс количина ресурса, а онда ће К8с то сам схватити. Али подршка за складиштење у Кубернетес-у је и даље нестабилна: У (ово издање је објављено недељама пре) ове функције постају само бета.
Проћи ће шест месеци до годину дана – постаће мање-више стабилан, или ће се бар тако прогласити. Тада могућност снимака и промене величине у потпуности решава ваш проблем. Зато што имате базу. Да, можда није веома брзо, али брзина зависи од тога шта је „испод хаубе“, јер неке имплементације могу да копирају и копирају-уписују на нивоу подсистема диска.
НС: Такође је неопходно да сви мотори (Амазон, Гугл...) почну да подржавају ову верзију - и за то је потребно неко време.
ДС: Још их не користимо. Користимо наше.
Локални развој за Кубернетес
НС: Да ли сте наишли на такву жељу када треба да инсталирате све подове на једну машину и урадите тако мали тест. Да бисте брзо добили доказ концепта, погледајте да апликација ради у Кубернетес-у, а да за њу не посветите гомилу машина. Ту је Миникубе, зар не?
ДС: Чини ми се да се у овом случају – распоређеном на једном чвору – ради искључиво о локалном развоју. Или неке манифестације таквог обрасца. Једи тамо , . Идемо ка коришћењу Кубернетес ИН Доцкер-а. Сада смо почели да радимо са њим за тестове.
НС: Некада сам мислио да је ово покушај да се сви подови умотају у једну Доцкер слику. Али испоставило се да се овде ради о нечем сасвим другом. У сваком случају, постоје одвојени контејнери, одвојени подови - само у Доцкер-у.
ДС: Да. И направљена је прилично смешна имитација, али значење је ово... Имамо услужни програм за постављање - . Желимо да то буде условни режим werf up: „Набавите ми локални Кубернетес.“ И онда тамо покрените услов werf follow. Тада ће програмер моћи да уређује ИДЕ, а процес ће бити покренут у систему који види промене и поново гради слике, премјештајући их на локалне К8с. На овај начин желимо да покушамо да решимо проблем локалног развоја.
Снимци и клонирање базе података у К8с стварности
НС: Ако се вратимо на копирање на писање. Приметио сам да и облаци имају снимке. Они раде другачије. На пример, у ГЦП: имате инстанцу од више терабајта на источној обали Сједињених Држава. Повремено правите снимке. Покупите копију диска на западној обали са снимка - за неколико минута све је спремно, ради веома брзо, само треба попунити кеш меморију. Али ови клонови (снимци) служе за 'обезбеђивање' новог волумена. Ово је супер када треба да креирате много инстанци.
Али за тестове, чини ми се да снимци, о којима ви говорите у Доцкер-у или ја говорим у ЗФС-у, бтрфс-у па чак и ЛВМ-у... - омогућавају вам да не креирате заиста нове податке на једној машини. У облаку ћете их и даље плаћати сваки пут и чекати не секунде, већ минуте (и у случају , могуће сат).
Уместо тога, ове податке можете добити за секунд или две, покренути тест и бацити их. Ови снимци решавају различите проблеме. У првом случају - за повећање и добијање нових реплика, ау другом - за тестове.
ДС: Не слажем се. Омогућавање правилног функционисања клонирања волумена је задатак облака. Нисам погледао њихову примену, али знам како то радимо на хардверу. Имамо Цепх, дозвољава било који физички волумен () рећи клонирати и добити други волумен са истим карактеристикама за десетине милисекунди, 'ами итд. Морате да схватите да унутра постоји лукаво копирање на писање. Зашто облак не би урадио исто? Сигуран сам да покушавају да ураде ово на овај или онај начин.
НС: Али и даље ће им требати секунде, десетине секунди да покрену инстанцу, доведу Доцкер тамо, итд.
ДС: Зашто је потребно подизати целу инстанцу? Имамо инстанцу са 32 језгра, 16... и може да стане у њу - на пример, четири. Када наручимо пету, инстанца ће већ бити подигнута, а затим ће бити обрисана.
НС: Да, занимљиво, испоставило се да је Кубернетес друга прича. Наша база података није у К8с, и имамо једну инстанцу. Али клонирање базе података од више терабајта не траје више од две секунде.
ДС: Ово је супер. Али моја почетна поента је да ово није опште решење. Да, то је кул, али је погодно само за Постгрес и само на једном чвору.
НС: Погодан је не само за Постгрес: ови планови ће, као што сам описао, функционисати само у њему. Али ако се не трудимо око планова, а потребни су нам само сви подаци за функционално тестирање, онда је ово погодно за било који ДБМС.
ДС: Пре много година урадили смо нешто слично на ЛВМ снимцима. Ово је класика. Овај приступ се веома активно користио. Чворови са стањем су само бол. Зато што их не треба испуштати, треба их увек памтити...
НС: Да ли видите било какву могућност хибрида овде? Рецимо да је статефул нека врста под, ради за неколико људи (много тестера). Имамо један волумен, али захваљујући систему датотека, клонови су локални. Ако капсула падне, али диск остане, подићи ће се, пребројати информације о свим клоновима, покупити све поново и рећи: „Ево ваших клонова који раде на овим портовима, наставите да радите са њима.
ДС: Технички то значи да је унутар Кубернетес-а један под унутар којег покрећемо много Постгреса.
НС: Да. Он има ограничење: рецимо да са њим не ради више од 10 људи у исто време. Ако вам треба 20, покренућемо другу такву капсулу. У потпуности ћемо га клонирати, пошто добијемо други пуни волумен, имаће истих 10 „танких“ клонова. Зар не видите ову прилику?
ДС: Морамо да додамо безбедносна питања овде. Ова врста организације подразумева да овај под има високе привилегије (способности), јер може да обавља нестандардне операције на систему датотека... Али понављам: верујем да ће у средњем року поправити складиште у Кубернетес-у, а у облаци ће поправити целу причу обимима - све ће „прорадити“. Биће промене величине, клонирања... Постоји волумен - кажемо: „Креирај нови на основу тога“ и после секунд и по добијамо оно што нам треба.
НС: Не верујем у једну и по секунду за много терабајта. На Цефу то радиш сам, али причаш о облацима. Идите у облак, направите клон ЕБС запремине од више терабајта на ЕЦ2 и видите какве ће бити перформансе. Неће потрајати неколико секунди. Јако ме занима када ће достићи овај ниво. Разумем шта говорите, али се не слажем.
ДС: Ок, али рекао сам средњорочно, не краткорочно. За неколико година.
О оператеру за ПостгреСКЛ из Заланда
Усред овог састанка, Алексеј Кљукин, бивши програмер из Заланда, такође се придружио и говорио о историји ПостгреСКЛ оператера:
Одлично је што се ова тема дотиче уопштено: и Постгрес и Кубернетес. Када смо то почели да радимо у Заланду 2017. године, то је била тема којом су сви желели да се баве, али нико није. Сви су већ имали Кубернетес, али када су питали шта да раде са базама података, чак и људи воле , који је проповедао К8с, рекао је нешто овако:
„Идите на управљане услуге и користите их, немојте покретати базу података у Кубернетесу. У супротном, ваш К8 ће одлучити, на пример, да изврши надоградњу, искључи све чворове и ваши подаци ће летети далеко, далеко.
Одлучили смо да направимо оператера који ће, супротно овом савету, покренути Постгрес базу података у Кубернетесу. И имали смо добар разлог - . Ово је аутоматски прелазак на грешку за ПостгреСКЛ, урађен исправно, тј. користећи етцд, цонсул или ЗооКеепер као складиште информација о кластеру. Такав репозиторијум који ће свима који питају, на пример, шта је садашњи лидер, дати исте информације – упркос томе што имамо све распоређено – да не дође до расцепа мозга. Плус смо имали за њега.
Генерално, потреба компаније за аутоматским преласком на грешку појавила се након миграције са интерног хардверског центра података у облак. Облак је био заснован на власничком решењу ПааС (Платформ-ас-а-Сервице). Он је отвореног кода, али је било потребно много рада да се покрене. То се звало .
У почетку није постојао Кубернетес. Тачније, када је наше сопствено решење пуштено у рад, К8 је већ постојао, али је био толико сиров да није био погодан за производњу. Било је то, по мом мишљењу, 2015. или 2016. године. До 2017. Кубернетес је постао мање-више зрео — постојала је потреба да се тамо пресели.
И већ смо имали Доцкер контејнер. Постојао је ПааС који је користио Доцкер. Зашто не пробати К8с? Зашто не бисте написали свог оператера? Мурат Кабилов, који нам је дошао из Авита, започео је ово као пројекат самоиницијативно – „да се игра“ – и пројекат је „покренуо“.
Али генерално, желео сам да причам о АВС-у. Зашто је постојао историјски АВС код...
Када покренете нешто у Кубернетес-у, морате схватити да је К8с такав рад у току. Стално се развија, побољшава, па чак и с времена на време квари. Морате пажљиво да пратите све промене у Кубернетесу, морате бити спремни да зароните у то ако се нешто деси и научите како то функционише до детаља – можда и више него што бисте желели. Ово се, у принципу, односи на било коју платформу на којој покрећете своје базе података...
Дакле, када смо урадили изјаву, имали смо Постгрес који ради на спољном волумену (ЕБС у овом случају, пошто смо радили на АВС-у). База података је расла, у неком тренутку је било потребно променити њену величину: на пример, почетна величина ЕБС-а је била 100 ТБ, база података је порасла до ње, сада желимо да ЕБС направимо 200 ТБ. Како? Рецимо да можете да извршите думп/ресторе на новој инстанци, али то ће потрајати дуго и укључивати застоје.
Због тога сам желео промену величине која би повећала ЕБС партицију, а затим рекла систему датотека да користи нови простор. И ми смо то урадили, али у то време Кубернетес није имао никакав АПИ за операцију промене величине. Пошто смо радили на АВС-у, написали смо код за његов АПИ.
Нико вас не спречава да урадите исто за друге платформе. У изјави нема наговештаја да се може покренути само на АВС-у и да неће радити на свему осталом. Генерално, ово је пројекат отвореног кода: ако неко жели да убрза појаву употребе новог АПИ-ја, добродошли сте. Једи , пулл захтеви - Заландо тим покушава да одговори на њих прилично брзо и промовише оператера. Колико ја знам, пројекат на Гоогле Суммер оф Цоде и неким другим сличним иницијативама. Заландо веома активно ради на томе.
ПС Бонус!
Ако сте заинтересовани за тему ПостгреСКЛ-а и Кубернетеса, имајте на уму да је следећи Постгрес уторак одржан прошле недеље, где сам разговарао са Николајем Александар Кукушкин из Заланда. Видео са њега је доступан .
Ппс
Прочитајте и на нашем блогу:
- «";
- «";
- «";
- «'.
Извор: ввв.хабр.цом