Preskočiť na obsah

Vytvorenie testovacieho prostredia OpenStack

Príprava zariadení

Príprava servera MAAS

Pre potreby nasadenia prostredia OpenStack bol pripravený virtualizovaný server, ktorý bude slúžiť ako základ pre systém MAAS (Metal as a Service). Tento server je nakonfigurovaný so 4 virtuálnymi procesormi (vCPU), 4 GB operačnej pamäte a 80 GB pevného disku.

Z pohľadu sieťovej konektivity má server pripojené dve sieťové rozhrania:

  • prvé do VLAN siete KIS-vlan203 (konektivita „do sveta“),
  • druhé do testovacej siete (konektivita „do vnútra“).

Toto riešenie umožňuje oddelenie manažmentu a dátovej prevádzky.

Ako inštalačné médium je pripojený ISO obraz ubuntu-22.04.5-live-server-amd64.iso (Ubuntu Server). Grafická karta nie je explicitne nakonfigurovaná, keďže inštalácia a správa systému prebieha primárne cez konzolu.

Táto konfigurácia poskytuje dostatočný výkon a konektivitu pre účely správy fyzickej a virtuálnej infraštruktúry pomocou MAAS.

Príprava servera JUJU

Pre zabezpečenie orchestrácie a nasadzovania jednotlivých komponentov OpenStack bol pripravený virtualizovaný server, ktorý bude slúžiť ako hostiteľ pre nástroj Juju.

Tento server je vybavený:

  • 4 virtuálnymi procesormi (vCPU)
  • 8 GB operačnej pamäte
  • 60 GB úložného priestoru na pevnom disku

Z hľadiska sieťovej konektivity je zariadenie pripojené do vnútornej testovacej siete, ktorá predstavuje interný testovací segment slúžiaci na komunikáciu medzi jednotlivými komponentmi infraštruktúry.

Tento hardvérový profil je plne postačujúci pre potreby riadenia nasadzovania pomocou Juju a pre integráciu s prostredím MAAS.

Inštalácia potrebných serverov

Základná inštalácia servera MAAS s PostgreSQL 14

V tejto fáze bola vykonaná čistá inštalácia systému MAAS vo verzii 3.5, pričom namiesto predvoleného snap balíka maas-test-db sa použila samostatne inštalovaná databáza PostgreSQL 14.

Tento prístup poskytuje:

  • vyššiu flexibilitu,
  • lepšiu kontrolu nad databázovým backendom,
  • vhodnejšie riešenie pre produkčné prostredia.

Inštalácia PostgreSQL 14 a príprava databázy

Najskôr je potrebné nainštalovať PostgreSQL 14:

sudo apt update
sudo apt install postgresql-14

Následne sa vytvorí databázový používateľ a databáza pre MAAS:

sudo -u postgres psql

V prostredí psql sa vykonajú nasledujúce príkazy:

CREATE USER maas WITH ENCRYPTED PASSWORD '<password>';
CREATE DATABASE maasdb OWNER maas;
\q

Konfigurácia prístupu k databáze

Pre umožnenie autentifikácie sa upraví konfiguračný súbor pg_hba.conf:

sudo nano /etc/postgresql/14/main/pg_hba.conf

Do súboru sa pridajú alebo upravia nasledujúce riadky:

local   all             all                                     md5
host    maasdb          maas            127.0.0.1/32            md5
host    all             maas            127.0.0.1/32            md5

Zároveň sa overí, že PostgreSQL počúva na požadovanom porte. V súbore postgresql.conf:

sudo nano /etc/postgresql/14/main/postgresql.conf

sa nastaví parameter:

listen_addresses = '127.0.0.1'

Po úpravách sa služba PostgreSQL reštartuje:

sudo systemctl restart postgresql

Inštalácia a inicializácia MAAS

Po príprave databázy sa nainštaluje MAAS vo verzii 3.5:

sudo snap install maas --channel=3.5/stable

Inicializácia MAAS systému prebehne príkazom:

sudo maas init region+rack --maas-url http://<IP_adresa_servera>:5240/MAAS --database-uri "postgres://maas:<password>@127.0.0.1:5432/maasdb"

V prípade, že sa objaví chyba connection refused, je potrebné skontrolovať, či databáza skutočne počúva na TCP porte 5432 a či nie je chyba v konfiguračnom súbore pg_hba.conf.

Vytvorenie administrátora MAAS

Po úspešnej inicializácii je potrebné vytvoriť administrátorský účet:

sudo maas createadmin --username student --password <PASSWORD> --email student@kis.fri.uniza.sk

A následne je potrebné vytvoriť a uložiť API kľúč:

ssh-keygen -t rsa
sudo maas apikey --username student > maas-api-key

Dokončenie inštalácie

Po úspešnom spustení a inicializácii MAAS je možné pristúpiť k jeho webovému rozhraniu. To je dostupné na adrese:

http://<IP_adresa_servera>:5240/MAAS

Po otvorení stránky sa zobrazí prihlasovacie rozhranie, kde je potrebné prihlásiť sa pomocou údajov zadaných pri vytváraní administrátora (napr. používateľ student). Následne je nutné prejsť úvodným sprievodcom, v ktorom sa vykonávajú základné kroky – voľba mena regiónu a voľba DNS serverov.

Nasadenie OpenStack prostredia pomocou inicializačných skriptov

Po úspešnom deploymente Juju bundle sme pristúpili k spusteniu pomocných skriptov, ktoré zabezpečili inicializáciu certifikačnej infraštruktúry, Vault servera a kompletné nastavenie OpenStack prostredia. Skripty pochádzajú z repozitára: https://bitbucket.org/kis-fri/maas-juju/src/master/scripts/ a zohrali kľúčovú úlohu pri automatizácii post-deploy krokov.

Skript autoVault.sh

Ako prvý sme spustili skript autoVault.sh, ktorý inicializoval a odomkol nástroj HashiCorp Vault. Skript sa spúšťa s parametrami, ktoré určujú počet vygenerovaných kľúčov a počet potrebných kľúčov na odomknutie (unseal). Napríklad:

./autoVault.sh deploy 10 3

Týmto príkazom sa vygeneruje 10 kľúčov, pričom na unseal Vaultu sú potrebné minimálne 3 kľúče. Vault následne automaticky vytvorí požadované politiky, vygeneruje certifikáty a pripraví prostredie na bezpečné uchovávanie tajomstiev.

Skript initOpenstack.sh

Ako posledný sme spustili skript initOpenstack.sh, ktorý zabezpečil kompletné nastavenie OpenStack prostredia. Skript vytvoril základné projekty, používateľov, role, ako aj počiatky sieťovej topológie (napr. región, služby, endpointy). Vďaka tomuto kroku sme získali plne funkčné OpenStack prostredie pripravené na ďalšiu konfiguráciu.

Zhrnutie

Vďaka správnemu použitiu skriptov autoVault.sh, certCopy.sh a initOpenstack.sh sme vytvorili bezpečné a centralizovane riadené prostredie pre služby OpenStacku. Tieto skripty výrazne uľahčili konfiguráciu a zabezpečili konzistentné nastavenie všetkých požadovaných komponentov. Výsledkom je plne pripravená infraštruktúra pripravená na prevádzku jednotlivých služieb a aplikačných vrstiev OpenStack cloudu.

V druhom kroku úvodného sprievodcu je možné vybrať a stiahnuť ďalšie operačné systémy, ktoré budú používané na bootovanie spravovaných uzlov. Predvolený obraz je Ubuntu 20.04 LTS (architektúra amd64), avšak vzhľadom na požiadavku nasadenia OpenStack verzie Yoga je potrebné doplniť aj obraz Ubuntu 22.04 LTS pre architektúru amd64.

Po označení požadovanej verzie je potrebné výber potvrdiť kliknutím na tlačidlo Update selection, čím sa spustí stiahnutie zvolených inštalačných obrazov do MAAS systému.

Obrazy na bootovanie

Úspešné dokončenie inštalácie

V nasledujúcom kroku úvodného sprievodcu sa vyžaduje importovať verejný SSH kľúč, ktorý bol vygenerovaný počas inštalácie. Ako zdroj kľúča sa zvolí možnosť Upload, pričom verejný kľúč, ktorý získame pomocou príkazu:

cat ~/.ssh/id_rsa.pub

sa vloží do poľa Public key. Tento krok zabezpečuje, že MAAS bude schopný pristupovať k novým uzlom po ich nasadení bez nutnosti interaktívneho zadávania prihlasovacích údajov. Po vložení kľúča je potrebné potvrdiť formulár a pokračovať v konfigurácii.

Konfigurácia sieťových rozhraní pre MAAS

Pre správne nasadenie MAAS servera v rámci OpenStack prostredia je potrebné zabezpečiť pripojenie do dvoch samostatných sietí – jednej externej (napr. VLAN203) určenej na správu a prístup do internetu, a jednej vnútornej (napr. 10.11.0.0/16), využívanej na provisioning, PXE bootovanie a DHCP. Obe siete boli predpripravené ako samostatné virtuálne prepínače v prostredí VMware a priradené k príslušným rozhraniam servera.

Siete:

  • verejná sieť určená pre správu, aktualizácie a externú komunikáciu,
  • vnútorná sieť (napr. 10.11.0.0/16) vyhradená pre PXE bootovanie, DHCP a provisioning spravovaných uzlov.

V prostredí VMware boli vytvorené dve nezávislé virtuálne siete. Na MAAS serveri sa tým pádom očakávajú dve sieťové rozhrania – jedno pre každú sieť.

Počas inštalácie operačného systému sa odporúča nakonfigurovať tieto rozhrania staticky. Konfigurácia sa vykonáva pomocou nástroja Netplan, úpravou súboru:

sudo nano /etc/netplan/50-cloud-init.yaml

Príklad konfigurácie pre MAAS server s rozhraniami ens160 (verejná sieť) a ens192 (vnútorná sieť) môže vyzerať nasledovne:

network:
  version: 2
  ethernets:
    ens160:
      addresses:
        - <IP_adresa_MAAS>/25
      nameservers:
        addresses: [1.1.1.1]
      routes:
        - to: default
          via: 158.193.152.129
    ens192:
      addresses:
        - 10.11.0.1/16
      nameservers:
        addresses: []

Po uložení konfigurácie sa zmeny aplikujú príkazom:

sudo netplan apply

Takto nastavené rozhrania zabezpečujú, že MAAS server má prístup do vonkajšej siete na správu systému a zároveň vidí vnútornú podsieť, ktorú bude používať pre alokáciu adries a sieťovú automatizáciu. Táto konfigurácia je základom pre správne fungovanie PXE bootovania a dynamickej správy uzlov prostredníctvom MAAS.

Základné nastavenie DHCP v MAAS

Jednou z kľúčových funkcionalít systému MAAS po jeho inštalácii je integrovaný DHCP server. Ten je zodpovedný za dynamickú alokáciu IP adries pri PXE bootovaní a nasadzovaní systémov. Aby bolo možné túto službu využívať, musí sa po inicializácii správne nakonfigurovať prostredníctvom MAAS CLI.

Najskôr je potrebné sa autentifikovať voči MAAS inštancii pomocou používateľského mena a API kľúča:

maas login student http://<IP_adresa_servera>:5240/MAAS - < maas-api-key

V navrhnutej architektúre pre OpenStack je vnútorná sieť 10.11.0.0/16 použitá pre DHCP, PXE a provisioning. Rozsah adries je rozdelený na:

  • statický rozsah: 10.11.0.1 – 10.11.0.255 (rezervované pre infraštruktúrne komponenty),
  • dynamický rozsah: 10.11.2.0 – 10.11.255.254 (používaný MAAS-om pre DHCP).

Tieto rozsahy sa nastavujú nasledovne:

maas student ipranges create type=dynamic start_ip=10.11.2.0 end_ip=10.11.255.254
maas student ipranges create type=reserved start_ip=10.11.0.1 end_ip=10.11.0.255 comment='static IPs'

Pre správne fungovanie DHCP je potrebné, aby VLAN, v ktorej sa tieto rozsahy nachádzajú, mala pridelený priestor (space) a bola aktívna v rámci správneho fabricu. Najskôr sa vytvorí priestor pre správu OpenStack siete:

maas student spaces create name=openstack-mgmt

Následne sa priradí tento priestor (space) k VLAN (napr. VLAN ID 2 v rámci fabricu 1):

maas student vlan update 1 untagged space=openstack-mgmt

Nakoniec sa aktivuje DHCP služba na danej VLAN s uvedením názvu hlavného rack kontroléra (získaného napr. cez maas student rack-controllers read):

maas student vlan update 1 untagged dhcp_on=true primary_rack=<rack_controller_system_id>

Týmto krokom sa aktivuje DHCP pre sieť 10.11.0.0/16, čím MAAS získa možnosť dynamicky prideľovať IP adresy pre spravované uzly počas PXE bootovania a nasadzovania operačných systémov.

Sieťové úpravy konfigurácie

Aby bolo možné zabezpečiť správne smerovanie paketov medzi podsieťami v prostredí OpenStack, je potrebné na hlavnom MAAS serveri povoliť IP forwarding. Tento mechanizmus umožňuje serveru presmerovávať sieťovú prevádzku medzi jednotlivými sieťovými rozhraniami, čo je nevyhnutné napríklad pre komunikáciu medzi vnútornou a verejnou sieťou.

Trvalé povolenie IP forwardingu sa vykonáva úpravou súboru /etc/sysctl.conf:

sudo nano /etc/sysctl.conf

V tomto súbore je potrebné odkomentovať (alebo pridať) riadok:

Úprava súboru sysctl.conf

Následne sa zmeny aplikujú príkazom:

sudo sysctl -p

Na zabezpečenie správneho fungovania NAT a routovania upravíme pravidlá nftables v konfiguračnom súbore:

sudo nano /etc/nftables.conf

V tomto súbore nastavíme potrebné pravidlá preroutingu a postroutingu (napr. masquerading pre konkrétne rozhranie).

Úprava konfiguračného súboru nftables

Po úprave konfigurácie je potrebné pravidlá načítať – ak služba nftables ešte nebeží, spustíme ju a zároveň aktivujeme jej automatické spúšťanie po štarte systému:

sudo systemctl start nftables
sudo systemctl enable nftables

Ak služba už beží, stačí použiť:

sudo systemctl restart nftables

Správnosť aplikovaných pravidiel následne overíme príkazom, ktorý vypíše aktuálne aktívne pravidlá firewallu:

sudo nft list ruleset

Úprava podsiete 10.11.0.0/16

Na správne smerovanie sieťovej prevádzky a zabezpečenie funkčného DNS rozlíšenia je potrebné upraviť konfiguráciu podsiete priamo cez webové rozhranie MAAS. V časti Subnets otvoríme konkrétnu podsieť 10.11.0.0/16 a kliknutím na Edit zmeníme nasledujúce kľúčové parametre:

  • Gateway IP nastavíme na hodnotu 10.11.0.1 (server MAAS), čím sa definuje výstupný bod siete pre všetky zariadenia priradené do tejto podsiete.
  • DNS servery nastavíme na 1.1.1.1 a 8.8.8.8 (môžu byť aj iné, avšak je potrebné nejaké definovať), čo zabezpečuje redundanciu a vysokú dostupnosť DNS rozlíšenia pre všetkých klientov v danej sieti.

Tieto zmeny sú kriticky dôležité pre funkčnosť bootstrapovanej Juju inštancie, ktorá potrebuje vedieť, kam smerovať verejnú prevádzku a ako riešiť doménové mená. Po uložení zmien MAAS automaticky aktualizuje svoje DHCP ponukya následne tieto nové hodnoty distribuuje všetkým zariadeniam v spravovanom rozsahu, ktoré prešli boot-om až po tejto zmene.

Nastavenie predvolenej brány

Základná inštalácia servera JUJU

Po úspešnej konfigurácii siete, DHCP rozsahov a priradení priestorov v systéme MAAS môžeme pristúpiť k spusteniu virtuálneho servera, ktorý bude slúžiť ako kontrolný uzol pre nástroj Juju. Tento server je potrebné pripojiť do internej siete (resp. 10.11.0.0/16), ktorú sme predtým nakonfigurovali v MAAS.

Po zapnutí servera dôjde k PXE bootu – ak je sieť správne nastavená a MAAS má aktívny DHCP a TFTP server, zariadenie automaticky načíta inštalačný obraz, spustí sa provisioning a následne sa systém automaticky nainštaluje podľa šablóny nastavených nasadení (deployment) v MAAS. Po úspešnej inštalácii sa server reštartuje a následne vypne.

V tomto okamihu je nový server viditeľný vo webovom rozhraní MAAS ako nový (status: New) a môže byť priradený k ďalším nasadeniam vrátane Juju controller-a. Tento krok predstavuje bod, kedy môžeme začať s nasadzovaním samotnej OpenStack infraštruktúry.

JUJU server viditeľný v MAAS

Po úspešnej inštalácii servera a jeho zobrazení v MAAS je potrebné vykonať ešte niekoľko úprav pred jeho použitím ako Juju controller.

Označenie servera ako Juju uzol

Vo webovom rozhraní MAAS prejdeme na konkrétny server, zmeníme meno servera (napr. juju) a v časti Configuration pridáme nový Tag s názvom juju. Tento tag je neskôr využívaný nástrojom Juju pri automatizovanom výbere vhodného uzla pre kontrolér.

Pridanie označenia juju na server

Nastavenie napájacieho manažmentu

Po pridaní tagu je nutné nakonfigurovať spôsob zapínania servera v sekcii Power Configuration. Podľa použitej infraštruktúry (napr. IPMI, Virsh, manual) vyberieme príslušný typ a vyplníme potrebné údaje ako adresa BMC, prihlasovacie údaje alebo URI. Táto konfigurácia je nevyhnutná na to, aby MAAS mohol server automaticky zapínať a vypínať pri nasadení.

Poznámka: Pole VMware API protocol je kľúčové – ak nie je správne vyplnené (napr. chýba https+unverified), MAAS nebude schopný server zapnúť pri nasadzovaní.

Konfigurácia napájania JUJU servera

Nastavenie statickej IP adresy pre Juju kontrolér

Po úspešnom nasadení a pridaní tagu juju je potrebné upraviť sieťové rozhranie servera tak, aby namiesto dynamickej adresy používalo statickú IP adresu. Tým zabezpečíme, že Juju kontrolér bude mať vždy rovnakú adresu, čo je dôležité pre stabilitu riadenia cloudu.

  1. V MAAS web rozhraní prejdeme na záložku Network daného uzla.
  2. V zozname sieťových rozhraní klikneme v stĺpci Action na šípku a vyberieme možnosť Edit Physical.

Úprava statickej IP adresy JUJU

  1. V otvorenom formulári zmeníme spôsob priradenia IP adresy z Auto assign na Static.
  2. Do poľa s IP adresou zadáme hodnotu 10.11.0.2 (adresa musí spadať do nášho statického rozsahu, napr. 10.11.0.1–10.11.0.255). Zmeny uložíme kliknutím na Save.

Nastavenie statickej IP adresy JUJU

Týmto krokom sme zabezpečili, že Juju kontrolér bude pri každom zapnutí používať stálu IP adresu z definovaného statického rozsahu.

Uvedenie stroja do stavu „Ready“

Po priradení statickej adresy a nastavení napájania zostáva posledný krok – skomisionovať (commission) stroj, aby bol pripravený na ďalšie použitie v MAAS.

  1. V MAAS web rozhraní vyberieme stroj, ktorý je v stave New.
  2. Klikneme na možnosť Commission.

  3. V dialógu je odporúčané zaškrtnúť:

  4. Allow SSH access and prevent machine powering off – umožní udržať stroj zapnutý po skomisionovaní.

  5. Retain network configuration – ponechá ručne nastavenú statickú IP adresu.
  6. Voliteľne môžeme ponechať predvolené commissioning a testing skripty. Napr. smartctl-validate overí stav disku.
  7. Potvrďte kliknutím na Start commissioning for machine.

JUJU commission

Po dokončení procesu sa stroj presunie do stavu Ready, čím je pripravený na nasadenie ako Juju kontrolér alebo iný typ uzla. Tento krok môže nejaký čas trvať.

Inštalácia servera JUJU

Po úspešnej príprave infraštruktúry v MAAS je ďalším krokom nainštalovať Juju – nástroj určený na orchestráciu a správu služieb v cloudových prostrediach, ako je napr. OpenStack. Juju umožňuje jednoducho definovať, nasadiť a spravovať celé aplikačné architektúry pomocou tzv. charmov.

Inštalácia sa vykonáva priamo na MAAS serveri prostredníctvom nástroja snap, ktorý zabezpečí automatické aktualizácie a izolované prostredie:

sudo snap install juju --classic

Po nainštalovaní budeme môcť inicializovať Juju kontrolér, ktorý využije MAAS ako poskytovateľa strojov pre nasadzovanie služieb. V ďalších krokoch sa zameriame na jeho inicializáciu a registráciu k MAAS.

Aby mohol Juju komunikovať s prostredím MAAS a využívať ho ako zdroj strojov, je potrebné definovať jeho pripojenie vo forme vlastného cloud profilu. Tento profil popisuje typ cloudu, autentifikačný mechanizmus a API koncový bod MAAS servera.

Najskôr vytvoríme konfiguračný súbor v YAML formáte, v ktorom zadáme potrebné parametre pre pripojenie:

nano maas-cloud.yaml

Obsah súboru bude nasledovný:

clouds:
  maas-one:
    type: maas
    auth-types: [oauth1]
    endpoint: http://<IP_adresa_servera>:5240/MAAS

Po uložení konfiguračného súboru zaregistrujeme nový cloud do Juju pomocou príkazu:

juju add-cloud --client -f maas-cloud.yaml maas-one

Takto pridaný cloud maas-one bude následne dostupný ako cieľové prostredie pre nasadzovanie kontroléra a ďalších služieb pomocou Juju.

Po pridaní MAAS ako cloudového prostredia je nevyhnutné zabezpečiť autentifikáciu, aby mohol Juju pristupovať k jeho API a spravovať fyzické alebo virtuálne stroje. Na tento účel sa používa tzv. OAuth kľúč, ktorý bol vygenerovaný pri nastavovaní MAAS účtu.

Poverenia sa zadávajú pomocou konfiguračného súboru vo formáte YAML, napríklad:

nano maas-creds.yaml

Obsah súboru vyzerá nasledovne:

credentials:
  maas-one:
    anyuser:
      auth-type: oauth1
      maas-oauth: <API_kluc>

Poznámka: Reťazec v poli maas-oauth predstavuje váš osobný API kľúč z MAAS rozhrania. Tento kľúč je možné získať priamo cez MAAS webové GUI alebo z uloženého súboru z predchádzajúcej inštalácie.

Po vytvorení súboru poverení ich zaregistrujeme v Juju:

juju add-credential --client -f maas-creds.yaml maas-one

Po úspešnom pridaní cloudového profilu a poverení môžeme pristúpiť k samotnej inštalácii Juju kontroléra. V tomto kroku sa vyberie stroj z prostredia MAAS, ktorý má priradený tag juju (ten bol nakonfigurovaný v predchádzajúcich krokoch), a na ňom sa automaticky vykoná inštalácia kontroléra.

Príkaz na spustenie inicializácie kontroléra vyzerá nasledovne:

juju bootstrap --bootstrap-series=focal --constraints tags=juju maas-one maas-controller

Po úspešnom vykonaní tohto príkazu bude kontrolér Juju pripravený na nasadzovanie a orchestráciu ďalších služieb v rámci MAAS prostredia.

Poznámka: V prípade záujmu o overenie nastavení na serveri juju, použite príkaz:

ssh ubuntu@10.11.0.2 -i ~/.local/share/juju/ssh/juju_id_rsa

Po úspešnej inštalácii by sme mali vidieť nasledovné:

Úspešná finalizácia servera JUJU

Základná inštalácia/príprava výpočtových uzlov

Pred samotným nasadzovaním služieb OpenStacku pomocou nástroja Juju je nevyhnutné pripraviť výpočtové uzly (tzv. compute nodes), ktoré budú zabezpečovať prevádzku virtuálnych strojov. Tieto uzly musia byť riadené systémom MAAS a musia byť uvedené do stavu Ready.

Registrácia výpočtových uzlov do MAAS

Fyzické alebo virtuálne zariadenia určené ako compute nody je potrebné pripojiť do siete spravovanej MAAS-om (zvyčajne cez PXE boot). Po reštarte uzla sa zariadenie zaregistruje v MAAS ako nový stroj v stave New.

Poznámka: Sieť, cez ktorú sa uzol pripája, musí byť nakonfigurovaná v MAAS ako PXE boot-enabled VLAN, s povoleným DHCP a TFTP serverom.

Commissioning (zavedenie zariadenia)

Zariadenie v stave New je potrebné najskôr skomisionovať (Commission), aby MAAS zistil jeho hardvérové parametre a overil pripojenie.

Postup v MAAS GUI:

  • Prejdi do záložky Machines
  • Vyber uzol so stavom New
  • Klikni na Take action → Commission
  • V dialógovom okne ponechaj predvolené možnosti (komisia cez MAAS image)
  • Spusti proces kliknutím na Start Commissioning

Po úspešnom dokončení sa stav zariadenia zmení na Ready.

Overenie stavu

Po úspešnej komisií sa uistíme, že uzol:

  • je v stave Ready
  • má priradený hostname (napr. compute-1, compute-2)
  • má viditeľné základné komponenty: CPU, RAM, disky, sieťové karty
  • je pripravený na pridelenie pre Juju alebo iné služby

V prípade zlyhania commissioning-u:

  • skontroluj logy cez MAAS GUI → záložka Logs
  • uisti sa, že zariadenie je pripojené do správnej VLAN s povoleným PXE a má prístup k MAAS serveru

Zhrnutie

Po správnej registrácii a komisií musí byť každý výpočtový uzol pripravený v stave Ready, aby mohol byť nasadený ako nova-compute alebo iná OpenStack služba pomocou nástroja Juju.

Nastavenia servera

Po úspešnom bootstrapovaní Juju kontroléra je nevyhnutné pripraviť kompletnú sieťovú infraštruktúru v prostredí MAAS. Tieto siete budú neskôr využívané jednotlivými službami OpenStack-u ako transportné, dátové, manažmentové alebo verejné. Pre správnu funkcionalitu celého systému je potrebné, aby každá sieť bola v MAAS definovaná, správne priradená ku konkrétnemu VLAN ID, podsieti, a označená patričným space-om pre ďalšiu integráciu v Juju.

Na nasledujúcom obrázku je znázornená cieľová konfigurácia piatich sietí v rámci MAAS GUI:

Cieľová konfigurácia sietí

Postup konfigurácie:

  1. Prístup do MAAS GUI:

  2. Otvoríme webové rozhranie MAAS a prejdeme do sekcie Subnets (alebo Networking → Subnets).

  3. Identifikujeme každú podsieť podľa rozsahu adries.

  4. Nastavenie VLAN a fabric:

  5. Pre každú sieť vytvoríme alebo vyberieme zodpovedajúci Fabric (napr. fabric-0, fabric-1).

  6. Pre každú podsieť zadefinujeme správne VLAN ID a jeho názov – napr. 153 (brEX) alebo 500 (brVXLAN).

  7. Priradenie „Space“:

  8. Pre správnu integráciu s Juju sa každá sieť priraďuje do logického priestoru (Space), ktorý sa neskôr využíva pri nasadzovaní OpenStack služieb.

    • Manažment: openstack-mgmt
    • Dátová sieť: openstack-vxlan
    • Externé siete môžu zostať bez space, ak ich používanie nie je priame v deploymente (napr. plávajúce IP).

Je potrebné sa uistiť, že každý fyzický alebo virtuálny stroj v MAAS má pripojené správne VLAN podľa svojej role – cez Devices → Interfaces → Edit Physical → VLAN assignment.

Nasadenie OpenStack prostredia pomocou Juju bundle

Po úspešnej príprave infraštruktúry prostredníctvom MAAS a inicializácii Juju kontroléra je možné pristúpiť k nasadeniu samotného OpenStack prostredia. Na tento účel sa využíva tzv. Juju bundle – konfiguračný súbor, ktorý popisuje kompletnú architektúru OpenStack-u, vrátane požiadaviek na jednotlivé služby, ich závislostí a alokácie na konkrétne uzly.

Príprava prostredia

Pred samotným nasadením je potrebné overiť, že všetky komponenty sú pripravené:

  • Juju kontrolér je aktívny a prihlásený ku cloudu maas-one.
  • Všetky potrebné compute nody sa nachádzajú v stave Ready v MAAS.
  • MAAS má správne nastavené siete, DNS, gateway a DHCP.
  • Bundle súbor z repozitára je pripravený.

Použitý bundle je dostupný v oficiálnom repozitári KIS FRI: https://bitbucket.org/kis-fri/maas-juju/src/master/bundles/

V našom prípade sa jedná o súbor bundleTest2node_20240718.bundle, ktorý je prispôsobený pre nasadenie základnej OpenStack topológie na dvoch výpočtových uzloch.

Spustenie nasadzovacieho procesu

V nasledujúcom kroku sa spustí samotné nasadzovanie OpenStack služieb. To sa vykoná prostredníctvom jedného príkazu:

juju deploy ./bundleTest2node_20240718.bundle

Tento príkaz inicializuje nasadzovanie všetkých služieb popísaných v bundle, medzi ktoré patria napríklad:

  • keystone (autentifikačná služba),
  • glance (systém pre správu obrazov),
  • nova-cloud-controller a nova-compute (správa virtuálnych strojov),
  • neutron-gateway, neutron-api, neutron-openvswitch (sieťová infraštruktúra),
  • a ďalšie komponenty potrebné pre plnohodnotný OpenStack stack.

Bundle zároveň obsahuje definície tzv. constraints a placement rules, ktoré zabezpečujú, že jednotlivé služby budú nasadené na vhodné nody podľa ich označení v MAAS (napr. tag juju, compute a pod.).

Monitorovanie priebehu nasadzovania

Nasadzovanie môže trvať niekoľko minút až desiatok minút v závislosti od výkonnosti infraštruktúry. Počas nasadzovacieho procesu sa odporúča monitorovať stav pomocou:

watch juju status

Tento príkaz zabezpečí priebežný výpis stavu všetkých služieb a ich alokáciu na jednotlivé uzly. Stavy ako waiting, executing, blocked alebo active indikujú fázy nasadzovacieho procesu.

Pre základnú orientáciu možno použiť aj:

juju status --color

V prípade zlyhania niektorej služby je možné získať detailný výpis pomocou:

juju debug-log

Výsledok

Po úspešnom dokončení nasadzovacieho procesu budú všetky komponenty OpenStack-u aktívne a pripravené na ďalšiu konfiguráciu (pridanie sieťových bridge-ov, definícia projektov, upload image-ov a pod.). Všetky jednotky budú v stave active, čo signalizuje úspešné nasadenie.

Nasadenie OpenStack prostredia pomocou inicializačných skriptov

Po úspešnom deploymente Juju bundle sme pristúpili k spusteniu pomocných skriptov, ktoré zabezpečili inicializáciu certifikačnej infraštruktúry, Vault servera a kompletné nastavenie OpenStack prostredia. Skripty pochádzajú z repozitára: https://bitbucket.org/kis-fri/maas-juju/src/master/scripts/ a zohrali kľúčovú úlohu pri automatizácii post-deploy krokov.

Skript autoVault.sh

Ako prvý sme spustili skript autoVault.sh, ktorý inicializoval a odomkol nástroj HashiCorp Vault. Skript sa spúšťa s parametrami, ktoré určujú počet vygenerovaných kľúčov a počet potrebných kľúčov na odomknutie (unseal). Napríklad:

./autoVault.sh deploy 10 3

Týmto príkazom sa vygeneruje 10 kľúčov, pričom na unseal Vaultu sú potrebné minimálne 3 kľúče. Vault následne automaticky vytvorí požadované politiky, vygeneruje certifikáty a pripraví prostredie na bezpečné uchovávanie tajomstiev.

Skript initOpenstack.sh

Ako posledný sme spustili skript initOpenstack.sh, ktorý zabezpečil kompletné nastavenie OpenStack prostredia. Skript vytvoril základné projekty, používateľov, role, ako aj počiatky sieťovej topológie (napr. región, služby, endpointy). Vďaka tomuto kroku sme získali plne funkčné OpenStack prostredie pripravené na ďalšiu konfiguráciu.

Zhrnutie

Vďaka správnemu použitiu skriptov autoVault.sh, certCopy.sh a initOpenstack.sh sme vytvorili bezpečné a centralizovane riadené prostredie pre služby OpenStacku. Tieto skripty výrazne uľahčili konfiguráciu a zabezpečili konzistentné nastavenie všetkých požadovaných komponentov. Výsledkom je plne pripravená infraštruktúra pripravená na prevádzku jednotlivých služieb a aplikačných vrstiev OpenStack cloudu.

Nasadenie OpenStack Octavia (Load Balancer)

Táto časť opisuje nastavenie OpenStack Octavia do testovacieho prostredia spravovaného pomocou MaaS a Juju.

1. Nasadenie MySQL routerov pre Octavia a Barbican

Tieto routre poskytujú databázové prepojenie medzi jednotlivými službami a MySQL InnoDB Cluster-om.

juju deploy mysql-router --channel 8.0/stable barbican-mysql-router --to lxd:0
juju deploy mysql-router --channel 8.0/stable octavia-mysql-router --to lxd:0

2. Nasadenie Barbican s Vault backend-om

juju deploy barbican --channel 2023.2/stable --config openstack-origin=cloud:jammy-bobcat --to lxd:1
juju deploy barbican-vault --to lxd:1

3. Nasadenie Octavia

Prvotné nasadenie bez špecifickej väzby na OVN.

juju deploy octavia --channel 2023.2/stable --config openstack-origin=cloud:jammy-bobcat --to lxd:0
  1. Nasadenie Octavia Dashboard

Nutné pre integráciu Octavia do Horizon.

juju deploy octavia-dashboard --channel 2023.2/stable --to lxd:1

5. Nasadenie komponentov pre Amphora image

juju deploy glance-simplestreams-sync --to lxd:0
juju deploy octavia-diskimage-retrofit --to lxd:0
  1. Vytvorenie základných Juju integrácií medzi službami

Po nasadení služieb je potrebné vytvoriť vzťahy medzi Octavia, Barbican a ďalšími OpenStack službami.

# Databázové vzťahy
juju integrate barbican-mysql-router:db-router mysql-innodb-cluster:db-router
juju integrate barbican-mysql-router:shared-db barbican:shared-db
juju integrate octavia-mysql-router:db-router mysql-innodb-cluster:db-router
juju integrate octavia-mysql-router:shared-db octavia:shared-db

# RabbitMQ
juju integrate rabbitmq-server:amqp barbican:amqp
juju integrate rabbitmq-server:amqp octavia:amqp

# Keystone
juju integrate keystone:identity-service barbican:identity-service
juju integrate keystone:identity-service octavia:identity-service
juju integrate keystone:identity-service glance-simplestreams-sync:identity-service
juju integrate keystone:identity-credentials octavia-diskimage-retrofit:identity-credentials

# Vault a Barbican
juju integrate vault:certificates barbican:certificates
juju integrate vault:certificates octavia:certificates
juju integrate vault:certificates glance-simplestreams-sync:certificates
juju integrate barbican-vault:secrets-storage vault:secrets
juju integrate barbican:secrets barbican-vault:secrets

# Neutron a Octavia
juju integrate neutron-api:neutron-load-balancer octavia:neutron-api

# Horizon
juju integrate openstack-dashboard:dashboard-plugin octavia-dashboard:dashboard

# Octavia diskimage retrofit
juju integrate glance-simplestreams-sync:juju-info octavia-diskimage-retrofit:juju-info
  1. Povolenie port security
juju config neutron-api enable-ml2-port-security=True
  1. Aktualizácia pomocných charm-ov
juju refresh barbican-vault --channel 2023.2/stable
juju refresh octavia-diskimage-retrofit --channel 2023.2/stable
juju refresh glance-simplestreams-sync --channel 2023.2/stable
  1. Úprava nasadenia Octavia pre OVN

V tejto fáze bola Octavia deklarovaná s dodatočným binding-om pre ovsdb-subordinate.

juju deploy ch:octavia --channel 2023.2/stable \
  --config openstack-origin=cloud:jammy-bobcat \
  --to lxd:0 \
  --bind "openstack-mgmt ovsdb-subordinate=openstack-vxlan"
  1. Úprava nasadenia MySQL router-a pre Octavia

Deklarovaný s prefixom ch:.

juju deploy ch:mysql-router --channel 8.0/stable octavia-mysql-router

# Ďalej boli znova vykonané príslušné integrácie
juju integrate octavia-mysql-router:db-router mysql-innodb-cluster:db-router
juju integrate octavia-mysql-router:shared-db octavia:shared-db

juju integrate rabbitmq-server:amqp octavia:amqp
juju integrate keystone:identity-service octavia:identity-service
juju integrate neutron-api:neutron-load-balancer octavia:neutron-api
juju integrate vault:certificates octavia:certificates
  1. Nasadenie OVN chassis pre Octavia
juju deploy ch:ovn-chassis --channel 23.09/stable octavia-ovn-chassis \
  --bind "ovsdb=openstack-mgmt data=openstack-vxlan"

# Následné vytvorenie vzťahov s Octavia, OVN Central a Vault
juju integrate octavia:ovsdb-subordinate octavia-ovn-chassis:ovsdb-subordinate
juju integrate octavia-ovn-chassis:ovsdb ovn-central:ovsdb
juju integrate octavia-ovn-chassis:certificates vault:certificates

# Opätovne nastavené port security
juju config neutron-api enable-ml2-port-security=True

Po týchto krokoch bol stav služby Octavia vo výpise juju status nasledovný:

Awaiting end-user execution of `configure-resources` action to create required resources, Missing required certificat...
  1. Overenie Amphora provider

Overenie konfigurácie služby Octavia. Výstup true potvrdzuje, že Amphora provider je v Octavia už povolený

test@maas-test:~$ juju config octavia enable-amphora
true
  1. Generovanie certifikátov

Pre autentifikáciu a bezpečnosť komunikácie medzi Amphora-mi a Octavia control plane, Octavia využíva klientské certifikáty.

Nasledovný blok kódu (uvedený aj v oficiálnom návode - dokumentácií OpenStack pre nasadenie Octavia) zabezpečuje vytvorenie certifikátov a kľúčov, pričom je potrebné si jednotlivé parametre upraviť.

mkdir -p ~/octavia-certs/demoCA/newcerts
cd ~/octavia-certs
touch demoCA/index.txt demoCA/index.txt.attr

# 1) Issuing CA (Octavia ho používa na vydávanie amphora certov)
openssl genpkey -algorithm RSA -aes256 -pass pass:CHANGE_ME -out issuing_ca_key.pem
openssl req -x509 -passin pass:CHANGE_ME -new -nodes -key issuing_ca_key.pem \
  -config /etc/ssl/openssl.cnf \
  -subj "/C=SK/ST=BA/O=KIS/CN=octavia-issuing-ca" \
  -days 3650 \
  -out issuing_ca.pem


# 2) Controller CA + controller cert
openssl genpkey -algorithm RSA -aes256 -pass pass:CHANGE_ME -out controller_ca_key.pem
openssl req -x509 -passin pass:CHANGE_ME -new -nodes -key controller_ca_key.pem \
  -config /etc/ssl/openssl.cnf \
  -subj "/C=SK/ST=BA/O=KIS/CN=octavia-controller-ca" \
  -days 3650 \
  -out controller_ca.pem

openssl req -newkey rsa:2048 -nodes -keyout controller_key.pem \
  -subj "/C=SK/ST=BA/O=KIS/CN=octavia-controller" \
  -out controller.csr

openssl ca -passin pass:CHANGE_ME -config /etc/ssl/openssl.cnf \
  -cert controller_ca.pem -keyfile controller_ca_key.pem \
  -create_serial -batch \
  -in controller.csr -days 3650 -out controller_cert.pem

cat controller_cert.pem controller_key.pem > controller_cert_bundle.pem
  1. Konfigurácia Octavia

Vytvorené certifikáty a kľúče boli "odovzdané" charm-u:

juju config octavia \
    lb-mgmt-issuing-cacert="$(base64 ~/octavia-certs/issuing_ca.pem)" \
    lb-mgmt-issuing-ca-private-key="$(base64 ~/octavia-certs/issuing_ca_key.pem)" \
    lb-mgmt-issuing-ca-key-passphrase=CHANGE_ME \
    lb-mgmt-controller-cacert="$(base64 ~/octavia-certs/controller_ca.pem)" \
    lb-mgmt-controller-cert="$(base64 ~/octavia-certs/controller_cert_bundle.pem)"
  1. Konfigurácia Glance
juju config glance-simplestreams-sync use_swift=false
juju config glance-simplestreams-sync run=true
juju config octavia-diskimage-retrofit amp-image-tag=octavia-amphora
  1. Inicializácia zdrojov Octavia

Vytvorí požadované OpenStack zdroje potrebné na dokončenie konfigurácie Octavia.

juju run --wait=30m octavia/leader configure-resources
  1. Výsledný stav
barbican                    active
barbican-mysql-router       active
barbican-vault              active
glance-simplestreams-sync   active
octavia                     active
octavia-dashboard           active
octavia-diskimage-retrofit  active
octavia-mysql-router        active
octavia-ovn-chassis         active

Troubleshoot

Chyba pri nasadzovaní bundle: "Base does not match"

Pri spúšťaní inštalácie OpenStack bundle cez Juju na MAAS sa môže vyskytnúť chyba spojená s nekompatibilitou verzií operačného systému (OS base).

Konkrétne ide o chybu:

ERROR cannot deploy bundle: cannot add unit for application "nova-compute": acquiring machine to host unit "nova-compute/0": cannot assign unit "nova-compute/0" to machine 0: base does not match: unit has "ubuntu@22.04", machine has "ubuntu@24.04"

Pomocou príkazu: juju status --format=yaml, je vidieť, že v sekcií machines majú stroje priradený channel: channel: "24.04".

Problém je možné vyriešiť "vynútením" správnej verzie ubuntu pre celý model. To je možné zabezpečiť po vytvorení modelu zadaním príkazu juju model-config default-base=ubuntu@22.04.

Po opätovnom zadaní príkazu juju status --format=yaml, by pri strojoch mal byť priradený channel: channel: "22.04".

Následne sa môže znova nasadiť bundle, ktorý by už mal úspešne prejsť.

OVN-chassis padá s hook failed: "ovsdb-relation-changed" kvôli chýbajúcim VLAN sub-rozhraniam

Jadro problému: ovn-chassis má v konfigurácii namapované provider mosty (brEX, brEX2) na VLAN rozhrania bond.153/bond.154, ktoré v systéme neexistujú. Charm sa ich snaží pridať na bridge, ale narazí na neplatný interfejs a spadne na hooku ovsdb-relation-changed.

Dôsledky v praxi: compute nody sa síce javia „živé“, ale provider konektivita je nefunkčná. Inštancie na externých/VLAN sieťach nedostanú uplink, floating IP nefungujú, North–South prevádzka stojí, a môže sa javiť, že „OpenStack je OK“, hoci traffic z/na VM sa nedostane von. Navyše sa zacyklí provisioning ovn-chassis (opakované pády hooku), takže ďalšie zmeny v sieti sa nemusia správne aplikovať. Inými slovami: bez existujúcich VLAN sub-rozhraní neprepojíš brEX/brEX2 na fyziku a celý provider layer je „hluchý“.

Riešenie

Poznámka: Všetky kroky sú vykonávané na zariadení, kde beží MAAS.

Krok 1

Vytvor VLAN iface bond.153 a bond.154 na oboch výpočtových uzloch (compute nodes)

juju ssh nova-compute/0 -- sudo ip link add link bond name bond.153 type vlan id 153
juju ssh nova-compute/0 -- sudo ip link add link bond name bond.154 type vlan id 154
juju ssh nova-compute/0 -- sudo ip link set bond up && sudo ip link set bond.153 up && sudo ip link set bond.154 up

juju ssh nova-compute/1 -- sudo ip link add link bond name bond.153 type vlan id 153
juju ssh nova-compute/1 -- sudo ip link add link bond name bond.154 type vlan id 154
juju ssh nova-compute/1 -- sudo ip link set bond up && sudo ip link set bond.153 up && sudo ip link set bond.154 up

Overenie: 

juju ssh nova-compute/0 -- ip -d link show bond.153

Ak je vypísaný detail rozhrania, overenie je validné.

Krok 2

Nastav ovn-chassis mappingy explicitne

juju config ovn-chassis \
  ovn-bridge-mappings="physnet1:brEX physnet2:brEX2" \
  bridge-interface-mappings="brEX:bond.153 brEX2:bond.154"

Overenie:

juju ssh nova-compute/0 -- sudo ovs-vsctl get Open_vSwitch . external-ids:ovn-bridge-mappings

Je potrebné vidieť reťazec s physnet1:brEX,physnet2:brEX2.

Krok 3

Spusti zlyhaný hook znova:

juju resolved ovn-chassis/0 --retry
juju resolved ovn-chassis/1 --retry

Ak príkaz zlyhá, je potrebné ho pustiť bez parametra --retry (rôzne verzie)

Overenie:

juju status ovn-chassis --format=short

Očakávame, že inštancie ovn-chassis budú v stave active. Pozor, tento krok môže nejaký čas trvať.

Chybová hláška pri pokuse o vytvorenie stacku

Pri vytváraní stack-ov v Horizon GUI cez +Launch Stack sa zobrazí hláška: Error: Unable to retreive stack list. Details ERROR: Internal Error

OpenStack Heat potrebuje špeciálnu doménu a admin používateľa na správu stackov. Ak sa toto pri deploymente nevykonalo (čo sa pri manuálnych bundle občas stane), Heat vráti Internal Error.

Prvým pokusom je vynútenie vytvorenia domény príkazom: juju run heat/0 domain-setup. Je pravdepodobné, že tento task neprejde a vo výpise bude možné vidieť tento error:

Attempting to parse version from URL.
SSL exception connecting to https://10.11.1.48:35357/v3/auth/tokens: HTTPSConnectionPool(host='10.11.1.48', port=35357): Max retries exceeded with url: /v3/auth/tokens (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)')))
Failed to discover available identity versions when contacting https://10.11.1.48:35357/v3.
Chyba SSL: CERTIFICATE_VERIFY_FAILED znamená, že Heat sa pokúša komunikovať s Keystonom cez HTTPS, ale nedôveruje SSL certifikátu, ktorý Keystone používa. Navyše sa pokúša o pripojenie na port 35357, čo je starý administratívny port Keystonu (v novších verziách sa už používa štandardný port 5000).

Ďalším krokom môže byť úprava konfiguračného súboru sudo nano /etc/heat/heat.conf po pripojení na jednotku heat príkazom juju ssh heat/0, avšak príkaz juju run heat/0 domain-setup podľa všetkého túto konfiguráciu "ignoroval".

Funkčným riešením je napríklad nastavenie premenných prostredia, avšak toto je len dočasné riešenie (napríklad po výpadku servera bude potrebné tieto zmeny vykonať znova): 

export OS_AUTH_URL=https://<ADRESA_KEYSTONE>:5000/v3
export OS_USERNAME=heat_heat-cfn
export OS_PASSWORD=<password zo sekcie keystone_authtoken v konfiguračnom súbore etc/heat/heat.conf>
export OS_PROJECT_NAME=services
export OS_USER_DOMAIN_NAME=service_domain
export OS_PROJECT_DOMAIN_NAME=service_domain
export OS_IDENTITY_API_VERSION=3
export OS_INSECURE=True

Následne je potrebné zadať nasledujúce príkazy:

Vytvorenie domény heat

openstack --insecure domain create --description "Owns users and projects created by heat" heat

Vytvorenie admin používateľa pre túto doménu

openstack --insecure user create --domain heat –password <Heslo zadené pri EXPORT príkazoch vyššie> heat_domain_admin

Priradenie role admin pre tohto používateľa v doméne

openstack --insecure role add --user heat_domain_admin --user-domain heat --domain heat admin

A následne: sudo systemctl restart heat-api heat-engine

Ďalej je možné, že heat smeruje na databázovú jednotku, ktorá je v móde read-only. Toto sa dá overiť príkazom sudo tail -n 50 /var/log/heat/heat-engine.log, kde by sa mala zobraziť hláška:

'The MySQL server is running with the --read-only option so it cannot execute this statement'

Pri výpise príkazom juju status mysql-innodb-cluster je vidieť režimy jednotlivých jednotiek (R/O alebo R/W).

Ďalej je potrebné prejsť do kontajnera s heat: juju ssh heat/0, prejsť do konfiguračného súboru: sudo nano /etc/heat/heat.conf a v sekcií [database] upraviť IP adresu tak, aby tam bola adresa R/W jednotky. A následne zadať príkaz sudo systemctl restart heat-api heat-engine.

Medzi virtuálnymi inštanciami nefunguje konektivita

V prípade, že virtuálne inštancie sú vytvorené na rôznych výpočtových uzloch (compute nodes), je možné že medzi nimi nebude fungovať konektivita ("ping") aj napriek správnej konfigurácií adresácie a smerovania. Tento problém sa dá vyriešiť pridaním rozhraní medzi výpočtovými uzlami, podobne ako pri predošlom troubleshoot-e.

Pre compute-node 1:

juju ssh nova-compute/0
sudo ip link add link bond name bond.500 type vlan id 500
sudo ip link set bond.500 up
sudo ovs-vsctl del-port brVXLAN bond.500
sudo ovs-vsctl add-port brVXLAN bond.500

Pre compute-node 2:

juju ssh nova-compute/1
sudo ip link add link bond name bond.500 type vlan id 500
sudo ip link set bond.500 up
sudo ovs-vsctl del-port brVXLAN bond.500
sudo ovs-vsctl add-port brVXLAN bond.500

Obnova prostredia po úplnom výpadku

Tento postup nasledujte v prípade, že došlo k úplnému vypnutiu infraštruktúry (napr. výpadok napájania alebo samostného servera) a potrebujete systém znova uviesť do prevádzky.

1. Vrstva VMWare

Poradie spúšťania je kritické kvôli vzájomným závislostiam služieb. V prostredí VMWare zapínajte servery v tomto poradí:

  1. MaaS Server - Zapnite a čakajte aspoň 5 minút.
  2. Juju - Zapnite a čakajte aspoň 5 minút.
  3. Výpočtové uzly (compute nodes) - Zapnite

2. Monitorovanie

Po zapnutí hardvéru potrebuje cloud približne 30 až 40 minút, kým sa služby pokúsia samy inicializovať. Počas tejto doby sa stavy budú dynamicky meniť.

Priebeh môžete sledovať pomocou juju status --watch 1s

3. Oprava MySQL InnoDB Cluster

  1. Identifikácia Leader Unit - Vo výpise juju status hľadajte jednotku mysql-innodb-cluster, ktorá má pri svojom názve hviezdičku (napr. mysql-innodb-cluster/2*)

  2. Spustite obnovu - Na túto leader unit spustite:

juju run mysql-innodb-cluster/<cislo_leader_unit> reboot-cluster-from-complete-outage

Napríklad:

juju run mysql-innodb-cluster/2 reboot-cluster-from-complete-outage
  1. Riešenie problémov

Ak sú jednotky stále v stave executing aj po 20-30 minútach, vykonajte reštart všetkých jednotiek clustra:

Napríklad:

juju ssh mysql-innodb-cluster/0 sudo reboot
juju ssh mysql-innodb-cluster/1 sudo reboot
juju ssh mysql-innodb-cluster/2 sudo reboot

4. Odomknutie služby Vault

Služba Vault zostáva po reštarte uzamknutá. Bez jej odomknutia nebudú fungovať certifikáty a prístup k API.

  1. Reštartovanie jednotky : juju ssh vault/0 sudo reboot

  2. Odomknutie : Prebieha využitím 3 kľúčov (kľúče sa nachádzajú vo vaultKeys.txt)

export VAULT_ADDR='http://127.0.0.1:8200'
vault operator unseal <kluc1>
vault operator unseal <kluc2>
vault operator unseal <kluc3>
  1. Potvrdenie : juju resolved vault/0