Pemulihan Aktif: Bolehkah pemulihan bencana berlaku lebih cepat? Lebih cepat?

Menyandarkan data penting adalah perkara yang baik. Tetapi bagaimana jika kerja perlu diteruskan dengan segera, dan setiap minit adalah penting? Kami di Acronis memutuskan untuk menyemak bagaimana mungkin untuk menyelesaikan masalah memulakan sistem secepat mungkin. Dan ini adalah siaran pertama dalam siri Pemulihan Aktif, di mana saya akan memberitahu anda bagaimana kami memulakan projek bersama-sama dengan Universiti Innopolis, penyelesaian yang kami temui dan perkara yang kami usahakan hari ini. Butiran ada di bawah potongan.

hello! Nama saya Daulet Tumbayev, dan hari ini saya ingin berkongsi dengan anda pengalaman saya dalam membangunkan sistem yang mempercepatkan pemulihan bencana. Untuk bercakap tentang keseluruhan laluan pembangunan projek, mari kita mulakan sedikit dari jauh. Saya kini bekerja di Acronis, tetapi saya juga lulusan Universiti Innopolis, di mana saya menamatkan program Sarjana dalam Pengurusan Pembangunan Perisian (dikenali sebagai MSIT-SE). Innopolis adalah universiti muda, dan kurikulumnya lebih muda. Tetapi ia dibina berdasarkan kurikulum Universiti Carnegie Mellon, yang kerjanya merangkumi topik seperti projek perindustrian.

Tujuan projek perindustrian adalah untuk membenamkan pelajar dalam pembangunan sebenar dan menyatukan pengetahuan yang diperoleh dalam amalan. Untuk melakukan ini, universiti bekerjasama dengan syarikat seperti Yandex, Acronis, MTC dan berpuluh-puluh yang lain (secara keseluruhan, sehingga 2018, universiti itu mempunyai 144 rakan kongsi). Dalam perjalanan kerjasama, syarikat menawarkan kawasan kerja mereka kepada universiti, dan pelajar memilih salah satu projek yang lebih dekat dengan minat dan tahap latihan mereka. Secara harfiah dua tahun lalu saya masih "di seberang penghadang" dan bekerja sebagai pelajar di projek Acronis yang lain. Tetapi kali ini saya menjadi perunding teknikal untuk pelajar di pihak syarikat dan mencadangkan projek Pemulihan Aktif kepada Innopolis. Idea Pemulihan Aktif telah dirumuskan oleh pasukan Kernel di Acronis, tetapi pembangunan penyelesaian itu bermula bersama-sama dengan Universiti Innopolis.

Pemulihan Aktif – mengapa ia diperlukan?

Secara tradisinya, pemulihan bencana berfungsi mengikut skema standard. Selepas masalah dengan komputer anda, anda pergi ke antara muka web beberapa sistem sandaran, contohnya, Acronis True Image, dan klik butang "pulihkan" yang besar. Seterusnya anda perlu menunggu N minit, dan hanya selepas itu anda boleh terus bekerja.

Masalahnya ialah nombor N ini, juga dikenali sebagai RTO (objektif masa pemulihan), masa pemulihan yang dibenarkan, boleh sangat mengagumkan, yang bergantung pada kelajuan sambungan (jika pemulihan daripada awan), saiz cakera keras mesin anda , dan beberapa faktor lain. Adakah mungkin untuk mengurangkannya? Ya, anda boleh, kerana untuk menyambung kerja anda tidak selalu memerlukan cakera komputer penuh. Foto dan video yang sama tidak menjejaskan kefungsian peranti dalam apa jua cara dan boleh ditarik ke atas kemudian di latar belakang.

Pemandu diperlukan...

Sistem pengendalian menjangkakan untuk bermula dengan cakera sedia sepenuhnya. Oleh itu, Windows melakukan satu siri pemeriksaan untuk memeriksa integriti cakera. Sistem tidak akan membenarkan permulaan biasa jika beberapa fail yang OS jangkakan untuk ditemui hilang atau rosak. Untuk menyelesaikan masalah ini, diputuskan untuk meletakkan pada cakera apa yang dipanggil fail pengarah semula yang kami buat, yang menggantikan fail yang hilang atau rosak, tetapi sebenarnya adalah tiruan. Ia tidak mengambil masa yang lama untuk mencipta pengarah semula sedemikian, kerana mereka sebenarnya tidak mempunyai sebarang kandungan.

Pemulihan selanjutnya berlaku seperti berikut. Dengan proses latar belakang, selari dengan operasi sistem pengendalian, "dummies" diisi dengan data. Proses pemulihan latar belakang mengambil kira beban cakera dan tidak melebihi had yang ditetapkan. Walau bagaimanapun, pengguna atau sistem pengendalian itu sendiri mungkin tiba-tiba memerlukan fail yang belum wujud. Di sinilah mod pemulihan kedua dimainkan. Keutamaan fail yang diminta dinaikkan kepada maksimum, dan proses pemulihan segera memuatkan fail ke cakera. Sistem pengendalian menerima fail yang diperlukan, walaupun dengan sedikit kelewatan.

Inilah rupa gambar yang ideal. Walau bagaimanapun, dalam dunia nyata, terdapat sejumlah besar perangkap dan potensi kebuntuan. Bersama pelajar sarjana Innopolis, kami memutuskan untuk meneroka senario pemulihan ini, menilai keuntungan dalam RTO dan memahami sama ada pendekatan sedemikian boleh dilaksanakan? Lagipun, tiada penyelesaian sedemikian di pasaran pada masa itu.

Dan jika saya memutuskan untuk mengusahakan komponen perkhidmatan kepada lelaki dari Innopolis, maka dalam Acronis kerja bermula penapis mini oleh pemacu sistem fail. Ini dilakukan oleh pasukan Windows Kernel. Rancangannya adalah seperti ini:

• Lancarkan pemacu pada peringkat awal permulaan OS,
• Semasa bekerja, apabila ruang pengguna akan siap sepenuhnya, muat turun perkhidmatan
• Perkhidmatan memproses permintaan pemandu dan menyelaraskan kerja selanjutnya.

Kehalusan kejuruteraan pemandu

Jika rakan sekerja saya akan bercakap tentang perkhidmatan dalam jawatan lain, maka dalam teks ini kami akan mendedahkan selok-belok pembangunan pemandu. Pemacu penapis mini yang telah dibangunkan mempunyai dua mod operasi - apabila sistem dimulakan dalam mod biasa, dan apabila sistem baru sahaja mengalami kegagalan dan sedang dipulihkan. Sebelum memuatkan perpustakaan dan aplikasi pengguna, dan oleh itu perkhidmatan kami, pemandu berkelakuan sama. Dia tidak tahu di negeri mana sistem itu berada sekarang. Akibatnya, setiap ciptaan, baca dan tulis direkodkan dan semua metadata direkodkan. Dan apabila perkhidmatan dalam talian, pemandu memberikan maklumat ini kepada perkhidmatan tersebut.

Dalam kes permulaan biasa, perkhidmatan menghantar isyarat "Relax" kepada pemandu supaya ia "berehat" dan berhenti mengelog semua data dengan teliti. Dalam kes ini, pemacu beralih kepada mengelog hanya perubahan pada cakera dan melaporkannya kepada perkhidmatan, yang, menggunakan alat Acronis lain, mengekalkan sandaran cakera dalam keadaan paling terkini pada media yang ditentukan oleh pengguna. Ini boleh menjadi sandaran awan, jauh, beransur-ansur atau setiap malam.

Jika mod pemulihan didayakan, perkhidmatan memberitahu pemandu bahawa ia perlu berfungsi dalam mod "Pemulihan". Sistem baru sahaja pulih daripada ranap sistem, dan sebaik sahaja ia membuat permintaan untuk membuka fail pada cakera, penapis mini mesti memintas operasi ini, membuat permintaan ini sendiri, menyemak sama ada fail sedemikian wujud pada cakera dan sama ada ia boleh dibuka.

Jika fail tiada, penapis mini menghantar maklumat ini kepada perkhidmatan, yang meningkatkan keutamaan pemulihan fail (selama ini, pemulihan sedang berlaku di latar belakang). Ternyata fail ini hanya melompat ke permulaan baris gilir. Selepas ini, perkhidmatan itu sendiri (atau cara Acronis lain) memulihkan fail ini dan memberitahu pemandu bahawa semuanya ok, kini sistem pengendalian boleh mengaksesnya dan pemandu "melepaskan" permintaan asal, dari sistem ke cakera.

Jika pemulihan adalah mustahil, perkhidmatan memberitahu pemandu bahawa fail itu tiada dalam sandaran. Pemacu penapis mini kami hanya meneruskan permintaan sistem dan peminta asal (OS itu sendiri atau aplikasi) menerima ralat "fail tidak ditemui". Walau bagaimanapun, ini adalah perkara biasa jika fail itu benar-benar tiada pada cakera dan dalam sandaran.

Sudah tentu, sistem pengendalian akan berfungsi dengan lebih perlahan, kerana membaca mana-mana fail atau perpustakaan berlaku dalam beberapa peringkat, mungkin dengan akses kepada sumber jauh. Tetapi pengguna boleh kembali bekerja secepat mungkin semasa pemulihan masih berlaku.

Perlu lebih rendah, malah lebih rendah...

Prototaip telah membuktikan fungsinya. Tetapi kami juga mendapati keperluan untuk meneruskan kerana dalam beberapa kes masih terdapat kebuntuan. Sebagai contoh, sistem pengendalian boleh meminta pelbagai pustaka dalam beberapa utas, yang membawa kepada perkhidmatan kami bergelung semula pada dirinya sendiri.

Masalah yang sedang saya usahakan ialah meningkatkan kelajuan Pemulihan Aktif dan meningkatkan tahap keselamatan sistem. Katakan sistem tidak memerlukan keseluruhan fail, tetapi hanya sebahagian daripadanya. Untuk tujuan ini, pemacu lain telah dibangunkan - pemacu penapis cakera. Ia tidak lagi berfungsi pada peringkat fail, tetapi pada peringkat blok. Prinsip operasi adalah serupa: dalam mod operasi biasa, pemandu hanya log blok yang diubah pada cakera, dan dalam mod pemulihan, ia cuba membaca blok itu sendiri, dan jika tidak berjaya, meminta perkhidmatan untuk meningkatkan keutamaan. Walau bagaimanapun, semua bahagian lain sistem tetap sama. Sebagai contoh, perkhidmatan peringkat OS tidak mengesyaki bahawa ia diminta untuk berkomunikasi dengan pemandu lain, kerana tugas utama adalah untuk menyediakan OS dengan tepat data yang diperlukan untuk operasi. Kawasan ini memerlukan penambahbaikan yang ketara, jika hanya kerana perkhidmatan itu belum tahu bagaimana untuk berfikir di peringkat blok.

Langkah seterusnya saya memutuskan untuk melancarkan pemacu lebih mendalam dan lebih awal, turun ke tahap pemacu UEFI dan aplikasi Windows Asli dan bukannya perkhidmatan. Untuk tujuan ini ia dibangunkan pemacu but UEFI (atau pemacu DXE), yang bermula dan mati walaupun sebelum OS bermula. Tetapi kita akan melihat "sejarah" pemacu UEFI, butiran mengenai pemasangan dan pemasangan, serta spesifikasi aplikasi Windows Native dalam siaran seterusnya. Jadi langgan blog kami, dan sementara itu saya akan menyediakan cerita tentang peringkat kerja seterusnya. Saya akan gembira melihat komen dan nasihat anda.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Pernahkah anda mengalami situasi di mana pemulihan mengambil masa yang sangat lama:

• 65.1% Ya28

• 23.2% No10

• 11.6% Tidak memikirkannya5

43 pengguna mengundi. 3 pengguna berpantang.

Sumber: www.habr.com