Fontos adatok biztonsági mentése jó dolog. De mi van, ha a munkát azonnal folytatni kell, és minden perc számít? Az Acronis-nál megvizsgáltuk, hogy mennyire lehetséges a rendszer gyors helyreállításának megvalósítása. Ez az Active Restore sorozat első posztja, amelyben elmondom, hogyan kezdtük el a projektet az Innopolis Egyetemmel, milyen megoldást találtunk, és min dolgozunk ma. Részletek a folytatásban.
Helló! A nevem Daulet Tumbaev, és ma szeretném megosztani veletek a vészhelyzeti helyreállítást gyorsító rendszer fejlesztésével kapcsolatos tapasztalataimat. Hogy elmeséljem a projekt fejlődésének teljes történetét, kezdjük egy kicsit távolabbról. Jelenleg az Acronisnál dolgozom, de az Innopolis Egyetem volt hallgatója is vagyok, ahol a szoftverfejlesztés menedzsment mesterképzését (MSIT-SE) végeztem. Az Innopolis egy fiatal egyetem, az oktatási program pedig még újabb. De az a Carnegie Mellon Egyetem tanterveire épül, amelyben foglalkoznak ipari projektekkel is.
Az ipari projekt célja, hogy a hallgatót bevezesse a valós fejlesztésbe és megszilárdítsa a megszerzett tudást a gyakorlatban. Ennek érdekében az egyetem olyan cégekkel működik együtt, mint a Yandex, az Acronis, az MTC és még sok más (2018 végére az egyetemnek összesen 144 partnere volt). A partnerség során a cégek ajánlják az egyetemnek a munkaterületeiket, a hallgatók pedig választanak egy projektet, amely közelebb áll az érdeklődésükhöz és felkészültségük szintjéhez. Két évvel ezelőtt még „a barricád másik oldalán” voltam, és hallgatóként dolgoztam egy másik Acronis projekten. De ezúttal technikai tanácsadó lettem a hallgatók számára a cégtől, é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 kezdődött.
Active Restore – miért van szükség erre?
Hagyományosan a vészhelyzeti helyreállítás szabványos séma szerint működik. Számítógépes problémák esetén belép a webes felületre egy biztonsági mentést végző rendszerbe, például az Acronis True Image-ba, és megnyomja a „visszaállítás” feliratú nagy gombot. Ezután várnia kell N percet, és csak ezután folytathatja a munkát.
A probléma az, hogy ez a N szám, amelyet RTO-nak (helyreállítási időcél) is neveznek, egy meglehetősen jelentős időintervallum lehet, amely a kapcsolat sebességétől függ (ha felhőből történik a helyreállítás), a számítógép merevlemezének méretétől és egyéb tényezőktől. Lehet-e csökkenteni? Igen, lehet, hiszen a munka folytatásához nem mindig szükséges az egész számítógép lemeze. Az olyan fényképek és videók nem befolyásolják az eszköz működését, és később, a háttérben betölthetők.
Driver needed…
A rendszerműködés teljesen felkészült lemezzel tervezi a startot. Ezért a Windows egy sor lemezhitelesítést végez. A rendszer nem fogja engedni a normál indítást, ha hiányoznak vagy sérültek bizonyos fájlok, amiket az operációs rendszer vár. E probléma megoldására azt döntöttük, hogy a lemezre létrehozunk úgynevezett átirányító fájlokat, amelyek pótolják a hiányzó vagy sérült fájlokat, de valójában üres tartalommal bírnak. Az ilyen átirányítók létrehozása nem tart sokáig, hiszen valójában nincs tartalmuk.
A következő helyreállítási folyamat így zajlik. A háttérfolyamat, párhuzamosan az operációs rendszer munkájával, a „tartalom nélküli” fájlokat adatokkal tölti fel. A háttéreljesítés figyelembe veszi a lemez terhelését, és nem lépi túl a megállapított határértéket. Azonban a felhasználó vagy maga az operációs rendszer váratlanul kérheti egy fájl megérkezését, amely még nem áll rendelkezésre. Ekkor lép életbe 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 végül megkapja a szükséges fájlt, bár kis késleltetéssel.
Így fest az ideális kép. Azonban a valóságban rengeteg aknamező és potenciális holtpont található. Az Innopolis mesterszakos hallgatóival közösen úgy döntöttünk, hogy kutatjuk ezt a helyreállítási forgatókönyvet, értékeljük az RTO-ban elért nyereséget, és megértsük, hogy ilyen megközelítés megvalósítható-e? Hiszen ilyen megoldások akkor még nem voltak a piacon.
És ha a szolgáltatási elemet az Inopolis diákjaira bíztam, akkor az Acronis keretein belül elkezdődött a munka . Ezt a Windows Kernel csapata végezte. A terv a következő volt:
- A meghajtót a rendszer indításának korai szakaszában kell elindítani,
- A működés során, amikor teljesen kész lesz, a szolgáltatás betöltődik
- A szolgáltatás kezeli a meghajtó kérését és koordinálja annak további működését.
A meghajtóépítés részletei
Ha a szolgáltatásról a kollégáim egy másik posztban beszélnek, akkor ebben a szövegben a meghajtó fejlesztésének részleteit tárgyaljuk. A már kifejlesztett mini-szűrő meghajtónak két üzemmódja van - amikor a rendszer normál üzemmódban indul, és amikor a rendszer éppen egy hibát élt át, és a helyreállítása folyamatban van. Mielőtt a felhasználói könyvtárak és alkalmazások, így a szolgáltatásunk betöltődne, a meghajtó ugyanúgy viselkedik. Nem tudja, hogy a rendszer most melyik állapotában van. Ennek következtében minden create, read és write naplózva van, a metaadatok mind rögzítve vannak. Amikor a szolgáltatás online lesz, a meghajtó ezt az információt a szolgáltatásnak biztosítja.
Normál indítás esetén a szolgáltatás egy "Relax" jelet küld a meghajtónak, hogy az "ellazuljon" és ne rögzítse minden adatot annyira precízen. Ebben az esetben a meghajtó csak a lemezen történt változások naplózására vált át, és tájékoztatja a szolgáltatást, amely az Acronis egyéb eszközeivel maximálisan aktuális állapotban tartja a lemezképet az adott tárolón, amit a felhasználó megadott. Ez lehet felhőalapú, távoli, fokozatos vagy éjszakai biztonsági mentés.
Ha a helyreállítási mód aktiválódik, a szolgáltatás tájékoztatja a meghajtót, hogy "Recovery" módban kell működnie. A rendszer éppen helyreállt a hibából, és amint kérést küld a fájl megnyitására a lemezen, a mini-szűrőnek le kell állítania ezt a műveletet, meg kell tennie ezt a kérést, ellenőriznie kell, hogy van-e ilyen fájl a lemezen, és meg lehet-e nyitni.
Ha a fájl nem található, a mini-szűrő ezt az információt továbbítja a szolgáltatásnak, amely növeli a fájl helyreállításának prioritását (ez idő alatt a helyreállítás háttérben zajlik). Így ez a fájl gyakorlatilag a sor elejére ugrik. Ezt követően a szolgáltatás (vagy más Acronis eszközök) helyreállítja a fájlt, és értesíti a meghajtót, hogy minden rendben van, most az operációs rendszer hozzáférhet a fájlhoz, és a meghajtó „elengedi” az eredeti kérést a rendszer és a lemez között.
Ha a helyreállítás lehetetlen, a szolgáltatás értesíti a meghajtót, hogy a fájl a biztonsági másolatban sincs. A mini-szűrő meghajtónk egyszerűen átengedi a rendszer kérését, így az eredeti kérvényező (maga az operációs rendszer vagy egy alkalmazás) hibát kap: „fájl nem található”. Ez azonban teljesen normális, ha a fájl valóban nem volt jelen sem a lemezen, sem 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, és lehetséges, hogy távoli erőforrásokhoz is hozzáférést igényel. De a felhasználó így is a lehető leghamarabb folytathatja a munkát, míg a helyreállítás még zajlik.
Tovább kell menni, még inkább...
A prototípus bizonyította működőképességét. De azt is észleltük, hogy tovább kell lépnünk, mert bizonyos esetekben még mindig előfordulnak holtpontok. Például az operációs rendszer több szálon kérheti a különböző könyvtárakat, ami a szolgáltatásunk önmagára záródását okozza.
A problémán, amin most dolgozom, az Active Restore sebességének növelése és a rendszer biztonságának fokozása. Tegyük fel, hogy a rendszernek nem egy egész fájlra van szüksége, csak annak egy részére. Erre egy új illesztőprogramot fejlesztettek ki - egy szűrő illesztőprogramot. Ez már nem fájl szinten, hanem blokk szinten működik. A működési elv hasonló: a normál működési módban az illesztőprogram egyszerűen naplózza a lemezen történt módosított blokkokat, míg a helyreállítási módban megpróbálja önállóan elolvasni a blokkot, és ha ez nem sikerül, a szolgáltatástól kér prioritásnövelést. Közben a rendszer többi része változatlan marad. Például az operációs rendszer szintű szolgáltatás egyáltalán nem sejti, hogy egy másik illesztőprogrammal való kommunikációra próbálnak rávinni, mert a fő feladat a pontosan olyan adatok biztosítása, amelyek az operációs rendszer működéséhez szükségesek. Ez az irány jelentős fejlesztéseket igényel, legalábbis azért, mert a szolgáltatás még nem képes blokkszinten gondolkodni.
A következő lépésben úgy döntöttem, hogy az illesztőprogramot mélyebbre és korábban indítom, leereszkedve a UEFI illesztőprogramok és Native Windows alkalmazások szintjére a szolgáltatás helyett. Ehhez egy (vagy DXE illesztőprogramot) fejlesztettek ki, amely a művelet előtt már elindul és leáll. De az UEFI illesztőprogramok „történetét”, a telepítés és összeszerelés részleteit, valamint a Windows Native alkalmazások sajátosságait a következő bejegyzésben tárgyaljuk. Szóval iratkozzon fel a blogunkra, én addig készítek egy beszámolót a munka következő szakaszáról. Örömmel várom a megjegyzéseit és tanácsait.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Voltak olyan helyzetek, amikor a helyreállítás kínzóan hosszú ideig tartott:
65.1%Igen28
23.2%Nem10
11.6%Nem gondolkodtam rajta5
43 felhasználó szavazott. 3 felhasználó tartózkodott.
Forrás: habr.com
