Page 1
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
Page 2
ii
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
Page 3
iii
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.
Page 4
iv
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.
Page 5
v
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
Page 6
vi
DAFTAR ISI
LEMBAR PENGESAHAN ........................................................................................................ II
ABSTRAKSI ............................................................................................................................ III
KATA PENGANTAR.............................................................................................................. IV
DAFTAR ISI ........................................................................................................................... VI
DAFTAR GAMBAR ................................................................................................................. X
DAFTAR TABEL .................................................................................................................... XI
PENDAHULUAN ................................................................................................................... I-1
1.1 Latar Belakang ......................................................................................................... I-1
1.2 Rumusan Masalah..................................................................................................... I-2
1.3 Tujuan ...................................................................................................................... I-2
1.4 Batasan Masalah ....................................................................................................... I-3
1.5 Metodologi ............................................................................................................... I-3
1.6 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 Ethernet ................................................................................................... II-4
2.2.1.2 Ethernet MAC Address Takeover .............................................................. II-5
2.2.1.3 IP Takeover .............................................................................................. II-6
2.2.2 Fault Handling .................................................................................................... II-6
2.2.2.1 Cluster Node Failure Detection ................................................................ II-6
2.2.2.2 Aplication Fail-Over Enabling ................................................................. II-7
2.2.3 Membership Service ............................................................................................. II-8
2.2.3.1 Dynamic Cluster Membership .................................................................. II-8
Page 7
vii
2.2.4 Management ........................................................................................................ II-9
2.2.4.1 Cluster-Wide Kernel Crash Dump ............................................................ II-9
2.3 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
Page 8
viii
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 Hasil Pengujian ...................................................................................................... IV-5
4.3 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 Kesimpulan .................................................................................................................1
5.2 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
Page 9
ix
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
Page 10
x
DAFTAR GAMBAR
Gambar III-1 Rancangan Sistem ............................................................................................ III-2
Gambar IV-1 Model Sistem .................................................................................................. IV-2
Page 11
xi
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
Page 12
I-1
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].
Page 13
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.
Page 14
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. Carrier Grade Linux yang dipakai adalah versi 4.0.
3. 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 standar-
standar CGL yang telah ditetapkan.
Page 15
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.
Page 16
II-1
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 ke-
4, 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. Prioritas 1 (P1), berisi requirements yang bersifat wajib.
2. Prioritas 2 (P2), berisi requirements yang bersifat opsional.
Page 17
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 seakan-
akan 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.
Page 18
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 berbeda-
beda, 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. Scalability Cluster
3. Server Consolidation Cluster
4. 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
Page 19
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
Page 20
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 aturan-
aturan 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.
Page 21
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.
Page 22
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.
Page 23
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.
Page 24
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
Page 25
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
Page 26
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.
Page 27
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.
Page 28
III-1
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. Ethernet MAC Address Takeover (CAF 2.1)
2. IP Takeover (CAF 2.2)
3. Cluster Node Failure Detection (CFH 1.0)
4. Application Failover Enabling (CFH 3.0)
5. Dynamic Cluster Membership (CMS 2.0)
6. 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. Linux Kernel Crash Dump untuk melakukan dump pada network storage.
5. Netdump dan Netdump-server untuk melakukan dump pada network storage.
Page 29
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>
Page 30
III-3
Keterangan:
T : Kasus Uji
<Aspek> : Kode aspek yang diuji, misalnya CAF, CFH, dan CDIAG
<ID> : ID standar requirement
<No> : 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. Lakukan konfigurasi IP eth0 pada tiap node.
b. Periksa MAC address pada kedua node.
c. Matikan salah satu node (dengan asumsi terjadi crash node tersebut).
d. Periksa MAC address node lainnya.
Page 31
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 Kasus Uji T_CAF_2.1_02
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. Lakukan konfigurasi IP eth0 pada tiap node.
b. Periksa MAC address pada kedua node.
c. Non-aktifkan interface eth0.
d. 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:
Page 32
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. Lakukan konfigurasi IP eth0 pada tiap node.
b. Periksa IPaddress pada kedua node.
c. Matikan salah satu node (dengan asumsi terjadi crash node tersebut).
d. 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 Kasus Uji T_CAF_2.2_02
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. Lakukan konfigurasi IP eth0 pada tiap node.
b. Periksa IP address pada kedua node.
c. Non-aktifkan interface eth0.
d. 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:
Page 33
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.
Page 34
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. Jalankan service PCP pada tiap node.
b. Jalankan script monitoring kondisi disk (Input Output).
Pengujian ini dikatakan berhasil apabila PCP dapat memonitor kondisi disk pada tiap node.
3.4.2 Kasus Uji T_CFH_1.0_02
Pada kasus uji ini, akan dilakukan tes apakah PCP dapat memonitor node mengenai kondisi
processor. Langkah pengujiannya adalah sebagai berikut:
a. Jalankan service PCP pada tiap node.
b. Jalankan script monitoring kondisi processor (CPU Utilization).
Pengujian ini dikatakan berhasil apabila PCP dapat memonitor kondisi processor pada tiap node.
3.4.3 Kasus Uji T_CFH_1.0_03
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.
Page 35
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 Kasus Uji T_CFH_1.0_04
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 Kasus Uji T_CFH_1.0_05
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. Periksa apakah semua node tidak mati.
b. Matikan salah satu node.
c. Periksa apakah terjadi deteksi kegagalan.
d. 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
Page 36
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 Kasus Uji T_CFH_3.0_01
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. Lakukan konfigurasi dan jalankan 1 service pada server A.
b. Periksa apakah service tersebut berjalan dengan baik.
c. Matikan server A.
d. Periksa service pada server B.
Page 37
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 Kasus Uji T_CFH_3.0_02
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. Lakukan konfigurasi dan jalankan 3 service pada server A.
b. Periksa apakah service tersebut berjalan dengan baik.
c. Matikan server A.
d. 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:
Page 38
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. Periksa keanggotaan cluster.
b. Lakukan konfigurasi 1 node baru.
c. 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. Periksa keanggotaan cluster.
b. Lakukan konfigurasi 2 node baru (menggunakan virtual machine).
c. 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
Page 39
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. Buat program kernelpanic yang membuat error kernel.
b. Menjalankan service netdump-server pada node A.
c. Menjalankan service netdump pada node B .
d. Jalankan program kernelpanic.
e. 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 Kasus Uji Keterangan
SUKSES GAGAL
Ethernet MAC Address Takeover
T_CAF_2.1_01 mendapatkan MAC Address node yang
mati
tidak melakukan Takeover MAC Address
node yang dimaksud
Page 40
III-13
T_CAF_2.1_02 mendapatkan MAC
Address node yang mati
tidak melakukan
Takeover MAC Address node yang dimaksud
IP Takeover T_CAF_2.2_01 mendapatkan IP
Address node yang mati
tidak melakukan
Takeover IP Address node yang dimaksud
T_CAF_2.2_02 mendapatkan IP
Address node yang mati
tidak melakukan
Takeover IP Address node yang dimaksud
Cluster Node Failure Detection
T_CFH_1.0_01 dapat memonitor Disk (Storage) tiap node
gagal memonitor Disk tiap node
T_CFH_1.0_02 dapat memonitor
Processor tiap node
gagal memonitor
Processor tiap node
T_CFH_1.0_03 dapat memonitor
Memory tiap node
gagal memonitor Memory
tiap node
T_CFH_1.0_04 dapat memonitor NIC tiap node
gagal memonitor NIC tiap node
T_CFH_1.0_05 mendeteksi failure dan optimalisasi waktu
tidak dapat mendeteksi failure pada suatu node
Application Failover
Enabling
T_CFH_3.0_01 berhasil melakukan 1
service Failover
gagal melakukan Failover
T_CFH_3.0_02 berhasil melakukan 3
service Failover
gagal melakukan Failover
Dynamic Cluster
Membership
T_CMS_2.0_01 berhasil menambahkan
1 node
berhasil menambahkan
node
T_CMS_2.0_02 berhasil menambahkan 2 node
berhasil menambahkan node
Cluster Wide Kernel
Crash Dump
T_CDIAG_2.2_01 berhasil melakukan
dump pada shared storage
dump pada lokal storage
Page 41
IV-1
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 Spesifikasi / Keterangan
Type Notebook Compaq Presario v3504TU
Processor Intel(R) Centrino Duo T7300
Memory 3072 MB DDR2 RAM
Storage 120 GB HDD
Display 14.1“ WXGA TFT LCD
Display Adapter Mobile Intel(R) 965 358 MB VRAM
Ethernet Marvell Yukon 88E8039 PCI-E Fast Ethernet Controller
WLAN Intel(R) Pro/Wireless 3945ABG
DVD/CD ROM 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:
Page 42
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. Hearbeat-2.0.8, merupakan perangkat lunak untuk High Availability Cluster.
4. PCP-2.7.8-20090217, merupakan perangkat lunak untuk melakukan monitoring.
5. 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
Page 43
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 Cluster Node Failure Detection
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.
Page 44
IV-4
4.1.4 Application Failover Enabling
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
Page 45
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 Kasus Uji Status Keterangan
Ethernet MAC Address
Takeover
T_CAF_2.1_A_01 GAGAL tidak terjadi Takeover
T_CAF_2.1_M_02 GAGAL tidak terjadi Takeover
IP Takeover T_CAF_2.2_A_01 SUKSES terjadi IP Takeover
T_CAF_2.2_M_02 SUKSES terjadi IP Takeover
Cluster Node Failure
Detection
T_CFH_1.0_A_01 SUKSES berhasil memonitor Disk
T_CFH_1.0_A_02 SUKSES berhasil memonitor Processor
T_CFH_1.0_A_03 SUKSES berhasil memonitor Memory
T_CFH_1.0_A_04 SUKSES berhasil memonitor NIC
T_CFH_1.0_A_05 SUKSES berhasil mendeteksi failure
Application Failover Enabling
T_CFH_3.0_A_01 SUKSES berhasil melakukan Failover
T_CFH_3.0_A_02 SUKSES berhasil melakukan Failover
Dynamic Cluster
Membership
T_CMS_2.0_A_01 SUKSES berhasil menambahkan node
T_CMS_2.0_A_02 SUKSES berhasil menambahkan node
Cluster Wide Kernel
Crash Dump T_CDIAG_2.2_A_01 GAGAL dump pada lokal storage
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
Page 46
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 Cluster Node Failure Detection
Hasil dari pengujian Cluster Node Failure Detection memuaskan. Pada pengujian pertama, waktu
yang dibutuhkan untuk mendeteksi failure adalah 10 detik, namun setelah melakukan konfigurasi
Page 47
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 Application Failover Enabling
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.
Page 48
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 Cluster-
Wide 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
Page 49
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.
Page 50
V-1
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 modul-
modul yang digunakan yang dapat meningkatkan kemampuan Fedora 7 dalam
memenuhi kebutuhan yang terdapat pada CGL Cluster.
Page 51
xii
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] Linux-HA. Heartbeat. September 2007. http://linux-ha.org
[5] LKCD Installation and Configuration, http://lkcd.sourceforge.net/doc/lkcd_tutorial.pdf
[6] Performance Co-PilotTM User’s and Administrator’s Guide. SGI. Maret 2008.
http://techpubs.sgi.com/library/manuals/2000/007-2614-004/pdf/007-2614-004.pdf
[7] Performance Co-PilotTM Programmer’s 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/case15-
clusterconsolidation.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/
Page 52
A-1
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.
Page 53
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.
Page 54
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).
Page 55
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, single-
node 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
Page 56
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 kernel-
space 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
Page 57
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
Page 58
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.
Page 59
A-1
Lampiran B
PCP Chart Resource Monitoring