Хабрахабр

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

Резервное копирование важных данных – это хорошо. Но что если работу нужно продолжить сразу, и на счету каждая минута? Мы в Acronis решили проверить, насколько возможно решить задачу максимально быстрого запуска системы. И это первый пост из серии Active Restore, в котором я расскажу, как мы приступили к проекту вместе с Университетом Иннополис, какое нашли решение, и над чем работаем сегодня. Подробности – под катом.

Меня зовут Даулет Тумбаев, и сегодня мне хочется поделиться с вами своим опытом разработки системы, ускоряющей аварийное восстановление. image
Привет! Сейчас я работаю в Acronis, но также являюсь выпускником Университета Иннополис, который я заканчивал по программе магистратуры “Управление разработкой ПО” (известной как MSIT-SE). Чтобы рассказать обо всем пути развития проекта, начнем немного издалека. Но зато она построена на учебных планах Университета Карнеги-Меллона (Carnegie Mellon University), в наработках которого есть такая тема, как индустриальные проекты. Иннополис – молодой университет, а учебная программа – еще моложе.

Для этого университет сотрудничает с такими компаниями, как Яндекс, Acronis, MTC и десятками других (всего на 2018 год у вуза было 144 партнера). Цель индустриального проекта – погрузить студента в реальную разработку и закрепить полученные знания на практике. Буквально два года назад я еще был “по ту сторону баррикад” и работал как студент над другим проектом Acronis. В ходе сотрудничества компании предлагают университету свои рабочие направления, а студенты выбирают один из проектов, который им ближе по интересам и уровню подготовки. Сама идея Active Restore была сформулирована командой Kernel в компании Acronis, однако разработка решения началась вместе с Университетом Иннополис. Но в этот раз я стал техническим консультантом для студентов со стороны компании и предложил Иннополису проект Active Restore.

Active Restore – зачем это нужно?

Традиционно аварийное восстановление работает по стандартной схеме. После неприятностей с компьютером, вы заходите в веб-интерфейс какой-то системы резервного копирования, например, Acronis True Image, и нажимаете большую кнопку “восстановить”. Далее нужно подождать N минут, и только после этого вы сможете продолжить работу.

Можно ли его уменьшить? Проблема заключается в том, что это число N, известное так же как RTO (recovery time objective), допустимое время восстановления, может быть весьма внушительным, которое зависит от скорости соединения (если происходит восстановление из облака), от объема жесткого диска вашей машины и ряда других факторов. Те же фото и видео никак не сказываются на функциональности устройства и могут быть подтянуты позже в фоновом режиме. Да, можно, ведь для того, чтобы возобновить работу не всегда нужен полный диск компьютера.

Driver needed...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»