Futtat valaki Home Assistant kubernetesben, illetve ha igen az Add-On-okkal mi a helyzet ?
Hozzászólások
Sima docker containerben futtatom, de csak magat core-t es akkor nincs Add-On (ha jol tudom). HACS-t es azon keresztul mindenfele integraciot hasznalok (mqtt, tasmota, fronius/huawei solar, stb). Mire kell az Add-On?
Mire jo a magas rendelkezesre allas HA eseten? Ha otthon vagyok akkor eleg gyorsan eszreveszem ha nem mukodik, amikor meg nem vagyok otthon akkor annyira nem erdekel (amig mas nem szol miatta, utana eletbe lep az elso pont).
Irhattam volna, hogy mire jo a HA a HA eseten :D
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Nekem speciel eleg fontos. Az ingatlan ahol hasznalom, ott a berlok es egyeb felhasznalok ezzel tudjak nyitni a parkolo kaput, bejarati ajtot nyitni, futest/hutes kapcsolni, riasztot kezelni, stb.
Idáig csak méláztam rajta, de pl zigbee az 1 darab kordinátorral tud csak menni, ehhez tényleg nem érdemes, de kipróbáltam a thread-et. Ezt már magas rendelkezésre álláshoz tervezték, ugyhogy körülnéztem a neten, nem sok mindent találtam.
A "matter over thread" szenzorokhoz, ügyes kütyükhöz matter add-on kell. A homeassistant ahogy látom konténerben fut, az add-onok is, elvileg mehetne kubernetesbe, akár 3 db málna pc-vel, de gondoltam ne nulláról induljak.
Látok egy két kezdeményezést, az ad-onokról nem nyilatkoznak.
Szerintem overkill a többpéldányos futtatás. Több komplexitást és hibalehetőséget hozol be mint ahányszor valójában hsználni fogod.
Én odáig mentem el hogy ha megrohad akkor újraindul (docker container).
Van napi mentés, ha hardveres megrohadás van akkor a tegnapi állapot visszahozható pillanatok alatt.
Jó minőségű alkatrészek vannak, sd kártyát ki kell hagyni.
Ha évente áll egy napot az még bőven jó SLA (de nem áll annyit se).
Aminek ennél jobb SLA kell azt meg kell oldani HA-függetlenül.
A replikáció csak addig jó megoldás amíg stateless (vagy nagyjából stateless) tudsz lenni.
Amint elkezdesz "állapotgépet építeni" véged van...
Attól függ, hogy mi az, ami nem működik HA nélkül, és mennyi kényelmetleséget vagy hajlandó bevállalni (vagyis inkább tipikusan mennyire türelmes az, akivel együtt élsz :D). 3 RPI még nem olyan veszettül drága, ráadásul ha valakinek amúgy is van mondjuk napeleme, és hozzá egy akksi pakk (hogy tudja tárolni az extra termelés), akkor egész sok failure esetet le lehet fedni. Főleg ha amúgy is ért hozzá és szívesen foglalkozik vele...
Az megvan, hogy HA készre szerelt még nem magas rendelkezésre állás.
Ja, az megvan, csak nem tudom mennyire akarsz magas rendelkezesre allast. Lesz dupla internet kapcsolat, dupla tapegyseg, UPS es generator is? Mert az sem magas rendelkezesre allas ha elmegy az aram vagy az internet a kubernetes alol. Ha csak az a lenyeg, hogy legyen egy supervisor ami indit egy kontenert ha leallna a jelenlegi arra akar eleg egy cronjob is ami havonta/hetente/stb. ujrainditja :)
Bocs, hogy nem teljesen a temaban szolok hozza, csak nem vilagos pontosan hogyan kepzeled el a HA HA-t.
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
3 málna pc, ahhoz adnak 3 tápot, esetleg kis ups, internet ha nincs éppen ,akkor nincs távoli elérés, de ettől még megy minden. Ha elmegy az áram a lakásban , akkor szünet.
Zigbee Zwawe nem jó, - mivel Single point of Failure -ök, az egy kordinátor miatt. Helyette thread, thread border routerekkel, pontosabban ezek gatewayek , ipv4 -el , border routerek egy preferált hálózatban, illetve egy LAN -on a málnákkal , thread egy network key alatt. A replikák száma 1 , vagyis csak 1 HA példány futna. Ha egy málna elszáll, indul Home assistant példánya másik málnán.
Hát, nem nagyon láttam még olyan High Availability megoldást, amihez nem kellett quorum a korrekt implementációhoz. Nyilván nem a Home Assistantot akarod 3 példányban futtatni, hanem pl a K8s mastert.
Elméletileg ez mind megoldható k8s-szel. Nyilván arra kell figyelned, hogy a Persistent Volume-ok is redundánsak legyenek, nem teheted meg, hogy egyszerűen a RPI-ben lévő SD kártyát bemappeled a konténerbe. Egy sima Deploymentként kell kezelned, egy instance-szal, aztán ha egy node megpusztul, akkor a Deployment fog neked csinálni még 1 pod-ot.
Amire figyelned kell, hogy a HA IP címe nem lesz állandó, tehát nem tudod közvetlenül megcímezni, hacsak nem csinálsz valami DNS-es megoldást, vagy floating IP-t, vagy valami hasonlót, hogy elérd a HA-t. Nyilván ennek mind redundánsnak kell lennie, hogy legyen értelme a HA-nak a HA esetében is.
Köszi, ilyesmi miatt érdekelt a tapasztalat. Neten vannak fenn Helm chartok, van amelyik pár órás karbantartású, illetve egyet találtam amelyikben van egy code-server HA addon is. Az ip-t az metall lb load balancerrel , layer 2, lebegő IP-vel. Illetve ReadWriteMany persistent storage, replica 1, De HA megy mysql-lel,
ott is lehet variálni, mariadb , mysql is ad sql routert. (MySQL Router 8.0)
Persze, tehetsz rendes DB-t is alá, de ha amúgy nincs, akkor én nem tenném, szinte mindegy, hogy a DB-nek a high availability-jét oldod meg, vagy a HA alatti storage-nak. Én biztos Ceph-fel próbálkoznék (valószínüleg a rook k8s operatorral), mert azt már használtam, nem hiszem, hogy gond lenne vele akár ha a raspeberryn hostolod. Van ahhoz is mindenféle guide a neten:
Ja igen, amit legutóbb rosszul írtam, hogy nem is Deployment kell neked, hanem StatefulSet, hogy a pod-ok alatt mindig ugyanaz a PV legyen. Itt nincs szükséged ReadWriteMany-re, mert mindig egy pod-nak kell lennie egyszerre, ha több van, azok összeakadnatnak.
A lényeg hogy minden komponenst ami használsz úgy kell összeraknod, hogy ne okozzon gondot, ha bármelyik node kiesik. Igazából elég egyszerű tesztelni: egyszerűen egyesével lelövöd raspberry-ket, és ha minden megy tovább akkor jó (úgy értve, hogy lehet egy rövid (<1min) leállás, de újra elérhetővé kell mindennek válnia magától). Azután visszakapcsolod, és jöhet a következő. Ha végigmentél mind a 3-mon, és nem volt gond, akkor kész vagy.
Ha ez gond, akkor azt az egy patch kábelt egy másik switchbe csatlakoztatod, ha ez igény(3 málna 3 switch, ide még talán 100 -as switchek is elegek) . Miért kellene kettő interfész a málnára ? Egy ip van a a Home assistanthoz , a Home Assistant meg megy valamelyik gépen, szerintem mindegy melyiken. Router nem kell.Internet nem kell.
Mert ha nincs, akkor ha s2 hal meg, akkor szétesik az egész. Na most, ha valami buta szart összekábelezel, akkor majd vagy jó lesz, amit a spanning tree csinál, vagy nem :) És hát ha még más eszköz is van, ami kábeles, akkor tovább bonyolodik a helyzet.
Ezt ált úgy szokták, hogy van két switch, azok között is van két kábel LACPvel, és minden host 2 kábellel van felkötve, egyik egyik switchbe, másik másikba, aztán ezek között is LACP (vagy legalábbis valami bonding van), így minden fizikailag redundáns, nincs az, hogy egy host félig van leszakadva a hálóról, de közben megy.
Ha mindharom rpi-t egy switchbe dugsz, akkor egyszerre szakad le mind. Ha van 3 switched es egymas utan kotod oket egy nagy L2-be, akkor a kozepso switch halala eseten a ket szelso rpi se fogja latni egymast.
Akkor lesz igazan redundans a halozatod, ha ket switched van, az rpi-nek 2 nic-je kell legyen, amit egy-egy kabellal bekotsz. LACP-vel pedig osszefogod a ket portot.
De mindez nyilvan overkill egy otthonautomatizaciohoz.
Ja , most esett le, az LACP miatt legyen a két utp. Iinkább a szervereknél kritikus, k8s szerintem más logika , talán nem annyira kritikus, de igen kettő a tuti, viszont "eldobható" gépek, ha leáll egy , bármi okból csere. Nem kell raid se, fölösleges . 3 gép a határ , ha van 10 vasad, 3 leáll, jövő hónapban ha arra jársz kicseréled. 12 gép 3 db 4-es switchben, 1 switch leáll marad 8 gép.
De igen a switchek hibahelyek. Bár most az lobog a zászlón, hogy switch nem kritikus, de a végén még megdumáltok. :-).
SPF-es switch 3. Ennyi, routert ne hozza szóba senki.
Ha van olyan automatizacio, amihez a mobilok lokacioja szukseges (a mobilos app idonkent elkuldi a lokaciot), akkor bizony a routingra is szukseg van. Es akkor mar bejon az ISP, mint SPOF is.
Szóval redundáns LACP , dupla patch kábel, 3 fázis, aggregátor, földelőrendszer, villámvédelem, , biztonsági ajtó, örség.
Hát igen, de mit adtak nekünk a rómaiak .... :-) https://www.youtube.com/watch?v=J2Bx19qJ_Vs
Köszi, ezeken écsak méláztam, neten van karbantartott Helm, azt is majd megnézegetem, napokban majd kipróbálom, de nem málnán.
Storage: jiva-openebs esetleg, de majd meglátjuk, nincs elképzelés még, cehp-et még nem próbáltam: https://i.imgur.com/RhBtCr4.png
Illetve nem is annyira a "mire jó?" a kérdés, hanem hogy mennyiben maga a HA a kritikus ebből a szempontból? Nálam merülnek a Zigbee cuccok elemei, szakadt már le Sonoff a WiFi-ről, de maga a HA még nem állt meg (frissítésen kívül) soha, amíg villany van a gépe alatt.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Ez igy van, egy kis itx lehet hogy sose romlik el, de ha 100 -ból csak 3 romlik el, akkor gondoskodnod kell róla hogy abból a 3 darabból ne te vásároljál.
3 fázis: ha akarsz 99 %-os BIZTOS rendelkezésre állást, az egy x ár, de ahogy teszed a 99. mögé a 9-eseket úgy nő a költsége a rendelkezésre állásnak , ráadásul nem lineárisan, hanem exponenciálisan. Ezt neked kell tudni , mi az ami kell. Ha van egy tartalék géped, amiről időnként van mentés ,teljesen jó. Bemész a kamrába és kicseréled a kis gépet.
Ha 3 különálló épület, nyaraló más városokban, van 200+ végpontod, megint más A matter/thread kitűzte a zászlóra ,és megcélozta a több ezer endpontból, szenzorból álló épületkezelő rendszert, illteve az ipart. Ahogy olvasom a nyilatkozataikat, ("matter thread lesz a kapu , a többiek rések ezen a kapun") nem hogy megcélozta, hanem mainstreamnek akarja magát. Na jó, ezt majd meglátjuk.
A HB-ról tudok nyilatkozni, ott a cél a semi-reduntant, azaz ha egyik node elszáll, akkor a többi még tudja vinni a házat. Pl ha a fűtés elmegy, akkor a világítás még maradjon. Illetve ha frissítés történik akkor a vezérlés maradjon meg: azaz ha a frissítés valamiért hibára futna, akkor ne álljon az egész, hanem az adott node mehessen vissza korábbi verzióra. Addig a többi node meg tartja a frontot.
Matter/thread pároas ezt segíti, más már mint zigbee , zwave. Fizikailag távol lévő hálózatokat is egy thraed hálózatba kötheted, szegmentálhatod pl a házózati id (networkkey) alapján) ipv6-os , tehát meglévő (IPV6-os) halózatot használni tudja.Ha leáll egy border router átveszi a helyét egy másik, ha az is leáll, egy router kinevezheti magát border routerré, egy endpoint routerré stb. Amig egy szenzorhoz lehetséges route, úgy alakitja magát a hálózat, hogy működö képes marad.
Illetve egy matter végpont több kezelő rendszerbe is beköthető, nem csak egybe, mint idáig.
Azért ez elég megnézősnek hangzik, erősen függ imho a mindenféle eszközöktől is, hogy ne legyen zagyvaság a vége. Nekem pl van olyan integrációm (klíma), amit ha bekapcskor épp nem volt HA (jellemzően a klíma előbb tér magához, mint a HA), akkor onnan sose fog menni, míg seggbe nem rúgom a klienst, ez pl szerintem lehet nem bírna egy random billentést.
Ha nem olyat választasz, hogy mindig csak egy pod fut, akkor azért meg kell nézni pl az összes multicastos cuccot, mert ott simán lehetnek mindenféle duplikátumok, de egy mqttnél is mengézném azért, hogy biztosan nem duplikál semmi a pub/subon, mennyire lesz a másik pod ugyanaz a kliens/másik kliens.
Köszi , pont ezért kérdeztem a tapasztalatokat ne nulláról kelljen kezdeni, (van egy pár helm chart) de igazából nem is a mostani iot-s cuccok érdekelnek, inkább majd a thread,ha lesz belőle egyáltalán valami. Ha a polcodon ott egy málna, kihúzod kicseréled es megy tovább minden ,pár perc ha van mentésed, de nem erre gondolok. Nagyobb ,több helyen ,lakásban külön épületekben lévő , thread közös hálózat messze egymástól a szenzorcsoportok (kilométerekre) , ha leáll egy "border router" (gatewaynek is mondhatnám) , akkor átveszi a helyét egy másik, ha mind leáll akkor "feléled" egy , pontosabban szerepkört vált valamelyik . Egy közös thread hálózatban, és te is messze vagy fizikailag.
A thread pdig ezt már most tudja, nincs benne SPOF. A hass pedig nem tudja.
4 féle telepítési modja van, kellene egy ötödik.
Hozzászólások
Sima docker containerben futtatom, de csak magat core-t es akkor nincs Add-On (ha jol tudom). HACS-t es azon keresztul mindenfele integraciot hasznalok (mqtt, tasmota, fronius/huawei solar, stb). Mire kell az Add-On?
Mire jo a magas rendelkezesre allas HA eseten? Ha otthon vagyok akkor eleg gyorsan eszreveszem ha nem mukodik, amikor meg nem vagyok otthon akkor annyira nem erdekel (amig mas nem szol miatta, utana eletbe lep az elso pont).
Irhattam volna, hogy mire jo a HA a HA eseten :D
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Nekem speciel eleg fontos. Az ingatlan ahol hasznalom, ott a berlok es egyeb felhasznalok ezzel tudjak nyitni a parkolo kaput, bejarati ajtot nyitni, futest/hutes kapcsolni, riasztot kezelni, stb.
Idáig csak méláztam rajta, de pl zigbee az 1 darab kordinátorral tud csak menni, ehhez tényleg nem érdemes, de kipróbáltam a thread-et. Ezt már magas rendelkezésre álláshoz tervezték, ugyhogy körülnéztem a neten, nem sok mindent találtam.
A "matter over thread" szenzorokhoz, ügyes kütyükhöz matter add-on kell. A homeassistant ahogy látom konténerben fut, az add-onok is, elvileg mehetne kubernetesbe, akár 3 db málna pc-vel, de gondoltam ne nulláról induljak.
Látok egy két kezdeményezést, az ad-onokról nem nyilatkoznak.
https://github.com/pajikos/home-assistant-helm-chart
https://blog.claryel.hu
Szerintem overkill a többpéldányos futtatás. Több komplexitást és hibalehetőséget hozol be mint ahányszor valójában hsználni fogod.
Én odáig mentem el hogy ha megrohad akkor újraindul (docker container).
Van napi mentés, ha hardveres megrohadás van akkor a tegnapi állapot visszahozható pillanatok alatt.
Jó minőségű alkatrészek vannak, sd kártyát ki kell hagyni.
Ha évente áll egy napot az még bőven jó SLA (de nem áll annyit se).
Aminek ennél jobb SLA kell azt meg kell oldani HA-függetlenül.
A replikáció csak addig jó megoldás amíg stateless (vagy nagyjából stateless) tudsz lenni.
Amint elkezdesz "állapotgépet építeni" véged van...
Gábriel Ákos
Attól függ, hogy mi az, ami nem működik HA nélkül, és mennyi kényelmetleséget vagy hajlandó bevállalni (vagyis inkább tipikusan mennyire türelmes az, akivel együtt élsz :D). 3 RPI még nem olyan veszettül drága, ráadásul ha valakinek amúgy is van mondjuk napeleme, és hozzá egy akksi pakk (hogy tudja tárolni az extra termelés), akkor egész sok failure esetet le lehet fedni. Főleg ha amúgy is ért hozzá és szívesen foglalkozik vele...
Ha "mission critical" es penzt keresel vele akkor miert nem veszel egy HA Green vagy HA Yellow keszre szerelt cuccot?
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Az megvan, hogy HA készre szerelt még nem magas rendelkezésre állás.
https://blog.claryel.hu
Ja, az megvan, csak nem tudom mennyire akarsz magas rendelkezesre allast. Lesz dupla internet kapcsolat, dupla tapegyseg, UPS es generator is? Mert az sem magas rendelkezesre allas ha elmegy az aram vagy az internet a kubernetes alol. Ha csak az a lenyeg, hogy legyen egy supervisor ami indit egy kontenert ha leallna a jelenlegi arra akar eleg egy cronjob is ami havonta/hetente/stb. ujrainditja :)
Bocs, hogy nem teljesen a temaban szolok hozza, csak nem vilagos pontosan hogyan kepzeled el a HA HA-t.
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
3 málna pc, ahhoz adnak 3 tápot, esetleg kis ups, internet ha nincs éppen ,akkor nincs távoli elérés, de ettől még megy minden. Ha elmegy az áram a lakásban , akkor szünet.
Zigbee Zwawe nem jó, - mivel Single point of Failure -ök, az egy kordinátor miatt. Helyette thread, thread border routerekkel, pontosabban ezek gatewayek , ipv4 -el , border routerek egy preferált hálózatban, illetve egy LAN -on a málnákkal , thread egy network key alatt. A replikák száma 1 , vagyis csak 1 HA példány futna. Ha egy málna elszáll, indul Home assistant példánya másik málnán.
https://blog.claryel.hu
A 3 málnás gépet három külön fázisra kötöd?
Domain, tárhely és webes megoldások: aWh
Miért három? Csak nem még quorumot is akarsz?
Gábriel Ákos
Hát, nem nagyon láttam még olyan High Availability megoldást, amihez nem kellett quorum a korrekt implementációhoz. Nyilván nem a Home Assistantot akarod 3 példányban futtatni, hanem pl a K8s mastert.
Indul a másik málnán. Melyik állapotból?
Gábriel Ákos
Elméletileg ez mind megoldható k8s-szel. Nyilván arra kell figyelned, hogy a Persistent Volume-ok is redundánsak legyenek, nem teheted meg, hogy egyszerűen a RPI-ben lévő SD kártyát bemappeled a konténerbe. Egy sima Deploymentként kell kezelned, egy instance-szal, aztán ha egy node megpusztul, akkor a Deployment fog neked csinálni még 1 pod-ot.
Amire figyelned kell, hogy a HA IP címe nem lesz állandó, tehát nem tudod közvetlenül megcímezni, hacsak nem csinálsz valami DNS-es megoldást, vagy floating IP-t, vagy valami hasonlót, hogy elérd a HA-t. Nyilván ennek mind redundánsnak kell lennie, hogy legyen értelme a HA-nak a HA esetében is.
Köszi, ilyesmi miatt érdekelt a tapasztalat. Neten vannak fenn Helm chartok, van amelyik pár órás karbantartású, illetve egyet találtam amelyikben van egy code-server HA addon is. Az ip-t az metall lb load balancerrel , layer 2, lebegő IP-vel. Illetve ReadWriteMany persistent storage, replica 1, De HA megy mysql-lel,
ott is lehet variálni, mariadb , mysql is ad sql routert. (MySQL Router 8.0)
https://blog.claryel.hu
Persze, tehetsz rendes DB-t is alá, de ha amúgy nincs, akkor én nem tenném, szinte mindegy, hogy a DB-nek a high availability-jét oldod meg, vagy a HA alatti storage-nak. Én biztos Ceph-fel próbálkoznék (valószínüleg a rook k8s operatorral), mert azt már használtam, nem hiszem, hogy gond lenne vele akár ha a raspeberryn hostolod. Van ahhoz is mindenféle guide a neten:
https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberrypi-4-clust… (ez simán cephadm-mel, k8s nélkül)
https://medium.com/@monofuel34089/renegade-cluster-ba179061463a (ez már rookkal)
Ja igen, amit legutóbb rosszul írtam, hogy nem is Deployment kell neked, hanem StatefulSet, hogy a pod-ok alatt mindig ugyanaz a PV legyen. Itt nincs szükséged ReadWriteMany-re, mert mindig egy pod-nak kell lennie egyszerre, ha több van, azok összeakadnatnak.
A lényeg hogy minden komponenst ami használsz úgy kell összeraknod, hogy ne okozzon gondot, ha bármelyik node kiesik. Igazából elég egyszerű tesztelni: egyszerűen egyesével lelövöd raspberry-ket, és ha minden megy tovább akkor jó (úgy értve, hogy lehet egy rövid (<1min) leállás, de újra elérhetővé kell mindennek válnia magától). Azután visszakapcsolod, és jöhet a következő. Ha végigmentél mind a 3-mon, és nem volt gond, akkor kész vagy.
Es akkor jon az, hogy mi van akkor ha az egy szem switch/router hal meg.
rpi-nek egy eth csatlakozoja van, egy USB-s csatolora is szukseg lesz a masodik interface-hez. Vagy esetleg a Wifi a masodik.
Szoval erosen bonyolodik a dolog.
Ha ez gond, akkor azt az egy patch kábelt egy másik switchbe csatlakoztatod, ha ez igény(3 málna 3 switch, ide még talán 100 -as switchek is elegek) . Miért kellene kettő interfész a málnára ? Egy ip van a a Home assistanthoz , a Home Assistant meg megy valamelyik gépen, szerintem mindegy melyiken. Router nem kell.Internet nem kell.
https://blog.claryel.hu
Mert a switch SPOF. Ha tényleg magas rendelkezésre állást akarsz, akkor két switch kell.
Az ok, ha az egyik switch elromlik, de itt az van hogy két interface legyen a málnának. De minek, elég egy, egy eth kabel oszt jónapot.
https://blog.claryel.hu
Ja, hogy három switchet írtál, elnézést, az esetben valóban működhet.
Persze ugye olyankor az van, hogy simán csak sorba kötni nem elég, kell egy kör:
Mert ha nincs, akkor ha s2 hal meg, akkor szétesik az egész. Na most, ha valami buta szart összekábelezel, akkor majd vagy jó lesz, amit a spanning tree csinál, vagy nem :) És hát ha még más eszköz is van, ami kábeles, akkor tovább bonyolodik a helyzet.
Ezt ált úgy szokták, hogy van két switch, azok között is van két kábel LACPvel, és minden host 2 kábellel van felkötve, egyik egyik switchbe, másik másikba, aztán ezek között is LACP (vagy legalábbis valami bonding van), így minden fizikailag redundáns, nincs az, hogy egy host félig van leszakadva a hálóról, de közben megy.
Mert egy kabelt csak egy switchbe lehet bedugni.
Ha mindharom rpi-t egy switchbe dugsz, akkor egyszerre szakad le mind. Ha van 3 switched es egymas utan kotod oket egy nagy L2-be, akkor a kozepso switch halala eseten a ket szelso rpi se fogja latni egymast.
Akkor lesz igazan redundans a halozatod, ha ket switched van, az rpi-nek 2 nic-je kell legyen, amit egy-egy kabellal bekotsz. LACP-vel pedig osszefogod a ket portot.
De mindez nyilvan overkill egy otthonautomatizaciohoz.
Ja , most esett le, az LACP miatt legyen a két utp. Iinkább a szervereknél kritikus, k8s szerintem más logika , talán nem annyira kritikus, de igen kettő a tuti, viszont "eldobható" gépek, ha leáll egy , bármi okból csere. Nem kell raid se, fölösleges . 3 gép a határ , ha van 10 vasad, 3 leáll, jövő hónapban ha arra jársz kicseréled. 12 gép 3 db 4-es switchben, 1 switch leáll marad 8 gép.
De igen a switchek hibahelyek. Bár most az lobog a zászlón, hogy switch nem kritikus, de a végén még megdumáltok. :-).
SPF-es switch 3. Ennyi, routert ne hozza szóba senki.
https://blog.claryel.hu
Ha van olyan automatizacio, amihez a mobilok lokacioja szukseges (a mobilos app idonkent elkuldi a lokaciot), akkor bizony a routingra is szukseg van. Es akkor mar bejon az ISP, mint SPOF is.
Szóval redundáns LACP , dupla patch kábel, 3 fázis, aggregátor, földelőrendszer, villámvédelem, , biztonsági ajtó, örség.
Hát igen, de mit adtak nekünk a rómaiak .... :-)
https://www.youtube.com/watch?v=J2Bx19qJ_Vs
https://blog.claryel.hu
Köszi, ezeken écsak méláztam, neten van karbantartott Helm, azt is majd megnézegetem, napokban majd kipróbálom, de nem málnán.
Storage: jiva-openebs esetleg, de majd meglátjuk, nincs elképzelés még, cehp-et még nem próbáltam:
https://i.imgur.com/RhBtCr4.png
https://blog.claryel.hu
Persze, OpenEBS is jó, én csak azért említettem a Ceph-et, mert azt ismerem.
Reggel meg kivilágosodik, idáig 100 %-os rendelkezésre állással, úgyhogy kár tökölni az oktondi kapcsolókkal. . :-)
https://blog.claryel.hu
Ja, ja, minek beszívni a levegőt, ha úgy is kifújod. Ugye.
Illetve nem is annyira a "mire jó?" a kérdés, hanem hogy mennyiben maga a HA a kritikus ebből a szempontból? Nálam merülnek a Zigbee cuccok elemei, szakadt már le Sonoff a WiFi-ről, de maga a HA még nem állt meg (frissítésen kívül) soha, amíg villany van a gépe alatt.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Ez igy van, egy kis itx lehet hogy sose romlik el, de ha 100 -ból csak 3 romlik el, akkor gondoskodnod kell róla hogy abból a 3 darabból ne te vásároljál.
3 fázis: ha akarsz 99 %-os BIZTOS rendelkezésre állást, az egy x ár, de ahogy teszed a 99. mögé a 9-eseket úgy nő a költsége a rendelkezésre állásnak , ráadásul nem lineárisan, hanem exponenciálisan. Ezt neked kell tudni , mi az ami kell. Ha van egy tartalék géped, amiről időnként van mentés ,teljesen jó. Bemész a kamrába és kicseréled a kis gépet.
Ha 3 különálló épület, nyaraló más városokban, van 200+ végpontod, megint más A matter/thread kitűzte a zászlóra ,és megcélozta a több ezer endpontból, szenzorból álló épületkezelő rendszert, illteve az ipart. Ahogy olvasom a nyilatkozataikat, ("matter thread lesz a kapu , a többiek rések ezen a kapun") nem hogy megcélozta, hanem mainstreamnek akarja magát. Na jó, ezt majd meglátjuk.
https://blog.claryel.hu
A HB-ról tudok nyilatkozni, ott a cél a semi-reduntant, azaz ha egyik node elszáll, akkor a többi még tudja vinni a házat. Pl ha a fűtés elmegy, akkor a világítás még maradjon. Illetve ha frissítés történik akkor a vezérlés maradjon meg: azaz ha a frissítés valamiért hibára futna, akkor ne álljon az egész, hanem az adott node mehessen vissza korábbi verzióra. Addig a többi node meg tartja a frontot.
Matter/thread pároas ezt segíti, más már mint zigbee , zwave. Fizikailag távol lévő hálózatokat is egy thraed hálózatba kötheted, szegmentálhatod pl a házózati id (networkkey) alapján) ipv6-os , tehát meglévő (IPV6-os) halózatot használni tudja.Ha leáll egy border router átveszi a helyét egy másik, ha az is leáll, egy router kinevezheti magát border routerré, egy endpoint routerré stb. Amig egy szenzorhoz lehetséges route, úgy alakitja magát a hálózat, hogy működö képes marad.
Illetve egy matter végpont több kezelő rendszerbe is beköthető, nem csak egybe, mint idáig.
https://blog.claryel.hu
Azért ez elég megnézősnek hangzik, erősen függ imho a mindenféle eszközöktől is, hogy ne legyen zagyvaság a vége. Nekem pl van olyan integrációm (klíma), amit ha bekapcskor épp nem volt HA (jellemzően a klíma előbb tér magához, mint a HA), akkor onnan sose fog menni, míg seggbe nem rúgom a klienst, ez pl szerintem lehet nem bírna egy random billentést.
Ha nem olyat választasz, hogy mindig csak egy pod fut, akkor azért meg kell nézni pl az összes multicastos cuccot, mert ott simán lehetnek mindenféle duplikátumok, de egy mqttnél is mengézném azért, hogy biztosan nem duplikál semmi a pub/subon, mennyire lesz a másik pod ugyanaz a kliens/másik kliens.
Köszi , pont ezért kérdeztem a tapasztalatokat ne nulláról kelljen kezdeni, (van egy pár helm chart) de igazából nem is a mostani iot-s cuccok érdekelnek, inkább majd a thread,ha lesz belőle egyáltalán valami. Ha a polcodon ott egy málna, kihúzod kicseréled es megy tovább minden ,pár perc ha van mentésed, de nem erre gondolok. Nagyobb ,több helyen ,lakásban külön épületekben lévő , thread közös hálózat messze egymástól a szenzorcsoportok (kilométerekre) , ha leáll egy "border router" (gatewaynek is mondhatnám) , akkor átveszi a helyét egy másik, ha mind leáll akkor "feléled" egy , pontosabban szerepkört vált valamelyik . Egy közös thread hálózatban, és te is messze vagy fizikailag.
A thread pdig ezt már most tudja, nincs benne SPOF. A hass pedig nem tudja.
4 féle telepítési modja van, kellene egy ötödik.
https://blog.claryel.hu