NGINX Load Balancing

Load Balancing zamonaviy veb-infratuzilmaning muhim jihati bo'lib, kiruvchi trafikni bir nechta serverlar bo'ylab samarali taqsimlashga imkon beradi. NGINX, high-performance web server, proxy server va reverse proxy server load balancing mustahkam imkoniyatlarini taklif etadi. Ushbu qo'llanmada biz NGINX yordamida load balancing tushunchalari(concept) va amaliy amalga oshirilishini ko'rib chiqamiz.

NGINX o'zining high performance, kengaytirilishi(scalability) va advanced xususiyatlari(feature) bilan mashhur bo'lgan ko'p qirrali dasturiy ta'minotdir. U HTTP, HTTPS, TCP va UDP trafigini load balancing qilishi mumkin bo'lgan reverse proxy server sifatida ishlaydi. NGINX-ning Load Balancing imkoniyatlari DevOpslarga/Adminlarga trafikni serverlar o'rtasida samarali taqsimlash uchun turli strategiyalarni o'rnatish imkoniyatini beradi. Ushbu tushunchalarni tushunish va load balancing uchun NGINX-ni to'g'ri sozlash mustahkam va samarali veb-infratuzilmani saqlash uchun asosiy hisoblanadi.

NGINX'da Load Balancing metodlar

• Round Robin-> - bu NGINX-da load balancinning default metodi. U kiruvchi so'rovlarni mavjud serverlar bo'ylab ketma-ket ravishda teng ravishda taqsimlaydi. Har bir keyingi so'rov server pool bo'ylab o'tish orqali navbatdagi serverga yo'naltiriladi.

• Least Connection-> Least Connection metodi kiruvchi so'rovlarni hozirda eng kam faol ulanishga ega serverga yo'naltiradi. Ushbu strategiya trafikni serverlarga joriy ish yukiga(workload) qarab yo'naltirish orqali yanada muvozanatli taqsimlashni ta'minlaydi.

• IP Hash-> IP Hash load balancing clientning IP manzilini ma'lum bir serverga ko'rsatadigan hash funksiyasidan foydalanadi. Ushbu metod bir xil mijoz IP-dan so'rovlar har doim bir xil serverga yo'naltirilishini ta'minlaydi, bu seansning barqarorligi va izchilligini osonlashtiradi.

• Weighted Load Balancing-> Weighted Load Balancing devops/adminlarga serverlarga ularning imkoniyatlari yoki imkoniyatlaridan kelib chiqqan holda turli og'irliklarni(weight) belgilash imkonini beradi. Og'irligi yuqori bo'lgan serverlar kiruvchi trafikning mutanosib ravishda katta qismini oladi, bu esa resurslarni yaxshiroq taqsimlashga imkon beradi.

• Dynamic Load Balancing-> NGINX Plus, commercial versiyasi, real-time ishlash ko'rsatkichlari asosida server og'irliklarini dinamik ravishda sozlaydigan moslashuvchan load balancerni taklif qiladi. Bu xususiyat trafik taqsimotini optimallashtiradi va so'rovlarni kam ishlaydigan serverlardan uzoqlashtiradi.

NGINX bilan load balancing qilish

Bizda quyidagi holat bor: devops-journey.uz (opens in a new tab) platformasiga juda ko'p userlar ko'plab so'rovlar yubormoqda. Bizda atiga bitta server bor va clientlardan kelgan so'rovlar bosimini NGINX bilan load balancing qilishimiz kerak. Bu amaliyotni amalga oshirish uchun bizga 4ta server kerak bo'ladi.

Biz vaziyatimizda devops-journey.uz (opens in a new tab) saytini gorizontal kengaytirishimiz(horizontal scaling) va load balancing qilishimiz kerak.

Kengaytirish(Scaling) ikki xil bo'ladi bu vertikal va gorizontal.

• Vertical Scaling-> Bu bitta serverning resurslarini ko'paytirishni o'z ichiga oladi. Masalan, protsessorni yangilash, qo'shimcha RAM qo'shish yoki serverdagi xotirani kengaytirish. Bu kompyuterga qo‘shimcha imkoniyatlar qo‘shish orqali uni yanada kuchliroq qilish kabi. Biroq, bitta serverni qancha yangilashingiz mumkinligining chegarasi bor va bir nuqtada u juda qimmatga tushishi yoki masshtabni kengaytirishni davom ettirish imkonsiz bo'lishi mumkin. Qisqa qilib aytganda server resurslarini(CPU,RAM,Storage,Network) ko'paytirish orqali kengatirish(scaling)

• Horizontal Scaling-> Tarmoq yoki tizimga qo'shimcha serverlar yoki nodelarni qo'shishni o'z ichiga oladi. Bir serverni kuchliroq qilish o'rniga, yukni taqsimlash uchun ko'proq serverlarni qo'shasiz. Bu ish yukini(workload) yengish uchun bir nechta serverlarning birgalikda ishlashiga o'xshaydi. Ushbu yondashuv kengaytirilishi mumkin va kerak bo'lganda qo'shimcha serverlarni qo'shish orqali ortib borayotgan talablarni qondirishi mumkin. Qisqa qilib aytganda bitta serverni resurlarini kuchaytirgandan ko'ra serverlar sonini ko'paytirib bosimni teng taqsimlash.

Biz gorizontal scalingni tanlaymiz va bizda bitta application serverimiz bor edi uni gorizontal kengaytirib 3ta application server qilamiz va bitta NGINX(Load Balancer) server sozlab olamiz. Endi bizda 3ta application sevrer bor yani 3ta serverda devops-journey.uz platformasi 300 portda ishlab turibti. Ushbu holatda NGINX(Load Balancing)ni ko'rib chiqamiz.

Rasmda holat tasvirlangan.

1. NGINX serverimizni sozlab NGINX o'rnatib olamiz.

Serverni yangilab olamiz.

sudo apt update && sudo apt upgrade -y

NGINX o'rnatamiz

sudo apt install nginx nginx-extras

SSL sertifikat olish uchun certbot o'rnatamiz.

sudo apt install certbot python3-certbot-nginx -y

NGINX o'rnatilganidan keyin uni statusini ko'ramiz.

sudo systemctl status nginx
sudo systemctl enable nginx

NGINX o'rnatganimizdan keyin NGINX Load Balancer sozlashni boshlasak bo'ladi.

NGINX HTTP Load Balancing sozlash

devops-journey.uz (opens in a new tab) uchun /etc/nginx/sites-available jildida NGINX configuratsiya yaratib olamiz.

docker run -d -p 3000:3000 --name devops-journey --restart always devopsjourneyuz/devops-journey-uz:latest

Uchta application serverimizga ham docker o'rnatib SonarQubeni docker orali ishga tushiramiz.

1. Dockerni bash script yozib o'rntamiz.

nano docker.sh

#!/bin/bash
 
# Update and upgrade system packages
sudo apt update && sudo apt upgrade -y
# Install additional utilities
sudo apt install -y curl gnupg2 software-properties-common apt-transport-https 
 
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get -y install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
 
# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
 
sudo apt-get -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-compose
 
# Adjust Docker socket permissions
sudo usermod -aG docker $USER
sudo chmod 666 /var/run/docker.sock
sudo chown $USER:docker /var/run/docker.sock
 
# Restart and enable Docker service
sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl enable docker

Docker o'rnatilganidan keyin SonarQubeni ishga tushiramiz. SonarQube default 9000-portda ishga tushadi

docker run -d --name sonar -p 9000:9000 sonarqube:lts-community

SonarQube 3ta application serverimizda ham ulanganidan keyin har biriga kirib Loginga admin Passowrdga admin yozib kiramiz va yangi parol qo'yishda quyidagicha parol qo'yamiz.

Bunday ko'rinishda login parol qo'yishning o'ziga xos xususiyati bor u orqali biz load balancer qaysi serverdagi SonarQubega yo'naltirganini bilib olishimiz va Load Balancing metodlari to'gri ishlayotganini bilib olamiz.

cd /etc/nginx/sites-available/
nano devops-journey.uz

devops-journey.uz konfiguratsiya ochib olganimzidan keyin quyidagicha Load Balancing konfiguratsiya qilamiz.

upstream backend {
  server 185.168.1.21:9000;
  server 185.168.1.22:9000;
  server 185.168.1.23:9000;
}
server {
    listen 80;
    server_name devops-journey.uz;
 
    location / {
        proxy_pass http://backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Bu NGINX konfiguratsiya devops-journey.uz (opens in a new tab) kelgan requestlarni(so'rovlarni) 3ta application serverga Load balancing qilib turishi kerak.

Keling konfiguratsiyani ko'rib chiqamiz.

upstream backend {
  server 185.168.1.21:9000;
  server 185.168.1.22:9000;
  server 185.168.1.23:9000;
}

NGINX upstream load balancing uchun klaster ochish va boshqarishni bildiradi. konfiguratsiyadagi backend esa klasterimiz nomi. backend klasterimiz ichida serverlarimiz IP manzillari va applicationimiz ishlab turgan portlari ko'rsatilgan. Qancha server bo'lsa shuncha server qo'shib borilaveradi yoki bitta serverda bitta application bir nechta portda ishlab turgan bo'lsa qo'shilaveradi.

Misol uchun bitta serverda bitta application bir nechta portda Docker containerda ishlab turgan bo'lsa quyidagicha bo'ladi.

upstream backend {
  server 185.168.1.21:9000;
  server 185.168.1.21:9001;
  server 185.168.1.21:9002;
}

Ushbu holatda 185.168.1.21 IP manzilli serverda 1ta application replica bo'lib 3ta portda ishlab turibti.

server {
    listen 80;
    server_name devops-journey.uz;

• server bloki ma'lum bir server yoki domen uchun so'rovlarni qayta ishlashga xos konfiguratsiyani qamrab oladi.

• listen 80; server bloki HTTP trafigi uchun standart port bo'lgan 80-portdagi kiruvchi ulanishlarni tinglashini(listen) bildiradi.

• server_name devops-journey.uz; server blokidagi konfiguratsiyani devops-journey.uz domeni bilan bog‘laydi. Ushbu domen uchun so'rov kelib tushganda, ushbu server blokida belgilangan konfiguratsiyalar qo'llaniladi.

    location / {
        proxy_pass http://backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

• location / {...} Bu blok ildiz(root) URL (/) ga qilingan so'rovlarni oladi. Ushbu patternga mos keladigan barcha so'rovlar ushbu blokdagi direktivalar tomonidan qayta ishlanadi.

• proxy_pass http://backend/; Ushbu direktiv Nginx-ga joylashuvga (/) mos keladigan barcha kiruvchi so'rovlarni backend deb nomlangan upstream blokida belgilangan serverlar guruhiga proksi-serverdan o'tkazishni aytadi. Bunday holda, root URL manziliga kelgan har qanday so'rov backend upstream guruhida belgilangan serverlardan biriga yo'naltiriladi.

• proxy_set_header Host $host; Proksilangan soʻrovning Host headerini odatda client soʻrovida mavjud host nomini ifodalovchi $host qiymatiga oʻrnatadi.

• proxy_set_header X-Real-IP $remote_addr; Proksi-so'rovning X-Real-IP headerini $remote_addr qiymatiga o'rnatadi, unda so'rov yuborayotgan clientning IP-manzili mavjud.

• proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; Clientning IP manzilini mavjud X-Forwarded-For headeriga qo'shib, mavjud qiymatlarni saqlaydi. Ushbu header asl clientning IP-manzilini kuzatish uchun ishlatiladi, ayniqsa so'rovlar proksi-serverlar yoki load balancerlar orqali o'tganda.

• proxy_set_header X-Forwarded-Proto $scheme; Proksilangan soʻrovning X-Forwarded-Proto headerini client soʻrovida ishlatiladigan protokolni (http yoki https) ifodalovchi $scheme qiymatiga oʻrnatadi.

Qisqa qilib aytganda, ushbu konfiguratsiya bloki serverning root URL(/) keladigan har qanday so'rovlarni upstreamdagi serverlari guruhi backenddagi barcha serverlarga yo'naltirishni bildiradi va shu bilan birga client ma'lumotlarini saqlash va yo'naltirilgan so'rovga maxsus headerlarni o'zgartirish yoki qo'shish bilan ma'lum tafsilotlarni backend serverlariga yuboradi.

NGINX-da symbolic link yaratib uni reload qilamiz.

sudo ln -s /etc/nginx/sites-available/devop-journey.uz /etc/nginx/sites-enabled/devop-journey.uz
sudo systemctl reload nginx

SSL sertifikat olib HTTP'ni HTTPS qilish uchun certbot o'rnatib SSL sertifikat olamiz

sudo apt update
sudo apt install certbot python3-certbot-nginx

sudo certbot --nginx -d devops-journey.uz

certbot orqali muvafaqqiyatli SSL sertifikat olganingizdan keyin brauzerdan applicatiomizga tashrif buyurishingiz mumkin va https orqali ochilishi kerak.

devops-jourey.uz(bu yerda sizning ilovangiz domeni bo'ladi)ga brauzerda tashrif buyurganingizda sizda quyidagi oyna ochilishi kerak.

Endi qiziq joyi boshlandi, esingizda bo'lsa biz 3ta serverga 3ta SonarQube o'rnatib hammasiga loginga admin parolga esa serverlarga qarab node1, node2, node3 deb parol qo'yib sozlagan edik. Hozir domen orqali applicationimizga kiramiz sizda SonarQubega kirish oynasi ochiladi u yerdan Loginga admin yozamiz va parolga node1 yozamiz agar xato bo'lsa node2, node3 sabab NGINX qaysi serverga yo'naltirganini bilishimiz uchun. Maksimum 3ta urinish bilan to'gri parolni topasiz parol to'gri deydi va kirganida yana SonarQube kirish sahifasiga qaytaradi. Xo'sh buning sababi nima? Sababi shundaki NGINX configuratsiyamizga Load Balancing metodlarini kiritmadik bu holda NGINX default Round Robin metodidan foydalanib load balancing qiladi.

Rasmda hozirgi holatimiz tasvirlangan yani birinchi so'rovda SonarQube kirish sahifasiga kirdik va to'gri login parol kiritib kirishni bosganimzida 2chi so'rov ketti va bu biz ulangan serverga emas balki boshqa serverga yo'naltirildi boshqa serverda esa boshqa login parol mavjud shuning uchun biz login qilib kira olmaymiz SonarQube tanlanganini sababi ham aslida shu edi Load Balancing qanday ishlashini ishlayotganini bilish uchun edi.

Round Robin load balancing metodi Stateless Load balancingga kiradi bu haqida Load Balancing (opens in a new tab) qo'llanmasida yozilgan.

Demak bizni holatimizda Round Robin load balancing to'gri kelmas ekan chunki stateless sessiya ushlamaydi. Xo'sh biz qanday yo'l tutamiz.

Keling NGINX Configuratsiyamizga laod balancing metodlarini qo'shamiz va IP/URL Hash metodidan foydalanib ko'ramiz.

NGINX configuratsiyamizga quyidagi o'zgartisihni kiritamiz NGINXga reload beramiz.

sudo nano /etc/nginx/sites-available/devop-journey.uz

upstream backend {
  ip_hash;
  server 185.168.1.21:9000;
  server 185.168.1.22:9000;
  server 185.168.1.23:9000;
}
server {
    listen 80;
    server_name devops-journey.uz;
 
    location / {
        proxy_pass http://backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

upstream blokiga ip_hash; qo'shib qo'ydik va endi nginx reload berib sinab ko'ramiz.

sudo systemctl reload nginx

Brauzerdan applicationimizga domen orqali kiramiz va maximum 3ta urinish bilan parolni topib login qilib kira olamiz. Bu safar bu muvaffaqqiytali bo'ldi yana biz login qilib kira oldik. Endi boshqa kompyuterlardan kirib ko'ramiz ular boshqa serverlarga tushib qolishadi. Xo'sh bu qanday ishladi qanday qilib kira oldik va qanday ishlab turibti?

Ushbu bizning holatimiz Rasmda tasvirlangan. IP/URL Hash load balancing Stateful Load Balancingga kiradi yani sessiyani saqlab bir marta ulanib olgan serveringiz keyingi so'rovlaringiz ham shu serverga yo'naltiriladi.

Bizda keyingi muammoli vaziyat bor. 3ta application serverimiz resurslari bir xil emas ular quyidagicha deb tassavur qilamiz.

Agar hozir Round Robin yoki IP/URL Hash load balancing algoritmlaridan foydalanadigan bo'lsak resurslari kichik serverlarda bosim ortib ketadi va buni ko'tarolmay qoladi. Yani load balancing metodlari serverlarga sorovlarni teng taqsimlaydi bu holda hamma serverlar resurslari bir xil bo'lsagini yaxshi natija beradi.

Bu vaziyat uchun serverlarga weight berish orqali bu vaziyatdan chiqa olamiz. Yani resurslari ko'p serverlga yuqori weight beriladi resurlari kamroq serverlga weight kam beriladi. Bu holatda load balancer weight yuqori bo'lgan serverlarga so'rovlarni ko'proq yo'naltiradi weight kichik serverlarga esa kamroq so'rovlar yuboriladi.

Buning uchun NGINX configuratsiyamizni quyidagidek yangilaymiz va NGINXga reload berib ishga tushiramiz.

sudo nano /etc/nginx/sites-available/devop-journey.uz

upstream backend {
  server 185.168.1.21:9000 weight=10;
  server 185.168.1.22:9000 weight=8;
  server 185.168.1.23:9000 weight=4;
}
server {
    listen 80;
    server_name devops-journey.uz;
 
    location / {
        proxy_pass http://backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

upstream blokiga weight qo'shib qo'ydik va endi nginx reload berib sinab ko'ramiz.

sudo systemctl reload nginx

Ushbu holat rasmda tasvirlanganidek ishlaydi. Bu Weighted Round Robin load balancing metodida serverlar holatidan kelib chiqib so'rovlarni taqsimlaydi. Bunda Sserver A da resurlar ko'pligi va weight yuqoriligi sabab ko'proq so'rovlar yuboriladi Server C da esa resurslar kamligi va weight kichikligi sabab kamroq so'rovlar yuboriladi. Bu Load Balancing server resurlari bir xil bo'lmaganida qo'l keladi.

Bizni applicationimiz uchun Round Robin load balancing metodi to'gri kelmagani uchun ushbu configuratsiyani IP/URL Hash laod balancing metodida ham ishlata olamiz. Quyida IP/URL Hash Load Balancing metodida serverlarga weight berib load balancing qilish NGINX konfiguratsiyasi.

sudo nano /etc/nginx/sites-available/devop-journey.uz

upstream backend {
  ip_hash;
  server 185.168.1.21:9000 weight=10;
  server 185.168.1.22:9000 weight=8;
  server 185.168.1.23:9000 weight=4;
}
server {
    listen 80;
    server_name devops-journey.uz;
 
    location / {
        proxy_pass http://backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

NGINXda yana bir load balancing metodini qo'llashimiz mumkin bu Least Connections load balancing metodidir. Ushbu load balancing metodi qaysi serverda connection kam bo'lsa shu serverga so'rovlarni yuboradi. Least Connections load balancing metodi Stateful Load Balancing bo'lib sessiya bilan ishlaydi.

Least Connections uchun NGINX configuratsiya quyidagicha

upstream backend {
  least_conn;
  server 185.168.1.21:9000 weight=10;
  server 185.168.1.22:9000 weight=8;
  server 185.168.1.23:9000 weight=4;
}
server {
    listen 80;
    server_name devops-journey.uz;
 
    location / {
        proxy_pass http://backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Ushbu configuratsiya bilan NGINXni ishga tushirsak quyidagi rasmdagidek ishlaydi.

Endi bizda yana bir muammoli vaziyat paydo bo'ldi. 3ta application serverimiz bor lekin ular so'rovlarga har xil tezlikda javob beradi. Load Balancer esa barcha serverlarga so'rovlarni teng taqsimlayapti lekin ba'zi serverlar so'rovlarga sekin javob beryapti bu unga ko'proq yuk tushishiga olib keladi. Xo'sh buni vaziyatga qanday yechimk berishimiz mumkin? Bu vaziyatada biz Least Time load balancing metodidan foydalanamiz bu load balancing metod qaysi serverlar so'rovlarga tez javob bersa shu serverga ko'proq so'rovlar yuboradi sekin javob qayrtaradigan serverlarga esa kam so'rov yuboradi.

Keling bu uchun NGINX Load Balancing konfiguratsiyamizni yangilab NGINXga reload berib ishga tushiramiz.

sudo nano /etc/nginx/sites-available/devop-journey.uz

upstream backend {
  least_time header;
  server 185.168.1.21:9000 weight=10;
  server 185.168.1.22:9000 weight=8;
  server 185.168.1.23:9000 weight=4;
}
server {
    listen 80;
    server_name devops-journey.uz;
 
    location / {
        proxy_pass http://backend/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

upstream blokiga least_time header; load balancing metodini qo'shib qo'ydik va endi nginx reload berib sinab ko'ramiz.

sudo systemctl reload nginx

Ushbu holat quyidagi rasmda tasvirlangan.

Ushbu mavzuda biz NGINX'da HTTP Load balancing configuratsiya qilishni va loyihamizga serverlarimiz holatiga qarab load balancing metodlarini qo'llashni ko'rib chiqdik. Buni hammasi NGINX Open Sourceda ishlaydi. Qolgan Health Check va advanced load balancing uchun NGINX Plus yoki qo'shimcha dasturlar kerak bo'ladi. Keyingi qismlarda TCP/UDP Load balancingni ko'rib chiqamiz.

Qo'shimcha