У кожної страшної історії про переїзд та сама середина: хтось спершу змінив DNS, а потім почав копіювати. Простій під час переїзду майже ніколи не пов'язаний із тим, що копіювання йде повільно. Він пов'язаний із неправильним порядком кроків.
Ось порядок, який працює, — чи йдете ви від іншого провайдера, чи переїжджаєте між двома нашими тарифами.
1. За два дні: знизьте TTL
Знайдіть DNS-записи, які змінюватимете (зазвичай A, AAAA і всі CNAME, що на них вказують), і знизьте їхній TTL до 300 секунд. Потім зачекайте щонайменше стільки, скільки був старий TTL. Запис із TTL на добу означає, що частина резолверів віддаватиме стару адресу ще добу після зміни, і ніщо на сервері цього не пришвидшить.
Цей крок пропускають найчастіше, і саме він перетворює п'ятихвилинне перемикання на день, коли половина користувачів бачить старий сервер.
2. Складіть опис старого сервера
Ви збираєтеся перезібрати цю машину деінде, тож запишіть, що вона насправді робить. Не те, що ви пам'ятаєте. Те, що вона робить:
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-адресою. Остання група найпідступніша: allowlist у партнера, налаштування вебхуків у платіжного провайдера, перевірка моніторингу.
3. Зберіть новий сервер поруч зі старим
Замовте новий сервер, а старий не чіпайте. Оберіть тариф зі списку VPS з таким самим або більшим диском, ніж ви реально використовуєте, а не ніж вам продали. Якщо на стару машину приходить хоч якийсь вхідний трафік (сайт, вебхуки, API), новій потрібен власний IPv4. NAT-тариф приймає вхідні з'єднання лише на своєму SSH-порту, а чому це важливо, пояснює стаття Що може й чого не може один проброшений порт.
Під'єднайтеся, поставте ті самі пакети, заново створіть користувачів і фаєрвол. Ключі й перший вхід описано в посібнику з підключення.
4. Синхронізуйте файли двічі
Перша синхронізація копіює все, поки старий сервер працює далі. Вона може тривати годинами — це нормально.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids зберігає власників файлів за номером, і це рятує від класичного сюрпризу «усе належить не тому користувачеві», коли дві системи створювали користувачів у різному порядку. Якщо ви ще не користувалися rsync через SSH, стаття Як передати файли на VPS розбирає це крок за кроком.
Друга синхронізація, просто перед перемиканням, копіює лише те, що змінилося після першої. Зазвичай це секунди.
5. Переносьте базу даних свідомо
З файлами все просто. База даних, яка приймає записи, — єдине місце, де «без простою» потребує або невеликого компромісу, або додаткової роботи.
Простий шлях: один раз зробити дамп і відновити його для тестів, а в момент перемикання зупинити запис на хвилину (перевести застосунок у режим лише читання або зупинити його), зняти свіжий дамп, відновити на новому сервері й запустити застосунок там. Для більшості невеликих проєктів це пауза в хвилину-дві, про яку можна попередити заздалегідь.
Шлях без паузи: налаштувати реплікацію зі старої бази на нову, дати їй наздогнати, а в момент перемикання зробити нову базу основною. Налаштування більше, і воно того варте, коли навіть хвилина втрачених записів неприпустима.
6. Перевірте новий сервер, поки його ніхто не бачить
DNS досі вказує на старий сервер, тож новий можна перевірити без свідків. Надішліть запит до свого справжнього домену на нову адресу:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
Якщо сертифіката там ще немає, перевірте так само по HTTP або додайте тимчасовий рядок у файл hosts і проклікайте сайт у браузері. Перевірте вхід, завантаження файлів, фонові задачі й вихідну пошту. Це найдешевша мить, щоб виявити розширення PHP, якого бракує.
7. Перемикайте й не вимикайте старий сервер
Зробіть фінальну синхронізацію файлів і крок із базою, потім змініть DNS-записи. З TTL у 300 секунд основна частина трафіку переїде за хвилини. Стежте за логом доступу старого сервера: туди ще капатиме від резолверів і клієнтів, які ігнорують TTL. Залиште його увімкненим і незмінним на кілька днів. Потім оновіть усе, що вказує на старий IP: allowlist у партнерів, адреси вебхуків, а для пошти — зворотний DNS нової адреси (на наших тарифах із виділеним IP ви задаєте його самі, див. зворотний DNS) і SPF-запис.
Що ламається найчастіше
Приблизно в порядку частоти, з якою ми це бачимо: таймер systemd, якого ніхто не вніс до списку, конфіг із захардкодженою старою IP, файли, що належать не тому користувачеві, фаєрвол, який блокує власний порт застосунку, сертифікат, що подовжується на старому сервері, але не на новому, і пошта, яка летить у спам, бо в нової адреси ще немає зворотного DNS.
Де цей чекліст не підходить
Навантаженій базі з постійними записами й нульовою терпимістю до паузи потрібна повноцінна реплікація й репетиція, а не чекліст із блогу. Windows-сервери переїжджають іншими інструментами, ніж rsync. І якщо переїзд насправді про розмір, спершу прочитайте ось що: тарифи тут ростуть на місці. Перехід на більший тариф того самого мережевого типу додає vCPU, RAM і диск одним перезавантаженням, без жодного переїзду. Новий сервер потрібен лише для зменшення. Якщо ви переїжджаєте, бо не певні, чи вистачає машини, стаття Коли вам насправді потрібно 64 GB RAM може позбавити вас цієї подорожі, а VPS, shared-хостинг, виділений сервер чи хмара допоможе, якщо ви не певні, що VPS узагалі правильний дім.
Коментарі
Поки немає коментарів. Будьте першим.