onlab.md

\input{onlabmacros}
\markright{Réthelyi Bálint (IZUM0B)} 
\begin{titlepage}
 \begin{figure}[h]
    \centering
      \includegraphics[width=12cm]{bme_logo}
  \label{fig:bme_logo}
  \end{figure}
  \thispagestyle{empty}
\onlabcim
 
  %\szerzo argumentumok: #1=Név, #2=Neptunkód, #3=szakirány, #4=email,#5 konzulens-1, #6 konzulens-1-email, #7 konzulens-2, #8 konzulens-2-email
  \onlabszerzo{Réthelyi Bálint}{IZUM0B}{Mérnökinformatikus szak}{rethelyibalint@gmail.com}{Dr. Simon Csaba}{simon@tmit.bme.hu}{Dr. Maliosz Markosz}{maliosz@tmit.bme.hu}
  \feladatcim{Proxmox alapú virtualizációs klaszter kiépítése a HSNLabnál}
  \feladatmaga{Proxmox alapú virtualizációs klaszter kiépítése és 
  üzemeltetésének megkönnyítése a HSNLabnál.}

\tanevfelev{2021/22}{II}
\end{titlepage}

# Bevezetés
Az önálló laboratóriumomat a TMIT-en a HSNLab-nál végeztem. A labornak a 
különböző kutatásokhoz van négy szervere. Ezeket a szervereket használják
Kubernetes, valamint docker konténerek futtatására, és ezeken a
szervereken keresztül érik el a tanszéki belső hálózatot is.

Amikor átvettem a szerverek üzemeltetését, a négy gép úgynevezett
[bare-metal](https://en.wikipedia.org/wiki/Bare-metal_server) 
szerver volt, azaz a fizikai szerveren futott egy operációs rendszer
és a felhasználók azt használták. A hosztokon Ubuntu 18.04 futott.

## Problémák a jelenlegi megoldással

Míg első elgondolásra a bare metal megoldás kényelmesnek hangzik 
üzemeletetési szempontból, erről kiderült, hogy azért bőven akad vele
probléma.  
A laborban sokan dolgoznak, csak a BSc és MSc hallgatók száma meghaladja a százat. A laborban az volt a szokásjog, hogy mindenki a `root` 
felhasználóhoz kapott hozzáférést, ezzel a `docker` használatához szükséges
jogosultságok kiosztására nem volt szükség.  
Ez a megoldás sajnos nehezebb auditálhatóságot okozott, hiszen minden
felhasználó a `root` felhasználó nevében végezte a munkáját, így mindent
a `root` felhasználó csinált.  

Minden felhasználónak különböző csomagverziók és azok függőségeire volt 
szüksége, ezért ezek karbantartása és kezelése is problémákat okozott, 
hiszen mindenkinek a fizikai gépen kellett dolgoznia.

Összességében arra jutottam, hogy a virtualizáció lenne a megoldás ezekre a
problémákra, melyet egy hypervisorral (vagy hiperfelügyelővel) terveztem 
megoldani.

# Miért jó a virtualizáció a bare-metal szerver helyett?  

## Mi is pontosan egy bare-metal szerver?  

A bare-metal szerver a fizikai szervert jelenti, melyet általában egy 
kliens/felhasználó használ. Sokkal nagyobb számítási kapacitással 
rendelkezik, mint egy-egy virtuális gép, hiszen hozzáférünk a fizikai
hoszt összes erőforrásához, beleértve a memóriát, a processzort, a 
diszkeket és a sávszélességet is. Előny még emellett, hogy teljes 
felügyeletünk lehet a fizikai gép felett, mind hardveresen, mind 
szoftveresen.

## Mi az a virtualizáció?  

A virtualizáció egy hoszting megoldás, ami több virtuális gép
párhuzamos futtatását teszi lehetővé egy fizikai eszközön. Lehetőséget
biztosít a fizikai gép erőforrásainak *feldarabolására*, és ezek 
kiosztására a virtuális gépek között, így azok ugyanazon erőforrás részein,
*darabkáin* tudnak megosztozni.  
Virtuális gépek használata elősegíti a felhasználók könnyebb 
auditálhatóságát, valamint minden felhasználónak egyedi, elszeparált 
környezetet biztosít, amit a saját igényeinek megfelelően 
alakíthat. 

Ha a virtualizációs megoldást választják, akkor a virtuális gépek 
kiosztását és menedzselését rábízzák egy úgynevezett hypervisorra
(magyarul hiperfelügyelőre).

# Mi az a hypervisor?  

A hypervisor a virtualizációt lehetővé tevő szoftverek kulcsfontosságú 
része. A hypervisor feladata a virtuális gépek (vendéggépek) előkészítése
és a virtuális gépek által elért hardver funkciók elkapása, feldolgozása. 

A hypervisorok egy virtualizációs réteget hoznak létre az által, hogy 
felügyelik, hogy a virtuális gépeken futó folyamatok mely fizikai 
erőforrásokhoz férnek hozzá.

A gépet, amelyre a hypervisort telepítjük, gazdagépnek nevezzük, szemben a 
rajtuk futó virtuális vendéggépekkel.

A hypervisorok a fizikai beosztásán kívül biztosíthatnak emulált 
hardvereket (merevlemez, egér, képernyő, hálókártya, stb.), amelyek 
használatával a vendéggépek úgy viselkedhetnek, mintha fizikai hardveren 
futnának.

A Virtual Machine (virtuális gép) -- a továbbiakban VM -- szempontjából 
nincs különbség a fizikai és a virtualizált környezet között. A 
vendéggépek nem tudják, hogy a hypervisor virtuális környezetben hozta 
létre őket. Sem azt, hogy megosztják a rendelkezésre álló számítási 
teljesítményt. A VM-ek változatlanul az őket működtető hardveren futnak, 
így teljes mértékben függnek annak stabil működésétől.

A hypervisornak tradicionálisan két típusa van. Az első típust bare-metal 
hypervisornak is szokták hívni, míg a másodikat hosztolt hypervisornak. [@hypervisors]

## Első típusú hypervisor  

A bare-metal hypervisor egy olyan szoftverréteg, amelyet közvetlenül a 
fizikai kiszolgálóra telepítünk.

Nincs közte szoftver vagy bármilyen operációs rendszer, innen a bare-metal 
hypervisor (magyarul csupasz metál) elnevezés. Az 1-es típusú hypervisor 
kiváló teljesítményt és stabilitást biztosít, mivel nem egy operációs 
rendszeren belül fut.

Az 1-es típusú hiypervisor egy nagyon alapszintű operációs rendszer, 
amelyen virtuális gépeket lehet futtatni. A fizikai gép, amelyen a 
hypervisor fut, csak virtualizációs célokat szolgál. Másra nem használható.

## Második típusú hypervisor  

Az ilyen típusú hypervisor egy fizikai gép operációs rendszerén belül fut.

Ezért nevezzük a 2. típusú hypervisorokat hosztolt hypervisoroknak. Az 1. 
típusú hypervisorokkal szemben, amelyek közvetlenül a hardveren futnak, a 
hosztolt hypervisorok alatt egy szoftverréteg található. Ebben az esetben 
a következőkkel rendelkezünk:

- Egy fizikai gép.
- A hardverre telepített operációs rendszer (Windows, Linux, macOS).
- Az operációs rendszeren belül egy 2. típusú hypervisor szoftver.
- A vendég virtuális gépek tényleges példányai.

Ebben az esetben a fizikai hoszton is tudjuk kezelni, menedzselni a 
virtuális gépeinket.

## A modern hypervisor  

Manapság rájöttek, hogy a bare-metal hypervisor jó tulajdonságai mellett
kényelmes, ha az operációs rendszer teljes értékű. Ezért a gyártók 
beleépítették az operációs rendszerekbe a hypervisor modult, ezzel
elérve, hogy legyen egy tradicionális operációs rendszerünk, annak minden
pozitív tulajdonságával és kényelmi funkciójával, és a hypervisor is kernel
szintű legyen, ne legyen még egy plusz réteg az operációs rendszer fölött.

A teljesség igénye nélkül ilyen megoldások az alábbiak:

- VMware ESXi
- Hyper-V
- Linux + KVM
- bhyve (FreeBSD)
- Hypervisor framework (Apple macOS)
- Proxmox

## Modern hypervisorok kezelése  

Ha elindítunk egy fizikai kiszolgálót, amelyen egy hypervisor 
van telepítve, egy parancssorszerű képernyő jelenik meg. Ha egy monitort 
csatlakoztatunk a szerverhez, akkor a hardver és a hálózat néhány 
részletét láthatjuk. Ez általában a CPU típusából, a memória 
mennyiségéből, az IP-címből és a MAC-címből áll.

Általában ezek csak egyszerű szerverkonfigurációt tesznek lehetővé.

Ez a dátum és az idő, az IP-cím, a jelszó stb. megváltoztatásából áll. A 
virtuális példányok létrehozásához egy másik gépen beállított 
kezelőkonzolra van szükség. A konzol segítségével csatlakozhatunk a 
szerveren lévő hypervisorhoz, és kezelhetjük a virtuális környezetet.

A kezelési konzol lehet webalapú vagy különálló szoftvercsomag, amelyet 
telepíthetünk arra a gépre, amelynek távoli kezelését szeretnénk.

Az egyik elvégezhető művelet a virtuális gépek fizikai kiszolgálók közötti 
manuális vagy automatikus áthelyezése. Ez a mozgatás a VM adott 
pillanatban fennálló erőforrásigényén alapul, és a végfelhasználókra 
gyakorolt hatás nélkül történik. Ugyanez a folyamat történik akkor is, ha 
egy hardverdarab vagy egy egész szerver meghibásodik. A megfelelően 
konfigurált kezelőszoftver a virtuális gépeket egy működő szerverre 
helyezi át, amint probléma merül fel. Az észlelési és helyreállítási 
eljárás automatikusan és zökkenőmentesen zajlik.

A hypervisorok egyik legjobb tulajdonsága, hogy lehetővé teszik a fizikai
erőforrások túlkiosztását.

A hypervisorokkal több erőforrást rendelhetünk a virtuális gépekhez, mint 
amennyi rendelkezésre áll. Ha például a kiszolgálón 128 GB 
RAM van, és nyolc virtuális gépet használunk, mindegyikhez 24 GB RAM-ot 
rendelhetünk. Ez összesen 192 GB RAM-ot jelent, de maguk a VM-ek valójában 
nem fogják elfogyasztani a fizikai kiszolgáló mind a 24 GB-ját. A VM-ek 
azt hiszik, hogy 24 GB-ot használhatnak, holott valójában csak annyi 
RAM-ot használnak, amennyi az egyes feladatok elvégzéséhez szükséges.

A hypervisor csak annyi erőforrást rendel ki, amennyi szükséges ahhoz, 
hogy egy példány teljes mértékben működőképes legyen.

# Modern hypervisorok áttekintése

## VMware ESXi  

Az ESXi egy BSD alapú operációs rendszer, melynek magja a VMkernel, mely a 
FreeBSD kernelén alapszik és ebbe építették bele a hypervisort.

Nagyvállalati környezetben a legtöbbször ezt a megoldást a vSphere-el 
együtt használják, mely lehetővé teszi több ESXi hoszt klaszterizálását,
viszont fizetős.

Korábbi munkáim során találkoztam már a megoldással, és a tanszéki 
környezethez feleslegesen bonyolultnak és túlságosan robusztusnak ítéltem 
meg, ezért elvetettem a használatát.

## Hyper-V  

A Hyper-V a Microsoft hypervisor megoldása, mely mind a fogyasztói
Windows, mind Windows Server operációs rendszereken elérhető. 
Természetesen az átlag felhasználók számára jóval kevesebb funkció érhető 
el, mint a szerveres környezetben.

A Hyper-V a Microsoft által készített NT kernel része, így Windowson
lehetővé teszi virtuális gépek futtatását.

Ezzel a megoldással is találkoztam már korábban, és mivel a tanszéki
környezetben inkább Linuxos környezetre van szükség, feleslegesen 
bonyolultnak éreztem egy Windowsos réteg bevonását az ökoszisztémába.

## Linux plusz KVM  

A KVM, azaz Kernel-based Virtual Machine (kernel alapú virtuális gép) egy 
virtualizációs infrastruktúra a Linux rendszermagba integrálva. A modul
betöltésekor a Linux kernel egy vékony része Hypervisorrá válik. A KVM 
natív (hardver-segített) virtualizációt támogat.  

A KVM egy nyílt forráskódú megoldás, mely egy betölthető kernelmodulból, a 
`kvm.ko`-ból, amely az alapvető virtualizációs infrastruktúrát biztosítja, 
és egy processzorspecifikus modulból, például a `kvm-intel.ko` vagy 
`kvm-amd.ko` modulból áll. 

Ez egy egyszerű API-t biztosít, mely segítségével könnyű virtuális gépeket
futtató programokat írni, például ilyen a QEMU is.

Ezen a megoldáson (QEMU+KVM) alapszik a Proxmox VE is, amelyet végül a 
tanszéki rendszerek hypervisorának választottam.

## Proxmox VE  

A Proxmox VE egy teljes körű, nyílt forráskódú, Debian alapú
szervermenedzsment platform virtualizációhoz. Szorosan integrálja a KVM 
hypervisort és a Linux Containers (LXC), a szoftveresen definiált tárolási 
és hálózati funkciókat egyetlen platformon. Az integrált webalapú 
felhasználói felülettel könnyedén kezelhetőek a VM-ek és konténerek, a 
klaszterek magas rendelkezésre állása vagy az 
integrált katasztrófa-helyreállítási eszközök (disaster recovery tools).

# Proxmox VE telepítése  

## Beállítások kiválasztása  

### Hálózat beállítása  

Először szeretném, hogy a hosztot el lehessen érni rögtön a tanszéki
hálózatról, valamint legyen hozzáférése az internethez is, így a korábbi
interfészét szeretnénk megtartani, valamint a korábbi 
interfészbeállításokat is.  
Azaz beállítom menedzsment interfésznek a korábbi interfészt (ez 
jelen esetben az `ens18` interfész). Hosztnévnek a `vke2.hsnlab`-ot 
veszem fel (ez beírásra kerül a `/etc/hosts` fájlba, valamint ez alapján
lesz beállítva a hoszt hosztneve).
IP címnek beállítom a korábban használt címet: `10.6.6.7/24` és átjárónak
szintén a korábbi átjárót: `10.6.6.1`. 

A \ref{network}. ábrán a hálózati beállítások láthatóak.

![Hálózat beállítása\label{network}](pics/proxmox05.png){width=75%}  

### Fájlrendszer beállítása  

Szerettem volna, ha szoftveres raid-et használna a szerver zfs-el, mivel
a zfs fájl szinten kezeli az adatokat, így sokkal több lehetőség áll
rendelkezésre az adatok védelme, sebességnövelés, stb. érdekében.
Hardveres raid-el szemben a szoftveres raid nincsen hardverhez kötve,
így meghibásodás esetén a merevlemezeket át lehet tenni egy másik gépbe,
ahol szoftveresen ugyanúgy össze lehet rakni a raid-et, és le lehet 
menteni az adatokat, valamint így a vendor lock-in (gyártókhoz kötés) se 
áll fent.
A szoftveres raid rendszeresen kap frissítéseket, így az idővel jobb,
hatékonyabb lehet, valamint biztonsági hibákat is lehet rajtuk javítani,
ellentétben egy hardveres raid vezérlővel. [@zfs]

Ezen kívül a zfs támogat:

- cow (copy on write)-ot (magyarul: írás közbeni másolás)
- transzparens tömörítést
- thin allocated (magyarul: vékonyan allokált) virtuális diskek 
létrehozását
- snapshotokat (pillanatképeket) és azok hálózaton való átküldését

Az \ref{filesystem}. ábrán láthatóak a fájlrendszer beállításai. Mivel
két lemezes rendszerről van szó, ezért RAID1-et választottam, ami a lemezek
tükrözését jelenti.

![Fájlrendszer beállítása\label{filesystem}](pics/proxmox02.png){width=75%}  

## A hardveres RAID vezérlő átállítása HBA módba  

Mivel korábban úgy döntöttem, hogy a Proxmoxon szoftveres raid-et fogok 
használni, ezért át kellett kapcsoljam a hardveres RAID vezérlőt HBA módba.

### SAS vezérlők módjai  

A szerverekben több merevlemez vagy SSD együttes használatához úgynevezett
SAS vezérlőt alkalmaznak (Serial Attached SCSI), mely segítségével
sorosan lehet a merevlemezeket csatlakoztatni.

Ezeknek a SAS vezérlőknek általában két módja van, a RAID mód és a HBA mód.
[@sas]

RAID módban, azaz Redundant Array of Independent Disks (magyarul: 
független lemezek redundáns tömbje), az operációs rendszer nem fogja látni a független lemezeket, hanem egy virtuális tömbként, eszközként fogja azt 
kezelni.

HBA módban (Host Bus Adapter) a vezérlő átadja a lemezeket az operációs
rendszernek, azaz az operációs rendszer látni fogja az összes független
lemezt.

## Telepítés  

A Proxmox telepítése innentől kezdve egy *Next,Next, Finish* jellegű
feladat, a telepítés előtt még leelenőriztem a beállításokat, melyek
a \ref{confirm}. ábrán láthatóak.

![Beállítások ellenőrzése\label{confirm}](pics/proxmox06.png){width=75%}  

# A Proxmox üzemeltetése  

A Proxmoxot általában két módon lehet elérni, konzolosan, vagy pedig a
webes interfészén keresztül.

## Webes interfész  

A webes interfészt (Proxmox GUI) a fizikai gép IP címén lehet elérni, a
`8006`-os porton. Fontos a biztonságos kapcsolat (`https`), mert anélkül 
nem tölt be. Így a korábban telepített szervert jelenleg a 
`https://10.6.6.7:8006` címen lehet elérni (tanszéki hálózatról). 
Belépéskor a `Linux PAM` autentikációt kell választani jelen esetben, ebben
az esetben a hoszt gépen létrehozott `root` felhasználóval tudunk belépni,
ezt a \ref{login}. ábrán láthatjuk.

![Proxmox GUI belépés\label{login}](pics/proxmox_login.png){width=35%}

## Konzolos (CLI) interfész  

A konzolos interfészt vagy fizikai hozzáféréssel érjük el, a hosztra
csatlakoztatott billentyűzet és monitor kombinációval, vagy a gyakoribb
megoldás, hogy `ssh`-n keresztül csatlakozunk a hosztra.  
Mivel korábban pont azért választottam a Proxmoxot, hogy kapjak egy 
tradicionális linux shellt (héjat), ezért a megszokott linuxos parancsokon
kívül van pár extra, Proxmox specifikus parancs is.

## VM készítése (automatizálás)

A hypervisoroknak a legfontosabb funkcionalitása természetesen a virtuális
gépek készítése, menedzselése. Erre a Proxmox nyújt webes felületet is, 
ahol egy barátságos menüsoron keresztül lehet létrehozni VM-eket, valamint
egy API-t, amit mind konzolon keresztül (cli-ból), mind külső alkalmazással
lehet vezérelni.

Ahhoz, hogy egy VM-et fel tudjunk telepíteni, fel kell tölteni a Proxmox
tárhelyére a VM telepítő képet (VM ISO).

Egy VM telepítő konfigurálása általában hosszú folyamat, melyet nagyobb 
mennyiségű VM előállításánál az üzemeltető nem feltétlen szeretne kivárni,
egyesével elvégezni.

### CloudInit

Az iparban (valamint a tanszéken is) a legtöbb esetben Ubuntu VM-eket 
használnak. Létezik egy CloudInitnek nevezett megoldás Ubuntu VM-ek 
egyszerűbb telepítésére. A CloudInit lehetőséget biztosít arra, hogy
előre (a VM indítása és telepítése előtt) beállítsuk a teljesség igénye 
nélkül az alábbiakat a virtuális gépen:

- felhasználó (létezik egy alapértelmezett, ez az `ubuntu` felhasználó)
- jelszó (nem kötelező beállítani)
- SSH publikus kulcso(ka)t (ez, ha nem adtunk meg jelszót, a belépéshez 
elengedhetetlen)
- valamint a hálózati interfészeket lehet konfigurálni:
  - IPv4 és IPv6-os címek
  - IPv4 és IPv6-os hálózati átjárók
  - MAC cím

## IaaS (Infrastructure as a Service) megoldás a Proxmox üzemeltetéséhez

Az iparban manapság elterjedt fogalom az Infrastructure as a Service 
(magyarul infrastruktúra, mint szolgáltatás) -- továbbiakban IaaS --
rendszerautomatizálás szempontjából kényelmes lehetőségeket biztosít.

Általános megoldás a Terrible kombináció, mely az Ansible és a 
Terraform eszközök együttes használatából ered.

Az Ansible egy olyan eszköz, melyben deklaratívan le tudjuk írni az 
operációs rendszerünk és a telepített alkalmazásaink kívánt állapotát.

A terraform pedig olyan eszköz, mely segítségével deklaratív konfigurációs 
nyelven tudnak a fejlesztők definiálni virtuális gépeket 
(és konténereket). Segítségével gyorsan, öndokumentálóan és könnyen lehet 
létrehozni a kívánt virtuális gépeket.

### Ansible-ös CloudInit

A félév során elkészítettem egy Ansible `playbook`ot (forgatókönyvet),
mely segítségével automatikusan fel tudok telepíteni tetszőleges
CloudInit-es VM sablont (Vm template) a hosztra, melyeken előtte
beállítom a QEMU Guest Agent-öt, mely egy, a vendéggépen futó processz,
ami a hoszt OS felé reportol adatokat és segíti a vendég gép vezérlését
(pl. leállítás, újraindítás). [@ansible]

### Terraform-os VM és LXC konténer generálás

Miután elkészítettem a CludInit-es VM sablonokat (Ubuntu 20.04, 22.04), 
készítettem két Terraformos konfigurációt is, melyek segítségével VM-eket
és LXC konténereket lehet bármekkora mennyiségben, automatizáltan 
létrehozni. [@terraform]

# Későbbi fejlesztési lehetőségek

## Többi szerver újratelepítése

A későbbiekben szeretném a maradék három szervert is újratelepíteni 
Proxmoxal és a Proxmox által használt klaszterizációs megoldást beállítani,
hogy a szerverek egy közös Proxmox klaszterként funkcionáljanak. Szeretnék
közöttük elosztott fájlrendszer megoldást beállítani, hogy az adatok 
biztonságosan legyenek tárolva, erre a Ceph-et néztem ki megoldásnak.

## GitLab integráció

Szeretnék elkészíteni olyan repozitori(ka)t, ahol a Terraformos megoldás
teljesen ki lenne dolgozva, és biztonságos módon lehetne automatikusan
generálni a VM-eket és LXC konténereket.

## Kubernetes(ek)

Szeretnék egy, vagy több Kubernetes klasztert létrehozni a gépeken, 
melyeken a tanszéken dolgozók tudnák a kutatásaikat folytatni. Ehhez
szeretnék szintén automatizálható konfigurációt elkészíteni, hogy
ha szükség lenne egy újabb Kubernetesre, vagy ha egy meglevőt kellene 
eldobni és helyette újat létrehozni, akkor azt kényelmesen lehessen 
elvégezni bárki által.

# Összefoglalás

A félév során megismertem a tanszéki szervereket és azok felhasználásának
módját. Utána néztem, hogy milyen megoldássokkal lehetne javítani, jobbá 
tenni a jelenlegi helyzetet, majd telepítettem egy Proxmox hypervisort
az egyik tanszéki szerverre.  
Elkészítettem egy Ansible-ös és két Terraformos konfigurációt a rendszer
automatizálásának előkészítéséhez.

# Irodalomjegyzék