Att säkerhetskopiera viktiga data är bra. Men vad händer om arbetet måste fortsätta omedelbart och varje minut räknas? Vi på Acronis beslutade oss för att undersöka hur möjligt det är att lösa uppgiften med att starta systemet så snabbt som möjligt. Detta är det första inlägget i serien Active Restore, där jag kommer att berätta hur vi påbörjade projektet tillsammans med Innopolis Universitet, vilken lösning vi hittade, och vad vi arbetar med idag. Läs mer under inlägget.
Hej! Jag heter Daulet Tumbaev och idag vill jag dela med mig av min erfarenhet av att utveckla ett system som påskyndar katastrofåterställning. För att berätta hela utvecklingsresan av projektet, låt oss börja lite från början. Just nu arbetar jag på Acronis, men jag är också alumna från Innopolis Universitet, där jag avslutade min magisterutbildning i "Programvaruutvecklingsledning" (känd som MSIT-SE). Innopolis är ett ungt universitet och utbildningen är ännu yngre. Men den är byggd på läroplanerna från Carnegie Mellon University, där det finns ett fokus på industriella projekt.
Målet med det industriella projektet är att fördjupa studenten i verklig utveckling och befästa de kunskaper som erhållits i praktiken. För detta samarbetar universitetet med företag som Yandex, Acronis, MTC och flera dussin andra (totalt hade universitetet 144 partners år 2018). Under samarbetet erbjuder företagen universitetet sina arbetsområden, och studenterna väljer ett av projekten som de tycker är mest intressant och som matchar deras nivå av förberedelse. Precis för två år sedan var jag "på den andra sidan barrikaderna" och arbetade som student på ett annat Acronis-projekt. Men den här gången blev jag teknisk konsult för studenterna från företaget och föreslog projektet Active Restore till Innopolis. Själva idén om Active Restore formulerades av Kernel-teamet på Acronis, men utvecklingen av lösningen inleddes tillsammans med Innopolis Universitet.
Active Restore – varför behövs det?
Traditionellt fungerar katastrofåterställning enligt en standardplan. Efter besvär med datorn går du in i webbgränssnittet för något säkerhetskopieringssystem, till exempel Acronis True Image, och trycker på den stora knappen "återställ". Sedan måste du vänta N minuter, och först efter detta kan du fortsätta arbeta.
Problemet är att detta nummer N, även känt som RTO (recovery time objective), den tillåtna återställningstiden, kan vara ganska betydande och beror på hastigheten på anslutningen (om återställning sker från molnet), storleken på hårddisken på din maskin och en rad andra faktorer. Kan det minskas? Ja, det kan det, eftersom det inte alltid krävs en fullständig disk från datorn för att återuppta driften. Bilder och videor påverkar inte enhetens funktionalitet och kan tas in senare i bakgrunden.
Drivrutin behövs…
Operativsystemet försöker starta med en helt färdig disk. Därför kör Windows ett antal kontroller av diskens integritet. Systemet tillåter inte en normal start om vissa filer som operativsystemet förväntar sig att hitta saknas eller är skadade. För att lösa detta problem beslutades det att lägga till så kallade omdirigeringsfiler på disken, som ersätter saknade eller skadade filer men i själva verket är tomma. Att skapa sådana omdirigerare tar inte lång tid, eftersom de i grunden inte har något innehåll.
Återställningen sker på följande sätt. Genom en bakgrundsprocess, parallellt med operativsystemets arbete, fylls 'de tomma filerna' med data. Bakgrundsåterställningsprocessen tar hänsyn till diskbelastningen och överskrider inte den angivna gränsen. Men användaren eller operativsystemet kan plötsligt begära en fil som ännu inte finns. Här träder den andra återställningsläget in. Prioriteten för den begärda filen höjs till max, och återställningsprocessen laddar skyndsamt filen till disken. Operativsystemet får den behövda filen, även om med en liten fördröjning.
Så här ser den idealiska bilden ut. Men i verkligheten finns det en mängd fallgropar och potentiella dödlägen. Tillsammans med masterstudenterna från Innopolis beslutade vi att undersöka detta återställningssätt, bedöma vinsten i RTO och förstå om en sådan metod är genomförbar? För sådana lösningar fanns det helt enkelt inte på marknaden vid den tiden.
Och om jag bestämde mig för att överlåta den servicekomponenten till killarna från Innopolis, så inleddes det arbete inuti Acronis med . Detta arbete utfördes av Windows Kernel-teamet. Planen var att
- starta drivrutinen i ett tidigt skede av OS-starten,
- under drift, när är helt klart, laddas tjänsten.
- Tjänsten hanterar drivrutinsförfrågningar och koordinerar dess fortsatta arbete.
Nycklar inom drivrutinsutveckling
Om mina kollegor kommer att berätta om tjänsten i ett annat inlägg, så kommer vi i denna text att avslöja detaljerna om drivrutinsutvecklingen. En redan utvecklad minifiltrdrivrutin har två arbetslägen – när systemet startat normalt och när systemet just har genomgått ett fel och återställs. Innan inläsningen av användarbibliotek och program, och därmed vår tjänst, börjar, beter sig drivrutinen på samma sätt. Den vet inte i vilket tillstånd systemet befinner sig. Som ett resultat registreras varje create, read och write och alla metadata dokumenteras. När tjänsten är online, tillhandahåller drivrutinen denna information till tjänsten.
Vid en vanlig start skickar tjänsten en signal till drivrutinen att ”slappna av”, så att den “slappnar av” och slutar noggrant registrera all data. I detta fall övergår drivrutinen till att registrera endast ändringar på disken och rapporterar om dem till tjänsten, som med hjälp av andra Acronis-verktyg upprätthåller en säkerhetskopia av disken i maximalt aktuellt tillstånd på den enhet som användaren har definierat. Detta kan vara moln-, fjärr-, stegvis eller nattlig säkerhetskopiering.
Om återställningsläget aktiveras, meddelar tjänsten drivrutinen att den behöver arbeta i ”Recovery”-läge. Systemet har just återställts efter ett fel, och så snart det gör en begäran om att öppna en fil på disken, måste minifiltern fånga denna operation, göra denna begäran, kontrollera om en sådan fil finns på disken och om den kan öppnas.
Om en fil saknas, vidarebefordrar mini-filterinformationen detta till tjänsten, som ökar prioriteten för filåterställningen (under hela denna tid pågår återställningen i bakgrunden). Det innebär att denna fil helt enkelt hoppar fram till början av kön. Efter detta återställer tjänsten filen själv (eller med andra Acronis-verktyg) och informerar drivrutinen att allt är okej, nu kan operativsystemet få åtkomst till den, och drivrutinen "släpper" den ursprungliga begäran från systemet till disken.
Om återställningen är omöjlig meddelar tjänsten drivrutinen att filen inte finns i säkerhetskopian. Vår mini-filterdrivrutin vidarebefordrar helt enkelt systembegäran vidare, och den ursprungliga begärande (själva OS:et eller applikationen) får ett felmeddelande "fil inte hittad". Men detta är helt normalt om filen verkligen inte fanns på disken eller i säkerhetskopian.
Självklart kommer operativsystemet att fungera mycket långsammare, eftersom läsning av vilken fil som helst eller bibliotek sker i flera steg, och eventuellt med åtkomst till externa resurser. Men användaren kan ändå börja arbeta på kort tid, medan återställningen fortfarande pågår.
Måste gå ner, ännu lägre…
Prototypen har bevisat sin funktionalitet. Men vi har också upptäckt behovet av att gå vidare, eftersom dödlägen fortfarande inträffar i vissa fall. Till exempel kan operativsystemet begära olika bibliotek i flera trådar, vilket leder till att vår tjänst låser sig på sig själv.
Problemet jag arbetar med just nu är att öka hastigheten på Active Restore och förbättra systemets säkerhetsnivå. Anta att systemet inte behöver hela filen, utan endast en del av den. För detta utvecklades en annan drivrutin - en filterdrivrutin för disken. Den arbetar inte längre på filnivå utan på blocknivå. Arbetsprincipen är liknande: i normalt läge protokollför drivrutinen helt enkelt de ändrade blocken på disken, medan den i återställningsläge försöker läsa blocket själv och vid misslyckande begär att få prioriteringen höjd. Samtidigt förblir alla andra delar av systemet oförändrade. Till exempel misstänker inte operativsystemets tjänst ens att den ombeds interagera med en annan drivrutin, eftersom huvuduppgiften är att tillhandahålla det data som operativsystemet behöver för att fungera. Detta område kräver omfattande förbättringar åtminstone eftersom tjänsten ännu inte kan tänka på blocknivå.
Som nästa steg beslöt jag att starta drivrutinen djupare och tidigare, på UEFI-drivrutinsnivå och Native Windows-applikationer istället för tjänsten. För detta utvecklades (eller DXE-drivrutin), som startar och dör innan operativsystemet ens startar. Men "historien" om UEFI-drivrutiner, detaljer om skapande och installation, samt specifika egenskaper hos Windows Native-applikationer, kommer vi att gå igenom i nästa inlägg. Så följ vår blogg, medan jag förbereder berättelsen om nästa arbetssteg. Jag ser fram emot era kommentarer och råd.
Endast registrerade användare kan delta i omröstningen. , tack.
Har du någonsin varit med om situationer där återställningen tog plågsamt lång tid:
65.1%Ja28
23.2%Nej10
11.6%Har inte tänkt på det5
43 användare röstade. 3 användare avstod.
Källa: habr.com
