Sikkerhedskopiering af vigtige data er en god ting. Men hvad nu, hvis arbejdet skal fortsætte med det samme, og hvert minut tæller? Vi hos Acronis besluttede at tjekke, hvordan det er muligt at løse problemet med at starte systemet så hurtigt som muligt. Og dette er det første indlæg i Active Restore-serien, hvor jeg vil fortælle dig, hvordan vi startede projektet sammen med Innopolis University, hvilken løsning vi fandt, og hvad vi arbejder på i dag. Detaljer er under skæringen.
Hej! Mit navn er Daulet Tumbayev, og i dag vil jeg gerne dele min erfaring med at udvikle et system, der fremskynder gendannelse efter katastrofe. For at tale om hele projektets udviklingsvej, lad os starte lidt på afstand. Jeg arbejder i øjeblikket hos Acronis, men jeg er også uddannet fra Innopolis University, hvor jeg gennemførte kandidatuddannelsen i Software Development Management (kendt som MSIT-SE). Innopolis er et ungt universitet, og læseplanen er endnu yngre. Men det er bygget på pensum fra Carnegie Mellon University, hvis arbejde omfatter et emne som industrielle projekter.
Formålet med industriprojektet er at fordybe den studerende i reel udvikling og konsolidere den erhvervede viden i praksis. For at gøre dette samarbejder universitetet med virksomheder som Yandex, Acronis, MTC og snesevis af andre (i alt havde universitetet i 2018 144 partnere). I løbet af samarbejdet tilbyder virksomhederne deres arbejdsområder til universitetet, og de studerende vælger et af projekterne, der er tættere på deres interesser og uddannelsesniveau. For bogstaveligt talt to år siden var jeg stadig "på den anden side af barrikaderne" og arbejdede som studerende på et andet Acronis-projekt. Men denne gang blev jeg teknisk konsulent for studerende på virksomhedens side og foreslog Active Restore-projektet til Innopolis. Selve ideen om Active Restore blev formuleret af Kernel-teamet hos Acronis, men udviklingen af løsningen begyndte sammen med Innopolis University.
Aktiv gendannelse – hvorfor er det nødvendigt?
Traditionelt fungerer disaster recovery efter en standardordning. Efter problemer med din computer, går du til webgrænsefladen på et backupsystem, for eksempel Acronis True Image, og klikker på den store "gendan" knap. Dernæst skal du vente N minutter, og først efter det kan du fortsætte med at arbejde.
Problemet er, at dette tal N, også kendt som RTO (gendannelsestidsobjektiv), den tilladte retableringstid, kan være ret imponerende, hvilket afhænger af forbindelseshastigheden (hvis gendannelsen er fra skyen), størrelsen på din maskines harddisk og en række andre faktorer. Er det muligt at reducere det? Ja, det kan du, for for at genoptage arbejdet behøver du ikke altid en fuld computerdisk. De samme billeder og videoer påvirker ikke enhedens funktionalitet på nogen måde og kan trækkes op senere i baggrunden.
Driver nødvendig...
Operativsystemet forventer at starte med disken helt klar. Derfor udfører Windows en række kontroller for at kontrollere diskens integritet. Systemet tillader ikke en normal opstart, hvis nogle filer, som OS forventer at blive fundet, mangler eller er beskadiget. For at løse dette problem blev det besluttet at placere de såkaldte redirector-filer på disken, som vi oprettede, som erstatter manglende eller beskadigede filer, men i virkeligheden er dummies. Det tager ikke lang tid at oprette sådanne omdirigerere, fordi de faktisk ikke har noget indhold.
Yderligere restaurering sker som følger. Ved en baggrundsproces, parallelt med driften af operativsystemet, fyldes "dummies" med data. Baggrundsgendannelsesprocessen tager højde for diskbelastningen og overskrider ikke den indstillede grænse. Brugeren eller selve operativsystemet kan dog pludselig kræve en fil, der endnu ikke eksisterer. Det er her den anden gendannelsestilstand kommer i spil. Prioriteten for den anmodede fil hæves til maksimum, og gendannelsesprocessen indlæser filen på disken. Operativsystemet modtager den nødvendige fil, dog med en lille forsinkelse.
Sådan ser et ideelt billede ud. Men i den virkelige verden er der et stort antal faldgruber og potentielle dødvande. Sammen med Innopolis masterstuderende besluttede vi at udforske dette recovery-scenarie, evaluere gevinsterne i RTO og forstå, om en sådan tilgang er gennemførlig? Sådanne løsninger var der jo simpelthen ikke på markedet på det tidspunkt.
Og hvis jeg besluttede at udbyde servicekomponenten til fyrene fra Innopolis, så begyndte arbejdet inden for Acronis på . Dette blev gjort af Windows Kernel-teamet. Planen var sådan her:
- Start driveren på et tidligt stadium af OS-start,
- Under arbejdet, hvornår vil være helt klar, download tjenesten
- Tjenesten behandler chaufføranmodninger og koordinerer sit videre arbejde.
Finesser af driverteknik
Hvis mine kolleger vil tale om tjenesten i et andet indlæg, så vil vi i denne tekst afsløre forviklingerne ved chaufførudvikling. Den allerede udviklede minifilterdriver har to driftstilstande - når systemet startede i normal tilstand, og når systemet lige har oplevet en fejl og er ved at blive gendannet. Før indlæsning af brugerbiblioteker og applikationer, og derfor vores service, opfører chaufføren sig på samme måde. Han ved ikke, hvilken tilstand systemet er i i øjeblikket. Som et resultat bliver hver oprettelse, læsning og skrivning logget, og alle metadata registreres. Og når tjenesten er online, giver chaufføren disse oplysninger til tjenesten.
Ved normal start sender tjenesten et "Slap af"-signal til chaufføren, så den "slapper af" og stopper omhyggeligt med at logge alle data. I dette tilfælde skifter driveren til kun at logge ændringer på disken og rapporterer dem til tjenesten, som ved hjælp af andre Acronis-værktøjer vedligeholder diskbackupen i den mest opdaterede tilstand på det medie, som brugeren har angivet. Dette kan være cloud, fjern, gradvis eller natlig backup.
Hvis gendannelsestilstand er aktiveret, fortæller tjenesten driveren, at den skal fungere i "gendannelsestilstand". Systemet er netop genoprettet efter et nedbrud, og så snart det fremsætter en anmodning om at åbne en fil på disken, skal minifilteret opsnappe denne handling, selv foretage denne anmodning, kontrollere om en sådan fil findes på disken og om den kan åbnes.
Hvis en fil mangler, sender minifilteret disse oplysninger til tjenesten, hvilket øger prioriteten af filgendannelse (almen denne tid foregår gendannelse i baggrunden). Det viser sig, at denne fil simpelthen hopper til begyndelsen af køen. Herefter gendanner selve tjenesten (eller andre Acronis-midler) denne fil og fortæller driveren, at alt er ok, nu kan operativsystemet få adgang til den, og driveren "frigiver" den oprindelige anmodning, fra systemet til disken.
Hvis gendannelse er umulig, informerer tjenesten driveren om, at filen ikke er i sikkerhedskopien. Vores minifilterdriver sender blot systemanmodningen videre, og den oprindelige anmoder (selve OS eller applikationen) modtager en "fil ikke fundet"-fejl. Dette er dog helt normalt, hvis filen virkelig ikke var på disken og i sikkerhedskopien.
Selvfølgelig vil operativsystemet arbejde meget langsommere, fordi læsning af enhver fil eller ethvert bibliotek sker i flere trin, muligvis med adgang til eksterne ressourcer. Men brugeren kan komme tilbage på arbejde så hurtigt som muligt, mens genopretning stadig finder sted.
Har brug for lavere, endnu lavere...
Prototypen har bevist sin funktionalitet. Men vi fandt også et behov for at komme videre, fordi der i nogle tilfælde stadig er dødvande. For eksempel kan styresystemet anmode om forskellige biblioteker i flere tråde, hvilket fører til, at vores service går tilbage på sig selv.
Det problem, jeg i øjeblikket arbejder på, er at øge hastigheden af Active Restore og øge niveauet af systemsikkerhed. Lad os sige, at systemet ikke har brug for hele filen, men kun en del af den. Til dette formål blev der udviklet en anden driver - diskfilterdriveren. Det virker ikke længere på filniveau, men på blokniveau. Funktionsprincippet er det samme: i normal driftstilstand logger driveren simpelthen ændrede blokke på disken, og i gendannelsestilstand forsøger den at læse blokken på egen hånd, og hvis det ikke lykkes, anmoder den tjenesten om at øge prioriteten. Alle andre dele af systemet forbliver dog de samme. For eksempel har en tjeneste på OS-niveau ikke engang mistanke om, at den bliver bedt om at kommunikere med en anden driver, fordi hovedopgaven er at forsyne OS med præcis de data, der er nødvendige for driften. Dette område kræver væsentlige forbedringer, om ikke andet fordi tjenesten endnu ikke ved, hvordan den skal tænke på blokniveau.
Det næste trin besluttede jeg at starte driveren dybere og tidligere, faldende til niveauet for UEFI-drivere og Native Windows-applikationer i stedet for tjenesten. Til dette formål blev den udviklet (eller DXE-driver), som starter og dør, selv før operativsystemet starter. Men vi vil se på "historien" af UEFI-drivere, detaljer om montering og installation samt detaljerne for Windows Native-applikationer i det næste indlæg. Så abonner på vores blog, og i mellemtiden vil jeg forberede en historie om næste fase af arbejdet. Jeg vil blive glad for at se dine kommentarer og råd.
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Har du nogensinde haft situationer, hvor bedring tog ulidelig lang tid:
-
65.1 %Ja 28
-
23.2 %Nr 10
-
11.6 %Tænkte ikke over det 5
43 brugere stemte. 3 brugere undlod at stemme.
Kilde: www.habr.com