Q/A Load Balancer

Q: Apa sih Load Balancer itu?

A: Load Balancer adalah metoda atau teknik membagi beban, untuk mengatasi overloadnya layanan suatu protokol. Beban yang semula jatuh pada satu mesin atau aplikasi, dipecah-pecah bebannya ke beberapa mesin. 

Q : Apa sih HTTP Load Balancer itu?

A : HTTP Load Balancer adalah pembagi beban layanan HTTP. Jika derasnya traffic HTTP dipandang telah membebani salah satu server aplikasi, dipecahlah traffic tersebut, agar dapat dilayani beberapa mesin secara bersamaan.

Q : Emang ada Load Balancer selain protokol HTTP?

A : Ada dong.. Bahkan database juga dapat dikenai teknik load balancing ini.

Q : Nginx emang bisa ya buat gituan?

A : Semua webserver sebenarnya didesain untuk ada fitur load balancing ini. Selain fitur VirtualHost, Reverse Proxy, Load Balancer ini biasanya menjadi fitur penting.

Q : Sik sik pak, Reverse Proxy itu apa si?  

A : Reverse Proxy adalah terjemahan dari proxy balik. Proxy server adalah layanan caching dan port forwarding. Ada direct proxy, ada reverse proxy. Direct Proxy terletak di gateway internet suatu lokasi, agar para pengakses internet terbantu dengan fitur caching dan port forwardingnya. Sedangkan Reverse Proxy terletak di depan sebuah webserver, agar memperingan kinerja webserver. FItur reverse proxy inilah yang banyak dimanfaatkan untuk Load Balancer.

Nah, jadi kalau sampeyan-sampeyan merasa bebannya berat, boleh ya beban itu dibagi dengan yang lain. Komputer aja bisa kok kalian gak bisa…

 

NGINX

Nginx,  (baca : engine-x, en-jin-x) saat ini berubah menjadi webserver yang termasuk paling populer. Disamping terhitung paling ringan, Nginx memiliki kekuatan caching yang sangat baik, dengan demikian sangat potensial menjadi mesin reverse proxy, atau bahkan Load Balancer. Bahkan, kemampuan TCP Forwarding dari Nginx ini mampu untuk memforward port-port lain, dengan fitur yang namanya stream.

Nginx masa kini menjadi pilihan bagi para Sysadmin, dan DevOps engineer sebagai unsur untuk memperkuat rancangan infrastruktur layanan network masa kini. Versi yang berjalan saat ini adalah 1.17.0. Ada dua versi besar, Nginx Plus (komersial), dan Nginx free (Community). Bedanya pada beberapa layanan hanya ada di Nginx Plus. Kerasa banget jika pada fitur-fitur HTTP Load Balancer.

 

Load Balancer dengan Nginx

Gambar di atas merupakan skema umum Nginx sebagai HTTP Load Balancer. Biasanya Backend Server 1, 2 dan 3 atau lebih, memiliki karakteristik yang sama. Berisi aplikasi yang sama. Di sana diharapkan saat BS-1 mengalami berat, maka akan juga dishare ke BS-2 dan BS-3.

Q : eh gimana dengan database?

A : Database bisa juga ada load balancing. Tapi tidak dengan cara biasa. Karena database harus selalu sinkron antara node satu dan node lainnya.

Q : Terus gimana caranya?

A : Sik ya saya tak belajar dulu… Lain kali ditulis di sini wis.. Wong di sini ini tempat catatan saya kalau lupa.

 

HTTP Load Balancer Method

Karena kebutuhan load balancing traffic HTTP itu berbeda-beda, maka metoda pembagian bebannya juga beda-beda juga. Misal : ada yang nunggu satu penuh dulu baru kedua diisi. Ada juga yang berusaha tetap sama bebannya. Ada lagi yang mengandalkan persisten session. Agar seorang user yang baru login di BS-1, tidak terlempar ke BS-2 yang menyebabkan gagal session. Dokumentasi tentang HTTP Load Balancer untuk Nginx ini secara lengkap ada di https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/. Saya akan bahas beberapa fitur metoda load balancing, yang disediakan oleh Nginx versi Gratis. (Ya kalik pakai Nginx plus, orang belum bisa beli)….

Syntax konfigurasi umum dalam Nginx Load Balancer :

http {
    upstream nama_upstream {
        nama_method;
        server http://backend-1;
        server http://192.168.0.245;
        server ....;
    }
}

server {
    location / {
        proxy_pass http://nama_upstream;
    }
}

 

 

1. Round Robin

Metoda LB (Load Balancing) Round Robin ini merupakan metode paling populer. Karena metoda tersebut adalah metoda LB default nginx. Default, berarti jika tidak ditentukan, ya dia sudah pasti Round Robin. Metoda ini menggunakan perhitungan beban akses yang mengarah ke tiap Backend Server. Nginx sudah memiliki cara untuk mengukur berat sebuah beban akses. Jika jumlah byte di BS-1 sudah lebih banyak daripada BS-2, segera berpindah ke BS-2. Dan seterusnya.

Metoda ini bagus sih. Cuma semua ada Pros dan Cons nya. Metoda RR (Round Robin), akan menjamin bahwa beban yang masuk ke tiap backend akan selalu sama. Namun kelemahannya adalah, sysadmin harus mempersiapkan metoda untuk mempertahankan session. Karena dengan method ini, seorang user yang sedang login di BS-1, dapat saja di detik berikutnya terlempar ke BS-2. Masalah session yang terlempar-lempar ke banyak backend, untuk PHP dapat juga si diakali dengan ini https://blogit.bimosaurus.com/2019/03/04/replikasi-session-untuk-php-antar-host/. Untuk bahasa pemrograman lain bisa menggunakan cara lain. Java misal dengan RMI.

Ada sih cara lain untuk mendapatkan persistent session, tapi dengan catatan, pakai Nginx Plus. 😁😁

😁😁😁

Syntax Config Round Robin Method Load Balancer adalah sebagai berikut :

http {
    upstream mesin_lb1 {
        server bs1.abcde.net weight=5;
        server 192.168.0.1;
        server 192.168.0.2;
        server 192.168.0.3;
        server 192.168.0.4 backup;
    }
}
server {
    location / {
        proxy_pass http://mesin_lb1;
    }
}

 

Q: Lho-lho-lho om, sik om, weight=5 dan backup itu artinya apa?

A : weight=5 itu artinya adalah memberi prioritas pada mesin BS1. Kenapa si diprioritaskan? Karena bisa saja kemampuan mesin itu lebih yahud ketimbang lainnya. Backup itu artinya : tidak digunakan. Baru akan digunakan ketika lainnya sudah kewalahan. 

 

2. Least Conn

Least Connection, artinya adalah perhitungan balancing berdasarkan jumlah koneksi yang masuk, tak peduli satu koneksinya bebannya sama atau tidak. Jadi kalau sebuah server sudah kena aturan least_conn, maka si HTTP Load Balancer akan  mengatur agar  jumlah koneksi di semua backend server itu selalu sama. Berisiko ndak sih terhadap session? Masih ada, meski tidak sebesar di Round Robin. Yuk kita tengok sintaks konfignya

upstream nama_upstream{
   least_conn;
   server 192.168.100.2;
   server 192.168.100.3;
   server 192.168.100.4;
}
server {
    location / {
        proxy_pass http://nama_upstream;
    }
}

 

3. Hash atau Generic Hash

Metode Load Balancer Hash ini memetakan beban ke masing-masing backend-server dengan cara membuat hashing berdasarkan text dan atau Nginx Variables yang ditentukan dalam hash config. Contoh yang biasa digunakan misalnya antara lain :

 

upstream backend {
    hash $scheme$request_uri;

    server bs1;
    server bs2;
    server bs3;
}

server {
    server_name abc.efghijkl.mno;

    location / {
       proxy_pass http://backend;
    }
}

 

4. IP Hash

IP Hash adalah metode Load balancing yang menerapkan pemetaan beban ke server tertentu berdasarkan IP Client tertentu, ($remote_addr), dengan pola hashing. Maka dengan demikian hasil yang diharapkan adalah adanya persisten session yang diterima oleh seluruh client. Dengan metode ini, client X akan dapat dilayani oleh server X, client Y akan dilayani oleh server Y, dan seterusnya.

Catatan penting !!, bahwa jika client yang dilayani memiliki IPv6, maka  hitungan hashing akan dihitung berdasarkan seluruh alamat. Sepanjang digit IP menjadi faktor hitungannya. Namun, jika client yang dilayani adalah ber-IPv4, maka hitungan hanya didasarkan pada 3 oktet pertama. Jadi, jika melayani /24 gimana? Ya sulit lah…. Oleh karena itu, jika /24 disarankan untuk menggunakan jenis Generic Hash, dengan metode hashing : hash $remote_addr.

Contoh Syntax Nginx Load Balancer dengan IP Hash :

upstream lb_ip_hash{
ip_hash;
server 172.16.30.16;
server 172.16.30.17;
server 172.16.30.18;
server satuduatiga.net;
}

Begitu dideklarasi bahwa method yang dipakai adalah ip_hash, maka Nginx Load Balancer akan segera membuat rumusan agar client tertentu mendapatkan layanan dari backend tertentu. Ini jelas aman sekali untuk para admin yang malas membuat session replication. Sudah barang tentu satu client akan mendapatkan persisten connection terhadap server tertentu. Konon, kelemahan dari metode ini adalah, tingkat kerataan beban akses di masing-masing server, jelas akan kalah dengan RR ataupun Least Conn. Ditambah lagi, proses hashing-hashingan dan rumus-rumusan itu sedikit akan menambah proses pada Nginx untuk mendapatkan hasil Hashing HTTP Load Balancer.

 

Health Check

Health Check adalah suatu cara yang digunakan oleh Nginx Load Balancer untuk mengetahui apakah suatu node backend-server itu dalam kondisi baik atau tidak. Jika tidak dalam kondisi baik, maka beban akan dialihkan ke node backend yang lain. Health check di Nginx ada dua macam. Ada Passive Health Check (semua versi Nginx), dan ada Active Health Check (Nginx Plus saja).

 

1. Passive Health Check Load Balancer

Passive Health Check adalah proses Health Check terhadap Backend Node dengan berdasar response timeout terhadap backend. Jika timeout, barulah dialihkan ke node lainnya. Ada dua parameter yang digunakan dalam check timeout tersebut. Jika parameter tersebut memenuhi syarat sebagai timeout, maka Load Balancer akan memindahkan pemilihan node. Parameter tersebut adalah

• fail_timeout adalah batasan waktu respon atas suatu request. Jika melebihi value yang ditentukan, dianggap timeout ? Analogis dengan gini : “Kalau lo sampai minggu depan nggak ngelamar gue, aku pilih yang lain”
• max_fail adalah jumlah request yang gagal mendapatkan respon

Contoh yuk:

   upstream backend{
      server 172.16.30.16 weight=3 max_fails=3 fail_timeout=30s; 
      server 172.16.30.17 max_fails=3 fail_timeout=30s; 
      server node3.bimosaurus.com max_fails=3 fail_timeout=30s;
      server backup.bimosaurus.com backup;
   }

Artinya adalah bahwa pada statemend untuk backend-server node pertama : server 172.16.30.16 akan mendapat prioritas 3, jika 3 kali gagal dengan maksimal waktu 30 detik, akan dilempar ke tempat lain. Dan seterusnya.

Q : Jadi client bisa mengalami error duluan dong kalau dengan Passive Health Check

A : Iya

Q : Ada solusi nggak?

A : Pakai Nginx Plus 😁🙏

2. Active Health Check Load Balancer

Active Health Check adalah proses cek aktif terhadap seluruh node, dengan harapan sebelum error/timeout terjadi, load balancer sudah dapat memilihkan node lainnya yang lebih sehat. Fitur ini hanya ada di Nginx Plus.

 

Fitur pada Nginx sebenarnya cukup banyak, tidak hanya sebagai Load Balancer, Webserver, Reverse Proxy saja. Fungsi untuk stream juga cukup bagus dan dapat digunakan untuk melakukan UDP Forwarding juga. Dengan kemampuannya itu, Nginx juga kadang dapat juga berfungsi sebagai seperti pengganti NAT.

Q: Contoh nginx lengkap dong…

A: Ya nggak sah lengkap-lengkap dong.. Berikut ini ya….

#/etc/nginx/sites-enabled/mesin_lb1.conf
upstream mesin_lb1{
   server 10.10.10.1 weight=5 max_fails=3 fail_timeout=30s; 
   server 10.10.10.2 max_fails=3 fail_timeout=30s; 
   server 10.10.10.3 max_fails=3 fail_timeout=30s; 
   server node10.bimosaurus.com backup;
}

server {
        listen 80;
        server_name mesin_lb1.bimosaurus.com;
	access_log /var/log/nginx/mesin_lb1.bimosaurus.com_access_log;
	error_log /var/log/nginx/mesin_lb1.bimosaurus.com_error_log;


        location / {
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header        Host $host;
            fastcgi_param REMOTE_ADDR $http_x_real_ip;
            proxy_pass       http://mesin_lb1;
            client_max_body_size 50m;
	    proxy_buffers 8 16m;
	    proxy_buffer_size 32m;

        }
}

Silakan dicoba, semoga bermanfaat, ditunggu saja artikel lainnya. Boleh juga kontak-kontak ke bimosaurus@gmail.com