Sao lưu dữ liệu quan trọng là một điều tốt. Nhưng điều gì sẽ xảy ra nếu công việc cần được tiếp tục ngay lập tức và mỗi phút đều có giá trị? Tại Acronis, chúng tôi quyết định kiểm tra xem có thể giải quyết vấn đề khởi động hệ thống nhanh nhất có thể hay không. Và đây là bài đăng đầu tiên trong loạt bài Active Restore, trong đó tôi sẽ cho bạn biết cách chúng tôi bắt đầu dự án cùng với Đại học Innopolis, giải pháp chúng tôi đã tìm ra và những gì chúng tôi đang làm ngày hôm nay. Chi tiết đang được cắt giảm.
Xin chào! Tên tôi là Daulet Tumbayev và hôm nay tôi muốn chia sẻ với các bạn kinh nghiệm của tôi trong việc phát triển một hệ thống tăng tốc độ khắc phục thảm họa. Để nói về toàn bộ chặng đường phát triển của dự án, chúng ta hãy bắt đầu từ xa một chút. Tôi hiện đang làm việc tại Acronis, nhưng tôi cũng đã tốt nghiệp Đại học Innopolis, nơi tôi đã hoàn thành chương trình Thạc sĩ về Quản lý Phát triển Phần mềm (được gọi là MSIT-SE). Innopolis là một trường đại học trẻ và chương trình giảng dạy thậm chí còn trẻ hơn. Nhưng nó được xây dựng dựa trên chương trình giảng dạy của Đại học Carnegie Mellon, nơi có công trình nghiên cứu về chủ đề như các dự án công nghiệp.
Mục đích của dự án công nghiệp là giúp sinh viên hòa mình vào sự phát triển thực sự và củng cố kiến thức thu được vào thực tế. Để làm được điều này, trường đại học hợp tác với các công ty như Yandex, Acronis, MTC và hàng chục công ty khác (tổng cộng, tính đến năm 2018, trường có 144 đối tác). Trong quá trình hợp tác, các công ty cung cấp khu vực làm việc của họ cho trường đại học và sinh viên chọn một trong những dự án gần với sở thích và trình độ đào tạo của họ hơn. Theo đúng nghĩa đen, hai năm trước, tôi vẫn “ở bên kia rào chắn” và làm sinh viên trong một dự án Acronis khác. Nhưng lần này tôi trở thành cố vấn kỹ thuật cho sinh viên bên công ty và đề xuất dự án Active Restore cho Innopolis. Ý tưởng về Active Restore được nhóm Kernel tại Acronis xây dựng, nhưng việc phát triển giải pháp này lại bắt đầu cùng với Đại học Innopolis.
Khôi phục hoạt động - tại sao cần thiết?
Theo truyền thống, việc khắc phục thảm họa hoạt động theo một sơ đồ tiêu chuẩn. Sau khi máy tính gặp sự cố, bạn truy cập giao diện web của một số hệ thống sao lưu, chẳng hạn như Acronis True Image và nhấp vào nút “khôi phục” lớn. Tiếp theo, bạn cần đợi N phút và chỉ sau đó bạn mới có thể tiếp tục làm việc.
Vấn đề là con số N này hay còn gọi là RTO (recovery time target), thời gian khôi phục cho phép, có thể khá ấn tượng, điều này phụ thuộc vào tốc độ kết nối (nếu khôi phục từ đám mây), dung lượng ổ cứng máy của bạn , và một số yếu tố khác. Có thể giảm nó? Có, bạn có thể, vì để tiếp tục công việc, không phải lúc nào bạn cũng cần có đĩa máy tính đầy. Các ảnh và video giống nhau không ảnh hưởng đến chức năng của thiết bị theo bất kỳ cách nào và có thể được hiển thị sau này ở chế độ nền.
Cần tài xế...
Операционная система рассчитывает запускаться с полностью готовым диском. Поэтому Windows проводит ряд проверок на целостность диска. Система не позволит произвести нормальный запуск при отсутствии или повреждении некоторых файлов, которые ОС ожидает найти. Для решений этой проблемы было решено подложить на диск созданные нами, так называемые, файлы-редиректоры, которые заменяют отсутствующие или поврежденные файлы, но по факту являются пустышками. Создать такие редиректоры совсем недолго, ведь они по факту не имеют никакого содержимого.
Sự phục hồi tiếp theo xảy ra như sau. Bằng một tiến trình nền, song song với hoạt động của hệ điều hành, các “hình nộm” chứa đầy dữ liệu. Quá trình khôi phục nền có tính đến tải đĩa và không vượt quá giới hạn đã đặt. Tuy nhiên, người dùng hoặc bản thân hệ điều hành có thể đột nhiên yêu cầu một tệp chưa tồn tại. Đây là nơi chế độ phục hồi thứ hai phát huy tác dụng. Mức độ ưu tiên của tệp được yêu cầu được nâng lên tối đa và quá trình khôi phục sẽ tải tệp khẩn cấp vào đĩa. Hệ điều hành nhận được tệp được yêu cầu, mặc dù có một chút chậm trễ.
Đây là những gì một hình ảnh lý tưởng trông như thế nào. Tuy nhiên, trong thế giới thực, có rất nhiều cạm bẫy và bế tắc tiềm ẩn. Cùng với các sinh viên thạc sĩ Innopolis, chúng tôi quyết định khám phá kịch bản phục hồi này, đánh giá lợi ích đạt được trong RTO và tìm hiểu xem liệu cách tiếp cận như vậy có khả thi hay không? Rốt cuộc, đơn giản là không có giải pháp nào như vậy trên thị trường vào thời điểm đó.
Và nếu tôi quyết định cung cấp thành phần dịch vụ cho những người đến từ Innopolis, thì bên trong Acronis, công việc sẽ bắt đầu . Этим занялась команда Windows Kernel. План был такой:
- Khởi chạy trình điều khiển ở giai đoạn đầu khởi động hệ điều hành,
- Trong quá trình làm việc, khi sẽ hoàn toàn sẵn sàng, tải xuống dịch vụ
- Dịch vụ xử lý các yêu cầu của trình điều khiển và điều phối công việc tiếp theo của nó.
Sự tinh tế của kỹ thuật điều khiển
Nếu các đồng nghiệp của tôi sẽ nói về dịch vụ trong một bài đăng khác, thì trong bài viết này, chúng tôi sẽ tiết lộ những điểm phức tạp của việc phát triển trình điều khiển. Trình điều khiển bộ lọc mini đã được phát triển có hai chế độ vận hành - khi hệ thống khởi động ở chế độ bình thường và khi hệ thống vừa gặp lỗi và đang được khôi phục. Trước khi tải các thư viện và ứng dụng của người dùng, cũng như dịch vụ của chúng tôi, trình điều khiển sẽ hoạt động như nhau. Anh ta không biết hệ thống hiện đang ở trạng thái nào. Kết quả là mọi thao tác tạo, đọc và ghi đều được ghi lại và tất cả siêu dữ liệu đều được ghi lại. Và khi dịch vụ trực tuyến, tài xế sẽ cung cấp thông tin này cho dịch vụ.
Trong trường hợp khởi động bình thường, dịch vụ sẽ gửi tín hiệu “Thư giãn” đến trình điều khiển để tài xế “thư giãn” và ngừng ghi lại tất cả dữ liệu một cách cẩn thận. Trong trường hợp này, trình điều khiển chuyển sang chỉ ghi nhật ký các thay đổi trên đĩa và báo cáo chúng cho dịch vụ, dịch vụ này sử dụng các công cụ Acronis khác để duy trì bản sao lưu đĩa ở trạng thái cập nhật nhất trên phương tiện do người dùng chỉ định. Đây có thể là sao lưu đám mây, từ xa, dần dần hoặc hàng đêm.
Nếu chế độ khôi phục được bật, dịch vụ sẽ thông báo cho trình điều khiển rằng nó cần hoạt động ở chế độ “Phục hồi”. Hệ thống vừa mới khôi phục sau sự cố và ngay khi đưa ra yêu cầu mở tệp trên đĩa, bộ lọc mini phải chặn thao tác này, tự thực hiện yêu cầu này, kiểm tra xem tệp đó có tồn tại trên đĩa hay không và liệu nó có thể được mở.
Nếu thiếu tệp, bộ lọc mini sẽ truyền thông tin này đến dịch vụ, điều này làm tăng mức độ ưu tiên khôi phục tệp (trong suốt thời gian này, quá trình khôi phục đang diễn ra ở chế độ nền). Hóa ra tập tin này chỉ đơn giản là nhảy về đầu hàng đợi. Sau đó, chính dịch vụ (hoặc các phương tiện Acronis khác) sẽ khôi phục tệp này và thông báo cho trình điều khiển rằng mọi thứ đều ổn, bây giờ hệ điều hành có thể truy cập vào nó và trình điều khiển “giải phóng” yêu cầu ban đầu, từ hệ thống đến đĩa.
Nếu không thể khôi phục, dịch vụ sẽ thông báo cho trình điều khiển rằng tệp không có trong bản sao lưu. Trình điều khiển bộ lọc mini của chúng tôi chỉ cần chuyển yêu cầu hệ thống đi xa hơn và người yêu cầu ban đầu (chính hệ điều hành hoặc ứng dụng) sẽ nhận được lỗi “không tìm thấy tệp”. Tuy nhiên, điều này khá bình thường nếu tập tin thực sự không có trên đĩa và trong bản sao lưu.
Tất nhiên, hệ điều hành sẽ hoạt động chậm hơn nhiều vì việc đọc bất kỳ tệp hoặc thư viện nào đều diễn ra theo nhiều giai đoạn, có thể có quyền truy cập vào các tài nguyên từ xa. Nhưng người dùng có thể quay lại làm việc sớm nhất có thể trong khi quá trình phục hồi vẫn đang diễn ra.
Cần thấp hơn, thậm chí thấp hơn...
Nguyên mẫu đã chứng minh được chức năng của nó. Nhưng chúng tôi cũng nhận thấy cần phải tiếp tục vì một số trường hợp vẫn còn bế tắc. Ví dụ: hệ điều hành có thể yêu cầu nhiều thư viện khác nhau trong một số luồng, điều này dẫn đến việc dịch vụ của chúng tôi tự lặp lại.
Vấn đề tôi hiện đang giải quyết là tăng tốc độ Active Restore và tăng mức độ bảo mật hệ thống. Giả sử hệ thống không cần toàn bộ tệp mà chỉ cần một phần của nó. Với mục đích này, một trình điều khiển khác đã được phát triển - trình điều khiển bộ lọc đĩa. Nó không còn hoạt động ở cấp độ tệp nữa mà ở cấp độ khối. Nguyên lý hoạt động tương tự: ở chế độ hoạt động bình thường, trình điều khiển chỉ cần ghi lại các khối đã thay đổi trên đĩa và ở chế độ khôi phục, nó sẽ cố gắng tự đọc khối đó và nếu không thành công, hãy yêu cầu dịch vụ tăng mức độ ưu tiên. Tuy nhiên, tất cả các phần khác của hệ thống vẫn giữ nguyên. Ví dụ: một dịch vụ cấp hệ điều hành thậm chí không nghi ngờ rằng nó đang được yêu cầu liên lạc với một trình điều khiển khác, vì nhiệm vụ chính là cung cấp cho hệ điều hành chính xác dữ liệu cần thiết để hoạt động. Lĩnh vực này đòi hỏi những cải tiến đáng kể, nếu chỉ vì dịch vụ chưa biết cách suy nghĩ ở cấp khối.
Следующим шагом я решил запустить драйвер глубже и раньше, опустившись на уровень UEFI драйверов и Native Windows приложений вместо сервиса. Для этого был разработан (или DXE драйвер), который стартует и умирает еще до старта ОС. Но “историю” UEFI драйверов, подробности о сборке и установке, а также специфике Windows Native приложений, мы рассмотрим в следующем посте. Так что подписывайтесь на наш блог, а я пока подготовлю рассказ о следующем этапе работ. Буду рад вашим комментариям и советам.
Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. , xin vui lòng.
Bạn đã bao giờ gặp phải tình huống mà quá trình phục hồi mất một thời gian rất dài:
65.1%Có28
23.2%10
11.6%Chưa nghĩ tới chuyện đó5
43 người dùng bình chọn. 3 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com
