연결할 수 없는 NTP 서버로 인한 클록 드리프트

Symptoms

시계는 실제로 보이는 화면에서는 거의 언급되지 않습니다. 증상은 대신 두 시스템의 시간이 일치하는 데 의존하는 모든 것에 나타납니다.

사용자는 로그인할 수 없거나 세션이 예상보다 빨리 종료됩니다.
GitHub Connect가 연결되지 않거나 라이선스 페이지가 서버 오류를 반환합니다.
GitHub Actions 작업이 시작되지 않거나 토큰이 잘못된 것으로 거부됩니다.
/var/log/github/exceptions.log에는 'Expiration time' claim ('exp') is too far in the future와 같이 토큰 만료 클레임이 미래의 너무 먼 시점으로 설정되었음을 나타내는 오류가 포함됩니다.
웹 인터페이스, 로그 또는 커밋의 타임스탬프는 예상 시간과 일치하지 않습니다.

클록이 잘못된 인스턴스에서 서명한 토큰은 토큰 자체에 아무런 문제가 없더라도 수신하는 시스템에는 유효하지 않은 것으로 보입니다. 따라서 이러한 실패는 시간이 아닌 인증을 가리킵니다.

원인

GitHub Enterprise Server UDP 포트 123을 통해 NTP(네트워크 시간 프로토콜) 서버와 동기화하여 시계를 정확하게 유지합니다. 그 중 하나 이상에 지속적으로 도달해야 합니다.

구성된 서버는 일반적인 사유로 연결할 수 없게 됩니다.

방화벽 또는 보안 그룹이 아웃바운드 UDP 포트 123을 차단하는데, 나머지 인스턴스는 작동하기 때문에 이 문제를 놓치기 쉽습니다.
내부 시간 서버는 서비스 해제되거나 이름이 바뀌었으며 인스턴스는 여전히 이전 주소를 가리키고 있습니다.
호스트 이름이 더 이상 IP 주소로 확인되지 않습니다.
서버가 하나만 구성되었으므로 서버가 사라지면 대체할 서버가 없습니다.

구성된 서버에 연결할 수 없는 경우 Chrony는 외부 수정 없이 로컬 시스템 클록을 계속 실행하여 GitHub Enterprise Server가 구성한 대체 스트라텀 10을 보고합니다. 이것은 크로니 외부에서 관리되는 별도의 장치인 하드웨어 시계가 아닙니다.

그 순간에 아무 것도 실패하지 않으며 오류가 발생하지 않습니다. 시계는 보정이 중단되어 처음에는 천천히 드리프트하다가, 정확한 시간에 의존하는 무언가가 고장 날 때까지 계속 어긋납니다. 드리프트가 커질수록 실패 범위가 더 커집니다.

가상 머신의 클록도 설정하려고 하는 하이퍼바이저는 인스턴스 자체 동기화와 충돌하여 동일한 결과를 초래할 수 있습니다.

문제 확인 중

관리 셸에 SSH로 접속합니다. 자세한 내용은 관리 셸(SSH)에 액세스을(를) 참조하세요.
시간 소스 및 해당 상태를 나열합니다.
```
sudo chronyc sources -v
```
각 소스의 왼쪽 열 MS을 읽으십시오. ?는 chrony가 해당 소스를 사용하지 않음을 의미합니다. 이것만으로는 네트워크 문제의 증거가 아닙니다. 동일한 표식이 동기화되지 않은 서버 자체와 아직 충분한 측정값을 제공하지 않은 소스에도 나타나기 때문입니다.

접근할 수 없는 소스는 같은 줄에 있는 근거로 식별됩니다. 아래 출력에서는 Reach은 0이고, 이는 최근 설문 조사 중 어느 것도 회신을 받지 못했다는 의미이며, LastRx는 -이고, 이는 샘플이 한 번도 도착한 적이 없다는 것을 의미합니다. 어느 서버도 한 번도 응답한 적이 없습니다.
```
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? ntp1.example.com              0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp2.example.com              0  10     0     -     +0ns[   +0ns] +/-    0ns
```
소스가 *로 표시된 경우 chrony가 해당 소스를 선택한 것이므로 도달 가능성 문제는 배제됩니다. Chrony가 큰 오프셋을 점진적으로 수정하고 그렇게 하는 동안 인스턴스가 실제 시간에서 크게 벗어날 수 있으므로 클록이 정확한지 확인하지 않습니다. 어느 쪽이든 나머지 검사를 계속합니다.
인스턴스가 실제로 무엇에 동기화되어 있는지 확인합니다.
```
sudo chronyc tracking
```
대괄호 안에 빈 이름이 있는 참조 ID는 10의 계층과 함께 인스턴스가 구성된 서버 사용을 포기했으며 자체 클록을 사용 중임을 의미합니다.
```
Reference ID    : 7F7F0101 ()
Stratum         : 10
System time     : 0.000000000 seconds fast of NTP time
```
Stratum은 참조 클록으로부터 인스턴스가 몇 단계 떨어져 있는지 나타내며, 인스턴스는 항상 자신이 따르는 서버보다 하나 더 높게 보고합니다. 10의 값은 특정한 값입니다. 즉, 사용할 수 있는 소스가 없을 때를 대비해 GitHub Enterprise Server이 구성하는 대체 값이므로, 이름 없는 참조 ID와 함께 표시되는 것이 그 신호입니다.

정상 인스턴스는 대신 팔로우하는 서버의 이름을 지정하고 해당 서버보다 하나 높은 스트라텀을 보고합니다.
```
Reference ID    : D9723B03 (ntp1.example.com)
Stratum         : 3
System time     : 0.000079420 seconds fast of NTP time
```

System time 는 인스턴스가 따르는 서버에 대해 측정되므로 자체 클록을 따르는 경우 값은 의미가 없습니다. 시계 오차가 얼마나 커졌든 관계없이 0에 가깝게 읽힙니다.

신뢰할 수 있는 기준 시간 소스와 인스턴스 클록을 비교하여 드리프트를 직접 측정합니다.
```
date -u
```
얼마나 크게 벗어났는지 확인해 보세요. 큰 차이는 시계가 제어되지 않은 채 드리프트되고 있는 것을 확인합니다.
기울어진 정도 및 유지된 샘플 수와 같은 각 원본에 대한 세부 정보를 원하는 경우 다음 명령을 사용합니다.
```
sudo chronyc sourcestats -v
```

문제 해결하기

먼저 동기화를 복원한 다음 동기화가 끊어진 동안 쌓인 드리프트를 수정합니다. 도달 가능성을 수정하지 않고 드리프트를 수정하면 다시 발생하기 전까지 시간을 벌 뿐입니다.

관리 콘솔의 "시간" 섹션에서 인스턴스가 어떤 서버를 대상으로 구성되었는지 확인합니다. 자세한 내용은 시간 동기화 구성을(를) 참조하세요.
인스턴스가 해당 대상에 연결할 수 있는지 확인합니다. 아웃바운드 UDP 포트 123은 인스턴스와 서버 사이의 모든 방화벽 및 보안 그룹에서 각 서버에 열려 있어야 합니다. 자세한 내용은 네트워크 포트을(를) 참조하세요.
서버가 사라지거나 해당 서버로 가는 경로를 열 수 없는 경우 인스턴스가 연결할 수 있는 서버를 구성합니다. 하나가 없어져도 인스턴스에 아무것도 남지 않는 일이 없도록 2개 이상을 구성합니다.
chrony가 시간 소스를 다시 선택했는지 확인합니다. 그 중 하나는 이제 Reach로 표시되어야 하며, *가 0이 아닌 값인 상태여야 합니다.
```
sudo chronyc sources -v
```
인스턴스가 동기화되지 않은 동안 누적된 드리프트를 수정합니다. NTP는 자체적으로 작은 불일치를 수정하지만 큰 차이는 다음 명령으로 수정해야 합니다. 자세한 내용은 시간 동기화 구성을(를) 참조하세요.
```
sudo chronyc -a makestep
```
이제 시계가 신뢰할 수 있는 기준 시간과 일치하는지 확인합니다. 이는 드리프트가 여전히 수정되고 있는 것이 아니라 실제로 사라졌다는 것을 알려주는 검사입니다.
```
date -u
```
실패하고 있던 것이 무엇이든 다시 시도하십시오.

재발 방지

두 개 이상의 시간 서버를 구성하므로 하나를 잃더라도 동기화가 중지되지 않습니다.
서버를 변경한 후 인스턴스가 실제로 서버에 연결할 수 있는지 확인합니다. 구성된 서버가 반드시 작동하는 것은 아니며 응답이 중지되어도 사용자에게 경고해 주지 않습니다.
방화벽 규칙이 변경되면 시간 서버에 아웃바운드 UDP 포트 123을 열어 두세요.
하이퍼바이저가 가상 머신의 클록을 설정하지 않도록 하여 인스턴스의 자체 동기화와 경쟁하지 않도록 합니다. 자세한 내용은 가상화 공급자가 제공하는 설명서를 참조하세요.
일상적인 상태 검사의 일부로 시간 소스를 확인합니다. 드리프트는 문제가 되기 전까지는 무해하며, 문제가 작을 때 포착하면 서로 관련 없는 여러 장애 중 어느 것이 클록 때문에 발생한 것인지 파악해야 하는 일을 줄여 줍니다.

연락하기 GitHub 지원

구성 및 네트워크 경로를 확인한 후에도 인스턴스가 여전히 시간 서버에 연결할 수 없거나, 시계가 정확해진 후에도 원래 증상이 계속되면 계속 진행하지 말고 GitHub 지원에 문의하십시오. 자세한 내용은 지원 티켓 만들기을(를) 참조하세요.

이미 티켓을 연 경우 지원 번들을 첨부하면 GitHub 지원 문제를 더 빠르게 진단하는 데 도움이 됩니다. 자세한 내용은 GitHub 지원에 데이터 제공을(를) 참조하세요.

연결할 수 없는 NTP 서버로 인한 클록 드리프트

이 기사에서

Symptoms

원인

문제 확인 중

문제 해결하기

재발 방지

연락하기 GitHub 지원

추가 읽기

이 문서가 도움이 되었나요?

계속 도움이 필요하세요?