Það er gott að taka öryggisafrit af mikilvægum gögnum. En hvað ef vinnan þarf að halda áfram strax og hver mínúta skiptir máli? Við hjá Acronis ákváðum að athuga hvernig hægt er að leysa vandamálið við að koma kerfinu í gang eins fljótt og auðið er. Og þetta er fyrsta færslan í Active Restore seríunni, þar sem ég mun segja þér hvernig við byrjuðum verkefnið ásamt Innopolis háskólanum, hvaða lausn við fundum og hvað við erum að vinna að í dag. Upplýsingar eru undir klippingu.
Halló! Ég heiti Daulet Tumbayev og í dag langar mig að deila með þér reynslu minni af þróun kerfis sem flýtir fyrir bata við hörmungum. Til að tala um alla þróunarleið verkefnisins skulum við byrja aðeins úr fjarlægð. Núna vinn ég hjá Acronis en er líka útskrifaður frá Innopolis háskólanum þar sem ég lauk meistaranámi í hugbúnaðarþróunarstjórnun (þekkt sem MSIT-SE). Innopolis er ungur háskóli og námskráin er enn yngri. En það er byggt á námskrá Carnegie Mellon háskólans, en starf hans nær yfir efni eins og iðnaðarverkefni.
Tilgangur iðnverkefnisins er að sökkva nemandanum niður í raunverulegan þroska og treysta áunna þekkingu í reynd. Til að gera þetta er háskólinn í samstarfi við fyrirtæki eins og Yandex, Acronis, MTC og tugi annarra (alls frá og með 2018 hafði háskólinn 144 samstarfsaðila). Í samstarfinu bjóða fyrirtæki háskólanum upp á starfssvæði sín og nemendur velja eitt þeirra verkefna sem er nær áhugasviði þeirra og menntunarstigi. Fyrir bókstaflega tveimur árum síðan var ég enn „hinum megin við girðingarnar“ og vann sem nemandi í öðru Acronis verkefni. En í þetta skiptið gerðist ég tækniráðgjafi fyrir nemendur hjá fyrirtækinu og lagði til Active Restore verkefnið til Innopolis. Sjálf hugmyndin um Active Restore var mótuð af Kernel teyminu hjá Acronis, en þróun lausnarinnar hófst ásamt Innopolis háskólanum.
Active Restore - hvers vegna er það þörf?
Hefð er að hamfarabati virkar samkvæmt stöðluðu kerfi. Eftir vandræði með tölvuna þína ferðu í vefviðmót einhvers öryggisafritunarkerfis, til dæmis Acronis True Image, og smellir á stóra „endurheimta“ hnappinn. Næst þarftu að bíða í N mínútur og aðeins eftir það geturðu haldið áfram að vinna.
Vandamálið er að þessi tala N, einnig þekkt sem RTO (batatímamarkmið), leyfilegur batatími, getur verið nokkuð áhrifamikill, sem fer eftir tengingarhraðanum (ef endurheimt er úr skýinu), stærð harða disksins á vélinni þinni. , og fjölda annarra þátta. Er hægt að minnka það? Já, þú getur það, því til að geta haldið áfram vinnu þarftu ekki alltaf fullan tölvudisk. Sömu myndir og myndbönd hafa ekki áhrif á virkni tækisins á nokkurn hátt og hægt er að draga þær upp síðar í bakgrunni.
Vantar bílstjóra...
Stýrikerfið gerir ráð fyrir að byrja með diskinn að fullu tilbúinn. Þess vegna framkvæmir Windows röð athugana til að athuga heilleika disksins. Kerfið mun ekki leyfa venjulega ræsingu ef einhverjar skrár sem stýrikerfið býst við að finnast vantar eða eru skemmdar. Til að leysa þetta vandamál var ákveðið að setja á diskinn svokallaðar redirector skrár sem við bjuggum til, sem koma í stað týndra eða skemmda skráa, en eru í raun dúllur. Það tekur ekki langan tíma að búa til slíka umvísanir vegna þess að þeir hafa í raun ekki neitt efni.
Frekari endurreisn fer fram sem hér segir. Með bakgrunnsferli, samhliða rekstri stýrikerfisins, eru „dúllur“ fylltar af gögnum. Endurheimtunarferlið í bakgrunni tekur mið af álagi disksins og fer ekki yfir sett mörk. Hins vegar gæti notandinn eða stýrikerfið sjálft skyndilega þurft skrá sem er ekki enn til. Þetta er þar sem seinni batahamurinn kemur við sögu. Forgangur umbeðinnar skráar er hækkaður í hámark og endurheimtarferlið hleður skránni bráðlega á diskinn. Stýrikerfið fær nauðsynlega skrá, þó með smá seinkun.
Svona lítur hugsjón mynd út. Hins vegar, í hinum raunverulega heimi, er gríðarlegur fjöldi gildra og hugsanlegra stöðva. Ásamt Innopolis meistaranemum ákváðum við að kanna þessa bata atburðarás, meta ávinninginn í RTO og skilja hvort slík nálgun sé framkvæmanleg? Enda voru einfaldlega engar slíkar lausnir á markaðnum á þessum tíma.
Og ef ég ákvað að leggja út þjónustuhlutann til strákanna frá Innopolis, þá hófst vinna innan Acronis á . Þetta var gert af Windows Kernel teyminu. Planið var svona:
- Ræstu bílstjórann á fyrstu stigum ræsingar stýrikerfisins,
- Í vinnu, hvenær verður alveg tilbúinn, hlaðið niður þjónustunni
- Þjónustan afgreiðir beiðnir bílstjóra og samhæfir frekari vinnu.
Fínleiki ökumannsverkfræði
Ef samstarfsmenn mínir munu tala um þjónustuna í annarri færslu, þá munum við í þessum texta afhjúpa ranghala þróun ökumanns. Þegar búið er að þróa smásíudrifinn er með tvær aðgerðastillingar - þegar kerfið byrjaði í venjulegri stillingu og þegar kerfið hefur bara orðið fyrir bilun og verið er að endurheimta það. Áður en notendasöfn og forrit eru hlaðin, og þar með þjónustu okkar, hegðar ökumaðurinn sér eins. Hann veit ekki í hvaða ástandi kerfið er núna. Fyrir vikið er hver sköpun, lesning og skrif skráð og öll lýsigögn skráð. Og þegar þjónustan er á netinu veitir ökumaðurinn þessar upplýsingar til þjónustunnar.
Ef um eðlilega ræsingu er að ræða sendir þjónustan „slaka“ merki til ökumanns þannig að hann „slakar á“ og hættir að skrá öll gögn vandlega. Í þessu tilviki skiptir ökumaðurinn yfir í að skrá aðeins breytingar á disknum og tilkynnir þær til þjónustunnar sem, með því að nota önnur Acronis verkfæri, heldur öryggisafritinu á disknum í nýjustu ástandi á miðlinum sem notandinn tilgreinir. Þetta getur verið afrit af skýi, fjarstýringu, smám saman eða á nóttunni.
Ef endurheimtarhamur er virkur, segir þjónustan ökumanninum að hún þurfi að vinna í „Recovery“ ham. Kerfið er nýbúið að jafna sig eftir hrun og um leið og það leggur fram beiðni um að opna skrá á disknum þarf smásían að stöðva þessa aðgerð, gera þessa beiðni sjálf, athuga hvort slík skrá sé til á disknum og hvort það er hægt að opna hana.
Ef skrá vantar sendir smásían þessar upplýsingar til þjónustunnar, sem eykur forgang skráarbata (allan þennan tíma er endurheimt í gangi í bakgrunni). Það kemur í ljós að þessi skrá hoppar einfaldlega í byrjun biðröðarinnar. Eftir þetta endurheimtir þjónustan sjálf (eða önnur Acronis leið) þessa skrá og segir bílstjóranum að allt sé í lagi, nú hefur stýrikerfið aðgang að henni og bílstjórinn „sleppir“ upprunalegu beiðninni, frá kerfinu yfir á diskinn.
Ef endurheimt er ómögulegt, lætur þjónustan ökumanninn vita að skráin sé ekki í öryggisafritinu. Smásíurekillinn okkar sendir einfaldlega kerfisbeiðnina áfram og upphaflegi beiðandinn (stýrikerfið sjálft eða forritið) fær villuna „skrá fannst ekki“. Hins vegar er þetta alveg eðlilegt ef skráin var í raun ekki á disknum og í öryggisafritinu.
Auðvitað mun stýrikerfið virka mun hægar, vegna þess að lestur á hvaða skrá eða bókasafn sem er á sér stað í nokkrum áföngum, hugsanlega með aðgangi að fjarlægum auðlindum. En notandinn getur farið aftur til vinnu eins fljótt og auðið er á meðan bati á sér enn stað.
Þarftu lægra, jafnvel lægra...
Frumgerðin hefur sannað virkni sína. En við fundum líka þörf á að halda áfram vegna þess að í sumum tilfellum eru enn pattstöður. Stýrikerfið getur til dæmis óskað eftir ýmsum söfnum í nokkrum þráðum, sem leiðir til þess að þjónusta okkar snýst aftur um sig.
Vandamálið sem ég er að vinna í er að auka hraða Active Restore og auka öryggi kerfisins. Segjum að kerfið þurfi ekki alla skrána heldur aðeins hluta hennar. Í þessu skyni var annar bílstjóri þróaður - diskasíudrifinn. Það virkar ekki lengur á skráarstigi, heldur á blokkarstigi. Meginreglan um aðgerðir er svipuð: í venjulegum rekstrarham skráir ökumaðurinn einfaldlega breyttar blokkir á disknum og í bataham reynir hann að lesa blokkina á eigin spýtur, og ef það tekst ekki, biður hann um að þjónustuna auki forganginn. Hins vegar eru allir aðrir hlutar kerfisins óbreyttir. Til dæmis grunar stýrikerfisþjónustu ekki einu sinni að hún sé beðin um að hafa samskipti við annan ökumann, því aðalverkefnið er að útvega stýrikerfinu nákvæmlega þau gögn sem nauðsynleg eru til notkunar. Þetta svæði krefst verulegra umbóta, þó ekki væri nema vegna þess að þjónustan veit ekki enn hvernig á að hugsa á blokkarstigi.
Næsta skref ákvað ég að ræsa ökumanninn dýpra og fyrr og fara niður á UEFI ökumenn og innfædd Windows forrit í stað þjónustunnar. Í þessu skyni var það þróað (eða DXE driver), sem byrjar og deyr jafnvel áður en stýrikerfið byrjar. En við munum skoða „sögu“ UEFI ökumanna, upplýsingar um samsetningu og uppsetningu, svo og sérkenni Windows Native forrita í næstu færslu. Svo gerist áskrifandi að blogginu okkar og í millitíðinni mun ég undirbúa sögu um næsta stig vinnunnar. Ég mun vera ánægð að sjá athugasemdir þínar og ráðleggingar.
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Hefur þú einhvern tíma lent í aðstæðum þar sem bati tók óskaplega langan tíma:
-
65.1%Já28
-
23.2%No10
-
11.6%Hugsaði ekki um það5
43 notendur kusu. 3 notendur sátu hjá.
Heimild: www.habr.com