Rezumat: o descriere a tipurilor de reboot, o poveste despre sysrq, ipt_SYSRQ, ipmi, psu.
Cum se repornește serverul? - Aceasta este o întrebare care este de obicei întrebată de utilizatori foarte novici care sunt confundați între oprire, oprire-r, reboot, init 6, etc.
Un administrator cu experiență pentru a specifica o întrebare: „ce serverul nu este?“ Diferite tipuri de eșecuri server necesită diferite tipuri de repornire - și în mod incorect opțiunea selectată va duce la consecințe grave, inclusiv o vizită la web fața IPMI / DRAC / iLO la „doperezagruzit“ va cea mai ușoară. Cel mai dificil lucru din practica personală a fost călătoria lui Enikeyschik în orașul vecin. Cu scopul de "push reboot" pe un server stand-alone.
În acest articol: ce împiedică serverul să se repornească și cum să-l ajute.
Să începem cu teoria rebootării.
Când opriți sau reporniți serverul de manager de inițializare (în cele mai multe distribuții moderne - systemd, într-un Ubuntu 14.04 excentric este încă ciocoi, în coșul de gunoi arhaic - SysV-init) într-o anumită ordine trimite toți demonii comanda „opri“. Și majoritatea demonilor (cum ar fi DBMS, cum ar fi mysql) știu să închidă corect. De exemplu, completați toate tranzacțiile, salvați toate datele nesalvate pe disc etc. Pentru ca DBMS în memorie, cum ar fi redis, poate fi critică deloc: nu l-am salvat, l-am pierdut.
Vechiul sistem de inițializare a așteptat pe termen nelimitat pentru fiecare dintre scenariile de inițiere. De exemplu, în cazul în care "joker" a adăugat o strună "sleep 3600" la "stop", serverul dvs. va reporni o oră cu o coadă. Și dacă există un număr mai mare sau pur și simplu un program care nu vrea să se termine, atunci repornirea nu se va termina niciodată.
Noua inițializare a sistemului (de fapt, nu timid - a fost doar systemd) da un timeout (tipic 120 sau 180 de secunde) pentru stocarea datelor, iar apoi finalizează procesul prin forță. În plus față de oprirea demonii, demontează sistemul de fișiere (de exemplu, aruncat de pe toate cache-uri bloc), opriți target'y iSCSI (de asemenea, cu cache skidyvaniem), etc. și altele asemenea. Având în vedere că timpul petrecut la Shatdaun se dovedește a fi pe termen nelimitat, totul este în regulă. În plus, există cel puțin niște speranțe pentru finalizarea corectă a tuturor demonilor, a cache-ului de fișier skidyvanie etc.
Astfel, pe un sistem sănătos, răspunsul corect la întrebarea "Cum se repornește" este de a rula comanda de repornire. În unele cazuri - chiar și singura corectă (amendament: dacă interfața grafică cu utilizatorul pentru a face «repornirea sistemului», mediul desktop va crede că aceasta este o repornire de urgență - pentru a reincarca de modul de grafică trebuie utilizat «repornire» în interfața DE).
Ce se poate întâmpla în neregulă cu "respingerea obișnuită"? Ei bine, în primul rând, unul dintre procesele demonilor poate începe să fie "blunt" - vezi mai sus.
În al doilea rând, este posibil să existe o problemă în cazul dezasamblării sistemelor de fișiere. Se crede că este suficient să "ucizi" toate procesele și să dezinstalezi discul va fi ușor - nimeni nu o folosește. Dar, acest lucru, să-l vorbim blând, nu este așa. Iată potențialele metode "de a le cufunda cu unghii, astfel încât să nu fie șterse:
- / fs / swap -l 1G; mkswap / fs / swap; swapon / fs / swap
- dd dacă = / dev / sda de = / fs / imagine; kpartx / fs / imagine
- losetup --find --show / fs / image
și așa mai departe. Pe scurt: un fișier poate fi ocupat nu numai de sistemul de fișiere, ci și de kernel. Un modul din kernel poate fi ocupat în căutarea răspunsurilor la sensul vieții și nu are intenția de a elibera resursa.
Este plin? Sistem de fișiere neinstalat. Sistemat în această situație încearcă să încerce și aruncă (sistem de fișiere neasamblat). Asta este, rebootarea în această situație va fi foarte lungă, dar totuși va trece. Dar aceasta este dacă umount returnează o eroare.
Și se întâmplă că umount nu poate finaliza operația deoarece ceva nu este disponibil. De exemplu, un fișier de pe un server nfs. Dacă un proces accesează un astfel de fișier, acesta nu poate fi finalizat (chiar și cu ajutorul lui kill -9). Și în această situație, "repornirea" va închide pur și simplu serverul. Din nou, locurile cele mai tipice din systemd „acoperite“, dar șansele de a da peste TASK_UNINTERRUPTIBLE ( „D“ în aux ps) este încă posibil.
Ce ar trebui să fac? Aveți posibilitatea să reporniți fără să sincronizați sistemele de fișiere și să finalizați orice reboot -f. Dar și el poate să stea. Despre motivele de mai jos, dar pentru consecințele pro: toate procesele nu sunt oprite și mor imediat, sesiunile tcp nu sunt închise, cache-urile de disc nu sunt resetate. Cu toate acestea, kernel-ul efectuează încă o mișcare în zona de repornire (și, probabil, o parte din memoria cache va fi abandonată). Principalul lucru este că în timpul rebootării, cea mai mare parte a kernel-ului va fi folosită. Și asta înseamnă că, dacă nucleul este greu, atunci s-ar putea să nu ne întoarcem.
Se întâmplă că numai o singură consolă rămâne pe server (iar cea de-a doua nu se deschide). De ce? Deoarece cineva are legătură cu driverul de disc. Sau controlor de raid. Sau altceva, după care numai amintirile din cache-ul discului rămân din '/'. Aceasta înseamnă că avem doar comenzi bash (built-in), care sunt executate fără a rula noi procese.
Există o metodă de reboot care nu necesită executarea fișierelor executabile (adică citirea de pe discul lipsă). Aceasta (din rădăcină): echo b> / proc / sysrq-trigger. Fișierul de declanșare sysrq vă permite să "apăsați" orice buton din combinațiile SysRq (butoane de urgență a kernel-ului). Inclusiv SysRq-b, adică un "reboot" de urgență. Se întâmplă adesea că, după apăsarea tastei enter, fluxul de linii nu are nici măcar timp să apară - serverul este deja la repornire înainte ca sistemul să se întoarcă. Acesta este cel mai puternic dintre software-ul care este pentru reboot.
Notă: corectul "sincronizare, repornire" aparent corect în această situație, adică SysRq-s, SysRq-B este o eroare, deoarece după SysRq-S, kernelul poate încerca să înceapă să comunice cu un set gol și poate panica sau să întrerupă ultima consoană disponibilă. Dacă se efectuează o repornire de urgență, aceasta trebuie să fie de urgență
Toate acestea funcționează dacă aveți o consolă pe server. Și dacă login-ul se blochează și nu există o consolă deschisă? Există un modul ipt_SYSRQ. permițându-vă să executați cereri sysrq pentru a obține un anumit pachet de rețea (mai precis, prin regula iptables). Funcționează integral în kernel, adică nu depinde de FS. Comanda send_sysrq este, de asemenea, atașată la aceasta.
stăpânul pentru paznic
S-ar crede că acest lucru este "totul", dar există și mai multe agățări neplăcute. De exemplu, cardul de rețea este atârnat. Rebootul obișnuit (inclusiv prin sysrq) nu ajută. Cel de-al doilea exemplu al unei astfel de situații proaste este suspendarea incintei, care este blocată pe un disc rău și ignoră resetarea tuturor magistralelor. Rebootul pare să fie resetat totul, dar discurile nu sunt disponibile.
În acest caz, avem nevoie de un ciclu de putere (pornit / oprit). Executarea fizică la server nu este interesantă, astfel încât să puteți examina capabilitățile serverelor moderne: IPMI. Este un microcomputer agil care vă permite să controlați un computer "mare". Acesta este de obicei numit IPMI, DRAC, iLO, etc.
Comanda noastră este: ipmitool ciclu de putere șasiu. Este mai solicitant pentru sistemul de sănătate (modulele kernel trebuie să fie încărcate, ipmitool în sine ar trebui să pornească cu succes, ipmi ar trebui să fie de lucru, etc). Dar vă permite să vă răsuciți pe dieta tuturor. Mai exact, aproape toate - dacă serverul are jbod'y, atunci această echipă nu ajunge la ele. Dar, la urma urmei, acesta este un reboot foarte bun și bun.
Dacă nucleul este complet greu, atunci comanda poate fi executată și de la distanță (ipmitool-H ipmi.server.local ciclu de alimentare șasiu)
Următorul punct de "durere" îl constituie sursele de alimentare suspendate. Da, se întâmplă. Bug-urile din firmware-ul surselor de alimentare sunt corectate, trebuie să fie cusute. Desigur, orice restabilire soft (cum ar fi ciclul de putere ipmi) nu funcționează în această situație. Trebuie fie să mușezi fizic cablul, fie să blochezi alimentarea de la distanță. În această situație, priza IP ajută.
Se pare ca acesta (fragmentul panoului de control pentru serverele.com/servers.ru):
Evident, în aceste condiții, rebootarea va avea loc într-un scenariu dur, dar cu siguranță va trece.