سلام
با یه بنده خدایی بحثم شد ایشون رو که نتونستم قانع کنم فعلا ولی دوست دارم حداقل افراد عاقلی که این پستو میخونن رو قانع کنم.
خیلی دوست دارم از کلاسترینگ بگم یا بهتره بگم سرویس توزیع شده کلاستری. شاید اولش خیلی تئوری بنظر بیاد ولی اگر حوصله کنم بنویسم سر ۲ هفته بدجور عملی میشه. توی مبحث سیستم های توزیع شده ما موضوعی به اسم Consensus داریم. همونطور که اسمش میگه الگوریتم های تجمیع زیرساخت هر سرویس کلاستری ای هستن و مثالشون رو جلوتر میزنم روز به روز ازشون استفاده میکنیم و خبر نداریم. در اصل اتفاقی که میفته چند تا Node با هم به نتیجه میرسن که حالت فعلی چیه و چکار باید بکنن.
مرسوم ترین این الگوریتم ها Paxos ( که زوکیپر نسخه مشابه به این رو برای خودش طراحی کرده استفاده میکنه و چندین اپلیکیشن معروف دیگه) و Raft ( که Etcd استفاده میکنه ازش و Corosync ( که بعدا راجع بهش مینویسم)). Paxos الگوریتم نسبتا پیچیده ایه و موقعی که Raft رو رونمایی کردن عملا گفتن که الگوریتم ساده تر و قابل فهم تر از Paxos رو مطرح کردن. مقداری Raft رو توضیح میدم تا بعدا که چیزای جالب تر بنویسم.
ساده ترین حالتی که بخوام رفت رو توضیح بدم اینطور هست که ابتدا تعدادی نود (معمولا تعداد فرد که دلیلش رو میگم بزودی) کانفیگ میشن که از این الگوریتم استفاده کنن. هرکدوم از این نود ها یه تایمری داره که بعد از تموم شدنش به همه Heartbeat میفرسته و ازشون فیدبک میگیره و تایمر رو ریست میکنه (چیزی که میگن این هست که این تایمر رو حدودا مشابه با RTT بزارید) طبق الگوریتم Leader Election (انتخاب رهبر) اولین نودی که متوجه نبود لیدر میشه به همه نود ها تقاضای لیدر شدن میفرسته و بعد از گرفتن پاسخ تبدیل به لیدر میشه. فرض کنیم میخوایم مقداری رو در تمامی نود ها اضافه کنیم. این تغییر رو به نود لیدر میفرستیم تا اعمال کنه- بعد لیدر به همه نود ها این تغییر رو ارسال میکنه و پیامی ازشون دریافت میکنه که متوجه بشه تغییرات در همه نود ها اعمال شدن.
یه نکته ای که وجود داره این هست که کلاستر ما تا وقتی کار میکنه بیشتر از نصف (Quorum) نود فعال باشن. یعنی وقتی از ۵ نود ۲ نود زنده باشن کلاستر ما متوقف میشه. دلیلش چیه؟
فرض کنیم اینطوری نبود و درصورتی که از ۵ نود ۲ نود زنده بودن کلاستر کار میکرد. تو همین حالت تصور کنید همه ۵ نود زنده هستن و بطور ناگهانی بین نود ها پارتیشنی صورت میگیره و از سمت نتوورکی ۳ نود از ۲ نود جدا میشن. الان ۳ نود ما فکر میکنه همه چی رواله و به کارش ادامه میده بطور همزمان ۲ نود هم فکر میکنن همه چی رواله و به کارشون ادامه میدن. اتفاقی که افتاد این هست که ما الان ۲ تا لیدر داریم که تغییرات رو اعمال میکنن!!!!!! به این حالت Split-Brain میگن. چون نصف دیتای ما با نصف دیگه فرق داره و مغز جدایی دارن! پس برای جلوگیری از این مشکل این شرط رو گذاشتن که فقط و فقط درصورت وجود quorum تغییرات "کامیت" بشن. در این صورت اگر پارتیشن پیش بیاد پارتیشن ۲ نودیمون تغییرات رو اعمال نمیکنه چون چیزی که میبینه این هست که نصف کمتر نود ها فعالن- بطور همزمان سمت پارتیشن ۳ نودمون همه تغییرات اعمال میشه و بعد از حل پارتیشن که ۲ نود به ۳ نود می پیوندن دیتا "synchronize" میشه.
سوالات:
اولین سوال: RTT چیست؟ زمانی که طول میکشه رکوئست شما به نود دیگه برسه و نتیجش برگرده.
سوال بعدی: چرا تعداد نودارو زوج نذاریم؟ فرض کنید ۸ نود داشته باشیم. نصف این نود ها میشن ۴- طبق چیزی که بررسی کردیم Fault Tolerance ما با ۸ نود میشه ۳ (همواره باید بیشتر از نصف نود های زنده باشن که میشه ۵ نود- هشت منهای پنج هم میشه ۳). اگر ۷ نود هم داشته باشیم باز تا ۳ نود FT داریم. پس عملا نود اضافی گذاشتیم که نه تنها کمکی نمیکنه- بلکه یه نقطه خرابی و دردسر دیگست.
سوال بعدی: FT چیه؟ Fault Tolerance یعنی تعداد نود هایی که میتونیم از دست بدیم و سرویس زنده بمونه. معمولا این عدد n/2-1 هست.
اینایی که گفتم مسخره بازی یا تئوری نیستا! کوبرنتیزی که همه "عاشقش" هستیم از Etcd استفاده میکنه که اونم از Raft استفاده میکنه.
تعدادی نتیجه گوگل سرچ جالب:
1. Some deployment tools set up Raft consensus algorithm to do leader election of Kubernetes services.
2. Zab (ZooKeeper Atomic Broadcast) is the Paxos- variant consensus protocol that powers the core of ZooKeeper, a popular open-source Paxos system.
3. http://thesecretlivesofdata.com/raft/#home
4. https://en.wikipedia.org/wiki/Paxos_(computer_science)
با یه بنده خدایی بحثم شد ایشون رو که نتونستم قانع کنم فعلا ولی دوست دارم حداقل افراد عاقلی که این پستو میخونن رو قانع کنم.
خیلی دوست دارم از کلاسترینگ بگم یا بهتره بگم سرویس توزیع شده کلاستری. شاید اولش خیلی تئوری بنظر بیاد ولی اگر حوصله کنم بنویسم سر ۲ هفته بدجور عملی میشه. توی مبحث سیستم های توزیع شده ما موضوعی به اسم Consensus داریم. همونطور که اسمش میگه الگوریتم های تجمیع زیرساخت هر سرویس کلاستری ای هستن و مثالشون رو جلوتر میزنم روز به روز ازشون استفاده میکنیم و خبر نداریم. در اصل اتفاقی که میفته چند تا Node با هم به نتیجه میرسن که حالت فعلی چیه و چکار باید بکنن.
مرسوم ترین این الگوریتم ها Paxos ( که زوکیپر نسخه مشابه به این رو برای خودش طراحی کرده استفاده میکنه و چندین اپلیکیشن معروف دیگه) و Raft ( که Etcd استفاده میکنه ازش و Corosync ( که بعدا راجع بهش مینویسم)). Paxos الگوریتم نسبتا پیچیده ایه و موقعی که Raft رو رونمایی کردن عملا گفتن که الگوریتم ساده تر و قابل فهم تر از Paxos رو مطرح کردن. مقداری Raft رو توضیح میدم تا بعدا که چیزای جالب تر بنویسم.
ساده ترین حالتی که بخوام رفت رو توضیح بدم اینطور هست که ابتدا تعدادی نود (معمولا تعداد فرد که دلیلش رو میگم بزودی) کانفیگ میشن که از این الگوریتم استفاده کنن. هرکدوم از این نود ها یه تایمری داره که بعد از تموم شدنش به همه Heartbeat میفرسته و ازشون فیدبک میگیره و تایمر رو ریست میکنه (چیزی که میگن این هست که این تایمر رو حدودا مشابه با RTT بزارید) طبق الگوریتم Leader Election (انتخاب رهبر) اولین نودی که متوجه نبود لیدر میشه به همه نود ها تقاضای لیدر شدن میفرسته و بعد از گرفتن پاسخ تبدیل به لیدر میشه. فرض کنیم میخوایم مقداری رو در تمامی نود ها اضافه کنیم. این تغییر رو به نود لیدر میفرستیم تا اعمال کنه- بعد لیدر به همه نود ها این تغییر رو ارسال میکنه و پیامی ازشون دریافت میکنه که متوجه بشه تغییرات در همه نود ها اعمال شدن.
یه نکته ای که وجود داره این هست که کلاستر ما تا وقتی کار میکنه بیشتر از نصف (Quorum) نود فعال باشن. یعنی وقتی از ۵ نود ۲ نود زنده باشن کلاستر ما متوقف میشه. دلیلش چیه؟
فرض کنیم اینطوری نبود و درصورتی که از ۵ نود ۲ نود زنده بودن کلاستر کار میکرد. تو همین حالت تصور کنید همه ۵ نود زنده هستن و بطور ناگهانی بین نود ها پارتیشنی صورت میگیره و از سمت نتوورکی ۳ نود از ۲ نود جدا میشن. الان ۳ نود ما فکر میکنه همه چی رواله و به کارش ادامه میده بطور همزمان ۲ نود هم فکر میکنن همه چی رواله و به کارشون ادامه میدن. اتفاقی که افتاد این هست که ما الان ۲ تا لیدر داریم که تغییرات رو اعمال میکنن!!!!!! به این حالت Split-Brain میگن. چون نصف دیتای ما با نصف دیگه فرق داره و مغز جدایی دارن! پس برای جلوگیری از این مشکل این شرط رو گذاشتن که فقط و فقط درصورت وجود quorum تغییرات "کامیت" بشن. در این صورت اگر پارتیشن پیش بیاد پارتیشن ۲ نودیمون تغییرات رو اعمال نمیکنه چون چیزی که میبینه این هست که نصف کمتر نود ها فعالن- بطور همزمان سمت پارتیشن ۳ نودمون همه تغییرات اعمال میشه و بعد از حل پارتیشن که ۲ نود به ۳ نود می پیوندن دیتا "synchronize" میشه.
سوالات:
اولین سوال: RTT چیست؟ زمانی که طول میکشه رکوئست شما به نود دیگه برسه و نتیجش برگرده.
سوال بعدی: چرا تعداد نودارو زوج نذاریم؟ فرض کنید ۸ نود داشته باشیم. نصف این نود ها میشن ۴- طبق چیزی که بررسی کردیم Fault Tolerance ما با ۸ نود میشه ۳ (همواره باید بیشتر از نصف نود های زنده باشن که میشه ۵ نود- هشت منهای پنج هم میشه ۳). اگر ۷ نود هم داشته باشیم باز تا ۳ نود FT داریم. پس عملا نود اضافی گذاشتیم که نه تنها کمکی نمیکنه- بلکه یه نقطه خرابی و دردسر دیگست.
سوال بعدی: FT چیه؟ Fault Tolerance یعنی تعداد نود هایی که میتونیم از دست بدیم و سرویس زنده بمونه. معمولا این عدد n/2-1 هست.
اینایی که گفتم مسخره بازی یا تئوری نیستا! کوبرنتیزی که همه "عاشقش" هستیم از Etcd استفاده میکنه که اونم از Raft استفاده میکنه.
تعدادی نتیجه گوگل سرچ جالب:
1. Some deployment tools set up Raft consensus algorithm to do leader election of Kubernetes services.
2. Zab (ZooKeeper Atomic Broadcast) is the Paxos- variant consensus protocol that powers the core of ZooKeeper, a popular open-source Paxos system.
3. http://thesecretlivesofdata.com/raft/#home
4. https://en.wikipedia.org/wiki/Paxos_(computer_science)
👍7