A fontos adatok biztonsági mentése jó dolog. De mi van akkor, ha a munkát azonnal folytatni kell, és minden perc számít? Mi az Acronisnál úgy döntöttünk, hogy megvizsgáljuk, hogyan lehetséges-e a lehető leggyorsabban megoldani a rendszerindítás problémáját. És ez az első bejegyzés az Active Restore sorozatból, amelyben elmesélem, hogyan kezdtük el a projektet az Innopolis Egyetemmel közösen, milyen megoldást találtunk, és min dolgozunk ma. A részletek a vágás alatt találhatók.
Helló! A nevem Daulet Tumbayev, és ma szeretném megosztani veletek a katasztrófa utáni helyreállítást felgyorsító rendszer fejlesztésével kapcsolatos tapasztalataimat. Ha a projekt teljes fejlődési útjáról beszélünk, kezdjük egy kicsit távolról. Jelenleg az Acronisban dolgozom, de az Innopolis Egyetemen is diplomáztam, ahol a Szoftverfejlesztési Menedzsment mesterszakot (MSIT-SE) végeztem. Az Innopolis egy fiatal egyetem, és a tananyag még fiatalabb. De a Carnegie Mellon Egyetem tantervére épül, amelynek munkájában olyan téma szerepel, mint az ipari projektek.
Az ipari projekt célja, hogy a hallgatót elmerítse a valódi fejlődésben, és a megszerzett tudást megszilárdítsa a gyakorlatban. Ennek érdekében az egyetem együttműködik olyan cégekkel, mint a Yandex, Acronis, MTC és több tucat másik cég (összesen 2018-ban az egyetemnek 144 partnere volt). Az együttműködés során a cégek felajánlják munkaterületeiket az egyetemnek, a hallgatók pedig az érdeklődési körükhöz és képzettségi szintjükhöz közelebb álló projekteket választják. Szó szerint két évvel ezelőtt még „a barikádok túloldalán” voltam, és diákként dolgoztam egy másik Acronis projekten. Ezúttal azonban a cég diákjainak műszaki tanácsadója lettem, és az Active Restore projektet javasoltam az Innopolisnak. Az Active Restore ötletét az Acronis Kernel csapata fogalmazta meg, de a megoldás fejlesztése az Innopolis Egyetemmel együtt kezdődött.
Active Restore – miért van rá szükség?
Hagyományosan a katasztrófa utáni helyreállítás szabványos séma szerint működik. A számítógéppel kapcsolatos problémák után fel kell lépnie egy biztonsági mentési rendszer webes felületére, például az Acronis True Image-re, és rákattint a nagy „visszaállítás” gombra. Ezután N percet kell várnia, és csak ezután folytathatja a munkát.
A probléma az, hogy ez az N szám, más néven RTO (helyreállítási idő cél), a megengedett helyreállítási idő, meglehetősen lenyűgöző lehet, ami a kapcsolat sebességétől (ha a helyreállítás felhőből történik), a gép merevlemezének méretétől függ. és számos egyéb tényező. Lehetséges-e csökkenteni? Igen, megteheti, mert a munka folytatásához nem mindig van szüksége teljes számítógépes lemezre. Ugyanazok a fotók és videók semmilyen módon nem befolyásolják az eszköz működését, és később a háttérben előhúzhatók.
Sofőr szükséges...
Az operációs rendszer egy teljesen előkészített lemezzel való indítást vár. Ezért Windows Egy sor lemezintegritási ellenőrzést hajt végre. A rendszer nem engedélyezi a normál indítást, ha az operációs rendszer által keresett fájlok hiányoznak vagy sérültek. A probléma megoldása érdekében úgy döntöttünk, hogy úgynevezett átirányító fájlokat helyezünk el a lemezen. Ezek a fájlok helyettesítik a hiányzó vagy sérült fájlokat, de lényegében álfájlok. Ezen átirányítók létrehozása nagyon egyszerű, mivel valójában nem tartalmaznak semmilyen tartalmat.
A további helyreállítás a következőképpen történik. Egy háttérfolyamattal, az operációs rendszer működésével párhuzamosan, a „bábukat” töltik fel adatokkal. A háttér-helyreállítási folyamat figyelembe veszi a lemezterhelést, és nem lépi túl a beállított korlátot. Előfordulhat azonban, hogy a felhasználó vagy maga az operációs rendszer hirtelen olyan fájlt igényel, amely még nem létezik. Itt jön képbe a második helyreállítási mód. A kért fájl prioritása maximálisra emelkedik, és a helyreállítási folyamat sürgősen betölti a fájlt a lemezre. Az operációs rendszer kis késéssel ugyan, de megkapja a szükséges fájlt.
Így néz ki egy ideális kép. A való világban azonban rengeteg buktató és potenciális holtpont van. Az Innopolis mesterszakos hallgatóival együtt úgy döntöttünk, hogy megvizsgáljuk ezt a helyreállítási forgatókönyvet, értékeljük az RTO-ban elért eredményeket, és megértjük, hogy megvalósítható-e egy ilyen megközelítés? Hiszen akkoriban egyszerűen nem voltak ilyen megoldások a piacon.
És ha úgy döntöttem, hogy a szolgáltatási komponenst az innopolisi srácoknak adom, akkor az Acronison belül elkezdődött a munka A csapat gondoskodott erről. Windows Kernel. A terv a következő volt:
- Indítsa el az illesztőprogramot az operációs rendszer indításának korai szakaszában,
- Munka közben, mikor teljesen készen áll, töltse le a szolgáltatást
- A szerviz feldolgozza a járművezetői kéréseket és koordinálja további munkáját.
A járművezetői tervezés finomságai
Ha kollégáim egy másik bejegyzésben beszélnek majd a szolgáltatásról, akkor ebben a szövegben a sofőrfejlesztés fortélyait tárjuk fel. A már kifejlesztett miniszűrő-illesztőprogramnak két üzemmódja van - amikor a rendszer normál módban indult, és amikor a rendszer éppen meghibásodott, és helyreállítás alatt áll. A felhasználói könyvtárak és alkalmazások, és így szolgáltatásunk betöltése előtt az illesztőprogram ugyanúgy viselkedik. Nem tudja, hogy jelenleg milyen állapotban van a rendszer. Ennek eredményeként minden létrehozás, olvasás és írás naplózásra kerül, és minden metaadat rögzítésre kerül. És amikor a szolgáltatás online, a sofőr megadja ezt az információt a szolgáltatásnak.
Normál indítás esetén a szolgáltatás „Relax” jelzést küld a sofőrnek, hogy az „ellazuljon”, és leállítsa az összes adat gondos naplózását. Ebben az esetben az illesztőprogram csak a lemezen történt változások naplózására vált, és jelenti azokat a szerviznek, amely az Acronis egyéb eszközeivel a legfrissebb állapotban tartja a lemez biztonsági mentését a felhasználó által megadott adathordozón. Ez lehet felhő, távoli, fokozatos vagy éjszakai biztonsági mentés.
Ha a helyreállítási mód engedélyezve van, a szolgáltatás közli az illesztőprogrammal, hogy „Helyreállítás” módban kell működnie. A rendszer éppen most állt helyre egy összeomlás után, és amint egy fájl megnyitását kéri a lemezen, a miniszűrőnek el kell hárítania ezt a műveletet, magának kell végrehajtania ezt a kérést, ellenőriznie kell, hogy van-e ilyen fájl a lemezen, és hogy kinyitható.
Ha egy fájl hiányzik, a mini-szűrő továbbítja ezt az információt a szolgáltatásnak, ami növeli a fájl-helyreállítás prioritását (mindeddig a helyreállítás a háttérben zajlik). Kiderült, hogy ez a fájl egyszerűen a sor elejére ugrik. Ezek után maga a szolgáltatás (vagy más Acronis eszköz) visszaállítja ezt a fájlt, és közli a meghajtóval, hogy minden rendben, most már az operációs rendszer hozzáférhet, és az illesztőprogram „kiadja” az eredeti kérést, a rendszerről a lemezre.
Ha a helyreállítás lehetetlen, a szolgáltatás tájékoztatja az illesztőprogramot, hogy a fájl nincs a biztonsági másolatban. Miniszűrő-illesztőprogramunk egyszerűen továbbítja a rendszerkérést, és az eredeti kérelmező (maga az operációs rendszer vagy az alkalmazás) „fájl nem található” hibaüzenetet kap. Ez azonban teljesen normális, ha a fájl valóban nem volt a lemezen és a biztonsági másolatban.
Természetesen az operációs rendszer sokkal lassabban fog működni, mivel bármely fájl vagy könyvtár olvasása több lépésben történik, esetleg távoli erőforrásokhoz való hozzáféréssel. A felhasználó azonban a lehető leghamarabb újra munkába állhat, amíg a helyreállítás még folyamatban van.
Kell lejjebb, még lejjebb...
A prototípus bizonyította működőképességét. De azt is tapasztaltuk, hogy tovább kell lépni, mert egyes esetekben még mindig vannak holtpontok. Például az operációs rendszer több szálban kérhet különféle könyvtárakat, ami ahhoz vezet, hogy szolgáltatásunk visszahurkolja magát.
A probléma, amin jelenleg dolgozom, az Active Restore sebességének növelése és a rendszerbiztonság szintjének növelése. Tegyük fel, hogy a rendszernek nem a teljes fájlra van szüksége, hanem annak csak egy részére. Erre a célra egy másik illesztőprogramot fejlesztettek ki - a lemezszűrő illesztőprogramját. Már nem fájl szinten működik, hanem blokk szinten. A működési elv hasonló: normál üzemmódban az illesztőprogram egyszerűen naplózza a megváltozott blokkokat a lemezen, helyreállítási módban pedig megpróbálja önállóan beolvasni a blokkot, és ha nem jár sikerrel, a prioritás növelését kéri a szolgáltatástól. A rendszer többi része azonban változatlan marad. Például egy operációs rendszer szintű szolgáltatás nem is sejti, hogy egy másik meghajtóval való kommunikációt kérik tőle, mert a fő feladat az, hogy az operációs rendszert pontosan a működéshez szükséges adatokkal lássa el. Ez a terület jelentős fejlesztéseket igényel, már csak azért is, mert a szolgáltatás még nem tud blokkszinten gondolkodni.
A következő lépés az volt, hogy a drivert régebbre és mélyebbre futtattam, egészen az UEFI driver és a Native szintig. Windows alkalmazások szolgáltatás helyett. Erre a célra fejlesztették ki (vagy DXE illesztőprogram), amely még az operációs rendszer indulása előtt elindul és leáll. De az UEFI illesztőprogramok "története", az összeszerelés és a telepítés részletei, valamint a sajátosságok Windows A következő bejegyzésben a natív alkalmazásokkal foglalkozunk majd. Iratkozzatok fel a blogunkra, amíg elkészítem a történetemet a munkánk következő szakaszáról. Szívesen olvasom a hozzászólásaitokat és javaslataitokat.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Volt már olyan helyzete, amikor a felépülés kínzóan hosszú ideig tartott:
65.1%Igen 28
23.2%No10
11.6%Nem gondoltam rá5
43 felhasználó szavazott. 3 felhasználó tartózkodott.
Forrás: will.com
