Squid Proxy HA: Hướng dẫn cấu hình Keepalived (Tự động Failover)

Nếu bạn đang vận hành một máy chủ Squid Proxy duy nhất cho toàn bộ doanh nghiệp, bạn đang ngồi trên một “quả bom nổ chậm”. Hệ thống đó tồn tại một rủi ro chí mạng: Single Point of Failure (SPOF) – hay còn gọi là Điểm lỗi duy nhất.

Chỉ cần máy chủ Squid này gặp sự cố (lỗi phần cứng, treo dịch vụ, update lỗi, hoặc đơn giản là bảo trì…), toàn bộ công ty của bạn sẽ lập tức mất kết nối Internet. Hậu quả là mọi hoạt động kinh doanh bị đình trệ, và đội ngũ IT phải nhận hàng loạt cuộc gọi phàn nàn.

Giải pháp cho vấn đề này là xây dựng một hệ thống Squid Proxy HA (High Availability – Tính sẵn sàng cao).

Bài viết này sẽ hướng dẫn bạn từng bước, một cách chi tiết và thực tế nhất, cách sử dụng Keepalived để thiết lập một cụm Squid Proxy HA. Mục tiêu là tạo ra một hệ thống proxy có khả năng tự động chuyển đổi (failover) sang máy chủ dự phòng trong vòng vài giây khi có sự cố, đảm bảo kết nối Internet của người dùng cuối luôn thông suốt.

Proxy Server Illustration

Tóm tắt giải pháp Keepalived cho Squid HA:

  • Loại bỏ SPOF: Chuyển từ một điểm lỗi duy nhất sang hệ thống sẵn sàng cao.
  • Tự động Failover: Chuyển đổi sang máy chủ dự phòng trong vài giây.
  • Sử dụng VRRP: Quản lý Địa chỉ IP Ảo (VIP) cho người dùng cuối.
  • Theo dõi Dịch vụ (Process Check): Đảm bảo dịch vụ squid đang chạy, không chỉ riêng OS.

Tại sao doanh nghiệp cần Squid Proxy HA?

Một máy chủ Squid đơn lẻ là một SPOF. Điều này có nghĩa là bất kỳ sự cố nào xảy ra với máy chủ đó đều có thể làm tê liệt hoàn toàn khả năng truy cập web của tổ chức.

Những rủi ro thực tế khi chạy một máy chủ proxy duy nhất:

  • Lỗi phần cứng: Ổ cứng hỏng, lỗi RAM, lỗi card mạng (NIC), hoặc sập nguồn đột ngột đều khiến proxy ngừng hoạt động.
  • Lỗi dịch vụ: Đây là trường hợp phổ biến nhất. Máy chủ Linux vẫn chạy, nhưng dịch vụ (process) squid bị treo, “chết” hoặc không phản hồi do cạn kiệt tài nguyên (RAM, CPU).
  • Bảo trì bắt buộc: Khi bạn cần nâng cấp hệ điều hành, vá lỗi bảo mật, hoặc cập nhật file squid.conf, bạn buộc phải khởi động lại dịch vụ, tạo ra “thời gian chết” (downtime) dù là ngắn.
  • Sự cố mạng: Lỗi cáp mạng hoặc lỗi cổng switch kết nối đến máy chủ proxy cũng sẽ cô lập nó khỏi hệ thống.

Một hệ thống Squid Proxy HA giải quyết tất cả các vấn đề này. Bằng cách sử dụng hai (hoặc nhiều) máy chủ chạy song song và một địa chỉ IP “nổi”, hệ thống có thể tự động phát hiện lỗi và chuyển hướng lưu lượng truy cập sang máy chủ dự phòng ngay lập tức. Điều này mang lại độ tin cậy cấp doanh nghiệp, đảm bảo kinh doanh liên tục và giảm tải áp lực cho đội ngũ quản trị hệ thống.

Mô hình kiến trúc và chuẩn bị

Mutual Assistance Abstract Concept Vector Illustration

Trước khi đi vào các dòng lệnh, chúng ta cần thống nhất về mô hình. Phương pháp phổ biến, đơn giản và hiệu quả nhất là mô hình Active-Passive (Chủ động-Dự phòng) sử dụng một địa chỉ IP “ảo”.

  • Virtual IP (VIP): Đây là địa chỉ IP duy nhất mà tất cả máy trạm (client) trong công ty sẽ trỏ proxy tới (ví dụ: 192.168.1.100). Địa chỉ này không được gán “cứng” cho bất kỳ máy nào.
  • Node MASTER: Là máy chủ Squid đang hoạt động (proxy-01), nó sẽ “nắm giữ” và phản hồi cho địa chỉ VIP này.
  • Node BACKUP: Là máy chủ Squid dự phòng (proxy-02), luôn ở trạng thái sẵn sàng. Nó liên tục “theo dõi” sức khỏe của Node MASTER.
  • Kịch bản Failover: Khi Node MASTER gặp sự cố, Node BACKUP sẽ phát hiện ra (thông qua giao thức VRRP), tự động “cướp” lấy VIP và tự biến mình thành MASTER mới. Quá trình này diễn ra tự động, người dùng cuối gần như không cảm nhận được sự gián đoạn.

Bảng điều kiện chuẩn bị

Để thực hiện hướng dẫn này, hãy đảm bảo bạn đã chuẩn bị sẵn môi trường sau:

Thành phần Thông tin ví dụ Ghi chú quan trọng
Node 1 (MASTER) proxy-01 (IP: 192.168.1.10) Đã cài đặt Linux (Ubuntu/CentOS)
Node 2 (BACKUP) proxy-02 (IP: 192.168.1.11) Đã cài đặt Linux (Ubuntu/CentOS)
Virtual IP (VIP) 192.168.1.100 Một IP chưa sử dụng trong mạng của bạn
Squid Proxy Đã cài đặt trên cả 2 node BẮT BUỘC: File squid.conf trên 2 node phải giống hệt nhau. (Nếu chưa cài, xem hướng dẫn setup Squid Server cơ bản).

Vấn đề quan trọng: Đồng bộ cấu hình

Bạn phải luôn ghi nhớ: Keepalived chỉ xử lý việc chuyển đổi IP (failover). Nó không xử lý việc đồng bộ cấu hình.

Nếu bạn thay đổi một quy tắc (rule) trong /etc/squid/squid.conf trên proxy-01, bạn phải tự đồng bộ thay đổi đó sang proxy-02. Nếu bạn quên, khi failover xảy ra, proxy-02 sẽ chạy với cấu hình cũ, gây ra lỗi logic hoặc bảo mật.

Bạn có thể dùng các công cụ như rsync, lsyncd hoặc các hệ thống quản lý cấu hình như Ansible, Puppet để tự động hóa việc này.

Vấn đề về xác thực

Bài viết này tập trung vào tính sẵn sàng (HA). Nếu hệ thống proxy của bạn yêu cầu xác thực người dùng tập trung, hãy đảm bảo bạn cấu hình đồng bộ trên cả hai node.

Nếu bạn sử dụng Kerberos, cả hai node Squid HA đều phải được join domain và sử dụng chung một file squid.keytab (được tạo cho cùng một Service Principal Name – SPN).

Cài đặt Keepalived

Bước đầu tiên là cài đặt Keepalived trên cả hai máy chủ proxy-01proxy-02. Keepalived là công cụ “trái tim” sử dụng giao thức VRRP (Virtual Router Redundancy Protocol) để giao tiếp và quyết định ai là MASTER.

Trên Ubuntu / Debian:

sudo apt update
sudo apt install keepalived -y

Trên CentOS / RHEL / AlmaLinux:

sudo yum install keepalived -y

Sau khi cài đặt, dịch vụ sẽ có sẵn nhưng chưa được cấu hình. Chúng ta sẽ thực hiện việc đó ở bước tiếp theo.

Cấu hình chi tiết Squid Keepalived

Business Process Automation BPA Concept Vector Illustration

Toàn bộ “phép thuật” nằm trong file cấu hình /etc/keepalived/keepalived.conf. Chúng ta sẽ cấu hình 3 thành phần chính một cách cẩn thận:

  1. Theo dõi Process: Làm sao Keepalived biết dịch vụ Squid còn “sống” hay đã “chết”?
  2. Notify Scripts: Hành động gì khi một node trở thành MASTER hoặc BACKUP?
  3. Cấu hình Node: Định nghĩa proxy-01 là MASTER và proxy-02 là BACKUP.

Theo dõi dịch vụ Squid (Phần quan trọng nhất)

Đây là phần giá trị nhất của một cấu hình HA chuyên nghiệp. Nếu bạn chỉ cấu hình Keepalived để kiểm tra xem máy chủ có chạy không (ví dụ: ping), bạn sẽ gặp rắc rối lớn.

Tại sao? Vì kịch bản phổ biến nhất là: Máy chủ proxy-01 vẫn chạy bình thường, nhưng dịch vụ squid bị treo, không chấp nhận kết nối.

Lúc này, Keepalived vẫn nghĩ proxy-01 ổn và vẫn giữ VIP. Kết quả: Toàn bộ công ty mất mạng.

Thay vì dùng vrrp_script (phải chạy lệnh kiểm tra liên tục – polling), chúng ta sẽ dùng một cơ chế hiệu quả hơn, được tích hợp sẵn: vrrp_track_process.

vrrp_track_process sử dụng “process events kernel connector” của Linux. Nó không cần polling, mà sẽ được Kernel thông báo ngay lập tức khi một process mà nó theo dõi bị “chết”.

Hãy mở file /etc/keepalived/keepalived.conf trên cả hai Node và thêm đoạn sau vào đầu file:

# --- THEO DOI PROCESS SQUID (NHANH, HIEU QUA) ---
vrrp_track_process squid_process {
    # Ten process can theo doi
    process "squid"
    
    # Kiem tra process co phai cua user "proxy" (Ubuntu) hoac "squid" (CentOS)
    # Neu khong chac chan, ban co the bo qua dong nay
    # user proxy
    
    # Neu process "squid" khong tim thay (bi chet)
    # Ha 20 diem priority
    weight -20 
    
    # (Tuy chon) Yeu cau 2 lan kiem tra loi moi ha diem
    fall 2 
    # (Tuy chon) Yeu cau 3 lan kiem tra dung moi tang diem
    rise 3
}

Lưu ý: Tên process thường là “squid”. Bạn có thể kiểm tra chính xác bằng lệnh ps -C squid -o comm=.

Script thông báo (Notify Scripts) – Nâng cao

Đây là một kỹ thuật nâng cao nhưng rất hữu ích. Chúng ta muốn rằng:

  • Khi một node trở thành MASTER, nó phải chắc chắn rằng dịch vụ Squid đang chạy.
  • Khi một node trở thành BACKUP, nó nên dừng dịch vụ Squid để tiết kiệm tài nguyên (tùy chọn).

Hãy tạo các script này trên cả hai Node:

  1. Tạo thư mục scripts:
    sudo mkdir -p /etc/keepalived/scripts
  2. Tạo script become_master.sh:
    sudo nano /etc/keepalived/scripts/become_master.sh

    Thêm nội dung:

    #!/bin/bash
    # Dam bao Squid dang chay khi tro thanh MASTER
    systemctl start squid
    echo "$(date): Tro thanh MASTER, da chay Squid" >> /var/log/keepalived_state.log
  3. Tạo script become_backup.sh:
    sudo nano /etc/keepalived/scripts/become_backup.sh

    Thêm nội dung:

    #!/bin/bash
    # (Tuy chon) Dung Squid khi tro thanh BACKUP
    # systemctl stop squid
    echo "$(date): Tro thanh BACKUP" >> /var/log/keepalived_state.log
  4. Cấp quyền thực thi:
    sudo chmod +x /etc/keepalived/scripts/*.sh

Chúng ta sẽ gọi các script này trong file cấu hình chính ngay sau đây.

Cấu hình Node MASTER (proxy-01)

Bây giờ, trên máy chủ proxy-01, hãy thay thế toàn bộ nội dung file /etc/keepalived/keepalived.conf bằng đoạn cấu hình sau:

# Day la file config tren NODE MASTER (proxy-01)

# Dinh nghia global
global_defs {
   # Dinh danh duy nhat cho node nay, ten gi cung duoc
   router_id proxy-01
   
   # Cho phep cac script VRRP duoc chay voi quyen root
   enable_script_security
}

# Khoi theo doi process (da dinh nghia o tren)
vrrp_track_process squid_process {
    process "squid"
    weight -20 
    fall 2
    rise 3
}

# Khoi cau hinh VRRP chinh
vrrp_instance VI_1 {
    # Khai bao day la may chu MASTER
    state MASTER
    
    # Ten card mang se giu VIP (vd: eth0, ens192)
    interface eth0 
    
    # ID phai giong het nhau tren ca 2 node
    # Day la cach chinh de phan biet cac cum HA, phai duy nhat
    virtual_router_id 51 
    
    # MASTER phai co priority cao hon BACKUP
    priority 101 
    
    # Thoi gian quang ba goi tin (1 giay)
    advert_int 1

    # Danh sach IP Ao (VIP)
    virtual_ipaddress {
        192.168.1.100/24 # Thay bang VIP cua ban
    }

    # THEO DOI PROCESS SQUID
    track_process {
        squid_process
    }

    # GOI NOTIFY SCRIPTS
    notify_master "/etc/keepalived/scripts/become_master.sh"
    notify_backup "/etc/keepalived/scripts/become_backup.sh"
    notify_fault "/etc/keepalived/scripts/become_master.sh" # Chay lai Squid neu co loi
}

Giải thích các điểm chính:

  • state MASTER: Khai báo đây là máy chủ chính.
  • interface eth0: Tên card mạng của bạn (dùng lệnh ip a để xem).
  • virtual_router_id 51: Đây là “tên” của cụm HA này. Cả MASTER và BACKUP phải có ID giống hệt nhau. Đây là yếu tố then chốt để phân biệt các cụm HA trên cùng một mạng.
  • priority 101: Điểm ưu tiên. Con số này phải cao hơn Node BACKUP.
  • track_process { squid_process }: Đây là mấu chốt! Nó liên kết khối VRRP này với trình theo dõi squid_process. Nếu squid “chết”, priority 101 sẽ bị trừ 20, còn 81. Vì 81 < 100 (của BACKUP) nên Node BACKUP sẽ giành quyền MASTER.
  • notify_master: Gọi script khi node này trở thành MASTER.

Cấu hình Node BACKUP (proxy-02)

Tiếp theo, trên máy chủ proxy-02, hãy thay thế toàn bộ nội dung file /etc/keepalived/keepalived.conf bằng cấu hình sau. Nó gần như tương tự, chỉ khác 3 điểm.

# Day la file config tren NODE BACKUP (proxy-02)

global_defs {
   # Khac biet 1: router_id phai khac
   router_id proxy-02
   enable_script_security
}

# Khoi theo doi process (phai giong het MASTER)
vrrp_track_process squid_process {
    process "squid"
    weight -20 
    fall 2
    rise 3
}

# Khoi cau hinh VRRP chinh
vrrp_instance VI_1 {
    # Khac biet 2: Khai bao day la may chu BACKUP
    state BACKUP 
    
    interface eth0 
    virtual_router_id 51 # Phai giong MASTER
    
    # Khac biet 3: Priority thap hon MASTER
    priority 100 
    
    advert_int 1

    virtual_ipaddress {
        192.168.1.100/24 
    }

    track_process {
        squid_process
    }
    
    notify_master "/etc/keepalived/scripts/become_master.sh"
    notify_backup "/etc/keepalived/scripts/become_backup.sh"
    notify_fault "/etc/keepalived/scripts/become_master.sh"
}

Ba điểm khác biệt duy nhất là:

  • router_id proxy-02
  • state BACKUP
  • priority 100 (Thấp hơn 101 của MASTER)

Cấu hình Firewall (Bắt buộc)

Bạn cấu hình mọi thứ đúng, nhưng nó sẽ không chạy. Tại sao? Vì Firewall đang chặn.

Keepalived (VRRP) không dùng TCP hay UDP. Nó là một giao thức IP (protocol) riêng biệt. Tên của nó là vrrp hoặc protocol số 112. Bạn phải cho phép nó trên cả hai Node.

Trên CentOS / RHEL (sử dụng firewalld):

# Cho phep giao thuc VRRP vinh vien
sudo firewall-cmd --add-protocol=vrrp --permanent

# (Tuy chon) VRRP cung dung multicast, mo dia chi multicast
sudo firewall-cmd --add-rich-rule='rule family="ipv4" destination address="224.0.0.18" accept' --permanent

# Reload firewall
sudo firewall-cmd --reload

Trên Ubuntu (sử dụng UFW):

UFW hơi “phiền” hơn vì nó không nhận diện tên vrrp dễ dàng. Cách an toàn nhất là cho phép protocol 112.

# Mo file cau hinh rule "truoc"
sudo nano /etc/ufw/before.rules

# Them 2 dong sau vao TRUOC khoi *filter (thuong la o tren cung)
-A ufw-before-input -p vrrp -j ACCEPT
-A ufw-before-output -p vrrp -j ACCEPT

# (Luu file va thoat)

# Reload UFW
sudo ufw reload

Việc cấu hình UFW đúng cách là tối quan trọng, vì nó là tuyến phòng thủ đầu tiên. Để tìm hiểu sâu hơn về cách bảo vệ máy chủ của bạn một cách toàn diện, hãy tham khảo hướng dẫn đầy đủ về Bảo mật VPS Linux với UFW, Fail2Ban và Hardening SSH.

Khởi động dịch vụ: Sau khi cấu hình và mở firewall, hãy khởi động và kích hoạt Keepalived trên cả hai Node:

sudo systemctl enable keepalived
sudo systemctl start keepalived

# Kiem tra trang thai
sudo systemctl status keepalived

Kiểm thử Failover (Sự thật được phơi bày)

Đã đến lúc kiểm tra thành quả.

Kiểm tra trạng thái ban đầu

Trên Node MASTER (proxy-01), chạy lệnh ip a:

$ ip a show eth0
...
    inet 192.168.1.10/24 ...
    inet 192.168.1.100/24 brd 192.168.1.255 scope global secondary eth0  <-- VIP đã xuất hiện!
...

Trên Node BACKUP (proxy-02), chạy lệnh ip a: Bạn sẽ không thấy IP 192.168.1.100.

Tuyệt vời! Hệ thống đang ở trạng thái bình thường. Giờ hãy cấu hình một máy trạm trỏ proxy về VIP 192.168.1.100 (port 3128) và thử truy cập web. Bạn phải truy cập thành công.

Kịch bản 1 – Dịch vụ Squid “chết”

Đây là kịch bản mà vrrp_track_process của chúng ta phát huy tác dụng. Nguyên nhân phổ biến khiến dịch vụ ‘chết’ trong khi OS vẫn chạy là do cạn kiệt tài nguyên. Bạn có thể tham khảo cách chẩn đoán tại VPS Linux CPU 100%: Hướng dẫn chẩn đoán và xử lý triệt để nguyên nhân gốc rễ.

Trên Node MASTER (proxy-01), hãy giả lập lỗi dịch vụ Squid:

# Dung dich vu Squid tren MASTER
sudo systemctl stop squid

Chờ khoảng 5-10 giây… (thời gian fall 2 x interval 2 + chuyển đổi)

Bây giờ, kiểm tra trên Node BACKUP (proxy-02):

$ ip a show eth0
...
    inet 192.168.1.11/24 ...
    inet 192.168.1.100/24 brd 192.168.1.255 scope global secondary eth0  <-- VIP đã tự động nhảy sang!
...

Trên máy trạm của bạn, hãy thử F5 trang web. Bạn sẽ thấy kết nối vẫn thông suốt (có thể bị delay 1-2 giây lúc chuyển đổi).

Kịch bản 2 – Máy chủ MASTER “sập”

Đây là kịch bản lỗi phần cứng hoặc sập OS. Trên Node MASTER (proxy-01), hãy khởi động lại dịch vụ Squid (sudo systemctl start squid) để nó giành lại VIP (quá trình này gọi là Failback).

Sau khi VIP đã quay về proxy-01, hãy giả lập sập nguồn bằng cách tắt dịch vụ Keepalived (hoặc shutdown máy):

# Tat Keepalived tren MASTER
sudo systemctl stop keepalived

Ngay lập tức (khoảng 1-3 giây), VIP sẽ được chuyển sang proxy-02. Kết nối của người dùng vẫn được đảm bảo.

Troubleshooting và tinh chỉnh nâng cao

Computer Troubleshooting Abstract Concept Vector Illustration

Không phải lúc nào mọi thứ cũng suôn sẻ. Dưới đây là các vấn đề bạn có thể gặp và các kỹ thuật để làm chủ hệ thống HA của mình.

Troubleshooting: “VIP không nhảy”

  • Triệu chứng: VIP không xuất hiện trên MASTER, hoặc không nhảy sang BACKUP khi MASTER sập.
  • Nguyên nhân 1 (90%): Do Firewall.
    • Giải pháp 1: Kiểm tra lại Bước 5.
  • Nguyên nhân 2 (10%): Lỗi cấu hình.
    • Giải pháp 2 (Dùng tcpdump): Chạy lệnh sau trên cả hai Node để xem chúng có “nói chuyện” (gửi gói tin VRRP) không.
      sudo tcpdump -n -i eth0 vrrp

      Nếu bạn thấy các dòng output (ví dụ: ... 192.168.1.10 > 224.0.0.18: VRRPv2, ...), nghĩa là chúng đang giao tiếp. Nếu tcpdump cho thấy kết nối VRRP vẫn chạy, nhưng client vẫn báo lỗi Connection Refused hoặc Timeout, vấn đề có thể không nằm ở Keepalived mà ở chính Squid. Hãy tham khảo hướng dẫn Phân tích & sửa lỗi kết nối Proxy: Hướng dẫn debug “Connection Refused” & “Timeout” để chẩn đoán sâu hơn.

Vấn đề “Split-Brain”

  • Triệu chứng: Cả hai Node (proxy-01proxy-02) đều nghĩ mình là MASTER và cùng “nắm giữ” VIP 192.168.1.100.
  • Nguyên nhân: Thường là do 2 node mất kết nối mạng (cùng chạy VRRP) với nhau, nhưng cả 2 vẫn kết nối được với switch tổng.
  • Giải pháp: Đây là vấn đề về thiết kế mạng. Cách phòng tránh tốt nhất là đảm bảo virtual_router_id (ví dụ: 51) là duy nhất cho cụm HA này trên toàn bộ mạng (VLAN) của bạn. Nếu bạn có 2 cụm HA cùng chạy virtual_router_id 51 trên cùng một VLAN, chúng sẽ xung đột.

Tinh chỉnh nopreempt (Ngăn Master tự động giành quyền)

  • Vấn đề: Theo cấu hình hiện tại, proxy-01 (priority 101) luôn giành lại quyền MASTER ngay khi nó khởi động (gọi là preemption). Điều này có thể gây phiền toái nếu bạn đang bảo trì proxy-01 và muốn nó khởi động lại nhưng vẫn ở chế độ BACKUP để kiểm tra, tránh “flapping” (chuyển đổi liên tục).
  • Giải pháp: Thêm nopreempt vào cấu hình.
  • Cách làm: Trong file keepalived.conf của Node MASTER (proxy-01), trong khối vrrp_instance VI_1, hãy thêm dòng nopreempt và đổi state mặc định thành BACKUP.
    vrrp_instance VI_1 {
        # Khai bao la BACKUP de no khong tu dong gianh quyen khi moi khoi dong
        state BACKUP
    
        # Them dong nay de no KHONG gianh quyen cua node co priority thap hon
        nopreempt
    
        interface eth0 
        virtual_router_id 51 
        priority 101 # Van giu priority cao
        ...
    }

    Với cấu hình này, proxy-01 vẫn có priority cao nhất, nhưng khi khởi động, nó sẽ ở trạng thái BACKUP và sẽ chỉ trở thành MASTER khi và chỉ khi proxy-02 (100) bị lỗi.

Đề cập đến BFD (Phát hiện lỗi nhanh hơn)

  • Khái niệm: Cấu hình của chúng ta (vrrp_track_process) theo dõi dịch vụ Squid. Nhưng nếu dịch vụ Squid vẫn chạy, mà kết nối mạng (ví dụ: cáp tới router) bị đứt thì sao?
  • Giải pháp nâng cao: Keepalived hỗ trợ BFD (Bidirectional Forwarding Detection). Đây là một giao thức phát hiện lỗi mạng ở tốc độ rất nhanh (mili-giây).
  • Ứng dụng: Bạn có thể cấu hình bfd_instance trong Keepalived để theo dõi kết nối đến gateway (router). Sau đó, bạn dùng track_bfd trong vrrp_instance (tương tự track_process). Nếu kết nối BFD “chết”, nó cũng sẽ trừ điểm priority và kích hoạt failover. Đây là kỹ thuật dùng cho các hệ thống yêu cầu độ trễ failover cực thấp.

Kết luận

Chúc mừng! Bạn vừa hoàn thành việc xây dựng một hệ thống Squid Proxy HA thực thụ.

Bằng cách loại bỏ “Điểm lỗi duy nhất” (SPOF), bạn đã biến hệ thống proxy của mình từ một rủi ro tiềm tàng thành một dịch vụ cấp doanh nghiệp, có độ tin cậy cao. Với Keepalived, Virtual IP, và cơ chế theo dõi process hiệu quả, hệ thống của bạn giờ đây có thể tự động “chữa lành” khi một node gặp sự cố, đảm bảo người dùng luôn có kết nối Internet ổn định.

Đây là một kỹ năng quản trị hệ thống quan trọng, giúp tăng cường độ tin cậy cho bất kỳ dịch vụ mạng thiết yếu nào, không chỉ riêng Squid.

Tài liệu tham khảo

Chia sẻ bài viết:

Đánh giá

0/5 - (0 Bình chọn)

Chưa có đánh giá.