KVM + virsh в продакшне: запускаем первый стенд и сравниваем с ESXi

Последние недели у нас шёл внутренний разговор, который рано или поздно приходит к любой команде, которая давно сидит на VMware: а что если не VMware? Не в смысле «бросить всё и переехать», а в смысле - можно ли сейчас взять KVM и поставить клиенту в продакшн без риска облажаться перед лицом серьёзной нагрузки?

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

Взяли железо, поставили KVM, завели несколько виртуалок с RHEL 6 и CentOS, дали нагрузку. Вот что получилось.

Как ставили и что использовали

Хост - двухсокетный сервер на базе Intel Xeon E5-2600, 128 ГБ RAM, RAID-контроллер с кешем, локальные диски под хранение. Ничего экзотического. ОС хоста - CentOS 6.5, пакеты из стандартного репозитория: qemu-kvm, libvirt, virt-manager. Для управления со стороны - virsh и virt-manager через SSH с X-forwarding.

Сети делали через linux bridge: один бридж на production VLAN, один на management. Никаких вендорских сетевых коммутаторов.

Виртуалки: несколько инстансов RHEL 6.5 под прикладные сервисы, один CentOS для мониторинга. Диски - qcow2 через virtio-blk, сеть - virtio-net.

Где KVM не уступает ESXi

Производительность вычислений нас не удивила - приятно, но ожидаемо. KVM с virtio-драйверами на гостевых RHEL отдаёт ресурсы почти без накладных расходов. Под типичной прикладной нагрузкой - веб-приложение с базой данных - разницы между физическим сервером и виртуалкой на KVM практически нет. vSphere в этом плане тоже хорош, но принципиального отрыва нет ни в одну сторону.

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

Хранение - вот тут чуть интереснее. qcow2 с cache=writeback даёт приемлемую производительность, но если нужна честная запись без потерь при отказе питания - включаешь cache=none и теряешь часть скорости. В vSphere та же история с политиками кеша на датастором, просто интерфейс привычнее.

Где ESXi заметно удобнее

Управляемость - вот где разрыв реальный, и отрицать его было бы нечестно.

• vCenter vs virsh. vCenter - это центральное управление кластером, DRS, HA, vMotion через GUI. virsh - это CLI к одному хосту. Да, libvirt умеет управлять несколькими хостами, и virsh -c qemu+ssh://другой-хост/system работает. Но это ручная координация, а не оркестрация. Если один из трёх хостов упал - ВМ никуда сами не уедут.
• Живая миграция. virsh migrate работает, мы проверили. Но миграция с общим хранилищем требует NFS или другого разделяемого тома - с локальными дисками это уже отдельная история с full copy. В vSphere vMotion на shared storage - отполированная история, настраиваешь раз и не думаешь.
• Мониторинг и алерты. ESXi пишет события в vCenter, там можно настроить алерты по любому параметру. В случае KVM - нужно самому прикрутить внешний мониторинг. Мы использовали Zabbix с libvirt-плагином, работает, но это дополнительный слой, который надо поддерживать.
• Снапшоты. virsh snapshot-create есть и работает. Но управление снапшотами в virsh менее наглядное, и дерево снапшотов через CLI быстро превращается в кашу если не вести учёт руками.

Лицензионный вопрос

Это, собственно, то, из-за чего разговор вообще начался. vSphere с vCenter - это деньги, и немалые. KVM - это ядро Linux, libvirt - открытый код, RHEL-хост на сервере у клиента уже был. Итого: новый гипервизорный стенд обошёлся без дополнительных лицензионных расходов на виртуализацию.

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

Что в итоге

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

Честный вывод: KVM - это рабочий гипервизор для продакшна при условии, что ты готов строить управляемость своими руками или мириться с её ограниченностью. Для одного-двух хостов без требований к автоматическому failover - вполне годится. Для кластера из десяти хостов с HA и живой миграцией по требованию - ESXi сейчас выигрывает по удобству управления с большим отрывом.

Сопровождение таких стендов мы берём, но сразу предупреждаем: операционные трудозатраты на KVM-кластер без коммерческого management layer выше, чем на сопоставимый vSphere. Это нужно считать в экономике перехода, а не только лицензии.

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