Continuamos nuestra inmersión en el fascinante mundo del troubleshooting a través de los logs. En hemos acordado el significado de los términos básicos y hemos echado un vistazo a la estructura general de Veeam como una aplicación única. La tarea ahora es entender cómo se generan los archivos de logs, qué información contienen y por qué se ven como se ven.
¿Qué piensan ustedes, qué son en realidad esos "logs"? La mayoría considera que los logs de cualquier aplicación deben desempeñar el papel de una entidad todopoderosa que pasa la mayor parte del tiempo en un segundo plano, pero que en el momento adecuado aparece de la nada con una armadura brillante y salva el día. Es decir, se espera que contengan todo, desde los errores más pequeños en cada componente, hasta transacciones individuales de la base de datos. Y que, después de un error, se escriba inmediatamente cómo corregirlo. Y todo esto debería caber en un par de megabytes, como máximo. ¡Es solo texto! ¡No puede ser que los archivos de texto ocupen decenas de gigabytes, yo he escuchado eso en alguna parte!
Así que, los logs
en el mundo real son simplemente un archivo de información diagnóstica. Y qué almacenar, de dónde obtener la información para el almacenamiento y cuán detallada debe ser, lo deciden los propios desarrolladores. Algunos optan por el camino del minimalismo, manteniendo registros de encendido/apagado, mientras que otros recopilan todo lo que pueden alcanzar. Aunque también existe una opción intermedia con la posibilidad de elegir el llamado nivel de registro, donde tú mismo indicas cuán detallada quieres que sea la información que almacenas y cuánto espacio adicional tienes en tus discos. Por cierto, VBR tiene seis de esos niveles. Y créanme, ustedes no quieren ver lo que sucede cuando se registra con el nivel más detallado y tienen poco espacio libre en su disco.
Bien. Hemos entendido aproximadamente qué queremos mantener, pero surge la pregunta legítima: ¿de dónde obtener esta información? Parte de los eventos para el registro, por supuesto, los generamos nosotros mismos a través de nuestros procesos internos. Pero, ¿qué hacer cuando ocurre una interacción con el entorno externo? Para no caer en un caos de soluciones improvisadas, Veeam tiende a no reinventar lo que ya ha sido inventado. Siempre que haya una API disponible, una función integrada en el sistema, una biblioteca, etc., priorizaremos las soluciones existentes antes de comenzar a desarrollar nuestras propias soluciones ingeniosas. Aunque estas últimas también son numerosas. Por lo tanto, al analizar los registros, es importante comprender que la mayor parte de los errores proviene de los mensajes de APIs externas, llamadas del sistema y otras bibliotecas. En este caso, el papel de VBR se reduce a reenviar estos errores a los archivos de registro tal como están. Y la principal tarea del usuario es aprender a entender qué línea corresponde a quién, y por qué ese 'quién' es responsable. Por lo tanto, si el código de error del registro de VBR te lleva a una página de MSDN, eso es normal y correcto.
Como acordamos anteriormente: Veeam es una aplicación SQL-based. Eso significa que todas las configuraciones, toda la información y, en general, todo lo que se necesita para un funcionamiento normal, se almacena en su base de datos. De aquí surge una verdad simple: lo que no está en los registros, probablemente esté en la base. Pero esto no es una respuesta definitiva: algunas cosas no se encuentran ni en los registros locales de los componentes de Veeam, ni en su base de datos. Por lo tanto, es necesario aprender a estudiar los registros del host, los registros de la máquina local y los registros en general de todo lo que participa en el proceso de respaldo y restauración. A veces sucede que la información que se necesita no está en ningún lugar. Así es el camino.
Algunos ejemplos de tales APIs
Esta lista no tiene como objetivo ser exhaustiva, así que no busques la verdad en ella como si fuera la última instancia. Su tarea es simplemente mostrar las APIs y tecnologías externas más comunes utilizadas en nuestros productos.
Comencemos con VMware.
El primero en la lista será vSphere API. Se utiliza para la 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 a todos los interesados les recomiendo consultar el VMware vSphere API Reference para la versión y . Las versiones más actuales se pueden buscar fácilmente en Google.
VIX API. La magia negra del hipervisor, para la que hay una lista de errores separada vSphere Web Services API
. Desde vSphere 6.0 (aproximadamente, ya que este API fue introducido por primera vez en la versión 5.5) se usa para trabajar con máquinas invitadas y ha reemplazado prácticamente a VIX en todas partes. En esencia, es otra API para gestionar vSphere. Para quienes estén interesados, recomiendo estudiar un excelente VDDK
(Virtual Disk Development Kit). Una biblioteca de la que se habló parcialmente en este . Se utiliza para leer discos virtuales. Hace tiempo, era parte de VIX, pero con el tiempo se separó en un producto independiente. Sin embargo, debido a su herencia, utiliza los mismos códigos de error que VIX. Pero por alguna razón, en el mismo SDK no hay descripción de estos errores. Por ello, mediante la experiencia se ha averiguado que los errores de VDDK con otros códigos son simplemente una traducción de binario a decimal. Consiste en dos partes: la primera mitad representa información no documentada sobre el contexto, y la segunda parte son los tradicionales errores de VIX/VDDK. Por ejemplo, si vemos: Error VDDK: 21036749815809.Error desconocido
Podemos convertir esto a hex y obtenemos 132200000001. La parte poco informativa 132200 simplemente la ignoramos, y el resto será nuestro código de error (VDDK 1: Error desconocido). Recientemente, hubo un artículo separado sobre los errores más comunes de VDDK
. Ahora echemos un vistazo a .
. Aquí se puede encontrar toda la información necesaria y relevante en el Visor de Eventos.
. Pero hay un inconveniente: por una antigua tradición, Windows no registra el texto completo del error, 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 'Conexión agotada'. Claro que está bien si recuerdas los más conocidos, pero ¿qué hacer con los errores nunca antes vistos? Visor de Eventos. Pero hay un pequeño inconveniente: por una antigua tradición, Windows no registra el texto completo del error, 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 “Conexión agotada”. Por supuesto, es genial si recuerdas los más conocidos, pero ¿qué hacer con los que nunca antes habías visto?
Y para que la vida no parezca tan dulce, los errores también se almacenan en forma hexadecimal, con el prefijo 0x8007. Por ejemplo, 0x8007000e en realidad es 14, Memoria insuficiente. Por qué y para quién se hizo así es un misterio cubierto de oscuridad. Sin embargo, puedes descargar gratis y sin SMS la lista completa de errores desde .
Por cierto, a veces también aparecen otros prefijos, no solo 0x8007. En esta triste situación, para entender el HRESULT (“handle de resultado”), es necesario profundizar aún más en para desarrolladores. En la vida normal, no te recomendaría hacer tal cosa, pero si de repente te ves acorralado o simplemente tienes curiosidad, ahora sabes qué hacer.
Pero los amigos en Microsoft se compadecieron un poco de nosotros y presentaron al mundo la herramienta . Este es un pequeño pedazo de felicidad de consola que puede traducir códigos de error a un lenguaje comprensible sin necesidad de usar Google. Funciona más o menos así.
C:UsersrootDesktop>err.exe 0x54f
# para hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Se produjo un error interno.
# como HRESULT: Severidad: ÉXITO (0), FACILIDAD_NULA (0x0), Código 0x54f
# para hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Se produjo un error interno.
# Se encontraron 2 coincidencias para "0x54f"Surge una pregunta legítima: ¿por qué no escribimos de inmediato la descripción en los registros y dejamos estos códigos misteriosos? La respuesta está en aplicaciones externas. Cuando tú mismo haces una llamada a alguna API de WinAPI, descifrar su respuesta no es complicado, porque incluso hay una llamada especial de WinAPI para eso. Pero como ya se mencionó, en nuestros registros entra todo lo que llega en nuestras respuestas. Y aquí, para descifrar, tendrías que monitorear constantemente este flujo de conciencia, extraer trozos con errores de Windows, descifrarlos e insertarlos de nuevo. Seamos sinceros, no es la actividad más emocionante.
API de Gestión de Archivos de Windows se utiliza para trabajar con archivos. Crear archivos, eliminar, abrir para escritura, trabajar con atributos y demás.
El mencionado anteriormente PowerShell Direct como un análogo de la API VIX en el mundo de Hyper-V. Desafortunadamente, no es tan flexible: tiene muchas limitaciones en funcionalidad, no funciona con cada versión de host y lejos de todos los invitados.
RPC (Remote Procedure Call) Creo que no hay persona que haya trabajado con Windows que no haya visto errores relacionados con RPC. A pesar de la creencia popular, no es un protocolo único, sino cualquier protocolo cliente-servidor que cumple con ciertos parámetros. Sin embargo, si tenemos un error RPC en nuestros registros, en el 90% de los casos será un error del Microsoft RPC, que es parte de DCOM (Modelo de Objeto Componente Distribuido). Se puede encontrar una gran cantidad de documentación sobre este tema en línea, aunque gran parte de ella está bastante desactualizada. Pero si hay un fuerte deseo de profundizar en el tema, puedo recomendar artículos. , y una larga lista .
Las principales razones de los errores RPC en nuestros registros son los intentos fallidos de interacción entre los componentes de VBR (servidor > proxy, por ejemplo) y, la mayoría de las veces, debido a problemas de comunicación.
El error más destacado entre todos los errores es el de 'The RPC server is unavailable' (1722). En términos simples, el cliente no pudo establecer conexión con el servidor. No hay una respuesta única sobre el porqué, pero normalmente se trata de un problema de autenticación o de acceso a la red al puerto 135. Esto es común en infraestructuras con asignación dinámica de puertos. Al respecto, hay incluso una . Y Microsoft tiene una sobre cómo buscar las causas del mal funcionamiento.
El segundo error más común es: 'There are no more endpoints available from the endpoint mapper' (1753). El cliente o servidor RPC no pudieron asignarse un puerto. Generalmente ocurre cuando el servidor (en nuestro caso, la máquina anfitriona) estaba configurado para asignar puertos de manera dinámica de un rango estrecho que se ha agotado. Y si lo vemos desde el lado del cliente (en nuestro caso, el servidor VBR), significa que nuestro VeeamVssAgent no se ha iniciado o no se ha registrado como una interfaz RPC. También hay información sobre esto. .
Y para completar el Top 3 de errores RPC, recordemos 'RPC function call failed' (1726). Este error aparece cuando se establece la conexión, pero las solicitudes RPC no se procesan. Por ejemplo, solicitamos información sobre el estado de VSS (en caso de que se esté realizando una copia sombra en ese momento, y nosotros estamos intentando acceder), y no obtenemos respuesta, solo silencio e ignorancia.
API de Windows Tape Backup se necesita para trabajar con bibliotecas o unidades de cinta. Como mencioné al principio: no hay ningún placer en escribir nuestros controladores y luego lidiar con el soporte de cada dispositivo. Por eso Veeam no tiene sus propios controladores. Todo se realiza a través de la API estándar, cuyo soporte implementan los propios fabricantes de hardware. ¿No es mucho más lógico, verdad?
SMB/CIFS Todo el mundo los escribe juntos por costumbre, aunque no todos recuerdan que CIFS (Common Internet File System) es simplemente una versión privada de SMB (Server Message Block). Por lo tanto, no hay nada de malo en generalizar estos conceptos. Samba, por otro lado, es la implementación de Linux/Unix, y allí hay sus propias particularidades, pero me estoy desviando. Lo que aquí es importante: cuando Veeam solicita grabar algo a través de una ruta UNC (serverdirectory), el servidor utiliza la jerarquía de controladores del sistema de archivos, incluyendo mup y mrxsmb, para escribir en la unidad compartida. En consecuencia, los errores también serán generados por estos controladores.
No se puede prescindir de Winsock API. Si hay algo que hacer a través de la red, VBR trabaja a través de la API de Windows Socket, conocida popularmente como Winsock. Así que si vemos en el registro una combinación IP:Puerto, eso es. En la documentación oficial hay una buena lista de posibles .
El mencionado anteriormente WMI (Windows Management Instrumentation) es una API todopoderosa para gestionar todo y a todos en el mundo de Windows. Por ejemplo, al trabajar con Hyper-V, casi todas las solicitudes al host se realizan precisamente a través de él. En resumen, es una herramienta completamente indispensable y muy poderosa en sus capacidades. En los intentos de ayudar a averiguar dónde y qué se rompió, la herramienta integrada WBEMtest.exe es de gran ayuda.
Y el último de la lista, pero no menos importante — VSS (Volume Shadow Storage). El tema es tan inagotable y enigmático como la cantidad de documentación escrita al respecto. Shadow Copy se entiende más fácilmente como un tipo especial de instantánea, que es lo que en esencia es. Gracias a él, en VMware se pueden hacer copias de seguridad coherentes con las aplicaciones, y en Hyper-V prácticamente se puede hacer de todo. Tengo planes de escribir un artículo separado con un resumen sobre VSS, pero por ahora pueden intentar leer . Solo tengan cuidado, ya que intentar entender VSS de un vistazo puede llevar a lesiones cerebrales.
Con esto, creo que podemos detenernos. Considero que he explicado las cosas más básicas, así que en el siguiente capítulo veremos los registros. Pero si tienen preguntas, no duden en plantearlas en los comentarios.
Fuente: habr.com
