ابر مقاوم در برابر بلایا: چگونه کار می کند

هی هابر!

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

سیستم ذخیره سازی ابری مقاوم در برابر بلایا در سایت OST.

چه در داخل است

این خوشه دارای سرورهای Cisco UCS با Hypervisor VMware ESXi، دو سیستم ذخیره سازی INFINIDAT InfiniBox F2240، تجهیزات شبکه Cisco Nexus و همچنین سوئیچ های Brocade SAN است. این خوشه به دو سایت تقسیم می شود - OST و NORD، یعنی هر مرکز داده مجموعه ای یکسان از تجهیزات دارد. در واقع، این همان چیزی است که آن را ضد فاجعه می کند.

در یک سایت، عناصر اصلی نیز کپی شده اند (میزبان، سوئیچ SAN، شبکه).
این دو سایت با مسیرهای اختصاصی فیبر نوری، همچنین رزرو شده، به هم متصل می شوند.

چند کلمه در مورد سیستم های ذخیره سازی ما اولین نسخه یک ابر ضد فاجعه را در NetApp ساختیم. در اینجا ما INFINIDAT را انتخاب کردیم و دلیل آن این است:

• گزینه تکثیر Active-Active. این به ماشین مجازی اجازه می دهد حتی اگر یکی از سیستم های ذخیره سازی به طور کامل از کار بیفتد، عملیاتی باقی بماند. بعداً در مورد Replication بیشتر به شما خواهم گفت.
• سه کنترل کننده دیسک برای افزایش تحمل خطای سیستم. معمولا دو تا هستند.
• راه حل آماده ما یک رک از پیش مونتاژ شده دریافت کردیم که فقط باید به شبکه متصل شود و پیکربندی شود.
• پشتیبانی فنی دقیق مهندسان INFINIDAT دائماً گزارش‌ها و رویدادهای سیستم ذخیره‌سازی را تجزیه و تحلیل می‌کنند، نسخه‌های سفت‌افزار جدید را نصب می‌کنند و به پیکربندی کمک می‌کنند.

این هم چند عکس از باز کردن بسته بندی:

چگونه کار می کند

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

در تمام این موارد، ماشین‌های مجازی کلاینت به کار خود ادامه می‌دهند، و دلیل آن در اینجا آمده است.

طراحی خوشه طوری طراحی شده است که هر میزبان ESXi با ماشین های مجازی مشتری بتواند به هر یک از دو سیستم ذخیره سازی دسترسی داشته باشد. اگر سیستم ذخیره سازی در سایت OST از کار بیفتد، ماشین های مجازی به کار خود ادامه می دهند: میزبان هایی که روی آن ها در حال اجرا هستند برای داده ها به سیستم ذخیره سازی در NORD دسترسی خواهند داشت.

این همان چیزی است که نمودار اتصال در یک خوشه به نظر می رسد.

این به دلیل این واقعیت است که یک پیوند بین سوئیچ بین پارچه‌های SAN دو سایت پیکربندی شده است: سوئیچ Fabric A OST SAN به سوئیچ Fabric A NORD SAN و به طور مشابه برای سوئیچ‌های Fabric B SAN متصل است.

خوب، برای اینکه تمام این پیچیدگی‌های کارخانه‌های SAN معنا پیدا کند، Replication Active-Active بین دو سیستم ذخیره‌سازی پیکربندی شده است: اطلاعات تقریباً به طور همزمان در سیستم‌های ذخیره‌سازی محلی و از راه دور نوشته می‌شوند، RPO = 0. معلوم می شود که داده های اصلی در یک سیستم ذخیره سازی ذخیره می شود و ماکت آن در سیستم دیگر ذخیره می شود. داده ها در سطح حجم های ذخیره سازی تکرار می شوند و داده های VM (دیسک های آن، فایل پیکربندی، فایل swap و غیره) روی آنها ذخیره می شود.

میزبان ESXi حجم اولیه و ماکت آن را به عنوان یک دستگاه دیسک (دستگاه ذخیره سازی) می بیند. 24 مسیر از میزبان ESXi به هر دستگاه دیسک وجود دارد:

12 مسیر آن را به سیستم ذخیره سازی محلی (مسیرهای بهینه) و 12 مسیر باقی مانده را به سیستم ذخیره سازی راه دور (مسیرهای غیر بهینه) متصل می کند. در یک وضعیت عادی، ESXi با استفاده از مسیرهای "بهینه" به داده های موجود در سیستم ذخیره سازی محلی دسترسی پیدا می کند. هنگامی که این سیستم ذخیره سازی از کار می افتد، ESXi مسیرهای بهینه را از دست می دهد و به مسیرهای "غیر بهینه" سوئیچ می کند. این همان چیزی است که در نمودار به نظر می رسد.

طرح یک خوشه مقاوم در برابر بلایا

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

حال ببینیم چه اتفاقی برای ماشین های مجازی کلاینت در هنگام خرابی های مختلف می افتد. بیایید با سبک ترین گزینه ها شروع کنیم و با جدی ترین - شکست کل سایت پایان دهیم. در مثال‌ها، پلتفرم اصلی OST و پلتفرم پشتیبان با کپی داده‌ها، NORD خواهد بود.

چه اتفاقی برای ماشین مجازی کلاینت می افتد اگر...

پیوند تکراری خراب می شود. تکثیر بین سیستم های ذخیره سازی دو سایت متوقف می شود.
ESXi فقط با دستگاه های دیسک محلی (از طریق مسیرهای بهینه) کار می کند.
ماشین های مجازی به کار خود ادامه می دهند.

ISL (لینک بین سوئیچ) خراب می شود. مورد بعید است. مگر اینکه یک بیل مکانیکی دیوانه چندین مسیر نوری را در یک زمان حفاری کند که در مسیرهای مستقل اجرا می شود و از طریق ورودی های مختلف به سایت آورده می شود. ولی به هر حال. در این حالت هاست های ESXi نیمی از مسیرها را از دست می دهند و فقط می توانند به سیستم های ذخیره سازی محلی خود دسترسی داشته باشند. کپی ها جمع آوری می شوند، اما میزبان ها نمی توانند به آنها دسترسی داشته باشند.

ماشین های مجازی به طور معمول کار می کنند.

سوئیچ SAN در یکی از سایت ها خراب می شود. میزبان های ESXi برخی از مسیرهای سیستم ذخیره سازی را از دست می دهند. در این حالت، هاست در سایتی که سوئیچ در آن شکست خورده است، تنها از طریق یکی از HBA های خود کار می کنند.

ماشین های مجازی به طور عادی به کار خود ادامه می دهند.

همه سوئیچ های SAN در یکی از سایت ها از کار می افتند. فرض کنید چنین فاجعه ای در سایت OST رخ داده است. در این صورت هاست های ESXi در این سایت تمام مسیرهای دستگاه دیسک خود را از دست خواهند داد. مکانیسم استاندارد VMware vSphere HA وارد عمل می شود: حداکثر در 140 ثانیه تمام ماشین های مجازی سایت OST در NORD را مجددا راه اندازی می کند.

ماشین های مجازی در حال اجرا بر روی میزبان های سایت NORD به طور عادی کار می کنند.

میزبان ESXi در یک سایت از کار می افتد. در اینجا مکانیسم vSphere HA دوباره کار می‌کند: ماشین‌های مجازی از میزبان ناموفق در میزبان‌های دیگر - در همان سایت یا از راه دور، دوباره راه‌اندازی می‌شوند. زمان راه اندازی مجدد ماشین مجازی تا 1 دقیقه است.

اگر همه هاست های ESXi در سایت OST از کار بیفتند، هیچ گزینه ای وجود ندارد: ماشین های مجازی در یکی دیگر راه اندازی مجدد می شوند. زمان شروع مجدد به همین صورت است.

سیستم ذخیره سازی در یک سایت از کار می افتد. فرض کنید سیستم ذخیره سازی در سایت OST از کار می افتد. سپس میزبان‌های ESXi سایت OST به کار با کپی‌های ذخیره‌سازی در NORD تغییر می‌کنند. پس از بازگشت سیستم ذخیره سازی ناموفق به سرویس، تکرار اجباری رخ می دهد و میزبان های ESXi OST دوباره شروع به دسترسی به سیستم ذخیره سازی محلی می کنند.

ماشین های مجازی در تمام این مدت به طور عادی کار می کنند.

یکی از سایت ها خراب می شود. در این صورت تمام ماشین های مجازی در سایت پشتیبان از طریق مکانیزم vSphere HA راه اندازی مجدد خواهند شد. زمان راه اندازی مجدد VM 140 ثانیه است. در این صورت، تمام تنظیمات شبکه ماشین مجازی ذخیره می شود و از طریق شبکه برای مشتری در دسترس باقی می ماند.

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

یک ابر مقاوم در برابر بلایای طبیعی مبتنی بر دو مرکز داده از چنین خرابی هایی محافظت می کند.

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

منابع:

1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

منبع: www.habr.com