Cloudian i jego przygody

Jak obiecałem tak zrobiłem. Oto kolejny artykuł o przygodach naszego rycerza – znanego wszystkim jako Cloudian. Tak naprawdę, to będzie początek jego przygód, ponieważ wcześniej nie było mi dane poznać go od strony kunsztu technicznego. 

Artykuł ten jest kontynuacją pierwszej części przygód Cloudiana. Tym razem odpowiem na postawione pytanie, czy nasz waleczny bohater jest rycerzem na białym koniu, czy też paziem na kobyle.

Jak wiemy, Cloudian Hyperstore nie tylko przechowuje dane jako zwykły zasób dyskowy, ale również ma wiele funkcji i mechanizmów, które działają w ramach tej przestrzeni dyskowej. Sprawdzę, czy uruchomienie i zarządzanie Cloudianem jest proste i szybkie. Nie będę przeprowadzał żadnych testów wydajnościowych, ponieważ nie posiadając odpowiedniego sprzętu, trudno miarodajnie przeprowadzić taki test. Oczywiście całość uruchamiam jako maszyny wirtualne w środowisku VMware. 

https://lelusz.comblog/cloudian-niczym-rycerz-na-bialym-koniu/

Podzieliłem tę przygodę na trzy proste etapy.  

Etap 1.: przygotowanie.  

Chyba nikt tego nie robi, tzn. nie czyta dokumentacji technicznej. To jest jak czytanie instrukcji obsługi przed uruchomieniem reaktora jądrowego. Może się udać albo i nie. Oczywiście w naszym przypadku odpowiedzialność jest sporo mniejsza, ale czasu stracimy sporo, tego nam nikt już nie odda. Koniec gadania, czas na lekturę… 

Po 5 minutach czytania wiemy wszystko. Sprawa jest banalna, potrzeba tylko systemów operacyjnych, instalatora i licencji. 

W końcu Install Guide ma tylko 40 stron. Wspomnę jeszcze, że w trakcie pisania artykułu HyperStore jest dostępny w wersji 7.2.3, ale już pojawiła się wersja 7.3, którą możemy sobie testować.  

Ale wracając do instalacji. Sam system operacyjny jaki jest zalecany, to CentOS lub RHEL w wersji 7.7. Jeżeli chodzi o same wymagania sprzętowe to: 1 lub 2 CPU (8 rdzeni per CPU), 128GB RAM lub więcej, trochę dysków twardych na dane oraz SSD na potrzeby bazy i 2 karty sieciowe 10GbE lub szybsze. Oczywiście są to rekomendowane wymagania dla środowisk produkcyjnych. Nie są one jakieś ogromne, ale jak już mamy klaster stworzony z 5 nodów to 640GB RAM może zrobić swoje. W sumie nie mamy się co martwić, bo w końcu nasze infrastruktury są RAMem płynące. Oczywiście sam instalator wytknie nam „błędy”, że jest za mało dysków, czy RAMu.  

Drobna rzecz, która mówi nam, gdzie tkwi problem, ale jest niezwykle przydatna. Wracając do samego systemu. Możemy go pobrać również ze strony Cloudiana. Dostępne są obrazy ISO jak i OVA. Możemy również przygotować sobie sami taki system, również nie jest to problemem. Cloudian nie wspiera innych dystrybucji Linuxa oraz Windowsa. Takie rozwiązanie jest dobre, ponieważ ciężko jest pisać aplikacje, które działają na wielu systemach operacyjnych, które mają problemy ze sobą i generują miliony błędów i problemów. Dodatkowymi wymaganiami na czas instalacji jest wyłączenie selinux oraz wbudowanego firewalla/iptables. Oczywiście nie ma się co martwić, to tylko na czas instalacji. Sam Cloudian wygeneruje i załaduje konfiguracje firewalla tak, aby było potencjalnie bezpiecznie. Z takich grubszych wymagań to posiadanie Python 2.7 oraz zamontowanie partycji /tmp bez flagi noexec.  

Kolejnym wymaganiem, które podane jest w dalszych częściach instrukcji do Cloudiana jest wykorzystywanie odpowiednio skonfigurowanych dysków.

HyperStore nie wspiera XFS’a, LVM’a, VirtIO oraz multipathingu. Jednym słowem, wystarczą czyste dyski, a resztę zrobi za nas skrypt dostarczany przez producenta, o którym za chwilę. Dodatkowo HyperStore domyślnie instaluje Cassandre i Redis tam, gdzie już jest system operacyjny, dlatego aby przyspieszyć te bazy danych, warto zainstalować system na dyskach SSD. Oczywiście w tym wypadku rekomendowany jest RAID 1 (w przypadku VM nie ma to teoretycznie znaczenia). Dodatkowo wymagane jest wykorzystanie UUID’ów do montowania dysków twardych, a nie etykiet. W szybki sposób możemy zmienić te ustawienia we “fstab”. Systemy Linux rezerwują 5% miejsca dla użytkownika root oraz na usługi systemowe. Można tą wartość zmienić na 0% dla dysków, gdzie będą przechowywane dane. Daje nam to kilka lub kilkanaście dodatkowych GB na dane. 

Skrypt, o którym wspomniałem wcześniej, dostarczany jest przez producenta. W sposób „klikalny” możemy skonfigurować serwery. Nie musimy wszystkiego robić ręcznie. Jest to kolejne, również bardzo pomocne rozwiązanie.  

No i powtarzamy całą konfigurację na każdym serwerze, który ma należeć do klastra. To trochę jak w filmie “Na skraju jutra”. 

Etap 2.: instalacja. 

Skoro mamy już przygotowane systemy operacyjne, możemy skonfigurować load balancer. Serio? Tak! 

Opcje są dwie: DNS lub jakiś dostępny load balancer. Wykorzystanie w środowisku konfiguracji DNS nie jest zbyt dobrym pomysłem, ponieważ klasyczne serwery DNS nie mają możliwości sprawdzenia stanu serwera. W razie awarii ruch może być kierowany dalej do serwera, który już nie odpowiada. Słabe rozwiązanie. Rozsądnie będzie wykorzystywać jednak load balancer. No i znów spotykamy kilka możliwości:

• Możemy wykorzystać darmowe HAproxy, 
• ale również takie rozwiązania, jakNSX,
• AVI,
• F5 i wiele innych.  

Tak dużo możliwości, a tak mało czasu na przetestowanie tego wszystkiego.

Mając już wszystko – instalujemy. 

Sprawa jest banalnie prosta, ponieważ potrzebny jest plik instalacyjny i licencja. Licencje musimy mieć swoją, a plik instalacyjny pobrać ręcznie lub za pomocą narzędzia z etapu pierwszego. Odpalamy polecenie instalacji i dzieje się magia.  

A tak na poważnie, wcześniej generujemy plik, gdzie zapisane są ustawienia węzłów (również można to zrobić za pomocą skryptu) i po instalacji wszystkiego wskazujemy go i podajemy hasła do systemów. 

Resztę zrobi za nas puppet. 

Etap 3.: celebrowanie sukcesu.  

Możemy się zalogować do usługi, konfigurujemy nowe hasła itp. i już możemy działać. Jak widzimy, sprawa samej instalacji jest prosta. Przygotowanie systemów operacyjnych jest bardziej czasochłonna, dodatkowo dochodzą aspekty sieciowe jak load balancer. W pewnych miejscach, jak systemy operacyjne, aby ułatwić nam prace, producent oprogramowania dorzuca nam skrypty, co przyspiesza instalacje/konfiguracje.

Dodatkowo producenci load balancerów, jak i sam Cloudian, daje nam rekomendacje i instrukcje w jaki sposób skonfigurować tę usługę.  

Jest jeszcze spora ilość elementów konfigurowalnych w usłudze. Można ją integrować z innymi usługami nie tylko formie klasycznej, ale i także jako składowanie backupów czy na potrzeby kontenerów. Sama usługa ma dość niski próg wejścia, aby ją uruchomić, co jest sporym plusem. Samo zarządzanie również nie jest problematyczne. Ilość błędów oraz poprawek jest niewielka, a produkt wygląda na stabilny i dopracowany.  

Zdecydowanie Cloudian nie jest paziem na nędznej kobyle. 

Pamiętajmy jednak, że nie dbając o podstawowe rzeczy, może się taki stać, zresztą jak każda inna usługa. Dlatego też warto odpowiednio przygotować naszego rumaka i zbroję, a będziemy “kopytkować” bezpiecznie i daleko ku przygodzie. Zachęcam do testów i wdrażania.  

Jako uzupełnienie artykułów na blogu, na naszym kanale YouTube pojawi się demo, opisujące jak wygląda instalacja i konfiguracja w rzeczywistości – Cloudian nie pozostawi po sobie jedynie suchego tekstu.   

Testy Cloudian Hyperstore odbyły się dzięki uprzejmości firmy CLICO, największego – ze 100% kapitałem polskim – specjalizowanego dystrybutora z wartością dodaną w Polsce i regionie CEE, koncentrującego się na trzech obszarach: bezpieczeństwie, sieciach i zarządzaniu.