KVM + libvirt на CentOS 6: тестируем live migration и virsh вместо VMware для Linux-хостинга

CentOS 6 вышел в конце прошлого года, и одним из главных его аргументов для нас стала нормальная поддержка KVM прямо из коробки - через libvirt и virt-manager без плясок с ядром. Мы давно присматривались к тому, чтобы часть клиентской Linux-инфраструктуры перевести с OpenVZ на KVM. В этом месяце наконец поставили полноценный тестовый стенд и прогнали его через несколько сценариев. Пишем по горячим следам.

Почему вообще уходить с OpenVZ

OpenVZ - рабочий инструмент, мы его используем давно и без особых претензий. Контейнеры быстро поднимаются, overhead минимальный, снапшоты простые. Но у него есть три принципиальных ограничения, которые с некоторых пор стали регулярно вылезать:

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

Второе - только Linux. Клиент захотел Windows-гостя рядом с Linux на том же хосте - с OpenVZ это тупик.

Третье - изоляция не полная. Контейнеры делят /proc и некоторые системные ресурсы. Для большинства задач это незаметно, но в редких случаях - чаще всего с приложениями, которые агрессивно работают с сетевым стеком или файловыми дескрипторами - один контейнер мог влиять на соседей. KVM - полная виртуализация с отдельным ядром для каждого гостя, этой проблемы нет.

VMware для Linux-хостинга нам покупать не хочется: лицензии дорогие, а функционал ESXi в этом сценарии избыточен. Hyper-V на Linux-хосте не живёт. KVM - логичный следующий шаг.

Стенд и базовая конфигурация

Два хоста на CentOS 6.0 x86_64: каждый по 32 ГБ RAM, Intel Xeon с поддержкой VT-x. Общее хранилище - NFS-шара на третьем сервере, туда кладём образы дисков ВМ. Без общего хранилища live migration не работает, это принципиально.

Установка KVM + libvirt в CentOS 6 делается в несколько команд:

yum groupinstall "Virtualization" "Virtualization Platform" "Virtualization Client"
service libvirtd start
chkconfig libvirtd on

Проверяем, что процессор поддерживает аппаратную виртуализацию:

egrep '(vmx|svm)' /proc/cpuinfo

Если вывод пустой - KVM не заведётся, нужно проверять BIOS на предмет включённого VT-x. На наших хостах флаг vmx присутствует, всё хорошо.

Сеть настраиваем через bridge: создаём br0 на хосте, привязываем к нему физический интерфейс, гости подключаются к бриджу напрямую и получают IP из той же подсети, что и хост. Это стандартная схема для серверной виртуализации - гости видны в сети как отдельные машины.

Создание ВМ и базовый virsh

Первую ВМ подняли через virt-install - он генерирует XML-конфигурацию и регистрирует машину в libvirt:

virt-install \
  --name testvm01 \
  --ram 2048 \
  --disk /mnt/vmstore/testvm01.qcow2,size=20,format=qcow2 \
  --vcpus 2 \
  --os-type linux \
  --os-variant rhel6 \
  --network bridge=br0 \
  --graphics none \
  --console pty,target_type=serial \
  --location 'http://mirror.centos.org/centos/6/os/x86_64/' \
  --extra-args 'console=ttyS0,115200n8 serial'

Дальше управление через virsh. Несколько команд, которые вошли в ежедневный обиход:

virsh list --all          # список всех ВМ
virsh start testvm01      # запустить
virsh shutdown testvm01   # мягкое выключение
virsh destroy testvm01    # принудительное (аналог выдёргивания питания)
virsh console testvm01    # последовательная консоль
virsh dumpxml testvm01    # вывод XML-конфигурации

Написали небольшой shell-скрипт для массовых операций - например, snapshot всех ВМ перед обслуживанием хоста:

#!/bin/bash
for vm in $(virsh list --name --state-running); do
    virsh snapshot-create-as --domain "$vm" \
        --name "pre-maintenance-$(date +%Y%m%d)" \
        --atomic
    echo "Snapshot created for $vm"
done

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

Live migration: проверяем на практике

Это был главный вопрос: насколько live migration в KVM/libvirt сравним с vMotion по надёжности и прозрачности для гостя.

Схема проста - обоим хостам нужен доступ к одному хранилищу с образами дисков (у нас NFS), SSH-ключи между хостами для аутентификации, и настроенный libvirtd с включённым TCP-транспортом на обоих.

Команда миграции:

virsh migrate --live testvm01 qemu+ssh://kvm02/system

Мигрировали ВМ с запущенным nginx и активными подключениями. Во время миграции запускали ping к гостю и делали HTTP-запросы каждые 100 мс. Результат: два-три пропущенных ping в момент переключения, HTTP-запросы с timeout не упали вовсе. Для нашего сценария - обслуживание хостов без окна недоступности - это приемлемо.

vMotion на гигабите делал это примерно так же. Существенная разница в том, что KVM-миграция работает без vCenter - не нужен централизованный оркестратор, достаточно SSH между хостами.

Что насторожило

Несколько моментов, которые требуют внимания перед тем, как идти в продакшн:

qcow2 vs raw. Образы в формате qcow2 дают снапшоты и сжатие, но добавляют overhead на I/O из-за дополнительного слоя трансляции. На нагруженных базах данных это может быть заметно. raw-образы быстрее, но без встроенных снапшотов. Пока тестируем оба варианта под разные сценарии.

Сеть libvirtd при live migration. По умолчанию libvirtd слушает только на unix-сокете, для миграции нужно включить TCP и открыть порты (16514 для TLS, 49152-49215 для данных миграции). Это значит, что нужна нормальная сегментация - трафик миграции не должен ходить через публичный интерфейс.

Мониторинг. Zabbix-агент внутри KVM-гостя работает как обычно, никаких проблем. Но метрики самого гипервизора - количество ВМ, состояние, потребление ресурсов - нужно снимать через libvirt API или virsh. Готового шаблона под это мы не нашли, будем писать сами.

Где стоим сейчас

Стенд работает две недели, нескольких тестовых ВМ живут на KVM без нареканий. На обслуживании у нас сейчас три клиента с OpenVZ-кластерами, и для одного из них - там уже поднялся вопрос о Windows-госте - миграция на KVM выглядит оправданной. Для остальных двух пока нет практического смысла менять то, что работает.

Главный вывод этого месяца: KVM в CentOS 6 - это уже не «поиграться на коленке», а рабочий инструмент для продакшн-Linux-хостинга. Live migration работает, управление через virsh scripted, overhead приемлемый. Для VMware это не конкурент в корпоративном сегменте с Windows-парком, но для чисто Linux-окружений разрыв значительно меньше, чем год назад.