Tại sao NTP đồng bộ hóa với ĐỊA PHƯƠNG chứ không phải máy chủ từ xa?


11

Vì vậy, tôi đang cố gắng gỡ lỗi thiết lập NTP hiện tại của mình và thấy rằng anh ta bù từ máy chủ được cấu hình duy nhất của tôi là hơn 3 giây và không điều chỉnh. Dấu hoa thị trên LOCAL (0) trong đầu ra ntpq dường như chỉ ra rằng hệ thống đang tự đồng bộ hóa với chính nó chứ không phải máy chủ 10.130.33.201 (là một hộp linux khác trên hệ thống của chúng tôi mà chúng tôi muốn mọi thứ đồng bộ hóa).

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

Và đây là tập tin ntp.conf của tôi. Được viết bởi người khác, vì vậy tôi không chắc chắn 100% rằng mọi thứ đều đúng.

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

Tôi đã đọc về sự bùng nổ và iburst và minpoll / maxpoll, vì vậy tôi nhận ra rằng những điều đó có thể không cần thiết, nhưng tôi không nghĩ điều đó có liên quan đến vấn đề hiện tại của tôi.

Ngoài ra, do cách thức triển khai, tệp cấu hình đó sẽ mất rất nhiều công việc để thay đổi, vì vậy tôi hy vọng rằng không có gì thực sự phải thay đổi. Tôi hy vọng rằng đây là trường hợp tôi không hiểu NTP hoạt động như thế nào.


BIÊN TẬP -

Vì vậy, có vẻ như đây là một bản sao của Câu hỏi này , nhưng tôi không cảm thấy rằng poster đã có câu trả lời đầy đủ, vì vậy tôi vẫn muốn biết tại sao giờ địa phương lại được ưa thích hơn máy chủ. Ngoài ra, theo một trong những câu trả lời dưới đây, tôi đã thử sử dụng prefertừ khóa trên dòng máy chủ của cấu hình và khởi động lại, nhưng dường như điều đó không có tác dụng.

Nếu tôi loại bỏ tất cả các dòng "cục bộ" trong cấu hình làm câu trả lời cho câu hỏi khác, điều gì sẽ xảy ra nếu máy chủ không thể truy cập được? NTP có chết không hay nó cứ tiếp tục cố gắng?


EDIT QUAN TRỌNG -

Ok, thông thường, 10.130.33.201 ("Máy chủ") không có quyền truy cập vào internet và không có nguồn thời gian GPS để sử dụng. Phần quan trọng là tất cả các thiết bị trên hệ thống có cùng thời gian với máy chủ, bất kể thời gian đó thực sự chính xác đến mức nào.

Vì vậy, chỉ để xem điều gì sẽ xảy ra, tôi đã thêm một trong các máy chủ nhóm NTP vào tệp cấu hình của máy chủ để nó có thời gian từ đó thay vì nhận thời gian từ cục bộ. Bây giờ nó chính xác nhận được thời gian từ máy chủ thời gian NTP.

Sau khi tôi làm điều đó, các máy khách bây giờ đồng bộ hóa với máy chủ thay vì thích LOCAL (0)

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

CÂU HỎI MỚI - Khi máy chủ của tôi đang sử dụng cục bộ (ví dụ ban đầu đã được cung cấp), có vẻ như các khách hàng đang nói: "Ồ, 10.130.33.201 đang sử dụng máy chủ LOCAL (0). Hmm, tôi cũng có máy chủ LOCAL (0) - - Tôi sẽ chỉ sử dụng trực tiếp thay vì nhận thông tin tương tự qua 10.130.33.201 ".

Có phải vậy không? Có phải họ đang cố gắng "trực tiếp đến nguồn" không chính xác LỘC (0)? Tôi cần máy chủ của mình để có thời gian từ LOCAL (0) và tôi cần khách hàng lấy thời gian từ máy chủ. Ngay bây giờ loại bỏ máy chủ "cục bộ" khỏi các tệp cấu hình máy khách là tùy chọn duy nhất, nhưng tôi muốn hiểu tại sao điều này xảy ra, và nếu có thể, hãy tránh thay đổi cấu hình của chúng (thay đổi cấu hình sẽ rất nhiều việc vì môi trường của chúng ta...).

Ngoài ra, điều này trông giống như một bản sao khác mà không có câu trả lời tốt.


Ngoài ra, nếu bạn luôn có quyền truy cập mạng vào 10.130.33.201, hãy cân nhắc xóa nguồn đồng hồ cục bộ.
Aaron Copley

Câu trả lời:


9

Chỉ với một máy chủ NTP được cấu hình, thuật toán không hoàn toàn chắc chắn ai sẽ tin tưởng. Mặc dù, tầng thấp hơn với máy chủ từ xa, tôi cá rằng thuật toán cho rằng giờ địa phương đáng tin cậy hơn.

Hãy thử sử dụng prefertừ khóa với servertuyên bố của bạn để đặt đó làm nguồn thời gian ưu tiên.


BIÊN TẬP -

Vì vậy, có vẻ như đây là một bản sao của Câu hỏi này, nhưng tôi không cảm thấy rằng poster đã có câu trả lời đầy đủ, vì vậy tôi vẫn muốn biết tại sao giờ địa phương lại được ưa thích hơn máy chủ.

Đối với một câu trả lời thực sự đầy đủ, bạn sẽ đào sâu vào ruột của một thuật toán rất phức tạp. Tài liệu thậm chí không quá cụ thể nhưng tôi chắc chắn có một tờ giấy trắng hoặc thông số kỹ thuật ngoài kia.

Nếu tôi loại bỏ tất cả các dòng "cục bộ" trong cấu hình làm câu trả lời cho câu hỏi khác, điều gì sẽ xảy ra nếu máy chủ không thể truy cập được? NTP có chết không hay nó cứ tiếp tục cố gắng?

Trình nền NTP không chết hoặc dừng, nhưng nó thoát thời gian đồng bộ hóa sau khi không đến được máy chủ từ xa. Đây là lý do tại sao các thực tiễn tốt nhất sẽ đề xuất tối thiểu ba máy chủ từ xa và không sử dụng LCL trừ khi bạn bị ngắt kết nối mạng. Ba máy chủ được đề xuất bởi vì khi chỉ có hai, và họ không đồng ý, họ sẽ chọn cái nào? Máy chủ thứ ba sẽ giúp thuật toán loại bỏ máy chủ không có thật.

Cuối cùng, tôi chỉ nhận thấy rằng bạn không xác định a driftfile. Điều này có thể giúp?


Liệu sự khác biệt giữa hai tầng lớp (ums?) Có ảnh hưởng gì đến điều này không? Sẽ có máy chủ thấp hơn 9 giúp đỡ?
JPhi1618

Nó có thể. Phải thừa nhận rằng, tôi không biết nhiều về nội bộ của thuật toán. Tuy nhiên, trường hợp duy nhất mà bạn nên fudge tầng là với đồng hồ địa phương. Tôi không thể khuyên bạn nên sửa máy chủ từ xa để khắc phục. NTP nên được tin cậy để xác định nguồn tốt nhất với nhiễu tối thiểu. Bạn chỉ cần có một trường hợp mà bạn cần phải đẩy nó một chút.
Aaron Copley

Cảm ơn những lời đề nghị. Có một driftfile, nhưng nó không được tạo ra nên tôi gỡ bỏ để xem điều gì sẽ xảy ra. Xóa dòng cục bộ sẽ làm cho nó đồng bộ hóa với máy chủ, vì vậy đó là một cái gì đó. Bạn nói rằng ntpd sẽ "bỏ thời gian đồng bộ hóa sau khi nó không đến được máy chủ từ xa", nhưng nó sẽ bắt đầu lại sau khi máy chủ đạt được? Tôi chỉ muốn được an toàn trong trường hợp gián đoạn mạng tạm thời.
JPhi1618

Không, nó sẽ không bắt đầu lại. Nó chỉ bỏ cuộc. Điều này thật khó chịu và cũng là một trò hề đối với tôi. Chúng tôi biết bây giờ để khởi động lại NTP nếu kết nối mạng bị mất. Driftfile của bạn có thể không được tạo vì ntp không có quyền đối với đường dẫn. Kiểm tra kỹ xem.
Aaron Copley

7

Đối với tôi, có vẻ như khoảng thời gian bù (chênh lệch giữa thời gian hệ thống của bạn và thời gian lưu trữ của NTP) quá khác biệt đối với NTP để đặt đúng.

Đề xuất của tôi,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

Bạn sẽ không gặp vấn đề gì sau đó.


2
Nếu máy xảy ra là VM hoặc có một số điều kiện khác khiến máy bị hỏng thời gian nghiêm trọng, bạn có thể đặt tinker panic 0tùy chọn ntp để buộc NTP chấp nhận bất kỳ sự bù đắp nào. Nhưng chỉ sử dụng điều này với các máy chủ NTP, bạn chắc chắn sẽ không bao giờ trả lại thời gian xấu.
Zoredache

Ok, tôi nghĩ rằng nó phải được giảm hơn 1000 trước khi đó là một vấn đề, và sau đó tôi nghĩ rằng máy chủ sẽ được liệt kê với một dấu #? đây không phải là trường hợp à? Là "bù" trong vài giây hoặc mili giây?
JPhi1618

Nó sẽ không đồng bộ hóa với 10.130.33.201 ngay bây giờ vì độ lệch quá cao, nhưng điều này sẽ không khắc phục được thực tế là nó trôi đủ ở nơi đầu tiên mà LCL đang trở nên hấp dẫn hơn. Tôi nghĩ điều này, một driftfile đang hoạt động, và prefersẽ thực hiện các mẹo.
Aaron Copley

Bạn có thể giải thích tại sao độ lệch quá cao? Đó là ít hơn 1000 (cách ít hơn) và không có dấu #. Ngoài ra, tôi đã xác minh thời gian thực tế trên cả hai hệ thống và chúng cách nhau khoảng 4 giây.
JPhi1618

+/- 1000 ms ... không phải +/- 1000 s . Đó là ở -3742 ms .
Aaron Copley

2

Tầng của 10.130.33.201 với tư cách là máy chủ LOCAL là 9, làm cho tầng địa phương được tính từ này (9 + 1 = 10) cạnh tranh với máy chủ LOCAL cục bộ ở tầng 10. Vì tầng địa phương LOCAL không có độ trễ mạng hoặc jitter, nên nó có thể trông hơi tốt hơn đối với ntpd so với điều khiển từ xa.

Nếu bạn muốn cấu hình này hoạt động, hãy đặt máy chủ LOCAL 'master' ở tầng thấp hơn 9. Không quá thấp nếu bạn muốn có thời gian truy tìm đến máy chủ tầng 1 được ưu tiên.


Cảm ơn. Tôi sẽ kiểm tra điều này ngay khi tôi có thể. Trông đầy hứa hẹn.
JPhi1618

Chà, có vẻ như trước đây tôi đã cố gắng hạ tầng tầng của máy chủ LỘC 10.130.33.201. Hiện tại, nó được đặt thành 5, khách hàng xem nó là 6, nhưng vẫn thích ĐỊA PHƯƠNG của riêng mình có tầng 10. Cấu hình này đã được áp dụng trong nhiều ngày.
JPhi1618

2

Tôi biết điều này là cũ, nhưng tôi nghĩ bạn đúng. Không ai chỉ ra cách gỡ lỗi các vấn đề ntpd. Hóa ra là có thể làm được.

Tôi nghĩ rằng bạn đã đi đúng hướng khi bạn nghi ngờ rằng việc sử dụng LOCAL (0) cục bộ và trên máy chủ ngược dòng có thể là một vấn đề.

Đó chắc chắn là trên một hòn đảo thời gian gồm 4 máy chủ mà tôi gặp vấn đề tương tự. Tất cả đều được đặt là đồng nghiệp của nhau, vì vậy có thể là một vấn đề khác với bạn.

Trước hết, có một cách tốt hơn để xử lý các đảo thời gian được gọi là chế độ mồ côi được hỗ trợ với các phiên bản ntpd trong vài năm qua:

Chế độ mồ côi trên doc.ntp.org

Ban đầu cả 4 máy chủ đều có cùng một tầng 10 và thích đồng hồ cục bộ của họ. Tôi đã sửa nó và họ vẫn thích đồng hồ cục bộ của họ (tầng này dường như rất quan trọng).

Tôi đã sử dụng lệnh ntpq pe (ngang hàng), như, rv để có thể xử lý những gì đang xảy ra. Bạn cần sử dụng rv (readvar) trên số liên kết để máy chủ kết xuất thông tin. pe và dường như được sắp xếp theo cùng một chỉ mục để bạn có thể lấy số theo cách đó. như có một trường được gọi là điều kiện có thể hiển thị từ chối giá trị nếu nó không giống như máy chủ.

Trong đầu ra rv là một trường gọi là flash. Nếu tất cả đều tốt thì đây sẽ là con số không. Nếu không, đó là một bitmask (hiển thị ở dạng hex) của các vấn đề. Họ có thể được tìm kiếm ở đây:

giải mã nội bộ ntpd

Vấn đề tôi gặp phải là 0800 ngang hàng. Nó chỉ ra rằng refid của đồng hồ là quan trọng. Nhìn thấy ĐỊA PHƯƠNG (0) cả trên đồng hồ cục bộ và từ máy chủ từ xa có ntpd nghĩ rằng có một vòng lặp. David Mills xác nhận rằng trong các bài đăng trên comp.prot Protocol.time'Làm thế nào để tránh vòng lặp trong NTP '(Tôi đã đạt đến giới hạn 2 liên kết của mình, xin lỗi!)

Sử dụng đối số refid để fudge để đặt refid duy nhất không hoạt động - nó vẫn hiển thị dưới dạng ĐỊA PHƯƠNG (0) tại người nhận.

Những gì dường như đã làm việc là sử dụng số hiệu duy nhất cho trình điều khiển cục bộ. 127.127.1. [0-3]. Sử dụng cùng một ID trên cả máy chủ và dòng fudge. Khi tôi làm điều này, các máy chủ thường được đồng bộ hóa với máy chủ tầng thấp nhất thường sử dụng đồng hồ cục bộ của nó. Tuy nhiên, đôi khi nó đã cố gắng sử dụng một trong những máy chủ khác đang sử dụng nó làm nguồn. Tuy nhiên thời gian đã đồng bộ và dường như vẫn ở đó.

Có lẽ đã quá muộn để giúp đỡ, nhưng tôi cung cấp nó để hiển thị NTP có thể tuân theo logic và xử lý sự cố. Tôi mất hàng giờ để đạt được câu trả lời bằng thử nghiệm và lỗi và sau đó tìm thấy các tài liệu sau đó.


-1

Sử dụng iburst để buộc máy chủ gửi yêu cầu NTP đến NTS mong muốn ngay cả khi một yêu cầu không thành công


Điều này cần một lời giải thích tốt hơn.
Sven
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.