Continuamos nossa imersão no fascinante mundo da solução de problemas nos logs. No nosso último encontro, definimos o significado de termos básicos e tivemos uma visão geral da estrutura do Veeam como um único aplicativo. A tarefa agora é entender como os arquivos de log são formados, que tipo de informações eles contêm e por que eles parecem ser como são.
O que você acha que são esses "logs"? Para a maioria, os logs de qualquer aplicativo deveriam assumir o papel de uma entidade onipotente, que na maior parte do tempo permanece em algum lugar nos bastidores, mas que no momento certo aparece do nada com armadura reluzente para salvar o dia. Ou seja, eles devem conter tudo, desde os menores erros em cada componente até transações específicas do banco de dados. E logo após um erro, deveria haver uma anotação sobre como corrigi-lo. Tudo isso deve caber em alguns megabytes, no máximo. É só texto! Não é possível que arquivos de texto ocupem dezenas de gigabytes, ouvi isso em algum lugar!
Assim, os logs
No mundo real, os logs são apenas um arquivo de informações de diagnóstico. E o que armazenar, de onde obter as informações para armazenamento e quão detalhadas elas devem ser, cabe aos desenvolvedores decidirem. Alguns optam pelo minimalismo, armazenando apenas registros de LIGADO/DESLIGADO, enquanto outros coletam diligentmente tudo o que conseguem alcançar. Embora exista uma opção intermediária com a possibilidade de escolher o chamado Nível de Registro, onde você mesmo indica quão detalhadas as informações que deseja manter e quanto espaço extra você possui em seus discos =) No VBR, existem seis desses níveis, a propósito. E, acredite, você não quer ver o que acontece quando o registro é feito no nível mais detalhado com espaço livre em seu disco.
Está bem. Temos uma ideia do que queremos manter, mas surge a pergunta legítima: de onde obter essas informações? Parte dos eventos a serem registrados, é claro, são gerados por nossos próprios processos internos. Mas o que fazer quando ocorre uma interação com o ambiente externo? Para não cairmos em um caos de gambiarras e soluções improvisadas, a Veeam tende a não reinventar a roda. Sempre que há uma API pronta, uma função integrada ao sistema, uma biblioteca, etc., daremos preferência às opções existentes antes de começarmos a criar nossas soluções elaboradas. Embora estas últimas também sejam abundantes. Portanto, ao analisar os logs, é importante entender que a maior parte dos erros provém de mensagens de APIs externas, chamadas de sistema e outras bibliotecas. Nesse caso, o papel do VBR é encaminhar esses erros para os arquivos de log como estão. E a principal tarefa do usuário é aprender a entender qual linha é de quem e por que esse “quem” é responsável. Portanto, se o código de erro do log do VBR o leva até uma página do MSDN, isso é normal e correto.
Como já discutimos anteriormente: a Veeam é um aplicativo baseado em SQL. Isso significa que todas as configurações, todas as informações e tudo o que é necessário para o funcionamento normal está armazenado em seu banco de dados. Daqui vem a simples verdade: o que não está nos logs, provavelmente está no banco. Mas isso também não é uma solução mágica: algumas coisas não estão nem nos logs locais dos componentes da Veeam, nem em seu banco de dados. Portanto, é necessário aprender a estudar os logs do host, os logs da máquina local e os logs de tudo o que participa do processo de backup e restauração. Às vezes, a informação necessária não está em lugar nenhum. Esse é o caminho.
Alguns exemplos de tais APIs
Esta lista não se propõe a ser uma referência abrangente, então não busque nela a verdade absoluta. Sua função é apenas mostrar as APIs e tecnologias externas mais frequentemente usadas em nossos produtos.
Vamos começar com VMware.
O primeiro da lista será vSphere API. Utilizado para autenticação, leitura de hierarquias, criação e exclusão de snapshots, solicitação de informações sobre máquinas e muito (muito) mais. A funcionalidade da solução é bastante ampla, por isso, recomendo a todos que consultem a VMware vSphere API Reference para a versão e . Para versões mais atuais, é fácil encontrar informações na internet.
VIX API. Magia negra do hipervisor, para a qual há uma lista separada . API do VMware para trabalhar com arquivos no host sem conexão de rede. Uma opção de último recurso quando é necessário colocar um arquivo na máquina que não possui um canal de comunicação melhor. É uma fonte de dor e sofrimento se o arquivo for grande e o host estiver sobrecarregado. Mas a regra aqui é que mesmo 56,6 Kb/s é melhor do que 0 Kb/s. No Hyper-V, uma coisa semelhante é chamada de PowerShell Direct. Mas isso só era verdade até o advento
do vSphere Web Services API . Começando com o vSphere 6.0 (aproximadamente, já que esse API foi introduzido pela primeira vez na versão 5.5), é usado para trabalhar com máquinas virtuais e há muito substituiu o VIX. Na verdade, é mais uma API para gerenciar o vSphere. Para os interessados, recomendo estudar manual.
VDDK (Virtual Disk Development Kit). Uma biblioteca que foi parcialmente mencionada neste . Usada para ler discos virtuais. Há muito tempo, fazia parte do VIX, mas ao longo do tempo foi separada em um produto distinto. No entanto, como herdeiro, usa os mesmos códigos de erro que o VIX. Mas, por algum motivo, não há nenhuma descrição desses erros na própria SDK. Portanto, de forma empiricamente, foi descoberto que os erros do VDDK com outros códigos são apenas uma tradução de código binário para decimal. Consiste em duas partes - a primeira metade é uma informação não documentada sobre o contexto, e a segunda parte são os erros tradicionais do VIX/VDDK. Por exemplo, se vemos:
Erro VDDK: 21036749815809.Erro desconhecido
, podemos converter isso para hex e obter 132200000001. O início não informativo 132200 é descartado, e o restante será nosso código de erro (VDDK 1: Erro desconhecido). Recentemente, foi feita uma postagem separada sobre os erros VDDK mais comuns. .
Agora vamos olhar para Windows.
. Aqui, tudo o que precisamos e é importante pode ser encontrado no Event Viewer. Mas há uma pegadinha: por uma tradição antiga, o Windows registra não o texto completo do erro, mas apenas seu número. Por exemplo, o erro 5 é 'Acesso negado', 1722 é 'O servidor RPC não está disponível' e 10060 é 'Tempo de conexão esgotado'. Claro, é ótimo se você se lembra dos mais conhecidos, mas e quanto aos erros desconhecidos até agora?
E para que a vida não pareça um doce, os erros também são armazenados em formato hexadecimal, com o prefixo 0x8007. Por exemplo, 0x8007000e é na verdade 14, Faltando Memória. A razão para isso permanece um mistério. No entanto, você pode baixar de graça e sem SMS uma lista completa de erros de .
Aliás, às vezes aparecem outros prefixos, não só 0x8007. Nessa situação triste, para entender o HRESULT (“handle de resultado”), é preciso se aprofundar ainda mais em para desenvolvedores. Na vida cotidiana, não recomendo fazer isso, mas caso você esteja realmente pressionado ou apenas curiosidade, agora você sabe o que fazer.
Mas os companheiros da Microsoft foram um pouco mais indulgentes e apresentaram ao mundo a ferramenta . É um pequeno pedaço de felicidade em console, capaz de traduzir códigos de erro para uma linguagem compreensível sem precisar usar o Google. Funciona mais ou menos assim.
C:UsersrootDesktop>err.exe 0x54f
# para hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ocorreu um erro interno.
# como um HRESULT: Severidade: SUCESSO (0), INSTALAÇÃO_NULL (0x0), Código 0x54f
# para hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ocorreu um erro interno.
# 2 correspondências encontradas para "0x54f"Surge uma pergunta legítima: por que não escrevemos a decodificação nos logs imediatamente, deixando esses códigos misteriosos? A resposta está em aplicativos de terceiros. Quando você mesmo faz uma chamada de WinAPI, decifrar sua resposta não é difícil, pois existe até uma chamada especial de WinAPI para isso. Mas como já foi mencionado, nossos logs capturam tudo que recebemos em respostas. E aqui, para decifrar, seria necessário monitorar constantemente esse fluxo de consciência, extrair pedaços com erros do Windows, decifrar e inserir de volta. Vamos ser sinceros, não é a tarefa mais emocionante.
API de Gerenciamento de Arquivos do Windows é amplamente utilizada ao trabalhar com arquivos. Criar arquivos, excluir, abrir para gravação, trabalhar com atributos e muito mais.
A mencionada acima PowerShell Direct como um análogo ao VIX API no mundo do Hyper-V. Infelizmente, não tão flexível: muitas limitações funcionais, não funciona com todas as versões de host e não com todas as máquinas virtuais.
RPC (Remote Procedure Call) Eu acho que não há uma única pessoa que trabalhou com Windows que não tenha visto erros relacionados ao RPC. Apesar da crença popular, não é um único protocolo, mas qualquer protocolo cliente-servidor que atende a uma série de parâmetros. No entanto, se tivermos um erro de RPC em nossos logs, em 90% dos casos será um erro do Microsoft RPC, que faz parte do DCOM (Modelo de Objeto Componente Distribuído). Há uma enorme quantidade de documentação sobre esse tema disponível na rede, mas a maior parte está bastante desatualizada. Mas se houver um forte desejo de estudar o assunto, posso recomendar artigos. , e uma longa lista .
As principais causas do surgimento de erros de RPC em nossos logs são as falhas nas tentativas de interação entre componentes VBR (servidor > proxy, por exemplo) e, na maioria das vezes, devido a problemas de comunicação.
O campeão entre todos os campeões é o erro The RPC server is unavailable (1722). Simplificando, o cliente não conseguiu estabelecer uma conexão com o servidor. Como e por que isso acontece — não há uma resposta única, mas geralmente é um problema de autenticação ou de acesso à rede na porta 135. Isso é característico de infraestrutura com alocação dinâmica de portas. Há até uma . E a Microsoft possui um para encontrar as causas da falha.
O segundo erro mais comum é: There are no more endpoints available from the endpoint mapper (1753). O cliente ou servidor RPC não conseguiram escalar uma porta para si. Isso geralmente ocorre quando o servidor (neste caso, a máquina virtual) foi configurado para alocação dinâmica de portas dentro de um intervalo restrito que foi esgotado. E se olharmos do lado do cliente (neste caso, o servidor VBR), isso significa que o nosso VeeamVssAgent não foi iniciado ou não foi registrado como interface RPC. Há também .
E para finalizar o Top 3 de erros RPC, lembremos do erro RPC function call failed (1726). Isso aparece quando a comunicação foi estabelecida, mas as solicitações RPC não funcionam. Por exemplo, solicitamos informações sobre o status do VSS (caso uma cópia sombra esteja em andamento, e tentamos acessá-la), mas recebemos silêncio e ignorância em resposta.
API de Backup de Fitas do Windows é necessário para trabalhar com bibliotecas ou drives de fita. Como mencionei no começo: escrever seus próprios drivers e depois se preocupar em dar suporte a cada dispositivo não é nada agradável. Portanto, a Veeam não possui drivers próprios. Tudo é feito através da API padrão, cujo suporte é fornecido pelos próprios fornecedores de hardware. Assim, faz mais sentido, não faz?
SMB/CIFS Todos costumam escrever isso lado a lado, embora não seja muito comum ninguém lembrar que CIFS (Common Internet File System) é apenas uma versão privada do SMB (Server Message Block). Portanto, não há nada de errado em generalizar esses conceitos. Samba, por outro lado, é a implementação do Linux/Unix, e possui suas peculiaridades, mas me desviei do assunto. O que é importante: quando a Veeam solicita gravar algo pelo caminho UNC (serverdirectory), o servidor utiliza a hierarquia de drivers do sistema de arquivos, incluindo mup e mrxsmb, para gravar no recurso compartilhado. Portanto, os erros serão gerados também por esses drivers.
De forma alguma pode-se prescindir de Winsock API. Se algo precisar ser feito pela rede, o VBR opera através da Windows Socket API, popularmente conhecida como Winsock. Portanto, se vemos no log a combinação IP:Port, é isso que é. A documentação oficial tem uma boa lista de possíveis .
A mencionada acima WMI (Windows Management Instrumentation) é uma API poderosa para gerenciar tudo e todos no mundo Windows. Por exemplo, ao trabalhar com Hyper-V, praticamente todas as solicitações ao host são feitas através dele. Em suma, é uma ferramenta indispensável e muito poderosa em suas capacidades. Nas tentativas de ajudar a descobrir onde e o que deu errado, a ferramenta embutida WBEMtest.exe é de grande ajuda.
E, por último na lista, mas absolutamente não menos importante — VSS (Volume Shadow Storage). O tema é tão inesgotável e misterioso quanto a quantidade de documentação que existe sobre ele. O Shadow Copy é mais fácil de entender como um tipo especial de snapshot, que na verdade é o que ele é. Graças a isso, no VMware é possível fazer backups consistentes de aplicações, enquanto no Hyper-V se pode fazer quase tudo. Tenho planos de escrever um artigo separado com um resumo sobre o VSS, mas por enquanto você pode tentar ler . Apenas tome cuidado, pois tentar entender o VSS de forma superficial pode levar a dores de cabeça.
Com isso, podemos parar por aqui. Considero que consegui explicar as questões mais básicas, então no próximo capítulo já iremos analisar os logs. Mas, se você tiver perguntas, não hesite em deixá-las nos comentários.
Fonte: habr.com
