বিরামহীন RabbitMQ থেকে Kubernetes মাইগ্রেশন

RabbitMQ হল Erlang-এ লেখা একটি বার্তা ব্রোকার যা আপনাকে একাধিক নোড জুড়ে সম্পূর্ণ ডেটা প্রতিলিপি সহ একটি ফেলওভার ক্লাস্টার সংগঠিত করতে দেয়, যেখানে প্রতিটি নোড অনুরোধগুলি পড়তে এবং লিখতে পরিষেবা দিতে পারে। প্রোডাকশন অপারেশনে অনেকগুলি কুবারনেটস ক্লাস্টার থাকার কারণে, আমরা প্রচুর সংখ্যক RabbitMQ ইনস্টলেশনকে সমর্থন করি এবং ডাউনটাইম ছাড়াই এক ক্লাস্টার থেকে অন্য ক্লাস্টারে ডেটা স্থানান্তর করার প্রয়োজনের সম্মুখীন হয়েছি।

অন্তত দুটি ক্ষেত্রে আমাদের এই অপারেশনের প্রয়োজন ছিল:

1. একটি RabbitMQ ক্লাস্টার থেকে ডেটা স্থানান্তর করা হচ্ছে যা Kubernetes-এ অবস্থিত নয় একটি নতুন – ইতিমধ্যেই “kubernetized” (অর্থাৎ K8s পডে কাজ করছে) – ক্লাস্টারে।
2. Kubernetes-এর মধ্যে RabbitMQ-এর মাইগ্রেশন এক নামস্থান থেকে অন্য নামস্থানে (উদাহরণস্বরূপ, যদি সার্কিটগুলিকে নামস্থান দ্বারা সীমাবদ্ধ করা হয়, তাহলে এক সার্কিট থেকে অন্য সার্কিটে পরিকাঠামো স্থানান্তর করা)।

নিবন্ধে প্রস্তাবিত রেসিপিটি এমন পরিস্থিতির উপর দৃষ্টি নিবদ্ধ করে (তবে তাদের মধ্যে সীমাবদ্ধ নয়) যেখানে একটি পুরানো RabbitMQ ক্লাস্টার (উদাহরণস্বরূপ, 3 নোডের) রয়েছে, যা ইতিমধ্যে K8s বা কিছু পুরানো সার্ভারে অবস্থিত। Kubernetes এ হোস্ট করা একটি অ্যাপ্লিকেশন (ইতিমধ্যে আছে বা ভবিষ্যতে) এটির সাথে কাজ করে:

... এবং আমরা এটিকে কুবারনেটসের নতুন প্রযোজনায় স্থানান্তরিত করার কাজের মুখোমুখি হয়েছি।

প্রথমত, মাইগ্রেশনের সাধারণ পদ্ধতি বর্ণনা করা হবে, এবং তারপরে এর বাস্তবায়নের প্রযুক্তিগত বিশদ বর্ণনা করা হবে।

মাইগ্রেশন অ্যালগরিদম

প্রথম, প্রাথমিক, কোনো পদক্ষেপের আগে পর্যায়টি হল পুরানো RabbitMQ ইনস্টলেশনে উচ্চ প্রাপ্যতা মোড সক্ষম করা আছে কিনা তা পরীক্ষা করা (HA) কারণটি সুস্পষ্ট - আমরা কোনো ডেটা হারাতে চাই না। এই চেকটি চালানোর জন্য, আপনি RabbitMQ অ্যাডমিন প্যানেলে যেতে পারেন এবং অ্যাডমিন → নীতি ট্যাবে নিশ্চিত করুন যে মান সেট করা আছে ha-mode: all:

পরবর্তী ধাপ হল কুবারনেটস পডগুলিতে একটি নতুন RabbitMQ ক্লাস্টার তৈরি করা (আমাদের ক্ষেত্রে, উদাহরণস্বরূপ, 3টি নোড সমন্বিত, তবে তাদের সংখ্যা আলাদা হতে পারে)।

এর পরে, আমরা পুরানো এবং নতুন RabbitMQ ক্লাস্টারগুলিকে একত্রিত করি, একটি একক ক্লাস্টার (6 নোডের):

পুরানো এবং নতুন RabbitMQ ক্লাস্টারগুলির মধ্যে ডেটা সিঙ্ক্রোনাইজেশনের প্রক্রিয়া শুরু হয়েছে। ক্লাস্টারের সমস্ত নোডের মধ্যে সমস্ত ডেটা সিঙ্ক্রোনাইজ হয়ে গেলে, আমরা নতুন ক্লাস্টার ব্যবহার করতে অ্যাপ্লিকেশনটি স্যুইচ করতে পারি:

এই ক্রিয়াকলাপগুলির পরে, RabbitMQ ক্লাস্টার থেকে পুরানো নোডগুলি অপসারণ করা যথেষ্ট এবং পদক্ষেপটি সম্পূর্ণ হিসাবে বিবেচিত হতে পারে:

আমরা এই স্কিমটি উৎপাদনে বহুবার ব্যবহার করেছি। যাইহোক, আমাদের নিজস্ব সুবিধার জন্য, আমরা এটিকে একটি বিশেষ সিস্টেমের মধ্যে প্রয়োগ করেছি যা একাধিক কুবারনেটস ক্লাস্টারে স্ট্যান্ডার্ড RMQ কনফিগারেশন বিতরণ করে। (যারা কৌতূহলী তাদের জন্য: আমরা কথা বলছি অ্যাডন-অপারেটরযা সম্পর্কে আমরা সম্প্রতি বলেছেন). নীচে আমরা পৃথক নির্দেশাবলী উপস্থাপন করব যা যে কেউ তাদের ইনস্টলেশনে প্রয়োগ করতে পারে প্রস্তাবিত সমাধানটি কার্যকর করার জন্য।

এর অনুশীলনে এটি চেষ্টা করা যাক

প্রয়োজনীয়তা

বিবরণ খুব সহজ:

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 ডেটা সহ রয়েছে যা স্থানান্তর করা দরকার৷

একটি 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 ক্লাস্টার প্রস্তুত:

সমস্ত নোডের মধ্যে বার্তাগুলি সিঙ্ক্রোনাইজ হওয়ার সময় আপনাকে অবশ্যই অপেক্ষা করতে হবে৷ এটা অনুমান করা কঠিন নয় যে বার্তা সিঙ্ক্রোনাইজেশনের সময় নির্ভর করে হার্ডওয়্যারের ক্ষমতার উপর যার উপর ক্লাস্টার স্থাপন করা হয়েছে এবং বার্তার সংখ্যার উপর। বর্ণিত পরিস্থিতিতে, তাদের মধ্যে মাত্র 10টি রয়েছে, তাই ডেটা তাত্ক্ষণিকভাবে সিঙ্ক্রোনাইজ করা হয়েছিল, কিন্তু পর্যাপ্ত পরিমাণে বার্তাগুলির সাথে, সিঙ্ক্রোনাইজেশন কয়েক ঘন্টা স্থায়ী হতে পারে।

সুতরাং, সিঙ্ক্রোনাইজেশন অবস্থা:

এটা হল +5 মানে বার্তা ইতিমধ্যেই আছে অধিক 5টি নোডে (ক্ষেত্রে যা নির্দেশ করা হয়েছে তা ছাড়া Node) এইভাবে, সিঙ্ক্রোনাইজেশন সফল হয়েছে।

4. যা অবশিষ্ট থাকে তা হল অ্যাপ্লিকেশনটিতে থাকা RMQ ঠিকানাটিকে নতুন ক্লাস্টারে পরিবর্তন করা (এখানে নির্দিষ্ট ক্রিয়াগুলি নির্ভর করে আপনি যে প্রযুক্তি স্ট্যাকটি ব্যবহার করছেন এবং অন্যান্য অ্যাপ্লিকেশন সুনির্দিষ্টতার উপর), যার পরে আপনি পুরানোটিকে বিদায় জানাতে পারেন৷

শেষ অপারেশনের জন্য (যেমন ইতিমধ্যেই после অ্যাপ্লিকেশনটিকে একটি নতুন ক্লাস্টারে স্যুইচ করা) প্রতিটি নোডে যান পুরাতন ক্লাস্টার এবং কমান্ড চালান:

rabbitmqctl stop_app
rabbitmqctl reset

ক্লাস্টারটি পুরানো নোডগুলি সম্পর্কে "ভুলে গেছে": আপনি পুরানো RMQ মুছে ফেলতে পারেন, যেখানে সরানো সম্পূর্ণ হবে।

মন্তব্য: আপনি যদি শংসাপত্রের সাথে RMQ ব্যবহার করেন, তাহলে মৌলিকভাবে কিছুই পরিবর্তন হয় না - চলমান প্রক্রিয়াটি ঠিক একইভাবে পরিচালিত হবে।

তথ্যও

বর্ণিত স্কিমটি প্রায় সব ক্ষেত্রেই উপযুক্ত যখন আমাদের RabbitMQ স্থানান্তর করতে হবে বা কেবল একটি নতুন ক্লাস্টারে যেতে হবে।

আমাদের ক্ষেত্রে, অসুবিধাগুলি শুধুমাত্র একবারই দেখা দিয়েছিল, যখন অনেক জায়গা থেকে RMQ অ্যাক্সেস করা হয়েছিল, এবং আমাদের কাছে RMQ ঠিকানাটিকে সর্বত্র নতুন করে পরিবর্তন করার সুযোগ ছিল না। তারপরে আমরা একই লেবেল সহ একই নেমস্পেসে একটি নতুন RMQ চালু করেছি যাতে এটি বিদ্যমান পরিষেবা এবং প্রবেশের আওতায় পড়ে এবং পডটি চালু করার সময় আমরা হাত দিয়ে লেবেলগুলিকে ম্যানিপুলেট করেছিলাম, সেগুলিকে শুরুতে সরিয়ে দিয়েছিলাম যাতে অনুরোধগুলি না পড়ে খালি RMQ, এবং বার্তাগুলি সিঙ্ক্রোনাইজ হওয়ার পরে সেগুলি আবার যোগ করা।

পরিবর্তিত কনফিগারেশন সহ একটি নতুন সংস্করণে RabbitMQ আপডেট করার সময় আমরা একই কৌশল ব্যবহার করেছি - সবকিছু একটি ঘড়ির মতো কাজ করেছিল।

দ্রষ্টব্য

এই উপাদানটির একটি যৌক্তিক ধারাবাহিকতা হিসাবে, আমরা MongoDB (একটি হার্ডওয়্যার সার্ভার থেকে Kubernetes-এ স্থানান্তর) এবং MySQL (কিভাবে আমরা কুবারনেটসের ভিতরে এই DBMS প্রস্তুত করব) সম্পর্কে নিবন্ধ তৈরি করছি। সেগুলো আগামী মাসে প্রকাশিত হবে।

PPS

আমাদের ব্লগেও পড়ুন:

• «ডাটাবেস এবং কুবারনেটস (ওভারভিউ এবং ভিডিও রিপোর্ট)";
• «K8s টিপস এবং কৌশল: বড় ডাটাবেসের জন্য বুটস্ট্র্যাপ গতি বাড়ান».

উত্স: www.habr.com