Hướng dẫn cân bằng tải nginx 1 vps hứng request và 3 vps còn lại xử lý nghiệp vụ

“1 VPS hứng request → chia sang 3 VPS chạy” luôn, kiểu kiến trúc phổ biến nhất ngoài đời 👇

1️⃣ Mô hình tổng thể (rất quan trọng)

Internet
   |
   v
[VPS 1 - Nginx Load Balancer]
   |        |        |
   v        v        v
[VPS 2]  [VPS 3]  [VPS 4]
(App)    (App)    (App)

• VPS 1:
  • IP public
  • Chỉ làm nhiệm vụ Nginx cân bằng tải
• VPS 2,3,4:
  • Chạy web/app thật (PHP, Node, CI3, WP…)
  • Có thể không cần public IP (private IP càng tốt)

2️⃣ Điều kiện cần

Trên VPS 1 (Load balancer)

• Ubuntu / Debian
• Nginx
• Mở port 80 / 443

Trên VPS 2,3,4 (Backend)

• Web server đang chạy:
  • Nginx + PHP-FPM
  • hoặc Apache
  • hoặc NodeJS
• App giống nhau 100%
• Database dùng chung (1 DB server hoặc DB cluster)

3️⃣ Cấu hình Nginx cân bằng tải (VPS 1)

Ví dụ backend IP

VPS 2: 10.0.0.2
VPS 3: 10.0.0.3
VPS 4: 10.0.0.4

3.1 Khai báo upstream

upstream backend_app {
    least_conn;
    server 10.0.0.2:80;
    server 10.0.0.3:80;
    server 10.0.0.4:80;
}

👉 Giải thích:

• least_conn: đẩy request vào server đang ít kết nối nhất
• Có thể thay bằng:
  • round_robin (mặc định)
  • ip_hash (giữ session theo IP)

3.2 Server block hứng request

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend_app;
        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;
    }
}

✔ Request từ user → VPS 1
✔ VPS 1 → phân sang VPS 2/3/4

4️⃣ HTTPS (rất hay bị hỏi)

👉 Chỉ cần SSL ở VPS 1

• Cài Certbot trên VPS 1
• Backend chỉ cần HTTP nội bộ

certbot --nginx -d example.com

5️⃣ Session & Login (cực kỳ quan trọng)

❌ Sai lầm phổ biến

• Session lưu file local
• User login xong refresh là văng

✅ Cách chuẩn

Cách 1: Redis (khuyến nghị)

• Redis server riêng
• CI3 / PHP / WP đều hỗ trợ

Cách 2: ip_hash

upstream backend_app {
    ip_hash;
    server 10.0.0.2;
    server 10.0.0.3;
    server 10.0.0.4;
}

⚠ Không scale tốt bằng Redis

6️⃣ Health check (tránh chết 1 node là sập)

upstream backend_app {
    server 10.0.0.2 max_fails=3 fail_timeout=10s;
    server 10.0.0.3 max_fails=3 fail_timeout=10s;
    server 10.0.0.4 max_fails=3 fail_timeout=10s;
}

👉 1 VPS chết → Nginx tự loại

7️⃣ Khi nào nên dùng mô hình này

✔ Traffic trung bình → cao
✔ Muốn scale ngang
✔ Không muốn dùng Cloud LB (AWS / GCP đắt)
✔ Chủ động control hệ thống

8️⃣ Khi KHÔNG nên dùng

❌ App còn nhỏ
❌ Chưa xử lý session
❌ Database yếu → LB cũng không cứu được

9️⃣ Gợi ý nâng cao (chuẩn production)

• VPS 1 chạy:
  • Nginx
  • Fail2ban
  • Rate limit
• Backend:
  • Không public IP
• Có thể thêm:
  • 2 LB + Keepalived (VIP)
  • Redis cluster
  • Docker / CI-CD