Cloister → ការគ្រប់គ្រងចង្កោម OTP សាមញ្ញ

ស្ទើរតែគ្រប់កម្មវិធីអាជីវកម្មដែលទទួលបានជោគជ័យមិនយូរមិនឆាប់ចូលដំណាក់កាលដែលតម្រូវឱ្យមានការធ្វើមាត្រដ្ឋានផ្ដេក។ ក្នុង​ករណី​ជា​ច្រើន អ្នក​អាច​ចាប់ផ្ដើម​ឧទាហរណ៍​ថ្មី​ដោយ​សាមញ្ញ ហើយ​កាត់​បន្ថយ​ការ​ផ្ទុក​មធ្យម។ ប៉ុន្តែក៏មានករណីតិចតួចផងដែរ ដែលយើងត្រូវធានាថាថ្នាំងផ្សេងគ្នាដឹងអំពីគ្នាទៅវិញទៅមក និងចែកចាយបន្ទុកការងារដោយប្រុងប្រយ័ត្ន។

វាប្រែជាសំណាងណាស់។ អ៊ែឡាំងដែលយើងជ្រើសរើសសម្រាប់វាក្យសម្ព័ន្ធដ៏រីករាយ និងការបំផ្លើសនៅជុំវិញវាមានថ្នាក់ដំបូង ការគាំទ្រសម្រាប់ប្រព័ន្ធចែកចាយ. តាមទ្រឹស្តី នេះស្តាប់ទៅមិនសំខាន់ទាំងស្រុង៖

សារឆ្លងកាត់រវាងដំណើរការនៅលើថ្នាំងផ្សេងៗគ្នា ក៏ដូចជារវាងតំណភ្ជាប់ និងម៉ូនីទ័រ មានតម្លាភាព […]

នៅក្នុងការអនុវត្តអ្វីគ្រប់យ៉ាងគឺស្មុគស្មាញបន្តិច។ ចែកចាយ អ៊ែឡាំង ត្រូវបានបង្កើតឡើងនៅពេលដែល "កុងតឺន័រ" មានន័យថាប្រអប់ដែកដ៏ធំមួយសម្រាប់ការដឹកជញ្ជូន ហើយ "docker" គ្រាន់តែជាពាក្យមានន័យដូចសម្រាប់បុរសឆ្នេរសមុទ្រ។ IN IP4 មានអាសយដ្ឋានជាច្រើនដែលមិនបានកាន់កាប់ ការដាច់បណ្តាញជាធម្មតាត្រូវបានបង្កឡើងដោយសត្វកណ្តុរទំពារតាមខ្សែ ហើយពេលវេលាដំណើរការជាមធ្យមនៃប្រព័ន្ធផលិតកម្មត្រូវបានវាស់វែងក្នុងរយៈពេលជាច្រើនទសវត្សរ៍។

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

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

តម្រូវការ

អ្វី​ដែល​ខ្ញុំ​ត្រូវ​ការ​ផ្ទាល់​គឺ​បណ្ណាល័យ​មួយ​ដែល​នឹង​ទទួល​បន្ទុក​គ្រប់គ្រង​ចង្កោម ហើយ​នឹង​មាន​លក្ខណៈ​សម្បត្តិ​ដូច​ខាង​ក្រោម៖

• ការងារប្រកបដោយតម្លាភាព ទាំងបញ្ជីថ្នាំងដែលមានកូដរឹង និងការរកឃើញថាមវន្តតាមរយៈសេវាកម្ម អ៊ែឡាំង;
• ការហៅត្រឡប់មកវិញដែលមានមុខងារពេញលេញសម្រាប់រាល់ការផ្លាស់ប្តូរ topology (ថ្នាំងនៅទីនោះ ថ្នាំងនៅទីនេះ អស្ថេរភាពបណ្តាញ ការបំបែក);
• ចំណុចប្រទាក់ថ្លាសម្រាប់បើកដំណើរការចង្កោមដែលមានឈ្មោះវែង និងខ្លី ដូចជាមួយ :nonode@nohost;
• ការគាំទ្រ Docker ចេញពីប្រអប់ ដោយមិនចាំបាច់សរសេរកូដហេដ្ឋារចនាសម្ព័ន្ធ។

ក្រោយមកមានន័យថាបន្ទាប់ពីខ្ញុំបានសាកល្បងកម្មវិធីក្នុងស្រុក :nonode@nohostឬនៅក្នុងបរិយាកាសចែកចាយសិប្បនិម្មិតដោយប្រើ test_cluster_task, ខ្ញុំគ្រាន់តែចង់រត់ docker-compose up --scale my_app=3 ហើយមើលពីរបៀបដែលវាប្រតិបត្តិបីករណីនៅក្នុង docker ដោយមិនមានការផ្លាស់ប្តូរកូដណាមួយឡើយ។ ខ្ញុំក៏ចង់បានកម្មវិធីអាស្រ័យដូចជា mnesia - នៅពេលដែល topology ផ្លាស់ប្តូរ នៅពីក្រោយឆាក ពួកគេបានកសាងចង្កោមឡើងវិញដោយមិនមានការទាត់បន្ថែមពីកម្មវិធីនោះទេ។

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

វិធីសាស្រ្តដែលបានជ្រើសរើស

ខ្ទម មានបំណងដំណើរការជាកម្មវិធី ទោះបីជាអ្នកប្រើប្រាស់កម្រិតខ្ពស់អាចធ្វើការជាមួយការផ្គុំ និងថែទាំចង្កោមដោយដៃដោយដំណើរការដោយផ្ទាល់ក៏ដោយ។ Cloister.Manager នៅក្នុងមែកធាងអ្នកគ្រប់គ្រងកម្មវិធីគោលដៅ។

នៅពេលដំណើរការជាកម្មវិធី បណ្ណាល័យពឹងផ្អែកលើ configដែលវាអានតម្លៃមូលដ្ឋានខាងក្រោម៖

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

ប៉ារ៉ាម៉ែត្រខាងលើមានន័យត្រង់ដូចខាងក្រោមៈ ខ្ទម ប្រើសម្រាប់កម្មវិធី OTP :my_app, ប្រើ ការរកឃើញសេវាកម្ម erlang ដើម្បីភ្ជាប់ថ្នាំងយ៉ាងហោចណាស់បី និង MyApp.Listener ម៉ូឌុល (ការអនុវត្ត @behaviour Cloister.Listener) ត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីទទួលការជូនដំណឹងអំពីការផ្លាស់ប្តូរ topology ។ ការពិពណ៌នាលម្អិតនៃការកំណត់រចនាសម្ព័ន្ធពេញលេញអាចរកបាននៅក្នុង ឯកសារ.

ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធនេះកម្មវិធី ខ្ទម នឹងមាន បើកដំណើរការជាដំណាក់កាលការពន្យារពេលដំណើរការចាប់ផ្តើមកម្មវិធីមេ រហូតដល់ការឯកភាពគ្នាត្រូវបានឈានដល់ (ថ្នាំងបីត្រូវបានភ្ជាប់ និងតភ្ជាប់ ដូចក្នុងឧទាហរណ៍ខាងលើ។ នៅពេលណាដែល topology ផ្លាស់ប្តូរ (វានឹងមានច្រើន ពីព្រោះថ្នាំងមិនចាប់ផ្តើមធ្វើសមកាលកម្មទាំងស្រុង) អ្នកដោះស្រាយនឹងត្រូវបានគេហៅថា MyApp.Listener.on_state_change/2. ភាគច្រើននៃពេលវេលាដែលយើងអនុវត្តសកម្មភាពមួយនៅពេលដែលយើងទទួលបានសារស្ថានភាព %Cloister.Monitor{status: :up}ដែលមានន័យថា៖ "ជំរាបសួរ ចង្កោមត្រូវបានប្រមូលផ្តុំ។"

ក្នុងករណីភាគច្រើនការដំឡើង consensus: 3 គឺល្អបំផុត ពីព្រោះទោះបីជាយើងរំពឹងថានឹងមានថ្នាំងបន្ថែមទៀតដើម្បីភ្ជាប់ក៏ដោយ ការហៅត្រឡប់មកវិញនឹងឆ្លងកាត់ status: :rehashing → status: :up នៅលើថ្នាំងដែលបានបន្ថែម ឬដកចេញថ្មី។

នៅពេលចាប់ផ្តើមនៅក្នុងរបៀបអភិវឌ្ឍន៍ អ្នកគ្រាន់តែត្រូវកំណត់ consensus: 1 и ខ្ទម រីករាយនឹងរំលងការរង់ចាំសម្រាប់ការប្រមូលផ្តុំចង្កោម នៅពេលដែលគាត់ឃើញ :nonode@nohostឬ :node@hostឬ :[email protected] - អាស្រ័យលើរបៀបដែលថ្នាំងត្រូវបានកំណត់រចនាសម្ព័ន្ធ (:none | :shortnames | :longnames).

ការគ្រប់គ្រងកម្មវិធីចែកចាយ

កម្មវិធីដែលបានចែកចាយមិននៅក្នុងកន្លែងទំនេរ ជាធម្មតារួមបញ្ចូលភាពអាស្រ័យដែលបានចែកចាយ ដូចជា mnesia. វាងាយស្រួលសម្រាប់ពួកយើងក្នុងការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធរបស់ពួកគេឡើងវិញពីការហៅត្រឡប់មកវិញដូចគ្នា។ on_state_change/2. ជាឧទាហរណ៍នៅទីនេះ គឺជាការពិពណ៌នាលម្អិតអំពីរបៀបកំណត់រចនាសម្ព័ន្ធឡើងវិញ mnesia នៅលើការហោះហើរនៅក្នុង ឯកសារ ខ្ទម.

អត្ថប្រយោជន៍ចម្បងនៃការប្រើប្រាស់ ខ្ទម គឺថាវាធ្វើប្រតិបត្តិការចាំបាច់ទាំងអស់ដើម្បីបង្កើតចង្កោមឡើងវិញបន្ទាប់ពីការផ្លាស់ប្តូរ topology នៅក្រោមក្រណាត់. កម្មវិធីគ្រាន់តែដំណើរការក្នុងបរិយាកាសចែកចាយដែលបានរៀបចំរួចជាស្រេច ជាមួយនឹងថ្នាំងទាំងអស់បានតភ្ជាប់ ដោយមិនគិតពីថាតើយើងស្គាល់អាសយដ្ឋាន IP ហើយដូច្នេះឈ្មោះថ្នាំងជាមុន ឬពួកគេត្រូវបានចាត់តាំង/ផ្លាស់ប្តូរថាមវន្ត។ នេះមិនតម្រូវឱ្យមានការកំណត់រចនាសម្ព័ន្ធ docker ពិសេសនោះទេ ហើយតាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍កម្មវិធី វាមិនមានភាពខុសប្លែកគ្នារវាងការដំណើរការក្នុងបរិយាកាសចែកចាយ ឬដំណើរការនៅក្នុងមូលដ្ឋាននោះទេ។ :nonode@nohost. អ្នកអាចអានបន្ថែមអំពីរឿងនេះនៅក្នុង ឯកសារ.

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

ចំណាំ: នៅចំណុចនេះនៅក្នុងដើមមានឃ្លាថា "Happy clustering!" ហើយ Yandex ដែលខ្ញុំបកប្រែ (ខ្ញុំមិនចាំបាច់ឆ្លងកាត់វចនានុក្រមខ្លួនឯងទេ) បានផ្តល់ឱ្យខ្ញុំនូវជម្រើស "Happy clustering!" ប្រហែល​ជា​មិន​អាច​ស្រមៃ​ឃើញ​ការ​បក​ប្រែ​ល្អ​ជាង​នេះ​ទេ ជាពិសេស​នៅ​ក្នុង​ស្ថានភាព​ភូមិសាស្ត្រ​នយោបាយ​បច្ចុប្បន្ន។

ប្រភព: www.habr.com