У каждой страшной истории о переезде одна и та же середина: кто-то сначала поменял 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 вообще правильный дом.
Комментарии
Пока нет комментариев. Будьте первым.