Giải bài toán độ trễ với Anycast
Các dịch vụ có lưu lượng truy cập cao như DNS hoặc các ứng dụng phân phối toàn cầu cuối cùng đều chạm tới một giới hạn vật lý khắc nghiệt: tốc độ ánh sáng. Dù bạn có tối ưu hóa cơ sở dữ liệu đến đâu, một người dùng ở Singapore sẽ gặp độ trễ ít nhất 200–250ms khi kết nối tới máy chủ tại New York. Định tuyến Unicast tiêu chuẩn gửi lưu lượng đến một đích cụ thể. Các bộ cân bằng tải (Load balancer) có giúp ích, nhưng chúng thường bị giới hạn trong một trung tâm dữ liệu hoặc khu vực duy nhất.
Anycast thay đổi hoàn toàn cuộc chơi. Bằng cách quảng bá cùng một địa chỉ IP từ nhiều vị trí địa lý khác nhau thông qua BGP (Border Gateway Protocol), hạ tầng cốt lõi của internet sẽ tự động điều hướng người dùng đến nút (node) hoạt động ổn định “gần nhất”.
Tôi đã triển khai kiến trúc này trong môi trường production để xử lý các đợt tăng vọt lưu lượng theo vùng mà trước đây từng gây quá tải cho các điểm truy cập đơn vùng của chúng tôi. Khi một nút gặp sự cố, BGP sẽ rút lại (withdraw) tuyến đường chỉ trong vài giây, và lưu lượng sẽ chuyển hướng liền mạch sang vị trí tốt nhất tiếp theo. Đây là một thiết kế có khả năng tự phục hồi (self-healing).
Chúng ta sẽ thiết lập một Anycast IP trên Linux bằng FRRouting (FRR). Trong kịch bản này, hai máy chủ sẽ dùng chung một IP để cung cấp dịch vụ có độ sẵn sàng cao (high-availability), phản ứng nhanh hơn bất kỳ cơ chế failover dựa trên DNS truyền thống nào.
Kiến trúc tối ưu khoảng cách
Trước khi bắt tay vào cấu hình, hãy cùng xem qua sơ đồ thiết kế. Trong một thiết lập tiêu chuẩn, mỗi máy chủ có một IP duy nhất. Với Anycast, chúng ta gán một “Anycast IP” dùng chung cho một interface ảo (dummy interface) trên mọi nút. Sau đó, mỗi máy chủ sẽ thông báo với router upstream rằng nó là chủ sở hữu hợp lệ của IP đó.
Tại sao nên chọn giải pháp này thay vì Global Server Load Balancer (GSLB)?
- Failover dưới một giây: Sự hội tụ BGP thường nhanh hơn việc cập nhật TTL của DNS, vốn có thể mất vài phút để phổ biến trên toàn cầu.
- Một IP duy nhất: Khách hàng của bạn chỉ cần thêm vào whitelist hoặc cấu hình một đích đến duy nhất.
- Hấp thụ DDoS tự nhiên: Lưu lượng tấn công được phân tán trên toàn bộ hạ tầng toàn cầu thay vì tập trung vào một đường truyền duy nhất.
Anycast là tiêu chuẩn vàng cho các dịch vụ dựa trên UDP như DNS. Nó cũng hoạt động tốt với TCP (HTTP/HTTPS), miễn là định tuyến BGP của bạn ổn định. Nếu các tuyến đường bị “chập chờn” (flap) thường xuyên, các phiên TCP sẽ bị ngắt vì các gói tin của cùng một phiên có thể kết thúc ở các máy chủ khác nhau.
Cài đặt: Thiết lập FRRouting
Đối với BGP trên Linux, FRRouting (FRR) là tiêu chuẩn của ngành. Đây là một nhánh (fork) hiệu suất cao của Quagga với giao diện dòng lệnh (CLI) tạo cảm giác quen thuộc cho bất kỳ ai từng sử dụng thiết bị Cisco hoặc Juniper gear. Ví dụ này sử dụng Ubuntu 22.04, nhưng logic này có thể áp dụng cho bất kỳ bản phân phối hiện đại nào.
Cài đặt kho lưu trữ và gói FRR:
# Thêm khóa GPG và kho lưu trữ của FRR
curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -
FRRVER="frr-stable"
echo deb https://deb.frrouting.org/frr $(lsb_release -s -c) $FRRVER | sudo tee /etc/apt/sources.list.d/frr.list
# Cập nhật và cài đặt
sudo apt update
sudo apt install frr frr-pythontoolsFRR chạy một hệ thống daemon dạng module. Chúng ta cần kích hoạt daemon BGP một cách thủ công.
# Kích hoạt daemon BGP
sudo sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo systemctl restart frrCấu hình: Để BGP phục vụ bạn
Việc cấu hình trải dài trên hai lớp: stack mạng của Linux và engine định tuyến FRR.
1. Interface ảo (Dummy Interface)
Chúng ta cần một interface ảo để giữ Anycast IP. Chúng ta tránh sử dụng interface vật lý (như eth0) vì muốn có khả năng “ẩn” Anycast IP nếu dịch vụ cục bộ bị lỗi mà không làm ngắt kết nối quản trị của máy chủ.
# Tạo một interface ảo tên là 'anycast0'
sudo ip link add anycast0 type dummy
sudo ip link set anycast0 up
# Gán Anycast IP của bạn (ví dụ: 192.0.2.100)
sudo ip addr add 192.0.2.100/32 dev anycast02. Thiết lập BGP Peering qua vtysh
Bây giờ chúng ta sẽ yêu cầu FRR quảng bá IP này ra thế giới. Chúng ta sử dụng vtysh, shell tích hợp của FRR. Bạn sẽ cần số hiệu mạng (ASN) và IP của thiết bị upstream (peer).
sudo vtysh
configure terminal
# Thay 65001 bằng ASN của bạn
router bgp 65001
bgp router-id 1.1.1.1
# Neighbor upstream của bạn (ví dụ: ISP hoặc switch ToR)
neighbor 203.0.113.1 remote-as 65000
neighbor 203.0.113.1 description Ket_Noi_Upstream
address-family ipv4 unicast
# Quảng bá Anycast IP cụ thể
network 192.0.2.100/32
neighbor 203.0.113.1 activate
exit-address-family
exit
write memory3. Tránh hiện tượng “Black Hole”
Đây là một bài học mà tôi đã rút ra được một cách khó khăn: nếu dịch vụ Nginx hoặc BIND của bạn bị sập nhưng máy chủ vẫn hoạt động, BGP vẫn sẽ tiếp tục thông báo cho thế giới gửi lưu lượng đến đó. Điều này tạo ra một “hố đen” (black hole). Bạn phải liên kết việc quảng bá BGP với trạng thái sức khỏe của dịch vụ.
Một đoạn mã bash script đơn giản có thể giám sát ứng dụng của bạn và hạ interface anycast0 xuống nếu lệnh curl -s localhost thất bại. Khi interface đã hạ, FRR sẽ ngừng quảng bá tuyến đường, và internet sẽ tự động chuyển hướng lưu lượng đến các nút khác của bạn trong vòng vài giây.
Xác minh: Chứng minh hiệu quả
Kiểm tra việc quảng bá tuyến đường từ bên trong vtysh:
show ip bgp summary
show ip bgp 192.0.2.100/32Mã trạng thái *> là những gì bạn muốn thấy—nó xác nhận một tuyến đường hợp lệ và là đường đi tốt nhất. Nhưng đừng chỉ tin vào kết quả cục bộ. Để xác minh hành vi Anycast thực sự, hãy sử dụng một công cụ như RIPE Atlas hoặc mtr từ các vị trí VPS khác nhau trên toàn cầu.
# Chạy lệnh này từ một máy khách từ xa
mtr -rw 192.0.2.100Nếu bạn thấy hop cuối cùng đến Máy chủ A từ London và Máy chủ B từ Tokyo, thiết lập của bạn đã hoạt động. Việc giám sát các phiên BGP này qua Prometheus with frr_exporter là điều bắt buộc để đảm bảo sự ổn định trong môi trường production. Anycast từng là công cụ dành cho những gã khổng lồ, nhưng với Linux hiện đại, bất kỳ đội ngũ nào có ASN đều có thể xây dựng một mạng lưới toàn cầu và bền bỉ.
