ოპენნებულა. მოკლე შენიშვნები

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

ასე რომ, როგორც ვხედავთ, ბევრი ღრუბლოვანი პროვაიდერი მუშაობს kvm-ზე და ამყარებს გარე კავშირებს მანქანებთან სამართავად. ნათელია, რომ დიდი ჰოსტერები წერენ საკუთარ ჩარჩოებს ღრუბლოვანი ინფრასტრუქტურისთვის, მაგალითად, იგივე YANDEX. ვიღაც იყენებს openstack-ს და აკავშირებს ამის საფუძველზე - SELECTEL, MAIL.RU. მაგრამ თუ თქვენ გაქვთ საკუთარი აპარატურა და სპეციალისტების მცირე პერსონალი, მაშინ ჩვეულებრივ ირჩევთ რაღაც მზას - VMWARE, HYPER-V, არის უფასო და ფასიანი ლიცენზიები, მაგრამ ეს არ არის ის, რაზეც ახლა ვსაუბრობთ. მოდით ვისაუბროთ ენთუზიასტებზე - ესენი არიან მათ, ვისაც არ ეშინია რაიმე ახლის შეთავაზება და მოსინჯვა, მიუხედავად იმისა, რომ კომპანიამ ნათლად აჩვენა, "ვინ მოგემსახურება ამას თქვენს შემდეგ", "ვაპირებთ თუ არა ამის მოგვიანებით წარმოებას. ? საშინელი." მაგრამ თქვენ შეგიძლიათ ჯერ გამოიყენოთ ეს გადაწყვეტილებები სატესტო სკამზე და თუ ეს ყველას მოეწონება, მაშინ შეგიძლიათ დააყენოთ საკითხი შემდგომი განვითარებისა და გამოყენების შესახებ უფრო სერიოზულ გარემოში.

ასევე აქ არის ანგარიშის ბმული www.youtube.com/watch?v=47Mht_uoX3A ამ პლატფორმის შემუშავების აქტიური მონაწილისგან.

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

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

1. ინსტალაციის განმეორებადობა

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

2. Მონიტორინგი

ჩვენ დავაკვირდებით თავად კვანძს, kvm-ს და opennebula-ს. საბედნიეროდ, ის უკვე მზად არის. არსებობს უამრავი ვარიანტი Linux ჰოსტების მონიტორინგის შესახებ, იგივე Zabbix ან კვანძის ექსპორტიორი - ვისაც რა მოსწონს უკეთესი - ამ მომენტში მე განვსაზღვრავ მას, როგორც მონიტორინგის სისტემის მეტრიკას (ტემპერატურა, სადაც მისი გაზომვა შესაძლებელია, დისკის მასივის თანმიმდევრულობა), zabbix-ის მეშვეობით და რაც შეეხება განაცხადებს პრომეთეს ექსპორტიორის მეშვეობით. მაგალითად, kvm მონიტორინგისთვის, შეგიძლიათ აიღოთ პროექტი github.com/zhangjianweibj/prometheus-libvirt-exporter.git და დააყენე systemd-ით გაშვებაზე, საკმაოდ კარგად მუშაობს და აჩვენებს kvm მეტრიკას, არის ასევე მზა დაფა grafana.com/grafana/dashboards/12538.

მაგალითად, აქ არის ჩემი ფაილი:

/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter

[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"

[Install]
WantedBy=multi-user.target

ასე რომ, ჩვენ გვყავს 1 ექსპორტიორი, გვჭირდება მეორე, რომ დავაკვირდეთ თავად opennebula-ს, მე ეს გამოვიყენე github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

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

node_exporter ფაილში ჩვენ ვცვლით დაწყებას ასე:

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

შექმენით დირექტორია mkdir -p /var/lib/opennebula_exporter

ზემოთ წარმოდგენილი bash სკრიპტი, ჯერ ვამოწმებთ სამუშაოს კონსოლის საშუალებით, თუ გვიჩვენებს რა გვჭირდება (თუ შეცდომას იძლევა, შემდეგ დააინსტალირეთ xmlstarlet), დააკოპირეთ /usr/local/bin/opennebula_exporter.sh.

დაამატეთ cron ამოცანა ყოველ წუთს:

*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)

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

(გასაგებია, რომ აქ მე გადავიტან CPU, ram)

მათთვის, ვისაც უყვარს და იყენებს Zabbix, არსებობს github.com/OpenNebula/addon-zabbix

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

ჯერ ნამდვილად არ დამიწყია შესვლა. უმარტივესი ვარიანტია td-agent-ის დამატება /var/lib/one დირექტორია რეგულარული გამონათქვამებით გასაანალიზებლად. მაგალითად, sunstone.log ფაილი ემთხვევა nginx regexp-ს და სხვა ფაილებს, რომლებიც აჩვენებენ პლატფორმაზე წვდომის ისტორიას - რა არის ამის უპირატესობა? მაგალითად, ჩვენ შეგვიძლია მკაფიოდ თვალყური ადევნოთ "შეცდომა, შეცდომა"-ს რაოდენობას და სწრაფად მივადევნოთ თვალი სად და რა დონეზე არის გაუმართაობა.

3. სარეზერვო ასლები

ასევე არის ფასიანი დასრულებული პროექტები - მაგალითად სექ wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. აქ ჩვენ უნდა გვესმოდეს, რომ მანქანის სურათის უბრალოდ სარეზერვო ასლის შექმნა ამ შემთხვევაში სულაც არ არის იგივე, რადგან ჩვენმა ვირტუალურმა მანქანებმა უნდა იმუშაონ სრული ინტეგრაციით (იგივე კონტექსტური ფაილი, რომელიც აღწერს ქსელის პარამეტრებს, vm სახელს და თქვენი აპლიკაციების მორგებულ პარამეტრებს) . აქედან გამომდინარე, აქ ჩვენ ვწყვეტთ რა და როგორ გავაკეთოთ სარეზერვო ასლი. ზოგიერთ შემთხვევაში სჯობს თავად vm-ში არსებულის ასლების გაკეთება. და შესაძლოა დაგჭირდეთ მხოლოდ ერთი დისკის სარეზერვო ასლი მოცემული აპარატიდან.

მაგალითად, ჩვენ დავადგინეთ, რომ ყველა მანქანა იწყება მუდმივი სურათებით, შესაბამისად, წაკითხვის შემდეგ docs.opennebula.io/5.12/operation/vm_management/img_guide.html

ეს ნიშნავს, რომ ჯერ ჩვენ შეგვიძლია ავტვირთოთ სურათი ჩვენი vm-დან:

onevm disk-saveas 74 3 prom.qcow2
Image ID: 77

Смотрим, под каким именем он сохранился

oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
   
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.

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

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

4. გამოყენების სიმარტივე

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

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

და შემდეგ მიდგება იმის გაგება, თუ რატომ ათვლის opennebula ყოველ ახალ ინსტანციას ახალი id-ით, მაგალითად, იმავე proxmox-ში შექმნა vm id 101-ით, წაშალა, შემდეგ ისევ შექმნი და id 101. opennebula-ში ეს არ მოხდება. ყოველი ახალი ინსტანცია შეიქმნება ახალი ID-ით და ამას თავისი ლოგიკა აქვს - მაგალითად, ძველი მონაცემების გასუფთავება ან წარუმატებელი ინსტალაციები.

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

5. მაქსიმალური სიმარტივე

რა თქმა უნდა, რაც უფრო წინ წახვალ, მით უფრო ნაკლები ხდებიან ისინი, ვინც გაგიგებენ.

ჩემი სტენდის პირობებში - 3 კვანძი nfs საცავებით - ყველაფერი კარგად მუშაობს. მაგრამ თუ ჩვენ ვატარებთ ექსპერიმენტებს ელექტროენერგიის გათიშვასთან დაკავშირებით, მაგალითად, სნეპშოტის გაშვებისას და კვანძის კვების გამორთვისას, ჩვენ ვინახავთ პარამეტრებს მონაცემთა ბაზაში, რომ არის სნეპშოტი, მაგრამ სინამდვილეში არ არსებობს (კარგად, ჩვენ ყველას გვესმის, რომ ჩვენ თავდაპირველად დაწერა მონაცემთა ბაზა ამ მოქმედების შესახებ sql-ში, მაგრამ თავად ოპერაცია არ იყო წარმატებული). უპირატესობა ის არის, რომ სნეპშოტის შექმნისას იქმნება ცალკე ფაილი და არის „მშობელი“, ამიტომ პრობლემების შემთხვევაში და თუნდაც gui-ს საშუალებით არ მუშაობს, შეგვიძლია ავიღოთ qcow2 ფაილი და ცალკე აღვადგინოთ. docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

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

თუ მაინც გსურთ მისი შედარება openstack-თან, მაშინ შეგიძლიათ თქვათ ეს: opennebula-ში არ არსებობს მკაფიო განმარტება, თუ რომელი ტექნოლოგიები გამოიყენოს მონაცემთა შესანახად, ქსელის მართვისთვის, რესურსები - თითოეული ადმინისტრატორი თავად წყვეტს, რა არის მისთვის უფრო მოსახერხებელი.

6. დამატებითი დანამატები და ინსტალაციები

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

მითითებულია ღრუბლოვანი სხვა პროვაიდერების მხარდაჭერა docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Vmware Cloud-ის დაკავშირებაც ვცადე Selectel-იდან, მაგრამ არაფერი გამოვიდა - ზოგადად დაბლოკილია, რადგან ბევრი ფაქტორია და ჰოსტინგის პროვაიდერის ტექნიკურ მხარდაჭერაზე წერას აზრი არ აქვს.

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

7. გამოყენების დადებითი გამოცდილება და შეცდომების გამართვა

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

მაგალითად, მარტივი ოპერაცია დისკის სურათის კოპირების ერთი მონაცემთა საცავიდან მეორეში. ჩემს შემთხვევაში არის 2 კვანძი nfs-ით, სურათს ვაგზავნი - კოპირება ხდება frontend opennebula-ს მეშვეობით, თუმცა ყველა მიჩვეული ვართ, რომ მონაცემები პირდაპირ ჰოსტებს შორის უნდა იყოს კოპირებული - იგივე vmware, hyper-v ჩვენ ვართ. ამას მიჩვეული, მაგრამ აქ სხვას. არსებობს სხვა მიდგომა და განსხვავებული იდეოლოგია და 5.12 ვერსიაში მათ ამოიღეს ღილაკი "მიგრაცია მონაცემთა მაღაზიაში" - მხოლოდ თავად მანქანა გადადის, მაგრამ არა საცავი, რადგან ნიშნავს ცენტრალიზებულ შენახვას.

შემდეგი არის პოპულარული შეცდომა სხვადასხვა მიზეზით: „ვირტუალური მანქანის განლაგების შეცდომა: ვერ შევქმენი დომენი /var/lib/one//datastores/103/10/deployment.5“.

• სურათის უფლებები oneadmin მომხმარებლისთვის;
• ნებართვები oneadmin მომხმარებლისთვის, რომ გაუშვას libvirtd;
• მონაცემთა მაღაზია სწორად არის დამონტაჟებული? მიდი და შეამოწმე გზა თავად კვანძზე, იქნებ რამე ჩამოვარდა;
• არასწორად კონფიგურირებული ქსელი, უფრო სწორად, წინა მხარეს, ქსელის პარამეტრებში არის vlan-ის მთავარი ინტერფეისი br0, მაგრამ კვანძზე წერია როგორც bridge0 - იგივე უნდა იყოს.

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

8. დოკუმენტაცია, თემი. Შემდგომი განვითარება

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

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

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

ამ დროისთვის, კომპანიაში გარკვეული პოლიტიკა შეიცვალა 5.12 forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 საინტერესო იქნება, თუ როგორ განვითარდება პროექტი. დასაწყისში, მე კონკრეტულად აღვნიშნე ზოგიერთი გამყიდველი, რომელიც იყენებს მათ გადაწყვეტილებებს და რას გვთავაზობს ინდუსტრია. რა თქმა უნდა, არ არსებობს მკაფიო პასუხი იმაზე, თუ რა უნდა გამოვიყენოთ. მაგრამ პატარა ორგანიზაციებისთვის, მათი მცირე კერძო ღრუბლის შენარჩუნება შეიძლება არც ისე ძვირი იყოს, როგორც ჩანს. მთავარია ზუსტად იცოდე რა გჭირდება.

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

კარგი ჩატია t.me/opennebula ისინი აქტიურად გეხმარებიან და არ გიგზავნიან Google-ში პრობლემის გადაჭრის მოსაძებნად. Შემოგვიერთდი.

წყარო: www.habr.com