Otwarta mgławica. Krótkie notatki

Otwarta mgławica. Krótkie notatki

Cześć wszystkim. Ten artykuł został napisany dla tych, którzy wciąż wahają się pomiędzy wyborem platform wirtualizacyjnych i po przeczytaniu artykułu z serii „Zainstalowaliśmy proxmox i ogólnie wszystko jest w porządku, 6 lat działania bez ani jednej przerwy”. Ale po zainstalowaniu tego czy innego gotowego rozwiązania pojawia się pytanie: jak mogę to poprawić tutaj, aby monitorowanie było bardziej zrozumiałe, a tutaj, aby kontrolować kopie zapasowe…. A potem przychodzi czas i zdajesz sobie sprawę, że potrzebujesz czegoś bardziej funkcjonalnego, chcesz, aby wszystko w twoim systemie stało się jasne, a nie ta czarna skrzynka, lub chcesz użyć czegoś więcej niż hypervisora ​​i kilku maszyn wirtualnych. W tym artykule będzie zawarte kilka przemyśleń i praktyk opartych na platformie Opennebula - wybrałem ją, ponieważ. nie wymaga zasobów, a architektura nie jest tak złożona.

I tak, jak widzimy, wielu dostawców usług chmurowych pracuje na kvm i tworzy zewnętrzne połączenia w celu sterowania maszynami. Oczywiste jest, że duzi hostingodawcy piszą własne frameworki dla infrastruktury chmurowej, na przykład ten sam YANDEX. Ktoś korzysta z openstack i na tej podstawie tworzy połączenie - SELECTEL, MAIL.RU. Jeśli jednak dysponujesz własnym sprzętem i małą kadrą specjalistów, to zazwyczaj wybierasz coś gotowego – VMWARE, HYPER-V, są licencje bezpłatne i płatne, ale nie o tym teraz mówimy. Porozmawiajmy o entuzjastach – to ci, którzy nie boją się oferować i próbować czegoś nowego, pomimo tego, że firma wyraźnie dała do zrozumienia: „Kto będzie to po tobie obsługiwał”, „Czy wprowadzimy to później do produkcji” ? Straszny." Można jednak najpierw zastosować te rozwiązania na stanowisku probierczym i jeśli wszystkim się to spodoba, wówczas można postawić kwestię dalszego rozwoju i zastosowania w poważniejszych środowiskach.

Poniżej znajduje się także link do raportu www.youtube.com/watch?v=47Mht_uoX3A od aktywnego uczestnika rozwoju tej platformy.

Być może w tym artykule coś będzie zbędne i już zrozumiałe dla doświadczonego specjalisty, a w niektórych przypadkach nie będę opisywał wszystkiego, ponieważ podobne polecenia i opisy są dostępne w Internecie. To tylko moje doświadczenia z tą platformą. Mam nadzieję, że aktywni uczestnicy dopiszą w komentarzach, co można było zrobić lepiej i jakie błędy popełniłem. Wszystkie działania odbywały się na domowym stojaku składającym się z 3 komputerów PC o różnych charakterystykach. Ponadto nie wskazałem, jak działa to oprogramowanie i jak je zainstalować. Nie, tylko doświadczenie administracyjne i problemy, które napotkałem. Być może będzie to przydatne dla kogoś w ich wyborze.

Więc zacznijmy. Jako administrator systemu ważne są dla mnie poniższe punkty, bez których raczej nie skorzystam z tego rozwiązania.

1. Powtarzalność instalacji

Instrukcji instalacji opennebuli jest mnóstwo, nie powinno być żadnych problemów. Z wersji na wersję pojawiają się nowe funkcje, które nie zawsze będą działać przy przechodzeniu z wersji do wersji.

2. Monitorowanie

Będziemy monitorować sam węzeł, kvm i opennebulę. Na szczęście jest już gotowy. Istnieje wiele opcji monitorowania hostów Linux, ten sam Zabbix lub eksporter węzłów - kto woli, co lepsze - w tej chwili definiuję to jako monitorowanie metryk systemu (temperatura, w której można ją zmierzyć, spójność macierzy dyskowej), poprzez zabbix , a jeśli chodzi o wnioski za pośrednictwem eksportera Prometheus. Na przykład do monitorowania kvm możesz wziąć projekt github.com/zhangjianweibj/prometheus-libvirt-exporter.git i ustaw go tak, aby działał przez systemd, działa całkiem dobrze i pokazuje metryki KVM, jest też gotowy dashboard grafana.com/grafana/dashboards/12538.

Na przykład oto mój plik:

/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

I tak mamy 1 eksportera, potrzebujemy drugiego do monitorowania samej mgławicy Open, użyłem tego github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Można dodać do normalnego eksporter_węzłów aby monitorować system, wykonaj następujące czynności.

W pliku node_exporter zmieniamy początek w następujący sposób:

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

Utwórz katalog mkdir -p /var/lib/opennebula_exporter

bash przedstawiony powyżej, najpierw sprawdzamy działanie przez konsolę, jeśli pokazuje to, czego potrzebujemy (jeśli daje błąd, to zainstaluj xmlstarlet), skopiuj go do /usr/local/bin/opennebula_exporter.sh

Dodaj zadanie cron na każdą minutę:

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

Zaczęły pojawiać się metryki, można je brać jak prometeusz i budować wykresy oraz robić alerty. W Grafanie możesz narysować np. taki prosty dashboard.

Otwarta mgławica. Krótkie notatki

(jasne, że tutaj przeciążam procesor, ram)

Dla tych, którzy kochają i używają Zabbix, istnieje github.com/OpenNebula/addon-zabbix

Jeśli chodzi o monitorowanie, najważniejsze jest to, że istnieje. Oczywiście można dodatkowo skorzystać z wbudowanych narzędzi do monitorowania maszyn wirtualnych i wgrać dane do rozliczeń, tutaj każdy ma swoją wizję, ja jeszcze nie zacząłem nad tym bliżej pracować.

Tak naprawdę jeszcze nie zacząłem się logować. Najprostszą opcją jest dodanie td-agent w celu przeanalizowania katalogu /var/lib/one za pomocą wyrażeń regularnych. Przykładowo plik sunstone.log pasuje do wyrażenia regularnego nginx i innych plików pokazujących historię dostępu do platformy - jaka jest tego zaleta? Cóż, możemy na przykład jednoznacznie prześledzić liczbę „Błąd, błąd” i szybko sprawdzić, gdzie i na jakim poziomie występuje awaria.

3. Kopie zapasowe

Istnieją również płatne projekty ukończone - np. wrz wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Tutaj musimy zrozumieć, że samo utworzenie kopii zapasowej obrazu maszyny nie jest w tym przypadku wcale takie samo, ponieważ nasze maszyny wirtualne muszą działać z pełną integracją (ten sam plik kontekstowy, który opisuje ustawienia sieciowe, nazwę maszyny wirtualnej i niestandardowe ustawienia dla twoich aplikacji) . Dlatego tutaj decydujemy, co i jak będziemy tworzyć kopie zapasowe. W niektórych przypadkach lepiej jest zrobić kopie zawartości samego vm. A może wystarczy wykonać kopię zapasową tylko jednego dysku z danej maszyny.

Ustaliliśmy na przykład, że wszystkie maszyny zaczynają od trwałych obrazów, dlatego po przeczytaniu docs.opennebula.io/5.12/operative/vm_management/img_guide.html

Oznacza to, że najpierw możemy załadować obraz z naszego vma:

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

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

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

Znalazłem też w internecie ciekawy raport i jest więcej taki otwarty projekt, ale jest tylko miejsce na qcow2.

Ale jak wszyscy wiemy, prędzej czy później nadejdzie czas, gdy zapragniesz przyrostowych kopii zapasowych, tutaj jest to trudniejsze i być może kierownictwo przeznaczy pieniądze na płatne rozwiązanie, albo pójdzie w drugą stronę i zrozumie, że tutaj tylko ograniczamy zasoby, i tworzenie kopii zapasowych na poziomie aplikacji oraz dodawanie szeregu nowych węzłów i maszyn wirtualnych - tak, tutaj mówię, że używanie chmury wyłącznie do uruchamiania klastrów aplikacji i uruchamianie bazy danych na innej platformie lub branie gotowej jeśli to możliwe, od dostawcy.

4. Łatwość użytkowania

W tym akapicie opiszę problemy jakie napotkałem. Na przykład według obrazów, jak wiemy, są one trwałe - gdy ten obraz jest zamontowany na maszynie wirtualnej, wszystkie dane są zapisywane na tym obrazie. A jeśli nietrwałe, to obraz jest kopiowany do pamięci, a dane są zapisywane do tego, co zostało skopiowane z obrazu źródłowego - tak działają szablony szablonów. Wielokrotnie sprawiałem sobie problemy, zapominając o określeniu trwałego i skopiowano obraz o wielkości 200 GB, problem polega na tym, że tej procedury z pewnością nie można anulować, trzeba udać się do węzła i zabić bieżący proces „cp”.

Jedną z ważnych wad jest to, że nie można anulować działań po prostu za pomocą interfejsu użytkownika. Albo raczej anulujesz je i zobaczysz, że nic się nie dzieje, i uruchomisz je ponownie, anulujesz i tak naprawdę będą już 2 procesy cp, które kopiują obraz.

I wtedy przychodzi do zrozumienia, dlaczego opennebula numeruje każdą nową instancję nowym identyfikatorem, na przykład w tym samym proxmox utworzył vm o identyfikatorze 101, usunął go, następnie tworzysz go ponownie i ma identyfikator 101. W opennebula tak się nie stanie, każda nowa instancja zostanie utworzona z nowym identyfikatorem i ma to swoją własną logikę - na przykład usunięcie starych danych lub nieudane instalacje.

To samo dotyczy przechowywania; przede wszystkim platforma ta ma na celu scentralizowane przechowywanie. Istnieją dodatki do używania lokalnego, ale nie o tym mówimy w tym przypadku. Myślę, że w przyszłości ktoś napisze artykuł o tym, jak udało mu się wykorzystać lokalną pamięć masową na węzłach i z powodzeniem wykorzystać ją na produkcji.

5. Maksymalna prostota

Oczywiście im dalej zajdziesz, tym mniej będzie tych, którzy Cię zrozumieją.

W warunkach mojego stoiska - 3 węzły z pamięcią nfs - wszystko działa dobrze. Ale jeśli będziemy przeprowadzać eksperymenty polegające na zaniku prądu, np. podczas uruchamiania migawki i wyłączania zasilania węzła, to zapiszemy w bazie ustawienia, że ​​jest migawka, a tak naprawdę jej nie ma (no cóż, wszyscy rozumiemy, że my początkowo zapisałem bazę danych o tej akcji w sql, ale sama operacja nie powiodła się). Zaletą jest to, że podczas tworzenia migawki tworzony jest oddzielny plik i istnieje „rodzic”, dlatego w przypadku problemów i nawet jeśli nie działa to przez GUI, możemy pobrać plik qcow2 i przywrócić go osobno docs.opennebula.io/5.8/operative/vm_management/vm_instances.html

W sieciach niestety nie wszystko jest takie proste. No cóż, przynajmniej jest łatwiej niż w openstacku, użyłem tylko vlanu (802.1Q) - działa całkiem nieźle, ale jeśli dokonasz zmian w ustawieniach z sieci szablonowej, to te ustawienia nie zostaną zastosowane do już uruchomionych maszyn, tj. musisz usunąć i dodać kartę sieciową, wtedy nowe ustawienia zostaną zastosowane.

Jeśli nadal chcesz to porównać z openstack, możesz powiedzieć tak: w opennebula nie ma jasnej definicji, jakich technologii używać do przechowywania danych, zarządzania siecią, zasobami - każdy administrator sam decyduje, co jest dla niego wygodniejsze.

6. Dodatkowe wtyczki i instalacje

W końcu, jak rozumiemy, platforma chmurowa może zarządzać nie tylko kvm, ale także vmware esxi. Niestety nie miałem basenu z Vcenter, jeśli ktoś próbował to proszę pisać.

Stwierdzono wsparcie dla innych dostawców usług w chmurze docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, Błękit.

Próbowałem też podłączyć Vmware Cloud od Selectel, ale nic nie pomogło - ogólnie zostało zablokowane, bo czynników jest wiele i nie ma sensu pisać do pomocy technicznej dostawcy hostingu.

Ponadto, teraz nowa wersja ma petardę - jest to premiera microvm, rodzaju uprzęży kvm over docker, która zapewnia jeszcze większą wszechstronność, bezpieczeństwo i zwiększoną produktywność, ponieważ nie ma potrzeby marnowania zasobów na sprzęt emulujący. Jedyna przewaga jaką widzę nad Dockerem to to, że nie zajmuje on dodatkowej ilości procesów i nie ma zajętych gniazd przy korzystaniu z tej emulacji tzn. Całkiem możliwe jest użycie go jako modułu równoważenia obciążenia (ale prawdopodobnie warto napisać o tym osobny artykuł, dopóki nie przeprowadzę w pełni wszystkich testów).

7. Pozytywne doświadczenia z użytkowania i debugowania błędów

Chciałem podzielić się swoimi spostrzeżeniami na temat pracy, część opisałem powyżej, chciałbym napisać więcej. Rzeczywiście, pewnie nie jestem jedyny, który w pierwszej chwili uważa, że ​​to nie jest właściwy system i w ogóle wszystko tutaj jest o kulę – jak oni w ogóle z tym współpracują? Ale potem przychodzi zrozumienie, że wszystko jest całkiem logiczne. Oczywiście nie da się zadowolić wszystkich i niektóre aspekty wymagają poprawy.

Na przykład prosta operacja kopiowania obrazu dysku z jednego magazynu danych do drugiego. W moim przypadku są 2 węzły z nfs, wysyłam obraz - kopiowanie odbywa się poprzez frontendową mgławicę open, choć wszyscy jesteśmy przyzwyczajeni do tego, że dane należy kopiować bezpośrednio pomiędzy hostami - w tym samym vmware, hyper-v jesteśmy przyzwyczajony do tego, ale tutaj do innego. Jest inne podejście i inna ideologia, a w wersji 5.12 usunięto przycisk „migruj do datastore” – przenoszona jest tylko sama maszyna, ale nie pamięć, ponieważ oznacza scentralizowane przechowywanie.

Następny jest popularny błąd z różnych przyczyn: „Błąd wdrażania maszyny wirtualnej: Nie można utworzyć domeny z /var/lib/one//datastores/103/10/deployment.5”. Poniżej znajduje się najważniejsza rzecz, na którą należy zwrócić uwagę.

  • Prawa do obrazu dla użytkownika oneadmin;
  • Uprawnienia użytkownika oneadmin do uruchamiania libvirtd;
  • Czy magazyn danych jest poprawnie zamontowany? Idź i sprawdź ścieżkę na samym węźle, może coś odpadło;
  • Źle skonfigurowana sieć, a raczej na froncie jest w ustawieniach sieciowych, że głównym interfejsem dla vlanu jest br0, natomiast na węźle jest zapisane jako Bridge0 - musi być takie samo.

systemowy magazyn danych przechowuje metadane dla Twojej maszyny wirtualnej, jeśli uruchomisz maszynę wirtualną z trwałym obrazem, wówczas maszyna wirtualna musi mieć dostęp do pierwotnie utworzonej konfiguracji w magazynie, w którym utworzono maszynę wirtualną - jest to bardzo ważne. Dlatego podczas przenoszenia maszyny wirtualnej do innego magazynu danych należy wszystko dokładnie sprawdzić.

8. Dokumentacja, społeczność. Dalszy rozwój

A reszta, dobra dokumentacja, społeczność i najważniejsze, że projekt będzie nadal żył w przyszłości.

Generalnie wszystko jest dość dobrze udokumentowane i nawet korzystając z oficjalnego źródła nie będzie problemu z instalacją i znalezieniem odpowiedzi na pytania.

Społeczność, aktywny. Publikuje wiele gotowych rozwiązań, które możesz zastosować w swoich instalacjach.

W tej chwili niektóre zasady w firmie uległy zmianie od wersji 5.12 forum.opennebula.io/t/w kierunku-silniejszej-opennebula-community/8506/14 Ciekawie będzie zobaczyć, jak projekt się rozwinie. Na początku konkretnie wskazałem niektórych dostawców, którzy korzystają z ich rozwiązań oraz to, co oferuje branża. Oczywiście nie ma jednoznacznej odpowiedzi, czego używać. Jednak w przypadku mniejszych organizacji utrzymanie małej chmury prywatnej może nie być tak kosztowne, jak się wydaje. Najważniejsze jest, aby dokładnie wiedzieć, czego potrzebujesz.

Dzięki temu niezależnie od tego, jaki system chmurowy wybierzesz, nie powinieneś poprzestawać na jednym produkcie. Jeśli masz czas, warto przyjrzeć się innym, bardziej otwartym rozwiązaniom.

Jest dobra pogawędka t.me/opennebula Aktywnie pomagają i nie odsyłają Cię do szukania rozwiązania problemu w Google. Dołącz do nas.

Źródło: www.habr.com

Dodaj komentarz