Final Project

Analisis Pemenuhan Carrier Grade Linux Standard 4.
0 Aspek Cluster Pada Fedora 7
LAPORAN TUGAS AKHIR
Disusun sebagai syarat kelulusan tingkat sarjana
oleh: Prasetyo Nugroho / 13504039
PROGRAM STUDI TEKNIK INFORMATIKA SEKOLAH TEKNIK ELEKTRO DAN INFORMATIKA INSTITUT TEKNOLOGI BANDUNG 2009
LEMBAR PENGESAHAN Program Studi Sarjana Teknik Informatika
Analisis Pemenuhan Carrier Grade Linux Standard 4.0 Aspek Cluster Pada Fedora 7
Tugas Akhir Program Studi Sarjana Teknik Informatika ITB
Oleh Prasetyo Nugroho / 13504039
Telah disetujui dan disahkan sebagai laporan Tugas Akhir Bandung, pada tanggal 26 Juni 2009
Pembimbing
Achmad Imam Kistijantoro, S.T., M.Sc., Ph.D. NIP 132320559
ii
ABSTRAKSI
Carrier Grade adalah istilah bahwa suatu sistem dibangun untuk meningkatkan ketersediaan dan ketepatan waktu untuk memenuhi standar dari jaringan komunikasi modern. Carrier Grade Linux (CGL) adalah sekumpulan spesifikasi yang dibangun oleh Open Source Development Labs (OSDL). CGL sendiri dibangun untuk menggantikan arsitektur jaringan telekomunikasi saat ini yang masih bersifat tertutup, yang sangat mahal untuk dikembangkan dan dirawat. Sistem operasi yang dapat memenuhi spesifikasi-spesifikasi yang ditetapkan pada CGL disebut Carrier Grade Operating System. Aspek Cluster merupakan salah satu aspek yang penting yang harus dimiliki suatu sistem operasi agar dapat dianggap sebagai Carrier Grade Operating System. Tujuan utama adanya cluster ini adalah agar dapat meningkatkan hasil produksi, meningkatkan ketersediaan produk dan layanan, meningkatkan perawatan produk, dan mengefisiensi biaya. Analisis dan pengujian terhadap Fedora 7 bertujuan untuk mengetahui kemampuan Fedora 7 dalam memenuhi kebutuhan-kebutuhan yang terdapat pada CGL khususnya dalam aspek Cluster. Selain itu, juga untuk mengetahui aplikasi dan tambahan apasaja yang dibutuhkan dalam rangka memenuhi kebutuhan yang terdapat pada CGL Cluster. Hasil dari pengujian yang dilakukan menunjukkan bahwa Fedora 7 dapat memenuhi beberapa spesifikasi yang diujikan. Selain itu, terdapat juga perbandingan antara Fedora 7 dan Fedora 11 dalam memenuhi spesifikasi yang diujikan. Kata kunci: CGL, Cluster, Fedora 7.
iii
KATA PENGANTAR
Puji syukur yang sangat besar kepada Tuhan atas anugerah dan berkat yang diberikan kepada penulis untuk menyelesaikan tugas akhir ini dengan judul Analisis Pemenuhan Carrier Grade Linux Standard 4.0 Aspek Cluster Pada Fedora 7. Selama pengerjaan tugas akhir ini, penulis banyak didukung dan dibantu oleh berbagai pihak. Oleh karena itu penulis ingin mengucapkan terima kasih kepada: 1. Orang tua (Bapak dan Ibu) yang mau memberikan kepercayaan, dukungan, kesempatan, dan doa selama ini. Juga kepada mas Prambudi dan mas Saseno atas dukungan, perhatian, dan semangat yang telah diberikan selama ini. 2. Bapak Achmad Imam Kistijantoro, S.T., M.Sc., Ph.D selaku pembimbing tugas akhir ini atas segala ilmu, kebaikan, dan kesabaran yang telah diberikan dan yang sangat berharga selama pengerjaan tugas akhir ini. 3. Ibu Henny Yusnita Zubir, B.S., M.T. atas kritik dan masukan yang diberikan dalam tahap proposal dan persiapan sidang tugas akhir ini. 4. Bapak Bugi Wibowo, S.T., M.T. atas kritik, masukan, dan beberapa pemahaman dalam tahap seminar dan sidang tugas akhir ini. 5. Bapak Riza Satria Perdana, S.T., M.T. atas kritik, masukan, dan banyak pemahaman dalam tahap sidang tugas akhir ini. 6. Para staf dan pegawai Teknik Informatika: Pak Rasidi, Pak Ade Taryat, dan Ibu Nur atas bantuan dalam hal birokrasi dan administrasi selama proses tugas akhir ini. 7. Rekan-rekan sister: Dian, Moren, dan Anda, yang telah bersama-sama berbagi pemahaman dan mendukung dalam pengerjaan tugas akhir ini. 8. Teman-teman dekat: Yoseph, Igor, Heryanto, Philip, Depsi, dan Santy yang telah memberikan semangat dan dukungan dalam pengerjaan tugas akhir ini. 9. Teman-teman MIC dan POSS: Gita, Herianto, Step, Devis, Joel ,Ronald atas pertemanan selama ini. 10. Teman-teman IF 2004 atas persahabatan yang telah terjalin serta semangat perjuangan bersama-sama selama ini.
iv
Serta kepada pihak-pihak lainnya yang tidak dapat disebutkan satu-persatu pada kesempatan ini. Akhir kata, penulis berharap agar tugas akhir ini dapat bermanfaat bagi banyak pihak terlebih bagi pengembang opensource software secara keseluruhan. Tidak lupa juga, penulis mengharapkan adanya saran dan kritik yang membangun.
Bandung, 26 Juni 2009
Penulis
DAFTAR ISI
LEMBAR PENGESAHAN ........................................................................................................ II ABSTRAKSI ............................................................................................................................ III KATA PENGANTAR.............................................................................................................. IV DAFTAR ISI ........................................................................................................................... VI DAFTAR GAMBAR ................................................................................................................. X DAFTAR TABEL .................................................................................................................... XI PENDAHULUAN ................................................................................................................... I-1 1.1 1.2 1.3 1.4 1.5 1.6 Latar Belakang ......................................................................................................... I-1 Rumusan Masalah..................................................................................................... I-2 Tujuan ...................................................................................................................... I-2 Batasan Masalah ....................................................................................................... I-3 Metodologi ............................................................................................................... I-3 Sistematika Pembahasan ........................................................................................... I-4
DASAR TEORI ...................................................................................................................... II-1 2.1 Carrier Grade Linux ................................................................................................. II-1
2.1.1 CGL 4.0 Cluster ................................................................................................... II-2 2.2 High Availability Cluster ......................................................................................... II-3
2.2.1 Availability Framework ....................................................................................... II-4 2.2.1.1 2.2.1.2 2.2.1.3 Ethernet ................................................................................................... II-4 Ethernet MAC Address Takeover .............................................................. II-5 IP Takeover .............................................................................................. II-6
2.2.2 Fault Handling .................................................................................................... II-6 2.2.2.1 2.2.2.2 Cluster Node Failure Detection ................................................................ II-6 Aplication Fail-Over Enabling ................................................................. II-7
2.2.3 Membership Service ............................................................................................. II-8 2.2.3.1 Dynamic Cluster Membership .................................................................. II-8 vi
2.2.4 Management ........................................................................................................ II-9 2.2.4.1 2.3 Cluster-Wide Kernel Crash Dump ............................................................ II-9
Kakas ...................................................................................................................... II-9
2.3.1 Heartbeat ............................................................................................................. II-9 2.3.2 Linux Kernel Crash Dump ................................................................................. II-10 2.3.3 Netdump dan Netdump-server ............................................................................ II-11 2.3.4 Performance Co-Pilot ........................................................................................ II-11 ANALISIS DAN PERANCANGAN KASUS UJI................................................................. III-1 3.1 Spesifikasi Pengujian ............................................................................................. III-1
3.1.1 Rancangan Sistem yang Dibangun ..................................................................... III-2 3.1.4 Kode Kasus Uji .................................................................................................. III-2 3.2 Ethernet MAC Address Takeover CAF 2.1 ......................................................... III-3
3.2.1 Kasus Uji T_CAF_2.1_01 .................................................................................. III-3 3.2.2 Kasus Uji T_CAF_2.1_02 .................................................................................. III-4 3.3 IP Takeover CAF 2.2 .......................................................................................... III-4
3.3.1 Kasus Uji T_CAF_2.2_01 .................................................................................. III-5 3.3.2 Kasus Uji T_CAF_2.2_02 .................................................................................. III-5 3.4 Cluster Node Failure Detection CFH 1.0 ............................................................. III-5
3.4.1 Kasus Uji T_CFH_1.0_01 .................................................................................. III-7 3.4.2 Kasus Uji T_CFH_1.0_02 .................................................................................. III-7 3.4.3 Kasus Uji T_CFH_1.0_03 .................................................................................. III-7 3.4.4 Kasus Uji T_CFH_1.0_04 .................................................................................. III-8 3.4.5 Kasus Uji T_CFH_1.0_05 .................................................................................. III-8 3.5 Application Failover Enabling CFH 3.0 .............................................................. III-8
3.5.1 Kasus Uji T_CFH_3.0_01 .................................................................................. III-9 3.5.2 Kasus Uji T_CFH_3.0_02 ................................................................................ III-10 3.6 Dynamic Cluster Membership CMS 2.0 ............................................................ III-10
3.6.1 Kasus Uji T_CMS_2.0_01 ................................................................................ III-11 3.6.2 Kasus Uji T_CMS_2.0_02 ................................................................................ III-11 3.7 Cluster-Wide Kernel Crash Dump CDIAG 2.2.................................................. III-11
3.7.1 Kasus Uji T_CDIAG_2.2_01 ............................................................................ III-12 vii
3.8
Kriteria Keberhasilan Pengujian........................................................................... III-12
HASIL PENGUJIAN DAN PEMBAHASAN ....................................................................... IV-1 4.1 Jalannya Pengujian ................................................................................................ IV-1
4.1.1 Ethernet MAC Address Takeover ....................................................................... IV-2 4.1.2 IP Takeover ....................................................................................................... IV-3 4.1.3 Cluster Node Failure Detection ......................................................................... IV-3 4.1.4 Application Failover Enabling ........................................................................... IV-4 4.1.5 Dynamic Cluster Membership ............................................................................ IV-4 4.1.6 Cluster-Wide Kernel Crash Dump...................................................................... IV-4 4.2 4.3 Hasil Pengujian...................................................................................................... IV-5 Analisis Hasil Pengujian ........................................................................................ IV-5
4.3.1 Ethernet MAC Address Takeover ....................................................................... IV-5 4.3.2 IP Takeover ....................................................................................................... IV-6 4.3.3 Cluster Node Failure Detection ......................................................................... IV-6 4.3.4 Application Failover Enabling ........................................................................... IV-7 4.3.5 Dynamic Cluster Membership ............................................................................ IV-8 4.3.6 Cluster Wide Kernel Crash Dump ...................................................................... IV-8 PENUTUP ............................................................................................................................. V-1 5.1 5.2 Kesimpulan .................................................................................................................1 Saran ...........................................................................................................................1
DAFTAR REFERENSI ........................................................................................................... XII LAMPIRAN A....................................................................................................................... A-1 Cluster Requirements ......................................................................................................... A-1 CFH.1.0 Cluster Node Failure Detection........................................................................ A-1 CFH.2.0 Prevent Failed Node From Corrupting Shared Resources ................................ A-2 CFH.3.0 Application Fail-Over Enabling ....................................................................... A-2 CSM.1.0 Storage Network Replication ............................................................................ A-3 CSM.2.0 Cluster-aware Volume Management for Shared Storage .................................. A-3 CSM.4.0 Redundant Cluster Storage Path ...................................................................... A-4 viii
CSM.6.0 Cluster File System .......................................................................................... A-4 CSM.7.0 Shared Storage Consistent Access .................................................................... A-4 CCM.2.1 Cluster Communication Service - Logical Addressing ..................................... A-4 CCM.2.2 Cluster Communication Service - Fault Handling............................................ A-5 CCM.3.0 Redundant Cluster Communication Path ......................................................... A-5 CAF.2.1 Ethernet MAC Address Takeover ...................................................................... A-6 CAF.2.2 IP Takeover ...................................................................................................... A-6 CDIAG.2.1 Cluster-Wide Identified Application Core Dump .......................................... A-6 CDIAG.2.2 Cluster-Wide Kernel Crash Dump ................................................................ A-6 CDIAG.2.3 Cluster Wide Log Collection ........................................................................ A-7 CDIAG.2.4 Synchronized/Atomic Time Across Cluster ................................................... A-7 LAMPIRAN B ........................................................................................................................ B-1 PCP CHART RESOURCE MONITORING ............................................................................ B-1
ix
DAFTAR GAMBAR
Gambar III-1 Rancangan Sistem............................................................................................ III-2 Gambar IV-1 Model Sistem .................................................................................................. IV-2
DAFTAR TABEL
Tabel III-1 Kriteria Keberhasilan......................................................................................... III-12 Tabel IV-1 Spesifikasi Hardware Server B (Server Pasif) ...................................................... IV-1 Tabel IV-2 Hasil Percobaan .................................................................................................. IV-5
xi
BAB I Pendahuluan
Pada bab ini, akan dijelaskan mengenai latar belakang, rumusan masalah, tujuan, batasan masalah, metodologi, serta sistematika pembahasan yang digunakan dalam menyusun laporan tugas akhir.
1.1
Latar Belakang
Carrier Grade Linux (CGL) adalah sekumpulan spesifikasi yang dibangun oleh Open Source Development Labs (OSDL) agar suatu sistem operasi Linux dapat dikatakan sebagai Carrier Grade Operating System. Carrier Grade adalah istilah bahwa suatu sistem dibangun untuk meningkatkan ketersediaan dan ketepatan waktu untuk memenuhi standar dari jaringan komunikasi modern [1]. CGL sendiri dibangun untuk menggantikan arsitektur jaringan telekomunikasi saat ini yang masih bersifat tertutup, yang sangat mahal untuk dikembangkan dan dirawat [2]. Saat ini CGL versi 4.0 telah meliputi 7 spesifikasi standar, yaitu Availability, Clusters, Serviceability, Performance, Standards, Hardware, dan Security. Dalam setiap aspek tersebut, terdapat spesifikasi-spesifikasi yang dikategorikan menjadi 3 prioritas, yaitu Prioritas 1 (bersifat wajib), Prioritas 2 (bersifat opsional), dan Prioritas 3 (bersifat rencana dan tidak diwajibkan). Aspek Cluster merupakan salah satu aspek yang penting yang harus dimiliki suatu sistem operasi agar dapat dianggap sebagai Carrier Grade Operating System. Tujuan utama adanya cluster ini adalah agar dapat meningkatkan hasil produksi, meningkatkan ketersediaan produk dan layanan, meningkatkan perawatan produk, dan mengefisiensi biaya. Teknologi cluster dibagi menjadi beberapa tipe, misalnya High Performance Cluster, Scalability Cluster, High Availability Cluster, dan Server Consolidation Cluster [4]. Namun untuk dapat meningkatkan ketersediaan, CGL pada aspek cluster ini akan lebih difokuskan pada tipe/model High Availability Cluster, sedangkan model cluster lainnya menjadi prioritas kedua [4].
I-1
I-2 Monta Vista, NexusWare, dan FSM Labs adalah beberapa perusahaan yang bersifat komersil, misalnya Monta Vista Carrier Grade Edition, yang telah mendaftarkan produknya sebagai produk yang memenuhi CGL versi 3.2. Sedangkan sistem operasi lain, seperti Fedora, memang tidak dirancang sebagai sistem operasi yang mendukung Carrier Grade. Fedora adalah salah satu sistem operasi Linux yang telah cukup lama dikenal. Fedora dikeluarkan oleh Fedora Project. Fedora Project adalah koleksi dari proyek-proyek yang disponsori oleh Red Hat dan dikembangkan sebagai kerja sama antara komunitas open source dan pengembang Red Hat. Fedora sendiri dikembangkan dengan tujuan meningkatkan perkembangan dari perangkat lunak yang sifatnya gratis dan open source.
1.2
Rumusan Masalah
Fedora sebagai salah satu sistem operasi yang bersifat gratis dan open source, tidak dirancang sebagai sistem operasi yang mendukung Carrier Grade, sehingga diperlukan pengajian lebih lanjut tentang kemungkinan pengembangan Fedora untuk memenuhi spesifikasi yang terdapat pada CGL. Masalah-masalah yang akan dikaji dalam tugas akhir ini adalah: 1. Spesifikasi-spesifikasi, yang ditetapkan oleh CGL aspek Cluster, apa saja yang dapat dipenuhi oleh Fedora 7. 2. Bagaimana cara/prosedur pengujian terdahap Fedora 7 untuk memenuhi spesifikasi yang diberikan oleh CGL. 3. Modul-modul apa saja yang dibutuhkan Fedora 7 agar dapat memenuhi spesifikasi CGL tersebut.
1.3
Tujuan
Tujuan utama tugas akhir ini adalah melakukan analisis terhadap Fedora 7 dalam memenuhi setiap requirements yang diberikan oleh CGL pada aspek Cluster.
I-3 1.4 Batasan Masalah
Batasan-batasan yang didefinisikan dalam pelaksanaan tugas akhir ini adalah: 1. Masalah pemenuhan requirements aspek Cluster pada Prioritas 1 dan Prioritas 2, akan tetapi akan lebih difokuskan pada beberapa requirements saja yang dianggap penting dan mudah untuk diuji. 2. 3. Carrier Grade Linux yang dipakai adalah versi 4.0. Pengujian dilakukan pada sistem operasi Fedora 7.
1.5
Metodologi
Dalam penyusunan tugas akhir ini digunakan metodologi berikut: 1. Studi Literatur Mempelajari sumber-sumber pustaka baik yang berupa buku (textbook), jurnal dan artikel ilmiah, maupun website yang berhubungan Carrier Grade Linux versi 4.0 dan Sistem Operasi Linux khususnya Fedora 7. 2. Analisis Penyelesaian Masalah dan Perancangan Pegujian Melakukan analisis terhadap masalah yang dikaji, mendefinisikan batasan-batasan dalam masalah tersebut, serta mencari solusinya. Analisis juga meliputi cara-cara yang akan dilakukan pada pengujian requirements. 3. Eksplorasi/Pengujian Standar CGL Melakukan pengujian-pengujian requirements CGL pada Fedora 7 sesuai dengan prosedur/cara yang telah direncanakan sebelumnya. Ekplorasi ini juga mencakup pendokumentasian hasil. 4. Analisis Hasil dan Penarikan Kesimpulan Analisis hasil dilakukan dengan membandingkan hasil pengujian dengan standarstandar CGL yang telah ditetapkan.
I-4 1.6 Sistematika Pembahasan
Sistematika penulisan laporan tugas akhir ini adalah sebagai berikut: 1. Bab I Pendahuluan, berisi penjelasan mengenai latar belakang, rumusan masalah, tujuan, batasan masalah, metodologi, serta sistematika pembahasan yang digunakan untuk menyusun laporan tugas akhir. 2. Bab II Dasar Teori, berisi tentang dasar teori yang digunakan dalam analisis, perancangan, dan implementasi tugas akhir. 3. Bab III Analisis dan Perancangan Teknik Pengujian , berisi analisis dan perancangan secara global mengenai teknik-teknik pengujian yang akan dilakukan dan rincian prosedur-prosedur pengujian yang akan dibagun sebagai dasar tahap yang akan dilaksanakan selanjutnya. 4. Bab IV Hasil Pengujian dan Pembahasan, berisi mengenai hasil pengujian dan analisis dari hasil pengujian pada sistem operasi Fedora 7. 5. Bab V Penutup, berisi kesimpulan dan saran yang didapatkan selama pelaksanaan tugas akhir.
BAB II Dasar Teori
Pada bab ini, akan dibahas hal-hal yang berhubungan dengan pengerjaan tugas akhir ini. Dasar teori yang akan dibahas akan dapat memberikan pemahaman tentang CGL yang akan lebih difokuskan pada aspek Cluster. Dasar teori yang akan dibahas adalah mengenai konsep-konsep dasar dan perangkat lunak yang berguna untuk mempermudah proses analisis dan perancangan pengujian yang akan dilakukan pada tahap berikutnya.
2.1
Carrier Grade Linux
Carrier Grade Linux adalah sekumpulan spesifikasi yang dibangun oleh Open Source Development Lab (OSDL). Suatu sistem operasi Linux yang dapat memenuhi spesifikasi tersebut dapat dikatakan sebagai Carrier Grade Operating System. Carrier Grade adalah suatu istilah untuk sistem yang didesain untuk meningkatkan availability dan performance, yang dibutuhkan pada elemen jaringan komunikasi modern. Sejak tahun 2002, CGL mulai berkembang. Sejumlah perwakilan dari kalangan pengembang Linux, penyedia perlengkapan jaringan, industri telekomunikasi berkumpul dan mencoba mendefinisikan bagaimana CGL dapat membentuk suatu lingkungan dengan tingkat availability, serviceability, dan scalability yang tinggi. Oleh karena itu, terbentuklah OSDL CGL working group, dan sejak terbentuknya kelompok kerja tersebut, mereka telah menghasilkan tiga versi utama untuk mendefinisikan kebutuhan tersebut. Versi terbaru dari CGL saat ini adalah versi ke4, sedangkan versi ke-5 masih dalam tahap pembuatan. Spesifikasi yang terdapat pada CGL versi 4 merupakan superset dari spesifikasi CGL 3.2, namun ada beberapa requirement, yang tidak dibutuhkan, dihilangkan. Pada CGL 4.0 ini diperkenalkan 3 jenis prioritas, yaitu: 1. 2. Prioritas 1 (P1), berisi requirements yang bersifat wajib. Prioritas 2 (P2), berisi requirements yang bersifat opsional. II-1
II-2 3. Prioritas 3 (P3), berisi requirements yang bersifat rencana dan dalam tahap pengembangan serta tidak diwajibkan. CGL 4.0 dibagi menjadi 7 aspek requirements, yaitu: 1. Availability, mendeskripsikan tentang fungsionalitas yang dibutuhkan untuk availability dan recovery pada 1 node saja. 2. Cluster, mendeskripsikan komponen-komponen yang dibutuhkan untuk
membangun suatu cluster dengan tingkat availability yang tinggi. Load balancing dan performance adalah tujuan kedua. 3. Serviceability, mendeskripsikan fitur-fitur yang dibutuhkan untuk pelayanan dan perawatan sistem dan mencakup tools yang mendukungnya. 4. Performance, mendeskripsikan fitur-fitur yang dibutuhkan dalam membantu performansi sistem, misalnya real-time requirements. 5. Standards, menyediakan referensi terhadap API, spesifikasi, standar yang dibutuhkan seperti POSIX, IETF, dan SA Forum. 6. Hardware, mendeskripsikan spesifikasi-spesifikasi perangkat keras yang
dibutuhkan yang berkaitan dengan lingkungan operasi carrier. 7. Security, mendeskripsikan fitur-fitur yang diperlukan untuk membangun sistem yang aman. Sampai saat dokumen ini ditulis, CGL 4.0 masih dalam proses menunggu pendaftaran pengembang-pengembang yang ingin mendaftarkan produknya sebagai salah satu produk yang memenuhi standar-standar yang telah ditetapkan dalam CGL 4.0.
2.1.1
CGL 4.0 Cluster
Cluster komputer adalah grup atau sekelompok komputer yang saling bekerjasama dan seakanakan terlihat sebagai satu komputer. Tiap node saling terhubung dan berkomunikasi dalam Local Area Network. Cluster biasanya dibangun untuk meningkatkan performance dan/atau tingkat availability melebihi kemampuan yang disediakan oleh satu komputer.
II-3 Salah satu aspek penting yang harus dimiliki suatu sistem operasi agar dapat dianggap sebagai Carrier Grade Operating System adalah aspek Cluster, dimana aspek ini dibutuhkan untuk membangun suatu cluster yang memiliki tingkat availability yang tinggi. Tujuan utama adanya cluster ini adalah agar dapat meningkatkan hasil produksi, meningkatkan ketersediaan produk dan layanan, meningkatkan perawatan produk, dan mengefisiensi biaya. Teknologi cluster dapat dibagi menjadi beberapa tipe yang mempunyai tujuan yang berbedabeda, yaitu: 1. High Availability Cluster (HAC) Di implementasikan secara khusus untuk meningkatkan availability dari layanan yang disediakan. Beroperasi dengan menggunakan redundant nodes, yang berguna untuk menyediakan layanan ketika terjadi kerusakan pada node lainnya. 2. 3. 4. Scalability Cluster Server Consolidation Cluster High Performance Computing (HPC) Berfokus untuk mengembangkan supercomputer, parallel process algorithms, dan related software. HPC biasanya digunakan untuk menyelesaikan permasalahan yang besar, misalnya desain produk, riset, mempelajari lingkungan (prediksi cuaca dan geologi), image processing, dll. Dengan adanya beberapa tipe cluster ini dan kebutuhan akan tingkat availabilitas yang tinggi, akhirnya OSDL memutuskan bahwa CGL 4.0 aspek Cluster akan lebih difokuskan pada High Availability Cluster (HAC) dan kemudian akan meluas pada beberapa tipe cluster lainnya[4]. Untuk memenuhi beberapa kebutuhan pada aspek cluster ini, akan dibahas lebih lanjut mengenai High Availability Cluster.
2.2
High Availability Cluster
High Availability Clusters (lebih dikenal sebagai HA Clusters atau Failover Clusters) adalah cluster komputer yang diimplementasikan dengan tujuan utama untuk meningkatkan availabilitas layanan yang disediakan cluster tersebut. HA Cluster beroperasi dengan menggunakan banyak
II-4 komputer dimana komputer-komputer tersebut berguna untuk menyediakan layanan ketika suatu sistem komputer mengalami crash. Secara normal, apabila suatu server mengalami crash, maka layanan yang disediakan server tersebut akan terhenti sampai server tersebut diperbaiki. HA Cluster melakukan hal ini dengan cara mendeteksi perangkat keras/lunak yang salah atau error, dan menjalankan ulang aplikasi atau program tersebut sesegera mungkin tanpa membutuhkan administrative intervention, proses ini dikenal sebagai Failover. Sebagai bagian dalam proses ini, program cluster akan mengkonfigurasi node/komputer sebelum memulai menjalankan aplikasi. HA cluster biasanya menggunakan Heartbeat private network connection1 dimana digunakan untuk memonitor kondisi dan status tiap node dalam cluster, jadi tiap node pada cluster terhubung dalam satu jaringan tertentu, namun Heartbeat juga dapat memonitor kondisi dan status tiap node tanpa menggunakan private network connection, melainkan dengan melakukan broadcast, misalnya pada eth0. Dengan demikian, tiap server dapat saling berkomunikasi tanpa menggunakan jaringan tersendiri. Tiap perangkat lunak (software) clustering harus dapat menangani kejadian yang disebut split -brain. Split-brain terjadi ketika semua komunikasi antar node terputus secara bersamaan, akan tetapi setiap node dalam cluster tersebut masih berjalan. Jika hal ini terjadi, tiap node dalam cluster akan salah memutuskan bahwa tiap node lainnya telah mati (down) dan mencoba untuk menjalankan aplikasi layanan ( service) yang sebenarnya masih dijalankan oleh node lain. Terjadinya duplikasi service dapat menyebabkan data yang disimpan pada shared storage menjadi rusak (corrupt). Program yang dipakai dalam membuat model High Availability Cluster ini adalah Heartbeat, dan beberapa bagian penting yang akan dibahas lebih lanjut dalam dokumen ini adalah mengenai Availability Framework, Fault Handling, dan Management.
2.2.1
Availability Framework
2.2.1.1 Ethernet Ethernet pada mulanya berdasarkan pada ide komunikasi komputer melalui coaxial cable yang bekerja sebagai medium transmisi broadcast. Metode yang dipakai terlihat sedikit mirip dengan
1
Jaringan khusus antara server-server yang menggunakan Heartbeat
II-5 sistem radio, walaupun terdapat beberapa prinsip yang berbeda, misalnya komunikasi dengan menggunakan kabel akan lebih mudah dalam mendeteksi tabrakan ( collision) dibandingkan dengan sistem radio. Pada saat ingin mengirimkan paket, komputer melakukan sensing pada medium/kabel terlebih dahulu untuk mengetahui apakan medium tersebut sedang digunakan atau tidak. Jika 2 komputer mengirim bersama pada satu medium, maka akan terjadi tabrakan (collision) yang dapat dideteksi oleh masing-masing komputer, oleh karena itu perlu aturanaturan yang mengatur cara pengiriman pada suatu medium.
2.2.1.2 Ethernet MAC Address Takeover Media Access Control address (MAC address) adalah suatu identifikasi yang unik yang terdapat pada network adapter. MAC address atau dapat disebut juga sebagai Ethernet Hardware Address (EHA) adalah suatu angka hexa-desimal yang digunakan sebagai nama pada suatu network adapter, misalnya dalam sebuah komputer ada lebih dari 1 ethernet adapter, maka ethernet adapter tersebut akan mempunyai MAC address yang berbeda. Namun, saat ini MAC address dapat diubah, hal ini disebut MAC spoofing. MAC address terdiri dari 2 bagian, 6 digit awal dari MAC address mengandung nomer ID dari pembuat ethernet tersebut, sedangkan 6 digit akhir merepresentasikan nomer serial yang ditentukan ke ethernet oleh pembuat (pabrikan). TCP/IP dan arsitektur jaringan pada umumnya mengadopsi OSI (Open Systems Interconnection) model. Dalam model ini, fungsionalitas jaringan dibagi menjadi beberapa lapisan ( layer). MAC address berperan pada lapisan Data Link (layer 2). MAC address bekerja dalam mendukung implementasi hardware pada network stack. Pada OSDL CGL CAF. 2.1. disyaratkan bahwa sistem operasi harus memiliki mekanisme untuk memprogram dan mengumumkan MAC address pada ethernet sehingga ketika terjadi suatu kejadian Software Failure, node lainnya (redundant node) akan mulai menerima traffic yang seharusnya mengarah ke node sebelumnya.
II-6 2.2.1.3 IP Takeover IP address adalah suatu alamat yang unik yang memungkinkan perangkat elektronik mengidentifikasi dan berkomunikasi dengan perangkat lainnya dalam suatu jaringan komputer yang menggunakan Internet Protocol (IP) standar. Setiap perangkat dalam suatu jaringan dapat memiliki alamat unik sendiri dengan lingkup tertentu. Pemberian alamat IP dapat dilakukan secara statis dan dinamis. Pemberian alamat secara statis adalah dengan menentukan secara manual alamat IP oleh pengguna komputer. Namun ada kemungkinan alamat IP yang digunakan tidak bisa dipakai untuk berkomunikasi dalam jaringan komputer karena telah digunakan oleh perangakat/komputer lain, atau alamat tersebut di luar subnet/lingkup yang ditentukan dalam jaringan komputer tersebut. Cara lain dalam menentukan alamat IP adalah dengan pemberian alamat secara dinamis atau yang lebih dikenal dengan istilah Dynamic Host Configuration Protocol (DHCP). Berbeda dengan cara statis, alamat IP yang didapatkan dengan cara dinamis bisa dilakukan secara acak atau ditentukan oleh server di jaringan komputer tersebut. Pada OSDL CGL CAF.2.2. disyaratkan bahwa sistem operasi harus memiliki mekanisme untuk memprogram dan mengumumkan IP address sehingga ketika terjadi suatu kejadian Software Failure, redundant node akan mulai menerima traffic yang seharusnya untuk node yang mengalami failure.
2.2.2
Fault Handling
2.2.2.1 Cluster Node Failure Detection Dalam clustering, salah satu hal yang penting adalah mendeteksi failure node. Dengan adanya mekanisme deteksi failure node ini, maka aksi selanjutnya akan dapat dijalankan. Tiap node dalam cluster berkomunikasi menggunakan jaringan privat, semakin banyak (sering) tingkat komunikasi dalam jaringan, maka akan semakin cepat dalam mendeteksi node yang mengalami failure, namun hal ini dapat memberatkan jaringan dengan traffic yang tinggi.
II-7 Pada OSDL CGL CFH. 1.0. disyaratkan bahwa carrier grade Linux sebaiknya menyediakan mekanisme deteksi failure node berbasis komunikasi yang cepat. Setidaknya, mekanisme failure node mengelola daftar node yang sedang aktif dalam cluster. Perubahan dalam keanggotaan cluster harus dapat dimonitor oleh cluster service, aplikasi, dan middleware yang telah terdaftar untuk dinotifikasi bila terjadi perubahan event keanggotaan. Failure detection pada node dengan cepat harus tidak bergantung pada laporan failure suatu node. Namun, self-diagnosis sebaiknya ditingkatkan untuk meningkatkan kecepatan
pendeteksian failure dalam cluster. Node failure detection dengan cepat sebaiknya memiliki kapabilitas sebagai berikut: Kemampuan untuk menyediakan health monitoring anggota cluster melalui mekanisme komunikasi Mendukung multiple, redundant jalur komunikasi untuk memeriksa kesehatan node cluster Mendukung failure detection dengan cepat Kemampuan untuk menyediakan pergantian kejadian ( event) anggota cluster ke aplikasi Node failure detection dalam cluster ini sebaiknya hanya menggunakan persentase bandwidth yang kecil untuk memonitor kesehatan anggota cluster.
2.2.2.2 Aplication Fail-Over Enabling High availability cluster sangat erat hubungannya dengan peningkatan service availability yang disediakan. Untuk meningkatkan service availability, cluster harus memiliki mekanisme aplikasi fail-over. Setelah mendeteksi failure node, maka aksi yang selanjutnya dilakukan adalah memulai aplikasi atau service yang disediakan oleh node sebelumnya ke node yang lain karena node tersebut mengalami kerusakan atau failure. Dengan adanya mekanisme ini, layanan yang diberikan/disediakan akan tetap tersedia, karena layanan yang disediakan oleh node yang mengalami failure diambil alih node lain yang menjadi back-up node.
II-8 Pada OSDL CGL CFH. 3.0 disyaratkan bahwa carrier grade Linux sebaiknya menyediakan mekanisme untuk melakukan fail-over suatu aplikasi dalam cluster dari node yang satu ke node lainnya. Aplikasi dan node dimonitor dan mekanisme failover dilakukan ketika suatu failure terdeteksi. Ketika failure tersebut terdeteksi, mekanisme fail-over aplikasi harus memutuskan aturan apa yang harus dilakukan untuk skenario fail-over ini dan selanjutnya memulai proses untuk menjalankan aplikasi atau melakukan inisiasi untuk menghidupkan kembali aplikasi dalam waktu 1 detik. Waktu yang diperlukan dalam melakukan mekanisme fail-over ini bergantung pada failure detection pada aplikasi atau node, waktu untuk menjalankan aturan fail-over, dan waktu untuk menjalankan atau memulai kembali aplikasi yang gagal tersebut. Waktu fail-over total untuk suatu aplikasi harus mengijinkan cluster untuk mengelola availability aplikasi carrier grade.
2.2.3
Membership Service
2.2.3.1 Dynamic Cluster Membership Dalam suatu cluster, tiap node dapat berkomunikasi melalui jaringan. Node tersebut hanya dapat berkomunikasi dengan node lainnya yang telah terdaftar dalam keanggotaan ( membership) pada cluster tersebut. Dengan mengetahui anggota tersebut, maka tiap node dapat mengirim pesan ke IP address node tujuan. Agar komunikasi tersebut dapat berlangsung, maka tiap node harus didaftarkan terlebih dahulu sesuai dengan u-name-nya (nama sistem) dan IP addressnya. Untuk dapat mengetahui bahwa node tersebut adalah anggota dari suatu cluster, maka tiap node harus memiliki satu kata sandi yang sama, dengan kata sandi tersebut tiap node dapat mengotentikasi node lainnya. Selain dengan mendaftarkan node terlebih dahulu pada konfigurasi awal, node baru dapat ditambahkan dalam keanggotaan cluster secara dinamis. Penambahan node secara dinamis ini dilakukan dengan cara mengotentikasi node baru dengan kata sandi yang dimiliki oleh cluster tersebut. Node yang terotentikasi akan menjadi bagian dari anggota cluster tanpa harus didaftarkan pada konfigurasi awal.
II-9 Pada OSDL CGL CMS. 2.0 disyaratkan bahwa carrier grade Linux sebaiknya menyediakan kemampuan untuk menambah node baru (dengan IP address baru) pada suatu cluster secara dinamis, tanpa konfigurasi awal sebagai bagian dari anggota cluster.
2.2.4
Management
2.2.4.1 Cluster-Wide Kernel Crash Dump Dalam cluster, terjadinya kegagalan ( failure) pada suatu node mungkin saja dikarenakan terjadinya kerusakan (crash) pada kernel. Pada OSDL CGL CDIAG. 2.2 disyaratkan bahwa sistem operasi harus dapat menyediakan cluster-aware kernel crash dump yang secara unik mengidentifikasi node/komputer mana yang menghasilkan crash dump. Misalnya, apabila suatu node mengalami crash, maka node tersebut akan menghasilkan crash dump pada network storage, data tersebut akan diidentifikasi secara unik sebagai data yang berasal dari node yang mengalami crash tersebut.
2.3
Kakas
Kakas yang akan digunakan dalam pengerjaan Tugas Akhir ini adalah sebagai berikut: 2.3.1 Heartbeat
Heartbeat adalah komponen inti dari Linux-HA project. Heartbeat adalah opensource software untuk melakukan HA Cluster. Heartbeat merupakan software yang dapat berjalan pada sistem operasi berbasis unix, walaupun platform utama adalah Linux, namun Heartbeat telah di-compile dan dapat berjalan pada sistem operasi BSD, Solaris, dan AIX. Dengan adanya Heartbeat, pembangunan HA Cluster menjadi lebih mudah. Dalam Heartbeat versi 2, telah ditambahkan fitur untuk monitoring resource untuk lokal maupun cluster. Dengan adanya Cluster Resource Management (CRM), administrator jaringan dapat memonitor node yang aktif maupun yang pasif pada cluster dan service yang sedang berjalan. Heartbeat dapat
II-10 memonitoring anggota cluster yang aktif, pasif, maupun yang sedang mati. Hampir semua kebutuhan untuk membangun HA Cluster dimiliki oleh program ini. Heartbeat juga dilengkapi dengan Heartbeat-GUI untuk mempermudah dalam melakukan konfigurasi aplikasi atau service pada tiap node. Heartbeat dapat digunakan pada Database server, Web server, File server, DNS server, DHCP server, dll. Heartbeat memiliki dokumentasi yang cukup singkat, oleh karena itu diperlukan eksplorasi yang lebih banyak untuk mengetahui fitur-fitur dan kemampuan yang dimiliki Heartbeat. Kurangnya contoh-contoh kasus dan penjelasan-penjelasan mengenai cara konfigurasi dalam dokumentasi Heartbeat merupakan salah satu kendala dalam mengerjakan tugas akhir ini. Penulis membutuhkan waktu yang banyak untuk melakukan eksplorasi dan percobaan-percobaan mengenai Heartbeat, sehingga dapat memakai beberapa fitur yang dimiliki Heartbeat untuk melakukan pengujian-pengujian terhadap Fedora 7.
2.3.2
Linux Kernel Crash Dump
Linux Kernel Crash Dump (LKCD) adalah sebuah sekumpulan kernel patch dan utility yang dapat melakukan pencatatan kernel memory pada catatan kejadian (event) dari kernel panic. Kenel image yang tersimpan menjadi bukti forensik pada kernel panic yang memungkinkan dengan menggunakan fitur-fitur yang tersedia dalam package LKCD. Sistem operasi Unix yang komersial sebagaian besar telah menyediakan fitur-fitur/alat-alat (utilities) penanganan crash yang mirip seperti kemampuan yang dimiliki LKCD, akan tetapi package ini termasuk baru untuk Linux dan harus ditambahkan secara manual. LKCD memiliki dokumentasi yang cukup baik, karena dilengkapi dengan penjelasan fitur dan cara instalasi patch LKCD. Fedora 7 memiliki kernel 2.6.21 sedangkan patch LKCD yang terbaru adalah untuk kernel versi 2.6.10, oleh karena perlu dilakukan downgrade Fedora 7 untuk meng-install patch LKCD tersebut pada versi kernel 2.6.10. Penulis membutuhkan waktu yang sangat banyak untuk meng-compile kernel dan menambahkan patch LKCD karena banyak kegagalan yang terjadi. Pada akhirnya, penulis gagal meng-compile dan menambahkan patch
II-11 LKCD pada kernel 2.6.10, sehingga pengujian Cluster-Wide Kernel Crash Dump tidak dapat dilakukan dengan menggunakan LKCD.
2.3.3
Netdump dan Netdump-server
Netdump adalah suatu protocol sederhana yang berjalan menggunakan UDP dimana berfungsi untuk mengirim kernel core memory images ke remote server pada saat terjadi crash. Netdump digunakan secara utama pada Red Hat Enterprise Linux 4 dan sistem sebelumnya, akan tetapi distribusi lain pun ada yang telah menggunakan protocol ini. Netdump digunakan pada client, sedangkan Netdump-server bertugas menerima dump dari client yang telah menjalankan service Netdump dengan menggunakan port 6666 secara default. Netdump yang dijalankan pada sisi client harus mendaftar ke server yang menjalankan service netdump-server agar dapat melakukan dump ke server yang dituju. Untuk dapat menjalankan service netdump, perlu dilakukan konfigurasi awal, yaitu mendefinisikan IP address server yang berperan sebagai network storage. Netdump dan Netdump-server memiliki dokumentasi yang sangat singkat dan referensi yang sedikit. Pada dokumentasi netdump, hanya terdapat penjelasan singkat dan cara menjalankan service netdump. Namun, dokumentasi tidak dilengkapi dengan permasalahan-permasalahan yang terjadi saat menjalankan service netdump dan netdump-server. Sehingga diperlukan waktu yang cukup banyak dalam melakukan eksplorasi mengenai netdump. Referensi-referensi yang ada tidak cukup membantu untuk menyelesaikan permasalahan yang terjadi. Pada akhirnya, service netdump yang dijalankan pada sisi client tidak dapat berjalan karena terdapat error karena terdapat konflik dengan kernel Fedora 7, sedangkan netdump-server dapat berjalan dengan baik tanpa adanya permasalahan yang berarti.
2.3.4
Performance Co-Pilot
Performance CO-Pilot merupakan salah satu proyek opensource dari SGI. SGI sendiri merupakan pengembang perangkat lunak yang berkantor pusat di California, Amerika Serikat.
II-12 PCP memungkinkan melakukan monitoring terpusat untuk host yang berbeda-beda pada suatu jaringan. PCP menyediakan framework dan layanan untuk mendukung system-level performance monitoring dan performance management. Layanan yang ditawarkan oleh PCP menarik untuk mengatasi permasalahan sistem yang lebih kompleks. PCP memberikan layanan manajemen performansi pada sistem dalam skala besar, menkorelasikan end-user QOS dengan aktivitas platform. Fokus dari PCP adalah performansi pada level sistem, dimana PCP juga berkontribusi beberapa aspek: Sistem pada perangkat keras Sistem operasi, termasuk kernel Aplikasi end-user Jaringan Multiple host (client-server, dsb)
PCP juga dilengkapi dengan pcmchart, sehingga dapat menampilkan diagram mengenai resource yang dimonitor. PCP memiliki dokumentasi yang lengkap, dan dokumentasi PCP terbagi menjadi 2, yaitu dokumentasi tentang penggunaan PCP sebagai pengguna dan administrator dan panduan penggunaan PCP untuk programmer, yaitu untuk melakukan pengembangan PCP lebih lanjut. Oleh karena itu, tidak banyak waktu yang dibutuhkan untuk melakukan eksplorasi dan pemahaman mengenai PCP. Waktu tersebut dibutuhkan untuk membaca dokumentasi, mengerti, dan melakukan percobaan-percobaan untuk mengetahui fitur mana yang dapat digunakan dalam menunjang tugas akhir ini.
BAB III Analisis dan Perancangan Kasus Uji
Pada bab ini, akan dibahas mengenai analisis dan perancangan teknik-teknik pengujian yang akan dilakukan dan rincian prosedur-prosedur pengujian yang akan dibagun untuk analisis pemenuhan CGL Cluster pada Fedora 7.
3.1
Spesifikasi Pengujian
Dalam pengujian yang akan dilakukan, requirements yang akan diuji antara lain: 1. 2. 3. 4. 5. 6. Ethernet MAC Address Takeover (CAF 2.1) IP Takeover (CAF 2.2) Cluster Node Failure Detection (CFH 1.0) Application Failover Enabling (CFH 3.0) Dynamic Cluster Membership (CMS 2.0) Cluster-Wide Kernel Crash Dump (CDIAG 2.2)
Dalam pengerjaan Tugas Akhir ini, hanya akan diuji 6 requirements di atas karena dianggap penting dan mudah untuk diuji dan analisis. Pada aspek cluster ini, masih terdapat 11 requirements lagi, untuk lebih jelasnya dapat dilihat pada Lampiran A. Pengujian akan dilakukan pada perangkat lunak sebagai berikut: 1. Sistem operasi Fedora 7 dengan kernel 2.6.21-1.264.fc7 yang dirilis resmi pada repositori Fedora Project. 2. Heartbeat-2.0.8 yang merupakan perangkat lunak yang digunakan untuk membangun High Availability Cluster. 3. PCP-2.7.8-20090217 yang merupakan perangkat lunak yang digunakan untuk memonitor resource pada node dalam cluster dalam Tugas Akhir ini. 4. 5. Linux Kernel Crash Dump untuk melakukan dump pada network storage. Netdump dan Netdump-server untuk melakukan dump pada network storage. III-1
III-2 3.1.1 Rancangan Sistem yang Dibangun
Gambar III-1 Rancangan Sistem
Rancangan sistem yang akan dibangun terdiri dari 3 server, server A yang menjadi server aktif dan server B yang menjadi server pasif yang akan ditambahkan secara dinamis dan Server C yang juga akan ditambahkan secara dinamis. Server A akan menjadi server yang berjalan pertama kali, sedangkan server B dan server C hanya standby dan menjadi back-up saat server A mati. Tiap node berkomunikasi dan saling terhubung menggunakan eth0.
3.1.4
Kode Kasus Uji
Pembahasan tiap kasus uji yang dilakukan, diurutkan berdasarkan ID standar requirement yang telah ditentukan. Kode Kasus Uji ini memiliki format yaitu:
T_<Aspek>_<ID>_<No>
III-3 Keterangan: T : Kasus Uji
<Aspek> : Kode aspek yang diuji, misalnya CAF, CFH, dan CDIAG <ID> <No> : ID standar requirement : Nomor kasus uji
3.2
Ethernet MAC Address Takeover CAF 2.1
Spesifikasi CAF 2.1 berkaitan tentang implementasi MAC address takeover yang merupakan prioritas 1 memiliki deskripsi sebagai berikut: Description: OSDL CGL specifies a mechanism to program and announce MAC addresses on Ethernet interfaces so that when a SW Failure event occurs, redundant nodes may begin receiving traffic for failed nodes. Berdasarkan deskripsi di atas, dapat dianalisis bahwa sistem operasi yang mendukung requirement ini harus dapat melakukan takeover MAC address. Maka skenario tes uji yang akan dilakukan adalah sebagai berikut:
3.2.1
Kasus Uji T_CAF_2.1_01
Pada kasus uji ini, akan dilakukan tes untuk mekanisme MAC address takeover pada eth0. Pengujian ini dilakukan dengan mematikan salah satu node. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. Lakukan konfigurasi IP eth0 pada tiap node. Periksa MAC address pada kedua node. Matikan salah satu node (dengan asumsi terjadi crash node tersebut). Periksa MAC address node lainnya.
III-4 Pengujian ini dikatakan berhasil apabila terjadi MAC address takeover, yaitu MAC address node yang masih aktif sama dengan MAC address node yang mati ketika node tersebut dalam keadaan aktif.
3.2.2
Pada kasus uji ini, akan dilakukan tes untuk mekanisme MAC address takeover pada eth0. Pengujian ini dilakukan dengan memutuskan hubungan node dengan mencabut kabel LAN atau mematikan eth0. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. Lakukan konfigurasi IP eth0 pada tiap node. Periksa MAC address pada kedua node. Non-aktifkan interface eth0. Periksa MAC address node lainnya.
Pengujian ini dikatakan berhasil apabila terjadi MAC address takeover, yaitu MAC address node 1 sama dengan MAC address node 2.
3.3
IP Takeover CAF 2.2
Spesifikasi CAF 2.2 berkaitan tentang implementasi IP address takeover yang merupakan prioritas 1 memiliki deskripsi sebagai berikut: Description: OSDL CGL specifies a mechanism to program and announce IP addresses (using gratuition ARP) so that when a Software Failure event occurs, redundant nodes may begin receiving traffic for failde nodes. Berdasarkan deskripsi di atas, dapat dianalisis bahwa sistem operasi yang mendukung requirement ini harus dapat melakukan takeover IP address. Jadi akan dilakukan percobaan pada 2 node, salah satu node akan dinon-aktifkan untuk melihat apakah terjadi IP Takeover. Maka skenario tes uji yang akan dilakukan adalah sebagai berikut:
III-5 3.3.1 Kasus Uji T_CAF_2.2_01
Pada kasus uji ini, akan dilakukan tes untuk mekanisme IP address takeover pada eth0. Pengujian ini dilakukan dengan mematikan salah satu node. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. Lakukan konfigurasi IP eth0 pada tiap node. Periksa IPaddress pada kedua node. Matikan salah satu node (dengan asumsi terjadi crash node tersebut). Periksa IP address node lainnya.
Pengujian ini dikatakan berhasil apabila terjadi IP address takeover, yaitu IP address node yang masih aktif sama dengan IP address node yang mati ketika node tersebut dalam keadaan aktif.
3.3.2
Pada kasus uji ini, akan dilakukan tes untuk mekanisme IP address takeover pada eth0. Pengujian ini dilakukan dengan memutuskan hubungan node dengan mencabut kabel LAN atau mematikan eth0. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. Lakukan konfigurasi IP eth0 pada tiap node. Periksa IP address pada kedua node. Non-aktifkan interface eth0. Periksa IP address node lainnya.
Pengujian ini dikatakan berhasil apabila terjadi IP address takeover, yaitu IP address node 1 sama dengan IP address node 2.
3.4
Cluster Node Failure Detection CFH 1.0
Spesifikasi CFH 1.0 berkaitan tentang implementasi Cluster Node Failure Detection, yang merupakan prioritas 2 memiliki deskripsi sebagai berikut:
III-6 Description: OSDL CGL specifies that carrier grade Linux shall provide a fast, communicationbased cluster node failure mechanism that is reflected in a cluster membership service. At a minimum, the cluster node failure mechanism maintains a list of the nodes that are currently active in the cluster. Changes in cluster membership must result in a membership event that can be monitored by cluster services, applications, and middleware that register to be notified of membership events. Fast node failure detection shall include the following capabilities: Ability to provide cluster membership health monitoring through cluster communication mechanisms. Support for multiple, redundant communication paths to check the health of cluster nodes. Support for fast failure detection. The guideline is a maximum of 250ms for failure detection. Since there is tradeoff between fast failure detection and potentially false failures, the health-monitoring interval must be tunable. Ability to provide a cluster-membership change event to middleware and applications. Berdasarkan deskripsi tersebut di atas, dapat dianalisis bahwa suatu sistem operasi yang mendukung Cluster Node Failure Detection harus dapat memenuhi syarat sebagai berikut: a. Menyediakan fasilitas monitoring kesehatan anggota cluster, jadi akan dilakukan pengujian untuk memonitor resource anggota cluster. Pengujian pada poin ini akan dilakukan dengan menggunakan PCP. b. Mendukung multiple, redundant jalur komunikasi untuk memeriksa status kesehatan node c. Mendukung deteksi kegagalan dengan cepat. Untuk mendeteksi kegagalan, digunakan Heartbeat yang dijalankan pada 2 node dan akan dilakukan percobaan dengan memutuskan hubungan antar node dengan asumsi salah satu node mati, dan dilakukan pengukuran waktu yang dibutuhkan.
III-7 d. Menyediakan kemampuan untuk melakukan perubahaan keanggotaan cluster kepada middleware dan aplikasi Untuk melakukan monitoring, penulis menggunakan PCP. PCP terlebih dahulu dikonfigurasi dan dibuat rules agar dapat mengerti apa saja yang akan diperiksa dan monitoring seperti apa yang dibutuhkan. Berdasarkan syarat tersebut, dapat dibuat sejumlah kasus uji sebagai berikut:
3.4.1
Kasus Uji T_CFH_1.0_01
Pada kasus uji ini, akan dilakukan tes apakah PCP dapat memonitor node mengenai kondisi disk. Langkah pengujiannya adalah sebagai berikut: a. b. Jalankan service PCP pada tiap node. Jalankan script monitoring kondisi disk (Input Output).
Pengujian ini dikatakan berhasil apabila PCP dapat memonitor kondisi disk pada tiap node.
3.4.2
Pada kasus uji ini, akan dilakukan tes apakah PCP dapat memonitor node mengenai kondisi processor. Langkah pengujiannya adalah sebagai berikut: a. b. Jalankan service PCP pada tiap node. Jalankan script monitoring kondisi processor (CPU Utilization).
Pengujian ini dikatakan berhasil apabila PCP dapat memonitor kondisi processor pada tiap node.
3.4.3
Pada kasus uji ini, akan dilakukan tes apakah PCP dapat memonitor node mengenai kondisi memory. Langkah pengujiannya adalah sebagai berikut: a. Jalankan service PCP pada tiap node.
III-8 b. Jalankan script monitoring kondisi memory (Memory Usage).
Pengujian ini dikatakan berhasil apabila PCP dapat memonitor penggunaan memory pada tiap node.
3.4.4
Pada kasus uji ini, akan dilakukan tes apakah PCP dapat memonitor node mengenai Network Interface Card. Langkah pengujiannya adalah sebagai berikut: a. Jalankan service PCP pada tiap node. b. Jalankan script monitoring kondisi network interface. Pengujian ini dikatakan berhasil apabila PCP dapat memonitor network interface pada tiap node.
3.4.5
Pada kasus uji ini, akan dilakukan tes untuk mekanisme Node Failure Detection. Pengujian ini dilakukan dengan mematikan salah satu node dan melihat apakah terjadi deteksi kegagalan node. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. Periksa apakah semua node tidak mati. Matikan salah satu node. Periksa apakah terjadi deteksi kegagalan. Hitung waktu yang dibutuhkan, konfigurasi ulang, dan uji lagi untuk mendapatkan hasil yang maksimal. Pengujian ini dikatakan berhasil apabila node yang gagal/mati dapat terdeteksi. Waktu yang dibutuhkan untuk deteksi kegagalan akan dicatat.
3.5
Application Failover Enabling CFH 3.0
III-9 Spesifikasi CFH 3.0 berkaitan tentang implementasi Application Failover yang merupakan prioritas 2 memiliki deskripsi sebagai berikut: Description: OSDL CGL specifies that carrier grade Linux shall provide mechanisms for failing over applications in a cluster from one node to another. Applications and nodes are monitored and a failover mechanism is invoked when a failure is detected. Once a failure is detected, the application failover mechanism must determine which policies apply to this failover scenario and then begin the process to start a standby application or initiate the re-spawn of an application within 1 second. The full application failover time is dependent upon application and node failure detection, the time to apply the failover policies, and the time it takes to start or restart the application. The aggregate failover time for an application must allow the cluster to maintain carrier grade application availability. Berdasarkan deskripsi di atas, dapat dianalisis bahwa sistem operasi yang mendukung requirement ini harus dapat melakukan application failover. Jadi akan dilakukan percobaan dengan mejalankan beberapa service pada salah satu node dan mematikan node tersebut untuk melihat apakah service yang dijalankan diambil alih oleh node yang lain. Dalam deskripsi di atas, dikatakan bahwa waktu yang dibutuhkan untuk menjalankan kembali service atau aplikasi tersebut adalah sekitar 1 detik. Namun, waktu tersebut juga bergantung pada . Maka skenario tes uji yang akan dilakukan adalah sebagai berikut:
3.5.1
Pada kasus uji ini, akan dilakukan tes untuk mekanisme Application Failover pada tiap node. Pengujian ini dilakukan dengan menjalankan sejumlah aplikasi/service kemudian mematikan salah satu node. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. Lakukan konfigurasi dan jalankan 1 service pada server A. Periksa apakah service tersebut berjalan dengan baik. Matikan server A. Periksa service pada server B.
III-10 Pengujian ini dikatakan berhasil apabila terjadi Application Failover, yaitu service yang dijalankan server A, dijalankan oleh server B ketika server A mati.
3.5.2
Pada kasus uji ini, akan dilakukan tes untuk mekanisme Application Failover pada tiap node. Pengujian ini dilakukan dengan menjalankan sejumlah aplikasi/service kemudian mematikan salah satu node. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. Lakukan konfigurasi dan jalankan 3 service pada server A. Periksa apakah service tersebut berjalan dengan baik. Matikan server A. Periksa service pada server B.
Pengujian ini dikatakan berhasil apabila terjadi Application Failover, yaitu service yang dijalankan server A, dijalankan oleh server B ketika server A mati.
3.6
Dynamic Cluster Membership CMS 2.0
Spesifikasi CMS 2.0 berkaitan tentang implementasi Dynamic Cluster Membership yang merupakan prioritas 2 memiliki deskripsi sebagai berikut: Description: OSDL CGL specifies that carrier grade Linux shall provide the ability to add a new node (with new IP address) to the cluster dynamically without pre-configuration as part of membership. Berdasarkan deskripsi di atas, dapat dianalisis bahwa sistem operasi yang mendukung requirement ini harus dapat melakukan registrasi anggota cluster baru hanya dengan mengonfigurasi node baru. Maka skenario tes uji yang akan dilakukan adalah sebagai berikut:
III-11 3.6.1 Kasus Uji T_CMS_2.0_01
Pada kasus uji ini, akan dilakukan tes untuk mekanisme Dynamic Cluster Membership pada tiap cluster. Pengujian ini dilakukan dengan mengkonfigurasi node baru dan memeriksa apakah node tersebut telah menjadi anggota cluster. Langkah pengujiannya adalah sebagai berikut: a. b. c. Periksa keanggotaan cluster. Lakukan konfigurasi 1 node baru. Periksa keanggotaan cluster, apakah node baru telah menjadi anggota.
Pengujian ini dikatakan berhasil apabila node yang baru dikonfigurasi dan sebelumnya bukan anggota cluster menjadi anggota dalam cluster.
3.6.2
Kasus Uji T_CMS_2.0_02
Pada kasus uji ini, akan dilakukan tes untuk mekanisme Dynamic Cluster Membership pada tiap cluster. Pengujian ini dilakukan dengan mengkonfigurasi node baru dan memeriksa apakah node tersebut telah menjadi anggota cluster. Langkah pengujiannya adalah sebagai berikut: a. b. c. Periksa keanggotaan cluster. Lakukan konfigurasi 2 node baru (menggunakan virtual machine). Periksa keanggotaan cluster, apakah node baru telah menjadi anggota.
Pengujian ini dikatakan berhasil apabila node yang baru dikonfigurasi dan sebelumnya bukan anggota cluster menjadi anggota dalam cluster.
3.7
Cluster-Wide Kernel Crash Dump CDIAG 2.2
Spesifikasi CDIAG 2.2 berkaitan tentang implementasi Cluster-Wide Kernel Crash Dump yang merupakan prioritas 1 memiliki deskripsi sebagai berikut: Description: OSDL CGL specifies that carrier grade Linux shall provide a cluster-aware kernel crash dump that uniquely identifies which node produced the crash dump. For
III-12 instance, if a diskless node dumps crash data to network storage, the data will be uniquely identified as originating from that node. Berdasarkan deskripsi di atas, dapat dianalisis bahwa sistem operasi yang mendukung requirement ini harus dapat membuat dump pada network storage saat terjadi crash. Maka skenario tes uji yang akan dilakukan adalah sebagai berikut:
3.7.1
Kasus Uji T_CDIAG_2.2_01
Pada kasus uji ini, akan dilakukan tes untuk mekanisme Cluster-Wide Kernel Crash Dump. Pengujian ini dilakukan untuk mendapatkan dump pada network storage dengan membuat crash salah satu node lalu memeriksa dump pada node yang berperan sebagai penerima dump dari node yang mengalami crash. Langkah pengujiannya adalah sebagai berikut: a. b. c. d. e. Buat program kernelpanic yang membuat error kernel. Menjalankan service netdump-server pada node A. Menjalankan service netdump pada node B . Jalankan program kernelpanic. Periksa dump pada node A.
Pengujian ini dikatakan berhasil apabila node yang rusak membuat dump kerusakan kernel pada node A. 3.8 Kriteria Keberhasilan Pengujian
Berdasarkan perancangan-perancangan kasus-kasus uji di atas, dapat disederhanakan mengenai kriteria keberhasilan pengujian. Tabel III-3 berikut merinci kriteria tersebut:
Tabel III-1 Kriteria Keberhasilan
Kategori Ethernet MAC Address Takeover
Keterangan SUKSES mendapatkan MAC Address node yang mati GAGAL tidak melakukan Takeover MAC Address node yang dimaksud
III-13
T_CAF_2.1_02 mendapatkan MAC Address node yang mati mendapatkan IP Address node yang mati mendapatkan IP Address node yang mati dapat memonitor Disk (Storage) tiap node dapat memonitor Processor tiap node dapat memonitor Memory tiap node dapat memonitor NIC tiap node mendeteksi failure dan optimalisasi waktu berhasil melakukan 1 service Failover berhasil melakukan 3 service Failover berhasil menambahkan 1 node berhasil menambahkan 2 node berhasil melakukan dump pada shared storage tidak melakukan Takeover MAC Address node yang dimaksud tidak melakukan Takeover IP Address node yang dimaksud tidak melakukan Takeover IP Address node yang dimaksud gagal memonitor Disk tiap node gagal memonitor Processor tiap node gagal memonitor Memory tiap node gagal memonitor NIC tiap node tidak dapat mendeteksi failure pada suatu node gagal melakukan Failover gagal melakukan Failover berhasil menambahkan node berhasil menambahkan node dump pada lokal storage
IP Takeover
T_CAF_2.2_01
T_CAF_2.2_02
Cluster Node Failure Detection
T_CFH_1.0_01 T_CFH_1.0_02 T_CFH_1.0_03 T_CFH_1.0_04 T_CFH_1.0_05
Application Failover Enabling
T_CFH_3.0_01 T_CFH_3.0_02
Dynamic Cluster Membership
T_CMS_2.0_01 T_CMS_2.0_02
Cluster Wide Kernel Crash Dump
T_CDIAG_2.2_01
BAB IV HASIL PENGUJIAN DAN PEMBAHASAN
Pada bab ini, akan dibahas mengenai hasil pengujian dari kasus uji yang telah dibuat dan analisis hasil pengujian yang telah dilakukan.
4.1
Jalannya Pengujian
Pengujian dilakukan pada perangkat keras dengan spesifikasi sebagai berikut:

Tabel IV-1 Spesifikasi Hardware Server B (Server Pasif)
Perihal Type Processor Memory Storage Display Display Adapter Ethernet WLAN DVD/CD ROM
Spesifikasi / Keterangan Notebook Compaq Presario v3504TU Intel(R) Centrino Duo T7300 3072 MB DDR2 RAM 120 GB HDD 14.1 WXGA TFT LCD Mobile Intel(R) 965 358 MB VRAM Marvell Yukon 88E8039 PCI-E Fast Ethernet Controller Intel(R) Pro/Wireless 3945ABG DVD RW
Pengujian dilakukan dengan menggunakan 3 virtual machine yang menggunakan sistem operasi Fedora 7 dan saling terhubung. Selain itu, pengujian juga dilakukan pada Fedora 11, yaitu Fedora versi terbaru, sebagai perbandingan. Model sistem yang dibangun adalah sebagai berikut:
IV-1
IV-2
Gambar IV-1 Model Sistem
Pengujian dilakukan pada perangkat lunak sebagai berikut: 1. Sistem operasi Fedora 7 dengan kernel 2.6.21-1.264.fc7 yang dirilis resmi pada repositori Fedora Project. 2. Sistem operasi Fedora 11 dengan kernel 2.6.29.4-167.fc11.i686 yang dirilis resmi pada repositori Fedora Project. 3. 4. 5. Hearbeat-2.0.8, merupakan perangkat lunak untuk High Availability Cluster. PCP-2.7.8-20090217, merupakan perangkat lunak untuk melakukan monitoring. Linux Kernel Crash Dump (LKCD), perangkat lunak untuk melakukan penyimpanan crash dump pada network storage. 6. Netdump dan Netdump-server, perangkat lunak untuk melakukan penyimpanan crash dump pada network storage.
4.1.1
Ethernet MAC Address Takeover
Pengujian Ethernet MAC Address Takeover membutuhkan modul Heartbeat. Pengujian ini dilakukan dengan menjalankan service Heartbeat pada setiap node dan prosedur MAC Address
IV-3 Takeover. Setelah itu, salah satu node akan di-non-akitfkan dan diperiksa apakah prosedur MAC Address Takeover diambil alih oleh node lain dan MAC Address node tersebut berubah, Pengujian ini dilakukan untuk mengetahui apakah terjadi MAC Address Takeover sehingga MAC Address node yang berperan sebagai backup server memiliki MAC Address yang sama dengan node yang telah mati. Pengujian dilakukan dengan cara mematikan NIC node yang aktif.
4.1.2
IP Takeover
Pengujian IP Takeover membutuhkan modul Heartbeat. Pengujian dilakukan dengan menjalankan service Heartbeat dan prosedur IP Takeover. Pengujian ini dilakukan untuk mengetahui apakah terjadi IP Takeover, sehingga IP backup server mengambil alih IP node yang telah mati. Dalam pengujian ini, server A (10.0.0.1) menjalankan prosedur IP Takeover dan mengatur IP 10.0.0.5 sebagai IP shared dan server B (10.0.0.2) menjadi server backup yang akan mengambil alih proserdur tersebut. Pengujian dilakukan dengan melakukan ping sebanyak 50x pada IP shared, lalu memutuskan NIC pada server A tersebut. Setelah itu, IP node yang berperan menjadi backup server diperiksa, apakah terjadi IP Takeover, yaitu IP node tersebut sama dengan IP node yang mati.
4.1.3
Pengujian Cluster Node Failure Detection dilakukan dengan menjalankan service Heartbeat dan PCP. Pengujian ini dilakukan untuk memonitor kondisi resource tiap node dan mendeteksi failure pada saat node yang lain dimatikan. Pengujian dilakukan dengan menjalankan script bash untuk memonitor disk, memory, processor, dan network setiap node, dan mematikan salah satu node, lalu melihat apakah node yang masih aktif dapat mendeteksi node yang mati lalu mengkonfigurasi dan menguji kembali untuk mendapatkan hasil yang optimal, yaitu waktu yang lebih singkat dalam mendeteksi failure. Dalam hal ini, karena pengujian failure detection menggunakan Heartbeat, maka waktu tersingkat untuk mendeteksi failure adalah 3 detik, sedangkan yang diharapkan adalah 250ms.
IV-4
4.1.4
Pengujian Application Failover Enabling dilakukan dengan menjalankan service Heartbeat dan beberapa service lain. Pengujian dilakukan untuk mengetahui apakah terjadi Failover, sehingga backup server / node pasif mengambil alih service yang sebelumnya dijalankan oleh node aktif setelah node tersebut mati. Pengujian dilakukan dengan menjalankan beberapa service dan mematikan node aktif, yaitu node yang menjalankan service tersebut. Setelah terjadi mekanisme node failure detection, service tersebut akan diambil alih oleh node yang lain, dan mengukur waktu yang dibutuhkan untuk menjalankan service tersebut kembali.
4.1.5
Dynamic Cluster Membership
Pengujian Dynamic Cluster Membership dilakukan dengan menjalankan service Heartbeat dan mengkonfigurasi node baru. Pengujian ini dilakukan untuk mengetahui apakah node baru yang telah dikonfigurasi dapat dideteksi oleh node lain dalam cluster tanpa mengkonfigurasi ulang node lainnya. Sehingga, penambahan node dalam cluster dapat dilakukan kapan saja. Pengujian dilakukan dengan menjalankan service Heartbeat pada node baru dan menjalankan crm_mon (Cluster Resource Management Monitoring) untuk melihat perubahan setelah penambahan node. Pada awal pengujian, server A (10.0.0.1) menjalankan service Heartbeat, setelah berjalan dengan baik, server B (10.0.0.2) yang telah dikonfigurasi, ditambahkan menjadi anggota cluster dengan menjalankan service Heartbeat. Lalu mencatat waktu yang dibutuhkan untuk menambahkan 1 node. Setelah itu dilakukan lagi penambahan server C (10.0.0.3) ke dalam cluster.
4.1.6
Cluster-Wide Kernel Crash Dump
Cluster Wide Kernel Crash Dump dengan LKCD membutuhkan versi kernel 2.6.10 (versi tertinggi), sehingga tidak cocok dengan Fedora yang memiliki kernel 2.6.21. Patch LKCD terbaru tersebut tentu saja tidak dapat diimplementasikan pada Fedora 7. Pengujian dilakukan
IV-5 dengan menjalankan script bash untuk membuat kernel menjadi crash dan melihat dump yang dibuat, namun pada lokal storage, bukan shared storage. 4.2 Hasil Pengujian
Hasil pengujian kasus uji yang telah dibuat adalah sebagai berikut:
Tabel IV-2 Hasil Percobaan
Kategori Ethernet MAC Address Takeover IP Takeover
Kasus Uji T_CAF_2.1_A_01 T_CAF_2.1_M_02 T_CAF_2.2_A_01 T_CAF_2.2_M_02 T_CFH_1.0_A_01 T_CFH_1.0_A_02
Status GAGAL GAGAL SUKSES SUKSES SUKSES SUKSES SUKSES SUKSES SUKSES SUKSES SUKSES SUKSES SUKSES GAGAL
Keterangan tidak terjadi Takeover tidak terjadi Takeover terjadi IP Takeover terjadi IP Takeover berhasil memonitor Disk berhasil memonitor Processor berhasil memonitor Memory berhasil memonitor NIC berhasil mendeteksi failure berhasil melakukan Failover berhasil melakukan Failover berhasil menambahkan node berhasil menambahkan node dump pada lokal storage
T_CFH_1.0_A_03 T_CFH_1.0_A_04 T_CFH_1.0_A_05
Application Failover Enabling Dynamic Cluster Membership Cluster Wide Kernel Crash Dump
T_CFH_3.0_A_01 T_CFH_3.0_A_02 T_CMS_2.0_A_01 T_CMS_2.0_A_02 T_CDIAG_2.2_A_01
4.3
Analisis Hasil Pengujian
Berdasarkan hasil pengujian yang telah dilakukan, dapat dianalisis beberapa hal sebagai berikut:
4.3.1
Ethernet MAC Address Takeover
Hasil dari pengujian MAC Address Takeover dikatakan gagal. MAC Address node yang menjadi backup tidak mengambil MAC Address node yang menjalankan service sebelumnya. Dalam contoh kasus ini, server A (00:0C:29:13:0D:E7) menjalankan proserdur IP shared yang
IV-6 didalamnya terdapat parameter NIC, setelah prosedur tersebut berjalan, server A
dimatikan/dinon-aktifkan, dan server B (00:0C:29:0E:07:D9) sebagai backup server secara otomatis akan mengambil alih prosedur tersebut. Namun setelah proses itu terjadi, MAC address server B tidak berubah. Hal ini dikarenakan ARP (Address Resolution Protocol) tidak mengubah nilai MAC address dalam cache ke nilai MAC address yang baru. MAC address dapat diubah secara manual dengan perintah ip link, namun hal itu akan memutuskan koneksi yang sedang aktif. Pengujian MAC Address Takeover pada Fedora 11 memberi hasil yang sama. Heartbeat tidak mendukung mekanisme MAC Address Takeover pada Fedora 7 maupun Fedora 11.
4.3.2
IP Takeover
Hasil dari pengujian IP Takeover sangat memuaskan. IP shared yang dijalankan node yang aktif diambil alih oleh node lainnya ketika node tersebut mati. Server A (10.0.0.1) yang menjalankan prosedur IP shared (10.0.0.5) pada awalnya berjalan seperti biasa, lalu dimatikan untuk dilihat apakah prosedur IP shared diambil alih oleh server B (10.0.0.2). Ketika server A mati/non-aktif, server B segera mengambil alih dan menjalankan prosedur IP shared, sehingga seakan-akan server yang memiliki IP 10.0.0.5 selalu aktif. Dengan demikian Fedora 7 telah memenuhi kebutuhan IP Takeover yang diterdapat pada CGL Cluster. Dengan terpenuhinya kebutuhan ini, maka tingkat availability menjadi tinggi. Waktu yang dibutuhkan untuk melakukan IP Takeover bergantung pada waktu yang dibutuhkan untuk mendeteksi failure pada suatu node. Pengujian IP Takeover pada Fedora 11 memberi hasil yang sama. Pengujian ini dapat dikatakan berhasil, karena terjadi mekanisme IP Takeover saat salah satu node yang menjalankan prosedur IP shared dinon-aktifkan.
4.3.3
Hasil dari pengujian Cluster Node Failure Detection memuaskan. Pada pengujian pertama, waktu yang dibutuhkan untuk mendeteksi failure adalah 10 detik, namun setelah melakukan konfigurasi
IV-7 ulang, dapat mencapai 3 detik, hal ini dikarenakan Heartbeat memiliki batas minimum untuk menentukan bahwa suatu node mati, yaitu 3 detik. Semakin rendah waktu yang dibutuhkan untuk mendeteksi failure, maka penggunaan jaringan juga semakin tinggi. Dengan demikian, dapat dikatakan bahwa Heartbeat dapat menangani failure detection walaupun waktu yang dibutuhkan minimal adalah 3 detik. Selain pengujian dalam mendeteksi failure, pengujian lain yang dilakukan adalah dalam melakukan monitoring pada Disk, Processor, Memory, dan Network. Pengujian ini juga berhasil, PCP tidak hanya dapat memonitor resource lokal, namun juga resource pada host lain, dalam hal ini node lainnya. Pengujian Cluster Node Failure Detection pada Fedora 11 memberi hasil yang serupa. Dengan tambahan aplikasi Heartbeat, Fedora 11 dapat lulus tes yang diujikan. Dengan hasil ini, dapat dikatakan bahwa baik Fedora 7 maupun Fedora 11 mendukung Cluster Node Failure Detection.
4.3.4
Hasil dari pengujian Application Failover Enabling sangat memuaskan. Pada pengujian kasus uji yang pertama, service yang dijalankan oleh node aktif yaitu service Httpd dapat diambil alih oleh node pasif saat node aktif dimatikan. Waktu yang dibutuhkan untuk melakukan Failover bergantung pada waktu yang dibutuhkan untuk mendeteksi failure, semakin sedikit waktu yang digunakan, akan semakin baik, sehingga service dapat tetap berjalan walaupun sempat mati beberapa saat. Pada pengujian untuk service yang lebih dari 1, dalam hal ini 3 service httpd, vsftpd, dan mail, pengujian juga berjalan dengan baik. Service yang dijalankan oleh suatu node akan diambil alih semuanya ke node lain yang aktif ketika node tersebut mati. Dengan demikian, Fedora 7 dapat dikatakan telah memenuhi kebutuhan Application Failover Enabling yang terdapat dalam CGL Cluster dengan menggunakan Heartbeat. Pengujian Application Failover Enabling pada Fedora 11 memberi hasil yang sama. Pada pengujian dengan menjalankan 1 service maupun 3 services, service yang dijalankan oleh salah satu node akan diambil alih oleh node yang masih aktif, dalam hal ini, server A yang menjalankan 3 services akan dinon-aktifkan, setelah terjadi mekanisme node failure detection, maka service tersebut akan secara otomatis diambil alih oleh node lainnya, yaitu server B.
IV-8 4.3.5 Dynamic Cluster Membership
Hasil dari pengujian Dynamic Cluster Membership sangat memuaskan. Penambahan anggota cluster secara dinamis berlangsung dengan baik. Pengujian dilakukan dengan mengkonfigurasi node baru yang akan dijadikan anggota cluster, yaitu server B (10.0.0.2) dan server C (10.0.0.3) dan anggota cluster yaitu server A (10.0.0.1). Pada Heartbeat digunakan otentikasi yaitu pada file authkeys yang didalamnya terdapat kata sandi untuk registrasi cluster, apabila kata sandi tersebut sama, maka node tersebut dapat didaftarkan dan ditambahkan kedalam cluster. Penambahan 1 maupun 2 node baru dapat berlangsung dengan baik, waktu yang dibutuhkan untuk mendaftarkan anggota cluster tersebut adalah sekitar 30 detik. Dengan demikian, Fedora 7 telah memenuhi kebutuhan Dynamic Cluster Membership yang terdapat dalam CGL Cluster. Pengujian Dynamic Cluster Membership pada Fedora 11 memberi hasil yang sama dengan pengujian yang dilakukan pada Fedora 7. Fedora 11 dengan tambahan aplikasi Heartbeat mampu melakukan mekanisme ini dengan baik. Dengan hasil ini, dapat disimpulkan bahwa Fedora 7 dan Fedora 11 mampu memenuhi spesifikasi tentang Dynamic Cluster Membership dengan menggunakan aplikasi Heartbeat.
4.3.6
Cluster Wide Kernel Crash Dump
Hasil pengujian Cluster Wide Kernel Crash Dump dapat dikatakan gagal. Hal ini terjadi karena patch LKCD tidak dapat terinstall pada Fedora 7. Instalasi LKCD dilakukan dengan melakukan patch pada kernel 2.6.10, namun selalu terjadi kegagalan pada saat meng-compile kernel pada bagian file process.h. Karena LKCD gagal di-install, percobaan kemudian dilakukan dengan menginstall netdump pada client dan netdump-server pada sisi server untuk menerima dump dari client. Setelah melakukan konfigurasi netdump pada client, netdump tetap tidak dapat berjalan dikarenakan terjadi error pada saat menjalankan service netdump yang kemudian tidak dapat melakukan penambahan netconsole pada kernel Fedora. Kegagalan ini terjadi karena modul netconsole.ko tidak berhasil disisipkan ke dalam kernel. Kegagalan dalam pengujian ClusterWide Kernel Crash Dump terletak pada bagian kernel yang tidak mendukung netdump, maupun LKCD walaupun telah menggunakan versi kernel yang sama dengan patch LKCD terakhir. Oleh karena itu, script yang dirancang untuk membuat Linux menjadi crash hanya menghasilkan
IV-9 dump, yang merupakan standard yang diberikan kernel, pada file messages yang terdapat pada direktori /var/log/. Dengan demikian, Fedora 7 gagal memenuhi kebutuhan Cluster Wide Kernel Crash Dump yang merupakan salah satu kebutuhan pada CGL Cluster. Pengujian pada Fedora 11 memberi hasil yang sama, akan tetapi pengujian dilakukan dengan menggunakan aplikasi tambahan netdump dan netdump-server. Pada Fedora 11, terdapat paket netdump-server yang sesuai, namun tidak terdapat paket netdump untuk client, sehingga tidak dapat dilakukan pengujian, dan penulis juga mencoba meng-install paksa paket netdump yang seharusnya untuk sistem operasi Red Hat Enterprise Linux 4, namun tetap terjadi kegagalan pada saat menjalankan service netdump pada client. Sampai saat ini, belum ada paket netdump yang sesuai dengan Fedora 11, walaupun ada paket netdump-server yang sesuai untuk Fedora 11.
BAB V PENUTUP
5.1
Kesimpulan
Kesimpulan yang diperoleh selama pengerjaan Tugas Akhir ini adalah: 1. Fedora 7 mampu memenuhi sebagian besar pengujian yang dilakukan di Tugas Akhir ini, dan hasil yang serupa didapatkan pada Fedora 11. 2. Pengujian dilakukan dengan meng-install modul-modul yang dibutuhkan, menyusun skenario/tahap-tahap pengujian, dan melakukan konfigurasi pada tiap node sehingga didapat hasil yang diharapkan. 3. Heartbeat sebagai salah satu modul yang digunakan pada Tugas Akhir ini, memiliki fitur-fitur yang sangat dibutuhkan dalam memenuhi spesifikasi yang diuji. 4. Untuk memenuhi 6 requirements yang diujikan pada Tugas Akhir ini, dibutuhkan Heartbeat untuk High Availability Cluster, PCP untuk memonitor resources tiap node, dan Netdump dan Netdump-server yang dibutuhkan untuk melakukan dump pada network storage. 5.2 Saran
Untuk pengembangan lebih lanjut, saran-saran yang dapat diberikan pada Tugas Akhir ini adalah sebagai berikut: 1. Diperlukan pengujian dan eksplorasi lebih lanjut terhadap kebutuhan lain yang belum diujikan dari CGL Cluster pada Fedora 7. 2. Diperlukan eksplorasi yang lebih mendalam mengenai fitur-fitur pada modulmodul yang digunakan yang dapat meningkatkan kemampuan Fedora 7 dalam memenuhi kebutuhan yang terdapat pada CGL Cluster.
V-1
Daftar Referensi
[1]
Carrier Grade Linux Requirements Definition Overview Version 4.0, http://developer.osdl.org/dev/cgl/cgl40/cgl40-overview.pdf.
[2]
Carrier Grade Linux Clustering Requirements Definition Overview Version 4.0, http://developer.osdl.org/dev/cgl/cgl40/cgl40-cluster.pdf.
[3]
Linux Foundation. The Linux Fondation. CGL Glossary. September 2007. http://www.linux-foundation.org/en/CGL_Glossary.
[4] [5] [6]
Linux-HA. Heartbeat. September 2007. http://linux-ha.org LKCD Installation and Configuration, http://lkcd.sourceforge.net/doc/lkcd_tutorial.pdf Performance Co-PilotTM Users and Administrators Guide. SGI. Maret 2008. http://techpubs.sgi.com/library/manuals/2000/007-2614-004/pdf/007-2614-004.pdf
[7]
Performance Co-PilotTM Programmers Guide, SGI. April 2008. http://techpubs.sgi.com/library/manuals/2000/007-2614-004/pdf/007-3434-003.pdf
[8]
Building a Two-Node Linux Cluster with Heartbeat. Linux Journal. April 2008. http://www.linuxjournal.com/article/5862
[9]
Case Study: Cluster Consolidation, Moab Workload Manager. Juni 2008. http://www.clusterresources.co.uk/products/mwm/docs/casestudies/case15clusterconsolidation.shtml
[10] Unix. Lopsa. Agustus 2008. http://lopsa.org/taxonomy_menu/9/24/25 [11] Red Hat, Inc.'s Network Console and Crash Dump Facility. Red Hat, Inc. Maret 2009. http://www.redhat.com/support/wpapers/redhat/netdump/
xii
Lampiran A
Cluster Requirements CFH.1.0 Cluster Node Failure Detection Priority: P2 Description: CGL specifies that carrier grade Linux shall provide a fast, communicationbased cluster node failure mechanism that is reflected in a cluster membership service. At a minimum, the cluster node failure mechanism maintains a list of the nodes that are currently active in the cluster. Changes in cluster membership must result in a membership event that can be monitored by cluster services, applications, and middleware that register to be notified of membership events. Fast node failure detection must not depend on a failing node reporting that the node is failing. However, self-diagnosis may be leveraged to speed up failure detection in the cluster. This requirement does not address the issue of how to prevent failing nodes from accessing shared resources (see CFH.3.0 Application Fail-Over Enabling). Fast node failure detection shall include the following capabilities: Ability to provide cluster membership health monitoring through cluster communication mechanisms. Support for multiple, redundant communication paths to check the health of cluster nodes. Support for fast failure detection. The guideline is a maximum of 250ms for failure detection. Since there is tradeoff between fast failure detection and potentially false failures, the health-monitoring interval must be tunable. Ability to provide a cluster-membership change event to middleware and applications.
Cluster node failure detection must use only a small percentage of the total cluster communication bandwidth for membership health monitoring. The guideline is that the bandwidth used by the health monitoring mechanism shall be linear with respect to the number of bytes per second per node.
A-1
A-2 CFH.2.0 Prevent Failed Node From Corrupting Shared Resources Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a way to fence a failed or errant node from shared resources, such as SAN storage, to prevent the failed node from causing damage to shared resources. Since the surviving nodes in the cluster will want to failover resources, applications, and/or middleware to other surviving nodes in the cluster, the cluster must make sure it is safe to do the failover. Killing the failed node is the easiest and safest way to protect shared resources from a failing node. If a failing node can detect that it is failing, the failing node could kill itself (suicide) or disable its ability to access shared resources to augment the node isolation process. However, the cluster cannot depend on the failing node to alter the cluster when it is failing, so the cluster must be proactive in protecting shared resources. External Specification Dependencies: This requirement is dependent on hardware to provide a mechanism to reset or isolate a failed or failing node.
CFH.3.0 Application Fail-Over Enabling Priority: P2 Description: CGL specifies that carrier grade Linux shall provide mechanisms for failing over applications in a cluster from one node to another. Applications and nodes are monitored and a failover mechanism is invoked when a failure is detected. Once a failure is detected, the application failover mechanism must determine which policies apply to this failover scenario and then begin the process to start a standby application or initiate the re-spawn of an application within 1 second. Note: The full application failover time is dependent upon application and node failure detection, the time to apply the failover policies, and the time it takes to start or restart the application. The aggregate failover time for an application must allow the cluster to maintain carrier grade application availability.
A-3 CSM.1.0 Storage Network Replication Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a mechanism for storage network replication. The storage network replication shall provide the following: A network replication layer that enables RAID-1-like disk mirroring, using a cluster-local network for data. Resynchronization of replicated data after node failure and recovery such that replicated data remains available during resynchronization.
CSM.2.0 Cluster-aware Volume Management for Shared Storage Priority: P2 Description: CGL specifies that carrier grade Linux shall provide management of logical volumes on shared storage from different cluster nodes. Volumes in such an environment are usually on physical disks accessible to multiple nodes. Volume management shall include the following: Enabling remote nodes to be informed of volume definition changes. Providing consistent and persistent cluster-wide volume names. Managing volumes from different cluster nodes consistently. Providing support for the striping and concatenation of storage. Clustered mirroring of shared storage is not included in this requirement (see CSM.3.0 Shared Storage Mirroring).
A-4 CSM.4.0 Redundant Cluster Storage Path Priority: P1 Description: CGL specifies that Linux shall provide each cluster node with the ability to have redundant access paths to shared storage. CGL Availability Requirement: AVL.7.1 Multi-Path Access To Storage.
CSM.6.0 Cluster File System Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a cluster-wide file system. A clustered file system must allow simultaneous access to shared files by multiple computers. Node failure must be transparent to file system users on all surviving nodes. A clustered file system must provide the same user API and semantics as a file system associated with private, singlenode storage.
CSM.7.0 Shared Storage Consistent Access Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a consistent method to access shared storage from different nodes to ensure partition information isn't changed on one node while a partition is in use on another node that would prevent the change.
CCM.2.1 Cluster Communication Service - Logical Addressing Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a cluster communication service with a socket-based interface that provides logical addressing for pointto-point and
A-5 multipoint communication. The communication service must hide the physical topology of the cluster from application programs with this logical addressing scheme. Mapping between logical and physical addresses must be performed transparently. In addition, there must be no user-level distinction between inter- and intra-node communications or between user-space and kernelspace messages. Connection-oriented and connectionless modes must be supported.
CCM.2.2 Cluster Communication Service - Fault Handling Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a reliable communication service that detects a connection failure, aborts the connection, and reports the connection failure. An established connection must react to and report a problem to the application within 100 ms upon any kind of service failure, such as a process or node crash. The connection failure detection requirement must offer controls that allow it to be tailored to specific conditions in different clusters. An example is to allow the specification of the duration of timeouts or the number of lost packets before declaring a connection failed.
CCM.3.0 Redundant Cluster Communication Path Priority: P1 Description: CGL specifies that Linux shall provide each cluster node the ability to have redundant communication paths to other cluster nodes and for these paths to appear as a single interface to an application. CGL Availability Requirement: AVL.7.3 Redundant Communication Paths
A-6 CAF.2.1 Ethernet MAC Address Takeover Priority: P1 Description: CGL specifies a mechanism to program and announce MAC addresses on Ethernet interfaces so that when a SW Failure event occurs, redundant nodes may begin receiving traffic for failed nodes.
CAF.2.2 IP Takeover Priority: P1 Description: CGL specifies a mechanism to program and announce IP addresses (using gratuitous ARP) so that when a SW Failure event occurs, redundant nodes may begin receiving traffic for failed nodes.
CDIAG.2.1 Cluster-Wide Identified Application Core Dump Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a cluster-aware application core dump that uniquely identifies which node produced the core dump. For instance, if a diskless node dumps core files to network storage, the core dump will be uniquely identified as originating from that node.
CDIAG.2.2 Cluster-Wide Kernel Crash Dump Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a cluster-aware kernel crash dump that uniquely identifies which node produced the crash dump. For instance, if a diskless
A-7 node dumps crash data to network storage, the data will be uniquely identified as originating from that node.
CDIAG.2.3 Cluster Wide Log Collection Priority: P1 Description: CGL specifies that carrier grade Linux shall provide a cluster-wide logging mechanism. A cluster-wide log shall contain node identification, message type, and cluster time identification. This cluster-wide log may be implemented as a central log or as the collection of specific node logs.
CDIAG.2.4 Synchronized/Atomic Time Across Cluster Priority: P1 Description: CGL specifies that carrier grade Linux shall provide cluster wide time synchronization within 500mS, and must synchronize within 10 seconds once the time synchronization service is initiated. In a cluster, each node must have be synchronized to the same wall-clock time to provide consistency in access times to shared resources (i.e. clustered file system modification and access times) as well as time stamps in cluster-wide logs.
Lampiran B PCP Chart Resource Monitoring
A-1

Final Project

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Final Project

Diunggah oleh

Hak Cipta:

Format Tersedia

Analisis Pemenuhan Carrier Grade Linux Standard 4.

0 Aspek Cluster Pada Fedora 7

LAPORAN TUGAS AKHIR

Disusun sebagai syarat kelulusan tingkat sarjana

oleh: Prasetyo Nugroho / 13504039

LEMBAR PENGESAHAN Program Studi Sarjana Teknik Informatika

Tugas Akhir Program Studi Sarjana Teknik Informatika ITB

Oleh Prasetyo Nugroho / 13504039

Achmad Imam Kistijantoro, S.T., M.Sc., Ph.D. NIP 132320559

Bandung, 26 Juni 2009

Kakas ...................................................................................................................... II-9

3.7.1 Kasus Uji T_CDIAG_2.2_01 ............................................................................ III-12 vii

Kriteria Keberhasilan Pengujian........................................................................... III-12

I-3 1.4 Batasan Masalah

I-4 1.6 Sistematika Pembahasan

BAB II Dasar Teori

Carrier Grade Linux

CGL 4.0 Cluster

High Availability Cluster

Jaringan khusus antara server-server yang menggunakan Heartbeat

Linux Kernel Crash Dump

Netdump dan Netdump-server

BAB III Analisis dan Perancangan Kasus Uji

III-2 3.1.1 Rancangan Sistem yang Dibangun

Gambar III-1 Rancangan Sistem

Kode Kasus Uji

III-3 Keterangan: T : Kasus Uji

Ethernet MAC Address Takeover CAF 2.1

Kasus Uji T_CAF_2.1_01

Kasus Uji T_CAF_2.1_02

IP Takeover CAF 2.2

III-5 3.3.1 Kasus Uji T_CAF_2.2_01

Kasus Uji T_CAF_2.2_02

Cluster Node Failure Detection CFH 1.0

Kasus Uji T_CFH_1.0_01

Kasus Uji T_CFH_1.0_02

Kasus Uji T_CFH_1.0_03

III-8 b. Jalankan script monitoring kondisi memory (Memory Usage).

Kasus Uji T_CFH_1.0_04

Kasus Uji T_CFH_1.0_05

Application Failover Enabling CFH 3.0

Kasus Uji T_CFH_3.0_01

Kasus Uji T_CFH_3.0_02

Dynamic Cluster Membership CMS 2.0

III-11 3.6.1 Kasus Uji T_CMS_2.0_01

Kasus Uji T_CMS_2.0_02

Cluster-Wide Kernel Crash Dump CDIAG 2.2

Kasus Uji T_CDIAG_2.2_01

Kategori Ethernet MAC Address Takeover

Kasus Uji T_CAF_2.1_01

Cluster Node Failure Detection

T_CFH_1.0_01 T_CFH_1.0_02 T_CFH_1.0_03 T_CFH_1.0_04 T_CFH_1.0_05

Application Failover Enabling

Dynamic Cluster Membership

Cluster Wide Kernel Crash Dump

BAB IV HASIL PENGUJIAN DAN PEMBAHASAN

Pengujian dilakukan pada perangkat keras dengan spesifikasi sebagai berikut:

Gambar IV-1 Model Sistem

Ethernet MAC Address Takeover

Cluster Node Failure Detection

Application Failover Enabling

Dynamic Cluster Membership

Cluster-Wide Kernel Crash Dump