\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