Piszki Lab

Analiza przypadku w języku przodków…

CloudStack – instalacja i konfiguracja, część 4, CloudStack Management Server

| 0 comments

W poprzednich trzech częściach omówiliśmy Apache CloudStack, jego terminologię oraz przygotowaliśmy węzeł (CentOS 7) do pełnienia wielu ról. W tym artykule skupimy się na uruchomieniu CloudStack Management Server oraz zainicjowaniu pierwszej Zony. Efektem końcowym będzie w pełni funkcjonalny klaster CloudStack gotowy do pracy. Przypomnę tylko, że omawiany klaster to trzy serwer CentOS 7, wykorzystujemy MariaDB Galera z keepalived i haproxy. W następnych częściach tej serii zostanie omówiona podstawowa konfiguracja w bierzącym działaniu, dobre praktyki oraz analiza błędów.

cs21

Konfigurację zaczniemy od przygotowania bazy danych, tworzymy użytkownika i nadajemy uprawnienia. Najlepsza opcja to pozostawienie domyślnych nazw, czyli cloud/cloud (hasło dowolne).

W mysql wydajemy polecenia:

grant all on *.* to cloud@’cstack.piszki.lab’ identified by ‘dbpass’;

flush privileges;

Następnie uruchamiamy skrypt inicjujący bazę danych CloudStack (—deploy-as=cloud:dbpass) na pierwszym nodzie, na każdym kolejnym który ma być częścią klastra, wydajemy to polecenie bez części –deploy-as. CloudStack skaluje się bez ograniczeń, już na starcie możemy mieć wiele CloudStack Management Server. Ja zdecydowałem się tylko na dwa aby utrzymać HA (konfiguracja HAProxy została omówiona w poprzedniej części).

cs2

Następnie wydajemy polecenie cloudstack-setup-management:

cs3

Teraz musimy pobrać pliki template maszyn systemowych (routery, proxy, secondary storage). Mimo, że w części trzeciej pisałem o użyciu NFS lokalnie, to ostatecznie użyłem zasobu z mojego serwera NAS (zdecydowała oszczędność miejsca). Udział NFS, który będzie pełnił rolę Secondary Storage, montujemy na chwilę lokalnie i wykonujemy skrypt jak niżej.

cs4

Pobiera on i rozpakowuje pliki tworząc przy okazji odpowiedni schemat katalogów.

cs5

W tym momencie jesteśmy gotowi do uruchomienia CloudStack Management Server (systemctl start cloudstack-management). Warto sprawdzić w logu /var/log/cloudstack/management/management-server.log czy wszystko jest ok i nie ma błędu. Warto w tym momencie wykonać także zrzut bazy danych cloud i generalnie, stwórzcie w cron skrypt który do wybranego katalogu co godzinę będzie wykonywał zrzut bazy cloud. W tej bazie jest wszystko, jej uszkodzenie uszkadza całą instalację, wielu kroków konfiguracyjnych nie da się cofnąć, cofnięcie się do bazy z przed zmian często ratuje sytuację.

Wchodzimy na adres (w moim przypadku http://cstack.piszki.lab/client via haproxy) http://host:8080/client logujemy się admin/password i naszym oczom ukazuje się konfigurator.

cs6

Wybieramy oczywiście opcję zaawansowaną. Podajemy nazwę pierwszej zony i adresy IP naszych serwerów DNS. Jak zauważycie, w konfiguratorze jest rozróżnienie na serwery DNS zewnętrzne i wewnętrzne, w obu przypadkach to mogą być te same serwery lokalne.

cs7

Hyperwizorem jest oczywiście KVM, jest to też jedyne miejsce w którym możemy włączyć lokalny storage dla VM (jeśli nie zdecydowaliśmy się użyć Ceph opisanego w poprzedniej części).

cs8

Wykorzystamy OpenvSwitch w sieci zaawansowanej z izolacją GRE dla sieci Trunk.

cs9

Musimy powiązać każdy typ sieci z odpowiednim interfejsem, wszystko to zostało omówione w części drugiej.

cs10

Dodajemy adresację publiczną dla naszej Zony. W idealnym świecie to powinna być adresacja internetowa, my użyjemy jednej z lokalnych sieci a ewentualny dostęp z zewnątrz załatwimy później za pomocą NAT. Taka konfiguracja jest jak najbardziej wspierana (otrzymamy efekt ala VMware vSphere), jednak trzeba pamiętać, że CloudStack to usługa dla dostawców chmury, powinna działać na styku z Internetem.

cs11

Co to jest POD zostało omówione w części pierwszej, dodajemy tutaj adresację mgmt zarezerwowaną dla urządzeń zewnętrznych (inna niż pula).

cs12

Sieci gościa to zakres VLAN z których będą korzystać sieci typu VPC (omówimy to w kolejnym artykule).

cs13

Tworzymy klaster.

cs14

W którym musimy podać pierwszy węzeł który zostanie automatycznie podłączony do CloudStack.

cs15

Dodajemy Primary Storage, tutaj udział CephFS omówiony w poprzedniej części.

cs16

Dodajemy Secondary Storage, tutaj udział z NAS.

cs17

Kończymy konfigurację, jeśli wszystko jest prawidłowo zrobione to możemy włączyć Zonę. Włączenie zony ma te konsekwencje, że zostaną automatycznie uruchomione dwie systemowe maszyny wirtualne Console Proxy VM i Secondary Storage VM. Pierwsza obsługuje konsole a druga template maszyn. Zonę można zawsze wyłączyć w sekcji Infrstructure, jeśli jest włączona a maszyny systemowe nie chcą się poprawnie uruchomić, proces ich tworzenia jest wznawiany w pętli. Jeśli coś jest nie tak, wyłączamy Zonę, usuwamy problem i ją włączamy.

cs19

Warto w trakcie tworzenia konfiguracji i uruchamiania Zony włączyć podgląd management-server.log aby sprawdzić czy nie pojawiają się błędy. Poniżej fragment logu który pokazuje jak wygląda komunikat prawidłowo dodanego hosta. Jeśli coś jest nie tak, tutaj zawsze jest informacja która sekcja zawiodła.

cs18

Jeżeli wszystko jest OK, to powinniście zobaczyć ekran jak na pierwszym obrazku w tym artykule, informacje o pojemności dysków pojawią się gdy poprawnie uruchomi się i zgłosi maszyna Secondary Storage VM. Kolejne hosty klastra dodajemy ręcznie w sekcji Infrstructure –> Hosts:

cs20

Oceń ten artykuł:
[Głosów:0    Średnia:0/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.