Back-ups van belangrijke data zijn cruciaal. Maar wat als je meteen verder moet met je werk en elke minuut telt? Bij Acronis hebben we besloten te onderzoeken hoe we de snelste systeemherstart mogelijk kunnen maken. Dit is de eerste post in de Active Restore-serie, waarin ik uitleg hoe we samen met de Innopolis Universiteit aan dit project zijn begonnen, welke oplossing we hebben gevonden en waaraan we vandaag de dag werken. Meer details – onder de kat.
Hallo! Mijn naam is Daullet Tumbaev en vandaag wil ik graag mijn ervaring delen over de ontwikkeling van een systeem dat het herstel na een storing versnelt. Om het hele ontwikkelingspad van het project te beschrijven, beginnen we iets verder terug. Momenteel werk ik bij Acronis, maar ik ben ook afgestudeerd aan de Innopolis Universiteit, waar ik de Masteropleiding "Software Development Management" (bekend als MSIT-SE) heb gevolgd. Innopolis is een jonge universiteit en het curriculum is zelfs nog jonger. Maar het is wel gebouwd op de leerplannen van de Carnegie Mellon Universiteit, waar ook een onderwerp als industriële projecten aan bod komt.
Het doel van het industriële project is om studenten onder te dompelen in echte ontwikkeling en de opgedane kennis in de praktijk toe te passen. Hiervoor werkt de universiteit samen met bedrijven zoals Yandex, Acronis, MTC en tientallen anderen (in totaal had de universiteit in 2018 144 partners). Gedurende deze samenwerking bieden bedrijven de universiteit hun werkgebieden aan, en mogen studenten een van de projecten kiezen dat het beste aansluit bij hun interesses en voorbereiding. Slechts twee jaar geleden stond ik nog “aan de andere kant van de barricade” en werkte ik als student aan een ander Acronis-project. Maar deze keer werd ik technische consultant voor de studenten vanuit het bedrijf en stelde ik het Active Restore-project voor. Het idee achter Active Restore is geformuleerd door het Kernel-team binnen Acronis, maar de ontwikkeling van de oplossing is begonnen in samenwerking met de Innopolis Universiteit.
Active Restore – waarom is dit nodig?
Traditioneel werkt noodherstel volgens een standaardprocedure. Na problemen met de computer ga je naar de webinterface van een back-upsysteem, bijvoorbeeld Acronis True Image, en druk je op de grote knop "herstellen". Daarna moet je N minuten wachten, en pas dan kun je je werk weer voortzetten.
Het probleem is dat dit aantal N, ook bekend als RTO (recovery time objective), het toegestane hersteltempo, behoorlijk indrukwekkend kan zijn. Dit hangt af van de snelheid van de verbinding (als het herstel vanuit de cloud plaatsvindt), van de grootte van de harde schijf van uw machine en een aantal andere factoren. Is het mogelijk om het te verminderen? Ja, dat kan, want om weer aan de slag te gaan, is het niet altijd nodig om de volledige schijf van de computer te hebben. Foto's en video's hebben geen invloed op de functionaliteit van het apparaat en kunnen later op de achtergrond worden opgehaald.
Driver nodig…
Het besturingssysteem moet opstarten met een volledig beschikbare schijf. Daarom voert Windows een aantal controles uit op de schijfintegriteit. Het systeem laat geen normale opstart toe als bepaalde bestanden ontbreken of beschadigd zijn, die het besturingssysteem verwacht te vinden. Voor het oplossen van dit probleem hebben we besloten om zogenaamde redirect-bestanden op de schijf te plaatsen, die de ontbrekende of beschadigde bestanden vervangen, maar in feite lege bestanden zijn. Het aanmaken van zulke redirect-bestanden kost niet veel tijd, aangezien ze feitelijk geen inhoud hebben.
Vervolgens verloopt het herstel als volgt. Een achtergrondproces vult parallel aan het werk van het besturingssysteem de "lege" bestanden met gegevens. Het proces van achtergrondherstel houdt rekening met de belasting op de schijf en overschrijdt de ingestelde limiet niet. Echter, de gebruiker of het besturingssysteem zelf kan plotseling een bestand opvragen dat nog niet beschikbaar is. Hier komt de tweede herstelmodus in beeld. De prioriteit van het opgevraagde bestand wordt verhoogd tot het maximum en het herstelproces laadt het bestand urgent op de schijf. Het besturingssysteem ontvangt het benodigde bestand, zij het met een kleine vertraging.
Zo ziet het ideale scenario eruit. Maar in de echte wereld zijn er talloze valkuilen en potentiële deadlocks. Samen met de masterstudenten van Innopolis hebben we besloten dit herstelscenario te onderzoeken, de winst in RTO te evalueren en te begrijpen of zo'n aanpak haalbaar is? Want dergelijke oplossingen waren op dat moment simpelweg niet op de markt.
En terwijl ik het serviceaspect aan de jongens van Innopolis heb toevertrouwd, begon binnen Acronis het werk aan Dit werd opgepakt door het Windows Kernel-team. Het plan was als volgt:
- De driver vroeg tijdens een vroeg stadium van het opstarten van het besturingssysteem,
- Tijdens de werking, wanneer volledig gereed is, wordt de service geladen.
- De service verwerkt verzoeken van de driver en coördineert zijn verdere werking.
De fijnere details van driverontwikkeling
Als mijn collega’s over de service in een andere post vertellen, zullen we in deze tekst de nuances van driverontwikkeling onthullen. De reeds ontwikkelde mini-filter driver heeft twee werkmodi – wanneer het systeem op normale wijze is opgestart, en wanneer het systeem net een storing heeft meegemaakt en hersteld wordt. Voordat de gebruikersbibliotheken en applicaties worden geladen, en dus ook onze service, gedraagt de driver zich hetzelfde. Hij weet niet in welke toestand het systeem zich momenteel bevindt. Als gevolg daarvan worden elke create, read en write geprotocolleerd, alle metadata worden vastgelegd. En zodra de service online is, biedt de driver deze informatie aan de service aan.
Bij een normale opstart geeft de service de driver een signaal “Relax”, zodat hij “ontspant” en stopt met nauwgezet alle gegevens te protocoleren. In dit geval schakelt de driver over op het registreren van alleen wijzigingen op de schijf en rapporteert deze aan de service, die met behulp van andere Acronis-tools de diskbackup in maximaal actuele staat houdt op het medium dat door de gebruiker is bepaald. Dit kan cloud, remote, geleidelijk of nachtelijke back-up zijn.
Als de herstelmodus wordt ingeschakeld, meldt de service de driver dat hij in de “Recovery”-modus moet werken. Het systeem is net hersteld na een storing, en zodra het een verzoek doet om een bestand op de schijf te openen, moet de mini-filter deze bewerking onderscheppen, het verzoek zelf doen, controleren of zo'n bestand op de schijf bestaat en of het geopend kan worden.
Als het bestand ontbreekt, geeft de minifilter deze informatie door aan de service, die de prioriteit voor het herstellen van het bestand verhoogt (terwijl de herstelprocedure op de achtergrond doorgaat). Het lijkt erop dat dit bestand gewoon naar het begin van de wachtrij springt. Daarna herstelt de service zelf (of via andere middelen van Acronis) dit bestand en meldt aan de driver dat alles in orde is, zodat het besturingssysteem toegang kan krijgen tot het bestand en de driver de originele aanvraag “loslaat”, van het systeem naar de schijf.
Als herstel onmogelijk is, meldt de service aan de driver dat het bestand ook niet in de backup zit. Onze minifilterdriver laat de systeemaanvraag gewoon verdergaan, en de originele aanvrager (het besturingssysteem of een applicatie) ontvangt de foutmelding “bestand niet gevonden”. Dit is echter volkomen normaal als het bestand inderdaad niet op de schijf of in de backup stond.
Natuurlijk zal het besturingssysteem veel trager werken, omdat het lezen van elk bestand of bibliotheek in meerdere stappen gebeurt, mogelijk met toegang tot externe bronnen. Maar de gebruiker kan in de kortst mogelijke tijd aan de slag, terwijl het herstel nog steeds plaatsvindt.
Moet lager, nog lager…
Het prototype heeft zijn werking bewezen. Maar we hebben ook de behoefte ontdekt om verder te gaan, omdat er nog steeds deadlocks optreden in sommige gevallen. Bijvoorbeeld, het besturingssysteem kan verschillende bibliotheken in meerdere threads aanvragen, wat leidt tot een vastloper van onze service op zichzelf.
Het probleem waar ik momenteel aan werk, is het verhogen van de snelheid van Active Restore en het verbeteren van de beveiliging van het systeem. Stel dat het systeem niet het volledige bestand nodig heeft, maar slechts een deel ervan. Hiervoor is er nog een stuurprogramma ontwikkeld - een schijffilterdriver. Dit werkt niet op bestandsniveau, maar op blokniveau. Het werkprincipe is vergelijkbaar: in de normale werking registreert de driver gewoon de gewijzigde blokken op de schijf, en in de herstelmodus probeert hij zelfstandig een blok te lezen; als dat niet lukt, vraagt hij de service om prioriteit te verhogen. Ondertussen blijven alle andere delen van het systeem hetzelfde. Bijvoorbeeld, de OS-niveau service vermoedt niet eens dat het met een andere driver communiceert, omdat de belangrijkste taak is om de OS precies die gegevens te bieden die nodig zijn voor het functioneren. Dit gebied vereist aanzienlijke verbeteringen, niet in de laatste plaats omdat de service nog niet in staat is om op blokniveau na te denken.
De volgende stap die ik besloot te zetten, was om de driver dieper en eerder te starten, op het niveau van UEFI-stuurprogramma's en Native Windows-applicaties in plaats van de service. Hiervoor is er ontwikkeld (of DXE-driver), die opstart en afsterft voordat het OS begint. Maar we zullen de 'geschiedenis' van UEFI-stuurprogramma's, details over de bouw en installatie, evenals de specifieke kenmerken van Windows Native-applicaties, in de volgende post bekijken. Dus abonneer je op onze blog, terwijl ik het verhaal over de volgende fase van de werkzaamheden voorbereid. Ik kijk uit naar je opmerkingen en adviezen.
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Heb je situaties meegemaakt waarbij het herstel ellendig lang duurde:
65.1%Ja28
23.2%Nee10
11.6%Niet erover nagedacht
43 gebruikers hebben gestemd. 3 gebruikers hebben zich onthouden.
Bron: habr.com
