Nós, da Veeam, adoramos logs. E como a maioria das nossas soluções é modular, geramos muitos logs. Como nossa área de atuação é garantir a segurança dos seus dados (ou seja, a sua tranquilidade), os logs devem não apenas registrar cada pequeno detalhe, mas fazê-lo de maneira detalhada. Isso é necessário para que, em caso de problemas, possamos entender como isso aconteceu, quem é o culpado e o que fazer em seguida. É como na criminologia: você nunca sabe qual pequeno detalhe pode ajudá-lo a encontrar o assassino de Laura Palmer.
Por isso, decidi me lançar em uma série de artigos onde falarei de forma sequencial sobre o que registramos nos logs, onde os armazenamos, como não enlouquecer com sua estrutura e o que realmente procurar neles.
Por que uma série de artigos e por que não descrever tudo de uma só vez?
Simplesmente listar onde cada log está localizado e o que contém seria uma tarefa bastante ingrata. E pensar em manter essa informação atualizada é até assustador. Uma simples listagem de todos os tipos possíveis de logs no Veeam Backup & Replication seria uma tabela de várias páginas em fonte pequena. Além disso, ela só seria atual no momento da publicação, já que, com a saída do próximo patch, podem surgir novos logs, a lógica das informações armazenadas nos antigos pode mudar, e assim por diante. Portanto, é muito mais vantajoso explicar a estrutura deles e a essência das informações contidas. Isso permitirá uma melhor orientação no futuro, em vez de apenas decorar nomes.
Assim, para não mergulharmos de cabeça em um mar de textos longos, vamos fazer um trabalho preparatório neste artigo. Portanto, hoje não vamos nos aprofundar nos próprios logs, mas iremos abordá-los pelo lado: vamos compor um glossário e discutir um pouco sobre a estrutura da Veeam sob a perspectiva da geração de logs.
Glossário e gírias
Aqui, em primeiro lugar, devo me desculpar com os defensores da pureza da língua russa e os estudiosos do dicionário de Ozhegov. Todos nós amamos muito nosso idioma nativo, mas a maldita indústria de TI opera em inglês. Não fomos nós que decidimos isso; assim, historicamente, as coisas aconteceram. Não sou culpada, ele veio por conta própria.
No nosso setor, o problema dos anglicismos (e jargões) tem suas especificidades. Quando palavras aparentemente inocentes como 'host' ou 'guest' já têm um significado muito específico em todo o mundo, em ⅙ do planeta continua a haver uma confusão heróica, com pessoas consultando dicionários. E o argumento absolutamente obrigatório 'Ah, mas aqui no meu trabalho...'.
Além disso, existe a nossa própria terminologia, que é característica dos produtos Veeam, embora algumas palavras e expressões tenham se popularizado. Por isso, agora vamos concordar sobre o que cada termo significa, e, doravante, quando eu mencionar 'guest', estarei me referindo especificamente ao que está escrito neste capítulo, e não ao que você está acostumado no seu trabalho. E sim, isso não é um capricho meu; são termos estabelecidos na indústria. É um tanto inútil lutar contra eles. Embora eu esteja sempre aberto a debater nos comentários.
Infelizmente, existem muitos termos em nosso trabalho e nos produtos, então não tentarei enumerá-los todos. Apenas os mais básicos e necessários para sobreviver em um mar de informações sobre backups e logs. Para os interessados, posso também de um colega sobre faixas, onde ele também traz uma lista de termos relacionados àquela parte da funcionalidade.
Host: No mundo da virtualização, isso se refere a uma máquina com hipervisor. Física, virtual, em nuvem — não importa. Se um hipervisor (ESXi, Hyper-V, KVM, etc.) está rodando em algo, então esse 'algo' é chamado de host. Seja um cluster de dez racks ou seu laptop com um laboratório de uma a duas máquinas virtuais — se você iniciou um hipervisor, você se tornou um host. Porque o hipervisor hospeda máquinas virtuais. Há até uma história de que a VMware, em determinado momento, quis estabelecer uma associação forte da palavra 'host' especificamente com o ESXi. Mas não conseguiu.
No mundo moderno, o conceito de 'host' praticamente se misturou ao conceito de 'servidor', o que gera certa confusão na comunicação, especialmente quando se discute infraestrutura Windows. Assim, qualquer máquina que tenha algum serviço de interesse pode ser chamada de host. Por exemplo, nos logs do WinSock, tudo é marcado como host. O clássico 'Host not found' é um exemplo disso. Portanto, devemos partir do contexto, mas lembrar — no mundo da virtualização, um host é aquele que hospeda guests (sobre isso, duas linhas abaixo).
Entre os jargões locais (na verdade, acrônimos, neste caso) aqui lembramos que VMware é VI, vSphere é VC, e Hyper-V é HV.
Gast (Convidado): Máquina virtual que opera em um host. Não há necessidade de explicar, pois tudo é tão lógico e simples. No entanto, muitos insistem em trazer aqui outros significados.
Por quê? Eu não sei.
SO do convidado, ou seja, o sistema operacional da máquina convidada. E assim por diante.
Backup/Replication Job (trabalho de backup): Um jargão puramente do VMware, referindo-se a uma das tarefas. Backup job == Trabalho de Backup. Ninguém conseguiu pensar em uma boa tradução, então todos dizem "job". Com a ênfase na última sílaba.
Sim, assim tão facilmente se diz "job". E até em e-mails isso é escrito, e tudo bem.
Diversos Trabalhos de Backup, Tarefas de Backup e etc., obrigado, mas não é necessário. Apenas job, e você será entendido. O principal é colocar a ênfase na última sílaba.
Backup (Backup, bck. Para os verdadeiros veteranos, é permitido dizer bakup): Além do óbvio (uma cópia de segurança dos dados em algum lugar), também se refere ao próprio job (três linhas acima, se você já esqueceu), que resulta na criação do arquivo de backup. Provavelmente, os falantes nativos de inglês são muito preguiçosos para dizer toda vez I ran my backup job, então eles simplesmente dizem I ran my backup, e todos se entendem perfeitamente. Sugiro apoiar essa iniciativa maravilhosa.
Consolidate (Consolidação): Termo que surgiu no ESXi 5.0. Uma opção no menu de trabalho com snapshots que inicia o processo de remoção dos chamados snapshots orphaned. Ou seja, snapshots que fisicamente existem, mas caíram da estrutura lógica exibida. Teoricamente, esse processo não deve afetar os arquivos exibidos no gerenciador de snapshots, mas pode acontecer de tudo. A essência do processo de consolidação é que os dados do snapshot (disco filho) são gravados no disco principal (disco pai). O processo de união dos discos é chamado de merge. Se um comando de consolidação foi dado, a entrada do snapshot pode ser removida do banco de dados antes que o snapshot seja mesclado e excluído. E se o snapshot não puder ser excluído por qualquer motivo, esses snapshots orphaned aparecem. Sobre o trabalho com snapshots, a VMware possui . E nós também já escrevemos sobre eles .
Datastore (Armazenamento ou storage): É um conceito muito amplo, mas no mundo da virtualização, refere-se a um lugar onde são armazenados os arquivos das máquinas virtuais. De qualquer forma, é fundamental entender o contexto e, em caso de dúvidas, esclarecer o que exatamente seu interlocutor quis dizer.
Proxy (Proxy): É importante entender imediatamente que o Veeam Proxy não é exatamente a mesma coisa que estamos acostumados a ver na internet. Dentro dos produtos da Veeam, trata-se de uma entidade que se encarrega de transferir dados de um lugar para outro. Sem entrar em detalhes, o VBR é o servidor de comando, enquanto o proxy são suas ‘cavalos de trabalho’. Ou seja, o proxy é a máquina pela qual o tráfego flui e na qual estão instalados os componentes do VBR, que ajudam a gerenciar esse tráfego. Por exemplo, transferindo dados de um canal para outro ou simplesmente conectando discos (modo HotAdd).
Repository (Repositório): Tecnologicamente, isso é apenas uma entrada na base de dados do VBR, indicando o local onde os backups são armazenados e como se conectar a esse local. Na prática, pode ser desde um simples compartilhamento CIFS até um disco separado, servidor ou um bucket na nuvem. Novamente, estamos no contexto, mas entendemos que o repositório é simplesmente o lugar onde seus backups estão.
Snapshot (Snapshot): Aqueles que adoram gramática de Oxford preferem dizer 'snépshot' ou 'snépshot', no entanto, a maioria das pessoas iliteradas ganha devido à massa. Para quem não sabe, essa é uma tecnologia que permite restaurar o estado do disco em um determinado momento. Isso é feito, ou redirecionando temporariamente as operações de I/O do disco principal — isso será chamado de snapshot RoW (Redirect on Write) — ou transferindo os blocos que estão sendo sobrescritos do seu disco para outro — isso será chamado de snapshot CoW (Copy on Write). É graças às amplas possibilidades de aplicação dessas funções que a Veeam pode realizar sua mágica de backup. Estritamente falando, não apenas ela, mas isso será o caso em lançamentos futuros.
Na documentação e nos logs do ESXi há uma certa confusão em torno desse termo, e no contexto de menção a snapshots, podemos encontrar tanto os próprios snapshots, quanto o redo log e até mesmo o delta disk. Na documentação da Veeam não há tal desordem, e snapshot é um snapshot, enquanto redo log é exatamente o arquivo REDO, criado por um disco non-persistent independente. Os arquivos REDO são excluídos ao desligar a máquina virtual, por isso confundi-los com snapshots é um caminho para o fracasso.
Sintético: Backups sintéticos referem-se a backups reverse incremental e forever forward. Caso você ainda não tenha se deparado com este termo, é apenas um dos mecanismos usados para construir uma cadeia de backups. No entanto, também é possível encontrar o conceito de Transform nos logs, que é utilizado na criação de cópias completas a partir dos incrementos (synthetic full).
Tarefa: Este é o processo de tratamento de cada máquina individual dentro de um job. Ou seja, se você tiver um job de backup que inclui três máquinas, cada máquina será processada em uma tarefa separada. Assim, haverá quatro logs: um principal para o job e três para as tarefas. Porém, há um detalhe importante aqui: ao longo do tempo, a palavra "tarefa" se tornou excessivamente polissêmica. Quando falamos sobre logs gerais, entendemos que a tarefa se refere à VM. Mas há suas "tarefas" também no proxy e no repositório. Lá, isso pode significar tanto um disco virtual, quanto uma máquina virtual, ou todo o job. Portanto, é crucial não perder o contexto.
Veeam %name% Service:: Para o sucesso dos backups, vários serviços estão em operação, cuja lista pode ser encontrada na ferramenta padrão. Seus nomes refletem claramente sua essência, no entanto, entre eles, o mais importante é o Veeam Backup Service, sem o qual os demais não funcionarão.
VSS: Tecnicamente, VSS deve sempre se referir ao Microsoft Volume Shadow Copy Service. Na prática, é utilizado por muitos como sinônimo de Application-Aware Image Processing. O que, é claro, está categoricamente errado, mas isso é uma história do tipo "todo SUV pode ser chamado de Jeep, e você será compreendido".
Logs fantásticos e os lugares onde eles habitam
Quero começar este capítulo revelando um grande mistério — que hora é exibida nos logs?
Lembre-se:
- O ESXi sempre escreve logs em UTC+0.
- O vCenter mantém logs de acordo com o horário de seu fuso horário.
- A Veeam mantém logs de acordo com o horário e o fuso horário do servidor em que está instalada.
- E apenas os eventos do Windows no formato EVTX não estão vinculados a nada. Ao serem abertos, o horário é ajustado para a máquina na qual foram abertos. Essa é a opção mais conveniente, embora possa haver dificuldades também com ela. A única dificuldade perceptível é a diferença de locais. Este é um caminho praticamente garantido para logs ilegíveis. Sim, existem maneiras de corrigir isso, mas vamos apenas concordar que tudo em TI funciona em inglês e vamos sempre configurar a localidade dos servidores para inglês. Por favor.
Agora, vamos falar sobre os locais onde os logs residem e como obtê-los. No caso do VBR, existem duas abordagens.
A primeira opção é adequada se você não está ansioso para procurar entre um monte de arquivos que se referem ao seu problema específico. Para isso, temos um assistente separado, no qual você pode especificar um trabalho específico e o período exato para o qual você precisa dos logs. Ele então irá percorrer as pastas e reunir tudo necessário em um único arquivo. Detalhes sobre onde encontrá-lo e como trabalhar com ele estão escritos em .
No entanto, o assistente não coleta logs de todas as tarefas e, por exemplo, se você precisar examinar os logs de um restaurante, failover ou failback, o caminho correto é a pasta %ProgramData%/Veeam/Backup. Este é o principal repositório de logs do VBR, e %ProgramData% é uma pasta oculta, o que é normal. A propósito, o local padrão pode ser renomeado usando uma chave de registro do tipo REG_SZ: LogDirectory na chave HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
Nas máquinas Linux, os logs dos agentes de trabalho devem ser procurados em /var/log/VeeamBackup/, se for usada a conta root ou sudo. Se você não tem tais privilégios, procure os logs em /tmp/VeeamBackup.
Para o Veeam agent for %OS_name%, os logs devem ser procurados em %ProgramData%/Veeam/Endpoint (ou %ProgramData%/Veeam/Backup/Endpoint) e /var/log/veeam respectivamente.
Se você usa o Processamento de Imagem Ciente da Aplicação (e é bem provável que você o utilize), a situação se complica um pouco. Você precisará dos logs do nosso helper, que estão armazenados dentro da própria máquina virtual, e os logs do VSS. Detalhes sobre como e onde obter essa informação estão escritos em . E, claro, há para a coleta dos logs do sistema necessários.
Eventos do Windows são convenientemente coletados de acordo com . Se você estiver usando o Hyper-V, a situação se complica, pois você também precisará de todos os seus logs da seção Application and Service Logs > Microsoft > Windows. Embora sempre seja possível seguir um caminho mais direto e simplesmente pegar todos os objetos de %SystemRoot%System32winevtLogs.
Se algo quebrar durante a instalação/atualização, você pode encontrar tudo o que precisa na pasta %ProgramData%/Veeam/Setup/Temp. Embora não vou esconder que eventos do sistema operacional podem conter informações mais úteis do que esses logs. O que restar de interessante estará em %Temp%, mas lá estão principalmente os logs da instalação de softwares auxiliares, como banco de dados, bibliotecas .Net e outros. Tenha em mente que o Veeam é instalado a partir de um msi, e todos os seus componentes também são instalados como pacotes msi separados, mesmo que isso não tenha sido mostrado na interface gráfica. Portanto, se a instalação de um dos componentes falhar, toda a instalação do VBR será interrompida. Assim, você precisa verificar os logs para entender o que exatamente deu errado e em que momento.
E uma dica final: ao receber um erro durante a instalação, não se apresse em clicar em OK. Primeiro, colete os logs, depois clique em OK. Assim, você obterá um log que termina no momento do erro, sem lixo no final.
E às vezes é necessário mexer nos logs do vSphere. Uma tarefa bastante ingrata, mas, arregaçando as mangas, é preciso fazer. No caso mais simples, precisamos dos logs com eventos da máquina virtual vmware.log, que estão ao lado do seu arquivo .vmx. Em um caso mais complicado, abra o Google e pergunte onde estão os logs para a sua versão do host, pois a VMware adora mudar esse local de uma versão para outra. Aqui, por exemplo, , e aqui para . Para os logs do vCenter, repetimos o procedimento . Mas, de maneira geral, estaremos interessados nos logs de eventos do host hostd.log, eventos de hosts gerenciados pelo vCenter vpxa.log, logs do núcleo vmkernel.log e logs de autenticação auth.log. E, nos casos mais complicados, o log do SSO, que está na pasta SSO, pode ser útil.
Demais? Complicado? Assustador? E isso nem é metade das informações com as quais nosso suporte trabalha diariamente. Então, eles realmente são muito bons.
Componentes do Veeam
E, como finalização deste artigo introdutório, vamos falar um pouco sobre os componentes do Veeam Backup & Replication. Porque, ao procurar a causa das dores, é bom entender como o paciente está estruturado.
Então, como todos sabem, o Veeam Backup é um aplicativo baseado em SQL. Ou seja, todas as configurações, todas as informações e tudo o que é necessário para o seu funcionamento normal – tudo isso está em seu banco de dados. Na verdade, em dois bancos, se estamos falando da combinação VBR e EM: VeeamBackup e VeeamBackupReporting, respectivamente. Assim acontece: instalamos mais um aplicativo e surge mais um banco. Para não colocar todos os ovos em uma só cesta.
Mas para que tudo isso funcione de forma harmoniosa, precisamos de um conjunto de serviços e aplicativos que conectarão todos os componentes. Apenas como exemplo, assim é que isso aparece em um dos meus laboratórios:
No papel de maestro, temos Veeam Backup Service. Ele é responsável pela troca de informações com os bancos de dados. Também é responsável por iniciar todas as tarefas, orquestra os recursos alocados e atua como um centro de comunicação para diversas consoles, agentes e tudo mais. Em suma, sem ele nada funcionaria, mas isso não significa que ele faz tudo sozinho.
A execução do que foi planejado é auxiliada por Veeam Backup Manager. Este não é um serviço, mas uma entidade que gerencia o início dos trabalhos e monitora o processo de execução. As "mãos" do serviço de backup, que se conectam aos hosts, criam instantâneas, monitoram a retenção e assim por diante.
Mas vamos voltar à lista de serviços. Veeam Broker Service. Surgiu na v9.5 (e não é um minerador de criptomoedas, como alguns pensaram na época). Ele coleta informações sobre os hosts VMware e mantém sua atualidade. Mas não corram para escrever comentários raivosos dizendo que estamos espionando vocês e vazando todas as senhas/login para o taçmayoru. A situação é um pouco mais simples. Quando você inicia um backup, o primeiro passo é se conectar ao host e atualizar todos os dados sobre sua estrutura. É uma história bastante lenta e trabalhosa. Apenas lembre-se de quanto tempo leva o processo de login através da interface web, e tenha em mente que ali apenas a camada superior é considerada. E depois ainda é necessário abrir toda a hierarquia até o local desejado, aliás. Em suma, um pesadelo. Se você inicia uma dezena de backups, cada tarefa precisa passar por esse processo. Se falamos de grandes infraestruturas, esse processo pode levar dez minutos ou mais. Portanto, foi tomada a decisão de criar um serviço separado para isso, pelo qual sempre será possível obter informações atualizadas. Ao ser iniciado, ele verifica e escaneia toda a infraestrutura adicionada, e depois tenta operar apenas no nível das mudanças incrementais. Assim, mesmo que você ative simultaneamente cem backups, todos solicitarão informações ao nosso broker, em vez de atormentar os hosts com suas solicitações. Se você se preocupa com os recursos, nossos cálculos indicam que para 5000 máquinas virtuais, são necessários apenas cerca de 100 Mb de memória.
Em seguida, temos Veeam Console. Também conhecido como Veeam Remote Console, também conhecido como Veeam.Backup.Shell. Essa é a interface gráfica que vemos nas capturas de tela. Tudo é simples e evidente — a console pode ser iniciada de qualquer lugar, desde que seja Windows e haja conexão com o servidor VBR. A única coisa que se pode dizer: o processo FLR montará os pontos localmente (ou seja, na máquina onde a console está sendo executada). E os diversos Veeam Explorers também serão iniciados localmente, pois fazem parte da console. Mas isso me levou a um caminho mais profundo...
O próximo serviço interessante é Veeam Backup Catalog Data Service. Na lista de serviços, é conhecido como Veeam Guest Catalog Service. Ele se ocupa da indexação de sistemas de arquivos em máquinas virtuais e preenche a pasta VBRCatalog com essas informações. É utilizado apenas onde a opção de indexação está ativada. E ativá-la faz sentido apenas se você tiver o Enterprise Manager. Portanto, um conselho sincero: não ative a indexação sem necessidade, se você não tiver o EM. Preserve seus nervos e o tempo do suporte.
Também vale a pena mencionar outros serviços importantes, como Veeam Installer Service, que é responsável pela entrega e instalação dos componentes necessários em proxies, repositórios e outros gateways. Na prática, ele transporta os pacotes .msi para os servidores e realiza a instalação deles.
Veeam Data Mover — entrega dados através de agentes auxiliares (não apenas) instalados nos proxies. Por exemplo, durante o backup, um agente lerá os arquivos dos datastores do host, enquanto o outro os gravará cuidadosamente no backup.
É importante destacar uma questão que frequentemente gera reações dos clientes — a diferença de versões dos serviços e das informações no painel Programas e Recursos. Sim, a lista será a mesma, mas as versões podem estar completamente desordenadas. Isso não é muito agradável visualmente, porém é completamente normal, desde que tudo funcione de forma estável. Por exemplo, o número da versão do serviço Installer fica bastante atrasado em relação aos vizinhos. Um pesadelo? Não, pois ele não é reinstalado completamente, apenas suas DLLs são atualizadas. No patch v9.5 U4 ocorreu um pesadelo para o suporte técnico: na atualização, todos os serviços receberam novas versões, exceto o principal. No patch U4b, o serviço de transporte ultrapassou todos os outros por duas versões (se considerarmos os números). E isso também é normal — foi encontrado um bug sério nele, por isso recebeu uma atualização extra em relação aos outros. Portanto, em resumo: a diferença de versões PODE ser um problema, mas se a diferença existir e tudo funciona corretamente, provavelmente é assim que deve ser. Mas ninguém proíbe você de esclarecer isso com o suporte técnico.
Estes foram os chamados serviços obrigatórios ou Mandatory services. E ainda existem vários serviços auxiliares, como Tape Service, Mount Service, vPowerNFS Service e assim por diante.
Para o Hyper-V, tudo é o mesmo, apenas existe Veeam Backup Hyper-V Integration Service e seu próprio driver para trabalhar com CBT.
E no final, vamos falar sobre quem trabalha em ambientes virtuais durante o backup. Para a execução de scripts pré e pós-freeze, criação de cópias sombra, coleta de metadados, trabalho com logs de transações SQL e outros, é utilizado Veeam Guest Helper. E se acontece a indexação de sistemas de arquivos, Veeam Guest Indexer . Estes são serviços temporários, implantados durante o backup e removidos após sua conclusão.
No caso de máquinas Linux, tudo é muito mais fácil devido à grande quantidade de bibliotecas integradas e às capacidades do próprio sistema. Por exemplo, a indexação é feita através do mlocate.
Por enquanto, é tudo
Não me atrevo a te incomodar mais e uma breve introdução ao funcionamento interno do Veeam está encerrada. Sim, nem chegamos perto dos próprios logs, mas acredite, para que as informações apresentadas neles não pareçam um fluxo de consciência desconexo, tal introdução é absolutamente necessária. Pretendo abordar os logs propriamente ditos apenas no terceiro artigo, e o plano para o próximo é explicar quem gera os logs, o que exatamente está neles e por que é assim e não de outra forma.
Fonte: habr.com
