🥇Создание отказоустойчивой ИТ инфраструктуры. Часть 2. Установка и настройка кластера oVirt 4.3

מאמר זה הוא המשך של הקודם - "יצירת תשתית IT עמידה בפני תקלות. חלק 1 - הכנה לפריסת אשכול oVirt 4.3".

הוא יכסה את תהליך ההתקנה והתצורה הבסיסית של אשכול oVirt 4.3 לאירוח מכונות וירטואליות בזמינות גבוהה, תוך התחשבות בעובדה שכל השלבים המקדימים להכנת התשתית כבר הושלמו בעבר.

חלק מבוא

המטרה העיקרית של המאמר היא לספק הוראות שלב אחר שלב כמו "הַבָּא -> יש -> סיום», сколько показать некоторые особенности при его установке и настройке. Процесс по развёртыванию вашего кластера, не всегда может совпадать с описанным в ней, из-за особенностей инфраструктуры и окружения, но общие принципы будут одинаковыми.

מנקודת מבט סובייקטיבית, oVirt4.3 по своему функционалу похож на VMware vSphere версии 5.х, но конечно же со своими особенностями настройки и работы.

למעוניינים, ניתן למצוא את כל ההבדלים בין RHEV (aka oVirt) ל-VMware vSphere באינטרנט, למשל כאן, но всё же буду иногда отмечать их некоторые отличия или похожести между собой, по ходу статьи.

בנפרד, ברצוני להשוות מעט את העבודה עם רשתות עבור מכונות וירטואליות. oVirt מיישמת עיקרון דומה של ניהול רשת עבור מכונות וירטואליות (להלן VMs), כמו ב-VMware vSphere:

с помощью стандартного Linux bridge (в VMware — Standard vSwitch), работающего на хостах виртуализации;
באמצעות Open vSwitch (OVS) (ב-VMware - Distributed vSwitch) – это распределённый виртуальный коммутатор, состоящий из двух основных компонентов: центрального сервера OVN и контроллеров OVN на управляемых хостах.

יש לציין כי בשל קלות היישום, המאמר יתאר הגדרת רשתות ב-oVirt עבור VM באמצעות גשר Linux סטנדרטי, שהוא הבחירה הסטנדרטית בעת שימוש ב-KVM hypervisor.

В связи с этим имеется несколько базовых правил по работе с сетью в кластере, которые лучше не нарушать:

כל הגדרות הרשת במארחים לפני הוספתן ל-oVirt חייבות להיות זהות, למעט כתובות IP.
ברגע שמארח נלקח לשליטת oVirt, מאוד לא מומלץ לשנות שום דבר באופן ידני בהגדרות הרשת ללא ביטחון מלא בפעולות שלך, מכיוון שסוכן oVirt פשוט יחזיר אותם לקודמים לאחר הפעלה מחדש של המארח או סוֹכֵן.
Добавление новой сети для ВМ, как и работы с ней, должно производиться только из консоли управления oVirt’ом.

עוד אחד הערה חשובה — для очень критичного окружения (весьма чувствительного к денежным потерям), всё-таки рекомендовалось бы использовать платную поддержку и использовать Red Hat Virtualization 4.3. В процессе эксплуатации кластера oVirt, могут возникать некоторые моменты, по которым желательно как можно скорее получить квалифицированную помощь, а не разбираться с ними самостоятельно.

ולבסוף מומלץ перед развёртыванием кластера oVirt, ознакомиться с תיעוד רשמי, чтобы быть в курсе хотя бы основных понятий и определений, иначе далее статью читать будет немного трудно.

בסיסי להבנת המאמר ועקרונות הפעולה של אשכול oVirt הם מסמכי ההנחיה הבאים:

Объём там не очень большой, за час-два вполне можно осилить основные принципы, а для любителей подробностей рекомендуется почитать תיעוד מוצר עבור 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.

מדוע לא ניתן לפרוס VM כזה על מארחי אשכולות?

В самом начале процесса развёртывания управляющего сервера oVirt, у нас имеется дилемма — управляющую ВМ ставить нужно, но самого кластера фактически ещё нет, и поэтому что можно с ходу придумать? Правильно – установить KVM на будущий узел кластера, далее на нём создать виртуальную машину, например, с ОС CentOS и в ней развернуть oVirt engine. Это может делаться обычно из соображений полного контроля над такой ВМ, но это ошибочное намерение, потому что в таком случае, в дальнейшем 100% будут проблемы с такой управляющей ВМ:

לא ניתן להעביר אותו במסוף oVirt בין מארחים (צמתים) של האשכול;
при миграции средствами KVM через וירש לנדוד, эта ВМ будет недоступна к управлению из консоли oVirt.
хосты кластера нельзя будет вывести в מצב תחזוקה (מצב תחזוקה), אם אתה מעביר את ה-VM הזה ממארח למארח באמצעות וירש לנדוד.

אז עשו הכל לפי הכללים - השתמשו במארח נפרד עבור שרת הניהול של oVirt, או ב-VM עצמאי הפועל עליו, או יותר טוב, עשו כפי שנכתב באפשרות השנייה.

אפשרות 2
התקנת oVirt Engine Appliance על מארח אשכול המנוהל על ידו.

Именно этот вариант будет рассмотрен далее, как более правильный и подходящий в нашем случае.
Требования к такой ВМ описаны ниже, добавлю лишь, что рекомендуется иметь минимум два хоста в инфраструктуре, на которых может быть запущена управляющая ВМ, чтобы сделать её отказоустойчивой. Здесь хотелось бы добавить, что как писал уже в комментариях в предыдущей статье, мне так и не удалось получить מוח מפוצל על מקבץ oVirt של שני מארחים, עם היכולת להפעיל עליהם VMs עם מנוע מתארח.

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

Ссылка на официальную документацию — מדריך מנוע מארח עצמי של oVirt, глава «Deploying the Self-Hosted Engine Using the Command line»

В документе указаны предварительные условия, которые должны быть выполнены перед развёртыванием hosted-engine ВМ, а также детально расписан сам процесс её установки, так что повторять его дословно нет особого смысла, поэтому акцентируем внимание не некоторых важных деталях.

Перед началом всех действий, обязательно включаем поддержку виртуализации в настройках BIOS на хосте.
התקן את החבילה עבור מתקין המנוע המתארח במארח:

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 במסך במארח (תוכל לצאת ממנו באמצעות 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 работающая внутри этой ВМ)
и др. параметры.

כדי להתקין VM זמין במיוחד עם מנוע מתארח, יצרנו בעבר LUN מיוחד על מערכת האחסון, בגודל מספר 4 ו-150 GB, שהוצג לאחר מכן למארחי האשכול - ראה מאמר קודם.

בעבר בדקנו גם את הנראות שלו במארחים:

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

תהליך פריסת המנוע המתארח עצמו אינו מסובך; בסופו אנו אמורים לקבל משהו כזה:

[ 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 על צמתי האשכול מראש באמצעות חבילות libvirt и qemu-kvm (או qemu-kvm-ev) желаемой версии, хотя при развёртывании узла кластера oVirt, он может это сделать и сам.

אבל אם libvirt и qemu-kvm были установлены не самой свежей версии, то можно получить такую ошибку во время развёртывания hosted engine:

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

Т.е. необходимо иметь обновлённую версию libvirt עם הגנה מפני 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'/>

לאחר מכן, תוכל להמשיך להתקין את המנוע המתארח.

2) ב-oVirt 4.3, הנוכחות והשימוש בחומת אש firewalld является обязательным требованием.

אם במהלך הפריסה של VM עבור מנוע מתארח נקבל את השגיאה הבאה:

[ 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

לאחר מכן עליך לכבות חומת אש נוספת (אם נעשה בה שימוש), ולהתקין ולהפעיל firewalld:

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 על מארח חדש עבור האשכול, הוא יגדיר את היציאות הנדרשות ב firewalld באופן אוטומטי.

3) אתחול מארח עם VM שפועל עליו עם מנוע מתארח.

כרגיל קישור 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

אם ה-VM שלנו עם מנוע מתארח לא מופעל ואם אנו רואים שגיאות דומות ביומן השירות:

שגיאה ביומן השירות:

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

לאחר הפעלת ה-VM עם מנוע מתארח, אנו מוציאים אותו ממצב תחזוקה:

הליך להסרת VM ממצב תחזוקה:

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 и всего с ней связанного.

לפעמים יש צורך להסיר כראוי מנוע מתארח שהותקן בעבר - קשר למסמך ההנחיות.

Просто выполняем команду на хосте:

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

לאחר מכן, אנו מסירים חבילות מיותרות, ומגבים כמה הגדרות לפני זה, במידת הצורך:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

Создание нового датацентра

תיעוד עזר - מדריך ניהול oVirt. Chapter 4: Data Centers

Сначала определим, что такое מרכז הנתונים (אני מצטט מהעזרה) היא ישות לוגית המגדירה קבוצה של משאבים המשמשים בסביבה ספציפית.

Датацентр — это своего рода контейнер, состоящий из:

логических ресурсов в виде кластеров и хостов
сетевых ресурсов кластера в виде логических сетей и физических адаптеров на хостах,
משאבי אחסון (עבור דיסקים VM, תבניות, תמונות) בצורה של אזורי אחסון (Storage Domains).

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

מרכז הנתונים, או מרכזי הנתונים אם ישנם כמה מהם, מנוהלים ממסוף ניהול או פורטל אחד.

Чтобы создать датацентр, заходим в административный портал и создаём новый датацентр:
לחשב >> מרכזי נתונים >> חדש

Так как у нас используется общее хранилище на СХД, то тип хранилища (Storage Type) должен быть Shared:

צילום מסך של אשף יצירת מרכז הנתונים

При установке виртуальной машины с hosted-engine, по умолчанию создаётся датацентр – מרכז נתונים 1, и далее при необходимости у него можно поменять тип хранилища (Storage Type) на другой.

יצירת מרכז נתונים היא משימה פשוטה, ללא ניואנסים מסובכים, וכל הפעולות הנוספות איתו מתוארות בתיעוד. הדבר היחיד שאציין הוא שמארחים בודדים שיש להם רק אחסון מקומי (דיסק) ל-VMs לא יוכלו להיכנס למרכז נתונים עם Storage Type - Shared (לא ניתן להוסיף אותם שם), ועבורם צריך ליצור מרכז נתונים נפרד - כלומר. כל מארח בודד עם אחסון מקומי צריך מרכז נתונים נפרד משלו.

Создание нового кластера

קישור לתיעוד - מדריך ניהול oVirt. Chapter 5: Clusters

Без излишних подробностей, אשכול – это логическая группировка хостов, имеющих общую область хранения (в виде общих дисков на СХД, как в нашем случае). Также желательно, чтобы хосты в кластере были идентичны по железу, и имели бы одинаковый тип процессора (Intel или AMD). Лучше всего конечно, чтобы сервера в кластере были полностью одинаковыми.

האשכול הוא חלק ממרכז נתונים (עם סוג מסוים של אחסון - מקומי או משותף), וכל המארחים חייבים להיות שייכים לאשכול כלשהו, תלוי אם יש להם אחסון משותף או לא.

בעת התקנת מכונה וירטואלית עם מנוע מתארח על מארח, מרכז נתונים נוצר כברירת מחדל - מרכז נתונים 1, вместе с кластером – אשכול 1, ובעתיד תוכל להגדיר את הפרמטרים שלו, להפעיל אפשרויות נוספות, להוסיף לו מארחים וכו'.

Как обычно, для получения подробностей о всех настройках кластера, желательно обратиться к официальной документации. Из каких-то особенностей настройки кластера, добавлю лишь, что при его создании достаточно настроить только основные параметры на вкладке כללי.

אציין את הפרמטרים החשובים ביותר:

סוג מעבד — נבחר על סמך אילו מעבדים מותקנים במארחי האשכול, מאיזה יצרן הם, ואיזה מעבד במארחים הוא הישן ביותר, כך שבהתאם לכך, נעשה שימוש בכל הוראות המעבד הזמינות באשכול.
סוג המתג – у нас в кластере используется только Linux bridge, поэтому его и выбираем.
Firewall type – тут всё понятно, это firewalld, который должен быть включен и настроен на хостах.

צילום מסך עם פרמטרי אשכול

Установка дополнительных хостов в Self-Hosted окружении

קשר на документацию.

Дополнительные хосты для Self-Hosted окружения, добавляются так же, как и обычный хост, с выполнением дополнительного пункта по развертыванию ВМ с hosted engine — Choose hosted engine deployment action >> לפרוס. Так как дополнительному хосту тоже должен быть презентован LUN для ВМ с hosted engine, то это значит, что этот хост можно при необходимости использовать для размещения на нём ВМ с hosted engine.
למטרות סובלנות תקלות, מומלץ מאוד שיהיו לפחות שני מארחים שעליהם ניתן למקם VM מנוע מתארח.

На дополнительном хосте отключаем 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 в данный момент активна, имеет золотую корону и надпись «הפעלת Hosted Engine VM», хост, на котором эта ВМ может быть запущена при необходимости – надпись «יכול להפעיל את Hosted Engine VM".

В случае сбоя хоста на котором «הפעלת Hosted Engine VM", הוא יופעל מחדש באופן אוטומטי במארח השני. ניתן גם להעביר את ה-VM הזה מהמארח הפעיל למארח המתנה לצורך תחזוקה שלו.

Настройка Power Management / fencing на хостах oVirt

Ссылки на документацию:

Red Hat Virtualization 4.3 –> Technical Reference -> Chapter 4. Power Management
מדריך ניהול oVirt -> Chapter 7: Hosts

Хотя может показаться, что добавление и настройка хоста выполнены, но это не совсем так.
Для нормальной работы хостов, и выявления/устранения сбоев с кем-либо из них, необходима настройка Power Management / fencing.

סייף, או גידור, הוא תהליך של אי הכללה זמנית של מארח פגום או פגום מהאשכול, שבמהלכו מופעלים מחדש או שירותי oVirt שבו או המארח עצמו.

כל הפרטים על ההגדרות והפרמטרים של ניהול צריכת חשמל / גידור ניתנים, כרגיל, בתיעוד; אני אתן רק דוגמה כיצד להגדיר פרמטר חשוב זה, כפי שהוחל על שרתי Dell R640 עם iDRAC 9.

Заходим в административный портал, кликаем לחשב >> מארחים בחר מארח.
אנחנו לוחצים ערוך.
לחץ על הכרטיסייה ניהול צריכת חשמל.
סמן את התיבה שליד האפשרות Enable Power Management.
סמן את התיבה שליד האפשרות Kdump integrationכדי למנוע מהמארח להיכנס למצב גידור בזמן הקלטת dump של התרסקות ליבה.

הערה.

После включения Kdump integration на уже работающем хосте, он должен быть переустановлен в соответствии с процедурой в oVirt Administration Guide -> Chapter 7: Hosts -> התקנה מחדש של מארחים.

Опционально можно отметить флажок Disable policy control of power management, אם אנחנו לא רוצים שניהול צריכת החשמל של המארח יהיה נשלט על ידי מדיניות התזמון של האשכול.
לחץ על הכפתור (+) כדי להוסיף התקן חדש לניהול צריכת חשמל, ייפתח חלון עריכת מאפייני הסוכן.
Для iDRAC9, заполняем поля:
- כתובת - כתובת iDRAC9
- שם משתמש סיסמא – соответственно логин и пароль для входа в iDRAC9
- סוּג — drac5
- סימן לאבטח
- добавить следующие опции: cmd_prompt=>,login_timeout=30

צילום מסך עם פרמטרים של "ניהול צריכת חשמל" במאפייני המארח

יצירת אזור אחסון או Storage Domains

קישור לתיעוד - מדריך ניהול oVirt, Chapter 8: Storage.

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

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

У oVirt имеется три типа области хранения:

דומיין נתונים - לאחסן את כל הנתונים הקשורים למכונות וירטואליות (דיסקים, תבניות). לא ניתן לשתף את דומיין הנתונים בין מרכזי נתונים שונים.
ISO Domain (סוג מיושן של אזור אחסון) - לאחסון תמונות התקנת מערכת ההפעלה. ISO Domain ניתן לשיתוף בין מרכזי נתונים שונים.
ייצוא דומיין (устаревший тип области хранения) – для временного хранения образов, перемещаемых между датацентрами.

במקרה הספציפי שלנו, אזור אחסון מסוג Data Domain משתמש ב-Fibre Channel Protocol (FCP) כדי להתחבר ל-LUNs במערכת האחסון.

מנקודת המבט של oVirt, בעת שימוש במערכות אחסון (FC או iSCSI), כל דיסק וירטואלי, תמונת מצב או תבנית הם דיסק לוגי.
Блочные устройства собираются в одно целое (на хостах кластера) с помощью Volume Group и затем разделяются с помощью LVM на логические тома, используемые как виртуальные диски для ВМ.

ניתן לראות את כל הקבוצות הללו וכרכים רבים של LVM על מארח האשכול באמצעות הפקודות וכו и lvs. באופן טבעי, כל הפעולות עם דיסקים כאלה צריכות להיעשות רק ממסוף oVirt, למעט מקרים מיוחדים.

Виртуальные диски для ВМ могут быть двух типов — QCOW2 или RAW. Диски могут быть "רזה"או"עבה". תמונות בזק נוצרות תמיד כ"רזה".

הדרך לנהל דומיינים של Storage, או אזורי אחסון אליהם מגיעים דרך FC, היא הגיונית למדי – לכל דיסק וירטואלי של VM ישנו אמצעי אחסון לוגי נפרד שניתן לכתיבה על ידי מארח אחד בלבד. עבור חיבורי FC, oVirt משתמש במשהו כמו LVM מקובץ.

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

כפי שאנו יכולים לראות מהתיאור, אשכול ב-oVirt, כמו אשכול ב-VMware vSphere או Hyper-V, פירושו בעצם אותו הדבר - זהו קיבוץ לוגי של מארחים, רצוי זהים בהרכב החומרה, ובעל אחסון משותף לווירטואלי. דיסקים של מכונה.

נמשיך ישירות ליצירת אזור אחסון לנתונים (דיסקים VM), שכן בלעדיו מרכז הנתונים לא יאתחל.
הרשה לי להזכיר לך שכל ה-LUNs המוצגים למארחי האשכול במערכת האחסון חייבים להיות גלויים עליהם באמצעות הפקודה "multipath -ll".

על פי תיעוד, עבור לפורטל עבור אל אחסון >> תחומים -> דומיין חדש и выполняем инструкции из раздела "Adding FCP Storage".

После запуска мастера, заполняем требуемые поля:

שם — задаём имя кластера
Domain Function -נתונים
סוג אחסון — Fibre Channel
Host to Use — выбираем хост, на котором доступен требуемый нам LUN

В списке LUN’ов отмечаем нужный нам, кликаем להוסיף ואז ОК. При необходимости можно скорректировать дополнительные параметры области хранения, кликнув на פרמטרים מתקדמים.

Скриншот мастера по добавлению «Storage domain»

По результатам работы мастера, мы должны получить новую область хранения, а наш датацентр перейти в статус UP, או אתחול:

צילומי מסך של מרכז הנתונים ואזורי האחסון בו:

יצירה והגדרת רשתות עבור מכונות וירטואליות

קישור לתיעוד - מדריך ניהול oVirt, Chapter 6: Logical Networks

רשתות, או רשתות, משמשות לקיבוץ רשתות לוגיות המשמשות בתשתית הוירטואלית oVirt.

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

כדי לקבץ ולחלק תעבורה בין רשתות, רשתות VLAN מוגדרות על המתגים.

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

Предварительные настройки сетевых адаптеров на хостах для подключения виртуальных машин должны были быть выполнены в מאמר קודם - ממשק לוגי מוגדר bond1, אז כל הגדרות הרשת צריכות להתבצע רק דרך הפורטל הניהולי של oVirt.

После создания ВМ с hosted-engine, помимо автоматического создания датацентра и кластера, также автоматически создалась и логическая сеть для управления нашим кластером – ovritmgmt, שאליו היה מחובר VM זה.

При необходимости можно посмотреть настройки логической сети ovritmgmt и скорректировать их, но надо быть осторожным, чтобы не потерять управление инфраструктурой oVirt.

Настройки логической сети ovritmgmt

כדי ליצור רשת לוגית חדשה עבור VMs רגילים, בפורטל הניהולי עבור אל רשת >> רשתות >> חדש, и на вкладке כללי הוסף רשת עם מזהה VLAN הרצוי, וסמן גם את התיבה שליד "רשת VM», это означает что её можно использовать для назначения на ВМ.

צילום מסך של הרשת הלוגית החדשה VLAN32

כרטיסייה אשכול, прикрепляем эту сеть к нашему кластеру אשכול 1.

אחרי זה אנחנו הולכים ל לחשב >> מארחים, עבור לכל מארח בתורו, לכרטיסייה ממשקי רשת, והפעל את האשף הגדר רשתות מארחות, כדי להיקשר למארחים של רשת לוגית חדשה.

צילום מסך של אשף "הגדר רשתות מארחות".

סוכן 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.

לאחר הוספת רשת לוגית ובדיקת החיבור בין המארח והמנוע ה-VM המתארח, ניתן להשתמש בה במכונה הוירטואלית.

Создание установочного образа для развёртывания виртуальной машины

קישור לתיעוד - מדריך ניהול oVirt, Chapter 8: Storage, раздел Uploading Images to a Data Storage Domain.

Без установочного образа ОС, не удастся установить виртуальную машину, хотя это конечно и не является проблемой, если в сети установлен, например, סַנדְלָר с заранее созданными образами.

במקרה שלנו, זה לא אפשרי, אז תצטרך לייבא תמונה זו לתוך oVirt בעצמך. בעבר, זה הצריך יצירת ISO Domain, אך בגרסה החדשה של oVirt הוא הוצא משימוש, ולכן כעת ניתן להעלות תמונות ישירות לתחום Storage מהפורטל הניהולי.

В административном портале идём в אחסון >> דיסקים >> העלה >> הַתחָלָה
אנו מוסיפים את תמונת מערכת ההפעלה שלנו כקובץ 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 לאחסון תמונות ותבניות בנפרד מדיסקים של VM, או אפילו לאחסן אותם ב-Storage Domain עבור המנוע המתארח, אך הדבר נתון לשיקול דעתו של המנהל.

צילום מסך עם תמונות ISO ב-Storage Domain עבור מנוע מתארח

צור מכונה וירטואלית

קישור לתיעוד:
oVirt מדריך לניהול מכונות וירטואליות –> Chapter 2: Installing Linux Virtual Machines
Console Clients Resources

После загрузки в oVirt установочного образа с ОС, можно переходить непосредственно к созданию виртуальной машины. Много было работы проделано, но мы уже находимся на завершающем этапе, ради чего всё это и затевалось – получение отказоустойчивой инфраструктуры для хостинга высокодоступных виртуальных машин. И причём всё это абсолютно бесплатно – ни одной копейки на приобретение каких-либо лицензий на ПО, не было потрачено.

Для создания виртуальной машины с CentOS 7, должен быть загружен установочный образ с ОС.

Заходим в административный портал, идём в לחשב >> מכונות וירטואליות, והפעל את אשף יצירת ה-VM. מלא את כל הפרמטרים והשדות ולחץ ОК. Всё очень просто, если следовать документации.

כדוגמה, אתן את ההגדרות הבסיסיות והנוספות של VM זמין במיוחד, עם דיסק שנוצר, מחובר לרשת, ואתחול מתמונת התקנה:

צילומי מסך עם הגדרות VM זמינות במיוחד

После окончания работ с мастером, закрываем его, запускаем новую ВМ и устанавливаем на неё ОС.
כדי לעשות זאת, עבור אל המסוף של VM זה דרך הפורטל הניהולי:

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

Чтобы подключиться к консоли ВМ, предварительно надо настроить консоль в свойствах виртуальной машины.

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

Для подключения к консоли ВМ можно использовать, например, מציג מכונות וירטואליות.

כדי להתחבר למסוף ה-VM ישירות בחלון הדפדפן, הגדרות החיבור דרך המסוף צריכות להיות כדלקמן:

לאחר התקנת מערכת ההפעלה ב-VM, רצוי להתקין את סוכן האורח של oVirt:

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

לפיכך, כתוצאה מהפעולות שלנו, ה-VM שנוצר יהיה זמין מאוד, כלומר. אם צומת האשכול עליו הוא פועל נכשל, oVirt תאתחל אותו אוטומטית בצומת השני. ניתן גם להעביר VM זה בין מארחי אשכולות למטרות תחזוקה או אחרות.

מסקנה

Надеюсь, что этой статьёй удалось донести, что oVirt – вполне нормальный инструмент по управлению виртуальной инфраструктурой, который развернуть не так и сложно — главное соблюдать определённые правила и требования, описанные как в статье, так и в документации.

בגלל הנפח הרב של המאמר לא ניתן היה לכלול בו הרבה דברים כמו ביצוע צעד אחר צעד של אשפים שונים עם כל ההסברים המפורטים וצילומי המסך, מסקנות ארוכות של כמה פקודות וכו'. למעשה, זה ידרוש כתיבת ספר שלם, וזה לא הגיוני במיוחד בגלל שגרסאות חדשות של תוכנה מופיעות כל הזמן עם חידושים ושינויים. הדבר החשוב ביותר הוא להבין את העיקרון של איך הכל עובד ביחד, ולקבל אלגוריתם כללי ליצירת פלטפורמה סובלנית לתקלות לניהול מכונות וירטואליות.

למרות שיצרנו תשתית וירטואלית, כעת עלינו ללמד אותה לקיים אינטראקציה הן בין האלמנטים האישיים שלה: מארחים, מכונות וירטואליות, רשתות פנימיות ועם העולם החיצון.

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

מקור: www.habr.com

יצירת תשתית IT עמידה בפני תקלות. חלק 2. התקנה והגדרה של אשכול oVirt 4.3