بې ځایه RabbitMQ ته Kubernetes مهاجرت

بې ځایه RabbitMQ ته Kubernetes مهاجرت

RabbitMQ یو پیغام بروکر دی چې په ایرلنګ کې لیکل شوی چې تاسو ته اجازه درکوي د ډیری نوډونو په اوږدو کې د بشپړ ډیټا نقل کولو سره د ناکامۍ کلستر تنظیم کړئ ، چیرې چې هر نوډ کولی شي غوښتنې لوستل او لیکلو خدمت وکړي. د تولید په عملیاتو کې د کبرنیټس ډیری کلسترونه درلودل، موږ د لوی شمیر RabbitMQ تاسیساتو ملاتړ کوو او له یو کلستر څخه بل کلستر ته د ډیټا لیږدولو اړتیا سره مخ یو.

موږ لږترلږه دوه قضیو کې دې عملیاتو ته اړتیا لرو:

  1. د RabbitMQ کلستر څخه ډیټا لیږدول چې په کوبرنیټس کې موقعیت نلري نوي ته - دمخه "کوبرنیټ شوی" (د مثال په توګه د K8s پوډونو کې کار کوي) - کلستر.
  2. د RabbitMQ مهاجرت په Kubernetes کې د یو نوم ځای څخه بل ته (د مثال په توګه، که چیرې سرکیټونه د نوم ځای په واسطه محدود شوي وي، نو بیا د زیربنا لیږد له یو سرکټ څخه بل ته).

په مقاله کې وړاندیز شوی ترکیب په شرایطو متمرکز دی (مګر په دوی پورې محدود ندی) په کوم کې چې د RabbitMQ یو زوړ کلستر شتون لري (د مثال په توګه ، د 3 نوډونو) ، یا دمخه په K8s یا ځینې زاړه سرورونو کې موقعیت لري. یو اپلیکیشن چې په کوبرنیټس کې کوربه شوی (د مخه شتون لري یا په راتلونکي کې) د دې سره کار کوي:

بې ځایه RabbitMQ ته Kubernetes مهاجرت

... او موږ په کوبرنیټس کې نوي تولید ته د دې د مهاجرت له دندې سره مخ یو.

لومړی، د مهاجرت عمومي طریقه به پخپله بیان شي، او وروسته به د هغې د پلي کولو تخنیکي توضیحات بیان شي.

د مهاجرت الګوریتم

د هر عمل څخه دمخه لومړی، لومړنی، مرحله دا ده چې وګورئ چې د لوړ شتون حالت په زاړه RabbitMQ نصب کې فعال شوی دی (HA). دلیل څرګند دی - موږ نه غواړو کوم معلومات له لاسه ورکړو. د دې چک د ترسره کولو لپاره، تاسو کولی شئ د RabbitMQ اډمین پینل ته لاړ شئ او په اډمین → پالیسي ټب کې ډاډ ترلاسه کړئ چې ارزښت ټاکل شوی ha-mode: all:

بې ځایه RabbitMQ ته Kubernetes مهاجرت

بل ګام د Kubernetes پوډونو کې د نوي RabbitMQ کلستر پورته کول دي (زموږ په قضیه کې، د بیلګې په توګه، د 3 نوډونو څخه جوړ شوی، مګر د دوی شمیر ممکن توپیر ولري).

له دې وروسته، موږ زاړه او نوي RabbitMQ کلسترونه یوځای کوو، یو واحد کلستر ترلاسه کوو (د 6 نوډونو):

بې ځایه RabbitMQ ته Kubernetes مهاجرت

د زاړه او نوي RabbitMQ کلسترونو ترمنځ د معلوماتو همغږي کولو پروسه پیل شوې. یوځل چې ټول معلومات په کلستر کې د ټولو نوډونو ترمینځ همغږي شي ، موږ کولی شو د نوي کلستر کارولو لپاره غوښتنلیک بدل کړو:

بې ځایه RabbitMQ ته Kubernetes مهاجرت

د دې عملیاتو وروسته، دا د RabbitMQ کلستر څخه د زاړه نوډونو لرې کولو لپاره کافي دي، او حرکت بشپړ ګڼل کیدی شي:

بې ځایه RabbitMQ ته Kubernetes مهاجرت

موږ دا سکیم څو ځله په تولید کې کارولی دی. په هرصورت، زموږ د خپلې اسانتیا لپاره، موږ دا په یو ځانګړي سیسټم کې پلي کړی چې د ډیری کوبرنیټس کلسترونو کې د معیاري RMQ ترتیبونه توزیع کوي. (د هغو کسانو لپاره چې لیواله دي: موږ یې په اړه خبرې کوو addon-operatorد کوم په اړه چې موږ په دې وروستیو کې وویل). لاندې به موږ انفرادي لارښوونې وړاندې کړو چې هرڅوک کولی شي په خپلو تاسیساتو کې پلي شي ترڅو وړاندیز شوي حل په عمل کې هڅه وکړي.

راځئ چې دا په عمل کې هڅه وکړو

اړتیاو

توضیحات خورا ساده دي:

  1. د کبرنیټس کلستر (مینیکیوب به هم کار وکړي)؛
  2. د RabbitMQ کلستر (په نخښه فلز کې ځای پرځای کیدی شي، او د رسمي هیلم چارټ څخه په کبرنیټس کې د منظم کلستر په څیر جوړ شي).

د لاندې مثال لپاره، ما Kubernetes ته RMQ ځای په ځای کړ او ورته یې وویل rmq-old.

ودریږئ چمتووالی

1. د هیلم چارټ ډاونلوډ کړئ او لږ څه ترمیم کړئ:

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 ته Kubernetes مهاجرت

د ازموینې بینچ چمتو دی: موږ د ډیټا سره "زاړه" RabbitMQ لرو چې لیږدولو ته اړتیا لري.

د RabbitMQ کلستر مهاجرت

1. لومړی، راځئ چې نوی RabbitMQ په کې ځای په ځای کړو ملګری نوم ځای سره ورته 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. د 6 نوډونو RMQ کلستر چمتو دی:

بې ځایه RabbitMQ ته Kubernetes مهاجرت

تاسو باید انتظار وکړئ کله چې پیغامونه د ټولو نوډونو ترمنځ همغږي کیږي. دا اټکل کول ستونزمن ندي چې د پیغام همغږي کولو وخت د هارډویر ظرفیت پورې اړه لري په کوم کې چې کلستر ځای په ځای شوی او د پیغامونو شمیر پورې اړه لري. په بیان شوي سناریو کې، یوازې 10 یې شتون لري، نو ډاټا په سمدستي توګه همغږي شوي، مګر د کافي لوی شمیر پیغامونو سره، همغږي کول د ساعتونو لپاره دوام کولی شي.

نو، د همغږۍ حالت:

بې ځایه RabbitMQ ته Kubernetes مهاجرت

دا +5 پدې معنی چې پیغامونه لا دمخه شتون لري نور په 5 نوډونو کې (پرته له هغه څه چې په ساحه کې ښودل شوي Node). په دې توګه، همغږي بریالۍ وه.

4. ټول هغه څه چې پاتې دي د غوښتنلیک کې د RMQ پته نوي کلستر ته بدلول دي (دلته ځانګړي کړنې د ټیکنالوژۍ سټیک پورې اړه لري چې تاسو یې کاروئ او د غوښتنلیک نور مشخصات) له هغې وروسته تاسو کولی شئ زاړه ته الوداع ووایاست.

د وروستي عملیاتو لپاره (یعنې دمخه после نوي کلستر ته د غوښتنلیک بدلول) هر نوډ ته لاړ شئ زوړ کلستر کړئ او امرونه اجرا کړئ:

rabbitmqctl stop_app
rabbitmqctl reset

کلستر د زړو نوډونو په اړه "هیر شوی": تاسو کولی شئ زوړ RMQ حذف کړئ، په کوم ځای کې چې حرکت به بشپړ شي.

تبصره: که تاسو د سندونو سره RMQ کاروئ ، نو هیڅ شی په بنسټیز ډول نه بدلیږي - د حرکت پروسه به په ورته ډول ترسره شي.

موندنو

بیان شوی سکیم د نږدې ټولو قضیو لپاره مناسب دی کله چې موږ د RabbitMQ مهاجرت ته اړتیا لرو یا په ساده ډول نوي کلستر ته لاړ شو.

زموږ په قضیه کې ، ستونزې یوازې یوځل رامینځته شوې ، کله چې RMQ ته له ډیری ځایونو څخه لاسرسی وم ، او موږ فرصت نه درلود چې د RMQ پته په هر ځای کې نوي ته بدل کړو. بیا موږ د ورته لیبلونو سره په ورته نوم ځای کې یو نوی RMQ پیل کړ ترڅو دا د موجوده خدماتو او انګریزونو لاندې راشي ، او کله چې پوډ پیل کړو موږ لیبلونه د لاس په واسطه اداره کړل ، په پیل کې یې لیرې کړل ترڅو غوښتنې ونه رسیږي. RMQ خالي کړئ، او د پیغامونو له ترکیب وروسته یې بیرته اضافه کړئ.

موږ ورته ستراتیژي کارولې کله چې د بدل شوي ترتیب سره نوي نسخه ته RabbitMQ تازه کول - هرڅه د ساعت په څیر کار کوي.

PS

د دې موادو د منطقي دوام په توګه، موږ د MongoDB په اړه مقالې چمتو کوو (د هارډویر سرور څخه Kubernetes ته مهاجرت) او MySQL (څنګه موږ دا DBMS په کوبرنیټس کې چمتو کوو). دوی به په راتلونکو میاشتو کې خپاره شي.

پی پی ایس

زموږ په بلاګ کې هم ولولئ:

سرچینه: www.habr.com

Add a comment