Phân tán NTP là gì và làm cách nào để kiểm soát nó?

Chúng tôi triển khai các máy chủ Ubuntu 14.04 trên các mạng bị cô lập, chạy ntpd 4.2.6p5, được định cấu hình để sử dụng nhiều máy chủ NTP do khách hàng cung cấp (không có quyền truy cập vào pool.ntp.org). Các thiết bị đầu cuối câm của chúng tôi chạy phiên bản cũ của BusyBox (1,00-RC2) và ntpclient 2010 từ Larry Doolittle.

Thiết lập này đã hoạt động rất tốt trong nhiều năm, nhưng gần đây chúng tôi đã đạt được một rào cản với một khách hàng mới. Họ đã cung cấp cho chúng tôi 5 địa chỉ máy chủ NTP nội bộ có vẻ như hoạt động rất tốt, theo như ntpdate-debianliên quan đến máy chủ Linux. Tuy nhiên, ntpclientvề phía BusyBox, phàn nàn với "Độ phân tán quá cao". Từ đầu ra gỡ lỗi, ntpclientnhận "1217163.1" từ máy chủ NTP nhưng giá trị tối đa mà nó hỗ trợ là tuyệt đối (65536).

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

Đây là tất cả các thiết bị trên cùng một mạng LAN nên thật lòng tôi rất bối rối. Thậm chí còn kinh ngạc.

Đây là ntpq -pnđầu ra từ máy chủ Ubuntu 14.04:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

Câu hỏi của tôi là:

1. Phân tán là gì và những gì có thể thay đổi giá trị của nó?
2. Những lệnh nào tôi có thể chạy để có thêm thông tin chi tiết từ các máy chủ NTP?
3. Có thể lỗi nằm ở phía máy chủ Ubuntu, với một lỗi không đúng ntp.conf? Không có gì đặc biệt ở đó thực sự.
4. Sẽ chuyển sang chrony thay đổi bất cứ điều gì trong trường hợp này?

Tôi thấy một số nhầm lẫn đang diễn ra trong các câu trả lời ở đây. Đối với người mới bắt đầu, ntpclientít nhất là trong -schế độ, không hoạt động như một máy khách NTP đầy đủ, nó chỉ gửi và nhận một gói , do đó không có "8 gói cuối cùng nhận được". Nó thực sự không ước tính sự phân tán của chính nó.

Thay vào đó, giá trị mà nó đang in là giá trị được gọi là "phân tán gốc" (rootdisp) trong gói được máy chủ trả về, đây là ước tính của tổng số lượng lỗi / phương sai giữa máy chủ đó và thời gian chính xác. Cách tính toán này khá đơn giản: mọi máy chủ NTP đều lấy thời gian từ đồng hồ bên ngoài (ví dụ: máy thu radio hoặc GPS) hoặc từ máy chủ NTP khác. Nếu một máy chủ nhận được thời gian của nó từ một đồng hồ bên ngoài, sự phân tán gốc của nó là lỗi tối đa ước tính của đồng hồ đó. Nếu nó nhận được thời gian từ một máy chủ NTP khác, thì sự phân tán gốc của nó là sự phân tán gốc của máy chủ đó cộng với sự phân tán được thêm bởi liên kết mạng giữa chúng.

Một điểm khó hiểu ở đây là trong khi ntpq và chrony hiển thị phân tán và phân tán gốc trong vài giây, đó là những gì mọi người thường tìm đến, ntpclient hiển thị nó trong micro giây . Bất kể, giá trị 1217163 vẫn còn khá cao. Một máy chủ NTP tốt biết thời gian trong vòng vài mili giây; một cái xấu trong vòng vài chục hoặc hàng trăm mili giây. Bạn đang nói với bạn rằng thời gian của nó chỉ có thể được tin cậy trong vòng +/- 1,2 giây.

Bạn thực sự có thể nhận được ntpclient để đồng bộ hóa với máy chủ này bằng cách chuyển tùy chọn -x 0hoặc -t(tùy thuộc vào phiên bản của ntpclient), điều này vô hiệu hóa kiểm tra độ tỉnh của NTP. Nếu bạn chỉ cần thời gian gần như chính xác (trong vòng vài giây), điều đó có thể đủ tốt. Tuy nhiên, ntpclient đang khá hợp lý khi từ chối đồng bộ hóa với một máy chủ tồi như vậy. ntpqĐầu ra của bạn trên máy ubfox đang hiển thị độ giật hàng trăm mili giây cho tất cả các máy chủ của nó, mặc dù chúng có độ trễ thấp, điều này cho thấy một mạng rất không đáng tin cậy, âm mưu của tất cả các máy chủ cung cấp thời gian thất thường hoặc cơ bản vấn đề chấm công trên máy chủ.

Tôi cũng lo ngại rằng máy chủ 10.31.10.22 đang quảng cáo một bản giới thiệu LOCL(đồng hồ cục bộ không có kỷ luật) nhưng có tầng 1. Thông thường, đồng hồ cục bộ được chuyển thành tầng 10 để nó chỉ được sử dụng làm nguồn đồng bộ hóa cuối cùng để giữ một đàn khỏi trôi. 10.31.10.22 bị định cấu hình sai và cung cấp thời gian xấu cho phần còn lại của mạng hoặc bị xử lý kỷ luật thời gian tốt bởi một số chương trình nằm ngoài sự kiểm soát của NTP, trong trường hợp đó, cấu hình sai chỉ đơn giản là quảng cáo phản hồi LOCL; nó nên được ghi đè lên ví dụ GPShoặc bất cứ điều gì đang cung cấp thời gian của nó.

Chỉ là một câu trả lời một phần cho "Phân tán là gì?":

Một chuyến đi khứ hồi NTP điển hình:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

Điều này mang lại hai giá trị, bù (chênh lệch thời gian giữa máy khách và máy chủ) và độ trễ (thiết yếu thời gian di chuyển mạng) với các công thức sau:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

Máy khách chọn phần bù hiện tại trong số 8 gói cuối cùng nhận được, chọn gói có độ trễ nhỏ nhất.

8 gói tương tự được sử dụng để tính toán độ phân tán bằng cách lấy trung bình có trọng số chênh lệch của 8 độ lệch này với gói được chọn trong bước cuối cùng, trong đó độ trễ được sử dụng làm hệ số trọng số, tạo ra trọng số lớn hơn cho độ trễ nhỏ hơn. Nó là thước đo cho "mức chênh lệch" của các giá trị và được sử dụng để tính toán chất lượng của máy chủ thời gian, đặc biệt nếu bạn có nhiều lựa chọn.

Sự phân tán và xiên của bạn là rất lớn, có một sự bù đắp rất lớn từ đồng hồ địa phương đến đồng đẳng đó. Bạn nên so sánh độ lệch với cục bộ datevà đặt đồng hồ theo cách thủ công.

Nhận ntpd chạy và hiển thị ntpq -ptừ một máy chủ bằng cách sử dụng tất cả các đồng nghiệp. Nó sẽ chọn những cái tốt hơn.

Theo tài liệu cisco này , " sự phân tán , được báo cáo trong vài giây, là chênh lệch thời gian đồng hồ tối đa từng được quan sát giữa đồng hồ cục bộ và đồng hồ máy chủ". Với các máy chủ ntp không bị hỏng hoàn toàn, sẽ không bao giờ xảy ra sự phân tán cao. Kịch bản khả thi duy nhất là khi khách hàng của bạn vào ntp và cho đến nay chỉ có đồng hồ cục bộ của nó. Và thậm chí sau đó, một sự phân tán cao như bạn báo cáo tương ứng với các đồng hồ đã tắt hơn hai tuần .

Cần phải đủ để đảm bảo rằng đồng hồ cục bộ không còn quá xa trong thời gian đầu (thậm chí một vài giờ vẫn có thể chấp nhận được), bằng cách điều chỉnh đồng hồ (và ngày chẵn!) Trong BIOS hoặc bằng cách phát hành ntpdatemột lần trước khi bắt đầu ntpdtrên máy khách.