Mencadangkan data penting itu baik. Tetapi bagaimana jika pekerjaan itu perlu dilanjutkan segera, dan setiap menit diperhitungkan? Kami di Acronis memutuskan untuk memeriksa seberapa mungkin menyelesaikan tugas memulai sistem secepat mungkin. Dan ini adalah posting pertama dalam seri Active Restore di mana saya akan memberi tahu Anda bagaimana kami memulai proyek dengan Innopolis University, solusi apa yang kami temukan, dan apa yang kami kerjakan hari ini. Detail - di bawah potongan.
Hai Nama saya Daulet Tumbaev, dan hari ini saya ingin berbagi dengan Anda pengalaman saya dalam mengembangkan sistem yang mempercepat pemulihan bencana. Untuk berbicara tentang seluruh jalur pengembangan proyek, mari kita mulai sedikit dari jauh. Saat ini saya bekerja di Acronis, tetapi saya juga lulusan Universitas Innopolis, yang saya lulus dalam Program Magister Manajemen Pengembangan Perangkat Lunak (dikenal sebagai MSIT-SE). Innopolis adalah universitas muda, dan kurikulumnya bahkan lebih muda. Tapi kemudian dibangun di atas kurikulum Universitas Carnegie Mellon (Universitas Carnegie Mellon), yang dalam pencapaiannya ada topik seperti proyek industri.
Tujuan dari proyek industri adalah untuk membenamkan siswa dalam pengembangan nyata dan mengkonsolidasikan pengetahuan yang diperoleh dalam praktik. Untuk ini, universitas bekerja sama dengan perusahaan seperti Yandex, Acronis, MTC dan banyak lainnya (secara total, universitas memiliki 144 mitra untuk 2018). Dalam rangka kerjasama, perusahaan menawarkan arahan kerja mereka ke universitas, dan siswa memilih salah satu proyek yang lebih dekat dengan mereka dalam minat dan tingkat pelatihan mereka. Hanya dua tahun yang lalu, saya masih "di sisi lain dari barikade" dan bekerja sebagai mahasiswa di proyek Acronis lainnya. Tapi kali ini, saya menjadi konsultan teknis untuk siswa dari perusahaan dan mengusulkan proyek Active Restore ke Innopolis. Gagasan Active Restore dirumuskan oleh tim Kernel di Acronis, tetapi pengembangan solusi dimulai dengan Universitas Innopolis.
Active Restore - mengapa ini diperlukan?
Secara tradisional, pemulihan bencana bekerja sesuai dengan skema standar. Setelah mengalami masalah dengan komputer, Anda pergi ke antarmuka web beberapa sistem cadangan, misalnya, Acronis True Image, dan klik tombol "restore" yang besar. Selanjutnya, Anda perlu menunggu N menit, dan hanya setelah itu Anda dapat terus bekerja.
Masalahnya adalah bahwa angka N ini, juga dikenal sebagai RTO (sasaran waktu pemulihan), waktu pemulihan yang diizinkan, bisa sangat mengesankan, yang tergantung pada kecepatan koneksi (jika pemulihan dari cloud terjadi), pada volume hard drive komputer Anda dan sejumlah faktor lainnya. Bisakah itu dikurangi? Ya, Anda bisa, karena untuk melanjutkan pekerjaan Anda tidak selalu memerlukan disk komputer lengkap. Foto dan video yang sama tidak memengaruhi fungsionalitas perangkat dan dapat ditarik kemudian di latar belakang.
Pengemudi dibutuhkan ...
Sistem operasi mengharapkan untuk memulai dengan disk yang sudah selesai. Oleh karena itu, Windows melakukan serangkaian pemeriksaan untuk integritas disk. Sistem tidak akan memungkinkan permulaan yang normal dengan tidak adanya atau kerusakan beberapa file yang diharapkan oleh OS. Untuk mengatasi masalah ini, diputuskan untuk meletakkan di disk apa yang disebut file redirector yang kami buat, yang menggantikan file yang hilang atau rusak, tetapi sebenarnya adalah boneka. Untuk membuat pengalihan seperti itu tidak lama, karena sebenarnya mereka tidak memiliki konten.
Pemulihan lebih lanjut terjadi sebagai berikut. Proses latar belakang, bersamaan dengan pengoperasian sistem operasi, “boneka” diisi dengan data. Proses pemulihan latar belakang memperhitungkan beban pada disk dan tidak melebihi batas yang ditentukan. Namun, pengguna atau sistem operasi itu sendiri mungkin tiba-tiba meminta file yang belum ada. Di sinilah mode pemulihan kedua berperan. Prioritas file yang diminta ditingkatkan ke maksimum, dan proses pemulihan segera mengunggah file ke disk. Sistem operasi menerima file yang diinginkan, walaupun dengan sedikit penundaan.
Ini terlihat seperti gambar yang sempurna. Namun, di dunia nyata, ada sejumlah besar jebakan dan potensi kebuntuan. Bersama dengan mahasiswa sarjana Innopolis, kami memutuskan untuk menyelidiki skenario pemulihan ini, mengevaluasi perolehan dalam RTO, dan memahami apakah pendekatan ini layak? Memang, keputusan seperti itu di pasar sama sekali tidak ada pada waktu itu.
Dan jika saya memutuskan untuk memberikan komponen layanan kepada orang-orang dari Innopolis, maka di dalam pekerjaan Acronis dimulai pada
driver sistem file mini-filter . Ini dilakukan oleh tim Kernel Windows. Rencananya adalah ini:
- Jalankan driver pada tahap awal memulai OS,
- Selama operasi, ketika ruang pengguna sepenuhnya siap, unduh layanan
- Layanan ini memproses permintaan pengemudi dan mengoordinasikan pekerjaan selanjutnya.
Seluk-beluk rekayasa pengemudi
Jika kolega saya akan berbicara tentang layanan di pos lain, maka dalam teks ini kami akan mengungkapkan seluk beluk pengembangan driver. Mini-filter driver yang sudah dikembangkan memiliki dua mode operasi - ketika sistem mulai dalam mode normal, dan ketika sistem baru saja mengalami kegagalan dan pemulihannya terjadi. Sebelum memuat pustaka pengguna dan aplikasi, dan karena itu layanan kami, driver berperilaku sama. Dia tidak tahu keadaan sistem saat ini. Akibatnya, setiap membuat, membaca dan menulis dicatat, semua meta-data dicatat. Dan ketika layanan online, pengemudi memberikan informasi ini ke layanan.
Dalam hal start normal, layanan mentransmisikan sinyal "Santai" ke pengemudi sehingga "santai" dan tidak lagi mencatat semua data dengan cermat. Dalam kasus ini, driver beralih ke pendataan hanya perubahan pada disk dan melaporkannya ke layanan, yang dengan bantuan alat Acronis lainnya mempertahankan cadangan disk dalam kondisi terbaru di media yang ditentukan pengguna. Ini bisa berupa cloud, remote, bertahap, atau cadangan malam.
Jika mode pemulihan diaktifkan, layanan memberi tahu pengemudi bahwa ia perlu bekerja dalam mode "Pemulihan". Sistem baru saja pulih setelah kegagalan, dan segera setelah memberikan permintaan untuk membuka file pada disk, mini-filter harus mencegat operasi ini, membuat permintaan ini sendiri, memeriksa apakah ada file pada disk dan apakah itu dapat dibuka.
Jika tidak ada file, filter mini mentransfer informasi ini ke layanan, yang meningkatkan prioritas pemulihan file (selama ini, pemulihan sedang berlangsung). Ternyata file ini baru saja melompat ke awal antrian. Setelah itu, layanan itu sendiri (atau oleh alat Acronis lainnya) mengembalikan file ini dan memberi tahu driver bahwa semuanya baik-baik saja, sekarang sistem operasi dapat mengaksesnya dan driver "melepaskan" permintaan asli, dari sistem ke disk.
Jika pemulihan tidak memungkinkan, layanan memberi tahu pengemudi bahwa tidak ada file di cadangan juga. Pengandar filter mini kami hanya melewatkan permintaan sistem lebih lanjut dan pemohon asli (OS itu sendiri atau aplikasi) menerima kesalahan "file tidak ditemukan". Namun, ini cukup normal jika file tersebut benar-benar tidak ada di disk dan di cadangan.
Tentu saja, sistem operasi akan bekerja lebih lambat, karena membaca file atau pustaka apa pun terjadi dalam beberapa tahap, dan mungkin dengan akses ke sumber daya jarak jauh. Tetapi kemudian pengguna dapat mulai bekerja sesegera mungkin saat pemulihan masih berlangsung.
Perlu lebih rendah, bahkan lebih rendah ...
Prototipe telah membuktikan nilainya. Tetapi kami juga menemukan kebutuhan untuk melanjutkan, karena dalam beberapa kasus kebuntuan masih terjadi. Misalnya, sistem operasi dapat meminta berbagai pustaka di beberapa utas, yang mengarah pada penutupan layanan kami.
Masalah yang saya kerjakan sekarang adalah meningkatkan kecepatan Active Restore dan meningkatkan tingkat keamanan sistem. Misalkan sistem tidak memerlukan seluruh file, hanya sebagian saja yang diperlukan. Untuk ini, driver lain dikembangkan - driver filter disk. Tidak lagi berfungsi pada file, tetapi pada level blok. Prinsip operasi serupa: dalam operasi normal, pengemudi hanya mencatat blok yang diubah pada disk, dan dalam mode pemulihan, ia mencoba membaca blok sendiri, jika terjadi kegagalan, ia meminta layanan untuk meningkatkan prioritas. Namun, semua bagian lain dari sistem tetap sama. Misalnya, layanan tingkat OS bahkan tidak curiga sedang ditawarkan untuk berkomunikasi dengan driver lain, karena tugas utamanya adalah menyediakan OS dengan data yang diperlukan untuk berfungsi. Arah ini memerlukan peningkatan yang signifikan, jika saja karena layanan masih tidak tahu bagaimana berpikir di tingkat blok.
Langkah selanjutnya, saya memutuskan untuk menjalankan driver lebih dalam dan lebih awal, turun ke level driver UEFI dan aplikasi Windows Asli daripada layanan. Untuk ini,
driver boot UEFI (atau driver DXE) dikembangkan, yang dimulai dan mati sebelum OS dimulai. Tapi "sejarah" driver UEFI, detail tentang perakitan dan instalasi, serta spesifik aplikasi Windows Native, kami akan pertimbangkan di posting berikutnya. Jadi berlangganan ke blog kami, dan untuk saat ini saya akan menyiapkan cerita tentang tahap kerja selanjutnya. Saya akan senang atas komentar dan saran Anda.