🥇Postgres ថ្ងៃអង្គារ #5: “PostgreSQL និង Kubernetes. CI/CD ស្វ័យប្រវត្តិកម្មសាកល្បង»

នៅចុងឆ្នាំមុនការផ្សាយបន្តផ្ទាល់មួយផ្សេងទៀតនៃសហគមន៍ PostgreSQL របស់រុស្ស៊ីបានកើតឡើង # RuPostgresក្នុងអំឡុងពេលដែលសហស្ថាបនិករបស់ខ្លួន Nikolai Samokhvalov បាននិយាយជាមួយនាយកបច្ចេកទេស Flan Dmitry Stolyarov អំពី DBMS នេះនៅក្នុងបរិបទរបស់ Kubernetes ។

យើងកំពុងបោះផ្សាយប្រតិចារិកនៃផ្នែកសំខាន់នៃការពិភាក្សានេះ និងនៅ បណ្តាញ YouTube សហគមន៍ វីដេអូពេញបានបង្ហោះ៖

មូលដ្ឋានទិន្នន័យ និង Kubernetes

NS៖ យើងនឹងមិននិយាយអំពី VACUUM និង CHECKPOINT ថ្ងៃនេះទេ។ យើងចង់និយាយអំពី Kubernetes ។ ខ្ញុំដឹងថាអ្នកមានបទពិសោធន៍ច្រើនឆ្នាំ។ ខ្ញុំបានមើលវីដេអូរបស់អ្នក ហើយថែមទាំងបានមើលឡើងវិញខ្លះទៀត... តោះទៅត្រង់ចំណុច៖ ហេតុអ្វីបានជា Postgres ឬ MySQL នៅក្នុង K8s ទាំងអស់?

ឌី.ស៊ី៖ មិនមាន និងមិនអាចមានចម្លើយច្បាស់លាស់ចំពោះសំណួរនេះទេ។ ប៉ុន្តែជាទូទៅ នេះគឺជាភាពសាមញ្ញ និងភាពងាយស្រួល...សក្តានុពល។ មនុស្សគ្រប់គ្នាចង់បានសេវាកម្មគ្រប់គ្រង។

NS៖ យ៉ាងម៉េច RDSមានតែនៅផ្ទះទេ?

ឌី.ស៊ី: បាទ: ដូចជា RDS គ្រប់ទីកន្លែង។

NS៖ "កន្លែងណាក៏ដោយ" គឺជាចំណុចល្អ។ នៅក្នុងក្រុមហ៊ុនធំ ៗ អ្វីគ្រប់យ៉ាងមានទីតាំងនៅកន្លែងផ្សេងៗគ្នា។ ចុះហេតុអ្វីបានជាប្រសិនបើជាក្រុមហ៊ុនធំមិនយកដំណោះស្រាយដែលត្រៀមរួចរាល់? ឧទាហរណ៍ Nutanix មានការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួន ក្រុមហ៊ុនផ្សេងទៀត (VMware...) មាន "RDS ដូចគ្នា តែនៅផ្ទះ"។

ឌី.ស៊ី៖ ប៉ុន្តែយើងកំពុងនិយាយអំពីការអនុវត្តដាច់ដោយឡែកដែលនឹងដំណើរការតែក្នុងលក្ខខណ្ឌជាក់លាក់ប៉ុណ្ណោះ។ ហើយប្រសិនបើយើងកំពុងនិយាយអំពី Kubernetes នោះមានហេដ្ឋារចនាសម្ព័ន្ធជាច្រើនប្រភេទ (ដែលអាចមាននៅក្នុង K8s)។ សំខាន់នេះគឺជាស្តង់ដារសម្រាប់ APIs ទៅកាន់ cloud...

NS៖ មិនគិតថ្លៃផងដែរ!

ឌី.ស៊ី៖ វាមិនសូវសំខាន់ទេ។ សេរីភាពគឺមានសារៈសំខាន់សម្រាប់ទីផ្សារដែលមិនមែនជាផ្នែកធំពេក។ អ្វីផ្សេងទៀតគឺជាការសំខាន់... អ្នកប្រហែលជានៅចាំរបាយការណ៍ "មូលដ្ឋានទិន្នន័យ និង Kubernetes"?

NS៖ បាទ។

ឌី.ស៊ី៖ ខ្ញុំបានដឹងថាវាត្រូវបានទទួលយ៉ាងមិនច្បាស់។ មនុស្សមួយចំនួនគិតថាខ្ញុំកំពុងនិយាយ៖ "បុរសៗ តោះយកមូលដ្ឋានទិន្នន័យទាំងអស់ទៅក្នុង Kubernetes!" ខណៈពេលដែលអ្នកផ្សេងទៀតបានសម្រេចចិត្តថាទាំងនេះគឺជាកង់ដ៏គួរឱ្យភ័យខ្លាចទាំងអស់។ ប៉ុន្តែខ្ញុំចង់និយាយអ្វីដែលខុសគ្នាទាំងស្រុង៖ “មើលអ្វីដែលកំពុងកើតឡើង តើមានបញ្ហាអ្វីខ្លះ និងរបៀបដែលគេអាចដោះស្រាយបាន។ តើយើងគួរប្រើមូលដ្ឋានទិន្នន័យ Kubernetes ឥឡូវនេះទេ? ផលិតផល? ជាការប្រសើរណាស់, លុះត្រាតែអ្នកចូលចិត្ត ... ធ្វើរឿងជាក់លាក់។ ប៉ុន្តែសម្រាប់ dev ខ្ញុំអាចនិយាយបានថាខ្ញុំណែនាំវា។ សម្រាប់ dev ថាមវន្តនៃការបង្កើត/លុបបរិស្ថានគឺមានសារៈសំខាន់ខ្លាំងណាស់។"

NS: ដោយ dev តើអ្នកមានន័យថាបរិស្ថានទាំងអស់ដែលមិនមែនជាផលិតផលទេ? ដំណាក់កាល, QA…

ឌី.ស៊ី៖ ប្រសិនបើយើងនិយាយអំពី perf stands នោះប្រហែលជាមិនមែនទេ ព្រោះតម្រូវការមានជាក់លាក់។ ប្រសិនបើយើងកំពុងនិយាយអំពីករណីពិសេសដែលមូលដ្ឋានទិន្នន័យធំខ្លាំងណាស់គឺត្រូវការសម្រាប់ដំណើរការ នោះប្រហែលជាមិនមែន... ប្រសិនបើនេះជាបរិស្ថានឋិតិវន្ត និងប្រើប្រាស់បានយូរនោះ តើអ្វីជាអត្ថប្រយោជន៍នៃការមានមូលដ្ឋានទិន្នន័យនៅក្នុង K8s?

NS៖ គ្មាន។ ប៉ុន្តែតើយើងឃើញបរិយាកាសឋិតិវន្តនៅឯណា? បរិយាកាសឋិតិវន្តនឹងលែងប្រើនៅថ្ងៃស្អែក។

ឌី.ស៊ី៖ ដំណាក់កាលអាចជាឋិតិវន្ត។ យើងមានអតិថិជន...

NS៖ បាទ ខ្ញុំក៏មានមួយដែរ។ វាជាបញ្ហាធំប្រសិនបើអ្នកមានមូលដ្ឋានទិន្នន័យ 10 TB និង 200 GB ដំណាក់កាល...

ឌី.ស៊ី៖ ខ្ញុំមានករណីឡូយណាស់! នៅលើឆាកមានមូលដ្ឋានទិន្នន័យផលិតផលដែលការផ្លាស់ប្តូរត្រូវបានធ្វើឡើង។ ហើយមានប៊ូតុងមួយ: "ចាប់ផ្តើមផលិតកម្ម" ការផ្លាស់ប្តូរទាំងនេះ - deltas - ត្រូវបានបន្ថែម (វាហាក់ដូចជាពួកវាត្រូវបានធ្វើសមកាលកម្មយ៉ាងសាមញ្ញតាមរយៈ API) នៅក្នុងផលិតកម្ម។ នេះគឺជាជម្រើសកម្រនិងអសកម្មណាស់។

NS៖ ខ្ញុំបានឃើញការចាប់ផ្ដើមអាជីវកម្មនៅក្នុងជ្រលងភ្នំដែលកំពុងអង្គុយនៅ RDS ឬសូម្បីតែនៅក្នុង Heroku ទាំងនេះគឺជារឿងកាលពី 2-3 ឆ្នាំមុន ហើយពួកគេបានទាញយកកម្មវិធីចាក់ចោលទៅក្នុងកុំព្យូទ័រយួរដៃរបស់ពួកគេ។ ដោយសារតែមូលដ្ឋានទិន្នន័យនៅតែមានត្រឹមតែ 80 GB ហើយមានកន្លែងទំនេរនៅលើកុំព្យូទ័រយួរដៃ។ បន្ទាប់មកពួកគេទិញថាសបន្ថែមសម្រាប់អ្នករាល់គ្នាដើម្បីឱ្យពួកគេមានមូលដ្ឋានទិន្នន័យ 3 ដើម្បីអនុវត្តការអភិវឌ្ឍន៍ផ្សេងៗគ្នា។ នេះជារបៀបដែលវាកើតឡើងផងដែរ។ ខ្ញុំក៏បានឃើញដែរថា ពួកគេមិនខ្លាចក្នុងការចម្លងផលិតផលចូលទៅក្នុងឆាកនោះទេ វាអាស្រ័យទៅលើក្រុមហ៊ុនខ្លាំងណាស់។ ប៉ុន្តែខ្ញុំក៏បានឃើញថាពួកគេមានការភ័យខ្លាចខ្លាំងណាស់ ហើយជាញឹកញាប់ពួកគេមិនមានពេលនិងដៃគ្រប់គ្រាន់។ ប៉ុន្តែមុនពេលយើងបន្តទៅប្រធានបទនេះ ខ្ញុំចង់ឮអំពី Kubernetes ។ តើខ្ញុំយល់យ៉ាងត្រឹមត្រូវថាមិនទាន់មានអ្នកណាម្នាក់នៅឡើយទេ?

ឌី.ស៊ី៖ យើងមានមូលដ្ឋានទិន្នន័យតូចៗនៅក្នុង prod ។ យើងកំពុងនិយាយអំពីទំហំរាប់សិបជីហ្គាបៃ និងសេវាកម្មមិនសំខាន់ ដែលយើងខ្ជិលក្នុងការបង្កើតការចម្លង (ហើយវាមិនចាំបាច់ទេ)។ ហើយបានផ្តល់ថាមានការផ្ទុកធម្មតានៅក្រោម Kubernetes ។ មូលដ្ឋានទិន្នន័យនេះបានដំណើរការនៅក្នុងម៉ាស៊ីននិម្មិត - តាមលក្ខខណ្ឌនៅក្នុង VMware នៅលើប្រព័ន្ធផ្ទុកទិន្នន័យ។ យើងបានដាក់វានៅក្នុង PV ហើយឥឡូវនេះយើងអាចផ្ទេរវាពីម៉ាស៊ីនមួយទៅម៉ាស៊ីនមួយ។

NS៖ មូលដ្ឋានទិន្នន័យដែលមានទំហំរហូតដល់ 100 GB អាចដាក់ចេញក្នុងរយៈពេលពីរបីនាទីនៅលើថាសល្អ និងបណ្តាញល្អមែនទេ? ល្បឿន 1 GB ក្នុងមួយវិនាទីលែងជាកម្រនិងអសកម្មទៀតហើយ។

ឌី.ស៊ី៖ បាទ សម្រាប់ប្រតិបត្តិការលីនេអ៊ែរ នេះមិនមែនជាបញ្ហាទេ។

NS៖ មិនអីទេ យើងគ្រាន់តែគិតអំពីផលិតផល។ ហើយប្រសិនបើយើងកំពុងពិចារណា Kubernetes សម្រាប់បរិស្ថានដែលមិនមែនជាផលិតផល តើយើងគួរធ្វើអ្វី? ខ្ញុំឃើញនៅ Zalando ធ្វើប្រតិបត្តិករ, នៅក្នុង Crunchy sawingមានជម្រើសផ្សេងទៀតមួយចំនួន។ ហើយមាន OnGres - នេះគឺជាមិត្តល្អរបស់យើង Alvaro មកពីប្រទេសអេស្ប៉ាញ៖ អ្វីដែលពួកគេធ្វើគឺសំខាន់មិនមែនគ្រាន់តែទេ។ ប្រតិបត្តិករនិងការចែកចាយទាំងមូល (StackGres) ដែលក្នុងនោះបន្ថែមពីលើ Postgres ខ្លួនពួកគេក៏បានសម្រេចចិត្តដាក់ឯកសារបម្រុងទុក ប្រូកស៊ី Envoy ...

ឌី.ស៊ី៖ បេសកជនដើម្បីអ្វី? តុល្យភាពចរាចរណ៍ Postgres ជាពិសេស?

NSបាទ/ចាស៎។ នោះគឺពួកគេយល់ឃើញថា៖ ប្រសិនបើអ្នកយក Linuxប្រសិនបើយើងនិយាយអំពីការចែកចាយ និងខឺណែល នោះ PostgreSQL ធម្មតាគឺជាខឺណែល ហើយពួកគេចង់បង្កើតការចែកចាយដែលងាយស្រួលប្រើលើពពក និងដំណើរការលើ Kubernetes។ ពួកគេកំពុងភ្ជាប់សមាសធាតុ (ការបម្រុងទុក។ល។) និងបំបាត់កំហុសពួកវា ដើម្បីធានាថាពួកវាដំណើរការបានល្អ។

ឌី.ស៊ី: អស្ចារ្យ! សំខាន់នេះគឺជាកម្មវិធីដើម្បីបង្កើត Postgres គ្រប់គ្រងផ្ទាល់ខ្លួនរបស់អ្នក។

NS: យូ Linuxការចែកចាយមានបញ្ហាជាប់លាប់៖ របៀបបង្កើតកម្មវិធីបញ្ជាដើម្បីគាំទ្រផ្នែករឹងទាំងអស់។ ហើយពួកគេកំពុងគិតថាពួកគេនឹងដំណើរការនៅក្នុង Kubernetes។ ខ្ញុំដឹងថាយើងទើបតែបានឃើញការពឹងផ្អែករបស់ Zalando លើ AWS ហើយវាមិនល្អប៉ុន្មានទេ។ មិនគួរមានការពឹងផ្អែកលើហេដ្ឋារចនាសម្ព័ន្ធជាក់លាក់ណាមួយទេ - តើចំណុចសំខាន់គឺជាអ្វី?

ឌី.ស៊ី៖ ខ្ញុំមិនដឹងថាតើ Zalando ស្ថិតក្នុងស្ថានភាពបែបណានោះទេ ប៉ុន្តែនៅក្នុងការផ្ទុក Kubernetes ឥឡូវនេះត្រូវបានបង្កើតឡើងតាមរបៀបដែលវាមិនអាចទៅរួចទេក្នុងការធ្វើការបម្រុងទុកថាសដោយប្រើវិធីសាស្ត្រទូទៅ។ ថ្មីៗនេះនៅក្នុងស្តង់ដារ - នៅក្នុងកំណែចុងក្រោយបំផុត។ លក្ខណៈបច្ចេកទេសរបស់ CSI – យើងបានបង្កើតរូបថតដែលអាចធ្វើទៅបាន ប៉ុន្តែតើវាត្រូវបានអនុវត្តនៅកន្លែងណា? និយាយតាមត្រង់ទៅ អ្វីគ្រប់យ៉ាងនៅតែឆៅ... យើងកំពុងព្យាយាម CSI នៅលើ AWS, GCE, Azure, vSphere ប៉ុន្តែភ្លាមៗនៅពេលដែលអ្នកចាប់ផ្តើមប្រើវា អ្នកអាចមើលឃើញថាវាមិនទាន់រួចរាល់នៅឡើយទេ។

NS៖ នោះហើយជាមូលហេតុដែលពេលខ្លះយើងត្រូវពឹងផ្អែកលើហេដ្ឋារចនាសម្ព័ន្ធ។ ខ្ញុំគិតថានេះនៅតែជាដំណាក់កាលដំបូង - ការឈឺចាប់កើនឡើង។ សំណួរ៖ តើអ្នកនឹងផ្តល់ដំបូន្មានអ្វីខ្លះដល់អ្នកថ្មីថ្មោងដែលចង់សាកល្បង PgSQL នៅក្នុង K8s? ប្រហែលជាប្រតិបត្តិករអ្វី?

ឌី.ស៊ី៖ បញ្ហាគឺថា Postgres គឺ 3% សម្រាប់ពួកយើង។ យើងក៏មានបញ្ជីកម្មវិធីផ្សេងគ្នាជាច្រើននៅក្នុង Kubernetes ខ្ញុំនឹងមិនរាយបញ្ជីអ្វីទាំងអស់។ ឧទាហរណ៍ Elasticsearch ។ មានប្រតិបត្តិករជាច្រើន៖ ខ្លះកំពុងអភិវឌ្ឍយ៉ាងសកម្ម អ្នកផ្សេងទៀតមិនមាន។ យើងបានតាក់តែងតម្រូវការសម្រាប់ខ្លួនយើងអំពីអ្វីដែលប្រតិបត្តិករគួរមាន ដើម្បីឲ្យយើងទទួលយកវាយ៉ាងយកចិត្តទុកដាក់។ នៅក្នុងប្រតិបត្តិករពិសេសសម្រាប់ Kubernetes - មិនមែននៅក្នុង "ប្រតិបត្តិករដើម្បីធ្វើអ្វីមួយនៅក្នុងលក្ខខណ្ឌរបស់ Amazon" ... តាមពិតយើងយ៉ាងទូលំទូលាយ (= ស្ទើរតែទាំងអស់អតិថិជន) ប្រើប្រតិបត្តិករតែមួយ - សម្រាប់ Redis (យើងនឹងផ្សាយអត្ថបទអំពីគាត់ឆាប់ៗនេះ).

NS៖ ហើយមិនមែនសម្រាប់ MySQL ទេ? ខ្ញុំដឹងថា Percona... ចាប់តាំងពីពេលនេះពួកគេកំពុងធ្វើការលើ MySQL, MongoDB និង Postgres ពួកគេនឹងត្រូវបង្កើតដំណោះស្រាយជាសកលមួយចំនួន៖ សម្រាប់មូលដ្ឋានទិន្នន័យទាំងអស់ សម្រាប់អ្នកផ្តល់សេវាពពកទាំងអស់។

ឌី.ស៊ី៖ យើងមិនមានពេលមើលប្រតិបត្តិករសម្រាប់ MySQL ទេ។ នេះមិនមែនជាការផ្តោតសំខាន់របស់យើងនៅពេលនេះទេ។ MySQL ដំណើរការបានល្អក្នុងលក្ខណៈឯករាជ្យ។ ហេតុអ្វីត្រូវប្រើប្រតិបត្តិករ ប្រសិនបើអ្នកគ្រាន់តែអាចបើកដំណើរការមូលដ្ឋានទិន្នន័យ... អ្នកអាចបើកដំណើរការ Docker container ជាមួយ Postrges ឬអ្នកអាចបើកដំណើរការវាតាមរបៀបសាមញ្ញ។

NS៖ មានសំណួរអំពីរឿងនេះផងដែរ។ គ្មានប្រតិបត្តិករទេ?

ឌី.ស៊ី៖ បាទ 100% នៃពួកយើងមាន PostgreSQL ដំណើរការដោយគ្មានប្រតិបត្តិករ។ រហូតមកដល់ពេលនេះ។ យើងប្រើប្រាស់យ៉ាងសកម្មនូវប្រតិបត្តិករសម្រាប់ Prometheus និង Redis ។ យើងមានគម្រោងស្វែងរកប្រតិបត្តិករសម្រាប់ Elasticsearch - វាគឺជាកម្មវិធីមួយដែល "ឆេះ" បំផុត ពីព្រោះយើងចង់ដំឡើងវានៅក្នុង Kubernetes ក្នុង 100% នៃករណី។ ដូចដែលយើងចង់ធានាថា MongoDB តែងតែត្រូវបានដំឡើងនៅក្នុង Kubernetes ផងដែរ។ នៅទីនេះបំណងប្រាថ្នាជាក់លាក់លេចឡើង - មានអារម្មណ៍ថានៅក្នុងករណីទាំងនេះអ្វីមួយដែលអាចធ្វើបាន។ ហើយយើងមិនបានមើល Postgres ទេ។ ជាការពិតណាស់ យើងដឹងថាមានជម្រើសផ្សេងគ្នា ប៉ុន្តែតាមពិតយើងមានតែឯង។

DB សម្រាប់សាកល្បងនៅក្នុង Kubernetes

NS៖ ចូរបន្តទៅប្រធានបទនៃការធ្វើតេស្ត។ របៀបបញ្ចេញការផ្លាស់ប្តូរទៅកាន់មូលដ្ឋានទិន្នន័យ - តាមទស្សនៈរបស់ DevOps ។ មានសេវាមីក្រូ មូលដ្ឋានទិន្នន័យជាច្រើន មានអ្វីមួយកំពុងផ្លាស់ប្តូរកន្លែងណាមួយគ្រប់ពេលវេលា។ របៀបធានា CI/CD ធម្មតា ដើម្បីឱ្យអ្វីៗដំណើរការតាមលំដាប់លំដោយ តាមទស្សនៈរបស់ DBMS ។ តើវិធីសាស្រ្តរបស់អ្នកជាអ្វី?

ឌី.ស៊ី៖ មិនអាចមានចម្លើយតែមួយទេ។ មានជម្រើសជាច្រើន។ ទីមួយគឺទំហំនៃមូលដ្ឋានដែលយើងចង់រមៀលចេញ។ អ្នកផ្ទាល់បាននិយាយថាក្រុមហ៊ុនមានអាកប្បកិរិយាខុសៗគ្នាចំពោះការមានច្បាប់ចម្លងនៃមូលដ្ឋានទិន្នន័យផលិតផលនៅលើ dev និងដំណាក់កាល។

NS៖ ហើយនៅក្រោមលក្ខខណ្ឌនៃ GDPR ខ្ញុំគិតថាពួកគេកាន់តែមានការប្រុងប្រយ័ត្ន... ខ្ញុំអាចនិយាយបានថានៅអឺរ៉ុបពួកគេបានចាប់ផ្តើមដាក់ពិន័យរួចហើយ។

ឌី.ស៊ី៖ ប៉ុន្តែជាញឹកញាប់អ្នកអាចសរសេរកម្មវិធីដែលយកកន្លែងចាក់សំរាមពីការផលិត ហើយធ្វើឱ្យវាមានភាពច្របូកច្របល់។ ទិន្នន័យផលិតផលត្រូវបានទទួល (រូបថត បោះចោល ច្បាប់ចម្លងប្រព័ន្ធគោលពីរ...) ប៉ុន្តែវាត្រូវបានអនាមិក។ ផ្ទុយទៅវិញ វាអាចមានស្គ្រីបជំនាន់៖ ទាំងនេះអាចជាកម្មវិធី ឬគ្រាន់តែជាស្គ្រីបដែលបង្កើតមូលដ្ឋានទិន្នន័យធំ។ បញ្ហាគឺ៖ តើត្រូវចំណាយពេលប៉ុន្មានដើម្បីបង្កើតរូបភាពមូលដ្ឋាន? ហើយត្រូវប្រើពេលប៉ុន្មានដើម្បីដាក់ពង្រាយវាក្នុងបរិយាកាសដែលចង់បាន?

យើងបានមកដល់គ្រោងការណ៍មួយ៖ ប្រសិនបើអតិថិជនមានសំណុំទិន្នន័យថេរ (កំណែមូលដ្ឋានទិន្នន័យអប្បបរមា) នោះយើងប្រើពួកវាតាមលំនាំដើម។ ប្រសិនបើយើងកំពុងនិយាយអំពីបរិស្ថានពិនិត្យឡើងវិញ នៅពេលដែលយើងបង្កើតសាខាមួយ យើងបានដាក់ពង្រាយឧទាហរណ៍នៃកម្មវិធី - យើងដាក់ចេញនូវមូលដ្ឋានទិន្នន័យតូចមួយនៅទីនោះ។ ប៉ុន្តែវាប្រែជាល្អ។ ជម្រើស។នៅពេលដែលយើងយកកន្លែងចាក់សំរាមពីផលិតកម្មម្តងក្នុងមួយថ្ងៃ (នៅពេលយប់) ហើយបង្កើត Docker container ជាមួយ PostgreSQL និង MySQL ជាមួយនឹងទិន្នន័យដែលបានផ្ទុកនេះដោយផ្អែកលើវា។ ប្រសិនបើអ្នកត្រូវការពង្រីកមូលដ្ឋានទិន្នន័យ 50 ដងពីរូបភាពនេះ វាត្រូវបានធ្វើយ៉ាងសាមញ្ញ និងរហ័ស។

NS៖ ដោយការចម្លងសាមញ្ញ?

ឌី.ស៊ី៖ ទិន្នន័យត្រូវបានរក្សាទុកដោយផ្ទាល់នៅក្នុងរូបភាព Docker ។ ទាំងនោះ។ យើងមានរូបភាពដែលត្រៀមរួចជាស្រេច ទោះបីជា 100 GB ក៏ដោយ។ សូមអរគុណដល់ស្រទាប់នៅក្នុង Docker យើងអាចដាក់ពង្រាយរូបភាពនេះឱ្យបានច្រើនដងតាមដែលយើងត្រូវការ។ វិធីសាស្រ្តគឺឆោតល្ងង់ប៉ុន្តែវាដំណើរការល្អ។

NS៖ បន្ទាប់មក នៅពេលអ្នកសាកល្បង វាផ្លាស់ប្តូរភ្លាមៗនៅក្នុង Docker មែនទេ? ចម្លងលើការសរសេរនៅខាងក្នុង Docker - បោះវាចោល ហើយទៅម្តងទៀត អ្វីគ្រប់យ៉ាងគឺល្អ។ ថ្នាក់! ហើយតើអ្នកបានប្រើវាអស់ហើយឬនៅ?

ឌី.ស៊ី៖ ជាយូរមកហើយ។

NS៖ យើងធ្វើរឿងស្រដៀងគ្នាខ្លាំងណាស់។ មានតែយើងទេដែលមិនប្រើការចម្លងលើការសរសេររបស់ Docker ប៉ុន្តែមានមួយផ្សេងទៀត។

ឌី.ស៊ី៖ វាមិនមែនជាទូទៅទេ។ ហើយ Docker ធ្វើការនៅគ្រប់ទីកន្លែង។

NS៖ តាមទ្រឹស្តី បាទ។ ប៉ុន្តែយើងក៏មានម៉ូឌុលនៅទីនោះដែរ អ្នកអាចបង្កើតម៉ូឌុលផ្សេងៗគ្នា និងធ្វើការជាមួយប្រព័ន្ធឯកសារផ្សេងៗ។ បន្តិចទៀតនៅទីនេះ។ ពីផ្នែក Postgres យើងមើលទៅទាំងអស់នេះខុសគ្នា។ ឥឡូវនេះខ្ញុំបានមើលពីខាង Docker ហើយឃើញថាអ្វីៗដំណើរការសម្រាប់អ្នក។ ប៉ុន្តែប្រសិនបើមូលដ្ឋានទិន្នន័យមានទំហំធំ ឧទាហរណ៍ 1 TB នោះអ្វីៗទាំងអស់នេះត្រូវចំណាយពេលយូរ៖ ប្រតិបត្តិការនៅពេលយប់ និងបញ្ចូលអ្វីៗគ្រប់យ៉ាងទៅក្នុង Docker... ហើយប្រសិនបើ 5 TB ត្រូវបានបញ្ចូលទៅក្នុង Docker... ឬអ្វីៗគ្រប់យ៉ាងល្អ?

ឌី.ស៊ី៖ អ្វីដែលខុសគ្នា៖ ទាំងនេះគឺជា blobs គ្រាន់តែប៊ីត និងបៃ។

NS៖ ភាពខុសគ្នាគឺ៖ តើអ្នកធ្វើវាតាមរយៈការបោះចោល និងស្តារឡើងវិញទេ?

ឌី.ស៊ី៖ មិនចាំបាច់ទាល់តែសោះ។ វិធីសាស្រ្តសម្រាប់បង្កើតរូបភាពនេះអាចខុសគ្នា។

NS៖ សម្រាប់អតិថិជនមួយចំនួន យើងបានបង្កើតវា ដូច្នេះជំនួសឱ្យការបង្កើតរូបភាពមូលដ្ឋានជាទៀងទាត់ យើងរក្សាវាឱ្យទាន់សម័យជានិច្ច។ វាគឺជាការចម្លងដ៏សំខាន់ ប៉ុន្តែវាទទួលទិន្នន័យមិនមែនពីមេដោយផ្ទាល់ទេ ប៉ុន្តែតាមរយៈប័ណ្ណសារ។ បណ្ណសារប្រព័ន្ធគោលពីរដែល WAL ត្រូវបានទាញយកជារៀងរាល់ថ្ងៃ ជាកន្លែងដែលការបម្រុងទុកត្រូវបានយក... WALs ទាំងនេះបន្ទាប់មកទៅដល់រូបភាពមូលដ្ឋានដោយមានការពន្យាពេលបន្តិច (តាមន័យត្រង់ 1-2 វិនាទី)។ យើងក្លូនពីវាតាមមធ្យោបាយណាមួយ - ឥឡូវនេះយើងមាន ZFS តាមលំនាំដើម។

ឌី.ស៊ី៖ ប៉ុន្តែជាមួយ ZFS អ្នកត្រូវបានកំណត់ត្រឹមថ្នាំងមួយ។

NS៖ បាទ។ ប៉ុន្តែ ZFS ក៏មានវេទមន្តផងដែរ។ ផ្ញើ៖ ជាមួយវា អ្នកអាចផ្ញើរូបថតមួយសន្លឹក ហើយសូម្បីតែ (ខ្ញុំមិនទាន់បានសាកល្បងវានៅឡើយទេ ប៉ុន្តែ...) អ្នកអាចផ្ញើ delta រវាងពីរ PGDATA. តាមពិតទៅ យើងមានឧបករណ៍មួយទៀតដែលយើងពិតជាមិនបានពិចារណាសម្រាប់កិច្ចការបែបនេះ។ PostgreSQL មាន pg_rewindដែលដំណើរការដូចជា rsync "ឆ្លាតវៃ" រំលងអ្វីដែលអ្នកមិនចាំបាច់មើល ពីព្រោះគ្មានអ្វីផ្លាស់ប្តូរនៅទីនោះទេ។ យើងអាចធ្វើសមកាលកម្មរហ័សរវាងម៉ាស៊ីនមេទាំងពីរ ហើយត្រឡប់វិញតាមវិធីដូចគ្នា។

ដូច្នេះ ពីនេះផ្នែក DBA បន្ថែមទៀត យើងកំពុងព្យាយាមបង្កើតឧបករណ៍ដែលអនុញ្ញាតឱ្យយើងធ្វើដូចដែលអ្នកបាននិយាយ៖ យើងមានមូលដ្ឋានទិន្នន័យមួយ ប៉ុន្តែយើងចង់សាកល្បងអ្វីមួយ 50 ដងស្ទើរតែក្នុងពេលដំណាលគ្នា។

ឌី.ស៊ី៖ 50 ដងមានន័យថាអ្នកត្រូវបញ្ជាទិញ 50 Spot ។

NS៖ ទេ យើងធ្វើអ្វីគ្រប់យ៉ាងនៅលើម៉ាស៊ីនតែមួយ។

ឌី.ស៊ី៖ ប៉ុន្តែតើអ្នកនឹងពង្រីក 50 ដងដោយរបៀបណា ប្រសិនបើមូលដ្ឋានទិន្នន័យមួយនេះគឺ terabyte ។ ភាគច្រើនទំនងជានាងត្រូវការ RAM 256 GB តាមលក្ខខណ្ឌ?

NS៖ បាទ ពេលខ្លះអ្នកត្រូវការការចងចាំច្រើន នោះជារឿងធម្មតាទេ។ ប៉ុន្តែនេះគឺជាឧទាហរណ៍ពីជីវិត។ ម៉ាស៊ីនផលិតមានស្នូល 96 និង 600 GB ។ ក្នុងពេលជាមួយគ្នានេះ 32 cores (សូម្បីតែ 16 cores ឥឡូវនេះ) និង 100-120 GB នៃអង្គចងចាំត្រូវបានប្រើសម្រាប់មូលដ្ឋានទិន្នន័យ។

ឌី.ស៊ី៖ ហើយ 50 ច្បាប់សមនឹងនៅទីនោះ?

NS៖ ដូច្នេះមានច្បាប់ចម្លងតែមួយប៉ុណ្ណោះ បន្ទាប់មកចម្លងលើការសរសេរ (ZFS) ដំណើរការ... ខ្ញុំនឹងប្រាប់អ្នកឱ្យលម្អិតបន្ថែមទៀត។

ឧទាហរណ៍ យើងមានមូលដ្ឋានទិន្នន័យ 10 TB ។ ពួកគេបានបង្កើតថាសសម្រាប់វា ZFS ក៏បានបង្រួមទំហំរបស់វា 30-40 ភាគរយ។ ដោយសារយើងមិនធ្វើការធ្វើតេស្តផ្ទុក ពេលវេលាឆ្លើយតបពិតប្រាកដមិនសំខាន់សម្រាប់យើងទេ៖ អនុញ្ញាតឱ្យវាយឺតជាង 2 ដង - មិនអីទេ។

យើងផ្តល់ឱកាសដល់អ្នកសរសេរកម្មវិធី QA DBA ជាដើម។ អនុវត្តការធ្វើតេស្តក្នុង 1-2 ខ្សែស្រឡាយ។ ជាឧទាហរណ៍ ពួកគេអាចដំណើរការការធ្វើចំណាកស្រុកមួយចំនួន។ វាមិនតម្រូវឱ្យមាន 10 cores ក្នុងពេលតែមួយទេ - វាត្រូវការ 1 Postgres backend, 1 core ។ ការធ្វើចំណាកស្រុកនឹងចាប់ផ្តើម - ប្រហែលជា ស្វ័យប្រវត្តិ នឹងនៅតែចាប់ផ្តើម បន្ទាប់មកស្នូលទីពីរនឹងត្រូវបានប្រើ។ យើងមាន 16-32 ស្នូលដែលបានបែងចែក ដូច្នេះមនុស្ស 10 នាក់អាចធ្វើការក្នុងពេលតែមួយបាន មិនមានបញ្ហាទេ។

ដោយសារតែរាងកាយ PGDATA ដូចគ្នា វាប្រែថាយើងកំពុងបោកបញ្ឆោត Postgres ។ ល្បិចនេះគឺនេះ: ឧទាហរណ៍ 10 Postgres ត្រូវបានចាប់ផ្តើមក្នុងពេលដំណាលគ្នា។ តើអ្វីជាបញ្ហាជាធម្មតា? ពួកគេដាក់ shared_buffersឧបមាថា ២៥%។ ដូច្នោះហើយនេះគឺ 25 GB ។ អ្នកនឹងមិនអាចបើកដំណើរការលើសពីបីនេះទេ ព្រោះអង្គចងចាំនឹងអស់។

ប៉ុន្តែនៅចំណុចខ្លះ យើងបានដឹងថាវាមិនចាំបាច់ទេ៖ យើងកំណត់ shared_buffers ទៅ 2 GB ។ PostgreSQL មាន effective_cache_sizeហើយតាមការពិត វាមានតែមួយគត់ដែលមានឥទ្ធិពល ផែនការ. យើងកំណត់វាទៅ 0,5 TB ។ ហើយវាមិនសំខាន់ទេដែលថាពួកគេមិនមានពិតប្រាកដ: គាត់ធ្វើផែនការដូចជាពួកគេមាន។

ដូច្នោះហើយនៅពេលដែលយើងសាកល្បងប្រភេទនៃការធ្វើចំណាកស្រុកមួយចំនួនយើងអាចប្រមូលផែនការទាំងអស់ - យើងនឹងឃើញពីរបៀបដែលវានឹងកើតឡើងនៅក្នុងផលិតកម្ម។ វិនាទីនឹងមានភាពខុសប្លែកគ្នា (យឺតជាង) ប៉ុន្តែទិន្នន័យដែលយើងពិតជាបានអាន ហើយផែនការខ្លួនឯង (អ្វីដែលចូលរួមនៅទីនោះ។ ហើយអ្នកអាចដំណើរការការត្រួតពិនិត្យបែបនេះជាច្រើនស្របគ្នានៅលើម៉ាស៊ីនតែមួយ។

ឌី.ស៊ី៖ តើអ្នកមិនគិតថាមានបញ្ហាប៉ុន្មាននៅទីនេះទេ? ទីមួយគឺជាដំណោះស្រាយដែលដំណើរការតែលើ PostgreSQL ប៉ុណ្ណោះ។ វិធីសាស្រ្តនេះគឺឯកជនណាស់ វាមិនមានលក្ខណៈទូទៅទេ។ ទីពីរគឺថា Kubernetes (និងអ្វីគ្រប់យ៉ាងដែលបច្ចេកវិទ្យាពពកនឹងទៅឥឡូវនេះ) ពាក់ព័ន្ធនឹងថ្នាំងជាច្រើន ហើយថ្នាំងទាំងនេះគឺមានភាពមិនច្បាស់លាស់។ ហើយក្នុងករណីរបស់អ្នក វាគឺជាថ្នាំងដែលជាប់លាប់។ រឿងទាំងនេះធ្វើឱ្យខ្ញុំឈ្លោះគ្នា។

NS៖ ជាដំបូង ខ្ញុំយល់ស្រប នេះជារឿង Postgres សុទ្ធសាធ។ ខ្ញុំគិតថាប្រសិនបើយើងមានប្រភេទ IO ផ្ទាល់ និងបណ្តុំសតិបណ្ដោះអាសន្នសម្រាប់ការចងចាំស្ទើរតែទាំងអស់នោះ វិធីសាស្រ្តនេះនឹងមិនដំណើរការទេ - ផែនការនឹងខុសគ្នា។ ប៉ុន្តែសម្រាប់ពេលនេះ យើងធ្វើការតែជាមួយ Postgres យើងមិនគិតពីអ្នកដទៃទេ។

អំពី Kubernetes ។ អ្នកផ្ទាល់ប្រាប់យើងគ្រប់ទីកន្លែងថាយើងមានមូលដ្ឋានទិន្នន័យជាប់លាប់។ ប្រសិនបើឧទាហរណ៍បរាជ័យ រឿងសំខាន់គឺរក្សាទុកថាស។ នៅទីនេះយើងក៏មានវេទិកាទាំងមូលនៅក្នុង Kubernetes ហើយសមាសធាតុជាមួយ Postgres គឺដាច់ដោយឡែកពីគ្នា (ទោះបីជាវានឹងនៅទីនោះនៅថ្ងៃណាមួយក៏ដោយ)។ ដូច្នេះ អ្វីគ្រប់យ៉ាងគឺដូចនេះ៖ វត្ថុបានធ្លាក់ចុះ ប៉ុន្តែយើងបានរក្សាទុក PV របស់វា ហើយគ្រាន់តែភ្ជាប់វាទៅវត្ថុ (ថ្មី) ផ្សេងទៀត ដូចជាគ្មានអ្វីកើតឡើង។

ឌី.ស៊ី៖ តាមទស្សនៈរបស់ខ្ញុំ យើងបង្កើតផតនៅក្នុង Kubernetes ។ K8s - elastic: knots ត្រូវបានបញ្ជាតាមតម្រូវការ។ ភារកិច្ចគឺគ្រាន់តែបង្កើត pod ហើយនិយាយថាវាត្រូវការធនធាន X ហើយបន្ទាប់មក K8s នឹងដោះស្រាយវាដោយខ្លួនឯង។ ប៉ុន្តែការគាំទ្រទំហំផ្ទុកនៅក្នុង Kubernetes នៅតែមិនស្ថិតស្ថេរ៖ 1.16នៅ 1.17 (ការចេញផ្សាយនេះត្រូវបានចេញផ្សាយ និមិត្ត មុន) លក្ខណៈពិសេសទាំងនេះក្លាយជាតែបែតាប៉ុណ្ណោះ។

ប្រាំមួយខែទៅមួយឆ្នាំនឹងកន្លងផុតទៅ - វានឹងកាន់តែមានស្ថេរភាពឬយ៉ាងហោចណាស់វានឹងត្រូវបានប្រកាសដូចនេះ។ បន្ទាប់មកលទ្ធភាពនៃការថតរូប និងផ្លាស់ប្តូរទំហំដោះស្រាយបញ្ហារបស់អ្នកទាំងស្រុង។ ដោយសារតែអ្នកមានមូលដ្ឋាន។ បាទ វាប្រហែលជាមិនលឿនទេ ប៉ុន្តែល្បឿនអាស្រ័យលើអ្វីដែល "នៅក្រោមក្រណាត់" ពីព្រោះការអនុវត្តខ្លះអាចចម្លង និងចម្លងលើការសរសេរនៅកម្រិតប្រព័ន្ធរងរបស់ថាស។

NS៖ វាក៏ចាំបាច់សម្រាប់ម៉ាស៊ីនទាំងអស់ (Amazon, Google...) ដើម្បីចាប់ផ្តើមគាំទ្រកំណែនេះ - វាត្រូវការពេលវេលាខ្លះផងដែរ។

ឌី.ស៊ី៖ យើងមិនទាន់ប្រើវានៅឡើយទេ។ យើងប្រើរបស់យើង។

ការអភិវឌ្ឍន៍ក្នុងតំបន់សម្រាប់ Kubernetes

NS៖ តើអ្នកបានជួបនូវការប្រាថ្នាបែបនេះទេនៅពេលដែលអ្នកត្រូវការដំឡើង pods ទាំងអស់នៅលើម៉ាស៊ីនតែមួយ ហើយធ្វើការសាកល្បងតូចបែបនេះ។ ដើម្បីទទួលបានភស្តុតាងនៃគំនិតយ៉ាងឆាប់រហ័ស សូមមើលថាកម្មវិធីដំណើរការនៅក្នុង Kubernetes ដោយមិនកំណត់ម៉ាស៊ីនមួយចំនួនសម្រាប់វា។ មាន Minikube មែនទេ?

ឌី.ស៊ី៖ វាហាក់ដូចជាខ្ញុំថាករណីនេះ - ដាក់ពង្រាយនៅលើថ្នាំងមួយ - គឺទាំងស្រុងអំពីការអភិវឌ្ឍន៍ក្នុងស្រុក។ ឬការបង្ហាញខ្លះនៃគំរូបែបនេះ។ បរិភោគ មីនីគូប, មាន k3s, KIND. យើងកំពុងឆ្ពោះទៅរកការប្រើប្រាស់ Kubernetes IN Docker ។ ឥឡូវនេះយើងបានចាប់ផ្តើមធ្វើការជាមួយវាសម្រាប់ការធ្វើតេស្ត។

NS៖ ខ្ញុំធ្លាប់គិតថានេះជាការប៉ុនប៉ងដើម្បីរុំផតទាំងអស់ក្នុងរូបភាព Docker មួយ។ ប៉ុន្តែវាបានប្រែក្លាយថានេះគឺអំពីអ្វីដែលខុសគ្នាទាំងស្រុង។ ទោះយ៉ាងណាក៏ដោយ មានធុងដាច់ដោយឡែក ផតដាច់ដោយឡែក - គ្រាន់តែនៅក្នុង Docker ប៉ុណ្ណោះ។

ឌី.ស៊ី៖ បាទ។ ហើយមានការក្លែងបន្លំគួរឱ្យអស់សំណើចមួយ ប៉ុន្តែអត្ថន័យគឺនេះ... werf. យើងចង់ធ្វើឱ្យវាក្លាយជារបៀបតាមលក្ខខណ្ឌ werf up៖ "យក Kubernetes ក្នុងតំបន់ឱ្យខ្ញុំ។" ហើយបន្ទាប់មកដំណើរការតាមលក្ខខណ្ឌនៅទីនោះ werf follow. បន្ទាប់មក អ្នកអភិវឌ្ឍន៍នឹងអាចកែសម្រួល IDE ហើយដំណើរការមួយនឹងត្រូវបានដាក់ឱ្យដំណើរការនៅក្នុងប្រព័ន្ធដែលមើលឃើញការផ្លាស់ប្តូរ និងបង្កើតរូបភាពឡើងវិញ ដោយដាក់ឱ្យប្រើប្រាស់វាឡើងវិញទៅកាន់ K8s មូលដ្ឋាន។ នេះជារបៀបដែលយើងចង់ព្យាយាមដោះស្រាយបញ្ហានៃការអភិវឌ្ឍន៍មូលដ្ឋាន។

រូបថត និងការក្លូនមូលដ្ឋានទិន្នន័យក្នុងការពិត K8s

NS៖ ប្រសិនបើយើងត្រឡប់ទៅចម្លងលើការសរសេរ។ ខ្ញុំបានកត់សម្គាល់ឃើញថា ពពកក៏មានរូបថតដែរ។ ពួកគេធ្វើការខុសគ្នា។ ឧទាហរណ៍នៅក្នុង GCP៖ អ្នកមានឧទាហរណ៍ពហុតេរ៉ាបៃនៅលើឆ្នេរសមុទ្រភាគខាងកើតនៃសហរដ្ឋអាមេរិក។ អ្នកថតរូបតាមកាលកំណត់។ អ្នកយកច្បាប់ចម្លងនៃថាសនៅឆ្នេរសមុទ្រភាគខាងលិចពីរូបថតមួយ - ក្នុងរយៈពេលពីរបីនាទីអ្វីគ្រប់យ៉ាងគឺរួចរាល់ វាដំណើរការយ៉ាងលឿន មានតែឃ្លាំងសម្ងាត់ប៉ុណ្ណោះដែលត្រូវបំពេញក្នុងអង្គចងចាំ។ ប៉ុន្តែក្លូនទាំងនេះ (រូបថត) គឺដើម្បី 'ផ្តល់' បរិមាណថ្មី។ នេះគឺត្រជាក់នៅពេលដែលអ្នកត្រូវបង្កើតឧទាហរណ៍ជាច្រើន។

ប៉ុន្តែសម្រាប់ការធ្វើតេស្ត វាហាក់ដូចជាខ្ញុំថា រូបថតដែលអ្នកនិយាយអំពីនៅក្នុង Docker ឬខ្ញុំនិយាយអំពី ZFS, btrfs និងសូម្បីតែ LVM ... - ពួកគេអនុញ្ញាតឱ្យអ្នកមិនបង្កើតទិន្នន័យថ្មីពិតប្រាកដនៅលើម៉ាស៊ីនតែមួយ។ នៅក្នុងពពក អ្នកនឹងនៅតែបង់ប្រាក់សម្រាប់ពួកគេរាល់ពេល ហើយរង់ចាំមិនវិនាទី ប៉ុន្តែប៉ុន្មាននាទី (ហើយក្នុងករណី ខ្ជិលផ្ទុកប្រហែលជានាឡិកា) ។

ជំនួសមកវិញ អ្នកអាចទទួលបានទិន្នន័យនេះក្នុងរយៈពេលមួយ ឬពីរវិនាទី ដំណើរការតេស្ត ហើយបោះវាចោល។ រូបថតទាំងនេះដោះស្រាយបញ្ហាផ្សេងៗ។ ក្នុងករណីដំបូង - ដើម្បីពង្រីកនិងទទួលបានច្បាប់ចម្លងថ្មីហើយទីពីរ - សម្រាប់ការធ្វើតេស្ត។

ឌី.ស៊ី៖ ខ្ញុំមិនយល់ស្របទេ។ ការធ្វើឱ្យការក្លូនកម្រិតសំឡេងដំណើរការបានត្រឹមត្រូវគឺជាភារកិច្ចរបស់ពពក។ ខ្ញុំមិនបានមើលការអនុវត្តរបស់វាទេ ប៉ុន្តែខ្ញុំដឹងពីរបៀបដែលយើងធ្វើវានៅលើ hardware។ យើងមាន Ceph វាអនុញ្ញាតឱ្យបរិមាណរាងកាយណាមួយ (RBD) និយាយ ក្លូន និងទទួលបានភាគទីពីរដែលមានលក្ខណៈដូចគ្នាក្នុងរយៈពេលរាប់សិបមិល្លីវិនាទី អាយអូអាយ'អាមី ជាដើម។ អ្នកត្រូវយល់ថាមានការចម្លងតាមការសរសេរដែលពិបាកនៅខាងក្នុង។ ហេតុអ្វីពពកមិនគួរធ្វើដូចគ្នា? ខ្ញុំប្រាកដថាពួកគេកំពុងព្យាយាមធ្វើវិធីនេះឬវិធីផ្សេងទៀត។

NS៖ ប៉ុន្តែវានឹងនៅតែចំណាយពេលប៉ុន្មានវិនាទី រាប់សិបវិនាទីដើម្បីលើកឧទាហរណ៍ នាំ Docker មកទីនោះ។ល។

ឌី.ស៊ី៖ ហេតុអ្វីចាំបាច់លើកឧទាហរណ៍ទាំងមូល? យើងមានឧទាហរណ៍មួយដែលមានស្នូល 32, 16 ... ហើយវាអាចសមនឹងវា - ឧទាហរណ៍បួន។ ពេលយើងបញ្ជាទិញទីប្រាំ វត្ថុនោះនឹងត្រូវបានលើកឡើង ហើយបន្ទាប់មកវានឹងត្រូវបានលុប។

NS៖ បាទ គួរឱ្យចាប់អារម្មណ៍ Kubernetes ប្រែទៅជារឿងផ្សេង។ មូលដ្ឋានទិន្នន័យរបស់យើងមិនស្ថិតនៅក្នុង K8s ទេ ហើយយើងមានឧទាហរណ៍មួយ។ ប៉ុន្តែការក្លូនមូលដ្ឋានទិន្នន័យពហុតេរ៉ាបៃត្រូវចំណាយពេលមិនលើសពីពីរវិនាទី។

ឌី.ស៊ី៖ នេះពិតជាអស្ចារ្យណាស់។ ប៉ុន្តែចំណុចដំបូងរបស់ខ្ញុំគឺថា នេះមិនមែនជាដំណោះស្រាយទូទៅទេ។ បាទ វាត្រជាក់ណាស់ ប៉ុន្តែវាសាកសមសម្រាប់តែ Postgres និងនៅលើថ្នាំងមួយប៉ុណ្ណោះ។

NS៖ វាសមរម្យមិនត្រឹមតែសម្រាប់ Postgres ប៉ុណ្ណោះទេ៖ ផែនការទាំងនេះ ដូចដែលខ្ញុំបានពិពណ៌នានឹងដំណើរការតែនៅក្នុងវាប៉ុណ្ណោះ។ ប៉ុន្តែប្រសិនបើយើងមិនខ្វល់អំពីគម្រោង ហើយយើងគ្រាន់តែត្រូវការទិន្នន័យទាំងអស់សម្រាប់ការធ្វើតេស្តមុខងារ នោះវាគឺសមរម្យសម្រាប់ DBMS ណាមួយ។

ឌី.ស៊ី៖ ជាច្រើនឆ្នាំមុន យើងបានធ្វើអ្វីមួយស្រដៀងគ្នានៅលើរូបថត LVM។ នេះគឺជាបុរាណ។ វិធីសាស្រ្តនេះត្រូវបានប្រើប្រាស់យ៉ាងសកម្ម។ ថ្នាំងរដ្ឋគ្រាន់តែជាការឈឺចាប់ប៉ុណ្ណោះ។ ដោយសារតែអ្នកមិនគួរបោះបង់ចោល អ្នកត្រូវតែចងចាំពួកគេជានិច្ច...

NS៖ តើអ្នកឃើញលទ្ធភាពនៃកូនកាត់នៅទីនេះទេ? ចូរនិយាយថា stateful គឺជាប្រភេទនៃ pod មួយចំនួន វាដំណើរការសម្រាប់មនុស្សជាច្រើន (អ្នកសាកល្បងជាច្រើន) ។ យើងមានភាគមួយ ប៉ុន្តែដោយសារប្រព័ន្ធឯកសារ ក្លូនគឺជាមូលដ្ឋាន។ ប្រសិនបើផតធ្លាក់ ប៉ុន្តែថាសនៅតែដដែល ផតនឹងកើនឡើង រាប់ព័ត៌មានអំពីក្លូនទាំងអស់ រើសអ្វីៗទាំងអស់ម្តងទៀត ហើយនិយាយថា "នេះគឺជាក្លូនរបស់អ្នកដែលកំពុងដំណើរការនៅលើច្រកទាំងនេះ សូមបន្តធ្វើការជាមួយពួកវា។"

ឌី.ស៊ី៖ តាមបច្ចេកទេស នេះមានន័យថានៅក្នុង Kubernetes វាគឺជាផតមួយដែលយើងដំណើរការ Postgres ជាច្រើន។

NS៖ បាទ។ គាត់មានដែនកំណត់៖ ចូរនិយាយថាមិនលើសពី 10 នាក់ធ្វើការជាមួយគាត់ក្នុងពេលតែមួយ។ ប្រសិនបើអ្នកត្រូវការ 20 យើងនឹងបើកដំណើរការផតថលបែបនេះទីពីរ។ យើងនឹងក្លូនវាយ៉ាងពេញលេញ ដោយបានទទួលបរិមាណពេញលេញទីពីរ វានឹងមានក្លូន "ស្តើង" ចំនួន 10 ដូចគ្នា។ តើអ្នកមិនឃើញឱកាសនេះទេ?

ឌី.ស៊ី៖ យើងត្រូវបន្ថែមបញ្ហាសុវត្ថិភាពនៅទីនេះ។ ប្រភេទនៃស្ថាប័ននេះបង្កប់ន័យថាផតនេះមានសិទ្ធិខ្ពស់ (សមត្ថភាព) ព្រោះវាអាចដំណើរការមិនស្តង់ដារលើប្រព័ន្ធឯកសារ... ប៉ុន្តែខ្ញុំនិយាយម្តងទៀត៖ ខ្ញុំជឿថាក្នុងរយៈពេលមធ្យម ពួកគេនឹងជួសជុលការផ្ទុកនៅក្នុង Kubernetes ហើយនៅក្នុង ពពកពួកគេនឹងជួសជុលរឿងទាំងមូលជាមួយនឹងបរិមាណ - អ្វីគ្រប់យ៉ាងនឹង "គ្រាន់តែដំណើរការ" ។ វានឹងមានការផ្លាស់ប្តូរទំហំ ការក្លូន... មានបរិមាណមួយ - យើងនិយាយថា "បង្កើតថ្មីមួយដោយផ្អែកលើវា" ហើយបន្ទាប់ពីមួយវិនាទីកន្លះយើងទទួលបានអ្វីដែលយើងត្រូវការ។

NS៖ ខ្ញុំមិនជឿក្នុងរយៈពេលមួយវិនាទីកន្លះសម្រាប់ terabytes ជាច្រើន។ នៅលើ Ceph អ្នកធ្វើវាដោយខ្លួនឯង ប៉ុន្តែអ្នកនិយាយអំពីពពក។ ចូលទៅកាន់ពពក បង្កើតការក្លូននៃបរិមាណ EBS ពហុតេរ៉ាបៃនៅលើ EC2 ហើយមើលថាតើដំណើរការនឹងទៅជាយ៉ាងណា។ វានឹងមិនចំណាយពេលប៉ុន្មានវិនាទីទេ។ ខ្ញុំចាប់អារម្មណ៍ខ្លាំងណាស់នៅពេលពួកគេនឹងឈានដល់កម្រិតនេះ។ ខ្ញុំយល់ពីអ្វីដែលអ្នកកំពុងនិយាយ ប៉ុន្តែខ្ញុំសុំឱ្យខុសគ្នា។

ឌី.ស៊ី៖ អូខេ ប៉ុន្តែខ្ញុំនិយាយក្នុងរយៈពេលមធ្យម មិនមែនរយៈពេលខ្លីទេ។ ជាច្រើនឆ្នាំ។

អំពីប្រតិបត្តិករសម្រាប់ PostgreSQL ពី Zalando

នៅពាក់កណ្តាលនៃកិច្ចប្រជុំនេះ Alexey Klyukin ដែលជាអតីតអ្នកអភិវឌ្ឍន៍មកពី Zalando ក៏បានចូលរួម និងនិយាយអំពីប្រវត្តិរបស់ប្រតិបត្តិករ PostgreSQL ផងដែរ៖

វាល្អណាស់ដែលប្រធានបទនេះត្រូវបានប៉ះពាល់ជាទូទៅ៖ ទាំង Postgres និង Kubernetes ។ នៅពេលដែលយើងចាប់ផ្តើមធ្វើវានៅ Zalando ក្នុងឆ្នាំ 2017 វាជាប្រធានបទដែលមនុស្សគ្រប់គ្នាចង់ធ្វើ ប៉ុន្តែគ្មាននរណាម្នាក់ធ្វើនោះទេ។ មនុស្សគ្រប់រូបមាន Kubernetes រួចហើយ ប៉ុន្តែនៅពេលដែលពួកគេសួរថាតើត្រូវធ្វើអ្វីជាមួយមូលដ្ឋានទិន្នន័យ សូម្បីតែមនុស្សក៏ចូលចិត្តដែរ។ Kelsey Hightowerដែលអធិប្បាយ K8s បាននិយាយអ្វីមួយដូចនេះ៖
“ចូលទៅកាន់សេវាកម្មដែលបានគ្រប់គ្រង ហើយប្រើពួកវា កុំដំណើរការមូលដ្ឋានទិន្នន័យនៅក្នុង Kubernetes ។ បើមិនដូច្នោះទេ K8s របស់អ្នកនឹងសម្រេចចិត្ត ជាឧទាហរណ៍ ដើម្បីធ្វើការអាប់ដេត សូមបិទថ្នាំងទាំងអស់ ហើយទិន្នន័យរបស់អ្នកនឹងហោះហើរទៅឆ្ងាយ។”
យើងបានសម្រេចចិត្តបង្កើតប្រតិបត្តិករមួយដែលផ្ទុយនឹងដំបូន្មាននេះនឹងចាប់ផ្តើមមូលដ្ឋានទិន្នន័យ Postgres នៅក្នុង Kubernetes ។ ហើយយើងមានហេតុផលល្អ - ប៉ាតូនី. នេះគឺជាការបរាជ័យដោយស្វ័យប្រវត្តិសម្រាប់ PostgreSQL ធ្វើបានត្រឹមត្រូវ i.e. ដោយប្រើ etcd កុងស៊ុល ឬ ZooKeeper ជាកន្លែងផ្ទុកព័ត៌មានអំពីចង្កោម។ ឃ្លាំងបែបនេះដែលនឹងផ្តល់ឱ្យអ្នកគ្រប់គ្នាដែលសួរឧទាហរណ៍អ្វីដែលអ្នកដឹកនាំបច្ចុប្បន្នគឺព័ត៌មានដូចគ្នា - បើទោះបីជាការពិតដែលថាយើងមានអ្វីគ្រប់យ៉ាងដែលបានចែកចាយ - ដូច្នេះមិនមានខួរក្បាលបំបែក។ បូកយើងមាន រូបថតរបស់ Docker សម្រាប់គាត់។
ជាទូទៅ តម្រូវការរបស់ក្រុមហ៊ុនសម្រាប់ការបរាជ័យដោយស្វ័យប្រវត្តិបានលេចឡើងបន្ទាប់ពីការផ្លាស់ប្តូរពីមជ្ឈមណ្ឌលទិន្នន័យផ្នែករឹងខាងក្នុងទៅកាន់ពពក។ ពពកត្រូវបានផ្អែកលើដំណោះស្រាយ PaaS (Platform-as-a-Service) ដែលមានកម្មសិទ្ធិ។ វាជាប្រភពបើកទូលាយ ប៉ុន្តែវាត្រូវការការងារជាច្រើនដើម្បីឱ្យវាដំណើរការ។ វាត្រូវបានគេហៅថា STUPS.
ដំបូងឡើយ មិនមាន Kubernetes ទេ។ ច្បាស់ជាងនេះទៅទៀត នៅពេលដែលដំណោះស្រាយផ្ទាល់ខ្លួនរបស់យើងត្រូវបានដាក់ពង្រាយ K8s មានរួចហើយ ប៉ុន្តែវាឆៅខ្លាំងណាស់ ដែលវាមិនស័ក្តិសមសម្រាប់ការផលិត។ តាមគំនិតរបស់ខ្ញុំ គឺឆ្នាំ 2015 ឬ 2016។ នៅឆ្នាំ 2017 Kubernetes មានភាពចាស់ទុំតិច ឬច្រើន—មានតម្រូវការក្នុងការធ្វើចំណាកស្រុកនៅទីនោះ។
ហើយយើងមានធុង Docker រួចហើយ។ មាន PaaS ដែលប្រើ Docker ។ ហេតុអ្វីមិនសាកល្បង K8s? ហេតុអ្វីមិនសរសេរប្រតិបត្តិករផ្ទាល់ខ្លួនរបស់អ្នក? Murat Kabilov ដែលបានមករកយើងពី Avito បានចាប់ផ្តើមនេះជាគម្រោងមួយនៅលើគំនិតផ្តួចផ្តើមផ្ទាល់ខ្លួនរបស់គាត់ - "លេង" ហើយគម្រោង "បានបិទ" ។
ប៉ុន្តែជាទូទៅខ្ញុំចង់និយាយអំពី AWS ។ ហេតុអ្វីបានជាមានកូដប្រវត្តិសាស្រ្ត AWS ទាក់ទងនឹង...
នៅពេលអ្នកដំណើរការអ្វីមួយនៅក្នុង Kubernetes អ្នកត្រូវយល់ថា K8s គឺជាការងារដែលកំពុងដំណើរការ។ វាត្រូវបានអភិវឌ្ឍឥតឈប់ឈរ កែលម្អ និងសូម្បីតែបែកបាក់ពីមួយពេលទៅមួយពេល។ អ្នកត្រូវតាមដានយ៉ាងដិតដល់នូវការផ្លាស់ប្តូរទាំងអស់នៅក្នុង Kubernetes អ្នកត្រូវត្រៀមខ្លួនដើម្បីចូលទៅក្នុងវា ប្រសិនបើមានអ្វីមួយកើតឡើង ហើយរៀនពីរបៀបដែលវាដំណើរការយ៉ាងលម្អិត - ប្រហែលជាច្រើនជាងអ្នកចង់បាន។ ជាគោលការណ៍ នេះអនុវត្តចំពោះវេទិកាណាមួយដែលអ្នកដំណើរការមូលដ្ឋានទិន្នន័យរបស់អ្នក...
ដូច្នេះនៅពេលដែលយើងធ្វើសេចក្តីថ្លែងការណ៍ យើងមាន Postgres ដំណើរការលើភាគខាងក្រៅ (EBS ក្នុងករណីនេះចាប់តាំងពីយើងកំពុងធ្វើការលើ AWS)។ មូលដ្ឋានទិន្នន័យបានកើនឡើង នៅចំណុចខ្លះវាចាំបាច់ដើម្បីផ្លាស់ប្តូរទំហំវា៖ ឧទាហរណ៍ ទំហំដំបូងនៃ EBS គឺ 100 TB មូលដ្ឋានទិន្នន័យបានកើនឡើងដល់វា ឥឡូវនេះយើងចង់ធ្វើឱ្យ EBS 200 TB ។ យ៉ាងម៉េច? ចូរនិយាយថាអ្នកអាចធ្វើការ dump/restore លើ instance ថ្មី ប៉ុន្តែវានឹងចំណាយពេលយូរ ហើយពាក់ព័ន្ធនឹងពេលវេលារងចាំ។
ដូច្នេះ ខ្ញុំចង់ប្ដូរទំហំដែលនឹងពង្រីកភាគថាស EBS ហើយបន្ទាប់មកប្រាប់ប្រព័ន្ធឯកសារឱ្យប្រើទំហំថ្មី។ ហើយយើងបានធ្វើវា ប៉ុន្តែនៅពេលនោះ Kubernetes មិនមាន API សម្រាប់ប្រតិបត្តិការផ្លាស់ប្តូរទំហំទេ។ ចាប់តាំងពីយើងធ្វើការលើ AWS យើងបានសរសេរកូដសម្រាប់ API របស់វា។
គ្មាននរណាម្នាក់រារាំងអ្នកពីការធ្វើដូចគ្នាសម្រាប់វេទិកាផ្សេងទៀតទេ។ មិនមានតម្រុយណាមួយនៅក្នុងសេចក្តីថ្លែងការណ៍ដែលថាវាអាចដំណើរការបានតែលើ AWS ប៉ុណ្ណោះ ហើយវានឹងមិនដំណើរការលើអ្វីផ្សេងទៀតនោះទេ។ ជាទូទៅ នេះគឺជាគម្រោងប្រភពបើកចំហ៖ ប្រសិនបើអ្នកណាម្នាក់ចង់បង្កើនល្បឿននៃការលេចឡើងនៃការប្រើប្រាស់ API ថ្មី អ្នកត្រូវបានស្វាគមន៍។ បរិភោគ GitHubទាញសំណើ - ក្រុម Zalando ព្យាយាមឆ្លើយតបទៅពួកគេយ៉ាងរហ័ស និងផ្សព្វផ្សាយប្រតិបត្តិករ។ តាមខ្ញុំដឹងគឺគម្រោង បានចូលរួម នៅ Google Summer of Code និងគំនិតផ្តួចផ្តើមស្រដៀងគ្នាមួយចំនួនទៀត។ Zalando កំពុងធ្វើការយ៉ាងសកម្មលើវា។

PS ប្រាក់រង្វាន់!

ប្រសិនបើអ្នកចាប់អារម្មណ៍លើប្រធានបទ PostgreSQL និង Kubernetes សូមចំណាំផងដែរថា Postgres ថ្ងៃអង្គារបន្ទាប់បានកើតឡើងកាលពីសប្តាហ៍មុន ដែលខ្ញុំបាននិយាយជាមួយ Nikolai Alexander Kukushkin មកពី Zalando. វីដេអូពីវាមាន នៅទីនេះ.