Piszki Lab

Analiza przypadku w języku przodków…

CloudStack – Instalacja i konfiguracja, część 1, koncepcja i terminologia.

| 2 komentarze

Tym artykułem chciałbym otworzyć całą serię wpisów na temat Apache CloudStack. Od dłuższego czasu zajmuję się tym rozwiązaniem, zebrałem całkiem spory bagaż doświadczeń którymi chętnie się podzielę. Zaczniemy od odpowiedzi na pytanie, czemu CloudStack (a nie OpenStack, oVirt, OpenNebula, Proxmox lub inny Stack)? Każde z wymienionych rozwiązań testowałem, każde jest ciekawe, każde ma swój pomysł na chmurę, ale jedynie CloudStack jest najbardziej zbliżony do funkcjonalności jaką oferuje VMware vCenter połączone z VMware NSX (to oczywiście moje zdanie). CloudStack jest oprogramowaniem otwarto źródłowym, jest zwarty (nie ma stu modułów instalowanych osobno), skaluje się od jednego serwera do N, może funkcjonować na jednym hoście razem z hyperwizorem (do testów jak znalazł), dysponuje bardzo rozbudowanym API, ma komercyjne wsparcie i używają go duże firmy. Należy pamiętać, że CloudStack jest profilowany jako usługa typu Public Cloud, oznacza to, że jest nastawiony na funkcjonowanie na styku z Internetem. Na szczęście da się go bez problemu używać wewnątrz organizacji tak, jak to się dzieje w przypadku VMware vCenter.

clou1

Zaczniemy od wyjaśnienia koncepcji funkcjonowania CloudStack. Jak wspomniałem, jest to rozwiązanie pozwalające zbudować publiczną lub prywatną chmurę typu infrastruktura jako usługa (IaaS). CloudStack potrafi zarządzać wieloma hyperwizorami (KVM, ESXi, Xen, LXC, Hyper-V), wspiera proste (płaskie) i zaawansowane sieci, dostarcza zaawansowane usługi takie jak DNS, DHCP, routing, VPN. Oprócz zaawansowanego API dostarcza bardzo rozbudowany interfejs graficzny dostępny poprzez WWW. Wspiera całą gamę rozwiązań dyskowych, takich jak np. GlusterFS, Ceph i jako jedyne znane mi rozwiązanie, wpiera SharedMountPoint czyli lokalnie montowany, współdzielony zasób (dokładnie jak VMware VMFS). CloudStack pozwala się masywnie skalować do rozmiarów geograficznych (wiele datacenter) co odzwierciedla jego struktura logiczna.

cloud2

Terminologię należy przyswoić, ma ona swoje odzwierciedlenie w interfejsie CloudStack. Region to nic innego jak jednostka grupująca lokalne Data Center (np. z danego obszaru), Zona to odpowiednik pojedynczego Data Center (w nim będziemy pracować), Pod odpowiada logice DC (może to być pojedyncza szafa Rack lub cała grupa wpięta do jednego segmentu sieci, każdy Pod ma osobną sieć MGMT), Cluster to oczywiści klaster serwerów zapewniających usługi (np. KVM). Kolejnym, typowym jedynie dla CloudStack, elementem jest podejście do przestrzeni dyskowej.

cloud3

Secondary Storage to usługa typu NFS zapewniająca przestrzeń do przechowywania obrazów źródłowych (Template VM), migawek dysków (snapshot), obrazów ISO. Secondary Storage jest wspólne dla całego Data Center (Zona). Primary Storage to tradycyjna przestrzeń dyskowa podłączana do klastra (CloudStack wspiera też dyski lokalne serwerów). Wymogiem jest posiadanie przynajmniej jednego serwera NFS (może to być np. NAS) i jednego dysku typu Primary (lokalny lub zdalny). Przejdziemy teraz do omówienia sieci (oczywiście skrótowego), rozróżniamy sieć typu Basic i Advanced. Wyboru sieci dokonujemy w trakcie zainicjowania danej Zony i nie możemy jej zmienić w trakcie funkcjonowania.

cloud4

Powyższy rysunek przedstawia model typu Basic, separacja sieci poprzez VLAN, jeden fizyczny router i switch, sieć publiczna może być lokalną adresacją. Oczywiście możemy używać jednej sieci bez VLAN do wszystkiego lub miksować sieci z VLAN i bez VLAN (przez różne interfejsy). Sieć typ podstawowego jest obsługiwana przez mostki sieciowe (cała opisywana przeze mnie konfiguracja dotyczyć będzie KVM).

cloud5

Powyższy rysunek przedstawia schemat zaawansowany, możemy w nim tworzyć prywatne sieci VPC (Virtual Private Cloud) stojące za wirtualnym routerem (wymagane są tagi VLAN), sieci izolowane, sieci współdzielone. Separacja sieci poprzez GRE z zastosowaniem OpenvSwitch (jest wymagany). Tutaj możemy tworzyć już naprawdę ciekawe konfiguracje przypominające to, co mamy w VMware NSX. Konfigurację zaawansowaną z powodzeniem możemy uruchomić na pojedynczym hoście fizycznym.

To oczywiście bardzo skrótowy opis, ale wystarczający do rozpoczęcia zabawy z CloudStack, szczegóły będą wyjaśniane przy poszczególnych aspektach opisywanej instalacji i konfiguracji. Pozostał do omówienia model wdrożenia. W CloudStack wymagany jest fizyczny serwer typu MGMT i minimum jeden host z wirtualizatorem, wygląda to tak:

cloud6

Oczywiście jest to marnotrawstwo, po pierwsze może to być jeden serwer a po drugie modelem do którego będziemy dążyć jest sytuacja w której CloudStack Management Server funkcjonuje jako maszyna wirtualna. Tutaj powstaje dodatkowa trudność, wszystkie VM w CloudStack stoją za wirtualnymi routerami, nie da się wykonać bootstrapa VM MGMT bez zainicjowania sieci (i całej konfiguracji) tak jak to ma miejsce w oVirt. Dlatego my instalację wykonamy według tego modelu:

OPM-MGMT

Konfiguracja ta obejmuje dwa fizyczne serwery, oczywiście drugi serwer może być wirtualną maszyną funkcjonującą wewnątrz CloudStack. Usługi typu GlusterFS mogą być zastąpione innymi (w przypadku jednego serwera może to być dysk lokalny), zastosujemy jednak na pewno MariaDB Galera (klaster MySQL), Keepalived (usługa pływającego adresu IP), HAProxy (wiadomo). CloudStack umożliwia funkcjonowanie wielu serwerów MGMT (nody), poszczególne nody mogą dołączać do klastra w dowolnym momencie, jeśli macie jeden serwer fizyczny to drugi (wirtualny) dołączycie później. Dzięki temu uzyskamy pełną elastyczność, jeśli posiadacie klaster złożony z trzech serwerów to jako Primary Storage polecam bardzo Ceph. W tym artykule to wszystko, będę się do niego odnosił w trakcie instalacji i konfiguracji (terminologia), całość instalacji zostanie przeprowadzona w systemie CentOS 7, ale może to być dowolny Linuks wspierający KVM. Model wdrożenia z rysunku powyżej jest zbliżony do tego co jest uruchamiane w systemach produkcyjnych.

EDIT:

Ze względu na zmiany w Lab, dalsza konfiguracja zostanie przedstawiona na bazie klastra złożonego z trzech serwerów (wirtualnych). Trzy serwery dają większe możliwości, zamiast GlusterFS zastosujemy Ceph. Oprócz tego nic się nie zmieni w konfiguracji.

Oceń ten artykuł:
[Total: 4 Average: 5]

2 Comments

Dodaj komentarz

Required fields are marked *.