Mencadangkan data penting adalah hal yang baik. Namun bagaimana jika pekerjaan perlu segera dilanjutkan, dan setiap menitnya berarti? Kami di Acronis memutuskan untuk memeriksa seberapa mungkin menyelesaikan masalah memulai sistem secepat mungkin. Dan ini adalah postingan pertama dalam seri Pemulihan Aktif, di mana saya akan memberi tahu Anda bagaimana kami memulai proyek bersama dengan Universitas Innopolis, solusi apa yang kami temukan, dan apa yang sedang kami kerjakan hari ini. Detailnya sedang dipotong.
Halo! Nama saya Daulet Tumbayev, dan hari ini saya ingin berbagi dengan Anda pengalaman saya dalam mengembangkan sistem yang mempercepat pemulihan bencana. Untuk membicarakan keseluruhan jalur pengembangan proyek, mari kita mulai dari jauh. Saat ini saya bekerja di Acronis, namun saya juga lulusan Universitas Innopolis, tempat saya menyelesaikan program Magister Manajemen Pengembangan Perangkat Lunak (dikenal sebagai MSIT-SE). Innopolis adalah universitas muda, dan kurikulumnya bahkan lebih muda lagi. Tapi itu dibangun berdasarkan kurikulum Universitas Carnegie Mellon, yang karyanya mencakup topik seperti proyek industri.
Tujuan dari proyek industri adalah untuk membenamkan siswa dalam pengembangan nyata dan mengkonsolidasikan pengetahuan yang diperoleh dalam praktik. Untuk melakukan hal ini, universitas bekerja sama dengan perusahaan seperti Yandex, Acronis, MTC dan puluhan lainnya (total, pada 2018, universitas memiliki 144 mitra). Dalam kerjasama, perusahaan menawarkan wilayah kerjanya kepada universitas, dan mahasiswa memilih salah satu proyek yang lebih dekat dengan minat dan tingkat pelatihan mereka. Secara harfiah dua tahun yang lalu saya masih “berada di balik barikade” dan bekerja sebagai mahasiswa di proyek Acronis lainnya. Namun kali ini saya menjadi konsultan teknis untuk mahasiswa di pihak perusahaan dan mengusulkan proyek Active Restore ke Innopolis. Ide Active Restore dirumuskan oleh tim Kernel di Acronis, tetapi pengembangan solusinya dimulai bersama dengan Innopolis University.
Pemulihan Aktif – mengapa diperlukan?
Secara tradisional, pemulihan bencana bekerja berdasarkan skema standar. Setelah ada masalah dengan komputer Anda, buka antarmuka web beberapa sistem cadangan, misalnya, Acronis True Image, dan klik tombol besar “pulihkan”. Selanjutnya Anda perlu menunggu N menit, dan baru setelah itu Anda dapat terus bekerja.
Masalahnya adalah angka N ini, juga dikenal sebagai RTO (tujuan waktu pemulihan), waktu pemulihan yang diizinkan, bisa sangat mengesankan, tergantung pada kecepatan koneksi (jika pemulihan dilakukan dari cloud), ukuran hard drive mesin Anda. , dan sejumlah faktor lainnya. Apakah mungkin untuk menguranginya? Ya, bisa, karena untuk melanjutkan pekerjaan Anda tidak selalu memerlukan disk komputer yang lengkap. Foto dan video yang sama tidak mempengaruhi fungsionalitas perangkat dengan cara apa pun dan nantinya dapat dilihat di latar belakang.
Dibutuhkan supir...
Sistem operasi mengharapkan untuk memulai dengan disk yang sepenuhnya siap. Oleh karena itu Windows Melakukan serangkaian pemeriksaan integritas disk. Sistem tidak akan mengizinkan startup normal jika beberapa file yang diharapkan OS untuk ditemukan hilang atau rusak. Untuk mengatasi masalah ini, kami memutuskan untuk menempatkan apa yang disebut file pengarah (redirector files) pada disk. File-file ini menggantikan file yang hilang atau rusak, tetapi pada dasarnya adalah file dummy. Membuat pengarah ini sangat mudah, karena sebenarnya tidak berisi konten apa pun.
Restorasi lebih lanjut terjadi sebagai berikut. Melalui proses latar belakang, bersamaan dengan pengoperasian sistem operasi, “boneka” diisi dengan data. Proses pemulihan latar belakang memperhitungkan beban disk dan tidak melebihi batas yang ditetapkan. Namun, pengguna atau sistem operasi itu sendiri mungkin tiba-tiba membutuhkan file yang belum ada. Di sinilah mode pemulihan kedua berperan. Prioritas file yang diminta dinaikkan ke maksimum, dan proses pemulihan segera memuat file ke disk. Sistem operasi menerima file yang diperlukan, meskipun dengan sedikit penundaan.
Seperti inilah gambaran idealnya. Namun, di dunia nyata, ada banyak sekali kendala dan potensi kebuntuan. Bersama dengan mahasiswa master Innopolis, kami memutuskan untuk mengeksplorasi skenario pemulihan ini, mengevaluasi kemajuan dalam RTO, dan memahami apakah pendekatan seperti itu layak dilakukan? Lagi pula, solusi seperti itu belum ada di pasaran pada saat itu.
Dan jika saya memutuskan untuk memberikan komponen layanan kepada orang-orang dari Innopolis, maka pekerjaan di dalam Acronis dimulai Tim tersebut menangani hal ini. Windows Inti (kernel). Rencananya adalah sebagai berikut:
- Luncurkan driver pada tahap awal startup OS,
- Selama bekerja, kapan akan benar-benar siap, unduh layanannya
- Layanan memproses permintaan pengemudi dan mengoordinasikan pekerjaan selanjutnya.
Seluk-beluk rekayasa pengemudi
Jika rekan-rekan saya akan membicarakan layanan ini di postingan lain, maka pada teks kali ini kami akan mengungkap seluk-beluk pengembangan driver. Driver filter mini yang sudah dikembangkan memiliki dua mode pengoperasian - saat sistem dimulai dalam mode normal, dan saat sistem baru saja mengalami kegagalan dan sedang dipulihkan. Sebelum memuat perpustakaan pengguna dan aplikasi, dan oleh karena itu layanan kami, driver berperilaku sama. Dia tidak tahu di kondisi mana sistem saat ini berada. Hasilnya, setiap pembuatan, pembacaan, dan penulisan dicatat, dan semua metadata dicatat. Dan ketika layanan sedang online, pengemudi memberikan informasi ini kepada layanan tersebut.
Dalam kasus start normal, layanan mengirimkan sinyal "Santai" kepada pengemudi sehingga "santai" dan berhenti mencatat semua data dengan cermat. Dalam hal ini, driver beralih ke hanya mencatat perubahan pada disk dan melaporkannya ke layanan, yang, dengan menggunakan alat Acronis lainnya, menjaga cadangan disk dalam kondisi terkini pada media yang ditentukan oleh pengguna. Ini bisa berupa pencadangan cloud, jarak jauh, bertahap, atau setiap malam.
Jika mode pemulihan diaktifkan, layanan memberi tahu pengemudi bahwa ia perlu bekerja dalam mode “Pemulihan”. Sistem baru saja pulih dari kerusakan, dan segera setelah membuat permintaan untuk membuka file di disk, filter mini harus mencegat operasi ini, membuat permintaan ini sendiri, memeriksa apakah file tersebut ada di disk dan apakah itu bisa dibuka.
Jika ada file yang hilang, filter mini mengirimkan informasi ini ke layanan, yang meningkatkan prioritas pemulihan file (selama ini, pemulihan terjadi di latar belakang). Ternyata file ini melompat begitu saja ke awal antrian. Setelah ini, layanan itu sendiri (atau sarana Acronis lainnya) memulihkan file ini dan memberi tahu pengemudi 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 file tersebut tidak ada dalam cadangan. Driver filter mini kami meneruskan permintaan sistem lebih lanjut dan pemohon asli (OS itu sendiri atau aplikasi) menerima kesalahan "file tidak ditemukan". Namun, hal 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 perpustakaan apa pun terjadi dalam beberapa tahap, mungkin dengan akses ke sumber daya jarak jauh. Namun pengguna dapat kembali bekerja secepatnya selama pemulihan masih berlangsung.
Perlu lebih rendah, bahkan lebih rendah...
Prototipe telah membuktikan fungsinya. Namun kami juga merasa perlu untuk melanjutkan karena dalam beberapa kasus masih terdapat kebuntuan. Misalnya, sistem operasi mungkin meminta berbagai perpustakaan di beberapa thread, yang menyebabkan layanan kami mengulang kembali dirinya sendiri.
Masalah yang sedang saya kerjakan adalah meningkatkan kecepatan Active Restore dan meningkatkan tingkat keamanan sistem. Katakanlah sistem tidak membutuhkan seluruh file, tetapi hanya sebagian saja. Untuk tujuan ini, driver lain dikembangkan - driver filter disk. Ini tidak lagi berfungsi pada tingkat file, tetapi pada tingkat blok. Prinsip operasinya serupa: dalam mode operasi normal, driver hanya mencatat blok yang diubah pada disk, dan dalam mode pemulihan, ia mencoba membaca blok itu sendiri, dan jika tidak berhasil, meminta layanan untuk meningkatkan prioritas. Namun, semua bagian lain dari sistem tetap sama. Misalnya, layanan tingkat OS bahkan tidak curiga bahwa ia diminta untuk berkomunikasi dengan driver lain, karena tugas utamanya adalah menyediakan data yang diperlukan OS untuk pengoperasiannya. Area ini memerlukan perbaikan yang signifikan, hanya karena layanan belum mampu berpikir di tingkat blok.
Langkah selanjutnya yang saya ambil adalah menjalankan driver lebih dalam dan lebih awal, hingga ke level driver UEFI dan Native. Windows Aplikasi, bukan layanan. Untuk tujuan ini, aplikasi tersebut dikembangkan. (atau driver DXE), yang mulai dan berhenti bahkan sebelum OS dimulai. Tetapi "sejarah" driver UEFI, detail tentang perakitan dan instalasi, dan spesifikasinya Windows Kami akan membahas aplikasi native di postingan berikutnya. Jadi, berlanggananlah blog kami sementara saya menyiapkan cerita tentang tahap selanjutnya dari pekerjaan kami. Saya ingin sekali mendengar komentar dan saran Anda.
Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. , silakan.
Pernahkah Anda mengalami situasi di mana pemulihan memerlukan waktu yang sangat lama:
65.1%Ya28
23.2%No10
11.6%Tidak memikirkannya5
43 pengguna memilih. 3 pengguna abstain.
Sumber: www.habr.com
