☰

가상 머신에서 NTP 서버를 실행할 때의 제한은 무엇입니까? (2010)

tag-icon • tag-icon virtualization ntp
가상 머신에서 NTP 서버를 실행할 때의 제한은 무엇입니까? (2010)

내 로컬 네트워크에 여러 Stratum 2 시간 서버를 설정하고 싶습니다. 가상 머신은 3개의 1U 서버를 구입하는 것보다 확실히 더 저렴한 방법입니다. 그렇게 하면 어떤 제한이 따르나요? 즉, 정확도가 어느 정도까지 부정적인 영향을 받습니까?

또한, 하드웨어 불규칙성을 완화하기 위해 이러한 로컬 시간 서버가 다른 물리적 시스템에 상주해야 한다는 것이 내 직감입니다. 이 직감이 맞나요?

편집하다 "가상 머신"으로는 그렇지 않다고 말해야 겠네요구체적으로평균VM웨어. 오히려 가상화된 인스턴스의 일반적인 개념을 의미했습니다.

답변1

지금은 2023년이고,이 질문에 대한 이전 답변은 모두 이제 잘못되었습니다.(그리고 적어도 2016년 후반부터), 적어도 Linux VM에 관한 한 말입니다. [아래 조언은 Windows VM에는 적용되지 않을 수 있습니다.]

2023년 이후에 이 글을 읽고 있다면 최대 20-100ms 정확도에 대한 2013년 이전 답변의 주장을 믿지 마십시오. 최신 VM의 시간 동기화는 LAN에서 1밀리초 미만의 정확도를 달성할 수 있으며 소비자급 인터넷 연결에서는 1밀리초에 근접합니다.

다음 ServerFault 질문에는 최신 토론이 포함되어 있습니다.

다음은 내 주장을 뒷받침하는 몇 가지 예시적인 오프셋 그래프(연대순으로 표시)입니다. 어떤 경우에는 원시 로그 파일이 아직 남아 있는데, 이를 스스로 조사하려는 누구에게나 기꺼이 제공할 것입니다. 각 인스턴스의 그래프 규모를 확인하세요.

  1. ntpd2016년 말 KVM 하이퍼바이저(일종의 Intel Xeon) 아래 OpenStack 프라이빗 클라우드에서 실행되는 VM :오프셋-kvm
  2. ntpd2020년 중반 독립형 KVM 호스트(Intel Celeron 1037U)에서 실행되는 VM :오프셋-kvm-셀러론
  3. 2021년 말에 실행되는 다수의 AWS t3a.micro(AMD) 인스턴스 :chronyd오프셋-aws-t3a
  4. 2021년 말에 실행되는 다수의 AWS t4g.micro(ARM) 인스턴스 :chronyd오프셋-aws-t4g
  5. 2022년 초에 실행되는 다수의 Azure Standard_B1s(Intel) 인스턴스 :chronyd오프셋-azure-b1s
  6. chronyd2022년 후반에 AWS ECS/Fargate(Intel)에서 실행되는 다수의 컨테이너 :오프셋 파게이트

답변2

간단한 사실은 2010년에도 VM 내 클럭 정확도가 여전히 매우 나쁘다는 것입니다. 이는 몇 가지 지점에서 발생하지만 가장 중요한 점은 시간 드리프트가 일정하지 않다는 것입니다. 드리프트 팩터는 시시각각 변합니다. NTP는 내부에 클럭 보상이 내장된 프로토콜이지만 정적 드리프트 요소가 내장되어 설계되었습니다. 예를 들어 물리적 시스템이 30일마다 12초를 잃는 경우 NTP는 이를 보상할 수 있으며 매우 잘 수행합니다. 그러나 해당 시스템이 30일마다 4~70초씩 손실을 입을 수 있다면 NTP는 해당 수준의 변화를 추적하는 데 능숙하지 않습니다.

NTP가 VM 환경을 따라가는 것을 정말 어렵게 만드는 것은 NTP가 보는 로컬 시계가 1분 동안 드리프트 요인을 변경할 수 있다는 것입니다. 상위 시간 소스를 확인하는 빈도에 따라 주요 드리프트 요인 변경이 발생하고 동기화가 훨씬 더 자주 중단될 수 있습니다. 동기화되지 않은 시간은 조직 전체에 걸쳐 연속적으로 발생합니다.

로컬 네트워크용 NTP는 메모리 공간이 매우 작은 상대적으로 영향이 적은 프로토콜이며 DNS 및 DHCP 서버와 같은 다른 네트워크 인프라 서버에 안전하게 피기백할 수 있습니다. 일부 라우터는 NTP 기능도 제공할 수 있으므로 해당 기능을 살펴보는 것이 좋습니다.

이상적으로는 각각 서로 다른 상위 계층 서버 세트와 동기화되는 별도의 위치에 있는 두 개의 별도 서버를 원합니다. 또한 두 시간 서버 모두 다른 서버를 '피어'로 사용하도록 구성하여 업스트림 시간 소스 중 하나가 잘못될 경우 시간 서비스에 대한 영향을 최소화하는 것도 매우 좋은 생각입니다. 계층 변경이 있지만 적어도 동기화되지 않은 것으로 보고되지는 않습니다. 마지막으로 업스트림 시간 제공자에게 친절하게 대하고 시간이 잘 설정되면 폴링 사이에 매우 오랜 시간이 걸리도록 서버를 구성하십시오. 이는 'server' 라인의 ​​'maxpoll' 매개변수이며 동기화 시도 간 2의 거듭제곱(초)입니다.

이를 위해 반드시 VM을 사용해야 한다면 이러한 NTP 서버를 3개 이상 설정하겠습니다. 각각은 다른 호스트에 있어야 하며, 가능하다면 다른 데이터 센터에 있어야 합니다. 방금 제안한 것처럼 서로 다른 시간 소스가 필요하며 서로 피어해야 합니다. 그런 다음 세 가지를 모두 상위 소스로 사용하도록 모든 NTP 클라이언트를 구성합니다. 네트워크 외부의 동기화 패킷과 네트워크상의 동기화 패킷 사이에 1시간 30분을 넘지 않도록 maxpoll 값이 충분히 낮은지 확인하십시오. 주어진 시간에 세 가지 중 적어도 하나가 동기화될 가능성이 높습니다. 한 명의 시간 호스트와만 대화할 수 있는 클라이언트의 경우 가끔씩 발생하는 동기화되지 않는 이벤트를 참아내면 됩니다. 전반적으로 이 시나리오의 시간 품질은 물리적 서버만큼 정확하지 않습니다.

만약 제가 추측해야 한다면 순수 VM 환경에서 합의 시간은 아마도 30~100ms 이내일 것이라고 말하고 싶습니다. 순수한 물리적 환경에서는 시간 서버가 안정화될 만큼 충분히 오랫동안 가동되면 합의 시간이 10ms 이내일 것입니다.

답변3

vmware 시간 관리 보기문서. VM에서 NTP 데몬을 실행하는 것은 아마도 좋은 생각이 아닐 것입니다. 특히 안정적인 시간이 필요한 경우에는 더욱 그렇습니다.

답변4

가상화된 환경에서 NTP를 실행하면 운 좋게도 20ms의 정확도를 얻을 수 있습니다(VMware를 사용하여 수행한 작업입니다). 가상화된 클록 왜곡은 특히 리소스 경합이 있는 가상화된 환경에서 좋지 않습니다.

얼마나 정확해야 하는지에 따라 다릅니다. 두 번째(웹 서버의 경우 EG)에만 관심이 있다면 리소스 경합이 없는 한 괜찮을 것입니다. 밀리초 단위의 정확성(예: 사용량이 많은 데이터베이스, 로그 서버, 연구 프로젝트)을 원한다면 가상화된 시간 서버를 잊어버리십시오.

NTP 서버는 항상 물리적 호스트에 있어야 합니다. 하나의 불량 서버가 풀에서 거부되도록 하려면 그 중 최소 3개가 풀에 피어링되어 있어야 합니다. 가능하다면 인터넷보다는 GPS나 기타 지역 Tier-0 소스에서 시간을 확보하세요.

관련 정보