Kopie zapasowe ważnych danych to dobry pomysł. Ale co jeśli trzeba kontynuować pracę natychmiast, a każda minuta ma znaczenie? W Acronis postanowiliśmy sprawdzić, jak szybko można uruchomić system. To pierwszy post z serii Active Restore, w którym opowiem, jak przystąpiliśmy do projektu we współpracy z Uniwersytetem Innopolis, jakie rozwiązanie znaleźliśmy i nad czym pracujemy dzisiaj. Szczegóły poniżej.
Cześć! Nazywam się Dałłet Tumbaev i dzisiaj chciałbym podzielić się z Wami swoim doświadczeniem w rozwijaniu systemu przyspieszającego odzyskiwanie po awarii. Żeby opowiedzieć o całej drodze rozwoju projektu, zacznijmy od początku. Obecnie pracuję w Acronis, ale również jestem absolwentem Uniwersytetu Innopolis, który ukończyłem w ramach programu magisterskiego „Zarządzanie Rozwojem Oprogramowania” (znanego jako MSIT-SE). Innopolis to młody uniwersytet, a program nauczania jest jeszcze młodszy. Jednak został oparty na planach studiów Uniwersytetu Carnegie Mellon, który ma obszerne zasoby poświęcone projektom przemysłowym.
Celem projektu przemysłowego jest zanurzenie studenta w rzeczywistym rozwoju i wzmocnienie zdobytej wiedzy w praktyce. Uniwersytet współpracuje z takimi firmami, jak Yandex, Acronis, MTC i dziesiątkami innych (w sumie w 2018 roku uniwersytet miał 144 partnerów). W trakcie współpracy firmy oferują uniwersytetowi swoje obszary pracy, a studenci wybierają jeden z projektów, który jest im najbliższy zainteresowaniami i poziomem przygotowania. Jeszcze dwa lata temu byłem „po drugiej stronie barykady” i pracowałem jako student nad innym projektem Acronis. Tym razem zostałem doradcą technicznym dla studentów ze strony firmy i zaproponowałem Uniwersytetowi Innopolis projekt Active Restore. Sama idea Active Restore została sformułowana przez zespół Kernel w firmie Acronis, jednak rozwój rozwiązania rozpoczął się we współpracy z Uniwersytetem Innopolis.
Active Restore – po co to potrzebne?
Tradycyjnie odzyskiwanie po awarii działa według standardowego schematu. Po problemach z komputerem wchodzisz do interfejsu internetowego jakiegoś systemu do tworzenia kopii zapasowych, na przykład Acronis True Image, i naciskasz duży przycisk „odzyskaj”. Następnie musisz poczekać N minut, a dopiero potem będziesz mógł kontynuować pracę.
Problem polega na tym, że ta wartość N, znana także jako RTO (recovery time objective), dopuszczalny czas przywracania, może być dość imponująca i zależy od prędkości połączenia (jeśli przywracanie odbywa się z chmury), od pojemności dysku twardego Twojego urządzenia oraz wielu innych czynników. Czy można ją zmniejszyć? Tak, można, ponieważ aby wznowić działanie, nie zawsze potrzebny jest pełny dysk komputera. Te same zdjęcia i filmy nie wpływają na funkcjonalność urządzenia i mogą być ładowane później w tle.
Potrzebny sterownik…
System operacyjny powinien uruchamiać się z całkowicie gotowym dyskiem. Dlatego Windows przeprowadza szereg kontroli integralności dysku. System nie pozwoli na normalne uruchomienie, jeśli brakuje lub są uszkodzone niektóre pliki, które OS oczekuje znaleźć. Aby rozwiązać ten problem, postanowiono umieścić na dysku stworzone przez nas tak zwane pliki przekierowujące, które zastępują brakujące lub uszkodzone pliki, lecz w rzeczywistości są pustymi plikami. Stworzenie takich przekierowań nie zajmuje dużo czasu, ponieważ w istocie nie mają one żadnej zawartości.
Dalej przywracanie odbywa się w następujący sposób. Procesy w tle, równolegle z pracą systemu operacyjnego, wypełniają „puste pliki” danymi. Proces tła przywracania uwzględnia obciążenie dysku i nie przekracza ustalonego limitu. Jednak użytkownik lub sam system operacyjny może nagle zażądać pliku, którego jeszcze nie ma. Wtedy wchodzi w grę drugi tryb przywracania. Priorytet zażądania pliku zwiększa się do maksimum, a proces przywracania pilnie ładował plik na dysk. System operacyjny otrzymuje potrzebny plik, choć z niewielką zwłoką.
Tak wygląda idealny obraz. Jednak w realnym świecie istnieje ogromna liczba pułapek i potencjalnych zatorów. Wraz z magistrantami z Innopolis postanowiliśmy zbadać ten scenariusz przywracania, ocenić zyski w RTO i zrozumieć, czy takie podejście jest możliwe? Otóż na rynku nie było podobnych rozwiązań w tamtym czasie.
A jeśli postanowiłem powierzyć część serwisową kolegom z Innopolis, w Acronis rozpoczęła się praca nad To zrealizował zespół Windows Kernel. Plan był taki:
- Uruchomić sterownik na wczesnym etapie uruchamiania systemu operacyjnego,
- W trakcie pracy, gdy będzie całkowicie gotowy, załadować usługę,
- Usługa przetwarza żądania sterownika i koordynuje jego dalszą pracę.
Szczegóły budowania sterowników
Jeśli moi koledzy opowiedzą o usłudze w innym wpisie, to w tym tekście omówimy szczegóły dotyczące rozwoju sterownika. Już opracowany mini-filtr sterownika ma dwa tryby pracy – gdy system uruchamia się w normalnym trybie oraz gdy system dopiero co przeszedł awarię i odbywa się jego przywracanie. Zanim rozpoczną się ładowanie bibliotek i aplikacji użytkownika, a w konsekwencji także naszej usługi, sterownik zachowuje się w ten sam sposób. Nie wie, w jakim stanie obecnie znajduje się system. W efekcie każde create, read i write jest rejestrowane, a wszystkie metadane są rejestrowane. A gdy usługa będzie online, sterownik dostarcza te informacje usłudze.
W przypadku zwykłego uruchomienia usługa przekazuje sterownikowi sygnał 'Relax', aby 'zrelaksował się' i przestał skrupulatnie rejestrować wszystkie dane. W takim przypadku sterownik przechodzi na rejestrowanie tylko zmian na dysku i informuje o nich usługę, która z wykorzystaniem innych narzędzi Acronis utrzymuje kopię zapasową dysku w maksymalnie aktualnym stanie na nośniku określonym przez użytkownika. Może to być kopia zapasowa w chmurze, zdalna, stopniowa lub nocna.
Jeśli włącza się tryb przywracania, usługa informuje sterownik, że musi działać w trybie 'Recovery'. System dopiero co został przywrócony po awarii, a gdy tylko wysyła żądanie otwarcia pliku na dysku, mini-filtr powinien przechwycić tę operację, samodzielnie wykonać to żądanie, sprawdzić, czy taki plik jest na dysku i czy można go otworzyć.
W przypadku braku pliku, mini-filtr przekazuje tę informację do usługi, która zwiększa priorytet przywracania pliku (w tym czasie w tle trwa przywracanie). Okazuje się, że ten plik po prostu skacze na początek kolejki. Następnie usługa sama (lub innymi środkami Acronis) przywraca ten plik i informuje sterownik, że wszystko jest w porządku, teraz system operacyjny może się do niego odwołać, a sterownik "zwalnia" oryginalne żądanie z systemu do dysku.
Jeśli przywrócenie jest niemożliwe, usługa informuje sterownik, że pliku nie ma również w kopii zapasowej. Nasz mini-filtr sterownika po prostu przepuszcza zapytanie systemowe dalej, a oryginalny wnioskodawca (sam system operacyjny lub aplikacja) otrzymuje błąd "plik nie znaleziono". Niemniej jednak, to całkowicie normalne, jeśli pliku rzeczywiście nie było na dysku i w kopii zapasowej.
Oczywiście, system operacyjny będzie działał znacznie wolniej, ponieważ odczyt dowolnego pliku lub biblioteki odbywa się w kilku etapach, przy czym być może z dostępem do zasobów zdalnych. Ale użytkownik może rozpocząć pracę w najkrótszym możliwym czasie, podczas gdy przywracanie nadal się odbywa.
Musisz niżej, jeszcze niżej…
Prototyp udowodnił swoją funkcjonalność. Ale odkryliśmy również potrzebę dalszego rozwoju, ponieważ w niektórych przypadkach wciąż występują deadlocki. Na przykład, system operacyjny może żądać różnych bibliotek w kilku wątkach, co prowadzi do zamknięcia naszej usługi na samej sobie.
Problem, nad którym obecnie pracuję, polega na zwiększeniu prędkości Active Restore oraz podniesieniu poziomu bezpieczeństwa systemu. Załóżmy, że system potrzebuje nie całego pliku, a tylko jego części. W tym celu opracowano kolejny sterownik — filtr dysku. Działa on już nie na poziomie plików, a na poziomie bloków. Zasada działania jest podobna: w normalnym trybie pracy sterownik po prostu rejestruje zmienione bloki na dysku, a w trybie przywracania próbuje samodzielnie odczytać blok, a w przypadku niepowodzenia żąda podniesienia priorytetu od serwisu. Przy tym wszystkie inne części systemu pozostają takie same. Na przykład, serwis na poziomie systemu operacyjnego nawet nie podejrzewa, że ma do czynienia z innym sterownikiem, ponieważ głównym zadaniem jest dostarczenie systemowi operacyjnemu dokładnie tych danych, które są niezbędne do działania. Ten kierunek wymaga znacznych poprawek przynajmniej dlatego, że serwis wciąż nie potrafi myśleć na poziomie bloków.
Kolejnym krokiem postanowiłem uruchomić sterownik głębiej i wcześniej, schodząc na poziom sterowników UEFI oraz aplikacji natywnych Windows zamiast serwisu. W tym celu opracowano (lub sterownik DXE), który startuje i umiera jeszcze przed uruchomieniem systemu operacyjnego. Ale „historię” sterowników UEFI, szczegóły dotyczące kompilacji i instalacji, a także specyfikę aplikacji natywnych Windows omówimy w następnym poście. Dlatego subskrybujcie naszego bloga, a ja w międzyczasie przygotuję opowieść o następnym etapie prac. Będę wdzięczny za Wasze komentarze i rady.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Czy mieliście kiedyś sytuacje, gdy przywracanie trwało niewiarygodnie długo:
65.1%Tak28
23.2%Nie10
11.6%Nie myślałem5
Zagłosowało 43 użytkowników. Wstrzymało się 3 użytkowników.
Źródło: habr.com
