Hamıya salam. Bu məqalə hələ də virtualizasiya platformalarının seçimi arasında qalan və "Proxmox quraşdırdıq və hər şey qaydasındadır, 6 illik iş vaxtı bir boşluq deyil" seriyasından bir məqalə oxuduqdan sonra yazılmışdır. Ancaq bu və ya digər qutulu həlli quraşdırdıqdan sonra sual yaranır ki, onu burada necə düzəltmək olar ki, monitorinq daha başa düşüləndir və burada ehtiyat nüsxələrə nəzarət etmək .... Və sonra vaxt gəlir və başa düşürsən ki, daha funksional bir şey istəyirsən, ya da bu qara qutu deyil, sisteminizdə hər şeyin aydın olmasını istəyirsiniz və ya hipervizor və bir dəstə virtual maşından daha çox şey istifadə etmək istəyirsiniz. . Bu yazıda Opennebula platformasına əsaslanan bəzi düşüncələr və təcrübələr olacaq - ona görə seçdim. resurslara tələbkar deyil və arxitektura o qədər də mürəkkəb deyil.
Beləliklə, gördüyümüz kimi, bir çox bulud provayderi kvm üzərində işləyir və maşınları idarə etmək üçün xarici qoşqu hazırlayır. Aydındır ki, böyük hosterlər bulud infrastrukturu, məsələn, eyni YANDEX üçün öz bağlamalarını yazırlar. Kimsə openstack-dən istifadə edir və bu əsasda bağlama edir - SELECTEL, MAIL.RU. Ancaq öz avadanlıqlarınız və kiçik bir mütəxəssis heyətiniz varsa, onlar ümumiyyətlə hazır olanlardan bir şey seçirlər - VMWARE, HYPER-V, pulsuz və pullu lisenziyalar var, amma indi bu barədə deyil. Həvəskarlar haqqında danışaq – bunlar şirkətin “Sizdən sonra kim xidmət edəcək”, “Sonra onu satışa çıxaracağıqmı? Qorxulu." Ancaq bütün bunlardan sonra, siz əvvəlcə bu həlləri test skamyasında tətbiq edə bilərsiniz və hər kəs bunu bəyənirsə, o zaman daha ciddi mühitlərdə daha da inkişaf etdirmək və istifadə etmək məsələsini qaldıra bilərsiniz.
Həmçinin burada hesabata keçid var. bu platformanın inkişafında fəal iştirakçıdan.
Bəlkə də bu məqalədə bir şey artıq olacaq və təcrübəli mütəxəssis üçün artıq aydındır və bəzi hallarda hər şeyi təsvir etməyəcəyəm, çünki oxşar əmrlər və təsvirlər şəbəkədədir. Bu sadəcə mənim bu platforma ilə təcrübəmdir. Ümid edirəm ki, aktiv iştirakçılar nəyi daha yaxşı etmək olar və hansı səhvləri etdiyimi şərhlərdə əlavə edəcəklər. Bütün hərəkətlər müxtəlif xüsusiyyətlərə malik 3 fərdi kompüterdən ibarət ev stendində aparılıb. Ayrıca, bu proqramın necə işlədiyini və necə qurulacağını göstərməyə başlamadım. Xeyr, yalnız idarəetmə təcrübəsi və üzləşdiyi problemlər. Bəlkə kimsə seçimində faydalı olacaq.
Beləliklə, başlayaq. Bir sistem administratoru olaraq, aşağıdakı məqamlar mənim üçün vacibdir, onsuz bu həlli istifadə edə bilmərəm.
1. Quraşdırmanın təkrarlanması
Opennebula quraşdırmaq üçün çoxlu təlimatlar var, onunla heç bir problem yaşamamalısınız. Versiyadan versiyaya, versiyadan versiyaya keçərkən həmişə əldə edilə bilməyən yeni funksiyalar görünür.
2. Monitorinq
Düyün özünü, kvm və açıq nebulanı izləyəcəyik. Şükürlər olsun ki, artıq hazırdır. Linux hostlarının, eyni zabbix və ya node ixracatçısının monitorinqi ilə bağlı bir çox seçim var - kimin daha çox xoşuna gəlirsə - hazırda mən onu elə müəyyənləşdirirəm ki, sistem ölçülərini (ölçülə bilən temperatur, disk massivinin ardıcıllığı), zabbix vasitəsilə, lakin prometeydə ixracatçı vasitəsilə tətbiqlərə gəldikdə. Məsələn, kvm monitorinqi üçün bir layihə götürə bilərsiniz və işə salmağı systemd vasitəsilə qoyun, olduqca yaxşı işləyir və kvm ölçülərini göstərir, hazır tablosuna da malikdir .
Məsələn, mənim faylım budur:
/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.targetVə beləliklə, bizim 1 ixracatçımız var, opennebulanın özünü izləmək üçün ikinciyə ehtiyacımız var, mən bundan istifadə etdim
Adilərə əlavə edilə bilər sistemə aşağıdakı kimi nəzarət etmək.
node_exporter faylında başlanğıcı bu şəkildə dəyişdiririk:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectormkdir -p /var/lib/opennebula_exporter kataloqu yaradın
yuxarıda təqdim olunan bash skripti, əvvəlcə konsol vasitəsilə işi yoxlayırıq, əgər bizə lazım olanı göstərirsə (səhv verirsə, onda xmlstarlet qoyuruq), onu /usr/local/bin/opennebula_exporter.sh-ə köçürün.
Hər dəqiqə üçün bir cron tapşırığı əlavə edin:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metriklər görünməyə başladı, onları Prometheus ilə götürə və qrafiklər qura və xəbərdarlıq edə bilərsiniz. Məsələn, qrafanada belə sadə bir tablosunu çəkə bilərsiniz.
(görə bilərsiniz ki, burada cpu, ram-i aşmışam)
Zabbix-i sevən və istifadə edənlər üçün var
Hər şeyi izləmək üçün əsas odur. Əlbətdə ki, əlavə olaraq, quraşdırılmış virtual maşın monitorinq alətlərindən istifadə edərək və məlumatları fakturaya yükləmək, bunu daha yaxından etməyə başlayana qədər hər kəsin öz baxışı var.
Xüsusilə başlamadı isə giriş üçün. Ən asan seçim /var/lib/one qovluğunu normal ifadələrlə təhlil etmək üçün td-agent əlavə etməkdir. Məsələn, sunstone.log faylı nginx regexp və platformaya daxil olma tarixini göstərən digər fayllara uyğun gəlir - üstünlük nədir? Yaxşı, məsələn, biz "Səhv, səhv" sayını açıq şəkildə izləyə bilərik və nasazlığın harada və hansı səviyyədə olduğunu tez bir zamanda izləyə bilərik.
3. Yedəkləmələr
Ödənişli bitmiş layihələr də var - məsələn, sentyabr :OpenNebula_Backup. Burada başa düşməliyik ki, sadəcə olaraq maşının təsvirinin ehtiyat nüsxəsini çıxarmaq, bu halda, heç də belə deyil, çünki virtual maşınlarımız tam inteqrasiya ilə işləməlidir (şəbəkə parametrlərini, vm adını və xüsusi parametrləri təsvir edən eyni fayl konteksti). ərizələriniz). Buna görə də, burada nəyi və necə ehtiyat nüsxəsini çıxaracağımızı müəyyənləşdiririk. Bəzi hallarda vm-nin özündə olanların surətini çıxarmaq daha yaxşıdır. Və bəlkə də bu maşından yalnız bir diskin ehtiyat nüsxəsini çıxartmalısınız.
Məsələn, biz müəyyən etdik ki, bütün maşınlar oxuduqdan sonra davamlı şəkillərlə işə başlayır
Beləliklə, əvvəlcə şəkli vm-dən yükləyə bilərik:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Şəbəkədə də tapıldı və daha çox var , lakin burada yalnız qcow2 saxlama altında.
Ancaq hamımız bildiyimiz kimi, gec-tez artımlı ehtiyat nüsxələri istədiyiniz bir an gəlir, bu daha çətindir və bəlkə rəhbərlik pullu bir həll üçün pul ayıracaq və ya başqa yolla gedəcək və burada yalnız resursları kəsdiyimizi başa düşəcək və proqram səviyyəsində rezervasiyalar və yeni qovşaqların və virtual maşınların sayının əlavə edilməsi - bəli, burada deyirəm ki, buluddan istifadə sırf proqram klasterlərini işə salmaq və verilənlər bazasını başqa platformada işə salmaq və ya mümkünsə, onu təchizatçıdan hazırlamaq üçündür. .
4. İstifadə asanlığı
Bu paraqrafda mən qarşılaşdığım problemləri təsvir edəcəyəm. Məsələn, şəkillərə görə, bildiyimiz kimi, davamlı var - bu şəkil vm-ə quraşdırıldıqda, bütün məlumatlar bu təsvirə yazılır. Davamlı deyilsə, o zaman şəkil yaddaşa kopyalanır və məlumatlar orijinal şəkildən kopyalanana yazılır - şablon blankları belə işləyir. Davamlı qeyd etməyi unutaraq dəfələrlə özünə problem yaratdı və 200 GB təsvir kopyalandı, problem ondadır ki, bu proseduru qəti şəkildə ləğv etmək mümkün deyil, siz node'a gedib cari "cp" prosesini öldürməlisiniz.
Əhəmiyyətli çatışmazlıqlardan biri odur ki, sadəcə gui istifadə edərək hərəkətləri geri qaytara bilməzsiniz. Daha doğrusu, siz onları ləğv edəcəksiniz və heç bir şey olmadığını görəcək və yenidən başlayacaqsınız, ləğv edin və əslində görüntünü kopyalayan 2 cp prosesi olacaq.
Və sonra başa düşməyə gəlir ki, nə üçün opennebula hər yeni nümunəni yeni id ilə nömrələyir, məsələn, eyni proxmox-da 101 id ilə vm yaratdı, onu sildi, sonra id 101-i yenidən yaratdı. Bu, hər yeni id-də baş verməyəcək. instansiya yeni id ilə yaradılacaq və bunun öz məntiqi var - məsələn, köhnə məlumatların və ya uğursuz quraşdırmaların təmizlənməsi.
Eyni şey saxlama üçün də gedir, ən çox bu platforma mərkəzləşdirilmiş saxlama məqsədi daşıyır. Yerli istifadə üçün əlavələr var, lakin bu halda bu barədə deyil. Düşünürəm ki, gələcəkdə kimsə qovşaqlarda yerli yaddaşdan necə istifadə etməyi və istehsalda uğurla istifadə etməyi bacardıqları barədə məqalə yazacaq.
5. Maksimum sadəlik
Təbii ki, nə qədər irəli getsən, səni anlayanlar bir o qədər az olur.
Stendimin şəraitində - nfs saxlama ilə 3 qovşaq - hər şey yaxşı işləyir. Amma gücü söndürmək üçün eksperimentlər aparsaq, o zaman məsələn, snapshot çəkib qovşağın gücünü söndürəndə verilənlər bazasında parametrləri saxlayırıq ki, bir anlıq görüntü var, amma əslində belə deyil. (yaxşı, hamımız başa düşürük ki, biz əvvəlcə bu hərəkət haqqında verilənlər bazasını sql-də yazdıq, lakin əməliyyatın özü uğurlu olmadı). Üstünlüyü ondan ibarətdir ki, snapshot yaratarkən ayrıca bir fayl yaranır və "valideyn" var, buna görə də problemlər olduqda və gui vasitəsilə işləməsə belə, biz qcow2 faylını götürüb ayrıca bərpa edə bilərik.
Şəbəkələrdə, təəssüf ki, hər şey o qədər də sadə deyil. Yaxşı, heç olmasa openstack-dən daha asandır, mən yalnız vlan (802.1Q) istifadə etdim - yaxşı işləyir, lakin şablon şəbəkəsindən parametrlərə dəyişiklik etsəniz, bu parametrlər artıq işləyən maşınlarda tətbiq edilməyəcək, yəni. şəbəkə xəritəsini silmək və əlavə etmək lazımdır, onda yeni parametrlər tətbiq olunacaq.
Hələ də openstack ilə müqayisə etmək istəyirsinizsə, o zaman bunu deyə bilərsiniz, opennebula-da məlumatların saxlanması, şəbəkənin idarə edilməsi, resurslar üçün hansı texnologiyalardan istifadə olunacağına dair dəqiq bir tərif yoxdur - hər bir idarəçi onun üçün daha əlverişli olanı özü üçün qərar verir.
6. Əlavə plaginlər və quraşdırmalar
Axı, anladığımız kimi, bulud platforması təkcə kvm deyil, həm də vmware esxi-ni idarə edə bilir. Təəssüf ki, kimsə yazmağa çalışsa, Vcenter ilə hovuzum yox idi.
Digər bulud provayderlərinə dəstək olaraq bildirilir
AWS, AZURE.
Mən də Vmware Cloud-u selectel-dən bağlamağa çalışdım, amma heç nə olmadı - ümumiyyətlə, çoxlu faktorlar olduğu üçün qol vurdum və hosting provayderinin texniki dəstəyinə yazmağın mənası yoxdur.
Həmçinin, indi yeni versiyada fişəng var - bu, docker üzərində kvm bağlama kimi microvm-in işə salınmasıdır ki, bu da daha çox yönlülük, təhlükəsizlik və performans təkmilləşdirmələri verir, çünki hardware emulyasiyasında resursları sərf etməyə ehtiyac yoxdur. Docker-ə münasibətdə yalnız bir üstünlük görürəm ki, o, əlavə sayda prosesləri əhatə etmir və bu emulyasiyadan istifadə edərkən işğal edilmiş yuvalar yoxdur, yəni. onu yük balanslaşdırıcısı kimi istifadə etmək olduqca mümkündür (lakin bütün testləri tam şəkildə tamamlayana qədər bu barədə ayrıca məqalə yazmağa dəyər).
7. Müsbət istifadəçi təcrübəsi və səhvlərin aradan qaldırılması
Əsərlə bağlı müşahidələrimi bölüşmək istədim, bir hissəsini yuxarıda təsvir etdim, daha çox yazmaq istəyirəm. Həqiqətən, yəqin ki, əvvəlcə bunun düzgün sistem olmadığını və ümumiyyətlə hər şeyin qoltuqaltı olduğunu düşünən tək mən deyiləm - onunla necə işləyirlər? Ancaq sonra başa düşür və hər şey olduqca məntiqlidir. Təbii ki, hamını razı sala bilməzsən və bəzi şeyləri təkmilləşdirmək lazımdır.
Məsələn, disk şəklini bir məlumat anbarından digərinə köçürmək üçün sadə əməliyyat. Mənim vəziyyətimdə nfs ilə 2 qovşaq var, mən şəkli göndərirəm - kopyalama frontend opennebula vasitəsilə gedir, baxmayaraq ki, biz hamımız məlumatların birbaşa hostlar arasında kopyalanmasına öyrəşmişik - eyni vmware, hyper-v, biz buna öyrəşiblər, amma burada başqasına. Fərqli bir yanaşma və fərqli bir ideologiya var və 5.12 versiyasında "məlumat anbarına köçür" düyməsi silindi - yalnız maşın özü köçürülür, yaddaş deyil. mərkəzləşdirilmiş saxlama deməkdir.
Bundan əlavə, müxtəlif səbəblərdən qaynaqlanan məşhur xəta “Virtual maşının yerləşdirilməsi xətası: /var/lib/one//datastores/103/10/deployment.5-dən domen yaradıla bilmədi” Aşağıda baxılacaq ən yaxşı şey var.
- Oneadmin istifadəçisi üçün şəkil hüquqları;
- oneadmin istifadəçisi üçün libvirtd-i işə salmaq icazələri;
- Məlumat anbarı düzgün quraşdırılıbmı? Gedin və düyünün özündə olan yolu yoxlayın, bir şey düşmüş ola bilər;
- Yanlış konfiqurasiya edilmiş şəbəkə, daha doğrusu, frontenddə, şəbəkə parametrlərindədir ki, br0 vlan üçün əsas interfeysdir və qovşaqda bridge0 yazılır - eyni olmalıdır.
Sistem məlumat anbarı vm üçün metadata saxlayır, əgər siz davamlı təsvirə malik vm işlədirsinizsə, onda vm-nin vm-ni yaratdığınız yaddaşda ilkin yaradılmış konfiqurasiyaya girişi olmalıdır - bu çox vacibdir. Buna görə də, vm-ni başqa bir məlumat anbarına köçürərkən hər şeyi iki dəfə yoxlamaq lazımdır.
8. Sənədləşmə, icma. Əlavə inkişaf
Qalan, yaxşı sənədlər, icma və ən əsası, layihənin gələcəkdə yaşamağa davam etməsi.
Burada, ümumiyyətlə, hər şey kifayət qədər yaxşı sənədləşdirilmişdir və hətta rəsmi mənbəyə görə, müəyyən etmək və suallara cavab tapmaq problem olmayacaq.
İcma aktiv. Quraşdırmalarınızda istifadə edə biləcəyiniz bir çox hazır həllər dərc edir.
Hal-hazırda, 5.12-dən bəri şirkətdəki bəzi siyasətlər dəyişdi Layihənin necə inkişaf edəcəyini görmək maraqlı olacaq. Başlanğıcda mən öz həllərindən istifadə edən bəzi satıcıları və sənayenin nə təklif etdiyini xüsusi qeyd etdim. Əlbəttə ki, sizin üçün nə istifadə edəcəyiniz dəqiq cavab yoxdur. Lakin kiçik təşkilatlar üçün öz kiçik şəxsi buludlarını saxlamaq göründüyü qədər baha olmaya bilər. Əsas odur ki, sizə nə lazım olduğunu dəqiq bilməkdir.
Nəticədə, bulud sistemi olaraq nə seçdiyinizdən asılı olmayaraq, bir məhsulda dayanmamalısınız. Vaxtınız varsa, başqa daha açıq həll yollarına baxmalısınız.
Yaxşı söhbət var aktiv şəkildə kömək edin və problemin həllini Google-da axtarmaq üçün göndərməyin. Qoşulun.
Mənbə: www.habr.com