ដំណោះស្រាយ Hyperconverged AERODISK vAIR ។ មូលដ្ឋានគឺប្រព័ន្ធឯកសារ ARDFS

សួស្តីអ្នកអាន Habr ។ ជាមួយនឹងអត្ថបទនេះ យើងបើកស៊េរីដែលនឹងនិយាយអំពីប្រព័ន្ធ hyperconverged AERODISK vAIR ដែលយើងបានបង្កើត។ ដំបូងឡើយ យើងចង់ប្រាប់អ្វីៗគ្រប់យ៉ាងនៅក្នុងអត្ថបទទីមួយ ប៉ុន្តែប្រព័ន្ធនេះគឺស្មុគស្មាញណាស់ ដូច្នេះយើងនឹងស៊ីដំរីជាផ្នែកៗ។

ចូរចាប់ផ្តើមរឿងជាមួយនឹងប្រវត្តិនៃការបង្កើតប្រព័ន្ធ ស្វែងយល់ពីប្រព័ន្ធឯកសារ ARDFS ដែលជាមូលដ្ឋាននៃ vAIR ហើយក៏និយាយបន្តិចអំពីទីតាំងនៃដំណោះស្រាយនេះនៅលើទីផ្សាររុស្ស៊ី។

នៅក្នុងអត្ថបទនាពេលខាងមុខ យើងនឹងនិយាយលម្អិតបន្ថែមទៀតអំពីធាតុផ្សំស្ថាបត្យកម្មផ្សេងៗគ្នា (ចង្កោម អ្នកត្រួតពិនិត្យខ្ពស់ ការផ្ទុកតុល្យភាព ប្រព័ន្ធត្រួតពិនិត្យ។ ទំហំ។ យើងក៏នឹងលះបង់អត្ថបទដាច់ដោយឡែកមួយទៅកំណែសហគមន៍នៃ vAIR ផងដែរ។

តើ Aerodisk ជារឿងអំពីប្រព័ន្ធផ្ទុកទិន្នន័យមែនទេ? ឬហេតុអ្វីបានជាយើងចាប់ផ្តើមធ្វើ hyperconvergence នៅកន្លែងដំបូង?

ដំបូងឡើយ គំនិតបង្កើត hyperconvergence ផ្ទាល់របស់យើងបានមកដល់កន្លែងណាមួយប្រហែលឆ្នាំ 2010។ នៅពេលនោះ មិនមានទាំង Aerodisk ឬដំណោះស្រាយស្រដៀងគ្នា (ប្រព័ន្ធ hyperconverged ប្រអប់ពាណិជ្ជកម្ម) នៅលើទីផ្សារ។ ភារកិច្ចរបស់យើងមានដូចខាងក្រោម៖ ពីសំណុំនៃម៉ាស៊ីនមេដែលមានថាសមូលដ្ឋានដែលរួបរួមដោយការភ្ជាប់អន្តរកម្មតាមរយៈពិធីការអ៊ីសឺរណិត វាចាំបាច់ក្នុងការបង្កើតការផ្ទុកបន្ថែម និងបើកដំណើរការម៉ាស៊ីននិម្មិត និងបណ្តាញសូហ្វវែរនៅទីនោះ។ ទាំងអស់នេះត្រូវតែអនុវត្តដោយគ្មានប្រព័ន្ធផ្ទុកទិន្នន័យ (ដោយសារតែមិនមានលុយសម្រាប់ប្រព័ន្ធផ្ទុកទិន្នន័យ និងផ្នែករឹងរបស់វា ហើយយើងមិនទាន់បានបង្កើតប្រព័ន្ធផ្ទុកទិន្នន័យផ្ទាល់ខ្លួនរបស់យើងនៅឡើយ)។

យើងបានសាកល្បងដំណោះស្រាយប្រភពបើកចំហជាច្រើន ហើយទីបំផុតបានដោះស្រាយបញ្ហានេះ ប៉ុន្តែដំណោះស្រាយគឺស្មុគស្មាញ និងពិបាកក្នុងការធ្វើម្តងទៀត។ លើសពីនេះ ដំណោះស្រាយនេះស្ថិតនៅក្នុងប្រភេទ “តើវាដំណើរការទេ? កុំប៉ះ! ដូច្នេះហើយ ដោយបានដោះស្រាយបញ្ហានោះ យើងមិនបានអភិវឌ្ឍបន្ថែមទៀតនូវគំនិតនៃការប្រែក្លាយលទ្ធផលនៃការងាររបស់យើងទៅជាផលិតផលពេញលេញនោះទេ។

បន្ទាប់ពីឧប្បត្តិហេតុនោះ យើងបានផ្លាស់ប្តូរឆ្ងាយពីគំនិតនេះ ប៉ុន្តែយើងនៅតែមានអារម្មណ៍ថាបញ្ហានេះអាចដោះស្រាយបានទាំងស្រុង ហើយអត្ថប្រយោជន៍នៃដំណោះស្រាយបែបនេះគឺច្រើនជាងជាក់ស្តែង។ ក្រោយមក ផលិតផល HCI របស់ក្រុមហ៊ុនបរទេសបានត្រឹមតែបញ្ជាក់ពីអារម្មណ៍នេះប៉ុណ្ណោះ។

ដូច្នេះហើយ នៅពាក់កណ្តាលឆ្នាំ 2016 យើងបានត្រលប់ទៅកិច្ចការនេះវិញ ដែលជាផ្នែកនៃការបង្កើតផលិតផលពេញលេញ។ នៅពេលនោះ យើងមិនទាន់មានទំនាក់ទំនងអ្វីជាមួយវិនិយោគិនទេ ដូច្នេះយើងត្រូវទិញកន្លែងអភិវឌ្ឍន៍សម្រាប់ខ្លួនយើង មិនមែនលុយច្រើនទេ។ ដោយបានប្រមូលម៉ាស៊ីនមេដែលបានប្រើហើយប្តូរនៅលើ Avito យើងបានចុះទៅអាជីវកម្ម។

ភារកិច្ចដំបូងចម្បងគឺបង្កើតរបស់យើង ទោះបីសាមញ្ញក៏ដោយ ប៉ុន្តែប្រព័ន្ធឯកសាររបស់យើងផ្ទាល់ ដែលអាចចែកចាយទិន្នន័យដោយស្វ័យប្រវត្តិ និងស្មើៗគ្នាក្នុងទម្រង់នៃប្លុកនិម្មិតនៅលើចំនួន nth នៃ nodes cluster ដែលត្រូវបានភ្ជាប់ដោយ interconnect តាមរយៈ Ethernet ។ ក្នុងពេលជាមួយគ្នានោះ FS គួរតែធ្វើមាត្រដ្ឋានបានល្អ និងងាយស្រួល និងឯករាជ្យពីប្រព័ន្ធដែលនៅជាប់គ្នា ពោលគឺឧ។ ត្រូវបានផ្តាច់ចេញពី vAIR ក្នុងទម្រង់ជា "គ្រាន់តែជាកន្លែងផ្ទុក"។

គំនិត vAIR ដំបូង

យើងបានបោះបង់ចោលដោយចេតនានូវការប្រើប្រាស់ដំណោះស្រាយប្រភពបើកចំហដែលត្រៀមរួចជាស្រេចសម្រាប់ការរៀបចំកន្លែងផ្ទុកដែលលាតសន្ធឹង (ceph, gluster, luster និងផ្សេងទៀត) ដើម្បីគាំទ្រដល់ការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួនរបស់យើង ដោយសារយើងមានបទពិសោធន៍គម្រោងជាច្រើនជាមួយពួកគេ។ ជាការពិតណាស់ដំណោះស្រាយទាំងនេះខ្លួនឯងគឺល្អឥតខ្ចោះ ហើយមុនពេលធ្វើការលើ Aerodisk យើងបានអនុវត្តគម្រោងការរួមបញ្ចូលច្រើនជាងមួយជាមួយពួកគេ។ ប៉ុន្តែវាជារឿងមួយដែលត្រូវអនុវត្តភារកិច្ចជាក់លាក់មួយសម្រាប់អតិថិជនម្នាក់ បណ្តុះបណ្តាលបុគ្គលិក និងប្រហែលជាទិញការគាំទ្រពីអ្នកលក់ដ៏ធំ ហើយរឿងមួយទៀតដើម្បីបង្កើតផលិតផលចម្លងយ៉ាងងាយស្រួលដែលនឹងត្រូវបានប្រើសម្រាប់កិច្ចការផ្សេងៗដែលយើងជា អ្នក​លក់​ប្រហែល​ជា​ដឹង​អំពី​ខ្លួន​យើង​នឹង​មិន​បាន។ សម្រាប់គោលបំណងទីពីរ ផលិតផលប្រភពបើកចំហដែលមានស្រាប់មិនសមស្របនឹងយើងទេ ដូច្នេះហើយយើងសម្រេចចិត្តបង្កើតប្រព័ន្ធឯកសារចែកចាយដោយខ្លួនឯង។
ពីរឆ្នាំក្រោយមក អ្នកអភិវឌ្ឍន៍ជាច្រើន (ដែលធ្វើការរួមគ្នាលើ vAIR ជាមួយនឹងការងារនៅលើប្រព័ន្ធផ្ទុកម៉ាស៊ីនបុរាណ) ទទួលបានលទ្ធផលជាក់លាក់មួយ។

នៅឆ្នាំ 2018 យើងបានសរសេរប្រព័ន្ធឯកសារសាមញ្ញមួយ ហើយបានបន្ថែមវាជាមួយនឹងផ្នែករឹងចាំបាច់។ ប្រព័ន្ធនេះរួមបញ្ចូលគ្នានូវថាសរូបវ័ន្ត (ក្នុងស្រុក) ពីម៉ាស៊ីនមេផ្សេងៗគ្នាចូលទៅក្នុងអាងផ្ទះល្វែងមួយតាមរយៈការភ្ជាប់ទំនាក់ទំនងខាងក្នុង ហើយ "កាត់" ពួកវាទៅជាប្លុកនិម្មិត បន្ទាប់មកឧបករណ៍ទប់ស្កាត់ដែលមានកម្រិតខុសគ្នានៃការអត់ឱនចំពោះកំហុសត្រូវបានបង្កើតឡើងពីប្លុកនិម្មិត ដែលប្លុកនិម្មិតត្រូវបានបង្កើត។ និងប្រតិបត្តិដោយប្រើប្រាស់រថយន្ត KVM hypervisor ។

យើង​មិន​បាន​រំខាន​ខ្លាំង​ពេក​ជាមួយ​នឹង​ឈ្មោះ​ប្រព័ន្ធ​ឯកសារ​ទេ ហើយ​បាន​ហៅ​វា​យ៉ាង​ខ្លី​ថា ​​ARDFS (ទាយ​ថា​វា​តំណាង​ឱ្យ​អ្វី))

គំរូនេះមើលទៅល្អ (មិនមែនជាការមើលឃើញទេ ពិតណាស់មិនទាន់មានការរចនាដែលមើលឃើញនៅឡើយ) ហើយបានបង្ហាញពីលទ្ធផលល្អទាក់ទងនឹងការអនុវត្ត និងការធ្វើមាត្រដ្ឋាន។ បន្ទាប់ពីលទ្ធផលពិតដំបូង យើងបានកំណត់គម្រោងនេះជាចលនា ដោយរៀបចំបរិយាកាសអភិវឌ្ឍន៍ពេញលេញ និងក្រុមដាច់ដោយឡែកដែលដោះស្រាយតែជាមួយ vAIR ប៉ុណ្ណោះ។

គ្រាន់តែនៅពេលនោះ ស្ថាបត្យកម្មទូទៅនៃដំណោះស្រាយបានចាស់ទុំ ដែលមិនទាន់មានការផ្លាស់ប្តូរធំដុំនៅឡើយ។

ចូលទៅក្នុងប្រព័ន្ធឯកសារ ARDFS

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

រចនាសម្ព័ន្ធផ្ទុក

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

ថាសនិម្មិត (វត្ថុផ្ទុកសម្រាប់ម៉ាស៊ីននិម្មិត) ត្រូវបានបន្ថែមនៅលើកំពូលនៃអាង ARDFS ដែលត្រូវបានបង្កើតឡើងពីប្លុកនិម្មិតដែលមានទំហំ 4 មេកាបៃ។ ថាសនិម្មិតរក្សាទុកទិន្នន័យដោយផ្ទាល់។ គ្រោងការណ៍អត់ធ្មត់កំហុសក៏ត្រូវបានកំណត់នៅកម្រិតថាសនិម្មិតផងដែរ។

ដូចដែលអ្នកប្រហែលជាបានទាយរួចហើយថាសម្រាប់ការអត់ឱនកំហុសនៃប្រព័ន្ធរងរបស់ឌីស យើងមិនប្រើគោលគំនិតនៃ RAID (អារេមិនច្របូកច្របល់នៃឌីសឯករាជ្យទេ) ប៉ុន្តែប្រើ RAIN (Redundant array of independent nodes)។ ទាំងនោះ។ ការអត់ឱនកំហុសត្រូវបានវាស់វែង ស្វ័យប្រវត្តិ និងគ្រប់គ្រងដោយផ្អែកលើថ្នាំង មិនមែនថាសទេ។ ជាការពិតណាស់ ថាសក៏ជាវត្ថុផ្ទុកផងដែរ ពួកវាដូចជាអ្វីៗផ្សេងទៀតត្រូវបានត្រួតពិនិត្យ អ្នកអាចអនុវត្តប្រតិបត្តិការស្តង់ដារទាំងអស់ជាមួយពួកវា រួមទាំងការផ្គុំ RAID ផ្នែករឹងក្នុងស្រុក ប៉ុន្តែចង្កោមដំណើរការជាពិសេសលើថ្នាំង។

នៅក្នុងស្ថានភាពដែលអ្នកពិតជាចង់បាន RAID (ឧទាហរណ៍ សេណារីយ៉ូដែលគាំទ្រការបរាជ័យជាច្រើននៅលើចង្កោមតូចៗ) គ្មានអ្វីរារាំងអ្នកពីការប្រើប្រាស់ឧបករណ៍បញ្ជា RAID ក្នុងតំបន់ និងការកសាងកន្លែងផ្ទុកដែលលាតសន្ធឹង និងស្ថាបត្យកម្ម RAIN នៅលើកំពូលនោះទេ។ សេណារីយ៉ូនេះពិតជាផ្សាយផ្ទាល់ ហើយត្រូវបានគាំទ្រដោយពួកយើង ដូច្នេះយើងនឹងនិយាយអំពីវានៅក្នុងអត្ថបទអំពីសេណារីយ៉ូធម្មតាសម្រាប់ការប្រើប្រាស់ vAIR ។

គ្រោងការណ៍នៃការអត់ឱនកំហុសការផ្ទុក

វាអាចមានគ្រោងការណ៍ការអត់ឱនកំហុសពីរសម្រាប់ថាសនិម្មិតនៅក្នុង vAIR៖

1) កត្តាចម្លង ឬចម្លងសាមញ្ញ - វិធីសាស្រ្តនៃការអត់ឱនកំហុសនេះគឺសាមញ្ញដូចជាដំបង និងខ្សែពួរ។ ការចម្លងតាមសមកាលកម្មត្រូវបានអនុវត្តរវាងថ្នាំងដែលមានកត្តា 2 (2 ច្បាប់ចម្លងក្នុងមួយចង្កោម) ឬ 3 (3 ច្បាប់ចម្លងរៀងគ្នា) ។ RF-2 អនុញ្ញាតឱ្យថាសនិម្មិតដើម្បីទប់ទល់នឹងការបរាជ័យនៃថ្នាំងមួយនៅក្នុងចង្កោម ប៉ុន្តែ "ស៊ី" ពាក់កណ្តាលនៃបរិមាណដែលមានប្រយោជន៍ ហើយ RF-3 នឹងទប់ទល់នឹងការបរាជ័យនៃថ្នាំង 2 នៅក្នុងចង្កោម ប៉ុន្តែបម្រុងទុក 2/3 នៃ បរិមាណមានប្រយោជន៍សម្រាប់តម្រូវការរបស់វា។ គ្រោងការណ៍នេះគឺស្រដៀងទៅនឹង RAID-1 ពោលគឺថាសនិម្មិតដែលបានកំណត់រចនាសម្ព័ន្ធក្នុង RF-2 មានភាពធន់ទ្រាំទៅនឹងការបរាជ័យនៃថ្នាំងណាមួយនៅក្នុងចង្កោម។ ក្នុងករណីនេះ អ្វីៗនឹងល្អជាមួយទិន្នន័យ ហើយសូម្បីតែ I/O ក៏មិនឈប់ដែរ។ នៅពេលដែលថ្នាំងដែលបានធ្លាក់ចុះត្រឡប់ទៅសេវាវិញ ការសង្គ្រោះ/ការធ្វើសមកាលកម្មទិន្នន័យដោយស្វ័យប្រវត្តិនឹងចាប់ផ្តើម។

ខាងក្រោមនេះជាឧទាហរណ៍នៃការចែកចាយទិន្នន័យ RF-2 និង RF-3 ក្នុងរបៀបធម្មតា និងក្នុងស្ថានភាពបរាជ័យ។

យើងមានម៉ាស៊ីននិម្មិតដែលមានទំហំ 8MB នៃទិន្នន័យពិសេស (មានប្រយោជន៍) ដែលដំណើរការលើ 4 vAIR nodes ។ វាច្បាស់ណាស់ថានៅក្នុងការពិតវាមិនទំនងថានឹងមានបរិមាណតូចបែបនេះទេប៉ុន្តែសម្រាប់គ្រោងការណ៍ដែលឆ្លុះបញ្ចាំងពីតក្កវិជ្ជានៃប្រតិបត្តិការ ARDFS ឧទាហរណ៍នេះគឺអាចយល់បានបំផុត។ AB គឺជាប្លុកនិម្មិត 4MB ដែលមានទិន្នន័យម៉ាស៊ីននិម្មិតតែមួយគត់។ RF-2 បង្កើតច្បាប់ចម្លងពីរនៃប្លុកទាំងនេះ A1+A2 និង B1+B2 រៀងគ្នា។ ប្លុកទាំងនេះត្រូវបាន "ដាក់ចេញ" នៅទូទាំងថ្នាំង ដោយជៀសវាងចំណុចប្រសព្វនៃទិន្នន័យដូចគ្នានៅលើថ្នាំងដូចគ្នា ពោលគឺចម្លង A1 នឹងមិនមានទីតាំងនៅលើថ្នាំងដូចគ្នាទៅនឹងច្បាប់ចម្លង A2 នោះទេ។ ដូចគ្នានឹង B1 និង B2 ។

ប្រសិនបើថ្នាំងណាមួយបរាជ័យ (ឧទាហរណ៍ ថ្នាំងលេខ 3 ដែលមានច្បាប់ចម្លង B1) ច្បាប់ចម្លងនេះត្រូវបានដំណើរការដោយស្វ័យប្រវត្តិនៅលើថ្នាំងដែលគ្មានច្បាប់ចម្លងរបស់វា (នោះគឺច្បាប់ចម្លង B2) ។

ដូច្នេះ ថាសនិម្មិត (និង VM តាមនោះ) អាចរស់បានយ៉ាងងាយស្រួលពីការបរាជ័យនៃថ្នាំងមួយនៅក្នុងគ្រោងការណ៍ RF-2 ។

គ្រោងការណ៍ចម្លងខណៈពេលដែលសាមញ្ញនិងអាចទុកចិត្តបានទទួលរងពីបញ្ហាដូចគ្នានឹង RAID1 - មិនមានកន្លែងប្រើប្រាស់គ្រប់គ្រាន់ទេ។

2) ការលុបការសរសេរកូដ ឬលុបការសរសេរកូដ (ត្រូវបានគេស្គាល់ផងដែរថាជា "ការសរសេរកូដដែលលែងត្រូវការ" "ការសរសេរកូដលុប" ឬ "កូដដែលប្រើឡើងវិញ") មានដើម្បីដោះស្រាយបញ្ហាខាងលើ។ EC គឺ​ជា​គម្រោង​ដែល​ប្រើ​ប្រាស់​ដដែលៗ​ដែល​ផ្តល់​នូវ​ទិន្នន័យ​ដែល​អាច​ប្រើ​បាន​ខ្ពស់​ជាមួយ​នឹង​ទំហំ​ថាស​ទាប​បើ​ធៀប​នឹង​ការ​ចម្លង។ គោលការណ៍ប្រតិបត្តិការនៃយន្តការនេះគឺស្រដៀងទៅនឹង RAID 5, 6, 6P ។

នៅពេលអ៊ិនកូដ ដំណើរការ EC បែងចែកប្លុកនិម្មិត (4MB តាមលំនាំដើម) ទៅជា "កំណាត់ទិន្នន័យ" តូចៗជាច្រើន អាស្រ័យលើគ្រោងការណ៍ EC (ឧទាហរណ៍ គ្រោងការណ៍ 2+1 បែងចែកប្លុក 4MB នីមួយៗទៅជា 2 2MB) ។ បន្ទាប់មក ដំណើរការនេះបង្កើត "កំណាត់ភាពស្មើគ្នា" សម្រាប់ "កំណាត់ទិន្នន័យ" ដែលមិនធំជាងផ្នែកមួយក្នុងចំណោមផ្នែកដែលបានបែងចែកពីមុន។ នៅពេលឌិកូដ EC បង្កើតកំណាត់ដែលបាត់ដោយការអានទិន្នន័យ "រស់រានមានជីវិត" នៅទូទាំងចង្កោមទាំងមូល។

ឧទាហរណ៍ ថាសនិម្មិតដែលមានគ្រោងការណ៍ 2 + 1 EC ដែលត្រូវបានអនុវត្តលើថ្នាំងចង្កោមចំនួន 4 នឹងងាយស្រួលទប់ទល់នឹងការបរាជ័យនៃថ្នាំងមួយនៅក្នុងចង្កោមតាមរបៀបដូចគ្នានឹង RF-2 ។ ក្នុងករណីនេះ ការចំណាយលើសនឹងទាបជាង ជាពិសេសមេគុណសមត្ថភាពមានប្រយោជន៍សម្រាប់ RF-2 គឺ 2 ហើយសម្រាប់ EC 2+1 វានឹងមាន 1,5 ។

ដើម្បីពិពណ៌នាវាឱ្យកាន់តែសាមញ្ញ ខ្លឹមសារគឺថាប្លុកនិម្មិតត្រូវបានបែងចែកជា 2-8 (ហេតុអ្វីបានជាពី 2 ទៅ 8 សូមមើលខាងក្រោម) "បំណែក" ហើយសម្រាប់បំណែកទាំងនេះ "បំណែក" នៃភាពស្មើគ្នានៃបរិមាណស្រដៀងគ្នាត្រូវបានគណនា។

ជាលទ្ធផល ទិន្នន័យ និងភាពស្មើគ្នាត្រូវបានចែកចាយស្មើៗគ្នានៅទូទាំងថ្នាំងទាំងអស់នៃចង្កោម។ ក្នុងពេលជាមួយគ្នានេះ ក៏ដូចជាការចម្លងដែរ ARDFS ចែកចាយទិន្នន័យដោយស្វ័យប្រវត្តិនៅលើថ្នាំងក្នុងវិធីមួយដើម្បីការពារទិន្នន័យដូចគ្នាបេះបិទ (ច្បាប់ចម្លងនៃទិន្នន័យ និងភាពស្មើគ្នារបស់ពួកគេ) ពីការរក្សាទុកនៅលើថ្នាំងដូចគ្នា ដើម្បីលុបបំបាត់ឱកាសនៃការបាត់បង់ទិន្នន័យដោយសារ ចំពោះការពិតដែលថាទិន្នន័យនិងភាពស្មើគ្នារបស់ពួកគេនឹងបញ្ចប់ភ្លាមៗនៅលើថ្នាំងផ្ទុកមួយដែលបរាជ័យ។

ខាងក្រោមនេះគឺជាឧទាហរណ៍មួយ ជាមួយនឹងម៉ាស៊ីននិម្មិត 8 MB ដូចគ្នា និង 4 nodes ប៉ុន្តែជាមួយនឹងគ្រោងការណ៍ EC 2+1 ។

ប្លុក A និង B ត្រូវបានបែងចែកជាពីរបំណែកនៃ 2 MB នីមួយៗ (ពីរព្រោះ 2+1) នោះគឺ A1+A2 និង B1+B2 ។ មិនដូចការចម្លងទេ A1 មិនមែនជាច្បាប់ចម្លងរបស់ A2 ទេ វាជាប្លុកនិម្មិត A ចែកជាពីរផ្នែកដូចគ្នាជាមួយប្លុក B។ សរុបមក យើងទទួលបានពីរឈុត 4MB ដែលនីមួយៗមានពីរបំណែក MB ។ បន្ទាប់មក សម្រាប់សំណុំនីមួយៗ ភាពស្មើគ្នាត្រូវបានគណនាដោយបរិមាណមិនលើសពីមួយដុំ (ឧ. 2 MB) យើងទទួលបានបន្ថែម + 2 បំណែកនៃភាពស្មើគ្នា (AP និង BP)។ សរុបមកយើងមានទិន្នន័យ 4×2 + 2×2 parity ។

បន្ទាប់មក បំណែកត្រូវបាន "ដាក់ចេញ" នៅទូទាំងថ្នាំង ដូច្នេះទិន្នន័យមិនប្រសព្វជាមួយភាពស្មើគ្នារបស់ពួកគេ។ ទាំងនោះ។ A1 និង A2 នឹងមិនស្ថិតនៅលើថ្នាំងដូចគ្នាជាមួយ AP ទេ។

ក្នុងករណីមានការបរាជ័យនៃថ្នាំងមួយ (ឧទាហរណ៍ ទីបីផងដែរ) ប្លុកដែលធ្លាក់ចុះ B1 នឹងត្រូវបានស្ដារឡើងវិញដោយស្វ័យប្រវត្តិពី BP parity ដែលត្រូវបានរក្សាទុកនៅលើថ្នាំងលេខ 2 ហើយនឹងត្រូវបានធ្វើឱ្យសកម្មនៅលើថ្នាំងដែលមាន គ្មាន B-parity, i.e. បំណែកនៃ BP ។ ក្នុងឧទាហរណ៍នេះគឺជាថ្នាំងលេខ 1

ខ្ញុំប្រាកដថាអ្នកអានមានសំណួរ៖

"អ្វីគ្រប់យ៉ាងដែលអ្នកបានពិពណ៌នាត្រូវបានអនុវត្តជាយូរមកហើយទាំងដោយដៃគូប្រកួតប្រជែង និងនៅក្នុងដំណោះស្រាយប្រភពបើកចំហ តើអ្វីជាភាពខុសគ្នារវាងការអនុវត្ត EC របស់អ្នកនៅក្នុង ARDFS?"

ហើយបន្ទាប់មកនឹងមានលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍នៃ ARDFS ។

លុបការសរសេរកូដដោយផ្តោតលើភាពបត់បែន

ដំបូងឡើយ យើងបានផ្តល់គ្រោងការណ៍ EC X+Y ដែលអាចបត់បែនបានដោយស្មើភាព ដែល X ស្មើនឹងលេខពី 2 ទៅ 8 ហើយ Y គឺស្មើនឹងលេខពី 1 ដល់លេខ 8 ប៉ុន្តែតែងតែតិចជាង ឬស្មើទៅនឹង X។ គ្រោងការណ៍នេះត្រូវបានផ្តល់ជូន សម្រាប់ភាពបត់បែន។ ការបង្កើនចំនួនបំណែកទិន្នន័យ (X) ដែលប្លុកនិម្មិតត្រូវបានបែងចែកអនុញ្ញាតឱ្យកាត់បន្ថយការចំណាយលើស ពោលគឺបង្កើនទំហំប្រើប្រាស់បាន។
ការបង្កើនចំនួនបំណែកស្មើគ្នា (Y) បង្កើនភាពជឿជាក់នៃថាសនិម្មិត។ តម្លៃ Y កាន់តែធំ ថ្នាំងកាន់តែច្រើននៅក្នុងចង្កោមអាចបរាជ័យ។ ជាការពិតណាស់ ការបង្កើនបរិមាណស្មើគ្នាកាត់បន្ថយបរិមាណនៃសមត្ថភាពដែលអាចប្រើប្រាស់បាន ប៉ុន្តែនេះគឺជាតម្លៃដែលត្រូវចំណាយសម្រាប់ភាពជឿជាក់។

ការពឹងផ្អែកនៃការអនុវត្តនៅលើសៀគ្វី EC គឺស្ទើរតែដោយផ្ទាល់: "បំណែក" កាន់តែច្រើន ការអនុវត្តកាន់តែទាបនៅទីនេះ ជាការពិត ទិដ្ឋភាពមានតុល្យភាពគឺត្រូវការ។

វិធីសាស្រ្តនេះអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងកំណត់រចនាសម្ព័ន្ធការផ្ទុកដែលលាតសន្ធឹងជាមួយនឹងភាពបត់បែនអតិបរមា។ នៅក្នុងអាង ARDFS អ្នកអាចប្រើគ្រោងការណ៍នៃការអត់ឱនកំហុសណាមួយនិងបន្សំរបស់ពួកគេដែលតាមគំនិតរបស់យើងក៏មានប្រយោជន៍ផងដែរ។

ខាងក្រោមនេះគឺជាតារាងប្រៀបធៀបគ្រោងការណ៍ RF និង EC ជាច្រើន (មិនអាចធ្វើទៅបានទាំងអស់) ។

តារាងបង្ហាញថាសូម្បីតែការរួមបញ្ចូលគ្នា "Terry" ច្រើនបំផុត EC 8 + 7 ដែលអនុញ្ញាតឱ្យបាត់បង់រហូតដល់ 7 ថ្នាំងក្នុងចង្កោមក្នុងពេលដំណាលគ្នា "បរិភោគ" ទំហំដែលអាចប្រើបានតិចជាង (1,875 ធៀបនឹង 2) ជាងការចម្លងស្តង់ដារ និងការពារ 7 ដងប្រសើរជាង ដែលធ្វើឱ្យយន្តការការពារនេះ ទោះបីកាន់តែស្មុគស្មាញក៏ដោយ ក៏កាន់តែមានភាពទាក់ទាញក្នុងស្ថានភាពដែលវាចាំបាច់ ដើម្បីធានាបាននូវភាពជឿជាក់អតិបរមានៅក្នុងលក្ខខណ្ឌនៃទំហំថាសមានកំណត់។ ក្នុងពេលជាមួយគ្នានេះ អ្នកត្រូវយល់ថារាល់ "បូក" ដល់ X ឬ Y នឹងក្លាយជាការអនុវត្តបន្ថែម ដូច្នេះនៅក្នុងត្រីកោណរវាងភាពជឿជាក់ ការសន្សំ និងការអនុវត្ត អ្នកត្រូវជ្រើសរើសដោយប្រុងប្រយ័ត្នបំផុត។ សម្រាប់ហេតុផលនេះ យើងនឹងលះបង់អត្ថបទដាច់ដោយឡែកមួយដើម្បីលុបទំហំការសរសេរកូដ។

ភាពជឿជាក់ និងស្វ័យភាពនៃប្រព័ន្ធឯកសារ

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

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

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

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

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

តើអ្នកណាត្រូវការអព្ភូតហេតុនេះ?

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

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

តើប្រព័ន្ធផ្ទុកទិន្នន័យល្អជាង GCS នៅពេលណា?

នៅពេលដែលយើងធ្វើការជាមួយទីផ្សារ យើងតែងតែត្រូវបានសួរថាតើពេលណាដែលវាល្អជាងក្នុងការប្រើប្រាស់គ្រោងការណ៍បុរាណជាមួយប្រព័ន្ធផ្ទុកទិន្នន័យ ហើយនៅពេលណាដែលត្រូវប្រើ hyperconvergent? ក្រុមហ៊ុនជាច្រើនដែលផលិត GCS (ជាពិសេសក្រុមហ៊ុនដែលមិនមានប្រព័ន្ធផ្ទុកនៅក្នុងផលប័ត្ររបស់ពួកគេ) និយាយថា៖ "ប្រព័ន្ធផ្ទុកទិន្នន័យកំពុងលែងប្រើ ហើយមានការបញ្ចូលគ្នាច្រើនតែប៉ុណ្ណោះ!" នេះ​ជា​សេចក្តីថ្លែងការណ៍​ដ៏​ក្លាហាន ប៉ុន្តែ​វា​មិន​ឆ្លុះបញ្ចាំង​ពី​ការពិត​ទាំងស្រុង​នោះទេ។

ជាការពិត ទីផ្សារផ្ទុកទិន្នន័យពិតជាកំពុងឆ្ពោះទៅរកការបង្រួបបង្រួមគ្នាខ្លាំង និងដំណោះស្រាយស្រដៀងគ្នា ប៉ុន្តែតែងតែមាន "ប៉ុន្តែ" ។

ទីមួយ មជ្ឈមណ្ឌលទិន្នន័យ និងហេដ្ឋារចនាសម្ព័ន្ធ IT ដែលត្រូវបានសាងសង់ឡើងតាមគ្រោងការណ៍បុរាណជាមួយនឹងប្រព័ន្ធផ្ទុកទិន្នន័យមិនអាចសាងសង់ឡើងវិញបានយ៉ាងងាយស្រួលនោះទេ ដូច្នេះទំនើបកម្ម និងការបញ្ចប់ហេដ្ឋារចនាសម្ព័ន្ធបែបនេះនៅតែជាកេរ្តិ៍ដំណែលសម្រាប់រយៈពេល 5-7 ឆ្នាំ។

ទីពីរ ហេដ្ឋារចនាសម្ព័ន្ធដែលបច្ចុប្បន្នកំពុងត្រូវបានសាងសង់សម្រាប់ផ្នែកភាគច្រើន (មានន័យថាសហព័ន្ធរុស្ស៊ី) ត្រូវបានសាងសង់ឡើងតាមគ្រោងការណ៍បុរាណដោយប្រើប្រព័ន្ធផ្ទុកទិន្នន័យ ហើយមិនមែនដោយសារតែមនុស្សមិនដឹងអំពី hyperconvergence នោះទេ ប៉ុន្តែដោយសារតែទីផ្សារ hyperconvergence គឺថ្មី ដំណោះស្រាយ និង ស្ដង់ដារមិនទាន់ត្រូវបានបង្កើតឡើងនៅឡើយ មនុស្ស IT មិនទាន់ទទួលបានការបណ្តុះបណ្តាលនៅឡើយ ពួកគេមានបទពិសោធន៍តិចតួច ប៉ុន្តែពួកគេត្រូវការបង្កើតមជ្ឈមណ្ឌលទិន្នន័យនៅទីនេះ និងឥឡូវនេះ។ ហើយនិន្នាការនេះនឹងមានរយៈពេល 3-5 ឆ្នាំទៀត (ហើយបន្ទាប់មកកេរ្តិ៍ដំណែលមួយទៀត សូមមើលចំណុចទី 1) ។

ទីបី វាមានកម្រិតបច្ចេកទេសសុទ្ធសាធក្នុងការពន្យាពេលតិចតួចបន្ថែម 2 មិល្លីវិនាទីក្នុងមួយសរសេរ (ជាការពិតណាស់មិនរាប់បញ្ចូលឃ្លាំងសម្ងាត់មូលដ្ឋាន) ដែលជាថ្លៃដើមនៃការចែកចាយ។

ជាការប្រសើរណាស់, កុំភ្លេចអំពីការប្រើប្រាស់ម៉ាស៊ីនមេរាងកាយធំដែលចូលចិត្តការធ្វើមាត្រដ្ឋានបញ្ឈរនៃប្រព័ន្ធរងថាស។

មានកិច្ចការចាំបាច់ និងពេញនិយមជាច្រើនដែលប្រព័ន្ធផ្ទុកទិន្នន័យដំណើរការល្អជាង GCS ។ នៅទីនេះជាការពិតណាស់ក្រុមហ៊ុនផលិតទាំងនោះដែលមិនមានប្រព័ន្ធផ្ទុកនៅក្នុងផលប័ត្រផលិតផលរបស់ពួកគេនឹងមិនយល់ស្របជាមួយយើងទេប៉ុន្តែយើងត្រៀមខ្លួនដើម្បីជជែកវែកញែកដោយសមហេតុផល។ ជាការពិតណាស់ ពួកយើងក្នុងនាមជាអ្នកអភិវឌ្ឍន៍ផលិតផលទាំងពីរ ប្រាកដជានឹងប្រៀបធៀបប្រព័ន្ធផ្ទុកទិន្នន័យ និង GCS នៅក្នុងការបោះពុម្ពផ្សាយនាពេលអនាគតរបស់យើង ដែលយើងនឹងបង្ហាញយ៉ាងច្បាស់ថាមួយណាល្អជាងនៅក្រោមលក្ខខណ្ឌណាមួយ។

ហើយតើដំណោះស្រាយ hyperconverged ដំណើរការល្អជាងប្រព័ន្ធផ្ទុកទិន្នន័យនៅឯណា?

ដោយផ្អែកលើចំណុចខាងលើ ការសន្និដ្ឋានជាក់ស្តែងចំនួនបីអាចត្រូវបានទាញ៖

1. នៅពេលដែលការពន្យាពេលបន្ថែម 2 មិល្លីវិនាទីសម្រាប់ការថត ដែលកើតឡើងជាប់លាប់នៅក្នុងផលិតផលណាមួយ (ឥឡូវនេះយើងមិននិយាយអំពីសំយោគទេ nanoseconds អាចត្រូវបានបង្ហាញនៅលើសំយោគ) គឺមិនសមហេតុសមផលទេ hyperconvergent គឺសមរម្យ។
2. កន្លែងដែលការផ្ទុកពីម៉ាស៊ីនមេធំអាចប្រែទៅជានិម្មិតតូចៗជាច្រើន ហើយចែកចាយក្នុងចំណោមថ្នាំង នោះ hyperconvergence ក៏នឹងដំណើរការល្អនៅទីនោះផងដែរ។
3. កន្លែងដែលការធ្វើមាត្រដ្ឋានផ្ដេកគឺជាអាទិភាពខ្ពស់ជាងការធ្វើមាត្រដ្ឋានបញ្ឈរ GCS នឹងធ្វើបានល្អនៅទីនោះផងដែរ។

តើដំណោះស្រាយទាំងនេះជាអ្វី?

1. សេវាកម្មហេដ្ឋារចនាសម្ព័ន្ធស្តង់ដារទាំងអស់ (សេវាថតសំបុត្រ EDMS ម៉ាស៊ីនមេឯកសារ ប្រព័ន្ធ ERP និង BI តូច ឬមធ្យម។ល។)។ យើងហៅវាថា "ការគណនាទូទៅ" ។
2. ហេដ្ឋារចនាសម្ព័ន្ធនៃអ្នកផ្តល់សេវាពពក ដែលចាំបាច់ត្រូវពង្រីកយ៉ាងរហ័ស និងតាមស្តង់ដារផ្ដេក និងងាយស្រួល "កាត់" ម៉ាស៊ីននិម្មិតមួយចំនួនធំសម្រាប់អតិថិជន។
3. ហេដ្ឋារចនាសម្ព័ន្ធផ្ទៃតុនិម្មិត (VDI) ដែលម៉ាស៊ីននិម្មិតអ្នកប្រើប្រាស់តូចៗជាច្រើនដំណើរការ ហើយ "អណ្តែត" ស្ងាត់ៗនៅក្នុងចង្កោមឯកសណ្ឋាន។
4. បណ្តាញសាខា ដែលសាខានីមួយៗត្រូវការស្តង់ដារ ធន់នឹងកំហុស ប៉ុន្តែហេដ្ឋារចនាសម្ព័ន្ធមានតំលៃថោកនៃម៉ាស៊ីននិម្មិត 15-20 ។
5. រាល់ការគណនាដែលបានចែកចាយ (ឧទាហរណ៍សេវាកម្មទិន្នន័យធំ)។ កន្លែងដែលបន្ទុកមិន "ជ្រៅ" ប៉ុន្តែ "ក្នុងទទឹង" ។
6. បរិយាកាសសាកល្បង ដែលការពន្យារពេលតិចតួចអាចទទួលយកបាន ប៉ុន្តែមានការរឹតបន្តឹងថវិកា ពីព្រោះទាំងនេះគឺជាការធ្វើតេស្ត។

នៅពេលនេះ វាគឺសម្រាប់កិច្ចការទាំងនេះដែលយើងបានបង្កើត AERODISK vAIR ហើយវាស្ថិតនៅលើពួកគេដែលយើងកំពុងផ្តោតអារម្មណ៍ (ទទួលបានជោគជ័យរហូតមកដល់ពេលនេះ)។ ប្រហែលជាវានឹងផ្លាស់ប្តូរក្នុងពេលឆាប់ៗនេះ ព្រោះ... ពិភពលោកមិននៅស្ងៀមទេ។

ដូច្នេះ…

វាបញ្ចប់ផ្នែកដំបូងនៃស៊េរីធំនៃអត្ថបទនៅក្នុងអត្ថបទបន្ទាប់យើងនឹងនិយាយអំពីស្ថាបត្យកម្មនៃដំណោះស្រាយនិងសមាសធាតុដែលបានប្រើ។

យើងស្វាគមន៍សំណួរ សំណូមពរ និងជម្លោះស្ថាបនា។

ប្រភព: www.habr.com