🥇 مهاجرت آرام RabbitMQ به Kubernetes

RabbitMQ یک کارگزار پیام است که به زبان Erlang نوشته شده است که به شما امکان می دهد یک خوشه failover با تکثیر کامل داده در چندین گره سازماندهی کنید، جایی که هر گره می تواند درخواست های خواندن و نوشتن را ارائه دهد. با داشتن بسیاری از خوشه های Kubernetes در عملیات تولید، ما از تعداد زیادی نصب RabbitMQ پشتیبانی می کنیم و با نیاز به انتقال داده ها از یک خوشه به خوشه دیگر بدون توقف مواجه شدیم.

حداقل در دو مورد به این عمل نیاز داشتیم:

انتقال داده ها از یک خوشه RabbitMQ که در Kubernetes قرار ندارد به یک خوشه جدید - که قبلاً "kubernetized" شده است (یعنی در غلاف های K8s کار می کند).
مهاجرت RabbitMQ در Kubernetes از یک فضای نام به فضای نام دیگر (به عنوان مثال، اگر مدارها با فضاهای نام محدود شوند، سپس برای انتقال زیرساخت از یک مدار به مدار دیگر).

دستور العمل ارائه شده در مقاله بر موقعیت هایی متمرکز است (اما به هیچ وجه به آنها محدود نمی شود) که در آن یک خوشه قدیمی RabbitMQ (به عنوان مثال از 3 گره) وجود دارد که در حال حاضر در K8s یا در برخی از سرورهای قدیمی قرار دارد. یک برنامه میزبانی شده در Kubernetes (در حال حاضر یا در آینده) با آن کار می کند:

... و ما با وظیفه انتقال آن به تولید جدید در Kubernetes روبرو هستیم.

ابتدا رویکرد کلی خود مهاجرت شرح داده خواهد شد و پس از آن جزئیات فنی اجرای آن شرح داده خواهد شد.

الگوریتم مهاجرت

اولین مرحله، مقدماتی، قبل از هر اقدامی، بررسی فعال بودن حالت دسترسی بالا در نصب قدیمی RabbitMQ است (HA). دلیل واضح است - ما نمی خواهیم هیچ داده ای را از دست بدهیم. برای انجام این بررسی، می توانید به پنل مدیریت RabbitMQ بروید و در تب Admin → Policies مطمئن شوید که مقدار تنظیم شده است. ha-mode: all:

گام بعدی این است که یک خوشه RabbitMQ جدید در پادهای Kubernetes ایجاد کنیم (مثلاً در مورد ما از 3 گره تشکیل شده است، اما تعداد آنها ممکن است متفاوت باشد).

پس از این، ما خوشه های قدیمی و جدید RabbitMQ را ادغام می کنیم و یک خوشه واحد (از 6 گره) به دست می آوریم:

فرآیند همگام سازی داده ها بین خوشه های قدیمی و جدید RabbitMQ آغاز شده است. هنگامی که همه داده ها بین تمام گره های خوشه همگام شدند، می توانیم برنامه را برای استفاده از خوشه جدید تغییر دهیم:

پس از انجام این عملیات، کافی است گره های قدیمی را از خوشه RabbitMQ حذف کنید و این حرکت را می توان کامل در نظر گرفت:

ما بارها از این طرح در تولید استفاده کرده ایم. با این حال، برای راحتی خود، آن را در یک سیستم تخصصی پیاده‌سازی کردیم که پیکربندی‌های استاندارد RMQ را در چندین خوشه Kubernetes توزیع می‌کند. (برای کسانی که کنجکاو هستند: ما در مورد آن صحبت می کنیم اپراتور افزونهکه در مورد آن ما به تازگی گفته شده است). در زیر دستورالعمل‌های جداگانه‌ای را ارائه می‌کنیم که هر کسی می‌تواند در نصب‌های خود اعمال کند تا راه‌حل پیشنهادی را در عمل امتحان کند.

بیایید آن را در عمل امتحان کنیم

مقررات

جزئیات بسیار ساده است:

خوشه Kubernetes (minikube نیز کار خواهد کرد).
خوشه 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 جدید را در آن مستقر کنیم دوست فضای نام با یکسان 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 گره آماده است:

باید منتظر بمانید تا پیام ها بین همه گره ها همگام شوند. حدس زدن اینکه زمان همگام سازی پیام به ظرفیت سخت افزاری که خوشه روی آن مستقر است و تعداد پیام ها بستگی دارد دشوار نیست. در سناریوی توصیف شده، تنها 10 مورد از آنها وجود دارد، بنابراین داده ها فوراً همگام شدند، اما با تعداد کافی پیام ها، همگام سازی می تواند ساعت ها طول بکشد.

بنابراین، وضعیت همگام سازی:

اینجا +5 به این معنی است که پیام ها از قبل وارد شده اند بیشتر در 5 گره (به جز مواردی که در فیلد نشان داده شده است Node). بنابراین، همگام سازی موفقیت آمیز بود.

4. تنها چیزی که باقی می ماند این است که آدرس RMQ در برنامه را به خوشه جدید تغییر دهید (عملکردهای خاص در اینجا به پشته فناوری که استفاده می کنید و سایر مشخصات برنامه بستگی دارد)، پس از آن می توانید با قدیمی خداحافظی کنید.

برای آخرین عملیات (یعنی قبلا پس از تغییر برنامه به یک خوشه جدید) به هر گره بروید قدیمی خوشه بندی کنید و دستورات را اجرا کنید:

rabbitmqctl stop_app
rabbitmqctl reset

خوشه گره های قدیمی را فراموش کرده است: می توانید RMQ قدیمی را حذف کنید، در این مرحله حرکت تکمیل می شود.

یادداشت: اگر از RMQ با گواهی ها استفاده می کنید، هیچ چیز اساساً تغییر نمی کند - فرآیند جابجایی دقیقاً به همان صورت انجام می شود.

یافته ها

طرح توصیف شده تقریباً برای همه مواردی که ما نیاز به مهاجرت RabbitMQ یا به سادگی به یک خوشه جدید داریم مناسب است.

در مورد ما، مشکلات فقط یک بار به وجود آمد، زمانی که RMQ از مکان‌های زیادی قابل دسترسی بود و ما فرصتی برای تغییر آدرس RMQ به آدرس جدید در همه جا نداشتیم. سپس یک RMQ جدید در همان فضای نام با همان برچسب ها راه اندازی کردیم تا تحت سرویس ها و ورودی های موجود قرار گیرد و هنگام راه اندازی پاد، برچسب ها را با دست دستکاری کردیم و در ابتدا آنها را حذف کردیم تا درخواست ها روی RMQ را خالی کنید و بعد از همگام سازی پیام ها دوباره آنها را اضافه کنید.

ما هنگام به‌روزرسانی RabbitMQ به نسخه جدید با پیکربندی تغییر یافته از همان استراتژی استفاده کردیم - همه چیز مانند یک ساعت کار می‌کرد.

PS

به عنوان ادامه منطقی این مطالب، در حال آماده سازی مقالاتی در مورد MongoDB (مهاجرت از سرور سخت افزاری به Kubernetes) و MySQL (نحوه تهیه این DBMS در داخل Kubernetes) هستیم. در ماه های آینده منتشر خواهند شد.

PPS

در وبلاگ ما نیز بخوانید:

منبع: www.habr.com

مهاجرت یکپارچه RabbitMQ به Kubernetes