قهرمان خاموش یک مایگریشن موفق: AM-ROUTE

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

در یکی از پروژه‌های مهم مهاجرت (Migration) مرتبط با محصول سرور ابری، با سناریویی ویژه و حساس روبرو بودیم که موفقیت در آن مستلزم ترکیبی از خلاقیت مهندسی، تسلط کامل بر زیرساخت شبکه و درک عمیق رفتار سیستم‌های کلاد و تجهیزات شبکه بود. مسئله این بود که باید مجموعه‌ای بزرگ از ابرک‌ها، به تعداد حدود ۷۰۰ تا ۸۰۰ ماشین مجازی، از یک کلاستر قدیمی به کلاستر جدید در دیتاسنتری دیگر منتقل می‌شدند، در حالی که آدرس‌های آی‌پی کاربران آنها باید بدون کوچک‌ترین تغییر باقی می‌ماند تا کاربران در طول فرآیند مهاجرت هیچ تغییری در دسترسی یا تجربه کاربری خود حس نکنند.

این مفهوم که به‌عنوان VM Mobility یا IP Mobility شناخته می‌شود، در تئوری رایج است، اما در عمل به دلیل پیچیدگی‌های متعدد معماری شبکه، محدودیت‌های تجهیزات فیزیکی و لایه‌های مختلف نرم‌افزاری، یکی از چالش‌های اساسی در حوزه کلاد به شمار می‌آید. در زیرساخت ابری ما، امکان همزمان ادورتایز شدن یک آی‌پی در دو نقطه شبکه (دو کلاستر مختلف) وجود نداشت. از سوی دیگر، رنج‌های آی‌پی تخصیص یافته به هر مجموعه از کاربران بسیار گسترده بود (رنج 22/)، به این معنا که انتقال کامل ابرک‌ها به‌صورت همزمان امکان‌پذیر نبود؛ چرا که منابع پردازشی، ذخیره‌سازی و شبکه به شکل یکباره قادر به تحمل بار چنین جابه‌جایی حجیمی نبودند. بنابراین، مهاجرت باید به صورت تدریجی و با کنترل دقیق روی هر مرحله انجام می‌شد؛ در حالی که همزمان کاربران در هر دو کلاستر به‌طور فعال خدمات دریافت می‌کردند.

یکی دیگر از چالش‌های مهم، ساختار سخت‌افزاری شبکه بود. شبکه در هر کلاستر متشکل از چند سوئیچ Top of Rack (TOR) از نوع Cisco Nexus C3064PQ و همچنین دو سوئیچ تجمیعی Nexus C93180YC-EX بود که به عنوان لایه Aggregation و گیت‌وی اینترنت کاربران عمل می‌کردند. اگرچه طراحی کلی شبکه در هر دو کلاستر مشابه بود، اما محدودیت‌های زیرساختی و سناریوی پیاده شده مانع استفاده از تکنولوژی‌های مدرن و محبوبی مانند VXLAN می‌شد؛ تکنولوژی‌هایی که امروزه در کلادهای پیشرفته برای فراهم کردن قابلیت mobility و ساخت شبکه‌های مجازی بین کلاسترها کاربرد گسترده دارند.

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

در حین بررسی‌های عمیق‌تر تنظیمات سوئیچ‌های نکسوس، نکته جالبی کشف کردیم: جدول روتینگ این سوئیچ‌ها شامل مسیرهایی با عنوان AM Route بود که به صورت خودکار پس از ایجاد ARP روی یک پورت ثبت می‌شدند. این روت‌ها که مسیرهایی با ماسک 32/ بودند، در واقع نشان می‌دادند یک ماشین مجازی خاص از طریق کدام پورت فیزیکی قابل دسترسی است. نکته قابل توجه این بود که این قابلیت بسیار کاربردی، در مستندات رسمی سیسکو به صورت محدود بیان شده بود و منابع آنلاین قابل اتکایی درباره آن وجود نداشت.

پس از آزمایش‌های متعدد، متوجه شدیم می‌توان این AM Routeها را از طریق پروتکل BGP به سایر تجهیزات شبکه ادورتایز کرد. بر اساس این کشف، معماری روتینگ چندلایه‌ای را طراحی کردیم که به شرح زیر بود:

• در هر دو کلاستر، رنج کامل آدرس‌های آی‌پی (22/) به صورت پیش‌فرض از طریق BGP به سوئیچ‌های بالادستی اعلام شد.
• به صورت همزمان، با استفاده از دستور redistribute am route-map ... روت‌های دقیق 32/ مربوط به VMهایی که در هر کلاستر روشن و فعال بودند، به صورت داینامیک و خودکار به BGP تزریق شدند.
• سوئیچ‌های بالادستی، اکنون قادر بودند بر اساس حضور واقعی هر ماشین مجازی در یکی از کلاسترها، تصمیم بگیرند که ترافیک ورودی را به کدام مسیر هدایت کنند.

نتیجه این شد که وقتی یک ابرک از کلاستر A به کلاستر B منتقل می‌شد، به محض روشن شدن و ثبت ARP روی سوئیچ‌های کلاستر B، مسیر دقیق 32/ به صورت خودکار به BGP تزریق شده و به دلیل اولویت بالاتر، جایگزین مسیر عمومی 22/ می‌شد. این رفتار باعث شد حتی در طول مهاجرت تدریجی، کاربران هیچ‌گونه قطعی یا اختلالی را تجربه نکنند و تمامی ترافیک به طور پویا و بدون دخالت دستی به مسیر جدید هدایت شود.

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