Өткөн жылдын аягында орусиялык PostgreSQL коомчулугунун кезектеги түз эфири болуп өттү , анын жүрүшүндө анын тең негиздөөчүсү Николай Самохвалов Flantтын техникалык директору Дмитрий Столяров менен Kubernetes контекстинде бул DBMS жөнүндө сүйлөштү.
Биз бул талкуунун негизги бөлүгүнүн стенограммасын жарыялап жатабыз, жана at Толук видео жарыяланды:
Берилиштер базалары жана Kubernetes
НС: Биз бүгүн ВАКУМ жана ТЕКШЕРҮҮ ПУНКТтору жөнүндө сүйлөшпөйбүз. Биз Kubernetes жөнүндө сүйлөшкүбүз келет. Сиздин көп жылдык тажрыйбаңыз бар экенин билем. Мен сиздин видеоңузду көрдүм, ал тургай айрымдарын кайра көрдүм... Келгиле, түз сөзгө келели: эмне үчүн Postgres же MySQL дегеле K8s?
DS: Бул суроого так жооп жок жана болушу да мүмкүн эмес. Бирок жалпысынан бул жөнөкөйлүк жана ыңгайлуулук... потенциал. Ар бир адам башкарылган кызматтарды каалайт.
НС: Кантип , үйдө гана?
DS: Ооба: RDS сыяктуу, каалаган жерде.
НС: "Кандай болбосун" - бул жакшы нерсе. Чоң компанияларда баары ар кайсы жерде жайгашкан. Эмнеге анда ал чоң компания болсо, даяр чечимди кабыл албайт? Мисалы, Nutanixтин өзүнүн иштеп чыгуулары бар, башка компанияларда (VMware...) ошол эле "RDS, үйдө гана" бар.
DS: Бирок биз белгилүү бир шарттарда гана иштей турган өзүнчө ишке ашыруу жөнүндө сөз болуп жатат. Эгерде биз Kubernetes жөнүндө сөз кыла турган болсок, анда инфраструктуранын көп түрдүүлүгү бар (ал K8де болушу мүмкүн). Негизинен бул булуттагы API үчүн стандарт...
НС: Бул да бекер!
DS: Бул анчалык деле маанилүү эмес. Эркиндик рыноктун өтө чоң эмес сегменти үчүн маанилүү. Дагы бир нерсе маанилүү... Баяндама эсиңизде болсо керек ""?
НС: Ооба.
DS: Мен аны абдан түшүнүксүз кабыл алганын түшүндүм. Кээ бирөөлөр мени: “Балдар, келгиле, бардык маалымат базаларын Кубернетеске киргизели!” деп айтып жатам деп ойлошсо, башкалары мунун баары коркунучтуу велосипеддер деп чечишти. Бирок мен таптакыр башка нерсени айткым келди: “Карагылачы, эмне болуп жатат, кандай көйгөйлөр бар жана аларды кантип чечсе болот. Азыр биз Kubernetes маалымат базасын колдонушубуз керекпи? өндүрүш? Мейли, эгер сиз кааласаңыз... кээ бир нерселерди жасоо. Бирок иштеп чыгуучу үчүн мен аны сунуштайм деп айта алам. Иштеп чыгуучу үчүн чөйрөлөрдү түзүү/жок кылуу динамизми абдан маанилүү.
NS: Иштеп чыгуучу деп, сиз өндүрүлбөгөн бардык чөйрөлөрдү айтып жатасызбы? Сактоо, QA…
DS: Эгерде биз персоналдык стенддер жөнүндө сөз кыла турган болсок, анда, балким, андай эмес, анткени ал жерде талаптар конкреттүү. Эгерде биз сахналаштыруу үчүн өтө чоң маалымат базасы талап кылынган өзгөчө учурлар жөнүндө сөз кыла турган болсок, анда, балким, андай эмес... Эгер бул статикалык, узак мөөнөттүү чөйрө болсо, анда базанын K8s ичинде жайгашканынан кандай пайда бар?
НС: Жок. Бирок биз статикалык чөйрөлөрдү кайдан көрөбүз? Статикалык чөйрө эртең эскирип калат.
DS: Статистика статикалык болушу мүмкүн. Биздин кардарларыбыз бар...
НС: Ооба, менде да бар. Эгер сизде 10 ТБ маалымат базасы жана 200 ГБ стадировкасы болсо, бул чоң көйгөй...
DS: Менде абдан сонун иш бар! Сахналоодо өзгөртүүлөр киргизилген продукт маалымат базасы бар. Ал эми баскыч бар: "өндүрүшкө чыгуу". Бул өзгөртүүлөр - дельталар - өндүрүштө кошулат (алар жөн гана API аркылуу синхрондоштурууда окшойт). Бул абдан экзотикалык вариант.
НС: Мен өрөөндө RDS же атүгүл Херокуда отурган стартаптарды көрдүм - бул 2-3 жыл мурунку окуялар - алар таштандыны ноутбукка жүктөп алышат. Анткени база дагы 80 ГБ гана, ал эми ноутбукта бош орун бар. Андан кийин алар ар кандай иштеп чыгууларды жүргүзүү үчүн 3 маалымат базасы болушу үчүн, ар бир адам үчүн кошумча дисктерди сатып алышат. Бул да ушундай болот. Мен ошондой эле алар продюсерди сахнага көчүрүүдөн коркпой турганын көрдүм - бул компаниядан көз каранды. Бирок алардын абдан коркуп, көп учурда убактысы жана колу жетпей турганын да көрдүм. Бирок биз бул темага өтүүдөн мурун, мен Kubernetes жөнүндө уккум келет. Мен туура түшүнөмбү, азырынча эч ким өндүрүмсүз?
DS: Бизде чакан маалымат базалары бар. Кеп ондогон гигабайттык жана критикалык эмес кызматтар жөнүндө болуп жатат, алар үчүн биз репликаларды жасоого жалкоо болгонбуз (жана андай муктаждык жок). Жана Kubernetes астында кадимки сактагыч бар болсо. Бул маалымат базасы виртуалдык машинада иштеген - шарттуу түрдө VMwareде, сактоо тутумунун үстүндө. Биз киргиздик эми биз аны машинадан машинага которо алабыз.
НС: 100 ГБ чейинки бул өлчөмдөгү маалымат базаларын жакшы дисктерде жана жакшы тармакта бир нече мүнөттүн ичинде жайылтууга болот, туурабы? Секундасына 1 ГБ ылдамдык мындан ары экзотикалык эмес.
DS: Ооба, сызыктуу иштөө үчүн бул көйгөй эмес.
НС: Макул, биз продюсер жөнүндө ойлонушубуз керек. Эгерде биз Кубернеттерди өндүрүштүк эмес чөйрөлөр үчүн карап жаткан болсок, эмне кылышыбыз керек? Мен муну Заландодо көрүп жатам , Crunchy , кээ бир башка параметрлер бар. Жана бар - бул испаниялык биздин жакшы досубуз Альваро: алардын кылганы жөн эле эмес , жана бүт бөлүштүрүү (), ага Postgres өзүнөн тышкары, алар ошондой эле камдык көчүрмөнү, Элчи проксиди толтурууну чечишти ...
DS: Эмне үчүн элчи? Postgres трафиктин тең салмактуулугу өзгөчөбү?
НС: Ооба. Башкача айтканда, алар муну мындайча көрүшөт: эгерде сиз Linux дистрибьюторун жана ядросун алсаңыз, анда кадимки PostgreSQL өзөк болуп саналат жана алар булуттарга ыңгайлуу жана Kubernetesте иштей турган бөлүштүрүүнү каалашат. Алар компоненттерди (камдык көчүрмөлөрдү ж.б.) бириктирип, жакшы иштеши үчүн аларды оңдоо.
DS: Аябай сонун! Негизи бул өзүңүздүн башкарылган Postgres түзүүчү программалык камсыздоо.
НС: Linux дистрибьюторлорунун түбөлүк көйгөйлөрү бар: бардык жабдыктар колдоого алынышы үчүн драйверлерди кантип жасоо керек. Жана алар Кубернетесте иштейбиз деген ойго ээ. Мен Zalando операторунда биз жакында AWS менен байланышты көрдүк жана бул мындан ары жакшы эмес экенин билем. Белгилүү бир инфраструктура менен байланыш болбошу керек - анда эмне кереги бар?
DS: Заландо кандай кырдаалга туш болгонун так билбейм, бирок Kubernetes сактагычында азыр жалпы ыкманы колдонуп, дисктин камдык көчүрмөсүн алуу мүмкүн эмес кылып жасалган. Жакында стандартта - акыркы версияда — Биз снапшотторду мүмкүн кылдык, бирок ал кайда ишке ашырылууда? Чынын айтсам, баары мурдагыдай эле чийки... Биз AWS, GCE, Azure, vSphere үстүнө CSI сынап жатабыз, бирок аны колдоно баштаганыңызда, ал азырынча даяр эмес экенин көрө аласыз.
НС: Ошондуктан биз кээде инфраструктурага таянууга туура келет. Менимче, бул дагы эле алгачкы этап - өсүп жаткан оору. Суроо: PgSQLди K8де сынап көргүсү келген жаңыдан келгендерге кандай кеңеш берет элеңиз? Кайсы оператор болушу мүмкүн?
DS: Маселе Postgres биз үчүн 3% болуп саналат. Бизде ошондой эле Kubernetesте ар кандай программалык камсыздоолордун абдан чоң тизмеси бар, мен баарын тизмектеп койбойм. Мисалы, Elasticsearch. Операторлор көп: кээ бири активдүү өнүгүп жатат, башкалары жок. Биз өзүбүзгө талаптарды иштеп чыктык, ага олуттуу мамиле кылуу үчүн оператордо эмне болушу керек. Kubernetes үчүн атайын оператордо - "Амазондун шарттарында бир нерсе кылуу үчүн оператордо" эмес... Чынында, биз кеңири (= дээрлик бардык кардарлар) бир операторду колдонобуз - (жакында ал жөнүндө макала жарыялайбыз).
НС: Жана MySQL үчүн эмес? Мен Percona экенин билем... алар азыр MySQL, MongoDB жана Postgres үстүндө иштеп жаткандыктан, алар кандайдыр бир универсалдуу чечимди түзүшү керек: бардык маалымат базалары үчүн, бардык булут провайдерлери үчүн.
DS: MySQL үчүн операторлорду кароого убактыбыз болгон жок. Бул азыр биздин негизги багытыбыз эмес. MySQL өз алдынча жакшы иштейт. Эгер сиз жөн гана маалымат базасын ишке киргизе алсаңыз, эмне үчүн операторду колдонушуңуз керек... Сиз Postrges менен Docker контейнерин ишке киргизсеңиз болот же аны жөнөкөй жол менен ишке киргизсеңиз болот.
НС: Бул боюнча да суроо бар эле. Оператор жокбу?
DS: Ооба, биздин 100% PostgreSQL операторсуз иштейт. Азырынча ушундай. Биз Prometheus жана Redis үчүн операторду активдүү колдонобуз. Бизде Elasticsearch операторун табуу пландары бар - бул эң "өрт күйгөн" оператор, анткени биз аны 100% учурларда Кубернетеске орноткубуз келет. Биз MongoDB да дайыма Kubernetesте орнотулушун камсыз кылууну каалайбыз. Бул жерде белгилүү бир каалоолор пайда болот - бул учурларда бир нерсе жасоого болот деген сезим бар. Биз Постгрести да караган жокпуз. Албетте, биз ар кандай варианттар бар экенин билебиз, бирок чындыгында бизде өз алдынча бар.
Kubernetesте тестирлөө үчүн DB
НС: Тестирлөө темасына өтөбүз. Маалымат базасына өзгөртүүлөрдү кантип жайылтуу керек - DevOps көз карашынан. Микросервистер, көптөгөн маалымат базалары бар, бир жерде дайыма бир нерсе өзгөрүп турат. Кадимки CI/CDди кантип камсыз кылуу керек, ошондо бардыгы DBMS көз карашы боюнча тартипке келет. Сиздин мамилеңиз кандай?
DS: Бир жооп болушу мүмкүн эмес. Бир нече варианттар бар. Биринчиси, биз жайылгыбыз келген базанын өлчөмү. Сиз өзүңүз айтып өттүңүз, компаниялар иштеп чыгуучу жана сахнада продюсерлик базанын көчүрмөсүн алууга ар кандай мамиледе.
НС: Ал эми ГДПРдин шартында, менимче, алар уламдан-улам этият болуп жатышат... Европада алар азыр эле айып пул сала башташты деп айта алам.
DS: Бирок көп учурда сиз өндүрүштөн таштанды алып, аны бүдөмүк кылган программаны жаза аласыз. Продукт маалыматтары алынат (снапшот, дамп, экилик көчүрмө...), бирок анонимдүү. Анын ордуна, муун скрипттери болушу мүмкүн: бул арматуралар же жөн гана чоң маалымат базасын түзүүчү скрипт болушу мүмкүн. Маселе: негизги сүрөттү түзүү үчүн канча убакыт керек? Жана аны керектүү чөйрөдө жайгаштыруу үчүн канча убакыт талап кылынат?
Биз схемага келдик: эгерде кардарда белгиленген маалыматтар топтому бар болсо (базасынын минималдуу версиясы), анда биз аларды демейки боюнча колдонобуз. Эгерде биз карап чыгуу чөйрөлөрү жөнүндө сөз кыла турган болсок, анда биз филиалды түзүп жатканда, биз тиркеменин инстанциясын орноттук - биз ал жерде кичинекей маалымат базасын чыгарабыз. Бирок жакшы болуп чыкты , биз өндүрүштөн таштандыны күнүнө бир жолу (түндө) алып, анын негизинде PostgreSQL жана MySQL менен Docker контейнерин курганда, жүктөлгөн маалыматтар менен. Бул сүрөттөн маалымат базасын 50 эсе кеңейтүү керек болсо, бул абдан жөнөкөй жана тез жасалат.
НС: Жөнөкөй көчүрүү мененби?
DS: Маалыматтар түздөн-түз Docker сүрөтүндө сакталат. Ошол. Бизде 100 ГБ болсо да даяр сүрөт бар. Докердеги катмарлардын аркасында биз бул сүрөттү канча жолу керек болсо, ошончо ирет тез жайгаштыра алабыз. Метод акылсыз, бирок ал жакшы иштейт.
НС: Анан, сиз сынаганыңызда, ал Dockerдин ичинде өзгөрөт, туурабы? Dockerдин ичинде көчүрүү-жазуу - аны ыргытып, кайра барыңыз, баары жакшы. Класс! Ал эми сиз аны толугу менен колдонуп жатасызбы?
DS: Узак убакыт бою.
НС: Биз абдан окшош нерселерди жасайбыз. Болгону биз Докердин көчүрмөсүн эмес, башкасын колдонобуз.
DS: Бул жалпы эмес. Жана Docker бардык жерде иштейт.
НС: Теориялык жактан, ооба. Бирок бизде модулдар да бар, сиз ар кандай модулдарды жасап, ар кандай файл системалары менен иштей аласыз. Бул жерде кандай көз ирмем. Постгрес тараптан биз мунун баарына башкача карайбыз. Эми мен Докер тарабынан карадым жана баары сиз үчүн иштеп жатканын көрдүм. Бирок, эгерде маалымат базасы чоң болсо, мисалы, 1 ТБ, анда мунун баары көп убакытты талап кылат: түнкү операциялар жана бардыгын Dockerге толтуруу... Ал эми 5 ТБ Докерге толтурулса... Же баары жакшыбы?
DS: Эмнеси менен айырмасы бар: булар блоб, жөн гана бит жана байт.
НС: Айырмасы бул: сиз муну таштанды жана калыбына келтирүү аркылуу жасайсызбы?
DS: Такыр зарыл эмес. Бул сүрөттү түзүү ыкмалары ар кандай болушу мүмкүн.
НС: Кээ бир кардарлар үчүн, биз аны дайыма негизги сүрөттү түзүүнүн ордуна, аны дайыма жаңыртып туруу үчүн жасадык. Негизинен бул реплика, бирок ал маалыматтарды кожоюндан түздөн-түз эмес, архив аркылуу алат. WALлар күн сайын жүктөлүп алынган, резервдик көчүрмөлөр алынуучу бинардык архив... Бул WALлар бир аз кечигүү менен (сөзмө-сөз 1-2 секунд) негизги сүрөткө жетет. Биз андан каалаган жол менен клондоштуруу - азыр бизде демейки боюнча ZFS бар.
DS: Бирок ZFS менен сиз бир түйүн менен чектелесиз.
НС: Ооба. Бирок ZFS да сыйкырдуу касиетке ээ : анын жардамы менен сиз сүрөттү жөнөтө аласыз жана ал тургай (мен чындыгында муну сынай элекмин, бирок...) экөөнүн ортосунда дельтаны жөнөтө аласыз PGDATA. Чынында, бизде дагы бир курал бар, аны биз чындап эле мындай тапшырмалар үчүн карап чыга элекпиз. PostgreSQL бар , ал "акылдуу" rsync сыяктуу иштейт, ал жерде эч нерсе өзгөргөн жок, анткени сиз көрүүнүн кереги жок көп нерсени өткөрүп жиберет. Биз эки сервердин ортосунда тез синхрондоштурууну жасап, ошол эле жол менен артка түрө алабыз.
Ошентип, бул жагынан, көбүрөөк DBA жагынан, биз сиз айткандай эле жасоого мүмкүндүк берген куралды түзүүгө аракет кылып жатабыз: бизде бир маалымат базасы бар, бирок биз бир нерсени дээрлик бир убакта 50 жолу сынагыбыз келет.
DS: 50 жолу 50 Spot инстанциясына заказ беришиңиз керек дегенди билдирет.
НС: Жок, биз бардыгын бир станокто жасайбыз.
DS: Бирок бул бир маалымат базасы, айталы, терабайт болсо, кантип 50 эсе кеңейтесиз. Кыязы, ага шарттуу 256 ГБ оперативдик эс керекпи?
НС: Ооба, кээде сизге көп эс тутум керек - бул нормалдуу көрүнүш. Бирок бул турмуштан бир мисал. өндүрүш машина 96 өзөгү жана 600 ГБ бар. Ошол эле учурда маалымат базасы үчүн 32 өзөк (азыр кээде 16 ядро да) жана 100-120 ГБ эстутум колдонулат.
DS: Жана 50 нускасы ошол жерге туура келет?
НС: Ошентип, бир гана көчүрмөсү бар, анда көчүрүү-жазууга (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 ТБ кылып койдук. Жана алардын чындыгында жок экени да маанилүү эмес: ал бар сыяктуу пландарды түзөт.
Ошого жараша биз миграциянын кандайдыр бир түрүн сынап көргөндө бардык пландарды чогулта алабыз – өндүрүштө кандай болорун көрөбүз. Ал жерде секундалар башкача болот (жайыраак), бирок биз чындап окуган маалыматтар жана пландардын өзү (кандай JOIN бар, ж.б.) өндүрүштөгүдөй болуп чыгат. Жана сиз бир машинада параллелдүү көптөгөн текшерүүлөрдү жүргүзө аласыз.
DS: Бул жерде бир нече көйгөйлөр бар деп ойлобойсузбу? Биринчиси - PostgreSQLде гана иштеген чечим. Бул ыкма абдан купуя, ал жалпы эмес. Экинчиси, Kubernetes (жана булут технологиялары азыр бара жаткан бардык нерселер) көптөгөн түйүндөрдү камтыйт жана бул түйүндөр эфемердик. Ал эми сиздин учурда бул штаттык, туруктуу түйүн. Бул нерселер мени карама-каршы келет.
НС: Биринчиден, мен макулмун, бул таза Postgres окуясы. Менин оюмча, бизде кандайдыр бир түз IO жана дээрлик бардык эс тутум үчүн буфердик бассейн болсо, бул ыкма иштебейт - пландар башкача болот. Бирок азырынча биз Postgres менен гана иштейбиз, башкалар жөнүндө ойлобойбуз.
Kubernetes жөнүндө. Бизде туруктуу маалымат базасы бар экенин сиз өзүңүз айтып жатасыз. Эгерде инстанция иштебей калса, эң негизгиси дискти сактап калуу. Бул жерде бизде Kubernetesтеги бүт платформа бар жана Postgres менен компонент өзүнчө (бирок ал бир күнү ошол жерде болот). Демек, бардыгы мындай: инстанция кулады, бирок биз анын PV-сун сактап, эч нерсе болбогондой башка (жаңы) инстанцияга туташтырдык.
DS: Менин көз карашым боюнча, биз Kubernetes'те поддондорду түзөбүз. K8s - ийкемдүү: түйүндөр зарыл болгон учурда заказ кылынат. Тапшырма жөн гана поддон түзүү жана ага X сандагы ресурстар керек деп айтуу, андан кийин K8s аны өз алдынча чечет. Бирок Kubernetes'те сактагычты колдоо дагы эле туруксуз: боюнча (бул релиз чыкты недели мурун) бул функциялар бетага гана айланат.
Алты айдан бир жылга чейин өтөт - ал аздыр-көптүр туруктуу болуп калат, же жок дегенде ушундай деп жарыяланат. Андан кийин сүрөткө тартуу жана өлчөмүн өзгөртүү мүмкүнчүлүгү сиздин көйгөйүңүздү толугу менен чечет. Анткени сиздин базаңыз бар. Ооба, бул өтө тез эмес болушу мүмкүн, бирок ылдамдык "капоттун астындагы" нерседен көз каранды, анткени кээ бир ишке ашыруулар дисктин подсистемасынын деңгээлинде көчүрүп жана жазууга болот.
НС: Ошондой эле бардык кыймылдаткычтар үчүн (Amazon, Google...) бул версияны колдоого алуу зарыл - бул да бир аз убакытты талап кылат.
DS: Биз аларды азырынча колдоно элекпиз. Биз өзүбүздүн.
Kubernetes үчүн жергиликтүү өнүгүү
НС: Ушундай каалоого туш келдиңизби, сиз бир станокто баардык поддондорду орнотуп, ушундай кичинекей сыноону жасашыңыз керек. Концепциянын далилин тез алуу үчүн, колдонмо Kubernetes'те иштеп жатканын көрүңүз, ага бир топ машиналарды арнабастан. Minikube бар, туурабы?
DS: Менимче, бул иш - бир түйүндө жайгаштырылган - жалаң жергиликтүү өнүгүүгө байланыштуу. Же мындай үлгүнүн кээ бир көрүнүштөрү. же жок , . Биз Kubernetes IN Dockerди колдонууну көздөп жатабыз. Эми аны менен тесттер үчүн иштей баштадык.
НС: Мен бул бардык подкасттарды бир Докер сүрөтүнө таңуу аракети деп ойлочумун. Бирок бул таптакыр башка нерсе жөнүндө экени белгилүү болду. Кандай болбосун, өзүнчө контейнерлер, өзүнчө поддондор бар - жөн эле Докерде.
DS: Ооба. Жана абдан күлкүлүү имитация жасалган, бирок мааниси бул... Бизде жайылтуу үчүн утилита бар - . Биз аны шарттуу режимге айланткыбыз келет werf up: "Мага жергиликтүү Kubernetes алып кел." Анан ошол жерде шарттуу иштет werf follow. Андан кийин иштеп чыгуучу IDEди түзөтө алат жана системада өзгөрүүлөрдү көрүп, сүрөттөрдү кайра куруп, аларды жергиликтүү K8ге кайра жайгаштырган процесс башталат. Мына ушинтип жергиликтүү өнүгүү маселесин чечүүгө аракет кылгыбыз келет.
K8s реалдуулугунда сүрөттөр жана маалымат базасын клондоо
НС: Эгерде биз көчүрүү-жазууга кайтсак. Булуттардын да көз ирмемдик сүрөттөрү бар экенин байкадым. Алар башкача иштешет. Мисалы, GCPде: Америка Кошмо Штаттарынын чыгыш жээгинде көп терабайттык инстанцияңыз бар. Сиз мезгил-мезгили менен сүрөткө тартып турасыз. Сиз батыш жээгиндеги дисктин көчүрмөсүн сүрөткө тартып аласыз - бир нече мүнөттөн кийин баары даяр, ал абдан тез иштейт, эстутумда кэш гана толтурулушу керек. Бирок бул клондор (сүрөттөр) жаңы томду "камсыздоо" үчүн. Көптөгөн инстанцияларды түзүү керек болгондо, бул сонун.
Бирок тесттер үчүн мага Dockerде сиз айтып жаткан же мен ZFS, btrfs жана жада калса LVMде айтып жаткан көз ирмемдик сүрөттөр... - алар бир машинада чындап жаңы маалыматтарды түзбөөгө мүмкүндүк берет. Булутта сиз алар үчүн ар бир жолу төлөйсүз жана секунда эмес, мүнөт күтөсүз (жана учурда , мүмкүн саат).
Анын ордуна, сиз бул маалыматтарды бир же эки секундда ала аласыз, тестти өткөрүп, аны ыргытып жиберсеңиз болот. Бул сүрөттөр ар кандай маселелерди чечет. Биринчи учурда - масштабын кеңейтүү жана жаңы репликаларды алуу, ал эми экинчисинде - тесттер үчүн.
DS: Мен макул эмесмин. Көлөмдү клондоштурууну туура иштетүү булуттун милдети. Мен алардын ишке ашырылышын караган жокмун, бирок мен аны аппараттык камсыздоодо кантип жасаганыбызды билем. Бизде Ceph бар, ал каалаган физикалык көлөмгө мүмкүндүк берет () айт клон жана ондогон миллисекунддарда бирдей мүнөздөмөлөргө ээ экинчи томду алыңыз, 'ami, ж.б. Ичинде татаал көчүрмө бар экенин түшүнүшүңүз керек. Эмне үчүн булут да ошондой кылбашы керек? Алар муну тигил же бул жол менен жасоого аракет кылып жатышканына ишенем.
НС: Бирок мисалды көтөрүү, Докерди ал жакка алып келүү ж.б. үчүн алар дагы эле секунда, ондогон секунд талап кылынат.
DS: Эмне үчүн бүтүндөй бир инстанцияны көтөрүү керек? Бизде 32 өзөктүү инстанция бар, 16... жана ал ага бата алат - мисалы, төрт. Бешинчисине буйрутма бергенде, инстанция көтөрүлүп, анан өчүрүлөт.
НС: Ооба, кызыктуу, Kubernetes башка окуя болуп чыгат. Биздин маалымат базабыз K8де жок жана бизде бир инстанция бар. Бирок көп терабайттык базаны клондоо эки секунддан ашык эмес убакытты алат.
DS: Бул сонун. Бирок менин баштапкы оюм, бул жалпы чечим эмес. Ооба, бул сонун, бирок ал Postgres үчүн гана ылайыктуу жана бир түйүндө гана.
НС: Бул Postgres үчүн гана ылайыктуу эмес: бул пландар, мен сүрөттөгөндөй, анда гана иштейт. Бирок, эгерде биз пландар жөнүндө убара болбой турган болсок жана функционалдык тестирлөө үчүн бардык маалыматтар керек болсо, анда бул ар кандай DBMS үчүн ылайыктуу.
DS: Көп жылдар мурун биз LVM снапшотторунда окшош нерсени жасаганбыз. Бул классика. Бул ыкма абдан активдүү колдонулган. Мамлекеттик түйүндөр жөн гана оору. Анткени аларды таштабаш керек, дайыма эстеп жүрүш керек...
НС: Сиз бул жерде гибрид болушу мүмкүн экенин көрүп жатасызбы? Келгиле, абалды аныктоо - бул кандайдыр бир подкаст, ал бир нече адамдар үчүн иштейт (көптөгөн тестерлер). Бизде бир том бар, бирок файл тутумунун аркасында клондор жергиликтүү. Эгерде подвод кулап, бирок диск кала берсе, подкаст көтөрүлөт, бардык клондор жөнүндө маалыматты санап, баарын кайра алып: "Мына, бул порттордо сиздин клондоруңуз иштеп жатат, алар менен иштөөнү уланта бериңиз".
DS: Техникалык жактан алганда, бул Kubernetes ичинде биз көптөгөн Postgres иштеткен бир поддон экенин билдирет.
НС: Ооба. Анын чеги бар: аны менен бир убакта 10дон ашык адам иштебейт дейли. Эгер сизге 20 керек болсо, биз экинчи ушундай подводду ишке киргизебиз. Биз аны толугу менен клондойбуз, экинчи толук томду алгандан кийин, ошол эле 10 "жука" клонго ээ болот. Сиз бул мүмкүнчүлүктү көрбөй жатасызбы?
DS: Биз бул жерге коопсуздук маселелерин кошушубуз керек. Уюмдун бул түрү бул поддондун жогорку артыкчылыктарга (мүмкүнчүлүктөргө) ээ экенин билдирет, анткени ал файл тутумунда стандарттуу эмес операцияларды аткара алат... Бирок мен дагы бир жолу кайталайм: орто мөөнөттүү келечекте алар Kubernetes'те сактоону оңдойт деп ишенем, жана булуттар, алар бүт окуяны томдор менен оңдошот - баары "жөн эле иштейт". Өлчөмүн өзгөртүү, клондоштуруу болот... Көлөм бар – биз: “Ошонун негизинде жаңысын түзүңүз” деп айтабыз, бир жарым секунддан кийин керектүү нерсени алабыз.
НС: Мен көп терабайт үчүн бир жарым секунд ишенбейм. Кефте сен муну өзүң кыласың, бирок булуттар жөнүндө айтасың. Булутка барыңыз, EC2де көп терабайттык EBS көлөмүнүн клонун жасаңыз жана аткаруу кандай болорун көрүңүз. Бул бир нече секунд талап кылынбайт. Алар качан ушул деңгээлге жетет деген суроо мени абдан кызыктырат. Мен эмне деп жатканыңызды түшүнөм, бирок мен башка пикирди айткым келет.
DS: Макул, бирок мен кыска мөөнөттүү эмес, орто мөөнөттүү дедим. Бир нече жылдан бери.
Zalando тартып PostgreSQL үчүн оператор жөнүндө
Бул жолугушуунун ортосунда Заландодон келген мурдагы иштеп чыгуучу Алексей Клюкин да кошулуп, PostgreSQL операторунун тарыхы жөнүндө айтып берди:
Бул тема жалпысынан козголуп жатканы абдан жакшы: Postgres жана Kubernetes. Биз муну 2017-жылы Заландодо жасай баштаганда, бул ар бир адам жасагысы келген тема болчу, бирок эч ким кылган эмес. Ар бир адам мурунтан эле Kubernetes болгон, бирок алар маалымат базалары менен эмне кылуу керек деп сурашканда, атүгүл адамдарга жагат , K8s кабар айткан, мындай деди:
"Башкарылган кызматтарга өтүп, аларды колдонуңуз, Кубернетестеги маалымат базасын иштетпеңиз. Болбосо, сиздин K8s, мисалы, жаңыртууну чечет, бардык түйүндөрдү өчүрүп, маалыматтарыңыз алыска учуп кетет.
Биз бул кеңешке каршы, Kubernetesте Postgres маалымат базасын ишке киргизе турган оператор жасоону чечтик. Бизде жакшы себеп бар болчу - . Бул PostgreSQL үчүн автоматтык түрдө иштен чыгуу, туура жасалган, б.а. etcd, consul же ZooKeeperди кластер жөнүндө маалыматты сактоочу катары колдонуу. Мындай репозиторий, мисалы, азыркы лидер ким деп сурагандардын баарына бирдей маалымат берет - бизде бардыгы бөлүштүрүлгөнүнө карабастан - мээнин бөлүнүүсү болбошу үчүн. Плюс бизде болгон ал үчүн.
Жалпысынан алганда, компаниянын автоматтык түрдө иштен чыгууга болгон муктаждыгы ички аппараттык маалымат борборунан булутка көчкөндөн кийин пайда болгон. Булут патенттик PaaS (Platform-as-a-Service) чечиминин негизинде түзүлгөн. Бул Open Source, бирок аны ишке киргизүү үчүн көп эмгек талап кылынган. деп аталды .
Башында Кубернетес болгон эмес. Тагыраак айтканда, биздин өзүбүздүн чечимибиз орнотулганда, K8s мурунтан эле бар болчу, бирок ал ушунчалык чийки болгондуктан, өндүрүшкө жараксыз болчу. Менимче, 2015 же 2016-жыл. 2017-жылга карата Кубернетес аздыр-көптүр жетилген — ал жакка көчүү зарылчылыгы бар болчу.
Бизде Docker контейнери бар болчу. Dockerди колдонгон PaaS бар болчу. Эмне үчүн K8s аракет кылбайт? Эмне үчүн өз операторуңузду жазбайсыз? Бизге Авитодон келген Мурат Кабилов муну өз демилгеси менен «ойноо» долбоору катары баштап, долбоор «баштап кетти».
Бирок, жалпысынан, мен AWS жөнүндө айткым келди. Эмне үчүн тарыхый AWS менен байланышкан код бар эле ...
Kubernetes'те бир нерсени иштеткенде, K8s мындай иш жүрүп жатканын түшүнүшүңүз керек. Ал тынымсыз өнүгүп, өркүндөп, алтургай мезгил-мезгили менен бузулуп турат. Сиз Кубернетестеги бардык өзгөрүүлөргө кылдат көз салышыңыз керек, эгер бир нерсе болуп кетсе, ага сүңгүп кирип, анын кантип иштээрин майда-чүйдөсүнө чейин билүүгө даяр болушуңуз керек - балким, сиз каалагандан да көп. Бул, негизинен, сиз маалымат базаларыңызды иштеткен бардык платформаларга тиешелүү...
Ошентип, биз билдирүү жасаганда, бизде Postgres тышкы томдо иштеген (бул учурда EBS, анткени биз AWSде иштеп жатканбыз). Маалыматтар базасы чоңойду, кандайдыр бир учурда анын өлчөмүн өзгөртүү керек болду: мисалы, EBSтин баштапкы өлчөмү 100 ТБ болчу, маалымат базасы ага чейин өстү, азыр биз EBS 200 ТБ кылгыбыз келет. Кантип? Келгиле, сиз жаңы инстанцияда таштанды/калыбына келтире аласыз дейли, бирок бул көп убакытты талап кылат жана иштебей турган убакытты талап кылат.
Ошондуктан, мен EBS бөлүмүн чоңойтуп, анан файл тутумуна жаңы мейкиндикти колдонууну айта турган өлчөмүн өзгөртүүнү кааладым. Жана биз муну жасадык, бирок ал убакта Кубернетте өлчөмүн өзгөртүү операциясы үчүн API болгон эмес. Биз AWSде иштегендиктен, анын API кодун жаздык.
Башка платформалар үчүн да ушундай кылууңузга эч ким тоскоолдук кылбайт. Билдирүүдө аны AWSде гана иштетүүгө болот деген эч кандай ишарат жок жана ал башкалардын бардыгында иштебейт. Жалпысынан алганда, бул Open Source долбоору: кимдир бирөө жаңы API колдонуунун пайда болушун тездетүүнү кааласа, сизди кош келиңиз. же , суроо-талаптарды тартуу - Zalando командасы аларга тез арада жооп берүүгө жана операторду илгерилетүүгө аракет кылат. Менин билишимче, долбоор Google Summer of Code жана башка ушул сыяктуу демилгелерде. Заландо анын үстүндө абдан активдүү иштеп жатат.
PS бонусу!
Эгерде сизди PostgreSQL жана Kubernetes темасы кызыктырса, анда кийинки Postgres шейшемби өткөн аптада өткөнүн эске алыңыз, анда мен Николай менен сүйлөштүм. Заландодон Александр Кукушкин. Анын видеосу жеткиликтүү .
PPS
Биздин блогдон дагы окуңуз:
- «";
- «";
- «";
- ««.
Source: www.habr.com