chrony so với systemd-timesyncd - Sự khác biệt và trường hợp sử dụng như máy khách NTP là gì?

Bằng cách nào đó nhưng không hoàn toàn dựa trên câu hỏi cũ hơn "ntpd so với systemd-timesyncd - Làm thế nào để đạt được đồng bộ hóa NTP đáng tin cậy?" , Tôi muốn hỏi về sự khác biệt giữa chrony và systemd-timesyncd về mặt máy khách NTP .

Tôi biết rằng systemd-timesyncd là một triển khai máy khách ntp tối thiểu hoặc ít hơn trong khi chrony là một giải pháp daemon NTP đầy đủ, tình cờ bao gồm một máy khách NTP.

Bản phát hành Beaver Bionic Beaver ghi chú như sau:

Để đồng bộ hóa thời gian đơn giản, hệ thống cơ sở đã đi kèm với systemd-timesyncd. Chrony chỉ cần thiết để hoạt động như một máy chủ thời gian hoặc nếu bạn muốn đồng bộ hóa được quảng cáo chính xác và hiệu quả hơn.

Tôi thích ý tưởng sử dụng một công cụ được cài đặt sẵn tối thiểu để thực hiện công việc và tôi khá chắc chắn systemd-timesyncd sẽ thực hiện công việc cho các trường hợp sử dụng của tôi, tôi vẫn tò mò:

• Sự khác biệt trong thế giới thực giữa hai bên về độ chính xác là gì?
• Sự khác biệt về hiệu quả là gì?
• Nhu cầu đồng bộ hóa thời gian "không đơn giản" hay còn gọi là trường hợp sử dụng cho chrony là máy khách NTP là gì?

Các thông báo của systemd-timesyncd trong file TIN TỨC systemd làm một công việc tốt trong việc giải thích sự khác biệt của công cụ này so với Chrony và các công cụ như nó. (nhấn mạnh của tôi):

Một trình nền "systemd-timesyncd" mới đã được thêm vào để đồng bộ hóa đồng hồ hệ thống trên mạng. Nó thực hiện một máy khách SNTP . Trái ngược với các triển khai NTP như chrony hoặc máy chủ tham chiếu NTP, điều này chỉ thực hiện phía máy khách và không bận tâm đến độ phức tạp NTP đầy đủ, chỉ tập trung vào thời gian truy vấn từ một máy chủ từ xa và đồng bộ hóa đồng hồ cục bộ với nó . Trừ khi bạn có ý định phục vụ NTP cho các máy khách được nối mạng hoặc muốn kết nối với đồng hồ phần cứng cục bộ, máy khách NTP đơn giản này sẽ phù hợp hơn cho hầu hết các cài đặt. [...]

Thiết lập này là trường hợp sử dụng phổ biến cho hầu hết các máy chủ trong một đội máy chủ. Chúng thường sẽ được đồng bộ hóa từ các máy chủ NTP cục bộ, chúng được đồng bộ hóa từ nhiều nguồn, có thể bao gồm cả phần cứng. systemd-timesyncd cố gắng cung cấp một giải pháp dễ sử dụng cho trường hợp sử dụng phổ biến đó.

Cố gắng giải quyết các câu hỏi cụ thể của bạn:

Sự khác biệt trong thế giới thực giữa hai bên về độ chính xác là gì?

Tôi tin rằng bạn có thể có được độ chính xác cao hơn bằng cách lấy dữ liệu đồng bộ hóa từ nhiều nguồn, đặc biệt không phải là trường hợp sử dụng được hỗ trợ cho systemd-timesyncd. Nhưng khi bạn đang sử dụng nó để nhận dữ liệu đồng bộ hóa từ các máy chủ NTP trung tâm được kết nối với mạng nội bộ đáng tin cậy của bạn, việc sử dụng nhiều nguồn không thực sự phù hợp và bạn có được độ chính xác tốt từ một nguồn duy nhất.

Nếu bạn đang đồng bộ hóa máy chủ của mình từ một máy chủ đáng tin cậy trong mạng cục bộ và trong cùng một trung tâm dữ liệu , sự khác biệt về độ chính xác giữa NTP và SNTP sẽ gần như không tồn tại. NTP có thể tính đến RTT và thực hiện thời gian, nhưng điều đó không có lợi khi RTT của bạn thực sự nhỏ, đó là trường hợp của một mạng cục bộ nhanh và một máy gần đó. Bạn cũng không cần nhiều nguồn nếu bạn có thể tin tưởng vào nguồn bạn đang sử dụng.

Sự khác biệt về hiệu quả là gì?

Nhận đồng bộ hóa từ một nguồn đơn giản hơn nhiều so với nhận từ nhiều nguồn, vì bạn không phải đưa ra quyết định về nguồn nào tốt hơn nguồn khác và có thể kết hợp thông tin từ nhiều nguồn. Các thuật toán đơn giản hơn nhiều và sẽ yêu cầu tải CPU ít hơn cho trường hợp đơn giản.

Nhu cầu đồng bộ hóa thời gian "không đơn giản" hay còn gọi là trường hợp sử dụng cho chrony là máy khách NTP là gì?

Điều đó được đề cập trong đoạn trích dẫn ở trên, nhưng trong mọi trường hợp, đây là những trường hợp sử dụng cho Chrony không được bao phủ bởi systemd-timesyncd:

• chạy máy chủ NTP (để các máy chủ khác có thể sử dụng máy chủ này làm nguồn để đồng bộ hóa);
• nhận thông tin đồng bộ hóa NTP từ nhiều nguồn (điều quan trọng đối với các máy chủ nhận thông tin đó từ các máy chủ công cộng trên Internet); và
• nhận thông tin đồng bộ hóa từ đồng hồ cục bộ, thường liên quan đến phần cứng chuyên dụng như thiết bị GPS có thể nhận thông tin thời gian chính xác từ các vệ tinh.

Những trường hợp sử dụng này yêu cầu Chrony hoặc ntpd hoặc tương tự.

Như câu trả lời khác nêu chính xác, chronythực hiện NTP và systemd-timesyncdSNTP.

Từ quan điểm của một khách hàng dịch vụ thời gian:

SNTP là một giao thức đơn giản hơn nhiều để thực hiện;
NTP cho phép tăng / chỉnh sửa từng bước theo thời gian. Một lợi thế lớn của NTP là nó cũng tính đến RTT của câu trả lời để có thời gian chính xác hơn.

Từ https://www.meinbergglobal.com/english/faq/faq_37.htm

Mặc dù máy chủ hoặc máy khách NTP đầy đủ tính năng đạt đến độ chính xác rất cao và tránh các bước thời gian đột ngột nhất có thể bằng cách sử dụng các phương pháp toán học và thống kê khác nhau và điều chỉnh tốc độ xung nhịp mượt mà, SNTP chỉ có thể được đề xuất cho các ứng dụng đơn giản, trong đó yêu cầu cho độ chính xác và độ tin cậy không quá khắt khe. Bằng cách bỏ qua các giá trị trôi và sử dụng các cách đơn giản hóa các phương pháp điều chỉnh đồng hồ hệ thống (thường là bước thời gian đơn giản), SNTP chỉ đạt được đồng bộ hóa thời gian chất lượng thấp khi so sánh với việc thực hiện NTP đầy đủ.

SNTP áp dụng một cách tiếp cận đơn giản hơn nhiều. Nhiều sự phức tạp của thuật toán NTP được loại bỏ. Thay vì kéo dài thời gian, nhiều khách hàng SNTP bước thời gian. Điều này tốt cho nhiều ứng dụng yêu cầu một dấu thời gian đơn giản. Ngoài ra, SNTP thiếu khả năng giám sát và lọc nhiều máy chủ NTP. Thường thì cách tiếp cận vòng tròn đơn giản được sử dụng, trong đó nếu một máy chủ bị lỗi, thì cách tiếp theo trong danh sách sẽ được sử dụng

Từ https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP chính xác và chính xác hơn nhiều so với SNTP và điều này khiến nó trở thành người chiến thắng thực tế trong hầu hết các ứng dụng doanh nghiệp. Mặt khác, sự đơn giản của SNTP làm cho nó phù hợp hơn với những thứ như camera IP, DVR và một số thiết bị chuyển mạch mạng. Các loại phần cứng này thiếu tài nguyên xử lý để xử lý các giao thức phức tạp hơn, nhưng khi các thiết bị được kết nối ngày càng mạnh mẽ, điều đó có thể thay đổi.

Một điểm yếu lớn của SNTP là bạn không thể làm cho nó chính xác hơn bằng cách truy xuất thời gian từ nhiều nguồn như Giao thức thời gian mạng theo mặc định.

Một điểm quan trọng khác tôi có thể thấy việc triển khai SNTP gây ra nhiều vấn đề hơn NTP là ảo hóa, khi bạn có cả trình ảo hóa trình ảo hóa và trình ảo NTP đang cố gắng thay đổi thời gian VM. Đặc biệt với việc họ không đồng ý về thời gian với một số cấu hình sai khiến cả hai đều hoạt động, nó có thể gây ra vấn đề lớn. (Trong khi các quản trị viên hệ thống có thẩm quyền sẽ chỉ duy trì hoạt động một phương thức để đồng bộ hóa với thời gian, có thể xảy ra cả hai đều hoạt động do lỗi cấu hình).

PS systemd-timesyncdkhông nên là một sự thay thế khuyên khi không sử dụng systemd.

chronykhông phải là một hình thức ngã ba ntpdnhưng nó được thực hiện từ đầu. Nó thực hiện cả chế độ máy khách và máy chủ của giao thức NTPv4 đầy đủ ( RFC5905 ). Trên người dùng cấp doanh nghiệp, chúng tôi đang thấy xu hướng chuyển từ truyền thống ntpdsang chronythích Red Hat (RHEL 7 trở đi) và SuSE (từ SLES 15).

systemd-timesyncdchỉ thực hiện chế độ máy khách giao thức SNTP ( RFC4330 ) . Do đó các trường hợp sử dụng phức tạp không được bảo hiểm . Ví dụ: SNTP không thể làm cho nó chính xác hơn bằng cách lấy thời gian từ nhiều nguồn như NTP theo mặc định. Kết quả là không thể cung cấp thời gian chính xác cao như .systemd-timesyncdsystemd-timesyncdchrony