Continuamos a nosa inmersión no fascinante mundo das adiviñas... resolución de problemas mediante rexistros. EN acordamos o significado dos termos básicos e analizamos a estrutura xeral de Veeam como unha única aplicación cun só ollo. A tarefa deste é descubrir como se forman os ficheiros de rexistro, que tipo de información se mostra neles e por que teñen o seu aspecto.
Que cres que son estes "rexistros"? Segundo a maioría, os rexistros de calquera aplicación deberían ter o papel dunha especie de entidade omnipotente que a maioría das veces vexeta nalgún lugar do xardín traseiro, pero no momento adecuado aparece da nada nunha armadura brillante e salva a todos. É dicir, deberían conter de todo, dende os máis mínimos erros en cada compoñente ata transaccións individuais de bases de datos. E para que despois do erro inmediatamente se escribise como solucionalo. E todo isto debería caber nun par de megabytes, sen máis. É só texto! Os ficheiros de texto non poden levar decenas de gigabytes, escoiteino nalgún sitio!
Entón os rexistros
No mundo real, os rexistros son só un arquivo de información de diagnóstico. E o que hai que almacenar alí, onde obter información para o almacenamento e o detalle que debe ser, depende dos propios desenvolvedores. Alguén segue o camiño do minimalismo mantendo rexistros do nivel ON / OFF e alguén rastrexa con dilixencia todo o que pode alcanzar. Aínda que tamén hai unha opción intermedia coa posibilidade de seleccionar o chamado Nivel de rexistro, cando vostede mesmo indica a información detallada que quere almacenar e canto espazo extra en disco ten =) VBR ten seis niveis deste tipo, por certo. E, créame, non quere ver que pasa co rexistro máis detallado con espazo libre no seu disco.
Ben. Entendemos aproximadamente o que queremos gardar, pero xorde unha pregunta lexítima: de onde conseguir esta información? Por suposto, formamos parte dos eventos para rexistrarnos nos nosos procesos internos. Pero que facer cando hai unha interacción co medio externo? Para non caer nun inferno de muletas e bicicletas, Veeam adoita non inventar inventos que xa foron inventados. Sempre que haxa unha API preparada, unha función integrada, unha biblioteca, etc., daremos preferencia ás opcións preparadas antes de comezar a cercar os nosos artefactos. Aínda que isto último tamén é suficiente. Polo tanto, ao analizar os rexistros, é importante entender que a maior parte dos erros recae nas mensaxes de API de terceiros, chamadas de sistema e outras bibliotecas. Neste caso, o papel de VBR redúcese a reenviar estes erros aos ficheiros de rexistro. E a principal tarefa do usuario é aprender a comprender que liña é de quen e de que é responsable este "quen". Polo tanto, se un código de erro do rexistro de VBR o leva a unha páxina de MSDN, é correcto.
Como acordamos anteriormente: Veeam é unha chamada aplicación baseada en SQL. Isto significa que todas as configuracións, toda a información e, en xeral, todo o que só é necesario para o funcionamento normal: todo está almacenado na súa base de datos. De aí a simple verdade: o que non está nos rexistros está moi probablemente na base de datos. Pero isto tampouco é unha bala de prata: algunhas cousas non están nos rexistros locais dos compoñentes de Veeam, nin na súa base de datos. Polo tanto, cómpre aprender a estudar os rexistros do host, os rexistros da máquina local e os rexistros de todo o que está implicado no proceso de copia de seguridade e restauración. E tamén ocorre que a información necesaria non está dispoñible en ningún lado. Ese é o camiño.
Algúns exemplos de tales API
Esta lista non pretende ser excepcionalmente completa, polo que non hai que buscar nela a verdade definitiva. O seu propósito é só mostrar as tecnoloxías e API de terceiros máis comúns que se usan nos nosos produtos.
Empecemos VMware.
O primeiro da lista será API de vSphere. Úsase para a autenticación, ler a xerarquía, crear e eliminar instantáneas, solicitar información sobre máquinas e moito (moito) máis. A funcionalidade da solución é moi ampla, polo que podo recomendar a VMware vSphere API Reference para a versión и . Para versións máis actuais, todo está en Google.
API VIX. A maxia negra do hipervisor, para o que hai un separado . API de VMware para traballar con ficheiros no host sen conectarse a eles pola rede. Unha opción de último recurso cando necesitas poñer un ficheiro nunha máquina á que non hai mellor canle de comunicación. É dor e sufrimento se o ficheiro é grande e o host está cargado. Pero aquí funciona a regra de que incluso 56,6 Kb/s é mellor que 0 Kb/s. En Hyper-V, esta cousa chámase PowerShell Direct. Pero iso só era antes
API de servizos web de vSpehere A partir de vSphere 6.0 (aproximadamente, xa que esta API se introduciu por primeira vez na versión 5.5) úsase para traballar con máquinas convidadas e suplantou a VIX en case todas partes. De feito, esta é outra API para xestionar vSphere. Para os que estean interesados, recoméndolles estudar manual.
VDDK (Kit de desenvolvemento de discos virtuais). A biblioteca, que se tratou parcialmente neste . Úsase para ler discos virtuais. Érase unha vez que formaba parte do VIX, pero co paso do tempo pasou a ser un produto separado. Pero como herdeiro, usa os mesmos códigos de erro que VIX. Pero por algún motivo, non hai ningunha descrición destes erros no propio SDK. Polo tanto, descubriuse empíricamente que os erros VDDK con outros códigos son só unha tradución de código binario a decimal. Consta de dúas partes: a primeira metade é información non documentada sobre o contexto e a segunda parte son os erros tradicionais VIX / VDDK. Por exemplo, se vemos:
VDDK error: 21036749815809.Unknown error
Despois convertemos isto a hexadecimal e obtemos 132200000001. Simplemente descartamos o inicio non informativo de 132200, e o resto será o noso código de erro (VDDK 1: Erro descoñecido). Sobre os erros VDDK máis frecuentes, recentemente houbo un separado .
Agora vexámolo Fiestras.
Aquí, todo o que é máis necesario e importante para nós pódese atopar na norma Visor de eventos. Pero hai un problema: segundo unha longa tradición, Windows non rexistra o texto completo do erro, senón só o seu número. Por exemplo, o erro 5 é "Acceso denegado" e 1722 é "O servidor RPC non está dispoñible" e 10060 é "A conexión esgotou o tempo de espera". Por suposto, é xenial se lembras os máis famosos, pero que hai dos que ata agora non se viron?
E para que a vida non pareza nada de mel, os erros tamén se almacenan en forma hexadecimal, co prefixo 0x8007. Por exemplo, 0x8007000e é en realidade 14, sen memoria. Por que e para quen se fixo isto é un misterio envolto na escuridade. Non obstante, pódese descargar unha lista completa de erros de balde e sen SMS desde .
Por certo, ás veces hai outros prefixos, non só 0x8007. Nunha situación tan triste, para comprender HRESULT ("manso de resultado"), cómpre afondar aínda máis en para desenvolvedores. Na vida normal, non che aconsello que fagas isto, pero se de súpeto presionaches contra a parede ou só tes curiosidade, agora xa sabes que facer.
Pero os compañeiros de Microsoft apiadáronse un pouco de nós e mostráronlle ao mundo unha utilidade . Esta é unha pequena peza de felicidade da consola que pode traducir códigos de erro en humanos sen usar Google. Funciona así.
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"Xorde unha pregunta lexítima: por que non escribimos inmediatamente o descifrado nos rexistros, pero deixamos estes códigos misteriosos? A resposta está en aplicacións de terceiros. Cando tiras algunha chamada WinAPI, non é difícil descifrar a súa resposta, porque ata hai unha chamada WinAPI especial para iso. Pero como xa se mencionou, todo o que só nos chega nas respostas entra nos nosos rexistros. E aquí, para descifralo, habería que supervisar constantemente este fluxo de conciencia, sacar pezas con erros de Windows, descifralas e pegalas de novo. Sexamos sinceros, non é a actividade máis emocionante.
API de xestión de ficheiros de Windows usado de todas as formas posibles cando se traballa con ficheiros. Crear ficheiros, eliminar, abrir para escribir, traballar con atributos, etc., etc.
mencionado anteriormente PowerShell directo como un análogo da API VIX no mundo Hyper-V. Desafortunadamente, non é tan flexible: moitas restricións sobre a funcionalidade, non funciona con todas as versións do host e non con todos os convidados.
CPR (Chamada de procedemento remoto) Non creo que haxa unha soa persoa que teña traballado con WIndows que non teña visto erros relacionados co RPC. A pesar do equívoco popular, este non é un protocolo único, senón calquera protocolo cliente-servidor que satisfaga unha serie de parámetros. Non obstante, se hai un erro RPC nos nosos rexistros, o 90% das veces será un erro de Microsoft RPC, que forma parte do DCOM (Distributed Component Object Model). Podes atopar unha gran cantidade de documentación sobre este tema na rede, pero a parte do león está bastante desfasada. Pero se hai un desexo agudo de estudar o tema, entón podo recomendar artigos , e longa lista .
As principais causas dos erros de RPC nos nosos rexistros son os intentos errados de comunicarse entre compoñentes de VBR (servidor > proxy, por exemplo) e a maioría das veces debido a problemas de comunicación.
O primeiro lugar entre todos os primeiros é o erro O servidor RPC non está dispoñible (1722). En termos sinxelos, o cliente non puido establecer unha conexión co servidor. Como e por que - non hai unha única resposta, pero normalmente é un problema coa autenticación ou co acceso á rede ao porto 135. Este último é típico para infraestruturas con asignación dinámica de portos. Neste tema, hai incluso . E Microsoft ten para atopar a causa do fallo.
Segundo erro máis popular: non hai máis puntos finais dispoñibles no mapa de puntos finais (1753). O cliente ou servidor RPC non puido asignarse un porto. Adoita ocorrer cando o servidor (no noso caso, a máquina convidada) foi configurado para asignar de forma dinámica portos dun intervalo estreito que rematou. E se inicias sesión desde o lado do cliente (no noso caso, o servidor VBR), isto significa que o noso VeeamVssAgent non se iniciou ou non se rexistrou como interface RPC. Tamén hai sobre este tema .
Ben, para completar os 3 principais erros de RPC, lembremos que fallou a chamada da función RPC (1726). Aparece se a conexión se estableceu, pero as solicitudes RPC non se procesan. Por exemplo, solicitamos información sobre o estado do VSS (de súpeto agora mesmo estase facendo alí unha mina de sombra, e estamos tentando subir), e en resposta a nós, silenciar e ignorar.
Windows Tape Backup API necesario para traballar con bibliotecas de cintas ou unidades. Como comentei ao principio: non temos pracer en escribir os nosos propios controladores e despois sufrir co apoio de cada dispositivo. Polo tanto, vim non ten controladores propios. Todo a través dunha API estándar, cuxo soporte é implementado polos propios provedores de hardware. Moito máis lóxico, non?
SMB / CIFS Por costume, todos os escriben un ao carón, aínda que non todos lembran que CIFS (Common Internet File System) é só unha versión privada de SMB (Server Message Block). Polo tanto, non hai nada de malo en xeneralizar estes conceptos. Samba xa é unha implementación de LinuxUnix, e ten as súas propias peculiaridades, pero divago. O que é importante aquí: cando Veeam pide escribir algo na ruta UNC (directorio do servidor), o servidor usa a xerarquía de controladores do sistema de ficheiros, incluíndo mup e mrxsmb, para escribir no balón. En consecuencia, estes controladores tamén xerarán erros.
Non se pode prescindir Winsock API. Se hai que facer algo a través da rede, VBR funciona a través da API de Windows Socket, coñecida popularmente como Winsock. Entón, se vemos un montón de IP:Port no rexistro, isto é. A documentación oficial ten unha boa lista de posibles .
mencionado anteriormente WMI (Windows Management Instrumentation) é unha especie de API todopoderoso para xestionar todo e todos no mundo de Windows. Por exemplo, cando se traballa con Hyper-V, case todas as solicitudes ao host pasan por el. Nunha palabra, a cousa é absolutamente insubstituíble e moi poderosa nas súas capacidades. Nun intento de axudar a descubrir onde e que está roto, a ferramenta WBEMtest.exe integrada axuda moito.
E o último da lista, pero non menos importante en importancia - VSS (Almacenamento de sombras de volume). O tema é tan inesgotable e misterioso como se ten escrito sobre el tanta documentación. A Shadow Copy enténdese simplemente como un tipo especial de instantánea, que en esencia é. Grazas a el, podes facer copias de seguridade coherentes coas aplicacións en VMware e case todo en Hyper-V. Teño plans para facer un artigo separado con un pouco de aperta sobre VSS, pero de momento podes tentar ler . Só ten coidado, porque. tentar comprender a VSS nun flash pode levar a dano cerebral.
Nisto, quizais, podemos parar. Considero rematada a tarefa de explicar as cousas máis básicas, polo que no próximo capítulo xa veremos os rexistros. Pero se tes algunha dúbida, non dubides en preguntalas nos comentarios.
Fonte: www.habr.com