គំរូនៃការផ្ទុកទិន្នន័យនៅក្នុង Kubernetes

ហេហេ!

យើងរំលឹកអ្នកថាយើងបានចេញផ្សាយមួយផ្សេងទៀតគួរឱ្យចាប់អារម្មណ៍និងមានប្រយោជន៍បំផុត។ សៀវភៅ អំពីលំនាំ Kubernetes ។ វាទាំងអស់បានចាប់ផ្តើមជាមួយ "លំនាំ"Brendan Burns ហើយដោយវិធីនេះ យើងមានការងារនៅក្នុងផ្នែកនេះ។ ឆ្អិន. ថ្ងៃនេះ យើងសូមអញ្ជើញអ្នកឱ្យអានអត្ថបទមួយពីប្លុក MinIO ដែលរៀបរាប់យ៉ាងខ្លីអំពីនិន្នាការ និងជាក់លាក់នៃគំរូនៃការផ្ទុកទិន្នន័យនៅក្នុង Kubernetes ។

Kubernetes បានផ្លាស់ប្តូរជាមូលដ្ឋាននូវការអភិវឌ្ឍន៍កម្មវិធីបែបប្រពៃណី និងលំនាំនៃការប្រើប្រាស់។ ឥឡូវនេះក្រុមមួយអាចបង្កើត សាកល្បង និងដាក់ឱ្យប្រើប្រាស់កម្មវិធីមួយក្នុងរយៈពេលប៉ុន្មានថ្ងៃ—នៅទូទាំងបរិស្ថានជាច្រើន ទាំងអស់នៅក្នុងក្រុម Kubernetes ។ ការងារបែបនេះជាមួយបច្ចេកវិទ្យាជំនាន់មុន ជាធម្មតាចំណាយពេលច្រើនសប្តាហ៍ បើមិនរាប់ខែ។

ការបង្កើនល្បឿននេះអាចធ្វើទៅបានដោយការអរូបីដែលផ្តល់ដោយ Kubernetes - នោះគឺដោយសារតែ Kubernetes ខ្លួនវាធ្វើអន្តរកម្មជាមួយនឹងព័ត៌មានលម្អិតកម្រិតទាបនៃម៉ាស៊ីនរូបវន្ត ឬម៉ាស៊ីននិម្មិត ដែលអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ប្រកាសដំណើរការដែលចង់បាន បរិមាណអង្គចងចាំដែលចង់បាន និងចំនួនកុងតឺន័រ។ ឧទាហរណ៍ ក្នុងចំណោមប៉ារ៉ាម៉ែត្រផ្សេងទៀត។ ជាមួយនឹងសហគមន៍ដ៏ធំមួយដែលគាំទ្រ Kubernetes និងការទទួលយករបស់វាបន្តពង្រីក Kubernetes គឺជាអ្នកនាំមុខគេក្នុងចំណោមវេទិការវង់តន្រ្តីកុងតឺន័រដោយរឹមធំទូលាយ។

នៅពេលដែលការប្រើប្រាស់ Kubernetes កើនឡើង ភាពច្របូកច្របល់អំពីគំរូនៃការផ្ទុករបស់វា។.

ជាមួយនឹងអ្នកគ្រប់គ្នាប្រកួតប្រជែងដណ្តើមយកដុំ Kubernetes pie (ឧ. ការផ្ទុកទិន្នន័យ) នៅពេលនិយាយអំពីការផ្ទុកទិន្នន័យ សញ្ញាត្រូវបានលង់ទឹកដោយសំឡេងច្រើន។
Kubernetes បង្កប់នូវគំរូទំនើបសម្រាប់ការអភិវឌ្ឍន៍កម្មវិធី ការដាក់ឱ្យប្រើប្រាស់ និងការគ្រប់គ្រង។ ម៉ូដែលទំនើបនេះកាត់បន្ថយការផ្ទុកទិន្នន័យពីការគណនា។ ដើម្បីយល់ច្បាស់ពីការផ្ដាច់ខ្លួននៅក្នុងបរិបទរបស់ Kubernetes អ្នកក៏ត្រូវយល់ថាតើកម្មវិធីគ្មានរដ្ឋ និងគ្មានរដ្ឋជាអ្វី និងរបៀបដែលការផ្ទុកទិន្នន័យសមនឹងវា។ នេះគឺជាកន្លែងដែលវិធីសាស្រ្ត REST API ដែលប្រើដោយ S3 មានគុណសម្បត្តិច្បាស់លាស់លើវិធីសាស្រ្ត POSIX/CSI នៃដំណោះស្រាយផ្សេងទៀត។

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

កុងតឺន័រគ្មានរដ្ឋ

កុងតឺន័រមានទម្ងន់ស្រាល និងមានលក្ខណៈធម្មជាតិ។ ពួកវាអាចត្រូវបានបញ្ឈប់ ដកចេញ ឬដាក់ពង្រាយទៅកាន់ថ្នាំងផ្សេងទៀតយ៉ាងងាយស្រួល - ទាំងអស់ក្នុងរយៈពេលតែប៉ុន្មានវិនាទីប៉ុណ្ណោះ។ នៅក្នុងប្រព័ន្ធរៀបចំកុងតឺន័រដ៏ធំមួយ ប្រតិបត្តិការបែបនេះកើតឡើងគ្រប់ពេលវេលា ហើយអ្នកប្រើប្រាស់មិនកត់សំគាល់សូម្បីតែការផ្លាស់ប្តូរបែបនេះ។ ទោះយ៉ាងណាក៏ដោយ ការផ្លាស់ទីគឺអាចធ្វើទៅបានលុះត្រាតែកុងតឺន័រមិនមានការពឹងផ្អែកណាមួយលើថ្នាំងដែលវាស្ថិតនៅ។ ធុងបែបនេះត្រូវបានគេនិយាយថាដំណើរការ គ្មានរដ្ឋ.

ធុងផ្ទុករដ្ឋ

ប្រសិនបើកុងតឺន័ររក្សាទុកទិន្នន័យនៅលើឧបករណ៍ដែលបានភ្ជាប់ក្នុងមូលដ្ឋាន (ឬនៅលើឧបករណ៍ប្លុក) នោះឃ្លាំងផ្ទុកទិន្នន័យដែលវាស្នាក់នៅនឹងត្រូវផ្លាស់ទីទៅថ្នាំងថ្មី រួមជាមួយនឹងកុងតឺន័រដោយខ្លួនឯង ក្នុងករណីមានការបរាជ័យ។ នេះសំខាន់ព្រោះបើមិនដូច្នេះទេកម្មវិធីដែលដំណើរការក្នុងកុងតឺន័រនឹងមិនអាចដំណើរការបានត្រឹមត្រូវទេព្រោះវាត្រូវការចូលប្រើទិន្នន័យដែលផ្ទុកនៅលើមេឌៀក្នុងស្រុក។ ធុងបែបនេះត្រូវបានគេនិយាយថាដំណើរការ រដ្ឋ.

តាមទស្សនៈបច្ចេកទេសសុទ្ធសាធ កុងតឺន័រដែលមានលក្ខណៈរដ្ឋក៏អាចផ្លាស់ទីទៅថ្នាំងផ្សេងទៀតផងដែរ។ ជាធម្មតាវាត្រូវបានសម្រេចដោយប្រើប្រព័ន្ធឯកសារដែលបានចែកចាយ ឬទប់ស្កាត់ការផ្ទុកបណ្តាញដែលភ្ជាប់ទៅនឹងថ្នាំងទាំងអស់ដែលកំពុងដំណើរការកុងតឺន័រ។ នៅក្នុងវិធីនេះ កុងតឺន័រចូលប្រើបរិមាណសម្រាប់ការផ្ទុកទិន្នន័យជាប់លាប់ ហើយព័ត៌មានត្រូវបានរក្សាទុកនៅលើថាសដែលមានទីតាំងនៅទូទាំងបណ្តាញ។ ខ្ញុំនឹងហៅវិធីសាស្ត្រនេះថា "វិធីសាស្រ្តកុងតឺន័រដែលមានរដ្ឋ" ហើយនៅក្នុងអត្ថបទដែលនៅសល់ខ្ញុំនឹងហៅវាថាសម្រាប់ជាប្រយោជន៍នៃឯកសណ្ឋាន។

នៅក្នុងវិធីសាស្រ្តកុងតឺន័រដែលមានស្ថានភាពធម្មតា ផតនៃកម្មវិធីទាំងអស់ត្រូវបានភ្ជាប់ទៅប្រព័ន្ធឯកសារដែលបានចែកចាយតែមួយ ដែលជាប្រភេទនៃការផ្ទុករួមគ្នាដែលទិន្នន័យកម្មវិធីទាំងអស់ស្ថិតនៅ។ ខណៈពេលដែលការប្រែប្រួលខ្លះអាចធ្វើទៅបាន នេះគឺជាវិធីសាស្រ្តកម្រិតខ្ពស់។

ឥឡូវនេះ សូមក្រឡេកមើលមូលហេតុដែលវិធីសាស្រ្តកុងតឺន័រដែលមានសភាពទ្រុឌទ្រោមគឺជាការប្រឆាំងនឹងគំរូនៅក្នុងពិភពពពក។

ការរចនាកម្មវិធីដើមនៅលើពពក

ជាប្រពៃណី កម្មវិធីបានប្រើមូលដ្ឋានទិន្នន័យសម្រាប់ការផ្ទុកព័ត៌មានដែលមានរចនាសម្ព័ន្ធ និងថាសមូលដ្ឋាន ឬប្រព័ន្ធឯកសារចែកចាយ ដែលទិន្នន័យដែលគ្មានរចនាសម្ព័ន្ធ ឬសូម្បីតែពាក់កណ្តាលរចនាសម្ព័ន្ធទាំងអស់ត្រូវបានបោះចោល។ នៅពេលដែលបរិមាណនៃទិន្នន័យដែលមិនមានរចនាសម្ព័ន្ធកើនឡើង អ្នកអភិវឌ្ឍន៍បានដឹងថា POSIX មានភាពច្របូកច្របល់ពេក មានតម្លៃលើសគេ ហើយទីបំផុតបានរារាំងដល់ការអនុវត្តកម្មវិធីនៅពេលផ្លាស់ទីទៅខ្នាតធំពិតប្រាកដ។

នេះបានរួមចំណែកជាចម្បងដល់ការលេចចេញនូវស្តង់ដារថ្មីសម្រាប់ការផ្ទុកទិន្នន័យ ពោលគឺការផ្ទុកនៅលើពពក ដែលធ្វើការផ្អែកលើ REST API ជាចម្បង និងរំដោះកម្មវិធីពីការថែទាំបន្ទុកដ៏លំបាកនៃកន្លែងផ្ទុកទិន្នន័យមូលដ្ឋាន។ ក្នុងករណីនេះ កម្មវិធី​ចូល​ទៅ​ក្នុង​ទម្រង់​គ្មាន​រដ្ឋ​យ៉ាង​មាន​ប្រសិទ្ធភាព (ចាប់តាំងពី​ស្ថានភាព​ស្ថិតនៅក្នុង​កន្លែងផ្ទុក​ពីចម្ងាយ)។ កម្មវិធីទំនើបត្រូវបានបង្កើតឡើងពីដំបូងដោយគិតពីកត្តានេះ។ តាមក្បួនមួយ កម្មវិធីទំនើបណាមួយដែលដំណើរការទិន្នន័យប្រភេទមួយ ឬមួយផ្សេងទៀត (កំណត់ហេតុ ទិន្នន័យមេតា ប្លុក។

វិធីសាស្រ្តកុងតឺន័រដែលមានលក្ខណៈរដ្ឋបង្ខំឱ្យគំរូទាំងមូលនេះត្រឡប់ទៅកន្លែងដែលវាបានចាប់ផ្តើម!

ដោយប្រើចំណុចប្រទាក់ POSIX ដើម្បីរក្សាទុកទិន្នន័យ កម្មវិធីដំណើរការដូចជាមានសភាពច្បាស់លាស់ ហើយដោយសារមូលហេតុនេះ ពួកវាចាកចេញពីគោលការណ៍សំខាន់បំផុតនៃការរចនាផ្តោតលើពពក ពោលគឺសមត្ថភាពក្នុងការផ្លាស់ប្តូរទំហំនៃខ្សែស្រឡាយអ្នកធ្វើការកម្មវិធីអាស្រ័យលើការចូល។ បញ្ចូល។ ផ្ទុក ផ្លាស់ទីទៅថ្នាំងថ្មីភ្លាមៗ នៅពេលដែលថ្នាំងបច្ចុប្បន្នបរាជ័យ ហើយដូច្នេះនៅលើ។

ដោយក្រឡេកមើលស្ថានភាពនេះឱ្យកាន់តែដិតដល់ យើងឃើញថានៅពេលជ្រើសរើសកន្លែងផ្ទុកទិន្នន័យ យើងប្រឈមមុខនឹងបញ្ហា POSIX ទល់នឹង REST API ម្តងហើយម្តងទៀត ប៉ុន្តែជាមួយនឹងបញ្ហា POSIX កាន់តែធ្ងន់ធ្ងរឡើងដោយសារតែធម្មជាតិចែកចាយនៃបរិស្ថាន Kubernetes ។ ជាពិសេស,

• POSIX គឺជជែក៖ POSIX semantics តម្រូវឱ្យប្រតិបត្តិការនីមួយៗត្រូវបានភ្ជាប់ជាមួយទិន្នន័យមេតា និងឯកសារពិពណ៌នាដែលជួយរក្សាស្ថានភាពនៃប្រតិបត្តិការ។ នេះបណ្តាលឱ្យមានការចំណាយសំខាន់ៗដែលមិនមានតម្លៃពិតប្រាកដ។ Object storage APIs ជាពិសេស S3 API កម្ចាត់តម្រូវការទាំងនេះ ដែលអនុញ្ញាតឱ្យកម្មវិធីដំណើរការ ហើយបន្ទាប់មក "ភ្លេច" អំពីការហៅទូរសព្ទ។ ការឆ្លើយតបរបស់ប្រព័ន្ធផ្ទុកទិន្នន័យបង្ហាញថាតើសកម្មភាពនេះបានជោគជ័យឬអត់។ ប្រសិនបើវាបរាជ័យ កម្មវិធីអាចព្យាយាមម្តងទៀត។
• ការរឹតបន្តឹងបណ្តាញ៖ នៅក្នុងប្រព័ន្ធចែកចាយ វាបង្កប់ន័យថាអាចមានកម្មវិធីជាច្រើនដែលព្យាយាមសរសេរទិន្នន័យទៅកាន់មេឌៀដែលបានភ្ជាប់ដូចគ្នា។ ដូច្នេះមិនត្រឹមតែកម្មវិធីនឹងប្រកួតប្រជែងគ្នាសម្រាប់កម្រិតបញ្ជូនទិន្នន័យ (ដើម្បីបញ្ជូនទិន្នន័យទៅកាន់មេឌៀ) ប៉ុន្តែប្រព័ន្ធផ្ទុកទិន្នន័យខ្លួនឯងនឹងប្រកួតប្រជែងសម្រាប់កម្រិតបញ្ជូននេះដោយការបញ្ជូនទិន្នន័យឆ្លងកាត់ថាសរឹង។ ដោយសារតែភាពច្របូកច្របល់នៃ POSIX ចំនួននៃការហៅតាមបណ្តាញកើនឡើងជាច្រើនដង។ ម៉្យាងវិញទៀត S3 API ផ្តល់នូវភាពខុសគ្នាយ៉ាងច្បាស់រវាងការហៅតាមបណ្តាញរវាងការហៅចេញពីម៉ាស៊ីនភ្ញៀវទៅកាន់ម៉ាស៊ីនមេ និងអ្វីដែលកើតឡើងនៅក្នុងម៉ាស៊ីនមេ។
• សន្តិសុខ៖ គំរូសុវត្ថិភាព POSIX ត្រូវបានរចនាឡើងសម្រាប់ការចូលរួមយ៉ាងសកម្មរបស់មនុស្ស៖ អ្នកគ្រប់គ្រងកំណត់រចនាសម្ព័ន្ធកម្រិតចូលប្រើប្រាស់ជាក់លាក់សម្រាប់អ្នកប្រើប្រាស់ ឬក្រុមនីមួយៗ។ គំរូនេះពិបាកសម្របខ្លួនទៅនឹងពិភពលោកដែលផ្តោតលើពពក។ កម្មវិធីទំនើបអាស្រ័យលើគំរូសុវត្ថិភាពដែលមានមូលដ្ឋានលើ API ដែលសិទ្ធិចូលប្រើត្រូវបានកំណត់ជាសំណុំនៃគោលការណ៍ គណនីសេវាកម្ម លិខិតសម្គាល់បណ្តោះអាសន្ន។ល។ ត្រូវបានបែងចែក។
• ការគ្រប់គ្រងបាន៖ កុងតឺន័រ​ដែល​មាន​រដ្ឋ​មាន​ការ​គ្រប់​គ្រង​ខ្លះ​លើស​ដើម។ យើងកំពុងនិយាយអំពីការធ្វើសមកាលកម្មការចូលប្រើទិន្នន័យស្របគ្នា ដោយធានានូវភាពស៊ីសង្វាក់គ្នានៃទិន្នន័យ ទាំងអស់នេះទាមទារឱ្យមានការពិចារណាយ៉ាងប្រុងប្រយ័ត្នអំពីគំរូនៃការចូលប្រើទិន្នន័យដែលត្រូវប្រើ។ កម្មវិធីបន្ថែមត្រូវតែត្រូវបានដំឡើង ត្រួតពិនិត្យ និងកំណត់រចនាសម្ព័ន្ធ មិនមែននិយាយអំពីកិច្ចខិតខំប្រឹងប្រែងអភិវឌ្ឍន៍បន្ថែមទេ។

ចំណុចប្រទាក់ផ្ទុកទិន្នន័យកុងតឺន័រ

ខណៈពេលដែល Container Storage Interface (CSI) គឺជាជំនួយដ៏ល្អមួយជាមួយនឹងការរីកសាយនៃស្រទាប់បរិមាណ Kubernetes ដោយផ្នែកខាងក្រៅវាទៅឱ្យអ្នកលក់ឧបករណ៍ផ្ទុកភាគីទីបី វាក៏បានរួមចំណែកដោយអចេតនាដល់ការជឿជាក់ថាវិធីសាស្រ្តនៃកុងតឺន័រដែលមានស្ថានភាពគឺជាវិធីសាស្ត្រដែលបានណែនាំសម្រាប់ ការរក្សាទុកទិន្នន័យនៅក្នុង Kubernetes ។

CSI ត្រូវ​បាន​បង្កើត​ឡើង​ជា​ស្តង់ដារ​មួយ​សម្រាប់​ការ​ផ្តល់​នូវ​ប្រព័ន្ធ​ផ្ទុក​ឯកសារ​និង​ប្លុក​តាម​អំពើ​ចិត្ត​ដល់​កម្មវិធី​ចាស់​នៅ​ពេល​ដំណើរការ​លើ Kubernetes។ ហើយដូចដែលអត្ថបទនេះបានបង្ហាញ ស្ថានភាពតែមួយគត់ដែលវិធីសាស្រ្តកុងតឺន័រដែលមានស្ថានភាព (និង CSI នៅក្នុងទម្រង់បច្ចុប្បន្នរបស់វា) មានន័យគឺនៅពេលដែលកម្មវិធីខ្លួនវាគឺជាប្រព័ន្ធកេរ្តិ៍ដំណែលដែលវាមិនអាចបន្ថែមការគាំទ្រសម្រាប់ API ផ្ទុកវត្ថុ .

វាជាការសំខាន់ណាស់ដែលត្រូវយល់ថាការប្រើប្រាស់ CSI នៅក្នុងទម្រង់បច្ចុប្បន្នរបស់វា ពោលគឺការដំឡើងភាគនៅពេលធ្វើការជាមួយកម្មវិធីទំនើប យើងនឹងជួបប្រទះបញ្ហាដូចគ្នាដែលកើតឡើងនៅក្នុងប្រព័ន្ធដែលការផ្ទុកទិន្នន័យត្រូវបានរៀបចំនៅក្នុងរចនាប័ទ្ម POSIX ។

វិធីសាស្រ្តកាន់តែប្រសើរ

ក្នុងករណីនេះ វាជាការសំខាន់ដែលត្រូវយល់ថាកម្មវិធីភាគច្រើនមិនត្រូវបានរចនាឡើងជាពិសេសសម្រាប់ការងារគ្មានរដ្ឋ ឬគ្មានរដ្ឋនោះទេ។ ឥរិយាបថនេះអាស្រ័យលើស្ថាបត្យកម្មប្រព័ន្ធទាំងមូល និងជម្រើសនៃការរចនាជាក់លាក់។ សូមនិយាយបន្តិចអំពីកម្មវិធីដែលមានរដ្ឋ។

ជាគោលការណ៍ ទិន្នន័យកម្មវិធីទាំងអស់អាចត្រូវបានបែងចែកជាប្រភេទធំៗជាច្រើន៖

• ទិន្នន័យកំណត់ហេតុ
• ទិន្នន័យត្រាពេលវេលា
• ទិន្នន័យប្រតិបត្តិការ
• ទិន្នន័យមេតា
• រូបភាពកុងតឺន័រ
• ទិន្នន័យ Blob (វត្ថុគោលពីរធំ)

ប្រភេទទិន្នន័យទាំងអស់នេះត្រូវបានគាំទ្រយ៉ាងល្អនៅលើវេទិកាផ្ទុកទិន្នន័យទំនើប ហើយមានវេទិកាដើមកំណើតពពកជាច្រើនដែលត្រូវបានកែសម្រួលដើម្បីបញ្ជូនទិន្នន័យក្នុងទម្រង់ជាក់លាក់នីមួយៗទាំងនេះ។ ឧទាហរណ៍ ទិន្នន័យប្រតិបត្តិការ និងទិន្នន័យមេតាអាចស្ថិតនៅក្នុងមូលដ្ឋានទិន្នន័យមូលដ្ឋានពពកទំនើបដូចជា CockroachDB, YugaByte ជាដើម។ រូបភាពកុងតឺន័រ ឬទិន្នន័យប្លុកអាចត្រូវបានរក្សាទុកក្នុងបញ្ជីឈ្មោះ docker ដោយផ្អែកលើ MinIO ។ ទិន្នន័យត្រាពេលវេលាអាចត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យស៊េរីពេលវេលាដូចជា InfluxDB ជាដើម។ យើងនឹងមិនលម្អិតអំពីប្រភេទទិន្នន័យនីមួយៗ និងកម្មវិធីរបស់វានៅទីនេះទេ ប៉ុន្តែគំនិតទូទៅគឺដើម្បីជៀសវាងការផ្ទុកទិន្នន័យជាប់លាប់ដែលពឹងផ្អែកលើការភ្ជាប់ថាសមូលដ្ឋាន។

លើសពីនេះទៀត ជារឿយៗវាមានប្រសិទ្ធភាពក្នុងការផ្តល់នូវស្រទាប់ឃ្លាំងសម្ងាត់បណ្តោះអាសន្នដែលបម្រើជាឃ្លាំងផ្ទុកឯកសារបណ្តោះអាសន្នសម្រាប់កម្មវិធី ប៉ុន្តែកម្មវិធីមិនគួរពឹងផ្អែកលើស្រទាប់នេះជាប្រភពនៃការពិតនោះទេ។

ការផ្ទុកកម្មវិធីដែលមានស្ថានភាព

ខណៈពេលដែលក្នុងករណីភាគច្រើនវាមានប្រយោជន៍ក្នុងការរក្សាកម្មវិធីឱ្យគ្មានរដ្ឋ កម្មវិធីទាំងនោះដែលត្រូវបានរចនាឡើងដើម្បីរក្សាទុកទិន្នន័យ - ដូចជាមូលដ្ឋានទិន្នន័យ ឃ្លាំងផ្ទុកវត្ថុ ឃ្លាំងតម្លៃ - ត្រូវតែមានលក្ខណៈរដ្ឋ។ សូមក្រឡេកមើលមូលហេតុដែលកម្មវិធីទាំងនេះត្រូវបានដាក់ឱ្យប្រើប្រាស់នៅលើ Kubernetes ។ សូមលើកយក MinIO ជាឧទាហរណ៍ ប៉ុន្តែគោលការណ៍ស្រដៀងគ្នានេះអនុវត្តចំពោះប្រព័ន្ធផ្ទុកទិន្នន័យដើមកំណើតពពកធំផ្សេងទៀត។

កម្មវិធី Cloud-native ត្រូវបានរចនាឡើងដើម្បីទាញយកអត្ថប្រយោជន៍ពេញលេញពីភាពបត់បែនដែលមាននៅក្នុងកុងតឺន័រ។ នេះមានន័យថាពួកគេមិនធ្វើការសន្មត់អំពីបរិស្ថានដែលពួកគេនឹងត្រូវបានដាក់ពង្រាយ។ ជាឧទាហរណ៍ MinIO ប្រើយន្តការសរសេរកូដលុបខាងក្នុងដើម្បីផ្តល់ឱ្យប្រព័ន្ធនូវភាពធន់គ្រប់គ្រាន់ដើម្បីបន្តដំណើរការទោះបីជាថាសពាក់កណ្តាលបរាជ័យក៏ដោយ។ MinIO ក៏គ្រប់គ្រងភាពត្រឹមត្រូវនៃទិន្នន័យ និងសុវត្ថិភាពដោយប្រើការបំបែកផ្នែកខាងម៉ាស៊ីនមេដែលមានកម្មសិទ្ធិ និងការអ៊ិនគ្រីប។

សម្រាប់កម្មវិធីដែលផ្តោតលើពពកបែបនេះ បរិមាណជាប់លាប់ក្នុងតំបន់ (PVs) គឺងាយស្រួលបំផុតដូចជាការផ្ទុកបម្រុងទុក។ PV ក្នុងស្រុកផ្តល់នូវសមត្ថភាពក្នុងការរក្សាទុកទិន្នន័យឆៅ ខណៈដែលកម្មវិធីដែលកំពុងដំណើរការនៅលើកំពូលនៃ PVs ទាំងនេះដោយឯករាជ្យប្រមូលព័ត៌មានដើម្បីធ្វើមាត្រដ្ឋានទិន្នន័យ និងគ្រប់គ្រងតម្រូវការទិន្នន័យដែលកំពុងកើនឡើង។

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

ចលនាខ្លាំងឆ្ពោះទៅរកការបំបែកទិន្នន័យពីការគណនា

នៅក្នុងអត្ថបទនេះ យើងបាននិយាយអំពីរបៀបដែលកម្មវិធីត្រូវបានតំរង់ទិសដើម្បីដំណើរការដោយមិនរក្សាទុកស្ថានភាព ឬនិយាយម្យ៉ាងទៀត ការរក្សាទុកទិន្នន័យត្រូវបានបំបែកចេញពីកុំព្យូទ័រនៅលើវា។ សរុបសេចក្តីមក សូមក្រឡេកមើលឧទាហរណ៍ជាក់ស្តែងមួយចំនួននៃនិន្នាការនេះ។

Sparkដែលជាវេទិកាវិភាគទិន្នន័យដ៏លេចធ្លោមួយ មានលក្ខណៈជាប្រពៃណី និងត្រូវបានដាក់ឱ្យប្រើប្រាស់នៅលើ HDFS ។ ទោះជាយ៉ាងណាក៏ដោយ នៅពេលដែល Spark ផ្លាស់ទីទៅក្នុងពិភពពពកកណ្តាល វេទិកានេះត្រូវបានប្រើប្រាស់កាន់តែខ្លាំងឡើងដោយគ្មានរដ្ឋដោយប្រើ `s3a` ។ Spark ប្រើ s3a ដើម្បីផ្ទេរស្ថានភាពទៅប្រព័ន្ធផ្សេងទៀត ខណៈពេលដែល Spark containers ខ្លួនឯងដំណើរការទាំងស្រុងដោយគ្មានរដ្ឋ។ អ្នកលេងសហគ្រាសធំៗផ្សេងទៀតនៅក្នុងវិស័យវិភាគទិន្នន័យធំ ជាពិសេស។ បញ្ឈរ, តេរ៉ាតាតា, បៃតងផ្លុំ ពួកគេក៏កំពុងផ្លាស់ប្តូរទៅធ្វើការជាមួយការបំបែកនៃការផ្ទុកទិន្នន័យ និងការគណនាលើពួកគេ។

គំរូស្រដៀងគ្នានេះក៏អាចត្រូវបានគេមើលឃើញនៅលើវេទិកាវិភាគធំផ្សេងទៀត រួមទាំង Presto, Tensorflow ទៅ R, Jupyter ។ តាមរយៈការបញ្ជូនស្ថានភាពទៅប្រព័ន្ធផ្ទុកពពកពីចម្ងាយ វាកាន់តែងាយស្រួលគ្រប់គ្រង និងពង្រីកកម្មវិធីរបស់អ្នក។ លើសពីនេះទៀតវាជួយសម្រួលដល់ការចល័តនៃកម្មវិធីទៅកាន់បរិយាកាសផ្សេងៗ។

ប្រភព: www.habr.com