В нестабильное время риск недоступности дата-центров становится особенно значимым: сбои электроснабжения и связи, аварии и внешние воздействия могут вывести из строя отдельную площадку. Поэтому запасной вариант миграции стоит готовить до инцидента: выбрать альтернативное облако, сохранить независимые резервные копии и проверить восстановление проекта. Если ЦОД уже недоступен, обычный перенос с работающего источника может оказаться невозможным.
Миграцию работающего проекта стоит проектировать вокруг двух ограничений: сколько изменений бизнес готов потерять и сколько времени он допускает недоступность записи. От этих величин зависит способ переноса базы, длительность параллельной работы и бюджет. Выбор провайдера по цене виртуальной машины имеет смысл только после этого.
Ниже — порядок переезда из Yandex Cloud для проектов на виртуальных машинах и контейнерах. Основной сценарий: приложение, PostgreSQL и пользовательские файлы; перенос с короткой остановкой записи. Для больших баз и сервисов, тесно связанных с платформой Яндекса, способ переноса нужно адаптировать.
Приведённые цены — ориентиры для расчёта, а не фиксированное предложение. Перед миграцией сверяйте ставки, налоги и состав услуг по ссылкам на тарифы. Без состава ресурсов и фактического счёта проекта достоверную цену переезда назвать нельзя.
1. Начните с границы миграции, а не с заказа сервера
Сначала определите, какие зависимости от Яндекса нужно устранить. Простого списка виртуальных машин недостаточно. Проверьте исходящие обращения приложения, задания по расписанию, очередь фоновых задач, хранилища секретов, реестры контейнеров и систему выпуска релизов.
| Зависимость в Яндексе | Решение до начала переноса |
|---|---|
| Managed PostgreSQL или MySQL | Целевая версия, расширения, права, способ синхронизации |
| Object Storage и CDN | Перенос объектов, адреса файлов, подписи ссылок, очистка кэша |
| Lockbox, IAM, сервисные аккаунты | Новая схема выдачи секретов и прав |
| Container Registry | Копирование образов и изменение процесса выпуска |
| Message Queue и фоновые обработчики | Порядок остановки, перенос или доработка очереди |
| Cloud Functions, API Gateway | Замена интеграции, повторное развёртывание или переработка |
| Cloud DNS, сертификаты, балансировщики | Адреса назначения и порядок переключения |
| Логи и мониторинг | Сохранение наблюдаемости во время и после переезда |
2. Выберите целевую архитектуру до сравнения цен
Для небольшого проекта допустим перенос приложения и базы на одну виртуальную машину или VDS сервер. Но если сейчас база обслуживается провайдером, такая схема передаёт вашей команде обновления, резервное копирование и восстановление. Снижение облачного счёта нельзя считать экономией, пока не оценена эта работа.
- Перенос приложения на заново собранное окружение. Удобен, когда есть исходный код, инструкции запуска и воспроизводимая сборка. Позволяет убрать накопленные изменения сервера.
- Перенос образа виртуальной машины. Полезен для сложного устаревшего окружения, но требует проверки формата диска, загрузки, драйверов и сетевых настроек у получателя.
- Развёртывание контейнеров. Подходит, когда приложение уже упаковано. Переносятся также постоянные данные, настройки, секреты и внешние зависимости.
3. Куда переносить: сравнивайте законченные конфигурации
Для российского проекта в короткий список можно включить Selectel, Cloud.ru, VK Cloud и Timeweb Cloud. Проверять нужно конкретный продукт и регион, а не бренд целиком: характеристики процессоров, дисков и доступность управляемых сервисов отличаются даже внутри одной платформы.
| Площадка | Когда включать в короткий список | Что проверить на пилоте |
|---|---|---|
| Selectel | Нужны виртуальные машины, управляемые базы и возможность развивать инфраструктуру | Производительность дисков, подходящая линейка CPU, размещение сервисов |
| Cloud.ru Evolution | Планируется собрать инфраструктуру из отдельных облачных ресурсов | Тип машины, гарантированная доля CPU, сети, диски и отдельные платные ресурсы |
| VK Cloud | Проект требует набора управляемых сервисов или уже связан с экосистемой VK | Соответствие нужных функций, квоты и подтверждённая смета |
| Timeweb Cloud | Проект переносится на виртуальные машины с понятной конфигурацией | Конкретная линейка сервера, регион, IP, резервные копии и сеть |
Перечни продуктов проверяются на официальных страницах Selectel, Cloud.ru, VK Cloud и Timeweb Cloud.
В запросе поставщику укажите требуемые ресурсы, объём данных, месячный трафик, режим резервирования и допустимое время восстановления. Попросите перечислить исключения из цены: публичные адреса, диски, снимки, балансировщик, резервные копии и платную поддержку.
AWS, Google Cloud и Azure имеют смысл рассматривать после проверки обслуживания вашего юридического лица, оплаты и доступности из сетей пользователей. В частности, AWS опубликовал прекращение новых регистраций клиентов из России и Беларуси. Нельзя включать его в смету как гарантированно доступный вариант нового размещения. Сообщение Amazon.
4. Сколько будет стоить новое размещение
Сравнивайте месячный счёт в одинаковом режиме работы:
вычисления + диски + база + сеть + адреса + резервные копии + вспомогательные сервисы + сопровождение.
Подтверждённые ценовые ориентиры
В качестве примера расчёта по опубликованным ставкам Cloud.ru Evolution Compute возьмём машину 2 vCPU / 4 ГБ RAM по цене 2,9707 ₽ в час с НДС 22%, или 2 138,90 ₽ за 720 часов (30 дней). Публичный IP — 0,2074 ₽ в час, или 149,33 ₽. Получается 2 288,23 ₽ до оплаты диска, копий и прочих ресурсов. Это ставка обычной машины из тарифа, а не более дешёвой конфигурации с ограниченной гарантированной долей CPU. Тариф Cloud.ru.
Другой ценовой ориентир — опубликованное предложение Timeweb Cloud для Москвы, MSK Ultra 50: 2 CPU, 4 ГБ RAM и 50 ГБ NVMe — 5 480 ₽ в месяц. Это другая линейка CPU, а диск включён: напрямую сравнивать её с ценой машины Cloud.ru нельзя. НДС и доплаты следует подтвердить в итоговом заказе. Тариф Timeweb.
Модель полной сметы
Следующая таблица — пример планирования, а не тариф конкретного поставщика. Все суммы условно считаются окончательными рублёвыми расходами заказчика за месяц; если поставщик выставляет цены без НДС, налог добавляют до сравнения.
| Статья расходов | Небольшой сайт | Магазин | Сервис с резервированием |
|---|---|---|---|
| Серверы приложения | 2 500 | 5 000 | 10 000 |
| База данных | На том же сервере | 6 000 | 15 000 |
| Диски и резервные копии | 1 000 | 2 500 | 5 000 |
| Сеть, адреса, балансировщик, мониторинг | 500 | 2 500 | 5 000 |
| Инфраструктура в месяц | 4 000 | 16 000 | 35 000 |
5. Отдельно посчитайте бюджет миграции
Разовые расходы включают подготовку окружения, передачу данных, репетицию, переключение, проверку и период сохранения старой площадки. Бесплатная помощь провайдера не обязательно покрывает доработку приложения и ответственность за согласованность данных — объём работ следует зафиксировать.
Пример для магазина, без привязки к рыночной ставке специалиста:
| Работа или ресурс | Модельная сумма |
|---|---|
| Подготовка и репетиция: 16 часов × 2 000 ₽ | 32 000 ₽ |
| Переключение и наблюдение: 8 часов × 2 000 ₽ | 16 000 ₽ |
| Семь дней нового размещения до запуска: 16 000 × 7 / 30 | 3 733 ₽ |
| Семь дней старого после запуска: 24 000 × 7 / 30 | 5 600 ₽ |
| Резерв на передачу данных и временные ресурсы | 2 000 ₽ |
| Всего | 59 333 ₽ |
Здесь ставка и трудозатраты — допущения для демонстрации расчёта. Последняя строка расходов является резервом, который нужно заменить расчётом трафика и ресурсов. Это не предложение выполнить любую миграцию за указанную сумму.
При экономии 8 000 ₽ в месяц такой бюджет окупается примерно за 7,4 месяца. Если дополнительно потребуется 5 000 ₽ ежемесячного сопровождения, экономия уменьшится до 3 000 ₽, а окупаемость вырастет почти до 20 месяцев.
Выгрузку с виртуальных машин считайте по правилам Yandex VPC; выгрузку из Object Storage — по правилам этого хранилища. Не переносите ставки одного сервиса на другой. Учитывайте уже использованные бесплатные объёмы, повторные передачи и дополнительные сетевые узлы. Тарификация VPC.
6. Подготовьте площадку и проведите репетицию
Снимите показатели текущего проекта за обычный период и за пики: загрузку CPU, память, задержки базы, скорость диска, размер данных и число запросов. Равное число виртуальных ядер не гарантирует равную производительность.
Создайте целевое окружение с совместимыми версиями. Настройте закрытую связь с базой, доступ администратора, резервное копирование и сбор журналов. Выдайте новые ключи; не переносите в новое облако права сервисных аккаунтов Яндекса как будто они универсальны.
Разверните приложение из проверенной сборки. Конфигурацию подключения к базе, хранилищу и внешним сервисам изменяйте отдельно от исходного кода. Фоновые обработчики, отправку сообщений, расписания и реальные платежи на тестовой копии отключите.
Затем восстановите копию базы и файлов. Репетиция должна ответить на три вопроса: восстанавливаются ли данные, работает ли приложение и сколько времени занимает финальная последовательность. Успешное создание архива не подтверждает возможность восстановления.
Пока идёт репетиция, подготовьте DNS. Уменьшите время кэширования нужных записей заранее и дождитесь истечения их прежнего значения. Изменение на пять минут непосредственно перед переездом не заставит существующие кэши забыть адрес, который они сохранили на сутки.
7. Перенесите приложение, файлы и базу
Сначала переносится основная масса данных, пока старый проект продолжает работать. Финальные изменения передаются в согласованное окно.
Код приложения лучше разворачивать из репозитория или подготовленного артефакта. Для пользовательских файлов на Linux подходит rsync. Пример выполняется со старого сервера; пути, пользователь и адрес — заменяемые значения:
rsync -an --itemize-changes /srv/project/uploads/ deploy@NEW_HOST:/srv/project/uploads/
rsync -a --info=progress2 /srv/project/uploads/ deploy@NEW_HOST:/srv/project/uploads/Первая команда показывает изменения, вторая выполняет передачу. Завершающая косая черта у исходного каталога означает копирование его содержимого. Пользователю назначения нужны права записи; права владельцев файлов после передачи необходимо проверить.
Базу нельзя переносить обычным копированием её рабочего каталога. Для базового сценария PostgreSQL используйте логическую выгрузку и восстановление. Пример для администратора по документации PostgreSQL:
pg_dump -h OLD_DB -U migration -W -Fc -f project.dump project
createdb -h NEW_DB -U db_admin -W -T template0 -O app_user project_migration
pg_restore -h NEW_DB -U app_user -W --no-owner --no-acl --exit-on-error -d project_migration project.dumpКоманды выполняются с машины, имеющей разрешённый доступ к обеим базам. Пароли вводятся по запросу. Целевая роль app_user должна быть создана заранее, а база project_migration — отсутствовать до команды createdb. При повторной репетиции используйте новую пустую базу.
Если восстановление базы занимает больше допустимого окна, полная финальная выгрузка не подходит. Нужна предварительная загрузка и непрерывная передача изменений — репликация. Её совместимость, права и ограничения управляемой базы проверяются на пилоте, включая смену схемы и последовательности идентификаторов.
8. Проверьте проект до публичного переключения
Тестировать нужно под настоящим доменным именем, направляя только тестовый клиент на новый адрес. Открытие сайта по IP не проверяет сертификат, маршрутизацию по домену, cookie и перенаправления.
Для единичной HTTPS-проверки:
curl --resolve example.ru:443:NEW_IP https://example.ru/ -IПодставьте домен и реальный адрес. Команда не меняет публичный DNS и проверяет сертификат штатным способом. Для полного тестирования в браузере используйте локальное переопределение адреса на тестовой машине.
Приёмочный набор должен включать авторизацию, поиск, оформление заказа, загрузку файла, отправку письма, работу API и административные операции. Для магазина отдельно проверьте уведомления платёжной системы, изменение статуса заказа и обмен с учётной системой.
Подготовьте сертификат до смены DNS. Если автоматический выпуск зависит от публичной доступности, заранее выберите поддерживаемый способ подтверждения домена или перенесите действующий сертификат, если это допускается его хранением и правилами проекта.
9. Выполните переключение с единственным источником записи
Для базового сценария с короткой остановкой порядок следующий:
- Зафиксируйте начало работ и прекратите выпуск релизов.
- Закройте пользовательскую запись на старой площадке.
- Остановите расписания и фоновые обработчики, дождитесь завершения активных операций.
- Создайте финальную выгрузку базы и передайте последние файловые изменения.
- Восстановите базу в подготовленное пустое назначение и проверьте контрольные показатели.
- Направьте новое приложение на финальную базу и выполните проверки.
- Переключите входящий трафик и разрешите запись только на новой площадке.
- Включайте фоновые задачи и внешние интеграции по согласованному списку.
Режим обслуживания сам по себе не гарантирует остановку записи. В базу могут продолжать писать API, обработчики очереди и входящие уведомления. Для платежей и других внешних событий определите, какие отправители повторяют доставку, где сохраняются события и как будет выполнена сверка.
DNS не переключает всех пользователей одновременно. Часть запросов продолжит приходить на старый IP. Старый сервер должен либо безопасно направлять их на новую площадку, либо оставаться без записи с понятным ответом. Продолжать принимать заказы в старую базу нельзя.
Обновите не только A-записи, но и используемые AAAA-записи, поддомены API, административные адреса и настройки CDN. Забытый IPv6 может оставить часть аудитории на старом сервере.
План отката
До появления новых записей на целевой площадке возврат обычно сводится к восстановлению маршрута на старое окружение. После первого нового заказа две базы уже различаются.
Поэтому план отката должен содержать не только старый IP, но и порядок сохранения новых данных. При проблеме остановите запись, выгрузите изменения новой площадки, согласуйте их с исходной базой и только затем возвращайте приложение. Возможность обратного восстановления между версиями нужно проверить заранее.
В период наблюдения следите за ошибками приложения, ответами сервера, задержками базы, фоновыми заданиями и бизнес-показателями. Нормальная загрузка CPU не доказывает, что заказы проходят. Сравнивайте показатели с исходной площадкой при сопоставимой нагрузке.
Удаление виртуальных машин не гарантирует прекращения всех начислений. Проверьте оставшиеся диски, снимки, IP, базы, хранилища, журналы и платные сервисы. Удалять их следует после окончания срока возврата и проверки независимых резервных копий.
Миграция завершена, когда проект работает на новой площадке, данные согласованы, восстановление проверено и зависимости от Яндекса, входившие в границы работ, устранены. Первый практический шаг — собрать перечень зависимостей и счёт за полный месяц, затем заказать пилот одной и той же конфигурации у двух подходящих провайдеров.
Добавить комментарий