Distrib választás szerver célra

Linux-haladó

Üdv,

használok egy ubuntu 14.04 LTS szervert egy éve 24/7 üzemmódban, de túl sűrűnek találom a frissítéseket, főleg az újraindítást igénylőket, tekintve, hogy a kiesés egy percre sem megengedett.

Érdemes-e átállni másik distrib-re, vagy létezik olyan gyakorlat, ami értelmes szintre csökkenti a problémát?Amit tudnia kell:

  • több soros port bővítő kártyáról fogadni adatokat
  • postgresql adatbázisba tárolja őket
  • tcp socketen csatlakozik helyi kliensekhez (nem csak a postgres)
  • tud futni rajta xojo project (démonok egy része azzal készült)
  • adatbázist replikálja forró tartalék szerverre

Amit eddig tettem:

  • kikapcsoltam az unattended-upgrades-t
  • a postgresql-t külön is letiltottam apt configban
  • replikálom az adatbázist egyik kiemelt munkaállomásra

Ebben kérem a tisztelt társaság véleményét/segítségét, köszönettel:
soky

  • 8697 megtekintés

( _ventura_ v | 2016. 07. 23., szo – 09:11 )

Szerintem CentOS, 10 évente elég dist upgradelni :D Valamint ha 0 állás lehet, akkor gondolom pár száz Ft-t megér a ksplice támogatás. Legalábbis régen ennyi volt. Mert azért itt is jönnek sűrün kernel upgradek.

Fedora 23, Thinkpad x220

https://kernelnewbies.org/Linux_4.0#head-9aa7c8499b42911a48c02b24f367bf…

--------------------------------------------------------------------
http://www.kmooc.uni-obuda.hu/
http://www.memooc.hu/
http://www.hbone.hu/hu/hirek/hbone_workshop
http://videotorium.hu/hu/channels/details/814,BME_Villamosmernoki_es_In…

( koqsz | 2016. 07. 23., szo – 09:21 )

Még ilyen indokot se hallottam, hogy biztonsági frissítések miatti újraindítás miatt distro cserét akar az ember!
Kérdéseim a következőek:
- Szerinted a többi Linux-on nem lesz ugyanez?
- Miért kell annyit újraindítani? Ha a kernel miatt, akkor "ksplice" lesz a barátod!
- Az adatbázist miért egy munkaállomásra replikálod? Mi lesz ha a munkaállomás elszáll?
- Mi lesz ha a server valamiért megáll, HW hiba miatt sose többé nem indul el?

A leírásod alapján a rendszer egy "tipikus magyar" megoldás, mely szerint 0 Ft-ból vagy olcsóbban hozz ki egy 99.99999%-os elérésű szervert!

Bocs, ha bántóak a dolgok, amiket leírtam, de szarból még senkinek sem sikerült jó várat építenie.

- Szerinted a többi Linux-on nem lesz ugyanez?
Slackware-n biztos nem :)

- Miért kell annyit újraindítani? Ha a kernel miatt, akkor "ksplice" lesz a barátod!
Igen, a kernel miatt, ezt a ksplice-t megnézem, köszönöm!

- Az adatbázist miért egy munkaállomásra replikálod? Mi lesz ha a munkaállomás elszáll?
Pont ez a mostani foglalkozás célja, egy forró tartalék szervert beállítani mellé.

A leírásod alapján a rendszer egy "tipikus magyar" megoldás, mely szerint 0 Ft-ból vagy olcsóbban hozz ki egy 99.99999%-os elérésű szervert!
Jól látod, de valahogy el kellett indulni...

( vl v | 2016. 07. 23., szo – 11:48 )

vagy létezik olyan gyakorlat, ami értelmes szintre csökkenti a problémát?

Létezik. Ha valóban "egy percre sem állhat le a rendszer", akkor nyilvánvalóan több gép kell hozzá, elvárt konzisztenciától függően minimum 2 vagy 3. Mondjuk ez soros portokon érkező adatok esetében minimum érdekes lesz, bár ha szigorúan szimplex az adatátvitel (csak jön az adat, küldeni nem kell), akkor azért nem bonyolult olyan kábelt csinálni, ami több gép bemenetére is ráköti ugyanazt. Ha full duplex kommunikáció kell, na az már sokkal bonyolultabb megoldást igényel.

Ezt a részt is meg kell oldani. Kell válaszolni is, csak egy nyugtát, de akkor is.
Mind a négy drót átdugása nyilván kényelmetlen, meg is forrasztanék egy átkapcsoló dobozkát, de 16 morzés kapcsolót nem találtam az első boltban. Nyilván keresni kell még, de ez ügyben is szívesen vennék ötleteket. A másik véglet egy harmadik gép lenne, aki mind a négy portot átjátsza valahogy a belső hálózatra, de akkor az ő meghibásodására is kell megoldás, nem beszélve az összes vevő démon átirásáról...

Az egy olyan eszköz, amin van sok soros port - pl. 32 - a másik oldala meg ip. Ezzel dugdosás nélkül lehet kezelni a failover-t.
Bevallom a pontos megoldások tekintetében nem vagyok naprakész. Ennek ellenére feltételezem, hogy manapság is léteznek olyan feladatok, ahol sok soros eszközt kell fogadni. Csak meg kell találni a számodra megfelelő terméket.
Iderakok két linket. Nem kell megijedni az áraktól, ezek ipari csúcs modellek.
Az egyik több soros portot koncentrál egyre, míg a másik soros portokat tesz át hálózatra, amiket a szerver virtuális com portokként tud kezelni.
http://www.bb-elec.com/Products/Serial-Connectivity/Serial-Data-Tools-A…
http://www.bb-elec.com/Products/Ethernet-Serial-Servers-Gateways/Ethern…

A soros port fizikai paramétereitől függően számtalan megoldás létezhet.
Ha a soros eszköz a munkahely mellett van, rögtön bevezetném oda, vagy ip-re rakva a munkahelyen keresztül. (stb.)

Kiegészítés:
Most látom, hogy csak 4 dugód van.
Ez sem rossz: http://www.ebay.com/itm/USR-TCP232-200-LAN-Server-Serial-Device-Server-…
(Ez a gyártó!)

Köszönöm szépen!
Ha még programozni is lehetne, mit kezdjen pontosan a beérkező adattal, vagy tudna több szerver között választani...
Ha csak egy virtuális soros port, hogy regisztrálja be magát egy szerver, hogy szeretné használni és meddig van joga hozzá?
Remélem, lehet róla részletes doksit szerezni még vásárlás előtt.

A jelszó: heartbeat.
Lényegében egy cluster funkciót kell kialakítani.
A legegyszerűbb esetben a két szerver egyike az aktív, a másik a tartalék. Az aktív periodikusan, ún. heartbeat üzenetekkel jelez a tartaléknak. Ha megdöglött, akkor nincs szívverés. Ekkor adott időn belül átveszi a közös erőforrásait a tartalék. - Esetünkben a soros eszköz olvasását. Ehhez az eszköz TCP server módban van.
Ha már az etherneten vannak a csomagok, akkor akár duplikálni is lehet, stb.

Az olcsó kínai TCP/UDP <-> soros portok programozhatók az rfc2217 szerint (is), már ha szükséged van a dinamikus beállításra. Szerintem akár netcat segítségével is össze lehet hozni a megfelelő programot.
Nem biztos, hogy pont erre a típusra van szükséged, csak példaként:
http://www.usriot.com/download/datasheet/USR-TCP232-200_datasheet.pdf
http://www.usriot.com/download/T24/USR-TCP232-T24%20Series%20Setting%20…

A dokumentáció egyszerű, de a szerkezet is csak ennyire bonyolult. :)
De ilyet is lehet találni hozzá:
https://github.com/danymar24/node-usrtcp232

Lényegében 100$ nagyságrendben - némi munkával - össze lehet lapátolni egy 300-600$ megoldást.

( dotnetlinux | 2016. 07. 23., szo – 15:08 )

Priv on

Soky Lufthansa Systems? Sokat hallottam Rolad...

Priv off

Tobb vasban erdemes gondolkodni, terheleselosztas+biztonsag+rendelkezesre allas. Centos konzolban csak a legfontosabb csomagokat kapja meg normal repobol, azt is kicsit kesve, hogy jol kitesztelt legyen.

hogy jol kitesztelt legyen

Igen, mégis egyre szarabb. A 3.10.0-327.xx.x.el7.x86_64 kernel sor az egy tragédia. Először a clocksource miatt volt kernel crash aztán meg sikerült beportolni ezt a mdraid5 crasht és ezt már nem is javítják ki a 327 sorozatban, csak a 7.3 kiadással jön majd a javítás. Régen minden jobb volt...

( sibike | 2016. 07. 23., szo – 15:45 )

A szolgáltatások közül melyik "nem állhat le egy percre sem"? Az adatgyűjtés?

Akkor két szerver, nem kell HA cluster és hasonlók.
Külön adatgyűjtők, mindegyik hálózaton mindkét (vagy akár több) szerver felé elküldi az adatokat, amelyik szerver éppen működik, kiabál, ha kell.
De amit nem úszol meg, az az adatgyűjtők kiszervezése a szerverből. Elég sok hasonló próbálkozást láttam már, soha nem lett belőlük működő rendszer.

Nem.
Arra gondolok, hogy vannak kis dobozaid, amelyekbe ömlik be az adat a soros portokon. Minden doboz a beérkezett adatokat addig tárolja, amíg nem tudja, hogy valamelyik szerver megkapta. A doboz akkor kiabáljon (itt nincs más lehetőséged csak kb. egy beeper, esetleg neki lehet állni GSM moduloknak stb.), ha egyik szerver sem elérhető. A dobozokon annyi szoftver legyen, amennyi a minimum, azon kívül, hogy kifelé küldik az adatokat, célszerűen semmi kommunikációt nem szabad engedni a hálózaton. Nincs frissítgetés stb. Ha módosítani akarsz a rendszeren, kiveszed a bootdisket, és úgy javítasz.
Ezzel az alapvető problémád megoldva, frissítés miatt az adatgyűjtés nem áll le.
Kell hozzá minimum két szerver, így ezekből az egyiken mindig azt csinálsz, amit akarsz. Én valószínűleg azt csinálnám, hogy a dobozok UDP-n küldenek ki broadcast üzeneteket, amelyik szerver megkapja, válaszol, ha kell, riaszt a kliensek felé. A dobozok az első válasz után eldobhatják a tárolt adatot, a szerverek szinkronizálják az adatokat egymás között, ha szükséges.
Ha lehet, arra alapoznék, hogy a hálózat, amelyen kommunikálnak, biztonságos, ha nem megy, akkor valamilyen digest alapú hitelesítéssel látnám el a dobozokat.

Nagyon jó, tetszik, köszönöm szépen!
A két szerver szükségessége hamar kiderült.
Viszon a dobozokat nem lehetne megspórolni valami watchdogba oltott átkapcsolóval? Aki ahhoz a szerverhez kapcsolná a soros kábeleket, amelyik kitartóan rugdalná, mint valami hw watchdogot. Az lenne a fő szerver, venné az adatokat (mint most). A tartalékra replikál postgresql. Na igen, csak ki és hogyan veszi észre, ha megáll? A soros portokat átkapcsolni nem elég, közölni kéne tartalék szerverrel, hogy már ő a fő, ne csak replikáljon, hanem fogadjon soros porton. A visszaállásról nem is beszélve: a közben keletkezett adatokat vissza kéne juttatni a megjavított fő szerverre.

A dobozkás megoldásodban a klienseket is UDP broadkasztos módon kéne csatlakoztatni a szerverek egyikéhez?
Valamint létezik szimmetrikus adatbázis replikáció, akármelyik szerveren keletkezett adatok vagy módosítások átkerülnek a másikra és vica versa?

Na igen, csak ki és hogyan veszi észre, ha megáll? A soros portokat átkapcsolni nem elég, közölni kéne tartalék szerverrel, hogy már ő a fő, ne csak replikáljon, hanem fogadjon soros porton.

Khm. Szerintem olvasgass utána a "cluster", "HA", "failover" megoldásoknak, és rá fogsz jönni, hogy ezt már feltalálták.

Viszon a dobozokat nem lehetne megspórolni valami watchdogba oltott átkapcsolóval?

Hát persze, ugyanakkor észre kéne venni, hogy a dobozka/átkapcsoló a rendszerben egy SPOF lesz az adott soros vonal tekintetében. Ergó olyan valamit akarsz ott használni, ami minél inkább megbízható. Átkapcsoló esetén az átkapcsolás vezérlési megoldása is része a problémának (és a SPOF-nak)... Az ideális az lenne, ha a soros vonal maga nem lenne SPOF (a rendszer, amiből jön az adat, képes lenne egynél több soros vonalon kommunikálni, de ez valószínűleg irreális álom).

Úgy általánosságban: azt is látni kell, hogy pl. TCP-n sokmásodperces timeoutok/retransmissionök vannak, nem is feltétlenül teljesen kontroll alatt tartható módon. A TCP/RS232 gatewayen pedig egy soros vonalra egyszerre egy valaki csatlakozhat.

Látom, elég jól leírtad, miért nem lehet tisztességesen megcsinálni szerveren belüli soros portokkal :)
Az, hogy a kliensek hogyan csatlakoznak a szerverhez, igényektől (pl. biztonság) is függ. Én pl. most csinálok egy olyan rendszert, ahol egy szerver a frissítése alatt az állapotokat broadcast küldi ki az egyik subnetbe, és ha ott van legalább egy gép, amin fut a kliensszoftverem, akkor látom, hol tart. Ha nem, nem. Viszont, engem jelen esetben hidegen hagy, hogy ki jut hozzá az információhoz, nincsen benne semmi titok, viszont nem kell bemenni a szerverszobába és monitort kötni a gépre, illetve az operátort sem kell megtanítani az IP konzol használatára.

Azt kell észrevenni, hogy egy ilyen problémára tipikusan nem a veszek n komponenst és összedrótozom a megoldás, ez egy komplex hardver- és szoftverfejlesztési feladat. Az általam leírt megoldás esetén pl. minden sql replikáció abszolút alkalmatlan.
Érdemes egy olyan fejlesztőt keresni, aki csinált már hasonlót. Előbb-utóbb fel fog merülni egy rakat kérdés, amelyre (megfelelő ismeretek híján) nem is gondolt senki az alkalmazók közül. (Az egyik nagy kedvencem pl.: a mérőeszközök soros portjainak földje biztos lehet közös?)

( markia | 2016. 07. 23., szo – 23:22 )

A SlES 12nél futásközben lehet kernelt frissíteni 99,9999 rendelkezésre állás elérhető. A technológia más distriben is elérhető de a Novell suportot is ad hozzá!

( janoszen v | 2016. 07. 24., v – 13:15 )

Azert az elgondolkoztato, hogy ha a biztonsagi frissiteseket nem jatszod be mert nem megengedett a kieses. Jobb esetben ezt ugy szokas megoldani, hogy van egy manualis failover lehetoseg es ugy vegzed el a kritikus frissiteseket.

Persze ha nincs kint publikusan es jol be van tuzfalazva, akar azt is csinalhatod, hogy egyszeruen nem frissitesz.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

( locsemege v | 2016. 07. 24., v – 13:23 )

Csak kérdezem, hogy az nagyon elkefélt ötlet, hogy High Available cluster két géppel, aztán felváltva frissítgetni? Az oprendszer például CentOS, de akkor már bármi más is akár.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( sj | 2016. 07. 24., v – 20:18 )

a kozelmultban kaptam olyan igenyt, hogy egy nagy rendelkezesre allasu virtual host kell (a site amugy egy csomo mas vhost-okat is kiszolgalo gepen lett volna), ami nem allhat le, mert a hudefontos adatok ide erkeznek kb. fel percenkent a par szaz adatgyujto eszkozrol. Amikor megkerdeztem kedves megrendelot, hogy figyelj mar, gyoker, szerinted akkor hogyan fogok OS-t, alkalmazast, whatever frissiteni, akkor azt valaszolta, hogy fogalma sincs, de ti ugyis olyan ugyesek vagytok, es biztos megoldjatok. Aztan abban maradtunk, hogy erre a projektre most inkabb nem adunk ajanlatot abban a formaban.

Btw. az ilyen csomo tavoli kutyun levo adatokat sokkal ertelmesebb, ha nem push-sal (pl. post keres) kuldik el a kutyuk, hanem a kozpont pull-lal olvassa ki beloluk. Igy nem gond, ha a szerver kiesik egy rovid idore. Vagy ha ez nem jarhato, akkor legalabb valami failsafe, timeout, retry es ilyesmi hivoszavak vannak implementalva kutyu oldalon.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"kb. fel percenkent a par szaz adatgyujto eszkozrol. "

Ha 30mp-enként érkezik adat, akkor az valami repetatív dolog, amiből ha kimarad 2-3 adag (60-90mp), akkor a világ nem omlik össze. (Nyilván ez nem igaz, ha pénzügyi tranzakciók vesznek el... :))

Mondjatok egy példát, amikor nem szabad kiesnie 60mp-re egy mérőnek? PaksII-höz kell? :)

Nem hiszem el, hogy ilyen kaliberű cucc "túloldala", azaz ami a soros port másik végén van, olyan valaki által lett megálmodva, akinek lövése sincs arról, hogy hogyan lehet megbízható rendszert építeni.

Márpedig akkor kellene lenni valami koncepciónak, hogy hogyan lehet hibatűrő módon kezelni az eseményeket a soros vonal "innenső" oldalán.

Pedig elhiheted!
Ezért vagyok itt, mert nem így születtem (vagy, mert túl régen)...

Abban igazad lehet, hogy nem is a soros porttól kezdve kéne vizsgálni a rendszert. Attól, hogy én ezen keresztül kapom, még nem itt keletkezik az adat, ezt megelőzően is van benne redundancia, nyugtázás, ismétlés szükség esetén.

Igen, a soros port túloldala puffereli és ismételi, amíg nem nyugtázom vissza. Sőt, az egyik soros porton egy másiknak a tartalék vevőjéről kapom az eseményt, ha a fő átvitel megszakadt.
Az uptime nem is az esemény elvesztése miatt kell, inkább a riasztásra raegálás, az intézkedés gyorsasága miatt.