Il backup dei dati importanti è una buona cosa. Ma cosa succede se è necessario continuare a lavorare immediatamente e ogni minuto conta? In Acronis abbiamo deciso di scoprire quanto fosse possibile avviare il sistema nel modo più rapido. Questo è il primo post di una serie su Active Restore, in cui parlerò di come abbiamo avviato il progetto insieme all'Università di Innopolis, quale soluzione abbiamo trovato e su cosa stiamo lavorando oggi. Maggiori dettagli – nel seguito.
Ciao! Mi chiamo Daulet Tumbaev e oggi desidero condividere con voi la mia esperienza nello sviluppo di un sistema che accelera il ripristino di emergenza. Per raccontare l'intero percorso di sviluppo del progetto, partiamo da lontano. Attualmente lavoro in Acronis, ma sono anche un laureato dell'Università di Innopolis, dove ho conseguito il master in "Gestione dello sviluppo software" (noto come MSIT-SE). Innopolis è un'università giovane, e il programma di studio è ancora più giovane. Tuttavia, è basato sui piani di studio dell'Università Carnegie Mellon, i cui elaborati includono un tema come i progetti industriali.
L'obiettivo di un progetto industriale è immergere lo studente nello sviluppo reale e consolidare le conoscenze acquisite nella pratica. A tal fine, l'università collabora con aziende come Yandex, Acronis, MTC e decine di altre (nel 2018, l'ateneo aveva 144 partner). Durante la collaborazione, le aziende propongono all'università le loro aree di lavoro, e gli studenti scelgono uno dei progetti che più si avvicina ai loro interessi e al loro livello di preparazione. Solo due anni fa ero ancora "dall'altra parte delle barricate" e lavoravo come studente su un altro progetto di Acronis. Ma questa volta sono diventato consulente tecnico per gli studenti dalla parte dell'azienda e ho proposto all'Innopolis il progetto Active Restore. L'idea stessa di Active Restore è stata formulata dal team Kernel di Acronis, tuttavia lo sviluppo della soluzione è iniziato insieme all'Università di Innopolis.
Active Restore – a cosa serve?
Tradizionalmente, il ripristino di emergenza opera secondo 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 aspettare N minuti, e solo dopo potrai riprendere a lavorare.
Il problema è che questo numero N, noto anche come RTO (recovery time objective), ovvero il tempo di ripristino consentito, può essere piuttosto significativo e dipende dalla velocità della connessione (se il ripristino avviene dal cloud), dalla capacità del disco rigido della tua macchina e da vari altri fattori. È possibile ridurlo? Sì, è possibile, poiché per riprendere le attività non è sempre necessario avere l'intero disco del computer a disposizione. Le stesse foto e video non influenzano la funzionalità del dispositivo e possono essere recuperati successivamente in background.
Driver necessario…
Il sistema operativo è progettato per avviarsi con un disco completamente pronto. Pertanto, Windows esegue una serie di controlli sull'integrità del disco. Il sistema non consentirà un avvio normale in assenza o con danneggiamento di alcuni file che il SO si aspetta di trovare. Per risolvere questo problema, abbiamo deciso di inserire sul disco dei cosiddetti file redirettori che sostituiscono i file mancanti o danneggiati, ma che in realtà sono dei vuoti. Creare tali redirettori non richiede molto tempo, poiché di fatto non contengono alcun contenuto.
Il ripristino avviene come segue. In un processo in background, parallelamente al funzionamento del sistema operativo, i "vuoti" vengono riempiti di dati. Il processo di ripristino in background tiene conto del carico sul disco e non supera il limite stabilito. Tuttavia, l'utente o lo stesso sistema operativo possono improvvisamente richiedere un file che non è ancora disponibile. Qui entra in gioco la seconda modalità di ripristino. La priorità del file richiesto aumenta al massimo e il processo di ripristino carica rapidamente il file sul disco. Il sistema operativo ottiene il file necessario, seppur con un lieve ritardo.
Questo è come appare il quadro ideale. Tuttavia, nel mondo reale, ci sono un'enorme quantità di insidie e potenziali deadlock. Insieme ai masterandi di Innopolis abbiamo deciso di esplorare questo scenario di ripristino, valutare il guadagno in RTO e capire se un tale approccio è fattibile. Infatti, soluzioni simili sul mercato non esistevano affatto in quel momento.
E se ho deciso di lasciare l'aspetto del servizio ai ragazzi di Innopolis, all'interno di Acronis è iniziato il lavoro su . Questo è stato affrontato dal team di Windows Kernel. Il piano era il seguente:
- Avviare il driver in una fase iniziale di avvio del sistema operativo,
- Durante il funzionamento, quando sarà completamente pronto, caricare il servizio.
- Il servizio gestisce le richieste del driver e coordina il suo ulteriore funzionamento.
Le complessità della creazione di driver
Se i miei colleghi parleranno del servizio in un altro post, in questo testo sveleremo le complessità dello sviluppo di driver. Un driver mini-filtro già sviluppato ha due modalità di funzionamento: quando il sistema è avviato in modalità normale e quando il sistema ha appena subito un crash e sta per essere ripristinato. Prima che avvenga il caricamento delle librerie e delle applicazioni dell'utente, e quindi anche del nostro servizio, il driver si comporta allo stesso modo. Non sa in quale stato si trovi attualmente il sistema. Di conseguenza, ogni create, read e write viene registrato e tutte le meta-informazioni vengono registrate. E quando il servizio sarà online, il driver fornisce queste informazioni al servizio.
Nel caso di un avvio normale, il servizio invia un segnale “Relax” al driver 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 ne informa il servizio, che tramite altri strumenti Acronis mantiene il backup del disco nel modo più attuale possibile sul supporto scelto dall'utente. Questo può essere un backup in cloud, remoto, incrementale o notturno.
Se si attiva la modalità di recupero, il servizio informa il driver che deve lavorare in modalità “Recovery”. Il sistema si è appena ripristinato dopo un crash e, non appena invia una richiesta di apertura di un file sul disco, il mini-filtro deve intercettare questa operazione, effettuare essa stessa la richiesta, controllare se il file esiste sul disco e se può essere aperto.
In caso di assenza del file, il mini-filtraggio trasmette questa informazione al servizio, che aumenta la priorità per il ripristino del file (nel frattempo, il ripristino avviene in background). Pertanto, questo file semplicemente salta all'inizio della coda. Dopo di che, il servizio stesso (o altri mezzi di Acronis) ripristina questo file e informa il driver che va tutto bene, ora il sistema operativo può accedervi e il driver "libera" la richiesta originale dal sistema al disco.
Se il ripristino non è possibile, il servizio informa il driver che il file non è presente nemmeno nel backup. Il nostro mini-filtraggio lascia semplicemente che la richiesta di sistema continui e la richiesta originale (il sistema operativo stesso o l'applicazione) riceve l'errore "file non trovato". Tuttavia, è perfettamente normale se il file non era realmente presente né sul disco né nel backup.
Certo, il sistema operativo funzionerà molto più lentamente, poiché la lettura di qualsiasi file o libreria avviene in più fasi, con possibile accesso a risorse remote. Ma gli utenti possono iniziare a lavorare in tempi brevi, mentre il ripristino è ancora in corso.
Devi scendere 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 deadlock. Ad esempio, il sistema operativo può richiedere diverse librerie in più thread, il che porta al blocco del nostro servizio su se stesso.
Il problema su cui sto lavorando attualmente è l'aumento della velocità di Active Restore e il miglioramento del livello di sicurezza del sistema. Supponiamo che al sistema non serva un intero file, ma solo una sua parte. A tal fine, è stato sviluppato un ulteriore driver: il driver filtro del disco. Questo lavora non a livello di file, ma a livello di blocco. Il principio di funzionamento è simile: in modalità normale, il driver semplicemente protocolla i blocchi modificati sul disco, mentre in modalità di ripristino cerca di leggere il blocco autonomamente e, in caso di fallimento, richiede al servizio di aumentare la priorità. Tutte le altre parti del sistema rimangono invariate. Ad esempio, il servizio a livello di OS nemmeno sospetta di comunicare con un'altra driver, poiché l'obiettivo principale è fornire all'OS esattamente i dati necessari per il funzionamento. Questa direzione richiede significativi sviluppi, almeno perché il servizio non è ancora in grado di operare a livello di blocco.
Il passo successivo che ho deciso di intraprendere è stato avviare il driver più in profondità e prima, scendendo a livello dei driver UEFI e delle applicazioni Native Windows invece del servizio. A tal fine è stato sviluppato (o driver DXE), che si avvia e termina ancora prima dell'avvio del sistema operativo. Ma la "storia" dei driver UEFI, i dettagli sull'assemblaggio e l'installazione, nonché le specifiche delle applicazioni Native Windows, saranno trattate nel prossimo post. Quindi, iscrivetevi al nostro blog, mentre io preparo un racconto sulla prossima fase dei lavori. Sarò felice di leggere i vostri commenti e suggerimenti.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Vi è mai capitato di trovarvi in situazioni in cui il ripristino è durato in modo straziante a lungo:
65.1%Sì28
23.2%No10
11.6%Non ci ho mai pensato5
Hanno votato 43 utenti. 3 utenti si sono astenuti.
Fonte: habr.com
