haproxy و ردیس کلاستر

ردیس یک محدودیت خیلی مهمی داره و اون اینکه single thread  و برای همین نمی‌تونه  بیشتر از  یک core از پردازشگر رو استفاده کنه. یکی از راه‌حل‌های روتین استفاده از کلاستر ردیس که عملا اطلاعات بین چند node ردیس پخش میشه(sharding)‌. نکته مهم اینه که در این مدل شما چند نود ردیس به شکل master  دارید که هر کدوم از اونها باید دست کم یک slave داشته باشند تا در صورتیکه یک نود به هر دلیل از دسترس خارج شد، نود slave به صورت خودکار وارد بازی بشه.

در این پروسه  هیچ تضمینی برای اینکه اطلاعات از دست نره (در زمان از دست رفتن نود master)‌ وجود نداره! دلیلش اینه که شما اطلاعات رو روی node مستر می‌نویسید، نود مستر به کلاینت میگه اوکی دیتا رو دارم و بعد تازه میره دنبال اینکه دیتا  روی نود slave هم ذخیره بشه. :)‌

این رو هم بگم که برای اینکه دیتا به شکل مساوی بین node های مستر پخش بشه، کلاستر ردیس از چیزی به اسم SLOT استفاده میکنه. در مجموع ۱۶۳۸۴ اسلات ردیس کلاستر داره که بسته به تعداد node هایی که داریم میاییم اسلات ها رو بین نودها تقسیم میکنیم.

کلاینت در صورتی که به یک node (مستر) درخواست بده واطلاعات روی اون  نباشه، بجای اینکه کلید درخواستی رو بده، اطلاعات nodeی رو  که کلید داره رو میده و دوباره کلاینت باید به اون دومی درخواست بده 🙂  و  این میشه همون سربار یا overhead که ردیس کلاستر به ردیس معمولی داره بعلاوه اینکه یک سری محدودیت ها رو هم خواهید داشت مثل اینکه نمیشه از قابلیت Geo location ردیس استفاه کنید .

حالا نکته اینجاس که اگر کلاینت به یک نود مستر وصل شه و اون نود به هر دلیل داون بشه، هر چند slave به شکل خودکار تبدیل به مستر میشه، اما دیگه کلاینت از اون نود اطلاعی نداره!‌ برای حل این مشکل از لودبالانس HAPROXY استفاده میکنیم.

خودم haproxy رو به دلایل خیلی زیادی با داکر همیشه بالا میارم که کار رو خیلی ساده میکنه و برای اینکار هم لازم نیست همه چی رو از اول بسازیم، از یک داکر اماده استفاده میکنیم.

و بعد باید اون رو build کنیم.

قبل از اجرای تنظیمات باید یک کانفیگ haproxy ایجاد کنیم که اون رو به خورد کانتینر بدیم.

بخش frontend باعث میشه haproxy روی پورت  ۶۳۷۹ لیستن کنه و هر ترافیکی هم که به سمتش بیاد رو به  backend پیشفرضی که تعریف کردیم، بفرسته.

در بخش backend که قلب اصلی سیستم، haproxy  به نودهای فقط master ترافیک رو می‌فرسته. نکته قشنگ کار اینه که در اینجا همه نود های redis چه مستر و چه slave رو میدیم و از haproxy میخوایم بره وضعیت نودها رو خوش در بیاره. haproxy هم هر یک ثانیه میره از نودهای ردیس میپرسه که شما مسترسی یا salve  و اونها هم اگر جواب بدند مستر، به رنگ سبز در میان و اگر slave باشند دیگه از دور خارج میشند و عملا ترافیکی به سمت اونها نمیره 🙂

در بخش stats هم که صرفا امار haproxy رو فعال کردیم و کار مهمی انجام نمیده، بخش اول nbproc هم نمایانگر تعداد core های سرور و اینجا با فرض اینکه سرور هفت core پردازشی داره، شش تا از اونها رو بدین شکل به خورد haproxy میدیم 🙂 haproxy هم مشابه nginx میاد به تعداد core هایی که مشخص کردیم child میسازه.

و در نهایت داکر ha رو با کامند زیر اجرا می‌کنیم.

یک قابلیت خوب این کانتینر اینه که میشه کانفیگ haproxy روی سرور اصلی رو ویرایش کرد، کانتینر به شکل خودکار متوجه این امر میشه و در صورتی که مشکلی در سینتکس وجود نداشته باشه، تغییر رو اعمال میکنه. برای اینکه از این قابلیت استفاده کنید باید تغییری در ادیتور vim بدیم.

 

و در نهایت اینکه اگر سرورتون زیر بار خیلی زیادی حتما تنظیمات زیر داخل sysctl فراموش نشه.

 

The short URL of the present article is: https://wp.me/p1SRCG-Hj

2 دیدگاه برای “haproxy و ردیس کلاستر”

  1. درود بر شما نوید جان
    دستت درد نکنه بابت این مطلب.فقط یه نکته اینکه و اون هم هست که اونجا که گفته بودی :
    «یک قابلیت خوب این کانتینر اینه که میشه کانفیگ haproxy روی سرور اصلی رو ویرایش کرد، کانتینر به شکل خودکار متوجه این امر میشه و در صورتی که مشکلی در سینتکس وجود نداشته باشه، تغییر رو اعمال میکنه. برای اینکه از این قابلیت استفاده کنید باید تغییری در ادیتور vim بدیم.»

    فرض کن ما فایل تنظیمات haproxy رو روی host ویرایش کردیم.آیا با این چیزی که گفتی آیا کانتینر/haproxy خودکار restart میشه!؟دقیقا چه اتفاقی می افته؟

    سپاس

    1. سلام حسین جان
      اره عزیزم، خودکار هم ریست میشه :ی میاد اول چک میکنه از لحاظ سینتکسی مشکل نداشته باشه و اگر همه چی بدون مشکل باشه reload میده خیلی نرم و بدون تقریبا هیچ خونریزی و اینکه کسی متوجه شه این اتفاق می یوفته 🙂

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *