Keunggulan Nginx sebagai Reverse Proxy pernah dibahas dalam artikel sebelumnya. Kali ini akan lanjutkan obrolan mengenai kelebihan lain dari Nginx sebagai HTTP Load Balancer. Keunggulan Nginx sebagai HTTP Load Balancer sudah banyak juga dimanfaatkan oleh banyak Sysadmin ataupun Devops Engineer, untuk mengatasi problematika overload aplikasi web. Dalam case ini, Nginx berperan sebagai pembagi beban. Saat difungsikan sebagai HTTP Load Balancer, Nginx akan mengatur beban berdasarkan kriteria yang ditentukan.
Tidak hanya HTTP, Nginx juga dapat melakukan forwarding untuk TCP Load Balancer dan UDP Load Balancer. Sebenarnya, proses load balancing ini adalah gabungan dari proses Reverse Proxy untuk multiple backend ditambah dengan kemampuan Health Check Nginx terhadap backend server. Si Nginx akan selalu ngecek ke backend-nya, server backend mana yang terpantau loadnya lebih ringan, dia akan segera diberikan beban akses selanjutnya. Dengan demikian diharapkan beban proses akan merata di seluruh backend server. Mari kita bahas HTTP Load Balancer lebih dulu.
[lwptoc]
Konfigurasi Dasar Nginx sebagai HTTP Load Balancer
Seperti yang telah kita coba pada artikel sebelumnya, Nginx sebagai webserver akan memiliki struktur konfigurasi sebagai berikut :
server{
listen 80;
location / {
root /var/www/html;
index index.html;
}
}
Sedangkan konfigurasi Nginx HTTP Reverse Proxy akan memiliki struktur dasar
server{
listen 80;
proxy_pass http://ip.ad.dr.es:80;
}
Sebagai HTTP Load Balancer, konfigurasi Nginx akan memiliki struktur yang tidak jauh berbeda dengan HTTP Reverse Proxy:
- memastikan lokasi tag http{}
- membuat group backend
- membuat Listener Server, dan memanggil proxy pass seperti yang namanya didefinisikan pada backend upstream
http{
upstream lb-ecampuz{
#baris method : round_robin, least_conn, ip_hash, hash, least_time, random
server 192.168.100.2 weight=5;
server 192.168.100.3;
server 192.168.100.4;
server 192.168.100.5 backup;
}
server{
server_name loadbalancing.ecampuz.net;
listen 80;
location /{
proxy_pass http://lb-ecampuz:80;
proxy_redirect off;
proxy_set_header Host $host;
#dst
}
}
}
Pada konfigurasi di atas, artinya adalah,
- server tersebut akan dipanggil dengan nama loadbalancing.ecampuz.net, berjalan pada port 80.
- membuat group upstream backend dengan nama lb-ecampuz.
- group upstream backend berisi 4 server backend, salah satu sebagai backup, salah satu diprioritaskan dengan weight 5
Pada bagian upstream backend, selain adanya opsi untuk menentukan backend node, ada juga advanced option yang dapat diatur untuk keperluan pengaturan lebih detail. Opsi tersebut antara lain adalah :
- Load Balancing Method
- Server Weights
- Server Slow Start (Nginx Plus)
- Enabling Session Persistence (Nginx Plus)
- Limitasi Koneksi (Nginx Plus)
- HTTP Load Balancer Health Check
Banyak ya..!! Tapi kita tidak akan menggunakan semua itu, kecuali memang dibutuhkan kondisi khusus. Oh ya, untuk Nginx plus adalah produk Nginx yang berbayar, yang tentu memiliki modul, fitur, jaminan dan kegunaan yang tidak dimiliki oleh Nginx biasa. Di sini tidak akan kita bahas lebih dulu konfigurasi untuk Nginx Plus. Mari kita bahas sepintas satu-satu.
Load Balancing Method
Metode yang digunakan oleh Nginx sebagai Load Balancer ada beberapa. Antara lain adalah :
- Round Robin
- Least Connection
- IP Hash
- Generic Hash
- Least Time (nginx-plus saja)
- Random (sebagian hanya bisa di nginx-plus)
Kita bahas nomor 1 sampai 4 saja dulu, untuk yang membutuhkan akses nginx – plus, lain kali saja.
Round Robin
Round Robin merupakan default method. JIka parameter ini tidak ditentukan, maka sudah otomatis method yang digunakan adalah Round Robin. Sebenarnya apakah Round Robin itu? Round Robin adalah sistem setengah kompetisi. Sebuah beban akses akan diarahkan pada backend node yang masih memiliki beban kecil, berapapun jumlah koneksinya. Pertimbangannya adalah “beban server”. Sifatnya paralel.
Keunggulan Round Robin adalah beban akan merata ke masing-masing node, dan konfigurasi tidak pusing. Kelemahan Round Robin ini potensi adanya suatu client yang terputus sessionnya, karena si client ini saat pertama akses login session mendapatkan jatah di node pertama, saat akses ke dua diberikan node kedua, di mana di node kedua ini tidak tersimpan file penanda sessionnya. Bisakah diatasi? Tim eCampuz tentu sudah menyiapkan pembuatan naskah tentang hal ini. Kelak kita bahas ya 😉
Konfigurasi pada alinea sebelum ini adalah contoh untuk penggunaan Round Robin Method
Least Connection
Least connection adalah metode yang mengarahkan pada jumlah koneksi paling sedikit, tidak peduli dengan besarnya byte beban akses dan siapa clientnya. Jika backend node A sudah memiliki 100 akses (meskipun akses ringan), sementara node B memiliki 90 akses (meskipun akses berat), maka akses selanjutnya tetap akan diberikan pada node B. Contoh konfigurasi adalah
upstream lb-ecampuz{
least_conn;
server 192.168.100.2;
server 192.168.100.3;
server 192.168.100.4;
}
IP Hash
IP Hash ini keren. IP Client atau REMOTE_ADDR, akan dirumus dihitung dengan rumusan hashing tertentu, sehingga mendapatkan penentuan “Client yang ini bakal dapat node mana”. Dengan metode IP Hash ini, tentu akan lebih menjamin seorang client tidak akan terputus sessionnya gara-gara dibagi ke node lain.. Dengan menggunakan IP Hash ini, sysadmin nggak perlu repot-repot membuat session replication dong. (Etapi session replication juga seru lho… 😈 )
upstream lb-ecampuz{
ip_hash;
server 192.168.100.2;
server 192.168.100.3;
server 192.168.100.4;
}
Generic Hash
Generic Hash ini juga keren. Backend Node tujuan, akan ditentukan berdasarkan sesuatu yang dibawa oleh si client, yang dalam hal ini disebut dengan “key”. Bisa saja berupa variable, string atau parameter lain.
upstream lb-ecampuz{
hash $request_uri consistent;
server 192.168.100.2;
server 192.168.100.3;
server 192.168.100.4;
}
Dari beberapa jenis Load Balancer method ini, manakah yang paling ringan bagi Nginx untuk bekerja? Jawabannya jelas : Round Robin dan Least Conn. Karena dalam operasionalnya, Nginx tentu tidak pusing-pusing membuat hash IP dan segala hal. Tapi memang bagi para sysadmin harus menyiapkan konsekuensinya : menyiapkan session replication pada masing-masing backend node, untuk mengantisipasi client kehilangan session akibat alih-penanganan backend node.
Server Weights
Apa sih server weights itu? Secara bahasa, jelas Server Weights adalah bobot server. Bobot server adalah dianggap sebagai kapasitas sebuah server untuk menangani beban akses. Sifatnya adalah perbandingan. Pada penentuan backend node server, defaultnya (jika nilai tidak ditentukan), maka seluruh Server Weights adalah sama, yaitu 1.
Perhatikan pada contoh berikut ini :
upstream lb-ecampuz{
server 192.168.100.2 weight=3; #node1
server 192.168.100.3; #node2
server 192.168.100.4; #node3
}
Pada contoh tersebut, server node2 dan node3 dianggap memiliki server weights 1. Sedangkan node1 memiliki weights 3. Dengan kondisi seperti itu, jika terdapat 5 beban akses, maka 3 buah akan diserahkan pada server node1, sedang node2 dan node3 akan mendapat masing-masing satu beban.
Health Check
Health Check adalah cara suatu server proxy atau load balancer untuk melakukan pemeriksaan kesiapan backend node servernya. Untuk konfigurasinya, dapat dilakukan oleh sysadmin. Mari kita bahas parameter konfigurasinya, antara lain :
- Passive Health Check (Nginx Plus dan Nginx Open Source). Nginx akan memonitor berdasarkan timeout, alias insiden time out telah terjadi, baru kemudian menyatakan bahwa node tidak dalam kondisi bagus
- fail_timeout, adalah satuan waktu untuk Nginx menyatakan bahwa sebuah backend node terjadi timeout.
- max_fails, adalah jumlah kegagalan akses ke backend node, hingga akhirnya Nginx melakukan pemindahan akses (fileover), ke node yang lain.
- Active Health Check (Nginx Plus). Nginx akan memonitor secara aktif. Keunggulannya, sebelum insiden terjadi nginx sudah dapat menentukan bahwa backend node tidak dalam kondisi yang baik
Contoh konfigurasi antara lain
upstream lb-ecampuz{
server 192.168.100.2 weight=3 max_fails=3 fail_timeout=30s; #node1
server 192.168.100.3 max_fails=3 fail_timeout=30s; #node2
server 192.168.100.4 max_fails=3 fail_timeout=30s; #node3
server 192.168.100.5 backup;
}
Semua referensi ini mengacu pada docs.nginx.com dan juga pengalaman sehari-hari tim eCampuz.
Q : Bisakah saya menggunakan nama backend itu dengan nama domain, bukan IP?
A : Lho justru boleh, karena memang sebenarnya domain yang diharapkan. Itu akan sangat penting saat backend node node load balancer memiliki banyak VirtualHost.
Q : Bagaimana dengan TCP/UDP Load Balancing?
A : Sebenarnya hampir sama saja, hanya saja pada non HTTP, si Proxy hanya akan berlaku sebagai port forwarder saja, tidak sampai ke caching.
Q : Contohnya apa saja?
A : SMTP Load balancing dan DNS misalnya.
Q : Kalau HTTP Load Balancing, nanti databasenya beda dong antara backend node A dengan backend node B?
A : Untuk database nanti bisa saja tetap satu koneksi database. Bisa juga database di-load balancing juga. Untuk upload file, nanti ada mekanisme replikasi juga ke seluruh server, atau juga bisa via mounting ke satu storage secara bersamaan.
Q : Contoh konfigurasi virtualhost yang menggunakan Load Balancer yang lengkap dong min
A : Boleeh..
#lokasi file di /etc/nginx/sites-enabled/contohlb.ecampuz.net
server {
listen 80;
server_name contohlb.ecampuz.net;
return 301 https://$host$request_uri; #semua yang ngarah ke http, lempar ke https
access_log /var/log/nginx/contohlb.ecampuz.net_access_log;
error_log /var/log/nginx/contohlb.ecampuz.net_error_log;
}
upstream contohlb{
server 192.168.100.2 weight=3 max_fails=3 fail_timeout=30s; #node1
server 192.168.100.3 max_fails=3 fail_timeout=30s; #node2
server contohlb3.ecampuz.net max_fails=3 fail_timeout=30s; #node3
server backuplb.ecampuz,net backup;
}
server {
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/contohlb.ecampuz.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/contohlb.ecampuz.net/privkey.pem;
access_log /var/log/nginx/contohlb.ecampuz.net_access_log;
error_log /var/log/nginx/contohlb.ecampuz.net_error_log;
server_name contohlb.ecampuz.net;
ssl_session_cache shared:SSL:50m;
#ssl_stapling on;
#ssl_stapling_verify on;
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 https://contohlb:443;
client_max_body_size 50m;
proxy_buffers 8 16m;
proxy_buffer_size 32m;
}
}
Ini ya, contohnya, kami memasang di Nginx Ubuntu, pada /etc/nginx/sites-available/contohlb.ecampuz.net.conf. Lantas setelah itu kami lakukan
ln -s /etc/nginx/sites-available/contohlb.ecampuz.net.conf /etc/nginx/sites-enabled/ systemctl reload nginx
HTTPS Proxying, Termination vs Pass Through
Contoh di atas, kami menggunakan HTTPS, dengan semua traffic HTTP dialihkan ke HTTPS. Pembuatan HTTPS nya dengan menggunakan SSL Letsencrypt, yang tutorialnya dapat diambil di : sini. Dalam dunia Reverse Proxy / Load Balancer untuk HTTPS ada dua macam metode dalam meletakkan kunci SSL-nya.
- Termination SSL (Kunci SSL diletakkan di proxy). Data encrypt dibongkar di proxy, selanjutnya dikirim ke backend tanpa SSL
- Pass through (Kunci SSL diletakkan di backend node). Proxy hanya melewatkan saja segala transfer data.
- Bridging SSL. Proxy melakukan pembongkaran data encrypt, kemudian dikirim forward ke backend dengan SSL lagi
Dalam kenyataannya, banyak juga aplikasi yang meminta kedua SSL-key diletakkan di kedua tempat (Proxy dan Backend) atau Bridging, contohnya adalah WordPress, karena WordPress menerapkan pemanggilan URL secara dinamik sampai ke pemanggilan protokol scheme nya (http atau https).
Selain Nginx, ada lagi sebuah HTTP / TCP UDP Proxy Engine (Load Balancer) yang populer digunakan para devops hacktivists, yaitu HAProxy (High Availability Proxy). HAproxy ini sifatnya Open Source, dan sangat ringan untuk digunakan. Beberapa method load balancing yang dimiliki cukup banyak. Bahkan ada juga yang di Nginx hanya ada di Nginx-Plus, namun di HAProxy sudah disiapkan. Hanya saja, karena HAProxy ini memang disiapkan untuk proxying dan load balancing, maka dia tidak menyediakan fitur webserving biasa (VirtualHost). Kapan-kapan kita bahas juga ya 🙂
Bermain trik dan tips teknologi termasuk teknologi load balancer, di dunia kampus sebenarnya mengasyikkan. Kasusnya banyak, kebutuhannya kompleks, pelajaran yang didapat cukup lengkap. Kadang ada kampus yang harus mengakali bagaimana menghadapi segala keruwetan dengan kondisi terbatas sehingga sysadmin di kampus mereka kaya akan trik. Banyak juga kampus yang memiliki infrastruktur cukup memadai sehingga memungkinkan para sysadmin lebih mengenal perangkat mahal dibandingkan sysadmin di tempat lain.
