In Veeam amiamo i log. Poiché la maggior parte delle nostre soluzioni è modulare, generano un numero considerevole di log. E dato che il nostro ambito è garantire la sicurezza dei vostri dati (cioè il sonno tranquillo), i log devono non solo registrare ogni minimo evento, ma farlo in modo dettagliato. Questo è necessario affinché, in caso di problemi, sia chiaro cosa sia successo, chi è responsabile e quali siano i passaggi successivi. Qui è come nella criminologia: non sai mai quale piccolo particolare possa aiutarti a trovare l'assassino di Laura Palmer.
Perciò ho deciso di intraprendere una serie di articoli in cui racconterò passo dopo passo cosa registriamo nei log, dove li archiviazione, come non perdere la testa 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 quali log si trovano e cosa contengono è un'idea piuttosto poco praticabile. E pensare a mantenere queste informazioni aggiornate è spaventoso. Un semplice elenco di tutti i possibili tipi di log in Veeam Backup & Replication potrebbe riempire diverse pagine in caratteri minuscoli. Inoltre, sarà attuale solo al momento della pubblicazione; con l'uscita del prossimo aggiornamento possono emergere nuovi log, cambiare la logica delle informazioni memorizzate nei log esistenti, e così via. È quindi molto più vantaggioso spiegare la loro struttura e il significato delle informazioni contenute. Questo permetterà una migliore comprensione pratica rispetto a una semplice memorizzazione dei nomi.
Pertanto, per non tuffarci a capofitto in pagine di testo, in questo articolo faremo un po' di lavoro preparatorio. Oggi non entreremo nei log stessi, ma procederemo da lontano: creeremo un glossario e discuteremo brevemente la struttura di Veeam dal punto di vista della generazione dei log.
Glossario e gergo
Qui innanzitutto dobbiamo scusarci con i sostenitori della purezza della lingua russa e con i testimoni del dizionario di Ozhegov. Ammiro profondamente la nostra lingua madre, ma la maledetta industria IT funziona in inglese. Non è colpa nostra, ma così è storicamente. Non sono io a essere colpevole, è venuto da solo.
Nel nostro settore, il problema degli anglicismi (e del gergo) ha una sua specificità. Mentre nel mondo si comprende da tempo significati molto concreti dietro parole innocenti come 'host' o 'guest', su ⅙ della terra continua una disperata confusione con l'inserimento nei dizionari. E l'argomento obbligatorio 'Ma da noi al lavoro…'.
In aggiunta, c'è una terminologia strettamente nostra, che appartiene specificamente ai prodotti Veeam, anche se alcune parole e frasi sono entrate nel linguaggio comune. Pertanto, ora ci mettiamo d'accordo su cosa significa ogni termine, e in futuro con la parola 'guest' intenderò esattamente ciò che è scritto in questo capitolo, e non ciò che sei abituato a usare nel tuo lavoro. E sì, non è un capriccio personale, sono termini consolidati nell'industria. Combattere contro di essi è piuttosto futile. Anche se sono sempre aperto a discutere nei commenti.
Purtroppo, ci sono così tanti termini nel nostro lavoro e nei nostri prodotti che non cercherò di elencarli tutti. Solo i più basilari e necessari per sopravvivere in un mare di informazioni su backup e log. Per chi è interessato, posso anche dei colleghi sulle lingue, dove riportava anche un elenco di termini relativi a quella parte della funzionalità.
Host: Nel mondo della virtualizzazione, si tratta di una macchina con un hypervisor. Fisica, virtuale, cloud — non importa. Se qualcosa esegue un hypervisor (ESXi, Hyper-V, KVM, ecc.), allora si chiama host. Che sia un cluster di dieci rack o il tuo laptop con un laboratorio su un paio di macchine virtuali — se hai avviato un hypervisor, sei diventato un host. Perché l'hypervisor ospita macchine virtuali. C'è persino una leggenda che VMware una volta voleva ottenere un forte legame tra la parola host e ESXi. Ma non ci è riuscita.
Nel mondo moderno, il termine "host" si è praticamente fuso con quello di "server", creando una certa confusione nella comunicazione, specialmente quando si parla di infrastrutture Windows. Qualsiasi macchina che ospita un servizio di nostro interesse può quindi essere considerata un host. Ad esempio, nei log di WinSock, tutto viene etichettato come host. Il classico "Host not found" ne è un esempio. Dobbiamo quindi fare riferimento al contesto, ma ricordiamo che nel mondo della virtualizzazione, un host è ciò che ospita gli ospiti (di questo parleremo tra poco).
Tra i gerghi locali (più precisamente acronimi, in questo caso) si ricordano VMware – VI, vSphere – VC, e Hyper-V – HV.
Guest (Ospite): Una macchina virtuale che opera su un host. Qui non c'è niente da spiegare, è molto logico e semplice. Tuttavia, molti sono determinati a portare qui altri significati.
Perché? Non lo so.
Guest OS, quindi, è il sistema operativo della macchina ospite. E così via.
Backup/Replication Job (jobA): Un termine puramente VMWare che designa uno dei lavori. Backup job == Job di Backup. Come tradurlo elegantemente in russo? Nessuno ci ha mai pensato, quindi tutti usano "jobA" con l'accento sull'ultima sillaba.
Sì, è così semplice che si prende e si dice « job ». E lo scrivono anche nelle email, e va tutto bene.
Vari lavori di backup, attività di backup, ecc., grazie, ma basta. È solo job, e vi capiranno. L'importante è accentuare l'ultima sillaba.
Backup (Bècap, backup. Per i veri old-school è permesso anche bacàp): Oltre al significato ovvio (un backup di dati da qualche parte), significa anche il job stesso (le tre righe sopra, se già l'hai dimenticato), da cui emerge quel file di backup. Probabilmente, i gentiluomini anglofoni sono troppo pigri per dire ogni volta I ran my backup job, quindi dicono solo I ran my backup, e tutti si capiscono perfettamente. Propongo di sostenere questa iniziativa straordinaria.
Consolidare (Consolidamento): Termine introdotto in ESXi 5.0 Opzione nel menu di gestione degli snapshot, avvia il processo di eliminazione dei cosiddetti snapshot orfani. Ovvero snapshot che esistono fisicamente, ma che sono stati esclusi dalla struttura logica visualizzabile. Teoricamente, questo processo non dovrebbe influenzare i file visualizzati nel gestore degli snapshot, ma può succedere di tutto. 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 l'ordine di consolidamento, la registrazione dello snapshot può essere rimossa dal database prima che lo snapshot sia unito e cancellato. E se lo snapshot non può essere eliminato per qualsiasi motivo, allora compaiono questi snapshot orfani. VMware ha . E anche noi abbiamo scritto qualcosa su di loro .
Datastore (Stora o storage): Un concetto molto ampio, ma nel mondo della virtualizzazione si intende il luogo dove sono archiviati i file delle macchine virtuali. Tuttavia, in ogni caso, è necessario comprendere chiaramente il contesto e, in caso di dubbi, chiarire cosa intendesse esattamente il proprio interlocutore.
Proxy (Proxy): È importante comprendere fin da subito che Veeam Proxy non è esattamente la stessa cosa a cui siamo abituati nel panorama di internet. Nel contesto dei prodotti Veeam, rappresenta un'entità che si occupa di spostare i dati da un luogo all'altro. In termini semplici, VBR è il server centrale, mentre il proxy funge da cavallo di battaglia. Quindi, il proxy è la macchina attraverso la quale scorre il traffico e su cui sono installati i componenti di VBR, che aiutano a gestire questo traffico. Ad esempio, può spostare dati da un canale a un altro o semplicemente collegare dischi a sé (modalità HotAdd).
Repository (Репозиторий): Tecnicalmente, è semplicemente una registrazione nel database di VBR che indica dove sono memorizzati i backup e come connettersi a questo luogo. In effetti, può essere sia una semplice condivisione CIFS che un disco, un server o un bucket nel cloud. Insomma, ci troviamo nel contesto, ma capiamo che il repository è semplicemente il luogo dove sono archiviati i tuoi backup.
Snapshot (СнапшОт): Gli appassionati della grammatica di Oxford preferiscono dire chi è uno snapshot, chi è un altro, tuttavia la maggioranza non esperta prevale grazie alla sua maggiore massa. Per chi non lo sapesse, questa è una tecnologia che consente di ripristinare lo stato di un disco a un certo momento nel tempo. Si realizza tramite un temporaneo reindirizzamento delle operazioni di I/O lontano dal disco principale — questo sarà chiamato snapshot RoW (Redirect on Write) — oppure spostando i blocchi riscrivibili dal disco su un altro — questo sarà chiamato snapshot CoW (Copy on Write). È grazie alla versatilità di queste funzioni che Veeam può realizzare la sua magia di backup. A dire il vero, non solo a Veeam si deve questo, ma anche ai prossimi rilasci.
Nella documentazione e nei log di ESXi, intorno a questo termine regna il caos, e nel contesto menzionato degli snapshot si possono trovare sia gli snapshot stessi che i redo log e persino i delta disk. Nella documentazione Veeam non esiste tale confusione, e uno snapshot è semplicemente uno snapshot, mentre il redo log è proprio il file REDO, creato da un disco non persistente indipendente. I file REDO vengono eliminati quando si spegne la macchina virtuale, quindi confonderli con gli snapshot è un passo verso il fallimento.
Sintetico (Synthetic): I backup sintetici si riferiscono ai backup reverse incremental e forever forward. Se non hai mai sentito questo termine, è semplicemente uno dei meccanismi utilizzati per costruire una catena di backup. Tuttavia, nei log puoi anche incontrare il concetto di Transform, che viene utilizzato nella creazione di copie complete a partire dagli incrementi (synthetic full).
Task: Questo è il processo di elaborazione di ciascun singolo server all'interno di un job. Cioè: se hai un job di backup che include tre macchine, ogni macchina sarà elaborata come un task separato. In totale, ci saranno quattro log: uno principale per il job e tre per i task. Tuttavia, c'è un'importante sfumatura: col tempo la parola “task” è diventata eccessivamente ambigua. Quando parliamo di log generali, intendiamo che il task è proprio una VM. Ma ci sono anche i propri “task” nel proxy e nel 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: A favore di backup di successo lavorano diversi servizi, i cui nomi possono essere trovati negli strumenti standard. I loro nomi riflettono chiaramente la loro funzione, ma tra questi c'è il più importante — il Veeam Backup Service, senza il quale gli altri non funzioneranno.
VSS: Tecnicamente, VSS dovrebbe sempre riferirsi a Microsoft Volume Shadow Copy Service. In pratica, viene usato da molti come sinonimo di Application-Aware Image Processing. Questo, naturalmente, è categoricamente errato, ma è una storia del tipo 'Qualsiasi SUV può essere chiamato Jeep, e ti capiranno'.
Fantastici log e i luoghi in cui abitano
Voglio iniziare questo capitolo rivelando un grande segreto: quale ora appare nei log?
Ricordate:
- ESXi scrive sempre i log in UTC+0.
- vCenter registra i log secondo il suo fuso orario.
- Veeam registra i log in base all'orario e al fuso orario del server su cui è installato.
- E solo gli eventi Windows in formato EVTX non sono legati a nulla. Quando vengono aperti, l'ora viene ricalcolata in base alla macchina su cui sono stati aperti. È l'opzione più comoda, anche se a volte ci sono complicazioni. L'unica difficoltà tangibile è la differenza delle lingue locali. Questo è praticamente un modo garantito per avere log illeggibili. Sì, ci sono opzioni per risolverlo, ma non discutiamo sul fatto che tutto nell'IT funziona in inglese, e concordiamo di impostare sempre la lingua inglese sui server. Per favore.
Adesso parliamo dei luoghi dove risiedono i log e come ottenerli. Nel caso di VBR ci sono due approcci.
La prima opzione è adatta se non hai voglia di cercare nei vari file che riguardano specificamente il tuo problema. A questo scopo abbiamo un wizard separato, al quale puoi specificare un lavoro concreto e un periodo specifico per i log. Poi lui scorrerà le cartelle e metterà tutto il necessario in un zip. Di dove trovarlo e come lavorarci, è scritto in dettaglio in .
Tuttavia, il wizard non raccoglie i log di tutti i compiti e, ad esempio, se è necessario esaminare i log del ristorante, del failover o del failback, dovrai andare nella cartella %ProgramData%/Veeam/Backup. Questa è la principale repository di log di VBR, e %ProgramData% è una cartella nascosta, il che è normale. Inoltre, il percorso predefinito può essere modificato utilizzando una chiave di registro di tipo REG_SZ: LogDirectory nella diramazione HKEY_LOCAL_MACHINE/SOFTWARE/Veeam/Veeam Backup and Replication.
Sulle macchine Linux, i log degli agenti di lavoro possono essere trovati in /var/log/VeeamBackup/, se si utilizza un account root o sudo. Se non si dispone di tali privilegi, cerca i log in /tmp/VeeamBackup.
Per Veeam agent per %OS_name%, i log devono essere cercati in %ProgramData%/Veeam/Endpoint (o %ProgramData%/Veeam/Backup/Endpoint) e /var/log/veeam rispettivamente.
Se utilizzate la Elaborazione Immagine Consapevole dell'Applicazione (e probabilmente la state utilizzando), la situazione si complica un po'. Avrete bisogno dei log del nostro helper, che sono conservati all'interno della macchina virtuale stessa, e dei log VSS. Su come e dove ottenere queste informazioni, è scritto in dettaglio in . E, naturalmente, ci sono per la raccolta dei log di sistema necessari.
Gli eventi di Windows possono essere facilmente raccolti secondo . Se utilizzi Hyper-V, la situazione si complica, poiché avrai bisogno anche di tutti i suoi log dalla sezione Application and Service Logs > Microsoft > Windows. Anche se puoi sempre seguire un percorso più diretto e semplicemente raccogliere tutti gli oggetti da %SystemRoot%System32winevtLogs.
Se qualcosa si rompe durante l'installazione/aggiornamento, puoi trovare tutto il necessario nella cartella %ProgramData%/Veeam/Setup/Temp. Anche se non nasconderò che negli eventi del sistema operativo puoi trovare informazioni più utili rispetto a questi log. Il restante materiale interessante si trova in %Temp%, ma si tratta principalmente di log di installazione di software correlato, come database, librerie .Net e altro. Tieni presente che Veeam si installa tramite msi, e tutti i suoi componenti vengono installati come pacchetti msi separati, anche se non era mostrato nell'interfaccia grafica. Pertanto, se l'installazione di uno dei componenti fallisce, l'intera installazione di VBR si fermerà. Dobbiamo quindi accedere ai log e vedere cosa esattamente si è rotto e a che punto.
E un consiglio finale: se ricevi un errore durante l'installazione, non avere fretta di premere OK. Prima raccogli i log, poi premi OK. In questo modo otterrai un log che termina nel momento dell'errore, senza spazzatura alla fine.
Può capitare di dover esaminare i log di vSphere. È un'attività poco gratificante, ma, rimboccandosi le maniche, bisogna farlo anche per cose più complesse. Nella sua forma più semplice, avremo bisogno dei log degli eventi della macchina virtuale vmware.log, che si trovano accanto al suo file .vmx. Nel caso più complesso, possiamo aprire Google e cercare dove si trovano i log per la tua versione dell'host, dato che VMware ama cambiare la posizione da una versione all'altra. Ecco per esempio, , e per . Per i log di vCenter ripetiamo la procedura . Ma in generale, ci interesseranno i log degli eventi dell'host hostd.log, gli eventi degli host sotto la gestione di vCenter vpxa.log, i log del kernel vmkernel.log e i log di autenticazione auth.log. E nei casi più disperati, potrebbe essere utile il log SSO, che si trova nella cartella SSO.
Complicato? Confuso? Spaventoso? Eppure, questa è solo una parte delle informazioni con cui il nostro supporto lavora ogni giorno. Quindi sono davvero molto bravi.
Componenti Veeam
E per concludere questo articolo introduttivo, parleremo un po' dei componenti di Veeam Backup & Replication. Quando si cerca la causa dei problemi, è utile comprendere come è strutturato il paziente.
Allora, come è sicuramente noto a tutti, Veeam Backup è un'applicazione basata su SQL. In altre parole, tutte le impostazioni, tutte le informazioni e in generale tutto ciò che è necessario per un normale funzionamento si trova nel suo database. Più precisamente, in due database, se parliamo del collegamento VBR e EM: VeeamBackup e VeeamBackupReporting, rispettivamente. Così va: installando un'altra applicazione, appare un altro database. Per non mettere tutte le uova in un solo paniere.
Ma affinché tutto questo lavori in modo armonioso, avremo bisogno di un insieme di servizi e applicazioni che colleghino tutti i componenti insieme. Solo per esempio, ecco come appare in uno dei miei laboratori:
Nel ruolo di direttore d'orchestra c'è Veeam Backup Service. È lui a rispondere per lo scambio di informazioni con i database. Inoltre, si occupa dell'avvio di tutti i compiti, orchestrando le risorse allocate e fungendo da centro di comunicazione per le varie console, agenti e altro. Insomma, senza di lui non si potrebbe proprio fare, ma ciò non significa affatto che faccia tutto da solo.
A realizzare ciò che ha in mente lo aiuta Veeam Backup Manager. Questo non è un servizio, ma un'entità che si occupa di avviare job e monitorare l'andamento della loro esecuzione. Le braccia operative del servizio di backup, che si collegano agli host, creano snapshot, controllano il retention e così via.
Ma torniamo all'elenco dei servizi. Veeam Broker Service. È stato introdotto nella v9.5 (e non è un miner di criptovaluta, come pensavano alcuni all'epoca). Si occupa della raccolta delle informazioni sugli host VMware e del mantenimento della loro aggiornamento. Ma non affrettatevi a scrivere commenti indignati, dicendo che vi stiamo spiando e rubiamo tutte le credenziali. È tutto un po' più semplice. Quando avviate un backup, la prima cosa da fare è collegarsi all'host e aggiornare tutte le informazioni sulla sua struttura. È una storia piuttosto lenta e ingombrante. Ricordate quanto tempo impiega l'operazione di login attraverso l'interfaccia web, e considerati solo i dati superficiali. Inoltre, è necessario espandere l'intera gerarchia fino al punto richiesto. In breve, un incubo. Se state eseguendo un centinaio di backup, ciascun lavoro deve affrontare questa procedura. Se parliamo di grandi infrastrutture, questo processo può richiedere dieci minuti o più. Pertanto, è stata presa la decisione di creare un servizio separato per ottenere sempre informazioni aggiornate. All'avvio, verifica e scansiona tutta l'infrastruttura aggiunta, e poi cerca di funzionare solo a livello di cambiamenti incrementali. Così, anche se avviate contemporaneamente cento backup, tutti richiederanno informazioni dal nostro broker, invece di stressare gli host con le loro richieste. Se siete preoccupati per le risorse, secondo i nostri calcoli, ci vogliono solo circa 100 Mb di memoria per 5000 macchine virtuali.
Proseguiamo con Veeam Console. Anche nota come Veeam Remote Console, o Veeam.Backup.Shell. Questa è l'interfaccia grafica che vediamo negli screenshot. Tutto è semplice e chiaro: la console può essere avviata da qualsiasi luogo, purché sia Windows e ci sia una connessione al server VBR. L'unica cosa che posso dire: il processo FLR monterà i punti localmente (cioè sulla macchina dove è avviata la console). Naturalmente, anche i vari Veeam Explorers verranno avviati localmente, poiché fanno parte della console. Ma mi sto allontanando dall'argomento...
Il prossimo servizio interessante è Veeam Backup Catalog Data Service. Nell'elenco dei servizi è conosciuto come Veeam Guest Catalog Service. Si occupa di indicizzare i file system sulle macchine guest e riempie la cartella VBRCatalog con queste informazioni. Viene utilizzato solo dove è attivata l'opzione di indicizzazione. Ha senso attivarla solo se si dispone di Enterprise Manager. Pertanto, un consiglio sincero: non attivate l'indicizzazione senza motivo se non avete EM. Risparmiate i vostri nervi e il tempo del supporto.
Tra gli altri importanti servizi, vale la pena menzionare Veeam Installer Service, con il quale avviene la consegna e l'installazione dei componenti necessari su proxy, repository e altri gateway. In pratica, trasporta i pacchetti .msi sui server e ne esegue l'installazione.
Veeam Data Mover — attraverso agenti ausiliari eseguibili su proxy (e non solo) si occupa del trasferimento dei dati. Ad esempio, durante il backup, un agente leggerà i file dai datastore dell'host, mentre un secondo li registrerà con attenzione nel backup.
È importante sottolineare un aspetto che spesso colpisce i clienti: la differenza tra le versioni dei servizi e le informazioni nell'area Programmi e funzionalità. Sì, l'elenco sarà identico, ma le versioni possono variare notevolmente. Questo, visivamente, non è l'ideale, ma è del tutto normale se tutto funziona stabilmente. Ad esempio, la versione del servizio Installer è notevolmente indietro rispetto alle altre. È un disastro? No, perché non viene reinstallato completamente, ma aggiornata solo la sua DLL. Nel patch v9.5 U4 si è verificato un incubo per il supporto tecnico: durante l'aggiornamento, tutti i servizi hanno ricevuto nuove versioni, tranne quello principale. Nel patch U4b, il servizio di trasporto ha superato tutti gli altri di ben due versioni (se si giudica dai numeri). E questo è normale: è stata trovata una grave vulnerabilità in esso, quindi ha ricevuto un aggiornamento extra rispetto agli altri. Pertanto, in sintesi: la differenza di versioni PUÒ essere un problema, ma se essa esiste e tutto funziona correttamente, probabilmente è così che deve essere. Tuttavia, non c'è nulla che vi impedisca di chiedere chiarimenti al supporto tecnico.
Si trattava di quelli che vengono definiti servizi obbligatori o Mandatory services. Esistono anche diversi servizi ausiliari, come Tape Service, Mount Service, vPowerNFS Service e così via.
Per Hyper-V è fondamentalmente lo stesso, solo che ci sono aspetti specifici. Servizio di integrazione Veeam Backup Hyper-V e un driver dedicato per lavorare con il CBT.
Infine parleremo di chi opera sulle macchine virtuali durante il backup. Per l'esecuzione di script pre- e post-freeze, per la creazione di snapshot, la raccolta di metadati, la gestione dei 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, distribuiti durante il backup e rimossi successivamente.
Nel caso delle macchine Linux, tutto è molto più semplice grazie alla presenza di numerose librerie integrate e alle capacità del sistema stesso. Ad esempio, l'indicizzazione avviene tramite mlocate.
Per ora è tutto.
Non voglio più tediarvi e una breve Considero conclusa l'introduzione allo spazio sottostante di Veeam. Sì, non ci siamo nemmeno avvicinati ai log, ma credetemi, per fare in modo che le informazioni presentate in essi non appaiano come un flusso di coscienza disordinato, un'introduzione del genere è sicuramente necessaria. Pianifico di passare ai log veri e propri solo nel terzo articolo, mentre il prossimo avrà come obiettivo spiegare chi genera i log, cosa è effettivamente visualizzato in essi e perché in questo modo, e non in altro modo.
Fonte: habr.com
