Fakultas Ilmu Komputer
Universitas Brawijaya
3280
Implementasi
High
Availability
pada
Gateway Wireless Sensor Network
dengan Protokol Komunikasi
Message Queuing Telemetry Transport
Bagus Prasetyo1, Sabriansyah Rizqika Akbar2, Widhi Yahya3Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1bagustyo92@gmail.ac.id, 2sabrian@ub.ac.id, 3widhi.yahya@ub.ac.id
Abstrak
MQTT-SN merupakan pengembangan dari protokol yang banyak digunakan pada Internet of Things sekarang ini yaitu MQTT. Pada penerapanya MQTT-SN sama dengan MQTT, tetapi MQTT-SN difokuskan pada wireless sensor network. Pada MQTT-SN yang paling terlihat adalah hadirnya gateway sebagai kolektif data dari sensor node untuk diteruskan ke broker server. Gateway merupakan bagian terpenting pada MQTT-SN, karena gateway merupakan penghubung antara sensor node dengan broker server. Oleh sebab itu tingkat ketersediaan gateway haruslah tinggi untuk tetap dapat meneruskan data ke broker ketika terjadi gangguan. Penelitian ini memfokuskan untuk meningkatkan ketersediaan gateway dan broker MQTT dengan mengimplementasikan 3 buah Raspberry Pi sebagai gateway yang dipasangkan Load Balancer Haproxy, dan juga redudansi Keepalived. Dalam penelitian ini juga menggunakan multi broker yang saling berbagi pesan atau topik untuk meningkatkan ketersediaan broker. Hasil dari penelitian ini adalah broker dan gateway berhasil ditingkatkan ketersediaanya dengan klasterisasi, pembagian beban trafik, penggunaan multi broker dan juga redudansi pada sistem hingga 100% ketika salah satu gateway atau brokerserver mengalami gangguan.
Kata kunci: High Availability, Load Balancer, Redudansi, Gateway, Raspberry Pi, MQTT, Multi Broker
Abstract
MQTT-SN is a development of the widely used protocol on the Internet of Things Technology, MQTT. In common MQTT-SN protocol is same as well as MQTT, but MQTT-SN is focused on the sector of wireless sensor network. In MQTT-SN the most prominent is the presence of gateway. Gateway is used to collective data from multiple sensor nodes and forwarding data to broker server. Gateway is the most important part of MQTT-SN technology, because gateway is communicator between sensor node and broker server. Therefor availability of gateway is crucial when facing failure-system or down. This research will be focus on increasing the availability of MQTT server brokers and gateway by implementing Haproxy Load Balancer and Keepalived that installed on 3 Raspberry Pi’s as gateways. This system also used multiple broker servers which sharing message or topic for improve availability on broker server side. Research results is brokers and gateways successfully improved availability by using clusterization, balancer traffic, multiple broker implementation and redudancy up to 100% when one of the gateway or broker has a failure.
Keywords: High Availability, Load Balancer, Redudancy, Gateway, Raspberry Pi, MQTT, Multiple Brokers
1. PENDAHULUAN
MQTT-SN merupakan adaptasi teknologi MQTT yang dikembangkan untuk wireless sensor network. Dalam sistem MQTT-SN seluruh end-point atau node pada WSN akan terhubung melalui Gateway. Gateway sendiri merupakan perantara sensor node dalam mengirim data pada jaringan lokal WSN agar terhubung ke server broker MQTT melalui
jaringan internet (Govindan & Azad, 2015). Pada implementasinya, gateway memiliki peran penting pada MQTT-SN oleh sebab itu gateway failure adalah salah satu hal yang sangat dihindari dalam mengimplementasi MQTT-SN. Untuk meminimalisir kegagalan gateway dalam meneruskan informasi sensing dari node, maka dibutuhkan sebuah redundan gateway sebagai sebuah solusi ketika terjadi gateway failure.
MQTT pada WSN dapat menimbulkan berbagai masalah ketika memiliki jumlah klien yang sangat besar. Server ataupun gateway yang tidak dapat melakukan auto scalling ketika banyaknya request atau publish yang masuk dapat membuat server down ataupun gateway failure. Oleh sebab itu dibutuhkan suatu pemodelan cluster broker dan gateway MQTT yang terdistribusi sebagai solusi mengatasi masalah tersebut menggunakan Load Balancing dan juga redudansi. Load Balancing merupakan suatu mekanisme pendistribusian beban trafik pada dua atau lebih jalur koneksi agar tetap berjalan secara optimal dengan memaksimalkan throughput dan memperkecil waktu respon untuk menghindari overload. Dalam penerapanya load balancing menggunakan algoritma yang mengatur pendistribusian trafik pengguna yang mencoba melakukan request ke server ataupun gateway (Devi & Utariaraj, 2015).
Oleh sebab itu, broker dan gateway MQTT dirasa perlu untuk ditingkatkan ketersediaanya agar selalu mampu menjembatani klien. Hal tersebut dapat dicapai dengan cara melakukan klasterisasi, pembagian beban trafik, penggunaan multi broker dan juga redudansi pada sistem. Pembagian beban trafik dapat dicapai dengan penggunaan Load Balancer Haproxy pada gateway agar dapat membagi beban trafik yang diterima pada broker. Ketersediaan gateway juga haruslah ditingkatkan dengan redudansi Keepalived pada gateway agar gateway dapat selalu menangani pesan yang masuk dari nodesensor. Penggunaan multi broker dan sinkronisasi pesan juga mampu meningkatkan ketersediaan dari sisi broker server. Harapanya sistem yang dibangun nantinya dapat memiliki ketersediaan yang tinggi ketika broker ataupun gateway mengalami gangguan.
2. METODOLOGI PENELITIAN
Langkah-langkah yang akan dilakukan pada penelitian ini disesuaikan seperti pada Gambar 1 yakni studi kepustakaan, rekayasa kebutuhan, perancangan, implementasi, pengujian yang disesuaikan dengan analisis kebutuhan dan kesimpulan yang merupakan rangkuman dari penerlitian ini agar dapat dikembangkan lebih lanjut.
Gambar 1. Diagram alir metode penelitian
3. PERANCANGAN DAN
IMPLEMENTASI
3.1. Perancangan Topologi Sistem
Gambar 3. Topologi Sistem
Pada gambar 2 merupakan alur yang perlu diperhatikan pada saat perancangan sistem. Gambar 2 menjelaskan bahwa gateway dan klien (sensornode) terhubung menggunakan jaringan lokal yang memanfaatkan media nirkabel WiFi. Gateway juga bertugas mengirim pesan yang diterima dari klien ke broker menggunakan jaringan internet untuk nantinya diteruskan ke pengguna atau subscriber. Pada gambar 3 tersebut juga dijelaskan bahwa mekanisme publish-subscribe pada protokol MQTT yang dikombinasikan dengan load balancer haproxy dan juga redudansi keepalived. Berikut adalah penejalsan lebih rincinya:
1. Klien (node sensor) dan juga gateway haruslah berada pada satu jaringan lokal yang memanfaatkan modul komunikasi nirkabel WiFi.
2. Beberpa broker server MQTT yang berjalan pada komputer server akan berjalan secara bersamaan pada alamat ip publik yang berbeda.
3. Broker-broker server tersebut akan melakukan sinkronisasi topik memanfaatkan plugin bridge mosquito agar tiap broker mendapatkan pesan yang dikirim oleh gateway pada topik yang telah ditentukan.
4. Gateway memanfaatkan sebuah mikrokomputer raspberry pi sebagai pusat
pemrosesan data yang dikirim oleh klien (nodesensor) dan nantinya akan diteruskan kepada broker server menggunakan haproxy.
5. Jumlah gateway yang tersedia akan berjumlah lebih dari satu sebagai bentuk redundansi yang memanfaatkan keepalived untuk meningkatkan high availability dari gateway dalam hal menangani data yang dikirim oleh klien (sensornode).
6. Klien (node sensor) yang memanfaatkan modul WiFi sebagai media pengiriman data, akan melakukan sensing data yang selanjutnya akan diteruskan atau dikirim kepada gateway melalui mekanisme publish dengan topik yang telah ditentukan dan menggunakan alamat ip gateway sebagai alamat host pengiriman.
7. Gateway sebagai destinasi pengiriman oleh klien (node sensor) memanfaatkan load balancer haproxy sebagai portal pengiriman ke brokerserver.
8. Haproxy akan bertugas melakukan bind port MQTT yang berada pada port 1883 di komputer server dan juga membagi beban trafik dari klien yang mencoba melakukan publish ke broker server dengan memanfaatkan load balancer.
9. Ketika topik yang dikirim oleh klien kepada gateway sesuai dengan topik yang telah disinkronisasikan maka salah satu broker server akan menerima pesan pada topik tersebut dan melakukan sinkronisasi kepada brokerserver lainya sehingga semua broker mendapatkan pesan yang dikirim oleh klien.
3.2. Perancangan Broker
Gambar 4. Perancangan BrokerServer
alamat dengan cara saling berbagi informasi topik sehingga tiap broker mendapatkan pesan yang dikirim atau di-publish oleh seluruh klien. Dengan bridge pula tiap subscriber mampu mendapatkan data yang dipublish pada alamat broker yang berbeda dan tersambung melalui bridge.
Dengan adanya bridge maka publisher cukup melakukan publish ke salah satu computer server maka pesan akan diterima di seluruh broker server yang terubung. Subscriber dapat mengakses brokerserver manapun dengan topik yang sama walaupun berada di alamat yang berbeda. Dengan bridge pula brokerserver tidak lagi terpusat sehingga mengurangi kemungkinan down atau single point of failure. Walaupun sudah menjadi tugas server untuk tidak mati namun terkadang hal-hal yang tidak terduga dapat terjadi dan dapat membuat server mengalami down, entah mungkin karena trafik yang tinggi dan storage yang terbatas atau bahkan computer server mengalami error.
3.3. Perancangan Gateway
Gambar 5. Perancangan Gateway
Pada gateway akan memanfaatkan 2 perangkat keras berupa mikrokomputer berbeda sebagai gateway. Mikrokomputer tersebut adalah raspberry pi 3 yang dipasangkan aplikasi haproxy dan juga keepalived dengan config tertentu agar mampu menjadi gateway. Haproxy akan menghubungkan gateway dengan broker server, sedangkan keepalived akan menghubungkan gateway dengan klien (sensor node), selain itu keepalived tersebut berfungsi sebagai redudansi sehingga klien seolah-olah mengakses satu ip yaitu ip virtual seperti yang ditunjukan pada gambar 5.
Load Balancer Haproxy
Haproxy berfungsi untuk melakukan pemerataan trafik yang akan masuk dari node sensor ke brokerserver menggunakan algoritma round robin agar beban server tidak terpusat dan mampu mengurangi single point of failure. Haproxy itu sendiri juga akan melakukan
binding seluruh port computer server yang menjalankan protokol MQTT pada port 1883, oleh sebab itu gateway mampu menjalankan atau menjadi broker lokal tanpa perlu menjalankan aplikasi mosquitto. Untuk menjadikan haproxy sebuah broker lokal untuk klien (sensor node) dibutuhkan konfigurasi pada perangkat mikrokomputer yang menjalankan aplikasi haproxy, konfigurasi lebih rincinya akan di jelaskan pada bab 5.2.3 tentang implementasi gateway. Klien (sensor node) akan mengakses gateway menggunakan alamat ip yang dijadikan host atau alamat pengiriman dengan menggunakan protokol MQTT pada port 1883, karena gateway telah melakukan binding port maka gateway mampu menjalankan fungsi broker untuk lokal untuk diteruskan ke broker server.
Redudansi Keepalived
Keepalived pada dasarnya akan menghubungkan antar kedua gateway. Kedua gateway tersebut akan menjalankan haproxy yang dihubungkan oleh keepalived. Fungsi utamanya yaitu sebagai redudansi untuk menangani single point of failure. Ketika salah satu gateway mengalami gangguan maka salah satunya akan melakukan backup dengan melakukan pengecekan secara berkala menggunakan config yang telah dibuat. Config ini akan dijalankan oleh keepalived sebagai parameter kapan keepalived akan melakukan transisi ke gateway lainya ketika salah satu gateway mengalami down. Keepalived menjalankan fungsinya dengan membuat ip virtual yang berjalan di salah satu perangkat, ip tersebut haruslah berada pada jaringan yang sama dengan dimana kedua perangkat atau gateway tersebut terhubung. Ip virtual tersebutlah yang akan diakses oleh klien (sensor node) sebagai host MQTT lokal.
3.4. Implementasi Topologi Sistem
Gambar 6. Implementasi Topologi
Broker
Server
Gambar 7. Implementasi Topologi
Gateway
Berdasarkan gambar 6 dan 7 diatas menunjukan bahwa topologi akan dibedakan menjadi dua bagian dan penerapan implementasi kedua topologi ini akan lebih rinci dijelaskan pada sub-bab implementasi broker server, gateway, dan juga implementasi perangkat lunak dan perangkat keras dari kedua komponen utama sistem ini.
3.5. Implementasi Broker Server
Terdapat 3 komputer server yang dibuat melalui VPS amazon cloud service dengan alamat ip yang berbeda. Komputer server pertama dengan nama ngehubx memiliki ip address 54.255.183.14, dan bagus pada ip address 13.229.129.151. Kedua computer tersebut akan dijadikan bridge master. Sedangkan komputer server ketiga dengan nama Irfan dan ip address 52.74.69.17 yang berperan sebagai slave. Master adalah brokerserver yang menjalankan konfigurasi plugin bridge.
Sedangkan slave hanya akan menerima masukan konfigurasi dari bridge master tanpa adanya tambahan konfigurasi bridge di broker server tersebut.
Untuk menghubungkan tiap broker server dibutuhkan plugin bridge yang dapat dihadirkan melalui file konfigurasi pada broker mosquitto. Direktori file konfigurasi berada pada
“/etc/mosquitto/mosquitto.conf”. Sebelum melakukan konfigurasi yang dibutuhkan pertama adalah menentukan siapa yang akan menjadi master dan siapa yang akan menjadi slave. Untuk menghindari perulangan pesan yang dikirim pada tiap broker dan mampu berbagi pesan yang sama tanpa adanya duplicate maka hanya akan dibutuhkan satu konfigurasi di kedua broker yang ingin dihubungkan.
Tabel 1. Konfigurasi BrokerServer MQTT sebagai Master (ngehubx)
Konfigurasi bridge di tiap broker server hanya ditujukan atau dibuat pada komputer server yang bertugas sebagai master, sedangkan slave tidak perlu mengubah konfigurasi broker server apapun. Berdasarkan tabel 1 diatas konfigurasi bridge dimulai dari baris ke-8 sampai dengan baris terakhir. Kedua konfigurasi pada dua broker yang berbeda tersebut hanya dibedakan berdasarkan client-id untuk menghubungkan master dan juga slave. Pada baris ke-8 konfigurasi hanya sebatas penamaan hubungan atau koneksi antara broker master dan juga slave. Baris selanjutnya dengan parameter addres merupakan alamat ip address ataupun host dari broker server slave yang ingin dihubungkan dengan master. Pada kasus diatas alamat ip address slave berada pada 52.74.69.17 atau dapat diakses dengan host dns www.irfanreza.tk. Selain itu untuk menghubungkan antara brokerserver master dan 1
connection coba_server_irfan
slave dibutuhkan topik yang ingin di samakan atau disinkronisasikan. Sehingga tiap adanya pesan yang dikirim melalui topik yang telah ditentukan tersebut pada broker server master, maka broker server slave akan mendapatkan pesan yang sama. Pada baris terakhir hanya berupa verifikasi untuk menghubungkan master ke slave, karena pihak slave menggunakan verifikasi username dan juga password ke tiap klien manapun yang ingin menggunakan protokol MQTT pada server tersebut.
3.6. Implementasi Gateway
Implementasi perangkat keras akan
menyesuaikan dengan sub-bab perancangan
sebelumnya. Sesuai dengan perancangan,
gateway
terdiri dari 3 mikrokomputer
raspberry pi yang terhubung dengan jaringan
yang sama melalui portable hotspot telepon
pintar. Implementasi
gateway
ini dapat
dilihat pada gambar 7 dibawah.
Gambar 8. Implementasi Gateway
Setelah seluruh perangkat lunak telah terpasang dengan baik di masing masing gateway maka selanjutnya adalah melakukan konfigurasi haproxy dan juga keepalived. Kedua gateway tersebut menggunakan konfigurasi yang sama untuk haproxy. Hal ini dilakukan karena menurut fungsinya yaitu agar tiap gateway mampu sama-sama terhubung ke tiap broker server dengan melakukan bind port. Berikut adalah konfigursi haproxy pada ketiga gateway tersebut.
Gambar 9. Konfigurasi Haproxy Gateway
Berdasarkan fungsi konfigurasi gambar 9. diatas terdapat fungsi binding yang ditujukan untuk melakukan binding port tiap brokerserver pada port 1883. Karena pada dasarnya MQTT merupakan koneksi TCP maka mode akan menyesuaikan mode tcp seperti yang terlihat pada gambar 9. Algoritma Load Balancing yang digunakan menggunakan algoritma roundrobin. Pada baris selanjutnya adalah menentukan kemana haproxy ini akan terhubung, dalam kasus ini terhubung ke ketiga brokerserver yang sebelumnya telah dibuat dengan menggunakan ip address tiap broker.
Lalu untuk mempermudah pembacaan status dari tiap status haproxy tersebut maka ditambahkan sebuah konfigurasi pembacaan status haproxy yang dapat dibuka melalui browser dengan ketentuan penulisan alamat sebagai berikut ip_address:port/haproxy_stats. Hal ini dapat dilakukan dengan ketentuan komputer yang mengakses alamat tersebut di browser harus terhubung dengan jaringan yang sama pada kedua gateway. Konfigurasi tersebut berada pada baris ke-1 hingga 5 dengan ketentuan verifikasi autentikasi username dengan password, pada kasus diatas username
yang digunakan adalah “bagus” dan password “bitabitu”. Berikut adalah tampilan yang dibuka
setelah mengakses status haproxy pada kedua gatewa tersebut.
Gambar 10. Statistik Haproxy Gateway
server yang dilakukan binding. Ketika server mengalami gangguan ataupun down maka status ini akan memberikan informasi berupa sinyal berwarna merah pada status server yang mengindikasikan adanya masalah pada sisi server. informasi lainya yang juga tersedia seperti session rate, jumlah byte yang dikirim ke server, jumlah error, pid, uptime dan lain sebagainya.
Gambar 11. Konfigurasi Keepalived Gateway
Pada kedua konfigurasi berdasarkan gambar 11 diatas menunjukan bahwa hanya terdapat sedikit perbedaan antara master dan juga slave. Seperti yang telah disinggung sebelumnya bahwa konfigurasi master akan mendapatkan prioritas yang lebih besar dibandingkan dengan slave terkait priority. Jika master mendapatkan angka priority 101 sedangkan slave 100 maka gateway master akan mendapatkan giliran pertama yang menangani virtual ip. Selain itu perbedaan juga terletak pada lvs_id, masing masing konfigurasi dan penamaan state, hal ini hanya untuk membedakan identitas dari tiap gateway master dan juga slave. Karena interface yang digunakan pada sistem ini juga memanfaatkan konektifitas nirkabel atau wireless. Masing-masing konfigurasi mendeklarasikan interface wlan0 sebagai perantara penghubung di tiap gateway. Pembentukan virtual ip di masing masing konfigurasi yang artinya virtual ip address yang akan diakses oleh klien (sensornode) berda pada alamat ip 192.168.43.30 dengan memperhatikan keharusan berada di jaringan yang sama dengan klien dan juga gateway. Script yang digunakan untuk melakukan validasi terhadap di masing masing file konfigurasi. Artinya script akan melakukan pengecekan apakah status haproxy bekerja baik atau tidak dengan interval waktu dan timeout tertentu sebelum nantinya melakukan swap atau memindahkan virtual ip ke slave ataupun sebaliknya.
4. PENGUJIAN
4.1. Pengujian Gateway
4.1.1. Pengujian Load Balancing Gateway
Karena fungsi dari load balancer haproxy ini bertujuan untuk menghubungkan antara gateway dengan broker, maka pengujian ini dilakukan untuk melihat sekaligus menguji konfigurasi haproxy yang telah di buat dan dirancang sebelumnya. Hal ini dilakukan untuk menganalisis seberapa besar prosentase keberhasilan gateway mampu terhubung dan meneruskan pesan yang didapat dari klien (sensornode) ke broker.
Tabel 2. Hasil pengiriman tiap gateway ke broker 1 Terkirim Terkirim Terkirim 2 Terkirim Terkirim Terkirim 3 Terkirim Terkirim Terkirim 4 Terkirim Terkirim Terkirim 5 Terkirim Terkirim Terkirim 6 Terkirim Terkirim Terkirim 7 Terkirim Terkirim Terkirim 8 Terkirim Terkirim Terkirim 9 Terkirim Terkirim Terkirim 10 Terkirim Terkirim Terkirim
Berdasarkan tabel 2 pengujian yang telah
dilakukan sebanyak 10 kali percobaan
tersebut
adalah
tiap
gateway
yang
melakukan pengiriman pesan yang didapat
dari klien (
sensor
node
) telah berhasil
diteruskanya ke
broker
server
tanpa adanya
kegagalan yang juga mengindikasikan
prosentase keberhasilan dari tiap
gateway
sebesar 100%, baik itu pada
gateway
master,
slave 1, ataupun slave 2. Sehingga mampu
disimpulkan bahwa konfigurasi haproxy
load balancer sudah bekerja dengan baik dan
sesuai yang diharapkan.
4.1.2. Pengujian Redudansi Gateway
sebelumnya. Hal ini bertujuan untuk menganalisis berapa lama waktu disconnect yang dibutuhkan ketika terjadi swap.
Untuk mendapatkan hasil yang relevan Pada gambar 6.8 dapat dilihat mekanisme TCP yang terjadi ketika klien atau subscriber melakukan percobaan untuk terhubung ke virtual ip gateway. Terlihat setiap beberapa detik sekali klien selalu mengirimkan push ACK atau acknowledgement kepada gateway, ketika gateway aktif dan telah terhubung maka gateway akan membalasnya dengan mengirim ACK kembali ke klien. Namun ketika salah satu gateway yang terhubung terakhir di matikan maka klien gagal membangun koneksi. Ketika gagal membangun koneksi tersebutlah proses perhitungan dimulai, pada kasus gambar 6.8 diatas proses gagal membangun koneksi ke gateway terjadi pada detik ke-171 lalu baru berhasil mendapatkan balasan ACK dari gateway pada detik ke-181. Dengan ini dapat dikalkulasikan selisih waktu sekitar 10 detik, itu artinya gateway melakukan proses swap selama kurang lebih 10 detik.
Dari 10 kali percobaan melakukan swaping maka hasil yang didapat adalah sebagai berikut.adalah dengan mencatat waktu disconnected pada ip gateway virtual ketika terjadi proses swap dan juga dengan mencatat waktu request time out menggunakan protokol ICMP atau sering disebut dengan ping pada ip virtual gateway menggunakan WireShark. Hasil dari pengujian ini dapat dilihat seperti pada gambar berikut.
Gambar 12. Pengujian dengan menggunakan ping
Gambar 13. Pencatatan waktu timeout menggunakan wireshark
Pada gambar 12. menunjukan ketika salah satu gateway yang terakhir terhubung dimatikan maka sistem membutuhkan waktu untuk melakukan swap ke gateway lainya sehingga menimbulkan request time out. Sedangkan gambar 13 menunjukan presisi waktu ketika mulai adanya request, time out dan juga reply yang selanjutnya dapat dilakukan kalkulasi menjadi lama waktu time out dengan mengurangi bagian reply dan juga request seperti yang telah ditandai.
Gambar 14. Pencatatan waktu dengan capture protokol TCP ketika gateway melakukan proses
swap
Pada gambar 14. dapat dilihat mekanisme TCP yang terjadi ketika klien atau subscriber melakukan percobaan untuk terhubung ke virtual ip gateway. Terlihat setiap beberapa detik sekali klien selalu mengirimkan push ACK atau acknowledgement kepada gateway, ketika gateway aktif dan telah terhubung maka gateway akan membalasnya dengan mengirim ACK kembali ke klien. Namun ketika salah satu gateway yang terhubung terakhir di matikan maka klien gagal membangun koneksi. Ketika gagal membangun koneksi tersebutlah proses perhitungan dimulai, pada kasus gambar 14. diatas proses gagal membangun koneksi ke gateway terjadi pada detik ke-171 lalu baru berhasil mendapatkan balasan ACK dari gateway pada detik ke-181. Dengan ini dapat dikalkulasikan selisih waktu sekitar 10 detik, itu artinya gateway melakukan proses swap selama kurang lebih 10 detik.
Tabel 3. Hasil lama waktu yang diperlukan ketika timeout
Percobaan ke -
Lama waktu timeout (s)
Lama waktu
gateway
disconnect (s)
1 10,901 s 10,518 s
2 10,626 s 9,973 s
3 10,689 s 10,544 s
Percobaan ke -
Lama waktu timeout (s)
Lama waktu
gateway
4 9,969 s 6,924 s
5 10,100 s 10,332 s
6 10,771 s 9,982 s
7 10,234 s 10,446 s
8 10,523 s 10,223 s
9 10,614 s 10,942 s
10 10,634 s 9,911 s
Berdasarkan tabel hasil pengujian tabel 3 yang telah dilakukan sebanyak 10 kali percobaan dapat disimpulkan bahwa rata-rata lama waktu request time out yang diperlukan ketika proses swap adalah 10,506 detik sedangkan rata-rata waktu disconnected dengan filter TCP connection dari gateway adalah 9,979 detik. Selisih waktu antara capture protokol ICMP dan TCP hanya terpaut 0,527 detik, ini artinya ketika gateway melakukan proses swap hanya memakan waktu kurang lebih sekitar 10 detik. Waktu yang paling lama ketika request time out terdapat pada percobaan pertama, sedangkan status disconnected TCP terlama ada pada percobaan ke-9 yang masing-masing sebesar 10,901 dan 10,942 detik. Waktu tercepat berada pada percobaan ke-4 yang nilai masing masing sebesar 9,969 dan 6,924 detik.
4.1.3. Pengujian Pengiriman Data
Pengujian ini bertujuan untuk melihat prosentase keberhasilan gateway ketika melakukan tugasnya yaitu meneruskan pesan ke broker. Pengujian ini sekaligus menguji kehandalan atau ketersediaan gateway ketika terjadi swap.
Percobaan pengiriman data-pun dilakukan pada tiap QoS dan juga sebanyak dilakukan sebanyak 1000 kali pengiriman dengan mematikan salah satu gateway. Hal itu dilakukan ketika proses pengiriman mematikan salah satu gateway. Percobaan pengiriman ini dilakukan sebanyak 3 kali untuk melihat berapa prosentase keberhasilan data yang dikirim dan juga data yang diterima.
Tabel 4. Hasil percobaan pengiriman data menggunakan tiap QoS dengan mematikan
gateway
Berdasarkan tabel 4 sebelumnya, percobaan dilakukan sebanyak 3 kali dengan urutan mematikan gateway yaitu pertama master, kedua slave 1, dan terakhir slave 2. Hasil yang didapat adalah keseluruhan data yang dikirm dan diterima oleh subscriber berjumlah sama yaitu 1.000 pesan tiap percobaanya. Baik itu menggunakan QoS 0, QoS 1 ataupun QoS 2, hal ini terjadi lantaran sewaktu percobaan koneksi internet sedang stabil sehingga seluruh pesan dapat masuk debgan baik oleh subscriber (MQTT-Box). Maka dari itu prosentase keberhasilan pengujian ini sebesar 100% ketika koneksi internet stabil tanpa adanya loss ataupun duplicate di tiap QoS yang digunakan.
Berdasarkan kedua percobaan ini pula dapat disimpulkan bahwa selama gateway yang mati bukanlah gateway yang terakhir terhubung ke jaringan maka tidak akan adanya proses swap sehingga pesan dapat diteruskan tanpa adanya timeout ataupun disconnected dari ip gateway virtual memungkinkan virtual ip gateway ditangani oleh gateway lainya. Selain itu tingkat keberhasilan atau kecocokan antara pesan yang dikirim dan diterima juga di pengaruhi oleh koneksi internet pada saat itu. Ketika memiliki konektifitas internet yang stabil maka hamper bisa dipastikan tidak adanya data loss ataupun duplicate di tiap QoS-nya. Sebaliknya jika konektifitas tidak stabil maka mempengaruhi data yang masuk ke subscriber.
4.2. Pengujian Broker Server
4.2.1. Pengujian Sinkronisasi Broker Server
Tabel 5. Hasil Percobaan Sinkornisasi Broker
Berdasarkan tabel 5 pengujian yang telah dilakukan pada 10 kali percobaan tersebut dapat disimpulkan bahwa meskipun dengan menggunakan QoS yang berbeda-beda, broker tetap mampu melakukan sinkronisasi di tiap brokerserver tanpa adanya ketidak sesuaian atau kegagalan dari konfigurasi bridge yang telah dibuat. Sehingga mampu dikatakan bahwa presentasi keberhasilan dari percobaan sinkronisasi broker tersebut sebesar 100%.
5. KESIMPULAN
Berdasarkan dari apa yang telah dirancang, diimplementasikan dapat disimpulkan sebagai berikut:
1. Gateway dan juga broker MQTT pada jaringan WSN dapat ditingkatkan
ketersediaanya dengan
mengimplementasikan klasterisasi, pembagian beban trafik, penggunaan multi broker dan juga redudansi pada sistem. 2. Jika pada sisi gateway telah berhasil
ditingkatkan ketersediaanya, begitu pula pada sisi brokerserver. Brokerserver telah mampu melakukan sinkronisasi pada seluruh broker server yang terhubung dengan melakukan konfigurasi bridge mosquitto yang berguna untuk menghubungkan antara 2 atau lebih broker server sehingga seluruh broker yang terhubung dapat berbagi topik dan pesan ketika ada pesan yang diteruskan oleh gateway.
3. Jika pada sisi gateway telah berhasil ditingkatkan ketersediaanya, begitu pula pada sisi brokerserver. Brokerserver telah mampu melakukan sinkronisasi pada seluruh broker server yang terhubung dengan melakukan konfigurasi bridge mosquitto yang berguna untuk
menghubungkan antara 2 atau lebih broker server sehingga seluruh broker yang terhubung dapat berbagi topik dan pesan ketika ada pesan yang diteruskan oleh gateway.
Untuk penelitian selanjutnya disarankan untuk menambahkan cluster pada sisi gateway agar dapat dikelompokan sesuai dengan topologi yang ingin dibuat. Selain itu penelitian selanjutnya dapat menggunakan algoritma pada load balancer Haproxy yang lebih baik agar beban trafik benar benar terbagi secara merata bukan lagi menggunakan round robin.
6. DAFTAR PUSTAKA
PRADA, M., 2016. Communication with Resource-Constrained Device Through MQTT for Control Education.
PRITISH SACHDEVA, SHRUTIK KATCHII. (2014). A Review Paper on Raspberry Pi. India: International Journal of Current Engginering and Technology.
DEVI, D. C., & UTARIARAJ, V. R. (2015). Load Balancing in Cloud Computing Environment Using Improved Weighted Round Robin Algorithm for Nonpreemptive Dependent Tasks. The Scientific World Journal, 1-14.
