Windows Server 2016의 시간 정확도 향상

Windows Server 2016은 현지 시계를 UTC(협정 세계시)와 동기화할 시간과 조건을 수정하는 데 사용하는 알고리즘을 개선했습니다. NTP(네트워크 시간 프로토콜)는 4개의 값을 사용하여 클라이언트 요청/응답 및 서버 요청/응답의 타임스탬프를 기반으로 시간 오프셋을 계산합니다. 그러나 네트워크는 시끄럽고 네트워크 정체 및 네트워크 대기 시간에 영향을 주는 기타 요인으로 인해 NTP의 데이터가 급증할 수 있습니다. Windows Server 2016 알고리즘은 여러 가지 기술을 사용하여 이 노이즈를 평균화하여 안정적이고 정확한 클록을 생성합니다. 정확한 시간에 사용하는 원본은 향상된 API를 참조하여 더 나은 해상도를 제공합니다. 이러한 향상된 기능을 통해 할 일에서 UTC에 대해 1ms 정확도를 달성할 수 기본.

Hyper-V

Windows Server 2016은 Hyper-V TimeSync 서비스를 개선했습니다. 향상된 기능으로는 VM(가상 머신) 시작 시 보다 정확한 초기 시간 또는 Windows 시간 서비스(W32Time)에 제공된 샘플에 대한 VM 복원 및 인터럽트 대기 시간 수정이 포함됩니다. 이렇게 개선하면 부하가 75%인 컴퓨터에서도 루트 평균 정사각형(분산을 나타낸)이 있는 호스트의 10μs 이내를 유지할 수 있습니다. 자세한 내용은 Hyper-V 아키텍처를 참조하세요.

참고 항목

부하는 균형 잡힌 프로필을 사용하여 prime95 벤치마크를 사용하여 만들어졌습니다.

호스트가 게스트에게 보고하는 계층 수준이 더 투명합니다. 이전에는 호스트가 정확도에 관계없이 고정 계층 2를 표시했습니다. Windows Server 2016의 변경 내용으로 호스트는 호스트 Stratum보다 큰 Stratum 1을 보고하므로 가상 게스트에게 더 나은 시간을 제공합니다. 호스트 Stratum은 원본 시간에 따라 일반적인 수단을 통해 W32Time에 의해 결정됩니다. Windows Server 2016 게스트가 기본 가입한 게스트는 호스트를 기본값으로 설정하지 않고 가장 정확한 시계를 찾습니다. 이러한 이유로 Windows Server 2012 R2 및 이전 버전에서 할 일기본 참여하는 컴퓨터에 대해 Hyper-V 시간 공급자 설정을 수동으로 사용하지 않도록 설정하는 것이 좋습니다.

모니터링

성능 모니터 카운터가 추가되었습니다. 이러한 카운터를 사용하면 시간 정확도를 기준, 모니터링 및 해결할 수 있습니다. 다음 표에서는 카운터를 나열합니다.

카운터	설명
시간 오프셋을 계산합니다.	W32Time 서비스에서 마이크로초 단위로 계산한 시스템 클록과 선택한 시간 원본 간의 절대 시간 오프셋입니다. 새 유효한 샘플을 사용할 수 있는 경우 계산된 시간 샘플으로 표시 된 시간 오프셋으로 업데이트 됩니다. 이 시간은 로컬 시계의 실제 시간 오프셋입니다. W32Time은 이 오프셋을 사용하여 클록 보정을 시작하고 샘플 간의 계산 시간을 로컬 시계에 적용해야 하는 재기본ing 시간 오프셋으로 업데이트합니다. 폴링 간격이 낮은 이 성능 카운터(예: 256초 이하)를 사용하고 원하는 클록 정확도 제한보다 작은 카운터 값을 찾아 클록 정확도를 추적할 수 있습니다.
클럭 주파수 조정	절대 클록 주파수를 조정 하면 당 10 억 부분에는 W32Time가 로컬 시스템 시계를 변경 합니다. 이 카운터는 W32Time에서 수행한 작업을 시각화하는 데 도움이 됩니다.
NTP 왕복 지연	NTP 클라이언트가 서버로부터 응답을 마이크로초 단위로 수신하는 데 발생한 가장 최근의 왕복 지연입니다. 이 지연은 NTP 클라이언트에서 요청을 NTP 서버로 전송하고 서버에서 유효한 응답을 받는 사이에 경과된 시간입니다. 이 카운터는 NTP 클라이언트도 지연 특징을 결정 하는 데 도움이 됩니다. 더 크거나 다양한 왕복은 NTP 시간 계산에 노이즈를 추가할 수 있으며, 이로 인해 NTP를 통한 시간 동기화의 정확도에 영향을 줄 수 있습니다.
NTP 클라이언트 원본 수	NTP 클라이언트에서 사용 중인 NTP 시간 원본의 활성 수입니다. 이 숫자는 이 클라이언트의 요청에 응답하는 시간 서버의 활성 고유 IP 주소 수입니다. 이 숫자는 피어 이름의 DNS 확인 및 현재 연결 가능성에 따라 구성된 피어보다 크거나 작을 수 있습니다.
NTP 서버 들어오는 요청	NTP 서버에서 수신한 요청 수(requests/sec)입니다.
NTP 서버 나가는 응답	NTP 서버에서 응답한 요청 수(응답/초)입니다.

처음 세 개의 카운터는 정확도 문제를 해결하기 위한 대상 시나리오입니다. 자세한 내용은 이 문서의 뒷부분에 있는 시간 정확도 및 NTP 문제 해결 섹션을 참조하세요. 마지막 세 개의 카운터는 NTP 서버 시나리오를 다루며 부하를 확인하고 현재 성능을 기준으로 하는 경우에 유용합니다.

환경별 구성 업데이트

다음 표에서는 각 역할에 대한 Windows Server 2016과 이전 버전 간의 기본 구성 변경 내용을 설명합니다. 이제 Windows Server 2016 및 Windows 10 1주년 업데이트(빌드 14393)에 대한 설정이 고유하므로 별도의 열로 표시됩니다.

역할	설정	Windows Server 2016	Windows 10	Windows Server 2012 R2 Windows Server 2008 R2 Windows 10
독립 실행형/Nano 서버
	시간 서버	time.windows.com	해당 없음	time.windows.com
	폴링 주기	64-1024초	해당 없음	한 주에 한 번
	시계 업데이트 빈도	1초에 한 번	해당 없음	1시간마다 한 번
독립 실행형 클라이언트
	시간 서버	해당 없음	time.windows.com	time.windows.com
	폴링 주기	해당 없음	하루에 한 번	한 주에 한 번
	시계 업데이트 빈도	해당 없음	하루에 한 번	1시간마다 한 번
도메인 컨트롤러
	시간 서버	PDC/GTIMESERV	해당 없음	PDC/GTIMESERV
	폴링 주기	64-1024초	해당 없음	1,024 - 32,768초
	시계 업데이트 빈도	1초에 한 번	해당 없음	1시간마다 한 번
도메인 구성원 서버
	시간 서버	DC	해당 없음	DC
	폴링 주기	64 -1,024초	해당 없음	1,024 - 32,768초
	시계 업데이트 빈도	1초에 한 번	해당 없음	5분마다 한 번
도메인 구성원 클라이언트
	시간 서버	해당 없음	DC	DC
	폴링 주기	해당 없음	1,204 - 32,768초	1,024 - 32,768초
	시계 업데이트 빈도	해당 없음	5분마다 한 번	5분마다 한 번
Hyper-V 게스트
	시간 서버	호스트 및 시간 서버의 계층에 따라 최상의 옵션을 선택합니다.	호스트 및 시간 서버의 계층에 따라 최상의 옵션을 선택합니다.	호스트 기본값
	폴링 주기	위의 역할에 따라	위의 역할에 따라	위의 역할에 따라
	시계 업데이트 빈도	위의 역할에 따라	위의 역할에 따라	위의 역할에 따라

참고 항목

Hyper-V의 Linux의 경우 Linux에서 Hyper-V 호스트 시간을 사용하도록 허용 섹션 을 참조하세요.

증가 된 폴링 및 시계 업데이트 빈도의 영향

더 정확한 시간을 제공하기 위해 폴링 빈도 및 클록 업데이트에 대한 기본값이 증가하므로 작은 조정을 더 자주 할 수 있습니다. 이 변경으로 인해 UDP(사용자 데이터그램 프로토콜)/NTP 트래픽이 더 많이 발생합니다. 이러한 패킷은 작으므로 광대역 링크에 거의 또는 전혀 영향을 미치지 않아야 합니다. 이점은 더 다양한 하드웨어 및 환경에서 시간이 더 낫다는 것입니다.

배터리 지원 디바이스의 경우 폴링 빈도를 늘리면 문제가 발생할 수 있습니다. 배터리 디바이스가 꺼지는 동안 시간을 저장하지 않습니다. 다시 시작할 때 시계에 대한 빈번한 수정이 필요할 수 있습니다. 폴링 빈도를 늘리면 시계가 불안정해지고 더 많은 전력을 사용할 수도 있습니다. 클라이언트 기본 설정을 변경하지 않는 것이 좋습니다.

DC(Do기본 컨트롤러는 Active Directory에서 NTP 클라이언트의 업데이트 증가에 따른 곱한 효과에도 영향을 최소화해야 합니다기본. NTP는 다른 프로토콜에 비해 리소스 사용량이 훨씬 적고 한계 효과가 있습니다. Windows Server 2016의 증가된 설정에 영향을 받기 전에 다른 do기본 기능에 대한 제한에 도달할 가능성이 더 높습니다. Active Directory는 간단한 NTP보다 시간을 덜 정확하게 동기화하는 경향이 있는 보안 NTP를 사용합니다. PDC(기본 do기본 컨트롤러)에서 두 개의 Stratum 클라이언트로 확장할 수 있는지 확인했습니다.

신중한 계획으로 코어당 초당 NTP 요청 수가 100 개를 예약 해야 합니다. 예를 들어 각각 4개의 코어가 있는 4개의 DC로 구성된 do기본를 사용하면 초당 1,600개의 NTP 요청을 처리할 수 있습니다. 64초마다 한 번씩 시간을 동기화하도록 구성된 클라이언트가 10,000개이고 시간이 지남에 따라 요청이 균일하게 수신되는 경우 모든 DC에 걸쳐 10,000/64 또는 약 160개의 요청/초가 표시됩니다. 이 금액은 이 예제에 따라 1,600개의 NTP 요청/초 내에 쉽게 포함됩니다. 이러한 계획 권장 사항은 보수적이며 주로 네트워크, 프로세서 속도 및 부하에 따라 달라집니다. 언제나 그처럼 사용자 환경에서 기준 및 테스트가 있습니다.

DC가 40%를 초과하는 상당한 CPU 부하로 실행되는 경우 이 로드는 거의 확실하게 NTP 응답에 노이즈를 추가하고 사용자의 작업 시간 정확도에 영향을 줍니다기본. 마찬가지로 실제 결과 이해 하는 사용자 환경에서 테스트 해야 합니다.

시간 정확도 측정

Windows Server 2016의 시간 정확도를 측정하기 위해 다양한 도구, 메서드 및 환경을 사용했습니다. 측정 하 고 환경 조정 정확도 결과 요구 사항을 충족 하는지 확인할 이러한 기법을 사용할 수 있습니다.

방법

우리의 할기본 소스 시계는 GPS 하드웨어와 두 개의 정밀도 NTP 서버로 구성. 또한 측정을 위해 별도의 참조 테스트 머신을 사용했으며, 다른 제조업체에서 설치한 정밀도 GPS 하드웨어도 있습니다. 일부 테스트의 경우 할 일기본 클록 원본 외에 참조로 사용할 정확하고 신뢰할 수 있는 시계 원본이 필요합니다.

실제 및 가상 컴퓨터를 모두 사용 하 여 정확도 측정 하 4 가지의 다른 방법을 사용 했습니다. 여러 방법을 결과 유효성을 검사할 독립 수단을 제공 합니다.

1. 별도의 GPS 하드웨어가 있는 참조 테스트 머신에 대해 조건부로 지정된 w32tm로컬 시계를 측정합니다.

2. 스트립 차트를 사용하여 NTP 서버에서 클라이언트로 NTP ping을 W32tm 측정합니다.

3. 스트립 차트를 사용하여 클라이언트에서 NTP 서버로의 NTP ping을 W32tm 측정합니다.

4. TSC(타임스탬프를 카운터)를 사용하여 호스트에서 게스트로 Hyper-V 결과를 측정합니다. 이 카운터는 양쪽 파티션에 파티션과 시스템 시간 간에 공유 됩니다. VM에서 호스트 시간과 클라이언트 시간의 차이를 계산했습니다. 그런 다음 측정값이 동시에 발생하지 않으므로 TSC 클록을 사용하여 게스트의 호스트 시간을 보간했습니다. 또한 시간 구분 볼륨 클록을 사용하여 API의 지연 및 대기 시간을 고려했습니다.

W32tm는 기본 제공되지만 테스트 중에 사용한 다른 도구는 테스트 및 사용을 위한 오픈 소스 GitHub의 Microsoft 리포지토리에 사용할 수 있습니다. 도구를 사용하여 측정을 수행하는 방법에 대한 자세한 내용은 Windows 시간 보정 도구 Wiki를 참조하세요.

표시된 테스트 결과는 테스트 환경 중 하나에서 수행한 측정의 하위 집합입니다. 시간 계층 구조가 시작될 때 기본 정확도를 보여 줍니다기본 시간 계층 구조의 끝에 클라이언트가 수행됩니다. 이러한 결과는 비교를 위해 2012 기반 토폴로지의 동일한 컴퓨터와 비교됩니다.

토폴로지

비교를 위해 Windows Server 2012 R2 및 Windows Server 2016을 기반으로 토폴로지 테스트했습니다. 두 토폴로지 모두 설치 된 GPS 클록 하드웨어와 Windows Server 2016 컴퓨터를 참조 하는 두 개의 실제 Hyper-v 호스트 컴퓨터의 구성 됩니다. 각 호스트는 다음 토폴로지에 따라 정렬된 3개의 do기본 조인 Windows 게스트를 실행합니다. 줄은 시간 계층 구조와 사용되는 프로토콜/전송을 나타냅니다.

그래픽 결과 개요

다음 두 그래프는 이전 토폴로지 기반의 do기본의 두 특정 멤버에 대한 시간 정확도를 나타냅니다. 각 그래프에는 Windows Server 2012 R2 및 2016 결과가 모두 오버레이되어 시각적으로 향상된 기능을 보여 줍니다. 정확도는 호스트에 비해 게스트 컴퓨터 내에서 측정되었습니다. 그래픽 데이터는 수행한 전체 테스트 집합의 하위 집합을 나타내며 최상의 시나리오와 최악의 시나리오를 보여 줍니다.

루트 do기본 PDC의 성능

루트 PDC는 정확하고 안정적인 것으로 입증된 GPS 하드웨어가 있는 Windows Server 2016인 Hyper-V 호스트(VMIC 사용)와 동기화됩니다. 이 요구 사항은 설명선으로 식별되는 음영 영역으로 표시되는 1ms 정확도에 중요합니다.

자식 do기본 클라이언트의 성능

자식 do기본 클라이언트는 루트 PDC와 통신하는 자식 do기본 PDC에 연결됩니다. 해당 시간은 1ms 요구 사항 내에 있습니다.

장거리 테스트

다음 차트에서는 하나의 가상 네트워크 홉을 Windows Server 2016과 6개의 실제 네트워크 홉과 비교합니다. 서로 겹치는 데이터를 표시 하는 투명도 있는 두 개의 차트 위에 표시 됩니다. 네트워크 홉을 늘리면 대기 시간이 늘어나고 시간 편차가 커지게 됩니다. 차트가 확대되므로 음영 처리된 영역으로 표시되는 1ms 범위가 더 큽니다. 시간은 1에서 볼 수 있듯이 여러 홉 ms. 음의 방향으로 이동되어, 네트워크 비대칭을 보여줍니다. 모든 네트워크는 다르며 측정값은 많은 환경 요인에 따라 달라집니다.

정확한 시간 유지를 위한 모범 사례

정확한 시간 관리를 위해 다음 모범 사례를 따르세요.

반도체 원본 클록

컴퓨터의 시간은 동기화되는 원본 시계만큼만 좋습니다. 1ms의 정확도를 달성하려면 GPS 하드웨어 또는 마스터 소스 시계로 참조하는 네트워크 어플라이언스 시간이 필요합니다. 기본값 time.windows.com 을 사용하면 안정적이고 현지 시간 원본이 제공되지 않을 수 있습니다. 원본 시계에서 멀어질수록 네트워크는 정확도에 영향을 줍니다. 최상의 정확도를 위해서는 각 데이터 센터에 마스터 원본 시계가 있어야 합니다.

하드웨어 GPS 옵션

다양한 하드웨어 솔루션은 정확한 시간을 제공할 수 있습니다. 일반적으로 솔루션 오늘날 기반으로 GPS 안테나 합니다. 라디오 및 전화 접속 모뎀 솔루션은 전용 회선을 사용합니다. 네트워크에 어플라이언스 연결하거나 PCIe 또는 USB 디바이스를 통해 Windows와 같은 PC에 연결합니다. 다양한 옵션은 서로 다른 수준의 정확도를 제공하며, 언제나 그처럼 결과는 사용자 환경에 따라 달라집니다. 정확도에 영향을 주는 변수에는 GPS 가용성, 네트워크 안정성 및 부하 및 PC 하드웨어가 포함됩니다. 이러한 요소는 안정적이고 정확한 시간에 대한 요구 사항인 원본 시계를 선택할 때 모두 중요합니다.

수행기본 및 동기화 시간

도메인 구성원 컴퓨터를 확인 하려면 도메인 계층 구조를 사용 하 여 시간을 동기화 원본으로 사용 합니다. 각 do기본 멤버는 동기화할 다른 컴퓨터를 찾아서 시계 원본으로 저장합니다. 각 do기본 멤버 유형은 다른 규칙 집합을 따라 시간 동기화를 위한 시계 원본을 찾습니다. 포리스트 루트의 PDC는 모든 작업에 대한 기본 클록 소스입니다기본. 여기에 나열된 다양한 역할 및 원본을 찾는 방법에 대한 개략적인 설명은 다음과 같습니다.

• PDC 역할이 있는 컨트롤러 기본: 이 컴퓨터는 할 일기본 대한 신뢰할 수 있는 시간 원본입니다. 그것은 할 일에서 사용할 수있는 가장 정확한 시간이있다기본. GTIMESERV 역할이 사용되는 경우를 제외하고 부모 do기본 DC와 동기화해야 합니다.
• 다른 기본 컨트롤러: 이 컴퓨터는 할 일기본 클라이언트 및 멤버 서버의 시간 원본 역할을 합니다. DC는 자체 do기본 또는 부모 do기본 DC의 PDC와 동기화할 수 있습니다.
• 클라이언트/멤버 서버: 이 컴퓨터는 자체 수행의 DC 또는 PDC와 동기화할 수 있습니다기본 또는 부모 do기본 DC 또는 PDC.

사용 가능한 후보에 따라, 점수 매기기 가장 적합 한 시간 원본을 찾는 데 사용 됩니다. 이 시스템 시간 원본과 상대 위치의 안정성을 고려합니다. 이 검사 시간 서비스가 시작될 때 한 번 발생합니다. 시간 동기화 하는 방법을 세밀 하 게 제어 해야 하는 경우에 특정 위치에 좋은 시간 서버를 추가 하거나 중복을 추가할 수 있습니다. 자세한 내용은 GTIMESERV를 사용하여 로컬 신뢰할 수 있는 시간 서비스 지정 섹션을 참조하세요.

혼합 OS 환경(Windows Server 2012 R2 및 Windows Server 2008 R2)

최고의 정확도를 위해 순수 Windows Server 2016이 기본 환경이 필요하지만 혼합 환경에서는 여전히 이점이 있습니다. Windows Server 2012에 Windows Server 2016 Hyper-V를 배포하면기본 멘션 개선되었으나 게스트가 Windows Server 2016에 있는 경우에만 게스트에게 도움이 됩니다. Windows Server 2016 PDC는 향상된 알고리즘으로 인해 보다 정확한 시간을 제공할 수 있으므로 보다 안정적인 원본입니다. PDC를 바꾸는 것은 옵션이 아닐 수 있으므로 대신 GTIMESERV 롤 집합을 사용하여 Windows Server 2016 DC를 추가할 수 있습니다. 이는 사용자의 작업 정확도에 대한 업그레이드입니다기본. Windows Server 2016 DC는 다운스트림 시간 클라이언트에 더 나은 시간을 제공할 수 있지만 원본 NTP 시간만큼만 좋습니다.

또한 설명한 대로 클록 폴링 및 새로 고침 빈도는 Windows Server 2016에서 수정되었습니다. 이러한 빈도는 수동으로 하위 수준 DC로 변경하거나 그룹 정책을 통해 적용할 수 있습니다. 이러한 구성을 테스트하지는 않았지만 Windows Server 2008 R2 및 Windows Server 2012 R2에서 제대로 작동하며 몇 가지 이점을 제공해야 합니다.

Windows Server 2016 이전 버전에서는 정확한 시간 유지에 여러 가지 문제가 발생하여 조정 후 즉시 시스템 시간이 드리프트되었습니다. 이 문제로 인해 정확한 NTP 원본에서 시간 샘플을 자주 가져오고 로컬 시계를 데이터로 컨디셔닝하면 샘플링 내 기간에 시스템 클록의 드리프트가 더 작아집니다. 결과적으로 하위 수준 OS 버전에서 더 나은 시간 유지가 제공됩니다. 가장 잘 관찰된 정확도는 정확도가 높은 설정으로 구성된 Windows Server 2012 R2 NTP 클라이언트가 정확한 Windows Server 2016 NTP 서버에서 시간을 동기화했을 때 약 5ms였습니다.

게스트 DC와 관련된 일부 시나리오에서 Hyper-V TimeSync 샘플은 작업기본 시간 동기화를 방해할 수 있습니다. 이 문제는 Windows Server 2016 Hyper-V 호스트에서 실행되는 Windows Server 2016 게스트에 대해 더 이상 존재하지 않아야 합니다.

Hyper-V TimeSync 서비스가 W32Time에 샘플을 제공하지 않도록 설정하려면 다음 게스트 레지스트리 키를 설정합니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Linux에서 Hyper-V 호스트 시간을 사용하도록 허용

Hyper-v에서 실행 하는 Linux 게스트에 대 한 클라이언트 NTP 서버에 대해 시간 동기화에 대 한 NTP 데몬을 사용 하 여 일반적으로 구성 됩니다. Linux 배포판에서 TimeSync 버전 4 프로토콜을 지원하고 Linux 게스트가 TimeSync 통합 서비스를 사용하도록 설정한 경우 호스트 시간과 동기화됩니다. 이 시나리오는 두 메서드를 모두 사용하는 경우 시간 유지가 일관되지 않게 될 수 있습니다.

호스트 시간에만 동기화하려면 다음 두 가지 방법 중 하나로 NTP 시간 동기화를 사용하지 않도록 설정하는 것이 좋습니다.

• 파일에서 ntp.conf NTP 서버를 사용하지 않도록 설정합니다.
• NTP 디먼을 사용하지 않도록 설정합니다.

이 구성에서는 시간 서버 매개 변수는이 호스트입니다. 폴링 빈도 5 초 및 시계 업데이트 빈도 5 초도 합니다.

NTP를 통해서만 동기화하려면 게스트에서 TimeSync 통합 서비스를 사용하지 않도록 설정하는 것이 좋습니다.

참고 항목

Linux 게스트를 사용하여 정확한 시간을 지원하려면 최신 업스트림 Linux 커널에서만 지원되는 기능이 필요합니다. 이 기능은 아직 모든 Linux 배포판에서 널리 사용할 수 없습니다. 지원 배포에 대한 자세한 내용은 Windows에서 Hyper-V용 지원되는 Linux 및 FreeBSD 가상 머신을 참조 하세요.

GTIMESERV를 사용하여 로컬 신뢰할 수 있는 시간 서비스 지정

Good Time Server 플래그 GTIMESERV를 사용하여 하나 이상의 DC를 정확한 원본 시계로 지정할 수 있습니다. 예를 들어 GPS 하드웨어가 장착된 특정 DC는 GTIMESERV로 플래그를 지정할 수 있습니다. 이 플래그는 할 일기본 GPS 하드웨어를 기반으로 시계를 참조하도록 합니다.

참고 항목

do기본 플래그에 대한 자세한 내용은 MS-ADTS 프로토콜 설명서를 참조하세요.

TIMESERV는 컴퓨터가 현재 신뢰할 수 있는지 여부를 나타내는 또 다른 관련 Do기본 Services 플래그이며, DC에서 연결이 끊어지면 변경될 수 있습니다. 이 상태의 DC는 NTP를 통해 쿼리할 때 반환됩니다 Unknown Stratum . 여러 번 시도한 후 DC는 시스템 이벤트 시간 서비스 이벤트 36을 기록합니다.

DC를 GTIMESERV로 구성하려면 다음 명령을 사용하여 수동으로 구성합니다. 이 경우 DC는 다른 컴퓨터를 마스터 클록으로 사용합니다. 이 컴퓨터는 어플라이언스 또는 전용 컴퓨터일 수 있습니다.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

참고 항목

자세한 내용은 Windows 시간 서비스 구성을 참조 하세요.

DC에 GPS 하드웨어가 설치된 경우 다음 단계를 사용하여 NTP 클라이언트를 사용하지 않도록 설정하고 NTP 서버를 사용하도록 설정합니다.

먼저 NTP 클라이언트를 사용하지 않도록 설정하고 다음 레지스트리 키 변경 내용을 사용하여 NTP 서버를 사용하도록 설정합니다.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

다음으로 Windows 시간 서비스를 다시 시작합니다.

net stop w32time && net start w32time

마지막으로 이 컴퓨터에 신뢰할 수 있는 시간 원본이 있음을 나타냅니다.

w32tm /config /reliable:yes /update

변경 내용이 제대로 수행되었는지 검사 다음 명령을 실행합니다. 이 명령은 여기에 표시된 결과에 영향을 줍니다.

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

타사 가상 플랫폼의 Windows Server 2016

Windows가 가상화되면 기본적으로 하이퍼바이저는 시간 제공을 담당합니다. 그러나 active Directory가 제대로 작동하려면 기본 조인된 멤버를 DC와 동기화해야 합니다. 게스트와 타사 가상 플랫폼의 호스트 간에 언제든지 가상화를 사용하지 않도록 설정하는 것이 가장 좋습니다.

계층 구조 검색

마스터 클록 원본에 대한 시간 계층 구조 체인은 기본 동적이므로 특정 컴퓨터의 상태 쿼리하여 시간 원본을 이해하고 마스터 원본 시계에 연결해야 합니다. 이 정보는 시간 동기화 문제를 진단하는 데 도움이 될 수 있습니다.

특정 클라이언트의 문제를 해결하려는 경우 첫 번째 단계는 다음 w32tm 명령을 사용하여 시간 원본을 이해하는 것입니다.

w32tm /query /status

결과는 무엇보다도 원본을 표시합니다. 원본은 할 일에서 시간을 동기화하는 사용자를 나타냅니다기본. 이 컴퓨터의 시간 계층 구조의 첫 번째 단계입니다. 다음으로, 이전 명령의 원본 항목을 사용하고 매개 변수를 /stripchart 사용하여 체인에서 다음 시간 원본을 찾습니다.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

또한 다음 명령은 지정된 do기본에서 찾을 수 있는 각 DC를 나열하고 각 파트너를 결정할 수 있는 결과를 출력합니다. 이 명령에는 수동으로 구성된 컴퓨터가 포함됩니다.

w32tm /monitor /domain:my_domain

목록을 사용하여 do기본 통해 결과를 추적하고 각 단계의 계층 구조 및 시간 오프셋을 이해할 수 있습니다. 여기서의 시간 오프셋 악화 크게 지점 두어의 잘못 된 경우 루트를 확인할 수 있습니다. 여기에서 로깅을 켜 w32tm 서 해당 시간이 잘못된 이유를 이해할 수 있습니다.

그룹 정책 사용

예를 들어 특정 NTP 서버를 사용하도록 클라이언트를 할당하거나 가상화할 때 하위 수준 운영 체제를 구성하는 방법을 제어하도록 할당하여 그룹 정책을 사용하여 더 엄격한 정확도를 달성할 수 있습니다. 가능한 시나리오 및 관련 그룹 정책 설정 목록은 다음과 같습니다.

가상화된 do기본s: Windows Server 2012 R2에서 가상화된 DC를 제어하여 Hyper-V 호스트가 아닌 기본 시간을 동기화하려면 이 레지스트리 항목을 사용하지 않도록 설정할 수 있습니다. PDC의 경우 Hyper-V 호스트가 가장 안정적인 시간 원본을 제공하기 때문에 항목을 사용하지 않도록 설정하지 않습니다. 레지스트리 항목을 변경한 후 W32Time을 다시 시작해야 합니다.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

정확도 중요한 로드: 시간 정확도 중요한 워크로드의 경우 NTP 서버 및 폴링 및 클록 업데이트 빈도와 같은 관련 시간 설정을 컴퓨터 그룹을 구성할 수 있습니다. 이 작업은 일반적으로 do기본 의해 처리되지만 더 많은 제어를 위해 마스터 클록을 직접 가리키도록 특정 컴퓨터를 대상으로 지정할 수 있습니다.

그룹 정책 설정	새 값
NtpServer	ClockMasterName,0x8
MinPollInterval	6-64 초
MaxPollInterval	6
UpdateInterval	100 – 초당 한 번
EventLogFlags	3-모든 특수 한 시간 로깅

참고 항목

및 설정은 NtpServer Windows NTP 클라이언트 구성 설정을 사용하여 System\Windows 시간 서비스\시간 공급자 아래에 EventLogFlags 있습니다. 나머지 세 가지는 전역 구성 설정을 사용하여 System\Windows 시간 서비스 아래에 있습니다.

원격 정확도 중요한 부하 원격: 분기의 시스템에서 기본,예를 들어 소매 및 PCI(결제 신용 산업)의 경우 수동 NTP 시간 원본이 구성되지 않은 한 Windows는 현재 사이트 정보 및 DC 로케이터를 사용하여 로컬 DC를 찾습니다. 이 환경에 올바른 시간으로 빠르게 수렴을 사용 하 여 정확도의 1 초 필요 합니다. 이 옵션을 사용하면 W32Time에서 시계를 뒤로 이동할 수 있습니다. 이 동작이 허용 가능하고 요구 사항을 충족하는 경우 다음 정책을 만들 수 있습니다. 모든 환경과 마찬가지로 네트워크를 테스트하고 기준선으로 지정해야 합니다.

그룹 정책 설정	새 값
MaxAllowedPhaseOffset	1이지만 1초 이상인 경우 클록을 올바른 시간으로 설정합니다.

이 MaxAllowedPhaseOffset 설정은 전역 구성 설정을 사용하여 System\Windows 시간 서비스 아래에 있습니다.

참고 항목

그룹 정책 및 관련 항목에 대한 자세한 내용은 Windows 시간 서비스 도구 및 TechNet의 설정 문서를 참조하세요.

Azure 및 Windows IaaS 고려 사항

다음은 Azure 및 Windows IaaS(Infrastructure as a Service)에 대해 고려해야 할 몇 가지 사항입니다.

Azure 가상 머신: Active Directory 도메인 Services

Active Directory 도메인 Services를 실행하는 Azure VM이 기존 온-프레미스 Active Directory 포리스트의 일부인 경우 TimeSync(VMIC)를 사용하지 않도록 설정해야 합니다. 이 작업을 통해 포리스트의 모든 DC(물리적 및 가상)가 단일 시간 동기화 계층 구조를 사용할 수 있습니다. 자세한 내용은 Hyper-V에서 실행 기본 컨트롤러를 참조하세요.

Azure 가상 머신: Do기본 조인된 머신

기존 Active Directory 포리스트, 가상 또는 물리적 포리스트에 조인된 기본 컴퓨터를 호스팅하는 경우 게스트에 대해 TimeSync를 사용하지 않도록 설정하고 W32Time이 시간 Type=NTP5구성을 통해 DC와 동기화되도록 구성하는 것이 가장 좋습니다.

Azure 가상 머신: 독립 실행형 작업 그룹 컴퓨터

Azure VM이 할 일기본 조인되지 않고 DC가 아닌 경우 기본 시간 구성을 유지하고 VM을 호스트와 동기화하는 것이 좋습니다.

Windows 애플리케이션에 정확한 시간이 필요합니다.

Windows 애플리케이션에 정확한 시간이 필요한 경우 수행할 수 있는 몇 가지 작업은 다음과 같습니다.

타임 스탬프 API

시간이 경과하지 않고 UTC에 비해 가장 높은 정확도가 필요한 프로그램은 GetSystemTimePreciseAsFileTime API를 사용해야 합니다. 이 API를 사용하면 애플리케이션이 Windows 시간 서비스에 의해 조건화된 시스템 시간을 가져옵니다.

UDP 성능

트랜잭션에 UDP 통신을 사용하는 애플리케이션이 있고 대기 시간을 최소화하는 것이 중요한 경우 포트 기본 필터링 엔진에서 제외할 포트 범위를 구성하는 데 사용할 수 있는 몇 가지 관련 레지스트리 항목이 있습니다. 이 작업을 수행하면 대기 시간이 모두 향상되고 처리량이 증가합니다. 그러나 레지스트리를 변경 숙련 된 관리자에 게 제한 해야 합니다. 이 해결 방법은 방화벽으로 보호되는 포트를 제외합니다. 자세한 내용은 다음 참조를 참조하세요.

Windows Server 2012 및 Windows Server 2008의 경우 먼저 핫픽스를 설치해야 합니다. 자세한 내용은 Windows 8 및 Windows Server 2012에서 멀티캐스트 수신기 애플리케이션을 실행할 때 Datagram 손실을 참조하세요.

네트워크 드라이버 업데이트

일부 네트워크 공급업체에는 드라이버 대기 시간 및 UDP 패킷 버퍼링에 비해 성능을 향상시키는 드라이버 업데이트가 있습니다. UDP 처리량에 도움이 되는 업데이트가 있는지 확인하려면 네트워크 공급업체에 문의하세요.

감사 목적으로 로깅

시간 추적 규정을 준수하기 위해 로그, 이벤트 로그 및 성능 모니터 정보를 수동으로 보관 w32tm 할 수 있습니다. 나중에 보관 된 정보를 이전에 특정 시간에 대 한 준수를 증명 사용할 수 있습니다. 다음 요소는 정확도를 나타내는 데 사용됩니다.

1. 계산 시간 오프셋 성능 모니터 카운터를 사용하여 클록 정확도 이 카운터는 원하는 정확도 내의 클록을 보여줍니다.
2. 로그에서 찾고 Peer Response from 있는 w32tm 클록 소스입니다. 메시지 텍스트 다음에는 유효성을 검사할 참조 클록 체인의 다음 시간 원본과 다음을 설명하는 IP 주소 또는 VMIC가 있습니다.
3. 클록 조건은 로그를 w32tm 사용하여 발생 중인 유효성을 검사 ClockDispl Discipline: \*SKEW\*TIME\* 하여 상태. 이 상태 당시 활성 상태임을 w32tm 나타냅니다.

이벤트 로깅

전체 스토리를 얻으려면 이벤트 로그 정보도 필요합니다. 시스템 이벤트 로그를 수집하고 Time-Server, Microsoft-Windows-Kernel-Boot 및 Microsoft-Windows-Kernel-General에서 필터링하면 다른 영향으로 인해 시간이 변경되었는지(예: 제3자)를 검색할 수 있습니다. 외부 간섭을 피하기 위해 이러한 로그가 필요할 수 있습니다. 그룹 정책은 로그에 기록되는 이벤트 로그에 영향을 줄 수 있습니다. 자세한 내용은 이전 섹션 그룹 정책 사용을 참조하세요.

W32Time 디버그 로깅

감사 목적으로 사용하도록 설정 w32tm 하려면 다음 명령을 사용하여 시계의 주기적인 업데이트를 표시하고 원본 시계를 나타내는 로깅을 사용하도록 설정합니다. 새 로깅을 사용 하도록 서비스를 다시 시작 합니다.

자세한 내용은 Windows 시간 서비스에서 디버그 로깅 켜기를 참조 하세요.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

성능 모니터

Windows Server 2016 Windows 시간 서비스는 감사에 대한 로깅을 수집하는 데 사용할 수 있는 성능 카운터를 노출합니다. 이러한 카운터는 로컬 또는 원격으로 기록할 수 있습니다. 컴퓨터 시간 오프셋 및 왕복 지연 카운터를 기록할 수 있습니다. 다른 성능 카운터와 마찬가지로 System Center Operations Manager를 사용하여 원격으로 모니터링하고 경고를 만들 수 있습니다. 예를 들어 시간 오프셋이 원하는 정확도에서 드리프트될 때 경고를 사용하여 경고할 수 있습니다. 자세한 내용은 System Center 관리 팩을 참조하세요.

Windows 추적 가능성 예제

로그 파일에서 w32tm 두 가지 정보의 유효성을 검사하려고 합니다. 첫 번째는 로그 파일이 현재 조건 클록임을 나타내는 것입니다. 이 표시는 논쟁의 여지가 있는 시간에 Windows 시간 서비스에 의해 시계가 조건화되고 있음을 증명합니다.

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

기본 점은 접두사로 W32Time이 시스템 클록과 ClockDispln Discipline상호 작용하고 있다는 증거인 접두사 메시지가 표시된다는 것입니다.

다음으로, 현재 참조 시계로 사용 중인 원본 컴퓨터를 보고하는 논쟁의 여지가 있는 시간 전에 로그에서 마지막 보고서를 찾아야 합니다. 이 정보는 IP 주소, 컴퓨터 이름 또는 VMIC 공급자일 수 있습니다. 이 공급자는 Hyper-V의 호스트와 동기화 중임을 나타냅니다. 다음 예제에서는 10.197.216.105의 IPv4 주소를 제공합니다.

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

이제 참조 시간 체인에서 첫 번째 시스템의 유효성을 검사했으므로 참조 시간 원본에서 로그 파일을 조사하고 동일한 단계를 반복해야 합니다. 이 프로세스는 GPS와 같은 실제 시계 또는 NIST와 같은 알려진 시간 원본에 도달할 때까지 계속됩니다. 참조 시계가 GPS 하드웨어인 경우 제조된 로그도 필요할 수 있습니다.

네트워크 고려 사항

NTP 프로토콜 알고리즘은 네트워크의 대칭에 종속됩니다. 네트워크 홉 수를 늘리면 비대칭 확률이 증가합니다. 따라서 특정 환경에서 표시되는 정확도 유형을 예측하기가 어렵습니다.

windows Server 2016의 성능 모니터 및 새 Windows 시간 카운터를 사용하여 환경의 정확도를 평가하고 기준을 만들 수 있습니다. 문제 해결을 수행하여 네트워크에 있는 컴퓨터의 현재 오프셋을 확인할 수도 있습니다.

네트워크를 통해 정확한 시간에 대한 두 가지 일반적인 표준이 있습니다.

• 정밀 시간 프로토콜 - IEEE 1588(PTP): PTP는 네트워크 인프라에 대한 요구 사항이 더 엄격하지만 종종 하위 마이크로즈컨드 정확도를 제공할 수 있습니다.
• 네트워크 시간 프로토콜 – RFC 1305(NTP): NTP는 더 다양한 네트워크 및 환경에서 작동하므로 관리하기가 더 쉽습니다.

Windows는 기본적으로 비도입 기본 조인된 컴퓨터에 대해 간단한 NTP(RFC2030)를 지원합니다. do기본 조인 머신의 경우 ms-SNTP라는 보안 NTP를 사용합니다. 이 NTP는 RFC1305 및 RFC5905 설명된 인증된 NTP보다 관리 이점을 제공하는 기본 협상된 비밀을 사용합니다.

do기본 및 nondo기본 조인 프로토콜 모두 UDP 포트 123이 필요합니다. NTP 모범 사례에 대한 자세한 내용은 네트워크 시간 프로토콜 모범 사례 IETF 초안을 참조하세요.

신뢰할 수 있는 하드웨어 클록(RTC)

특정 범위를 초과하지 않는 한 Windows는 시간을 단계별로 실행하지 않고 대신 시계를 적용합니다. 즉 w32tm , Windows Server 2016에서 기본적으로 1초로 설정되는 시계 업데이트 빈도 설정을 사용하여 시계의 빈도 를 정기적으로 조정합니다. 시계가 뒤에 있으면 빈도를 가속화합니다. 앞으로 진행되면 빈도가 느려집니다. 그러나 클록 빈도 조정 사이의 시간 동안 하드웨어 시계가 제어됩니다. 펌웨어 또는 하드웨어 시계에 문제가 있으면 머신의 시간 정확도가 떨어질 수 있습니다.

이 시나리오는 사용자 환경에서 테스트 및 기준이 필요한 또 다른 이유입니다. 계산된 시간 오프셋 성능 카운터가 대상으로 하는 정확도에서 안정화되지 않는 경우 펌웨어가 최신 상태인지 확인할 수 있습니다. 또 다른 테스트로 중복된 하드웨어가 동일한 문제를 재현하는지 확인할 수 있습니다.

시간 정확도 및 NTP 문제 해결

계층 구조 검색 섹션을 사용하여 부정확한 시간의 원인을 파악할 수 있습니다. 시간 오프셋을 살펴보면 계층 구조에서 시간이 NTP 원본과 가장 많은 차이를 보이는 지점을 찾습니다. 계층 구조를 이해하면 특정 시간 원본이 정확한 시간을 받지 못하는 이유를 이해하려고 합니다.

시간이 서로 다른 시스템에 집중하면 다음 도구를 사용하여 문제를 확인하고 해결 방법을 찾는 데 도움이 되는 추가 정보를 수집할 수 있습니다. 참조는 UpstreamClockSource 다음을 사용하여 w32tm /config /status검색된 클록입니다.

• 시스템 이벤트 로그
• 를 사용하여 로깅 사용 w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• w32Time 레지스트리 키 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• 로컬 네트워크 추적
• 성능 카운터(로컬 컴퓨터 또는 UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• 대기 시간 및 원본에 대한 홉 수를 이해하기 위한 PING UpstreamClockSource
• Tracert UpstreamClockSource

문제	증상	해결
로컬 TSC 클록은 안정적이지 않습니다.	여러 100us의 1-2 분 마다 여전히 있지만 Perfmon-물리적 컴퓨터 동기화 클록 안정적인 시계를 사용 하 여 표시 합니다.	펌웨어를 업데이트하거나 다른 하드웨어가 동일한 문제를 표시하지 않는지 확인합니다.
네트워크 대기 시간	w32tm 10ms RoundTripDelay 를 초과하는 스트립 차트가 표시됩니다. 지연의 변화로 인해 왕복 시간의 절반만큼 큰 노이즈가 발생할 수 있습니다. 예를 들어 한 방향으로만 지연될 수 있습니다. UpstreamClockSource 는 PING에 표시된 대로 여러 홉입니다. TTL 128 가까워야 합니다. Tracert를 사용 하 여 각 홉에서 대기 시간을 찾을 수 있습니다.	시간에 대 한 자세히 클럭 소스를 찾습니다. 한 가지 해결 방법은 동일한 세그먼트에 원본 시계를 설치하거나 지리적으로 가까운 원본 시계를 수동으로 가리키는 것입니다. 도메인 시나리오에 대 한 GTimeServ 역할이 있는 컴퓨터를 추가 합니다.
NTP 원본에 안정적으로 연결할 수 없습니다.	W32tm /stripchart 간헐적으로 "요청 시간 초과"를 반환합니다.	NTP 원본이 응답하지 않습니다.
NTP 원본이 응답하지 않습니다.	NTP 클라이언트 원본 수, NTP 서버 들어오는 요청 및 NTP 서버 나가는 응답에 대한 Perfmon 카운터를 확인하고 기준과 비교하여 사용량을 확인합니다.	서버 성능 카운터를 사용하여 기준선을 참조하여 부하가 변경되었는지 확인합니다. 사항이 네트워크 정체 문제의 있습니까?
컨트롤러는 가장 정확한 클록을 사용하지 기본.	토폴로지 또는 최근에 추가 된 마스터 시간 클록에서 변경 됩니다.	이 경우 w32tm /resync /rediscover
클라이언트 시계가 표류하고 있습니다.	NTP 클라이언트 시간 원본 수 카운터가 1에서 0으로 이동한다는 것을 설명하는 로그 파일의 시스템 이벤트 로그 및/또는 텍스트의 Time-Service 이벤트 36.	업스트림 원본 문제를 해결하고 성능 문제가 발생하고 있는지 이해합니다.

기준선 시간

기본 설정은 네트워크의 성능과 정확도를 이해하고 문제가 발생할 때 향후 기준과 비교할 수 있도록 하는 것이 중요합니다. 루트 PDC 또는 GTIMESRV로 표시된 모든 머신의 기준을 지정하려고 합니다. 또한 모든 포리스트에서 PDC를 기준으로 하는 것이 좋습니다. 마지막으로 거리 또는 높은 부하와 같은 흥미로운 특성이 있는 중요한 DC 또는 머신을 선택하고 기준선을 선택합니다.

Windows Server 2016과 2012 R2를 기준으로 하는 데도 유용합니다. 그러나 Windows Server 2012 R2에는 성능 카운터가 없기 때문에 비교할 수 있는 도구만 w32tm /stripchart 있습니다. 동일한 특성을 가진 두 컴퓨터를 선택하거나 컴퓨터를 업그레이드하고 업데이트 후 결과를 비교해야 합니다. Windows 시간 측정 추 록 2016과 2012 간의 측정을 수행 하는 방법에 대 한 자세한 내용은 있습니다.

모든 W32Time 성능 카운터를 사용하여 적어도 일주일 동안 데이터를 수집합니다. 이 데이터는 시간이 지남에 따라 네트워크의 변형을 설명하기에 충분한 참조가 있고 시간 정확도가 안정적이라는 확신을 제공하기에 충분한 실행을 보장합니다.

NTP 서버 중복성

비도(nondo기본 조인된 컴퓨터 또는 PDC와 함께 사용되는 수동 NTP 서버 구성의 경우 둘 이상의 서버를 사용하는 것이 가용성의 경우 적절한 중복성 측정값입니다. 또한 모든 원본이 정확하고 안정적이라고 가정하면 더 나은 정확도를 제공할 수 있습니다. 그러나 토폴로지를 잘 설계하지 않았거나 시간 원본이 안정적이지 않으면 결과 정확도가 더 나빠질 수 있으므로 주의해야 합니다. W32Time에서 수동으로 참조할 수 있는 지원되는 시간 서버의 제한은 10입니다.

윤초

지구의 회전 기간은 기후 및 지질 학적 사건으로 인해 시간에 따라 달라집니다. 일반적으로 변형은 2년마다 약 1초입니다. 원자 시간의 변형이 너무 커질 때마다 1초(위쪽 또는 아래쪽)의 보정이 삽입되며, 이를 윤초라고 합니다. 이 삽입은 차이가 0.9초를 초과하지 않는 방식으로 수행됩니다. 이 보정은 실제 보정보다 6개월 전에 발표됩니다. Windows Server 2016 이전에는 Microsoft Time Service가 윤초를 인식하지 못했지만 외부 시간 서비스에 의존하여 이 문제를 처리했습니다. Windows Server 2016의 증가 시간 정확도, Microsoft 윤 초 문제에 대 한 더 적합 한 솔루션에서 작동 합니다.

보안 시간 시딩

서버 2016의 W32Time에는 보안 시간 시드 기능이 포함되어 있습니다. 이 기능은 나가는 SSL 연결의 대략적인 현재 시간을 결정합니다. 이 시간 값은 로컬 시스템 시계를 모니터링하고 총 오차를 수정하는 데 사용됩니다. 이 기능에 대한 자세한 내용은 이 블로그 게시물을 참조하세요. 시간 오프셋에 대한 모니터링을 포함하는 신뢰할 수 있는 시간 원본 및 잘 모니터링된 컴퓨터가 있는 배포에서는 보안 시간 시드 기능을 사용하지 않고 기존 인프라를 대신 사용하도록 선택할 수 있습니다.

기능을 사용하지 않도록 설정하려면 다음을 수행합니다.

1. 그룹 정책을 사용하여 관리 SecureTimeSeeding합니다. 다음 설정을 UtilizeSslTimeData참조하는 섹션을 참조하세요. Learn: Policy CSP - ADMX_W32Time.

2. 또는 레지스트리 값을 수동으로 설정할 수 있습니다. UtilizeSSLTimeData 레지스트리 구성 값을 0 특정 컴퓨터로 설정합니다.

   reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
   

3. 컴퓨터를 즉시 다시 부팅할 수 없는 경우 W32Time에 구성 업데이트에 대해 알릴 수 있습니다. 이 알림은 SSL 연결에서 수집된 시간 데이터에 따라 시간 모니터링 및 적용을 중지합니다.

   W32tm.exe /config /update
   

4. 머신을 다시 부팅하면 설정이 즉시 적용되고 SSL 연결에서 시간 데이터 수집이 중지됩니다. 후자의 부분에는 약간의 오버헤드가 있으며 성능 문제가 되어서는 안 됩니다.

5. 이 설정을 전체 do기본 적용하려면 W32Time 그룹 정책 설정 0 의 값을 설정하고 UtilizeSSLTimeData 설정을 게시합니다. 그룹 정책 클라이언트에서 설정을 선택하면 W32Time에 알림이 표시되고 SSL 시간 데이터를 사용하여 시간 모니터링 및 적용을 중지합니다. 각 컴퓨터가 다시 부팅되면 SSL 시간 데이터 수집이 중지됩니다. 기본 휴대용 슬림 노트북/태블릿 및 기타 장치가 있는 경우 이러한 컴퓨터를 이 정책 변경에서 제외할 수 있습니다. 이러한 장치는 결국 배터리 드레이닝에 직면하고 시간을 부트스트랩하기 위해 보안 시간 시드 기능이 필요합니다.