Миграция серверов - это процесс переноса операционных систем, приложений и данных с одной физической или виртуальной платформы на другую. Главная цель - перевезти всю инфраструктуру с минимальным временем недоступности сервисов или вовсе без него. В этой статье вы получите проверенный алгоритм: от инвентаризации и построения карты зависимостей до выбора стратегии (P2V, V2V, V2P) и финальной проверки работоспособности.
Риски при миграции возникают из-за забытых cron-скриптов, хардкода IP-адресов в конфигах или неучтенных внешних API. Пошаговый план, описанный ниже, построен так, чтобы выявить эти скрытые связи до старта работ. Вы узнаете, как синхронизировать данные через rsync, переключить трафик через балансировщик и подготовить план отката, если что-то пойдет не так.
План миграции: с чего начать
Предварительное планирование определяет, пройдет ли миграция за одно окно обслуживания или растянется на несколько дней аварийных восстановлений. Начните с трех этапов: инвентаризация оборудования и ПО, составление карты зависимостей, оценка текущих нагрузок и ресурсов. Без этой базы вы рискуете пропустить критичный компонент, например, старый сервер с единственным экземпляром внутреннего DNS, который держит на себе всю локальную сеть.
Для оценки нагрузок соберите метрики за последние 2-4 недели: утилизацию CPU, потребление RAM, IOPS дисковой подсистемы и сетевой трафик. Эти цифры станут ориентиром для выбора целевой платформы. Если вы переносите высоконагруженную базу данных, которая упирается в 10 000 IOPS, а целевое хранилище выдает только 2 000, миграция провалится на этапе тестирования производительности.
Инвентаризация: что и куда переносим
Полный аудит текущей инфраструктуры фиксирует каждый компонент, подлежащий переносу. Составьте таблицу со следующими столбцами: имя хоста, IP-адрес, тип (физический/виртуальный/контейнер), операционная система и версия ядра, список ключевых сервисов, объем данных на дисках, наличие резервных копий и ответственный за сервис.
Для сбора информации используйте команды на исходных машинах. Список физических устройств и характеристик железа: lshw -short или dmidecode -t system. Перечень запущенных контейнеров: docker ps --format 'table {{.Names}} {{.Image}} {{.Status}}'. Активные виртуальные машины на KVM-хосте: virsh list --all. Не забудьте зафиксировать сетевые настройки: IP-адреса, маски, шлюзы, маршруты (ip addr show; ip route show), содержимое /etc/resolv.conf для DNS, активные SSL-сертификаты и даты их истечения (openssl x509 -in /path/to/cert.pem -noout -enddate).
Отдельная строка инвентаризации - базы данных и файловые хранилища. Для каждой БД зафиксируйте: тип (MySQL, PostgreSQL, MongoDB), версию, размер данных на диске, метод репликации (если есть) и расписание бэкапов. Файловые хранилища опишите в формате: путь монтирования, файловая система, объем занятого места (df -hT), способ синхронизации (NFS, rsync, объектное хранилище).
Карта зависимостей: как не разорвать связи
Карта зависимостей - это схема, показывающая, какой сервис с кем взаимодействует и через какие протоколы. Стройте ее от внешнего запроса пользователя вглубь инфраструктуры. Например: пользователь → балансировщик (IP .10, порт 443) → веб-сервер Nginx (IP .20) → PHP-FPM (IP .20, порт 9000) → PostgreSQL (IP .30, порт 5432). Каждая стрелка на схеме - потенциальная точка разрыва при смене IP-адреса или сетевой конфигурации.
Для выявления связей используйте комбинацию инструментов и ручного аудита. Команда ss -tulpn покажет все слушающие порты и процессы на каждом сервере. nmap -sT -p- просканирует открытые порты целевой машины извне. Главная опасность - скрытые зависимости: хардкод IP-адресов в коде приложений, в конфигурационных файлах или в переменных окружения. Проверьте все конфиги в /etc на предмет прямых IP вместо DNS-имен командой grep -rEo '([0-9]{1,3}\.){3}[0-9]{1,3}' /etc/. Не пропустите внешние API, привязанные к вашему исходящему IP в белых списках (whitelist) на стороне провайдера - смена адреса оборвет интеграцию.
Особый случай - фоновые задачи. Проверьте crontab всех пользователей (for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done) и системные таймеры systemd (systemctl list-timers --all). Забытый скрипт очистки логов, который обращается к базе данных по старому IP, может всплыть через неделю после миграции.
Выбор стратегии миграции: P2V, V2V, V2P
Стратегия миграции определяется исходной и целевой платформами. Три базовых направления: Physical-to-Virtual (P2V) - конвертация физического сервера в виртуальную машину, Virtual-to-Virtual (V2V) - перенос между гипервизорами, Virtual-to-Physical (V2P) - развертывание виртуальной машины на физическое железо. Каждая стратегия решает свою задачу и требует специфических инструментов.
Выбор стратегии зависит от целей. P2V применяют для консолидации стареющего парка железа и освобождения места в дата-центре. V2V - при смене вендора виртуализации, например, переход с VMware на Proxmox или KVM. V2P - редкий сценарий для высоконагруженных систем, которым нужно исключить накладные расходы гипервизора и получить прямой доступ к оборудованию.
P2V: перенос физических серверов в виртуальную среду
P2V - самая востребованная стратегия при модернизации инфраструктуры. Процесс состоит из трех шагов: подготовка исходного сервера, создание образа диска, развертывание образа на гипервизоре с последующей адаптацией загрузчика и драйверов.
Подготовка исходного сервера начинается с остановки некритичных служб, чтобы минимизировать изменения данных во время создания образа. Остановите сервисы, которые активно пишут на диск: базы данных, почтовые серверы, логи агрегаторов. Если полная остановка невозможна, переведите базу данных в режим read-only или сделайте дамп отдельно. Удалите временные файлы и старые логи для уменьшения размера образа: apt clean; journalctl --vacuum-size=100M; find /var/log -type f -name '*.log' -mtime +30 -delete.
Для создания образа используйте специализированные инструменты. VMware vCenter Converter Standalone подходит для целевой платформы vSphere: он устанавливается как агент на исходную машину и передает образ напрямую на ESXi-хост. Для открытых гипервизоров (KVM, Proxmox) работает Clonezilla: загрузитесь с Live-образа Clonezilla на физическом сервере, создайте образ диска на внешнем носителе или сетевом хранилище, затем восстановите его на виртуальную машину. Альтернативный метод - создание сырого образа через dd и конвертация: dd if=/dev/sda of=/mnt/backup/server.img bs=4M status=progress с последующим qemu-img convert -f raw -O qcow2 server.img server.qcow2.
После развертывания образа на гипервизоре основная проблема - несовместимость драйверов. Физический сервер использует драйверы для конкретного RAID-контроллера или сетевой карты, которых нет в виртуальной среде. Перед конвертацией установите в исходную ОС пакеты для виртуальных устройств: для Linux - apt install linux-image-virtual или yum install kernel с поддержкой virtio, для Windows - драйверы VirtIO. После загрузки виртуальной машины проверьте, что все диски и сетевые интерфейсы определились корректно (lsblk; ip link show).
V2V и V2P: когда это нужно
V2V-миграция требуется при смене гипервизора. Типичный сценарий: уход от проприетарного VMware к открытому KVM или Proxmox. Самый простой метод - экспорт виртуальной машины в формат OVF (Open Virtualization Format) на исходном гипервизоре и импорт на целевом. Команда qemu-img convert преобразует формат дисков: qemu-img convert -f vmdk source.vmdk -O qcow2 target.qcow2. Для миграции между KVM-хостами используйте virsh migrate --live при наличии общего хранилища или virsh dumpxml с копированием дисков через rsync.
V2P применяют редко, когда виртуализация создает неприемлемые накладные расходы для высоконагруженных систем. Например, база данных с 50 000 транзакций в секунду может требовать прямого доступа к NVMe-дискам без прослойки гипервизора. Процесс обратный P2V: создайте образ виртуального диска, запишите его на физический носитель через dd, затем загрузитесь с Live-системы и восстановите загрузчик через grub-install. Главный риск V2P - несовместимость драйверов: виртуальная машина ожидает устройства VirtIO, а физическое железо требует родных драйверов. Перед миграцией установите соответствующие пакеты ядра и модули.
Для всех стратегий критичен вопрос лицензирования. Перенос Windows-сервера на новое железо или гипервизор может потребовать повторной активации. Проверьте тип лицензии (OEM, Volume, Retail) до миграции: OEM-лицензия привязана к конкретному оборудованию и может не активироваться на виртуальной машине.
Выполнение миграции с минимальным простоем
Миграция с минимальным downtime строится на принципе «синхронизировать, затем переключить». Вы поднимаете целевую инфраструктуру параллельно с работающей исходной, синхронизируете данные, тестируете все на целевой стороне и только потом перенаправляете трафик. Этот подход сокращает окно недоступности до времени переключения DNS или балансировщика - обычно от нескольких секунд до пары минут.
Если параллельная работа невозможна (нет ресурсов или лицензий), планируйте окно обслуживания. Заранее согласуйте время с бизнесом, подготовьте все скрипты и протестируйте их на стенде. Типичное окно для небольшой инфраструктуры из 5-10 серверов - 4-6 часов ночью или в выходной день. Пошаговое руководство по планированию миграции инфраструктуры содержит готовый чек-лист для оценки рисков и расчета допустимого времени простоя.
Синхронизация данных и переключение трафика
Первый проход синхронизации выполняйте на работающей системе. Для файлов используйте rsync: rsync -avz --progress --exclude='/proc/*' --exclude='/sys/*' --exclude='/dev/*' / source-server:/mnt/target/. Флаг -a сохраняет права и временные метки, -z сжимает данные при передаче. После первого прохода, который может занять часы для больших объемов, выполните второй и третий проходы - они завершатся быстро, так как rsync копирует только изменившиеся файлы.
Для баз данных стратегия зависит от СУБД. PostgreSQL поддерживает потоковую репликацию: настройте реплику на целевом сервере, дождитесь полной синхронизации, затем выполните switchover - повысьте реплику до мастера. MySQL/MariaDB используйте утилиту mysqldump с флагом --single-transaction для InnoDB-таблиц или mydumper для параллельного дампа больших баз. MongoDB предоставляет встроенную репликацию через replica set: добавьте целевой узел в набор, дождитесь синхронизации, исключите исходный узел.
Переключение трафика - финальный аккорд. Если используется балансировщик (Nginx, HAProxy), измените upstream на целевые серверы и перезагрузите конфигурацию: nginx -s reload. Если трафик идет через DNS, заранее уменьшите TTL записей до 60-300 секунд (за 24 часа до миграции), чтобы изменение A-записи распространилось быстро. После смены IP в DNS проверьте разрешение: dig +short your-domain.com. Старые соединения могут висеть еще несколько минут - не выключайте исходные серверы сразу, дайте трафику плавно перетечь.
План отката: что делать, если что-то пошло не так
План отката - это документированная процедура возврата к исходной инфраструктуре за минимальное время. Он должен быть написан до начала миграции и проверен на тестовом окружении. Ключевой принцип: исходные серверы не уничтожаются и не модифицируются до подтверждения стабильной работы целевой инфраструктуры в течение оговоренного периода (обычно 24-72 часа).
Чек-лист плана отката включает: актуальные резервные копии всех конфигурационных файлов исходных серверов, сохраненные дампы баз данных на момент последней синхронизации, документированные IP-адреса и DNS-записи исходной среды, процедуру обратного переключения трафика (возврат upstream в балансировщике или откат DNS-записей), контакты ответственных лиц для экстренной связи. Команда для быстрого отката трафика через балансировщик: закомментируйте новые upstream-серверы, раскомментируйте старые, выполните nginx -s reload. Время отката - менее минуты.
Храните план отката в отдельном файле вне мигрируемой инфраструктуры - в облачной заметке, на личном ноутбуке или в бумажном виде. Во время аварии доступ к вики на мигрируемом сервере может отсутствовать. Полное руководство по миграции серверов включает расширенный чек-лист отката с примерами команд для разных сценариев.
Проверка работоспособности после миграции
Тестирование после миграции подтверждает, что все сервисы функционируют корректно на новой платформе. Проверки выполняются по структурированному чек-листу, который охватывает сетевую доступность, работу приложений, целостность данных, внешние интеграции и мониторинг. Не пропускайте этот этап - проблемы, не выявленные в первые часы, могут проявиться через неделю в виде падения продаж из-за неработающей формы обратной связи.
Автоматизируйте проверки где возможно. Smoke-тесты через curl для веб-эндпоинтов, скрипты проверки целостности БД, опрос метрик через Prometheus - все это сокращает время валидации и исключает человеческий фактор. Ручная проверка обязательна для бизнес-критичных сценариев: оформление заказа, отправка email-уведомлений, загрузка файлов.
Чек-лист тестирования: от сети до приложений
Разбейте проверки на категории и проходите их последовательно. Сетевая доступность: ping до целевых серверов из внутренней сети и извне, traceroute для проверки маршрутов, telnet или nc для проверки открытых портов (nc -zv server-ip 443). DNS-разрешение: dig A your-domain.com @8.8.8.8 и dig MX your-domain.com для почтовых записей. Убедитесь, что разрешаются все поддомены и обратные зоны (PTR-записи), если они используются для почтовых серверов.
Веб-сервер: curl с явным указанием заголовка Host для проверки виртуальных хостов: curl -I -H 'Host: example.com' http://server-ip/. Проверьте коды ответа (200 для страниц, 301/302 для редиректов, 404 для несуществующих - но не для живых страниц). SSL-сертификаты: openssl s_client -connect your-domain.com:443 -servername your-domain.com и проверка срока действия, цепочки доверия, соответствия домену.
Базы данных: подключитесь клиентом к каждой БД, выполните тестовый запрос (SELECT 1;), проверьте количество записей в критичных таблицах и сравните с данными до миграции. Почтовые сервисы: отправьте тестовое письмо через sendmail или swaks, проверьте очередь (mailq), убедитесь, что SPF/DKIM/DMARC-записи проходят валидацию. Фоновые задачи: проверьте логи cron и systemd-таймеров за последний час после миграции, убедитесь, что задачи выполнились без ошибок. Мониторинг и логирование: агенты Zabbix/Prometheus должны быть подключены к серверу мониторинга, централизованный сбор логов (ELK, Loki) - получать поток с новых серверов.
Типичные проблемы после миграции и их решение
Несоответствие версий ПО - самая частая проблема. На целевом сервере может стоять более новая версия PHP, которая ломает обратную совместимость, или другая мажорная версия PostgreSQL, требующая дампа и восстановления вместо репликации. Перед миграцией составьте таблицу версий критичного ПО на исходной и целевой сторонах и добейтесь их идентичности или проверенной совместимости.
Забытые переменные окружения проявляются ошибками вида «connection refused» или «undefined variable». Проверьте файлы /etc/environment, .env в корне проектов, переменные в systemd-юнитах (systemctl show service-name | grep Environment). Проблемы с правами доступа: после rsync или восстановления из архива владельцы файлов могут сбиться на root. Исправьте рекурсивно: chown -R www-data:www-data /var/www/project. Для баз данных проверьте, что пользователь БД имеет доступ с нового IP: GRANT ALL PRIVILEGES ON database.* TO 'user'@'new-ip' IDENTIFIED BY 'password';.
Конфликты IP-адресов возникают, если целевые серверы подняты с теми же IP, что и исходные, в одной сети. Всегда используйте разные IP на время синхронизации и тестирования, меняя их только в момент финального переключения. Неработающие внешние сервисы из-за смены IP - проблема белых списков. Заранее запросите у провайдеров API добавление новых исходящих адресов в whitelist. Если интеграция критична, сохраните старый IP через прокси или NAT до полного перехода.
Документирование изменений и снижение рисков
Актуальная документация после миграции - это страховка на случай аварии и инструмент для онбординга новых сотрудников. Обновите схемы сети с новыми IP-адресами и именами хостов, инвентарные списки оборудования и виртуальных машин, конфигурационные файлы ключевых сервисов в репозитории, процедуры восстановления из резервных копий с учетом нового расположения данных.
Используйте системы управления конфигурациями (Ansible, Puppet, Salt) как способ документирования кодом. Вся конфигурация сервера, описанная в Ansible-плейбуке, сама по себе является документацией: она показывает, какие пакеты установлены, какие сервисы запущены, какие файлы конфигурации применены. После миграции обновите плейбуки, чтобы они отражали целевую инфраструктуру, и храните их в Git-репозитории с историей изменений. Руководство по миграции IT-инфраструктуры для DevOps включает методологию документирования на всех этапах проекта.
Документирование снижает риски при будущих миграциях и авариях. Если через год потребуется перенести инфраструктуру еще раз, актуальная схема сети и инвентарный список сократят время аудита с недели до нескольких часов. Для экстренного восстановления критично иметь документированную процедуру: в случае сбоя в 3 часа ночи вы не будете вспоминать, на каком именно сервере крутился почтовый релей.
Юридические аспекты: что нужно знать о персональных данных
При миграции серверов, особенно с выходом в зарубежные дата-центры или облака, необходимо учитывать требования 152-ФЗ «О персональных данных». IP-адрес в российской правоприменительной практике трактуется как персональные данные (косвенный идентификатор физического лица). Это означает, что передача IP-адреса посетителя вашего сайта на зарубежный сервер без согласия может быть квалифицирована как нарушение.
Проверьте, какие внешние сервисы использует ваша инфраструктура. Подключение Google Fonts передает IP-адрес каждого посетителя на серверы Google в США. Аналогично работают зарубежные CDN (jsDelivr, unpkg, cdnjs), чат-виджеты (Intercom, Zendesk Chat), встроенные видео с YouTube и Vimeo, карты Google Maps, капчи reCAPTCHA. При миграции на российские серверы или при ревизии инфраструктуры замените эти сервисы на самохостинг: шрифты храните локально, используйте российские CDN, настройте отложенную загрузку видео и карт только после явного согласия пользователя.
Для соответствия 152-ФЗ обеспечьте: опубликованную политику обработки персональных данных, форму согласия с активным (не предустановленным) чекбоксом, уведомление Роскомнадзора о начале обработки ПДн, локализацию первичной базы данных с персональными данными на территории России. Если миграция предполагает трансграничную передачу данных, требуется отдельное уведомление РКН. Штрафы за нарушение требований о локализации достигают 6 миллионов рублей для юридических лиц.