هر داستان ترسناک مهاجرت وسطی یکسان دارد: کسی اول DNS را عوض کرده و بعد شروع به کپی کرده است. قطعی هنگام جابهجایی تقریباً هیچ‌وقت به خاطر کند بودن کپی نیست. به خاطر انجام مراحل با ترتیب اشتباه است.
این ترتیبی است که جواب می‌دهد، چه از ارائه‌دهندهٔ دیگری می‌آیید و چه میان دو تعرفهٔ ما جابه‌جا می‌شوید.
۱. دو روز پیش: TTL را کم کنید
رکوردهای DNS را که تغییر خواهید داد پیدا کنید (معمولاً A، AAAA و هر CNAME که به آن‌ها اشاره میکند) و TTL آن‌ها را به 300 ثانیه برسانید. بعد دستکم به اندازهٔ TTL قدیمی صبر کنید. رکوردی با TTL یک‌روزه یعنی برخی resolverها تا یک روز پس از تغییر همچنان نشانی قدیمی را می‌دهند، و هیچ کاری روی سرور سرعتش را بیشتر نمی‌کند.
این همان مرحله‌ای است که مردم جا می‌اندازند، و همین است که جابهجایی پنج‌دقیقه‌ای را به روزی تبدیل میکند که نیمی از کاربران سرور قدیمی را می‌بینند.
۲. از سرور قدیمی فهرست بردارید
قرار است این ماشین را جای دیگری از نو بسازید، پس بنویسید واقعاً چه کار میکند. نه آنچه به خاطر دارید. آنچه انجام می‌دهد:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
به فهرست اضافه کنید: گواهی‌های TLS و نحوهٔ تمدیدشان، فایل‌های محیطی حاوی رازها، قواعد فایروال، کاربران و کلیدهای SSH آن‌ها، پایگاه‌داده و حجمش، و هر چیزی که با نشانی IP با سرور صحبت میکند. این گروه آخر موذی است: فهرست مجاز یک شریک، تنظیمات webhook یک درگاه پرداخت، یک بررسی پایش.
۳. سرور تازه را کنار سرور قدیمی بسازید
سرور تازه را سفارش دهید و به قدیمی دست نزنید. از فهرست VPS تعرفه‌ای با دیسکی برابر یا بیشتر از آنچه واقعاً استفاده می‌کنید انتخاب کنید، نه آنچه به شما فروخته‌اند. اگر ماشین قدیمی هر نوع ترافیک ورودی دریافت میکند (سایت، webhook، API)، ماشین تازه IPv4 اختصاصی لازم دارد. تعرفهٔ NAT اتصال ورودی را فقط روی پورت SSH خودش می‌پذیرد، و یک پورت فوروارد‌شده چه کاری می‌تواند بکند و چه کاری نه توضیح می‌دهد چرا این مهم است.
وصل شوید، همان بسته‌ها را نصب کنید، کاربران و فایروال را از نو بسازید. کلیدها و نخستین ورود در راهنمای اتصال آمده است.
۴. فایلها را دو بار همگام کنید
همگامسازی اول همه‌چیز را کپی میکند در حالی که سرور قدیمی به کارش ادامه می‌دهد. ممکن است ساعت‌ها طول بکشد؛ اشکالی ندارد.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
گزینهٔ --numeric-ids مالکیت فایلها را بر اساس شماره نگه می‌دارد و جلوی غافلگیری کلاسیک «همه‌چیز مال کاربر اشتباه است» را می‌گیرد، وقتی دو سیستم کاربران را با ترتیب متفاوت ساخته‌اند. اگر هرگز rsync را روی SSH به کار نبرده‌اید، چطور فایلها را به VPS منتقل کنیم گام‌به‌گام توضیحش می‌دهد.
همگامسازی دوم، درست پیش از جابهجایی، فقط آنچه را از اولی به بعد تغییر کرده کپی میکند. معمولاً چند ثانیه طول می‌کشد.
۵. پایگاه‌داده را آگاهانه منتقل کنید
فایلها ساده‌اند. پایگاهدادهای که نوشتن دریافت میکند تنها بخشی است که «بدون قطعی» در آن یا یک مصالحهٔ کوچک می‌خواهد یا کار بیشتر.
راه ساده: یک بار برای آزمایش dump بگیرید و بازیابی کنید، و هنگام جابهجایی نوشتن را یک دقیقه متوقف کنید (برنامه را در حالت فقط‌خواندنی بگذارید یا متوقفش کنید)، یک dump تازه بگیرید، روی سرور تازه بازیابی کنید و برنامه را آنجا راه بیندازید. برای بیشتر پروژه‌های کوچک این یک توقف یکی دو دقیقه‌ای است که میشود از قبل اعلامش کرد.
راه بدون توقف: از پایگاه‌دادهٔ قدیمی به تازه replication راه بیندازید، بگذارید عقب‌ماندگی‌اش را جبران کند، و هنگام جابهجایی پایگاه تازه را اصلی کنید. راه‌اندازی بیشتری دارد، و وقتی حتی یک دقیقه نوشتن ازدست‌رفته پذیرفتنی نیست، می‌ارزد.
۶. سرور تازه را پیش از اینکه کس دیگری ببیند آزمایش کنید
DNS هنوز به سرور قدیمی اشاره میکند، پس میتوانید سرور تازه را بی‌سروصدا آزمایش کنید. درخواستی برای دامنهٔ واقعیتان به نشانی تازه بفرستید:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
اگر گواهی هنوز آنجا نیست، به همین شکل روی HTTP آزمایش کنید، یا یک خط موقت به فایل hosts اضافه کنید و در مرورگر سایت را بگردید. ورود، بارگذاری، کارهای پس‌زمینه و ایمیل خروجی را بررسی کنید. این ارزان‌ترین لحظه برای کشف یک افزونهٔ PHP جاافتاده است.
۷. جابه‌جا کنید، و سرور قدیمی را روشن نگه دارید
همگامسازی آخر فایلها و مرحلهٔ پایگاه‌داده را انجام دهید، سپس رکوردهای DNS را عوض کنید. با TTL سیصدثانیه‌ای بیشتر ترافیک در چند دقیقه منتقل میشود. لاگ دسترسی سرور قدیمی را زیر نظر بگیرید: هنوز باریکه‌ای از درخواست‌ها از resolverها و کلاینت‌هایی که TTL را نادیده میگیرند به آن می‌رسد. چند روز بدون تغییر روشنش بگذارید. بعد هر چیزی را که به IP قدیمی اشاره میکند بهروز کنید: فهرستهای مجاز شرکا، نشانیهای webhook، و برای ایمیل DNS معکوس نشانی تازه (در تعرفه‌های IP اختصاصی ما خودتان تنظیمش می‌کنید، ببینید DNS معکوس) و رکورد SPF.
آنچه بیشتر از همه خراب میشود
تقریباً به ترتیب دفعاتی که می‌بینیم: تایمر systemd که هیچ‌کس در فهرست نیاورده، فایل پیکربندی‌ای که IP قدیمی مستقیم در آن نوشته شده، فایل‌هایی که مال کاربر اشتباه‌اند، فایروالی که پورت خود برنامه را می‌بندد، گواهی‌ای که روی سرور قدیمی تمدید میشود ولی روی تازه نه، و ایمیلی که به اسپم می‌رود چون نشانی تازه هنوز DNS معکوس ندارد.
جایی که این چک‌لیست جواب نمی‌دهد
پایگاه‌دادهٔ پرکار با نوشتن پیوسته و بی‌تحمل در برابر توقف، به replication واقعی و یک تمرین کامل نیاز دارد، نه به چک‌لیست یک وبلاگ. سرورهای Windows با ابزارهایی جز rsync جابه‌جا می‌شوند. و اگر جابهجایی در اصل به خاطر اندازه است، اول این را بخوانید: اینجا تعرفه‌ها در جا بزرگ می‌شوند. رفتن به تعرفهٔ بزرگ‌تر از همان نوع شبکه با یک ری‌استارت vCPU و رم و دیسک اضافه میکند، بدون هیچ مهاجرتی. سرور تازه فقط برای کوچک کردن لازم است. اگر چون مطمئن نیستید ماشین کافی است جابه‌جا می‌شوید، کی واقعاً به ۶۴ گیگابایت رم نیاز دارید شاید شما را از این سفر معاف کند، و اگر مطمئن نیستید VPS اصلاً خانهٔ درستی است، VPS، هاست اشتراکی، سرور اختصاصی یا ابر کمکتان میکند.
نظرات
هنوز نظری نیست. اولین نفر باشید.