BAB III METODOLOGI PENELITIAN Dalam penelitian ini penulis

13
BAB III
METODOLOGI PENELITIAN
Dalam penelitian ini penulis akan melakukan penelitian terhadap hasil virtualisasi pada
sebuah controller. Melalui virtualisasi, sebuah controller dibagi menjadi beberapa
instansi controller dan berada dalam perangkat yang sama. Dengan konsep ini, setiap
switch hanya berkomunikasi dengan controller yang menjadi master baginya. Hal ini
dapat dilihat pada Gambar 3.1.
Gambar 3.1. Pembagian instansi pada controller
Penelitian akan dilakukan dengan dua komponen perangkat lunak yaitu Mininet
(untuk emulasi jaringan Openflow) dan menggunakan controller Open Network
Operating System (ONOS) yang diinstalasi ke dalam sistem operasi Linux Ubuntu
Server 14.04 LTS 64 bit. Controller ONOS yang telah terinstalasi
Universitas Sumatera Utara
14
dihubungkan dengan skenario topologi/sistem jaringan yang telah diemulasi dengan
Mininet.
3.1
Rancangan Penelitian
Adapun rancangan yang akan dilakukan untuk dapat melakukan penelitian adalah
sebagai berikut :
1. Perancangan topologi dan emulasi dengan konfigurasi Mininet.
2. Instalasi ONOS pada sistem operasi server.
3. Konfigurasi container dengan Linux Containers (LXC)
4. Konfigurasi ONOS terhadap tiap container yang terbentuk.
Dalam penelitian ini, penulis akan menggunakan 3 topologi masing-masing
menggunakan satu, dua dan tiga instansi controller dalam sebuah controller. Skenario
ini dapat dilihat pada Gambar 3.2.
Universitas Sumatera Utara
15
Gambar 3.2. Skenario topologi penelitian
Universitas Sumatera Utara
16
Dari ketiga skenario tersebut, akan diukur nilai throughput dan latency antar
host yang didapat. Nilai throughput akan dilihat dan dibandingkan dengan keadaan
tanpa pembagian instansi. Dari rencana penelitian ini, akan dilihat efektifitas dan
pengaruh dari pembagian fungsi kontrol pada controller. Flowchart dari proses
penelitian dapat dilihat pada Gambar 3.3.
Gambar 3.3. Flowchart proses penelitian
Universitas Sumatera Utara
17
3.2
Proses Penelitian
3.2.1
Emulasi jaringan dengan Mininet
Mininet merupakan perangkan lunak yang dapat membangun emulasi sebuah
jaringan Openflow, dimana Mininet mendukung Openflow versi 1.0, namun
dapat dirancang untuk dapat menjalankan perangkat lunak switch yang
menggunakan versi yang terbaru (Azodolmolky, 2013). Dalam sebuah mesin
tunggal baik perangkat keras komputer, virtual maupun melalui media cloud,
Mininet dapat membangun sebuah jaringan dengan komponen virtual seperti
switch, controller maupun link yang menghubungkan. Jaringan yang dibentuk
oleh Mininet menjalankan code yang sesungguhnya, termasuk aplikasi jaringan
Unix/Linux yang sesungguhnya termasuk kernel yang sesungguhnya juga.
Dengan demikian, jaringan maupun code yang dikembangkan dan diuji pada
Mininet untuk controller Openflow, swith maupun host dapat dipindahkan ke
sistem yang sesungguhnya dengan perubahan yang minimal, untuk uji coba pada
sistem yang sesungguhnya, evaluasi performa, maupun pengembangan dan
penelitian (Mininet Overview, 2016).
Tampilan awal dari Mininet dapat dilihat pada Gambar 3.4. Apabila
tidak dilakukan perintah untuk topologi yang dikembangkan, Mininet akan jalan
dengan topologi awal yang terdiri dari sebuah swith (s1), dua buah host (h1 dan
h2) dan sebuah controller (c0), dimana controller akan menggunakan alamat
127.0.0.1 sebagai identitasnya. Pada tampilan tersebut akan terlihat juga link
yang diemulasi untuk menghubungkan host dan switch dalam jaringan.
Gambar 3.4. Tampilan awal Mininet
Universitas Sumatera Utara
18
Sesuai skenario pada Gambar 3.1, Mininet akan digunakan untuk membangun
topologi jaringan. Adapun informasi mengenai parameter perangkat yang akan
dilakukan emulasi dalam Mininet dapat dilihat pada Tabel 3.1.
Tabel 3.1. Tabel informasi perangkat jaringan
Nama
3.2.2
Jenis
Alamat
c0
Controller (instansi 1)
10.0.3.11
c1
Controller (instansi 2)
10.0.3.12
c2
Controller (instansi 3)
10.0.3.13
s1
Switch 1
00:00:00:00:00:01
s2
Switch 2
00:00:00:00:00:02
s3
Switch 3
00:00:00:00:00:03
s4
Switch 4
00:00:00:00:00:04
s5
Switch 5
00:00:00:00:00:05
s6
Switch 6
00:00:00:00:00:06
h1
Host 1
10.0.0.1
h6
Host 6
10.0.0.6
Konfigurasi Open Network Operating System (ONOS)
ONOS merupakan sistem operasi jaringan SDN bersifat open source yang
pertama. Fokus untuk ONOS adalah jaringan service provider dan ONOS telah
dilengkapi fasilitas untuk mempermudah melakukan kontrol terhadap seluruh
perangkat yang mendukung protokol Openflow (The Open Networking Lab,
2014). Spesifikasi perangkat keras minimum yang diperlukan untuk
menjalankan ONOS untuk diinstalasi dalam sebuah virtual machine adalah :
-
Ubuntu Server 14.04 LTS 64-bit
-
2 GB RAM atau lebih
-
2 atau lebih processor
Untuk membangun dan menjalankan ONOS diperlukan :
-
Java 8 SDK
-
Apache Maven 3.3.9
Universitas Sumatera Utara
19
-
Git
-
Bash
-
Apache Karaf 3.0.5
Tampilan CLI dari ONOS setelah instalasi berhasil, dapat dilihat pada Gambar
3.5.
Gambar 3.5. Tampilan CLI dari ONOS
3.2.3
Konfigurasi Linux Containers (LXC)
Linux Containers (LXC) merupakan teknologi virtualisasi ringan. Berbeda
dengan virtualisasi penuh seperti Qemu ataupun VMware, container tidak
mengemulasikan perangkat keras dan setiap container yang dibentuk berbagi
sistem operasi yang sama sebagai host (Ubuntu Documentation, 2015). Hal ini
dapat menghemat sumberdaya seperti CPU, memory dan lain-lain. Dalam
penelitian ini penulis akan melakukan pembagian instansi pada controller
ONOS dengan melalui konfigurasi pada LXC dengan menggunakan
sumberdaya pada sebuah server dengan sistem operasi Ubuntu Server.
Setiap container membutuhkan alamat IP agar dapat terdeteksi dan
terhubung dalam jaringan. Linux bridges digunakan untuk menghubungkan
container yang dibentuk. Pada LXC, bridges yang digunakan dinamai lxcbr0.
Setiap container akan menggunakan virtual Ethernet bridge interface (veth)
yang akan terhubung melalui bridge. Konfigurasi LXC akan dilakukan dalam
penelitian ini untuk melakukan virtualisasi pada sebuah controller, sehingga
Universitas Sumatera Utara
20
terlihat seperti tiga unit controller, dimana ketiganya terhubung melalui sebuah
bridge.
3.2.4
Konfigurasi Wireshark
Wireshark merupakan perangkat lunak open source yang dapat menangkap dan
melakukan decode terhadap paket data dalam jaringan. Proses decode
menggunakan dissector yang dapat mengidentifikasi dan menampilkan nilai
dari paket data dalam jaringan (Chappel, 2013). Untuk instalasi perangkat lunak
ini, dilakukan terhadap sistem operasi utama.
3.2.5
Pengukuran Performa Jaringan
Pengukuran performa jaringan dilakukan dengan dua cara, yaitu pengukuran
throughput dan latency, dimana throughput merupakan jumlah bit yang dapat
dikirimkan dalam jaringan pada periode waktu tertentu dan latency merupakan
lama waktu yang dibutuhkan sebuah pesan data untuk dikirim dari satu titik awal
ke titik akhir. Pengukuran latency diutamakan untuk pengiriman data dari titik
awal ke titika akhir, lalu kembali lagi. Proses ini dinamakan round-trip time atau
RTT ( Peterson & Davie, 2003). Pada penelitian ini, penulis mengukur
throughput dengan menggunakan aplikasi iperf. Iperf merupakan perangkat
lunak open source yang dapat melakukan pengukuran parameter jaringan
menggunakan komunikasi data bidirectional maupun unidirectional melalui
paket Transmission Control Protocol (TCP) maupun User Datagram Protocol
(UDP) dalam prosesnya (Duarte & Pujolle, 2013). Untuk pengukuran latency,
penulis menggunakan protokol ICMP.
3.2
Integrasi Komponen Penelitian
Tampilan hasil dari konfigurasi Mininet dan integrasinya terhadap controller dapat
dilihat pada CLI dari Mininet di Gambar 3.6. Dapat dilihat pada skenario pertama
seluruh switch terhubung pada sebuah controller yaitu c1. Pada skenario kedua ada 2
controller yaitu c1 dan c2, dan pada skenario ketiga terdapat tiga controller yaitu c1, c2
dan c3. Pada tampilan tersebut terlihat terhubungnya jaringan dengan jumlah controller
sesuai skenario penelitian.
Universitas Sumatera Utara
21
Gambar 3.6. Tampilan Mininet untuk skenario penelitian
ONOS dilengkapi dengan GUI untuk melihat tampilan topologi yang dibentuk.
Gambar hasil konfigurasi jaringan terhadap tiga skenario penelitian dapat dilihat pada
Gambar 3.7 dan Gambar 3.8. Dapat dilihat pada GUI, setiap pasangan controller dan
switch digambarkan dengan warna yang sama. Pada CLI, terlihat pasangan dari switch
dengan controller yang menjadi master terhadapnya.
Universitas Sumatera Utara
22
Gambar 3.7. Tampilan GUI pada ONOS untuk skenario penelitian
Universitas Sumatera Utara
23
Gambar 3.8. Tampilan CLI pada ONOS terhadap skenario penelitian
Pada penelitian ini, penulis menamai container yang dibentuk pada LXC
dengan nama instansi-satu, instansi-dua dan instansi-tiga. Untuk veth pada tiap
container penulis menamainya veth-satu, veth-dua dan veth-tiga. Hasil konfigurasi
tersebut dapat dilihat pada Gambar 3.9. Tiap container diberi alamat IP sesuai alamat
pada tiap controller.
Universitas Sumatera Utara
24
Gambar 3.9. Tampilan konfigurasi LXC untuk penelitian
Universitas Sumatera Utara
25
BAB IV
HASIL PENELITIAN DAN PEMBAHASAN
4.1
Hasil Perhitungan Pada Penelitian
4.1.1
Hasil Perhitungan Latency
Pengukuran latency dilakukan terhadap host 1 dan host 6 dengan pengiriman
paket ICMP. Untuk tiap skenario penelitian, dilakukan tiga kali percobaan,
dimana setiap percobaan dilakukan pengiriman paket ICMP sebanyak 20
sequence/urutan. Hasil pengukuran dapat dilihat pada Tabel 4.1, Tabel 4.2, dan
Tabel 4.3. Satuan latency adalah milliseconds (ms).
Tabel 4.1. Nilai latency pada penilitian untuk skenario 1
Urutan
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Percobaan 1
57.2
1.26
0.094
0.094
0.174
0.138
0.085
0.075
0.149
0.12
0.159
0.118
0.095
0.089
0.156
0.157
0.101
0.115
Skenario 1
Percobaan 2 Percobaan 3
105
62.5
0.67
2.31
0.139
0.103
0.153
0.101
0.131
0.162
0.164
0.26
0.173
0.115
0.176
0.17
0.165
0.181
0.145
0.08
0.152
0.137
0.135
0.176
0.158
0.088
0.175
0.121
0.335
0.23
0.171
0.14
0.162
0.183
0.152
0.178
Universitas Sumatera Utara
26
19
20
0.137
0.156
0.155
0.174
0.107
0.167
Tabel 4.2. Nilai latency pada penilitian untuk skenario 2
Urutan
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Skenario 2
Percobaan 1 Percobaan 2 Percobaan 3
91
118
94.1
2.06
0.698
2.36
0.124
0.192
0.142
0.128
0.22
0.178
0.129
0.137
0.086
0.147
0.17
0.219
0.204
0.16
0.178
0.211
0.214
0.107
0.138
0.127
0.135
0.164
0.151
0.068
0.135
0.098
0.11
0.142
0.159
0.262
0.06
0.109
0.088
0.135
0.123
0.142
0.146
0.138
0.118
0.146
0.139
0.113
0.075
0.144
0.098
0.068
0.136
0.1
0.125
0.151
0.1
0.069
0.146
0.066
Tabel 4.3. Nilai latency pada penilitian untuk skenario 3
Urutan
1
2
3
4
5
6
Skenario 3
Percobaan 1 Percobaan 2 Percobaan 3
105
100
113
1.98
1.98
2.44
0.136
0.124
0.149
0.091
0.129
0.088
0.103
0.096
0.14
0.064
0.077
0.089
Universitas Sumatera Utara
27
7
8
9
10
11
12
13
14
15
16
17
18
19
20
4.1.2
0.098
0.092
0.065
0.073
0.074
0.074
0.071
0.06
0.084
0.076
0.082
0.081
0.097
0.129
0.137
0.067
0.068
0.079
0.073
0.127
0.146
0.141
0.091
0.113
0.08
0.064
0.119
0.102
0.231
0.07
0.074
0.107
0.088
0.162
0.065
0.089
0.085
0.088
0.126
0.089
0.085
0.081
Hasil Perhitungan Throughput
Pengukuran throughput dilakukan dengan aplikasi iperf dengan mengirimkan
paket TCP antara host 1 dan host 6. Pengiriman iperf dilakukan sebanyak 10
kali. Hasil pengukuran terlihat pada Tabel 4.4, dimana satuan dari throughput
dalam Gigabit tiap detik (Gbit/s).
Tabel 4.4. Nilai throughput pada tiap skenario penelitian
Percobaan Skenario 1 Skenario 2 Skenario 3
1
17.7
18.4
19.5
2
18.9
18.7
20.9
3
19.8
17.8
18.4
4
21.5
18.3
20
5
19.6
18.8
18.2
6
18.4
18.9
19.7
7
18.7
19.8
20.1
8
19.4
19.8
19.8
9
20.7
22.1
19.4
10
19.8
20.5
18.5
Universitas Sumatera Utara
28
4.2
Analisis Hasil Penelitian
4.2.1
Analisis Hasil Virtualisasi terhadap Container
Dilihat dari output CLI pada ONOS, identitas setiap switch yang berada pada
emulasi jaringan ketika berkomunikasi dengan controller dalam control network
menggunakan alamat IP dari lxcbr0 namun dengan port komunikasi yang
berbeda-beda. Nomor port ini diberi secara acak. Untuk analisis, penulis
mengunakan instansi 2 pada skenario penelitian 3. Pada gambar tersebut tampak
perangkat pada jaringan yang dilihat oleh instansi 2 dari controller.
Gambar 4.1. Tampilan perangkat yang dilihat oleh instansi 2
Pada Gambar 4.1 juga dapat dilihat bahwa instansi 2 menjadi controller untuk
switch 2 dan 5 (sesuai dengan skenario 3) dimana switch 2 terhubung dengan
controller melalui port 36234 dan switch 5 melalui port 36243. Sebuah
controller dalam jaringan Openflow mengirimkan paket broadcast secara
periodik untuk mendeteksi topologi jaringan. Dalam hal ini, controller
menggunakan Link Layer Discovery Protocol atau LLDP (Hu, 2014).
Berdasarkan pengamatan penulis, controller ONOS yang digunakan dalam
penelitian menggunakan alamat de:ad:be:ef:ba:11 untuk pengiriman paket
LLDP. Pada Gambar 4.2 dapat dilihat controller hanya mengirimkan pakett
LLDP ke switch yang dikontrolnya.
Universitas Sumatera Utara
29
Gambar 4.2. Paket Link Layer Discovery Protocol (LLDP)
Untuk melihat alur paket komunikasi controller dan switch, dijalankan paket
ICMP antara host 1 dan host 6 (yang melewati switch yang dikontrol controller
yang berbeda). Pada gambar 4.3, dapat dilihat bahwa instansi 2 hanya menerima
packet-in dan packet-out dari switch yang menjadi bawahannya yaitu switch 2
dan 5.
Universitas Sumatera Utara
30
Gambar 4.3. Komunikasi packet-in dan packet-out pada instansi 2
Paket packet-in dan packet-out yang diterima oleh instansi 2 berupa pertanyaan
dari switch mengenai proses yang perlu dilakukan seputar paket ICMP yang
diterima. Pada Gambar 4.3 tersebut juga tampak jenis paket ICMP tersebut,
dimana Type 8 adalah echo request dan 0 adalah echo reply. Dari pengiriman
paket ICMP tersebut, dapat dilihat bahwa switch 2 dan 5 berkomunikasi dengan
instansi ke 2 dari controller, sehingga virtualisasi dan pemisahan kontrol dapat
dikatakan telah berhasil.
4.2.2
Analisis Terhadap Jaringan Data
Berdasarkan hasil pengukuran pada Tabel 4.1, Tabel 4.2 dan Tabel 4.3, dapat
dilihat bahwa nilai latency tertinggi terletak pada 2 sequence pertama. Grafik
yang menunjukkan hasil pengukuran latency tersebut dapat dilihat pada Gambar
4.4, Gambar 4.5 dan Gambar 4.6.
Universitas Sumatera Utara
31
Gambar 4.4. Grafik perhitungan latency pada percobaan 1
Universitas Sumatera Utara
32
Gambar 4.5. Grafik perhitungan latency pada percobaan 2
Universitas Sumatera Utara
33
Gambar 4.6. Grafik perhitungan latency pada percobaan 3
Berdasarkan grafik pada Gambar 4.4, Gambar 4.5, dan Gambar 4.6 dapat dilihat
bahwa latency komunikasi pada jaringan data tidak berbeda jauh. Skenario satu
digambarkan dengan warna biru, skenario dua warna merah, dan skenario tiga
dengan warna hijau. Adapun latency tertinggi terjadi pada awal komunikasi.
Universitas Sumatera Utara
34
Selain karena delay untuk packet-in dan packet-out yang dijelaskan pada sub
bab 4.2.1, paket baru yang terlihat pada Wireshark adalah Address Resoulution
Protocol (ARP), dimana host 1 mengirimkan paket broadcast ARP untuk
mencari host 6. Dapat dilihat pada Gambar 4.7, yang merupakan daftar paket
ARP yang muncul dan ditangkap pada lxcbr0 sejak paket ICMP dijalankan.
Gambar 4.7. Paket ARP pada awal komunikasi jaringan data
Untuk nilai latency terhadap sequence ICMP setelah proses ARP, pada tiap
skenario memiliki nilai dibawah 1 ms. Sepanjang pengetahuan penulis, belum
ada standarisasi kelayakan nilai latency pada jaringan LAN. Nilai latency
terbaik yang diharapkan tentunya adalah 0 ms. Namun hal tersebut tidak
memungkinkan dikarenakan ada faktor sumber datangnya latency, mulai dari
delay propagasi sinyal, delay antarmuka jaringan untuk serialisasi, delay
pemrosesan jaringan, delay di dalam perangkat dan delay antrian (Kay, 2016).
Melihat faktor tersebut dan membandingkan latency pada skenario penelitian
mendekati 0 ms, maka penulis melihat trafik cukup baik dan normal.
Grafik pengukuran throughput
dapat dilihat pada Gambar 4.8.
Percobaan pengukuran throughput dilakukan sebanyak 10 kali terhadap ketiga
skenario penelitian.
Universitas Sumatera Utara
35
Throughput (Gb/s)
25
20
15
10
5
0
1
2
3
4
5
6
7
8
9
10
Nomor Percobaan
Skenario 1
Skenario 2
Skenario 3
Gambar 4.8. Grafik pengukuran throughput
Pada gambar tersebut dapat dilihat throughput yang diperoleh dari ketiga
skenario bervariasi dengan percobaan ketiga skenario setelah dilakukan
percobaan sebanyak sepuluh kali dari host 1 ke host 6. Ketika penulis
mengirimkan paket TCP untuk mengukur throughput melalui iperf dari host 1
ke host 6 , penulis menemukan adanya delay berupa TCP retransmisson dan
TCP out of order. Seperti pada Gambar 4.9 dalam skenario 1. TCP
retransmission dan TCP out of order terlihat pada komunikasi antara switch
dengan controller yang menjadi pusatnya.
Universitas Sumatera Utara
36
Gambar 4.9. Delay terhadap TCP pada skenario 1
Pada skenario tiga, seluruh instansi controller juga menerima TCP
retransmission dan TCP out of order lebih sedikit, dikarenakan fungsi controller
telah dibagi sehingga tidak seperti skenario 1 dimana controller melakukan
kontrol terhadap seluruh switch. Hal ini dapat dilihat pada Gambar 4.10.
Gambar 4.10. Delay terhadap TCP pada instansi 3 dalam skenario 3.
Universitas Sumatera Utara
37
Peringatan retransmission pada Wireshark muncul ketika Wireshark
mendeteksi dua paket data dengan urutan/sequence yang sama. Pengirim akan
mengirimkan kembali (retransmit) data tersebut ketika dia tidak menerima
acknowledgement dari paket yang dikirimkan dalam jangka waktu yang
ditentukan. Sementara peringatan out of order mengindikasikan bahwa
Wireshark mendeteksi paket yang bergerak melalui jalur yang tidak tepat.
Peringatan ini pada umumnya tidak menjadi masalah, kecuali batas waktu
penerima untuk menerima paket out of order tersebut telah lewat (Chappel,
2013). Berdasarkan hasil pengamatan penulis, tidak ditemukan indikasi lain dari
komunikasi data melalui ONOS dan switch, yang berpengaruh terhadap
throughput. Throughput yang diterima pada ketiga skenario berada pada rentang
17.7 s/d 22.1 dimana rata-rata throughput dalam sepuluh kali percobaan untuk
skenario 1, skenario 2 dan skenario 3 masing-masing adalah 194.5, 193.1 dan
194.5. Berdasarkan data tersebut, penulis melihat throughput tetap stabil dalam
keadaan dilakukan virtualisasi.
Universitas Sumatera Utara
38
BAB V
KESIMPULAN DAN SARAN
5.1
Kesimpulan
Berdasarkan hasil pengukuran dan analisis yang dilakukan pada penelitian ini, dapat
disimpulkan bahwa :
1. Konsep virtualisasi dapat diterapkan dengan baik pada controller dalam
jaringan LAN berbasis Openflow yang diemulasikan, dimana komunikasi switch
dalam control network dapat dibagi sesuai dengan jumlah instansi yang
dibentuk. Trafik data dari switch pada control network tetap berkomunikasi pada
instansi controller yang menjadi pusatnya.
2. Virtualisasi pada jaringan umumnya digunakan untuk optimasi/meningkatkan
fungsi manajemen maupun keamanan. Dengan nilai latency dan throughput
yang tidak berpengaruh terhadap penambahan jumlah instansi dalam jaringan
LAN berbasis Openflow, maka berdasarkan hasil emulasi, konsep virtualisasi
tepat untuk diterapkan pada implementasi jaringan tersebut.
5.1
Saran
Adapun saran dari penelitian ini yang dapat digunakan untuk penelitian yang akan
dating adalah:
1. Dengan virtualisasi controller, switch hanya akan berkordinasi dengan instansi
controller yang menjadi pusatnya. Dengan dimungkinkannya pemisahan
instansi ini, dapat ditingkatkan kemampuan manajeman jaringan seperti
penerapan Quality of Service (QoS) maupun peningkatan keamanan untuk
melindungi control network yang terpisah secara logika. Penulis berpendapat
perlu diadakan kajian untuk hal tersebut.
2. Penerapan virtualisasi pada jaringan salah satunya adalah untuk mendukung
sistem distribusi, dimana sumber daya sebuah sistem dapat diperbantukan
Universitas Sumatera Utara
39
untuk sistem lain. Dengan virtualisasi controller, dapat mendukung konsep
tersebut, dimana sumber daya controller dapat diperbantukan ke jaringan lain
khususnya yang berbeda lokasi secara fisik (remote area). Penulis berpendapat
perlunya kajian lebih lanjut terhadap hal tersebut.
Universitas Sumatera Utara