Kopjimi i të dhënave të rëndësishme është i domosdoshëm. Por çfarë ndodh nëse puna duhet të vazhdojë menjëherë dhe çdo minutë ka rëndësi? Ne në Acronis vendosëm të shqyrtojmë se sa e mundur është të zgjidhet detyra e nisjes më të shpejtë të sistemit. Ky është postimi i parë në serinë Active Restore, ku do të flas për si e kemi filluar projektin në bashkëpunim me Universitetin Innopolis, çfarë zgjidhjeje gjetëm dhe mbi çfarë po punojmë sot. Detajet - më poshtë.
Përshëndetje! Emri im është Daulet Tumbaev, dhe sot dua të ndaja 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ë pak më larg. Tani punoj në Acronis, por gjithashtu jam një dëshmues i Universitetit Innopolis, që e përfundova nën programin e masterit “Menaxhimi i Zhvillimit të Softuerit” (i njohur si MSIT-SE). Innopolis është një universitet i ri, dhe programi mësimor është edhe më i ri. Por është ndërtuar mbi planet mësimore të Universitetit Carnegie Mellon, ku ka një fokus në projekte industriale.
Qëllimi i projektit industrial është të zhyt studentin në zhvillimin e vërtetë dhe të konsolidojë njohuritë e marra në praktikë. Për këtë universiteti bashkëpunon me kompani si Yandex, Acronis, MTC dhe dhjetëra të tjera (deri në vitin 2018, universiteti numëronte 144 partnerë). Gjatë bashkëpunimit, kompanitë ofrojnë universiteteve drejtimet e tyre të punës, ndërsa studentët zgjedhin një nga projektet që u përshtatet më shumë interesave dhe nivelit të përgatitjes. Vetëm dy vjet më parë isha “në anën tjetër të barricadave” dhe punoja si student në një projekt tjetër të Acronis. Por këtë herë kam qenë këshilltar teknik për studentët nga ana e kompanisë dhe i ofrova Universitetit Innopolis projektin Active Restore. Ideja për Active Restore u formulua nga ekipi Kernel në Acronis, megjithatë zhvillimi i zgjidhjes filloi së bashku me Universitetin Innopolis.
Active Restore – pse është e nevojshme?
Tradicionalisht, rikuperimi emergjent punon sipas një skeme standarde. Pas problemeve me kompjuterin, ju hyni në ndërfaqen e internetit të një sistemi rezervimi, për shembull, Acronis True Image, dhe klikoni butonin e madh “rikthe”. Më pas duhet të prisni N minuta, dhe vetëm pas kësaj mund të vazhdoni punën.
Problemi është se ky numër N, i njohur gjithashtu si RTO (objective e kohës së rikuperimit), koha e pranueshme e rikuperimit, mund të jetë mjaft i konsiderueshëm, i cili varet nga shpejtësia e lidhjes (nëse rikuperimi po ndodh nga re), nga kapaciteti i hard disku të pajisjes tuaj dhe faktorë të tjerë. A është e mundur ta pakësosh atë? Po, është e mundur, sepse për të rinisur punën nuk është gjithmonë e nevojshme një disk i plotë i kompjuterit. Po ashtu, fotografitë dhe videot nuk kanë ndonjë ndikim në funksionalitetin e pajisjes dhe mund të tërhiqen më vonë në mënyrë të ndjeshme.
Driver i nevojshëm…
Sistemi operativ llogarit se duhet të nisë me një disk plotësisht të gatshëm. Prandaj Windows bën një sërë kontrollesh të integritetit të diskut. Sistemi nuk do të lejojë që të bëhet një nisje e zakonshme nëse disa skedarë, të cilat OS pritet t'i gjejë, mungojnë ose janë dëmtuar. Për zgjidhjen e këtij problemi, u vendos të vendosnim në disk skedarët tanë të njohur si skedarë redirektues, të cilët zëvendësojnë skedarët që mungojnë ose janë dëmtuar, por në fakt janë të zbrazët. Të krijosh këto redirektues nuk merr shumë kohë, sepse ato në fakt nuk kanë asnjë përmbajtje.
Më pas rikuperimi ndodh në këtë mënyrë. Në mënyrë paralele me punën e sistemit operativ, “zbrazët” ndFillojnë të mbushen me të dhëna. Procesi i rikuperimit në sfond merr parasysh ngarkesën në disk dhe nuk e kalon kufirin e vendosur. Megjithatë, përdoruesi ose vetë sistemi operativ mund të kërkojë papritur një skedë, e cila ende nuk ekziston. Këtu hyn në veprim regjimi i dytë i rikuperimit. Prioriteti i skedarit të kërkuar rritet deri në maksimum, dhe procesi i rikuperimit ngarkon me urgjencë skedarin në disk. Sistemi operativ merr skedarin e nevojshëm, edhe pse me një vonesë të vogël.
Kështu duket skena ideale. Megjithatë, në botën reale, ekziston një numër i madh pengesash dhe ndalimesh potenciale. Së bashku me masterantët e Innopolis, vendosëm të studiojmë këtë skenar rikuperimi, të vlerësojmë përfitimin në RTO dhe të kuptojmë nëse një qasje e tillë është realizueshme? Sepse zgjidhje të ngjashme në treg thjesht nuk ishin në atë kohë.
Dhe nëse unë vendosa t'i lë komponentin e shërbimit në duar të studentëve të Innopolis, atëherë brenda Acronis filloi puna mbi . Këtë e ka marrë përsipër ekipi i Windows Kernel. Plani ishte i tillë:
- Të nisë drejtori në fazën e hershme të ngarkesës së OS-së,
- Gjatë punës, kur të jetë plotësisht e gatshme, të ngarkohet shërbimi.
- Shërbimi përpunon kërkesat e drejtori dhe koordinon funksionimin e tij të mëtejshëm.
Hollësitë e ndërtimit të drejtori
Nëse kolegët e mi do të flasin për shërbimin në një postim tjetër, në këtë tekst ne do të zbulojmë hollësitë e zhvillimit të drejtori. Një drejtori mini-filtri të zhvilluar tashmë ka dy mënyra funksionimi – kur sistemi fillon në mënyrë standarde, dhe kur sistemi sapo ka përjetuar një dështim dhe është në procesin e rikuperimit. Para se të fillojë ngarkimi i bibliotekave dhe aplikacioneve të përdoruesit, dhe kështu shërbimit tonë, drejtori vepron njëlloj. Ai nuk di në cilin prej gjendjeve ndodhet tani sistemi. Si rezultat, çdo krijim, lexim dhe shkruar dokumentohet, duke e regjistruar të gjitha meta-të dhënat. Kur shërbimi të jetë online, drejtori i ofron këtë informacion shërbimit.
Në rastin e nisjes normale, shërbimi i dërgon drejtori një sinjal "Relax", në mënyrë që ai të "qetësohet" dhe të ndalojë regjistrimin e të gjitha të dhënave me pedantizëm. Në këtë rast, drejtori kalon në regjistrimin vetëm të ndryshimeve në disk dhe u raporton atyre shërbimit, i cili me ndihmën e mjeteve të tjera Acronis, mbështet backup-in e diskut në gjendjen më të përditësuar në atë mbajtës që përdoruesi ka caktuar. Kjo mund të jetë backup i re, distancë, progresiv ose gjatë natës.
Nëse aktivizohet moda e rikuperimit, shërbimi i thotë drejtori se duhet të funksionojë në modën "Recovery". Sistemi sapo është rikuperuar nga dështimi, dhe sa herë që bën kërkesë për të hapur një skedare në disk, mini-filtri duhet ta kapë këtë operacion, të bëjë vetë këtë kërkesë, të kontrollojë nëse ka një skedare të tillë në disk dhe nëse mund të hapet.
Nëse skedari nuk ekziston, mini-filtri i transmeton këtë informacion shërbimit, që e rrit prioritetin e rikuperimit të skedarit (gjatë gjithë kësaj kohe është duke u kryer rikuperimi në sfond). Kështu, ky skedari thjesht kalon në fillim të radhës. Më pas, shërbimi vetë (ose me mjete të tjera Acronis) e rikuperon këtë skedari dhe i raporton drejtori që gjithçka është në rregull, tani sistemi operativ mund të bëjë kërkesë për të dhe drejtori "liron" kërkesën origjinale, nga sistemi në disk.
Në rast se rikuperimi nuk është i mundur, shërbimi i raporton drejtori se skedari as në backup nuk ekziston. Drejtori ynë mini-filtri thjesht lejon kërkesën sistemore të kalojë më tej dhe kërkuesi origjinal (sistemi operativ apo aplikacioni vetë) merr një gabim "file not found". Megjithatë, kjo është krejt normale, nëse skedari nuk ka qenë vërtet në disk dhe në backup.
Sigurisht, sistemi operativ do të funksionojë shumë më ngadalë, sepse leximi i çdo skedari apo biblioteke ndodh në disa faza, ndoshta me qasje në burime të largëta. Por përdoruesi mund të fillojë punën në një periudhë të shkurtër, derisa rikuperimi akoma po ndodhi.
Duhet më poshtë, akoma më poshtë...
Prototipi ka treguar funksionimin 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 rrjedha, duke krijuar kështu një bllokim të shërbimit tonë mbi vetveten.
Problemi mbi të cilin po punoj tani është rritja e shpejtësisë së Active Restore dhe niveli i sigurisë së sistemit. Supozoni se sistemi ka nevojë për jo një skedar të plotë, vetëm një pjesë të tij. Për këtë u zhvillua një tjetër drejtori — drejtori i filtrit të diskut. Ai punon jo në nivelin e skedarit, por në nivelin e bllokut. Parimi i funksionimit është i ngjashëm: në modën normale të funksionimit, drejtori thjesht dokumenton blloqet e ndryshuar në disk, ndërsa në modën e rikuperimit, përpiqet të lexojë bllokun vetë, dhe në rast dështimi kërkon që shërbimi të rrisë prioritetin. Në këtë rast, të gjitha pjesët e tjera të sistemit mbeten të njëjta. Për shembull, shërbimi në nivelin e OS-së as që e dyshon se po i ofrohet të komunikojë me një drejtori tjetër, sepse detyra kryesore është të ofrojë OS-së të dhënat e nevojshme për funksionimin. Ky drejtim kërkon përmirësime të konsiderueshme, të paktën, sepse shërbimi ende nuk di të mendojë në nivelin e bllokut.
Hapi tjetër, vendosa të nisja drejtori më thellë dhe më herët, duke zbritur në nivelin e drejtuesve UEFI dhe aplikacioneve Native Windows në vend të shërbimit. Për këtë u zhvillua (ose DXE driver), i cili fillon dhe vdes përpara se OS të nisë. Por “historinë” e driverëve UEFI, detajet mbi ndërtimin dhe instalimin, si dhe specifikat e aplikacioneve Native Windows, do t'i shqyrtojmë në postimin e ardhshëm. Pra, regjistrohuni në blogun tonë, derisa unë përgatit një tregim mbi fazën tjetër të punës. Do të jem i lumtur për komentet dhe këshillat tuaja.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutemi.
A keni pasur ndonjëherë situata kur rikuperimi ka zgjatur tmerrësisht gjatë:
65.1%Po28
23.2%Jo
11.6%Nuk kam menduar5
Këto janë votat e 43 përdoruesve. 3 përdorues abstenuan.
Burimi: habr.com
