Xây dựng hạ tầng uptime 99.99% với Keepalived, HAProxy và NGINX trên Ubuntu 26.04

Khi sản phẩm Software-as-a-Service (SaaS) của bạn được thiết kế để đáp ứng SLA 99.99%, hạ tầng phải có khả năng tự động hấp thụ sự cố. SLA 99.99% chỉ cho phép khoảng 52 phút gián đoạn mỗi năm. Nếu load balancer chính gặp sự cố lúc 2 giờ sáng Chủ nhật, hệ thống cần phục hồi trong vài giây, trước khi kỹ sư có thể can thiệp.

Một quản trị viên hạ tầng Linux giàu kinh nghiệm có thể sử dụng bộ công cụ này khi cung cấp dịch vụ quản trị IT cho SaaS yêu cầu vận hành liên tục, không gián đoạn. Bộ công cụ kết hợp ba thành phần:

• NGINX – phục vụ ứng dụng của bạn trên hai (hoặc nhiều) web server
• HAProxy – phân phối traffic đến các web server đó kèm kiểm tra sức khỏe
• Keepalived – chạy trên hai nút load balancer, chia sẻ một địa chỉ IP ảo (floating IP), tự động chuyển đổi dự phòng qua VRRP

Kết hợp lại, chúng mang lại khả năng chuyển đổi dự phòng tự động và cân bằng tải linh hoạt, giảm thiểu gián đoạn dịch vụ.

Trong hướng dẫn này, chúng tôi sẽ trình bày cách xây dựng toàn bộ bộ công cụ từ đầu. Kiến trúc gồm hai load balancer chia sẻ một địa chỉ IP ảo, tự động chuyển đổi dự phòng giữa chúng, đứng trước hai máy chủ web.

Các lệnh và tệp cấu hình đã được kiểm tra trên Ubuntu 26.04 LTS ("Resolute Raccoon") và cũng hoạt động không thay đổi trên Ubuntu 24.04 LTS ("Noble Numbat").

Đến cuối hướng dẫn, bạn sẽ có một hạ tầng SaaS có tính sẵn s cao, được thiết kế để giảm thiểu thời gian chết và hỗ trợ các ứng dụng hướng tới SLA 99.99%.

Tổng quan kiến trúc

-c

Internet / Clients
│
▼
Floating IP: 192.168.0.100
│
┌──────────────┴──────────────┐
│                              │
node-lb01 (MASTER)             node-lb02 (BACKUP)
192.168.0.11                    192.168.0.12
Keepalived + HAProxy            Keepalived + HAProxy
│                              │
└──────────────┬───────────────┘
▼
┌─────────────┴─────────────┐
│                            │
web01                        web02
192.168.0.21 (NGINX)         192.168.0.22 (NGINX)

Cách hoạt động:

1. Keepalived chạy trên cả hai load balancer và dùng VRRP (Virtual Router Redundancy Protocol) để bầu chọn một nút làm MASTER. MASTER giữ địa chỉ IP ảo 192.168.0.100.
2. HAProxy chạy trên cả hai load balancer tại mọi thời điểm, lắng nghe trên IP ảo, và chuyển tiếp traffic đến web01 và web02 dựa trên kiểm tra sức khỏe.
3. Nếu node-lb01 gặp sự cố (crash, mất mạng, HAProxy chết), Keepalived trên node-lb02 phát hiện thiếu bản tin quảng bá VRRP và tự thăng cấp thành MASTER, chiếm IP ảo trong vòng 1–3 giây.
4. NGINX trên web01 và web02 phục vụ ứng dụng thực tế. HAProxy liên tục kiểm tra sức khỏe và tự động loại bỏ nút chết khỏi vòng quay.

Sơ đồ mạng

Điều kiện tiên quyết

• Năm máy hoặc VM Ubuntu 26.04 LTS (hoặc 24.04 LTS) khớp với bảng trên, tất cả trên cùng một mạng layer-2 (VRRP phụ thuộc vào multicast/broadcast, vì vậy hai nút LB phải chia sẻ cùng một subnet).
• Quyền root hoặc sudo trên tất cả các máy.
• Quy tắc tường lửa cho phép:
  • Cổng 80/443 đến IP ảo từ máy khách
  • Cổng 80 từ các nút LB đến các web server
  • Giao thức VRRP (IP protocol 112) và địa chỉ multicast 224.0.0.18 giữa hai nút LB
• Làm quen cơ bản với systemd và chỉnh sửa tệp cấu hình qua SSH.

Ubuntu 26.04 đi kèm UFW (nền tảng là nftables) nhưng bị tắt theo mặc định, vì vậy nó sẽ không can thiệp cho đến khi bạn bật. Nếu bạn muốn bật, đây là các quy tắc khớp với sơ đồ này. Chạy trên các máy phù hợp trước khi bật UFW để không tự khóa mình ngoài SSH:

# On both node-lb01 and node-lb02
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow from 192.168.0.0/24 to any port 8404 proto tcp   # stats page, LAN only
sudo ufw allow from 192.168.0.11 to 224.0.0.18 proto vrrp
sudo ufw allow from 192.168.0.12 to 224.0.0.18 proto vrrp
# On both web01 and web02
sudo ufw allow 22/tcp
sudo ufw allow from 192.168.0.11 to any port 80 proto tcp
sudo ufw allow from 192.168.0.12 to any port 80 proto tcp
# Then, on each host:
sudo ufw enable

Nếu hai load balancer của bạn là VM đám mây (AWS, Azure, GCP, v.v.) thay vì máy vật lý hoặc VM tại chỗ, hãy kiểm tra ghi chú về unicast VRRP trong Phần 6 trước khi tiếp tục. Hầu hết các mạng đám mây âm thầm chặn traffic multicast mà VRRP sử dụng theo mặc định, và Keepalived sẽ có vẻ hoạt động nhưng không bao giờ thực sự chuyển đổi dự phòng.

Phần 1: Thiết lập máy chủ web (web01, web02)

Chạy phần này trên cả hai web01 và web02.

1.1 Cập nhật hệ thống và cài đặt NGINX

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx

1.2 Xác nhận NGINX đang chạy

sudo systemctl enable --now nginx
sudo systemctl status nginx

1.3 Tạo trang kiểm tra phân biệt

Điều này giúp bạn xác nhận trực quan HAProxy cân bằng tải chính xác sau này. Chạy lệnh tương ứng trên mỗi máy chủ.

Trên web01:

echo "<h1>Response from web01 (192.168.0.21)</h1>" | sudo tee /var/www/html/index.html

Trên web02:

echo "<h1>Response from web02 (192.168.0.22)</h1>" | sudo tee /var/www/html/index.html

1.4 Thêm endpoint kiểm tra sức khỏe nhẹ

HAProxy sẽ thăm dò đường dẫn này để xác định backend có khỏe không. Giữ nó tách biệt với thư mục gốc ứng dụng để bạn có thể trả về mã 200/503 có kiểm soát độc lập với logic ứng dụng.

echo "OK" | sudo tee /var/www/html/healthz

Xác minh từ một máy khác:

curl http://192.168.0.21/healthz
curl http://192.168.0.22/healthz

Cả hai phải trả về OK.

Phần 2: Thiết lập HAProxy (node-lb01, node-lb02)

Chạy phần này trên cả hai nút load balancer. Cấu hình giống hệt nhau trên cả hai.

2.1 Cài đặt HAProxy

sudo apt update && sudo apt upgrade -y
sudo apt install -y haproxy

Kho lưu trữ mặc định của Ubuntu 26.04 cung cấp trực tiếp HAProxy 3.2, đủ mới cho mọi thứ trong hướng dẫn này (Ubuntu 24.04 cung cấp HAProxy 2.8, cũng hoạt động fine với cấu hình bên dưới). Vì vậy, không cần PPA hoặc kho bên thứ ba.

Xác minh những gì bạn có:

haproxy -v

Hoặc,

sudo haproxy -v

Kết quả mẫu:

HAProxy version 3.2.9-1ubuntu2.2 2026/06/19 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2030.
Known bugs: http://www.haproxy.org/bugs/bugs-3.2.9.html
Running on: Linux 7.0.0-28-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 21 01:01:36 UTC 2026 x86_64

2.2 Cấu hình HAProxy

Sao lưu cấu hình mặc định, sau đó thay thế nó:

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
sudo nano /etc/haproxy/haproxy.cfg

Sử dụng cấu hình này:

global
log /dev/log local0
log /dev/log local1 notice
maxconn 4096
user haproxy
group haproxy
daemon
defaults
log     global
mode    http
option  httplog
option  dontlognull
timeout connect 5s
timeout client  30s
timeout server  30s
retries 3
# Stats page for quick visibility into backend health
listen stats
bind *:8404
stats enable
stats uri /stats
stats refresh 10s
stats auth admin:ChangeThisPassword!
frontend http_front
bind 192.168.0.100:80
default_backend web_servers
backend web_servers
balance roundrobin
option httpchk GET /healthz
http-check expect status 200
default-server inter 2s fall 3 rise 2
server web01 192.168.0.21:80 check
server web02 192.168.0.22:80 check

Ghi chú về cấu hình này:

• bind 192.168.0.100:80 – HAProxy liên kết với IP ảo, không phải IP riêng của nút. Điều này có nghĩa HAProxy cần net.ipv4.ip_nonlocal_bind = 1 (được đề cập bên dưới), vì IP ảo sẽ không xuất hiện trên interface của nút BACKUP.
• option httpchk GET /healthz với fall 3 rise 2 – một backend được đánh dấu down sau 3 lần kiểm tra thất bại liên tiếp và được đánh dấu khỏe lại sau 2 lần thành công liên tiếp, kiểm tra mỗi 2 giây. Điều này tránh tình trạng rung lắc do một gói tin bị rớt.
• Thay đổi mật khẩu trang stats trước khi triển khai bất cứ thứ gì giống production.
• option httpchk GET /healthz (phương thức + URI, không thêm gì else) vẫn được hỗ trợ đầy đủ trong HAProxy 3.2 và là dạng đơn giản nhất cho kiểm tra cơ bản. Nếu sau này bạn muốn thêm header tùy chỉnh hoặc phiên bản HTTP cụ thể vào yêu cầu kiểm tra, hãy sử dụng cú pháp mới hơn http-check send meth GET uri /healthz hdr Host example.com thay thế. Việc nhồi thêm chi tiết đó vào cuối dòng option httpchk là không được khuyến khích và sẽ đưa ra cảnh báo cấu hình.

2.3 Cho phép HAProxy liên kết với IP không phải local

Vì IP ảo chỉ thực sự xuất hiện trên nút hiện là MASTER, cả hai nút cần được phép liên kết với nó trước:

sudo sysctl -w net.ipv4.ip_nonlocal_bind=1
echo "net.ipv4.ip_nonlocal_bind = 1" | sudo tee -a /etc/sysctl.conf

2.4 Xác thực và khởi động HAProxy

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl enable --now haproxy
sudo systemctl status haproxy

Tiếp theo chúng ta sẽ thiết lập Keepalived trên cả hai load balancer.

Phần 3: Thiết lập Keepalived (node-lb01, node-lb02)

3.1 Cài đặt Keepalived

Trên cả hai nút:

sudo apt install -y keepalived

3.2 Tạo script kiểm tra sức khỏe

Keepalived chỉ nên quảng bá IP ảo từ một nút nếu HAProxy trên nút đó thực sự còn sống.

Tạo script này trên cả hai nút:

sudo tee /etc/keepalived/check_haproxy.sh > /dev/null << 'EOF'
#!/bin/bash
# Exit 0 = healthy, exit 1 = unhealthy
if systemctl is-active --quiet haproxy; then
exit 0
else
exit 1
fi
EOF

Làm cho nó có thể thực thi:

sudo chmod +x /etc/keepalived/check_haproxy.sh

3.3 Cấu hình Keepalived trên node-lb01 (MASTER)

Tạo tệp cấu hình keepalived cho nút Master:

sudo nano /etc/keepalived/keepalived.conf

Thêm nội dung sau:

vrrp_script chk_haproxy {
script "/etc/keepalived/check_haproxy.sh"
interval 2
weight -60
fall 3
rise 2
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass ChangeThisSecret
}
virtual_ipaddress {
192.168.0.100/24
}
track_script {
chk_haproxy
}
}

Thay eth0 bằng tên interface mạng thực tế của bạn. Bạn có thể kiểm tra bằng lệnh ip a. Trên nhiều image đám mây, nó là ens3, ens5, hoặc tương tự.

3.4 Cấu hình Keepalived trên node-lb02 (BACKUP)

Cùng tệp, trên nút thứ hai, với hai khác biệt: state BACKUP và priority thấp hơn.

sudo nano /etc/keepalived/keepalived.conf

Thêm các dòng sau:

vrrp_script chk_haproxy {
script "/etc/keepalived/check_haproxy.sh"
interval 2
weight -60
fall 3
rise 2
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass ChangeThisSecret
}
virtual_ipaddress {
192.168.0.100/24
}
track_script {
chk_haproxy
}
}

Giải thích các tham số chính:

• virtual_router_id – Phải giống hệt nhau trên cả hai nút; đó là cách chúng nhận ra nhau là cùng một nhóm VRRP. Phải là duy nhất trên LAN nếu có các nhóm VRRP khác.
• priority – Cao hơn sẽ thắng bầu chọn. node-lb01 (150) trở thành MASTER khi cả hai khỏe; node-lb02 (100) tiếp quản khi node-lb01's hiệu dụng priority giảm xuống dưới 100.
• weight -60 trên chk_haproxy – Đây là phần thực sự liên kết chuyển đổi dự phòng của Keepalived với sức khỏe của HAProxy. Trong Keepalived, một trọng số âm được trừ vào priority của instance khi script được theo dõi đã thất bại fall (3) lần liên tiếp. Trọng số dương sẽ làm ngược lại (cộng vào priority khi thành công) và sẽ không kích hoạt chuyển đổi dự phòng ở đây. Với weight -60, nếu HAProxy chết trên node-lb01, priority hiệu dụng của nó giảm từ 150 xuống 90 — dưới mức 100 của node-lb02 — vì vậy node-lb02 chiếm IP ảo.
• auth_pass – Phải khớp trên cả hai nút. Nó ngăn traffic VRRP không liên quan trên cùng mạng can thiệp. Lưu ý rằng auth_type PASS gửi mật khẩu này dưới dạng văn bản rõ trên đường truyền (chỉ 8 ký tự đầu tiên thực sự được sử dụng). Nó nhằm ngăn chặn nhiễu chéo ngẫu nhiên giữa các nhóm VRRP không liên quan trên một LAN dùng chung, không phải để chống lại kẻ tấn công đã có mặt trên mạng đó. Nếu bạn cần bảo vệ thực sự chống lại traffic VRRP giả mạo, hãy xem tùy chọn mới hơn auth_hmac của Keepalived.
• advert_int 1 – MASTER gửi quảng bá mỗi 1 giây; BACKUP coi MASTER chết sau khoảng 3 khoảng thời gian bị bỏ lỡ.

3.5 Khởi động Keepalived

Trên cả hai nút:

sudo systemctl enable --now keepalived
sudo systemctl status keepalived

3.6 Xác minh IP ảo

Trên node-lb01, xác nhận nó hiện sở hữu IP ảo:

ip a show eth0 | grep 192.168.0.100

ip a show eth0

Bạn sẽ thấy 192.168.0.100/24 được liệt kê là địa chỉ phụ trên nút MASTER.

Kết quả mẫu từ node-lb01:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether bc:24:11:29:90:f6 brd ff:ff:ff:ff:ff:ff
altname enp0s18
altname enxbc24112990f6
inet 192.168.0.11/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.0.100/24 scope global secondary proto 0x12 eth0
valid_lft forever preferred_lft forever
inet6 fe80::be24:11ff:fe29:90f6/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever

Trên node-lb02, lệnh tương tự sẽ không hiển thị gì. Nó ở trạng thái BACKUP.

Kết quả mẫu từ node-lb02:

Kiểm tra nhật ký Keepalived để xác nhận chuyển trạng thái:

sudo journalctl -u keepalived -n 30 --no-pager

Trên nút MASTER, bạn sẽ thấy:

[...]
Aug 09 08:52:57 node-lb01 Keepalived_vrrp[15913]: (VI_1) Entering MASTER STATE

Trên nút Backup, bạn sẽ thấy:

Aug 09 08:52:57 node-lb02 Keepalived_vrrp[15682]: (VI_1) Entering BACKUP STATE

Phần 4: Kiểm tra end-to-end

Từ bất kỳ máy khách nào trên mạng:

curl http://192.168.0.100/

Chạy vài lần và bạn sẽ thấy phản hồi xen kẽ giữa "Response from web01" và "Response from web02" nhờ cân bằng tải round-robin của HAProxy.

Kiểm tra trang stats HAProxy (từ trình duyệt hoặc qua SSH tunnel, vì nó không được phơi bày ra ngoài bởi cấu hình này):

http://192.168.0.11:8404/stats
http://192.168.0.12:8404/stats

Bạn sẽ thấy cả web01 và web02 được liệt kê là UP (màu xanh).

Trang Stats HAProxy của nút MASTER:

Phần 5: Kiểm tra chuyển đổi dự phòng

Đây là phần thực sự xác thực tuyên bố "tính sẵn sàng cao". Đừng bỏ qua nó.

5.1 Mô phỏng sự cố load balancer

Trên node-lb01 (MASTER hiện tại), dừng Keepalived:

sudo systemctl stop keepalived

Trong vài giây, đến node-lb02 và kiểm tra IP ảo:

ip a show eth0 | grep 192.168.0.100

Bây giờ nó sẽ hiển thị IP ảo. Trong khi đó, chạy một vòng lặp curl liên tục từ máy khách để xác nhận không có gián đoạn đáng kể:

while true; do curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" http://192.168.0.100/; sleep 0.5; done

Bạn sẽ thấy tối đa một hoặc hai yêu cầu thất bại/chậm trong quá trình chuyển đổi, sau đó traffic tiếp tục bình thường qua node-lb02.

Khởi động lại Keepalived trên node-lb01 để khôi phục nó làm MASTER (vì priority cao hơn, nó sẽ tự động chiếm lại IP ảo):

sudo systemctl start keepalived

Đến node-lb02 và xác minh xem nó có dùng IP ảo không. Lần này bạn sẽ không thấy IP ảo.

5.2 Mô phỏng sự cố web server

Dừng NGINX trên web01:

sudo systemctl stop nginx

Quan sát trang stats HAProxy. web01 sẽ chuyển sang DOWN trong khoảng 6 giây (3 lần kiểm tra thất bại × 2s giây), và tất cả traffic sẽ chuyển sang web02 mà không có lỗi client-visible, vì HAProxy ngừng định tuyến đến backend ngay khi nó bị đánh dấu down.

Khởi động lại NGINX và xác nhận web01 tham gia lại vòng quay:

sudo systemctl start nginx

5.3 Mô phỏng sự cố HAProxy trên nút đang hoạt động

Dừng HAProxy (không phải Keepalived) trên nút hiện là MASTER:

sudo systemctl stop haproxy

Nhờ khối track_script, Keepalived sẽ phát hiện điều này qua check_haproxy.sh và tự giáng cấp, chuyển IP ảo cho nút kia, ngay cả khi Keepalived vẫn đang chạy.

Bây giờ thử truy cập trang stats HAProxy của nút MASTER, tức là http://192.168.0.11:8404/stats. Nó sẽ không tải.

Bạn vẫn có thể truy cập trang stats HAProxy của nút BACKUP, tức là http://192.168.0.12:8404/stats và xem stats của tất cả các nút.

Đây là kịch bản mà một thiết lập Keepalived-only (không kiểm tra sức khỏe HAProxy) sẽ bỏ sót hoàn toàn, để IP ảo trỏ đến một nút có proxy chết.

Phần 6: Tăng cường bảo mật cho production

Một bản demo chuyển đổi dự phòng hoạt động không giống một hạ tầng sẵn sàng cho production. Trước khi đưa vào vận hành, hãy cân nhắc:

1. TLS termination

Hướng dẫn này sử dụng HTTP đơn giản cho rõ ràng. Trong production, hãy kết thúc TLS tại HAProxy (hoặc tại NGINX trên backend, hoặc cả hai) bằng Let's Encrypt qua certbot, và chuyển hướng cổng 80 sang 443.

2. Unicast VRRP nếu multicast không đáng tin cậy

Một số nhà cung cấp đám mây (AWS, Azure, GCP) chặn traffic multicast/broadcast, thứ mà VRRP phụ thuộc vào theo mặc định. Sử dụng các chỉ thị unicast_src_ip và unicast_peer bên trong vrrp_instance để chạy VRRP qua unicast thay thế.

3. Quy tắc tường lửa

Khóa chặt trang stats HAProxy (cổng 8404) chỉ cho các IP nội bộ, và giới hạn traffic VRRP đến giữa hai nút LB với nhau.

4. Nhiều hơn hai web server backend

Mô hình này mở rộng sạch sẽ. Thêm nhiều dòng server vào khối backend của HAProxy.

5. Giám sát và cảnh báo

Chuyển nhật ký HAProxy và Keepalived đến một hệ thống trung tâm (ví dụ: Prometheus + HAProxy exporter, hoặc một bộ tổng hợp nhật ký) và cảnh báo về các chuyển trạng thái VRRP. Một lần chuyển đổi dự phòng hoạt động đúng là tốt, nhưng bạn vẫn muốn biết nó đã xảy ra.

6. Duy trì phiên (Session persistence)

Nếu ứng dụng của bạn dựa vào phiên server-side (không phải stateless/JWT), hãy thêm cookie SRVID insert vào khối backend, hoặc chuyển trạng thái phiên đến một kho lưu trữ dùng chung như Redis để bất kỳ backend nào cũng có thể phục vụ bất kỳ yêu cầu nào.

7. Quản lý cấu hình

Sau khi xác thực thủ công, hãy chuyển cấu hình HAProxy và Keepalived vào Ansible, Terraform, hoặc công cụ cung cấp bạn chọn để cả hai nút LB luôn đồng bộ và các nút mới có thể được xây dựng tái lập.

Vì sao điều này đưa bạn đến 99.99%

Toán uptime không khoan nhượng. Như đã nói, 99.99% cho phép khoảng 52 phút và 36 giây gián đoạn mỗi năm, hoặc khoảng 4.3 phút mỗi tháng. Một load balancer đơn hoặc một web server đơn có thể dễ dàng phá vỡ ngân sách đó chỉ với một lần cập nhật kernel hỏng hoặc một lỗi phần cứng.

Kiến trúc này loại bỏ các điểm lỗi đơn lẻ ở hai lớp:

• Lớp load balancer: Chuyển đổi dự phòng VRRP của Keepalived thường hoàn tất trong 1–3 giây, và vì nó cũng theo dõi sức khỏe của chính HAProxy (không chỉ máy có lên hay không), một tiến trình proxy treo hoặc crash cũng kích hoạt chuyển đổi dự phòng.
• Lớp ứng dụng: Kiểm tra sức khỏe chủ động của HAProxy loại bỏ một web server lỗi khỏi vòng quay trong vài giây, và traffic tiếp tục được phục vụ từ (các) nút còn lại.

Những gì bộ công cụ này không tự giải quyết là lỗi cấp ứng dụng, chuyển đổi dự phòng cơ sở dữ liệu, sự cố cấp DNS, hoặc các sự cố làm cả hai nút LB chết đồng thời (ví dụ: phụ thuộc nguồn điện/mạng dùng chung).

Vì vậy, nếu 99.99% là cam kết SLA cứng, hãy đảm bảo hai load balancer và hai web server nằm trong các miền lỗi thực sự độc lập (rack riêng, vùng khả dụng, hoặc máy chủ riêng), không chỉ là các VM riêng trên cùng một hypervisor.

Tóm tắt

Bạn hiện có:

• Hai web server NGINX phục vụ nội dung và một endpoint kiểm tra sức khỏe
• Hai instance HAProxy cân bằng tải trên các web server đó với kiểm tra sức khỏe chủ động
• Hai instance Keepalived chia sẻ một IP ảo qua VRRP, với chuyển đổi dự phòng gắn với sức khỏe thực tế của HAProxy, không chỉ trạng thái sống của nút

Đây là mô hình được sử dụng nội bộ bởi vô số nền tảng SaaS production, và nó hoàn toàn mã nguồn mở, tự lưu trữ được, và cloud-agnostic. Từ đây, các bước tiếp theo tự nhiên là TLS termination, tự động hóa cấu hình, và thêm lớp giám sát để các lần chuyển đổi dự phòng hiển thị thay vì im lặng.