Өткен жылдың соңында ресейлік PostgreSQL қауымдастығының кезекті тікелей трансляциясы өтті , оның барысында оның негізін қалаушы Николай Самохвалов Flant техникалық директоры Дмитрий Столяровпен Kubernetes контекстіндегі осы ДҚБЖ туралы сөйлесті.
Біз осы талқылаудың негізгі бөлігінің стенограммасын жариялап отырмыз, және at Толық бейне жарияланды:
Мәліметтер базасы және Кубернет
Н.С: Біз бүгін ВАКУУМ және БЕКЕРУ нүктелері туралы айтпаймыз. Біз Кубернетес туралы айтқымыз келеді. Мен сіздің көп жылдық тәжірибеңіз бар екенін білемін. Мен сіздің бейнелеріңізді көрдім, тіпті кейбіреулерін қайта қарадым... Сөзге тікелей көшейік: неге Postgres немесе MySQL K8-де?
DS: Бұл сұраққа нақты жауап жоқ және болуы да мүмкін емес. Бірақ жалпы алғанда, бұл қарапайымдылық пен ыңғайлылық ... әлеует. Барлығы басқарылатын қызметтерді қалайды.
Н.С: Қалайша , тек үйде ме?
DS: Иә: RDS сияқты, кез келген жерде.
Н.С: «Кез келген жерде» - жақсы нүкте. Ірі компанияларда бәрі әртүрлі жерлерде орналасқан. Неліктен ол ірі компания болса, дайын шешім қабылдамайды? Мысалы, Nutanix-тің өз әзірлемелері бар, басқа компанияларда (VMware...) бірдей «RDS, тек үйде» бар.
DS: Бірақ біз белгілі бір жағдайларда ғана жұмыс істейтін бөлек іске асыру туралы айтып отырмыз. Егер біз Kubernetes туралы айтатын болсақ, онда инфрақұрылымның алуан түрлілігі бар (ол K8-де болуы мүмкін). Негізінде бұл бұлтқа арналған API стандарты...
Н.С: Бұл да тегін!
DS: Бұл соншалықты маңызды емес. Нарықтың өте үлкен емес сегменті үшін еркіндік маңызды. Тағы бір нәрсе маңызды... Баяндама есіңізде шығар«?»
Н.С: Иә.
DS: Мен оны өте екіұшты қабылдағанын түсіндім. Кейбіреулер мені: «Жігіттер, барлық дерекқорларды Кубернетеске енгізейік!» деп айтып жатырмын деп ойлады, ал басқалары мұның бәрі қорқынышты велосипедтер деп шешті. Бірақ мен мүлде басқа нәрсе айтқым келді: «Қараңдаршы, не болып жатыр, қандай мәселелер бар және оларды қалай шешуге болады. Біз қазір Kubernetes дерекқорларын пайдалануымыз керек пе? Өндіріс? Жақсы, егер сізге ұнайтын болса ғана ... белгілі бір нәрселермен айналысу. Бірақ әзірлеуші үшін мен оны ұсынамын деп айта аламын. Әзірлеуші үшін орталарды жасау/жою динамизмі өте маңызды».
Н.С.: Әзірлеуші деп сіз өндірілмеген барлық орталарды айтасыз ба? Сахналау, QA…
DS: Егер біз тамаша стендтер туралы айтатын болсақ, онда олай емес шығар, өйткені талаптар нақты. Егер біз сахналау үшін өте үлкен деректер базасы қажет болатын ерекше жағдайлар туралы айтатын болсақ, онда олай емес шығар... Егер бұл статикалық, ұзақ өмір сүретін орта болса, онда деректер базасының K8s-де орналасуының қандай пайдасы бар?
Н.С: Жоқ. Бірақ біз статикалық орталарды қайдан көреміз? Статикалық орта ертең ескіреді.
DS: Кезең статикалық болуы мүмкін. Біздің клиенттеріміз бар...
Н.С: Иә, менде де бар. Егер сізде 10 ТБ деректер базасы және 200 ГБ сахналау болса, бұл үлкен мәселе...
DS: Менде өте жақсы іс бар! Кезеңде өзгертулер енгізілген өнім дерекқоры бар. «Өндіріске шығару» түймесі бар. Бұл өзгерістер - дельталар - өндірісте қосылады (олар API арқылы жай синхрондалған сияқты). Бұл өте экзотикалық нұсқа.
Н.С: Мен алқапта RDS немесе тіпті Херокуда отырған стартаптарды көрдім - бұл 2-3 жыл бұрынғы оқиғалар - және олар қоқыстарды ноутбукке жүктеп алады. Өйткені дерекқор әлі де тек 80 ГБ, ал ноутбукта бос орын бар. Содан кейін олар әр түрлі әзірлемелерді жүзеге асыру үшін 3 дерекқорға ие болу үшін барлығына қосымша дискілерді сатып алады. Бұл да солай болады. Мен сондай-ақ олардың өнімді көшіруден қорықпайтынын көрдім - бұл компанияға байланысты. Бірақ мен олардың қатты қорқатынын, көбінесе уақыттары мен қолдары жетпейтінін көрдім. Бірақ бұл тақырыпқа көшпес бұрын мен Кубернетес туралы естігім келеді. Мен әлі ешкімнің өндірісте емес екенін дұрыс түсінемін бе?
DS: Бізде өндірісте шағын дерекқорлар бар. Біз көшірме жасауға тым жалқау болған ондаған гигабайттық және маңызды емес қызметтер туралы айтып отырмыз (және мұндай қажеттілік жоқ). Кубернетес астында қалыпты сақтау орны болған жағдайда. Бұл дерекқор виртуалды машинада жұмыс істеді - шартты түрде VMware-де, сақтау жүйесінің жоғарғы жағында. Біз оны орналастырдық енді біз оны машинадан машинаға ауыстыра аламыз.
Н.С: Мұндай көлемдегі, 100 ГБ дейінгі дерекқорларды жақсы дискілерде және жақсы желіде бірнеше минут ішінде шығаруға болады, солай ма? Секундына 1 ГБ жылдамдық енді экзотикалық емес.
DS: Иә, сызықтық жұмыс үшін бұл мәселе емес.
Н.С: Жарайды, біз тек өнім туралы ойлауымыз керек. Егер біз Kubernetes-ті өндірістік емес орталар үшін қарастыратын болсақ, не істеуіміз керек? Мен мұны Заландодан көремін , Crunchy тілінде , басқа да опциялар бар. Және бар - бұл Испаниядан келген жақсы досымыз Альваро: олардың істеп жатқандары жай ғана емес , және бүкіл бөлу (), оған Postgres-тен басқа, олар сондай-ақ резервтік көшірме жасауды шешті, Envoy прокси...
DS: Не үшін елші? Postgres трафигін теңдестіру керек пе?
Н.С: Иә. Яғни, олар оны былай көреді: егер сіз Linux дистрибутивін және ядросын алсаңыз, онда кәдімгі PostgreSQL ядро болып табылады және олар бұлтқа ыңғайлы және Kubernetes-те жұмыс істейтін дистрибуция жасағысы келеді. Олар құрамдастарды (сақтық көшірмелерді және т.б.) біріктіреді және жақсы жұмыс істеуі үшін оларды түзетеді.
DS: Өте керемет! Негізінде бұл өзіңіздің басқарылатын Postgres-ті жасауға арналған бағдарламалық құрал.
Н.С: Linux дистрибутивтерінде мәңгілік мәселелер бар: барлық аппараттық құралдарға қолдау көрсетілетіндей драйверлерді қалай жасауға болады. Және олар Кубернетесте жұмыс істейміз деген ойға ие. Мен Zalando операторында біз жақында AWS қосылымын көргенімізді білемін және бұл енді жақсы емес. Белгілі бір инфрақұрылыммен байланыс болмауы керек - сонда не керек?
DS: Мен Заландоның қандай жағдайға тап болғанын білмеймін, бірақ Kubernetes қоймасында қазір жалпы әдісті пайдаланып дискінің сақтық көшірмесін алу мүмкін болмайтын етіп жасалған. Жақында стандартты - соңғы нұсқада — біз суретке түсіруге мүмкіндік жасадық, бірақ ол қайда жүзеге асырылады? Шынымды айтсам, бәрі әлі де шикі... Біз AWS, GCE, Azure, vSphere үстіне CSI-ны қолданып жатырмыз, бірақ оны пайдалана бастағанда оның әлі дайын емес екенін байқауға болады.
Н.С: Сондықтан кейде инфрақұрылымға сенуге тура келеді. Менің ойымша, бұл әлі ерте кезең - өсіп келе жатқан ауырсыну. Сұрақ: K8-де PgSQL-ді қолданғысы келетін жаңадан келгендерге қандай кеңес берер едіңіз? Қандай оператор болуы мүмкін?
DS: Мәселе мынада, Postgres біз үшін 3%. Сондай-ақ бізде Kubernetes-те әртүрлі бағдарламалық жасақтаманың өте үлкен тізімі бар, мен тіпті бәрін тізімдемеймін. Мысалы, Elasticsearch. Операторлар өте көп: кейбіреулері белсенді дамып келеді, басқалары жоқ. Біз өзімізге талаптар қойдық, операторда не болуы керек, біз оны байыппен қабылдаймыз. Арнайы Kubernetes үшін операторда - «Amazon шарттарында бірдеңе жасайтын операторда» емес... Шындығында, біз кең таралған (= барлық дерлік клиенттер) бір операторды қолданамыз - (жақында ол туралы мақала жариялаймыз).
Н.С: MySQL үшін де емес пе? Мен Percona екенін білемін... олар қазір MySQL, MongoDB және Postgres жүйелерінде жұмыс істеп жатқандықтан, олар әмбебап шешімнің қандай да бір түрін жасауы керек: барлық дерекқорлар үшін, барлық бұлттық провайдерлер үшін.
DS: MySQL үшін операторларды қарауға уақытымыз болмады. Бұл қазір біздің басты назарымызда емес. MySQL дербес күйде жақсы жұмыс істейді. Егер сіз жай ғана дерекқорды іске қоса алсаңыз, операторды не үшін пайдалану керек... Сіз Postrges көмегімен Docker контейнерін іске қоса аласыз немесе оны қарапайым жолмен іске қоса аласыз.
Н.С: Бұл туралы да сұрақ болды. Оператор мүлдем жоқ па?
DS: Иә, біздің 100% PostgreSQL операторсыз жұмыс істейді. Әзірге солай. Біз Prometheus және Redis үшін операторды белсенді түрде қолданамыз. Бізде Elasticsearch операторын табу жоспарлары бар - бұл ең «өрт» болып табылады, өйткені біз оны 100% жағдайда Кубернетеске орнатқымыз келеді. Біз MongoDB әрқашан Kubernetes-те орнатылғанын қамтамасыз еткіміз келеді. Мұнда белгілі бір тілектер пайда болады - бұл жағдайларда бірдеңе жасауға болады деген сезім бар. Біз Постгреске де қарамадық. Әрине, біз әртүрлі нұсқалардың бар екенін білеміз, бірақ іс жүзінде бізде автономды бар.
Kubernetes-те тестілеуге арналған ДБ
Н.С: Тестілеу тақырыбына көшейік. Дерекқорға өзгертулерді қалай шығаруға болады - DevOps тұрғысынан. Микросервистер, көптеген дерекқорлар бар, бір жерде бір нәрсе үнемі өзгеріп отырады. ДҚБЖ тұрғысынан бәрі реттелген болуы үшін қалыпты CI/CD қалай қамтамасыз етуге болады. Сіздің көзқарасыңыз қандай?
DS: Бір жауап болуы мүмкін емес. Бірнеше нұсқа бар. Біріншісі - біз шығарғымыз келетін негіздің өлшемі. Сіз өзіңіз айтып өттіңіз, компаниялардың әзірлеуші және сахнадағы өнім дерекқорының көшірмесін алуға әртүрлі көзқарастары бар.
Н.С: Ал GDPR шарттарында олар барған сайын сақтық танытып жатыр деп ойлаймын... Еуропада олар айыппұл сала бастады деп айта аламын.
DS: Бірақ көбінесе өндірістен қоқысты алып, оны жасыратын бағдарламалық жасақтаманы жаза аласыз. Өндіріс деректері алынады (сурет, демп, екілік көшірме...), бірақ ол анонимді. Оның орнына, генерациялау сценарийлері болуы мүмкін: бұл құрылғылар немесе үлкен дерекқорды жасайтын сценарий болуы мүмкін. Мәселе мынада: негізгі кескінді жасауға қанша уақыт кетеді? Және оны қажетті ортаға орналастыру үшін қанша уақыт қажет?
Біз схемаға келдік: егер клиентте тіркелген деректер жиынтығы болса (деректер базасының минималды нұсқасы), онда біз оларды әдепкі бойынша қолданамыз. Егер біз шолу орталары туралы айтатын болсақ, филиалды жасаған кезде біз қолданбаның данасын орналастырдық - біз сол жерде шағын дерекқорды шығарамыз. Бірақ жақсы шықты , біз күніне бір рет (түнде) өндірістен қоқысты алып, оның негізінде осы жүктелген деректермен PostgreSQL және MySQL бар Docker контейнерін жасағанда. Бұл суреттен дерекқорды 50 есе кеңейту қажет болса, бұл өте қарапайым және жылдам орындалады.
Н.С: Қарапайым көшіру арқылы ма?
DS: Деректер тікелей Docker кескінінде сақталады. Анау. Бізде 100 ГБ болса да дайын сурет бар. Docker қабаттарының арқасында біз бұл кескінді қажетінше бірнеше рет жылдам орналастыра аламыз. Әдіс ақымақ, бірақ ол жақсы жұмыс істейді.
Н.С: Содан кейін тестілеу кезінде ол Docker ішінде өзгереді, солай ма? Docker ішіндегі жазуға көшіру - оны лақтырып, қайта барыңыз, бәрі жақсы. Сынып! Ал сіз оны толығымен пайдаланып жатырсыз ба?
DS: Узақ уақытқа.
Н.С: Біз өте ұқсас нәрселер жасаймыз. Тек біз Docker's copy-on-write қолданбасын, бірақ басқасын қолданамыз.
DS: Бұл жалпы емес. Ал Docker барлық жерде жұмыс істейді.
Н.С: Теориялық тұрғыдан, иә. Бірақ бізде модульдер де бар, сіз әртүрлі модульдер жасай аласыз және әртүрлі файлдық жүйелермен жұмыс жасай аласыз. Бұл жерде қандай сәт. Postgres жағынан біз мұның бәріне басқаша қараймыз. Енді мен Docker жағынан қарап, бәрі сіз үшін жұмыс істейтінін көрдім. Бірақ егер деректер базасы үлкен болса, мысалы, 1 ТБ болса, онда мұның бәрі көп уақытты алады: түнгі операциялар және бәрін Docker-ге толтыру ... Ал егер 5 ТБ Docker-ге толтырылса... Әлде бәрі жақсы ма?
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 сол сияқты, біз шынымен Постгресті алдап жатырмыз. Бұл қулық: мысалы, 10 Postgres бір уақытта іске қосылады. Мәселе әдетте қандай? Олар қойды , 25% дейік. Тиісінше, бұл 200 ГБ. Олардың үшеуінен артық іске қоса алмайсыз, себебі жад таусылады.
Бірақ бір сәтте біз бұл қажет емес екенін түсіндік: ортақ_буферлерді 2 ГБ етіп орнаттық. PostgreSQL бар , ал шын мәнінде әсер ететін жалғыз нәрсе . Біз оны 0,5 ТБ етіп орнаттық. Олардың шын мәнінде жоқ екендігі де маңызды емес: ол бар сияқты жоспарлар жасайды.
Тиісінше, көші-қонның қандай да бір түрін сынақтан өткізген кезде біз барлық жоспарларды жинай аламыз – оның өндірісте қалай болатынын көреміз. Секундтар әр түрлі болады (баяу), бірақ біз шынымен оқитын деректер және жоспарлардың өзі (қандай JOIN бар және т.б.) өндірістегідей болады. Және бір станокта көптеген осындай тексерулерді қатар жүргізе аласыз.
DS: Бұл жерде бірнеше мәселе бар деп ойламайсыз ба? Біріншісі - тек PostgreSQL-де жұмыс істейтін шешім. Бұл тәсіл өте жеке, ол жалпы емес. Екіншіден, Кубернетес (және бұлтты технологиялардың барлығы) көптеген түйіндерді қамтиды және бұл түйіндер эфемерлі. Ал сіздің жағдайда бұл күйді, тұрақты түйін. Бұл нәрселер мені жанжалдырады.
Н.С: Біріншіден, мен келісемін, бұл таза Postgres оқиғасы. Менің ойымша, егер бізде тікелей IO және барлық дерлік жад үшін буферлік пул болса, бұл тәсіл жұмыс істемейді - жоспарлар басқаша болады. Бірақ әзірге біз тек Postgres-пен жұмыс істейміз, басқалар туралы ойламаймыз.
Кубернетес туралы. Бізде тұрақты деректер базасы бар екенін сіз өзіңіз барлық жерде айтасыз. Егер данасы сәтсіз болса, ең бастысы - дискіні сақтау. Мұнда бізде Kubernetes-те бүкіл платформа бар және Postgres-пен құрамдас бөлек (бірақ ол бір күні сонда болады). Сондықтан, бәрі былай: данасы құлады, бірақ біз оның PV-ын сақтап қалдық және оны ештеңе болмағандай басқа (жаңа) данаға қостық.
DS: Менің көзқарасым бойынша, біз Kubernetes-те подкаст жасаймыз. K8s - серпімді: түйіндер қажет болған жағдайда тапсырыс беріледі. Тапсырма жай ғана подкаст жасау және оған X көлемдегі ресурстар қажет екенін айту, содан кейін K8 оны өздігінен анықтайды. Бірақ Kubernetes-те сақтауды қолдау әлі де тұрақсыз: , in (бұл шығарылым шығарылды апта бұрын) бұл мүмкіндіктер тек бета нұсқасына айналады.
Алты айдан бір жылға дейін өтеді - ол азды-көпті тұрақты болады немесе кем дегенде ол осылай жарияланады. Содан кейін суретке түсіру және өлшемін өзгерту мүмкіндігі мәселеңізді толығымен шешеді. Өйткені сізде негіз бар. Иә, бұл өте жылдам болмауы мүмкін, бірақ жылдамдық «қақпақтың астындағы» нәрсеге байланысты, себебі кейбір іске асырулар дискілік ішкі жүйе деңгейінде көшіріп, жазуға болады.
Н.С: Сондай-ақ барлық қозғалтқыштарға (Amazon, Google...) осы нұсқаны қолдауды бастау қажет - бұл да біраз уақытты алады.
DS: Біз оларды әлі қолданбаймыз. Біз өзімізді қолданамыз.
Кубернетес үшін жергілікті даму
Н.С: Бір станокқа барлық подшипниктерді орнатып, осындай шағын сынақтан өткізу қажет болғанда, осындай тілек кездестірдіңіз бе? Тұжырымдаманың дәлелін жылдам алу үшін қосымшаның көптеген машиналарды арнамай-ақ, Kubernetes-те жұмыс істейтінін қараңыз. Minikube бар, солай ма?
DS: Менің ойымша, бұл іс - бір түйінге орналастырылған - тек жергілікті дамуға қатысты. Немесе мұндай үлгінің кейбір көріністері. Тамақ , бар , . Біз Kubernetes IN Docker қолданбасын пайдалануға көшеміз. Енді біз онымен сынақтар үшін жұмыс істей бастадық.
Н.С: Мен бұл барлық подкасттарды бір Docker кескініне орау әрекеті деп ойлайтынмын. Бірақ бұл мүлдем басқа нәрсе туралы екені белгілі болды. Қалай болғанда да, бөлек контейнерлер, бөлек бағандар бар - тек Docker-де.
DS: Иә. Бұл жерде өте күлкілі еліктеу жасалған, бірақ мағынасы мынада... Бізде орналастыруға арналған утилита бар - . Біз оны шартты режимге айналдырғымыз келеді werf up: «Маған жергілікті Кубернеттерді алыңыз.» Содан кейін шартты орындаңыз werf follow. Содан кейін әзірлеуші IDE өңдей алады және өзгерістерді көретін және кескіндерді жергілікті K8-ге қайта орналастыратын жүйеде процесс іске қосылады. Жергілікті даму мәселесін осылайша шешуге тырысамыз.
K8s шындықтағы суреттер мен дерекқорды клондау
Н.С: Егер көшіру-жазуға қайта оралсақ. Бұлттардың да суреттері бар екенін байқадым. Олар басқаша жұмыс істейді. Мысалы, GCP-де: Америка Құрама Штаттарының шығыс жағалауында көп терабайт данасы бар. Сіз мезгіл-мезгіл суретке түсіресіз. Сіз батыс жағалаудағы дискінің көшірмесін суреттен аласыз - бірнеше минуттан кейін бәрі дайын, ол өте жылдам жұмыс істейді, тек кэшті жадқа толтыру керек. Бірақ бұл клондар (суреттер) жаңа томды «қамтамасыз ету» үшін. Бұл көптеген даналарды жасау қажет болғанда тамаша.
Бірақ сынақтар үшін сіз Docker-те айтатын немесе мен ZFS, btrfs және тіпті LVM-де айтатын суреттер... - олар бір машинада шынымен жаңа деректерді жасамауға мүмкіндік береді деп ойлаймын. Бұлтта сіз олар үшін әрқашан төлейсіз және секундтар емес, минуттар күтесіз (және жағдайда , сағат болуы мүмкін).
Оның орнына, сіз бұл деректерді бір-екі секундта ала аласыз, сынақты орындап, оны тастаңыз. Бұл суреттер әртүрлі мәселелерді шешеді. Бірінші жағдайда - масштабтау және жаңа көшірмелерді алу үшін, ал екіншісінде - сынақтар үшін.
DS: Мен келіспеймін. Көлемді клондаудың дұрыс жұмыс істеуін қамтамасыз ету - бұлттың міндеті. Мен олардың орындалуын қарастырған жоқпын, бірақ мен оны аппараттық құралда қалай жасайтынымызды білемін. Бізде Ceph бар, ол кез келген физикалық көлемге мүмкіндік береді () айту Clone және ондаған миллисекундтарда бірдей сипаттамалары бар екінші томды алыңыз, 'ами және т.б. Ішінде күрделі көшірме бар екенін түсіну керек. Неліктен бұлт осылай жасамауы керек? Олар мұны бір жолмен жасауға тырысатынына сенімдімін.
Н.С: Бірақ дананы көтеру, Docker-ді сол жерге әкелу және т.б. үшін оларға секундтар, ондаған секундтар қажет болады.
DS: Неліктен тұтас дананы көтеру керек? Бізде 32 ядросы бар данасы бар, 16... және ол оған сыя алады - мысалы, төрт. Бесіншіге тапсырыс бергенде, данасы көтеріледі, содан кейін ол жойылады.
Н.С: Иә, қызық, Кубернетес басқа әңгіме болып шығады. Біздің дерекқорымыз K8-де жоқ және бізде бір данасы бар. Бірақ көп терабайттық дерекқорды клондау екі секундтан аспайды.
DS: Бұл тамаша. Бірақ менің бастапқы ойым - бұл жалпы шешім емес. Иә, бұл керемет, бірақ ол тек Postgres үшін және тек бір түйінде жарамды.
Н.С: Бұл тек Postgres үшін ғана емес: бұл жоспарлар, мен сипаттағандай, тек онда жұмыс істейді. Бірақ егер біз жоспарлар туралы алаңдамасақ және функционалды тестілеу үшін барлық деректер қажет болса, онда бұл кез келген ДҚБЖ үшін қолайлы.
DS: Көптеген жылдар бұрын біз LVM суреттерінде ұқсас нәрсені жасадық. Бұл классика. Бұл әдіс өте белсенді қолданылды. Күйлік түйіндер - бұл жай ғана ауырсыну. Өйткені сіз оларды түсірмеуіңіз керек, оларды әрқашан есте сақтауыңыз керек ...
Н.С: Бұл жерде гибрид болуы мүмкін бе? Айталық, күй - бұл подкасттың бір түрі, ол бірнеше адам үшін жұмыс істейді (көп тестерлер). Бізде бір том бар, бірақ файлдық жүйенің арқасында клондар жергілікті. Егер подвод құлап кетсе, бірақ диск қалса, подвод көтеріледі, барлық клондар туралы ақпаратты санап, барлығын қайтадан алып: «Міне, осы порттарда сіздің клондарыңыз жұмыс істейді, олармен жұмыс істеуді жалғастырыңыз» деп айтыңыз.
DS: Техникалық тұрғыдан бұл Kubernetes ішінде бұл көптеген Postgres жұмыс істейтін бір подкаст екенін білдіреді.
Н.С: Иә. Оның шегі бар: онымен бір уақытта 10 адам жұмыс істемейді делік. Егер сізге 20 қажет болса, біз екінші осындай подкастты іске қосамыз. Біз оны толығымен клондаймыз, екінші толық томды алғаннан кейін оның бірдей 10 «жұқа» клондары болады. Сіз бұл мүмкіндікті көрмейсіз бе?
DS: Мұнда қауіпсіздік мәселелерін қосу керек. Ұйымдастырудың бұл түрі бұл подкасттың жоғары артықшылықтарға (мүмкіндіктерге) ие екенін білдіреді, себебі ол файлдық жүйеде стандартты емес операцияларды орындай алады... Бірақ қайталаймын: орта мерзімді перспективада олар Kubernetes-те сақтауды түзетеді деп сенемін, және бұлттар олар бүкіл оқиғаны томдармен түзетеді - бәрі «жұмыс істейді». Өлшемді өзгерту, клондау болады... Көлемі бар – біз: «Оның негізінде жаңасын жасаңыз» деп айтамыз және бір жарым секундтан кейін біз қажет нәрсені аламыз.
Н.С: Мен көп терабайт үшін бір жарым секундқа сенбеймін. Кефте сіз мұны өзіңіз жасайсыз, бірақ сіз бұлттар туралы айтасыз. Бұлтқа өтіңіз, EC2-де көп терабайт EBS көлемінің клонын жасаңыз және өнімділіктің қандай болатынын көріңіз. Бұл бірнеше секундты алмайды. Олардың қашан осы деңгейге жететіні мені қатты қызықтырады. Мен не айтып тұрғаныңызды түсінемін, бірақ мен басқаша айтуды өтінемін.
DS: Жарайды, бірақ мен қысқа мерзімді емес, орта мерзімді айттым. Бірнеше жыл бойы.
Zalando ұсынған PostgreSQL операторы туралы
Осы кездесудің ортасында Заландоның бұрынғы әзірлеушісі Алексей Клюкин де қосылып, PostgreSQL операторының тарихы туралы айтты:
Бұл тақырыптың жалпы қозғалғаны өте жақсы: Postgres және Kubernetes. Біз мұны 2017 жылы Заландода жасай бастағанда, бұл бәрінің қалаған тақырыбы болды, бірақ ешкім істемеді. Барлығында Kubernetes болды, бірақ олар дерекқормен не істеу керектігін сұрағанда, тіпті адамдарға ұнайды К8-ді уағыздаған , былай деді:
«Басқарылатын қызметтерге өтіп, оларды пайдаланыңыз, Kubernetes-те дерекқорды іске қоспаңыз. Әйтпесе, сіздің K8 құрылғыларыңыз, мысалы, жаңартуды, барлық түйіндерді өшіруді шешеді және деректеріңіз алыс, алыс ұшады».
Біз осы кеңеске қайшы, 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 жұмыс істеп тұрғанын түсінуіңіз керек. Ол үнемі дамып, жетілдіріліп, тіпті мезгіл-мезгіл бұзылып отырады. Сіз Kubernetes-тегі барлық өзгерістерді мұқият қадағалап отыруыңыз керек, егер бірдеңе орын алса, оған сүңгуге және оның қалай жұмыс істейтінін егжей-тегжейлі білуге дайын болуыңыз керек - мүмкін сіз қалағаннан да көп. Бұл, негізінен, дерекқорларыңызды іске қосатын кез келген платформаға қатысты...
Сонымен, біз мәлімдеме жасаған кезде бізде 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
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com