Cluster építése/Felépítése - Hardver-Szoftver struktúrák
Folytassuk akkor a második cikkel, amiben igyekszem a felmerült kérdésekre is válaszolni. Amennyire lehet, az írás elején, de lesz, amit a sorok között válaszolok meg. Igazából nem feltétlenül ebben a sorrendben haladok a projekt megvalósításával, csak igyekeztem előre venni a kérdésekre a válaszokat.
Tartalomjegyzék:
(A linkek a cikkek megjelenése után lesznek elérhetők.)
- 1. Cikk: "Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket..." - Az Első Cikk ITT olvasható.
- 2. Cikk: "AI (és másra is használt) Cluster építése" - A Második Cikk ITT olvasható.
- 3. Cikk: "AI Kérdés érkezett - 3600 soros Spagetti kód refaktorálása és budget" - A Harmadik Cikk ITT olvasható.
- 4. Cikk: "AI Cluster - A Projekt céljai, a Cluster felépítésének okai" - Folyamatban
- 5. Cikk: "AI Cluster - Hardver Összesítő, tervezett felépítés" - Aktuális Cikk.
- 6. Cikk: "Hardverek tesztelése és firmware-ellenőrzés" - Tervben....
- 7. Cikk: "Hálózati konfiguráció (Gépek egymás közti hálózata, és külön hálózaton a Termináláshoz)" - Tervben...
- 8. Cikk: "Debian 13 alaprendszer telepítése" - Tervben...
- 9. Cikk: "Kubernetes és Docker telepítése" - Tervben...
- 10. Cikk: "Hálózati konfiguráció (Független, különálló hálózat az Internet eléréséhez!)" - Tervben...
- 11. Cikk: "Tesztek, Monitorozás, Virtuális gépek (VM-ek) telepítése" - Tervben...
- 12. Cikk: "VM-ek beállítása (Kvóták), tervezet adatmentési megoldások" - Tervben...
- Stb.
- X-edik Cikk: "A megvalósítás során előkerült hibák, és azok megoldásai (Gyűjtemény)" - Tervben...
(A változtatás jogát fenntartom! A cikkek sorrendje a projekt előrehaladtával módosulhat, és további témák is felmerülhetnek, összevonások is előfordulhatnak.)
Ez a cikk a tervezési fázist mutatja be, és célja, hogy a szakmai közösség visszajelzéseivel finomítsam a rendszert. A fórumon várom az ötleteket, különösen örülök, ha elkerülhető hibákra hívják fel jó előre a figyelmemet. De lehet az az AI modellek kiválasztására is (Bár ebből igen szép számmal szedtem már össze.), az API-feldolgozásra és akár a SPARC integrációra is!
Sajnos ezen a képe még együtt jelennek meg a nem összeillő adatok.
---------------------------------------------------------------------------------
Kezdjünk azzal, hogy válaszolok felmerült kérdésekre:
Ahogy az a hozzászólások résznél is írtam: "Minden építő jellegű kritikát elfogadok, szakmai tanácsadást, segítséget, stb..."
A sajnálatos szerver leállás előtt (Prohardver Lapcsalád Szerver hiba) is volt számos hozzászólás, kérdés-felelettel, sajnos ezek elvesztek. 
Van ez így.
A Prohardver lapcsalád februári szerverhibája (CPU csere utáni adatbázis-összeomlás és egyhetes kiesés) arra tanított, hogy a mentések integritását rendszeresen ellenőrizni kell. Ezért az a terv, hogy napi inkrementális mentéseket végzek Restic-kel egy külső NAS-ra vagy felhőbe (pl. Backblaze B2), és CRC-tesztekkel (restic check) ellenőrzöm a mentések sértetlenségét. Ezen felül fontolgatom további ellenőrzések (pl. MD5 hash összehasonlítás) bevezetését a maximális megbízhatóság érdekében.
A Ceph cluster háromszoros replikációja további redundanciát biztosít, ezeket a gyengébb gépeken is meg lehet oldani.
A Grafana/Prometheus segítségével monitorozom a gépek egészségét (pl. CPU hibák, lemez I/O), hogy észrevegyem az olyan rejtett problémákat, mint a Prohardver esetében.
Erről bővebben majd az "Automatizált mentési rendszer kiépítése" című cikkben. (Lásd Tartalomjegyzék)
1.
Kérdés volt, (Több embertől is) hogy az elavult gépek vajon megfelelőek lesznek, megfelelőek lehetnek-e, mennyire jelent kihívást az elavult hardverek kezelése?
Jelenleg úgy gondolom, - amíg vki meg nem győz az ellenkezőjéről! - hogy az elavult hardverek költséghatékony megoldást jelenthetnek...
..meglehet ez a döntés mindig kompromisszumokkal és extra munkával járnak.
A SUN SPARC szervereken is Debian-t tervezek, de:
"A Debian 13 nem támogatja hivatalosan a SPARC architektúrát (csak amd64, arm64, armhf, armel, ppc64el, riscv64, s390x szerepel a release notes-ban). Azonban a Debian 10/11 még támogatta a SPARC64-et, így backportolhatsz egy régebbi kernelt, vagy használhatsz Oracle Linuxot/Illumos-t ezekre a gépekre."
A SUN SPARC gépek külön kezelést igényelnek: "A SPARC T3-2 szerverek (6 CPU, 512 GB RAM) hatalmas számítási kapacitást nyújtanak, de a Debian 13 nem támogatja a SPARC64-et. Ezért ezekre a gépekre Debian 11-et vagy Oracle Linuxot tervezek,
különálló node-ként kezelem adatbázis- vagy tároló feladatokra, amelyeket NFS vagy Ceph segítségével integrálok a Kubernetes clusterrel, de nem futtatnak közvetlenül Kubernetes pod-okat.
A SPARC gépek eltérő architektúrája miatt külön image-eket kell buildelnem a Docker konténerekhez, és a hálózati integrációt gondosan kell tervezni.
A SPARC gépek (SUN SPARC T3-2) integrálása egy egységes Kubernetes/Docker clusterbe nem TRIVIÁLIS feladat, több technikai akadály miatt:
- Architektúra különbség:
A SPARC64 egy big-endian RISC architektúra, míg a cluster többi része (Dell XS23-TY3, Tesla GPU-k) valószínűleg x86_64 (little-endian CISC). A Kubernetes és a Docker főleg x86_64 és arm64 architektúrákra van optimalizálva, és a SPARC64-re kevés hivatalos image érhető el. Például a Docker Hub-on a legtöbb konténer (pl. Python, PyTorch) nem támogat SPARC64-et, így saját image-eket kell buildelned, ami időigényes és hibára hajlamos.
- Szoftverkompatibilitás:
A Debian 13 nem támogatja a SPARC64-et, így a SPARC gépekre Debian 11-et vagy Oracle Linuxot kell telepítened. Ez azt jelenti, hogy a clusterben különböző operációs rendszerek és kernelverziók futnak, ami bonyolítja a kezelést (pl. eltérő csomagkezelés, frissítési ciklusok, biztonsági patchek).
- Hálózati és klaszterintegráció:
A Kubernetes feltételezi, hogy minden node homogén környezetben fut (hasonló OS, kernel, container runtime). A SPARC gépek külön node-ként való integrálása lehetséges, de a Kubernetes nem tudja közvetlenül kezelni őket a konténerizált workloadok szempontjából, mert a pod-ok nem futhatnak SPARC64-en standard image-ekkel. Ezért valószínűleg különálló adatbázis- vagy tároló node-ként kell őket használni, ami extra hálózati konfigurációt és szinkronizációt igényel (pl. NFS, Ceph, vagy API-kapcsolatok).
- PREEMPT_RT korlátok:
A PREEMPT_RT kernel SPARC64-en nem hivatalosan támogatott, így a valós idejű funkcionalitás nem garantált ezeken a gépeken, ami eltér a cluster többi részétől (x86_64, RT kernel).
Megoldható-e, hogy a SPARC gépek a Docker és Kubernetes részei legyenek?
Igen, megoldható, de jelentős extra munkával, és nem biztos, hogy érdemes a teljes integráció.
Íme a lehetőségek és kihívások:
- Lehetőség 1: SPARC node-ok különálló szereppel:
- Megközelítés:
A SPARC gépeket különálló node-ként kezeled, amelyek nem futnak Kubernetes pod-okat, hanem dedikált feladatokat látnak el (pl. TimescaleDB adatbázis, API előfeldolgozás). Ezeket NFS-en vagy API-n keresztül integrálod a Kubernetes clusterrel.
- Előny:
Nem kell SPARC64-re Docker image-eket buildelni, és a Debian 11/Oracle Linux kompatibilis marad. A SPARC 128 szál/CPU előnye kihasználható adatbázis-műveletekre.
- Hátrány:
Nem teljes Kubernetes integráció, így a SPARC gépek nem részei a Kubernetes schedulernek (nem futtatnak pod-okat).
- Példa:
Telepíts TimescaleDB-t a SPARC gépekre (sudo apt install timescaledb-postgresql-17 Debian 11-en), és konfigurálj egy PostgreSQL replikációt a Kubernetes pod-okkal való szinkronizációhoz.
- Lehetőség 2: SPARC node-ok Kubernetes részeként:
- Megközelítés:
Telepítsd a Docker-t és a Kubernetes node komponenseket (kubelet, kubeadm) a SPARC gépekre Debian 11 vagy Oracle Linux alapon. Buildelj SPARC64-kompatibilis Docker image-eket a feladatokhoz (pl. Python API kliensekhez).
- Előny:
A SPARC gépek teljes értékű Kubernetes node-ként működhetnek, és a 768 szál kihasználható párhuzamos API-feldolgozásra.
- Hátrány:
Nagyon időigényes a SPARC64 image-ek buildelése (pl. docker build --platform linux/sparc64), mert sok függőség nem érhető el natívan. A Kubernetes közösségi támogatása SPARC-ra minimális, így hibakeresés nehéz lesz.
- Példa:
Telepítsd a Docker-t Oracle Linuxra:sudo yum install docker-ce
sudo systemctl enable docker
Majd buildelj egy SPARC64 image-et:FROM sparc64/debian:11
RUN apt update && apt install python3 python3-pip
RUN pip3 install ccxt
COPY app.py /app/
CMD ["python3", "/app/app.py"]
Ez azonban sok próbálkozást igényel, mert a SPARC64 image-ek ritkák.
A SPARC64 image-ek buildelése kihívás, mert a Docker Hub-on nem érhetők el hivatalos SPARC64 image-ek.
Ezért saját base image-et kell létrehozni, például egy Debian 11 alapú image-ből kiindulva.
- A legkézenfekvőbb megoldás:
A SPARC gépeket különálló node-ként adatbázisra, és/vagy adat előfeldolgozásra, API feladatokra használom. Nem fogom teljes Kubernetes node-ként integrálni, mert az túl bonyolult és nem költséghatékony. Helyette egy NFS, vagy Ceph mount-ot csinálok a SPARC gépekről a Kubernetes pod-okhoz, így az adatbázis-adatok elérhetők maradnak.
Kicsit jobban érezhető a szerverek-gépek egymáshoz viszonyított teljesítmény aránya
(Főleg a GPU adatok torzítása nélkül)
A valós idejű API-adatfeldolgozás szempontjából kulcsfontosságú
(Erre később térek majd ki, egy másik részében a cikkenek.) a PREEMPT_RT kernel használata a clusterben, különösen az API lekérdezések és AI modellek alacsony latencyjéhez. Bár a PREEMPT_RT a Linux 6.12 kernelbe integrálódott, a Debian 13 alapértelmezett kernelje nem aktiválja. Ezért az linux-image-rt-amd64 csomagot telepítem, amely biztosítja a <100 µs latencyt.
A telepítés egyszerű (Minta):sudo apt install linux-image-rt-amd64
sudo reboot
Figyelem:
Utána a GRUB-ban ki kell választani az RT kernelt!
A legnagyobb kihívás az NVIDIA driver kompatibilitása lehet, de ezt workaroundokkal kezelem, például az IGNORE_PREEMPT_RT_PRESENCE=1 változóval.
Az NVIDIA driver és a PREEMPT_RT kernel kompatibilitása nem hivatalosan támogatott, így az IGNORE_PREEMPT_RT_PRESENCE=1 workaround használata stabilitási kockázatot jelenthet. Ezt alapos teszteléssel (pl. cyclictest és nvidia-smi) ellenőrzöm.
Illetve a másik félelmem pont az egy Clusteren belül több különböző Debian verzió, vagy egyenesen másik rendszer. (Oracle Linux)
2.
Kérdés volt továbbá, hogy az elavult hardverek, még a Tesla K80-as is a régi CUDA támogatással mennyire lehet használható 1-1 AI-hoz, a tanításhoz, stb.
1. Kezdetben elő-tanított modelleket fogok használni, amik kevésbé igénylik, például LLaMA 7B vagy BERT alapú modelleket fontolgatok, de a közösség javaslatai alapján változhatnak az adott modellek. (Még nem döntöttem mindenről, tanulmányozom a kérdést.)
Olyan modellek lesznek az elsők, amelyek 24 GB VRAM-on kezelhetők. Nagyobb modellekhez (pl. 16B paraméteres) model parallelism-t vagy több K80-at használok párhuzamosan. (A Kubernetesben.)
2. A CUDA 3.7 korlátok miatt PyTorch vagy TensorFlow régebbi verzióit használom (pl. PyTorch 1.13 CUDA 11.8-hoz).
Előfordulhat, hogy egy újabb VGA újabb CUDA maggal ugyan többet tud, és erősebb a számítási képessége, azonban jelentősen drágább is, és nagyon sok esetben a VRAM mennyisége sem mindegy, 1db ilyen kártya kevés lehet. (Mondjuk egy 16 milliárd paraméteres modell futtatása szeretne legalább 16GB VRAM-ot...) Itt úgy gondolom, hogy mindenképpen előny a futtatásban, hogy 100GB VRAM feletti mennyiségen tudom futtatni a modelleket!
Itt még mindig nehezen kivehető a CUDA magok mellett a többi adat aránya
3. Ha nagyon hiányát látom az új CUDA magoknak, (Úgy gondolom, hogy: Kizárólag abban az esetben, ha tanítani, képezni szeretném a modellem, modelljeimet...) akkor:
A. Ha szükséges, felhőalapú számítási kapacitást bérlek az edzéshez, például AWS EC2 P4d instance-eket,
Így kizárólag a számítást adom át, az adataimhoz így nincsen hozzáférésük, nem teljes szervereket kell bérelni:
terabyte-okkal, + CPU + 100GB-1'000GB RAM-okkal...
ARANY ÁRON!
B. Azonkívül ebben az esetben a későbbiekben (Főleg ha sikerül szolgáltatás nyújtásra, és/vagy haszon termelésére használni!)
még mindig beszerezhető 1-több megfelelő hardver a saját rendszerbe is! Nem rögtön a kezdő fázisban!
Amiket néztem, azok 2-3M Ft körül játszanak az EU-ban, és ugyebár nem egy db lenne belőle az ideális, hanem 4-6-8db.
Egyelőre így is fájó a költségoldalam, erre még nem telik sajna, így be kell érnem azzal, amit jobb híján be tudtam szerezni!!!
Viszont:
A K80-asok és a P100 energiahatékonysága és hűtése kihívás lehet, ezért monitorozom a hőmérsékletet (NVIDIA DCGM Exporter) és optimalizálom a terhelést.
A 3D gyorsító kártyák (Pl.: A TESLA K80-asok) beépítése és hűtésének kiépítés jelen pillanatban "sufni-tuning" lesz, költséghatékony, egyedi hűtési megoldásokkal, átépített Rack szerver extra ventilátorokkal, egy szétkapott régi Rack-ből átépítve. A kezdetektől extra hűtésben gondolkoztam! (Valószínűleg erről majd egy külön Cikk is születik, mert nem lesz egyszerű menet!)
---------------------------------------------------------------------------------
Innen pedig akkor a tervezett folytatása a Cikknek:
(Több dolog, amikről írni szerettem volna, felmerült a kérdésekben, így az alábbi rész egészen lerövidült. )
A jelenlegi felállás szerint minden gépen éppen annyi alap rendszer és szolgáltatás lesz csak telepítve, amennyi elkezeli a hardvert, és átadja annak teljesítményét a teljes Cluster felé. Sem több, sem kevesebb. (Így nyilván grafikus felület sem, de remélem, hogy ezt nem kell mondani...) Ez aztán a különböző VM-ek felé osztja azokat ki, megvalósítva, hogy mindig oda ad teljesítményt, ahová az jó és kell.
(Ez persze szépen hangzik és jól, egyszerűnek, de valószínűleg korántsem lesz ennyire az. - Mármint egyszerű...)
Azt sem titkoltam el, hogy többek között tanulni is kívánok ezzel a projekttel, nem csak használni, márpedig az egy "megveszem-bekapcsolom-használom" eszköz-rendszer pároson annyira azért nem valósul meg. 
A tervezett terheléselosztásról pár szóban:
- A Dell XS23-TY3 (128 mag, 768 GB RAM) futattja a Kubernetes control plane-t,
- A SPARC gépek adatbázis-tárolásra, és az API-ok nagyszámú, párhuzamos adatainak feldolgozására szolgálnak,
- A Tesla K80/P100 GPU-kat a Kubernetes NVIDIA GPU Operator osztja ki a konténereknek,
- Minden VM kvótákkal lesz szabályozva. Értelemszerűen mindhez kell egy minimum teljesítmény, hogy sohase álljanak le, és egy maximum is, hogy a többi fontos művelettől se vegyék el soha a szükséges erőforrásokat! Ehhez vegyük hozzá, hogy egy fontossági sorrend beállításával máris tervszerűen üzemeltethető az egész!
- Az AI modellek kizárólag VM-eken futnak, amelyek a Kubernetes scheduler és az NVIDIA GPU Operator segítségével osztják el a terhelést a Dell, más szerverek és a GPU-s gépek között. A VM-ek kvótázása biztosítja, hogy minden modell megkapja a szükséges erőforrásokat, de ne terhelje túl a rendszert.
Tehát akkor sorban: (Legalábbis egyelőre ez a terv.)
- Hardverek tesztelése és firmware-ellenőrzés (Összeírás, összehasonlítás) és szükség esetén FW-cserék,
- Debian 13 alaprendszer telepítése,
- Hálózati konfiguráció (Gépek egymás közti hálózata, és külön hálózaton a Termináláshoz),
- PREEMPT_RT kernel beállítása,
- Kubernetes és Docker telepítése,
- Hálózati konfiguráció (Független, különálló hálózat az Internet eléréséhez!),
- Virtuális gépek (VM-ek) konfigurálása,
- Grafana és Prometheus monitorozás beállítása,
- Automatizált mentési rendszer kiépítése,
- Stressztesztek és teljesítmény mérése,
- AI modellek telepítése és konfigurálása,
- Adatforrások kiterjesztése, és API-feldolgozások beállítása,
- ... ( További ötletek és fejlesztések később következnek. )
Röviden még pár fontos dologról:
Az API lekérdezések (pl. Tőzsdei API-k, Telegram, és Discord csatornák figyelése, Híroldalak figyelése, Stb) WebSocket-ekkel történnek, amelyeket Python konténerekben futtatok (ccxt könyvtár). Az adatokat Adatbázisba mentem valós időben, a PREEMPT_RT kernel pedig biztosítja a <100 µs latencyt.
Ezen lekérdezésekben, és a párhuzamos adatfeldolgozásokban is nagy segítség a SPARC speciális hardvere! (CPU magonként 128 szál: 3 x 2 CPU x 128 szál = 768 szál csak ez a 3 gép.)
A További ötletek közül egy, ami valószínűleg többeteket is érdekli majd: JARVIS
Az Android app (JARVIS) WebSocket-ekkel kommunikál a clusterrel, így valós idejű információkat, adatokat, és eredményeket jelenít meg, illetve a későbbiekben tudok megtárgyalni vele.
A tervek szerint Kotlinban fejlesztem, (vagy idő híján kiadom másnak) Retrofit és Room segítségével, hogy offline is működjön. Legalábbis ez a terv.
A mostani állás szerint ez egy saját igényeimhez igazított modell lesz, ami tulajdonképpen kommunikál majd az összes többivel, összefogja azok működését, illetve a kommunikációt segíti.
A memóriám, jegyzeteim lesz, amolyan komornyik, Concierge féleség, ahogy a névadója is! (Kis tisztelgés Vasember és a filmek előtt, amiknek nagy rajongója vagyok!)
Mostanra eljutottam oda, hogy annyi híroldalt követek, annyi hírlevélre vagyok feliratkozva, annyi minden érdekel, amiről nem szeretnék lemaradni, hogy jól járok, ha ezeket elolvassa helyettem, és összefoglalja a lényeget. Így gyorsabban kiszűrhetőek a felesleges megkeresések, reklámok (amik mindenbe be vannak már ágyazva, időt rabolva a fontos, engem érdeklő dolgok elől...), gyorsan megbeszéljük a dolgokat, elmondja, rá tudok kérdezni arra, ami valóban érdekel, illetve hozza azt a pár dolgot, amit tényleg szívesen olvasnék el.
Így van esélye, hogy semmiről sem maradok le, ami fontos, sem a kutyám, sem a párom névnapja nem marad ünneplés nélkül, nem felejtem el, hogy 8 hónapja milyen remek ajándék ötletet láttam...
..arról nem is beszélve, hogy a munka milyen hatékonyságúvá válik!!!
Mert amikor a termelékenységem nő, akkor annak már igenis anyagi hozama van, (Adott esetben segítve a hardver fejlesztését-vásárlását is!) mindjárt több értelme lesz, mint a hobbi felhasználás.
Több konkrét ötletem van ezeken a területeken is, azonban ez jelen pillanatban erősen üzleti titok!
"Soha ne teremts magadnak sem ellenséget, sem konkurenciát!"
Attól nem félek, ha a későbbiekben valaki lemásolja a dolgokat, így lesz, amikor írok konkrétumokat is!
Azonban könnyen lehetséges, hogy jobb anyagi helyzetből, előnnyel indulva beelőz, majd én lehetetlenedek el. 
Ezt elkerülve lesznek dolgok, amiket nem fogok megosztani, amíg nem működik, illetve nem léptem velük egy bizonyos szint fölé.
Ezek leginkább a felhasználás módját érintik, pont ezért bocsátom előre, hogy ezekről kérdés esetén sem fogok nyilatkozni egy ideig!
Szerintem ezen felül is van bőven téma!
----------------------------------------------------------------------------------
