Das Sichern wichtiger Daten ist gut. Was aber, wenn die Arbeit sofort fortgesetzt werden muss und jede Minute zählt? Wir bei Acronis haben uns entschlossen zu prüfen, wie es möglich ist, die Aufgabe, das System so schnell wie möglich zu starten, zu lösen. Und dies ist der erste Beitrag in der Active Restore-Reihe, in dem ich Ihnen erzähle, wie wir das Projekt mit der Innopolis University begonnen haben, welche Lösung wir gefunden haben und woran wir heute arbeiten. Details - unter dem Schnitt.
Hallo! Mein Name ist Daulet Tumbaev, und heute möchte ich Ihnen meine Erfahrungen bei der Entwicklung eines Systems mitteilen, das die Wiederherstellung nach einem Katastrophenfall beschleunigt. Um über den gesamten Entwicklungspfad des Projekts zu sprechen, lassen Sie uns von weitem beginnen. Ich arbeite derzeit bei Acronis, habe aber auch einen Abschluss der Innopolis University, die ich im Master-Programm für Software Development Management (MSIT-SE) erworben habe. Innopolis ist eine junge Universität, und der Lehrplan ist noch jünger. Aber dann baut es auf dem Lehrplan der Carnegie Mellon University (Carnegie Mellon University) auf, in dessen Errungenschaften es so etwas wie industrielle Projekte gibt.
Ziel des Industrieprojekts ist es, den Studenten in die reale Entwicklung einzutauchen und das in der Praxis erworbene Wissen zu festigen. Zu diesem Zweck kooperiert die Universität mit Unternehmen wie Yandex, Acronis, MTC und Dutzenden anderen (insgesamt hatte die Universität im Jahr 2018 144 Partner). Im Rahmen der Kooperation bieten Unternehmen der Universität ihre Arbeitsanweisungen an, und die Studierenden wählen eines der Projekte aus, das ihnen in ihrem Interesse und Ausbildungsstand näher steht. Noch vor zwei Jahren befand ich mich „auf der anderen Seite der Barrikaden“ und arbeitete als Student an einem anderen Acronis-Projekt. Diesmal wurde ich technischer Berater für Studenten des Unternehmens und schlug Innopolis das Active Restore-Projekt vor. Die Idee zu Active Restore wurde vom Kernel-Team von Acronis formuliert, aber die Entwicklung der Lösung begann mit der Innopolis University.
Aktive Wiederherstellung - warum wird dies benötigt?
Traditionell funktioniert die Notfallwiederherstellung nach einem Standardschema. Nach Problemen mit dem Computer rufen Sie die Weboberfläche eines Backup-Systems auf, z. B. Acronis True Image, und klicken auf die große Schaltfläche „Wiederherstellen“. Als nächstes müssen Sie N Minuten warten, und erst danach können Sie weiterarbeiten.
Das Problem besteht darin, dass diese Zahl N, auch als RTO (Recovery Time Objective) bezeichnet, die zulässige Wiederherstellungszeit, sehr beeindruckend sein kann. Dies hängt von der Verbindungsgeschwindigkeit (falls eine Wiederherstellung aus der Cloud erfolgt), dem Festplattenvolumen Ihres Computers und der Verfügbarkeit ab eine Reihe anderer Faktoren. Kann es reduziert werden? Ja, das können Sie, denn um die Arbeit wieder aufzunehmen, benötigen Sie nicht immer eine vollständige Computerfestplatte. Dieselben Fotos und Videos beeinträchtigen nicht die Funktionalität des Geräts und können später im Hintergrund abgerufen werden.
Treiber benötigt ...
Das Betriebssystem erwartet den Start mit einer vollständig abgeschlossenen Festplatte. Daher führt Windows eine Reihe von Überprüfungen auf Datenträgerintegrität durch. Das System lässt keinen normalen Start zu, wenn einige vom Betriebssystem erwartete Dateien fehlen oder beschädigt sind. Um dieses Problem zu lösen, wurde beschlossen, die von uns erstellten so genannten Redirector-Dateien auf die Festplatte zu kopieren, die fehlende oder beschädigte Dateien ersetzen, in Wirklichkeit aber Dummies sind. Das Erstellen solcher Redirectors dauert nicht lange, da sie tatsächlich keinen Inhalt haben.
Weitere Wiederherstellung erfolgt wie folgt. Hintergrundprozess Parallel zum Betrieb des Betriebssystems werden „Dummies“ mit Daten gefüllt. Der Hintergrundwiederherstellungsprozess berücksichtigt die Belastung der Festplatte und überschreitet das festgelegte Limit nicht. Der Benutzer oder das Betriebssystem selbst können jedoch plötzlich eine Datei anfordern, die noch nicht vorhanden ist. Hier kommt der zweite Wiederherstellungsmodus ins Spiel. Die Priorität der angeforderten Datei wird auf das Maximum erhöht, und der Wiederherstellungsprozess lädt die Datei dringend auf die Festplatte hoch. Das Betriebssystem empfängt die gewünschte Datei, allerdings mit einer leichten Verzögerung.
Es sieht aus wie ein perfektes Bild. In der realen Welt gibt es jedoch eine Vielzahl von Fallstricken und potenziellen Deadlocks. Zusammen mit den Innopolis-Studenten beschlossen wir, dieses Wiederherstellungsszenario zu untersuchen, den Gewinn an RTO zu bewerten und zu verstehen, ob dieser Ansatz machbar ist. Solche Marktentscheidungen gab es damals schlichtweg nicht.
Und wenn ich mich entschloss, die Service-Komponente an die Jungs von Innopolis zu übergeben, begann ich in Acronis mit der Arbeit an einem
Mini-Filter-Dateisystemtreiber . Dies wurde vom Windows-Kernel-Team durchgeführt. Der Plan war:
- Führen Sie den Treiber in einem frühen Stadium des Startens des Betriebssystems aus.
- Laden Sie den Dienst während des Betriebs herunter, wenn der Benutzerbereich vollständig verfügbar ist
- Der Service bearbeitet Fahreranfragen und koordiniert die weitere Arbeit.
Die Feinheiten der Fahrertechnik
Wenn meine Kollegen in einem anderen Beitrag über den Service sprechen, werden wir in diesem Text die Feinheiten der Treiberentwicklung aufzeigen. Der bereits entwickelte Treiber-Minifilter verfügt über zwei Betriebsmodi - als das System im normalen Modus gestartet wurde und als das System gerade einen Fehler aufwies und seine Wiederherstellung erfolgte. Vor dem Laden der Benutzerbibliotheken und Anwendungen und damit unseres Dienstes verhält sich der Treiber genauso. Er weiß nicht, in welchem Zustand sich das System gerade befindet. Dadurch wird jedes Erstellen, Lesen und Schreiben protokolliert, alle Metadaten werden aufgezeichnet. Wenn der Dienst online ist, stellt der Fahrer diese Informationen dem Dienst zur Verfügung.
Im Falle eines normalen Starts sendet der Dienst ein Entspannungssignal an den Fahrer, so dass er sich entspannt und nicht mehr alle Daten gewissenhaft protokolliert. In diesem Fall wechselt der Treiber zur Protokollierung nur der Änderungen auf der Festplatte und meldet sie an den Dienst, der mit Hilfe anderer Acronis-Tools die Sicherung der Festplatte auf dem vom Benutzer definierten Datenträger auf dem neuesten Stand hält. Dies kann eine Cloud-, Remote-, schrittweise oder Nachtsicherung sein.
Wenn der Wiederherstellungsmodus aktiviert ist, informiert der Dienst den Treiber, dass er im Wiederherstellungsmodus arbeiten muss. Das System wurde gerade nach einem Fehler wiederhergestellt. Sobald der Minifilter eine Anforderung zum Öffnen einer Datei auf der Festplatte ausgibt, sollte er diesen Vorgang abfangen, die Anforderung selbst ausführen und prüfen, ob sich eine solche Datei auf der Festplatte befindet und ob sie geöffnet werden kann.
Wenn keine Datei vorhanden ist, überträgt der Minifilter diese Informationen an den Dienst, wodurch die Priorität der Dateiwiederherstellung erhöht wird (während der gesamten Zeit wird die Wiederherstellung ausgeführt). Es stellt sich heraus, dass diese Datei nur an den Anfang der Warteschlange springt. Danach stellt der Dienst selbst (oder andere Acronis-Tools) diese Datei wieder her und teilt dem Treiber mit, dass alles in Ordnung ist. Jetzt kann das Betriebssystem darauf zugreifen und der Treiber gibt die ursprüngliche Anforderung vom System auf die Festplatte „frei“.
Wenn eine Wiederherstellung nicht möglich ist, informiert der Dienst den Treiber, dass sich auch keine Datei in der Sicherung befindet. Unser Minifiltertreiber überspringt die Systemanforderung einfach weiter und der ursprüngliche Anforderer (das Betriebssystem selbst oder die Anwendung) erhält den Fehler "Datei nicht gefunden". Dies ist jedoch ganz normal, wenn sich die Datei wirklich nicht auf der Festplatte und im Backup befand.
Natürlich arbeitet das Betriebssystem viel langsamer, da das Lesen einer Datei oder Bibliothek in mehreren Phasen erfolgt und möglicherweise auch auf Remote-Ressourcen zugegriffen werden kann. Aber dann kann der Benutzer so schnell wie möglich mit der Arbeit beginnen, während die Wiederherstellung noch stattfindet.
Brauche weniger, noch weniger ...
Der Prototyp hat sich bewährt. Wir haben aber auch festgestellt, dass wir weitermachen müssen, da in einigen Fällen immer noch Deadlocks auftreten. Beispielsweise kann das Betriebssystem verschiedene Bibliotheken in mehreren Threads anfordern, was dazu führt, dass unser Dienst für sich selbst geschlossen wird.
Das Problem, an dem ich gerade arbeite, besteht darin, die Geschwindigkeit der aktiven Wiederherstellung zu erhöhen und die Systemsicherheit zu erhöhen. Angenommen, das System benötigt keine ganze Datei, sondern nur einen Teil davon. Hierfür wurde ein weiterer Treiber entwickelt - ein Festplattenfiltertreiber. Es funktioniert nicht mehr auf der Datei, sondern auf der Blockebene. Das Funktionsprinzip ist ähnlich: Im normalen Betrieb protokolliert der Treiber einfach die geänderten Blöcke auf der Festplatte, und im Wiederherstellungsmodus versucht er, den Block selbst zu lesen. Im Fehlerfall fordert er den Dienst auf, die Priorität zu erhöhen. Alle anderen Teile des Systems bleiben jedoch gleich. Beispielsweise ahnt ein Dienst auf Betriebssystemebene nicht einmal, dass er zur Kommunikation mit einem anderen Treiber angeboten wird, da die Hauptaufgabe darin besteht, dem Betriebssystem genau die Daten zur Verfügung zu stellen, die für das Funktionieren erforderlich sind. Diese Richtung erfordert erhebliche Verbesserungen, schon allein deshalb, weil der Dienst noch nicht weiß, wie er auf Blockebene denken soll.
Im nächsten Schritt habe ich beschlossen, den Treiber ausführlicher und früher auszuführen und statt des Dienstes die UEFI-Treiber und native Windows-Anwendungen zu verwenden. Zu diesem Zweck wurde ein
UEFI-Boot-Treiber (oder DXE-Treiber) entwickelt, der startet und abstirbt, bevor das Betriebssystem gestartet wird. Die „Geschichte“ der UEFI-Treiber, Einzelheiten zur Montage und Installation sowie die Besonderheiten der Windows Native-Anwendungen werden wir im nächsten Beitrag behandeln. Abonnieren Sie also unseren Blog und ich bereite vorerst eine Geschichte über die nächste Phase der Arbeit vor. Ich würde mich über Ihre Kommentare und Ratschläge freuen.