Continuamos nuestra inmersión en el fascinante mundo de las adivinanzas... solución de problemas por logs. EN acordamos el significado de los términos básicos y observamos la estructura general de Veeam como una sola aplicación con un solo ojo. La tarea para este es descubrir cómo se forman los archivos de registro, qué tipo de información se muestra en ellos y por qué se ven de la manera que se ven.
¿Qué crees que son estos "registros"? Según la mayoría, a los registros de cualquier aplicación se les debe asignar el papel de una especie de entidad omnipotente que la mayor parte del tiempo vegeta en algún lugar del patio trasero, pero en el momento adecuado aparece de la nada con una armadura brillante y salva a todos. Es decir, deben contener todo, desde los más mínimos errores en cada componente hasta las transacciones individuales de la base de datos. Y para que después del error se escribiera de inmediato cómo solucionarlo. Y todo esto debería caber en un par de megas, no más. ¡Es solo texto! Los archivos de texto no pueden tomar decenas de gigabytes, ¡lo escuché en alguna parte!
Entonces los registros
En el mundo real, los registros son solo un archivo de información de diagnóstico. Y qué almacenar allí, dónde obtener información para el almacenamiento y qué tan detallada debe ser, depende de los propios desarrolladores decidir. Alguien sigue el camino del minimalismo manteniendo registros del nivel ON / OFF, y alguien rastrilla diligentemente todo lo que puede alcanzar. Aunque también hay una opción intermedia con la capacidad de seleccionar el llamado Nivel de registro, cuando usted mismo indica qué información detallada desea almacenar y cuánto espacio adicional en disco tiene =) VBR tiene seis niveles de este tipo, por cierto. Y, créeme, no querrás ver qué pasa con el registro más detallado con espacio libre en tu disco.
Bien. Entendemos aproximadamente lo que queremos guardar, pero surge una pregunta legítima: ¿de dónde obtener esta información? Por supuesto, formamos parte de los eventos para registrarnos por nuestros procesos internos. Pero, ¿qué hacer cuando hay una interacción con el medio externo? Para no caer en un infierno de muletas y bicicletas, Veeam tiende a no inventar inventos que ya han sido inventados. Siempre que haya una API preparada, una función integrada, una biblioteca, etc., daremos preferencia a las opciones preparadas antes de empezar a cercar nuestros artilugios. Aunque esto último también es suficiente. Por lo tanto, al analizar los registros, es importante comprender que la mayor parte de los errores recae en mensajes de API de terceros, llamadas al sistema y otras bibliotecas. En este caso, la función de VBR se reduce a reenviar estos errores a los archivos de registro tal cual. Y la tarea principal del usuario es aprender a comprender qué línea es de quién y de qué es responsable este "quién". Entonces, si un código de error del registro de VBR lo lleva a una página de MSDN, está bien y es correcto.
Como acordamos anteriormente: Veeam es una aplicación basada en SQL. Esto significa que todas las configuraciones, toda la información y, en general, todo lo que solo es necesario para el funcionamiento normal, todo se almacena en su base de datos. De ahí la simple verdad: lo que no está en los registros probablemente esté en la base de datos. Pero esto tampoco es una bala de plata: algunas cosas no están en los registros locales de los componentes de Veeam, ni en su base de datos. Por lo tanto, debe aprender a estudiar los registros del host, los registros de la máquina local y los registros de todo lo que está involucrado en el proceso de copia de seguridad y restauración. Y también sucede que la información necesaria no está disponible en ningún lado. Ese es el camino.
Algunos ejemplos de dichas API
Esta lista no pretende ser excepcionalmente completa, por lo que no es necesario buscar la verdad última en ella. Su propósito es solo mostrar las API y tecnologías de terceros más comunes que se utilizan en nuestros productos.
Comencemos con VMware.
El primero en la lista será API de vSphere. Se utiliza para autenticación, lectura de la jerarquía, creación y eliminación de instantáneas, solicitud de información sobre máquinas y mucho (mucho) más. La funcionalidad de la solución es muy amplia, por lo que puedo recomendar la referencia de la API de VMware vSphere para la versión и . Para versiones más actuales, todo se busca en Google.
API VIX. La magia negra del hipervisor, para la que existe un . API de VMware para trabajar con archivos en el host sin conectarse a ellos a través de la red. Una opción de último recurso cuando necesita colocar un archivo en una máquina para la que no hay un mejor canal de comunicación. Es dolor y sufrimiento si el archivo es grande y el host está cargado. Pero aquí funciona la regla de que incluso 56,6 Kb/s es mejor que 0 Kb/s. En Hyper-V, esto se llama PowerShell Direct. Pero eso fue solo antes
API de servicios web de vSphere A partir de vSphere 6.0 (aproximadamente, ya que esta API se introdujo por primera vez en la versión 5.5), se usa para trabajar con máquinas invitadas y ha suplantado a VIX en casi todas partes. De hecho, esta es otra API para administrar vSphere. Para aquellos que estén interesados, recomiendo estudiar. manual.
VDDK (Kit de desarrollo de disco virtual). La biblioteca, que se discutió parcialmente en este . Se utiliza para leer discos virtuales. Érase una vez que era parte del VIX, pero con el tiempo se trasladó a un producto separado. Pero como heredero, usa los mismos códigos de error que VIX. Pero por alguna razón, no hay una descripción de estos errores en el propio SDK. Por lo tanto, se descubrió empíricamente que los errores de VDDK con otros códigos son solo una traducción del código binario al decimal. Consta de dos partes: la primera mitad es información no documentada sobre el contexto, y la segunda parte son los errores tradicionales de VIX / VDDK. Por ejemplo, si vemos:
VDDK error: 21036749815809.Unknown error
Luego convertimos audazmente esto a hexadecimal y obtenemos 132200000001. Simplemente descartamos el comienzo no informativo de 132200, y el resto será nuestro código de error (VDDK 1: Error desconocido). Acerca de los errores VDDK más frecuentes, recientemente hubo un error separado .
Ahora veamos Ventanas.
Aquí, todo lo que es más necesario e importante para nosotros se puede encontrar en el estándar. Visor de sucesos. Pero hay un problema: según una larga tradición, Windows no registra el texto completo del error, sino solo su número. Por ejemplo, el error 5 es "Acceso denegado", el 1722 es "El servidor RPC no está disponible" y el 10060 es "Se agotó el tiempo de espera de la conexión". Por supuesto, es genial si recuerdas los más famosos, pero ¿qué pasa con los que no has visto hasta ahora?
Y para que la vida no te parezca para nada miel, los errores también se almacenan en forma hexadecimal, con el prefijo 0x8007. Por ejemplo, 0x8007000e es en realidad 14, sin memoria. Por qué y para quién se hizo esto es un misterio envuelto en la oscuridad. Sin embargo, se puede descargar una lista completa de errores de forma gratuita y sin SMS desde .
Por cierto, a veces hay otros prefijos, no solo 0x8007. En una situación tan triste, para comprender HRESULT ("manejador de resultados"), debe profundizar aún más en para desarrolladores. En la vida ordinaria, no te aconsejo que hagas esto, pero si de repente presionas contra la pared o simplemente tienes curiosidad, ahora sabes qué hacer.
Pero los compañeros de Microsoft se apiadaron un poco de nosotros y le mostraron al mundo una utilidad. . Esta es una pequeña pieza de la felicidad de la consola que puede traducir códigos de error en humanos sin 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"Surge una pregunta legítima: ¿por qué no escribimos inmediatamente el descifrado en los registros, sino que dejamos estos códigos misteriosos? La respuesta está en las aplicaciones de terceros. Cuando obtiene alguna llamada de WinAPI usted mismo, no es difícil descifrar su respuesta, porque incluso hay una llamada especial de WinAPI para esto. Pero como ya se mencionó, todo lo que solo nos llega en las respuestas se mete en nuestros registros. Y aquí, para descifrarlo, uno tendría que monitorear constantemente este flujo de conciencia, sacar piezas con errores de Windows, descifrarlos y pegarlos nuevamente. Seamos honestos, no es la actividad más emocionante.
API de administración de archivos de Windows utilizado en todas las formas posibles cuando se trabaja con archivos. Crear archivos, eliminar, abrir para escribir, trabajar con atributos, etc.
Mencionado anteriormente PowerShell directo como un análogo de la API VIX en el mundo Hyper-V. Desafortunadamente, no es tan flexible: muchas restricciones en la funcionalidad, no funciona con todas las versiones del host y no con todos los invitados.
RPC (Llamada a procedimiento remoto) No creo que haya una sola persona que haya trabajado con WIndows que no haya visto errores relacionados con RPC. A pesar del concepto erróneo popular, no se trata de un único protocolo, sino de cualquier protocolo cliente-servidor que satisfaga una serie de parámetros. Sin embargo, si hay un error de RPC en nuestros registros, el 90 % de las veces será un error de Microsoft RPC, que forma parte de DCOM (Modelo de objetos de componentes distribuidos). Puede encontrar una gran cantidad de documentación sobre este tema en la red, pero la mayor parte está bastante desactualizada. Pero si hay un gran deseo de estudiar el tema, puedo recomendar artículos. , y larga lista .
Las causas principales de los errores de RPC en nuestros registros son los intentos fallidos de comunicación entre los componentes de VBR (servidor > proxy, por ejemplo) y, en la mayoría de los casos, debido a problemas de comunicación.
El top top entre todos los tops es el error El servidor RPC no está disponible (1722). En términos simples, el cliente no pudo establecer una conexión con el servidor. Cómo y por qué: no hay una respuesta única, pero generalmente es un problema con la autenticación o con el acceso de red al puerto 135. Este último es típico de las infraestructuras con asignación dinámica de puertos. Sobre este tema, hay incluso . Y Microsoft tiene para encontrar la causa de la falla.
Segundo error más común: no hay más puntos finales disponibles en el asignador de puntos finales (1753). El cliente o servidor RPC no pudo asignarse un puerto. Por lo general, ocurre cuando el servidor (en nuestro caso, la máquina invitada) se ha configurado para asignar dinámicamente puertos de un rango estrecho que ha finalizado. Y si inicia sesión desde el lado del cliente (en nuestro caso, el servidor VBR), esto significa que nuestro VeeamVssAgent no se inició o no se registró como una interfaz RPC. También hay sobre este tema .
Bueno, para completar los 3 errores principales de RPC, recordemos que la llamada a la función RPC falló (1726). Aparece si se ha establecido la conexión, pero no se procesan las solicitudes RPC. Por ejemplo, solicitamos información sobre el estado de VSS (de repente en este momento se está haciendo una mina de sombra allí y estamos tratando de escalar), y en respuesta a nosotros, callar e ignorar.
API de copia de seguridad en cinta de Windows necesarios para trabajar con bibliotecas de cintas o unidades. Como mencioné al principio: no tenemos ningún placer en escribir nuestros propios controladores y luego sufrir con el soporte de cada dispositivo. Por lo tanto, vim no tiene controladores propios. Todo a través de una API estándar, cuyo soporte es implementado por los propios proveedores de hardware. Mucho más lógico, ¿verdad?
SMB / CIFS Por costumbre, todos los escriben uno al lado del otro, aunque no todos recuerdan que CIFS (Common Internet File System) es solo una versión privada de SMB (Server Message Block). Así que no hay nada de malo en generalizar estos conceptos. Samba ya es una implementación de LinuxUnix, y tiene sus propias peculiaridades, pero estoy divagando. Lo que es importante aquí: cuando Veeam solicita escribir algo en la ruta UNC (directorio del servidor), el servidor utiliza la jerarquía de los controladores del sistema de archivos, incluidos mup y mrxsmb, para escribir en la bola. En consecuencia, estos controladores también generarán errores.
no puedo prescindir API Winsock. Si es necesario hacer algo a través de la red, VBR funciona a través de la API de Windows Socket, conocida popularmente como Winsock. Entonces, si vemos un montón de IP: Puerto en el registro, esto es todo. La documentación oficial tiene una buena lista de posibles .
Mencionado anteriormente WMI (Instrumentación de administración de Windows) es una especie de API todopoderosa para administrar todo y a todos en el mundo de Windows. Por ejemplo, cuando se trabaja con Hyper-V, casi todas las solicitudes al host pasan por él. En una palabra, la cosa es absolutamente insustituible y muy poderosa en sus capacidades. En un intento por ayudar a descubrir dónde y qué está dañado, la herramienta integrada WBEMtest.exe ayuda mucho.
Y último en la lista, pero de ninguna manera menos importante: VSS (Almacenamiento de sombra de volumen). El tema es tan inagotable y misterioso cuanto más documentación se ha escrito sobre él. Shadow Copy se entiende más simplemente como un tipo especial de instantánea, que en esencia lo es. Gracias a él, puede realizar copias de seguridad coherentes con las aplicaciones en VMware y casi todo en Hyper-V. Tengo planes de hacer un artículo separado con algo de compresión en VSS, pero por ahora puedes intentar leer . Solo ten cuidado, porque. tratar de entender VSS en un instante puede provocar una lesión cerebral.
En esto, tal vez, podamos detenernos. Doy por finalizada la tarea de explicar las cosas más básicas, por lo que en el próximo capítulo ya veremos los logs. Pero si tienes alguna pregunta, no dudes en hacerla en los comentarios.
Fuente: habr.com