어떻게 든, 그러나 정확히 오래된 질문을 토대로 구축하지는 않습니다."ntpd 및 systemd-timesyncd - 안정적인 NTP 동기화를 달성하는 방법은 무엇입니까?", NTP 측면에서 chrony와 systemd-timesyncd의 차이점에 대해 문의하고 싶습니다.고객.
systemd-timesyncd는 최소한의 ntp 클라이언트 구현인 반면 chrony는 NTP 클라이언트를 포함하는 완전한 NTP 데몬 솔루션이라는 것을 알고 있습니다.
우분투바이오닉 비버 수정 정보 기록다음을 진술하십시오.
간단한 시간 동기화가 필요한 경우 기본 시스템에는 이미 systemd-timesyncd가 함께 제공됩니다. Chrony는 시간 서버 역할만 하거나 보다 정확하고 효율적인 동기화를 원하는 경우에만 필요합니다.
나는 사전 설치된 최소한의 도구를 사용하여 작업을 수행하는 것을 좋아하며 systemd-timesyncd가 내 사용 사례에 맞게 작업을 수행할 것이라고 확신하지만 여전히 궁금합니다.
- 둘 사이의 실제 정확도 차이는 무엇입니까?
- 효율성의 차이는 무엇입니까?
- "간단하지 않은" 시간 동기화 요구 사항, NTP 클라이언트로서 chrony의 사용 사례는 무엇입니까?
답변1
이것systemd NEWS 파일의 systemd-timesyncd에 대한 공지Chrony 및 유사한 도구와 비교하여 이 도구의 차이점에 대한 좋은 설명입니다. (강조):
새로운 것"시스템 시간 동기화"네트워크의 시스템 시계를 동기화하는 데몬이 추가되었습니다. 그것은SNTP 클라이언트. NTP 구현과 대조적으로, 예를 들면 다음과 같습니다.만성병 환자또는 클라이언트만 구현하고 전체 NTP 복잡성과 관련이 없는 NTP 참조 서버,원격 서버에서 시간을 쿼리하고 로컬 시계를 동기화하는 데 집중하세요.. 네트워크 클라이언트에 NTP 서비스를 제공할 계획이 없거나 로컬 하드웨어 시계에 연결하려는 경우가 아니면 이 간단한 NTP 클라이언트가 대부분의 설치에 더 적합합니다. [...]
이 설정은 서버 팜에 있는 대부분의 호스트에 대한 일반적인 사용 사례입니다. 일반적으로 하드웨어를 포함할 수 있는 여러 소스에서 자체적으로 동기화되는 로컬 NTP 서버에서 동기화됩니다. systemd-timesyncd는 이러한 일반적인 사용 사례에 대해 사용하기 쉬운 솔루션을 제공하려고 시도합니다.
특정 문제를 해결해 보세요.
둘 사이의 실제 정확도 차이는 무엇입니까?
여러 소스에서 동기화 데이터를 가져오면 더 나은 정확성을 얻을 수 있다고 생각합니다. 이는 systemd-timesyncd에서 특별히 지원하지 않는 사용 사례입니다. 그러나 이를 사용하여 안정적인 내부 네트워크에 연결된 중앙 NTP 서버에서 동기화 데이터를 가져오는 경우 여러 소스를 사용하는 것은 실제로 그다지 관련이 없으며 단일 소스에서 좋은 정확도를 얻을 수 있습니다.
로컬 네트워크와 동일한 데이터 센터에 있는 신뢰할 수 있는 서버에서 서버를 동기화하는 경우, NTP와 SNTP의 정확도 차이는 거의 존재하지 않습니다. NTP는 RTT를 설명하고 시간 번짐을 수행할 수 있지만 RTT가 매우 작은 경우(예: 빠른 로컬 네트워크 및 근처 컴퓨터의 경우)에는 큰 도움이 되지 않습니다. 또한 사용 중인 소스를 신뢰할 수 있다면 여러 소스가 필요하지 않습니다.
효율성의 차이는 무엇입니까?
단일 소스에서 동기화하는 것은 여러 소스에서 동기화하는 것보다 훨씬 간단합니다. 어떤 소스가 다른 소스보다 나은지 결정하거나 여러 소스의 정보를 결합할 필요가 없기 때문입니다. 알고리즘은 훨씬 간단하며 간단한 경우에는 CPU 로드가 덜 필요합니다.
"간단하지 않은" 시간 동기화 요구 사항, NTP 클라이언트로서 chrony의 사용 사례는 무엇입니까?
이는 위의 인용문에서 해결되었지만 그럼에도 불구하고 다음은 systemd-timesyncd에서 다루지 않는 Chrony 사용 사례입니다.
- NTP 서버를 실행합니다(다른 호스트가 이 호스트를 동기화 소스로 사용할 수 있도록).
- 여러 소스에서 NTP 동기화 정보를 얻습니다. 이는 인터넷의 공용 서버에서 이 정보를 얻는 호스트에 중요합니다.
- 일반적으로 GPS 장치와 같은 특수 하드웨어가 포함된 로컬 시계에서 동기화 정보를 얻으면 위성에서 정확한 시간 정보를 얻을 수 있습니다.
이러한 사용 사례에는 Chrony 또는 ntpd 또는 이와 유사한 것이 필요합니다.
답변2
다른 답변이 올바르게 지적했듯이 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 데몬이 모두 가상 머신 시간을 변경하려고 할 때 SNTP 구현이 NTP보다 더 많은 문제를 일으킨다는 것입니다. 특히 시간이 일치하지 않고 일부 구성 오류로 인해 둘 다 활성화되면 큰 문제가 발생할 수 있습니다. (유능한 시스템 관리자는 한 가지 시간 동기화 방법만 활성 상태로 유지하지만 구성 오류로 인해 두 가지 방법을 동시에 활성화할 수도 있습니다.)
systemd-timesyncd사용하지 않을 때는 PS를 대안으로 권장하지 않습니다 systemd.
답변3
chrony분기된 형식이 아니라 ntpd처음부터 구현되었습니다. 두 가지 모두를 달성합니다.고객그리고섬기는 사람전체 NTPv4 프로토콜에 대한 모드(RFC5905). 엔터프라이즈 수준 사용자 사이에서는 레거시에서 ntpd벗어나 chronyRed Hat(RHEL 7 이상) 및 SuSE(SLES 15 이상)와 같은 경향을 보이고 있습니다.
systemd-timesyncdSNTP 프로토콜만 구현합니다(RFC4330)고객모델. 따라서 복잡한 사용 사례는 속하지 않습니다 systemd-timesyncd. 예를 들어 SNTP는 기본적으로 NTP처럼 여러 소스에서 시간을 검색하여 더 정확하게 만들 수 없습니다. 따라서 systemd-timesyncd동일한 고정밀 시간을 제공할 수 없습니다 chrony.