Рэзервовае капіраванне важных дадзеных - гэта добра. Але што, калі працу трэба працягнуць адразу, і на рахунку кожная хвіліна? Мы ў 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. План быў такі:
- Запусціць драйвер на ранняй стадыі запуску АС,
- Падчас працы, калі будзе цалкам гатовы, загрузіць сэрвіс
- Сэрвіс апрацоўвае запыты драйвера і каардынуе яго наступную працу.
Тонкасці драйверабудавання
Калі пра сэрвіс мае калегі раскажуць у іншым пасце, то ў гэтым тэксце мы раскрыем тонкасці распрацоўкі драйвера. У ужо распрацаванага міні-фільтр драйвера ёсць два рэжыму працы - калі сістэма запусцілася ў штатным рэжыме, і калі сістэма толькі што перажыла збой і адбываецца яе аднаўленне. Да таго, як пайдзе загрузка карыстацкіх бібліятэк і прыкладанняў, а такім чынам і нашага сэрвісу, драйвер паводзіць сябе аднолькава. Ён не ведае, у якім са станаў зараз знаходзіцца сістэма. У выніку кожны create, read і write пратакалюецца, фіксуюцца ўсе мета-дадзеныя. А калі сэрвіс будзе анлайн, драйвер падае гэтую інфармацыю сэрвісу.
У выпадку звычайнага старту сэрвіс перадае драйверу сігнал "Relax", каб ён "расслабіўся" і перастаў скрупулёзна пратакаляваць усе дадзеныя. У гэтым выпадку драйвер пераходзіць на пратакаляванне толькі змен на кружэлцы і паведамляе аб іх сэрвісу, які з дапамогай іншых прылад Acronis падтрымлівае бэкап кружэлкі ў максімальна актуальным стане на тым носьбіце, які вызначыў карыстач. Гэта можа быць хмарнае, выдаленае, паступовае ці начное рэзервовае капіраванне.
Калі ўключаецца рэжым узнаўлення, сэрвіс паведамляе драйверу, што яму неабходна працаваць у рэжыме "Recovery". Сістэма толькі што аднавілася пасля збою, і як толькі яна дае запыт на адкрыццё файла на дыску, міні-фільтр павінен перахапіць дадзеную аперацыю, сам зрабіць гэты запыт, праверыць, ці ёсць такі файл на дыску і ці атрымліваецца яго адкрыць.
У выпадку адсутнасці файла, міні-фільтр перадае гэтую інфармацыю сэрвісу, які павялічвае прыярытэт узнаўлення файла (увесь гэты час фонам ідзе ўзнаўленне). Атрымліваецца, што гэты файл проста скача ў пачатак чаргі. Пасля гэтага сэрвіс сам (ці іншымі сродкамі Acronis) аднаўляе гэты файл і паведамляе драйверу што ўсё ок, зараз аперацыйная сістэма можа звяртацца да яго і драйвер "адпускае" арыгінальны запыт, ад сістэмы да дыска.
Калі ўзнаўленне немагчыма, сэрвіс паведамляе драйверу, што файла і ў бэкапе няма. Наш міні-фільтр драйвер проста прапускае сістэмны запыт далей ну і арыгінальны які запытвае (сама АС або прыкладанне) атрымлівае памылку "file not found". Зрэшты, гэта суцэль нармалёва, калі файла сапраўды не было на дыску і ў бэкапе.
Вядома, аперацыйная сістэма будзе працаваць нашмат павольней, таму што чытанне любога файла ці бібліятэкі адбываецца ў некалькі этапаў, прычым, магчыма, з доступам да выдаленых рэсурсаў. Але затое карыстач можа прыступіць да працы ў найкароткі тэрмін, пакуль аднаўленне ўсё яшчэ адбываецца.
Трэба ніжэй, яшчэ ніжэй…
Прататып даказаў сваю працаздольнасць. Але мы таксама выявілі запатрабаванне рухацца далей, таму што ў некаторых выпадках па-ранейшаму адбываюцца дзядлакі. Напрыклад, аперацыйная сістэма можа запытваць розныя бібліятэкі ў некалькі плыняў, што прыводзіць да замыкання нашага сэрвісу на самога сябе.
Праблема над якой я цяпер працую - гэта павышэнне хуткасці Active Restore і павышэнні ўзроўню бяспекі сістэмы. Дапушчальны, сістэме патрэбен не цэлы файл, неабходна толькі яго частка. Для гэтага быў распрацаваны яшчэ адзін драйвер - фільтр-драйвер дыска. Ён працуе ўжо не на файлавым, а на блокавым узроўні. Прынцып працы падобны: у нармальным рэжыме працы драйвер проста пратакалюе змененыя блокі на дыску, а ў рэжыме аднаўлення, спрабуе прачытаць блок самастойна, у выпадку няўдачы запытвае ў сэрвісу павышэнне прыярытэту. Пры гэтым усе астатнія часткі сістэмы застаюцца такімі ж. Напрыклад, сэрвіс узроўня АС нават не падазрае, што яму прапануюць мець зносіны з іншым драйверам, таму што галоўная задача - падаць АС менавіта тыя дадзеныя, якія неабходныя для функцыянавання. Дадзены кірунак патрабуе істотных дапрацовак хаця б таму што сэрвіс яшчэ не ўмее думаць на блокавым узроўні.
Наступным крокам я вырашыў запусціць драйвер глыбей і раней, апусціўшыся на ўзровень UEFI драйвераў і Native Windows прыкладанняў замест сэрвісу. Для гэтага быў распрацаваны (або DXE драйвер), які стартуе і памірае яшчэ да старту АС. Але "гісторыю" UEFI драйвераў, падрабязнасці аб зборцы і ўстаноўцы, а таксама спецыфіцы Windows Native прыкладанняў, мы разгледзім у наступным пасце. Так што падпісвайцеся на наш блог, а я пакуль падрыхтую аповяд аб наступным этапе прац. Буду рады вашым каментарам і парадам.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
Ці бывалі ў вас сітуацыі, калі аднаўленне працягвалася пакутліва доўга:
-
65.1%Так28
-
23.2%Няма10
-
11.6%Не задумваўся5
Прагаласавалі 43 карыстальніка. Устрымаліся 3 карыстальніка.
Крыніца: habr.com