Implementasi High Availability pada Gateway Wireless Sensor Network dengan Protokol Komunikasi Message Queuing Telemetry Transport

  

Vol. 2, No. 10, Oktober 2018, hlm. 3280-3289 http://j-ptiik.ub.ac.id

Implementasi High Availability pada Gateway Wireless Sensor Network

dengan Protokol Komunikasi Message Queuing Telemetry Transport

_{1 2 3} Bagus Prasetyo , Sabriansyah Rizqika Akbar , Widhi Yahya

  Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya _{1 2 3} Email: bagustyo92@gmail.ac.id, sabrian@ub.ac.id, widhi.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 broker server 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 jaringan internet (Govindan & Azad, 2015).

1. PENDAHULUAN

  Pada implementasinya, gateway memiliki peran penting pada MQTT-SN oleh sebab itu gateway MQTT-SN merupakan adaptasi teknologi

  failure adalah salah satu hal yang sangat

  MQTT yang dikembangkan untuk wireless dihindari dalam mengimplementasi MQTT-SN.

  sensor network . Dalam sistem MQTT-SN

  Untuk meminimalisir kegagalan gateway dalam seluruh end-point atau node pada WSN akan meneruskan informasi sensing dari node, maka terhubung melalui Gateway. Gateway sendiri dibutuhkan sebuah redundan gateway sebagai merupakan perantara sensor node dalam sebuah solusi ketika terjadi gateway failure. mengirim data pada jaringan lokal WSN agar terhubung ke server broker MQTT melalui

  Pemodelan terpusat pada broker dan gateway

  Fakultas Ilmu Komputer Universitas Brawijaya

3280

  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

  Gambar 1. Diagram alir metode penelitian penerapanya load balancing menggunakan algoritma yang mengatur pendistribusian trafik 3. pengguna yang mencoba melakukan request ke PERANCANGAN DAN

  IMPLEMENTASI server ataupun gateway (Devi & Utariaraj, 2015).

  3.1. Perancangan Topologi Sistem

  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

  Gambar 2. Gambaran Sistem ditingkatkan dengan redudansi Keepalived pada

  gateway agar gateway dapat selalu menangani

  pesan yang masuk dari node sensor. 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. pemrosesan data yang dikirim oleh klien (node sensor) 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 (sensor node).

  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

  Gambar 3. Topologi Sistem ke broker server. Pada gambar 2 merupakan alur yang perlu 8.

  Haproxy akan bertugas melakukan bind diperhatikan pada saat perancangan sistem. port MQTT yang berada pada port 1883 di

  Gambar 2 menjelaskan bahwa gateway dan klien komputer server dan juga membagi beban (sensor node) terhubung menggunakan jaringan trafik dari klien yang mencoba melakukan lokal yang memanfaatkan media nirkabel WiFi.

  publish ke broker server dengan Gateway juga bertugas mengirim pesan yang

  memanfaatkan load balancer. diterima dari klien ke broker menggunakan jaringan internet untuk nantinya diteruskan ke

  9. Ketika topik yang dikirim oleh klien kepada pengguna atau subscriber. Pada gambar 3

  gateway sesuai dengan topik yang telah

  tersebut juga dijelaskan bahwa mekanisme disinkronisasikan maka salah satu broker

  publish -subscribe pada protokol MQTT yang server akan menerima pesan pada topik

  dikombinasikan dengan load balancer haproxy tersebut dan melakukan sinkronisasi kepada dan juga redudansi keepalived. Berikut adalah

  broker server lainya sehingga semua broker

  penejalsan lebih rincinya: mendapatkan pesan yang dikirim oleh klien.

  3.2. Perancangan Broker

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 Gambar 4. Perancangan Broker Server melakukan sinkronisasi topik memanfaatkan plugin bridge mosquito agar

  Pada gambar 4 dijelaskan bahwa broker tiap broker mendapatkan pesan yang server akan berjalan pada 4 komputer server dan dikirim oleh gateway pada topik yang telah alamat ip yang berbeda menggunakan MQTT ditentukan. mosquitto. Mosquitto memiliki plugin

  broker

  4. memanfaatkan sebuah bernama bridge yang mampu menghubungkan Gateway mikrokomputer raspberry pi sebagai pusat dua atau lebih broker server yang berbeda 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.

  host atau alamat pengiriman dengan menggunakan protokol MQTT pada port 1883, karena gateway telah melakukan binding port maka gateway mampu menjalankan fungsi

  3.4. Implementasi Topologi Sistem Topologi yang telah dibuat akan dibagi menjadi 2 bagian utama, pertama adalah bagaimana komunikasi antara gateway dengan broker server lalu yang kedua komunikasi antara gateway dengan klien (sensor node). Karena pada penelitian ini gateway menjadi poin utama yang perlu dibahas dan dipisahkan agar memudahkan implementasi dan pembahasan.

  tersebutlah yang akan diakses oleh klien (sensor node ) sebagai host MQTT lokal.

  gateway tersebut terhubung. Ip virtual

  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 mengalami down. Keepalived

  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 tersebut akan menjalankan haproxy

  Keepalived pada dasarnya akan menghubungkan antar kedua gateway. Kedua

  Redudansi Keepalived

  broker untuk lokal untuk diteruskan ke broker server .

  gateway . Klien (sensor node) akan mengakses gateway menggunakan alamat ip yang dijadikan

  Dengan adanya bridge maka publisher cukup melakukan publish ke salah satu computer server maka pesan akan diterima di seluruh broker

  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

  sensor ke broker server menggunakan algoritma

  Haproxy berfungsi untuk melakukan pemerataan trafik yang akan masuk dari node

  Load Balancer Haproxy

  ), selain itu keepalived tersebut berfungsi sebagai redudansi sehingga klien seolah-olah mengakses satu ip yaitu ip virtual seperti yang ditunjukan pada gambar 5.

  node

  menghubungkan gateway dengan klien (sensor

  server , sedangkan keepalived akan

  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

  mengakses broker server manapun dengan topik yang sama walaupun berada di alamat yang berbeda. Dengan bridge pula broker server 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.

  server yang terubung. Subscriber dapat

3.3. Perancangan Gateway

  Gambar 6. Implementasi Topologi Broker Server

  5

  16 pid_file /var/run/mosquitto.pid persistence true persistence_location /var/lib/mosquitto/ log_dest file /var/log/mosquitto/mosquitto.log include_dir /etc/mosquitto/conf.d #konfigurasi bridge connection coba_server_irfan address 52.74.69.17:1883 cleansession false topic coba/# both 2 remote_clientid 1 remote_username rfan remote_password rfandoang

  15

  14

  13

  12

  11

  10

  9

  8

  7

  6

  4

  Gambar 7. Implementasi Topologi Gateway

  3

  2

  1

  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 broker server master dan

  broker yang berbeda tersebut hanya dibedakan

  Tabel 1. Konfigurasi Broker Server 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

  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.

  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”.

  Sedangkan slave hanya akan menerima masukan konfigurasi dari bridge master tanpa adanya tambahan konfigurasi bridge di broker server tersebut.

  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 broker server yang menjalankan konfigurasi plugin bridge.

  Broker Server

  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

  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.

  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 broker server 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 broker server yang sebelumnya telah dibuat dengan menggunakan ip address tiap broker.

3.6. Implementasi Gateway

  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 Informasi terkait status sesuai dengan gambar 10 diatas berupa informasi keadaan broker

  server

  7 Terkirim Terkirim Terkirim

  1 Terkirim Terkirim Terkirim

  2 Terkirim Terkirim Terkirim

  3 Terkirim Terkirim Terkirim

  4 Terkirim Terkirim Terkirim

  5 Terkirim Terkirim Terkirim

  6 Terkirim Terkirim Terkirim

  8 Terkirim Terkirim Terkirim

  Gateway Slave 1

  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

  Fungsi dari redudansi keepalived ini bertujuan untuk meningkatkan ketersediaan dari

  gateway yang akan diakses oleh klien, redudansi

  ini juga berfungsi menambahkan virtual ip yang akan di akses oleh subscriber. Pada sub-bab ini akan berfokus pada pengujian yang dilakukan untuk melihat sekaligus menguji konfigurasi keepalived yang telah dibuat dan dirancang

  Gateway Slave 2

  Gateway Master

  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

  gateway master dan juga slave. Karena interface

  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

  yang digunakan pada sistem ini juga memanfaatkan konektifitas nirkabel atau

  broker Percobaan ke -

  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 (sensor node) 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.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 (sensor node) ke broker.

  Tabel 2. Hasil pengiriman tiap gateway ke

4. PENGUJIAN

  sebelumnya. Hal ini bertujuan untuk menganalisis berapa lama waktu disconnect yang dibutuhkan ketika terjadi swap.

  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.

  2 10,626 s 9,973 s 3 10,689 s 10,544 s Percobaan ke -

  Lama waktu gateway disconnect (s) 1 10,901 s 10,518 s

  Percobaan ke - Lama waktu timeout (s)

  Tabel 3. Hasil lama waktu yang diperlukan ketika timeout

  dikalkulasikan selisih waktu sekitar 10 detik, itu artinya gateway melakukan proses swap selama kurang lebih 10 detik.

  gateway pada detik ke-181. Dengan ini dapat

  berhasil mendapatkan balasan ACK dari

  gateway terjadi pada detik ke-171 lalu baru

  maka klien gagal membangun koneksi. Ketika gagal membangun koneksi tersebutlah proses perhitungan dimulai, pada kasus gambar 14. diatas proses gagal membangun koneksi ke

  gateway yang terhubung terakhir di matikan

  aktif dan telah terhubung maka gateway akan membalasnya dengan mengirim ACK kembali ke klien. Namun ketika salah satu

  gateway

  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

  Gambar 14. Pencatatan waktu dengan capture protokol TCP ketika gateway melakukan proses swap

  Gambar 12. Pengujian dengan menggunakan ping Gambar 13. Pencatatan waktu timeout menggunakan wireshark

  Untuk mendapatkan hasil yang relevan Pada

  ICMP atau sering disebut dengan ping pada ip virtual gateway menggunakan WireShark. Hasil dari pengujian ini dapat dilihat seperti pada gambar berikut.

  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

  pada detik ke-181. Dengan ini dapat dikalkulasikan selisih waktu sekitar 10 detik, itu artinya gateway melakukan proses swap selama kurang lebih 10 detik.

  gateway

  berhasil mendapatkan balasan ACK dari

  gateway terjadi pada detik ke-171 lalu baru

  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 yang terhubung terakhir di matikan

  akan membalasnya dengan mengirim ACK kembali ke klien. Namun ketika salah satu

  gateway aktif dan telah terhubung maka gateway

  klien selalu mengirimkan push ACK atau acknowledgement kepada gateway, ketika

  gateway . Terlihat setiap beberapa detik sekali

  percobaan untuk terhubung ke virtual ip

gambar 6.8 dapat dilihat mekanisme TCP yang terjadi ketika klien atau subscriber melakukan

  Lama waktu timeout (s) Lama waktu gateway disconnect (s)

  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.

  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.

  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.

4.1.3. Pengujian Pengiriman Data

  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

  kehandalan atau ketersediaan gateway ketika terjadi swap.

  . 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

  broker . Pengujian ini sekaligus menguji

  Pengujian ini bertujuan untuk melihat prosentase keberhasilan gateway ketika melakukan tugasnya yaitu meneruskan pesan ke

  4.2. Pengujian Broker Server

  4.2.1. Pengujian Sinkronisasi Broker Server

  Pengujian ini bertujuan untuk melihat prosentase keberhasilan tiap broker server melakukan sinkronisasi topik pada tiap data yang dikirim oleh gateway. Sekaligus menguji topologi yang telah dibuat pada sisi broker server .

  gateway

  Tabel 5. Hasil Percobaan Sinkornisasi menghubungkan antara 2 atau lebih broker

  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. Berdasarkan tabel 5 pengujian yang telah dilakukan pada 10 kali percobaan tersebut dapat

  6. DAFTAR PUSTAKA

  disimpulkan bahwa meskipun dengan PRADA, M., 2016. Communication with menggunakan QoS yang berbeda-beda, broker

  Resource-Constrained Device Through

  tetap mampu melakukan sinkronisasi di tiap MQTT for Control Education .

  broker server tanpa adanya ketidak sesuaian atau

  kegagalan dari konfigurasi bridge yang telah PRITISH SACHDEVA, SHRUTIK KATCHII. dibuat. Sehingga mampu dikatakan bahwa (2014). A Review Paper on Raspberry Pi. presentasi keberhasilan dari percobaan

  India: International Journal of Current sinkronisasi broker tersebut sebesar 100%.

  .

  Engginering and Technology DEVI, D. C., & UTARIARAJ, V. R. (2015).

5. KESIMPULAN

  Load Balancing in Cloud Computing Environment Using Improved Weighted

  Berdasarkan dari apa yang telah dirancang,

  Round Robin Algorithm for Nonpreemptive

  diimplementasikan dapat disimpulkan sebagai berikut:

  Dependent Tasks . The Scientific World Journal, 1-14.

  GOVINDAN, K., & AZAD, A. P. (2015). End- jaringan WSN dapat ditingkatkan

1. Gateway dan juga broker MQTT pada

  to-end service assurance in IoT MQTT-SN .

  ketersediaanya dengan IEEE, 290-296. 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 broker server. Broker server 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 broker server. Broker server telah mampu melakukan sinkronisasi pada seluruh broker server yang terhubung dengan melakukan konfigurasi bridge mosquitto yang berguna untuk