Respaldar datos importantes es bueno. Pero, 驴qu茅 pasa si el trabajo necesita continuar de inmediato y cada minuto cuenta? Nosotros en Acronis decidimos verificar qu茅 tan posible es resolver la tarea de iniciar el sistema lo m谩s r谩pido posible. Y esta es la primera publicaci贸n de la serie Active Restore en la que les contar茅 c贸mo comenzamos el proyecto con la Universidad de Innopolis, qu茅 soluci贸n encontramos y en qu茅 estamos trabajando hoy. Detalles - debajo del corte.
Hola Mi nombre es Daulet Tumbaev, y hoy quiero compartir con ustedes mi experiencia en el desarrollo de un sistema que acelere la recuperaci贸n ante desastres. Para hablar sobre todo el camino de desarrollo del proyecto, comencemos un poco desde lejos. Actualmente trabajo en Acronis, pero tambi茅n me gradu茅 de la Universidad de Innopolis, quien me gradu茅 en el Programa de Maestr铆a en Gesti贸n del Desarrollo de Software (conocido como MSIT-SE). Innopolis es una universidad joven, y el plan de estudios es a煤n m谩s joven. Pero luego se basa en el plan de estudios de la Universidad Carnegie Mellon (Universidad Carnegie Mellon), en cuyos logros existe un tema como los proyectos industriales.
El prop贸sito del proyecto industrial es sumergir al estudiante en un desarrollo real y consolidar el conocimiento adquirido en la pr谩ctica. Para hacer esto, la universidad coopera con empresas como Yandex, Acronis, MTC y docenas de otras (en total, la universidad ten铆a 144 socios para 2018). En el curso de la cooperaci贸n, las empresas ofrecen sus direcciones de trabajo a la universidad, y los estudiantes eligen uno de los proyectos m谩s cercanos a ellos en sus intereses y nivel de capacitaci贸n. Hace solo dos a帽os, todav铆a estaba "al otro lado de las barricadas" y trabajaba como estudiante en otro proyecto de Acronis. Pero esta vez, me convert铆 en consultor t茅cnico para estudiantes de la compa帽铆a y propuse el proyecto Restauraci贸n activa a Innopolis. La idea de Restauraci贸n activa fue formulada por el equipo de Kernel en Acronis, pero el desarrollo de la soluci贸n comenz贸 con la Universidad de Innopolis.
Restauraci贸n activa: 驴por qu茅 es necesario?
Tradicionalmente, la recuperaci贸n ante desastres funciona de acuerdo con un esquema est谩ndar. Despu茅s de problemas con la computadora, vaya a la interfaz web de alg煤n sistema de respaldo, por ejemplo, Acronis True Image, y haga clic en el bot贸n grande "restaurar". A continuaci贸n, debe esperar N minutos, y solo despu茅s de eso puede continuar trabajando.
El problema es que este n煤mero N, tambi茅n conocido como RTO (objetivo de tiempo de recuperaci贸n), el tiempo de recuperaci贸n permitido, puede ser bastante impresionante, lo que depende de la velocidad de conexi贸n (si se produce la recuperaci贸n de la nube), del volumen del disco duro de su computadora y Una serie de otros factores. 驴Se puede reducir? S铆, puede, porque para reanudar el trabajo no siempre necesita un disco de computadora completo. Las mismas fotos y videos no afectan la funcionalidad del dispositivo y se pueden extraer m谩s adelante en segundo plano.
Conductor necesario ...
El sistema operativo espera comenzar con un disco completamente terminado. Por lo tanto, Windows realiza una serie de comprobaciones de integridad del disco. El sistema no permitir谩 un inicio normal en ausencia o da帽o de algunos archivos que el sistema operativo espera encontrar. Para resolver este problema, se decidi贸 colocar en el disco los llamados archivos redirectores que creamos, que reemplazan los archivos faltantes o da帽ados, pero en realidad son tontos. Crear tales redirectores no es largo, porque de hecho no tienen contenido.
La recuperaci贸n adicional ocurre de la siguiente manera. Proceso de fondo, en paralelo con la operaci贸n del sistema operativo, los "dummies" se llenan de datos. El proceso de recuperaci贸n en segundo plano tiene en cuenta la carga en el disco y no supera el l铆mite establecido. Sin embargo, el usuario o el propio sistema operativo pueden solicitar de repente un archivo que a煤n no existe. Aqu铆 es donde entra en juego el segundo modo de recuperaci贸n. La prioridad del archivo solicitado se incrementa al m谩ximo, y el proceso de recuperaci贸n carga urgentemente el archivo en el disco. El sistema operativo recibe el archivo deseado, aunque con un ligero retraso.
Se ve como una imagen perfecta. Sin embargo, en el mundo real, hay una gran cantidad de trampas y posibles puntos muertos. Junto con los estudiantes universitarios de Innopolis, decidimos investigar este escenario de recuperaci贸n, evaluar la ganancia en RTO y entender si este enfoque es factible. De hecho, tales decisiones en el mercado simplemente no exist铆an en ese momento.
Y si decid铆 renunciar al componente de servicio a los chicos de Innopolis, entonces, dentro de Acronis, el trabajo comenz贸 en un
controlador de sistema de archivos con mini filtro . Esto fue hecho por el equipo de Windows Kernel. El plan era este:
- Ejecute el controlador en una etapa temprana de inicio del sistema operativo,
- Durante la operaci贸n, cuando el espacio del usuario est茅 completamente listo, descargue el servicio
- El servicio procesa las solicitudes de los conductores y coordina su trabajo posterior.
Las sutilezas de la ingenier铆a del conductor.
Si mis colegas hablar谩n sobre el servicio en otra publicaci贸n, en este texto revelaremos las sutilezas del desarrollo de controladores. El mini filtro de controlador ya desarrollado tiene dos modos de funcionamiento: cuando el sistema se inici贸 en modo normal y cuando el sistema acaba de experimentar una falla y se produce su recuperaci贸n. Antes de cargar las bibliotecas y aplicaciones de usuario, y por lo tanto nuestro servicio, el controlador se comporta igual. 脡l no sabe en qu茅 estado se encuentra el sistema ahora. Como resultado, cada creaci贸n, lectura y escritura se registra, se registran todos los metadatos. Y cuando el servicio est谩 en l铆nea, el controlador proporciona esta informaci贸n al servicio.
En el caso de un inicio normal, el servicio transmite una se帽al de "Relax" al conductor para que "se relaje" y deje de registrar escrupulosamente todos los datos. En este caso, el controlador cambia al registro solo los cambios en el disco y los informa al servicio, que con la ayuda de otras herramientas de Acronis mantiene la copia de seguridad del disco en el estado m谩s actualizado en el medio que defini贸 el usuario. Puede ser una copia de seguridad en la nube, remota, gradual o nocturna.
Si el modo de recuperaci贸n est谩 habilitado, el servicio informa al controlador que necesita trabajar en el modo "Recuperaci贸n". El sistema se acaba de recuperar despu茅s de una falla y, tan pronto como solicita que se abra un archivo en el disco, el mini filtro debe interceptar esta operaci贸n, realizar esta solicitud, verificar si existe dicho archivo en el disco y si se puede abrir.
Si no hay ning煤n archivo, el mini filtro transfiere esta informaci贸n al servicio, lo que aumenta la prioridad de la recuperaci贸n de archivos (todo este tiempo, la recuperaci贸n est谩 en progreso). Resulta que este archivo simplemente salta al comienzo de la cola. Despu茅s de eso, el servicio en s铆 (o por otras herramientas de Acronis) restaura este archivo y le dice al controlador que todo est谩 bien, ahora el sistema operativo puede acceder a 茅l y el controlador "libera" la solicitud original, del sistema al disco.
Si la recuperaci贸n no es posible, el servicio informa al controlador que tampoco hay ning煤n archivo en la copia de seguridad. Nuestro controlador de mini-filtro simplemente omite la solicitud del sistema y el solicitante original (el sistema operativo o la aplicaci贸n) recibe un error de "archivo no encontrado". Sin embargo, esto es bastante normal si el archivo realmente no estaba en el disco y en la copia de seguridad.
Por supuesto, el sistema operativo funcionar谩 mucho m谩s lento, porque la lectura de cualquier archivo o biblioteca ocurre en varias etapas, y posiblemente con acceso a recursos remotos. Pero entonces el usuario puede comenzar a trabajar lo antes posible mientras la recuperaci贸n a煤n est谩 teniendo lugar.
Necesita m谩s bajo, incluso m谩s bajo ...
El prototipo ha demostrado su val铆a. Pero tambi茅n encontramos la necesidad de seguir adelante, porque en algunos casos todav铆a se producen puntos muertos. Por ejemplo, el sistema operativo puede solicitar varias bibliotecas en varios subprocesos, lo que conduce al cierre de nuestro servicio.
El problema en el que estoy trabajando ahora es aumentar la velocidad de Restauraci贸n activa y aumentar el nivel de seguridad del sistema. Supongamos que el sistema no necesita un archivo completo, solo se necesita una parte. Para esto, se desarroll贸 otro controlador: un controlador de filtro de disco. Ya no funciona en el archivo, sino en el nivel de bloque. El principio de funcionamiento es similar: en funcionamiento normal, el controlador simplemente registra los bloques modificados en el disco y, en modo de recuperaci贸n, intenta leer el bloque por s铆 solo; en caso de falla, solicita al servicio que aumente la prioridad. Sin embargo, todas las dem谩s partes del sistema siguen siendo las mismas. Por ejemplo, un servicio a nivel del sistema operativo ni siquiera sospecha que se le est谩 ofreciendo comunicarse con otro controlador, porque la tarea principal es proporcionar al sistema operativo exactamente los datos necesarios para su funcionamiento. Esta direcci贸n requiere mejoras significativas, aunque solo sea porque el servicio a煤n no sabe c贸mo pensar a nivel de bloque.
El siguiente paso, decid铆 ejecutar el controlador m谩s profundo y antes, cayendo al nivel de los controladores UEFI y las aplicaciones nativas de Windows en lugar del servicio. Para esto, se desarroll贸 un
controlador de arranque UEFI (o controlador DXE), que se inicia y muere antes de que se inicie el sistema operativo. Pero la "historia" de los controladores UEFI, los detalles sobre el ensamblaje y la instalaci贸n, as铆 como los detalles de las aplicaciones nativas de Windows, los consideraremos en la pr贸xima publicaci贸n. Suscr铆bete a nuestro blog y por ahora preparar茅 una historia sobre la pr贸xima etapa del trabajo. Estar铆a feliz por sus comentarios y consejos.