IMPLEMENTASI PEMANTAUAN SIMPUL-SIMPUL JARINGAN DENGAN PROTOKOL SNMP MENGGUNAKAN PYTHON-FUSE

IBNU FEBRY K. - 5106100091 1

IMPLEMENTASI PEMANTAUAN SIMPUL-SIMPUL

JARINGAN DENGAN PROTOKOL SNMP MENGGUNAKAN

PYTHON-FUSE

Ibnu Febry K. – Wahyu Suadi, S.Kom, M.Kom, Bagus Jati S., S.Kom

Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember, Email: ibnu06@cs.its.ac.id, wahyu@its-sby.edu, bagus@if.its.ac.id

Abstrak Seiring dengan perkembangan

teknologi jaringan komputer, keperluan untuk memantau keadaan simpul-simpul jaringan juga semakin tinggi. Hal ini terbukti dengan dibuatnya

protokol SNMP untuk memudahkan para

administrator jaringan untuk melakukan

pemantauan jaringan. Dengan adanya protokol SNMP ini, dimungkinkan seorang pengguna melihat ataupun mengubah properti dari suatu simpul jaringan. Karena banyaknya jumlah properti dari suatu simpul yang dapat dipantau, tak sedikit aplikasi-aplikasi yang dikembangkan untuk menjawab keperluan ini.

Tugas akhir ini dibuat agar pengguna dapat melakukan pemantauan keadaan simpul-simpul dengan representasi suatu sistem berkas. Sehingga untuk memantau keadaan simpul-simpul yang sedang dimonitor cukup dengan mengamati isi dari berkas. Objek yang diamati oleh aplikasi ini dapat berupa keadaan CPU, RAM serta proses yang sedang berjalan di dalam suatu komputer. Seiring dengan pesatnya perkembangan SNMP ini, banyak piranti-prainti jaringan yang menyertakan agen secara built-in yang mendukung SNMP. Objek-objek ini akan dikelompokkan berdasarkan alamat IP simpul jaringan dan waktu pengambilan data. Karena bersifat memantau, aplikasi ini hanya dapat membaca nilai dari objek-objek tersebut dan tidak dapat menerima trap dari simpul-simpul yang sedang dipantau.

Tugas akhir ini dikembangkan dengan bahasa Python dengan library FUSE yang disebut

Python-FUSE dan library PySNMP untuk

pengaplikasian protokol SNMP.

Kata kunci: Pemantauan, Simpul Jaringan, Filesystem, Python, FUSE, SNMP.

1. PENDAHULUAN

Seiring dengan bertambah kompleksnya jaringan komputer pada kehidupan TI, maka perlu bagi administrator jaringan untuk memiliki suatu cara yang mudah dan umum dalam hal melakukan kontrol terhadap komponen-komponen pada jaringan. Hal yang perlu dikontrol oleh seorang

administrator dapat berupa sumber daya yang

terpakai, status lalu lintas data ataupun proses yang

sedang berjalan. Jika elemen-elemen jaringan yang dikontrol berjumlah kurang dari 10, tentu hal tersebut tidak menjadi masalah tapi sangat melelahkan jika berjumlah ratusan.

Salah satu solusi yang cukup umum untuk mengatasi hal tersebut adalah protokol SNMP (Simple Network Management Protocol). SNMP ini sangat membantu pekerjaan para administrator dalam melakukan monitoring perangkat-perangkat jaringan dengan perintah-perintah yang mudah dipahami secara jarak jauh atau disebut remotely. SNMP akan mengambil informasi, biasanya disebut query, baik sumber daya yang digunakan maupun proses-proses yang sedang berjalan.

Implementasi protokol SNMP pada manajer menimbulkan kekhawatiran karena informasi simpul yang diperoleh dan disimpan pada suatu

folder dapat diakses oleh pengguna yang memiliki

hak previllege yang lebih tinggi. Oleh karena itu, implementasi teknologi FUSE (Filesystem in

USErspace) dapat menjadi salah satu solusi yang

cukup ampuh. Informasi-informasi simpul yang dimonitor akan direpresentasikan dalam bentuk hierarki suatu filesystem. Dengan adanya FUSE, seorang pengguna dapat membuat filesystem sesuai dengan keinginan tanpa bantuan seorang super

user dan FUSE hanya dapat diakses oleh pengguna

yang membuatnya. Sehingga, pada tugas akhir ini penulis mencoba merepresentasikan informasi simpul, dalam hal ini komputer, dalam suatu sistem berkas.

2. SNMP

Pada dunia SNMP, dikenal dua istilah yakni manajer dan agen. Suatu manajer adalah suatu

server yang menjalankan beberapa sistem piranti

lunak yang mampu menangani tugas pengaturan dari suatu jaringan. Manajer seringkali ditujukan kepada NMS (Network Managemet Stations). Suatu NMS bertanggung jawab untuk melakukan

polling dan menerima trap dari agen-agennya pada

suatu jaringan.

Suatu poll, pada konteks pengaturan jaringan, dapat berupa suatu tindakan meminta beberapa informasi kepada suatu agen. Agen dapat berupa suatu router, switch¸ komputer, dan lain-lain. Informasi ini dapat digunakan selanjutnya untuk menentukan apakah suatu even yang ingin dihindari telah terjadi.

IBNU FEBRY K. - 5106100091 2

memberitahu NMS bahwa suatu hal telah terjadi.

Trap dikirimkan secara asinkron dan bukan suatu

respon dari query yang dikirimkan oleh NMS. Selanjutnya, berdasarkan trap yang diterima NMS, akan ditentukan tindakan yang akan dilakukan terhadap agen tersebut.

Istilah kedua, agen, adalah suatu piranti lunak yang berjalan pada simpul jaringan yang dimonitor. Agen dapat berupa suatu program yang terpisah (daemon dengan bahasa UNIX) atau tergabung di dalam sistem operasi (contohnya IOS milik Cisco pada suatu router atau sistem operasi

low-level yang mengontrol UPS). Agen

menyediakan informasi manajemen kepada NMS dengan mengamati beberapa aspek suatu simpul.

SNMP menggunakan UDP sebagai protokol transportasi untuk mengirimkan data antara manajer dan agen, UDP, didefinisikan pada RFC 768, lebih dipilih daripada TCP karena sifatnya

connectionless sehingga tidak ada koneksi end-to-end yang dibuat antara agen dengan manajer.

Aspek inilah yang membuat UDP menjadi tidak dapat diandalkan karena tidak ada pengetahuan datagram yang hilang pada tingkat protokol. SNMP menentukan apakah datagram telah hilang dan mengirim ulang jika diinginkan. Hal ini ditandai dengan adanya timeout sederhana.

SNMP menggunakan port UDP 161 ketika mengirimkan dan menerima permintaan query dan port UDP 162 untuk menerima trap dari simpul jaringan. Setiap simpul yang mengimplementasikan UDP harus menggunakan port ini secara default, namun beberapa vendor memperbolehkan penggantian port ini. Jika penggantian port dilakukan, maka NMS juga harus dilakukan penyesuaian.

3. Format Pesan SNMP

Tiap protokol tentunya memiliki standar pesan yang digunakan. Format pesan SNMP menentukan

filed apa sajakah yang dimasukkan ke dalam pesan

berikut dengan urutannya. Pada lapisan terluar pada format pesan protokol SNMP versi 2, terdapat beberapa elemen penting dalam format pesannya yakni :

 SNMP version

 SNMP community string



SNMP PDU

Sehingga dari uraian di atas, pada blok pesan SNMP terdapat 3 sub-blok utama pada pesan SNMP. Untuk ilustrasinya berikut dengan tipe datanya dapat dilihat pada gambar

SNMP Message (Sequence) SNMP Version (Integer) SNMP Community String (Octet String) SNMP PDU (GetRequest, GetNextRequest, etc)

Gambar 1 Format Pesan SNMP v2 (1)

Karena SNMP Version dan SNMP Community String adalah tipe data primitif, keduanya tidak tersusun dari field yang lebih kecil (tidak ada lapisan dibawahnya lagi). SNMP PDU merupakan tipe data kompleks yang tersusun dari beberapa field yang lebih kecil di dalamnya. SNMP PDU terdiri dari sebuah Request ID, Error, Error Index dan Varbind List. Varbind List adalah Sequence yang terdiri dari 2 field spesifik, yakni OID yang merupakan parameter spesifik dan nilai dari OID tersebut. Sehingga, pesan SNMP dapat dilihat sebagai berikut :

SNMP Message (Sequence) SNMP Version (Integer) SNMP Commu nity String (Octet String) SNMP PDU (Sequence) Requ est ID (integ er Erro r (Inte ger) Varbind List (Sequence) Varbind (Sequence) OID Value (Integ er, etc)

Gambar 2 Format Pesan SNMPv2 (2)

4. FUSE

FUSE ialah suatu library yang memungkinkan suatu aplikasi yang berada dalam lingkup pengguna atau userspace bisa berperan sebagai sistem berkas (filesystem) yang direferensikan oleh kernel. Library ini tercatat telah berjalan di berbagai sistem operasi, antara lain : GNU/Linux, Unix, MacOS, bahkan Microsoft Windows.

Di GNU/Linux, modul kernel dan library ini berkomunikasi melalui suatu file descriptor khusus yang diperoleh dari membuka /dev/fuse. Berkas ini dapat dibuka berkali-kali dan file descriptor yang diperoleh akan diberikan kepada syscall mount untuk dipasangkan dengan descriptor milik sistem berkas yang di-mount.

FUSE adalah suatu modul kernel pada sistem operasi yang mirip dengan UNIX yang mengijinkan pengguna selain administrator untuk membuat sistem berkasnya sendiri tanpa harus mengubah kernel. Hal ini bisa tercapai dengan menjalankan kode sistem berkas pada tingkatan pengguna dengan FUSE sebagai “jembatan” dengan interface kernel sebenarnya. FUSE secara resmi masuk dalam source code kernel linux sejak linux versi 2.6.14.

FUSE sangat bermanfaat untuk membuat sistem berkas virtual. Tidak seperti sistem berkas tradisional, yang menulis dan membaca data dari disk, sistem berkas virtual tidak melakukan penyimpanan sendiri. FUSE berfungsi sebagai mediasi dengan sistem berkas triadisional yang memegang penulisan dan pembacaan data secara fisik pada disk. Sistem berkas virtual tersebut akan berfungsi sepenuhnya sebagai sistem berkas tapi belum tentu benar-benar menulis ke suatu media

IBNU FEBRY K. - 5106100091 3

penyimpanan. Sistem berkas virtual ini hanya menjadi jembatan komunikasi dengan layer dibawahnya yang bisa berupa sistem berkas lain atau bahkan suatu sistem yang tidak berkaitan dengan media penyimpanan sama sekali.

Gambar 3 Diagram Cara Kerja FUSE

Seperti yang terlihat pada gambar diatas, suatu operasi berkas atau direktori yang dilakukan oleh pengguna akan „dikirimkan‟ masuk melalui ke glibc untuk selanjutnya diteruskan ke kernel. Di dalam kernel, operasi tersebut akan ditangani oleh Virtual File System (VFS). Karena yang diakses oleh pengguna adalah FUSE, maka request tersebut diteruskan ke library FUSE dan selanjutnya akan diproses dengan program yang berjalan pada lingkup pengguna (userspace) untuk memberikan respon atas request yang dikirimkan.

Respons yang diberikan oleh program yang berada di userspace akan dikirmkan kembali melalui kernel melalui library FUSE dan glibc. Selanjutnya diteruskan ke pengguna oleh VFS. Dengan alur yang demikian, FUSE memberikan suatu fleksibilitas yang cukup besar bagi pengembang untuk membuat sistem berkas sesuai dengan kebutuhan.

FUSE telah didukung oleh banyak bahasa pemrograman karena banyaknya keberadaan

wrapper oleh masing-masing bahasa. Sebagai

contoh bahasa Python telah memberikan suatu

library Python-FUSE yang mampu menyuguhkan

fitur-fitur FUSE.

5. DESAIN DAN IMPLEMENTASI

Pengerjaan tugas akhir ini akan membangun suatu aplikasi yang diberi nama SNMPFS. Aplikasi ini memiliki antarmuka berupa suatu sistem berkas. Aplikasi ini memberikan kemudahan kepada pengguna, dalam hal ini adalah manajer SNMP, untuk memantau / memonitor keadaan simpul-simpul jaringan yang diawasi pada suatu subnet. Simpul-simpul jaringan yang dipantau dalam aplikasi ini terbatas pada simpul yang mendukung SNMP. Aplikasi ini dikembangkan dengan library Python-FUSE sebagai wrapper FUSE untuk keperluan antarmuka sistem berkas.

Aplikasi ini bertujuan untuk memberikan kemudahan kepada pengguna untuk memantau

kondisi-kondisi komputer di subnet tertentu dengan antarmuka sebuah sistem berkas. Dengan digunakannya FUSE sebagai implementasi sistem berkas, data-data yang ditampilkan pada suatu susunan direktori dan berkas akan lebih aman. Dikatakan lebih aman karena sistem berkas yang telah di-mount oleh pengguna tertentu, tidak dapat diakses oleh pengguna lain. Selain itu pengguna dapat melakukan kustomisasi penyajian informasi serta OID yang dipantau sesuai dengan keinginan pengguna.

5.1. Arsitektur Aplikasi

Aplikasi ini akan terbagi menjadi 3 modul utama, yakni modul pengambilan data / polling secara berkala dari agen ke manajer dan modul sistem berkas sebagai antarmuka untuk menampilkan data kepada pengguna. Masing-masing modul menggunakan library tambahan yang berbeda-beda yang akan dijelaskan lebih lanjut pada bab 4.

Modul pertama, yakni pengumpulan data, merupakan implementasi dari peran seorang manajer dalam suatu NMS. Modul ini berupa suatu program thread yang berjalan terus menerus, dapat disebut daemon, yang akan melakukan pengambilan data mengenai kondisi objek yang sedang dimonitor di tempat agen „hidup‟ secara berkala. Objek yang sedang dimonitor tersebut berupa kondisi CPU (CPU time, Idle CPU time, User CPU time, dan lain-lain), kondisi RAM (RAM free, RAM used, RAM buffered dan lain-lain) serta proses-proses yang sedang berjalan (PID, Process Name, Parameter, CPU usage, dan lain-lain) dan dapat ditambahkan pada berkas konfigurasi.

Objek-objek yang dimonitor dan selanjutnya akan diambil nilai-nilainya dapat dituliskan pada berkas konfigurasi (app.conf). Pada berkas inilah pengguna menentukan alias objek, OID serta deskripsi mengenai suatu objek yang dimonitor untuk selanjutnya ditentukan objek ini termasuk pada kategori informasi yang mana.

Modul kedua, yakni antarmuka aplikasi, adalah implementasi dari penyampaian informasi dari agen yang telah dimasukkan ke basis data. Antarmuka ini akan menyuguhkan informasi dari mesin basis data dikelompokkan berdasarkan komputer agen dan waktu data-data tersebut diambil. Pada tingkat atas akan terdapat direktori-direktori dengan label alamat IP komputer-komputer yang dimonitor. Selanjutnya, pada tingkatan kedua sistem berkas akan terlihat direktori-direktori dengan label waktu (jam dan tanggal) data-data tersebut diambil. Pada tingkatan ketiga, terdapat berkas-berkas dengan label kategori informas akan ditampilkan (data CPU, data RAM dan lain-lain).

Sistem berkas yang akan dibuat bersifat

IBNU FEBRY K. - 5106100091 4

berkas dengan label-label kategori yang telah ditentukan dalam berkas konfigurasi. Fungsi-fungsi standar sistem berkas seperti write, mkdir, mknod, rmdir dan fungsi-fungsi lain yang sifatnya memodifikasi isi suatu sistem berkas akan dihilangkan / tidak diimplementasikan.

Ketika seorang pengguna membaca sebuah berkas, maka sistem berkas melalui fungsi read akan melakukan SQL query dengan argumen path berkas tersebut. Contohnya, seorang pengguna akan membuka berkas dengan label CPU load

yang terletak pada alamat

mountpoint/127.0.0.1/21122009_150015/C PU load, maka SQL query akan mencari data CPU load milik 127.0.0.1 dengan waktu pengambilan 21122009_150015. Sedangkan, mountpoint/ merupakan direktori tempat sistem berkas ini di-mount.

Modul ketiga, yakni media penyimpanan data.. Modul inilah yang menghubungkan antara modul 1 dan 2. Menghubungkan dalam hal ini artinya data yang telah diambil atau dikumpulkan oleh modul 1 dapat dilihat dan ditampilkan oleh modul 2 melalui modul ini. Modul ini menyediakan fungsi-fungsi yang berhubungan dengan pemasukan (insert), dan pengambilan (select) data. Karena basis data yang digunakan memiliki fitur serverless, akses ke basis data tidak terasa lambat namun secepat pembacaan teks pada suatu berkas di dalam komputer.

Berikut diagram alir aplikasi yang dibuat :

database file SNMP manager SNMP agent SNMP agent SNMP agent filesystem data query SNMP query SNMP query SNMP query object values object values object values object values user categories data our application

Gambar 4 Arsitektur Aplikasi

6. Uji Coba

Pada bab ini akan dibahas tentang hasil uji coba dan analisa kinerja aplikasi yang dibuat. Uji coba ini akan dibagi menjadi dua studi kasus meliputi uji coba fungsionalitas dan uji coba performa.

6.1. Uji fungsionalitas

Karena bertujuan untuk menguji fungsi 4ystem berjalan sesuai dengan desain 4ystem. Uji coba fungsionalitas ini meliputi beberapa pengujian fungsi-fungsi pokok, seperti mounting, proses baca dan tulis, unmounting.

Sehingga 4 ystem 4 o yang disusun untuk uji coba antara lain:

 Uji coba mounting sistem berkas

 Uji coba kontrol polling thread

 Uji coba polling data dari agen

 Uji coba penampilan kategori informasi suatu jenis simpul yang dimonitor

 Uji coba pembacaan berkas informasi pada sistem berkas



Uji coba unmounting sistem berkas Parameter untuk menentukan keberhasilan jalannya fungsi apikasi adalah dengan memperhatikan log dari 4 ystem berkas, manajer dan pembacaan berkas informasi.

Pada uji coba ini aku diperlihatkan isi dari kategori informasi dengan antarmuka berupa sistem berkas yang telah dibuat. Sistem berkas yang telah dibuat akan menampilkan isi direktori dengan mengubah isi method filesystem call pada

class FUSE dengan melakukan query SQL pada

basis data. Sebelumnya, jika basis data kosong maka proses polling data dari agen gagal. Seperti yang diketahui proses polling data termasuk proses pengambilan dan penyimpanan data.

Pada gambar di bawah ini proses polling data telah berhasil sebelumnya, dan dilakukan perintah

ls pada sistem berkas.

Gambar 5 Hasil Eksekusi Perintah ls

6.2. Uji performa

Uji coba ini direncanakan dengan melakukan

polling data kepada agen pada masing-masing

simpul dengan jumlah simpul yang berbeda. Uji coba ini melibatkan 3 jenis simpul yang berbeda, yakni workstation, router, dan switch. Workstation yang digunakan untuk polling menggunakan sistem operasi yang berbeda-beda, mulai Debian, Ubuntu, Kubuntu, Windows XP SP2, Windows Server 2008, dan Windows 7. Perbedaan sistem operasi yang digunakan karena ingin dibuktikan SNMP juga dapat bekerja pada sistem operasi yang bermacam-macam. Adanya variasi jumlah simpul ini ditujukan agar dipunyai pembanding jika jumlah simpul ini berubah sehingga menghasilkan waktu total polling data yang berbeda.

IBNU FEBRY K. - 5106100091 5

Jumlah simpul-simpul tersebut antara lain:

 5 simpul (3 workstation + 1 switch + 1 router)

 10 simpul (8 workstation + 1 switch + 1 router)

 15 simpul (13 workstation + 1 switch + 1 router)

Polling data melibatkan 21 OID (18 OID scalar + 3 OID tabular) untuk Workstation dan 2

OID (1 scalar + 1 tabular) untuk jenis simpul lain. Setiap kali melakukan polling akan diulangi sebanyak 5 kali uji coba lalu dicari rata-ratanya sehingga hasil dari uji coba ini dapat dilihat perbedaan waktu.

Pengujian untuk masing-masing perintah dilakukan sebanyak 5 kali. Hasilnya adalah sebagai berikut :

Percobaan

Waktu Pengiriman (dalam detik) 5 10 15 1 34,950 68,410 98,410 2 36,90 70,650 99,700 3 37,240 66,920 98,490 4 37,960 69,110 98,020 5 37,080 69,300 98,570 Rata-rata 36,826 68,878 98,638 7. SIMPULAN

Dari serangkaian uji coba dan analisa yang dilakukan terhadap sistem yang dibuat, maka dapat dibuat kesimpulan antara lain :

1.

Waktu polling data yang diperlukan berbanding lurus dengan jumlah simpul yang dimonitor, semakin banyak jumlah simpul yang dimonitor maka semakin banyak pula waktu yang dibutuh-kan untuk melakukan polling.

2.

Simpul dengan sistem operasi Windows XP SP 2 memiliki waktu polling yang paling stabil atau tidak fluktuatif.

8. DAFTAR PUSTAKA

[1] Anonim. ____. Linux SNMP OIDs for CPU Memory and Disk Statistics, URL

<http://www.debianadmin.com/linux- snmp-oids-for-cpumemory-and-disk-statistics.html>. Diakses pada Oktober 2009

[2] Anonim. ____. sqlite3- DB-API 2.0 Interface for SQLite Databases, URL<http://docs.python.org/library/sqli te3.html>. Diakses pada November 2009

[3] Anonim. 2009. The Net-SNMP Wiki, URL

<http://www.net-snmp.org/wiki/index.php/Main_Page>. Diakses pada November 2009

[4] Brueck, Dave, dkk. 2001. Python Bible. Hungry Minds, Inc.

[5] Chun, Wesley J. 2001. Core Python Programming. Deitel

[6] Cisco. 2005. Catalyst 3750 Switch Software Configuration Guide. Cisco [7] D-Link. 2003. D-LinkTM DGS-3224TGR

Managed 24-Port Gigabit Ethernet Switch User’s Guide. D-Link

[8] Etingof, Ilya. 2007. PySNMP Tutorial, URL

<http://pysnmp.sourceforge.net/docs/4.x /index.html>. Diakses pada Oktober 2009

[9] Masyarakat Digital Gotong Royong. 2008. Pengantar Sistem Komputer, URL <http://free.vlsm.org/v06/Kuliah/Sistem Operasi/BUKU/SistemOperasi-4.X-2/index.html>. Diakses pada Desember 2009

[10] Mauro, Douglas & Schmidt, Kevin. 2005. Essential SNMP, 2nd Edition. O‟Reilly [11] Scott. 2008. Simple Filesystem How to in

Python,

URL<http://sourceforge.net/apps/media wiki/fuse/index.php?title=SimpleFilesys temHowto>. Diakses pada Oktober 2009

[12] Stallings, William. 1998. SNMPv3 : A Security Enhancement for SNMP. IEEE Communications Survey

[13] SQLite Team. _____. SQLite Documentations, URL < http://www.sqlite.org/ >. Diakses pada November 2009

[14] Tamura, Koichi. 2009. FUSE Text

Implementation, URL

<http://koichitamura.blogspot.com/2009 /03/fuse-text-implementation.html>. Diakses pada Oktober 2009