Windows Server 2016의 시간 정확도 향상

• 적용 대상:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2 and 22H2

Windows Server 2016은 시간을 수정하고 로컬 클록를 UTC(협정 세계시)와 동기화하기 위한 알고리즘을 개선했습니다. NTP(네트워크 시간 프로토콜)은 클라이언트 요청/응답 및 서버 요청/응답의 타임스탬프를 기반으로 시간 오프셋을 계산하기 위해 네 가지 값을 사용합니다. 그러나 네트워크는 노이즈가 많고, 네트워크 혼잡 및 네트워크 지연에 영향을 미치는 기타 요인으로 인해 NTP 데이터에 스파이크가 발생할 수 있습니다. Windows Server 2016 알고리즘은 여러 가지 기술을 사용하여 이러한 노이즈를 평균화하여 안정적이고 정확한 클록를 제공합니다. 정확한 시간을 제공하는 소스는 또한 개선된 API를 참조하여 더 나은 해상도를 제공합니다. 이러한 개선 사항을 통해 도메인 전체에서 UTC에 대해 1ms의 정확도를 달성할 수 있습니다.

Hyper-V

Windows Server 2016은 Hyper-v TimeSync 서비스를 개선시켰습니다. 개선 사항에는 VM(가상 머신) 시작 또는 VM 복원 시 더 정확한 초기 시간과 Windows 시간 서비스(W32Time)에 제공되는 샘플에 대한 인터럽트 지연 시간 보정이 포함됩니다. 이 개선 사항은 75% 부하가 걸린 머신에서도 루트 평균 제곱(분산을 나타냄) 50µs로 호스트와 10µs 이내에 머물 수 있게 합니다. 자세한 내용은 Hyper-V 아키텍처를 참조하세요.

참고 항목

부하는 균형 잡힌 프로파일을 사용하여 prime95 벤치마크를 통해 생성되었습니다.

호스트가 게스트에게 보고하는 Stratum 레벨이 더 투명해졌습니다. 이전에 호스트는 정확도에 관계없이 고정 계층 2를 제시했습니다. Windows Server 2016의 변경으로 호스트는 호스트 계층보다 1단계 더 큰 계층을 보고하며, 그로 인해 가상 게스트의 시간이 개선됩니다. 호스트 계층은 소스 시간을 기준으로 일반적인 수단을 통해 W32time에 의해 결정됩니다. 도메인 가입 Windows Server 2016 게스트는 호스트 기본값으로 설정하지 않고 가장 정확한 클록를 찾을 수 있습니다. 이러한 이유로, 도메인에 참여하는 Windows Server 2012 R2 및 이전 버전의 머신에 대해 Hyper-V 시간 공급자 설정을 수동으로 비활성화할 것을 권장합니다.

모니터링

성능 모니터 카운터가 추가 되었습니다. 이러한 카운터를 통해 시간 정확성의 기준을 설정하고, 모니터링하며, 문제를 해결할 수 있습니다. 다음 표는 카운터 목록을 보여 줍니다.

카운터	설명
시간 오프셋을 계산합니다.	시스템 클록과 선택된 시간 원본 간의 절대 시간 오프셋은 W32Time 서비스에 의해 마이크로초 단위로 계산됩니다. 새 유효한 샘플을 사용할 수 있는 경우 계산된 시간 샘플으로 표시 된 시간 오프셋으로 업데이트 됩니다. 이 시간은 이 로컬 클록의 실제 시간 오프셋입니다. W32Time은 이 오프셋을 사용하여 클록 보정을 시작하고, 샘플 간에 계산된 시간을 업데이트하며, 로컬 클록에 적용해야 하는 남은 시간 오프셋을 반영합니다. 클록 정확성은 이 성능 카운터를 사용하여 낮은 폴링 간격(예: 256초 이하)으로 추적할 수 있으며, 카운터 값이 원하는 클록 정확성 한계보다 작은지 확인하여 추적할 수 있습니다.
클럭 주파수 조정	절대 클록 주파수를 조정 하면 당 10 억 부분에는 W32Time가 로컬 시스템 시계를 변경 합니다. 이 카운터는 W32time에서 수행 중인 작업을 시각화 하는 데 도움을 줍니다.
NTP 왕복 지연	서버에서 응답을 받은 NTP 클라이언트에 발생한 가장 최근의 왕복 지연 시간(마이크로초)입니다. 이 지연 시간은 NTP 클라이언트가 NTP 서버에 요청을 전송하고 서버로부터 유효한 응답을 받는 데 걸리는 시간입니다. 이 카운터는 NTP 클라이언트도 지연 특징을 결정 하는 데 도움이 됩니다. 더 크거나 변동이 있는 왕복 시간이 NTP 시간 계산에 노이즈를 추가할 수 있으며, 이는 NTP를 통한 시간 동기화의 정확성에 영향을 미칠 수 있습니다.
NTP 클라이언트 원본 수	NTP 클라이언트에서 사용 중인 NTP 시간 활성 원본 수입니다. 이 숫자는 이 클라이언트의 요청에 응답하는 활성 시간 서버의 고유 IP 주소 수를 나타냅니다. 이 숫자는 피어 이름의 DNS 해상도와 현재 연결 가능성에 따라 구성된 피어 수보다 많거나 적을 수 있습니다.
NTP 서버 들어오는 요청	NTP 서버에 의해 수신 된 요청 수(요청/초)입니다.
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-1024초	해당 없음	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(도메인 컨트롤러)는 Active Directory 도메인에서 NTP 클라이언트의 업데이트 증가로 인한 배가된 영향에도 불구하고 최소한의 영향을 받아야 합니다. NTP는 다른 프로토콜에 비해 자원 소비가 훨씬 적으며, 그 영향도 미미합니다. Windows Server 2016의 설정 증가로 영향을 받기 전에 다른 도메인 기능의 한계에 도달할 가능성이 더 큽니다. Active Directory는 단순 NTP보다 시간을 덜 정확하게 동기화하는 경향이 있는 보안 NTP를 사용합니다. 우리는 이것이 PDC(기본 도메인 컨트롤러)로부터 두 계층 떨어진 클라이언트까지 확장할 수 있음을 확인했습니다.

신중한 계획으로 코어당 초당 NTP 요청 수가 100 개를 예약 해야 합니다. 예를 들어, 각 4개의 코어를 가진 4개의 도메인 컨트롤러(DC)로 구성된 도메인의 경우, 초당 1,600개의 NTP 요청을 처리할 수 있어야 합니다. 10,000개의 클라이언트가 64초마다 한 번씩 시간을 동기화하도록 구성되어 있고, 요청이 시간에 따라 균일하게 수신되는 경우, 모든 도메인 컨트롤러(DC)에 걸쳐 초당 약 160개의 요청(10,000/64)을 보게 될 것입니다. 이 예시를 기반으로 하면, 이 양은 우리의 초당 1,600개의 NTP 요청 범위 내에 쉽게 들어갑니다. 이러한 계획 권장 사항은 보수적이며 네트워크, 프로세서 속도 및 부하에 따라 크게 달라집니다. 항상 그렇듯, 사용자 환경에서 기준을 설정하고 테스트하세요.

DC가 40%보다 높은 CPU 부하 하에서 실행되는 경우 거의 확실하게 NTP 응답에 노이즈가 추가되어 도메인의 시간 정확도에 영향을 줍니다. 마찬가지로 실제 결과 이해 하는 사용자 환경에서 테스트 해야 합니다.

시간 정확도 측정

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

방법

우리 도메인 원본 클록을 GPS 하드웨어를 갖춘 두 개의 고정밀 NTP 서버로 구성되었습니다. 측정을 위해 별도의 참조 테스트 머신도 사용했으며, 이 머신에는 다른 제조사의 고정밀 GPS 하드웨어가 설치되어 있었습니다. 일부 테스트에서는 도메인 클록 원본 외에도 참조로 사용할 정확하고 신뢰할 수 있는 클록 원본이 필요합니다.

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

1. 로컬 클록를 w32tm에 의해 조정된 상태에서 별도의 GPS 하드웨어를 갖춘 참조 테스트 머신과 비교합니다.

2. NTP 서버에서 클라이언트로의 NTP 핑을 W32tm stripchart를 사용하여 측정합니다.

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

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

W32tm은 내장되어 있지만, 테스트 중에 사용한 다른 도구들은 GitHub의 Microsoft 저장소에서 오픈 소스로 제공되므로 테스트 및 사용이 가능합니다. 도구를 사용 측정법에 대한 더 자세한 내용은 Windows 시간 보정 도구 위키를 참조하세요.

보여지는 테스트 결과는 우리가 테스트 환경 중 하나에서 수행한 측정의 일부입니다. 이들은 시간 계층의 시작 부분에서 유지되는 정확도와 시간 계층의 끝에 있는 하위 도메인 클라이언트를 보여줍니다. 이 결과들은 비교를 위해 2012 기반 토폴로지의 동일한 머신들과 비교됩니다.

토폴로지

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

그래픽 결과 개요

다음 두 그래프는 앞서 언급한 토폴로지를 기반으로 도메인 내 두 특정 멤버의 시간 정확도를 나타냅니다. 각 그래프는 Windows Server 2012 R2와 2016 결과를 겹쳐서 표시하여 시각적으로 개선 사항을 보여줍니다. 정확도는 호스트와 비교하여 게스트 머신 내에서 측정되었습니다. 그래픽 데이터는 우리가 수행한 전체 테스트 세트의 일부를 나타내며, 최상의 경우와 최악의 경우를 보여줍니다.

루트 도메인 PDC의 성능

루트 PDC는 Hyper-V 호스트(VMIC 사용)에 동기화되며, 이는 정확하고 안정적인 것으로 입증된 GPS 하드웨어를 갖춘 Windows Server 2016입니다. 이 요구 사항은 1ms 정확도에 필수적이며, 이는 설명선에 의해 표시된 음영 영역으로 나타납니다.

하위 도메인 클라이언트의 성능

하위 도메인 클라이언트와 통신하는 루트 PDC는 하위 도메인 PDC에 연결 됩니다. 그 시간도 1ms 요구 사항 내에 있습니다.

장거리 테스트

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

정확한 시간 관리를 위한 모범 사례

이러한 정확한 시간 관리를 위한 모범 사례를 따르세요.

튼실한 원본 클록

머신 시간의 품질은 동기화되는 원본 클록의 품질에 달려 있습니다. 정확도 1ms를 달성하려면 네트워크에 마스터 원본 클록으로 참조하는 GPS 하드웨어 또는 시간 어플라이언스가 있어야 합니다. 기본값 time.windows.com 사용하면 안정적이고 로컬인 시간 원본이 제공되지 않을 수 있습니다. 원본 클록에서 멀어질수록 네트워크가 정확도에 영향을 미칩니다. 각 데이터센터에 마스터 원본 클록를 두는 것이 최고의 정확도를 보장합니다.

하드웨어 GPS 옵션

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

도메인 및 시간 동기화

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

• PDC 역할을 가진 도메인 컨트롤러: 이 머신은 도메인의 신뢰할 수 있는 시간 원본입니다. 도메인에서 사용할 수 있는 가장 정확한 시간을 가지고 있습니다. GTIMESERV 역할이 활성화된 경우를 제외하고는 상위 도메인의 DC와 동기화해야 합니다.
• 다른 도메인 컨트롤러: 이 머신은 도메인 내 클라이언트와 구성원 서버를 위한 시간 원본으로 작동합니다. DC는 자신의 도메인의 PDC와 동기화하거나 상위 도메인의 다른 DC와 동기화할 수 있습니다.
• 클라이언트/구성원 서버: 이 머신은 자신의 도메인 내의 모든 DC 또는 PDC와 동기화할 수 있으며, 상위 도메인의 DC 또는 PDC와도 동기화할 수 있습니다.

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

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

최고의 정확도를 위해서는 순수한 Windows Server 2016 도메인 환경이 필요하지만, 혼합 환경에서도 여전히 이점이 있습니다. Windows Server 2016 Hyper-V를 Windows Server 2012 도메인에 배포하면 앞서 언급한 개선 사항 덕분에 게스트에게 이점이 있지만, 이는 게스트도 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 2016 NTP 서버에서 시간을 동기화할 때, 높은 정확도 설정으로 구성된 Windows Server 2012 R2 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를 사용해서 신뢰할 수 있는 로컬 시간 서비스를 지정 합니다.

정확한 원본 클록으로 사용할 하나 이상의 DC를 지정하려면 Good Time Server 플래그인 GTIMESERV를 사용하면 됩니다. 예를 들어, GPS 하드웨어를 장착 하는 특정 DC는 GTIMESERV로 플래그 지정될 수 있습니다. 이 플래그는 도메인이 GPS 하드웨어를 기반으로 한 클록를 참조하도록 보장합니다.

참고 항목

도메인 플래그에 대한 자세한 정보는 MS-ADTS 프로토콜 설명서를 참조하세요.

TIMESERV는 도메인 서비스와 관련된 또 다른 플래그로, 머신이 현재 신뢰할 수 있는지 여부를 나타냅니다. 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

역시 유용한, 다음 명령 목록은 지정된 도메인에서 찾을 수 있는 각 도메인 컨트롤러(DC)를 나열하고, 각 파트너를 확인할 수 있는 결과를 출력합니다. 이 명령에는 수동으로 구성된 머신이 포함됩니다.

w32tm /monitor /domain:my_domain

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

그룹 정책 사용

그룹 정책을 사용하여 정확도를 더 높일 수 있습니다. 예를 들어 가상화할 때 특정 NTP 서버를 사용하도록 또는 하위 수준 OS를 구성하는 방법을 제어하도록 클라이언트를 할당할 수 있습니다. 여기에 가능한 시나리오 및 관련 그룹 정책 설정 목록이 있습니다:

가상화 도메인: Windows Server 2012 R2에서 가상화된 DC가 Hyper-V 호스트가 아닌 도메인과 시간을 동기화하도록 제어하려면, 다음 레지스트리 항목을 비활성화할 수 있습니다. PDC의 경우, Hyper-V 호스트가 가장 안정적인 시간 원본을 제공하기 때문에 해당 항목을 비활성화하지 않는 것이 좋습니다. 레지스트리 항목 데이터가 변경 되면 W32Time 재시작이 필요 합니다.

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

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

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

참고 항목

NtpServer 및 EventLogFlags 설정은 Windows NTP 클라이언트 구성 설정을 사용하여 System\Windows Time Service\Time Providers 아래 위치에서 발견됩니다. 다른 세 가지는 전역 구성 설정을 사용하면 System\Windows Time Service 아래 위치함을 알게 됩니다.

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

그룹 정책 설정	새 값
MaxAllowedPhaseOffset	1, 그러나 1초 이상이라면, 클록를 올바른 시간으로 설정합니다.

전역 구성 설정을 사용하면 System\Windows 아래 있는 시간 서비스 MaxAllowedPhaseOffset 설정이 찾아집니다.

참고 항목

그룹 정책 및 관련 항목에 대한 자세한 내용은 TechNet의 Windows Time 서비스 도구 및 설정 기사를 확인하세요.

Azure 및 Windows IaaS 고려 사항

다음은 Azure 및 Windows IaaS(서비스 제공 인프라)에 대해 고려해야 할 몇 가지 사항입니다.

Azure 가상 머신: Active Directory Domain Services

Active Directory Domain Services를 실행 중인 Azure VM이 기존 온-프레미스 Active Directory 포리스트에 포함된 경우 TimeSync(VMIC)를 비활성화 설정해야 합니다. 이 행동은 단일 시간 동기화 계층 구조를 사용하기 위해 실제 및 가상, 포리스트에서 모든 Dc를 허용 하도록 합니다. 더 자세한 내용은 Hyper-V에서 도메인 컨트롤러 실행을 참조하세요.

Azure 가상 머신: 도메인에 가입된 컴퓨터

기존 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에서 멀티캐스트 수신 애플리케이션을 실행 시 데이터그램 손실을 참조하세요.

네트워크 드라이버를 업데이트 하세요.

일부 네트워크 공급업체는 드라이버 대기 시간 및 UDP 패킷 버퍼링과 관련하여 성능을 향상시키는 드라이버 업데이트를 제공합니다. UDP 처리량을 개선할 수 있는 업데이트가 있는지 네트워크 공급업체에 문의하세요.

감사 목적 로깅

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

1. 계산 시간 오프셋 성능 모니터 카운터를 사용하여 클록 정확도를 확인할 수 있습니다. 이 카운터는 원하는 정확도 범위 안에서 클록를 표시 합니다.
2. w32tm 로그의 Peer Response from을 찾는 클록 원본입니다. 메시지 텍스트 다음에는 시간 원본와 검증할 참조 클록 체인의 다음 단계를 설명하는 IP 주소 또는 VMIC가 나옵니다.
3. w32tm 로그를 사용하여 ClockDispl Discipline: \*SKEW\*TIME\* 발생 유효성을 검사하는 클록 조건 상태입니다. 이 상태는 w32tm가 현재 활성화 되어 있다는 것을 나타냅니다.

이벤트 로깅

전체 스토리를 가져오려면, 이벤트 로그 정보도 필요 합니다. 시스템 이벤트 로그를 수집하고 Time-Server, Microsoft-Windows-Kernel-Boot 및 Microsoft-Windows-Kernel-General로 필터링하면, 예를 들어 타사와 같은 다른 요인이 시간을 변경했는지 확인할 수 있습니다. 외부 간섭을 피하기 위해 이러한 로그가 필요할 수 있습니다. 그룹 정책은 어떤 이벤트 로그가 로그에 기록 될지 여부에 영향을 줄 수 있습니다. 자세한 내용은 앞의 그룹 정책 사용 섹션을 참조하십시오.

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

주요 요점은 ClockDispln Discipline로 시작하는 메시지를 확인할 수 있다는 점이며, 이는 W32Time이 시스템 클록과 상호 작용하고 있음을 증명합니다.

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

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)를 지원합니다. 도메인에 가입된 머신의 경우, MS-SNTP라는 보안 NTP를 사용합니다. 이는 RFC1305 및 RFC5905에 설명된 인증된 NTP보다 관리상의 이점을 제공하는 도메인 협상 비밀을 사용합니다.

도메인 및 비도메인 가입 프로토콜 모두 UDP 포트 123을 필요로 합니다. NTP 모범 사례에 대한 자세한 내용은 네트워크 시간 프로토콜 현재 모범 사례 IETF 초안을 참조하세요.

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

Windows는 특정 한계를 초과하지 않는 한 시간을 조정하지 않고 대신 클록을 조율합니다. 이는 Windows Server 2016에서 w32tm이 기본적으로 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
• UpstreamClockSource PING해서 원본에 따라 대기 시간 및 홉 수 이해하기
• Tracert UpstreamClockSource

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

기준 시간

기준선을 설정하는 것은 네트워크의 성능과 정확성을 이해하는 데 중요합니다. 이렇게 하면 문제가 발생했을 때 기준선과 비교할 수 있습니다. 루트 PDC 또는 GTIMESRV로 표시된 모든 머신을 기준선으로 지정하는 것이 좋습니다. 모든 포리스트의 PDC에 대해서도 기준선을 설정하는 것을 권장합니다. 마지막으로, 거리나 높은 부하와 같은 흥미로운 특성을 가진 중요한 DC나 머신을 선택하여 기준선을 설정하세요.

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

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

NTP 서버 중복성

도메인 미가입 머신이나 PDC에서 사용하는 수동 NTP 서버 구성의 경우, 가용성을 대비해 두 개 이상의 서버를 사용하는 것이 좋은 중복성 대비책입니다. 모든 소스가 정확하고 안정적이라고 가정하면, 이는 더 나은 정확성을 제공할 수도 있습니다. 그러나 토폴로지가 잘 설계 되어있지 않거나 시간 원본이 안정적이지 못하면, 결과 정확도는 더 나쁠 수 있으니 주의가 필요합니다. W32Time이 수동으로 참조할 수 있는 지원되는 시간 서버의 한도는 10개입니다.

윤초

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

보안 시간 시딩

Server 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. 도메인 전체에서 이 설정을 적용하려면 W32time 그룹 정책 설정의 UtilizeSSLTimeData 값을 0으로 설정하고 설정을 게시합니다. 그룹 정책 클라이언트에서 이 설정을 선택하면 W32time 서비스에 알림이 전달되고 SSL 시간 데이터를 사용한 시간 모니터링 및 적용이 중지됩니다. 각 머신이 재부팅 될 때마다 SSL 시간 데이터 수집이 중지됩니다. 도메인에 휴대용 슬림 노트북/태블릿 및 기타 디바이스가 있는 경우 이 정책 변경에서 이러한 머신을 제외하는 것이 좋습니다. 이 장치들은 결국 배터리 소모 문제에 직면하게 되며, 시간을 부트스트랩하기 위해 보안 시간 시드 기능이 필요합니다.