Oluliste andmete varundamine on hea asi. Aga mis juhtub, kui tööd tuleb jätkata kohe ja iga minut loeb? Me Acronises otsustasime uurida, kui kiiresti on võimalik süsteemi käivitamise ülesanne lahendada. See on esimene postitus sarjast Active Restore, kus räägin, kuidas me alustasime projekti koos Innopolis Ülikooliga, millise lahenduse leidsime ja mille kallal me täna töötame. Täiendavad üksikasjad on allpool.
Tere! Minu nimi on Daulet Tumbaev ja täna tahan jagada teiega oma kogemust süsteemi arendamisel, mis kiirendab havariide taastamist. Et rääkida kogu projekti arenguteest, alustame natuke kaugemalt. Praegu töötan Acronises, kuid olen ka Innopolis Ülikooli vilistlane, mille lõpetasin magistriõppe programmiga "Tarkvara arenduse juhtimine" (tuntud kui MSIT-SE). Innopolis on noor ülikool ja õppeprogramm on veel noorem. Kuid see on üles ehitatud Carnegie Melloni Ülikooli õppekavadele, millel on selline teema nagu tööstusprojektid.
Industriaalse projekti eesmärk on viia tudeng reaalsetesse arendusprotsessidesse ja kinnistada saadud teadmised praktikas. Selleks teeb ülikool koostööd ettevõtetega nagu Yandex, Acronis, MTC ja paljude teistega (2018. aasta seisuga oli ülikoolil kokku 144 partnerit). Koostöö käigus pakuvad ettevõtted ülikoolile oma tööalaseid suundi ning tudengid valivad ühe projekti, mis neid huvitab ja vastab nende ettevalmistustasemele. Veel kaks aastat tagasi olin “barjääri teisel pool” ja töötasin tudengina Acronise teise projekti kallal. Kuid seekord olin tehniline konsultant tudengitele ettevõtte poolt ning pakkusin Innopolis Ülikoolile projekti Active Restore. Active Restore'i idee formulareeris Acronise Kernel'i meeskond, kuid lahenduse arendamine algas koos Innopolis Ülikooliga.
Active Restore – milleks seda vajatakse?
Traditsiooniline havariide taastamine töötab standardse skeemi alusel. Pärast arvutiga probleeme logite sisse mõne varundamissüsteemi veebiliidesesse, näiteks Acronis True Image, ja vajutate suurt nuppu "taasta". Edasi tuleb oodata N minutit, ja alles siis saab tööga jätkata.
Probleem seisneb selles, et see number N, tuntud ka kui RTO (kaose taastumise sihtaja), lubatud taastumise aeg, võib olla üsna ulatuslik, sõltudes ühenduse kiirusest (kui taastamine toimub pilvest), teie masina kõvaketta mahust ja mitmest muust tegurist. Kas on võimalik seda vähendada? Jah, on võimalik, sest töö jätkamiseks ei ole alati vajalik terve arvuti kettad. Samad fotod ja videod ei mõjuta seadme funktsionaalsust ja neid saab hiljem taustal alla laadida.
Driver needed…
Operatsioonisüsteem arvab, et see käivitub täiesti valmis kettaga. Seetõttu teeb Windows mitmeid kettakontrollimise protseduure. Süsteem ei lase normaalselt käivitada, kui mõni oodatud fail on puuduv või rikutud. Selle probleemi lahendamiseks otsustati kettale paigutada meie loodud, nn ümbersuunamisfailid, mis asendavad puuduvad või kahjustatud failid, kuid on tegelikult tühjad. Selliste ümbersuunajate loomine ei võta kaua aega, kuna neil ei ole tegelikult sisu.
Edasi toimub taastamine järgmiselt. Taustprotsessis, paralleelselt operatsioonisüsteemi tööga, täidetakse 'tühjaks' jäämised andmetega. Taustal toimuv taastamisprotsess arvestab kettakoormust ja ei ületa kehtestatud piirmäära. Siiski võib kasutaja või ise operatsioonisüsteem ootamatult nõuda faili, mida veel ei ole. Siin astub sisse teine taastamisrežiim. Nõutava faili prioriteet tõstatakse maksimaalseks ja taastamisprotsess laeb faili kiiresti kettale. Operatsioonisüsteem saab vajaliku faili, kuigi väikese viivitusega.
Nii näeb välja ideaalne pilt. Kuid tegelikus maailmas on palju peidetud küsimusi ja potentsiaalseid ummikseise. Koos Innopolis olevate üliõpilastega otsustasime uurida seda taastamisstsenaariumi, hinnata RTO saavutamist ja mõista, kas selline lähenemine on teostatav? Selliseid lahendusi turul lihtsalt ei olnud.
Ja kui teenuse osa otsustasin usaldada Innopolis olevatele poistele, siis Acronise sees algas töö . Sellega tegeleb Windows Kernel meeskond. Plaan oli selline:
- Käivitada draiver operatsioonisüsteemi käivitamise varases etapis,
- Töö ajal, kui on täielikult valmis, laadida teenus
- Teenusele koordineerib ja töötleb draiveri päringud ning reguleerib selle edasist tööd.
Draiveri arendamise nüansid
Kui minu kolleegid räägivad teenusest teises postituses, siis selles tekstis avame draiveri arendamise nüansse. Juba välja arendatud mini-filtri draiveril on kaks töörežiimi – kas süsteem käivitus normaalses režiimis või just praegu taastatakse see pärast tõrget. Enne kui kasutajate teegid ja rakendused, ning seega ka meie teenus, laaditakse, käitub draiver samamoodi. Ta ei tea, millises olekus süsteem parasjagu asub. Tulemuseks on iga create, read ja write protokollimine, kõik metaandmed fikseeritakse. Ja kui teenus on veebis, siis draiver edastab selle teabe teenusele.
Tavalise käivitamise korral edastab teenus draiverile signaali “Relax”, et ta “rahuneks” ja lõpetaks kõigi andmete detailse protokollimise. Sellisel juhul liigub draiver üle ainult ketta muudatuste protokollimisele ja teatab neist teenusele, mis Acronise teiste tööriistade abil toetab kettavaru maksimaalselt värskena säilitamist selle seadme peal, mille kasutaja on määranud. See võib olla pilve-, kaug- või öine varukoopia.
Kui taastamisrežiim aktiveeritakse, teatab teenus draiverile, et tal on vaja töötada “Recovery” režiimis. Süsteem on just taastunud tõrke järgselt ja niipea, kui ta esitab päringu faili avamiseks kettal, peab mini-filter selle toimingu katkestama, tegema ise selle päringu, kontrollima, kas selline fail on kettal olemas ja kas seda on võimalik avada.
Kui faili pole, edastab mini-filter selle teabe teenusele, mis tõstab 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 (või Acronise muud meetodid) selle faili ning teatab draiverile, et kõik on korras, nüüd saab operatsioonisystem sellele juurdepääsu ja draiver "lahti laseb" originaalsest päringust süsteemilt kettale.
Kui taastamine ei ole võimalik, teavitab teenus draiverit, et faili pole ka varukoopias. Meie mini-filter draiver edastab lihtsalt süsteemipäringu edasi ning originaalne pärija (isegi operatsioonisüsteem või rakendus) saab veateate "fail ei leitud". Kuid see on täiesti normaalne, kui faili tõepoolest ei olnud kettal ega varukoopias.
Muidugi töötab operatsioonisüsteem palju aeglasemalt, sest igasuguste failide või teekide lugemine toimub mitmes etapis, võimalusel ka kaugressurssidega juurdepääsuga. Kuid siiski saab kasutaja oma tööga alustada väga kiiresti, kuni taastamine veel kestab.
Peab minema madalamale, veel madalamale…
Prototüüp tõestas oma töökindlust. Kuid me avastasime ka vajaduse edasi liikuda, kuna mõnel juhul toimuvad endiselt lukustused. Näiteks võib operatsioonisüsteem küsida erinevaid teeke mitmes niidis, mis toob kaasa meie teenuse sulgemise enda peale.
Probleem, millega praegu tegelen, on Active Restore kiirus ja süsteemi turvalisuse taseme tõstmine. Oletame, et süsteem ei vaja tervet faili, vaid ainult selle osa. Selleks on välja töötatud veel üks draiver - kettafiltri draiver. See töötab enam mitte failitasemel, vaid plokkide tasemel. Tööprintsiip on sarnane: tavatasandil protokollib draiver lihtsalt kettal muudetud plokid, samas kui taastamisrežiimis proovib ta plokki ise lugeda, ebaõnnestumise korral küsib ta teenuselt prioriteedi tõstmist. Samal ajal jäävad kõik ülejäänud süsteemi osad muutumatuks. Näiteks ei kahtle OS taseme teenus, et talle pakutakse suhtlemist teise draiveriga, sest peamine ülesanne on pakkuda OS-le just neid andmeid, mis on vajalikud funktsioneerimiseks. See suund vajab märkimisväärseid täiustusi, vähemalt seetõttu, et teenus ei oska veel mõelda plokkide tasemel.
Järgmise sammuna otsustasin käivitada draiveri sügavamalt ja varem, laskudes UEFI draiverite ja Native Windows rakenduste tasemele teenuse asemel. Selleks on välja töötatud (või DXE draiver), mis käivitub ja kaob enne operatsioonisüsteemi käivitumist. Kuid UEFI draiverite "ajalugu", üksikasjad kogumise ja installimise kohta ning Windows Native rakenduste spetsiifika käsitleme järgmises postituses. Nii et palun liituge meie blogiga, samas kui ma valmistan ette juttu järgmise töö etapi kohta. Ootan väga teie kommentaare ja nõuandeid.
Ainult registreeritud kasutajad saavad küsitluses osaleda. , palun.
Kas olete kunagi olnud olukordades, kus taastumine kestis piinarikkalt kaua:
65.1%Jah28
23.2%Ei10
11.6%Ei mõelnud
Hääletas 43 kasutajat. Hoidus 3 kasutajat.
Allikas: habr.com
