Sziasztok!
Adott 7 darab 4-8 GB memóriás, 2-4 magos workstation/server gép, sok tárhellyel, ezek közül nem kell mindet felhasználni... :-)
Van lokálisan több, 10+ olyan gép, amit monitorozni kellene, főként Linux: ping, alap linux-os szolgáltatások, tárhely, általános.
Az lenne a cél, hogy minél inkább kiesés nélkül lehessen monitorozni a gépeket, tehát a nagy rendelkezésre állás a szempont.
HA-nál az automatizáltság a prioritás még, hogy magától váltson át a másik gépre, ha az elsődleges monitor szerver megáll. Tehát hogy ne kézzel kelljen átkapcsolni.
Linux alapú, ingyenes megoldást keresek.
2 fő kérdés van:
1. Milyen HA megoldást javasoltok?
2. Milyen monitoring megoldást javasoltok?
A jelenlegi válaszaim, ezekre várnék kritikát, véleményt. Köszönöm.
1. HA:
CentOS 7 Linux, DRBD-n 1 master és 2 slave, majd arra virtualizációval vagy konténerizációval felhúzni a monitorozó gépet, majd valamilyen corosync pacemaker a failover kezelésre. Ha az elsődleges nem elérhető, átveszi egy slave gép a helyét, elindítja a szolgáltatást, felveszi az IP-t, ha szükséges.
Van értelme 3 node-nál többet használni? Csak mert monitoring-ra általában 1-et, néha kettőt szoktak... :-) Ez inkább költői kérdés.
Esetleg valamilyen Xen / Vmware / KVM-es HA megoldás?
2. Monitoring:
OMD (Nagios like), azon belül Check_mk klienseket a kliensekre. OMD-n belül a consol labs féle változatot:
https://labs.consol.de/omd/
Köszönöm az észrevételeket és véleményeket.
Hozzászólások
Elso korben szerintem azokat pontositsd mit ertesz monitoring alatt avagy melyik mennyire fontos:
- ha megall valami szolgaltatas, elfogy a hely stb azt eszrevegye es kuldjon riasztast
- netan ilyen esetekrol fogadjon is eventeket (snmp trap, log alert stb.), ne csak o ellenorizgesse ami alapjan szinten riasztas
- esetleg ne csak riasztas hanem legyen trigger kezeles is, hogy megprobaljon beavatkozni a monitoring
- netan nem(csak) riasztasok kellenek, hanem teljesitmenyekrol visszanemoleges mindenfele grafikon
Az is szempont lehet hogy milyen gyakran kell valtoztatni a konfigon, mert uj gep kerul be, uj szolgaltatas, valtoztatni kell riasztasi kuszobon stb.
Ahogy akar azon is el lehet gondolkozni valoban kell-e HA megoldas, vagy lehet stabilabban kivitelezheto ha 2 (vagy akar 3) aktiv monitoring rendszered fut, persze ez plusz terhelest jelenthet a klienseknek, meg monitoring rendszerek konfig szinkronjat meg kell oldani, illetve ha riasztas van akkor ertesites mehet ki ugyanarrol, de akar ez is lehet egy alternativa.
Amugy en inkabb monitoring os-en belul csinalnek drbd-t vagy gluster szintu megoldast, esetleg ezek nelkul db-ben szinkronizalt megoldassal attol fuggoen milyen monitoringrol lesz szo vegul es nem a hypervisor szintjen.
HA megoldara jo esellyel corosync+pacemaker-t ajanlanek.
3 node-nal tobbet felesleges, hacsak nem szamitasz arra hogy 1-nel tobb is megallhat belole mielott valaki helyreteszi, vagy ha joval tobb gepre szamolsz es teljesitmeny elosztas miatt kellene, de ahhoz kell, hogy tudja vagy megold valahogy a monitoring task-ok elosztasat tobb gep kozott.
A fenti kerdesektol fuggoen en azt mondnam ha egyszeruseg a szempont, ritkan kell konfigolni es riasztasokra kell akkor nagios/icinga, ha teljesitmeny (is) kell akkor munin (melle).
Ha gyakrabban valtozhat, kellhet a csilivilibb kinezet, konnyebb konfiguralhatosag akkor zabbix (cserebe tobb eroforras kell neki es kritikus pontja a db amibol dolgozik).
De sok egyeb is van, egyszeru ellenorzesekre foleg. Ha egzotikusabb dolgokat kell/szeretnel figyelni akkor lehet erdemes abbol kiindulni hogy minek van arra plugin/modul/egyeb megoldasa. Ahogy a konfiguralhatosag, atlathatosag, stabilitas, fancy kinezet es tarsai alapjan lehet mondani jol hangzo uj dolgokat vagy epp faek egyszerusegu betonstabil megoldasokat.
+1. Ha nagyjából elég (és hosszabb távon is megfelel) a "megy/nem megy", "jó/nem jó" szintű figyelés, akkor elég a Nagios-familia valamely tagját felrakni. Itt kell a fájl szintű szinkron (konfig), ezt vagy verziókezelőben tartanám (és a monitoring app indulásakor húzná ki magához), vagy kézzel tartanám szinkronban. A drbd szép meg jó, de a monitoring alá nem tennék plusz egy komponenst, ha nem életbevágóan fontos.
Ha nem elég a nagios (és leszármazottainak) tudása, azaz kell idősoros adatokat, trendeket figyelni, több figyelt paraméter/állapot alapján döntést hozni a riasztásokról, normális grafikonokat összerakni (vérpisálós rrd konfigurálás nélkül), akkor Zabbix (aktív/passzív, faék egyszerűen heartbeat-tel), alá a MariaDB-t meg illendően Galera fürtként összerakva.
+1 a Zabbixnak. Én mondjuk PostgreSQL-en hajtom, de ez vallási kérdés. :)
---
"A megoldásra kell koncentrálni nem a problémára."
Zabbix azert jobb, mert zabbix server es a configja ritkan valtozik, majdnem minden a DBben van.
Ezert kulon lehet szedni a szervert, a db reszt, es a web feluletet.
DB kivetelevel lsyncdvel szinkronizalhatod a configokat. DBbol meg epithetsz clustert.
Erosen ajanlom az history_ tablak particionalasat. Mert ott tortenik az igazi forgalom.
Ez lehet hogy soknak tunik, de az Db clusterek epiteseben szerzett tapasztalat mindig kifizetodo.
+1, azért _is_ jobb :-) A history_ particionálásán túl az internal housekeeping beállításait is érdemes átgondolni, és csak a ténylegesen szükséges adatokat megtartani.
Nekem a particionalassal volt gondom regebben, amikor frissiteni akartam a rendszert, mivel Zabbix alapbol nem tamogatta ezt a megoldast es az update megakadt, mivel a db nem ugy nezett ki mint azt az update script gondolta.
Nalad jelentkezett hasonlo gond?
Udv,
Zsolt
Sajnos odaig nem jutottam el, mert elhagytam a ceget. Pedig tervbe volt veve. A tobb teras adatok folyamatos porszivozast igenyeltek. De most ujra epitek infrat, kiprobalom.
Szia, válaszok:
Ami jó lenne:
- teljesitmenyekrol visszanemoleges mindenfele grafikon
- ha megall valami szolgaltatas, elfogy a hely stb azt eszrevegye es kuldjon riasztast
- a többi amit írtál, bónusz, de nem szükséges
A legkisebb egység, az 1-5 perc közötti, amennyi időnként lenne ellenőrizve.
Új gép / változtatás: havi pár alkalom maximum.
Kell HA megoldás, mert nem új gépek lesznek használva, és fontos, hogy ne legyen adatvesztés, és fontos, hogy minél nagyobb legyen a rendelkezésreállás lehetősége, tehát 3-4 gépből 2 gép kiesés esetén is jó lenne működnie, maximum minimális adatvesztéssel.
Szempont lenne az egyszerűbb üzemeltethetőség és rugalmasság, hogy hardver csere esetén is menjen tovább, ezért gondoltam virtuális gépre, esetleg konténerekre.
A cloud-os megoldás mellett sok minden szól, viszont ellene, hogy ellenőrizze a lokális gépeket, nem szeretném beengedni a monitoring-ot sem. Az is ellene, hogy van több, egész használható szerver erre.
Változatlanul a legnagyobb kérdés a részemről, hogy legyen megoldva a kiesés esetén a váltás, 3-4 gép esetén, hogy automatikus legyen, és a váltáskor ne sérüljön meg a cluster, ha visszajön a kiesett elsődleges. Vagy tudja kezelni, hogy kiesik az elsődleges, másodlagos, és a harmadlagos megy, majd ha visszajön a másodlagos, akkor álljon át arra, majd ha az elsődleges, arra, szinkronban. Ha tudok ilyen megoldásra példa megvalósítást, az szuper lenne.
Ott a Galera Cluster, ami a DB részét elvileg megoldja, csak ott van a szolgáltatások, vagy a virtuális gép kapcsolgatása. Azért tűnik nekem egyszerűbbnek elméletben, ha maximum 1 virtuális gép aktív a 3-4 node-on, és valami megbízhatóan indítja, kezeli ezt, így elméletben.
Nekem DRDB alapon az LXC konténerben futó szolgáltatások már szépen működtek, manuális átkapcsolással, úgy soha nem volt gond, ha kiesett az egyik, hogy újra szinkronba kerüljenek. Ennél szebb és automatikus megoldást szeretnék.
Ha lehet választani, akkor a monitoring üzemeltetés szempontból: "faek egyszerusegu betonstabil megoldas" lenne jó, inkább a feature-k kárára.
Sakk-matt,
KaTT :)
Teljesítményadatokat a legtöbb adatgyűjrő valamilyen time-series DB-ben tárol, de ebből HA...talán az InfluxDB, de az nem ingyen van.
Esetleg gnocchi+swift, de ennek a párosnak a teljesítménye nem egy csúcs, bár talán a te esetedben még elég lehet, viszont konfigurálni sem túl egyszerű.
Zabbix az SQL-ben tárolásával nem tudom, mennyit bír.
A csak monitoring pacemaker+nagiossal tök egyszerű, a pacemaker egy nodeon elindítja a nagiost, és kész. Ha az lehal, elindítja a másikon, se DB, se DRBD nem kell hozzá.
Zabbix sokat bír, CPU-t meg memóriát azért kell alá rakni, meg azért a DB alatt sem jó, ha 5400-as PATA diszkek vannak :-) Százas nagyságrendű, masszívan terhelt webes szolgáltatás alatti géppark, MySQL meg Oracle meg minden appszerverből percenként lehúzott státuszadatok figyelése az akkori átlagos szerver vason simán elkocogott (Zabbix+MySQL). Néhány ezer érték figyelésével.
Azért a Nagios "döglik az egyiken, indítom a másikon" alá valamilyen fájlrendszer szinkron köll, vagy egy 3. gép, amin ott figyel verziókezelőben az összes konfig, és induláskor előbb az aktuális konfigot kihúzza maga alá, ha eléri. Ha nem, akkro riasztást küld, hogy nem érhető el a konfig, és megy az aktuálissal tovább.
Az, hogy a konfig fájljait szinkronban tartod, az alap, de azt intézheted ahogy akarod, konfig managerrel, rsynccel, nfs-en tartod, stb.
Azaz a fájlszintű szinkronnal ugyanúgy beviszed a plusz komponenst a rendszerbe - és azt se felejtsük el, hogy az állapotot is fájlokban tárolja a Nagios család, erho azokat is szinkronizálni (vagy szinkronban izélni) kell, mert ha nem teszed, akkor a billenés után vagy egy régi állapothoz képest fog ellenőrizni a Nagios, vagy ismeretlen állapottal fog minden indulni.
Vagy abban az állapotban, ahol a régin abbahagyta, de ennyit talán be lehet vállalni egy failovernél.
Igen, ez a harmadik lehetőség - ami azóta változott a konfigban az "unknown", ami anno ment, de a borulás idején nem, az fals "rendben" állapotban indul, illetve ha korábban "error" állapotban volt, akkor a borulás után "bepirosodik", amire fölöslegesen rámozdulhat az üzemeltető csapat....
Azt kell csinálni, mint a riasztós távfelügyelet, elvileg csak akkor mozdulnak a problémára, ha 1 percig nem kapcsolom ki a riasztót :)
Használ valaki 2-3 monitoring szervert, egymástól függetlenül, egymás klónjait futtatva, az azonos riasztásokat kizárva?
Sakk-matt,
KaTT :)
Hát én biztos nem. Illetve volt egy időszak, amikor futott egy nagios egy olyan gépen, amin már nem kellett volna, meg azon is, amin kellett. Dupla biztonság :) Amúgy nem, semmi értelme nem volt. Ha lenne olyan monitorozó, amely el tudná osztani a feladatokat több példány közt, na az jó lenne (mint ahogy az OpenStackben is van pár szervíz, amelyek egy külső koordinátor segítségével szét tudják osztani a feladatokat).
Zabbix+Zabbix proxy?
Nem ismerem, de ahogy nézem, itt neked kell szétosztani a feladatokat, mondjuk 1 proxy/site. Ahelyett, hogy indítanál 3 szervert, azok meg elosztják egymás közt automatikusan.
Nálunk egy időben volt ilyen 2 gépes felállás. A DRBD-n voltak az LXC konténerek és Heartbeat figyelt a gépeken.
Kb 3 évig működött és egy esetben volt csak vele probléma: olyan szerencsétlenül esett ki az elsődleges gép, hogy a meleg tartalékra még szinkronizált volna valamit, de nem sikerült és emiatt inkonzisztens maradt az a diszk - így pedig nem lehetett felcsatolni.
Másik tapasztalat a DRBD+LXC kombóval, hogy drasztikusan csökken a sebesség ha sok a fájlművelet (és gondolom a fenti hibába is hamar bele lehet csúszni). Ez 5+ éve volt, azóta persze fejlődhetett valamit a technika.
Erdemes megnezned az icinga2-t.
https://www.icinga.com/docs/icinga2/latest/doc/06-distributed-monitorin…
+1
Icinga2 (nem csak elosztottan, hanem HA-ban is lehet hajtani) + MariaDB + Galera + Grafana/Graphite/PNP
--
A gyors gondolat többet ér, mint a gyors mozdulat.
Nagios familia kölke...
Sziasztok!
https://labs.consol.de/omd/
Igen, az OMD Labs-edition tartalmazza:
Monitoring core:
Nagios
Icinga 2
Naemon
Graphing:
PNP4Nagios
Grafana
Nagflux
Histou
Databases:
MySQL/MariaDB
InfluxDB
Ha Icinga 2 core lesz, ti ezek közül melyiket javasoljátok, az eddigi infók alapján?
Sakk-matt,
KaTT :)
Icinga2+Grafana+Percona
Percona alatt úgy érted, hogy mindenképpen MySQL cluster, tehát 3 node? És a többi node-on mi lenne?
Az Icinga2-nél mi a HA jellegű bevett megoldás, ha a nagy rendelkezésre állás a cél?
Sakk-matt,
KaTT :)
A monitoringnak nem kell magas rendrlkezesre allasunak lennie szerintem, mert ha nem megy, arrol tudnod kell. A magas rendelkezesre allas nem az ilyen eszkozparknal kezdodik, de ezen is lehet ilyeneket tanulni, viszont egy uj szerver nrm valoszinu hogy egyhamar meghibasodik, arra viszont meg kell a garancia.
A monitoring szervernek Zabbixot javaslok vm-ben csak ssd-n. Ekkora parkra nem kell optimalizalni semmit, csak hasznalni.
Ha ilyen cuccok vannak a megoldashoz akkor valamilyen hypervisror + replica megoldast hasznalnek, pl hyper-v free vagy sok mas. Ehhez viszont jo lenne ismerni a teljes infrastrukturat is.
Sziasztok,
Köszönöm mindenkinek a hozzászólásokat, sok hasznosat írtatok.
Én magas rendelkezésre állású monitoringot szeretnék.
Egy fontos infó van, hogy nem új, hanem régebbi gépekből építem majd a monitoringot, ezért is indokolt a 3 gép, mert nem tudni, hogy meddig mennek. Jelenleg mindegyik hibátlan, de nem garanciális minden részük, csak a HDD-k például.
Tehát olyan megoldást keresek, aminél a 3 gépből ha 2 tönkre megy, akkor is megy a szolgáltatás és vissza tudok állni rá. Ezért írtam, hogy lehetne 4-5 gépes is valójában, de ezt elviekben túlzásnak tartom.
Az is felmerült, mint ötlet, hogy lenne 2 gép, mint failover-es monitoring, és 2 gép, mint storage (iSCSI / NFS / DRDB, bármi ), amin mint storage fut, amin vannak a monitoring adatok.
Ésszerűnek tűnne, hogy egy virtuális gépben fusson az egész, mert azt könnyű más hardveren bekapcsolni. Tehát ebben gondolkozom jelenleg.
Az, hogy a HA / failover hogy lesz megoldva, a kérdés, ez egy nagy kérdés még bennem.
Monitoringban hajlok a Zabbix felé, azonban az OMD / Nagios irányt ismerem mélyebben.
OMD esetén meg lehet oldani, hogy adatbázis nélkül, fájlokban megy az egész. Az más, hogy ez mennyire szép vagy jó, de lehet. Üzemeltetni egyszerűbb.
Zabbix hátránya, hogy adatbázis kell hozzá... itt amit használnék: vagy DRBD jellegű megoldással, hogy van 1 aktív, amin fut pld 1 MariaDB, és 2 gép meg szinkronizál, vagy Galera Cluster jellegű, de akkor azokat is külön kezelni kell.
Ezért tűnik nekem jelenleg ésszerűnek, hogy legyen 1 virtuális gépben például Zabbix,
kap 2-4 core-t, 4-6 GB memóriát, amiben benne van a MariaDB is, és kész.
A másik 2 node meg szinkronban van, és ha leáll az elsődleges aktív, a 2. átveszi a helyét, elindul a virtuális gép, vagy a konténer.
Persze a fentiek fényében változatlanul nyitott vagyok újabb, ésszerűbb, logikusabb megoldásra, csak eddig már ilyesmiket csináltam.
Használatról: kb 5 külső, távoli szerver, 5 lokális szerver és 15 lokális desktop gépet kellene monitorozni, ebből a szerverek a fontosak. Főként riasztás szinten, viszont szép és jó lenne terheltségi és egyéb kimutatások, ezért szeretnék HA jellegűt, hogy ne nagyon legyenek nagy kiesések.
Köszönöm még egyszer az eddigi infókat is.
Sakk-matt,
KaTT :)
A mindent csak fájlban tárolni egy ideig elviselhető, utána viszont csak a gond van vele. A drbd lehet valamilyen szinten megoldás, de oda/vissza borogatni, netán 2+ node-on hasnzálni - erősen szuboptimális. Az meg pláne, hogy egy konfig módosítás után újra kell rúgni a monitoringot - egy konfigurációs hiba ezt szépen meg tudja akasztani, és a monitoring máris kiesett arra az időre, amíg javítos a beállítást.
A DB backend szerintem nem hátrány - sőt. Külön lehet skálázni, HA-megoldást rakni alá/fürtbe szervezni, stb.
A "kimutatások" iránti igény gondolom szép grafikonokat is takar - ha igen, akkor vagy megtanulsz rrd-fájlokat natívan írni/olvasni, és a Nagios-hoz hegeszteni mindenféle szépséges rrd-s grafikonokat, vagy goto Zabbix, ahol a vizualizáció alapvetően grafikonokon (szimpla, több adatsor egy grafikonon, több grafikon egy desktop-on, stb.) történik.
Ezzel a monitorozott eszközmennyiséggel ha fogsz két gépet, és azokra raksz OS+Mariadb+Galera fürtöt (szinkronizálás dedikált lábon, a ha már lúd, röfögjön elv alapján), felraksz rá egy-egy Zabbix szervert (DB a 127.0.0.1-en), amit hearbeat billegtet ide-oda egy közös service IP-vel, amin eléred a böngészőből, illetve amin keresztül kimennek a monitoring kérések, és nagyjából ennyi. DB-t szerintem ne vm vagy fájl szinten szinkronizálj, mert egy billenés után bár konzisztens állapotra fogja hozni magát, ha minden jól megy, de a jó ég se tudja, hogy mely tranzakciók mennek a levesbe. (Oké, szinkron replikációval kvázi egyszerre lesz ott az adat mindkét tárolótömbőn, de ez most nem ilyen környezet). Nem véletlen, hogy a komolyabb RDBMS-ek készítői saját HA/fürtözési megoldással rukkoltak elő...
A figyelt node-ok száma alapján nem fog sokat enni a Zabbisz szerver, sem CPU, sem DB szempontból, bár azért attól is függ, hogy node-onként mennyi paramétert szeretnél monitorozni (és hogyan).
Köszönöm.
RRD-vel sokat dolgoztam, egész szép és hasznos grafikonokat hoztam ki, ez a része nem gond.
Alapvetően az egyszerű és megbízható monitoring üzemeltetés lenne a fő szempont, hogy akár 2 gép kiesés után is menjen, majd vissza tudjon állni.
Lehet DB is, ha indokolt, csak eleve HA szinten DB-t üzemeltetni is egy külön kihívás, persze ha ez a legjobb út, hát legyen. Sokszor láttam elhasalt MySQL alapú replikációt, vagy szétesett cluster-t régebben, ezért is próbálom ezt elkerülni, ha lehet.
Tehát lesz 2 gép, rajta:
OS + MariaDB + Galera + Zabbix: ip: .11, .12
Heartbeat billegeti a virtual IP-t, ami .10 .
Heartbeat-et még nem használtam.
Nem lehetne úgy, hogy mindkettő gép virtuális gépben fut, és mondjuk egy harmadik gépre mentődik le az virtuális gép image, ha bármi lenne, akkor legyen friss mentés?
Inkrementális DB mentést nem szeretnék, full dump-ba menteni meg nem tűnik szép megoldásnak, főként több évnyi adat esetén.
Alapvetően 3 virtuális gépes megoldás lenne jó, ami mindhárom egymás tükre, és 2 kiesés esetén is menne az egész. Nem tudom, ezt tudná-e a heartbeat szépen kezelni, és a Galerával sem próbáltam még ilyet. A virtuális gép azért lenne jó, mert menet közben is lehetne menteni. Tudom, a teljesítmény rovására virtualizálok. Nyilván telefonközpontot nem virtualizálnék, ahol fontos az alacsony válaszidő... :-)
Sakk-matt,
KaTT :)
Szerintem ez, így olyan komplikalt lenne és ezeken az eszkozokon annyira instabil, hogy folyamatosan patkolni fogod, hogy menjen.
Inkabb az alatta levő retegeket epidtsd meg redundansan. Pleldaul ovirt + glusterfs amiben tud gutni a vm. Erre a parkra vsan es esxi picit durva lenne meg ha lopod is, mar ha lehet.
Ha a zabbix mellett dontesz, ott ket dologbol lehet csak 1 db, a db szerver ami lehet cluster ami 10 hostra picit eros valamint a zabbix szerver nem ami meg a dbt hasznalja mindenre.
Es mi lenne ha fizetnel egy vm-ert ami felhoben van es belathat a vpn-en a halizatba? Villanyszamla arabol minden kijonne.
Elgondolkoztató...
Milyen VM lehet optimális erre? 1-2 core, 2-4 GB RAM? SSD indokolt? 50 GB hely max?
Akkor kb meg van oldva a backup/HA, elvileg.
Sakk-matt,
KaTT :)
Hat. Nezd meg a zabbix meretezeset, de ha tenyleg csak 10 hostod lesz akkor nem sok, az smart, temp es os adatokkal max 5000 item es 2000 trigger, ami minimalis terheles. 50Gb hdd, 4Gb ram, 2 cpu szerintem boven eleg lesz.
A db miatt a parhuzamos io durva lehet, de raid10 7k lemezekkel sok optimalizacioval 150k item meg jol fut, de ssd-vel jobban. Ha oda ez jo volt, akkor Neked barmi.
Az os es a db is tuleli a ha miatti rebootot.
Meg esetleg a proxmox 5.1 ceph bluestor support miatt szoba johet, de arra ez keves, a gluster annal sporolosabb.
"sok optimalizacioval 150k item meg jol fut"
Érdekelne az a sok optimalizáció.
freeoli,
róbáltam priv-et küldeni, de az üzenet visszapattant. Tudom miért, de az most mindegy.
Ha érdekel, hogy milyen méret és környezet van nálam, és mire vagyok kíváncsi, légy szíves dobj te egy privet. :)
Hátha én is segíthetek neked, nem csak te nekem...
thnx
Ne lopjuk el a show-t a topic nyitótól, mert más téma, más méretek ;)
---
"A megoldásra kell koncentrálni nem a problémára."
Ok. De kene mennie.
Annyit meg ide irnek, hogy a vps / 3 lesz a mysql qps es hasonlo az iops reszeles utan, elotte rosszabb de csak parszor, viszont az iops massziv csucsokat tud generalni, pl a housekeeper futasakor.
250k item es 70k triggerre eleg egy fapad ssd is, mert a seek a halala sok hasonlo terhelesnek, persze, ehhez van 64gb ram is.
A cpu igenye szerintem dobbenetesen alacsony a zabbixnak, ennyire osszese a proxykkal egyutt 8 ghz alatt van a fogyasztasa mindennel egyutt.
Nyugodtan itt is beszélhettek erről, engem, és biztosan mást is érdekel. Ez nem show, és nincs mit ellopni... :-)
Sakk-matt,
KaTT :)
Igazad van.
De a rendszer paraméterei, amiről szó lenne nem nyilvánosak.
Már azzal is a korlátaimat feszegetem ha freeolival privátban megosztok pár részletet.
Amire nyilván szüksége van, ha válaszolni szeretne a kérdése(i)mre... :)
---
"A megoldásra kell koncentrálni nem a problémára."
Proxmox 5.1 + 3? node, az egész monitoring egy KVM-ben. Ez így mennyire tűnik jó megoldásnak? Mi a hátránya? A Proxmox elvileg megoldja a HA-s részt.
Shared storage-ra CEPH (RDB)?
Hány node-ból lehet ezt megúszni megbízhatóan, hogy Proxmox-ban KVM + Proxmox-os Shared storage?
Sakk-matt,
KaTT :)
HA-nak jó, és működni fog.
A ceph pl 3x replika mellett durva io-t csinál a db miatt. A db-t kivenném önálló vasra, a többi mehet. Persze a 10 host mellett szerintem a db-t is elbírja.
A ceph-nek sok kicsi lemezt adj, ne kevés nagyot. Persze ha választhatsz. :-)
---
"A megoldásra kell koncentrálni nem a problémára."
Köszönöm, ki fog derülni, hogy működik.
Sakk-matt,
KaTT :)
fogsz két gépet, és azokra raksz OS+Mariadb+Galera fürtöt
Emlékezetem szerint a Galera azt mondja, hogy két node nem cluster. Ha az egyik node-ot szabályosan leállítod, akkor az tudja értesíteni a másik node-ot, ezért az tovább fog működni - de szabálytalan leállás esetén megáll, mint a szög, mert nem tudja eldönteni, hogy mi történt a párjával? Fejre állt vagy csak nem elérhető? De a split-brain tuti biztos elkerülése érdekében inkább nem hajlandó semmit sem csinálni, minthogy baj legyen. Tehát ha Galera, akkor minimum három gépet fogsz - ellenkező esetben nem redundáns a cluster.
Ott a pont, a két node-os móka tényleg nem Galera volt.
Galera-tól függetlenül általában kimondható, hogy a cluster node-jainak megfelelő számossága 3+2n alakú.
---
"A megoldásra kell koncentrálni nem a problémára."
Milenne, ha a mindenféle mesterséges félintelligenciát tartalmazó "HA-megoldás" hákkhegyek inkább a fullosan párhuzamos működés keretében megvalósított riasztás-deduplikáció mellett döntenétek?
Mint a prometheus + alertmanager kombó?
Ilyet még nem láttam élesben. Tehát van 2, egymástól független monitor szerver, és egy harmadik szerver kezeli, hogy ne jöjjön duplikálva az üzenet? Mi van, ha az egyik leáll? Szól a másik, hogy nem megy az egyik monitor szerver?
Ilyen esetben ugyanazzal a monitor konfiggal megy az egész?
Nem gond a dupla terhelés a klienseken?
Sakk-matt,
KaTT :)