Continuiamo la nostra immersione nel mondo affascinante della diagnostics… troubleshooting dei log. In abbiamo concordato il significato dei termini di base e abbiamo dato un'occhiata alla struttura generale di Veeam come applicazione unica. L'obiettivo di questo è capire come si formano i file di log, quali informazioni sono rappresentate in essi e perché appaiono come appaiono.
Cosa ne pensate, cosa sono esattamente questi «log»? Secondo molti, ai log di qualsiasi applicazione dovrebbe essere riservato il ruolo di una sorta di entità onnipotente, che per la maggior parte del tempo giace in qualche angolo remoto, ma che al momento giusto emerge dal nulla con un'armatura splendente e salva tutti. Cioè, dovrebbero contenere tutto, dagli errori minori di ogni componente alle singole transazioni del database. E dopo un errore dovrebbe essere scritto subito come correggerlo. E tutto questo dovrebbe stare in un paio di megabyte, non di più. Ma è solo testo! I file di testo non possono occupare decine di gigabyte, l'ho sentito da qualche parte!
Quindi, i log
Nel mondo reale, i log sono semplicemente archivi di informazioni diagnostiche. Spetta agli sviluppatori decidere cosa conservare, da dove ottenere le informazioni da memorizzare e quanto dettagliate devono essere. Alcuni scelgono un approccio minimalista, registrando solo gli eventi di accensione/spegnimento, mentre altri si dedicano a raccogliere tutto ciò che riescono a raggiungere. Esiste anche una soluzione intermedia che consente di scegliere il cosiddetto Logging Level, dove puoi specificare quanto dettagliate desideri che siano le informazioni da conservare e quanto spazio libero hai sui dischi =) VBR offre ben sei livelli in questo senso. E, credetemi, non volete vedere cosa succede con il logging più dettagliato quando lo spazio sul disco è disponibile.
Va bene. Abbiamo capito in linea di massima cosa vogliamo conservare, ma sorge una domanda legittima: da dove prendere queste informazioni? Parte degli eventi da registrare, ovviamente, proviene dai nostri processi interni. Ma cosa fare quando ci sono interazioni con ambienti esterni? Per non scivolare in una miseria di soluzioni improvvisate, Veeam tende a non reinventare l'acqua calda. Ogni volta che esiste già un'API pronta, una funzione integrata nel sistema, una libreria, ecc., preferiremo optare per le soluzioni già pronte prima di iniziare a costruire le nostre. Anche se ce ne sono molte altre. Pertanto, quando si analizzano i log, è importante comprendere che la maggior parte degli errori proviene da messaggi di API di terze parti, chiamate di sistema e altre librerie. In questo caso, il ruolo di VBR si limita a inoltrare questi errori nei file di log così come sono. E il compito principale dell'utente è imparare a capire quale riga proviene da chi e cosa responsabile. Pertanto, se il codice di errore nei log di VBR vi porta a una pagina MSDN, è normale e corretto.
Come concordato in precedenza: Veeam è un'applicazione basata su SQL. Questo significa che tutte le impostazioni, tutte le informazioni e in generale tutto ciò che è necessario per il normale funzionamento è conservato nel suo database. Da qui deriva una semplice verità: ciò che non è nei log, è probabilmente presente nel database. Ma non è una soluzione infallibile: alcune informazioni non si trovano né nei log locali dei componenti di Veeam né nel suo database. Pertanto, è necessario imparare a esaminare i log dell'host, i log della macchina locale e i log di tutto ciò che partecipa al processo di backup e ripristino. Ci sono anche casi in cui l'informazione necessaria non si trova da nessuna parte. Questo è il percorso.
Alcuni esempi di tali API
Questo elenco non ha l'obiettivo di essere esaustivo, quindi non cercate in esso la verità assoluta. Il suo scopo è semplicemente quello di mostrare le API esterne e le tecnologie più comuni utilizzate nei nostri prodotti.
Iniziamo con VMware.
Il primo nell'elenco sarà vSphere API. Utilizzato per l'autenticazione, la lettura della gerarchia, la creazione e la cancellazione di snapshot, la richiesta di informazioni sulle macchine e molto (molto) altro. Le funzionalità della soluzione sono molto ampie, quindi consiglio a chiunque di consultare la VMware vSphere API Reference per la versione e . Per le versioni più recenti, è tutto facilmente reperibile su Google.
VIX API. Magia nera dell'ipervisor, per la quale esiste un elenco separato di . API VMware per lavorare con file sull'host senza doverli connettere in rete. Una soluzione di ultima istanza, quando è necessario caricare un file su una macchina per cui non c'è un canale di comunicazione migliore. È fonte di dolore e sofferenza se il file è grande e l'host è carico. 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 così è stato solo fino all'arrivo di
vSphere Web Services API . A partire da vSphere 6.0 (circa, poiché questo API è stato introdotto per la prima volta nella versione 5.5) viene utilizzato per lavorare con le macchine virtuali ed ha ormai praticamente sostituito VIX. In sostanza, è un altro API per la gestione di vSphere. Per chi è interessato, consiglio di studiare manuale.
VDDK (Virtual Disk Development Kit). La libreria di cui si è parlato parzialmente in questo . Utilizzato per leggere dischi virtuali. Un tempo era parte di VIX, ma nel tempo è stato separato in un prodotto autonomo. Tuttavia, in quanto erede, utilizza gli stessi codici di errore di VIX. Ma per qualche motivo, nel SDK non c'è alcuna descrizione di questi errori. Pertanto, è stato scoperto per esperienza che gli errori VDDK con altri codici sono semplicemente una traduzione da binario a decimale. Si compone di due parti: la prima metà fornisce informazioni non documentate sul contesto, mentre la seconda parte contiene gli errori tradizionali di VIX/VDDK. Ad esempio, se vediamo:
VDDK error: 21036749815809.Unknown error
Allora possiamo tranquillamente convertirlo in hex e ottenere 132200000001. L'informazione non informativa iniziale 132200 viene semplicemente scartata, e il resto sarà il nostro codice di errore (VDDK 1: Unknown error). Riguardo agli errori VDDK più comuni, recentemente è stata dedicata una .
Ora diamo un'occhiata a WIndows.
Qui possiamo trovare tutto ciò di cui abbiamo bisogno e che è importante per noi nel Event Viewer. Ma c'è un problema: per antica tradizione, Windows non registra il testo completo dell'errore, ma solo il suo codice. Ad esempio, l'errore 5 significa "Accesso negato", mentre 1722 è "Il server RPC non è disponibile" e 10060 indica "Timeout della connessione". Certamente, è utile ricordare i più noti, ma cosa fare con quelli mai visti prima?
E per rendere le cose ancora più complicate, gli errori vengono memorizzati anche in formato esadecimale, con il prefisso 0x8007. Ad esempio, 0x8007000e corrisponde a 14, Out of Memory. Perché e per chi sia stato fatto così — è un mistero. Tuttavia, puoi scaricare gratuitamente e senza SMS l'elenco completo degli errori da .
Per inciso, a volte ci sono altri prefissi, non solo 0x8007. In una situazione così triste, per comprendere HRESULT ("handle di risultato") è necessario approfondire ulteriormente per sviluppatori. Nella vita di tutti i giorni, non te lo consiglio, ma se ti trovi in difficoltà o semplicemente sei curioso, ora sai cosa fare.
Ma i ragazzi della Microsoft si sono un po' impietositi nei nostri confronti e hanno rilasciato l'utility . Si tratta di un piccolo pezzo di felicità da console, che sa tradurre i codici di errore in un linguaggio comprensibile senza utilizzare Google. Funziona più o meno in questo modo.
C:UsersrootDesktop>err.exe 0x54f
# per hex 0x54f / decimale 1359
ERROR_INTERNAL_ERROR winerror.h
# Si è verificato un errore interno.
# come HRESULT: Severità: SUCCESS (0), FACILITY_NULL (0x0), Codice 0x54f
# per hex 0x54f / decimale 1359
ERROR_INTERNAL_ERROR winerror.h
# Si è verificato un errore interno.
# 2 corrispondenze trovate per "0x54f"Sorge una domanda legittima: perché non scriviamo subito una spiegazione nei log e lasciamo questi codici misteriosi? La risposta sta nelle applicazioni di terze parti. Quando chiami tu stesso una qualche chiamata WinAPI, decifrare la risposta non è difficile, poiché esiste una chiamata WinAPI speciale per questo. Ma come già detto, nei nostri log entra tutto ciò che viene in risposta. E qui bisognerebbe monitorare costantemente questo flusso di coscienza, estrarre pezzi con gli errori di Windows, decifrarli e reinserirli. Diciamo la verità, non è l'attività più entusiasmante.
API di Gestione File di Windows è utilizzata in vari modi per lavorare con i file. Creazione di file, eliminazione, apertura in scrittura, gestione degli attributi e molto altro.
Il suddetto PowerShell Direct come analogo all'API VIX nel mondo di Hyper-V. Purtroppo, non è così flessibile: ci sono molte limitazioni funzionali, non è compatibile con ogni versione dell'host e non con tutti i guest.
richiesta RPC (Remote Procedure Call) Credo che non ci sia nessuna persona che abbia lavorato con Windows che non abbia mai visto errori legati a RPC. Nonostante la comune credenza, non si tratta di un protocollo unico, ma di qualunque protocollo client-server che soddisfi una serie di parametri. Tuttavia, se nei nostri log troviamo un errore RPC, nel 90% dei casi sarà un errore di Microsoft RPC, che è parte di DCOM (Distributed Component Object Model). Si può trovare un'enorme quantità di documentazione sul tema in rete, ma gran parte di essa è piuttosto datata. Se c'è un forte desiderio di approfondire l'argomento, posso consigliare degli articoli. , e un elenco lungo .
Le principali cause delle errori RPC presenti nei nostri log sono tentativi falliti di interazione tra i componenti VBR (server > proxy, ad esempio) e più spesso a causa di problemi di comunicazione.
L'errore principale tra tutti gli errori è The RPC server is unavailable (1722). In parole semplici, il client non è riuscito a stabilire una connessione con il server. Non c'è una risposta unica su come e perché, ma di solito si tratta di un problema di autenticazione o di accesso alla rete sulla porta 135. Quest'ultimo è caratteristico delle infrastrutture con assegnazione dinamica delle porte. A tal proposito esiste anche . E Microsoft ha per la ricerca delle cause del malfunzionamento.
Il secondo errore più comune è: There are no more endpoints available from the endpoint mapper (1753). Il client RPC o il server non sono riusciti ad assegnare una porta. Di solito si verifica quando il server (nel nostro caso la macchina ospite) è stato configurato per l'assegnazione dinamica delle porte da un intervallo ristretto, che si è esaurito. Se si osserva dalla parte del client (nel nostro caso il server VBR), significa che il nostro VeeamVssAgent non è stato avviato o non è stato registrato come interfaccia RPC. Anche su questo tema esiste .
E per completare il Top 3 degli errori RPC, ricordiamo che la chiamata di funzione RPC è fallita (1726). Questo errore si presenta quando la connessione è stata stabilita, ma le richieste RPC non vengono elaborate. Ad esempio, stiamo richiedendo informazioni sullo stato di VSS (magari in quel momento si sta eseguendo una copia shadow e noi stiamo tentando di accedervi), e invece non riceviamo risposta ma solo silenzio e ignoranza.
API di backup su nastro di Windows è necessaria per lavorare con librerie o unità a nastro. Come ho menzionato all'inizio: non ci fa piacere scrivere i nostri driver e poi faticare nel supporto di ciascun dispositivo. Pertanto, non abbiamo driver proprietari. Tutto avviene tramite l'API standard, il cui supporto è fornito dai produttori di hardware stessi. È molto più logico, vero?
SMB/CIFS Tutti tendono a scriverli vicini, anche se non tutti ricordano che il CIFS (Common Internet File System) è semplicemente una versione privata del SMB (Server Message Block). Quindi non c'è nulla di sbagliato nel generalizzare questi concetti. Samba è una realizzazione per LinuxUnix e ha le sue peculiarità, ma mi sto distraendo. Ciò che è importante qui è che quando Veeam chiede di scrivere qualcosa tramite il percorso UNC (serverdirectory), il server utilizza una gerarchia dei driver di file system, compresi 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 attraverso il Windows Socket API, comunemente noto come Winsock. Quindi se vediamo nel registro una combinazione IP:Port, è lui. Nella documentazione ufficiale c'è un buon elenco di possibili .
Il suddetto WMI (Windows Management Instrumentation) è un'API onnipotente per gestire tutto e tutti nel mondo Windows. Ad esempio, quando si lavora con Hyper-V, quasi tutte le richieste al host avvengono proprio tramite questa API. In altre parole, è un elemento assolutamente indispensabile e molto potente nelle sue possibilità. Nelle difficoltà di capire dove e cosa sia rotto, è di grande aiuto lo strumento integrato WBEMtest.exe.
E l'ultimo della lista, ma non certo il meno significativo - VSS (Volume Shadow Storage). Un argomento così ricco e misterioso quanto la documentazione scritta a riguardo. La Shadow Copy è più facile da comprendere come un tipo speciale di snapshot, che in realtà è ciò che rappresenta. Grazie a questo, in VMware è possibile eseguire backup coerenti con l'applicazione, e in Hyper-V si può praticamente fare tutto. Ho in programma di scrivere un articolo separato con un riassunto su VSS, ma nel frattempo potete provare a leggere . Solo con cautela, poiché cercare di comprendere VSS di fretta può portare a danni cerebrali.
A questo punto, credo di poter fermarmi. Ritengo che la mia missione di spiegare le nozioni di base sia compiuta, quindi nel prossimo capitolo ci concentreremo sui log. Ma se avete domande, non esitate a condividerle nei commenti.
Fonte: habr.com
