chrony vs. systemd-timesyncd – NTP 클라이언트와의 차이점과 사용 사례는 무엇입니까?

어떻게 든 오래된 질문 "ntpd vs. systemd-timesyncd-안정적인 NTP 동기화를 얻는 방법?" NTP 클라이언트의 관점에서 chrony와 systemd-timesyncd의 차이점에 대해 묻고 싶습니다 .

systemd-timesyncd는 다소 최소한의 ntp 클라이언트 구현이지만 chrony는 NTP 클라이언트를 포함하는 완전한 NTP 데몬 솔루션입니다.

우분투 바이오닉 비버 릴리즈 노트 는 다음과 같이 말합니다 :

간단한 시간 동기화를 위해 기본 시스템에는 이미 systemd-timesyncd가 제공됩니다. Chrony는 시간 서버 역할을하거나 광고가보다 정확하고 효율적인 동기화를 원하는 경우에만 필요합니다.

나는 사전 설치된 최소한의 도구를 사용하여 작업을 수행한다는 아이디어를 좋아하며 systemd-timesyncd가 내 사용 사례에 대해 작업을 수행 할 것이라고 확신하지만 여전히 궁금합니다.

• 정확도 측면에서이 둘의 실제 차이점은 무엇입니까?
• 효율성의 차이는 무엇입니까?
• NTP 클라이언트로 사용하기위한 "단순하지 않은"시간 동기화 요구 사항은 무엇입니까?

systemd NEWS 파일에서 systemd-timesyncd 의 발표는 Chrony 및 이와 유사한 도구와 비교하여이 도구의 차이점을 잘 설명합니다. (강조 광산) :

네트워크에서 시스템 시계를 동기화하기 위해 새로운 "systemd-timesyncd" 데몬이 추가되었습니다. SNTP 클라이언트를 구현합니다 . chrony 또는 NTP 참조 서버 와 같은 NTP 구현과 달리 이것은 클라이언트 측만 구현하며 하나의 원격 서버에서 시간을 쿼리하고 로컬 클럭을 동기화하는 데에만 집중 하여 완전한 NTP 복잡성을 방해하지 않습니다 . 네트워크 클라이언트에 NTP를 제공하거나 로컬 하드웨어 시계에 연결하려는 경우가 아니면이 간단한 NTP 클라이언트는 대부분의 설치에 적합해야합니다. [...]

이 설정은 서버 집합에있는 대부분의 호스트에 대한 일반적인 사용 사례입니다. 일반적으로 로컬 NTP 서버에서 동기화되며,이 서버는 하드웨어를 포함하여 여러 소스에서 동기화됩니다. systemd-timesyncd는 일반적인 사용 사례에 사용하기 쉬운 솔루션을 제공하려고합니다.

특정 질문을 해결하려고합니다.

정확도 측면에서이 둘의 실제 차이점은 무엇입니까?

여러 소스에서 동기화 데이터를 가져 와서 정확도를 높일 수 있다고 생각합니다. 특히 systemd-timesyncd의 지원되는 사용 사례가 아닙니다. 그러나 신뢰할 수있는 내부 네트워크에 연결된 중앙 NTP 서버에서 동기화 데이터를 얻는 데 사용하는 경우 여러 소스를 사용하는 것이 실제로 그다지 적합하지 않으며 단일 소스에서 좋은 정확도를 얻습니다.

로컬 네트워크와 동일한 데이터 센터에있는 신뢰할 수있는 서버에서 서버를 동기화하는 경우 NTP와 SNTP의 정확도 차이는 거의 없습니다. NTP는 RTT를 고려하여 시간 측정을 수행 할 수 있지만 RTT가 매우 작은 경우에는 그다지 도움이되지 않습니다. 즉, 빠른 로컬 네트워크와 가까운 시스템의 경우입니다. 사용중인 소스를 신뢰할 수있는 경우 여러 소스가 필요하지 않습니다.

효율성의 차이는 무엇입니까?

어떤 소스가 다른 소스보다 더 나은지 결정하지 않고 여러 소스의 정보를 결합 할 수 있으므로 단일 소스에서 동기화를 얻는 것이 여러 소스에서 얻는 것보다 훨씬 간단합니다. 알고리즘은 훨씬 단순하며 간단한 경우 CPU로드가 덜 필요합니다.

NTP 클라이언트로 사용하기위한 "단순하지 않은"시간 동기화 요구 사항은 무엇입니까?

위의 인용문에서 다루었지만, 어떤 경우에는 systemd-timesyncd가 다루지 않는 Chrony의 유스 케이스입니다.

• NTP 서버 실행 (다른 호스트가이 호스트를 동기화를위한 소스로 사용할 수 있도록)
• 여러 소스에서 NTP 동기화 정보 얻기 (인터넷의 공용 서버에서 해당 정보를받는 호스트에게 중요) 과
• 위성으로부터 정확한 시간 정보를 얻을 수있는 GPS 장치와 같은 특수 하드웨어를 포함하는 로컬 클록으로부터 동기화 정보를 얻는 것.

이러한 사용 사례에는 Chrony 또는 ntpd 또는 이와 유사한 것이 필요합니다.

다른 답변의 상태가 올 바르면 chronyNTP 및 systemd-timesyncdSNTP를 구현 합니다.

시간 서비스 클라이언트의 관점에서 :

SNTP는 구현하기가 훨씬 간단한 프로토콜입니다.
NTP는 시간에 따라 단계별 증분 / 수정을 허용합니다. NTP의 주요 장점 중 하나는보다 정확한 시간을 얻기 위해 응답의 RTT도 고려한다는 것입니다.

에서 https://www.meinbergglobal.com/english/faq/faq_37.htm

완전한 기능을 갖춘 NTP 서버 또는 클라이언트는 매우 높은 수준의 정확도에 도달하고 다른 수학적 및 통계적 방법과 부드러운 클럭 속도 조정을 사용하여 가능한 한 급격한 시간 단계를 피하지만 SNTP는 간단한 응용 프로그램에만 권장됩니다. 정확성과 신뢰성은 그다지 요구되지 않습니다. 드리프트 값을 무시하고 시스템 클럭 조정 방법을 단순화하는 방법 (종종 간단한 시간 단계)을 사용하여 SNTP는 전체 NTP 구현과 비교할 때 품질이 낮은 시간 동기화 만 달성합니다.

SNTP는 훨씬 간단한 접근 방식을 채택합니다. NTP 알고리즘의 많은 복잡성이 제거되었습니다. 많은 SNTP 클라이언트가 시간을 왜곡시키지 않고 단계적으로 진행합니다. 간단한 타임 스탬프가 필요한 많은 응용 프로그램에 적합합니다. 또한 SNTP에는 여러 NTP 서버를 모니터링하고 필터링하는 기능이 없습니다. 하나의 서버에 장애가 발생하면 목록의 다음 서버가 사용되는 간단한 라운드 로빈 방식이 종종 사용됩니다.

에서 https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP는 SNTP보다 훨씬 정확하고 정확하므로 대부분의 엔터프라이즈 응용 프로그램에서 사실상 승자가됩니다. 반면, SNTP의 단순성은 IP 카메라, DVR 및 일부 네트워크 스위치와 같은 것에 더 적합합니다. 이러한 유형의 하드웨어에는보다 복잡한 프로토콜을 처리 할 처리 리소스가 부족하지만 연결된 장치가 점점 강력 해짐에 따라 변경 될 수 있습니다.

SNTP의 주요 단점 중 하나는 기본적으로 네트워크 시간 프로토콜 (Network Time Protocol)과 같은 여러 소스에서 시간을 검색하여 더 정확하게 검색 할 수 없다는 것입니다.

하이퍼 바이저와 NTP 데몬이 VM 시간을 변경하려고 할 때 NTP보다 더 많은 문제를 발생시키는 SNTP 구현이 가상화에 있다는 것을 알 수있는 또 하나의 주요 요점입니다. 특히 잘못된 구성으로 인해 시간에 동의하지 않으면 둘 다 활성화되어 큰 문제가 발생할 수 있습니다. 유능한 시스템 관리자는 시간 동기화를 위해 한 가지 방법 만 활성 상태로 유지하지만 구성 오류로 인해 둘 다 활성 상태 일 수 있습니다.

PS systemd-timesyncd를 사용하지 않을 때는 권장되는 대안이되어서는 안됩니다 systemd.

chrony포크 형식은 ntpd아니지만 처음부터 구현됩니다. 전체 NTPv4 프로토콜 ( RFC5905 ) 의 클라이언트 및 서버 모드를 모두 구현합니다 . 기업 수준의 사용자에, 우리는 전통에서 추세 전환을보고있는 에 레드햇 (이후 RHEL 7)과 (SLES 15) 수세처럼.ntpdchrony

systemd-timesyncdSNTP 프로토콜 ( RFC4330 ) 클라이언트 모드 만 구현 하십시오. 따라서 복잡한 사용 사례는에서 다루지 않습니다 systemd-timesyncd. 예를 들어, SNTP는 기본적으로 NTP와 같이 여러 소스에서 시간을 검색하여 더 정확하게 만들 수 없습니다. 결과적으로 systemd-timesyncd만큼 높은 정밀도 시간을 제공 할 수 없습니다 chrony.