Continuăm să ne aprofundăm în fascinanta lume a troubleshooting-ului prin jurnalele de log. Am convenit asupra semnificației termenilor de bază și am aruncat o privire asupra structurii generale a Veeam, ca aplicație unică. Sarcina pentru această sesiune este să înțelegem cum se formează fișierele jurnal, ce informații sunt conținute în ele și de ce arată așa cum arată.
Ce părere aveți despre ceea ce sunt aceste «jurnale»? Din opinia celor mai mulți, jurnalele oricărei aplicații ar trebui să aibă rolul unei entități omnipotente, care în cea mai mare parte a timpului trăiește undeva în fundal, dar în momentul potrivit apare din neant în armuri 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ții separate ale bazei de date. Iar după o eroare, ar trebui să indice imediat cum să se corecteze. Și ar trebui să încapă toate acestea într-un mic spațiu de câteva megabytes, nu mai mult. E doar text! Nu e posibil ca fișierele text să ocupe zeci de gigabytes, am auzit asta undeva!
Așadar, jurnalele
În lumea reală, jurnalele sunt doar arhive de informații diagnostice. Și ce ar trebui să conțină, de unde ar trebui să provină informațiile pentru stocare și cât de detaliate ar trebui să fie, depinde de dezvoltatori. Unii optează pentru minimalism, păstrând înregistrări de tip ON/OFF, iar alții încearcă să strângă tot ce pot atinge. Deși există și o variantă intermediară, denumită Logging Level, în care îți poți specifica cât de detaliată vrei să fie informația păstrată și cât de mult spațiu suplimentar ai pe discuri =) La VBR, sunt șase astfel de niveluri, de altfel. Și, credeți-mă, nu doriți să vedeți ce se întâmplă atunci când aveți un jurnal detaliat, cu prea mult spațiu liber pe disc.
Bine. Am înțeles aproximativ ce dorim să păstrăm, dar apare o întrebare legitimă: de unde să obținem aceste informații? O parte dintre evenimentele pentru logare, desigur, le generăm noi prin procesele noastre interne. Dar ce facem când are loc o interacțiune cu mediul extern? Pentru a nu cădea în haosul complet al soluțiilor improvizate, Veeam are tendința de a nu reinventa roata. Întotdeauna, când există deja un API gata, o funcție încorporată în sistem, o bibliotecă etc., vom acorda prioritate opțiunilor existente, înainte de a începe să construim soluții ingineresque. Deși acestea din urmă sunt destul de numeroase. De aceea, în analiza jurnalelor, este important să înțelegem că majoritatea erorilor provin din mesajele de la API-urile externe, apeluri de sistem și alte biblioteci. În acest caz, rolul VBR se reduce la trimiterea acestor erori în fișierele de logare așa cum sunt. Iar sarcina principală a utilizatorului este să învețe să înțeleagă care linie provine de la cine și pentru ce răspunde acel „cine”. Prin urmare, dacă codul de eroare din jurnalul VBR te duce pe pagina MSDN, este în regulă și corect.
După cum am convenit anterior: Veeam este o aplicație SQL-based. Asta înseamnă că toate setările, toate informațiile și, în general, tot ce este necesar pentru funcționarea normală – totul este stocat în baza sa de date. De aici derivă o adevărată adevăr: ceea ce nu se află în jurnale, cel mai probabil se află în bază. Dar aceasta nu este o soluție perfectă: unele lucruri nu se regăsesc nici în jurnalele locale ale componentelor Veeam, nici în baza sa de date. Așadar, trebuie să învățăm să studiem jurnalele gazdelor, jurnalele mașinii locale și jurnalele tuturor celor care participă la procesul de backup și restaurare. Uneori, chiar nu există informații necesare nicăieri. Asta este calea.
Câteva exemple de astfel de API-uri
Această listă nu are scopul de a fi exhaustivă, așa că nu trebuie să cauți adevărul în ultima instanță în ea. Sarcina ei este doar să arate cele mai frecvente API-uri externe și tehnologii utilizate în produsele noastre.
Să începem cu VMware.
Primul în listă va fi vSphere API. Este utilizat pentru autentificare, citirea ierarhiei, crearea și ștergerea snapshot-urilor, solicitarea informațiilor despre mașini și multe (foarte multe) alte lucruri. Funcționalitatea soluției este foarte extinsă, așa că tuturor celor interesați le recomand referința API VMware vSphere pentru versiunea și . Pentru versiuni mai actuale, totul se poate găsi ușor pe Google.
VIX API. Magia neagră a hipervizorului, pentru care există o listă separată de . VMware API pentru lucrul cu fișiere pe gazdă fără a se conecta la acestea prin rețea. O opțiune de ultimă instanță, atunci când trebuie să transferi un fișier într-o mașină pentru care nu există un canal de comunicare mai bun. Reprezintă o durere și suferință dacă fișierul este mare, iar 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, un lucru similar se numește PowerShell Direct. Dar așa a fost doar până la apariția
vSphere Web Services API . Începând cu vSphere 6.0 (aproximativ, deoarece acest API a fost prezentat pentru prima dată în versiunea 5.5) este utilizat pentru a lucra cu mașinile virtuale și deja aproape peste tot a înlocuit VIX. Practic, este un alt API pentru gestionarea vSphere. Cei interesați pot să consulte ghid excelent.
VDDK (. Virtual Disk Development Kit). O bibliotecă despre care s-a vorbit parțial în această . Este utilizată pentru citirea discurilor virtuale. Cu mult timp în urmă era parte din VIX, dar cu timpul a fost separată într-un produs distinct. În schimb, având drepturi de succesor, folosește aceleași coduri de eroare ca și VIX. Dar dintr-un motiv oarecare, SDK-ul nu conține nicio descriere a acestor erori. Prin urmare, metodologic s-a descoperit că erorile VDDK cu alte coduri sunt de fapt o translație din binar în cod zecimal. Se compune din două părți – prima jumătate reprezintă informații nedocumentate despre context, iar partea a doua – erorile tradiționale VIX/VDDK. De exemplu, dacă vedem:
Eroare VDDK: 21036749815809.Eroare necunoscută
Atunci convertim cu încredere în hex și obținem 132200000001. Începutul neinformativ 132200 este pur și simplu ignorat, iar restul va fi codul nostru de eroare (VDDK 1: Eroare necunoscută). Despre cele mai frecvente erori VDDK, de fapt, a fost scris recent un .
Acum să ne uităm la WIndows.
Aici tot ce este necesar și important pentru noi poate fi găsit în standardul Event Viewer. Dar există o problemă: conform unei tradiții vechi, Windows înregistrează nu un text complet al erorii, ci doar numărul acesteia. De exemplu, eroarea 5 – este „Acces interzis”, iar 1722 – este „Serverul RPC nu este disponibil”, iar 10060 – este „Conexiune expirat”. Sigur că este grozav dacă îți amintești cele mai cunoscute, dar ce să faci cu cele neverificate până acum?
Şi pentru ca viața să nu pară complet un răsfăț, erorile sunt stocate și sub formă hexazecimală, cu prefixul 0x8007. De exemplu, 0x8007000e înseamnă de fapt 14, Out of Memory. De ce și pentru cine a fost făcut așa — este un mister acoperit de întuneric. Totuși, lista completă a erorilor poate fi descărcată gratuit și fără SMS de la .
Apropo, uneori întâlnim și alte prefixe, nu doar 0x8007. Într-o asemenea situație nefericită, pentru a înțelege HRESULT („handle de rezultat”) trebuie să ne adâncim și mai mult în pentru dezvoltatori. În viața de zi cu zi, nu vă recomand așa ceva, dar dacă sunteți copleșiți de circumstanțe sau pur și simplu sunteți curioși, acum știți ce să faceți.
Dar cei de la Microsoft au fost puțin mai îngăduitori cu noi și au dat lumii utilitarul . Este un mic fragment de fericire în consolă care poate traduce codurile de eroare în termeni umani fără a utiliza Google. Funcționează cam așa.
C:UsersrootDesktop>err.exe 0x54f
# pentru hexazecimal 0x54f / zecimal 1359
ERROR_INTERNAL_ERROR winerror.h
# A apărut o eroare internă.
# ca un HRESULT: Severitate: SUCCES (0), FACILITATE_NULL (0x0), Cod 0x54f
# pentru hexazecimal 0x54f / zecimal 1359
ERROR_INTERNAL_ERROR winerror.h
# A apărut o eroare internă.
# 2 potriviri găsite pentru "0x54f"Se pune o întrebare legitimă: de ce nu scriem imediat o interpretare în jurnale, lăsând aceste coduri misterioase? Răspunsul se regăsește în aplicațiile externe. Când faci tu însuți un apel WinAPI, interpretarea răspunsului nu este deloc dificilă, deoarece există chiar un apel special WinAPI pentru asta. Dar, așa cum s-a spus, în jurnalele noastre ajunge tot ce primim în răspunsuri. Și aici ar trebui să monitorizăm constant acest flux de conștiință, să extragem bucăți de erori Windows, să le interpretăm și să le inserăm înapoi. Să fim sinceri, nu este cea mai captivantă activitate.
Windows File Management API este folosit în diverse moduri în gestionarea fișierelor. Crearea fișierelor, ștergerea, deschiderea pentru scriere, lucrul cu atributele și altele, și altele.
Menționat anterior PowerShell Direct ca un echivalent al VIX API în lumea Hyper-V. Din păcate, nu este atât de flexibil: există multe restricții funcționale, nu funcționează cu fiecare versiune de gazdă și cu foarte multe dintre gazdele virtuale.
RPC (Remote Procedure Call) Cred că nu există o persoană care a lucrat cu Windows și care să nu fi văzut erori legate de RPC. În ciuda concepției populare, acesta nu este un protocol unitar, ci orice protocol client-server care respectă o serie de parametri. Totuși, dacă în jurnalele noastre apare o eroare RPC, în 90% din cazuri aceasta va fi o eroare de la Microsoft RPC, care face parte din DCOM (Distributed Component Object Model). Pe internet există o cantitate imensă de documentație pe acest subiect, totuși cea mai mare parte este destul de învechită. Dar, dacă există un interes arzător de a studia subiectul, pot recomanda articole , și o listă lungă .
Principalele cauze ale apariției erorilor RPC în jurnalele noastre sunt încercările eșuate de interacțiune între componentele VBR (server > proxy, de exemplu) și, cel mai adesea, din cauza problemelor de conectivitate.
Cea mai comună dintre toate este eroarea The RPC server is unavailable (1722). Pe scurt, clientul nu a reușit să stabilească o conexiune cu serverul. Cum și de ce — nu există un răspuns unitar, dar de obicei este o problemă de autentificare sau de acces la rețea până la portul 135. Ultima este caracteristică infrastructurilor cu alocare dinamică a porturilor. Pe acest subiect există chiar . Iar Microsoft are pentru identificarea cauzelor defectării.
A doua eroare ca popularitate: There are no more endpoints available from the endpoint mapper (1753). Clientul sau serverul RPC nu au reușit să-și aloce un port. Apare de obicei atunci când serverul (în cazul nostru, mașina gazdă) a fost configurat pentru alocarea dinamică a porturilor dintr-un interval restrâns, care s-a epuizat. Și dacă privim din perspectiva clientului (în cazul nostru, serverul VBR), înseamnă că VeeamVssAgent-ul nostru fie nu s-a pornit, fie nu a fost înregistrat ca interfață RPC. Pe acest subiect de asemenea există .
Și pentru a finaliza topul celor 3 erori RPC, să ne amintim de eroarea RPC function call failed (1726). Aceasta apare dacă conexiunea a fost stabilită, dar cererile RPC nu sunt procesate. De exemplu, solicităm informații despre starea VSS (poate tocmai se face o copie shadow și noi încercăm să intervenim), iar răspunsul nostru este tăcere și ignorare.
API de backup pe bandă Windows este necesar pentru a lucra cu biblioteci sau unități cu bandă. Așa cum am menționat la început: să scriem proprii drivere și să ne chinuim apoi cu suportul fiecărui dispozitiv nu ne aduce nicio satisfacție. Prin urmare, Veeam nu are drivere proprii. Totul se face prin API-ul standard, al cărui suport este implementat de furnizorii de hardware. Așa că este mult mai logic, nu-i așa?
SMB/CIFS Toată lumea le scrie din obișnuință, deși puțini își amintesc că CIFS (Common Internet File System) este doar o versiune privată a SMB (Server Message Block). Așadar, nu e nimic rău în generalizarea acestor concepte. Samba, pe de altă parte, este implementarea Linux/Unix și are propriile sale particularități, dar am deviat de la subiect. Ceea ce este important aici: atunci când Veeam cere să scrie ceva printr-un drum UNC (serverdirectory), serverul folosește ierarhia driverelor sistemului de fișiere, inclusiv mup și mrxsmb, pentru a scrie pe share. Prin urmare, aceste drivere vor genera și erorile.
Nu se poate să scapi fără Winsock API. Dacă există ceva de făcut prin rețea, VBR funcționează prin Windows Socket API, cunoscut pe scară largă sub numele de Winsock. Așadar, dacă vedem în jurnal o legătură IP:Port, acesta este. În documentația oficială există o listă destul de bună a posibilelor .
Menționat anterior WMI (Windows Management Instrumentation) — acesta este un API omnipotent pentru gestionarea tuturor și a tuturor în lumea Windows. De exemplu, atunci când lucrăm cu Hyper-V, aproape toate cererile către gazdă se fac prin intermediul acestuia. Pe scurt, este un lucru complet indispensabil și foarte puternic în capacitățile sale. În încercările de a ajuta să aflăm unde și ce s-a stricat, instrumentul încorporat WBEMtest.exe este de mare ajutor.
Și ultimul pe listă, dar deloc cel din urmă ca importanță — VSS (Volume Shadow Storage). Subiectul este atât de inepuizabil și misterios cât de multă documentație s-a scris despre el. Shadow Copy este cel mai ușor de înțeles ca un tip special de snapshot, care de fapt acesta este. Datorită lui, în VMware putem face backup-uri aplicație-consistente, iar în Hyper-V practic totul. Am planificat să scriu un articol separat cu o sinteză despre VSS, dar până atunci, puteți încerca să citiți . Doar fiți atenți, deoarece încercarea de a înțelege VSS pe fugă poate duce la dureri de cap.
Pe acest subiect, cred că ne putem opri. Consider că am explicat cele mai fundamentale aspecte, așa că în următorul capitol ne vom uita la loguri. Dar dacă mai aveți întrebări, nu ezitați să le adresați în comentarii.
Sursa: habr.com
