ovirt что это такое
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
oVirt
oVirt — это бесплатная платформа для управления виртуализацией, лицензированная и разработанная как программное обеспечение с открытым исходным кодом. oVirt основывается на мощной виртуальной машине на базе ядра (гипервизор KVM) и на сервере управления RHEV, выпущенном Red Hat, Inc. для сообщества с открытым исходным кодом.
Содержание
Архитектура
Стандартное развертывание oVirt состоит из трех вещей, в первую очередь:
Кроме того, обычно служба идентификации отправляется в сторону механизма, чтобы аутентифицировать пользователей и администраторов для ovirt-engine.
Узлы хранения могут использовать хранилище блоков или файлов и могут быть локальными или удаленными, доступными через NFS. Технологии хранения, такие как GlusterFS, поддерживаются через тип хранилища POSIXFS. Узлы хранения сгруппированы в пулы хранения, что может обеспечить высокую доступность и избыточность. Страница терминов хранилища Vdsm содержит более подробную информацию.
Различные диаграммы и описания ниже представляют архитектуру проекта oVirt и его различные компоненты.
На следующей диаграмме показаны различные компоненты в сердечнике двигателя:
Основными компонентами ядра двигателя являются:
Технология
oVirt базируется на технологии KVM
Особенности
Хранение организовано внутри объектов, называемых доменами хранения, и может быть локальным или общим. Домены хранения могут быть созданы с использованием следующих решений или протоколов хранения:
Функции аварийного восстановления включают возможность импорта любого домена хранения в разные экземпляры экземпляра oVirt, а репликация может управляться из oVirt с помощью функции гео-репликации GlusterFS или путем использования синхронной / асинхронной репликации уровня блока, предоставляемой поставщиками оборудования для хранения. Резервные копии oVirt могут быть автоматизированы и периодически перенесены в удаленное местоположение.
Возможности
Хранение
oVirt использует централизованную систему хранения для образов дисков виртуальной машины, файлов ISO и моментальных снимков. Сеть хранения данных может быть реализована с использованием:
oVirt имеет три типа доменов хранения:
Вы должны присоединить домен данных к центру обработки данных, прежде чем присоединить к нему домены других типов.
Общие сведения о доменах хранения
В NFS все виртуальные диски, шаблоны и моментальные снимки являются файлами.
В SAN (iSCSI / FCP) каждый виртуальный диск, шаблон или моментальный снимок является логическим томом. Блочные устройства объединяются в логический объект, называемый группой томов, а затем разделяются LVM на логические тома для использования в качестве виртуальных жестких дисков.
Виртуальные диски могут иметь один из двух форматов: QCOW2 или RAW. Тип хранилища может быть либо разреженным, либо предварительно выделенным. Снимки всегда разрежены, но их можно использовать для дисков, созданных как RAW или разреженных.
Поддержка операционных систем
oVirt часть 1. Введение
oVirt. все статьи цикла
Краткая история
На сегодняшний день, существует четыре основных кита на рынке виртуализации серверов на базе архитектуры x86. Лидером здесь является VMware с продуктом vSphere, следом идет Microsoft и их Hyper-V, с большим отставанием XenServer от Citrix и к сожалению но совсем позади RHEV — RedHat Enterprise Virtualization.
Следует отметить, что с продуктами для виртуализации приложений и рабочих станций картина выглядит несколько иначе и фаворитом здесь является Citrix. Но, это лишь к слову так как гвоздь сегодняшней программы — RHEV практически отсутствует в этой нише. Если кто-то еще не понял при чем тут RHEV то немного об его истории будет как раз кстати.
Точкой отсчета можно считать далекий 2006 год, когда популярный сегодня модуль ядра KVM стал частью ядра Linux. А вместе с ним мир узнал о израильской компании Qumranet. Кроме KVM они разрабатывали совершенно новый протокол удаленного взаимодействия с рабочим столом виртуальных машин под названием SPICE. Этот протокол вместе с KVM являлся основой их платформы для виртуализации рабочих станций под названием Solid ICE. Спустя два года RedHat покупает Qumranet и их наработки ложатся в основу платформы RHEV. С тех пор начинается победное шествие KVM над Xen в дистрибутивах основанных на RHEL.
В 2010 году RedHat выпускает на рынок первую (с номером 2.1) версию RHEV. Так как по наследству от Qumranet, RHEV получила сервер управления, написанный на .NET, то для работы с ним была необходима установленная MS Windows. По этой же причине исходный код продукта не был открыт. Но спустя еще два года все Windows-зависимые компоненты были переписаны на Java и Python и вошли в самую значимую версию RHEV 3.0 с полностью открытым кодом. Именно с этой версии началась история oVirt, так как это не что иное как upstream-версия RHEV развиваемая сообществом.
На текущий момент стабильным считается обновление с номером 3.4 выпущенное этим летом.
Что есть oVirt?
OVirt — это платформа для виртуализации дата-центра. При этом на ряду с виртуализацией серверов oVirt представляет некоторые возможности для виртуализации рабочих станций.
Основные возможности платформы
По функционалу и предназначению oVirt является аналогом VMware vSphere предоставляя практически те же возможности уступая пожалуй лишь в некотором удобстве.
Поддержка до 128 логических CPU и 2 ТБ памяти на гипервизоре, 160 vCPU и 2 ТБ памяти — для ВМ:
Поддержка сетевых хранилищ iSCSI, FC, NFS, GlusterFS, а так же локальных дисков гипервизоров:
Поддержка переноса работающих ВМ между узлами (Live Migration), перезапуск ВМ в случае отказа гипервизора (High Availability) а так же автоматическая балансировка нагрузки на узлах кластера:
Поддержка снимков состояния (snapshots) работающих ВМ:
Поддержка “тонких” дисков:
Создание шаблонов ВМ, экспорт и импорт (в формате OVF):
Горячее добавление/удаление виртуальных сетевых адаптеров (vNIC), поддержка изолированных локальных сетей на хосте (bridge-less network), зеркалирование портов (port mirroring):
Интегрированный механизм отчетности, позволяющий анализировать данные о производительности за различные периоды и строить прогнозы по развитию виртуальной инфраструктуры:
Богатый API, позволяющий получить доступ ко всем компонентам решения из сторонних приложений:
Виртуализация рабочих станций
Здесь так же, практически стандартный современный набор:
Портал самообслуживания, позволяющий пользователям в зависимости от разрешений самостоятельно развертывать ВМ, создавать шаблоны и администрировать собственные экземпляры:
Технология связанных клонов (Linked image), позволяющая запустить множество ВМ из одного образа:
Пулы виртуальных машин:
Автоматическая приостановка ВМ (Auto suspend):
Поддержка 32-битного цветового режима:
Поддержка потокового видео (streaming video):
Поддержка нескольких мониторов (до 4):
Двунаправленное аудио и видео:
Перенаправление USB (USB 2.0 redirection):
Оптимизация работы по медленным каналам связи (WAN).
К сожалению из-за недостаточной популярности платформы для нее не найти полнофункциональных решений для резервного копирования, таких как Veeam Backup & Replication или Acronis Backup for VMware. Кроме этого, oVirt не может похвастаться таким набором дополнительных продуктов как у VMware, но справедливости ради стоит сказать что эти расширения находят применение довольно редко.
POWERFUL OPEN SOURCE VIRTUALIZATION
oVirt is a free open-source virtualization solution for your entire enterprise
Donate Hardware!
COMMUNITY POWERED
oVirt is an open-source distributed virtualization solution, designed to manage your entire enterprise infrastructure. oVirt uses the trusted KVM hypervisor and is built upon several other community projects, including libvirt, Gluster, PatternFly, and Ansible.
What’s included?
Case Studies
Florida State University RCC
Florida State University’s Research Computing Center (RCC) provides the university’s academic community with access to a virtual machine cluster. It is used for basic data services, collaborative applications, firewall installation, and other self-managed services.
In 2016, RCC successfully migrated their virtual machine cluster to oVirt. The oVirt-powered cluster is currently serving 60 users across 20 academic departments.
Alter Way
Meet Alter Way, a French hosting company who deploys oVirt in production for their clients, because «it allowed us to scale up as well as scale out our client workloads».
The main points which swayed their decision? «A very active community, an ambitious technical roadmap with regular releases, and the involvement of companies including Red Hat, Intel, NetApp, Cisco and IBM reassured us that the project would be around for the duration.»
Brussels Airport Company
Find out how the Brussels Airport Company keeps a vital transportation and cargo center moving by managing their virtual machines with oVirt.
Faced with an opportunity to take the approximately 150 virtual machines housed on 30 Solaris machines and manage them with another virtual datacenter management tool, the Brussels Airport IT team went with oVirt running atop CentOS.
Развёртывание и настройка oVirt 4.0. Часть 1. Создание кластера виртуализации в конфигурации Hosted Engine
С этой записи я начну серию заметок о развёртывании и базовой настройке свободно распространяемой системы виртуализации oVirt версии 4.0 в конфигурации Hosted Engine с учётом тех граблей, по которым мне удалось походить. Но для начала пару слов о том, каким образом я пришёл к решению о необходимости развёртывания такого продукта, как oVirt.
Итак, oVirt. Сразу хочу определиться с терминологией и архитектурой oVirt, чтобы не было в дальнейшем каких-то недопониманий того, что и зачем делается. Сам по себе, oVirt не является гипервизором, а является средством управления гипервизором KVM. По сути oVirt в сегодняшнем его состоянии уже можно ставить в одну линейку c такими продуктам, как VMware vCenter или Microsoft System Center Virtual Machine Manager, делая при этом скидку на то, что это всё-тки не коммерческое решение, и ждать от него всего богатства функционала, как у коммерческих решений, не приходится. Однако, как я вижу, oVirt сегодня очень активно развивается и поддерживается компанией Red Hat. И это не может не радовать.
Архитектура oVrt
Сердцем oVirt является сервер с компонентами oVirt Engine. С этого сервера происходит управление всеми хостами виртуализации, общими дисковыми ресурсами и виртуальными сетями. В ранних версиях oVirt Engine требовал наличия выделенного сервера под свою управляющую роль и для построения высоко-доступной инфраструктуры oVirt требовалось, как минимум, 3 физических сервера – один сервер под oVirt Engine и минимум два хоста виртуализации. В настоящее же время oVirt Engine не требует наличия выделенного физического сервера, а может быть развёрнут в виде виртуальной машины прямо на том хосте виртуализации, которым он будет в последствии управлять. Такой вариант развёртывания в терминологии oVirt называется Hosted Engine. Таким образом, теперь для развёртывания высоко-доступной инфраструктуры oVirt требуется наличие лишь двух физических серверов. Обратите внимание на то, что говоря про oVirt, я сразу завёл речь о высокой доступности, так как я считаю, что заниматься внедрением oVirt имеет смысл лишь тогда, когда вы планируете использовать функционал кластеризации и балансировки нагрузки с использованием нескольких хостов виртуализации (от двух и более). Что же касается более мелких вариантов виртуальных сред (1-2 хоста), то для них более эффективным, с точки зрения максимального упрощения развёртывания, может оказаться использование таких продуктов, как ранее упомянутый Proxmox VE.
План развёртывания oVirt Hosted Engine
Видео, где Simone сам комментирует свою презентацию, можно найти здесь: oVirt self-hosted engine seamless deployment by Simone Tiraboschi
Подготовка хостов к развёртыванию oVirt Hosted Engine
Нам потребуется подготовить 2 физических сервера с ОС CentOS Linux 7.2 под будущие хосты виртуализации. В моём случае используется два «олд-скульных» сервера HP ProLiant DL360 G5 одинаковой аппаратной конфигурации (особенности установки CentOS 7 на такой сервер описывались ранее ) :
Проверяем на обоих хостах наличие поддержки виртуализации на процессоре сервера, например, утилитой lscpu:
Другой вариант, посмотреть вывод команды:
Среди флагов процессора должен присутствовать флаг vmx (для процессоров Intel), либо флаг svm (для процессоров AMD).
Поддержка есть, двигаемся дальше.
Останавливаем и отключаем службу NetworkManager, так как oVirt берёт на себя управление сетевыми профилями в системе. Когда я пробовал выполнять развёртывание oVirt 3.6, с запущенной службой NetworkManager, oVirt попросту не устанавливался. В oVirt 4.0 ситуация изменилась, и теперь процесс установки работает с запущенной службой NetworkManager, однако я предпочёл всё же отключить и остановить данную службу и сейчас:
В файлах, описывающих сетевые интерфейсы ( /etc/sysconfig/network-scripts/ifcfg* ), уберём значения параметров DNS, там где они указаны в явном виде (удалим параметры DNS1,DNS2 и т.д.) и добавим параметр PEERDNS=no. Например, в моём случае, конфигурационный файл интерфейса управления (vlan-интерфейс поверх bond-интерфейса), через который я подключаюсь к серверу выглядит следующим образом:
Добавим в системный конфигурационный файл /etc/sysctl.conf пару строчек:
Чтобы сразу задействовать включение ipv6, например на интерфейсе lo, можно сделать так:
После проделанных изменений перезагрузим сервер и проверим, чтобы на Loopback-интерфейсе был назначен адрес ipv6 ::1
Добавляем информацию о репозитории oVirt и Epel. Это обязательный шаг.
Развёртывание oVirt Hosted Engine на первом хосте
Загружаем минимальный установочный образ CentOS 7 во временную папку на первом хосте ( KOM-AD01-VM31 ), который мы будем использовать для развёртывания oVirt. Этот образ потребуется нам в дальнейшем для установки виртуальной машины с oVirt Hosted Engine:
Репозитории oVirt и Epel уже были подключены ранее на этапе подготовки хоста. Устанавливаем пакеты, необходимые для развёртывания oVirt Hosted Engine:
В процессе установки в систему дополнительно будет установлено более трёхсот пакетов-зависимостей.
Дополнительно установим утилиту screen:
Перед запуском процедуры развёртывания запустим утилиту screen, как это рекомендует онлайн-руководство, создав screen-сессию и подключившись к ней.
В screen-сессии запускаем процедуру развёртывания oVirt Hosted Engine:
В процессе развёртывания будет задан ряд вопросов, на которые мы должны ответить. На первый вопрос о том, что мы действительно хотим сделать из данного сервера хост виртуализации и после этого создать виртуальную машину для развёртывания Hosted Engine, отвечаем утвердительно (можно просто Enter, так как в фигурных скобках отражается предлагаемый по умолчанию ответ):
Конфигурация хранилища для виртуальной машины Hosted Engine
Следующим шагом, программа установки опросит систему на предмет доступных для сервера хранилищ выбранного типа и выдаст перечень возможных вариантов. Выбираем LUN, в который будет размещена виртуальная машина с Hosted Engine. Чтобы LUN можно было использовать для первичного развёртывания oVirt, он не должен содержать никаких разделов (должен иметь статус free):
Конфигурация сети хоста для создания bridge-интерфейса
На вопрос об автоматической настройке брандмауэра отвечаем утвердительно, чтобы скрипты установки создали нужные для функционирования oVirt правила в iptables и firewalld
Конфигурация виртуальной машины для роли Hosted Engine
Следующий этап – задание параметров будущей виртуальной машины Hosted Engine.
Конфигурация Hosted Engine.
Следующий этап – задание параметров, относящихся к работе Hosted Engine.
Установка на хост компонент oVirt и создание виртуальной машины
После того как все параметры будущей виртуальной машины Hosted Engine заданы, ещё раз их просматриваем и жмём Enter для подтверждения запуска процесса установки:
В ходе установки будет выполнена настройка libvirt и VDSM, настройка дискового хранилища, которое мы выделили под виртуальную машину Hosted Engine, создание виртуальной машины…
Затем на экран будет выведено предложение подключиться к консоли созданной виртуальной машины для установки внутрь этой ВМ гостевой ОС. Консоль виртуальной машины будет нам доступна на нашем хосте ( KOM-AD01-VM31 ) по протоколу VNC на порту 5900 с временным паролем доступа указанном в сообщении.
Появившееся в самом конце сообщения меню выбора действий, мы пока оставим без выбора, то есть ничего больше пока не нажимаем в этом сеансе. Предполагается, что первый пункт будет выбран позднее, в том случае, если дальнейшая процедура развертывания ОС в виртуальную машину для Hosted Engine пройдёт штатно. Если же в процессе установки CentOS внутрь виртуальной машины возникнут проблемы, то можно будет вернуться к этому меню и выбрать пункт 3 для того, чтобы гипервизору хоста была дана команда на перезапуск этой ВМ. Пункты 2 и 4 нужны в том, случае если вы решили «на всё плюнуть» и пойти играть в пинг-понг.
Итак, оставим текущий сеанс в ожидании и создадим новое подключение к консоли только что созданной и запущенной виртуальной машины Hosted Engine по протоколу VNC.
Установка гостевой ОС в виртуальную машину Hosted Engine
Так как наш хост не имеет установленных X-компонент, то подключение к консоли виртуальной машины можно сделать с любого другого компьютера локальной сети, имеющего графическую среду и средства работы с протоколом VNC. Я использую для этой задачи рабочую станцию на базе Microsoft Windows и утилиту UltraVNC Viewer (загрузить можно отсюда ). Интерфейс утилиты «прост до безобразия», и всё, что нам нужно указать это адрес подключения и пароль, который мы только что увидели в screen-сессии на хосте:
В моём случае для установки CentOS был выбран NetInstall-дистрибутив, который подразумевает загрузку необходимых для установки ОС пакетов из онлайн-репозитория CentOS. Поэтому нам придётся дополнительно его прописать в разделе установщика INSTALLATION SOURCE
Добавим онлайн-репозиторий для CentOS 7 64-bit:
При этом не забываем указать данные прокси сервера, если он используется:
Разделы диска я оставил предложенные режимом автоматической разметки, только отказался от использования LVM и заменил файловую систему на ext4. Из общей ёмкости виртуального диска в 40 GB под систему я оставил 25 GB, и сделал отдельную точку монтирования размером в 15 GB под NFS-шару для oVirt ISO Domain, как и планировал ранее.
Дождёмся конца установки CentOS в виртуальную машину и в завершении выполним её перезагрузку:
Как только виртуальная система уйдёт в перезагрузку, наша VNC-сессия к этой виртуальной машине будет автоматически закрыта.
Перезагрузка виртуальной машины
Отправив виртуальную машину в перезагрузку, отключив тем самым VNC-сессию, возвращаемся в screen-сессию на нашем хосте виртуализации ( KOM-AD01-VM31 ) и в ожидающем меню процедуры развёртывания выбираем пункт 1, инициируя тем самым процедуру повторной загрузки, только что отключенной виртуальной машины.
После этого программа развёртывания oVirt дождётся от гипервизора хоста сигнал того, что виртуальная машина загружена и предложит нам снова подключиться к этой ВМ через VNC с использованием всё того же временного пароля.
Появившееся в самом конце меню выбора действий мы снова пока оставим в ожидании. Предполагается, что первый пункт будет выбран позднее, в том случае, если дальнейшая процедура развертывания самого управляющего набора пакетов oVirt Engine внутри только что развёрнутой виртуальной CentOS будет завершена успешно. И опять же, если в процессе установки пакетов oVirt Engine внутри виртуальной машины возникнут проблемы, то можно будет вернуться к этому меню и выбрать пункт 3 для того, чтобы гипервизор хоста перезапустил эту ВМ, и мы смогли начать этот шаг заново. Пункты 2 и 4 могут пригодится тем, кто решил всё бросить и пойти на рыбалку.
Итак, снова оставим текущий сеанс в ожидании и создадим новое подключение к нашему хосту по протоколу VNC.
После-установочная настройка гостевой ОС в виртуальной машине
На этот раз подключившись к консоли виртуальной машины мы уже увидим приглашение входа только что установленной CentOS 7. Входим в систему с учётной записью пользователя root и паролем, который мы задали в ходе установки ОС на эту виртуальную машину.
Кстати, теперь уже мы может использовать SSH для доступа к нашему виртуальному серверу.
После этого нам желательно будет перезагрузить ОС внутри виртуальной машины. Для этого внутри виртуальной машины вызовем команду reboot, а когда отключится VNC-сессия, вернёмся в screen-сессию на нашем хосте виртуализации и выберем пункт рестарта виртуальной машины – Power off and restart the VM.
После того, как виртуальная машина снова станет доступна, мы можем подключиться к ней по VNC или SSH (кому как удобно) и выполнить процедуру развёртывания управляющих пакетов oVirt Engine. Однако в нашем примере, как вы наверное помните, мы хотим дополнительно организовать NFS-шару для возможности монтирования ISO-образов из этой шары к будущим виртуальным машинам (oVirt ISO Domain). Поэтому перед тем, как приступить к установке управляющих пакетов oVirt Engine в виртуальной машине, настроим в ней NFS-сервер.
Установка NFS-сервера в гостевой ОС виртуальной машины
Снова подключившись к виртуальной машине, устанавливаем NFS-сервер, который в дальнейшем потребуется нам в качестве ISO Domain. Можно конечно использовать для oVirt ISO Domain и выделенный NFS-сервер, но в моём случае его нет, поэтому все загрузочные/инсталляционные ISO-образы мы будем держать непосредственно в NFS-шаре внутри самого oVirt Engine сервера.
Устанавливаем пакеты для поддержки NFS:
Проверяем наличие каталога, который мы указали в процессе установки ОС:
Запускаем службы NFS и включаем их автозагрузку:
Включаем разрешающие правила брандмауэра firewalld для возможности удалённого подключения к NFS-серверу:
Теперь можно переходить к развёртыванию управляющих пакетов oVirt Engine на гостевую ОС внутри нашей виртуальной машины.
Установка компонент oVirt Engine в гостевой ОС виртуальной машины
Добавляем информацию о репозиториях oVirt и Epel, а затем сразу выполняем установку и запуск развёртывания управляющих компонент oVirt Engine:
Будет запущен мастер развёртывания компонент oVirt Engine, где нам тоже потребуется ответить на ряд вопросов. На первые четыре вопроса из секции PRODUCT OPTIONS можно оставить предложенные по умолчанию утвердительные ответы
В разделе вопросов о сетевой конфигурации оставим предложенное по умолчанию FQDN имя нашего виртуального сервера и разрешим настройку необходимых правил брандмауэра:
В секции конфигурации базы данных оставим предложенные по умолчанию значения, чтобы программа установки развернула и сконфигурировала локальный экземпляр postgresql:
В конфигурации Engine у нас будет запрошен пароль учётной записи admin. Здесь важно указать тот же пароль, который мы указывали ранее в начале процедуры развёртывания Hosted Engine на хосте (ранее он фигурировал в нашем описании как Pa$sw0rD ). В противном случае Engine может на запуститься. Значения в следующих паре вопросов я также оставил предложенные по умолчанию.
Далее последует вопрос о конфигурации PKI. Как я понял, в процессе установки oVirt разворачивает локальную службу сертификации и выдает из неё сертификаты для внутренних нужд компонент oVirt, в частности для защиты соединения с веб-порталами oVirt. Имя организации для сертификатов предлагается при этом взятое из доменной части FQDN-имени сервера Hosted Engine. Оставляем значение по умолчанию, так как менять его у нас особых причин нету.
В секции конфигурации Apache оставим предложенные по умолчанию значения вопросов о необходимости установки и автоматического запуска веб-сервера.
В секции SYSTEM CONFIGURATION нам будет задан вопрос хотим ли мы создать ISO Domain для oVirt на этой виртуальной машине. Утвердительно ответим на этот вопрос, так как ранее мы подготовили службу NFS-сервера в этой системе. Затем укажем путь к каталогу, который мы ранее подготовили под NFS-шару ( /var/nfs-ovirt-iso-share/files ) и установим разрешения на доступ к этой шаре. В нашем примере разрешается доступ на запись ( rw ) всем NFS-клиентам из нашей серверной подсети ( 10.1.0.0/24 ). Имя ISO domain можно задать любое или оставить предложенное (так оно будет отображаться в дальнейшем в консоли oVirt).
В сводной секции просмотрим все выбранные параметры развёртывания и нажмём Enter для запуска процесса установки oVirt Engine:
Дождёмся успешного выполнения всех основных этапов установки oVirt Engine:
В конечном итоге программа установки выведет URL-адрес веб-портала администрирования oVirt и имена лог-файла и файла ответов, который можно использовать при повторных попытках установки. Последнее сообщение говорит нам об успешном окончании процесса установки.
На данном этапе можно считать, что oVirt Engine установлен.
Процесс развертывания попросит нас выключить ОС в виртуальной машине с Engine. Выключаем виртуальный сервер, выполнив, например, команду poweroff
После этого процесс развёртывания oVirt Hosted Engine в screen-сессии на нашем первом хосте виртуализации ( KOM-AD01-VM31 ) будет автоматически завершён, а виртуальная машина Engine снова запустится.
Итак, процесс развёртывания oVirt Hosted Engine на первом хосте завершён и теперь нужно выполнить развёртывание ещё на одном хосте, чтобы сделать конфигурацию Engine высоко-доступной.
Развёртывание oVirt Hosted Engine на втором хосте
Для развёртывания мы будем использовать второй хост с именем KOM-AD01-VM32 с аналогичными настройками доступа к общим дискам на СХД и сетевой конфигурацией. Выполняем на хосте все те же предварительные настройки, что ранее делали на первом хосте (см.пункт «Подготовка хостов к развёртыванию oVirt Hosted Engine»).
После того, как хост подготовлен, выполняем установку пакета ovirt-hosted-engine-setup и запускаем развёртывание hosted-engine в screen-сессии:
Здесь снова нам нужно будет ответить на ряд вопросов. Сначала в разделе конфигурации хранилища выберем тот же диск на котором ранее мы развернули виртуальную машину Hosted Engine. Статус этого диска в этот раз будет отображаться как used.
Затем программа установки обнаружит на выбранном диске так называемый Data Domain и спросит, хотим ли мы присоединить данный хост к нему. Ответим утвердительно, а на следующий вопрос о присвоении идентификатора хоста Host ID оставим вычисленное автоматически предлагаемое значение – 2. Основную массу других параметров, которые мы задали для настройки Hosted Engine в процессе развёртывания первого хоста, программа установки считает из конфигурационного файла на диске с виртуальной машиной Hosted Engine.
Дале нам потребуется два раз ввести пароль учётной записи admin, который мы задали в процессе развертывания первого хоста и повторно использовали в процессе развёртывания oVirt Engine (ранее он фигурировал в нашем описании как Pa$sw0rD ). Затем введём имя нашего второго хоста, под которым этот хост будет отображаться в дальнейшем в веб-консоли oVirt и его полное доменное имя FQDN:
Далее будет выполнен процесс непосредственной настройки компонент oVirt на данном хосте с обновлением текущей конфигурации Hosted Engine. В конце мы должны получить сообщение об успешной установке Hosted Engine.
Теперь наш экземпляр oVirt Hosted Engine стал высоко-доступным, то есть при отключении хоста, на котором запущена виртуальная машина с Hosted Engine, будет происходить автоматический перезапуск виртуальной машины Hosted Engine на втором доступном хосте.
Портал администрирования oVirt Engine
Проверим доступ к основному инструменту администрирования инфраструктуры oVirt – веб-порталу. Для этого перейдём в веб-браузере по ссылке, которую мы получили ранее в завершении процесса развёртывания oVirt Engine на виртуальной машине. В нашем случае это:
https://kom-ad01-ovirt1.holding.com/ovirt-engine/
На данной стартовой веб-странице oVirt Engine мы сможем увидеть текущую версию oVirt Engine и ссылки на портал администрирования oVirt (Administration Portal) и пользовательский портал (User Portal). Для входа на портал администрирования нам потребуется ввести учётные данные учётной записи admin, пароль для которой мы задали ранее в процессе развертывания первого хоста (ранее он фигурировал в нашем описании как Pa$sw0rD ).
Перед нами появится сводная статусная информация о состоянии ключевых показателей нашей виртуализации oVirt на открывающейся по умолчанию закладке Dashboard.
Кстати, замечено, что в IE11 Dashboard иногда может не отображаться (бесконечный статус Loading…), при этом, например в Firefox или Chrome страница загружается сразу. Также могу отметить, что на десктопе Ubuntu 16.04 в Firefox веб-консоль периодически может подтормаживать, вызывая сильную нагрузку на процессор.
Послеустановочная модификация конфигурации multipathd
После чего заставить службу multipathd перечитать настройки:
А ещё лучше выполнить проверочную перезагрузку сервера, чтобы убедиться в том, что в процессе запуска системы и старта всех служб настроенная нами multipath-конфигурация работает штатно. Аналогичным образом нужно настроить конфигурационный файл на всех хостах, входящих в кластер oVirt и подключенных к дисковым ресурсам одной и той же СХД.
Ручной запуск ВМ Hosted Engine
В некоторых ситуациях может получиться так, что веб-интерфейс управления oVirt недоступен, так как виртуальная машина с oVirt Hosted Engine выключена (например ВМ была выключена непосредственно из гостевой ОС). В таком случае потребуется выполнить ручной запуск ВМ c Hosted Engine. Сделать это можно с помощью утилиты управления oVirt на любом из хостов, на которых были развёрнуты компоненты Hosted Engine. Для того, чтобы запустить виртуальную машину c oVirt Hosted Engine выполним на хосте команду:
Дополнительно, чтобы выяснить какие виртуальные машины выполняются на хосте, можно воспользоваться утилитой vdsClient:
Обратите внимание на то, что после запуска ВМ с Hosted Engine, веб-портал администрирования oVirt доступен не сразу, так как для требуется некоторое время на запуск необходимых веб-служб.
На данном этапе можно считать, что минимальные действия по развёртыванию инфраструктуры oVirt в конфигурации Hosted Engine выполнены, и теперь у нас есть базовый инструментарий для администрирования виртуальных машин на базе открытого гипервизора KVM. В следующей части мы рассмотрим процедуру замены цифрового сертификата, используемого для защиты HTTP соединений с порталами oVirt, чтобы избежать предупреждений безопасности веб-браузеров.
Дополнительные источники информации: