داستان جابجایی ۱۸ سرور ترب در بامداد ۱۰ شهریور ۱۴۰۲

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

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

تا اینجا کار دیتاسنتر مقصد رو مشخص کردیم. می‌مونه منتقل کردن سرورها! دو تا راه برای انجام این کار داشتیم.

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

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

سال پیش سرورها رو یک بار منتقل کرده بودیم. در این انتقال از راه اول استفاده کرده بودیم. تعدادی سرور در دیتاسنتر مقصد از مبین‌هاست اجاره کردیم. روی این سرورها یک کلاستر Kubernetes مدیریت شده از همروش گرفتیم. (به صورت کلی مدیریت کردن تمام کلاسترهای K8S ترب به همروش برون‌سپاری شده است) با توجه به اینکه ظرفیت کلاستر مقصد کوچیک‌تر از کلاستر مبدا بود، فقط سرویس‌های مهم رو روی کلاستر جدید Replicate کردیم. با توجه به این که امکان انتقال تمام سرویس‌ها به صورت همزمان نبود، نیاز به ایجاد یک ارتباط امن بین دو کلاستر داشتیم تا در بازه‌ی انتقال سرویس‌ها بتوانند با هم در ارتباط باشند. همچنین تجربه‌ی زیادی در لایه‌ی شبکه نداشتیم و نمی‌خواستیم پیچیدگی زیادی داشته باشیم. برای همین از Skupper برای این ارتباط استفاده کردیم. این ابزار تنظیمات پیچیده‌ای نداشت. در هر کلاستر یک instance از این ابزار مستقر می‌شد. کافی بود یکی از instanceها از طریق شبکه‌ی اینترنت در دسترس باشد. سپس instance دیگر با استفاده از TLS یک ارتباط امن بین دو کلاستر ایجاد می‌کرد. همچنین باید فرآیند CI/CD رو تغییر می‌دادیم که روی هر دو کلاستر کدهای جدید Deploy بشن. در نهایت یک روز صبح خیلی زود تمام درخواست‌های سرویس‌های اصلی رو به کلاستر جدید منتقل کردیم. در این مرحله ربات‌های خزنده‌ی ترب هنوز روی کلاستر قبلی بودند. خیلی زود متوجه شدیم که ارتباط امنی که توسط Skupper درست کرده بودیم مطابق انتظارمون عمل نمی‌کنه. در واقع میزان latency که Skupper ایجاد می‌کرد زیاد بود. چیزی که توی تست‌هایی که انجام داده بودیم زیاد بهش توجه نکردیم. در نتیجه برای یک هفته بروزرسانی محصولاتمون با اختلال همراه بود. برای همین باید با سرعت این مراحل رو برای بقیه سرویس‌ها تکرار می‌کردیم تا به پایداری کلی برسیم. کل این فرآیند (از زمان تصمیم‌گیری برای انتقال سرورها تا منتقل شدن آخرین سرور) شاید حدود ۲ ماه طول کشید و کلی بار عملیاتی روی دوشمون گذاشت. در نتیجه هزینه‌ی احتمالی این روش رو می‌دونستیم.

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

در نهایت جمعه ساعت ۲ بامداد ۱۰ شهریور ۱۴۰۲ خاموش کردن سرورها شروع شد. برای جلوگیری از آسیب احتمالی به داده‌ها، ابتدا باید VMها از طریق سیستم‌عامل خاموش می‌کردیم و در نهایت خود سرور رو خاموش می‌کردیم. همزمان با خاموش شدن سرورها، از رک خارج و بسته‌بندی می‌شدند تا در هنگام انتقال آسیب احتمالی به خود سرورها به حداقل برسد. خاموش شدن سرورها تا ساعت ۳:۲۰ به طور کامل انجام شد. حدود ۳:۵۰ سرورها از آسیاتک خارج شد. حدود ۴:۴۰ سرورها آماده‌ی نصب در های‌وب بودند. ساعت ۶:۴۵ تمام سرورها نصب و اولین سرور روشن شد و تا ساعت ۸ تمام سرویس‌های ترب در مدار قرار گرفتند. خوشبختانه در این انتقال تمام سرویس‌های مهم بدون مشکل به مدار برگشتند. فقط به دلیل خاموش کردن ناگهانی یکی از VMها، Filesystem آن دچار مشکل شده بود. خوشبختانه این سرویس، از سرویس‌های حیاتی نبود و مشکل جدی ایجاد نکرد.

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