Hogyan újraindítani a szervert 1
Kivonat: ismertetése reboot, a történet SysRq, ipt_SYSRQ, IPMI, tápegység.
Hogyan újraindítani a szervert? - Ez az a kérdés, hogy általában nagyon jól kérték a kezdő felhasználók számára, akik összetévesztették a megállítása, shutdown -r, újraindítás, init 6 stb
Egy tapasztalt rendszergazda adja meg a kérdést: „mi a szerver nem?” Különböző szerver hiba igényelnek a különböző típusú újraindítás - és helytelenül kiválasztott opció vezet szörnyű következményekkel jár, beleértve a látogatás a web arcát IPMI / DRAC / ILO „doperezagruzit” lesz a legegyszerűbb. A legnehezebb az én privát gyakorlat enikeyschiki utazás a közeli városban. Annak érdekében, hogy „push újraindítás” a magányos szerveren.
Ebben a cikkben: mi akadályozza a szerver újraindítás és hogyan, hogy segítsen neki.
Kezdjük az elmélet reboot.
Ha kikapcsolja vagy újraindítja a inicializálási menedzser szerver (a legtöbb modern disztribúció - systemd, excentrikus Ubuntu 14.04 is felkapaszkodott, az archaikus szemetet - sysv-init) egy bizonyos sorrendben küldi az összes démont parancs „kikapcsol”. És a legtöbb démonok (pl adatbázisok, mint például mysql) tudja, hogyan kell megfelelően áll le. Például, hogy töltse ki az összes ügylet minden adatot mentett a lemezre, stb Mert in-memory adatbázisok, mint Redis, hogy minden kritikus lehet nem tartják meg - elveszett.
A régi rendszer initsalizatsii vár a végtelenségig az egyes init szkriptek. Például, ha a „joker” hozzáadott Önt a „stop” gally „alvó 3600”, akkor a szerver újraindul óra farka. És ha van, talán inkább egy szám, vagy egy program, ami nem akar vége, és újraindít soha nem ér véget.
Új inicializálása a rendszer (valójában, nem szégyenlős - csak systemd) ad egy időtúllépés (tipikusan 120 vagy 180 másodperc) az adatok tárolásához, majd befejezi a folyamatot erővel. Amellett, hogy leállítja a démonok, csatold le a fájlrendszert (azaz dobott ki az összes blokk cache), stop iscsi target'y (szintén skidyvaniem cache), stb stb Abban az időben shatdauna kiderül a végtelenségig, ez mind ugyanazt a pályát. Plusz, van legalább némi reményt a megfelelő befejezése minden ördögök ellen, skidyvanie fájl cache, és így tovább. D.
Tehát egy egészséges rendszer a helyes választ arra a kérdésre, „hogyan kell elindulni” - végre reboot. Egyes esetekben - akár egyetlen helyes (módosítás: ha a grafikus felhasználói felületre «újraindítás», az asztali környezet úgy gondolja, hogy ez egy vészhelyzet újraindítás - újratölti a grafikus módot kell használni «újraindítás» DE interface).
Mi lehet baj, ha egy „normál reboot”? Nos, először is, néhány démon lehet kezdeni a „tompa” - lásd fentebb.
Másodszor, lehet, hogy a probléma leválasztása fájlrendszerek. Úgy véljük, hogy ez elég ahhoz, hogy „kill”: mindazok a folyamatok, és leválasztani a meghajtó könnyű lesz - nem érdemes. Ahhoz azonban, hogy enyhén szólva nem igaz. Íme a lehetséges módszerek „fs köröm körmök, hogy ne leválasztani:
- fallocate / fs / swap -L 1G; mkswap / fs / swap; swapon / fs / swap
- dd if = / dev / sda A = / fs / kép; kpartx / fs / kép
- losetup --find --show / fs / kép
stb Röviden: A fájl használatban lehet nem csak a fájl rendszer, hanem a mag. És a lényege a modul lehet elfoglalt keres választ az élet értelme, és nincs szándék, hogy kiadja a forrás.
Mint azt tele? Nem szerelt fájlrendszert. Systemd ebben a helyzetben próbál és próbál, és öntvények (nem szerelt fájlrendszer). Azaz újraindítás ebben a helyzetben lesz túl hosszú, de még mindig tartanak. De ez hibát okoz, ha a umount.
És úgy történik, hogy umount nem tudja végrehajtani a műveletet annak a ténynek köszönhető, hogy valami nem áll rendelkezésre. Például egy fájlt nfs-server. Ha a folyamat fellebbezni ilyen fájlt, akkor nem kell kitölteni (még a kill -9). És ebben a helyzetben, „újraindítás” fátylat szerver. Ismét a legjellemzőbb helyeken systemd „lefedett”, de esélye botlás TASK_UNINTERRUPTIBLE ( „D” ps aux) is lehetséges.
Mit kell tenni? Akkor újra szinkronizálás nélkül a fájlrendszer és a befejezése semmit újraindul -f. De ez is lehet akasztani. Körülbelül a következő okok miatt, de most körülbelül a következményekkel: minden folyamat nem állt meg, és azonnal haltak meg, a tcp nem zárt, a lemez cache nem törlődik. Azonban a rendszermag is végez némi mozgást a területen reboot (és esetleg része a cache törlődik). A legfontosabb dolog - a legtöbb mag fogja használni a reboot. És ez azt jelenti, hogy ha a kernel poplohelo, nem mehetünk vissza.
Úgy történik, hogy a szerver továbbra is nyitott csak egy konzolon (és az utóbbi már nem nyitott). Miért? Mert valaki valamit podhimichil meghajtó lemezre. Vagy RAID vezérlő. Vagy még valamit, majd a „/” már csak emlék a merevlemezen. Ez azt jelenti, hogy csak hasonlít bash parancs (beépített), amelyeket végre anélkül, hogy új folyamatokat.
Ott látsz módszer, amely nem igényel semmilyen futtatható fájlokat (vagyis olvasni a hiányzó lemez). Ez (root): echo b> / proc / SysRq-ravaszt. SysRq-indító fájl lehetővé teszi, hogy a „Press” bármelyik gombot SysRq kombinációi (sürgősségi központi kapcsolót). Beleértve SysRq-b, vagyis vészhelyzet "reboot". Gyakran előfordul, hogy miután beírtuk nem is jelenik meg új sor - a szerver már az újraindítás előtt syscall vissza. Ez a legerősebb Softovaya hogy újra kell indítani.
Megjegyzés: kazhuyuscheesya helyes ebben a helyzetben, "sync, reboot", azaz SysRq-s, SysRq-B egy hiba, mert után SysRq-S, a kernel számára talán megpróbálja elindítani kommunikál az üres halmaz, és potenciálisan esnek pánikba, vagy letörnek tőled a rendelkezésre álló legújabb konzolokra. Ha korábban vészhelyzet újraindítás - meg kell figyelniük
Minden működik, ha a konzol a szerveren. És ha megnyitja a bejelentkezési lefagy, és nem konzolon? Ott ipt_SYSRQ modult. SysRq lehetővé teszi, hogy végre lekérdezéseket, így bizonyos hálózati csomag (vagy pontosabban a iptables szabály). Works teljes egészében a kernel, azaz a FS nem. Számára a csapat csatolt send_sysrq.
éjjeliőr védekezni
Az ember azt gondolja, hogy ez a „minden”, de vannak még kellemetlenebb lebeg. Például akasztani hálózati kártya. És a normál újraindítás (többek között SysRq) nem segít. Egy másik példa a rossz helyzet, hogy tegye zárt, ami zalipla egy rossz lemezt, és figyelmen kívül hagyja a busz alapállapotba. Reboot mint minden visszaáll és hajtások elérhetők.
Ebben az esetben van szükség, bekapcsoláskor (be / ki). Fizikailag fut a szerver nem érdekli, hogy mi is nézd meg a lehetőségeket a modern szerver: IPMI. Ez vstrenny mikroszámítógép segítségével kezelheti „nagy” számítógép. Ő nevükön IPMI, DRAC, az ILO, stb
Mi érdeke parancsot: ipmitool alváz bekapcsolt. Ez szigorúbb (kernel modulokat kell betölteni, ipmitool maga kell kezdeni sikeresen IPMI, hogy működik, stb) a rendszer teljesítményét. De ez lehetővé teszi, hogy torzítja a táplálkozás minden. Pontosabban majdnem minden - ha a kiszolgáló jbod'y, majd fel őket, ez a parancs nem éri el. De mégis, ez egy nagyon szilárd és jó reboot.
Ha a kernel poplohelo, a parancs elvégezhető távolról (ipmitool H ipmi.server.local alváz bekapcsolt)
Következő pont „fájdalom” - lóg tápegységek. Igen, ez történik. Hibákat a firmware PSU helyes, meg kell villogni. Természetesen bármilyen puha újraindítás (például IPMI bekapcsolt) ebben a helyzetben nem működik. Meg kell akár fizikailag piszkálni kábel vagy torzíthatja a hatalom távolról. Ebben a helyzetben segít az IP-aljzatba.
Úgy néz ki, mint ez (töredéke a vezérlőpult servers.com/servers.ru):
Nyilvánvaló, hogy ilyen körülmények között, reboot-én kerül sor a kemény ochon forgatókönyv, de ez minden bizonnyal sor kerül.