Đã 2 giờ sáng. Điện thoại của tôi rung liên hồi với các cảnh báo. Độ trễ DNS của cụm máy chủ chính vừa vọt từ mức ổn định 10ms lên tới 500ms đáng kinh ngạc. Người dùng đang báo cáo rằng ‘mất mạng rồi’, mặc dù các đường truyền backbone gần như trống rỗng.
Thủ phạm? Các DNS recursor của chúng tôi đang nghẹt thở dưới lưu lượng truy cập tăng gấp 10 lần. Trong những khoảnh khắc này, bạn không cần một công cụ chỉ biết nói ‘nó đang chậm’. Bạn cần một công cụ xác định chính xác điểm gãy (breaking point). Qua nhiều năm, tôi đã tin dùng dnsperf và resperf để giải quyết những bài toán này.
Bắt đầu nhanh: Chạy bài kiểm tra đầu tiên của bạn
Khi bạn đang ở giữa một sự cố, bạn không có thời gian để đọc một cuốn hướng dẫn dày 50 trang. Bạn cần biết ngay lập tức liệu máy chủ của mình có thể xử lý mức Queries Per Second (QPS) hiện tại hay không. Ban đầu được phát triển bởi Nominum và hiện được duy trì bởi DNS-OARC, dnsperf và resperf là các tiêu chuẩn công nghiệp để đo kiểm DNS.
1. Cài đặt
Việc cài đặt các công cụ này trên các bản phân phối Linux hiện đại chỉ mất một phút. Đối với người dùng Ubuntu hoặc Debian, hãy chạy:
sudo apt update
sudo apt install dnsperfIf you đang sử dụng RHEL hoặc CentOS, hãy kích hoạt kho lưu trữ EPEL trước:
sudo yum install epel-release
sudo yum install dnsperf2. Xây dựng tệp truy vấn (Query File)
Cả hai công cụ đều không tạo truy vấn ngẫu nhiên. Chúng yêu cầu một ‘datafile’—một tệp văn bản đơn giản liệt kê các tên miền và loại bản ghi (record type) bạn muốn kiểm tra. Hãy tạo một tệp tên là queries.txt:
google.com A
facebook.com A
itfromzero.com AAAA
cloudflare.com MX
linux.org AĐể có một bài kiểm tra ý nghĩa, đừng chỉ dùng năm dòng. Tôi thường trích xuất từ 50.000 đến 100.000 truy vấn duy nhất từ querylog thực tế của mình để mô phỏng hành vi người dùng thật và bỏ qua các trường hợp khớp cache đơn giản.
3. Bài đánh giá đầu tiên
Hãy kiểm tra một DNS server nội bộ ở mức 100 QPS ổn định trong 30 giây:
dnsperf -s 127.0.0.1 -p 53 -d queries.txt -l 30 -Q 100Báo cáo sẽ hiển thị số lượng truy vấn đã gửi, số lượng bị mất và độ trễ trung bình. Nếu số lượng ‘Lost queries’ bằng 0 và độ trễ dưới 20ms, máy chủ của bạn vẫn đang hoạt động nhẹ nhàng. Nếu độ trễ tăng cao trong khi QPS vẫn thấp, bạn đang gặp nút thắt cổ chai về cấu hình.
Lựa chọn công cụ: dnsperf so với resperf
Mặc dù đi cùng một gói, chúng đóng vai trò khác nhau. Chọn sai công cụ sẽ cho bạn dữ liệu sai lệch.
dnsperf: Chuyên gia đo thông lượng (Throughput)
Tôi sử dụng dnsperf chủ yếu cho các máy chủ Authoritative DNS. Nó gửi truy vấn với tốc độ cố định. Nó hoàn hảo để trả lời câu hỏi: “Máy chủ của tôi có thể xử lý 50.000 QPS với các bản ghi tĩnh không?” Nó duy trì một mức tải nhất quán để đo lường sự ổn định theo thời gian.
resperf: Công cụ tìm kiếm năng lực (Capacity Finder)
resperf (Resolution Performance) được xây dựng cho các máy chủ Caching và Recursive DNS. Khác với người anh em của mình, resperf bắt đầu với tốc độ truy vấn thấp và tăng dần lên cho đến khi máy chủ thất bại. Điều này tiết lộ ‘ngưỡng trần’ (ceiling) của bạn.
Khi tôi chuyển sang một bộ cân bằng tải phần cứng mới, tôi chạy resperf để tìm điểm mà biểu đồ phản hồi bắt đầu đi ngang. Trong một lần di chuyển gần đây, resperf cho thấy các máy ảo mới của chúng tôi có thể xử lý 12.000 QPS, nhưng độ trễ tăng gấp ba lần ở mức 13.000 QPS. Điều này cho phép chúng tôi thiết lập giới hạn tốc độ (rate limit) chính xác trước khi triển khai thực tế.
Kiểm tra chịu tải nâng cao (Stress Testing)
Môi trường production rất phức tạp. Để có dữ liệu thực sự đáng tin cậy, bạn cần đẩy các công cụ này mạnh hơn.
Tìm năng lực tối đa
Để tìm mức QPS tối đa tuyệt đối mà máy chủ có thể xử lý, hãy sử dụng tính năng tăng dần (ramp-up):
resperf -s 192.168.1.10 -d queries.txt -m 10000Cờ -m thiết lập mục tiêu QPS tối đa. resperf xuất ra một khối dữ liệu mỗi giây. Hãy tìm điểm mà “Actual QPS” ngừng tăng ngay cả khi “Target QPS” vẫn tăng. Đó chính là giới hạn của bạn.
Sử dụng đa luồng
Trên các máy chủ hiệu năng cao, như cấu hình BIND hoặc Unbound 32 nhân, bản thân công cụ đo kiểm có thể trở thành nút thắt cổ chai. Sử dụng cờ -T để phân bổ tải trên nhiều nhân CPU của máy kiểm tra:
dnsperf -s 10.0.0.5 -d queries.txt -T 4 -l 60 -Q 20000Mô phỏng các máy khách phân tán
Tường lửa thường sử dụng giới hạn tốc độ dựa trên IP nguồn. Nếu bạn chạy một bài kiểm tra khổng lồ từ một máy duy nhất, tường lửa có thể loại bỏ các gói tin, làm sai lệch kết quả. Bạn có thể vượt qua điều này bằng cách chạy công cụ từ nhiều container hoặc sử dụng cờ -x để mô phỏng các cổng nguồn (source port) khác nhau.
Cách khắc phục kết quả đánh giá xấu
Nếu các bài đánh giá cho thấy độ trễ cao hoặc mất gói tin, đừng hoảng sợ. Đây là danh sách kiểm tra của tôi để tinh chỉnh các nút DNS hiệu năng thấp.
1. Giới hạn tệp mở (Open File Limits)
Các DNS server xử lý hàng nghìn kết nối đồng thời. Nếu giới hạn của hệ điều hành quá thấp, các truy vấn sẽ biến mất. Kiểm tra giới hạn hiện tại bằng ulimit -n. Đối với các nút production, tôi luôn đặt mức này ít nhất là 65.535 trong /etc/security/limits.conf.
2. Kích thước bộ nhớ và Cache
Nếu resperf cho thấy độ trễ cao đối với các truy vấn đệ quy (recursive) nhưng phản hồi nhanh cho các truy vấn lặp lại, thì cache của bạn quá nhỏ. Với BIND, hãy kiểm tra max-cache-size. Với Unbound, hãy xem rrset-cache-size. Tăng các giá trị này đảm bảo máy chủ trả lời từ RAM thay vì phải chờ đợi các root server ở phía trên.
3. Đa luồng và CPU Pinning
Theo dõi mức sử dụng CPU trong khi chạy dnsperf. Nếu một nhân bị chiếm 100% trong khi các nhân khác rảnh rỗi, phần mềm của bạn đang không đa luồng đúng cách. Trong Unbound, bạn phải đặt num-threads rõ ràng để khớp với số nhân của mình. Trong BIND, hãy đảm bảo bạn sử dụng cờ -n cho số lượng luồng làm việc (worker threads).
4. Tinh chỉnh UDP Stack
Thông thường, nút thắt cổ chai nằm ở nhân Linux. Tôi thường xuyên tăng bộ đệm nhận UDP để ngăn chặn việc mất gói tin trong các đợt lưu lượng tăng đột biến:
# Thiết lập bộ đệm UDP tối đa thành 16MB
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216Tổng kết
Đánh giá hiệu năng không phải là để chạy theo những con số lớn nhất. Đó là về khả năng dự đoán. Bằng cách sử dụng dnsperf cho các bài kiểm tra cơ sở (baseline) và resperf để tìm điểm gãy, bạn có thể ngủ ngon hơn khi biết chính xác hạ tầng của mình có thể chịu đựng được bao nhiêu lưu lượng. Tôi biến các bài kiểm tra này thành một bước kiểm duyệt bắt buộc trong quy trình CI/CD của mình. Đừng đợi đến khi xảy ra sự cố lúc 2 giờ sáng mới phát hiện ra máy chủ của bạn đạt ngưỡng tối đa ở mức 5.000 QPS—hãy kiểm tra nó ngay hôm nay.
