У канцы мінуўшчыны гады адбыўся чарговы прамы эфір расійскай PostgreSQL-супольнасці , у рамках якога яго сузаснавальнік Мікалай Самахвалаў пагаварыў з тэхнічным дырэктарам "Фланта" Дзмітрыем Сталяровым пра гэтую СКБД у кантэксце Kubernetes.
Мы публікуем стэнаграму асноўнай часткі гэтай дыскусіі, а на апублікаваны поўны відэазапіс:
Базы дадзеных і Kubernetes
НС: Мы не будзем сёння пра VACUUM і CHECKPOINT’ы. Жадаем пагаварыць пра Kubernetes. Я ведаю, што ў цябе ўжо шмат гадоў досведу. Глядзеў твае відэа і некаторыя нават кавалачкамі пераглядаў… Давай адразу з месца ў кар'ер: навошта наогул Postgres ці MySQL у K8s?
ДС: Адназначнага адказу на гэтае пытанне няма і не можа быць. Але ўвогуле, гэта прастата і зручнасць… патэнцыйныя. Усім жа жадаецца managed-сэрвісаў.
НС: Каб як , толькі ў сябе?
ДС: Так: каб як RDS, толькі дзе заўгодна.
НС: «Дзе заўгодна» - гэта добрая заўвага. У вялікіх кампаніях усё размешчана ў розных месцах. А чаму тады, калі гэта вялікая кампанія, не ўзяць гатовае рашэньне? Напрыклад, ёсць у Nutanix свае распрацоўкі, у іншых кампаній (VMware…) – той жа "RDS, толькі ў сябе".
ДС: Але гэта мы гаворым пра асобна ўзятую рэалізацыю, якая будзе працаваць толькі ў пэўных умовах. А калі гаворка пра Kubernetes, то тут вялізная разнастайнасць інфраструктуры (якая можа быць у K8s). Па сутнасці гэта стандарт для API да воблака…
НС: Яшчэ і бясплатна!
ДС: Гэта не так важна. Бясплатнасць важная не вельмі вялікаму сегменту рынку. Важна іншае… Ты, мусіць, успамінаеш даклад «»?
НС: Так.
ДС: Я зразумеў, што яго ўспрынялі вельмі неадназначна. Частка людзей падумалі, што я кажу: «Хлопцы, паехалі ўсімі БД у Kubernetes!», а іншыя вырашылі, што гэта ўсё жудасныя ровары. А я хацеў сказаць увогуле пра іншае: «Глядзіце, што адбываецца, якія ёсць праблемы і як іх можна вырашаць. Цяпер ехаць базамі ў Kubernetes? Production’ам? Ну толькі калі вы любіце… займацца пэўнымі рэчамі. А вось для dev’а – магу сказаць, што рэкамендую. Для dev’а вельмі важная дынамічнасць стварэння/выдалення акружэнняў».
НС: Пад dev’ом ты маеш на ўвазе ўсе асяроддзі, якія не prod? Staging, QA…
ДС: Калі гаворым пра perf-стэнды, то ўжо, напэўна, не, бо там патрабаванні спецыфічныя. Калі гаворым пра асаблівыя выпадкі, дзе на staging патрэбна вельмі вялікая БД, то таксама, напэўна, не… Калі гэта статычнае асяроддзе, якое доўга жыве, то якая выгада ад таго, што база размешчана ў K8s?
НС: Ніякай. Але дзе мы бачым статычныя асяроддзі? Статычнае асяроддзе састарэла ўжо заўтра.
ДС: Staging можа быць статычным. У нас ёсць кліенты…
НС: Так, у мяне таксама ёсць. Вялікая праблема, калі ў цябе ёсць база на 10 Тб, а staging – 200 Гб…
ДС: У мяне ёсць вельмі круты кейс! На staging знаходзіцца prod'авая база, у якую ўносяць змены. І прадугледжана кнопка: "выкаціць у production". Гэтыя змены – дэльты – даліваюцца (здаецца, проста па API’шцы сінхранізуюцца) у production. Гэта вельмі экзатычны варыянт.
НС: Я бачыў стартапы ў Даліне, якія сядзяць у RDS'е ці нават у Heroku яшчэ - гэта гісторыі 2-3-гадовай даўніны, - і яны спампоўваюць дамп сабе на лаптоп. Таму што база пакуль усяго толькі 80 Гб, а на лаптопе ёсць месца. Потым яны дакупляюць дыскі кожнаму, каб па 3 базы мець, каб розныя распрацоўкі весьці. Вось так бывае таксама. Таксама бачыў, што не баяцца prod капіяваць у staging - вельмі моцна залежыць ад кампаніі. Але бачыў і што вельмі баяцца, і што часта не хапае часу і рук. Але перш, чым мы пяройдзем да гэтай тэмы, жадаецца пачуць пра Kubernetes. Я правільна разумею, што ў prod’е пакуль ні ў кога?
ДС: У нас невялікія базы ёсць у prod’е. Гаворка пра аб'ёмы ў дзясяткі гігабайт і некрытычныя сэрвісы, для якіх лянота было рабіць рэплікі (ды і няма такой патрэбы). І пры ўмове, што пад Kubernetes’ам ёсьць нармальнае сховішча. Гэтая база працавала ў віртуальнай машыне – умоўна ў VMware, па-над СХД. Мы яе змясцілі ў і зараз можам пераносіць яе з машыны на машыну.
НС: Базы такога памеру, да 100 Гб, на добрых дысках і пры добрай сетцы можна раскатаць за некалькі хвілін, правільна? Хуткасць у 1 Гб у секунду - гэта ўжо не экзотыка.
ДС: Так, для лінейнай аперацыі гэта не праблема.
НС: Окей, пра prod мы мусім толькі думаць. А калі мы разглядаем Kubernetes для не-prod-акружэнняў - як рабіць? Я бачу, што ў Zalando , у Crunchy , ёсць яшчэ нейкія варыянты. І ёсць - Гэта наш добры знаёмы Alvaro з Іспаніі: яны робяць па сутнасці не проста , а цэлы дыстрыбутыў (), у які апроч самога Postgres’а яшчэ і бэкап вырашылі запіхаць, проксі Envoy…
ДС: Envoy для чаго? Балансіроўкі менавіта трафіку Postgres?
НС: Так. Гэта значыць яны гэта бачаць як: калі ўзяць Linux-дыстрыбутыў і ядро, то звычайны PostgreSQL - гэта ядро, а яны жадаюць зрабіць дыстрыбутыў, які будзе прыязны да аблокаў і круціцца ў Kubernetes. Яны стыкуюць кампаненты (бэкапы і да т.п.) і адладжваюць, каб яны добра працавалі.
ДС: Вельмі крута! Па сутнасці гэта софт, каб зрабіць свой managed Postgres.
НС: У Linux-дыстрыбутываў вечныя праблемы: як рабіць драйверы, каб усё жалеза падтрымлівалася. А ў іх ідэя, што яны ў Kubernetes будуць працаваць. Я ведаю, што ў аператары Zalando мы нядаўна ўбачылі завязку на AWS і гэта ўжо не вельмі добрае. Не павінна ж быць завязкі на канкрэтную інфраструктуру - у чым тады сэнс?
ДС: Не ведаю, у якой сітуацыі канкрэтна Zalando завязаўся, але ў Kubernetes зараз storage зроблены так, што нельга generic-спосабам зняць дыскавы бэкап. Нядаўна ў стандарце - у апошняй версіі - зрабілі магчымасць снапшотаў, але дзе яна рэалізаваная? Шчыра, усё яшчэ настолькі волкае… Мы спрабуем CSI па-над AWS, GCE, Azure, vSphere, але ледзь пачынаеш выкарыстоўваць, як відаць, што яно яшчэ не гатова.
НС: Таму і даводзіцца часам завязвацца на інфраструктуру. Думаю, гэта яшчэ працягваецца ранняя стадыя - праблемы росту. Пытанне: што б ты параіў пачаткоўцам, якія жадаюць паспрабаваць PgSQL у K8s? Які аператар, можа быць?
ДС: Праблема ў тым, што Postgres для нас - гэта 3%. У нас ёсць яшчэ вельмі вялікі спіс рознага софту ў Kubernetes, не буду нават усё пералічваць. Напрыклад, Elasticsearch. Аператараў - куча: нейкія развіваюцца актыўна, іншыя - не. Мы для сябе склалі патрабаванні, што павінна быць у аператары, каб мы ўспрымалі яго сур'ёзна. У аператары менавіта для Kubernetes – не ў «аператары, каб рабіць нешта ва ўмовах Amazon’а»… Па факце мы дастаткова масава (= амаль ва ўсіх кліентаў) выкарыстоўваем адзіны аператар – (хутка апублікуем артыкул і пра яго).
НС: А для MySQL таксама няма? Я ведаю, што Percona… бо яны зараз займаюцца і MySQL, і MongoDB, і Postgres, яны павінны будуць нейкі ўніверсальны запілаваць: для ўсіх баз, для ўсіх хмарных правайдэраў.
ДС: Мы не паспелі паглядзець на аператары для MySQL. Для нас гэта зараз не галоўны фокус. MySQL нармальна працуе ў standalone. Навошта аператар, калі можаш проста запусціць БД… Можна запусціць Docker-кантэйнер з Postrges, а можна запусціць яго проста.
НС: Пра гэта таксама было пытанне. Наогул без аператара?
ДС: Так, у 100% у нас PostgreSQL запушчаны без аператара. Пакуль што так. Мы актыўна выкарыстоўваем аператар для Prometheus, для Redis. У нас ёсць у планах знайсці аператар для Elasticsearch – ён больш за ўсё "гарыць", таму што хочам яго ў 100% выпадках ставіць у Kubernetes. Гэтак жа, як мы жадаем прыйсці да таго, каб MongoDB таксама заўсёды ставіць у Kubernetes. Тут з'яўляюцца пэўныя жаданні - ёсць адчуванне, што ў гэтых выпадках можна нешта зрабіць. А пра Postgres мы нават не глядзелі. Канешне, ведаем пра існаванне розных варыянтаў, але па факце ў нас standalone.
БД для тэсціравання ў Kubernetes
НС: Давай пяройдзем да тэмы тэсціравання. Як раскочваць змены ў базе – з пункту гледжання DevOps-перспектывы. Ёсць мікрасэрвісы, шмат баз, увесь час недзе нешта мяняецца. Як забяспечыць нармальны CI/CD, каб з пазіцыі СКБД усё было ў парадку. Які ў цябе падыход?
ДС: Не можа быць аднаго адказу. Ёсць некалькі параметраў. Першы - гэта памер базы, якую мы хочам раскачаць. Ты сам згадаў, што ў кампаніях па-рознаму ставяцца да таго, каб копія prod-базы была на dev і stage.
НС: А ва ўмовах GDPR, я думаю, яны ставяцца ўсё больш і больш акуратна… Магу сказаць, што ў Еўропе ўжо пачалі штрафаваць.
ДС: Але часта можна напісаць софт, які робіць дамп з production’а і яго абфусуе. Атрымліваюцца prod’авыя дадзеныя (снапшот, дамп, бінарная копія…), але яны ананімаваныя. Замест гэтага могуць быць і скрыпты генерацыі: гэта могуць быць фікстуры ці проста скрыпт, які генеруе вялікую базу. Праблема якая: колькі часу ствараецца базавы вобраз? І колькі часу разгарнуць яго на патрэбным асяроддзі?
Мы дашлі да схемы: калі ў кліента ёсць фікстурны набор дадзеных (мінімальная версія базы), то па змаўчанні выкарыстаем іх. Калі гаворка ідзе пра review-акружэнні, калі мы стварылі branch, у нас разгарнуўся асобнік прыкладання мы туды раскочваем маленькую базу. Але добра атрымаўся і , Калі з production’а раз у суткі (уначы) здымаем дамп і збіраем на яго падставе Docker-кантэйнер з PostgreSQL і MySQL з гэтымі загружанымі дадзенымі. Калі з гэтай выявы трэба 50 раз разгарнуць базу, гэта робіцца досыць проста і хутка.
НС: Простым капіраваннем?
ДС: Дадзеныя захоўваюцца прама ў Docker-ладзе. Г.зн. у нас ёсць гатовы вобраз, няхай на 100 Гб. Дзякуючы пластам у Docker мы можам хутка разгортваць гэты вобраз патрэбную колькасць разоў. Спосаб тупы, але працуе нядрэнна.
НС: Далей, калі тэстуеце, яно прама ўсярэдзіне Docker’а мяняецца, так? Copy-on-write усярэдзіне Docker’а – выкідваем і зноўку паехалі, усё добра. Клас! І вы гэта ўжо карыстаецеся на ўсю моц?
ДС: Даўно.
НС: Мы вельмі падобнымі рэчамі займаемся. Толькі мы не Docker’аўскі copy-on-write выкарыстоўваем, а які-небудзь яшчэ.
ДС: Ён не generic. А Docker’ны працуе паўсюдна.
НС: Па ідэі, так. Але ў нас таксама там ёсць модулі, можна розныя модулі зрабіць і працаваць з рознымі файлавымі сістэмамі. Тут які момант. Мы з боку Postgres’а на ўсё гэта па-іншаму глядзім. Цяпер я паглядзеў з боку Docker’а і ўбачыў, што ў вас усё працуе. Але калі база – велізарная, напрыклад, 1 Тб, то гэта ўжо ўсё доўга: і аперацыі ўначы, і запіхваць усё ў Docker… А калі 5 Тб запіхваць у Docker… Ці ўсё нармальна?
ДС: Якая розніца: гэта ж блобы, проста бітыя і байты.
НС: Розніца такая: вы гэта праз dump і restore робіце?
ДС: Зусім неабавязкова. Спосабы генерацыі гэтай выявы могуць быць розныя.
НС: Для некаторых кліентаў мы зрабілі так, што замест рэгулярнай генерацыі базавай выявы мы яго стала падтрымліваем у актуальным стане. Ён па сутнасці з'яўляецца рэплікай, але даныя атрымлівае не з майстра напрамую, а праз архіў. Бінарны архіў, куды WAL’ы накатваюцца кожны дзень, там жа бэкапы здымаюцца… Гэтыя WAL’ы потым далятаюць – з невялікай затрымкай (літаральна 1-2 секунды) – да базавай выявы. З яго мы любым спосабам клануем – зараз па змаўчанні ў нас ZFS.
ДС: Але з ZFS вы абмежаваныя адным вузлом.
НС: Так. Але ў ZFS ёсць яшчэ чароўны : з ім можна паслаць снапшот і нават (я гэта яшчэ не вельмі тэсціраваў, але…) можна дасылаць дэльту паміж двума PGDATA. Насамрэч, у нас яшчэ адна прылада, якую мы не асоба разглядалі для такіх задач. У PostgreSQL ёсць , Які працуе як «разумны» rsync, прапускалы шматлікае з таго, што можна не глядзець, таму што там сапраўды нічога не змянялася. Мы можам паміж двума серверамі зрабіць хуткую сінхранізацыю і адкруціць назад сапраўды гэтак жа.
Дык вось, мы стараемся з гэтага, больш DBA'нага, боку зрабіць інструмент, які дазваляе зрабіць тое ж самае, пра што ты казаў: у нас ёсць адна база, але мы хочам 50 разоў нешта пратэставаць, ледзь не адначасова.
ДС: 50 разоў азначае, што вам трэба замовіць 50 Spot’авых інстансаў.
НС: Не, на адной машыне ўсё робім.
ДС: Але як вы разгорнеце 50 разоў, калі гэта адна база, скажам, тэрабайтавая. Хутчэй за ўсё ёй трэба ўмоўна 256 Гб RAM?
НС: Так, памяці часам трэба шмат - гэта нармальна. Але такі прыклад з жыцця. На production-машыне 96 ядраў і 600 Гб. Пры гэтым для БД выкарыстоўваюцца 32 ядры (нават 16 ядраў зараз часам) і памяці 100-120 Гб.
ДС: І туды залазіць 50 копій?
НС: Дык копія вось адна, далей працуе copy-on-write (ZFS’ны)… Раскажу падрабязней.
У нас, напрыклад, база на 10 Тб. Дыск для яе зрабілі, ZFS яшчэ сціснуў яе памер працэнтаў на 30-40. Паколькі мы не які робіцца нагрузачнае тэставанне, нам дакладны час водгуку не важна: хай будзе да 2 раз тармазней гэта окей.
Мы даем магчымасць праграмістам, QA, DBA і да т.п. выконваць тэсціраванне ў 1-2 патоку. Напрыклад, яны могуць запусціць нейкую міграцыю. Яна не патрабуе адразу 10 ядраў – ёй патрэбен 1 бэкэнд Postgres’а, 1 ядро. Міграцыя запусціцца - можа, яшчэ запусціцца, тады другое ядро задзейнічаецца. У нас выдзелена 16-32 ядры, так што 10 чалавек могуць адначасова працаваць, ніякіх праблем няма.
Паколькі фізічна PGDATA аднолькавая, атрымліваецца так, што мы падманваем Postgres насамрэч. Фішка ў чым: запускаецца, напрыклад, 10 Postgres'аў адначасова. Праблема звычайна якая? Ставяць , дапусцім, у 25%. Адпаведна, гэта 200 Гігабайт. Больш за трох такіх ужо не запусціш, таму што памяць скончыцца.
Але мы ў нейкі момант зразумелі, што гэта не трэба: мы ставім shared_buffers у 2 Гб. у PostgreSQL ёсць , і ў рэальнасці толькі ён уплывае на . Яго мы і ставім у 0,5 Тб. І нават не важна, што іх насамрэч няма: ён будуе планы, як быццам яны ёсць.
Адпаведна, калі мы тэстуем нейкую міграцыю, можна сабраць усе планы – мы ўбачым, як яно будзе адбывацца на production. Секунды там будуць іншыя (тармазнейшыя), але дадзеныя, якія мы рэальна счытваем, і самі планы (якія там JOIN’ы і да т.п.) атрымліваюцца сапраўды такімі ж, як на production. І раўналежна можна запускаць мноства такіх праверак на адной машыне.
ДС: Ты не лічыш, што тут ёсць некалькі праблем? Першая - гэта рашэнне, якое працуе толькі на PostgreSQL. Такі падыход - вельмі прыватны, ён не generic. Другая – Kubernetes (і ўсё, куды цяпер ідуць хмарныя тэхналогіі) мяркуе мноства вузлоў, і гэтыя вузлы – эфемерныя. А у тваім выпадку гэта stateful, персістэнтны вузел. Гэтыя рэчы ў мяне выклікаюць супярэчнасці.
НС: Першае - згодны, гэта чыста Postgres'авая гісторыя. Думаю, калі ў нас ёсць які-небудзь direct IO і буферны пул амаль пад усю памяць, такі падыход не падыдзе - планы будуць іншыя. Але мы пакуль толькі з Postgres'ам і працуем, пра іншых не думаем.
Пра Kubernetes. Ты ж сам усюды расказваеш, што ў нас база персістэнтная. Калі інстанс упаў, галоўнае - захаваць дыск. Вось у нас таксама ўся платформа ў Kubernetes, а кампанент з Postgres – асобна (хоць і ён там аднойчы будзе). Таму ўсё так: інстанс упаў, але мы захавалі яго PV і проста падключылі да іншага (новаму) інстансу, як быццам нічога не здарылася.
ДС: З майго пункту гледжання, мы ствараем pod’ы ў Kubernetes. K8s - эластычны: вузлы заказваюцца самі па меры неабходнасці. Задача проста стварыць pod і сказаць, што яму трэба X рэсурсаў, а далей K8s сам разбярэцца. Але падтрымка сховішчаў у Kubernetes па-ранейшаму нестабільная: у , У (гэты рэліз выйшаў тыдня таму) гэтыя фічы становяцца толькі бэтай.
Пройдзе паўгода-год - яно стане больш-менш стабільным, ці хаця б будзе заяўлена такім. Тады магчымасць снапшотаў і resize’а ўжо вырашае вашу задачу поўнасцю. Бо ў вас ёсць база. Так, яна можа быць не вельмі хуткай, але хуткасць залежыць ад таго, што пад капотам , таму што некаторыя рэалізацыі ўмеюць капіяванне і copy-on-write на ўзроўні дыскавай падсістэмы.
НС: Тут жа трэба яшчэ, каб усе рухавічкі (Amazon, Google…) паспелі пачаць падтрымліваць гэтую версію - гэта ж таксама нейкі час займае.
ДС: Пакуль мы іх не выкарыстоўваем. Мы выкарыстоўваем сваё.
Лакальная распрацоўка пад Kubernetes
НС: Ці сутыкаўся ты з такой хацелкай, калі трэба на адной машыне падняць усе pod’ы і зрабіць такое маленькае тэставаньне. Каб па-хуткаму атрымаць proof of concept, паглядзець, што прыкладанне працуе ў Kubernetes, не вылучаючы пад гэта кучу машын. Ёсць Minikube, так?
ДС: Мне здаецца, гэты кейс - на адным вузле разгарнуць - пра лакальную распрацоўку выключна. Або нейкія праявы такога патэрна. Ёсць , ёсць , . Мы ідзем да таго, што будзем выкарыстоўваць Kubernetes IN Docker. Цяпер пачалі з ім працаваць для тэстаў.
НС: Я раней думаў, што гэта спроба загарнуць усе pod’ы ў адзін Docker-выява. Але аказалася, што гэта зусім пра іншае. Усё роўна там асобныя кантэйнеры, асобныя pod’ы - проста ў Docker'е.
ДС: Так. І там дастаткова пацешная імітацыя зроблена, але сэнс такі… У нас ёсць утыліта для дэплою — . Мы хочам у ёй зрабіць рэжым - умоўна. werf up: «Паднімі мне лакальны Kubernetes». І далей запусціць там умоўны werf follow. Тады распрацоўнік зможа кіраваць у IDE, а ў сістэме запушчаны працэс, які бачыць змены і перазбірае выявы, перадаплаўвае іх у лакальны K8s. Так мы жадаем паспрабаваць вырашыць праблему лакальнай распрацоўкі.
Снапшоты і кланаванне БД у рэаліях K8s
НС: Калі вярнуцца да copy-on-write. Я заўважыў, што ў аблокаў таксама ёсць снапшоты. Яны працуюць па-рознаму. Напрыклад, у GCP: у цябе на ўсходнім узбярэжжы ЗША ёсць шматтэрабайтны інстанс. Робіш перыядычна снапшоты. Падымаеш з снапшота копію дыска на заходнім узбярэжжы - праз некалькі хвілін ужо ўсё гатова, працуе вельмі хутка, толькі кэш трэба запоўніць у памяці. Але гэтыя клоны (снапшоты) – для таго, каб за'provision’іць новы том. Гэта крута, калі трэба шмат інстанс стварыць.
А вось для тэстаў, мне здаецца, снапшоты, пра якія ты распавядаеш у Docker’е ці я распавядаю ў ZFS, btrfs і нават LVM… яны дазваляюць як раз на адной машыне не рабіць рэальна новыя дадзеныя. У воблаку ты яшчэ плаціць за іх кожны раз будзеш і чакаць ужо не секунды, а хвіліны (а ў выпадку , магчыма, і гадзіннік).
Замест гэтага можна за секунду-дзве атрымаць гэтыя даныя, паганяць тэст і выкінуць. Гэтыя снапшоты вырашаюць розныя задачы. У першым выпадку - каб адмаштабавацца і новыя рэплікі атрымаць, а ў другім - для тэстаў.
ДС: Не пагаджуся. Зрабіць нармальна кланаванне тамоў - гэта задача аблокі. Я не глядзеў іх рэалізацыю, але ведаю, як гэта які робіцца мы на жалезе. У нас ёсць Ceph, у ім можна любому фізічнаму таму () сказаць кланаваць і атрымаць за дзясяткі мілісекунд другі том з такімі ж характарыстыкамі, Вамі і да т.п. Трэба разумець, што там усярэдзіне хітры copy-on-write. Чаму воблаку не рабіць гэтак жа? Упэўнены, што яны так ці інакш імкнуцца гэта зрабіць.
НС: Але ў іх усё роўна сыдуць секунды, дзясяткі секунд, каб падняць інстанс, прывесці туды Docker і г.д.
ДС: Чаму абавязкова цэлы інстанс узнімаць? У нас жа ёсць інстанс на 32 ядры, на 16… і ў яго колькісьці залазіць — напрыклад, чатыры. Калі мы пяты заказваем, ужо паднімецца інстанс, а потым ён выдаліцца.
НС: Так, цікава, у Kubernetes атрымліваецца іншая гісторыя. У нас БД не ў K8s, і адзін інстанс. Затое на кланаванне шматтэрабайтнай базы ідзе не больш за дзве секунды.
ДС: Гэта крута. Але мой першапачатковы пасыл у тым, што гэта не generic-рашэнне. Так, яно класнае, але падыходзіць толькі Postgres і толькі на адным вузле.
НС: Яно падыходзіць не толькі для Postgres: гэта планы, як я апісваў, будуць так працаваць толькі ў ім. Але калі не затлумляцца з нагоды планаў, а нам проста патрэбныя ўсе дадзеныя для функцыянальнага тэставання, тады гэта падыдзе для любой СКБД.
ДС: Шмат гадоў таму мы рабілі падобнае на LVM-снапшотах. Гэта класіка. Такі падыход вельмі актыўна выкарыстоўваўся. Проста stateful-вузлы - гэта боль. Таму што іх трэба не губляць, заўсёды пра іх памятаць…
НС: Ці не бачыш ты тут нейкай магчымасці гібрыда? Дапушчальны, stateful гэта pod нейкі, ён працуе на некалькіх людзей (шмат тэстыравальнікаў). Том у нас адзін, але дзякуючы файлавай сістэме клоны - лакальныя. Калі pod зваліўся, дыск застаўся паднімецца pod, інфармацыю аб усіх клонах лічыць, усё зваротна падніме і скажа: "Вось вашы клоны на гэтых партах запушчаныя, працуйце з імі далей".
ДС: Тэхнічна гэта азначае, што ў рамках Kubernetes гэта адзін pod, унутры якога мы запускаем шмат Postgres’аў.
НС: Так. У яго ёсць ліміт: дапусцім, адначасова з ім працуюць не больш за 10 чалавек. Калі трэба 20 - запусцім другі такі pod. Цалкам рэальна склануем яго, атрымаўшы другі поўны том, на ім будуць такія ж 10 "тонкіх" клонаў. Не бачыш такой магчымасці?
ДС: Трэба дадаць сюды пытанні бяспекі. Такі варыянт арганізацыі мае на ўвазе, што ў гэтага pod'а высокія прывілеі (capabilities), таму што ён можа выконваць нестандартныя аперацыі над файлавай сістэмай… Але паўтаруся: я лічу, што ў сярэднетэрміновай даляглядзе ў Kubernetes паправяць storage, у аблоках паправяць усю гісторыю з тамамі - усё будзе «проста працаваць». Будзе resize, кланаванне... Ёсць тым - мы кажам: "Ствары новы на аснове таго", - і праз паўтары секунды атрымліваем што трэба.
НС: Не веру ў паўтары секунды для многіх тэрабайт. На Ceph ты робіш сам, а кажаш пра аблокі. Ідзі ў воблака, на EC2 зрабі клон тома EBS многіх тэрабайт і паглядзі, якая прадукцыйнасць будзе. Гэта не зойме некалькі секунд. Мне вельмі цікава, калі яны дойдуць да такога паказчыка. Разумею, аб чым ты гаворыш, але дазволю сабе не пагадзіцца.
ДС: Ок, але я сказаў, што ў сярэднетэрміновай перспектыве, не кароткатэрміновай. На працягу некалькіх год.
Пра аператар для PostgreSQL ад Zalando
У сярэдзіне гэтай сустрэчы да яе таксама далучыўся Аляксей Клюкін, былы распрацоўшчык з кампаніі Zalando, які распавёў пра гісторыю аператара PostgreSQL:
Выдатна, што ўвогуле гэтая тэма закранута: і Postgres, і Kubernetes. Калі мы пачыналі яе рабіць у Zalando у 2017-м годзе, гэта была такая тэма, якой усе хацелі займацца, але ніхто не рабіў. Ва ўсіх ужо з'яўляўся Kubernetes, але калі пыталіся, што рабіць з базамі дадзеных, то нават такія людзі, як , якія прапаведавалі K8s, казалі прыкладна наступнае:
«Ідзіце ў managed-сэрвісы і выкарыстоўвайце іх, не запускайце БД у Kubernetes. Інакш ваш K8s вырашыць, напрыклад, зрабіць апгрэйд, патушыць усе вузлы, і вашы дадзеныя паляцяць далёка-далёка».
Мы вырашылі зрабіць аператар, які будзе, насуперак гэтай радзе, запускаць БД Postgres у Kubernetes. І ў нас была добрая падстава — . Гэта аўтаматычны failover для PostgreSQL, зроблены правільна, г.зн. які выкарыстоўвае etcd, consul або ZooKeeper у якасці сховішчы інфармацыі аб кластары. Такога сховішча, якое будзе аддаваць усім, хто пытаецца, напрыклад, які зараз лідэр, адну і тую ж інфармацыю - нягледзячы на тое, што ў нас усё размеркаванае, - каб не было split brain’а. Плюс, у нас быў для яго.
Наогул, запатрабаванне ў auto failover у кампаніі з'явілася пасля міграцыі з унутранага жалезнага дата-цэнтра ў воблака. Воблака было заснавана на ўласным рашэнні PaaS (Platform-as-a-Service). Яно Open Source’нае, але каб яго падняць, трэба было моцна папрацаваць. Звалася .
Першапачаткова ніякага Kubernetes’а не было. Дакладней, калі разгортвалася ўласнае рашэнне, K8s ужо быў, але настолькі волкім, што для production не падыходзіў. Гэта быў, на маю думку, 2015 ці 2016 год. Да 2017-га года Kubernetes стаў больш-менш сталым - з'явілася неабходнасць міграцыі туды.
І ў нас ужо быў Docker-кантэйнер. Была PaaS, якая выкарыстоўвала Docker. Чаму б не паспрабаваць K8s? Чаму б не напісаць свой аператар? Мурат Кабілаў, які прыйшоў да нас з Авіта, пачаў гэта як праект па ўласнай ініцыятыве - "пагуляць", - і праект "узляцеў".
Але наогул я хацеў расказаць пра AWS. Чаму там быў гістарычна код, звязаны з AWS…
Калі вы запускаеце штосьці ў Kubernetes, трэба разумець, што K8s - гэта такі work in progress. Ён увесь час развіваецца, паляпшаецца і перыядычна нават ламаецца. Трэба сачыць уважліва за ўсімі зменамі ў Kubernetes, трэба быць гатовым у выпадку чаго пагрузіцца ў яго і даведацца, як працуе ў дэталях - магчыма, больш, чым вам бы хацелася. Гэта, у прынцыпе, у любой платформы, на якой вы запускаеце свае БД…
Такім чынам, калі мы рабілі аператар, у нас быў Postgres, які працаваў з вонкавым томам (у дадзеным выпадку – EBS, паколькі мы працавалі ў AWS). База дадзеных расла, у нейкі момант запатрабавалася зрабіць resize: напрыклад, першапачатковы памер EBS – 100 Тб, база дарасла да яго, зараз жадаем зрабіць EBS у 200 Тб. Як? Дапушчальны, можна зрабіць dump/restore на новы інстанс, але гэта доўга і з прастоем.
Таму хацелася такі resize, які будзе павялічваць падзел EBS’а і потым казаць файлавай сістэме сістэме выкарыстоўваць новую прастору. І мы гэта зрабілі, але ў той час у Kubernetes’а не было ніякага API для апэрацыі resize’а. Паколькі мы працавалі на AWS, мы напісалі код для яго API.
Ніхто не перашкаджае зрабіць тое ж самае для іншых платформ. У аператары няма завязкі, што яго можна запусціць толькі на AWS, а на ўсім астатнім ён працаваць не будзе. Увогуле, гэта Open Source-праект: калі хто-небудзь жадае паскорыць з'яўленне выкарыстання новага API – калі ласка. Ёсць , pull-запыты – каманда Zalando імкнецца даволі аператыўна на іх рэагаваць і прасоўваць аператар. Наколькі ведаю, праект у Google Summer of Code і нейкіх іншых падобных ініцыятывах. Zalando над ім вельмі актыўна працуе.
PS Бонус!
Калі вас цікавіць тэма PostgreSQL і Kubernetes, то звяртаем таксама ўвагу, што на мінулым тыдні адбыўся наступны Postgres-аўторак, дзе з Мікалаем меў зносіны Аляксандр Кукушкін з Zalando. Відэа з яго даступна .
PPS
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com