Hệ điều hành · 16/10/2026

Đồng bộ thời gian Linux với chrony: NTP an toàn cho production

Đồng hồ Linux lệch vài giây có thể làm TLS báo certificate chưa hợp lệ, log sai thứ tự, token hết hạn sớm, Kerberos thất bại và dữ liệu phân tán khó đối soát. Chrony không chỉ “đặt giờ đúng”: chronyd đo offset và độ trôi của oscillator, chọn nguồn phù hợp, rồi điều chỉnh clock theo cách hạn chế time jump. Một cấu hình production cần nhiều nguồn độc lập, policy step/slew rõ ràng, NTS khi hỗ trợ và metric chứng minh node thật sự đang đồng bộ.

Đồng bộ thời gian Linux với chrony: NTP an toàn cho production

Đồng hồ Linux lệch vài giây có thể làm TLS báo certificate chưa hợp lệ, log sai thứ tự, token hết hạn sớm, Kerberos thất bại và dữ liệu phân tán khó đối soát. Chrony không chỉ “đặt giờ đúng”: chronyd đo offset và độ trôi của oscillator, chọn nguồn phù hợp, rồi điều chỉnh clock theo cách hạn chế time jump. Một cấu hình production cần nhiều nguồn độc lập, policy step/slew rõ ràng, NTS khi hỗ trợ và metric chứng minh node thật sự đang đồng bộ.

Bài viết dựa trên tài liệu chính thức của chrony.conf và chronyc. Directive và output có thể khác theo phiên bản chrony/distro; kiểm tra man page được cài trên máy trước khi áp dụng.

1. Có nhiều “đồng hồ” trên một máy

Khái niệmDùng choLưu ý
System realtime clockTimestamp lịch, log, TLSCó thể được NTP điều chỉnh hoặc step
Monotonic clockĐo duration, timeoutKhông nên nhảy lùi như wall clock
RTC/hardware clockGiữ thời gian qua rebootKhông thay cho NTP đang chạy
TimezoneHiển thị giờ địa phươngKhông làm clock chính xác hơn

Ứng dụng đo latency hoặc deadline nội bộ nên dùng monotonic API. UTC/timezone là bài toán biểu diễn; NTP là bài toán đồng bộ. Đổi timezone không sửa clock drift.

2. Offset, frequency, jitter và root distance

  • Offset: ước lượng chênh lệch giữa local clock và nguồn.
  • Frequency/drift: tốc độ clock chạy nhanh hoặc chậm theo thời gian.
  • Jitter: độ biến động giữa các measurement.
  • Root distance: biên sai số ước lượng tích lũy, gồm dispersion và delay.

Một server có ping thấp chưa chắc là nguồn tốt nếu jitter cao hoặc upstream sai. Chrony so sánh nhiều measurement, loại nguồn không đồng thuận và có thể kết hợp các nguồn phù hợp để cải thiện ước lượng.

3. Cấu hình khởi đầu có điều kiện

# Chỉ thêm "nts" nếu pool/server thực sự hỗ trợ NTS
pool time-a.example.net iburst maxsources 2 nts
pool time-b.example.org iburst maxsources 2 nts

# Yêu cầu ít nhất hai nguồn selectable trước khi cập nhật clock
minsources 2

driftfile /var/lib/chrony/drift

# Chỉ cho phép step nếu lệch trên 1 giây trong 3 update đầu
makestep 1.0 3

# Đồng bộ RTC định kỳ trên hệ hỗ trợ
rtcsync

# Lưu NTS cookies/keys theo đường dẫn phù hợp của distro
ntsdumpdir /var/lib/chrony

Đây là skeleton minh họa. Hostname, đường dẫn, quyền file, NTS support và default config khác theo distribution. Nếu nguồn không hỗ trợ NTS, thêm nts làm nguồn không hoạt động thay vì tự “nâng cấp” bảo mật.

4. Nhiều nguồn chỉ hữu ích khi độc lập

Bốn hostname trỏ cùng provider, cùng upstream hoặc cùng đường mạng không tạo bốn fault domain. Chọn nguồn từ hạ tầng đáng tin, hiểu operator và network path. Trong môi trường enterprise, có thể dùng nhiều NTP gateway nội bộ lấy thời gian từ upstream độc lập.

minsources 2 ngăn clock update khi chỉ còn một nguồn selectable, giúp giảm rủi ro tin nguồn sai đơn lẻ. Đổi lại, node có thể ngừng cập nhật khi network partition chỉ cho thấy một nguồn. Chọn số dựa trên threat model và availability; theo dõi ngay khi selectable sources thấp hơn kỳ vọng.

5. Step và slew có hậu quả khác nhau

Slew làm clock chạy nhanh/chậm tạm thời để dần xóa offset, tránh nhảy timestamp. Step đặt clock ngay, xử lý nhanh lệch lớn nhưng có thể làm thời gian nhảy tiến hoặc lùi.

Time jump có thể gây:

  • timer/lease/TTL chạy sai hoặc hết hạn đột ngột;
  • log và event đảo thứ tự;
  • job scheduler chạy lặp hoặc bỏ lịch;
  • database/consensus system cảnh báo clock anomaly;
  • metric rate tạo spike hoặc giá trị âm.

makestep 1.0 3 giới hạn step vào giai đoạn đầu, khi service nhạy cảm nên chưa nhận traffic. Không chạy chronyc makestep tùy tiện trên production đang tải chỉ để dashboard offset về 0.

6. Bootstrap trước khi khởi động workload nhạy thời gian

Trình tự an toàn cho node mới:

  1. khởi động chronyd và thu measurement với iburst;
  2. cho phép step trong policy bootstrap nếu offset lớn;
  3. đợi trạng thái sync đạt ngưỡng;
  4. sau đó mới mở service phụ thuộc TLS, token, database hoặc consensus.
chronyc waitsync 60 0.01

Ví dụ trên đợi tối đa khoảng 60 lần kiểm tra để remaining correction dưới 10 ms; không phải ngưỡng bắt buộc. Systemd unit có thể dùng dependency/readiness gate, nhưng tránh làm toàn máy boot vô hạn khi NTP upstream mất—cần timeout và degraded-mode policy.

7. Đọc chronyc thay vì chỉ xem service active

chronyc tracking
chronyc sources -v
chronyc sourcestats -v
chronyc activity

systemctl active chỉ chứng minh process chạy. Trong sources, dấu * là nguồn đang chọn, + là nguồn acceptable được kết hợp, ? thường chưa reachable/đủ measurement, và x báo falseticker không đồng thuận. Reach 377 ở dạng bát phân nghĩa tám lần poll gần nhất đều nhận reply hợp lệ.

tracking cung cấp reference ID, stratum, system time correction, frequency, skew, root delay và root dispersion. Đọc các trường cùng nhau; offset nhỏ tại một thời điểm không bảo đảm nguồn còn reachable hoặc sai số bound tốt.

8. NTS xác thực nguồn thời gian, không sửa mọi rủi ro

NTP truyền thống không xác thực mạnh nguồn, nên kẻ tấn công trên đường mạng có thể giả mạo hoặc can thiệp. Network Time Security (NTS) dùng quá trình thiết lập khóa và extension field để xác thực gói NTP khi cả client/server hỗ trợ.

  • Pin CA/trust store phù hợp và đảm bảo bootstrap time không quá sai để TLS NTS-KE hoạt động.
  • Cho phép đúng network flow cần thiết theo tài liệu server/provider.
  • Bảo vệ ntsdumpdir và kiểm tra permission.
  • Theo dõi NTS handshake/cookie failure, không âm thầm fallback ngoài policy.

NTS xác thực nguồn và integrity, không làm upstream chính xác, không chống host bị root compromise và không thay việc so sánh nhiều nguồn.

9. Firewall và chronyc control plane

Client NTP thường cần outbound UDP 123; NTS có thêm kết nối thiết lập khóa theo server. Chỉ mở inbound NTP nếu host thật sự phục vụ client khác. Không bật allow rộng trên mọi interface chỉ vì một hướng dẫn mẫu.

chronyc local ưu tiên Unix socket với quyền hạn phù hợp. Nếu mở monitoring/control qua network, giới hạn bindcmdaddress, cmdallow, firewall và command được phép. Không expose control endpoint công khai.

10. VM, cloud và container

VM có thể chịu clock drift khi host quá tải, suspend/resume hoặc live migration. Không chạy đồng thời nhiều daemon/time agent cùng điều khiển clock nếu chưa hiểu tương tác. Dùng nguồn thời gian được cloud provider khuyến nghị khi phù hợp, nhưng vẫn giám sát độc lập.

Container thường chia sẻ kernel clock với host và không nên tự chạy chronyd để chỉnh giờ. Trong Kubernetes, đồng bộ là trách nhiệm của node OS; alert theo node và đánh dấu/loại node có clock không tin cậy. Pod không sửa được host time một cách an toàn bằng việc thêm privilege.

11. Leap second và timezone

Leap second handling phụ thuộc upstream, kernel, chrony và policy smear của nhà cung cấp. Không trộn ngẫu nhiên nguồn smear và non-smear vì chúng có thể bất đồng trong cửa sổ leap. Chọn một chính sách nhất quán, test ứng dụng và ghi rõ nguồn nào smear.

Timezone database cần cập nhật riêng. Lưu event timestamp bằng UTC/instant; chuyển sang timezone khi hiển thị. Chrony không giải quyết daylight saving time hoặc rule lịch địa phương.

12. Monitoring và alert

Tín hiệuÝ nghĩa
Synchronization stateNode có reference hợp lệ hay không
System/last offsetMức correction hiện tại
Root distanceBound sai số ước lượng
Frequency/skewĐộ trôi và độ chắc của ước lượng
Selectable/reachable sourcesDiversity và network health
Source stateFalseticker, unreachable, waiting
Last successful updateThời gian holdover đang tăng

Alert theo SLO của hệ thống: authentication có thể cần tolerance khác database transaction ordering hoặc measurement system. Alert riêng cho mất sync kéo dài, root distance cao, số nguồn thấp và offset tăng nhanh. Đừng chỉ ping UDP 123.

13. Runbook khi clock lệch

  1. Xác nhận symptom bằng tracking, sources và metric ngoài host.
  2. Kiểm tra DNS, firewall, NTS handshake, source state và network delay.
  3. So sánh nhiều node/nguồn; không chọn một website hiển thị giờ làm authority.
  4. Đánh giá tác động của step trước khi thực hiện.
  5. Nếu cần, drain traffic/stop workload nhạy thời gian, sửa clock rồi khởi động lại có kiểm soát.
  6. Kiểm tra token, certificate, database lease, log và scheduled job sau sự cố.

Checklist production

  • Chrony version/config được quản lý và kiểm tra theo distro.
  • Có nhiều nguồn độc lập; minsources phù hợp threat model.
  • NTS được dùng khi hỗ trợ và failure không fallback ngoài policy.
  • makestep giới hạn ở bootstrap; step runtime có runbook.
  • Workload nhạy thời gian đợi sync/readiness có timeout.
  • Không có hai daemon cùng tranh quyền điều chỉnh clock.
  • Container dựa vào node time; node lệch được cordon/drain theo policy.
  • Firewall/control socket chỉ mở phạm vi cần thiết.
  • Metric có offset, root distance, sources, reachability và sync state.
  • Đã diễn tập upstream outage, VM resume và clock lệch lớn.

Kết luận

Đồng bộ thời gian tốt không phải là một lần chạy date, mà là quá trình liên tục ước lượng offset, drift và độ tin cậy của nguồn. Chrony phát huy giá trị khi nguồn đủ độc lập, step chỉ xảy ra trong cửa sổ an toàn, NTS bảo vệ đường thời gian và monitoring đo đúng root distance lẫn synchronization state. Khi đó clock trở thành một dependency production có SLO, không phải giả định vô hình.

Thảo luận

Bình luận 0

Đăng nhập để bình luận

Bạn cần có tài khoản để tham gia thảo luận và trả lời độc giả khác.

Đăng nhậpĐăng ký

Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.