Cara Setting Load Balancing dengan Nginx

https://musaamin.web.id/cara-setting-load-balancing-dengan-nginx/

Load Balancing adalah sebuah mekanisme untuk membagi atau mendistribusikan trafik ke beberapa server. Nginx selain berfungsi sebagai web server bisa juga berfungsi sebagai load balancer.

Metode Load Balancing

Round Robin: mendistribusikan trafik ke setiap server secara bergantian.
Least Connections: mendistribusikan trafik ke server yang paling sedikit koneksi aktifnya.
IP Hash: mendistribusikan trafik ke server yang sama ketika visitor pertama kali melakukan request.

0.Perangkat yang digunakan

Perangkat yang digunakan di tutorial ini:

OS Ubuntu 18.04 LTS
Nginx web server
PHP-FPM 7.2
Node1: 10.130.127.167
Node2: 10.130.128.35
LoadBalancer: 128.199.187.215
Domain: defnex.com

1.Install Nginx dan PHP-FPM di Node

Install Nginx di Node1 dan Node2.

1
2
3
sudo apt install nginx php php-fpm -y
sudo systemctl status nginx 
sudo systemctl status php7.2-fpm 

Membuat file index.php di Node1.

1
2
sudp mkdir /var/www/defnex.com
sudo echo "<h1>node1</h1>" > /var/www/defnex.com/index.php 

Membuat file index.php di Node2.

1
2
sudo mkdir /var/www/defnex.com
sudo echo "<h1>node2</h1>" > /var/www/defnex.com/index.php 

Membuat server block di Node1 dan Node2.

1
sudo nano /etc/nginx/conf.d/defnex.com.conf 

File konfigurasi server block.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
server {
    listen 80;
 
    server_name defnex.com www.defnex.com;
    root /var/www/defnex.com/;
 
    index index.php index.html index.htm;
 
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
 
    location ~ \.php$ {
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_pass                    unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index                   index.php;
        fastcgi_param DOCUMENT_ROOT     $realpath_root;
        fastcgi_param SCRIPT_FILENAME   $realpath_root$fastcgi_script_name;
    }
 
    access_log /var/log/nginx/defnex.com.access.log;
    error_log /var/log/nginx/defnex.com.error.log warn;
}

Uji dan restart Nginx.

1
2
3
sudo nginx -t
sudo systemctl restart nginx 
sudo systemctl status nginx 

2.Install dan Konfigurasi Nginx di Load Balancer

Install Nginx.

1
2
sudo apt install nginx -y
sudo systemctl status nginx 

Membuat server block untuk load balancing domain defnex.com.

1
sudo nano /etc/nginx/conf.d/lb-defnex.com.conf 

File konfigurasi server block load balancing domain defnex.com.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
upstream backend {
    server 10.130.127.167; #node1
    server 10.130.128.35;  #node2
}
 
server {
    listen 80;
    server_name defnex.com www.defnex.com;
 
    location / {
        proxy_redirect      off;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    Host $http_host;
        proxy_pass http://backend;
    }
} 

Pada konfigurasi upstream backend dituliskan IP address dari backend server. Secara default metode load balancing yang digunakan adalah Round Robin.

Konfigurasi load balancing jika menggunakan metode Least Connections.

1
2
3
4
5
upstream backend {
 least_conn;
    server 10.130.127.167; #node1
    server 10.130.128.35;  #node2
} 

Konfigurasi load balancing jika menggunakan metode IP Hash.

1
2
3
4
5
upstream backend {
 ip_hash;
    server 10.130.127.167; #node1
    server 10.130.128.35;  #node2
} 

Uji dan restart Nginx.

1
2
3
sudo nginx -t
sudo systemctl restart nginx 
sudo systemctl status nginx 

3.Pengujian

Browse domain berulang kali, akan menampilkan halaman dari Node1 dan Node2 secara bergantian.

selamat mencoba 🙂

================================

HTTP Load Balancer dengan Nginx

Bimosaurus, 2 years ago 0 8 min read 1692

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.

nginx for load balancer

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.

Alur Request pada Nginx Load Balancer

Daftar Isi sembunyikan

1 Konfigurasi Dasar Nginx sebagai HTTP Load Balancer

2 Load Balancing Method

5 HTTPS Proxying, Termination vs Pass Through

Konfigurasi Dasar Nginx sebagai HTTP Load Balancer

Seperti yang telah kita coba pada artikel sebelumnya, Nginx sebagai webserver akan memiliki struktur konfigurasi sebagai berikut :

1
2
3
4
5
6
7
 server{
    listen 80;
    location / {
       root /var/www/html;
       index index.html;
    }
}

Sedangkan konfigurasi Nginx HTTP Reverse Proxy akan memiliki struktur dasar

1
2
3
4
    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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 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

1
2
3
4
5
6
    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… 😈 )

1
2
3
4
5
6
    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.

1
2
3
4
5
6
    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 :

1
2
3
4
5
    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

1
2
3
4
5
6
    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..

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
#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

1
2
3
 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).

SSL Method for Load Balancer — Perbandingan peletakan kunci SSL pada HTTP Reverse Proxy

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.

Kumpulan Tutorial Kito

Rabu, 22 Maret 2023

LOADBALANCING-linux

Cara Setting Load Balancing dengan Nginx

0.Perangkat yang digunakan

1.Install Nginx dan PHP-FPM di Node

2.Install dan Konfigurasi Nginx di Load Balancer

3.Pengujian

HTTP Load Balancer dengan Nginx

Konfigurasi Dasar Nginx sebagai HTTP Load Balancer

Load Balancing Method

Round Robin

Least Connection

IP Hash

Generic Hash

Server Weights

Health Check

HTTPS Proxying, Termination vs Pass Through

Tidak ada komentar:

Posting Komentar