Các giải pháp đồng bộ thời gian: Chrony vs. NTPd vs. systemd-timesyncd
Hiện tượng lệch đồng hồ hệ thống (clock drift) nếu không được kiểm soát có thể tàn phá hạ tầng phân tán nghiêm trọng. Khoảng lệch chỉ vỏn vẹn 200 mili-giây cũng đủ phá vỡ cơ chế đồng thuận Raft trong các cụm etcd, vô hiệu hóa các JSON Web Token (JWT) có thời hạn ngắn, và làm sai lệch dữ liệu distributed tracing trong Jaeger. Khi chọn một time daemon cho Linux, bạn thường có ba hướng tiếp cận:
- systemd-timesyncd: Client SNTP tối giản được tích hợp sẵn trực tiếp vào systemd. Tiến trình này chỉ lấy thời gian từ các nguồn từ xa và định kỳ điều chỉnh đồng hồ cục bộ. Nó không thể đóng vai trò là một time server nội bộ.
- NTPd truyền thống: Daemon tham chiếu kỳ cựu từng vận hành các hệ thống UNIX thuở ban đầu. Dù đã qua thử thách thực tế nhiều năm và giàu tính năng, nó phải mất hàng giờ mới ổn định sau khi khởi động. Nó cũng hoạt động kém hiệu quả khi độ trễ mạng tăng đột biến trên các đường truyền đám mây bị nghẽn.
- Chrony (chronyd): Engine NTP hiện đại, hiệu năng cao được xây dựng chuyên biệt cho máy ảo, máy chủ đám mây và thiết bị edge. Chrony thích ứng rất nhanh khi các thao tác snapshot máy ảo tạm dừng thực thi, card mạng bị rớt kết nối hoặc tần số xung nhịp đồng hồ dao động.
So sánh các giải pháp: Đánh đổi trong môi trường triển khai thực tế
Mỗi công cụ hướng tới một nhu cầu vận hành khác nhau. Dưới đây là bảng so sánh thực tế của chúng trong môi trường production:
1. systemd-timesyncd
Ưu điểm: Không cần cài thêm bất kỳ package nào trên các bản phân phối hiện đại; dung lượng RAM cực nhỏ (~3MB RSS); hoàn toàn không mất công bảo trì cho các máy chủ đơn lẻ cơ bản.
Nhược điểm: Không thể chia sẻ thời gian cho các subnet VPC nội bộ; thiếu hỗ trợ đóng dấu thời gian phần cứng (hardware timestamping); không thể đàm phán khóa Network Time Security (NTS); khả năng phục hồi kém nếu đồng hồ khởi động với độ lệch quá lớn.
2. NTPd (Network Time Protocol Daemon)
Ưu điểm: Hàng chục năm kinh nghiệm thực chiến; hỗ trợ driver phần cứng tham chiếu thời gian chuyên dụng rất phong phú như máy thu sóng vô tuyến hoặc đồng hồ nguyên tử.
Nhược điểm: Tốc độ hội tụ rất chậm—thường mất từ 30 đến 60 phút chỉ để kéo độ lệch đồng hồ xuống dưới 10 mili-giây; dễ chập chờn trên các đường truyền WAN nhiều jitter; trong quá khứ dễ bị tấn công giả mạo gói tin dạng plain text nếu không có các cấu hình autokey phức tạp.
3. Chrony
Ưu điểm: Khóa thời gian hệ thống đạt độ chính xác dưới một mili-giây chỉ trong vài giây; kiểm soát độ trôi tần số của bộ dao động cực kỳ chuẩn xác; vận hành mượt mà ở cả vai trò client lẫn server cấp enterprise; hỗ trợ native chuẩn Network Time Security (NTS) qua TLS.
Nhược điểm: Thay thế daemon mặc định của bản phân phối, đồng nghĩa với việc các shell script cũ trích xuất dữ liệu từ ntpq sẽ phải được cập nhật lại để dùng chronyc.
Kiến trúc kiểm chứng thực tế cho Production
Đối với các cụm máy chủ yêu cầu tính sẵn sàng cao (HA), hãy tránh việc để hàng trăm instance đồng loạt truy vấn các cụm public pool bên ngoài. Thay vào đó, hãy xây dựng mô hình đồng bộ hai tầng:
- VPC Edge Time Relay: Triển khai tối thiểu hai node relay Chrony nội bộ trên mỗi cloud region. Cấu hình chúng lấy thời gian từ các server Stratum-1 và Stratum-2 công khai có bảo mật NTS qua các kênh xác thực TLS.
- Workload Node nội bộ: Cấu hình các máy chủ cơ sở dữ liệu, node Kubernetes và máy chủ microservice làm client Chrony trỏ về các relay nội bộ qua mạng con private. Đừng quên thiết lập thêm một pool dự phòng để khôi phục khi xảy ra sự cố.
- Chính sách xử lý trôi giờ nghiêm ngặt: Chỉ cho phép
makesteptrong lần khởi động máy đầu tiên. Bắt buộc áp dụng cơ chế chỉnh giờ từ từ (slewing) trong suốt quá trình runtime. Việc nhảy lùi thời gian (stepping backwards) trong lúc vận hành bình thường có thể làm hỏng tuần tự ghi dữ liệu trong PostgreSQL, Cassandra hoặc Prometheus.
Hướng dẫn triển khai từng bước
Bước 1: Cài đặt Chrony và vô hiệu hóa các daemon xung đột
Đầu tiên, hãy dọn dẹp các daemon mặc định để tránh tình trạng tranh chấp cổng UDP 123:
# Trên Ubuntu/Debian
sudo apt update && sudo apt install -y chrony
sudo systemctl stop systemd-timesyncd 2>/dev/null || true
sudo systemctl disable systemd-timesyncd 2>/dev/null || true
# Trên RHEL/Rocky/AlmaLinux
sudo dnf install -y chrony
Bước 2: Cấu hình Chrony làm Client có bảo mật NTS
Network Time Security (NTS) kết hợp NTP với TLS. Giao thức này sử dụng mật mã để xác thực các nguồn cấp thời gian upstream và ngăn chặn triệt để các cuộc tấn công man-in-the-middle. Chỉnh sửa file cấu hình tại /etc/chrony/chrony.conf (hoặc /etc/chrony.conf trên các hệ thống RHEL):
# Truy vấn các máy chủ Stratum-1/2 hỗ trợ NTS đa dạng, gần về mặt địa lý
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
server ptbtime1.ptb.de iburst nts
# Chỉ cho phép nhảy thời gian trong 3 lần cập nhật đầu tiên nếu độ lệch > 1 giây
# Sau đó, bắt buộc điều chỉnh trơn tru (slewing)
makestep 1.0 3
# Theo dõi độ trôi tần số của bộ dao động qua các lần khởi động lại
driftfile /var/lib/chrony/drift
# Đồng bộ đồng hồ phần cứng RTC của kernel mỗi 11 phút
rtcsync
# Ghi log các điều chỉnh đồng hồ
logdir /var/log/chrony
Áp dụng các thay đổi và kích hoạt service tự chạy khi khởi động:
sudo systemctl restart chrony
sudo systemctl enable chrony
Bước 3: Chia sẻ thời gian cho mạng nội bộ của bạn
Biến một gateway hoặc bastion host thành NTP server cục bộ cho toàn bộ VPC. Mở file cấu hình và thêm quyền truy cập cho subnet cùng stratum nội bộ dự phòng:
# Cho phép yêu cầu đồng bộ từ subnet VPC nội bộ của bạn
allow 10.0.0.0/16
# Cung cấp thời gian cục bộ ngay cả khi kết nối internet upstream tạm thời bị ngắt
local stratum 10
# Lắng nghe duy nhất trên interface nội bộ (ví dụ: IP của eth1)
bindaddress 10.0.1.5
Kích hoạt cấu hình server mà không làm gián đoạn các phiên đang hoạt động:
sudo systemctl reload chrony
Bước 4: Xác thực mã hóa NTS và giám sát độ lệch
Trong một đợt thử nghiệm trên instance AWS c6i.large chạy Ubuntu 22.04 LTS dưới tải 10.000 req/giây, Chrony đã duy trì độ lệch đồng hồ trong phạm vi 18 micro-giây so với UTC. Mức tiêu thụ bộ nhớ duy trì dưới 6MB RSS, trong khi lượng chiếm dụng CPU ở mức dưới 0,1%.
Kiểm tra trạng thái đồng bộ upstream và sức khỏe của các peer:
chronyc sources -v
Tìm dấu hoa thị (*) bên cạnh nguồn tốt nhất, điều này cho biết Chrony đã khóa nguồn đó làm tham chiếu chính. Sau đó kiểm tra xác thực NTS:
chronyc authdata
Số lượng cookie khác không cùng quy trình trao đổi khóa đã được xác minh chứng minh rằng cơ chế xác thực mật mã đang vận hành chính xác.
Xử lý sự cố lệch giờ và rớt mạng trong môi trường Production
1. Nguồn không phản hồi (Reference ID 00000000 / Stratum 0)
Chạy lệnh chronyc tracking để xem xét các chỉ số cốt lõi:
chronyc tracking
# Đầu ra cho thấy mất kết nối upstream:
# Reference ID : 00000000 ()
# Stratum : 0
# Leap status : Chưa đồng bộ
Khi Reference ID bị trống, nguyên nhân thường do tường lửa mạng đang chặn lưu lượng. NTS yêu cầu mở hai cổng: cổng TCP 4460 cho bước bắt tay trao đổi khóa TLS ban đầu và cổng UDP 123 cho các gói tin thời gian. Kiểm tra kết nối bằng nc:
# Kiểm tra cổng trao đổi khóa NTS (TCP 4460)
nc -zvw3 time.cloudflare.com 4460
# Kiểm tra cổng gói tin NTP (UDP 123)
nc -zuvw3 time.cloudflare.com 123
2. Khôi phục sau sự cố máy ảo bị tạm dừng kéo dài
Hoạt động bảo trì hypervisor hoặc live migration có thể làm đóng băng một máy ảo khách trong vài giây hoặc thậm chí vài phút. Khi máy ảo tiếp tục hoạt động, mặc định Chrony sẽ điều chỉnh đồng hồ từ từ (slew) để tránh làm gián đoạn các ứng dụng đang chạy. Nếu hệ thống của bạn đòi hỏi phải khớp thời gian ngay lập tức, hãy ép buộc nhảy bước thủ công:
sudo chronyc makestep
Thao tác này bỏ qua tốc độ điều chỉnh tăng giảm dần và đồng bộ thời gian hệ thống ngay lập tức.
3. Đánh giá Jitter và loại bỏ các Peer chập chờn
Theo dõi độ biến thiên mạng (jitter) và độ ổn định đồng hồ giữa các peer theo thời gian:
chronyc sourcestats -v
Hãy chú ý đặc biệt đến các cột Std Dev (độ lệch chuẩn ước tính) và Est offset. Những máy chủ upstream có độ lệch chuẩn trên 10 mili-giây hoặc tỷ lệ mất gói tin cao nên được loại bỏ khỏi cấu hình để ưu tiên các giải pháp thay thế có độ trễ ổn định hơn.
