Backup-ul datelor importante este esențial. Dar ce se întâmplă dacă activitatea trebuie să continue imediat, iar fiecare minut contează? La Acronis, am decis să testăm cât de rapid putem relansa sistemul. Acesta este primul articol din seria Active Restore, în care voi povesti cum am început proiectul împreună cu Universitatea Innopolis, ce soluție am găsit și la ce lucrăm astăzi. Detalii mai jos.
Salut! Numele meu este Daulet Tumbaev și astăzi vreau să împărtășesc cu voi experiența mea în dezvoltarea unui sistem menit să accelereze recuperarea de urgență. Pentru a povesti întreaga evoluție a proiectului, să începem de la început. În prezent, lucrez la Acronis, dar sunt și absolvent al Universității Innopolis, unde am terminat programul de master în „Managementul dezvoltării software”, cunoscut ca MSIT-SE. Innopolis este o universitate tânără, iar programul său de studiu este chiar și mai nou. Totuși, acesta se bazează pe planurile de învățământ ale Universității Carnegie Mellon, care include subiecte referitoare la proiecte industriale.
Scopul proiectului industrial este de a implica studentul în dezvoltarea reală și de a consolida cunoștințele dobândite în practică. În acest sens, universitatea colaborează cu companii precum Yandex, Acronis, MTC și zeci de altele (până în 2018, universitatea avea 144 de parteneri). Pe parcursul colaborării, companiile oferă universității domenii de lucru, iar studenții aleg unul dintre proiectele care le stârnesc interesul și se potrivesc nivelului lor de pregătire. Cu doar doi ani în urmă, eu eram „de partea cealaltă a baricadei” și lucram ca student la un alt proiect Acronis. Însă de data aceasta am fost consultant tehnic pentru studenți din partea companiei și am propus Universității Innopolis proiectul Active Restore. Ideea Active Restore a fost formulată de echipa Kernel din cadrul Acronis, însă dezvoltarea soluției a început împreună cu Universitatea Innopolis.
Active Restore – de ce este necesar?
În mod tradițional, recuperarea de urgență funcționează conform unui șablon standard. După ce întâmpinați probleme cu computerul, accesați interfața web a unui sistem de backup, de exemplu, Acronis True Image, și apăsați butonul mare „restaurați”. Apoi, trebuie să așteptați N minute, iar abia după aceea veți putea continua activitatea.
Problema constă în faptul că acest număr N, cunoscut și ca RTO (obiectivul de timp de recuperare), timpul permis pentru restaurare, poate fi destul de considerabil, depinzând de viteza conexiunii (dacă se face recuperarea din cloud), de volumul hard disk-ului mașinii tale și de o serie de alți factori. Poate fi redus? Da, poate fi, deoarece pentru a relua activitatea nu este întotdeauna necesar un disk complet al computerului. De exemplu, fotografiile și videoclipurile nu afectează funcționalitatea dispozitivului și pot fi aduse ulterior în fundal.
Driver necesar…
Sistemul de operare este proiectat să se lanseze cu un disk complet pregătit. Prin urmare, Windows efectuează o serie de verificări ale integrității diskului. Sistemul nu va permite un pornire normală în absența sau deteriorarea anumitor fișiere pe care sistemul de operare se așteaptă să le găsească. Pentru a rezolva această problemă, s-a decis să plasăm pe disk fișiere de redirecționare, care înlocuiesc fișierele lipsă sau deteriorate, dar care de fapt sunt goluri. Crearea acestor redirecționări nu durează mult, deoarece ele de fapt nu conțin nimic.
Ulterior, recuperarea se desfășoară astfel. Printr-un proces în fundal, în paralel cu activitatea sistemului de operare, „golurile” sunt umplute cu date. Procesul de recuperare în fundal ia în considerare sarcina pe disk și nu depășește limita stabilită. Cu toate acestea, utilizatorul sau sistemul de operare însuși pot solicita brusc un fișier care nu este încă disponibil. Aici intervine al doilea mod de recuperare. Prioritatea fișierului solicitat crește la maxim, iar procesul de recuperare în regim de urgență încarcă fișierul pe disk. Sistemul de operare primește fișierul dorit, chiar dacă cu o mică întârziere.
Așa arată imaginea ideală. Cu toate acestea, în lumea reală, există o mulțime de capcane și blocaje potențiale. Împreună cu studenții de la Innopolis, am decis să cercetăm acest scenariu de recuperare, să evaluăm câștigul în RTO și să înțelegem dacă un astfel de abordare este realizabilă. De fapt, nu existau soluții similare pe piață în acel moment.
Și deși am decis să las partea de servicii pe mâna colegilor de la Innopolis, în interiorul Acronis a început lucrul la . Echipa Windows Kernel s-a ocupat de aceasta. Planul a fost următorul:
- Să lansăm driverul într-o etapă timpurie a pornirii sistemului de operare,
- În timpul funcționării, când va fi complet pregătit, să încărcăm serviciul
- Serviciul procesează cererile driverului și coordonează activitatea acestuia.
Aspectele tehnice ale dezvoltării driverelor
Dacă colegii mei vor discuta despre serviciu într-o altă postare, în acest text vom explora detaliile dezvoltării driverului. Un driver mini-filtru deja dezvoltat are două moduri de funcționare – când sistemul a fost pornit în mod normal și când sistemul a trecut recent printr-o defecțiune și se află în proces de restaurare. Până când se va clasa bibliotecile și aplicațiile utilizatorului, și, prin urmare, și serviciul nostru, driverul se comportă la fel. Nu știe în care dintre aceste stări se află acum sistemul. Ca urmare, fiecare creare, citire și scriere este protocoalizată, sunt înregistrate toate metadatele. Iar când serviciul va fi online, driverul oferă aceste informații serviciului.
În cazul unei porniri normale, serviciul transmite driverului un semnal „Relax”, astfel încât acesta să „relaxeze” și să nu mai protocoalizeze meticulos toate datele. În acest caz, driverul trece la protocoalizarea doar a modificărilor de pe disc și informează despre acestea serviciul, care, cu ajutorul altor instrumente Acronis, menține backup-ul discului în starea cea mai actualizată pe suportul pe care l-a definit utilizatorul. Acesta poate fi un backup în cloud, la distanță, gradual sau de noapte.
Dacă se activează modul de restaurare, serviciul informează driverul că trebuie să lucreze în modul „Recovery”. Sistemul s-a restaurat recent după o defecțiune, iar de îndată ce face o cerere de deschidere a unui fișier de pe disc, mini-filtrul trebuie să intercepteze această operație, să efectueze cererea, să verifice dacă există un astfel de fișier pe disc și dacă poate fi deschis.
În cazul în care fișierul este absent, mini-filtrul transmite această informație serviciului, care crește prioritatea de recuperare a fișierului (în tot acest timp, recuperarea se desfășoară în fundal). Astfel, acest fișier pur și simplu sare la începutul cozii. După aceasta, serviciul însuși (sau prin alte mijloace Acronis) recuperează acest fișier și raportează driver-ului că totul este în regulă, acum sistemul de operare poate accesa fișierul, iar driver-ul „eliberează” cererea originală de la sistem către disc.
Dacă recuperarea nu este posibilă, serviciul informează driver-ul că fișierul nu există nici în backup. Mini-filtrul nostru pur și simplu permite cererea sistemului să continue, iar cererea originală (sistemul de operare sau aplicația) primește eroarea „fișierul nu a fost găsit”. Totuși, acest lucru este perfect normal, dacă fișierul nu a existat pe disc și în backup.
Desigur, sistemul de operare va funcționa mult mai lent, deoarece citirea oricărui fișier sau bibliotecă se desfășoară în mai multe etape, posibil cu acces la resurse externe. Dar utilizatorul poate începe să lucreze într-un timp foarte scurt, în timp ce recuperarea continuă.
Trebuie mai jos, încă mai jos...
Prototipul și-a demonstrat funcționalitatea. Dar am descoperit și nevoia de a merge mai departe, deoarece în unele cazuri se produce în continuare blocaje. De exemplu, sistemul de operare poate solicita diverse biblioteci în mai multe fire de execuție, ceea ce duce la blocarea serviciului nostru pe sine.
Problema asupra căreia lucrez în prezent este creșterea vitezei Active Restore și îmbunătățirea nivelului de securitate al sistemului. Să presupunem că sistemului nu îi este necesar un fișier întreg, ci doar o parte din el. În acest scop, a fost dezvoltat un alt driver - un driver de filtrare a discului. Acesta nu lucrează pe nivel de fișiere, ci pe nivel bloc. Principiul de funcționare este similar: în mod normal, driverul pur și simplu înregistrează blocurile modificate de pe disc, iar în modul de recuperare, încearcă să citească blocul de unul singur, iar în caz de eșec, solicită creșterea priorității de la serviciu. În același timp, toate celelalte părți ale sistemului rămân neschimbate. De exemplu, serviciul la nivel de sistem de operare nici măcar nu bănuiește că i se propune să comunice cu un alt driver, deoarece sarcina principală este de a oferi sistemului de operare exact datele necesare pentru funcționare. Această direcție necesită modificări semnificative, cel puțin pentru că serviciul nu poate încă să gândească la nivel bloc.
Următorul pas pe care am decis să-l fac este să lansez driverul mai devreme și mai profund, coborând la nivelul driverelor UEFI și al aplicațiilor Native Windows în loc de serviciu. Pentru aceasta a fost dezvoltat (sau driverul DXE), care pornește și se oprește înainte de startul sistemului de operare. Dar „istoricul” driverelor UEFI, detalii despre construcție și instalare, precum și specificitatea aplicațiilor Windows Native le vom discuta în următorul post. Așa că abonați-vă la blogul nostru, iar eu voi pregăti o poveste despre următoarea etapă a lucrărilor. Aș fi bucuros să primesc comentariile și sfaturile voastre.
Numai utilizatorii înregistrați pot participa la sondaj. , vă rugăm.
Ați avut vreodată situații în care recuperarea a durat exasperant de mult:
65.1%Da28
23.2%Nu10
11.6%Nu m-am gândit5
43 de utilizatori au votat. 3 utilizatori s-au abținut.
Sursa: habr.com
