آموزش مهاجرت سرور بدون قطعی؛ انتقال سایت به سرور جدید با کمترین Downtime

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

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

برای سایت‌های ساده، انتقال فایل‌ها، ایمپورت پایگاه داده، نصب SSL و تغییر DNS ممکن است کافی باشد، اما برای فروشگاه‌های آنلاین، سامانه‌های رزرو، سرویس‌های API یا وب‌سایت‌هایی با تراکنش بالا، باید موضوعاتی مانند همگام‌سازی دیتابیس، Cron Job، ایمیل، آپلود فایل، کش، نشست کاربران و تغییرات لحظه‌ای اطلاعات نیز در نظر گرفته شود.

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

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

مهاجرت Zero-Downtime به روشی از انتقال زیرساخت گفته می‌شود که در آن سرویس اصلی در طول بخش عمده عملیات مهاجرت فعال می‌ماند و زمان قطعی احتمالی فقط به یک بازه بسیار کوتاه برای هماهنگ‌کردن آخرین داده‌ها و تغییر مسیر ترافیک محدود می‌شود؛ بنابراین اصطلاح Zero-Downtime را نباید همیشه به معنای صفر ثانیه اختلال دانست، بلکه در بسیاری از معماری‌ها هدف، نزدیک‌شدن به صفر و حذف Downtime قابل‌توجه است. این روش زمانی اهمیت بیشتری پیدا می‌کند که سایت یا اپلیکیشن به‌صورت ۲۴ ساعته در حال دریافت درخواست باشد، کاربران هم‌زمان در حال ثبت سفارش باشند یا داده‌ها دائما تغییر کنند.

در چنین شرایطی، خاموش‌کردن سرور فعلی برای چند ساعت و سپس جابه‌جایی سایت بین سرورها می‌تواند باعث از دست رفتن سفارش‌ها، فرم‌ها، تراکنش‌ها یا اطلاعات کاربران شود. راهکار استاندارد این است که ابتدا سرور جدید ساخته و تست شود، سپس انتقال فایل بین سرورها انجام گیرد و یک نسخه اولیه از پایگاه داده روی مقصد قرار گیرد؛ در پروژه‌های پرتراکنش، همگام‌سازی تغییرات دیتابیس نیز ادامه پیدا می‌کند تا در زمان Cutover اختلاف بین دو محیط به حداقل برسد. در مرحله نهایی، ترافیک از سرور فعلی به سرور جدید منتقل می‌شود و برای کاهش ریسک، سرور قدیمی برای مدتی فعال باقی می‌ماند. Google Cloud نیز Zero-Downtime Migration را در مفهوم عملی، مهاجرت داده در حالی توصیف می‌کند که پایگاه داده مبدأ همچنان تغییر می‌کند؛ در نتیجه سرعت انتقال باید به اندازه‌ای باشد که بتوان داده‌های موجود و تغییرات جدید را به‌موقع به مقصد رساند.

بیشتر بخوانیدباتری سیلیکون کربن چیست؟ + بررسی نحوه عملکرد، مزایا و معایب

اقدامات ضروری قبل از جابه‌جایی سرور

قبل از شروع جابه‌جایی سرور نباید مستقیما سرور جدید را جایگزین سرور فعلی کنید؛ ابتدا باید یک فهرست کامل از سرویس‌ها، داده‌ها، وابستگی‌ها و تنظیمات زیرساخت تهیه شود تا چیزی در فرایند انتقال سایت بدون قطعی جا نماند. در مرحله اول، مشخصات سرور فعلی شامل سیستم‌عامل و نسخه آن، وب‌سرور مانند Nginx یا Apache، نسخه PHP یا Runtime مورد استفاده، نسخه و نوع پایگاه داده، محل ذخیره فایل‌های سایت، حجم فضای مصرف‌شده، CPU، RAM، دیسک، پورت‌های باز، قوانین فایروال، گواهی SSL، Cron Jobها، سرویس‌های ایمیل، APIها و دسترسی‌های SSH را ثبت کنید؛ سپس IP سرور فعلی، رکوردهای DNS، مقدار TTL و سرویس‌هایی که مستقیما به IP وابسته هستند نیز مستندسازی شوند.

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

بررسی منابع، سرویس‌ها و تنظیمات سرور فعلی

اولین مرحله عملی در انتقال سرور بدون قطعی، تهیه یک شناسنامه فنی کامل از سرور فعلی است؛ قبل از خرید یا پیکربندی سرور جدید باید سیستم‌عامل و نسخه آن، معماری CPU، مقدار RAM، فضای دیسک و نوع ذخیره‌سازی، وب‌سرور مانند Nginx یا Apache، نسخه Runtimeهایی مانند PHP، Node.js یا Python، نسخه پایگاه داده، سرویس‌های فعال، پورت‌های باز، قوانین فایروال، دسترسی‌های SSH، کاربران سیستم، گواهی‌های SSL، Cron Jobها، سرویس ایمیل و APIهای وابسته را ثبت کنید. سپس حجم واقعی فایل‌های سایت، اندازه پایگاه داده، مسیرهای Upload، فایل‌های تنظیمات و متغیرهای محیطی را مشخص کنید تا سرور مقصد بر اساس مصرف واقعی منابع انتخاب شود، نه صرفا بر اساس ظرفیت اسمی. برای مثال، اگر سرور فعلی هنگام ساعات اوج مصرف ۸۰ درصدRAMو ۷۰ درصد CPU مصرف می‌کند، انتقال همان بار کاری به سروری با منابع مشابه لزوما بهبود عملکرد ایجاد نمی‌کند و بهتر است ظرفیت CPU، RAM و فضای ذخیره‌سازی با درنظرگرفتن رشد آینده افزایش یابد.

همچنین باید وابستگی‌های شبکه، IPهای مجاز، Whitelistها و سرویس‌هایی که به IP سرور قدیمی متصل هستند شناسایی شوند؛ زیرا تغییر IP سرور ممکن است باعث اختلال API، سرویس پرداخت، ایمیل یا ارتباط میان سرورها شود. در این مرحله بهتر است از دستورات مانیتورینگ سیستم و لاگ‌XNET‌سرور برای ثبت الگوی مصرف CPU، RAM، I/O و ترافیک استفاده کنید و مشخص کنید کدام سرویس‌ها واقعا باید به سرور جدید منتقل شوند. مستندسازی دقیق مبدأ یکی از پایه‌های مهاجرت کنترل‌شده است، زیرا انتخاب روش مهاجرت، اندازه سرور مقصد و زمان Cutover مستقیما به حجم داده، نرخ تغییرات و محدودیت Downtime وابسته است.

تهیه بکاپ کامل از فایل‌ها و پایگاه داده

قبل از هرگونه انتقال فایل بین سرورها باید حداقل یک نسخه سالم و قابل بازیابی از اطلاعات تهیه کنید؛ این مرحله را می‌توان در سه لایه انجام داد: ابتدا بکاپ فایل‌های سایت شامل هسته برنامه، تصاویر، فایل‌های Upload، تنظیمات و سایر داده‌های موجود روی دیسک تهیه شود، سپس بکاپ دیتابیس به‌صورت کامل و ترجیحا با ابزار بومی همان موتور پایگاه داده گرفته شود و در نهایت تنظیمات مهم سرور مانند Virtual Hostها، Cron Jobها، گواهی SSL و فایل‌های پیکربندی نیز جداگانه ذخیره شوند.

بکاپ نباید صرفا روی همان سرور قدیمی باقی بماند؛ یک نسخه مستقل روی فضای ذخیره‌سازی جداگانه قرار دهید و قبل از مهاجرت، فرآیند Restore را روی محیط آزمایشی بررسی کنید تا مطمئن شوید فایل بکاپ واقعا قابل استفاده است. برای پایگاه داده‌های بزرگ، ابتدا حجم Backup و زمان انتقال آن را اندازه‌گیری کنید، زیرا روش Backup/Restore آفلاین در دیتابیس‌های حجیم می‌تواند پنجره Cutover طولانی‌تری ایجاد کند؛ در مقابل، روش‌های Online Migration می‌توانند داده اولیه را در حالی منتقل کنند که پایگاه داده مبدأ همچنان فعال است و سپس تغییرات جدید را به مقصد منتقل کنند. همچنین بهتر است برای هر Backup مقدار Hash یا اندازه فایل ثبت شود تا پس از انتقال پایگاه داده بین سرورها بتوان صحت فایل را بررسی کرد. در زمان تهیه آخرین بکاپ نیز تاریخ و ساعت دقیق آن را ثبت کنید تا بدانید مقصد دقیقا تا چه نقطه‌ای از داده‌های سرور مبدأ را پوشش می‌دهد؛ این موضوع در صورت نیاز به Rollback Plan اهمیت زیادی دارد.

آماده‌سازی Rollback Plan

پیش از شروع Cutover باید یک برنامه بازگشت در مهاجرت سرور یا Rollback Plan مشخص و قابل اجرا داشته باشید تا اگر پس از انتقال، خطای جدی در وب‌سرور، دیتابیس، API، پرداخت، ایمیل یا عملکرد برنامه مشاهده شد، بتوانید بدون تصمیم‌گیری لحظه‌ای به محیط قبلی برگردید. در ساده‌ترین سناریو، سرور فعلی تا زمانی که سلامت سرور جدید تأیید نشده است روشن و آماده سرویس‌دهی باقی می‌ماند؛ در کنار آن، باید مشخص کنید در صورت شکست مهاجرت دقیقا چه کسی تصمیم بازگشت را می‌گیرد، چه معیارهایی باعث فعال‌شدن Rollback می‌شوند، رکورد DNS یا Load Balancer چگونه به IP قبلی برمی‌گردد و داده‌هایی که پس از Cutover روی سرور جدید ایجاد شده‌اند چگونه مدیریت خواهند شد.

این مورد در سایت‌های تراکنشی اهمیت بیشتری دارد، زیرا اگر کاربران پس از انتقال سفارش یا اطلاعات جدیدی ثبت کنند و سپس DNS را به سرور قدیمی برگردانید، داده‌های ایجادشده روی مقصد ممکن است روی سرور قدیمی وجود نداشته باشند و باعث ناسازگاری شوند. به همین دلیل، پیش از مهاجرت باید مشخص کنید Rollback فقط در چند دقیقه ابتدایی امکان‌پذیر است یا برای حفظ داده‌ها به Reverse Replication، Snapshot یا روش دیگری نیاز دارید. همچنین زمان لازم برای بازگرداندن سرویس، آخرین Backup معتبر و روش تأیید سلامت سرور قدیمی باید مستند شود. AWS نیز در مرحله Cutover توصیه می‌کند پیش از تغییر مسیر ترافیک، Backup نهایی، همگام‌سازی داده‌ها و تست انجام شود و مسیر Failback از قبل مشخص باشد؛ بنابراین Rollback نباید یک راهکار اضطراریِ بداهه باشد، بلکه باید بخشی از طراحی مهاجرت Zero-Downtime محسوب شود.

آماده‌سازی سرور مقصد

پس از شناخت کامل محیط مبدأ و آماده‌کردن بکاپ، مرحله بعدی ساخت و پیکربندی سرور مقصد است؛ این سرور باید پیش از دریافت ترافیک واقعی تا حد امکان از نظر سیستم‌عامل، وب‌سرور، Runtime، پایگاه داده، ساختار فایل‌ها، شبکه و تنظیمات امنیتی آماده شود. اگر سایت روی یک سرور مجازی لینوکسی قرار دارد، نسخه سیستم‌عامل، معماری CPU و نسخه سرویس‌های اصلی را با نیازمندی‌های نرم‌افزار تطبیق دهید و سپس وب‌سرور، Runtime، Database Server، سرویس‌های لازم و ابزارهای مانیتورینگ را نصب کنید. در این مرحله نباید فقط به انتقال فایل‌ها اکتفا کرد؛ نسخه PHP، Node.js یا سایر Runtimeها، Extensionهای مورد نیاز، تنظیمات PHP-FPM، محدودیت‌های Upload، Memory Limit، Max Execution Time، تنظیمات وب‌سرور، Permission فایل‌ها و دسترسی سرویس‌ها باید با محیط قبلی مقایسه شوند. همچنین پورت‌های موردنیاز مانند SSH، HTTP و HTTPS را در فایروال باز و دسترسی‌های غیرضروری را مسدود کنید و در صورت استفاده از SSH، احراز هویت کلیدمحور و محدودکردن دسترسی Root را در نظر بگیرید. سرور جدید باید با IP مستقل و بدون تغییر DNS عمومی آماده تست باشد تا بتوانید پیش از انتقال سایت به سرور جدید، عملکرد واقعی برنامه را بررسی کنید. در معماری‌های حرفه‌ای، محیط مقصد قبل از Cutover کاملا Provision و Validate می‌شود و فقط پس از تأیید سلامت سرویس‌ها ترافیک تولیدی به آن منتقل خواهد شد؛ این رویکرد باعث می‌شود بخش عمده مشکلات احتمالی پیش از مرحله نهایی شناسایی شوند و کاهش Downtime در زمان جابه‌جایی عملی‌تر شود.

نصب وب‌سرور، Runtime و پایگاه داده

برای آماده‌سازی سرور مقصد ابتدا باید محیط نرم‌افزاری آن را با سرور فعلی تطبیق دهید تا برنامه پس از انتقال با خطاهای سازگاری مواجه نشود؛ در یک سرور لینوکسی، ابتدا سیستم‌عامل و بسته‌های پایه را به‌روزرسانی کنید، سپس وب‌سرور مورد استفاده سایت مانند Nginx یا Apache را نصب و Virtual Host یا Server Block مربوط به دامنه را ایجاد کنید. در مرحله بعد، Runtime موردنیاز برنامه را با همان نسخه یا نسخه سازگار نصب کنید؛ برای مثال در سایت PHP، نسخه PHP، PHP-FPM و Extensionهایی مانند MySQLi، PDO، GD، cURL، OpenSSL، Mbstring و Zip باید با نیازمندی برنامه مطابقت داشته باشند. سپس موتور پایگاه داده، مانند MySQL یا MariaDB، نصب و تنظیم شود و پارامترهای اصلی آن بر اساس حجم و نوع workload تعیین شوند. پس از نصب سرویس‌ها، ساختار دایرکتوری سایت را ایجاد کرده و تنظیمات مربوط به Document Root، Permission و مالکیت فایل‌ها را اعمال کنید. اگر برنامه از Node.js، Python یا Runtime دیگری استفاده می‌کند، نسخه دقیق Runtime و وابستگی‌های آن نیز باید منتقل شود؛ زیرا اختلاف نسخه می‌تواند باعث تغییر رفتار برنامه شود. در صورتی که سرور جدید از ماشین یا معماری متفاوتی استفاده می‌کند، سازگاری سیستم‌عامل، دیسک، رابط شبکه و نرم‌افزارهای موجود را نیز قبل از انتقال بررسی کنید؛ مستندات Google Cloud نیز تأکید می‌کند که هنگام انتقال workload باید سازگاری سیستم‌عامل، نوع دیسک، رابط‌های ذخیره‌سازی و ویژگی‌های ماشین مقصد بررسی شود.

تنظیم SSL، فایروال، SSH و دسترسی‌ها

بعد از نصب سرویس‌های اصلی، نوبت به ایمن‌سازی سرور جدید می‌رسد و بهتر است این مرحله قبل از انتقال اطلاعات انجام شود؛ ابتدا پورت‌ها و سرویس‌های موردنیاز را مشخص کنید و در فایروال فقط دسترسی‌های ضروری مانند HTTP روی پورت 80، HTTPS روی پورت 443 و SSH روی پورت 22 یا پورت سفارشی تعیین‌شده را مجاز کنید، در حالی که پورت‌های بلااستفاده بسته باقی بمانند. سپس دسترسی SSH را بررسی کنید و ترجیحا احراز هویت مبتنی بر کلید SSH را به‌کار ببرید، دسترسی مستقیم Root را محدود کنید و برای کاربران مدیریتی Permissionهای حداقلی موردنیاز را تعریف کنید. در مرحله بعد، گواهی SSL دامنه را روی وب‌سرور مقصد نصب و زنجیره Certificate را بررسی کنید؛ اگر از Let’s Encrypt استفاده می‌کنید، علاوه بر صدور گواهی باید Auto-Renewal آن را نیز آزمایش کنید. سپس قوانین فایروال، دسترسی سرویس‌ها به پایگاه داده، ارتباط APIها، پورت‌های داخلی و IPهای مجاز را با محیط قبلی مقایسه کنید. نکته مهم این است که هنگام انتقال سایت به سرور جدید، نباید صرفا بازبودن پورت 80 و 443 را کافی بدانید؛ ارتباطات داخلی، سرویس‌های مانیتورینگ، SMTP، DNS و APIهای خارجی نیز ممکن است به IP یا پورت مشخصی وابسته باشند. مستندات AWS برای محیط‌های مهاجرتی نیز بر بررسی شبکه، Subnet، Routing، Security Group و پورت‌های لازم پیش از اجرای Migration تأکید دارد.

بررسی CPU، RAM و فضای ذخیره‌سازی

در این مرحله باید مشخص کنید که آیا منابع سرور مقصد برای اجرای workload فعلی و رشد آینده کافی هستند یا خیر؛ برای این کار فقط تعداد هسته‌های CPU یا مقدار RAM اسمی را مقایسه نکنید، بلکه مصرف واقعی سرور فعلی در ساعات عادی و اوج بار را بررسی کرده و شاخص‌هایی مانند CPU Utilization، Memory Usage، Disk I/O، IOPS، فضای آزاد دیسک، Network Throughput و Load Average را ثبت کنید. اگر سرور فعلی مثلا به‌طور مستمر در ساعات پرترافیک به محدودیت CPU یا RAM نزدیک می‌شود، سرور جدید نباید صرفا با همان مشخصات انتخاب شود و بهتر است ظرفیت بیشتری برای Peak Load و رشد آینده در نظر گرفته شود. فضای ذخیره‌سازی نیز باید بر اساس حجم فعلی داده، Backupها، فایل‌های موقت، لاگ‌ها و رشد پیش‌بینی‌شده محاسبه شود؛ علاوه بر ظرفیت، نوع دیسک و عملکرد I/O نیز برای دیتابیس و سایت‌های پرترافیک اهمیت دارد. Google Cloud در راهنمای ارزیابی مهاجرت توصیه می‌کند اندازه‌گذاری مقصد بر اساس داده‌های عملکردی واقعی CPU، Memory و Storage انجام شود و در انتخاب ماشین، نیازهای workload، عملکرد و هزینه هم‌زمان در نظر گرفته شوند. بنابراین پیش از جابه‌جایی سرور حداقل چند بازه زمانی از مصرف منابع را بررسی کنید، ظرفیت سرور مقصد را تعیین کنید، فضای کافی برای Backup و Rollback کنار بگذارید و در نهایت مطمئن شوید منابع جدید در زمان افزایش ترافیک نیز توان پاسخ‌گویی دارند.

انتقال اولیه فایل‌های سایت

برای انتقال اولیه فایل‌های سایت بهتر است پیش از تغییر DNS، تمام فایل‌های موجود روی سرور فعلی را به سرور مقصد منتقل کنید تا در زمان نهایی جابه‌جایی سایت بین سرورها فقط فایل‌های جدید یا تغییرکرده باقی بمانند؛ در سرورهای لینوکسی، ابزار `rsync` یکی از گزینه‌های مناسب برای این کار است، زیرا می‌تواند ساختار پوشه‌ها، زمان تغییر فایل‌ها، مجوزها و در صورت استفاده از گزینه‌های مناسب، لینک‌های نمادین را حفظ کند و در اجرای مجدد فقط اختلاف فایل‌ها را منتقل کند، بنابراین برای کاهش Downtime بسیار کاربردی است. مرحله اول این است که روی سرور جدید فضای ذخیره‌سازی، مسیر Document Root و مالکیت پوشه سایت را آماده کنید؛ سپس از طریق SSH با دسترسی مناسب به هر دو سرور متصل شوید و ارتباط شبکه و دسترسی به مسیر مقصد را بررسی کنید. در مرحله دوم، فایل‌های سایت را با ساختاری مشابه سرور قدیمی منتقل کنید؛ برای نمونه، در یک سناریوی لینوکسی می‌توان از دستوری مانند `rsync -avz /var/www/example/ user@NEW_SERVER_IP:/var/www/example/` استفاده کرد، البته مسیرها، نام کاربری و IP سرور باید متناسب با محیط واقعی تغییر کنند و اگر مالکیت، ACL یا ویژگی‌های پیشرفته فایل‌ها اهمیت دارد، گزینه‌های مربوط به آن نیز باید جداگانه بررسی شوند. در مرحله سوم، پس از پایان کپی، تعداد فایل‌ها، حجم پوشه‌ها، مالکیت و Permissionها و همچنین فایل‌های مهمی مانند `.env`، فایل‌های پیکربندی، تصاویر، فایل‌های آپلودشده و پوشه‌های وابسته به برنامه را با سرور قدیمی مقایسه کنید؛ اگر سایت از لینک‌های نمادین استفاده می‌کند، باید مطمئن شوید مقصد آن لینک‌ها روی سرور جدید نیز معتبر است. در مرحله چهارم، بدون تغییر DNS، یک بار دیگر `rsync` را اجرا کنید تا فایل‌هایی که از زمان انتقال اول تغییر کرده‌اند نیز منتقل شوند؛ این روش باعث می‌شود انتقال مرحله‌ای داده‌ها انجام شود و در زمان Cutover، حجم اطلاعات باقی‌مانده برای انتقال نهایی به حداقل برسد. در نهایت، تا زمانی که تست سرور جدید قبل از انتقال، بررسی لاگ‌ها و صحت عملکرد سایت کامل نشده است، سرور قدیمی را حذف یا خاموش نکنید؛ زیرا هدف این مرحله آماده‌سازی یک کپی عملیاتی و قابل استفاده از سایت روی سرور جدید است، نه جایگزینی فوری سرور فعلی.

انتقال و همگام‌سازی دیتابیس

برای انتقال و همگام‌سازی دیتابیس ابتدا باید یک نسخه کامل از پایگاه داده روی سرور فعلی تهیه و آن را به سرور مقصد منتقل کنید؛ در سایت‌های کم‌تراکنش می‌توانید ابتدا با ابزارهایی مانند `mysqldump` خروجی بگیرید، فایل Dump را از طریق SSH یا `rsync` به سرور جدید انتقال دهید و سپس آن را روی MySQL/MariaDB مقصد Import کنید، اما برای مهاجرت سرور بدون قطعی نباید تصور کنید که همین Dump اولیه به‌تنهایی کافی است، زیرا در فاصله بین تهیه بکاپ و Import، ممکن است کاربران سفارش جدید ثبت کنند، حساب کاربری بسازند، فرم ارسال کنند یا اطلاعات دیگری در دیتابیس تغییر کند. روش مرحله‌ای به این شکل است: ابتدا نسخه اولیه دیتابیس را از سرور فعلی تهیه کنید؛ سپس آن را روی سرور جدید Import کنید؛ بعد بررسی کنید که جداول، رکوردها، Charset، Collation، کاربران دیتابیس، Indexها و ساختار Schema صحیح هستند؛ در مرحله بعد، اگر دیتابیس همچنان در حال تغییر است، یک روش همگام‌سازی دیتابیس مانند Replication یا CDC راه‌اندازی کنید تا تغییرات بعد از Snapshot اولیه نیز به مقصد برسند. در MySQL، Replication می‌تواند داده‌های سرور Source را به Replica منتقل کند و در روش مبتنی بر Binary Log، Replica از نقطه مشخص‌شده در لاگ ادامه می‌دهد؛ مستندات رسمی MySQL نیز تأکید می‌کنند که هنگام استفاده از داده موجود، ابتدا Snapshot به Replica منتقل می‌شود و سپس Replication تغییرات ایجادشده بعد از Snapshot را اعمال می‌کند. در مرحله پایانی، وضعیت همگام‌سازی را بررسی کنید و مطمئن شوید تأخیر Replication به مقدار قابل قبول رسیده است؛ سپس در زمان Cutover، نوشتن اطلاعات را برای مدت کوتاهی متوقف یا کنترل کنید، آخرین تغییرات را به مقصد برسانید، صحت داده‌ها را بررسی کنید و برنامه را به دیتابیس جدید متصل کنید. برای دیتابیس‌های پرتراکنش، استفاده از Replication اهمیت بیشتری دارد، زیرا انتقال یک‌باره فایل Dump در چنین شرایطی می‌تواند فاصله زمانی قابل‌توجهی بین نسخه مبدأ و مقصد ایجاد کند و احتمال قطعی سایت هنگام مهاجرت یا از دست رفتن آخرین تراکنش‌ها را افزایش دهد. همچنین هنگام پیکربندی Replication باید اتصال TCP/IP، حساب کاربری مخصوص Replication، تنظیمات Binary Log و شناسه یکتای `server_id` را بررسی کنید؛ MySQL برای هر Source و Replica یک شناسه یکتا در توپولوژی Replication نیاز دارد.

استفاده از Replication برای دیتابیس‌های پرتراکنش

اگر سایت شما دارای دیتابیس پرتراکنش است، برای اینکه انتقال سرور بدون قطعی با کمترین توقف انجام شود، بهتر است به‌جای اتکا به یک Dump نهایی، از Replication استفاده کنید؛ در این روش ابتدا یک Snapshot یا Dump اولیه از پایگاه داده روی سرور فعلی تهیه و روی سرور جدید بازیابی می‌شود، سپس Replication را فعال می‌کنید تا تغییرات جدید از طریق Binary Log به مقصد منتقل شوند. برای اجرای مرحله‌ای، ابتدا روی سرور مبدأ مطمئن شوید Binary Logging فعال است و یک `server_id` یکتا برای آن تعیین شده، سپس روی سرور مقصد نیز `server_id` متفاوت تنظیم کنید و دسترسی شبکه و حساب کاربری مخصوص Replication را ایجاد کنید؛ مستندات رسمی MySQL نیز تأکید می‌کنند که Source و Replica باید شناسه یکتای `server_id` داشته باشند و Replica با استفاده از Binary Log تغییرات ثبت‌شده روی Source را دریافت و اعمال می‌کند. در مرحله بعد، Snapshot اولیه را روی سرور جدید Import کنید و نقطه شروع Replication را بر اساس موقعیت Binary Log یا در معماری‌های مناسب با GTID مشخص کنید؛ سپس Replication را Start کرده و وضعیت آن را مرتب بررسی کنید تا مطمئن شوید تغییرات جدید دیتابیس بدون خطا به سرور مقصد می‌رسند. در زمان Cutover، ابتدا ثبت تغییرات حساس را برای مدت کوتاهی متوقف یا سایت را وارد حالت فقط‌خواندنی دیتابیس کنید، صبر کنید تمام تراکنش‌های باقی‌مانده روی Replica اعمال شوند، سپس چند رکورد و جدول مهم را مقایسه کنید و در صورت صحت، اتصال برنامه را به دیتابیس سرور جدید تغییر دهید؛ نکته مهم این است که Replication به‌معنای همگام‌سازی کاملا آنی نیست و باید Lag آن را پایش کنید، زیرا حجم تراکنش‌ها، منابع سرور و سرعت شبکه می‌تواند باعث ایجاد تأخیر شود. همچنین اگر نسخه MySQL سرور جدید با سرور قدیمی متفاوت است، سازگاری نسخه‌ها و قابلیت‌های مورد استفاده را پیش از مهاجرت بررسی کنید؛ MySQL در برخی ترکیب‌های نسخه‌ای محدودیت‌های مشخصی برای Replication دارد. به این ترتیب، بخش عمده انتقال پایگاه داده بین سرورها در حالی انجام می‌شود که سایت همچنان روی سرور فعلی فعال است و در لحظه نهایی فقط یک پنجره کوتاه برای همگام‌سازی نهایی و تغییر مسیر برنامه باقی می‌ماند؛ این دقیقا همان رویکردی است که در سناریوهای Zero-Downtime Migration برای کاهش Downtime کاربرد دارد.

تست سرور جدید قبل از انتقال نهایی

پیش از تغییر DNS هنگام مهاجرت سرور، باید سرور جدید را به‌عنوان یک محیط Production واقعی آزمایش کنید تا مشکلاتی که پس از تغییر مسیر کاربران ایجاد می‌شوند، به حداقل برسند؛ ابتدا با استفاده از فایل Hosts روی رایانه خود، دامنه را به IP سرور جدید نگاشت کنید تا بدون تغییر DNS عمومی بتوانید سایت را از مقصد مشاهده کنید، سپس صفحه اصلی و صفحات مهم، ورود و ثبت‌نام کاربران، جست‌وجو، فرم‌ها، پنل مدیریت، تست ثبت سفارش، سبد خرید و فرآیند پرداخت را بررسی کنید و در صورت وجود سیستم آپلود، یک تست آپلود فایل انجام دهید تا مشخص شود Permissionها، مسیر ذخیره‌سازی و محدودیت‌های Runtime صحیح هستند؛ در مرحله بعد، تست ارسال ایمیل را انجام دهید و عملکرد APIهای داخلی و خارجی، Webhookها و سرویس‌های وابسته را بررسی کنید، سپس Cron Jobها را کنترل کنید تا اجرای وظایف زمان‌بندی‌شده روی سرور جدید باعث اجرای دوباره یا از دست رفتن Jobها نشود. در ادامه، لاگ وب‌سرور، لاگ Runtime و لاگ برنامه را بررسی کنید و خطاهای 4xx و 5xx، خطاهای اتصال به دیتابیس، مشکلات Permission و خطاهای SSL را برطرف کنید؛ همچنین CPU، RAM، فضای ذخیره‌سازی و سایر منابع سرور را هنگام اجرای تست‌های واقعی زیر نظر بگیرید تا مشخص شود سرور مقصد توان پاسخ‌گویی به بار کاری سرور فعلی را دارد. برای مهاجرت دیتابیس، ابتدا صحت داده‌های مهم را با نمونه‌برداری یا مقایسه رکوردها بررسی کنید و در صورت استفاده از Replication، Replication Delay را پایش کنید؛ مستندات Google Cloud توصیه می‌کنند پیش از Promotion، تأخیر Replication به حداقل برسد و برای جلوگیری از از دست رفتن داده، در زمان نهایی‌سازی نوشتن روی Source متوقف شود و مقصد تا رسیدن تأخیر به صفر عقب‌ماندگی خود را جبران کند. ([Google Cloud Documentation][1]) در نهایت، نتیجه تمام تست‌ها را ثبت کنید و فقط زمانی سرور جدید را برای انتقال سایت بدون قطعی آماده Cutover بدانید که سایت، دیتابیس، فایل‌ها، SSL، APIها، ایمیل، Cron Jobها و سرویس‌های جانبی بدون خطای جدی کار کنند؛ این مرحله در عمل یکی از مهم‌ترین بخش‌های Zero-Downtime Migration است، زیرا امکان شناسایی مشکل را قبل از اینکه کاربران واقعی به سرور جدید هدایت شوند فراهم می‌کند.

بیشتر بخوانیدResizable BARچیست و چگونه عملکرد کارت گرافیک را تا 15 درصد بهتر می‌کند؟

تست سرور جدید قبل از انتقال نهایی

پیش از اینکه انتقال سایت به سرور جدید را نهایی کنید، باید سرور مقصد را در شرایطی تا حد امکان مشابه محیط واقعی آزمایش کنید؛ ابتدا با فایل Hosts روی یک سیستم مدیریتی، دامنه را موقتا به IP سرور جدید متصل کنید تا بدون تغییر عمومی DNS بتوانید سایت را از مقصد ببینید، سپس صفحات اصلی، ورود کاربران، ثبت‌نام، جست‌وجو و بخش مدیریت را بررسی کنید و بعد به سراغ تست فرم‌ها، ثبت سفارش، سبد خرید، فرآیند پرداخت و تست آپلود فایل بروید تا مشخص شود فایل‌ها، Permissionها و ارتباط با پایگاه داده صحیح هستند. در مرحله بعد، ارسال و دریافت ایمیل، APIها، Webhookها و سرویس‌های خارجی را آزمایش کنید و تمام Cron Jobهای سرور فعلی را فهرست کرده و مطمئن شوید وظایف زمان‌بندی‌شده روی سرور جدید نیز با همان زمان‌بندی و تنظیمات اجرا می‌شوند؛ اگر Cronها روی هر دو سرور هم‌زمان فعال باشند، مراقب اجرای دوباره وظایفی مانند ارسال ایمیل، پردازش سفارش یا عملیات مالی باشید. سپس گواهی SSL را با HTTPS بررسی کنید و مطمئن شوید Certificate، زنجیره گواهی و Redirectهای HTTP به HTTPS درست کار می‌کنند؛ در ادامه لاگ وب‌سرور، لاگ Runtime و لاگ برنامه را بررسی کنید و خطاهای 4xx، 5xx، اتصال دیتابیس، Permission و Timeout را برطرف کنید. هم‌زمان باید مانیتورینگ سرور را فعال کرده و مصرف CPU، RAM، فضای ذخیره‌سازی، Load و سایر منابع سرور را هنگام اجرای درخواست‌های واقعی یا تست بار کنترل کنید؛ AWS نیز در فرایند Cutover توصیه می‌کند پس از آماده‌شدن مقصد، دسترسی و عملکرد نمونه جدید بررسی و برنامه قبل از نهایی‌کردن انتقال آزمایش شود. در پایان، صحت داده‌های مهم را با سرور قدیمی مقایسه کنید و اگر از Replication استفاده می‌کنید، وضعیت و تأخیر همگام‌سازی را بررسی کنید؛ فقط زمانی وارد مرحله تغییر DNS شوید که نتیجه این آزمایش‌ها قابل قبول باشد، زیرا هدف تست سرور جدید قبل از انتقال این است که بخش عمده خطاها پیش از هدایت کاربران واقعی شناسایی شود و احتمال قطعی سایت هنگام مهاجرت به حداقل برسد.

تست فرم‌ها، سفارش، پرداخت و آپلود فایل

بعد از اینکه سایت روی سرور جدید با فایل Hosts در دسترس قرار گرفت، باید قابلیت‌های تعاملی و عملیاتی آن را مرحله‌به‌مرحله بررسی کنید؛ ابتدا فرم‌های تماس، ثبت‌نام، ورود و بازیابی رمز عبور را آزمایش کنید و مطمئن شوید اطلاعات بدون خطا در پایگاه داده ذخیره می‌شوند، سپس در سایت‌های فروشگاهی یک محصول را به سبد خرید اضافه کرده، تعداد و قیمت را تغییر دهید و یک تست ثبت سفارش کامل انجام دهید؛ در مرحله بعد فرآیند پرداخت را در محیط آزمایشی یا با یک تراکنش کنترل‌شده بررسی کنید و مطمئن شوید Callback یا Webhook درگاه به سرور جدید می‌رسد و وضعیت سفارش پس از پرداخت به‌درستی تغییر می‌کند، سپس یک تست آپلود فایل انجام دهید تا محدودیت حجم، Permission پوشه‌ها، مسیر ذخیره‌سازی و دسترسی برنامه به فایل‌های آپلودشده بررسی شود. همچنین اگر سایت تصاویر زیادی دارد، چند تصویر قدیمی و جدید را باز کنید تا مسیر فایل‌ها، لینک‌های ذخیره‌شده و دسترسی وب‌سرور صحیح باشد؛ در ادامه درخواست‌های AJAX و API را بررسی کنید و در لاگ وب‌سرور و لاگ برنامه به دنبال خطاهای 404، 403، 500 و خطاهای Timeout بگردید. این مرحله باید قبل از تغییر DNS انجام شود، زیرا در صورت مشاهده مشکل هنوز می‌توانید ترافیک را روی سرور قدیمی نگه دارید و بدون ایجاد قطعی سایت هنگام مهاجرت مشکل را برطرف کنید؛ در یک Zero-Downtime Migration هدف این است که سرور مقصد پیش از Cutover تا حد امکان اعتبارسنجی شده باشد و تغییر مسیر کاربران، آخرین مرحله مهاجرت باشد.

بررسی APIها، ایمیل، Cron Jobها و لاگ‌ها

در مرحله بعد سرویس‌هایی را آزمایش کنید که ممکن است در انتقال فایل‌های سایت به‌تنهایی قابل مشاهده نباشند؛ ابتدا تمام APIهای مورد استفاده سایت را با درخواست‌های GET و POST آزمایشی بررسی کنید و مطمئن شوید آدرس Endpoint، کلیدها و متغیرهای محیطی، گواهی SSL و دسترسی شبکه روی سرور جدید صحیح هستند، سپس ارسال ایمیل‌های تراکنشی مانند ثبت‌نام، بازیابی رمز، ثبت سفارش و اعلان‌های مدیریتی را آزمایش کنید و لاگ سرویس ایمیل و لاگ برنامه را برای خطا بررسی کنید. بعد فهرست Cron Jobهای سرور قدیمی را با مقصد مقایسه کنید و هر Job را با زمان‌بندی مناسب روی سرور جدید تنظیم کنید؛ اگر عملیاتی مانند پردازش سفارش، ارسال ایمیل یا همگام‌سازی اطلاعات روی Cron اجرا می‌شود، هنگام انتقال مراقب باشید یک Job به‌صورت هم‌زمان روی هر دو سرور اجرا نشود، زیرا ممکن است عملیات تکراری ایجاد کند. در ادامه لاگ وب‌سرور، Runtime و سیستم‌عامل را بررسی کرده و خطاهای غیرعادی را در ساعات مختلف ثبت کنید؛ همچنین زمان پاسخ‌گویی و مصرف CPU و RAM را زیر نظر بگیرید تا مشخص شود مشکل فقط در زمان تست ساده پنهان نمانده است. برای انتقال سایت بدون قطعی بهتر است این آزمایش‌ها پیش از تغییر DNS انجام شوند و نتیجه هر تست مستند شود تا هنگام Cutover دقیقا بدانید چه قابلیت‌هایی باید دوباره بررسی شوند.

تغییر IP و مدیریت DNS Propagation

پس از موفقیت تست‌ها، نوبت به تغییر مسیر دامنه از سرور فعلی به سرور جدید می‌رسد؛ ابتدا چند ساعت یا ترجیحا پیش از پنجره مهاجرت، مقدار TTL رکوردهای DNS مرتبط را کاهش دهید تا Resolverها مدت کوتاه‌تری اطلاعات قدیمی را در Cache نگه دارند، سپس درست قبل از Cutover یک آخرین همگام‌سازی داده‌ها انجام دهید و اگر دیتابیس در حال Replication است، اجازه دهید تغییرات باقی‌مانده به مقصد برسند. بعد رکورد A یا رکورد مناسب دامنه را از IP سرور قدیمی به IP سرور جدید تغییر دهید و بلافاصله پاسخ DNS را از چند Resolver و چند شبکه مختلف بررسی کنید؛ نکته مهم این است که تغییر DNS الزاما به معنی انتقال فوری تمام کاربران نیست، زیرا Resolverها ممکن است پاسخ قبلی را تا پایان TTL در Cache نگه دارند و بنابراین مدتی هر دو سرور باید آماده پاسخ‌گویی باشند. Google Cloud نیز TTL را مدت‌زمانی می‌داند که رکورد DNS می‌تواند در Cache Resolver باقی بماند و در راهکارهای مهاجرت، بررسی Cache و ترافیک باقی‌مانده روی مبدأ اهمیت دارد. در این بازه، DNS Propagation را با ابزارهای مانیتورینگ و بررسی DNS در نقاط مختلف دنبال کنید و اگر هنوز بخشی از کاربران به سرور قدیمی می‌رسند، آن سرور را فعال نگه دارید؛ پس از اطمینان از اینکه ترافیک اصلی به مقصد منتقل شده و داده‌ها نیز هماهنگ هستند، می‌توانید TTL را به مقدار عادی بازگردانید.

فعال نگه داشتن هم‌زمان سرور قدیمی و جدید

برای انتقال سایت بدون قطعی بهتر است پس از تغییر DNS، سرور قدیمی و سرور جدید را برای مدتی هم‌زمان فعال نگه دارید، زیرا همه کاربران بلافاصله رکورد جدید DNS را دریافت نمی‌کنند و برخی Resolverها ممکن است IP قبلی را تا پایان TTL در Cache نگه دارند؛ بنابراین ابتدا مطمئن شوید سایت روی هر دو سرور قابل اجرا است، سپس DNS را به IP جدید تغییر دهید و در ساعات بعد، ترافیک هر دو سرور را از طریق لاگ‌ها، ابزارهای مانیتورینگ و آمار بازدید بررسی کنید. در این مرحله اگر بخشی از کاربران هنوز به سرور قدیمی متصل هستند، نباید آن را خاموش کنید؛ بلکه باید همگام‌سازی داده‌ها را ادامه دهید و مخصوصا برای فایل‌های آپلودی و دیتابیس‌هایی که همچنان تغییر می‌کنند، اختلاف بین دو محیط را کنترل کنید. مستندات Google Cloud نیز در سناریوهای انتقال مبتنی بر DNS توصیه می‌کنند سرویس قدیمی و جدید تا زمان اطمینان از پایان Propagation به‌صورت هم‌زمان اجرا شوند و پس از متوقف‌شدن ترافیک روی مقصد قدیمی، سرویس قبلی کنار گذاشته شود. در عمل، ابتدا چند درخواست واقعی از شبکه‌ها و دستگاه‌های مختلف ارسال کنید، سپس لاگ وب‌سرور را در هر دو سرور بررسی کرده و ببینید چه میزان درخواست هنوز به IP قدیمی می‌رسد؛ هم‌زمان CPU، RAM، فضای ذخیره‌سازی و وضعیت سرویس‌های اصلی سرور جدید را زیر نظر داشته باشید. اگر پس از گذشت زمان مناسب، تقریبا تمام ترافیک به سرور جدید منتقل شده، داده‌ها صحیح هستند و هیچ خطای جدی در فرم‌ها، سفارش‌ها، پرداخت، APIها، ایمیل و Cron Jobها مشاهده نمی‌شود، می‌توانید مرحله بعدی یعنی خاموش‌کردن کنترل‌شده سرور قدیمی را اجرا کنید؛ اما تا قبل از این اطمینان، حذف فوری سرور قدیمی ریسک قطعی سایت هنگام مهاجرت و دشوارشدن Rollback را افزایش می‌دهد.

مانیتورینگ ترافیک و منابع سرور جدید

بعد از تغییر DNS، مانیتورینگ را به‌صورت مرحله‌ای انجام دهید؛ ابتدا لاگ‌XNET‌سرور را روی سرور جدید بررسی کنید تا افزایش درخواست‌ها، خطاهای HTTP، درخواست‌های ناموفق و الگوهای غیرعادی مشخص شود، سپس مصرف CPU سرور، RAM، فضای ذخیره‌سازی، Load و Network را با وضعیت عادی سرور قدیمی مقایسه کنید تا مشخص شود سرور مقصد در بار واقعی نیز ظرفیت کافی دارد. در مرحله بعد، خطاهای 5xx، Timeout، خطاهای اتصال به دیتابیس و خطاهای Application را بررسی کنید و هم‌زمان عملکرد صفحات مهم، APIها، ورود کاربران، ثبت سفارش و پرداخت را کنترل کنید؛ اگر دیتابیس روی سرور جدید قرار گرفته است، وضعیت همگام‌سازی دیتابیس و Replication Lag را نیز زیر نظر داشته باشید. سپس بررسی کنید که فایل‌های جدیدی که کاربران پس از تغییر DNS ایجاد می‌کنند، مانند تصاویر، فایل‌های ضمیمه یا اطلاعات سفارش، در مسیر صحیح ذخیره می‌شوند و مشکل Permission یا کمبود فضا وجود ندارد. در صورت مشاهده افزایش غیرمنتظره مصرف منابع، ابتدا مشخص کنید مشکل از افزایش ترافیک، تنظیمات وب‌سرور، Runtime، Queryهای دیتابیس یا کمبود منابع است و قبل از افزایش منابع سرور علت اصلی را مشخص کنید. AWS نیز در راهنمای Cutover بر ایجاد داشبورد مانیتورینگ و پایش برنامه پس از انتقال تأکید می‌کند تا مشکلات محیط جدید سریع شناسایی شوند. این پایش باید تا زمانی ادامه پیدا کند که اطمینان کافی از پایداری سرور جدید حاصل شود؛ بعد از آن می‌توانید سرور قدیمی را از چرخه عملیاتی خارج کنید.

بررسی کامل داده‌ها و عملکرد سایت

پس از اینکه بیشتر ترافیک به سرور جدید منتقل شد، باید یک بررسی نهایی از داده‌ها و عملکرد انجام دهید؛ ابتدا چند رکورد مهم دیتابیس را با نسخه موجود روی سرور قدیمی مقایسه کنید، سپس تعداد سفارش‌ها، کاربران، محصولات، فایل‌های آپلودشده و سایر داده‌های حساس را بررسی کنید و اگر سایت تراکنش‌های زیادی دارد، گزارش‌های مالی و سفارش‌های ثبت‌شده در بازه مهاجرت را نیز کنترل کنید. در مرحله بعد، چند صفحه مهم و تعدادی از تصاویر و فایل‌های سایت را باز کرده و لینک‌های داخلی را بررسی کنید تا مشخص شود انتقال فایل‌ها کامل بوده است؛ سپس فرم‌ها، ورود کاربران، ثبت سفارش، پرداخت، آپلود، ارسال ایمیل و APIها را دوباره آزمایش کنید و لاگ‌های سرور را برای خطاهای جدید بررسی کنید. اگر از Database Replication استفاده کرده‌اید، قبل از پایان کار مطمئن شوید Replication بدون خطا متوقف شده و دیتابیس مقصد اکنون منبع اصلی عملیات است؛ در غیر این صورت ممکن است با ادامه نوشتن روی سرور قدیمی، داده‌های جدید در دو محیط متفاوت شوند. همچنین وضعیت SSL، Cron Jobها، Firewall، پورت‌های سرور، Permission فایل‌ها و سرویس‌های پس‌زمینه را کنترل کنید. این مرحله باید با یک چک‌لیست از پیش تعیین‌شده انجام شود و صرفا بالا آمدن صفحه اصلی به‌عنوان موفقیت مهاجرت در نظر گرفته نشود؛ زیرا هدف جابه‌جایی سرور تنها انتقال فایل‌ها نیست، بلکه باید کل سرویس شامل برنامه، دیتابیس، فایل‌ها، شبکه و سرویس‌های جانبی بدون نقص روی مقصد کار کند.

خاموش کردن سرور قدیمی پس از اطمینان از انتقال

وقتی DNS Propagation تا حد قابل‌قبولی انجام شد، ترافیک روی سرور قدیمی به میزان ناچیزی رسید و تست‌های عملکردی و داده‌ای موفق بودند، می‌توانید سرور قدیمی را به‌صورت کنترل‌شده از مدار خارج کنید؛ ابتدا از آخرین وضعیت فایل‌ها و دیتابیس یک بکاپ سرور تهیه کنید و آن را در محلی مستقل نگه دارید، سپس Cron Jobها و سرویس‌هایی را که دیگر نباید روی سرور قدیمی اجرا شوند غیرفعال کنید و قبل از خاموش‌کردن، مطمئن شوید هیچ سرویس مهم یا API داخلی هنوز به IP قدیمی وابسته نیست. در مرحله بعد، دسترسی‌های SSH و سرویس‌های اضافی سرور قدیمی را بررسی کنید و در صورت امکان به‌جای حذف فوری، برای مدتی آن را متوقف یا در وضعیت آماده بازگشت نگه دارید؛ زیرا اگر پس از خاموشی خطایی کشف شود، داشتن یک محیط قبلی آماده می‌تواند اجرای Rollback Plan را ساده‌تر کند. مستندات Google Cloud نیز در فرایندهای مهاجرت بر این نکته تأکید دارند که پس از Cutover و اعتبارسنجی موفق می‌توان وارد مرحله نهایی‌سازی شد و در صورت Rollback باید امکان بازگرداندن ترافیک به منبع قبلی و مدیریت داده‌های ایجادشده پس از Cutover وجود داشته باشد. بنابراین برای یک مهاجرت Zero-Downtime حرفه‌ای، خاموش کردن سرور قدیمی را آخرین اقدام بدانید، نه بخشی از انتقال اولیه؛ پس از اطمینان کامل می‌توانید منابع سرور قبلی را آزاد کنید و در نهایت مستندات، IPهای جدید، تنظیمات DNS و اطلاعات دسترسی محیط جدید را به‌روزرسانی کنید.

اگر مهاجرت ناموفق بود چگونه Rollback کنیم؟

برای اجرای برنامه بازگشت در مهاجرت سرور باید قبل از Cutover دقیقا مشخص کنید چه شرایطی باعث بازگشت و چه کسی مسئول تصمیم‌گیری است؛ ابتدا معیارهایی مانند افزایش شدید خطاهای 5xx، از کار افتادن پرداخت، ناسازگاری داده‌ها، مشکل جدی در API یا افزایش غیرعادی مصرف منابع را به‌عنوان Trigger تعیین کنید، سپس تا پایان پنجره Rollback، سرور قدیمی را روشن و آماده نگه دارید. اگر بعد از انتقال سایت به سرور جدید مشکل جدی مشاهده شد، ابتدا عملیات نوشتن روی سرور جدید را متوقف کنید تا داده‌های جدید بدون کنترل بیشتری ایجاد نشوند، سپس در صورتی که معماری شما اجازه می‌دهد سرویس را روی سرور قدیمی فعال کنید و رکورد DNS یا تنظیم Load Balancer را به IP سرور قدیمی برگردانید؛ بعد از تغییر DNS، وضعیت Resolverها و ترافیک را بررسی کنید و مطمئن شوید کاربران دوباره به محیط قبلی می‌رسند. نکته بسیار مهم این است که اگر بعد از Cutover تراکنش جدیدی روی سرور جدید ثبت شده باشد، صرفا برگرداندن DNS کافی نیست و باید تکلیف این داده‌ها مشخص شود؛ می‌توانید از Replication معکوس، Fail-forward، Dual Write یا در شرایط مناسب Backup/Restore استفاده کنید، اما نباید بدون برنامه داده‌های جدید را حذف یا با نسخه قدیمی جایگزین کنید. AWS نیز توصیه می‌کند Rollback برای حالت بدون داده جدید با بازگرداندن ترافیک به محیط قبلی ساده‌تر است، اما اگر پس از Cutover داده جدید ایجاد شده باشد، باید استراتژی مشخصی برای انتقال یا حفظ آن داده‌ها داشته باشید. در پایان، علت شکست را ثبت کنید، سرویس جدید را از دسترس کاربران خارج نگه دارید، مشکل را برطرف کنید و پیش از اجرای دوباره مهاجرت Zero-Downtime، سناریوی انتقال را مجددا در محیط آزمایشی تمرین کنید؛ بنابراین Rollback Plan نباید فقط یک Backup ساده باشد، بلکه باید شامل Triggerهای بازگشت، روش تغییر DNS، وضعیت دیتابیس، مسئول تصمیم‌گیری و مراحل بازگرداندن سرویس باشد.

اشتباهات رایج در مهاجرت سرور بدون قطعی

یکی از رایج‌ترین اشتباهات در مهاجرت سرور بدون قطعی این است که انتقال فقط به کپی فایل‌های سایت محدود شود و سرویس‌هایی مانند دیتابیس، Cron Job، API، ایمیل، SSL و تنظیمات Firewall نادیده گرفته شوند؛ برای جلوگیری از این مشکل، ابتدا تمام سرویس‌ها و وابستگی‌های سرور فعلی را فهرست کنید، سپس همان موارد را روی سرور مقصد پیاده‌سازی و تست کنید. اشتباه دوم، تغییر DNS پیش از آماده‌شدن کامل سرور جدید است؛ ابتدا باید فایل‌ها، دیتابیس و تنظیمات منتقل شوند، تست‌های عملکردی انجام شوند و سپس DNS تغییر کند. اشتباه سوم، نادیده گرفتن داده‌هایی است که در فاصله انتقال اولیه تا Cutover ایجاد می‌شوند؛ اگر سایت پویا است، باید از همگام‌سازی داده‌ها یا Replication استفاده کنید و قبل از تغییر مسیر، آخرین تغییرات را به مقصد منتقل کنید. اشتباه دیگر، خاموش‌کردن سریع سرور قدیمی است؛ پس از تغییر DNS باید هر دو محیط را مدتی فعال نگه دارید، زیرا DNS Propagation برای همه کاربران هم‌زمان اتفاق نمی‌افتد و برخی Resolverها ممکن است همچنان IP قبلی را در Cache داشته باشند. همچنین کاهش ندادن TTL پیش از مهاجرت، نداشتن بکاپ دیتابیس قابل بازیابی، تست نکردن فرم‌ها و پرداخت، انتقال ناقص تصاویر و فایل‌ها، فراموش کردن Cron Jobها، عدم بررسی Permissionها، ناسازگاری نسخه Runtime یا PHP، باز نبودن پورت‌های موردنیاز و نداشتن مانیتورینگ از دیگر خطاهای متداول هستند. AWS در راهنمای برنامه‌ریزی Cutover تأکید می‌کند که پیش از انتقال باید وابستگی‌های سیستم، تست عملکردی، اتصال سرویس‌ها، زمان Downtime و روش Rollback مشخص و مستند شوند. بنابراین برای کاهش Downtime نباید تنها روی سرعت کپی فایل‌ها تمرکز کنید؛ موفقیت Zero-Downtime Migration حاصل هماهنگی هم‌زمان DNS، فایل‌ها، دیتابیس، سرویس‌های نرم‌افزاری، شبکه، مانیتورینگ و یک برنامه بازگشت آزمایش‌شده است.

بیشتر بخوانیدعلت خرابی ناگهانیSSDچیست؟+ علائم ، تست سلامت و زمان تعویض

چک‌لیست نهایی Zero-Downtime Migration

برای اینکه قبل از پایان جابه‌جایی سایت بین سرورها مطمئن شوید چیزی از قلم نیفتاده است، ابتدا بررسی کنید که بکاپ سرور، بکاپ دیتابیس و بکاپ فایل‌های سایت تهیه و خارج از سرور نگهداری شده‌اند، سپس منابع سرور جدید شامل CPU، RAM و فضای ذخیره‌سازی را با نیاز واقعی سایت مقایسه کنید و مطمئن شوید وب‌سرور، Runtime و پایگاه داده به‌درستی نصب شده‌اند؛ در مرحله بعد، انتقال فایل‌ها و تصاویر را بررسی کنید و مالکیت و Permission مسیرهای مهم را کنترل کنید، سپس دیتابیس را Import یا با Replication همگام کنید و قبل از Cutover صحت رکوردهای مهم و وضعیت Replication را بررسی کنید. در مرحله بعد گواهی SSL، Firewall، SSH، پورت‌های موردنیاز، APIها، ایمیل و Cron Jobها را تست کنید و با استفاده از فایل Hosts، سایت را بدون تغییر عمومی DNS بررسی کنید؛ سپس فرم‌ها، ورود کاربران، ثبت سفارش، پرداخت و آپلود فایل را آزمایش کرده و لاگ‌XNET‌سرور و Runtime را برای خطاهای 4xx، 5xx و Timeout بررسی کنید. پیش از تغییر DNS، TTL رکوردهای لازم را کاهش دهید، زمان Cutover و مسئول هر مرحله را مشخص کنید و یک Rollback Plan قابل اجرا داشته باشید؛ هنگام Cutover، آخرین همگام‌سازی داده‌ها را انجام دهید، در صورت نیاز نوشتن دیتابیس را برای مدت کوتاهی متوقف کنید، DNS را به IP سرور جدید تغییر دهید و سپس ترافیک، منابع و عملکرد مقصد را زیر نظر بگیرید. Google Cloud توضیح می‌دهد که پس از تغییر DNS، به دلیل Cache شدن رکوردها و TTL، انتقال ترافیک برای همه کاربران فوری نیست و باید محیط قدیمی و جدید تا پایان این مرحله هم‌زمان در دسترس باشند. در نهایت، وقتی ترافیک روی سرور قدیمی عملا متوقف شد، داده‌ها صحیح بودند، سرویس‌ها پایدار بودند و معیارهای عملکردی مورد انتظار تأمین شد، می‌توانید سرور قدیمی را از مدار خارج کنید؛ این ترتیب باعث می‌شود مهاجرت Zero-Downtime به‌جای یک جابه‌جایی ناگهانی، به یک فرآیند کنترل‌شده با امکان تست، پایش و بازگشت تبدیل شود.

سوالات متداول درباره مهاجرت سرور بدون قطعی

نوشتهآموزش مهاجرت سرور بدون قطعی؛ انتقال سایت به سرور جدید با کمترین Downtimeاولین بار درTechnoc. پدیدار شد.

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