Az előző részekben bemutattam az otthoni hálózatom felépítését, a VLAN-okat és a közöttük zajló kommunikáció szabályozását. Közben többször is előkerültek különféle szerverek és szolgáltatások. Mielőtt ezek részleteibe belemennénk, érdemes kicsit visszatekinteni arra, hogyan lett egyáltalán saját szerverem.
A történet egy Raspberry Pi-vel kezdődött, amelyen akkor még ownCloud futott. USB-n csatlakoztattam hozzá egy laptopból származó merevlemezt, ezen tároltam a fájljaimat. A cél egyszerű volt: szerettem volna az otthon tárolt állományaimat távolról is elérni. Ehhez kezdetben elegendőnek bizonyult ez a kis összeállítás.
Aztán a merevlemez tönkrement. Ez volt az a pont, amikor elkezdtem komolyabban gondolkodni azon, hogy milyen rendszerre szeretném hosszabb távon rábízni a fájljaimat.
Nagyjából ebben az időszakban vásároltam egy Raspberry Pi 3-at is, amelyet a televízióra kötve médiaközpontként használtam. Ezzel megjelent egy újabb igény: a médiafájloknak is kellett egy központi tárolóhely, ahonnan a lejátszó elérheti őket.
Ekkor kezdett körvonalazódni, hogy szükségem lenne egy szerverre. Olyan gépet szerettem volna, amelyen tovább működhet az ownCloud – később a Nextcloud –, és amely egyúttal a médiafájlok tárolását, illetve hálózati elérését is biztosítja. A kiinduló igény tehát még egészen egyszerű volt: saját fájlok távoli elérése és közös tárhely az otthoni médiának. Innen indult a ma használt szerverkörnyezetem kialakítása.
A Raspberry Pi üzemeltetése közben tisztában voltam azzal, hogy egy öreg laptop-merevlemez bármikor meghibásodhat, (ami meg is történt) és vele együtt a rajta tárolt adatok is elveszhetnek. Éppen ezért semmilyen pótolhatatlan anyagot nem bíztam rá. Inkább csak játéknak, kísérletezésnek indult az egész, aztán idővel megszokott kényelmi szolgáltatás lett belőle.
Közben azonban felmerült az igény egy megbízhatóbb központi adattárolóra is. Olyan rendszerre, amelyre már fontosabb fájlokat is rábízhatok, és amelynél egyetlen merevlemez meghibásodása még nem jelent adatvesztést. Adta magát, hogy az addigi kísérleti összeállítást komolyabb alapokra helyezzem.
Volt azonban néhány szempont, amelyből nem szerettem volna engedni:
- Alacsony fogyasztás. Ez volt a legfontosabb, hiszen folyamatosan működő gépet terveztem.
- Nagy tárhely. A saját fájlok mellett a médiaállományoknak is el kellett férniük.
- Redundáns lemezkezelés. Egy merevlemez kiesését a rendszernek adatvesztés nélkül kellett átvészelnie.
Két lehetőség között gondolkodtam: vagy vásárolok egy kétlemezes NAS-t, például egy Synologyt, vagy építek egy saját szervert valamilyen passzív hűtésű alaplap köré.
Ekkoriban a munkahelyemen már több szervert üzemeltettem, különféle virtualizációs környezetekben. Dolgoztam OpenVZ-vel, LXC-vel, KVM-mel és VMware-rel is, illetve Synology NAS-t is helyeztem üzembe. Mindkét iránnyal volt tehát gyakorlati tapasztalatom.
A döntés egyik alapja így már biztos volt: bármelyik megoldást választom, a tárolást úgy szeretném kialakítani, hogy egyetlen HDD meghibásodása miatt ne veszítsem el az adataimat. Erre szolgált volna a lemezek tükrözése, vagyis a RAID1. Ez természetesen nem helyettesíti a biztonsági mentést, de az egy merevlemez kieséséből eredő problémára megoldást ad.
Hosszas gondolkodás után végül egy saját építésű, Linuxot futtató szerver mellett döntöttem. Leginkább azért, mert úgy éreztem, ez nagyobb szabadságot ad nekem a rendszer kialakításában és a későbbi bővítésében, mint egy gyári NAS operációs rendszere.
Ráadásul néhány felhasználható alkatrész már rendelkezésre állt otthon. Volt egy Chieftec szerverházam, benne egy szintén Chieftec tápegységgel, illetve 8 GB DDR3 memóriám is. Ezek jó kiindulási alapot jelentettek, így elsősorban egy megfelelő, alacsony fogyasztású alaplapot kellett keresnem.
Az ár szintén fontos szempont volt, ezért az akkori kínálat legolcsóbb megoldásai között nézelődtem. Az alacsony fogyasztás mellett egy lényeges műszaki feltételt tartottam szem előtt: a processzor támogassa a hardveres virtualizációt. Szerettem volna, ha később a különféle szolgáltatásokat virtuális gépekben is futtathatom.
Így esett végül a választásom az ASRock J3455M alaplapra. A meglévő Chieftec házzal, tápegységgel és a 8 GB DDR3 memóriával ez lett az otthoni szerverem alapja.
Szükségem volt még 8Gb RAM-ra (Igy lett 16Gb) és még két merevlemezre is, hogy létre tudjam hozni a RAID1 tömböt. Kezdetnek két darab 1 TB-os lemezzel számoltam, ami tükrözés mellett 1 TB névleges, használható kapacitást jelentett. Nem vagyunk nagy filmnézők, a fényképeinket rendben tartjuk, és a zenegyűjteményem sem különösebben nagy, így ez akkor elegendőnek tűnt.
Szívem szerint NAS-ba szánt, folyamatos üzemre tervezett merevlemezeket választottam volna. A projektet azonban alacsony költségvetésből szerettem volna megvalósítani, ezért végül az általam akkor talált legolcsóbb lemezeket vettem meg: két Toshiba P300-at.
Azzal számoltam, hogy ha az egyik meghibásodik, a RAID1 tükrözésnek köszönhetően az adatok a másik lemezen még rendelkezésre állnak. Emellett terveztem a lemezek állapotának folyamatos figyelését is, hogy az észlelhető problémákról minél hamarabb tudomást szerezzek. Természetesen a monitorozás sem képes minden meghibásodást előre jelezni, és a tükrözés sem helyettesíti a biztonsági mentést.
A két azonos típusú, egyszerre üzembe helyezett lemez választása ugyanakkor némi bizonytalanságot is jelentett számomra. Ugyanabban a gépben, hasonló körülmények között, közel azonos terheléssel és üzemidővel működtek, ezért számolnom kellett azzal is, hogy akár egymáshoz közeli időpontban hibásodhatnak meg. Bíztam benne, hogy az élettartamuk között azért lesz annyi eltérés, hogy az első meghibásodása után legyen időm cserélni a lemezt. Utólag már tudom, hogy ennél a két példánynál így alakult: 5 év üzem után a meghibásodásuk között nagyjából kb 4 hónap telt el.
Az egyiknél hibás szektorok jelentek meg, a másiknál pedig a rendszer naplójában észlelt, javíthatatlan olvasási hibák miatt döntöttem a csere mellett. Nem vártam meg, hogy teljesen működésképtelenné váljanak.
Az építés során még egy fontos szempontom volt: a hűtés zaja. Nálam az egész informatikai rendszer az emeleten, egy gardróbszekrényben kapott helyet, vagyis a lakótérben működik. Emiatt különösen fontos volt, hogy a szerver csendes legyen.
A Chieftec szerverházban a merevlemezek hűtéséről két darab 8 cm-es ventilátor gondoskodik, amelyek közvetlenül a lemezekre fújják a levegőt. Teljes fordulaton azonban meglehetősen hangosak, ezért ezen mindenképpen változtatni szerettem volna.
Két megoldás merült fel bennem. Az egyik az volt, hogy a ventilátorokat 12 V helyett 5 V-ról működtetem, így alacsonyabb fordulaton, lényegesen halkabban járnak. A másik lehetőségként valamilyen egyszerű szabályozást képzeltem el, amellyel beállíthatom a számomra megfelelő fordulatszámot.
Végül a szabályozható megoldás mellett döntöttem, de nem bonyolítottam túl a dolgot. Egy LM317-es állítható feszültségszabályozóval oldottam meg a ventilátorok tápfeszültségének szabályozását. Az IC adatlapján szereplő alapkapcsolást építettem meg, és egy kis hűtőzászlót is szereltem rá a keletkező hő elvezetésére. Ezzel kézzel beállíthatóvá vált a ventilátorok fordulatszáma, így a hűtés és a zajszint közötti kompromisszumot is magam választhattam meg.
LM317 alapkapcsolása
Miután összeállt a hardver, következhetett a Linux telepítése. A szoftveres RAID1 tömböket már a telepítőben létrehoztam, így a rendszer eleve tükrözött lemezekre került. Ez nagyjából hat évvel ezelőtt történt, és őszintén szólva ma már nem emlékszem, pontosan milyen lépésekkel állítottam be. Arra viszont igen, hogy különösebb nehézséget nem okozott.Arra külön figyelni kellett, hogy a rendszerindító mindkét lemezen rendelkezésre álljon, mert az EFI-partíciók nem részei a RAID-tömbnek, így azok tartalmát a tükrözés nem tartja szinkronban. Hiába maradnak meg ugyanis az adataink egy lemezhiba után, ha a gép a megmaradt merevlemezről nem tud elindulni.Ilyenkor érdemes átgondolni hogy a szervergépünk milyen szolgátatásokat fog futtatni. Én annak a híve vagyok, hogy egy szerver egy szolgáltatást futtasson. Ebben az esetben viszont érdemes virtualizációt alkalmazni. az én esetemben ez még azért fontos mert több szerver több hálózati szegmensbe (vlan-ba) tartozik. Igy biztonságtechnikailag is sokkal jobban elkülönithetőek a gépek.
A Linux telepítése után következhetett a virtualizációs környezet kialakítása. Ehhez a KVM/QEMU és a libvirt mellett feltelepítettem a virtuális gépek létrehozásához és a hálózat kezeléséhez szükséges eszközöket is:
sudo apt update && sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst
Az első parancs frissíti a csomaglistát, majd annak sikeres lefutása után elindul a csomagok telepítése. A KVM/QEMU biztosítja a virtuális gépek futtatását, a libvirt pedig ezek kezeléséhez ad közös felületet. A libvirt-clients csomag része például a később használt virsh, amellyel parancssorból vezérelhetjük a virtuális gépeket. A virtinst többek között a létrehozásukhoz használható virt-install eszközt tartalmazza, a bridge-utils pedig a hálózati bridge-ek kezeléséhez biztosít segédprogramokat.
Ezzel felkerültek a virtualizáció alapvető eszközei. Bevallom őszintén, magát a virtualizációs környezetet nagyrészt a telepítés utáni alapbeállításokkal hagytam működni. A következő kérdés az volt, hogyan fogom kezelni a virtuális gépeket.
Erre parancssoros és grafikus eszközök is rendelkezésünkre állnak. Parancssorból például a korábban említett virsh segítségével dolgozhatunk, akár a szerver helyi konzolján, akár SSH-n keresztül bejelentkezve. Én ezt a kezelési módot nem igazán használom, a mindennapokban kényelmesebb számomra a grafikus felület. Emiatt a parancssoros kezelés részleteibe itt nem is mennék bele, de akit érdekel, az elérhető parancsokat és kapcsolókat megtalálja a virsh hivatalos dokumentációjában.
A grafikus kezeléshez a Virtual Machine Manager, röviden virt-manager áll rendelkezésünkre. Ezzel létrehozhatjuk, elindíthatjuk, leállíthatjuk a virtuális gépeinket, illetve módosíthatjuk a hozzájuk rendelt erőforrásokat és virtuális hardvereket.Az alábbi parancssal telepithetjük a programot.
sudo apt update && sudo apt install virt-manager
Ezt a kezelőfelületet többféleképpen is használhatjuk. Az egyik lehetőség, hogy közvetlenül a szerverre telepítjük, és a szervergép előtt ülve indítjuk el. Ehhez természetesen helyi grafikus környezetre is szükségünk van. Én ilyen célra az Xfce felületet kedvelem, mert viszonylag alacsony erőforrásigény mellett teljes értékű asztali környezetet biztosít.
A szerverre telepített virt-managert azonban távolról is megjeleníthetjük SSH-s X11-továbbítással. Ilyenkor maga a program a szerveren fut, az ablaka viszont a saját számítógépünkön jelenik meg. Windows alatt például Xming és PuTTY segítségével is megoldható ez. Ehhez a szerveren nem szükséges teljes asztali környezetnek vagy helyi grafikus munkamenetnek futnia, de a virt-managernek, a hozzá tartozó grafikus függőségeknek és az X11-továbbításhoz szükséges csomagoknak rendelkezésre kell állniuk, valamint az SSH-kapcsolaton engedélyezni kell az X11-továbbítást. A saját gépünkön pedig egy X-szerver, például az Xming gondoskodik a megjelenítésről.
Ez akkor lehet hasznos, ha olyan számítógépről szeretnénk kezelni a szervert, amelyen nem tudjuk vagy nem szeretnénk közvetlenül futtatni a virt-managert, de az X11-megjelenítéshez szükséges eszközök rendelkezésünkre állnak.
A másik lehetőség, hogy a virt-managert a saját számítógépünkre telepítjük, és abból SSH-n keresztül csatlakozunk a szerver libvirt szolgáltatásához. Ebben az esetben a kezelőprogram és annak grafikus felülete is a helyi gépünkön fut, a virtuális gépek pedig továbbra is a szerveren működnek.
Mivel az asztali számítógépemen is Linuxot használok, én ezt a megoldást választottam. Így a szerverre sem asztali környezetet, sem virt-managert nem kellett telepítenem, és X11-továbbításra sem volt szükségem. A saját gépemen megnyitom a kezelőfelületet, csatlakozom a szerverhez, és innen kezelem a rajta futó virtuális gépeket.
A virt-managerrel a következőképp kell kapcsolodnunk a távoli környezethez.
Fájl>Kapcsolat hozzáadása.
A felhasználónév mezőbe a szerveren létező Linux-felhasználónk nevét írjuk. Ennek a felhasználónak SSH-belépési lehetőséggel és a virtualizációs környezet kezeléséhez szükséges jogosultsággal is rendelkeznie kell. Nálam ez már adott volt, mert a saját felhasználóm szerepelt a libvirt csoportban, így külön beállításra nem volt szükség.
A csoporttagságot a szerveren az alábbi paranccsal ellenőrizhetjük:
id usernevemTermészetesen mindenki a saját felhasználónevét helyettesítse be. Ha a libvirt csoporttagság hiányzik, Ubuntu alatt így adhatjuk hozzá:
sudo usermod -aG libvirt usernevemA módosítás után bontsuk a kapcsolatot, majd csatlakozzunk újra, hogy az új csoporttagság érvényesüljön.
A következő feladat annak kialakítása volt, hogyan kapcsolódjanak a virtuális gépek a korábban bemutatott hálózatokhoz.
sudo apt install bridge-utils vlanA bridge-utils az előző parancsban már szerepelt, ezért ha azzal feltelepítettük, itt nem történik újabb telepítése. A következőkben a hálózatot Netplannel konfiguráljuk; ehhez önmagában egyik csomag sem kötelező, de a hagyományos hálózatkezelő eszközöket is elérhetővé teszik.
A hálózati beállításokat a Netplan segítségével végezzük el. Nálam a konfiguráció az /etc/netplan/50-cloud-init.yaml fájlban található, ezért ezt nyitom meg szerkesztésre:
sudo nano /etc/netplan/50-cloud-init.yaml
A fájl tartalma nálam a következő:
network:
version: 2
renderer: networkd
ethernets:
enp1s0:
dhcp4: false
dhcp6: false
link-local: []
bridges:
br0:
interfaces: [enp1s0]
addresses: [192.168.8.8/24]
routes:
- to: default
via: 192.168.8.1
mtu: 1500
nameservers:
addresses: [192.168.8.3, 192.168.208.3]
parameters:
stp: true
forward-delay: 4
dhcp4: false
dhcp6: false
br0.6:
interfaces: [vlan6]
mtu: 1500
dhcp4: false
dhcp6: false
link-local: []
br0.9:
interfaces: [vlan9]
mtu: 1500
dhcp4: false
dhcp6: false
link-local: []
br0.7:
interfaces: [vlan7]
mtu: 1500
dhcp4: false
dhcp6: false
link-local: []
br0.4:
interfaces: [vlan4]
mtu: 1500
dhcp4: false
dhcp6: false
link-local: []
vlans:
vlan6:
id: 6
link: enp1s0
dhcp4: false
dhcp6: false
link-local: []
vlan9:
id: 9
link: enp1s0
dhcp4: false
dhcp6: false
link-local: []
vlan7:
id: 7
link: enp1s0
dhcp4: false
dhcp6: false
link-local: []
vlan4:
id: 4
link: enp1s0
dhcp4: false
dhcp6: false
link-local: []
Az enp1s0 a szerver fizikai hálózati interfésze. A host saját IP-címe a br0 bridge-re kerül, amely a címkézetlenül érkező belső szerverhálózathoz kapcsolódik. A switcholdali beállítás rendeli ezt a forgalmat a 8-as VLAN-hoz.Ezen a címen érhető el a szerver, tehát ez az ő management ip-je.
A többi hálózat számára külön VLAN-interfészeket hozunk létre az enp1s0 fölött. Ezek végzik a VLAN-címkézést, a hozzájuk tartozó bridge-ek pedig csatlakozási pontot biztosítanak a virtuális gépeknek. Például a publikus szerverhálózatba szánt VM-et a br0.6 bridge-hez kapcsoljuk, amely a vlan6 interfészen keresztül éri el a 6-os VLAN-t.
A VLAN-interfészek és a hozzájuk tartozó bridge-ek nem kapnak saját IP-címet ebben a konfigurációban. A virtuális gépek ettől még használhatnak DHCP-t: a náluk beállított DHCP-kliens az adott VLAN DHCP-szerverétől kér címet.
Eljutottunk tehát odáig, hogy van egy saját szerverünk, amelyen már működik a KVM virtualizációs környezet. Kialakítottuk a virtuális gépek hálózati csatlakozásához szükséges VLAN-interfészeket és bridge-eket, valamint a saját számítógépünkről is tudunk kapcsolódni a szerverhez, hogy kezeljük a rajta futó virtuális gépeket.
A következő bejegyzésben megnézzük, hogyan használom ezt a környezetet a gyakorlatban. Átvesszük a virtuális gépek kezelésének alapjait, majd létrehozunk egy új virtuális szervert, és csatlakoztatjuk a neki megfelelő hálózathoz. Ezen egy egyszerű webszervert indítunk el, amelynek példáján keresztül azt is bemutatom, hogyan tehetünk egy szolgáltatást elérhetővé az internet felől.
Ezzel összeérnek a sorozat eddigi részei: a VLAN-ok, a tűzfalszabályok és a saját szerverünk egy konkrét szolgáltatás működésén keresztül állnak össze egésszé.