BAB III ANALISIS DAN PERANCANGAN TEKNIK PENGUJIAN Pada bab ini akan dibahas teknik-teknik pengujian untuk melakukan analisis terhadap pemenuhan CGL Availability pada Fedora 7.
3.1
Spesifikasi Pengujian
3.1.1
Spesifikasi Hardware dan Software
Pengujian dilakukan pada perangkat keras dengan spesifikasi sebagai berikut:
Tabel III-1 Spesifikasi Hardware Pengujian
Perihal
Spesifikasi/Keterangan
Type
Notebook ACER Aspire 5024 WLCi
Processor
AMD Turion 64 ML-34
Memory
1024 MB DDR RAM
Storage
60 GB HDD
Display
15.4” WXGA CrystalBrite TFT LCD
Display Adapter
ATI Mobility Radeon X700 PCI Express 128 VRAM
Ethernet
10/100/1000 Gigabit Ehternet
WLAN
802.11 b/g
DVD/CD ROM
DVD/CD-RW
Pengujian akan dilakukan terhadap sistem operasi sebagai berikut yaitu sistem operasi Fedora 7 versi kernel 2.6.21-1.264.fc7(OS-Original). Sistem operasi ini memakai kernel yang dirilis resmi pada repositori fedora project. Pada sistem Operasi ini telah ditambahkan perangkat lunak pendukung pengujian yaitu: 1. Performance Co Pilot, merupakan framework untuk montoring resource pada komputer
III-1
2. Net SNMP dan SNMPTRAP Daemon, SNMP agent untuk mendeteksi dan menangani paket-paket dengan protokol SNMP 3. Ifenslave, perangkat lunak untuk melakukan bonding antar 2 NIC atau lebih 4. Wireshark, sebagai perangkat lunak memonitor paket-paket yang lewat di NIC Sistem operasi ini lebih identik dengan Fedora 7 awal yang merupakan kernel versi 2.6.211.264.fc7. Penulis beranggapan sistem operasi ini mewakili keadaan Fedora 7 yang sebenarnya dengan modul-modul yang telah mampu di tambahkan di Fedora 7. 3.1.2
Tipe Kasus Uji
Kasus uji yang penulis pakai dapat diklasifikasi menjadi 2 jenis yaitu: 1. Otomatis Pengujian secara otomatis bersifat tidak memiliki interaksi dengan penguji. Penguji hanya diminta untuk menjalankan program atau script yang telah ditulis. Program akan menjalankan kasus uji secara otomatis dan menghasilkan keluaran file output rekapitulasi pengujian. Sebagian besar kasus uji merupakan tipe ini. 2. Manual Pengujian secara manual membutuhkan interaksi dengan penguji. Interaksi yang dimaksud seperti melepaskan perangkat keras yang bersangkutan. Program tidak akan menghasilkan laporan seperti pada pengujian otomatis. Sebab hasil bergantung apa yang dilihat oleh penguji. Jenis ini dipakai pada pengujian notifikasi dan Ethernet bonding.
Sebagai catatan pada saat pengujian terlebih dahulu membaca file readme sebagai konfigurasi awal sebelum melakukan pengujian. 3.1.3
Kode Kasus Uji
Pada Tugas Akhit ini untuk memudahkan melakukkan pengujian, maka tiap kasus uji akan diberi kode kasus uji yang unik, sehingga dapat saling dibedakan. Pembahasan kasus uji diurutkan berdasarkan ID standar requirement yang telah ditentukan. Tiap kasus uji kana memiliki kata
III-2
kunci tertentu sehingga memudahkan untuk mengidentifikasikannya. Kata kunci ditulis setelah kode kasusus uji. Kode kasus uji memiliki format yaitu :
T _XXX_Y.Y_N_ZZ
Keterangan : T
: Kasus uji
XXX : Aspek yang di uji yaitu “AVL” untuk availability
3.2
Y.Y
: ID standar requirement
N
: Tipe Skenario ‘A’ untuk otomatis dan ‘M’ untuk manual
ZZ
: nomor kasus uji
Robust Mutexes - AVL 1.0
Spesifikasi AVL 1.0 [OSD07a] berkaitan tentang implementasi Robust Mutexes, merupakan prioritas 3 memiliki deskripsi sebagai berikut :
Description: OSDL CGL specifies that carrier grade Linux shall provide an enhancement to the POSIX Thread implementation that provides support for robust mutexes. Robust mutex support shall permit a mutex to synchronize threads, either in the same process or in different processes, even when processes or threads exit or abort unexpectedly. Applications using a robust mutex shall be able to see various return codes that indicate whether the previous holder of the mutex terminated, and also the recovery status of the state of the mutex.The new holder of the robust mutex shall be able to detect a failure, perform cleanup actions, and re-initialize the mutex for continued use. If a cleanup of the state protected by the mutex can't be completed, the mutex shall be marked “inconsistent” so that any future attempts to lock it will generate a status
III-3
indicating that it is inconsistent. The following two modes for setting the mutex to an inconsistent state shall be provided: •
Automatically mark the mutex “inconsistent” when the owner dies and the subsequent owner fails to explicitly mark it healthy.
•
Provide an advisory to subsequent owners that the mutex needs to be explicitly marked inconsistent.
Berdasarkan deskripsi di atas dapat di analisis bahwa sistem operasi yang mendukung robust mutex harus memenuhi syarat sebagai berikut: a. Memungkinkan sinkronisasi antar thread baik itu di proses yang sama ataupun di proses yang berbeda ketika suatu thread exit atau abort secara tidak sengaja b. Aplikasi atau program yang menggunakan robust mutex harus dapat mengerti return code bahwa pemegang mutex sebelumnya telah diterminasi c. Aplikasi atau program yang menggunakan robust mutex harus dapat mengerti status recovery dari state mutex d. Pemegang mutex baru harus bisa mendeteksi kegagalan, melakukan aksi “cleanup”dan inisialisasi ulang mutex untuk pengunaan selanjutnya. e. Jika aksi “cleanup” sedang diproteksi atau di-lock oleh mutex maka mutex tersebut akan ditandai dengan state “inconsistent” yang penggunaan selanjutnya dengan state inconsistent juga . f. Cara menge-set suatu state terdapat 2 mode yaitu: -
Secara otomatis ditandai “inconsistent” saat pemilik mutex terminasi dan pemegang berikutnya gagal menyatakan mutex tersebut “healthy”
-
Memberikan saran agar owner baru menyatakan bahwa mutex tersebut “inconsistent”
Robust mutexes pada Linux telah dikembangkan oleh Linux OS & Technology Team dari Intel Corporation dengan proyek “fusyn+RTNPTL: The making of a real-time synchronization infrastructure for Linux”[6]. Fusyn telah menyediakan kasus uji sebanyak 35 kasus uji. Dari 35 kasus uji tersebut terdapat 13 kasus uji yang menurut penulis berkaitan erat dengan robust mutex. III-4
Berikut penjelasan kasus uji tersebut yang penulis ambil sebagai pengujian terhadap sistem operasi Fedora.
3.2.1
Kasus Uji T_AVL_1.0_A_01 Dead Pass-Ownership
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan di-lock b. Thread A terminate atau abort tanpa unlocking c. Thread B jalan dan mencoba memperoleh mutex d. Thread B harusnya mendapatkan kode “EOWNERDEAD” pada mutex
3.2.2
Kasus Uji T_AVL_1.0_A_02 Get Dead Pass-Ownership
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja dan calon thread pemilik baru telah ada di antrian sebelumnya. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan dilock b. Thread B jalan dan mencoba memperoleh mutex namun sedang dipegang oleh thread A c. Thread A terminate atau abort tanpa unlocking d. Thread B harusnya mendapatkan mutex pada recovery mode
3.2.3
Kasus Uji T_AVL_1.0_A_03 Single Waiting Dead Pass-Ownership
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak III-5
sengaja dan calon thread pemilik baru telah ada di antrian sebelumnya namun pemilik baru tidak mampu melakukan recovery. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan dilock b. Thread B dan C jalan dan mencoba memperoleh mutex namun sedang dipegang oleh thread A c. Thread C memiliki prioritas lebih tinggi dari B d. Thread A terminate atau abort tanpa unlocking e. Thread C harusnya mendapatkan mutex pada recovery mode f. Thread C tidak mampu merecovery kemudian unlock mutex dan memberikan nya kepada Thread B
3.2.4
Kasus Uji T_AVL_1.0_A_04 Multi Waiting Dead Pass-Ownership
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja dan calon-calon thread pemilik baru telah ada di antrian sebelumnya. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan dilock b. Thread B,C,D,E, dan F jalan dan mencoba memperoleh mutex namun sedang dipegang oleh thread A c. Prioritas thread B lebih tinggi dari C, C lebih tinggi dari D, dan seterusnya hingga F merupakan prioritas terendah d. Thread A terminate atau abort tanpa unlocking e. Thread B harusnya mendapatkan mutex pada recovery mode, kemudian B terminate dan diganti oleh C, lalu D, dan seterusnya
3.2.5
Kasus Uji T_AVL_1.0_A_05 Recovery Dead Pass-Ownership
III-6
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja dan calon thread pemilik baru telah ada di antrian sebelumnya, pemilik mampu merecovery dan meneruskan ke pemilik lain yang kemudian abort lagi. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan dilock b. Thread B dan C jalan dan mencoba memperoleh mutex namun sedang dipegang oleh thread A c. Thread C memiliki prioritas lebih tinggi dari B d. Thread A terminate atau abort tanpa unlocking e. Thread C harusnya mendapatkan mutex pada recovery mode f. Thread C mampu merecovery kemudian unlock mutex dan memberikan nya kepada Thread B g. Thread B abort tanpa unlocking, harusnya owner terakhir adalah B
3.2.6
Kasus Uji T_AVL_1.0_A_06 Different Paths Lock Consistency
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja dan calon thread pemilik baru telah ada di antrian sebelumnya dan mampu melakukan recovery. Juga dites apakah mungkin melakukan recovery tanpa memiliki mutex. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan dilock b. Thread A terminate atau abort tanpa unlocking c. Lakukan recovery mode pada mutex d. Thread B jalan dan mendapatkan mutex pada recovery mode e. Thread B melakukan recovery mengeset mutex kembali ke consistent state f. Thread B exit dan meng-unlock mutex
III-7
3.2.7
Kasus Uji T_AVL_1.0_A_07 Get Dead owner Without Blocking
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja dan calon thread pemilik baru telah ada di antrian sebelumnya namun ada pemilik lain yang mencoba melakukan locking tetapi gagal. Locking thread lain disini tidak bersifat bloking dan diharapkan tidak dapat melakukan locking karena ada kode “EBUSY”. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan dilock b. Thread A terminate atau abort tanpa unlocking c. Thread B start dan memperoleh mutex dengan kode “EOWNERDEAD” dan menuggu signal untuk lanjut d. Saat B sedang menunggu signal untuk launjut thread C start dan mencoba mendapatkan mutex tetapi gagal karean “EBUSY” e. Thread C exit f. Thread B exit setelah mendapatkan signal lanjut dan melepaskan lock
3.2.8
Kasus Uji T_AVL_1.0_A_08 Get Not-Recoverable
Pada Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja dan calon thread pemilik baru telah ada di antrian sebelumnya namun ada pemilik lain yang mencoba melakukan locking tetapi gagal. Locking thread lain disini tidak bersifat bloking dan diharapkan tidak dapat melakukan locking karena ada kode “EBADR” yang diberikan pemilik thread karena tidak mungkin di-recover. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan dilock b. Thread A terminate atau abort tanpa unlocking c. Thread B start dan memperoleh mutex dengan kode “EOWNERDEAD” dan menuggu signal untuk lanjut
III-8
d. Thread B mengeset state ke mutex “ENOTRECOVERABLE” e. Saat B sedang menunggu signal untuk lanjut thread C start dan mencoba mendapatkan mutex tetapi gagal karena “EBADR” f. Thread C exit g. Thread B exit setelah mendapatkan signal lanjut dan melepaskan lock
3.2.9
Kasus Uji T_AVL_1.0_A_09 Non-Contended Acquisition
Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja sedangkan program bukan owner dari mutex. Program dapat memperoleh lock tanpa harus ke kernel space. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex tanpa melalui kernel dan dilock b. Thread A terminate atau abort tanpa unlocking c. Program mencoba meng-unlock mutex walaupun dia bukan owner
3.2.10 Kasus Uji T_AVL_1.0_A_10 Get Non-Contended Acquisition
Kasus Uji ini akan dilakukan tes apakah masih memungkinkan mendapatkan mutex (locking) apabila thread pemilik mutex sebelumnya telah terminasi exit atau abort secara tidak sengaja sedangkan program bukan owner dari mutex. Program dapat melepaskan lock tanpa harus ke kernel space. Program utama membantu thread didalamnya untuk memperoleh lock. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex tanpa melalui kernel dan dilock b. Thread B start menunggu lock c. Program utama meng-unlock mutex tanpa melalui kernel walaupun bukan owner d. Thread B mendapatkan lock e. Thread A berhenti f. Thread B berhenti dan melepaskan lock
III-9
3.2.11 Kasus Uji T_AVL_1.0_A_11 Recovery Non-Contended Acquisition
Kasus Uji ini sama dengan kasus uji T_AVL_1.0_10 sebelumnya namun pada awalnya ada thread lain yang menyebabkan state mutex jadi inconsistent. Langkah pengujian sebagai berikut: a. Thread 0 start memperoleh lock melalui kernel b. Thread 0 berhenti tanpa mengunlock c. Thread A dibuat, memperoleh mutex tanpa melalui kernel dan dilock d. Thread B start menunggu lock e. Program utama meng-unlock mutex tanpa melalui kernel walaupun bukan owner f. Thread B mendapatkan lock g. Thread A berhenti h. Thread B berhenti dan melepaskan lock
3.2.12 Kasus Uji T_AVL_1.0_A_12 Deadlock Non-Contended Acquisition
Kasus Uji ini akan dilakukan tes untuk melihat fitur mematikan dan menghidupkan robustness pada fusyn. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex tanpa melalui kernel dan dilock b. Thread A berhenti, tanpa melepaskan lock c. Thread B dibuat, mencoba memperoleh mutex tanpa melalui kernel d. Thread B tidak dapat memperoleh lock mendapat signal “EINTR” e. Thread B berhenti
3.2.13 Kasus Uji T_AVL_1.0_A_13 Non Robust Test
Kasus Uji ini akan dilakukan tes untuk melihat tidak mungkinnya mendapatkan lock jika mode robust tidak dipakai, ketika owner dari lock terminate. Langkah pengujian sebagai berikut: a. Thread A dibuat, memperoleh mutex dan fast locking III-10
b. Thread A exit atau abort tanpa unlocking c. Thread B dibuat d. Thread B menunggu selama beberapa detik untuk mendapatkan lock, namun tidak dapat juga
3.3
Forced Unmount - AVL 3.2
Spesifikasi AVL 3.2 [OSD07a] berkaitan tentang implementasi Force Unmount, merupakan prioritas 1 memiliki deskripsi sebagai berikut :
Description: OSDL CGL specifies that carrier grade Linux shall provide support for forced unmounting of a file system. The unmount shall work even if there are open files in the file system. Pending requests shall be ended with the return of an error value when the file system is unmounted.
Berdasarkan deskripsi di atas dapat di analisis bahwa sistem operasi yang mendukung force unmount harus memenuhi syarat sebagai berikut: a. perintah “unmount” tetap bekerja walaupun ada file pada direktori mount point ataupun di bawahnya yang sedang di akses b. Permintaan terhadap file akan di hentikan dan diberikan error value ketika sudah di unmount
Forced Umount telah menjadi patch untuk kernel linux dan sudah ada di kernel versi 2.6.11 dan diatasnya. Berdasarkan syarat yang telah dideskripsikan sebelumnya dapat dibuat sejumlah uji kasus sebagai berikut:
III-11
3.3.1
Kasus Uji T_AVL_3.2_A_01 Read Testing
Pada Kasus Uji ini akan dilakukan tes apakah perintah “Unmount” tetap bekerja walaupun ada file yang sedang buka dan kemudian apakah mungkin membaca dari file system yang sudah terunmount. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point b. Lakukan pembukaan pada file yang ada pada mount point c. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya d. Lakukan pembacaan terhadap file yang di file system yang telah ter-unmount e. Periksa apakah perintah force umount berjalan atau tidak, dengan memeriksa apakah device file system masih ada di list device yang di mount atau tidak
3.3.2
Kasus Uji T_AVL_3.2_A_02 Write Testing
Pada Kasus Uji ini akan dilakukan tes apakah perintah “unmount” tetap bekerja walaupun ada file yang sedang dibuka dan kemudian apakah mungkin menulis dari file system yang sudah terunmount. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point b. Lakukan pembukaan pada file yang ada pada mount point c. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya d. Lakukan penulisan ulang terhadap file yang di file system yang telah ter-unmount e. Periksa apakah perintah force umount berjalan atau tidak, dengan memeriksa apakah device file system masih ada di list device yang di mount atau tidak
3.3.3
Kasus Uji T_AVL_3.2_A_03 Change Current Directory
III-12
Pada Kasus Uji ini akan dilakukan tes apakah perintah “unmount” tetap bekerja walaupun direktori kerja pindah ke mount point yang bersangkutan. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point b. Pindahkan direktori kerja ke mount point c. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya d. Pindahkan direktori kerja ke mount point lagi e. Periksa apakah perintah force umount berjalan atau tidak, dengan memeriksa apakah device file system masih ada di list device yang di mount atau tidak
3.3.4
Kasus Uji T_AVL_3.2_A_04 Change Root Directory
Pada Kasus Uji ini akan dilakukan tes apakah perintah “unmount” tetap bekerja walaupun root direktori kerja pindah ke mount point yang bersangkutan. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point b. Pindahkan root direktori kerja ke mount point c. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya d. Lakukan Pindahkan root direktori kerja ke mount point lagi e. Periksa apakah perintah force umount berjalan atau tidak, dengan memeriksa apakah device file system masih ada di list device yang di mount atau tidak
3.3.5
Kasus Uji T_AVL_3.2_A_05 Memory Mapping Read
Pada Kasus Uji ini akan dilakukan tes apakah perintah “unmount” tetap bekerja walaupun ada file yang sedang buka dan kemudian apakah mungkin membaca dari file system yang sudah terunmount. Pembacaan ulang tidak dilakukan secara langsung melainkan melalui mekanisme memory mapping. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point
III-13
b. Tulis data ke map area c. Lakukan memory mapping ke file baca d. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya e. Lakukan pembacaan kembali dari memory mapping f. Periksa apakah perintah force umount berjalan atau tidak, dengan memeriksa apakah device file system masih ada di list device yang di mount atau tidak
3.3.6
Kasus Uji T_AVL_3.2_A_06 Memory Mapping Write
Pada Kasus Uji ini akan dilakukan tes apakah perintah “unmount” tetap bekerja walaupun ada file yang sedang buka dan kemudian apakah mungkin menulis dari file system yang sudah terunmount. Penulisan ulang tidak dilakukan secara langsung melainkan melalui mekanisme memory mapping. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point b. Tulis data ke map area c. Lakukan memory mapping ke file tulis d. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya e. Lakukan penulisan kembali dari memory mapping f. Periksa apakah perintah force umount berjalan atau tidak, dengan memeriksa apakah device file system masih ada di list device yang di mount atau tidak 3.3.7
Kasus Uji T_AVL_3.2_A_07 Read Error Value
Pada Kasus Uji mirip seperti kasus uji 3.3.7 Kasus Uji T_AVL_3.2_A_01, hanya pada kasus ni ini akan dilihat apakah proses pembacaan ulang setelah perintah unmount memberikan nilai error atau tidak. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point b. Lakukan pembukaan pada file yang ada pada mount point
III-14
c. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya d. Lakukan pembacaan terhadap file yang di file system yang telah ter-unmount e. Periksa apakah ada error value yang diberiakan atau tidak terhadap pembacaan file
3.3.8
Kasus Uji T_AVL_3.2_A_08 Write Error Value
Pada Kasus Uji mirip seperti kasus uji 3.3.7 Kasus Uji T_AVL_3.2_A_02, hanya pada kasus ni ini akan dilihat apakah proses penulisan ulang setelah perintah unmount memberikan nilai error atau tidak. Langkah pengujian sebagai berikut: a. Lakukan proses mounting pada file system yang dipilih ke mount point b. Lakukan pembukaan pada file yang ada pada mount point c. Jalankan perintah force unmount terhadap device file system yang telah di-mount terlebih sebelumnya d. Lakukan penulisan ulang terhadap file yang di file system yang telah ter-unmount f. Periksa apakah ada error value yang diberiakan atau tidak terhadap penulisan file
3.4
Low Memory Condition Monitor – AVL 4.3
Spesifikasi AVL 4.3 [OSD07a] berkaitan tentang implementasi Low Memory Condition Monitor, merupakan prioritas 3 memiliki deskripsi sebagai berikut :
Description: OSDL CGL specifies that carrier grade Linux shall provide a low memory condition monitor. To avoid encountering a true out-of-memory (OOM) condition in the Linux kernel, a userspace facility should be provided to monitor memory usage and take action based on a configurable low-memory threshold. This threshold would be set to predict an OOM condition before it becomes critical. The threshold would apply to both physical memory and swap area.
III-15
The application should record the top N memory-consuming processes, so that when the threshold is reached, processes that are not on the user-defined do-not -kill list that are trending up in memory use can be killed. This capability would allow the application to tell the kernel to stop allocating memory to user-space processes. When applications run out of pre-allocated memory, the system could remain nominally in service until more memory becomes available.
Berdasarkan deskripsi di atas dapat di analisis bahwa sistem operasi yang mendukung Low Memory Condition Monitor harus memenuhi syarat sebagai berikut: a. Menghindari kondisi true out-of-memory (OOM) pada kernel b. Menyediakan fasilitas me-monitor penggunaan memory pada user space c. Menjalankan aksi berdasarkan low-memory threshold yang berubah sesuai prediksi dan mencakup physical memory dan swap area. d. Menyimpan data sejumlah proses yang memakai memori pada tingkat tertentu e. Meminta kernel agar pada saat tertentu menghentikan proses alokasi memori ke proses di user space
Seperti yang telah disebutkan pada bab II bahwa pada Linux telah dikembangkan suatu € untuk memonitor penggunaan resources pada Linux, yaitu CKRM. Namun pada penelitian CRKM versi terbaru adalah untuk kernel versi 2.6.28 yang merupakan versi di bawah Fedora 7. Penulis mengalami kesulitan yang cukup berarti untuk memasukkan modul CKRM ke dalam kernel Fedora 7. Sebagai pengganti CKRM, PGP dianggap cukup baik dan mudah untuk diimplementasikan untuk melakukan tes ini. Dengan PGP terlebih dahulu dibuat aturan atau rules agar pmie dapat mengerti monitoring apa yang kita inginkan. Pmie kemudian dijalankan dengan aturan tersebut sehingga monitoring dapat berjalan. Program eatmem dari test yang diberikan oleh CKRM dapat digunakan sebagai program yang mengkonsumsi memori. Berdasarkan syarat yang telah dideskripsikan sebelumnya dapat dibuat sejumlah uji kasus sebagai berikut:
III-16
3.4.1
Kasus Uji T_AVL_4.3_M_01 Alert Condition
Pada kasus uji ini akan diuji kriteria apakah CKRM mampu menghindari kondisi Out Of Memory dan meminta proses alokasi memori ke proses di user space, berikut langkah tesnya: a. Buat dengan program eatmem lakukan konsumsi memori sesuai dengan spesifikasi perangkat lunak misalnya program menkonsumsi 750 MB untuk 1 GB Total memori. b. Lakukan monitoring dengan pmie dengan rules untuk medeteksi kondisi memori kritis dengan refresh rate tertentu misalnya 3 detik. c. Periksa apakah ada peringatan atau alert yang keluar. 3.4.2
Kasus Uji T_AVL_4.3_M_02 Process List
Pada kasus uji ini akan diuji kriteria apakah CKRM mampu memberikan tool untuk monitoring penggunan memori dan tool tersebut mampu menyimpan sejumlah informasi proses yang mengkonsumsi memori yang banyak, langkah pengujian sebagai berikut: a. Buat sejumlah program eatmem, lakukan konsumsi memori sesuai dengan spesifikasi perangkat lunak misalnya program pertama mengkonsumsi 200 MB, program kedua mengkonsumsi 220 MB, dan program ketiga mengkonsumsi 250 MB. b. Lakukan monitoring dengan pmie dengan rules untuk medeteksi proses yang mengkonsumsi memori banyak dengan refresh rate tertentu misalnya 3 detik. c. Periksa apakah ada print atau list proses-proses yang mengkonsumsi memori banyak.
3.5
Low Memory Notification Mechanism – AVL 4.4
Spesifikasi AVL 4.4 [OSD07a] berkaitan tentang implementasi Low Memory Notification Mechanism, merupakan prioritas 3 memiliki deskripsi sebagai berikut :
Description: OSDL CGL specifies that carrier grade Linux shall provide a low memory notification mechanism.Whenever a low memory condition is detected, the mechanism shall generate a remote notification. III-17
Notification methods shall support enterprise-level notification protocols such as SNMP or CIM. See: •
STD.7 SNMP (for IPv4 and IPv6)
Berdasarkan deskripsi di atas dapat dianalisis bahwa sistem operasi yang mendukung Low Memory Notification Mechanism harus memenuhi syarat yaitu menyediakan remote notification jika terjadi low memory condition.
Untuk melakukan pengujian ini diperlukan adanya SNMP Agent pada perangkat yang diuji. 3.5.1
Kasus Uji T_AVL_4.4_M_01 SMTP Trap Generator
Pada Kasus uji ini akan dicoba apakah jik terjadi kondisi low memory apakah PCP mengirim notifikasi melalui SNMP, berikut langkah pengujiannya a. Buat dengan program eatmem lakukan konsumsi memori sesuai dengan spesifikasi perangkat lunak misalnya program menkonsumsi 750 MB untuk 1 GB Total memori. b. Lakukan monitoring dengan pmie dengan rules untuk medeteksi kondisi memori kritis dan mengirim SNMPTRAP dengan refresh rate tertentu misalnya 3 detik. c. Dengan tool yang disediakan SNMP Agent periksa apakah ada notifikasi yang dikirimkan, biasanya notifikasi berupa SMNP TRAP. d. Dengan bantuan perangkat lunak wireshark lakukan pendeteksi pake SNMP tersebut.
3.6
Ethernet link bonding using IPV4 – AVL 21.0
Spesifikasi AVL 21.0 [OSD07a] berkaitan tentang implementasi Ethernet link bonding using IPV4, merupakan prioritas 1 memiliki deskripsi sebagai berikut :
Description: OSDL CGL shall support bonding of multiple Ethernet NICs within a single node using IPV4. The bonding supports the following functions:
III-18
•
Ethernet link aggregation - Supports multiple Ethernet cards to be bonded for bandwidth aggregation.
•
Ethernet link failover - Supports automatic failover of an IP address from one Ethernet NIC to another within a single node using the Ethernet bonding.
Some mode of bonding requires IEEE 802.3ad support on switches; however, other modes do not require special protocol support.
Berdasarkan deskripsi di atas dapat dianalisis bahwa sistem operasi yang mendukung Ethernet link bonding harus memenuhi syarat sebagai berikut: a. Mampu melakukan link aggregasi yang merupakan kemampuan untuk mem-bonding sejumlah Ethernet card dengan bandwith yang teragregasi juga b. Mampu melakukan failover dari satu interface bond ke lainnya jia terjadi kegagalan pada satu interface Fileover dilakukan pada node yang sama.
Sesuai dengan spesifikasi hardware pengujian yang hanya memiliki 1 ethernet card maka pada kasus tes akan dilakukan bonding antara ethernet dan wireless card. Juga perlu diingat bahwa pada sebagian kasus diperlukan kemampuan bonding dari switch atau router yang dituju. Berikut skema tes uji yang akan dilakukan: 3.6.1
Kasus Uji T_AVL_21.0_M_01 Bonding Capability
Pada kasus uji ini akan dicoba apakah dapat melaukan bonding antara eth0 yang merupakan ethernet card dan eth1 yang merupakan wireless card. Bonding yang tercipta dilakukan pengukuran dengan memakai perangkat lunak pembantu dan memakai koneksi hasil bonding. Langkah pengujian sebagai berikut: a. Lakukan konfigurasi bond0, eth0, eth1 yang mana bond0 merupakan koneksi hasil bonding dari eth0 dan eth1 b. Uji peningkatan bandwitdh dengan perangkat lunak pembantu, lakukan dengan melakaukan ping melalui bond0 sebanyak 50x terhadap gateway
III-19
c. Perangakat lunak wireshark dapat digunakan untuk melihat performansi, hasil pengujian dapat dilaporkan pada bentuk grafik 3.6.2
Kasus Uji T_AVL_21.0_M_02 Failover to Wireless
Pada kasus uji ini akan dicoba apakan dapat melakukan bonding antara eth0 yang merupakan ethernet card dan eth1 yang merupakan wireless card. Bonding yang tercipta dilakukan pengukuran dengan memakai perangkat lunak pembantu dan memakai koneksi hasil bonding. Pada saat pengukuran dilakukan pemutusan terhadap ethernet. Langkah pengujian sebagai berikut: a. Lakukan konfigurasi bond0, eth0, eth1 yang mana bond0 merupakan koneksi hasil bonding dari eth0 dan eth1. b. Uji peningkatan bandwitdh dengan perangkat lunak pembantu, lakukan dengan melakaukan ping melalui bond0 sebanyak 50x terhadap gateway c. Pada saat proses ping belum selesai, non-aktifkan interface eth0. d. Perhatikan apakah ping terus berlanjut atau tidak. e. Perangakat lunak wireshark dapat digunakan untuk melihat performansi, hasil pengujian dapat dilaporkan pada bentuk grafik 3.6.3
Kasus Uji T_AVL_21.0_M_03 Failover to Wired
Pada kasus uji ini akan dicoba apakan dapat melakukan bonding antara eth0 yang merupakan ethernet card dan eth1 yang merupakan wireless card. Bonding yang tercipta dilakukan pengukuran dengan memakai perangkat lunak pembantu dan memakai koneksi hasil bonding. Pada saat pengukuran dilakukan pemutusan terhadap wireless. Langkah pengujian sebagai berikut: a. Lakukan konfigurasi bond0, eth0, eth1 yang mana bond0 merupakan koneksi hasil bonding dari eth0 dan eth1. b. Uji peningkatan bandwitdh dengan perangkat lunak pembantu, lakukan dengan melakaukan ping melalui bond0 sebanyak 50x terhadap gateway
III-20
c. Pada saat proses ping belum selesai, non-aktifkan interface eth1. d. Perhatikan apakah ping terus berlanjut atau tidak. e. Perangakat lunak wireshark dapat digunakan untuk melihat performansi, hasil pengujian dapat dilaporkan pada bentuk grafik
3.7
Kriteria Keberhasilan Pengujian
Berdasarkan perancangan-perancangan kasus-kasus uji dapat dihimpun sejumlah syarat apakah kasus uji tersebut terpenuhi atau tidak. Tabel III-2 berikut merinci kriteria tersebut:
Tabel III-2 Keriteria Keberhasilan
Kategori Robust Mutex
Kasus Uji T_AVL_1.0_A_01
T_AVL_1.0_A_02
T_AVL_1.0_A_03
T_AVL_1.0_A_04
T_AVL_1.0_A_05
T_AVL_1.0_A_06
Keterangan Berhasil Gagal mendapatkan mutex dari tidak mendapatkan mutex, pemilik sebelumnya yang atau salah mendapatkan telah terminasi kode mutex atau segmentation fault mendapatkan mutex dari tidak mendapatkan mutex, pemilik sebelumnya yang atau salah mendapatkan telah terminasi kode mutex atau segmentation fault mendapatkan mutex dari tidak mendapatkan mutex, pemilik sebelumnya yang atau salah mendapatkan telah terminasi kode mutex atau segmentation fault mendapatkan mutex dari tidak mendapatkan mutex, pemilik sebelumnya yang atau salah mendapatkan telah terminasi kode mutex atau segmentation fault mendapatkan mutex dari tidak mendapatkan mutex, pemilik sebelumnya yang atau salah mendapatkan telah terminasi kode mutex atau segmentation fault mendapatkan mutex dari tidak mendapatkan mutex, pemilik sebelumnya yang atau salah mendapatkan telah terminasi kode mutex atau segmentation fault
III-21
Kategori
Kasus Uji T_AVL_1.0_A_07
Force Unmount
Berhasil mendapatkan mutex dari pemilik sebelumnya yang telah terminasi
T_AVL_1.0_A_08 T_AVL_1.0_A_09 T_AVL_1.0_A_10 T_AVL_1.0_A_11
mutex te-recover mengunlock mutex mengunlock mutex mendapatkan mutex dari pemilik sebelumnya yang telah terminasi
T_AVL_1.0_A_12 T_AVL_1.0_A_13
vfulock dimatikan mendapatkan mutex dari pemilik sebelumnya yang telah terminasi
T_AVL_3.2_A_01
T_AVL_3.2_A_07
berhasil meng-unmount device berhasil meng-unmount device berhasil meng-unmount device berhasil meng-unmount device berhasil meng-unmount device berhasil meng-unmount device mengembalikan kode error
T_AVL_3.2_A_08
mengembalikan kode error
T_AVL_4.3_M_01
ada informasi low memory, program tidak diizinkan memakai memory lebih dari threshold, sehingga tidak terjadi kondisi out of memory Data proses yang menkonsumsi memori tersimpan dan benar
T_AVL_3.2_A_02 T_AVL_3.2_A_03 T_AVL_3.2_A_04 T_AVL_3.2_A_05 T_AVL_3.2_A_06
Low Memory Condition Monitor
Keterangan
T_AVL_4.3_M_02
III-22
Gagal tidak mendapatkan mutex, atau salah mendapatkan kode mutex atau segmentation fault mutex tidak te-recover gagal meng-unlock mutex gagal meng-unlock mutex tidak mendapatkan mutex, atau salah mendapatkan kode mutex atau segmentation fault vfulock tidak dimatikan tidak mendapatkan mutex, atau salah mendapatkan kode mutex atau segmentation fault tidak berhasil mengunmount device tidak berhasil mengunmount device tidak berhasil mengunmount device tidak berhasil mengunmount device tidak berhasil mengunmount device tidak berhasil mengunmount device tidak mengembalikan kode error tidak mengembalikan kode error tidak ada informasi low memory, program diizinkan memakai memory lebih dari threshold, sehingga terjadi kondisi out of memory Data proses yang menkonsumsi memori tidak tersimpan atau benar
Kategori Low Mem Condition Monitor Notification Ethernet Bonding
Kasus Uji T_AVL_4.4_M_01
T_AVL_21.0_M_01 T_AVL_21.0_M_02 T_AVL_21.0_M_03
Keterangan Berhasil Ada SNMP Trap yang bangkit saat low memory
Gagal Tidak Ada SNMP Trap yang bangkit saat low memory
bonding berhasil dilakukan ada peningkatan bandwidth ada fail over ke wireless ada fail over ke wired ethernet
bonding tidak berhasil dilakukan ada fail over ke wireless tidak ada fail over ke wired ethernet
III-23
