oVirt. все статьи цикла
Главная страница Engine предлагает на выбор три различных портала (См. рис. 1): для пользователей (User Portal), для администраторов (Administration Portal) и для просмотра отчетов (Reports Portal). Ниже, в разделе Downloads присутствует внешняя ссылка на страницу где можно загрузить клиент SPICE, плагины и драйвера.
Рис. 1 Страница входа oVirt Engine
Для настройки инфраструктуры необходимо перейти в раздел администрирования (Administration Portal).
В плане архитектуры все довольно знакомо и схоже с аналогичными платформами виртуализации (См. рис. 2).
Рис. 2. Веб-консоль администратора oVirt
Наивысшим объектами являются дата-центры (Data Centers). В его состав входят один или несколько кластеров (Clusters) в них соответственно включаются вычислительные узлы (Hosts) на которых в свою очередь работают ВМ. Такие объекты как хранилища (Storage) и сети (Networks) ассоциируются с конкретным дата-центром и доступны всем кластерам.
Дата центр
После первого входа в веб-консоль Engine вы обнаружите, что дата-центр (Default data center) и кластер ассоциированный с ним (Default cluster) уже созданы. Я рекомендую не создавать новые объекты, а переименовать существующие и при необходимости изменить настройки.
Кроме стандартных имени и описания дата-центра интересны два параметра: Type и Quota Mode. Первый определяет какой тип хранилища будет использоваться. Тип Shared позволяет использовать поддерживаемые типы общих хранилищ, а Local — только локальные диски вычислительных узлов.
Примечание: При использовании локальных дисков, становятся не доступны такие возможности как перенос ВМ на другой узел, а так же защита ВМ с помощью HA. Более того, в дата-центре с таким типом хранилища, может быть только один кластер и единственный узел в нем. То есть если у вас несколько таких узлов каждый из них будит существовать в своем собственном дата-центре.
Quota Mode — определяет действие при срабатывании квот: Disable — квоты выключены, Audit — логирование и бездействие, Enforced — ограничивать ресурсы в соответствие с квотами. Более подробно о механизме квот в соответствующем разделе.
Кластер
Кластер, как и в других платформах виртуализации – это группа физических серверов, которые являются пулом вычислительных ресурсов для виртуальных машин. Так же это область миграции, в пределах которой виртуальные машины могут быть перемещены с узла на узел. По этому все члены кластера должны иметь один и тот же тип процессора, работать в одном сетевом сегменте и иметь доступ к одинаковому набору хранилищ.
У кластера значительно больше параметров, но наиболее значимый сейчас это CPU Name. Здесь из выпадающего списка необходимо выбрать семейство процессоров установленных на наших гипервизорах. В случае если выбор будет не верным, узел попросту не удастся активировать – перевести в состояние готовности. Узнать тип процессора на узле можно после его добавления в разделе информации (См. Рис. 3), после чего изменить настройки кластера.
Рис. 3. Информация о гипервизоре
Так же, если запускаемые ВМ не критичны к производительности то я рекомендую перейти на вкладку Optimization и задействовать отключенные механизмы оптимизации KVM.
Это позволит ВМ использовать гиперпотоки процессоров как реальные виртуальные процессоры (Count Threads As Cores). Memory Balloon высвободит в общий пул неиспользуемую память ВМ, а KSM control (слияние одинаковых страниц памяти)позволяет использовать одну страницу памяти несколькими ВМ. Все это дает возможность запустить на одном узле больше ВМ без потери или с минимальной потерей производительности.
Гипервизоры
Теперь дело дошло до гипервизоров, которые находятся в ожидании с предыдущего раздела. Делается это на вкладке Hosts, предварительно выбрав в левой панели созданный ранее кластер.
Указываем отображаемое имя в поле Name, а так же полное доменное имя (желательно) или IP в поле Address и пароль root для доступа по SSH.
Следом будет предложено настроить параметры IPMI-модуля установленного в сервере (Power management). Это позволит выполнять перезагрузку, включение и выключение сервера прямо из интерфейса Engine, что очень удобно.
Поддерживаемые типы IPMI-модулей
: apc, apc_snmp, bladecenter, cisco_ucs, drac5, eps, ilo, ilo2, ilo3,
ilo4, ipmilan, rsa, rsb, wti.
В случае отсутствия IPMI-модуля, его настройку можно опустить и не обращать внимание на соответствующее предупреждение.
Далее Engine выполнит установку и настройку всех необходимых пакетов и служб с подключенных на узле репозиториев. Ход процесса можно наблюдать в нижней панели событий (См. рис. 4).
Рис. 4. Автоматическая настройка гипервизора.
oVirt Node Hupervisor
oVirt Node Hypervisor — дистрибутив CentOS из которого удаленно все лишнее и оставлен только гипервизор и все то что необходимо для его работы. Более того, файловая система дистрибутива доступна только для чтения, и лишь некоторые каталоги с конфигурационными файлами на запись. oVirt Node Hypervisor является аналогом ESXi от VMware со схожим псевдографическим интерфейсом (См. рис. 5).
Рис. 5. Интерфейс oVirt Node.
Последнюю версию можно загрузить с официального сайта.
Дистрибутив очень быстро и легко устанавливается и так же просто подключается к Engine.
Сложно судить какой вариант более приемлемый. По моему мнению полноценная ОС более функциональная и универсальная, а специализированный дистрибутив выглядит немного надежнее и практически не требует обслуживания.
Помогла ли вам статья?
