Правењето резервна копија на важни податоци е добра работа. Но, што ако работата треба да продолжи веднаш и секоја минута е важна? Ние во Acronis решивме да провериме колку е можно да се реши проблемот со стартување на системот што е можно побрзо. И ова е првиот пост од серијата Active Restore, во кој ќе ви кажам како го започнавме проектот заедно со Универзитетот Иннополис, какво решение најдовме и на што работиме денес. Деталите се под сечењето.
Здраво! Јас се викам Даулет Тумбаев и денес би сакал да го споделам со вас моето искуство во развојот на систем кој го забрзува обновувањето при катастрофи. За да зборуваме за целиот развојен пат на проектот, да почнеме малку од далеку. Моментално работам во Acronis, но исто така сум дипломиран на Универзитетот Иннополис, каде што ја завршив магистерската програма за управување со развој на софтвер (позната како MSIT-SE). Иннополис е млад универзитет, а наставната програма е уште помлада. Но, таа е изградена на наставната програма на Универзитетот Карнеги Мелон, чија работа вклучува таква тема како индустриски проекти.
Целта на индустрискиот проект е да го потопи ученикот во вистински развој и да го консолидира стекнатото знаење во пракса. За да го направите ова, универзитетот соработува со компании како што се Yandex, Acronis, MTC и десетици други (вкупно, од 2018 година, универзитетот имаше 144 партнери). Во текот на соработката, компаниите ги нудат своите работни области на универзитетот, а студентите избираат еден од проектите што е поблизок до нивните интереси и степен на обука. Буквално пред две години сè уште бев „од другата страна на барикадите“ и работев како студент на друг проект на Acronis. Но, овој пат станав технички консултант за студенти од страната на компанијата и го предложив проектот Active Restore на Innopolis. Самата идеја за Active Restore беше формулирана од тимот на Kernel во Acronis, но развојот на решението започна заедно со Универзитетот Innopolis.
Активно обновување - зошто е потребно?
Традиционално, обновувањето при катастрофи работи според стандардна шема. По проблеми со вашиот компјутер, одите на веб-интерфејсот на некој резервен систем, на пример, Acronis True Image, и кликнете на големото копче „обновување“. Следно, треба да почекате N минути, а само после тоа можете да продолжите да работите.
Проблемот е во тоа што овој број N, исто така познат како RTO (објект за време на обновување), дозволеното време за обновување, може да биде доста импресивен, што зависи од брзината на поврзувањето (ако обновувањето е од облакот), големината на тврдиот диск на вашата машина , и низа други фактори. Дали е можно да се намали? Да, можете, бидејќи за да продолжите со работа не секогаш ви треба целосен компјутерски диск. Истите фотографии и видеа не влијаат на функционалноста на уредот на кој било начин и може да се повлечат подоцна во заднина.
Потребен е возач...
Оперативниот систем очекува да стартува со целосно подготвен диск. Затоа Windows Врши серија проверки на интегритетот на дискот. Системот нема да дозволи нормално стартување ако некои датотеки што оперативниот систем очекува да ги пронајде недостасуваат или се оштетени. За да го решиме овој проблем, решивме да поставиме таканаречени датотеки за пренасочување на дискот. Овие датотеки ги заменуваат датотеките што недостасуваат или се оштетени, но во суштина се лажни датотеки. Креирањето на овие пренасочувачи е многу лесно, бидејќи тие всушност не содржат никаква содржина.
Понатамошната реставрација се случува на следниов начин. Со процес на позадина, паралелно со работата на оперативниот систем, „куклата“ се полни со податоци. Процесот на обновување на позадината го зема предвид оптоварувањето на дискот и не ја надминува поставената граница. Сепак, корисникот или самиот оперативен систем може одеднаш да побараат датотека што сè уште не постои. Ова е местото каде што стапува во игра вториот режим за обновување. Приоритетот на бараната датотека се зголемува до максимум, а процесот на обновување итно ја вчитува датотеката на дискот. Оперативниот систем ја прима потребната датотека, иако со мало задоцнување.
Вака изгледа идеална слика. Меѓутоа, во реалниот свет има огромен број замки и потенцијални ќор-сокак. Заедно со магистерските студенти на Иннополис, решивме да го истражиме ова сценарио за закрепнување, да ги оцениме придобивките во RTO и да разбереме дали таков пристап е изводлив? На крајот на краиштата, во тоа време едноставно немаше такви решенија на пазарот.
И ако решив да им ја подадам услугата компонента на момците од Иннополис, тогаш во рамките на Acronis започна работата Тимот се погрижи за ова. Windows Јадро. Планот беше ваков:
- Стартувајте го драјверот во рана фаза на стартување на ОС,
- За време на работа, кога ќе биде целосно подготвен, преземете ја услугата
- Услугата ги обработува барањата на возачот и ја координира нејзината понатамошна работа.
Суптилностите на инженерството на возачите
Ако моите колеги ќе зборуваат за услугата во друг пост, тогаш во овој текст ќе ги откриеме сложеноста на развојот на возачот. Веќе развиениот драјвер за мини-филтер има два режима на работа - кога системот стартуваше во нормален режим и кога системот штотуку доживеа дефект и се обновува. Пред да се вчитаат корисничките библиотеки и апликации, а со тоа и нашата услуга, возачот се однесува исто. Тој не знае во која состојба моментално е системот. Како резултат на тоа, секое креирање, читање и пишување е евидентирано и сите метаподатоци се запишуваат. И кога услугата е онлајн, возачот ги дава овие информации на услугата.
Во случај на нормален старт, услугата испраќа сигнал „Опушти“ на возачот, така што тој „се опушти“ и престанува скрупулозно да ги евидентира сите податоци. Во овој случај, двигателот се префрла на евидентирање само промени на дискот и ги известува на услугата, која, користејќи други алатки на Acronis, ја одржува резервната копија на дискот во најсовремена состојба на медиумот наведен од корисникот. Ова може да биде облак, далечински, постепен или ноќен бекап.
Ако режимот за обновување е овозможен, услугата му кажува на возачот дека треба да работи во режимот „Обнова“. Системот штотуку се опорави од падот, и штом ќе поднесе барање за отворање датотека на дискот, мини-филтерот мора да ја пресретне оваа операција, да го направи ова барање самиот, да провери дали таква датотека постои на дискот и дали може да се отвори.
Ако датотеката недостасува, мини-филтерот ги пренесува овие информации до услугата, со што се зголемува приоритетот на обновување на датотеката (сето ова време, обновувањето се одвива во позадина). Излегува дека оваа датотека едноставно скока на почетокот на редот. После ова, самата услуга (или други средства на Acronis) ја обновува оваа датотека и му кажува на возачот дека сè е во ред, сега оперативниот систем може да пристапи до него и драјверот го „пушта“ оригиналното барање, од системот до дискот.
Ако обновувањето е невозможно, услугата го информира возачот дека датотеката не е во резервната копија. Нашиот двигател за мини-филтер едноставно го пренесува системското барање понатаму и оригиналниот барател (самиот ОС или апликацијата) добива грешка „датотеката не е пронајдена“. Сепак, ова е сосема нормално ако датотеката навистина не била на дискот и во резервната копија.
Се разбира, оперативниот систем ќе работи многу побавно, бидејќи читањето на која било датотека или библиотека се случува во неколку фази, можеби со пристап до оддалечени ресурси. Но, корисникот може да се врати на работа што е можно поскоро додека опоравувањето сè уште се одвива.
Треба пониско, уште пониско...
Прототипот ја докажа својата функционалност. Но, најдовме и потреба да продолжиме понатаму бидејќи во некои случаи сè уште има ќор-сокак. На пример, оперативниот систем може да бара различни библиотеки во неколку нишки, што доведува до тоа нашата услуга да се врати на себе.
Проблемот на кој моментално работам е зголемување на брзината на Active Restore и зголемување на нивото на безбедност на системот. Да речеме дека на системот не му е потребна целата датотека, туку само дел од неа. За таа цел, беше развиен уште еден двигател - двигател за филтер за диск. Веќе не работи на ниво на датотека, туку на ниво на блок. Принципот на работа е сличен: во нормалниот режим на работа, возачот едноставно ги евидентира променетите блокови на дискот, а во режимот за обновување, тој се обидува сам да го прочита блокот и ако не успее, бара услугата да го зголеми приоритетот. Сепак, сите други делови од системот остануваат исти. На пример, услугата на ниво на ОС дури и не се сомнева дека од неа се бара да комуницира со друг возач, бидејќи главната задача е да му ги обезбеди на ОС точно податоците што се неопходни за работа. Оваа област бара значителни подобрувања, само затоа што услугата сè уште не знае како да размислува на ниво на блок.
Следниот чекор што го презедов беше да го инсталирам драјверот подлабоко и порано, спуштајќи се до UEFI драјверот и Native ниво. Windows апликации наместо услуга. За таа цел, беше развиена (или DXE драјвер), кој се стартува и умира дури и пред да се стартува оперативниот систем. Но, „историјата“ на UEFI драјверите, деталите за склопување и инсталација и спецификите Windows Ќе ги разгледаме нативните апликации во следната објава. Затоа, претплатете се на нашиот блог додека јас подготвувам приказна за следната фаза од нашата работа. Би сакал да ги чујам вашите коментари и предлози.
Само регистрирани корисници можат да учествуваат во анкетата. , вие сте добредојдени.
Дали некогаш сте имале ситуации кога закрепнувањето траело измачувано долго:
65.1%Да 28
23.2%Бр 10 г
11.6%Не размислував за тоа5
Гласаа 43 корисници. 3 корисници се воздржаа.
Извор: www.habr.com
