Active Restore: может ли аварийное восстановление происходить быстрее? Намного быстрее?

Резервное копирование важных данных – это хорошо. Но что если работу нужно продолжить сразу, и на счету каждая минута? Мы в 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 (recovery time objective), допустимое время восстановления, может быть весьма внушительным, которое зависит от скорости соединения (если происходит восстановление из облака), от объема жесткого диска вашей машины и ряда других факторов. Можно ли его уменьшить? Да, можно, ведь для того, чтобы возобновить работу не всегда нужен полный диск компьютера. Те же фото и видео никак не сказываются на функциональности устройства и могут быть подтянуты позже в фоновом режиме.

Driver needed…

Операционная система рассчитывает запускаться с полностью готовым диском. Поэтому Windows проводит ряд проверок на целостность диска. Система не позволит произвести нормальный запуск при отсутствии или повреждении некоторых файлов, которые ОС ожидает найти. Для решений этой проблемы было решено подложить на диск созданные нами, так называемые, файлы-редиректоры, которые заменяют отсутствующие или поврежденные файлы, но по факту являются пустышками. Создать такие редиректоры совсем недолго, ведь они по факту не имеют никакого содержимого.

Далее восстановление происходит следующим образом. Фоновым процессом, параллельно с работой операционной системы, «пустышки» наполняются данными. Процесс фонового восстановления учитывает нагрузку на диск и не превышает установленный лимит. Однако пользователь или сама операционная система может внезапно потребовать файл, которого еще нет. Тут в дело вступает второй режим восстановления. Приоритет затребованного файла повышается до максимального, и процесс восстановления в срочном порядке подгружает файл на диск. Операционная система получает нужный файл, хоть и с небольшой задержкой.

Так выглядит идеальная картина. Однако в реальном мире, существует огромное количество подводных камней и потенциальных дедлоков. Вместе с магистрантами Иннополиса мы решили исследовать данный сценарий восстановления, оценить выигрыш в RTO, и понять, осуществим ли такой подход? Ведь подобных решений на рынке просто не было на тот момент.

И если сервисную составляющую я решил отдать на откуп ребятам из Иннополиса, то внутри Acronis началась работа над мини-фильтр драйвером файловой системы. Этим занялась команда Windows Kernel. План был такой:

• Запустить драйвер на ранней стадии запуска ОС,
• Во время работы, когда user space будет полностью готов, загрузить сервис
• Сервис обрабатывает запросы драйвера и координирует его дальнейшую работу.

Тонкости драйверостроения

Если про сервис мои коллеги расскажут в другом посте, то в этом тексте мы раскроем тонкости разработки драйвера. У уже разработанного мини-фильтр драйвера есть два режима работы – когда система запустилась в штатном режиме, и когда система только что пережила сбой и происходит ее восстановление. До того, как пойдет загрузка пользовательских библиотек и приложений, а следовательно и нашего сервиса, драйвер ведет себя одинаково. Он не знает, в каком из состояний сейчас находится система. В результате каждый create, read и write протоколируется, фиксируются все мета-данные. А когда сервис будет онлайн, драйвер предоставляет эту информацию сервису.

В случае обычного старта сервис передает драйверу сигнал “Relax”, чтобы он “расслабился” и перестал скрупулезно протоколировать все данные. В этом случае драйвер переходит на протоколирование только изменений на диске и сообщает о них сервису, который с помощью других инструментов Acronis поддерживает бэкап диска в максимально актуальном состоянии на том носителе, который определил пользователь. Это может быть облачное, удаленное, постепенное или ночное резервное копирование.

Если включается режим восстановления, сервис сообщает драйверу, что ему необходимо работать в режиме “Recovery”. Система только что восстановилась после сбоя, и как только она дает запрос на открытие файла на диске, мини-фильтр должен перехватить данную операцию, сам сделать этот запрос, проверить, есть ли такой файл на диске и получается ли его открыть.

В случае отсутствия файла, мини-фильтр передает эту информацию сервису, который повышает приоритет восстановления файла (все это время фоном идет восстановление). Получается, что этот файл просто прыгает в начало очереди. После этого сервис сам (или другими средствами Acronis) восстанавливает этот файл и сообщает драйверу что все ок, теперь операционная система может обращаться к нему и драйвер “отпускает” оригинальный запрос, от системы к диску.

Если восстановление невозможно, сервис сообщает драйверу, что файла и в бэкапе нет. Наш мини-фильтр драйвер просто пропускает системный запрос дальше ну и оригинальный запрашивающий (сама ОС или приложение) получает ошибку “file not found”. Впрочем, это вполне нормально, если файла действительно не было на диске и в бэкапе.

Конечно, операционная система будет работать намного медленнее, потому что чтение любого файла или библиотеки происходит в несколько этапов, причем, возможно, с доступом к удаленным ресурсам. Но зато пользователь может приступить к работе в кратчайший срок, пока восстановление все еще происходит.

Нужно ниже, еще ниже…

Прототип доказал свою работоспособность. Но мы также обнаружили потребность двигаться дальше, потому что в некоторых случаях по-прежнему происходят дедлоки. Например, операционная система может запрашивать различные библиотеки в несколько потоков, что приводит к замыканию нашего сервиса на самого себя.

Проблема над которой я сейчас работаю – это повышение скорости Active Restore и повышении уровня безопасности системы. Допустим, системе нужен не целый файл, необходима лишь его часть. Для этого был разработан еще один драйвер — фильтр-драйвер диска. Он работает уже не на файловом, а на блочном уровне. Принцип работы схожий: в нормальном режиме работы драйвер просто протоколирует измененные блоки на диске, а в режиме восстановления, пробует прочитать блок самостоятельно, в случае неудачи запрашивает у сервиса повышение приоритета. При этом все остальные части системы остаются такими же. Например, сервис уровня ОС даже не подозревает, что ему предлагают общаться с другим драйвером, потому что главная задача – предоставить ОС именно те данные, которые необходимы для функционирования. Данное направление требует существенных доработок хотя бы потому что сервис еще не умеет думать на блочном уровне.

Следующим шагом я решил запустить драйвер глубже и раньше, опустившись на уровень UEFI драйверов и Native Windows приложений вместо сервиса. Для этого был разработан UEFI boot драйвер (или DXE драйвер), который стартует и умирает еще до старта ОС. Но “историю” UEFI драйверов, подробности о сборке и установке, а также специфике Windows Native приложений, мы рассмотрим в следующем посте. Так что подписывайтесь на наш блог, а я пока подготовлю рассказ о следующем этапе работ. Буду рад вашим комментариям и советам.