Linux újraindítás hetente: hogyan beszéljem le a kollégákat erről?

Red Hat, Fedora, CentOS

Multinál dolgozom, adatközpontunk Indiában. Projecthez kaptunk 4 gépet, amiken RHES 5.4 (Tikanga) fut. Az indiai legények minden gépen beállítottak egy automatikus újraindítást hétfő hajnalban (helyi idő szerint), mert szerintük "disabling autoreboot increases the risk of OS crash day by day". Hogyan beszéljem őket le erről?
A szervereken egy elosztott/grid megoldás fut, szerencsére biztonságoz eléggé ahhoz, hogy ne legyen adatvesztés/korrupció még akkor sem, ha kimegy as OS vagy a hardver alóla. Ugyanakkor pain in the ass minden hétfőn újraindítani a node-okat és néha a vasárnapi feldolgozás nem ér időben véget és kezdhetjük előről hétfőn.
Namármost egyértelmű, hogy amit az indiai fiúk írnak, az egetverő baromság és minden bizonnyal a tudatlanságukból eredő tévhit, de ezt nem mondhatom meg nekik így nyíltan. Tudtok valami olyan angol nyelvű forrást, ami hitel érdemlően bizonyítja, hogy a Linux képes akár egy hétnél tovább is futni, annélkül, hogy összeomolna? A saját, házi szervereinken aktuális 64 napos uptime (szerelték a hútést, le kellett kapcsolni a gépeket) nem volt elég meggyőző nekik.
Köszönöm előre is.

  • 4608 megtekintés

( zamboriz v | 2011. 10. 31., h – 07:16 )

Érv: a ksplice -t senki sem használná, ha hetente újra kéne indítani a rendszereket.

( subchee | 2011. 10. 31., h – 08:26 )

"disabling autoreboot increases the risk of OS crash day by day"
Ez akár igaz is lehet. SLES10 -en futó Novell Directory Services daemon évek óta ismert hibája a memóriaszivárgás. A Novell hivatalos javaslata (mivel évek óta nem találják az okát): indítsd újra az NDS daemont kéthetente.

Tehát futhat nálatok is olyan szolgáltatás, ami miatt lehasalhat a szerver.

Passz. Túl sok jót nem tudok általánosságban nyilatkozni az indiaiakról. Egy ottani "vmware szakember" (level2 vmware támogató) kérdezte meg múltkor tőlem, hogyan kell elindítani egy virtuális gépet vmware server-en, ha nem indult el magától... sok ilyen történetem van. :)

( sabe v | 2011. 10. 31., h – 08:37 )

Te vagy a megrendelő. (Még multin belül is)
Mondd azt, hogy márpedig ne indítsák újra, mert az üzleti érdek ezt kívánja. Egy technikus nem bírálhatja ezt felül.

( emberk | 2011. 10. 31., h – 08:44 )

Nálunk gyakrabban van áramszünet (szünetmentes táppal együtt, kb évente 1-2), mint reboot. Szerintem simán mondd meg nekik a véleményedet, persze ha akarod virágnyelven :).

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( meditor | 2011. 10. 31., h – 09:19 )

Hát az időnkénti újraindítás szerintem sem árt. A hetenkénti talán
túlzás és valszeg azért választották ezt, mert könnyű beállítani.
Alkudj: indítsák újra 2 hetente.
> Sol omnibus lucet.

Errol tudnal bovebben nyilatkozni? Konkretan, hogy miert gondolod azt, hogy idonkent ujra kell inditani, ha ezt semmi se indokolja amugy (pl. kernel frissites). Tenyleg kivancsi vagyok, excegnel voltak 200+ napos uptime-mal gepek gond nelkul szolgaltak ki sokszaz usert nap mint nap.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Tapasztalatom szerint pl mindig van egy kis memória szivárgás, na nem sok,
csak annyi, hogy néhány hét után elkezd swappelni. Nem látványosan, csak egy
kicsit.

Néha nem árt egy fsck. Ezt szerintem periódikus boottal a legcélszerűbb kiváltani.
Én le is szoktam állítani a szervert néha és hidegstartot adok.

Persze sok függ a hardverminőségtől. Sokan egyszerű PC-t használnak szervernek.

Ne gondoljuk, hogy a futó alkalmazások hibátlanok. A takarítás legegyszerűbb
módja a reboot.

Egy bootlista végignézése rengeteg információt ad a hardver egészségi
állapotáról.

Szóval van indok bőven...

> Sol omnibus lucet.

Na lassuk sorban:
- Memoriaszivargas: ehhez aztan felesleges a reboot. Meg kell nezni, melyik alkalmazas szivarog, es restartolni kell az illetot. De nem az egesz gepet.
- Fsck: ezt maintenance idokeretben szokas csinalni, de nem heti rendszeres idozitett reboottal, de foleg nem hetente. Ha nincs gond, ezt havi 1x eleg megcsinalni. Legfeljebb. De inkabb negyedevente.
- Takaritas legegyszerubb modja a reboot: aha, es utana sose tudod meg, valojaban milyen problemaid is voltak. Ezt pedig nem art tudni, mert ebbol szuletnek az ejszakazasok.
- Egy bootlista...: igen, ezt hivjak maintenance idokeretnek. Megint nem heti feladat. Legfeljebb negyedevente egyszer erdemes ezt eljatszani, ha csak ez van.

De ezek mind akkor ervenyesek, ha nagyon ujra akarunk inditgatni. Viszont meg ezek is feleslegesek a gepek jo reszenel. Sem az fsck sem pedig a bootlista megnezese nem kritikus dolog, a hardver allapotarol ezer mas modon is lehet tajekozodni, a fajlrendszerrel pedig addig biztos nincs gond, amig a gep eletben van (nincs kernel panik, nincs aramkimaradas, meg egyebek). Szoval meg mindig nincs olyan indok, ami miatt egy gepet csak ugy idonkent ujra kene inditani, ha semmi nem indokolja.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Általában a hw hibákat szeretik az ilyennel tervezett módon felderíteni. Pl. haldokló vinyó, venti stb lehet hogy restart után már nem pörög fel vagy már bejelez rá a rendszer. Jobb így cserélni, minthogy egy óvatlan pillanatban adja meg magát. Igen, a raid rebuild is jobb ha elindul még a tervezett időben, mert valszin még onnantól néhány órán át csak minimális a gép üzemszerű igénybevétele. Ez inkább ott szokott képbe jönni, ahol 100-as nagyságrendű gép van és így általában jól tervezhető a dolog, illetve sok hw-nél jóval nagyobb az esély hogy valami megadja magát.

Olyan is történt már, hogy adott szerveren a raid vezérlő vagy a hotswap backplane sértődött be sok száz nap után és az egyik diszket hibásnak jelezte a raid vezérlő. A diszknek nem volt baja és egy sima reboot után rögtön el is indul a rebuild.

A nagy uptime-mal az is a probléma, amit fentebb meditor írt. Mégpedig hogy pl. egy 1-2 éve futó X OS-nél minimális tapasztalat van valszin arról, hogy ennyi idő alatt mi történik a lelkivilágában. Olyan gépem is volt (Xen dom0) ami 930. napon aszondta hogy akkor ő most elszáll (xend valahogy elkattant, 1-2 vps elérhetetlenné vált, a load meg csak nőtt nyom nélkül), amit egy resettel kellett orvosolni. Szerencsére gond nélkül visszajött, de azért kissé izgultam, mert nem én kapcsoltam be anno...

Egyetértek, a 3. bekezdéssel különösképpen.
Nem feltétlen hülyeség az újraindítás, sőt mint látszik is igen korrekten meg lehet indokolni.
Még olyan disztróknál is is mint pl. RHEL 5, ami elvileg Enterprise, meg nem is tegnap jött ki lehetnek/vannak olyan hibák, amik esetleg csak pár hónap futás után, nagy terhelés alatt, XY fájlrendszert használva, stb. jönnek elő, esetleg a legkellemetlenebb pillanatban.
Ha adott időközönként megtörténik egy reboot, akkor ez elkerülhető akár.
Nyilván a kernel patch-eket sem úgy adják ki, hogy előtte kipróbálják, hogy bírja-e az összes támogatott hardveren az 5 éves uptime-ot...

A hw problemakat az ember akkor all neki felderiteni, ha van egy olyan gyanuja, hogy fennallnak (vannak ilyen jelek) => lasd meg: indokolt reboot.

A RAID rebuild - ha egyaltalan szukseges - kezzel is triggerelheto, emlekeim szerint. Legalabbis a legtobb RAID vezerlo ezt lehetove teszi. Elo lehet ra ugy keszulni, hogy a szolgaltatasokat allitjuk le, es nem a gepet.

"hibasnak jelezte" => lasd meg: indokolt reboot.

Nem folytatom tovabb. A kerdes meg mindig az, hogy miert kell egy gepet ujrainditani, ha azt semmi nem indokolja, vagyis nincsenek gyanus jelek, halott diszkek, meg effelek a rendszerben, ami valami komolyabb hardverhibara utalna. A winyocseret meg jobb helyeken mar hotswap keretekkel oldjak meg, a minimalis rendszerleallas erdekeben. Es igen, meg sw raid mellett is meg lehet ezt online csinalni, hw raid mellett meg plane.

Hogy egy szoftverrel mi tortenik, az megint egy mas teszta. Xend eseteben talan jo a komplett gep reboot, mert igy a virtualis gepekkel is vegigjatszatja a reboot folyamatot, de mas szoftvernel legfeljebb egy sima /etc/init.d/X restart parancsot kell kiadni.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hiába hotswap, ha egyszerre kettő esik ki mert későn veszik észre az már izgalmas is lehet, hiába van RAID6.

Épp a hibás jelzés olyan esetünkben, hogy mondjuk egy havi 1x-es reboot policyval valszin az életben nem jön elő. :)

Az indok az, hogy ha valami szar, akkor az lehetőleg tervezett rebootnál derüljön ki és ne fordítva. Ez nyilván nem zár ki mindent, de ahogy hallottam általában hasznosnak bizonyult és ismétlem ez 100-as nagyságrendű gépparknál számíthat ahol ezres nagyságrendű diszk, memó stb. fut. (Könnyen ki lehet számolni, hogy ha 1m MTBF-es egy diszk, akkor mondjuk 1000-ből mennyi időnként várható egy kihalása.)

Hat en nem tudom, nalunk nagios figyelgeti a RAID-ben a diszkeket, ha gond van, csipog, levelezik, SMS-ezik, es meg mindig idoben eszrevettuk a bajt.

Egyszerre ketto esik ki: ennek azert nem tul nagy a valoszinusege, bar teny es valo, hogy volt mar ilyen eset. De ez ellen nem is nagyon lehet vedekezni...

En ugy vagyok vele, hogy ha valami szar, az akkor deruljon ki, amikor szar, hogy a tervezett reboot idejere mar ott figyeljen az asztalomon a cserealkatresz.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Hát az időnkénti újraindítás szerintem sem árt."

Hát ez egy hülyeség, amíg valaki be nem bizonyítja (márpedig sokszor felmerül az ilyesmi). Nálunk pl. van egy direkt fejlesztésekhez használt szerver (Ubuntu -val), ami 100-200 napokat megy úgy, hogy heti 5 napban nyüstöljük (build ott folyik mer' gyorsabb, fut egy rakat szervíz (pl. CI), ott futtatjuk az alkalmazások integrációs buildjeit, a teszteket, amelyek akár stressztesztek is szoktak lenni, szóval dolgozik eleget).

--
http://neurogadget.com/

( buccaneers v | 2011. 10. 31., h – 09:31 )

meg is adtad a választ: a hétvégi job nem fut le, ezért kéritek más időpontra és ritkábban.
nem kell "hit" vitába bocsátkozni, nem feladatod a 'hittérítés'...

Te, mint sysadmin tolmácsolod a főnököd kérését vagyis, pontosan megadod mikor akarod, hogy újra induljon. Egy hét után nem állítja be, akkor elkéred az Ő főnöke email címét és megírod...

nagyobb feldolgozás _előtt_ én is újra szoktam indítani - lehet hogy nincs haszna csak megszokás...

üdv mindenkinek:
buci

Azt hiszem, ez a legjobb válasz, mármint az a része, hogy nem feladatom a hittérítés. Nyilván hivatkoztam a hétvégi végrehajtásra a HelpDesk kérésben, lesz is eredménye, de azt reméltem, hogy meg is tudom velük tudományosan értetni, hogy felesleges amit csinálnak.

( uid_17626 | 2011. 10. 31., h – 09:41 )

Hazai önkormányzatnál is hallottam heti egy reboot policyről.
Egy informatikai affinitást nyomokban tartalmazó hölgy volt a vezető aki programozó-matematikusként végzett.

Személyes tapasztalatom pedig az, hogy vannak olyan disztrok amelyek nem telepítik alapból a logrotate-ot és ez gond tud lenni.

( Fisher v | 2011. 10. 31., h – 10:45 )

"Multinál dolgozom", azaz azt kell csinálnod amit a főnököd mond. "Ugyanakkor pain in the ass minden hétfőn újraindítani a node-okat", ez legalább annyira szakmai indok mint az indiaiaké.

Egyetlen dologra hivatkozhatsz, mégpedig arra, hogy a vasárnapi feldogozás néha nem fut le. Viszont - mivel multi és company policy van meg minden - ha ebbe kapaszkodsz, akkor jó eséllyel szombat lesz a hétfőből, és nem jársz jobban.

Az, hogy amit az indiaiak írnak marhaság, az egy dolog. Gondolom ők szállították a rendszert, és a fenti paraméterrel vállalják a supportot.

Az IBM is kér (izé, tulajdonképpen előír) a gépeire évente x óra karbantartást, ami nem ritkán microcode upgrade-t jelent, ami bizony leállásos is lehet. Azaz amúgy hiába menne a gép akár évekig is, néha le kell állni vele, vagy nincs support.

Elmúlt az AS/400-asok meg a többéves uptime ideje. Manapság ha egy gép uptime-ja több mint egy év, akkor az jó eséllyel elavult (kslice ide vagy oda :D).

És ja, az indiánokkal kár vitatkozni, és különösen idegtépő ha supportosok. Az amúgy végtelenül higgadt és jámbor DBA kollégámat hihetetlen gyorsan ki tudták hozni a sodrából.

"elavult"
Marmint micsoda avult el benne? Ezt jobb tisztazni, mielott az ember tevutra kerul.

A kernel nem frissul heti szinten, ez szinte biztos, meg a rolling-release Arch se hoz heti szinten kernel frissitest. Az, hogy egy apache frissul az egy /etc/init.d/apache2 restart, semmikeppen sem komplett gep reboot. Ugyanez az osszes szerver szoftverre all - egy frissites utan az adott szervizt kell ujrainditani, semmi mast.

Nem tudom, milyen multinal dolgozik a topiknyito, de jobb helyeken a reboot csak tervezett maintenance idokeretben csinalhato meg reszben a gepen futo szolgaltatas SLA-janak szavatolasa miatt, reszben pedig mert akkor van ido egyeb dolgok elvegzesere is.

Tevedes ne essek: nem azt mondom, hogy ne inditsunk ujra gepeket, ha kell, szakmailag indokolt az ujrainditas, akkor tegyuk meg, akarmilyen fajdalmas is. De csak az ujraindulasert magaert heti szinten ujrainditani egy gepet - ez szerintem konkretan fassag. Es ez meg a legfinomabb jelzo.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Első sorban a kernel, mert ahhoz kell bootolni. Régi kernel, régi dist, esetleg régi libc-hez vezet, az meg régi appokhoz.

Illetve egyfajta indikátornak tartom, ha nagyon nagy az uptime, akkor vagy rém profi üzemelteti, vagy tojank a frissítésekre. Melyik eset a valószínűbb? :D

Ami meg a heti újraindítást illeti, valószínűleg így tudták az indiaiakkal újraindíttatni a szivárgó alkalmazást, ami azóta vagy szivárog még vagy nem, de a policy úgy maradt, mert nem meri senki se megváltoztatni. Állítólag ilyen előfordul multiknál. Az SLA meg gonosz dolog, a kéthetente reboot az max 25-30 alkalom, alkalmanként legyen 10 perc, max. 300 perc. Egy év 525600 perc, aminek a 300 csupán 0,06%-a (jól számoltam?). Plusz ez tervezett leállás.

Bár tekintve hogy a konkrét körülményekről semmit se tudunk, ez csak így felesleges okoskodás, abba is hagyom.

Regi kernel: altalaban tervezett kernelfrissito partikat szokas jatszani, libc-re is hasonlok vannak. Nalunk konkretan ez ugy mukodott, hogy amikor osszejott mar jopar olyan frissites, ami reboot-ot igenyelt volna, na akkor rebootoltunk. Egyebkent se a kernelt se a libc-t nem frissitik olyan surun olyan nagy leptekben, hogy ez kellene. Fel, legfeljebb negyedevente boven eleg egy reboot, annal gyakrabban csak ha valami baj van.

A reboot az eleg durva beavatkozas, mert magaban hordozza a "mi van, ha nem bootol re" eshetoseget is, ilyenkor van szep nagy outage. Szoval ezt nagyon tervezni kell, es lehetoleg minel ritkabban megejteni, mert akkor ritkabban van kimaradas -> az ugyfel elegedettebb.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( erdohegr | 2011. 10. 31., h – 11:04 )

Multinál dolgozom
Döntéshozó vagy? Ha nem, akkor az aggályaidat ("néha a vasárnapi feldolgozás nem ér időben véget és kezdhetjük előről hétfőn") egy döntéshozónak add elő. Nem lebeszélni kell amúgy őket, hanem a megfelelő embernek meghozni egy döntést.

( dj | 2011. 10. 31., h – 11:21 )

Én semmit sem indítok újra. Windows szervert sem. Megteszi helyettem az áramszolgáltató havi rendszereségű "karbantartása" az oszlopon. Ilyenkor a szünetmentes szépen leállítja a szervereket, oszt megvan a "kötelező" reboot.

( turul16 v | 2011. 10. 31., h – 12:08 )

Ilyen verziot lattam 600+ napig menni, aztan hdd csere kovetkezett.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Rt711 v | 2011. 10. 31., h – 14:24 )

Hacsak nem indiai kihelyezett supportos admin kollégák -mert akkor biza megb.tta a maci-, akkor emeld fel szépen a telefont és hívd a külföldi managered hogy: beleugatnak a melódba. Mivel te vagy a teamed a felelős az OS-ért, ezért kéred hogy a "company policy" be nem tartása miatt vonja őket felelősségre. Ráadásul a megrendelő esetenként külön fizet az uptime-ért, szóval ha épp "reboot" vagy karbantartás van, és az indiai haverok szakértése miatt ez már túllépi az éves időkeretet akkor biza kegyetlen büntetéseket tudnak kiszabni -megjegyzem ilyen esetben jogosan.

Indiai supporttal csak a török vagy a maláj veszi fel a versenyt. :)

-
Debian Squeeze

( Vladi | 2011. 10. 31., h – 19:50 )

"Ugyanakkor pain in the ass minden hétfőn újraindítani a node-okat és néha a vasárnapi feldolgozás nem ér időben véget és kezdhetjük előről hétfőn."

Ezzel érvelhetnél pl. Vagy egyezzetek meg egy újraindításban. Mondjuk 10 naponta. Akkor ők is megnyugszanak.

>>: sys-admin.hu :<<

( b | 2011. 10. 31., h – 19:55 )

Ezt teszi a windóz az emberekkel.

--
GPLv3-as hozzászólás.

( dikki | 2011. 10. 31., h – 22:16 )

_sok_ 1000+ napos uptime-ju gepet lattam mar. de hulye indiait is.

( STP | 2011. 11. 01., k – 02:56 )

"disabling autoreboot increases the risk of OS crash day by day"
Akkor javasold, hogy naponta reboot-oljanak.
Nem is. Inkább óránként.

(Egyébként az idézett szöveg óriási, kár hogy faszság.)

( _Franko_ v | 2011. 11. 01., k – 09:59 )

Tipikus company policy (vagyis: ezt így szoktuk, de nem tudjuk, hogy miért). Az eredete gondolom onnan jön, hogy volt egy leak valamelyik programban annó, és beépült az üzemeltetésbe a rutin, hogy ha hetente nincs reboot, akkor egyszercsak megáll a szolgáltatás.

Az indiaiakkal tapasztalataim szerint két baj van:
1, nem tudják azt mondani, hogy "nem tudom".
2, különféle hihetőnek tűnő indokokkal gyakran elfedik az előző pont hiányosságait.

Ebből a kettőből általában az jön ki, hogy ha nem tudnak valamire válaszolni, akkor is válaszolnak valamit, legyen az bármilyen hülyeség.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home