Sauvegarder les données importantes est une bonne chose. Mais que se passe-t-il si le travail doit continuer 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 le problème du démarrage du système le plus rapidement possible. Et ceci est le premier article de la série Active Restore, dans lequel je vais vous raconter comment nous avons démarré le projet avec l'Université d'Innopolis, quelle solution nous avons trouvée et sur quoi nous travaillons aujourd'hui. Les détails sont sous la coupe.
Bonjour! Je m'appelle Daulet Tumbayev et j'aimerais aujourd'hui 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 parcours de développement du projet, commençons un peu de loin. Je travaille actuellement chez Acronis, mais je suis également diplômé de l'Université d'Innopolis, où j'ai suivi le 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 il s'appuie sur le programme d'études de l'Université Carnegie Mellon, dont les travaux incluent des sujets tels que les projets industriels.
Le but du projet industriel est de plonger l'étudiant dans un développement réel 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, en 2018, l'université comptait 144 partenaires). Au cours de la coopération, les entreprises proposent leurs domaines de travail à l'université et les étudiants choisissent l'un des projets les plus proches de leurs intérêts et de leur niveau de formation. Il y a littéralement deux ans, j'étais encore « de l'autre côté des barricades » et je travaillais comme étudiant sur un autre projet Acronis. Mais cette fois, je suis devenu consultant technique auprès des étudiants du côté de l’entreprise et j’ai proposé le projet Active Restore à Innopolis. L'idée même d'Active Restore a été formulée par l'équipe Kernel d'Acronis, mais le développement de la solution a commencé en collaboration avec l'Université d'Innopolis.
Active Restore – pourquoi est-elle nécessaire ?
Traditionnellement, la reprise après sinistre fonctionne selon un schéma standard. Après des problèmes avec votre 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 pourrez continuer à travailler.
Le problème est que ce nombre N, également appelé RTO (recovery time objective), temps de récupération autorisé, peut être assez impressionnant, qui dépend de la vitesse de connexion (si la récupération se fait depuis le cloud), de la taille du disque dur de votre machine. , et un certain nombre d'autres facteurs. Est-il possible de le réduire ? Oui, c'est possible, car pour reprendre le travail, vous n'avez pas toujours besoin d'un disque informatique plein. Les mêmes photos et vidéos n’affectent en rien les fonctionnalités de l’appareil et peuvent être affichées ultérieurement en arrière-plan.
Pilote nécessaire...
Le système d'exploitation s'attend à démarrer avec le disque entièrement prêt. Par conséquent, Windows effectue une série de vérifications pour vérifier l'intégrité du disque. Le système ne permettra pas un démarrage normal si certains fichiers que le système d'exploitation s'attend à trouver sont manquants ou endommagés. Pour résoudre ce problème, il a été décidé de placer sur le disque les fichiers dits redirecteurs que nous avons créés, qui remplacent les fichiers manquants ou endommagés, mais qui sont en fait des mannequins. Il ne faut pas longtemps pour créer de tels redirecteurs, car ils n’ont en réalité aucun contenu.
Une restauration ultérieure se produit comme suit. Par un processus en arrière-plan, parallèlement au fonctionnement du système d’exploitation, des « mannequins » sont remplis de données. Le processus de récupération en arrière-plan prend en compte la charge du disque et ne dépasse pas la limite spécifiée. Cependant, l'utilisateur ou le système d'exploitation lui-même peut soudainement avoir besoin d'un fichier qui n'existe pas encore. C'est là qu'intervient le deuxième mode de récupération. La priorité du fichier demandé est augmentée au maximum et le processus de récupération charge de toute urgence le fichier sur le disque. Le système d'exploitation reçoit le fichier requis, mais avec un léger retard.
Voilà à quoi ressemble une image idéale. Cependant, dans le monde réel, il existe un grand nombre de pièges et d’impasses potentielles. Avec les étudiants du master Innopolis, nous avons décidé d'explorer ce scénario de reprise, d'évaluer les gains en RTO et de comprendre si une telle approche est réalisable ? Après tout, de telles solutions n’existaient tout simplement pas à l’époque sur le marché.
Et si je décidais de confier le composant service aux gars d'Innopolis, alors au sein d'Acronis, le travail commençait sur . Cela a été réalisé par l'équipe Windows Kernel. Le plan était le suivant :
- Lancez le pilote dès le début du démarrage du système d'exploitation,
- Pendant le travail, quand sera complètement prêt, téléchargez le service
- Le service traite les demandes des chauffeurs et coordonne ses travaux ultérieurs.
Subtilités de l'ingénierie des pilotes
Si mes collègues parlent du service dans un autre article, alors dans ce texte, nous révélerons les subtilités du développement des pilotes. Le pilote de mini-filtre déjà développé a deux modes de fonctionnement : lorsque le système démarre en mode normal et lorsque le système vient de subir une panne et est en cours de restauration. Avant de charger les bibliothèques et applications utilisateur, et donc notre service, le pilote se comporte de la même manière. Il ne sait pas dans quel état se trouve actuellement le système. En conséquence, chaque création, lecture et écriture est journalisée et toutes les métadonnées sont enregistrées. Et lorsque le service est en ligne, le chauffeur fournit ces informations au service.
Dans le cas d'un démarrage normal, le service envoie un signal « Relax » au conducteur pour qu'il « se détende » et arrête scrupuleusement d'enregistrer 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, maintient la sauvegarde du disque dans l'état le plus à jour sur le support spécifié par l'utilisateur. Il peut s'agir d'une sauvegarde dans le cloud, à distance, progressive ou nocturne.
Si le mode de récupération est activé, le service indique au pilote qu'il doit fonctionner en mode « Récupération ». Le système vient de se remettre d'un crash, et dès qu'il fait une demande d'ouverture d'un fichier sur le disque, le mini-filtre doit intercepter cette opération, faire lui-même cette demande, vérifier si un tel fichier existe sur le disque et si il peut être ouvert.
Si un fichier est manquant, le mini-filtre transmet cette information au service, ce qui augmente la priorité de récupération du fichier (pendant tout ce temps, la récupération se déroule en arrière-plan). Il s'avère que ce fichier saute simplement au début de la file d'attente. Après cela, le service lui-même (ou d'autres moyens Acronis) restaure ce fichier et indique au pilote que tout va bien, le système d'exploitation peut désormais y accéder et le pilote « libère » la demande d'origine, du système vers le disque.
Si la récupération est impossible, le service informe le pilote que le fichier n'est pas dans la sauvegarde. Notre pilote de mini-filtre transmet simplement la requête système et le demandeur d'origine (le système d'exploitation lui-même ou l'application) reçoit une erreur « fichier non trouvé ». Cependant, cela est tout à fait normal si le fichier n'était vraiment pas sur le disque ni dans la sauvegarde.
Bien entendu, le système d'exploitation fonctionnera beaucoup plus lentement, car la lecture de n'importe quel fichier ou bibliothèque se déroule en plusieurs étapes, éventuellement avec accès à des ressources distantes. Mais l’utilisateur peut reprendre le travail le plus rapidement possible pendant que la récupération est toujours en cours.
Il faut plus bas, encore plus bas...
Le prototype a prouvé sa fonctionnalité. Mais nous avons également constaté la nécessité d’aller de l’avant car, dans certains cas, des impasses subsistent. Par exemple, le système d'exploitation peut demander diverses bibliothèques dans plusieurs threads, ce qui conduit notre service à revenir sur lui-même.
Le problème sur lequel je travaille actuellement est d'augmenter la vitesse d'Active Restore et d'augmenter le niveau de sécurité du système. Disons que le système n'a pas besoin de l'intégralité du fichier, mais seulement d'une partie. À cette fin, un autre pilote a été développé : le pilote de filtre de disque. Cela ne fonctionne plus au niveau du fichier, mais au niveau du bloc. Le principe de fonctionnement est similaire : en mode de 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 tout seul et, en cas d'échec, 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 lui est demandé de communiquer avec un autre pilote, car la tâche principale est de fournir au système d'exploitation exactement les données nécessaires au fonctionnement. Ce domaine nécessite des améliorations significatives, ne serait-ce que parce que le service ne sait pas encore penser au niveau des blocs.
L'étape suivante, j'ai décidé de lancer le pilote plus profondément et plus tôt, en descendant au niveau des pilotes UEFI et des applications Windows natives au lieu du service. A cet effet, il a été développé (ou pilote DXE), qui démarre et meurt avant même le démarrage du système d'exploitation. Mais nous examinerons « l'historique » des pilotes UEFI, les détails sur l'assemblage et l'installation, ainsi que les spécificités des applications Windows Native dans le prochain article. Alors abonnez-vous à notre blog, et en attendant je vous préparerai un article sur la prochaine étape des travaux. Je serai heureux de voir vos commentaires et vos conseils.
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Avez-vous déjà vécu des situations où la récupération a pris un temps atrocement long :
-
65.1%Oui28
-
23.2%Non10
-
11.6%Je n'y ai pas pensé5
43 utilisateurs ont voté. 3 utilisateurs se sont abstenus.
Source: habr.com