Ne continuăm imersiunea în lumea fascinantă a ghicirii... depanare prin jurnal. ÎN am convenit asupra semnificației termenilor de bază și am analizat structura generală a Veeam ca o singură aplicație cu un singur ochi. Sarcina pentru acesta este de a afla cum sunt formate fișierele jurnal, ce fel de informații sunt afișate în ele și de ce arată așa cum arată.
Ce crezi că sunt aceste „bușteni”? Potrivit celor mai mulți, jurnalelor oricărei aplicații ar trebui să li se atribuie rolul unui fel de entitate omnipotentă care de cele mai multe ori vegeta undeva în curtea din spate, dar la momentul potrivit apare de nicăieri în armură strălucitoare și salvează pe toată lumea. Adică ar trebui să conțină totul, de la cele mai mici erori din fiecare componentă până la tranzacțiile individuale ale bazei de date. Și astfel încât după eroare s-a scris imediat cum să o remediez. Și toate acestea ar trebui să încapă în câțiva megaocteți, nu mai mult. Este doar text! Fișierele text nu pot lua zeci de gigaocteți, am auzit-o pe undeva!
Deci bustenii
În lumea reală, jurnalele sunt doar o arhivă de informații de diagnosticare. Și ce să stocați acolo, de unde să obțineți informații pentru stocare și cât de detaliat ar trebui să fie, este la latitudinea dezvoltatorilor înșiși să decidă. Cineva urmează calea minimalismului ținând înregistrări ale nivelului ON / OFF, iar cineva grebla cu sârguință tot ce poate ajunge. Deși există și o opțiune intermediară cu posibilitatea de a selecta așa-numitul Nivel de înregistrare, atunci când tu însuți indicați cât de detaliate doriți să stocați și cât spațiu suplimentar pe disc aveți =) VBR are șase astfel de niveluri, de altfel. Și, credeți-mă, nu doriți să vedeți ce se întâmplă cu cea mai detaliată logare cu spațiu liber pe disc.
Amenda. Am înțeles aproximativ ce vrem să salvăm, dar apare o întrebare legitimă: de unde să obținem aceste informații? Desigur, facem parte din evenimentele pentru înregistrarea noastră prin procesele noastre interne. Dar ce să faci când există o interacțiune cu mediul extern? Pentru a nu aluneca într-un iad de cârje și biciclete, Veeam tinde să nu inventeze invenții care au fost deja inventate. Ori de câte ori există un API gata făcut, o funcție încorporată, o bibliotecă etc., vom acorda preferință opțiunilor gata făcute înainte de a începe să ne îngrădim dispozitivele. Deși și acesta din urmă este suficient. Prin urmare, atunci când analizați jurnalele, este important să înțelegeți că cea mai mare parte a erorilor revine mesajelor de la API-uri terțe, apeluri de sistem și alte biblioteci. În acest caz, rolul VBR se reduce la redirecționarea acestor erori către fișierele jurnal așa cum sunt. Și sarcina principală a utilizatorului este să învețe să înțeleagă care linie este de la cine și de ce este responsabil acest „cine”. Deci, dacă un cod de eroare din jurnalul VBR vă duce la o pagină MSDN, este bine și corect.
După cum am convenit mai devreme: Veeam este o așa-numită aplicație bazată pe SQL. Aceasta înseamnă că toate setările, toate informațiile și, în general, tot ceea ce este necesar doar pentru funcționarea normală - totul este stocat în baza sa de date. De aici adevărul simplu: ceea ce nu este în jurnale este cel mai probabil în baza de date. Dar nici acesta nu este un glonț de argint: unele lucruri nu sunt în jurnalele locale ale componentelor Veeam și nici în baza de date a acesteia. Prin urmare, trebuie să învățați cum să studiați jurnalele gazdă, jurnalele mașinii locale și jurnalele a tot ceea ce este implicat în procesul de backup și restaurare. Și se întâmplă, de asemenea, că informațiile necesare nu sunt disponibile nicăieri. Acesta este drumul.
Câteva exemple de astfel de API-uri
Această listă nu își propune să fie excepțional de completă, așa că nu este nevoie să căutați adevărul suprem în ea. Scopul său este doar de a afișa cele mai comune API-uri și tehnologii terțe utilizate în produsele noastre.
Să începem VMware.
Primul pe listă va fi vSphere API. Folosit pentru autentificare, citirea ierarhiei, crearea și ștergerea instantaneelor, solicitarea de informații despre mașini și multe (foarte multe) altele. Funcționalitatea soluției este foarte largă, așa că pot recomanda VMware vSphere API Reference pentru versiune и . Pentru versiuni mai actuale, totul este doar căutat pe google.
VIX API. Magia neagră a hipervizorului, pentru care există un separat . VMware API pentru lucrul cu fișiere de pe gazdă fără a vă conecta la ele prin rețea. O variantă de ultimă instanță atunci când trebuie să puneți un fișier într-o mașină la care nu există un canal de comunicare mai bun. Este durere și suferință dacă fișierul este mare și gazda este încărcată. Dar aici funcționează regula că chiar și 56,6 Kb / s este mai bine decât 0 Kb / s. În Hyper-V, acest lucru se numește PowerShell Direct. Dar asta a fost doar înainte
API-ul vSpehere Web Services Pornind de la vSphere 6.0 (aproximativ, deoarece acest API a fost introdus pentru prima dată în versiunea 5.5) este folosit pentru a lucra cu mașinile invitate și a înlocuit VIX aproape peste tot. De fapt, acesta este un alt API pentru gestionarea vSphere. Pentru cei interesați, recomand să studieze manual.
VDDK (Virtual Disk Development Kit). Biblioteca, despre care s-a discutat parțial în aceasta . Folosit pentru a citi discuri virtuale. Pe vremuri a făcut parte din VIX, dar de-a lungul timpului a fost mutat într-un produs separat. Dar ca moștenitor, folosește aceleași coduri de eroare ca și VIX. Dar din anumite motive, nu există o descriere a acestor erori în SDK-ul în sine. Prin urmare, s-a descoperit empiric că erorile VDDK cu alte coduri sunt doar o traducere din cod binar în cod zecimal. Este format din două părți - prima jumătate este informații nedocumentate despre context, iar a doua parte este tradiționalele erori VIX / VDDK. De exemplu, dacă vedem:
VDDK error: 21036749815809.Unknown error
Apoi convertim cu îndrăzneală acest lucru în hex și obținem 132200000001. Îndepărtăm pur și simplu începutul neinformativ al lui 132200, iar restul va fi codul nostru de eroare (VDDK 1: Eroare necunoscută). Despre cele mai frecvente erori VDDK, a existat recent un separat .
Acum să ne uităm la Ferestre.
Aici, tot ceea ce este cel mai necesar și important pentru noi poate fi găsit în standard Vizualizator de eveniment. Dar există o captură: conform unei lungi tradiții, Windows nu înregistrează textul complet al erorii, ci doar numărul acesteia. De exemplu, eroarea 5 este „Acces refuzat”, iar 1722 este „Serverul RPC nu este disponibil”, iar 10060 este „Conexiune expirată”. Desigur, este grozav dacă îți amintești de cele mai faimoase, dar cum rămâne cu cele nevăzute până acum?
Și pentru ca viața să nu pară deloc miere, erorile sunt stocate și în formă hexazecimală, cu prefixul 0x8007. De exemplu, 0x8007000e este de fapt 14, Memorie epuizată. De ce și pentru cine s-a făcut acest lucru este un mister învăluit în întuneric. Cu toate acestea, o listă completă de erori poate fi descărcată gratuit și fără SMS de la .
Apropo, uneori există și alte prefixe, nu doar 0x8007. Într-o situație atât de tristă, pentru a înțelege HRESULT („mânerul rezultat”), trebuie să aprofundezi și mai mult în pentru dezvoltatori. În viața obișnuită, nu te sfătuiesc să faci asta, dar dacă te-ai apăsat brusc de perete sau ești doar curios, acum știi ce să faci.
Dar tovarășii de la Microsoft s-au făcut puțin milă de noi și au arătat lumii o utilitate . Aceasta este o mică parte din fericirea consolei care poate traduce codurile de eroare în om fără a utiliza Google. Funcționează așa.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Apare o întrebare legitimă: de ce nu scriem imediat decriptarea în jurnale, ci lăsăm aceste coduri misterioase? Răspunsul este în aplicațiile de la terți. Când trageți un apel WinAPI, nu este dificil să descifrați răspunsul acestuia, deoarece există chiar și un apel WinAPI special pentru acest lucru. Dar, așa cum am menționat deja, tot ceea ce ne vine doar ca răspunsuri intră în jurnalele noastre. Și aici, pentru a-l decripta, ar trebui să monitorizeze constant acest flux de conștiință, să scoată din el bucăți cu erori de Windows, să le decripteze și să le lipească înapoi. Să fim sinceri, nu cea mai interesantă activitate.
API-ul Windows File Management folosit în toate modurile posibile atunci când lucrați cu fișiere. Crearea fișierelor, ștergerea, deschiderea pentru scriere, lucrul cu atribute și așa mai departe și așa mai departe.
menționat mai sus PowerShell Direct ca un analog al API-ului VIX în lumea Hyper-V. Din păcate, nu atât de flexibil: o mulțime de restricții privind funcționalitatea, nu funcționează cu fiecare versiune a gazdei și nu cu toți oaspeții.
RPC (Remote Procedure Call) Nu cred că există o singură persoană care a lucrat cu WIndows care să nu fi văzut erori legate de RPC. În ciuda concepției greșite populare, acesta nu este un singur protocol, ci orice protocol client-server care satisface o serie de parametri. Cu toate acestea, dacă există o eroare RPC în jurnalele noastre, 90% din timp va fi o eroare de la Microsoft RPC, care face parte din DCOM (Distributed Component Object Model). Puteți găsi o cantitate imensă de documentație pe acest subiect pe net, dar partea leului este destul de depășită. Dar dacă există o dorință acută de a studia subiectul, atunci pot recomanda articole , si lista lunga .
Principalele cauze ale erorilor RPC din jurnalele noastre sunt încercările eșuate de a comunica între componentele VBR (server > proxy, de exemplu) și cel mai adesea din cauza problemelor de comunicare.
Primul top dintre toate topurile este eroarea Serverul RPC este indisponibil (1722). În termeni simpli, clientul nu a putut stabili o conexiune cu serverul. Cum și de ce - nu există un singur răspuns, dar de obicei este o problemă cu autentificarea sau cu accesul la rețea la portul 135. Acesta din urmă este tipic pentru infrastructurile cu alocare dinamică a portului. Pe acest subiect, există chiar . Și Microsoft are pentru a găsi cauza defecțiunii.
A doua cea mai populară eroare: nu mai sunt puncte finale disponibile din mapatorul punctelor finale (1753). Clientul sau serverul RPC nu a reușit să își atribuie un port. De obicei, apare atunci când serverul (în cazul nostru, mașina oaspete) a fost configurat să aloce dinamic porturi dintr-un interval restrâns care s-a încheiat. Și dacă vă conectați din partea clientului (în cazul nostru, serverul VBR), aceasta înseamnă că VeeamVssAgent fie nu a pornit, fie nu a fost înregistrat ca interfață RPC. Există și pe această temă .
Ei bine, pentru a completa primele 3 erori RPC, să ne amintim că apelul funcției RPC a eșuat (1726). Apare dacă conexiunea a fost stabilită, dar cererile RPC nu sunt procesate. De exemplu, solicităm informații despre starea VSS (deodată în acest moment se face acolo o mină în umbră și încercăm să urcăm), iar ca răspuns la noi, tăcem și ignorăm.
API-ul Windows Tape Backup necesare pentru a lucra cu biblioteci de benzi sau unități. După cum am menționat la început: nu ne face plăcere să ne scriem propriile drivere și apoi să suferim cu sprijinul fiecărui dispozitiv. Prin urmare, vim nu are drivere proprii. Totul printr-un API standard, al cărui suport este implementat de către furnizorii de hardware înșiși. Mult mai logic, nu?
SMB / CIFS Din obișnuință, toată lumea le scrie una lângă alta, deși nu toată lumea își amintește că CIFS (Common Internet File System) este doar o versiune privată a SMB (Server Message Block). Deci nu este nimic greșit în generalizarea acestor concepte. Samba este deja o implementare LinuxUnix și are propriile sale particularități, dar mă opresc. Ce este important aici: atunci când Veeam cere să scrie ceva în calea UNC (serverdirectory), serverul folosește ierarhia driverelor sistemului de fișiere, inclusiv mup și mrxsmb, pentru a scrie în minge. În consecință, aceste drivere vor genera și erori.
Nu pot face fără Winsock API. Dacă trebuie făcut ceva prin rețea, VBR funcționează prin API-ul Windows Socket, cunoscut sub numele de Winsock. Deci, dacă vedem o grămadă de IP:Port în jurnal, acesta este. Documentația oficială are o listă bună de posibile .
menționat mai sus WMI (Windows Management Instrumentation) este un fel de API atotputernic pentru gestionarea tuturor și a tuturor celor din lumea Windows. De exemplu, atunci când lucrați cu Hyper-V, aproape toate solicitările către gazdă trec prin acesta. Într-un cuvânt, lucrul este absolut de neînlocuit și foarte puternic în capacitățile sale. În încercarea de a ajuta la aflarea unde și ce este defect, instrumentul încorporat WBEMtest.exe ajută foarte mult.
Și ultimul pe listă, dar nu în ultimul rând ca importanță - VSS (Volume Shadow Storage). Subiectul este la fel de inepuizabil și misterios cu cât s-a scris multă documentație pe el. Shadow Copy este cel mai simplu înțeles ca un tip special de instantaneu, ceea ce în esență este. Datorită lui, puteți face copii de rezervă conforme aplicației în VMware și aproape totul în Hyper-V. Am de gând să fac un articol separat, cu o strângere pe VSS, dar deocamdată poți încerca să citești . Doar fii atent, pentru că. încercarea de a înțelege VSS într-o clipă poate duce la leziuni cerebrale.
Pe asta, poate, ne putem opri. Consider că sarcina de a explica cele mai elementare lucruri a fost finalizată, așa că în capitolul următor ne vom uita deja la jurnalele. Dar dacă aveți întrebări, nu ezitați să le întrebați în comentarii.
Sursa: www.habr.com