Kopjimi i rezervës së të dhënave të rëndësishme është i rëndësishëm. Por çfarë nëse puna duhet të vazhdojë menjëherë, dhe çdo minutë ka rëndësi? Ne në Acronis vendosëm të shqyrtojmë se sa shpejt mund ta zgjidhim sfidën e nisjes sa më shpejt të sistemit. Ky është postimi i parë në serinë Active Restore, ku do të tregoj se si filluam projektin në bashkëpunim me Universitetin Innopolis, cila ishte zgjidhja që gjetëm, dhe çfarë po punojmë sot. Detajet më poshtë.
Përshëndetje! Emri im është Daulat Tumbaev, dhe sot dua të ndaj me ju përvojën time në zhvillimin e një sistemi që përshpejton rikuperimin emergjent. Për të treguar të gjithë rrugën e zhvillimit të projektit, le të fillojmë nga pak më larg. Tani punoj në Acronis, por gjithashtu jam një diplomant i Universitetit Innopolis, të cilin e përfundova në programin e magjistraturës në "Menaxhimin e Zhvillimit të Softuerit" (në njohur si MSIT-SE). Innopolis është një universitet i ri, dhe programa mësimore është edhe më e re. Megjithatë, ajo është ndërtuar mbi planin mësimor të Universitetit Carnegie Mellon, i cili ka një temë të tillë si projektet工业。
Qëllimi i projektit industrial është të zhytë studentin në zhvillimin real dhe të forcojë njohuritë e fituara në praktikë. Për këtë, universiteti bashkëpunon me kompani si Yandex, Acronis, MTC dhe dhjetëra të tjera (në vitin 2018, universiteti kishte gjithsej 144 partnerë). Gjatë bashkëpunimit, kompanitë ofrojnë universitetit drejtimet e tyre të punës, dhe studentët zgjedhin një nga projektet që iu përshtatet më shumë sipas interesave dhe nivelit të përgatitjes. Vetëm dy vjet më parë isha "në anën tjetër të barricadës" dhe punoja si student në një projekt tjetër të Acronis. Por këtë herë u bëra këshilltar teknik për studentët nga ana e kompanisë dhe i propozoja Universitetit Innopolis projektin Active Restore. Ideja e vetë Active Restore u formulua nga ekipi Kernel në Acronis, megjithatë, zhvillimi i zgjidhjes filloi së bashku me Universitetin Innopolis.
Active Restore – përse është e nevojshme?
Tradicionalisht, rikuperimi nga fatkeqësitë funksionon sipas një skeme standarde. Pas ndodhisë së pakëndshme me kompjuterin tuaj, ju futeni në ndërfaqen në internet të një sistemi kopjimi, si Acronis True Image, dhe klikoni butonin e madh “rikupero”. Më pas, duhet të prisni N minuta, dhe vetëm pas kësaj do të jeni në gjendje të vazhdoni punën.
Problemi është se ky numër N, i njohur gjithashtu si RTO (objektivi i kohës së rikuperimit), kohëzgjatja e pranueshme për rikuperim, mund të jetë mjaft e konsiderueshme, e cila varet nga shpejtësia e lidhjes (nëse rikuperimi realizohet nga облак), nga kapaciteti i hard diskut tuaj dhe nga një sërë faktorësh të tjerë. A është e mundur ta reducioni atë? Po, është e mundur, sepse për të vazhduar punën, nuk është gjithmonë e nevojshme të keni një disk të plotë kompjuteri. Të njëjtat fotografi dhe video nuk ndikojnë aspak në funksionalitetin e pajisjes dhe mund të tërhiqen më vonë në sfond.
Shoferi nevoitet...
Sistemi operativ parashikon të fillojë me një disk plotësisht të gatshëm. Prandaj, Windows bën një sërë kontrollesh për integritetin e diskut. Sistemi nuk do të lejojë një fillim normal në mungesë ose dëmtim të disa skedareve që OS-a pritet të gjejë. Për zgjidhjen e këtij problemi, u vendos të vendosnim skedaret e ashtuquajtur të ridirektuar në disk, të cilat zëvendësojnë skedaret që mungojnë ose janë të dëmtuara, por në fakt janë bosh. Të krijosh një të tillë është krejtësisht e shpejtë, sepse ato në fakt nuk kanë asnjë përmbajtje.
Më pas rikuperimi ndodh siç vijon. Me një proces në sfond, paralelisht me punën e sistemit operativ, "boshllëqet" mbushen me të dhëna. Procesi i rikuperimit në sfond merr parasysh ngarkesën në disk dhe nuk e tejkalon kufirin e vendosur. Sidoqoftë, përdoruesi ose vetë sistemi operativ mund të kërkojë papritur një skedar që ende nuk egziston. Këtu hyn në lojë mode të dytë të rikuperimit. Prioriteti i skedarit të kërkuar rritet në maksimum, dhe procesi i rikuperimit ngarkohet me urgjencë skedarin në disk. Sistemi operativ merr skedarin e nevojshëm, ndonëse me një vonesë të vogël.
Kjo është pamja e përkryer. Megjithatë, në botën reale ka një sasi të madhe pengesash dhe potencialesh bllokimesh. Së bashku me studentët e magjistraturës në Innopolis, ne vendosëm të hulumtojmë këtë skenar rikuperimi, të vlerësojmë përfitimin në RTO dhe të kuptojmë nëse një qasje e tillë është e mundur. Në atë kohë, nuk kishte zgjidhje të tilla në treg.
Dhe nëse komponentin shërbyes e besoja ekipit nga Innopolis, brenda Acronis filloi puna mbi . Ekipi i Windows Kernel u angazhua për këtë. Plani ishte:
- Të aktivizohet drejtori në një fazë të hershme të startit të OS-së,
- Gjatë punës, kur të jetë plotësisht gati, të ngarkohet shërbimi
- Shërbimi trajton kërkesat e drejtori dhe koordinon punën e tij të mëtjeshme.
Finesat e ndërtimit të drejtorëve
Nëse kolegët e mi do të flasin për shërbimin në një post tjetër, në këtë tekst do të zbulojmë finesat e zhvillimit të drejtori. Mini-filtri i drejtorisë së zhvilluar tashmë ka dy modet e funksionimit – kur sistemi ka nisur në mënyrë standarde, dhe kur sistemi sapo ka përjetuar një dështim dhe po rikuperohet. Para se të fillojë ngarkimi i bibliotekave dhe aplikacioneve të përdoruesve, dhe kështu edhe shërbimi ynë, drejtori portë saktësisht kur janë në ndonjë nga të dyja gjendjet. Si rezultat, çdo create, read dhe write registrohet, të gjitha metadatat fiksohen. Dhe kur shërbimi të jetë në linjë, drejtori ofron këtë informacion shërbimit.
Në rastin e nisjes normale, shërbimi i dërgon drejtori sinjalin “Relax”, që të “relaksohet” dhe të ndalojë regjistrimin me përpikëri të të dhënave. Në këtë rast, drejtori kalon në regjistrimin vetëm të ndryshimeve në disk dhe i raporton atyre shërbimit, i cili me ndihmën e mjeteve të tjera Acronis mban backup-in e diskut në gjendjen më të re më të mundshme në atë bartës që përdoruesi e ka caktuar. Kjo mund të jetë ruajtje e brezit, e largët, e gradualshme ose e natës.
Nëse aktivizohet moda e rikuperimit, shërbimi i njofton drejtorin se duhet të punojë në modin “Recovery”. Sistemi sapo është rikuperuar pas një dështimi, dhe sa herë që ai bën një kërkesë për të hapur një skedar në disk, mini-filtri duhet të kapë këtë operacion, të bëjë këtë kërkesë vetë, të kontrollojë nëse ekziston një skedar i tillë në disk dhe nëse është e mundur ta hapë atë.
Në rast se skedari mungon, mini-filtri e kalon këtë informacion te shërbimi, i cili rrit prioritetin e rikuperimit të skedarit (gjatë gjithë kësaj kohe rikuperimi vazhdon në sfond). Kështu që ky skedar thjesht përfundon në fillim të rendit. Pas kësaj, shërbimi vetë (ose me mjete të tjera Acronis) e rikuperon këtë skedar dhe i njofton drejtorit që gjithçka është në rregull, tani sistemi operativ mund të aksesojë atë dhe drejtori “liron” kërkesën origjinale nga sistemi në disk.
Nëse rikuperimi është i pamundur, shërbimi i njofton drejtorit se skedari nuk ekziston as në backup. Mini-filtri ynë i drejtorit thjesht e kalon kërkesën sistemore përpara dhe aplikacioni origjinal (vetë OS ose aplikacioni) merr gabimin “file not found”. Megjithatë, kjo është krejt normale nëse skedari nuk ka ekzistuar aspak në disk dhe në backup.
Sigurisht, sistemi operativ do të punojë shumë më ngadalë, sepse leximi i çdo skedari ose biblioteke ndodh në disa faza, ndoshta me qasje në burime të largëta. Por, me siguri, përdoruesi mund të fillojë punën në një afat të shkurtër, ndërsa rikuperimi vazhdon ende.
Duhet më poshtë, akoma më poshtë...
Prototipi e ka provuar funksionalitetin e tij. Por ne gjithashtu zbuluam nevojën për të ecur përpara, sepse në disa raste ende ndodhin bllokime. Për shembull, sistemi operativ mund të kërkojë biblioteka të ndryshme në disa thread-e, duke çuar në një bllokim të shërbimit tonë në vetvete.
Problemi që po trajtoj tani është rritja e shpejtësisë së Active Restore dhe përmirësimi i nivelit të sigurisë së sistemit. Supozoni se sistemi nuk ka nevojë për një skedar të tërë, i nevojitet vetëm një pjesë e tij. Për këtë është zhvilluar një drejtues i ri — filtrues drejtuesi i diskut. Ai punon jo në nivelin e skedarëve, por në nivelin bllok. Principi i funksionimit është i ngjashëm: në mënyrën normale të funksionimit, drejtuesi thjesht protokon blloqet e ndryshuara në disk, ndërsa në mënyrën e rikuperimit, përpiqet të lexojë bllokun vetë, dhe në rast dështimi, kërkon nga shërbimi rritjen e prioritetit. Në këtë mënyrë, të gjitha pjesët e tjera të sistemit mbeten të njëjta. Për shembull, shërbimi në nivelin e OS as që dyshon se i ofrohet të komunikojë me një drejtues tjetër, për shkak se detyra kryesore është të ofrojë për OS pikërisht ato të dhëna që janë të nevojshme për funksionimin. Ky drejtim kërkon përmirësime të konsiderueshme, të paktën sepse shërbimi nuk di akoma të mendojë në nivelin bllok.
Hapi tjetër vendosa ta nis drejtuesin më thellë dhe më herët, duke rënë në nivelin e drejtuesve UEFI dhe aplikacioneve Native Windows në vend të shërbimit. Për këtë është zhvilluar (ose drejtuesi DXE), i cili nis dhe vdes para fillimit të OS. Megjithatë, “historinë” e drejtuesve UEFI, detajet për ndërtimin dhe instalimin, si dhe specifikat e aplikacioneve Native Windows, do t'i shqyrtojmë në postimin e ardhshëm. Prandaj, regjistrohuni në blogun tonë, ndërsa unë do të përgatis një tregim për fazën tjetër të punës. Do të jem i lumtur për komentet dhe sugjerimet tuaja.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
A keni pasur ndonjëherë situata kur rikuperimi ka zgjatur vërtet shumë:
65.1%Po28
23.2%Jo10
11.6%Nuk kam menduar5
Votuan 43 përdorues. Të ndaluar 3 përdorues.
Burimi: habr.com
