Резервирането на важни данни е важно. Но какво, ако е необходимо веднага да продължите работа и всяка минута е от значение? В Acronis решихме да проверим колко е възможно да се реши задачата с максимално бързо стартиране на системата. Това е първият пост от серията Active Restore, в която ще разкажа как започнахме проекта заедно с Университета Иннополис, какво решение намерихме и по какво работим в момента. Повече подробности след прочита.
Здравейте! Аз съм Даулет Тумбаев и днес бих искал да споделя опита си в разработването на система, която ускорява възстановяването след инцидент. За да разкажа за целия път на развитие на проекта, ще започнем малко отдалеч. В момента работя в Acronis, но също съм завършил Университета Иннополис, който завърших по магистратура "Управление на софтуерното развитие" (известна като MSIT-SE). Иннополис е млад университет, а учебната програма е още по-млада. Но тя е изградена на основата на учебните планове на Университета Карнеги-Мелън (Carnegie Mellon University), които имат теми, свързани с индустриални проекти.
Целта на индустриалния проект е да потопи студента в реална разработка и да укрепи получените знания на практика. За целта университетът си сътрудничи с компании като Яндекс, Acronis, МТС и десетки други (всъщност, през 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) възстановява файла и уведомява драйвера, че всичко е наред, сега операционната система може да се свърже с него и драйверът „освобождава“ оригиналната заявка, от системата към диска.
Ако възстановяването е невъзможно, службата уведомява драйвера, че файла няма и в резервното копие. Нашият мини-филтър драйвер просто пропуска системната заявка напред и оригиналната искане (самата ОС или приложение) получава грешка „файлът не е намерен“. Въпреки това, това е напълно нормално, ако файлът действително не е бил на диска и в резервното копие.
Разбира се, операционната система ще работи много по-бавно, защото прочитането на всеки файл или библиотека се извършва в няколко етапа, с възможен достъп до отдалечени ресурси. Но потребителят може да започне работа в най-кратък срок, докато възстановяването все още протича.
Трябва по-долу, още по-долу...
Прототипът доказа своята работоспособност. Но ние също така открихме необходимостта да се движим напред, тъй като в някои случаи все още се случват блокировки. Например, операционната система може да запрашва различни библиотеки в няколко потока, което води до блокиране на нашата служба сама на себе си.
Проблемата, по която работя в момента, е увеличаването на скоростта на Active Restore и повишаването на нивото на безопасност на системата. Да речем, че системата не се нуждае от целия файл, а само от част от него. За това беше разработен още един драйвер - филтър-драйвер на диска. Той работи не на файлово, а на блоково ниво. Принципът на работа е сходен: в нормалния режим на работа драйверът просто регистрира променените блокове на диска, а в режим на възстановяване опитва да прочете блока самостоятелно, а в случай на неуспех изисква от услугата повишаване на приоритета. При това всички други части на системата остават същите. Например, услугата на ниво ОС дори не подозира, че ѝ предлагат да комуникира с друг драйвер, тъй като основната задача е да предостави на ОС именно тези данни, които са нужни за функционирането. Това направление изисква съществени подобрения поне защото услугата все още не умее да мисли на блоково ниво.
Следващата стъпка, която реших да предприема, е да стартирам драйвера по-дълбоко и по-рано, слезвайки на ниво UEFI драйвери и Native Windows приложения вместо услугата. За целта беше разработен (или DXE драйвер), който стартира и умира още преди старта на ОС. Но ‘историята’ на UEFI драйверите, подробностите относно сборката и инсталацията, както и спецификата на Native Windows приложения, ще разгледаме в следващия пост. Така че се абонирайте за нашия блог, а аз ще подготвя разказ за следващия етап от работата. Ще се радвам на вашите коментари и съвети.
Само регистрирани потребители могат да участват в анкетата. , моля.
Случвало ли ви се е да имате ситуации, в които възстановяването продължава бавно:
65.1%Да28
23.2%Не10
11.6%Не бях се замислял
Гласуваха 43 потребители. Въздържаха се 3 потребители.
Източник: habr.com
