Миграция нескольких VPS на выделенный сервер с минимальным простоем: порядок переноса и возврата

MAATRIX · Выделенные серверы · Статья 33 из 48

Самый важный момент переезда наступает не тогда, когда меняется IP-адрес. Он наступает, когда новая площадка принимает первую рабочую запись: заказ, загруженный файл, изменение профиля. После этого старый сервер уже нельзя просто объявить главным обратно. На двух сторонах появилась разная история, и с ней придётся разобраться.

Поэтому миграция нескольких VPS на один выделенный сервер — прежде всего задача согласованности данных. Копирование занимает заметное время и хорошо видно на графиках. Управление записью менее зрелищно, зато именно оно помогает закончить переезд без потерянных операций.

Разберём план, который сокращает остановку за счёт предварительной подготовки, проверенного переноса и ясного переключения. Универсального обещания «без простоя» здесь быть не может: возможность непрерывной работы зависит от приложения, способа хранения данных и допустимой сложности перехода. Для многих проектов короткое согласованное окно надёжнее, чем неподготовленная попытка сделать его невидимым.

У нескольких VPS обычно больше обязанностей, чем кажется

Начните с инвентаризации. На каждом сервере есть очевидные службы и тихие обязанности: расписания, обработчики очередей, обновление сертификатов, отправка писем, выгрузки, приём вебхуков, резервное копирование. Если перенести только веб-приложение и базу, сайт может успешно открыться, а ночной обмен данными — исчезнуть.

Для каждой службы укажите владельца, версию, зависимости, данные, секреты, внешние адреса и способ запуска. Отдельно отметьте, какие процессы имеют право менять состояние. Это не только HTTP-запросы пользователей: фоновый worker и старое расписание способны продолжать запись после включения красивой страницы технических работ.

Составьте карту общих данных. Несколько приложений могут использовать одну базу, общий каталог загрузок или очередь. Такие компоненты нельзя переносить как независимые чемоданы, не проверив совместимость промежуточных состояний.

Полезно также выяснить, почему сервисы изначально были разделены. Иногда это историческая случайность, иногда — разные требования к доступности, безопасности или ОС. Переезд на одну физическую машину объединяет аппаратный риск. Несколько новых VM на ней сохранят логическое разделение, но не прежнюю независимость от отказа хоста.

Подготовьте место назначения до объявления окна

Размер нового сервера считают по одновременному потреблению, а не по сумме выданных vCPU. Память должна вмещать рабочие наборы, диск — данные, временные копии, журналы и рост. CPU и накопители проверяют при смешанной нагрузке: несколько прежде независимых процессов теперь встретятся на общей машине.

ANKH с шестью ядрами Ryzen 7600X, 64 ГБ DDR5 и 1 ТБ NVMe за $329 в месяц может подойти для умеренной консолидации. PYLON с шестнадцатью ядрами Ryzen 7950X и теми же объёмами RAM и диска за $429 стоит проверять при большей вычислительной работе. Количество старых VPS само по себе не определяет выбор между ними.

Если нужны 128 ГБ памяти и больше независимых исполнителей, кандидатом становится NECROPOLIS: 48 ядер EPYC 7642 и 2 × 1 ТБ NVMe за $529. При зеркале полезный номинальный объём близок к одному терабайту. Российский CARTOUCHE за $295 даёт 128 ГБ DDR4, 28 ядер двух E5-2680 v4 суммарно и 2 × 600 ГБ SSD; здесь особенно внимательно проверяют вместимость и скорость рабочих операций.

На новом хосте заранее настраивают ОС или гипервизор, сеть, ограничение доступа, наблюдение и независимое резервное копирование. Проверяют путь восстановления доступа при проблемах загрузки, уточняя доступные средства у провайдера. Возможность KVM или собственной установки не следует считать автоматически включённой в любой тариф.

У ANKH и PYLON в карточках указан срок подготовки 72 часа, у NECROPOLIS — 96. Это только часть календаря: после выдачи ещё нужны установка и испытания. Окно миграции назначают по готовности проверенной среды, а не по времени появления письма с доступами.

Выберите способ переноса каждого вида данных

Статические файлы удобно копировать заранее и затем передать изменения. Но для загружаемых пользователями файлов нужен момент согласования: пока старое приложение продолжает записывать, предварительная копия неизбежно отстаёт. Финальная синхронизация проводится после остановки соответствующих записывающих процессов или другим проверенным механизмом согласованного переноса.

Для СУБД используют штатный способ резервного копирования, восстановления или репликации. Обычное копирование изменяющегося каталога базы не гарантирует работоспособной копии. Например, документация PostgreSQL по файловым резервным копиям отдельно описывает требования к остановке и согласованным снимкам. Без выполнения этих условий похожие файлы не означают одинаковую базу.

Небольшую базу иногда проще перенести через штатную выгрузку и восстановление в согласованное окно. Большую — предварительно развернуть на целевой стороне и поддерживать актуальность репликацией. Выбор зависит от объёма, потока изменений, версии СУБД и допустимой остановки, а не от желания обязательно использовать более сложный механизм.

В PostgreSQL физическая потоковая репликация предъявляет требования к совместимости версии и среды. Логическая репликация имеет другой набор возможностей и ограничений: например, перенос изменений схемы и состояния последовательностей требует отдельного внимания. Проверять их следует по официальному перечню ограничений, а не считать любое слово «репликация» полным клонированием сервера.

Очереди, поисковые индексы и кэши тоже требуют собственного решения. Восстанавливаемый кэш иногда можно прогреть заново. В очереди могут находиться ещё не выполненные обязательства перед пользователями. Считать их одинаково расходными данными было бы слишком смелой оптимизацией.

Репетиция отвечает на вопрос, сколько продлится остановка

Перед рабочим переключением выполните перенос представительной копии и измерьте этапы. Сколько занимает полная передача? Как быстро целевая база применяет накопившиеся изменения? Сколько времени занимает контроль целостности, запуск приложения и проверка внешних интеграций?

Если источник производит изменения быстрее, чем новая сторона успевает их получать и применять, реплика не догонит его по одному вашему желанию. Нужно изменить условия: ресурсы, канал, нагрузку или способ переноса. Окно, рассчитанное по размеру базы и теоретическому гигабиту, не учитывает такую динамику.

На время испытаний заблокируйте настоящие побочные действия тестовой копии. Она не должна отправлять клиентам письма, списывать платежи, выполнять рабочие вебхуки или конкурировать со старой системой за задания. Используйте предусмотренные тестовые режимы интеграций и отдельные права.

Результат репетиции — исполнимый порядок действий с условиями продолжения. Например, подтверждено наличие копии, пройдена проверка данных, целевой узел выдерживает нагрузку, все внешние зависимости доступны. Формулировка «администратор смотрит, всё ли нормально» слишком мало помогает тому же администратору в напряжённый момент.

Заранее определите предел времени, после которого переключение откладывают, если новая сторона ещё не принимала рабочую запись. Назначьте человека, принимающего решение, и сохраните доступы к обеим площадкам. Подробности подготовки возврата разобраны в статье «План отката миграции».

DNS помогает переключить вход, но не управляет данными

Если переезд предполагает смену DNS-записи, TTL уменьшают заранее с учётом её прежнего времени кэширования. Само изменение TTL не удаляет уже сохранённые ответы из всех кэшей. Значение определяет срок хранения DNS-данных; практические особенности описаны в документации Cloudflare о TTL.

Также существуют активные соединения, локальные настройки, интеграции с жёстко указанным IP и промежуточные прокси. Поэтому переключение записи не является мгновенной общей командой всем клиентам. Часть обращений ещё может приходить на старый адрес.

Для этого периода нужна определённая судьба старой точки входа: она либо безопасно направляет запросы к единственному новому владельцу записи, либо не принимает изменения и сообщает о техническом окне. Две независимо пишущие копии приложения с разошедшимися базами — плохой способ переждать DNS-кэши.

Проверьте сертификаты, доменные имена, доверенные прокси, списки разрешённых адресов у партнёров и исходящие соединения. После переноса приложение обращается наружу с другого адреса; иногда именно это ломает интеграцию, хотя DNS и новая база настроены правильно.

Рабочее переключение: от последней старой записи к первой новой

Точная процедура зависит от стека, но порядок ответственности можно описать последовательно.

1. Ограничьте появление новых изменений на исходной стороне. Включите согласованный режим приложения, остановите фоновые задания и другие источники записи. Дождитесь завершения или корректно обработайте операции, которые уже выполняются.
2. Доведите данные до контрольной точки. Передайте оставшиеся файлы, подтвердите получение и применение последних изменений базы. Проверяйте конкретное положение репликации и состояние компонентов, а не только отсутствие заметной задержки на графике.
3. Зафиксируйте, кто имеет право записывать. Старую сторону исключите из записи, новую сделайте единственным рабочим источником. Механизм должен учитывать повторный запуск старого сервиса после перезагрузки.
4. Переключите вход и проверьте ключевые операции. Выполните безопасные контрольные сценарии чтения и записи, проверьте происхождение ответа, интеграции и сохранность результата.
5. Запустите фоновые процессы в одном месте. Верните очереди, расписания, обмены и остальные обязанности так, чтобы две площадки не выполняли одну работу одновременно.

Для PostgreSQL порядок работы standby и перехода к записи описан в руководстве по резервным серверам. Само повышение реплики до primary не отключает старый primary и не решает всю задачу переключения приложения. Исключение одновременной независимой записи остаётся частью вашего плана.

Очереди проверяют особенно внимательно. Незавершённое задание может быть доставлено повторно. Приложение должно уметь распознать уже выполненное действие или безопасно обработать повтор; иначе одна операция переезда превратится в несколько писем или платежных попыток. Такие свойства проверяют до окна, а не добавляют в процессе ночного переключения.

После первой новой записи возврат становится другой операцией

До начала рабочей записи на целевой стороне часто возможно вернуться к исходной системе, если её состояние сохранено и новые изменения не появились. После начала записи на dedicated нужно решить, как вернуть эти изменения обратно. Простая смена DNS в обратную сторону не переносит данные.

План может предусматривать обратную репликацию, проверенную выгрузку накопившихся изменений либо устранение проблемы на новой стороне с сохранением её главным источником. Возможность каждого варианта зависит от версии, схемы и характера данных. Если обратная совместимость не предусмотрена, обещание мгновенного отката будет неверным.

Поэтому во время миграции по возможности не совмещают переезд железа с крупным изменением схемы базы, версии приложения и правил обработки. Чем больше изменений произошло одновременно, тем сложнее понять причину сбоя и восстановить согласованное состояние.

Старые VPS после переключения не удаляют немедленно. Их сохраняют на согласованный период как часть плана восстановления, с запрещённой самостоятельной рабочей записью и ограниченным доступом. Срок определяется наблюдением за системой, требованиями к данным и стоимостью переходного периода — универсального числа дней здесь нет.

Но само сохранение старых дисков ещё не означает наличия рабочего возврата. Нужно знать, какие данные на них устарели, каким способом они будут доведены до нужного состояния и кто вправе запустить процедуру. Подпись «backup-old-final» этих сведений не заменяет.

Что проверить до отключения последних VPS

Проверки продолжаются после того, как новая главная страница впервые открылась. Нужны чтение и запись, загрузка файлов, авторизация, поиск, фоновые задания, уведомления и внешние обмены. Отдельно сверяют ключевые сущности и результаты операций, учитывая, что рабочая система продолжает изменяться.

Сравните время ответа и ресурсы с исходной площадкой. На одном хосте ночной бэкап, индексация и массовая обработка могут впервые встретиться одновременно. Первый обычный рабочий цикл иногда рассказывает о новой машине больше, чем короткий нагрузочный прогон.

Убедитесь, что резервные копии создаются уже из правильного источника и восстанавливаются в отдельную проверочную среду. Обновите мониторинг, документацию, адреса в автоматизации и учёт секретов. Временные доступы, выданные для переноса, после завершения отзывают.

Подробная проверка результата рассмотрена в статье «Как проверить, что миграция прошла успешно». Старые ресурсы выводят из эксплуатации только после выполнения заранее согласованных критериев и сохранения нужных материалов по принятому регламенту.

Минимальный простой получается из большого объёма работы до переключения: предварительных копий, репетиции, понятного владельца записи и проверенного возврата. В удачно подготовленном переезде самый напряжённый этап оказывается коротким и довольно скучным. Для инфраструктуры это отличный литературный финал: все события на месте, ни один заказ не потерялся между главами.

Все материалы о выделенных серверах