Een back-up maken van belangrijke gegevens is een goede zaak. Maar wat als het werk meteen door moet en elke minuut telt? Wij bij Acronis hebben besloten om na te gaan hoe mogelijk het probleem van het zo snel mogelijk opstarten van het systeem kan worden opgelost. En dit is het eerste bericht in de Active Restore-serie, waarin ik je zal vertellen hoe we samen met Innopolis University het project zijn gestart, welke oplossing we hebben gevonden en waar we vandaag aan werken. Details staan onder de snit.
Hallo! Mijn naam is Daulet Tumbayev en vandaag wil ik graag mijn ervaring met u delen bij het ontwikkelen van een systeem dat het herstel na een ramp versnelt. Om over het hele ontwikkelingstraject van het project te praten, laten we een beetje van ver beginnen. Momenteel werk ik bij Acronis, maar ik ben ook afgestudeerd aan de Innopolis University, waar ik de masteropleiding Software Development Management (bekend als MSIT-SE) heb afgerond. Innopolis is een jonge universiteit en het curriculum is nog jonger. Maar het is gebaseerd op het curriculum van de Carnegie Mellon Universiteit, wiens werk een onderwerp als industriële projecten omvat.
Het doel van het industriële project is om de student onder te dompelen in echte ontwikkeling en de verworven kennis in de praktijk te consolideren. Om dit te doen werkt de universiteit samen met bedrijven als Yandex, Acronis, MTC en tientallen anderen (in totaal had de universiteit vanaf 2018 144 partners). In het kader van de samenwerking bieden bedrijven hun werkplekken aan de universiteit aan en kiezen studenten een van de projecten die dichter bij hun interesses en opleidingsniveau ligt. Letterlijk twee jaar geleden stond ik nog “aan de andere kant van de barricades” en werkte ik als student aan een ander Acronis-project. Maar deze keer werd ik technisch adviseur voor studenten aan de kant van het bedrijf en stelde ik het Active Restore-project voor aan Innopolis. Het idee zelf van Active Restore werd geformuleerd door het Kernel-team van Acronis, maar de ontwikkeling van de oplossing begon samen met Innopolis University.
Actief herstel – waarom is dit nodig?
Traditioneel werkt disaster recovery volgens een standaardschema. Na problemen met uw computer gaat u naar de webinterface van een of ander back-upsysteem, bijvoorbeeld Acronis True Image, en klikt u op de grote knop "Herstellen". Vervolgens moet u N minuten wachten, en pas daarna kunt u verder werken.
Het probleem is dat dit getal N, ook bekend als RTO (recovery time objective), de toegestane hersteltijd, behoorlijk indrukwekkend kan zijn, wat afhangt van de verbindingssnelheid (als het herstel vanuit de cloud plaatsvindt), de grootte van de harde schijf van uw machine en nog een aantal andere factoren. Is het mogelijk om het te verminderen? Ja dat kan, want om het werk te hervatten heb je niet altijd een volle computerschijf nodig. Dezelfde foto's en video's hebben op geen enkele manier invloed op de functionaliteit van het apparaat en kunnen later op de achtergrond worden weergegeven.
Chauffeur nodig...
Het besturingssysteem verwacht te starten met de schijf volledig gereed. Daarom voert Windows een reeks controles uit om de integriteit van de schijf te controleren. Het systeem staat een normale opstart niet toe als bepaalde bestanden waarvan het besturingssysteem verwacht dat ze worden gevonden, ontbreken of beschadigd zijn. Om dit probleem op te lossen, werd besloten om de zogenaamde redirector-bestanden die we hadden gemaakt op de schijf te plaatsen, die ontbrekende of beschadigde bestanden vervangen, maar in feite dummies zijn. Het duurt niet lang om dergelijke redirectors te maken, omdat ze eigenlijk geen inhoud hebben.
Verder herstel vindt als volgt plaats. Door een achtergrondproces, parallel aan de werking van het besturingssysteem, worden ‘dummies’ gevuld met gegevens. Het herstelproces op de achtergrond houdt rekening met de schijfbelasting en overschrijdt de ingestelde limiet niet. Het kan echter voorkomen dat de gebruiker of het besturingssysteem zelf plotseling een bestand nodig heeft dat nog niet bestaat. Dit is waar de tweede herstelmodus in het spel komt. De prioriteit van het opgevraagde bestand wordt verhoogd naar het maximum en het herstelproces laadt het bestand dringend op schijf. Het besturingssysteem ontvangt het vereiste bestand, zij het met een kleine vertraging.
Zo ziet een ideaal plaatje eruit. In de echte wereld zijn er echter een groot aantal valkuilen en potentiële impasses. Samen met de masterstudenten van Innopolis hebben we besloten dit herstelscenario te verkennen, de winst in RTO te evalueren en te begrijpen of een dergelijke aanpak haalbaar is? Dergelijke oplossingen waren op dat moment immers eenvoudigweg niet op de markt.
En als ik besloot de servicecomponent uit te besteden aan de jongens van Innopolis, begon het werk binnen Acronis . Dit werd gedaan door het Windows Kernel-team. Het plan was als volgt:
- Start het stuurprogramma in een vroeg stadium van het opstarten van het besturingssysteem,
- Tijdens het werk, wanneer zal helemaal klaar zijn, download de service
- De dienst verwerkt de chauffeursaanvragen en coördineert de verdere werkzaamheden.
Subtiliteiten van rijtechniek
Als mijn collega's in een andere post over de service zullen praten, dan zullen we in deze tekst de fijne kneepjes van de ontwikkeling van stuurprogramma's onthullen. De reeds ontwikkelde minifilterdriver heeft twee bedrijfsmodi: wanneer het systeem in de normale modus is gestart en wanneer het systeem zojuist een storing heeft ondervonden en wordt hersteld. Voordat gebruikersbibliotheken en applicaties, en dus onze service, worden geladen, gedraagt het stuurprogramma zich hetzelfde. Hij weet niet in welke staat het systeem zich momenteel bevindt. Als gevolg hiervan wordt elke creatie, lees- en schrijfactie vastgelegd en worden alle metadata vastgelegd. En wanneer de dienst online is, geeft de chauffeur deze informatie door aan de dienst.
Bij een normale start stuurt de dienst een ‘Relax’-signaal naar de bestuurder, zodat deze ‘ontspant’ en stopt met het nauwgezet loggen van alle gegevens. In dit geval schakelt het stuurprogramma over op het registreren van alleen wijzigingen op de schijf en rapporteert deze aan de service, die, met behulp van andere Acronis-tools, de schijfback-up in de meest up-to-date staat houdt op de door de gebruiker opgegeven media. Dit kan een cloud-, externe, geleidelijke of nachtelijke back-up zijn.
Als de herstelmodus is ingeschakeld, vertelt de service de bestuurder dat deze in de herstelmodus moet werken. Het systeem is zojuist hersteld van een crash en zodra het een verzoek doet om een bestand op de schijf te openen, moet het minifilter deze bewerking onderscheppen, dit verzoek zelf doen, controleren of een dergelijk bestand op de schijf bestaat en of het kan worden geopend.
Als een bestand ontbreekt, verzendt het minifilter deze informatie naar de service, waardoor de prioriteit van het bestandsherstel toeneemt (al die tijd vindt het herstel op de achtergrond plaats). Het blijkt dat dit bestand eenvoudigweg naar het begin van de wachtrij springt. Hierna herstelt de service zelf (of andere middelen van Acronis) dit bestand en vertelt de bestuurder dat alles in orde is, nu heeft het besturingssysteem er toegang toe en geeft de bestuurder het oorspronkelijke verzoek "vrij" van het systeem naar de schijf.
Als herstel onmogelijk is, informeert de service de bestuurder dat het bestand niet in de back-up staat. Ons minifilterstuurprogramma geeft het systeemverzoek eenvoudigweg door en de oorspronkelijke aanvrager (het besturingssysteem zelf of de applicatie) krijgt de foutmelding 'bestand niet gevonden'. Dit is echter heel normaal als het bestand zich echt niet op de schijf en in de back-up bevond.
Natuurlijk zal het besturingssysteem veel langzamer werken, omdat het lezen van een bestand of bibliotheek in verschillende fasen plaatsvindt, mogelijk met toegang tot externe bronnen. Maar de gebruiker kan zo snel mogelijk weer aan het werk, terwijl het herstel nog plaatsvindt.
Lager nodig, nog lager...
Het prototype heeft zijn functionaliteit bewezen. Maar we vonden ook de noodzaak om verder te gaan, omdat er in sommige gevallen nog steeds sprake is van een impasse. Het besturingssysteem kan bijvoorbeeld verschillende bibliotheken in verschillende threads opvragen, wat ertoe leidt dat onze service op zichzelf terugkeert.
Het probleem waar ik momenteel aan werk is het verhogen van de snelheid van Active Restore en het verhogen van het niveau van systeembeveiliging. Laten we zeggen dat het systeem niet het hele bestand nodig heeft, maar slechts een deel ervan. Voor dit doel is een ander stuurprogramma ontwikkeld: het schijffilterstuurprogramma. Het werkt niet meer op bestandsniveau, maar op blokniveau. Het werkingsprincipe is vergelijkbaar: in de normale werkingsmodus registreert de bestuurder eenvoudigweg gewijzigde blokken op de schijf, en in de herstelmodus probeert hij het blok zelf te lezen en als dit niet lukt, vraagt hij de service om de prioriteit te verhogen. Alle andere delen van het systeem blijven echter hetzelfde. Een service op besturingssysteemniveau vermoedt bijvoorbeeld niet eens dat hem wordt gevraagd om met een ander stuurprogramma te communiceren, omdat de hoofdtaak erin bestaat het besturingssysteem te voorzien van precies de gegevens die nodig zijn voor de werking. Op dit vlak zijn flinke verbeteringen nodig, al was het maar omdat de dienst nog niet op blokniveau weet te denken.
Bij de volgende stap besloot ik de driver dieper en eerder te lanceren, afdalend naar het niveau van UEFI-drivers en Native Windows-applicaties in plaats van de service. Voor dit doel is het ontwikkeld (of DXE-stuurprogramma), dat start en sterft zelfs voordat het besturingssysteem start. Maar we zullen in het volgende bericht kijken naar de ‘geschiedenis’ van UEFI-stuurprogramma’s, details over montage en installatie, evenals de specifieke kenmerken van Windows Native-applicaties. Dus abonneer je op onze blog en in de tussentijd bereid ik een verhaal voor over de volgende fase van het werk. Ik zal blij zijn om uw opmerkingen en advies te zien.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Heeft u ooit situaties gehad waarin het herstel ondraaglijk lang duurde:
-
65.1%Ja28
-
23.2%Geen10
-
11.6%Ik heb er niet over nagedacht5
43 gebruikers hebben gestemd. 3 gebruikers onthielden zich van stemming.
Bron: www.habr.com