Continuiamo la nostra immersione nell'affascinante mondo dell'ipotesi ... risoluzione dei problemi tramite registri. IN abbiamo concordato il significato dei termini di base e abbiamo esaminato la struttura generale di Veeam come una singola applicazione con un occhio solo. Il compito di questo è capire come si formano i file di registro, che tipo di informazioni vengono visualizzate in essi e perché hanno l'aspetto che hanno.
Cosa pensi che siano questi "registri"? Secondo i più, ai log di qualsiasi applicazione dovrebbe essere assegnato il ruolo di una sorta di entità onnipotente che il più delle volte vegeta da qualche parte nel cortile di casa, ma al momento giusto appare dal nulla in armatura scintillante e salva tutti. Cioè, dovrebbero contenere tutto, dai minimi errori in ogni componente alle singole transazioni del database. E così dopo l'errore è stato subito scritto in che altro modo risolverlo. E tutto questo dovrebbe stare in un paio di megabyte, non di più. È solo testo! I file di testo non possono contenere decine di gigabyte, l'ho sentito da qualche parte!
Quindi i registri
Nel mondo reale, i registri sono solo un archivio di informazioni diagnostiche. E cosa archiviare lì, dove ottenere le informazioni per l'archiviazione e quanto dovrebbero essere dettagliate, spetta agli sviluppatori stessi decidere. Qualcuno segue il percorso del minimalismo tenendo traccia del livello ON / OFF e qualcuno rastrella diligentemente tutto ciò che può raggiungere. Sebbene esista anche un'opzione intermedia con la possibilità di selezionare il cosiddetto Livello di registrazione, quando tu stesso indichi quante informazioni dettagliate desideri memorizzare e quanto spazio su disco extra hai =) A proposito, VBR ha sei di questi livelli. E, credimi, non vuoi vedere cosa succede con la registrazione più dettagliata con spazio libero sul tuo disco.
Bene. Abbiamo capito approssimativamente cosa vogliamo salvare, ma sorge una domanda legittima: da dove ottenere queste informazioni? Naturalmente, facciamo parte degli eventi per la registrazione noi stessi dai nostri processi interni. Ma cosa fare quando c'è un'interazione con l'ambiente esterno? Per non scivolare in un inferno pece di stampelle e biciclette, Veeam tende a non inventare invenzioni già inventate. Ogni volta che c'è un'API già pronta, una funzione integrata, una libreria, ecc., daremo la preferenza alle opzioni già pronte prima di iniziare a recintare i nostri aggeggi. Anche se quest'ultimo è anche sufficiente. Pertanto, quando si analizzano i log, è importante comprendere che la maggior parte degli errori ricade sui messaggi di API di terze parti, chiamate di sistema e altre librerie. In questo caso, il ruolo di VBR si riduce all'inoltro di questi errori ai file di registro così come sono. E il compito principale dell'utente è imparare a capire quale riga proviene da chi e di cosa è responsabile questo "chi". Quindi, se un codice di errore dal registro VBR ti porta a una pagina MSDN, va bene e corretto.
Come abbiamo concordato in precedenza: Veeam è una cosiddetta applicazione basata su SQL. Ciò significa che tutte le impostazioni, tutte le informazioni e in generale tutto ciò che è necessario solo per il normale funzionamento - tutto è memorizzato nel suo database. Da qui la semplice verità: ciò che non è nei registri è molto probabilmente nel database. Ma neanche questo è un proiettile d'argento: alcune cose non sono nei log locali dei componenti Veeam, né nel suo database. Pertanto, è necessario imparare a studiare i registri dell'host, i registri della macchina locale ei registri di tutto ciò che è coinvolto nel processo di backup e ripristino. E succede anche che le informazioni necessarie non siano disponibili da nessuna parte. Questo è il modo.
Alcuni esempi di tali API
Questo elenco non mira a essere eccezionalmente completo, quindi non è necessario cercare la verità ultima in esso. Il suo scopo è solo quello di mostrare le API e le tecnologie di terze parti più comuni utilizzate nei nostri prodotti.
Iniziamo con VMware.
Il primo della lista sarà API vSphere. Utilizzato per l'autenticazione, la lettura della gerarchia, la creazione e l'eliminazione di istantanee, la richiesta di informazioni sulle macchine e molto (molto) altro. La funzionalità della soluzione è molto ampia, quindi posso consigliare la VMware vSphere API Reference per la versione и . Per le versioni più attuali, tutto è semplicemente cercato su Google.
API VIX. La magia nera dell'hypervisor, per la quale esiste un separato . API VMware per lavorare con i file sull'host senza connettersi ad essi tramite la rete. Un'opzione di ultima istanza quando è necessario inserire un file in una macchina per la quale non esiste un canale di comunicazione migliore. È dolore e sofferenza se il file è grande e l'host è caricato. Ma qui funziona la regola che anche 56,6 Kb / s è meglio di 0 Kb / s. In Hyper-V, questa cosa si chiama PowerShell Direct. Ma questo era solo prima
API dei servizi Web vSpehere A partire da vSphere 6.0 (approssimativamente, poiché questa API è stata introdotta per la prima volta nella versione 5.5) viene utilizzata per lavorare con macchine guest e ha soppiantato VIX quasi ovunque. In effetti, questa è un'altra API per la gestione di vSphere. Per coloro che sono interessati, consiglio di studiare Manuale.
VDDK (Kit di sviluppo del disco virtuale). La biblioteca, che è stata parzialmente discussa in questo . Utilizzato per leggere i dischi virtuali. Una volta faceva parte del VIX, ma nel tempo è stato spostato in un prodotto separato. Ma come erede, usa gli stessi codici di errore del VIX. Ma per qualche ragione, non c'è alcuna descrizione di questi errori nell'SDK stesso. Pertanto, è stato scoperto empiricamente che gli errori VDDK con altri codici sono solo una traduzione dal codice binario al codice decimale. Consiste di due parti: la prima metà è costituita da informazioni non documentate sul contesto e la seconda parte sono i tradizionali errori VIX / VDDK. Ad esempio, se vediamo:
VDDK error: 21036749815809.Unknown error
Quindi lo convertiamo coraggiosamente in esadecimale e otteniamo 132200000001. Scartiamo semplicemente l'inizio non informativo di 132200 e il resto sarà il nostro codice di errore (VDDK 1: errore sconosciuto). Per quanto riguarda gli errori VDDK più frequenti, recentemente c'è stato un file separato .
Ora diamo un'occhiata Finestre.
Qui, tutto ciò che è più necessario e importante per noi si trova nello standard Visualizzatore eventi. Ma c'è un problema: secondo una lunga tradizione, Windows non registra il testo completo dell'errore, ma solo il suo numero. Ad esempio, l'errore 5 è "Accesso negato" e 1722 è "Il server RPC non è disponibile" e 10060 è "Timeout connessione". Certo, è fantastico se ricordi i più famosi, ma che dire di quelli mai visti?
E affinché la vita non sembri affatto dolce, anche gli errori vengono memorizzati in forma esadecimale, con il prefisso 0x8007. Ad esempio, 0x8007000e è in realtà 14, Memoria esaurita. Perché e per chi è stato fatto è un mistero avvolto nell'oscurità. Tuttavia, un elenco completo degli errori può essere scaricato gratuitamente e senza SMS da .
A proposito, a volte ci sono altri prefissi, non solo 0x8007. In una situazione così triste, per comprendere HRESULT ("result handle"), è necessario approfondire ancora di più per gli sviluppatori. Nella vita ordinaria, non ti consiglio di farlo, ma se improvvisamente ti sei schiacciato contro il muro o sei solo curioso, ora sai cosa fare.
Ma i compagni di Microsoft hanno avuto un po' di pietà per noi e hanno mostrato al mondo un'utilità . Questo è un piccolo pezzo di felicità della console che può tradurre i codici di errore in umani senza utilizzare Google. Funziona così.
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"Sorge una domanda legittima: perché non scriviamo subito la decrittazione nei log, ma lasciamo questi misteriosi codici? La risposta è nelle applicazioni di terze parti. Quando estrai tu stesso una chiamata WinAPI, non è difficile decifrare la sua risposta, perché esiste anche una chiamata WinAPI speciale per questo. Ma come già accennato, tutto ciò che ci arriva solo nelle risposte entra nei nostri registri. E qui, per decrittografarlo, bisognerebbe monitorare costantemente questo flusso di coscienza, estrarre da esso pezzi con errori di Windows, decrittografarli e incollarli nuovamente. Siamo onesti, non l'attività più eccitante.
API di gestione dei file di Windows utilizzato in ogni modo possibile quando si lavora con i file. Creazione di file, eliminazione, apertura per la scrittura, utilizzo di attributi e così via.
Menzionato sopra PowerShell diretto come analogo dell'API VIX nel mondo Hyper-V. Sfortunatamente, non così flessibile: molte restrizioni sulla funzionalità, non funziona con tutte le versioni dell'host e non con tutti gli ospiti.
RPC (Remote Procedure Call) Non credo che ci sia una sola persona che ha lavorato con Windows che non abbia visto errori relativi a RPC. Nonostante il malinteso popolare, questo non è un singolo protocollo, ma qualsiasi protocollo client-server che soddisfi una serie di parametri. Tuttavia, se è presente un errore RPC nei nostri registri, il 90% delle volte si tratterà di un errore di Microsoft RPC, che fa parte di DCOM (Distributed Component Object Model). Puoi trovare un'enorme quantità di documentazione su questo argomento in rete, ma la parte del leone è piuttosto obsoleta. Ma se c'è un acuto desiderio di studiare l'argomento, allora posso consigliare articoli , e lunga lista .
Le cause principali degli errori RPC nei nostri log sono i tentativi falliti di comunicare tra i componenti VBR (server > proxy, ad esempio) e molto spesso a causa di problemi di comunicazione.
Il top top tra tutti i top è l'errore Il server RPC non è disponibile (1722). In termini semplici, il client non è riuscito a stabilire una connessione con il server. Come e perché - non esiste una risposta univoca, ma di solito si tratta di un problema con l'autenticazione o con l'accesso alla rete alla porta 135. Quest'ultimo è tipico delle infrastrutture con assegnazione dinamica delle porte. Su questo argomento, c'è anche . E Microsoft ha per trovare la causa del guasto.
Secondo errore più comune: non ci sono più endpoint disponibili dal mappatore di endpoint (1753). Il client o il server RPC non è riuscito ad assegnarsi una porta. Di solito si verifica quando il server (nel nostro caso, la macchina ospite) è stato configurato per allocare dinamicamente le porte da un intervallo ristretto che è terminato. E se accedi dal lato client (nel nostro caso, il server VBR), significa che il nostro VeeamVssAgent non è stato avviato o non è stato registrato come interfaccia RPC. C'è anche su questo argomento .
Bene, per completare i primi 3 errori RPC, ricordiamo che la chiamata alla funzione RPC non è riuscita (1726). Appare se la connessione è stata stabilita, ma le richieste RPC non vengono elaborate. Ad esempio, richiediamo informazioni sullo stato di VSS (improvvisamente in questo momento viene creata una mina ombra lì e stiamo cercando di arrampicarci) e, in risposta a noi, silenzio e ignoranza.
API di backup su nastro di Windows necessari per lavorare con librerie a nastro o unità. Come ho detto all'inizio: non ci piace scrivere i nostri driver e poi soffrire con il supporto di ogni dispositivo. Pertanto, vim non ha driver propri. Tutto attraverso un'API standard, il cui supporto è implementato dagli stessi fornitori di hardware. Molto più logico, vero?
SMB / CIFS Per abitudine, tutti li scrivono uno accanto all'altro, anche se non tutti ricordano che CIFS (Common Internet File System) è solo una versione privata di SMB (Server Message Block). Quindi non c'è niente di sbagliato nel generalizzare questi concetti. Samba è già un'implementazione LinuxUnix e ha le sue peculiarità, ma sto divagando. Ciò che è importante qui: quando Veeam chiede di scrivere qualcosa nel percorso UNC (serverdirectory), il server utilizza la gerarchia dei driver del file system, inclusi mup e mrxsmb, per scrivere sulla palla. Di conseguenza, anche questi driver genereranno errori.
Non posso farne a meno API WinSock. Se qualcosa deve essere fatto sulla rete, VBR funziona tramite l'API Windows Socket, popolarmente nota come Winsock. Quindi, se vediamo un gruppo di IP: Port nel registro, è questo. La documentazione ufficiale ha un buon elenco di possibili .
Menzionato sopra WMI (Windows Management Instrumentation) è una sorta di API onnipotente per la gestione di tutto e tutti nel mondo Windows. Ad esempio, quando si lavora con Hyper-V, quasi tutte le richieste all'host lo attraversano. In una parola, la cosa è assolutamente insostituibile e molto potente nelle sue capacità. Nel tentativo di aiutare a scoprire dove e cosa è rotto, lo strumento integrato WBEMtest.exe aiuta molto.
E l'ultimo della lista, ma non per questo meno importante: VSS (Archiviazione dell'ombra del volume). L'argomento è tanto inesauribile e misterioso quanto tanta documentazione è stata scritta su di esso. Shadow Copy è più semplicemente inteso come un tipo speciale di istantanea, che in sostanza lo è. Grazie a lui, puoi eseguire backup coerenti con l'applicazione in VMware e quasi tutto in Hyper-V. Ho intenzione di fare un articolo separato con un po' di compressione su VSS, ma per ora puoi provare a leggere . Fai solo attenzione, perché. cercare di capire VSS in un lampo può portare a lesioni cerebrali.
Su questo, forse, possiamo fermarci. Considero completato il compito di spiegare le cose più basilari, quindi nel prossimo capitolo esamineremo già i registri. Ma se hai domande, sentiti libero di farle nei commenti.
Fonte: habr.com