Резервното копиране на важни данни е добра практика. Но какво, ако работата трябва да продължи веднага и всяка минута е от значение? В Acronis решихме да проверим доколко е възможно да се постигне максимално бързо стартиране на системата. Това е първият пост от серията Active Restore, в който ще разкажа как започнахме проекта с Университета Иннополис, какво решение намерихме и по какво работим в момента. Подробности - под кат.
Здравейте! Аз съм Даулет Тумбаев и днес искам да споделя с вас опита си в разработката на система, която ускорява аварийните възстановявания. За да разкажа за целия път на развитие на проекта, нека започнем отдалеч. В момента работя в Acronis, но също съм възпитаник на Университета Иннополис, който завърших по магистърската програма "Управление на разработката на софтуер" (известна като MSIT-SE). Иннополис е млад университет, а учебната програма е още по-млада. Но е построена на основата на учебните планове на Университета Карнеги-Мелън (Carnegie Mellon University), в които има теми като индустриални проекти.
Целта на индустриалния проект е да потопи студента в реалната разработка и да затвърди получените знания на практика. За целта университетът си сътрудничи с компании като Яндекс, Acronis, MTC и десетки други (към 2018 година университетът имаше 144 партньора). В процеса на сътрудничество компаниите предлагат на университета свои работни насоки, а студентите избират един от проектите, който им е най-близък по интереси и ниво на подготовка. Само преди две години бях "от другата страна на барикадата" и работех като студент по друг проект на Acronis. Но този път станах технически консултант за студентите от страна на компанията и предложих на Иннополис проекта Active Restore. Самата идея за Active Restore бе формулирана от екипа Kernel в компанията Acronis, но разработката на решението започна в сътрудничество с Университета Иннополис.
Active Restore – защо е нужно?
Традиционно аварийната възстановяване работи по стандартна схема. След проблеми с компютъра, влизате в уеб интерфейса на някоя система за архивиране, например Acronis True Image, и натискате голямото бутон "възстанови". След това трябва да изчакате N минути, и само след това ще можете да продължите работа.
Проблемът е, че това число N, известно и като RTO (целева време за възстановяване), допустимо време за възстановяване, може да бъде доста значително и зависи от скоростта на връзката (ако възстановяването се извършва от облака), от обема на硬кия диск на вашата машина и редица други фактори. Може ли да бъде намалено? Да, може, тъй като за възобновяване на работата не винаги е необходим целият диск на компютъра. Снимките и видеата не влияят на функционалността на устройството и могат да бъдат възстановени по-късно на заден план.
Изисква се драйвер...
Операционната система се планира да стартира с напълно готов диск. Затова Windows извършва редица проверки за целостта на диска. Системата няма да позволи нормално стартиране при липса или повреда на някои файлове, които ОС очаква да намери. За решение на този проблем беше решено да поставим на диска създадените от нас, така наречени, файлове-редиректори, които заменят липсващите или повредени файлове, а де факто са празни. Създаването на такива редиректори не отнема много време, тъй като те де факто нямат никакво съдържание.
След това възстановяването протича по следния начин. В заден процес, паралелно с работата на операционната система, "празните" файлове се запълват с данни. Процесът на фоново възстановяване отчита натоварването на диска и не надвишава зададения лимит. Въпреки това потребителят или самата операционна система може неочаквано да изиска файл, който все още не съществува. Тук влиза в действие вторият режим на възстановяване. Приоритетът на изисквания файл се увеличава до максималния, а процесът на възстановяване спешно зарежда файла на диска. Операционната система получава необходимия файл, макар и с малко забавяне.
Така изглежда идеалната картина. Въпреки това, в реалния свят съществува огромно количество подводни камъни и потенциални задънени улици. Заедно с магистрантите от Иннополис решихме да изследваме този сценарий за възстановяване, да оценим печалбата в RTO и да разберем дали такъв подход е осъществим. В момента на пазара нямаше подобни решения.
И ако реших да оставя сервизната част на ребятата от Иннополис, то вътре в Acronis започна работа по . За това се зае екипът на Windows Kernel. Планът беше следния:
- Да стартира драйвера на ранния етап на зареждане на ОС,
- По време на работа, когато ще бъде напълно готов, да зареди сервиза.
- Сервизът обработва заявките на драйвера и координира неговата по-нататъшна работа.
Тънкости на драйверостроенето
Ако моите колеги ще разкажат за сервиза в друг пост, в този текст ще разкрием тънкостите на разработката на драйвера. Вече разработеният мини-филтър драйвер има два режима на работа - когато системата е стартирана в нормален режим и когато системата току-що е преживяла срив и се възстановява. Преди да започне зареждането на потребителските библиотеки и приложения, а следователно и на нашия сервиз, драйверът се държи по един и същ начин. Той не знае в какъв статус е системата. В резултат на това всяко събитие create, read и write се записва, фащат се всички мета-данни. А когато сервизът стане онлайн, драйверът предоставя тази информация на сервиза.
В случай на нормален старт, сервизът предава на драйвера сигнал "Relax", за да "се отпусне" и да спре скрупульозно да записва всички данни. В този случай драйверът преминава на записване само на промените на диска и уведомява за тях сервиза, който с помощта на други инструменти на Acronis поддържа резервното копие на диска в максимално актуално състояние на носителя, определен от потребителя. Това могат да бъдат облачно, дистанционно, постепенно или нощно резервно копиране.
Ако режимът на възстановяване е активиран, услугата информира драйвера, че трябва да работи в режим "Recovery". Системата току-що се е възстановила след срив и щом подаде заявка за отваряне на файл на диска, мини-филтърът трябва да прихване тази операция, сам да извърши заявката, да провери дали файлът съществува на диска и дали може да бъде отворен.
В случай че файлът липсва, мини-филтърът предава тази информация на услугата, която увеличава приоритета на възстановяване на файла (през това време се извършва възстановяване на заден план). Файлът просто преминава на преден план в опашката. След това услугата самостоятелно (или с помощта на други средства на Acronis) възстановява файла и информира драйвера, че всичко е наред, сега операционната система може да го достъпи, а драйверът "отпуска" оригиналната заявка от системата към диска.
Ако възстановяването не е възможно, услугата информира драйвера, че файлът отсъства и в резервното копие. Нашият мини-филтър просто пропуска системната заявка напред и оригиналният запитващ (самата ОС или приложение) получава грешка "file not found". Всъщност, това е напълно нормално, ако файлът наистина не е бил на диска и в резервното копие.
Разбира се, операционната система ще работи много по-бавно, тъй като четенето на всякакъв файл или библиотека става на няколко етапа, възможно и с достъп до отдалечени ресурси. Но потребителят може да започне работа в най-кратък срок, докато възстановяването все още се извършва.
Трябва по-надолу, още по-надолу…
Прототипът доказа своята работоспособност. Но ние също така открихме необходимостта да продължим напред, тъй като в някои случаи все още се случват дедложи. Например, операционната система може да иска различни библиотеки в няколко потока, което води до блокиране на нашата услуга сама за себе си.
Проблема, над която в момента работя, е да се увеличи скоростта на Active Restore и да се повиши нивото на сигурност на системата. Да предположим, че на системата не е нужен целият файл, а само част от него. За целта беше разработен още един драйвер - филтър-драйвер за диска. Той работи не на файлово, а на блоково ниво. Принципът на работа е сходен: в нормален режим на работа драйверът просто протоколира променените блокове на диска, а в режим на възстановяване, опитва да прочете блока самостоятелно, и в случай на неуспех, иска от услугата да повиши приоритета. При това всички останали части на системата остават непроменени. Например, услугата на ниво ОС дори не подозира, че й предлагат да комуникира с друг драйвер, защото основната задача е да предостави на ОС именно данните, които са необходими за функционирането. Това направление изисква съществени доработки, поне защото услугата все още не умее да мисли на блоково ниво.
Следващата стъпка реших да бъде стартирането на драйвера по-дълбоко и по-рано, спускайки се на ниво драйвери UEFI и нативни Windows приложения вместо услугата. За целта беше разработен или DXE драйвер, който стартира и умира още преди старта на ОС. Но 'историята' на UEFI драйверите, подробностите за изграждане и инсталация, както и спецификата на Windows нативните приложения, ще разгледаме в следващия пост. Така че се подпишете на нашия блог, а аз ще подготвя разказ за следващия етап от работата. Ще се радвам на вашите коментари и съвети.
Само регистрирани потребители могат да участват в анкетата. , моля.
Случвало ли ви се е да имате ситуации, когато възстановяването продължава ужасно дълго:
65.1%Да28
23.2%Не10
11.6%Не съм мислил5
Гласували 43 потребители. Въздържали се 3 потребители.
Източник: habr.com
