En Veeam amamos los registros. Y dado que la mayoría de nuestras soluciones son modulares, generan una gran cantidad de registros. Y dado que nuestra actividad se centra en asegurar la conservación de sus datos (es decir, en garantizar su tranquilidad), los registros no solo deben registrar cada detalle, sino hacerlo de manera detallada. Esto es necesario para que en caso de cualquier incidente podamos entender cómo ocurrió, quién fue el responsable y qué hacer a continuación. Es como en la criminología: nunca se sabe qué pequeño detalle te ayudará a encontrar al asesino de Laura Palmer.
Por lo tanto, decidí embarcarme en una serie de artículos donde contaré de manera secuencial qué escribimos en los registros, dónde los almacenamos, cómo no volvernos locos con su estructura y qué buscar en su interior.
¿Por qué una serie de artículos y por qué no describir todo de una vez?
Simplemente enumerar qué registro está donde y qué contiene es una idea bastante complicada. Y pensar en mantener esta información actualizada da miedo. Enumerar todos los posibles tipos de registros en Veeam Backup & Replication es una tabla de varias páginas en letra pequeña. Además, solo será relevante en el momento de la publicación, ya que con cada nueva actualización pueden aparecer nuevos registros, cambiar la lógica de la información almacenada en los antiguos, etc. Por lo tanto, será mucho más beneficioso explicar su estructura y la esencia de la información que contienen. Esto permitirá orientarse mejor en el terreno en lugar de simplemente memorizar los nombres.
Por eso, para no lanzarnos de cabeza a un mar de texto, realicemos un trabajo preparatorio en este artículo. Hoy no vamos a profundizar en los registros mismos, sino que abordaremos el tema desde una perspectiva más amplia: elaboraremos un glosario y discutiremos un poco la estructura de Veeam desde el punto de vista de la generación de registros.
Glosario y jerga
Aquí, en primer lugar, debo disculparme ante los defensores de la pureza del idioma ruso y los testigos del diccionario de Ozhigov. Todos amamos mucho nuestro idioma nativo, pero la maldita industria de TI trabaja en inglés. No lo inventamos nosotros, sino que así ha sido históricamente. No soy responsable, él llegó por su cuenta.
En nuestro sector, el problema de los anglicismos (y del argot) tiene su propia especificidad. Mientras que en la mayoría del mundo ya se entienden cosas muy concretas con palabras inocentes como 'host' o 'guest', en una sexta parte del planeta continúa la heroica confusión y las dudas, con personas recurriendo a los diccionarios. Y siempre el argumento obligatorio: 'Pero en nuestro trabajo...'.
Además, existe nuestra terminología específica que pertenece precisamente a los productos de Veeam, aunque algunas palabras y expresiones se han popularizado. Por lo tanto, ahora vamos a acordar qué significa cada término, y en adelante, bajo la palabra 'guest', me referiré a lo que está escrito en este capítulo y no a lo que ustedes estén acostumbrados en su trabajo. Y sí, esto no es un capricho personal, son términos establecidos en la industria. Luchar contra ellos resulta algo absurdo. Aunque siempre estoy dispuesto a debatir en los comentarios.
Lamentablemente, hay una gran cantidad de términos en nuestro trabajo y productos, así que no intentaré enumerarlos todos. Solo mencionaré los más básicos y necesarios para sobrevivir en el mar de información sobre copias de seguridad y registros. Para aquellos interesados, también puedo de un colega sobre cintas, donde también se presenta una lista de términos relacionados con esa parte de la funcionalidad.
Host (Host): En el mundo de la virtualización, es una máquina con hipervisor. Física, virtual, en la nube — no importa. Si hay algo que ejecuta un hipervisor (ESXi, Hyper-V, KVM, etc.), entonces esa 'cosa' se llama host. Puede ser un clúster de diez racks o tu laptop con una labora de una y media máquinas virtuales — si has iniciado un hipervisor, entonces eres un host. Porque el hipervisor aloja máquinas virtuales. Hay incluso una anécdota de que VMware, en su momento, quiso lograr una fuerte asociación de la palabra host precisamente con ESXi. Pero no lo logró.
En el mundo moderno, el concepto de 'host' se ha fusionado prácticamente con el concepto de 'servidor', lo que genera cierta confusión en la comunicación, especialmente cuando se trata de infraestructura Windows. Por lo tanto, cualquier máquina que tenga algún servicio interesante para nosotros puede ser llamada sin duda un host. Por ejemplo, en los registros de WinSock, la palabra host se utiliza para marcar de todo. El clásico 'Host not found' es un buen ejemplo. Así que debemos tener en cuenta el contexto, pero recordemos: en el mundo de la virtualización, un host es lo que aloja a los huéspedes (sobre esto, en dos líneas más abajo).
De los argot locales (más bien acrónimos en este caso) se recuerda que VMware es VI, vSphere es VC y Hyper-V es HV.
Guest (Huésted): Máquina virtual que opera en el host. Aquí ni siquiera hay mucho que explicar, es todo tan lógico y sencillo. Sin embargo, muchos insisten en traer aquí otros significados.
¿Por qué? No lo sé.
Guest OS, correspondiente al sistema operativo de la máquina huésped. Y así sucesivamente.
Backup/Replication Job (trabajo de respaldo): Un término puramente de VMware que denota alguna de las tareas. Backup job == Trabajo de Respaldo. Nadie ha encontrado una traducción hermosa al español, así que todos dicen "trabajo". Con el acento en la última sílaba.
Sí, así de simple se dice "trabajo". Y hasta se escribe así en los correos, y todo está bien.
Cualquier cosa como Trabajos de Respaldo, Tareas de Respaldo, etc., gracias, pero no es necesario. Simplemente 'trabajo', y te entenderán. Lo principal es acentuar la última sílaba.
Backup (Respaldo, backup. Para los verdaderos viejos se permite usar bakup): Además de lo obvio (una copia de seguridad de datos que se encuentra en alguna parte), también se refiere a la tarea (tres líneas más arriba, si ya lo olvidaste), a raíz de la cual resulta el archivo de respaldo. Probablemente, los hablantes de inglés son demasiado perezosos para decir todo el tiempo "realicé mi trabajo de respaldo", así que simplemente dicen "realicé mi respaldo", y todos se entienden perfectamente. Propondría apoyar esta maravillosa iniciativa.
Consolidate (Consolidación): Término que apareció en ESXi 5.0. Opción en el menú de trabajo con instantáneas que inicia el proceso de eliminación de las llamadas instantáneas huérfanas. Es decir, instantáneas que físicamente existen, pero que han caído de la estructura lógica visible. Teóricamente, este proceso no debería afectar a los archivos que se muestran en el administrador de instantáneas, sin embargo, puede suceder cualquier cosa. La esencia del proceso de consolidación es que los datos de la instantánea (disco hijo) se escriben en el disco principal (disco padre). El proceso de unir discos se llama 'fusión' (merge). Si se da la orden de consolidación, el registro de la instantánea puede ser eliminado de la base antes de que la instantánea sea fusionada y eliminada. Y si no se pudo eliminar la instantánea por cualquier motivo, entonces aparecen estas instantáneas huérfanas. VMwre tiene . Y nosotros también escribimos sobre ellas .
Datastore (Almacenamiento o storage): Es un concepto muy amplio, pero en el mundo de la virtualización se entiende como el lugar donde se almacenan los archivos de las máquinas virtuales. Sin embargo, en cualquier caso, es necesario comprender muy bien el contexto y, ante la menor duda, aclarar qué es exactamente lo que su interlocutor quiso decir.
Proxy: Es importante entender de inmediato que Veeam Proxy no es exactamente lo mismo a lo que estamos acostumbrados en las áreas de internet. Dentro de los productos de Veeam, es una entidad que se encarga de mover datos de un lugar a otro. Sin entrar en detalles, VBR es el servidor de comandos, y el proxy son sus caballos de trabajo. Es decir, el proxy es la máquina a través de la cual fluye el tráfico y en la que están instalados los componentes de VBR que ayudan a gestionar ese tráfico. Por ejemplo, mover datos de un canal a otro o simplemente añadir discos (modo HotAdd).
Repository: Técnicamente, esto es simplemente un registro en la base de VBR que indica el lugar donde se almacenan las copias de seguridad y cómo conectarse a dicho lugar. En realidad, esto puede ser tanto un simple recurso CIFS como un disco separado, un servidor o un bucket en la nube. Nuevamente, estamos en contexto, pero entendemos que un repositorio es simplemente el lugar donde se encuentran sus copias de seguridad.
Snapshot: Los amantes de la gramática de Oxford prefieren decir uno como snÉpshot, otro como snÉpshot, sin embargo, la mayoría analfabeta gana debido a su mayor número. Para quienes no lo saben, esta es una tecnología que permite restaurar el estado de un disco en un momento determinado. Esto se hace o desviando temporalmente las operaciones de entrada/salida del disco principal, lo que se denominará snapshot RoW (Redirect on Write), o extrayendo los bloques sobrescribibles de su disco a otro, lo que se llamará snapshot CoW (Copy on Write). Gracias a las amplias posibilidades de aplicación de estas funciones, Veeam puede realizar su magia de copias de seguridad. Estrictamente hablando, no solo ellos, pero será tarea de las próximas versiones.
En la documentación y los registros de ESXi hay un caos alrededor de este término, y en el contexto de las instantáneas, puedes encontrar tanto las instantáneas como el redo log e incluso el disco delta. En la documentación de Veeam no hay tal desorden, y la instantánea es una instantánea, mientras que el redo log es precisamente el archivo REDO, creado por un disco no persistente independiente. Los archivos REDO se eliminan al apagar la máquina virtual, por lo que confundirlos con las instantáneas es un camino hacia el fracaso.
Sintético: Las copias de seguridad sintéticas se refieren a copias de seguridad reverse incremental y forever forward. Si por casualidad no te has encontrado con este término, es simplemente uno de los mecanismos utilizados para construir la cadena de copia de seguridad. Sin embargo, en los registros también se puede encontrar el término Transform, que se utiliza en el contexto de la creación de copias completas a partir de incrementos (synthetic full).
Tarea: Es el proceso de procesamiento de cada máquina individual en el marco del trabajo. Es decir, si tienes un trabajo de copia de seguridad que incluye tres máquinas, cada máquina se procesará en el marco de una tarea separada. En total, habrá cuatro registros: uno principal para el trabajo y tres para las tareas. Sin embargo, aquí hay un matiz importante: con el tiempo, la palabra "tarea" se ha vuelto excesivamente ambigua. Cuando hablamos de registros generales, suponemos que una tarea es exactamente una VM. Pero hay sus propias "tareas" en el proxy y en el repositorio. Allí puede significar tanto un disco virtual como una máquina virtual o todo el trabajo. Por lo tanto, es importante no perder el contexto.
Servicio Veeam %name% (Servicio): Para el éxito de las copias de seguridad, varios servicios trabajan juntos, cuya lista se puede encontrar en la consola estándar. Sus nombres reflejan bastante claramente su esencia, sin embargo, entre ellos hay uno que es el más importante: Veeam Backup Service, sin el cual los demás no funcionarán.
VSS: Técnicamente, VSS siempre debe significar Microsoft Volume Shadow Copy Service. De hecho, muchos lo usan como sinónimo de Application-Aware Image Processing. Lo cual, por supuesto, es totalmente incorrecto, pero es una de esas historias donde "cualquier todoterreno puede ser llamado jeep y te entenderán".
Los fantásticos registros y los lugares donde habitan
Quiero comenzar este capítulo revelando un gran misterio: ¿qué hora se muestra en los registros?
Recuerda:
- ESXi siempre escribe registros en UTC+0.
- vCenter lleva registros según el tiempo de su zona horaria.
- Veeam lleva registros según el tiempo y la zona horaria del servidor en el que está instalado.
- Y solo los eventos de Windows en formato EVTX no están vinculados a nada. Al abrirse, la hora se recalcula en función de la máquina en la que se abren. Es la opción más conveniente, aunque también puede haber complicaciones. La única dificultad tangible es la diferencia de localizaciones. Este es un camino prácticamente garantizado hacia registros ilegibles. Sí, hay formas de solucionarlo, pero vamos a aceptar que todo en IT funciona en inglés, y acordemos siempre establecer la localización en inglés en los servidores. Por favor.
Ahora hablemos de los lugares donde residen los logs y cómo obtenerlos. En el caso de VBR, hay dos enfoques.
La primera opción es adecuada si no tienes ganas de buscar en un montón general de archivos que se relacionan únicamente con tu problema. Para esto, tenemos un asistente separado que te permite especificar un trabajo concreto y un período específico para los logs que necesitas. Luego, él recorrerá las carpetas y recopilará todo lo necesario en un solo archivo comprimido. Sobre dónde buscarlo y cómo trabajar con él, se detalla en .
Sin embargo, el asistente no recopila los logs de todas las tareas y, por ejemplo, si necesitas estudiar los logs del restaurante, failover o failback, tu camino te llevará a la carpeta %ProgramData%/Veeam/Backup. Este es el principal almacén de logs de VBR, y %ProgramData% es una carpeta oculta, lo cual es normal. Por cierto, el lugar por defecto se puede reasignar con una clave de registro tipo REG_SZ: LogDirectory en la rama HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
En máquinas Linux, los logs de los agentes de trabajo deben buscarse en /var/log/VeeamBackup/, si se utiliza una cuenta root o sudo. Si no tienes esos privilegios, busca los logs en /tmp/VeeamBackup.
Para Veeam agent for %OS_name%, los logs deben buscarse en %ProgramData%/Veeam/Endpoint (o %ProgramData%/Veeam/Backup/Endpoint) y /var/log/veeam correspondientemente.
Si utilizas Processing de Imágenes con Aplicaciones (y es probable que lo estés haciendo), la situación se complica un poco. Necesitarás los logs de nuestro helper, que se almacenan dentro de la propia máquina virtual, y los logs de VSS. Sobre cómo y dónde obtener esta información, se detalla en . Y, por supuesto, hay para recopilar los logs del sistema necesarios.
Es conveniente recopilar eventos de Windows según . Si utilizas Hyper-V, la situación se complica, ya que también necesitarás todos sus logs de la rama Applications and Service Logs > Microsoft > Windows. Aunque siempre puedes optar por el camino más grueso y simplemente obtener todos los objetos de %SystemRoot%System32winevtLogs.
Si algo se rompe durante la instalación/actualización, puedes encontrar todo lo necesario en la carpeta %ProgramData%/Veeam/Setup/Temp. Aunque no voy a ocultar que en los eventos del sistema operativo se puede encontrar información más útil que en estos registros. Lo que queda de interés se encuentra en %Temp%, pero ahí, sobre todo, están los registros de instalación del software complementario, como bases de datos, bibliotecas .Net, y demás. Ten en cuenta que Veeam se instala a partir de un archivo msi, y todos sus componentes también se instalan como paquetes msi separados, incluso si esto no se muestra en la interfaz gráfica. Por lo tanto, si la instalación de uno de los componentes falla, toda la instalación de VBR se detendrá. Así que hay que ir a los registros y ver qué exactamente falló y en qué momento.
Y un truco al final: si recibes un error durante la instalación, no te apresures a presionar OK. Primero recoge los registros, luego presiona OK. De esta manera, obtendrás un registro que termina en el momento del error, sin residuos al final.
Y a veces es necesario meterse en los registros de vSphere. Es una tarea poco agradecida, pero, arremangándose, hay que hacer cosas peores. En su forma más sencilla, necesitaremos los registros de eventos de la máquina virtual vmware.log, que están junto a su archivo .vmx. En un caso más complicado, abrimos Google y buscamos dónde están los registros para tu versión del host, ya que a VMware le encanta cambiar esta ubicación de una versión a otra. Por ejemplo, , y aquí está para . Para los registros de vCenter repetimos el procedimiento de . Pero en general, nos interesan los registros de eventos del host hostd.log, eventos de los hosts bajo la gestión de vCenter vpxa.log, los registros del núcleo vmkernel.log y los registros de autenticación auth.log. En los casos más avanzados, puede ser útil el registro SSO, que se encuentra en la carpeta SSO.
¿Complejo? ¿Confuso? ¿Intimidante? Y eso que esto ni siquiera es la mitad de la información con la que trabaja nuestro soporte diariamente. Así que realmente son muy buenos.
Componentes de Veeam
Y como cierre de este artículo introductorio, hablemos un poco sobre los componentes de Veeam Backup & Replication. Porque cuando buscas la raíz de los problemas, no está de más entender cómo está compuesto el paciente.
Así que, como probablemente todos saben, Veeam Backup es una aplicación basada en SQL. Es decir, toda la configuración, toda la información y, en general, todo lo que se necesita para su funcionamiento normal, se encuentra en su base de datos. O mejor dicho, en dos bases, si hablamos de la combinación de VBR y EM: VeeamBackup y VeeamBackupReporting, respectivamente. Así ha sido desde el principio: instalamos otra aplicación y aparece otra base. Para no poner todos los huevos en una sola canasta.
Pero para que todo esto funcione de manera cohesionada, necesitaremos un conjunto de servicios y aplicaciones que conecten todos los componentes. Exclusivamente como ejemplo, así es como se ve en uno de mis laboratorios:
En el papel del director principal está el Veeam Backup Service. Él es el encargado de intercambiar información con las bases. También se encarga de iniciar todas las tareas, orquesta los recursos asignados y actúa como un centro de comunicaciones para diversas consolas, agentes y demás. En resumen, sin él no se puede hacer nada, pero eso no significa que lo haga todo solo.
En la ejecución de lo planificado, le ayuda el Veeam Backup Manager. No es un servicio, sino una entidad encargada de iniciar trabajos y supervisar el proceso de su ejecución. Las manos trabajadoras del servicio de backup, con las que se conecta a los hosts, crea instantáneas, controla el retención y así sucesivamente.
Pero volvamos a la lista de servicios. Veeam Broker Service. Apareció en v9.5 (y no es un minero de criptomonedas, como pensaron algunos en ese momento). Se encarga de recopilar información sobre los hosts de VMware y mantenerla actualizada. Pero no se apresuren a escribir comentarios enojados, diciendo que los estamos espiando y filtrando todos los inicios de sesión/y contraseñas. La realidad es un poco más sencilla. Cuando inician una copia de seguridad, lo primero que deben hacer es conectarse al host y actualizar todos los datos sobre su estructura. Es un proceso bastante lento y engorroso. Solo piensen en cuánto tiempo les toma la operación de inicio de sesión a través de la interfaz web, y recuerden que solo se considera la capa superior. Y luego tienen que expandir toda la jerarquía hasta el lugar adecuado, por cierto. En resumen, un desastre. Si están ejecutando una docena de copias de seguridad, cada tarea debe realizar este procedimiento. Si se trata de grandes infraestructuras, este proceso puede tardar diez minutos o más. Por lo tanto, se tomó la decisión de dedicar un servicio separado para esto, a través del cual siempre se podrá obtener información actualizada. Al iniciar, verifica y escanea toda la infraestructura añadida, y luego intenta trabajar solo a nivel de cambios incrementales. Así que, incluso si están ejecutando cien copias de seguridad simultáneamente, todas solicitarán información a nuestro corredor, y no acosarán a los hosts con sus solicitudes. Si les preocupa el consumo de recursos, según nuestros cálculos, para 5000 máquinas virtuales, se necesita alrededor de 100 Mb de memoria.
A continuación tenemos Veeam Console. También conocida como Veeam Remote Console, o Veeam.Backup.Shell. Esa es la interfaz gráfica que vemos en las capturas de pantalla. Todo es sencillo y evidente: la consola se puede ejecutar desde cualquier lugar, siempre que sea Windows y haya conexión al servidor VBR. Lo único que se puede decir es que el proceso de FLR montará puntos localmente (es decir, en la máquina donde se ejecuta la consola). Y los diversos Veeam Explorers también se ejecutarán localmente, ya que son parte de la consola. Pero eso me ha llevado a desvariar…
El siguiente servicio interesante es Veeam Backup Catalog Data Service. En la lista de servicios, es conocido como Veeam Guest Catalog Service. Se encarga de indexar sistemas de archivos en máquinas virtuales y llena con este conocimiento la carpeta VBRCatalog. Se utiliza solo donde se ha habilitado la opción de indexación. Y es recomendable habilitarla únicamente si tiene Enterprise Manager. Por lo tanto, un consejo sincero: no active la indexación sin más, si no tiene EM. Cuide sus nervios y el tiempo de soporte.
También de otros servicios importantes, vale la pena mencionar Veeam Installer Service, a través del cual se lleva a cabo la entrega e instalación de los componentes necesarios en proxies, repositorios y otros gateways. De hecho, transporta los paquetes .msi necesarios a los servidores y realiza su instalación.
Veeam Data Mover — se encarga de mover datos mediante agentes auxiliares que se ejecutan en proxies (y no solo). Por ejemplo, durante una copia de seguridad, un agente leerá archivos de los datastores del host, y el segundo los escribirá cuidadosamente en la copia de seguridad.
Es importante mencionar una cosa que a menudo notan los clientes: la diferencia de versiones de los servicios y la información en la herramienta Programas y características. Sí, la lista será la misma, pero las versiones pueden estar completamente desactualizadas. No es muy bueno desde un punto de vista visual, pero es completamente normal si todo funciona de manera estable. Por ejemplo, el número de versión del servicio Installer está muy por detrás de los demás. ¿Un desastre? No, ya que no se reinstala en su totalidad, simplemente se actualizan sus DLL. En el parche v9.5 U4 ocurrió una pesadilla para el soporte técnico: al actualizar, todos los servicios obtuvieron nuevas versiones, excepto el más importante. En el parche U4b, el servicio de transporte superó a los demás por dos versiones (si se juzga por los números). Y eso también es normal - se encontró un error serio en él, por lo que recibió una actualización adicional en comparación con los demás. Así que, en resumen: la diferencia de versiones PUEDE ser un problema, pero si existe esa diferencia y todo funciona correctamente, entonces probablemente así deba ser. Pero nadie le prohíbe verificarlo con el soporte técnico.
Estos fueron los llamados servicios obligatorios o Mandatory services. Y hay una serie de servicios auxiliares, como Tape Service, Mount Service, vPowerNFS Service, y así sucesivamente.
Para Hyper-V, todo es lo mismo, solo que hay un específico Veeam Backup Hyper-V Integration Service y su propio controlador para trabajar con CBT.
Y al final hablemos de quién trabaja en máquinas virtuales durante la copia de seguridad. Para ejecutar scripts pre y post-freeze, para crear copias de sombra, recolectar metadatos, trabajar con los registros de transacciones SQL y demás se utiliza Veeam Guest Helper. Y si hay una indexación de sistemas de archivos, Veeam Guest Indexer . Estos son servicios temporales que se despliegan durante la copia de seguridad y se eliminan después de ella.
En el caso de las máquinas Linux, todo es mucho más sencillo debido a la gran cantidad de bibliotecas integradas y capacidades del propio sistema. Por ejemplo, la indexación se realiza a través de mlocate.
Hasta aquí por ahora
No me atrevo a hacerles sufrir más y una breve introducción al trasfondo de Veeam considero concluida. Sí, ni siquiera hemos llegado cerca de los registros, pero créanme, para que la información presentada en ellos no parezca un flujo de conciencia incoherente, es absolutamente necesario este tipo de introducción. Planeo pasar a los registros en el tercer artículo, y el plan para el siguiente es explicar quién genera los registros, qué es lo que realmente se muestra en ellos y por qué de esa manera y no de otra.
Fuente: habr.com
