លីនុចមានមុខជាច្រើន៖ របៀបធ្វើការលើការចែកចាយណាមួយ។

ការបង្កើតកម្មវិធីបម្រុងទុកដែលដំណើរការលើការចែកចាយណាមួយមិនមែនជាកិច្ចការងាយស្រួលនោះទេ។ ដើម្បីធានាថា Veeam Agent សម្រាប់លីនុចដំណើរការលើការចែកចាយពី Red Hat 6 និង Debian 6 ដល់ OpenSUSE 15.1 និង Ubuntu 19.04 អ្នកត្រូវដោះស្រាយបញ្ហាជាច្រើន ជាពិសេសការពិចារណាថាផលិតផលកម្មវិធីរួមមានម៉ូឌុលខឺណែល។

អត្ថបទ​ត្រូវ​បាន​បង្កើត​ឡើង​ដោយ​ផ្អែក​លើ​សម្ភារៈ​ពី​សុន្ទរកថា​ក្នុង​សន្និសីទ Linux Peter 2019.

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

អ្នកគ្រប់គ្រងកញ្ចប់។ .deb ទល់នឹង .rpm

ចូរចាប់ផ្តើមជាមួយនឹងបញ្ហាជាក់ស្តែងនៃការចែកចាយផលិតផលឆ្លងកាត់ការចែកចាយផ្សេងៗគ្នា។
មធ្យោបាយធម្មតាបំផុតក្នុងការចែកចាយផលិតផលកម្មវិធីគឺត្រូវដាក់កញ្ចប់នៅលើឃ្លាំងមួយ ដើម្បីឱ្យអ្នកគ្រប់គ្រងកញ្ចប់ដែលបានបង្កើតនៅក្នុងប្រព័ន្ធអាចដំឡើងវាពីទីនោះបាន។
ទោះយ៉ាងណាក៏ដោយ យើងមានទម្រង់កញ្ចប់ពេញនិយមពីរ៖ rpm и deb. នេះមានន័យថាអ្នកគ្រប់គ្នានឹងត្រូវគាំទ្រ។

នៅក្នុងពិភពនៃកញ្ចប់ deb កម្រិតនៃភាពឆបគ្នាគឺអស្ចារ្យណាស់។ កញ្ចប់ដូចគ្នាដំឡើង និងដំណើរការបានល្អដូចគ្នាទាំងនៅលើ Debian 6 និង Ubuntu 19.04។ ស្តង់ដារសម្រាប់ដំណើរការបង្កើតកញ្ចប់ និងធ្វើការជាមួយពួកវាដែលដាក់ចុះក្នុងការបែងចែក Debian ចាស់ នៅតែពាក់ព័ន្ធនៅក្នុង Linux Mint និងប្រព័ន្ធប្រតិបត្តិការបឋមដែលទើបនឹងកើត។ ដូច្នេះក្នុងករណី Veeam Agent សម្រាប់ Linux កញ្ចប់ deb មួយសម្រាប់ hardware platform នីមួយៗគឺគ្រប់គ្រាន់ហើយ។

ប៉ុន្តែនៅក្នុងពិភពនៃកញ្ចប់ rpm ភាពខុសគ្នាគឺអស្ចារ្យណាស់។ ទីមួយ ដោយសារតែមានអ្នកចែកចាយឯករាជ្យទាំងស្រុងពីរគឺ Red Hat និង SUSE ដែលភាពត្រូវគ្នាគឺមិនចាំបាច់ទាំងស្រុង។ ទីពីរ អ្នកចែកចាយទាំងនេះមានឧបករណ៍ចែកចាយពីអ្នកទាំងនោះ។ ការគាំទ្រនិងពិសោធន៍។ មិនចាំបាច់មានភាពឆបគ្នារវាងពួកគេទាំងពីរទេ។ វាបានប្រែក្លាយថា el6, el7 និង el8 មានកញ្ចប់ផ្ទាល់ខ្លួនរបស់ពួកគេ។ កញ្ចប់ដាច់ដោយឡែកសម្រាប់ Fedora ។ កញ្ចប់សម្រាប់ SLES11 និង 12 និងមួយដាច់ដោយឡែកសម្រាប់ openSUSE ។ បញ្ហាចម្បងគឺភាពអាស្រ័យ និងឈ្មោះកញ្ចប់។

បញ្ហាភាពអាស្រ័យ

ជាអកុសល កញ្ចប់ដូចគ្នាជារឿយៗបញ្ចប់នៅក្រោមឈ្មោះផ្សេងគ្នានៅក្នុងការចែកចាយផ្សេងៗគ្នា។ ខាងក្រោមនេះគឺជាបញ្ជីផ្នែកនៃភាពអាស្រ័យនៃកញ្ចប់ veeam ។

សម្រាប់ EL7៖
សម្រាប់ SLES 12៖

• libblkid
• libgcc
• libstdc++
• ncurses-libs
• fuse-libs
• file-libs
• veeamsnap=3.0.2.1185

• libblkid ១
• libgcc_s1
• libstdc++ ៦
• libmagic ១
• libfuse ២
• veeamsnap-kmp=3.0.2.1185

ជាលទ្ធផល បញ្ជីនៃភាពអាស្រ័យគឺមានតែមួយគត់សម្រាប់ការចែកចាយ។

អ្វីដែលកាន់តែអាក្រក់នោះគឺនៅពេលដែលកំណែដែលបានអាប់ដេតចាប់ផ្តើមលាក់នៅក្រោមឈ្មោះកញ្ចប់ចាស់។

ឧទាហរណ៍:

កញ្ចប់នេះត្រូវបានធ្វើបច្ចុប្បន្នភាពនៅក្នុង Fedora 24 លេស ពីកំណែទី 5 ដល់កំណែ 6 ។ ផលិតផលរបស់យើងត្រូវបានបង្កើតឡើងជាមួយនឹងកំណែទី 5 ដើម្បីធានាបាននូវភាពឆបគ្នាជាមួយនឹងការចែកចាយចាស់ៗ។ ដើម្បីប្រើកំណែទី 5 ចាស់នៃបណ្ណាល័យនៅលើ Fedora 24 ខ្ញុំត្រូវប្រើកញ្ចប់ ncurses-compat-libs.

ជាលទ្ធផលមានកញ្ចប់ពីរសម្រាប់ Fedora ដែលមានភាពអាស្រ័យខុសៗគ្នា។

គួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀត។ បន្ទាប់ពីការអាប់ដេតការចែកចាយបន្ទាប់ កញ្ចប់ ncurses-compat-libs ជាមួយនឹងកំណែ 5 នៃបណ្ណាល័យ វាប្រែថាមិនអាចប្រើបាន។ វាមានតម្លៃថ្លៃសម្រាប់អ្នកចែកចាយដើម្បីអូសបណ្ណាល័យចាស់ៗទៅក្នុងកំណែថ្មីនៃការចែកចាយ។ បន្ទាប់ពីពេលខ្លះ បញ្ហាបានកើតឡើងម្តងទៀតនៅក្នុងការចែកចាយ SUSE ។

ជាលទ្ធផល ការចែកចាយមួយចំនួនត្រូវទម្លាក់ការពឹងផ្អែកច្បាស់លាស់របស់ពួកគេទៅលើ ncurses-libsនិងជួសជុលផលិតផលដើម្បីឱ្យវាអាចដំណើរការជាមួយកំណែណាមួយនៃបណ្ណាល័យ។

ដោយវិធីនេះនៅក្នុងកំណែទី 8 នៃ Red Hat មិនមានកញ្ចប់មេតាទៀតទេ ពស់ថ្លាន់ដែលសំដៅទៅចាស់ល្អ។ ពស់ថ្លាន់ 2.7។ មាន python2 и ពស់ថ្លាន់3.

ជម្មើសជំនួសសម្រាប់អ្នកគ្រប់គ្រងកញ្ចប់

បញ្ហា​ដែល​មាន​ភាព​អាស្រ័យ​គឺ​ចាស់​ហើយ​ច្បាស់​ជា​យូរ​មក​ហើយ។ ចាំតែ Dependency hell ។
ដើម្បីបញ្ចូលគ្នានូវបណ្ណាល័យ និងកម្មវិធីផ្សេងៗ ដើម្បីឱ្យពួកវាដំណើរការប្រកបដោយស្ថេរភាព និងមិនមានជម្លោះ - តាមពិតនេះគឺជាកិច្ចការដែលអ្នកចែកចាយលីនុចព្យាយាមដោះស្រាយ។

អ្នកគ្រប់គ្រងកញ្ចប់ព្យាយាមដោះស្រាយបញ្ហានេះតាមរបៀបខុសគ្នាទាំងស្រុង។ សូណាសប្បាយចិត្ត ពី Canonical ។ គំនិតចម្បង៖ កម្មវិធីដំណើរការក្នុងប្រអប់ខ្សាច់ដាច់ដោយឡែក និងត្រូវបានការពារពីប្រព័ន្ធមេ។ ប្រសិនបើកម្មវិធីត្រូវការបណ្ណាល័យ ពួកគេត្រូវបានផ្គត់ផ្គង់ជាមួយកម្មវិធីខ្លួនឯង។

Flatpak ក៏អនុញ្ញាតឱ្យអ្នកដំណើរការកម្មវិធីនៅក្នុងប្រអប់ខ្សាច់ដោយប្រើ Linux Containers ។ គំនិតប្រអប់ខ្សាច់ក៏ត្រូវបានប្រើប្រាស់ផងដែរ។ AppImage.

ដំណោះស្រាយទាំងនេះអនុញ្ញាតឱ្យអ្នកបង្កើតកញ្ចប់មួយសម្រាប់ការចែកចាយណាមួយ។ ក្នុងករណី Flatpak ការដំឡើង និងការបើកដំណើរការកម្មវិធីគឺអាចធ្វើទៅបាន ទោះបីជាមិនមានចំណេះដឹងរបស់អ្នកគ្រប់គ្រងក៏ដោយ។

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

បញ្ហាទីពីរគឺថាការចែកចាយពេញនិយមនៅក្នុងបរិយាកាសសហគ្រាសពី Red Hat និង SUSE មិនទាន់មានការគាំទ្រសម្រាប់ Snappy និង Flatpak នៅឡើយទេ។

ក្នុងន័យនេះ ភ្នាក់ងារ Veeam សម្រាប់លីនុចមិនមានទេ។ snapcraft.io មិននៅលើ flathub.org.

ដើម្បីបញ្ចប់សំណួរអំពីកម្មវិធីគ្រប់គ្រងកញ្ចប់ ខ្ញុំចង់កត់សម្គាល់ថាមានជម្រើសមួយដើម្បីបោះបង់កម្មវិធីគ្រប់គ្រងកញ្ចប់ទាំងស្រុងដោយរួមបញ្ចូលគ្នានូវឯកសារគោលពីរ និងស្គ្រីបសម្រាប់ដំឡើងពួកវាទៅក្នុងកញ្ចប់មួយ។

កញ្ចប់បែបនេះអនុញ្ញាតឱ្យអ្នកបង្កើតកញ្ចប់ទូទៅមួយសម្រាប់ការចែកចាយ និងវេទិកាផ្សេងៗគ្នា អនុវត្តដំណើរការដំឡើងអន្តរកម្ម អនុវត្តការប្ដូរតាមបំណងចាំបាច់។ ខ្ញុំទើបតែជួបប្រទះកញ្ចប់បែបនេះសម្រាប់លីនុចពី VMware ។

បញ្ហាអាប់ដេត

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

មានយុទ្ធសាស្ត្រអាប់ដេតចំនួន ៣៖

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

ដោយសារអ្នកប្រើប្រាស់ផ្សេងគ្នាប្រើយុទ្ធសាស្ត្រអាប់ដេតផ្សេងៗគ្នា នោះវាចាំបាច់ដើម្បីគាំទ្រទាំងការចេញផ្សាយចុងក្រោយបង្អស់ និងកំណែដែលបានចេញផ្សាយពីមុនទាំងអស់។ នេះធ្វើឱ្យស្មុគស្មាញទាំងដំណើរការអភិវឌ្ឍន៍ និងការធ្វើតេស្ត ហើយបន្ថែមការឈឺក្បាលដល់ក្រុមគាំទ្រ។

ភាពខុសគ្នានៃវេទិកាផ្នែករឹង

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

នៅក្នុងគម្រោង Veeam Agent for Linux យើងនៅតែមិនអាចគាំទ្រអ្វីទាំងអស់ដូច RISC នេះទេ។

ខ្ញុំនឹងមិនរស់នៅលើបញ្ហានេះដោយលំអិតទេ។ ខ្ញុំនឹងរៀបរាប់តែបញ្ហាចម្បងៗប៉ុណ្ណោះ៖ ប្រភេទដែលពឹងផ្អែកលើវេទិកា ដូចជា size_tការតម្រឹមរចនាសម្ព័ន្ធ និងលំដាប់បៃ។

ការភ្ជាប់ឋិតិវន្ត និង/ឬថាមវន្ត

ប៉ុន្តែសំណួរគឺ "តើធ្វើដូចម្តេចដើម្បីភ្ជាប់ជាមួយបណ្ណាល័យ - ថាមវន្តឬឋិតិវន្ត?" មានតម្លៃពិភាក្សា។

តាមក្បួនកម្មវិធី C/C++ នៅក្រោមលីនុច ប្រើការភ្ជាប់ថាមវន្ត។ វាដំណើរការល្អប្រសិនបើកម្មវិធីត្រូវបានបង្កើតឡើងជាពិសេសសម្រាប់ការចែកចាយជាក់លាក់មួយ។

ប្រសិនបើភារកិច្ចគឺដើម្បីគ្របដណ្តប់ការចែកចាយផ្សេងៗជាមួយនឹងឯកសារគោលពីរមួយ នោះអ្នកត្រូវផ្តោតលើការចែកចាយដែលគាំទ្រចាស់ជាងគេ។ សម្រាប់ពួកយើង នេះគឺជា Red Hat 6។ វាមាន gcc 4.4 ដែលសូម្បីតែស្តង់ដារ C++11 មិនគាំទ្រ យ៉ាងពេញលេញ.

យើងបង្កើតគម្រោងរបស់យើងដោយប្រើ gcc 6.3 ដែលគាំទ្រយ៉ាងពេញលេញ C++14 ។ តាមធម្មជាតិ ក្នុងករណីនេះនៅលើ Red Hat 6 អ្នកត្រូវតែយក libstdc++ និងជំរុញបណ្ណាល័យជាមួយអ្នក។ មធ្យោបាយងាយស្រួលបំផុតគឺភ្ជាប់ទៅពួកគេដោយឋិតិវន្ត។

ប៉ុន្តែ alas មិនមែនគ្រប់បណ្ណាល័យទាំងអស់អាចភ្ជាប់គ្នាដោយឋិតិវន្តនោះទេ។

ទីមួយបណ្ណាល័យប្រព័ន្ធដូចជា libfuse, libblkid វាចាំបាច់ក្នុងការភ្ជាប់ថាមវន្តដើម្បីធានាភាពឆបគ្នារបស់ពួកគេជាមួយខឺណែល និងម៉ូឌុលរបស់វា។

ទីពីរ​គឺ​មាន​ភាព​ទន់ភ្លន់​ជាមួយ​នឹង​អាជ្ញាប័ណ្ណ។

អាជ្ញាប័ណ្ណ GPL ជាមូលដ្ឋានអនុញ្ញាតឱ្យអ្នកភ្ជាប់បណ្ណាល័យតែជាមួយកូដប្រភពបើកចំហប៉ុណ្ណោះ។ MIT និង BSD អនុញ្ញាតឱ្យមានការភ្ជាប់ឋិតិវន្ត និងអនុញ្ញាតឱ្យបណ្ណាល័យត្រូវបានរួមបញ្ចូលនៅក្នុងគម្រោងមួយ។ ប៉ុន្តែ LGPL ហាក់បីដូចជាមិនផ្ទុយនឹងការភ្ជាប់ឋិតិវន្តទេ ប៉ុន្តែតម្រូវឱ្យឯកសារដែលចាំបាច់សម្រាប់ការភ្ជាប់ត្រូវបានចែករំលែក។

ជាទូទៅ ការប្រើប្រាស់ការភ្ជាប់ថាមវន្តនឹងរារាំងអ្នកពីការផ្តល់អ្វីទាំងអស់។

បង្កើតកម្មវិធី C/C++

ដើម្បីបង្កើតកម្មវិធី C/C++ សម្រាប់វេទិកា និងការចែកចាយផ្សេងៗគ្នា វាគ្រប់គ្រាន់ហើយក្នុងការជ្រើសរើស ឬបង្កើតកំណែសមរម្យនៃ gcc ហើយប្រើ cross-compilers សម្រាប់ស្ថាបត្យកម្មជាក់លាក់ ហើយប្រមូលផ្តុំសំណុំបណ្ណាល័យទាំងមូល។ ការងារ​នេះ​គឺ​អាច​ធ្វើ​ទៅ​បាន ប៉ុន្តែ​មាន​បញ្ហា​ណាស់។ ហើយមិនមានការធានាថាអ្នកចងក្រង និងបណ្ណាល័យដែលបានជ្រើសរើសនឹងផ្តល់នូវកំណែដែលអាចដំណើរការបាននោះទេ។

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

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

ទោះយ៉ាងណាក៏ដោយ មានគុណវិបត្តិចំពោះវិធីសាស្រ្តនេះ៖ សម្រាប់ការចែកចាយនីមួយៗនៅក្នុងស្ថាបត្យកម្មដូចគ្នា អ្នកនឹងត្រូវប្រមូលសំណុំឯកសារគោលពីរផ្ទាល់ខ្លួនរបស់អ្នក។ គុណវិបត្តិមួយទៀតគឺថាម៉ាស៊ីនមួយចំនួនធំបែបនេះត្រូវតែរក្សា ហើយទំហំថាស និង RAM ច្រើនត្រូវតែបែងចែក។

នេះជារបៀបដែលកញ្ចប់ KMOD នៃម៉ូឌុលខឺណែល veeamsnap ត្រូវបានចងក្រងសម្រាប់ការចែកចាយ Red Hat ។

បើកសេវាកម្មសាងសង់

សហសេវិកមកពី SUSE បានព្យាយាមអនុវត្តមូលដ្ឋានកណ្តាលមួយចំនួនក្នុងទម្រង់នៃសេវាកម្មពិសេសសម្រាប់ការចងក្រងកម្មវិធី និងការផ្គុំកញ្ចប់ - សេវាកម្មបើកចំហ.

សំខាន់ វាគឺជា hypervisor ដែលបង្កើតម៉ាស៊ីននិម្មិត ដំឡើងកញ្ចប់ចាំបាច់ទាំងអស់នៅក្នុងវា ចងក្រងកម្មវិធី និងបង្កើតកញ្ចប់នៅក្នុងបរិយាកាសដាច់ដោយឡែកនេះ បន្ទាប់ពីនោះម៉ាស៊ីននិម្មិតត្រូវបានបញ្ចេញ។

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

ទោះយ៉ាងណាក៏ដោយ មានបញ្ហាមួយ៖ ឧបករណ៍ច្រូតកាត់បែបនេះពិបាកនឹងបំពាក់ទៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធដែលមានស្រាប់។ ឧទាហរណ៍ ការគ្រប់គ្រងកំណែគឺមិនចាំបាច់ទេ យើងមានរបស់យើងសម្រាប់កូដប្រភពរួចហើយ។ យន្តការហត្ថលេខារបស់យើងគឺខុសគ្នា៖ យើងប្រើម៉ាស៊ីនមេពិសេស។ ឃ្លាំងក៏មិនត្រូវការដែរ។

លើសពីនេះទៀត ការគាំទ្រសម្រាប់ការចែកចាយផ្សេងទៀត - ឧទាហរណ៍ Red Hat - ត្រូវបានអនុវត្តយ៉ាងលំបាក ដែលអាចយល់បាន។

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

នៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង ដោយប្រើ OpenBuildService កញ្ចប់ KMP ជាច្រើនប្រភេទទាំងមូលនៃម៉ូឌុលខឺណែល veeamsnap សម្រាប់ការចែកចាយ SUSE ត្រូវបានប្រមូលផ្តុំ។

បន្ទាប់ ខ្ញុំចង់និយាយអំពីបញ្ហាជាក់លាក់ចំពោះម៉ូឌុលខឺណែល។

ខឺណែល ABI

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

ដើម្បីបង្កើតម៉ូឌុលសម្រាប់ខឺណែល vanilla អ្នកប្រាកដជាត្រូវការបឋមកថានៃខឺណែលពិសេសនេះ ហើយវានឹងដំណើរការតែលើខឺណែលនេះប៉ុណ្ណោះ។

DKMS អនុញ្ញាតឱ្យអ្នកធ្វើស្វ័យប្រវត្តិកម្មដំណើរការនៃការបង្កើតម៉ូឌុលនៅពេលធ្វើបច្ចុប្បន្នភាពខឺណែល។ ជាលទ្ធផល អ្នកប្រើប្រាស់នៃឃ្លាំង Debian (និងសាច់ញាតិជាច្រើនរបស់វា) ប្រើម៉ូឌុលខឺណែលទាំងពីឃ្លាំងរបស់អ្នកចែកចាយ ឬចងក្រងពីប្រភពដោយប្រើ DKMS ។

ទោះជាយ៉ាងណាក៏ដោយ ស្ថានភាពនេះមិនសមស្របនឹងផ្នែកសហគ្រាសជាពិសេសនោះទេ។ អ្នកចែកចាយកូដកម្មសិទ្ធិចង់ចែកចាយផលិតផលជាប្រព័ន្ធគោលពីរដែលបានចងក្រង។

អ្នកគ្រប់គ្រងមិនចង់រក្សាទុកឧបករណ៍អភិវឌ្ឍន៍នៅលើម៉ាស៊ីនមេផលិតកម្មសម្រាប់ហេតុផលសុវត្ថិភាពទេ។ អ្នកចែកចាយ Enterprise Linux ដូចជា Red Hat និង SUSE បានសម្រេចចិត្តថាពួកគេអាចគាំទ្រ kABI ដែលមានស្ថេរភាពសម្រាប់អ្នកប្រើប្រាស់របស់ពួកគេ។ លទ្ធផលគឺកញ្ចប់ KMOD សម្រាប់ Red Hat និងកញ្ចប់ KMP សម្រាប់ SUSE ។

ខ្លឹមសារនៃដំណោះស្រាយនេះគឺសាមញ្ញណាស់។ សម្រាប់កំណែជាក់លាក់នៃការចែកចាយ Kernel API ត្រូវបានបង្កក។ អ្នកចែកចាយបញ្ជាក់ថាគាត់ប្រើខឺណែលឧទាហរណ៍ 3.10 ហើយធ្វើការកែតម្រូវ និងកែលម្អតែប៉ុណ្ណោះដែលមិនប៉ះពាល់ដល់ចំណុចប្រទាក់ខឺណែល ហើយម៉ូឌុលដែលប្រមូលបានសម្រាប់ខឺណែលដំបូងបំផុតអាចប្រើសម្រាប់កម្មវិធីបន្តបន្ទាប់ទាំងអស់ដោយគ្មានការចងក្រងឡើងវិញ។

Red Hat ទាមទារភាពឆបគ្នា kABI សម្រាប់ការចែកចាយពេញមួយវដ្តជីវិតរបស់វា។ នោះគឺម៉ូឌុលដែលបានជួបប្រជុំគ្នាសម្រាប់ rhel 6.0 (ចេញផ្សាយខែវិច្ឆិកា 2010) ក៏គួរតែដំណើរការលើកំណែ 6.10 (ចេញផ្សាយខែមិថុនា ឆ្នាំ 2018)។ ហើយនេះគឺជិត 8 ឆ្នាំ។ តាមធម្មជាតិ កិច្ចការនេះគឺពិបាកណាស់។
យើងបានកត់ត្រាករណីជាច្រើនដែលម៉ូឌុល veeamsnap ឈប់ដំណើរការដោយសារបញ្ហាភាពឆបគ្នា kABI ។

បន្ទាប់ពីម៉ូឌុល veeamsnap ដែលបានចងក្រងសម្រាប់ RHEL 7.0 បានប្រែទៅជាមិនឆបគ្នាជាមួយខឺណែលពី RHEL 7.5 ប៉ុន្តែវាបានផ្ទុក និងត្រូវបានធានាថានឹងគាំងម៉ាស៊ីនមេ យើងបានបោះបង់ចោលការប្រើប្រាស់ភាពឆបគ្នា kABI សម្រាប់ RHEL 7 ទាំងអស់គ្នា។

បច្ចុប្បន្ន កញ្ចប់ KMOD សម្រាប់ RHEL 7 មានការជួបប្រជុំគ្នាសម្រាប់កំណែចេញផ្សាយនីមួយៗ និងស្គ្រីបដែលផ្ទុកម៉ូឌុល។

SUSE បានខិតទៅជិតភារកិច្ចនៃភាពឆបគ្នា kABI ដោយប្រុងប្រយ័ត្នជាងមុន។ ពួកគេផ្តល់នូវភាពឆបគ្នា kABI តែនៅក្នុងកញ្ចប់សេវាកម្មមួយ។

ជាឧទាហរណ៍ ការចេញផ្សាយ SLES 12 បានធ្វើឡើងក្នុងខែកញ្ញា ឆ្នាំ 2014។ ហើយ SLES 12 SP1 គឺរួចហើយនៅក្នុងខែធ្នូ ឆ្នាំ 2015 ពោលគឺជាងមួយឆ្នាំបានកន្លងផុតទៅហើយ។ ទោះបីជាការចេញផ្សាយទាំងពីរប្រើខឺណែល 3.12 ក៏ដោយក៏ kABI មិនឆបគ្នាដែរ។ ជាក់ស្តែង ការរក្សាភាពឆបគ្នារបស់ kABI ត្រឹមតែមួយឆ្នាំគឺងាយស្រួលជាង។ វដ្តនៃការធ្វើបច្ចុប្បន្នភាពម៉ូឌុលខឺណែលប្រចាំឆ្នាំមិនគួរបង្កបញ្ហាសម្រាប់អ្នកបង្កើតម៉ូឌុលទេ។

ជាលទ្ធផលនៃគោលការណ៍ SUSE នេះ យើងមិនបានកត់ត្រាបញ្ហាតែមួយជាមួយនឹងភាពឆបគ្នា kABI នៅក្នុងម៉ូឌុល veeamsnap របស់យើងទេ។ ពិត ចំនួនកញ្ចប់សម្រាប់ SUSE គឺស្ទើរតែជាលំដាប់នៃទំហំធំជាង។

បំណះ និង backports

ទោះបីជាអ្នកចែកចាយព្យាយាមធានានូវភាពឆបគ្នា kABI និងស្ថេរភាពខឺណែលក៏ដោយ ក៏ពួកគេព្យាយាមធ្វើឱ្យប្រសើរឡើងនូវការអនុវត្ត និងលុបបំបាត់ពិការភាពនៃខឺណែលដែលមានស្ថេរភាពនេះ។

ក្នុងពេលជាមួយគ្នានេះ បន្ថែមពីលើ "ការងារលើកំហុស" ផ្ទាល់ខ្លួនរបស់ពួកគេ អ្នកអភិវឌ្ឍន៍នៃសហគ្រាសលីនុច ម៉ូនីទ័រខឺណែលផ្លាស់ប្តូរនៅក្នុងខឺណែល vanilla និងផ្ទេរពួកវាទៅ "ស្ថេរភាព" របស់ពួកគេ។

ពេលខ្លះវានាំទៅរកអ្នកថ្មី។ កំហុស.

នៅក្នុងការចេញផ្សាយចុងក្រោយរបស់ Red Hat 6 មានកំហុសមួយបានកើតឡើងនៅក្នុងការអាប់ដេតតិចតួចមួយ។ វានាំឱ្យការពិតដែលថាម៉ូឌុល veeamsnap ត្រូវបានធានាថានឹងគាំងប្រព័ន្ធនៅពេលដែលរូបថតត្រូវបានចេញផ្សាយ។ ដោយបានប្រៀបធៀបប្រភពខឺណែលមុន និងបន្ទាប់ពីការអាប់ដេត យើងបានរកឃើញថា backport គឺត្រូវស្តីបន្ទោស។ ការជួសជុលស្រដៀងគ្នានេះត្រូវបានធ្វើឡើងនៅក្នុងខឺណែល vanilla កំណែ 4.19 ។ វាគ្រាន់តែថាការជួសជុលនេះដំណើរការបានល្អនៅក្នុងខឺណែល vanilla ប៉ុន្តែនៅពេលផ្ទេរវាទៅ "ស្ថេរភាព" 2.6.32 បញ្ហាបានកើតឡើងជាមួយ spinlock ។

ជាការពិតណាស់ មនុស្សគ្រប់រូបតែងតែមានកំហុស ប៉ុន្តែតើវាសមនឹងការអូសកូដពី 4.19 ទៅ 2.6.32 ប្រថុយនឹងស្ថេរភាពដែរឬទេ?... ខ្ញុំមិនប្រាកដទេ...

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

នៅពេលខ្ញុំព្យាយាមបង្កើតម៉ូឌុលនៅលើខឺណែល 4.4 ពី SLES 12 SP3 ខ្ញុំមានការភ្ញាក់ផ្អើលក្នុងការស្វែងរកមុខងារពី vanilla 4.8 នៅក្នុងវា។ តាមគំនិតរបស់ខ្ញុំ ការអនុវត្តប្លុក I/O នៃខឺណែល 4.4 ពី SLES 12 SP3 គឺស្រដៀងទៅនឹងខឺណែល 4.8 ជាងការចេញផ្សាយមុននៃខឺណែល 4.4 ដែលមានស្ថេរភាពពី SLES12 SP2 ។ ខ្ញុំមិនអាចវិនិច្ឆ័យថាតើភាគរយនៃលេខកូដត្រូវបានផ្ទេរពីខឺណែល 4.8 ទៅ SLES 4.4 សម្រាប់ SP3 នោះទេ ប៉ុន្តែខ្ញុំមិនអាចហៅខឺណែលថា 4.4 ដែលមានស្ថេរភាពដូចគ្នានោះទេ។

អ្វី​ដែល​មិន​សប្បាយចិត្ត​បំផុត​គឺ​នៅពេល​សរសេរ​ម៉ូឌុល​ដែល​អាច​ដំណើរការ​បានល្អ​ដូចគ្នា​នៅលើ​ខឺណែល​ផ្សេងៗ អ្នក​មិនអាច​ពឹងផ្អែក​លើ​កំណែ​ខឺណែល​បាន​ទៀតទេ។ អ្នកក៏ត្រូវយកទៅក្នុងគណនីចែកចាយផងដែរ។ វាជាការល្អដែលពេលខ្លះអ្នកអាចចូលរួមក្នុងនិយមន័យដែលលេចឡើងរួមជាមួយមុខងារថ្មី ប៉ុន្តែឱកាសនេះមិនតែងតែលេចឡើងទេ។

ជាលទ្ធផល កូដកាន់តែធំឡើងជាមួយនឹងការណែនាំអំពីការចងក្រងតាមលក្ខខណ្ឌចំលែក។

វាក៏មានបំណះដែលផ្លាស់ប្តូរ API ខឺណែលដែលបានចងក្រងឯកសារផងដែរ។
ខ្ញុំបានឆ្លងកាត់ការចែកចាយ KDE neon 5.16 ហើយមានការភ្ញាក់ផ្អើលយ៉ាងខ្លាំងដែលឃើញការហៅ lookup_bdev នៅក្នុងកំណែខឺណែលនេះបានផ្លាស់ប្តូរបញ្ជីប៉ារ៉ាម៉ែត្របញ្ចូល។

ដើម្បីទទួលបានវាជាមួយគ្នា ខ្ញុំត្រូវបន្ថែមស្គ្រីបទៅ makefile ដែលពិនិត្យមើលថាតើមុខងារ lookup_bdev មានប៉ារ៉ាម៉ែត្ររបាំងដែរឬទេ។

ការចុះហត្ថលេខាលើម៉ូឌុលខឺណែល

ប៉ុន្តែសូមត្រលប់ទៅបញ្ហានៃការចែកចាយកញ្ចប់។

គុណសម្បត្តិមួយនៃ kABI ស្ថេរភាពគឺថាម៉ូឌុលខឺណែលអាចត្រូវបានចុះហត្ថលេខាជាឯកសារគោលពីរ។ ក្នុងករណីនេះ អ្នកអភិវឌ្ឍន៍អាចប្រាកដថាម៉ូឌុលមិនត្រូវបានខូចខាតដោយចៃដន្យ ឬកែប្រែដោយចេតនា។ អ្នកអាចពិនិត្យមើលវាដោយប្រើពាក្យបញ្ជា modinfo ។

ការចែកចាយ Red Hat និង SUSE អនុញ្ញាតឱ្យអ្នកពិនិត្យមើលហត្ថលេខារបស់ម៉ូឌុល ហើយផ្ទុកវាបានលុះត្រាតែវិញ្ញាបនបត្រដែលត្រូវគ្នាត្រូវបានចុះឈ្មោះនៅលើប្រព័ន្ធ។ វិញ្ញាបនបត្រគឺជាសោសាធារណៈដែលម៉ូឌុលត្រូវបានចុះហត្ថលេខា។ យើងចែកចាយវាជាកញ្ចប់ដាច់ដោយឡែក។

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

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

EFI នៅលើម៉ាស៊ីននិម្មិត

ទោះបីជាការពិតដែលថា EFI ត្រូវបានគាំទ្រជាយូរមកហើយដោយក្រុមហ៊ុនផលិត motherboard ស្ទើរតែទាំងអស់នៅពេលដំឡើងប្រព័ន្ធអ្នកគ្រប់គ្រងប្រហែលជាមិនគិតអំពីតម្រូវការសម្រាប់ EFI ទេហើយវាអាចត្រូវបានបិទ។

មិនមែនអ្នកមើលការខុសត្រូវទាំងអស់គាំទ្រ EFI ទេ។ VMWare vSphere គាំទ្រ EFI ចាប់ផ្តើមពីកំណែ 5 ។
Microsoft Hyper-V ក៏ទទួលបានការគាំទ្រ EFI ដោយចាប់ផ្តើមជាមួយ Hyper-V សម្រាប់ Windows Server 2012R2 ។

ទោះយ៉ាងណាក៏ដោយ នៅក្នុងការកំណត់លំនាំដើម មុខងារនេះត្រូវបានបិទសម្រាប់ម៉ាស៊ីនលីនុច ដែលមានន័យថាវិញ្ញាបនបត្រមិនអាចដំឡើងបានទេ។

នៅក្នុង vSphere 6.5 កំណត់ជម្រើស ចាប់ផ្ដើមសុវត្ថិភាព អាចធ្វើទៅបានតែនៅក្នុងកំណែចាស់នៃចំណុចប្រទាក់បណ្ដាញដែលដំណើរការតាមរយៈ Flash ។ Web UI លើ HTML-5 នៅ​តែ​នៅ​ឆ្ងាយ។

ការចែកចាយពិសោធន៍

ហើយជាចុងក្រោយ ចូរយើងពិចារណាអំពីបញ្ហានៃការចែកចាយពិសោធន៍ និងការចែកចាយដោយគ្មានការគាំទ្រជាផ្លូវការ។ ម៉្យាងវិញទៀតការចែកចាយបែបនេះទំនងជាមិនត្រូវបានរកឃើញនៅលើម៉ាស៊ីនមេនៃអង្គការធ្ងន់ធ្ងរនោះទេ។ មិនមានការគាំទ្រជាផ្លូវការសម្រាប់ការចែកចាយបែបនេះទេ។ ដូច្នេះ​សូម​ផ្តល់​ឱ្យ​។ ផលិតផលមិនអាចត្រូវបានគាំទ្រលើការចែកចាយបែបនេះទេ។

ទោះជាយ៉ាងណាក៏ដោយ ការចែកចាយបែបនេះក្លាយជាវេទិកាងាយស្រួលសម្រាប់ការសាកល្បងដំណោះស្រាយពិសោធន៍ថ្មី។ ឧទាហរណ៍ Fedora, OpenSUSE Tumbleweed ឬកំណែមិនស្ថិតស្ថេរនៃ Debian ។ ពួកគេមានស្ថេរភាពណាស់។ ពួកគេតែងតែមានកំណែថ្មីនៃកម្មវិធី និងតែងតែជាខឺណែលថ្មី។ ក្នុងមួយឆ្នាំ មុខងារពិសោធន៍នេះអាចបញ្ចប់នៅក្នុង RHEL, SLES ឬ Ubuntu ដែលបានធ្វើបច្ចុប្បន្នភាព។

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

អ្នកអាចសិក្សាបញ្ជីបច្ចុប្បន្ននៃការចែកចាយដែលគាំទ្រជាផ្លូវការសម្រាប់កំណែ 3.0 នៅទីនេះ. ប៉ុន្តែបញ្ជីពិតប្រាកដនៃការចែកចាយដែលផលិតផលរបស់យើងអាចដំណើរការបានគឺកាន់តែទូលំទូលាយ។

ដោយផ្ទាល់ ខ្ញុំចាប់អារម្មណ៍លើការពិសោធន៍ជាមួយ Elbrus OS។ បន្ទាប់ពីបញ្ចប់កញ្ចប់ veeam ផលិតផលរបស់យើងត្រូវបានដំឡើង និងដំណើរការ។ ខ្ញុំបានសរសេរអំពីការពិសោធន៍នេះនៅលើ Habre in អត្ថបទ.

ជាការប្រសើរណាស់ ការគាំទ្រសម្រាប់ការចែកចាយថ្មីនៅតែបន្ត។ យើងកំពុងរង់ចាំកំណែ 4.0 ដែលត្រូវបានចេញផ្សាយ។ បេតា​ហៀបនឹង​បង្ហាញ​ខ្លួន ដូច្នេះ​សូម​ចាំ​មើល តើមានអ្វីថ្មី?!

ប្រភព: www.habr.com