خوشه ای از دو گره - شیطان در جزئیات است

هی هابر! ترجمه مقاله را مورد توجه شما قرار می دهم "دو گره - شیطان در جزئیات است" توسط اندرو بکهوف

بسیاری از مردم خوشه های دو گره را ترجیح می دهند زیرا از نظر مفهومی ساده تر به نظر می رسند و همچنین 33٪ ارزان تر از همتایان سه گره خود هستند. اگرچه جمع کردن یک خوشه خوب از دو گره کاملاً ممکن است، اما در بیشتر موارد، به دلیل سناریوهای بررسی نشده، چنین پیکربندی بسیاری از مشکلات نامشخص را ایجاد می کند.

اولین گام برای ایجاد هر سیستم با دسترسی بالا، یافتن و تلاش برای حذف نقاط شکست منفرد است که اغلب به اختصار به آنها گفته می شود. SPoF (تک نقطه شکست).

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

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

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

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

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

بنابراین، برای جلوگیری از خراب شدن داده ها در نتیجه شکست یک گره - ما به چیزی به نام تکیه می کنیم "تجزیه" (شمشیربازی).

اصل تفکیک

در قلب اصل تفکیک این سوال وجود دارد: آیا یک گره رقیب می تواند باعث خرابی داده ها شود؟ در صورتی که خرابی داده ها یک سناریوی محتمل باشد، یک راه حل خوب جداسازی گره از درخواست های دریافتی و ذخیره سازی مداوم است. متداول ترین رویکرد برای جداسازی، جدا کردن گره های معیوب است.

دو دسته از روش های تفکیک وجود دارد که من آنها را نام می برم مستقیما и غیرمستقیم، اما می توان آنها را به همان اندازه نامید فعال и منفعل. روش‌های مستقیم شامل اقداماتی از جانب همتایان بازمانده، مانند تعامل با دستگاه IPMI (رابط مدیریت پلتفرم هوشمند) یا iLO (مکانیسمی برای مدیریت سرورها در صورت عدم دسترسی فیزیکی به آنها) است، در حالی که روش‌های غیرمستقیم متکی به خرابی هستند. گره به نحوی تشخیص دهد که در وضعیت ناسالم قرار دارد (یا حداقل از بهبود سایر اعضا جلوگیری می کند) و سیگنال نگهبان سخت افزار در مورد نیاز به قطع اتصال گره شکست خورده.

Quorum هنگام استفاده از هر دو روش مستقیم و غیر مستقیم کمک می کند.

تفکیک مستقیم

در مورد جداسازی مستقیم، می‌توانیم از حد نصاب برای جلوگیری از مسابقات جداسازی در صورت خرابی شبکه استفاده کنیم.

با مفهوم حد نصاب، اطلاعات کافی در سیستم (حتی بدون اتصال به همتایان آن) وجود دارد تا گره ها به طور خودکار بدانند که آیا باید جداسازی و/یا بازیابی را آغاز کنند.

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

مشکل جداسازی این است که متداول‌ترین دستگاه‌های مورد استفاده به دلیل همان رویدادهای خرابی که می‌خواهیم برای بازیابی هدف قرار دهیم، از دسترس خارج می‌شوند. اکثر کارت‌های IPMI و iLO بر روی هاست‌هایی که کنترل می‌کنند نصب می‌شوند و به‌طور پیش‌فرض از همان شبکه استفاده می‌کنند، که باعث می‌شود میزبان‌های هدف باور کنند که میزبان‌های دیگر آفلاین هستند.

متأسفانه، ویژگی های عملکرد دستگاه های IPMI و iLo به ندرت در زمان خرید تجهیزات در نظر گرفته می شود.

تفکیک غیر مستقیم

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

با این پیکربندی، اگر حد نصاب از بین نرود، تایمر نگهبان سخت افزار هر N ثانیه بازنشانی می شود. اگر تایمر (معمولاً چندین مضرب N) منقضی شود، دستگاه یک خاموش کردن نامطلوب (نه خاموش شدن) انجام می دهد.

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

مشکل انتخاب یک حالت این است که هیچ اقدامی وجود ندارد که دسترسی را به حداکثر برساند و از از دست رفتن داده ها جلوگیری کند.

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

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

اگر جایگزین دیگری وجود نداشته باشد، بهترین رویکرد این است که در دسترس بودن را قربانی کنیم (در اینجا نویسنده به قضیه CAP اشاره می کند). در دسترس بودن زیاد داده های خراب به هیچ کس کمک نمی کند، و تطبیق دستی مجموعه داده های مختلف نیز سرگرم کننده نیست.

حد نصاب

Quorum عالی به نظر می رسد، درست است؟

تنها نقطه ضعف این است که برای اینکه آن را در یک خوشه با N عضو داشته باشید، باید بین N/2+1 از گره‌های باقیمانده خود ارتباط برقرار کنید. که در یک خوشه دو گره پس از شکست یک گره امکان پذیر نیست.

که در نهایت ما را به مشکل اساسی با دو گره می رساند:
حد نصاب در دو خوشه گره معنا ندارد و بدون آن نمی توان به طور قابل اعتماد مسیر عملی را تعیین کرد که دسترسی را به حداکثر می رساند و از از دست رفتن داده ها جلوگیری می کند.
حتی در سیستمی متشکل از دو گره که توسط یک کابل متقاطع به هم متصل شده اند، تشخیص قطعی بین قطع شبکه و خرابی گره دیگر غیرممکن است. غیرفعال کردن یک انتها (که البته احتمال آن متناسب با فاصله بین گره ها است) برای باطل کردن هر گونه فرضی که سلامت پیوند با سلامت گره شریک برابر است، کافی است.

ساخت یک خوشه دو گره کار می کند

گاهی اوقات مشتری نمی تواند یا نمی خواهد یک گره سوم را خریداری کند و ما مجبور می شویم به دنبال جایگزین باشیم.

گزینه 1 - روش تفکیک تکراری

دستگاه iLO یا IPMI یک گره نشان دهنده یک نقطه شکست است زیرا در صورت شکست، بازماندگان نمی توانند از آن برای رساندن گره به حالت ایمن استفاده کنند. در خوشه‌ای از 3 یا بیشتر گره، می‌توانیم با محاسبه حد نصاب و استفاده از یک محافظ سخت‌افزار (مکانیسم جداسازی غیرمستقیم، همانطور که قبلاً بحث شد) این را کاهش دهیم. در مورد دو گره، ما باید به جای آن از واحدهای توزیع توان شبکه (PDUs) استفاده کنیم.

پس از یک شکست، بازمانده ابتدا سعی می کند با دستگاه جداسازی اولیه (iLO یا IPMI تعبیه شده) تماس بگیرد. در صورت موفقیت آمیز بودن، بهبودی به طور معمول ادامه می یابد. تنها در صورتی که دستگاه iLO/IPMI از کار بیفتد، PDU قابل دسترسی است؛ اگر دسترسی موفقیت آمیز باشد، بازیابی می تواند ادامه یابد.

مطمئن شوید که PDU را در شبکه ای متفاوت از ترافیک کلاستر قرار دهید، در غیر این صورت یک شکست شبکه، دسترسی به هر دو دستگاه جداسازی را مسدود می کند و بازیابی سرویس ها را مسدود می کند.

در اینجا ممکن است بپرسید - آیا PDU تنها نقطه شکست است؟ که جوابش البته هست.

اگر این خطر برای شما مهم است، شما تنها نیستید: هر دو گره را به دو PDU متصل کنید و به نرم افزار خوشه بندی بگویید هنگام روشن و خاموش کردن گره ها از هر دو استفاده کند. در صورت از بین رفتن یکی از PDUها، خوشه فعال باقی می ماند و برای جلوگیری از بازیابی، به خرابی دوم PDU دیگر یا دستگاه IPMI نیاز است.

گزینه 2 - اضافه کردن یک داور

در برخی سناریوها، در حالی که روش تفکیک تکراری از نظر فنی امکان پذیر است، اما از نظر سیاسی دشوار است. بسیاری از شرکت‌ها دوست دارند بین مدیران و صاحبان برنامه‌ها فاصله‌ای داشته باشند، و مدیران شبکه‌های آگاه از امنیت همیشه مشتاق به اشتراک‌گذاری تنظیمات دسترسی PDU با کسی نیستند.

در این مورد، جایگزین پیشنهادی ایجاد یک شخص ثالث خنثی است که بتواند محاسبه حد نصاب را تکمیل کند.

در صورت خرابی، یک گره باید بتواند امواج هوایی همتا یا داور خود را ببیند تا بتواند خدمات را بازیابی کند. اگر هر دو گره بتوانند داور را ببینند اما نتوانند یکدیگر را ببینند، داور دارای یک تابع قطع ارتباط است.

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

تفاوت عملی بین یک داور و یک گره سوم این است که یک داور به منابع بسیار کمتری برای کار نیاز دارد و به طور بالقوه می تواند به بیش از یک خوشه خدمت کند.

گزینه 3 - عامل انسانی

رویکرد نهایی این است که بازماندگان به اجرای سرویس‌هایی که قبلاً اجرا می‌کردند ادامه دهند، اما تا زمانی که مشکل خود به خود حل نشود (بازیابی شبکه، راه‌اندازی مجدد گره) یا شخصی مسئولیت تایید دستی مرده بودن طرف مقابل را بر عهده نگیرد، سرویس‌های جدیدی را شروع نکنند.

گزینه جایزه

آیا اشاره کردم که می توانید یک گره سوم اضافه کنید؟

دو قفسه

برای بحث، بیایید وانمود کنیم که من شما را به شایستگی گره سوم متقاعد کرده ام، اکنون باید آرایش فیزیکی گره ها را در نظر بگیریم. اگر آنها در یک رک قرار داشته باشند (و تغذیه شوند)، این نیز به منزله SPoF است و با افزودن یک رک دوم قابل حل نیست.

اگر این تعجب آور است، در نظر بگیرید که اگر یک رک با دو گره از کار بیفتد چه اتفاقی می افتد، و چگونه گره باقی مانده بین آن و یک شکست شبکه تفاوت قائل می شود.

پاسخ کوتاه این است که امکان پذیر نیست و دوباره با تمام مشکلات موجود در مورد دو گره روبرو هستیم. یا بازمانده:

• حد نصاب را نادیده می گیرد و به اشتباه تلاش می کند تا در هنگام قطع شدن شبکه، بازیابی را آغاز کند (توانایی کامل جداسازی داستان متفاوتی است و بستگی به این دارد که آیا PDU درگیر است و آیا آنها برق را با هر یک از رک ها به اشتراک می گذارند)، یا
• به حد نصاب احترام می گذارد و زمانی که گره همتایش از کار بیفتد، خود را زودتر از موعد قطع می کند

در هر صورت، دو رک بهتر از یکی نیستند، و گره ها باید منابع تغذیه مستقل دریافت کنند یا در سه (یا بیشتر، بسته به تعداد گره های شما) رک توزیع شوند.

دو مرکز داده

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

اگر به درستی انجام شود، مرکز داده دوم یک نسخه به‌روز و ثابت از خدمات و داده‌های آن‌ها را در اختیار شما قرار می‌دهد. با این حال، مانند سناریوهای دو گره، دو رک، اطلاعات کافی در سیستم برای اطمینان از حداکثر در دسترس بودن و جلوگیری از فساد (یا اختلاف مجموعه داده ها) وجود ندارد. حتی با وجود سه گره (یا رک)، توزیع آن‌ها در تنها دو مرکز داده باعث می‌شود که سیستم نتواند به‌طور قابل اعتماد تصمیم درستی را در صورت وقوع یک رویداد (اکنون بسیار محتمل‌تر) اتخاذ کند که هر دو طرف نمی‌توانند ارتباط برقرار کنند.

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

منبع: www.habr.com