ការធ្វើចំណាកស្រុកដោយរលូននៃ RabbitMQ ទៅ Kubernetes

RabbitMQ គឺជាឈ្មួញកណ្តាលសារដែលសរសេរនៅក្នុង Erlang ដែលអនុញ្ញាតឱ្យអ្នករៀបចំក្រុមបរាជ័យជាមួយនឹងការចម្លងទិន្នន័យពេញលេញឆ្លងកាត់ថ្នាំងជាច្រើន ដែលថ្នាំងនីមួយៗអាចផ្តល់សេវាអាន និងសរសេរសំណើ។ ការមានចង្កោម Kubernetes ជាច្រើននៅក្នុងប្រតិបត្តិការផលិតកម្ម យើងគាំទ្រការដំឡើង RabbitMQ មួយចំនួនធំ ហើយត្រូវប្រឈមមុខនឹងតម្រូវការក្នុងការផ្ទេរទិន្នន័យពីចង្កោមមួយទៅចង្កោមមួយទៀតដោយគ្មានពេលទំនេរ។

យើងត្រូវការប្រតិបត្តិការនេះយ៉ាងហោចណាស់ពីរករណី៖

1. ការផ្ទេរទិន្នន័យពីចង្កោម RabbitMQ ដែលមិនមានទីតាំងនៅ Kubernetes ទៅថ្មីមួយ - "kubernetized" រួចហើយ (ឧ. ប្រតិបត្តិការនៅក្នុង K8s pods) - cluster។
2. ការធ្វើចំណាកស្រុករបស់ RabbitMQ នៅក្នុង Kubernetes ពីចន្លោះឈ្មោះមួយទៅកន្លែងមួយទៀត (ឧទាហរណ៍ ប្រសិនបើសៀគ្វីត្រូវបានកំណត់ដោយ namespaces បន្ទាប់មកដើម្បីផ្ទេរហេដ្ឋារចនាសម្ព័ន្ធពីសៀគ្វីមួយទៅសៀគ្វីមួយទៀត)។

រូបមន្តដែលបានស្នើឡើងនៅក្នុងអត្ថបទគឺផ្តោតលើស្ថានភាព (ប៉ុន្តែមិនត្រូវបានកំណត់ចំពោះពួកវាទាំងអស់) ដែលក្នុងនោះមានចង្កោម RabbitMQ ចាស់ (ឧទាហរណ៍ 3 ថ្នាំង) ដែលមានទីតាំងនៅ K8s ឬនៅលើម៉ាស៊ីនមេចាស់មួយចំនួន។ កម្មវិធីដែលបង្ហោះនៅលើ Kubernetes (មានរួចហើយ ឬនៅពេលអនាគត) ដំណើរការជាមួយវា៖

... ហើយ​យើង​ត្រូវ​ប្រឈម​មុខ​នឹង​ភារកិច្ច​ផ្ទេរ​វា​ទៅ​ផលិតកម្ម​ថ្មី​នៅ Kubernetes។

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

ក្បួនដោះស្រាយការធ្វើចំណាកស្រុក

ដំណាក់កាលដំបូង ដំណាក់កាលដំបូង មុនពេលសកម្មភាពណាមួយគឺត្រូវពិនិត្យមើលថាតើរបៀបដែលមានកម្រិតខ្ពស់ត្រូវបានបើកនៅក្នុងការដំឡើង RabbitMQ ចាស់ (HA) ហេតុផលគឺជាក់ស្តែង - យើងមិនចង់បាត់បង់ទិន្នន័យណាមួយទេ។ ដើម្បីអនុវត្តការត្រួតពិនិត្យនេះ អ្នកអាចចូលទៅកាន់ផ្ទាំងគ្រប់គ្រង RabbitMQ ហើយនៅក្នុងផ្ទាំង Admin → Policies សូមប្រាកដថាតម្លៃត្រូវបានកំណត់។ ha-mode: all:

ជំហានបន្ទាប់គឺត្រូវលើកចង្កោម RabbitMQ ថ្មីនៅក្នុងផត Kubernetes (ឧទាហរណ៍ក្នុងករណីរបស់យើង មាន 3 ថ្នាំង ប៉ុន្តែចំនួនរបស់ពួកគេអាចខុសគ្នា)។

បន្ទាប់ពីនេះ យើងបញ្ចូលចង្កោម RabbitMQ ចាស់ និងថ្មី ដោយទទួលបានចង្កោមតែមួយ (ក្នុងចំណោម 6 ថ្នាំង)៖

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

បន្ទាប់ពីប្រតិបត្តិការទាំងនេះ វាគ្រប់គ្រាន់ហើយក្នុងការដកថ្នាំងចាស់ចេញពីចង្កោម RabbitMQ ហើយការផ្លាស់ទីអាចត្រូវបានចាត់ទុកថាពេញលេញ៖

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

តោះសាកល្បងអនុវត្ត

តម្រូវការ

ព័ត៌មានលម្អិតគឺសាមញ្ញណាស់៖

1. ចង្កោម Kubernetes (minikube ក៏នឹងដំណើរការផងដែរ);
2. ចង្កោម RabbitMQ (អាច​ត្រូវ​បាន​ដាក់​ពង្រាយ​នៅ​លើ​លោហៈ​ទទេ ហើយ​ធ្វើ​ដូច​ជា​ចង្កោម​ធម្មតា​នៅ​ក្នុង Kubernetes ពី​តារាង Helm ផ្លូវការ)។

សម្រាប់ឧទាហរណ៍ខាងក្រោម ខ្ញុំបានដាក់ពង្រាយ RMQ ទៅ Kubernetes ហើយបានហៅវា។ rmq-old.

ការរៀបចំឈរ

1. ទាញយកតារាង Helm ហើយកែសម្រួលវាបន្តិច៖

helm fetch --untar stable/rabbitmq-ha

ដើម្បីភាពងាយស្រួល យើងកំណត់ពាក្យសម្ងាត់ ErlangCookie និងធ្វើនយោបាយ ha-allដូច្នេះតាមលំនាំដើម ជួរត្រូវបានធ្វើសមកាលកម្មរវាងថ្នាំងទាំងអស់នៃចង្កោម RMQ៖

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. ដំឡើងតារាង៖

helm install . --name rmq-old --namespace rmq-old

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

កៅអីសាកល្បងរួចរាល់ហើយ៖ យើងមាន RabbitMQ "ចាស់" ជាមួយនឹងទិន្នន័យដែលត្រូវការផ្ទេរ។

ការធ្វើចំណាកស្រុកក្រុម RabbitMQ

1. ជាដំបូង សូមដាក់ពង្រាយ RabbitMQ ថ្មីនៅក្នុង មិត្តភក្តិ namespace ជាមួយ ដូចគ្នា ErlangCookie និងពាក្យសម្ងាត់សម្រាប់អ្នកប្រើប្រាស់។ ដើម្បីធ្វើដូចនេះយើងនឹងអនុវត្តប្រតិបត្តិការដែលបានពិពណ៌នាខាងលើដោយផ្លាស់ប្តូរពាក្យបញ្ជាចុងក្រោយសម្រាប់ការដំឡើង RMQ ដូចខាងក្រោម:

helm install . --name rmq-new --namespace rmq-new

2. ឥឡូវអ្នកត្រូវបញ្ចូលចង្កោមថ្មីជាមួយក្រុមចាស់។ ដើម្បីធ្វើដូចនេះសូមចូលទៅកាន់ផតនីមួយៗ ថ្មី RabbitMQ និងប្រតិបត្តិពាក្យបញ្ជា៖

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

នៅក្នុងអថេរមួយ។ OLD_RMQ អាសយដ្ឋានរបស់ថ្នាំងមួយត្រូវបានរកឃើញ ចាស់ ចង្កោម RMQ ។

ពាក្យបញ្ជាទាំងនេះនឹងបញ្ឈប់ថ្នាំងបច្ចុប្បន្ន ថ្មី ចង្កោម RMQ ភ្ជាប់វាទៅចង្កោមចាស់ ហើយបើកវាម្តងទៀត។

3. ចង្កោម RMQ នៃ 6 nodes គឺរួចរាល់ហើយ៖

អ្នកត្រូវតែរង់ចាំខណៈពេលដែលសារត្រូវបានធ្វើសមកាលកម្មរវាងថ្នាំងទាំងអស់។ វាមិនពិបាកក្នុងការទាយថាពេលវេលាធ្វើសមកាលកម្មសារអាស្រ័យលើសមត្ថភាពនៃផ្នែករឹងដែលដាក់ពង្រាយ និងលើចំនួនសារ។ នៅក្នុងសេណារីយ៉ូដែលបានពិពណ៌នា វាមានត្រឹមតែ 10 ប៉ុណ្ណោះ ដូច្នេះទិន្នន័យត្រូវបានធ្វើសមកាលកម្មភ្លាមៗ ប៉ុន្តែជាមួយនឹងសារមួយចំនួនធំគ្រប់គ្រាន់ ការធ្វើសមកាលកម្មអាចមានរយៈពេលរាប់ម៉ោង។

ដូច្នេះស្ថានភាពធ្វើសមកាលកម្ម៖

វាគឺជាការ +5 មានន័យថា សារមានរួចហើយ ច្រើនទៀត នៅលើ 5 ថ្នាំង (លើកលែងតែអ្វីដែលត្រូវបានចង្អុលបង្ហាញនៅក្នុងវាល Node) ដូច្នេះ ការធ្វើសមកាលកម្មបានជោគជ័យ។

4. អ្វីដែលនៅសេសសល់គឺត្រូវប្តូរអាសយដ្ឋាន RMQ នៅក្នុងកម្មវិធីទៅចង្កោមថ្មី (សកម្មភាពជាក់លាក់នៅទីនេះអាស្រ័យលើជង់បច្ចេកវិទ្យាដែលអ្នកកំពុងប្រើ និងលក្ខណៈពិសេសកម្មវិធីផ្សេងទៀត) បន្ទាប់ពីនោះអ្នកអាចនិយាយលាទៅកាន់លេខចាស់។

សម្រាប់ប្រតិបត្តិការចុងក្រោយ (ឧ после ប្តូរកម្មវិធីទៅចង្កោមថ្មី) ទៅកាន់ថ្នាំងនីមួយៗ ចាស់ cluster និងប្រតិបត្តិពាក្យបញ្ជា៖

rabbitmqctl stop_app
rabbitmqctl reset

ចង្កោម "ភ្លេច" អំពីថ្នាំងចាស់៖ អ្នកអាចលុប RMQ ចាស់ ដែលនៅពេលនោះការផ្លាស់ទីនឹងត្រូវបានបញ្ចប់។

ការកត់សម្គាល់៖ ប្រសិនបើអ្នកប្រើ RMQ ជាមួយវិញ្ញាបនបត្រ នោះគ្មានអ្វីផ្លាស់ប្តូរជាមូលដ្ឋានទេ ដំណើរការផ្លាស់ប្តូរនឹងត្រូវបានអនុវត្តដូចគ្នាយ៉ាងពិតប្រាកដ។

ការរកឃើញ

គ្រោងការណ៍ដែលបានពិពណ៌នាគឺសមរម្យសម្រាប់ស្ទើរតែគ្រប់ករណីទាំងអស់ នៅពេលដែលយើងត្រូវការផ្លាស់ទី RabbitMQ ឬគ្រាន់តែផ្លាស់ទីទៅចង្កោមថ្មី។

ក្នុងករណីរបស់យើង ការលំបាកបានកើតឡើងតែម្តងគត់ នៅពេលដែល RMQ ត្រូវបានចូលប្រើពីកន្លែងជាច្រើន ហើយយើងមិនមានឱកាសផ្លាស់ប្តូរអាសយដ្ឋាន RMQ ទៅអាសយដ្ឋានថ្មីនៅគ្រប់ទីកន្លែងនោះទេ។ បន្ទាប់មក យើងបានបើកដំណើរការ RMQ ថ្មីនៅក្នុង namespace ដូចគ្នាជាមួយនឹងស្លាកដូចគ្នា ដូច្នេះវានឹងស្ថិតនៅក្រោមសេវាកម្មដែលមានស្រាប់ និង Ingresses ហើយនៅពេលចាប់ផ្តើម pod យើងរៀបចំស្លាកដោយដៃ ដោយយកវាចេញនៅដើមដំបូង ដើម្បីកុំឱ្យសំណើធ្លាក់លើ RMQ ទទេ ហើយបន្ថែមពួកវាត្រឡប់មកវិញបន្ទាប់ពីសារត្រូវបានធ្វើសមកាលកម្ម។

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

PS

ជាការបន្តឡូជីខលនៃសម្ភារៈនេះ យើងកំពុងរៀបចំអត្ថបទអំពី MongoDB (ការផ្លាស់ប្តូរពីម៉ាស៊ីនមេផ្នែករឹងទៅ Kubernetes) និង MySQL (របៀបដែលយើងរៀបចំ DBMS នេះនៅក្នុង Kubernetes)។ ពួកគេនឹងត្រូវបានបោះពុម្ពផ្សាយនៅក្នុងខែខាងមុខនេះ។

PPS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «មូលដ្ឋានទិន្នន័យ និង Kubernetes (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ)»
• «គន្លឹះ និងល្បិច K8s៖ បង្កើនល្បឿន Bootstrap សម្រាប់មូលដ្ឋានទិន្នន័យធំ"។

ប្រភព: www.habr.com