შეცდომის ტოლერანტული IT ინფრასტრუქტურის შექმნა. ნაწილი 2. oVirt 4.3 კლასტერის ინსტალაცია და კონფიგურაცია

ეს სტატია წინა სტატიის გაგრძელებაა - ”შეცდომის ტოლერანტული IT ინფრასტრუქტურის შექმნა. ნაწილი 1 - მზადება oVirt 4.3 კლასტერის განსათავსებლად".

იგი მოიცავს oVirt 4.3 კლასტერის საბაზისო ინსტალაციისა და კონფიგურაციის პროცესს მაღალ ხელმისაწვდომი ვირტუალური მანქანების ჰოსტინგისთვის, იმის გათვალისწინებით, რომ ინფრასტრუქტურის მომზადების ყველა წინასწარი ნაბიჯი უკვე დასრულებულია.

შესავალი

სტატიის მთავარი მიზანია მიაწოდოს ნაბიჯ-ნაბიჯ ინსტრუქციები, როგორიცაა "შემდეგი -> დიახ -> ფერი"როგორ ვაჩვენოთ ზოგიერთი ფუნქცია მისი ინსტალაციისა და კონფიგურაციისას. თქვენი კლასტერის განლაგების პროცესი შეიძლება ყოველთვის არ ემთხვეოდეს მასში აღწერილს, ინფრასტრუქტურისა და გარემოს მახასიათებლების გამო, მაგრამ ზოგადი პრინციპები იგივე იქნება.

სუბიექტური თვალსაზრისით, oVirt 4.3 მისი ფუნქციონალობა მსგავსია VMware vSphere ვერსიის 5.x-ის, მაგრამ რა თქმა უნდა თავისი კონფიგურაციისა და ფუნქციონირების მახასიათებლებით.

დაინტერესებულთათვის, ყველა განსხვავება RHEV (aka oVirt) და VMware vSphere-ს შორის შეგიძლიათ ნახოთ ინტერნეტში, მაგალითად. აქ, მაგრამ მე მაინც დროდადრო აღვნიშნავ მათ ზოგიერთ განსხვავებას ან მსგავსებას ერთმანეთთან, როგორც სტატია ვითარდება.

ცალკე, მსურს შევადაროთ მუშაობა ქსელებთან ვირტუალური მანქანებისთვის. oVirt ახორციელებს ქსელის მართვის მსგავს პრინციპს ვირტუალური მანქანებისთვის (შემდგომში ვირტუალური მანქანებისთვის), როგორც VMware vSphere-ში:

• სტანდარტული Linux ხიდის გამოყენებით (VMware-ში - სტანდარტული vSwitch), მუშაობს ვირტუალიზაციის ჰოსტებზე;
• Open vSwitch-ის (OVS) გამოყენებით (VMware-ში - განაწილებული vSwitch) არის განაწილებული ვირტუალური გადამრთველი, რომელიც შედგება ორი ძირითადი კომპონენტისგან: ცენტრალური OVN სერვერი და OVN კონტროლერები მართულ ჰოსტებზე.

უნდა აღინიშნოს, რომ განხორციელების სიმარტივის გამო, სტატიაში აღწერილი იქნება ქსელების დაყენება oVirt-ში VM-ისთვის სტანდარტული Linux ხიდის გამოყენებით, რაც სტანდარტული არჩევანია KVM ჰიპერვიზორის გამოყენებისას.

ამასთან დაკავშირებით, არსებობს ქსელთან კლასტერში მუშაობის რამდენიმე ძირითადი წესი, რომლებიც უმჯობესია არ დაირღვეს:

• ყველა ქსელის პარამეტრი ჰოსტებზე მათ oVirt-ში დამატებამდე უნდა იყოს იდენტური, გარდა IP მისამართებისა.
• მას შემდეგ, რაც ჰოსტი მოხვდება oVirt-ის კონტროლის ქვეშ, არ არის რეკომენდებული რაიმეს ხელით შეცვლა ქსელის პარამეტრებში თქვენი მოქმედებების სრული ნდობის გარეშე, რადგან oVirt აგენტი უბრალოდ დააბრუნებს მათ წინაზე ჰოსტის გადატვირთვის შემდეგ ან აგენტი.
• VM-ისთვის ახალი ქსელის დამატება, ისევე როგორც მასთან მუშაობა, უნდა განხორციელდეს მხოლოდ oVirt მართვის კონსოლიდან.

სხვა მნიშვნელოვანი ჩანაწერი - ძალიან კრიტიკული გარემოსთვის (ძალიან მგრძნობიარეა ფულადი დანაკარგების მიმართ), მაინც რეკომენდებული იქნება ფასიანი მხარდაჭერის გამოყენება და გამოყენება Red Hat ვირტუალიზაცია 4.3. oVirt კლასტერის მუშაობისას შეიძლება წარმოიშვას გარკვეული საკითხები, რისთვისაც მიზანშეწონილია მიიღოთ კვალიფიციური დახმარება რაც შეიძლება მალე, ვიდრე თავად გაუმკლავდეთ მათ.

და ბოლოს რეკომენდირებულია oVirt კლასტერის დანერგვამდე, გაეცანით ოფიციალური დოკუმენტაცია, იმისთვის რომ იცოდეთ სულ მცირე ძირითადი ცნებები და განმარტებები, თორემ ცოტა გაგიჭირდებათ სტატიის დარჩენილი ნაწილის წაკითხვა.

სტატიისა და oVirt კლასტერის მოქმედების პრინციპების გასაგებად ძირითადია ეს სახელმძღვანელო დოკუმენტები:

• oVirt ინსტალაციის სახელმძღვანელო
• oVirt Self-Hosted Engine Guide
• oVirt ადმინისტრაციის სახელმძღვანელო
  

მოცულობა იქ არც თუ ისე დიდია, ერთ-ორ საათში შეგიძლიათ საკმაოდ დაეუფლოთ ძირითად პრინციპებს, მაგრამ ვისაც დეტალები მოსწონს, რეკომენდებულია წაიკითხოს პროდუქტის დოკუმენტაცია Red Hat ვირტუალიზაციისთვის 4.3 — RHEV და oVirt არსებითად ერთი და იგივეა.

ასე რომ, თუ ჰოსტების, კონცენტრატორებისა და შენახვის სისტემების ყველა ძირითადი პარამეტრი დასრულებულია, ჩვენ პირდაპირ მივდივართ oVirt-ის განთავსებაზე.

ნაწილი 2. oVirt 4.3 კლასტერის ინსტალაცია და კონფიგურაცია

ორიენტაციის გასაადვილებლად ამ სტატიაში ჩამოვთვლი ძირითად ნაწილებს, რომლებიც სათითაოდ უნდა შევავსოთ:

1. oVirt მართვის სერვერის ინსტალაცია
2. ახალი მონაცემთა ცენტრის შექმნა
3. ახალი კლასტერის შექმნა
4. დამატებითი ჰოსტების დაყენება Self-Hosted გარემოში
5. შენახვის ადგილის ან შენახვის დომენების შექმნა
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 მეშვეობით მიგრაციისას ვირშ მიგრაცია, ეს VM არ იქნება ხელმისაწვდომი მართვისთვის oVirt კონსოლიდან.
• კლასტერ ჰოსტების ჩვენება შეუძლებელია მოვლის რეჟიმში (შენარჩუნების რეჟიმი), თუ ამ VM-ს გადაიტანთ ჰოსტიდან ჰოსტზე გამოყენებით ვირშ მიგრაცია.

ასე რომ, ყველაფერი გააკეთე წესების მიხედვით - გამოიყენეთ ან ცალკე ჰოსტი oVirt მენეჯმენტის სერვერისთვის, ან მასზე გაშვებული დამოუკიდებელი VM, ან კიდევ უკეთესი, გააკეთეთ ისე, როგორც დაწერილია მეორე ვარიანტში.

ვარიანტი 2
oVirt Engine Appliance-ის დაყენება მის მიერ მართულ კლასტერ ჰოსტზე.

ეს არის ის ვარიანტი, რომელიც შემდგომში განიხილება, როგორც უფრო სწორი და შესაფერისი ჩვენს შემთხვევაში.
ასეთი VM-ის მოთხოვნები აღწერილია ქვემოთ; მე მხოლოდ დავამატებ, რომ რეკომენდირებულია იყოს მინიმუმ ორი ჰოსტი ინფრასტრუქტურაში, რომელზედაც შესაძლებელია საკონტროლო VM-ის გაშვება, რათა ის გაუმართავი იყოს. აქვე მინდა დავამატო, რომ, როგორც უკვე დავწერე წინა სტატიის კომენტარებში, ვერასოდეს მივიღე გაყოფილი ტვინი oVirt ორი ჰოსტის კლასტერზე, მათზე ჰოსტინგის ძრავის VM-ების გაშვების შესაძლებლობით.

oVirt Engine Appliance-ის დაყენება კლასტერის პირველ ჰოსტზე

ოფიციალური დოკუმენტაციის ბმული - oVirt Self-Hosted Engine Guide, თავი "თვითმმართველობის ჰოსტირებული ძრავის დაყენება ბრძანების ხაზის გამოყენებით»

დოკუმენტში მითითებულია წინაპირობები, რომლებიც უნდა აკმაყოფილებდეს მასპინძელი ძრავის 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. დაამატეთ შენახვის ადგილები ან შენახვის დომენები ვირტუალური მანქანების დისკებისთვის
5. ქსელების დამატება და კონფიგურაცია ვირტუალური მანქანებისთვის
6. დაამატეთ და მართეთ ვირტუალური მანქანები, ინსტალაციის სურათები, VM შაბლონები

ყველა ეს მოქმედება შემდგომში იქნება განხილული, ზოგი დიდ უჯრედებში, ზოგი უფრო დეტალურად და ნიუანსებით.
მაგრამ პირველ რიგში ამ დანამატის წაკითხვას გირჩევთ, რომელიც ალბათ ბევრს გამოადგება.

გარდა ამისა

1) პრინციპში, თუ არსებობს ასეთი საჭიროება, მაშინ არაფერი გიშლით ხელს, რომ წინასწარ დააინსტალიროთ KVM ჰიპერვიზორი კლასტერულ კვანძებზე პაკეტების გამოყენებით. ლიბვირტი и ქემუ-კვმ (ან ქემუ-კვმ-ევ) სასურველი ვერსიის, თუმცა oVirt კლასტერული კვანძის განლაგებისას, მას შეუძლია ამის გაკეთება თავად.

მაგრამ თუ ლიბვირტი и ქემუ-კვმ თუ არ გაქვთ დაინსტალირებული უახლესი ვერსია, შეიძლება მიიღოთ შემდეგი შეცდომა ჰოსტინგის ძრავის დაყენებისას:

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'/>

ამის შემდეგ, შეგიძლიათ გააგრძელოთ ჰოსტინგის ძრავის დაყენება.

2) oVirt 4.3-ში, firewall-ის არსებობა და გამოყენება ცეცხლოვანი სამყარო სავალდებულო მოთხოვნაა.

თუ მასპინძელი ძრავისთვის 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

შემდეგ თქვენ უნდა გამორთოთ სხვა firewall (თუ ის გამოიყენება) და დააინსტალიროთ და გაუშვათ ცეცხლოვანი სამყარო:

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

მოგვიანებით, ოვირტი აგენტის დაინსტალირებისას კლასტერის ახალ ჰოსტზე, ის დააკონფიგურირებს საჭირო პორტებს ცეცხლოვანი სამყარო ავტომატურად.

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-ის მოვლის რეჟიმიდან ამოღების პროცედურა:

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და შემდეგ, საჭიროების შემთხვევაში, შეგიძლიათ შეცვალოთ მისი შენახვის ტიპი სხვაზე.

მონაცემთა ცენტრის შექმნა მარტივი ამოცანაა, ყოველგვარი სახიფათო ნიუანსების გარეშე და მასთან დაკავშირებული ყველა დამატებითი მოქმედება აღწერილია დოკუმენტაციაში. ერთადერთი, რასაც აღვნიშნავ, არის ის, რომ ცალკეული ჰოსტები, რომლებსაც აქვთ მხოლოდ ადგილობრივი საცავი (დისკი) VM-ებისთვის, ვერ შეძლებენ მონაცემთა ცენტრში შეღწევას Storage Type - Shared (მათი იქ ვერ დაემატება), და მათთვის თქვენ უნდა შექმნათ ცალკე მონაცემთა ცენტრი - ე.ი. ლოკალური მეხსიერების მქონე თითოეულ ინდივიდუალურ ჰოსტს სჭირდება საკუთარი ცალკე მონაცემთა ცენტრი.

ახალი კლასტერის შექმნა

დოკუმენტაციის ბმული - oVirt ადმინისტრაციის სახელმძღვანელო. თავი 5: კლასტერები

ზედმეტი დეტალების გარეშე, მტევანი – ეს არის ჰოსტების ლოგიკური დაჯგუფება, რომლებსაც აქვთ საერთო საცავი (საზოგადოებრივი დისკების სახით შენახვის სისტემაზე, როგორც ჩვენს შემთხვევაში). ასევე სასურველია, რომ კლასტერში ჰოსტები იყოს იდენტური ტექნიკით და ჰქონდეს იგივე ტიპის პროცესორი (Intel ან AMD). რა თქმა უნდა, უმჯობესია, რომ კლასტერში სერვერები სრულიად იდენტური იყოს.

კლასტერი არის მონაცემთა ცენტრის ნაწილი (სპეციფიკური ტიპის შენახვის - ლოკალური ან გაიზიარა), და ყველა ჰოსტი უნდა მიეკუთვნებოდეს რაიმე სახის კლასტერს, იმისდა მიხედვით, აქვთ თუ არა მათ საერთო მეხსიერება.

ჰოსტზე ძრავით ვირტუალური მანქანის დაყენებისას, ნაგულისხმევად იქმნება მონაცემთა ცენტრი - მონაცემთა ცენტრი 1კლასტერთან ერთად - კასეტური 1და მომავალში შეგიძლიათ დააკონფიგურიროთ მისი პარამეტრები, ჩართოთ დამატებითი პარამეტრები, დაამატოთ მასში ჰოსტები და ა.შ.

ჩვეულებისამებრ, კლასტერის ყველა პარამეტრის შესახებ დეტალებისთვის, მიზანშეწონილია მიმართოთ ოფიციალურ დოკუმენტაციას. კლასტერის დაყენების ზოგიერთი მახასიათებლიდან მხოლოდ დავამატებ, რომ მისი შექმნისას საკმარისია მხოლოდ ძირითადი პარამეტრების კონფიგურაცია ჩანართზე ზოგადი.

მე აღვნიშნავ ყველაზე მნიშვნელოვან პარამეტრებს:

• პროცესორის ტიპი — შეირჩევა იმის მიხედვით, თუ რომელი პროცესორებია დაინსტალირებული კლასტერ ჰოსტებზე, რომელი მწარმოებლისგან არიან ისინი და რომელი პროცესორია ჰოსტებზე ყველაზე ძველი, ასე რომ, აქედან გამომდინარე, გამოყენებული იქნება კლასტერში არსებული ყველა პროცესორის ინსტრუქცია.
• გადართვის ტიპი – ჩვენს კლასტერში ჩვენ ვიყენებთ მხოლოდ Linux bridge-ს, ამიტომ ვირჩევთ მას.
• Firewall-ის ტიპი – აქ ყველაფერი გასაგებია, ეს არის firewalld, რომელიც უნდა იყოს ჩართული და კონფიგურირებული ჰოსტებზე.

სკრინშოტი კასეტური პარამეტრებით

დამატებითი ჰოსტების დაყენება Self-Hosted გარემოში

ლინკები დოკუმენტაციისთვის.

დამატებითი ჰოსტები Self-Hosted გარემოსთვის ემატება ისევე, როგორც ჩვეულებრივი ჰოსტი, მასპინძელი ძრავით VM-ის განლაგების დამატებითი ნაბიჯით - აირჩიეთ მასპინძელი ძრავის განლაგების მოქმედება >> განათავსეთ. ვინაიდან დამატებით ჰოსტს ასევე უნდა წარუდგინოს LUN VM-ისთვის ჰოსტინგის ძრავით, ეს ნიშნავს, რომ ეს ჰოსტი, საჭიროების შემთხვევაში, შეიძლება გამოყენებულ იქნას VM-ის მასპინძლობისთვის მასზე განთავსებული ძრავით.
შეცდომის ტოლერანტობის მიზნით, რეკომენდებულია მინიმუმ ორი ჰოსტი, რომლებზეც შეიძლება განთავსდეს მასპინძელი ძრავის 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

დააინსტალირეთ საჭირო საცავი და მასპინძელი ძრავის ინსტალერი:

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 ვირტუალიზაცია 4.3 –> ტექნიკური მითითება -> თავი 4. ენერგიის მენეჯმენტი
• oVirt ადმინისტრაციის სახელმძღვანელო -> თავი 7: მასპინძლები

მიუხედავად იმისა, რომ შეიძლება ჩანდეს, რომ თქვენ დაასრულეთ ჰოსტის დამატება და კონფიგურაცია, ეს მთლად ასე არ არის.
მასპინძლების ნორმალური მუშაობისთვის და რომელიმე მათგანის წარუმატებლობის იდენტიფიცირებისთვის/მოგვარებისთვის საჭიროა ენერგიის მენეჯმენტის/ღობეების პარამეტრები.

ფარიკაობა, ან ფარიკაობა, არის კლასტერიდან გაუმართავი ან წარუმატებელი ჰოსტის დროებით გამორიცხვის პროცესი, რომლის დროსაც ან მასზე არსებული oVirt სერვისები ან თავად ჰოსტი განახლდება.

ელექტროენერგიის მენეჯმენტის / ფარიკაობის განსაზღვრებისა და პარამეტრების შესახებ ყველა დეტალი მოცემულია, როგორც ყოველთვის, დოკუმენტაციაში; მე მხოლოდ მაგალითს მივცემ, თუ როგორ უნდა დააკონფიგურიროთ ეს მნიშვნელოვანი პარამეტრი, როგორც გამოიყენება Dell R640 სერვერებზე iDRAC 9-ით.

1. გადადით ადმინისტრაციულ პორტალზე, დააწკაპუნეთ გამოთვლაც >> მასპინძლობს აირჩიეთ მასპინძელი.
2. ჩვენ დააჭირეთ რედაქტირება.
3. დააწკაპუნეთ ჩანართზე ენერგიის მართვა.
4. მონიშნეთ ყუთი ვარიანტის გვერდით ჩართეთ ენერგიის მართვა.
5. მონიშნეთ ყუთი ვარიანტის გვერდით Kdump ინტეგრაციარათა თავიდან აიცილოს მასპინძელი ფარიკაობის რეჟიმში გადასვლას ბირთვის ავარიული ნაგავსაყრელის ჩაწერისას.

შენიშვნა.

Kdump ინტეგრაციის ჩართვის შემდეგ უკვე გაშვებულ ჰოსტზე, ის ხელახლა უნდა დააინსტალიროთ oVirt ადმინისტრაციის სახელმძღვანელოში მოცემული პროცედურის მიხედვით -> თავი 7: მასპინძლები -> ჰოსტების ხელახლა ინსტალაცია.

1. სურვილისამებრ, შეგიძლიათ შეამოწმოთ ყუთი ენერგიის მართვის პოლიტიკის კონტროლის გამორთვა, თუ არ გვინდა, რომ მასპინძელი ენერგიის მენეჯმენტი კონტროლდებოდეს კლასტერის დაგეგმვის პოლიტიკით.
2. დააჭირეთ ღილაკს (+) ენერგიის მართვის ახალი მოწყობილობის დასამატებლად გაიხსნება აგენტის თვისებების რედაქტირების ფანჯარა.
   iDRAC9-ისთვის შეავსეთ ველები:
   • მისამართი - iDRAC9 მისამართი
   • Მომხმარებლის სახელი პაროლი – შესვლა და პაროლი iDRAC9-ში შესასვლელად, შესაბამისად
   • ტიპი -drac5
   • mark უსაფრთხო
   • დაამატეთ შემდეგი პარამეტრები: cmd_prompt=>,login_timeout=30

სკრინშოტი „ენერგიის მენეჯმენტის“ პარამეტრებით ჰოსტის თვისებებში

შენახვის ადგილის ან შენახვის დომენების შექმნა

დოკუმენტაციის ბმული - oVirt ადმინისტრაციის სახელმძღვანელო, თავი 8: შენახვა.

შენახვის დომენი, ან შენახვის ზონა, არის ცენტრალიზებული ადგილი ვირტუალური მანქანების დისკების, ინსტალაციის სურათების, შაბლონების და სნეპშოტების შესანახად.

შენახვის ზონები შეიძლება დაუკავშირდეს მონაცემთა ცენტრს სხვადასხვა პროტოკოლების, კლასტერებისა და ქსელის ფაილური სისტემების გამოყენებით.

oVirt-ს აქვს სამი ტიპის შენახვის ადგილი:

• მონაცემთა დომენი – ვირტუალურ მანქანებთან დაკავშირებული ყველა მონაცემის შესანახად (დისკები, შაბლონები). მონაცემთა დომენის გაზიარება შეუძლებელია სხვადასხვა მონაცემთა ცენტრს შორის.
• ISO დომენი (მოძველებული ტიპის შენახვის ადგილი) – OS-ის ინსტალაციის სურათების შესანახად. ISO დომენის გაზიარება შესაძლებელია სხვადასხვა მონაცემთა ცენტრს შორის.
• დომენის ექსპორტი (საცავის მოძველებული ტიპი) – მონაცემთა ცენტრებს შორის გადაადგილებული სურათების დროებით შესანახად.

ჩვენს კონკრეტულ შემთხვევაში, მონაცემთა დომენის ტიპის შენახვის ზონა იყენებს ბოჭკოვანი არხის პროტოკოლს (FCP) საცავის სისტემის LUN-ებთან დასაკავშირებლად.

oVirt-ის თვალსაზრისით, შენახვის სისტემების გამოყენებისას (FC ან iSCSI), თითოეული ვირტუალური დისკი, სნეპშოტი ან შაბლონი არის ლოგიკური დისკი.
ბლოკის მოწყობილობები იკრიბება ერთ ერთეულში (კლასტერ ჰოსტებზე) Volume Group-ის გამოყენებით და შემდეგ იყოფა LVM-ის გამოყენებით ლოგიკურ ტომებად, რომლებიც გამოიყენება ვირტუალურ დისკებად VM-ებისთვის.

ყველა ეს ჯგუფი და მრავალი LVM ტომი შეიძლება ნახოთ კლასტერ ჰოსტზე ბრძანებების გამოყენებით და ა.შ и ლვ. ბუნებრივია, ასეთ დისკებთან ყველა მოქმედება უნდა განხორციელდეს მხოლოდ oVirt კონსოლიდან, გარდა განსაკუთრებული შემთხვევებისა.

ვირტუალური დისკები VM-ებისთვის შეიძლება იყოს ორი ტიპის - QCOW2 ან RAW. დისკები შეიძლება იყოს "გამხდარი"ან"სქელი". Snapshots ყოველთვის იქმნება როგორც"тонкие".

Storage დომენების, ან FC-ის საშუალებით წვდომის შენახვის ზონების მართვის გზა საკმაოდ ლოგიკურია - თითოეული VM ვირტუალური დისკისთვის არის ცალკე ლოგიკური ტომი, რომელიც მხოლოდ ერთი ჰოსტის მიერ არის დაწერილი. FC კავშირებისთვის, oVirt იყენებს რაღაც კლასტერულ LVM-ს.

ერთსა და იმავე საცავზე მდებარე ვირტუალური მანქანების მიგრაცია შესაძლებელია ჰოსტებს შორის, რომლებიც მიეკუთვნებიან იმავე კლასტერს.

როგორც აღწერიდან ვხედავთ, კლასტერი oVirt-ში, ისევე როგორც კლასტერი VMware vSphere-ში ან Hyper-V-ში, არსებითად ნიშნავს იგივეს - ეს არის ჰოსტების ლოგიკური დაჯგუფება, სასურველია იდენტური ტექნიკის შემადგენლობით და აქვს საერთო მეხსიერება ვირტუალურისთვის. მანქანის დისკები.

მოდით პირდაპირ გავაგრძელოთ მონაცემთა შენახვის არეალის შექმნა (VM დისკები), რადგან ამის გარეშე მონაცემთა ცენტრის ინიციალიზაცია არ მოხდება.
შეგახსენებთ, რომ ყველა LUN, რომელიც წარმოდგენილია კასეტური ჰოსტებისთვის შენახვის სისტემაზე, უნდა იყოს ხილული მათზე ბრძანების გამოყენებით.მრავალმხრივი -ll".

მიხედვით დოკუმენტაცია, გადადით პორტალზე გადასვლა შენახვის სივრცე >> დომენები -> ახალი დომენი და მიჰყევით ინსტრუქციას "FCP Storage-ის დამატება" განყოფილებიდან.

ოსტატის გაშვების შემდეგ შეავსეთ საჭირო ველები:

• სახელი - დააყენეთ კლასტერის სახელი
• დომენის ფუნქცია - მონაცემები
• შენახვის ტიპი - ბოჭკოვანი არხი
• მასპინძელი გამოსაყენებლად — აირჩიეთ ჰოსტი, რომელზეც ხელმისაწვდომია ჩვენთვის საჭირო LUN

LUN-ების სიაში მონიშნეთ ის, რაც გვჭირდება, დააწკაპუნეთ დამატება და შემდეგ OK. საჭიროების შემთხვევაში, შეგიძლიათ დაარეგულიროთ შენახვის ადგილის დამატებითი პარამეტრები დაწკაპუნებით მოწინავე პარამეტრები.

ოსტატის სკრინშოტი „საცავის დომენის“ დასამატებლად

ოსტატის შედეგებიდან გამომდინარე, ჩვენ უნდა მივიღოთ ახალი საცავი და ჩვენი მონაცემთა ცენტრი უნდა გადავიდეს სტატუსზე UP, ან ინიციალიზებული:

მონაცემთა ცენტრისა და მასში შენახვის ადგილების ეკრანის ანაბეჭდები:

ვირტუალური მანქანებისთვის ქსელების შექმნა და კონფიგურაცია

დოკუმენტაციის ბმული - oVirt ადმინისტრაციის სახელმძღვანელო, თავი 6: ლოგიკური ქსელები

ქსელები ან ქსელები ემსახურება oVirt ვირტუალურ ინფრასტრუქტურაში გამოყენებული ლოგიკური ქსელების დაჯგუფებას.

ვირტუალურ მანქანაზე ქსელურ ადაპტერსა და ჰოსტის ფიზიკურ ადაპტერს შორის ურთიერთქმედებისთვის გამოიყენება ლოგიკური ინტერფეისები, როგორიცაა Linux bridge.

ქსელებს შორის ტრაფიკის დასაჯგუფებლად და გასაყოფად, VLAN-ები კონფიგურებულია გადამრთველებზე.

oVirt-ში ვირტუალური მანქანებისთვის ლოგიკური ქსელის შექმნისას მას უნდა მიენიჭოს გადამრთველზე VLAN ნომრის შესაბამისი იდენტიფიკატორი, რათა VM-ებმა შეძლონ ერთმანეთთან კომუნიკაცია, მაშინაც კი, თუ ისინი მუშაობენ კლასტერის სხვადასხვა კვანძზე.

ქსელის ადაპტერების წინასწარი პარამეტრები ჰოსტებზე ვირტუალური მანქანების დასაკავშირებლად უნდა გაკეთდეს წინა სტატია - კონფიგურირებულია ლოგიკური ინტერფეისი ბმული 1, მაშინ ქსელის ყველა პარამეტრი უნდა განხორციელდეს მხოლოდ oVirt ადმინისტრაციული პორტალის მეშვეობით.

VM-ის შექმნის შემდეგ ჰოსტ-ძრავით, გარდა მონაცემთა ცენტრისა და კლასტერის ავტომატური შექმნისა, ასევე ავტომატურად შეიქმნა ლოგიკური ქსელი ჩვენი კლასტერის სამართავად - ოვრიტმგმტ, რომელსაც ეს VM იყო დაკავშირებული.

საჭიროების შემთხვევაში, შეგიძლიათ ნახოთ ლოგიკური ქსელის პარამეტრები ოვრიტმგმტ და დაარეგულირეთ ისინი, მაგრამ ფრთხილად უნდა იყოთ, რომ არ დაკარგოთ კონტროლი oVirt ინფრასტრუქტურაზე.

ლოგიკური ქსელის პარამეტრები ovritmgmt

ჩვეულებრივი VM-ებისთვის ახალი ლოგიკური ქსელის შესაქმნელად გადადით ადმინისტრაციულ პორტალზე ქსელი >> ქსელები >> ახალიდა ჩანართზე ზოგადი დაამატეთ ქსელი სასურველი VLAN ID-ით და ასევე მონიშნეთ ველი „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: შენახვა, განყოფილება სურათების ატვირთვა მონაცემთა შენახვის დომენზე.

OS-ის ინსტალაციის სურათის გარეშე, ვირტუალური აპარატის დაყენება შეუძლებელი იქნება, თუმცა ეს, რა თქმა უნდა, არ არის პრობლემა, თუ, მაგალითად, დაინსტალირებულია ქსელში. კობლლერი წინასწარ შექმნილი სურათებით.

ჩვენს შემთხვევაში, ეს შეუძლებელია, ამიტომ თქვენ თავად მოგიწევთ ამ სურათის იმპორტი oVirt-ში. ადრე ეს მოითხოვდა ISO დომენის შექმნას, მაგრამ oVirt-ის ახალ ვერსიაში ის მოძველებულია და, შესაბამისად, ახლა შეგიძლიათ ატვირთოთ სურათები პირდაპირ Storage დომენში ადმინისტრაციული პორტალიდან.

ადმინისტრაციულ პორტალში გადადით შენახვის სივრცე >> დისკები >> ატვირთვა >> დასაწყისი
ჩვენ ვამატებთ ჩვენს OS სურათს 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 სერთიფიკატი "სანდო Root CA-ები"(Trusted Root CA) ადმინისტრატორის საკონტროლო სადგურზე, საიდანაც ჩვენ ვცდილობთ ჩამოტვირთოთ სურათი.

სერთიფიკატის დამატების შემდეგ Trusted Root CA, დააწკაპუნეთ ხელახლა "ტესტი კავშირი", უნდა მიიღოს:

Connection to ovirt-imageio-proxy was successful.

სერტიფიკატის დამატების მოქმედების დასრულების შემდეგ, შეგიძლიათ სცადოთ ISO სურათის ატვირთვა Storage Domain-ში.

პრინციპში, თქვენ შეგიძლიათ შექმნათ ცალკე Storage Domain მონაცემთა ტიპით, რათა შეინახოთ სურათები და შაბლონები VM დისკებისგან განცალკევებით, ან თუნდაც შეინახოთ ისინი Storage Domain-ში მასპინძელი ძრავისთვის, მაგრამ ეს არის ადმინისტრატორის შეხედულებისამებრ.

სკრინშოტი ISO გამოსახულებით Storage Domain-ში მასპინძელი ძრავისთვის

შექმენით ვირტუალური მანქანა

დოკუმენტაციის ბმული:
oVirt ვირტუალური მანქანების მართვის სახელმძღვანელო –> თავი 2: Linux-ის ვირტუალური მანქანების ინსტალაცია
კონსოლის კლიენტების რესურსები

ინსტალაციის სურათის OS-ით oVirt-ში ჩატვირთვის შემდეგ, შეგიძლიათ პირდაპირ გააგრძელოთ ვირტუალური მანქანის შექმნა. ბევრი სამუშაო გაკეთდა, მაგრამ ჩვენ უკვე ფინალურ ეტაპზე ვართ, რისთვისაც ეს ყველაფერი დაიწყო - შეცდომის ტოლერანტული ინფრასტრუქტურის მოპოვება მაღალ ხელმისაწვდომი ვირტუალური მანქანების ჰოსტინგისთვის. და ეს ყველაფერი აბსოლუტურად უფასოა - არც ერთი პენი არ დაიხარჯა რაიმე პროგრამული ლიცენზიის შესაძენად.

CentOS 7-ით ვირტუალური მანქანის შესაქმნელად, ოპერაციული სისტემის ინსტალაციის სურათი უნდა იყოს გადმოწერილი.

ჩვენ მივდივართ ადმინისტრაციულ პორტალზე, გადადით გამოთვლაც >> ვირტუალური მანქანებიდა გაუშვით VM შექმნის ოსტატი. შეავსეთ ყველა პარამეტრი და ველი და დააწკაპუნეთ OK. ყველაფერი ძალიან მარტივია, თუ დაიცავთ დოკუმენტაციას.

მაგალითად, მე მივცემ უაღრესად ხელმისაწვდომი VM-ის ძირითად და დამატებით პარამეტრებს, შექმნილი დისკით, დაკავშირებულია ქსელთან და ჩაიტვირთება ინსტალაციის სურათიდან:

სკრინშოტები მაღალ ხელმისაწვდომი VM პარამეტრებით

ოსტატთან მუშაობის დასრულების შემდეგ, დახურეთ იგი, გაუშვით ახალი VM და დააინსტალირეთ მასზე OS.
ამისათვის გადადით ამ VM-ის კონსოლზე ადმინისტრაციული პორტალის მეშვეობით:

ადმინისტრაციული პორტალის პარამეტრების ეკრანის სურათი VM კონსოლთან დასაკავშირებლად

VM კონსოლთან დასაკავშირებლად, ჯერ უნდა დააკონფიგურიროთ კონსოლი ვირტუალური მანქანის თვისებებში.

VM პარამეტრების სკრინშოტი, ჩანართი „კონსოლი“.

VM კონსოლთან დასაკავშირებლად შეგიძლიათ გამოიყენოთ, მაგალითად, ვირტუალური მანქანების მაყურებელი.

VM კონსოლთან პირდაპირ ბრაუზერის ფანჯარაში დასაკავშირებლად, კონსოლის მეშვეობით კავშირის პარამეტრები უნდა იყოს შემდეგი:

VM-ზე OS-ის დაყენების შემდეგ, სასურველია დააინსტალიროთ 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