Piszki Lab

Analiza przypadku w języku przodków…

CloudStack – instalacja i konfiguracja, część 2, przygotowanie sieci.

| 0 comments

Wydawać by się mogło, że zainstalowanie CloudStack to nic trudnego, i tak jest. Trzeba jednak dokładnie zaplanować jak będziemy używać sieci i przestrzeni dyskowej i odpowiednio skonfigurować hosta lub hosty do pełnienia funkcji serwera zarządczego i wirtualizatora. W tym poście omówię dokładnie konfigurację sieci na poziomie serwera, pierwsza jest oparta na mostkach a druga na OpenvSwitch (obydwie wykluczają się wzajemnie). Systemem operacyjnym jest najnowszy CentOS 7 (w wersji minimal install), na czas instalacji i konfiguracji proponuję wyłączyć SELinux i FirewallD (do ustawień zapory jeszcze powrócimy). Na potrzeby tego artykułu założyłem że serwer jest wyposażony w minimum dwie karty sieciowe, nie będziemy używać LACP, użyjemy jednej sieci domyślnej bez tagowania (VLAN1) i kilku sieci tagowanych. W przypadku braku w waszej domowej infrastrukturze sieci tagowanej możecie użyć sieci nie tagowanych do wszystkiego, modyfikując odpowiednio konfigurację.

br6

W przypadku CloudStack całością procesu konfiguracji sieci po stronie KVM i systemu operacyjnego (np. w trakcie uruchamiania VM) zarządza CloudStack Agent instalowany na każdym hoście. Konfiguracja ta wymaga podania nazw dla sieci rozróżnianych na poziomie CloudStack. Sieci te to management, public, guest i opcjonalnie storage. Nazwy sieci muszą odpowiadać nazwie cloudbrN, gdzie N to numer (nie musi być kolejny), standardowy schemat to:

cloudbr0 – public

cloudbr1 – mgmt

cloudbr2 – guest

Wszystkie sieci mogą współdzielić jeden mostek podpięty do interfejsu zsumowanego LACP (bond), panuje tutaj dowolność konfiguracji. Sieci i ich nazwy definiujemy na poziomie Zony w sekcji sieci fizyczne (będzie o tym dalej). Wygląda to tak (KVM traffic label):

br3

Nazwa sieci cloudbrN jest jednocześnie nazwą mostka sieciowego (ethernet bridge), nazwy te muszą być tożsame (CloudStack Agent <-> host) i spójne na przestrzeni całego klastra. W pliku konfiguracyjnym agenta sieci są precyzyjnie opisane. Interfejs sieciowy cloudbrN musi być zawsze podniesiony (UP), jeśli przejdzie w stan zatrzymania (Down), przestanie działać cała (np. public) sieć. Liczba zdefiniowanych sieci na poziomie CloudStack nie przekłada się wprost na liczbę interfejsów cloudbrN na poziomie hosta. Na poziomie hosta tworzone są dynamicznie interfejsy vnet zgodnie z potrzebami. Zdefiniowane na poziomie hosta interfejsy nie muszą mieć przypisanych adresów IP ale mogą, sieć management musi mieć przypisany adres IP (z wiadomych względów). Temat stworzenia mostka sieciowego jest prosty, omówiłem go w tym artykule (wystarczy jeden mostek i jedna sieć lub tyle mostków ile potrzebujemy). Tak wyglądają interfejsy sieciowe na poziomie hosta z wykorzystaniem mostków sieciowych przy uruchomionych VM (cloud0 i virbr0 są tworzone automatycznie) :

br2

Tutaj zajmiemy się siecią opartą na OpenvSwitch (konfiguracja sugerowana i zgodna z nie tagowaną siecią). Niestety nie ma pakietów z OpenvSwitch na CentOS 7, musimy je przygotować sami, na początek instalujemy wymagane pakiety (całość procesu zajmuje 2 minuty):

3

W tym momencie mamy uruchomiony poprawnie OpenvSwitch, zanim przeprowadzimy jego konfigurację, należy przygotować pliki interfejsów sieciowych i wgrać je do /etc/sysconfig/network-scripts. Dla każdej karty sieciowej tworzymy plik ifcfg-ens3s0 z zawartością (gdzie ens3s0 to oczywiście przykład):

DEVICE=ens3s0
IPV6INIT=no
IPV6_AUTOCONF=no
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
NM_CONTROLLED=no

Ja stworzyłem interfejs zsumowany Bond typu Aktywny-Pasywny (Backup) dla dwóch kart sieciowych ens3s0 i ens5s0, plik o nazwie ifcfg-bond0:

DEVICE=bond0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBond
OVS_BRIDGE=br0
BOOTPROTO=none
BOND_IFACES=”ens3s0 ens5s0″
OVS_OPTIONS=”bond_mode=active-backup lacp=off other_config:bond-detect-mode=miimon other_config:bond-miimon-interval=100″
HOTPLUG=no

Tworzymy teraz pliki dla interfejsów cloudbrN, zawartość dla wszystkich jest taka sama, plik ifcfg-cloudbr0:

DEVICE=cloudbr0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
IPV6INIT=no
IPV6_AUTOCONF=no
BOOTPROTO=none
HOTPLUG=no

Pliki mostków głównych (br), ifcfg-br0:

DEVICE=br0
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
DEVICETYPE=ovs
TYPE=OVSBridge

Dodatkowo tworzymy interfejs MGMT z przypisanym adresem IP (dotychczasową konfigurację IP usuńcie), plik ifcfg-mgmt0 :

DEVICE=mgmt0
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
IPV6INIT=no
IPV6_AUTOCONF=no
BOOTPROTO=static
IPADDR=172.18.50.193
NETMASK=255.255.255.0
GATEWAY=172.18.50.1
DNS=172.18.60.10

Moja konfiguracja opiera się na czterech kartach i pliki interfejsów wyglądają tak:

br4

Teraz przystępujemy do konfiguracji OpenvSwitch (moja konfiguracja na cztery karty) w konsoli (nie przez ssh):

ovs-vsctl add-br br0
ovs-vsctl add-bond br0 bond0 enp3s0 enp5s0
ovs-vsctl set port br0 trunks=24,26,27,28,29,30,31,50,51,60,61
ovs-vsctl add-br mgmt0 br0 50
ovs-vsctl add-br cloudbr0 br0 0
ovs-vsctl add-br cloudbr1 br0 61
ovs-vsctl add-br br1
ovs-vsctl add-bond br1 bond1 ens2f0 ens2f1
ovs-vsctl set port br1 trunks=24,26,27,28,29,30,31,50,51,60,61
ovs-vsctl add-br mgmt1 br1 60

W ramach wyjaśnień, tworzymy mostek br0 do którego podpinamy bond0, ustawiamy tagi VLAN, tworzymy mostki mgmt0 i cloudbrN. Ważne, że dla cloudbr0 ustawiamy tag 0, czyli natywny (na porcie mamy Trunk i domyślny VLAN 60). Jeśli nie posiadasz sieci z VLAN to taka konfiguracja z cloudbr0 tag 0 zadziała poprawnie dla wszystkich sieci (public, mgmt, guest) dokładnie tak samo jak w przypadku zwykłego mostka sieciowego. Tak jak wspominałem wcześniej, standardowe mostki sieciowe wchodzą w interakcję z OpenvSwitch, dlatego należy je wyłączyć. Tworzymy plik /etc/modprobe.d/blacklist.conf z zawartością: blacklist bridge

Dodatkowo w pliku /etc/sysctl.conf dodajemy dyrektywy:

net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0

Restartujemy hosta, po restarcie wygląda to tak:

br5

Konstrukcja całości jest bardzo czytelna jak widać (mostek cloud0 jest zakładany przez CloudStack Agent). Ważna informacja, dla danego mostka (br) tylko jeden port może mieć ustawiony tag 0 (brak VLAN). Przy poprawnej konfiguracji możemy się swobodnie komunikować z hostem poprzez interfejs mgmt0. W następnej części omówimy dokładnie przestrzeń dyskową (Primary i Secondary Storage) oraz zestawimy klaster MariaDB, skonfigurujemy też KeepaliveD, HAProxy i zainstalujemy CloudStack Management Server.

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

Dodaj komentarz

Required fields are marked *.


.

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

.