Top Banner
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
59

Final Project

Jun 26, 2015

Download

Documents

CGL Clustering test on Fedora 7
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: 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

Page 2: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

x

DAFTAR GAMBAR

Gambar III-1 Rancangan Sistem ............................................................................................ III-2

Gambar IV-1 Model Sistem .................................................................................................. IV-2

Page 11: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

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: Final Project

A-1

Lampiran B

PCP Chart Resource Monitoring