새로운 시간 동기화의 표준 Chrony 트러블슈팅 가이드

오늘은 최근에 AOS 7.3.x 버전을 배포하면서 변경된 부분들을 체크 했는데 시간관리 데몬이 Chrony로 변경된 것을 확인했어.  그 부분에 대해 자세히 이야기 해 볼께. 

시간 동기화 바뀐 거 알지? 이제 옛날 ntp는 버려라

Nutanix AOS 6.8이나 PC 2024.1 올린 사람들 당황했지? 나도 어제 서버 시간 틀어져서 삽질하다 보니까 옛날 ntp-client가 싹 날아갔더라고. 이제 그 자리에 Chrony가 떡하니 자리 잡았어.

클러스터 환경에서 시간 1밀리초라도 어긋나면 데이터 정합성 다 깨져서 대형 사고 나는 거 알잖아? 이제 뒤에서 도는 chronyd 데몬이랑, 이거 조작하는 chronyc 명령어에 빨리 적응해야 해. 손에 익었던 ntpq니 ntpdate니 다 잊어버려. 장애 났을 때 당황하지 말고 내 트러블슈팅 기록 보면서 바로바로 써먹어 봐.

야, 타임 서버 안 붙어? 방화벽 탓하기 전에 데몬부터 살았는지 봐

장애 터지면 다들 막 복잡한 로그부터 뒤지려고 하는데, 진짜 제일 기본부터 가자. 프로세스 살아있어? 백그라운드 데몬이 죽어있는데 그 어떤 화려한 명령어 친다고 답이 나오겠냐. 일단 이거 한 줄 쳐서 심장 박동부터 확인해.

nutanix@CVM:~$ systemctl status chronyd

데몬 살아있는지 보는 건 트러블슈팅의 기본 중 기본이야. 이거 쳤을 때 초록색으로 Active: active (running) 떠 있는지 두 눈으로 똑똑히 확인해. 만약 데몬이 정지 상태거나 지 혼자 계속 재시작(restarting) 하고 있으면 백날 chronyc 명령어 날려봤자 답 안 돌아와. 시스템 부팅하고 데몬이 제대로 올라왔는지 무조건 먼저 챙겨라.

데몬 살아있어? 오케이. 그럼 이제 밖으로 찔러봐야지. 무턱대고 동기화부터 하겠다고 덤비지 마. 잘못해서 로컬 시간 확 틀어지면 노드 간 통신 다 끊어지고 지옥 열린다. 시간 값은 1도 건드리지 말고 얌전하게 핑만 날려보는 꿀팁 알려줄게.

nutanix@CVM:~$ chronyd -Q 'server <ntp-server> iburst'

옛날에 ntpdate -q 썼던 거 기억나지? 그거랑 똑같은 거야. 저기 -Q 옵션이 핵심인데, 내 시스템 시간은 절대 안 건드리고 상대방 타임 서버가 응답만 하는지 묻고 빠지는 거거든. 뒤에 붙은 iburst는 처음에 패킷 여러 개를 와다다 쏴서 동기화 확인 속도를 확 끌어올려 줘. 만약 여기서 'No suitable source for synchronisation' 뜨면 백퍼 우리 쪽 서버 문제는 아니야. 당장 네트워크 팀에 전화해서 UDP 123번 막혀있냐고 따져보자. 

네트워크 팀에 전화했더니 "방화벽 다 열려있는데요?" 이러지? 백퍼 이럴 줄 알았다. 뇌피셜로 싸우지 말고 팩트로 조져야 돼. 패킷 까보자.

nutanix@CVM:~$ sudo tcpdump -nn -i any udp port 123 and host <ntp-server>

괜히 역방향 DNS 찾는다고 버벅대지 말고 -nn 무조건 붙여라. 이거 걸어놓고 검은 화면 뚫어져라 쳐다봐. 우리 CVM에서 밖으로 나가는 Client 패킷(length 48)만 찍히고 돌아오는 Server 패킷이 하나도 없지? 이러면 100% 방화벽 인바운드 정책이 빠졌거나 라우팅 꼬인 거야. Client랑 Server 패킷이 탁구 치듯이 핑퐁 왔다 갔다 해야 네트워크 혐의 벗는 거다. 증거 캡처해서 네트워크 담당자한테 다시 던져.

도대체 누굴 바라보고 있는 거야? 동기화 소스 까보기

방화벽 뚫렸다고 끝난 줄 알았어? 아니야. 이제 데몬이 수많은 타임 서버 중에 누구랑 손잡고 있는지, 통신 퀄리티는 괜찮은지 봐야 돼. 네트워크 지연 때문에 엉뚱한 서버 쳐다보고 있으면 진짜 골치 아프거든. 옛날 그 보기 싫던 매트릭스 표보다 훨씬 깔끔하게 볼 수 있어.

nutanix@CVM:~$ sudo chronyc -n sources -v



chronyc 명령어 실행 장면

명령어 칠 때 -n 옵션은 선택이 아니라 필수다. 가끔 장애 상황에서 내부 DNS까지 맛이 가는 경우가 있는데, 저 옵션 안 넣으면 IP를 호스트네임으로 풀겠다고 데몬이 한참 동안 멍 때리면서 명령어 자체가 먹통이 돼버려. 바빠 죽겠는데 터미널 멈춰있으면 진짜 피 말리잖아? 그리고 실무에서 보면 피어(Peer) 상태가 고정된 게 아니라 네트워크 상황에 따라 엄청 널뛰기를 하거든. 그러니까 한 번만 치지 말고 몇 초 간격으로 여러 번 쳐서 상태 기호가 안정적으로 유지되는지 봐야 돼. 이거 치면 리스트가 쫙 나오는데, 복잡한 수치 다 무시하고 왼쪽에 붙은 기호들만 확실하게 챙겨가자.

상태 기호	실무 해석 (이것만 기억해!)
^*	현재 제일 짱짱한(Current best) 메인 타임 서버. CVM이 픽한 진짜 서버.
^~	시간이 너무 널뛰기해서 통신 품질을 못 믿겠는(too variable) 상태.
^?	응답이 아예 없거나 연결이 끊어진(unusable) 깡통 상태.

실무 꿀팁: Genesis 리더를 못 찾으면 평생 삽질한다

여기서 뉴비들이 제일 많이 하는 착각 하나 짚고 갈게. "클러스터 CVM 여러 대가 다 각자 타임 서버랑 통신하겠지?" 절대 아니야. Nutanix 아키텍처가 그렇게 비효율적이지 않아. 클러스터 안에 'Genesis 리더'라고 대장 노드가 딱 하나 있는데, 얘만 밖이랑 통신하고 나머지 일반 CVM들은 다 이 대장 시간만 따라가게 되어 있어.

nutanix@CVM:~$ allssh 'sudo chronyc tracking | grep Reference'

이 명령어 하나면 클러스터 시간 동기화 흐름 다 꿰뚫어 볼 수 있어. 딱 치면 외부 NTP IP나 도메인(예: 0A328014) 당당하게 쳐다보고 있는 놈이 딱 한 대 나올 거거든? 걔가 지금 클러스터 시간을 지배하는 Genesis 리더야. 나머지 평범한 노드들은 zk1, zk2 이러면서 내부 IP만 바라보고 있을 거고.

🚨 [경고] Reference ID 7F7F0101의 공포
여기서 진짜 주의할 거! Reference ID에 7F7F0101 떠있는 노드 있으면 당장 확인해. 그거 어떤 타임 서버랑도 연결 끊어져서 지 혼자 엉터리 로컬 시간 돌리고 있다는 미친 경고등이니까. 방치하면 클러스터 통째로 터진다.

🔥 1분 요약: Chrony 장애 시 3단 콤보 체크리스트

지금까지 말한 거 복잡하면 딱 이 세 가지만 순서대로 머릿속에 박아둬. 이것만 해도 삽질 시간 반으로 줄인다.

• 1단계 (생존 확인): systemctl status chronyd 쳐서 데몬이 초록불(running) 띄우고 있는지 무조건 제일 먼저 볼 것.
• 2단계 (네트워크 확인): chronyd -Q 날려서 응답 오는지 보고, 안 오면 바로 tcpdump 까서 방화벽 범인 색출할 것.
• 3단계 (리더 확인): allssh '... tracking' 때려서 우리 클러스터의 Genesis 리더가 외부 통신 잘 하고 있는지, 7F7F0101(고립 에러) 뜬 노드는 없는지 감시할 것.

화면이랑 터미널 설정값 왜 다르냐? 막타 확인

마지막으로 어이없는 실수 하나 잡아보자. 분명히 Prism 웹 화면엔 잘 세팅했는데, 터미널 까보면 딴 세상인 경우가 있어. 설정 파일 꼬인 거니까 논리적 설정이랑 물리적 상태가 똑같은지 크로스체크 무조건 해야 돼.

nutanix@CVM:~$ ncli cluster get-ntp-servers

클러스터 껍데기 설정값(ncli)이랑 아까 확인한 실제 데몬 물리적 상태가 일치하는지 싹 다 비교해 봐. 옛날 유령 서버 주소 남아있거나 타이핑 오타 난 거 있지? 이럴 땐 제발 CLI에서 파일 열어서 억지로 수정하려고 삽질하지 마. 깔끔하게 Prism Element 웹 접속해서 기존 NTP 다 지워버리고 새로 싹 등록해. 그게 설정 파일 꼬인 거 푸는 제일 안전하고 빠른 정공법이다. 내가 이거 때문에 새벽 3시까지 고생해 봐서 안다. ㅜ ㅜ 

오늘의 교훈은 사서 고생한다 입니다.  ㅋ 그럼 다음 글에서 만나 볼께요.