Oluliste andmete varundamine on hea. Kuid mis siis, kui töö tuleb jätkata kohe ning iga minut loeb? Me Acronises otsustasime uurida, kuivõrd kiiresti saab süsteemi taas käivitada. See on esimene postitus Active Restore'i seeriast, kus jagan, kuidas me projekti koos Innopolise Ülikooliga alustasime, millise lahenduse leidsime ja millega me praegu tegeleme. Üksikasjad on allpool.
Tere! Minu nimi on Daulat Tumbaev ja täna tahan jagada teiega oma kogemust süsteemi arendamisest, mis kiirendab hädaolukorra taastamist. Projekti arengu tervikpildi selgitamiseks alustame natuke kaugemalt. Praegu töötan Acronises, kuid olen ka Innopolise Ülikooli vilistlane, mille lõpetasin magistriõppes "Tarkvara arenduse juhtimine" (tuntud kui MSIT-SE). Innopolis on noor ülikool ja õppekava veel noorem. Kuid see on üles ehitatud Carnegie Melloni Ülikooli õppeplaanide alusel, millel on selline teema nagu tööstusprojektid.
Tööstusprojekti eesmärk on viia üliõpilane tõelisse arendusse ja kinnistada saadud teadmised praktikas. Selleks teeb ülikool koostööd selliste ettevõtetega nagu Yandex, Acronis, MTC ja veel kümnete teistega (kokku oli 2018. aasta seisuga ülikoolil 144 partnerit). Koostöö käigus pakuvad ettevõtted ülikoolile oma töövaldkondi, mille seast üliõpilased valivad ühe projekti, mis on neile huvitavam vastavalt nende huvidele ja ettevalmistusele. Alles kaks aastat tagasi olin ma veel "barjääri teisel pool" ja töötasin tudengina Acronise juures teise projekti kallal. Kuid seekord sain ma ettevõtte poolt üliõpilaste tehniliseks nõustajaks ning pakkusin Innopolis ülikoolile projekti Active Restore. Idee Active Restore'ist pärineb Acronise Kernel meeskonnalt, kuid lahenduse arendamine algas koostöös Innopolis ülikooliga.
Active Restore – miks see vajalik on?
Traditsiooniline hädaolukorra taastamine toimib standardse skeemi järgi. Pärast arvutiga tekkivaid probleeme sisenete mõne varundussüsteemi veebiliidesesse, näiteks Acronis True Image, ja vajutate suurt nuppu "taasta". Seejärel tuleb oodata N minutit ja alles siis saate jätkata tööd.
Probleem seisneb selles, et see number N, mida tuntakse ka kui RTO (recovery time objective), taastumise sihtaja, võib olla üsna suur, sõltudes ühenduse kiirusest (kui taastamine toimub pilvest), teie masina kõvaketta mahust ja mitmest muust tegurist. Kas seda on võimalik vähendada? Jah, see on võimalik, sest töö jätkamiseks ei ole alati vajalik kogu arvuti kettaruum. Näiteks fotod ja videod ei mõjuta seadme funktsionaalsust ja need saab hiljem taustal üles laadida.
Driver needed…
Operatsioonisüsteem eeldab, et käivitamiseks on täielikult valmis ketas. Seetõttu viib Windows läbi mitmeid ketta terviklikkuse kontrolle. Süsteem ei luba normaalset käivitamist, kui puuduvad või on kahjustatud teatud failid, mida OS ootab. Selle probleemi lahendamiseks on otsustatud ketta peale paigutada meie loodud nn suunamisfailid, mis asendavad puuduvad või kahjustatud failid, kuid on tegelikult tühjad. Selliste suunajate loomine ei võta kaua aega, kuna neil ei ole sisuliselt mingit sisu.
Edasi taastamine toimub järgmiselt. Taustprotsessis, paralleelselt operatsioonisüsteemi tööga, täidetakse „tühikud” andmetega. Tausttaastamise protsess arvestab ketta koormust ega ületa seadistatud limiiti. Kuid kasutaja või ise operatsioonisüsteem võib äkitselt nõuda faili, mida veel ei ole. Siin tuleb mängu teine taastamisrežiim. Nõutud failile antakse maksimaalne prioriteet ja taastamisprotsess laadib faili kiiresti kettale. Operatsioonisüsteem saab vajaliku faili, kuigi väikese viivitusega.
Nii näeb ideaalne pilt välja. Kuid tõelises maailmas on palju takistusi ja potentsiaalseid ummikseid. Koos Innopolis magistrantidega otsustasime uurida seda taastamisstsenaariumi, hinnata RTO kasu ja mõista, kas selline lähenemine on teostatav? Sest sarnaseid lahendusi turul lihtsalt ei olnud tol hetkel.
Ja kui otsustasin, et teenusekomponendi annan Innopolis poiste hoolde, siis Acronise sees algas töö . Sellega tegeleb Windows Kernel'i meeskond. Plaan oli järgmine:
- Käivitada draiver operatsioonisüsteemi varajases käivitamisfaasis,
- Töötamise ajal, kui on täielikult valmis, laadida teenus,
- Teenuse kaudu töödeldakse draiveri taotlusi ja koordineeritakse selle edasine töö.
Draiverite arenduse nüansid
Kui minu kolleegid räägivad teenusest teises postituses, siis selles tekstis avame draiveri arendamise nüansid. Juba arendatud mini-filtri draiveril on kaks töörežiimi – kui süsteem on käivitatud normaalses režiimis ja kui süsteem on just kogenud tõrget ning toimub selle taastamine. Enne, kui kasutajakogumikud ja rakendused, sealhulgas meie teenus, laaditakse, käitub draiver ühtlaselt. Ta ei tea, millises olekus süsteem praegu on. Selle tulemusena protokollitakse iga create, read ja write ning kõik metaandmed fikseeritakse. Kui teenus on online, annab draiver selle teabe teenusele.
Tavalise käivitamise korral edastab teenus draiverile signaali "Relax", et ta "rahuneks" ja lõpetaks kõikide andmete põhjaliku protokollimise. Sel juhul läheb draiver üle vaid muudatuste protokollimisele kettal ja teavitab sellest teenust, mis teiste Acronise tööriistade abil säilitab ketta varukoopia maksimaalselt värskena vastavalt kasutaja määratud salvestamiseks. See võib olla pilve-, kaug- või järkjärguline varundamine, samuti öine varundamine.
Kui taastamisrežiim aktiveeritakse, teavitab teenus draiverit, et tal on vaja töötada "Recovery" režiimis. Süsteem on just hiljuti taastunud ootamatust katkestusest, ja niipea, kui see esitab päringu faili avamiseks kettal, peab mini-filter selle toimingu kinni püüdma, tegema selle päringu ise, kontrollima, kas selline fail on kettal olemas ja kas seda on võimalik avada.
Kui faili pole olemas, edastab mini-filtriteenus selle teabe teenusele, mis suurendab faili taastamise prioriteeti (kogu selle aja jooksul toimub taustal taastamine). Tulemuseks on see, et see fail hüppab lihtsalt järjekorra etteotsa. Pärast seda taastab teenus ise (või Acronise kaudu muude abinõudega) selle faili ja teada annab draiverile, et kõik on korras, nüüd saab operatsioonisüsteem sellega ühendust võtta ja draiver "vabastab" originaalse päringu süsteemist kettale.
Kui taastamine ei õnnestu, teavitab teenus draiverit, et faili ei leidu ka varukoopias. Meie mini-filtriteenus lihtsalt suunab süsteemipäringu edasi ja originaalne pärija (isegi operatsioonisüsteem või rakendus) saab veateate "fail ei leitud". Siiski on see täiesti normaalne, kui faili tegelikult kettal ja varukoopias ei olnud.
Muidugi töötab operatsioonisüsteem tunduvalt aeglasemalt, kuna iga faili või teegiga töötamise protsess toimub mitmes etapis, mis võib hõlmata ligipääsu kaugressurssidele. Kuid kasutaja saab töötamisega alustada lühikese aja jooksul, kuni taastamine jätkub.
Peab olema madalam, veel madalam…
Prototüüp on oma töövõimet tõestanud. Siiski oleme avastanud vajaduse edasi liikuda, kuna mõnes olukorras esinevad endiselt ummistused. Näiteks võib operatsioonisüsteem nõuda erinevaid teeke mitmesugustes voogudes, mis toob kaasa meie teenuse enda peale ummistumise.
Probleem, millega ma hetkel töötan, on Active Restore kiirus ja süsteemi turvalisuse tase. Oletame, et süsteemile ei ole vajalik tervet faili, vaid vaid selle osa. Selleks on arendatud veel üks draiver - kettahõivefilter. See toimib nüüd mitte failitasemel, vaid plokkide tasemel. Töö põhimõte on sarnane: normaalses töös režiimis protokollib draiver lihtsalt ketta muudetud plokid, aga taastamisrežiimis üritab lugeda plokki iseseisvalt ja juhul, kui see ebaõnnestub, küsib teenuselt prioriteedi tõstmist. Samal ajal jäävad kõik muud süsteemi osad muutumatuks. Näiteks ei kahtlusta OS-i tase isegi, et talle pakutakse suhtlemist teise draiveriga, kuna peamine ülesanne on pakkuda OS-ile vaid neid andmeid, mis on vajalikud selle toimimiseks. See suund vajab olulisi täiustusi, vähemalt seetõttu, et teenus ei oska veel plokkide tasemel mõelda.
Järgmiseks sammuks otsustasin muuta draiveri käivitamise sügavamaks ja varasemaks, laskudes UEFI draiverite ja Native Windows rakenduste tasemele hoopis teenuse asemel. Selleks on arendatud (või DXE draiver), mis käivitub ja sureb enne, kui OPS käivitub. Kuid UEFI draiverite „ajalugu“, koos kogumise ja installimise üksikasjadega, samuti Windowsi Native rakenduste spetsiifilisusega, käsitleme järgmises postituses. Seega liituge meie blogiga, samas kui ma valmistan ette järgmise tööetapi jutustust. Ootan teie kommentaare ja nõuandeid.
Ainult registreeritud kasutajad saavad küsitluses osaleda. , palun.
Kas olete kunagi kogenud olukordi, kus taastamine kestis piinavalt kaua:
65.1%Jah28
23.2%Ei
11.6%Ei ole mõelnud
Hääletas 43 kasutajat. Erakonnast jäi 3 kasutajat.
Allikas: habr.com
