Hirdetés

SFF Itthoni labor

Sziasztok,

Hirdetés

Az első SFF otthoni szerverem építése előtt állok, és az alábbi eseteket fedném le vele:

-VPN,DNS,DHCP, Proxy és backup
-Nas, plex és néhány konténeres alkalmazást szeretnék futtatni
-Ansible,Git, terraform és talán Jenkins
-És pár teszt VM.
-Talán egy IAM szolgáltatást is futtatnék.

Erre 8-10 VM-et képzeltem el Proxmox-on (Gui-s Linuxokat főleg).
Mivel szeretném ezt a rendszert 0-24 futtatni, ezért az alacsony energiafogyasztást helyeztem előtérbe...a kis méretes feltételt csak az esztétika miatt szabtam meg. Erre a célra a következő alkatrészlistát szedtem össze:
-Ház: Jonsbo N4
-CPU: Ryzen 7 5700G
-Alaplap: Asrock B550M Phantom
-Ram: Kingston Fury Beast 2x16 GB
-HDD: 2x1TB WD Red
-SSD: 1 TB Samsung 980 Pro
-PSU:Corsair SF450 gold
-És valami proci hűtő, ami passzol
- + valami kis GPU transzkódoláshoz (quadro p620 vagy intel 310)

https://pcpartpicker.com/user/kelematth/saved/bsGgzy
Mit gondoltok erről a buildről? Szerintetek érdemes egy gépben kezelnem ezeket a szolgáltatásokat illetve szerintetek elég lehet a fenti use-casekhez?

Előre is köszönöm a segítségeteket!

  • R0GERIUS

    tag

    Erre 8-10 VM-et képzeltem el Proxmox-on (Gui-s Linuxokat főleg)
    Ezt határozottan kerüld, túl sok erőforrást eszik a GUI, vagy jelentősen több RAM-ra lesz szükséged.
    Webes GUI a legjobb erre és reverse proxy irányba tapogatóznék inkább.

    Ha Proxmox a terv, akkor inkább a VM-eket LXC konténerekkel váltsd ki, főleg a hálózatkezelők esetén (VPN, DNS, DHCP, (reverse) proxy).
    Akár azon a hack-en is megéri gondolkozni, hogy LXC alatt Docker-t felhúzni (sajnos lehet olyan szoftver, aminek kellhet, például amit fenn említettem).

    Nas, plex és néhány konténeres alkalmazást szeretnék futtatni
    Manapság a NAS-t leszámítva a Docker Compose segítségével le lehet írni egy teljes szoftver szolgáltatás stack-et és sokkal könnyebb üzemeltetni azt, így a kis dolgokra én ebbe az irányba vinném inkább.
    Ebben az esetben kifejezetten javasolt azonos forrásból (pl. linuxserver.io) származó képek használata, mert a Docker rétegekkel (layer-ekkel) dolgozik és kevesebb-re van szükség, mert sok esetben lesz ugyanaz az alapréteg ekkor.
    LXC-vel is megcsinálható ugyanez, de sokkal több a mikromenedzsment és nincs sajnos gyári "software stack" leírója.

    Ansible,Git, terraform és talán Jenkins
    Ansible és Terraform elfér egy LXC konténerben, nem feltétlen érdemes szétdarabolni és legegyszerűbben egy Visual Studio Code-al remote-olva adnék "GUI"-t a dolognak, ha szerkeszteni és futtatni szeretnéd.
    Git-et nem feltétlen üzemeltetnék külön, inkább Gitlab CE és társai, amit érdemesebb, hacsak nem kifejezetten törekszel egy házi és könnyű dologra, iparban ritkán van külön használva.
    Jenkins-t viszont mindenképpen rakd külön konténerbe, az amúgy is fájdalmas tud lenni, nem kizárt, hogy kell néha neki újraindítgatás, főleg ha belenyúlsz egy memory leakes pluginba. :))

    Ha ipari kísérletezés a cél, akkor inkább a Docker még az irányadó, LXC nem elterjedt annyira, mert ritka, amikor teljes OS-t megéri virtualizálni és nem lehet csak az app-ot magát.
    Ha keveset akarsz szenvedni, akkor külön VM a Docker Compose-nak és abban kísérletezni, ami nagyon az alapja az ilyeneknek és ritka a Docker kezelése GUI-ból.
    A Docker esetén a hálózati réteget is elviszi a Docker Engine, amit lehet szintén Docker Compose-ban deklarálni.

    Személy szerint Proxmox-ban LXC-ben futtatnám, amire van normális LXC konténer (lásd: https://community-scripts.github.io/ProxmoxVE/) (mivel annak van a legkisebb "resource overhead"-je és nem kell annyira mikromenedzselni a memóriát), egy VM Docker-nek és egy a NAS-nak a maradék erőforrás a homokozó.
    Vagy a Proxmox vonalat elengedni, Ubuntu LTS szerver (ingyenes Ubuntu Pro-val a live patch kernel miatt) opcionálisan egy webes GUI és Docker-be minden, kivéve a NAS, amihez sanszosan kell egy VM.
    Nincs tökéletes megoldás, preferencia kérdése a dolog.

  • R0GERIUS

    tag

    Személy szerint csatlakoznék az előttem szólóhoz.
    Van egy kis tapasztalatom a fentivel, így kiegészítem azzal:

    Konténerizációs különbségek:
    - LXC: olyan konténer ahol OS virtualizáció a cél, mert több szolgáltatás is kell ugyanazon konténerben, jó példa erre a Zabbix, ha nincs szeparálva (vagy csak tesztként üzemelteted)
    - Docker: olyan konténer, ahol az app virtualizáció a cél, szűken csak az app-ot és annak követelményeit tartalmazza

    Emiatt, vannak olyan dolgok, amiket érdemesebb LXC-ben vagy Docker-ben futtatni, mintsem a másik alternatívában. Ilyen például az LXC-s 'NGINX Proxy Manager' (web guis, nem a sima NGINX), ami igazán csak Docker-ben fut jól, az LXC-s verzió nagyon sokszor nálam képtelen volt elindulni megfelelően egy szerver restart után.
    A csapda ott van, hogy nincs támogatás Docker-re Proxmox-ban, ott jönnek a hackelős történetek.

    Következő posztba dobom a hasznos tanácsokat, hogy ne legyen ebből rekord hosszú hozzászólás.

  • buherton

    őstag

    Személy szerint az alábbiakat javaslom azzal a felkiáltással, hogy szerintem még nem tisztázódott le benned, hogy mit is szeretnél.

    Először is erősen javaslom, hogy Linux only legyen a setup még hozzá GUI nélkül. A GUI egy-egy esetben lehet jobb a CLI-al szemben, de erre az appok tipikusan adnak webes felülelet, lásd Proxmox, Jenkins, stb. Ráadásul a GUI csak nyűg és viszi az erőforrást.

    Home serverhez mini-ITX alaplapot javaslok. Szerintem fontos a méret és tök jó dolog tud lenni, ha kicsi a gép és el lehet rakni, ahol nincs szem előtt. Személy szerint valami ilyesmit javaslok: [Topton N18] vagy [ROCK 5 ITX].

    Szerintem teljesen felesleges napjainkben VM-eket futtatni, a világ a konténerizáció felé ment el. Személy szerint javaslom, hogy minden appod konténerben fusson.

    Gitet szerintem nem érdemes lokál szerveren futtatni a GitHub mindent tud.

  • shadowkidhu

    újonc

    LOGOUT blog

    Köszönöm a konstruktív hozzászólásokat és az ötleteket!

    Annyival kiegészíteném a virtualizációra való fixációmat,hogy az itthoni laborral az is a célom, hogy egy vállalati infrának különböző elemeit illetve azok közötti kapcsolatát tudjam gyakorolni (a média szerver és a NAS-on kívül).

  • bambano

    titán

    válasz LZs?! #4 üzenetére

    Szerintem vm-et marokszám az üzemeltessen, aki meg akarja tanulni a vm-eket, hogy esetleg később fizetős melóban használja. Otthon, különösebb biztonsági igény nélkül, értelmetlen.
    Ráadásul a vm vagy a konténer egy plusz réteg a rendszerben, amiben lehetnek hibák. Na azt debuggold ki...

    Minek futtatnék opnsense tűzfalat? Ami tűzfal szabály egy otthoni rendszerben kell, azt beleírom a debian init szkriptjébe oszt jónapot. Ha nincs fizetős opnsense meló (a láthatáron se), akkor nem kell opnsense. Proxmox dettó, úgysem fogsz hot backup proxmox clustert építeni, mert azt egy gépből nem lehet, tehát amit a proxmox alapból tud a sima kvm-hez képest, az itt offtopic. Akkor minek proxmox? Hogy legyen még egy webes felület, ahol az okleveles kettősklikkelő kiélheti magát?

    Ahogy itt a fórumokat látom, teljesen elszálltak az architekturális kérdésekre adott válaszok.

  • bambano

    titán

    válasz shadowkidhu #2 üzenetére

    Na mégegyszer: az egy teljesen rossz gyakorlat, hogy vm-eket meg konténereket használnak olyanra, amire az alap oprendszer való.
    Majd képzeld el azt a pontot, amikor 8-10 vm-et kell hirtelen upgradelni. Azért nem érdemes se vm-et se konténert telepíteni, hogy legyen mit adminolni.

    Amit leírtál, az kb. egy alap debian. Erre ráhúzol egy libkvm-et azoknak a vm-eknek, amiken tesztelsz, rodeózol, és slussz.

  • LZs?!

    aktív tag

    válasz bambano #1 üzenetére

    A RAM kérdésben csatlakoznék a kollégához: parancssoros Linux VM kifuthat 2GB/VM körül (kalandvágyóknak: 1GB + barebone funkcionalitás; tesztelni elég pl. connectivity, etc.), de GUI-s Linux is megkéri a legalább 4GB memóriát és 2 magot, hogy érdemben reszponzív legyen. A CPU időt a hypervisor tudja ütemezni, így tehetsz 20 VM-et is akár a 8 magra, legfeljebb esnek-kelnek egymáson, és nem fognak kapkodni közben; ellenben még ha dinamikusra is állítod a mermória menedzsmentet (pl. range: min 2GB, max 4GB), amit a VM egyszer már allokált magának a 'burkában', azt a hypervisor már nem tudja (fogja) elvenni.

    Ugyanakkor abban nem értek egyet, hogy nem érdemes VM-be csomagolni: szerintem mindent, ami egy szolgáltatás csomagként operál, érdemes egy-egy különálló VM-be tenni: kompartmentalizáció. Utána mind a change/modify/replace, mind a backup/restore is könnyebb, példa okáért: OPNsense 'routert' (sic!) futtatsz és valami megcsúszik benne - akarsz hibát keresni? Igen -> go for it. Nem -> importálsz/onboard-olsz egy exportált 1:1 (biztonsági) másolatát annak a VM-nek és mész tovább. ...és nagyban is igaz ez a VM-ek összességére, ha megcsuklik a kemény vas az egész hóbelevanc alatt.

  • SutPet

    aktív tag

    Ha plex akkor érdemes intel felé nézelődni a quicksync miatt és nem kell külön vga. Én nemrég álltam át épített xpenology-ról (régi atom D510). Az új tomtop intel n6005-el valamiért egyik loader se akarta megenni így maradt proxmox vagy truenas. Mivel proxmoxom van máshol itthoni célra meg jó kisérletezni ezért truenas scale-re esett a választás, 16g-rammal a plex + *arr stacket gondnélkül viszi konténerből. VM-et csak 2-t próbáltam rajta 4-4gb rammal az vígan elment.
    Az egyéb felépítés nálam: 256 nvme a rendszernek, 512 nvme az appoknak, 2*20TB media, 4*2tb mentéseknek.

    Az én usecase-emhez döcögősen az atom is elég volt(oracle db- azért nem hasított annyira...), a váltás csak azért történt mert plex transcode-ot egyáltalán nem bírt és szembejött a jóáras lap és elméletben még kevesebbet is fogyaszt (d510 13w, n6005 10w).

  • shadowkidhu

    újonc

    LOGOUT blog

    válasz bambano #1 üzenetére

    Köszi!
    Igen, pár szolgáltatást át akarok rakni LXC-be illetve konténerbe. A 8-10 VM-et igazából a tesztek miatt saccoltam. :)

  • bambano

    titán

    Egyrészt 10 rendesebb vm nem fog elfutni 32 giga ramon.
    Másrészt teljesen felesleges olyan dolgokat vm-be rakni, ami nem igényli. Ami állandóan kell, az az alap oprendszeren fusson.
    VM-be azokat a kísérleti dolgokat érdemes tenni, amint felraksz, összegányolsz és letörölsz másnap.

Még van hozzászólás! Tovább