С этой записи я начну серию заметок о развёртывании и базовой настройке свободно распространяемой системы виртуализации oVirt версии 4.0 в конфигурации Hosted Engine с учётом тех граблей, по которым мне удалось походить. Но для начала пару слов о том, каким образом я пришёл к решению о необходимости развёртывания такого продукта, как oVirt.
Моя практика использования виртуальных машин на базе Linux, в доступной мне среде виртуализации на базе Microsoft Hyper-V, показала, что стабильность работы таких гостевых систем в некоторых сценариях, мягко говоря, оставляет желать лучшего. Например, неоднократно были замечены проблемы с некоторыми версиями RHEL, Ubuntu, Debian, когда банальная перезагрузка гостевой системы приводила к невозможности последующей загрузки ОС, или чехарда с компонентами интеграции. Некоторые проблемы вытекают из нестабильной работы всё тех же компонент интеграции, например, во время горячего резервного копирования виртуальных машин c Ubuntu из System Center DPM, shadow copy провайдер внутри ВМ порой делает что-то такое, после чего файловая система ext4 на каком-нибудь из дисков переходит в режим Read Only и, как следствие, сервисы внутри гостевой системы ломаются. При этом я ничего плохого не хочу сказать про Hyper-V, как про платформу виртуализации, ведь все ОС от Microsoft работают в Hyper-V вполне достойно. Что же касается Linux-систем, то проблема, на мой взгляд, заключается в том, что, на самом деле, Microsoft не уделяет должного внимания вопросу контроля за средствами интеграции Hyper-V с операционными средами, отличными от Windows. Видимо для этих ребят гораздо важней заявить миру о том, что теперь PowerShell можно запустить в Linux, а bash теперь работает в Windows. В общем по личному опыту, пока у меня есть устоявшееся мнение о том, что Hyper-V, как гипервизор, не может претендовать на звание решения для гетерогенных сред. Вы скажете, есть же VMware! Но к полноценной среде виртуализации от VMware с поддержкой кластеризации и прочих "плюшек" у меня доступа нет, поэтому про эту платформу я сказать не могу ничего. В общем, исходя из соображений того, что с виртуальными Linux-системами, так как я живу, жить больше нельзя, я начал своё движение в сторону изучения средств виртуализации серверов в мире открытых и свободно-распространяемых систем. Перечитав кучу разных "холиваров" на тему выбора лучшего средства управления гипервизором KVM, как наиболее популярным средством программной виртуализации для Linux-систем, меня заинтересовали два решения – это Proxmox VE и oVirt. Исходя из информации, доступной в открытых источниках, я сравнил функциональные возможности обоих продуктов и пришёл к выводу, что oVirt имеет больше перспектив развития, так как по сути является более масштабируемым решением, чем Proxmox VE. Несмотря на некоторые свои явные недостатки с точки зрения "юзабилити", например отсутствие бэкапа виртуальных машин штатными средствами администрирования (чего не скажешь о Proxmox), oVirt мне показался более интересным в том плане, что он является upstream-решением для платформы виртуализации Red Hat Enterprise Virtualization (RHEV). А как известно, компания Qumranet, в недрах которой родилась технология KVM, в 2008 году была куплена именно компанией Red Hat. Поэтому кто, как не ребята из Red Hat, "умеют правильно готовить" обвязку для KVM.
Итак, 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 собрана на Вики-странице oVirt Architecture. Здесь я постарался в одной схеме собрать информацию из разных схем:
Дополнительную информацию по архитектуре oVirt можно найти и в других источниках, например не будет лишним просмотреть презентацию Yaniv Bronhaim (Red Hat Senior Software Engineer) - March 2016 The oVirt Way General Product Overview. О назначении основных компонент архитектуры неплохо расписал на русском языке в своём блоге Александр Руденко.
План развёртывания oVirt Hosted Engine
Для развёртывания oVirt версии 4.0 в конфигурации Hosted Engine в качестве опорного руководства будем использовать oVirt Hosted Engine Howto. Перед тем, как приступить к процедуре развёртывания, для лучшего понимания последовательности этапов развёртывания, посмотрим на очень наглядную, на мой взгляд, схему из презентации Simone Tiraboschi (Software Engineer, Red Hat):
Видео, где Simone сам комментирует свою презентацию, можно найти здесь: oVirt self-hosted engine seamless deployment by Simone Tiraboschi
Кстати в этой же презентации Simone представляет нам и альтернативные варианты развёртывания oVirt, в том числе, применительно к варианту Hosted Engine, в презентации уделяется внимание такому варианту развёртывания, как oVirt Hosted Engine Appliance. Слайд презентации также наглядно показывает нам то, что данный вариант с готовой виртуальной машиной oVirt Hosted Engine в виде Appliance может сократить количество этапов развёртывания Hosted Engine и выглядит более привлекательно с точки зрения ускорения процесса развёртывания.
Однако меня несколько смутил тот факт, что rpm-пакеты, необходимые для такого варианта развёртывания, постоянно пересобираются и доступны для загрузки в виде последней успешной сборки. К тому же, мне хотелось самостоятельно установить ОС внутрь виртуальной машины Hosted Engine так, как мне это нужно, контролируя процесс происходящего, а не получать уже готовую, кем-то и как-то сконфигурированную, Linux-систему. Поэтому я остановился на варианте развёртывания из первого слайда, и далее в этой статье будут последовательно рассмотрены все этапы такого развёртывания.
Подготовка хостов к развёртыванию oVirt Hosted Engine
Нам потребуется подготовить 2 физических сервера с ОС CentOS Linux 7.2 под будущие хосты виртуализации. В моём случае используется два "олд-скульных" сервера HP ProLiant DL360 G5 одинаковой аппаратной конфигурации (особенности установки CentOS 7 на такой сервер описывались ранее) :
- 2 Quad-Core процессора Intel Xeon X5460 3.16GHz (c поддержкой Intel Virtualization Technology (VT-x))
- 2 встроенных сетевых адаптера NC373i Multifunction Gigabit Server Adapter, объединённых в LACP Bond для агрегации пропускной способности и повышения доступности.
- двух-портовый FC HBA (HP FC1242SR / HP FC2242SR), подключённый к SAN.
С СХД каждому из хостов презентовано (с использованием multipath) общее хранилище через FC SAN в виде двух дисков. Один выделенный диск - под виртуальную машину oVirt Hosted Engine, второй - под все остальные виртуальные машины будущего кластера oVirt.
Хосты будут иметь имена KOM-AD01-VM31 и KOM-AD01-VM32. В процессе развёртывания oVirt нами будет создана виртуальная машина с именем KOM-AD01-OVIRT1, так же с ОС CentOS Linux 7.2
Проверяем на обоих хостах наличие поддержки виртуализации на процессоре сервера, например, утилитой lscpu:
Другой вариант, посмотреть вывод команды:
# cat /proc/cpuinfo
Среди флагов процессора должен присутствовать флаг vmx (для процессоров Intel), либо флаг svm (для процессоров AMD).
Поддержка есть, двигаемся дальше.
***
Останавливаем и отключаем службу NetworkManager, так как oVirt берёт на себя управление сетевыми профилями в системе. Когда я пробовал выполнять развёртывание oVirt 3.6, с запущенной службой NetworkManager, oVirt попросту не устанавливался. В oVirt 4.0 ситуация изменилась, и теперь процесс установки работает с запущенной службой NetworkManager, однако я предпочёл всё же отключить и остановить данную службу и сейчас:
# systemctl stop NetworkManager
# systemctl disable NetworkManager
Чтобы избежать граблей описанных в баге Red Hat Bugzilla – Bug 1160423 - hosted-engine --deploy doesn't copy DNS config to ovirtmgmt, задействуем использование в качестве основного источника настроек DNS клиента файл resolv.conf
# cat /etc/resolv.conf
nameserver 10.1.0.9
nameserver 10.1.6.8
search holding.com
В файлах, описывающих сетевые интерфейсы (/etc/sysconfig/network-scripts/ifcfg*), уберём значения параметров DNS, там где они указаны в явном виде (удалим параметры DNS1,DNS2 и т.д.) и добавим параметр PEERDNS=no. Например, в моём случае, конфигурационный файл интерфейса управления (vlan-интерфейс поверх bond-интерфейса), через который я подключаюсь к серверу выглядит следующим образом:
# cat /etc/sysconfig/network-scripts/ifcfg-bond0.4
TYPE=Vlan
VLAN_ID=4
DEVICE=bond0.4
NAME=bond0-vlan4
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
VLAN=yes
MTU=1500
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
IPADDR=10.1.0.231
PREFIX=24
GATEWAY=10.1.0.1
PEERDNS=no
DOMAIN=holding.com
<
p align="center">***
Далее. Если ранее на сервере была полностью отключена поддержка ipv6, то, как минимум, потребуется её включить в явном виде для интерфейсов lo и ovirtmgmt (будет создан в системе дальнейшем с процессе развёртывания oVirt) . Это нужно, чтобы процесс установки смог подключиться к службе vdsm (это грабли версии 4.0, которые мусолились в ветке [ovirt-users] oVirt 4 Hosted Engine deploy on fc storage - [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 101] Network is unreachable и по информации Bug 1350883 были пофиксены в версии 4.0.2)
Добавим в системный конфигурационный файл /etc/sysctl.conf пару строчек:
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 0 net.ipv6.conf.ovirtmgmt.disable_ipv6 = 0
Чтобы сразу задействовать включение ipv6, например на интерфейсе lo, можно сделать так:
# cat /proc/sys/net/ipv6/conf/lo/disable_ipv6
1
# echo 0 > /proc/sys/net/ipv6/conf/lo/disable_ipv6
# cat /proc/sys/net/ipv6/conf/lo/disable_ipv6
0
После проделанных изменений перезагрузим сервер и проверим, чтобы на Loopback-интерфейсе был назначен адрес ipv6 ::1
# ip addr show lo
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
***
Добавляем информацию о репозитории oVirt и Epel. Это обязательный шаг.
# yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm # yum -y install epel-release
Развёртывание oVirt Hosted Engine на первом хосте
Загружаем минимальный установочный образ CentOS 7 во временную папку на первом хосте (KOM-AD01-VM31), который мы будем использовать для развёртывания oVirt. Этот образ потребуется нам в дальнейшем для установки виртуальной машины с oVirt Hosted Engine:
# wget http://mirror.yandex.ru/centos/7/isos/x86_64/CentOS-7-x86_64-NetInstall-1511.iso -P /tmp/
Репозитории oVirt и Epel уже были подключены ранее на этапе подготовки хоста. Устанавливаем пакеты, необходимые для развёртывания oVirt Hosted Engine:
# yum install ovirt-hosted-engine-setup
В процессе установки в систему дополнительно будет установлено более трёхсот пакетов-зависимостей.
Дополнительно установим утилиту screen:
# yum install screen
Перед запуском процедуры развёртывания запустим утилиту screen, как это рекомендует онлайн-руководство, создав screen-сессию и подключившись к ней.
# screen -RD
В screen-сессии запускаем процедуру развёртывания oVirt Hosted Engine:
# hosted-engine --deploy
В процессе развёртывания будет задан ряд вопросов, на которые мы должны ответить. На первый вопрос о том, что мы действительно хотим сделать из данного сервера хост виртуализации и после этого создать виртуальную машину для развёртывания Hosted Engine, отвечаем утвердительно (можно просто Enter, так как в фигурных скобках отражается предлагаемый по умолчанию ответ):
Конфигурация хранилища для виртуальной машины Hosted Engine
На начальном этапе развёртывания нас спросят о том, какой тип хранилища мы будем использовать для размещения файлов виртуальной машины с oVirt Hosted Engine. В нашем случае выбран тип хранилища - fc
Следующим шагом, программа установки опросит систему на предмет доступных для сервера хранилищ выбранного типа и выдаст перечень возможных вариантов. Выбираем LUN, в который будет размещена виртуальная машина с Hosted Engine. Чтобы LUN можно было использовать для первичного развёртывания oVirt, он не должен содержать никаких разделов (должен иметь статус free):
Конфигурация сети хоста для создания bridge-интерфейса
Следующий этап - конфигурация сети. Выбираем тот интерфейс, у которого есть фактическая привязка к сети. Как я уже ранее сказал, в нашем случае используется Bond-интерфейс bond0, поверх которого создан тегированный VLAN-интерфейс bond0.4. С этого интерфейса должен быть доступен указанный далее IP-адрес шлюза (в противном случае установка завершится ошибкой). На базе указанного интерфейса в процессе развёртывания будет создан bridge-интерфейс с именем ovirtmgmt, к которому в свою очередь будет выполнена привязка виртуального сетевого адаптера виртуальной машины Hosted Engine.
На вопрос об автоматической настройке брандмауэра отвечаем утвердительно, чтобы скрипты установки создали нужные для функционирования oVirt правила в iptables и firewalld
Конфигурация виртуальной машины для роли Hosted Engine
Следующий этап – задание параметров будущей виртуальной машины Hosted Engine.
- Сначала нужно указать источник загрузки дистрибутива Linux, который будет использоваться в процессе установки ОС внутрь виртуальной машины Hosted Engine. Так, как мы планируем установку ОС с ранее загруженного ISO-образа, выбираем виртуальны привод - cdrom.
- Затем нужно выбрать протокол подключения к консоли ВМ – оставляю предлагаемый по умолчанию vnc.
- Затем нас спросят о том, какого типа процессоры должны использоваться для ВМ – оставляю предлагаемый по умолчанию тип model_Penryn (у вас он может быть другим в зависимости от физических процессоров хоста).
- Количество виртуальных процессоров - минимум 2.
- Размер диска ВМ в большинстве случаев тоже можно оставить предлагаемый по умолчанию (25 GB). Однако в нашем примере, мы сделаем размер больше предлагаемого, так как на этой ВМ мы в дальнейшем сделаем NFS-шару, на которой будут размещаться ISO-образы, которые в случае необходимости будут монтироваться на виртуальные машины (oVirt ISO Domain) – 40 GB
- Адрес MAC для виртуальной сетевой карты оставляем сгенерированный автоматически.
- Размер оперативной памяти ВМ оставляем предлагаемый минимум 4096 MB. При необходимости позже его можно будет изменить. Рекомендуемым значением при этом является 16 GB.
- В конце задаём путь к ранее загруженному ISO-образу установочного диска CentOS 7.
Конфигурация Hosted Engine.
Следующий этап – задание параметров, относящихся к работе Hosted Engine.
- Укажем пароль для пользователя admin. Пароль, который зададим здесь, будет в дальнейшем использоваться для доступа к порталу администрирования oVirt (чтобы в дальнейшем не запутаться, для примера, будем считать что этот пароль у нас Pa$sw0rD). Этот же пароль нам потребуется ввести в дальнейшем в процессе развёртывания управляющего ПО в виртуальной машине для oVirt Engine. Пароль вводим два раза.
- Укажем имя хоста, с которого производится установка виртуальной машины. В нашем случае это хост KOM-AD01-VM31.
- Укажем полное доменное имя для виртуального сервера Hosted Engine. В нашем случае это хост KOM-AD01-OVIRT1.holding.com.
- Укажем адрес и порт почтового сервера SMTP, на который будут отправляться почтовые уведомления. По умолчанию в этих полях установлен вариант localhost и порт 25. Чтобы такая конфигурация работала, можно в дальнейшем будет настроить локальную службу SMTP-сервера, например так, как это описано в здесь. Я выбрал другой вариант – сразу указал адрес корпоративного почтового SMTP сервера.
- В конце укажем e-mail адрес отправителя и адрес получателя уведомлений (в моём случае это адрес группы рассылку в которую входят администраторы oVirt).
Установка на хост компонент 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 7.2. Пример установки рассматривался ранее. Отличие этой установки в том, что она несколько проще, так как сейчас не потребуется дополнительных действий с подгрузкой драйверов.
В моём случае для установки CentOS был выбран NetInstall-дистрибутив, который подразумевает загрузку необходимых для установки ОС пакетов из онлайн-репозитория CentOS. Поэтому нам придётся дополнительно его прописать в разделе установщика INSTALLATION SOURCE
Добавим онлайн-репозиторий для CentOS 7 64-bit:
http://mirror.centos.org/centos/7/os/x86_64/
При этом не забываем указать данные прокси сервера, если он используется:
Разделы диска я оставил предложенные режимом автоматической разметки, только отказался от использования 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 для доступа к нашему виртуальному серверу.
В гостевой ОС обновим все пакеты, отключим при необходимости поддержку IPv6 и выполним прочие пост-установочные процедуры, некоторые из которых рассматривались ранее.
После этого нам желательно будет перезагрузить ОС внутри виртуальной машины. Для этого внутри виртуальной машины вызовем команду 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:
# yum install nfs-utils
Проверяем наличие каталога, который мы указали в процессе установки ОС:
# ls -la /var/nfs-ovirt-iso-share/
total 24
drwxr-xr-x. 3 root root 4096 Jul 26 15:55 .
drwxr-xr-x. 20 root root 4096 Jul 26 15:52 ..
drwx------. 2 root root 16384 Jul 26 15:15 lost+found
Создаём каталог под общую сетевую папку и выставляем на него разрешения (36:36 это UID/GID vdsm:kvm) в соответствии с документом oVirt - Troubleshooting NFS Storage Issues:
# mkdir -p /var/nfs-ovirt-iso-share/files
# chown 36:36 /var/nfs-ovirt-iso-share/files
# chmod -R 755 /var/nfs-ovirt-iso-share/files
Запускаем службы NFS и включаем их автозагрузку:
# systemctl start rpcbind
# systemctl start nfs-server
# systemctl enable rpcbind
# systemctl enable nfs-server
Включаем разрешающие правила брандмауэра firewalld для возможности удалённого подключения к NFS-серверу:
# firewall-cmd --permanent --zone=public --add-service=nfs
# firewall-cmd --permanent --zone=public --add-service=mountd
# firewall-cmd --permanent --zone=public --add-service=rpc-bind
# firewall-cmd --reload
Теперь можно переходить к развёртыванию управляющих пакетов oVirt Engine на гостевую ОС внутри нашей виртуальной машины.
Установка компонент oVirt Engine в гостевой ОС виртуальной машины
Добавляем информацию о репозиториях oVirt и Epel, а затем сразу выполняем установку и запуск развёртывания управляющих компонент oVirt Engine:
# yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release40.rpm # yum install epel-release # yum install ovirt-engine # engine-setup
Будет запущен мастер развёртывания компонент 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).
В следующей секции нас попросят выбрать режим хранения сведений в исторической базе данных Data Warehouse. Чтобы понять различие между двумя предложенными вариантами можно заглянуть в документ Red Hat Virtualization 4.0 - Data Warehouse Guide. Так как мы устанавливаем базу данных DWH на том же сервере, где будет работать и оперативная база данных oVirt и даже сами компоненты oVirt Engine, рекомендуемым вариантом будет использование упрощённого формата хранения исторических данных (Basic), которые, к слову, используются при построении отчётов. А на тему развёртывания и настройки отчётности в oVirt мы поговорим отдельно в одной из следующих частей цикла заметок о развёртывании oVirt.
В сводной секции просмотрим все выбранные параметры развёртывания и нажмём Enter для запуска процесса установки oVirt Engine:
Дождёмся успешного выполнения всех основных этапов установки oVirt Engine:
В конечном итоге программа установки выведет URL-адрес веб-портала администрирования oVirt и имена лог-файла и файла ответов, который можно использовать при повторных попытках установки. Последнее сообщение говорит нам об успешном окончании процесса установки.
На данном этапе можно считать, что oVirt Engine установлен.
Теперь перебираемся в screen-сессию на наш первый хост виртуализации (KOM-AD01-VM31), где ранее была запущена процедура развёртывания oVirt Hosted Engine и в ожидающем ответа меню выбираем пункт (1) Continue setup … , подтверждая тем самым факт того, что компоненты 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-сессии:
# yum install ovirt-hosted-engine-setup screen -y
# screen -RD
# hosted-engine --deploy
Здесь снова нам нужно будет ответить на ряд вопросов. Сначала в разделе конфигурации хранилища выберем тот же диск на котором ранее мы развернули виртуальную машину 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
Если в процессе подготовки физических серверов под хосты oVirt ранее использовалась настройка multipath-подключений к СХД, то нужно учесть тот факт, что в процессе развёртывания компонент oVirt на эти серверы происходит модификация конфигурационного файла /etc/multipath.conf. При этом простая обратная правка этого файла не имеет смысла, так как управляющий код VDSM всё равно будет переписывать содержимое этого файла. Причём в прежних версиях oVirt такая ситуация имела безусловный характер (Red Hat Bugzilla - Bug 1076531 - vdsm overwrites multipath.conf at every startup if vdsm installed file was replaced). По началу такая ситуация меня несколько смутила, но задав вопрос в официальной мейл-группе oVirt, я достаточно оперативно получил информацию о возможном варианте решения этой проблемы. Вообще инженер Red Hat дал понять то, что без веских на то причин, модификация файла multipath.conf в сторону отклонения от варианта генерируемого VDSM - не самая лучшая идея. Если же всё же вы решили что в multipath.conf должны быть ваши настройки, то для того, чтобы VDSM не изменял контент файла после ваших правок, во второй строке файла (сразу после строки типа # VDSM REVISION 1.3) нужно добавить строку # VDSM PRIVATE, то есть начало файла должно выглядеть следующим образом:
# VDSM REVISION 1.3
# VDSM PRIVATE
...
После чего заставить службу multipathd перечитать настройки:
# systemctl reload multipathd
А ещё лучше выполнить проверочную перезагрузку сервера, чтобы убедиться в том, что в процессе запуска системы и старта всех служб настроенная нами multipath-конфигурация работает штатно. Аналогичным образом нужно настроить конфигурационный файл на всех хостах, входящих в кластер oVirt и подключенных к дисковым ресурсам одной и той же СХД.
Ручной запуск ВМ Hosted Engine
В некоторых ситуациях может получиться так, что веб-интерфейс управления oVirt недоступен, так как виртуальная машина с oVirt Hosted Engine выключена (например ВМ была выключена непосредственно из гостевой ОС). В таком случае потребуется выполнить ручной запуск ВМ c Hosted Engine. Сделать это можно с помощью утилиты управления oVirt на любом из хостов, на которых были развёрнуты компоненты Hosted Engine. Для того, чтобы запустить виртуальную машину c oVirt Hosted Engine выполним на хосте команду:
# hosted-engine --vm-start
Дополнительно, чтобы выяснить какие виртуальные машины выполняются на хосте, можно воспользоваться утилитой vdsClient:
# vdsClient -s 127.0.0.1 list table
661bafca-e9c3-4191-99b4-285ff8553488 30897 KOM-AD01-TEST1 Up 10.1.0.25
3c5cfc11-9af1-4e68-89b8-101c2b005832 13331 HostedEngine Down
Как видим, на данном хосте в текущий момент времени хостится две виртуальных машины - KOM-AD01-TEST1 (запущена) и HostedEngine (выключена). Посмотреть статус виртуальных машин на другом хосте можно указав имя хоста в ключе -s.
Обратите внимание на то, что после запуска ВМ с Hosted Engine, веб-портал администрирования oVirt доступен не сразу, так как для требуется некоторое время на запуск необходимых веб-служб.
***
На данном этапе можно считать, что минимальные действия по развёртыванию инфраструктуры oVirt в конфигурации Hosted Engine выполнены, и теперь у нас есть базовый инструментарий для администрирования виртуальных машин на базе открытого гипервизора KVM. В следующей части мы рассмотрим процедуру замены цифрового сертификата, используемого для защиты HTTP соединений с порталами oVirt, чтобы избежать предупреждений безопасности веб-браузеров.
Дополнительные источники информации:
- oVirt Documentation - Hosted Engine Howto
- Red Hat Enterprise Virtualization 3.6 - Self-Hosted Engine Guide
- iVirt-it.ru – oVirt
- Евгений Деревянкин - oVirt - часть 8 - Hosted Engine (видео)
- Ben Draper Blog - Installing oVirt 3.5 on CentOS 7 (Hosted Engine)
- Red Hat Open Source Community Blog - Up and Running with oVirt 3.5, Part Two
- GitHub - andrewklau - oVIrt Engine + VDSM iptables rules & [ovirt-users] firewalld rules for engine
RSS - Записи
Алексей, а можно поподробнее что за сценарии, при которых ВМ на Linux на Hyper-V не стабильна (про DPM понятно)?
Приведённый пример эксплуатации Linux-систем на Hyper-V приводящий с абсолютно непредсказуемым остановкам работы сервисов внутри ВМ - это не достаточно красочный пример?? И проблема тут даже не в DPM, проблема в том, как работают компоненты интеграции. Попробуйте завести на Hyper-V какую-нибудь старую версию Red Hat, да ещё и в 32-битном варианте. На ВМ gen2 такая система у вас попросту не взлетит, а на ВМ gen1 такие системы могут попросту "сдохнуть" от банальной перезагрузки гостевой ОС (пример с тем же Debian упоминался мной ранее).
У меня был такой пример, были настроены скрипты, которые делали backup MYSQL. После выполнения скриптов файловая система переходила в режим Read Only. В интернете предлагается решение, но нам оно не помогло.
фс переходит в read only при ошибке IO, т.е. не получилось читать или писать в диск. Так что я бы смотрел на проблемы с производительностью или просто с дисковой подсистемой гипервизора или эмулятора дисковых контроллеров
В моём случае на тех же стораджах и тех же хостах виртуальные машины на базе Windows работают без подобных фокусов, так что тут имеет место быть именно проблема с компонентами интеграции Hyper-V.
windows при ошибках IO ругается на нехватку места на диске, это еще со времен DOS такой веселый прикол. Но да, проблема может быть и в компонентах интеграции, хотя я бы поставил на дисковый стек виртуализации, т.е. драйвер диск-контроллера в госте или систему эмуляции/паравиртуализации дискового контроллера в гипервизоре.
Кстати, в QEMU/KVM есть еще один механизм защиты от проблем с IO, если сам QEMU не смог выполнить IO машины на физ. сторадже, машина останавливатеся в режим pause, чтоб заморозить весь in flight io и не потерять его из-за проблем с доступом к физ. дискам. Отвалился fc fabric например, машина сразу на паузе. Починили доступ к SAN, сняли с паузы, и как будто ничего и не случилось.
VMW добавили такую фичу только в 2012, с большой помпой выдавая ее за новую мегаразработку и назвав vmstun, емнип, но не запатентовали, так как QEMU это умеет чуть ли не с первых дней своего существования
Обратная ссылка: Развёртывание и настройка oVirt 4.0. Часть 2. Замена сертификата веб-сервера oVirt Engine | Блог IT-KB /
Интересно, как Microsoft борется с проблемами нестабильности linux в Azure. Они же что-то на базе Hyper-V там используют?
А про нестабильность Linux в Azure здесь вроде бы никто и не говорил.
ну да, речь шла о нестабильности Linux под Hyper-V, Azure тоже использует Hyper-V, следовательно, можно ожидать похожих проблем?
Не могу знать. Не работал с Azure.
Алексей, а что можете сказать про сравнение oVirt и Nutanix Community Edition?
Планируете ли или используете ли SELinux или AppArmor или может аналог для виртуализации?
Про сравнение ничего сказать не могу. Не имел дела с Nutanix. По поводу SELinux, вообще я думал, что это дополнительный механизм защиты исполнения процессов в системе, поэтому вопрос применительно к виртуализации мне не понятен.
А виртуализация это не процесс? :) На мой взгляд виртуализацию первым делом нужно защищать всеми силами, отсюда и вопрос "какими средствами вы защищаете хосты виртуализации? Наверняка и там есть свои особенности."
oVirt/RHV/RHEV используют SELinux и sVirt (это специальное расширение SELinux для kvm) из коробки, ничего делать не надо, просто не трогать готовые настройки
Ого, вот тут конечно он впереди планеты всей. Порадовал.
Вопрос может не по теме или может на будущее:
Имею тоже DL380G5 c процами 51xx. Ovirt 4 ими рулит. Хосты активируются только если в настройках кластера выбран процессор Conroe. Проблема с запуском OS Windows начиная с версии 2012. Создаю VM и параметр Operating System выставляю Win2012R2 - при сохранении имею ругань такого типа "The guest OS doesn't support the following CPUs: opteron_g1, conroe. Its possible to change the cluster cpu or set a different one per VM". Единственное как получилось запустить виртуалку это в свойствах машины в разделе хоста поставив опцию Pass-Through Host CPU отключив миграцию. Как сделать что бы и миграция работала и процессор адекватный был (Не Conroe)?
В данный момент я рассматриваю oVirt в качестве платформы виртуализации Linux-систем, к тому же я в самом начале пути. Поэтому, по крайней мере сейчас, не имею ответа на вопрос такого рода. Вы можете задать любой вопрос по oVirt в их официальную мейл-группу http://lists.ovirt.org/mailman/listinfo/users
Там достаточно оперативно на вопросы отвечают технические специалисты из Red Hat, то есть те люди, у которых самый максимальный опыт в этом деле :)
Windows 2012/8.1 и выше требуют определенных фичеров процессора которые не существуют на таких старых моделях как Conroe или G1. Или апгрейд процессора, или ставьте более старую винду
1. "Затем нас спросят о том, какого типа процессоры". Тут бы к месту была ссылочка какие типы можно выбрать. Я правильно понимаю, это для уравнивания процессерных инструкций вм (забыл как в vmeare называется, чет вылетело из головы)?
2. "отказался от использования LVM и заменил файловую систему на ext4.". А почему именнно так?
3. "# chmod -R 777 /var/nfs-ovirt-iso-share". А зачем 777, это действительно так необходимо?
1." Тут бы к месту...". Без комментариев
2. "А почему именнно так?". Потому что я так захотел.
3. Возможно для корректной работы ISO Domain хватит и меньших привилегий, но я этого не проверял.
"Hosted Engine. Если мы не знаем на каком из хостов выполнялась виртуальная машина в момент её выключения"
Странное поведение, разве не для того мы кластерилизовали ее, что бы она могла запуститься на любом хосте? Тем более, что ВМ Hosted Engine быда предварительно корректно выключена.
Спасибо за труды и ответы.
Стоит только начать работу с oVirt. Через некоторое время много что может показаться странным. oVirt не "вылизан" так, как его коммерческие аналоги типа SCVMM и я про это говорил в самом начале. Теперь я понимаю, что браться за продуктивное внедрение такой штуки может только человек с устойчивой психикой.
:)
другой продукт это всегда другой подход и другие парадигмы. Зациклившись на ином, всегда тяжелее их понять. Мне вот на vmware постоянно хочется пойти и пооткрывать им баги
Что именно странно? то что машина может быть выключена специально, без того чтоб система ее все время пыталась запустить? Есть штатные ситуации когда это на самом деле нужно. А включение хостов в список доступных для HE это тоже вполне нормально, не всегда я хотел бы чтоб настолько критичная машина работала во всем кластере, зачастую полезно ограничить ее, особенно в больших установках (кластер oVirt расширяется до сотен хостов, в отличии от vmware)
Dan, спасибо за комментарии. Только Вы не ругайтесь :). Лично я только осваиваюсь в oVirt, поэтому на некоторые вопросы не могу вполне внятно отвечать. В таких случаях я стараюсь честно об этом говорить, чтобы не вводить людей в заблуждение. А от Вас, как от специалиста, который "в теме", ждём конструктивных замечаний, желательно без эмоций :) Если у Вас есть желание и силы, то можно организовать у нас на форуме раздел для вопросов по oVirt, где Вы выступите на правах модератора. Что скажете?
Отвечаю тут, т.к. ниже почему то нет "reply". Никаких эмоций я все написал четко по делу :) отвечать на вопросы могу и дальше, по мере возможности. "У нас на форуме" это где? А то я уже этим занимаюсь на petri, serverfault, linuxquestions, redhat-club.org, daniweb и еще на кучке ресурсов. Я не против, если время найдется
Ссылка на форум в шапке. Насколько я понимаю, на перечисленных ресурсах публика в основном англоговорящая, а у нас основная аудитория - это русскоязычные. Ресурсов по oVirt в рунете не так много, поэтому было бы неплохо развивать это направление по мере наших скромных возможностей. Разумеется все понимают, что ответы будут по мере возможности, здесь же у нас всё-таки не платная служба технической поддержки Red Hat, всё на общественных началах :)
Ага, ссылку уже увидел, в принципе никаких проблем, постараюсь помочь.
Спасибо!
1. а мне вот, на пример, ничего не хочется делать в vmvare, потомучто что бы я не сделал, все работает, бекапится и запускается без проблем.
2. Меня удивило, то что для запуска HE мне зачем-то нужно знать на каком хосте она лежит и запускать именно с него, а не с любого из тех, на котором она лежит.
3. Ограничения на каких хостах работать, куда мигрировать и т. д. в vmware тоже прекрасно работает, не спорю вещь нужная.
4. кластер vmware тоже расширяется нехило, зачастую его ограничения утыкаются в хранилища сетевые и рекомендации, которые неиозначают, что кластер не будет работать. И не вижу большого смысла в таких здоровенных кластерах, вот еслибы это был суперкомпютер другое дело.
А теперь само главное :)
Мне бы не хотелось бы поднимать здесь или в каком-то другом месте холивар на тему что лучше vmware или ovirt. Но я бы судовольствием почитал ваши коментарии как знающего человека. На пример как ваш клмент выше или ниже :) С удовольствием даже почитаю ваш комент по поводу моего пункта 2! :)
> 1. а мне вот, на пример, ничего не хочется делать в vmvare, потомучто что бы я не сделал, все
> работает, бекапится и запускается без проблем.
Ничего, с опытом все прийдет :)
> 2. Меня удивило, то что для запуска HE мне зачем-то нужно знать на каком хосте она лежит и
> запускать именно с него, а не с любого из тех, на котором она лежит.
Странно, это совесем не нужно. В тексте именно так написано?
> 4. кластер vmware тоже расширяется нехило, зачастую его ограничения утыкаются в хранилища
> сетевые и рекомендации, которые неиозначают, что кластер не будет работать. И не вижу
> большого смысла в таких здоровенных кластерах, вот еслибы это был суперкомпютер другое
> дело.
нехило это 32 хоста? Даже не смешно ведь. Смысл больших кластеров не в комбинированной вычислительной мощности, а в большом migration domain, т.е. большой пул из машин способных поднять определенную VM. Сейчас, с микросервисами с одной стороны и VDI с другой, количество VM зашкаливает за пятизначные цифры, и размазывать их между многими кластерами практически означает еще один уровень определения для машины, что очень сильно усложняет вообще все.
> Мне бы не хотелось бы поднимать здесь или в каком-то другом месте холивар на тему что
> лучше vmware или ovirt. Но я бы судовольствием почитал ваши коментарии как знающего
> человека. На пример как ваш клмент выше или ниже :) С удовольствием даже почитаю ваш
> комент по поводу моего пункта 2! :)
Холивар не нужен, просто сравнивается дорогой поддерживаемый продукт, с бесплатным опенсорсом. В этом плане стоимость позволяет очень быстро забыть все недоработки или непонимания. А если сравнивать с поддерживаемым RHV, то все вообще становится весело. Но этим пусть занимаются те кому за это платят зарплату, я с той работы уже несколько лет как ушел :)
По п.2 действительно была неверная формулировка предложения, вводящая в заблуждение. Поправил.
4. Cluster and Resource Pool Maximums ESXi - 64 хоста, 8000 vm. Я к этой цифре даже рядом не стоял.
Вот как раз для сравнения я и читаю эту серию интереснейших статей. Обычно два пути. Выбрать платный софт, поддержку и съэкономить на кол-ве людей и трудозатратах, соответственно. Дибо бесплатный и нанять человека который будет пилить, следить и траблшутить, в общем тратить на это свое время. У меня лично третий вариант - ни на соыт ни на людей тратиться компания не хочет, а вешать на себя еще один не слабый момент я на себя не хочу, мне и так не хватает 24 в сутках :).
"Но этим пусть занимаются те кому за это платят зарплату, я с той работы уже несколько лет как ушел :)"
Я не понял в чем кокретно заключалась работа. О чем речь :) ?
Кто-то стоял, кто-то нет, смысл тут не в размерах даже в том что под капотом. Ограничения на размер кластера наложены в VMW тем, что используется vmfs, кластерная файловая система использующая scsi-3PR для разграничения локов. Это гигантский костыль, и я уверен что при разговоре со спецом по вмвари он скажет что лучше до 64 дело не доводить. oVirt/RHV не используют PR вообще, и поэтому ограничения просто нет. 200 хостов это то что было официально проверено под очень мощными нагрузками, но никто не запрещает ставить больше. А вот затыков с метадата-операциями на датасторе просто не будет, так как локи не ограничены изначально протоколом scsi3
Ну тут затык не в vmvare и vmfs, а больше именно в scsi очереди в 32. vmfs это следствие. Я писал ранее, что основным ограничением размера кластера у вари являются хранилища.
НО никто не заприщает использовать NFS, именно так я и делаю. 64 хоста это также проверенная и гарантированная конфигурация.
Не вижу смысла продолжать здесь дискусия по поводу vmware. Лючше раскажите побольше про ovirt. А еще лучше про свой опыт, но я думаю для этого было бы лучше отдельную статейку накатать, т. к. форум все таки не тот формат, потом лазить искать на какой странице что и собирать это воедино.
Опыт у меня с ним самый непосредственный - занимался поддержкой этой системы еще с тех пор как она называлась SolidIce и не принадлежала Red Hat. Ставил, поддерживал, патчил, писал расширения и хотфиксы, потом управлял разработкой некоторых ее аспектов как продакт-манагер. Потом ушел, по личным причинам, из фирмы и проекта. Так что с технической т.з. я очень много и глубоко знаю, но рассказов не пишу, не умею я это дело. Если есть конкретные вопросы - постараюсь ответить
Сейчас пересоздал ISO Domain. При наличии прав отличных от 777 NFS-шара просто не подключается в oVirt
Спасибо. +1 к странностям oVirt :)
в документации написано - нужно chown -R 36:36 на директорию, а не 777
Всё верно. Права должны быть минимум 755 vdsm:kvm (36:36). Проверил на практике и исправил по тексту.
Обратная ссылка: Развёртывание и настройка oVirt 4.0. Часть 3. Базовые операции в oVirt | Блог IT-KB /
Алексей oVirt это аналог VirtManagera?
Если Вы имеете ввиду https://virt-manager.org, то oVirt это совсем не аналог, а продукт гораздо более функциональный и рассчитанный на другие масштабы.
Спасибо за ответ, именно за него и имеется ввиду.Есть цель попробовать по вашим статьям настроить виртуализации на КВМ, т.к давно уже хотят перевести на гипервизор КВМ.Как вы считаете для небольшой инфраструктуры начинать управлять виртуалками с VirtManager?
Про VirtManager я никак не считаю. Если инфраструктура небольшая (1-2 хоста), то возможно имеет смысл посмотреть в сторону Proxmox VE, а не лезть в дебри oVirt.
Два хоста которые обслуживают Линукс сервисы и 3 хоста которые обслуживают Windows сервисы. В данный момент все на Hyper-V. Есть желание Линукс-сервисы перевести на Линукс гипервизор.
Спасибо за ваши статьи, они очень практические и понятные. Хорошее дело делаете!
Обратная ссылка: Развёртывание и настройка oVirt 4.0. Часть 6. Обновление Hosted Engine | Блог IT-KB /
О, эта прекрасная комбинация Hyper-V + Ubuntu + DPM. Сколько я напарился с этим всем, а оно по-прежнему периодически ломает файловую систему после бэкапа машины. Даже с установленным linux-virtual-lts-xenial
Спасибо за статью. Если появится свободный хост, обязательно попробую это или proxmox
А заодно попробуйте Nutanix CE ... а то у меня что-то руки не доходят, а почитать отзыв и сравнение хочется :)
В комментах здесь https://habrahabr.ru/company/nutanix/blog/257855/ говорят интересную вещь про Nutanix Community Edition "EULA разрешает только test/dev".
Вообще там в комментах много чего интересного есть почитать :)
Да , действительно, статейку я эту читал и комменты ... но видимо комменты не дочитал. Они, конечно, в статье сразу пишут "Бесплатно." :)
Там больше теории, а я бы не отказался от практической статьи, на подобии Вашей. На словах у всех все супер :)
Что я понял для себя из той статьи и комментариев:
- NCE это решение не ориентированное на Shared Storage, а наоборот, локальные хранилища серверов собираются в некий виртуальный сторадж, при этом наличие для каждого сервера как минимум одного SSD диска под кэши и прочие служебные вещи - обязательно.
- NCE работает только с сетевыми платами от Intel
- NCE кластеризуется объёмом не более 4-х узлов, то есть о перспективе расширения инфраструктуры на таком решении можно забыть,
- NCE хоть и бесплатен, но если его начать использовать в продуктиве, то можно понести риски, связанные с возможными претензиями отдела "К".
То есть, тут есть, над чем задуматься.
Возможно конечно я что-то неверно истолковал для себя, но как бы там ни было, здесь заметка конкретно про oVirt, и разводить споры на тему сравнения разных решений наверно будет не совсем уместно.
Тезка, приветствую!
Как раз сейчас продуктовая группа MS интересуется у заказчиков, что нужно улучшить в резервном копировании SCDPM в части *NIX машин и компонентов (файлы, базы данных и т.д.).
Можете объективно написать здесь в комментариях или мне лично в https://www.facebook.com/eugene.leitan или на email: eleytan@gmail.com .
Я смогу передать Ваши пожелания! :)
Спасибо!
Отписал в ФБ. Ничего особенно, в целом.
в ФБ ничего нет :(
Дублирую:
По поводу DPM и бэкапа nix машин, по-моему, все давно понятно. Нужно, в первую очередь, чтобы оно работало. Основная проблема - при бэкапировании иногда происходит мистика, из-за чего в гостевой ОС файловая система переходит в read-only. Даже с рекомендованными МС шаманизмами с установкой virtual кернела это иногда происходит.
К сожалению (или счастью) мы не используем резервное копирование сервисов linux-машин, только бэкапим виртуалки целиком. На этих машинах у нас крутится MySQL в том числе (и MariaDB), но задачи бэкапирования отдельно баз никогда не стояло, так что не могу сказать о его необходимости. Наверное, тут надо спрашивать тех, для кого это актуально)
С уважением, Евгений
Передай им, что мы желаем бекапы виртуальных машин из кластера oVirt делать на горячую, только чтобы "без кидалова", как сейчас. Пусть организуют DPM Community Edition. Я думаю у тебя после таких слов они сразу погоны сорвут :)))
"DPM Community Edition"
Это для кого? Учитывая интеграцию с AD у DPM, тогда надо и Windows Server Community :D
Леха, не сорвут, п.ч. именно сейчас MS дружит со всеми! Ждите мощных интеграций *NIX систем с Windows, Apple, Android :)
Если есть желание работать с Microsoft по таким направлениям, то тоже можно либо писать здесь в комментариях или мне лично в https://www.facebook.com/eugene.leitan или на email: eleytan@gmail.com.
а "DPM Community" уже есть и называется это все дело "Cloud and Datacenter Management", куда входит весь Sytem Center :)
Пожелания по поводу резервного копирования *Nix систем написал.
Посмотрим, что будет через 3-4 месяца :)
Кстати, а можно, пользуясь случаем, поинтересоваться перспективами SC2016? Это будет CB как SCCM? Или обычный вариант?
Пока точной информации нет (скоро уже выйдет SC 2016), но скорее всего как привычный/обычный вариант :)
Обратная ссылка: Развёртывание и настройка oVirt 4.0. Часть 7. Расширение кластера и балансировка нагрузки | Блог IT-KB /
Обратная ссылка: Развёртывание и настройка oVirt 4.0. Часть 11. Резервное копирование oVirt Hosted Engine | Блог IT-KB /
Такая конфигурация, когда ISO домен экспортируется с виртуалки, на которой крутится Engine, имеет одну неприятную особенность: в случае отказа хоста, на котором выполняется виртуалка с Engine, она не будет перезапущена на другом хосте из-за недоступности этого самого ISO домена. Подробнее можно тут https://bugzilla.redhat.com/show_bug.cgi?id=1215434 глянуть. Тоже относится и к Export домену. Поэтому нужно подключать/отключать эти домены по необходимости (преимущественно держать отключенными) или еще какое решение придумывать.
Да, встречал где-то подобную информацию. На самом деле конфигурацию с совмещённым ISO Domain с Hosted Engine я использовал только изначально некоторое время. Позже перешёл на использование ISO Domain на выделенном файловом сервере с включённой дедупликацией, поэтому описанных проблем не успел испытать.
hosted engine это изначально потенциальные проблемы типа "яйцо-курица", и такие проблемы будут возникать, ничего тут не поделаешь. Решение очень простое - планировать систему правильно заранее, чтоб потом таких проблем не возникало. Более того, в 99% случаев, RHEV я ставил с engine на отдельном хосте или кластере, не потому что hosted engine хуже, а потому что при определенных размерах, смысла виртуализировать engine нет. Чем больше машин, SD и прочих объектов, тем тяжелее база данных. Если там еще и DWH - тем более. Если оттуда же еще и раздавать ISO или проксировать spice, то нагрузка еще больше. Конечно с тремя хостами и десятком машин HE это прекрасное решение и экономия, но такие системы, из моего опыта, имеют свойство расти, и быстро.
Ну, у меня пока только два хоста, которые я могу под oVirt использовать, так что других вариантов особо и нет. А про особенность эту просто стоит помнить, чтобы избежать неприятных сюрпризов. Вообще, ситуация странная, ведь для HE создаётся отдельный домен, но его почему-то недостаточно, чтобы оно взлетело. Намудрили они там с дизайном.
Просто не продумали все возможные сценарии, их может быть очень много. Я вообще считаю что на HE не надо было автоматом поднимать ISO, a гораздо лучше было бы при подключении нового ISO домена заливать в него с машины где engine ISO файл с tools и vfd с драйверами.
Обратная ссылка: Расширение правил iptables на хостах oVirt 4.0 | Блог IT-KB /
По поводу отключения обновлений resolve.conf нашел самое правильное решение на мой взгляд:
vim /etc/NetworkManager/NetworkManager.conf
в сецию [main] добавляем
dns=none