Сначала подготовьте и протестируйте новый сервер, скопируйте данные с помощью поддерживаемого приложением метода обеспечения согласованности, определите окно переключения и сохраните старое окружение. Откат должен учитывать записи, принятые на новом сервере, а не только изменение DNS.
Проведите инвентаризацию сервиса перед переносом машины
Миграция включает не только файлы приложения. Перечислите базы данных, загрузки, запланированные задачи, обработчики очередей, сертификаты, домены, секреты и исходящие интеграции. Запишите версии программного обеспечения и важные рабочие допущения, такие как права на файлы и пути хранения. Новый выделенный сервер может выявить забытую зависимость, которая годы назад была незаметно установлена в старом окружении.
Назначьте ответственного за решение о переключении и определите, что считается успехом. Включите проверки, видимые пользователю, согласованность данных и возможность восстановить доступ. Убедитесь, что новая конфигурация предоставлена и работоспособна, прежде чем объявлять дату миграции. Подтверждение заказа или указанная спецификация оборудования — это не то же самое, что работающее целевое окружение, готовое принимать производственные данные.
Создайте целевое окружение как отдельную среду
Установите необходимый стек, настройте администрирование и сконфигурируйте предполагаемый межсетевой экран. Храните секреты приватно и осознанно задавайте права сервисов. Проверьте ожидаемое поведение имени хоста и сертификата приложения до переключения публичного трафика. Документация Apache о виртуальных хостах показывает, почему маршрутизация по имени хоста — это отдельное конфигурационное решение, отличное от адреса сервера. Работающая страница по умолчанию не доказывает, что настроен правильный хост приложения.
Используйте репрезентативный восстановленный набор данных для репетиции, отключив или перенаправив исходящую электронную почту, платежи и запланированные задачи в безопасные тестовые системы. Это не позволит тестовому окружению воздействовать на реальных пользователей. Проверьте вход, загрузки, фоновую работу и восстановление. Запишите процедуру и её длительность, чтобы реальное окно основывалось на наблюдаемом процессе, а не на оптимизме.
Выберите согласованную границу данных
Используйте метод резервного копирования или репликации, поддерживаемый базой данных и приложением. PostgreSQL различает SQL-дампы, резервные копии файловой системы и непрерывное архивирование, каждый из которых имеет свои допущения. В его руководстве по дампам отмечается, что дампы базы данных могут быть внутренне согласованными, тогда как роли кластера и другие детали требуют отдельной обработки. Изучите требования именно для вашей системы, а не копируйте открытые файлы данных без разбора.
Спланируйте, как база данных связана с загрузками и состоянием очереди. Если запись указывает на файл, скопированный в другое время, восстановленное приложение может быть неполным, даже если обе копии по отдельности успешны. Решите, следует ли ненадолго приостановить запись, использовать протестированную схему репликации или выполнить экспорт, специфичный для приложения. Явно зафиксируйте это решение о согласованности в руководстве.
| Этап | Требуемое доказательство | Решение |
|---|---|---|
| Репетиция | Приложение и восстановленные данные проходят проверки | Целевое окружение можно рассматривать для переключения |
| Финальная синхронизация | Определённая согласованная точка восстановления | Продолжать только с понятными оставшимися изменениями |
| Переключение трафика | Правильная маршрутизация и поведение сертификата | Наблюдать за обоими окружениями |
| Откат | Расположение всех новых принятых записей | Сверить данные перед возвратом трафика |
Подготовьте маршрутизацию трафика без обещаний мгновенных изменений
DNS time-to-live управляет тем, как долго записи могут кэшироваться, как объясняется в документации Cloudflare по DNS. Проверьте TTL заранее, если DNS является частью миграции, и дайте существующим кэшированным записям устареть согласно их предыдущей настройке. Изменение значения в момент переключения не может задним числом сократить срок жизни каждого кэшированного ответа. В ходе перехода разные клиенты могут попадать в разные целевые окружения.
Сохраняйте старое окружение доступным, пока изменения маршрутизации не стабилизируются, с осознанной политикой в отношении того, может ли оно по-прежнему принимать записи. Избегайте запуска дублирующих потребителей очередей или запланированных задач, если приложение не рассчитано на это. Наблюдайте за запросами с обеих сторон и подтвердите предполагаемое имя хоста, сертификат TLS и версию приложения с независимых клиентов.
Определите откат после начала записи
Пока новая система не начнёт принимать изменения, возврат трафика может быть относительно простым. После этого один только откат DNS способен привести к потере работы или создать две конфликтующие истории. Определите, как будут сохраняться или согласовываться новые записи и загрузки. Если приложение не может безопасно их объединить, контролируемый период обслуживания может быть предпочтительнее импровизированного возврата к старой копии.
Задайте условия, требующие приостановки миграции, и обеспечьте доступность ответственного за решение. Сохраняйте журналы и полезные доказательства в соответствии с правилами хранения проекта. Не удаляйте старую машину или её независимую резервную копию только потому, что главная страница один раз загрузилась. Срок хранения должен покрывать согласованные потребности в проверке и откате.
Завершите миграцию операционными проверками
После переключения проверьте резервные копии, оповещения, продление сертификатов, запланированные задачи и восстановление доступа. Убедитесь, что отслеживаемый хост является новым назначением и что в продакшене не осталось тестовых интеграций. Проверьте ошибки приложения и видимое пользователям время отклика при обычном трафике. Обновите инвентаризацию и runbook, чтобы следующему администратору не пришлось догадываться, что изменилось.
Специализированные семейства SwissOctet предлагают разные физические конфигурации, но работы по миграции и управляемую помощь необходимо подтвердить для выбранной услуги. Используйте каталог, чтобы выбрать подходящие ресурсы, а затем постройте протестированный перенос с учётом данных вашего приложения. Миграция завершена, когда услуга и процесс её восстановления работают на целевом окружении, а не просто когда файлы были перенесены.
Ваш практический чек-лист.
- Проведите инвентаризацию данных, задач, секретов и интеграций.
- Проверьте предоставленное целевое окружение перед планированием.
- Проведите репетицию с безопасными внешними интеграциями.
- Определите согласованность базы данных и загрузок.
- Спланируйте переход маршрутизации и предотвращение дублирования задач.
- Определите откат для новых записей.
- Проверьте резервные копии и мониторинг после переключения.
Детали, которые важны.
Можно ли выполнить миграцию, скопировав каталог приложения?+
Только если это охватывает всё, что нужно сервису, и сохраняет согласованность. Базы данных, загрузки, задачи, секреты и конфигурация обычно требуют отдельного внимания.
Делает ли снижение TTL DNS переключение мгновенным?+
Нет. Ранее закэшированные ответы могут сохраняться до истечения их прежнего срока жизни, а клиенты могут обновляться в разное время.
Откат — это просто указание DNS на старый сервер?+
Нет, после того как новый сервер начал принимать записи. Прежде чем возвращать трафик, вы должны учесть эти записи и файлы.
Перейдите к источнику.
Эти источники поддерживают технические концепции в этом руководстве. Следуйте актуальной документации, прежде чем менять производственную систему.
- PostgreSQL: Резервное копирование и восстановление www.postgresql.org
- PostgreSQL: согласованность и восстановление дампа SQL www.postgresql.org
- Apache: документация по виртуальным хостам httpd.apache.org
- Cloudflare DNS: время жизни developers.cloudflare.com
Редакционное руководство от SwissOctet. Примеры иллюстративны. Спецификации услуг, доступные опции и договорные условия необходимо проверять отдельно.