At tage backup af vigtige data er en god idé. Men hvad hvis arbejdet skal fortsætte med det samme, og hver minut tæller? Hos Acronis har vi besluttet at undersøge, hvor hurtigt systemet kan genstartes. Dette er det første indlæg i serien Active Restore, hvor jeg vil fortælle, hvordan vi gik i gang med projektet sammen med Innopolis Universitetet, hvilken løsning vi fandt, og hvad vi arbejder på i dag. Detaljer – nedenfor.
Hej! Mit navn er Daulet Tumbaev, og i dag vil jeg gerne dele mine erfaringer med at udvikle et system, der accelererer nødagter. For at fortælle om hele udviklingsprocessen for projektet, starter vi et stykke væk. Jeg arbejder nu hos Acronis, men er også cand.scient. fra Innopolis Universitetet, hvor jeg afsluttede min kandidatuddannelse i "Software Development Management" (kendt som MSIT-SE). Innopolis er et ungt universitet, og studieprogrammet er endnu yngre. Men det er baseret på studieplaner fra Carnegie Mellon Universitet, som har emner inden for industrielle projekter.
Målet med det industrielle projekt er at give studerende en oplevelse af ægte udvikling og fastslåde deres viden gennem praktik. For dette samarbejder universitetet med virksomheder som Yandex, Acronis, MTC og mange andre (i 2018 havde universitetet 144 partnere). I samarbejdets løb tilbyder virksomhederne deres arbejdsretninger til universitetet, mens studerende vælger et projekt, der passer til deres interesser og niveau. For blot to år siden var jeg "på den anden side af barrikaderne" og arbejdede som studerende på et andet Acronis-projekt. Men denne gang blev jeg teknisk rådgiver for studerende fra virksomhedens side og foreslog Innopolis universitetet projektet Active Restore. Ideen til Active Restore blev formuleret af Kernel teamet hos Acronis, men udviklingen af løsningen begyndte sammen med Innopolis universitetet.
Active Restore – hvad er behovet?
Traditionelt fungerer nødagter efter en standardprocedure. Efter problemer med computeren logger du ind på webgrænsefladen til et backup-system, for eksempel Acronis True Image, og trykker på den store "gendan"-knap. Derefter skal du vente N minutter, og først derefter kan du fortsætte arbejdet.
Problemet er, at dette tal N, også kendt som RTO (recovery time objective), den acceptable genopretningstid, kan være ret betydeligt og afhænger af forbindelseshastigheden (hvis der genoprettes fra skyen), diskstørrelsen på din maskine og en række andre faktorer. Kan det reduceres? Ja, det kan det, da det ikke altid er nødvendigt at have hele computerens disk klar for at fortsætte arbejdet. De samme billeder og videoer påvirker ikke enhedens funktionalitet og kan hentes senere i baggrunden.
Driver nødvendig…
Operativsystemet beregner at starte op med en helt klar disk. Derfor udfører Windows en række tjek for diskens integritet. Systemet tillader ikke en normal opstart, hvis nogle filer, som OS forventer at finde, mangler eller er beskadigede. For at løse dette problem besluttede vi at lægge såkaldte redirector-filer på disken, som erstatter manglende eller beskadigede filer, men som i virkeligheden er tomme skal. At oprette sådanne redirectorer tager ikke lang tid, da de i princippet ikke har noget indhold.
Herefter sker genopretningen som følger. I baggrundsprocessen, parallelt med operativsystemets arbejde, fyldes "skallerne" med data. Baggrundsgenopretningsprocessen tager hensyn til belastningen på disken og overskrider ikke den fastsatte grænse. Men brugeren eller selve operativsystemet kan pludselig kræve en fil, der endnu ikke er tilgængelig. Her træder den anden genoprettelsesmetode i kraft. Prioriteten af den anmodede fil hæves til maksimum, og genopretningsprocessen indlæser hurtigt filen på disken. Operativsystemet får den nødvendige fil, selvom med en lille forsinkelse.
Sådan ser det perfekte billede ud. Men i den virkelige verden findes der et væld af faldgruber og potentielle deadlocks. Sammen med kandidatstuderende fra Innopolis besluttede vi at undersøge dette genoprettelsesscenario, vurdere gevinsten i RTO og finde ud af, om en sådan tilgang er gennemførlig? For der havde ikke været lignende løsninger på markedet på det tidspunkt.
Og hvis jeg besluttede at overlade den servicemæssige del til gutterne fra Innopolis, så begyndte arbejdet indenfor Acronis på Dette blev taget op af Windows Kernel-teamet. Planen var som følger:
- At starte driveren tidligt i opstartsprocessen af operativsystemet,
- mens er helt klar, at indlæse tjenesten.
- Tjenesten behandler driverens forespørgsler og koordinerer dens videre arbejde.
Nuancerne ved driverudvikling
Mens mine kollegaer vil tale om tjenesten i et andet indlæg, vil vi i denne tekst afsløre nuancerne ved udviklingen af driveren. Den allerede udviklede mini-filter driver har to driftsmuligheder - når systemet startes op i normal tilstand, og når systemet lige har gennemgået et crash og er i gang med at blive gendannet. Inden brugerbiblioteker og -applikationer, samt vores tjeneste, begynder at indlæses, opfører driveren sig ens. Den ved ikke, i hvilken tilstand systemet befinder sig. Som et resultat registreres hver create, read, og write, og alle metadata dokumenteres. Og når tjenesten er online, giver driveren disse oplysninger til tjenesten.
Ved en almindelig opstart sender tjenesten et signal "Relax" til driveren, så den "kan slappe af" og stoppe med at registrere alle data omhyggeligt. I dette tilfælde overgår driveren til kun at registrere ændringer på disken og informere tjenesten, som med andre Acronis-værktøjer holder diskbackupen så opdateret som muligt på det medie, som brugeren har angivet. Dette kan være cloud, fjernlager, gradvis eller natbackup.
Hvis behandlingen af gendannelsestilstand aktiveres, informerer tjenesten driveren om, at den skal arbejde i "Recovery"-tilstand. Systemet er lige blevet gendannet efter et crash, og så snart det anmoder om at åbne en fil på disken, skal mini-filteret opsnappe denne operation, selv udføre denne forespørgsel, kontrollere om en sådan fil findes på disken, og om den kan åbnes.
Hvis filen mangler, videregiver mini-filtret denne information til tjenesten, som hæver prioriteten for at gendanne filen (i mellemtiden foregår gendannelsen i baggrunden). Det betyder, at filen blot springer til starten af køen. Derefter gendanner tjenesten selv (eller ved hjælp af andre Acronis-midler) denne fil og informerer driveren om, at alt er i orden, så nu kan operativsystemet tilgå den, og driveren "frigiver" den originale anmodning fra systemet til disken.
Hvis gendannelse er umulig, informerer tjenesten driveren om, at filen heller ikke findes i backup'en. Vores mini-filterdriver lader simpelthen den systemiske anmodning passere videre, så den oprindelige anmodende part (selve OS eller applikationen) modtager fejlen "fil ikke fundet". Det er dog helt normalt, hvis filen rent faktisk ikke var på disken og i backup'en.
Selvfølgelig vil operativsystemet arbejde betydeligt langsommere, fordi læsning af enhver fil eller bibliotek sker i flere trin, muligvis med adgang til eksterne ressourcer. Men brugeren kan dog starte sit arbejde på kort tid, mens gendannelsen stadig foregår.
Skal længere ned, endnu længere...
Prototypen har bevist sin funktionalitet. Men vi har også opdaget behovet for at bevæge os videre, da der i nogle tilfælde stadig opstår deadlocks. For eksempel kan operativsystemet anmode om forskellige biblioteker i flere tråde, hvilket fører til, at vores tjeneste låser sig selv.
Problemet jeg arbejder på nu er at forbedre hastigheden af Active Restore og niveauet af systemets sikkerhed. Antag, at systemet ikke har brug for en hel fil, men kun en del af den. Derfor er der udviklet en yderligere driver - diskfilterdriveren. Den arbejder ikke på filniveau, men på blokniveau. Princippet for drift er det samme: i normal drift registrerer driveren blot de ændrede blokke på disken, mens den i gendannelsesmodus forsøger at læse blokken selv. Hvis det mislykkes, anmoder den om en prioriteringsforøgelse fra tjenesten. Alle andre dele af systemet forbliver uændrede. For eksempel anede OS-niveau tjenesten ikke engang, at den beder om at kommunikere med en anden driver, fordi hovedopgaven er at levere de data til OS, som er nødvendige for driften. Dette område kræver betydelige forbedringer, ikke mindst fordi tjenesten endnu ikke kan tænke på blokniveau.
Neste skridt besluttede jeg at starte driveren dybere og tidligere ved at bevæge mig ned på UEFI-drivere og native Windows-applikationer i stedet for tjenesten. Derfor er der udviklet (eller DXE-driver), som starter og dør endnu før OS starter. Men "historien" om UEFI-drivere, detaljer om bygning og installation samt specifikationen for Windows Native-applikationer, vil vi se nærmere på i næste indlæg. Så abonner på vores blog, mens jeg forbereder en fortælling om næste fase af arbejdet. Jeg ser frem til jeres kommentarer og råd.
Kun registrerede brugere kan deltage i undersøgelsen. , please.
Har du nogensinde været i situationer, hvor gendannelse tog en ubehageligt lang tid:
65.1%Ja28
23.2%Nej10
11.6%Aldrig tænkt over det5
I alt 43 brugere stemte. 3 brugere afholdt sig.
Kilde: habr.com
