Penggunaan internet saat ini menuntut kinerja dan waktu aktif. Untuk mencapai hal ini, banyak salinan dari sistem yang sama dijalankan, dan beban didistribusikan di atasnya. Teknik arsitektur ini disebut penskalaan horizontal. Infrastruktur berbasis perangkat lunak semakin populer karena fleksibilitasnya, membuka kemungkinan dunia yang luas. Apakah penggunaan kecil untuk ketersediaan tinggi atau besaran ribuan traffic di seluruh dunia, ada kebutuhan untuk solusi penyeimbangan beban yang sama dinamisnya dengan infrastruktur. NGINX memenuhi kebutuhan ini dalam beberapa cara, seperti HTTP, TCP, dan load balancing UDP, yang Kita bahas dalam posting ini.
Saat menyeimbangkan beban (load Balancing), penting dampaknya bagi klien sangat positif. Banyak arsitektur web modern menggunakan tingkatan aplikasi tanpa tier, menyimpan dalam memori atau database bersama. Namun, ini bukan kenyataan untuk semua. Status sesi sangat penting dan luas dalam aplikasi interaktif. Keadaan ini dapat disimpan secara lokal ke server aplikasi karena sejumlah alasan; misalnya, dalam aplikasi yang datanya dikerjakan sangat besar sehingga kinerja jaringan terlalu mahal. Ketika keadaan disimpan secara lokal ke server aplikasi, sangat penting bagi pengalaman pengguna bahwa permintaan selanjutnya terus dikirim ke server yang sama. Sisi lain dari situasi ini adalah bahwa server tidak boleh dirilis sampai sesi selesai. Bekerja dengan aplikasi stateful pada skala membutuhkan penyeimbang beban yang cerdas. NGINX Plus menawarkan beberapa cara untuk mengatasi masalah ini dengan melacak cookie atau perutean.
Artikel berikut berkaitan dengan load balancing dengan NGINX dan NGINX Plus
Bagaimana mendistribusikan beban antara dua atau lebih server HTTP?
Penggunaan modul HTTP NGINX untuk memuat keseimbangan melalui server HTTP menggunakan upstream Block:
upstream backend {
server 13.22.12.45:80 weight=1;
server dev.example.com:80 weight=2;
}
server {
location / {
proxy_pass http://backend;
}
}
Konfigurasi ini menyeimbangkan beban di dua server HTTP pada port 80. Parameter beben menginstruksikan NGINX untuk memberikan koneksi dua kali lebih banyak ke server kedua, dan parameter beban default ke 1.
HTTP upstream module control load balancing untuk HTTP. Modul ini mendefinisikan tujuan — setiap kombinasi soket Unix, alamat IP, dan catatan DNS, atau campuran. Modul upstream juga menentukan bagaimana setiap permintaan individu ditugaskan ke server upstream mana saja.
Setiap tujuan upstream ditentukan dalam upstream pool oleh server direktif. Arahan server disediakan soket Unix, alamat IP, atau FQDN, bersama dengan sejumlah parameter opsional. Parameter opsional memberikan kontrol lebih besar atas perutean permintaan. Parameter-parameter ini termasuk beban berat server dalam algoritma balancing; apakah server dalam mode siaga tersedia, atau tidak tersedia; dan bagaimana menentukan apakah server tidak tersedia. NGINX Plus menyediakan sejumlah parameter lainnya seperti batas koneksi ke server, kontrol resolusi DNS tingkat lanjut, dan kemampuan untuk peningkatkan koneksi ke server.
Bagaimana mendistribusikan beban antara dua atau lebih TCP server?
Gunakan stream module NGINX untuk menyeimbangkan beban melalui server TCP menggunakan upstream block:
stream {
upstream mysql_read {
server dev1.example.com:3306 weight=5;
server dev2.example.com:3306;
server 13.22.12.34:3306 backup;
}
server {
listen 3306;
proxy_pass mysql_read;
}
}
Blok server dalam contoh ini menginstruksikan NGINX untuk meneruskan ke port TCP 3306 dan menyeimbangkan beban antara dua database MySQL untuk membaca replika, dan mencantumkan yang lain sebagai cadangan yang akan melewati lalu lintas jika pemilihan awal turun. Konfigurasi ini tidak akan ditambahkan ke folder conf.d karena folder itu termasuk dalam blok http; sebagai gantinya, Anda harus membuat folder lain bernama stream.conf.d, buka blok stream di file nginx.conf, dan sertakan folder baru untuk konfigurasi stream.
Penyeimbangan beban TCP ditentukan oleh modul aliran NGINX. Modul stream, seperti modul HTTP, memungkinkan Anda untuk menentukan kumpulan server stream dan mengkonfigurasi listening server. Saat mengonfigurasi listening server pada port yang diberikan, Anda harus menentukan listen port, atau secara opsional, address dan port. Dari sana, tujuan harus dikonfigurasikan, apakah itu proxy balik langsung ke address lain atau ke upstream pool sumber.
Upstream pool untuk TCP load balancing sangat mirip dengan upstream untuk HTTP, dalam hal ini mendefinisikan upstream resorce sebagai server, yang dikonfigurasikan dengan soket Unix, IP, atau nama domain yang memenuhi syarat (FQDN), serta kpasitas server, jumlah koneksi maksimum, Penyesuaian DNS, dan periode peningkatan koneksi; dan jika server aktif, turun, atau dalam mode cadangan.
NGINX Plus menawarkan lebih banyak fitur untuk load balancing TCP. Fitur-fitur canggih yang ditawarkan di NGINX Plus dapat ditemukan di dalam arrtikel ini. Pemeriksaan lainnya untuk semua load balancing akan dibahas di lain artikel berikutnya.
Bagaimana mendistribusikan beban antara dua atau lebih UDP server?
Gunakan stream module NGINX untuk memuat load balance melalui server UDP menggunakan upstream blok yang didefinisikan sebagai udp:
stream {
upstream ntp {
server ntp1.example.com:123 weight=2;
server ntp2.example.com:123;
}
server {
listen 123 udp;
proxy_pass ntp;
}
}
Bagian konfigurasi ini menyeimbangkan beban antara dua upstream Network Time Protocol (NTP) server menggunakan protokol UDP. Menentukan keseimbangan beban UDP semudah menggunakan parameter udp pada listendirective.
Jika layanan yang Anda over load balancing memerlukan beberapa paket untuk dikirim bolak-balik antara klien dan server, Anda dapat menentukan parameter reuseport. Contoh dari jenis layanan ini adalah OpenVPN, Voice over Internet Protocol (VoIP), solusi virtual desktop, dan Datagram Transport Layer Security (DTLS). Berikut ini adalah contoh penggunaan NGINX untuk menangani koneksi OpenVPN dan proksi mereka ke layanan OpenVPN yang berjalan secara lokal:
stream {
server {
listen 1195 udp reuseport;
proxy_pass 127.0.0.1:1194;
}
}
Anda mungkin bertanya, “Mengapa saya membutuhkan penyeimbang beban ketika saya dapat memiliki beberapa host dalam catatan DNS A atau SRV?” Jawabannya adalah tidak hanya ada algoritma penyeimbang alternatif yang dapat digunakan untuk menyeimbangkan, tetapi kita dapat memuat keseimbangan lebih server DNS itu sendiri. Layanan UDP membentuk banyak layanan yang kami andalkan dalam sistem jaringan, seperti DNS, NTP, dan VoIP. Penyeimbangan beban UDP mungkin kurang umum untuk beberapa tetapi sama bermanfaatnya di world of scale.
Anda dapat menemukan penyeimbangan beban UDP dalam modul stream, seperti halnya TCP, dan mengkonfigurasinya sebagian besar dengan cara yang sama. Perbedaan utama adalah bahwa directive listen menentukan bahwa open socket digunakan untuk bekerja dengan datagram. Ketika bekerja dengan datagram, ada beberapa arahan lain yang mungkin berlaku di mana mereka tidak akan dalam TCP, seperti direktif proxy_response, yang menentukan NGINX berapa banyak tanggapan yang diharapkan dapat dikirim dari server upstream. Secara default, ini tidak terbatas hingga batas proxy_timeout tercapai.
Parameter reuseport menginstruksikan NGINX untuk membuat individual listening socket untuk setiap worker process. Ini memungkinkan kernel untuk mendistribusikan koneksi masuk antara worker processes untuk menangani beberapa paket yang dikirim antara klien dan server. Fitur reuseport hanya bekerja di kernel Linux 3.9 dan lebih tinggi, DragonFly BSD, dan FreeBSD 12 dan lebih tinggi.
Semoga artikel ini bermanfaat….
