Fórum Root.cz
Hlavní témata => Server => Téma založeno: cik951 07. 01. 2014, 18:34:05
-
Dobrý den,
chtěl jsem se zeptat zkušenějších na nejlepší postupy při vypínání / restartování serveru ( např. kvůli instalaci nové verze kernelu ). Buď jestli víte o nějakém zdroji na netu nebo pokud napíšete nějaké osobně použivané postupy a upozornění, tak budu rád.
Když se podíváte na internet, tak všude se většinou píše jen o
$ shutdown -r now
což v případě víceuživatelského serveru ( na kterém třeba ještě běží mysql ) bez kontroly aktuálně připojených uživatelů asi nebude nejlepší nápad :)
díky
-
V klidu muzes pouzit jak shutdown -r now, tak treba reboot. aplikace, sluzby a uzivatele jsou normalne legalne ukonceni (max jim spadne session) , ale vsechny services (apache, mysql, atd...) jsou ukoncovany scripty z rcx.d a nehrozi tim nekonzistence dat.
-
Hlavně si dej pozor, abys to napsal ve správném terminálu a nevypnul něco jinýho ;)
-
což v případě víceuživatelského serveru ( na kterém třeba ještě běží mysql ) bez kontroly aktuálně připojených uživatelů asi nebude nejlepší nápad :)
Je to problém, to máš pravdu - a nemá žádný magický řešení. Je to o komunikaci, ne o technice.
Za normálních okolností máš asi jenom 3 možnosti:
1. dáš uživatelům vědět, kdy bude odstávka, a v ten čas prostě tu službu uživatelům sestřelíš, jejich smůla, byli informovaní
2. máš nějaké prostředky, jak jim v tu chvíli dát vědět, aby se odhlásili sami
3. máš nějaké prostředky, jak nová připojení nepovolovat a počkat, až ta současná budou uzavřena
Prví řešení je asi nejčastější, druhý nejpracnější a třetí nejpitomější.
Teda to mluvím o tom, že máš starost o komfort uživatelů. Jestli ti jde jenom o data, tak to můžeš být celkem v klidu, za normálních okolností se ty služby se ukončí korektně. Teda za podmínky, že nepoužíváš žádný software, který by to neuměl (např. sdílení souborů nebo netransakční databáze je problém).
Anebo kdybys byl odvážná až sebevražedná nátura, můžeš zkusit hot upgrades ;) http://www.ksplice.com/doc/ksplice.pdf
-
Hlavně si dej pozor, abys to napsal ve správném terminálu a nevypnul něco jinýho ;)
Tyvole, to není žádná sranda - onehdá se mně to stalo a myslel jsem, že mě jebne :)
-
což v případě víceuživatelského serveru ( na kterém třeba ještě běží mysql ) bez kontroly aktuálně připojených uživatelů asi nebude nejlepší nápad :)
Je to problém, to máš pravdu - a nemá žádný magický řešení. Je to o komunikaci, ne o technice.
Za normálních okolností máš asi jenom 3 možnosti:
1. dáš uživatelům vědět, kdy bude odstávka, a v ten čas prostě tu službu uživatelům sestřelíš, jejich smůla, byli informovaní
2. máš nějaké prostředky, jak jim v tu chvíli dát vědět, aby se odhlásili sami
3. máš nějaké prostředky, jak nová připojení nepovolovat a počkat, až ta současná budou uzavřena
Prví řešení je asi nejčastější, druhý nejpracnější a třetí nejpitomější.
Teda to mluvím o tom, že máš starost o komfort uživatelů. Jestli ti jde jenom o data, tak to můžeš být celkem v klidu, za normálních okolností se ty služby se ukončí korektně. Teda za podmínky, že nepoužíváš žádný software, který by to neuměl (např. sdílení souborů nebo netransakční databáze je problém).
Anebo kdybys byl odvážná až sebevražedná nátura, můžeš zkusit hot upgrades ;) http://www.ksplice.com/doc/ksplice.pdf
- napsat e-mail, Skype, IM, ...
- shutdown -h +10 Ukoncete praci, system se vypina za deset minut
- zablokovat na firewallu všechna nová spojení, ale souhlasím, že to není vhodné řešení
-
...Když se podíváte na internet, tak všude se většinou píše jen o
$ shutdown -r now
V tom pripade vsude pisou jen ptakoviny, protoze tak se server nevypina, nybrz restartuje...
-
- napsat e-mail, Skype, IM, ...
- shutdown -h +10 Ukoncete praci, system se vypina za deset minut
To prave zalezi, co je to za stroj. Kdyz je to firemni fileserver, muzes jim zpravy pres wall posilat do aleluia a efekt se moc nedostavi ;)
Ja to delam u planovanych odstavek verejnym oznamenim (vetisnou hromadny mail) a pred odstavkou jeste kontrolu a pripadnej telefonat s dotazem "Dobry den, cetl(a) jste mail?" ;)
-
...Když se podíváte na internet, tak všude se většinou píše jen o
$ shutdown -r now
V tom pripade vsude pisou jen ptakoviny, protoze tak se server nevypina, nybrz restartuje...
chtěl jsem se zeptat zkušenějších na nejlepší postupy při vypínání / restartování serveru .....
nepsat ptakoviny a lepe cist
jinak v pripade ze se nejedna jen o konzolove aplikace, tak davam na vedomi mailem cca den/tyden (dle potreby) predem. Kdyz pak nekdo vola, poslu ho do .... precteni mailu.
-
U serveru nevim, ale.. na domacim pocitaci vzdycky cekam, nez se objevi hlaska "Nyni muzete vas pocitac bezpecne vypnout."
-
Jo a předtím ještě zběsile mačkáš tlačítko turbo aby to netrvalo tak dlouho :D
-
Nevím jak je běžné, ale já mám server vyladěn tak aby zvládnul bez úhony vypnutí vytažením kabelu z UPSky. :-D
-
Hlavně si dej pozor, abys to napsal ve správném terminálu a nevypnul něco jinýho ;)
Tyvole, to není žádná sranda - onehdá se mně to stalo a myslel jsem, že mě jebne :)
Kamarád takhle vypínal svůj notebook. Nicméně nic se nedělo. Až o pár milisekund dýl mu došlo, co tím příkazem udělal. No, hned se začal shánět po někom s autem a řidičákem, aby dojeli k serveru a nahodili ho.
Mimochodem - tomu samýmu kamarádovi takhle jednoho dne restartnula server "nepověřená osoba s přístupem", která se neobtěžovala konzultovat aktuální problém s adminem. Jak to dopadlo? Výpadek služby. Proč? Disky už nebyly schopný naject - hardwarový selhání. Dokud jely, byly v pohodě, jakmile se vypnuly, už se některý nezapnuly... Divný, leč tak to bylo.
-
A já myslel, že Linux je ten kouzelný OS, který jede bez přestání desítky let a nemusí se na to sahat, proto ho všichni admini chtějí :D
-
Vezmu to z jiného konce, který tady ještě nikdo nepopsal. Udržujte systém průběžně tak, aby nastartoval do funkčního a správného stavu. Ono ne vždy můžete ovlivnit, zda se server vypne nebo ne, a ne vždy máte na vypínání spoustu času.
Co je obvykle dobré si hlídat:
- pravidla iptables, když je měníte on-line, po odladění úprav je uložte tak, aby se při příštím startu načetly
- parametry jádra a verze jádra při bootu – konfigurace Lilo nebo Grub; po aktualizaci kernelu je dobré počítač hned zrestartovat, ne aktualizovat do foroty s tím, že až se později bude muset z nějakého důvodu restartovat, naběhne to s novým jádrem – ono to někdy nenaběhne vůbec
- aktualizované služby – když zaktualizujete nějakou serverovou službu, třeba Apache, běží pořád dál ta stará verze. Je dobré pak přerestartovat tu službu na novou verzi, abyste měl jistotu, že je vše v pořádku (není problém v konfiguraci, nechybí nějaká závislost, aplikace s tou novou verzí fungují)
- init skripty – když službu spustíte přes /etc/init.d/sluzba start z rootovské konzole, běží v jiném prostředí, než při startu systému. Občas, když je startovací skript špatně napsaný, to z konzole funguje a při startu systému ne.
- závislost na službách jiných serverů – v trochu složitějším prostředí bude webový server záviset na DNS serveru a databázovém serveru, databázový na NTP, NTP a DNS na routeru… V ještě složitějším prostředí ty závislosti budou cyklické. A když dojde k výpadku celé serverovny a spustí se to v náhodném pořadí, půlka služeb zase popadá nebo se dostane do stavů, které nikdo nikdy netestoval. Jestli si dobře pamatuju, Seznam.cz takhle kdysi startoval služby po výpadku napájení v pronajatém housingu asi půl dne, protože všechno záviselo na všem…
Pokud dělám na serveru větší změny, které by start mohly ovlivnit, naplánuju pak restart serveru, i když by se ta změna obešla bez výpadku. Právě proto, abych včas ověřil, že vše nastartuje správně.
-
U serveru nevim, ale.. na domacim pocitaci vzdycky cekam, nez se objevi hlaska "Nyni muzete vas pocitac bezpecne vypnout."
To mate Widle 95 v AT kejsu? Takovou hlasku jsem uz dlouho nevidel.
-
- pravidla iptables, když je měníte on-line, po odladění úprav je uložte tak, aby se při příštím startu načetly
- parametry jádra a verze jádra při bootu – konfigurace Lilo nebo Grub; po aktualizaci kernelu je dobré počítač hned zrestartovat, ne aktualizovat do foroty s tím, že až se později bude muset z nějakého důvodu restartovat, naběhne to s novým jádrem – ono to někdy nenaběhne vůbec
...anebo provozovat FreeBSD, který ani jedním z těchto Linuxových featur netrpí ;)
- závislost na službách jiných serverů – v trochu složitějším prostředí bude webový server záviset na DNS serveru a databázovém serveru, databázový na NTP, NTP a DNS na routeru… V ještě složitějším prostředí ty závislosti budou cyklické. A když dojde k výpadku celé serverovny a spustí se to v náhodném pořadí, půlka služeb zase popadá nebo se dostane do stavů, které nikdo nikdy netestoval. Jestli si dobře pamatuju, Seznam.cz takhle kdysi startoval služby po výpadku napájení v pronajatém housingu asi půl dne, protože všechno záviselo na všem…
Je vidět, že se vyznáš, páč tohle je fakt problém, strašně blbě se tomu předchází a málo kdo na to myslí.
Pokud dělám na serveru větší změny, které by start mohly ovlivnit, naplánuju pak restart serveru, i když by se ta změna obešla bez výpadku. Právě proto, abych včas ověřil, že vše nastartuje správně.
Taky hodně dobrá rada z praxe. Ale ne vždycky to jde.
-
U serveru nevim, ale.. na domacim pocitaci vzdycky cekam, nez se objevi hlaska "Nyni muzete vas pocitac bezpecne vypnout."
nebolo to nahodou: "nyni muzete pocitac bez obav vypnout" ? tu hlasku si zapamatam do smrti tak isto ako pravidlo, ze disk treba zaparkovat pred vypnutim pocitaca :-)
inak win95 bol jediny OS, kde som mal nastavenu lokalizaciu .. aj moji kamarati .. asi to bola popularna piratska verzia z ciech :)
inak ked sa bavime o serveroch a update - zlate pravidlo: nerob zmenu, kym nemas funkcny backup! pri solaris/freebsd aspon novy boot env, pri hpux ignite a pri linuxoch nejaky ten mondo rescue.
-
U serveru nevim, ale.. na domacim pocitaci vzdycky cekam, nez se objevi hlaska "Nyni muzete vas pocitac bezpecne vypnout."
nebolo to nahodou: "nyni muzete pocitac bez obav vypnout" ?
Windows 95 jsi mohl vypnout bez obav, Windows 98 jsi zase mohl vypnout bezpečně.
-
a DOS si proste vypol :)
-
A já myslel, že Linux je ten kouzelný OS, který jede bez přestání desítky let a nemusí se na to sahat, proto ho všichni admini chtějí :D
To samozrejme je. Na Linuxu je restart potreba tak leda kvuli update jadra. Kdyby to byly Widle, je restartu potreba treba i nekolik a sluzba by byla nedostupna dve hodiny, protoze se updatoval IE a instaloval security patch KB5674365465609868865784356865. Zaplatpanbu clovek na Widlich uz nemusi restartovat, protoze pripojil jinou mys nebo se updatoval Notepad.
-
Windows 95 jsi mohl vypnout bez obav, Windows 98 jsi zase mohl vypnout bezpečně.
Horsi bylo, ze to clovek nemohl bez obav zapnout.
-
U windowsího se pomodlit aby zase naběhl.
-
Nejprve chci všem poděkovat za odpovědi.
jivep - Díky, žes jako první odpověděl, už jsem měl strach, že to nikoho nezaujme :)
Mirek Prýmek
Za normálních okolností máš asi jenom 3 možnosti:
1. dáš uživatelům vědět, kdy bude odstávka, a v ten čas prostě tu službu uživatelům sestřelíš, jejich smůla, byli informovaní
2. máš nějaké prostředky, jak jim v tu chvíli dát vědět, aby se odhlásili sami
3. máš nějaké prostředky, jak nová připojení nepovolovat a počkat, až ta současná budou uzavřena
ad 1) Opravdu tenhle přístup používáš ve firemním prostředí ? Je mi jasné, že někteří uživatelé jsou na facku, ale nevím jestli bych si to s lehkým srdcem dovolil ;) Pokud to ale měl být jen jako výčet možností, tak to pak jo.
Takže mi z toho vychází, že nejlepší kombinace z hlediska konfliktů s uživateli, je nejspíš kombinace 2 a 3 nebo se pletu? Protože samostatná 3 by taky mohla znamenat, že se nedočkám nikdy a začnou volat uživatelé, že se nemohou připojit. A u samostané verze 2 by člověk taky mohl dopadnout jak Sisyfos. Jedny uživatele budu vyhazovat a druzí se vesele začnou opět připojovat. ;D
Sten -
Díky za tvůj postup
Mimochodem. Pokud někdo bude číst tuhle diskuzi pro inspiraci, tak bych chtěl upozornit, že posledních 5 minut před vypnutím / restartováním server vám systém neumožní vytvořit nové spojení pomocí ssh ani lokálně se přihlásit.
AnthonyX
Nevím jak je běžné, ale já mám server vyladěn tak, aby zvládnul bez úhony vypnutí vytažením kabelu z UPSky. :-D
Vytažením kabelu z které strany UPS? ;)
Filip Jirsák - Díky moc za zajímavé informace.
závislost na službách jiných serverů – v trochu složitějším prostředí bude webový server záviset na DNS serveru a databázovém serveru, databázový na NTP, NTP a DNS na routeru… V ještě složitějším prostředí ty závislosti budou cyklické. A když dojde k výpadku celé serverovny a spustí se to v náhodném pořadí, půlka služeb zase popadá nebo se dostane do stavů, které nikdo nikdy netestoval. Jestli si dobře pamatuju, Seznam.cz takhle kdysi startoval služby po výpadku napájení v pronajatém housingu asi půl dne, protože všechno záviselo na všem…
Dá se tomuhle zabránit nebo aspoň minimalizovat problémy vhodným pořadím spouštění služeb a například použitím bootwait a spuštění nějakých testovacích procesů na dostupnost služby? Pokud plácám nesmysly, tak mě někdo rychle zastavte :D
martin-ux - díky za tip na Mondo Rescue. kouknu se jestli by mi tohle řešení v něčem neusnadnil život
-
a DOS si proste vypol :)
ee - disky si mal vzdy poslusne zaparkovat ! =)
-
Hlavně si dej pozor, abys to napsal ve správném terminálu a nevypnul něco jinýho ;)
Tyvole, to není žádná sranda - onehdá se mně to stalo a myslel jsem, že mě jebne :)
To je udel kazdyho ... kolega si udelal 150km vejlet ... ;D
Jinak treba v mem pripade plati, ze obecne mezi sobotnim odpolednem a nedelnim vecerem veci "nemusi" fungovat, a pokud nekdo neco urgentne potrebuje delat, tak to naopak musi ohlasit on IT.
A já myslel, že Linux je ten kouzelný OS, který jede bez přestání desítky let a nemusí se na to sahat, proto ho všichni admini chtějí :D
Taky ze na nej sahat nemusis .. jenze on trebas nekdo chce novejsi verzi nejakyho SW ... protoze ... Pokud se tyce trebas fileserveru, neni na netu, je za firewallem ... takze proc do nej rejpat? Jenze obcas trebas potrebujes prestehovat server/vymenit disky/neco prepojit/... takze to vypnout proste musis. Dneska ti totiz uz nebude stacit srv nekde v kumbale s jednim gigovym diskem na desitky let ...
A mimochodem, na tuxovi nemusim restartovat system kvuli aktualizaci webserveru/sqlka/... dokonce si muzu pres SSHcko patchnou SShcako... a restartnout sluzbu, aniz by me to odpojilo ... to je ficura, co?
Mimochodem, s lety adminovani sem dosel do stavu, kdy si vetsinu provoznich serveru klidne lajsnu restartovat v normalnim provozu (vyjikma je snad jen SQLko, ale v nouzi i to). Proc? Protoze i kdyz managori vetsinou pozadujou provoz 24/7 "furt und furt", vypadku neceho pod hodinu si v realu sotva nekdo vsimne. Zrovna dneska ... "ona ta tiskarna nejak netiskne ... uz 2 hodiny" ... a ve finale z toho bylo ... ze ona ta tiskarna netiskne ... ale uz 3 dny (vylezly z toho i pondelni tisky ...). Takze ono to ve versine pripadu neni s trvalym provozem nijak zhavy.
2FJirsak: Zavislosti jsou na nakopani rite dodavateli ... kvuli temhle kktinam mam na vsech stroji v bootloaderech vsemozny delaye = trebas aplikacni srv ceka 10 minut ... a ja doufam, ze to SQLko za tech 10 minut zvladne (normalne mu staci 5). A co sem novych veci tyce - aplikace musi nastartovat i bez databaze, a pripojit se "az ji najde". Kdyz mi nekdo prinese neco, co tohle nezvlada, tak se automaticky zarazuje az za posledniho imbecila na planete.
-
Taky ze na nej sahat nemusis ..
hej, kym nechytis bug ako: http://www.claudiokuenzler.com/blog/247/linux-virtual-server-crash-update_cpu_power-kernel-uptime-bug
(ako naschval nefunguje teraz novel link http://www.novell.com/support/kb/doc.php?id=7009834)
ja som si svoje s linuxom uzil a pri porovnani s unixom teda ma co dohanat. ale zbytocny flame tu vytvarat nejdem.
-
martin-ux: zvlastne, mal som niekolko masin s debianom a 2.6.32 kernelom, a vsetky mali uptime viac ako 500 dni a bezali bez problemov.
-
Dá se tomuhle zabránit nebo aspoň minimalizovat problémy vhodným pořadím spouštění služeb a například použitím bootwait a spuštění nějakých testovacích procesů na dostupnost služby?
Důležité je, zda o těch závislostech víte. Třeba webová aplikace může záviset na překladu DNS názvu DB serveru, ke kterému dojde při navazování spojení -- takže při startu a pak třeba až při příštím restartu webové nebo databázové služby. Nebo informace o unixovém účtu bude typicky potřeba jenom při startu služby. A pokud máte účty v LDAPu, a část LDAP je v SQL databázi, LDAP je replikovaný a závisí na NTP -- pak vám najednou kdejaká služba bude tranzitivně přes LDAP záviset na NTP a SQL serveru (a ten SQL server bude nejspíš mezi těmi závislými službami, takže hned máte cyklus). Při krátkodobé odstávce LDAPu nebo SQL nic nepoznáte, protože vše bude nakešované...
Pokud ty závislosti znáte, můžete se snažit udržovat ten graf acyklický. A pak mít buď zdokumentované pořadí zapínání strojů (pokud výpadek všeho je považováno za takový průšvih, že to pak stejně budete nahazovat ručně), a nebo to ošetřit ve startovacích skriptech služeb (lepší než zdržovat celý boot nebo čekat nějaký čas je čekat na dostupnost dané služby, pokud to nějak rozumně jde udělat). Pokud je ten graf cyklický, je dobré mít aspoň zdokumentovaná ta kritická místa a vědět, jak se ta která služba dá nastartovat v nějakém nouzovém režimu, kdy třeba neposkytuje vše, ale umožní aspoň nastartovat závislou službu. Nebo se pokusit ty služby rozdělit. Třeba pro webhostera je pohodlné mít DNS záznamy klientů v SQL databázi, ale DNS záznamy pro infrastrukturu vlastní sítě je lepší mít v souboru na disku (klidně jen cronem pravidelně vytvářený dump důležitých záznamů z databáze), DNS server nejprve startovat jenom nad tímhle souborem a dostupný jen z vnitřní sítě, a teprve dodatečně připojit i záznamy z SQL a otevřít server i do internetu. Což se takhle hezky popíše, ale nenajdete na to hotové řešení, takže si pak musíte od nuly napsat startovací skript, musíte nějak řešit tu záměnu konfigurací (a aby společné části byly opravdu stejné, ne že upravíte IP adresu DNS serveru ve velkém konfiguráku a v konfiguráku pro nouzový start zůstane stará), je dobré mít nějaký postup, jak tu nouzovou konfiguraci otestovat...
Vše to samozřejmě závisí na tom, kolik práce se do toho investuje. Pokud k většímu výpadku dojde jednou za dva roky a za hodinu to máte spravené, asi nemá smysl trávit týdny ladění konfigurací pro automatickou obnovu po výpadku. Na druhou stranu, pokud dojde k opravdovému průšvihu, je každý ověřený postup a spolehlivá automatická obnova k nezaplacení, protože pak vám zbývá čas na řešení těch opravdových průšvihů, se kterými nikdo nepočítal.
-
martin-ux: zvlastne, mal som niekolko masin s debianom a 2.6.32 kernelom, a vsetky mali uptime viac ako 500 dni a bezali bez problemov.
na tom nevidim nic zvlastne, vid.:
A fix for this issue has been released since kernel version 2.6.32.54-0.3
inu, ja som nehovoril, ze linux nevie ist > 208dni. reagoval som len na jardu a jeho koment na magic os :)
-
V klidu muzes pouzit jak shutdown -r now, tak treba reboot. aplikace, sluzby a uzivatele jsou normalne legalne ukonceni (max jim spadne session) , ale vsechny services (apache, mysql, atd...) jsou ukoncovany scripty z rcx.d a nehrozi tim nekonzistence dat.
Pri tomto Vasom tvrdeni ze sa nemoze nic stat by som si nebol uplne isty. Zazil som ze externy dodavatel nam dodal software ktory bol akoby na kolene robeny. Ziadne transakcie, binarne logy, nechcite ani neviet co s takym softvérom dokazal spravit obycajny `shutdown -r now'. Az sa niekedy zdalo ze to urobili takto naschvál aby im potom firma musela platit za servis takto "padnuteho" servera.
-
@yos3f: A proc jste jim za to zaplatili?
-
@JardaP:
Je to komplikovane. Maju specificky software ktory je z programatorskej stranky katastrofa a je to kazdemu jasne no neexistuje alternativa ktora by ho mohla momentalne nahradit, existovat sa bez softu tohto typu sa tiez neda a tak aby bola z ich strany tech. podpora sa to jednoducho zaplatilo.
-
@yos3f: A proc jste jim za to zaplatili?
Co myslis, moh sem si vybrat realizatora ... rekneme ... DS? Ale zaplatit sem to ... bohuzel ... musel, stejne jako ty a vsichni ostatni. Casto ses na tom uplne stejne i v soukromym sektoru ... trebas ... osobne neznam horsi system, nez ... SAP. Cokoli v tom nastavit je naprosta tragedie ... a i kdyz neco 100x otestujes, po 101 naostro se to podela. Presto ses casto postaven pred volbu ... ze bud budes pouzivat toto ... nebo nebudes mit kseft ...
-
Ještě jeden příspěvek k diskusi o cyklických závislostech služeb, tentokrát od provozovatelů GitHubu: DNS Outage Post Mortem (https://github.com/blog/1759-dns-outage-post-mortem). Že by infrastrukturní DNS nemělo záviset pokud možno na ničem jiném jsem tu psal, v odkazu je ukázka, jak to může dopadnout, když to tak není.