Noi di Veeam amiamo i log. E poiché la maggior parte delle nostre soluzioni è modulare, scrivono una quantità considerevole di log. Dato che il nostro campo di attività è la protezione dei vostri dati (cioè il sonno tranquillo), i log non devono solo registrare ogni singolo dettaglio, ma farlo anche in modo piuttosto dettagliato. È necessario affinché, in caso di problemi, sia chiaro come è avvenuto il “problema”, chi è responsabile e cosa occorre fare in seguito. Qui è come nella criminologia: non si sa mai quale piccolo dettaglio possa aiutarti a trovare l’assassino di Laura Palmer.
Per questo ho deciso di intraprendere una serie di articoli, in cui racconterò in modo sequenziale cosa scriviamo nei log, dove li archiviamo, come non impazzire per la loro struttura e cosa cercare al loro interno.
Perché una serie di articoli e perché non descrivere tutto in una volta?
Elencare semplicemente dove si trova ogni log e cosa contiene è un'impresa piuttosto infelice. E pensare a come mantenere queste informazioni aggiornate è spaventoso. Un semplice elenco di tutti i possibili tipi di log in Veeam Backup & Replication sarebbe una tabella su più fogli in carattere ridotto. Inoltre, sarebbe valida solo al momento della pubblicazione, poiché con l'uscita del prossimo aggiornamento potrebbero apparire nuovi log, cambiare la logica delle informazioni archiviate nei vecchi, e così via. Pertanto, è molto più utile spiegare la loro struttura e il significato delle informazioni in esse contenute. Questo permetterà di orientarsi meglio, piuttosto che limitarsi a memorizzare nomi.
Quindi, per non tuffarci a capofitto in fogli di testo, vediamo di fare un po' di lavoro preparatorio in questo articolo. Pertanto, oggi non ci addentreremo nei log stessi, ma ci avvicineremo da lontano: comporremo un glossario e discuteremo un po' della struttura di Veeam dal punto di vista della generazione di log.
Glossario e gerghi
Qui è opportuno scusarsi con i sostenitori della purezza della lingua russa e con i testimoni del vocabolario di Ožegov. Amiamo tutti molto la nostra lingua madre, ma la dannata industria IT lavora in inglese. Non siamo stati noi a deciderlo, ma così è stato storicamente. Non è colpa mia, è venuto da sé (s)
Nel nostro campo, il problema degli anglicismi (e del gergo) ha le sue specificità. Quando con parole innocue come "host" o "guest" il mondo intero intende già da tempo cose altamente specifiche, su ⅙ della terra continua un'eroica confusione e incertezza con tentativi di consultare dizionari. E c'è sempre l'argomento da non perdere: "Ma da noi al lavoro…".
In aggiunta, abbiamo una terminologia che è specifica per i prodotti Veeam, anche se alcune parole e frasi sono diventate d’uso comune. Quindi ora ci accordiamo sul significato di ogni termine e in seguito, per me, la parola "guest" si riferirà precisamente a quanto scritto in questo capitolo, e non a come siete abituati a usarla nella vostra azienda. E sì, non è un capriccio personale, ma termini consolidati nel settore. Combattere contro di essi è piuttosto senza senso. Anche se sono sempre favorevole a qualche discussione nei commenti.
Purtroppo, ci sono un numero estremamente elevato di termini nel nostro lavoro e nei prodotti, quindi non tenterò di elencarli tutti. Solo i più basilari e necessari per sopravvivere nel mare di informazioni su backup e log. Per chi fosse interessato, posso anche di un collega sui nastri, dove ha anche fornito un elenco di termini riguardanti quella parte della funzionalità.
Host (Host): Nel mondo della virtualizzazione, è la macchina con hypervisor. Fisica, virtuale, cloud — non importa. Se qualcosa sta eseguendo un hypervisor (ESXi, Hyper-V, KVM ecc.), allora quel "qualcosa" è chiamato host. Che si tratti di un cluster di dieci rack o del vostro laptop con un paio di macchine virtuali — se avete avviato un hypervisor, siete diventati un host. Perché l'hypervisor ospita macchine virtuali. C'è anche una leggenda che dice che VMware, un tempo, voleva ottenere un'associazione precisa tra la parola host e ESXi. Ma non ci è riuscita.
Nel mondo moderno, il concetto di "host" si è praticamente fuso con quello di "server", il che crea una certa confusione nella comunicazione, specialmente quando si parla di infrastruttura Windows. Quindi qualsiasi macchina che ospiti un servizio di nostro interesse può essere tranquillamente chiamata host. Ad esempio, nei log di WinSock, il termine host viene utilizzato per etichettare tutto quello che passa. Il classico esempio è "Host non trovato". Quindi partiamo dal contesto, ma ricordiamo — nel mondo della virtualizzazione, un host è quello che ospita i guest (di questo ne parleremo tra un paio di righe).
Tra i gerghi locali (più precisamente acronimi, in questo caso) si ricorda che VMware è VI, vSphere è VC e Hyper-V è HV.
Guest (Ospite): Una macchina virtuale che gira su un host. Qui non c'è nemmeno bisogno di spiegare, tutto è così logico e semplice. Tuttavia, molti si sforzano di portare qui altri significati.
Perché? Non lo so.
Guest OS, di conseguenza, il sistema operativo della macchina ospite. E così via.
Backup/Replication Job (jobA): Un gergo puramente VMware, che indica uno dei compiti. Backup job == Lavoro di Backup. Come tradurre bene in russo — nessuno lo ha inventato, quindi tutti dicono "jobA". Con l'accento sull'ultima sillaba.
Sì, semplicemente si prendono e si dice "jobA". E anche nelle lettere si scrivono così, e va tutto bene.
Tutti i lavori di Backup, Compiti di Backup, ecc., grazie, ma no. Solo jobA, e verranno capiti. L'importante è mettere l'accento sull'ultima sillaba.
Backup (Backup, bacheca. Per i veri oldfag è consentito backup): Oltre al significato ovvio (un backup di dati da qualche parte), significa anche il lavoro stesso (tre righe sopra, se già l’avete dimenticato), da cui viene creato il famigerato file di backup. Probabilmente, i signori madrelingua inglesi sono troppo pigri per dire ogni volta I ran my backup job, quindi dicono semplicemente I ran my backup, e tutti si comprendono perfettamente. Propongo di sostenere questa meravigliosa iniziativa.
Consolidate (Consolidamento): Un termine emerso in ESXi 5.0 Opzione nel menu per lavorare con gli snapshot, che avvia il processo di eliminazione dei cosiddetti snapshot orfani. Cioè, snapshot che esistono fisicamente, ma che sono caduti dalla struttura logica visualizzata. Teoricamente, questo processo non dovrebbe coinvolgere i file mostrati nel gestore degli snapshot, tuttavia può succedere. L'essenza del processo di consolidamento è che i dati dello snapshot (child disk) vengono scritti nel disco principale (parent). Il processo di unione dei dischi è chiamato merge. Se è stato dato un comando di consolidamento, allora la registrazione dello snapshot può essere rimossa dal database prima che lo snapshot venga unito ed eliminato. E se lo snapshot non è stato possibile eliminare per qualsiasi motivo, allora compaiono questi snapshot orfani. Per quanto riguarda il lavoro con gli snapshot, VMware ha . E noi abbiamo anche scritto qualcosa su di loro .
Datastore (Store o Storage): Un concetto molto ampio, ma nel mondo della virtualizzazione si intende il luogo dove sono memorizzati i file delle macchine virtuali. Tuttavia, in ogni caso è necessario comprendere chiaramente il contesto e, in caso di minimi dubbi, chiarire cosa intendesse esattamente il vostro interlocutore.
Proxy (Proxy): È importante capire subito che Veeam Proxy non è esattamente la stessa cosa a cui siamo abituati nei vari angoli di Internet. Nell'ambito dei prodotti Veeam, è una sorta di entità che si occupa di trasferire dati da un luogo all'altro. Senza entrare nei dettagli, VBR è il server centrale, mentre il proxy è il suo operatore. Quindi, il proxy è la macchina attraverso cui passa il traffico e sulla quale sono installati i componenti VBR che aiutano a gestire questo traffico. Ad esempio, trasferire dati da un canale all'altro o semplicemente collegare dischi (modalità HotAdd).
Repository (Repository): Tecnica mente, è semplicemente una registrazione nel database VBR che indica il luogo dove sono memorizzati i backup e come connettersi a quel luogo. Può essere una semplice condivisione CIFS, un disco separato, un server o un bucket nel cloud. Di nuovo, siamo nel contesto, ma comprendiamo che il repository è semplicemente un luogo dove si trovano i vostri backup.
Snapshot (Snapshot): Gli amanti della grammatica di Oxford preferiscono dire "chi snapshòt", chi "snapshòt", tuttavia la maggioranza ignorante vince grazie all'impetuosità. Se qualcuno non lo sa, questa è una tecnologia che permette di ripristinare lo stato di un disco in un determinato momento. Questo avviene o mediante un temporaneo reindirizzamento delle operazioni I/O lontano dal disco principale — allora sarà chiamato snapshot RoW (Redirect on Write) — oppure mediante il trasferimento dei blocchi riscrivibili dal vostro disco a un altro — questo sarà chiamato snapshot CoW (Copy on Write). Grazie alle ampie possibilità di utilizzo di queste funzioni, Veeam può operare la sua magia di backup. A dire il vero, non solo per loro, ma questo è un argomento per i prossimi rilasci.
Nella documentazione e nei log di ESXi regna il caos attorno a questo termine, e nel contesto dei snapshot si possono trovare sia i snapshot stessi, sia il redo log e anche il delta disk. Nella documentazione di Veeam non c'è tale confusione; uno snapshot è uno snapshot e il redo log è esattamente il file REDO creato da un disco non persistente. I file REDO vengono eliminati al momento dello spegnimento della macchina virtuale, quindi confonderli con gli snapshot è un errore che può portare al fallimento.
Sintetico: I backup sintetici si riferiscono ai backup reverse incremental e forever forward. Se non avete mai incontrato questo termine, è semplicemente uno dei meccanismi utilizzati per costruire una catena di backup. Tuttavia, nei log si può anche incontrare il termine Transform, che viene utilizzato nell'ambito della creazione di copie complete a partire dagli incrementi (synthetic full).
Task (Compito): Questo è il processo di elaborazione di ciascuna singola macchina nell'ambito di un job. Quindi: se avete un job di backup che include tre macchine, ogni macchina verrà elaborata all'interno di un compito separato. In totale, ci saranno quattro log: uno principale per il job e tre per i compiti. Tuttavia, c'è un'importante sfumatura: nel tempo la parola "compito" è diventata eccessivamente ambigua. Quando parliamo di log generali, intendiamo che un compito è precisamente una VM. Ma ci sono "compiti" anche sul proxy e sul repository. Qui può significare sia un disco virtuale, sia una macchina virtuale, sia l'intero job. È quindi importante non perdere il contesto.
Veeam %name% Service (Servizio): A beneficio dei backup di successo, operano diversi servizi, il cui elenco può essere trovato nell'apposito strumento standard. I loro nomi riflettono abbastanza chiaramente la loro essenza, ma tra gli altri c'è uno molto importante — il Veeam Backup Service, senza il quale gli altri non funzionano.
VSS: Tecnicamente, VSS dovrebbe sempre riferirsi al Microsoft Volume Shadow Copy Service. In realtà, molti lo usano come sinonimo di Application-Aware Image Processing. Cosa che, ovviamente, è categoricamente errata, ma è una storia del tipo "Qualsiasi fuoristrada può essere chiamato jeep, e ti comprenderanno".
Log fantastici e i luoghi in cui abitano
Voglio iniziare questo capitolo svelando un grande segreto: quale ora è visualizzata nei log?
Ricordatevi:
- ESXi scrive sempre i log in UTC+0.
- vCenter tiene i log in base al suo fuso orario.
- Veeam tiene i log in base al tempo e al fuso orario del server su cui è installato.
- E solo gli eventi Windows in formato EVTX non sono legati a nulla. Quando li apri, il tempo viene ricalcolato in base alla macchina su cui sono stati aperti. È l'opzione più comoda, anche se ci sono delle difficoltà. L'unica vera difficoltà è la differenza delle localizzazioni. Questo è praticamente un modo garantito per avere log illeggibili. Sì, ci sono modi per risolvere, ma non discutiamo sul fatto che tutto in IT funziona in inglese e concordiamo sempre di impostare la localizzazione inglese sui server. Per favore.
Ora parliamo dei luoghi in cui vivono i log e come recuperarli. Nel caso di VBR ci sono due approcci.
La prima opzione è adatta se non sei ansioso di cercare nella massa dei file che riguardano il tuo problema specifico. A tale scopo, abbiamo un wizard separato, al quale puoi indicare un lavoro specifico e un periodo specifico per il quale hai bisogno dei log. Poi lui stesso scorrerà le cartelle e metterà tutto il necessario in un unico archivio. Dove cercarlo e come lavorarci è descritto in dettaglio in .
Tuttavia, il wizard raccoglie i log non di tutti i compiti e, ad esempio, se hai bisogno di esaminare i log di un ristorante, di un failover o di un failback, il tuo percorso è nella cartella %ProgramData%/Veeam/Backup. Questo è il principale deposito di log di VBR, e %ProgramData% è una cartella nascosta, il che è normale. A proposito, il percorso predefinito può essere rinominato mediante una chiave di registro di tipo REG_SZ: LogDirectory nella chiave HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
Sulle macchine Linux, i log degli agenti di lavoro devono essere cercati in /var/log/VeeamBackup/, se si utilizza un account root o sudo. Se non hai privilegi di questo tipo, cerca i log in /tmp/VeeamBackup.
Per Veeam agent for %OS_name%, i log devono essere cercati in %ProgramData%/Veeam/Endpoint (o %ProgramData%/Veeam/Backup/Endpoint) e /var/log/veeam rispettivamente.
Se utilizzi l'Application-Aware Image Processing (e probabilmente lo stai facendo), la situazione si complica un po'. Avrai bisogno dei log del nostro helper, che sono memorizzati all'interno della macchina virtuale stessa, e dei log VSS. Come e dove ottenere questa fortuna è descritto in dettaglio in . E, naturalmente, ci sono per raccogliere i log di sistema necessari.
È comodo raccogliere gli eventi di Windows secondo . Se utilizzi Hyper-V, la questione si complica, poiché avrai bisogno anche di tutti i suoi log dalla sezione Applications and Service Logs > Microsoft > Windows. Anche se puoi sempre seguire un percorso più grossolano e semplicemente prelevare tutti gli oggetti da %SystemRoot%System32winevtLogs.
Se durante l'installazione/aggiornamento qualcosa si rompe, puoi trovare tutto il necessario nella cartella %ProgramData%/Veeam/Setup/Temp. Anche se non nascondo che negli eventi del sistema operativo si possono trovare informazioni più utili che in questi log. Le cose interessanti rimaste si trovano in %Temp%, ma lì ci sono principalmente i log di installazione di software ausiliario, come database, librerie .Net e altro. Tieni presente che Veeam viene installato da msi, e tutti i suoi componenti vengono installati anch'essi come pacchetti msi separati, anche se non è stato mostrato nell'interfaccia grafica. Pertanto, se l'installazione di uno dei componenti fallisce, l'intera installazione di VBR verrà interrotta. Bisogna quindi controllare i log per vedere cosa si è rotto e in quale momento.
E un consiglio finale: dopo aver ricevuto un errore durante l'installazione, non avere fretta di cliccare su OK. Prima prendi i log, poi clicca su OK. In questo modo otterrai un log che termina al momento dell'errore, senza spazzatura alla fine.
A volte è necessario immergersi nei log di vSphere. Un compito molto ingrato, ma, rimboccandosi le maniche, è necessario affrontare anche questo. Nel caso più semplice, avremo bisogno dei log degli eventi della macchina virtuale vmware.log, che si trovano accanto al suo file .vmx. In un caso più complesso, apriamo Google e chiediamo dove si trovano i log per la tua versione dell'host, poiché VMware ama cambiare questo percorso da una release all'altra. Ecco, ad esempio, , e questo è per . Per i log di vCenter, ripetiamo la procedura . Ma in generale, ci interessano i log degli eventi dell'host hostd.log, gli eventi degli host gestiti da vCenter vpxa.log, i log del kernel vmkernel.log e i log di autenticazione auth.log. E nei casi più gravi, può essere utile il log SSO, che si trova nella cartella SSO.
Complicato? Confuso? Spaventoso? Eppure non è nemmeno la metà delle informazioni con cui il nostro supporto lavora quotidianamente. Quindi, sono davvero molto bravi.
Componenti Veeam
E come conclusione di questo articolo introduttivo, parleremo un po' dei componenti di Veeam Backup & Replication. Infatti, quando cerchi la causa dei problemi, è utile capire come è strutturato il paziente.
Quindi, come probabilmente tutti sanno, Veeam Backup è un'applicazione SQL-based. Cioè, tutte le impostazioni, tutte le informazioni e, in generale, tutto ciò che è necessario per un corretto funzionamento si trova nel suo database. Piuttosto, in due database, se parliamo della combinazione VBR e EM: VeeamBackup e VeeamBackupReporting, rispettivamente. È così che funziona: installiamo un'altra applicazione e appare un altro database. Per non mettere tutte le uova in un unico paniere.
Ma affinché tutto questo funzioni senza intoppi, abbiamo bisogno di un insieme di servizi e applicazioni che colleghino tutti i componenti insieme. Solo per fare un esempio, ecco come appare in uno dei miei laboratori:
Nel ruolo di direttore d'orchestra c'è Veeam Backup Service. È lui che gestisce lo scambio di informazioni con i database. Risponde inoltre all'avvio di tutti i compiti, si occupa dell'orchestrazione delle risorse allocate e funge da centro di comunicazione per diverse console, agenti e tutto il resto. Insomma, senza di lui non si può fare, ma questo non significa affatto che faccia tutto da solo.
A supportarlo nell'esecuzione di quanto pianificato c'è Veeam Backup Manager. Non è un servizio, ma un'entità che si occupa dell'avvio dei job e monitora il processo della loro esecuzione. Le braccia operative del backup service, che si connette agli host, crea snapshot, monitora il retention e così via.
Ma torniamo alla lista dei servizi. Veeam Broker Service. È apparso in v9.5 (e non è un miner di criptovalute, come allora pensarono alcuni). Si occupa di raccogliere informazioni sui host VMware e mantenerle aggiornate. Ma non correte subito a scrivere commenti arrabbiati su come stiamo spiando voi e rubando tutte le vostre credenziali. È tutto un po' più semplice. Quando avviate un backup, la prima cosa da fare è connettersi all'host e aggiornare tutti i dati sulla sua struttura. È una storia piuttosto lenta e ingombrante. Ricordate quanto dura l'operazione di accesso attraverso l'interfaccia web e tenete presente che lì si considera solo il livello superiore. E poi bisogna anche espandere tutta la gerarchia fino al posto desiderato, tra l'altro. Insomma, un incubo. Se state avviando una decina di backup, ogni job dovrà passare attraverso questa procedura. Se si parla di grandi infrastrutture, questo processo può richiedere dieci minuti o più. Pertanto, è stata presa la decisione di dedicare un servizio separato per ottenere sempre informazioni aggiornate. All'avvio, controlla e scansiona tutta l'infrastruttura aggiunta, e poi cerca di lavorare solo a livello di cambiamenti incrementali. Quindi, anche se avviate contemporaneamente cento backup, tutti richiederanno informazioni dal nostro broker, senza affliggere gli host con le proprie richieste. Se siete preoccupati per le risorse, secondo i nostri calcoli, per 5000 macchine virtuali è necessario solo circa 100 Mb di memoria.
In seguito abbiamo Veeam Console. Anche nota come Veeam Remote Console, o Veeam.Backup.Shell. Questo è il GUI che vediamo negli screenshot. È tutto semplice e ovvio: la console può essere avviata da qualsiasi luogo, purché sia Windows e che ci sia connessione al server VBR. L'unica cosa da dire: il processo FLR monterà i punti localmente (cioè sulla macchina dove è avviata la console). E anche i vari Veeam Explorers verranno avviati localmente, poiché sono parte della console. Ma sto già divagando...
Il prossimo servizio interessante è Veeam Backup Catalog Data Service. Nell'elenco dei servizi è noto come Veeam Guest Catalog Service. Si occupa dell'indicizzazione dei file system sulle macchine guest e riempie di queste informazioni la cartella VBRCatalog. Viene utilizzato solo dove è attivata l'opzione di indicizzazione. È consigliabile attivarla solo se si dispone di un Enterprise Manager. Pertanto, il consiglio è: non attivate l'indicizzazione così, a meno che non abbiate un EM. Risparmiatevi nervi e tempo del supporto.
Inoltre, tra gli altri importanti servizi, è opportuno menzionare Veeam Installer Service, grazie al quale avviene la consegna e l'installazione dei componenti necessari su proxy, repository e altri gateway. Infatti, esso consegna i pacchetti .msi sui server e ne gestisce l'installazione.
Veeam Data Mover — tramite agenti ausiliari eseguiti sui proxy (e non solo) si occupa del trasferimento dei dati. Ad esempio, durante il backup un agente leggerà i file dai datastore dell'host e un secondo li copierà attentamente nel backup.
Voglio sottolineare un aspetto importante che spesso provoca reazioni nei clienti: la differenza tra le versioni dei servizi e quelle visibili nella console Programmi e funzionalità. Sì, l'elenco sarà lo stesso, ma le versioni possono mostrare una completa discordanza. Questo non è proprio ideale dal punto di vista visivo, ma è comunque normale se tutto funziona stabilmente. Ad esempio, il numero di versione del servizio Installer è molto indietro rispetto agli altri. Terribile? No, poiché non viene reinstallato completamente, ma si aggiorna semplicemente il suo DLL. Con la patch v9.5 U4 si è verificato un incubo per il supporto: nell'aggiornamento tutti i servizi hanno ricevuto nuove versioni, tranne il principale. Nella patch U4b, il servizio di trasporto ha superato tutti gli altri di ben due versioni (se giudichiamo dai numeri). Anche questo è normale: è stato trovato un grave bug, quindi ha ricevuto un aggiornamento bonus rispetto agli altri. Pertanto, per concludere: la differenza delle versioni PUÒ essere un problema, ma se esiste una differenza e tutto funziona correttamente, probabilmente è così che deve essere. Tuttavia, non è vietato chiedere chiarimenti al supporto.
Questi erano i cosiddetti servizi obbligatori o Mandatory services. Ce n'è anche un'intera serie di servizi ausiliari, come Tape Service, Mount Service, vPowerNFS Service e così via.
Per Hyper-V, in generale, è tutto lo stesso, solo che c'è il specifico Veeam Backup Hyper-V Integration Service e il suo driver per lavorare con il CBT.
E alla fine parleremo di chi lavora su virtual machine durante il backup. Per avviare gli script pre- e post-freeze, per creare una shadow copy, raccogliere metadati, gestire i log delle transazioni SQL e altro, si utilizza Veeam Guest Helper. E se avviene l'indicizzazione dei file system, Veeam Guest Indexer . Questi sono servizi temporanei, attivati durante il backup e rimossi dopo di esso.
Nel caso di macchine Linux, è tutto molto più semplice grazie alla presenza di un gran numero di librerie integrate e alle capacità del sistema stesso. Ad esempio, l'indicizzazione avviene tramite mlocate.
Per ora è tutto
Non voglio più tediarvi e la breve introduzione allo spazio interno di Veeam è finita. Sì, non siamo nemmeno lontanamente arrivati ai log stessi, ma credetemi, affinché le informazioni in essi contenute non sembrino un flusso di coscienza sconnesso, è assolutamente necessario un'introduzione di questo tipo. Ho in programma di passare ai log veri e propri solo nel terzo articolo, mentre il piano per il prossimo sarà spiegare chi genera i log, cosa esattamente vi è riportato e perché in quel modo, e non in un altro.
Fonte: habr.com
