BAB II LANDASAN TEORI

Transkripsi

1 BAB II LANDASAN TEORI Pada bab ini akan dijelaskan beberapa konsep dasar yang berguna untuk pemahaman yang lebih detail mengenai konsep-konsep tersebut sehingga memudahkan proses analisis dan perancangan pengujian yang akan dilakukan pada tahap berikutnya. 2.1 Carrier Grade Linux CGL Overview Carrier Grade Linux (CGL) merupakan 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 yang digunakan pada industri telekomunikasi untuk mengacu pada perangkat yang memiliki karakteristik atau ketersediaan dan performansi yang diperlukan oleh perusahaan Carrier (penyedia jasa telekomunikasi). Penyedia jasa telekomunikasi tersebut membutuhkan perangkat yang reliable, dan teruji kemampuannya. Standar yang dibangun oleh CGL merupakan standar yang dari berbagai kepentingan seperti; perusahaan telekomunikasi, distro-distro linux, penyedia perlengkapan jaringan, komunitas open-source, dan sebagainya. CGL mulai berkembang sejak tahun 2002, yang mana berkumpul sejumlah perwakilan dari kalangan industri telekomunikasi, penyedia jaringan, dan pengembang Linux mencoba untuk mendefinisikan bagaimana CGL dapat mampu membentuk suatu lingkungan operasi dengan availability, serviceability, dan scalability yang tinggi. Maka dibentuklah suatu kelompok kerja yang sekarang dikenal dengan nama OSDL CGL working group. Sejak kelompok tersebut dibentuk mereka telah berhasil membuat 4 versi standar yang utama. Saat dokumen ini ditulis CGL working group telah membuat versi utama terbaru yaitu versi ke-4 dan sedang dalam proses membuat versi ke-5. CGL working group saat ini terdiri dari 36 perwakilan dari pengembang II-1

2 Linux, penyalur, penyedia perlengkapan jaringan, kalangan industri dan anggota komunitas pengembang di dunia. Gambar II-1 Ekosistem Carrier Grade Linux [OSD07b] CGL versi 4 merupakan superset dari CGL versi 3.2 namun ada beberapa bagian/requirement yang dihilangkan. CGL 4.0 memperkenalkan 3 jenis prioritas yaitu: [OSD07a] 1. Prioritas 1, requirement bersifat wajib atau mandatory requirements. 2. Prioritas 2, requirement bersifat opsional, jika ini dimasukkan dalam proses pendaftaran harus disertakan bukti dari pemenuhan requirement yang ditetapkan. 3. Prioritas 3, requirement masih bersifat rencana atau pengembangan dan tidak diwajibkan. CGL 4.0 terdiri dari 7 aspek/jenis requirement, yaitu: [OSD07b] 1. Availability, mendeskripsikan funsionalitas untuk 1 node saja, availability dan recoverynya. 2. Clusters, mendeskripsikan komponen-komponen yang diperlukan untuk membangun sebuah cluster dengan availability yang tinggi. II-2

3 3. Serviceability, mendeskripsikan fitur-fitur yang diperlukan untuk pelayanan dan perawatan sistem dan mencakup tool yang mendukungnya 4. Performance, mendeskripsikan fitur-fitur untuk membantu performansi dari sistem seperti real-time, juga mendeskripsi komponen untuk mendukung performansi 5. Standards, mendeskripsikan acuan terhadap API, spesifikasi, standar seperti POSIX, IETF, dan SA Forum. 6. Hardware, mendeskripsikan spesifikasi-spesifikasi perangkat keras yang berkaitan dengan sistem operasi carrier. 7. Security, mendeskripsikan fitur-fitur yang harus dipenuhi untuk membangun sistem yang aman. Saat dokumen ini ditulis CGL 4.0 masih dalam proses menunggu pendaftaran pengembang yang ingin mendaftarkan produknya sebagai produk yang memenuhi standar-standar yang telah ditetapkan CGL CGL 4.0 Availability Aspek Availability merupakan aspek dasar yang harus dimiliki suatu sistem operasi yang ingin dianggap sebagai Carrier Grade Operating System yang mengindikasikan bahwa suatu sistem harus dapat beroperasi dan melayani permintaan kapan saja. Ketersediaan sistem bergantung pada ketersediaan dari masing-masing komponennya. Harus dimungkinkan untuk melakukan perawatan dan ekspansi sistem tanpa harus menyebabkan terganggunya pelayanan yang disediakannya. Sistem harus mampu tahan terhadap kegagalan komponen. Aspek availability merupakan aspek dasar yang harus menfokuskan pada ketersediaan suatu workstation dan merupakan pendukung aspek serviceability. Pada aspek availability standar-standar yang ada dapat dikelompokkan menjadi 4 bagian yaitu: 1. Robust Software Robust Software menyangkut kualitas yang sangat baik terhadap system software, middleware dan application software. Pada Robust Software, standar yang dipilih penulis II-3

4 adalah robust mutexes (AVL 1.0) yang harus menyediakan mutex yang robust untuk threads yang akan dijelaskan kemudian. 2. On-Line Operations On-Line Operations berkaitan dengan penyediaan layanan/service walaupun saat sedang melakukan proses pengubahan baik itu hardware ataupun software. Sebagai contoh saat terjadi perbaikan atau perubahan file terkadang dibutuhkan rebooting terhadap sistem. Kemampuan untuk mengubah atau memperbaharui perangkat keras seperti disks, processor, memory, dan lainnya tanpa menyebabkan node tersebut mati merupakan bagian dari kelompok ini. Standar yang penulis pilih pada bagian ini adalah Force Unmount (AVL 3.2) dan konsep yang berkaitan adalah konsep mounting. 3. Monitoring Monitoring berkaitan tentang deteksi kegagalan hardware ataupun software. Deteksi status ini juga harus mampu memprediksi kemungkinan akan segera terjadinya kegagalan. Standar yang penulis pilih pada bagian ini adalah memory monitoring (AVL 4.3 dan AVL 4.4) yang akan penuh. 4. Redundancy Redundancy berkaitan dengan penyediaan komponen-komponen yang memiliki cadangan-cadangan sehingga jika salah satu tidak berfungsi yang lain dapat membantu. Standar yang penulis pilih pada bagian ini adalah Ethernet link bonding using IPv4 (AVL 21.0) teori yang berkaitan yaitu Ethernet link bonding di Linux 2.2 Robust Software Robust Mutex Mutex Mutex merupakan skema untuk mengatasi masalah komunikasi antar proses terjadinya sharing resource yang dipakai. Ketika 2 proses atau lebih mencoba mengakses shared resource (misalnya main memory, atau shared file) yang sama maka terjadilah apa yang dikenal dengan race condition, kondisi dimana hasil dari proses yang bersangkutan bergantung pada proses yang terlebih dahulu mendapatkan akses terhadap resource yang di-shared tersebut. Bagian dari program yang mencoba mengakses shared resource tersebut disebut critical region. Untuk II-4

5 menghindari race condition tersebut dibutuhkan suatu kondisi mutual exclusion antar proses. Pada mutual exclusion: 1. Tidak ada 2 proses yang mengakses critical region bersamaan 2. Tidak ada asumsi dibuat tentang kecepatan atau jumlah CPU 3. Tidak ada proses yang berjalan di luar critical region yang memblok proses lain 4. Tidak ada proses yang harus menunggu selamanya untuk masuk ke critical region-nya Gambar II-2 Race Condition Gambar II-3 Critical Region [TAN01] II-5

6 Mutex merupakan salah satu solusi mengimplementasikan mutual exclusion, baik untuk sejumlah shared resource atau potongan kode, mudah dan efisien untuk diimplementasikan. Mutex merupakan variable yang dapat menandakan 2 status, locked state dan unlocked state. Locked State merupakan state dimana critical region sedang diakses proses lain dan biasanya berupa suatu nilai integer selain 0 umumnya 1. Unlocked State merupakan state dimana tersedia critical region yang bisa di akses dan biasanya direpresentasikan dengan nilai 0. Pada Linux dengan bahasa pemograman C kita dapat melakukan programming menggunakan mutex. Jika ingin memakai multithread kita dapat memanfaatkan beberapa system call yang di sediakan di Linux seperti: pthread_create(pthread_t *restrict thread, const pthread_attr_t *restrict attr, void *(*start_routine)(void*), void *restrict arg); pthread_mutex_destroy(pthread_mutex_t *mutex); pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict attr); pthread_mutex_lock(pthread_mutex_t *mutex); pthread_mutex_trylock(pthread_mutex_t *mutex); pthread_mutex_unlock(pthread_mutex_t *mutex); Gambar II-4 Fungsi Dasar POSIX thread Robust Mutex CGL Availability, AVL 1.0 Robust Mutex menyatakan tentang pengimplementasian mutex pada POSIX(standar UNIX dari IEEE) Thread yang memenuhi kriteria robust. Kriteria ini yaitu: [OSD07a] 1. Memungkinkan sinkronisasi antar thread baik itu di proses yang sama ataupun di proses yang berbeda ketika suatu thread exit atau abort secara tidak sengaja II-6

7 2. Aplikasi yang memakai mutex tersebut harus bisa mengerti berbagai informasi yang mengindikasikan pemegang mutex sebelumnya sudah di terminated dan juga status recovery dari state mutex 3. Pemegang mutex baru harus bisa medeteksi kegagalan dan melakukan aksi cleanup dan inisialisasi ulang mutex untuk pengunaan selanjutnya. 4. Jika aksi cleanup sedang diproteksi atau dilock oleh mutex maka mutex tersebut akan ditandai dengan state inconsistent yang penggunaan selanjutnya dengan state inconsistent juga. Robust mutexes pada Linux telah dikembangkan oleh Linux OS & Technology Team dari Intel Corporation dengan proyek fusyn+rtnptl: The making of a real-time synchronization infrastructure for Linux. fusyn+rtnptl dikembangkan oleh Iñaky Pérez-González, Boris Hu, dan 3 orang lainnya[gon04]. Fusyn atau Fast User SYNChronization merupakan proyek yang mencoba mengimplementasikan real-time locking pada kernel linux. RTNPTL atau Real-Time Native POSIX Thread Library (RT-NPTL) merupakan modifikasi dari NPTL yang menyediakan fitur-fitur baru yang mendukung real-time interaksi, yang mana algoritma diharapkan mampu memprediksi kemungkinan yang terjadi. Fusyn memungkinkan pemenuhan 4 hal utama sebagai berikut : 1. Mutex dan variabel kondisional harus memenuhi ekspektasi real-time 2. Robustness, mengetahui bahwa pemilik mutex sebelumnya telah terminasi 3. Uncontested locks/unlocks terjadi tanpa intervensi kernel 4. Deteksi deadlock Fitur yang paling terkait dengan CGL Availability tentu saja fitur robustness. Robustness menyediakan fungsi yang toleran terhadap kegagalan pada proses atau thread tertentu II-7

8 Thread runs Lock mutex terminated Thread runs waiting Mutex??? waiting Waktu t Gambar II-5 Ilustrasi Missing Mutex Owner Pada Gambar II-5 dapat dilihat bahwa jika program menggunakan mekanisme mutex biasa (nonrobust), mutex masih tetap diblok walaupun owner telah mati, dan akhirnya proses atau thread lain yang menunggu tidak pernah di-wake-up. Selain mekanisme robust mutex hal ini dapat diatasi dengan cara lain seperti watchdogs, timeouts, dan sebagainya, namun cara lainnya masih dinilai komplek dan sulit [LIN05]. Robustness pada fusyn meyediakan informasi bagi mutex tentang siapa pemiliknya, dan jika pemiliknya akan melakukan notifikasi sesaat sebelum terminasi/dead. Jika hal tersebut terjadi maka mutex tersebut akan diletakkan pada suatu state tertentu (consistency state), dan akan di unlock lalu penunggu pertama(antri terdepan) akan ditetapkan sebagai owner baru. Jika tidak ada antrian terdepan maka akan tetap di unlock dan onwer-nya adalah dead owner sampai ada proses yang membutuhkannya. Thread atau proses baru yang mendapatkan mutex dari pemilik yang telah terminasi akan menerima kode tertentu pada fusyn disebut EOWNERDEAD, ini sebagai peringatan data yang dipegang oleh mutex ini mungkin tidak konsisten dan harus diperbaiki. Sebagai contoh apabila pemilik lama belum selesai menulis sesuatu ke sebuah file tetapi dia telah terminasi maka hal yang ditulis di file tersebut mungkin tidak konsisten. Pemilik baru dari mutex dapat melakukan beberapa hal terhadap ketidakkonsistenan tersebut, yaitu: a. Tidak menghiraukannya II-8

9 b. Tidak mampu memperbaiki dan memberikan hak pada proses atau thread lain yang mampu memperbaikinya yang tentu saja harus melakukan unlock c. Mampu dan berhasil memperbaiki sehingga mengeset state mutex menjadi normal d. Gagal memperbaiki, dan memberikan ke proses atau thread lain e. Gagal memperbaiki karena memang tidak bisa diperbaiki dan dalam fusyn diberi kode ENOTRECOVERABLE sehingga memungkinkan strategi lain dicoba Untuk mendukung robustness fusyn juga mengimplementasikan deadlock detection dan priority inheritance. Gambar II-6 Priority Inheritance [GON04] 2.3 On-Line Operation Force Unmount Mounting Proses mounting merupakan proses menambahkan sejumlah filesystem baru kedalam filesystem yang ada di komputer. Filesystem merupakan hirarki dari direktori yang digunakan untuk mengelola file dalam komputer atau storage. File merupakan abtraksi dari koleksi informasi pada media penyimpanan (hard disk, CD, flash disk, dan sebagainya) [LIN06]. II-9

10 Pada sistem operasi Linux direktori teratas pada hirarki direktori adalah root direktori atau dilambangkan dengan karakter slash ( / ). Untuk mendapatkan akses terhadap files yang diinginkan kita harus menentukan dimana letak kita ingin me-mount file tersebut dan dari mount point itu lah kita bisa mengakses. Sesuatu yang kita mount dapat berupa partisi hard disk, CDROM, USB device. Pada saat kita meng-attach device tersebut, driver yang menangani device bersangkutan akan membaca isi device dan membuat struktur direktori sesuai dengan hasil pembacaan. Contohnya pembacaan CDROM akan ditulis di direktori /mnt/cdrom. Gambar II-7 Strukur Direktori Linux dan Unix-like [TAN01] Sebagian besar dari proses mounting ditangani otomatis oleh sistem operasi, kita tidak menyadari telah terjadi proses mounting. Pada proses mounting ini linux telah menyediakan sub-direktori /mnt sebagai mount point device device yang removeable (USB device, CDROM, floppy), sementara untuk hard disk sendiri ada di /dev/xxx. Mount point merupakan direktori dimana file system yang baru telah di-mount. Mount point menjadi root direktori terhadap direktori yang di-mount. II-10

11 Walaupun proses mounting sebagian besar dilakukan oleh sistem operasi, kita dapat juga melakukananya secara manual. Pada Linux disediakan system call mount untuk melakukan proses mounting dan unmount untuk proses sebaliknya. Command mount dan unmount dapat dijalankan oleh user root, sebagai contoh jika kita ingin me-mount partisi hard-disk ke-8 yang memiliki ke sebuah direktori /dir, kita dapat menjalankan perintah : mount /dev/hda8 /dir Dengan proses mounting kita dapat mengakses file yang berada di partisi hard disk ke-4 tersebut melalui mount point-nya yaitu /dir/. Sebaliknya jika kita ini memutuskan koneksi ke tree utama, kita dapat melakukan proses unmounting, dengan perintah sebagai berikut: unmount /dev/hda8 /dir. Kita dapat melihat list device yang saat ini sedang di mount pada file /etc/fstab, file konfigurasi ini juga menunjukan informasi tentang file system device yang di-mount dan informasi lain nya. Pada saat booting file ini akan di buka dan mejadi acuan partisi mana yang akan di-mount secara otomatis. Kita dapat menambahkan partisi yang ingin kita mount secara otomatis pada saat booting. LABEL=/ / ext3 defaults 1 1 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode= sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /mnt/c /dev/sda2 fuseblk defaults 0 0 /mnt/g /dev/sda5 fuseblk defaults 0 0 /mnt/d /dev/sda6 vfat defaults 0 0 Gambar II-8 Contoh Fstab file II-11

12 Gambar II-9 Mounting "bar" ke Dalam "foo" [LIN06] Force Unmount Pada CGL AVL 3.2 [OSD07a] menyaratkan bahwa sistem operasi harus mampu untuk melakukan aksi force unmount yaitu perintah unmount tetap bekerja walaupun ada file pada direktori mount point ataupun di bawahnya yang sedang di akses. Permintaan terhadap file akan di hentikan dan diberikan error value ketika sudah di unmount. Force Unmount pada linux merupakan proyek tersendiri dapat di akses di Force Unmount merupakan modul kernel yang sudah ada untuk kernel versi 2.6 atau di atasnya. 2.4 Monitoring - Memory Monitoring Memory Memory, dapat diartikan sebagai sebuah semikonduktor yang isinya dapat diakses (dibaca atau ditulis), umumnya pada kecepatan yang sangat tinggi namun hanya bersifat sementara/volatile (misalnya pada saat digunakan atau saat masih ada power)[lin04b]. Memory saat ini ada beberapa jenis mulai dari registers, cache, main memory (RAM), ROM, magnetic disk, magnetic tape dan sebagainya. Registers, cache, dan RAM termasuk pada volatile memory, sedangkan II-12

13 magnetic disk dan magnetic tape termasuk non-volatile memory. Pada CGL Availability Requirements 4.3 dan 4.4 [OSD07a] memori yang dimaksudkan adalah main memori atau yang lebih dikenal dengan RAM (Random Access Memory) ditambah dengan virtual memory yang digunakan sebuah proses (program yang sedang dieksekusi). Pada Random Access Memory (RAM), kita dapat mengakses lokasi manapun pada memori pada suatu saat secara acak. RAM memiliki kecepatan akses sampai 10ns. RAM saat ini memiliki kapasitas yang beragam mulai dari 64 MB sampai dengan 4 GB. Biasanya kecepatan aksesnya mencapai beberapa ratus kali dari 1 cycle pada CPU Komputer yang ada saat ini masih memakai arsitektur Von Neumann yang dikenal sebagai stored program concepts. Pada arsitektur ini memori memiliki peran penting sebagai penyimpan data ataupun program yang sedang digunakan atau dieksekusi oleh CPU. Termasuk kernel yang merupakan inti dari sistem operasi juga di simpan di RAM saat sistem operasi sedang berjalan. Gambar II-10 Arsitektur Von Neumann [WPS05] Karena kapasitas RAM sangat terbatas dan memiliki harga yang relatif mahal, sedangkan proses yang menggunakan RAM jumlahnya sangat banyak. Maka dari itu kita mengenal apa yang disebut dengan virtual memory. Virtual memory merupakan storage yang disimulasi sebagai II-13

14 main memory sehingga dapat lebih meningkatkan pembagian RAM pada proses-proses lain yang membutuhkan. Virtual memory menggunakan teknik tertentu yang disebut paging. Paging adalah teknik untuk mengelola virtual address space (page). Paging menyangkut kapan harus menyimpan memory tidak aktif ke storage (virtual memory) dan kapan harus meload memory itu ketika dibutuhkan di main memory. Pada sistem operasi Linux terdapat 3 tingkat page table (struktur data pada virtual memory). Tingkatan ini untuk memudahkan pengaksesan pada virtual memory yang besar (pada umumnya ukuran virtual memory lebih besar dari ukuran RAM). Tiga tingkat itu yaitu; global directory, page middle directory, dan page table. Gambar II-11 Paging Stucture di Linux [TAN01] Pada virtual memory dikenal teknik yang disebut memory mapped, ini merupakan cara memetakan sebagian dari file ke main memory dan mendapatkan pointer-nya. Keuntungan utama dari memory mapping adalah meningkatkan performansi terutama jika ukuran file kecil. Mengakeses memory mapped files lebih cepat daripada menggunakan fungsi read atau write biasa. Dengan alasan memakai system call memerlukan tingkatan proses tertentu yang lebih lambat dibandingkan akses langsung ke memory program. Alasan lain kebanyakan dari sistem II-14

15 operasi wilayah memory mapped merupakan kernel file cache yang tidak memerlukan kopi di user space. Sedangkan menggunakan system call membutuhkan waktu untuk mengkopi memori. Selain virtual memory ada teknik lain untuk pengolahan main memory, teknik ini dikenal dengan swapping. Pada swapping program di-swap dari storage ke main memory ataupun sebaliknya tidak seperti paging yang hanya memindahkan pada bagian page table tertentu saja. Proses swapping meninggalkan banyak lubang di memory karena itu pada perkembangannya semakin dioptimalisasi dengan hanya memindahkan segment tertentu dari program. Pada perkembangannya swapping semakin mendekati atau mirip paging. Pada Linux ada yang dikenal dengan swap space/area, yaitu space pada storage yang digunakan untuk menampung kelebihan data yang tidak dapat ditampung oleh memory. Sewaktu melakukan instalasi Linux disarankan untuk membuat partisi swap sendiri dan biasanya berukuran 2 kali ukuran RAM Memory Monitoring Pada CGL AVL 4.3 [OSD07a] disyaratkan bahwa sistem operasi memenuhi CGL harus mampu me-monitor kondisi memory yang ada, aplikasi pada user space harus disediakan fasilitas untuk melihat kondisi memory sesuai dengan threshold (batasan) yang ditetapkan. Threshold yang ada harus bisa berubah dan diprediksi berdasarkan kondisi memory yang ada untuk menghindari kondisi OOM (out of memory). Batasan yang ada menyangkut RAM maupun swap space. Fasilitas itu juga harus mampu menyimpan sejumlah proses yang dinyatakan mengkonsumsi memory, jika threshold tercapai maka proses tertentu dapat dihentikan. Pada AVL 4.4 [OSD07a] juga dinyatakan perlunya notifikasi kondisi low-memory pada komputer lain. Salah satu proyek memory monitoring di Linux adalah CKRM (Class-based Kernel Resource Management). CKRM atau dibangun oleh 4 orang ahli dari IBM (Shailabh Nagar, Chandra II-15

16 Seetharaman, Hubertus Franke, dan Vivek Kashyap), bersama seorang ahli dari Red Hat (Rik van Riel) dan seorang peneliti dari Columbia University (Haoqiang Zheng). CKRM merupakan kumpulan dari modifikasi terhadap kernel linux untuk memungkinkan manajemen resource[nag04]. Ide dari CKRM adalah mengendalikan dan memonitor penggunaan resource melalui user-defined group dari objek kernel yang disebut kelas. Kelas dapat didefinisikan untuk memetakan antar aplikasi, workloads dan users dalam pemakaian mereka terhadap resource seperti CPU, pages, disk I/O, jumlah file handle dan sebagainya. Gambar II-12 CKRM Design [SOU06] Selain CKRM terdapat juga framework lain yang mendukung manajeman resource pada Linux yaitu Performance Co-Pilot atau PCP. PCP merupakan salah satu proyek open source dari SGI, yang merupakan pengembang perangkat lunak yang berkantor pusat di California, Amerika Serikat. Berbeda dengan CKRM yang berada pada lapisan kernel, PCP berada pada tingkat aplikasi. PGP memungkinkan pemograman yang lebih mudah di tingkat aplikasi dengan mendefinisikan aturan-aturan tertentu untuk monitoring. PCP juga memungkinkan melakukan monitoring terpusat untuk host yang berbeda-beda di jaringan. PCP sebenarnya lebih ditujukan II-16

17 pada sistem operasi IRIX yang juga dikeluarkan oleh SGI, namun PCP dapat juga digunakan pada sistem operasi Linux dengan beberapa fungsi yang tidak disediakan. PCP menyediakan sejumlah layanan yang cukup banyak dan dapat digunakan untuk monitoring dan mengolah performansi sistem. Layanan ini mampu mengakomodasi sistem sederhana sampai dengan sistem jaringan yang lebih kompleks. PCP ditujukan untuk performance analyst, benchmarker, capacity planner, developer, database administrator, dan lainnya. PCP dapat memonitor single sampai multi hosts, namun PCP menyarankan agar arsitektur jaringan berupa client-server. PCP mampu mendeteksi kegagalan pada host tertentu. PCP juga secara otomatis menyediakan log terhadap sistem yang sedang di monitor[goo99]. Pada PCP untuk melakukan monitoring diperlukan ada beberapa service yang berjalan dibackgound, seperti pmcd (Performance Metrics Collection Daemon) dan pmie (Performance Metrics Inference Engine). Pmcd berfungsi untuk menghimpun dan memberikan data informasi untuk monitoring, dan pmie menyediakan engine untuk monitoring secara otomatis [GOO99]. Gambar II-13 Arsitektur PCP [MCD99a] II-17

18 2.5 Redundancy - Ethernet Link Bonding Ethernet Ethernet dijabarkan pada standar IEEE 802.3, yang terdiri dari kabel coaxial dimana sejumlah komputer terhubung padanya. Ethernet pada awalnya merupakan eksperimen oleh perusahaan Xerox pada tahun 1970 yang mencapai kecepatan 3 Mbps. Saat ini Ethernet ada beberapa versi kecepatan, 10 Mbps, 100 Mbps, atau bahkan yang mencapai 1 Gbps atau lebih. Untuk mengirim paket, komputer pertama kali perlu melakukan sensing pada medium/kabel apakah sedang digunakan atau tidak. Jika tidak sedang ada transmisi atau tidak dipakai maka paket dapat dikirimkan termasuk header-nya. Terkadang diperlukan beberapa mekanisme tertentu sebelum pengiriman paket data. Jika 2 komputer mengirim bersama maka akan terjadi collision yang dapat dideteksi masing-masing komputer, salah satu cara menanganinya adalah dengan membangkitkan sejumlah bilangan random masing-masing dan melakukan pengiriman lagi. Jika terjadi tabrakan lagi maka jangkauan bilangan acak yang ada diperbesar 2x sehingga kemungkinan collision semakin berkurang. Saat ini dengan adanya switch kemungkinan collison semakin kecil. Hal ini karena paket yang diterima di switch akan di simpan di sana kemudian diteruskan untuk dikirim melalui port yang sudah khusus diberikan untuk setiap komputer. Gambar II-14 Ilustrasi Ethernet II-18

19 2.5.2 Ethernet Link Bonding Ethernet bonding adalah istilah yang dipakai untuk menunjukkan metode untuk melakukan agregasi sejumlah network interface menjadi sebuah interface saja. Gambar II-15 Ilustrasi Ethernet Bonding CGL Availability AVL 21.0 menyebutkan bahwa sistem operasi yang termasuk CGL harus mampu melakukan NIC bonding yang meliputi kemampuan untuk melakukan agregrasi sejumlah interface jaringan pada IPv4 dan kemampuan untuk melakukan failover jika salah satu interface mengalami gangguan. Sistem operasi Linux dengan kernel versi 2.6 telah mendukung ethernet bonding, namun dibutuhkan perangkat lunak tambahan untuk membantu proses bonding tersebut. Perangkat lunak tersebut seperti; net-tools, iputils, ifenslave dan perangkat lunak lainnya yang sejenis. Pada bonding terdapat istilah master dan slave, master merupakan interface baru hasil bonding sejumlah slave NIC. Proses bonding 2 NIC atau lebih perlu memperhatikan mode dan kemampuan NIC mendukung mode tersebut. Jika NIC tidak mampu mendukung mode tertentu maka bonding bonding dengan mode tersebut tidak dapat dilakukan. Pada bonding terdapat beberapa mode yaitu [DAV06]: 1. Round Robin (mode 0), pada mode ini NIC yang aktif diberi giliran untuk transmit yang bergantian sehingga beban NIC berkurang. II-19

20 2. Active-Backup (mode 1), jika hanya 1 slave NIC yang aktif slave lain akan membantu hanya jika NIC tersebut fail, semua interface card akan di bond ke MAC addres yang sama. 3. Balanced-XOR (mode 2), mengirim berdasarkan hash policy, yang default-nya adalah hasil XOR dari MAC tujuan dan MAC asal. 4. Broadcast (mode3), mengirim semua paket melalui semua NIC slave 5. Dynamic link aggregation-802.3ad (mode 4), membentuk sejumlah aggregasi kecepatan sesuai spesifikasi 802.3ad. II-20