\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 kiosztásokon 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` á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 Containerst (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.
{width=75%}
### Fájlrendszer beállítása
Szerettem volna, ha szoftveres raid-et használna a szerver zfs-sel, 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-del 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-ot (copy on write) (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.
{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.
{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, ilyenkor
a hoszt gépen létrehozott `root` felhasználóval tudunk belépni,
ezt a \ref{login}. ábrán láthatjuk.
{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