Đồng bộ thời gian Linux bằng Chrony/NTP và xử lý clock drift

Thời gian sai vài giây có thể làm log lệch thứ tự, token bị xem là hết hạn, TLS thất bại, job chạy sai cửa sổ và database khó điều tra transaction. Trên một máy độc lập, sai lệch nhỏ có vẻ vô hại; trong hệ phân tán, timestamp là ngữ cảnh dùng để ghép request, đối chiếu sự kiện và thực thi chính sách bảo mật. Đồng bộ thời gian vì thế là một thành phần vận hành, không phải thiết lập “cài một lần rồi quên”.

Chrony gồm daemon chronyd và công cụ chronyc, được thiết kế để đo offset, ước lượng tốc độ trôi của clock và điều chỉnh system clock. Bài viết này tập trung vào cách cấu hình an toàn, đọc trạng thái, đặt cảnh báo và xử lý sự cố. Tên package, service và vị trí file cấu hình có thể khác giữa distribution; luôn kiểm tra tài liệu đi kèm phiên bản đang chạy trước khi áp dụng.

1. Phân biệt system clock, RTC, timezone và nguồn NTP

System clock là thời gian kernel dùng khi hệ điều hành đang chạy. RTC là đồng hồ phần cứng giúp máy có mốc ban đầu sau khi tắt. Timezone chỉ là quy tắc hiển thị giờ địa phương; đổi timezone không sửa một clock đang sai. NTP cung cấp phép đo thời gian qua mạng, còn Chrony chọn nguồn, đánh giá chất lượng và điều chỉnh system clock.

Máy chủ nên giữ RTC theo UTC trừ khi có yêu cầu đặc biệt. Ứng dụng nên lưu timestamp theo UTC và chỉ chuyển timezone ở biên hiển thị. Lệnh sau cho ảnh chụp tổng quan, nhưng trạng thái “synchronized” không thay thế các số đo chi tiết của Chrony:

timedatectl status
date --iso-8601=seconds
date -u --iso-8601=seconds

Đừng sửa clock bằng date --set trên production khi chưa đánh giá tác động. Một bước nhảy ngược có thể phá timeout, lease và thứ tự log; bước nhảy tới trước có thể làm certificate hoặc token bị từ chối.

2. Kiểm tra dịch vụ nào đang quản lý thời gian

Trước khi cài hay sửa cấu hình, xác định máy đang dùng chronyd, systemd-timesyncd, agent của hypervisor hay công cụ cloud. Hai daemon cùng điều khiển system clock có thể tạo hành vi khó dự đoán. Tên unit thường là chrony hoặc chronyd tùy distribution.

systemctl status chronyd
systemctl status chrony
systemctl status systemd-timesyncd
ps -ef | grep -E '[c]hronyd|[t]imesyncd'
chronyd -v
chronyc tracking

Không chạy lệnh enable/disable hàng loạt chỉ vì một unit báo “not found”. Hãy kiểm tra package manager, image baseline và tài liệu distribution. Trong VM, xác minh hypervisor có ép thời gian guest hay không; nếu có hai cơ chế, chọn một owner rõ ràng hoặc cấu hình theo hướng dẫn của nền tảng.

3. Chọn nhiều nguồn thời gian tin cậy

Một nguồn duy nhất tạo single point of failure và không cho client so sánh để phát hiện nguồn sai. Dùng nhiều nguồn độc lập do tổ chức hoặc nhà cung cấp tin cậy quản lý. Trong doanh nghiệp, máy client thường trỏ tới cụm NTP nội bộ; các server tầng trên mới truy vấn nguồn ngoài. Thiết kế này kiểm soát egress, giảm tải và cho phép quan sát tập trung.

# Ví dụ minh họa; thay bằng nguồn đã được tổ chức phê duyệt
server ntp-a.internal.example iburst
server ntp-b.internal.example iburst
server ntp-c.internal.example iburst

makestep 1.0 3
rtcsync

iburst giúp lấy mẫu ban đầu nhanh hơn khi server khả dụng. makestep 1.0 3 cho phép bước clock nếu offset lớn hơn một giây trong ba lần cập nhật đầu; sau đó Chrony ưu tiên slew dần. Đây là ví dụ phổ biến chứ không phải giá trị đúng cho mọi workload. rtcsync yêu cầu kernel định kỳ đồng bộ RTC từ system time trên nền tảng hỗ trợ.

File chính có thể là /etc/chrony.conf hoặc /etc/chrony/chrony.conf; distribution cũng có thể dùng thư mục include. Giữ directive mặc định về drift, key, log và sandbox trừ khi hiểu lý do thay đổi. Trước khi restart, lưu bản diff và chuẩn bị rollback.

4. Step và slew: quyết định có ảnh hưởng ứng dụng

Slew tăng hoặc giảm tốc clock để hội tụ dần, giúp thời gian không nhảy đột ngột nhưng có thể mất lâu khi offset lớn. Step đặt clock sang giá trị mới ngay, hội tụ nhanh nhưng có thể làm thời gian tiến hoặc lùi đột ngột. Tài liệu Chrony khuyến nghị thông thường chỉ cho step trong vài lần cập nhật đầu, trước khi ứng dụng phụ thuộc thời gian khởi động đầy đủ.

Không dùng chronyc makestep tùy tiện trên máy đang xử lý giao dịch. Trước một step thủ công, đánh giá database, scheduler, distributed lock, Kerberos, certificate, message ordering và monitoring. Với server có clock sai nghiêm trọng, phương án an toàn có thể là drain traffic, dừng workload nhạy cảm, sửa time, xác minh rồi đưa node trở lại cụm.

“Clock đã đồng bộ” không có nghĩa mọi timestamp ứng dụng đều có thứ tự toàn cục. Network delay và concurrency vẫn tồn tại; thứ tự nghiệp vụ cần sequence, version hoặc logical clock phù hợp.

5. Đọc báo cáo tracking

chronyc -N tracking

Đừng alert chỉ theo stratum. Chất lượng phụ thuộc offset, jitter, root delay/distance, độ ổn định nguồn và topology. Baseline từng loại máy vì VM, bare metal và thiết bị biên có đặc tính drift khác nhau. Một frequency ổn định khác 0 không nhất thiết là lỗi; Chrony dùng ước lượng đó để bù clock.

6. Kiểm tra nguồn và thống kê mẫu

chronyc -N sources -v
chronyc sourcestats -v
chronyc activity

Trong báo cáo sources, ký hiệu ^* thường cho biết nguồn server đang được chọn, ^+ là nguồn có thể kết hợp, còn các trạng thái khác cần đọc theo man page đúng phiên bản. Cột reach phản ánh lịch sử reachability dưới dạng thanh ghi, không phải phần trăm đơn giản. Nếu không có nguồn selectable, hãy kiểm tra DNS, firewall, route, packet loss và chính sách source selection.

sourcestats giúp xem số mẫu, frequency và sai số ước lượng theo từng nguồn. Thay vì phản ứng với một mẫu offset, hãy tìm xu hướng: nguồn liên tục có jitter cao, node đổi nguồn quá thường xuyên, hoặc frequency tăng bất thường sau live migration/suspend.

7. Firewall, DNS và bảo mật nguồn thời gian

NTP truyền thống dùng UDP 123. Nếu dùng Network Time Security (NTS), cơ chế thương lượng còn cần kết nối theo cấu hình của server; ví dụ tài liệu Ubuntu hiện mô tả TCP 4460 cho NTS và vẫn dùng UDP 123 cho NTP. Chỉ mở đúng hướng và đúng destination cần thiết. Không biến client thành NTP server công khai bằng directive allow quá rộng.

• Dùng nguồn do tổ chức phê duyệt và nhiều vị trí độc lập.
• Ưu tiên authentication/NTS khi topology và distribution hỗ trợ.
• Giới hạn client subnet nếu node thật sự phục vụ NTP nội bộ.
• Giám sát thay đổi cấu hình, source được chọn và bước nhảy clock.
• Không log secret/key; bảo vệ file key bằng permission tối thiểu.

Clock sai quá xa có thể tạo vòng lặp bootstrapping với DNSSEC hoặc TLS: hệ thống cần thời gian đúng để xác minh chứng thư nhưng lại cần DNS/TLS để tới nguồn. Thiết kế nguồn bootstrap phải theo tài liệu distribution và mô hình đe dọa, không giải quyết bằng cách tắt xác minh TLS toàn hệ thống.

8. Thiết kế NTP nội bộ có dự phòng

Với fleet lớn, triển khai ít nhất vài NTP server nội bộ ở failure domain khác nhau. Mỗi client dùng nhiều nguồn; nguồn nội bộ truy vấn upstream tin cậy hoặc reference clock theo yêu cầu. Không đặt tất cả server thời gian trên cùng host, switch, hypervisor hay vùng mạng.

Chrony có thể phục vụ client khi cấu hình allow, nhưng chỉ nên cho subnet cụ thể và kèm firewall. Đừng cấu hình “local time” giả làm nguồn chuẩn trừ khi đã hiểu cách nó ảnh hưởng selection trong thời gian mất upstream. Khi cô lập mạng, quyết định ưu tiên availability hay độ chính xác phải được ghi rõ: clock tiếp tục free-run có uncertainty tăng dần.

9. Monitoring và SLO cho time synchronization

Thu thập metric định kỳ từ tracking và sources thay vì chỉ ping service. Tối thiểu cần:

• Trạng thái synchronized/leap và thời gian kể từ reference update.
• Absolute system offset, RMS offset và root dispersion/distance.
• Số nguồn selectable/reachable và nguồn đang được chọn.
• Frequency/skew, số lần source đổi và clock step.
• Tuổi của dữ liệu đo và lỗi truy vấn chronyc.

Ngưỡng phải phù hợp workload. Một hệ thống xác thực hoặc phân tích latency cần chặt hơn máy build. Cảnh báo nhiều tầng có thể phát hiện offset tăng, mất dự phòng và hoàn toàn unsynchronized. Dashboard phải dùng UTC và ghi rõ đơn vị; nhầm millisecond với second có thể tạo cảnh báo giả hoặc che lỗi nghiêm trọng.

10. Runbook xử lý sự cố

1. Xác nhận phạm vi: một node, một zone hay toàn bộ fleet.
2. Chụp timedatectl, chronyc tracking, sources -v, log dịch vụ và thay đổi gần nhất.
3. Kiểm tra có nhiều time daemon/agent cùng hoạt động không.
4. Kiểm tra DNS, UDP 123, NTS nếu dùng, route, packet loss và firewall.
5. So sánh source selection với node khỏe; không vội step clock.
6. Nếu cần sửa lớn, drain workload và tuân thủ runbook của ứng dụng.
7. Sau phục hồi, xác minh offset hội tụ, nguồn dự phòng và tác động lên log/job/token.

Trong container, system clock thường thuộc kernel của host; cài chronyd trong mỗi container không giải quyết clock host và thường thiếu quyền cần thiết. Đồng bộ tại node/VM, rồi giám sát ứng dụng từ góc nhìn container. Khi node resume sau suspend hoặc live migration, theo dõi offset và khả năng hội tụ thay vì giả định hypervisor đã xử lý hoàn hảo.

Checklist production

• Chỉ một cơ chế có quyền điều chỉnh system clock.
• Có nhiều nguồn tin cậy ở failure domain khác nhau.
• Step chỉ được phép trong cửa sổ đã đánh giá; thao tác thủ công có runbook.
• Firewall, DNS và NTS/authentication đã được kiểm thử.
• Offset, source health, leap status và drift có metric/cảnh báo.
• Topology NTP nội bộ, owner và quy trình thay nguồn được ghi tài liệu.
• Ứng dụng vẫn dùng version/sequence cho thứ tự nghiệp vụ, không chỉ timestamp.

Tài liệu tham khảo

• Chrony Documentation
• Chrony Frequently Asked Questions
• Chrony configuration and accuracy examples
• Ubuntu Server: Synchronize time using Chrony

Kết luận

Đồng bộ thời gian tin cậy cần nhiều hơn một daemon đang chạy. Một cấu hình production phải có nguồn đa dạng, policy step/slew rõ ràng, chỉ một owner của system clock, metric về offset và source health, cùng runbook cho sai lệch lớn. Chrony cung cấp dữ liệu cần thiết qua tracking, sources và sourcestats; nhiệm vụ của đội vận hành là biến những số đo đó thành SLO, cảnh báo và quy trình phục hồi an toàn.