Continuamos nossa imersão no fascinante mundo da adivinhação ... solução de problemas por logs. EM concordamos com o significado dos termos básicos e analisamos a estrutura geral da Veeam como um único aplicativo com um olho. A tarefa para este é descobrir como os arquivos de log são formados, que tipo de informação é exibida neles e por que eles têm a aparência que têm.
O que você acha que são esses "logs"? Segundo a maioria, os logs de qualquer aplicativo devem receber o papel de uma espécie de entidade onipotente que na maioria das vezes vegeta em algum lugar do quintal, mas no momento certo aparece do nada em uma armadura brilhante e salva a todos. Ou seja, devem conter tudo, desde os menores erros em cada componente até as transações individuais do banco de dados. E para que, após o erro, fosse imediatamente escrito como corrigi-lo. E tudo isso deve caber em alguns megabytes, não mais. É só texto! Arquivos de texto não podem levar dezenas de gigabytes, ouvi isso em algum lugar!
Então os registros
No mundo real, os logs são apenas um arquivo de informações de diagnóstico. E o que armazenar lá, onde obter informações para armazenamento e quão detalhado deve ser, cabe aos próprios desenvolvedores decidir. Alguém segue o caminho do minimalismo, mantendo registros do nível ON / OFF, e alguém recolhe diligentemente tudo o que pode alcançar. Embora também exista uma opção intermediária com a capacidade de selecionar o chamado Logging Level, quando você mesmo indica quantas informações detalhadas deseja armazenar e quanto espaço extra em disco você tem =) VBR tem seis desses níveis, a propósito. E, acredite, você não quer ver o que acontece com o registro mais detalhado com espaço livre em seu disco.
Multar. Entendemos aproximadamente o que queremos salvar, mas surge uma pergunta legítima: de onde obter essas informações? Claro, fazemos parte dos eventos para nos registrarmos por meio de nossos processos internos. Mas o que fazer quando há uma interação com o meio externo? Para não cair em um inferno de muletas e bicicletas, a Veeam tende a não inventar invenções que já foram inventadas. Sempre que houver uma API pronta, função integrada, biblioteca etc., daremos preferência às opções prontas antes de começar a cercar nossas engenhocas. Embora o último também seja suficiente. Portanto, ao analisar logs, é importante entender que a maior parte dos erros recai sobre mensagens de APIs de terceiros, chamadas de sistema e outras bibliotecas. Nesse caso, o papel do VBR se resume a 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 pelo que esse “quem” é responsável. Portanto, se um código de erro do log VBR levar você a uma página do MSDN, tudo bem e correto.
Como concordamos anteriormente: Veeam é um aplicativo baseado em SQL. Isso significa que todas as configurações, todas as informações e, em geral, tudo o que é necessário apenas para o funcionamento normal - tudo é armazenado em seu banco de dados. Daí a simples verdade: o que não está nos logs provavelmente está no banco de dados. Mas isso também não é uma bala de prata: algumas coisas não estão nos logs locais dos componentes da Veeam, nem em seu banco de dados. Portanto, você precisa aprender a estudar os logs do host, os logs da máquina local e os logs de tudo que está envolvido no processo de backup e restauração. E também acontece que as informações necessárias não estão disponíveis em nenhum lugar. Esse é o caminho.
Alguns exemplos dessas APIs
Esta lista não pretende ser excepcionalmente completa, portanto não há necessidade de procurar nela a verdade última. Seu objetivo é apenas mostrar as APIs e tecnologias de terceiros mais comuns usadas em nossos produtos.
Vamos começar com VMware.
O primeiro da lista será API vSphere. Usado para autenticação, leitura da hierarquia, criação e exclusão de instantâneos, solicitação de informações sobre máquinas e muito (muito) mais. A funcionalidade da solução é muito ampla, então posso recomendar o VMware vSphere API Reference para a versão и . Para versões mais atuais, tudo é apenas pesquisado no Google.
API VIX. A magia negra do hipervisor, para a qual existe um . API VMware para trabalhar com arquivos no host sem se conectar a eles pela rede. Uma opção de último recurso quando você precisa colocar um arquivo em uma máquina para a qual não há melhor canal de comunicação. É doloroso se o arquivo for grande e o host estiver carregado. Mas aqui funciona a regra de que mesmo 56,6 Kb / s é melhor que 0 Kb / s. No Hyper-V, essa coisa é chamada de PowerShell Direct. Mas isso foi só antes
API de serviços da Web do vSphere A partir do vSphere 6.0 (aproximadamente, desde que esta API foi introduzida pela primeira vez na versão 5.5), ela é usada para trabalhar com máquinas convidadas e suplantou o VIX em quase todos os lugares. Na verdade, essa é outra API para gerenciar o vSphere. Aos interessados, recomendo estudar manual.
VDDK (Kit de desenvolvimento de disco virtual). A biblioteca, que foi parcialmente discutida neste . Usado para ler discos virtuais. Era uma vez parte do VIX, mas com o tempo foi movido para um produto separado. Mas como herdeiro, ele usa os mesmos códigos de erro do VIX. Mas, por algum motivo, não há descrição desses erros no próprio SDK. Portanto, descobriu-se empiricamente que os erros de VDDK com outros códigos são apenas uma tradução do código binário para o decimal. Consiste em duas partes - a primeira metade são informações não documentadas sobre o contexto e a segunda parte são os erros VIX / VDDK tradicionais. Por exemplo, se vemos:
VDDK error: 21036749815809.Unknown error
Em seguida, convertemos isso em hexadecimal e obtemos 132200000001. Simplesmente descartamos o início não informativo de 132200 e o restante será nosso código de erro (VDDK 1: erro desconhecido). Sobre os erros de VDDK mais frequentes, recentemente houve um separado .
Agora vamos olhar para Janelas.
Aqui, tudo o que é mais necessário e importante para nós pode ser encontrado no padrão Visualizador de eventos. Mas há um problema: de acordo com uma longa tradição, o Windows não registra o texto completo do erro, mas apenas seu número. Por exemplo, o erro 5 é “Acesso negado” e 1722 é “O servidor RPC não está disponível” e 10060 é “Tempo limite da conexão esgotado”. Claro, é ótimo se você se lembrar dos mais famosos, mas e os inéditos?
E para que a vida não pareça mel, os erros também são armazenados em forma hexadecimal, com o prefixo 0x8007. Por exemplo, 0x8007000e é na verdade 14, memória insuficiente. Por que e para quem isso foi feito é um mistério envolto em trevas. No entanto, uma lista completa de erros pode ser baixada gratuitamente e sem SMS de .
A propósito, às vezes existem outros prefixos, não apenas 0x8007. Em uma situação tão triste, para entender o HRESULT (“manipulação do resultado”), você precisa se aprofundar ainda mais no para desenvolvedores. Na vida cotidiana, não aconselho você a fazer isso, mas se de repente você se pressionou contra a parede ou está apenas curioso, agora sabe o que fazer.
Mas os camaradas da Microsoft tiveram um pouco de pena de nós e mostraram ao mundo um utilitário . Este é um pequeno pedaço de felicidade do console que pode traduzir códigos de erro em humanos sem usar o Google. Funciona assim.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Surge uma pergunta legítima: por que não escrevemos imediatamente a descriptografia nos logs, mas deixamos esses códigos misteriosos? A resposta está em aplicativos de terceiros. Quando você mesmo puxa alguma chamada WinAPI, não é difícil decifrar sua resposta, porque existe até uma chamada WinAPI especial para isso. Mas, como já mencionado, tudo o que só chega até nós em respostas entra em nossos logs. E aqui, para descriptografá-lo, seria necessário monitorar constantemente esse fluxo de consciência, extrair dele os pedaços com erros do Windows, descriptografá-los e colá-los de volta. Sejamos honestos, não é a atividade mais emocionante.
API de gerenciamento de arquivos do Windows usado de todas as maneiras possíveis ao trabalhar com arquivos. Criar arquivos, excluir, abrir para gravação, trabalhar com atributos e assim por diante.
Mencionado acima PowerShell direto como um análogo da API VIX no mundo Hyper-V. Infelizmente, não é tão flexível: muitas restrições de funcionalidade, não funciona com todas as versões do host e nem com todos os convidados.
RPC (Chamada de Procedimento Remoto) Acho que não existe uma única pessoa que tenha trabalhado com o Windows que não tenha visto erros relacionados a RPC. Apesar do equívoco popular, este não é um protocolo único, mas qualquer protocolo cliente-servidor que satisfaça vários parâmetros. No entanto, se houver um erro de RPC em nossos logs, 90% das vezes será um erro do Microsoft RPC, que faz parte do DCOM (Distributed Component Object Model). Você pode encontrar uma grande quantidade de documentação sobre esse tópico na rede, mas a maior parte dela está bastante desatualizada. Mas se houver um desejo agudo de estudar o assunto, posso recomendar artigos , e longa lista .
As principais causas de erros de RPC em nossos logs são tentativas falhadas de comunicação entre componentes VBR (servidor > proxy, por exemplo) e, na maioria das vezes, devido a problemas de comunicação.
O top top entre todos os tops é o erro O servidor RPC não está disponível (1722). Em termos simples, o cliente não conseguiu estabelecer uma conexão com o servidor. Como e porquê - não existe uma resposta única, mas normalmente é um problema de autenticação ou de acesso à rede à porta 135. Este último é típico de infraestruturas com atribuição dinâmica de portas. Sobre este tema, há ainda . E a Microsoft tem para encontrar a causa da falha.
Segundo erro mais comum: Não há mais pontos de extremidade disponíveis no mapeador de pontos de extremidade (1753). O cliente ou servidor RPC falhou ao atribuir a si mesmo uma porta. Geralmente ocorre quando o servidor (no nosso caso, a máquina convidada) foi configurado para alocar portas dinamicamente de um intervalo estreito que terminou. E se você fizer login do lado do cliente (no nosso caso, o servidor VBR), isso significa que nosso VeeamVssAgent não foi iniciado ou não foi registrado como uma interface RPC. Há também neste tópico .
Bem, para concluir os 3 principais erros de RPC, vamos lembrar que a chamada de função RPC falhou (1726). Aparece se a conexão foi estabelecida, mas as solicitações RPC não são processadas. Por exemplo, solicitamos informações sobre o status do VSS (de repente, agora mesmo, uma mina de sombra está sendo feita lá e estamos tentando escalar) e, em resposta a nós, silenciamos e ignoramos.
API de backup em fita do Windows necessários para trabalhar com bibliotecas de fitas ou unidades. Como mencionei no início: não temos prazer em escrever nossos próprios drivers e depois sofrer com o suporte de cada dispositivo. Portanto, o vim não possui drivers próprios. Tudo por meio de uma API padrão, cujo suporte é implementado pelos próprios fornecedores de hardware. Muito mais lógico, certo?
SMB / CIFS Por hábito, todos os escrevem lado a lado, embora nem todos se lembrem de que o 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. O Samba já é uma implementação do LinuxUnix e tem suas próprias peculiaridades, mas estou divagando. O que é importante aqui: quando a Veeam pede para gravar algo no caminho UNC (serverdirectory), o servidor usa a hierarquia de drivers do sistema de arquivos, incluindo mup e mrxsmb, para gravar na bola. Conseqüentemente, esses drivers também gerarão erros.
Não posso fazer sem API do Winsock. Se algo precisa ser feito pela rede, o VBR funciona por meio da API Windows Socket, popularmente conhecida como Winsock. Então, se vemos um monte de IP:Port no log, é isso. A documentação oficial tem uma boa lista de possíveis .
Mencionado acima WMI (Windows Management Instrumentation) é uma espécie de API poderosa para gerenciar tudo e todos no mundo do Windows. Por exemplo, ao trabalhar com o Hyper-V, quase todas as solicitações ao host passam por ele. Em uma palavra, a coisa é absolutamente insubstituível e muito poderosa em suas capacidades. Na tentativa de ajudar a descobrir onde e o que está quebrado, a ferramenta WBEMtest.exe integrada ajuda muito.
E o último da lista, mas não menos importante - VSS (Armazenamento Sombra de Volume). O tópico é tão inesgotável e misterioso quanto muita documentação foi escrita sobre ele. A cópia de sombra é mais simplesmente entendida como um tipo especial de instantâneo, o que em essência é. Graças a ele, você pode fazer backups consistentes com aplicativos no VMware e quase tudo no Hyper-V. Tenho planos de fazer um artigo separado com algum aperto no VSS, mas por enquanto você pode tentar ler . Apenas tome cuidado, porque. tentar entender o VSS rapidamente pode levar a lesões cerebrais.
Sobre isso, talvez, possamos parar. Considero a tarefa de explicar as coisas mais básicas concluída, então no próximo capítulo já veremos os logs. Mas se você tiver alguma dúvida, sinta-se à vontade para perguntar nos comentários.
Fonte: habr.com