Кратак преглед ПостгреСКЛ изјава за Кубернетес, наш избор и искуство

Клијенти све чешће добијају следеће захтеве: „Желимо као Амазон РДС, али јефтиније“; „Желимо га као РДС, али свуда, у било којој инфраструктури. Да бисмо имплементирали овакво управљано решење на Кубернетес, погледали смо тренутно стање најпопуларнијих оператера за ПостгреСКЛ (Столон, оператери из Црунцхи Дата и Заландо) и направили свој избор.

Овај чланак је искуство које смо стекли и са теоријске тачке гледишта (преглед решења) и са практичне стране (шта је изабрано и шта је из тога произашло). Али прво, хајде да утврдимо који су општи захтеви за потенцијалну замену за РДС...

Шта је РДС

Када људи говоре о РДС-у, према нашем искуству, они мисле на управљану ДБМС услугу која:

1. лако се конфигурише;
2. има способност да ради са снимцима и да се опорави од њих (пожељно уз подршку ПИТР);
3. омогућава вам да креирате топологије мастер-славе;
4. има богату листу екстензија;
5. обезбеђује ревизију и управљање корисницима/приступом.

Уопштено говорећи, приступи имплементацији задатка могу бити веома различити, али пут са условним Ансибле-ом није нам близак. (Колеге из 2ГИС-а су као резултат дошле до сличног закључка његов покушај креирајте „алат за брзо постављање кластера за превазилажење грешке заснованог на Постгресу.“)

Оператори су уобичајен приступ за решавање сличних проблема у Кубернетес екосистему. Технички директор „Фланте” је већ говорио детаљније о њима у вези са базама података покренутим унутар Кубернетеса. дистолУ један од његових извештаја.

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

Постоји неколико популарних К8с оператера за ПостгреСКЛ:

• Столон;
• Црунцхи Дата ПостгреСКЛ Оператор;
• Заландо Постгрес Оператор.

Погледајмо их пажљивије.

Избор оператера

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

• распоређивање са Гита и са Прилагођени ресурси;
• подршка против афинитета;
• инсталирање афинитета чворова или селектора чворова;
• постављање толеранција;
• доступност могућности подешавања;
• разумљиве технологије па чак и команде.

Не улазећи у детаље о свакој од тачака (питајте у коментарима да ли и даље имате питања о њима након што прочитате цео чланак), приметићу генерално да су ови параметри потребни за прецизније описивање специјализације чворова кластера како би се наручите их за одређене примене. На тај начин можемо постићи оптималну равнотежу у погледу перформанси и трошкова.

Сада пређимо на саме ПостгреСКЛ операторе.

1. Столон

Столон из италијанске компаније Соринт.лаб у већ поменути извештај сматран је својеврсним стандардом међу оператерима за ДБМС. Ово је прилично стар пројекат: његово прво јавно објављивање одржано је у новембру 2015. (!), а ГитХуб спремиште има скоро 3000 звездица и 40+ сарадника.

Заиста, Столон је одличан пример промишљене архитектуре:

Уређај овог оператера можете детаљно пронаћи у извештају одн пројектну документацију. Уопштено говорећи, довољно је рећи да може да ради све што је описано: прелазак на грешку, проксији за транспарентан приступ клијенту, резервне копије... Штавише, проксији обезбеђују приступ преко једне услуге крајње тачке – за разлику од друга два решења о којима се говори у наставку (сваки имају по две услуге за приступ бази).

Међутим, Столон нема прилагођених ресурса, због чега се не може применити на начин да је лако и брзо – „као врући колачи“ – креирати ДБМС инстанце у Кубернетесу. Управљање се врши преко комуналног предузећа stolonctl, имплементација се врши преко Хелм графикона, а прилагођени су дефинисани и специфицирани у ЦонфигМап-у.

С једне стране, испоставља се да оператор заправо није оператор (на крају крајева, не користи ЦРД). Али с друге стране, то је флексибилан систем који вам омогућава да конфигуришете ресурсе у К8с како вам одговара.

Да резимирамо, нама лично се није чинило оптималним да креирамо посебан графикон за сваку базу података. Стога смо почели да тражимо алтернативе.

2. Црунцхи Дата ПостгреСКЛ Оператор

Оператер из Црунцхи Дата, млади амерички стартап, изгледао је као логична алтернатива. Његова јавна историја почиње првим издањем у марту 2017. године, од тада ГитХуб спремиште је добило нешто мање од 1300 звездица и 50+ сарадника. Најновије издање из септембра тестирано је за рад са Кубернетес 1.15-1.18, ОпенСхифт 3.11+ и 4.4+, ГКЕ и ВМваре Ентерприсе ПКС 1.3+.

Архитектура Црунцхи Дата ПостгреСКЛ Оператор такође испуњава наведене захтеве:

Управљање се одвија преко услужног програма pgo, међутим, он заузврат генерише прилагођене ресурсе за Кубернетес. Стога нас је оператер обрадовао као потенцијалне кориснике:

• постоји контрола преко ЦРД-а;
• практично управљање корисницима (такође преко ЦРД-а);
• интеграција са другим компонентама Црунцхи Дата Цонтаинер Суите — специјализована колекција слика контејнера за ПостгреСКЛ и услужних програма за рад са њим (укључујући пгБацкРест, пгАудит, екстензије из цонтриб-а, итд.).

Међутим, покушаји да се почне са коришћењем оператера из Црунцхи Дата открили су неколико проблема:

• Није било могућности толеранције - обезбеђен је само нодеСелецтор.
• Креирани подови су били део Деплоимент-а, упркос чињеници да смо применили апликацију са стањем. За разлику од СтатефулСетс-а, Деплоиментс не могу креирати дискове.

Последњи недостатак доводи до смешних тренутака: на тестном окружењу успели смо да покренемо 3 реплике са једним диском локално складиште, што је довело до тога да оператер пријави да 3 реплике раде (иако нису).

Још једна карактеристика овог оператера је његова готова интеграција са разним помоћним системима. На пример, лако је инсталирати пгАдмин и пгБоунце и у документација разматрају се унапред конфигурисани Графана и Прометеј. У новије издање 4.5.0-бета1 побољшана интеграција са пројектом је посебно наведена пгМонитор, захваљујући чему оператер нуди јасну визуализацију ПгСКЛ метрика из кутије.

Међутим, чудан избор ресурса које генерише Кубернетес довео нас је до потребе да пронађемо другачије решење.

3. Заландо Постгрес Оператор

Заландо производе познајемо дуго: имамо искуства у коришћењу Заленијума и, наравно, покушали смо покровитељ је њихово популарно ХА решење за ПостгреСКЛ. О приступу компаније стварању Постгрес Оператор један од њених аутора, Алексеј Кљукин, рекао је у етру Постгрес-Уторак #5, и свидело нам се.

Ово је најмлађе решење о коме се говори у чланку: прво издање је одржано у августу 2018. Међутим, упркос малом броју формалних издања, пројекат је прешао дуг пут, већ је превазишао по популарности решење из Црунцхи Дата са 1300+ звездица на ГитХуб-у и максималним бројем сарадника (70+).

„Испод хаубе“ овај оператер користи времена тестирана решења:

• Патрони и Спило за вожњу,
• ВАЛ-Е - за резервне копије,
• ПгБоунцер - као базен везе.

Овако је представљена архитектура оператера из Заланда:

Оператером се у потпуности управља преко прилагођених ресурса, аутоматски креира СтатефулСет из контејнера, који се затим може прилагодити додавањем различитих приколица у под. Све ово је значајна предност у поређењу са оператером из Црунцхи Дата.

Пошто смо међу 3 разматране опције изабрали решење из Заланда, у наставку ће бити представљен даљи опис његових могућности, одмах уз праксу примене.

Вежбајте са Постгрес Оператором из Заланда

Примена оператера је веома једноставна: само преузмите тренутно издање са ГитХуб-а и примените ИАМЛ датотеке из директоријума манифеста. Алтернативно, такође можете користити операторһуб.

Након инсталације, требало би да бринете о подешавању складиште за дневнике и резервне копије. Ово се ради преко ЦонфигМап-а postgres-operator у именском простору у који сте инсталирали оператера. Када су спремишта конфигурисана, можете да примените свој први ПостгреСКЛ кластер.

На пример, наша стандардна примена изгледа овако:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

Овај манифест распоређује групу од 3 инстанце са приколицом у форми постгрес_екпортер, из које узимамо метрику апликације. Као што видите, све је врло једноставно, а ако желите, можете креирати буквално неограничен број кластера.

Вреди обратити пажњу панел за веб администрацију - постгрес-оператор-уи. Долази са оператером и омогућава вам креирање и брисање кластера, као и рад са резервним копијама које је направио оператер.

Листа ПостгреСКЛ кластера

Управљање резервним копијама

Још једна занимљива карактеристика је подршка АПИ тимова. Овај механизам се аутоматски креира улоге у ПостгреСКЛ-у, на основу резултирајуће листе корисничких имена. АПИ вам тада омогућава да вратите листу корисника за које се улоге аутоматски креирају.

Проблеми и решења

Међутим, употреба оператера убрзо је открила неколико значајних недостатака:

1. недостатак подршке за нодеСелецтор;
2. немогућност онемогућавања резервних копија;
3. када користите функцију креирања базе података, подразумеване привилегије се не појављују;
4. Понекад документација недостаје или је застарела.

На срећу, многи од њих се могу решити. Почнимо од краја - проблеми са документацију.

Највероватније ћете наићи на чињеницу да није увек јасно како да региструјете резервну копију и како да повежете резервну копију са корисничким интерфејсом оператера. Документација о томе говори успутно, али прави опис је унутра PR:

1. потреба да се направи тајна;
2. пренети га оператору као параметар pod_environment_secret_name у ЦРД са подешавањима оператера или у ЦонфигМап (у зависности од тога како одлучите да инсталирате оператера).

Међутим, како се испоставило, то је тренутно немогуће. Зато смо сакупили ваша верзија оператера са неким додатним развојем трећих страна. За више информација о томе, погледајте испод.

Ако оператору проследите параметре за резервну копију, наиме - wal_s3_bucket и приступне кључеве у АВС С3, затим то направиће резервну копију свега: не само базе у продукцији, већ и инсценације. Ово нам није одговарало.

У опису параметара за Спило, који је основни Доцкер омот за ПгСКЛ када се користи оператор, испоставило се: можете проследити параметар WAL_S3_BUCKET празан, чиме се онемогућавају резервне копије. Штавише, на велику радост, открио сам спреман ПР, који смо одмах прихватили у нашу виљушку. Сада само треба да додате enableWALArchiving: false на ресурс кластера ПостгреСКЛ.

Да, постојала је прилика да се то уради другачије покретањем 2 оператера: један за постављање (без резервних копија), а други за производњу. Али успели смо да се задовољимо једним.

У реду, научили смо како да пренесемо приступ базама података за С3 и резервне копије су почеле да улазе у складиште. Како направити резервне странице да раде у корисничком интерфејсу оператера?

Мораћете да додате 3 променљиве корисничком интерфејсу оператера:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

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

Још једна предност је био рад са тимским АПИ-јем и широке могућности за креирање база података и улога помоћу алата оператера. Међутим, створени улоге подразумевано нису имале права. Сходно томе, корисник са правима читања није могао да чита нове табеле.

Зашто је то? Упркос чињеници да у код ту је неопходно GRANT, не користе се увек. Постоје 2 методе: syncPreparedDatabases и syncDatabases. У syncPreparedDatabases - упркос чињеници да је у одељку preparedDatabases ту је постоји услов defaultRoles и defaultUsers за креирање улога, подразумевана права се не примењују. У процесу смо припреме закрпе како би се ова права аутоматски применила.

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

Шта се десило?

На основу резултата решавања наведених проблема, рачвали смо Постгрес Оператор из Заланда ваше спремиште, где се сакупља са тако корисним закрпама. А за већу погодност, такође смо прикупили Доцкер слика.

Листа ПР-ова прихваћених у форк:

• изградња безбедне лаке слике за оператера у Доцкер-у;
• онемогућавање прављења резервних копија;
• ажурирање верзија ресурса за тренутне верзије к8с;
• имплементација Ноде Аффинити.

Биће сјајно ако заједница подржи ове ПР-ове тако да они буду узводно са следећом верзијом оператера (1.6).

Бонус! Прича о успеху миграције производње

Ако користите Патрони, производња уживо се може пренети на оператера са минималним застојима.

Спило вам омогућава да креирате кластера у стању приправности преко С3 складиштења са Вал-Е, када се ПгСКЛ бинарни дневник прво складишти у С3, а затим испумпава реплика. Али шта да радите ако имате не користи Вал-Е на старој инфраструктури? Решење за овај проблем је већ било је предложено на чворишту.

ПостгреСКЛ логичка репликација долази у помоћ. Међутим, нећемо улазити у детаље о томе како креирати публикације и претплате, јер... наш план је био фијаско.

Чињеница је да је база података имала неколико учитаних табела са милионима редова, које су се, штавише, стално допуњавале и брисале. Једноставна претплата с copy_data, када нова реплика копира сав садржај са мастера, једноставно не може да прати мастер. Копирање садржаја је радило недељу дана, али никада није сустигло мајстора. На крају, то ми је помогло да решим проблем чланак колеге из Авито: можете пренети податке користећи pg_dump. Описаћу нашу (мало модификовану) верзију овог алгоритма.

Идеја је да можете направити онемогућену претплату везану за одређени слот за репликацију, а затим исправити број трансакције. На располагању су биле реплике за производни рад. Ово је важно јер ће реплика помоћи да се направи конзистентан думп и настави да прима промене од мастера.

Наредне команде које описују процес миграције ће користити следеће нотације хоста:

1. мајстор — изворни сервер;
2. реплица1 — стриминг реплика на старој продукцији;
3. реплица2 - нова логичка реплика.

План миграције

1. Креирајте претплату на мастер за све табеле у шеми public база dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. Направите слот за репликацију на главном:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. Зауставите репликацију на старој реплици:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. Добијте број трансакције од мастера:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. Уклоните думп са старе реплике. То ћемо урадити у неколико нити, што ће помоћи да се убрза процес:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. Отпремите думп на нови сервер:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. Након преузимања думп-а, можете започети репликацију на реплици за стримовање:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. Креирајмо претплату на нову логичку реплику:

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. Хајдемо oid претплате:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. Рецимо да је примљено oid=1000. Хајде да применимо број трансакције на претплату:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. Почнимо репликацију:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. Проверите статус претплате, репликација би требало да ради:

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. Након што се репликација покрене и базе података синхронизују, можете се пребацити.

13. Након онемогућавања репликације, потребно је да исправите секвенце. Ово је добро описано у чланку на вики.постгрескл.орг.

Захваљујући овом плану, прелазак је обављен са минималним кашњењима.

Закључак

Кубернетес оператери вам омогућавају да поједноставите различите радње тако што их сведете на креирање К8с ресурса. Међутим, пошто сте уз њихову помоћ постигли изузетну аутоматизацију, вреди запамтити да она може донети и бројне неочекиване нијансе, па мудро бирајте своје оператере.

Узимајући у обзир три најпопуларнија Кубернетес оператера за ПостгреСКЛ, изабрали смо пројекат из Заланда. И са тим смо морали да превазиђемо одређене потешкоће, али резултат је био заиста задовољан, па планирамо да проширимо ово искуство на неке друге ПгСКЛ инсталације. Ако имате искуства са коришћењем сличних решења, биће нам драго да видимо детаље у коментарима!

ПС

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

• «Базе података и Кубернетес (преглед и видео извештај)";
• «Постгрес уторак #5: ПостгреСКЛ и Кубернетес. ЦИ/ЦД. Аутоматизација тестирања";
• «Једна прича са Редис оператером у К8с и мини-преглед услужних програма за анализу података из ове базе података'.

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