One-cloud - កម្រិតមជ្ឈមណ្ឌលទិន្នន័យ OS នៅក្នុង Odnoklassniki

អាឡូហា មនុស្ស! ឈ្មោះរបស់ខ្ញុំគឺ Oleg Anastasyev ខ្ញុំធ្វើការនៅ Odnoklassniki នៅក្នុងក្រុមវេទិកា។ ហើយក្រៅពីខ្ញុំ មានផ្នែករឹងជាច្រើនដែលធ្វើការនៅក្នុង Odnoklassniki ។ យើង​មាន​មជ្ឈមណ្ឌល​ទិន្នន័យ​ចំនួន 500 ដែល​មាន​ប្រហែល 8 racks ជាមួយ​នឹង servers ជាង XNUMX ពាន់។ នៅចំណុចជាក់លាក់មួយ យើងបានដឹងថាការដាក់ឱ្យប្រើប្រាស់ប្រព័ន្ធគ្រប់គ្រងថ្មីនឹងអនុញ្ញាតឱ្យយើងផ្ទុកឧបករណ៍កាន់តែមានប្រសិទ្ធភាព ជួយសម្រួលដល់ការគ្រប់គ្រងការចូលប្រើប្រាស់ ធ្វើឱ្យការចែកចាយធនធានកុំព្យូទ័រដោយស្វ័យប្រវត្តិ (ឡើងវិញ) បង្កើនល្បឿននៃការចាប់ផ្តើមសេវាកម្មថ្មី និងបង្កើនល្បឿនការឆ្លើយតប។ ដល់គ្រោះថ្នាក់ទ្រង់ទ្រាយធំ។

តើវាមកពីអ្វី?

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

សំណើរបស់អ្នកប្រើត្រូវបានទទួលទាំងនៅផ្នែកខាងមុខនៃវិបផតថលមេ www.ok.ruនិងនៅលើផ្សេងទៀត ឧទាហរណ៍នៅលើផ្នែកខាងមុខ API តន្ត្រី។ ដើម្បីដំណើរការតក្កវិជ្ជាអាជីវកម្ម ពួកគេហៅម៉ាស៊ីនមេកម្មវិធី ដែលនៅពេលដំណើរការសំណើ ហៅសេវាកម្មមីក្រូឯកទេសចាំបាច់ - ក្រាហ្វមួយ (ក្រាហ្វនៃទំនាក់ទំនងសង្គម) ឃ្លាំងសម្ងាត់អ្នកប្រើប្រាស់ (ឃ្លាំងសម្ងាត់នៃទម្រង់អ្នកប្រើប្រាស់) ជាដើម។

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

ហេតុអ្វីបានជា​អញ្ចឹង? វិធីសាស្រ្តនេះមានអត្ថប្រយោជន៍ជាច្រើន៖

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

សេវាកម្មដែលមានការចម្លងជាច្រើនត្រូវបានបែងចែកម៉ាស៊ីនមេជាច្រើន - មួយសម្រាប់នីមួយៗ។ បន្ទាប់មកធនធានកុំព្យូទ័រសម្រាប់សេវាកម្មត្រូវបានបែងចែកយ៉ាងសាមញ្ញ៖ ចំនួនម៉ាស៊ីនមេដែលសេវាកម្មមាន ចំនួនអតិបរមានៃធនធានដែលវាអាចប្រើប្រាស់បាន។ “ងាយស្រួល” នៅទីនេះមិនមានន័យថាវាងាយស្រួលប្រើនោះទេ ប៉ុន្តែក្នុងន័យថាការបែងចែកធនធានត្រូវបានធ្វើឡើងដោយដៃ។

វិធីសាស្រ្តនេះក៏អនុញ្ញាតឱ្យយើងធ្វើផងដែរ។ ការកំណត់រចនាសម្ព័ន្ធដែកឯកទេស សម្រាប់កិច្ចការដែលកំពុងដំណើរការនៅលើម៉ាស៊ីនមេនេះ។ ប្រសិនបើកិច្ចការរក្សាទុកទិន្នន័យច្រើន នោះយើងប្រើម៉ាស៊ីនមេ 4U ដែលមានតួដែលមាន 38 ថាស។ ប្រសិនបើភារកិច្ចគឺការគណនាសុទ្ធសាធ នោះយើងអាចទិញម៉ាស៊ីនមេ 1U ដែលមានតម្លៃថោកជាង។ នេះមានប្រសិទ្ធភាពក្នុងការគណនា។ ក្នុងចំណោមរបស់ផ្សេងទៀត វិធីសាស្រ្តនេះអនុញ្ញាតឱ្យយើងប្រើម៉ាស៊ីនតិចជាង XNUMX ដងជាមួយនឹងបន្ទុកដែលប្រៀបធៀបទៅនឹងបណ្តាញសង្គមដ៏រួសរាយមួយ។

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

ដោយដឹងថានេះជាករណីនេះ យើងបានសម្រេចចិត្តដើម្បីគណនាថាតើយើងកំពុងប្រើរ៉ាកែតប្រកបដោយប្រសិទ្ធភាពប៉ុណ្ណា។
យើងបានយកតម្លៃនៃម៉ាស៊ីនមេដ៏មានឥទ្ធិពលបំផុតពីម៉ាស៊ីនមេដែលសមហេតុផលខាងសេដ្ឋកិច្ច ដោយបានគណនាថាតើម៉ាស៊ីនមេបែបនេះចំនួនប៉ុន្មានដែលយើងអាចដាក់ក្នុង racks កិច្ចការប៉ុន្មានដែលយើងនឹងដំណើរការលើពួកវាដោយផ្អែកលើគំរូចាស់ "ម៉ាស៊ីនមេមួយ = កិច្ចការមួយ" និងចំនួនប៉ុន្មាន ភារកិច្ចបែបនេះអាចប្រើឧបករណ៍។ ពួកគេបានរាប់ហើយស្រក់ទឹកភ្នែក។ វាបានប្រែក្លាយថាប្រសិទ្ធភាពរបស់យើងក្នុងការប្រើប្រាស់ rack គឺប្រហែល 11% ។ ការសន្និដ្ឋានគឺជាក់ស្តែង៖ យើងត្រូវបង្កើនប្រសិទ្ធភាពនៃការប្រើប្រាស់មជ្ឈមណ្ឌលទិន្នន័យ។ វាហាក់ដូចជាថាដំណោះស្រាយគឺជាក់ស្តែង៖ អ្នកត្រូវដំណើរការកិច្ចការជាច្រើននៅលើម៉ាស៊ីនមេតែមួយក្នុងពេលតែមួយ។ ប៉ុន្តែនេះគឺជាកន្លែងដែលការលំបាកចាប់ផ្តើម។

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

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

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

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

លើសពីនេះ បញ្ជីឈ្មោះ និងការដាក់ស្លាករូបភាពដែលត្រៀមរួចជាស្រេចនៅក្នុង Docker ផ្តល់ឱ្យយើងនូវបុព្វបទដែលត្រៀមរួចជាស្រេចសម្រាប់ការធ្វើកំណែ និងការបញ្ជូនកូដទៅផលិតកម្ម។

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

ការដំណើរការកុងតឺន័រដោយផ្ទាល់នៅលើម៉ាស៊ីនមេគឺគ្រាន់តែជាផ្នែកនៃបញ្ហាប៉ុណ្ណោះ។ ផ្នែកផ្សេងទៀតគឺទាក់ទងទៅនឹងការបង្ហោះកុងតឺន័រនៅលើម៉ាស៊ីនមេ។ អ្នក​ត្រូវ​យល់​ថា​កុងតឺន័រ​មួយ​ណា​អាច​ត្រូវ​បាន​ដាក់​នៅ​លើ​ម៉ាស៊ីន​មេ​មួយ​ណា។ នេះមិនមែនជាកិច្ចការងាយស្រួលនោះទេ ព្រោះកុងតឺន័រត្រូវដាក់នៅលើម៉ាស៊ីនមេឱ្យបានក្រាស់តាមដែលអាចធ្វើទៅបានដោយមិនបន្ថយល្បឿនរបស់វា។ ការដាក់បែបនេះក៏អាចមានការពិបាកពីទស្សនៈនៃការអត់ឱនចំពោះកំហុសផងដែរ។ ជាញឹកញាប់យើងចង់ដាក់ការចម្លងនៃសេវាកម្មដូចគ្នានៅក្នុង racks ផ្សេងគ្នា ឬសូម្បីតែនៅក្នុងបន្ទប់ផ្សេងគ្នានៃមជ្ឈមណ្ឌលទិន្នន័យ ដូច្នេះប្រសិនបើ rack ឬបន្ទប់បរាជ័យ យើងមិនបាត់បង់សេវាកម្មចម្លងទាំងអស់ភ្លាមៗនោះទេ។

ការចែកចាយកុងតឺន័រដោយដៃមិនមែនជាជម្រើសទេនៅពេលដែលអ្នកមានម៉ាស៊ីនមេ 8 ពាន់ និងកុងតឺន័រ 8-16 ពាន់។

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

ជាក់ស្តែង យើងត្រូវការស្រទាប់គ្រប់គ្រង ដែលនឹងធ្វើវាដោយស្វ័យប្រវត្តិ។

ដូច្នេះយើងបានមកដល់រូបភាពដ៏សាមញ្ញ និងអាចយល់បានដែលស្ថាបត្យករទាំងអស់ចូលចិត្ត៖ ការ៉េបី។

one-cloud masters គឺជាចង្កោមបរាជ័យដែលទទួលខុសត្រូវចំពោះការរៀបចំពពក។ អ្នក​អភិវឌ្ឍន៍​ផ្ញើ​ manifest មួយ​ទៅ​មេ​ដែល​មាន​ព័ត៌មាន​ទាំងអស់​ដែល​ចាំបាច់​ដើម្បី​រៀបចំ​សេវាកម្ម។ ដោយផ្អែកលើវា មេផ្តល់ពាក្យបញ្ជាដល់ minions ដែលបានជ្រើសរើស (ម៉ាស៊ីនដែលត្រូវបានរចនាឡើងដើម្បីដំណើរការកុងតឺន័រ)។ Minions មានភ្នាក់ងាររបស់យើងដែលទទួលពាក្យបញ្ជា ចេញពាក្យបញ្ជារបស់វាទៅ Docker ហើយ Docker កំណត់រចនាសម្ព័ន្ធខឺណែល linux ដើម្បីបើកដំណើរការកុងតឺន័រដែលត្រូវគ្នា។ បន្ថែមពីលើការប្រតិបត្តិពាក្យបញ្ជា ភ្នាក់ងារបន្តរាយការណ៍ទៅមេអំពីការផ្លាស់ប្តូរស្ថានភាពទាំងម៉ាស៊ីន minion និងកុងតឺន័រដែលកំពុងដំណើរការលើវា។

ការបែងចែកធនធាន

ឥឡូវនេះសូមក្រឡេកមើលបញ្ហានៃការបែងចែកធនធានដ៏ស្មុគស្មាញសម្រាប់ minions ជាច្រើន។

ធនធានកុំព្យូទ័រក្នុងពពកតែមួយគឺ៖

• បរិមាណនៃថាមពលខួរក្បាលប្រើប្រាស់ដោយកិច្ចការជាក់លាក់មួយ។
• ចំនួនអង្គចងចាំដែលមានសម្រាប់កិច្ចការ។
• ចរាចរណ៍បណ្តាញ។ minions នីមួយៗមានចំណុចប្រទាក់បណ្តាញជាក់លាក់ជាមួយនឹងកម្រិតបញ្ជូនមានកម្រិត ដូច្នេះវាមិនអាចទៅរួចទេក្នុងការចែកចាយកិច្ចការដោយមិនគិតពីចំនួនទិន្នន័យដែលពួកគេបញ្ជូនតាមបណ្តាញ។
• ថាស។ លើសពីនេះទៀតជាក់ស្តែងចំពោះកន្លែងទំនេរសម្រាប់កិច្ចការទាំងនេះយើងក៏បែងចែកប្រភេទនៃថាសផងដែរ: HDD ឬ SSD ។ ថាសអាចបម្រើសំណើចំនួនកំណត់ក្នុងមួយវិនាទី - IOPS ។ ដូច្នេះសម្រាប់កិច្ចការដែលបង្កើត IOPS ច្រើនជាងថាសតែមួយអាចដោះស្រាយបាន យើងក៏បែងចែក "spindles" - នោះគឺឧបករណ៍ថាសដែលត្រូវតែបម្រុងទុកសម្រាប់ភារកិច្ច។

បន្ទាប់មកសម្រាប់សេវាកម្មមួយចំនួន ឧទាហរណ៍សម្រាប់ user-cache យើងអាចកត់ត្រាធនធានដែលប្រើប្រាស់តាមរបៀបនេះ៖ 400 processor cores, 2,5 TB of memory, 50 Gbit/s traffic ក្នុងទិសដៅទាំងពីរ, ទំហំ HDD 6 TB ដែលមានទីតាំងនៅលើ spindles 100 ។ ឬក្នុងទម្រង់ដែលគេស្គាល់ច្រើនជាងនេះ៖

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

ចូរយើងត្រលប់ទៅដ្យាក្រាមដែលសាមញ្ញបំផុតរបស់យើងអំពីអន្តរកម្មនៃសមាសធាតុ ហើយគូរវាឡើងវិញជាមួយនឹងព័ត៌មានលម្អិតបន្ថែមទៀត - ដូចនេះ៖

អ្វីដែលទាក់ទាញភ្នែករបស់អ្នក៖

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

តោះគូររូបម្តងទៀត៖

បា! បាទ យើងឃើញឋានានុក្រម! នេះមានន័យថាអ្នកអាចចែកចាយធនធានជាផ្នែកធំៗ៖ កំណត់អ្នកអភិវឌ្ឍន៍ដែលមានទំនួលខុសត្រូវទៅកាន់ថ្នាំងនៃឋានានុក្រមនេះដែលត្រូវនឹងប្រព័ន្ធរងដែលមានមុខងារ (ដូចជា "តន្ត្រី" នៅក្នុងរូបភាព) ហើយភ្ជាប់កូតាទៅកម្រិតដូចគ្នានៃឋានានុក្រម។ ឋានានុក្រមនេះក៏អនុញ្ញាតឱ្យយើងរៀបចំសេវាកម្មកាន់តែមានភាពបត់បែន ដើម្បីភាពងាយស្រួលនៃការគ្រប់គ្រង។ ឧទាហរណ៍ យើងបែងចែកបណ្តាញទាំងអស់ ដោយហេតុថា នេះគឺជាក្រុមធំនៃម៉ាស៊ីនមេ ទៅជាក្រុមតូចៗជាច្រើន ដែលបង្ហាញក្នុងរូបភាពជាក្រុមទី 1 ក្រុមទី 2 ។

ដោយ​ដក​បន្ទាត់​បន្ថែម​ចេញ យើង​អាច​សរសេរ​ថ្នាំង​នីមួយៗ​នៃ​រូបភាព​របស់​យើង​ក្នុង​ទម្រង់​ជា​ពាក្យ​ចែចង់​មួយ៖ group1.web.front, api.music.front, user-cache.cache.

នេះជារបៀបដែលយើងមកដល់គំនិតនៃ "ជួរឋានានុក្រម" ។ វាមានឈ្មោះដូចជា "group1.web.front" ។ កូតាសម្រាប់ធនធាន និងសិទ្ធិអ្នកប្រើប្រាស់ត្រូវបានផ្តល់ទៅឱ្យវា។ យើងនឹងផ្តល់ឱ្យបុគ្គលពី DevOps នូវសិទ្ធិក្នុងការផ្ញើសេវាកម្មទៅជួរ ហើយបុគ្គលិកបែបនេះអាចចាប់ផ្តើមអ្វីមួយនៅក្នុងជួរ ហើយបុគ្គលមកពី OpsDev នឹងមានសិទ្ធិគ្រប់គ្រង ហើយឥឡូវនេះគាត់អាចគ្រប់គ្រងជួរ ចាត់តាំងមនុស្សនៅទីនោះ។ ផ្តល់សិទ្ធិដល់មនុស្សទាំងនេះ។ល។ សេវាកម្មដែលកំពុងដំណើរការលើជួរនេះនឹងដំណើរការក្នុងកូតារបស់ជួរ។ ប្រសិនបើកូតាគណនារបស់ជួរមិនគ្រប់គ្រាន់ដើម្បីប្រតិបត្តិសេវាកម្មទាំងអស់ក្នុងពេលតែមួយ នោះពួកវានឹងត្រូវបានប្រតិបត្តិតាមលំដាប់លំដោយ ដូច្នេះបង្កើតជួរដោយខ្លួនឯង។

ចូរយើងពិនិត្យមើលឱ្យកាន់តែច្បាស់អំពីសេវាកម្ម។ សេវាកម្មមានឈ្មោះពេញសិទ្ធិ ដែលតែងតែរួមបញ្ចូលឈ្មោះជួរ។ បន្ទាប់មកសេវាគេហទំព័រខាងមុខនឹងមានឈ្មោះ ok-web.group1.web.front. ហើយសេវាកម្មម៉ាស៊ីនមេកម្មវិធីដែលវាចូលប្រើនឹងត្រូវបានហៅ ok-app.group1.web.front. សេវាកម្មនីមួយៗមាន manifest ដែលបញ្ជាក់ពីព័ត៌មានចាំបាច់ទាំងអស់សម្រាប់ការដាក់នៅលើម៉ាស៊ីនជាក់លាក់៖ តើត្រូវប្រើប្រាស់ធនធានប៉ុន្មាន ការងារនេះត្រូវការអ្វីខ្លះ ការកំណត់រចនាសម្ព័ន្ធដែលត្រូវការសម្រាប់វា តើចំនួនចម្លងគួរមានប៉ុន្មាន លក្ខណៈសម្បត្តិសម្រាប់ដោះស្រាយការបរាជ័យនៃសេវាកម្មនេះ។ ហើយបន្ទាប់ពីសេវាកម្មត្រូវបានដាក់ដោយផ្ទាល់លើម៉ាស៊ីន នោះករណីរបស់វាលេចឡើង។ ពួកគេក៏ត្រូវបានគេដាក់ឈ្មោះដោយមិនច្បាស់លាស់ផងដែរ - ជាលេខឧទាហរណ៍ និងឈ្មោះសេវាកម្ម៖ 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

នេះគឺងាយស្រួលណាស់៖ ដោយមើលតែឈ្មោះកុងតឺន័រដែលកំពុងដំណើរការ យើងអាចដឹងបានភ្លាមៗ។

ឥឡូវនេះ សូមពិនិត្យមើលឱ្យកាន់តែច្បាស់នូវអ្វីដែលករណីទាំងនេះអនុវត្តជាក់ស្តែង៖ កិច្ចការ។

ថ្នាក់ដាច់ដោយឡែកពីការងារ

កិច្ចការទាំងអស់នៅក្នុង OK (ហើយប្រហែលជាគ្រប់ទីកន្លែង) អាចត្រូវបានបែងចែកជាក្រុម៖

• កិច្ចការ​ពន្យារ​ពេល​ខ្លី - ផលិតផល. សម្រាប់កិច្ចការ និងសេវាកម្មបែបនេះ ការពន្យាពេលការឆ្លើយតប (ភាពយឺតយ៉ាវ) គឺមានសារៈសំខាន់ខ្លាំងណាស់ តើសំណើនីមួយៗនឹងត្រូវបានដំណើរការដោយប្រព័ន្ធលឿនប៉ុណ្ណា។ ឧទាហរណ៍នៃកិច្ចការ៖ ផ្នែកខាងមុខគេហទំព័រ ឃ្លាំងសម្ងាត់ ម៉ាស៊ីនមេកម្មវិធី ការផ្ទុក OLTP ។ល។
• បញ្ហាក្នុងការគណនា - បាច់. នៅទីនេះល្បឿនដំណើរការនៃសំណើជាក់លាក់នីមួយៗមិនសំខាន់ទេ។ សម្រាប់ពួកគេ វាមានសារៈសំខាន់ថាតើការគណនាចំនួនប៉ុន្មានដែលកិច្ចការនេះនឹងធ្វើក្នុងរយៈពេលជាក់លាក់មួយ (រយៈពេលយូរ) នៃពេលវេលា (ឆ្លងកាត់)។ ទាំងនេះនឹងជាកិច្ចការណាមួយរបស់ MapReduce, Hadoop, machine learning, ស្ថិតិ។
• កិច្ចការផ្ទៃខាងក្រោយ - ទំនេរ. សម្រាប់កិច្ចការបែបនេះ ភាពយឺតយ៉ាវ ឬលំហូរចេញគឺមានសារៈសំខាន់ខ្លាំងណាស់។ នេះរួមបញ្ចូលទាំងការធ្វើតេស្តផ្សេងៗ ការធ្វើចំណាកស្រុក ការគណនាឡើងវិញ និងការបំប្លែងទិន្នន័យពីទម្រង់មួយទៅទម្រង់មួយទៀត។ ម៉្យាងវិញទៀត ពួកវាស្រដៀងនឹងការគណនា ម្យ៉ាងវិញទៀតវាមិនសំខាន់ចំពោះយើងទេថាតើពួកវាបញ្ចប់លឿនប៉ុណ្ណា។

សូមមើលពីរបៀបដែលកិច្ចការបែបនេះប្រើប្រាស់ធនធាន ឧទាហរណ៍ ដំណើរការកណ្តាល។

កិច្ចការពន្យាពេលខ្លី។ កិច្ចការបែបនេះនឹងមានលំនាំការប្រើប្រាស់ស៊ីភីយូស្រដៀងនឹងនេះ៖

សំណើពីអ្នកប្រើប្រាស់ត្រូវបានទទួលសម្រាប់ដំណើរការ កិច្ចការចាប់ផ្តើមប្រើស្នូលស៊ីភីយូដែលមានទាំងអស់ ដំណើរការវា ត្រឡប់ការឆ្លើយតប រង់ចាំសំណើបន្ទាប់ ហើយឈប់។ សំណើបន្ទាប់បានមកដល់ - ជាថ្មីម្តងទៀតយើងបានជ្រើសរើសអ្វីគ្រប់យ៉ាងដែលនៅទីនោះ គណនាវា ហើយកំពុងរង់ចាំបន្ទាប់ទៀត។

ដើម្បីធានាភាពយឺតយ៉ាវអប្បបរមាសម្រាប់កិច្ចការបែបនេះ យើងត្រូវយកធនធានអតិបរមាដែលវាប្រើប្រាស់ និងបម្រុងទុកចំនួនស្នូលដែលត្រូវការនៅលើ minion (ម៉ាស៊ីនដែលនឹងប្រតិបត្តិភារកិច្ច) ។ បន្ទាប់មករូបមន្តកក់សម្រាប់បញ្ហារបស់យើងនឹងមានដូចខាងក្រោម:

alloc: cpu = 4 (max)

ហើយប្រសិនបើយើងមានម៉ាស៊ីន minion ដែលមាន 16 cores នោះការងារបែបនេះចំនួន XNUMX អាចត្រូវបានដាក់នៅលើវា។ យើងកត់សំគាល់ជាពិសេសថាការប្រើប្រាស់ខួរក្បាលជាមធ្យមនៃកិច្ចការបែបនេះច្រើនតែមានកម្រិតទាប - ដែលជាក់ស្តែង ដោយសារផ្នែកសំខាន់នៃពេលវេលាដែលកិច្ចការរង់ចាំការស្នើសុំហើយមិនធ្វើអ្វីសោះ។

ភារកិច្ចគណនា។ លំនាំរបស់ពួកគេនឹងខុសគ្នាបន្តិចបន្តួច៖

ការប្រើប្រាស់ធនធាន CPU ជាមធ្យមសម្រាប់កិច្ចការបែបនេះគឺខ្ពស់ណាស់។ ជាញឹកញយ យើងចង់ឱ្យកិច្ចការគណនាបញ្ចប់ក្នុងចំនួនពេលវេលាជាក់លាក់មួយ ដូច្នេះយើងត្រូវបម្រុងទុកចំនួនអប្បបរមានៃ processors ដែលវាត្រូវការ ដើម្បីឱ្យការគណនាទាំងមូលត្រូវបានបញ្ចប់ក្នុងពេលវេលាដែលអាចទទួលយកបាន។ រូបមន្តកក់ទុករបស់វានឹងមើលទៅដូចនេះ៖

alloc: cpu = [1,*)

"សូមដាក់វានៅលើ minion ដែលយ៉ាងហោចណាស់មានស្នូលទំនេរមួយ ហើយបន្ទាប់មកតាមដែលមាន វានឹងលេបត្របាក់អ្វីៗទាំងអស់។"

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

ប៉ុន្ដែតើត្រូវធ្វើយ៉ាងម៉េច?

ជាដំបូង សូមក្រឡេកមើល prod និង alloc របស់វា៖ cpu = 4. យើងត្រូវកក់បួនស្នូល។ នៅក្នុងដំណើរការ Docker នេះអាចត្រូវបានធ្វើតាមពីរវិធី៖

• ជាមួយជម្រើស --cpuset=1-4ឧ. បែងចែកស្នូលជាក់លាក់ចំនួនបួននៅលើម៉ាស៊ីនទៅនឹងកិច្ចការ។
• Использовать --cpuquota=400_000 --cpuperiod=100_000កំណត់កូតាសម្រាប់ម៉ោងដំណើរការ ពោលគឺបង្ហាញថារាល់ 100 ms នៃពេលវេលាពិត កិច្ចការប្រើប្រាស់មិនលើសពី 400 ms នៃពេលវេលាដំណើរការ។ ស្នូលបួនដូចគ្នាត្រូវបានទទួល។

ប៉ុន្តែ តើ​វិធីសាស្ត្រ​មួយ​ណា​ដែល​សម​ស្រប?

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

ចូរយើងស្វែងយល់ពីរបៀបធ្វើការកក់ទុកនៅក្នុង Docker ដោយផ្អែកលើចំនួនស្នូលអប្បបរមា។ កូតា​សម្រាប់​កិច្ចការ​បាច់​គឺ​មិន​អាច​អនុវត្ត​បាន​ទៀត​ទេ ព្រោះ​មិន​ចាំបាច់​កំណត់​អតិបរមា​ទេ វា​គ្រប់គ្រាន់​ដើម្បី​ធានា​អប្បបរមា។ ហើយនៅទីនេះជម្រើសគឺសមល្អ។ docker run --cpushares.

យើងបានយល់ព្រមថាប្រសិនបើបាច់មួយទាមទារការធានាយ៉ាងហោចណាស់ស្នូលមួយ នោះយើងបង្ហាញ --cpushares=1024ហើយប្រសិនបើមានស្នូលពីរ នោះយើងបង្ហាញ --cpushares=2048. ការចែករំលែក Cpu មិនជ្រៀតជ្រែកក្នុងវិធីណាមួយជាមួយនឹងការចែកចាយពេលវេលាដំណើរការទេ ដរាបណាមានវាគ្រប់គ្រាន់។ ដូច្នេះ ប្រសិនបើ prod បច្ចុប្បន្នមិនប្រើស្នូលទាំងបួនរបស់វាទេនោះ គ្មានអ្វីកំណត់កិច្ចការបាច់ទេ ហើយពួកគេអាចប្រើពេលវេលាដំណើរការបន្ថែម។ ប៉ុន្តែនៅក្នុងស្ថានភាពដែលមានការខ្វះខាតនៃ processors ប្រសិនបើ prod បានប្រើប្រាស់ស្នូលទាំងបួនរបស់វា ហើយបានដល់កូតារបស់វានោះ ពេលវេលាដំណើរការដែលនៅសល់នឹងត្រូវបានបែងចែកតាមសមាមាត្រទៅនឹង cpushares ពោលគឺនៅក្នុងស្ថានភាពនៃ cores សេរីចំនួនបី មួយនឹងត្រូវបាន បានផ្តល់ទៅឱ្យកិច្ចការដែលមាន 1024 cpushares ហើយពីរដែលនៅសល់នឹងត្រូវបានផ្តល់ឱ្យទៅភារកិច្ចដែលមាន 2048 cpushares ។

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

• SCHED_OTHER
  តាមលំនាំដើម ដំណើរការអ្នកប្រើប្រាស់ធម្មតាទាំងអស់នៅលើម៉ាស៊ីនលីនុចទទួលបាន។
• SCHED_BATCH
  រចនាឡើងសម្រាប់ដំណើរការដែលពឹងផ្អែកលើធនធាន។ នៅពេលដាក់កិច្ចការលើ processor អ្វីដែលគេហៅថាការពិន័យធ្វើឱ្យសកម្មត្រូវបានណែនាំ៖ កិច្ចការបែបនេះទំនងជាមិនសូវទទួលបានធនធានដំណើរការទេ ប្រសិនបើបច្ចុប្បន្នវាកំពុងត្រូវបានប្រើប្រាស់ដោយកិច្ចការជាមួយ SCHED_OTHER
• SCHED_IDLE
  ដំណើរការផ្ទៃខាងក្រោយដែលមានអទិភាពទាបបំផុត សូម្បីតែទាបជាង -19 ដ៏ស្រស់ស្អាតក៏ដោយ។ យើងប្រើបណ្ណាល័យប្រភពបើកចំហរបស់យើង។ one-nioដើម្បីកំណត់គោលការណ៍ចាំបាច់នៅពេលចាប់ផ្តើមកុងតឺន័រដោយការហៅទូរសព្ទ

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

ប៉ុន្តែទោះបីជាអ្នកមិនសរសេរកម្មវិធីនៅក្នុង Java ក៏ដោយក៏រឿងដូចគ្នាអាចត្រូវបានធ្វើដោយប្រើពាក្យបញ្ជា chrt:

chrt -i 0 $pid

ចូរសង្ខេបកម្រិតឯកោរបស់យើងទាំងអស់ទៅក្នុងតារាងតែមួយសម្រាប់ភាពច្បាស់លាស់៖

ថ្នាក់អ៊ីសូឡង់
Alloc ឧទាហរណ៍
ជម្រើសដំណើរការ Docker
sched_setscheduler chrt*

ផលិតផល
ស៊ីភីយូ = ៤
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

បាច់
ស៊ីភីយូ = [1, *)
--cpushares=1024
SCHED_BATCH

ទំនេរ
ស៊ីភីយូ = [2, *)
--cpushares=2048
SCHED_IDLE

*ប្រសិនបើអ្នកកំពុងធ្វើ chrt ពីខាងក្នុងកុងតឺន័រ អ្នកប្រហែលជាត្រូវការសមត្ថភាព sys_nice ពីព្រោះតាមលំនាំដើម Docker ដកសមត្ថភាពនេះចេញនៅពេលចាប់ផ្តើមកុងតឺន័រ។

ប៉ុន្តែការងារមិនត្រឹមតែប្រើប្រាស់ខួរក្បាលប៉ុណ្ណោះទេ ថែមទាំងចរាចរផងដែរ ដែលប៉ះពាល់ដល់ភាពយឺតយ៉ាវនៃកិច្ចការបណ្តាញ ច្រើនជាងការបែងចែកធនធានដំណើរការមិនត្រឹមត្រូវ។ ដូច្នេះហើយ យើងចង់ទទួលបានរូបភាពដូចគ្នាសម្រាប់ចរាចរណ៍។ នោះគឺនៅពេលដែលកិច្ចការ prod ផ្ញើកញ្ចប់មួយចំនួនទៅបណ្តាញ យើងកំណត់ល្បឿនអតិបរមា (រូបមន្ត alloc: lan = [*,500mbps) ) ជាមួយនឹងផលិតផលណាដែលអាចធ្វើវាបាន។ ហើយ​សម្រាប់​បាច់​យើង​ធានា​តែ​ការ​បញ្ជូន​អប្បបរមា​ប៉ុណ្ណោះ ប៉ុន្តែ​មិន​កំណត់​អតិបរមា (រូបមន្ត alloc: lan=[10Mbps,*) ) ក្នុងករណីនេះ ចរាចរណ៍ផលិតផលគួរតែទទួលបានអាទិភាពលើកិច្ចការជាបាច់។
នៅទីនេះ Docker មិនមានបុព្វបទណាមួយដែលយើងអាចប្រើបានទេ។ ប៉ុន្តែវាមកដល់ជំនួយរបស់យើង។ ការគ្រប់គ្រងចរាចរណ៍លីនុច. យើងអាចសម្រេចបាននូវលទ្ធផលដែលចង់បានដោយមានជំនួយពីវិន័យ ខ្សែកោងសេវាយុត្តិធម៌តាមឋានានុក្រម. ដោយមានជំនួយរបស់វា យើងបែងចែកប្រភេទចរាចរណ៍ពីរ៖ ផលិតផលដែលមានអាទិភាពខ្ពស់ និងបណ្តុំ/ទំនេរដែលមានអាទិភាពទាប។ ជាលទ្ធផល ការកំណត់រចនាសម្ព័ន្ធសម្រាប់ចរាចរណ៍ចេញគឺដូចនេះ៖

នៅទីនេះ 1:0 គឺជា "root qdisc" នៃវិន័យ hsfc; 1:1 - ថ្នាក់កុមារ hsfc ដែលមានកម្រិតបញ្ជូនសរុប 8 Gbit/s ដែលថ្នាក់កុមារនៃធុងទាំងអស់ត្រូវបានដាក់។ 1:2 - ថ្នាក់កុមារ hsfc គឺជារឿងធម្មតាសម្រាប់រាល់កិច្ចការជាបាច់ និងទំនេរដែលមានដែនកំណត់ "ថាមវន្ត" ដែលត្រូវបានពិភាក្សាខាងក្រោម។ ថ្នាក់កូន hsfc ដែលនៅសេសសល់គឺជាថ្នាក់ឧទ្ទិសសម្រាប់បច្ចុប្បន្នកំពុងដំណើរការកុងតឺន័រ prod ជាមួយនឹងដែនកំណត់ដែលត្រូវគ្នាទៅនឹងការបង្ហាញរបស់ពួកគេ - 450 និង 400 Mbit/s ។ ថ្នាក់ hsfc នីមួយៗត្រូវបានផ្តល់ជាជួរ qdisc fq ឬ fq_codel អាស្រ័យលើកំណែខឺណែលលីនុច ដើម្បីជៀសវាងការបាត់បង់កញ្ចប់ព័ត៌មានកំឡុងពេលចរាចរណ៍ផ្ទុះ។

ជាធម្មតា វិញ្ញាសា tc បម្រើដើម្បីផ្តល់អាទិភាពដល់ចរាចរណ៍ដែលចេញ។ ប៉ុន្តែយើងចង់ផ្តល់អាទិភាពដល់ចរាចរណ៍ចូលផងដែរ - បន្ទាប់ពីទាំងអស់ កិច្ចការបាច់មួយចំនួនអាចជ្រើសរើសឆានែលចូលទាំងមូលបានយ៉ាងងាយស្រួល ទទួលឧទាហរណ៍ បណ្តុំទិន្នន័យបញ្ចូលដ៏ធំសម្រាប់ផែនទី និងកាត់បន្ថយ។ សម្រាប់បញ្ហានេះយើងប្រើម៉ូឌុល ifbដែលបង្កើតចំណុចប្រទាក់និម្មិត ifbX សម្រាប់ចំណុចប្រទាក់បណ្តាញនីមួយៗ ហើយប្តូរទិសចរាចរណ៍ចូលពីចំណុចប្រទាក់ទៅចរាចរណ៍ចេញនៅលើ ifbX ។ លើសពីនេះទៀតសម្រាប់ ifbX រាល់វិញ្ញាសាដូចគ្នាធ្វើការដើម្បីគ្រប់គ្រងចរាចរណ៍ចេញ ដែលការកំណត់រចនាសម្ព័ន្ធ hsfc នឹងស្រដៀងគ្នាខ្លាំងណាស់៖

ក្នុងអំឡុងពេលនៃការពិសោធន៍ យើងបានរកឃើញថា hsfc បង្ហាញលទ្ធផលល្អបំផុតនៅពេលដែលថ្នាក់ 1:2 នៃចរាចរណ៍បណ្តុំ/ទំនេរដែលមិនមានអាទិភាពត្រូវបានកំណត់នៅលើម៉ាស៊ីន minion មិនលើសពីផ្លូវទំនេរជាក់លាក់មួយ។ បើមិនដូច្នោះទេ ចរាចរណ៍ដែលមិនមែនជាអាទិភាពមានឥទ្ធិពលខ្លាំងពេកទៅលើភាពយឺតយ៉ាវនៃកិច្ចការផលិតផល។ miniond កំណត់ចំនួនបច្ចុប្បន្ននៃ bandwidth ឥតគិតថ្លៃជារៀងរាល់វិនាទី ដោយវាស់ស្ទង់ការប្រើប្រាស់ចរាចរណ៍ជាមធ្យមនៃ prod-tasks ទាំងអស់នៃ minion ដែលបានផ្តល់ឱ្យ ហើយដកវាចេញពីកម្រិតបញ្ជូនចំណុចប្រទាក់បណ្តាញ ជាមួយនឹងរឹមតូចមួយ, i.e.

ក្រុមតន្រ្តីត្រូវបានកំណត់ដោយឯករាជ្យសម្រាប់ចរាចរណ៍ចូលនិងចេញ។ ហើយយោងទៅតាមតម្លៃថ្មី miniond កំណត់រចនាសម្ព័ន្ធថ្នាក់ដែលមិនមែនជាអាទិភាព 1:2 ឡើងវិញ។

ដូច្នេះហើយ យើងបានអនុវត្តថ្នាក់ឯកោទាំងបី៖ prod, batch និង idle ។ ថ្នាក់ទាំងនេះមានឥទ្ធិពលយ៉ាងខ្លាំងទៅលើលក្ខណៈនៃការអនុវត្តការងារ។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តដាក់គុណលក្ខណៈនេះនៅផ្នែកខាងលើនៃឋានានុក្រម ដូច្នេះនៅពេលមើលឈ្មោះនៃជួរឋានានុក្រម វានឹងច្បាស់ភ្លាមៗនូវអ្វីដែលយើងកំពុងដោះស្រាយ៖

មិត្តភក្តិរបស់យើងទាំងអស់។ បណ្ដាញ и តន្ត្រី បន្ទាប់មកផ្នែកខាងមុខត្រូវបានដាក់ក្នុងឋានានុក្រមក្រោមផលិតផល។ ឧទាហរណ៍ នៅក្រោមបាច់ ចូរយើងដាក់សេវាកម្ម កាតាឡុកតន្ត្រីដែល​ចងក្រង​កាតាឡុក​បទ​ជា​ទៀងទាត់​ពី​សំណុំ​ឯកសារ mp3 ដែល​បាន​បង្ហោះ​ទៅ Odnoklassniki ។ ឧទាហរណ៍នៃសេវាកម្មនៅក្រោមទំនេរនឹងមាន ឧបករណ៍បំលែងតន្ត្រីដែលធ្វើឱ្យកម្រិតសំឡេងតន្ត្រីមានលក្ខណៈធម្មតា។

ជាមួយនឹងបន្ទាត់បន្ថែមត្រូវបានដកចេញម្តងទៀត យើងអាចសរសេរឈ្មោះសេវាកម្មរបស់យើងឱ្យកាន់តែល្អក់កករដោយបន្ថែមថ្នាក់ដាច់ដោយឡែកពីការងារទៅចុងបញ្ចប់នៃឈ្មោះសេវាកម្មពេញលេញ៖ web.front.prod, catalog.music.batch, transformer.music.idle.

ហើយឥឡូវនេះដោយក្រឡេកមើលឈ្មោះសេវាកម្ម យើងយល់មិនត្រឹមតែមុខងារដែលវាដំណើរការប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងថ្នាក់ឯកោរបស់វា ដែលមានន័យថាការរិះគន់របស់វាជាដើម។

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

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

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

លើសពីនេះ រហូតមកដល់ពេលនេះ យើងបានត្រឹមតែដោះស្រាយបញ្ហានៃការកំណត់អាទិភាពចរាចរណ៍ TCP ប៉ុណ្ណោះ៖ វិធីសាស្រ្ត hsfc មិនដំណើរការសម្រាប់ UDP ទេ។ ហើយសូម្បីតែនៅក្នុងករណីនៃចរាចរ TCP ប្រសិនបើកិច្ចការបាច់បង្កើតចរាចរច្រើន នេះក៏ផ្តល់នូវការកើនឡើងប្រហែល 10% ក្នុងការពន្យារពេលនៃកិច្ចការផលិតផល។

ការអត់ធ្មត់កំហុស

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

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

បញ្ហាទីពីរដែលអាចកើតមានគឺធុងធ្លាក់។ ហើយនៅទីនេះ គោលការណ៍ចាប់ផ្តើមឡើងវិញ ជួយសង្គ្រោះយើង អ្នករាល់គ្នាស្គាល់ពួកគេ Docker ខ្លួនវាធ្វើការងារដ៏អស្ចារ្យ។ ស្ទើរតែរាល់កិច្ចការផលិតផលទាំងអស់មានគោលការណ៍ចាប់ផ្តើមឡើងវិញជានិច្ច។ ពេលខ្លះយើងប្រើ on_failure សម្រាប់កិច្ចការបាច់ ឬសម្រាប់បំបាត់កំហុសធុងផលិតផល។

តើ​អ្នក​អាច​ធ្វើ​អ្វី​បាន​ប្រសិនបើ minion ទាំងមូល​មិន​មាន?

ជាក់ស្តែង ដំណើរការកុងតឺន័រនៅលើម៉ាស៊ីនផ្សេងទៀត។ ផ្នែកគួរឱ្យចាប់អារម្មណ៍នៅទីនេះគឺជាអ្វីដែលកើតឡើងចំពោះអាសយដ្ឋាន IP (es) ដែលបានកំណត់ទៅកុងតឺន័រ។

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

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

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

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

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

ដូច្នេះ ការគូសផែនទីនៃឈ្មោះសេវាកម្មទៅក្នុងបញ្ជីអាសយដ្ឋាន IP របស់វាផ្លាស់ប្តូរកម្រណាស់។ ប្រសិនបើអ្នកក្រឡេកមើលម្តងទៀតនូវឈ្មោះនៃករណីសេវាកម្មដែលយើងបានលើកឡើងនៅដើមអត្ថបទ (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …) យើងនឹងសម្គាល់ឃើញថាពួកវាស្រដៀងនឹង FQDNs ដែលប្រើក្នុង DNS ។ ត្រឹមត្រូវហើយ ដើម្បីផ្គូផ្គងឈ្មោះនៃសេវាកម្មទៅអាសយដ្ឋាន IP របស់ពួកគេ យើងប្រើពិធីការ DNS ។ លើសពីនេះទៅទៀត DNS នេះត្រឡប់អាសយដ្ឋាន IP ដែលបានបម្រុងទុកទាំងអស់នៃកុងតឺន័រទាំងអស់ - ទាំងដំណើរការ និងបញ្ឈប់ (ឧបមាថាការចម្លងចំនួនបីត្រូវបានប្រើ ហើយយើងមានអាសយដ្ឋានចំនួនប្រាំដែលបានបម្រុងទុកនៅទីនោះ - ទាំងប្រាំនឹងត្រូវបានបញ្ជូនមកវិញ) ។ អតិថិជនដែលបានទទួលព័ត៌មាននេះ នឹងព្យាយាមបង្កើតការតភ្ជាប់ជាមួយការចម្លងទាំងប្រាំ - ដូច្នេះហើយកំណត់អ្នកដែលកំពុងដំណើរការ។ ជម្រើសនេះសម្រាប់កំណត់ភាពអាចរកបានគឺអាចទុកចិត្តបានច្រើន វាមិនពាក់ព័ន្ធនឹង DNS ឬ Service Discovery ដែលមានន័យថាមិនមានបញ្ហាពិបាកដោះស្រាយក្នុងការធានានូវភាពពាក់ព័ន្ធនៃព័ត៌មាន និងការអត់ឱនចំពោះកំហុសនៃប្រព័ន្ធទាំងនេះទេ។ លើសពីនេះទៅទៀត នៅក្នុងសេវាកម្មសំខាន់ៗដែលប្រតិបត្តិការនៃវិបផតថលទាំងមូលអាស្រ័យ យើងមិនអាចប្រើ DNS បានទេ ប៉ុន្តែគ្រាន់តែបញ្ចូលអាសយដ្ឋាន IP ទៅក្នុងការកំណត់។

ការអនុវត្តការផ្ទេរ IP បែបនេះនៅពីក្រោយកុងតឺន័រអាចជារឿងមិនសំខាន់ - ហើយយើងនឹងពិនិត្យមើលពីរបៀបដែលវាដំណើរការជាមួយឧទាហរណ៍ខាងក្រោម៖

ឧបមាថា មេពពកតែមួយ ផ្តល់ពាក្យបញ្ជាទៅ minion M1 ដើម្បីដំណើរការ 1.ok-web.group1.web.front.prod ជាមួយអាសយដ្ឋាន 1.1.1.1 ។ ធ្វើការលើ minion ប៊ីដែលផ្សាយអាសយដ្ឋាននេះទៅម៉ាស៊ីនមេពិសេស ឧបករណ៍ឆ្លុះបញ្ចាំងផ្លូវ. ក្រោយមកទៀតមានវគ្គ BGP ជាមួយផ្នែករឹងបណ្តាញ ដែលផ្លូវនៃអាសយដ្ឋាន 1.1.1.1 នៅលើ M1 ត្រូវបានបកប្រែ។ M1 បញ្ជូនកញ្ចប់ព័ត៌មាននៅខាងក្នុងកុងតឺន័រដោយប្រើលីនុច។ មានម៉ាស៊ីនមេឆ្លុះបញ្ចាំងផ្លូវចំនួនបី ដោយសារនេះគឺជាផ្នែកសំខាន់មួយនៃហេដ្ឋារចនាសម្ព័ន្ធពពកតែមួយ - បើគ្មានពួកវាទេ បណ្តាញនៅក្នុងពពកតែមួយនឹងមិនដំណើរការទេ។ យើងដាក់ពួកវានៅក្នុងរ៉ាកែតផ្សេងៗគ្នា ប្រសិនបើអាចធ្វើទៅបានដែលមានទីតាំងនៅបន្ទប់ផ្សេងគ្នានៃមជ្ឈមណ្ឌលទិន្នន័យ ដើម្បីកាត់បន្ថយលទ្ធភាពនៃការបរាជ័យទាំងបីក្នុងពេលតែមួយ។

ឥឡូវ​នេះ​សូម​សន្មត​ថា​ការ​តភ្ជាប់​រវាង​មេ​ពពក​តែមួយ និង​មីនីន M1 ត្រូវ​បាន​បាត់បង់។ ម្ចាស់ពពកតែមួយនឹងធ្វើសកម្មភាពតាមការសន្មតថា M1 បានបរាជ័យទាំងស្រុង។ នោះគឺវានឹងផ្តល់ពាក្យបញ្ជាដល់ M2 minion ដើម្បីចាប់ផ្តើម web.group1.web.front.prod ជាមួយនឹងអាសយដ្ឋានដូចគ្នា 1.1.1.1 ។ ឥឡូវនេះយើងមានផ្លូវផ្ទុយគ្នាពីរនៅលើបណ្តាញសម្រាប់ 1.1.1.1: នៅលើ M1 និងនៅលើ M2 ។ ដើម្បីដោះស្រាយជម្លោះបែបនេះ យើងប្រើ Multi Exit Discriminator ដែលត្រូវបានបញ្ជាក់នៅក្នុងសេចក្តីប្រកាស BGP ។ នេះគឺជាលេខដែលបង្ហាញពីទម្ងន់នៃផ្លូវដែលបានផ្សព្វផ្សាយ។ ក្នុងចំណោមផ្លូវដែលមានជម្លោះ ផ្លូវដែលមានតម្លៃ MED ទាបជាងនឹងត្រូវបានជ្រើសរើស។ មេពពកតែមួយគាំទ្រ MED ជាផ្នែកសំខាន់នៃអាសយដ្ឋាន IP កុងតឺន័រ។ ជាលើកដំបូង អាសយដ្ឋានត្រូវបានសរសេរដោយ MED ធំល្មម = 1។ ក្នុងស្ថានភាពនៃការផ្ទេរកុងតឺន័រសង្គ្រោះបន្ទាន់បែបនេះ មេកាត់បន្ថយ MED ហើយ M000 នឹងទទួលបានពាក្យបញ្ជាដើម្បីផ្សព្វផ្សាយអាសយដ្ឋាន 000 ជាមួយ MED = 2. វត្ថុដែលដំណើរការលើ M1.1.1.1 នឹងនៅដដែល ក្នុងករណីនេះមិនមានទំនាក់ទំនងអ្វីទេ ហើយជោគវាសនាបន្ថែមទៀតរបស់គាត់ចាប់អារម្មណ៍យើងតិចតួចរហូតដល់ការភ្ជាប់ជាមួយមេត្រូវបានស្ដារឡើងវិញ នៅពេលដែលគាត់នឹងត្រូវបានបញ្ឈប់ដូចជាការទទួលយកចាស់។

គ្រោះថ្នាក់

ប្រព័ន្ធគ្រប់គ្រងមជ្ឈមណ្ឌលទិន្នន័យទាំងអស់តែងតែដោះស្រាយការបរាជ័យតិចតួចដែលអាចទទួលយកបាន។ ការហៀរកុងតឺន័រគឺជាបទដ្ឋានស្ទើរតែគ្រប់ទីកន្លែង។

សូមក្រឡេកមើលពីរបៀបដែលយើងដោះស្រាយគ្រោះអាសន្ន ដូចជាការដាច់ចរន្តអគ្គិសនីនៅក្នុងបន្ទប់មួយ ឬច្រើននៃមជ្ឈមណ្ឌលទិន្នន័យ។

តើគ្រោះថ្នាក់មានន័យដូចម្តេចសម្រាប់ប្រព័ន្ធគ្រប់គ្រងមជ្ឈមណ្ឌលទិន្នន័យ? ជាដំបូង នេះគឺជាការបរាជ័យដ៏ធំមួយនៃម៉ាស៊ីនជាច្រើន ហើយប្រព័ន្ធគ្រប់គ្រងត្រូវផ្លាស់ប្តូរកុងតឺន័រជាច្រើនក្នុងពេលតែមួយ។ ប៉ុន្តែប្រសិនបើគ្រោះមហន្តរាយមានទំហំធំខ្លាំង នោះវាអាចកើតឡើងដែលថាកិច្ចការទាំងអស់មិនអាចបែងចែកឡើងវិញទៅឱ្យ minions ផ្សេងទៀតបានទេ ព្រោះសមត្ថភាពធនធានរបស់មជ្ឈមណ្ឌលទិន្នន័យធ្លាក់ចុះក្រោម 100% នៃបន្ទុក។

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

តើអ្នកអាចធ្វើអ្វីបានអំពីរឿងទាំងអស់នេះ?

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

សូមក្រឡេកមើលម្តងទៀតនូវឋានានុក្រមនៃសេវាកម្មដែលយើងធ្លាប់ស្គាល់ ហើយព្យាយាមសម្រេចថាតើកិច្ចការណាមួយដែលយើងចង់ដំណើរការមុនគេ។

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

នៅលើផលិតផល យើងកំណត់អាទិភាពខ្ពស់ជាង 0; នៅលើបាច់ - ទាបជាងបន្តិច 100; នៅទំនេរ - ទាបជាង 200។ អាទិភាពត្រូវបានអនុវត្តតាមឋានានុក្រម។ កិច្ចការទាំងអស់ដែលទាបជាងនៅក្នុងឋានានុក្រមនឹងមានអាទិភាពដែលត្រូវគ្នា។ ប្រសិនបើយើងចង់ឱ្យឃ្លាំងសម្ងាត់នៅខាងក្នុង prod ដំណើរការមុនពេល frontends នោះយើងកំណត់អាទិភាពទៅ cache = 0 និង subqueues ខាងមុខ = 1។ ឧទាហរណ៍ ប្រសិនបើយើងចង់ឱ្យ portal មេត្រូវបានបើកពី fronts ជាមុនសិន ហើយ music front only បន្ទាប់មក យើងអាចកំណត់អាទិភាពទាបជាងទៅក្រោយ - 10 ។

បញ្ហាបន្ទាប់គឺកង្វះធនធាន។ ដូច្នេះ គ្រឿងបរិក្ខារមួយចំនួនធំ សាលទាំងមូលនៃមជ្ឈមណ្ឌលទិន្នន័យបានបរាជ័យ ហើយយើងបានដំណើរការឡើងវិញនូវសេវាកម្មជាច្រើន ដែលឥឡូវនេះមិនមានធនធានគ្រប់គ្រាន់សម្រាប់មនុស្សគ្រប់គ្នា។ អ្នក​ត្រូវ​សម្រេច​ចិត្ត​ថា​ត្រូវ​លះបង់​កិច្ចការ​ណា​មួយ​ដើម្បី​រក្សា​សេវាកម្ម​សំខាន់ៗ​ឱ្យ​ដំណើរការ។

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

នៅក្នុងឋានានុក្រមរបស់យើង វាសាមញ្ញណាស់ក្នុងការបញ្ជាក់អាទិភាពជាមុន ដូចជាការងារ prod និង batch preempt ឬ stop idle tasks ប៉ុន្តែមិនមែនគ្នាទៅវិញទៅមកទេ ដោយបញ្ជាក់អាទិភាពសម្រាប់ idle ស្មើនឹង 200។ ដូចនៅក្នុងករណីនៃ placement priority យើង អាច​ប្រើ​ឋានានុក្រម​របស់​យើង​ដើម្បី​ពណ៌នា​អំពី​ច្បាប់​ស្មុគស្មាញ​បន្ថែម​ទៀត។ ជាឧទាហរណ៍ សូមបង្ហាញថាយើងលះបង់មុខងារតន្ត្រី ប្រសិនបើយើងមិនមានធនធានគ្រប់គ្រាន់សម្រាប់វិបផតថលមេ ដោយកំណត់អាទិភាពសម្រាប់ថ្នាំងដែលត្រូវគ្នាទាបជាងនេះ៖ 10 ។

គ្រោះថ្នាក់ DC ទាំងមូល

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

ហើយនេះជាអ្វីដែលយើងធ្វើដើម្បីការពារនរណាម្នាក់ពីការ tweet #alive។

យុទ្ធសាស្ត្រដំបូងគឺភាពឯកោ។ រាល់ cloud instance នីមួយៗគឺដាច់ដោយឡែក ហើយអាចគ្រប់គ្រងម៉ាស៊ីននៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យតែមួយប៉ុណ្ណោះ។ នោះគឺការបាត់បង់ពពកដោយសារតែកំហុសឬពាក្យបញ្ជាប្រតិបត្តិករមិនត្រឹមត្រូវគឺជាការបាត់បង់មជ្ឈមណ្ឌលទិន្នន័យតែមួយគត់។ យើងត្រៀមខ្លួនរួចជាស្រេចសម្រាប់រឿងនេះ៖ យើងមានគោលការណ៍លែងត្រូវការតទៅទៀត ដែលការចម្លងនៃកម្មវិធី និងទិន្នន័យមានទីតាំងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យទាំងអស់។ យើងប្រើមូលដ្ឋានទិន្នន័យដែលអត់ឱនចំពោះកំហុស និងសាកល្បងជាទៀងទាត់សម្រាប់ការបរាជ័យ។
ចាប់តាំងពីថ្ងៃនេះ យើងមានមជ្ឈមណ្ឌលទិន្នន័យចំនួនបួន ដែលមានន័យថា បួនដាច់ដោយឡែកពីគ្នា និងដាច់ស្រយាលទាំងស្រុងនៃពពកតែមួយ។

វិធីសាស្រ្តនេះមិនត្រឹមតែការពារប្រឆាំងនឹងការបរាជ័យផ្នែករាងកាយប៉ុណ្ណោះទេប៉ុន្តែក៏អាចការពារប្រឆាំងនឹងកំហុសរបស់ប្រតិបត្តិករផងដែរ។

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

លទ្ធផល

លក្ខណៈពិសេសប្លែកនៃពពកតែមួយ៖

• គ្រោងការណ៍ដាក់ឈ្មោះតាមឋានានុក្រម និងរូបភាពសម្រាប់សេវាកម្ម និងធុងដែលអនុញ្ញាតឱ្យអ្នកស្វែងរកយ៉ាងរហ័សនូវអ្វីដែលជាភារកិច្ច ដែលវាទាក់ទងនឹង និងរបៀបដែលវាដំណើរការ និងអ្នកណាជាអ្នកទទួលខុសត្រូវចំពោះវា។
• យើងអនុវត្តរបស់យើង។ បច្ចេកទេសនៃការផ្សំផលិតផល និងបាច់-ភារកិច្ចលើ minions ដើម្បីបង្កើនប្រសិទ្ធភាពនៃការចែករំលែកម៉ាស៊ីន។ ជំនួសឱ្យ cpuset យើងប្រើកូតាស៊ីភីយូ ការចែករំលែក គោលការណ៍កំណត់ពេលស៊ីភីយូ និងលីនុច QoS ។
• វាមិនអាចទៅរួចទេក្នុងការផ្តាច់ធុងទាំងស្រុងដែលដំណើរការលើម៉ាស៊ីនតែមួយ ប៉ុន្តែឥទ្ធិពលទៅវិញទៅមករបស់ពួកគេនៅតែមានក្នុងរង្វង់ 20% ។
• ការរៀបចំសេវាកម្មតាមឋានានុក្រមជួយក្នុងការសង្គ្រោះគ្រោះមហន្តរាយដោយស្វ័យប្រវត្តិដោយប្រើ អាទិភាពនៃការដាក់ និងទុកជាមុន.

សំណួរគេសួរញឹកញាប់

ហេតុអ្វីបានជាយើងមិនយកដំណោះស្រាយដែលត្រៀមរួចជាស្រេច?

• ថ្នាក់ផ្សេងគ្នានៃភាពឯកោនៃភារកិច្ចតម្រូវឱ្យមានតក្កវិជ្ជាផ្សេងគ្នានៅពេលដាក់នៅលើ minions ។ ប្រសិនបើកិច្ចការ prod អាចត្រូវបានដាក់ដោយគ្រាន់តែកក់ធនធាន នោះកិច្ចការបាច់ និងទំនេរត្រូវតែដាក់ ដោយតាមដានការប្រើប្រាស់ធនធានពិតប្រាកដនៅលើម៉ាស៊ីន minion ។
• តម្រូវការដើម្បីយកទៅក្នុងគណនីធនធានដែលប្រើប្រាស់ដោយភារកិច្ចដូចជា៖
  • កម្រិតបញ្ជូនបណ្តាញ;
  • ប្រភេទនិង "spindles" នៃថាស។
• តម្រូវការដើម្បីបង្ហាញពីអាទិភាពនៃសេវាកម្មក្នុងអំឡុងពេលការឆ្លើយតបជាបន្ទាន់ សិទ្ធិ និងកូតានៃពាក្យបញ្ជាសម្រាប់ធនធាន ដែលត្រូវបានដោះស្រាយដោយប្រើជួរឋានានុក្រមនៅក្នុងពពកតែមួយ។
• តម្រូវការក្នុងការដាក់ឈ្មោះមនុស្សនៃធុង ដើម្បីកាត់បន្ថយពេលវេលាឆ្លើយតបទៅនឹងគ្រោះថ្នាក់ និងឧបទ្ទវហេតុនានា
• ភាពមិនអាចទៅរួចនៃការអនុវត្តរីករាលដាលតែម្តងនៃសេវាកម្ម Discovery; តម្រូវការក្នុងការរួមរស់ជាមួយគ្នាអស់រយៈពេលជាយូរជាមួយនឹងភារកិច្ចដែលរៀបចំនៅលើម៉ាស៊ីនផ្នែករឹង - អ្វីមួយដែលត្រូវបានដោះស្រាយដោយអាសយដ្ឋាន IP "ឋិតិវន្ត" បន្ទាប់ពីកុងតឺន័រ ហើយជាលទ្ធផល តម្រូវការសម្រាប់ការរួមបញ្ចូលតែមួយគត់ជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធបណ្តាញដ៏ធំមួយ។

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

សម្រាប់អ្នកដែលបានអានវគ្គចុងក្រោយ សូមអរគុណចំពោះការអត់ធ្មត់ និងការយកចិត្តទុកដាក់របស់អ្នក!

ប្រភព: www.habr.com