Da induve venenu i logs ? Veeam Log Diving

Cuntinuemu a nostra immersione in u mondu affascinante di guessing ... risoluzione di prublemi da logs. IN articulu precedente avemu accunsentutu nantu à u significatu di i termini basi è fighjemu a struttura generale di Veeam cum'è una sola applicazione cù un ochju. U compitu per questu hè di capisce cumu si formanu i fugliali di log, chì tipu d'infurmazioni sò affissati in elli è perchè si vedenu a manera di vede.

Chì pensate chì sò questi "logs" ? Sicondu a maiò parte, i logs di ogni applicazione deve esse attribuitu u rolu di un tipu d'entità omnipotente chì a maiò parte di u tempu vegetate in un locu in u patiu, ma à u mumentu ghjustu appare da nunda in armatura brillanti è salva à tutti. Vale à dì, duveranu cuntene tuttu, da i minimi errori in ogni cumpunente à e transazzioni di basa di dati individuali. È cusì chì dopu à l'errore hè statu subitu scrittu cumu altrimenti per riparà. È tuttu ciò chì deve esse in un paru di megabyte, micca più. Hè solu testu! I schedarii di testu ùn ponu micca piglià decine di gigabyte, l'aghju intesu in qualchì locu!

Allora i logs

In u mondu reale, i logs sò solu un archiviu di infurmazione di diagnostica. E ciò chì guardà quì, induve uttene infurmazioni per u almacenamentu è quantu detallatu deve esse, hè à i sviluppatori stessi di decide. Qualchissia seguita a strada di u minimalismu mantenendu registri di u nivellu ON / OFF, è qualcunu rastrella diligentemente tuttu ciò chì pò ghjunghje. Ancu s'ellu ci hè ancu una opzione intermedia cù a capacità di selezziunà u chjamatu Livellu di Logging, quandu tù stessu indicà quantu l'infurmazioni detallati chì vulete almacenà è quantu spaziu di discu extra avete =) VBR hà sei tali livelli, per via. È, crede à mè, ùn vulete micca vede ciò chì succede cù u logu più detallatu cù u spaziu liberu nantu à u vostru discu.

Va bè. Avemu capitu apprussimatamente ciò chì vulemu salvà, ma una quistione legittima si sorge: induve uttene sta infurmazione? Di sicuru, facemu parte di l'avvenimenti per u logu da i nostri prucessi interni. Ma chì fà quandu ci hè una interazzione cù l'ambiente esternu? Per ùn sbulicà in un infernu di crutches è biciclette, Veeam ùn tende micca à inventà invenzioni chì sò digià inventati. Ogni volta chì ci hè una API pronta, una funzione integrata, una biblioteca, etc., daremu preferenza à l'opzioni pronti prima di principià à recintà i nostri contraptions. Ancu l'ultime hè ancu abbastanza. Per quessa, quandu analizà i logs, hè impurtante capisce chì a parte di u leone di l'errori cade nantu à i missaghji da l'API di terzu partitu, e chjama di u sistema, è altre biblioteche. In questu casu, u rolu di VBR hè di trasmette questi errori à i fugliali di log. È u compitu principalu di l'utilizatore hè di amparà à capisce quale linea hè da quale, è ciò chì questu "chì" hè rispunsevule. Allora se un codice d'errore da u logu VBR vi porta à una pagina MSDN, hè bella è curretta.

Cume avemu accunsentutu prima: Veeam hè una applicazione chjamata basata in SQL. Questu significa chì tutti i paràmetri, tutte l'infurmazioni è in generale tuttu ciò chì hè necessariu solu per u funziunamentu normale - tuttu hè guardatu in a so basa di dati. Da quì a verità simplice: ciò chì ùn hè micca in i logs hè più prubabile in a basa di dati. Ma questu ùn hè ancu una bala d'argentu: alcune cose ùn sò micca in i logs lucali di cumpunenti Veeam, nè in a so basa di dati. Per quessa, avete bisognu à amparà à studià i logs d'ospiti, i logs di a macchina lucale è i logs di tuttu ciò chì hè implicatu in u prucessu di salvezza è restaurà. È succede ancu chì l'infurmazioni necessarii ùn sò micca dispunibili in ogni locu. Questu hè u modu. 

Alcuni esempi di tali API

Questa lista ùn hà micca scopu di esse eccezziunale cumpletu, cusì ùn ci hè bisognu di circà l'ultima verità in questu. U so scopu hè solu di mustrà l'API è e tecnulugia di terzu più cumuni utilizati in i nostri prudutti.

Cuminciamu cù Panda. 

U primu nantu à a lista serà vSphere API. Adupratu per l'autentificazione, leghje a gerarchia, creà è sguassate snapshots, dumandendu informazioni nantu à e macchine, è assai (assai) di più. A funziunalità di a suluzione hè assai larga, cusì possu ricumandemu u VMware vSphere API Reference per a versione 5.5 и 6.0. Per versioni più attuali, tuttu hè solu Googled.

VIX API. A magia negra di l'hypervisor, per quale ci hè un separatu lista di errore. VMware API per travaglià cù i fugliali nantu à l'ospite senza cunnette cù elli nantu à a reta. Una variante di l'ultimu risorsu quandu avete bisognu di mette un schedariu in una macchina à quale ùn ci hè micca un canale di cumunicazione megliu. Hè dulore è soffrenu se u schedariu hè grande è l'ospitu hè carricu. Ma quì a regula funziona chì ancu 56,6 Kb / s hè megliu cà 0 Kb / s. In Hyper-V, sta cosa hè chjamata PowerShell Direct. Ma questu era solu prima

vSpehere Web Services API Partendu da vSphere 6.0 (circa, postu chì sta API hè stata introdutta per a prima volta nantu à a versione 5.5) hè utilizatu per travaglià cù e macchine invitati è hà supplanted VIX quasi in ogni locu. In fatti, questu hè un altru API per a gestione di vSphere. Per quelli chì sò interessati, vi cunsigliu di studià grande manuale. 

VDDK (Kit di sviluppu di discu virtuale). A biblioteca, chì hè statu parzialmente discutitu in questu articulu. Adupratu per leghje dischi virtuali. Una volta era parte di u VIX, ma cù u tempu hè stata spustata in un pruduttu separatu. Ma cum'è eredi, usa i stessi codici d'errore cum'è VIX. Ma per una certa ragione, ùn ci hè micca una descrizzione di sti errori in u SDK stessu. Dunque, hè statu scupertu empirically chì l'errore VDDK cù altri codici sò solu una traduzzione da u codice binariu à u codice decimale. Hè custituitu di duie parte - a prima mità hè infurmazione micca documentata nantu à u cuntestu, è a seconda parte hè l'errore tradiziunale VIX / VDDK. Per esempiu, se vedemu:

VDDK error: 21036749815809.Unknown error

Allora cunvertemu audacemente questu in hex è uttene 132200000001. Simpricamente scartate l'iniziu uninformativu di 132200, è u restu serà u nostru codice d'errore (VDDK 1: Errore scunnisciutu). Riguardu à l'errori VDDK più frequenti, ci era pocu pocu un separatu un articulu.

Avà fighjemu Finestre.

Quì, tuttu ciò chì hè più necessariu è impurtante per noi pò esse truvatu in u standard Visor di avvene. Ma ci hè una catch: sicondu una longa tradizione, Windows ùn hà micca logatu u testu sanu di l'errore, ma solu u so numeru. Per esempiu, l'errore 5 hè "Access denied", è 1722 hè "U servitore RPC ùn hè micca dispunibule", è 10060 hè "Connection timed out". Di sicuru, hè fantasticu s'ellu vi ricurdate di i più famosi, ma chì ne dite di quelli invisibili finu à quì ? 

È cusì chì a vita ùn pare micca u meli, l'errori sò ancu almacenati in forma esadecimale, cù u prefissu 0x8007. Per esempiu, 0x8007000e hè in realtà 14, Fora di Memoria. Perchè è per quale questu hè statu fattu hè un misteru avvoltu in a bughjura. Tuttavia, una lista cumpleta di l'errori pò esse scaricata gratuitamente è senza SMS da devcenter.

Per via, qualchì volta ci sò altri prefissi, micca solu 0x8007. In una situazione cusì triste, per capisce HRESULT ("maniglia di u risultatu"), avete bisognu di sfondate ancu più in documentazione per i sviluppatori. In a vita urdinaria, ùn vi cunsigliu micca di fà questu, ma s'è vo avete pressu u muru di colpu o sò solu curiosi, avà sapete ciò chì fate.

Ma i camaradi di Microsoft hà pigliatu pietà di noi un pocu è hà dimustratu à u mondu una utilità ERR. Questu hè un picculu pezzu di felicità di cunsola chì pò traduce i codici d'errore in umanu senza aduprà Google. Funziona cusì.

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"

Una quistione legittima si sorge: perchè ùn avemu micca scrivite immediatamente a decryption à i logs, ma lasciate questi codici misteriosi? A risposta hè in applicazioni di terze parti. Quandu ti tira qualchi WinAPI chjamate sè stessu, ùn hè micca difficiule di decifrare a so risposta, perchè ci hè ancu una chjamata WinAPI speciale per questu. Ma cum'è digià dettu, tuttu ciò chì vene solu à noi in risposte entra in i nostri logs. E quì, per decifrallu, unu avissi da monitorà constantemente stu flussu di cuscenza, tira fora pezzi cù l'errore di Windows da ellu, decifrate è incollà. Simu onesti, micca l'attività più eccitante.

Windows File Management API utilizatu in ogni modu pussibule quandu u travagliu cù i schedari. Crià i schedari, sguassà, apre per scrive, travaglià cù attributi, è cetara è cetara.

citatu sopra PowerShell Direct cum'è un analogu di l'API VIX in u mondu Hyper-V. Sfurtunatamente, micca cusì flexible: assai restrizioni à e funziunalità, ùn funziona micca cù ogni versione di l'ospiti è micca cù tutti l'invitati.

RPC (Chjama di Procedura Remota) Ùn pensu micca chì ci hè una sola persona chì hà travagliatu cù Windows chì ùn hà micca vistu errori RPC-related. Malgradu u misconception populari, questu ùn hè micca un protokollu unicu, ma qualsiasi protokollu cliente-servitore chì satisface una quantità di parametri. Tuttavia, se ci hè un errore RPC in i nostri logs, 90% di u tempu serà un errore da Microsoft RPC, chì face parte di DCOM (Distributed Component Object Model). Pudete truvà una quantità enorme di documentazione nantu à questu tema nantu à a reta, ma a parte di u leone hè abbastanza antica. Ma s'ellu ci hè un desideriu acutu di studià u tema, allora possu ricumandemu articuli Cosa hè RPC?, comu RPC travaglia è longa lista Errori RPC.

I causi principali di l'errore RPC in i nostri logs sò tentativi falluti di cumunicà trà cumpunenti VBR (server> proxy, per esempiu) è più spessu per prublemi di cumunicazione.

A cima di tutte e cime hè l'errore U servitore RPC ùn hè micca dispunibule (1722). In termini simplici, u cliente ùn pudia micca stabilisce una cunnessione cù u servitore. Cumu è perchè - ùn ci hè micca una sola risposta, ma di solitu hè un prublema cù l'autentificazione o cù l'accessu di a rete à u portu 135. L'ultimu hè tipicu per l'infrastruttura cù l'assignazione di portu dinamica. Nantu à questu tema, ci hè ancu HF separatu. È Microsoft hà guida voluminosa per truvà a causa di u fallimentu.

Secondu errore più populari: Ùn ci sò più punti finali dispunibuli da u mapping endpoint (1753). U cliente o u servitore RPC hà fallutu per assignà un portu. Di solitu accade quandu u servitore (in u nostru casu, a macchina d'ospiti) hè stata cunfigurata per assignà dinamicamente i porti da un intervallu ristrettu chì hè finitu. È se accede da u latu di u cliente (in u nostru casu, u servitore VBR), questu significa chì u nostru VeeamVssAgent o ùn hà micca cuminciatu o ùn hè micca registratu cum'è una interfaccia RPC. Ci hè ancu nantu à questu tema HF separatu.

Ebbè, per compie i Top 3 errori RPC, ricurdatemu a chjama di a funzione RPC falluta (1726). Apparisce se a cunnessione hè stata stabilita, ma e richieste RPC ùn sò micca trattate. Per esempiu, dumandemu infurmazione nantu à u statutu di VSS (di colpu avà una mina d'ombra hè stata fatta quì, è avemu pruvatu à cullà), è in risposta à noi, silenziu è ignurà.

Windows Tape Backup API necessariu per travaglià cù biblioteche di nastri o unità. Cumu l'aghju dettu à u principiu: ùn avemu micca piacè di scrive i nostri cunduttori è dopu soffrenu cù u sustegnu di ogni dispusitivu. Dunque, vim ùn hà micca un driver propiu. Tuttu attraversu una API standard, u supportu di quale hè implementatu da i venditori di hardware stessi. Tantu più logicu, nò ?

SMB / CIFS Fora di l'abitudine, ognunu li scrive fiancu à fiancu, ancu s'ellu ùn tutti si ricordanu chì CIFS (Common Internet File System) hè solu una versione privata di SMB (Server Message Block). Allora ùn ci hè nunda di male à generalizà sti cuncetti. Samba hè digià una implementazione LinuxUnix, è hà e so peculiarità, ma digressu. Ciò chì hè impurtante quì: quandu Veeam dumanda à scrive qualcosa à u percorsu UNC (serverdirectory), u servitore usa a ghjerarchia di i cunduttori di u sistema di schedari, cumpresi mup è mrxsmb, per scrive à u ballò. Per quessa, sti drivers generaranu ancu errori.

Ùn pò fà senza Winsock API. Se qualcosa deve esse fattu nantu à a reta, VBR travaglia attraversu l'API Windows Socket, popularmente cunnisciutu Winsock. Allora s'è no vedemu una mansa di IP: Port in u logu, questu hè. A documentazione ufficiale hà una bona lista di pussibuli sbagli.

citatu sopra WMI (Windows Management Instrumentation) hè un tipu di API onnipotente per gestisce tuttu è tutti in u mondu Windows. Per esempiu, quandu travaglia cù Hyper-V, quasi tutte e dumande à l'ospitu passanu per ellu. In una parolla, a cosa hè assolutamente insustituibile è assai putente in e so capacità. In un tentativu di aiutà à sapè induve è ciò chì hè rottu, u strumentu integratu WBEMtest.exe aiuta assai.

È l'ultimu nantu à a lista, ma micca menu impurtanza - VSS (Volume Shadow Storage). U tema hè cum'è inesauribile è misteriosu quantu a documentazione hè stata scritta nantu à questu. Shadow Copy hè più simplicemente capitu cum'è un tipu speciale di snapshot, chì in essenza hè. Grazie à ellu, pudete fà una copia di salvezza cunsistenti in l'applicazioni in VMware, è quasi tuttu in Hyper-V. Aghju prughjettatu di fà un articulu separatu cù qualchì squeeze in VSS, ma per avà pudete pruvà à leghje sta descrizzione. Solu attenti, perchè. pruvà à capisce VSS in un lampu pò purtà à ferita cerebrale.

Nantu à questu, forse, pudemu piantà. Pensu chì u compitu di spiegà e cose più basi hè finitu, cusì in u prossimu capitulu avemu digià guardà i logs. Ma s'è vo avete qualchì quistione, sentite liberu di dumandà li in i cumenti.

Source: www.habr.com