Linux alapú HA cluster

 ( csearo | 2018. március 2., péntek - 11:09 )

Sziasztok,

egy J2EE-s projekthez szükségünk lenne egy nagy rendelkezésre állású, kereskedelmi Linux alapú klaszterre.

Tudtok olyan magyarországi céget ajánlani, ami ezzel foglalkozik?

Köszi előre is!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

ULX? Rehdat Cluster?

ULX: jó lehet, köszi!
Redhat Cluster: ezt is köszi, gondolom, valami ilyesmit szeretnénk :)
:wq

ajánlom magamat :)
--
Gábriel Ákos

Beszéljünk. Nekem is kéne clusteres segítség. Milyen konstrukcióban tudsz ilyet vállalni?

hehe, csak 1 éves a reakcióm :)
küldj pm-et a részletekkel.
--
Gábriel Ákos

2018-ban OS klaszter új fejlesztésű projekt alá? Biztos erre van szükséged?

Helyette mit ajánlanál?

Erre felkeszitett alkalmazast.
A kovetkezo problema altalaban a skalazodas. Sokszor kez a kezben jarnak.

Bocs, azt hittem, már megint egy felhőmániás ;)

Yep, szívemből szóltál

A több node-os paralel működésre felkészített app az alap szerintem, utána "csak" a terhelést kell jól szétszórni, illetve szükség esetén a dolgozó node-okat odanöveszteni a többi mellé :-)

+1
Akkor elmeletben megoldottuk a problemat.

Az az alap. De arra még mindig nem láttam választ, hogy az OS helyett mit ajánlana a kolléga?

Bár, azt sem írta, hogy on-premise kell neki, vagy felhőben is jó.
Mert onnantól, hogy tud skálázódni rendesen, már édesmindegy, hogy OS vagy AWS van alatta.

Vagy lemaradtam valamiről?

Bocs a félreérthető OS miatt. Azt hittem a szövegkörnyezetből kiderül hogy oprendszer.
OpenStack más réteg lenne mint amit a post-oló kérdez.
OpenShift meg pláne :D

Ah, én helyből openshitre gondoltam.
Azért is említettem párban az aws-el, ahol meg asg-től kezdve mindenféle van.
Kicsit másképp gondolkodnak a redundanciáról.

HP?

Én is ajánlom magamat, mint Ákos :) (Dolgoztunk már együtt is... ;) )

A HA nem egyszerű dolog, főként az alkalmazás rétegen múlik, jellemzően nem az OS-en. Jól felépített HA alkalmazás esetén az OS nem is kell, hogy részt vegyen a HA működésben, viszont a rendszer minden komponensét fel kell készíteni a HA működésre, failoverre.

Jó hír a JavaEE tudja ezt, alkalmazás szerver és DB függően.

+1 Az alkalmazás mindenképp úgy kell összerakni, hogy képes legyen több node-on párhuzamosan futva helyesen működni, utána már "csak" a terhelést kell jól elosztva rájuk tolni.

Meg biztosítani, hogy a DB se legyen SPOF.
Meg a hálózati eszközök se.
Meg ha van valami külső szolgáltatásfüggőség, akkor az se. Vicces, amikor 365*24-gyel számolnak egy szolgáltatást, miközben egy-két külső (értsd: semmi ráhatás) adatforrás 2-4-hetente kiesik a hétvégén 24-48 órára.

Pontosan.

Sőt, van ahol oda kell figyelni a "zero downtime maintanence"-re, "zero downtime upgrade"-re ami különösen pilótavizsgás, ha az alkalmazás rétegnél nem gondoltak erre, akkor tulajdonképpen lehetetlen.

Hol?
Az a hup-on keresi a szolgaltatot es a technologiat?

:) nem hinnéd el miket láttam már. Simán lehet, hogy olyan döntés előkészítésben részt vevő, akit megbíztak, hogy nézzen utána és minősítsen beszállítókat általa kitalált szempontrendszer alapján.

Ha HA, akkor egy szakemberben több kérdés merül fel, mint válasz. Első és legnagyobb kérdés az elvárt rendelkezésre állás mértéke: a tizedespont utáni kilencesek száma nagyon nem mindegy, exponenciálisan növeli a költségeket beszerzési és üzemeltetési oldalon egyaránt. A zero downtime upgrade, zero downtime deployment, zero downtime maintenance ugyanilyen kérdés.

Bizd ide, majd en eldontontom, h elhiszem-e:)
Szoval hol van zero downtime akarmi?

Bármilyen helyen, ahol folyamatos tranzakció áramlás vagy folyamatos adatfolyam van, ami nem eshet ki.
Vagy olyan rendszer esetén, ahol a rendszer kiesése több veszteséget termel, mint a HA kialakításának költsége.
Vagy olyan rendszer esetén, ahol az adat kiemelten fontos emberélet megőrzési szempontból (pl. kórházi rendszer) vagy biztonsági szempontból.
Vagy olyan rendszer esetén, ahol valamilyen előírás, törvényi megfelelés miatt ez kötelező.

- banki rendszerek ami a fizetéshez kötődik ( kártya rendszer, átutalási rendszer)
- folyamatosan üzemelő logisztikai rendszerek
- repüléshez kapcsolódó kiszolgáló rendszerek, reptéri rendszerek
- bizonyos államigazgatási rendszerek
- egészségügyi rendszerek
- nagy forgalmú, publikus oldalak
- telekommunikáció

Ez tankönyvbe illő megfogalmazás :) Esetleg onnan van?
Államigazgatás, egészségügy? Zero downtime? Zero upgrade max!

Bocs, semmi gond azzal, amit írsz, csak jártam már mindegyik területen, és így reggel durván felröhögtem :)

:) saját megfogalmazás, bár tankönyvet nem írtam, tananyagot már sokat.

Ha mindegyik területen dolgoztál akkor pontosan tudod, hogy mindenhol van olyan feladat, részterület, ahol cél lehet a zero downtime. Persze a zero downtime-ot teljesen elérni lehetetlen, de megközelíthető, minimalizálni kell a kockázatokat és a maintenance ablakot. pl. egy banki kártya rendszer esetében, ahol persze nincs tragédia, ha leállsz egy fél órára, de már ügyfél panaszaid lesznek.

Vagy pl. meg kellett tervezni és implementálni azt a rendszert, ami összeköti a német Lufthansa repülési rendszerét a Virgin Ausztráliával. Konkrétan tök eltérő időzóna, nem tudsz üres ablakkal tervezni, tranzakció nem veszhet el, nem duplikálódhat (exactly once delivery megvan?).

Vagy nem kicsi szállítmányozó cég teljes operációt felügyelő rendszere, folyamatos üzem, 3 műszak, éjjel sem eshet ki, mert rögtön szabad szemmel látható pénzösszegű a büntetés. Még egyszer: logisztikai cégről beszélek, nem emberélet múlott rajta.

Vagy egy külföldi mobilszolgáltató egyik szolgáltatása, amelyik persze kieshet, de jellemzően éjjel/nappal üzemel és használják.

Vagy mondjuk az OEP központi vény ellenőrző rendszere, ahol éjjel is van nyitva ügyeletes patika pl. (Ákos... :) )

Még egyszer. A felsorolt területeken nem minden rendszer ilyen, de mindenhol tapasztaltam már olyan feladatot, ahol ez cél lehet. Halkan jegyzem meg: ha bármelyik vezető elkezdi komolyan venni... :)

Értem amit mondasz. Én is ezzel foglalkozom :) Könyveket lehetne írni ezekről a dolgokról. De attól még a valóság néha szájbabasz. OEP esetén pl. lehetsz bármekkora zseni a kis szigeteden, de ha teszel hátra két lépést, és megnézed, mi van, akkor felröhögsz. :)

Nagy álmom, hogy egyszer csak public cloud alapon dolgozhassak végre... valaki? :)

Azért nem csak az OEP-nél röhögsz fel (kínodban...), ha teszel hátra két lépést, és úgy nézel rá a dolgokra... De ilyen ez a popszakma, minél bonyolultabb egy rendszer, minél több funkció van egybesűrítve, annál nehezebb ténylegesen hibatűrőre megcsinálni. A felhő az a buzzwordbingoban előkelő helyen áll nálam - nem saját mondás, hogy felhő nincs, csak másnak a számítógépe, de ezt nagyon igaznak tartom (gyakorlatilag kettőt hátralépve nézve a felhőt rögtön látszik is...)

+nagyonsok

A felhő/konténer mágia hype most jellemzően csak arra jó, hogy letold magadról a felelősséget. Majd a felhő futtató környezete megoldja. Aztán ha nem, akkor meg marad a pingvinezés.

Nagyon sokszor tapasztaltam már, hogy amikor egy problémát nem láttak át, nem értettek, nem érdekelte őket, akkor jöttek az alábbi tipikus válaszok:

- majd az oracle (adatbázis kezelő neve szabadon kicserélhető) megoldja
- majd az AWS (felhő szolgáltató neve szabadon kicserélhető) megoldja

díjnyertesek:
- a mi alkalmazásunk stateless, ezért nálunk ez nem probléma...
- mi web service-eket használunk, ezért nálunk ez nem probléma...

Ha elkezdi az ember felrajzolni a rendelkezésre állási függőségeket, adott esetben igen hamar eljut oda, hogy nem lehet bizonyos dolgokat házilag megoldani, vagy végtelen erőforrásba és pénzbe kerülne, ezért nem érdemes belekezdeni sem.

Nem, nem tartozom azok közé, akik felhúznak egy VM-et EC2-n, és várják a csodát :)

> letold magadról a felelősséget

Valoban, igy is fel lehet fogni:)

Zero downtime engem is erdekelne, hogy hogyan érhető el.
Mondjuk egy olyan rendszernél, ahol a klienseknek mindig a legfrissebb állapottal kell dolgozniuk, hogy lehet olyan rdbms upgrade-et végezni, ami az adatbázis szerkezetét is módosítja? (Oracle-nek voltak ilyenjei, nem tudom, mára ez mennyire változott)

1. Legfontosabb: az alkalmazást fel kell készíteni a HA működésre! Tesztelni kell a failovert.

2. Az adatbázist proxy-n, HA enabled connection pool-on kersztül éred el

3. Az adatbáziskezelő valamilyen streaming replication-t használ, de bonyolultabb esetben lehet sharding is.

https://www.slideshare.net/outlyer/zero-downtime-postgres-upgrades

Vagy lehet olyan alternatív architektúrát is tervezni, ahol egy szerver nyugodtan elfüstölhet adatbázis-kezelőstől, mindenestől...

És mit csinálsz, ha major postgres verziót kell frissítened? Mert a fenti link csak minor verziónál működik. :)

Ez egy jó kérdés.

Ha postgres specifikusan beszélgetünk akkor új feature a logical replication, ami már működni fog eltérő major verziók között. Vagy marad a Slony, ami tudja a különböző major verziók egyidejű kezelését.

Vagy ilyenkor marad a tervezett, minimalizált leállás, mint opció.

Vagy ha a leállás nem opció, akkor az architektúrát úgy kell összeállítani, hogy a teljes rendszer ne függjön a relációs adatbázis kiesésétől (pl. CQRS+Event Sourcing patternnel).

Sajnos csak oracle-lel volt dolgom ilyen szinten, azzal is régen. Akkoriban az okozott rémálmokat, hogy a kliens oldalnak mindig a legfrissebb adatot kellett szolgáltatni.
Az nem ment, hogy snapshotból kiszolgálni, mert jó neki a tiz perccel korábbi állapot.
Az egyéb szoftverekkel nem volt gond, de az adatbázis és a MQ esetében inkább leáll, upgrade, újraindít volt az eljárás.
Egy atomerőmű esetében elképzelni sem tudom ugyanezt... :)

Zero downtime bankoknal nincs. Legalabbis nekem az ellenkezoje a tapasztalatom, bejelentett downtime van es a konzisztencia fontosabb es csokolom.
Mondjuk sosem dolgoztam banknal, lehet a mogottesben van ilyen.

Allamigazgatas? Melyiknel kell zero downtime?
Nagy forgalmu oldalak? Meg a google sem teljesiti.
Telekommunikacio? Persze, amikor elvagjak a kabelt es megszunek egy megyeben a szolgaltatas. Rohog a vakbelem.

A tobbinel is a valosag hozzavetoleges.
Szoval en inkabb konkret peldakat vartam.

Viszont tovabbra is tartom, h tok bullshit idehozni a zero downtime-ot, amikor jon az atlaghupper, h wtf.
A szelsosegeken kivul vannak egyeb igenyek is.

:) Megvenném az önbizalmad felét ha eladó.

"Zero downtime bankoknal nincs. Legalabbis nekem az ellenkezoje a tapasztalatom, bejelentett downtime van es a konzisztencia fontosabb es csokolom.
Mondjuk sosem dolgoztam banknal, lehet a mogottesben van ilyen."

Az idézett utolsó sorért külön virtuális pacsi!
Zero downtime bankoknál most fog kelleni csak igazán. Baromi elavult rendszerekkel dolgoznak - hivatalosan ezt úgy mondjuk, hogy konzervatívan választják ki beszerzés során a rendszereiket - és hát szépen elment mellettük az élet.

"Államigazgatás" -> EKÁER?, Ügyfélkapu?, NAV?
"Nagy forgalmu oldalak? Meg a google sem teljesiti." -> nálam a Google nem esett ki az utolsó 10 évben, a Microsoft Azure, mint cloud szolgáltató viszont többször. De csináltam már olyan publikus oldalt ahol követelmény volt az aktív/aktív cluster, session replikációval.
"Telekommunikacio? Persze, amikor elvagjak a kabelt es megszunek egy megyeben a szolgaltatas. Rohog a vakbelem." -> :) Majd szólok a Telekomnak, hogy megtaláltad a költségcsökkentés szent grálját. Nem kell failover, nem kell SLA. Tök fölösleges. Röhögjünk együtt!

A tobbinel is a valosag hozzavetoleges.
Szoval en inkabb konkret peldakat vartam. Viszont tovabbra is tartom, h tok bullshit idehozni a zero downtime-ot, amikor jon az atlaghupper, h wtf. A szelsosegeken kivul vannak egyeb igenyek is.

Nincs olyan, hogy átlaghupper. Megdöbbennél egy két általam ismert HUP alias milyen rendszereket épít vagy üzemeltet az itteni felhasználók közül. Jellemzően ők a legszerényebbek.
Itt a kolléga kérdezett valamit, arra igyekeztem informatívan válaszolni: az alkalmazáson múlik a legtöbb minden, minimális dolog az OS-en vagy a konténeren. A zero downtime meg zero akármi csak mellékszálként jött föl, mint tisztázandó kérdés, hogy kell-e a feladathoz. Mondhatod, hogy bullshit, szíved joga, legtöbbször nem kell. Én eddig a 30-35 projektemből 3-4 projekten láttam olyat, ahol valósan, indokoltan igény volt az ennek megfelelően magas SLA. Ott is előfordulhat leállás, de igyekeznek elkerülni. Egyébként konkrét példákat írtam, nézd vissza. Volt olyan rendszer ahol óránként 1 000 000 Ft-nak megfelelő volt a kötbér leállások esetén. Ott már megremeg az ember keze minden változtatásnál.

Engedelmeddel az ügyfeleimnek hivatkoznék a te hozzászólásodra, hogy amit kérnek az úgy baromság ahogy van, hiszen te megmondtad. :)

> Az idézett utolsó sorért külön virtuális pacsi!

Pacsi v. nem, plz konkretumokat.
Addig humbug. Most kerem harmadszor:)

Hol kell pontosan, milyen celra _zero_ downtime? Mit jelent a zero?

> "Államigazgatás" -> EKÁER?, Ügyfélkapu?, NAV?

Ilyen felsorolasokat en is tudok.
Vegyuk pl. a nav-ot. Mit ernek pl. azzal, ha csinalnak egy zero downtime rendszert? Talan az online szamlazasra gondolhatsz. Feltetelezem, ott is egy queue-ba kerul a stuff es a feldolgozo rendszernek nem kell zero downtime-nak lennie. Ott is lenyegesebb, a konzisztencia. En legalabbis nem latom, jelenleg mit nyernenek vele.
Egy queue rendszert pedig nem nagy cucc osszehozni zero-ra. De ha olyan a protokoll, akkor akar kliens oldalon is varakozhatnak a szamlak, mert miet ne.

> nálam a Google nem esett ki az utolsó 10 évben

Nalam igen.
Ok maguk sem allitjak magukrol a zerot. Sot, konkretan arra hajtanak, h ha tul jol teljesitenek, akkor felhasznaljak a rendszelkezesre allo ido a fejlesztesektesztelesere, ami magaval fogja hozni a downtime-ot.

> De csináltam már olyan publikus oldalt ahol követelmény volt az aktív/aktív cluster, session replikációval.

Elhiszem. A kerdes arra vonatkozik, hol van ertelme.
Csinaltam en is HA clustert, ahol azert volt olyan, mert a megrendelo azt gondolta, attol tobb penze lesz. Sosem hozta be az arat.

> Nem kell failover, nem kell SLA.

Kibujt a szog a zsakbol.
Kevered a zero downtime-ot az SLA-val meg a failover-rel.

> Engedelmeddel az ügyfeleimnek hivatkoznék a te hozzászólásodra, hogy amit kérnek az úgy baromság ahogy van, hiszen te megmondtad. :)

Kerlek. Kuldd az ugyfeleidet hozzam. Csinaljunk egy kockazat- es koltsegelemzest es majd kiderul:)
Elhiszem neked a kotbert es hogy k. fasza csavo vagy (oszinten, barmi szarkazmus nelkul), viszont nem tudok szo nelkul elmenni, amikor vki orditva szelsosegeket kialt.
Ebbol jon aztan, amikor a (relativ) tapasztalatlan megrendelo v. epp sysadmin (ld. feltehetoleg OP) tisztara azt hiszi, h az o rendszere zero downtime nelkul egy zero.
Amellett sem tudok elmenni, amikor az igenyek felmerese nelkul vki megmondja, h mi a helyes es igaz ut.
Total teveszme.

t

ui.: Egyetertek, h az alkalmazasnak kell(ene) tamogatnia.

Nézd én szívesen beszélgetek értelmes emberekkel ilyen témában, mert kiegészítjük egymást.
De olvasd is el amit írok, lehetőleg értelmezd is, ne csak write only módban szólj hozzá, mert ennek így nem látom értelmét. Nem kiáltok ordítva szélsőségeket pl.

Már az első kérdésedre is leírtam, hol lenne/lehet értelme a zero downtime-nak:
- banki rendszerek ami a fizetéshez kötődik ( kártya rendszer, átutalási rendszer)

Több banknál éppen az a probléma, hogy a követelmény megjelent, de elkenték. Először a kártyás rendszereknél volt igény a folyamatos üzem, de a banki rendszer "történelmi okokból" hétköznap este nyit és reggel zár. Kártyával meg éjjel is, hétvégén is akarnak fizetni. Ahogy már fentebb is írtam: nem tragédia, ha egy éjjeli tervezett maintenance ablakot nyitnak pl. upgrade miatt, de nem elegáns, biztosan lesz 1-2 panasz. Az igény megjelent, és pont úgy oldották meg, ahogy sugalltad is: belefér az SLA-ba, leállunk valamikor éjjel. Most viszont a fizetési rendszerek, főként az azonnali fizetés kapcsán már a szabályzat is nagyon magas SLA-t követel, úgy is mondhatnám, hogy a szabályzás implicit megköveteli a zero downtime-ot a fizetési rendszereknél (ezt is írtam már: ha bármelyik felső vezető komolyan venné a követelményeket). Csakhogy ezt végig kellene vinni egészen a core rendszerekig. Itt viszont mivel a bankok nem nagyon haladtak az idővel az elmúlt 20 évben, szépen rájuk dőlnek az elavult legacy rendszerek.

Nem, nem arról beszélek, hogy az SLA betartása mellett leállunk. Az egy végső kiskapu, ha nagyon szükséges. Arról beszélek, hogy a rendszer külső szemlélő számára folyamatosan üzemel, közben upgradelünk, verziót cserélünk.

Bankban elvileg indokolt lehetne a zero downtime, gyakorlatban én még nem találkoztam vele.
Netbankon te is láthatod, de amikor kiszálltam, akkor még a swift és a visa is kénytelen volt eltűrni egy-egy leállást és nehezen tudom elképzelni, hogy ez sokat változott volna.

Kártyás tranzakcióknál az authorizációnak, mint szolgáltatásnak kell zero downtime, hogy ezt a banki rendszer, vagy tervezett leállása alatt a giro csinálja, az a szolgáltatás rendelkezésre állása szempontjából mindegy - tervezetten van lehetőség leállásra, akár komplett hétvégére is.

Amikor meg a boltokban "technikai okok miatt a kártyás fizetés szünetel"... :)
Újabban a giro authorizál? Én le voltam maradva a visa központnál...

A bolti "technikai ok" az esetek 9x%-ában a POS kommunikációs vonala szakadt/Mancika véletlenül kirúgta a tápot a konnektorból/elfogyott a papír/főnök azt mondta, hogy készpénz kell/stb. jellegű, nem banki oldalon fennálló problémából adódik.
Az egyenlegedet a kártyaszolgáltató nem ismeri, ergo nem is tudja rámondani, hogy "mehet", megkérdezi a banktól, vagy valaki mástól, hogy "van neki annyi egyenlege"? Az meg válaszol, hogy van, vagy épp azt, hogy nincs.

Félreértesz: nem arról beszéleky mikor egy-egy üzletben áll a kártya, hanem amikor fél Budapesten állt :)
(Jó, ez ritka, de volt rá példa)

Az egyenleg hogy jön ide? Változott az authorizáció menete?
Javíts ki,ha rosszul tudom/elavult: én úgy tudtam, hogy x összeghatárig a VISA(én ezen a néven ismertem a kártyaközpontot) jogosult volt megadni az engedélyt akkor is, ha a bank nem volt elérhető. Hogy ilyen esetekben ki viselte az esetleges fedezetlen vásárlások okozta kárt, azt nem tudom.

Az ilyen nagyobb területet érintő leállás, illetve minden kiesés a teljes rendszer (POS-termináltól elindulva a számlavezető rendszerig bezárólag) olyan elemének a hibájára vezethető vissza, aminek nincs tartaléka. Ez lehet akár egy izmosabb távközlési kábel elvágása/ellopása is (lásd Távíró u. melletti kiserdőben történt kábellopás 10 évvel ezelőtt), amit bár lehetne tartalékkal/kerülő iránnyal redundáns útvonallal hibatűrőbbé tenni, de ha enneka a költsége magasabb, mint a várható kárérték (a bekövetkezés valószinűségével súlyozva), ergo nem kap tartalék útvonalat.
Bár láttam én olyat, hogy a 2x64kilobites bérelt vonali kapcsolat (ami úgy lett igényelve, hogy egymás tartalékaként funkcionálnak) egy érpáronesett be a pécsi rendezőbe...

Az, hogy a kártyatársaság jogosult-e most is engedélyezni valameddig, azt nem tudom, a banki authorizációs rendszer helyett (megfelelő adatok átadásával) a giro is tud authorizálni - például akkor, amikor a banki rendszer frissül, vagy épp átalakulnak/összeolvadnak, és nem megy a számlavezető rendszer mondjuk péntek napzárástól a hétfői nyitásig...

O.K., csak példának hoztam, hogy ott sincs meg a zero, akkor meg miről beszélünk? :)

Az authorizációs _szolgáltatás_ katasztrófahelyzettől eltekintve erősen megcélozza a "zero downtime" elérését, és jellemzően tudja is (Nem is olcsó eszközökkel/megoldásokkal operálnak, az is igaz...). A kártyás vásárlás, mint lehetőség bár erre a szolgáltatásra épül, de közel sem zero downtime, mert ott a rendelkezésreállásnál fontosabb a költség - redundáns, külön nyomvonalon haladó, másik szolgáltatótól vett adatkapcsolat az elfogadóhelyek döntő részénél (nagyon) nem érné meg, ráadásul a "külön nyomvonalon" kitételnek megfelelni... Nagyon nem triviális.

Ha kellően nagy szeletét nézzük a világnak, akkor semmi sem zero downtime :-) Ha olyan kicsit, hogy ráfogható, akkor azzal meg nem biztos, hogy érünk valamit :-D

> nem elegáns

Bocs, en itt kiszalltam.

nem lehet hogy ugyanazon a projekten dolgozunk ? :)
--
Gábriel Ákos

Volt már rá példa, most szerintem nem. :)

Kubernetes?

Virtualizacio + kontenerek.
HA sztem felejtos, mondom ezt ugy h 10+ evig foglalkoztam vele. Heartbeat over rs232 meg ismeros valakinek? :)

sajnos beleégett

Fajo emlekeim vannak ilyenekrol... :(

Hát ezt megúsztam... VMS-en kicsit más volt a cluster, amit utána HPUX-on kellett tornáztatni, az meg... de az RS232-es heartbeat, na az durva :)

Miért lenne durva...? Normálisan a soros vonalon érkező jelcsomag (nem ip, nem ppp, raw) a kernelben egy számlálót piszkál.

Mert hányezer éves?

2000 környékén még ez ment :)
Sőt, asszem 2004-ben építettük az utolsó 2 node clustert Heartbeat alapokon, ott még erősen RS232 volt a kommunikáció.
Nem volt az semmivel sem rosszabb egyébként mint a mostani megoldások, az ethernettől független, elég stabil megoldás volt.
Nyilván a 2 node-os clusterek már akkor is szükségmegoldások voltak, nem győzöm azóta sem eleget hangoztatni h. 2 gép az nem cluster.

Úgy két évvel azelőtt, hogy kiszálltam a buliból (IT), még tanfolyamon emlegették. (Tán épp Zahy? Vagy valaki más...)

Kétgépes clusterrel mi a gond? Megfelelően kiválasztott quorum diszkkel simán mentek. Jó, egy VMS Cluster kicsit komolyabb volt, mint amit unixoktól láttam, de azóta sokat változott a világ.

Az oké h. megfelelő quorum diszk, de a qdisk sem volt egy sikerstory :)
http://people.redhat.com/ccaulfie/docs/Votequorum_Intro.pdf

Ráadásul: "I have touched on quorum device above but not mentioned it at all otherwise. With all of the above new options it's hoped that most installations will no longer need qdiskd to get the functionality they need from the cluster, and thus life should be a lot simpler. For those few poor souls that do need to use qdiskd still, err ... it's not there yet! Sorry." :)

Ez már sok nekem (az angol) :)
Röviden: worked for me.
Először hsc, hsd, hsj diszket használtunk erre, jött az optika, hsg és utána... a vms szép lassan kihalt. :(

Nálam meg mindig maradt az a tervezési filozófia h. legyen egy olyan node a rendszerben, amelyik nem tud ugyan erőforrásokat kezelni, de "szavazata" van. A node-ok közötti linkek legyenek minimum 2 fizikai tyúkbélen megoldva, ez lehet lacp, lehet bármi, de redundáns legyen.
Innen már csak a fejlesztőket kell ütni h. "cluster aware" legyen az az app, amit futtatni akarunk a csillió node-on. Namost a hősidőkben azért ezt nem volt olyan könnyű megoldani, főleg ha mondjuk Samba3 + msdfs kombóval próbáltál közel zero downtime fájlszervert építeni egy tákolmány ezer éves appnak aminek a fejlesztője arról sem tudott h. kijött a windows xp :)
Egyébként a VMS azért nem volt ám olyan szar, kár h. behatóbban nem sikerült vele foglalkoznom. Az AIX meg elég jól kezelte ezt az egész bulit a qourum pv megoldással együtt, de azért IBM-ék is mindig javasolták az "at least 3 node" szabályt.
Most fogalmam sincs h. ez az egész hol tart, már csak a corosync és rgmanager amivel foglalkozom, meg érintőlegesen docker swarm, ceph és barátai, bár leginkább shared storage-os megoldások üzemeltetése kapcsán a ceph helyett inkább a clvm játszik.
Igen, van még olyan ember, aki az FC storage-ben hisz, ha tárolásról van szó :)

NEM VOLT OLYAN SZAAAR??? Ember! A VMS (volt) AZ op.rendszer. A többi csak lájtos utánzat. ;)
A HSx storage felfogható volt egyfajta NAS-ként is, bőven volt ott redundancia :)

Upedate: szenilitás... ez már kezd tragikus méreteket ölteni... SAN - SAN - SAN - alias Storage Area Network. Bár ez inkább csak a FC bevezetésével, HSG-től...

Kontenerek, orchestrator (Kubernetes, Swarm, DC/OS, ami jolesik.)

----------------------
while (!sleep) sheep++;

Van egyébként ma olyan, aki zöldmezős beruházásnál (ha konténer alapú infrastruktúrára akar építeni), akkor nem Kubernetes-t választ? Kb. az összes nagy szolgáltató ezt nyomja out of the box. Még a Docker is beállt a sorba, hogy mentsék ami menthető.

Mi peldaul Swarm-ot valasztottunk. Indokok:
- nincs sok gep, csak par tucat; kerdezhetned, hogy akkor minek orchestrator: azert, mert igy a legegyszerubb a deployment. A fejlesztok hozza vannak szokva a compose fajlokhoz, es ugyanezeket lehet hasznalni mindenfele deploymentekhez is
- muszaj privat infrastrukturara epitenunk, tehat nincs kenyelmes CGE/AWS/Azure, hogy k8s-t menedzseljunk, es a Swarm tenyleg _annyira_ trivialisan menedzselheto
- a Swarm mindent tud, amire nekunk szuksegunk van
- a Docker biztos tamogatni fogja egy ideig, mert eleg komoly cegek hasznalnak nagyon nagy Swarm clustereket (pl. a Paypalnak tobb tizezer VM-es clusterei vannak)

Szoval esetunkben a kerdes inkabb az, hogy mi ertelme lett volna Kubernetest hasznalni. Ezzel persze lehet, hogy csak a sajat technikai dontesemet mentegetem :), de tenyleg nagyon egyszeru volt Swarmmal kezdeni, nem kellett ujratrenirozni a csapatot, etc. Kubernetesre meg valszeg siman nem lett volna ido.

----------------------
while (!sleep) sheep++;

swarm mar tud RBAC kezelni?

A fizetős verzió igen. Nekünk ez megéri, annyit spórolunk fejlesztési költségeken.

----------------------
while (!sleep) sheep++;

Ok, így érthető. :)

Kube lett a szabvany, ha ugy vesszuk, a Cloud Native. En meg egy darabig szurkoltam a Rancher-nek. Lassan jon ki a 2-es verzio. 5 key featurebol 2 azzal kapcsolatos, hogy ok tudnak Kubernetest futtatni, masik ketto meg azzal kapcsolatos, hogy ok tudnak Kubernetesen futni. Minek hasznalnek akkor egy koztes reteget, ha vege ugyis az, hogy Kubernetesen futtatom :D

-
Fájl feltöltése Github tárolóba

A core os egy eleg modern linux klaszter megoldas. mondjuk elsosorban konterner workloadokhoz. Es van hozza enterprise support.

-
Fájl feltöltése Github tárolóba

majd meglatjuk mennyire kurja szejjel a redhat ala systemd... az elgondolas ott is jo volt.

A sysvinit-et felfogni képteleneknek nem mindegy...? Sajnos a systemd részben onnan indult, hogy nagyon sokan képtelenek voltak jól felfogni az egyébként faék egyszerű sysvinit működését, filozófiáját. A systemd bonyolultabb, több ész kell a megértéséhez és a jól/hatékonyan történő használatához - persze a fikázáshoz kevsebb, de ez most mindegy :-) Lényeg a lényeg: a systemd nem fog semmit szétkufni, legfeljebb a sysvinit (meg az n+egy hamvába holt próbálkozás) tudás lesz erősen deprecated :-)

az otlet jo volt... service dependency, parallel startup...

Systemd fícsör... pl. a journal.

Ha őrzöd a journalokat, futtass egy journal --verify-t! Aztán ha van hiba, nézz utána, hogy lehet azt javítani!
Még szerencse, hogy van más log is.
Szóval én nem vagyok hanyattesve tőle és nem azért, mert divat utálni.

Halkan, lábujjhegyen kérdem: SMF-et láttál már?

+1
------------------------
{0} ok boto
boto ?

Láttam, és...? A binugzpistikék még a sysvinitet sem tudták normálisan használni, ergo minden, ami annál komolyabb dolog, megfekszi a gyomrot ebben a körben.
Anno bsd init volt amivel először találkoztam, aztán sysvinit, daemontools, upstart, smf, systemd - mindegyiknek van olyan tulajdonsága, amit ha most terveznék újra, szerintem másképp csinálnának. Nekem pl. az xml-es konfigurációs állomány "nem jön be" - marhára szuboptimális konzolon szerkeszteni, ha épp úgy hozza a sors...

Azt hiszem pont nemrégiben kiveséztük: az xml-t tudod validálni. Van rá standard.

Másrészt ne csúsztassunk! Nem a konfigurációt szerkeszted xml-ben, hanem a manifest állományt. Kb. a systemd unitfájl megfelelője.

json validálására meg kb. van draft. Ha jól rémlik már a 6.-nál tartanak. Ismétlem: draft.
A legtöbb implementáció kb. 2-es meg 3-as draftot támogat.
Meg volt valamelyik nyelv, amire ha jól rémlik, 17 implementációt számoltam össze. Ha ennyi van, azt azt sugallja, hogy egyikben se merjek bízni. Olyan érzés lehet, mint linuxról iSCSI target-et szolgáltatni. Az meg hasonló érzés, mint Xuxu Petaz-al társalogni. (If you know what I mean! ;-) )

Szóval, mit használnál xml helyett?

Amúgy meg a vim teljesen jó konzolon xml szerkesztésre is.
Másrészről: kb. két elég ritkán esetben kell a manifesthez nyúlni:
#1 elrontották, és javítani kell. Ebben az esetben ez eléggé ritka.
#2 valami olyan új szolgáltatáshoz hozod létre, ami korábban még nem volt. lássuk be, ez sem túl gyakori. Amikor ilyet csináltam, akkor meg fogtam egy hasonlót, átírtam benne az érdekes dolgokat és voila.

Figyelembevéve, hogy milyen sűrűn kell a manifest-hez hozzányúlni, meg mekkora maga a meló, itt ezt most netto drama queen-eskedésnek érzem.

Nem vele beszélted, hanem velem. (Bár félbemaradt). Rádadásul valami hosszú lószar 12. mellékszálaként. Másrészt ha meg csúsztatás azért az, hogy mutattam neked egy darab példát xmlen kívüli adatformátum validálására, az nem jelenti azt, hogy az az egyetlen. Ráadásul egy manifest / unitfile bonyolultságú dolgot nem is feltétlen kell valami standard validátorral megoldani.

Azért nekem szimpatikusabb az SMF evvel, hogy már az XML betöltésénél egy szimpla tyúkésszel felfogható validációt végiggörget rajta. Ha az zöld, akkor jöhet, ha meg piros, akkor nem kerül szemét a rendszerbe.

Plussz, másik oldalról: maga a validátor pedig egy az egyben egy objektív definíciója magának az elvárt adatnak.
Nincs olyan, hogy mire gondolt a költő a manpage írásakor.

Persze, de ilyen validációt lehet csinálni nem csak xsdvel.

Ja, és a manpage helyett az xsd-t is el lehet baszni :)

+1, a konfigurációt mindenképp validálni kell az adott motyónak, persze, lehet azt mondani, hogy deazikszemeltkönnyebb... És? Ez legyen a kódgányoló baja, nekem legyen kényelmes, tömör, olvasható a szintaxis, és kész :-)

De te nagyon árnyékboxolsz:
- ha konfigot kell b...tatni, arra ott az svccfg. Sima, szögegyszerű cli. Ott one by one tudsz lekérdezni, beállítani, azt csinálni amit akarsz bármelyik fmri bármelyik property-jével.
Persze, lehet exportálni. Az exportformátuma xml.
De ez "exportformátum"-ot meg ha szerkeszteni kell, azt majd program szerkeszti. OTT nem szempont, hogy hogy néz ki.

Amiről én beszélek: Az a manifest fájl. Azt meg a szolgáltatásintegrátoroknak kell egyszer megírnia. Megint csak nem a te dolgod, hacsak nem fejlesztesz ki egy új s*larish-os szolgáltatást.

Írtál egy új syslog-ng-t? Vagy mire kellett neked xml-t hegeszteni?
Vagy csak bénáztál, és a cli manja elkerülte a figyelmed, és helyette exportáltál xml-be, gányoltál, majd import?
Nem szégyen, csak a saját lámaságodért ne az smf-et hibáztasd! Mindenki hibázik.
Illik belőle tanulni, és nem áttolni a felelősséget :P

Szerintem nem véletlen, hogy ez a zűűűberszuper trutymó nem terjedt el... Az, hogy cli-vel kell kérdezz-feleleket játszani ahhoz, hogy beállítsam a mutyürü szolgáltatás pütyürü paraméterét emzéperikszksiszékhóemberperperfooszázaéklambda értékre... Az megint csak a sajtreszelő kategória a vi mütyürü.conf -hoz képest. Szerintem.

Szerencsére slowarishoz 2.5.x óta nem nagyon volt szerencsém - abban még normális init volt :-P

Gyakorlatilag azt nem ismered, amit az egész világ Solaris alatt ért, és ami elég sok, mára elterjedt technológia ihletője vagy inkubátora (volt). Ez nem baj, de hallgatni arany. :)
------------------------
{0} ok boto
boto ?

Ami még Solaris (helyesebben SunOS) volt, azt ismerem, azt, ami lett belőle, na azt valóban (de azt is mondhatnám, hogy szerencsére) nem, illetve nem igazán. AMit láttam belőle, nos, az bőven elég arra, hogy kerüljem, lehetőleg minél nagyobb ívben.

Az 5.10-zel érdemes legalább a release notes erejéig megismerkedni, sokat adott az iparnak.
------------------------
{0} ok boto
boto ?

Ok. Akkor maradjunk abban, hogy már az egész megközelítésed rossz a rendszerhez, de habzó szájjal oltod a rendszert, mindenki hülye csak te vagy helikopter stílusban.

Bocs, de ettől értelmesebb/ kultúráltabb embernek gondoltalak.
Mondjuk az is meglepett, hogy HZ-t tök ismeretlenül másik szálban hogy leoltottad. Igaz, én nem ismerem személyesen, és nem volt még vele bajom / problémám. De ez akkor is egy nyilvános fórum:
A személyes sérelmeid itt teregetni, akár magán (HZ-case), akár szakmai agymenésről (nettó előitéletek fröcsögése jelen esetben) van szó, az nem fasza!

Így, nem tudlak komolyan venni.

Amit láttam a slowarisből, miután annyi mindenben újítottak, az bőven elég volt ahhoz, hogy trutymónak nevezzem :-P Nagyon-nagyon sok olyasmi volt/van minden kereskedelmi unix(jellegű) rendszerben, ami azóta kváziszabvényként másütt is megjelent, és elfogadottá vált. A slowaris init-helyettesítő megoldása nem ilyen - szerintem szerencsére. Egyébként _szerinted_ miért jobb, mint a többi sysvinit utáni init megoldások? Hordozhatóság/átjárhatóság szempontjából hogyan viszonyul a sysvinit-es örökséghez?

Az xml nem emberi fogyasztásra szolgáló formátum, van olvasmányosabb, szemmel áttekinthetőbb és kevésbé szószátyár formátum a világon - az, hogy validálni mit nehezebb vagy könnyebb, az legyen a programozó gondja :-)
Hogy mit használnék? név-érték párok, strukturált értékadésoke setén a.strukturat.reprezentalo.prefixelt.nev=ertek megoldást, ini formátum - bármi, aminek a releváns része a beálíltás valós információtartalma, nem pedig a formázás/struktúrakijelölés. Egy valami van, amit soha nem használnék, sőt életfogytiglani bitreszeléssel büntetném, az a yaml :-P

smfgen, manifold, sima svccfg export > loptam.xml, edit, svccfg import loptam.xml
------------------------
{0} ok boto
boto ?

Ez ez smfgen, meg manifold mi?
# uname -v ; man smfgen ; man manifold ; smfgen ; manifold
omnios-r151024-32f54f0308
No manual entry for smfgen
No manual entry for manifold
-bash: smfgen: command not found
-bash: manifold: command not found

Ha valóban érdekelni fog, majd utánanézel. (Ha nem szállítja az OmniOS nevű illumos-disztribúció, akkor nem létezik?! Ugyan.)
------------------------
{0} ok boto
boto ?

Akkor beírom ide. Ahogy látom, mindkettő smartos/joyent saját fejlesztése.
Azért a félinfók villogtatása helyett szimpatikusabb lett volna, ha írsz róla pár szót, meg mondjuk ezt a két linket:
- https://code.google.com/archive/p/manifold/
- https://www.npmjs.com/package/smfgen

Amúgy: eddig, most gyors belenézés után egyik sem nyűgözött le :P

Mondjuk, a manifold legalább python. Azt meg lehet tenni virtualenv-be is, annélkül hogy a rendszerszintű python-t mindenféle dependenciákkal keresztbevernéd.

sub