چگونه بدون قطعی از یک سرور به سرور دیگر مهاجرت کنیم؟

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

مهاجرت سرور بدون قطعی در بسیاری از پروژه‌ها امکان‌پذیر است، اما هدف عملی معمولا رساندن Downtime به نزدیک صفر است. در قطعی کامل، سایت یا سرویس برای مدتی کاملا از دسترس خارج می‌شود. در اختلال کوتاه، ممکن است فقط بخشی از درخواست‌ها با خطا یا کندی مواجه شوند. در مقابل، مهاجرت Zero-Downtime به گونه‌ای انجام می‌شود که کاربران تغییر سرور را احساس نکنند و سرویس در تمام مراحل در دسترس باقی بماند. رسیدن به این وضعیت به آماده‌سازی کامل سرور مقصد، همگام‌سازی داده‌ها، تست پیش از انتقال و مدیریت درست DNS وابسته است. هرچه پروژه تراکنش و داده‌ بیشتری داشته باشد، برنامه‌ریزی این مراحل اهمیت بیشتری پیدا می‌کند.

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

وب‌سرور، نوع و نسخه دیتابیس، نسخه زبان برنامه‌نویسی، Cron Jobها، گواهی SSL، سرویس‌های خارجی و محل ذخیره فایل‌های آپلودی را ثبت کنید. حتی یک وابستگی فراموش‌شده می‌تواند پس از انتقال باعث اختلال در بخشی از سایت شود.

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

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

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

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

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

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

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

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

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

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

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

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

می‌توان با تغییر موقت فایل Hosts در سیستم محلی، دامنه را به IP سرور جدید متصل کرد. به این ترتیب، سایت از روی مقصد بررسی می‌شود بدون اینکه DNS عمومی برای کاربران تغییر کند.

فقط باز شدن صفحه اصلی کافی نیست. ورود و ثبت‌نام کاربران، فرم‌ها، ثبت سفارش، پرداخت، آپلود فایل، ارسال ایمیل و ارتباط با APIها را آزمایش کنید. همچنین لاگ‌های وب‌سرور و برنامه را بررسی کنید تا خطاهای پنهان قبل از انتقال نهایی شناسایی شوند.

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

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

پس از آماده‌سازی و تست کامل سرور مقصد، می‌توانید رکورد DNS را به IP جدید تغییر دهید. بااین‌حال، سرور قبلی نباید بلافاصله خاموش شود؛ چون ممکن است بخشی از کاربران به دلیل کش DNS همچنان برای مدتی به IP قدیمی متصل شوند.

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

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

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

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

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

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