🥇Створення відмовостійкої ІТ інфраструктури. Частина 2. Встановлення та налаштування кластера oVirt 4.3

Ця стаття є продовженням попередньої.Створення відмовостійкої ІТ інфраструктури. Частина 1 – підготовка до розгортання кластера oVirt 4.3».

У ній буде розглянуто процес базової установки та налаштування кластера oVirt 4.3 для хостингу високодоступних віртуальних машин, з урахуванням того, що всі попередні кроки з підготовки інфраструктури вже виконані раніше.

Вступна частина

Основна мета статті – кілька видати покрокову інструкцію виду «МАЙБУТНІ -> Так -> обробка», скільки показати деякі особливості при його встановленні та налаштуванні. Процес розгортання вашого кластера, не завжди може збігатися з описаним у ній, через особливості інфраструктури та оточення, але загальні принципи будуть однаковими.

З суб'єктивної точки зору, oVirt 4.3 за своїм функціоналом схожий на VMware vSphere версії 5.х, але звичайно зі своїми особливостями налаштування та роботи.

Для тих, хто цікавиться, всі відмінності між RHEV (aka oVirt) і VMware vSphere можна знайти в Інтернеті, наприклад тут, але все ж таки іноді відзначатиму їх деякі відмінності або схожості між собою, по ходу статті.

Окремо хотілося б трохи порівняти роботу із мережами для віртуальних машин. В oVirt реалізований схожий принцип управління мережами для віртуальних машин (далі ВМ), як і VMware vSphere:

за допомогою стандартного Linux bridge (в VMware - Standard vSwitch), що працює на хостах віртуалізації;
за допомогою Open vSwitch (OVS) (в VMware - Distributed vSwitch) – це розподілений віртуальний комутатор, що складається з двох основних компонентів: центрального сервера OVN та контролерів OVN на керованих хостах.

Необхідно відзначити, що через простоту реалізації, у статті буде описано налаштування мереж в oVirt'і для ВМ за допомогою стандартного Linux bridge, який є стандартним вибором при використанні гіпервізора KVM.

У зв'язку з цим є кілька базових правил по роботі з мережею в кластері, які краще не порушувати:

Усі мережні налаштування на хостах перед додаванням їх до oVirt повинні бути ідентичними, крім IP адрес.
Після того, як хост взятий під управління oVirt'ом, на ньому вкрай не рекомендується щось міняти руками в мережевих налаштуваннях, без повної впевненості у своїх діях, оскільки агент oVirt просто відкотить їх на попередні після рестарту хоста або агента.
Додавання нової мережі для ВМ, як і роботи з нею, повинне проводитися тільки з консолі управління oVirt'ом.

Ще одне важливе зауваження - Для дуже критичного оточення (дуже чутливого до грошових втрат), все-таки рекомендувалося б використовувати платну підтримку та використовувати Red Hat Virtualization 4.3. У процесі експлуатації кластера oVirt можуть виникати деякі моменти, за якими бажано якнайшвидше отримати кваліфіковану допомогу, а не розбиратися з ними самостійно.

І наостанок, рекомендується перед розгортанням кластера oVirt, ознайомитись з офіційну документацію, щоб бути в курсі хоча б основних понять та визначень, інакше далі статтю читати буде трохи важко.

Базовими для розуміння статті та принципів роботи кластера oVirt є ці керівні документи:

Обсяг там не дуже великий, за годину-дві цілком можна подужати основні принципи, а для любителів подробиць рекомендується почитати Product Documentation for Red Hat Virtualization 4.3 - RHEV і oVirt по суті те саме.

Отже, якщо всі базові налаштування на хостах, комутаторах та СГД виконані, переходимо безпосередньо до розгортання oVirt.

Частина 2. Встановлення та налаштування кластера oVirt 4.3

Для зручності орієнтування наведу за списком основні розділи у цій статті, які по черзі мають бути виконані:

Установка керуючого сервера oVirt
Створення нового датацентру
Створення нового кластера
Встановлення додаткових хостів у Self-Hosted оточення
Створення області зберігання або Storage Domains
Створення та налаштування мереж для віртуальних машин
Створення настановного образу для розгортання віртуальної машини
Створення віртуальної машини

Установка керуючого сервера oVirt

Керуючий сервер oVirt - це найголовніший елемент в інфраструктурі oVirt, у вигляді віртуальної машини, хоста, або віртуального пристрою, що управляє всією інфраструктурою oVirt.

Його близькі аналоги зі світу віртуалізації:

VMware vSphere - vCenter Server
Microsoft Hyper-V - System Center Virtual Machine Manager (VMM).

Для встановлення керуючого сервера oVirt, у нас є два варіанти:

Варіант 1
Розгортання сервера як спеціалізованої ВМ чи хоста.

Цей варіант цілком працює, але за умови, що така ВМ працює незалежно кластера, тобто. не запущена на будь-якому хості кластера у вигляді звичайної віртуальної машини під керуванням KVM.

Чому не можна розгортати таку ВМ на хостах кластера?

На самому початку процесу розгортання керуючого сервера oVirt, у нас є дилема - керуючу ВМ ставити потрібно, але самого кластера практично ще немає, і тому що можна відразу придумати? Правильно встановити KVM на майбутній вузол кластера, далі на ньому створити віртуальну машину, наприклад, з ОС CentOS і в ній розгорнути oVirt engine. Це може робитися зазвичай з міркувань повного контролю над такою ВМ, але це помилковий намір, тому що в такому разі надалі 100% будуть проблеми з такою керуючою ВМ:

її не можна буде мігрувати в консолі oVirt між хостами (вузлами) кластера;
при міграції засобами KVM через вірш мігрувати, ця ВМ буде недоступна для управління з консолі oVirt.
хости кластера не можна буде вивести в Режим обслуговування (режим обслуговування), якщо мігрувати цю ВМ з хоста на хост за допомогою вірш мігрувати.

Так що робіть все за правилами - використовуйте для керуючого сервера oVirt або окремий хост, або незалежну ВМ, запущену на ньому, а краще робіть як написано у другому варіанті.

Варіант 2
Установка oVirt Engine Appliance на керований ним кластер.

Саме цей варіант буде розглянуто далі, як правильніший і відповідний у нашому випадку.
Вимоги до такої ВМ описані нижче, додам лише, що рекомендується мати мінімум два хости в інфраструктурі, на яких може бути запущена керуюча ВМ, щоб зробити її стійкою до відмови. Тут хотілося б додати, що як уже писав у коментарях у попередній статті, мені так і не вдалося отримати роздвоєний мозок на кластері oVirt з двох хостів, з можливістю запуску hosted-engine ВМ на них.

Установка oVirt Engine Appliance на перший кластер-хост

Посилання на офіційну документацію oVirt Self-Hosted Engine Guide, глава «Deploying the Self-Hosted Engine За допомогою Command line»

У документі вказані попередні умови, які мають бути виконані перед розгортанням hosted-engine ВМ, а також детально розписаний сам процес її встановлення, так що повторювати його дослівно немає особливого сенсу, тому акцентуємо увагу на деяких важливих деталях.

Перед початком всіх дій обов'язково включаємо підтримку віртуалізації в налаштуваннях BIOS на хості.
Встановлюємо на хост пакет для інсталятора hosted-engine:

yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm 
yum -y install epel-release
yum install screen ovirt-hosted-engine-setup

Запускаємо на хості процедуру розгортання oVirt Hosted Engine у screen'і (вийти з нього можна через Ctrl-A+D, закрити через Ctrl-D):

screen
hosted-engine --deploy

За бажання можна запустити установку із заздалегідь підготовленим файлом відповідей:

hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-ohe.conf

Під час розгортання hosted-engine вказуємо всі необхідні параметри:

- имя кластера
- количество vCPU и vRAM (рекомендуется 4 vCPU и 16 Гб)
- пароли
- тип хранилища для hosted engine ВМ – в нашем случае FC
- номер LUN для установки hosted engine
- где будет находиться база данных для hosted engine – рекомендую для простоты выбрать Local (это БД PostgreSQL работающая внутри этой ВМ)
и др. параметры.

Для встановлення високодоступної ВМ з hosted engine, на СГД нами був заздалегідь створений спеціальний LUN під номером 4 і розміром 150 Гб, який був презентований хостам кластера – див. попередній статті.

Раніше ми також перевіряли його видимість на хостах:

multipath -ll
…
3600a098000e4b4b3000003c95d171065 dm-3 DELL    , MD38xxf
size=150G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:4  sdc 8:32  active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 18:0:0:4  sdj 8:144 active ready running

Сам процес розгортання hosted-engine нічого складного в собі не несе, в його кінці ми маємо отримати приблизно таке повідомлення:

[ INFO  ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20191129131846.conf'
[ INFO  ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Hosted Engine successfully deployed

Перевіряємо наявність сервісів oVirt на хості:

Якщо все було зроблено правильно, то після закінчення установки заходимо за допомогою веб-браузера на https://ovirt_hostname/ovirt-engine з комп'ютера адміністратора, і клацаємо [Administration Portal].

Скриншот «Administration Portal»

Ввівши логін та пароль (задані в процесі установки) у вікно як на скріншоті, потрапляємо в панель керування Open Virtualization Manager, в якій можна виконувати всі дії з віртуальною інфраструктурою:

додавати датацентр
додавати та налаштовувати кластер
додавати хости та керувати ними
додавати області зберігання або Storage Domains для дисків віртуальних машин
додавати та налаштовувати мережі для віртуальних машин
додавати віртуальні машини, настановні образи, шаблони ВМ та керувати ними

Всі ці дії будуть розглянуті далі, щось у велику клітинку, щось докладніше і з нюансами.
Але спочатку рекомендував би почитати цей додаток, який напевно багатьом може стати в нагоді.

Доповнення

1) В принципі, якщо є така необхідність, то нічого не заважає заздалегідь встановити гіпервізор KVM на вузли кластера, використовуючи пакети лібвірт и qemu-kvm (або qemu-kvm-ev) бажаної версії, хоча при розгортанні вузла кластера oVirt, він може це зробити і сам.

Але якщо лібвірт и qemu-kvm були встановлені не найсвіжішої версії, то можна отримати таку помилку під час розгортання hosted engine:

error: unsupported configuration: unknown CPU feature: md-clear

Тобто. необхідно мати оновлену версію лібвірт із захистом від MDS, який підтримує таку політику:

<feature policy='require' name='md-clear'/>

Встановлюємо libvirt v.4.5.0-10.el7_6.12 з підтримкою md-clear:

yum-config-manager --disable mirror.centos.org_centos-7_7_virt_x86_64_libvirt-latest_

yum install centos-release-qemu-ev
yum update
yum install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer libguestfs libguestfs-tools dejavu-lgc-sans-fonts virt-top libvirt libvirt-python libvirt-client

systemctl enable libvirtd
systemctl restart libvirtd && systemctl status libvirtd

Перевіряємо наявність підтримки 'md-clear':

virsh domcapabilities kvm | grep require
      <feature policy='require' name='ss'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='pku'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='invtsc'/>

Після цього можна продовжувати інсталяцію hosted engine.

2) В oVirt 4.3 наявність та використання фаєрволу брандмауер є обов'язковою вимогою.

Якщо під час розгортання ВМ для hosted-engine отримуємо таку помилку:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld is required to be enabled and active in order to correctly deploy hosted-engine. Please check, fix accordingly and re-deploy.n"}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

То необхідно вимкнути інший фаєрвол (якщо він використовується), і встановити і запустити брандмауер:

yum install firewalld
systemctl enable firewalld
systemctl start firewalld

firewall-cmd --state
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --get-zones

Надалі, при встановленні агента ovirt на новому хості для кластера, він налаштує необхідні порти в брандмауер автоматично.

3) Перезавантаження хоста з ВМ, що працює на ньому, з hosted engine.

Як зазвичай, посилання 1 и посилання 2 керівні документи.

Все управління hosted engine ВМ робиться ТІЛЬКИ за допомогою команди hosted-engine на хості, де вона працює, про вірш треба забути, також, як і про те, що до цієї ВМ можна підключитися по SSH і виконати на ній командувимикання».

Процедура щодо виведення ВМ у режим обслуговування:

hosted-engine --set-maintenance --mode=global

hosted-engine --vm-status
!! Cluster is in GLOBAL MAINTENANCE mode !!
--== Host host1.test.local (id: 1) status ==--
conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Host timestamp                     : 1821
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sat Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sat Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Перезавантажуємо хост з hosted engine agent і робимо з ним, що нам потрібно.

Після перезавантаження перевіряємо статус ВМ з hosted engine:

hosted-engine --vm-status

Якщо наша ВМ з hosted-engine не запускається, і якщо ми бачимо схожі помилки в лозі сервісу:

Помилка в журналі сервісу:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Failed to start necessary monitors
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (most recent call last):#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 131, in _run_agent#012    return action(he)#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 55, in action_proper#012    return he.start_monitoring()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 413, in start_monitoring#012    self._initialize_broker()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 537, in _initialize_broker#012    m.get('options', {}))#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - failed to start monitor via ovirt-ha-broker: [Errno 2] No such file or directory, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying to restart agent

То підключаємо сховище і перезапускаємо агента:

hosted-engine --connect-storage
systemctl restart ovirt-ha-agent
systemctl status ovirt-ha-agent

hosted-engine --vm-start
hosted-engine --vm-status

Після запуску ВМ з hosted-engine виводимо її з режиму обслуговування:

Процедура виведення ВМ з режиму обслуговування:

hosted-engine --check-liveliness
hosted-engine --set-maintenance --mode=none
hosted-engine --vm-status

--== Host host1.test.local (id: 1) status ==--

conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : 6d1eb25f
local_conf_timestamp               : 6222296
Host timestamp                     : 6222296
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (Fri Jan 17 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (Fri Jan 17 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        stopped=False

4) Вилучення hosted engine і всього з нею пов'язаного.

Іноді буває необхідно правильно видалити раніше встановлений hosted engine. посилання на керівний документ.

Просто виконуємо команду на хості:

/usr/sbin/ovirt-hosted-engine-cleanup

Далі видаляємо непотрібні пакети, забекапивши перед цим якісь конфіги, якщо це необхідно:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

Створення нового датацентру

Довідкова документація - oVirt Administration Guide. Chapter 4: Data Centers

Спочатку визначимо, що таке дата центр (Цитую з довідки) - це логічна сутність, яка визначає набір ресурсів, що використовуються в специфічному оточенні.

Датацентр - це свого роду контейнер, що складається з:

логічних ресурсів у вигляді кластерів та хостів
мережевих ресурсів кластера у вигляді логічних мереж та фізичних адаптерів на хостах,
ресурсів зберігання (для дисків ВМ, шаблонів, образів) як областей зберігання (Storage Domains).

Датацентр може включати декілька кластерів, що складаються з декількох хостів з віртуальними машинами, що працюють на них, у нього також може бути кілька областей зберігання, асоційованих з ним.
Датацентрів може бути кілька, вони працюють незалежно один від одного. В ovirt є поділ повноважень за ролями, і можна налаштувати дозволи персонально, як на рівні датацентру, так і на окремі його логічні елементи.

Датацентр, або датацентри, якщо їх кілька, управляються з єдиної адміністративної консолі або порталу.

Щоб створити датацентр, заходимо в адміністративний портал та створюємо новий датацентр:
обчислення >> центри обробки даних >> Нові

Так як у нас використовується загальне сховище на СГД, то тип сховища (Storage Type) має бути Shared:

Скріншот із майстром створення датацентру

При встановленні віртуальної машини з hosted-engine, за замовчуванням створюється датацентр – Datacenter1, і далі в разі потреби в нього можна змінити тип сховища (Storage Type) на інший.

Створення датацентру — це нескладне завдання, без хитрих нюансів, і всі додаткові дії з ним описані в документації. Єдино зауважу, що одиночні хости мають тільки локальне сховище (диск) для ВМ, в датацентр c Storage Type - Shared потрапити не зможуть (не можна їх додати туди), і для них потрібно створювати окремий датацентр - тобто. кожному окремому хосту з локальним сховищем, потрібен окремий датацентр.

Створення нового кластера

Посилання на документацію - oVirt Administration Guide. Chapter 5: Clusters

Без зайвих подробиць, кластер – це логічне угруповання хостів, що мають загальну область зберігання (у вигляді загальних дисків на СГД, як у нашому випадку). Також бажано, щоб хости в кластері були ідентичні залізом, і мали б однаковий тип процесора (Intel або AMD). Найкраще звичайно, щоб сервери у кластері були повністю однаковими.

Кластер входить до складу датацентру (з певним типом сховища Місцевий або Загальні), а всі хости в обов'язковому порядку повинні належати якомусь кластеру, залежно від того, чи є у них спільне сховище чи ні.

При встановленні віртуальної машини з hosted-engine на хост, за замовчуванням створюється датацентр. Datacenter1, разом із кластером – Кластер1, і надалі можна налаштувати його параметри, увімкнути додаткові опції, додати до нього хости тощо.

Як завжди, для отримання подробиць про всі налаштування кластера бажано звернутися до офіційної документації. З якихось особливостей налаштування кластера додам лише, що при його створенні достатньо налаштувати лише основні параметри на вкладці Загальне.

Відзначу найважливіші параметри:

Тип процесора - Вибирається, виходячи з того, які процесори встановлені на хостах кластера, від якого вони виробника, і який процесор на хостах найстаріший, щоб в залежності від цього використовувати всі доступні процесорні інструкції в кластері.
Тип комутатора – у нас у кластері використовується лише Linux bridge, тому його й вибираємо.
Firewall type – тут все зрозуміло, це firewalld, який має бути включений та налаштований на хостах.

Скріншот із параметрами кластера

Установка додаткових хостів у Self-Hosted оточенні

Посилання на документацію.

Додаткові хости для Self-Hosted оточення, додаються так само, як і звичайний хост, з виконанням додаткового пункту розгортання ВМ з hosted engine Choose hosted engine deployment action >> Розгортання. Оскільки додатковому хосту також має бути презентований LUN для ВМ з hosted engine, це означає, що це хост можна за необхідності використовуватиме розміщення ньому ВМ з hosted engine.
З метою відмови стійкості дуже рекомендується, щоб було мінімум два хоста, на яких може бути розміщена ВМ з hosted engine.

На додатковому хості відключаємо iptables (якщо включено), включаємо firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Встановлюємо потрібну версію KVM (за потребою):

yum-config-manager --disable mirror.centos.org_centos-7_7_virt_x86_64_libvirt-latest_

yum install centos-release-qemu-ev
yum update
yum install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer libguestfs libguestfs-tools dejavu-lgc-sans-fonts virt-top libvirt libvirt-python libvirt-client

systemctl enable libvirtd
systemctl restart libvirtd && systemctl status libvirtd

virsh domcapabilities kvm | grep md-clear

Встановлюємо потрібні репозиторії та інсталятор hosted engine:

yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm
yum -y install epel-release
yum update
yum install screen ovirt-hosted-engine-setup

Далі переходимо в консоль Open Virtualization Manager, додаємо новий хост, і робимо все покроково, як написано в документації.

В результаті, після додавання додаткового хоста, ми маємо отримати приблизно картину в адміністративній консолі, як на скріншоті.

Скріншот адміністративного порталу — хости

Хост, на якому ВМ з hosted-engine в даний момент активна, має золоту корону та напис.Running the Hosted Engine VM», хост, на якому ця ВМ може бути запущена при необхідності – напис «Can run the Hosted Engine VM».

У разі збою хоста на якомуRunning the Hosted Engine VM», вона автоматично перезапуститься на другому хості. Також цю ВМ можна мігрувати з активного хоста на резервний для його обслуговування.

Налаштування Power Management / fencing на хостах oVirt

Посилання на документацію:

Red Hat Virtualization 4.3 -> Technical Reference -> Chapter 4. Power Management
oVirt Administration Guide -> Chapter 7: Hosts

Хоча може здатися, що додавання та налаштування хоста виконано, але це не зовсім так.
Для нормальної роботи хостів, та виявлення/усунення збоїв з будь-ким з них, необхідне налаштування Power Management / fencing.

Фехтування, або огородження - це процес тимчасового виключення несправного або збійного хоста з кластера, в процесі якого перезапускаються або сервіси oVirt на ньому або сам хост.

Всі подробиці щодо визначення та параметрів Power Management / fencing дано, як зазвичай у документації, я лише наведу приклад, як налаштувати цей важливий параметр, у застосуванні до серверів Dell R640 з iDRAC 9.

Заходимо в адміністративний портал, клацаємо обчислення >> хости вибираємо хост.
Кількома Редагувати.
Клацаємо вкладку управління енергоспоживанням.
Відзначаємо прапорець навпроти опції Enable Power Management.
Відзначаємо прапорець навпроти опції Kdump integrationщоб хост не перейшов у режим огорожі (fencing), під час запису аварійного дампа ядра.

Примітка.

Після включення Kdump integration на вже працюючому хості, він повинен бути перевстановлений відповідно до процедури в oVirt Administration Guide -> Chapter 7: Hosts -> Reinstalling Hosts.

Опціонально можна відзначити прапорець Disable policy control of power managementЯкщо ми не хочемо, щоб управління живленням хоста, контролювалося б політикою планування (Scheduling Policy) кластера.
Клацаємо кнопку (+), щоб додати новий пристрій керування живленням, відкриється вікно редагування властивостей агента.
Для iDRAC9, заповнюємо поля:
- адреса – адреса iDRAC9
- Ім'я користувача Пароль – відповідно логін та пароль для входу до iDRAC9
- тип - drac5
- зазначити Безпечний
- додати такі опції: cmd_prompt=>,login_timeout=30

Скриншот з параметрами Power Management у властивостях хоста

Створення області зберігання або Storage Domains

Посилання на документацію - oVirt Administration Guide, Chapter 8: Storage.

Storage Domain, або область зберігання – це централізоване місце для зберігання дисків віртуальних машин, настановних образів, шаблонів та снепшотів.

Області зберігання можуть підключатися до датацентру, використовуючи різні протоколи, кластерні та мережеві файлові системи.

У oVirt є три типи області зберігання:

Домен даних – для зберігання всіх даних, пов'язаних із віртуальними машинами (диски, шаблони). Data Domain не може розподілятися між різними датацентрами.
ISO Domain (Застарілий тип області зберігання) – для зберігання настановних образів ОС. ISO Domain може розподілятися між різними датацентрами.
Export Domain (застарілий тип області зберігання) – для тимчасового зберігання образів, що переміщуються між датацентрами.

У нашому окремому випадку область зберігання з типом Data Domain, використовує Fibre Channel Protocol (FCP), для підключення до LUN на СХД.

З точки зору oVirt, при використанні СХД (FC або iSCSI) кожен віртуальний диск, снепшот чи шаблон це логічний диск.
Блокові пристрої збираються в одне ціле (на хостах кластера) за допомогою Volume Group і потім поділяються за допомогою LVM на логічні томи, які використовуються як віртуальні диски для ВМ.

Всі ці групи і безліч томів LVM можна побачити на хості кластера, за допомогою команд тощо и лв. Звичайно, що всі дії з такими дисками потрібно робити тільки з консолі oVirt, крім особливих випадків.

Віртуальні диски для ВМ можуть бути двох типів QCOW2 або RAW. Диски можуть бути "тонкими"Або"товстими". Снепшоти завжди створюються як "тонкі".

Спосіб управління Storage domains, або областями зберігання, доступ до яких здійснюється через FC, є досить логічним — для кожного віртуального диска ВМ існує окремий логічний том, який доступний для запису лише одному хосту. У разі підключень через FC, oVirt використовує щось на кшталт кластерного LVM.

Віртуальні машини, розташовані на одній області зберігання, можна мігрувати між хостами, що належать одному кластеру.

Як бачимо з опису, кластер в oVirt, як і кластер в VMware vSphere або Hyper-V, по суті позначають одне і теж - це логічне угруповання хостів, бажано однакових за складом "заліза", і мають спільне сховище для дисків віртуальних машин.

Перейдемо безпосередньо до створення області зберігання даних (дисків ВМ), оскільки без неї датацентр нічого очікувати проініціалізований.
Нагадаю, що всі презентовані хостам кластери LUN'и на СГД мають бути на них видно за допомогою команди «багатопрохідність -ll».

Згідно з документації, йдемо в порталі заходимо в зберігання >> Домени -> Новий домен та виконуємо інструкції з розділу "Adding FCP Storage".

Після запуску майстра заповнюємо необхідні поля:

ІМ'Я - задаємо ім'я кластера
Domain Function - Data
Тип зберігання - Fibre Channel
Host to Use - вибираємо хост, на якому доступний LUN

У списку LUN'ів відзначаємо потрібний нам, клацаємо додавати і потім ОК. При необхідності можна скоригувати додаткові параметри області зберігання, натиснувши на Розширені параметри.

Скріншот майстра з додавання «Storage domain»

За результатами роботи майстра ми маємо отримати нову область зберігання, а наш датацентр перейти в статус UP, або ініціалізований:

Скріншоти датацентру та областей зберігання в ньому:

Створення та налаштування мереж для віртуальних машин

Посилання на документацію - oVirt Administration Guide, Chapter 6: Logical Networks

Networks, або мережі – служать для угруповання логічних мереж, які у віртуальної інфраструктурі oVirt.

Для взаємодії мережевого адаптера на віртуальній машині з фізичним адаптером на хості використовуються логічні інтерфейси типу Linux bridge.

Для угруповання та поділу трафіку між мережами, на комутаторах налаштовані VLAN'и.

При створенні логічної мережі для віртуальних машин в oVirt, їй потрібно обов'язково призначити ідентифікатор, що відповідає номеру VLAN на комутаторі, щоб ВМ могли взаємодіяти один з одним, навіть якщо вони працюють на різних вузлах кластера.

Попередні налаштування мережевих адаптерів на хостах для підключення віртуальних машин повинні були бути виконані в попередній статті – налаштовано логічний інтерфейс bondxnumx, далі всі налаштування мережі повинні проводитися тільки через адміністративний портал oVirt.

Після створення ВМ з hosted-engine, окрім автоматичного створення датацентру та кластера, також автоматично створилася логічна мережа для управління нашим кластером – ovritmgmt, до якої було підключено цю ВМ.

При необхідності можна переглянути налаштування логічної мережі ovritmgmt і скоригувати їх, але треба бути обережним, щоб не втратити управління інфраструктурою oVirt.

Налаштування логічної мережі ovritmgmt

Для створення нової логічної мережі для звичайних ВМ, в адміністративному порталі переходимо до мережу >> Мережі >> Нові, і на вкладці Загальне додаємо мережу з потрібним ідентифікатором VLAN, а також ставимо прапорець навпроти «VM Network», це означає, що її можна використовувати для призначення на ВМ.

Скріншот нової логічної мережі VLAN32

На вкладці кластер, прикріплюємо цю мережу до нашого кластера Кластер1.

Після цього переходимо в обчислення >> хости, по черзі заходимо у кожен хост, на вкладку Мережні інтерфейси, і запускаємо майстер Setup host networksдля прив'язки до хостів нової логічної мережі.

Скріншот майстра "Setup host networks"

Агент oVirt автоматично зробить всі необхідні налаштування мережі на хості – створить VLAN і BRIDGE.

Приклад конфігураційних файлів для нових мереж на хості:

cat ifcfg-bond1
# Generated by VDSM version 4.30.17.1
DEVICE=bond1
BONDING_OPTS='mode=1 miimon=100'
MACADDR=00:50:56:82:57:52
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-bond1.432
# Generated by VDSM version 4.30.17.1
DEVICE=bond1.432
VLAN=yes
BRIDGE=ovirtvm-vlan432
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-ovirtvm-vlan432
# Generated by VDSM version 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Ще раз нагадаю, що на хості кластера НЕ ПОТРІБНО заздалегідь створювати руками мережеві інтерфейси ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

Після додавання логічної мережі та перевірки з'єднання між хостом та ВМ c hosted engine, її можна використовувати у віртуальній машині.

Створення настановного образу для розгортання віртуальної машини

Посилання на документацію - oVirt Administration Guide, Chapter 8: Storage, розділ Uploading Images to a Data Storage Domain.

Без інсталяційного образу ОС, не вдасться встановити віртуальну машину, хоча це звичайно і не є проблемою, якщо в мережі встановлено, наприклад, Шкіряник із заздалегідь створеними образами.

У нашому випадку такої можливості немає, тому доведеться самостійно імпортувати цей образ в oVirt. Раніше для цього потрібно створювати ISO Domain, але в новій версії oVirt він був визнаний застарілим, і тому тепер можна завантажувати образи прямо в Storage domain з адміністративного порталу.

В адміністративному порталі йдемо в зберігання >> диски >> Завантажувати >> Start
Додаємо наш образ ОС у вигляді ISO файлу, у формі заповнюємо всі поля, та клацаємо кнопку "Тестове підключення".

Скріншот майстра додавання настановного образу

Якщо отримуємо помилку такого виду:

Unable to upload image to disk d6d8fd10-c1e0-4f2d-af15-90f8e636dadc due to a network error. Ensure that ovirt-imageio-proxy service is installed and configured and that ovirt-engine's CA certificate is registered as a trusted CA in the browser. The certificate can be fetched from https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA`

То необхідно додати сертифікат oVirt до «Довірені кореневі ЦС(Trusted Root CA) на керуючій станції адміністратора, звідки намагаємося завантажити образ.

Після додавання сертифіката до Trusted Root CA, знову клацаємо "Тестове підключення", повинні отримати:

Connection to ovirt-imageio-proxy was successful.

Виконавши дію з додавання сертифіката, можна спробувати знову завантажити ISO в Storage Domain.

В принципі, можна зробити окремий Storage Domain з типом Data, для зберігання образів і шаблонів окремо від дисків ВМ, або навіть зберігати їх у Storage Domain для hosted engine, але це вже на розсуд адміністратора.

Скріншот із образами ISO у Storage Domain для hosted engine

Створення віртуальної машини

Посилання на документацію:
oVirt Virtual Machine Management Guide –> Chapter 2: Installing Linux Virtual Machines
Console Clients Resources

Після завантаження в oVirt інсталяційного образу з ОС можна переходити безпосередньо до створення віртуальної машини. Багато було роботи зроблено, але ми вже знаходимося на завершальному етапі, заради чого все це і затівалося – отримання стійкої до відмови інфраструктури для хостингу високодоступних віртуальних машин. І причому все це абсолютно безкоштовно - жодної копійки на придбання будь-яких ліцензій на ПЗ не було витрачено.

Для створення віртуальної машини з CentOS 7 повинен бути завантажений інсталяційний образ з ОС.

Заходимо до адміністративного порталу, йдемо в обчислення >> Віртуальні машини, та запускаємо майстер створення ВМ. Заповнюємо всі параметри та поля, і натискаємо ОК. Все дуже просто, якщо слідувати документації.

Як приклад, наведу основні та додаткові налаштування високодоступної ВМ, зі створеним диском, підключену до мережі, та із завантаженням з інсталяційного образу:

Скріншоти з налаштуваннями високодоступної ВМ

Після закінчення робіт із майстром, закриваємо його, запускаємо нову ВМ та встановлюємо на неї ОС.
Для цього заходимо в консоль цієї ВМ через адміністративний портал:

Скріншот налаштувань адміністративного порталу для підключення до консолі ВМ

Щоб підключитися до консолі ВМ, потрібно налаштувати консоль у властивостях віртуальної машини.

Скриншот налаштувань ВМ, вкладка «Console»

Для підключення до консолі ВМ можна використовувати, наприклад, Virtual Machine Viewer.

Щоб підключитися до консолі ВМ прямо у вікні браузера, налаштування підключення через консоль повинні бути такими:

Після встановлення ОС на ВМ, бажано встановити oVirt guest agent:

yum -y install epel-release
yum install -y ovirt-guest-agent-common
systemctl enable ovirt-guest-agent.service && systemctl restart ovirt-guest-agent.service
systemctl status ovirt-guest-agent.service

Отже, внаслідок наших дій, створена ВМ буде високодоступною, тобто. у разі збою вузла кластера, на якому вона запущена, oVirt автоматично перезапустить її на другому вузлі. Також цю ВМ можна мігрувати між хостами кластера для їх обслуговування або інших цілей.

Висновок

Сподіваюся, що цією статтею вдалося донести, що oVirt – цілком нормальний інструмент управління віртуальною інфраструктурою, який розгорнути не так і складно — головне дотримуватися певних правил і вимог, описаних як у статті, так і в документації.

Через великий обсяг статті в неї не вдалося помістити багато речей, типу покрокового виконання різних майстрів з усіма докладними поясненнями та скріншотами, довгі висновки якихось команд тощо. Насправді для цього потрібно було написати цілу книгу, що не має особливого сенсу, через нові версії ПЗ з нововведеннями і змінами, що постійно з'являються. Найголовніше - це зрозуміти принцип, як воно все разом працює, і отримати загальний алгоритм дій щодо створення стійкої до відмови платформи з управління віртуальними машинами.

Хоча віртуальну інфраструктуру ми створили, але тепер треба навчити її взаємодіяти як між своїми окремими елементами: хостами, віртуальними машинами, внутрішніми мережами, і із зовнішнім світом.

Цей процес є одним із основних завдань системного або мережевого адміністратора, яке буде розкрито у наступній статті — про використання віртуальних маршрутизаторів VyOS у відмовостійкій інфраструктурі нашого підприємства (як ви здогадалися, вони працюватимуть у вигляді віртуальних машин на нашому кластері oVirt).

Джерело: habr.com

Створення відмовостійкої ІТ інфраструктури. Частина 2. Встановлення та налаштування кластера oVirt 4.3