Il backup dei dati importanti è fondamentale. Ma cosa succede se è necessario continuare immediatamente e ogni minuto conta? Noi di Acronis abbiamo deciso di testare quanto sia possibile avviare il sistema nel modo più rapido possibile. Questo è il primo post di una serie su Active Restore, in cui spiegherò come abbiamo avviato il progetto insieme all'Università di Innopolis, quale soluzione abbiamo trovato e su cosa stiamo lavorando oggi. Maggiori dettagli sotto.
Ciao! Mi chiamo Daulet Tumbaev e oggi voglio condividere con voi la mia esperienza nello sviluppo di un sistema che accelera il ripristino di emergenza. Per raccontare l'intero percorso del progetto, iniziamo un po' indietro. Attualmente lavoro in Acronis, ma sono anche un laureato dell'Università di Innopolis, dove ho completato il programma di master in "Gestione dello sviluppo software" (noto come MSIT-SE). Innopolis è un'università giovane e il programma di studi è ancora più recente. Tuttavia, è basato sui piani di studio della Carnegie Mellon University, che ha una tematica legata ai progetti industriali.
L'obiettivo del progetto industriale è immergere lo studente nella vera sviluppo e consolidare le conoscenze acquisite nella pratica. A tal fine, l'università collabora con aziende come Yandex, Acronis, MTC e molte altre (fino al 2018, l'ateneo aveva 144 partner). Durante la collaborazione, le aziende propongono i loro indirizzi di lavoro all'università e gli studenti scelgono uno dei progetti che meglio si adatta ai loro interessi e al loro livello di preparazione. Solo due anni fa, ero ancora "dall'altra parte della barricata" e lavoravo come studente su un altro progetto di Acronis. Ma questa volta sono diventato consulente tecnico per gli studenti dall'azienda e ho proposto all'Università di Innopolis il progetto Active Restore. L'idea stessa di Active Restore è stata formulata dal team Kernel dell'Acronis, tuttavia lo sviluppo della soluzione è iniziato insieme all'Università di Innopolis.
Active Restore – perché è necessario?
Tradizionalmente, il ripristino di emergenza segue uno schema standard. Dopo un problema con il computer, accedi all'interfaccia web di un sistema di backup, ad esempio, Acronis True Image, e premi il grande pulsante "ripristina". Poi devi attendere N minuti, e solo dopo potrai riprendere a lavorare.
Il problema è che questo numero N, noto anche come RTO (recovery time objective), il tempo di recupero accettabile, può essere piuttosto significativo, e dipende dalla velocità della connessione (se il ripristino avviene dal cloud), dalla dimensione del disco rigido del tuo computer e da diversi altri fattori. È possibile ridurlo? Sì, è possibile, perché per riprendere il lavoro non è sempre necessario il disco completo del computer. Ad esempio, le foto e i video non influiscono sulle funzionalità del dispositivo e possono essere recuperati successivamente in background.
Driver necessari...
Il sistema operativo si aspetta di avviarsi con un disco completamente pronto. Pertanto, Windows esegue una serie di controlli sull'integrità del disco. Il sistema non permetterà un avvio normale in assenza o danneggiamento di alcuni file che il SO si aspetta di trovare. Per risolvere questo problema, è stata presa la decisione di inserire nel disco quelli che noi chiamiamo file reindirizzatori, che sostituiscono file mancanti o danneggiati, ma in effetti sono delle comodità. Creare tali reindirizzatori richiede davvero poco tempo, poiché non hanno contenuti.
Successivamente, il ripristino avviene nel seguente modo. Un processo in background, parallelamente al funzionamento del sistema operativo, riempie i "comodini" con i dati. Il processo di ripristino in background tiene conto del carico sul disco e non supera il limite stabilito. Tuttavia, l'utente o il sistema operativo stesso potrebbe improvvisamente richiedere un file che non è ancora disponibile. A questo punto entra in gioco la seconda modalità di ripristino. La priorità del file richiesto viene elevata al massimo e il processo di ripristino carica urgentemente il file sul disco. Il sistema operativo riceve il file necessario, anche se con un leggero ritardo.
Questa è l'immagine ideale. Tuttavia, nel mondo reale, ci sono un'enorme numero di insidie e potenziali deadlock. Insieme ai laureandi di Innopolis abbiamo deciso di esplorare questo scenario di ripristino, valutare i guadagni in RTO e capire se un tale approccio fosse possibile. Infatti, soluzioni simili non erano presenti sul mercato a quel tempo.
E se ho deciso di lasciare la parte di servizio ai ragazzi di Innopolis, all'interno di Acronis è iniziato il lavoro su . Questo compito è stato assunto dal team del Windows Kernel. Il piano era il seguente:
- Avviare il driver in una fase iniziale di avvio del sistema operativo,
- Quando sarebbe completamente pronto, caricare il servizio
- Il servizio gestisce le richieste del driver e coordina il suo funzionamento successivo.
Le sfide della creazione di driver
Se i miei colleghi parleranno del servizio in un altro post, in questo testo esploreremo le sfide nello sviluppo del driver. Il mini-driver già sviluppato ha due modalità operative: quando il sistema è avviato normalmente e quando il sistema ha appena subito un guasto e sta tornando operativo. Prima che vengano caricati le librerie e le applicazioni da parte dell'utente, e quindi anche il nostro servizio, il driver si comporta allo stesso modo. Non sa in quale stato si trovi attualmente il sistema. Di conseguenza, ogni operazione di create, read e write viene registrata, con tutti i metadati memorizzati. E quando il servizio sarà online, il driver fornirà queste informazioni al servizio.
In caso di avvio regolare, il servizio invia al driver un segnale “Relax”, affinché si “rilassi” e smetta di registrare meticolosamente tutti i dati. In questo caso, il driver passa a registrare solo le modifiche sul disco e le comunica al servizio, che con altri strumenti Acronis mantiene il backup del disco nel suo stato più attuale sul supporto scelto dall'utente. Potrebbe essere un backup in cloud, remoto, graduale o notturno.
Se si attiva la modalità di recupero, il servizio comunica al driver che deve lavorare in modalità “Recovery”. Il sistema si è appena ripristinato da un guasto e, non appena riceve una richiesta di apertura di un file sul disco, il mini-driver deve intercettare questa operazione, fare la richiesta, verificare se il file esiste sul disco e se può essere aperto.
In caso di assenza del file, il mini-driver trasmette queste informazioni al servizio, che aumenta la priorità del ripristino del file (nel frattempo il ripristino continua in background). Risulta che questo file salta semplicemente all'inizio della coda. Dopo di che, il servizio stesso (o con altri mezzi Acronis) ripristina il file e comunica al driver che va tutto bene, ora il sistema operativo può accedervi e il driver “libera” la richiesta originale, dal sistema al disco.
Se il recupero non è possibile, il servizio informa il driver che il file non è presente nemmeno nel backup. Il nostro mini-driver semplicemente passa la richiesta di sistema e la richiesta originale (il sistema operativo o l'applicazione) riceve un errore “file non trovato”. Tuttavia, questo è del tutto normale, se il file non era già presente sul disco e nel backup.
Certo, il sistema operativo funzionerà molto più lentamente, poiché la lettura di qualsiasi file o libreria avviene in più fasi e, possibilmente, con accesso a risorse remote. Ma in questo modo, l'utente può iniziare a lavorare nel più breve tempo possibile, mentre il recupero continua.
Deve essere più in basso, ancora più in basso…
Il prototipo ha dimostrato di funzionare. Ma abbiamo anche scoperto la necessità di andare oltre, perché in alcuni casi si verificano ancora dei deadlock. Ad esempio, il sistema operativo può richiedere diverse librerie in più thread, il che porta a una chiusura del nostro servizio su se stesso.
Il problema su cui sto lavorando ora è l'aumento della velocità dell'Active Restore e il miglioramento della sicurezza del sistema. Supponiamo che a sistema non serva un intero file, ma solo una sua parte. A tal fine è stato sviluppato un altro driver: il driver di filtro del disco. Questo non opera più a livello di file, ma a livello di blocco. Il principio di funzionamento è simile: in modalità normale, il driver registra semplicemente i blocchi modificati sul disco, mentre in modalità di recupero cerca di leggere il blocco da solo, richiedendo ai servizi un aumento di priorità in caso di fallimento. Nel contempo, tutte le altre parti del sistema rimangono le stesse. Ad esempio, il servizio a livello di sistema operativo non sospetta nemmeno che gli venga proposto di comunicare con un altro driver, perché l'obiettivo principale è fornire al sistema operativo esattamente i dati necessari al suo funzionamento. Questa direzione richiede significativi miglioramenti, in quanto il servizio non è ancora in grado di lavorare a livello di blocco.
Il passo successivo che ho deciso di intraprendere è avviare il driver più in profondità e prima, scendendo al livello dei driver UEFI e delle applicazioni Native Windows anziché del servizio. A questo scopo è stato sviluppato (o driver DXE), che si avvia e termina prima dell'avvio del sistema operativo. Ma esploreremo la "storia" dei driver UEFI, i dettagli sulla creazione e l'installazione, e le specifiche delle applicazioni native di Windows nel prossimo post. Quindi, iscriviti al nostro blog, mentre preparo la narrazione sul prossimo stadio dei lavori. Sarò felice di ricevere i vostri commenti e suggerimenti.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Hai mai avuto situazioni in cui il ripristino è durato incredibilmente a lungo:
65.1%Sì28
23.2%No10
11.6%Non ci avevo mai pensato5
Hanno votato 43 utenti. Si sono astenuti 3 utenti.
Fonte: habr.com
