Переезд на другой VPS без даунтайма: чек-лист миграции

Часть 14 из 14 · Серия «Сервер в бою» — финал

Поводов переехать у VPS-владельца за жизнь накапливается достаточно: у соседнего провайдера вдвое дешевле и втрое быстрее диски; старый тариф стал тесен; провайдер начал чудить; или — помните шестую статью? — вы выбрали «путь Б»: вместо release-upgrade на живую поднять свежую систему рядом. Повод есть почти у каждого. Не переезжают годами по одной причине — страшно: кажется, что миграция — это ночь без сна, лежащий сайт и лотерея «взлетит ли на новом месте».

Финальная статья серии — о том, что миграция без даунтайма не трюк, а последовательность, и держится она на одном принципе, который снимает 90% страха: старый сервер продолжает работать до самого конца и ещё пару недель после. Никакого «выключил тут — включил там». Два сервера живут параллельно, трафик перетекает со старого на новый плавно, а если что-то идёт не так — на любом шаге можно просто... не переключаться. Откат по умолчанию, встроенный в саму схему. А в конце закольцуем серию с того, с чего она фактически началась — со статьи про бэкапы, — потому что миграция, как выяснится, и есть самая честная их проверка.

Фаза 0, за неделю до: TTL, инвентаризация, новый дом

Снижаем TTL — самый ранний и самый забываемый шаг. Когда вы смените A-запись домена на новый IP, мир узнает об этом не мгновенно: DNS-ответы кэшируются на срок TTL, указанный в записи. Типичный TTL — час, а то и сутки: смените запись — и сутки часть посетителей будет ходить на старый сервер, часть на новый. Поэтому за несколько дней до переезда идём в DNS-панель и ставим A-записям TTL = 300 (5 минут). Тонкость, которую упускают: новое значение начнёт действовать только после того, как истечёт старое — если стоял TTL 86400, снижать его надо минимум за сутки до часа Х. Правило: снизь TTL за срок старого TTL. Теперь окно переключения — минуты, а не сутки.

Инвентаризация. Главный источник послемиграционных сюрпризов — не то, что переносили, а то, о чём забыли. Сядьте и выпишите всё, что живёт на сервере, — и тут читателя серии ждёт приятный момент: оглавление этих четырнадцати статей и есть готовый чек-лист. Сайты и их конфиги nginx с пулами PHP-FPM (статья 8), базы и их пользователи (10), кроны и таймеры — crontab -l от каждого пользователя плюс systemctl list-timers (12), jail'ы fail2ban (3), пиры WireGuard (7), сертификаты, .env из shared (13), настройки journald и logrotate (5), unattended-upgrades (6). Пройдитесь по списку с блокнотом — полчаса, которые сэкономят неделю «а почему письма перестали уходить».

Поднимаем новый сервер — и переносим окружение, а не копируем сервер. Соблазн «скопировать всё как есть» понятен, но переезд — редкий шанс получить чистую систему без трёхлетних наслоений (ради этого путь Б и выбирали). Разворачиваем на свежей LTS всё по инвентаризации: пользователи и права, nginx, пулы, MySQL с посчитанным buffer pool, fail2ban, мониторинг. Если код выезжает деплоем из прошлой статьи — половина переезда сводится к ./deploy.sh на новом сервере, и это лучший аргумент за уровень 3, который я приберегал напоследок. Единственная заминка — сертификат: Let's Encrypt не выдаст его серверу, на который домен ещё не указывает, штатным HTTP-способом. Два выхода: проверка через DNS (certbot -d site1.ru --preferred-challenges dns с TXT-записью) — или просто скопировать /etc/letsencrypt со старого сервера rsync'ом, это законно и работает.

Фаза 1: большая синхронизация — не спеша

Данные, которые не в Git: загрузки пользователей, shared/storage, база. Переносим rsync'ом — и вот где раскрывается его главное свойство: инкрементальность. Первый прогон большой и медленный, зато все последующие докидывают только изменившееся — на этом построена вся схема «финальная синхронизация за минуту».

# со старого сервера, первый прогон — заранее, хоть за день:
rsync -azP --delete /var/www/site1/shared/ site1@новый-ip:/var/www/site1/shared/

(-a — с правами и владельцами, -z — сжатие, -P — прогресс и докачка, --delete — удалять на приёмнике то, что удалено на источнике.) База — дампом, для маленького VPS это честный и достаточный путь:

mysqldump --single-transaction --routines site1_db | gzip > /tmp/site1.sql.gz
rsync -azP /tmp/site1.sql.gz site1@новый-ip:/tmp/
# на новом: zcat /tmp/site1.sql.gz | mysql site1_db

--single-transaction снимает согласованный снимок InnoDB-базы без блокировки — сайт на старом сервере ничего не замечает. Данные на новом сервере после этой фазы чуть устаревшие — и это нормально: свежую дельту докатим в момент переключения.

Фаза 2: репетиция — переключаемся, не переключаясь

Вот приём, который отличает миграцию по чек-листу от миграции на удачу. Как проверить сайт на новом сервере до смены DNS, если nginx ждёт запросов с правильным доменом, редиректы уводят на домен, а сертификат выписан на домен? Обмануть только свой компьютер — файлом hosts:

# /etc/hosts на вашей машине (Windows: C:\Windows\System32\drivers\etc\hosts)
203.0.113.99  site1.ru www.site1.ru

Теперь для всего мира сайт живёт на старом сервере, а для вас — на новом, по настоящему домену, с настоящим HTTPS. И начинается генеральный прогон, по-настоящему, руками: главная, вход в админку, добавить товар в корзину, отправить форму (и проверить, что письмо дошло — отправка почты со свежего IP — известное слабое место), загрузить файл. Параллельно — приборы: tail -f на error.log нового сервера (вторая статья — наш вечный спутник) и systemctl --failed. Каждая найденная сейчас проблема — это проблема, найденная без единого пострадавшего посетителя. Чините, повторяйте прогон, и только когда репетиция чистая — назначайте премьеру. Не забудьте потом убрать строку из hosts — классика: «у меня работает, у всех лежит» наоборот.

Фаза 3: переключение — час Х длиной в полчаса

Выбираем тихое время (ночь — по трафику вашей аналитики, а не по привычке) и идём по короткому сценарию.

Шаг 1: замораживаем запись на старом. Минутная честность насчёт «без даунтайма»: читатели не заметят ничего, но окно для записи — заказов, комментариев — на несколько минут нужно, иначе данные, созданные на старом сервере после снятия дампа, потеряются. Для блога достаточно ничего не делать, для магазина — php artisan down или режим read-only на минуты финальной синхронизации. (Строгий вариант без единой потерянной записи тоже существует: сразу после переключения DNS старый nginx превращается в прокси на новый IP — тогда даже посетители с закэшированным DNS попадают на новый сервер. Для большинства маленьких сайтов это перфекционизм, но знать о нём стоит.)

Шаг 2: финальная дельта. Те же команды из фазы 1 — но теперь rsync докидывает только изменения за прошедшие дни, а дамп свежей базы при снятом трафике летит быстро. Минуты.

Шаг 3: DNS. Меняем A-записи на новый IP. Благодаря TTL=300 мир переучивается за минуты.

Шаг 4: смотрим, как трафик перетекает. Красивейший момент всей операции — два окна, в каждом tail -f access.log своего сервера: слева, на старом, запросы редеют; справа, на новом, — набирают частоту. Когда левое окно замолкает (боты будут скрестись ещё долго — не в счёт), снимаем заглушку на новом, проходим смок-тест ещё раз — переезд состоялся. Uptime Kuma из четвёртой статьи всё это время дежурит снаружи и молчит — а значит, для мира не происходило вообще ничего.

Фаза 4: две недели страховки — и закрытие кольца

Не выключайте старый сервер. Он — ваш живой откат: пойди что-то не так на новом хоть завтра, возврат — это одна правка DNS обратно (TTL всё ещё 300 — не спешите его поднимать). Две недели параллельной жизни — срок, за который всплывает всё редкое: недельный отчёт из cron, ежемесячная задача, письмо с забытой формы, тот самый таймер, которого не было в инвентаризации. Поглядывайте в логи старого сервера: любой живой запрос туда — след чего-то непереехавшего. Через две недели тишины: финальный бэкап старого сервера в архив, снапшот на память — и гасите. TTL можно вернуть к часу.

И вот оно, обещанное кольцо. Присмотритесь к тому, что вы только что проделали: развернули систему с нуля по описанию, восстановили данные из копий, убедились, что всё работает, — миграция и восстановление из бэкапа — это одна и та же операция, просто у миграции «авария» плановая. Та статья про бэкапы начиналась с мысли, что непроверенная копия — мёртвый груз; так вот, переезд — самая честная проверка из существующих, и вы её только что прошли. Сервер, который можно пересоздать за вечер по инвентаризации и бэкапам, — это и есть настоящая устойчивость. Не uptime 700 дней, а воспроизводимость.

Сводный чек-лист миграции

Финал серии

Четырнадцать статей назад всё началось с трёх часов ночи, паники и руки, тянущейся к кнопке «Перезагрузить». Посмотрите на дистанцию: сервер теперь сам сообщает о проблемах раньше клиентов, сам чистит диск, сам продлевает сертификаты и докладывает о собственном здоровье; логи из простыни превратились в собеседника; боты кормятся банами, а не ресурсами; воркеры и память посчитаны, а не наугаданы; выкатка — команда, откат — симлинк, и даже переезд целого сервера — чек-лист на страницу, а не подвиг. Ни в одном из четырнадцати сюжетов не было магии — был один и тот же метод: сначала посмотри и измерь, потом трогай; всё важное — автоматизируй; всё автоматизированное — заставь отчитываться. «Сервер в бою» — это не сервер, на котором тушат пожары. Это сервер, за которым присматривают — и потому пожаров почти не бывает. Спокойных вам логов и зелёных мониторов. Серия окончена — сервер продолжает работать.