Restaurare activă: se poate întâmpla recuperarea în caz de dezastru mai rapid? Mult mai repede?

Este un lucru bun să faceți copii de rezervă ale datelor importante. Dar dacă munca trebuie să continue imediat și fiecare minut contează? Noi, cei de la Acronis, am decis să verificăm cât de posibil este să rezolvăm cât mai repede problema pornirii sistemului. Și acesta este primul post din seria Active Restore, în care vă voi spune cum am început proiectul împreună cu Universitatea Innopolis, ce soluție am găsit și la ce lucrăm astăzi. Detaliile sunt sub tăietură.

Buna ziua! Numele meu este Daulet Tumbayev și astăzi aș dori să vă împărtășesc experiența mea în dezvoltarea unui sistem care accelerează recuperarea în caz de dezastru. Pentru a vorbi despre întreaga cale de dezvoltare a proiectului, să începem puțin de departe. În prezent lucrez la Acronis, dar sunt și absolvent al Universității Innopolis, unde am absolvit programul de Master în Managementul dezvoltării software (cunoscut sub numele de MSIT-SE). Innopolis este o universitate tânără, iar programa este și mai tânără. Dar este construit pe curriculum-ul Universității Carnegie Mellon, a cărei activitate include un subiect precum proiectele industriale.

Scopul proiectului industrial este de a cufunda studentul în dezvoltarea reală și de a consolida în practică cunoștințele dobândite. Pentru a face acest lucru, universitatea cooperează cu companii precum Yandex, Acronis, MTC și alte zeci (în total, începând cu 2018, universitatea avea 144 de parteneri). Pe parcursul cooperării, companiile oferă universității domeniile lor de lucru, iar studenții aleg unul dintre proiectele care se apropie mai mult de interesele și nivelul de pregătire al acestora. Literal acum doi ani, eram încă „de cealaltă parte a baricadelor” și lucram ca student la un alt proiect Acronis. Dar de data aceasta am devenit consultant tehnic pentru studenții din partea companiei și am propus proiectul Active Restore la Innopolis. Însăși ideea de Active Restore a fost formulată de echipa Kernel de la Acronis, dar dezvoltarea soluției a început împreună cu Universitatea Innopolis.

Active Restore – de ce este nevoie?

În mod tradițional, recuperarea în caz de dezastru funcționează conform unei scheme standard. După probleme cu computerul, accesați interfața web a unui sistem de rezervă, de exemplu, Acronis True Image, și faceți clic pe butonul mare „restaurare”. În continuare, trebuie să așteptați N minute și numai după aceea puteți continua să lucrați.

Problema este că acest număr N, cunoscut și sub numele de RTO (obiectiv de timp de recuperare), timpul de recuperare admisibil, poate fi destul de impresionant, ceea ce depinde de viteza conexiunii (dacă recuperarea este din cloud), de dimensiunea hard disk-ului mașinii tale. , și o serie de alți factori. Este posibil să-l reduc? Da, puteți, pentru că pentru a relua munca nu aveți întotdeauna nevoie de un disc de computer complet. Aceleași fotografii și videoclipuri nu afectează în niciun fel funcționalitatea dispozitivului și pot fi ridicate ulterior în fundal.

Este nevoie de șofer...

Sistemul de operare se așteaptă să înceapă cu discul complet pregătit. Prin urmare, Windows efectuează o serie de verificări pentru a verifica integritatea discului. Sistemul nu va permite o pornire normală dacă unele fișiere pe care sistemul de operare se așteaptă să fie găsite lipsesc sau sunt deteriorate. Pentru a rezolva această problemă, s-a decis să plasăm pe disc așa-numitele fișiere redirector pe care le-am creat, care înlocuiesc fișierele lipsă sau deteriorate, dar de fapt sunt manechine. Nu durează mult pentru a crea astfel de redirectoare, pentru că de fapt nu au niciun conținut.

Restaurarea ulterioară are loc după cum urmează. Printr-un proces de fundal, în paralel cu funcționarea sistemului de operare, „manichinele” sunt umplute cu date. Procesul de recuperare în fundal ia în considerare încărcarea discului și nu depășește limita setată. Cu toate acestea, utilizatorul sau sistemul de operare însuși pot necesita brusc un fișier care nu există încă. Aici intră în joc al doilea mod de recuperare. Prioritatea fișierului solicitat este ridicată la maxim, iar procesul de recuperare încarcă urgent fișierul pe disc. Sistemul de operare primește fișierul necesar, deși cu o ușoară întârziere.

Așa arată o imagine ideală. Cu toate acestea, în lumea reală, există un număr mare de capcane și potențiale blocaje. Împreună cu studenții de la masterat Innopolis, am decis să explorăm acest scenariu de recuperare, să evaluăm câștigurile în RTO și să înțelegem dacă o astfel de abordare este fezabilă? La urma urmei, pur și simplu nu existau astfel de soluții pe piață la acel moment.

Și dacă m-am hotărât să ofer componenta de serviciu băieților de la Innopolis, atunci în cadrul Acronis a început munca la mini-filtru după driverul sistemului de fișiere. Acest lucru a fost făcut de echipa Windows Kernel. Planul era cam asa:

• Lansați driverul într-un stadiu incipient al pornirii sistemului de operare,
• În timpul muncii, când spațiu utilizator va fi complet gata, descărcați serviciul
• Serviciul procesează cererile șoferilor și își coordonează activitatea ulterioară.

Subtilități ale ingineriei șoferului

Dacă colegii mei vor vorbi despre serviciu într-o altă postare, atunci în acest text vom dezvălui complexitățile dezvoltării șoferilor. Driverul de mini-filtru deja dezvoltat are două moduri de operare - când sistemul a pornit în modul normal și când sistemul tocmai a suferit o defecțiune și este în curs de restabilire. Înainte de a încărca bibliotecile și aplicațiile utilizatorilor și, prin urmare, serviciul nostru, driverul se comportă la fel. Nu știe în ce stare se află sistemul în prezent. Ca rezultat, fiecare creare, citire și scriere este înregistrată și toate metadatele sunt înregistrate. Și când serviciul este online, șoferul furnizează aceste informații serviciului.

În cazul unei porniri normale, serviciul trimite șoferului un semnal de „relaxare”, astfel încât acesta să se „relaxeze” și să oprească înregistrarea scrupuloasă a tuturor datelor. În acest caz, driverul trece la înregistrarea numai a modificărilor de pe disc și le raportează serviciului, care, folosind alte instrumente Acronis, menține backup-ul discului în cea mai actualizată stare pe mediul specificat de utilizator. Acesta poate fi backup în cloud, la distanță, gradual sau nocturn.

Dacă modul de recuperare este activat, serviciul îi spune șoferului că trebuie să funcționeze în modul „Recuperare”. Sistemul tocmai s-a recuperat dintr-o blocare și, de îndată ce solicită deschiderea unui fișier de pe disc, mini-filtrul trebuie să intercepteze această operațiune, să facă el însuși această solicitare, să verifice dacă un astfel de fișier există pe disc și dacă se poate deschide.

Dacă lipsește un fișier, mini-filtrul transmite aceste informații către serviciu, ceea ce crește prioritatea recuperării fișierelor (în tot acest timp, recuperarea are loc în fundal). Se pare că acest fișier sare pur și simplu la începutul cozii. După aceasta, serviciul în sine (sau alte mijloace Acronis) restaurează acest fișier și îi spune șoferului că totul este în regulă, acum sistemul de operare îl poate accesa și driverul „eliberează” cererea originală, de pe sistem pe disc.

Dacă recuperarea este imposibilă, serviciul informează șoferul că fișierul nu se află în backup. Driverul nostru de mini-filtru trece pur și simplu cererea de sistem în continuare, iar solicitantul inițial (OS însuși sau aplicația) primește o eroare „fișier negăsit”. Cu toate acestea, acest lucru este destul de normal dacă fișierul nu a fost într-adevăr pe disc și în backup.

Desigur, sistemul de operare va funcționa mult mai lent, deoarece citirea oricărui fișier sau bibliotecă are loc în mai multe etape, eventual cu acces la resurse de la distanță. Dar utilizatorul se poate întoarce la muncă cât mai curând posibil, cât timp recuperarea este încă în loc.

Trebuie mai jos, chiar mai jos...

Prototipul și-a dovedit funcționalitatea. Dar am găsit și nevoia de a merge mai departe, deoarece în unele cazuri există încă blocaje. De exemplu, sistemul de operare poate solicita diverse biblioteci în mai multe fire de execuție, ceea ce duce la buclarea serviciului nostru pe sine.

Problema la care lucrez în prezent este creșterea vitezei Active Restore și creșterea nivelului de securitate a sistemului. Să presupunem că sistemul nu are nevoie de întregul fișier, ci doar de o parte a acestuia. În acest scop, a fost dezvoltat un alt driver - driverul de filtru de disc. Nu mai funcționează la nivel de fișier, ci la nivel de bloc. Principiul de funcționare este similar: în modul de funcționare normal, șoferul pur și simplu înregistrează blocurile modificate pe disc, iar în modul de recuperare, încearcă să citească singur blocul și, dacă nu reușește, solicită serviciului să mărească prioritatea. Cu toate acestea, toate celelalte părți ale sistemului rămân aceleași. De exemplu, un serviciu la nivel de sistem de operare nici măcar nu bănuiește că i se cere să comunice cu un alt driver, deoarece sarcina principală este de a furniza sistemului de operare exact datele necesare pentru funcționare. Acest domeniu necesită îmbunătățiri semnificative, fie și doar pentru că serviciul nu știe încă să gândească la nivel de bloc.

Următorul pas am decis să lansez driverul mai profund și mai devreme, coborând la nivelul driverelor UEFI și al aplicațiilor Windows native în locul serviciului. În acest scop a fost dezvoltat Driver de boot UEFI (sau driverul DXE), care pornește și moare chiar înainte de pornirea sistemului de operare. Dar ne vom uita la „istoria” driverelor UEFI, detalii despre asamblare și instalare, precum și specificul aplicațiilor Windows Native în următoarea postare. Așa că abonați-vă la blogul nostru și, între timp, voi pregăti o poveste despre următoarea etapă a muncii. Mă bucur să văd comentariile și sfaturile voastre.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Ați avut vreodată situații în care recuperarea a durat foarte mult timp:

• 65.1%Da28

• 23.2%Nr.10

• 11.6%Nu m-am gândit la asta5

Au votat 43 de utilizatori. 3 de utilizatori s-au abținut.

Sursa: www.habr.com