A néhai Log Insight – újkori nevén a Aria Operations for Logs – véleményem szerint a VMware legegyszerűbb, ugyanakkor legjobb termékei közé tartozik. Amit tud, azt jól tudja és nem kell a mélyére ásni, hogy elő is tudjuk csalogatni azokat. Nem újdonság, hogy a feladata a naplózás, a naplók gyűjtése és feldolgozása.
Természetéből adódóan azonban fontos redundáns módon megépíteni, hiszen ha pont akkor nem tud naplót fogadni és megjeleníteni számunkra, mikor kellene, akkor az egész nem ér semmit. Egy ilyen rendszer kiépítése nagyon egyszerű feladat, meg is mutatom mindjárt a mikéntjét, de nem szabad elmenni a következő megértése mellett.
Hiába van több Aria Operations for Logs appliance egy klaszterben, a logok tárolása nem redundáns. A feldolgozásuk az!
Tehát naplózok 100MB-ot, azt nem több példányban fogja tárolni a klaszter, hanem csak az egyik appliance-on. Csak annyit jelent, hogy a feldolgozást, a felületet és alapvetően a működést nem érinti egy appliance elvesztése, habár az elérhetetlen logok, természetesen elérhetetlenek is maradnak.
Továbbá maga a klaszter lehetősége még nem jelenti azt, hogy georedundáns mód támogatott. Olyan tehát nincs, hogy a több node más-más hálózatban, sem olyan, hogy stretched módon tudnának működni.
vRealize Log Insight does not support WAN clustering. Current versions of vRealize Log Insight do not support WAN clustering (also called geo-clustering, high-availability clustering, or remote clustering). All nodes in the cluster should be deployed in the same Layer 2 LAN.
https://docs.vmware.com/en/vRealize-Log-Insight/8.10/com.vmware.log-insight.administration.doc/GUID-9DCD851E-4A31-4FB1-9B05-62D981E1F749.html
Mi kell hozzá?
Ha teljesül az alábbi fár feltétel, akkor hibátlanul fog működni:
- legalább három egyforma méretű – javasolt a legalább medium (8 vCPU, 16GB RAM jelenleg) – appliance.
- négy darab IP-cím – azonos L2 ugye.
- négy darab DNS bejegyzés – nálam li1, li2, li3 és li.
- licenszek – licensz nélkül klaszter nem lehet.
- ha van NSX DFW akkor exlude listára tenni mindet.
- NTP!!
Lehet persze több node is, akár 18 darab is elképzelhető, de az egyszerre elveszhető appliance-ok száma 7-től felfelé már nem emelkedik.
Elmondható tehát, hogy ad redundanciát, de ami talán még lényegesebb, hogy feldolgozási kapacitást növel – illetve is növel – ami nem elhanyagolható. A logok mennyiségét általában a napi kapacitásban és EPS-ben szokták kifejezni és bizony egy small 30GB/2000 EPS-t, egy medium 75GB/5000 EPS-t, egy large pedig 225GB/15000 EPS-t tud. Ha tehát van egy klaszterem, amiben három medium node van és én egy elveszése mellett is szereném a 12000 EPS-t péládul, akkor négy ilyen node kell vagy esetleg választhatom a három large node-ot is, de az erősen túlnő. Az appliance-ok száma tehát az skálázhatóság elsődleges eszköze, ami sokszor az egyetlen is, ha a log forrása nem tud több helyre is logot küldeni.
Implementáció
A gyártótól érkező OVA-t három példányban telepítjük fel és az alapvető beállítás igazából az elsőn történik meg majd.
Első node – li1.demo.lab
Nálam ez a li1.demo.lab. Sok dologra nem is lehet kattintani csak a „Next” gombra.
Ez az a pont ahol az első és a többi – nálam másik kettő – telepítése eltér, mivel az elsőnél nyilván még nincs meglévő környezet, tehát itt most a „Start new deployment”-et kell kiválasztani.
Az admin felhasználóhoz tartozó e-mail beírása és a kívánt jelszó megadását kell elvégezni.
Be kell adni a kulcsot, ami a licenszünk. Ezt nem mutatom meg természetesen.
Megkérdezni, hogy a CEIP-ben részt kívánunk-e venni, illetve hogy értesítéseket alapértelmezetten hová küldjön.
Majd az NTP beállításokat kell elvégezni. Ez a lépés sokszor simán átugrásra kerül, de mint minden klaszternek, így ennek is iszonyatosan lényeges a pontos idő, ami ráadásul minden node-on azonosan jár.
Következő lépésben az SMTP-t kell felkonfigurálni, már ha persze szeretnénk levélben kapni riasztásokat, értesítéseket.
Aztán pedig az SSL-t lehet feltölteni, hogy ne az önaláírt és nem megbízható üzenet fogadjon minden alkalommal.
A végére is ér a varázsló, el is indul minden, használható a Log Insight.
Második és harmadik node – li2.demo.lab és li3.demo.lab
Mindkettőnél azonosan kell eljárni, ezért vonom egybe. Itt már inkább a „join existing deployment”-et illik választani.
Sokat nem is kérdez csak az első – primary – node FQDN-jét. OK nyomása után a SSL-t el kell fogadni.
Ahogyan alább is mutatja, egy kérést küld a primary appliance-nak, amit az egyetlen kattintható linken látni is fogunk, mivel átdob az elsődleges appliance felületére.
Az elsődleges appliance felületén tényleg látszik a kérés, amit el kell fogadni.
Ezen a ponton létre is jön maga a klaszter és fel is dobja a még szükséges dolgokat.
Az is jelzi, hogy két node-os klaszter tényleg nem támogatott. Tehát ha a harmadik node-on is elvégezzük a fenti lépéseket, akkor a következő lesz látható.
Kész van a klaszter, de közös IP-n még nem hallgat, pedig a redundancia miatt azt kellene megadni mint cél IP, minden rendszeren amit ide szeretnénk naplózni. Fel kell tehát venni egy – vagy akár több – virtuális IP-t is.
A Save gomb kiválasztása után azonnal el is kezd válaszolni az IP-n. Látható fent a Tags mező, aminek használata erősen javasolt, nagyban segíthet, ha keresni kell vagy tovább gyúrnánk a logokat. Megadom például hogy a VIP tag, VIP1 értékkel legyen benne. Tehát minden napló ami majd erre az IP-re érkezik, szürhető lesz ezzel a tag-el is. Ha több ilyen közös IP-t veszünk fel, akkor például különbséget tehetünk már itt aközött, hogy hová érkeznek – melyik IP-re – a vCenter logok – és például egy másikra a tartományvezérlők logjai.
Küldjünk naplókat
Az első forrásom a vCenter Server lesz, illetve az abban lévő ESXi kiszolgálók. A beállítás végtelenül egyszerű és bár elvégezhető lenne a vCenter felületéről is, de sokkal célravezetőbb azt a Log Insight-ból csinálni. Mielőtt beállítjuk nézzük meg mit tud a termék. Léteznek hozzá agent-ek is, amelyek Windows/Linux-ra telepítve akárhonnan képesek logot elhozni, illetve van a normál syslog is, amin keresztül tényleg bármi beköthető.
A vCenter illesztése nyilván a vCenter FQDN/IP-jét, a felhasználó és jelszó megadását követeli meg. A két kis pipa a kép jobb oldalán lehetővé teszi a vCenter-ben is látható event/task/alarm-ok (EAT) beküldését is, illetve a másik esetén magukat az ESXi-k syslog célját is beállítja a kívánt protocol mentén. Ha csak pár hoszton szeretnénk ezt megtenni, akkor azt mutatja be az alábbi kép. Nem elhanyagolható, hogy a target mezőben még azt is meg lehet adni, hogy melyik VIP-re vagy akár a primary node-ra történjen a logok irányítása. Nyilván itt a VIP-et érdemes megadni vagy kis túlzással értelmetlen volt, akkor egynél több appliance-ot telepíteni.
A bemutatóra használt rendszeremben teljesen világos, hogy nem generálódik irdatlan mennyiségű napló. Ha meg szeretnénk nézni, hogy hol tart teljesítményében a klaszter és az egyes node-ok, akkor az áttekinthetően meg is található a GUI-n. Itt már látható az aktuális és historikus EPS is. per node akár.
Hogy lehet mégis redundánsan tárolni a naplókat?
Ha telepítünk még egy Log Insight klasztert vagy akár csak egy node-ot, akkor a fenti klaszterből vagy minden vagy csak a kivíánt naplókat tovább lehet küldeni abba. Ezt a témát érintettem egy korábbi bejegyzésben.
A következő részben megnézzük, hogyan lehet saját dashboard-okat, riasztásokat és widget-eket létrehozni.
