VMware и Proxmox: как мигрировать большую инфраструктуру без боли для бизнеса

Еще несколько лет назад разговоры о замене VMware воспринимались как попытка сэкономить ради самой экономии. Практически в любой крупной компании можно было услышать один и тот же аргумент: "VMware дорогой, зато надежный". Инфраструктурные команды привыкли к знакомым инструментам, процедуры эксплуатации были отлажены годами, а сам гипервизор казался чем-то настолько фундаментальным, что его замена выглядела почти невозможной. Однако изменения на рынке заставили многие организации пересмотреть эти убеждения. Рост стоимости лицензий, ужесточение условий использования и усиливающаяся зависимость от одного поставщика сделали вопрос миграции не теоретическим, а вполне практическим.

При этом сама миграция редко становится чисто технической задачей. Бизнес видит цифры в счетах и хочет сократить расходы. Руководство ожидает минимального риска и отсутствия простоев. Пользователи вообще не должны заметить изменений. А инженеры оказываются между всеми этими ожиданиями, пытаясь перевезти десятки или сотни сервисов, сохранив их доступность и предсказуемость работы. Именно поэтому миграция крупных VMware-инфраструктур давно перестала быть задачей уровня "скопировать виртуальную машину". На самом деле это полноценный инфраструктурный проект, затрагивающий архитектуру, процессы и даже культуру эксплуатации.

Главный принцип такой миграции звучит удивительно просто:

Бизнес не должен заметить, что гипервизор вообще поменялся.

Если сотрудники утром открывают ERP-систему, запускают отчеты, работают с корпоративными порталами и не подозревают о происходящем - значит, инженеры сделали свою работу правильно.

Почему нельзя просто перенести виртуальные машины

Практически все проблемные проекты начинаются одинаково. Кто-то на совещании произносит фразу: "Это же просто виртуалки". После этого появляется оптимистичный план на ближайшие выходные: выключить VMware в пятницу вечером, экспортировать VMDK, импортировать их в Proxmox и в понедельник торжественно объявить о завершении миграции.

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

Переезжает не виртуальная машина. Переезжает вся экосистема вокруг нее.

Именно поэтому во время миграции очень быстро обнаруживаются неприятные сюрпризы. Оказывается, что критически важный сервис использует старую DNS-запись, про которую никто не помнит. Производственная база данных зависит от виртуальной машины, отмеченной как "temporary". Сервер, созданный для тестов несколько лет назад, давно обслуживает реальных пользователей. А часть приложений вообще никто не обновлял со времен, когда Docker считался экзотикой.

Хорошая миграция - это не перенос технического долга в новое место. Это возможность наконец разобраться с хаосом, накопленным годами.

Инвентаризация - знакомство с реальной инфраструктурой

Самая неприятная часть проекта одновременно оказывается самой полезной. Именно здесь выясняется, как на самом деле устроена инфраструктура компании.

Сначала подключаемся к vCenter:

Connect-VIServer vcsa.company.local

Получаем базовую информацию обо всех виртуальных машинах:

Get-VM | Select-Object `
Name,
PowerState,
NumCpu,
MemoryGB,
UsedSpaceGB,
ProvisionedSpaceGB,
Guest,
VMHost

Сохраняем результаты для дальнейшего анализа:

Get-VM | Select-Object `
Name,
PowerState,
NumCpu,
MemoryGB,
UsedSpaceGB,
ProvisionedSpaceGB,
Guest,
VMHost |
Export-Csv vmware-inventory.csv -NoTypeInformation

Но на этом останавливаться нельзя. Полезно сразу выгрузить сведения о сетевых подключениях:

Get-VM |
Get-NetworkAdapter |
Select-Object `
VM,
Name,
NetworkName,
MacAddress,
Type |
Export-Csv vmware-network.csv -NoTypeInformation

Собираем информацию о виртуальных дисках:

Get-VM |
Get-HardDisk |
Select-Object `
Parent,
Name,
CapacityGB,
StorageFormat,
Filename |
Export-Csv vmware-disks.csv -NoTypeInformation

Не менее важна информация о гостевых операционных системах и IP-адресах:

Get-VMGuest |
Select-Object `
VMName,
OSFullName,
IPAddress |
Export-Csv vmware-guests.csv -NoTypeInformation

Во многих организациях именно после анализа этих отчетов начинается настоящая инвентаризация. Выясняется, что часть систем не имеет владельцев, некоторые машины работают уже восемь-девять лет, а названия вроде test-new-final-v2 давно потеряли связь с реальностью.

Особенно интересно становится во время обсуждения следующего вопроса:

Кто отвечает за эту виртуальную машину?

И если в переговорной комнате наступает тишина, значит, миграция началась вовремя.

Snapshots как индикатор зрелости процессов

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

Проверяем их наличие:

Get-VM | Get-Snapshot

Получаем подробный отчет:

Get-VM |
Get-Snapshot |
Select-Object `
VM,
Name,
Created,
SizeGB |
Sort-Object Created

Если в результатах обнаруживается запись вида:

Created: 2019-03-17

то перед вами практически эталонная enterprise-инфраструктура.

Перед началом миграции необходимо провести полноценную ревизию снимков. Старые snapshots следует удалить, предварительно оценив доступное пространство в datastore. После удаления рекомендуется выполнить consolidate и убедиться в отсутствии зависших цепочек.

В противном случае можно столкнуться с крайне неприятной ситуацией, когда перенос виртуальной машины объемом 500 ГБ неожиданно превращается в миграцию нескольких терабайт данных. И именно в этот момент инженеры начинают понимать, что технический долг обладает вполне материальным весом.

Подготовка Proxmox и Ceph к production

Очень часто команда считает, что если кластер Proxmox успешно установлен, а Ceph показывает статус HEALTH_OK, значит инфраструктура готова к переезду. К сожалению, между понятиями "работает" и "готово к production" существует огромная разница.

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

Проверяем состояние кластера:

ceph -s

Анализируем использование дисков:

ceph osd df

Изучаем задержки:

ceph osd perf

Именно здесь становится понятно, насколько честно был спроектирован кластер хранения. Если значения commit latency стабильно превышают 20 мс, запускать производственную миграцию пока не стоит. Пользователи могут не знать, что такое Ceph, но они очень быстро почувствуют разницу между двумя миллисекундами и сорока.

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

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

Проверяем интерфейсы:

ip link

Тестируем Jumbo Frames:

ping -M do -s 8972 10.10.10.20

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

Миграция Linux - самый спокойный сценарий, если подготовиться заранее

На фоне остальных систем Linux действительно считается наиболее предсказуемым кандидатом для миграции. Большинство современных дистрибутивов прекрасно работают как в VMware, так и в Proxmox. Однако именно это создает опасную иллюзию простоты. Инженеры расслабляются, считая, что "Linux и так загрузится". Иногда так и происходит. А иногда виртуальная машина после первого запуска встречает администратора аварийной консолью initramfs и сообщением о невозможности обнаружить загрузочный диск.

Причина обычно банальна. VMware использует собственные контроллеры хранения, а Proxmox ориентирован на VirtIO - паравиртуализированные драйверы, обеспечивающие значительно более высокую производительность. Если необходимые модули не были заранее включены в initramfs, операционная система просто не понимает, где находится корневой раздел.

Поэтому подготовка Linux начинается еще внутри VMware.

Добавляем необходимые модули:

cat << EOF >> /etc/initramfs-tools/modules
virtio
virtio_pci
virtio_blk
virtio_scsi
virtio_net
EOF

Пересобираем initramfs:

update-initramfs -u -k all

Для систем на базе RHEL и производных дистрибутивов используем dracut:

dracut --force --regenerate-all

Проверяем наличие модулей:

lsinitramfs /boot/initrd.img-$(uname -r) | grep virtio

После этого можно удалить VMware Tools и установить агент QEMU:

apt remove open-vm-tools -y

apt install qemu-guest-agent -y

systemctl enable --now qemu-guest-agent

Проверяем статус:

systemctl status qemu-guest-agent

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

Конвертация и импорт дисков

Существует множество способов переноса дисков, однако наиболее универсальным вариантом остается экспорт VMDK и последующая конвертация.

На стороне VMware:

vmkfstools \
-i source.vmdk \
-d thin \
clone.vmdk

Конвертируем диск:

qemu-img convert \
-p \
-f vmdk clone.vmdk \
-O raw vm.raw

Почему RAW, а не QCOW2?

Потому что при использовании Ceph RBD формат RAW зачастую показывает более предсказуемую производительность и меньший накладной расход. Да, QCOW2 поддерживает дополнительные возможности вроде внутренних снимков, но в большинстве production-сценариев с Ceph предпочтение отдается именно RAW.

Создаем виртуальную машину:

qm create 101 \
  --name app-prod-01 \
  --memory 8192 \
  --cores 4 \
  --cpu host \
  --agent enabled=1 \
  --scsihw virtio-scsi-single \
  --net0 virtio,bridge=vmbr0

Импортируем диск:

qm importdisk \
101 \
vm.raw \
ceph-ssd

Подключаем его:

qm set 101 \
--scsi0 ceph-ssd:vm-101-disk-0

Настраиваем загрузку:

qm set 101 --boot order=scsi0

Запускаем машину:

qm start 101

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

journalctl -xe

Использование памяти:

free -h

Сетевые интерфейсы:

ip addr

Ошибки ввода-вывода:

dmesg | grep -i error

Только после этого виртуальную машину можно считать кандидатом для включения в production.

Windows - инфраструктурный survival horror

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

Проблема заключается в том, что Windows гораздо чувствительнее к изменениям виртуального оборудования. Смена контроллера хранения, переключение BIOS, особенности Secure Boot и отсутствие драйверов VirtIO способны превратить обычный перенос в полноценный инцидент.

Символом таких миграций давно стала ошибка:

INACCESSIBLE_BOOT_DEVICE

Чтобы избежать подобных ситуаций, следует действовать постепенно.

Сначала создаем виртуальную машину с SATA-контроллером:

qm create 200 \
  --name win-prod-01 \
  --memory 16384 \
  --cores 8 \
  --cpu host \
  --net0 e1000,bridge=vmbr0

Подключаем диск:

qm set 200 \
--sata0 ceph-ssd:vm-200-disk-0

Подключаем образ с драйверами VirtIO:

qm set 200 \
--ide2 local:iso/virtio-win.iso,media=cdrom

После успешной загрузки устанавливаем:

VirtIO Storage Driver;
VirtIO Network Driver;
Balloon Driver;
QEMU Guest Agent;
VirtIO Serial Driver.

Проверяем наличие драйверов:

Get-WindowsDriver -Online |
Where-Object {
    $_.OriginalFileName -like "*virtio*"
}

Только после этого переключаемся на VirtIO SCSI:

qm set 200 \
--delete sata0

qm set 200 \
--scsi0 ceph-ssd:vm-200-disk-0

Именно такой подход позволяет избежать значительной части проблем.

Проверка служб после миграции

После загрузки Windows необходимо убедиться, что все работает корректно.

Проверяем агент:

Get-Service QEMU-GA

Проверяем события системы:

Get-WinEvent -LogName System |
Select-Object -First 50

Контролируем сетевую связанность:

Test-NetConnection `
-ComputerName dc01.company.local `
-Port 389

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

Именно здесь становится очевидно, насколько важен rollback-план. Для Windows он не является дополнительной мерой предосторожности. Он обязателен.

Stateful-системы нельзя перевозить как виртуальные машины

Практически все первые крупные миграции совершают одну и ту же ошибку. Команда успешно переносит десятки Linux-серверов и начинает относиться к процессу слишком уверенно. Затем наступает очередь PostgreSQL, Elasticsearch, Kafka или Redis, и выясняется, что привычный подход больше не работает.

Потому что состояние приложения находится не внутри виртуальной машины.

Оно находится в данных.

И если данные являются самым ценным активом бизнеса, то переносить их методом "выключили - скопировали - включили" становится неоправданным риском.

Особенно если объемы измеряются уже не десятками гигабайт, а терабайтами.

Именно поэтому зрелые миграции строятся вокруг репликации, постепенного переключения и отказа от классического lift-and-shift для критически важных сервисов.

PostgreSQL: миграция через репликацию вместо героизма

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

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

Если PostgreSQL еще не работает в кластерном режиме, миграция становится идеальным поводом исправить эту ситуацию.

Создаем пользователя репликации:

CREATE ROLE replicator
WITH REPLICATION
LOGIN
PASSWORD 'strong-password';

Настраиваем параметры сервера:

wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
hot_standby = on
wal_keep_size = 4096MB

Добавляем правила доступа:

cat >> /etc/postgresql/16/main/pg_hba.conf << EOF
host replication replicator 10.20.0.0/16 scram-sha-256
EOF

Перезагружаем конфигурацию:

SELECT pg_reload_conf();

На новом узле Proxmox подготавливаем реплику:

systemctl stop postgresql

rm -rf /var/lib/postgresql/16/main/*

Создаем базовую копию:

pg_basebackup \
-h old-master \
-D /var/lib/postgresql/16/main \
-U replicator \
-P \
-R \
-C \
-S proxmox_replica

Запускаем службу:

systemctl start postgresql

Проверяем состояние репликации:

SELECT
    client_addr,
    state,
    sync_state,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

На стороне реплики контролируем отставание:

SELECT now() - pg_last_xact_replay_timestamp();

Если задержка измеряется секундами или долями секунд, система готова к переключению.

В заранее согласованное окно обслуживания блокируем запись на старом узле, убеждаемся, что реплика догнала мастер, и выполняем повышение:

SELECT pg_promote();

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

Если же в инфраструктуре используется Patroni, процесс становится еще безопаснее. Фактически мы расширяем существующий кластер новыми узлами в Proxmox, дожидаемся синхронизации и выполняем контролируемый switchover.

Посмотреть текущее состояние кластера Patroni можно командой:

patronictl list

А инициировать переключение:

patronictl switchover

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

Elasticsearch, Kafka и другие распределенные системы

Тот же принцип работает и для большинства современных распределенных платформ. Их главная сила заключается именно в возможности постепенного перемещения нагрузки.

Например, Elasticsearch совершенно не обязательно переносить как набор виртуальных машин. Гораздо разумнее добавить новые узлы в Proxmox-кластер и позволить системе самостоятельно перераспределить данные.

Проверяем состояние кластера:

curl -s \
http://localhost:9200/_cluster/health?pretty

Просматриваем размещение шардов:

curl -s \
http://localhost:9200/_cat/shards?v

Добавляем новые узлы и контролируем процесс ребалансировки:

curl -X GET \
"http://localhost:9200/_cat/recovery?v"

После завершения синхронизации постепенно выводим старые серверы из эксплуатации.

Kafka мигрируется похожим образом. Вместо выключения существующих брокеров мы расширяем кластер новыми экземплярами.

Проверяем список брокеров:

kafka-broker-api-versions.sh \
--bootstrap-server kafka01:9092

Запускаем перенос разделов:

kafka-reassign-partitions.sh \
--bootstrap-server kafka01:9092 \
--reassignment-json-file reassignment.json \
--execute

Контролируем выполнение:

kafka-reassign-partitions.sh \
--bootstrap-server kafka01:9092 \
--reassignment-json-file reassignment.json \
--verify

В результате потребители даже не подозревают, что часть нагрузки уже обслуживается совершенно другой инфраструктурой.

Redis, RabbitMQ и MinIO также лучше переносить путем постепенного расширения существующих кластеров. Да, такой подход требует больше подготовки, зато практически исключает продолжительные простои и значительно снижает риск потери данных.

Kubernetes проще построить заново

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

Очень многие инженеры сначала пытаются сохранить существующую структуру. Возникают идеи скопировать control plane, перенести etcd, экспортировать виртуальные диски мастер-узлов и вернуть все обратно уже в Proxmox. Теоретически это возможно. Практически подобные операции превращаются в крайне рискованные эксперименты.

Kubernetes создавался как платформа, способная переживать отказ отдельных узлов. Поэтому гораздо логичнее воспользоваться его сильными сторонами.

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

Создаем резервную копию объектов Kubernetes:

velero backup create production

Проверяем список резервных копий:

velero backup get

Восстанавливаем ресурсы в новом кластере:

velero restore create \
--from-backup production

Контролируем выполнение:

velero restore get

После восстановления постепенно переключаем ingress-контроллеры, переносим внешние точки входа и начинаем направлять пользовательский трафик уже на новый кластер.

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

CI/CD нельзя переносить в последний момент

Когда разговор заходит о миграции, большинство команд сосредотачивается на виртуальных машинах, системах хранения и базах данных. При этом очень часто забывают о механизмах доставки изменений. А ведь именно CI/CD-платформа становится кровеносной системой современной инфраструктуры. Если после переключения инженеры теряют возможность собирать контейнеры, выкатывать обновления или запускать автоматические тесты, то даже идеально перенесенный production начинает быстро превращаться в проблему.

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

Если используется GitLab, новые Runner следует зарегистрировать еще до начала активной фазы миграции:

gitlab-runner register

Пример регистрации shell-runner:

gitlab-runner register \
  --url https://gitlab.company.local \
  --registration-token GLRT-xxxxxxxx \
  --executor shell \
  --description proxmox-runner-01

Если используются Docker Runner:

gitlab-runner register \
  --url https://gitlab.company.local \
  --registration-token GLRT-xxxxxxxx \
  --executor docker \
  --docker-image alpine:latest \
  --description proxmox-docker-runner

После регистрации полезно убедиться, что новый исполнитель действительно доступен:

gitlab-runner verify

При использовании Jenkins логика остается аналогичной. Новые агенты поднимаются заранее:

java -jar agent.jar \
  -url https://jenkins.company.local \
  -secret SECRET \
  -name proxmox-agent-01 \
  -workDir /opt/jenkins

На протяжении некоторого времени старая VMware-площадка и новая инфраструктура Proxmox работают одновременно. Новые пайплайны постепенно начинают выполняться на новых исполнителях, а старые остаются страховкой на случай проблем.

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

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

Проверяем проекты Harbor через API:

curl -u admin:password \
https://harbor.company.local/api/v2.0/projects

Проверяем доступность контейнерных образов:

crictl pull \
harbor.company.local/library/nginx:latest

Наличие нескольких работающих экземпляров реестра существенно снижает риски во время переключения.

Переключение трафика - самый ответственный этап миграции

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

И здесь многие допускают критическую ошибку.

Они пытаются переключить всех сразу.

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

Гораздо безопаснее использовать постепенное переключение.

За несколько дней до cutover уменьшаем TTL DNS-записей:

Проверяем фактическое значение:

dig app.company.local

Убеждаемся:

dig app.company.local | grep TTL

Если используется HAProxy, новый backend добавляется заранее.

Исходная конфигурация:

backend app_backend
    balance roundrobin
    server app01 10.10.10.10:443 check

Добавляем новый сервер:

backend app_backend
    balance roundrobin
    server app01 10.10.10.10:443 check
    server app02 10.20.20.10:443 check

Проверяем конфигурацию:

haproxy -c \
-f /etc/haproxy/haproxy.cfg

Перезагружаем без разрыва соединений:

systemctl reload haproxy

Если балансировщик поддерживает взвешивание, можно организовать постепенный перенос нагрузки:

backend app_backend
    balance roundrobin
    server app01 10.10.10.10:443 check weight 95
    server app02 10.20.20.10:443 check weight 5

Через некоторое время:

backend app_backend
    balance roundrobin
    server app01 10.10.10.10:443 check weight 80
    server app02 10.20.20.10:443 check weight 20

Затем:

backend app_backend
    balance roundrobin
    server app01 10.10.10.10:443 check weight 50
    server app02 10.20.20.10:443 check weight 50

И только после подтверждения стабильности:

backend app_backend
    balance roundrobin
    server app02 10.20.20.10:443 check weight 100

Такой подход известен как canary migration. Он позволяет выявить проблемы до того, как они затронут всех пользователей.

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

Наблюдаемость становится главным инструментом инженера

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

Минимальный набор метрик должен включать:

загрузку процессоров;
использование оперативной памяти;
задержки дисковых операций;
сетевые ошибки;
время ответа приложений;
показатели баз данных;
бизнес-метрики.

Например, для PostgreSQL полезно отслеживать количество активных соединений:

SELECT count(*)
FROM pg_stat_activity;

Для Ceph:

ceph osd perf

Для Kubernetes:

kubectl top nodes

kubectl top pods -A

Для Linux-серверов:

iostat -xz 1

vmstat 1

sar -n DEV 1

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

Финальный cutover должен быть скучным

Это одна из самых недооцененных мыслей в инфраструктурной инженерии.

Многие привыкли романтизировать ночные аварии, экстренные совещания и героические спасения production. В фильмах про ИТ это выглядит впечатляюще. В реальной жизни подобные сценарии почти всегда являются следствием плохой подготовки.

Плохая миграция выглядит так:

собирается war room;
телефоны не замолкают;
руководство требует объяснений;
инженеры вручную исправляют конфигурации;
запускается экстренный rollback;
никто не понимает, сколько еще продлится инцидент.

Хорошая миграция выглядит удивительно скучно.

Трафик постепенно переключается.

Пользователи продолжают работать.

Мониторинг остается зеленым.

Время ответа приложений не меняется.

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

Именно такая скука является главным признаком зрелости инфраструктурной команды.

Почему VMware нельзя выключать сразу после миграции

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

Мы уже переехали. Когда можно выключать старый кластер?

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

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

Именно поэтому зрелые команды оставляют VMware в режиме ожидания еще некоторое время.

Минимальный разумный срок составляет:

24-72 часа

Но для действительно крупных инфраструктур этот период может достигать одной-двух недель.

В течение этого времени необходимо убедиться, что корректно работают:

резервное копирование;
задания планировщика;
интеграции с внешними системами;
механизмы высокой доступности;
системы мониторинга;
процессы восстановления;
бизнес-приложения;
процедуры обновления.

Очень полезно заранее составить чек-лист послемиграционной проверки.

Например:

- [ ] Проверены резервные копии
- [ ] Выполнен тест восстановления
- [ ] Проверена репликация PostgreSQL
- [ ] Проверены Kafka consumers
- [ ] Проверена работа Elasticsearch
- [ ] Проверен вход пользователей
- [ ] Проверены интеграции LDAP/AD
- [ ] Проверены CI/CD пайплайны
- [ ] Проверена работа мониторинга
- [ ] Проверены уведомления

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

Rollback-план должен существовать до начала работ

Существует старая инфраструктурная шутка:

Если у вас нет rollback-плана, значит, ваш rollback-план называется "импровизация".

Проблема в том, что импровизация обычно происходит ночью, под давлением времени и руководства.

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

Перед началом работ необходимо ответить на несколько вопросов.

Что станет сигналом к откату?

Например:

деградация производительности более чем на 20%;
невозможность завершить критические бизнес-операции;
ошибки приложений выше согласованного порога;
невозможность восстановления сервиса за установленное время.

Кто принимает решение?

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

Сколько времени занимает возврат?

Если rollback требует двенадцати часов ручной работы, это не rollback, а новый проект миграции.

Полезно заранее отработать процедуру на тестовой среде.

Например, для переключения трафика через HAProxy откат может выглядеть следующим образом:

cp \
/etc/haproxy/haproxy.cfg.rollback \
/etc/haproxy/haproxy.cfg

haproxy -c \
-f /etc/haproxy/haproxy.cfg

systemctl reload haproxy

Для DNS:

nsupdate << EOF
server dns01.company.local
update delete app.company.local A
update add app.company.local 300 A 10.10.10.10
send
EOF

Для PostgreSQL switchover через Patroni:

patronictl switchover

Хороший rollback должен быть скучным, предсказуемым и многократно проверенным.

Что дает бизнесу переход на Proxmox

Если отбросить технические детали, возникает вполне закономерный вопрос: зачем вообще проходить через такой сложный проект?

Ответ обычно лежит сразу в нескольких плоскостях.

Во-первых, компания получает значительно больший контроль над платформой. Исчезает зависимость от изменений лицензионной политики одного поставщика. Решения о развитии инфраструктуры принимаются исходя из интересов бизнеса, а не из очередного обновления прайс-листа.

Во-вторых, снижается стоимость владения. Разумеется, Proxmox не является "бесплатным VMware". Появляются расходы на проектирование, обучение команды, поддержку Ceph и развитие внутренних компетенций. Однако экономика таких платформ зачастую оказывается значительно более предсказуемой.

В-третьих, миграция становится поводом навести порядок.

За годы эксплуатации в инфраструктуре неизбежно накапливаются:

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

Во время переезда появляется редкая возможность задать простой вопрос:

А действительно ли нам это нужно?

Иногда ответ позволяет сократить инфраструктуру на десятки процентов без какого-либо влияния на бизнес.

Наконец, переход на Proxmox часто становится первым шагом к более зрелому Platform Engineering-подходу. Команды начинают активнее использовать автоматизацию, инфраструктуру как код, GitOps-практики и воспроизводимые процессы эксплуатации. В результате выигрывает не только виртуализация, но и вся инженерная культура компании.

Финальные мысли

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

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

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

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

Потому что лучшая миграция - это та, о которой никто потом не вспоминает.