Att säkerhetskopiera viktig data är bra. Men tänk om arbetet måste fortsätta direkt och varje minut räknas? Vi på Acronis bestämde oss för att kolla hur möjligt det är att lösa problemet med att starta systemet så snabbt som möjligt. Och det här är det första inlägget i Active Restore-serien, där jag ska berätta hur vi startade projektet tillsammans med Innopolis University, vilken lösning vi hittade och vad vi jobbar med idag. Detaljer finns under snittet.
Hallå! Jag heter Daulet Tumbayev, och idag skulle jag vilja dela med mig av min erfarenhet av att utveckla ett system som påskyndar katastrofåterställning. För att prata om hela utvecklingsvägen för projektet, låt oss börja lite på avstånd. Jag arbetar för närvarande på Acronis, men jag är också utexaminerad från Innopolis University, där jag genomförde masterprogrammet i Software Development Management (känd som MSIT-SE). Innopolis är ett ungt universitet och läroplanen är ännu yngre. Men det bygger på läroplanen från Carnegie Mellon University, vars arbete inkluderar ett sådant ämne som industriella projekt.
Syftet med det industriella projektet är att fördjupa studenten i verklig utveckling och befästa den förvärvade kunskapen i praktiken. För att göra detta samarbetar universitetet med företag som Yandex, Acronis, MTC och dussintals andra (totalt, från och med 2018, hade universitetet 144 partners). I samarbetet erbjuder företag sina arbetsområden till universitetet och studenterna väljer ett av projekten som ligger närmare deras intressen och utbildningsnivå. För bokstavligen två år sedan var jag fortfarande "på andra sidan barrikaderna" och arbetade som student på ett annat Acronis-projekt. Men den här gången blev jag teknisk konsult för studenter på företagets sida och föreslog Active Restore-projektet till Innopolis. Själva idén med Active Restore formulerades av Kernel-teamet på Acronis, men utvecklingen av lösningen började tillsammans med Innopolis University.
Active Restore – varför behövs det?
Traditionellt fungerar katastrofåterställning enligt ett standardschema. Efter problem med din dator går du till webbgränssnittet för något säkerhetskopieringssystem, till exempel Acronis True Image, och klickar på den stora "återställ"-knappen. Därefter måste du vänta N minuter, och först efter det kan du fortsätta arbeta.
Problemet är att detta nummer N, även känt som RTO (återställningstidsobjektiv), den tillåtna återställningstiden, kan vara ganska imponerande, vilket beror på anslutningshastigheten (om återställningen sker från molnet), storleken på din maskins hårddisk och ett antal andra faktorer. Är det möjligt att minska det? Ja, det kan du, för för att kunna återuppta arbetet behöver du inte alltid en full datordiskett. Samma foton och videor påverkar inte enhetens funktion på något sätt och kan dras upp senare i bakgrunden.
Förare behövs...
Operativsystemet förväntar sig att starta med disken helt klar. Därför utför Windows en serie kontroller för att kontrollera diskens integritet. Systemet tillåter inte en normal start om några filer som operativsystemet förväntar sig att hittas saknas eller är skadade. För att lösa detta problem beslutades det att placera de så kallade omdirigeringsfilerna som vi skapade på disken, som ersätter saknade eller skadade filer, men som i själva verket är dummies. Det tar inte lång tid att skapa sådana omdirigerare, eftersom de faktiskt inte har något innehåll.
Ytterligare restaurering sker enligt följande. Genom en bakgrundsprocess, parallellt med driften av operativsystemet, fylls "dummies" med data. Bakgrundsåterställningsprocessen tar hänsyn till diskbelastningen och överskrider inte den inställda gränsen. Däremot kan användaren eller själva operativsystemet plötsligt kräva en fil som ännu inte finns. Det är här det andra återställningsläget kommer in i bilden. Prioriteten för den begärda filen höjs till maximalt, och återställningsprocessen laddar omgående filen till disken. Operativsystemet tar emot den önskade filen, om än med en liten fördröjning.
Så här ser en idealbild ut. Men i den verkliga världen finns det ett stort antal fallgropar och potentiella dödlägen. Tillsammans med Innopolis masterstudenter bestämde vi oss för att utforska detta återhämtningsscenario, utvärdera vinsterna i RTO och förstå om ett sådant tillvägagångssätt är genomförbart? Det fanns ju helt enkelt inga sådana lösningar på marknaden vid den tiden.
Och om jag bestämde mig för att lägga ut servicekomponenten till killarna från Innopolis, så började arbetet inom Acronis på . Detta gjordes av Windows Kernel-teamet. Planen var så här:
- Starta drivrutinen i ett tidigt skede av OS-start,
- Under arbetet, när kommer att vara helt klar, ladda ner tjänsten
- Tjänsten behandlar förarförfrågningar och samordnar sitt fortsatta arbete.
Finesser av förarteknik
Om mina kollegor kommer att prata om tjänsten i ett annat inlägg, kommer vi i den här texten att avslöja krångligheterna med förarutveckling. Den redan utvecklade minifilterdrivrutinen har två driftlägen - när systemet startade i normalt läge och när systemet just har upplevt ett fel och håller på att återställas. Innan användarbibliotek och applikationer laddas, och därmed vår tjänst, beter sig föraren på samma sätt. Han vet inte vilket tillstånd systemet är i just nu. Som ett resultat loggas alla skapa, läsa och skriva och all metadata registreras. Och när tjänsten är online tillhandahåller föraren denna information till tjänsten.
Vid normal start skickar tjänsten en "Slappna av"-signal till föraren så att den "slappnar av" och slutar noggrant att logga all data. I det här fallet går drivrutinen över till att endast logga ändringar på disken och rapporterar dem till tjänsten, som med hjälp av andra Acronis-verktyg upprätthåller diskbackupen i det mest uppdaterade tillståndet på media som anges av användaren. Detta kan vara moln, fjärr, gradvis eller nattlig backup.
Om återställningsläget är aktiverat talar tjänsten om för föraren att den måste fungera i "Återställningsläge". Systemet har precis återhämtat sig från en krasch, och så snart det gör en begäran om att öppna en fil på disken, måste minifiltret avlyssna denna operation, göra denna begäran själv, kontrollera om en sådan fil finns på disken och om den kan öppnas.
Om en fil saknas överför minifiltret denna information till tjänsten, vilket ökar prioritet för filåterställning (hela tiden pågår återställning i bakgrunden). Det visar sig att den här filen helt enkelt hoppar till början av kön. Efter detta återställer tjänsten själv (eller andra Acronis-medel) denna fil och talar om för drivrutinen att allt är ok, nu kan operativsystemet komma åt den och drivrutinen "släpper" den ursprungliga begäran, från systemet till disken.
Om återställning är omöjlig informerar tjänsten föraren om att filen inte finns i säkerhetskopian. Vår minifilterdrivrutin skickar helt enkelt systembegäran vidare och den ursprungliga begäranden (operativsystemet självt eller applikationen) får ett "filen hittades inte"-felet. Detta är dock ganska normalt om filen verkligen inte fanns på disken och i säkerhetskopian.
Självklart kommer operativsystemet att fungera mycket långsammare, eftersom läsning av alla filer eller bibliotek sker i flera steg, eventuellt med tillgång till fjärrresurser. Men användaren kan återgå till arbetet så snart som möjligt medan återhämtning fortfarande pågår.
Behöver lägre, ännu lägre...
Prototypen har bevisat sin funktionalitet. Men vi fann också ett behov av att gå vidare eftersom det i vissa fall fortfarande finns låsningar. Operativsystemet kan till exempel begära olika bibliotek i flera trådar, vilket leder till att vår tjänst loopar tillbaka på sig själv.
Problemet jag för närvarande arbetar med är att öka hastigheten på Active Restore och öka nivån på systemsäkerheten. Låt oss säga att systemet inte behöver hela filen, utan bara en del av den. För detta ändamål utvecklades en annan drivrutin - diskfilterdrivrutinen. Det fungerar inte längre på filnivå, utan på blocknivå. Funktionsprincipen är liknande: i normalt driftläge loggar föraren helt enkelt ändrade block på disken, och i återställningsläge försöker den läsa blocket på egen hand, och om det misslyckas ber den tjänsten att öka prioriteten. Alla andra delar av systemet förblir dock desamma. Till exempel misstänker en tjänst på OS-nivå inte ens att den uppmanas att kommunicera med en annan drivrutin, eftersom huvuduppgiften är att förse OS med exakt de data som är nödvändiga för driften. Detta område kräver betydande förbättringar, om så bara för att tjänsten ännu inte vet hur man tänker på blocknivå.
Nästa steg bestämde jag mig för att lansera drivrutinen djupare och tidigare, sjunkande till nivån för UEFI-drivrutiner och Native Windows-applikationer istället för tjänsten. För detta ändamål utvecklades den (eller DXE-drivrutin), som startar och dör redan innan operativsystemet startar. Men vi kommer att titta på "historiken" för UEFI-drivrutiner, detaljer om montering och installation, samt detaljerna för Windows Native-applikationer i nästa inlägg. Så prenumerera på vår blogg, och under tiden förbereder jag en berättelse om nästa steg i arbetet. Jag blir glad över att se dina kommentarer och råd.
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Har du någonsin haft situationer där återhämtningen tog oerhört lång tid:
-
65.1%Ja 28
-
23.2%Nr 10
-
11.6%Tänkte inte på det 5
43 användare röstade. 3 användare avstod från att rösta.
Källa: will.com