Continuiamo la nostra immersione nell'affascinante mondo della risoluzione dei problemi tramite i registri. In abbiamo concordato il significato dei termini di base e date un'occhiata alla struttura generale di Veeam, come un'unica applicazione. L'obiettivo di questa è capire come vengono formati i file di registro, quali informazioni contengono e perché sono strutturati in questo modo.
Cosa ne pensate, cosa sono effettivamente questi "registri"? Secondo la maggior parte, i registri di qualsiasi applicazione dovrebbero avere il ruolo di un'entità onnipotente che per la maggior parte del tempo si trova in un angolo, ma quando serve appare dal nulla in armature scintillanti e salva tutti. Dovrebbero contenere tutto, dagli errori minimi in ogni componente a singole transazioni del database. E dopo un errore dovrebbe subito indicare come correggere il problema. E tutto questo dovrebbe stare in un paio di megabyte, al massimo. È solo testo! Non possono i file di testo occupare decine di gigabyte, l'ho sentito da qualche parte!
Quindi, i registri
Nel mondo reale, i registri sono semplicemente archivi di informazioni diagnostiche. E cosa conservare, da dove prendere le informazioni da archiviare e quanto dettagliate devono essere, spetta agli stessi sviluppatori. Alcuni seguono la strada del minimalismo, conservando registrazioni di accensione/spegnimento, mentre altri si affannano a raccogliere tutto ciò che possono. Anche se c'è un'opzione intermedia che consente di scegliere il cosiddetto Livello di Logging, dove tu stesso indichi quanto dettagliate vuoi che siano le informazioni che conservi e quanto spazio extra hai sui dischi =) A proposito, VBR ha sei di questi livelli. E, credetemi, non volete vedere cosa succede con la registrazione più dettagliata quando avete spazio libero sul vostro disco.
Va bene. Abbiamo più o meno capito cosa vogliamo mantenere, ma si pone una legittima domanda: da dove prendere queste informazioni? Parte degli eventi da registrare, ovviamente, sono generati da noi attraverso i nostri processi interni. Ma cosa fare quando si verifica un'interazione con l'ambiente esterno? Per non scivolare in un'inesauribile serie di soluzioni improvvisate, Veeam tende a non reinventare l'acqua calda. Ogni volta che esiste già un'API, una funzione integrata nel sistema, una libreria, ecc., daremo priorità alle soluzioni esistenti prima di iniziare a creare le nostre soluzioni ingegnose. Anche se ce ne sono già molte. Pertanto, durante l'analisi dei log è importante capire che la maggior parte degli errori proviene dai messaggi delle API esterne, dalle chiamate di sistema e da altre librerie. In questo caso, il ruolo di VBR è quello di inoltrare questi errori nei file di log così come sono. E il compito principale dell'utente è imparare a comprendere quale riga proviene da chi e per cosa risponde quel “chi”. Pertanto, se il codice di errore dai log VBR ti porta a una pagina MSDN, è normale 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 per il corretto funzionamento è conservato nel suo database. Da qui la semplice verità: ciò che non è presente nei log, probabilmente è presente nel database. Ma questo non è neanche una panacea: ci sono alcune informazioni che non si trovano né nei log locali dei componenti di Veeam né nel suo database. È quindi necessario imparare a studiare i log dell'host, i log della macchina locale e i log di tutto ciò che partecipa al processo di backup e ristorazione. A volte accade che le informazioni necessarie non siano disponibili da nessuna parte. Questa è la realtà.
Alcuni esempi di tali API
Questa lista non ha l'obiettivo di essere di completezza esclusiva, quindi non cercate la verità in essa come se fosse l'ultima istanza. Il suo compito è solo quello di mostrare le API e le tecnologie esterne più comuni utilizzate nei nostri prodotti.
Iniziamo con VMware.
Il primo della lista sarà vSphere API. Utilizzato per l'autenticazione, la lettura della gerarchia, la creazione e l'eliminazione di snapshot, la richiesta di informazioni sulle macchine e molto (molto) altro. La funzionalità della soluzione è molto ampia, quindi per tutti coloro che sono interessati consiglio la VMware vSphere API Reference per la versione e . Per le versioni più aggiornate si trova facilmente su Google.
VIX API. Magia nera del hypervisor, per la quale esiste un elenco separato . VMware API per lavorare con i file sull'host senza collegamento di rete. Una soluzione di ultima istanza, quando è necessario caricare un file su una macchina per la quale non c'è un canale di comunicazione migliore. Si tratta di dolore e sofferenza, se il file è grande e l'host è sovraccarico. Ma qui vale la regola che anche 56,6 Kb/s è meglio di 0 Kb/s. In Hyper-V, una cosa simile si chiama PowerShell Direct. Ma questo è stato solo fino all'arrivo
vSphere Web Services API A partire da vSphere 6.0 (circa, poiché questo API è stato presentato per la prima volta nella versione 5.5) è utilizzato per lavorare con le macchine virtuali ed ha praticamente sostituito VIX ovunque. In effetti, è un altro API per gestire vSphere. Consiglio a chi è interessato di studiare manuale.
VDDK (Virtual Disk Development Kit). Una libreria di cui si è parlato parzialmente in questo . È utilizzata per leggere dischi virtuali. Un tempo era parte di VIX, ma nel tempo è stata separata in un prodotto autonomo. Tuttavia, in quanto erede, usa gli stessi codici di errore di VIX. Ma per qualche motivo, nel SDK stesso non c'è alcuna descrizione di questi errori. Pertanto, è stato scoperto empiricamente che gli errori di VDDK con codici diversi sono semplicemente una traduzione dal codice binario al codice decimale. È composto da due parti: la prima metà è un'informazione non documentata sul contesto, e la seconda parte sono gli errori VIX/VDDK tradizionali. Ad esempio, se vediamo:
Errore VDDK: 21036749815809.Errore sconosciuto
Allora possiamo convertirlo senza paura in esadecimale e ottenere 132200000001. L'inizio non informativo 132200 viene semplicemente scartato, e il resto sarà il nostro codice di errore (VDDK 1: Errore sconosciuto). Recentemente è stato pubblicato un articolo sui più comuni errori di VDDK. .
Ora diamo un'occhiata a Windows.
Qui possiamo trovare tutto ciò di cui abbiamo bisogno e che è importante per noi nel standard Event Viewer. Ma c'è un problema: secondo una vecchia tradizione, Windows non registra il messaggio di errore completo, ma solo il suo numero. Ad esempio, l'errore 5 è "Accesso negato", l'errore 1722 è "Il server RPC non è disponibile", e l'errore 10060 è "Timeout della connessione". Certo, è fantastico se ricordi i più noti, ma come ci si comporta con quelli mai visti prima?
E per rendere la vita non troppo dolce, gli errori sono memorizzati anche in forma esadecimale, con il prefisso 0x8007. Ad esempio, 0x8007000e significa in realtà 14, Out of Memory. Perché e per chi sia stato fatto in questo modo rimane un mistero. Tuttavia, l'elenco completo degli errori può essere scaricato gratuitamente e senza SMS da .
A proposito, a volte si incontrano anche altri prefissi, non solo 0x8007. In una situazione così triste, per comprendere l'HRESULT (“handle del risultato”) è necessario approfondire ulteriormente per gli sviluppatori. Nella vita di tutti i giorni non vi consiglierei di fare una cosa del genere, ma se dovesse realmente servirvi o semplicemente vi interessa, ora sapete cosa fare.
Ma i compagni di Microsoft si sono un po' impietositi e ci hanno presentato l'utility . È un piccolo pezzo di felicità da console, in grado di tradurre i codici di errore in un linguaggio comprensibile senza utilizzare Google. Funziona più o meno così.
C:UsersrootDesktop>err.exe 0x54f
# per esadecimale 0x54f / decimale 1359
ERROR_INTERNAL_ERROR winerror.h
# Si è verificato un errore interno.
# come un HRESULT: Severità: SUCCESS (0), FACILITY_NULL (0x0), Codice 0x54f
# per esadecimale 0x54f / decimale 1359
ERROR_INTERNAL_ERROR winerror.h
# Si è verificato un errore interno.
# 2 corrispondenze trovate per "0x54f"Sorge una legittima domanda: perché non scriviamo subito la decodifica nei log, lasciando questi codici misteriosi? La risposta è nelle applicazioni di terze parti. Quando chiami un certo invocazione WinAPI, decifrare la sua risposta non è difficile, perché esiste persino una chiamata WinAPI speciale per questo. Ma come già detto, nei nostri log arriva tutto ciò che ci arriva nelle risposte. E qui per la decodifica sarebbe necessario monitorare continuamente questo flusso di coscienza, estrarne i pezzi con gli errori di Windows, decifrarli e reinserirli. Diciamo pure, non è l'attività più affascinante.
Windows File Management API viene utilizzato in vari modi quando si lavora con file. Creazione di file, eliminazione, apertura in scrittura, gestione degli attributi e altro ancora.
Il suddetto PowerShell Direct è l'equivalente di VIX API nel mondo Hyper-V. Sfortunatamente, non è così flessibile: molte limitazioni nella funzionalità, non funziona con ogni versione dell'host e nemmeno con tutti gli ospiti.
RPC (Remote Procedure Call) Penso che non ci sia nessuno che abbia lavorato con Windows e non abbia mai visto errori legati a RPC. Contrariamente a quanto si crede comunemente, non è un protocollo unico, ma qualsiasi protocollo client-server che soddisfi una serie di parametri. Tuttavia, se nei nostri log appare un errore RPC, nel 90% dei casi sarà un errore di Microsoft RPC, che fa parte di DCOM (Distributed Component Object Model). In rete si può trovare una grande quantità di documentazione su questo argomento, ma gran parte di essa è piuttosto obsoleta. Se c'è una forte voglia di approfondire l'argomento, posso consigliare articoli , e un lungo elenco .
Le principali cause degli errori RPC nei nostri log sono i tentativi di interazione falliti tra i componenti VBR (server > proxy, per esempio) e più spesso a causa di problemi di comunicazione.
Il top tra tutti i top è l'errore The RPC server is unavailable (1722). In parole povere, il client non è riuscito a stabilire una connessione con il server. Come e perché — non c'è una risposta unica, ma di solito è un problema di autenticazione o di accesso alla rete fino alla porta 135. Quest'ultimo è caratteristico per le infrastrutture con assegnazione dinamica delle porte. A questo proposito, c'è anche . E per Microsoft — per la ricerca delle cause dei malfunzionamenti.
Il secondo errore più comune è: There are no more endpoints available from the endpoint mapper (1753). Il client o il server RPC non sono riusciti ad assegnare una porta. Questo di solito accade quando il server (nel nostro caso macchina guest) è stato configurato per l'assegnazione dinamica delle porte da un intervallo ristretto, che è esaurito. E se si guarda dal lato del client (nel nostro caso il server VBR), significa che il nostro VeeamVssAgent non si è avviato o non è stato registrato come interfaccia RPC. Anche su questo tema c'è .
E per concludere il Top-3 degli errori RPC, ricordiamo RPC function call failed (1726). Questo errore si verifica se la connessione è stata stabilita, ma le richieste RPC non vengono elaborate. Ad esempio, richiediamo informazioni sullo stato del VSS (nel caso in cui stia eseguendo una copia shadow in questo momento, e noi tentiamo di accedere), e in risposta riceviamo silenzio e ignoranza.
Windows Tape Backup API è necessario per lavorare con librerie a nastro o dispositivi di archiviazione. Come ho già accennato all'inizio: scrivere i propri driver e poi affrontare la questione del supporto per ogni dispositivo non ci dà alcun piacere. Pertanto, Veeam non ha driver propri. Tutto passa attraverso l'API standard, il cui supporto è fornito dai produttori hardware stessi. È molto più logico, vero?
SMB/CIFS Tutti li scrivono di solito affiancati, anche se non tutti ricordano che CIFS (Common Internet File System) è semplicemente una versione privata di SMB (Server Message Block). Quindi non c'è nulla di sbagliato nell'unificare questi concetti. Samba, invece, è l'implementazione per Linux/Unix, e ha le sue peculiarità, ma mi sono un po' distratto. Ciò che è importante qui: quando Veeam richiede di scrivere qualcosa tramite un percorso UNC (serverdirectory), il server utilizza la gerarchia dei driver del file system, includendo mup e mrxsmb, per scrivere sulla condivisione. Di conseguenza, anche questi driver genereranno errori.
Non si può fare a meno di Winsock API. Se c'è qualcosa da fare in rete, VBR funziona tramite Windows Socket API, comunemente conosciuto come Winsock. Quindi, se vediamo nel log una coppia IP:Port, è questo. Nella documentazione ufficiale c'è un buon elenco di .
Il suddetto WMI (Windows Management Instrumentation) è un'API onnipotente per la gestione di tutto ciò che riguarda il mondo Windows. Ad esempio, quando si lavora con Hyper-V, quasi tutte le richieste al host avvengono tramite di esso. Insomma, è uno strumento indispensabile e molto potente nelle sue funzionalità. Nella ricerca di aiuto per capire dove e cosa sia andato storto, è molto utile lo strumento integrato WBEMtest.exe.
E l'ultimo della lista, ma di importanza non trascurabile, è VSS (Volume Shadow Storage). L'argomento è così ricco e misterioso, quanto è ampia la documentazione esistente su di esso. La Shadow Copy può essere compresa più facilmente come un tipo speciale di snapshot, che in sostanza è. Grazie a questo, in VMware è possibile effettuare backup coerenti con l'applicazione, e in Hyper-V praticamente tutto. Ho in programma di scrivere un articolo separato con un riassunto su VSS, ma nel frattempo puoi provare a leggere . Solo attenzione, perché cercare di comprendere VSS di fretta può portare a fastidi cerebrali.
Su questo, direi che possiamo fermarci. Considero completata l'attività di spiegare le cose più basilari, quindi nel prossimo capitolo esamineremo i log. Ma se hai domande, non esitare a farle nei commenti.
Fonte: habr.com
