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

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

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

חלק מבוא

המטרה העיקרית של המאמר היא לספק הוראות שלב אחר שלב כמו "הַבָּא -> יש -> עוד רגע והחנות באוויר"כיצד להציג תכונות מסוימות בעת התקנה והגדרת התצורה שלה. ייתכן שתהליך פריסת האשכול שלך לא תמיד עולה בקנה אחד עם המתואר בו, בשל מאפייני התשתית והסביבה, אך העקרונות הכלליים יהיו זהים.

מנקודת מבט סובייקטיבית, oVirt4.3 הפונקציונליות שלו דומה ל-VMware vSphere גרסה 5.x, אבל כמובן עם תכונות תצורה ותפעול משלה.

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

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

• באמצעות גשר לינוקס סטנדרטי (ב-VMware - vSwitch רגיל), פועל על מארחי וירטואליזציה;
• באמצעות Open vSwitch (OVS) (ב-VMware - vSwitch מבוזר) הוא מתג וירטואלי מבוזר המורכב משני רכיבים עיקריים: שרת OVN מרכזי ובקרי OVN במארחים מנוהלים.

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

בהקשר זה, ישנם מספר כללים בסיסיים לעבודה עם הרשת באשכול, שעדיף לא להפר אותם:

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

עוד אחד הערה חשובה - עבור סביבה קריטית מאוד (רגישה מאוד להפסדים כספיים), עדיין מומלץ להשתמש בתמיכה ושימוש בתשלום Red Hat Virtualization 4.3. במהלך הפעלת אשכול oVirt עלולות להתעורר בעיות מסוימות שבגינן מומלץ לקבל עזרה מוסמכת בהקדם האפשרי, במקום לטפל בהן בעצמך.

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

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

• מדריך ההתקנה של oVirt
• מדריך מנוע מארח עצמי של oVirt
• מדריך ניהול oVirt
  

הנפח שם לא גדול במיוחד, תוך שעה-שעתיים אפשר די לשלוט בעקרונות הבסיסיים, אבל למי שאוהב פרטים מומלץ לקרוא תיעוד מוצר עבור Red Hat Virtualization 4.3 - RHEV ו-oVirt הם בעצם אותו דבר.

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

חלק 2. התקנה והגדרה של אשכול oVirt 4.3

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

1. התקנת שרת הניהול oVirt
2. הקמת מרכז נתונים חדש
3. יצירת אשכול חדש
4. התקנת מארחים נוספים בסביבה Self Hosted
5. יצירת אזור אחסון או Storage Domains
6. יצירה והגדרת רשתות עבור מכונות וירטואליות
7. יצירת תמונת התקנה לפריסת מכונה וירטואלית
8. צור מכונה וירטואלית

התקנת שרת הניהול oVirt

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

האנלוגים הקרובים שלו מעולם הוירטואליזציה הם:

• VMware vSphere - שרת vCenter
• Microsoft Hyper-V - מנהל מחשב וירטואלי של מרכז המערכת (VMM).

להתקנת שרת הניהול oVirt, יש לנו שתי אפשרויות:

אפשרות 1
פריסת שרת בצורה של VM מיוחד או מארח.

אפשרות זו עובדת די טוב, אבל בתנאי ש-VM כזה פועל ללא תלות באשכול, כלומר. אינו פועל על אף מארח אשכול כמכונה וירטואלית רגילה המריץ KVM.

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

ממש בתחילת תהליך הפריסה של שרת הניהול oVirt יש לנו דילמה - אנחנו צריכים להתקין VM לניהול, אבל למעשה אין עדיין אשכול עצמו, ולכן מה אנחנו יכולים להמציא תוך כדי תנועה? זה נכון - התקן KVM על צומת אשכול עתידי, ואז צור בו מכונה וירטואלית, למשל, עם CentOS OS ופרוס בו את מנוע oVirt. זה יכול להיעשות בדרך כלל מסיבות של שליטה מלאה ב-VM כזה, אבל זו כוונה מוטעית, מכיוון שבמקרה זה, בעתיד יהיו 100% בעיות ב-VM כזה:

• לא ניתן להעביר אותו במסוף oVirt בין מארחים (צמתים) של האשכול;
• בעת הגירה באמצעות KVM via וירש לנדוד, VM זה לא יהיה זמין לניהול ממסוף oVirt.
• לא ניתן להציג מארחי אשכולות מצב תחזוקה (מצב תחזוקה), אם אתה מעביר את ה-VM הזה ממארח ​​למארח באמצעות וירש לנדוד.

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

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

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

התקנת oVirt Engine Appliance על המארח הראשון של האשכול

קישור לתיעוד רשמי - מדריך מנוע מארח עצמי של oVirt, פרק "פריסת המנוע המתארח בעצמו באמצעות שורת הפקודה»

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

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

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

- имя кластера
- количество 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 מהמחשב של המנהל, ולחץ על [פורטל ניהול].

צילום מסך של "פורטל ניהול"

בהזנת הכניסה והסיסמה (שנקבעו במהלך תהליך ההתקנה) לחלון כמו בצילום המסך, נגיע ללוח הבקרה של Open Virtualization Manager, בו ניתן לבצע את כל הפעולות עם התשתית הוירטואלית:

1. להוסיף מרכז נתונים
2. להוסיף ולהגדיר אשכול
3. להוסיף ולנהל מארחים
4. הוסף אזורי אחסון או Storage Domains עבור דיסקים של מכונות וירטואליות
5. להוסיף ולהגדיר רשתות עבור מכונות וירטואליות
6. להוסיף ולנהל מכונות וירטואליות, תמונות התקנה, תבניות VM

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

תוספת

1) באופן עקרוני, אם יש צורך כזה, אז שום דבר לא מונע ממך להתקין את היפרוויזר KVM על צמתי האשכול מראש באמצעות חבילות libvirt и qemu-kvm (או qemu-kvm-ev) של הגרסה הרצויה, אם כי בעת פריסת צומת אשכול oVirt, הוא יכול לעשות זאת בעצמו.

אבל אם libvirt и qemu-kvm אם לא התקנת את הגרסה העדכנית ביותר, ייתכן שתקבל את השגיאה הבאה בעת פריסת מנוע מתארח:

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 למסמכים מנהליים.

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

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

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

אנחנו מאתחלים את המארח עם סוכן המנוע המתארח ועושים איתו מה שאנחנו צריכים.

לאחר אתחול מחדש, בדוק את מצב ה-VM עם המנוע המתארח:

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) הסרת המנוע המתארח וכל מה שקשור אליו.

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

פשוט הפעל את הפקודה על המארח:

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

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

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

הקמת מרכז נתונים חדש

תיעוד עזר - מדריך ניהול oVirt. פרק 4: מרכזי נתונים

ראשית בואו נגדיר מה זה מרכז הנתונים (אני מצטט מהעזרה) היא ישות לוגית המגדירה קבוצה של משאבים המשמשים בסביבה ספציפית.

מרכז נתונים הוא סוג של מיכל המורכב מ:

• משאבים לוגיים בצורה של אשכולות ומארחים
• מקבץ משאבי רשת בצורה של רשתות לוגיות ומתאמים פיזיים במארחים,
• משאבי אחסון (עבור דיסקים VM, תבניות, תמונות) בצורה של אזורי אחסון (Storage Domains).

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

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

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

מכיוון שאנו משתמשים באחסון משותף במערכת האחסון, סוג האחסון צריך להיות משותף:

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

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

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

יצירת אשכול חדש

קישור לתיעוד - מדריך ניהול oVirt. פרק 5: אשכולות

בלי פרטים מיותרים, אשכול – זהו קיבוץ לוגי של מארחים בעלי אזור אחסון משותף (בצורה של דיסקים משותפים במערכת אחסון, כמו במקרה שלנו). כמו כן, רצוי שהמארחים באשכול יהיו זהים בחומרה ובעלי אותו סוג מעבד (Intel או AMD). עדיף, כמובן, שהשרתים באשכול יהיו זהים לחלוטין.

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

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

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

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

• סוג מעבד — נבחר על סמך אילו מעבדים מותקנים במארחי האשכול, מאיזה יצרן הם, ואיזה מעבד במארחים הוא הישן ביותר, כך שבהתאם לכך, נעשה שימוש בכל הוראות המעבד הזמינות באשכול.
• סוג המתג - באשכול שלנו אנחנו משתמשים רק ב-Linux bridge, זו הסיבה שאנחנו בוחרים בו.
• סוג חומת אש - הכל ברור כאן, זו חומת אש, שיש להפעיל ולהגדיר במארחים.

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

התקנת מארחים נוספים בסביבה Self Hosted

קשר לתיעוד.

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

במארח הנוסף, השבת את iptables (אם מופעל), הפעל חומת אש

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

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

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

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

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

צילום מסך של הפורטל האדמיניסטרטיבי - מארחים

המארח שעליו פועל כעת ה-VM עם המנוע המתארח בעל כתר זהב והכיתוב "הפעלת Hosted Engine VM", המארח שעליו ניתן להפעיל את ה-VM הזה במידת הצורך - הכתובת "יכול להפעיל את Hosted Engine VM".

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

הגדרת ניהול צריכת חשמל / גידור במארחי oVirt

קישורי תיעוד:

• Red Hat Virtualization 4.3 –> הפניה טכנית -> פרק 4. ניהול חשמל
• מדריך ניהול oVirt -> פרק 7: מארחים

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

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

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

1. עבור לפורטל הניהולי, לחץ לחשב >> מארחים בחר מארח.
2. אנחנו לוחצים ערוך.
3. לחץ על הכרטיסייה ניהול צריכת חשמל.
4. סמן את התיבה שליד האפשרות אפשר ניהול צריכת חשמל.
5. סמן את התיבה שליד האפשרות אינטגרציה של Kdumpכדי למנוע מהמארח להיכנס למצב גידור בזמן הקלטת dump של התרסקות ליבה.

הערה.

לאחר הפעלת שילוב Kdump במארח שכבר פועל, יש להתקין אותו מחדש בהתאם להליך במדריך הניהול של oVirt -> פרק 7: מארחים -> התקנה מחדש של מארחים.

1. לחלופין, אתה יכול לסמן את התיבה השבת את בקרת המדיניות של ניהול צריכת החשמל, אם אנחנו לא רוצים שניהול צריכת החשמל של המארח יהיה נשלט על ידי מדיניות התזמון של האשכול.
2. לחץ על הכפתור (+) כדי להוסיף התקן חדש לניהול צריכת חשמל, ייפתח חלון עריכת מאפייני הסוכן.
   עבור iDRAC9, מלא את השדות:
   • כתובת - כתובת iDRAC9
   • שם משתמש סיסמא - כניסה וסיסמה לכניסה ל-iDRAC9, בהתאמה
   • סוּג -drac5
   • סימן לאבטח
   • הוסף את האפשרויות הבאות: cmd_prompt=>,login_timeout=30

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

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

קישור לתיעוד - מדריך ניהול oVirt, פרק 8: אחסון.

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

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

ל-oVirt יש שלושה סוגים של אזורי אחסון:

• דומיין נתונים - לאחסן את כל הנתונים הקשורים למכונות וירטואליות (דיסקים, תבניות). לא ניתן לשתף את דומיין הנתונים בין מרכזי נתונים שונים.
• דומיין ISO (סוג מיושן של אזור אחסון) - לאחסון תמונות התקנת מערכת ההפעלה. ISO Domain ניתן לשיתוף בין מרכזי נתונים שונים.
• ייצוא דומיין (סוג מיושן של אזור אחסון) - לאחסון זמני של תמונות המועברות בין מרכזי נתונים.

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

מנקודת המבט של oVirt, בעת שימוש במערכות אחסון (FC או iSCSI), כל דיסק וירטואלי, תמונת מצב או תבנית הם דיסק לוגי.
התקני בלוק מורכבים ליחידה אחת (במארחי אשכול) באמצעות Volume Group ולאחר מכן מחולקים באמצעות LVM לנפחים לוגיים, המשמשים כדיסקים וירטואליים עבור VMs.

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

דיסקים וירטואליים עבור VMs יכולים להיות משני סוגים - QCOW2 או RAW. דיסקים עשויים להיות "רזה"או"עבה". תמונות בזק נוצרות תמיד כ"רזה".

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

ניתן להעביר מכונות וירטואליות הממוקמות באותו אזור אחסון בין מארחים השייכים לאותו אשכול.

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

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

על פי תיעוד, עבור לפורטל עבור אל אחסון >> תחומים -> דומיין חדש ופעל לפי ההוראות מהסעיף "הוספת אחסון FCP".

לאחר הפעלת האשף, מלא את השדות הנדרשים:

• שם - הגדר את שם האשכול
• פונקציית דומיין -נתונים
• סוג אחסון - ערוץ סיבים
• מארח לשימוש - בחר מארח שבו ה-LUN שאנו דורשים זמין

ברשימת ה-LUN, סמן את זה שאנו צריכים, לחץ להוסיף ואז ОК. במידת הצורך, ניתן להתאים פרמטרים נוספים של אזור האחסון על ידי לחיצה על פרמטרים מתקדמים.

צילום מסך של האשף להוספת "דומיין אחסון"

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

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

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

קישור לתיעוד - מדריך ניהול oVirt, פרק 6: רשתות לוגיות

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

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

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

בעת יצירת רשת לוגית עבור מכונות וירטואליות ב-oVirt, יש להקצות לה מזהה המתאים למספר ה-VLAN על המתג, כך שה-VMs יוכלו לתקשר זה עם זה, גם אם הם פועלים בצמתים שונים של האשכול.

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

לאחר יצירת VM עם מנוע מתארח, בנוסף ליצירה האוטומטית של מרכז נתונים ואשכול, נוצרה אוטומטית גם רשת לוגית לניהול האשכול שלנו - ovritmgmt, שאליו היה מחובר VM זה.

במידת הצורך, תוכל להציג את הגדרות הרשת הלוגיות ovritmgmt ולהתאים אותם, אך עליך להיזהר לא לאבד שליטה על תשתית oVirt.

הגדרות רשת לוגיות ovritmgmt

כדי ליצור רשת לוגית חדשה עבור VMs רגילים, בפורטל הניהולי עבור אל רשת >> רשתות >> חדש, ובכרטיסייה כללי הוסף רשת עם מזהה VLAN הרצוי, וסמן גם את התיבה שליד "רשת VM", זה אומר שניתן להשתמש בו להקצאה ל-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, פרק 8: אחסון, סעיף העלאת תמונות לתחום אחסון נתונים.

ללא תמונת התקנת מערכת ההפעלה, לא ניתן יהיה להתקין מכונה וירטואלית, אם כי זו כמובן לא בעיה אם, למשל, מותקן ברשת סַנדְלָר עם תמונות שנוצרו מראש.

במקרה שלנו, זה לא אפשרי, אז תצטרך לייבא תמונה זו לתוך 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 ל"CAs שורש מהימנים"(Trusted Root CA) בתחנת הבקרה של המנהל, ממנה אנו מנסים להוריד את התמונה.

לאחר הוספת האישור ל-CA Root מהימן, לחץ שוב על "בדיקת חיבור", אמור לקבל:

Connection to ovirt-imageio-proxy was successful.

לאחר שתשלים את פעולת הוספת האישור, תוכל לנסות להעלות שוב את תמונת ה-ISO ל- Storage Domain.

באופן עקרוני, ניתן ליצור Storage Domain נפרד מסוג Data לאחסון תמונות ותבניות בנפרד מדיסקים של VM, או אפילו לאחסן אותם ב-Storage Domain עבור המנוע המתארח, אך הדבר נתון לשיקול דעתו של המנהל.

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

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

קישור לתיעוד:
oVirt מדריך לניהול מכונות וירטואליות –> פרק 2: התקנת מכונות וירטואליות של לינוקס
משאבי לקוחות מסוף

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

כדי ליצור מכונה וירטואלית עם CentOS 7, יש להוריד את תמונת ההתקנה ממערכת ההפעלה.

אנחנו הולכים לפורטל האדמיניסטרטיבי, עבור אל לחשב >> מכונות וירטואליות, והפעל את אשף יצירת ה-VM. מלא את כל הפרמטרים והשדות ולחץ ОК. הכל מאוד פשוט אם אתה עוקב אחר התיעוד.

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

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

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

צילום מסך של הגדרות הפורטל הניהולי לחיבור לקונסולת ה-VM

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

צילום מסך של הגדרות VM, כרטיסיית "קונסול".

כדי להתחבר למסוף ה-VM אתה יכול להשתמש, למשל, מציג מכונות וירטואליות.

כדי להתחבר למסוף ה-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