La sauvegarde de données importantes est une bonne chose. Mais que se passe-t-il si le travail doit être poursuivi immédiatement et que chaque minute compte? Chez Acronis, nous avons décidé de vérifier dans quelle mesure il est possible de résoudre la tâche de démarrage du système le plus rapidement possible. Et c'est le premier article de la série Active Restore dans lequel je vais vous dire comment nous avons commencé le projet avec Innopolis University, quelle solution nous avons trouvée et sur quoi nous travaillons aujourd'hui. Détails - sous la coupe.
Salut Je m'appelle Daulet Tumbaev et aujourd'hui, je veux partager avec vous mon expérience dans le développement d'un système qui accélère la reprise après sinistre. Pour parler de l'ensemble du chemin de développement du projet, commençons un peu à distance. Je travaille actuellement chez Acronis, mais je suis également diplômé de l'Université Innopolis, que j'ai diplômé du programme de maîtrise en gestion du développement logiciel (connu sous le nom de MSIT-SE). Innopolis est une jeune université et le programme est encore plus jeune. Mais ensuite, il est construit sur le programme d'études de l'Université Carnegie Mellon (Université Carnegie Mellon), dans les réalisations desquelles il existe un sujet tel que les projets industriels.
Le projet industriel a pour objectif de plonger l'étudiant dans un véritable développement et de consolider les connaissances acquises dans la pratique. Pour ce faire, l'université coopère avec des entreprises telles que Yandex, Acronis, MTC et des dizaines d'autres (au total, l'université comptait 144 partenaires pour 2018). Dans le cadre de la coopération, les entreprises proposent leurs orientations de travail à l'université, et les étudiants choisissent l'un des projets les plus proches d'eux dans leur intérêt et leur niveau de formation. Il y a tout juste deux ans, j'étais toujours «de l'autre côté des barricades» et je travaillais en tant qu'étudiant sur un autre projet Acronis. Mais cette fois, je suis devenu consultant technique pour les étudiants de l'entreprise et j'ai proposé le projet Active Restore à Innopolis. L'idée d'Active Restore a été formulée par l'équipe Kernel d'Acronis, mais le développement de la solution a commencé avec l'Université Innopolis.
Restauration active - pourquoi est-ce nécessaire?
Traditionnellement, la reprise après sinistre fonctionne selon un schéma standard. Après des problèmes avec l'ordinateur, vous accédez à l'interface Web d'un système de sauvegarde, par exemple, Acronis True Image, et cliquez sur le gros bouton «restaurer». Ensuite, vous devez attendre N minutes, et seulement après cela, vous pouvez continuer à travailler.
Le problème est que ce nombre N, également appelé RTO (objectif de temps de récupération), le temps de récupération autorisé, peut être assez impressionnant, qui dépend de la vitesse de connexion (si la récupération à partir du cloud se produit), du volume du disque dur de votre ordinateur et un certain nombre d'autres facteurs. Peut-il être réduit? Oui, vous le pouvez, car pour reprendre le travail, vous n'avez pas toujours besoin d'un disque d'ordinateur complet. Les mêmes photos et vidéos n'affectent pas les fonctionnalités de l'appareil et peuvent être remontées plus tard en arrière-plan.
Pilote nécessaire ...
Le système d'exploitation prévoit de démarrer avec un disque entièrement terminé. Par conséquent, Windows effectue une série de vérifications de l'intégrité du disque. Le système ne permettra pas un démarrage normal en l'absence ou en cas de dommages de certains fichiers que le système d'exploitation s'attend à trouver. Pour résoudre ce problème, il a été décidé de mettre sur le disque les fichiers dits de redirection que nous avons créés, qui remplacent les fichiers manquants ou endommagés, mais sont en fait des mannequins. Créer de tels redirecteurs n'est pas long, car en fait ils n'ont pas de contenu.
Une récupération supplémentaire se produit comme suit. Processus d'arrière-plan, en parallèle avec le fonctionnement du système d'exploitation, les «nuls» sont remplis de données. Le processus de récupération en arrière-plan prend en compte la charge sur le disque et ne dépasse pas la limite définie. Cependant, l'utilisateur ou le système d'exploitation lui-même peut soudainement demander un fichier qui n'existe pas encore. C'est là que le deuxième mode de récupération entre en jeu. La priorité du fichier demandé est augmentée au maximum et le processus de récupération télécharge d'urgence le fichier sur le disque. Le système d'exploitation reçoit le fichier souhaité, mais avec un léger retard.
Cela ressemble à une image parfaite. Cependant, dans le monde réel, il y a un grand nombre d'écueils et d'impasses potentielles. Avec les étudiants de premier cycle d'Innopolis, nous avons décidé d'étudier ce scénario de rétablissement, d'évaluer le gain en RTO et de comprendre si cette approche est réalisable? En effet, de telles décisions sur le marché n'existaient tout simplement pas à l'époque.
Et si je décidais de céder le composant de service aux gars d'Innopolis, alors à l'intérieur d'Acronis, le travail sur un
pilote de système de fichiers mini-filtre a commencé. Cela a été fait par l'équipe Windows Kernel. Le plan était le suivant:
- Exécutez le pilote à un stade précoce du démarrage du système d'exploitation,
- Pendant le fonctionnement, lorsque l'espace utilisateur est entièrement prêt, téléchargez le service
- Le service traite les demandes des conducteurs et coordonne ses travaux ultérieurs.
Les subtilités de l'ingénierie du pilote
Si mes collègues parleront du service dans un autre article, alors dans ce texte, nous révélerons les subtilités du développement des pilotes. Le mini-filtre de pilote déjà développé a deux modes de fonctionnement: lorsque le système a démarré en mode normal et lorsque le système vient de subir une défaillance et que sa récupération se produit. Avant de charger les bibliothèques utilisateur et les applications, et donc notre service, le pilote se comporte de la même manière. Il ne sait pas dans quel état se trouve le système actuellement. En conséquence, chaque création, lecture et écriture est enregistrée, toutes les métadonnées sont enregistrées. Et lorsque le service est en ligne, le pilote fournit ces informations au service.
Dans le cas d'un démarrage normal, le service transmet un signal «Relax» au conducteur pour qu'il se «détende» et cesse d'enregistrer scrupuleusement toutes les données. Dans ce cas, le pilote passe à la journalisation uniquement des modifications sur le disque et les signale au service qui, à l'aide d'autres outils Acronis, conserve la sauvegarde de disque dans l'état le plus à jour sur le support que l'utilisateur a défini. Cela peut être une sauvegarde cloud, distante, progressive ou nocturne.
Si le mode de récupération est activé, le service informe le pilote qu'il doit travailler en mode «Récupération». Le système vient de récupérer après une panne, et dès qu'il donne une demande d'ouverture d'un fichier sur le disque, le mini-filtre doit intercepter cette opération, faire cette demande lui-même, vérifier s'il y a un tel fichier sur le disque et s'il peut être ouvert.
S'il n'y a pas de fichier, le mini-filtre transfère ces informations au service, ce qui augmente la priorité de récupération des fichiers (pendant tout ce temps, la récupération est en cours). Il s'avère que ce fichier saute juste au début de la file d'attente. Après cela, le service lui-même (ou par d'autres outils Acronis) restaure ce fichier et indique au pilote que tout va bien, maintenant le système d'exploitation peut y accéder et le pilote «libère» la demande d'origine, du système vers le disque.
Si la récupération n'est pas possible, le service informe le pilote qu'il n'y a pas non plus de fichier dans la sauvegarde. Notre pilote de mini-filtre ignore simplement la demande système et le demandeur d'origine (le système d'exploitation lui-même ou l'application) reçoit une erreur «fichier introuvable». Cependant, cela est tout à fait normal si le fichier n'était vraiment pas sur le disque et dans la sauvegarde.
Bien sûr, le système d'exploitation fonctionnera beaucoup plus lentement, car la lecture de tout fichier ou bibliothèque se déroule en plusieurs étapes, et éventuellement avec accès à des ressources distantes. Mais alors, l'utilisateur peut commencer à travailler dès que possible pendant que la récupération est en cours.
Besoin plus bas, encore plus bas ...
Le prototype a fait ses preuves. Mais nous avons également constaté la nécessité de continuer, car dans certains cas, des blocages se produisent toujours. Par exemple, le système d'exploitation peut demander diverses bibliothèques dans plusieurs threads, ce qui entraîne la fermeture de notre service à lui-même.
Le problème sur lequel je travaille maintenant augmente la vitesse de la restauration active et augmente le niveau de sécurité du système. Supposons que le système n'ait pas besoin d'un fichier entier, seulement une partie de celui-ci est nécessaire. Pour cela, un autre pilote a été développé - un pilote de filtre de disque. Cela ne fonctionne plus sur le fichier, mais au niveau du bloc. Le principe de fonctionnement est similaire: en fonctionnement normal, le pilote enregistre simplement les blocs modifiés sur le disque, et en mode de récupération, il essaie de lire le bloc par lui-même, en cas d'échec, il demande au service d'augmenter la priorité. Cependant, toutes les autres parties du système restent les mêmes. Par exemple, un service au niveau du système d'exploitation ne soupçonne même pas qu'il est proposé de communiquer avec un autre pilote, car la tâche principale consiste à fournir au système d'exploitation exactement les données nécessaires au fonctionnement. Cette direction nécessite des améliorations importantes, ne serait-ce que parce que le service ne sait toujours pas penser au niveau du bloc.
L'étape suivante, j'ai décidé d'exécuter le pilote plus en profondeur et plus tôt, en passant au niveau des pilotes UEFI et des applications Windows natives au lieu du service. Pour cela, un
pilote de démarrage UEFI (ou pilote DXE) a été développé, qui démarre et s'éteint avant le démarrage du système d'exploitation. Mais l '«historique» des pilotes UEFI, les détails de l'assemblage et de l'installation, ainsi que les spécificités des applications natives Windows, nous en tiendrons compte dans le prochain billet. Alors abonnez-vous à notre blog, et pour l'instant je vais préparer une histoire sur la prochaine étape du travail. Je serais heureux de vos commentaires et conseils.