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 eventosPero hai unha pega: segundo unha antiga tradición Windows Non rexistra o texto completo do erro, senón só o seu número. Por exemplo, o erro 5 significa "Acceso denegado", 1722 significa "O servidor RPC non está dispoñible" e 10060 significa "Tempo de espera da conexión esgotado". Por suposto, é xenial se lembras os máis comúns, pero que pasa cos que nunca viches antes?
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.
Windows API de xestión de ficheiros 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 API de copia de seguridade en cinta 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 Todo o mundo os escribe xuntos por costume, aínda que non todo o mundo lembra que CIFS (Common Internet File System) é simplemente unha versión propietaria de SMB (Server Message Block). Polo tanto, non hai nada de malo en xeneralizar estes conceptos. Samba, pola contra, é LinuxÉ unha implementación de Unix e ten as súas propias peculiaridades, pero divago. O importante aquí é que cando Veeam solicita escribir algo nunha ruta UNC (directorio do servidor), o servidor usa unha xerarquía de controladores do sistema de ficheiros, incluíndo mup e mrxsmb, para escribir na unidade compartida. En consecuencia, estes controladores tamén xerarán erros.
Non se pode prescindir Winsock APISe cómpre facer algo a través da rede, VBR funciona a través de Windows API de Socket, coñecida comunmente como Winsock. Entón, se vemos unha conexión IP:Port no rexistro, iso é todo. A documentación oficial ten unha boa lista de posibles .
mencionado anteriormente WMI (Windows A Instrumentación de Xestión é unha especie de API todopoderosa para xestionar todo e a todos no mundo. WindowsPor exemplo, ao traballar con Hyper-V, case todas as solicitudes ao host procésanse a través del. En resumo, é absolutamente indispensable e moi potente. A ferramenta WBEMtest.exe integrada é moi útil para tentar descubrir que está roto.
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
