Rezervimi i të dhënave të rëndësishme është një gjë e mirë. Por, çka nëse puna duhet të vazhdojë menjëherë dhe çdo minutë ka rëndësi? Ne në Acronis vendosëm të kontrollojmë se sa e mundur është të zgjidhet problemi i fillimit të sistemit sa më shpejt të jetë e mundur. Dhe ky është postimi i parë në serinë Active Restore, në të cilin do t'ju tregoj se si e filluam projektin së bashku me Universitetin Innopolis, çfarë zgjidhje gjetëm dhe për çfarë po punojmë sot. Detajet janë nën prerje.
Përshëndetje! Emri im është Daulet Tumbayev dhe sot do të doja të ndaja me ju përvojën time në zhvillimin e një sistemi që përshpejton rikuperimin nga fatkeqësitë. Për të folur për të gjithë rrugën e zhvillimit të projektit, le të fillojmë pak nga larg. Aktualisht punoj në Acronis, por jam diplomuar edhe në Universitetin Innopolis, ku kam kryer programin Master në Menaxhimin e Zhvillimit të Softuerit (i njohur si MSIT-SE). Innopolis është një universitet i ri, dhe kurrikula është edhe më e re. Por është ndërtuar mbi kurrikulën e Universitetit Carnegie Mellon, puna e të cilit përfshin një temë të tillë si projektet industriale.
Qëllimi i projektit industrial është të zhytë studentin në zhvillimin real dhe të konsolidojë njohuritë e fituara në praktikë. Për ta bërë këtë, universiteti bashkëpunon me kompani të tilla si Yandex, Acronis, MTC dhe dhjetëra të tjera (në total, që nga viti 2018, universiteti kishte 144 partnerë). Në kuadër të bashkëpunimit, kompanitë i ofrojnë universitetit fushat e tyre të punës dhe studentët zgjedhin një nga projektet që është më afër interesave dhe nivelit të tyre të formimit. Fjalë për fjalë dy vjet më parë isha ende "në anën tjetër të barrikadave" dhe punoja si student në një projekt tjetër Acronis. Por këtë herë u bëra një konsulent teknik për studentët në anën e kompanisë dhe propozova projektin Active Restore në Innopolis. Vetë ideja e Active Restore u formulua nga ekipi i Kernel në Acronis, por zhvillimi i zgjidhjes filloi së bashku me Universitetin Innopolis.
Rivendosja aktive - pse është e nevojshme?
Tradicionalisht, rikuperimi nga fatkeqësitë funksionon sipas një skeme standarde. Pas problemeve me kompjuterin tuaj, ju shkoni në ndërfaqen e internetit të një sistemi rezervë, për shembull, Acronis True Image, dhe klikoni në butonin e madh "rivendosje". Më pas duhet të prisni N minuta dhe vetëm pas kësaj mund të vazhdoni të punoni.
Problemi është se ky numër N, i njohur edhe si RTO (objektivi i kohës së rikuperimit), koha e lejuar e rikuperimit, mund të jetë mjaft mbresëlënëse, e cila varet nga shpejtësia e lidhjes (nëse rikuperimi është nga cloud), madhësia e hard drive-it të makinës suaj. , dhe një sërë faktorësh të tjerë. A është e mundur të zvogëlohet? Po, mundeni, sepse për të rifilluar punën nuk ju nevojitet gjithmonë një disk i plotë kompjuterik. Të njëjtat foto dhe video nuk ndikojnë në asnjë mënyrë funksionalitetin e pajisjes dhe mund të tërhiqen më vonë në sfond.
Kërkohet shofer...
Sistemi operativ pret të fillojë me një disk të përgatitur plotësisht. Prandaj Windows Kryen një sërë kontrollesh të integritetit të diskut. Sistemi nuk do të lejojë nisjen normale nëse disa skedarë që sistemi operativ pret të gjejë mungojnë ose janë të dëmtuar. Për të zgjidhur këtë problem, vendosëm të vendosim të ashtuquajturit skedarë ridrejtues në disk. Këta skedarë zëvendësojnë skedarët që mungojnë ose janë të dëmtuar, por në thelb janë skedarë artificialë. Krijimi i këtyre ridrejtuesve është shumë i lehtë, pasi ata në të vërtetë nuk përmbajnë asnjë përmbajtje.
Restaurimi i mëtejshëm ndodh si më poshtë. Me një proces sfondi, paralelisht me funksionimin e sistemit operativ, "dummies" mbushen me të dhëna. Procesi i rikuperimit të sfondit merr parasysh ngarkesën e diskut dhe nuk e kalon kufirin e caktuar. Megjithatë, përdoruesi ose vetë sistemi operativ mund të kërkojnë papritur një skedar që nuk ekziston ende. Këtu hyn në lojë mënyra e dytë e rikuperimit. Prioriteti i skedarit të kërkuar rritet në maksimum dhe procesi i rikuperimit ngarkon urgjentisht skedarin në disk. Sistemi operativ merr skedarin e kërkuar, megjithëse me një vonesë të vogël.
Kështu duket një foto ideale. Sidoqoftë, në botën reale, ka një numër të madh grackash dhe bllokimesh të mundshme. Së bashku me studentët e masterit të Innopolis, vendosëm të eksplorojmë këtë skenar rikuperimi, të vlerësojmë përfitimet në RTO dhe të kuptojmë nëse një qasje e tillë është e realizueshme? Në fund të fundit, thjesht nuk kishte zgjidhje të tilla në treg në atë kohë.
Dhe nëse vendosa t'u jap komponentin e shërbimit djemve nga Innopolis, atëherë brenda Acronis filloi puna Ekipi u kujdes për këtë. Windows Bërthama. Plani ishte ky:
- Nisni drejtuesin në një fazë të hershme të fillimit të OS,
- Gjatë punës, kur do të jetë plotësisht gati, shkarkoni shërbimin
- Shërbimi përpunon kërkesat e shoferit dhe koordinon punën e tij të mëtejshme.
Hollësitë e inxhinierisë së shoferit
Nëse kolegët e mi do të flasin për shërbimin në një postim tjetër, atëherë në këtë tekst do të zbulojmë ndërlikimet e zhvillimit të shoferit. Drejtuesi i mini-filtrit i zhvilluar tashmë ka dy mënyra funksionimi - kur sistemi filloi në modalitetin normal dhe kur sistemi sapo ka pësuar një dështim dhe po rikthehet. Para se të ngarkoni bibliotekat dhe aplikacionet e përdoruesve, dhe për këtë arsye shërbimin tonë, shoferi sillet njësoj. Ai nuk e di se në cilën gjendje është aktualisht sistemi. Si rezultat, çdo krijimi, lexim dhe shkrim regjistrohet dhe të gjitha meta të dhënat regjistrohen. Dhe kur shërbimi është në linjë, shoferi ia jep këtë informacion shërbimit.
Në rastin e një fillimi normal, shërbimi i dërgon shoferit një sinjal "Relax" në mënyrë që ai "të relaksohet" dhe të ndalojë regjistrimin e përpiktë të të gjitha të dhënave. Në këtë rast, drejtuesi kalon në regjistrimin vetëm të ndryshimeve në disk dhe i raporton ato në shërbim, i cili, duke përdorur mjete të tjera Acronis, ruan rezervimin e diskut në gjendjen më të përditësuar në median e specifikuar nga përdoruesi. Kjo mund të jetë rezervë në re, në distancë, graduale ose gjatë natës.
Nëse modaliteti i rikuperimit është i aktivizuar, shërbimi i tregon drejtuesit se duhet të funksionojë në modalitetin "Rimëkëmbje". Sistemi sapo është rikuperuar nga një përplasje, dhe sapo të bëjë një kërkesë për të hapur një skedar në disk, mini-filtri duhet të përgjojë këtë operacion, ta bëjë vetë këtë kërkesë, të kontrollojë nëse një skedar i tillë ekziston në disk dhe nëse mund të hapet.
Nëse një skedar mungon, mini-filtri ia transmeton këtë informacion shërbimit, gjë që rrit përparësinë e rikuperimit të skedarit (gjatë gjithë kësaj kohe, rikuperimi po vazhdon në sfond). Rezulton se ky skedar thjesht hidhet në fillim të radhës. Pas kësaj, vetë shërbimi (ose mjete të tjera Acronis) e rikthen këtë skedar dhe i thotë drejtuesit se gjithçka është në rregull, tani sistemi operativ mund të hyjë në të dhe shoferi "lëshon" kërkesën origjinale, nga sistemi në disk.
Nëse rikuperimi është i pamundur, shërbimi informon drejtuesin se skedari nuk është në kopje rezervë. Drejtuesi ynë i mini-filtrit thjesht kalon kërkesën e sistemit më tej dhe kërkuesi origjinal (vetë OS ose aplikacioni) merr një gabim "skedari nuk u gjet". Sidoqoftë, kjo është mjaft normale nëse skedari me të vërtetë nuk ishte në disk dhe në kopje rezervë.
Sigurisht, sistemi operativ do të funksionojë shumë më ngadalë, sepse leximi i çdo skedari ose biblioteke ndodh në disa faza, ndoshta me qasje në burime të largëta. Por përdoruesi mund të kthehet në punë sa më shpejt që të jetë e mundur ndërsa rikuperimi është ende duke u zhvilluar.
Duhet më e ulët, edhe më e ulët...
Prototipi ka vërtetuar funksionalitetin e tij. Por ne gjithashtu gjetëm nevojën për të ecur përpara sepse në disa raste ka ende ngërçe. Për shembull, sistemi operativ mund të kërkojë biblioteka të ndryshme në disa tema, gjë që çon në rikthimin e shërbimit tonë në vetvete.
Problemi me të cilin jam duke punuar aktualisht është rritja e shpejtësisë së "Rivendosjes aktive" dhe rritja e nivelit të sigurisë së sistemit. Le të themi se sistemi nuk ka nevojë për të gjithë skedarin, por vetëm një pjesë të tij. Për këtë qëllim, u zhvillua një drejtues tjetër - drejtuesi i filtrit të diskut. Nuk funksionon më në nivelin e skedarit, por në nivelin e bllokut. Parimi i funksionimit është i ngjashëm: në modalitetin normal të funksionimit, drejtuesi thjesht regjistron blloqet e ndryshuara në disk, dhe në modalitetin e rikuperimit, ai përpiqet ta lexojë vetë bllokun, dhe nëse nuk ka sukses, kërkon që shërbimi të rrisë përparësinë. Megjithatë, të gjitha pjesët e tjera të sistemit mbeten të njëjta. Për shembull, një shërbim i nivelit OS as nuk dyshon se i kërkohet të komunikojë me një drejtues tjetër, sepse detyra kryesore është t'i sigurojë OS saktësisht të dhënat që janë të nevojshme për funksionimin. Kjo fushë kërkon përmirësime të rëndësishme, qoftë dhe vetëm sepse shërbimi nuk di ende të mendojë në nivel blloku.
Hapi tjetër që ndërmora ishte ta ekzekutoja drajverin më thellë dhe më herët, duke zbritur te drajveri UEFI dhe niveli Native. Windows aplikacione në vend të një shërbimi. Për këtë qëllim, u zhvillua (ose drajveri DXE), i cili fillon dhe fiket edhe para se të fillojë sistemi operativ. Por "historia" e drajverëve UEFI, detajet rreth montimit dhe instalimit, si dhe specifikat Windows Do të trajtojmë aplikacionet native në postimin tjetër. Prandaj, regjistrohuni në blogun tonë ndërsa unë përgatis një artikull rreth fazës tjetër të punës sonë. Do të doja shumë të dëgjoja komentet dhe sugjerimet tuaja.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , te lutem
A keni pasur ndonjëherë situata ku shërimi ka marrë një kohë jashtëzakonisht të gjatë:
65.1%Po 28
23.2%Nr 10
11.6%Nuk e mendova5
43 përdorues votuan. 3 përdorues abstenuan.
Burimi: www.habr.com
