🥇Storage in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

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

និយាយឱ្យត្រង់ទៅ ខ្ញុំបានបោះបង់ហើយបោះបង់ Kubernetes (យ៉ាងហោចណាស់សម្រាប់ពេលនេះ)។ ខ្ញុំនឹងប្រើ ហឺរ៉ូគូ. ហេតុអ្វី? ព្រោះតែស្តុក! តើអ្នកណានឹងគិតថាខ្ញុំនឹងបង្កើនទំហំផ្ទុកច្រើនជាង Kubernetes ខ្លួនឯង។ ខ្ញុំប្រើ ពពក Hetznerព្រោះវាមានតម្លៃថោក ហើយការអនុវត្តគឺល្អ ហើយតាំងពីដំបូងមក ខ្ញុំបានដាក់ពង្រាយចង្កោមដោយប្រើ កសិករ. ខ្ញុំមិនបានសាកល្បងគ្រប់គ្រងសេវាកម្ម Kubernetes ពី Google/Amazon/Microsoft/DigitalOcean ជាដើម ពីព្រោះខ្ញុំចង់រៀនអ្វីៗគ្រប់យ៉ាងដោយខ្លួនឯង។ ខ្ញុំក៏សន្សំសំចៃដែរ។

ដូច្នេះហើយ ខ្ញុំបានចំណាយពេលច្រើនក្នុងការព្យាយាមសម្រេចចិត្តថាតើទំហំផ្ទុកមួយណាដែលត្រូវជ្រើសរើស នៅពេលដែលខ្ញុំកំពុងវាយតម្លៃជង់ Kubernetes ដែលអាចធ្វើទៅបាន។ ខ្ញុំចូលចិត្តដំណោះស្រាយប្រភពបើកចំហ មិនត្រឹមតែដោយសារតែតម្លៃប៉ុណ្ណោះទេ ប៉ុន្តែខ្ញុំបានពិនិត្យមើលជម្រើសបង់ប្រាក់មួយចំនួនដោយមានការចង់ដឹងចង់ឃើញ ដោយសារតែពួកគេមានកំណែឥតគិតថ្លៃដែលមានដែនកំណត់។ ខ្ញុំបានកត់ត្រាលេខមួយចំនួនពីការធ្វើតេស្តថ្មីៗ នៅពេលខ្ញុំប្រៀបធៀបជម្រើសផ្សេងៗ ហើយពួកគេអាចចាប់អារម្មណ៍ចំពោះអ្នកដែលរៀនអំពីការផ្ទុក Kubernetes។ ទោះបីជាខ្ញុំផ្ទាល់បាននិយាយលាទៅកាន់ Kubernetes នៅពេលនេះក៏ដោយ។ ខ្ញុំក៏ចង់លើកឡើងដែរ។ កម្មវិធីបញ្ជា CSIដែលអាចផ្តល់បរិមាណ Hetzner Cloud ដោយផ្ទាល់ ប៉ុន្តែខ្ញុំមិនទាន់បានសាកល្បងវានៅឡើយទេ។ ខ្ញុំបានរកមើលកន្លែងផ្ទុកដែលកំណត់ដោយកម្មវិធីពពក ព្រោះខ្ញុំត្រូវការការចម្លង និងសមត្ថភាពក្នុងការម៉ោនភាគបន្តបានយ៉ាងលឿននៅលើថ្នាំងណាមួយ ជាពិសេសក្នុងករណីមានការបរាជ័យថ្នាំង និងស្ថានភាពស្រដៀងគ្នាផ្សេងទៀត។ ដំណោះស្រាយមួយចំនួនផ្តល់នូវរូបថតភ្លាមៗ និងការបម្រុងទុកក្រៅបណ្តាញ ដែលងាយស្រួល។

ខ្ញុំបានសាកល្បងដំណោះស្រាយការផ្ទុក 6-7៖

OpenEBS

ដូចដែលខ្ញុំបាននិយាយរួចមកហើយ នៅក្នុងការប្រកាសមុន។ដោយបានសាកល្បងជម្រើសភាគច្រើនពីបញ្ជី ខ្ញុំបានតាំងទីលំនៅដំបូងនៅលើ OpenEBS ។ OpenEBS មានភាពងាយស្រួលក្នុងការដំឡើង និងប្រើប្រាស់ ប៉ុន្តែនិយាយឱ្យត្រង់ទៅ បន្ទាប់ពីបានសាកល្បងជាមួយនឹងទិន្នន័យពិតនៅក្រោមការផ្ទុក ខ្ញុំមានការខកចិត្តជាមួយនឹងដំណើរការរបស់វា។ នេះគឺជាប្រភពបើកចំហ ហើយអ្នកអភិវឌ្ឍន៍គឺដោយខ្លួនឯង។ ឆានែល Slack តែងតែមានប្រយោជន៍នៅពេលខ្ញុំត្រូវការជំនួយ។ ជាអកុសល វាមានដំណើរការមិនល្អខ្លាំងបើប្រៀបធៀបទៅនឹងជម្រើសផ្សេងទៀត ដូច្នេះការធ្វើតេស្តត្រូវតែដំណើរការឡើងវិញ។ បច្ចុប្បន្ន OpenEBS មានម៉ាស៊ីនផ្ទុកទិន្នន័យចំនួន 3 ប៉ុន្តែខ្ញុំកំពុងប្រកាសលទ្ធផលគោលសម្រាប់ cStor ។ ខ្ញុំមិនទាន់មានលេខសម្រាប់ Jiva និង LocalPV នៅឡើយទេ។

សរុបមក Jiva គឺលឿនជាងបន្តិច ហើយ LocalPV ជាទូទៅមានល្បឿនលឿន មិនអាក្រក់ជាងឌីសគោលដោយផ្ទាល់នោះទេ។ បញ្ហាជាមួយ LocalPV គឺថាកម្រិតសំឡេងអាចចូលបានតែនៅលើថ្នាំងដែលវាត្រូវបានរៀបចំ ហើយមិនមានការចម្លងអ្វីទាំងអស់។ ខ្ញុំមានបញ្ហាមួយចំនួនក្នុងការស្ដារការបម្រុងទុកតាមរយៈ ទូកសំពៅ នៅលើចង្កោមថ្មី ដោយសារឈ្មោះថ្នាំងខុសគ្នា។ ប្រសិនបើយើងនិយាយអំពីការបម្រុងទុក cStor មាន កម្មវិធីជំនួយសម្រាប់ Veleroដែលអ្នកអាចធ្វើការបម្រុងទុកក្រៅបណ្តាញនៃរូបថតក្នុងពេលណាមួយ ដែលងាយស្រួលជាងការបម្រុងទុកកម្រិតឯកសារជាមួយ Velero-Restic ។ ខ្ញុំបានសរសេរ ស្គ្រីបជាច្រើន។ដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការគ្រប់គ្រងការបម្រុងទុក និងការស្ដារឡើងវិញដោយប្រើកម្មវិធីជំនួយនេះ។ សរុបមក ខ្ញុំពិតជាចូលចិត្ត OpenEBS ប៉ុន្តែការសម្តែងរបស់វា...

រាក់

Rook ក៏ជាប្រភពបើកចំហផងដែរ ហើយខុសពីជម្រើសដែលនៅសល់ក្នុងបញ្ជី ដែលវាជាឧបករណ៍ផ្ទុកទិន្នន័យដែលបំពេញភារកិច្ចគ្រប់គ្រងការផ្ទុកដ៏ស្មុគស្មាញជាមួយនឹងកម្មវិធីខាងក្រោយផ្សេងៗគ្នា ឧ. សេហ្វ, EdgeFS និងផ្សេងៗទៀត ដែលជួយសម្រួលការងារយ៉ាងខ្លាំង។ ខ្ញុំមានបញ្ហាជាមួយ EfgeFS នៅពេលដែលខ្ញុំបានសាកល្បងវាកាលពីប៉ុន្មានខែមុន ដូច្នេះខ្ញុំបានសាកល្បងជាចម្បងជាមួយ Ceph ។ Ceph មិនត្រឹមតែផ្តល់នូវការផ្ទុកប្លុកប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងការផ្ទុកវត្ថុដែលត្រូវគ្នាជាមួយ S3/Swift និងប្រព័ន្ធឯកសារដែលបានចែកចាយផងដែរ។ អ្វីដែលខ្ញុំចូលចិត្តអំពី Ceph គឺសមត្ថភាពក្នុងការចែកចាយទិន្នន័យកម្រិតសំឡេងនៅទូទាំងថាសច្រើន ដូច្នេះបរិមាណអាចប្រើទំហំថាសបានច្រើនជាងដែលអាចសមនឹងថាសតែមួយ។ វាមានផាសុកភាព។ លក្ខណៈពិសេសមួយទៀតគឺនៅពេលដែលអ្នកបន្ថែមថាសទៅក្នុងចង្កោម វានឹងចែកចាយទិន្នន័យឡើងវិញដោយស្វ័យប្រវត្តិនៅទូទាំងថាសទាំងអស់។

Ceph មានរូបថត ប៉ុន្តែតាមខ្ញុំដឹង ពួកវាមិនអាចប្រើដោយផ្ទាល់នៅក្នុង Rook/Kubernetes បានទេ។ ពិតហើយ ខ្ញុំមិនបានចូលជ្រៅក្នុងរឿងនេះទេ។ ប៉ុន្តែមិនមានការបម្រុងទុកក្រៅបណ្តាញទេ ដូច្នេះអ្នកនឹងត្រូវប្រើអ្វីមួយជាមួយ Velero/Restic ប៉ុន្តែមានតែការបម្រុងទុកកម្រិតឯកសារប៉ុណ្ណោះ មិនមែនការថតចំលងតាមពេលវេលានោះទេ។ អ្វីដែលខ្ញុំពិតជាចូលចិត្តអំពី Rook គឺភាពងាយស្រួលក្នុងការធ្វើការជាមួយ Ceph ពោលគឺវាលាក់អ្វីដែលស្មុគស្មាញស្ទើរតែទាំងអស់ ហើយផ្តល់នូវឧបករណ៍ដើម្បីនិយាយជាមួយ Ceph ដោយផ្ទាល់សម្រាប់ការដោះស្រាយបញ្ហា។ ជាអកុសល ក្នុងអំឡុងពេលធ្វើតេស្តភាពតានតឹងនៃបរិមាណ Ceph ខ្ញុំបានបន្តមានបញ្ហាជាមួយ បញ្ហានេះដែលធ្វើឱ្យ Ceph មិនស្ថិតស្ថេរ។ វាមិនទាន់ច្បាស់ថាតើនេះជាកំហុសនៅក្នុង Ceph ខ្លួនឯង ឬជាបញ្ហានៅក្នុងវិធីដែល Rook គ្រប់គ្រង Ceph ។ ខ្ញុំបានគិតគូរជាមួយការកំណត់អង្គចងចាំ ហើយវាកាន់តែប្រសើរ ប៉ុន្តែបញ្ហាមិនត្រូវបានដោះស្រាយទាំងស្រុងនោះទេ។ Ceph មានដំណើរការសមរម្យ ដូចដែលអ្នកអាចមើលឃើញនៅក្នុងតារាងខាងក្រោម។ វាក៏មានផ្ទាំងគ្រប់គ្រងដ៏ល្អផងដែរ។

Rancher Longhorn

ខ្ញុំពិតជាចូលចិត្ត Longhorn ។ នៅក្នុងគំនិតរបស់ខ្ញុំ នេះគឺជាដំណោះស្រាយដ៏ជោគជ័យមួយ។ ពិត អ្នកអភិវឌ្ឍន៍ខ្លួនឯង (Rancher Labs) សារភាពថាវាមិនទាន់ស័ក្តិសមសម្រាប់បរិយាកាសការងារទេ ហើយនេះបង្ហាញ។ វាជាប្រភពបើកចំហ និងមានដំណើរការសមរម្យ (ទោះបីជាពួកគេមិនទាន់បានបង្កើនប្រសិទ្ធភាពវានៅឡើយ) ប៉ុន្តែបរិមាណត្រូវការពេលយូរដើម្បីភ្ជាប់ទៅផត ហើយក្នុងករណីដ៏អាក្រក់បំផុតវាត្រូវចំណាយពេល 15-16 នាទី ជាពិសេសបន្ទាប់ពីស្ដារការបម្រុងទុកដ៏ធំ ឬ ការធ្វើឱ្យប្រសើរឡើងនូវបន្ទុកការងារ។ វាមានរូបថត និងការបម្រុងទុកក្រៅបណ្តាញនៃរូបថតទាំងនេះ ប៉ុន្តែពួកវាអនុវត្តចំពោះបរិមាណប៉ុណ្ណោះ ដូច្នេះអ្នកនឹងនៅតែត្រូវការអ្វីមួយដូចជា Velero ដើម្បីបម្រុងទុកធនធានផ្សេងទៀត។ ការបម្រុងទុក និងការស្ដារឡើងវិញគឺអាចទុកចិត្តបាន ប៉ុន្តែមានភាពយឺតយ៉ាវមិនសមរម្យ។ ធ្ងន់ធ្ងរ គ្រាន់តែយឺតមិនគួរឱ្យជឿ។ ការប្រើប្រាស់ស៊ីភីយូ និងការផ្ទុកប្រព័ន្ធច្រើនតែកើនឡើងនៅពេលធ្វើការជាមួយចំនួនមធ្យមនៃទិន្នន័យនៅក្នុង Longhorn ។ មានផ្ទាំងគ្រប់គ្រងងាយស្រួលសម្រាប់គ្រប់គ្រង Longhorn ។ ខ្ញុំបាននិយាយរួចហើយថាខ្ញុំចូលចិត្ត Longhorn ប៉ុន្តែវាត្រូវការការងារមួយចំនួន។

StorageOS

StorageOS គឺជាផលិតផលបង់ប្រាក់ដំបូងគេក្នុងបញ្ជី។ វាមានកំណែអ្នកអភិវឌ្ឍន៍ដែលមានទំហំផ្ទុកដែលបានគ្រប់គ្រងមានកំណត់ 500GB ប៉ុន្តែខ្ញុំគិតថាមិនមានដែនកំណត់លើចំនួនថ្នាំងនោះទេ។ នាយកដ្ឋានលក់បានប្រាប់ខ្ញុំថាតម្លៃចាប់ផ្តើមពី $125 ក្នុងមួយខែសម្រាប់ 1 TB ប្រសិនបើខ្ញុំចាំបានត្រឹមត្រូវ។ មានផ្ទៃតាប្លូជាមូលដ្ឋាន និង CLI ងាយស្រួល ប៉ុន្តែអ្វីដែលចម្លែកកំពុងកើតឡើងជាមួយនឹងការអនុវត្ត៖ នៅក្នុងស្តង់ដារមួយចំនួនវាសមរម្យណាស់ ប៉ុន្តែនៅក្នុងការធ្វើតេស្តកម្រិតសំឡេង ខ្ញុំមិនចូលចិត្តល្បឿនទាល់តែសោះ។ ជាទូទៅខ្ញុំមិនដឹងថាត្រូវនិយាយអ្វីទេ។ ដូច្នេះខ្ញុំពិតជាមិនយល់ច្រើនទេ។ មិនមានការបម្រុងទុកក្រៅបណ្តាញនៅទីនេះទេ ហើយអ្នកក៏នឹងត្រូវប្រើ Velero ជាមួយ Restic ដើម្បីបម្រុងទុកបរិមាណ។ វាចម្លែកព្រោះផលិតផលត្រូវបានបង់។ ហើយអ្នកអភិវឌ្ឍន៍មិនមានបំណងចង់ទំនាក់ទំនងលើ Slack ទេ។

ការប្រកួតជម្រុះវិល

ខ្ញុំបានរៀនអំពី Robin នៅលើ Reddit ពីនាយកបច្ចេកទេសរបស់ពួកគេ។ ខ្ញុំមិនដែលឮគាត់ពីមុនមកទេ។ ប្រហែលជាដោយសារតែខ្ញុំកំពុងស្វែងរកដំណោះស្រាយដោយឥតគិតថ្លៃ ប៉ុន្តែ Robin ត្រូវបានបង់។ ពួកវាមានកំណែឥតគិតថ្លៃដែលមានទំហំផ្ទុក 10TB និងថ្នាំងបី។ សរុបមក ផលិតផលនេះពិតជាសមរម្យ និងមានមុខងារល្អៗ។ មាន CLI ដ៏អស្ចារ្យមួយ ប៉ុន្តែអ្វីដែលត្រជាក់បំផុតនោះគឺថាអ្នកអាចថតរូប និងបម្រុងទុកកម្មវិធីទាំងមូល (នៅក្នុងឧបករណ៍ជ្រើសរើសធនធាននេះត្រូវបានគេហៅថា Helm releases ឬ "flex apps") រួមទាំងបរិមាណ និងធនធានផ្សេងទៀត ដូច្នេះអ្នកអាចធ្វើបានដោយគ្មាន Velero ។ ហើយអ្វីគ្រប់យ៉ាងនឹងអស្ចារ្យប្រសិនបើមិនមែនសម្រាប់ព័ត៌មានលម្អិតតូចមួយទេ: ប្រសិនបើអ្នកស្តារ (ឬ "នាំចូល" ដូចដែលវាត្រូវបានគេហៅថា Robin) កម្មវិធីនៅលើចង្កោមថ្មី - ឧទាហរណ៍ក្នុងករណីសង្គ្រោះពីគ្រោះមហន្តរាយ - ការស្ដារឡើងវិញ។ ជាការពិតណាស់ ដំណើរការ ប៉ុន្តែបន្តការបម្រុងទុកកម្មវិធីដែលវាត្រូវបានហាមឃាត់។ វាមិនអាចទៅរួចទេក្នុងការចេញផ្សាយនេះ ដូចដែលអ្នកអភិវឌ្ឍន៍បានបញ្ជាក់។ នេះគឺដើម្បីដាក់វាឱ្យស្រាល ចម្លែក ជាពិសេសការពិចារណាពីគុណសម្បត្តិផ្សេងទៀត (ឧទាហរណ៍ ការបម្រុងទុក និងការស្ដារឡើងវិញលឿនមិនគួរឱ្យជឿ)។ អ្នកអភិវឌ្ឍន៍សន្យាថានឹងជួសជុលអ្វីៗគ្រប់យ៉ាងដោយការចេញផ្សាយបន្ទាប់។ ការអនុវត្តជាទូទៅគឺល្អ ប៉ុន្តែខ្ញុំបានកត់សម្គាល់នូវភាពចម្លែកមួយ៖ ប្រសិនបើខ្ញុំដំណើរការស្តង់ដារដោយផ្ទាល់លើកម្រិតសំឡេងដែលភ្ជាប់ជាមួយម៉ាស៊ីន នោះល្បឿនអានគឺលឿនជាងការរត់កម្រិតសំឡេងដូចគ្នាពីក្នុងផត។ លទ្ធផលផ្សេងទៀតទាំងអស់គឺដូចគ្នាបេះបិទ ប៉ុន្តែតាមទ្រឹស្តីមិនគួរមានភាពខុសគ្នានោះទេ។ ទោះបីជាពួកគេកំពុងធ្វើការលើវាក៏ដោយ ខ្ញុំមានការខកចិត្តចំពោះបញ្ហាជាមួយនឹងការស្ដារ និងការបម្រុងទុក - ខ្ញុំគិតថាទីបំផុតខ្ញុំបានរកឃើញដំណោះស្រាយសមស្របមួយ ហើយខ្ញុំថែមទាំងមានឆន្ទៈក្នុងការបង់ប្រាក់សម្រាប់វានៅពេលដែលខ្ញុំត្រូវការកន្លែងផ្ទុកបន្ថែម ឬម៉ាស៊ីនមេច្រើន។

portworx

ខ្ញុំមិនមានអ្វីត្រូវនិយាយច្រើននៅទីនេះទេ។ នេះជាផលិតផលដែលបានបង់ប្រាក់ស្មើគ្នាត្រជាក់និងថ្លៃ។ ការសម្តែងគឺអស្ចារ្យណាស់។ នេះគឺជាសូចនាករដ៏ល្អបំផុតរហូតមកដល់ពេលនេះ។ Slack បានប្រាប់ខ្ញុំថាតម្លៃចាប់ផ្តើមពី $205 ក្នុងមួយខែក្នុងមួយ node ដូចដែលបានរាយក្នុង GKE Marketplace របស់ Google ។ ខ្ញុំមិនដឹងថាតើវានឹងថោកជាងនេះទេប្រសិនបើអ្នកទិញផ្ទាល់។ ខ្ញុំមិនអាចមានលទ្ធភាពបែបនេះទេ ដូច្នេះហើយខ្ញុំមានការខកចិត្តយ៉ាងខ្លាំងដែលអាជ្ញាប័ណ្ណអ្នកអភិវឌ្ឍន៍ (រហូតដល់ 1 TB និង 3 nodes) ពិតជាគ្មានប្រយោជន៍ជាមួយ Kubernetes លុះត្រាតែអ្នកពេញចិត្តនឹងការផ្តល់ឋិតិវន្ត។ ខ្ញុំសង្ឃឹមថាអាជ្ញាប័ណ្ណកម្រិតសំឡេងនឹងទម្លាក់ចំណាត់ថ្នាក់ដោយស្វ័យប្រវត្តិទៅអ្នកអភិវឌ្ឍន៍នៅចុងបញ្ចប់នៃរយៈពេលសាកល្បង ប៉ុន្តែវាមិនបានកើតឡើងទេ។ អាជ្ញាប័ណ្ណអ្នកអភិវឌ្ឍន៍អាចប្រើដោយផ្ទាល់ជាមួយ Docker ប៉ុណ្ណោះ ហើយការកំណត់រចនាសម្ព័ន្ធនៅក្នុង Kubernetes គឺមានភាពស្ទាក់ស្ទើរ និងមានកម្រិត។ ជាការពិតណាស់ ខ្ញុំចូលចិត្តប្រភពបើកចំហ ប៉ុន្តែប្រសិនបើខ្ញុំមានលុយ ខ្ញុំប្រាកដជាជ្រើសរើស Portworx។ រហូតមកដល់ពេលនេះ ដំណើរការរបស់វាមិនប្រៀបធៀបទៅនឹងជម្រើសផ្សេងទៀតទេ។

លីនស្ទ័រ

ខ្ញុំបានបន្ថែមផ្នែកនេះបន្ទាប់ពីការបោះពុម្ពផ្សាយសារបង្ហោះ នៅពេលអ្នកអានម្នាក់ស្នើឱ្យសាកល្បង Linstor ។ ខ្ញុំបានសាកល្បងវាហើយខ្ញុំចូលចិត្តវា! ប៉ុន្តែយើងនៅតែត្រូវជីកជ្រៅជាងនេះ។ ឥឡូវនេះខ្ញុំអាចនិយាយបានថាការសម្តែងមិនអាក្រក់ទេ (ខ្ញុំបានបន្ថែមលទ្ធផលគោលខាងក្រោម)។ សំខាន់ខ្ញុំទទួលបានការអនុវត្តដូចគ្នានឹងថាសផ្ទាល់ដោយមិនមានការចំណាយលើសដើមឡើយ។ (កុំសួរថាហេតុអ្វីបានជា Portworx មានលេខល្អជាង drive benchmark ដោយផ្ទាល់។ ខ្ញុំមិនដឹងទេ។ ខ្ញុំទាយ។) ដូច្នេះ Linstor ហាក់ដូចជាមានប្រសិទ្ធភាពខ្លាំងណាស់រហូតមកដល់ពេលនេះ។ វាមិនមែនជាការលំបាកក្នុងការដំឡើងនោះទេ ប៉ុន្តែវាមិនងាយស្រួលដូចជម្រើសផ្សេងទៀតនោះទេ។ ដំបូងខ្ញុំត្រូវដំឡើង Linstor (ម៉ូឌុលខឺណែល និងឧបករណ៍/សេវាកម្ម) ហើយកំណត់រចនាសម្ព័ន្ធ LVM សម្រាប់ការផ្គត់ផ្គង់ស្តើង និងជំនួយការថតរូបនៅខាងក្រៅ Kubernetes ដោយផ្ទាល់នៅលើម៉ាស៊ីន ហើយបន្ទាប់មកបង្កើតធនធានដែលត្រូវការដើម្បីប្រើការផ្ទុកពី Kubernetes ។ ខ្ញុំមិនចូលចិត្តដែលវាមិនដំណើរការលើ CentOS ហើយខ្ញុំត្រូវប្រើ Ubuntu ។ ជាការពិតណាស់មិនគួរឱ្យភ័យខ្លាចទេប៉ុន្តែគួរឱ្យរំខានបន្តិចព្រោះឯកសារ (ដែលល្អដោយវិធីនេះ) និយាយអំពីកញ្ចប់ជាច្រើនដែលមិនអាចរកឃើញនៅក្នុងឃ្លាំង Epel ដែលបានបញ្ជាក់។ Linstor មានរូបថត ប៉ុន្តែមិនមែនជាការបម្រុងទុកក្រៅបណ្តាញទេ ដូច្នេះនៅទីនេះម្តងទៀត ខ្ញុំត្រូវប្រើ Velero ជាមួយ Restic ដើម្បីបម្រុងទុកបរិមាណ។ ខ្ញុំចូលចិត្តការថតរូបជាជាងការបម្រុងទុកកម្រិតឯកសារ ប៉ុន្តែវាអាចត្រូវបានអត់ឱនប្រសិនបើដំណោះស្រាយមានប្រសិទ្ធភាព និងអាចទុកចិត្តបាន។ Linstor គឺជាប្រភពបើកចំហប៉ុន្តែមានការគាំទ្រដែលបានបង់។ ប្រសិនបើខ្ញុំយល់បានត្រឹមត្រូវ វាអាចប្រើបានដោយគ្មានការរឹតបន្តឹង ទោះបីជាអ្នកមិនមានកិច្ចសន្យាគាំទ្រក៏ដោយ ប៉ុន្តែនេះត្រូវតែបញ្ជាក់ឱ្យច្បាស់លាស់។ ខ្ញុំមិនដឹងថាតើ Linstor ដែលត្រូវបានសាកល្បងសម្រាប់ Kubernetes យ៉ាងណានោះទេ ប៉ុន្តែស្រទាប់ផ្ទុកខ្លួនវាគឺនៅខាងក្រៅ Kubernetes ហើយជាក់ស្តែង ដំណោះស្រាយមិនបានបង្ហាញកាលពីម្សិលមិញទេ ដូច្នេះវាប្រហែលជាត្រូវបានសាកល្បងរួចហើយនៅក្នុងលក្ខខណ្ឌជាក់ស្តែង។ តើមានដំណោះស្រាយនៅទីនេះទេដែលនឹងធ្វើឱ្យខ្ញុំផ្លាស់ប្តូរចិត្ត ហើយត្រលប់ទៅ Kubernetes វិញ? ខ្ញុំមិនដឹងទេ។ យើងនៅតែត្រូវជីកជ្រៅ និងសិក្សាការចម្លង។ សូមមើល។ ប៉ុន្តែចំណាប់អារម្មណ៍ដំបូងគឺល្អ។ ខ្ញុំពិតជាចង់ប្រើចង្កោម Kubernetes ផ្ទាល់ខ្លួនរបស់ខ្ញុំជំនួសឱ្យ Heroku ដើម្បីមានសេរីភាពកាន់តែច្រើន និងរៀនអ្វីថ្មីៗ។ ដោយសារ Linstor មិនងាយស្រួលដំឡើងដូចអ្នកដទៃ ខ្ញុំនឹងសរសេរប្រកាសអំពីវាក្នុងពេលឆាប់ៗនេះ។

គោល

ជាអកុសល ខ្ញុំមិនបានរក្សាទុកកំណត់ត្រាជាច្រើនអំពីការប្រៀបធៀបទេ ព្រោះខ្ញុំមិនបានគិតថាខ្ញុំនឹងសរសេរអំពីវាទេ។ ខ្ញុំមានតែលទ្ធផលពី fio benchmarks ជាមូលដ្ឋាន និងសម្រាប់តែក្រុមថ្នាំងតែមួយប៉ុណ្ណោះ ដូច្នេះខ្ញុំមិនទាន់មានលេខសម្រាប់ការកំណត់រចនាសម្ព័ន្ធដែលបានចម្លងនៅឡើយទេ។ ប៉ុន្តែពីលទ្ធផលទាំងនេះ អ្នកអាចទទួលបានគំនិតរដុបនៃអ្វីដែលត្រូវរំពឹងពីជម្រើសនីមួយៗ ពីព្រោះខ្ញុំបានប្រៀបធៀបពួកវានៅលើម៉ាស៊ីនមេពពកដូចគ្នា 4 ស្នូល RAM 16 GB ជាមួយនឹងថាស 100 GB បន្ថែមសម្រាប់បរិមាណដែលបានសាកល្បង។ ខ្ញុំបានដំណើរការស្តង់ដារបីដងសម្រាប់ដំណោះស្រាយនីមួយៗ ហើយបានគណនាលទ្ធផលជាមធ្យម បូកខ្ញុំកំណត់ការកំណត់ម៉ាស៊ីនមេឡើងវិញសម្រាប់ផលិតផលនីមួយៗ។ នេះជារឿងមិនពិតទាំងស្រុង គ្រាន់តែផ្ដល់ឱ្យអ្នកនូវគំនិតទូទៅ។ នៅក្នុងការធ្វើតេស្តផ្សេងទៀត ខ្ញុំបានចម្លងរូបថត និងវីដេអូទំហំ 38 GB ពីកម្រិតសំឡេង ដើម្បីសាកល្បងការអាន និងការសរសេរ ប៉ុន្តែ alas ខ្ញុំមិនបានរក្សាទុកលេខនោះទេ។ និយាយឱ្យខ្លី៖ Portworkx គឺលឿនជាង។

សម្រាប់ការវាស់វែងកម្រិតសំឡេង ខ្ញុំបានប្រើ manifest នេះ៖

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

ដំបូងខ្ញុំបានបង្កើតកម្រិតសំឡេងជាមួយថ្នាក់ផ្ទុកដែលសមរម្យ ហើយបន្ទាប់មកបានដំណើរការការងារជាមួយ fio នៅពីក្រោយឆាក។ ខ្ញុំបានយក 1 GB ដើម្បីប៉ាន់ស្មានដំណើរការ ហើយមិនរង់ចាំយូរពេកទេ។ នេះជាលទ្ធផល៖

ខ្ញុំបានរំលេចតម្លៃល្អបំផុតសម្រាប់ម៉ែត្រនីមួយៗជាពណ៌បៃតង និងអាក្រក់បំផុតជាពណ៌ក្រហម។

សេចក្តីសន្និដ្ឋាន

ដូចដែលអ្នកអាចឃើញក្នុងករណីភាគច្រើន Portworx ដំណើរការបានល្អជាងអ្នកដទៃ។ ប៉ុន្តែសម្រាប់ខ្ញុំវាថ្លៃណាស់។ ខ្ញុំមិនដឹងថា Robin មានតម្លៃប៉ុន្មានទេ ប៉ុន្តែពួកគេមានកំណែឥតគិតថ្លៃដ៏អស្ចារ្យ ដូច្នេះប្រសិនបើអ្នកចង់បានផលិតផលដែលបង់ប្រាក់ អ្នកអាចសាកល្បងវា (សង្ឃឹមថាពួកគេដោះស្រាយបញ្ហាជាមួយនឹងការស្តារ និងបម្រុងទុកក្នុងពេលឆាប់ៗនេះ)។ ក្នុងចំណោមកម្មវិធីឥតគិតថ្លៃទាំងបី ខ្ញុំមានបញ្ហាតិចបំផុតជាមួយ OpenEBS ប៉ុន្តែដំណើរការរបស់វាមានកម្រិតទាប។ វាជាការអាណិតដែលខ្ញុំមិនបានរក្សាទុកលទ្ធផលបន្ថែមទៀត ប៉ុន្តែខ្ញុំសង្ឃឹមថាលេខ និងមតិយោបល់របស់ខ្ញុំនឹងជួយអ្នក។

ប្រភព: www.habr.com

ការផ្ទុកនៅក្នុង Kubernetes៖ OpenEBS ទល់នឹង Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor