Sistem Pemantauan dan Pencegahan Kegagalan Pada Sistem Operasi Pemulihan Sendiri Osvari Arsalan1, Kanda Januar Miraswan2, Taufik Iqbal Ramdhani3 Sekolah Tinggi Elektro dan Informatika Institut Teknologi Bandung
[email protected] [email protected] [email protected]
Bandung, Indonesia Abstrak— Kebutuhan akan toleransi terhadap kegagalan adalah hal yang sangat dibutuhkan dalam sistem operasi. Sebisa mungkin sebuah sistem operasi dapat mengatasi kegagalan tanpa mengorbankan aplikasi dan data yang sedang digunakan oleh pengguna. Metode pemulihan konvensional melakukan restart untuk menghalau kegagalan yang terjadi sehingga tidak terjadi kerusakan yang lebih buruk pada sistem. Hal ini mengakibatkan aplikasi dan data pengguna yang disimpan di memori volatile akan hilang dan merugikan pengguna pada akhirnya. Metode yang lebih baik telah di teliti [1] untuk melakukan pemulihan sendiri dari kegagalan tanpa restart. Metode penanganan yang dilakukan seperti exception handling, code reloading, micro-rebooting, system service restart secara otomatis, pemulihan watchdog timer-based, serta komponen transaksional. Ide yang diajukan dalam tulisan ini adalah dengan menambahkan sistem pencatatan perubahan kondisi dan kegagalan yang terjadi serta penanganan yang dilakukan sebagai upaya pemantauan dan pencegahan terjadinya kegagalan yang sama pada sistem operasi. Kata kunci— sistem operasi, penyembuhan sendiri, pencegahan
I. PENDAHULUAN Kehandalan sistem operasi sangat dibutuhkan saat ini seiringan dengan semakin kompleksnya sistem computer dan aplikasi yang berkembang saat ini. Aplikasi dan data pengguna merupakan hal yang paling krusial untuk ditangani. Kegagalan atau kesalahan yang terjadi harus ditangani dengan baik sehingga pengguna tidak kehilangan datanya. Sistem operasi yang ada menampilkan pesan STOP (fatal system error) berupa layar biru kemudian melakukan restart untuk pemulihan [2] atau memanggil fungsi PANIC [3].Hal ini mengakibatkan data dan aplikasi yang tersimpan di memori volatile akan hilang. Sistem yang ada saat ini memiliki dua karakter yang membuatnya menjadi tidak handal dan tidak aman. Pertama, sistem operasi berukuran besar (dibangun dari jutaan baris kode). Kedua, sistem operasi sangat lemah terhadap isolasi kegagalan[6]. Dari riset yang telah dilakukan [8,9,10] didalam 1000 baris kode mengandung 6 sampai 16 baris kode yang mengakibatkan kegagalan. Sebagai contoh, Linux kernel
memiliki sekitar 2,5 juta baris kode program. Artinya sekitar 150.000 sampai 400.000 baris kode program berpotensi mengakibatkan kegagalan pada sistem. Faktanya, tidak ada seorangpun yang mampu memahami keseluruhan baris program dimana sebuah sistem operasi memiliki jumlah baris yang banyak tersebut. Disisi lain, sistem operasi juga memiliki ratusan bahkan jutaan prosedur yang saling berhubungan satu sama lain sebagai sebuah program biner yang berjalan pada mode kernel. Proses dimana banyak prosedur meruju ke banyak prosedur lainnya akan berpotensi mengubah atau menimpa struktur data kunci dari komponen lain yang tidak berhubungan. Hasilnya, kerusakan pada sistem akan sulit untuk dideteksi dan ditangani. Ditambah lagi jika serangan malware, virus atau worm yang menginfeksi suatu prosedur kernel, tentu akan semakin memperburuk kerusakan pada sistem. Pengaturan yang baik terhadap sistem operasi harus dilakukan, namun pengaturan manual dengan banyak campur tangan manusia tentu sulit untuk dilakukan. Untuk itu penelitian yang telah dilakukan [1,2,5,6,7] merancang teknikteknik seperti exception handling, code reloading, microrebooting, system service restart secara otomatis, pemulihan watchdog timer-based, serta komponen transaksional yang mampu dilakukan oleh sistem operasi tanpa harus restart untuk melakukan pemulihan. Usulan kami dalam penelitian ini adalah mengajukan sebuah ide untuk membentuk suatu divisi yang berbasis perangkat lunak untuk melakukan pencatatan perubahan kondisi, kegagalan yang terjadi beserta penanganan yang dilakukan sistem operasi dan hasil dari penanganan tersebut. Sehingga untuk selanjutnya kegagalan yang fatal akibat kesalahan penanganan atau perubahan kondisi dapat disinyalir lebih dini. II. SISTEM OPERASI PEMULIHAN SENDIRI (SELF-HEALING OPERATING SYSTEM) Dalam tulisan ini akan dibahas mengenai rancangan system pemulihan sendiri pada system operasi choices [1,2]. Rancangan sistem operasi yang dapat memulihkan dirinya sendiri memiliki 2 bagian, yaitu bagian pendeteksian dan bagian penanganan, seperti terlihat pada gambar 1.
Gambar 1. Teknik dalam sistem operasi pemulihan sendiri A. Teknik Pendeteksian Kegagalan
3) Code Checksums
1) Proteksi Memori Virtual
Pengecekan kode secara periodik dilakukan sebagai upaya untuk mensinyalir adanya kode yang dapat menimbulkan Banyaknya prosedur yang saling berhubungan yang dapat kerusakan pada sistem. mengakses komponen driver pada kernel level akan menimbulkan kerusakan yang sulit ditangani. Untuk 4) Watchdog timers mengantisipasi kerusakan perlu adanya proteksi terhadap Watchdog timer merupakan perangkat eksternal yang komponen driver. Penelitian yang telah dilakukan [1] berhubungan langsung dengan pin reset prosesor ditujukan merancang proteksi pada driver dengan mengenkapsulasinya untuk mensinyalir adanya proses yang tidak perlu atau menjadi komponen berbasis memori virtual. Selain itu perulangan tak-berhingga. Watchdog timer akan terus memindahkannya ke layer aplikasi dan meletakkan sebuah menghitung selama sistem operasi berjalan. objek wrapper yang menyediakan akses read-only terhadap komponen tertentu. Rancangan seperti ini akan menjaga struktur data driver tidak akan berubah karena akses untuk B. Teknik Pemulihan menulis tidak disediakan. 1) Code reloading
Gambar 2. Rancangan isolasi komponen 2) Processor Exceptions Biasanya exception handling digunakan untuk menangkap kegagalan pada kode program untuk aplikasi. Namun, eksplorasi lebih lanjut telah dilakukan [11] untuk mensinyalir kegagalan pada kernel level dengan memanfaatkan exception pada prosesor. Kemudian dirancang exception berbasis bahasa pemrograman C++ untuk memetakan exception pada prosesor tersebut sehingga didapatlah rancangan exception yang berbasis bahasa pemrograman C++ yang mampu digunakan untuk mensinyalir kegagalan hingga pada kernel level.
Gambar 3. Pola kerja code reloading Kegagalan akibat kesalahan kode program terdiri dari 2 jenis yaitu kesalahan sintaksis dan kesalahan semantik. Kesalahan sintaksis dapat berupa salahnya input parameter yang diberikan pada saat pengkodean program dan kesalahan semantik menghasilkan prilaku program yang tidak konsisten atau menghasilkan keluaran yang salah. Kegagalan akibat kode dapat memicu terjadinya instruksi yang tidak valid pada kode sistem dan mengakibatkan memori korupsi.
Strategi yang digunakan adalah dengan melakukan pengecekan kode dan hashing secara berkala. Ketika exception mendapati adanya kode yang berpotensi menghasilkan kesalahan, maka prosesor akan melemparnya ke error handler untuk di cek kode mana yang salah tersebut pada media penyimpanan yang stabil yang menyimpan salinan kode program. Setelah kode ditemukan, maka kode tersebut dimuat ulang untuk kemudian dieksekusi kembali. Hasil penelitian yang telah dilakukan [1] dengan memasukkan 100 kegagalan memori karena kesalahan kode menunjukkan 85 buah kesalahan telah diperbaiki oleh CRC yang melakukan pengecekan secara berkala, sehingga terhindar dari potensi kegagalan dimasa depan. 4 buah kegagalan mengakibatkan interupsi akibat instruksi yang tidak dikenali dan telah di perbaiki secara otomatis. Sisanya 11 kesalahan mengakibatkan kernel crash. Hal ini disebabkan karena kesalahan berlangsung sebelum periode pengecekan oleh CRC (setiap 5 detik). 2) Component micro-reboots Strategi code reloading hanya memperbaiki kegagalan akibat adanya instruksi prosesor yang tidak valid. Sedangkan pada component micro rebooting memperbaiki kesalahan pada struktur data kernel. Micro-reboot bekerja sama dengan komponen isolasi dan wrapper ketika exception menangkap adanya kegagalan karena struktur data kernel yang rusak. Micro-reboot menginisialisasi ulang komponen yang terpengaruh atau justru menghancurkannya dan menciptakannya kembali kemudian mengulang kembali permintaan terhadap komponen tersebut. 3) Watchdog reset handling
Beruntungnya, kita masih dapat membangun sistem operasi dan data pengguna meskipun prosesor telah di reset karena sebagian kondisi pada memori volatile masih tetap dijaga sehingga terhindar dari kehilangan data total. Pengujian yang telah dilakukan [1] dengan memasukkan driver yang berisi struktur data yang salah yang ditulis secara manual yang akan muncul sebagai proses kernel yang salah. Proses yang terjadi menghasilkan loop tak berhingga dan tidak dapat diinterupsi. Tanpa adanya watchdog timer kondisi sistem operasi akan hangs atau lock up. Proses lain yang dilakukan adalah dengan menjalankan proses dekompresi terhadap berkas yang dikompres. Dengan menghidupkan watchdog timer, kernel dipulihkan segera setelah prosesor melakukan reset dan proses dekompresi berlanjut hingga selesai dan menghasilkan data yang valid. Hasil pengujian keseluruhan terhadap watchdog timer rata-rata pemulihan akibat kesalahan sebesar 70%. 4) Transactional component Ketikan sebuah error disebabkan oleh sebuah exception pada saat operasi transaksional pada komponen, state pada komponen dapat di roll back dengan mengagalkan transaksi. Operasi tersebut kemudian dilakukan ulang. Pendekatan ini didesain sebagai konjungsi dari isolated component dengan tujuan untuk meminimalisir propagasi error. Manajemen transaksi dilakukan oleh wrapper, objek yang sama yang menyediakan isolasi. Wrapper menggagalkan transaksi dan melakukan rollback state pada komponen jika terdapat exception yang tidak dapat ditangani. Model fault yang dapat diselesaikan oleh pendekatan ini adalah arbitrary memory corruption dalam komponen OS yang dideteksi dan diberikan sinyal oleh exception sebelum sebuah transaksi paca komponen melakukan commit. 5) Restart layanan otomatis Kegagalan pada layanan sistem operasi dapat mengakibatkan sistem menjadi berhenti. Jika kegagalan seperti ini terjadi maka dapat dilakukan restart terhadap layanan yang bersangkutan dan dapat dipastikan proses pada sistem operasi akan berlanjut.
Untuk melakukan proses restart layanan otomatis dibuat sebuah proses pemantau untuk memutuskan proses yang rusak. Proses pemantau akan menunggu proses yang siap. Jika proses pemantau mensinyalir adanya proses yang mengalami Gambar 4. Pola kerja watchdog timer kerusakan seperti berhenti (halt) maka secara sederhana akan Pada kondisi baik, sistem operasi akan secara rutin mereset melakukan restart terhadap proses yang bersangkutan dan perhitungan timer. Namun, pada kondisi yang buruk sistem proses dapat dilanjutkan. tidak mampu melakukan reset dan timer memasuki masa timeNamun, restart sederhana tidak dapat dilakukan manakala out. Jika kondisi seperti ini terjadi makan watchdog timer akan memberi sinyal (menggigit) prosesor sehingga prosesor ada proses yang melakukan lock terhadap struktur data tertentu melakukan full-reboot. Namun, tentu saja full-reboot akan yang di-sharing. Untuk itu proses pemantau akan melakukan mengakibatkan aplikasi dan data pengguna pada memori pengecekan terhadap semua lock dan memaksanya untuk dibebaskan ketika layanan berhenti. volatile akan hilang.
Pengujian yang telah dilakukan [1] menghasilkan keberhasilan pemulihan sebesar 78.9% dari 1000 eksperimen penginjeksian kegagalan. Kegagalan pemulihan terjadi ketika exceptions terjadi selama pembaruan status menjadi struktur data yang kritis, hal ini mengakibatkan kegagalan yang tidak bisa diperbaiki.
Fitur yang dimiliki oleh sistem tambahan ini antara lain: 1.
Penyimpanan Sistem yang diusulkan akan melakukan penyimpanan informasi perubahan semua kondisi aplikasi, komponen, dan layanan yang berjalan di atas sistem operasi. Perubahan yang disimpan adalah 5 kondisi terakhir. Setiap perubahan state akan disimpan di media penyimpanan sementara (buffer) terlebih dahulu. Jika ada kondisi perubahan tertentu yang mengakibatkan kegagalan total maka aplikasi / komponen / layanan tersebut akan diberi label dan 5 kondisi terakhir nya akan disimpan secara permanen dimedia penyimpanan stabil (basis data). Jika sistem operasi akan di matikan, maka sistem sebelumnya akan melakukan penghapusan semua catatan yang disimpan didalam media penyimpanan sementara (buffer). Serta pengecekan terhadap penyimpanan stabil jika alokasi memori telah hampir penuh dan melakukan penghapusan terhadap catatan kegagalan yang telah lama tidak terjadi.
2.
Pemantauan Pemantauan hanya dilakukan terhadap aplikasi / komponen / layanan yang pernah mengalami kegagalan total dam telah tercatat didalam media basis data saja. Jika dalam pemantauan aplikasi / komponen / layanan yang dipantau mengindikasikan perubahan kondisi yang sama seperti yang ada didalam basis data, maka setelah perubahan ke-4 aplikasi / komponen / layanan tersebut akan langsung di restart sehingga tidak masuk ke fase kegagalan total seperti sebelumnya.
3.
Pemulihan Proses pemulihan akan dilakukan secara individu saja terhadap aplikasi / komponen / layanan yang mengindikasikan perubahan kondisi yang sama seperti yang ada didalam basis data.
6) Pemulihan proses secara individu Jika pemulihan secara transparan tidak memungkinkan, dan proses pemulihan itu sendiri mengalami error, state dari proses individual dapat disimpan pada penyimpanan yang stabil sebagai harapan terakhir. Setelah proses user disimpan, full reboot dapat dilakukan dan state dari proses dapat dikembalikan secara selektif pada komputer. Semua state pada OS diinisialisasi ulang setelah reboot, memungkinkan menghilangkan error sebelumnya. Teknik ini memungkinkan semua user state tidak hilang ketika error hanya mempengaruhi beberapa aplikasi ataupun state OS yang tidak ada hubungannya. Hal ini juga dapat digabungkan dengan filesystem snapshot untuk memastikan integritas file tidak berubah setelah pemulihan dengan melanjutkan menjalankan proses user yang memiliki error. Model fault yang dapat diselesaikan oleh pendekatan ini adalah arbitrary corruption dalam komponen OS yang tidak mempengaruhi user process state dan process recovery code. III. USULAN PADA PENELITIAN Strategi yang baik telah dirancang untuk mengatasi kegagalan pada sistem operasi tanpa melakukan full restart [1,2,5,6,7] namun pada akhirnya akan melakukan full restart juga jika terjadi kegagalan yang terjadi tanpa prediksi, atau justru perbaikan yang dilakukan malah menimbulkan kesalahan lainnya yang lebih fatal. Untuk itu kami mengusulkan ide seperti: 1) Tambahkan divisi yang berbasis perangkat lunak yang melakukan pencatatan terhadap kegagalan dan penanganan serta dampak yang terjadi, pencatatan juga terhadap beberapa perubahan kondisi terakhir dari driver dan kode program. Sehingga jika dikemudian waktu ditemukan gejala yang sama dapat disinyalir dan ditanggulangi lebih dini oleh sistem operasi. Namun penambahan divisi ini tentu akan mempengaruhi kinerja sistem, untuk itu buatlah switch sehingga pengguna dapat mengaktifkan dan menonaktifkan pencatatan. 2) Lakukan proses adaptasi pada strategi code reloading dengan mengevaluasi rata-rata prosentase terjadinya kegagalan sebelum pengecekan untuk menentukan interval waktu yang paling efektif untuk pengecekan dan hashing. A. Sistem Pemantau Kegagalan Meskipun perancangan sistem operasi yang diusulkan [1] telah baik, namun masih memungkinkan terjadinya pemulihan kegagalan dengan cara full-reboot. Untuk meminimalisir kondisi tersebut kami mengusulkan untuk membuat sebuah sistem error monitoring untuk mencegah agar tidak terjadi kegagalan yang fatal.
Sistem Pemantau Kegagalan merupakan divisi tambahan yang akan membantu sistem operasi lebih handal lagi dalam menanggapi kegagalan yang terjadi. Penambahan divisi tentu akan menambah berat kinerja sistem sehingga perlu dibuat aturan-aturan untuk meminimalisir penambahan beban kerja tersebut, antara lain: - Sistem Pemantau dirancang dengan memiliki fungsi aktif dan non-aktif, sehingga pengguna dapat dengan sadar melakukan aktifasi sistem pemantau jika diperlukan. - Pemantauan hanya dilakukan terhadap aplikasi / komponen / layanan yang pernah tercatat didalam basis data mengalami kegagalan total. - Perubahan kondisi yang disimpan hanya 5 perubahan terakhir saja. - Sistem secara berkala mengecek dan menghapus catatan kegagalan total yang tidak terjadi dalam waktu
yang lama jika basis data sistem telah mencapai kapasitas maksimum. Berikut arsitektur Sistem Operasi dengan penambahan divisi sistem pemantau kegagalan:
IV. KESIMPULAN Penelitian yang telah dilakukan menghasilkan rancangan sistem operasi yang efektif dalam memulihkan diri sendiri dari kerusakan dan kegagalan tanpa harus selalu melakukan fullrestart. Strategi seperti code reloading, component microreboot, penambahan perangkat eksternal watchdog timer, transactional component, dan restart layanan otomatis mampu menanggulangi sebagian besar kegagalan. Namun, masih memungkinkan terjadinya kegagalan yang fatal sehingga terpaksa harus dilakukan full-restart sistem. Penambahan divisi pencatatan perubahan kondisi dan penanganan terhadap kegagalan dapat menjadi solusi yang baik sebagai upaya untuk mensinyalir kemungkinan terjadi kegagalan yang fatal lebih dini dikemudian waktu. Mengatur fleksibilitas interval waktu pengecekan dan hashing berdasarkan rata-rata kegagalan yang terjadi sebelum waktu pengecekan pada strategi code reloading juga dapat dijadikan upaya untuk meningkatkan kemampuan pemulihan sendiri pada sistem operasi. PENGAKUAN Kami berterima kasih kepada seluruh pihak yang telah membantu memberikan banyak masukan. Khususnya kepada rekan-rekan magister informatika Institut Teknologi Bandung sebagai rekan diskusi dan pak Afwarman selaku dosen pembimbing mata kuliah sistem operasi lanjut. REFERENSI [1]
[2]
Gambar 5. Arsitektur Sistem Operasi dengan penambahan sistem pemantau kegagalan B. Modifikasi Strategi Code Reloading Strategi code reloading yang diimplementasikan pada penelitian sebelumnya [1] telah baik dalam menanggulangi sebagian besar kegagalan. Namun waktu pengecekan terhadap kode yang sedang dieksekusi terlalu rigit. Pengecekan dilakukan oleh CRC dalam inverval waktu 5 detik secara konstan, sedangkan kode dapat berubah kondisi dalam tempo waktu yang tidak konstan. Untuk itu modifikasi yang kami usulkan adalah dengan mencatat waktu perubahan kondisi yang terjadi pada kode secara berkala, sehingga dapat dievaluasi interval waktu yang paling efektif untuk melakukan pengecekan terhadap kode kemudian informasi ini dapat di atur ulang kedalam CRC sehingga strategi code reloading ini dapat lebih fleksibel dan handal dalam menanggulangi kegagalan yang terjadi akibat perubahan kode pada aplikasi yang sedang dieksekusi.
[3] [4] [5] [6] [7]
[8]
[9]
[10]
[11]
F. M. David, and R. H. Campbell. Building A Self-Healing Operating System, Third IEEE International Symposium on Dependable, Autonomic and Secure Computing. Columbia, MD, 2007. F. M. David, J. C. Carlyle, E. M. Chan, D. K. Raila, and R. H. Campbell. Exception Handling in the Choices Operating System, volume 4119 of Lecture Notes in Computer Science. Springer-Verlag Inc., New York, NY, USA, 2006. Blue Screen. support.microsoft.com/kb/q129845. Fungsi panic. http://www.unix.com/man-page/FreeBSD/9/panic/. A. S. Tanenbaum, J. N. Herder, and H. Bos. Can We Make Operating Systems Reliable and Secure? Computer, 39(5):44–51, 2006. J. N. Herder, H. Bos, B. Gras, P. Homburg, and A. S. Tanenbaum. Failure Resilience for Device Drivers. In Proc. 37th DSN, 2007. J. N. Herder, H. Bos, B. Gras, P. Homburg, and A. S. Tanenbaum. Construction of a Highly Dependable Operating System. In Proceedings of the 6th European Dependable Computing Conference (EDCC), pages 3–12. IEEE Computer Society, 2006. T.J. Ostrand and E.J.Weyuker. The Distribution of Faults in a Large Industrial Software System. In Proc. of the 2002 ACMSIGSOFT Int’l Symp. on Software Testing and Analysis, pages 55–64. ACM, 2002. T.J. Ostrand and E.J.Weyuker and and R.M. Bell. Where the Bugs Are. In Proc. of the 2004 ACM SIGSOFT Int’l Symp. on Software Testing and Analysis, pages 86–96. ACM, 2004. V.R. Basili and B.T. Perricone. Software Errors and Complexity: An Empirical Investigation. Commun. Of the ACM, 21(1):42–52, Jan. 1984. H. I. Glyfason and G. Hjalmtysson. Exceptional Kernel: Using C++ Exceptions in the Linux Kernel, October 2004. http://netlab.ru.is/exception/KernelExceptions.pdf.