oVirt за 2 часа. Часть 1. Открытая отказоустойчивая платформа виртуализации

Введение

Open source проект oVirt — свободная платформа виртуализации корпоративного уровня. Пролистав habr, обнаружил, что oVirt освещен здесь не так широко, как того заслуживает.
oVirt фактически является апстримом для коммерческой системы Red Hat Virtualization (RHV, ранее RHEV), растет под крылом Red Hat. Чтобы не возникло путаницы, это не то же, что CentOS vs RHEL, модель ближе к Fedora vs RHEL.
Под капотом — KVM, для управления используется веб-интерфейс. Базируется на ОС RHEL/CentOS 7.
oVirt может использоваться как для «традиционной» серверной, так и десктопной виртуализации (VDI), в отличие от решения VMware обе системы могут уживаться в одном комплексе.
Проект хорошо документирован, давно достиг зрелости для продуктивного применения и готов к высоким нагрузкам.
Эта статья — первая в цикле о том, как построить работающий отказоустойчивый кластер. Пройдя по ним, мы за короткое (порядка 2-х часов) время получим полностью работающую систему, хотя ряд вопросов, конечно, раскрыть не удастся, постараюсь осветить их в следующих статьях.
У себя используем его несколько лет, начинали с версии 4.1. Наша промышленная система сейчас живет на вычислителях HPE Synergy 480 и ProLiant BL460c 10-го поколения c Xeon Gold CPU.
На момент написания действующая версия 4.3.

Статьи

1. Введение (Мы здесь)
2. Установка менеджера (ovirt-engine) и гипервизоров (hosts)
3. Дополнительные настройки

Функциональные особенности

В oVirt есть 2 основные сущности: ovirt-engine и ovirt-host(s). Для тех, кто хорошо знаком с продукцией VMware, oVirt в целом как платформа это vSphere, ovirt-engine — управляющий слой — выполняет те же функции, что vCenter, а ovirt-host — гипервизор, как ESX(i). Т.к. vSphere очень популярное решение, иногда буду приводить сравнение с ней.

Рис. 1 — панель управления oVirt.

В качестве гостевых машин поддерживается большинство дистрибутивов Linux и версий Windows. Для гостевых машин есть агенты и оптимизированные виртуальные устройства и драйверы virtio, в первую очередь дисковый контроллер и сетевой интерфейс.
Для реализации отказоустойчивого решения и всех интересных функций потребуется разделяемое хранилище. Поддерживаются как блочные FC, FCoE, iSCSI, так и файловые NFS хранилища и др. Для реализации отказоустойчивого решения система хранения также должна быть отказоустойчивой (минимум 2 контроллера, мультипасинг).
Использование локальных хранилищ возможно, но по умолчанию для настоящего кластера годятся только разделяемые хранилища (shared storages). Локальные хранилища делают систему разрозненным набором гипервизоров и даже при наличии разделяемого хранилища кластер собрать не получится. Наиболее правильный путь — бездисковые машины с boot from SAN, либо диски минимального объема. Вероятно, через vdsm hook возможен вариант сборки из локальных дисков Software Defined Storage (напр., Ceph) и презентации его ВМ, но серьезно его не рассматривал.

Архитектура

Рис. 2 — архитектура oVirt.
Подробнее с архитектурой можно ознакомиться в документации разработчика.

Рис. 3 — объекты oVirt.

Верхний элемент в иерархии — Data Center. Он определяет, используются разделяемые (shared) или локальные хранилища, а также используемый набор функций (совместимость, от 4.1 до 4.3). Может быть один или несколько. Для многих вариантов годится использование Data Center по умолчанию — Default.
Data Center состоит из одного или нескольких Clusters. Кластер определяет тип процессора, политики миграции и др. Для небольших инсталляций можно также ограничиться кластером Default.
Кластер, в свою очередь, состоит из Host‘ов, выполняющих основную работу — они несут виртуальные машины, к ним подключены хранилища. В кластере предполагается 2 или более хостов. Хотя технически возможно сделать кластер с 1-м хостом, но это не имеет практической пользы.

В oVirt поддерживается множество функций, в т.ч. живая миграция виртуальных машин между гипервизорами (live migration) и хранилищами (storage migration), десктопная виртуализация (virtual desktop infrastructure) с пулами ВМ, statefull и stateless ВМ, поддержка NVidia Grid vGPU, импорт из vSphere, KVM, есть мощное API и многое другое. Все эти функции доступны без лицензионных отчислений, а при необходимости поддержки ее можно приобрести у Red Hat через региональных партнеров.

О ценах на RHV

Стоимость не высока в сравнении с VMware, покупается только поддержка — без требования покупки самой лицензии. Поддержка приобретается только на гипервизоры, ovirt-engine, в отличие от vCenter Server трат не требует.

Пример расчета на 1-й год владения

Рассмотрим кластер из 4-х 2-х сокетных машин и розничные цены (без проектных скидок).
Стандартная подписка RHV стоит $999 за сокет/год (премиум 365/24/7 — $1499), итого 4*2*$999=$7992.
Цена vSphere:

• VMware vCenter Server Standard $10,837.13 за экземпляр, плюс подписка Basic $2,625.41 (Production — $3,125.39);
• VMware vSphere Standard $1,164.15 + Basic Subscription $552.61 (Production $653.82);
• VMware vSphere Enterprise Plus $6,309.23 + Basic Subscription $1,261.09 (Production $1,499.94).

Итого: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $27 196,62 за самый младший вариант. Разница около 3,5 раз!
В oVirt’е же все функции доступны без ограничений.

Краткие характеристики и максимумы

Системные требования

Для гипервизора требуется ЦПУ со включенной аппаратной виртуализацией, минимальный объем ОЗУ для старта — 2 ГиБ, рекомендованный объем хранилища для ОС — 55 ГиБ (по большей части для журналов и т.п., сама ОС занимает мало).
Подробнее — здесь.
Для Engine минимальные требования 2 ядра/4 ГиБ ОЗУ/25 ГиБ хранилища. Рекомендованные — от 4 ядра/16 ГиБ ОЗУ/50 ГиБ хранения.
Как и в любой системе, есть ограничения на объемы и количества, большинство из которых превышает возможности доступных массовых коммерческих серверов. Так, пара Intel Xeon Gold 6230 может адресовать 2 ТиБ ОЗУ и дает 40 ядер (80 потоков), что меньше даже лимитов одной ВМ.

Virtual Machine Maximums:

• Maximum concurrently running virtual machines: Unlimited;
• Maximum virtual CPUs per virtual machine: 384;
• Maximum memory per virtual machine: 4 TiB;
• Maximum single disk size per virtual machine: 8 TiB.

Host Maximums:

• Logical CPU cores or threads: 768;
• RAM: 12 TiB;
• Number of hosted virtual machines: 250;
• Simultaneous live migrations: 2 incoming, 2 outgoing;
• Live migration bandwidth: Default to 52 MiB (~436 Mb) per migration when using the legacy migration policy. Other policies use adaptive throughput values based on the speed of the physical device. QoS policies can limit migration bandwidth.

Manager Logical Entity Maximums:

В 4.3 существуют следующие лимиты.

• Data center
  • Maximum data center count: 400;
  • Maximum host count: 400 supported, 500 tested;
  • Maximum VM count: 4000 supported, 5000 tested;
• Cluster
  • Maximum cluster count: 400;
  • Maximum host count: 400 supported, 500 tested;
  • Maximum VM count: 4000 supported, 5000 tested;
• Network
  • Logical networks/cluster: 300;
  • SDN/external networks: 2600 tested, no enforced limit;
• Storage
  • Maximum domains: 50 supported, 70 tested;
  • Hosts per domain: No limit;
  • Logical volumes per block domain (more): 1500;
  • Maximum number of LUNs (more): 300;
  • Maximum disk size: 500 TiB (limited to 8 TiB by default).

Варианты внедрения

Как уже говорилось, oVirt строится из 2-х базовых элементов — ovirt-engine (управление) и ovirt-host (гипервизор).
Engine может размещаться как вне самой платформы (standalone Manager — это может быть ВМ, запущенная в другой платформе или отдельном гипервизоре и даже физическая машина), так и на самой платформе (self-hosted engine, аналогично подходу VCSA от VMware).
Гипервизор может быть установлен как на обычную ОС RHEL/CentOS 7 (EL Host), так и на специализированную минимальную ОС (oVirt-Node, основана на el7).
Аппаратные требования для всех вариантов примерно одинаковы.

Рис. 4 — стандартная архитектура.

Рис. 5 — Self-hosted Engine архитектура.

Для себя выбрал вариант standalone Manager и EL Hosts:

• standalone Manager немного проще при проблемах запуска, нет дилеммы курицы и яйца (как и для VCSA — не запустишь, пока полностью не поднимется хотя бы один хост), но появляется зависимость от другой системы*;
• EL Host предоставляет всю мощь ОС, что полезно для внешнего мониторинга, отладки, поиска неисправностей и т.д.

* Однако за все время эксплуатации это не потребовалось, даже после серьезной аварии с питанием.
Но уже ближе к делу!
Для эксперимента есть возможность освободить пару лезвий ProLiant BL460c G7 с Xeon® CPU. На них и будем воспроизводить процесс установки.
Узлам дадим имена ovirt.lab.example.com, kvm01.lab.example.com и kvm02.lab.example.com.
Переходим непосредственно к установке.

Источник: habr.com